ontology reasoning differences viewer · vocabulary (as long as it complies rdf) features: meta...
TRANSCRIPT
1
Praktikum zu modellgetriebener
Softwareentwicklung
Thema 3:
Ontology Reasoning Differences Viewer
Ausarbeitung von
Gorana Bralo, Dominik Bösl, Chris Kämpfe
Sommersemester 2008
Universität Augsburg
Lehrstuhl Programmierung verteilter Systeme
Betreuer: Wolf Fischer
2
Inhalt
Inhalt ................................................................................................................................... 2
1. Einleitung .................................................................................................................. 3
2. Theoretische Grundlagen ......................................................................................... 3
a. Ontologien ........................................................................................................... 4
b. OWL ..................................................................................................................... 5
c. EMF, GEF & GMF.................................................................................................. 7
d. Protégé .............................................................................................................. 10
e. Jena .................................................................................................................... 10
f. Metamodell ............................................................................................................ 10
3. Konzept für Editor zum Anzeigen von Unterschieden zwischen gelernten und
ungelernten Ontologien .................................................................................................... 11
4. Überarbeitung des Metamodells anhand der Praxis .............................................. 14
5. Das Jena-Framework ............................................................................................... 16
6. Konzept zur Erstellung des ORDVEditors ................................................................ 17
7. How-To zur Installation und Verwendung des Editors ........................................... 22
3
1. Einleitung Das Internet der heutigen Zeit bietet eine Flut an Informationen, die auf alle
Fragen Antworten zu geben scheint. Theoretisch steht jedem Menschen, soziale
und kulturelle Barrieren einmal außer Acht gelassen, beliebiges Wissen auf Abruf
zur Verfügung. Der vermeintliche Segen dieser Datenflut hat jedoch in den
letzten Jahren immer mehr seine Janusköpfigkeit offenbart und ist auf dem
besten Weg, sich in einen Fluch des Verloren-Gehens im Web zu entwickeln.
Auch allen Versuchen, das Internet durch mehr Animation und
Benutzer(un)freundlichkeit in seine Version 2.0, 3.0 oder beliebige weitere
Revisionen zu transformieren helfen nicht, sich in der Masse an Webseiten
zurechtzufinden oder sie automatisiert inhaltlich erfassen, verarbeiten oder auch
nur kategorisieren zu können. Diese mangelnde Möglichkeit einer
Semantisierung der Webinhalte wurde allerdings mittlerweile erkannt und es
wird von vielen Institutionen, Firmen und Forschergruppen versucht, den nicht
interpretierten Daten eine Bedeutung zuzuordnen um das Ziel, ein lernendes
oder gar wissendes System, zu erreichen.
Im Lauf der Forschung, auf welche Art und Weise man es den Rechnersystemen
ermöglichen kann, Wissen zu speichern und semantische Beziehungen erfassen
zu können, haben sich verschiedenste Lösungsansätze herausgebildet. Einer
davon ist das Modell der Ontologien, die Beziehungen zwischen „Objekten“
beschreiben und deren Relationen zueinander auf einer „Metaebene“
widerspiegeln. Durch die Angabe von Beispielrelationen kann das System dann
„lernen“ und ähnliche Beziehungen auf dieselbe Weise kategorisieren. Jedoch ist
es für den Menschen schwierig bis schlichtweg unmöglich, die Unterschiede
zwischen einer zugrunde liegenden aufwendigen Ontologie mit sehr vielen
Elementen und der bereits gelernten ausfindig machen zu können.
Daher soll im Verlauf dieses Praktikums eine Software erstellt werden, die es
ermöglicht, eine zuvor erstellte Ontologie und das zugehörige, bereits gelernte
Pendant einzulesen, wechselweise anzuzeigen und die entsprechenden
Unterscheide graphisch hervorzuheben.
2. Theoretische Grundlagen Um jedoch das Konzept und die Vorgehensweise bei der Entwicklung des Editors
beschreiben zu können, müssen einige grundlegende Modelle, Konstrukte sowie
Frameworks erläutert werden.
4
a. Ontologien
Eine Ontologie in der Informatik stellt eine formale Repräsentation einer Menge
von Konzepten innerhalb eines inhaltlichen Bereichs und deren Beziehungen
untereinander dar. Sie dient dem „Reasoning“ über die Eigenschaften des
jeweiligen Themengebietes sowie dessen Definition.
Ontologien kommen klassischerweise in der Künstlichen Intelligenz, dem
Semantic Web, Software Engineering, der Bioinformatik und als eine Form der
Wissensrepräsentation zum Einsatz.
Im Gegensatz zu klassischen Datenbanken, die keine Informationen über die
Bedeutung der gespeicherten Daten haben, besitzen Ontologien eine formale
Beschreibung der Daten sowie Regeln über deren Zusammenhang. Diese Regeln
erlauben es, Rückschlüsse aus den vorhandenen Daten zu ziehen, Widersprüche
in den Daten zu erkennen und fehlendes Wissen selbständig aus dem
Vorhandenen zu ergänzen. Diese Rückschlüsse werden durch logisches Folgern
(Inferenz) abgeleitet.
Um über einen Grundstock an semantischem Wissen verfügen zu können, muss
dieses zuerst vom Menschen in der Ontologie hinterlegt werden. Danach kann
die Ontologie aber durch automatische Verfahren weiteres Wissen akquirieren
sowie zusammenhänge erkennen und erlernen. Somit liegt nach dem Reasoning
eine „(an)gelernte) Ontologie vor, die im Unterschied zur Ausgangsontologie
über weitere Relationen verfügt. Wird zum Beispiel das Wissen „Ein Hund ist ein
Tier“ und „Snoopy ist ein Hund“ hinterlegt, so kann automatisch der
Zusammenhang „Snoopy ist ein Tier“ erkannt werden und „Snoopy“ würde als
Antwort auf die Frage nach allen Tieren in einer Datenbank zurückgeliefert
werden.
Ontologien bestehen aus folgenden Elementen:
Klassen (engl. Concepts) - Zusammenfassung gemeinsamer
Eigenschaften; manchmal auch als Klassen bezeichnet; mönnen in
Klassenstruktur angeordnet werden
Instanzen – Repräsentieren Objekte; stellen zur Verfügung stehende
Wissen dar
Relationen – Beziehung, in der Klassen und Objekte zueinander stehen;
Bezeichnen „Eigenschaften“ der Objekte
Vererbung – Relationen können vererbt werden; Mehrfachvererbung
theoretisch möglich; Einsatz von Transitivität erlaubt (auch Delegation
genannt)
5
Axiome – Aussagen innerhalb der Ontologie, deren Wahrheitswert immer
true ist; Dienen der Repräsentation von nicht ableitbarem Wissen
Abbildung 1 - Beispiel einer Ontologie zur Kategorisierung von Wein
Ontologien lassen sich in zwei Typen einteilen. Die sogenannten lightweight-
Ontologien werden durch Begriffe, Taxonomien und Beziehungen zwischen
Begriffen gebildet. Im Gegensatz dazu sind die heavyweight-Ontologien
Erweiterungen der leichtgewichtigen und ergänzen diese durch Axiome und
Einschränkungen, die die gewünschten Aussagen innerhalb der Ontologien
präzisieren.
b. OWL Um Ontologien beschreiben zu können bedient man sich so genannter knowledge
representation languages. Eine wichtige Familie davon bildet die Web Ontology
Language (OWL) die seit 2004 vom World Wide Web Consortium (W3C) standardisiert
ist. Dabei erlaubt es OWL, folgende Ontologiebestandteile zu beschreiben:
classes, class hierarchies
properties, property hierarchies
domain and range restrictions
6
logical expressions (and, or, not)
(in)equality
local properties
required/optional properties
required values of properties
enumerated classes
transitivity, symmetry, inverse of relations1
Die OWL-Sprachfamilie besteht hauptsächlich aus zwei größtenteils zueinander
kompatiblen Semantiken, OWL DL und OWL Lite; zudem existiert eine weniger
verbreitete Variante, der OWL Full Dialekt. OWL Lite, OWL DL und OWL Full
unterscheiden sich wie folgt:
OWL Lite OWL DL OWL Full
Classification hierarchy, simple constraints Features:
(sub)classes, individuals
(sub)poperties, domain, range
conjunction
(in)equality
cardinality constraints 0/1
datatypes
inverse, transitive, symmetric properties
someValuesForm
allValuesForm
Maximal expressiveness while maintaining tractability Direct correspondence with a Description Logic Features:
Negation
Disjunction
Full cardinality
Enumerated types
Very high expressiveness by losing tractability No restriction on use of vocabulary (as long as it complies RDF) Features:
Meta-classes
Modifying language
Abbildung 2 - Überblick über die OWL-Sprachfamilie 2
Die Semantik von OWL DL und OWL Lite basiert auf deskriptiver Logik, die über den
Vorteil verfügt, in ihrer Theorie sehr gut verstanden und analysiert zu sein und sich
durch die Berechenbarkeit Ihrer Eigenschaften auszeichnet. OWL Full hingegen
verwendet ein neuartiges semantisches Modell, das sehr stark in Anlehnung an das RDF
Schema gehalten ist um an dieser Stelle größtmögliche Kompatibilität zu ermöglichen.
1 Prof. Dr. Dr. h.c. Manfred Broy, Modellbildung in der Entwicklung, Vorlesung SoSe 2007,
TUM 2 ibid
7
Dabei gelten folgende Zusammenhänge:
Jede zulässige (legal) OWL Lite Ontologie ist eine zulässige OWL DL Ontologie.
Jede zulässige OWL DL Ontologie ist eine zulässige OWL Full Ontologie.
Jede gültige (valid) OWL Lite Schlussfolgerung (conclusion) ist eine gültige OWL
DL Schlussfolgerung.
Jede gültige OWL DL Schlussfolgerung ist eine valide OWL Full Schlussfolgerung 3
Die OWL-Ontologien selbst werden in einer RDF/XML-ähnlichen Syntax modelliert, was
einen der Gründe für die fundamentale Bedeutung von OWL für das Semantic Web
darstellt. Die durch eine OWL Ontologie beschriebenen Daten werden als eine Menge an
individuals und einer Menge von property assertions intrerpretiert, die diese Instanzen
mit einander verknüpfen. Die Ontologie an sich besteht aus einer Menge von Axiomen,
die bestimmte Eigenschaften einer Menge von idividuals, classes genannt, sowie deren
Beziehung zueinander festlegen. Aus diesen axiomatischen Beziehungen ergeben sich
auch die in der Ontologie gespeicherten semantischen Informationen.
Die Definition einer Relation zwischen zwei Instanzen zweier Klassen in OWL sieht
exemplarisch so aus:
Abbildung 3 - exemplarische OWL Beschreibung
c. EMF, GEF & GMF Bei EMF, EGL und GMF handelt es sich um Frameworks, die den Programmierer bei der
automatisierten Erzeugung von Quelltext aus strukturierten Modellen unterstützen
wollen.
EMF steht dabei für Eclipse Modeling Framework und stellt ein Open Source Java
Framework dar. Es ist in der Lage aus einem auf offenen Standards basierenden Modell
Java-Code zu erzeugen. Die Modell-Spezifikation dafür wird in XMI erstellt, das Modell
an sich kann entweder aus kommentiertem Java Code oder einem oder mehreren XML
Dokumenten bestehen sowie in einem Modellierwerkzeug wie etwa Ration Rose erstellt
und dann in EMF importiert werden. Das daraus resultierende Programm kann
wiederum Instanzen dieses Modells abfragen, serialisieren, manipulieren, erstellen,
validieren und Änderungen überwachen. Auch das automatisierte Erstellen von JUnit-
Code zum Testen des generierten Codes ist möglich. Vorteile des EMF sind dabei die
3 Nach Wikipedia-Eintrag der englischen Wikipedia zum Begriff „Web Ontologie
Language“
8
enge Integration in Eclipse mit allen daraus resultierenden Mehrwerten, wie der
erleichterten Erstellung von User Interfaces und der Interoperabilität mit anderen
Eclipse Projekten wie etwa GMF.
GEF bezeichnet das Eclipse Graphical Editing Framework, welches es dem Entwickler
ermöglicht, graphische Editoren mit einer reichen Palette an Funktionen aus seinen
bereits vorhandenen Anwendungsmodellen zu erstellen. Es setzt sich aus zwei Plugins
zusammen, wobei das org.eclipse.draw2D plugin ein Layout und Rendering Toolkit zum
Anzeigen von Graphiken anbietet. Dabei setzt GEF auf eine model-view-controller
Architektur.
Abbildung 4 - Ein mit GEF erstellter Editor zum Einfügen von Formen 4
Das Ecipse Graphical Modeling Framework, auch GMF, setzt schlussendlich auf EMF und
GEF auf und bietet eine generative Komponente sowie eine Laufzeit Infrastruktur, mit
deren Hilfe die Entwicklung von graphischen Editoren vereinfacht wird. Folgende Grafik
verdeutlicht den Workflow bei der Erstellung eines GMF Projektes.
4 GEF Tutorial, „A Shape Diagram Editor”, http://www.eclipse.org/articles/Article-GEF-
diagram-editor/shape.html
9
Abbildung 5 - Workflow zur Erstellung eines GMF Projektes 5
Durch den Einsatz von GMF werden viele Arbeitsschritte bei der Erstellung eines
graphischen Editors zusammengefasst oder automatisiert und die Entwicklungszeit bzw.
–Komplexität für aufwendige graphische Eingabetools erheblich reduziert.
Abbildung 6 - Ein fertiger GMF-Editor zur Erstellung von Mindmaps 6
5 GMF Tutorial auf Eclipse.org, http://wiki.eclipse.org/GMF_Tutorial
6 GMF Beispiel aus der GMF Gallerie auf Eclipse.org,
http://www.eclipse.org/modeling/gmf/gallery/mindmap.png
10
d. Protégé Der Protégé-Ontologie Editor dient der einfachen graphischen Erstellung von
Ontologien. Somit müssen Ontologien nicht mehr aufwendig rein textuell
„programmiert“ werden sondern können, ähnlich einem UML-Diagramm, gezeichnet
werden. Um mit Protégé auch OWL-konforme Ontologien erstellen zu können, bietet
der Editor die Möglichkeit, diese Funktionalität durch Plugins nachzurüsten. Dadurch ist
es möglich OWL und RDF Ontologien zu laden und zu speichern, Klassen, Eigenschaften
sowie SWRL-Regeln anzuzeigen und zu verändern, logische Klassen-Charakteristiken und
OWL-Ausdrücke zu definieren, Reasoner auszuführen und OWL-Individuals für den
Einsatz im Semantic Web zu editieren.7
e. Jena Jena ist ein auf Java basierendes Framework zur Erstellung von Semantic Web
Anwendungen. Hierfür wird eine Programmierumgebung bereitgestellt um auf RDF oder
OWL zugreifen zu können.
Aufgrund einer vielzahl von Java Interfaces und entsprechenden Implementationen ist
es möglich RDF Ressourcen zu repräsentieren. Somit können Graphen oder Modelle
erstellt und manipuliert werden.
Ein weiterer Mechanismus von Jena ist das Einlesen und Ausgeben von RDF Strukturen,
welcher ein wichtiger Teil des Praktikums darstellen wird.
f. Metamodell Bei der modellgetriebenen Softwareentwicklung spielen formale Modelle eine große
Bedeutung. Dabei geht es um Modelle, die die Funktionalität der zu entwickelnden
Software widerspiegeln und zwar auf einem höheren Abstraktionsniveau, absolut
Plattform unabhängig und Programmiersprachen unabhängig. Je näher so ein Modell an
dem Problemraum definiert ist und je ausdrucksstärker seine Elemente sind, desto
geringer gestaltet sich später der Aufwand bei der Entwicklung der Software. Ist das
Modell selbst mit ausreichend Semantik angereichert, so können z.B. Templates
definiert werden, die eine automatische Codegenerierung direkt aus dem Modell heraus
ermöglichen. Um solche formalen Modelle überhaupt definieren zu können bedarf es
einer Modellierungssprache, der so genannten DSL (Domain Specific Langauge). Es gibt
zwei Möglichkeiten eine Modellierungssprache zu wählen: Entweder durch Erweiterung
von UML durch Profile oder durch Definition einer von Grund auf neuen Sprache, die
speziell auf den vorliegenden Problemraum zugeschnitten ist. Im Rahmen dieses
Projektes werden wir auf die erste Möglichkeit zurückgreifen und UML für unsere
Bedürfnisse passend erweitern. Die Erweiterung einer schon vorhandenen Sprache
sowie die Definition einer absolut neuen Sprache erfolgt anhand so genannter
Metamodelle. Die griechische Vorbsilbe „meta“ bedeutet so viel wie „über“.
Metamodelle sind also Modelle, die etwas über die Modellierung aussagen. Ein 7 Protégé-OWL Beschreibung auf http://protege.stanford.edu/overview/protege-
owl.html
11
Metamodell definiert in abstrakter Weise die Modellelemente bzw. Konstrukte, die
verwendet werden können, um eine Modell zu erstellen. Ein Modell ist damit als eine
Instanz eines Metamodells zu sehen. Für das zugrunde liegende Projekt sieht das
Metamodell wie folgt aus:
Abbildung 7 - Metamodell (Erweiterung des UML Metamodells)
Das Metamodell besteht in diesem Fall aus einer Klasse und einer Property. Anhand der
Elemente dieses einfachen Metamodells ist man in der Lage komplexere Modelle zu
erstellen. Die erstellten Modelle werden im Kontext dieses Projektes schließlich als
Ontologien bezeichnet, die im Editor graphisch angezeigt werden und deren
Unterschiede ebenfalls graphisch hervorgehoben werden sollen. Im nächsten Abschnitt
wird näher auf das Konzept eingegangen.
3. Konzept für Editor zum Anzeigen von Unterschieden
zwischen gelernten und ungelernten Ontologien Ein nur schwer zu überblickendes Problem zwischen einer ungelernten und gelernten
Ontologie ist zuerkennen, was die gelernte Ontologie letztendlich gelernt hat.
12
Aufgabe für das Praktikum soll sein, einen Editor zu entwerfen, welcher die
Unterschiede zwischen den Ontologien graphisch hervorhebt und darstellt. Somit kann
überprüft werden, ob die gelernte Ontologie auch nichts „Falsches“ gelernt hat.
Im folgenden Abschnitt wird bildhaft dargestellt, wie der Aufbau des Konzeptes gedacht
ist.
Abbildung 8 zeigt eine ungelernte Ontologie. In dieser ist zu erkennen, welche
Beziehungen zwischen Personen bestehen, z.B. wer mit wem verheiratet ist oder wer
die Kinder des Ehepaares sind.
Abbildung 8 - Ein ungelernte Ontologie
In Abbildung 9 wird die gleiche Ontologie dargestellt nur das sie bereits Wissen
akquiriert hat.
In der linken oberen Hälfte des Bildes befinden sich wieder die Beziehungen der
Personen aus der vorangegangenen Abbildung 8.
Hinzukommt, dass die Ontologie aufgrund der Beziehungen der einzelnen Personen
gelernt hat, welche Person eine andere Person kennt. Anhand dieser Abbildung lässt
sich schon erkennen, dass der Überblick recht schnell verloren geht, welches Wissen neu
hinzugekommen ist.
13
Abbildung 9 - Ein ungelernte Ontologie
Der zu entwickelnde Editor soll die unterschiede der zwei Ontologien herausfinden und
diese darstellen (vgl. Abbildung 10).
In der Abbildung werden nur noch die Beziehungen dargestellt, wo eine Person die
andere kennt. Also das gelernte Wissen und somit die Unterschiede der Ontologien.
Abbildung 10 - Ein ungelernte Ontologie
Die grundlegende Idee des Editors ist somit das Einlesen von zwei Ontologien, welche
ebenfalls über den Editor angezeigt werden können. Nach erfolgreichem Einlesen sollen
die Unterschiede festgestellt und entsprechend angezeigt werden. Hierbei soll der
Editor auf dem Jena Framework aufbauen, um die Manipulationen an den Daten
vornehmen zu können.
14
4. Überarbeitung des Metamodells anhand der Praxis
Metamodell
Bei der modellgetriebenen Softwareentwicklung spielen formale Modelle eine
große Bedeutung. Dabei geht es um Modelle, die die Funktionalität der zu
entwickelnden Software widerspiegeln und zwar auf einem höheren
Abstraktionsniveau, absolut Plattform unabhängig und Programmiersprachen
unabhängig. Je näher so ein Modell an dem Problemraum definiert ist und je
ausdrucksstärker seine Elemente sind, desto geringer gestaltet sich später der
Aufwand bei der Entwicklung der Software. Ist das Modell selbst mit ausreichend
Semantik angereichert können so z.B. Templates definiert werden, die eine
automatische Codegenerierung direkt aus dem Modell heraus ermöglichen. Um
solche formalen Modelle überhaupt definieren zu können bedarf es einer
Modellierungssprache, der so genannten DSL (Domain Specific Language). Es gibt
zwei Möglichkeiten eine Modellierungssprache zu wählen: Entweder durch
Erweiterung von UML durch Profile oder durch Definition einer von Grund auf
neuen Sprache, die speziell auf den vorliegenden Problemraum zugeschnitten ist.
Im Rahmen dieses Projektes werden wir auf die erste Möglichkeit zurückgreifen
und UML für unsere Bedürfnisse passend erweitern. Die Erweiterung einer schon
vorhandenen Sprache sowie die Definition einer absolut neuen Sprache erfolgt
anhand so genannter Metamodelle. Die griechische Vorbsilbe „meta“ bedeutet
so viel wie „über“. Metamodelle sind also Modelle, die etwas über die
Modellierung aussagen. Ein Metamodell definiert in abstrakter Weise die
Modellelemente bzw. Konstrukte, die verwendet werden können, um ein Modell
zu erstellen. Ein Modell ist damit als eine Instanz eines Metamodells zu sehen.
Für das zugrunde liegende Projekt sieht das Metamodell wie folgt aus:
15
Abbildung 11 - Neues Metamodell
Es besteht aus sieben Klassen, die miteinander verbunden sind. Damit ist
festgelegt in welcher Weise Elemente, die im Editor graphisch dargestellt werden
sollen, erstellt und miteinander verknüpft werden können. Die Klasse
ElementDiagram ist dabei die Superklasse, die alle möglichen graphischen
Elemente enthält, die darstellbar sind. Diese graphischen Elemente sind durch
die Klasse GraphicalElements definiert. Alle Elemente, die von dieser Klasse
erben, besitzen drei Attribute: eine ID, zur eindeutigen Identifizierung, einen
Namen und ein Attribut „isHighlighted“ vom Typ Boolean. IsHighlighted gibt an,
ob das Element farblich hervorgehoben ist oder nicht, was bei der Darstellung
der Unterschiede zwischen zwei Ontologien eine Rolle spielt. Diese Unterschiede
werden farblich markiert.
Zu den darstellbaren graphischen Elementen zählen die TBoxClass, Property und
Datatype. Die TboxClass definiert alle möglichen bzw. auftretenden Klassen einer
vorliegenden Ontologie, mit der später konkrete Individuals abgeleitet werden
können. Ein Beispiel für eine TBoxClass ist eine Klasse namens „Person“ von
welcher eine konkrete Instanz (Individual), wie „Peter“ abgeleitet werden kann.
Jede TBoxClass kann außerdem eine oder auch mehrere Properties besitzen, die
16
ebenfalls graphisch dargestellt werden können. Eine Property kann entweder
eine DatatypeProperty sein, die etwas über den Datentyp einer TBoxClass
aussagt oder aber eine ObjectProperty, die die Eigenschaften einer TBoxClass
beschreibt. Eine ObjectProperty sagt etwas über die Beziehung der TBoxClass zu
anderen TboxClasses aus. Besitzt eine Klasse eine oder mehrere
ObjectProperties, dann sagt dies aus, dass diese TBoxClass in Beziehung zu einer
oder mehreren TBoxClasses steht. Eine ObjectProperty könnte z.B. „gehört zu“
sein. Daraus ergibt sich, dass eine ObjectProperty also eine Range- und eine
Domain-Klasse hat, d.h. eine Quell- und eine Zielklasse.
Schließlich gibt es noch die Klasse Datatype, die die Oberklasse für die
DatatypeProperties darstellt und selbst von der Klasse GraphicalElements erbt.
Im entwickelten Editor können demnach Klassen, ihre Datentypen und
Relationen untereinander graphisch dargestellt werden. Aufgrund dieses
Metamodells können so im weiteren Verlauf alle nötigen Elemente einer
Ontologie visualisiert werden und mit Hilfe von zusätzlichem selbst
geschriebenem Code letztendlich die Unterschiede zweier Ontologien graphisch
dargestellt und hervorgehoben werden.
5. Das Jena-Framework
Jena ist ein auf Java basierendes Framework zur Erstellung von Semantic Web Anwendungen.
Abbildung 12 - Jena Homepage
17
Hierfür wird eine Programmierumgebung bereitgestellt um auf RDF oder OWL zugreifen zu können. Aufgrund einer Vielzahl von Java Interfaces und entsprechenden Implementierungen ist es möglich RDF Ressourcen zu repräsentieren. Somit können Graphen oder Modelle erstellt und manipuliert werden. Ein weiterer Mechanismus von Jena ist das Einlesen und Ausgeben von RDF Strukturen, welcher ein wichtiger Teil des Praktikums darstellt. Um die Elemente der Ontologien in den Editor zu laden und graphisch darstellen zu können, müssen zunächst die OWL-Dateien, d.h. ihre Elemente, eingelesen werden. Dazu müssen die Libraries von Jena als Plugin in Eclipse eingebunden werden, damit man auf die Methoden zugreifen kann. Ist dies geschehen, so ist es möglich die Klassen und Properties der OWL-Datei mit entsprechenden Methoden auszulesen und schließlich an die Klassen zu übergeben, die diese Elemente zeichnen sollen. Dazu erstellt man als erstes ein leeres Ontology-Modell. So ein Modell wird dabei als eine Menge von Statements definiert, z.B. Ressourcen, Properties usw., die miteinander auf eine bestimmte Art und Weise verknüpf sind. Hat man die zu ladende OWL-Datei ausgewählt, wird mit Hilfe eines InputStreams die Datei eingelesen und in das zuvor erstellte leere Ontology-Modell geschrieben. Diese Modell enthält jetzt alle vorhandenen Elemente der eingelesen Ontologie und nun hat man mehrere Möglichkeiten auf die Elemente zuzugreifen. Es ist möglich alle Elemente, d.h. Statements auszulesen, nur die Klassen (Ressourcen) oder auch nur die Properties. Bei den Properties wird außerdem unterschieden zwischen DatatypeProperties und ObjecttypeProperties. Für dieses Praktikum werden jeweils zwei Ontologien auf diese Art eingelesen, jeweils ihre Klassen und ObjectProperties ausgelesen, miteinander verglichen und schließlich gezeichnet.
6. Konzept zur Erstellung des ORDVEditors
Im folgenden wird skizzenhaft geschildert wie der Ontology Reasoning Difference
Viewer Editor – kurz: ORDVEditor – mithilfe von GMF (Graphical Modelling
Framework) erstellt wurde.
Um einen Editor erstellen zu können benötigt man ein Metamodell (siehe
Abschnitt 4), welches durch GMF mittels Drag & Drop erstellt werden kann. Das
Metamodell bildet die Grundlage für den weitere Erstellung des Editors und wird
im Format einer *.ecore Datei gespeichert. Somit wird ermöglicht das
strukturelle Modelle definiert werden können.
Neben dem ecore-Modell wird ebenso das Generatormodell benötigt, auch
genmodel genannt. Im Gegenteil zum ecore-Modell enthält das genmodel nur
plattformspezifische Informationen und dient zum Generieren der Quelltexte.
Dabei kann festgelegt werden, welche Pakete verwendet werden sollen oder
auch die Darstellung der Modellstrukturen. Im konkreten generiert das
18
genmodel drei Projekte: ORDVEditor.editor (Benutzerschnittstellen),
ORDVEditor.edit (Adapter) und ORDVEditor (Schnittstellenklasse für alle
modellierten Objekte).
Dieser erste Teil entspricht die Erstellung des EMF-Bereichs des Editors. Der
folgende Teil erläutert die Erstellung der GMF Funktionalitäten. Mittels GMF
kann eben EMF und GEF in der gleichen Umgebung erstellt werden.
Als nächstes wird graphische Notation des Editor spezifiziert im gmfgraph. Der
Entwickler muss nun entscheiden, wie seine Elemente dargestellt werden sollen.
Der ORDVEditor besteht derzeit aus TboxClassen – dargestellt als Rechtecke –
und aus Datatypes – dargestellt als Ellipsen. Diese Elemente müssen auch
verbunden werden werden mit so genannten Connections. Im Projekt gibt es
zwei Connections, eine ObjectProperty und eine DatatypeProperty. Beide
Connections werden als eine durchgezogenen Linie mit einem Pfeil an einem
Ende dargestellt. Somit ist bis auf weiteres die graphische Notation des Editors
vereinbart worden.
Damit auf die graphischen Elemente zugegriffen werden kann, muss ebenfalls ein
gmftool
erstellt werden. Dies ist eine einfache Zuordnung, welche Inhalte die Palette des
späteren Editors enthalten soll.
Im vorletzten Schritt widmen wir uns der Erstellung der gmfmap. Die gmfmap
zählt nicht mehr zu GEF, sondern ist ein wichtiger Schlüssel für GMF. Denn
Anhand dieser wird das Mapping der drei zuvor erstellten Modelle
zusammengeführt und wird als Input verwendet um letztendlich das gmfgen
Modell zu generieren.
Mit dem gmfgen Modell steht man unmittelbar vor dem Ziel der Erstellung eines
Editors. Nachdem im gmfgen alle graphischen Elemente und Mappings
zusammengefügt wurden, kann nun daraus der lauffähige Editor generiert und
anschließend gestartet werden.
19
In der Abbildung sieht man
den Überblick von dem
bereits erzählten Modellen
sowie die erzeugten
Projekte aus dem genmodel.
Alle besprochenen Modelle
befinden sich im Ordner
model.
Nach erfolgreichem
generieren des gmfgen kann
über Run As -> Eclipse
Application der Editor
gestart werden.
Abbildung 13: Übersicht GMF Modelle
In der Abbildung 14 sieht man den gestarteten Editor. Am rechten Bildrand ist
die Palette, welche über das gmftool Modell kreiert wurde. Durch Drag & Drop
lassen sich die Elemente auf die Arbeitsfläche ziehen und entsprechend
verbinden. Wobei das Metamodell vorschreibt, welche Modellstrukturen zulässig
sind. So kann beispielsweise eine DatatypeProperty nie von einer TboxClass auf
einen Datatype zeigen.
20
Nach dem momentanen Stand ist es jedoch noch nicht möglich OWL Dateien zu
laden.
Um OWL Dateien zu bearbeiten wird das JENA Framework verwendet, welches
das einlesen von Web Ontology Languages unterstützt.
Die Ablauflogik hinter dem ORDVEditor ist die, dass zwei OWL Dateien
angegeben werden. Diese werden über JENA eingelesen und durch die Logik
verarbeitet. Dabei wird zunächst die ungelernte Ontologie geladen und intern
abgelegt, woraufhin anschließend die gelernte Ontologie geladen und
gespeichert wird. Nun werden alle Objekte der Ontologie mit der ungelernten
verglichen und bei Unterschieden zwischen diesen auch entsprechend vermerkt.
Nach dem dies erfolgreich durchgeführt wurde, müssen die Unterschiede wie
auch die Ontologien noch im Modell abgelegt und auf der GUI gezeichnet
werden.
GMF verwendet das Model-Viewer-Controller Pattern (MVC), was bedeutet, dass
das Modell und der Viewer über einen Controller kommunizieren müssen.
Deswegen müssen die Veränderungen über Commands durchgeführt werden,
damit das Modell und die GUI angepasst werden.
Abbildung 14: Beispiel ORDVEditor
21
1) CreateElementRequest cer = new CreateElementRequest(editDomain, 2) (EObject)diagrammeditpart.getModel(), elementType, 3) ORDVEditorPackage.Literals.ELEMENT_DIAGRAM__CONTAINS);4) Command tccc = new ICommandProxy(new TBoxClassCreateCommand(cer));5) dcs.execute(tccc); 6) TBoxClass eobj = (TboxClass)cer.getNewElement(); 7) SetRequest reqSet = new SetRequest(ed, eobj, 8) ORDVEditorPackage.Literals.GRAPHICAL_ELEMENTS__NAME, 9) „Name“); 10)SetValueCommand operation = new SetValueCommand(reqSet); 11)dcs.execute(new ICommandProxy(operation));
Abbildung 15: Ausführung eines Commands
Wie ein Command aussieht soll Abbildung 15 zeigen. In Zeile 1 wird eine
Anforderung (Request) erstellt für ein neues Element. Diese beinhaltet unter
anderem was für ein Typ es sein soll, im Beispiel eine TboxClass. Als nächstes
wird der Request an ein TboxClassCreateCommand (Zeile 4) weitergeleitet,
welcher wiederum „eingepackt“ ist. Das Command wird in Zeile 5 ausgeführt und
somit ist das Modell auf dem neusten Stand. Da aber die neue TboxClass noch
keinen Namen hat wird dies in Zeile 6 bis 11 noch nachgeholt. D.h. man holt sich
das neu erstellte Element (Zeile 6) führt einen neuen Request aus. Dieser
beinhaltet das neue Element, was geändert werden – der Name – und was für
ein Wert es bekommen sollen (Zeile 7 – 9). Damit das ganze auch wieder zum
Abschluss kommt benötigt man noch Zeile 11, wo das Command ausgeführt
wird.
Der Editor ist nun soweit lauffähig, das er eine OWL Datei einlesen kann, die
eingelesenen Elemente an das Modell weiterreicht und daraufhin auch die GUI
neu zeichnet. Somit lassen sich die Ontologien anzeigen sowie auch deren
Unterschiede.
22
7. How-To zur Installation und Verwendung des Editors
Im Folgenden wird beschrieben, wie der ORDV-Editor installiert und verwendet werden
kann. Voraussetzungen dazu sind eine lauffähige, aktuelle Installation von Eclipse (der
ORDV-Editor ist bisher auf Eclipse EUROPA und GANYMEDE getestet worden) sowie das
vollständige ORDV-Editor Package inklusive Jena-Framework.
1. Öffnen Sie Eclipse
2. Erstellen Sie ein neues Java Projekt
23
Abbildung 16 - Neues Java-Projekt erstellen
3. Benennen Sie es
Abbildung 17 - Bennen des Java-Projektes
4. Importieren Sie alle vier Teilprojekte aus dem ORDV-Archiv
24
Abbildung 18 - Importieren der Teilprojekte (1)
5. Wählen Sie "General"- "Existing Project into Workspace" aus
Abbildung 19 - Importieren der Teilprojekte (2)
25
6. Wählen Sie das ORDV-Editor Verzeichnis aus
Abbildung 20 - Importieren der Teilprojekte (3)
7. Selektieren Sie die Teilprojekte und das Jena-Framework
Abbildung 21 - Importieren der Teilprojekte (4)
26
8. Nun müssen die Referenzen auf das Jena-Framework gesetzt werden.
Öffnen Sie dazu das Paket ORDVEditor im Paketexplorer und klicken Sie
doppelt auf die Datei "Plugin.xml".
Abbildung 22 - Aktualisieren der Jena-Dependency (1)
9. Klicken Sie auf den Reiter "Dependencies" unter dem erschienenen
Fenster und dort auf "Add".
Abbildung 23 - Aktualisieren der Jena-Dependency (2)
27
10. Wählen Sie nun das Jena-Package aus und bestätigen Sie mir "ok".
Abbildung 24 - Aktualisierung der Jena-Dependency (3)
11. Wiederholen Sie diese Schritte mit den anderen drei Teilprojekten
ORDVEditor.diagram, ORDVEditor.edit und ORDVEditor.editor.
Abbildung 25 - Updaten der anderen Dependencies analog
28
12. Klicken Sie nun rechts auf das Teilprojekt ORDVEditor und wählen Sie "run
as" "Eclipse Application". Daraufhin sollte sich ein neues Eclipse-Fenster
öffnen.
Abbildung 26 - ORDVEditor als Eclipse Application starten
13. In dieser neuen Instanz von Eclipse erstellen Sie nun eine neue Java-
Applikation.
Abbildung 27 - Neues Java-Projekt anlegen
29
14. Auf dieses frisch erstelle Projekte klicken Sie wiederum rechts und
selektieren "run as" "Example".
Abbildung 28 - ORDVEditor als Example ausführen
15. Im erscheinenden Fenster wählen Sie ORDV-editor Diagram und
bestätigen mit "Next".
Abbildung 29 - Neues ORDV-Diagramm erstellen
30
16. Spezifizieren Sie das Stammverzeichnis des Projekts,...
Abbildung 30 - Pfad auswählen
17. ... wählen Sie eine ungelernte ...
Abbildung 31 - Auswählen einer ungelernten Ontologie
18. ... sowie eine gelernte Ontologie und bestätigen Sie mit "ok".
Abbildung 32 - Auswahl einer gelernten Ontologie
31
Abbildung 33 - Bestätigen
19. Daraufhin werden drei Tabs geöffnet, die jeweils die gelernte, ungelernte
sowie die Unterschiede zwischen den Ontologien darstellen. Aufgrund der
Zeichenroutinen in GMF werden alle Elemente jedoch übereinander
gezeichnet und müssen manuell platziert werden.
Abbildung 34 - Übereinander gezeichnete Elemente der Ontologien
32
20. Angeordnete Ansicht der ungelernten ...
Abbildung 35 - Angeordnete ungelernte Ontologie
21. ... gelernten sowie....
Abbildung 36 - Gelernte Ontologie
33
22. ... die Unterschiede der Ontologien
Abbildung 37 - Unterschiede der Ontologien
Abbildung 38 - Überschneidungsfreie Darstellung der Ontologie-Unterschiede