Praktikum zu mo dellgetriebener
Softwareentwick lung
Thema 3:
Ontology Reasoning Differences Viewer
Ausarbeitung von
Gorana Bralo, Domini k Bösl, Chr is Kämp fe
Somme rsemester 2008
Universi tät Augsburg
Lehrstuh l Programm ierung ver tei lter Systeme
Betreuer: Wolf Fischer
InhaltInhal t......................................................................................................................3
1.Einlei tung ........................................................................................................... 4
2.Theoretische Grundlagen ................................................................................. 5
a.Ontolog ien ...................................................................................................... 5
b.OWL ................................................................................................................. 7
c.EMF, GEF & GMF ............................................................................................. 9
d.Protégé .......................................................................................................... 12
e.Jena ................................................................................................................ 13
f.Metamodell .................................................................................................... 13
3.Konzept für Editor zum Anzeigen von Unterschieden zw ischen gelernten
und ungelernten Ontolog ien ............................................................................ 15
1. EinleitungDas Internet der heutigen Zeit bietet eine Flut an Infor mationen, die auf
al le Fragen Antworten zu geben scheint. Theoret isch steht jedem
Menschen, soziale und kul turelle Barrieren einmal außer Ach t gelassen,
beliebiges Wissen auf Abruf zur Verfügung. Der vermeintliche Segen
dieser Daten flut hat jedoch in den let zten Jahren imm er mehr seine
Janusköpfigkeitoffenbartundistauf dem bes ten Weg, sich in einen Fluch
des Verloren-Gehens im Web zu entwickeln.
Auch allen Versuchen, das Internet du rch mehr Animation und
Benut zer(un )freundl ichkeit in seine Version 2.0, 3.0 oder beliebige wei tere
Revisionen zu transfor mieren helfen nich t, sich in der Masse an Webseiten
zurechtzufinden oder sie automatisier t inhal tlich erfassen, verarbeiten
oder auch nu r kategor isieren zu können. Diese mangelnde Mögl ichkeit
einer Semant isierung der Webinhal te wurde allerdings mi t tlerweile
erkann t und es wi rd von vielen Insti tutionen, Firmen und
Forschergrup pen versucht, den nich t interpretier ten Daten eine
Bedeutung zuzuo rdnen um das Ziel, ein lernendes oder gar wissendes
System, zu erreichen.
Im Lauf der Forschung, auf welche Ar t und Weise man es den
Rechnersysteme n ermögl ichen kann, Wissen zu speichern und
semant ische Beziehungen erfassen zu können, haben sich versch iedenste
Lösungsansätze herausgebi ldet. Einer davon ist das Modell der
Ontolog ien, die Beziehungen zw ischen „Ob jek ten“ beschreiben und deren
Relationen zueinander auf einer „Metaebene“ widerspiegeln. Durch die
Angabe von Beispielrelationen kann das System dann „lernen“ und
ähnl iche Beziehungen auf dieselbe Weise kategor isieren. Jedoch ist es für
den Menschen schwier ig bis schlich tweg un mögl ich, die Unterschiede
zw ischen einer zug run de liegenden aufwend igen Ontolog ie mi t sehr
vielen Elementen und der bereits gelernten ausfind ig machen zu können.
Daher soll im Verlauf dieses Praktikums eine Software erstel lt werden, die
es ermögl ich t, eine zuvor erstellte Ontolog ie und das zugehör ige, bereits
gelernte Pendant einzulesen, wechselweise anzuzeigen und die
entsprechenden Unterscheide graph isch hervorzuheben.
2. Theoretische GrundlagenUm jedoch das Konzept und die Vorgehensweise bei der Entwick lung des
Editors beschreiben zu können, müssen einige grundlegende Modelle,
Konstrukte sowie Frameworks erläu ter t werden.
a. OntologienEine Ontolog ie in der Infor matik stel lt eine formale Repräsentation einer
Menge von Konzepten innerhalb eines inhal tlichen Bereichs und deren
Beziehungen un tereinander dar. Sie dien t dem „Reasoning“ über die
Eigenschaften des jeweiligen Themengebietes sowie dessen Defini tion.
Ontolog ien komm en klassischerweise in der Künstlichen Intel ligenz, dem
Semant ic Web, Software Engineering, der Bioinformatik und als eine Form
der Wissensrepräsen tation zum Einsatz.
Im Gegensatz zu klassischen Datenbanken, die keine Infor mationen über
die Bedeutung der gespeicherten Daten haben, besitzen Ontolog ien 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änd ig aus dem Vorhandenen zu ergänzen.
Diese Rückschlüsse werden du rch log isches Folgern (Inferenz) abgeleitet.
Um über einen Grundstock an semantischem Wissen ver fügen zu können,
muss dieses zuerst vom Menschen in der Ontolog ie hinter leg t werden.
Danach kann die Ontolog ie aber du rch automatische Verfahren wei teres
Wissen akqu irieren sowie Zusammenhänge erkennen und erlernen. Somi t
lieg t nach dem Reasoning eine „(an)gelernte“ Ontolog ie vo r, die im
Unterschied zur Ausgangsontolog ie über wei tere Relationen ver füg t. Wird
zum Beispiel das Wissen „Ein Hund ist ein Tier “ und „Snoopy ist ein Hund“
hinter leg t, so kann automatisch der Zusammenhang „Snoopy ist ein Tier “
erkann t werden und „Snoopy“ würde als Antwort auf die Frage nach allen
Tieren in einer Datenbank zurückgeliefer t werden.
Ontolog ien bestehen aus folgenden Elemen ten:
! Klassen (engl. Concep ts) - Zusammenfassung gemeinsamer
Eigenschaften; manchmal auch als Klassen bezeichnet; Können in
Klassenst ruktur angeordnet werden
! Instanzen – Repräsentieren Objek te; stel len zur Verfügung
stehende Wissen dar
! Relationen – Beziehung, in der Klassen und Objek te zueinander
stehen; Bezeichnen „Eigenschaften“ der Objek te
! Vererbung – Relationen können vererbt werden;
Mehrfachvererbung theoret isch mö glich; Einsatz von Transi tivi tät
er laub t (auch Delega tion genannt)
! Ax iome – Aussagen innerhalb der Ontolog ie, deren Wahrheitswert
immer true ist; Dienen der Repräsentation von nich t ableitbarem
Wissen
Abbildung 1 - Beispiel einer Ontologie zur Kategorisierung von Wein
Ontolog ien lassen sich in zwei Typen eintei len. Die sogenannten
ligh tweigh t-Ontolog ien werden du rch Begri ffe, Taxonomien und
Beziehungen zw ischen Begriffen gebi ldet. Im Gegensatz dazu sind die
heavyweigh t-Ontolog ien Erweiterungen der leich tgewichtigen und
ergänzen diese du rch Ax iome und Einschränkungen, die die gewünschten
Aussagen innerhalb der Ontolog ien präzisieren.
b. OWLUm Ontolog ien beschreiben zu können bedien t man sich so genannter
knowledge representat ion languages. Eine wichtige Familie davon bi ldet
die Web Ontology Language (OWL) die sei t 2004 vom World Wide Web
Consortium (W3C) standardisier t ist. Dabei er laubt es OWL, folgende
Ontolog iebestand tei le zu beschreiben:
! classes, class hierarchies
! properties, property hierarchies
! domain and range restrictions
! 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-Sprachfami lie bes teht haup tsächl ich aus zwei größtentei ls
zueinander kompat iblen Semant iken, OWL DL und OWL Lite; zudem
ex istier t eine wen iger verbrei tete Variante, der OWL Full Dialek t. OWL Lite,
OWL DL und OWL Full un terscheiden sich wie folgt:
1 Prof. Dr. Dr. h.c. Manfred Broy, Modellbi ldung in der Entwick lung, Vorlesung SoSe 2007, TUM
OWL Lite OWL DL OWL FullClassificat ion hierarchy, simp le constraints
Features:! (sub)classes,
individuals! (sub)poperties,
do main, range! conjunction! ( in)equality! cardinality
constraints 0/1! datatypes ! inverse,
transitive, symmet ric proper ties
! someValuesForm! allValuesForm
Maximal expressiveness while maintaining trac tabi lity
Di rect correspondence wi th a Description Log ic
Features:! Negation! Disjunction! Full cardinality! Enumerated
types
Very high expressiveness by losing trac tabi lity
No res triction on use of vocabulary (as long as it comp lies RDF)
Features:! Meta-classes! Modi fying
language
Abbildung 2 - Überblick über die OWL-Sprachfamilie 2
Die Semant ik von OWL DL und OWL Lite basiert auf deskriptiver Log ik, die
über den Vortei l ver füg t, in ihrer Theor ie sehr gu t verstanden und
analysiert zu sein und sich du rch die Berechenbarkeit Ihrer Eigenschaften
auszeichnet. OWL Full hingegen verwendet ein neuartiges semantisches
Modell, das sehr stark in Anlehnung an das RDF Schema gehal ten ist um
an dieser Stelle größtmögl iche Kompat ibi lität zu ermögl ichen.
Dabei gelten folgende Zusammenhänge:
! Jede zulässige (legal ) OWL Lite Ontolog ie ist eine zulässige OWL
DL Ontolog ie.
! Jede zulässige OWL DL Ontolog ie ist eine zulässige OWL Full
Ontolog ie.
2 ibid
! Jede gü ltige (valid) OWL Lite Schlussfolgerung (conclusion ) ist eine
gü ltige OWL DL Schlussfolgerung.
! Jede gü ltige OWL DL Schlussfolgerung ist eine val ide OWL Full
Schlussfolgerung 3
Die OWL-Ontolog ien selbst werden in einer RDF/XML-ähnlichen Syntax
mo dellier t, was einen der Gründe für die fundamentale Bedeutung von
OWL für das Semant ic Web darstel lt. Die du rch eine OWL Ontolog ie
beschriebenen Daten werden als eine Menge an individuals und einer
Menge von property assertions interpretier t, die diese Instanzen
mi teinander verknüpfen. Die Ontolog ie an sich besteht aus einer Menge
von Ax iomen, die bestimm te Eigenschaften einer Menge von idividuals,
classes genannt, sowie deren Beziehung zueinander festlegen. Aus diesen
ax iomatischen Beziehungen ergeben sich auch die in der Ontolog ie
gespeicherten semantischen Infor mationen. Die Defini tion einer Relation
zw ischen zwei Instanzen zweier Klassen in OWL sieht exemplar isch so
aus:
Abbildung 3 - exemplarische OWL Beschreibung 4
c. EMF, GEF & GMFBei EMF, EGL und GMF handel t es sich um Frameworks, die den
Programm ierer bei der automatisier ten Erzeugung von Quelltext aus
st rukturier ten Modellen un terstützen wollen.
EMF steht dabei für Eclipse Modeling Framework und stel lt ein Open Source
Java Framework dar. Es ist in der Lage aus einem auf offenen Standards
basierenden Modell Java-Code zu erzeugen. Die Modell-Spezi fikation
3 Nach Wikipedia-Eint rag der engl ischen Wikipedia zum Begri ff „Web Ontolog ie Language“4 Aus Prof. Dr. Dr. h.c. Manfred Broy, Modellbi ldung in der Entwick lung, Vorlesung SoSe 2007, TUM
dafür wi rd in XMI erstel lt, das Modell an sich kann entweder aus
kommen tier tem Java Code oder einem oder mehreren XML Dokumenten
bes tehen sowie in einem Modellierwerkzeug wie etwa Rational Rose
erstel lt und dann in EMF imp ortier t werden. Das daraus resul tierende
Programm kann wiederum Instanzen dieses Modells abfragen,
ser ialisieren, manipu lieren, erstellen, val idieren und Änderungen
überwachen. Auch das automatisier te Erstellen von JUnit-Code zum
Testen des generier ten Codes ist mö gl ich. Vortei le des EMF sind dabei die
enge Integration in Eclipse mi t al len daraus resul tierenden Mehrwerten,
wie der er leichter ten Erstel lung von User Inter faces und der
Interoperabili tät mi t anderen Eclipse Projek ten wie etwa GMF.
GEF bezeichnet das Eclipse Graphical Editing Framework, welches es dem
Entwick ler ermögl ich t, graph ische Editoren mi t einer reichen Palette an
Funktionen aus seinen bereits vorhandenen Anwendungsmodellen zu
erstel len. Es setzt sich aus zwei Plugins zusammen, wobei das
org.ecl ipse.draw2D plug in ein Layout und Rendering Toolkit zum
Anzeigen von Graphiken anbietet. Dabei setzt GEF auf eine mo del-view-
control ler Architek tur.
Abbildung 4 - Ein mit GEF erstellter Editor zum Einfügen von Formen 5
5 GEF Tutorial, „A Shape Diagram Editor ”, http://www.ecl ipse.org/ar ticles/Ar ticle-GEF-diagram -editor/shape.ht ml
Das Ecipse Graphical Modeling Framework, auch GMF, setzt
schlussendl ich auf EMF und GEF auf und bietet eine generative
Komponente sowie eine Laufzeit Inf ras truktur, mi t deren Hi lfe die
Entwick lung von graph ischen Editoren vereinfacht wi rd. Folgende Grafik
verdeutlich t den Workflow bei der Erstellung eines GMF Projek tes.
Abbildung 5 - Workflow zur Erstellung eines GMF Projektes 6
Durch den Einsatz von GMF werden viele Arbeitsschr itte bei der Erstel lung
eines graph ischen Editors zusammengefass t oder automatisier t und die
Entwick lungszeit bzw. –Ko mp lexität für aufwend ige graph ische
Eingabetoo ls erhebl ich reduzier t.
6 GMF Tutorial auf Eclipse.org, http://wiki.eclipse.org/GMF_Tutorial
Abbildung 6 - Ein fertiger GMF-Editor zur Erstellung von Mindmaps 7
d. ProtégéDer Protégé-Ontolog ie Editor dient der einfachen graph ischen Erstellung
von Ontolog ien. Somi t müssen Ontolog ien nich t mehr aufwend ig rein
textuell „prog ramm ier t“ werden sondern können, ähnl ich einem UML-
Diagramm, gezeichnet werden. Um mi t Protégé auch OWL-konforme
Ontolog ien erstel len zu können, bietet der Editor die Mögl ichkeit, diese
Funktional ität du rch Plugins nachzurüsten. Dadurch ist es mö glich OWL
und RDF Ontolog ien zu laden und zu speichern, Klassen, Eigenschaften
sowie SWRL-Regeln anzuzeigen und zu verändern, log ische Klassen-
Charak ter istiken und OWL-Ausdrücke zu definieren, Reasoner
auszu füh ren und OWL-Individuals für den Einsatz im Semant ic Web zu
editieren.8
7 GMF Beispiel aus der GMF Gallerie auf Eclipse.org, http://www.ecl ipse.org/mo deling /gmf /gallery/mindmap.png8 Protégé-OWL Beschreibung auf http://protege.stanford.edu/overview/ protege-owl.html
e. JenaJena ist ein auf Java basierendes Framework zur Erstellung von Semant ic
Web Anwendungen. Hier für wi rd eine Programm ierumgebung
bereitgestellt um auf RDF oder OWL zug reifen zu können.
Aufgrund einer Vielzahl von Java Inter faces und entsp rechenden
Imp lementat ionen ist es mö gl ich RDF Ressourcen zu repräsen tieren.
Somi t können Graphen oder Modelle erstellt und manipu lier t werden.
Ein wei terer Mechanismus von Jena ist das Einlesen und Ausgeben von
RDF Struk turen, welcher ein wich tiger Tei l des Praktikums darstellen wi rd.
f. MetamodellBei der mo dellgetriebenen Softwareentwick lung spielen formale Modelle
eine große Bedeutung. Dabei geht es um Modelle, die die Funktional ität
der zu entwickelnden Software widerspiegeln und zwar auf einem
höheren Abstraktionsniveau, absolut Plattform unabhängig und
Programm iersprachen unabhängig. Je näher so ein Modell an dem
Problemraum definier t ist und je ausdruckss tärker seine Elemente sind,
des to geringer gestaltet sich später der Aufwand bei der Entwick lung der
Software. Ist das Modell selbst mi t ausreichend Semant ik angereicher t, so
können z.B. Temp lates definier t werden, die eine automatische
Codegenerierung di rekt aus dem Modell heraus ermögl ichen. Um solche
formalen Modelle überhaup t definieren zu können bedarf es einer
Modellierungssprache, der so genannten DSL (Do main Specific
Langauge). Es gibt zwei Mögl ichkeiten eine Modellierungssprache zu
wäh len: Entweder du rch Erweiterung von UML du rch Profile oder du rch
Defini tion einer von Grund auf neuen Sprache, die speziel l auf den
vorliegenden Problemraum zugeschnitten ist. Im Rahmen dieses Projek tes
werden wi r auf die erste Mögl ichkeit zurückgreifen und UML für unsere
Bedür fnisse passend erwei tern. Die Erweiterung einer schon vorhandenen
Sprache sowie die Defini tion einer absolut neuen Sprache erfolgt anhand
so genannter Metamodel le. Die griechische Vorbsilbe „meta“ bedeutet so
viel wie „über“. Metamodel le sind also Modelle, die etwas über die
Modellierung aussagen. Ein Metamodel l definier t in abstrakter Weise die
Modelleleme nte bzw. Konst rukte, die verwendet werden können, um ein
Modell zu erstel len. Ein Modell ist dami t als eine Instanz eines
Metamodel ls zu sehen. Für das zug runde liegende Projek t sieht das
Metamodel l wie folgt aus:
Abbildung 7 - Metamodell (Erweiterung des UML Metamodells)
Das Metamodell bes teht in diesem Fall aus einer Klasse und einer
Proper ty. Anhand der Elemente dieses einfachen Metamodel ls ist man in
der Lage komp lexere Modelle zu erstel len. Die erstel lten Modelle werden
im Kon text dieses Projek tes schließl ich als Ontolog ien bezeichnet, die im
Editor graph isch angezeigt werden und deren Unterschiede ebenfal ls
graph isch hervorgehoben werden sollen. In Abbi ldung 8 ist ein Modell
dargestellt welches diesem Projek t als Ausgangson tolog ie dien t. Es
ex istieren mehrere Klassen, z.B. Person, Street, House, usw., die
mi teinander in Beziehung stehen, z.B. knows, isMarried To. Die
Beziehungen stel len dabei Instanzen der Metaklasse Proper ty dar und die
Klassen Instanzen der Metak lasse Class (siehe Abbi ldung 7). Aus diesem
Modell können nun beliebig viele wei tere Instanzen erstellt und in
Beziehung mi teinander gebracht werden, z.B. könnte „Ang ie“ der Name
einer Instanz der Klasse Person sein und in der isMarried To-Relation mi t
einer wei teren Instanz der Klasse Person stehen usw.. Aufgrun d der
Beziehungen, die zw ischen solchen Instanzen bestehen, lässt sich
schließl ich neues Wissen gewinnen welches dann im Editor graph isch
angezeigt werden kann.
Im nächsten Abschn itt wi rd näher auf das Konzept eingegangen.
Abbildung 8 - Modell
3. Konzept für Editor zum Anzeigen von Unterschieden zwischen gelernten und ungelernten Ontologien
Ein nu r schwer zu überbl ickendes Problem zwischen einer ungelernten
und gelernten Ontolog ie ist, zu erkennen was die gelernte Ontolog ie
let ztendl ich gelernt hat.
Aufgabe für das Praktikum soll sein, einen Editor zu entwerfen, welcher
die Unterschiede zw ischen den Ontolog ien graph isch hervorhebt und
darstellt. Somi t kann überprüft werden, ob die gelernte Ontolog ie auch
nich ts „Falsches“ gelernt hat.
Im folgenden Abschn itt wi rd bi ldhaf t dargestellt, wie der Aufbau des
Konzeptes gedacht ist.
Die Abbi ldung 9 zeigt eine ungelernte Ontolog ie. In dieser ist zu
erkennen, welche Beziehungen zw ischen Personen bes tehen, z.B. wer mi t
wem verheiratet ist oder wer die Kinder des Ehepaares sind.
Abbildung 9 - Eine ungelernte Ontologie
In Abbi ldung 10 wi rd die gleiche Ontolog ie dargestellt, nu r das sie bereits
Wissen akqu irier t hat.
In der linken oberen Hälfte des Bildes befinden sich wieder die
Beziehungen der Personen aus der vorangegangenen Abbi ldung 9.
Hinzu komm t, dass die Ontolog ie aufgrund der Beziehungen der
einzelnen Personen zueinander, gelernt hat, welche Person eine andere
Person kenn t. Anhand dieser Abbi ldung lässt sich schon erkennen, dass
der Überbl ick recht schnell ver loren geht, welches Wissen neu
hinzugekommen ist.
Abbildung 10 - Eine ungelernte Ontologie
Der zu entwickelnde Editor soll die Unterschiede der zwei Ontolog ien
herausfinden und diese graph isch darstel len (vgl. Abbi ldung 11).
In der Abbi ldung werden nu r noch die Beziehungen dargestellt, wo eine
Person die andere kenn t. Also das gelernte Wissen und somi t die
Unterschiede der Ontolog ien.
Abbildung 11 - Eine ungelernte Ontologie
Die grundlegende Idee des Editors ist somi t das Einlesen von zwei
Ontolog ien, welche ebenfal ls ü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 Manipu lat ionen an den Daten vornehmen zu
können.