Humboldt Universität zu Berlin

Mathematisch-Naturwissenschaftliche Fakultät II

Institut für Informatik

Lehrstuhl für Datenbanken und Informationssysteme

Diplomarbeit

Implementierung eines Prototyps für einontologie-basiertes

Anfragebearbeitungssystem

Björn Bösenberg

7. November 2005

Betreuer:

Dipl. Inf. Chokri Ben Necib

Inhaltsverzeichnis

1 Einleitung....................................................................................................51.1 Anfrageumformung..............................................................................6

2 Ontologien................................................................................................ 102.1 Beschreibung von Ontologien............................................................102.2 Ontologie-Modell...............................................................................112.3 Inferieren von neuem Wissen.............................................................112.4 Formalismen zur wissensbasierten Modellierung..............................122.5 Kategorisierung von Ontologien........................................................ 15

3 Ontologie-Sprachen................................................................................. 203.1 Historische Entwicklung von Ontologie-Sprachen............................ 213.2 RDF / RDF(S) ................................................................................... 22

3.2.1 Das RDF(S)-Modell................................................................... 223.2.2 RDF(S)-Konzepte.......................................................................233.2.3 RDF(S)-XML-Syntax................................................................24

3.3 OWL...................................................................................................263.3.1 Untersprachen ............................................................................263.3.2 OWL-Konzepte.......................................................................... 273.3.3 OWL-XML-Syntax.................................................................... 28

3.4 Abschlussbetrachtung zu Ontologie-Sprachen.................................. 294 Ontologie-Werkzeuge.............................................................................. 30

4.1 Anforderungen an Ontologie-Werkzeuge ......................................... 304.2 Jena.....................................................................................................314.3 SESAME ...........................................................................................334.4 Integrated Ontology Development Toolkit (IODT)........................... 354.5 Übersicht Ontologiewerkzeuge.......................................................... 36

5 Mapping zwischen Datenbank und Ontologie...................................... 385.1 Bereits existierende Ansätze.............................................................. 395.2 Mapping auf Schemaebene................................................................ 40

5.2.1 Korrespondenzen zwischen Relationennamen und Konzepten..415.2.2 Korrespondenzen zwischen Relationennamen und Beziehungenzwischen Konzepten............................................................................425.2.3 Korrespondenzen zwischen Attributnamen und Beziehungenzwischen Konzepten............................................................................435.2.4 Korrespondenzen zwischen Attributnamen und Eigenschaftenvon Konzepten.....................................................................................43

5.3 Mapping-Ansätze auf Instanzebene................................................... 445.3.1 Korrespondenzen zwischen Extensionsbereichen undBeziehungen zwischen Konzepten...................................................... 455.3.2 Korrespondenzen zwischen Datenbankinstanzen und Konzepten.475.3.3 Korrespondenzen zwischen Datenbankinstanz und Ontologie-Instanz................................................................................................. 48

2

5.4 Zugriffsfunktionen auf das Mapping..................................................485.5 Beziehungskardinalitäten................................................................... 515.6 Anwendung des Mapping auf die Transformationsregeln................. 525.7 Zusammenfassung..............................................................................55

6 Semiautomatische Verfahren zum Erstellen eines Mapping............... 566.1 Beschreibung verschiedener Mapping-Verfahren..............................56

6.1.1 Nutzen von Instanz- oder Schemainformationen....................... 576.1.2 Mapping von einzelnen Elementen oder zusammengesetztenStrukturen ........................................................................................... 586.1.3 Verwendung von Elementbezeichnern oder von Abhängigkeiten.596.1.4 Mapping unterschiedlicher Kardinalität zwischen Elementen... 606.1.5 Nutzung von Zusatzinformationen.............................................61

6.2 Algorithmische Methoden für die Erstellung von Mapping-Strukturen..................................................................................................................61

6.2.1 Unterscheidung von abhängigen und zusammengesetztenRelationen............................................................................................616.2.2 Mapping-Erstellung für Relationennamen und Konzepte..........626.2.3 Mapping-Erstellung für Relationennamen und Beziehungenzwischen Konzepten............................................................................636.2.4 Mapping-Erstellung für Attributnamen und Beziehungenzwischen Konzepten............................................................................646.2.5 Mapping-Erstellung für Attributnamen und Eigenschaften vonKonzepten............................................................................................666.2.6 Mapping für Extensionsbereich und Beziehungen zwischenKonzepten............................................................................................67

6.3 Zusammenfassung der semiautomatischen Mapping-Erstellung....... 687 Konzeptionelle Umsetzung der Anfragetransformation...................... 70

7.1 Erweiterungsverfahren von Transformationsregeln...........................707.2 Inferenzmechanismen........................................................................ 727.3 Umsetzung der Transformationsregeln.............................................. 77

7.3.1 Vocabulary-Regel.......................................................................787.3.2 Part-Whole-Regel.......................................................................79

7.3.2.1 Relevante Korrespondenzen............................................... 827.3.2.2 Konzeptionelle Umsetzung der Part-Whole-Transformation.83

7.3.3 Feature-Regel............................................................................. 867.3.4 Support-Regel.............................................................................897.3.5 Sensitivity-Regel........................................................................ 91

7.4 Zusammenfassung..............................................................................938 Architektur, Implementierung und Tests des ODBT-Prototypen...... 94

8.1 Systemanalyse.................................................................................... 948.2 System-Entwurf..................................................................................96

8.2.1 ODBT-Prototyp Schnittstelle..................................................... 96

3

8.2.2 Umformungsprozessor............................................................... 978.2.3 Mapping-Verarbeitung............................................................... 998.2.4 Ontologie-Werkzeuge und Inferenzregeln............................... 100

8.3 Benutzung der Beispiel-Datenbanken .............................................1028.4 Durchgeführte Tests auf WordNet und GNIS..................................104

Zusammenfassung.................................................................................... 107A.1 Beispiel-Ontologie-Graphen............................................................. 109A.2 Anfrage-Datenbanken....................................................................... 112A.3 XML-Mapping-Struktur...................................................................116A.4 UML-Klassen-Diagramme der Implementierung...........................125A.5 Testreihen zum Performanzvergleich von Sesame und Jena.........131Literaturverzeichnis................................................................................. 134

4

Kapitel 1

Einleitung

Die Themenstellung der vorliegenden Arbeit entstand aus den am Lehrstuhl fürDatenbanken und Informationssysteme entwickelten Methoden zur ontologie-basierten Transformation von Datenbankanfragen [28-31]. Die dort beschriebenenAnsätze überführen eine Datenbankanfrage mit Hilfe der semantischenAusdruckskraft einer Ontologie in eine erweiterte Anfrage. Diese erweiterteAnfrage soll nach der Überführung möglichst relevantere Anfrageergebnisse, alsdie ursprüngliche Anfrage, zurückliefern. Aufbauend auf diesem Ansatz wurde einPrototyp entwickelt, in dem die dort beschriebenen Verfahren und Konzeptegrößtenteils umgesetzt sind.

Ontologien repräsentieren in der Informatik semantisches Wissen. Sie werden inKapitel 2 unter verschiedenen Gesichtspunkten betrachtet. Es wird ein Ontologie-Modell definiert, das von Regeln zur Umformung von Datenbankanfragenverwendet werden kann. Im direkten Zusammenhang mit Ontologien wird derBegriff Inferenzbildung beschrieben, der die logische Schlussfolgerung neuenWissens ausdrückt. Außerdem findet eine Kategorisierung von unterschiedlichenOntologien statt, um deren Verwendbarkeit innerhalb des Prototypen zubestimmen.

In Kapitel 3 werden verschiedene Ontologie-Sprachen dahingehend untersucht, obsie den Anforderungen bezüglich der Abbildung des Ontologie-Modells für dieAnfrageumformung gerecht werden. Ein kleiner Exkurs ist ein Überblick derhistorischen Entwicklung von Ontologie-Sprachen. Es werden dann dieOntologie-Sprachen RDF(S) und OWL untersucht und diskutiert inwieweit siesich für die Umsetzung des Prototypen eignet..

Für die Speicherung, den Zugriff und die Inferenzbildung von Ontologien werdenin dem Prototyp Werkzeuge eingebunden, die einen Großteil dieser gefordertenFunktionalität für die Verwendung von Ontologien umsetzen. Der Prototypintegriert zwei verschiedene Ontologie-Werkzeuge (Sesame und Jena), die inKapitel 4 analysiert werden.

5

Kapitel 5 und 6 beschäftigen sich mit Mapping-Verfahren zwischen Ontologieund Datenbank. Hier wird, aufbauend auf bereits existierenden Ansätzen, eineeigene Mapping-Beschreibung geliefert, die es gestattet, ein Mapping zwischenKonzepten der Ontologie und dem Extensionsbereich in der Datenbank zuerstellen. Darauf aufbauend werden semiautomatische Verfahren entwickelt, umdieses Mapping zu generieren.

In Kapitel 7 werden die grundlegenden konzeptionellen Umsetzungen für dieDatenbanktransformation erarbeitet, auf der die Architektur und Implementierungdes Prototypen aufbaut. Damit die von einer Regel benötigten Zugriffe auf eineOntologie direkt ausgeführt werden können, wird ein eigenes Inferenz-Regelwerkgebildet. Die Regeln zur Umsetzung der Anfragetransformation werden dannjeweils einzeln behandelt und Algorithmen für die Erstellung transformierterDatenbankanfragen gegeben.

Kapitel 8 setzt die in Kapitel 7 erstellten Konzepte in eine Architektur um, die mitHilfe der verwendeten Ontologie-Werkzeuge den Prototypen für die ontologie-basierte Transformation von Datenbankanfragen bildet. Außerdem wird aufspezifische Implementationsaspekte, wie die Realisierung der Speicherung vonOntologien, eingegangen. Zum Schluss werden noch Tests, die auf demlauffähigen System durchgeführt werden, beschrieben und analysiert.

1.1 Anfrageumformung

Die von einem Benutzer an ein Datenbanksystem gestellte Datenbankanfrageliefert häufig ein für ihn nur unbefriedigendes Anfrageergebnis. Dies ist im Sinneder vorliegenden Arbeit unbefriedigend, da sich die Ergebnismenge nicht mit demdeckt, was der Benutzer, würde er den Inhalt der Datenbank kennen, gerne alsErgebnis bekäme. Einerseits bedeutet das, dass das Anfrageergebnismöglicherweise einige Einträge aus der Datenbank enthält, die eigentlich nicht fürihn relevant sind, andererseits könnten einige Einträge, die der Benutzer gernebekommen hätte, nicht Teil des Anfrageergebnisses sein. Die Ursache dafürkönnte sein, dass der Benutzer ein nur unzureichendes Wissen über die inhaltlicheStruktur der Datenbank besitzt. Die Datenbank könnte sich aber auch in einemnicht konsistenten Zustand befinden, so dass es für den Benutzer nicht möglich ist,über Anfragen alle von ihm gewünschten Ergebnisse zu erhalten. Beispielsweisekönnten für Einträge in der Datenbank synonyme Begriffe wie z.B. „Orange“ und„Apfelsine“ vorhanden sein. Weiterhin ist es für den Benutzer in manchen Fällennicht möglich eine Anfrage so zu formulieren, dass sie die für ihn gewünschtenErgebnisse liefert. So ist z.B. die Anfrage nach einer „vegetarischen Pizza“ aufeine Datenbank in der aber nicht gespeichert ist, ob eine Pizza vegetarisch ist,schwer zu erstellen, da der Benutzer ja möglicherweise nicht die Namen allerPizzen, die vegetarisch sind (Magarita, Funghi usw.), kennt.

6

Die Frage nach dem, was die eigentliche Intuition des Benutzers hinter derAnfrage ist, kann nur über das Wissen des semantischen Informationsgehalts derAnfrage gedeutet werden. Ohne dieses Wissen werden Anfragen nur auf reinsyntaktischer Ebene bearbeitet. Ontologien gestatten es, in der Informatiksemantisches Wissen in einer für Maschinen benutzbaren Form zu speichern [8].Die Methoden, wie sie in [28-31] beschrieben werden, formen auf Grundlagedieser Eigenschaft von Ontologien Datenbankanfragen mit semantischem Wissenum. Es wird also ein Verfahren angewendet, dass eine bestehendeDatenbankanfrage Q in eine neue Datenbankanfrage Q' überführt.

Die transformierte Anfrage Q' sollte für den Benutzer „sinnvollere“,Anfrageergebnisse zurückliefern als die ursprüngliche Anfrage. Der Begriff„sinnvoll“ kann in zweierlei Hinsicht ausgedrückt werden. Zum einen sindAnfrageergebnisse dann „sinnvoller“, wenn sie zusätzliche Tupel liefern, die derIntention der Anfrage des Benutzers entsprechen. Zum anderen sindAnfrageergebnisse auch dann im Auge des Benutzers sinnvoller, wenn Tupel, dienicht der Intention des Benutzers entsprechen, wegfallen. Es findet also sowohleine Erweiterung als auch eine Reduktion von Anfrageergebnissen statt.

Abbildung 1.1 Erweiterung und Reduktion vonAnfrageergebnissen

Die in Abbildung 1.1 dargestellte gelbe Menge stellt alle in der Datenbankenthaltenen Tupel da. Die rot schraffierte Menge enthält die Tupel, die für denBenutzer als relevant angesehen werden und somit der Intention des Benutzersentsprechen. Die schwarz schraffierte Menge bildet die von der Anfragegefundenen Tupel ab. Bei einer Erweiterung der Anfrageergebnisse ist zuerkennen, wie sich die Menge der gefundenen Tupel vergrößert. Die Erweiterung

7

Erweiterung

Reduktion

Tupel in DB

relevanteTupel

gefundeneTupel

sollte möglichst auf dem Bereich der für den Benutzer relevanten Tupel sein. Ausder Abbildung geht hervor, dass zusätzlich solche Tupel hinzukommen können,die für den Benutzer keine Relevanz haben. Bei einer Reduktion wird die Mengeder gefundenen Tupel verkleinert. Dies sollte möglichst auf dem Bereich derbisher gefundenen, nicht relevanten Tupel stattfinden. Es ist aber nichtauszuschließen, dass die Reduktion zu restriktiv ist und einige relevante Tupelwegfallen.

Die äußere Struktur der Anfragetransformation für Datenbankanfragen wird inAbbildung 1.2 illustriert. Der implementierte Prototyp für die ontologie-basierteTransformation von Datenbankanfragen wird als ODBT1-Prototyp bezeichnet. Indieser Darstellung ist zu erkennen, dass für die Anfrageumformung zweiKomponenten angesprochen werden. Zum einen ist dies die Ontologie, die wieschon erwähnt, das benötigte semantische Wissen enthält. Zum anderen ist diesein Mapping, das Referenzen zwischen Bestandteilen der Datenbank und derOntologie bildet. Durch die gestrichelten Linien wird angedeutet, dass diesesMapping zunächst nicht existiert, sondern jeweils zwischen unterschiedlichenDatenbanken und Ontologien gebildet werden muss.

Abbildung 1.2 Struktur der Anfrageverarbeitung

Für die Umformung der Datenbankanfrage werden in [28,30,31] mehrereUmformungsregeln entwickelt. Diese Umformungsregeln benutzen diesemantische Ausdruckskraft der Ontologie, um eine transformierte Anfrage zugenerieren.

Die konzeptuelle Erarbeitung der Umsetzung und die Implementierung dieserRegeln in einen Prototypen ist Ziel der vorliegenden Arbeit. Hierzu werden in denfolgenden Kapiteln zunächst die benötigten Grundlagen erarbeitet, indemOntologie-Sprachen, Ontologie-Werkzeuge und mögliche Mapping-Verfahren

1 engl. Ontology to DataBase query Transformation

8

ODBT-Prototyp

DBMS

OntologieQ

Q'

Mapping

untersucht werden. Später werden dann die entwickelten Verfahren zurUmsetzung der Anfragetransformation und die darauf aufbauende Architekturerläutert. Zunächst soll aber in einem eigenen Abschnitt der Begriff „Ontologien“genauer erklärt werden. Außerdem wird untersucht, welche Rolle Ontologien inder Informatik einnehmen.

9

Kapitel 2

Ontologien

Ontologien werden in der vorliegenden Arbeit benutzt, um das semantischeWissen, dass für die sinnvolle Transformation von Datenbankanfragen notwendigist, zu modellieren. Hierzu ist es zunächst nötig, den Begriff „Ontologie“ zuerläutern und ein eindeutiges Datenmodell für die Darstellung von Ontologien zugeben. Im weiteren soll auf den Begriff der Inferenz, der im Zusammenhang mitOntologien eine kausale Einheit bildet, eingegangen werden. Die Kausalitätzwischen Ontologie und Inferenz stützt sich auf Formalismen zurwissensbasierten Modellierung, von denen die gängigsten grob umrissen werdensollen. Schließlich werden in diesem Kapitel bestehende Ontologien konzeptionellin verschiedene Gruppen kategorisiert.

2.1 Beschreibung von Ontologien

Das Wort Ontologie ist griechisch und hat seinen Ursprung in der Philosophie. Eswird dort als „die Lehre des Seienden“ gebraucht. Im Bereich der Informatik wirddieser Begriff als eine konzeptionelle Formalisierung verschiedenerWissensräume betrachtet. Somit drückt eine Ontologie die Darstellung einesformalisierten Modells der Welt oder eines Teilbereichs der Welt aus.Teilbereiche dieses Weltbildes werden von Experten einer bestimmten Domänebestimmt und definiert [8, 18].

Eine sehr gängige und häufig zitierte Definition für Ontologien ist die von TomGruber:

„An ontology is an explicit specification of a conceptualization“ [10].

Mit der Konzeptualisierung ist ein abstraktes Modell, das einen bestimmtenAspekt der realen Welt wiedergibt, gemeint. Der Terminus einer explizitenSpezifizierung bedeutet, dass das Modell auf einer eindeutigen Sprache, die eine

10

maschinelle Verarbeitung ermöglicht, basiert.

Ontologien sind in einer hierarchischen Struktur von relevanten Konzepten undUnterkonzepten organisiert. Diese Beziehung zwischen den Konzepten wirdzumeist als ISA-Beziehung definiert und bildet das Grundgerüst der Ontologie.Einzelne Konzepte können mit anderen Konzepten über Beziehungen verknüpftoder mit Attributen detailliert beschrieben werden. Einem Menschen erschließensich meist implizit die Zusammenhänge, die sich aus bestimmten Sachverhaltenergeben. In der Informatik wird jedoch ein formales bzw. explizites „Weltbild“benötigt, um solche Zusammenhänge verstehen zu können. Dabei bildet dieOntologie eine eindeutige Wissensstruktur ab. Mit Hilfe dieser klar definiertenStruktur lassen sich anhand von Regeln Zusammenhänge logisch schlussfolgernund Verknüpfungen implizit erkennen [18].

2.2 Ontologie-Modell

Das für die Transformationsregeln benutzte Datenmodell, wie es in [30] gegebenwird, soll hier kurz beschrieben werden. Die Ontologie wird als 3-Tupel O = {C,R, I} angegeben. Dabei ist C = {c1, ..., cn} eine Menge von Konzepten und R ={"ISA", "SynOf", "PartOf", "ISASpecific" ...} eine Menge von binärenBeziehungen zwischen Konzepten. Zusätzliche semantische Eigenschaften könnenmit I ausdrückt werden, das eine Menge von Axiomen in First Order Logic (FOL)2

darstellt. In R bildet die "ISA" Beziehung das Grundgerüst. Außer denvordefinierten Beziehungen "ISA", "SynOf", "PartOf" und "ISASpecific" könnennoch eine beliebige Anzahl von zusätzlichen domänenspezifischen Beziehungenangegeben werden.

In der Darstellung wird die Ontologie als einseitig gerichteter Graph G(V, E)betrachtet, wobei V eine endliche Menge von Knoten und E ein endliche Mengevon Kanten ist. In dieser graphischen Sicht werden die Konzepte C auf V und dieBeziehungen R auf E abgebildet.

Dieses Ontologie-Modell dient als Basis für die von dem ODBT-Prototypverwendeteten und in [28,30,31] definierten Transformationsregeln. Einegeeignete Darstellung in existierenden Ontologie-Sprachen dieses Modells wird inKapitel 3 untersucht.

2.3 Inferieren von neuem Wissen

Ein durch eine Ontologie erstelltes Wissensmodell erlaubt nicht nur eine2 Vgl. Kap. 2.3.4.

11

kontextbezogene Suche, sondern gestattet auch die Ableitung erweiterten Wissensdurch die Ausführung modellierter Regeln. „Dadurch wird implizites Wissentransparent und neues Wissen abgeleitet, also eine Inferenz gebildet“ [18]. DerBegriff Inferenz spiegelt die automatisierte, computergestützte Schlussfolgerungwider. Das Resultat ist somit ein aufbereitetes Wissen, welches durch logischeSchlussfolgerungen gewonnen werden kann.

Das Inferieren neuen Wissens aus einer gegebenen Ontologie ist Schwerpunkt undHauptanwendungsgebiet einer Vielzahl von Ontologie-Tools, wie sie in Kapitel 4beschrieben werden. Einem computerbasierten Inferenzmodell muss einemathematische, wohl definierte Syntax der Wissensmodellierung zu Grundeliegen. Für Ontologien wurden zu Beginn der 90er Jahre vor allem wissensbasierteModellierungsmethoden wie Frames und First-Order Logic aus dem Bereich derkünstlichen Intelligenz verwendet. In letzter Zeit kamen weitestgehendwissensbasierte Modellierungsmethoden, basierend auf Beschreibungslogiken(DLs3) zur Anwendung, welche Teilklassen der Prädikatenlogik sind [32]. WeitereMethoden zur Modellierung kommen aus der Softwareentwicklung, wie UML,oder aus dem Datenbankentwurf, wie das Entitäten/Relationen-Modell. DieseMethoden sind aber, verglichen in ihrer Ausdruckskraft, schwächer als die vorhererwähnten Methoden und werden hier nicht weiter untersucht4.

Alternativ zum Begriff Inferenz wird auch oft der Begriff Deduktion verwendet5.Hiermit sind Ableitungen in einem Logik-Kalkül gemeint, welche aber imVergleich zur Inferenz meist rein syntaktisch sind. Im Kontext von Ontologienwerden die beiden Begriffe Deduktion und Inferenz aber als synonymer Begriffbenutzt. Auch in der vorliegenden Arbeit sollen beide Begriffe in ihrersemantischen Aussagekraft als gleichwertig betrachtet werden.

Die Bildung der Inferenz dient aber nicht nur zum Ableiten von neuem Wissen.Durch sie wird eine Ontologie zusätzlich auf Konsistenz überprüft, d.h. es istmöglich, eine eindeutige Aussage über die Korrektheit eines durch die Ontologiegebildeten Modells zu geben.

2.4 Formalismen zur wissensbasierten Modellierung

Die Kausalität zwischen einer Ontologie und der Inferenzbildung erfordertFormalismen, für die ein exakt definiertes Logikkalkül existiert. DieseFormalismen bilden ein logisches Modell, auf das jede Ontologie-Sprache, wie siein Kapitel 3 untersucht werden, aufbaut. Daher soll ein kurzer Überblick über drei

3 Description Logics4 Für eine Untersuchung dieser Methoden zur wissensbasierten Modellierung siehe [20]5 Im englischen existiert neben „inference“ und „deduction“ auch noch der Begiff „reasoning“,

ein „reasoner“ implementiert die Verfahren für die Inferenzbildung

12

wichtige Formalismen gegeben werden.

Frame Logik (F-Logic)

Als erstes soll hier die Modellierung von Ontologien mit Hilfe von F-Logicuntersucht werden.

„F-Logic [...] combines the advantages of conceptual high-level approachestypical for frame-based languages and the expressiveness, the compact syntax,and the well defined sematics from logics.“ [34]

Der Formalismus unterscheidet in 5 verschiedenen Komponenten: Klassen,Relationen, Funktionen, formellen Axiomen und Instanzen [20]. Die nunfolgenden Beschreibungen sollen anhand eines einfachen Beispiels verdeutlichtwerden.

Klassen repräsentieren Konzepte in einem allgemeinen Verständnis. Es ist z.B.möglich eine Tiefkühlpizza als eine Klasse innerhalb der Nahrungsmittel-Domänezu betrachten. Klassen werden möglichst so klassifiziert, dassVererbungsstrukturen angewandt werden können. Tiefkühlpizza kann alsUnterklasse von Pizza und Pizza als Unterklasse von Nahrungsmittel aufgefasstwerden. Außerdem können für Klassen notwendige Bedingungen angegebenwerden, wie die Kardinalität eines Attributs der Klasse. Das Attribut Brennwertfür die Klasse Pizza könnte sinnvollerweise mit einer Kardinalität von 1 belegtwerden. Außerdem können notwendige Bedingungen festgelegt werden. Für eineTiefkühlpizza könnte eine Bedingung sein, dass zumindest ein Verfallsdatumangegeben sein muss, das vom Format Datum ist. In F-Logic ist es noch zusätzlichmöglich, Metaklassen zu definieren, wobei deren Instanzen wiederum Klassensind.

Relationen bringen verschiedene Konzepte einer Domäne in eine binäreBeziehung. So wird die Subklassen-Beziehung Subclass-Of zum Aufbau einerKlassenhierarchie verwendet. Es können auch Relationen höherenAbstraktionsgrades ausgedrückt werden, wie z.B., dass eine Pizza in einem Ofenerwärmt wird.

Eine weitere Komponente von F-Logic sind Funktionen. Der Verkaufspreis einerTiefkühlpizza kann durch den Preis plus Mehrwertsteuer in einer Funktionangegeben werden.

Formale Axiome werden dazu benutzt Sachverhalte anzugeben, die immer wahrsein müssen. Sie werden vor allem benutzt, um die Konsistenz der Ontologie zugewährleisten. So könnte beispielsweise ein Axiom sein, dass eine vegetarischePizza keine Zutaten, die aus Fleisch bestehen, enthält.

13

Als letztes können durch Instanzen Elemente in F-Logic gebildet werden. ZumBeispiel könnte eine bestimmte Pizza, die sich beispielsweise gerade im Ofenbefindet, als Instanz in F-Logic gebildet werden.

Beschreibungslogiken (DLs)

Der DL Formalismus wird in zwei Teile unterteilt. Zum einen die TBox, diegenerelle Konzepte und Eigenschaften beschreibt. Zum anderen die ABox, die dasWissen zu spezifischen Instanzen enthält. Der Formalismus baut darauf auf,Ontologien mit drei verschiedenen Basiskomponenten abzubilden.

Konzepte, die vergleichbar mit Konzepten in der Frame basierten Logik sind,stellen Klassen von Objekten da. Konzepte in DL werden als primitiv betrachtet,wenn nur notwendige Bedingungen als Einschränkungen für deren Individuenangegeben werden. Konzepte sind jedoch definiert, wenn zusätzlich ausreichendeEigenschaften angegeben werden.

Ähnlich der Relation in F-Logic beschreiben Rollen binäre Beziehungen zwischenKonzepten. Weitergehend erlauben sie aber in diesem Formalismus auch dieBeschreibung von Klasseneigenschaften. Eine höherwertige Arität als die Binäreist in einigen DL Sprachen erlaubt. Wie Konzepte können auch Rollen als primitivoder hergeleitet angegeben werden, wobei einige DL-Sprachen dieses aus Gründender eingeschränkten Inferenzeigenschaften nicht zulassen, da so keineVererbungshierarchien möglich sind. Zudem können Funktionen, die einen Wertzurückliefern, als spezielle Form von Rollen gebildet werden.

Die letzte Basiskomponente stellen Individuen dar, die Instanzen von Klassensind.

Die Modellierung von Konzepten und Rollen fällt in den Bereich der TBox, wobeidie semantische Ausdruckskraft durch eine Reihe von Konstrukten gebildet wird.Diese können je nach DL-Sprache die Konjunktion, Disjunktion, Negation,Werteinschränkungen, Schnittmenge oder andere Konstrukte sein [20]. Durchunterschiedliche Auswahl aus den verschiedenen Konstrukten werdenverschiedene DL-Sprachen gebildet, wobei diese dann eine unterschiedlicheAusdruckskraft in Bezug auf die Darstellungsmöglichkeiten und das Inferierenneuen Wissens haben.

Prädikatenlogik der ersten Stufe (FOL)

Wie bereits erwähnt, sind die Beschreibungslogiken Teilmenge derPrädikatenlogik erster Stufe. Im Vergleich zu DLs ist die prädikatenlogischeInferenzbildung aber nur semi-entscheidbar. Das bedeutet, dass ein Widerspruch

14

in endlicher Zeit gefunden werden kann. Lässt sich kein Widerspruch finden,geschieht dieses jedoch nicht in endlicher Zeit. Die FOL ist insgesamtaussagekräftiger als die DLs, eignet sich aber aus genau dem zuerst beschriebenenSachverhalt nicht besonders gut als formales Wissensmodell für Ontologien.

2.5 Kategorisierung von Ontologien

Einen umfassenden Überblick über die Menge der zur Zeit existierendenOntologien zu geben, gestaltet sich durch die Vielzahl der unterschiedlichenAnsätze als schwieriges Unterfangen. Es stehen aber sowohl Ontologie-Bibliotheken wie auch Ontologie-Suchmaschinen zur Verfügung, die einengewissen Überblick verschaffen. Eine Auflistung einiger im Internet verfügbarerOntologie-Bibliotheken zeigt Tabelle 1.1.

Ontologie-Bibliothek

Adresse Sprachen

DAML ontologylibrary

http://www.daml.org/ontologies DAML

Ontolingua ontologylibrary

http://ontolingua.stanford.edu Ontolingua

Protégé OWLlibrary

http://protege.stanford.edu/plugins/owl/owl-library/

OWL

SHOE ontologylibrary

http://www.cs.umd.edu/projects/plus/SHOE/onts/index.html

SHOE

WebOnto ontologylibrary

http://webonto.open.ac.uk RDF(S), OWL,DAML-OIL

(KA)2 ontologylibrary

http://ka2portal.aifb.uni-karlsruhe.de

KAON, OWL

Tabelle 1.1 Übersicht von Ontologie-Bibliotheken

Swoogle6 ist ein über das Internet benutzbares Tool, dass die Suche nachStichwörtern innerhalb existierender Ontologien ermöglicht. Problematischerscheint, dass hier auch Ontologien zu finden sind, die zuDemonstrationszwecken mit Fehlern versehen worden sind und somit keinesinnvolle Verwendung finden sollen.

Zur Verwendung von Ontologien für die ontologie-basierte Anfragetransformation

6 http://swoogle.umbc.edu/

15

erscheint es sinnvoll, die bestehenden Ontologien in unterschiedlicheTeilbereiche zu unterteilen. Einige Ansätze versuchen Ontologien in verschiedeneAnwendungsgebiete zu kategorisieren, andere Ansätze wiederum unterteilenOntologien in deren formale Ausdrucksmächtigkeit [20]. Hier soll kurz auf denersten Ansatz eingegangen werden und eine Auflistung der wichtigsten Ontologie-Kategorien gegeben werden. Für einige Kategorien werden zusätzlich Beispielevon real existierenden Ontologien vorgestellt. Für die unterschiedlichenOntologien soll weiterhin evaluiert werden, inwieweit sie sich für die Verwendungder Transformationsregeln auf eine existierende Datenbank eignen.

Wissensrepräsentierende Ontologien (KR7-Ontologien)

KR-Ontologien enthalten die Entwurfsprimitive zur Formalisierung von Wissen ineinem bestimmten wissensrepräsentierenden Ansatz. Sie geben die formalenDefinitionen um die Darstellungsprimitive (wie z.B. Klassen, Relationen, ...)auszudrücken. Kapitel 3 wird sich der verschiedenen Ontologie-Sprachenwidmen, wobei die Sprachprimitive durch eine jeweils eigenen KR-Ontologiebeschrieben wird. Die KR-Ontologie beschreibt die jeweilige Sprache mit Hilfeeiner Menge von Vereinbarungen, die die Semantik der Sprachprimitivebeschreiben und einschränken [20].

Ein kurzes Beispiel, dass hier gegeben werden soll, bezieht sich auf die OWL-DLKR-Ontologie. Die OWL-Ontologie-Sprache wird noch genauer in Kapitel 3beschrieben. DL ist die Bezeichnung für eine auf Description Logic basierendeUntersprache von OWL. Die OWL-DL-Sprache besteht aus 16 Klassen und 24Eigenschaften und ergeben somit insgesamt 40 Primitive. Diese Primitive werdendurch die KR-Ontologie von OWL-DL beschrieben und eingeschränkt.Beispielsweise wird die Eigenschaft "owl:minCardinality" in der KR-Ontologievon OWL-DL mit der Domäne "owl:Restriction" auf den Bereich"xsd:nonNegativeInteger" {0, ... ,ℕ} eingeschränkt.

KR-Ontologien sind für die Verwendung innerhalb des ODBT-Prototypen nichtgeeignet, da sie sich auf die Struktur der Ontologie-Sprachen beziehen, derenSyntax nicht in Datenbanken wiederzufinden ist.

Allgemeine Ontologien

Allgemeine Ontologien werden benutzt, um allgemein gültiges Wissen, das sichüber die Domäne von bestimmten Wissensbereichen erstreckt, abzubilden. DiesesWissen kann verschiedener Natur sein und sich z.B. auf Zeit, Raum, Kausalitätusw. beziehen. Eine für diese Arbeit relevante allgemeine Ontologie ist die OWL-Mereology, in der die PartOf-Beziehung innerhalb von OWL mit Hilfe der in

7 engl. Knowledge Representation

16

OWL vorhandenen Konzepte beschrieben wird.

Domänenspezifische Ontologien

Eine weitere Gruppe von Ontologien bildet domänenspezifisches Wissen ab. EineDomäne ist ein eingeschränkter Wissensraum, der für ein Teilgebiet der realenWelt gilt. Domänenspezifische Ontologien werden von Experten in einembestimmten Bereich entworfen und liefern ein möglichst genaues Abbild derzugrunde liegenden Domäne. Diese Domänen können sich z.B. im Bereich derMedizin, Biologie, Physik, Verkehrswesen, Bildung usw. befinden. Die Konzeptedomänenspezifischer Ontologien sind normalerweise Spezialisierungen vonübergeordneten Ontologien, wie sie im nächsten Abschnitt behandelt werden.

Exemplarisch soll hier die Gene Ontology (GO)8 für eine domänenspezifischeOntologie erwähnt werden. Ziel des Gene-Ontology-Projekt ist es, ein wohldefiniertes Vokabular zu erschaffen, dass auf alle Organismen angewandt werdenkann, auch wenn das Wissen über die Rolle von Genen und Proteinen in Zellenzunimmt und sich ändert. GO ist Teil der „Open Biomedical Ontologies“9, dieeine übergreifende Internetseite für verschiedene, wohl definierte biologische undmedizinische Ontologien ist. GO enthält zur Zeit Einträge über 9162 biologischeProzesse, 1424 zelluläre Bestandteile und 6936 molekulare Funktionen.

Domänenspezifische Ontologien sind gut geeignet für die ontologie-basierteDatenbanktransformation. In Bezug auf die vorliegende Arbeit hat es sich jedochals Schwierig herausgestellt frei verfügbare Datenbanken und passendeOntologien für einen bestimmten Domänenbereich zu finden.

Übergeordnete Ontologien

Diese Ontologien stellen allgemeine Konzepte zur Verfügung, auf die von anderenOntologien zurückgegriffen werden kann. Sie stellen somit die oberste Ebene derDarstellung eines durch verschiedene Ontologien modellierten Wissensraumesdar. So ist es möglich, dass domänenspezifische Ontologien mit einerübergeordneten Ontologie verbunden werden. Somit werden überflüssigeRedundanzen vermieden, da häufig gängige Konzepte nicht für jededomänenspezifische Ontologie neu gebildet werden müssen. Außerdem verschafftes durch die Verwendung gleicher Terminologien einen höheren Grad anKonsistenz beim Einbinden mehrerer domänenspezifischer Ontologien. DasErstellen von übergeordneten Ontologien ist ein schwieriger, vonunterschiedlichen philosophischen Standpunkten beeinflusster Prozess [8].

8 http://www.geneontology.org/9 http://obo.sourceforge.net/

17

Bekannte Vertreter übergeordneter Ontologien sind z.B. SUO10 und Cyc11. Diezugrunde liegende Motivation zur Erstellung von Cyc war, eine gemeinsameGrundlage von Wissen für wissensbasierte Systeme zu schaffen. Das Problem derIntegration verschiedener domänenspezifischer Wissensräume soll durchEinbinden dieser Wissensräume innerhalb einer allgemeinen Wissensbasisvereinfacht werden. Die zugrunde liegenden Konzepte sollen allgemeingültig sein,d.h. jede erdenkbare neue Ontologie sollte ohne Probleme mit Cyc verknüpftwerden können [20]. Cyc bildet zur Zeit 6000 grundlegende obere Konzepte derrealen Welt ab.

Die Verwendung von übergeordneten Ontologien bietet sich für den Gebrauchinnerhalb des ODBT-Prototypen an. Der Vorteil ist, dass sie sich gut auf eineVielzahl von Datenbanken anwenden lassen. Jedoch ist es nicht gelungen, eineübergeordnete Ontologie zu finden, die eine PartOf-Beziehung verwendet. Dieseswäre aber für den Nachweis der Funktionalität der Part-Whole-Regelwünschenswert.

Linguistische Ontologien

Große Gruppen von Ontologien beschäftigen sich mit der Erkennung vonnatürlicher Sprache. Diese helfen einerseits bei der eindeutigen Begriffsdefinition,andererseits helfen sie, die semantischen Kategorien, die für dasSprachverständnis notwendig sind, zu erkennen. Das Hauptmerkmal dieserlinguistischen Ontologien ist, dass sie an grammatikalische Strukturen gebundensind, die z.B. durch Substantive, Adjektive und Verben aufgebaut sind.

Beispiele für linguistische Ontologien sind WordNet12, EuroWordNet13, dasGeneralized Upper Modell (GUM)14, die Mikrokosmos Ontologie15 und die aufWordNet aufbauende Sensus16 Ontologie [8]. Unterschiede ergeben sich in derAbhängigkeit von einer bestimmten Sprache, auf der die Ontologien aufgebautsind. Während z.B. WordNet vollkommen anhand der englischen Spracheentwickelt wurde, ist GUM für unterschiedliche Sprachen benutzbar.EuroWordNet gliedert sich wiederum in einen sprachunabhängigen Teil und einensprachabhängigen Teil, der dann in der jeweiligen Sprache angelegt werden muss.

WordNet ist nach einem Wort-Sinn-Paradigma aufgebaut und unterscheidet nichtzwischen Wortformen. Eine Unterscheidung findet zwischen Nomen, Verben,Adjektiven und Adverbien statt, unter der Annahme, dass diese auch

10 http://suo.ieee.org/11 http://www.opencyc.org/12 http://wordnet.princeton.edu/13 http://www.hum.uva.nl/~ewn/14 http://www.hum.uva.nl/~ewn/gwa.htm15 http://crl.nmsu.edu/mikro16 http://mozart.isi.edu:8003/sensus2/

18

unterschiedlich im menschlichen Gehirn gespeichert werden. Hier spiegelt sichder psycholinguistische Ansatz wider, der dieser Ontologie in ihren Ursprüngen zuGrunde lag. Der Aufbau von WordNet ist dicht an dem in 2.2 gegebenenOntologie-Modell, da die Grundstruktur sich ebenfalls auf die Basisbeziehungen"PartOf", "SynOf" und "ISA" stützt. WordNet verwendet für diese Beziehungendie Begriffe „hypernymy“, „meronymy“ und „synonymy“.

Um den Umfang linguistischer Ontologien zu veranschaulichen, sollen hier einigestatistische Daten der derzeitigen Version von WordNet angeführt werden. ZurZeit befinden sich in WordNet 152059 Wörter, 115424 Synsets, die jeweils einlexikalisches Konzept repräsentieren, und 203145 Wort-Sinn-Paare der englischenSprache.17 Die Größe der komprimierten Datei der gesamten WordNet Ontologieumfasst ca. 12 Megabyte.

Linguistische Ontologien eignen sich nicht so gut zur Verwendung bei derontologie-basierten Anfrageumformung. Dies liegt daran, dass dieAusdrucksmächtigkeit dieser Ontologien zum Wortverständnis für diemaschinelle Übersetzung von Sprache, oder die automatische Spracherzeugungentwickelt wurde. Diese Ausdrucksmächtigkeit eignet sich aber nicht gut, da beiden Verfahren zur Anfrageumformung, die in [28-31] beschrieben werden, eherdie Beziehungen zwischen realen Objekten benutzt werden.

Trotzdem wurde die linguistische WordNet-Ontologie als real existierendeOntologie für spätere Tests ausgewählt. Der Grund dafür ist, dass in ihr,abgesehen von sprachlichen Komponenten, auch Beziehungen zwischen Wörterngebildet werden, wie die PartOf-, ISA- und SynOf-Beziehung. Es eignet sichaußerdem durch eine große Abdeckung von allgemein gebräuchlichen Begriffender natürlichen Sprache. Dadurch ist eine große Nähe der Konzepte in WordNetzu Begriffen, die von einem Benutzer in der Anfrage verwendet werden, gegeben.

17 http://wordnet.princeton.edu/man/wnstats.7WN, Stand vom 17.2.2005

19

Kapitel 3

Ontologie-Sprachen

Eine Ontologie muss, um auch verwendbar zu sein, in einer exakten Notationausgedrückt werden. Eine Ontologie-Sprache definiert die formale Sprache ausder die Ontologie gebildet wird.

Das in Kapitel 2 vorgestellte Datenmodell zur Darstellung von Ontologien istzunächst nur ein rein gedankliches Gebilde. Durch eine Ontologie-Sprache wirdaus diesem Gebilde eine formale Sprache. Für die ontologie-basierteTransformation von Anfragen ist es wichtig, das in 2.2 beschriebenegraphenbasierte Ontologie-Modell mit gleichwertigen Ausdrucksmitteln derSprache erfassen zu können. Hierzu gehört die Beschreibung von Konzepten undBeziehungen zwischen Konzepten. Zudem sollten die Basisbeziehungen "ISA","SynOf" und "PartOf" mit Modellierungsprimitiven der Sprache gebildet werdenkönnen. Eine wichtige Anforderung ist, dass die Sprache semantischeEigenschaften für diese Beziehungen besitzt und Inferenzregeln zur Erstellungerweiterten Wissens für die Beziehungen definiert.

Die Entwicklung von Ontologie-Sprachen ist ein noch längst nichtabgeschlossenes Forschungsgebiet in der Informatik. Waren Ontologie-Sprachenzunächst nur Forschungsgebiet im Bereich der künstlichen Intelligenz, so drängendiese nun auch in andere Gebiete der Informatik vor. Durch die relativ neueninternetbasierten Ontologie-Sprachen soll die Vision eines globalen, universellenMediums zur Wissensmodellierung realisiert werden. Die historische Entwicklungerscheint somit wichtig genug, dass ihr ein einleitendes Unterkapitel gewidmetwird. Die Entwicklung für Ontologie-Sprachen ist, auch bezüglich der zukünftigenVerwendbarkeit und Unterstützung von Ontologie-Werkzeugen, die in Kapitel 4beschrieben werden, entscheidend.

20

3.1 Historische Entwicklung von Ontologie-Sprachen

Es erscheint wenig sinnvoll, eine genaue Beschreibung einer Vielzahlverschiedener Ontologie-Sprachen in der vorliegenden Arbeit zu geben. Zumeinen würde dies den Rahmen sprengen, zum anderen ist es für viele Sprachenersichtlich, dass sie sich bezüglich einer oder mehrerer Anforderungen nichteignen und somit für die Verwendung ausscheiden. Trotzdem sollen diewichtigsten Ontologie-Sprachen in ihrem historischen Zusammenhang erwähnt,und eine jeweils kurze Erläuterung in Bezug auf die Eignung für die ontologie-basierte Anfragetransformation gegeben werden. Für einen ausführlichenVergleich zwischen den gängigsten Ontologie-Sprachen siehe [20,35].

Die ersten ontologie-basierten Sprachen entstanden Anfang der 90er Jahre. Unteranderem zählen zu diesen Sprachen CycL, Ontolingua und FLogic. CycL ist dieerste Ontologie-Sprache, die auf Frames aufbaut. Ontolingua ist eine derausdrucksstärksten Ontologie-Sprachen und baut auf KIF, das ein Format zurWissensvermittlung darstellt, auf. Die Sprache besitzt eine SCHEME18-ähnlicheSyntax in Postfixnotation. FLogic ist eine Sprache, die, wie es der Name schonvermuten lässt, auf F-Logic aufbaut und vorwiegend in Zusammenhang mit derErstellung deduktiver und objektorientierter Datenbanken verwendet wurde. DieFLogic-Sprache kombiniert objektorientierte mit frame-basierten Konzepten. InBezug auf die Zukunftsfähigkeit und Interkompatibilität erscheinen dieseSprachen aber den neueren internetbasierten Ontologie-Sprachen unterlegen.Obwohl die Erstellung von Ontologien durch einige Ontologie-Werkzeugeunterstützt wird19, ist die Unterstützung der Inferenzbildung durch aktuelleOntologie-Werkzeuge nur eingeschränkt gegeben. D.h., nur ältere spezialisierteWerkzeuge führen die Inferenzbildungsmechanismen auf diesen Sprachen aus,und es finden keine Neuentwicklungen für diese Sprachen statt. Aufgrund der hieraufgeführten Gründe erscheint die Verwendung dieser Ontologie-Sprachen nichtsinnvoll und wird nicht weiter betrachtet.

Die erste internetbasierte Ontologie-Sprache SHOE wurde 1996 als eineWeiterentwicklung von HTML entwickelt. Ziel war es, semantisches Wissen fürdie maschinelle Verarbeitung innerhalb von Internetseiten zugänglich zu machenund damit eine aussagekräftige Verarbeitung für Suchmaschinen zu erreichen[20]. Durch speziell definierte Tags ist es möglich, die Ontologie-Definitionendirekt innerhalb von HTML einzubetten. Durch die Entwicklung der XML-Sprache und deren zunehmenden Verbreitung erscheint das Konzept jedoch wenigzukunftsträchtig.

18 http://www.gnu.org/software/mit-scheme/documentation/scheme.html19 OntoEdit, Protege-200 und WebODE unterstüten das erstellen von FLogic Ontologien

21

Als Basis für die neue Generation der internetbasierten Ontologie-Sprachen dientRDF, ein Datenmodell zur Speicherung von Wissensbasen. Auf diesesDatenmodell setzt eine Vielzahl von Ontologie-Sprachen, von denen diewichtigsten wie RDF(S), OIL, DAML-OIL und OWL hier beschrieben werdensollen, auf.

3.2 RDF / RDF(S)

Das RDF (Resource Description Framework) ist ein Metadaten-Modell zurBeschreibung von Internetressourcen. Das RDF-Schema (RDFS) beschreibt dieBeziehungen zwischen Eigenschaften und Ressourcen. Zusammen werden beideals RDF(S) bezeichnet. Obwohl RDF(S) Möglichkeiten bietet Ontologien zubeschreiben, sollte es nicht als eigentliche Ontologie-Sprache aufgefasst werden,sondern eher als eine generelle Beschreibungssprache für Metadaten im Internet[20].

3.2.1 Das RDF(S)-Modell

Das RDF Metadaten-Modell wurde zur Beschreibung von Internetressourcenentwickelt und ist Basis einer Schichtenarchitektur, die vom W3C20 in einemStandard präzisiert werden.

Grundlage für das RDF Datenmodell sind die folgenden Komponenten:

Ressourcen werden anhand von URI's21 angegeben undbezeichnen alles worüber mit RDF eine Aussage gemacht wird [35].Ressourcen können alles Identifizierbare repräsentieren, wie z.B.physikalische Objekte, abstrakte Konzepte, Verweise zu einerInternetseite oder Personen.

Eigenschaften werden verwendet, um einer Ressourcespezifische Attribute oder Charakteristika zuzuordnen.

Aussagen bestehen aus Subjekt, Prädikat und Objekt, wobei alledrei eine Ressource im RDF-Modell darstellen. Das Subjekt kannauch als Literal, d.h. als Text anstelle einer Ressource angegebensein. Eine Aussage korrespondiert zu einfachen Sätzen in natürlicherSprache der Form „Gabi liebt Hans“. „Gabi“ ist hier das Subjekt,„liebt“ Prädikat und „Hans“ das Objekt. Aussagen selbst können

20 World Wide Web Consortium, www.w3.org21 Uniform Resource Identifiers, RFC..., www....

22

durch die Verdinglichung auch Ressourcen sein, womit die Bildungvon Konstrukten wie „Peter sagt Gabi liebt Hans“ möglich wird,wobei „Gabi liebt Hans“ nun als Objekt aufgefasst wird.

In der RDF-KR-Ontologie werden die Konzepte, die auf RDF basieren, mit demPräfix „rdf“ ausgedrückt. Es ist nicht möglich, Beziehungen zwischen Ressourcenund Eigenschaften mit RDF zu beschreiben. Dies wird jedoch durch eineErweiterung des Grundvokabulars durch RDFS erreicht. Die Konzepte, die aufRDFS basieren, werden mit dem Präfix „rdfs“ ausgedrückt. RDF und RDFSwerden gemeinsam als RDF(S) ausgedrückt, für das die wichtigsten zu Verfügungstehenden Konzepte im weiteren aufgeführt werden.

3.2.2 RDF(S)-Konzepte

Es ist sinnvoll, die verschiedenen Konzepte für die RDF(S)-Sprache in dreiverschiedene Untergruppen aufzuteilen. Es werden hier alle wichtigen in dervorliegenden Arbeit benutzten Konzepte in RDF(S) beschrieben.22 Im Anschlusswerden die Möglichkeit zur Abbildung der Konzepte von RDF(S) auf das in [30]entwickelte und im ODBT-Prototypen verwendete Ontologie-Modell betrachtet(vgl. 2.2). Durch die zunächst verwirrende Groß- und Kleinschreibung werdenKlassen von Eigenschaften unterschieden.

Grundlegende Konzepterdfs:Resource: Dies ist die allen anderen Klassen übergeordnete Klasse und bildetdie Wurzel der in RDFS definierten Klassenhierarchie. rdf:Property: Definiert die Klasse der Eigenschaften in RDF. Die Eigenschaftenkönnen als Attribute von Ressourcen betrachtet werden. Außerdem können dieEigenschaften auch Beziehungen zwischen Ressourcen repräsentieren. rdf:Statement: Ist Unterklasse von rdfs:Resource und beschreibt die Klasse derTripel (Objekt, Prädikat und Subjekt), die in RDF(S) definiert werden können.

Schema-Definitions-Konzepte rdfs:subPropertyOf: Führt eine Spezialisierung von einer Eigenschaft auf eineandere Eigenschaft aus. rdfs:Class: Ist Unterklasse von rdfs:Resource und definiert die Klasse allerKlassen. rdf:type: Macht aus einer Ressource eine Instanz einer bestimmten Klasse (z.B.von rdf:Property). rdfs:subClassOf: Macht eine Spezialisierung von einer Klasse auf eine andereKlasse.rdfs:domain: Bestimmt den Domänenbereich einer rdfs:Ressource, für den diesegültig ist.rdfs:range: Bestimmt den Wertebereich, den eine Ressource annehmen kann.rdfs:Literal: Ist Unterklasse von rdfs:Resource und eine Klasse vonWertebreichen wie "String" oder "Integer".

22 Für eine vollständige Beschreibung siehe http://www.w3.org/TR/rdf-schema/

23

rdf:subject: Definiert eine Resource in einem rdf:Statement als Objekt.rdf:predicate: Definiert eine Resource in einem rdf:Statement als Prädikat.rdf:object: Definiert eine Resource in einem rdf:Statement als Subjekt.

Utility Konzepte

rdfs:seeAlso: Definiert eine Ressource, die eine Beschreibung von zusätzlicherInformation über eine andere Ressource hat. rdfs:isDefinedBy: Ist Untereigenschaft von rdfs:seeAlso und weist einerRessource den Namensraum zu, in der sie definiert ist.rdfs:label: Dient zur Bezeichnung einer Ressource.rdfs:comment: Dient zur Dokumentation einer Ressource.

Wie bereits in 2.2 beschrieben, wird eine Ontologie als 3-Tupel O = {C, R, I}modelliert. Sowohl Konzepte, als auch Beziehungen, sind in RDF(S) zunächstdurch "rdf:Ressource" ausgedrückt. Beziehungen werden durch "rdfs:statement"gebildet, wobei "rdf:Ressource" mit dem Typ "rdf:predicate" R entspricht. DieKonzepte C im Datenmodell von O werden in RDF(S) mit "rdfs:Class" definiertund können in einer Beziehung sowohl als "rdf:subject", als auch als "rdf:object"auftreten. Als Bezeichner für die Konzepte C und die Relationen R kann"rdfs:label" verwendet werden. Es ist jedoch wünschenswert, dass die "ISA","SynOf" und "PartOf" Beziehungen in R möglichst durch in RDF enthalteneModellierungsprimitive ausgedrückt werden können. Dies ist sinnvoll, um sichder Inferenzmöglichkeiten der Sprache zu bedienen. In RDF ist es jedoch nurmöglich, die ISA-Beziehung durch "rdfs:subClassOf" auszudrücken. Für dieSynOf- und PartOf-Relationen gibt es keine Modellierungsprimitive in derSprache.

3.2.3 RDF(S)-XML-Syntax

RDF(S) stellt, wie schon beschrieben, ein syntaxneutrales Datenmodell dar. Einesyntaktische Darstellungsmöglichkeit ist die Verwendung der XML-Sprache,wobei eine Spezifikation in [6] als Empfehlung des W3C herausgegeben wurde.Die Darstellung von RDF in XML, die hier gegeben werden, folgen dieserSpezifikation.

Zur Veranschaulichung der Möglichkeiten von RDF soll ein einfacher Ontologie-Graph, der wichtige Konzepte des eigenen Ontologie-Datenmodells besitzt, inRDF dargestellt werden. Die hier gezeigte Abbildung ist keine graphischeDarstellung von RDF, sondern soll auf dem in 2.2 gegebenen Graphenmodellbasieren.

Der Graph aus Abbildung 3.1 wird in Abbildung 3.1 in RDF(S)-XML-Syntaxdargestellt.

24

Abbildung 3.1 Beispiel-Ontologie mit wichtigenKonzepten für die Anfragetransformation

01 <?xml version="1.0"?>02 <!DOCTYPE rdf:RDF [<!ENTITY xsd"http://www.w3.org/2001/XMLSchema#">]>03 <rdf:RDF xml:lang="en"04 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"05 xmlns:rdfs="http://www.w3.org/TR/1999/PR-rdf-schema-19990303#">06 <rdfs:Class rdf:ID="Computer">07 <rdfs:comment>device that computes</rdfs:comment>08 </rdfs:Class>09 <rdfs:Class rdf:ID="DataProcessor">10 <rdfs:comment>device that computes</rdfs:comment>11 </rdfs:Class>12 <rdfs:Class rdf:ID="Notebook">13 <rdfs:comment>light, portable computer</rdfs:comment>14 <rdfs:subClassOf rdf:resource="Computer"/>15 </rdfs:Class>16 <rdfs:Class rdf:ID="Keyboard">17 <rdfs:comment>set of keys</rdfs:comment>18 </rdfs:Class>19 <rdf:Ressource rdf:ID="SynOf">20 <rdfs:comment>having the same meaning</rdfs:comment>21 </rdfs:Property>22 <rdf:Ressource rdf:ID="PartOf">23 <rdfs:comment>set of</rdfs:comment>24 </rdfs:Property>25 <rdf:Statement>26 <rdf:subject rdf:resource="#DataProcessor"/>27 <rdf:predicate rdf:resource="#SynOf"/>28 <rdf:object rdf:resource="#Computer"/>29 </rdf:Statement>30 <rdf:Statement>31 <rdf:subject rdf:resource="#Keyboard"/>32 <rdf:predicate rdf:resource="#PartOf"/>33 <rdf:object rdf:resource="#Notebook"/>34 </rdf:Statement>35 </rdf:RDF>

Abbildung 3.2 RDFS-Syntax

In Zeile 4-5 von Abbildung 3.2 werden die Namensräume für den RDF- undRDFS-Standard definiert. Dadurch ist es möglich, innerhalb des restlichenDokuments die Präfixe "rdf:" und "rdfs:" für die Konzepte, die sich auf RDF undRDFS beziehen, zu benutzen. In Zeile 6 wird eine Klasse "Computer" definiert,der zunächst als einzige Eigenschaft ein Kommentar durch "rdfs:comment"zugeordnet wird. Gleiches geschieht in den Zeilen 9 und 16 für die Klassen

25

Notebook

Computer

Keyboard

DataProcessor

Isa

PartOf

SynOf

"DataProcessor" und "Keyboard". Die Klasse "Notebook" in Zeile 12 bekommt inZeile 14, durch die Modellierungsprimitive "rdfs:subClassOf", die zusätzlicheEigenschaft zugewiesen, dass sie Unterklasse von "Computer" ist. In den Zeilen19 und 22 werden die Eigenschaften "SynOf" und "PartOf" definiert. In den Zeilen25-29 wird "DataProcessor" mit "Computer" durch die SynOf-Beziehung inBeziehung gesetzt und in Zeile 30-34 wird "Keyboard" als PartOf-Beziehung von"Notebook" beschrieben. Wie zu sehen ist, kann die Ontologie vollständig in RDF(S) abgebildet werden. Jedoch sind die Beziehungen "SynOf" und "PartOf" nichtmit semantischer Bedeutung versehen und können daher nicht für dieInferenzbildung benutzt werden.

Abschließend ist zu sagen, dass RDF(S) keine befriedigende Ontologie-Sprachefür den ODBT-Prototypen darstellt, da der Sprache wichtigeModellierungsprimitive für die SynOf- und PartOf-Beziehungen fehlen.

3.3 OWL

Die OWL-Ontologie-Sprache stellt eine Erweiterung von RDF(S) dar undübernimmt somit das in 3.3.2 beschriebene RDF-Datenmodell. Somit werden allein RDFS angebotenenen Konzepte auch in OWL unterstützt. OWL ist eineÜberarbeitung der DAML+OIL-Ontologie-Sprache und wurde vom W3C alsEmpfehlung eingestuft. Wie die DAML+OIL-Sprache, wurde auch OWL spezielldafür entwickelt, um Ontologien im Internet zu veröffentlichen und zu teilen.

3.3.1 Untersprachen

OWL gliedert sich in drei verschiedene Untersprachen, wobei eine Abwägungzwischen Funktionalität und Rechenkomplexität für die Wahl der entsprechendenOntologie-Untersprache vorgenommen werden muss.

OWL-Lite Dies ist die eingeschränkteste Untersprache von OWL.Sie unterstützt vor allem solche Anwendungen, die eine klassifizierteHierarchie und einfache Einschränkung auf Eigenschaften undKlassen benötigen.

OWL-DL Diese Untersprache erweitert die OWL-Lite Sprache miteinigen Modellierungsprimitiven. Der sprachliche Umfang vonOWL-DL wird aber noch so eingeschränkt, dass eine vollständigeBerechenbarkeit gegeben ist und alle Berechnungen in endlicher Zeitenden. OWL-DL Basiert auf den in 2.4 beschriebenenBeschreibungslogiken.

26

OWL-Full Dies ist die umfassendste Untersprache von OWL. Siewird gebraucht, um ein Maximum an Darstellungsmöglichkeiten undsyntaktischer Freiheit zu haben. Für OWL-Full ist nicht garantiert,dass es berechenbar ist. Es existiert auch noch keine Software,welche die kompletten Inferenzbildung von OWL-Fullimplementiert.

3.3.2 OWL-Konzepte

Alle Konzepte, die in 3.2.2 für RDF(S) beschrieben wurden, werden auch in dieOWL-Ontologie-Sprache übernommen. Konzepte werden in OWL als Klassenbezeichnet und werden mit den Modellierungsprimitive "owl:Class" gebildet.Zusätzliche Konzepte sind:

owl:disjointWith: Bestimmt, dass eine Klasse keine Instanzen mit einer anderenKlasse teilen kann.owl:equivalentClass: Zwei Klassen können als äquivalent ausgedrückt werden,wobei diese Klassen dann die gleichen Instanzen besitzen. Diese Eigenschaft kanndafür benutzt werden, zwei Klassen als Synonyme voneinander auszudrücken [26].owl:equivalentProperty: Zwei Eigenschaften können als äquivalent ausgedrücktwerden, wodurch synonyme Eigenschaften ausgedrückt werden können.owl:sameAs: Zwei Instanzen werden als gleich bezeichnet.owl:differentFrom: Eine Instanz wird als unterschiedlich zu einer anderen Instanzbezeichnet.owl:AllDifferent: Für mehrere Instanzen wird festgelegt, dass sie jeweilsuntereinander unterschiedlich sind.owl:inverseOf: Bezeichnet eine Eigenschaft als das Inverse einer anderenEigenschaft.owl:TransitiveProperty: Definiert eine Eigenschaft E als transitiv, d.h. für einetransitive Eigenschaft E gilt, dass, wenn ein Paar (x,y) und ein Paar (y,z) mit E inBeziehung stehen, so steht auch (x,z) in Beziehung zu E.owl:SymmetricProperty: Definiert eine Eigenschaft als symmetrisch, d.h. für einesymmetrische Eigenschaft S gilt, dass wenn ein Paar (x,y) in Beziehung steht, dannsteht auch (y.x) in Beziehung zu S.owl:FunctionalProperty: Bestimmt, dass höchstens eine Instanz über dieseEigenschaft gebildet werden darf.owl:InverseFunctionalProperty: Bestimmt, dass über das Inverse einerEigenschaft höchstens eine Instanz gebildet werden darf. Z.B. könnte dieEigenschaft "hat Kreditkartennummer" als "owl:InverseFunctionalProperty"bestimmt werden. Die Inverse Eigenschaft "Kreditkartennummer von" kannhöchstens einer Person zugeordnet werden.owl:allValuesFrom: Bestimmt, dass eine Klasse alle Eigenschaften einer anderenKlasse übernimmt.owl:someValuesFrom: Bestimmt, dass eine Klasse mindestens eine Eigenschafteiner anderen Klasse übernimmt.owl:intersectionOf: Bestimmt, dass eine Klasse alle Eigenschaften von zweianderen Klassen übernimmt.

Alle hier beschriebenen Konzepte beziehen sich auf die OWL-Lite-Untersprache.

27

OWL-DL und OWL-Full bieten noch die zusätzlichen Konzepte "owl:oneOf","owl:hasValue", "owl:disjointWith", "owl:unionOf", "owl:complementOf","owl:intersectionOf", "owl:minCardinality", "owl:maxCardinality" und"owl:cardinality", die hier nicht weiter betrachtet werden, da sie nicht benötigtwerden und die semantische Ausdrucksmächtigkeit von OWL-Lite für dieVerwendung im ODBT-Prototypen ausreicht.

Durch OWL sind nun zusätzliche Modellierungsprimitive vorhanden, um den in3.2.2 verfolgten Ansatz zur Darstellung von O aus 2.2 zu erweitern, und umzusätzliche semantische Ausdruckskraft zu erhalten. Die SynOf-Beziehung lässtsich mit OWL durch das Konzept "owl:equivalentClass" ausdrücken. Für diePartOf-Beziehung existieren in OWL keine Modellierungsprimitive jedoch bietetdie Sprache Umschreibungsmöglichkeiten diese Beziehung auszudrücken. DiesemProblem widmet sich [33], in dem ein Vorschlag gemacht wird, wie man diePartOf-Beziehung in OWL ausdrücken kann. „OWL does not provide any specialprimitives for part-whole relations, but contains sufficient expressive power tocapture most, but not all, of the common cases“ [33] Die PartOf-Beziehung isteine partielle Ordnung, d.h. sie ist transitiv, anti-symetrisch und reflexiv. DieOWL-Sprache gestattet nur, eine Beziehung als transitiv zu kennzeichnen.Teilweise können diese jedoch, wie in [33] beschrieben, mit anderen OWL-Ausdrucksmitteln modelliert werden.

3.3.3 OWL-XML-Syntax

Die Syntax von OWL baut auf die in 2.3.2 beschriebene RDF(S)-Syntax auf.Konzepte die aus RDF übernommen werden, werden mit gleichen Bezeichnern inder Syntax von OWL eingebettet.

Die in Abbildung 3.2 dargestellte XML-Syntax von OWL verdeutlicht, wie esmöglich ist, in OWL anhand des in Abbildung 3.1 dargestellten Graphen zubeschreiben.

01 <?xml version="1.0"?>02 <rdf:RDF03 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"04 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"05 xmlns:owl="http://www.w3.org/2002/07/owl#"06 <owl:Ontology rdf:about=""/>06 <owl:Class rdf:ID="Computer">07 <rdfs:comment>device that computes</rdfs:comment>08 </owl:Class>09 <owl:Class rdf:ID="DataProcessor">10 <rdfs:comment>device that computes</rdfs:comment>11 <owl:equivalentClass>Computer</owl:equivalentClass>12 </owl:Class>13 <owl:Class rdf:ID="Notebook">14 <rdfs:comment>light, portable computer</rdfs:comment>15 <rdfs:subClassOf rdf:resource="Computer"/>16 </owl:Class>17 <owl:Class rdf:ID="Keyboard">

28

18 <rdfs:comment>set of keys</rdfs:comment>19 <rdfs:subClassOf>20 <owl:Restriction>21 <owl:onProperty>22 <owl:ObjectProperty rdf:ID="is_part_of"/>23 </owl:onProperty>24 <owl:someValuesFrom>25 <owl:Class rdf:ID="Notebook"/>26 </owl:someValuesFrom>27 </owl:Restriction>28 </rdfs:subClassOf>29 </owl:Class>30 <owl:TransitiveProperty rdf:about="#is_part_of">31 <owl:inverseOf>32 <owl:TransitiveProperty rdf:about="#has_part"/>33 </owl:inverseOf>34 <rdf:typerdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>35 </owl:TransitiveProperty>36 <owl:TransitiveProperty rdf:about="#has_part">37 <owl:inverseOf>38 <owl:TransitiveProperty rdf:about="#is_part_of"/>39 </owl:inverseOf>40 <rdf:typerdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>41 </owl:TransitiveProperty>42 </rdf:RDF>

Abbildung 3.3 OWL Syntax der Abbildung 3.1

Wie aus diesem OWL-Beispiel zu erkennen ist, kann die Gleichheit zwischen denKonzepten "Computer" und "Data-Processor" in der Zeile 11 durch die"owl:equivalentClass" Modellierungsprimitive ausgedrückt werden. Die PartOf-und HasPart-Beziehungen werden explizit als transitive Beziehungen in Zeile 30und Zeile 36 definiert und in den Zeilen 31-33 und den Zeilen 37-39 als jeweilsInverses voneinander gebildet. Durch die Einschränkung mit"owl:someValuesFrom" in Zeile 24-26, wird definiert, dass "Keyboard" nur eineTeilmenge der Eigenschaften von "Notebook" besitzt.

3.4 Abschlussbetrachtung zu Ontologie-Sprachen

In diesem Kapitel wurde ein historischer Überblick über die wichtigstenOntologie-Sprachen gegeben, sowie die RDF(S)- und OWL-Sprachen näherbetrachtet. Die Verwendung der OWL-Sprache für den ODBT-Prototypen erfülltdie in Kapitel 3.1. aufgelisteten Anforderungen am besten und wird daher alsGrundlage für die Implementierung gewählt. Im Vergleich zu RDF(S) bietet siezusätzliche Modellierungsprimitive, die benötigt werden, um das in 2.2 gegebeneDatenmodell zufriedenstellend zu modellieren. Es existiert eine Vielzahl von indieser Sprache definierten Ontologien und es ist davon auszugehen, dass sich dieVerwendung dieser Sprache und die Unterstützung durch Werkzeuge noch erhöht.Durch die Empfehlung von OWL durch das W3C besteht die Hoffnung, dass sichdiese Technologie als Standard für die zukünftige internetbasierte Ontologie-Modellierung entwickelt.

29

Kapitel 4

Ontologie-Werkzeuge

Es existiert eine Vielzahl von Werkzeugen, die verschiedensteAnwendungsgebiete für das Arbeiten mit Ontologien unterstützen. DieVerwendung eines geeigneten Ontologie-Werkzeugs für denAnforderungsbereich, der sich für die Umsetzung der ontologie-basiertenAnfragetransformation ergibt, wird in diesem Kapitel analysiert.

Die Werkzeuge, die zum Einsatz kommen, müssen bestimmte Anforderungenerfüllen. So sollte es möglich sein, die Speicherung entweder in relationalenDatenbanken oder eigenen Speichermethoden eines Werkzeugs vorzunehmen undpersistent zu halten. Für die Verwendung von real existierenden Ontologien musses durch die Werkzeuge möglich sein, RDF-Daten im XML-Format einzulesenoder zu speichern. Dabei sollten sie geeignete Methoden zur Verfügung stellen,durch die das Erstellen, Einlesen, Bearbeiten und Durchsuchen der Ontologieermöglicht wird. Ein wichtiger Aspekt ist die Unterstützung der OWL-Ontologie-Sprache und deren Möglichkeiten zur Inferenzbildung, die, wie in Kapitel 3erläutert wurde, aufgrund ihrer Ausdruckskraft für die Ontologie-Modellierungverwendet werden soll.

Bei der Verwendung von relationalen Datenbanksystemen gibt es verschiedeneAnsätze der Speicherung. Diese sollen in der späteren Betrachtung einigerausgewählter Werkzeuge genauer analysiert werden.

4.1 Anforderungen an Ontologie-Werkzeuge

Eine Anfrage an die Ontologie wird in den meisten Ontologie-Werkzeugen überein zur Verfügung stehendes API oder eigene Ontologie-Anfragesprache gestellt.Es muss möglich sein, die Anfrage über dem ursprünglich angelegten und eineminferierten Ontologie-Graphen zu stellen, was zu unterschiedlichen Ergebnissenführen kann. Für die Umformungsregeln ist es nötig, dass der Zugriff auf beide

30

Graphen möglich ist. So wird z.B. bei der Verarbeitung der Part-Whole-Regel aufdie Transitvitätseigenschaften der PartOf-Beziehung verzichtet (vgl.7.2).

Leider existiert in Bezug auf die Anfragesprachen auf RDF-Daten noch keineinheitlicher Standard. Dies wirkt sich auch negativ auf die jeweiligeImplementierung der Anfragesprachen innerhalb von Ontologie-Werkzeugen aus.Problematisch für eine Abstraktion dieser Schemata ist, dass sich die Syntax, aberauch die semantische Aussagekraft, zum Teil stark für verschiedeneAnfragesprachen unterscheiden. Eine gute Übersicht über bekannte RDF-Anfagesprachen liefert [13].

4.2 Jena

Jena23, das mittlerweile in der zweiten Generation als Jena2 zur Verfügung steht,ist ein Open-Source-Projekt und eines der führenden Ontologie-Werkzeuge. Jenasgrößte Stärke ist ein extrem flexibles und ausdrucksstarkes API zur Bearbeitungund Anfrage an RDF-Graphen. Es enthält einen RDF/XML-Parser und I/O-Modul.Außerdem wird die Anfrage über eine eigene Anfragesprache (RDQL) unterstützt.

Architektur

Jenas innere Struktur basiert auf einer vereinfachten Abstraktion eines RDF-Graphen als tripelbasierte Struktur. Das Datenbanksubsystem von Jena erlaubt es,RDF-Graphen mittels der JDBC-Datenbankschnittstelle persistent inverschiedenen Datenbanken zu speichern. Unterstützt werden die Datenbank-Management-Systeme MySQL, PostgreSql und Oracle. Im Vergleich zu älterenJena1-Distributionen wurde das interne Datenbankschema auf Performanzoptimiert, indem das bisherige normalisierte Schema zur Speicherung des RDF-Graphen denormalisiert wurde. Dadurch entfallen bei der Anfrage zusätzlicheJoins, welche in der normalisierten Variante nötig sind [22].

Jena besitzt eine modulare Architektur und gestattet es, verschiedeneInferenzsubsysteme für RDF(S), OWL oder DAML+OIL einzubinden. Es ist auchmöglich, eigene Axiome über benutzerdefinierte Regeln zu definieren.

Inferenzmechanismen

Der Basis-Ontologiegraph wird in Jena durch einen inferierten Graphen, derzusätzliche virtuelle Aussagen enthält, gebildet. Der inferierte Graph unterstütztdie gleichen Zugriffs- und Anfrageschnittstellen wie der Basisgraph, stellt aberdarüber hinaus noch Methoden für die Konsistenzprüfung und das

23 URL http://jena.sourceforge.net/

31

Zurückverfolgen von angewandten Inferenzmechanismen zur Verfügung. DieImplementierung des inferierten Graphen liegt als Schicht über dem Basisgraph.Es ist möglich, Jena mit unterschiedlichen Mechanismen zur Inferenzbildung mitvorhandenen Regeln zu betreiben. Eine Möglichkeit ist es, einen Mechanismus,basierend auf dem RETE-Vorwärtsverkettungs24-Algorithmus, zu benutzen [36].Eine andere Möglichkeit ist einen auf SLD-Bäumen basierten Algorithmus derRückwärtsverkettung25 anzuwenden. Dies ist ein Verfahren, das auch in derProgrammiersprache PROLOG zur Anwendung kommt. Beide Mechanismenkönnen auch in einer kombinierten Form betrieben werden. In Jena existierenvordefinierte Inferenzregeln für die RDF(S)- und OWL-Ontologie-Sprachen, mitdenen die Inferenzbildung durchgeführt wird. Die Architektur ist aber auch durchzusätzliche Regeln erweiterbar.

Im Unterschied zum Basisgraph unterstützt Jena eine Speicherung des inferiertenGraphen nur innerhalb des Hauptspeichers. Jena liefert effektive Caching-Mechanismen, die eine schnelle Anfrage auf dem inferierten Graphen erlauben,jedoch müssen erhebliche Performanzeinbußen bei der ersten Anfrage gemachtwerden, da noch kein inferierter Graph existiert. Es existieren aber Ambitionen, inkünftigen Distributionen Verbesserungen vorzunehmen und Teile des inferiertenGraphen, wie z.B. die transitive Hülle der Subklassenbeziehung, innerhalb despersistenten Datenbankmodells aufzunehmen.

Abbildung 4.1 Jena Inferenzbildung

24 engl. forward chaining25 engl. backward chaining

32

Inferenzgraph

Ontologie Modell API

BasisgraphOntologie

Definitionen

Reasoner

ReasonerVerwaltung

Model Factory

erstelle

suche

Inferenz

bind schemabind

Wie in Abbildung 4.1 zu sehen ist, erzeugt der Jena „Reasoner“ aus demBasisgraphen, der die eigentliche Ontologie-Modellierung enthält, und den in denOntologie-Definitionen angegebenen Inferenzregeln einen Inferenzgraphen, aufden das Jena-Ontologie-Modell-API zugreift. Sobald der Inferenzgraph erstellt ist,findet bei erneuter Anfrage folglich keine weitere Inferenzbildung statt.

Die Regeln, die der Reasoner für die Inferenzbildung benutzt, können auch eigensinnerhalb des zur Verfügung stehenden API definiert werden. Dies wird durchfolgendes Beispiel, das die Transitivitätseigenschaft der"rdfs:subClassOf"-Beziehung ausdrückt, dargestellt.

...[rule2: (?a rdfs:subClassOf ?b)

(?b rdfs:subClassOf ?c) -> (?a rdfs:subClassOf ?c) ]

...

Jena Regel Syntax für die Transitivität der"rdfs:subClassOf"-Beziehung

4.3 SESAME

Sesame26 ist ein Open-Source-Java-Framework für die Speicherung, die Anfrageund die Inferenzbildung von RDF und RDF(S). Es kann als Datenbank für RDFund RDF(S), oder als Java-Bibliothek für Applikationen, die intern mit RDFarbeiten, genutzt werden. Sesame kann als Ontologie-Server betrieben, oder überdas Sesame-Graph-API angesprochen werden. Das Graph-API erlaubt detaillierteManipulationen von RDF aus der Java-Programmiersprache. Eine eigensimplementierte File-Speicherung ermöglicht es, komplett auf ein DBMS zuverzichten. Sesame benutzt dafür eine B-Tree-Indexierung. Mit ReSQL besitztSesame zudem eine eigene ausdrucksstarke Anfragesprache.

Architektur

Die Kommunikation des Benutzerprogramms mit Sesame läuft zum einen überdas Graph-API, das zum Erstellen und Navigieren über einem RDF-Graphenverwendet werden kann. Zum anderen kann über das Repository-API, das eineBearbeitung auf einer abstrakteren Ebene ermöglicht, zugegriffen werden. Diesbeinhaltet Methoden zum Suchen über die SeRQL- oder RQL-Anfragesprachen,oder das Lesen und Schreiben von RDF-Dateien. Beide greifen auf das SAIL27-API zu, dass von der zugrunde liegenden Speicherstruktur abstrahiert. Außerdemstellt das SAIL-API verschiedene Inferenzmechanismen bereit.

26 URL http://www.openrdf.org/27 engl. Storage And Inference Layer

33

Die Speicherung kann sowohl in einer Datenbank, als auch im Hauptspeichererfolgen. Eine zusätzliche Möglichkeit, die Sesame unabhängig von einem DBMSmacht und trotzdem eine effektive persistente Speicherung gestattet, ist eine mitB-Tree implementierte, native Speichermethode. Die beschriebene Architekturvon Sesame wird in Abbildung 4.2 dargestellt28.

Abbildung 4.2 hierarchische Struktur der SesameArchitektur

Es ist zusätzlich möglich, Sesame als Client-Server Architektur zu betreiben,worauf aber an dieser Stelle nicht näher eingegangen werden soll, da dieArchitektur des ODBT-Prototypen sich auf die Kommunikation über das APIbeschränkt.

Inferenzmechanismen

Die Inferenzbildung des RDF-Schema ist voll kompatibel mit den Semantik-Empfehlungen des W3C für RDF. Für OWL steht ein eigenes Modul zurVerfügung. Es ist aber auch möglich, die Inferenz von OWL durch Sesamesflexibel konfigurierbaren „Inferencer“ zu bilden. Der „Inferencer“ gestattet es,

28 vgl. URL http://www.openrdf.org/documentation.jsp

34

Sesame Zugriffs-API

Benutzerprogramm

Graphen-API "Repository"-API

RQLSeRQL

SAIL API

JDBC Haupt-speciher

Native-Speicherung

01110110101010000100101101101010100e010101011101101010100001001011011010

10100e010101

eigene Regeln zu definieren, die in XML-Format in einem separaten File abgelegtwerden.

Ein Beispiel einer selbst definierten Regel in Sesame, die das Inverse der HasPart-Beziehung definiert ist gegeben durch:

...<rule name="odbt6">

<premise><subject var="xxx"/><predicate uri="&hpa;hasPart"/><object var="yyy"/>

</premise><consequent>

<subject var="yyy"/><predicate uri="&pof;partOf"/><object var="xxx"/>

</consequent><triggers_rule>

<rule name="odbt7" /></triggers_rule>

</rule>...

XML-Regel-Syntax für das Inverse der HasPart-Beziehung inSesame

Die Regel-Syntax orientiert sich an dem RDF-Graphenmodell durch dieBenennung der XML-Tags mit Subjekt, Prädikat und Objekt. Wie zu sehen ist,wird jeweils eine Prämisse angegeben, welche, wenn sie erfüllt ist, eineKonsequenz nach sich zieht. Es ist weiterhin zu erkennen, dass im Vergleich zuden Regeln, wie sie in Jena definiert werden, noch zusätzlich Auslöser definiertwerden können. Durch diese werden bei Anwendung einer Regel andere Regelnausgeführt, die als Auslöser definiert sind. Dadurch kann die unnötigeAnwendung aller Regeln nach Ausführung einer Regel vermieden werden. InBeispiel 4.2 wird die nicht dargestellte Regel "odbt7" bei der Anwendung von derRegel "odbt6" ausgelöst.

4.4 Integrated Ontology Development Toolkit (IODT)

Das von IBM entwickelte „Integrated Ontology Development Toolkid“29(IODT)bietet eine Vielzahl von Möglichkeiten Ontologien zu visualisieren, zu erstellen,zu bearbeiten oder zu durchsuchen. Das Werkzeug ist in drei Komponenten(Orient, EODM, RStar) unterteilt, die jeweils unterschiedlichen Ansprüchen fürdie Benutzung genügen. Zusammen ergeben die Komponenten eine Plattform zurVerwaltung von RDF-Datenmodellen.

29 https://secure.alphaworks.ibm.com/tech/semanticstk

35

EODM (EMF30 Ontologie Definition Metamodell) API

Das EODM ist ein objektorientiertes Datenmodell, dass einen Großteil derKlassen und Methoden, die für die Repräsentation, Erstellung, Bearbeitung,Navigation und Serialisierung primitiver Konzepte in RDF(S) benötigt werden,liefert. Das EODM-API stellt Methoden zur Verfügung, mit denen es möglich ist,über einem bestehenden Modell zu navigieren. Datenmodelle können über dasRDF-XML importiert oder über das EODM-API erstellt werden. Die Verwendungvon EODM für den Zugriff auf Ontologien im ODBT Prototypen ist nichtgeeignet, da es keine Inferenzmechanismen liefert.

RStar

RStar ist ein Werkzeug, dass die Speicherung und Anfrage auf großen RDF-Datenbeständen gewährleistet. Dabei benutzt RDF relationale DBMS (DB2,Cloudscape) für die persistente Speicherung. Dem Programmierer stehen flexibleAPIs zum Laden, Durchsuchen und Bearbeiten von RDF zur Verfügung.Zusätzlich zu RDF wird RDFS und OWL unterstützt. In RStar ist es jedoch nichtmöglich, eigene Inferenzregeln zu definieren. RStar implementiert die SQL-ähnliche Sprache RSQL und stellt Methoden für die Anfrage bereit. Mit dieser istes möglich, RDF-Tripel aus dem zugrunde liegenden persistenten Ontologie-Graphen zu erhalten. Die Sprache ist aufgebaut aus SELECT, FROM, WHEREund USING Statement und orientiert sich an SQL.

Orient

Orient ist ein in die Eclipse-Plattform eingebundenes Tool, mit dem es möglichist, Ontologien zu erstellen, zu managen und zu visualisieren. Eingebunden inEclipse bietet Orient eine graphische Benutzeroberfläche mit mehrerenPerspektiven um RDF-Daten zu visualisieren. Wie schon in Kapitel 4.1. erwähnt,wird dieser Funktionsumfang nicht für den ODBT-Prototypen benötigt.

4.5 Übersicht Ontologiewerkzeuge

Die Programmierschnittstelle des ODBT-Prototypen, wie sie in 8.2.1 beschriebenwird, abstrahiert den Zugriff auf das zugrunde liegende Ontologie-Werkzeug. Diezu implementierenden Methoden sollten von jedem verwendeteten Werkzeugdurch möglichst direkten Zugriff realisiert werden. Beispielsweise wäre esmöglich, durch das rekursive Durchlaufen eines Ontologie-Graphen manuell alleSubklassen einer Klasse zu finden. Ein gleiches Ergebnis sollte aber möglichstdurch eine direkte Anfrage auf dem inferierten Ontologie-Graphen geliefert

30 Eclipse Modelling Framework

36

werden. Folgende Übersicht zeigt alle Anforderungen, die in dieser Hinsichterfüllt werden sollten und welches der hier betrachteten Werkzeuge diese aucherfüllt.

Jena Sesame IBM IODT Programmiersprache Java Java JavaDatenbanksubysteme MySql,

PostgreSql,Oracle

MySql,PostgreSql,Oracle

DB2, Derby(Cloudscape)

RDF(S) JA JA JARDF/XML JA JA JAOWL JA JA JAOWL-DL Inferenz JA JA JAEigene Inferenzregeln JA JA NEINPersistenterInferenzgraph

NEIN JA NEIN

Verfügbarkeit Open source Open source frei verfügbar

Tabelle 4.1 Übersicht von Ontologie-Werkzeugen

Es ist zu erkennen, dass Sesame die größte Funktionalität aufweist. Das IODT-Werkzeug von IBM hebt sich durch die Benutzung anderer Datenbanken, als sievon den anderen Werkzeugen verwendet werden, ab. Durch das Fehlen derFunktionalität zur Definition eigener Inferenzregeln ist die Verwendbarkeit desIBM-Werkzeug aber stark eingeschränkt. Sowohl das Jena-, als auch das IODT-Werkzeug besitzen nicht die Möglichkeit einen Inferenzgraphen persistent in derDatenbank zu speichern.

37

Kapitel 5

Mapping zwischen Datenbank undOntologie

Der Begriff des "Mapping" wird in Bezug auf Datenbanken und Ontologien in derLiteratur für teilweise sehr verschiedene Problemstellungen verwendet. Daher solldieser hier zunächst kurz für die verschiedenen Verwendungsformen erläutertwerden.

1. Abbildung auf SpeicherstrukturenDas wohl am meisten untersuchte Gebiet, in dem der Begriff "Mapping" inZusammenhang mit Ontologien verwendet wird, ist die Darstellung einesontologie-basierten Datenmodells innerhalb einer zumeist relationalenDatenbank. Eine Ontologie wird in einer möglichst effizienten Weise in Bezugauf Zugriffszeit bzw. Speicherplatz persistent in einer Datenbank abgebildet,was mit dem Begriff "Mapping" klassifiziert wird.

2. Überführung von InstanzdatenEin weiteres Gebiet, in dem das Mapping zwischen Datenbanken undOntologie behandelt wird, ist beim „Reverse Engineering“ von relationalenDatenbanken in ein ontologie-basiertes Datenmodell. Hintergrund ist hierzumeist die Migration von in relationalen Datenbanken vorhandenenDatenbeständen in das Semantische Web [1]. Das Mapping beschreibt somitdie Übertragung von Schemata und Instanzdaten von einem Datenmodell in einanderes.

3. Korrespondenz zwischen ElementenIn einer weiteren Betrachtungsweise wird der Begriff Mapping verwendet, umeine Zuordnung zwischen einem Datenbankmodell und einem ontologie-basierten Datenmodell herzustellen. Das Mapping beschreibt somit eineKorrelation zwischen Schemata und Instanzdaten in beiden Modellen.

Der für diese Arbeit verwendete Kontext des Mapping-Begriffs ist der im Punkt 3

38

angegebene.

Mapping-DefinitionEin Datenmodell M besteht aus Schema S und Instanzdaten I, also M⊂S∪ I .Dann ist ein Mapping das Resultat einer Vergleichsoperation zwischen zweiDatenmodellen M 1 und M 2 . Das Mapping besteht aus einer Menge vonKorrespondenzen ∈ , die jeweils Mapping-Elemente e∈M 1 mit Mapping-Elementen s∈M 2 referenzieren. Das Mapping zwischen Datenbank undOntologie wird mit ONT_DB=M ONT×M DB angegeben.

Die zu erarbeitenden Konzepte für ΨONT_DB gliedern sich in zwei verschiedeneBereiche. Zum einen gilt es eine wohl definierte Repräsentation der Mapping-Syntax zu liefern, welche, wie in [24] beschrieben wird, auf die Korrespondenzeneinschränkt, die bestehen dürfen. Zum anderen sollten möglichst automatisierteMechanismen und Algorithmen zum Finden eines Mappings erstellt werden,worauf in Kapitel 6 ausführlich eingegangen wird.

5.1 Bereits existierende Ansätze

Leider liefert die Literatur nur wenige Ansätze, die sich direkt mit dem Mappingzwischen Datenbanken und Ontologien beschäftigen. In [2] und [5] werden dieSprachen R2O und D2R beschrieben, die jeweils ein Mapping eines relationalenDatenbankschemas und einer Ontologie in RDF(S) oder OWL beschreiben. DerHauptschwerpunkt bei der Entwicklung dieser Sprache lag in der Fähigkeit derSprache, anhand eines gegebenen Mappings eine automatische Datenmigrationvon Datenbanken in Ontologien zu ermöglichen. Für eine Datenmigration von derOntologie zur Datenbank sind beide Sprachen nicht geeignet.

Beide Ansätze eignen sich nicht für die ontologie-basierte Transformation vonDatenbankanfragen, wie sie in der vorliegenden Arbeit behandelt wird. Dies liegtan der nur eingeschränkten Darstellungsmächtigkeit, die das Mapping vonDatenbankinstanzen auf Konzepte in der Ontologie nicht ermöglicht. Trotzdemsollen die deklarativen Mapping-Verfahren, wie sie in diesen Sprachen benutztwerden, als Vorlage für eine eigene deklarative Mapping-Beschreibungssprachebenutzt werden. Diese Art der deklarativen Mapping-Beschreibung wird auch in[3] vorgeschlagen, um Domänenunabhängigkeit und Wiederverwendbarkeit zuerlangen. Ein eigener Ansatz hierzu wird später beschrieben. Dieser Ansatzbenutzt eine XML-Syntax, um Elemente zwischen Ontologie und Datenbank zureferenzieren. Beispiele, in denen diese Syntax angewendet wird, werden in denfolgenden Kapiteln 5.2 und 5.3 gegeben. Die Datentypdefinition der XML-Syntaxist in A.3.1 aufgeführt.

39

5.2 Mapping auf Schemaebene

Zunächst sollen die Extension der Datenbank und die Instanzdaten der Ontologieaußer acht gelassen werden und Mapping-Verfahren nur auf reiner Schemaebenebeschrieben werden.

Ein relationales Datenbankschema besteht aus Relationennamen R, AttributnamenAi , Domänenbereich Di sowie Primärschlüssel und Fremdschlüsselbeziehungenals Integritätseigenschaften. Die Ontologie besteht auf Schemaebene ausKonzepten C, Beziehungen zwischen Konzepten R und Eigenschaften vonKonzepten P. Diese Darstellung der Ontologie bezieht sich auf die GrundlegendenKonzepte (Ressourcen, Eigenschaften und Aussagen) von RDF (vgl. 3.2.1). MitSDB = {R, Ai, Di} und SONT = {C, R, P} bildet ONT_DB={R , Ai , Di}×{C , R , P }somit die Menge der möglichen Korrespondenzen.

Aus den Bestandteilen der beiden Schemata kann nun auf die sinnvollenKorrespondenzen reduziert werden. Das Mapping auf den Domänenbereich sowiedie Integritätseigenschaften ist wenig sinnvoll und entfällt. Übrig bleiben folgendeKonstellationen:

Abbildung 5.1 Korrespondenzen auf Schemaebene

Wie in Abbildung 5.1 zu erkennen ist, werden nicht alle Konzepte als potenzielleKorrespondenzen zugelassen. Konzepte sollten auf Schemaebene nur aufRelationen und nicht auf Attributnamen gemappt werden können. Eigenschaftenvon Konzepten sollten nur auf Attributnamen und nicht auf Relationennamenzugelassen werden. Es ist jedoch möglich, wie aus einem späteren Beispiel nochersichtlich wird, dass Beziehungen zwischen Konzepten sowohl aufRelationennamen, als auch auf Attributnamen gemappt werden können.

Die einzelnen Korrespondenzen auf Schemaebene sollen nun näher erklärt undanhand eines Beispiels verdeutlicht werden. Abbildung 5.2 zeigt eine vereinfachtegraphische Darstellung einer Ontologie, welche die Beziehung zwischen

40

Relation Konzept

Attribut Eigenschaft eines Konzeptes

Beziehung zwischen Konzepten

Akademikern und deren Arbeitsumfeld darstellt. Der Graph ist auf diewesentlichen Merkmale reduziert, daher werden die Typ-Eigenschaften direktinnerhalb der Konzeptknoten angegeben.

Abbildung 5.2 akademische Ontologie in graphischerRDF Darstellung

Arbeit

Titel Erstellungsdatum

Wissenschaftler

Name Alter Verfasst

Forschungseinrichtung

Name Land Adresse

Arbeitet_In

Wissenschaftler Forschungseinrichtung

Abbildung 5.3 akademische Datenbank als relationalesDatenbankschema

5.2.1 Korrespondenzen zwischen Relationennamen undKonzepten

Konzepte werden auf Schemaebene ausschließlich zu Relationennamen gemappt,wobei so gebildete Korrespondenzen mit C R bezeichnet werden. Es ist wichtighier klarzustellen, dass nur manchmal alle Attribute einer Relation genau alleEigenschaften eines gemappten Konzeptes abdecken. Man spricht dann von einem

41

<<rdfs:Class>>ex:Akademiker

<<rdfs:Class>>ex:Arbeit

<<rdfs:Property>>ex:Name

ex:verfasst

<<rdfs:Property>>ex:Alter

rdfs:domain

<<rdfs:Property>>ex:Titel

<<rdfs:Class>>ex:Forschungseinrichtung

ex:arbeitet_in

rdfs:domain rdfs:domain

direkten Mapping. Es ist aber auch möglich, dass einige Attribute nicht alsEigenschaft eines Konzeptes gemappt werden können, wobei man hier von einerProjektion spricht. Eine weitere Möglichkeit ist, dass die Eigenschaften einesKonzeptes über Spalten in verschiedenen Relationen verteilt sein können, wobeidieses durch die Vereinigung von Relationen ausgedrückt wird. Somit ist es auchmöglich, dass ein Konzept auf mehrere Relationennamen gemappt wird [2]. ImBeispiel werden alle in der Ontologie vorhandenen Konzepte direkt auf genaueinen Relationennamen gemappt.

<DbRelationOntConceptMapping><DbRelation name="Arbeit" /><OntConcept url="ex:Arbeit" />

</DbRelationOntConceptMapping><DbRelationOntConceptMapping>

<DbRelation name="Wissenschaftler" /><OntConcept url="ex:Akademiker" />

</DbRelationOntConceptMapping><DbRelationOntConceptMapping>

<DbRelation name="Forschungseinrichtung" /><OntConcept url="ex:Forschungseinrichtung" />

</DbRelationOntConceptMapping>

XML-Struktur für C R

5.2.2 Korrespondenzen zwischen Relationennamen undBeziehungen zwischen Konzepten

Mit Relationen werden im relationalen Datenbankschema oft über FremdschlüsselN:M Beziehungen zwischen zwei anderen Relationen ausgedrückt. Daher machtes Sinn, dass auch Relationen mit Beziehungen zwischen Konzepten gemapptwerden. Solche Korrespondenzen werden mit R R ausgedrückt. Im Beispiel wirddie Relation "Arbeitet_In" mit der Beziehung "ex:arbeitet_in" gemappt. Die imDatenbankschema enthaltenen Fremdschlüsselbeziehungen der gemapptenRelation erlauben es, die mit der Relation in Beziehung gesetzten Relationen zuerhalten. Daher brauchen die Fremdschlüsselbeziehungen nicht explizit in dasMapping aufgenommen zu werden.

<DbRelationOntRelationshipMapping><DbRelation Name="arbeitet_in" /><OntRelationship url="ex:arbeitet_in">

<OntSubject url="ex:Akademiker" /><OntObject url="ex:Forschungseinrichtung" />

</OntRelationship></DbRelationRelationshipMapping>

XML-Struktur für R R

Das hier gegebene Mapping reicht aus, um aus der Datenbank die Information zuextrahieren, dass die Relation "Arbeitet_In" der Beziehung "ex:arbeitet_in"zugeordnet werden kann. Diese setzt die zwei Relationen "Wissenschaftler" und"Forschungseinrichtung" in Beziehung, die wiederum auf "ex:Akademiker" und

42

"ex:Forschungseinrichtung" gemappt sind. Es ist wichtig, das Konzept"ex:Akademiker" als Subjekt der Beziehung und "Forschungseinrichtung" alsObjekt der Beziehung explizit zu deklarieren. Dies ist notwendig, da die"arbeitet_in" Beziehung in der Ontologie auch andere Konzepte miteinander inBeziehung setzen kann. Für dieses Mapping ist aber nur die Beziehung zwischen"Akademiker" und "Forschungseinrichtung" gemeint.

5.2.3 Korrespondenzen zwischen Attributnamen undBeziehungen zwischen Konzepten

Beziehungen zwischen Konzepten können in Datenbanken auf Attributnamengemappt werden. Wenn die gemappten Attributnamen als ein Fremdschlüssel aufeine andere Relation zeigen, bilden sie eine 1:N Beziehung, sonst eine 1:1Beziehung. Korrespondenzen zwischen Attributnamen und Beziehungen zwischenKonzepten werden mit R A ausgedrückt. Im Beispiel gibt es in der Datenbankdas Attribut "Verfasst" in der Relation "Wissenschaftler". Der Attributname kannauf die Beziehung "ex:verfasst" gemappt werden, da die Beziehung zwischen derRelation "Wissenschaftler" und "Arbeit" gebildet wird, die mit der "ex:verfasst"Beziehung zwischen "Akademiker" und "Arbeit" übereinstimmt.

<DbAttributeOntRelationshipMapping><DbRelation name="Wissenschaftler">

<DbAttribute name="Verfasst" /></DbRelation><OntRelationship url="ex:verfasst">

<OntSubject url="ex:Akademiker" /><OntObject url="ex:Arbeit" />

</OntRelationship></DbAttributeOntRelationshipMapping>

XML-Struktur für R A

5.2.4 Korrespondenzen zwischen Attributnamen undEigenschaften von Konzepten

Als letztes Mapping auf Schemaebene können Eigenschaften von Konzepten aufAttributnamen gemappt werden, wobei die Korrespondenzen mit P A bezeichnetwerden. Es ist hier zu betonen, dass diese Korrespondenzen zusammen mit demMapping zwischen Relationennamen und Konzepten, als wichtige Eigenschaft dasautomatische Übertragen von Instanzen zwischen Datenbank- zum Ontologie-Schema ermöglichen. Daher konzentriert sich die Mapping-Erstellung, wie sie in[2,5] beschrieben wird, weitestgehend auf diese beiden Ansätze. Im Beispielkönnen in der Ontologie die Eigenschaften "ex:Name" und "ex:Alter" desKonzeptes "ex:Akademiker" auf die Attribute "Alter" und "Name" in der Relation"Wissenschaftler" gemappt werden. Das bereits existierende Mapping des

43

Konzeptes "ex:Akademiker" und des Relationennamens "Wissenschaftler" kanninferiert werden und muss nicht erneut angegeben werden.

<DbAttributeOntPropertyMapping><DbRelation name="Arbeit">

<DbAttribute name="Titel" /></DbRelation><OntProperty url="ex:Titel">

<ontClass url="ex:Arbeit" /></OntProperty>

</DbAttributeOntPropertyMapping><DbAttributeOntPropertyMapping>

<DbRelation name="Wissenschaftler"><DbAttribute name="Alter" />

</DbRelation><OntProperty url="ex:Alter">

<ontClass url="ex:Akademiker" /></OntProperty>

</DbAttributeOntPropertyMapping><DbAttributeOntPropertyMapping>

<DbRelation name="Wissenschaftler"><DbAttribute name="Name" />

</DbRelation><OntProperty url="ex:Name">

<ontClass url="ex:Akademiker" /></OntProperty>

</DbAttributeOntPropertyMapping>

XML-Struktur für P A

5.3 Mapping-Ansätze auf Instanzebene

Nachdem die verschiedenen Möglichkeiten der Mapping-Erstellung auf derSchemaebene betrachtet wurden, sollen nun die möglichen Konstellationen, diesich mit Einbeziehung der Instanzebene ergeben, betrachtet werden. Im Vergleichzum Datenbankschema ändern sich die Instanzdaten der Datenbank häufig, daInstanzen im laufenden Betrieb in der Datenbank eingefügt, gelöscht oderverändert werden. Es ist daher schwierig, während der Laufzeit ein konsistentesMapping zwischen Datenbank und Ontologie auf Instanzdaten zu bewahren.Somit ist ein Mapping auf Instanzen nur zur Laufzeit sinnvoll und sollte nichtüber längere Zeit persistent gehalten werden. Anders verhält es sich, wenn aufeinen Extensionsbereich gemappt wird.

Die Extension einer Datenbank bildet den Bereich aller in der Datenbankenthaltenen Instanzen. Die Extension kann auf bestimmte Attribute in einerRelation reduziert werden. Eine solche Projektion auf eine Extension bildet denExtensionsbereich.

Wie auf Abbildung 5.4 zu erkennen ist, kann von Datenbankinstanzen aufOntologie-Instanzen und auf Konzepte der Ontologie gemappt werden. Außerdemkann die Datenbankextension mit Beziehungen zwischen Konzepten gemapptwerden.

44

Abbildung 5.4 Korrespondenzen unter Einbeziehung derInstanzebenen

Die verschiedenen Möglichkeiten der Bildung von Korrespondenzen werden ineigenen Abschnitten erläutert.

5.3.1 Korrespondenzen zwischen Extensionsbereichen undBeziehungen zwischen Konzepten

Das schon beschriebene Mapping von Beziehungen zwischen Konzepten aufRelationennamen oder Attributnamen, kann durch zusätzliche Angaben zu einerMapping-Erstellung auf einen Extensionsbereich E erweitert werden. EineKorrespondenz R E enthält zwei Extensionsbereiche EprojSub und EprojObj, und eineBeziehung r. Die Semantik dieses Mappings ist, dass alle Instanzen in EprojSub alsSubjekt über die Beziehung r mit allen Instanzen in EprojObj als Objekt gemapptwerden.

Zur Verdeutlichung soll ein Beispiel über Berufe dienen. In der Abbildung 5.5 istein Ausschnitt einer allgemeinen Ontologie dargestellt. Der in dieser Ontologiedargestellte Bereich enthält Konzepte die im Extensionsbereich der Datenbank inAbbildung 5.6 als Werte auftauchen.

Abbildung 5.5 allgemeine Ontologie

45

Schule Flugzeug Hubschrauber

PilotLehrerex2:arbeitet_in ex2:arbeitet_inex2:arbeitet_in

Datenbank-instanz

Konzept

Extensionsbereiche

Ontologie-Instanz

Beziehung zwischen Konzepten

beruf arbeitet_in ort

B_ID Name Tätigkeit B_ID O_ID O_ID Bezeichnung Lärmpegel (db)

11 Lehrer Unterrichten 11 21 21 Schule 65

12 Pilot Fliegen 12 22 22 Flugzeug 80

12 23 23 Hubschrauber 11

Abbildung 5.6 Datenbank über Lärmbelastung fürverschiede Berufe

Im Abbildung 5.6 setzt die Relation "arbeitet_in" die beiden Relationen "Beruf"und "Ort" durch die Fremdschlüssel "B_ID" und "O_ID" in N:M Beziehung. DieRelation "arbeitet_in" kann zu der im Abbildung 5.5 gegebenen Beziehung"ex2:arbeitet_in" gemappt werden. Das Mapping unterscheidet sich zum Mappingin 5.2.2, da es nicht auf bestimmte Konzepte als Subjekt und Objekt derBeziehung eingeschränkt wird. Dabei bildet die Beziehung "ex2:arbeitet" eineKorrespondenz zwischen dem Extensionsbereich "Beruf.Name" und"Ort.Bezeichnung". "Beruf.Name" ist somit EprojSub der Korrespondenz und"Ort.Bezeichnung"ist EprojObj der Korrespondenz.

In der XML-Struktur bezeichnet der Inhalt des Tags <ProjectionFrom> denBereich, der das Subjekt der gemappten Beziehung wiedergibt. Dementsprechendist der Inhalt von <ProjectionTo> das Objekt der gemappten Beziehung. In denbeiden Projektionsbereichen wird jeweils ein Attribut, das ein Fremdschlüssel zueiner anderen Relation ist, angegeben. Außerdem wird jeweils derExtensionsbereich über einen Attributnamen definiert.

<DbRelationOntRelationshipMapping><DbRelation name="arbeitet_in" /><OntRelation url="ex:arbeitet_in" /><ProjectionFrom>

<DbAttribute name="B_ID" /><DbRelation name="beruf"> Subjekt

<DbAttribute name="Name" /> Extensions-</DbRelation> bereich

</ProjectionFrom><ProjectionTo>

<DbAttribute name="O_ID" /> Fremdschlüssel<DbRelation name="ort"> Objekt

<DbAttribute name="Bezeichnung" /></DbRelation>

</ProjectionTo></DbRelationOntRelationshipMapping>

XML-Struktur für R E (N:M)

Es ist auch möglich, Informationen über die referenzierten Fremdschlüssel in dasMapping aufzunehmen. Dies ist aber nicht unbedingt erforderlich, da die

46

Informationen auch aus den Datenbank-Metadaten gewonnen werden können. DasAttribut "B_ID", das ein Fremdschlüssel ist, könnte also durch folgende Strukturerweitert werden:

<DbAttribute name="B_ID"><ForeignKeyTo>

<DbRelation name="Beruf"> <DbAttribute name="B_ID" /> </DbRelation>

</ForeignKeyTo></DbAttribute>

XML-Struktur für die Angaben des referenziertenFremdschlüssel eines Attributs

Ein anderer Fall ist, dass eine Erweiterung eines A R zu einem R E gemachtwird. Dies würde anstelle eines N:M Mapping ein 1:N Mapping in der Datenbankausdrücken. Beispielsweise könnte in Abbildung 5.6 "arbeitet_in" direkt in"Beruf" als Attribut mit Fremdschlüssel auf "Ort" vorhanden sein. Für die sogebildete 1:N Beziehung zwischen "Beruf" und "Ort" würde das entsprechendeMapping wie folgt aussehen:

<DbAttributeOntRelationshipMapping><DbRelation name="Beruf">

<DbAttribute name="arbeitet_in" /></DbRelation><OntRelation url="ex:verfasst" /><ProjectionFrom>

<DbRelation name="Beruf"><DbAttribute name="Name" />

</DbRelation></ProjectionFrom><ProjectionTo>

<DbRelation name="Ort"><DbAttribute name="Bezeichnung" />

</DbRelation></ProjectionTo>

</DbAttributeOntRelationshipMapping>

XML-Struktur für R E (1:N)

5.3.2 Korrespondenzen zwischen Datenbankinstanzen undKonzepten

Es ist nicht vorgesehen, das Mapping zwischen Datenbankinstanzen undKonzepten in der XML-Mapping-Syntax darzustellen, da dieses Mapping nichtpersistent gehalten werden soll. Für dieses Mapping, das mit C V bezeichnetwird, wird erst zur Laufzeit versucht eine Korrespondenz zu erstellen. Daher isteine Speicherung wenig sinnvoll. Es gibt zwei Gründe, die für eine solcheVorgehensweise sprechen. Zum einen würde das Mapping einen enormenSpeicherbedarf gebrauchen, da die Größe der Extension einer Datenbankbeträchtlich sein kann und damit auch die Größe der gemappten Instanzen. Ein

47

zweiter Grund ist, dass das Mapping nach jedem Ändern der Datenbank oder derOntologie angeglichen werden müsste. Daher wird jeweils direkt beim Zugriff aufInstanzen in der Datenbank versucht, über einen linguistischen VergleichKonzepte in der Ontologie zu finden, die der Instanz entsprechen.

5.3.3 Korrespondenzen zwischen Datenbankinstanz undOntologie-Instanz

Es ist möglich, ein Mapping zwischen einer Datenbankinstanz und Ontologie-Instanz zu erstellen. Es ist hier anzumerken, dass das Datenbank- zu Ontologie-Mapping, wie es in [2,5] beschrieben wird, dazu entwickelt wurde, ein Mappingvon Datenbankinstanzen zu Ontologieinstanzenen zu erzeugen, indemDatenbankinstanzen in Ontologie-Instanzen überführt werden. Man kann fürdiesen Anwendungsfall also von einem Mapping auf Instanzebene sprechen, auchwenn die Ontologie-Instanzen erst durch das Mapping erzeugt werden. Jedoch istdieses Mapping nur unidirektional von der Datenbankinstanz zur Ontologie-Instanz.

Es ist nicht klar, ob ein bidirektionales Mapping zwischen Datenbankinstanz undOntologie-Instanz eine Anwendung findet. Ein Mapping zwischenDatenbankinstanz und Ontologie-Instanz wird vom ODBT-Prototypen nichtbenötigt, und eine weitere Betrachtung soll in der vorliegenden Arbeit nichtgeliefert werden.

5.4 Zugriffsfunktionen auf das Mapping

Es werden nun die Funktionen definiert, die für den Zugriff auf eine Mapping-Struktur , die das Mapping beinhaltet, benötigt werden. Eine solche Struktur istz.B. die XML-Syntax für ein Mapping zwischen Datenbanken und Ontologien. ist eine Funktion, die auf eine Mapping-Struktur zugreift und auch eineMapping-Struktur zurückliefert. In Tabelle 5.1a sind alle direktenZugriffsfunktionen abgebildet, die atomare Mapping-Strukturen zurückliefern. Siesind atomar, da sie sich nicht mehr in weitere Elemente zerlegen lassen. So liefertbeispielsweise RELm eine Mapping-Struktur mit allen Relationen innerhalbeiner Mapping-Struktur m zurück. Angewendet auf Beispiel 5.2.1 wäre dies eineMapping-Struktur mit den Relationen „Arbeit“, „Wissenschaftler“ und„Forschungseinrichtung“. Durch den Ausdruck ∣∣ werden direkt die Werteinnerhalb der Mapping-Struktur gebildet.

48

Funktion Inhalt der zurückgelieferte Mapping-Struktur

Mapping-Elemente

Ontologie Datenbank

REL Relation X

ATR Attribut X

CON Konzept X

RLS Beziehung X

SBJ Subjekt der Beziehung X

OBJ Objekt der Beziehung X

PRO Eigenschaft X

CLA Klasse der Eigenschaft X

Tabelle 5.1a direkte Zugriffsfunktionen auf atomareMapping-Strukturen

Funktion Inhalt der zurückgeliefertes Mapping-Struktur

Mapping-Elemente

Ontologie Datenbank

PR_FROMProjektionsbereich einer Beziehung voneinem Extensionsbereich X

PR_TOProjektionsbereich einer Beziehung aufeinen Extensionsbereich X

FKEY Fremdschlüsseleintrag X

C R Korrespondenzen zwischen einemKonzept und einer Relation X X

R R Korrespondenzen zwischen einerBeziehung und einer Relation X X

R A Korrespondenzen zwischen einerBeziehung und einem Attribut X X

P A Korrespondenzen zwischen einerEigenschaft und einem Attribut X X

R EKorrespondenzen zwischen einerBeziehung und Extensionsbereichen X X

Tabelle 5.1b direkte Zugriffsfunktionen aufzusammengesetzte Mapping-Strukturen

In Tabelle 5.1b sind die Zugriffsfunktionen verzeichnet, die zusammengesetzteMapping-Strukturen zurückliefern. So liefert z.B. C R eine Mapping-Strukturzurück, die alle Korrespondenzen zwischen Konzepten und Relationen enthält.Die Funktion CON C R würde dann eine Mapping-Struktur mit denKonzepten für Korrespondenzen zwischen Konzepten und Relationen liefern. Ein

49

anderes Beispiel ist, dass eine Mapping-Struktur gefunden werden soll, die alleKorrespondenzen zwischen Attributen und Eigenschaften enthält, für die dasAttribut den Wert „foo“ hat. Dies kann durch P A ∋x ∣ ∣ATR x∣=' foo ' ausgedrückt werden.

In Tabelle 5.1c werden die Zugriffsfunktionen dargestellt, die zusammengesetzteMapping-Strukturen zurückliefern, die indirekt über das Mapping gefundenwerden können. Dies ist nur die Funktion FKEY_REFS , die für einenFremdschlüsseleintrag die referenzierte Mapping-Struktur zurückliefert. Siebeinhaltet den Relationennamen und Attributnamen des Primärschlüssels derreferenzierten Relation. Diese werden über den Metadaten-Katalog des RDBMSerfragt. Alternativ wäre es auch möglich, diese Einträge direkt in die Mapping-Struktur aufzunehmen, wie es auch in 5.3.1 für die XML-Syntax beschriebenwird.

Funktion Inhalt der zurückgeliefertes Mapping-Struktur

Mapping-Elemente

Ontologie Datenbank

FKEY_REFS referenzierte Struktur einesFremdschlüsseleintrags X

Tabelle 5.1c indirekte Zugriffsfunktionen aufzusammengesetzte Mapping-Strukturen

Zuletzt soll noch ein Beispiel gegeben werden, das den indirekten Zugriffveranschaulichen soll. Das Beispiel bezieht sich auf das XML der Mapping-Struktur aus 5.3.1. Auf dieses Mapping wird mitATR FKEY_REFFKEYPR_FROM5.3.1 zugegriffen. Am besten liest man diesenAusdruck von innen nach außen. Die Funktion PR_FROM5.3.1 liefert dieMapping-Struktur, in der die Projektion von der Extension der Datenbank gegebenist. Dieses sind in der XML-Syntax des Mappings die Bestandteile des Tags<ProjectionFrom>. Die Funktion FKEY gibt eine Mapping-Struktur zurück, dieInformationen über den zugehörigen Fremdschlüssel enthält. Mit FKEY wirddas referenzierte Element des Fremdschlüsseleintrags gesucht. Dies ist in demMapping in 5.3.1 nicht vorhanden. Es kann aber mit dem Attribut "B_ID" derRelation "arbeitet_in" über den Datenbankkatalog die referenzierte Relation zudem Fremdschlüssel gefunden werden. Dies ist die Relation "Beruf". Die FunktionATR gibt nun die Mapping-Struktur mit dem Attribut des referenziertenPrimärschlüssels, also das Attribut "B_ID" in der Relation "Beruf". Das hiergezeigte Beispiel ist die tiefst mögliche Verschachtelung von Zugriffsfunktionen,die überhaupt sinnvoll möglich ist.

50

Damit wurden in diesem Abschnitt Methoden für den Zugriff auf Mapping-Strukturen geliefert, die vor allem in der konzeptionellen Umsetzung derAnfragetransformation in Kapitel 7 genutzt werden.

5.5 Beziehungskardinalitäten

In Datenbanken können durch Fremdschlüssel unterschiedlicheBeziehungskardinalitäten ausgedrückt werden. Befinden sich zwei Attribute in dergleichen Relation, stehen sie in einer 1:1 Beziehung zueinander. Besitzt einAttribut einer Relation R1 einen Fremdschlüssel auf einen Primärschlüssel eineranderen Relation R2, so stehen die Attribute in R1 und R2 in 1:N Beziehungzueinander. Umgekehrt stehen die Attribute einer Relation R1, auf derenPrimärschlüssel von einem Attribut einer anderen Relation R2 über einenFremdschlüssel referenziert wird, in N:1 Beziehung zu den Attributen in R2. DieAttribute zweier Relationen R1 und R2, deren Primärschlüssel jeweils überFremdschlüssel einer Relation R3 referenziert werden, stehen in N:M Beziehungzueinander.

Wie noch in 7.3 und 7.4 beschrieben wird, benutzen außer der Vocabulary-Regelalle anderen Regeln eine Korrespondenz R E für die Anfrage-Transformation.Die Extensionsbereiche, die diese Korrespondenz verbinden, stehen in einer deroben genannten Beziehungskardinalitäten. Die Erkennung für die Kardinalitätenfür eine Mapping-Struktur R E , sollen nun gegeben werden. Die Kardinalitätenwerden zwischen Subjekt und Objekt der gemappten Beziehung gebildet.

1:1 Korrespondenzen ( R E(1:1) )Als erste Bedingung muss erfüllt sein, dass beide Projektionsbereiche von R E

(<ProjectionFrom> und <ProjectionTo>) die gleiche Relation, in der dieExtensionen gemappt wird, enthalten:

∣RELPR¿R E∣ = ∣RELPR¿

R E∣Als zweite Bedingung muss erfüllt sein, dass für die Projektionsbereiche keineFremdschlüssel angegeben sind:

FKEYPR_FROMR E=∅ ∧ FKEYPR_TOR E=∅

N:M Korrespondenzen ( R E(N:M) )Die erste Bedingung ist die gleiche wie beim 1:1 Mapping:

∣RELPR¿R E∣ = ∣RELPR¿

R E∣Als zweite Bedingung muss erfüllt sein, dass für die ProjektionsbereicheFremdschlüssel angegeben sind:

FKEYPR_FROMR E≠∅ ∧ FKEYPR_TOR E≠∅

51

1:M Korrespondenzen ( R E(1:M) )Es muss als Bedingung gelten, dass für den Projektionsbereich, der als Subjektgemappt wird (<ProjectionFrom>), kein Fremdschlüssel angegeben wird. Für denProjektionsbereich, der als Objekt gemappt wird (<ProjectionFrom>), muss einFremdschlüssel angegeben sein.

FKEYPR_FROMR E=∅ ∧ FKEYPR_TOR E≠∅

N:1 Korrespondenzen ( R E(N:1) )Es muss als Bedingung gelten, dass für den Projektionsbereich, der als Subjektgemappt wird (<ProjectionFrom>), ein Fremdschlüssel angegeben wird. Für denProjektionsbereich, der als Objekt gemappt wird (<ProjectionFrom>), darf keinFremdschlüssel angegeben sein.

FKEYPR_FROMR E≠∅ ∧ FKEYPR_TOR E=∅

Für die spätere Umsetzung der Transfromationsregeln ist diese Unterscheidungwichtig, da der durch sie erweiterte Ausdruck jeweils unterschiedlich fürverschiedene Kardinalitäten gebildet wird.

5.6 Anwendung des Mapping auf dieTransformationsregeln

Es stellt sich die Frage, ob das hier entwickelte Mapping-Verfahren ausreichendfür die Verarbeitung der Transformationsregeln ist, und alle Anforderungenkomplett abdeckt. Aus diesem Grund werden die im ODBT-Prototyp umgesetztenRegeln nun einzeln anhand ihrer deklarativen formalen Beschreibung analysiert.Die in den folgenden Unterpunkten angegebenen Prämissen sollen vor allem denBezug zur theoretischen Ausarbeitung der Transformationsregeln in [28,30,31] fürdas Mapping herstellen, wo sie umfassend beschrieben werden. Die Umsetzungdieser Regeln wird später noch in 7.3 und 7.4 detailliert erarbeitet. Die Syntax derRegeln aus [30] ist teilweise angepasst worden, da z.B. dort anstelle von dieFunktionen 1 - 4 benutzt wird.

Mapping für die Vocabulary-Regel

Es sei hier die Prämisse der Vocabulary-Regel gegeben, wie sie in [30] formuliertist:

Prämisse (vgl. [30]) IF Q={x1 , ... , xn ∣ x1 , ... , xn ∈ R∧xi t0} and∃co ∈ , c0 , t0 ∈ C V

52

Der Bereich definiert das Mapping zwischen der angefragten Instanz und einemKonzept in der Ontologie. Daher wird für die Vocabulary-Regel kein Mapping aufSchemaebene benötigt. Das einzige Mapping, das erzeugt werden muss, ist daszwischen Datenbankinstanzen und Konzepten. Dieses erfolgt erst zur Zeit derAnfrage.

Mapping für Part-Whole-Regel

Prämisse (vgl. [30])IF Q={ x1 , ... , xn ∣ x1 , ... , xn ∈ R1∧xi t0}and∃c0 ∈ , c0 , t0 ∈ C V

and∃A1 , A2 ∈ FKEYS R2 , R1 ∣ A1 , A2 ∈ R r= "PartOf"and∀ ci∈ , ci≠c0 , PARTs c0⊄PARTs ci

In der Prämisse der Part-Whole-Regel werden zwei verschiedene Mappingsbenutzt. Zum einen wird schon wie in der Regel 1 mit c0 , t0 ∈ CV einMapping zwischen Instanz und einem Konzept in der Ontologie benutzt. Mit∃A1 , A2 ∈ FKEYS R2 , R1 ∣ A1 , A2 ∈ R E= "PartOf" wird ein Mappingzwischen einem Paar von Attributen, das über zwei Fremschschlüsselverweiseeiner Relation referenziert wird, mit einer Part-Of Beziehung gemappt. Dies istäquivalent zu dem in 5.3.1. erläuterten Mapping zwischen einer Extension undeiner Beziehung zwischen Konzepten für eine N:M Kardinalität.

Mapping für Support-Regel

Prämisse (vgl. [30])IF Q={xi ∣ x1 , ... , xn ∈ U R ∧ x p t0}and∃c0 ∈ , c0 , t0 ∈ C V

and∃Ai , A p ∈ U ,Ai , Ap ∈ R E= "PartOf"

Wie schon in Regel 1 und Regel 2 muss ein Mapping zwischen einer Instanz undeinem Konzept in der Ontologie gebildet werden , was durch c0 , t0 ∈ C V

ausgedrückt wird. Das Mapping, wie es in∃Ai , Ap ∈ U ,Ai , Ap ∈ R E= "PartOf" definiert wird, gestaltet sich etwasanders als in der Vocabulary-Regel da es für eine 1:1 Kardinalität definiert wird.Es ist aber auch ein Mapping zwischen Extensionsbereich und Beziehungenzwischen Konzepten. Auch für diese Regel wird - wie schon in der Part-Whole-Regel - das Mapping auf die PartOf-Beziehung eingeschränkt.

53

Mapping für die Feature-Regel

Prämisse (vgl. [30])IF Q={ x1 , ... , xn ∣ x1 , ... , xn ∈ R1∧xi t0}and∃c0 , c p ∈ , c0 , t0 ∈ C V∧c p , Ap ∈ C A

and∃Ai , ... , A j ∈U R ∣ Ak , t0 ∈ C A∧A p , Ak ∈ R E∈and∃c p ∈ ∣ cq=Rparent " ISAspecific " , c0and∃c0 ∈ SUBT c p∩SUBT ck

Für die Feature-Regel wird zunächst - wie in den anderen Regeln auch - mitc0 , t0 ∈ C V eine Instanz auf ein Konzept gemappt. Mit A p , Ak ∈ R E

findet ein Mapping auf einen Extensionsbereich statt. Außerdem wird einMapping zwischen Konzepten und Attributen mit Ak t0 ∈ C A für die Regelbenötigt.

Mapping für die Sensitivity-Regel

Prämisse (vgl. [28])IF Q={ x1 , ... , xn ∣ x1 , ... , xn ∈ R1∧xi t0}and∃c0 ∈ , c0 , t0 ∈ C V

and∃Ai ∈ U ,c0 , A p ∈ R E

Die hier dargestellte Sensitivity-Regel bezieht sich auf ein Mapping für Relationenmit 1:1 Kardinalitäten. Außer dem auch in dieser Regel vorhanden Mappingc0 , t0 ∈ C V zwischen Konzepten und Instanzen werden die Konzepte mitand∃Ai ∈ U ,c0 , A p ∈ R E zu einem Extensionsbereich gemappt.

Damit wurden alle in dieser Arbeit umgesetzten Transformationsregeln in Bezugauf das Mapping betrachtet. Es wird festgestellt, dass das in diesem Kapitelbeschriebene Mapping ausreicht, um den Funktionsumfang derTransformationsregeln abzudecken.

54

5.7 Zusammenfassung

Das Mapping zwischen Ontologie und Datenbank ist eine wichtige Komponentefür die spätere Umsetzung der ontologie-basierten Anfragetransformation. Indiesem Kapitel wurde eine Mapping-Struktur in XML-Syntax entwickelt, umElemente zwischen einer Ontologie und einer Datenbank zu referenzieren. Diemöglichen Korrespondenzen zwischen Datenbank und Ontologie, die in einerMapping-Struktur angegeben werden können, sind in Tabelle 5.2 zu sehen.

Korrespondenz Ontologie Datenbank PersistentC R∈C R⊆ Konzept Relation JA

R R∈R R⊆ Beziehung Relation JA

R A∈R A⊆ Beziehung Attribut JA

P A∈P A⊆ Eigenschaft Attribut JA

C V∈C V⊆ Konzept Instanz NEIN

R E∈R E⊆ Beziehung Extensionsbereich JA

Tabelle 5.2 Übersicht von möglichen Korrespondenzenzwischen Ontologie und Datenbank

Für die Mapping-Struktur wurden die Funktionen angegeben, mit denen esmöglich ist, Informationen aus der Mapping-Struktur zu extrahieren. Im weiterenwurden für R E Bedingungen gegeben, die es erlauben Korrespondenzen aufKardinalitäten einzuschränken. Zuletzt wurde anhand der Transformationsregelngeprüft, inwieweit das Mapping die Anforderungen des ODBT-Prototypenabdeckt.

55

Kapitel 6

Semiautomatische Verfahren zumErstellen eines Mapping

Es ist zwar möglich, ein Mapping rein manuell zu erstellen, jedoch ist dies einezeitaufwendige und auch fehlerhafte Herangehensweise. In diesem Kapitel sollenzunächst verschiedene Mapping-Verfahren gegenübergestellt werden. Danachwerden die geeigneten Verfahren zur Erstellung eines Mappings ausgewählt.Zusätzlich werden algorithmische Modelle vorgestellt, die es erlauben, einerelationale Datenbank mit einer mit RDF modellierten Ontologie semiautomatischzu erstellen.

6.1 Beschreibung verschiedener Mapping-Verfahren

Es sollen nun in Anlehnung an die Ausführungen in [33] die grundlegendenVerfahren zur Erstellung eines Mappings erläutert werden, aus denen dann spätereines für die Umsetzung in einem eigenen Ansatz ausgewählt wird. DieAbbildung 6.1 zeigt eine Übersicht über die möglichen Mapping-Verfahren und inwelcher Kombination sie angewendet werden können. Die einzelnen Bestandteiledieser baumartigen Übersicht werden im weiteren näher erläutert. Die Übersichtverdeutlicht gut, wie sich existierende Methoden aus den einzelnen Verfahren zurMapping-Erstellung zusammensetzen lassen. Alle Ansätze, die im folgendenerläutert werden, bedürfen der endgültigen Abstimmung mit einemDomänenexperten, sind also semiautomatisch.

Jede potenziell gefundene Korrespondenz muss jeweils zum Abgleich vorgelegtund verifiziert werden. Eine rein automatische Erstellung eines Mappings wärezwar möglich, aber extrem fehlerträchtig. Bezüglich des ODBT-Prototypen istdies jedoch eine Option, da die Anfragen an die Datenbank durch dieTransformation keinen absoluten Anspruch auf Korrektheit bezüglich derErgebnisse einer Anfrage haben können.

56

Abbildung 6.1 Übersicht der Benutzung verschiedenerMapping-Verfahren

6.1.1 Nutzen von Instanz- oder Schemainformationen

Es wird unterschieden, ob mögliche Mapping-Konstellationen durch die Analysevon Instanz- oder Schemainformationen gewonnen werden können. DieTerminologie mag an dieser Stelle etwas verwirrend sein, da beide Ansätzesowohl unter Einbeziehung von Instanz- sowie Schemainformationen einvollständiges Mapping, wie es in Kapitel 5.2. und 5.3. beschrieben wurde,erstellen können, also ein Mapping auf Instanz- und Schemaebene. DieUnterscheidung zwischen Instanz- und Schemainformationen bezieht sich somitnur darauf, welche dieser beiden Informationen verwendet werden kann, um dasMapping zu erstellen.

Die Mapping-Erstellung mit Schemainformationen basiert auf der reinen Analysevon Schemainformationen, wobei die Instanzdaten ignoriert werden. DieSchemainformationen enthalten die Namen von Elementen, Typdefinitionen (z.B.String, Date), Abhängigkeitsinformation und Schema-Strukturinformationen fürdas jeweilige Datenbank- oder Ontologie-Schema.

57

Mappingverfahren

Nutzung von Schemainformationen

Nutzung von Instanzinformationen

Mappen von ElementenMappen von

zusammengesetzten Strukturen

Mappen von Elementen

Linguistische Methoden

z.B. · Namens- gleichheit· Beschreibungs- gleichheit· globale Namensräume

Methoden basierend auf Abhängigkeiten

z.B. · Typgleichheit· Schlüssel- eigenschaften

Methoden basierend auf Abhängigkeiten

z.B.· Graf Mapping

Linguistische Methoden

z.B.Techniken der Informations- gewinnung (Worthäufig- keiten, Schlüssel- wörter)

Methoden basierend auf Abhängigkeiten

z.B.· Wertebereiche und Muster

Bei der Mapping-Erstellung mit Instanzinformationen wird versucht, aus derExtension der Datenmenge eines Schemas nützliche Informationen für dasMapping zu ziehen. Dies kann einerseits die Mapping-Erstellung mitSchemainformationen komplett ersetzen, oder aber einen zusätzlichenInformationsgewinn bei gleichartig plausibler Mapping-Erstellung durchSchemainformationen bringen. Dabei wird versucht, dass solche Schemaelementegemappt werden, deren Instanzdaten eine größtmögliche Ähnlichkeit aufweisen.

6.1.2 Mapping von einzelnen Elementen oderzusammengesetzten Strukturen

Eine weitere Unterscheidung ist die Mapping-Erstellung für unterschiedlicheEbenen der Granularität von Elementen. Der unterste Level der Granularität wirdals atomarer Level bezeichnet. Hierzu gehören z.B. in Datenbanken dieAttributnamen und in Ontologien die Eigenschaften von Konzepten, da es fürbeide keine Elemente niedrigerer Granularität gibt, aus denen siezusammengesetzt sind.

Alle höheren Ebenen der Granularität werden als zusammengesetzte Strukturendefiniert. Dieses sind z.B. in Datenbanken Relationennamen, Views oderDatenbanknamen. In Ontologien sind dies unter anderem Konzepte.

Die Erstellung eines Mappings kann über Bottom-Up oder Top-Down Methodendurchgeführt werden. Beide Ansätze bieten in gewisser Weise Vorteile, und es istnicht immer eindeutig, welche von beiden Möglichkeiten zu bevorzugen ist.Trotzdem wird die Top-Down-Herangehensweise im Allgemeinen als dieVariante betrachtet, die geringere Kosten verursacht [33].

Beim Top-Down-Verfahren wird zunächst versucht, dass zusammengesetzteStrukturen höherer Granularität gemappt werden, um dann abwärts zu denelementaren Elementen zu gelangen und dort ein Mapping zu finden. Der Vorteilbei Top-Down besteht in diesem Fall darin, dass die Suche der unterliegendenElemente niedrigerer Granularität auf den Bereich der Mapping-Elemente höhererGranularität eingeschränkt werden kann. Dies soll nun kurz anhand einesBeispiels verdeutlicht werden.

Die Relation "Wissenschaftler" der Datenbank aus Abbildung 5.3 wird zunächstmit dem Konzept "ex:Akademiker" der Ontologie in Abbildung 5.2 gemappt.Beim Mapping des Attributs "ex:Name" in der Relation "Wissenschaftler" kannsich nun in der Ontologie auf die Eigenschaften des Konzeptes "ex:Akademiker"beschränkt werden, um dort ein Mapping zu finden. Da die Eigenschaft"ex:Name" des Konzepts "ex:Akademiker" dort gemappt werden kann, entfällt einweiterer Vergleich für Eigenschaften anderer Konzepte als "ex:Akademiker". Die

58

Elemente niedrigerer Granularität können somit schneller gemappt werden. DieTop-Down Methode wird in den in 6.2 beschriebenen Algorithmen zursemiautomatischen Mapping-Erstellung angewendet.

Bei der Bottom-Up-Methode werden zunächst Elemente niedrigerer Granularitätgemappt, um dann die Mapping-Erstellung auf Elemente höherer Granularitätfortzuführen. Auch diese Herangehensweise hat ihre Vorteile, da z.B.Eigenschaften in Ontologien leichter zu Attributen in Datenbanken zugeordnetwerden können. Auch dies soll anhand eines Beispiels erläutert werden. DasAttribut "Titel" aus der Relation "Arbeit" in Abbildung 5.3 wird zunächst mit derEigenschaft "ex:Titel" des Konzeptes "ex:Arbeit" gemappt. Beim Übergang zuElementen höherer Granularität, also zu Relationen und Konzepten, kann nun ausdem vorhandenen Mapping geschlossen werden, dass das Konzept "ex:Arbeit" aufdie Relation "Arbeit" gemappt wird.

6.1.3 Verwendung von Elementbezeichnern oder vonAbhängigkeiten

Ein Beispiel für diese Verwendung von Abhängigkeiten wurde bereits - ohne es zuerwähnen - im letzten Abschnitt geliefert. Beim Bottom-Up-Ansatz wurdebeschrieben, dass das Konzept "ex:Arbeit" und die Relation "Arbeit" aus bereitsgemappten unterliegenden Elementen gefolgert werden können. Dies ist einBeispiel für ein Mapping unter Verwendung von Abhängigkeiten. Ein Mappingbasierend auf Elementbezeichner wäre es, wenn die Relation "Arbeit" und dasKonzept "ex:Arbeit" nur aufgrund eines linguistischen Abgleichs derElementbezeichner erfolgt wäre.

Bezüglich des Vergleichs von Elementbezeichnern können verschiedenelinguistische Verfahren angewandt werden, die hier aber nicht näher erläutertwerden sollen. Für diese Arbeit soll ein Vergleich auf Namensäquivalenzgenügen.

Abhängigkeiten können in vielfacher Weise verwendet werden, um Mappings zuerstellen. Generell enthalten Schemata Abhängigkeitsinformationen, die sich aufDatentypen, Wertebereiche, Einzigartigkeiten, Relationentypen, Kardinalität usw.beziehen. Wenn beide Schemata ähnliche Abhängigkeitsverhältnisse besitzen, dieauf eine Gleichartigkeit des Schemas bzw. der Instanzdaten schließen, könnendiese zur Bildung eines Mappings benutzt werden.

In relationalen Datenbanken werden Beziehungen über referentielleIntegritätseigenschaften, also Fremdschlüsselbeziehungen, ausgedrückt. Eine N:MBeziehung wird ausgedrückt, indem eine eigene Relation gebildet wird, die zweiandere Relationen über jeweils einen Fremdschlüssel miteinander verbindet. Es ist

59

daher möglich, mit dem Wissen über die Fremdschlüsselbeziehung und denbereits gebildeten Korrespondenzen, ein Mapping zwischen Konzepten undRelationen zu finden. Eine algorithmische Beschreibung zur Bildung desMappings von Beziehungen zwischen Konzepten in einer Ontologie undRelationen in Datenbanken folgt in 6.2.2. Auch bei über einen Fremdschlüsselgebildeten 1:N oder N:1 Beziehungen in der Datenbank ist es möglich, einMapping zwischen Attributnamen in der Datenbank und Beziehungen zwischenKonzepten in gleicher Weise zu finden.

Ein anderes Abhängigkeitsverhältnis, das für die Mapping-Erstellung zwischenDatenbank und Ontologie genutzt werden kann, ist die Einschränkung aufbestimmte Wertebereiche. Attributinstanzen in relationalen Datenbanken sinddurch die Angabe eines Datentyps auf einen bestimmten Wertebereich festgelegt.Analog dazu können in Ontologien, so z.B. in RDF(S), über den Identifikator"rdfs:range" Wertebereiche eingeschränkt werden. Möglich wäre esbeispielsweise, dass Attributnamen, deren Wertebereiche mit dem Datentyp vonSQL "DATE" eingeschränkt sind, nur mit solchen Eigenschaften von Konzeptengemappt werden, die mit "rdfs:range" auf den Bereich "xsd:date" eingeschränktsind. Wie hier zu erkennen ist, gibt es keine vordefinierten Typen in RDF(S) undOWL, auf die über "rdfs:range" eingeschränkt werden kann; anstelle dessen wird"xsd:date" verwendet. Es bedarf daher einiges an Vorkenntnis über dieTypinformationen in RDF(S) und OWL.

6.1.4 Mapping unterschiedlicher Kardinalität zwischenElementen

Zwei Schema-Elemente können in unterschiedlicher Kardinalität zueinandergemappt werden. Die Kardinalität drückt aus, wie viele der Elemente einesSchemas jeweils zu wie vielen Elementen eines anderen Schemas gemapptwerden. Dies sollte aber nicht verwechselt werden mit der Kardinalität, die in6.1.3 für Beziehungen in Datenbanken angegeben wurde. Es ergeben sich diebekannten Beziehungskardinalitäten 1:1, 1:N, N:1 und N:M. Der am häufigstenverwendete Fall ist das Mapping von 1:1 Kardinalitäten zwischen Elementen. Allebisher in diesem Kapitel gebrauchten Beispiele drücken 1:1 Kardinalitäten aus.Ein Beispiel für ein 1:N Mapping wäre eine Relation "Ware(Preis, Steuer)" undeine Ontologie, die das Konzept "ont:Ware" und die Eigenschaft "ont:Preis" desKonzeptes Ware hätte. Preis in der Ontologie könnte mit "ont:Preis = Ware.Preis*(Ware.Steuer/100)" gemappt werden. Es werden also zwei Attribute mit nur einerEigenschaft der Ontologie gemappt. Ein solches Mapping kann z.B. bei derÜberführung von Instanzdaten von der Datenbank zur Ontologie sinnvoll sein.

In der vorliegenden Arbeit soll sich auf die Mapping-Erstellung mit Hilfe von 1:1Kardinalitäten zwischen Elementen beschränkt werden.

60

6.1.5 Nutzung von Zusatzinformationen

Die in vielen Schemata enthaltenen Kommentare in natürlicher Sprache könnenauch für die Mapping-Erstellung Verwendung finden. Über linguistischeMethoden ist es möglich, Ähnlichkeiten bezüglich der Kommentare zu finden undsomit das Mapping zu erstellen. In Ontologien gibt es die Möglichkeit einezusätzliche Beschreibung von Elementen anzugeben, um sie für den Betrachterverständlicher zu machen. In relationalen Datenbanken wie z.B. DB2 existierenauch Möglichkeiten, zusätzliche Metadateninformationen zur Beschreibung vonSchemaelementen anzugeben. Es wäre daher durchaus möglich, dieseZusatzinformationen für den Erhalt von Korrespondenzen zu verwenden. Jedochwird in dieser Arbeit auf die Verwendung dieses Ansatzes für die algorithmischenVerfahren zur Mapping-Erstellung verzichtet.

6.2 Algorithmische Methoden für die Erstellung vonMapping-Strukturen

Aus Konzepte aus den bisherigen vorwiegend allgemein gehaltenenUnterscheidungen der Verfahren zur Mapping-Erstellung, werden nun teilweisebenutzt, um geeignete Algorithmen zum Erstellen des Mappings ont_db zuformulieren. Dazu wird auf die Bildung der Korrespondenzen in eigenenAbschnitten eingegangen. Die Algorithmen bauen aufeinander auf und könnenzum Schluss zu einem generellen Algorithmus zusammengefasst werden. Die hiervorgestellten Algorithmen versuchen, eine Korrespondenz von Elementen in einerDatenbank zu Elementen in einer Ontologie zu finden. Die Elemente derDatenbank werden somit iterativ für verschiedene Ebenen der Granularitätdurchlaufen. Daher wird die Mapping-Erstellung in der ReihenfolgeRelationennamen, Attributnamen, Extensionsbereich vollzogen. Es wird also einTop-Down-Verfahren angewendet.

6.2.1 Unterscheidung von abhängigen undzusammengesetzten Relationen

In [19] wird eine wichtige Klassifizierung zur Unterscheidung von Relationengeliefert. Es wird in Basisrelationen, abhängige Relationen und zusammengesetzteRelationen unterschieden. Diese Unterscheidung ist für das weitere Vorgehen sehrhilfreich und soll kurz erläutert werden. Eine ausführlichere Beschreibung mitBeispielen ist in [1] zu finden.

61

Basisrelation: Ist eine Relation unabhängig von anderen Relationen imDatenbankschema, wird sie als Basisrelation Rbas⊂R bezeichnet.

Abhängige Relation: Ist ein Primärschlüssel einer Relation abhängig von einemPrimärschlüssel einer anderen Relation, wird die Relation als abhängig

Rdep⊂R bezeichnet.

Zusammengesetzte Relation: Alle anderen Relationen Rcomp⊂R fallen unterdiese Kategorie.

Aufbauend auf dieser Kategorisierung sollen nun die Algorithmen zum Erstellenvon Korrespondenzen aufgebaut werden.

6.2.2 Mapping-Erstellung für Relationennamen undKonzepte

Jede Relation, die nicht in Rdep ist, wird versucht mit einem Konzept in Cgemappt zu werden.

01 foreach (r in Rbas∪Rcomp ) {02 foreach(c in C) {03 if (linguistischer_Vergleich(r, c) == true) {04 // linguistische Übereinstimmung05 if (bestätige_Mapping(r, c)) {06 // Benutzeranfrage erfolgreich07 erstelle_neue_Mapping_Referenz(r, c);08 }09 }10 }11 erfrage_Konzept(r);12 }

Algorithmus 6.1 Erstellen von C R

Der hier gelieferte Algorithmus vergleicht linguistisch durch die Funktion"linguistischer_Vergleich()" iterativ alle nicht Basisrelationen undzusammengesetzten Relationen. Wird eine Übereinstimmung gefunden, wirddurch die Funktion "bestätige_Mapping()" der Benutzer aufgefordert, dasgefundene Mapping zu verifizieren. Für jeden Relationennamen wird der Benutzerzusätzlich aufgefordert selbst ein Mapping über "erfrage_Konzept(r)" für denRelationennamen anzugeben. Durch die Funktion"erstelle_neue_Mapping_Referenz()" wird eine Verknüpfung zwischen Konzeptund Relation als Korrespondenz in das Mapping aufgenommen. Die Umsetzungder Funktion "linguistischer_Vergleich()" soll hier nicht weiter betrachtet werden.Der Algorithmus hat eine Laufzeit von O( ∣Rbas∪Rcomp∣∣C∣ ), da sowohl über alle

62

Konzepte als auch alle Relationennamen iteriert wird.

6.2.3 Mapping-Erstellung für Relationennamen undBeziehungen zwischen Konzepten

Jede Relation, die eine abhängige Relation in Rdep ist wird versucht mit einerBeziehung in R gemappt zu werden:

01 foreach (r in Rdep ) {02 foreach(r in R) {03 if (linguistischer_Vergleich(r, r) == true) {04 // linguistische Übereinstimmung05 if (bestätige_Mapping(r, r)) {06 // Benutzeranfrage erfolgreich07 erstelle_neue_Mapping_Referenz(r, r);08 }09 }10 }11 erfrage_Beziehung(r);12 }

Algorithmus 6.2a Erstellen von R R

Der Algorithmus 6.2a ist analog zum Algorithmus 6.1. aufgebaut. Die Laufzeit istO ∣Rdep∣∣R∣ . Er ist jedoch so noch nicht optimal, da er die bereits vorhandenenKorrespondenzen aus der Verarbeitung des Algorithmus 6.1 von Konzepten undRelationen nicht einbezieht. Er ist außerdem nicht vollständig, da nicht eindeutigist, welche Konzepte in der Ontologie miteinander in Beziehung gesetzt werden.Es soll nun eine Mapping-Erstellung in Bezug auf Abhängigkeiten (vgl. 6.1.3.)vorgenommen werden.

Der Algorithmus 6.2b sucht in Zeile 2 für jede Relation in Rdep diejenigenRelationen, die über einen Fremdschlüsseleintrag verbunden sind. Die Funktion"finde_gemappte_Konzepte_zu_Relationen()" in Zeile 3 versucht, die auf dieRelationen gemappten Konzepte durch die bereits erstellten KorrespondenzenC R zu finden. Diese Funktion kann mit Hilfe der Zugriffsfunktionen aufKorrespondenzen mit ∀ r∈R∃c∈C ∣ ∣CON C R ∋x ∣ ∣REL x ∣=r ∣gebildet werden. Werden genau zwei solche gemappten Konzepte gefunden (Zeile5), wird versucht Beziehungen in der Ontologie zwischen diesen beidenKonzepten zu suchen. Für jede dieser Beziehungen wird dann in Zeile 16 übereinen Abgleich mit dem Benutzer die Korrektheit erfragt. In Zeile 17 wird danndie Korrespondenz mit der Funktion "erstelle_neue_Mapping_Referenz()" demMapping zugefügt. Wie zu erkennen ist, werden im Vergleich zum Algorithmus6.2a auch die in Beziehung gesetzten Konzepte übernommen.

63

01 foreach (r in Rdep ) {02 Rfkey := Fremdschlüssel-Relationen in r;03 Cfkey := finde_gemappte_Konzepte_zu_Relationen(Rfkey);0405 if (size(Cfkey) != 2) {06 return;07 }0809 c1 := Cfkey[[0];10 c2 := Cfkey[[1];11 12 Rfkey := finde_Beziehungen_zwischen_Konzepten(c1, c2);1314 foreach (r in Rfkey) {15 if (bestätige_Mapping(r, r)) {16 // Benutzeranfrage erfolgreich17 erstelle_neue_Mapping_Referenz(r, c, c1, c2);18 }19 }20 }

Algorithmus 6.2b Erstellen von R R mit Einbeziehungvon C R

Es sei darauf verwiesen, dass dieser Algorithmus keinerlei linguistischenVergleich macht, und somit unterschiedliche Benennungen zwischen Ontologieund Datenbank nicht relevant sind. Wichtig ist aber, dass das bereits vorhererstellte C R Mapping möglichst korrekt ist, da sich Fehler innerhalb diesesMapping sonst in den Algorithmus 6.2b weiter vererben können. Die Laufzeit desAlgorithmus ist O( ∣Rdep∣∣R fkey∣ ), wobei R fkey ⊆ R .

6.2.4 Mapping-Erstellung für Attributnamen undBeziehungen zwischen Konzepten

Analog zu den vorangegangen Algorithmen zur Erstellung von Korrespondenzensoll auch hier ein Algorithmus basierend auf einfachen linguistischen Vergleichengegeben werden. Jede Relation, die keine Basisrelation Rbas ist, wird versucht miteinem Attribut a der Relation r gemappt zu werden.

Der Algorithmus 6.3a übernimmt nicht die in der Ontologie durch die Beziehungverknüpften Konzepte in die Korrespondenzen, und ist daher nicht vollständig. Eswird also nur ausgedrückt, dass eine Beziehung mit einem Attribut gemappt wird,es fehlt aber die Information, welche Konzepte diese Beziehung verbindet.

Wie in 6.1.2.3 können auch für das Erstellen von R A die bereits erstelltenKorrespondenzen von C R genutzt werden, um den Algorithmus zu erweitern.

64

01 foreach (r in Rdep∪Rcomp ) {02 foreach(Beziehung r in R) {03 foreach (Attribut von a in r) { 04 if (linguistischer_Vergleich(a, r) == true) {05 // linguistische Übereinstimmung06 if (bestätige_Mapping(a, r)) {07 // Benutzeranfrage erfolgreich08 erstelle_neue_Mapping_Referenz(a, r);09 }10 }11 erfrage_Beziehung(a);12 }13 }14 }

Algorithmus 6.3a Erstellen von R A

01 foreach (r in Rdep∪Rcomp ) {02 c1 := Mappe_Relation_zu_Konzepten(r);0304 if (cfkey == null)05 return;0607 foreach (Attribut a von r und a ist Fremdschlüssel){ 08 rfkey := Relation des Fremdschlüsselverweises von a09 cfkey := Mappe_Relation_zu_Konzepten(rfkey);10 11 if (cfkey == null)12 return;13 14 Rfkey := finde_Beziehungen_zwischen_Konzepten(c1, cfkey);1516 foreach (Beziehung r in Rfkey) {17 if (bestätige_Mapping(a, r)) {18 // Benutzeranfrage erfolgreich19 erstelle_neue_Mapping_Referenz(a, r, c1, cfkey);20 }21 }22 }23 }

Algorithmus 6.3b Erstellen von R A mit Einbeziehungvon C R

Der neue Algorithmus 6.3b iteriert über alle Relationen der Datenbank und suchtfür alle Attribute, die einen Fremdschlüsseleintrag darstellen, die referenziertenRelationen. Für die referenzierten Relationen und die Relationen, über die iteriertwird, werden die in C R gemappten Konzepte bestimmt (Zeile 2, 9). Existierendieses Konzepte, werden in Zeile 14 über die Funktion "isRelationshipOf()" alleBeziehungen in der Ontologie gesucht, die über die gemappten Konzepte inBeziehung stehen. Für jede gefundene Beziehung wird dann in Zeile 17 über einenAbgleich mit dem Benutzer die Korrektheit des Mappings vom Benutzer erfragt.Der Algorithmus hat eine Laufzeit von O( ∣R∣∣R fkey∣ ) wobei R fkey ⊆ R .

65

6.2.5 Mapping-Erstellung für Attributnamen undEigenschaften von Konzepten

Der naive Algorithmus zum Erstellen der Korrespondenzen zwischenAttributnamen und Eigenschaften von Konzepten, ist das Iterieren über alleAttribute und alle Eigenschaften von Konzepten. Hier soll nur der Algorithmusdargestellt werden, der die erstellten Korrespondenzen C R bereits einbezieht.

01 foreach (r in R) {02 c1 := Mappe_Relationen_zu_Konzepten(r);0304 if (c1 == null)05 return;0607 foreach (Attribut a von r) { 13 foreach(p liegt im Domänenbereich von c1) {14 if (bestätige_Mapping(a, p)) {16 erstelle_neue_Mapping_Referenz(a, p, c1);17 }18 }19 erfrage_Attribut(a);20 }

Algorithmus 6.4 Erstellen von P A mit Einbeziehungvon C R

Der Algorithmus iteriert über alle Relationen in der Datenbank und findetzunächst über das bereits erstellte C R die gemappten Konzepte in der Ontologie.Es werden dann alle Eigenschaften des gemappten Konzeptes in der Ontologie mitallen Attributen der Relation dem Benutzer zum Abgleich für ein möglichesMapping vorgelegt.

Es ist zu erkennen, dass dieser Algorithmus noch problematisch ist, da die Anzahlder dem Benutzer vorgelegten Mapping-Möglichkeiten sehr hoch ist. EineMöglichkeit wäre ein linguistischer Vergleich zwischen Attributen undEigenschaften. Dieses Vorgehen ist aber sehr fehlerträchtig, da oftunterschiedliche Bezeichnungen in der Ontologie und der Datenbank vorhandensind. Eine attraktivere Möglichkeit erscheint die Einbeziehung von Typgleichheit,wie es in Abbildung 6.1 dargestellt ist. So kann z.B. nur von Attributen mit denSQL-Typen "VAR", "VARCHAR" und "LONGVARCHAR" auf Eigenschaftender Ontologie, deren Wertebereich "rdf:range" dem Typ "rdf:literal" zugeordnetist, gemappt werden. Ein anderes Beispiel wäre, dass Attribute mit dem SQL-Typ"DATE" nur mit Eigenschaften der Ontologie mit dem Wertebereich "xsd:date"gemappt werden sollten.

66

6.2.6 Mapping für Extensionsbereich und Beziehungenzwischen Konzepten

Als letztes wird nun ein Algorithmus für ein Mapping zwischenExtensionsbereich und Beziehungen zwischen Konzepten vorgestellt. Für dieErstellung einer Korrespondenz R E ist es nötig, dass die Instanzdaten in derDatenbank betrachtet werden. Da die Erstellung von R E komplexer ist als diebisher beschriebenen Mapping-Erstellungen, soll auf eine Darstellung in Pseudo-Code verzichtet werden. Die Vorgehensweise wird anhand von sieben Schrittenerklärt, wobei auf die einzelnen Schritte später noch näher eingegangen wird.

(1)Es sei zunächst Ea der Extensionsbereich eines Attributs a. In Ea werdenalle Instanzen mit unterschiedlichen Namen auf Konzepte Ca aus derOntologie gemappt.

(2)Für alle c∈C a werden die Beziehungen Robj a gesucht für die c alsObjekt vorkommt. Gleichfalls werden alle Beziehungen Rsbj a gesucht fürdie c als Subjekt vorkommt.

(3)Dieses Verfahren wird für alle a1 , ... , ai∈A angewendet. Somit besitztjedes Attribut die Beziehungen Robj ak und Rsbj ak für die es potentiell alsSubjekt oder als Objekt für eine Beziehung gemappt werden kann.

(4)Für alle bereits gebildeten Korrespondenzen R R∈R R werden diegemappten Beziehungen rlsRR (durch die Zugriffsfunktion RLSR R ) unddie gemappten Relationen relRR (durch die Zugriffsfunktion RELR R )erstellt.

(5)Es ist nun möglich, dass die Extensionsbereiche der Attribute mit denBeziehungen gemappt werden. Der Extensionsbereich zweier Attribute a1

und a2 wird als eine R E Korrespondenz erstellt, wennRsbj a1

=rlsR R∧Robj a2=rlsR R . Durch das 4-Tupel (relRR, rlsRR a1, a2)

werden die Elemente in R E gebildet. Damit ist das Mapping für N:MKardinalitäten der Korrespondenzen gebildet.

(6)Für alle bereits gebildeten Korrespondenzen R A∈R A werden diegemappten Beziehung rlsRR (durch die Zugriffsfunktion RLSR R ) unddie gemappten Attribute atrRR (durch die Zugriffsfunktion ATR R R )erstellt.

(7)Es ist nun möglich, dass die Extensionsbereiche von A mit R gemapptwerden. Eine Korrespondenz mit 1:N Kardinalität wird erstellt, wennfür ein Attribut a gilt Rsbj a1

=rlsR R∧a=atr R R . Analog wird eineKorrespondenz für eine N:1 Kardinalität mit Robj a1

=rlsR R∧a=atr R R

erstellt. Durch das 2-Tupel (rlsRR , a) werden die Elemente in R E

gebildet. Damit ist die Mapping-Erstellung für R E komplett.

67

Es sollen nun einige Bemerkungen zu der hier gegebenen Vorgehensweisegemacht werden. Das in (1) gegebene Mapping sollte für große Datenbeständemöglichst automatisiert geschehen, da die Validierung durch einenDomänenexperten nicht praktikabel erscheint. Der in (5) gegebene sehrkostenintensive Vergleich Rsbj a1

=rlsR R∧Robj a2=rlsR R , der für jede Beziehung

durchgeführt wird, bietet noch Optimierungspotenzial indem z.B. dieBeziehungen auf Rsbj a1

, ... , Rsbj an∪Robj a1

∪Robj an eingeschränkt werden.

Der hier gegebene Algorithmus sollte als naiver Algorithmus betrachtet werden,der noch keine Optimierungen bezüglich von Laufzeiteigenschaften macht.Aufgrund der Komplexität soll die Entwicklung eines verbesserten Algorithmusnicht Bestandteil der vorliegenden Arbeit sein.

6.3 Zusammenfassung der semiautomatischenMapping-Erstellung

In diesem Kapitel wurde eine ausführliche Analyse des semiautomatischenErstellens von Korrespondenzen gegeben. Dabei kamen für die unterschiedlichenMapping-Konstellationen verschiedene Methoden zur Anwendung. DieAlgorithmen, wie sie hier gegeben sind, sollen als Basis für eine spätereImplementierung dienen, die im Rahmen dieser Diplomarbeit noch nichtumgesetzt wurde. Die Erstellung der Korrespondenzen für den ODBT-Prototypengeschieht bisher rein manuell.

Abbildung 6.2 Reihenfolge der Mapping-Erstellung

68

Verwendung von Schlüsseleigenschaften

RRVerwendung von

Schlüsseleigenschaften

RA

Vergleich auf Worthäufigkeiten

Rr

Verwendung von Typgleichheit

PA

Linguistische Methoden

CR

Die Abbildung 6.2 zeigt noch einmal in einer Übersicht, wie die einzelnenMethoden der Mapping-Erstellung aufeinander aufbauen. Es ist zu erkennen, wiein Kapitel 6.1.2 beschrieben, dass ein Top-Down-Verfahren zur Anwendungkommt, in dem zunächst Elemente höherer Granularität gemappt werden. Dieskann zu dem bereits erwähnten Nachteil führen, dass sich Fehler bei der Mapping-Erstellung auf Elemente niedriger Granularität weiterleiten. Für einen allgemeinenAlgorithmus würde also zunächst ein C R erstellt werden. Dieses könnte dannverwendet werden, um das R A , R R und P A Mapping zu erzeugen. DieErzeugung des R E Mapping kann unabhängig von der Erstellung der anderenMappings vorgenommen werden.

69

Kapitel 7

Konzeptionelle Umsetzung derAnfragetransformation

Die in den vorangegangenen Kapiteln untersuchten Teilbereiche und entwickeltenVerfahren bilden das Grundgerüst für die jetzt folgende konzeptionelleUmsetzung der Anfragetransformation, die dann später in eine Architektureingebunden werden kann.

7.1 Erweiterungsverfahren vonTransformationsregeln

Die Regeln, die für die Verwendung der Anfrageumformung verwendet werden,wurden bereits mehrfach erwähnt und werden nun definiert. Die Menge derTransformationsregeln sei mit =1 , ... ,2 gegeben. Diese wird inErweiterungsregeln ext und Reduktionsregeln rdc unterteilt, wobei=ext∪ rdc . Für insgesamt fünf Regeln werden in diesem Kapitel die

konzeptionellen Verfahren zur Umsetzung der Anfrageumformung entwickelt.Dies sind die Vocabulary-Regel voc , die Part-Whole-Regel ptw , die Feature-Regel fea , die Support-Regel sup und die Sensitivity-Regel sen , wobeivoc , ptw , fea ,sup∈ext und sen∈rdc .

Für die Anfrageumformung werden transformierbare Ausdrücke der Form=x t innerhalb der Anfrage Q extrahiert. Der Ausdruck bezeichnet ein binäresPrädikat , das ein Attribut x mit einem konstanten Term t verbindet und einenboolschen Rückgabewert liefert.

Durch die Funktion ,Q in wird aus eine neuer, expandierter Ausdruck 'gebildet. Dieser wird im Kontext der Anfrage Q in verarbeitet. Q in ist dabei dieden Ausdruck direkt umschließende Anfrage. Wenn in einer Anfrage keine

70

verschachtelten Anfragen vorhanden sind, oder der Ausdruck nicht in einerverschachtelten Anfrage vorkommt, ist Q in=Q . Das heißt, dass die Regel auf dieProjektions-, Selektions- und Join-Operatoren der direkt umschließenden Anfragezugreifen kann. Dies wird für die Support-Regel benötigt, wie später noch nähererläutert wird. Es ist aber auch für zukünftige Regeln wichtig, die den Kontext, indem verwendet wird, benötigen.

Die Bedeutung von Q in soll kurz anhand eines SQL-Beispiels erläutert werden.Die Anfrage Q1 und Q2 beziehen sich auf die Datenbank in A.2.3 und suchenjeweils nach allen Früchten, die süß sein sollen. Dies wird in Q1 durch ein Joingemacht und in Q2 durch eine verschachtelte Anfrage. Die Anfragen geben diegleichen Anfrageergebnisse zurück.

Q1 = SELECT fruits.name FROM fruits, fruitstaste_n1

WHERE fruits.t_id = fruits_taste_n1.idAND fruits_taste_n1.name = 'sweet';

Q2 = SELECT nameFROM fruitsWHERE t_id IN

SELECT idFROM fruits_taste_n1WHERE name = 'sweet';

Der einzige transformierbare Ausdruck λ ist in Q1 "fruits_taste_n1.name = 'sweet'"und wird im Kontext der gesamten SQL-Anweisung von den Regeln verarbeitet.Auch in Q2 gibt es nur einen einzigen transformierbaren Ausdruck λ mit "name ='sweet'". Dieser wird nur im Kontext der inneren (verschachtelten) "SELECT"Anfrage von den Regeln verarbeitet. An diesem Beispiel wird deutlich, dass füreine semantisch äquivalente Anfrage einer Regel unterschiedliche Kontexte zurVerfügung stehen können. Es ist daher auch möglich, dass für semantisch gleicheAnfragen unterschiedliche Anfrageergebnisse nach der Transformation geliefertwerden.

Es sei nun eine Datenbankanfrage Q auf eine Relation R gegeben:

Q={x1 , ... , xn ∣ x1 , ... , xn ∈ R ∧ }

Die Datenbankanfrage wird mit allen Erweiterungsregeln ext transformiert.Hierzu wird der Ausdruck λ über eine Disjunktion mit einem aus denErweiterungsregeln gebildeten Ausdruck verbunden. Dabei bleibt für den

71

Qin

Qin

transformierten Ausdruck ein boolscher Rückgabewert erhalten.

Q '={x1 , ... , xn ∣ x1 , ... , xn ∈ R ∧ ∨k=0

∣ext∣k ,Q in}

Analog findet eine Expansion der Datenbankanfrage über die Reduktionsregelnrdc statt, indem der Ausdruck λ über eine Konjunktion mit einem Ausdruck, der

aus den Reduktionsregeln gebildet wird, verbunden wird.

Q '={ x1 , ... , xn ∣ x1 , ... , xn ∈ R ∧ ∧k=0

∣ rdc∣k ,Q in}

Durch diese Vorgehensweise der Expansion einer Datenbankanfrage wird erreicht,dass die Anfrage transformiert wird, ohne dass sich die transformierten Ausdrückeder Regeln gegenseitig beeinflussen. Das heißt, dass der transformierte Ausdruckeiner Regel nicht von einer anderen Regel verarbeitet wird. DerProjektionsbereich der Anfrage Q und der Anfrage Q' bleibt durch dieTransformation identisch.

Die hier besprochene Vorgehensweise sollte in Zukunft hinsichtlich derKaskadierbarkeit von Transformationsregeln näher untersucht werden. Dasbedeutet, es sollte untersucht werden, inwieweit der transformierte Ausdruck einerRegel für die Transformation mit anderen Regeln genutzt werden kann. Dies sollaber nicht Bestandteil der vorliegenden Arbeit sein.

7.2 Inferenzmechanismen

Der Begriff Inferenz wurde bereits in 2.4 erläutert. Es soll nun anhand vonInferenzregeln die Inferenz über einer Ontologie gebildet werden. DieInferenzregeln, die für eine Ontologie erstellt werden, erweitern ein existierendesOntologie-Modell, indem sie implizit enthaltenes Wissen transparent machen.Wie in Kapitel 3 erarbeitet, eignet sich die OWL-Sprache für die Modellierungdes Ontologie-Modells gut, da sie Modellierungsprimitive für die elementarenBeziehungen wie ISA und SynOf besitzt. Die von OWL benutzten Inferenzregelnkönnen somit benutzt werden. OWL bietet Umschreibungsmöglichkeiten an, umdie PartOf-Beziehung auszudrücken (vgl. 3.4). Die Inferenzbildung der PartOf-Beziehung ist jedoch - wie sie von OWL umgesetzt wird - nicht ausreichend undwird durch einen eigenen Ansatz ersetzt. Dies wird anhand der einzelnenTransformationsregeln entwickelt. In den Ausführungen werden nur die relevantenAusschnitte aus den Umformungsregeln angegeben. Für eine genauereBeschreibung der Transformationsregeln sei erneut auf [28,30,31] verwiesen.

Für die Vocabulary-Regel findet eine Erweiterung über alle von einem Konzept

72

gefundenen, in der ISA-Hierarchie unterliegenden Konzepte und deren Synonymestatt. In der Vocabulary-Regel wird dies formal durch ∃ s∈DESC ' ISA' , c0und ∃ s∈SYNs c , c∈DESC ' ISA' , c0 dargestellt [28,30,31]. DESC() ist eineGraphoperation, die alle Konzepte zurückliefert, die transitiv über die angegebeneBeziehung verbunden sind. SYNs() ist eine Graphoperation die alle Konzepte, diein synonymer Beziehung zu einem Konzept stehen, zurückgibt. DieseGraphoperationen fallen weg, indem der Zugriff auf die für die Vocabulary-Regelbenötigten abgeleiteten Konzepte, direkt im inferierten Graphen enthalten ist. DieOWL-Sprache setzt die für diese Regel benötigte Inferenz der ISA-Beziehungbereits durch deren Inferenzregeln um. Die verwendeten Regeln sollen hier alsprädikatenlogische Ausdrücke angegeben werden. Für den ODBT-Prototypenwurde eine direkte Umsetzung in die Regelsyntax der Ontologie-Werkzeuge Jenaund Sesame vorgenommen.

(1) ∀ abc∣ Isa a ,b∧Isa b , c Isa a , c(2) ∀ abc∣Syn a ,b∧Synb , c Syn a , c(3) ∀ ab∣Syna ,b Syn b ,a (4) ∀ abc∣ Isa a ,b∧Syna , c Isa a , c

Abbildung 7.1 Inferenzbildung für Isa- und SynOf-Beziehung

73

computer

palmtopnotebookpc

calculator

data-processor

macpc intelpcapplepc

keyboardmonitordektop

ISA

PartOf

SynOf

ISA Inferenz

PartOf Inferenz

SynOf Inferenz

(1)

(4 , 1)

(4) (1)(2)

(2 , 3) (2 , 3)

(2 , 3)

(2 , 3)

Anhand dieser Regeln soll nun der inferierte Graph anhand eines Beispiels, das inAbbildung 7.1 dargestellt wird, gebildet werden. Das Beispiel ist ein Ausschnittaus der Produkt-Ontologie aus A.1 die auch später noch bei der Umsetzung derRegeln Verwendung findet.

Im Ontologie-Graphen sind die ursprünglichen, nicht inferierten Beziehungen alsdurchgängige Linien eingezeichnet. Für die durch die Inferenzregeln neugebildeten Beziehungen werden gestrichelte Linien benutzt. Außerdem ist nebenden inferierten Regeln jeweils die Nummer der Regel gegeben, die zur Bildungder Beziehung führt. Abhängig von der Ausführungsreihenfolge können diesunterschiedliche Regeln sein. So kann z.B. die ISA-Beziehung zwischen"applepc" und "computer" durch die Regel 4 gebildet werden, wenn die Synonym-Beziehung zwischen "macpc" und "applepc" bereits besteht. Anderseits ist es auchmöglich, dass die Beziehung mit der Regel 1 gebildet wird, wenn die ISA-Beziehung zwischen "pc" und "applepc" bereits besteht. In welcher Reihenfolgedie Regeln angewendet werden und welche Regeln die Anwendung einer anderenRegel auslösen, ist in Jena dem Inferenzmechanismus überlassen. In Sesamekönnen in der Regel-Syntax hierzu spezielle Auslöser31 explizit angegeben werden(vgl. 4.2, 4.3).

Damit ist die Inferenzbildung für die Vocabulary-Regel komplett, und es kann dienächste Transformationsregel betrachtet werden. Bei der Part-Whole-Regelwerden für ein Konzept diejenigen Konzepte gesucht, die in direkter PartOf-Beziehung stehen. Es werden also alle direkten Teile eines Konzeptes gesucht.Die PartOf-Konzepte, die ein Konzept besitzt, werden durch die ISA-Beziehungan unterliegende Konzepte weiter vererbt. Dies wird in der Part-Whole-Regelformal durch ∃ s∈PARTs c0 ausgedrückt [30]. Wie zuvor fällt die PARTs()Graphoperation weg und wird durch direkte Inferenzbildung auf einen inferiertenGraphen ersetzt.

(5) ∀ ab∣PartOf a ,b HasPart a ,b(6) ∀ ab∣PartOf a ,b PartOfInf a ,b(7) ∀ ab∣HasPart a ,b PartOf a ,b(8) ∀ abc∣ Isa a ,b∧PartOfInf c ,b PartOfInf c , a (9) ∀ abc∣Syn a ,b∧PartOfInf c , a PartOfInf c ,b(10) ∀ ab∣PartOfInf a ,b HasPartInf b , a

Die Inferenzbildung geschieht im Gegensatz zu der Isa- und SynOf-Beziehungnicht direkt auf der PartOf-Beziehung, sondern auf einer neu gebildetenBeziehung "PartOfInf". Der Grund dafür ist, dass es weiterhin möglich sein soll,nicht inferierte PartOf-Beziehungen von den inferierten PartOf-Beziehungen zuunterscheiden. So ist es z.B. in Sesame durch dieses Vorgehen nicht erforderlich,

31 engl. Trigger

74

einen inferierten und einen nicht inferierten Graphen im persistenten Datenbank-Subsystem zu halten, was eine erhebliche Speicherplatzreduktion darstellt. Alszusätzliche Inferenz wird die inverse Beziehung "HasPart" von "PartOf" gebildet.

Auch hier sollen die Regeln anhand eines Beispiels verdeutlicht werden, indemerneut der Ausschnitt aus der Produkt-Ontologie gewählt wird. Um den Graphenübersichtlich zu halten, wird darauf verzichtet, die inferierten HasPart-Beziehungen darzustellen.

Abbildung 7.2 Inferenzbildung der PartOf-Beziehungfür die Part-Whole-Regel

Auch in diesem Beispiel werden die Kanten durch die Nummer der Inferenzregelgekennzeichnet, durch die sie gebildet werden. Die PARTs() Graphoperation kannnun ersetzt werden, indem für ein Konzept alle durch die HasPartInf-Beziehungverbundenen Konzepte gesucht werden.

Nachdem die Inferenzbildung für die Part-Whole-Regel fertig gestellt ist, soll nunauf die Inferenzbildung der Support-Regel eingegangen werden. In der Support-Regel wird die transitive Eigenschaft der PartOf-Beziehung genutzt. In ihr werden

75

computer

palmtopnotebookpc

calculator

data-processor

macpc intelpcapplepc

keyboardmonitordektop

ISA

PartOf & PartOf Inferenz

SynOf

ISA Inferenz

PartOf Inferenz

SynOf Inferenz

(8) (8) (8) (8)(9) (9) (9)

Konzepte gesucht, die in der hierarchischen Struktur der PartOf-Beziehungoberhalb eines Konzeptes liegen. Die formale Darstellung hierzu bezeichnet dieGraphoperation ∃ s∈WHOLESsc0 [30]. Die bereits für die Part-Whole-Regelerstellten Inferenzregeln können erweitert werden, indem auch dieTransitivitätseigenschaft für die PartOf- und HasPart-Beziehung erfüllt ist.

(11) ∀ ab∣PartOfInf a ,b PartOfTransInf a ,b(12) ∀ abc∣PartOfTransInf a ,b

∧PartOfTransInf b , c PartOfTransInf a , c(13) ∀ ab∣PartOfTransInf a ,b HasPartTransInf a , c

Da es sich nur um die zusätzliche transitive Eigenschaft der PartOf-Regel handelt,soll hier darauf verzichtet werden ein weiteres Beispiel für diese Erweiterung derInferenzregeln zu geben. Es ist nun möglich, dass die Support-Regel durch die neugebildete PartOfTransInf-Beziehung direkt alle Konzepte finden kann, von denenein Konzept ein Bestandteil ist. Damit ist die Inferenzbildung auch für dieSupport-Regel abgeschlossen. Für die weiteren Regeln ist keine Erweiterung mehrnötig, da sie auf die gleichen Inferenzmechanismen wie die hier behandeltenRegeln angewiesen sind. Daher soll auf eine Betrachtung der noch ausstehendenInferenzregeln in diesem Kapitel verzichtet werden.

Eine letzte Betrachtung soll sich der Komplexität der Inferenzbildung widmen. ImVergleich zur OWL-basierten Inferenzbildung ist der Ansatz schlanker, da er sichauf die Schemaebene begrenzt. Außerdem fallen die Regeln für eine Vielzahl derModellierungsprimitive weg, da sie für die Transformationsregeln nicht benutztwerden. Zunächst sollen die Abhängigkeiten zwischen den einzelnen Regelnanalysiert werden. Eine Regel 11 ist abhängig von einer Regel 22 ,wenn es eine Schlussfolgerung s ∈ 2 gibt, die eine Prämisse p ∈ 1 erfüllt[7]. Aus dieser Definition können die Abhängigkeiten für die entworfenenInferenzregeln gebildet werden. Diese sind im Graph in Abbildung 7.3 dargestellt.Mit den Pfeilen wird der Auslöser einer Regel zu einer anderen Regelausgedrückt.

Die Komplexität beruht vor allem auf der transitiven Hüllenberechnung der Isa-,SynOf- und PartOfTransInf-Beziehung, wobei die Inferenzregeln, die dieseerzeugen, hochgradig abhängig voneinander sind. Zur Erstellung einesInferenzgraphen können Verfahren basierend auf Vorwärts- oderRückwärtsverkettung benutzt werden. Bei der Vorwärtsverkettung werden für eineAussage die Inferenzregeln durchlaufen, bis die Aussage die Prämisse einerInferenzregel erfüllt. Hieraus kann eine Schlussfolgerung gezogen werden, diedann erneut als Prämisse in anderen Regeln benutzt werden kann. Bei derRückwärtsverkettung prüft man anhand einer Zielsetzung, ob die

76

Schlussfolgerung einer Regel erfüllt ist. Anhand dieser Regel wird dann gesucht,ob Aussagen in der Prämisse der Regel vorhanden sind, die die Regel erfüllen. DieVorwärtsverkettung eignet sich besser zur Bildung der Inferenz im Voraus, da dieZielsetzung nicht unbedingt bekannt ist. Wie in 4.3.3 bereits erwähnt, werden inJena beide Mechanismen verwendet. Sesame basiert auf einemVorwärtsverkettung-Algorithmus, der in [7] beschrieben ist.

Abbildung 7.3 Abhängigkeiten der Inferenzregeln

Die Effizienz der Inferenzbildung hängt also stark von den implementiertenMechanismen ab. Für eine weiterführende Betrachtung der Abhängigkeiten beider Inferenzbildung sei hier auf [7,17] verwiesen.

7.3 Umsetzung der Transformationsregeln

Die Transformationsregeln , wie sie in [28,30,31] beschrieben sind, werdennun, mit Hilfe der bisher entwickelten Verfahren, in einer konzeptionellenUmsetzung innerhalb des ODBT-Prototypen beschrieben. Da sich dieImplementierung auf das relationale Datenbankmanagementsystem DB2 bezieht,wird die Syntax der Umformung in SQL angegeben. Die formale Darstellung derErweiterungsregeln ist in [28,30,31] gegeben. Im Vergleich zu diesen Regeln wirdaber der Zugriff auf die Ontologie nicht mit Graphoperationen umgesetzt, sonderngeschieht direkt auf dem inferierten Graphen, wie es in Kapitel 7.3 beschriebenwurde.

77

odbt1

odbt2

odbt3odbt4

odbt5

odbt6

odbt7

odbt8

odbt9

odbt10

odbt11

odbt12 odbt13

7.3.1 Vocabulary-Regel

Als erste der Erweiterungsregeln soll die Vocabulary-Regel betrachtet werden. Siesoll als Einstieg dienen, da sie im Vergleich zu den anderen Regeln einfacheraufgebaut ist. Sie nimmt auch eine gewisse Sonderstellung ein, da sie nicht das inKapitel 5 entwickelte Mapping benutzt. Die Vocabulary-Regel wird verwendet,um die semantische Aussagekraft des Vokabulars einer Anfrage zu erhöhen.Deshalb wird die Anfrage durch Synonyme und durch spezialisierte Ausdrückeerweitert.

Die Anwendung der Regel für einen transformierbaren Ausdruck =x t , wie erin 7.1 definiert ist, wird auf das Gleichheitsprädikat reduziert, also ="=" . Zubeschreiben ist nun die Bildung des durch die Vocabulary-Regel transformiertenAusdrucks ' voc=voc ,Q in . Das Attribut x wird über ein Instanz-KonzeptMapping C , V zur Laufzeit auf ein Konzept in der Ontologie gemappt. Über deninferierten Graphen der Ontologie werden dann alle in ISA- und SynOf-Beziehungstehenden Konzepte gesucht und mit ihnen die Erweiterung über eine Disjunktiongebildet.

Es soll nun der Algorithmus 7.1 zur Erweiterung durch die Vocabulary-Regelgegeben werden. Der Algorithmus benutzt die Funktion exp ,1 ,2 , durch dieein neuer Ausdruck über dem Prädikat und den Termen 1 und 2 gebildetwird.

01 ct := Mappe_Wert_zu_Konzepten(t);02 λvoc := ''; 03 Cext := ISA(ct) ∪ SynOf(ct);04 foreach (cext in Cext) {05 λext = exp(=, cext, x);06 if (erste Iteration)07 λvoc = λext;08 else09 λvoc = exp(OR, λvoc, λext);10 }

Algorithmus 7.1 Erstellen eines transformiertenAusdrucks λvoc

Der Algorithmus wird nun anhand eines kleinen SQL-Beispieles erläutert.

Q3 = SELECT * FROM product_1WHERE name = 'pc';

78

Q3' = SELECT * FROM product_1 WHERE name = 'pc'

OR name = 'macpc' OR name = 'intelpc' OR name = 'apple'

Die Anfrage Q3 bezieht sich auf die Produkt-Datenbank in A.2.1. Für dieTransformation wird die Ontologie aus A.1.1 verwendet. Der passende inferierteGraph wurde in Abbildung 7.2 dargestellt. Der einzige transformierbare Ausdruck in Q3 ist "name = 'pc'". In Zeile 1 des Algorithmus wird ein Konzept zumkonstanten Term "name" gemappt. Für das Konzept "name" werden dann in derOntologie in Zeile 3 alle Unterkonzepte der ISA-Beziehung und der zu ihr inBeziehung stehenden synonymen Konzepte gesucht. Da die Operationen auf deminferierten Graphen stattfinden, sind dies "macpc", "intelpc" und "apple", wie ausdem Graphen in Abbildung 7.2 zu erkennen ist. Über diesen Konzepten wird dannin Zeile 5 ein neuer Ausdruck mit dem Gleichheitsprädikat und demAttributnamen gebildet. Die Laufzeit des Algorithmus ist linear zu der Anzahl dererweiterten Konzepte, also O(Cext).

7.3.2 Part-Whole-Regel

Die Part-Whole-Regel wird dort angewendet, wo es möglich ist, Einträge in derDatenbank durch ihre Komponenten zu identifizieren. Mit der Anfrage nacheinem Begriff "Desktop" geht es dem Benutzer vielleicht im wesentlichen nichtdarum, wirklich Einträge mit der Zeichenkette "Desktop" zu erhalten. Vielmehrkönnte seine Intention sein, einen Computer, der zwar eine Tastatur, aber keinenMonitor hat, zu finden. Dieses semantische Wissen lässt sich durch die PartOf-Beziehung in der Ontologie modellieren und auf die Datenbankanfrage anwenden.

Die Part-Whole-Regel soll zunächst an einem Beispiel verdeutlicht werden, damitdie konzeptionelle Umsetzung später klarer wird. Das Beispiel ist aus derBeschreibung der Part-Whole-Regel in [30] entnommen. Für einen besserenÜberblick sind in Abbildung 7.2 noch einmal ein Ausschnitt aus der Produkt-Datenbank aus A.2.1 und der Produkt-Ontologie aus A.1.1 gegeben. Außerdemwird das Mapping in XML-Syntax angegeben, das die Elemente zwischenOntologie und Datenbank referenziert.

Auf die "PRODUCT" Relation wird folgende SQL-Datenbankanfrage gestellt:

Q4 = SELECT *FROM product_1WHERE name = 'macpc';

79

Ontologie Datenbank <DbRelationOntRelationshipMapping> <DbRelation name="COMPONENT"></DbRelation> <OntRelationship url="po:PartOf"></OntRelationship> <ProjectionFrom> <DbAttribute name="C_ID" /> <DbRelation name="PRODUCT"> <DbAttribute name="NAME" /> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbAttribute name="P_ID" /> <DbRelation name="PRODUCT"> <DbAttribute name="NAME" /> </DbRelation> </ProjectionTo> </DbRelationOntRelationshipMapping> Mapping-Struktur

Abbildung 7.4 benötigte Komponenten für eine Part-Whole Transformation

Die Anfrage würde derzeit nur ein Tupel (140, 'macpc', 'mac', 5000) zurückliefern.Durch die Part-Whole-Regel soll die Anfrage so erweitert werden, dass auch dieTupel zurückgeliefert werden, die alle Bestandteile von "macpc" haben. In derOntologie sind dieses "monitor", "desktop" und "keyboard". Schaut man sich nundie Datenbank an, kann man erkennen, dass auch das Tupel (142, "product","apple", 3000) diese Bestandteile hat. Nach der Anfrageumformung durch diePart-Whole-Regel sollte also auch dieses Tupel gefunden werden.

Das gegebene Mapping ist ein R E Mapping und referenziert die PartOf-Beziehung. Außerdem wird zwischen dem Extensionsbereich von "NAME" überdie Relation "COMPONENT" auf den gleichen Extensionsbereich von "NAME"gemappt. Das heißt, dass die Instanzen in "NAME" zueinander in PartOf-Beziehung stehen. Damit ist die Bedingung erfüllt, dass eine Erweiterung derDatenbankanfrage mit diesem Mapping stattfinden kann.

80

COMPONENTP_ID C_ID

123 135123 136140 129140 135140 136142 129142 135142 136

PRODUCTID NAME MODEL PRICE

123 computer ibm 1000129 monitor elsa 500135 keyboard itt 50136 desktop ibm 1300140 macpc mac 2000142 product apple 3000

macpc

keyboardmonitordektop

PartOf Inferenz

Für die Erweiterung werden zunächst alle Tupel in der "COMPONENT"Relationen gesucht, die als Teil32 "desktop" haben. Dies geschieht durch dieAnfrage Qdesktop.

Qdesktop

SELECT component.p_idFROM product, component WHERE component.c_id = product.id

AND product.name = 'desktop'

Das gleiche wird mit den Teilen "monitor" und "keyboard" gemacht. DerDurchschnitt gebildet über die Anfragen Qdesktop, Qmonitor und Qkeyboard, sind alleTupel des Attributs "P_ID" in der Relation "COMPONENT", die "desktop","monitor" und "keyboard" über den Fremdschlüsselverweis von "C_ID" in"PRODUCT" referenzieren. Daher kann der transformierte Ausdruck durch eineErweiterung "ID IN(Qdesktop INTERSECT Qmonitor INTERSECT Qkeyboard)" gebildetwerden. Mit nur dieser Erweiterung werden aber auch Tupel zurückgeliefert, diemehr Teile als nur "desktop", "monitor" und "keyboard" haben. Um dieses zuverhindern wird zusätzlich eine Anfrage gebildet, die alle Tupel in"COMPONENT" zurück gibt, die keines der drei Bestandteile besitzen. Einesolche Anfrage ist:

Q¬(desktop|keyboard|monitor)

SELECT component.p_idFROM product, component WHERE component.c_id = product.id

AND product.name NOT IN ('desktop', 'monitor', 'keyboard')

Diese Anfrage kann dann mit der Erweiterung "ID NOT IN ('desktop, monitor,keyboard')" auf die "PRODUKT" Relation angewendet werden. Somit ergibt sicheine vollständig transformierte Anfrage Q4'.

Q4'SELECT * FROM productWHERE name = 'apple'

OR ID IN (Qdesktop INTERSECT Q keyboard

INTERSECT Q monitor )AND ID NOT IN (Q¬(desktop|keyboard|monitor))

Durch diese Anfrage wird nun auch das zusätzliche Tupel (142, 'product', 'apple',3000) gefunden.

32 Teil bezeichnet hier den „Part“-Teil in der PartOf-Beziehung

81

In dem hier gegebenen Beispiel wird durch eine Korrespondenz mit N:MKardinalität erweitert (vgl. 5.5). Die Part-Whole-Regel kann aber auch mitKorrespondenzen mit 1:N Kardinalität erweitert werden. Beispielsweise könnteeine "COMPONENT" Relation existieren, die den Namen einer Komponenteenthält und über ein "C_ID" Attribut die "PRODUKT" Relation referenziert (vgl.A.2.1). Andere Kardinalitäten sind aber für diese Regel nicht sinnvoll.

7.3.2.1 Relevante Korrespondenzen

Bevor die Umsetzung der Part-Whole-Regel konzeptionell erarbeitet wird, soll aufdas Finden von Korrespondenzen eingegangen werden, die für die Anwendung derPart-Whole-Regel benutzt werden können. Dies soll allgemein betrachtet werden,da diese Funktionalität auch von anderen Regeln benötigt wird.

Eine für eine Transformationsregel relevante Korrespondenz, ist eineKorrespondenz, die für die Transformation der Regel angewendet werden kann.R E ist eine Mapping-Struktur, die eine Menge von R E Korrespondenzenenthält. Dabei soll das Finden von R E für unterschiedliche Kardinalitäten miteiner Funktion r ,aR E stattfinden. Die Parameter r und a müssenBestandteile der Korrespondenzen in der Mapping-Struktur sein. Die Funktion hatals Parameter eine Beziehung r, auf die die Korrespondenz eingeschränkt werdensoll. Außerdem hat sie den Parameter a, der das Attribut ist, dessenExtensionsbereich in der Mapping-Struktur enthalten sein muss. Bezogen auf dasBeispiel wäre r = "PartOf" und a = "NAME". Durch die ' PartOf ' , ' NAME ' würden also alle Mapping-Strukturen gefunden, die eine Korrespondenz R E

sind in der der Extensionsbereich von "NAME" mit der PartOf-Beziehunggemappt wird.

r , a⇔R E∋s ∣∣RLS s∣=r ∧∣ATR PR_TOs∣=a ∧∣RELPR_TOs∣=ra

Funktion zum Reduzieren einer Mapping-Struktur aufrelevante R E Korrespondenzen

In 5.5 wurden bereits die Bedingungen für die Bildung von Korrespondenzenunterschiedlicher Kardinalität definiert. Mit diesen dort definierten Bedingungenkann die Funktion r ,a weiter eingeschränkt werden, um nur Mapping-Strukturen zurückzuliefern, die Korrespondenzen bestimmter Kardinalität haben.

82

R E(1:1)r , a⇔r , a ∩ R E(1:1)

R E(1:N)r , a ⇔r , a ∩ R E(1:N)

R E(N:1)r , a ⇔r , a ∩ R E(N:1)

R E(N:M)r , a⇔r , a ∩ R E(N:M)

Funktionen zum reduzieren auf R E Mapping-Strukturen bestimmter Kardinalität

Diese Funktionen werden im weiteren für die Einschränkung aufKorrespondenzen für die Transformationsregeln angewendet.

7.3.2.2 Konzeptionelle Umsetzung der Part-Whole-Transformation

Im weiteren wird die konzeptionelle Umsetzung zur Bildung eines transformiertenAusdrucks für die Part-Whole-Regel formal erarbeitet. Um die Semantik derOntologie auf Inhalte in der Datenbank zu übertragen, ist es erforderlich, dass füreinen Ausdruck =x t die Extension des Attributs x mit der PartOf-Beziehungin einer Korrespondenz gemappt ist. Aus dieser Korrespondenz und demkonstanten Term t lässt sich eine Erweiterung erstellen, die der Part-Whole-Regelentspricht. Die Part-Whole-Regel kann, wie bereits erwähnt, mitKorrespondenzen, die eine 1:1 oder 1:N Kardinalität aufweisen, erweitert werden.

ptw(1:N)=R E(1:N) x , ' PartOf ' ptw(N:M)=R E(N:M)x , ' PartOf '

ptw=ptw(1:N)∪ptw(N:M)

Reduzieren auf Korrespondenzen für die Part-Whole-Regeln

Es ist nun möglich, aus den in ptw enthaltenen Korrespondenzen einen neuentransformierten Ausdruck ' ptw zu erstellen, welcher die Part-Whole-Erweiterungbildet. Für den Ausdruck =x t wird wie bereits in der Vocabulary-Regel dasAttribut x über eine Korrespondenz C V zur Laufzeit auf ein Konzept c in derOntologie gemappt. Für c werden dann alle in PartOf-Beziehung stehendenKonzepte C ptw=HasPart c in der Ontologie gesucht. Über diese Konzeptewerden jeweils eigene innere Ausdrücke ext( c ) gebildet. ext( c ) ist eineKorrespondenz-Erweiterung für ein Konzept c, da der Ausdruck auf derDatenbank eine Erweiterung mit c über den Inhalt einer bestehendenKorrespondenz erstellt. In dem hier gegebenen Beispiel sind dies keyboard , monitor

83

und desktop . Eine Korrespondenz-Einschränkung red( c ) schränkt eine Anfragemit einem Ausdruck auf die Konzepte C ein. Dies ist im obigen Beispiel¬monitor , desktop , keyboard .

Es soll nun eine Korrespondenz-Erweiterung ext( c ) für ein Konzept c∈C ptw

und eine N:M-Kardinalität der Korrespondenz gegeben werden:

ext cNM =

"SELECT ∣RELN : M ∣ . ∣ATR FKEY PR_TON : M ∣ FROM ∣RELPR_FROMN : M ∣,∣REL∣ WHERE ∣RELPR_FROMN : M ∣ . ∣ATR PR_FROMN : M ∣=c

AND ∣RELN : M ∣ . ∣ATR FKEY PR_FROMN : M ∣=∣RELPR_FROMN : M ∣ . ∣ATR FKEY_REFFKEYPR_FROMN : M ∣"

Bildung einer Korrespondenz-Erweiterung für R E(N:M)

Die Anfrage wird also mit Hilfe der in 5.4 definierten Zugriffsfunktionen auf eineMapping-Struktur erweitert. Des weiteren wird nun red( c ) ebenfalls für eineN:M-Kardinalität der Korrespondenzen und C ptw gebildet:

red C NM =

"SELECT ∣RELN : M ∣ . ∣ATR FKEY PR_TON : M ∣ FROM ∣RELPR_FROMN : M ∣,∣REL∣ WHERE ∣RELPR_FROMN : M ∣ . ∣ATR PR_FROMN : M ∣ NOT IN ¬C

AND ∣RELN : M ∣ . ∣ATR FKEY PR_FROMN : M ∣=∣RELPR_FROMN : M ∣ . ∣ATR FKEY_REFFKEYPR_FROMN : M ∣"

Bildung einer Korrespondenz-Einschränkung für R E(N:M)

Wie in der Vocabulary-Regel, wird beim Algorithmus 7.2 in Zeile 1 der Term tdes Ausdrucks zu einem Konzept in der Ontologie gemappt. In Zeile 3 werdendann alle PartOfInf-Konzepte gesucht (vgl. 7.2). Über diese Konzepte wird iteriertund in Zeile 7 die Korrespondenz-Erweiterungen gebildet. In Zeile 12 werden dieKorrespondenz-Einschränkungen in die Anfrage eingebunden. Der Algorithmuskann sowohl auf N:M, wie auch 1:N Kardinalitäten von Korrespondenzenangewendet werden.

84

01 ct := Mappe_Attributnamen_zu_Konzepten(t);02 λptw := ''; 03 Cext := HasPartInf(ct);0405 foreach (Cext) { 06 if (erste Iteration)07 λptw = Qext(cext);08 else09 λptw = exp("INTERSECT",λptw,Qext(cext));10 }11 12 λptw = exp("OR" ∣ATR FKEY PR_TO∣ "IN",λptw,Qred(cext))

Algorithmus 7.2 Erstellen eines transformiertenAusdrucks λptw

Im Folgenden wird noch die erweiternde und einschränkende Anfrage für eine 1:NKorrespondenz aufgeführt:

ext c1N =

"SELECT ∣ATR 1: N ∣ FROM ∣REL PR_FROM1: N ∣ WHERE ∣ATR PR_FROM1 : N ∣=c "

Bildung einer Korrespondenz-Erweiterung für R E(1:N)

red c1N =

"SELECT ∣ATR 1: N ∣ FROM ∣RELPR_FROM1: N ∣ WHERE ∣ATR PR_FROM1 : N ∣=NOT IN ¬C "

Bildung einer Korrespondenz-Einschränkung für R E(1:N)

Wie man erkennen kann, hat die Bildung für 1:N Kardinalitäten geringereKomplexität als die für N:M Kardinalitäten. Der Grund dafür ist, dass hier keinJoin über zwei Relationen gemacht werden muss. Außerdem müssen dieRelationennamen nicht explizit referenziert werden.

Damit ist die konzeptionelle Erarbeitung für die Umsetzung der Part-Whole-Regelabgeschlossen. Die bisher erarbeiteten Verfahren für Korrespondenz-Erweiterungen und Korrespondenz-Einschränkungen sind universell anwendbar,wenn über ein Konzept c in der Ontologie ein Ausdruck transformiert werden sollund werden auch in 7.3.3, 7.3.5, und 7.3.6 benutzt.

85

7.3.3 Feature-Regel

Als nächste Transformationsregel wird nun die konzeptuelle Umsetzung derFeature-Regel beschrieben. Die Regel nutzt domänenspezifische Beziehungen aus,um mit deren Hilfe eine Anfrage näher zu spezifizieren. In ihr wird dieISASpecific-Beziehung aus dem Ontologie-Modell verwendet (vgl. 2.2). Diese isteine spezielle ISA-Beziehung, die für die unterliegenden Konzepte definiert, dasssie genau durch die zusätzlich enthaltenen Beziehungen unterschieden werden. Sounterscheidet sich z.B. ein Konzept „Schimmel“ von einem Konzept "Pferd"genau darin, dass der "Schimmel" eine Beziehung "hat Farbe" zu "Weiß" hat. Ausdieser Beziehung wird in der Feature-Regel geschlossen, dass alle weißen PferdeSchimmel sind. Die Bildung eines transformierten Ausdrucks wird zunächstanhand des Beispiels über Früchte aus [30] erklärt.

Abbildung 7.5 Frucht-Ontologie und Frucht-Datenbank

In Abbildung 7.5 wird eine graphische Darstellung einer Ontologie gegeben, in derKonzepte und Beziehungen über Äpfel und deren Farben gegeben sind. Außerdemwird der Inhalt einer Datenbank angegeben, die Einträge über Früchte enthält. Daszugehörige Mapping zwischen der Ontologie und der Datenbank ist in A.3.4 zufinden. Auf die Frucht-Datenbank soll folgende SQL-Datenbankanfrage gestelltwerden:

Q5 = SELECT *FROM fruitsWHERE name = 'green-apple';

Die Anfrage würde derzeit nur das Tupel (19, 'green-apple', 'green', 30) zurückgeben. Mit Hilfe der Feature-Regel soll die Anfrage nun so erweitert werden, dass

86

FRUITSID NAME COLOR NUM

11 kiwi green 3012 banana yellow 5013 apple red 7014 cherry red 2015 peach red 3816 red-apple red 5217 plums red 4518 apple green 7019 green-apple green 3020 apple green 60

red-appleyellow-apple

apple

color

yellow

green

red

green-apple

has_color

ISASpecific

ISA

die zusätzlichen Beziehungen des in der Ontologie gemappten Konzepts zu"green-apple" den Kontext der Datenbankanfrage erweitert. Das Konzept "green-apple" ist durch die ISASpecific-Beziehung eine Spezialisierung von "apple" undsteht in der Beziehung "has_color" zu "green". Mit der R E Korrespondenz ausA.3.4 kann die Datenbankanfrage somit erweitert werden zu:

Q5' = SELECT *FROM fruitsWHERE name = 'green-apple';

(OR name = 'apple' AND color = 'green')

In der zugehörigen Korrespondenz wird der Extensionsbereich des Attributs"NAME" zum Extensionsbereich des Attributs "COLOR" über eine 1:1Kardinalität mit der Beziehung "has_color" verbunden.

Für die Feature-Regel werden zunächst noch einige Funktionen zum Navigierender Ontologie definiert

obj c , r Findet Konzepte, die das Objekt in einerBeziehung r darstellen, wobei in der Beziehungdas Subjekt c ist

sbj c , r Findet Konzepte, die das Subjekt in einerBeziehung r darstellen, wobei in der Beziehungdas Objekt c ist

obj c Findet Konzepte, die das Objekt in einerBeziehung r sind

sbj c Findet Konzepte, die das Subjekt in einerBeziehung r sind

Funktionen zum Navigieren des Ontologie-Modells

Die Umsetzung der Feature-Regel soll nach diesem einleitenden Beispiel nun füreinen transformierten Ausdruck =x t beschrieben werden. Es muss dieBedingung erfüllt sein, dass das zum Attributnamen x mit C V gemappteKonzept c mit der ISASpecific-Beziehung zu einem anderen Konzept inBeziehung steht. Dies kann mit obj c , ISASpecific≠∅ festgestellt werden.

Wie in 7.3.2.1 für die Part-Whole Regel entwickelt, wird nun auch für die Feature-Regel auf die relevanten Korrespondenzen reduziert. Die Erweiterung kann mit1:1, 1:N, N:1 und N:M Kardinalitäten der Korrespondenzen geschehen.

87

fea(1:N)=R r(1:1) x , r∈Rfea(N:M)=R r(1:N)x , r∈Rfea(N:M)=R r(N:1)x , r∈Rfea(N:M)=R r(N:M) x , r∈R

fea=fea(1:1)∪fea(1:N)∪fea(N:1)∪fea(N:M)

Reduzieren auf Korrespondenzen für die Feature-Regel

Auf den so gebildeten Korrespondenzen innerhalb von fea können nun dieErweiterungen gemacht werden. In 7.3.4 wurden bisher nur die Korrespondenz-Erweiterungen mit ext c

1N und ext cNM erstellt und dort auf die PartOf-Beziehung

angewendet. Diese Korrespondenz-Erweiterungen sind so auch auf die Feature-Regel anwendbar. Die fehlenden Korrespondenz-Erweiterungen für 1:1 und N:1Kardinalitäten werden jetzt noch nachgeliefert. Diese wurden in 7.3 nicht benötigt,da die Anwendung der Part-Whole-Regel für sie nicht sinnvoll ist.

ext c11 = "c=∣ATR PR_FROM1:1∣"

Bildung einer Korrespondenz-Erweiterung für R E(1:1)

ext cN1 =

" SELECT ∣ATRFKEY PR_TO∣ FROM ∣RELPR_FROMN :1∣ WHERE ∣ATR PR_FROMN :1∣=c "

Bildung einer Korrespondenz-Erweiterung für R E(N:1)

Mit den so gebildeten Korrespondenz-Erweiterungen ist es nun auch für dieFeature-Regel möglich, einen Algorithmus zur Transformation des Ausdrucks=x t zu bilden. Dazu wird zunächst das Attribut x mit C V zur Laufzeit aufein Konzept c in der Ontologie gemappt. Danach wird mitc ISpec=obj c , ISASpecific das in ISASpecific-Beziehung stehende Konzept zu c

gebildet. Außerdem werden alle Konzepte, die mit der in R E gemapptenBeziehung von c gebildet sind, mit C fea=obj c ,RLS fea gesucht.

Mit c ISpec und C fea kann ein vollständiger Algorithmus zur Bildung der Feature-Regel angegeben werden. Dieser wird für die Korrespondenz-Erweiterung einer1:1 Kardinalität angegeben:

88

01 ct := Mappe_Attributnamen_zu_Konzepten(t);02 λfea := ''; 0304 foreach (cfea in Cfea) { 05 if (erste Iteration)06 λfea = Qext(cz);07 else08 λfea = exp("AND",λfea,Qext(cfea));09 }10 λISpec := exp(=, cISpec , x)11 λfea := exp("AND",λfea,Qext(cfea));

Algorithmus 7.3 Erstellen eines transformiertenAusdrucks λfea

Der Algorithmus für N:1 Kardinalitäten ist äquivalent aufgebaut, außer dass das"AND" in Zeile 11 durch "OR ∣ATRFKEY PR_FROM∣ IN" ersetzt wird.

Somit ist das Verfahren zur Umsetzung der Feature-Regel vollständigbeschrieben.

7.3.4 Support-Regel

Die Support-Regel benutzt die transitive Eigenschaft der PartOf-Beziehung. Sokönnte z.B. verbal formuliert, eine Anfrage nach allem, was einen Reifen als Teilbesitzt, mit der Anfrage nach allem, was ein Rad besitzt, ergänzt werden, da jedesRad auch einen Reifen hat. Für eine ausführliche Erklärung der Support-Regel seihier auf [30] verwiesen.

Die Schwierigkeit der Umsetzung der Support-Regel ist nicht die eigentlicheErweiterung, sondern das Schließen, ob die Erweiterung für einen Ausdruck=x t gebildet werden darf. Die in 7.3.2.1 vorgestellten Verfahren zum Findenvon relevanten Referenzen sind hier nicht ausreichend, wie später noch erläutertwird. Da die eigentliche Erweiterung - so sie denn stattfinden darf - sehr einfachist, soll sie vorweggenommen werden.

Der Algorithmus 7.4 ist sehr ähnlich zu dem Algorithmus 7.1 der Vocabulary-Regel in 7.3.1. Konkret unterscheidet er sich nur in der Zeile 3, in der jetzt alleKonzepte gefunden werden, die das zu t gemappte Konzept ct in transitiverPartOf-Beziehung besitzt.

89

01 x → Attributname;02 t → konstanter Term;03 ct := Mappe_Wert_zu_Konzepten(t);04 λsup := ''; 05 Cext := PartOfTransInf(ct);06 foreach (Cext) {07 λext = exp(=, cext, x);08 if (erste Iteration)09 λsup = λext;10 else08 λsup = exp(OR, λsup, λext);09 }

Algorithmus 7.4 Erstellen eines transformiertenAusdrucks λsup

Da die Erweiterung von nun gegeben wurde, muss noch festgestellt werden, obder Ausdruck erweitert werden darf. Die Voraussetzung dafür ist, dass t mit demdurch die "SELECT"-Klausel projizierten Attribut der Anfrage in PartOf-Beziehung steht. Dies soll anhand eines Beispiels verdeutlicht werden, das sichauf die Beispieldatenbank in A.2.2 bezieht.

Q6 = SELECT nameFROM bio_terms_component_11WHERE component = 'carbon';

Für die hier gegebene Anfrage ist in A.3.5 eine Korrespondenz gegeben, in derder Extensionsbereich von "component" auf den Extensionsbereich von "name"mit der PartOf-Beziehung gemappt wird. Somit ist die Bedingung erfüllt, dass dieAnfrage für alle Konzepte erweitert werden kann, die "carbon" in PartOfTransInf-Beziehung haben.

Aus dem Beispiel wird klar, dass in der Regel die Attribute der"SELECT"-Klausel in der Datenbankanfrage bekannt sein müssen. Diese werdendurch die Erweiterungsfunktion der Feature-Regel fea ,Q in (vgl. 7.1) in derdirekt umschließenden Anfrage Q in von mitgeliefert. Aus Q in können danndie projizierten Attributnamen der "SELECT"-Klausel entnommen werden. Diesmuss für die Feature-Regel genau eines sein, das hier mit afea bezeichnet wird. Esmuss nun überprüft werden, ob eine Korrespondenz besteht die t in PartOf-Beziehung zu afea setzt was durch eine Erweiterung der Funktionen zurReduzierung von Mapping-Strukturen aus 7.3.2.1 geschieht.

90

r , a1 ,a2⇔R E∋s ∣∣RLS s∣=r ∧∣ATR PR_TOs∣=a1∧∣RELPR_TOs∣=ra1∧ ∣ATR PR_FROMs∣=a2∧∣RELPR_FROMs∣=ra2

Erweiterte Funktionen zum reduzieren auf Mapping-Strukturen zweier Extensionsbereiche

Damit ist auch die Umsetzung der Feature-Regel vollständig konzeptionellerarbeitet.

7.3.5 Sensitivity-Regel

Als letzte Transformationsregel wird nun die Sensitivity-Regel betrachtet, die in[28] ausführlich beschrieben wird. Sie ist die einzige Reduktionsregel - versuchtalso auf „sinnvollere“ Ergebnisse der Anfrage zu reduzieren.

Durch sie werden solche Anfragen eingeschränkt, die mit homonymen Begriffen inder Ontologie korrespondieren. In Ontologien stehen Konzepte in einerhomonymen Beziehung miteinander, wenn sie unterschiedliche Bedeutungenhaben, aber den gleichen Namen besitzen. Beispielsweise hat der englischeBegriff "bank" ein Homonymer Begriff. In der WordNet-Ontologie werden sogar18 verschiedene Bedeutungen für den Begriff "bank" gegeben. Es ist also gutnachvollziehbar, dass eine Anfrage, die den Begriff "bank" enthält, fehlerhafteAnfrageergebnisse zurückliefern kann, da nicht klar ist, auf welches "bank" sichdie Anfrage bezieht.

In der Sensitivity-Regel wird versucht, bei Begriffen, die als Homonyme in derOntologie vorhanden sind, durch eine Anfrage an den Benutzer auf eines derhomonymen Konzepte einzuschränken. Der Benutzer wird also aufgefordert denKontext, in dem er die Anfrage gestellt hat, zu definieren. Dafür muss es demBenutzer möglich sein, eine Auswahl der Kontexte zu treffen, die in der Ontologiedefiniert werden. Die Einschränkung des Kontextes wird durch dreiAuswahlverfahren realisiert.

1. Bestimmung eines Namensraums2. Einschränkung durch Beschreibungen3. Unterscheidung anhand eines übergeordenten, unterschiedlichen

Konzepts („immediate uncommon concepts“)[28]

91

Die Auswahl des Namensraums bezieht sich auf die in RDF benutzte Benennungvon Ressourcen durch URIs33, wodurch sie eindeutig referenziert werden. Dabeibenutzen unterschiedliche Ontologien jeweils verschiedene Namensraum-URIs.Durch die Einschränkung des Namensraumes wird also auf bestimmte Ontologienreduziert.

http://www.aiai.ed.ac.uk/resources/go/ - Gene Ontologyhttp://www.unine.ch/knowler/wordnet/ - WordNet

Namensräume für die "Gene Ontology" und "WordNet"

Bei der Einschränkung durch Beschreibungen werden für den Benutzerverständliche Erklärungen der homonymen Begriffe verwendet. Diese müssenaber wie in WordNet Teil der Ontologie sein.

• a container (usually with a slot in the top) for keepingmoney at home; 'the coin bank was empty'

• sloping land (especially the slope beside a body of water);'they pulled the canoe up on the bank'; 'he sat on the bankof the river and watched the currents'

Beschreibungen des Konzepts "bank" in WordNet

Durch das in [28] beschriebene Verfahren des „immediate uncomon concepts“werden die in der ISA-Struktur übergeordneten Konzepte gesucht, die unmittelbarunterschiedlich sind. In der Beispiel-Ontologie in A.1.4 wären dies die folgendenKonzepte:

http://www.localhost/ontologies/entities#electronic-devicehttp://www.localhost/ontologies/entities#non-electronic-devicehttp://www.localhost/ontologies/entities#formationhttp://www.localhost/ontologies/entities#facility

Auswahl des „immediate uncommon concept“

Nach der Bestimmung des Kontextes für einen homonymen Begriff und der damitverbundenen eindeutigen Zuordnung zu einem Konzept, wird die Transformationvon =x t durch die Sensitivity-Regel gebildet. Da sie fast identisch zurFeature-Regel ist wird sie nur grob umrissen.

Es wird zunächst der Term t auf ein Konzept csen in der Ontologie gemappt.Außerdem wird mit sen=x , r∈R auf relevanten Korrespondenzen allerKardinalitäten reduziert, in denen x zu einer beliebigen Beziehung R steht. MitC sen=obj csen ,RLS sen werden die Konzepte gefunden, die in einerBeziehung zu csen stehen und die in der Mapping-Struktur sen vorhanden sind.Der Algorithmus für die Erweiterung ist dann:

33 Uniform Resource Indentifier

92

01 λsen := ''; 02 foreach (c in Csen) { 03 if (erste Iteration)04 λsen = Qext(cz);05 else06 λsen = exp("OR",λsen,Qext(csen));07 }

Algorithmus 7.5 Erstellen eines transformiertenAusdrucks λsen

Die Ausführungen für die Transformation der Feature-Regel sind sehr kurzgehalten, da hier keine neuen Konzepte verwendet werden. Die einzelnen Schrittekönnen aber anhand der Ausführungen in 7.3.3 nachvollzogen werden.

Damit ist auch die letzte Transformationsregel konzeptionell beschrieben.

7.4 Zusammenfassung

In diesem Kapitel wurden die grundlegenden Methoden für die Umsetzung derTransformationsregeln, wie sie in [28-31] beschrieben werden, entwickelt. Eswurde am Anfang gezeigt, dass es möglich ist mit Hilfe eines inferiertenOntologiegraphen, die für die Transformationsregeln benötigten Graph-Operationen zu ersetzten. Durch die Bildung transformierter Ausdrücke mit Hilfevon Korrespondenz-Erweiterungen, wurde ein generisches Verfahren entwickelt,dass es erlaubt, einen Großteil der Funktionalität einiger derTransformationsregeln (Vocabulary-Regel, PartWhole-Regel, Sensitivity-Regel)umzusetzen. Dieses Verfahren wurde zunächst für die Part-Whole-Regelentwickelt und in der Feature-Regel vervollständigt. Das nächste Kapitel wird sichnun mit der konkreten Umsetzung der in diesem Kapitel entwickelten Verfahrenin eine Implementierung des ODBT-Prototypen beschäftigen.

93

Kapitel 8

Architektur, Implementierung undTests des ODBT-Prototypen

Die Architektur des ODBT-Prototypen orientiert sich an dem im vorangegangenenKapitel beschriebenen konzeptionellen Entwurf der ontologie-basiertenTransformation von Datenbankanfragen. Zunächst wird eine Systemanalyseerstellt, in der die verschiedenen Komponenten spezifiziert werden, die zurVerarbeitung der Anfrageumformung benötigt werden. Aufbauend darauf wirdein Überblick über die gesamte Architektur gegeben, die später in einzelnenBereichen näher spezifiziert wird.

8.1 Systemanalyse

Für die Architektur des ODBT-Prototypen wird zunächst eine Übersicht über diewichtigsten benötigten Komponenten gegeben, um die Umsetzung derTransformation von Datenbankanfragen zu vollziehen.

• Ein SQL-Parser zum Extrahieren von transformierbaren Ausdrückenund zum Zusammensetzen von erweiterten SQL Anfragen (vgl. 7.1).

• Eine Schnittstelle zur Kommunikation mit verschiedenen Ontologie-Werkzeugen. Durch diese wird die Funktionalität zum Speichern,Verarbeiten und Durchsuchen von Ontologien definiert.

• Eine Schnittstelle zum Zugriff auf Mapping-Strukturen. Durch diesesollen die Zugriffsfunktionen auf ein Mapping umgesetzt werden (vgl.5.4). Diese Komponente sollte auch das Finden von Korrespondenzenunterschiedlicher Kardinalität umsetzen (vgl. 5.5).

• Eine Komponente, welche die Bildung von erweiterbaren Ausdrückenfür die Transformationsregeln umsetzt (vgl. 7.1, 7.3, 7.4).

• Eine Benutzeroberfläche, mit der die Transformation vonDatenbankanfragen durchgeführt und dargestellt werden kann.

94

Mit diesen Komponenten wird nun eine grobe Architekturbeschreibung für dieAnfragetransformation gegeben. Diese ist in Abbildung 8.1 durch einZugriffsdiagramm visualisiert, das nun erläutert werden soll.

Abbildung 8.1 Zugriffsdiagramm für dieAnfragetransformation

In der Abbildung 8.1 ist zu erkennen, dass sich das gesamte System in dreiBereiche aufteilt. Der erste ist der ODBT-Prototyp, welcher die Komponenten, diegerade aufgelistet wurden, enthält. Weitere Bereiche sind das Ontologie-Werkzeugund die Datenbank, auf welche die transformierte Anfrage stattfindet. Die Pfeiledrücken jeweils den Zugriff einer Komponente auf eine andere Komponente aus.

Der Zugriff auf das System erfolgt über eine der drei Schnittstellen des ODBT-

95

Ontologie-Werkzeug API

Schnittstelle zu Ontologie-

Werkzeugen

Ontologie-Werkzeug

Mapping -Schnittstelle

ODBT-PrototypAPI

ODBT-Prototype

Umformungsregeln

Anfrage-Umformungs-

prozessor

Anfrage-Datenbank

SQL-Parser

ODBT CONSOLE

ODBTGUI

ODBT-Prototyp -SchnittstellenRDBMS

Zugriffsmechanismen

0 1 1 0 1 0

Inferenzgraph

RDF-Anfrage-sprache(RQL, ...)

0 1 1 0

1 0 1 0

Prototypen. Diese unterteilen sich in eine Programmierschnittstelle, einekonsolenbasierte Schnittstelle und eine Schnittstelle für eine graphischeBenutzeroberfläche. Die beiden letztgenannten nutzen die Funktionalität derProgrammierschnittstelle. Der SQL-Parser erhält eine Datenbankanfrage aus derODBT-Prototyp-Schnittstelle und extrahiert und erweitert sie durch dietransformierten Ausdrücke des Anfrage-Umformungsprozessors. Der Anfrage-Umformungsprozessor bildet das Rückgrad der Anfragetransformation. In ihmfindet die Umsetzung der Transformationsregeln statt. Dabei wird vom Anfrage-Umformungsprozessor die Mapping-Schnittstelle genutzt, um auf das Mappingzuzugreifen. Über die Schnittstelle zum Ontologie-Werkzeug greift der Anfrage-Umformungsprozessor auf den inferierten Graphen zu.

8.2 System-Entwurf

Mit der gegebenen Analyse des Systems sind die Hauptkomponenten für dieArchitektur definiert. Auf die einzelnen Komponenten wird in diesemUnterkapitel näher eingegangen. Die Frage nach einem geeigneten Ontologie-Werkzeug wurde in Kapitel 4 hinreichend geklärt. Wie bereits erwähnt, sollen diebeiden Ontologie-Werkzeuge Sesame und Jena in das System eingebundenwerden. Die Datenbankanfrage wird auf eine DB2-Datenbank gestellt. AlsProgrammiersprache wurde die objektorientierte Programmiersprache Javagewählt. Die Klassen-Diagramme des System-Entwurfs in UML34 für die JavaImplementation ist in A.4 zu finden.

8.2.1 ODBT-Prototyp Schnittstelle

Das ODBT-Prototyp-API, für die ontologie-basierte Transformation vonDatenbankanfragen, wird durch die Klasse OdbtPrototyp gebildet. EineÜbersicht der Klassenstruktur ist in A.4.1 dargestellt. Durch sie sind folgendeFunktionalitäten ansprechbar:

• Einbinden von Transformationsregeln• Einbinden des Mapping• Schnittstelle für die Benutzerkommunikation• Transformieren von Datenbankanfragen

Die Schnittstelle für die Benutzerkommunikation wird benötigt, damit z.B.unterschiedliche homonyme Begriffe, wie sie in 7.3.5 Erwähnung finden, vomBenutzer ausgewählt werden können.

34 Unified Modelling Language (http://www.uml.org)

96

Abbildung 8.2 Interaktionsdiagramm für dieKommunikation mit der ODBT-Schnittstelle

Die Abbildung 8.2 zeigt die Kommunikation mit der ODBT-Prototyp-Schnittstellein einem UML-Interaktionsdiagramm. Hier werden exemplarisch die Schritteangegeben, die für die Transformation einer Datenbankanfrage mit der Feature-Regel notwendig sind. Die Schritte sind jeweils durchnummeriert. Für die Angabeder Klassennamen und Methoden werden die Bezeichnungen aus derImplementierung übernommen. In Schritt 6 der Abbildung wird die Feature-Regelfür die Transformation gesetzt, was zur Erstellung einer neuen Instanz der KlasseFeatureRule durch die Klasse TransformationEngine führt. Der Schritt9 gibt die zu transformierende Regel an die Klasse OdbtPrototype, was zumAufruf der Funktion parseSql(Query) an den die SqlParser Klasse führt.Diese extrahiert die erweiterbaren Ausdrücke (vgl. 7.1) und erweitert sie mit Hilfeder Klasse TransformationEngine. In Schritt 11 wird dann dastransformierte Anfrageergebnis abgefragt.

8.2.2 Umformungsprozessor

Der Umformungsprozessor bildet, wie bereits erwähnt, das Rückgrad derTransformation von Datenbankanfragen. Er verbindet Datenbank, Ontologie-Werkzeuge, Mapping und Umformungsregeln. Eine Übersicht der Klassenstrukturdes Umformungsprozessors ist in A.4.2 gegeben. Durch denTransformationsprozessor selbst werden aber keine Funktionen aus Kapitel 7

97

OdbtProtoype TransformationEngine

FeatureRuleSqlParser

2: new(mappingHandler, UserInteraction)7: addFeatureRule()

3: new(TransormationEngine, InputStream)10: parseSql(Query)12: getTransformedQuery() 8: new()

1: new()4: setMappingHandelr(MappingHandler)5: setUserInteraction(UserInteraction)6: addFeatureRule()9: setQuery(Query)11: getTransformedQuery()

OdbtConsole

umgesetzt.

Abbildung 8.3 Sequenzdiagramm für die Verarbeitungder PartWhole-Regel

Das Zusammenspiel der einzelnen Komponenten des Umformungsprozessorswird in Abbildung 8.3 durch ein UML-Sequenzdiagramm exemplarisch für eineTransformation mit der PartWhole-Regel dargestellt. Die folgende Tabelle zeigtübersichtlich den Bezug zu den in Kapitel 7 erarbeiteten konzeptuellen Verfahren:

Methode formale Darstellung Referenz

transformExpression(concept,value, query, namespace) ptw= ptw ,Q in ∣ =x t (7.1)

findHasPartInf(concept,namespace) C ptw=HasPartOfInf c (7.3.2.2)

getCorrespondences(concept,relationship[], query) x , ' PartOf ' (7.3.2.1)

cardinalityExtension(concept) ext( c )(7.3.2.2)

(7.5)

98

partOfInfConcepts]

transPartOfQuery

OntologyAccessPartWholeRule

findHasPartInf(concept, namespace)

transformExpression(concept, value, query, namespace)

Transformation-Engine CardinalityMapping

correspondences

mappingExtensions

getCorespondences(concept, relationship[], query)

cardinalityExtension(concept)

Cardinality-Correspondence

new()

Die Bildung von relevanten Korrespondenzen und Korrespondenz-Erweiterungenwird nicht direkt in den Regeln, sondern durch die abstrakte KlasseCardinalityMapping umgesetzt, die noch in 8.2.3 näher erläutert wird.

8.2.3 Mapping-Verarbeitung

Die Klassenstruktur für das Mapping ist so gestaltet, dass sie möglichst aufunterschiedliche Zugriffs- und Speicherverfahren erweiterbar ist. Dazu existiert,wie es in Abbildung 8.3. dargestellt ist, ein Interface35 MappingHandler undein Interface Correspondence, die jeweils für den Zugriff auf eineSpeicherstruktur implementiert werden müssen. Für den ODBT-Prototyp wurdeder Zugriff auf die XML-Mapping-Struktur implementiert, wie sie in Kapitel 5beschrieben wurde. Die Klasse CardinalityMappingHandler benutzt dieMethoden des MappingHandler Interface, hat aber noch zusätzlicheFunktionalität zum Finden von relevanten Korrespondenzen für dieTransformationsregeln (vgl. 7.3.2.1). Die CardinalityCorrespondenceKlasse besitzt Methoden zur Erzeugung von Korrespondenz-Erweiterungenext( c ) und Korrespondenz-Einschränkungen red( c ) für dieTransformationsregeln (vgl. 7.3.2.1).

Abbildung 8.4 Klassenstruktur der Klassen für denZugriff auf das Mapping

Die Zugriffsmethoden auf Mapping-Elemente sind im CorrespondenceInterface enthalten. Eine Übersicht über diese Methoden wird im UML-Klassendiagramm in A.4.3 dargestellt.

35 Der Begriff Interface wird anstelle von Schnittstelle verwendet, um den direkten Bezug auf dieKlassenstruktur herzustellen

99

<<Interface>>MappingHandler

MappingHandlerXml

<<Interface>>Correspondence CardinalityCorrespondence

CardinalityMappingHandler

CorrespondenceXml

erzeugt

benutzt

benutzt

implementiert

erzeugt

implementiert

Das Mapping zwischen Datenbank und Ontologie enthält noch zusätzlicheEinträge für verwendete RDBMS und Ontologie-Werkzeuge. Es wird somit derBezug von einem Mapping zu einer bestimmten Ontologie und einer bestimmtenDatenbank gebildet.

</DbConnection jdbcDriver="com.ibm.db2.jcc.DB2Driver" jdbcDSN="jdbc:db2://xxx" user="xxx" password="xxx" ></DbConnection> <!-- ontology connection parameters --> <OntConnection ontTool="SESAME"> <DbConnection dbName="MySQL" jdbcDriver="com.mysql.jdbc.Driver" jdbcDSN="jdbc:mysql://xxx" user="xxx" password="xxx" OntConnection>

Datenbank und Ontologie Parameter in der XML-Mapping-Struktur

8.2.4 Ontologie-Werkzeuge und Inferenzregeln

In A.4.4 ist das UML-Klassendiagramm für die Zugriffsschnittstelle aufOntologie-Werkzeuge und die Bildung von Inferenzregeln dargestellt. Die KlasseOntologyToolHandler bildet die abstrakte Basisklasse für dieKommunikation mit Ontologiewerkzeugen. Die abstrakte KlasseOntologyToolAccess erweitert die Klasse für Zugriffsmethoden auf dieOntolgie. Diese wurden hinreichend in Kapitel 7 beschrieben und sollen nichtweiter erklärt werden. Die abstrakte Klasse OntologyToolBuilder ist aucheine Erweiterung der OntologyToolHandler Klasse. In ihr sind dieMethoden zum Einfügen von RDF bzw. OWL Daten definiert. Die Funktionalitätfür diese abstrakten Klassen wird in eigenen Klassen für die beiden benutztenOntologie-Werkzeuge Sesame und Jena implementiert. Diese wurden ausführlichin Kapitel 4 beschrieben. Darauf aufbauend werden jetzt einigeImplementationsaspekte für die Verwendung der Ontologie-Werkzeuge analysiert.

Zunächst wird das Einbinden der für den Prototypen entwickelten Inferenzregelnbetrachtet.

Der bereits in Kapitel 4 erwähnte „Storage And Inference Layer“ (SAIL) desSesame-Ontologie-Werkzeugs ist bezüglich der Speicherung von RDF-Daten sehrflexibel konfigurierbar. Die Konfiguration wird durch die KlasseRdfSchemaRepositoryConfig vorgenommen. Für die Implementation desODBT-Prototypen wurde die Speicherung in einer MySql-Datenbank

100

vorgenommen. Der Zugriff erfolgt in Sesame über die JDBC-Schnittstelle. Dahermüssen die Angaben über den JDBC-Treiber, den DSN („Data Source Name“),den Benutzernamen und das Passwort übergeben werden. Die MethodesetInferencerClass(class) konfiguriert, dass selbst definierte Regelnangewendet werden. Mit der Methode setParameter() werden die Regeln indie Konfiguration eingebunden.

// Benutze Datenbank für die SpeicherungRdfSchemaRepositoryConfig rdbmsSail = new RdfSchemaRepositoryConfig(jdbcDriver,jdbcDNS,user,password);

// Bestimme dass eigene Inferenzregeln angewendet werdenrdbmsSail.setInferencerClass("org.openrdf.sesame.sailimpl.rdbms.CustomInferenceServices");

// Setze die Regeln für den SAILrdbmsSail.setParameter("rule-file",odbtRules);

Erstellung eines SAIL mit selbst definierten Inferenzregeln ineiner Datenbank

Mit dieser Konfigurierung kann ein neuer SAIL in das „Repository“ (vgl. Kapitel4), von Sesame hinzugefügt werden.

// Ein „ModellMaker“ für relationale DatenbankenModelMaker maker = ModelFactory.createModelRDBMaker(dbConnection);

// erstelle das Ontologie-ModelModel odbtModel = maker.createModel("odbt");

// Ein „Reasoner“ für selbst definierte InferenzregelnReasoner reasoner = new GenericRuleReasoner(Rule.parseRules

(odbtRules));// Erstelle das Inferierte Ontologie-ModelInfModel odbtInfModel = ModelFactory.createInfModel(reasoner,

odbtModel);

Erstellung eines inferierten Ontologie-Modells mit eigenenInferenzregeln

Für die Umsetzung der Speicherung in Jena wurde ebenfalls eine MySql-Datenbank verwendet. In Jena existieren verschiedene Ontologie-Modelle, die mitder ModelMaker Klasse gebildet werden. Die KlasseGenericRuleReasoner erlaubt es, eigene Inferenzregeln zu definieren. DieKlasse InfModel besitzt dann Zugriffsmechanismen auf das inferierteOntologie-Modell.

Für die Suche nach Konzepten und Beziehungen in der Ontologie wird in Sesamedie Anfragesprache SeRQL (vgl. 4.2) und in Jena die Anfragesprche RDQL (vgl.4.3) verwendet. Es soll hier für beide Sprachen ein Beispiel für eine Anfrage nach

101

allen inferierten PartOf-Beziehungen eines Konzeptes "PC" gegeben werden. DieVerwendung des Namensraums "http://localhost/" drückt aus, dass es sich nur umlokale, für Testzwecke verwendete Konzepte handelt.

SELECT x FROM {x} <po:partOfInf> {pr:product}USING NAMESPACE

po = <http://localhost/partof#>,pr = <http://localhost/product#>

Suche nach PartOf-Beziehungen für "PC" in Sesame

SELECT ?x WHERE (?x

<http://localhost/partOf#partOfInf > <http://localhost/odbt#product#PC>)

Suche nach PartOf-Beziehungen für "PC" in Jena

Für den Zugriff und das Einfügen auf die beiden Ontologie-Werkzeuge Jena undSesame wurden einige Laufzeittests durchgeführt, die in A.5 dargestellt undbeschrieben werden.

Mit dieser kurzen Betrachtung der in Jena und Sesame verwendeten Mechanismenzur Erstellung eines inferierten Ontologie-Graphen sollen die Ausführungen zurVerwendung der Ontologie-Werkzeugen beendet werden.

8.3 Benutzung der Beispiel-Datenbanken

Die in diesem Kapitel beschriebene Architektur des ODBT-Prototypen wurde alslauffähige Version auf den Rechnern am Lehrstuhl für Datenbanken undInformationssysteme implementiert. Die im Anhang A.1 dargestellten Beispiel-Ontologien, auf die sich öfter in der vorliegenden Arbeit bezogen wird, sind fürJena und Sesame in MySql-Datenbanken gespeichert. Die Beispiel-Ontologiensind zudem jeweils als eigenes RDF-XML vorhanden. Die Datenbankinhalte ausA.2 wurden in einer DB2-Datenbank gespeichert. Mit der in A.3 angegebenenXML-Mappping-Struktur wird das Mapping zwischen den Beispiel-Datenbankendefiniert. Der XML-Mapping-File enthält, wie in 8.2.3 dargestellt, die Angabenfür die Verbindung zur Datenbank und zum Ontologie-Werkzeug. Daher reicht esaus, diesen in den ODBT-Prototypen einzulesen, um eine lauffähigeTestumgebung zu erstellen. Für die konsolenbasierte Testumgebung wird der Pfadzum Mapping-File als zusätzlicher Parameter beim Aufruf des Programmsübergeben. Bei der graphischen Benutzeroberfläche wird der Mapping-File überden Menüpunkt "File" geöffnet. Mit einer so erstellten Testumgebung lässt sichdie ontolgogie-basierte Transformation von Datenbankanfragen für die Beispielein A.1 und A.2. durchführen.

102

Abbildung 8.5 Verwendung der konsolenbasiertenBenutzeroberfläche des ODBT-Prototypen

Abbildung 8.6 Verwendung der graphischenBenutzeroberfläche des ODBT-Prototypen

In Abbildung 8.5 ist die Ausführung der konsolenbasierten Benutzerschnittstelle

103

dargestellt. Das Programm wird durch den Aufruf des ausführbaren jar-File"odbtConsole.jar" gestartet. Es ist zu erkennen, wie eine SQL-Anfrage nach"macpc" auf das Attribut "name" in der Relation "product_1" gestellt wird.Ausgegeben wird die ursprüngliche Anfrage, die transformierte Anfrage und dasAnfrageergebnis für die ursprüngliche und transformierte Anfrage. In Abbildung8.6 ist die Ausführung des ODBT-Prototypen mit graphischer Benutzeroberflächezu sehen. Hier können auch durch Auswahlfelder die zu verwendendenTransformationsregeln ausgewählt werden. In der Abbildung ist dieBenutzerkommunikation zur Auswahl eines „immediate uncommon concept“ für"bank" dargestellt.

8.4 Durchgeführte Tests auf WordNet und GNIS

Um den Prototyp nicht nur auf den speziell für Testzwecke angelegtenDatenbanken und Ontologien zu testen, wurden jeweils eine real existierendeOntologie und Datenbank ausgewählt. Die Evaluation von geeigneten Ontologienwurde in Kapitel 2 vorgenommen. Wie dort beschrieben, wird die WordNet-Ontologie verwendet, welche anhand der GNIS36-Datenbank getestet wird. Dieseist eine frei verfügbare, geographische Datenbank, die Einträge von etwa 2Millionen geographischen und kulturellen Merkmalen in den Vereinigten Staatenund deren Territorien beinhaltet. Erstellt wurde sie vom „U.S. Geological Survey“und „U.S. Board on Geographic Names“. Diese Datenbank wurde gewählt, da diein ihr enthaltenen Namen der geographischen Merkmale eine relativ großeÜbereinstimmung mit den in WordNet enthaltenen Konzepten besitzen.

Die GNIS-Daten sind in einem eigenen Datenformat gespeichert und wurdenzunächst in ein IXF37-Format exportiert. Dieses ist ein Format zum plattform-unabhängigen Austausch von Strukturen und Daten in relationalen Datenbankenund wird von DB2 unterstützt. Die Größe der GNIS-Datenbank im nichtkomprimierten IXF-Format beträgt zur Zeit 667 Mb.

Import der GNIS-Datenbank:IMPORT FROM gnis.ixf OF IXF MESSAGES messages/log.txt CREATE INTO GNIS;

Für die Tests wurden die bereits vorhandenen Informationen in der GNISDatenbank genutzt. Die Relation "gnis", wie sie in A.2.5 angegeben ist, beinhaltetunter anderem die Attribute "feature_name" und "feature_type". Das Attribut"feature_name" definiert Instanzen, die ein geographisches oder kulturelles

36 „Geographic Names Information System“, URL http://geonames.usgs.gov/37 Integrated Exchange Format

104

Merkmal beschreiben, wie z.B. „John F. Kennedy Airport“. Das Attribut"feature_type" bezeichnet den Typ dieses Merkmals, was z.B. „airport“ wäre.Durch die Typdeklaration von "feature_type" auf "feature_name" wird eine ISA-Beziehung zwischen beiden Attributen gebildet. Man kann z.B. sagen „John F.Kennedy Airport“ ist ein „airport“.

Der Test wurde so durchgeführt, dass auf "feature_name" die Begriffe aus"feature_type" angefragt werden. Eine normale Anfrage sollte also keine Resultatezurückliefern, da in "feature_name" nicht die Typbeschreibungen vorhanden sind.Dies wird in Abbildung 8.7 für die Anfrage nach "feature_name = 'stream'"gezeigt. Es ist zu erkennen, dass die ursprüngliche Anfrage keine Ergebnissezurückliefert. Die transformierte Anfrage liefert im Vergleich dazu zusätzlicheTupel. Wie zu erkennen ist, besitzt eine Teilmenge der Tupel auch in der Spalte"feature_type" den Wert "stream". Diese Tupel werden als Tupel, die für dieAnfrage relevant sind, angesehen. Es werden aber auch Tupel gefunden, die für"feature_type" nicht den Wert "stream" haben. Diese werden als nicht relevanteTupel der Anfrage bezeichnet (vgl. 1.1). Daher kann mit dem gegebenenTestverfahren gut überprüft werden, inwieweit die transformierteDatenbankanfrage sinnvolle Anfrageergebnisse generiert.

Abbildung 8.7 Anfrage an die GNIS Datenbank

Eine Auswahl der Testergebnisse auf die GNIS-Datenbank ist in Tabelle 8.1 zusehen. Die Terme aus "feature_type" werden mit tfeature_type ausgedrückt. DieAnzahl der Tupel für die Anfrage durch Q' werden mit res(Q') und die relevantengefunden Tupel mit rel(Q') bezeichnet. Die insgesamt enthaltenen Tupel, die denTerm tfeature_type in "feature_type" haben, werden mit num(fea_type) angegeben.

105

tfeature_type res(Q') rel(Q') num(fea_type) Verwendeter Kontext in WordNetbay 20 18 12341 an indentation of a shoreline larger than a cove but

smaller than a gulf

bridge 13 13 5643 a structure that allows people or vehicles to cross anobstacle such as a river or canal or railway etc.

channel33 5 3936

a deep and relatively narrow body of water (as in a riveror a harbor or a strait linking two larger bodies) thatallows the best passage for vessels

dam 3 3 54261 a barrier constructed to contain the flow of water or tokeep out the sea

island 356 132 19825 a land mass (smaller than a continent) that is surroundedby water

mine 0 0 33292 excavation in the earth from which ores and minerals areextracted

sea 15 4 12 a division of an ocean or a large body of salt waterpartially enclosed by land

stream 215 78 87430 a natural body of running water flowing on or under theearth

Tabelle 8.1 Testanfragen an "feature_name" in derGNIS-Datenbank

Aus der Tabelle ist zu erkennen, dass zusätzliche Tupel für einige Begriffe aus"feature_type" in der Anfrage auf "feature_name" gefunden werden. In Relation zuden insgesamt enthaltenen Tupeln sind dies jedoch nur sehr wenige. Der Grunddafür liegt darin, dass WordNet nicht viele geographische Merkmale enthält, unddaher auch kaum Übereinstimmungen gefunden werden können. Idealer wäresicher eine domänenspezifische Ontologie über geographische und kulturelleMerkmale. Für die Abdeckung der Begriffe aus "feature_type" eignet sichWordNet aber sehr gut, da es für fast alle in "feature_type" enthaltenen Begriffeein korrespondierendes Konzept in WordNet gibt.

Mit dieser abschließenden Betrachtung zur Verwendung von real existierendenDatenbanken und real existierenden Ontologien, speziell für GNIS und WordNet,soll dieses Kapitel beendet werden.

106

Kapitel 9

Zusammenfassung

In der hier vorliegenden Arbeit wurden mögliche Verfahren zur Umsetzung derontologie-basierten Anfragetransformation erarbeitet wie sie in [28-31]beschreiben werden. Aufbauend auf diesen Verfahren wurde ein Prototyp für einAnfragebearbeitungssystem entwickelt, der eine von Benutzern spezifiziertenAnfragen transformiert und über die neu gebildete Anfrage auf eine Datenbankzugreift.

In Kapitel 2-4 wurden zur Umsetzung des Prototyps die benötigten Grundlagenerarbeitet. Zunächst wurde der Begriff „Ontologie“ und Ontologien in einemerweiterten Kontext erklärt. Die Möglichkeit des Inferieren neuen Wissens ist einwichtiges Kriterium für die Umsetzung der Transformationsregeln. Daher wurdendie grundlegenden Formalismen zur wissensbasierten Modellierung vorgestellt.Auf die dort beschriebenen Formalismen von F-Logic und denBeschreibungslogiken bauen die in Kapitel 3 beschrieben Ontologie-Sprachen auf.Diese, in existierenden Ontologie-Werkzeugen benutzten Ontologie-Sprachen,wurden in Hinblick auf die Abdeckung des in [28-31] spezifizierten und für dieTransformation der Anfrage benötigten Ontologie-Modells untersucht. Für dieSprachen wurde eine kurze Übersicht der historischen Entwicklung gegeben,wobei die neueren, internetbasierten Ontologie-Sprachen eingehender betrachtetwurden.. Die meisten der internetbasierten Ontologie-Sprachen bauen auf dasRDF-Modell auf, für welches die später benötigten Konzepte zur Speicherung vonOntologien erklärt wurden. Es wurden die Möglichkeiten diskutiert RDF(S) undOWL auf das in [28-31] definierte und für die Anfragetransformation benutzteOntologie-Modell abgebildet. Die Umsetzung der PartOf-Beziehung stellte sich indiesem Zusammenhang problematisch dar, da sie in keiner Ontologie-Sprache alsModellierungsprimitiv vorhanden ist. Es wurde aber argumentiert, dass sich OWLzur Umsetzung eignet, da es ausreichende Umschreibungsmöglichkeiten für diePartOf-Beziehung besitzt. Aus den beschriebenen Ontologie-Werkzeugen inKapitel 4 wurden für die spätere Implementierung Sesame und Jena verwendet.Für diese wurden die Architektur und die Möglichkeiten der Inferenzbildungdiskutiert.

107

Kapitel 5-6 beschäftigen sich mit dem für den ODBT-Prototypen benötigtenMapping zwischen Ontologie und Datenbank. Da existierende Ansätze nicht diebenötigte Aussagekraft für die Bildung von Korrespondenzen zwischenKonzepten in der Ontologie und Extensionsbereichen in der Datenbank besitzen,wurde eine eigene, deklarative Beschreibungsform für das Mapping entwickelt.Dabei wurde zwischen Mapping auf Schema- und Instanzebene unterschiedenund jeweils auf die sinnvollen Korrespondenzen eingeschränkt. Die sinnvollenKorrespondenzen wurden anhand der im Prototypen verwendeten XML-Syntaxeinzeln erklärt. Aufbauend auf der so erstellten Mapping-Struktur wurden inKapitel 6 Algorithmen zum automatischen Generieren von Korrespondenzen fürdas Mapping geliefert. Hier wird sich vor allem an die Ausführungen von E.Rahm & P. A. Bernstein in [33] gehalten, um die dort vorgestellten Methoden aufdie eigenen Anforderungen zu übertragen. Das vorgestellte Top-Down-Verfahrengeneriert zunächst Korrespondenzen mit Mapping-Elementen höhererGranularität, und geht dann zu Korrespondenzen mit Mapping-Elementenniedrigerer Granularität über.

Aufbauend auf den Ausführungen in den Kapiteln 2-6 wurde in Kapitel 7 diekonzeptionelle Umsetzung der Anfragetransformation erarbeitet. Es wurdenVerfahren entwickelt, wie sich für die in [28,30-31] entwickeltenTransformationsregeln erweiterte Ausdrücke bilden lassen. Im Vergleich zu denAusführungen in [28,30-31] werden keine Graphoperationen zum Finden vonKonzepten in der Ontologie verwendet, sondern direkt auf den inferierten Graphenzugegriffen. Hierzu wurden die benötigten Mechanismen zur Inferenzbildunganhand der Transformationsregeln erarbeitet. Für die umgesetztenTransformationsregeln wurden schließlich jeweils die exakten Verfahren definiert,die einen transformierten Ausdruck mit Hilfe des Mapping und der Ontologieerstellen.

In Kapitel 8 wurde gezeigt, wie es möglich ist, die in Kapitel 7 entwickeltenVerfahren in eine Architektur umzusetzen. Dazu wurde auf die implementierteKlassenstruktur eingegangen und das Zusammenspiel der wichtigstenSystemkomponenten erklärt. Zum Ende des Kapitels wurde die Benutzung derimplementierten Beispiel-Ontologien und Beispiel-Datenbanken erläutert. DieAusführungen wurden dann durch die Beschreibung von angewendetenTestverfahren auf der GNIS-Datenbank und der WordNet-Ontologie beendet.

108

ANHANG

A.1 Beispiel-Ontologie-Graphen

Die hier gegebenen Ontologie-Graphen sind bis auf kleine Änderungen denAusführungen aus [28, 30] entnommen. Sie wurden wie hier abgebildet innerhalbdes Persistenz-Subsystem der Ontologie-Werkzeugen Jena und Sesame für denODBT-Prototypen erstellt.

A.1.1 Produkt-Ontologie

109

product

electronicnon-electronic

car

vehicle

fullsize-vanminivan

van

clothes screen

tv-screen

computer

palmtopnotebookpc

calculator

data-processor

lcd-monitor

macpc intelpc

applepc

keyboardmonitordektop

Normal-monitor

tube

key

ISA

PartOf

SynOf

display

A.1.2 Biologie-Ontologie

A.1.3 Frucht-Ontologie

110

molecule

non-polymer

polymer

proteindna

amino-acid

rna

poly-phosphate

oxygen carbon

phosphorus

atom

deoxyribo-nucleotide

nucleotide

ribo-nucleotideISA

PartOf

water

carbon-dioxide

object

abstract-object

physical-object

orange

fruit

red-appleyellow-apple

apple

taste

bittermildsweet

color

yellow greenred

bitter-green-apple ISA

ISAspecific

hasColor

hasTaste

A.1.4 Entitäten-Ontologie

111

anything

objectabstraction

relation artifact

Exchange-medium

communication

time organism

depository

museum

palmtopnotebookmetal

bank

substance

animal person

formationdevicefacility

ISA

made-of

used-for

fluidmaterial

palmtopnotebook earthclay

language

money

coins fund

ridgehill

bankdune

electronic-device

non-electronic-

devicecomputer

filterholder

saddlecontainer

bankbottle

save

A.2 Anfrage-Datenbanken

Die in tabellarischer Form dargestellten Datenbanken sind an die Ausführungen in[28, 30] angelehnt. Außerdem wird das Datenbank-Schema der GNIS-Datenbankangegeben. Die Datenbanken sind so wie hier angegeben in der DB2-Datenbankauf die der ODBT-Prototypen zugreift enthalten. Sie sind geeigneten für Tests derverschiedenen Transformationsregeln.

A.2.1 Produkt-Datenbank

112

A.2.2 Biologie-Datenbank

113

A.2.3 Frucht-Datenbank

A.2.4 Lager-Datenbank

A.2.5 GNIS-Datenbank

114

A.2.6 Waren-Datenbank

115

A.3 XML-Mapping-Struktur

• Für das Mapping, wie es in Kapitel 5 behandelt wird, ist hier dieDatentypdefinition angegeben.

• Es werden die Mapping-Files für die Verwendung der Beispieldatenbanken(A.2.1–A.2.4,A.2.6) und der Beispiel-Ontologien (A.1.1–A.1.4) dargestellt.Zusätzlich ist das Mapping zwischen WordNet und der GNIS-Datenbankgegeben.

A.3.1 Datentypdefinition für Mapping-Dateien<!-- Database Ontology Map Document Type Definition --><!-- Version 0.1 / 31.7.2005 / Bjoern Boesenberg --> <!ELEMENT DbOntMapping ((DbConnection), (OntConnection),(DbRelationOntConceptMapping | DbRelationOntRelationshipMapping |DbAttributeOntRelationshipMapping | DbRelationOntPropertyMapping)*) ><!ATTLIST DbOntMapping

name CDATA #REQUIRED>

<!ELEMENT OntConnection ((DbConnection | XmlFile)?, Namespace+,OdbtRelationships) ><!ATTLIST OntConnection

ontTool (JENA|SESAME|IBM) #REQUIRED><!ELEMENT DbConnection EMPTY><!ATTLIST DbConnection

dbName (MySQL|PostgreSQL|Oracle|DB2) #REQUIREDjdbcDriver CDATA #REQUIREDjdbcDSN CDATA #REQUIREDuser CDATA #IMPLIEDpassword CDATA #IMPLIED

><!ELEMENT XmlFile EMPTY><!ATTLIST XmlFile

fileName CDATA #REQUIRED><!ELEMENT Namespace EMPTY><!ATTLIST Namespace

uri CDATA #REQUIRED><!ELEMENT OdbtRelationships (IsARelationship , PartOfRelationship ,HasPartRelationship, SynonymRelationship , IsASpecificRelationship) ><!ELEMENT IsARelationship (PrimaryRelationship ,(SecondaryRelationship)*) >

116

<!ELEMENT PartOfRelationship (PrimaryRelationship ,(SecondaryRelationship)*) ><!ELEMENT HasPartRelationship (PrimaryRelationship ,(SecondaryRelationship)*) ><!ELEMENT SynonymRelationship (PrimaryRelationship ,(SecondaryRelationship)*) ><!ELEMENT IsASpecificRelationship (PrimaryRelationship ,(SecondaryRelationship)*) ><!ELEMENT PrimaryRelationship EMPTY><!ATTLIST PrimaryRelationship

url CDATA #REQUIRED><!ELEMENT SecondaryRelationship EMPTY><!ATTLIST SecondaryRelationship

url CDATA #REQUIRED><!ELEMENT DbRelationOntConceptMapping (DbRelation, OntConcept) ><!ELEMENT DbRelationOntRelationshipMapping (DbRelation,OntRelationship, (ProjectionFrom, ProjectionTo)?) ><!ELEMENT DbAttributeOntRelationshipMapping (DbRelation?,OntRelationship, (ProjectionFrom, ProjectionTo)?) ><!ELEMENT DbRelationOntPropertyMapping (DbRelation, OntProperty) >

<!ELEMENT ProjectionFrom ((DbRelation) | (DbAttribute, DbRelation)) ><!ELEMENT ProjectionTo ((DbRelation) | (DbAttribute, DbRelation)) > <!ELEMENT ForeignKeyTo (DbRelation) ><!ELEMENT DbRelation (DbAttribute)* ><!ATTLIST DbRelation

name CDATA #REQUIRED><!ELEMENT DbAttribute ((DbInstance)*,(ForeignKeyTo)?) ><!ATTLIST DbAttribute

name CDATA #REQUIRED><!ELEMENT DbInstance EMPTY > <!ATTLIST DbInstance

name CDATA #REQUIRED><!ELEMENT OntConcept EMPTY ><!ATTLIST OntConcept

url CDATA #REQUIRED><!ELEMENT OntRelationship (OntSubject?, OntObject?) ><!ATTLIST OntRelationship

url CDATA #REQUIRED><!ELEMENT OntProperty (OntClass)? ><!ATTLIST OntProperty

url CDATA #REQUIRED><!ELEMENT OntSubject EMPTY><!ATTLIST OntSubject

url CDATA #REQUIRED>

117

<!ELEMENT OntObject EMPTY><!ATTLIST OntObject

url CDATA #REQUIRED><!ELEMENT OntClass EMPTY><!ATTLIST OntClass

url CDATA #REQUIRED>

A.3.2 Ontologie- und Datenbankdefinitionen <DbConnection dbName="DB2" jdbcDriver="com.ibm.db2.jcc.DB2Driver" jdbcDSN="jdbc:db2://xxx" user="xxx" password="xxx" ></DbConnection> <!-- ontology connection parameters --> <OntConnection ontTool="xxx"> <DbConnection dbName="MySQL" jdbcDriver="com.mysql.jdbc.Driver" jdbcDSN="jdbc:mysql://xxx" user="xxx" password="xxx" ></DbConnection> <Namespaceuri="http://localhost/ontologies/product/"></Namespace> <Namespace uri="http://localhost/ontologies/fruit/"></Namespace> <Namespace uri="http://localhost/ontologies/bio/"></Namespace> <Namespaceuri="http://localhost/ontologies/entities/"></Namespace> <Namespace uri="http://www.unine.ch/knowler/wordnet"></Namespace> <OdbtRelationships> <IsARelationship> <PrimaryRelationship url="http://www.w3.org/2000/01/rdf-schema#subClassOf" /> <SecondaryRelationshipurl="http://www.unine.ch/knowler/wordnet#hyponymOf" /> </IsARelationship> <PartOfRelationship> <PrimaryRelationshipurl="http://localhost/ontologies/partWhole/#partOf" /> <SecondaryRelationshipurl="http://www.unine.ch/knowler/wordnet#pMeronym" /> </PartOfRelationship> <HasPartRelationship> <PrimaryRelationshipurl="http://localhost/ontologies/partWhole/#hasPart" /> </HasPartRelationship> <SynonymRelationship> <PrimaryRelationshipurl="http://www.w3.org/2002/07/owl#equivalentClass" /> <SecondaryRelationshipurl="http://www.unine.ch/knowler/wordnet#simlilarTo" /> </SynonymRelationship> <IsASpecificRelationship> <PrimaryRelationshipurl="http://localhost/ontologies/odbt/#specificSubClass" /> </IsASpecificRelationship> </OdbtRelationships>

118

A.3.3 Mapping Produkt-Datenbank / Produkt-Ontologie

<!-- 1:n mapping sample --> <DbAttributeOntRelationshipMapping> <DbRelation name="PRODUCT_COMPONENT_1N"> <DbAttribute name="P_ID"> <ForeignKeyTo> <DbRelation name="PRODUCT_2"> <DbAttribute name="ID"></DbAttribute> </DbRelation> </ForeignKeyTo> </DbAttribute> </DbRelation> <OntRelationshipurl="http://localhost/ontologies/partWhole/#partOf"></OntRelationship> <ProjectionFrom> <DbRelation name="PRODUCT_COMPONENT_1N"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="PRODUCT_2"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping> <!-- n:m mapping sample --> <DbRelationOntRelationshipMapping> <DbRelation name="PRODUCT_COMPONENT_NM"></DbRelation> <OntRelationshipurl="http://localhost/ontologies/partWhole/#partOf"></OntRelationship> <ProjectionFrom> <DbAttribute name="C_ID"> <ForeignKeyTo> <DbRelation name="PRODUCT_1"> <DbAttribute name="ID"></DbAttribute> </DbRelation> </ForeignKeyTo> </DbAttribute> <DbRelation name="PRODUCT_1"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbAttribute name="P_ID"> <ForeignKeyTo> <DbRelation name="PRODUCT_1"> <DbAttribute name="ID"></DbAttribute> </DbRelation> </ForeignKeyTo> </DbAttribute> <DbRelation name="PRODUCT_1"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionTo> </DbRelationOntRelationshipMapping>

119

A.3.4 Mapping Frucht-Datenbank / Frucht-Ontologie <!-- 1:1 mapping sample --> <DbAttributeOntRelationshipMapping> <DbRelation name="FRUITS"> <DbAttribute name="COLOR"></DbAttribute> </DbRelation> <OntRelationship url="http://localhost/ontologies/fruit/#has-color"></OntRelationship> <ProjectionFrom> <DbRelation name="FRUITS"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="FRUITS"> <DbAttribute name="COLOR"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping> <!-- n:1 mapping sample --> <DbAttributeOntRelationshipMapping> <DbRelation name="FRUITS"> <DbAttribute name="T_ID"> <ForeignKeyTo> <DbRelation name="FRUITS_TASTE_N1"> <DbAttribute name="ID"></DbAttribute> </DbRelation> </ForeignKeyTo> </DbAttribute> </DbRelation> <OntRelationship url="http://localhost/ontologies/fruit/#has-taste"></OntRelationship> <ProjectionFrom> <DbRelation name="FRUITS"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="FRUITS_TASTE_N1"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping>

A.3.5 Mapping Biologie-Datenbank / Biologie-Ontologie

<!-- 1:1 mapping sample --> <DbAttributeOntRelationshipMapping> <DbRelation name="BIO_TERMS_COMPONENT_11"> <DbAttribute name="COMPONENT"></DbAttribute> </DbRelation> <OntRelationshipurl="http://localhost/ontologies/partWhole/#partOf"></OntRelationship> <ProjectionFrom> <DbRelation name="BIO_TERMS_COMPONENT_11"> <DbAttribute name="COMPONENT"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="BIO_TERMS_COMPONENT_11"> <DbAttribute name="NAME"></DbAttribute> </DbRelation>

120

</ProjectionTo> </DbAttributeOntRelationshipMapping> <!-- n:m mapping sample --> <DbRelationOntRelationshipMapping> <DbRelation name="BIO_TERMS_COMPONENT_NM"></DbRelation> <OntRelationshipurl="http://localhost/ontologies/partWhole/#partOf"></OntRelationship> <ProjectionFrom> <DbAttribute name="C_ID"> <ForeignKeyTo> <DbRelation name="BIO_TERMS_1"> <DbAttribute name="ID"></DbAttribute> </DbRelation> </ForeignKeyTo> </DbAttribute> <DbRelation name="BIO_TERMS_1"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbAttribute name="T_ID"> <ForeignKeyTo> <DbRelation name="BIO_TERMS_1"> <DbAttribute name="ID"></DbAttribute> </DbRelation> </ForeignKeyTo> </DbAttribute> <DbRelation name="BIO_TERMS_1"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionTo> </DbRelationOntRelationshipMapping> <!-- 1:n mapping sample --> <DbAttributeOntRelationshipMapping> <DbRelation name="BIO_TERMS_COMPONENT_1N"> <DbAttribute name="C_ID"> <ForeignKeyTo> <DbRelation name="BIO_TERMS_2"> <DbAttribute name="ID"></DbAttribute> </DbRelation> </ForeignKeyTo> </DbAttribute> </DbRelation> <OntRelationshipurl="http://localhost/ontologies/partWhole/#partOf"></OntRelationship> <ProjectionFrom> <DbRelation name="BIO_TERMS_COMPONENT_1N"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="BIO_TERMS_2"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping>

A.3.6 Mapping Waren-Datenbank / Waren-Ontologie <!-- 1:1 mapping sample --> <DbAttributeOntRelationshipMapping> <OntRelationship url="http://www.w3.org/2000/01/rdf-schema#subClassOf"></OntRelationship> <ProjectionFrom> <DbRelation name="GOODS_TYPE_11">

121

<DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="GOODS_TYPE_11"> <DbAttribute name="TYPE"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping> <!-- n:m mapping sample --> <DbRelationOntRelationshipMapping> <DbRelation name="GOODS_TYPE_NM"></DbRelation> <OntRelationship url="http://www.w3.org/2000/01/rdf-schema#subClassOf"></OntRelationship> <ProjectionFrom> <DbAttribute name="G_ID"> <ForeignKeyTo> <DbRelation name="GOODS_1"> <DbAttribute name="ID"></DbAttribute> </DbRelation> </ForeignKeyTo> </DbAttribute> <DbRelation name="GOODS_1"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbAttribute name="T_ID"> <ForeignKeyTo> <DbRelation name="GOODS_1"> <DbAttribute name="ID"></DbAttribute> </DbRelation> </ForeignKeyTo> </DbAttribute> <DbRelation name="GOODS_1"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionTo> </DbRelationOntRelationshipMapping> <!-- 1:n mapping sample --> <DbAttributeOntRelationshipMapping> <DbRelation name="GOODS_TYPE_1N"> <DbAttribute name="G_ID"> <ForeignKeyTo> <DbRelation name="GOODS_2"> <DbAttribute name="ID"></DbAttribute> </DbRelation> </ForeignKeyTo> </DbAttribute> </DbRelation> <OntRelationship url="http://www.w3.org/2000/01/rdf-schema#subClassOf"></OntRelationship> <ProjectionFrom> <DbRelation name="GOODS_2"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="GOODS_TYPE_1N"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping> <!-- n:1 mapping sample --> <DbAttributeOntRelationshipMapping> <DbRelation name="GOODS_3"> <DbAttribute name="T_ID"> <ForeignKeyTo> <DbRelation name="GOODS_TYPE_N1">

122

<DbAttribute name="ID"></DbAttribute> </DbRelation> </ForeignKeyTo> </DbAttribute> </DbRelation> <OntRelationship url="http://www.w3.org/2000/01/rdf-schema#subClassOf"></OntRelationship> <ProjectionFrom> <DbRelation name="GOODS_3"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="GOODS_TYPE_N1"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping>

A.3.7 Mapping Lager-Datenbank / Entitäten-Ontologie

<!-- 1:1 mapping sample --> <DbAttributeOntRelationshipMapping> <OntRelationship url="http://localhost/ontologies/entities/#used-for"></OntRelationship> <ProjectionFrom> <DbRelation name="STORE"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="STORE"> <DbAttribute name="USE"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping> <!-- 1:1 mapping sample --> <DbAttributeOntRelationshipMapping> <OntRelationship url="http://localhost/ontologies/entities/#made-of"></OntRelationship> <ProjectionFrom> <DbRelation name="STORE"> <DbAttribute name="NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="STORE"> <DbAttribute name="MADE"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping>

123

A.3.8 Mapping GNIS-Datenbank / WordNet-Ontologie

<DbAttributeOntRelationshipMapping> <DbRelation name="GNIS"> <DbAttribute name="COMPONENT"></DbAttribute> </DbRelation> <OntRelationshipurl="http://localhost/ontologies/partWhole/#partOf"></OntRelationship> <ProjectionFrom> <DbRelation name="GNIS"> <DbAttribute name="STATE"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="GNIS"> <DbAttribute name="FEATURE_NAME"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping> <DbAttributeOntRelationshipMapping> <DbRelation name="GNIS"> <DbAttribute name="COMPONENT"></DbAttribute> </DbRelation> <OntRelationshipurl="http://localhost/ontologies/partWhole/#partOf"></OntRelationship> <ProjectionFrom> <DbRelation name="GNIS"> <DbAttribute name="STATE"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="GNIS"> <DbAttribute name="COUNTY_NAME"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping> <DbAttributeOntRelationshipMapping> <DbRelation name="GNIS"> <DbAttribute name="COMPONENT"></DbAttribute> </DbRelation> <OntRelationshipurl="http://localhost/ontologies/partWhole/#partOf"></OntRelationship> <ProjectionFrom> <DbRelation name="GNIS"> <DbAttribute name="COUNTY_NAME"></DbAttribute> </DbRelation> </ProjectionFrom> <ProjectionTo> <DbRelation name="GNIS"> <DbAttribute name="FEATURE_NAME"></DbAttribute> </DbRelation> </ProjectionTo> </DbAttributeOntRelationshipMapping>

124

A.4 UML-Klassen-Diagramme derImplementierung

• Die hier dargestellten UML-Klassen-Diagramme beziehen sich auf die Java-Implementation des ODBT-Prototypen. Die UML-Darstellung des Prototypen,die hier gegeben ist, ist nicht vollständig. Es fehlen einige Klassen, wie z.B.alle Exception- oder Helfer-Klassen die nicht für das Verständnis des Systems,oder direkt für die Anfragetransformation, benötigt werden. So fehlen dieKlassen zum Generieren der Tests und Klassen zum Erstellen der Ontologienund Datenbanken. Außerdem wurden so gut wie alle privaten Methoden derhier dargestellten Klassen nicht dargestellt. Nur da wo es zum Verständnis derArchitektur beiträgt werden sie angegeben.

• Die Verwendung der Programmierschnittstelle kann am besten anhand derDatei "de.hu.odbt.odbtPrototype.OdbtPrototypeConsole.java" nachvollzogenwerden.

• Klassen für die Benutzerschnittstelle befinden sich im Paket"de.hu.odbt.odbtPrototyp". Die Klassen, zur Ansprache der Ontologie-Werkzeuge befinden sich im Paket "de.hu.odbt.ontologyTools". Für denZugriff auf das Mapping benötigte Klassen sind im Paket"de.hu.odbt.ontDbMapping". Die Klassen zum Einlesen von Ontologien sindim Paket "de.hu.odbt.ontologyCreation" enthalten. Die Klassen für diedurchgeführten Tests sind im Paket "de.hu.odbt.odbtTesting". Klassen derHelfer-Klassen sind im Paket "de.hu.odbt.odbtUtility" zu finden.

125

A.4.1 Implementierung des ODBT-Prototyp

126

A.4.2 Implementierung des Umformungsprozessors

127

A.4.3 Implementierung der Mapping-Verarbeitung

128

A.4.4 Integration der Ontologie-Werkzeugen undInferenzregeln

129

A.4.5 Implementierung der Umformungsregeln

130

A.5 Testreihen zum Performanzvergleich vonSesame und Jena

• Die hier angegebenen Tests wurden zur Performanz-Analyse der Ontologie-Werkzeuge Jena und Sesame erstellt. Sie wurden unter Verwendung der Java-Klassen-Bibliothek JFreeChart erstellt.

• Die Tests wurden unter Verwendung der in 7.2 entwickelten Inferenzregeln fürden ODBT-Prototypen durchgeführt.

A.5.1 Suche nach ISA(c)

Für diesen Test werden alle zu einem Konzept in ISA-Beziehungen stehendenKonzepte gesucht. Das Diagramm verdeutlicht, dass Sesame im Vergleich zu Jenabessere Laufzeiteigenschaften besitzt. Außerdem ist zu erkennen, dass die ersteAnfrage in Jena deutlich längere Laufzeit als die darauf folgenden Anfragenbenötigt. Der Grund hierfür ist, dass Jena für die erste Anfrage zunächst dieInferenz über den Ontologie-Graphen bildet.

131

A.5.2 Initialisierung der Ontologie-Werkzeuge

Das Testdiagramm gibt die benötigte Zeit für die Initialisierung der Ontologie-Werkzeuge für unterschiedlich viele, in der Ontologie enthaltener, Aussagen an.Für Sesame ist die Zeit konstant, da der inferierte Graph persistent in derDatenbank gehalten wird. Für die Initialisierung von Jena ist zu erkennen, dassmit zunehmenden, bereits enthaltener Aussagen die Verarbeitungszeitexponentiell ansteigt. Dies kann durch die steigende Komplexität derInferenzbildung erklärt werden.

132

A 5.3 Sequenzielles Einfügen von RDF-Aussagenmit ISA- und PartOf-Beziehung

Das Testdiagramm zeigt die benötigte Zeit zum Einfügen von Aussagen in RDF,die mit der ISA- und PartOf-Beziehungen verbunden sind. In Jena ist ein linearerVerlauf zu erkennen. Der Grund ist, dass die Aussagen nur eingefügt werden aberkeine Inferenzbildung stattfindet. In Sesame findet die Inferenzbildung zur Zeitder Einfügeoperationen persistent in der Datenbank statt, wodurch dieexponentiell ansteigende Kurve zu erklären ist.

133

Literaturverzeichnis

[1] I. Astrova: Reverse Engineering of Relational Databases to Ontologies in C.Bussler, J. Davies, D. Fensel, R. Studer (Herausgeber): The Semantic Web:Research and Applications, First European Semantic Web Symposium, ESWS2004, Heraklion, Crete, Greece, 2004, Seite 327-341

[2] J. Barrasa, O. Corcho, A. Gómez-Pérez: R2O, an Extensible andSemantically based Database-to-ontology mapping Language, SecondWorkshop on Semantic Web and Databases (SWDB2004). Toronto, Canada,2004.

[3] J. Barrasa, O Corcho, A. Gómez-Pérez: Fund Finder: A case study ofdatabase-to-ontology mapping, Semantic Integration Workshop (ISWC 2003)Sanibel Island, Florida, 2003

[4] Y. An, . Borgida, J. Mylopoulos: Refining Semantic Mappings fromRelational Tables to Ontologies, Semantic Web and Databases, SecondInternational Workshop (SWDB 2004), Toronto, Canada, 2004, Seite 84-90

[5] C. Bizer: D2R MAP – A Database to RDF Mapping Languages, 12 WorldWide Web Conference, Budapest, 2003.

[6] D. Brickley, R. V. Guha: RDF Vocabulary Description Language 1.0: RDFSchema, 2004URL http://www.w3.org/TR/rdf-schema/

[7] J. Broekstra, A. Kampman: Inferencing and Truth Maintenance in RDFSchema: exploring a naive practical approach, Second International SemanticWeb Conference (ISWC), Florida, 2003 URL http://www.cs.vu.nl/~jbroeks/papers/inferencing.pdf

[8] B. Chandrasekaran, J. R. Josephson, V. R. Benjamins: What AreOntologies, and Why Do We Need Them? IEEE Intelligent Systems, Vol. 14,No. 1, 1999, Seite 20-26URL http://www.cs.umbc.edu/771/papers/chandrasekaranetal99.pdf

[9] R. H. L. Chiang, T. M. Barron, V. C. Storey: Reverse engineering ofrelational databases. Data Knowl. Eng. 12(2):, 1994 Seite 107-142

[10] T. R. Gruber: Towards Principles for the Design of Ontologies Used forKnowledge Sharing. in N. Guarino und R. Poli (Herausgeber), FormalOntology in Conceptual Analysis and Knowledge Representation. KluwerAcademic Publishers, Deventer, Niederlande, 1993

134

[11] T.R. Gruber: A translation approach to portable ontology specification,Proc. Int’l. Con. on Principles of Knowledge Representation and Reasoning,2000, San Francisco, 2000, Seite 471–482

[12] N. Guarino, C. Masolo, G. Vetere: OntoSeek: Content-Based Access to theWeb in IEEE Intelligent Systems & their apllications, 1998, S. 70-80

[13] P. Haase, J. Broekstra, A. Eberhart, R. Volz: A Comparison of RDFQuery Languages, INProceedings of the Third International Semantic WebConference, Hiroshima, Japan, 2004URL http://www.aifb.uni-karlsruhe.de/WBS/pha/rdf-query/

[14] P. Hayes: RDF Semantics, 2004 URL http://www.w3.org/TR/rdf-mt/

[15] G. van Heijst, A. T. Schreiber, B.J. Wielinga: Using explicit ontologies inKBS development in International Journal of Human-Computer Studies, 1997,S. 183-293

[16] O. Lassila, D. Mc Guinness: The Role of Frame-Based Representation onthe Semantic Web in Knowledge System Laboratory, Knowledge SystemsLaboratory Report KSL-01-02. Stanford University, 2001

[17] O. Lassila: Taking the RDF Model Theory Out For a Spin, in proceedings ofthe 1 International Semantic Web Conference, Sardinien, 2002

[18] R. Studer, H. Oppermann, H.-P. Schnurr: Die Bedeutung von Ontologienfür das Wissensmanagement, Institut AIFB, Universität Karlsruhe, September2001 URL http://www.ontoprise.de/documents/Bedeutung_von_Ontologien_fuer_WM.pdf

[19] D. Fensel, J. Hendler, H. Lieberman, W. Wahlster: Spinning the SemanticWeb, MIT Press., Massachusetts, 2003

[20] A. Gómez-Pérez, M. Frenández-Lopéz, O. Corcho: OntologicalEngineering, London, 2004

[21] A. Gómez-Pérez: A Survey on Ontology Tools, OntoWeb deliverable 1.3,2001 URL http://ontoweb.aifb.uni-karlsruhe.de/About/Deliverables/D13_v1-0.zip

[22] J. Große: Speicherverfahren und Werkzeuge für RDF/S, Berlin, 2003URL http://www.xml-clearinghouse.de/reports/

[23] J. Madhavan, P. A. Bernstein, E. Rahm: Generic Schema Matching withCubid IN Proceedings of the 7th VLDB Conference, Rom, 2001

[24] J. Madhavan, P. A. Bernstein, P. Domingos, A. Y. Halevy: Representingand Reasoning about Mappings between Domain Models, IN Eighteenthnational conference on Artificial intelligence, Seite 80-86 , Alberta, Canada2002

135

[25] F. Manola, E. Miller: RDF Primer, 2004URL http://www.w3.org/TR/rdf-primer/

[26] D. L. McGuiness, F. Van Harmelen: OWL Web Ontologie Language, 2004URL http://www.w3.org/TR/2004/REC-owl-features-20040210/

[27] R. Mizoguchi, J. Vanwelkenhuysen, M. Ikeda: Task Ontology for reuse ofproblem solving knowledge in N. Mars (Herausgeber): Towards Very LargeKnowledge Bases, 1995 , Amsterdam, Seite 87-96

[28] C. B. Necib, J. C. Freytag: Query Processing using Ontologies, INProceedings of the 17th Conference on Advanced Information SystemsEngineering (CAISE'05), Porto, Portugal, 2005/06

[29] C. B. Necib: mappings between Ontologies and Databases, Berlin, 2005

[30] C. Necib, J.-C. Freytag: Using Ontologies for Database Reformulation,Proceedings of the 18th Conference on Advances in Databases and InformationSystems (ADBIS'04), Budapest, Hungary, 2004/09

[31] C. B. Necib, J.-C. Freytag: Semantic Query Transformation usingOntologies, Proceedings of the 9th International Database Applications andEngineering Symposium (IDEAS'05). Monteral, Cananda, 2005/07

[32] D. Oberle: Mythologie der Informatik, Universität Karlsruhe, Karlsruhe,2001URL http://www.aifb.uni-karlsruhe.de/WBS/dob/docs/informatik.pdf

[33] E. Rahm, P. A. Bernstein: A survey of approaches to automatic schemamatching, The VLDB Journal, Vol. 10, No. 4., Seiten 334-350, 2001

[34] A. Rector: Welty Simple part-whole relations in OWL Ontologies, 2005, URL http://www.cs.man.ac.uk/~rector/swbp/simple-part-whole/simple-part-whole-relations-v0-2.html

[35] S. Staab, R. Studer: Handbook on Ontologies, International Handbooks onInformation Systems, Berlin, 2004

[36] P.H. Winston: Artificial intelligence at MIT : expanding frontiers,Cambridge, Mass., 1990

136

Selbständigkeitserklärung

Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig und nur unterVerwendung der angegebenen Quellen und Hilfsmittel angefertigt habe.

Berlin, den 7.11.2005

Einverständniserklärung

Ich erkläre hiermit mein Einverständnis, dass die vorliegende Arbeit in derBibliothek des Institutes für Informatik der Humboldt-Universität ausgestelltwerden darf.

Berlin, den 7. 11. 2005

137