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.