Ontology Reasoning Differences Viewer

Transkript

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 1

2 Inhalt Inhalt Einleitung Theoretische Grundlagen... 3 a. Ontologien... 4 b. OWL... 5 c. EMF, GEF & GMF... 7 d. Protégé e. Jena f. Metamodell Konzept für Editor zum Anzeigen von Unterschieden zwischen gelernten und ungelernten Ontologien Überarbeitung des Metamodells anhand der Praxis Das Jena-Framework Konzept zur Erstellung des ORDVEditors How-To zur Installation und Verwendung des Editors

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. 3

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) 4

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 5

6 logical expressions (and, or, not) (in)equality local properties required/optional properties required values of properties enumerated classes transitivity, symmetry, inverse of relations 1 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, Maximal expressiveness Very high expressiveness simple constraints while maintaining by losing tractability Features: tractability No restriction on use of (sub)classes, Direct correspondence vocabulary (as long as it individuals with a Description Logic complies RDF) (sub)poperties, domain, range Features: Features: conjunction Negation Meta-classes (in)equality Disjunction Modifying cardinality Full cardinality language constraints 0/1 Enumerated types datatypes inverse, transitive, symmetric properties somevaluesform allvaluesform 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 TUM 2 Prof. Dr. Dr. h.c. Manfred Broy, Modellbildung in der Entwicklung, Vorlesung SoSe 2007, ibid 6

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 7

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, 8

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, 6 GMF Beispiel aus der GMF Gallerie auf Eclipse.org, 9

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 10

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. 11

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. 12

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. 13

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: 14

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 15

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 16

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 17

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. 18

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. 19

20 Abbildung 14: Beispiel ORDVEditor 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. 20

21 1) CreateElementRequest cer = new CreateElementRequest(editDomain, 2) (EObject)diagrammeditpart.getModel(), elementtype, 3) ORDVEditorPackage.Literals.ELEMENT_DIAGRAM CONTAIN S);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. 21

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 22

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 23

24 Abbildung 18 - Importieren der Teilprojekte (1) 5. Wählen Sie "General"- "Existing Project into Workspace" aus Abbildung 19 - Importieren der Teilprojekte (2) 24

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) 25

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) 26

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 27

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 28

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 29

30 16. Spezifizieren Sie das Stammverzeichnis des Projekts,... Abbildung 30 - Pfad auswählen wählen Sie eine ungelernte... Abbildung 31 - Auswählen einer ungelernten Ontologie sowie eine gelernte Ontologie und bestätigen Sie mit "ok". Abbildung 32 - Auswahl einer gelernten Ontologie 30

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 31

32 20. Angeordnete Ansicht der ungelernten... Abbildung 35 - Angeordnete ungelernte Ontologie gelernten sowie... Abbildung 36 - Gelernte Ontologie 32

33 die Unterschiede der Ontologien Abbildung 37 - Unterschiede der Ontologien Abbildung 38 - Überschneidungsfreie Darstellung der Ontologie-Unterschiede 33