Konzepte und Techniken für das Semantic Web

Transkript

1 Universität Augsburg Institut für Informatik Programmierung verteilter Systeme Konzepte und Techniken für das Semantic Web WS 2007/2008 Seminarband Prof. Dr. Bernhard Bauer Dipl.-Inf. Wolf Fischer Dipl.-Inf. Florian Lautenbacher Dipl.-Inf. Stephan Roser

2 Vorwort Im Laufe des Wintersemester 2007 / 2008 fand an der Universität Augsburg das Seminar Konzepte und Techniken für das Semantic Web statt. Dieser Band stellt sämtliche studentischen Arbeiten dieses Seminars dar. Die erste Arbeit, behandelt von Gorana Bralo, gibt eine Einführung in die grundlegenden Prinzipien des Semantik Webs. Weiterhin zeigt sie, in welchen Gebieten das Semantic Web von Bedeutung ist und wo es bereits zu einem verstärkten Einsatz gelangt. In die theoretischen Grundlagen, auf denen das Semantic Web aufbaut, führt Carsten Angeli ein. Seine Arbeit widmet sich dabei insbesondere verschiedenen Beschreibungslogiken und wie diese zur Wissensrepräsentation angewendet werden können. Das Semantic Web wäre jedoch von keinerlei Nutzen, wenn es nicht verschiedene Software zur Inferenz auf Wissensbasen geben würde. Hierzu wurden drei unterschiedliche Reasoning-Techniken und deren Funktionsweisen untersucht: Thomas Eisenbarth widmete sich dem in Jena verwendeten RETE Algorithmus. Anschließend präsentiert Stephanie Siekmann in ihrer Arbeit das Prinzip, welches in einem der neuesten erhältlichen Reasoner, KAON2, zum Einsatz kommt. Abschließend zeigt Philipp Kretschmer, welche Funktionsweise einer der bekanntesten und am weitesten verbreiteten Algorithmen, der Tableaux Algorithmus, besitzt. Um Wissen aus einer Wissensbasis zu erhalten muss es jedoch eine Möglichkeit geben, diese abzufragen. SPARQL ist die hierfür vom W3C standardisierte Query- Sprache und wird von Alexander Matwin zusammengefasst. Um überhaupt an eine Wissensbasis zu gelangen bedarf es jedoch zuerst der Erstellung der Ontologie. Benedikt Gleich zeigt, welche verschiedenen Methodologien sowie auch Pattern im Laufe der Zeit entstanden sind und welche Parallelen sich hierbei zu den entsprechenden Ansätzen im Software Engineering ergeben. Ein Problem, welches sowohl bereits bei der Erstellung als auch generell bei der Verwendung von Ontologien auftritt, ist, dass für ein und die selbe Domäne häufig verschiedene Ontologien existieren, welche allerdings leicht oder komplett unterschiedliche Sichtwinkel auf den jeweiligen Bereich besitzen. Dennoch ist es manchmal notwendig, verschiedene Ontologien zu vereinen, um eine größere Wissensbasis zu erhalten. Entsprechende Techniken, wie ein solcher Vorgang bewerkstelligt werden kann, werden dem Bereich des Ontology Mapping zugeordnet und von Michael Buthut vorgestellt. Eine Anwendungsdomäne, in der Ontologien heutzutage bereits von größerer Bedeutung sind, stellen Web Services dar. In diesen werden Ontologien unter anderem dazu verwendet, eine automatische Komposition von verschiedenen Web Services zu erreichen. Welche Techniken dazu verwendet werden können und wie weit der Stand der Forschung ist, fasst Joachim Alpers zusammen. Den Abschluss des Seminars bildet die Arbeit von Martin Haslinger. Er beschäftigte sich mit der Frage, wie weit die Forschung bei den Themen Proof, Trust und Security im Kontext des Semantic Web ist.

3 III Die vorgestellten Themen stellen trotz ihres Umfangs jeweils nur eine komprimierte Übersicht über den aktuellen Stand der Forschung im Semantic Web Umfeld dar. Nach wie vor bietet dieser Bereich sehr viele Forschungsfelder, so dass auch in Zukunft mit vielen neuen und interessanten Forschungsresultaten zu rechnen ist. Februar 2008 Die Editoren

4 Inhaltsverzeichnis Grundlagen des Semantic Web und Anwendungsgebiete Theoretische Grundlagen des Semantic Web Reasoning: Rete (und Jena) Reasoning auf Datalog-Basis (KAON2) Reasoning mit Tableau (anhand von Pellet) Die Anfragesprache SPARQL Ontologie-Methodologien und Ontologie Design Ontology Mapping Semantic Web Service Composition Semantic Web: Proof, Trust und Security

5 Grundlagen des Semantic Web und Anwendungsgebiete Gorana Bralo Universität Augsburg Zusammenfassung Semantic Web ist eine neue Web-Technologie, die als Erweiterung des bestehenden World Wide Web zu sehen ist. Das Ziel ist dabei die Erweiterung der Funktionalitäten des WWW sowie seine Verbesserung und Optimierung. In Zukunft sollen die Informationen und Daten nicht nur für den Menschen verständlich sein, sondern auch für Maschinen. 1 Einleitung Wie sieht das Zeitalter, in dem wir Menschen uns heute befinden aus informationstechnologischer Sicht betrachtet eigentlich aus? Jeder hat sicherlich schon einmal darüber nachgedacht und früher oder später realisiert, dass Dinge, die uns vor einigen Jahren noch unmöglich erschienen, heute längst zu unserem Alltag gehören. Betrachten wir einmal das World Wide Web. Kaum jemand kann sich heutzutage das Internet noch wegdenken. Auf der einen Seite bietet es uns überaus viele Möglichkeiten und vereinfacht gleichzeitig in vielerlei Hinsicht unser Leben sowie unsere Kommunikation. Auf der anderen Seite weist es aber auch viele Schwächen und Verbesserungmöglichkeiten auf. Eine der neuen und bahnbrechenden Web-Technologien, die versucht diese Schwächen des WWW auszubessern und neue Funktionalitäten zu bieten, heißt Semantic Web. Doch bevor näher auf diese Technologie und ihre Möglichkeiten eingegangen wird, sollte zunächst die Frage beantwortet werden, was das Schlagwort Semantic Web überhaupt bedeutet und für was es genau steht. The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation. [?] Das Semantic Web ist also kein vollkommen neues oder eigenständiges Internet, sondern bildet viel mehr eine Erweiterung zu dem schon vorhandenen World Wide Web. Dabei beseitig es jedoch viele Nachteile des WWW, indem es neben der Syntax auch Semantik integriert. Das Internet enthält einen sehr großen Umfang an Informationen in Form von Dokumenten. Diese Dokumente können durchsucht und zur Informationsgewinnung herangezogen werden. Letzteres ist jedoch nur durch einen Menschen möglich, denn Maschinen sind nicht in der Lage

6 2 G. Bralo diese Daten zu interpretieren und ihnen eine Bedeutung zuzuordnen. Möchte man aber diese Daten effektiv nutzen, so ist es erforderlich die zugrundeliegende Semantik, also die Bedeutung, zu extrahieren. Sucht ein Nutzer im Internet nach einem bestimmten Schlüsselwort, z.b. dem Begriff Golf, so werden Suchergebnisse aus verschiedenen Bereichen zurückgeliefert, so z.b. aus dem Bereich Auto als auch aus dem Bereich Sport. Der Nutzer muss nun anschließend diese Ergebnisse durchsuchen und die für sich relevanten Quellen herausfiltern. Die Suchmaschine ist zwar in der Lage aufgrund des eingegebenen Suchbegriffes, die syntaktisch relevanten Ergebnisse zu suchen, aber nicht zu verstehen nach was der Nutzer sinngemäß gesucht hat. Maschinen sind also nicht fähig der Syntax eigenständig Semantik zuzuordnen da ihnen Kontextwissen fehlt. Genau an diesem Punkt setzt das Konzept des Semantic Web an. Es versucht mit neuen Technologien einen Lösungsansatz für dieses Problem zu bieten. Informationen sollen in Zukunft nicht nur maschinenlesbar sondern auch maschinenverständlich sein, d.h. Maschinen sollen in der Lage sein Informationen in ihrem Kontext zu verstehen. Dadurch könnte die Informationssuche automatisiert und personalisiert werden, was bedeuten würde, dass z.b. Suchmaschinen bessere und gezieltere Ergebnisse liefern und dem Menschen gleichzeitig Aufwand ersparen könnten. Doch nicht nur die Problematik von Suchmaschinen ist ein wichtiger Bereich vom Semantic Web. Es hat noch viele weitere wichtige Funktionalitäten und Anwendungsgebiete auf die im weiteren Verlauf noch eingegangen wird. Die Vision des Semantic Web besteht also darin einen Lösungsansatz dafür zu bieten, die Interaktion zwischen Maschinen auf einer neuen Ebene zu ermöglichen, auf der die Informationsverarbeitung bzw. -suche noch weitreichender automatisiert werden kann sowie effektiver und besser wird. Die Themen der vorliegenden Arbeit sind die Grundlagen und Anwendungsgebiete des Semantic Web. Sie behandelt in einem groben Überblick die zugrundeliegenden Konzepte sowie die Technologien des Semantic Web und versucht diese anhand von drei Projektbeispielen zu veranschaulichen. 2 Grundlagen des Semantic Web Damit das Semantic Web funktionieren und die oben genannten Ansprüche erfüllen kann, müssen die Maschinen auf strukturierte Informationen zugreifen können. Die heutzutage vorhandenen Informationen im WWW sind jedoch mehr chaotisch als strukturiert vorhanden. Es muss also zunächst eine gewisse Struktur in die Welt der Informationen und ihre Darstellung gebracht werden. Des weiteren müssen entsprechende Regeln definiert werden, wie Maschinen auf diese Informationen überhaupt zugreifen können. In diesem Kapitel werden daher die Architektur von Semantic Web und ihre Umsetzung, in Form von Werkzeugen, vorgestellt und im einzelnen kurz erklärt.

7 Grundlagen des Semantic Web und Anwendungsgebiete Das Schichtenmodell Das Grundgerüst des Semantic Web bildet das Schichtenmodell. [?] Es wurde von der WC3 Semantic Web Activity beschrieben und ist in Abbildung 1 dargestellt. Es besteht aus 7 Schichten, die von unten nach oben aufeinander aufbauen. Abbildung 1. Das Schichtenmodell URI und Unicode Die unterste Schicht, definiert durch URI und Unicode, ist wichtig für die Kommunikation zwischen Maschinen. Um Zeichen auf verschiedenen und heterogenen Systemen eindeutig und ohne Informationsverslust kodieren und dekodieren zu können, braucht man ein Kodierungsystem, das plattform- und sprachunabhängig ist. Hier wird daher der Unicode Zeichensatz eingesetzt. [?] Aus demselben Grund werden URIs (Unified Ressource Identifier) verwendet. Damit kann eine eindeutige Adressierung von verschiedenen physikalischen als auch abstrakten Ressourcen gewährleistet werden. Zwei syntaktisch gleiche Begriffe, mit unterschiedlicher Semantik, können somit durch zwei verschiedene URIs eindeutig referenziert werden. [?] XML und XML-Schema Die zweite Schicht definiert die einheitliche Formatierung und Darstellung von Dokumenten mittels XML. Im Gegensatz

8 4 G. Bralo zu HTML ist es bei der XML-Technologie möglich die Dokumentenstruktur für verschiedene Applikationen dynamisch anzupassen und beliebig zu erweitern. Ausserdem können mit selbst erstellen Tags Dokumente in bestimmter Form gekennzeichnet werden und dadurch mit Semantik angereichert werden. XML-Schema ist der WC3-Standard, der der Definition von XML-Sprachen dient. Namespaces werden definiert, um Namenskonflikte zwischen Dokumenten unterschiedlicher Entwickler zu vermeiden. [?] RDF und RDF-Schema Das Resource Description Framework (RDF) baut auf der XML-Schicht auf. Sie ist eine plattformunabhängige Beschreibungssprache, die dazu dient Beziehungen, d.h. den semantischen Zusammenhang, zwischen Daten zu definieren. Die RDF-Dokumente setzen sich aus drei verschiedenen Objekten zusammen, durch die eine solche Beziehung beschrieben wird: Ressourcen, Eigenschaften, Aussagen. Die Ressourcen sind die eigentlichen Dokumente. [?] Ontologie Eine Ontologie definiert formal einen Wissensbereich, indem Verbindungen und Beziehungen zwischen Objekten beschrieben werden. [?] Es gibt drei Bausteine: das Konzept bzw. den Begriff, Relationen zwischen diesen Begriffen sowie Regeln über die Relationen und Begriffe. Hier ein Beispiel zur Veranschaulichung: Hat man z.b. die Relationen Snoopy ist ein Hund und Hund ist ein Tier und würde eine Maschine nach Tier suchen, so wäre Snoopy ein Ergebnistreffer. Es wurde zwar nicht nach Hund gesucht, aber durch Ontologien ist es eben möglich Informationen, die nicht direkt miteinander verknüpft sind, zusammenzuführen. Ontologien definieren somit das zugrundeliegende Schema eines Systems. Um dieses konkret darstellen zu können und in die Daten einzubinden, benötigt man eine sogenannte Ontologiesprache, die OWL (Web Ontology Language). [?] Logic, Proof, Trust 3 Veranschaulichung des Semantic Web Konzeptes an Projektbeispielen In diesem Abschnitt werden drei Projekte der [?] im Detail vorgestellt. Anhand dieser konkreten Beispiele soll die Funktionsweise und die Idee des Semantic Web veranschaulicht werden. 3.1 Semantic MediaWiki Das Projekt [?] ist die Realisierung eines Wikisystems der etwas anderen Art. Es wurde von dem Institute AIFB (University of Karlsruhe) mit der Unterstüzung des FZI Karlsruhe umgesetzt.

9 Grundlagen des Semantic Web und Anwendungsgebiete Die Idee dahinter Das wohl bekannteste Beispiel eines Wikis ist Wikipedia. Heutzutage kennt und nutzt jeder die Online-Enzyklopädie um Wissen nachzuschlagen und sich zu informieren. Es entstand aus der Idee heraus, dass jeder Benutzer die Möglichkeit haben soll, an der Bearbeitung und Erstellung von Beiträgen zu einem Thema mitzuwirken. Das Ziel ist die Erstellung einer umfangreichen Online Enyklopädie, wobei jeder frei entscheiden kann worüber er einen Artikel verfassen möchte. Ein Wiki ist ein webbasiertes System, das das kollaborative Verfassen und Aktualisieren von Webseiten ermöglicht. [?] Das System ist also dezentral organisiert und es liegt an den Benutzern sich gegenseitig zu korrigieren und zu überwachen. Das Prinzip ist klar. Doch wie im ersten Kapitel schon angesprochen, leben wir heute in einer Zeit, in der das Informationswachstum schnell voranschreitet und die Benutzer schnell den Überblick verlieren können. Ein Wiki setzt keine Vorkenntnisse einer bestimmten Programmiesprache oder ähnlichem voraus um Inhalte zu bearbeiten. Der Benutzer ist fähig mit einer einfachen Syntax und einem Texteditor, den er aus seinem Browser heraus aufrufen kann, Veränderungen vorzunehmen. Genauso gibt es keine festgelegten Regeln wie der Inhalt der Seiten aufgebaut werden muss. Jeder Benutzer kann dies so umsetzen, wie er möchte. Dieses Konzept, das verschiedene Benutzer eigenständig Webseiten zu verschiedenen Themen erstellen können sowie das Fehlen einer festgelegten Struktur bzgl. des Artikelaufbaus, erfordert bei zunehmenden Informationen eine genauere Strukturierung. Die Artikel können zwar mit Links zu anderen Artikeln versehen werden um somit eine Verknüpfung zu erstellen, dennoch ist die Suchfunktion nicht optimal, da nur nach Schlüsselwörtern gesucht werden kann. Fehlt eine Verknüpfung durch Links, so wird die Suche nach Seiten, die sinngemäß in Verbindung stehen schwierig. Sogenannte Übersichtsseiten versuchen das Problem zu lösen und dem Nutzer die Suche zu erleichtern. Dabei werden die Inhalte verschiedener Artikel zusammengeführt und zu sogenannten Kategorien zugeordnet. Solche Übersichten müssen jedoch manuell erstellt und daher auch manuell gewartet werden, was einen enormen Zeitaufwand bedeutet. Wie am Anfang dieser Arbeit schon beschrieben, existieren Probleme bei der Suche nach Inhalten, da Maschinen kein Kontextwissen besitzen und damit nicht alle relevanten Inhalten von irrelevanten unterscheiden können. Zudem sind sie auch nicht in der Lage unterschiedliche Begriffe mit derselben Bedeutung zu erkennen. Das sind alles Punkte, die bei dem Durchsuchen von Informationen in einem Wiki ein Problem darstellen. Entweder es werden zu viele Ergebnisse zurückgeliefert, oder zu wenige. Die Idee des Semantic Wiki besteht nun darin, durch Semantik eine Lösung für diese Probleme zu schaffen. Der wesentliche Unterschied zu einem normalen Wiki ist der, das hier bei dem Erstellen von Artikeln Semantik integriert wird

10 6 G. Bralo und zwar mit Hilfe von sogenannten Annotationen. Annotationen sind nichts anderes als Anmerkungen, die dem Inhalt einer Webseite Bedeutung verleihen. Es ist also nicht nur die Darstellung von Inhalten wichtig, sondern auch ihre Bedeutung und mögliche Relationen zu anderen Inhalten. Diese Metadaten sind es, die den Maschinen das nötige Kontextwissen liefern, um die Bedeutung der Verknüpfungen verstehen zu können Funktionsweise Wie diese Idee konkret umgesetzt ist, soll an einem Beispiel veranschaulicht werden: Als Suchbegriff werden wir Berlin verwenden. Wie in Abbildung 2 zu sehen ist, wird als Ergebnis die entsprechende Seite zurückgeliefert, die Informationen zu "Berlin enthält. Abbildung 2. Das Sucherbenis der Suche nach dem Begriff: Berlin Neben der allgemeinen Beschreibung ist besonders der Bereich Facts about Berlin interessant. Dieser Bereich enthält wichtige zusätzliche Angaben bzgl. Berlin, z.b. zu der Einwohnerzahl oder der Fläche mit dem entsprechenden Wert. Alle diese Verweise stellen die Relation zwischen den entsprechenden Artikeln und Berlin dar, in diesem Fall z.b. zwischen den Artikeln Einwohnerzahl bzw. Fläche und dem Artikel Berlin. Um diese Beziehung noch verständlicher zu machen, sehen wir uns die Attributsuche von z.b. dem Attribut Population an. Durch Anklicken des Lupe -Symbols neben dem Wert für die Population, sehen wir die in Abbildung 3 dargestellte Ergebnisseite. Wie man sehr schön erkennen kann, werden hier alle Seiten aufgelistet, die bei dem Attribut Population den Wert 3,391,407 haben. Hier ist dies nur bei Berlin der Fall. Ausserdem hat man hier die Möglichkeit gezielt nach allen Städten zu suchen, die eine bestimmte Anzahl an Einwohnern haben. Dies verdeutlicht, dass also jede Seite, die eine Stadt beschreibt, ein Attribut

11 Grundlagen des Semantic Web und Anwendungsgebiete 7 Abbildung 3. Das Ergebnis der Attributsuche für das Attribut Population Population enthält und damit mit ihr in Relation steht. Die Maschine, die nun z.b. alle Stätde mit einer bestimmten Einwohnerzahl suchen soll, ist durch das Kontextwissen, nämlich das die Zahl 3,391,407 auf der Seite von Berlin die Population beschreibt, in der Lage, alle relevanten Seiten zu durchsuchen und falls zutreffend als Ergebnis zu liefern, so z.b. die Seite Berlin. Als ein weiteres Beispiel wird die Population betrachtet. Wie man sieht, ist zusätzlich zur Beschreibung des Attributs Population, z.b. der Typ, auch eine Auflistung aller verknüpfen Seiten angezeigt: Seiten mit allen Städten, die dieses Attribut auf ihrer Seite definiert haben. (siehe Abbildung 4) Abbildung 4. Das Attribut Population Wir können sehen, dass unter anderem auch Berlin aufgeführt ist, mit dem Wert 3,391,407. Es werden die gesamten Seiten angezeigt, die mit diesem Attribut in Relation stehen. Im Vergleich zu einem einfachen Wiki, beispielsweise Wikipedia, stellt diese Wiki- Form also eine erhebliche Vereinfachung für die Suche dar, die damit viel breiter und gezielter erfolgen kann. Sucht man nämlich nach dem gleichen Begriff, also z.b. Berlin, in Wikipedia, dann bekommt man ebenso einen groben Überblick über die Einwohneranzahl oder auch die Fläche. Möchte man jedoch gezielt

12 8 G. Bralo nach bestimmen Einwohnerzahlen oder allgemein nach Städten, mit definierten Einwohnerzahlen, suchen, ist das nicht automatisiert möglich. Dies muss der Benutzer manuell machen Integration von Semantik Der folgende Abschnitt beschäftigt sich mit der Einbindung von Semantik in das Wikisystem. Es wird aufgezeigt auf welche Weise sich in diesem Fall Ontologien wiederfinden, wie OWL zum Einsatz kommt und Queries verwendet werden. Wie bereits im ersten Kapitel dieser Arbeit erklärt wird, definiert eine Ontologie eine Wissensbasis, die sich aus drei Bausteinen zusammensetzt: Begriffe Relationen zwischen Begriffen Regeln bzgl. der Begriffe und Relationen Aufgrund dieser Wissensbasis ist man in der Lage Informationen und Inhalte als Begriffe zu definieren, Relationen zwischen ihnen herzustellen und somit für den Zweck der semantischen Anreicherung zu verwenden. Diese drei Bausteine finden sich demnach auch im Semantic MediaWiki wieder. Um diese konkret umzusetzen bedarf es außerdem einer Ontologiesprache, die in diesem Fall OWL DL ist. Die Abkürzung OWL DL steht für Web Ontologie Language Description Logic. In Abb. 5 sind die wesentlichen Konstrukte dieser Ontologiesprache und ihre Umsetzung im Semantic MediaWiki dargestellt: Abbildung 5. Ontologie im Semantic MediaWiki Anhand des Artikels Berlin wird die Umsetzung der Ontologie veranschaulicht. Um eine Wissensbasis aufzubauen, definiert man sich zunächst Begriffe, die man anschließend in Beziehung zueinander stellen kann. Solche Begriffe definiert

13 Grundlagen des Semantic Web und Anwendungsgebiete 9 man mit Hilfe der Ontologiesprache, die zu diesem Zweck Klassen, Objekte und verschiedene Eigenschaften von Klassen oder Objekten vorsieht. Eine Klasse wird im Semantic MediaWiki in Form von einer Category definiert. Eine Eigenschaft einer solchen Category wird durch eine Datatype property oder Objecttype property definiert. Diese Konstrukte definieren also die grobe Struktur des zugrundeliegenden Schemas. Konkrete Ausprägungen dieses Schemas sind dann alle Artikel, die zu einer bestimmten Category gehören oder als Property gekennzeichnet sind. Um bei einer Suche nach allen im Wiki existenten Städten auch die Stadt Berlin zurückgeliefert zu bekommen, muss diese also als Stadt gekennzeichnet werden. Dies erreicht man dadurch, dass man sie der Klasse Stadt zuordnet. In Abb. 6 sieht man den dazugehörigen Code: Abbildung 6. Zuordnug zur Klasse: City Durch [[Category::City]] ist der Artikel als City gekennzeichnet. Bei einer entsprechenden Suche nach Städten werden also alle Artikel im Semantic MediaWiki zurückgeliefert, die dieser Kategorie zugeordnet sind. Eine konkrete Ausprägung wäre daher unser Beispielartikel Berlin. Als weiteres Beispiel nehmen wir die Population. Die zugehörige Ontologiedefinition ist Datatype property und die konkrete Ausprägung in Falle des Artikels Berlin z.b. ist der Wert 3,391,407. Würde man nach allen Einwohnerzahlen suchen, würden also all diejenigen Zahlen zurückgeliefert, die mit Population getagged sind. Um also Relationen zwischen verschiedenen Artikeln in einem Wiki herzustellen, muss man sie entsprechend taggen, d.h. im Code mit dem richtigen Verweis der richtigen Klasse zuordnen bzw. als bestimmte Eigenschaft kennzeichnen. Für die semantische Suche im Semantic MediaWiki existieren sogenannte Inline- Queries. In Abb. 7 sieht man ein Beispiel für eine solche Inline-Query und das dazu zurückgelieferte Ergebnis. Diese ermöglichen eine einfache Einbindung in erstellte Seiten und den Zugriff auf diese Suchergebnisse durch mehrere Benutzer. Die Inline-Queries haben eine einfache Syntax. Es existieren vordefinierte Parame-

14 10 G. Bralo Abbildung 7. Inline-Query mit dargestelltem Ergebnis ter für die zurückzuliefernden Argumente sowie Parameter für die Darstellung der Suchergebnisse. Man definiert einfach die Suchkriterien durch die Inline-Query und bindet diese in die entsprechende Seite ein. Beim Seitenaufruf werden dann die Ergebnisse dargestellt. Die Darstellung der Ergebnisse lässt sich dabei beliebig verändern. Man kann die Daten sortieren oder sogar Templates benutzen, die es erlauben CSS einzubinden oder Bilder anzeigen zu lassen Zusammenfassung Das Ziel des Semantic MediaWiki ist demnach die Erweiterung des Wikisystems zu einem System welches nicht nur die Suche nach bestimmten Schlüsselwörtern sondern nach konkreten Fragen erlaubt. Es entstehen also kollaborative Wissensmanagement-Systeme, die trotz dezentraler Strukturen auf einer einheitlichen Wissensbasis beruhen. [?] Ausserdem ist das System beliebig erweiterbar ohne dabei auf eine Strukturierung der Daten verzichten zu müssen oder gar den Überblick über die Informationen zu verlieren. Durch die Semantik können auch neu hinzugefügte Daten stets in das Gesamtinformationsnetz integriert und mit anderen Daten verknüpft werden. 3.2 MultimediaN E-Culture demonstrator Bei dem Projekt [?] handelt es sich um eine Suchanwendung, die auf einer Ansammlung von Informationen und Quellen über Kunst beruht. Es macht die Suche nach Relationen zwischen Epochen, Malern und Gemälden und somit eine umfangreichere Informationsdarstellung möglich. Realisiert wurde das Projekt gemeinsam von mehreren holländischen Universitäten, wie z.b. der Universiteit van Amsterdam und der Technical University Eindhoven (TU/e).

15 Grundlagen des Semantic Web und Anwendungsgebiete Die Idee dahinter The objective of this project is the development of a set of e-culture demonstrators providing multimedia access to distributed collections of cultural heritage objects. [?] Das Ziel des MultimediaN E-Culture demonstrator ist also die Entwicklung eines elektronischen Assistenten, der einen multimedialen Zugriff auf verteilte Sammlungen von kulturellem Erbe ermöglicht. Dabei steht die umfangreiche Suche nach bestimmten Informationen und Sachverhalten mit einem höheren Grad an Verknüpfung untereinander im Vordergrund. Wie auch bei dem ersten Projektbeispiel des Semantic MediaWiki möchte man auch in diesem Fall die Suche nach konkreten Fragen ermöglichen und nicht nur nach einzelnen Schlüsselwörtern. Es sollen z.b. Fragen zu der Beziehung verschiedener Maler zueinander oder zu der Verbindungen zwischen verschiedenen Epochen dargestellt werden können. [?] Gezeigt wird also der semantische Informationszugriff sowie die kontextabhängige Darstellung von Informationen. [?] Im Rahmen dieses Projektes geht es vor allem um die Suche nach Gemälden berühmter Maler und verschiedenen Informationen im Bereich der Kunst im Allgemeinen. Wie weiter oben erwähnt, besteht die Wissensbasis dieses Systems aus verschiedenen Informationen zu Kunstwerken, Malern, sowie Epochen und ihren Verbindungen. Die Quellen dieser Informationsbasis bilden verschiedene Museen oder anderen Kunstarchive der Niederlande. Um die Vorteile eines solchen Systems gegenüber einem System ohne semanatische Integration besser zu erkennen, nimmt man als Gegenbeispiel die Suche mit Google. Google ist die Suchmaschine Nummer eins, wenn es darum geht Informationen zu finden, und besitzt keine semantische Grundlage. Mit der Bildersuche von Google kann man ebenso nach verschiedenen berühmten Gemälden oder Malern suchen. Der gravierendste Unterschied zwischen diesen beiden System ist dabei die Art und Weise der Suche und die zurückgelieferten Suchergebnisse. Sucht man mit der Google Bildersuche nach einem bestimmten Stichwort, kann es passieren, dass man entweder überhaupt keine Ergebnisse dazu zurückgeliefert bekommt oder aber viel zu viele. Dabei werden vielleicht auch irrelevante Ergebnisse angezeigt, die im Bezug auf das Suchwort sogar falsch sein können. Mit der Suche des MultimediaN E-Culture demontrator kann dies nicht passieren. Zu jedem Suchbegriff werden nur die wirklich relevanten Ergebnisse angezeigt. Gleichzeitig dazu werden auch die Verbindungen mit anderen Kategorien dargestellt, die für den Benutzer ebenfalls interessant sein könnten. Dadurch gewinnt man einen besseren Überblick über die Einordnung des gesuchten Begriffes und ist zu grundsätzlich zu einer gezielteren Informationssuche fähig. Durch Semantik werden auch bei diesem Projekt Beziehungen zwischen den Objekten der Wissensbasis hergestellt und somit ein großes Netz aus Informationen aufgebaut wobei die Suche die Einordnung der Objekte in dieses Netz aufgezeigt.

16 12 G. Bralo Funktionsweise Im folgenden Abschnitt wird an einem konkreten Suchbeispiel die Funktionsweise des MultimediaN E-Culture demonstrator erklärt. Es gibt zwei Möglichkeiten eine Suche durchzuführen, entweder mit der Basic Search oder der Advanced Search. Zunächst wird die Beispielsuche mit der Basic Search durchgeführt. Gesucht wird nach dem Maler Gustav Klimt. In das Suchfeld wird Klimt eingegeben. Nach der Eingabe erscheint unter dem Suchfeld eine Liste von möglichen Optionen bzw. Vorschlägen, die den Benutzer direkt auf die entsprechenden Suchseiten weiterleiten (Siehe Abbildung 8). Ist der Benutzer auf der Suche nach Bildern von dem Maler Klimt sind und keine Ergebnisse angezeigt haben möchte, die z.b. nur in irgendeiner Weise mit Klimt im Zusammenhang stehen, so hat er die Möglichkeit auf Works created by an artist with matching name on the keyword klimt zu klicken und wird direkt zur entsprechenden Seite weitergeleitet. Abbildung 8. Basic Search für den Suchbegriff Klimt Klickt man stattdesssen auf Search gelangt man zu der Seite, auf der alle möglichen Ergebnisse, die in irgendeinem Zusammenhang mit Klimt stehen, angezeigt werden. Die Suchergebnisse sind kategorisiert. Man sieht die Kategorie der Werke, die von Klimt stammen, aber auch Kategorien, die z.b. bestimmte Epochen enthalten. Die Werke und der Malstil von Klimt gehören demnach diesen Epochen an und es werden in der Kategorie die Werke von anderen Malern aufgelistet, die somit mit Klimt den Malstil, der charakteristisch für diese Epochen ist, gemeinsam haben. Des Weiteren wird im unteren Bereich der Seite die zeitliche Einordnung der Werke der verschiedenen Maler dargestellt, wie man in Abbildung 9 sehen kann. Klickt man nun in der Kategorie der Werke von Gustav Klimt auf ein konkretes Bild, z.b. The Kiss, dann gelangt man auf eine Detailseite (Abbildung 10) auf der weitere zusätzliche Informationen zu dem ausgewählten Werk angezeigt werden. Sie enthält Informationen zum Material des Kunstwerks, zum Entstehungszeitraum, der Art des Werkes oder auch zur Quelle des Werkes, also woher die Informationen zu dem Bild stammen. Alle diese Informationen sind dabei direkt mit dem Kunstwerk verbunden. Dies bedeutet, würde man konkret nach Werken suchen, die in einem bestimmten Zeitraum entstanden sind, so würde

17 Grundlagen des Semantic Web und Anwendungsgebiete 13 Abbildung 9. Zeitliche Einordnung der Werke auch dieses Werk aufgelistet werden, falls es denn in den gesuchten Zeitraum fällt. Abbildung 10. Detailseite zum Werk The Kiss Ausgehend von der Detailseite des Werks The Kiss kann man durch anklicken der rot markierten Informationsfelder auf weitere Seiten gelangen, die wiederum entsprechende Informationen zum angeklickten Begriff sowie mit dieser Information getaggte Werke enthalten. Klickt man z.b. auf den Begriff gold, der bei dem Werk The Kiss angibt, das dieses Werk Gold als Materialbestandteil enthält, gelangt man auf eine Seite, die Informationen zu diesem Material angibt.

18 14 G. Bralo Ausserdem wird auf der Seite zusätzlich zu den Materialinformationen auch die Kategorie mit entsprechenden Werken, die Gold verwenden, angezeigt. Die Advanced Search funktioniert genauso wie die Basic Search, hat zusätzlich aber noch die Möglichkeit die Suchkriterien zu verändern und genauer einzustellen. In Abbildung 11 sieht man die zur Verfügung stehenden Felder der erweiterten Suche. Abbildung 11. Detailseite zum Werk The Kiss Interessant ist das Feld Period. Anhand einer vorgegebenen Tabelle kann der Benutzer eigene sogenannte Time Queries erstellen und damit die Suche nach Werken oder Malern aus bestimmten Zeiträumen suchen, z.b. aus einer bestimmten Zeit, nach oder vor einer bestimmten Zeit. Neben Jahreszahlen kann man auch Abfragen generieren, wie z.b. his late period und ähliches. Im Vergleich zu der Bildersuche mit Google wird deutlich, dass die Suche in diesem Fall viel gezielter und umfangreicher erfolgen kann. Es werden keine Daten und Informationen doppelt geliefert. Zusätzlich werden, falls gewünscht, viele weiterführende Ergebnisse angezeigt und die Einordnung in das Gesamtnetz somit viel klarer. [?] Integration von Semantik Zusammenfassung Der MultimediaN E-Culture demonstrator ist ein System, das aufgrund der integrierten Semantik eine bessere Suche und Navigation durch die Daten im System ermöglicht. Alle Daten sind miteinander verbunden und strukturiert in das System integriert. Man gelangt einfach zu allen Seiten, die dem Benutzer die nötigen Informationen bereitstellen. Ausserdem bieten die vielen Optionen zahlreiche Möglichkeiten die Suchkriterien beliebig zu erweitern und zu verändern. Die Relationen zwischen den Daten stellen dem Benutzer nicht nur die gesuchten Daten sondern auch alle damit in Zusammenhang stehenden Daten zu Verfügung. Dieses System zeigt in welcher Form Semantik dazu beitragen

19 Grundlagen des Semantic Web und Anwendungsgebiete 15 kann das Suchen nach Daten zu optimieren und zu vereinfachen, vor allem im Hinblick auf Suchmaschinen. 4 Schluss Diese Seminararbeit wurde nicht abgeschlossen, daher fehlen noch diverse Punkte: Anwendungsgebiete, Zusammenfassung, weitere Beispiele, Literaturverzeichnis, etc. (Anmerkung der Editoren)

20 Theoretische Grundlagen des Semantic Web Carsten Angeli Universität Augsburg Zusammenfassung Das Semantic Web baut auf dem Fundament der Logik auf. In dieser Arbeit werden die Grundlagen der Pädikatenlogik und der Beschreibungslogik erklärt, und gezeigt, wie verschiedene Beschreibungslogiken in wissensbasierten Systemen zum Einsatz kommen. Die Ausdrucksmächtigkeit der vorgestellen Logikklassen SHIQ, SHOIN (D) und SROIQ (D+) wird im Detail untersucht. Abschließend wird auf die Zusammenhänge zwischen den Logikstufen und den im Semantic Web eingesetzten Ontologiesprachen RDFS, DAML+OIL, OWL DL und OWL 1.1 sowie SWRL eingegangen. 1 Einleitung 1.1 Motivation Die Anzahl der im Internet verfügbaren Webseiten und die Menge der angebotenen Services wächst stetig an. Bereits im November 2006 ergaben Schätzungen, dass die Zahl der weltweit angebotenen Seiten die Marke von 100 Millionen überschritten hat[15]. Diese Fülle an Daten und Informationen ist jedoch größtenteils unstrukturiert. Die Suche nach Informationen oder Diensten ist dadurch schwierig, da eine Suchmaschine den Volltext eines Dokuments durchsuchen muss, um seinen Inhalt zu ermitteln. Auch Zusammenhänge zwischen verschiedenen Dokumenten können nur schwer oder gar nicht ermittelt werden. Diese Lücke kann im Semantic Web mit Hilfe von Metadaten, Ontologien und Inferenzmaschinen geschlossen werden. Die Vision des Semantic Web stammt von Tim Berners-Lee[3]. Er beschreibt es als an extension of the current Web in which information is given well-defined meaning, better enabling computers and people to work in cooperation [4]. Die Informationen liegen im Semantic Web in strukturierter Form vor und können dadurch leichter gefunden und besser genutzt werden. Der Schlüssel hierzu liegt in der Verwendung von Logik, genauer, von Beschreibungslogik. Nur damit ist es möglich, das Inferenzmaschinen automatische Schlüsse über die Zusammenhänge von Daten ziehen können. In gewisser Weise stellt das Semantic Web damit das Gegenstück zum Web 2.0 dar: während bei letzterem die Kommunikation zwischen Menschen in sozialen Netzwerken im Vordergrund steht, dienen Beschreibungslogik und Ontologien im Semantic Web dazu, die Interaktion zwischen Maschinen zu verbessern.

21 Grundlagen Semantic Web Herausforderungen Um durch automatisiertes Schlussfolgern möglichst viel Information zu gewinnen, sind ausdrucksstarke Beschreibungslogiken nötig. Ist die Ausdrucksmächtigkeit jedoch zu groß gewählt, so ist die Logik nicht mehr entscheidbar. Ohne terminierende und effiziente Inferenz-Algorithmen ist eine Logik nicht für das Semantic Web geeignet. Daher müssen Logikstufen verwendet werden, die einen guten Kompromiss zwischen Ausdrucksmächtigkeit und Entscheidbarkeit darstellen. 1.3 Ziele und Aufbau der Arbeit Im Rahmen dieser Arbeit werden die Prädikatenlogik und die Beschreibungslogik als Grundlage des Semantic Web vorgestellt (Kapitel 2). Insbesondere die häufig verwendeten Logikstufen SHIQ (D), SHOIN (D) und SROIQ (D+) werden in Kapitel 3 auf ihre Ausdrucksmächtigkeit untersucht. Anschießend werden in Kapitel 4 die damit in den verschiedenen Ontologiesprachen möglichen semantischen Konstrukte betrachtet. Diese Verbindung von Beschreibungslogiken und Ontologiesprachen wird anhand der Sprachen RDFS, DAML+OIL, OWL DL und OWL 1.1 sowie SWRL gezeigt. 2 Grundlagen Die Bausteine des Semantic Web sind Metadaten, mit denen andere Inhalte beschrieben werden. Erst die Metadaten machen aus rohen Daten Informationen, indem sie den Inhalt eines Datums mit einer Bedeutung verknüpfen. Gibt man den Metadaten eine syntaktische Struktur und legt die formalen Zusammenhänge zwischen den Begriffen fest, so spricht man von einer Ontologie. Nach T. Gruber versteht man darunter eine explizite formale Spezifikation einer gemeinsamen Konzeptualisierung [9]. Eine Ontologie ist also die Beschreibung eines Wissensbereichs, die den Begriffen aus einer Terminologie eine Bedeutung zuweist und die Zusammenhänge zwischen den Konzepten festlegt. DerZweck einer Ontologie ist die Darstellung von Wissen in einer Form, die logischeschlüsse über den Inhalt ermöglicht. Um aus den statischen Informationen einer Ontologie neues Wissen zu erschließen, bedient man sich einer Inferenzmaschine (engl. reasoner). Dabei handelt es sich um ein Softwaresystem, das in der Lage ist, logische Schlussfolgerungen auf einer Ontologie zu berechnen. Man erhält dadurch Informationen, die nicht explizit in der Wissensbasis hinterlegt sind, aber durch die semantischen Zusammenhänge zu folgern sind 1. Die Voraussetzung dafür ist jedoch, dass die Ontologie, auf der die Inferenzmaschine arbeitet, in einer Sprache fomuliert ist, der eine feste Syntax und eine 1 Im Englischen: to entail: nach sich ziehen, zur Folge haben. Daher wird das Problem des Schließens über eine Ontologie (reasoning problem) auch als ontologie entailment bezeichnet.

22 18 C. Angeli formelle Logik zu Grunde liegen. Die Logik definiert dabei die Regelnfür die Schlussfolgerungen und die Gültigkeit von Aussagen. Fünf Aspekten kommt in der Logik besondere Bedeutung zu (vgl. [7]): Ausdrucksstärke Korrektheit Vollständigkeit Entscheidbarkeit Komplexität Welche Formulierungen sind in der Logik möglich, welche Sachverhalte kann sie ausdrücken? Sind nur gültige Schlussfolgerungen möglich? Können alle gültigen Schlussfolgerungen hergeleitet werden? Existiert ein terminierender Algorithmus zur Lösung des Problems? Welche Resourcen (Rechenleistung, Speicher) sind zur Berechnung nötig? Damit begründet die Logik das Fundament des Semantic Web. Von den unterschiedlichen Feldern der Logik sind für das Semantic Web besonders die Gebiete der Prädikatenlogik und der Beschreibungslogik von Interesse. 2.1 Prädikatenlogik Die Prädikatenlogik (auch: Quantorenlogik) kann in verschiedene Stufen unterteilt und durch Erweiterungen ergänzt werden. In dieser Arbeit werden nur diejenigen Bereiche untersucht, die für das Semantic Web von Bedeutung sind. Für eine allgemeinere Betrachtung der Logik sei auf U. Schöning [16] und E. Bergmann [2] verwiesen. 2.2 Prädikatenlogik 1. Stufe Die Grundlage der meisten Beschreibungslogiken ist die Prädikatenlogik der 1. Stufe (engl. first order logic, FOL). Diese Logik umfasst die Verwendung von Elementen (Variablen), Funktionen, Prädikaten und Quantifikation über Elemente, z.b. xp (x) (vergl. [17]). Sie erweitert damit die Aussagenlogik, die keine Variablen kennt, um Leerstellen, die besetzt werden können. Besetzt man die Leerstellen, können die Prädikate zu true oder false ausgewertet werden. Das wichtigste Werkzeug der Prädikatenlogik sind die Quantoren und. Mit ihnen können Aussagen über eine Anzahl von Elementen gemacht werden. Der Allquantor bedeutet dabei, dass ein Prädikat für alle Elemente gilt, der Existenzquantor sagt aus, dass es mindestens ein Element gibt, für das das Prädikat wahr ist. Die Aussage alle Raben sind schwarz kann damit formalisiert werden als xrabe(x) Schwarz(x). Die Quantoren können einander auch ersetzen: x verstehtlogik(x) x verstehtlogik(x) x verstehtlogik(x) x verstehtlogik(x) Das zweite Beispiel für die Ersetzung kann gelesen werden als Jeder versteht Logik. Es existiert keiner, der Logik nicht versteht.

23 Grundlagen Semantic Web Prädikatenlogik höherer Stufe Eine Erweiterung der Prädikatenlogik 1. Stufe auf Basis des typisierten Lambda- Kalküls ist die Prädikatenlogik höherer Stufe (engl. higher order logic, HOL). Die Grundlagen dafür enwickelte Alonso Church bereits 1940[5]. Im Gegensatz zur Prädikatenlogik 1. Stufe, in der nur über Elemente quantifiziert wird, werden in HOL auch Existenz- und Allaussagen über Prädikate gemacht. Ein Beispiel soll dies verdeutlichen: In first order logic ist es möglich, über das Prädikat x ist eine gerade Zahl, kurz G(x), z.b. die Aussage x G(x) ( es gibt eine Zahl, die gerade ist ) zu machen. In higher order logic ist es ebenso möglich, Aussagen wie Es gibt ein Prädikat mit der Eigenschaft: es trifft auf die Zahl x zu zu formalisieren: p p(x). p stellt dabei eine Variable dar, die mit einem Prädikat erster Stufe besetzt wird. Bei der Gesamtaussage handelt es sich damit um ein Prädikat zweiter Stufe. Diese Quantifizierung über Prädikate kann beliebig tief verschachtelt werden. 2.4 Beschreibungslogik Um die Begriffe und das Wissen einer Domäne formell und strukturiert darzustellen und durch logisches Schließen aus vorhandenem Wissen Neues zu generieren, werden Beschreibungslogiken verwendet. Ihr Vorteil gegenüber der Prädikatenlogik ist, dass die Struktur der Informationen erhalten bleibt und dass die Logik entscheidbar wird (Abschnitt 2.4.3). Damit können Ontologien erstellt werden, die die Grundlage für wissensbasierte Systeme wie das Semantic Web darstellen. Die Bausteine einer Beschreibungslogik sind Objekte (auch bezeichnet als Instanzen oder Individuen), Konzepte (auch: Klassen) und Rollen. Ein Objekt entspricht dabei einer einfachen Konstante. Ein Konzept ist formal betrachtet ein einstelliges Prädikat und steht für eine Menge von Objekten. Zweistellige Prädikate werden in der Beschreibungslogik als Rollen bezeichnet. Sie beschreiben die Verbindungen zwischen Objekten. Dies soll an einem Beispiel veranschaulicht werden. Für die Notation wird in dieser Arbeit die Konvention verwendet, die auch bei Baader et al. [1] und in den Publikationen von I. Horrocks zum Einsatz kommt: Objekte werden in Großbuchstaben geschrieben, Konzepte beginnen mit einem Großbuchstaben, Rollen beginnen mit Kleinbuchstaben. Als Schrift wird Sans Serif für Beispiele in den Beschreibungslogiken verwendet, Schreibmaschinenschrift wird bei Codebeispielen (RDF, OWL) in Kapitel 4 eingesetzt. Objekte: ANNA, TOM, UNI AUGSBURG Konzepte: Person, Universität, Student Person studiertan. Rollen: studiertan Damit lassen sich etwa die folgenden Sachverhalte formalisieren: Student(TOM), Student(ANNA) Universität(UNI AUGSBURG) studiertan(tom, UNI AUGSBURG)

24 20 C. Angeli Konzepte lassen sich unterscheiden in atomare und komplexe (zusammengesetzte) Konzepte. Im Beispiel handelt es sich bei Person und Universität um atomare Konzepte, die sich nicht weiter aufteilen lassen. Student bezeichnet ein komplexes Konzept, das auf dem atomaren Konzept Person und der Rolle studiertan aufbaut. Als besondere Konzepte existiert, das universelle Konzept und, das bottom- Konzept. Das universelle Konzept kann für jedes beliebige Konzept stehen, das bottom-konzept entspricht der leeren Menge. Dies wird deutlich, wenn man die Interpretation I betrachtet. Eine Interpretation weist einer Syntax eine definierte Semantik zu. Nach [1] besteht eine Interpretation I aus einer nicht leeren Menge I (der Domäne der Interpretation) und einer Interpretations- Funktion, die jedem atomaren Konzept A eine Menge A I I zuweist und jeder atomaren Rolle R eine binäre Relation R I I I zuordnet. Es gelten folgende Definitionen (nach [1]): I = I I = A I = I \ A I (C D) I = C I D I ( R.C) I = {a I b. (a, b) R I b C I } ( R. ) I = {a I b. (a, b) R I } Assertional Box und Terminological Box Bei einer Wissensbasis (engl. knowlege base) werden zwei Bereiche unterschieden: die TBox (terminological box) und die ABox (assertional box). Die TBox enthält dabei das Wissen über die Konzepte einer Ontologie und ihre Zusammenhänge. Die ABox dagegen speichert die Informationen über einzelne Individuen (Objekte) der Konzepte. Auch Zustandsinformationen über das modellierte System werden in der ABox abgelegt. In Abbildung 1 ist ein Beispiel dazudargestellt Open World Assumption vs. Closed World Assumption Bei der Modellierung einer Wissensrepräsentation kann man von zwei unterschiedlichen Standpunkten ausgehen, der Closed World Assumption und der Open World Assumption. Bei der ersten Annahme geht man davon aus, dass die verwendete Datenbasis vollständig ist und alles, was nicht explizit als wahr bekannt ist oder hergeleitet werden kann, falsch ist. Diese Annahme wird regelmäßig bei Datenbanksystemen verwendet. Betrachtet man beispielsweise die Abfrage nach einem bestimmten Artikel in der Produktdatenbank eines Unternehmens, so kann man davon ausgehen, dass, falls eine leere Ergebnismenge zurückgeliefert wird, es den Artikel nicht gibt, da alle Artikel in der Produktdatenbank aufgeführt werden. In der Prädikatenlogik und auch in der darauf basierenden Beschreibungslogik gilt diese Annahme im Allgemeinen nicht. Damit werden die Möglichkeiten von Inferenzschlüssen eingeschränkt. Jedoch entspricht die Open World Assumption

25 Grundlagen Semantic Web 21 Abbildung 1. Assertional Box und Terminological Box eher den Gegebenheiten der wirklichen Welt. Ist in einem Wissensbasierten System z.b. hinterlegt TOM Student studiertan.uniaugsburg, und es wird eine Anfrage gestellt TOM studiertan.tum? so wird das System unter der Open World Assumption nicht nein antworten, sondern unbekannt, denn es ist möglich, dass Tom an beiden Universitäten eingeschrieben ist Entscheidbarkeit der Beschreibungslogik Im Gegensatz zur Prädikatenlogik ist die Beschreibungslogik entscheidbar [11]. Dies ist eine wichtige Bedingung, damit automatische Inferenzschlüsse möglich sind. Die Grundlage für den Beweis der Entscheidbarkeit ist die Erfüllbarkeit von prädikatenlogischen Formeln mit (höchstens) zwei Variablen. Auf dieses Problem können alle Konzeptbeschreibungen, die sich auf die in Tabelle 1 aufgeführten Operatoren beschränken, zurückgeführt werden. Auf die Wiedergabe des vollständigen Beweises wird hier verzichtet. Er findet sich bei[14]. Tabelle 1. Zulässige Operatoren entscheidbarer Beschreibungslogiken C D Vereinigung von Konzepten C D Schnitt von Konzepten C Negation von Konzepten R.C Qualifizierte Allaussagen über Rollen R.C Qualifizierte Existenzaussagen über Rollen R S Inklusionsbeziehungen zwischen Rollen (Subsumption) R S Vereinigung von Rollen R S Schnitt von Rollen R Negation von Rollen R 1 Komplementbildung über Rollen

26 22 C. Angeli Damit ist es möglich, mit Hilfe von Inferenzmaschinen automatisierte Schlussfolgerungen zu ziehen. Dazu existieren unterschiedliche Algorithmen, die jedoch in dieser Arbeit nicht betrachtet werden. 3 Ausdrucksstärke von Beschreibungslogiken Um die Ausdrucksmächtigkeit von Beschreibungslogiken zu definieren, wird eine Reihe von Buchstaben-Symbolen verwendet. Dabei steht jeder Buchstabe für bestimmte Gesetzmäßigkeiten und Operatoren, die zur Verfügung stehen. In Tabelle 2 (Seite 23) wird die Bedeutung der Buchstaben für die Beschreibungslogik aufgelistet, teils auch mit Verweisen auf die damit möglichen Ausdrücke in den in Kapitel 4 beschriebenen Ontologiesprachen. Die Kombination der Symbole aus Tabelle 2 ergibt die Expressivität einer Logik. Verschiedene Zusammensetzungen sind dabei auch äquivalent, bestimmte Kombinationen schließen andere Stufen als Untermenge mit ein. 3.1 FL Als Beispiel für die einfachste strukturelle Beschreibungslogik soll hier die Grammatik von FL vorgestellt werden. (vgl. [7]) Es wird verwendet: A für atomare Konzepte C, D für komplexe Konzepte R für atomare Rollen Die Grammatik wird dann beschrieben durch: C, D A C D R.C R Atomare Konzepte wurden bereits in Abschnitt 2.4 erläutert. Der Schnitt (entspricht auch der logischen UND-Verknüpfung) von Konzepten erlaubt die Bildung von Klassen, deren Elemente gleichzeitig Instanzen aller am Schnitt beteiligten Konzepte sind. Die Quantoren werden wie folgt verwendet: die universelle Einschränkung R.C definiert ein Konzept, das alle Elemente enthält, die Instanzen von R und des Konzepts C sind. Zum Beispiel lässt sich so ein Konzept anlegen Studentin studiertan.weiblich. Mit der existenziellen Einschränkung R wird garantiert, dass jedes Element mindestens einmal in der Rollenbeziehung R steht. Das Konzept Student lässt sich auf diese Weise als studiertan darstellen. In den folgenden Abschnitten wird die Ausdrucksstärke häufig verwendeter und für das Semantic Web relevanter, Beschreibungslogiken betrachtet. 3.2 ALC und die SH-Logikfamilie Die Grundlage der meisten Beschreibungslogiken ist ALC. Die Abkürzung steht für attributive language [with] complement. Zusätzlich zu der im vorigen Abschnitt 3.1 vorgestellten Logik FL kann hier die Negation (bzw. Komplementbildung) von Konzepten formuliert werden. Im Gegensatz zur Familie der AL-Logiken gibt das C an, dass auch komplexe Konzepte negiert werden können.

27 Grundlagen Semantic Web 23 Tabelle 2. Symbolübersicht: Ausdrucksstärke von Beschreibungslogiken AL steht für attributive language. Dies ist die Basis für die meisten Beschreibungslogiken. Damit sind folgende Operationen möglich: Negation atomarer Konzepte: A Schnitt von Konzepten: C D Universelle Einschränkungen durch R.C Existenzielle Restriktion, limitiert auf atomare Rollen: R FL FL o C S H O I N R Q U F E (D) (D+) entpricht AL, jedoch ohne atomare Negation weitere Einschränkung von FL, auch die Verwendung von Existenzquantoren wird ausgeschlossen Negation (Komplementbildung) von komplexen Konzepten Abkürzung für ALC mit Transitivität für Rollen (in Kombinationen mit weiteren Buchstaben verwendet) Hierarchische Verschachtelung von Rollen, in RDFS ausgedrückt durch rdfs:subpropertyof Nominale Wert für Konzepte. In OWL ausgedrückt durch owl:oneof, owl:hasvalue Invertierung von Rollen Beschränkung der Kardinalität (owl:cardinality, owl:maxcardinality) Reflexivität und Irreflexität; Disjunktheit von Rollen; Axiome, die Zusammensetzung von Rollen beschreiben (in begrenztem Umfang) Qualifizierte Beschränkungen der Kardinalität. In OWL 1.1 ermöglicht durch Sprachkonstrukte, die die Kardinalität einschränken, und dabei eine Typisierung (spezifischer als owl:thing) zulassen. Vereinigung von Konzepten Funktionale Rollen ( features ), eine Teilmenge der Rollen in R Gestattet die Verwendung von Existenzquantoren in vollem Umfang, in OWL: für die durch den Quantor gebundene Variable sind auch andere Werte als owl:thing zulässig. Erlaubt die Verwendung von Datentypen (z. B. Integer, String) und expliziten Werten ( Text, 42) Es können nicht nur Standard-Datentypen wie in (D) verwendet werden, auch die Definition eigener Typen ist möglich.

28 24 C. Angeli Um sehr lange Namen für ausdrucksstarke Beschreibungslogiken zu vermeiden, wurde die Abkürzung S für ALC R+ eingeführt. [1] S entspricht damit ALC, erweitert um Transitivität für Rollen. Eine einfache Logik, die dies verwendet, ist z. B. SIN, die ALC R+ um die Invertierung von Rollen erweitert und die Beschränkung der Kardinalität zulässt. Kardinalitätsbeschänkungen können in der Form n R geschrieben werden. So lässt sich etwa mit studiertan die Menge der Hochschulen mit mindestens Studierenden beschreiben. Dabei muss eine Einschränkung beachtet werden: die Kardinalitätsbeschränkung ist nur dann für eine Rolle R zulässig, wenn von R keine transitiven Beziehungen zu Unterrollen existieren.[1]. Ist zusätzlich die hierarchische Verschachtelung von Rollen möglich, so wird dies durch den Buchstaben H ausgedrückt. Die wichtigsten Vertreter der SH- Familie sind die Logiken SHIQ, SHIF und SHOIN, die in den folgenden Abschnitten beschrieben werden. 3.3 SHIQ (D) und SHIN (D) Die Beschreibungslogik SHIQ (D) ist mächtig genug, um damit Ontologien zu erstellen, auch wenn einige Konstrukte fehlen, die erst von erweiterten Logiken (Abschnitte 3.4 und 3.5) eingeführt werden. Die Sprache OIL (Ontologie Inference Layer, siehe 4.2) basiert auf dieser Logik.[6] Die Erweiterung gegenüber der SH-Familie betreffen: I Invertierung von Rollen: R {R R R} Q Qualifizierte Beschränkungen der Kardinalität der Form n R.C und n R.C (D) Dieser Zusatz bezieht sich auf die Verwendung von Datentypen. Damit sind Standard-Datentypen wie Integer oder String möglich. Werden nur die Logik-Eigenschaften besprochen kann der Zusatz auch weggelassen werden. Eine ähnliche Beschreibungslogik ist SHIN (D). Im Gegensatz zu SHIQ (D) ist aber eine zahlenmäßige Beschränkungen nur in der Form n R. und n R. möglich. Das Top-Konzept steht dabei für jedes beliebige Konzept und wird vereinfachend weggelassen (z. B. n R). 3.4 SHOIN (D) In SHOIN (D) kommt eine weitere Möglichkeit hinzu, Konzepte anzulegen. Das Symbol O beschreibt, dass es erlaubt ist, Konzepte durch nominale Werte zu definieren, das heißt, es werden alle zulässigen Werte aufgezählt. Ein Konzept Schwierigkeitsgrad liese sich dann als Schwierigkeitsgrad {leicht, mittel, schwer} schreiben. Dies ist besonders nützlich, wenn es keine Möglichkeit gibt, das Konzept aus anderen Konzepten und Rollen aufzubauen. Im Gegensatz zu SHIQ (D) ist jedoch nur eine Kardinalitätsbeschränkung ohne Qualifizierung möglich (wie schon bei SHIN (D) beschrieben). Die in Abschnitt 4.3 vorgestellte Ontologiesprache OWL-DL basiert auf SHOIN (D).

29 Grundlagen Semantic Web SROIQ (D+) Zu den neuesten Entwicklungen auf dem Gebiet der Beschreibungslogik gehört die Logik SROIQ (D+). Die Grundlagen dazu stammen von Ian Horrocks et al. [12] und wurden 2006 auf der Konferenz Knowledge Representation and Reasoning vorgestellt. Der folgende Abschnitt stützt sich in Teilen auf Inhalte aus [12]. Die Erweiterungen gegenüber SHOIN betreffen die folgenden Bereiche: 1. H R: zu der hierarchischen Schachtelung von Rollen (H) kommt die Möglichkeit hinzu, Aussagen über Reflexivität, Irreflexivität, Anitsymmetrie und Disjunktheit von Rollen zu treffen. Im begrenztem Umfang lässt sich auch die Zusammensetzung von Rollen durch Axiome beschreiben. 2. N Q: bei einer Beschränkung der Kardinalität ist es auch möglich, eine Typisierung vorzunehmen. 3. (D) (D+) : Es können nicht nur die Standard-Datentypen wie in (D) verwendet werden, auch die Definition eigener Typen ist möglich. Die zusätzlichen Möglichkeiten von SROIQ gegenüber SHOIN werden im Folgenden sowohl theoretisch vorgestellt, als auch anhand einiger Beispiele veranschaulicht: Reflexivität Eine Relation ist reflexiv, wenn gilt: a A : (a, a) R. Dies kann z. B. auf die Rolle kennt(a, B) angewandt werden, denn jeder kennt sich selbst. Irreflexivität Für eine irreflexive Relation gilt: a A : (a, a) R. Das ist nützlich für die Rollendefinition istgeschwistervon(a, B), denn keiner zählt als Geschwister für sich selbst. Antisymmetrie Die Definition für Antisymmetrie lautet: a, b A : (a, b) R (b, a) R a = b. Die Verwendung ist beispielsweise sinnvoll bei der Rolle istteilvon(a, B). Disjunktheit Zwei Mengen (hier: Rollen) sind disjunkt, wenn sie kein gemeinsames Element besitzen. Während die Disjunktheit von Konzepten in den meisten Beschreibungslogiken ausgedrückt werden kann, ist die Disjunktheit von Rollen erst in SROIQ möglich. Damit lässt sich beispielsweise ausdrücken, dass die Rollen studiertan und istprofessoran disjunkt sind. Universelle Rolle U Als Gegenstück zu dem bereits in ALC eingeführten universellen Konzept (geschrieben als ), existiert in SROIQ auch eine universelle Rolle U, die für jede beliebige Rolle stehen kann. Komplexe Inklusion von Rollen Axiome der Form R S R und S R R können verwendet werden, um zu definieren, dass eine Rolle eine andere Rolle beinhaltet (subsumiert). Ein Beispiel soll das verdeutlichen: mit dem Axiom besitzt hatbauteil besitzt und der Tatsache, dass jedes Notebook mit einem Prozessor ausgestattet ist (Notebook hatbauteil.prozessor), lässt sich ausdrücken, dass der Besitzer eines Notebooks auch einen Prozessor besitzt: besitzt.notebook besitzt.prozessor Lokale Reflexivität In SROIQ kann ein Konzept mit R.Self definiert werden. So lässt sich z. B. das Konzept Narzist 2 als liebt.self formalisieren. 2 als Narzist wird eine selbstverliebte Person bezeichnet

30 26 C. Angeli Eine weitere Besonderheit der Logik SROIQ ist die Einführung einer Role Box (kurz RBox). Neben den gleichfalls vorhandenen ABoxen und TBoxen enthält die RBox alle Statements, die Rollen betreffen [12]. Formal definiert ist die RBox als Menge R = R h R a. Hierbei steht R h für eine reguläre Rollenhierarchie, R a bezeichnet eine (endliche) Menge von atomaren Rollen. Bei SROIQ (D+) handelt es sich gegenwärtig um die ausdrucksstärkste Beschreibungslogik, die entscheidbar ist, und für die (zumindest theoretisch) effiziente reasoning-algorithmen zur Verfügung stehen. 3.6 DLR Eine Beschreibungslogik, die sich deutlich von den bisher vorgestellten unterscheidet, ist DLR. Die Besonderheit ist, dass die auf AL basierenden Logiken nur binäre Rollen zulassen. Damit können nur (... ) Beziehungen zwischen [zwei] Konzepten repräsentiert werden, wohingegen in einigen Situationen in der realen Welt der Bedarf besteht, mehr als zwei Objekte in Relation zu setzen. ([1], Kap. 5.7) Aus diesem Grund sind in DLR n-stellige Relationen möglich. Die Grundbausteine sind atomare Konzepte (A) und Rollen (P). Mit der folgenden Syntax lassen sich n-stellige Konzepte und Rollen erstellen (aus: [1]): R n P ($i/n : C) R R 1 R 2 C 1 A C C 1 C 2 [$i]r k[$i]r Dabei gibt n die Stelligkeit der Relation an (2 n n max ; n max beliebig, aber fest). Die Variable $i verweist auf die i-te Komponente der Relation, 1 i n max. Genau betrachtet stellt DLR eine Erweiterung zu SQI dar, welche die beschriebenen n-stelligen Relationen einführt. Da DLR jedoch selten in der Praxis Anwendung findet, wird für weitere Details auf [1] verwiesen.

31 Grundlagen Semantic Web 27 4 Ontologiesprachen Die im Kapitel 3 vorgestellten Beschreibungslogiken sind die Grundlage für die im Semantic Web verwendeten Ontologiesprachen. Damit lässt sich diesen Sprachen die Ausdrucksmächtigkeit einer bestimmten Logik zuweisen. In den folgenden Abschnitten werden die wichtigsten Sprachen des Semantic Web betrachtet und ihre jeweilige Ausdrucksmächtigkeit anhand konkreter Sprachkonstrukte bewertet. 4.1 RDF und RDFS Das Resource Description Framework (RDF) ist eine der grundlegendsten Sprachen des Semantic Web. Seit 2004 gehört es zu den Empfehlungen des World Wide Web Consortiums (W3C). Das RDF dient dazu, Resourcen, insbesondere Internetseiten, mit Metadaten zu beschreiben. Jedoch ist RDF auf eine Grundmenge an Klassen beschränkt, die hauptsächlich dazu geeignet ist, einen Webresource mit Metadaten wie Autor, Titel, Version oder Erstellungs- und Änderungsdatum anzureichern. Um eigene Terminologien zu erstellen existiert eine Sprache zur Vokabeldefinition (RDF Vocabulary Description Language), RDF Schema. Damit lassen sich einfache Ontologien entwerfen, die Möglichkeiten für automatisches Reasoning sind jedoch sehr begrenzt. RDFS unterteilt alle Resourcen 3 in Klassen. Die Wurzelklasse, auf die sich alle anderen Klassen zurückführen lassen, ist rdfs:resource. Allgemeine Klassen werden durch rdfs:class beschrieben. Für Datentypen wird rdfs:datatype verwendet, einfache Literale, wie Integer oder String, fallen in die Klasse rdfs:literal. Um eine Ontologie zu erstellen, werden die Klassen zu sogenannten RDF- Tripeln verbunden. Diese Tripel haben dir Form Subjekt-Prädikat-Objekt und können zu komplexen RDF-Graphen kombiniert werden. Die Verbindung zwischen Subjekt und Objekt, also das Prädikat, wird in RDF durch Properties dargestellt. Dabei handelt es sich um binäre Relationen, entsprechend den Rollen in den Beschreibungslogiken. Die Menge der Properties wird ebenfalls zu einer Klasse zusammengefasst (rdfs:property). Beispiele für Properties in RDF sind etwa rdfs:domain und rdfs:range, mit denen die zulässigen Klassen für Subjekt und Objekt eingeschränkt werden. rdfs:subclassof und rdfs:subpropertyof werden benötigt um Hierarchien von Klassen und Properties zu erstellen, die einander subsumieren. Weitere Details zur Syntax und Grammatik von RDF und RDFS sind in den Empfehlungen des World Wide Web Consortiums 4 zu finden. 4.2 DAML+OIL Diese Ontologiesprache entstand durch die Zusammenführung der Entwicklung von DAML-ONT und OIL. DAML-ONT wurde vom DARPA, einer Forschungseinrichtung des US Verteidigungsministeriums, entworfen. DAML steht dabei für 3 Alles, was durch RDF beschrieben wird, wird als Resource bezeichnet. [18] 4

32 28 C. Angeli DARPA Agent Markup Language und wurde 2001 um das Ontologie Inference Layer OIL 5 erweitert. DAMl+OIL wurde entworfen, um die Struktur einer Domäne abzubilden; es verfolgt dabei einen objekt-orientierten Ansatz, der auf Klassen und Eigenschaften (Rollen) aufbaut. [10] Wie bereits in Teil 3.3 beschrieben, entsprechen die Möglichkeiten von DAML+OIL der Ausdrucksstärke SHIQ (D) bei den Beschreibungslogiken. An einem Codebeispiel lässt sich zeigen, wie etwa eine qualifizierte Kardinalitätsbeschränkung (Q) möglich ist. Betrachtet wird der DL-Ausdruck studiertan.universität. Ein ähnliches Beispiel wurde schon in Abschnitt 3.2 verwendet, jedoch ohne die Beschränkung auf Universität. In DAML+OIL würde, angelehnt an die RDF-Syntax, folgender Code geschrieben (Ausschnitt): 1 <daml:restriction daml:mincardinalityq="10000"> 2 <daml:onproperty rdf:resource="#studiertan"/> 3 <daml:hasclassq rdf:resource="#universitaet"/> 4 </daml:restriction> Obwohl DAML+OIL bereits viele Möglichkeiten zur Ontologie-Erstellung und zum Reasoning durch Inferenz-Algorithmen bietet, ist DAML+OIL inzwischen von OWL überholt. 4.3 OWL DL Bei der Web Ontology Language, kurz (OWL), handelt es sich ebenfalls um eine Spezifikation des W3C. OWL baut direkt auf RDF und RDFS auf und bringt wichtige Erweiterungen ein. Die Sprache kennt drei Ebenen: OWL Lite, OWL DL und OWL Full. Bei OWL Lite handelt es sich um eine eingeschränkte Variante, die sich hauptsächlich für einfache Konzept-Hierarchien mit wenigen einschränkenden Randbedingungen eignet. Die Ausdrucksstärke von OWL Lite entspricht der in Abschnitt 3.4 vorgestellten Logik SHIF (D). OWL Full hingegen bietet alle syntaktischen Möglichkeiten von RDF an, der Preis ist jedoch, dass die Entscheidbarkeit verloren geht. OWL DL (Description Logic) bietet hier den besten Kompromiss: es unterstützt alle Konstrukte der Logik SHOIN (D), garantiert jedoch Vollständigkeit 6 und Entscheidbarkeit 7. Ein kurzes Beispiel soll die Modellierungsmöglichkeiten mit OWL DL veranschaulichen. Es soll der Ausdruck Student Person studiertan.universität aus der Beschreibungslogik in die OWL Syntax übertragen werden. 1 <owl:class> 2 <owl:intersectionof rdf:parsetype="collection"> 3 <owl:class rdf:about="#person"/> 5 Selten auch als Ontologie Interchange Language bezeichnet, siehe: 6 Alle gültigen logischen Folgerungen können berechnet werden. 7 Alle Berechnungen terminieren in endlicher Zeit.

33 Grundlagen Semantic Web 29 4 <owl:restriction> 5 <owl:onproperty rdf:resource="#studiertan"/> 6 <owl:toclass> 7 <owl:class rdf:about="#universitaet"> 8 </owl:toclass> 9 </owl:restriction> 10 </owl:intersectionof> 11 </owl:class> Das Schlüsselwort Class definiert eine Klasse, entsprechend einem Konzept in den Beschreibungslogiken. Mit owl:intersectionof in Zeile zwei wird die Schnittmengenbildung von Klassen formuliert, analog zu im DL-Statement. Zeile drei nennt die Klasse Person als ersten Teil der Schnittbildung, in Zeile vier wird mit <owl:restriction> die zweite Klasse des Schnitts deklariert. Diese Deklaration geschieht implizit, in dem alle Klassen zusammengefasst werden, die der Rolle studiertan im owl:onproperty...-statement entsprechen. In Zeile sechs und sieben wird schließlich eine weitere Typbeschränkung vorgenommen, die verlangt, dass alle Objekte, die in der Rollenbeziehung stehen, aus der Klasse Universität stammen müssen. 4.4 OWL 1.1 Bei OWL 1.1 handelt es sich um eine Weiterentwicklung von OWL DL. Es werden neue Sprachelemente eingführt, die die Ausdrucksstärke deutlich erhöhen. Dabei wurde jedoch darauf geachtet, dass die Entscheidbarkeit erhalten bleibt und effiziente Inferenz-Algorithmen zur Verfügung stehen. Die Expressivität wird dabei von SHOIN (D) auf SROIQ (D+) erweitert. OWL 1.1 beruht auf der theoretischen Arbeit von Ian Horrocks et al.[12]. Seit September 2007 gibt es dazu eine Arbeitsgruppe, im Januar 2008 wurden erste detailliertere Dokumente zu OWL 1.1 als Working Draft des W3C veröffentlicht. 4.5 SWRL Die Semantic Web rule-language SWRL ist eine Kombination aus den Ontologiesprachen OWL Lite, OWL DL und der Regelsprache RuleML (Rule Markup Language). Das Ziel von SWRL ist der Entwurf einer Regelsprache für das Semantic Web. Für SWRL sind verschiedene Syntax-Varianten definiert, die für unterschiedliche Zwecke gedacht sind: (vgl. [13]) abstrakte Syntax Sie soll für den Menschen lesbar sein und so einen einfachen Zugang zum Verständnis der Regeln bieten. Diese Syntax baut auf der erweiterten Backus-Naur Form (EBNF) auf. konkrete XML Syntax Diese Variante kombiniert die XML-Darstellungen von OWL und RuleML. Der Vorteil ist hier, dass Ontologie Axiome und Regeln frei kombinert werden können, und dass eine einfache Interoperabilität zwischen den Werkzeugen gewährleistet ist.

34 30 C. Angeli konkrete RDF Syntax Regeln können in SWRL auch durch eine RDF Syntax beschrieben werden. Die Verwendung von Variablen in den Regeln übersteigt jedoch die Semantik von RDF. Ob eine entsprechende semantische Erweiterung von RDF möglich ist, ist nicht bekannt. Werden alle Modellierungsmöglichkeiten von SWRL ausgeschöpft, so sind die Ontologien nicht mehr entscheidbar. Für die Verwendung mit automatischen Inferenz-Systemen muss die Sprache daher eingeschränkt werden. Somit kann eine generelle Mächtigkeit der Sprache nicht angegeben werden. Eine geeignete Einschränkung von SWRL auf Description Logic Programs 8 wird bei [8] gezeigt. 5 Zusammenfassung und Ausblick Obwohl die Idee für das Semantic Web schon 1998 formuliert wurde ([3]) und die theoretischen Grundlagen der Beschreibunglogik seit 1940 bekannt sind ([5]), ist die Enwicklung leistungsfähiger Logiken für Ontologien noch immer ein wichtiger Gegenstand der Forschung. So baut die aktuell entwickelte, neue Version der Web Ontologie Language, OWL 1.1, direkt auf den Mitte 2006 veröffentlichten Ergebnissen von I. Horrocks zu der Logik SROIQ ([12]) auf. Durch die Verbesserung der Beschreibungslogiken, der Ontologiesprachen und der reasoning-algorithmen ist es möglich, immer größere und komplexere Ontologien zu entwerfen und zu verarbeiten. Die theoretischen und technischen Grundlagen für das Semantic Web sind damit gegeben. Um der Vision von Tim Berners-Lee zum Durchbruch zu verhelfen, ist es notwendig, die Konzepte und Techniken des Semantic Web auch in der Praxis einzusetzen. Ein erster Schritt wäre der konsequente Einsatz von Metadaten in Internetseiten, um die Inhalte automatisch zu erfassen. Die Standards zur Barrierefreiheit von Webseiten unterstützen dieses Ziel. So ist es für barrierefreie Seiten vorgesehen, Bilder immer mit <alt>-tags zu versehen, die den Inhalt des Bildes beschreiben. Gliedernde <div>-elemente müssen mit einem Titel versehen werden, der das Thema des Abschnitts geeignet beschreibt. Damit diese Metatags auch automatisch verarbeitet werden können reicht es nicht aus, die Syntax durch eine Sprache wie RDFS oder OWL festzulegen. Für eine klar definierte Semantik ist auch eine Ontologie notwendig, die die Bedeutung der Begriffe festsetzt. Für Metadaten, die Dokumente beschreiben, kann etwa die Dublin Core 9 Ontologie verwendet werden. Je mehr von den Möglichkeiten, die Ontologien im Semantic Web bieten, umgesetzt wird, desto besser und leichter können die Angebote im Internet genutzt werden. 8 Eine andere Art der Wissensrepräsentation als die in dieser Arbeit beschreibene Description Logic 9

35 Grundlagen Semantic Web 31 Literatur [1] F. Baader, D. Calvanese, D. L. McGuinness, D. Nardi, and P. F. Patel-Schneider. The Description Logic Handbook: Theory, Implementation, and Applications. Cambridge University Press, [2] E. Bergmann and H. Noll. Mathematische Logik mit Informatik-Anwendungen. Springer, [3] T. Berners-Lee. Semantic web road map. W3C Draft, Sept org/designissues/semantic.html. [4] T. Berners-Lee, J. Hendler, and O. Lassila. The semantic web. Scientific American, 284(5):34 43, [5] A. Church. A formulation of the simple theory of types. The Journal of Symbolic Logic, 5(2):56 68, [6] S. Decker and I. Horrocks. Knowledge representation on the web. In Proc. Int l Workshop on Description Logics (DL2000), [7] E. Franconi. Description logic tutorial course [8] B. N. Grosof, I. Horrocks, R. Volz, and S. Decker. Description logic programs: Combining logic programs with description logic. In Proc. 12th Int l World Wide Web Conf., May [9] T. R. Gruber. A translation approach to portable ontologies. Knowledge Acquisition, 5(2): , [10] I. Horrocks. DAML+OIL: a description logic for the semantic web. Bull. of the IEEE Computer Society Technical Committee on Data Engineering, 25(1):4 9, [11] I. Horrocks. Applications of description logics: State of the art and research challenges. Proceedings of the 13th International Conference on Conceptual Structures, pages 87 90, [12] I. Horrocks, O. Kutz, and U. Sattler. The even more irresistible SROIQ. In Proc. of the 10th Int. Conf. on Principles of Knowledge Representation and Reasoning (KR 2006), pages AAAI Press, [13] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, and M. Dean. Swrl: A semantic web rule language combining owl and ruleml. W3C Member submission, May [14] B. Nebel and S. Wölfl. Knowledge representation and reasoning vorlesung, [15] F. Rötzer. Neuer rekord: 100 millionen websites weltweit. heise online - News, 01. November [16] U. Schöning. Logik für Informatiker. B.I.-Wissenschaftsverlag, [17] W. Vogler. Logik für informatiker vorlesungsskript, [18] Rdf vocabulary description language 1.0: Rdf schema. W3C Recommendation,

36 Reasoning: Rete (und Jena) Thomas Eisenbarth Universität Augsburg Zusammenfassung Reasoning als Bestandteil des Semantic Webs befasst sich mit der von Logik geleiteten, intelligenten Beantwortung von Anfragen und Hinzulernen durch Maschinen. Das Ziel ist es, einen gesundenen Menschenverstand zu imitieren, indem der Maschine die tatsächliche Bedeutung von Fakten bekannt gemacht wird. Diese Herausforderung geht mit ernormen Datenmengen einher, auf Basis derer diese Semantik aufgebaut wird. Die Benutzung von trivialen Algorithmen zur Lösung von Problemen und Anfragen auf den Daten, führt häufig zu einer inakzeptablen Komplexität in Form von Laufzeit- und/oder Speicherbedarf. Dies wiederum behindert den Einsatz dieser Systeme in der Realität, in der sie beispielsweise in Geschäftsprozessmanagement- und Optimierungswerkzeugen Anwendung finden. Als einer der ersten Lösungsansätze entstand 1974 der Rete-Algorithmus. Dieser ist (in abgewandelter und zumeist optimierter Form) die Grundlage für viele bekannte und sich im Einsatz befindende Expertensysteme. 1 Aus diesem Grund ist es sinnvoll, die Hintergründe und Abläufe dieses Algorithmus zu kennen. Wir fassen die Funktionsweise von Rete zusammen und vergleichen diverse konkrete Implementierungen. 1 Einleitung Eine Fähigkeit der menschlichen Natur ist es, durch Lernen aus vergangenen Entscheidungen und daraus resultierenden Ergebnissen zu lernen. Computer dagegen haben im allgemeinen nicht diese Fähigkeit zu lernen. Um elektronischen Geräten im allgemeinen und Computern im speziellen zum einen dieses Lernen zu ermöglichen und zum anderen Entscheidungen (nach Möglichkeit auch noch) korrekt zu treffen, ist es notwendig, Wissen zu formulieren und den Maschinen zur Verfügung zu stellen. Wie landläufig bekannt ist, haben elektronische Geräte die Eigenschaft, dass man diesen selbst die einfachsten Zusammenhänge umfangreich darzulegen hat. Dies hat zur Folge, dass die sogenannten Expertensysteme, welche Computer zur Lösung von komplexen Problemen bewegen sollen, mit riesigen Datenmengen als Grundlage umzugehen haben. Auf dieser Basis werden Algorithmen verwendet, die aus dem Berg an Daten die für den Anwender relevanten heraussuchen und diesem (womöglich in anderer Repräsentation) als Lösung präsentieren. Der einfachste - jedoch leider ebenso inakzeptable - Weg zu 1 U.a. Jena, Red Hat s JBoss Rules, die Haley Ltd. und ILOG-Produktketten basieren auf Rete.[13, 12, 16, 15]

37 Reasoning: Rete (und Jena) 33 Abbildung 1. Einordnung von Rete im Semantic-Web. einer solchen Problemfindung wäre der folgende: Der Computer führt Listen über die Regeln eines solchen Systems und durchläuft diese Listen linear und ohne weitere Strategie zur Suche nach der gewünschten Lösung. Sei r nun die Anzahl der Regeln, p die Durchschnittliche Anzahl an Prämissen für diese Regeln und f die Anzahl an Fakten, so ist die Komplexität des beschriebenen Systems gleich O(rf p ) (1) Bei steigender Anzahl an Regelprämissen ist diese Laufzeit zu ungünstig, um damit ernsthaft arbeiten zu können. Charles L. Forgy fand im Zuge seiner Arbeit an der Carnegie Mellon University heraus, dass herkömmliche Systeme damals bis zu 90% ihrer Laufzeit mit Mustervergleichen (engl. pattern matching ) beschäftigt waren.[14] Man benötigt also eine effiziente Vorgehensweise, um schnell an die gewünschten Ergebnisse zu gelangen. Forgy hat einen Weg vorgestellt, der dies möglich macht: Der Rete-Algorithmus. Im Umfeld des Semantic Web lässt sich Rete als eine mögliche Basis von Reasoner-Systemen sehen. In der wohl bekannten Übersicht, die in Abbildung 1 dargestellt ist, kann man Rete damit auf der Ebene der OWL bzw. Rules einordnen. Im Zuge dieser Arbeit wollen wir in Kapitel 2 zunächst Begrifflichkeiten rund um Reasoning sowie Rete klären und konkrete Beispiele für die verwendeten Termini geben. Anschließend beschreiben wir in Kapitel 3 die einzelnen Schritte des Algorithmus im Detail und betrachten in Kapitel 4 das Thema Optimierungen im originalen Rete sowie Erweiterungen und weitere Verbesserungen von Nachfolgern. In Kapitel 5 betrachten wir den Zusammenhang von Rete und Jena und die Möglichkeiten des OWL-Reasonings in Jena.

38 34 T. Eisenbarth 2 Hintergrund und Einführung in Rete Reasoning-Systeme lassen sich anhand ihrer unterschiedlichen Funktionsweise grundsätzlich differenzieren: Rückwärts-verkettete 2 Algorithmen starten mit einer Menge von Schlussfolgerungen und arbeiten sich rückwärts zum Antezedenz durch, um zu prüfen, ob Daten vorhanden sind, die auf die gesuchten Schlussregeln passen. Dafür muss man wissen, nach welchen Zielen man sucht. In einem kriminologischen Expertensystem könnte man beispielsweise untersuchen wollen, ob ein Verdächtiger der Täter eines Verbrechens ist. Ein Indiz bei rückwärts verketteten Algorithmen das Ziel dar, wofür unser System den Nachweis sammeln muss: Es wird also versucht, alle Schlussregeln zu finden, die für die Überführung des Verdächtigen sorgen. Daraufhin muss gezeigt werden, dass die Vorbedingungen der Schlussregel ebenfalls wahr sind. So werden diese Vorbedingungen zum neuen Ziel, die wie beim ursprünglichen Ziel bewiesen werden müssen. Das Ergebnis ist entweder die Überführung des Täters in Form einer vollständigen, geprüften Kette ausgehend vom Ziel-Knoten. Andernfalls finden wir womöglich keine weiteren Regeln, deren Konklusionen bzw. Aktionen in die Kette passen. Der Verdächtige wäre dann unschuldig. Die zweite Möglichkeit ist die Nutzung von vorwärts-verketteten Algorithmen. 3 Im Gegensatz zu rückwärts gerichteten Algorithmen arbeitet das System hier Daten-gesteuert. Es werden also Daten in das System gegeben, die letztendlich entscheiden, ob eine Regel ausgeführt wird oder nicht. Sofern eine Ausführung der Regel(n) stattfindet, können damit wiederum solange neue oder abgeänderte Daten in das System eingespeist werden, bis eine Entscheidung möglich ist.[18] Charles L. Forgy hat in seiner Dissertation [5] bereits 1979 die Idee seines Algorithmus Rete beschrieben und diese in den darauf folgenden Jahren verfeinert. [8, 6] Rete bezeichnet das lateinische Wort für Netzwerk und wurde aufgrund der Organisationsform des Graphen gewählt, die ein Rete ausmacht. Die grundsätzliche Überlegung hinter Rete besteht aus folgenden Punkten: Ein Knoten im Graph repräsentiert eine Vorbedingung. Der Pfad vom Wurzelknoten zu einem Blatt stellt eine Menge von Vorbedingungen (die gesamte Liste von Vorbedingungen zu einer Aktion). Rete eliminiert Redundanzen dadurch, dass Knoten mehrfach verwendet werden (können). Es werden Teil-Lösungen gespeichert, wenn Fakten verbunden werden. Dadurch muss nicht das gesamte Netz neu berechnet werden, falls sich Fakten ändern. Diese (und weitere) charakteristischen Eigenschaften werden wir im folgenden genauer beschreiben. Eine Übersicht über verwendete Termini und deren Einordnung in Rete ist in Abbildung 2 dargestellt. Grundsätzlich werden bei Rete zwei Arten von Speicher unterschieden: Produktionsspeicher ( Production memory, PM) und Arbeitsspeicher ( working memory, WM). 2 engl. Backward-Chaining 3 engl. Forward-Chaining

39 Reasoning: Rete (und Jena) 35 Rete:,,Big Picture'' Arbeitsspeicher (WM) Produktionsspeicher (PM) Working Memory Elements (WMEs): Abbild der Welt und/oder des Systems selbst Produktionen (,,Regeln'') (Regelname LHS --> RHS) Alpha-Teil Tests auf Konstanten Beta-Teil Joins und Beta- Speicher Abbildung 2. Rete: Übersicht der Termini als Big picture. 2.1 Produktionsspeicher: PM Der Produktionsspeicher besteht aus Elementen, die ihrerseits wiederum zum einen als Regelprämissen (auch als Left Hand Side, LHS) und zum anderen als Right Hand Side (RHS) bezeichnet werden. Letztere sind zusammengesetzt aus Prämissen und Konklusionen. Zusammengefasst als Einheit nennt man die beiden Elemente Produktionen oder Regeln. Die Regel haben folgende Form: wenn Bedingung, dann Handlung. Im Allgemeinen können die beiden Teile der Regel unterschiedlich interpretiert werden: Als Schlussregel: Wenn Prämisse, dann Konklusion. Diese Form findet beispielsweise in der formalen Logik als Transformationsregel in einem Kalkül Anwendung. Als Hypothese: Wenn Anhaltspunkt, dann Hypothese. Als Hypothese ist eine Regel beispielsweise aus der Medizin als Diagnose bekannt. Als Produktion: Wenn Bedingung, dann Aktion.

40 36 T. Eisenbarth Diese Form von Regel finden wir in Produktionssystemen. Auch in Rete haben die Regeln diese Form. Konkret sehen Produktionen in Rete normalerweise folgendermaßen aus: Listing 3.1. Schema von Produktionen 1 ( Name der Regel 2 Left - hand - side, LHS : Regelpraemisse (n) 3 --> 4 Right -hand -side, RHS : Aktion (en) 5 ) In den Regelprämissen können Variablen verwendet werden. Diese sind in der Literatur wie auch in unserer Arbeit von spitzen Klammern umgeben: <x> Als konsistentes Beispiel in dieser Arbeit wollen wir uns eine Bibliothek vorstellen. Diese hat Bücher im Bestand, die in bestimmten Fachrichtungen (Informatik, Mathematik) einsortiert sind, verliehen werden können und von Verlagshäusern verlegt werden. Ein konkretes Beispiel für eine (Produktions-)Regel wäre: Listing 3.2. Konkrete Beispiel-Produktionen 1 ( Finde - ausgeliehenes -Buch - einsortiert -in - Informatik -mit - Verlag - Springer 2 (<x> ausgeliehen - an <y>) 3 (<x> einsortiert - in <z>) 4 (<x> verlegt - von Springer ) 5 --> 6 BeliebigeAktion () 7 ) Die RHS mit ihren Aktionen ist für den Rete-Algorithmus zunächst nicht von Bedeutung, da Rete die Suchfunktionalität, also die LHS, übernimmt. In konkreten Implementierungen übernehmen die Suchalgorithmen wie Rete das Finden einer Lösung. Andere Teile (Module) des Systems werden dann zur Ausführung der Regeln verwendet.[3, S.8.] Eine sinnvolle Möglichkeit für Aktionen wäre beispielsweise, neue Fakten in das System zu geben, die auf den Ergebnissen aufbauen, die durch die Auslösung gelernt wurden. 2.2 Arbeitsspeicher: WM Der Arbeitsspeicher eines Rete-Netzes besteht aus Working Memory Elements (WME). Diese beschreiben als Faktenbasis ein Modell der Realität des Rete und werden als n-tupel dargestellt. WMEs zu unserem Beispiel könnten also wie folgt aussehen: 1 w1: ( B1 verlegt - von Springer ) 2 w2: ( B1 einsortiert - in Mathematik ) 3 w3: ( B2 verlegt - von Pearson ) 4 w5: ( B2 einsortiert - in Informatik ) 5 w6: ( B2 ausgeliehen - an Thomas ) 6 w7: ( B1 ausgeliehen - an Hans ) 7 w8: ( B3 verlegt - von Pearson ) 8 w9: ( B4 einsortiert - in Informatik ) Listing 3.3. Beispiel-WMEs

41 Reasoning: Rete (und Jena) 37 Wie man sieht, setzen sich einfache WMEs z.b. als Tripel in der Form Objekt, Attribut, Wert zusammen. Die Einschränkung auf die Form des Tripels wird in der Literatur häufig aufgrund der Einfachheit gewählt. Grundsätzlich sind jedoch auch andere, komplexere Repräsentationen denkbar. In WMEs sind immer nur Konstanten und keine Variablen erlaubt. 3 Der Rete-Algorithmus Das Rete selbst ist ein Datenflußgraph, bestehend aus einem Alpha - sowie einem Beta -Teil: 3.1 Der Alpha-Teil WMEs Start verlegt-von? einsortiert-in? ausgeliehen-an? Hans Pearson Springer Mathematik Geographie Informatik Physik Thomas AM1 AM2 AM3 AM4 AM5 AM6 AM7 AM8 Abbildung 3. Alpha-Teil des Rete-Netzes. Pro Vorbedingung einer Produktionsregel wird im Alpha-Teil eine Filterregel mit genau dieser Vorbedingung angelegt. Als Tests der Vorbedingungen sind prinzipiell alle Funktionen vorstellbar, die einen Wahrheitswert (Boolean, true/false) zurückliefern können. Wie an unserem Beispiel zu erkennen ist, sind die auszuführenden Tests häufig Gleichheitsfunktionen. Konkrete Implementierungen von Rete unterstützen jedoch auch andere Funktionen (größer, kleiner, etc.). [3, S.10] Als Input in diese Filterregeln werden die WMEs gegeben: Von einem Startknoten aus werden die WMEs gegen die Filterregeln der Vorbedingungen

42 38 T. Eisenbarth geprüft. Als Output der Regel speichert Rete alle WMEs, die die Filterregel erfolgreich erfüllen. WMEs, die keine einzige Regel treffen werden verworfen. Die Liste an treffenden WMEs werden als Alpha-Speicher ( alpha memory, AM) bezeichnet und im Alpha-Teil des Graphen gespeichert. Rete würde im Beispiel als einen konkreten Alpha-Speicher also all diejenigen WMEs hinterlegen, die die Regel verlegt-von erfüllen. Ein weiterer Alpha-Speicher mit den entsprechend passenden WMEs würde für einsortiert-in angelegt. Anschaulich dargestellt wird dies in Abbildung Der Beta-Teil Der Beta-Teil des Rete-Netzes ist optional und besteht aus Knoten, die zwei Eingangskanten (veranschaulicht dargestellt als linke bzw. rechte Eingangskante) aufnehmen. Die üebergebenen Objekte heißen Tokens und dienen als Datenhalter z.b. für WMEs oder Listen von WMEs. In einigen Implementierungen werden die Token auch für die Alpha-Speicher verwendet. Dort halten diese jeweils ein einzelnes WME sozusagen als Wrapper. In der Regel ist eine der Eingangskanten durch einen Alpha-Speicher aus dem Alpha-Teil des Netzes belegt. Die zweite Kante wird durch Vorgänger-Tokens belegt. Der Wurzelknoten des Beta-Netzes ist ein spezieller Knoten: Er gibt keine Informationen an seine Nachfolger ab, um einen Einstieg in den Graphen zu ermöglichen. Es gibt mehrere Ansätze dieses Problem zu umgehen: Einige Implementierungen bieten einen Adapter für Alpha-Speicher, andere erlauben es, dass beide Eingangsknoten direkte Alpha-Speicher sind. Der Beta-Teil ist hauptsächlich zuständig für Join-Operationen, deren Resultate wiederum in Tokens gespeichert werden. Die Verknüpfung der Tokens wird durch eine JOIN-Operation realisiert, wie in 3.4 zu sehen ist. Listing 3.4. Join-Operation der Beta-Knoten 1 X Y Y Z 2 ========= ============ 3 foo John 4 and 10 5 bar Doe 6 7 Ergebnis eines Join auf beiden Knoten : 8 9 X Y Z 10 ====================== 11 foo 23 John 12 bar 42 Doe Das Ergebnis der Join-Operationen besteht also aus einer Kombination von Tokens die beispielsweise einige der Produktionsregeln treffen. Dieses Ergebnis wird Beta-Speicher. Der grundsätzliche Zweck ist die Speicherung von Referenzen bzw. Listen auf WMEs p-knoten Das Ergebnis der Verknüpfungskette ist eine Liste all derjenigen WMEs, die auf alle Regeln treffen oder eine leere Liste, sofern kein WME

43 Reasoning: Rete (und Jena) 39 alle Bedingungen erfüllt. Dieser Verbund von Fakten in Form von Tokens, die auf einen bestimmten Satz an Produktionsregeln zutreffen wird auch als Konfliktmenge (engl. conflict set ) bezeichnet. Der Token, der das Zutreffen aller Produktionsregeln beschreibt und damit ein Blatt des Baumes darstellt, wird auch Terminalknoten oder p-knoten (Produktions-Knoten) genannt. Für den Fall dass ein WME mehrere Produktionen erfüllt und dadurch auch mehrere Aktionen der RHS ausgeführt werden müssen, befinden sich diese im Konflikt. Als Agenda wird diese Liste der Aktionen genannt. In dieser werden Listen auszuführenden und aller (zeitlich) geplanter Aktionen geführt. Zeitlich geplante Aktionen werden ausgeführt, falls sie nach einer gewissen Zeit immer noch wahr sind.[4] Die Agenda kümmert sich auch um die Reihenfolge, in der die Regeln ausgeführt werden. Für die Lösung des Problems der Reihenfolge existieren eine Reihe von möglichen Ansätzen:[7] FIFO / LIFO: Die einfachsten und wahrscheinlich bekanntesten Varianten verwenden die Listenpositionen als Entscheidungsgrundlage. FIFO führt die ältesten Aktionen zuerst aus. LIFO arbeitet wie ein Stack und nimmt die neuesten Elemente mittels pop vom Stack bzw. aus der Liste. Salience benutzt einen ganzzahligen Wert zum Festlegen der Priorität. Höhere Zahlen bedeuten hierbei höhere Priorität. Komplexitätsbasierte Lösungsverfahren nehmen beispielsweise die Anzahl der Prämissen als Maß der Komplexität und setzen komplexere Aktionen an die Spitze der Agenda. Zusammenfassend lässt sich feststellen, dass der Alpha-Teil des Netzes alle Tests durchführt, die nur ein WME betreffen. Der Beta-Teil ist für alle anderen verantwortlich, in denen zwei oder mehr WMEs vorkommen. Abbildung 4, in Anlehnung an veranschaulicht dies. 3.3 Entfernen von WMEs Fakten (also WMEs in der Rete-Welt) ändern sich zwar nicht sehr häufig (zumindest im Vergleich zur Frequenz, mit der die Produktionen sich ändern). Dennoch muss man natürlich die Möglichkeit bedenken, dass WMEs entfernt werden müssen: Es müssen also alle Einträge im Alpha-Teil sowie im Beta-Teil entfernt werden. Im originalen Rete-Algorithmus hat Forgy das Entfernen von WMEs effektiv gleich realisiert, wie das Hinzufügen von Fakten. Der einzige Unterschied war, dass beim Entfernen in den entsprechenden Methoden ein spezielles Flag gesetzt war, mit dem zwischen Hinzufügen und Löschen unterschieden wurde.[3, S.28] Die Methoden, die die Join-Knoten behandeln, verfahren beim Löschen genauso. Der Vorteil besteht darin, dass sowohl das Hinzufügen als auch das Löschen effektiv mit den gleichen Methoden durchgeführt werden kann. 3.4 Bearbeiten von WMEs Wie wir bereits festgestellt haben, ändern sich Fakten im Vergleich zu Anfragen seltener. Dennoch muss man Anpassungen der Faktenbasis vornehmen, beispiels-

44 40 T. Eisenbarth Abbildung 4. Das gesamte Rete-Netz weise wenn man zeitliche Attribute in seinen Fakten hält. Älter werden wäre eine typische Operation, bei der ein Attribut nach Ablauf einer Frist inkrementiert wird. Das Bearbeiten von WMEs ist im originalen Rete jedoch nicht vorgesehen und muss über den Umweg realisiert werden, dass das zu bearbeitende WME entfernt, und ein neues WME eingefügt wird. 3.5 Negierte Prämissen Neben Tests auf die Existenz von WMEs im Arbeitsspeicher eines Rete möchte man auch überprüfen können, ob sich ein WME nicht im Speicher befindet. Die Syntax zur Darstellung lautet folgendermaßen: Listing 3.5. Konkrete Beispiel-Produktionen 1 (<x> ausgeliehen - an <y>) /* B1 */ 2 (<x> einsortiert - in <z>) /* B2 */ 3 -(<x> verlegt - von Springer ) /* B3 */

45 Reasoning: Rete (und Jena) 41 Dieser Ausschnitt einer Produktionsregel trifft dann zu, wenn x ausgeliehen ist in y, einsortiert ist in z, und nicht von Springer verlegt wurde. In Rete bedeutet dies, dass im Beta-Netz ein WME lediglich weiter nach unten im Baum gereicht wird, wenn die Produktionen B1 und B2 zutreffen und x mit der gleichen Variablenbindung nicht auf die Bedingung B3 anspricht. Negierte Prämissen werden häufig als abgeleitete Beta-Speicher implementiert, die prinzipiell einen identischen Funktionsumfang besitzen und auch Alpha- Speicher als Eingangskanten erhalten. Während bei normalen Beta-Speichern die Ergebnisse des Joins weitergereicht werden, müssen beim negativen die Ergebnisse der Joins zwischengespeichert werden. Das Token wird nur weitergegeben, sofern der Zwischenspeicher leer ist. Dies ist der Indikator, dass kein WME im Arbeitsspeicher existiert, das die beschriebene negierte Prämisse beinhaltet. 3.6 Hinzufügen und Entfernen der Produktionen Es wird häufig davon ausgegangen, dass Rete der Hinzufügen oder Entfernen von Produktionen nicht oder nur durch eine vollständige Neugenerierung des gesamten Rete-Netzes unterstützt. Dieser Trugschluss rührt von der Beschreibungssprache OPS5 her, die vom Rete-Erfinder Forgy definiert wurde und die erste erfolgreich eingesetzte Sprache für ein Expertensystem war. Auf dem Bereich der Modifikation von Produktionen, sprich Hinzufügen und Entfernen hatte OPS5 Defizite.[3] Beim Hinzufügen von Produktionen startet man am Startknoten des Beta-Netzes und arbeitet den Weg nach unten und fügt neue Beta Speicher bzw. Tupel ein oder findet ebensolche, die mitverwendet werden können. Ebenso muss der Alpha-Teil des Netzes durch die Wiederverwundung von Knoten oder durch Einfügen angepasst werden. 3.7 Laufzeitverhalten Obwohl Rete einen deutlichen Vorteil gegenüber primitiven Algorithmen bringt, hat die Original-Variante von Forgy auch Nachteile, von dem man in der Literatur regelmäßig liest: Der hohe Speicherverbrauch. Diese Feststellung gilt zumindest für die ersten Implementierungen von Rete, bei denen beispielsweise an vielen Stellen Kopien der WME-Instanzen angelegt wurden, anstatt mit Zeigern zu arbeiten. Eine zweite Sonderheit betrifft Expertensysteme im allgemeinen: Bei Graphen mit vielen Tausend oder Millionen Einträgen ist es entscheidend, nie das gesamte Netz ablaufen zu müessen. Eine derartige Operation wäre direkt proportional zur Größe des Rete-Netzes, was insgesamt zu einer geringen Skalierbarkeit führen würde. Denkt man an eine Implementierung von Rete in Java muss man beispielsweise die Konsequenzen des Mark & Sweep -Java Garbage Collectors mit einrechnen, der bei der Skalierbarkeit auch eine Grenze darstellen könnte. Garbage Collection durchläuft normalerweise alle Objektinstanzen und sucht nach Referenzen auf die untersuchte Instanz. Falls keine Referenz gefunden wird, kann das Objekt zerstört werden. Bei potentiell Millionen von Objekten ist die dadurch entstehende Problematik der Skalierbarkeit klar. Die einzigen Möglichkeiten dieses Problem anzugehen bestehen darin, einen intelligenteren

46 42 T. Eisenbarth (also spezielleren) Garbage Collector dafür zu verwenden, oder die Verwaltung des Speichers selbst zu übernehmen. Letzteres ist einfach, nachdem die Lebenszeit der zu verwaltenden Objekte klar definiert ist: Tokens werden dann entfernt, wenn ein WME entfernt wird. Andere bei anderen Objekte, wie beispielsweise den Produktionsregeln, ist der Lebenszyklus durch das Hinzufügen bzw. Entfernen der Produktion klar geregelt. Die Optimierung von Speicherplatz und Laufzeitverhalten war in der Vergangenheit neben Erweiterungen von Rete eines der Forschungsschwerpunkte. Wir wollen diese nun detaillierter betrachten. 4 Optimierungen und Nachfolger des Algorithmus Die Grundlage des Erfolgs von Rete beruht auf folgenden Eigenschaften: Rete speichert Ergebnisse der letzten Regel-Tests. Dies hat zur Folge, dass lediglich neue Fakten (WMEs) tatsächlich gegen die LHSs getestet und berechnet werden müssen. Die Komplexität von Rete ist also etwa O(rfp). Ein Vergleich zu der in der Einleitung genannten, exponentiellen Laufzeit von möglichen anderen Algorithmen machen die Vorteile von Rete deutlich. Zwei empirische Beobachtungen von Forgy bilden die Grundlage für die eingebauten Optimierungen:[9] Temporale Redundanz : Das Ausführen einer Aktion ändert gewöhnlich nur wenige Fakten.[9] Strukturelle Gleichheit: Identische Knoten tauchen häufig auf der LHS auf, es werden also die gleichen Prämissen verwendet. Diese Tatsachen benutzte Forgy, um Rete anzupassen. Folgende Optimierungen sind Bestandteil des originalen Rete-Algorithmus: 4.1 State-saving Diese Optimierung baut darauf, dass bei Änderungen des Arbeitsspeichers die Ergebnisse der Änderung einmalig in das Rete-Netz eingepflegt (also die Ergebnisse berechet) werden. Bei der nächsten Änderung des Arbeitsspeichers bleiben die meisten der vorherigen Modifikationen erhalten. Dadurch spart sich der Rete-Algorithmus die Neu-Berechnung der Änderungen. Diese Optimierung baut auf der Voraussetzung auf, dass sich Fakten (WMEs in Rete) zum einen weniger häufig ändern, als Anfragen gestellt werden. Zum anderen dürfen sich nur überschaubare Teile des gesamten Arbeitsspeichers ändern. Sollten die genannten Voraussetzungen in einer Umgebung nicht gelten, wäre dieser Rete-Mechanismus unter Umständen ineffizient.[3] 4.2 Teilen von Knoten Das Teilen von Knoten findet an mehreren Stellen in Rete statt. Im Alpha- Teil speichert Rete nur einen Alpha-Speicher, sofern mehrere Produktionen die gleichen Regeln haben, anstatt Duplikate zu erstellen. Wenn zwei oder mehr

47 Reasoning: Rete (und Jena) 43 Produktionen identische Prämissen haben, werden im Beta-Teil die gleichen Knoten dafür verwendet. Durch das Einsetzen eines Dummy -Root-Knotens entsteht im Beta-Teil von Rete ein Baum. 4.3 Erweiterungen des Original-Algorithmus Wie wir im vorherigen Abschnitt erläutert haben, biete der originale Rete- Algorithmus von Forgy Optimierungspotential. In den Jahren nach der ersten Veröffentlichung wurden diverse Erweiterungen und Optimierungen vorgeschlagenen: Viel Energie wurde in den Jahren auf die Optimierung von Rete auf Multiprozessorsysteme verwendet. Obwohl diese Algorithmen schneller zum Ziel kommen als die Sequentiellen, bilden die gleichen Algorithmen die Basis. Durch die hohe Verbreitung von SMP-Systemen (sogar in Consumer-Hardware durch Intel Core2Duo, etc.) in den letzten Jahren, wächst der Einfluss solcher Optimierungen sicher weiter. Eine (verkürzte) Übersicht weiterer Nachfolger des Algorithmus sei hier gegeben:[3, S.53] Modify-in-place erweitert Rete um die Möglichkeit, WMEs direkt zu ändern, ohne den Umweg des Entfernens und Hinzufügens. Scaffolding ist gedacht für Umgebungen, in denen WMEs häufig gelöscht und wieder hinzugefügt werden. Die Optimierung baut darauf, WMEs als inaktiv zu markieren, anstatt diese zu löschen. Bei Wiedereinfügen des gleichen WME wird der Zustand von inaktiv auf aktiv gesetzt und damit umfangreiche Speicherfunktionen vermieden. Eine ganze Reihe von Verbesserungen adressieren die Problematik der Join- Operationen im Beta-Netz: In Umgebungen mit sehr großen Mengen im Arbeitsspeicher können die Kreuzprodukte der Joins zu teuer werden. Collection Rete adressiert diese Problematik.[1] In den heutigen Anwendungen kommt Rete quasi ausschließlich mit Erweiterungen und Optimierungen zum Einsatz. 5 Rete und LP-Engine in Jena Jena ist ein Open Source Java-Framework, um Applikationen für das Semantic Web zu entwerfen. Es bietet Unterstützung für folgende Techniken: Das Ressource Description Framework (RDF) wurde zunächst als Metadaten- Model entworfen und wird heute auch als allgemeine Umgebung benutzt, um Informationen und Ressourcen für das WWW zu beschreiben. Es ist eine Empfehlung des W3C 4. Die genaue Definition was unter einer Ressource zu verstehen ist, und was damit die Grundlage bildet, was durch RDF beschrieben wird, ist in RFC 2396 definiert: A resource can be anything that has identity. Familiar examples include an electronic document, an image, 4 World Wide Web Consortium

48 44 T. Eisenbarth a service (e.g., today s weather report for Los Angeles ), and a collection of other resources. Not all resources are network retrievable ; e.g., human beings, corporations, and bound books in a library can also be considered resources Diese Ressourcen werden durch Tripel der Form Subjekt-Prädikat- Objekt beschrieben. Das Subjekt ist dabei durch die Ressource festgelegt, das Prädikat und Objekt beschreiben dieses. Ein Beispiel: Der Himmel hat die Farbe blau. Das Subjekt ist Der Himmel, Prädikat ist hat die Farbe und das Objekt ist blau. Ressource Description Framework Schema (RDFS) ist eine erweiterbare Sprache, die grundlegende Elemente für die Beschreibung von Ontologien als Vokabular bietet. RDFS definiert das Vokabular für eine bestimmte Domäne und ist ebenfalls eine Empfehlung des W3C. OWL ist eine Sammlung von Spezifikationen des W3C, um Ontologien durch eine formale Beschreibungssprache zu erstellen, um die automatisierte Verarbeitung der Daten möglich zu machen. OWL soll diese maschinelle Bearbeitung besser unterstützen als XML, RDF, und RDFS.[2] OWL setzt sich aus drei Unterklassen von Sprachen zusammen: OWL lite, OWL DL, and OWL Full 5 SPARQL ist eine RDF-Abfragesprache und ist rekursiv definiert als SPARQL Protocol and RDF Query Language. SPARQL wurde am nach einem langen Prozess vom W3C standardisiert. Tim Berners-Lee, Direktor des W3C, sagte zur Veröffentlichung des Standards: Trying to use the Semantic Web without SPARQL is like trying to use a relational database without SQL. Damit ist die Bedeutung sowie die Einordnung in die Zusammenhänge des Semantic Web als Abfragesprache klar. Das Projekt dppedia.org versucht die Inhalte von Wikipedia so zu strukturieren, dass sie mittels SPARQL abgefragt werden können. Derzeit sind Informationen zu Personen, Orten, Musikalben und Filmen erfasst. Eine in SPARQL formulierte Anfrage an diese Datenbank sieht beispielsweise so aus: 6 Listing 3.6. Anfrage an dbpedia.org 1 PREFIX owl : <http :// www. w3. org /2002/07/ owl #> 2 PREFIX xsd : <http :// www. w3. org /2001/ XMLSchema #> 3 PREFIX rdfs : <http :// www. w3. org /2000/01/ rdf - schema #> 4 PREFIX rdf : <http :// www. w3. org /1999/02/22 - rdf - syntax - ns#> 5 PREFIX foaf : <http :// xmlns. com / foaf /0.1/ > 6 PREFIX dc: <http :// purl. org / dc/ elements /1.1/ > 7 PREFIX : <http :// dbpedia. org / resource /> 8 PREFIX dbpedia2 : <http :// dbpedia. org / property /> 9 PREFIX dbpedia : <http :// dbpedia. org /> 10 PREFIX skos : <http :// www. w3. org /2004/02/ skos / core #> SELECT? name? birth? description? person WHERE { 13? person dbpedia2 : birthplace <http :// dbpedia. org / resource / Berlin >. 14? person skos : subject 15 <http :// dbpedia. org / resource / Category : German_musicians >. 16? person dbpedia2 : birth? birth. 17? person foaf : name? name. 5 Eine ausführliche formelle Beschreibung findet sich in [11] 6 Die Anfrage ist ein Beispiel des Projekts, zu finden unter OnlineAccess?v=8hr

49 Reasoning: Rete (und Jena) 45 18? person rdfs : comment? description. 19 FILTER ( LANG (? description ) = 'de '). 20 } 21 ORDER BY? name Die einzelnen Bestandteile der Anfrage haben folgende Bedeutung: PREFIX definiert Verkürzungen, damit der eigentliche Query übersichtlicher bleibt. owl steht hier beispielsweise abgekürzt für die URL Variablen werden durch ein vorangestelltes Fragezeichen definiert. Das Ergebnis soll in diesem Beispiel also Name, Geburtsdatum, Beschreibung und Person zurückgeben. Mittels birthplace und subject werden die Bedingungen zur Abfrage definiert: Ich möchte hier also alle Musiker, die in Berlin geboren wurden als Ergebnis bekommen. Durch den definierten FILTER werden nur diejenigen Resultate zurückgegeben, die in deutscher Sprache vorliegen. Falls der Filter nicht gesetzt ist, werden auch Ergebnisse in allen anderen Sprachen zurückgegeben, die in der dbpedia hinterlegt sind. Jena wurde von den HP Labs entwickelt und enthält ein Subsystem für Reasoner. Die Einordnung ist in Abbildung 5 zu sehen. In dieses Subsystem können Komponenten als Module integriert werden, um zusätzliche Fakten aus einer Basis zu generieren. Rete ist eine derartige spezielle Reasoner-Implementierung. Abbildung 5. Aufbau der Inferenz-Komponente von Jena.[13] 5.1 Jena und Rete Jena enthält einen allgemeinen Reasoner, der für OWL- und RDFS-Reasoning geeignet ist. Der Reasoner unterstützt die Bildung von Schlussfolgerungen, Forward- und Backward-Chaining und ein hybrides Verfahren, das in Abbildung 6 veranschaulicht ist. Das Forward-Chaining in Jena ist doppelt implementiert: Eine ältere Version, die nicht auf Rete basiert, kann in speziellen Umgebungen effizienter sein als die Rete-Version. Die Grundlage der zweiten Implementierung bildet der Rete- Algorithmus.

50 46 T. Eisenbarth 5.2 OWL-Reasoning in Jena Wie wir in der Einfüehrung zu diesem Kapitel beschrieben haben unterstützt Jena OWL-Reasoning. Genauer bezieht sich die Unterstützung auf OWL/lite. Jena liefert dazu drei verschiedene Konfigurationen aus: Eine Standard-Konfiguration und zwei kleinere, auf Performance optimierte Versionen. Allerdings ist keine davon vollständig, was den Funktionsumfang betrifft. Es können jedoch externe Reasoner wie Pellet, Racer or FaCT über den DIG-Standard eingebunden werden. 7 Diese bieten mitunter eine umfangreichere Unterstützung der OWL-Spezifikation. Eine Einschränkung der OWL-Unterstützung in Jena basiert auf dem grundlegenden Aufbau der Reasoner in Jena. Die Reasoner sind als instanzbasierte Systeme umgesetzt: Sie verwenden Regeln um die if- und only-if - OWL- Konstrukte auf die Daten zu verbreiten. Reasoning auf Klassen bedeutet in der Regel Klassenhierachien zu erkennen und auswerten zu können. Da Jena diese Anfragen indirekt löst, nämlich indem zwei prototypische Instanzen der beiden Klassen erstellt und ausgewertet werden, ist der von Jena gewählte Ansatz weniger mächtig als dies von DL-Systemen her bekannt ist. Es werden daher die Konstrukte complementof und oneof nicht unterstützt. Beide werden für die Bildung komplexer Klassen benutzt. Jena ist daher eher für einfache, normale Ontologien geeignet.[13] Die auf Performance optimierte Konfigurationen des OWL-Reasoners unterstützen die OWL-Konstrukte mincardinality und somevaluesfrom nicht. Ersteres prüft auf eine bestimmte untere Grenze der Kardinalität. Ein Beispiel veranschaulicht dies: Listing 3.7. owl:mincardinality 1 <owl : Class rdf : ID=" Vintage "> 2 <rdfs : subclassof > 3 <owl : Restriction > 4 <owl : onproperty rdf : resource ="# hasvintageyear "/ > 5 <owl : cardinality 6 rdf : datatype ="& xsd ; nonnegativeinteger " >1</ owl : cardinality > 7 </ owl : Restriction > 8 </ rdfs : subclassof > 9 </ owl : Class > 7 DIG ist ein standardisiertes XML-Format, um Description Logic zu formulieren: Abbildung 6. Ablauf des Hybrid-Reasoners in Jena.

51 Reasoning: Rete (und Jena) 47 Die Restriktion legt fest, dass jeder Wein mindestens einen Jahrgang haben muss. Das OWL-Konstrukt somevaluesfrom dient ebenfalls der Festlegung von Restriktionen: Listing 3.8. owl:somevaluesfrom 1 <owl : Class rdf : ID =" Wine "> 2 <rdfs : subclassof rdf : resource ="& food ; PotableLiquid " /> 3 <rdfs : subclassof > 4 <owl : Restriction > 5 <owl : onproperty rdf : resource ="# hasmaker " /> 6 <owl : somevaluesfrom rdf : resource ="# Winery " /> 7 </ owl : Restriction > 8 </ rdfs : subclassof > </ owl : Class > Zumindest eines der hasmaker -Eigenschaften muss im vorgenannten Beispiel auf eine Winery verweisen. Die kleinste Konfiguration des Reasoners wird OWLMicro genannt. Diese Konfiguration kommt dem Funktionsumfang von RFDS gleich, mit einigen hinzugefügten Axiomen: intersectionof unionof hasvalue OWLMicro erreicht die beschriebene hohe Performance durch das Auslassen der beschriebenen Kardinalitätsbeschränkungen und Gleichheitsaxiome, und wägt damit Performance gegen Funktionsumfang zugunsten ersterem ab.[13] 5.3 Tabling in Jena Die Backward-Chaining-Engine in Jena unterstützt Tabling, was von der Funktion an die State-Saving-Optimierung in Rete erinnert: Wenn ein Ziel in das Tabling aufgenommen wird, werden alle bis dahin berechneten Treffer auf dieses Ziel gespeichert. Diese Art Cache wird bei künftigen Abfragen benutzt, was zu Performance-Verbesserungen führt. In Jena können alle oder einzelne Ziele einer Abfrage in diesen Cache eingefügt werden. Die Einträge im Cache leben unendlich lange; es gibt keinerlei automatisierte Strategien zum Entfernen von Objekten. Eine reset-methode ermöglicht es, den Zwischenspeicher zu leeren. Bei Hinzufügen oder Entfernen von Statements wird reset automatisch aufgerufen und der Speicher damit geleert. Sofern diese Änderung der Statements nicht oder nicht häufig genug vorkommt, um die Speicherauslastung in Grenzen zu halten, muss manuell abgewägt werden, wann der Cache geleert wird. Zusammengefasst lässt sicht feststellen, dass Jena ein weit entwickeltes Framework für ein breites Aufgabenspektrum im Semantic Web ist. Es vereint diverse Funktionen wie Forward- und Backward-Chaining und bietet dank seiner flexiblen Architektur viele Schnittstellen und Möglichkeiten zur Erweiterung.

52 48 T. Eisenbarth 6 Zusammenfassung Wie am Anfang der Arbeit angedeutet, findet Rete heute in vielen Anwendungen Einsatz: Zum Beispiel auch JBoss Rules, ein Open Source Produktionssystem, das auf Geschäftsprozesse und -anwendung ausgerichtet ist, und von Red Hat vertrieben wird. Rules verwendet eine abgewandelte Version von Rete mit dem Namen ReteOO, angelehnt an die objektorientierte Optimierung. Ein Blick in die Regelsprache von JBoss Rules lässt einen eindrucksvollen Schluss auf die Nähe zum originalen Rete-Algorithmus zu: Listing 3.9. Regeln aus JBoss Rules 1 import rules. Good ; 2 import rules. Participant ; 3 import rules. Negotiation ; 4 5 rule " Validity -1" 6 when 7 Good (\ $good : name ) 8 Participant ( participantname == " Susan ", 9 goodname == \ $good ) 10 then 11 System. out. println (" Participant is interested in good :" 12 +\ $good ); 13 end Charles Forgy hat mit seiner Arbeit am Rete-Algorithmus einen wichtigen Grundstein für den heutigen Einsatz in Reasoning- und Pattern-Matching- Systemen und damit für das Semantic Web geschaffen. Die intensive Diskussion seiner Grundlagen in den Folgejahren haben weitere Verbesserungen nach sich gezogen und Rete im Laufe der Zeit zu einem funktionsreichen und hoch optimierten Suchverfahren ausgebaut. Neben dem praktischen Einsatz in vielen Systemen ist Rete selbst nach über 20 Jahren nach den ersten wissenschaftlichen Veröffentlichungen immer noch ein direktes Forschungsthema, was die Tragweite der Forschung von Forgy unterstreicht.[10, 17] Literatur [1] A. Acharya and M. Tambe. Collection oriented match. In CIKM 93: Proceedings of the second international conference on Information and knowledge management, pages , New York, NY, USA, ACM. [2] A. Deborah L. McGuinness (Knowledge Systems Laboratory, Stanford University) Frank van Harmelen (Vrije Universiteit. Owl web ontology language overview, abgerufen am [3] R. B. Doorenbos. Production matching for large learning systems. PhD thesis, Pittsburgh, PA, USA, [4] D. J. R. Engine. Temporal rules. abgerufen am [5] C. L. Forgy. On the efficient implementation of production systems. PhD thesis, Pittsburgh, PA, USA, [6] C. L. Forgy and S. J. Shepard. Rete: a fast match algorithm. AI Expert, 2(1):34 40, 1987.

53 Reasoning: Rete (und Jena) 49 [7] A. Giurca. Some facts about the jboss rule engine, abgerufen am [8] A. Gupta, C. Forgy, A. Newell, and R. Wedig. Parallel algorithms and architectures for rule-based systems. In ISCA 86: Proceedings of the 13th annual international symposium on Computer architecture, pages 28 37, Los Alamitos, CA, USA, IEEE Computer Society Press. [9] G. Ingargiola. Cis587:the rete algorith. ingargio/- cis587/readings/rete.html, abgerufen am [10] Z. M. K. Mastura Hanafiah. Using rule-based technique in developing the tool for finding suitable software methodology. Annals of Dentistry (ISSN ), 20, No 2, [11] F. U. A. Mike Dean, BBN Technologies Guus Schreiber. Owl web ontology language reference, abgerufen am [12] I. Red Hat. Jboss rules, abgerufen am [13] D. Reynolds. Jena 2 inference support, abgerufen am [14] B. Schneier. The rete matching algorithm, abgerufen am [15] D. Selmann. Ilog brms blog, abgerufen am [16] I. The Haley Enterprise, abgerufen am , Registrierung notwendig. [17] K. Walzer, A. Schill, and A. Löser. Temporal constraints for rule-based event processing. In PIKM 07: Proceedings of the ACM first Ph.D. workshop in CIKM, pages , New York, NY, USA, ACM. [18] B. Wilson. The ai dictionary, billw/aidict.html, abgerufen am

54 Reasoning auf Datalog-Basis (KAON2) Stephanie Siekmann Universität Augsburg Zusammenfassung Viele moderne Inferenzsysteme sind auf das Reasoning über großen TBoxen optimiert. Jedoch gibt es viele Anwendungen, darunter auch das Datenmanagement im Semantic Web, die nicht hauptsächlich auf der Überprüfung der Erfüllbarkeit von Konzepten beruhen, sondern auf der Anfragebearbeitung, also der Instanzüberprüfung in großen ABoxen. In dieser Arbeit wird ein Reasoningalgorithmus vorgestellt, der sich dieser Problematik annimmt. Eine SHIQ(D) Wissensbasis wird über fünf Transformationsschritte auf ein disjunktes Datalog Programm reduziert. Durch diese Transformation ist es möglich, Techniken zur Optimierung der Anfragebearbeitung aus der Datenbankentwicklung auf das Reasoningproblem zu übertragen und so die Performance, gerade gegenüber den Tableaux-basierten Konkurrenten, zu verbessern. 1 Einleitung Im World Wide Web können Fakten zwischen unterschiedlichen Anwendungen ausgetauscht und in lesbarer Form aufbereitet werden. Mit dem Aufkommen der Web Services wurde dieser Umgang mit Information schon wesentlich erleichtert, jedoch blieben es weiterhin pure Fakten ohne inhärente Bedeutung. Die Grundidee des Semantic Web ist es, die Fakten mit ihrer Bedeutung zu assoziieren. Hierfür müssen die im Web enthaltene Informationen so formalisiert werden, dass sie algorithmisch verarbeitet werden können, sie sind also in einer maschinenlesbaren Form festzuhalten. Um dieses Wissen letztendlich auch sinnvoll nutzen zu können, ist das Reasoning eine unverzichtbare Grundlage des Semantic Web. Reasoning bezeichnet das Ziehen von vernünftigen, nachvollziehbaren Schlüssen aus vorhandenem Wissen. Es simuliert im wesentlichen den gesunden Menschenverstand, also das Verstehen und Nutzen der Bedeutung von Fakten. [14] Diese Seminararbeit beschreibt eingangs die Grundlagen der Wissensrepräsentation im Semantic Web und zeigt dann die Aufgaben und Bedeutung des Reasonings auf. Im Hauptteil wird das Resolutions-basierte Reasoningsystem KAON2 detailliert vorgestellt. Nach einem Einblick in die Historie und die technische Architektur des Systems werden die einzelnen Transformationsschritte des Reduktionsalgorithmus beschrieben, der eine SHIQ Wissensbasis in ein disjuntives Datalog Programm übersetzt. Im Anschluss daran wird näher auf die möglichen Techniken zur Optimierung der Anfragebearbeitung auf einer solchen Datenbank eingegangen. Eine Performanceuntersuchung des KAON Algorithmus

55 Reasoning auf Datalog-Basis (KAON2) 51 schliesst die Arbeit ab. Im Folgenden wird vorausgesetzt, dass der Leser mit den Grundlagen von Ontologien in der Informatik, sowie den Sprachen des Semantic Web, wie RDF, vertraut ist. 2 Grundlagen des Reasoning 2.1 Wissensrepräsentation im Semantic Web Die Hauptaufgabe (vgl ) eines Reasoningsystems, auch Inferenzsystem genannt, besteht darin, neues Wissen aus Vorhandenem abzuleiten. Dieser Vorgang wird auch als Schlussfolgern bezeichnet. Aus einer Anzahl von Fakten, den Prämissen, wird ein neues Faktum, die Konklusion, abgeleitet. Um das Schlussfolgern im Semantic Web zu realisieren muss zunächst das vorhandene Wissen durch sogenannte Wissensrepräsentationssprachen maschinenlesbar formalisiert werden. Reales Wissen wird also in ein formales Modell überführt, das sogenannte Domänenmodell. [3] Ein Inferenzsystem verwendet Inferenzregeln zum Ableiten neuen Wissens. Diese Regeln sind Bestandteil eines sogenannten Kalküls, welches die zugrundeliegenden Möglichkeiten zur Manipulation von Formeln genau beschreibt. Die Möglichkeiten eines Inferenzmechanismus hängen stark von der Mächtigkeit der Repräsentationssprache ab. Je ausdrucksstärker die sprachlichen Konstrukte sind, desto aufwändiger ist das Schlussfolgern. Eine wichtige Rolle spielt in diesem Zusammenhang der Begriff der Entscheidbarkeit 1. Das Entscheidbarkeitsproblem einer Logik tritt in zwei Formen auf. Zum einen als Gültigkeitsproblem in der Frage ob eine gegebene Formel allgemeingültig ist. Zum anderen als Erfüllbarkeitsproblem. Es stellt sich die Frage ob für eine formulierte Semantik überhaupt eine Belegung gefunden werden kann, die korrekt und vollständig ist, so dass das System also nur gültige Schlüsse zieht, und für jede Aussage in endlicher Zeit feststellen kann, ob sie richtig oder falsch ist. Im Folgenden wird deutlich werden, dass man bei der Auswahl der Wissensrepräsentationssprache stets den Spagat zwischen einer möglichst ausdrucksstarken Logik und einer noch handhabbaren Komplexität des Inferenzmechanismus bewältigen muss. [14] Prädikatenlogik Die Prädikatenlogik stellt eine Erweiterung der Aussagenlogik dar. Syntaktisch werden Terme mittels Variablen, Konstanten und Funktionssymbolen, sowie den aus der Aussagenlogik üblichen Junktoren (,,,, ) gebildet. Über Relationssymbole stellt man Aussagen über die Beziehung dieser Terme zueinander dar, man formt sog. Atome. Um das volle Potential der Prädikatenlogik auszuschöpfen kann man noch Quantoren (, ) auf Atome anwenden um mit solchen sogenannten Formeln die Eigenschaften ganzer Objektmengen zu beschreiben. Bekannte Kalküle für die Prädikatenlogik sind der Hilbertkalkül, der Baumkalkül 1 Das klassische Entscheidungsproblem wurde zu Beginn dieses Jahrhundert von Hilbert formuliert. Es war Teil seines formalen Programms zur Lösung der Grundlagenprobleme der Mathematik.

56 52 S. Siekmann und der Resolutionskalkül. Mit letzterem kann über einen Widerspruchsbeweis geprüft werden ob eine Formel aus einer Wissensbasis abgeleitet werden kann. Dieses Prinzip wird im Rahmen des KAON2-Reduktionsalgorithmus (vgl. Kapitel 3) große Bedeutung erhalten. Die Prädikatenlogik der 1. Stufe, First Order Logic (FOL), ist in seiner klassichen Form sehr ausdrucksstark und daher nur semi-entscheidbar. Das bedeutet, dass man zwar alle wahren Schlüsse in endlicher Zeit finden kann, der Algorithmus aber nicht zwingend terminiert wenn man einen falschen Schluss widerlegen möchte. Des Weiteren darf die zugrundeliegende Wissensbasis keine Widersprüche enthalten um aus ihr neues Wissen ableiten zu können. [3] Beschreibungslogik Den Kompromiss zwischen der ausdrucksstarken Prädikatenlogik der 1. Stufe und der effizienten Inferenz auf der andere Seite stellt die sog. Beschreibungslogik, engl. description logic (DL), dar. Im Unterschied zur Prädikatenlogik ist sie entscheidbar. Für das Finden aller wahren sowie falschen Schlüsse gibt es also stets ein terminierendes Reasoning-System. DLs erlauben die Spezifikation von Hierarchien unter Verwendung einer eingeschränkten Menge von FOL-Formeln. [1] Abbildung 1. DL-Nomenklatur [2] ALC (Attributive Language incl. Complement) ist die kleinste, aussagenlogisch abgeschlossene Beschreibungslogik. Grundbausteine sind Klassen, auch als Konzepte bezeichnet, Rollen, die Attribute bzw. Beziehungen der Klassen beschreiben

57 Reasoning auf Datalog-Basis (KAON2) 53 und Individuen, also einzelne Instanzen der Klassen. Verfügbare Konstruktoren sind Konjunktion, Disjunktion und Negation (,, ), die Quantoren schränken Rollenbereiche ein (, ). Erweiterungen von ALC erlauben zusätzlich die Kardinalitätenrestriktion von Rollen: N : Kardinalitäten von Rollen ( number restrictions ) Q: Qualifizierte Rollenbeschränkungen F: Beschränkung der Kardinalitäten auf 0, 1 oder beliebig DL Nomenklatur Eine Übersicht über mögliche Erweiterungen von ALC finden sich in Abbildung 1: Durch die Abbildungsfunktion π sind alle ALC-Aussagen in die Prädikatenlogik übersetzbar, wodurch alle semantischen und logischen Konsequenzen nachvollziehbar werden Aufbau der Wissensbasis Franz Baader [1] gibt folgende Defintion für die Wissensbasis einer Beschreibungslogik: Description Logics (DL) is the most recent name for a family of knowledge representation formalisms that represent the knowledge of an application domain (the world) by first defining the relevant concepts of the domain (its terminology), and then using these concepts to specify properties of objects and individuals occuring in the domain (the world description). Abbildung 2. Architektur der Wissensbasis

58 54 S. Siekmann Die Wissensbasis K = (T, A) unterteilt sich in die T-Box und die A-Box, wie in Abbildung 2 zu sehen ist. Die T-Box enthält das terminologische Wissen, also allgemeingültige Aussagen über Klassen und Rollen, die die Struktur der zu modellierenden Domäne beschreiben. Das assertionale Wissen findet sich in der A-Box, deren Axiome Auskunft über die aktuelle Sitation geben, also den Zustand konkreter Instanzen von Klassen beschreiben OWL, die Web Ontology Language Aufgrund verschiedener Ansprüche an Komplexität und Entscheidbarkeit wurden die vom W3C 2 spezifizierten Ontologiesprachen modular entworfen. Auf Basis der Beschreibungslogik entstanden drei Abstufung von OWL, der Web Ontology Language. Abbildung 3. OWL Varianten [12] OWL Lite baut syntaktisch auf der RDFS 3 -Syntax auf, schränkt aber die erlaubte Nutzung und damit die Semantik ein um entscheidbar zu bleiben. Die Ausdruckskraft von OWL Lite entspricht der Beschreibungslogik SHIF(D), einer Abschwächung von SHIQ(D), da nur die Kardinalitäten 0, 1 und beliebig erlaubt sind. Reasoning auf einer OWL Lite Wissensbasis ist in ExpTime 4 möglich. [14] [5] OWL DL erhält die Nutzungseinschränkungen von OWL Lite aufrecht und bietet weitergehende Modellierungskonstrukte. OWL DL bietet eine maximale Auswahl 2 World Wide Web Consortium RDFS steht für Ressource Description Framework Schema (RDF-Schema) und ist eine Auszeichnungssprache die es erlaubt, eine Grammatik sowie Ontologien für RDF-Aussagen festzulegen und RDF um weitere, komplexe Metadaten zu ergänzen. 4 P NP PSpace ExpTime NExpTime

59 Reasoning auf Datalog-Basis (KAON2) 55 an Konstrukten, die noch entscheidbar ist und NExpTime für das Reasoning benötigt. OWL DL entspricht der Beschreibungslogik SHOIQ(D). [14] [5] OWL Full stellt die mächtigste Ausführung von OWL dar. Sämtliche existierenden Sprachkonstrukte werden unterstützt womit die volle RDF-Kompatibilität sichergestellt ist. OWL Full ist nicht entscheidbar und auch nicht in die Prädikatenlogik übersetzbar. [14] [5] Abbildung 4. Komplexitätsvergleich [5] SHIQ Da der KAON2 Algorithmus auf einer Wissensbasis arbeitet, die mittels SHIQ ausgedrückt ist, wird die Syntax und die Semantik dieser Beschreibungslogik an dieser Stelle kurz formal beschrieben. Im Folgenden wird angenommen, dass A, B Konzeptnamen, a, b Namen von Instanzen und R, S abstrakte Rollen sind. Eine SHIQ Wissensbasis, kurz SHIQ(KB), besteht aus drei endlichen Sets aus Axiomen, der RBox, der TBox und der ABox. Der Ausdruck KB bezeichnet die Größe der Wissensbasis. [8] [9] Eine SHIQ RBox, KB R, kann Axiome der Form S R enthalten, sofern auch Inv(R) Inv(S) 5 vorkommen. Ebenso können Transitivitätsaxiome T rans(r) in der RBox stehen, wenn diese auch T rans(inv(r)) enthält. Man bezeichnet eine Rolle R als einfach, wenn von ihr keine transitive Subrolle in KB R vorhanden ist, wenn also formal gilt S R 6 und T rans(s) / KB R. Nichteinfache Rollen werden auch als komplex bezeichnet. [9] Eine SHIQ TBox, KB T, ist eine endliche Menge von Konzeptinklusionsaxiomen der Form C D, wobei C und D Konzeptausdrücke sind, die aus Konzeptnamen mittels bekannter Operatoren (vergleiche Abbildung 5) gebildet werden. [9] Eine SHIQ ABox, KB A, enthält Axiome der Form A(a), A(a), R(a, b), S(a, b), a b und a b, wobei S eine einfache Rolle ist. Zu beachten ist, dass negierte Aussagen über einfache Rollen erlaubt sind. Eine SHIQ(KB) definiert sich also über ein Tripel (KB R,KB T,KB A ). Die Semantik wird durch Übersetzung in die First Order Logic sichtbar. [9] 5 Inv(R) = R 1 also die Inverse von R 6 ist die reflexiv-transitive Ableitung von

60 56 S. Siekmann Abbildung 5. Syntaxvergleich Die Logik SHIQ erhält man aus SHIQ indem man Kardinalitätenrestriktionen bei einfachen Rollen weiter einschränkt: n.s.c und n.s.c Durch Verbot der Transitivitätsaxiome T rans(r) in den RBoxen erhält man die weiter eingeschränkte Logik ALCHIQ, die während des 1. Transformationsschritt3.4.1 im Reduktionsalgorithmus von KAON2 relevant wird. 2.2 Reasoning im Semantic Web Aufgaben der Reasoner Inferenzsysteme unterstützen das Semantic Web sowohl beim Designen von Ontologien als auch bei der Wissensgewinnung, indem sie implizites Wissen explizit machen. Inferenz wird mittels Subsumption, Klassifikation und Konsistenzüberprüfung realisiert. [3] Bei der Subsumption stellt man sich die Frage welches Konzept Subkonzept eines anderen ist. Ein Konzept A subsumiert ein Konzept B wenn B Teilmenge von A ist. Das bedeutet, dass B spezieller ist als A. Mit diesem Wissen ist eine Einordnung neuer Konzepte in eine sogenannte Subsumptionshierarchie möglich. Die Klassifikation übernimmt die Eingliederung von neuen Konzepten in eine bestehende Ontologie. Man bestimmt für eine Instanz, zu welchem Konzept sie gehört. Klassifikation kann durch Subsumption realisiert werden Anforderungen an die Reasoner Zur Erfüllung oben genannter Aufgaben werden an die Reasoner besondere Anforderungen gestellt:

61 Reasoning auf Datalog-Basis (KAON2) 57 Korrektheit: Gültigkeit aller vom Reasoner abgeleiteten Aussagen Vollständigkeit: Finden sämtlicher Konzepte, im Rahmen der Klassifikation, zu denen eine Instanz zugeordnet ist Entscheidbarkeit: Entscheidung über die Gültigkeit einer Aussage in endlicher Zeit Effizienz: Möglichst effiziente Bearbeitung einer Anfrage Weitere spezielle Anforderungen lassen sich aufgrund der Eigenschaften des Semantic Web ableiten [3]: Skalierbarkeit: Das Semantic Web wächst ständig an. Reasoner müssen auch mit einer sich rasant vergrößernden Wissensbasis umgehen können. Adaptive Performance: Reasoner müssen mit der hohen Dynamik des Semantic Web umgehen können. Neues Wissen kommt hinzu, anderes verschwindet wieder, das Semantic Web ändert sich permanent. Robustheit: Inkonsistenzen wie widersprüchliche Formeln, Ausnahmen oder semantische broken links kommen im WWW sehr häufig vor. Diese dürfen die Funktionsfähigkeit des Inferenzsystems nicht beeinträchtigen. Integration verteilten Wissens: Ontologien können eine Vielzahl weiterer Ontologien, die im gesamten Semantic Web verteilt sind, einbinden. Wissen muss durch die Reasoner also homogen und konsistent über verschiedene Standards integriert werden können. Verständlichkeit: Da das Semantic Web vor allem normale Nutzer ansprechen soll, ist es entscheident, dass Reasoner einfach und intuitiv bedienbar bleiben. Viele dieser Anforderungen konkurrieren miteinander, man muss also zwischen ihnen abwägen. 3 KAON2 3.1 Historie Die Bezeichnung KAON steht für KArlsruhe ONtology and Semantic Web Tool Suite. Dieses Projekt wurde seit Beginn 2001 an dem Forschungszentrum für Informatik (FZI) Karlsruhe und dem Institut für angewandte Informatik und formale Beschreibungsverfahren (AIFB) der Universität Karlsruhe entwickelt. Die erste Version erschien im Jahr 2002 und wurde als Open-Source Infrastructure Tool Suite zur Erstellung und Verwaltung von Ontologien veröffentlicht. Auf Basis dieses Systems wird nun seit 2005 der Nachfolger KAON2 entwickelt. Dem bisherigen Entwickler- und Forschungsteam hat sich die Information Management Group (IMG) der Universität von Manchester angeschlossen, zudem wird das Projekt teilweise durch die EU 7 finanziert. Im Gegensatz zur KAON Toolsuite ist KAON2 keine Open Source Software mehr, sondern wird durch die Karlsruher Firma Ontoprise GmbH vertrieben. Eine Nutzung für Forschung und Lehre ist allerdings weiterhin kostenlos möglich. Im Gegensatz zu KAON, das als Ontologiesprache RDF(S) verwendet, basiert KAON2 auf OWL-DL. Die beiden Systeme sind also nicht kompatibel. [12] 7 EU IST Project DIP 50483

62 58 S. Siekmann 3.2 Architektur Abbildung 6. KAON2 Architektur [16] KAON2 ist ein DL-Reasoner, der SHIQ Wissensbasen bearbeiten kann. Das System unterstützt Aufgaben wie die Berechnung der Entscheidbarkeit einer Wissensbasis, die Erfüllbarkeit von Konzepten, die Berechnung der Subsumptionshierarchie und die Bearbeitung von Anfragen, dem sogennanten Query Answering. Abbildung 6 beschreibt den technischen Aufbau der KAON2 Architektur. Die Ontology API stellt Dienste zur Manipulation der Ontologie, wie das Hinzufügen von Axiomen, zur Verfügung. OWL und SWRL 8 werden syntaktisch vollständig unterstützt. Definiert von der Description Logic Implementation Group stellt das DIG Interface ein, von der Programmiersprache des Anwenders unabhängiges Interface dar. Es beinhaltet ein XML Schema für Beschreibungssprachen sowie HTTP als Transferprotokoll. Die Resoning API ermöglicht das Ausführen mehrerer Reasoning-Tasks. Die zentrale Komponente von KAON2 ist die Reasoning Engine welche auf dem Algorithmus zur Reduktion einer SHIQ Wissensbasis zu einem disjunkten Datalog Programm basiert. Eine detaillierte Beschreibung zu den technischen Aufgaben der einzelnen Subkomponenten finden sich in den Ausführung zu den entsprechenden Transformationsschritten in Abschnitt 3.4. Die Ontology Clausification Komponente übernimmt die Übersetzung der TBox einer SHIQ(KB) in ein Set von FOL-Klauseln (Schritt II). Das Basic Superposition Kalkül zur Saturierung dieser Klauseln ist im Theorem Prover implementiert (Schritt III). Auch die Elimination der Funktionssymbole (Schritt IV) und die Übersetzung der Klauseln in disjunkte Regeln (Schritt V) findet hier statt. Die eigentliche Anfragebearbeitung auf der disjunkten Datenbank findet in der Disjunctive Datalog Engine statt. [16] [15] 8 Semantic Web Rule Language

63 Reasoning auf Datalog-Basis (KAON2) Inferenzmechanismus Abbildung 7. KAON2 Inferenzmechanismus [11] Obwohl die Anfragebearbeitung auf A-Boxen im Semantic Web einen enorm hohen Stellenwert einnehmen arbeiten viele existierende Inferenzsysteme auf ihnen sehr ineffizient. [7] Für die Praxis ist das ABox-Reasoning, also die Instanzgenerierung, weit wichtiger als das TBox-Reasoning. Resolutionsbasierte Verfahren eignen sich erfahrungsgemäß hervorragend für die Generierung neuer Instanzen. [11] Das Hauptproblem ist, dass ein Reasoner in der Regel jede mögliche Antwort (a 1... a n ) auf eine Anfrage betrachten muss und zudem für jede Aussage zu überprüfen hat, ob die Negation Q(a 1... a n ) zu einem Widerspruch führt. Dies is offensichtlich sehr ineffizient. Naive Versuche solche Resolutionsbeweiser für First Order Logiken anzuwenden schlagen fehl. Grund ist, dass die Transformation der gegebenen Wissensbasis in FOL-Klauseln Existenzquantoren erzeugt, die in Funktionssymbolen skolemisiert werden müssen. Die Terminierung eines solchen Algorithmus ist nicht erzwingbar. [4] KAON2 behilft sich der Annahme, dass eine endliche Menge neuer, durch Existenzquantoren erzeugter, Individuen für das Ziehen aller relevanten Konsequenzen ausreicht. Zunächst wird nur die TBox behandelt. Eine endliche Menge logischer Konsequenzen wird aus der Wissensbasis abgeleitet und in ein disjunktes Datalog Programm transformiert. Konkret wird der Inhalt der TBox mittels des KAON2 Reduktionsalgorithmus in funktionsfreie Klauseln transformiert, die anschliessend in eine disjunkte Datenbank geschrieben werden. Eine detaillierte Beschreibung dieses Vorgangs folgt in Kapitel 3.4. Anschliessend wird die ABox dem disjunktiven Datalog Programm hinzugefügt. Das eigentliche Query-Answering wird in einem Konsistenzcheck umgewandelt und mittels standardisierter Methoden für funktionsfreie Klauseln auf diesem Datalog Programm ausgeführt. [7] Abbildung 7 verdeutlicht diese Zusammenhänge grafisch.

64 60 S. Siekmann 3.4 Transformationsalgorithmus Abbildung 8. KAON2 Transformation [6] In der Welt der deduktiven Datenbanken wurde die optimale Handhabung großer Datenmengen bereits intensiv erforscht. Es existieren effiziente query answering - Algorithmen. Zudem wurde eine Reihe von hochentwickelten Optimierungstechniken wie die join-order optimization (Berücksichtigung von Datensets mit Gemeinsamkeiten) und magic-sets (Ignorieren irrelevanter Elemente) erforscht. Auf diese Techniken wird im Rahmen dieser Arbeit in einem eigenen Kapitel zur Optimierung 3.5 näher eingegangen. Die Idee der KAON Entwickler war es, sich diese Entwicklungen aus dem Datenbankmanagement zu Nutze zu machen. Ziel des KAON2 Verfahrens ist es, die Anfragebearbeitung in OWL durch Wiederverwendung einer disjunktiven Datenbank zu realisieren. Die Wissensbasis eines DL-Systems kann auf eine Datenbank abgebildet werden, da diese dieselbe Grundstruktur beinhalten. Die in einer DL beschriebenen Wissensbasis muss also in eine Datenbank überführt werden, um eine effiziente Abfragebearbeitung durchzuführen. [8] Der Input des KAON2 Transformationsalgorithmus ist eine SHIQ Knowledge Base SHIQ(KB), der Output ein disjunktes Datalog Programm DD(KB). Die Tranformation findet in 5 Schritten statt: Elimination der Transitivitätsaxiome Die Wissensbasis liegt zu diesem Zeitpunkt in SHIQ vor. Wie in Kapitel 2.1 beschrieben, ist diese Logik noch zu ausdrucksstark um damit Berechnung durchführen zu können. Transitive Rollen stellen ein Problem für die Entscheidung über die Erfüllbarkeit

65 Reasoning auf Datalog-Basis (KAON2) 61 einer Wissensbasis dar, da sie in ihrer Klauselform keine sog. covering literals 9 enthalten. Die Terminierung des Algorithmus wird durch sie gefährdet. [4] Man überführt die Wissenbasis SHIQ(KB) im 1. Schritt der Transformation durch das Entfernen der transitiven Rollen in eine vollständige vergleichbare in ALCHIQ Wissensbasis Ω(KB). [8] Im Folgenden steht das Kürzel NNF (C) für die Negations-Normalform eines Konzepts C. 1. Berechnung des sog. concept closure, das kleinstmögliche Set aller relevanten Klauseln. Relevant bedeutet in diesem Zusammenhang, dass alle im Set enthaltenen Klauseln folgende Bedingungen erfüllen: Falls C D KB T, dann NNF ( C D) clos(kb) Falls C D KB T, dann NNF ( C D) clos(kb) und NNF ( D C) clos(kb) Falls C(a) KB A, dann NNF (C) clos(kb) Falls C clos(kb) und D ein Subkonzept von C ist, dann D clos(kb) Falls nr.c clos(kb), dann NNF ( C) clos(kb) Falls R.C clos(kb), S R, und T rans(s) KB R, dann S.C clos(kb) 2. Abgleichen der RBox durch Entfernen aller transitiven Axiome: Ω(KB) R erhält man durch Entfernen aller T rans(r) aus KB R 3. Abgleichen der TBox, indem für jedes Konzept das in clos(kb) enthalten ist ein neues Inklusionsaxiom, das die Transitivität kodiert, eingefügt wird: Ω(KB) T erhält man durch Hinzufügen eines neuen Inklusionsaxioms R.C S.( S.C) für jedes Konzept R.C clos(kb) und Rolle S, für die gilt S R und T rans(s) KB R 4. Bewahren der initialen ABox: Ω(KB) A = KB A Der formale Beweis dafür, dass Ω(KB) vollständig vergleichbar zur ursprünglichen Wissensbasis SHIQ(KB) ist und somit gilt, dass wenn SHIQ(KB) entscheidbar ist dies auch für die Wissensbasis nach der Transformation gilt, findet man bei Hustadt, Motik und Sattler (2006)[15] Überführung in die Klauselnormalform Im zweiten Schritt der Transformation wird die ALCHIQ Wissensbasis in FOL-Klauseln übersetzt. Die erste Idee hierzu wäre eine direkte Klausalisierung mittels des Mappingoperators π, siehe Tabelle 1, und anschliessender Skolemisierung dieser Klauseln. Dieser Ansatz bringt jedoch zwei wesentliche Nachteile mit sich. Zum Einen besteht die Gefahr des exponentiellen Wachstums der Wissensbasis aufgrund verschachtelter und Verknüpfungen. Des Weiteren kann durch das direkte Mapping die syntaktische Struktur der Ausgangsdaten zerstört werden, was es schwierig

66 62 S. Siekmann Übersetzung von Konzepten in FOL Übersetzung von Axiomen in FOL Übersetzung der Wissensbasis in FOL π y(a, X) = A(X) π y(c D, X) = π y(c, X) π y(d, X) π y( C, X) = π y(c, X) π y( R.C, X) = y : R(X, y) π y(c, y) π y( ns.c, X) = y 1,..., y n : S(X, y i π x(c, y i) y i y j π(c D) = x : π y(c, x) π y(d, x) π(r S) = x, y : R(x, y) S(x, y) π(t rans(r)) = x, y, z : R(x, y) R(y, z) R(x, z) π(c(a)) = π y(c, a) π(r(a, b)) = R(a, b) π(a b) = a b für, π(r) = x, y : R(x, y) R (y, x) π(kb) = R N R π(r) α T R A π(α) Tabelle 1. Mapping zu FOL [8] wenn nicht gar unmöglich macht ein Entscheidungsverfahren für die Klauseln zu finden. [4] Um diese Datenexplosion zu verhindern und die Struktur während der Prozedur zu erhalten führt man eine sogenannte strukturelle Transformation durch, auch als Renaming nach Nonnengart und Weidenbach (2001) bekannt. Grob gesagt führt die strukturelle Transformation einen neuen Namen für jede komplexe Unterformel in π(ω(kb)) ein. So ersetzt man z.b. P.A Q.B durch einen einfacheren Ausdruck P.A N 1, N 2 Q.B, N1 1 N 2. Anschliessend führt man auf diesem Datenset eine direkte Klausifikation durch. [6] Ergebnis dieses sogenannten Preprocessing ist ein äquivalentes Klauselset Ξ(KB), dessen enthaltene Klauseln sich in eine der acht folgenden syntaktischen Kategorien, vergleiche Tabelle 2, einordnen lassen. [9] Für einen Term t bezeichnet P (t) eine Disjunktion der Form ( )P 1 (t)... ( )P n (t), und P (F (x)) eine Disjunktion der Form P 1 (f1(x))... P n (f m (x)). Diese Eigenschaft wird man sich im nachfolgenden Transformationsschritt zu Nutze machen Saturieren der Klauseln mittels Basic Superposition Im zentralen Schritt des Algorithmus saturiert man die Klauseln der R- und der T-Box mittels eines Resolutionsbasierten Verfahren nach Bachmair, Nieuwenhuis und Robo (1995), dem sogenannten Basic Superposition Kalküls. Die aus der ursprünglichen Wissensbasis ableitbare Klauseln, die Inferenzen, werden mit Hilfe der Inferenzregeln des Kalküls berechnet. [8] Aus Platzgründen wird auf die Grundlagen der Resolution hier nicht detailliert eingegangen, sie werden im Folgenden als bekannt vorausgesetzt. Das Kalkül benötigt zwei Parameter. Zum Einen eine lexikographische Hierarchie, induziert durch eine Rangordnung > P über allen 9 Literale, die alle Variablen einer Klausel enthalten

67 Reasoning auf Datalog-Basis (KAON2) 63 Klausel-Typen (1) R(x, y) Inv(R)(y, x) (2) R(x, y) S(x, y) (3) P f (x) (R(x), f(x)) (4) P f (x) R(f(x), x)) (5) P 1(x) P 2(f(x)) f i(x) / f i(x) (6) P 1(x) P 2(g(x)) P 3(f(y(x))) t i / t j, wobei t i und t j in der Form f(g(x)) oder x sind. (7) P 1(x) R(x, y i) P 2(y) y i y j (8) R(a, b) P (t) t i / t j, wobei t (i) eine Konstante b oder ein funktionaler Term f i(a) ist. Tabelle 2. ALCHIQ Klausel Typen Funktionen, Konstanten und Prädikaten der Formeln: f > p c > p p > p Der zweite Parameter des Kalküls ist eine Entscheidungsfunktion f, die eigenmächtig ein Set negativer Literale aus jeder Klausel wählt. Die Saturation mittels Basis Superposition ist, wie die Resolution, ein Widerspruchsverfahren. Wird eine Menge von Schlussfolgerungen bis zur Redundanz erfüllt, sind also alle Inferenzen in N redundant, so ist N unentscheidbar wenn, und nur genau dann wenn, sie die leere Schlussfolgerung enthalten. [15] Die 5 Inferenzregeln des Kalküls werden im Folgenden vorgestellt: 1. Positive Superposition (C s t) ρ (D w v) ρ (C D w[t] p v) θ wobei σ = MGU(sρ, wρ ρ ) und θ = ρσ(+nebenbedingungen) Wählen gleicher Terme um sie in anderen Termen zu ersetzten. Entfernen des entsprechenden Äquivalenzaxioms nach der Vereinigung. 2. Negative Superposition (C s t) ρ (D w v) ρ (C D w[t] p v) θ wobei σ = MGU(sρ, wρ ρ ) und θ = ρσ(+nebenbedingungen) Selbes Vorgehen wie bei der positiven Superposition, nur mit ungleichen Axiomen. 3. Relexive Superposition (C s t) ρ (C θ wobei σ = MGU(sρ, tρ) und θ = ρσ(+nebenbedingungen)

68 64 S. Siekmann Äquivalenzprädikate werden mit dem Ergebnis ihrer Vereinigung ersetzt. 4. Equality Factoring (C s t s t ) ρ (C t t s t ) θ wobei σ = MGU(sρ, s ρ) und θ = ρσ(+nebenbedingungen) Eine Menge von Äquivalenzen wird nach Vereinigung der Terme vereinfacht. 5. Geordnete Hyperresolution (C A) ρ (D B) ρ) (C D) θ wobei E i die Form (C i A i ) ρ für 1 i n und N die Form (D B 1... B n ) ρ hat. σ ist die allgemeingültigste Substitution, wie A i θ = B i θ für 1 i n. Das Preprocessing im vorangegangenen Schritt der Transformation hat sichergestellt, dass die übergebenen Klauseln eine wohl-definierte Struktur haben. Eine Fallunterscheidung gibt Aufschluss über die möglichen Formen einer abgeleiteten Klausel C. Diese gehört entweder einer der 8 syntaktischen Kategorien (vergleiche Tabelle 2) an oder ist redundant. Eine Terminierung des Algorithmus ist an dieser Stelle also sichergestellt. Der Beweis mittels Induktion über die Herleitungslänge, sowie kompatible Regeln zur Elimination der Redundanz können bei Hustadt, Motik und Sattler (2004) [15] nachgelesen werden. Die Ergebnismenge der saturierten Klauseln wird als Sat(Γ T R ) bezeichnet und im folgenden, vierten Schritt der Transformation weiterverarbeitet Entfernen der Funktionssymbole Funktionssymbole innerhalb rekursiver Regeln gefährden die Terminierung der Anfragebearbeitung. Daher ersetzt man funktionale Terme f(a), f(x) in diesem Schritt durch frische Konstanten a f, x f und simuliert die Relation ein einem neuen Prädikat S f. Zur selben Zeit werden alle unsicheren, freien Variablen in den Klauseln gebunden. [9] Formal definiert man einen Operator λ, der funktionale Terme eliminiert und unsichere Variablen bindet wie folgt [15]: 1. Für jeden Term der Form f(x) in Klausel C wird eine neue Variable x f, die nicht in C vorkommt, eingeführt. Jedes Vorkommen von f(x) wird mit x f ersetzt. 2. Jeder funktionale Grundterm f(a) wird mit λ(f(a)) ersetzt. 3. Für jede Variable x f die im ersten Schritt eingeführt wurde wird das Literal S f (x, x f ) beigefügt. 4. Falls nach Ausführung der Schritte 1-3 noch Variablen u verbleiben, die in einem positiven Literal, nicht aber in einem negativen vorkommen, so wird

69 Reasoning auf Datalog-Basis (KAON2) 65 das Literal HU(x) hinzugefügt. HU steht für Herbrand Universe 10 und ist ein einfacher Trick unsichere Variablen u zu handhaben. Für jedes solche u wird eine Aussage HU(u) in den Rumpf der jeweiligen Klausel eingefügt. [8] Alle Inferenzschritte des Basic Superposition Kalküls auf dem saturierten Klauselset Ξ(KB) lassen sich auf diese Weise in F F (KB) überführen und umgekehrt, Ξ(KB) und F F (KB) sind also vollständig vergleichbar Transformation in ein disjunktes Datalog Programm Der Output F F (KB) enthält funktionsfreie Klauseln in denen jede Variable innerhalb eines negativen Literals vorkommt. Unter diesen Voraussetzungen kann das Klauselset im letzten Schritt der Transformation sehr einfach in einen disjunktiven Regelsatz umgeschrieben werden, indem man positive Literale in den Kopf der Formel und negative Literale in den Rumpf der Formel verschiebt. [6] Jede Klausel A 1... A n B 1... B n aus F F (KB) wird also nach obigen Regeln in die neue Form umgeschrieben A 1... A n B 1... B n mit n, m 0 und A i, B i Atome über Σ. 3.5 Optimierung Parallel zur Forschung im Bereich der Beschreibungslogiken wurden Techniken zur Optimierung von Anfragebearbeitungen in deduktiven Datenbanken entwickelt. Die Vergleichbarkeit einer Beschreibungslogik wie SHIQ und disjunktivem Datalog ermöglicht die Anwendung bekannter Optimierungstechniken aus der Welt der Datenbanken auf die Reasoning Problematik im Semantic Web. Der KAON2 Reduktionsalgorithmus ermöglicht es, eine SHIQ(KB) in ein disjunktives Datalog Programm umzuschreiben welches dieselben grundlegenden Fakten wie die ursprüngliche Wissensbasis beinhaltet. [15] Auf diese Weise wird ABox Reasoning auf eine Anfragebearbeitung im disjunktiven Datalog reduziert und erlaubt Optimierungstechniken anzuwenden die im Folgendem kurz vorgestellt werden. Join-Order Optimization stellt eine Kernfunktion deduktiver Datenbanken dar. Die Dauer einer Anfragebearbeitung ist stark von der Reihenfolge abhängig, in der die Tabellen bearbeitet werden. Dieses Optimierungsverfahren berechnet eine solche vorteilhafte Reihenfolge, indem Gemeinsamkeiten verschiedener Datensets berücksichtigt werden. [13] 10 nach dem französischen Mathematiker Jacques Herbrand

70 66 S. Siekmann Magic Sets Transformation für disjunktive Datenbanken wurde erstmals 1987 von Beeri und Ramakrishnan vorgestellt. Bei einer zielgerichteten Suche werden nur die relevanten ABox Fakten benötigt. So sorgt die Magic Set Transformation dafür, dass nur die relevanten Daten aus der Datenbank gelesen werden müssen. Die Überlegenheit der Top-Down Anfragebearbeitung, bei der sozusagen die Anfrage die Berechnung leitet, gegenüber dem Bottom-Up Prinzip stellt die Motivation für diese Optimierungstechnik dar. Dabei wird zu jedem berechneten Prädikat ein sogenanntes magisches Prädikat, indem die Menge der relevanten Fakten berechnet wird, hinzugefügt. Die originalen Regeln werden mit magischen Prädikaten angereichert, so dass die Verarbeitung nicht relevanter Daten vermieden wird. Grob gesagt wird die Anfrage also derart modifiziert, dass zunächst ein Set relevanter Fakten während der Anfrageevaluation erzeugt wird, indem dann die eigentliche Bearbeitung stattfindet. [13][15] 3.6 Performanceuntersuchung Reasoning auf Wissensbasen, die durch eine ausdrucksstarke Logik beschrieben werden, stellt ein schwieriges Berechnungsproblem dar. Für das Ableiten einer ALC(KB) mit leerer TBox wird im Worst Case PSpace benötigt, Schlussfolgern aus einer normalen ALC(KB) braucht ExpTime und das Reasoning über SHOIN (KB) NexpTime.[11] Der Worst Case entspricht hier aber nicht dem Average Case und so existieren eine Reihe hochspezialisierter Reasoner die für bestimmte Aufgaben optimiert wurden und dort effiziente Ergebnisse liefern. Diese Performanceuntersuchung beginnt mit der Laufzeitanalyse der einzelnen Transformations-Schritte des Reduktionsalgorithmus. Danach wird das ABoxsowie das TBox-Reasoning im Vergleich zu anderen Reasoningsystemen analysiert. Laufzeit des Reduktionsalgorithmus Die Beweise und Herleitungen zu den im Folgenden aufgelisteten Laufzeiten entnimmt der interessierte Leser bitte den Arbeiten von Hustadt, Motik und Sattler [8],[16],[10]. Der erste Schritt der Transformation, das Entfernen der Transititätsaxiome, findet in polynomialer Zeit zur Größe der Wissensbasis statt. Die darauf folgende struktureller Transformation zur Erzeugung logischer Klauseln ist ebenfalls polynomial. Die Saturation mit Basic Superposition findet in ExpTime statt. Ebenso bedarf die Erzeugung funktionsfreier Klauseln exponentieller Größe in KB. Die Umwandlung der TBox in ein Datalog-Programm benötigt zusammen also ExpTime. Diese Behandlung der TBox muss nur ein einziges Mal durchgeführt werden. Das Datalog Programm kann im Cache gespeichert und für weitere Anfragen wiederverwendet werden. Die eigentliche Anfragebearbeitung, beziehungsweise der Konsistenzcheck auf der Datenbank, ist NP vollständig. Zusammengefasst verhält sich der Algorithmus worst-case optimal. Die Erfüllbarkeit einer SHIQ Wissensbasis mittels KAON2 ist NP vollständig.

71 Reasoning auf Datalog-Basis (KAON2) 67 Die im Folgenden formulierten Aussagen basieren auf Evaluationsergebnissen der KAON2 Entwickler, nachzulesen bei Motik und Sattler [16], [15]. Es sei erwähnt, dass es schwierig, wenn nicht gar unmöglich ist, die einzelnen Reasoning-Algorithmen getrennt von ihrer Implementierung zu untersuchen. Die Implementierungsart dieser komplexen Algorithmen in Kombination mit einer durchdachten Speicherverwaltung, sowie die Wahl der Implementierungssprache wirken sich deutlich auf die Effiziens eines Reasoningsystems aus. ABox Reasoning Bei vielen, auf Beschreibungslogiken ausführbaren, Anwendungen verhält sich die TBox in Größe und Aufbau relativ stabil, vergleichbar zu einem Datenbank-Schema. Die ABox hingegen varriert stark und kann sehr groß werden. Aus dieser Motivation heraus haben die KAON2 Entwickler ein System entworfen, dass auf das Reasoning über großen ABoxen spezialisiert und optimiert ist. In der Theorie weist das KAON2 System bei der Anfragebearbeitung großer ABoxen deutlich bessere Ergebnisse auf als seine tableaux-basierten Konkurrenten auf, da diese in der Regel jedes Element der ABox ungeachtet derer Gemeinsamkeiten und ihrer Relevanz einzeln untersuchen. In der Praxis hat sich jedoch gezeigt, dass gerade diese Optimierungstechniken von Nachteil sein können, sofern sie für eine bestimmte Testumgebung suboptimal eingestellt sind. Auf Ontologien die von Haus aus viele Äquivalenzen beinhalten verschwindet zum Beispiel der positive Effekt der magic set Transformation. Angewandt auf andere Wissensbasen wirkten sich ungünstige Parameter sogar negativ auf die Bearbeitungszeit des Algorithmus aus. In wieder anderen Testumgebungen mit einfachen TBoxen und sehr großen ABoxen zeigte das KAON2 System die erhoffte Leistung und glänzte gerade im Vergleich zu Pellet 11 und RACER 12. Die tableaux-basierten Reasoner zeigten sich von der ansteigenden Datenmenge weitaus mehr beeindruckt als der Inferenzmechanismus der Karlsruher. TBox Reasoning Beim TBox Resoning erreicht der KAON2 Reasoner nicht die Performance tableaux-basierter Systeme. Die Ergebnisse schwanken sehr in Abhängigkeit des Aufbaus der TBox. [16] So hat sich gezeigt, dass KAON2 auf Ontologien mit zwar komplexen aber dennoch sehr kleinen TBoxen gute Ergebnisse liefert. Im Durchschnitt zeichnet sich aber ab, dass der Algorithmus die Robustheit der tableaux-basierten Systeme nicht erreicht. Für die Entwickler ist das nicht sehr überraschend, lag der Fokus bei der Entwicklung doch ganz klar auf dem Reasoning über großen A-Boxen. Desweiteren wurden für tableauxbasierte Systeme in den letzten Jahren eine Vielzahl von Optimierungstechniken entwickelt die genau diese Aufgabenstellung behandeln. Auf resolutions-basierte Systeme, wie KAON2, sind diese Verfahren nicht direkt übertragbar. Die KAON2- Entwickler sehen hier erfolgsversprechendes Forschungspotential um auf lange Sicht mit anderen Systemen gleichziehen zu können r.f.moeller/racer/

72 68 S. Siekmann 4 Schluss Bevor die Vision des Semantic Web nutzbar wird, muss eine kritische Masse verfügbarer Inhalte erreicht werden. Im Rahmen dieser Arbeit wurde deutlich, dass es sehr aufwendig ist maschineninterpretierbare Webinhalte zu erstellen. Die Frage stellt sich, ob man genügend Anwender finden wird, die diesen Mehraufwand nicht scheuen. Des Weiteren ist eine einheitliche Standardisierung erforderlich um parallele Entwicklungen nicht kompatibler Systeme zu verhindern. Dieser Aufgabe nimmt sich das W3C bereits erfolgreich an. Gerade im Bereich der Repräsentations- und Anfragesprachen für semantische Modelle existieren eine Reihe verschiedener Ansätze. Ein solches System ist KAON2, das in dieser Arbeit vorgestellt wurde. Eine beste Lösung für all die verschiedenen Aufgaben des Reasonings ist nicht in Sicht und so handelt es sich nach wie vor um ein hochaktuelles Forschungsgebiet. Richtet man den Blick speziell auf das KAON2 System, so kann man aktuellen Veröffentlichungen [10] entnehmen, dass zur Zeit zwei Themen im Mittelpunkt der Karlsruher Forschung stehen. Zum Einen die Erweiterung des Basic Superposition Kalküls um Simplifikationsregeln, die gefährliche Klauseln entschärfen und zum Anderen der Versuch algebraisches Reasoning direkt in den Resolutionsprozess zu integrieren, wie es beim Tableaux Kalkül (Haarslev, Timmann, Möller) bereits praktiziert wird. Literatur [1] F. Baader, D. Calvanese, D. L. McGuinness, D. Nardi, and P. F. Patel-Schneider, editors. The Description Logic Handbook: Theory, Implementation, and Applications. Cambridge University Press, [2] F. Baader, I. Horrocks, and U. Sattler. Description logics as ontology languages for the semantic web, [3] S. Balzer. Inferenzsysteme für das Semantic Web. Seminar Semantic Web und Inferenzsysteme, Universität Ulm, [4] C. Braun. KAON2 Algorithm - Non-tableau reasoning with description logics. Knowledge Representation and Reasoning for the Semantic Web, Seminar, Uni Karlsruhe, [5] P. Hitzler. Web Ontology Language OWL: Semantik. Vorlesung Intelligente Systeme im World Wide Web, Universität Karlsruhe, [6] U. Hustadt and B. Motik. Description Logics and Disjunctive Datalog The Story so Far. In I. Horrocks, U. Sattler, and F. Wolter, editors, Proc. of the 2005 Int. Workshop on Description Logics (DL 2005), volume 147 of CEUR Workshop Proceedings, Edinburgh, UK, July [7] U. Hustadt, B. Motik, and U. Sattler. Reasoning for Description Logics around SHIQ in a Resolution Framework. Technical Report /04, FZI, Germany, [8] U. Hustadt, B. Motik, and U. Sattler. Reducing SHIQ Description Logic to Disjunctive Datalog Programs. In D. Dubois, C. A. Welty, and M.-A. Williams, editors, Proc. of the 9th Int. Conference on Pronciples of Knowledge Representation and Reasoning (KR 2004), pages , Whistler, Canada, June AAAI Press.

73 Reasoning auf Datalog-Basis (KAON2) 69 [9] U. Hustadt, B. Motik, and U. Sattler. A Decomposition Rule for Decision Procedures by Resolution-based Calculi. In F. Baader and A. Voronkov, editors, Proc. of the 11th Int. Conference on Logic for Programming Artificial Intelligence and Reasoning (LPAR 2004), volume 3452 of LNAI, pages 21 35, Montevideo, Uruguay, March Springer. [10] U. Hustadt, B. Motik, and U. Sattler. Deciding Expressive Description Logics in the Framework of Resolution. Information & Computation, To appear. [11] M. Krötzsch. Practical reasoning with owl and rules. Invited talk at the Semantic Web Technology Showcase 2007, Vienna, Austria, MAY [12] N. Kwekkeboom. Ontologien im Semantic Web am Beispiel der KArlsruhe ONtology and Semantic Web Infrastructure. Seminar Ägenten im Semantic Web, Universität Münster, [13] A. Maedche and B. Motik. Repräsentations- und Anfragesprachen für Ontologien - eine Übersicht. Datenbank-Spektrum, 6:43 53, [14] W. May. Reasoning im und für das Semantic Web. In PGrundlagen von Datenbanken, pages 9 20, [15] B. Motik. Reasoning in Description Logics using Resolution and Deductive Databases. PhD thesis, Univesität Karlsruhe (TH), Karlsruhe, Germany, January [16] B. Motik and U. Sattler. A Comparison of Reasoning Techniques for Querying Large Description Logic ABoxes. In M. Hermann and A. Voronkov, editors, Proc. of the 13th Int. Conference on Logic for Programming Artificial Intelligence and Reasoning (LPAR 2006), volume 4246 of LNCS, pages , Phnom Penh, Cambodia, November Springer.

74 Reasoning mit Tableau (anhand von Pellet) Philipp Kretschmer Universität Augsburg Zusammenfassung Das Semantic Web versucht Probleme, die beim Finden von Informationen im Internet vorhanden sind, zu beseitigen. In Suchmaschinen ist eine riesige Menge an Informationen auffindbar, ob man die gesuchten Informationen in den Suchergebnissen wiederfindet, ist jedoch schwer zu sagen. Selten spiegelt die Trefferliste das gewünschte Resultat wieder. Auf der Suche nach einer Bank für seinen Garten, findet der Benutzer im Suchergebniss sowohl Internetadressen, die sich mit seiner Sitzgelegenheit auseinandersetzen, als auch welche die von einem Geldinstitut stammen. Dies zeigt, dass es hilfreich ist, die Suche mit einem semantischen Hintergrund zu ergänzen. Beschreibungslogiken sind in der Lage komplexes Wissen zu repräsentieren. Das World Wide Web Consortium (W3C) hat zu diesem Zweck die Web Ontology Language (OWL) spezifiziert. Der Tableaualgorithmus kann logische Schlussfolgerungen (Reasoning) aus den in der Wissensbasis (Ontologie) vorhandenen Informationen ziehen. Pellet ist für OWL implemeniert worden, da bereits existierende Reasoner notwendige Funktionen wie Reasoning mit Individuen, XML Schema Datentypen oder conjunctive ABox queriesnnicht unterstützten. 1 Einführung Das Internet hat sich zu einem Medium entwickelt, in dem eine schier unendliche Menge an Informationen publiziert wird. Die Informationen sind so aufbereitet, dass wir Menschen sie interpretieren und verstehen können. Auf der Suche nach einem bestimmten Begriff im Internet zum Beispiel Müller bekommt der Benutzer bei der Suchmaschine Yahoo eine Ergebnismenge mit ungefähr 126 Millionen Ergebnissen zurück. Ein Schulabsolvent auf der Suche nach dem traditionsreichen Beruf des Müllers wird selbst nach einigen Seiten feststellen, dass die ersten Resultate immer noch nicht mit seiner Suche übereinstimmen. Er bekommt lediglich Internetseiten großer und kleinerer Unternehmen oder von Familien mit diesem Namen angezeigt. Das Problem ist, dass Suchmaschinen nur die Zeichenketten der einzelnen Seiten mit komplexen Algorithmen analysieren und mit statistischen Werten aufbereiten können. Im Endeffekt bleibt die Suche aber dennoch Stichwortbasiert und alle Internetseiten, auf denen das Wort Müller vorhanden ist, sind in der Ergebnismenge vorhanden. Für den Benutzer ist es aber sinnvoller, bei der Suche den semantischen Inhalt in den Vordergrund zu holen. So bekommt der

75 Reasoning mit Tableau (anhand von Pellet) 71 Benutzer eine Ergebnismenge mit Firmen, Familien oder dem Handwerksberuf je nach seinem semantischen Wunsch angezeigt. Ziel des Semantic Web ist es darum, Wege und Methoden zu finden, Informationen so zu repräsentieren, dass Maschinen damit in einer Art und Weise umgehen können, die aus menschlicher Sicht nützlich und sinnvoll sind [3]. Beschreibungslogiken sind eine Familie von Sprachen, die Wissen einer Domäne repräsentieren können und es strukturiert und formell abbilden. Logische Formalismen bieten auch die Möglichkeit implizites Wissen aus einer Spezifikation zu generieren und sind außerdem ein Gebiet in dem intensiv geforscht wird. Die Entwickler einer Beschreibungslogik müssen auch darauf achten, dass sie die Sprache nicht zu ausdruckststark werden lassen, da ein effizientes Schlussfolgern erschwert würde. Das W3C standardisierte OWL anhand des Gesichtspunktes, dass für die Praxis ein optimaler Ausgleich zwischen Ausdrucksstärke und Effizienz vorhanden sein muss. Dieser Zielkonflikt ist einer der wichtigsten Forschungsansätze auf dem Gebiet der Beschreibungslogiken. Tableaualgorithmen ermöglichen automatisches Schlussfolgern und sind beliebt, weil sie oft eine optimale Worst-Case Komplexität haben und abgeschlossen sind [1]. Der Algorithmus zeichnet sich auch dadurch aus, dass er leicht an verschiedene Beschreibungslogiken angepasst werden kann. Der erste Tableaualgorithmus wurde von Schmidt-Schauß und Smolka 1991 für die Beschreibungslogik ALC (Kapitel 2.1) entwickelt. Die vom W3C standardisierte Sprache ist OWL, OWL-Full ist unentscheidbar, aber so ausdrucksstark gewählt, um möglichst viel mit implizitem Wissen arbeiten zu können. OWL-DL ist eine abgeschlossene Teilsprache von OWL und wurde entwickelt, dass Anfragen immer mit einem terminierenden Algorithmus beantwortet werden können. OWL DL entspricht der Beschreibungslogik SHOIN(D), die sehr ausdrucksstark und entscheidbar ist [3]. Eine der wenigen hochperfomanten Inferenzmaschinen für OWL ist Pellet. Sie ist die einzige, die zum jetzigen Zeitpunkt, alle OWL DL Konzepte unterstützt. Pellet ist Open Source und wurde entwickelt, weil bereits vorhandene Reasoner zwar durchaus hochperfomant sind, aber einige notwendige Eigenschaften nicht unterstützen. Dazu zählen unter anderem, dass der Reasoner nicht von eindeutigen Bezeichnern aussgehen soll und mit Individuen umgehen können muss. Pellet selbst ist auch hochperfomant, wie ein Vergleich in der Zusammenfassung zeigen wird. Das erste Ziel dieser Arbeit ist es, den Tableaualgorithmus vorzustellen, was in Kapitel 2 abgehandelt wird. Dies geschieht mit der Beschreibungslogik ALC, welche ebenfalls kurz vorgestellt wird (Abschnitt 2.1). Der zweite Hauptpunkt ist die Inferenzmaschine Pellet in Kapitel 3 und die von ihr implementierten Optimierungen in Abschnitt Tableau Dieses Kapitel stellt die Semantik und das automatische Schlussfolgern vor. Die Semantik, welche mit der Beschreibungslogik ALC möglich ist, schauen wir uns

76 72 P. Kretschmer im nächsten Kapitel an. Sie ist ein Teil der Prädikatenlogik erster Stufe und die Logik, mit der wir die Funktionsweise des Tableaualgorithmus zuerst ohne und dann mit dem Blockingverfahren kennenlernen. Ein Beispiel veranschaulicht abschließend das Vorgehen des Algorithmus. 2.1 Beschreibungslogik ALC ALC (Attributive Language with Complements) ist eine einfache Beschreibungslogik, die Teile von OWL DL repräsentieren kann. Ihr einfacher und übersichtlicher Aufbau ist der Grund, weshalb sie als Beispielsprache für die Vorstellung des Tableau gewählt wurde. Als Grundbausteine besitzt sie Klassen, Rollen und Individuen. Ein Ausdruck der Form F ussballprof i(olikahn) bedeutet, dass das Individuum OliKahn in der Klasse Fußballprofi enthalten ist. Hat man noch eine Klasse Verein, sagt uns das, dass durch die Rolle Mitglied der Form M itglied(olikahn, BayernM uenchen) OliKahn ein Mitglied des Vereins BayernMuenchen ist. Unter- und Äquivalenzklassenbeziehungen werden mit den Standardsymbolen und dargestellt. Komplexe Klassen werden durch Konjunktion und Disjunktion und deren Verschachtelung konstruiert. Mit den Quantoren R.C und R.C können auch komplexe Klassen erzeugt werden. Die Übersetzung in Prädikatenlogik sieht beispielhaft wie folgt aus: F ussballprof i V ereinsmitglied (ALC) ( x)(f ussballprof i(x) V ereinsmitglied(x)) (P raedikatenlogik) F ussballprofi P rofifussballer (ALC) ( x)(f ussballprof i(x) P rof if ussballer(x)) (P raedikatenlogik) Eine vollständige Übersetzungstabelle für die Prädikatenlogik erster Stufe ist in [3] zu finden. Die formale Syntax und Semantik kann in TBoxen und ABoxen unterteilt werden. ABoxen haben assertionales Wissen der Form C(a) oder R(a, b), für eine Klasse C und Rolle R und den Individuen a und b. Terminologisches Wissen wird in TBoxen dargestellt, welche die Äquivalenz und Unterklassenbeziehung beinhalten. Die Aussage, dass ein Profifussballer (Pf) eine Teilmenge von Mensch (M) geschnitten Vereinsmitglied (Vm) oder Mensch (M) geschnitten nicht Amateur (Am) ist,

77 Reasoning mit Tableau (anhand von Pellet) 73 wird in ALC und in Prädikatenlogik P f (M V m) (M Am) ( x)(p f(x) (M(x) V m(x)) (M(x) Am(x))) ausgedrückt. Ist logische Konsequenz aus der Aussage, dass der Profifußballer ein Mensch ist? Formell besitzt sie die Form in ALC und in Prädikatenlogik P f M ( (x)(p f(x) M(x)). Der Tableau ist ein Algorithmus für logische Schlussfolgerungen, mit dem wir das überprüfen können. 2.2 Tableauverfahren Logisches Schlussfolgern aus einer Theorie oder Wissensbasis kann nach [3] immer auf einen Nachweis von Unerfüllbarkeit zurückgeführt werden. Durch die enge Verwandschaft mit der Prädikatenlogik, wäre es denkbar, die Aussagen aus der Beschreibungslogik zuerst zu übersetzen und anschließend mit Algorithmen der Prädikatenlogik auf Unerfüllbarkeit zu prüfen. Außer, dass diese Vorgehensweise ineffizient ist, besteht noch das gravierende Problem, dass die Prädikatenlogik erster Stufe nicht entscheidbar ist. Eigens für Beschreibungslogiken entworfene Algorithmen versprechen hier eine bessere Performance Naives Tableauverfahren [5] beschreiben die Idee, dass das Testen auf Unterklassenbeziehungen auf das Testen von Erfüllbarkeit reduziert werden kann. Sie definieren ein Konzept als erfüllbar, wenn es in einer Interpretation eine nicht leere Menge verzeichnet wird, andernfalls ist es unerfüllbar. Die Beweise für Unterklassenbeziehungen und Erfüllbarkeit hängen folgendermaßen zusammen: (C D) (C D) ist unerfuellbar [6] Die Frage aus dem letzten Kapitel, ob der Profifußballer ein Mensch ist, kann man nun beantworten, indem man P f M in die Form (P f M) bringt und mit der vorhandenen Wissensbasis (P f (M V m) (M Am)) interpretiert. Der Algorithmus fängt mit einem einzelnen Individuum an und baut dann nach und nach eine vollständige Interpretation auf. Die Interpretation wird nach den Regeln des Tableaualgorithmus (Tabelle 1) durchgeführt. Wir zeigen, dass mit (P f M) keine vollständig Interpretation möglich ist, wodurch

78 74 P. Kretschmer Unerfüllbarkeit bewiesen ist. Das der Profifußballer ein Mensch ist, folgt sofort aus obiger Beziehung. Der Tableauansatz bietet Vorteile wie eine solide theoretische Basis, optimale Worst Case Effizienz und leichte Anpassbarkeit durch Erweiterung der Regeln [5]. Ein Tableau ist ein Graph, der zu Beginn eine Theorie oder Wissensbasis in Negationsnormalform (NNF) benötigt. NNF wird erreicht indem man alle Negationen mit unter anderem DeMorgan Regeln direkt vor die atomaren Klassen bringt. Dies ist in linearer Zeit für jede in ALC ausgedrückte Wissensbasis möglich [1]. Durch die Reduktion des automatischen Schlussfolgerns auf Unerfüllbarkeit versuchen wir D(a) und D(a), einen Widerspruch, in einer Aussage zu erzeugen. Bevor wir uns die Tableauregeln formell und das Vorgehen im Konkreten ansehen, ein einfaches Beispiel. Die Aussagen P f(a) und ( P f Am)(a) erfordern es, dass P f(a) und P f(a) und Am(a) gelten müssen, damit die Aussage wahr ist. Offensichtlich können die Aussagen P f(a) und P f(a), wie es für Erfüllbarkeit nötig wäre, gleichzeitig nicht wahr sein. Demnach gibt es keine wie in [5] verlangte nicht leere Menge, die eine Interpretation erfüllt. Auch die von [6] geforderte vollständige Interpretation ist durch den Widerspruch nicht möglich. Die Ersetzungregeln des Tableaualgorithmus für ALC sind in Tabelle 1 dargestellt und dem Buch von [3] entnommen. Das Tableau ist vollständig verzweigt, wenn man keine der Ersetzungsregeln mehr anwenden kann. Befindet sich in einem Ast des Tableaus ein Widerspruch, so ist dieser abgeschlossen. Sind alle Äste des Tableaus abgeschlossen, gilt die Wissensbasis, der dem Tableau zugrunde liegt, als unerfüllbar. Kann man keine neuen Elemente zu einem Ast hinzufügen müssen, wir den Algorithmus an dieser Stelle terminieren und die Wissensbasis ist erfüllbar. Grundsätzlich können die Ersetzungsregeln in beliebiger Reihenfolge Auswahl Aktion C(a) W (ABox) Füge C(a) hinzu. R(a, b) W (ABox) Füge R(a, b) hinzu. C W (T Box) Füge C(a) für ein bekanntes Individuum a hinzu. (C D)(a) A Füge A(a) und D(a) hinzu. (C D)(a) A Dupliziere den Ast. Füge zum einen C(a) und zum anderen Ast D(a) hinzu. ( R.C)(a) A Füge R(a, b) und C(b) für ein neues Individuum b hinzu. ( R.C)(a) A Falls R(a, b) A, so füge C(a) hinzu. Tabelle 1. Tableauersetzungsregeln für ALC; A ist die Aussagenmenge; auf die Aussagen in der Wissensbasis angewandt werden. Die Komplexität ist dann exponentiell in Bezug auf die Zeit. Eine Modifikation schafft es aber den

79 Reasoning mit Tableau (anhand von Pellet) 75 Algorithmus in polynomieller Zeit zu behandeln, dazu mehr im Kapitel 2.2.3, Komplexität [1]. Dieser Tableaualgorithmus garantiert wegen der Ersetzungregel ( R.C)(a) A keine Terminierung. Der folgende Abschnitt zeigt, wann ein solches Problem auftritt und wie es gelöst werden kann Tableauverfahren mit Blocking Das Problem, dass der Algorithmus nicht immer Terminiert, kommt durch die Regel ( R.C)(a) A. An dieser Stelle wird verlangt, R(a, b) und C(b) der Menge hinzuzufügen, wobei das Individuum b immer ein Neues sein muss. Abbildung 1 stellt einen solchen Fall dar (Beispiel aus [4]). Man will anhand der Theorie P erson hasp arent.p erson nachweisen, Abbildung 1. Terminierungsproblem dass Bill keine Person ( P erson(bill)) ist. Im ersten Schritt wird die Regel für Disjunktion angewandt und zwei Verzweigungen entstehen. Die linke Seite hat durch P erson(bill) einen Widerspruch und ist abgeschlossen. Die rechte Seite zeigt, wie man durch wiederholtes Anwenden der Regel für das Existenzzeichen in eine Endlosschleife geraten kann. Die neu hinzugefügten Individuen besitzen keine wesentlichen neuen Informationen und sind unnötig. Wir wenden die Regel in Zukunft nur an, wenn der Zweig an dieser Stelle nicht blockiert. Auf diese Weise kann der Algorithmus terminieren. Bleibt noch eine Definition für das Blockieren anzugeben. Müssen wir die Regel für ( R.C)(a) A anwenden, blockiert der Algorithmus an dieser Stelle, falls es ein b gibt, dass {C C(a) A} {C C(b) A}

80 76 P. Kretschmer gilt [3]. Wendet man diese Definition an, blockiert der Algorithmus bei der Wahl von hasp arent.p erson(x 1 ), da x 1 Bill ist. Bill blockt x 1 und der Zweig muss nicht weiter untersucht werden Komplexität Der Tableaualgorithmus für ALC wie er in Kapitel beschrieben ist, besitzt exponentielle Laufzeit und Speicheranforderungen [1]. Ziel eines jeden Algorithmus muss es sein, die Komplexität so gering wie möglich zu halten. In unserem Fall können die bestehenden Regeln unangetastet bleiben, sind jedoch nicht mehr beliebig hintereinander anwendbar. [1] geben eine Reihenfolge für das Anwenden der Regeln vor. Man fängt an mit {C 0 (x 0 )}. 1. wendet so lang wie möglich und an und sucht Widersprüche; 2. danach erzeugt man alle notwendigen Nachfolger von x 0 und wendet die Regel an; 3. Nachfolger werden genauso abgehandelt; Diese einfache Anpassung drückt uns die Speicherkomplexität in einen polynomiellen Rahmen Beispiel In diesem Beipiel schauen wir uns den Tableau mit Blocking an und verwenden für unseren Nachweiß eine Aussage, wie sie in jeder Organisation üblich ist, Chef hatv orgesetzten.chef. Der Vorstellung das ein Chef wieder mindestens einen Chef hat, fügen wir noch die Aussage hinzu, dass Knut ein Eisbaer ist, Eisbaer(Knut). Wir versuchen nachzuweisen, dass Knut kein Chef ist, Chef(Knut). Während der Konstruktion des Tableau verwenden wir Abkürzungen für die Begriffe, sie bestehen nur aus dem ersten Buchstaben des korrespondierenden Wortes. Klassen bekommen einen Großbuchstaben, alles andere Kleinbuchstaben. In die Wissensbasis W werden alle Aussagen in Negationnormalform eingetragen. { C h.c, E(k), C(k)} Initial haben wir in unserem Tableau nur einen leeren Ast A 0, der der leeren Menge entspricht. Im ersten Schritt wählen wir aus W F (k) und erhalten für A 0 die Menge A 1 mit A 1 = {E(k)}. Als nächstes Wählen wir C(k) und die Menge A 2 = {E(k), C(k)} ersetzt A 1. Als neues Element aus der Wissensbasis fehlt in unser Menge noch C h.c. Da es sich hier noch um ein Element der TBox handelt, müssen wir

81 Reasoning mit Tableau (anhand von Pellet) 77 noch ein bekanntes Individuum hinzufügen. Wir wählen den uns bekannten k aus und das Element gehört jetzt zur ABox Menge. A 3 = {E(k), C(k), ( C h.c)(k)} Wir wählen als nächstes ( C h.c)(k) und wenden die Regel für Disjunktion an. Ab jetzt müssen wir zwei Äste A 4,1 und A 4,2 betrachten. A 4,1 = {E(k), C(k), ( C h.c)(k), ( h.c)(k)} A 4,2 = {E(k), C(k), ( C h.c)(k), C(k)} Der Ast A 4,2 ist abgeschlossen, da er C(k) und C(k) enthält. Wenden wir uns jetzt A 4,1 zu, wählen ( h.c)(k) und ersetzen die Menge durch die neue A 5,1. Wie in der Ersetzungsregel vorgesehen, fügen wir die Rollenbeziehung und die Klasse C mit einem neuen Individuum j 1 hinzu. A 5,1 = {E(k), C(k), ( C h.c)(k), ( h.c)(k), h(k, k 1 ), C(k 1 )}. Wir wählen als nächstes C h.c aus W und dazu das bekannte Individuum k 1. Dieses Element fügen wir in A 5,1 ein und erhalten A 6,1 = A 5,1 {( C h.c)(k 1 )}. Nach der Disjunktionsregel müssen wir den Ast A 6,1 wieder teilen und durch A 7,1 = A 6,1 {( h.c)(k 1 )} A 7,2 = A 6,1 { C} ersetzen. An dieser Stelle terminiert der Algorithmus, da C(k) und C(k) ein Widerspruch in A 7,2 ist. Der letzte noch nicht abgeschlossene Ast ist A 7,1. An dieser Verzweigung können wir aber auch nicht weitermachen, denn 1. keine Auswahl aus der Wissensbasis oder A 7,1 bringt ein neues Element ins Tableau 2. bis auf ( h.c)(k 1 ). Dies wird aber durch k geblockt, weil beide in die Klassen C, C h.c und C gehören. Wir haben einen Tableau berechnet, der wegen Ast A 7,1 nicht abgeschlossen ist. Daraus können wir direkt schließen, dass die Aussage Chef(Knut) nicht aus der Wissensbasis { C h.c, E(k), C(k)} gefolgert werden kann. Wir haben gezeigt, dass mit der Wissensbasis es durchaus möglich ist, dass Knut ein Chef ist. 2.3 Implementierung und Optimierungen Die im Folgenden vorgestellten Implementierungs- und Optimierungsverfahren sind ein Teil derer, die Pellet unterstützt. Dazu gehören Lazy Unfolding, Normalization and Simplifikation und Semantic Branching, welche für die Logic SHIN(D) implementiert wurden. SHIN(D) entspricht OWL-Lite. Für OWL-DL, was der Logik SHOIN(D) gleichkommt, sind neue Techniken entworfen worden. Wir schauen uns in dieser Arbeit Learning-based Disjunkt Selection an.

82 78 P. Kretschmer Lazy Unfolding Lazy unfolding ist ähnlich dem Proxy Pattern, welches von [2] als Design Pattern für den Softwareentwurf vorgestellt wurde. Es geht darum, dass ein Proxy-Objekt ein Platzhalter für das komplexere Original ist und an dessen Stelle steht. Es wird erst dann durch das Original ausgetauscht, wenn das Original tatsächlich benötigt wird. Lazy unfolding kann man auf zwei verschiedene Arten anwenden. Die Erste ist wie oben beschrieben, wenn ein Konzept für den Algorithmus gebraucht wird, ersetzt man es durch seine Definition. Sei A D und es wird aus der Menge (A E) ausgewählt, wird an dieser Stelle A durch D ersetzt. Statt D kann A auch durch einen komplexeren Wert definiert werden. Bis jetzt werden unnötige Ersetzungen vermieden, falls schon ein widerspruchsfreier Ast gefunden wurde, oder schon vorher ein Konflikt auftrat. Noch effizienter ist es, wenn man nicht den Wert durch seine Definition austauscht, sondern sie mit in die Menge aufnimmt. Tritt später noch einmal dieses Konzept auf, muss man dieses nicht auch ersetzen, sondern hat es noch in der Menge und kann den Widerspruch ohne Ersetzen testen. Als Ergänzung zu den Tableauregeln kann man Lazy unfolding ausdrücken wie in Abbildung 2 Abbildung 2. Lazy unfolding Regeln Normalisierung Normalisation verstärkt den Gewinn der aus Lazy unfolding gezogen werden kann, noch um ein Vielfaches. Die Idee hinter Normalisation ist, dass Widersprüchliche nicht atomare Aussagen schnell erkannt werden. Hat man alle Konzepte in Negationsnormalform gebracht ( C D) und analog dazu (C D), sind zwei konträre Aussagen vorhanden. Das Problem ist jedoch, dass man erst beide mit den Ersetzungsregeln umformen muss, um das zu erkennen. Mit Hilfe der DeMorgan Regeln bringt man komplexe Aussagen in eine syntaktische Normalform. Wichtig ist nicht, ob man oder verwendet, sondern

83 Reasoning mit Tableau (anhand von Pellet) 79 das es einheitlich gemacht wird. Für das Beispiel aus dem letzten Abschnitt wählen wir und formen ( C D) in (C D) um. Jetzt ist der Widerspruch direkt ersichtlich. Die umgeformten Aussagen liegen aber nicht mehr alle in Negationsnormalform vor. Wichtig ist es noch die Konjunktionen als Mengen {C, D} und {C, D} zu betrachten, damit die Reihenfolge der Elemente keine Rolle spielt. Für die Logik ALC sind die Funktionen für Normalisierung und Vereinfachung in Abbildung 3 zu sehen. An andere ausdrucksstärkere Logiken können wir die Idee durch ergänzen der Funktionen anpassen. Ein Beipsiel dafür ist, die Restriktion auf Zahlen in umzuformen und als Norm zu wählen. Abbildung 3. Normalisierungsfunktionen [6] Wir können Widersprüche noch schneller erkennen, ohne die Ausrücke expandieren zu müssen. Wenn wir {C, D} und {C, D} durch atomare Konzeptnamen ersetzen, {C, D} CD und {C, D} CD, sind die Widersprüche sofort sichtbar. Unsere Ersetzungen müssen wir von denen in der Originalwissensbasis trennen, um den Benutzer nicht zu verwirren und dem System mitzuteilen, dass es sie nicht klassifiziert werden müssen [6]. Diese Methode ist leicht zu implementieren und für sehr viele Logiken anwendbar. Im Anschluss an diese Methode sind viele Tests auf Unerfüllbarkeit nicht mehr notwendig, weil die Widersprüche direkt vorliegen. Die veränderte Darstellungsweise erkennt doppelte Einträge wie (C D) und (D C) in der Aussage und reduziert beide auf eine Aussage {C, D}. Diese Verbesserung führt

84 80 P. Kretschmer allerdings auch zu neuen Kosten und kann daher manchmal auch keinen Nutzen oder sogar eine leichte Verschlechterung der Laufzeit bewirken Semantic Branching Search In Abschnitt haben wir das naive Tableauverfahren kennengelernt. Die vorgestellten Regeln basieren auf einer rein syntaktischen Betrachtung des Problems. Findet man eine Disjunktion vor, muss man den Baum an dieser Stelle aufteilen und beide Seiten weiter verfolgen. Schon an einem kleinen Beispiel wird deutlich, dass unter diesen Umständen der selbe Ausdruck mehrmals untersucht werden muss. Die Menge {(A B), (A C)} dient als Grundlage für den Test auf Unerfüllbarkeit. Wählt man zuerst (A B) aus, zeigt man A und B. Im weiteren ist es noch nötig, A wegen (A C) zu zeigen. Ist A ein komplexer Ausdruck verliert man viel Zeit für einen Beweis, den man schon geführt hat. Man sollte versuchen diese redundanten Test zu vermeiden. Wir erreichen dieses Ziel, indem wir die Disjunktion nicht syntaktisch aufteilen, sondern uns ein Element aus der noch nicht aufgeteilten Disjunktion herausnehmen, und damit den Baum weiter aufspannen [6]. Wir wählen für einen Ast A und für den Anderen A. Beide Äste sind strikt disjunkt und wir führen keine unnötigen Test aus. Anschaulich lässt sich die neue Vorgehensweise so darstellen. Diese Lösung ist durch Abbildung 4. Semantic Branching anpassen des weit verbreiteten Davis-Putnam-Logemann-Loveland Verfahren (DPLL) entstanden und hilft Entscheidbarkeit in Problemen zu optimieren. Durch hinzufügen des negierten Astes sind nur selten stark negative Auswirkungen aufgefallen, dagegen ist das Verbesserungspotenzial enorm groß. Starke Synergieeffekte sind bekannt zusammen mit den Vorgehensweisen Local Simplifikation und Heuristic guided search, die nicht Bestandteil dieser Arbeit sind und in [6] nachgelesen werden können Learning Based Disjunkt Selection Kritisch für die Leistung des Reasoning-Prozesses sind die Disjunktionen. Eine gute Reihenfolge in der die Disjunktionen abgearbeitet werden, bringt einen Leistungsschub für das Schlussfolgern. Für das DPLL Verfahren sind einige Verbesserungen gefunden worden, mit denen der Suchbaum möglichst klein gehalten werden kann [7]. Untersucht man Wissensbasen, kommt man oft zu dem Schluss, dass es an sich nur eine sinnvolle Erweiterung des Tableaus gibt. Der Reasoner kann das

85 Reasoning mit Tableau (anhand von Pellet) 81 Problem aber erst nach einigen Schritten feststellen, was bei teuren Expansionen nicht wünschenswert ist. Um keine Leistung zu verschenken, ist die Idee, dass der Algorithmus aus einer schon berechneten Aussage einer Disjunktion lernt. In [7] wird eine Möglichkeit aufgezeigt, wie man widerspruchsfreie Expansionen für ähnliche Aussagen wiederverwenden kann. Der Pseudocode in Abbildung 5 ist von ihnen vorgestellt worden und basiert auf der Idee, die Aussagen anhand der Anzahl, der durch sie verursachten Widersprüche zu sortieren. Jetzt ist es einfach, Abbildung 5. Pseudocode Learning based disjunkt selektion Technik eine Aussage, die schon einmal einen Widerspruch verursacht hat zu finden. Da es fast unmöglich ist, festzumachen, warum eine Disjunktion erfolgreich expandiert werden konnte, speichert diese Technik nur die Widersprüche ab. Eine Methode die im Nachhinein noch alle widerspruchsfreien Vervollständigungen findet und für den späteren Bedarf bereitstellt, ist aber denkbar [7]. 3 Pellet In Anwendungen des Semantic Web ist es vielmals von großer Bedeutung Schlussfolgerungen ziehen zu können. Diese sollen zudem schnell und vollständig sein. Bevor man mit der Entwicklung von Pellet begann, untersuchte man zuerst schon vorhandene Reasoner heraus, die die Beschreibungslogik von OWL (SHOIN(D)) behandeln konnten. Die bekanntesten davon sind FaCT und Racer. Die Leistung der Reasoner war gut, jedoch sind einige für das Semantic Web notwendige Eigenschaften, wie ABox Reasoning, conjuctive ABOX Queries und Unterstützung von XML Schema Datentypen, nicht vorhanden. Pellet erfüllt diese Anforderungen und bietet eine gute bis sehr gute Leistung an, wobei es der erste Reasoner ist, der ganz OWL-DL verarbeiten kann.

86 82 P. Kretschmer 3.1 Basis Dienste Pellet kann für OWL-DL einen vollständigen Konsistenz- sowie Syntaxtest durchführen. Als OWL-DL Reasoner sollte Pellet die Standardanforderungen für logische Schlussfolgerungen anbieten. Dazu gehören [8]: Konsistenztest, der sicherstellt, dass eine Wissensbasis keine widersprüchlichen Aussagen enthält. Eine ABox wird gegen eine TBox auf Konsistenz geprüft. Konzept Erfüllbarkeit, testet, ob zu einer Klasse Instanzen bestehen können. Wenn nicht, ist durch die Definition einer solchen Instanz die ganze Ontologie unvereinbar. Klassifikation, berechnet Klassenbeziehungen und dadurch eine komplette Klassenhierarchie. Realisation, errechnet die direkten Typen für jedes Individuum. Erst nach der Klassifikation möglich, da die direkten Typen im Bezug auf die Klassenhierarchie beschrieben sind. Da das Internet ein großes verteiltes System ist, hat man über manche Ontologien die man einbinden muss, keine Kontrolle. So kann es leicht passieren, dass sich das Vokabular der anderen Ontologie mit dem Eigenen überschneidet. Für diesen Fall bietet Pellet drei Lösungsmöglichkeiten an: Man kann die verursachende Aussage ignorieren. Man kann beide verwenden, aber unterschiedlich behandeln. Die Behandlung der Ontologie zurückweisen. Anfragen auf Individuuen in den Sprachen SPARQL und RDQL sind Conjunctive ABox Queries. Dieser Typ von Anfragen bietet noch wenig Implementierungerfahrung, da das Hauptaugenmerk bis jetzt auf dem Reasoning mit Klassen lag. Es ist jedoch anzunehmen, dass sich das in Zukunft ändern wird. Kein standard Dienst, der aber für die Praxis von großer Bedeutung ist, ist das Debugging. Es ist wichtig semantische Fehler in der Ontologie aufzuspüren. Typischerweise erkennen Reasoner nur Widersprüche und bieten keine Möglichkeit die Herkunft des Fehlers heraus zu finden. In Pellet gibt es einmal den Ansatz, dass der Fehlerursprung angezeigt wird und zusätzlich die Lösung axiom tracing [8]. Sie extrahiert die relevanten Basisaxiome, die den Widerspruch verursachen. 3.2 Architektur und Design Pellet macht keine eindeutigen Namensannahmen, unterstützt ABox Reasoning und arbeitet mit externen Modulen zusammen, die unter anderem XML Datentypen unterstützen. Beeinflusst wurden diese Funktionalitäten durch die Tatsache, dass Pellet speziell als OWL Reasoner gedacht war. Über Schnittstellen bietet Pellet, dass einen kleinen Kern besitzt, Anschlußmöglichkeiten für Erweiterungen und unterstützt explizit die DIG (DL Implementors Group) Schnittstelle.

87 Reasoning mit Tableau (anhand von Pellet) 83 Der Tableau Reasoner ist das Herzstück der Konsistenztest auf Wissensbasen. In ihn werden nach einem Verifizierungs- und Reparaturschritt die Ontologien geladen. Das Laden folgt für ABoxen direkt in den Reasoner, wohingegen die TBoxen erst einige Standardoptimierungen, wie Normalisierung und Absorption durchlaufen. Von den Hauptkomponenten aus Abbildung 6 schauen wir uns Abbildung 6. Pellet Hauptkomponenten folgende an: Parsen und Laden Tableau Reasoner Datentyp Reasoner Wissensbasis Schnittstelle ABox Query Engine Parsen und Laden Pellet bietet keinen integrierten OWL/RDF Parser, sondern ist in Toolkits integriert, die diese Funktionalität bieten. Pellet implementiert die Schnittstellen, um Queryanfragen in den Toolkits beantworten zu können [8]. Da Toolkits wie Jena oder WonderWeb andere Darstellungsformen für Ontologien haben, bietet Pellet Module an, um diese laden zu können. Über eine HTTP Verbindung werden Reasoner angeschlossen, die über die DIG Schnittstelle interagieren. Tableau Reasoner Die einzige Funktionalität des Tableau Reasoner ist: Eine Ontologie auf Konsistenz zu überprüfen [8]. Die Funktionsweise des Tableau Reasoning haben wir uns in Kapitel angeschaut. Mittels eines Plug-in- Verfahrens können diverse Strategien für den Algorithmus entwickelt werden. Standardmäßig ist SHOIN als Strategie gewählt, um OWL-DL vollständig zu unterstützen.

88 84 P. Kretschmer Datentypen Reasoner Ein Framework von I.Horrocks und U.Sattler von 2001 ist die Basis für Datentypen Reasoning in Pellet. Es geht in diesem Schritt darum, nicht leere Schnittmengen zwischen Datentypen zu finden, die dann als Konsistent bezeichnet werden. Wissensbasis Schnittstelle Alle Reasoning Aufgaben können auf einen Wissensbasis Konsistenztest reduziert werden, wobei man eine geeignete Transformation durchführen muss [8]. Boolsche Anfragen werden mit Hilfe eines Tests auf Unerfüllbarkeit und Anfragen die eine Menge als Antwort benötigen auf mehrere Konsistenztest zurückgeführt. Die Wissensbasisschnittstelle bietet die Funktionalität solche Queries zu beantworten und setzt auf der Annotated Term (ATerm) Bibliothek auf. ABox Query Engine Pellet kann Anfragen in SPARQL und RDQL annehmen und transformiert sie in ein internes Format mit dem Modul HP Lab s ARQ des Jena Toolkits. Die ABox Query Engine ist mit dem Tableau Reasoner und der Wissensbasis verbunden. Die Rolling-up Technik von Horrocks und Tessaris 2002 verwendet die Enginge um Anfragen mit ununterscheidbaren Variablen zu handhaben. Mehrere Query Engines zusammen beantworten die Anfrage. Die Erste analysiert die Anfrage und unterteilt sie gegebenenfalls in mehrere Teilanfragen. Diese werden dann getrennt bearbeitet und am Ende wieder zusammengeführt. Einige in Pellet implementierte Optimierungen sind in Kapitel 2.3 beschrieben worden. Die Leistung im Vergleich zu anderen Reasonern schauen wir uns in der Zusammenfassung an. 4 Zusammenfassung In dieser Arbeit haben wir uns den Tableaualgorithmus, mit der Beschreibungslogik ALC angeschaut. Wir haben dabei festgestellt, dass dieser nicht immer terminiert und dass mit Blocking ein Abschluss des Algorithmus immer gewährleistet werden kann. Im Weiteren haben wir Optimierungen des Tableauverfahren kennengelernt, die in Pellet implementiert sind. Abschließend schauen wir uns noch einen Leistungsvergleich zwischen Pellet und anderen hochperfomanten Reasonern an. Zum Vergleich verwenden wir RacerPro und FaCT Ausgeschlossen sind ABox Assertions, nominals und qualified number restrictrions, da nicht alle Reasoner diese unterstützen. Die Abbildung 7 zeigt nach oben an der Y-Achse die Zeit in logaritmischer Skala und nach rechts an der X-Achse die Größe der Ontologien [8]. Wir stellen fest, dass Pellet zwar generell langsamer als beide Konkurenten ist, aber dies in der Praxis nicht so schwer ins Gewicht fallen würde. Für die komplexe Medizinontologie Galen (äußerst rechts) ist Pellet fast zehnmal schneller als FaCT++. Die Leistung von Pellet in einem weiteren Test mit ABox Queries ist im Gegensatz zu RacerPro wesentlich besser. Die Forscher suchen nach neuen Optimierungen, um eine bessere Performance zu erreichen. Auf diese Weise, hoffen die Forscher in Praxisprojekten größere

89 Reasoning mit Tableau (anhand von Pellet) 85 Verbreitung zu finden. Ich bin zuversichtlich, dass dies gelingt und der Schulabsolvent auf der Suche nach seinen Traumberuf, effektiv mit semantischer Suche unterstützt werden kann. Abbildung 7. Leistungsvergleich Pellet, RacerPro und FaCT++ Literatur [1] F. Baader and U. Sattler. An overview of tableau algorithms for description logics [2] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, [3] P. Hitzler, M. Krötzsch, S. Rudolph, and Y. Sure. Semantic Web. Springer, [4] P. D. P. Hitzler, D. S. Rudolph, and D. R. Volz. Vorlesung intelligente systeme im world wide web; web ontology language owl: Semantik. Institut für Angewandte Informatik und Formale Beschreibungsverfahren (AIFB) Universität Karlsruhe (TH), [5] B. Hollunder, W. Nutt, and M. Schmidt-Schauß. Subsumption algorithms for concept description languages [6] I. Horrocks. Implementation and optimization techniques. In Description Logic Handbook, pages , [7] E. Sirin, B. Parsia, and B. C. Grau. From wine to water: Optimizing description logic reasoning for nominals [8] E. Sirin, B. Parsia, B. C. Grau, A. Kalyanpur, and Y. Katz. Pellet: A practical owl-dl reasoner

90 Die Anfragesprache SPARQL Alexander Matwin Universität Augsburg Zusammenfassung Die folgende Arbeit zeigt eine Einführung in SPAR- QL, ihre Sprachkonstrukte, wie man auf die von RDF spezifizierten Daten und Informationen zugreift und den Vergleich zur relationalen Algebra. SPARQL ist die Abkürzung für SPARQL Protocol and RDF Query Language. Nachdem sie beim World Wide Web Consortium (W3C) [8] mehrere Jahre auf der Liste der Candidate Recommandation stand und auch mal wieder verworfen wurde, ist sie aber seit dem 15. Januar 2008 zur endgültigen Recommandation avanciert [6]. SPARQL basiert im Kern auf einfache RDF Anfragen, deren Komplexität aber durch erweiterte Funktionalität, wie zum Beispiel der Konstruktion komplexerer Anfragemuster oder zusätzlicher Filterbedingungen, gesteigert werden kann. 1 Einführung Im Semantic Web ist es wichtig, einheitliche, offene Standards zu vereinbaren, um Informationen zwischen verschieden Plattformen und Anwendungen auszutauschen und in Beziehung setzen zu können. Diese Standards sollten auch das Ziel der Flexibilität und Erweiterbarkeit erfüllen. Zu diesem Zweck, der Schaffung solcher Standards, hat sich das W3C zusammengeschlossen, welches 1994 gegründet wurde. Da es sich bei diesem Consortium um keine anerkannte Organisation handelt und somit keine festen Standards festlegen darf, handelt es sich bei ihren Arbeiten um sogenannte Recommandations. Empfehlungen, basierend auf Technologien die frei von Patentgebühren sind. Es wurden bereits wichtige, grundlegende Standards von diesem Consortium beschrieben, wie zum Beispiel die Markup- und Meta-Sprache XML (extensible Markup Language), mit deren Hilfe man eine logische Struktur von Dokumenten festlegen kann. Auch Spezifikationssprachen wie RDF (Resource Description Framework) und OWL (Web Ontology Language ) sind schon längst als Recommandations von der W3C eingestuft. RDF ist eine allgemeine Sprache zur Beschreibung von Metadaten und strukturierten Informationen. Es ermöglicht Anwendungen den Austausch von Daten im Web, ohne dabei ihre ursprüngliche Bedeutung zu verlieren. OWL ist wie RDF auch eine Repräsentationssprache, nur mit dem Unterschied der höheren Komplexität und Ausdrucksstärke. So ist es hier möglich komplexere Sachverhalte und logische Zusammenhänge zu modellieren. Ziel dieser Sprachen ist es Informationen auf eine maschinenlesbare Art und Weise zu spezifizieren.

91 Die Anfragesprache SPARQL 87 Da RDF als Sprache zur Wissensrepräsentation eine der wichtigsten Grundlagen des Semantic Web darstellt, ist somit der Erfolg des Semantic Web wesentlich abhängig von der Möglichkeit auf eine standardisierte Weise Anfragen auf eine RDF-Datenmenge zu stellen oder generell auf die RDF-Daten zugreifen zu können. Verschiedenste Anfragesprachen, wie zum Beispiel XQuery, RDQL (RDF Query Language, SQL-ähnliche Syntax), SeRQL (Weiterentwickeltung von RDQL) haben sich im Laufe der letzte Jahre entwickelt, doch letztendlich konnte sich keiner dieser Sprachen durchsetzen. Dies lag nicht nur zuletzt an der teilweisen schwierigen Umsetzung komplexer Semantiken. Um die Entwicklung eines einheitlichen Standards zu avancieren, wurde anfang Februar 2004 die RDF Access Working Group von dem W3C gegründet. Es wurden von ihnen Anforderungen einer RDF-Abfragesprache und eine Reihe von Anwendungsfällen für den Zugriff auf RDF-Daten formuliert und können in [3] nachgelesen werden. Dabei hat sich über die letzten Jahre SPARQL als die geeignete Anfragesprache für RDF herauskristallisiert, die den gestellten Anforderungen genügte. Diese Arbeit beginnt mit einer kurzen Einführung in die RDF Syntax, die als Grundlage für die SPARQL-Anfragen dient. Somit wird der Einstieg in die folgende komplexere Betrachtung von SPARQL erleichtert. Es wird aufgezeigt, wieso SPARQL es verdient hat als Recommendation eingestuft worden zu sein und warum SPARQL den geforderten Leistung besser entspricht, als ihre Vorgänger. Danach folgt im Kapitel 3 die Übersetzung von SPARQL in relationale Algebra, welches die formale Semantik beschreibt und den Hauptteil der Arbeit ausmacht. In Kapitel 4 wird die Arbeit um SPARQL-DL, die konjunktive Anfragen zulässt, erweitert. Kapitel 5 gibt eine Zusammenfassung der Arbeit, den Ausblick und den aktuellen Stand von SPARQL wieder. 2 Sprachkonstrukte 2.1 RDF-Graphen und deren Syntax Das Grundkonzept von RDF ist die Beschreibung von Ressourcen durch eine Reihe von Eigenschaften und den zugehörigen Werten, dabei werden Ressourcen in RDF als Entitäten verstanden. Konkrete und abstrakte Gegenstände werden demzufolge auf Ressourcen abgebildet. Man kann über sie Aussagen treffen und sie untereinander in Beziehung setzen. Als gängige Ressourcen können zum Beispiel Personen, Dokumente, Internetseiten oder reale Dinge, wie die Alpen die als Beispiel während der gesamten Arbeit dienen, verwendet werden. Eine RDF-Aussage besteht somit aus einer Ressource, einer Eigenschaft und ihrem Wert. Die genaue Beschreibung der Syntax von RDF-Datenmengen und der Semantik kann hier [4] nachgelesen werden. Folgendes Beispiel zeigt einen RDF-Graphen zu drei gegebenen Aussagen. Es dient einerseits der Veranschaulichung mehrerer Aussagen, andererseits ist das Beispiel eingefügt worden, um in späteren Kapiteln darauf verweisen und zugreifen zu können.

92 88 A. Matwin Beispiel 2.1 Aussagen und ihre Darstellung in graphischer Form Die Zugspitze hat eine Höhe von 2962 Metern Die Zugspitze ist ein Teil der Alpen. Die Alpen liegen in Europa. Die Zugspitze hat den Namen Zugspitze. Abbildung 1. Transformation der Aussagen zu einem RDF-Graphen Da es nicht immer sinnvoll ist zur Repräsentation von RDF-Daten einen Graphen zu zeichnen, wurde als inoffizielle RDF-Syntax Turtle eingeführt, die die Beschreibung zulässiger RDF-Graphen zeigt. Natürlich gibt es noch weitere Syntax, um RDF Modelle zu beschreiben, wie XML, N3 oder N-Tripels. Da aber die Anfragesprache SPARQL wie RDF auf der Turtle Syntax basiert, ist es offensichtlich diese als Standard zu wählen. Der Graph in Abbildung 1 würde in Turtle wie folgt aussehen: < < Metern. Diese Textdarstellung sieht vor die einzelnen Tripel zeilenweise durch einen Punkt getrennt formal zu notieren. Die Unified Ressource Identifiers (URIs) werden durch < und > geklammert und Literale in Anführungszeichen gefasst. Die Syntax ist bis auf diese Besonderheiten eine direkte Übersetzung des RDF-Graphen in Tripel. Zur Vereinfachung ist es möglich Namensräume zu deklarieren, um die URIs abzukürzen (wie auch geschehen in Abbildung 1).

93 Die Anfragesprache SPARQL SPARQL- Anfragen In diesem Abschnitt geht es darum zu zeigen wie man speziell auf Informationen in RDF zugreifen kann. Es soll auch aufgezeigt werden, dass im Vergleich zu einer anderen RDF Query Language wie am Anfang beschrieben zum Beispiel XQuery oder RDQL, SPARQL eine weitaus höhere Komplexität bezüglich den Anfragen ermöglicht. SPARQL ermöglicht es die Anfragen anhand einiger Kriterien zu filtern, um die Ergebnismenge einzuschränken. So kann zum Beispiel in einem RDF-Dokument nach allen Literalen in deutscher Sprache gesucht werden, was mit der RDF Query Language RDQL nicht möglich wäre Bestandteile einer Anfrage Die SPARQL Anfrage verwendet einen RDF-Graph als Anfragemuster und ist in der Turtle Syntax formuliert. So ist ein konsistenter Zustand gegenüber dem Description Framework garantiert, der auch seine Daten in der RDF-Tripel Notation abspeichert. Da aber SPARQL gegenüber der RDF-Query Language mehr Komplexität verspricht, führt SPARQL zusätzliche Anfragevariablen ein, um bestimmte Elemente im Anfragegraphen als Ergebnis zu ermitteln. Außerdem kann auch über jede Anfrage, spezielle Ausgabeformatierung des Ergebnisses mit angegeben werden. Eine SPARQL Anfrage basiert auf der Idee des Pattern Matchings. Dies bedeutet, dass in einer Anfrage ein Graphmuster beschrieben wird, welches Variablen enthalten kann. Zu diesem Muster werden dann übereinstimmende Teilgraphen aus dem RDF-Graphen bestimmt. Die Variablen werden an die URIs, Literale oder leere Knoten gebunden und bilden die Lösung der Anfrage. Beispiel 2.2 Eine Anfrage in SPARQL PREFIX ex: < SELECT?res?name WHERE {?res ex:name?name } Diese Anfrage enthält drei wesentliche Bestandteile PREFIX, SELECT, WHERE. Das Schlüsselwort PREFIX deklariert wie in der Turtle-Notation auch schon gezeigt wurde, einen Namensraum. In der SELECT-Klausel, die das Ausgabeformat bestimmt, werden alle Lösungen einer Anfrage zurückgeliefert. Die Angabe von Variablennamen nach dem SELECT schränkt das Ergebnis auf diese Attribute ein. Es handelt sich um die Bezeichner, für die Rückgabewerte angefordert wurden. Die WHERE-Klausel macht die eigentliche Anfrage aus. In geschweiften Klammern folgt das Graphmuster, welches die Lösung der Anfrage beschreibt. Sie kann aus einer Kombination von einfachen und komplexen Graphmustern bestehen, welche in den folgenden Abschnitten genauer beschrieben werden. Demnach liefert die Anfrage aus Beispiel 2.2 als Ergebnis Ressourcen mit dem jeweiligen dazugehörigen Namen. Wendet man diese Anfrage auf den RDF Graphen aus Abbildung 1 an erhält man folgende Lösung:

94 90 A. Matwin?res?name Zugspitze Tabelle 1. Lösung einer Anfrage Einfache Graphmuster Bei der vorgestellten Anfrage handelt es sich in der WHERE-Klausel um ein einfaches Graphmuster. Dieses Muster besteht aus Tripeln die eine Turtle-ähnliche Syntax aufweisen. Im Gegensatz zu Turtle, können aber Variablenbezeichner wie zum Beispiel?res verwendet werden. Diese Bezeichner stehen für Platzhalter, die erst nach der Anfrage mit konkreten Werten aus dem gegebenen Datenbestand gefüllt werden. Das einfache Graphmuster enthält demnach eine Menge von Tripelmustern, in denen anstatt den RDF- Ausdrücken für Subjekt, Prädikat und Objekt Variablen stehen können. Es werden dann alle Teilgraphen (Tripel) im RDF-Graphen gesucht, die der Anfrage entsprechen und an die Variablen gebunden Leere Knoten in SPARQL Im allgemeinen dienen leere Knoten in RDF dazu, Beziehungen zwischen mehr als zwei Ressourcen zu kodieren. Dies wird durch Hilfsknoten ermöglicht, welche aber lediglich eine strukturelle Funktion besitzen und nicht auf Ressourcen verweisen, die beschrieben werden sollen. So können bei der Darstellung von mehrwertigen Prädikaten leere Knoten eingeführt werden. Auch bei SPARQL kommen die leeren Knoten auf verschiedene Weise zum Einsatz. Auf der einen Seite können leere Knoten in Anfragen als Subjekte und Objekte vorkommen. Sie können wie Variablen auch bei der Durchführung einer Anfrage mit Werten des RDF-Graphen belegt werden. Jedoch zählt diese Belegung nicht zum Ergebnis dazu und eine Auswahl mit SELECT ist auch nicht möglich. Mittels der festgelegten ID eines leeren Knotens kann er öfters innerhalb eines Graphmusters verwendet werden, jedoch nicht außerhalb in anderen Mustern. Dies muss vor allem bei gruppierten und komplexen Mustern berücksichtigt werden. Auf der anderen Seite kann ein leerer Knoten auch wieder im Ergebnis auftauchen. Dies ist dann der Fall wenn der RDF-Graph auch leere Knoten besitzt. Das Vorkommen eines leeren Knotens in der Ergebnismenge sichert lediglich die Existenz des entsprechenden Knotens im Anfragegraphen, gibt aber keine Auskunft über dessen Identität wieder. Leere Knoten erhalten in der Ergebnismenge zwar eine ID, doch ist diese komplett unabhängig von der Bezeichnung des leeren Knotens im Eingabegrahen. Liefert die Ergebnismenge allerdings mehrere leere Knoten mit der gleichen ID zurück, bedeutet dies, dass sie sich auf das selbe Element im Anfragegraphen beziehen. Dies kann natürlich verschiedene Auswirkungen auf die Vergleichbarkeit von Ergebnissen haben Komplexe Graphmuster In SPARQL ist es möglich aus mehreren einfachen Graphmustern komplexere Muster zu erzeugen, welche man als gruppierendes Graph-Muster bezeichnet. Dies ermöglicht, bestimmte Bedingungen

95 Die Anfragesprache SPARQL 91 nur an einen Teil des gesamten Musters zu stellen. So können zum Beispiel einige Teilmuster optional oder mehrere alternative Muster definiert werden. Dazu ist es notwendig, einzelne einfache Graphmuster mit Hilfe von geschweiften Klammern voneinander zu trennen. Diese Aufteilung macht aber nur Sinn, wenn zusätzliche Ausdruckmittel verwendet werden können. SPARQL bietet hier die Möglichkeit von optionalen Informationen. Das optionale Graphmuster dient den Abfragen von unvollständigem Wissen, da eventuell Daten nicht vorliegen können. Hierfür muss dem Graphmuster das Schlüsselwort OPTIONAL vorangestellt werden. Ein optionales Graphmuster (G,O) besteht aus zwei Graphmustern G und O, welches als Lösung entweder eine Lösung von G und O oder nur eine Lösung von G hat. Im letzteren Fall sind die Variablen von O ungebunden, da sie keiner Lösung im RDF-Graphen entsprechen. Das optionale Graphmuster muss folglich nicht bei allen Ergebnissen vorkommen, doch wenn sie vorkommen, tragen sie zur zusätzlichen Informationsgewinnnung bei. Beispiel 2.3 Folgende WHERE-Klausel fragt nach den Namen aller Berge und falls bekannt dem Datum seiner Erstbesteigung WHERE { {?res ex:name?name.} OPTIONAL {?res ex:erstbesteigung?datum.} } Gruppierende Graphmuster finden nicht nur bei optionalen Mustern Verwendung. Sie können auch für verschiedene alternative Muster benutzt werden. Mit dem Schlüsselwort UNION lassen sich zwei gruppierende Graphmuster verketten. Als Lösung enthält man die Menge, die entweder zu einem der Graphmuster oder zu beiden paßt. Der Operator UNION kann als Logisches Oder verstanden werden. Beispiel 2.4 Folgende WHERE-Klausel fragt nach den Namen aller Berge welche sich entweder in den französischen oder deutschen Alpen befinden WHERE { {?res ex:name?name; ex:teilvon ex:französischealpen. } UNION {?res ex:name?name; ex:teilvon ex:deutschealpen. } } Abschließend sei noch erwähnt, dass Kombinationen von OPTIONAL- und UNION- Graphmustern möglich und diese auch auf jeweils mehreren Mustern größer zwei verknüpfbar sind.

96 92 A. Matwin Anfragen mit Datenwerten Im Gegensatz zu den anderen Anfragesprachen wie zum Beispiel RDQL ist es in SPARQL möglich Anfragen mit Datenwerten zu stellen. Dabei unterscheidet SPARQL in typisierte und untypisierte Datenwerte. Liegt ein RDF-Literal in untypisierter Form vor, so kann mittels einer SPARQL-Anfrage ohne Benennung des Typs nach ihm gesucht werden. Dabei werden allerdings die Literale mit Typisierung nicht mit in die Ergebnismenge aufgenommen. Enthalten die Literale jedoch einen Datentyp oder eine Sprachinformation (zum Beispiel in der Form einer Sprachangabe wie ist es wichtig dies auch in der Anfrage zu berücksichtigen und den gesuchten Typ mitanzugeben. Eine Anfrage wie {?subjekt < "test".} würde bei folgendem RDF-Dokument ex:bsp1 ex:p "test". ex:bsp2 ex:p nur auf die Daten von bsp1 passen. Diese Eigenschaft ermöglicht es SPARQL mit Hilfe der Angabe des Sprachcodes in der Anfrage, in einem RDF-Graphen nach allen Literalen zum Beispiel in deutscher Sprache zu suchen Filter Oft reichen optionale oder alternative Bedingungen nicht aus, wenn zum Beispiel nach Werten in einem bestimmten Bereich gesucht werden soll, oder nach Literalen in denen ein bestimmtes Wort vorkommt. Ein weiteres Problem das durch die Verwendung von Sprachangaben auftritt ist, dass nicht nach einem Wert gesucht werden kann, wenn man die Sprachangabe nicht kennt. Diese Anfragen können in SPARQL mit Hilfe von verschiedenen Filterbedingungen gelöst werden. Sie dienen dem Zweck Ergebnismengen weiter einzuschränken. In dieser Arbeit wird nur ein ein Teil der Filterbedingungen vorgestellt. Eine komplette Auflistung sämtlicher Filter ist in [5] zu finden Beispiel 2.5 Folgendes Beispiel zeigt, wie man in einer SPARQL Anfrage Filterbedingungen einsetzt WHERE { {?res ex:name?name.} OPTIONAL {?res ex:erstbesteigung?datum FILTER (?datum > 1800) } } Dieses Beispiel zeigt auf, dass Filter, eingeleitet durch das Schlüsselwort FILTER, auch in gruppierenden Graph-Mustern eingesetzt werden können, auch wenn sie

97 Die Anfragesprache SPARQL 93 Bestandteile von Optionen oder Alternativen sind. Als Ergebnis dieser Anfrage, werden alle Namen der Berge und falls bekannt nur die Daten ausgegeben, wenn die Erstbesteigung nach 1800 war. In Beispiel 2.5 wurde der Vergleichsoperator > (größer) als Filterbedingung vorgestellt. Weitere Vergleichsoperatoren wie = (gleich), < (kleiner), <= (kleiner/- gleich), >= (größer/gleich) und!= (ungleich) können der Anfrage für Vergleiche dienen. Dabei ist zu beachten, dass nur verträgliche Datentypen untereinander verglichen werden können. Der Vergleich selber Datentypen macht SPARQL keine Probleme, so lassen sich Zeitangaben, numerische Werte, Wörter und getypte Werte ohne Sprachangabe vergleichen. SPARQL bietet auch die Möglichkeit durch spezielle Operatoren bestimmte Bedingungen zu testen oder auf einen Teil des Literals zuzugreifen. Mit Hilfe des Operators LANG(A) wird zum Beispiel der Sprachcode des Literals als String zurückgeliefert. Mit dem Operator STR(A) lässt sich ein Literal oder eine URI auf ein String abbilden. Diese unären Operatoren vereinfachen die Abfrage und schränken die Ergebnismenge weiter ein. Ein nützlicher binärer Operator ist der REGEX(A,B) Operator. Er liefert ein true zurück, wenn in der Zeichenkette A, der Ausdruck B gefunden werden kann. So lassen sich zum Beispiel bestimmte Literale durch die Angabe eines Wortes selektieren. Durch die booleschen Operationen && (logisches und), (logisches oder) und! (logische Negation) können mehrere Filterbedingungen verkettet oder eine Bedingung umgedreht werden. Dadurch werden komplexere Anfragen möglich und die Ausdrucksstärke wird erhöht. Abschließend sollen noch die arithmetischen Operatoren kurz erwähnt werden, mit denen man numerische Werte entsprechend berechnen kann. Es stehen hier die vier Grundrechenarten zur Verfügung Ausgabeformate Eine SPARQL-Anfrage besteht unter anderem auch aus der Spezifikation einer Ergebnisform. Es wurden in sämtlichen Beispielen die an SQL-angelehnte SELECT-Klausel verwendet, die alle Lösungen einer Anfrage ausgibt. Dies kann jedoch wie bei SQL auch zu Redundanzen führen. Um dem entgegen zu wirken sind weitere Ergebnisformen, wie CONSTRUCT, ASK und DESCRIBE möglich, die alle eine unterschiedliche Ausgabeform haben. Die CONSTRUCT-Klausel kann in Verbindung mit anderen Graphmustern dazu verwendet werden, als Ergebnisform wieder einen neuen generierten RDF- Graphen zu erhalten. Dabei werden die Variablen durch die, entsprechend in der Lösung gefundenen URIs oder Werte ersetzt. Bei Anfragen mit dem Schlüsselwort ASK, kann geprüft werden, ob es für das angegebene Graphmuster überhaupt eine Lösung im untersuchten RDF-Graphen gibt. Bei dieser Wahl der Ergebnisform entfällt die WHERE-Klausel und ein true oder false wird zurückgeliefert. Als vierte Ergebnisform ist die DESCRIBE-Klausel zulässig. Es kann hier eine Menge der zu beschreibenden Ressourcen ausgewählt werden. Der Ergebnisform ist wiederrum ein RDF-Graph, der die gefundene Lösung beschreibt.

98 94 A. Matwin Modifikatoren Trotz der vielen Möglichkeiten Ergebnisse anhand von Filterbedingungen oder verschiedenen Anfragemustern zu spezialisieren, kann die resultierende Lösungsmenge immer noch sehr groß sein. Um hier noch eine gewisse Struktur zur ermöglichen, bietet SPARQL Modifikatoren an. Sie ermöglichen die Lösungsmenge anhand von verschieden Kriterien zu sortieren. Auch hier lehnt sich SPARQL sehr stark an die SQL-Syntax an wie folgendes Beispiel zeigt. Beispiel 2.6 Diese Anfrage sortiert die Berge anhand ihrer Höhe SELECT?res?höhe WHERE {?res ex:erstbesteigung?datum.} ORDER BY?datum Hier werden die Berge aufsteigend nach dem Datum ihrer Besteigung ausgegeben. Eine absteigende Sortierung kann durch den Zusatz DESC(?datum) erreicht werden. Eine ORDER BY Anweisung kann nur auf eine SELECT Anweisung ausgeführt werden. Über das Schlüsselwort SORT BY kann explizit die Sortierreihenfolge für jede Variable einzeln bestimmt werden. Um einen Ausschnitt einer Ergebnismenge bei allen Ergebnisformen zu erhalten, werden die Schlüsselwörter LIMIT und OFFSET benötigt. Dabei gibt LIMIT die Anzahl der Ergebnisse an während OFFSET die Stelle angibt, wo mit der LIMIT Zählung begonnen werden soll. Eine zusätzlich Möglichkeit große Mengen zu reduzieren ist das Schlüsselwort DISTINCT, welches auch nur direkt nach dem SELECT auftreten darf. Es entfernt eventuelle Redundanzen aus der Ergebnismenge. 3 Übersetzung von SPARQL in relationale Algebra Im vorherigen Kapitel wurde vorgestellt, wie man mit SPARQL als Anfragesprache auf RDF-Mengen Lösungen finden und die Lösungsmenge durch Filteroperationen und Ausgabeformen reduzieren kann. Das folgende Kapitel beschreibt eine Übersetzung von SPARQL in relationale Algebra, eine formale abstrakte Sprache um Anfragen besser analysieren zu können. Wie wichtig die relationale Algebra ist, zeigt ihre heutige Verwendung: sie dient als theoretische Grundlage für Anfragesprachen in relationalen Datenbanken. Es werden Operatoren definiert, die auf Mengen von Relationen anwendbar sind, um so Relationen verknüpfen, filtern oder umbenennen zu können. Da SPARQL sich auch stark an die relationale Abfragesprache SQL anlehnt, dürfte die Transformation dem einen oder anderen vertraut vorkommen. Als Datenquelle der SPARQL-Anfragen werden wieder RDF-Dokumente dienen. So beruht die vorgestellte Algebra auf Operationen von RDF-Relationen. Einige von ihnen gleichen denen der relationalen Algebra, andere wiederum sind leicht modifiziert worden, um die SPARQL Semantik beschreiben zu können. Die Vorteile einer solchen Transformation liegen klar auf der Hand. Auf der einen Seite lassen sich durch die Darstellung von komplexeren Anfragen auf einen Operatorbaum, die Anfragen besser planen oder optimieren. Auf der

99 Die Anfragesprache SPARQL 95 anderen Seite können durch die Transformationen auf relationale Algebra, schon entwickelte und erprobte Algorithmen angewandt werden. So ist zum Beispiel eine Anwendung des Hill-Climbing Algorithmus nach der Transformation denkbar, um die Anfrage zu optimieren. Einen vorläufigen Überblick soll folgende Transformation einer SPARQL-Anfrage in einen relationalen Operatoraum bringen. Beispiel 3.1 Diese Anfrage liefert Namen von Personen und wenn vorhanden deren adresse SELECT?name?nickname WHERE {?person rdf:type foaf:person.?person foaf:name?name. OPTIONAL {?person foaf:nick?nickname } } π?name,?nickname : π?person?subject?nickname?object π?person?subject σ?predicate=rdf:type?object=foaf:p erson π?person?subject?name?object σ?predicate=foaf:name σ?predicate=foaf:nick Triples Triples Triples 3.1 Relationemodell für RDF Terme Als Erstes wird hier das Relationemodell für RDF Terme definiert, bevor eine relationale Definition von SPARQL gegeben werden kann. Ein RDF Term besteht wie in Kapitel 2 auch schon erwähnt entweder aus URIs, aus Literalen oder leeren Knoten. Diese Terme sind die Skalare, welche die Werte des hier vorgestellten Relationenmodell repräsentieren. Auch der Begriff der Anfrage-Variablen kommt uns von SPARQL vertraut vor und wird hier genauso mit einem? vor dem Namen dargestellt. Der Begriff des RDF-Tupels muss noch neu eingeführt werden. Es handelt sich hier um eine partielle Funktion, welche die Menge der Variablen auf die Menge der Terme abbildet. Ein Tupel könnte wie folgt aussehen:

100 96 A. Matwin?person < http : //example.org/people/simon >?name Simon t =?nickname Sam?age 23 Im Unterschied zu den bereits vorgestellten RDF Tripeln, können die Tupels eine beliebige Anzahl von Komponenten beinhalten, die untereinander in keiner semantischen Relation stehen müssen. Dies ist bei den Tripeln natürlich nicht der Fall, da die Komponenten Subjekt, Prädikat und Objekt durchaus in Beziehung stehen und dies auch den Sinn eines RDF-Tripel ausmacht. Ein Tupel kann als eine Art Container verstanden werden, der Variablen auf RDF-Terme abbildet. Es stellt jedoch kein Problem dar jedes RDF-Tripel auch als RDF-Tupel, allerdings ohne Semantik, darzustellen. Man spricht dann von einem S/P/O Tupel. Oft wird auch noch in gebundene oder freie Attribute unterschieden, je nachdem ob sie in der Tupeldomäne auftreten oder nicht. Unter einem Attribut versteht man die Variablen, die in einem Tupel vorkommen RDF Relationen Um bei mehreren Tupel die Übersicht nicht zu verlieren, ist es möglich sie in einer Tabelle anzuordnen, indem die Zeile einem Tupel entspricht und die Spalte einem Attribut der durch einen Variablennamen deklariert ist. Man spricht bei so einer Ansammlung von Tupeln, von einer RDF Relation. Eine sinnvolle Wahl von Variablennamen, die zugleich die Überschriften der Spalten sind, lässt Schlussfolgerungen über mögliche Operationen mit anderen Relationen ziehen. Anhand der Attribute von jedem Tupel lassen sich intuitiv die richtigen Überschriften finden. Dabei kann es auch vorkommen, dass bei einem Tupel ein Attribut nicht vorkommt und somit ungebunden ist. Dies entspricht in etwa dem NULL bei SQL. Beinhaltet eine Relation die Überschriften?Subject,?Prädikat,?Objekt spricht man von einer Graph Relation. Diese Relation besitzt nur S/P/O Tupel, die gleich den RDF-Tripeln sind. Daraus folgt, das jeder Graph-Relation ein RDF-Graph zugeordnet werden kann und umgekehrt. In den folgenden Kapiteln werden allgemeine Operatoren auf RDF-Relationen vorgestellt, die anschließend noch mit SPARQL-spezifischen Semantiken komplettiert werden Selektion Bei der Selektion (σ) werden diejenigen Tupel einer Relation ausgewählt, die das sogennante Selektionsprädikat erfüllen [2]. Dies lässt sich in SPARQL durch den Schlüsselbegriff FILTER realisieren. Durch die Filter-Klausel wird auch der Wertebereich durch Vergleichsoperatoren eingeschränkt. Es lassen sich auch so genannte konstante Attribut-Selektionen durchführen. So kann man zum Beispiel nur Tupel filtern, welche als Prädikat die gleiche URI besitzen. σ?predicate=ex:name (R)

101 Die Anfragesprache SPARQL Projektion und Umbennung Die Projektion (π) enthält die Menge der Attributnamen im Subskript [2]. Sie ermöglicht zum Beispiel nur auf das Subjekt oder das Objekt zu selektieren. Durch den Umbenennungsoperator kann der Varialenname?subject in?person geändert werden. π?person?subject (R)?name?object Inner Join und Left Outer Join In der regulären relationalen Algebra werden mit der Operation Inner Join ( ) mehrere Tabellen verbunden, sofern zumindest ein Attribut in beiden Tabellen übereinstimmt. In dem hier vorgestellten Modell gibt es einen kleinen Unterschied. Ein gemeinsames Attribut ist jedes Attribut, wenn es in beiden Relationen gebunden ist. Ein Inner Join fasst zwei Tabellen über die gemeinsamen Attribute zusammen. Dabei beinhaltet A Join B alle Kombination eines Tupels von A mit einem Tupel von B, allerdings ohne die Tupel die keinen Joinpartner im gemeinsamen Attribut haben. Der Left Outer Join (: )hingegen nimmt diese Tupel mit auf, und das fehlende Attribut wird in diesem Tupel zu einem ungebundenen.?person?name?parent ex : Simon Simon ex : P eter ex : Simon Simon ex : Claudia ex : T anja T anja Tabelle 2. Tabelle mit einem ungebundenem Attribut Union Der Union Operator in dem hier vorgestellten Relationenmodell, ist die Vereinigungsmenge der Tupeln von A mit den Tupeln von B. Dabei bleiben ungebundene Variablen auch in der Lösungsrelation ungebunden. Die Attributsmenge ergibt sich aus der Vereinigung der jeweiligen Attribute beider Relationen. 3.2 Relationale Definition für SPARQL Wie schon in Kapitel beschrieben, besteht eine SPARQL-Anfrage aus einen RDF-Graphen als Anfragemuster. Diese Graphenmuster können einfache, aber auch sehr komplexe Struktur aufweisen. So gibt es die Möglichkeit aus mehreren einfachen Mustern ein komplexeres Graphmuster zu erstellen, um auf diesem weitere Operationen durchzuführen. Hier seien nochmal die Schlüsselwörter OPTIONAL oder UNION aus Kapitel erwähnt. Ziel in diesem Abschnitt wird sein, eine Übersetzung der verschiedenen Anfragemuster von SPARQL-Anfragen in einen Ausdruck, des in Kapitel 3.1 definierten Relationenmodells, zu finden. Diese basieren auf einer Reihe von Rechenoperationen, welche die verschiedenen Ausdrucksmöglichkeiten einer Anfrage

102 98 A. Matwin repräsentieren. Unterschieden werden Operatoren, die der Beschreibung eines Graphen-Muster dienen, von jenen, die Modifikatoren der Ergebnismenge ausdrücken. Die hier relevanten Operatoren sind InnerJoin, LeftOuterJoin, Filter und Union. Jeder dieser Operatoren liefert das Ergebnis einer Teilanfrage. Wie diese Teilanfragen in einem komplexen Graphmuster ausgewertet werden, gilt es hier zu klären. Das Ergebnis der Übersetzung eines Graphmuster wird auch Pattern Relation genannt. Da die einfachste SPARQL-Anfrage aus einem RDF-Tripel besteht, bildet dieses Tripel auch den Anfang, bevor mit weiteren komplexeren Strukturen, wie gruppierende Graphmuster und Filter fortgesetzt wird Tripel - Suchmuster Eine Pattern Relation aus einer einfachen RDF- Tripel Anfrage erhält man durch eine konstante Attribut-Selektion auf das konkrete Attribut (meist das Prädikat) und durch Projektion und Umbenennung der Variablen. Beipiel 3.2 Transformation einer einfachen Anfrage eines RDF-Tripel in eine relationale Operation?person foaf:name?name wird in diese relationale Operation übersetzt: π?person?subject (σ?predicate=foaf:name )?name?object Gruppierte Graphmuster, OPTIONAL und FILTER Innerhalb eines gruppierten Muster ist die Reihenfolge der Abarbeitung der einzelnen Muster irrelevant solange sie nicht mit OPTIONAL verbunden sind. Die Übersetzung erfolgt folgendermaßen [7]: 1. Bildung der InnerJoins für alle Tripel-Suchmuster und Vereinigungen (UNI- ON). Dabei spielt hier die Reihenfolge keine Rolle, da der InnerJoin kommutativ und assoziativ ist. 2. Bildung des LeftOuterJoin aller optionalen Blöcke (OPTIONAL) mit dem Resultat aus 1., in der Reihenfolge wie sie in der Anfrage vorkommen. Dabei bildet das optionale Suchmuster die rechte Seite des OuterJoins. 3. Wende jede Werteeinschränkung (FILTER) durch den Selektionsoperator auf die Ergebnisse aus 2. an. Beispiel 3.3 Transformation eines gruppierten Musters in einen relationalen Ausdruck p1. FILTER (p). OPTIONAL p2. p3.

103 Die Anfragesprache SPARQL 99 wird übersetzt in σ p ((p1 p3) : p2) Dabei stehen die Abkürzungen p1, p2, p3 für beliebige einfache Suchmuster in der SPARQL Syntax und wurden der Übersichtlichkeit halber so dargestellt UNION UNION bezieht sich nur auf die direkt angrenzenden einfachen oder auch gruppierenden Graphmustern. Relationen werden vereinigt, sobald eine Relation auf die Anfrage passt. Ihr Relation Pattern wird wie in der Anfrage übersetzt. 3.3 Probleme bei der Übersetzung Die meisten SPARQL Anfragen könne ohne größere Probleme in relationale Algebra übersetzt werden. Allerdings gibt es auch besondere Fälle, die eigens betrachtet werden müssen. In dieser Arbeit werden zwei wichtige Transformationsprobleme angesprochen. Um einen Gesamtüberblick aller Probleme zu bekommen, sei auf [7] verwiesen FILTER Variablen Problem FILTER-Ausdrücke in SPARQL können beliebige Variablen benutzen, egal ob die Variablen innerhalb der Teilanfrage vorkommen oder in einem anderen Suchmuster außerhalb verwendet werden. Dies würde bei der genauen Übersetzung in einen Operatorbaum einen Fehler verursachen. Da sich die Selektion nur auf Variablen innerhalb des Unterbaumes, wo sie vorkommt beziehen und nicht auf Variablen außerhalb Einfluss nehmen kann, führt folgendes Beispiel zu einer nicht korrekten Lösung. Beispiel 3.6 Die Selektion im rechten Unterbaum hat keine Funktion und bezieht sich nicht auf die Variable im linken Unterbaum: : π?x?subject?type?object σ?type=foaf:p erson σ?pred=rdf:type Triples π?x?subject?name?object σ?pred=foaf:name Triples Um diesem Problem aus dem Weg zu gehen, kann man die Selektionsbedingung von FILTER im JOIN formulieren. Dadurch befindet sich die Einschränkung

104 100 A. Matwin am Verzweigungsknoten und kann auf beide Unterbäume angewandt werden. Man spricht von einem bedingten JOIN. Beispiel 3.7 Lösung des FILTER Variablen Problems :?type=foaf:p erson π?x?subject?type?object π?x?subject?name?object σ?pred=rdf:type σ?pred=foaf:name Triples Triples Geschachtelte OPTIONS Bei geschachtelten OPTIONS kann das Ergebnis der relationalen Algebra zur SPARQL Semantik unterschiedlich sein. Die SPARQL-Semantik sieht eine Abarbeitung der LeftOuterJoins (OPTIONAL) in der Reihenfolge, wie sie in der Anfrage vorkommen vor. Diese entspricht einer Auswertung im Operatorbaum von links nach rechts. Im Gegensatz dazu steht die Ausführung von unten nach oben beim Operatorbaum der relationalen Algebra. Dies führt zu einem Problem bei zwei in sich verschachtelten OPTIONALS. Wenn eine Variabel außerhalb der OPTIONAL-Ausführung und in dem innersten OPTIONAL-Ausdruck, aber nicht in dem zweiten OPTIONAL verwendet wird, kann eine verschiedene Bindung beteiligter Variablen durch eine unterschiedliche Ausführung auftreten. Dieser exklusive Fall tritt allerdings in der Praxis nicht sehr häufig auf und kann deshalb meist vernachlässigt werden. 4 SPARQL-DL Die bisherigen SPARQL-Anfragen legten alle eine RDF-Datenmenge zu Grunde. Dies bedeutet, dass im Graphmuster einer Anfrage immer ein, oder bei komplexeren Suchmustern, mehrere RDF-Tripel festgelegt waren. Dieses Kapitel erweitert das Spektrum nicht auf die Suche in RDF-Graphen, sondern wie man auch für Ontologien in Ontologiensprachen wie OWL-DL Anfragen stellen kann. Komplexe Ontologien bestehen meist nicht aus einfachen Graphen sondern besitzen eine Vielzahl unterschiedlicher Interpretationen. Ziel wird es sein eine einfache Anfragesprache zu beschreiben die mit SPARQL einhergeht aber auch OWL-DL unterstützt. SPAQRL-DL macht hier einen Schritt in die richtige Richtung. Als erstes müssen die syntaktischen Unterschiede von SPARQL und OWL-DL aufgezeigt werden, um eine Sprache zu entwickeln die mehrere flexible Anfragen auf unterschiedlichen Modellen erlaubt [1].

105 Die Anfragesprache SPARQL SPARQL Syntax RDF-Graphen bestehen aus einer Menge von SPO-Tripeln, in der jedes Tripel eine semantische Bedeutung hat. Die Elemente der Tupel können entweder aus leeren Knoten V bnodes einer URI V uri oder einem Literal V lit bestehen. Dies lässt sich formal folgendermaßen festhalten: (s,p,o) (V uri V bnodes ) V uri (V uri V bnode V lit ) 4.2 OWL-DL Syntax Obwohl man bis zu einem gewissen Grad, in den Interpretationen von OWL Graphen erkennen kann, ist die Semantik eine andere. Die Menge der URIs V uri teilt sich in viele verschiedene Teilmengen auf. Formal besteht ein OWL-DL Vokabular V o = (V cls,v op,v dp,v ap,v ind,v D,V lit ) aus einem 7-Tupel. Die Bedeutung dieser Teilmengen und deren Grammatik können in [1] nachgelesen werden. Eine OWL-Ontologie besteht hauptsächlich aus einer endlichen Menge von Klassen, Eigenschaften, den Properties und speziellen Axiomen. Klassen und Properties können in komplexe Beziehungen gesetzt werden, die mit Hilfe von Konstruktoren aus der Logik beschrieben werden. Es ist leicht erkennbar, dass sich das Vokabular und die Namensräume V uri der RDF-Datenmenge zum Vokabular der OWL-Ontologie unterscheiden. Es muss eine Interpretationsfunktion gefunden werden, die beide Vokabularien verträglich macht. Als erstes wird eine abstrakte Syntax für SPARQL-DL Anfragen definiert, ihre Semantik beschrieben und anschließend wird die abstrakte Syntax in das Tripelmuster von SPARQL überführt. 4.3 SPARQL-DL Abstract Syntax Folgendes OWL-DL Vokabular liegt vor: V o = (V cls,v op,v dp,v ap,v ind,v D,V lit ). V bnode und V var bilden die Mengen der leeren Knoten und Variablen. Eine atomare SPARQL-DL Anfrage q kann eine dieser Formen annehmen: q Type(a,C) PropertyValue(a,p,v) SameAs(a,b) DifferentFrom(a,b) EquivalentClass(C 1, C 2 ) SubClassOf(C 1, C 2 ) DisjointWith(C 1, C 2 ) ComplementOf(C 1, C 2 ) EquivalentProperty(p 1, p 2 ) SubPropertyOf(p 1, p 2 ) InverseOf(p 1, p 2 ) ObjectProperty(p) DatatypeProperty(p) Functional(p) InverseFunctional(p) Transitive(p) Symmetric(p) Annotation(s, p a, o) mit a,b V uri V bnode V var, v V uri V lit V bnode V var, p, q V uri V var, C, D S c V var, s V uri, p a V ap, o V uri V lit. Eine allgemeine Anfrage Q setzt sich aus einer endlichen Menge von q-anfragen zusammen. Diese werden mit einer Konjunktion verbunden und nennt sie deswegen auch eine konjunktive Anfrage. 4.4 SPARQL-DL Semantik Wie können nun diese atomaren Anfragen interpretiert werden? Die SPARQL-DL Semantik ist ähnlich der OWL-DL Semantik. Es müssen Kriterien spezifiziert

106 102 A. Matwin werden unter denen eine Interpretation eine atomare Anfrage erfüllt. Dabei wird ausgegangen, dass leere Knoten in den atomaren Anfragen vorkommen können. Sei O eine OWL-DL Ontologie mit V o wie in Kapitel 4.3 definiert und I die Interpretation von O mit I = ( I, I ). Eine atomare Anfrage passt zu V o, wenn alle URIs in der Anfrage ihrem korrekten Typ/Menge zugeordnet sind, zum Beispiel Type(a,C) mit a V ind und C V cls. Eine Durchführung σ überprüft ob ein Element aus V ind V bnode V lit auf ein Element der Interpretationen Domäne I überführt werden kann, mit der Bedingung, dass σ(a) = a I wenn a V ind oder a V lit. Eine Interpretation I erfüllt eine Anfrage q hinsichtlich σ, wenn q mit V o übereinstimmt und die entsprechende Bedingung aus Abbildung 2 erfüllt ist. Eine Interpretation I erfüllt eine Anfrage Q = q 1 q 2... q n bezüglich σ wenn auch für alle q i Q für jedes i=1,...,n I bezüglich σ gilt. Die Lösung zu einer SPARQL-DL Anfrage Q ist, wenn durch eine Variablenüberführung µ der Form V var V uri V lit alle Variablen in Q durch den entsprechenden Wert in µ ersetzt werden können. Die Anfrage µ(q) ist mit dem Vokabular von O verträglich und man sagt auch O ist ein Modell von µ(q). Abbildung 2. SPARQL-DL Anfrage und die Kriterien der Interpretation [1] 4.5 SPARQL-DL Abstract Syntax in RDF-Graphen Dieser Abschnitt beschäftigt sich mit der Übersetzung von der SPARQL-DL abstract Syntax in das RDF Tripelmuster. Dabei wird die Funktion T wie in [2] benutzt, welche komplexe Klassenausdrücke in ein oder mehrere RDF Tripel übersetzt. Wenn eine Komponente bei der Übersetzung als Subjekt, Prädikat oder Objekt verwendet wird, bedeutet dies, dass diese Übersetzung einen Teil

107 Die Anfragesprache SPARQL 103 des Ergebnisses ausmacht. Dieses Element ist dann auch Teil des Tripels. Die Übersetzung einer SPARQL-DL Anfrage ist die Vereinigung aller RDF-Tripel, die durch die Übersetzung jeder atomaren Query erhalten wurde. Abbildung 3 zeigt die Umformungen der Abstract Syntax in RDF-Tripel. Abbildung 3. Überführung der SPARQL-DL Syntax in RDF-Tripel [1] 5 Zusammenfassung In dieser Arbeit wurde als erstes ein kleiner Einblick in das Resource Description Framework gegeben, welches als formale Sprache für die Beschreibung sturkturierter Daten dient. Um nun auf diesen Datenbestand zugreifen zu können, hat sich letztendlich die Anfragesprache SPARQL durchgesetzt. Es wurden hier die wichtigsten Ausdrucksmittel von SPARQL vorgestellt, zugleich nicht auf jede Ausdrucksform im Detail, im Rahmen der Seminarabeit, eingegangen werden konnte. Die verschiedenen Anfragebedingungen in Form von unterschiedlichen Graphmustern und Filtern sowie Modifikatoren und Ausgabeformate haben gezeigt, dass SPARQL eine hohe Vielfalt und Komplexität bezüglich dem Zugriff auf spezifizierte Informationen bietet. Im dritten Kapitel wurde durch die Transformation in relationale Algebra die genaue Semantik der Ausdrucksmittel beschrieben. Ein Relationenmodell und die dazu gehörigen Mengenoperationen für RDF-Terme wurden eingeführt und vorgestellt. Diese Umsetzung von SPARQL-Anfragen in relationale Algebra ist nicht nur mit Aufwand verbunden, sondern bringt mehrere Vorteile mit sich. Abgesehen von einer graphisch, verständlicheren und vertraulicheren Darstellung zum Beispiel durch einen Operatorbaum, liegt es nicht fern SPARQL Anfragen auch nach SQL zu übersetzten. Da es momentan immer noch viel mehr SQL Server als SPARQL-Anfrage Server gibt. Der Übergang von der Industrie-

108 104 A. Matwin zur Informationsgesellschaft findet seine wohl markanteste Ausprägung in der rasanten Entwicklung des World Wide Web. [5] Um nun diese Entwicklung vorwärts zu treiben ist eine Umstrukturierung der Informationen notwendig. Das Web bietet heutzutage eine unüberschaubare Menge an Informationen, die auf den Menschen ausgerichtet ist. Ziel ist es aber die Bedeutung einer Information nicht nur für den Menschen interpretierbar zu machen sondern auch maschinenlesbar. Dies würde eine semantische Suche ermöglichen. Das Semantic Web steht für die Idee, die Information von vornherein in einer Art und Weise zur Verfügung zu stellen, die deren Verarbeitung durch Maschinen ermöglicht. [5] Diesen Ansatz verfolgt das World Wide WEB Consortium, welches durch ihre Standards wie den XML und RDF Informationsspezifikationssprachen und nicht zuletzt der Abfragesprache SPARQL den Weg in die Zukunft ebnen. SPARQL war in letzten Jahren meist nur als Anfragesprache für RDF-Graphen geeignet. Dies hat sich aber in letzter Zeit gewandelt. SPARQL-DL unterstützt nicht mehr nur die RDF-Semantik sondern teilweise auch die Semantik von OWL, wie in Kapitel 4 beschrieben. Sie kann als Sprache aufgefasst werden, die zwischen einer RDF Anfragesprache und einer reinen Anfragesprache für die Description Logic (DL) liegt. Ziel wird es sein, in nähere Zukunft eine Abfragesprache zu generieren die sämtliche Ausdrucksformen von SPARQL auch auf komplexere Ontologien erlaubt. SPARQL-DL ist schon mal ein Schritt in die richtige Richtung. Literatur [1] E.Sirin and B.Parsia. Sparql-dl:sparql query for owl-dl [2] F.Patel-Schneider and I.Horrocks. Owl web ontology language, [3] K.Clark. Rdf data access use cases and requirements, [4] P.Hayes. Rdf semantics, [5] P.Hitzler, M.Krötzsch, S.Rudolph, and Y.Sure. Semantic Web. Springer-Verlag, [6] R.Cover. W3c publishes sparql recommendation, [7] R.Cyganiak. A relational algebra for sparql [8] W3C. W3c world wide web consortium.

109 Ontologie-Methodologien und Ontologie Design Benedikt Gleich Universität Augsburg Zusammenfassung Das Design von Ontologien für praktische Anwendungen ist eine Aufgabe mit zunehmender Komplexität, so dass eine unstrukturierte und manuelle Entwicklung kaum noch sinnvoll ist. Ontologie- Methodologien liefern strukturierte Vorgehensanweisungen für den Prozess des Ontology Engineering in seiner Gesamtheit und beziehen dabei auch projektspezifische Fragestellungen mit ein. Ontologie Design Patterns adressieren dagegen den konkreten Modellierungs-Prozess und bieten hierbei konkrete Anleitungen für wiederkehrende Problemklassen. Da Ontologien eine Schlüsseltechnologie für das Semantic Web darstellen, ist auch deren konkrete Syntax (z.b. RDF/OWL) genauso relevant wie es semantische Ähnlichkeiten zu bekannteren Techniken wie UML sind. Da es noch viele praktische Herausforderungen im Ontologie Design gibt, verspricht dieses Forschungsfeld auch langfristig spannende Fragen und Antworten. 1 Einleitung Ontologien sind ein sehr mächtiges Werkzeug im Wissensmanagement und darüber hinaus eine der Schlüsseltechnologien des Semantic Web. Mit ihnen lassen sich nicht nur statische Taxonomien, sondern dynamische Abbilder der realen Welt erstellen, aus denen mit Inferenz-Regeln verschiedenste Aussagen abgeleitet werden können. Da Ontologien erhebliche Mengen von Wissen akkumulieren sollen, ist ihre Entwicklung ein langwieriger und komplexer Prozess. In dieser Arbeit sollen unter anderem Techniken beschrieben werden, mit denen dieser Entwicklungsprozess methodisch und strukturiert durchgeführt werden kann. Zusätzlich werden Ontologien gegen andere Modellierungstechniken abgegrenzt und gegenwärtige Herausforderungen kurz behandelt. Ontologie-Methodologien liefern Empfehlungen, wie die Entwicklung einer Ontologie organisiert werden kann. Zusätzlich findet man in Ontologie Design Patterns eine Reihe von praktischen Techniken, die bei der Modellierung einzelner Konzepte hilfreich sind. Im Folgenden sollen nach einer kurzen Abgrenzung zwischen Ontologien und anderen Modellierungstechniken wie UML verschiedene Ontologie-Methodologien genauer beschrieben werden. Darauf folgt eine Betrachtung verschiedener Ontology Design Patterns (ODPs). Die Arbeit schließt mit der Untersuchung von praktischen Herausforderungen und einer Zusammenfassung.

110 106 B. Gleich 1.1 Definitionen Für den Begriff der Ontologie gibt es eine Vielzahl von unterschiedlich intuitiven Definitionen[2]. Die bekannteste und in gewisser Weise klassische Definition stammt von Thomas Gruber[12]: An ontology is an explicit specification of a conceptualization. Nicht zuletzt aufgrund ihrer Kürze ist diese Definition nicht besonders intuitiv, besonders im Vergleich zu folgender Beschreibung [3], die die einzelnen Bestandteile von Ontologien beschreibt: An ontology is a hierarchically structured set of concepts describing a specific domain of knowledge that can be used to create a knowledge base. An ontology contains concepts, a subsumption hierarchy, arbitrary relations between concepts, and axioms. It may also contain other constraints and functions. 2 Unterschiede zwischen Ontologien und UML Durch den hohen Abstraktionsgrad des Konzeptes von Ontologien gibt es häufig Verwirrung bei der Abgrenzung zu anderen Modellierungs-Techniken wie UML oder auch zu Wissensrepräsentations-Sprachen wie XML. Grundsätzlich kann man festhalten, dass Ontologien in der Regel in XML- Dialekten (wie z.b. RDF / OWL) gespeichert und ausgetauscht werden. Abgesehen davon haben Ontologien eine eigene Semantik, die speziell auf die abstrakte, aber dennoch praktisch einsetzbare Beschreibung von Sachverhalten der realen Welt ausgerichtet ist. Eine andere Natur hat das Verhältnis zwischen Ontologien und UML Modellen und insbesondere Klassendiagrammen. Letztere können sowohl Code-Klassen in der objektorientierten Programmierung, als auch fachliche Sachverhalte der realen Welt beschreiben. Gerade das entspricht aber in vielen Aspekten dem Konzept von Ontologien. In der Tat ist es auch möglich, Übersetzungen zu definieren, mit denen z.b. in OWL definierte Ontologien nach UML oder auch UML-Modelle nach OWL abgebildet werden können [11, 1, 13]. Da es jedoch für die Erstellung von Ontologien inzwischen Tools wie protégé gibt, die ähnlich leicht wie UML-Editoren zu bedienen sind, ist der Einsatz von UML zur Modellierung von Ontologien grundsätzlich vor allem in Ausnahmefällen interessant.

111 3 Ontologie Methodologien Ontologie-Methodologien und Ontologie Design 107 Der Entwurf von Ontologien das Ontology Engineering erfährt in den letzten Jahren eine Entwicklung, die mit der des Software Engineering vergleichbar ist: Beide Bereiche streben ingenieursmäßige, also methodische und planbare Entwicklungsprozesse an. Ontologie-Methodologien beschäftigen sich mit der grundlegenden Fragestellung im Ontology Engineering: Welche Methoden, Aktivitäten und Annahmen sind für die Erstellung von Ontologien zu empfehlen?[5]. Die Methodologien des Ontology Engineering sind sehr heterogen und stark von ihren jeweiligen Anwendungsgebieten abhängig. Daher sollen nach der Vorstellung einer möglichen Klassifizierung einige konkrete Ansätze zur Methodik im Ontology Engineering genauer beschrieben werden. Bei der Betrachtung der verschiedenen Methodologien zeigt sich in der zeitlichen Entwicklung eine qualitative Veränderung: Während die frühen Methodologien wie Uschold/King oder Grüninger/Fox nur grundlegende und unvollständige Vorgehehensmodelle vorschlagen, liefern fortgeschrittene Varianten wie Methontology oder Ontology Development 101 bereits umfassende Empfehlungen für den gesamten Projektumfang und den Lebenszyklus des Ontology Design. Daher sollen diese im Folgenden als Methodologien der zweiten Generation bezeichnet werden, während die frühen Methodologien die ersten Generation darstellen. Die dritte Generation wird von Methodologien gebildet, die über das reine Ontology Design hinaus auch alle anderen Rahmenbedingungen des Ontology Engineering wie iterative Entwicklung oder Aspekte der Kollaboration einbeziehen. 3.1 Klassifikation Von Mariano Fernández López werden insgesamt neun verschiedene Kriterien vorgeschlagen[15], mit denen Methodologien zum Design von Ontologien klassifiziert werden können: C1: Einflüsse durch Knowledge Engineering Bereits vor dem breiten Einsatz von Ontologien gab es Ansätze zum Wissensmanagement. Es ist hilfreich für das Verständnis von Methodologien, sie auf diese Einflüsse hin zu überprüfen. C2: Detailgrad der Methodologie Wie detailliert wird das empfohlene Vorgehen beschrieben? Sind das konkrete Vorgehen und der Einsatz von Tools Bestandteil der Methodologie? C3: Art und Weise der Formalisierung Wie soll das zu erfassende (semantische) Wissen syntaktisch abgebildet werden? C4: Anwendungsabhängigkeit Gibt es einen konkreten Anwendungsbereich, auf den die Methodologie ausgelegt ist oder findet die Entwicklung abstrakt statt? C5: Vorgehen zur Auswahl von Konzepten Hier gibt es die grundlegenden Konzepte bottom-up (von konkreten zu abstrakten Konzepten), middleout (von den wichtigsten Konzepten zu den abstrakteren und konkreteren) sowie top-down (von abstrakten zu konkreten Konzepten).

112 108 B. Gleich C6: Empfehlungen zum Lebenszyklus? Wird auf implizite oder explizite Weise ein bestimmter Lebenszyklus für die zu entwickelnde Ontologie vorgeschlagen, etwa durch Angabe der erwarteten Lebensdauer? C7: Standardkonformität Bezieht sich die Methodologie auf die im IEEE- Standard beschriebenen Methoden zur Entwicklung von Software- Produkten? C8: Empfohlene Techniken Gibt es konkrete Vorschläge, wie bestimmte Aktivitäten im Ontology Engineering ausgeführt werden sollen? C9: Anwendung Welche Ontologien und welche Systeme wurden mit der vorgeschlagenen Methodologie bereits entwickelt? Obwohl diese Kriterien schon 1999 vorgestellt wurden, stellen sie doch nach wie vor ein hilfreiches Raster zur Analyse der vielen verschiedenen Methodologien dar, die nun im einzelnen kurz vorgestellt werden sollen. 3.2 Methodologien der ersten Generation Uschold/King Die Methode Uschold/King [17, 15, 5] ist eine der ersten vorgeschlagenen Methodologien. Sie empfiehlt im Wesentlichen vier Phasen: 1. Ermittlung der genauen Zielsetzung 2. Entwicklung der Ontologie (a) Erfassung der Konzepte (b) Kodierung (c) Integration existierender Ontologien 3. Evaluation 4. Dokumentation Dabei werden für die Erfassung der Konzepte (ontology capture) die drei Methoden top-down, bottom-up und middle-out jedoch mit Präferenz auf der letzten vorgeschlagen. Eine der wichtigsten Anwendungen dieser Methodologie ist die so genannte Enterprise Ontology, die eine Sammlung wichtiger Begriffe aus dem betriebswirtschaftlichen Umfeld darstellt. Insgesamt geht die Unschold/King- Methode allerdings nur auf wenige Aspekte des Ontology Engineering ein, womit bei ihrer Anwendung viele Fragen offen bleiben Grüninger/Fox Die Grüninger/Fox-Methode [10, 15] ist ebenfalls eine sehr frühe Methodologie, die sehr stark durch den Einsatz der Prädikatenlogik Erster Ordnung geprägt ist. Dabei werden sechs verschiedene Phasen unterschieden: 1. Erfassung von Motivations-Szenarien Meist ist die Entwicklung von neuen Ontologien durch Mängel in aktuellen Ontologien oder den Wunsch nach bestimmten Neuerungen motiviert. Diese Motive und insbesondere die erhofften neuen Ergebnisse sollten hier festgehalten werden.

113 Ontologie-Methodologien und Ontologie Design Informelle Formulierung von zentralen Anfragen Diese Fragen (competency questions) dienen als Benchmark für die spätere Entwicklung der Ontologie. Mit ihnen kann die Terminologie überprüft werden. So zeigt sich, ob Axiome und Definitionen ausreichend sind. 3. Formale Spezifikation der Ontologie Hierfür werden zuerst aus den zentralen Anfragen die wichtigsten Begriffe extrahiert, um diese dann in einen Formalismus zu überführen. 4. Spezifizierung von zentralen Anfragen Die bereits informell festgehaltenen zentralen Anfragen müssen nun formal spezifiziert werden. 5. Spezifizierung von Axiomen und Definitionen Ebenso wie die zentralen Anfragen müssen auch die Axiome und Definitionen spezifiziert werden, um sie praktisch einsetzen zu können. 6. Definition der Vollständigkeitsbedingungen Die nun spezifizierte Ontologie kann natürlich nur unter bestimmten Bedingungen vollständige Antworten liefern. Diese Bedingungen müssen nun festgehalten werden. Wiederum fehlen in dieser Methodologie eine Reihe von wichtigen Angaben, etwa zum Lebenszyklus der zu entwickelnden Ontologie oder zu empfehlenswerten Techniken und Tools. Im Gegensatz zur Uschold/King-Methode werden aber eventuelle Anwendungen zumindest in den Entwicklungsprozess einbezogen. Insgesamt ist die Uschold/King-Methode heute nur noch für spezielle Anwendungsfälle zu empfehlen. 3.3 Methodologien der zweiten Generation Methontology Während die bisher geschilderten Methodologien der ersten Generation angehören, handelt es sich bei Methontology bereits um eine Methodologie der zweiten Generation: Analog zum Software Engineering werden dort nicht nur die Kernaktivitäten der Entwicklung einer Ontologie, wie etwa die Spezifikation und Konzeptualisierung, sondern auch Umgebungsbedingungen wie Lebenszyklen oder konkrete Techniken beschrieben, was auch in Abbildung 1 dargestellt ist. Diese verschieden Aktivitäten des Ontology Development Process können dabei in drei Klassen eingeteilt werden[7, 15]: Projektmanagement Hierbei sind die klassischen Aktivitäten Planung, Überwachung und Qualitätssicherung zu nennen, die für die erfolgreiche Entwicklung einer Ontologie notwendig sind. Entwicklung Die Entwicklung setzt sich aus den Tätigkeiten Spezifikation, Konzeptualisierung, Formalisierung und Implementierung zusammen. Dabei wird in der Spezifikation beschrieben, warum die Ontologie entwickelt wird und wie bzw. von welchen Nutzern sie benutzt werden soll. Während im Rahmen der Konzeptualisierung das vorhandene Wissen strukturiert wird, wird es im Rahmen der Formalisierung in ein möglichst automatisiert verarbeitbares Modell transformiert. Nach der Implementierung, in der die Ergebnisse der vorherigen Schritte zu einem System zusammen gesetzt werden, folgt die

114 110 B. Gleich Abbildung 1. Bestandteile des Ontologie Design Prozesses von Methontology Wartungsphase, in der Fehler behoben und neue Anforderungen umgesetzt werden. Support In den Bereich des Support fallen die Aktivitäten des Ontology Engineering, die vor und nach der eigentlichen Entwicklung stattfinden. Dabei sind Aktivitäten wie die Aneignung des notwendigen Wissens (Knowledge Acquisition), die Evaluation der Ergebnisse oder die Integration eventueller verwendeter Ontologien zu nennen. Genauso entscheidend ist auch die Dokumentation der Ergebnisse sowie ein dediziertes Konfigurationsmanagement. Für die konkrete Entwicklung identifiziert Methontology dabei eine Reihe von Komponenten[4]: Konzepte Relationen Instanzen Konstanten Attribute Formale Axiome Regeln Diese Komponenten werden überwiegend im üblichen Sinne verwendet. Bei Attributen wird zwischen Instanzattributen und Klassenatributen unterschieden: Erstere beziehen sich auf Eigenschaften von Instanzen (z.b. Name bei einer konkreten Person), während sich Letztere sich auf das (abstrakte) Konzept an sich beziehen und weder vererbt noch in die Instanzen übernommen werden. Der Unterschied zwischen Axiomen und Regeln besteht darin, dass Axiome überwiegend im Sinne von Integritätsbedingungen verwendet werden, die immer wahr sein müssen, während Regeln die Basis für das Reasoning darstellen. Analog zum Software Engineering ist auch im Ontology Engineering ein gezieltes und geplantes Vorgehen unverzichtbar. Daher werden diese Aktivitäten

115 Ontologie-Methodologien und Ontologie Design 111 durch den Ontology Life Cycle in einen zeitlichen Zusammenhang gesetzt, der in Abbildung 2 illustriert wird. Abbildung 2. Die Verteilung der einzelnen Tätigkeiten von Methontology Darüber hinaus stellt Methontology auch Tools wie ODE oder WebODE zur Verfügung, wobei allerdings zusätzlich auch andere Tools verwendbar sind. Insgesamt präsentiert sich Methontology als durchdachte und umfassende Sammlung von Methoden zur Entwicklung von Ontologien. Die vielen verschiedenen Anwendungen, etwa aus der Rechtswissenschaft [4] oder der Chemie [16], zeigen die vielseitige Anwendbarkeit Ontology Development 101 Während die bisher geschilderten Methodologien sich überwiegend auf einem relativ abstrakten Niveau bewegen, liefert der Artikel Ontology Development 101: A Guide to Creating Your First Ontology [19] eine sehr anschauliche und pragmatische Methodologie für Ontologie Design. Dabei stellen die Autoren ihren Ausführungen einige allgemeine Grundregeln voran: Es gibt keine Patentlösung für Ontologie-Design. Die optimale Methodologie hängt immer von der jeweiligen Anwendung und den erwünschten Ergebnissen ab. Ontologie-Design ist zwangsläufig ein iterativer Prozess. Die Konzepte sollten sich möglichst an Objekten und Relationen des Anwendungsbereiches orientieren. Dabei werden Objekte durch Substantive und Relationen durch Verben beschrieben.

116 112 B. Gleich Darauf aufbauend wird dort eine konkrete und praxisnahe Vorgehensweise beschrieben, mit der eine Ontologie für den Anwendungsbereich verschiedener Weinsorten mit Hilfe des Ontologie-Editors protégé entwickelt werden könnte. Dieses Vorgehensmodell gliedert sich in sieben Schritte: 1. Bestimmung von Anwendungsbereich und Zielsetzung der Ontologie Am Anfang sollte festgelegt werden, wofür die Ontologie in welchem Bereich benutzt werden sollte und welche Arten von Anfragen an sie gestellt werden. Dafür empfehlen die Autoren die bereits geschilderten zentralen Anfragen (competency questions) aus der Grüninger/Fox-Methode. Darüber hinaus sollte erwähnt werden, wer die Ontologie warten und benutzen wird. 2. Wiederverwendung überprüfen Nach dem ersten Schritt ist es sehr empfehlenswert, zu überprüfen, ob wirklich eine neue Ontologie entwickelt werden muss oder ob es nicht bereits eine bestehende Ontologie gibt, die die Anforderungen weitgehend erfüllt. 3. Auflistung wichtiger Begriffe Als Grundlage für die nächsten Schritte sollten nun alle wichtigen Begriffe des Anwendungsbereiches möglichst vollständig aufgelistet werden, ohne auf etwaige Überschneidungen zu achten. 4. Definition von Klassen und deren Hierarchie Dafür eignen sich die bereits genannten Methoden top-down, bottom-up oder eine Kombination aus beidem. Die Hierarchie sollte dabei in der Form ist ein ( is a : subsumtion/subclass) entwickelt werden: Wenn jede Instanz von B eine auch eine Instanz von A ist, dann ist B eine Unterklasse A. 5. Definition von Klassen-Eigenschaften In dieser Phase können meist die im 3. Schritt erstellten Begriffe, die nicht im 4. Schritt als Klassen verwendet wurden, herangezogen werden: Höchstwahrscheinlich repräsentieren sie Eigenschaften. Dabei sind intrinsische (z.b. Geschmack) und extrinsische (z.b. Name) Eigenschaften zu unterscheiden. Weiterhin können diese sich auf Teile einer Klasse beziehen (z.b. die Flasche eines Weins) oder für eine Relation stehen (z.b. zum Weingut). Eigenschaften werden dabei häufig auch als Slots bezeichnet. 6. Definition von Aspekten Für die angelegten Slots müssen nun Aspekte definiert werden, die auch als facets bezeichnet werden. Diese Beziehen sich auf Typisierung, Wertebereich oder Kardinalität. Ein Wein kann beispielsweise aus mehreren Rebsorten zusammengesetzt sein. 7. Erstellung von Instanzen Um die erstellte Ontologie nun anzuwenden, müssen konkrete Instanzen erstellt werden, so dass auch die anfangs formulierten zentralen Anfragen überprüft werden können. Das in Ontology Development 101 geschilderte Vorgehen ist also sehr hilfreich und empfehlenswert für erste praktische Versuche mit Ontologien, wenn auch weniger wissenschaftlich als die anderen Methodologien. 3.4 Methodologien der dritten Generation Im Vergleich zu den bisher geschilderten Methodologien unterscheiden sich die Methodologien der dritten Generation vor allem dadurch, dass sie über den

117 Ontologie-Methodologien und Ontologie Design 113 eigentlichen Ontologie-Design-Prozess hinaus gehende Empfehlungen geben. Insbesondere bilden sie viele aus dem Software Engineering bekannte Techniken auf die Erstellung von Ontologien ab und vollziehen damit den Schritt vom reinen Ontology Design zum Ontology Engineering Methodologien und Software Engineering Schon bei Methontology ist ein deutlicher Bezug zum Software-Engineering anhand der Unterteilung in Management, Entwicklung und Support erkennbar: Während im Projektmanagement die Kosten, Termine und Qualität miteinander abgeglichen werden, entspricht die Entwicklung in Methontology dem Design und der Implementierung im Software Engineering. Der Support schließlich entspricht im Wesentlichen den Phasen Analyse, Test und Wartung. Daran zeigt sich, dass Ontologien zwar keine Software-Anwendungen im klassischen Sinne sind, aber grundsätzlich im Rahmen von ähnlichen kontrollierten und methodischen Prozessen entwickelt werden können und sollten. Dieser Ansatz wird von der Methodologie UPON [18] weiter verfeinert: UPON steht dabei für Unified Process for Ontology Building. Der Ansatz besteht also darin, für die Entwicklung von Ontologien einen iterativen, inkrementellen und an Use-Cases orientierten Prozess einzuführen. Dabei gibt es grundsätzlich fünf verschiedene Abläufe (Anforderungen, Analyse, Design, Implementierung und Test) sowie in jeder Iteration vier Phasen (inception, elaboration, construction und transition). Auch die Methodologie On-To-Knowledge [23] setzt ihre Schwerpunkte im organisatorischen Ablauf von Projekten, die durch fünf Phasen gekennzeichnet sind: Machbarkeits-Studie Kick-off Verfeinerung Evaluierung Wartung Dabei sind die Phasen Verfeinerung und Evaluierung iterativ angelegt. Parallelen zu klassischen Software-Entwicklungs-Modellen sind hierbei offensichtlich. Diese Parallelen zum Software Engineering sind dabei keineswegs weit hergeholt, sondern in den meisten Fällen mit nur geringen Anpassungen direkt für Ontologie-Methodologien anwendbar. Es empfiehlt sich also grundsätzlich, bekannte und bewährte Methoden aus dem Software Engineering für das Ontologie Design anzuwenden sei es nun durch die Nutzung von dedizierten Methodologien wie UPON oder Methontology oder einfach durch die individuelle Übertragung von bewährten Praktiken, soweit sie im Ontology Engineering nützlich sein können Kollaborative Methodologien Neben der Anlehnung an Techniken des Software Engineering liegt ein weiterer wesentlicher Aspekt aktueller Methodologien in der Betonung des kollaborativen Ansatzes.

118 114 B. Gleich Bei genauerer Betrachtung wird schnell klar, dass Ontologien anders als klassische Software-Systeme eine noch stärkere Interaktion der Beteiligten erfordern, da eine Arbeitsteilung im Ontologie Design nicht einfach durch die Aufteilung in verschiedene Module realisiert werden kann: Insbesondere muss auch die vertikale Konsistenz gewährleistet werden, etwa durch die Verwendung einer gemeinsamen Basis-Ontologie. Genau diesen Ansatz verfolgt die Methodologie DOGMA-MESS (Designing Ontology-Grounded Methods and Applications A Meaning Evolution Support System) [6]: Ontologien werden dabei auf mehreren verschiedenen Ebenen verwendet: Es gibt eine permanente Meta-Ontologie, die Begriffe wie Objekt, Prozess oder Akteur definiert. Diese wird durch die Upper Common Ontology verfeinert, in welcher ein einzelner Domain-Experte für die gesamte Organisation geltende Ableitungen von der Meta-Ontologie vornimmt. Diese Ontologie wird dann von mehreren verschiedenen Domain-Experten wiederum zu einer Lower Common Ontology verfeinert, in der dann schließlich die konkreten und Abteilungs-spezifischen Konzepte und Sachverhalte modelliert werden. So kann sichergestellt werden, dass parallele Entwicklungen von verschiedenen Arbeitsgruppen automatisch ein gewisses Maß an Konsistenz aufweisen, da sie auf einer gemeinsamen Grundlage beruhen. Dabei ist zu erwähnen, dass für jede Ontologie jeweils im Wesentlichen ein Experte zuständig ist; die Zusammenarbeit findet also vertikal und nicht horizontal oder Ontologie-intern statt. So werden Reibungsverluste vermieden und die Entwicklung von konsistenten Ontologien erleichtert. Eine ähnliche Struktur beschreibt auch die Methodologie DILIGENT (DIstributed, Loosely-controlled and evolving Engineering of ontologies) [20], die fünf Phasen beinhaltet: 1. Entwicklung (build) 2. Lokale Anpassung (local adaption) 3. Analyse (analysis) 4. Bereinigung (revision) 5. Lokale Überarbeitung (local update) Zu Beginn entwickelt eine Gruppe von Domain-Experten, Anwendern und Ontologie-Entwicklern eine erste Entwurfsversion der jeweiligen Ontologie. Im nächsten Schritt sind die Anwender frei, die initiale Ontologie für ihren eigenen Bedarf anzupassen und zu verändern. Daraus entstehen nun verschiedene und in der Regel auch widersprüchliche lokale Ontologien, die von einem Ausschuss mit Vertretern aller beteiligten Parteien regelmäßig analysiert und bereinigt werden, so dass sich die lokal angepassten Ontologien nicht zu weit auseinander entwickeln. Ist die Bereinigung durch den Ausschuss erfolgt, müssen die Anwender ihre lokalen Kopien soweit überarbeiten, dass die Konsistenz zur bereinigten Version weitestgehend wiederhergestellt wird. Es zeigt sich also, dass eine pragmatische Ontologie-Methodologie ein dediziertes Change Management erfordert. Dabei spielt es natürlich eine große Rolle, wie die Beteiligten ihre Änderungswünsche kommunizieren bzw. insgesamt

119 Ontologie-Methodologien und Ontologie Design 115 miteinander interagieren. Diese Perspektive ist auch kennzeichnend für die Methodologie HCOME (Human-Centered Ontology Engineering Methodology) [14]. Dort wird explizit zwischen privaten und gemeinsamen Phasen des Ontology Engineering entschieden. Beispielsweise wird die Spezifikation grundsätzlich gemeinsam durchgeführt, während die Konzeptualisierung ganz überwiegend in Einzelarbeit erfolgt. Die Details von HCOME können auch aus Abbildung 3 entnommen werden. Abbildung 3. Die Verteilung von privaten und gemeinsamen Aktivitäten in HCOME Insgesamt liefern die geschilderten kollaborativen Ansätze wertvolle Anregungen für die Entwicklung von umfangreichen und praktisch anwendbaren Ontologien. Ein semantisches Web kann nur entstehen, wenn eine möglichst große Anzahl von Beteiligten im Ontology Engineering vernetzt wird, so dass statt vieler inkompatibler Ontologien wenige möglichst vereinbare Ontologien entstehen können. Die geschilderten Methodologien rücken dieses Ziel zumindest etwas näher. 3.5 Vergleich und Bestandsaufnahme Anhand der geschilderten Methodologien lässt sich sehr gut die wissenschaftliche Entwicklung im Bereich Ontology Engineering nachvollziehen: Waren die ersten beiden Beispiele (Uschold/King und Grüninger/Fox) noch sehr rudimentäre Ansätze, die heute nur noch in Ausschnitten Anwendung finden, haben die

120 116 B. Gleich nachfolgenden Methodologien Methontology und Ontology Development 101 bereits einen durchaus ausgereiften Stand erreicht, der im Folgenden durch Methoden wie DILIGENT, HCOME, DOGMA oder UPON nur noch weiter differenziert und verfeinert wird. Dem entsprechend ist auch der Nutzen für konkrete Anwendungen zu sehen: Während Methontology und Ontology Development 101 sich als Universalwerkzeug für die verschiedensten Anwendungen eignen, dabei aber kollaborative Ansätze nicht einbeziehen, sind DILIGENT, HCOME und DOGMA dann empfehlenswert, wenn das Ontology Design in nennenswertem Maßstab mit vielen verschiedenen Beteiligten durchgeführt wird. Ebenso ist der Ansatz von UPON besonders für große Ontologie-Projekte interessant, an denen eine erhebliche Anzahl an Mitarbeitern dauerhaft beschäftigt ist. Die nächste große Herausforderung für Ontologie-Methodologien wird darin bestehen, die in der Theorie bereits sehr ausgereiften Techniken auch im praktischen Umfeld über rein akademische Experimente oder Feldstudien hinaus zu erproben. 4 Design Patterns Die vollständig manuelle Entwicklung von Ontologien ist heute nicht mehr praktikabel, weshalb Methoden für die effiziente semi-automatische Erstellung benötigt werden. Ontologie Design Patterns (ODPs) spielen dabei eine wichtige Rolle: Patterns have proved to be a fruitful way to handle the problem of reuse. [3] Grundsätzlich bezeichnen ODPs eine Reihe von Design-Richtlinien: OD- Ps name, abstract and identify ontological design structures, individual terms, composed larger expressions, and related semantic contexts. [22] Um die Vorteile von Design Patterns für Ontologien im praktischen Einsatz nutzen zu können, ist angesichts der wachsenden Vielfalt eine Klassifikation von Ontology Design Patterns sehr hilfreich. Bisher sind ODPs weitgehend auf bestimmte Spezialgebiete ausgerichtet. [3] schlägt eine allgemeine Klassifikation von Patterns nach verschiedenen Abstraktions- Ebenen vor, die auch in Abbildung 4 illustriert sind: Application Patterns Ontology Application Patterns beschreiben allgemeine Vorgehensweisen, wie die jeweilige Ontologie zu verwenden ist, insbesondere was ihren Zweck, ihren Kontext und ihre Schnittstellen anbelangt. Architecture Patterns Ontology Architecture Patterns sollen dagegen helfen, die grobe Struktur von Ontologien zu entwickeln. Insbesondere geht es hier um die Art und Weise der Partitionierung großer und komplexer Ontologien. Design Patterns Klassische Ontology Design Patterns beschreiben ein allgemeines und wiederholtes Konstrukt in Ontologien. Durch ihre hohe Spezifität können sie auch in der automatischen oder semi-automatischen Erstellung verwendet werden. Semantic Patterns Semantic Patterns dienen zur sprachunabhängigen Beschreibung bestimmter Konzepte (beispielsweise durch Prädikatenlogik).

121 Ontologie-Methodologien und Ontologie Design 117 Syntactic Patterns Syntactic Patterns beziehen sich auf die Art und Weise der syntaktischen Notation von Ontologien. Abbildung 4. Die Hierarchie von ODPs nach Blomqvist 4.1 Design Patterns aus der Molekularbiologie Eines der wichtigsten Anwendungsgebiete von ODPs ist die Molekularbiologie, wo schon sehr lange mit umfangreichen Ontologien gearbeitet wird [22]. Dort werden insgesamt sieben verschiedene grundlegende Design Patterns vorgeschlagen, die ganz überwiegend so abstrakt sind, dass sie ohne Weiteres in anderen Fachgebieten angewendet werden können: Definition-Encapsulation Dieses ODP erleichtert den Umgang mit verschiedenen Definitionen des selben Begriffes. Anstatt jede Definition einzeln zu

122 118 B. Gleich modellieren (und damit die Ontologie sehr unübersichtlich zu machen), können verschiedene Definitionen durch ein Interface gekapselt werden, so dass die Benutzer leichter und strukturierter die passende Definition auswählen können. Expression-Composer Häufig gibt es komplexe Ausdrücke, die sich aus mehreren einzelnen Komponenten zusammensetzen in der Molekularbiologie betrifft dies insbesondere die Namen von komplexen Molekülen. Diese können über einen Organizer und einen ExpressionComposer aus den einzelnen Elementen zusammengesetzt werden, womit diese nur einmal abgebildet werden müssen. ChainOfExpressions Hier geht es darum, dass verschiedene Konzepte einen bestimmten Kontext erfüllen können. Dieser Sachverhalt lässt sich durch ein Interface Expression abbilden, das eine Kette von ConcreteExpressions enthält. Terminological Hierarchy Es ist gerade in Ontologien üblich, umfangreiche baumartige Begriffs-Hierarchien aufzubauen. Diese bestehen aus (primitiven) Blättern und (zusammengesetzten) Knoten. Damit der Nutzer bei der Anwendung nicht zwischen diesen beiden Fällen unterscheiden muss, werden diese Eigenschaften hinter TreeComponents und dem TreeComposer gekapselt. Update-Dependencies Jede lebendige Ontologie erfährt regelmäßige Änderungen und Verbesserungen. Damit diese nicht die Konsistenz gefährden, kann ein Dependency-Updater eingerichtet werden, der benachrichtigt wird, wenn ein ihm zugeordnetes Element verändert wird und daraufhin die notwendigen Änderungen durchführt. Interaction-Hider In vielen Fällen verletzten Ontologien die Anforderung der möglichst geringen Kopplung. Dann bietet es sich an, die Interaktionen einer terminologischen Gruppe hinter einem InteractionHider zu kapseln. So kann eine Gruppe von Konzepten geändert werden, ohne dass unkontrollierbare Auswirkungen auf einen ganz anderen Teil der Ontologie auftreten können. Terminology-Organizer Gerade in der Chemie gibt es eine umfangreiche Nomenklatur, in der einzelne Wortbausteine für bestimmte Stoffe stehen. Modelliert man komplette Moleküle, ist es möglich, einen Organizer zu modellieren, der den den endgültigen Begriffsnamen aus den einzelnen enthaltenen Konzepten zusammensetzt. Obwohl dieser Ansatz sehr häufig zitiert wird, finden sich dennoch kaum direkte Weiterentwicklungen. Allerdings gibt es gegenwärtig wieder zunehmendes Interesse am Thema Ontologie Design Patterns, insbesondere im Rahmen des Semantic Web. 4.2 Design Patterns im Semantic Web Insbesondere von Aldo Gangemi [8] stammen wertvolle Anregungen zum Einsatz von Design Patterns im Semantic Web. An erster Stelle ist hier ein Notations- Ansatz für ODPs zu nennen, der sich an dem für Patterns im Software Engineering orientiert und aus folgenden Slots besteht:

123 Ontologie-Methodologien und Ontologie Design 119 allgemeiner Sachverhalt beispielhafter Anwendungsfall Notation bzw. Legende Herangehensweise (ggf. mit Alternativen) Bemerkungen OWL-Code Damit lassen sich nun eine Reihe von ODPs beschreiben, wobei diese hier aus Platzgründen nur informell beschrieben werden sollen [8, 9]. Die hervorgehobenen Begriffe stehen dabei für ontologische Konzepte. Menge-Element Entspricht etwa einer 1-n-Beziehung: Mehrere Instanzen eines Konzepts sind Bestandteil der Instanz eines Oberkonzepts. Teilnahme Objekte (z.b. Personen) nehmen an Ereignissen (z.b. Veranstaltungen) teil. Diese Teilnahme hat einen Zeitindex und eine Dauer. Vertrag-Umsetzung In einem Vertrag einigen sich in der Regel mehrere Parteien auf bestimmte Bedingungen, die einen Rechtsgegenstand betreffen. Die Umsetzung des Vertrages erfordert dabei bestimmte Handlungen. Plan-Ausführung Ein Plan entspringt einer bestimmten Situation und hat ein klar definiertes Ziel. Zu seiner Ausführung sind Aufgaben und Rollen notwendig. 4.3 Design Patterns im praktischen Einsatz von OWL Neben den erwähnten, eher akademischen Patterns gibt es noch einige sehr praktische Probleme im Ontologie-Design, die durch einfache ODPs gelöst werden können[21]: Listing 7.1. Attribute in OWL <owl:onproperty> <owl:functionalproperty r d f : I D=" h a s S p i c i n e s s " /> </ owl:onproperty>... <o w l : C l a s s r d f : I D=" S p i c i n e s s "> <r d f s : s u b C l a s s O f> <o w l : C l a s s r d f : a b o u t="#v a l u e P a r t i t i o n " /> </ r d f s : s u b C l a s s O f> <rdfs:comment xml:lang=" en ">A V a l u e P a r t i t i o n that d e s c r i b e s only v a l u e s from Hot, Medium or Mild. </ rdfs: comment> <o w l : e q u i v a l e n t C l a s s> <o w l : C l a s s> <owl:unionof rdf:parsetype=" C o l l e c t i o n "> <o w l : C l a s s r d f : a b o u t="#hot " /> <o w l : C l a s s r d f : I D="Medium" /> <o w l : C l a s s r d f : I D=" Mild " />

124 120 B. Gleich </ owl:unionof> </ o w l : C l a s s> </ o w l : e q u i v a l e n t C l a s s> </ o w l : C l a s s>... <owl:functionalproperty r d f : a b o u t="#h a s S p i c i n e s s "> <r d f s : r a n g e r d f : r e s o u r c e="#s p i c i n e s s " /> <rdfs:comment xml:lang=" en ">A property to be used with the V a l u e P a r t i t i o n S p i c i n e s s.</ rdfs:comment> <r d f : t y p e r d f : r e s o u r c e=" h t t p : //www. w3. org /2002/07/ owl# ObjectProperty " /> </ owl:functionalproperty> Enum-Attribute in OWL In OWL gibt es keinen Unterschied zwischen einer Relation und einem Attribut. Um dennoch eine klare Semantik zu gewährleisten, empfiehlt sich die Anwendung eines Patterns: Wie in Listing 7.1 beschrieben, wird eine funktionale Eigenschaft has[attributname] angelegt. Zusätzlich wird zur Klasse ValueType eine neue Unterklasse [Attributname]ValueType angelegt. Dieser werden nun die gewünschten Werte als Unterklassen zugeordnet. Schließlich wird der Wertebereich der anfangs definierten Eigenschaft auf [Attributname]ValueType gesetzt. Entwirren von Hierarchien Sehr häufig entstehen in der Anlage von hierarchischen Ontologien keine strikten Bäume, sondern Überschneidungen der Form, dass einzelne Blätter zu mehreren verschiedenen Vaterknoten gehören. Um dieses Problem zu lösen müssen alle überzähligen Relationen durch value types ersetzt werden. Dadurch kann die Zugehörigkeit zu mehreren Vaterknoten durch die Zugehörigkeit zu einem dem value type entsprechenden Knoten abgebildet werden. 4.4 Bewertung OPDs sind wie beschrieben eine wertvolle Technik des Ontologie Design. Allerdings sind Patterns in der Regel das Resultat der umfangreichen und regelmäßigen Anwendung bestimmter Techniken. Dieser Sachverhalt ist im Ontologie Design bisher eher die Ausnahme: Abgesehen von der Molekularbiologie sind Ontologien noch in nahezu allen anderen Bereichen ein sehr junges Forschungsfeld. Zwar können auch dort schon einzelne Patterns identifiziert werden, jedoch sind diese nur in den seltensten Fällen Ergebnis umfangreicher praktischer Anwendung, sondern vielmehr das Resultat von überwiegend akademischen Überlegungen. Das Forschungsfeld der ODPs ist also noch stark auf umfassende praktische Erfahrungen angewiesen, mit deren Hilfe in den nächsten Jahren noch nennenswerte Fortschritte erzielt werden können.

125 5 Praktische Herausforderungen Ontologie-Methodologien und Ontologie Design Die Einschränkungen OWL als Ontologie-Sprache OWL steht für Web Ontology Language und ist ein Standard des W3C [24], der speziell für die automatisierte Verarbeitung von Ontologien ausgelegt ist. OWL besteht aus drei Untersprachen mit jeweils steigender Ausdrucksmächtigkeit: OWL Lite, OWL DL und OWL Full. Im Vergleich zu RDF werden in OWL zusätzliche Sprachkonstrukte eingeführt, mit denen Eigenschaften wie etwa Disjunktheit oder Äquivalenz von Klassen oder Kardinalitäten notiert werden können. Allerdings zeichnen sich gerade OWL Lite und OWL DL auch durch die dort gemachten Einschränkungen aus. So sind bei OWL Lite nur die Kardinalitäten 0 und 1 erlaubt. Dadurch wird eine geringe Komplexität erreicht, die die automatische Verarbeitung deutlich erleichtert. OWL DL (DL steht für Description Logic) stellt hier eine Kompromiss- Lösung dar: Es wird genau die Ausdrucksstärke unterstützt, die noch vollständig entscheidbar ist. Dies geschieht durch die Aufstellung von Bedingungen für die Verwendung der einzelnen Sprachkonstrukte. OWL Full besitzt dagegen keine solchen Einschränkungen, womit jedoch die Entscheidbarkeit nicht mehr gewährleistet ist. Für automatisierte Verarbeitung ist OWL Full also trotz oder gerade wegen seiner großen Ausdrucksmächtigkeit ungeeignet. Grundsätzlich findet also immer ein Austausch zwischen Ausdrucksmächtigkeit und Entscheidbarkeit statt eines der wichtigsten grundlegenden Probleme des Semantic Web. Dennoch konnten mit der Sprachversion 1.1 noch einige Optimierungen an OWL vorgenommen werden [25]. Hier sind z.b. reflexive, irreflexive, symmetrische und asymmetrische Properties möglich. Ebenso ist es möglich, Kardinalitäten im Bezug auf bestimmte Konzepte exakt einzuschränken (qualified cardinality restrictions). Ebenso sind in OWL 1.1 benutzerspezifische Datentypen möglich, die sich an den XML Schema Datentypen orientieren, womit in einer Ontologie neue Datentypen definiert werden können. 5.2 Auf dem Weg zum Semantic Web Das Semantic Web ist nach wie vor eher eine Vision als eine konkrete Aufgabenstellung. Das gilt insbesondere für die häufige Vorstellung, das Semantic Web würde das gegenwärtige World Wide Web vollständig ablösen. Dass dies aktuell kaum realistisch ist, wird schnell ersichtlich, wenn man betrachtet, wie neue Informationen im Internet veröffentlicht werden: Es handelt sich in den meisten Fällen um natürlich-sprachlichen Text, der nicht semantisch annotiert ist. Sollte das Internet als Ganzes zu einem Semantischen Web werden, müssten alle Personen, die bisher Inhalte veröffentlichen, diese semantisch annotieren, was zumindest mit den heutigen Technologien kaum denkbar sind. Eine wesentliche Vorbedingung, die einen breiten Einsatz von semantischer Annotation überhaupt möglich machen könnte, ist die weitere Entwicklung und Ausdifferenzierung von Ontologien. Gerade mit der Entwicklung vieler kleiner

126 122 B. Gleich Ontologien, die konkrete und begrenzte fachliche Domänen abdecken, ist es denkbar, dass immer mehr Inhalte sukzessive semantisch angereichert werden eine Aufgabe, die dann ähnlich wie Programmierung oder Design an Semantik- Entwickler übergeben werden könnte. Damit diese Visionen jedoch zu Realität werden, ist es von entscheidender Bedeutung, ob sich konkrete Anwendungen für die Nutzer von semantischen Inhalten ergeben also im Web insbesondere ob sich semantische Suchmaschinen entwickeln, die dem Nutzer einen erkennbaren Mehrwert bringen. Das ist schon gegenwärtig beispielsweise bei Produktkatalogen denkbar, die momentan noch mit ad-hoc-methoden durchsucht werden. Abgesehen von der Vision des großen Semantischen Web gibt es schon heute viele kleinere Semantische Netze, die in bestimmten fachlichen Domänen bereits große Erfolge erzielen und intensiv genutzt werden. Dies ist beispielsweise in der Molekularbiologie der Fall und auch in anderen Bereichen wie etwa der Bibliographie, der Rechtswissenschaft oder bei Produkt-Katalogen gibt es vielversprechende Entwicklungen. 6 Zusammenfassung, Bewertung und Ausblick In dieser Arbeit wurden verschiedene Methoden und Techniken zur praktischen Erstellung von Ontologien behandelt. Während die beschrieben Methodologien bereits einen nennenswerten Reifegrad erreicht haben, sind Ontologie Design Patterns bisher noch in einem früheren Entwicklungs-Stadium. Dennoch sind beide Techniken sehr hilfreich beim Design von Ontologien und werden daher wohl zukünftig an Bedeutung zunehmen. Da Ontologien eine der Schlüsseltechnologien des Semantic Web darstellen, ist es zu erwarten, dass hier noch umfangreiche weitere Forschungsanstrengungen unternommen werden. Ontologie-Methodologien und Ontologie-Design sind also zwei Forschungsfelder, die auch zukünftig noch viele wertvolle Erkenntnisse versprechen und wesentlich zur Vision eines oder vieler semantischer Netze betragen. Literatur [1] K. Baclawski, M. K. Kokar, P. A. Kogut, L. Hart, J. Smith, W. S. Holmes III, J. Letkowski, and M. L. Aronson. Extending UML to support ontology engineering for the semantic Web. Lecture Notes in Computer Science, 2185:342+, [2] E. Blomqvist. State of the art: Patterns in ontology engineering, [3] E. Blomqvist and K. Sandkuhl. Patterns in ontology engineering: Classification of ontology patterns. In C. S. Chen, J. Filipe, I. Seruca, and J. Cordeiro, editors, ICEIS (3), pages , [4] O. Corcho, M. Fernández, A. Gómez-Pérez, and A. López-Cima. Building legal ontologies with methontology and webode. In R. Benjamins, P. Casanovas, J. Breuker, and A. Gangemi, editors, Law and the Semantic Web, number 3369 in LNAI, pages Springer-Verlag, 2005.

127 Ontologie-Methodologien und Ontologie Design 123 [5] O. Corcho, M. Fernández-López, and A. Gómez-Pérez. Methodologies, tools and languages for building ontologies: where is their meeting point? Data Knowl. Eng., 46(1):41 64, [6] A. de Moor, P. D. Leenheer, and R. Meersman. Dogma-mess: A meaning evolution support system for interorganizational ontology engineering. In H. Schärfe, P. Hitzler, and P. Øhrstrøm, editors, Proceedings of the 14th International Conference on Conceptual Structures (ICCS 2006), volume 4068 of Lecture Notes in Computer Science, pages Springer, [7] M. Fernández-López, A. Gómez-Pérez, and N. Juristo. Methontology: from ontological art towards ontological engineering. In Proc. Symposium on Ontological Engineering of AAAI, [8] A. Gangemi. Ontology design patterns for semantic web content. In International Semantic Web Conference, pages , [9] A. Gangemi. Ontology design patterns a primer, with applications and and perspectives abgerufen am [10] M. Grüninger and M. Fox. The role of competency questions in enterprise engineering, [11] R. Grønmo, M. C. Jaeger, and H. Hoff. Transformations between UML and OWL-S. In A. Hartman and D. Kreische, editors, Model Driven Architecture Foundations and Applications: First European Conference (ECMDA-FA 05), volume 3748 of LNCS, pages , Nuremberg, Germany, Nov Springer Verlag. [12] T. R. Gruber. Towards Principles for the Design of Ontologies Used for Knowledge Sharing. In N. Guarino and R. Poli, editors, Formal Ontology in Conceptual Analysis and Knowledge Representation, Deventer, The Netherlands, Kluwer Academic Publishers. [13] G. Guizzardi, G. Wagner, and H. Herre. On the foundations of uml as an ontology representation language. In EKAW, pages 47 62, [14] K. Kotis, G. A. Vouros, and J. P. Alonso. Hcome: A tool-supported methodology for engineering living ontologies. In C. Bussler, V. Tannen, and I. Fundulaki, editors, Semantic Web and Databases. Second International Workshop - SWDB 2004, volume 3372 of LNCS, pages , Berlin Heidelberg, Germany, August Springer-Verlag. [15] M. López. Overview of the methodologies for building ontologies, [16] M. F. López, A. Gómez-Pérez, J. P. Sierra, and A. P. Sierra. Building a chemical ontology using methontology and the ontology design environment. IEEE Intelligent Systems, 14(1):37 46, [17] M. K. M. Uschold. Towards a methodology for building ontologies, [18] A. D. Nicola, M. Missikoff, and R. Navigli. A proposal for a unified process for ontology building: Upon. In DEXA, pages , [19] N. F. Noy and D. L. Mcguiness. Ontology development 101: A guide to creating your first ontology. Technical report, Stanford Knowledge Systems Laboratory, March [20] H. S. Pinto, S. Staab, and C. Tempich. Diligent: Towards a fine-grained methodology for distributed, loosely-controlled and evolving engineering of ontologies. In R. L. de Mántaras and L. Saitta, editors, ECAI, pages IOS Press, [21] A. L. Rector, N. Drummond, M. Horridge, J. Rogers, H. Knublauch, R. Stevens, H. Wang, and C. Wroe. Owl pizzas: Practical experience of teaching owl-dl: Common errors & common patterns. In E. Motta, N. Shadbolt, A. Stutt, and N. Gibbins, editors, EKAW, volume 3257 of Lecture Notes in Computer Science, pages Springer, 2004.

128 124 B. Gleich [22] J. R. Reich. Onthological design patternsfor the integration of molecular biological information. In German Conference on Bioinformatics, pages , [23] S. Staab, R. Studer, H.-P. Schnurr, and Y. Sure. Knowledge processes and ontologies. IEEE Intelligent Systems, 16(1):26 34, [24] W3C. Owl web ontology language overview, [abgerufen am ]. [25] W3C. Owl 1.1 web ontology language overview, [abgerufen am ].

129 Ontology Mapping Michael Buthut Universität Augsburg Zusammenfassung Ontologien sind ein wichtiger Bestandteil der Vision des Semantic Web, mit der die Informationen im WWW nicht nur menschenlesbar, sondern maschinenlesbar werden sollen. Um eine Wissensbasis zu erweitern muss eine Ontologie mit einer anderen Ontologie verknüpft werden. Oftmals besitzen Ontologien nicht exakt dieselbe Domäne bzw. sie besitzen eine unterschiedliche Sichtweise auf die Domäne, dadurch kann es zu Inkonsistenz des gefolgerten Wissens kommen. Die Gründe dafür werden dargestellt und danach werden zwei Ansätze vorgestellt, wie dennoch zwei Ontologien miteinander verknüpft werden können. Im letzten Kapitel wird ein Framework vorgestellt mit dem sich verschiedene Ontology Mapping Ansätze einheitlich vergleichen lassen. 1 Einleitung Heutzutage ist es selbstversändlich Wissen über elektronische Medien zu verbreiten oder es sich anzueignen. Allerdings ist es oftmals schwer an das benötigte Wissen zu gelangen. Suchmaschinen nähern sich schwer dem subjektivem Optimum der Anfrage. Tim Berners-Lee, der Erfinder des WWW, entwurf deshalb die Vision des Semantic Web [1]. Das in elektronischen Medien hinterlegte Wissen sollte nicht mehr nur von Menschen lesbar und interpretierbar sein, sondern maschinenlesbar werden. Dadurch müsste nicht mehr gesucht werden, da alles Wissen semantisch erfasst und verlinkt wäre. Probleme stellen sich dabei, wenn zwei Wissensbasen miteinander verknüpft werden sollen die nicht dieselbe Sichtweise auf eine Domäne haben. Bei einer derartigen Verknüpfung darf diese keine Inkonsistenzen und damit falsche Annahmen folgern. In dieser Arbeit wird nach einer Einführung auf zwei unterschiedliche Ansätze eingegangen, wie Ontologien, trotz unterschiedlicher Domäne, miteinander verknüpft werden. Anschließend werden zwei Konzepte (C-OWL, OWL-DL) zum Austausch der Wissensbasis und deren formale Grundlagen näher behandelt und mit Beispielen illustriert. Nach Erarbeitung der beiden Konzepte wird am Ende noch auf einen Vergleich verschiedener Ansätze im Ontology Mapping eingegangen. 1.1 Ontologien und OWL Semantische Modelle vereinen in sich die Fähigkeit eine eindeutige Bedeutung jedem Informationselement explizit zu zuordnen. Damit dies erreicht werden kann, muss ein semantisches Modell drei Anforderungen erfüllen [5].

130 126 M. Buthut Gemeinsame Begrifflichkeit Die Bedeutung von Informationen kann nur unterschieden werden, wenn die beteiligten Systeme die gleiche Sprache sprechen. Jedes Einzelteil erhält dabei einen eindeutigen Namen (Symbol). Da unterschiedliche Anwendungsbereiche aber auch unterschiedliche Sichtweisen besitzen, können die Begriffe variieren. Beziehungen zwischen Dingen Eine eindeutige Bennenung der Informationsteile ist aber nicht ausreichend. Eine explizite Semantik ensteht erst mit dem Verständnis über deren Zusammenhänge. Die Beziehungen werden dabei als Rollen eines Symbols repräsentiert. mathematisch fundierte Semantik Mathematische Korrektheit ist darüber hinaus auch ein wichtiger Bestandteil semantischer Modell. Erst dadurch wird eine eindeutige Interpretation der Konstrukte möglich. Unter einer Ontologie versteht man Modelle die alle drei obige Eigenschaften besitzen. Sie dienen der Wissensrepräsentation eines formal definierten Systems von Begriffen und Relationen. Man bildet Informationen und deren Zusammenhang ab. Aber nicht nur deren Zusammenhang wird damit repräsentiert, sondern sie enthalten zusätzlich Inferenz- und Integritätsregeln. Mit diesen Regeln können aus einer Ontologie heraus Schlüsse gefolgert werden und deren Gültigkeit gewährleistet werden. Abbildung 1. Beispiel einer Ontologie [5] In Abbildung 1 wird eine Beispielontologie grafisch dargestellt. Beispielsweise enthält die Ontologie ein Konzept Person. Peter ist nach dieser Darstellung eine Person. Personen die Artikel geschrieben haben sind Autoren und damit wiederum Personen. hat-geschrieben ist dabei eine Beziehung zwischen einzelnen Elementen. Alex bildet damit eine Instanz des Konzeptes Autor und hat Artikel1 geschrieben. Automatisch könnte bei der Beispielontologie das Wissen abgeleitet werden, dass hat-geschrieben das Inverse zu hat-autor ist. Um eine solches Wissen automatisch ableiten zu können muss die Bedeutung der verwendeten

131 Ontology Mapping 127 Symbole mathematisch präzise formuliert sein. Eine dafür entwickelte Sprache ist OWL. Unter OWL versteht man die Web Ontology Language, eine Sprache mit der sich Ontologien anhand einer formalen Beschreibungssprache erstellen, veröffentlichen und verteilen lassen. OWL ist eine Spezifikation des W3C, dem Gremium zur Standardisierung der das World Wide Web betreffenden Techniken [8]. OWL besteht aus drei Untersprachen (OWL Lite, OWL DL, OWL Full) mit zunehmendem Abstraktionsgrad, so dass verschiedene Nutzergruppen, je nach Abstraktionsgrad, damit arbeiten können. In dieser Arbeit werden wir uns auf OWL-DL beschränken. Das Kürzel DL steht für description logic und zeigt damit den Grundgedanken des Ansatzes an. Die OWL DL zugrunde liegende Beschreibungslogik ist SHOIN (D), was wiederum eine entscheidbare Untermenge der Prädikatenlogik erster Stufe darstellt. 2 Ontology Mapping Nach der Vision des Semantic Web werden Ontologien eingesetzt um die semantische Beziehung von Objekten widerzuspiegeln. Es soll beispielsweise möglich sein Wissen über eine bestimmte Domäne um Wissen einer anderen Domäne zu erweitern. 2.1 Global as View vs. Local as View Sollen zwei Parteien miteinander kommunizieren können, müssen beide die gleiche Repräsentation für eine Ontologie haben. Oftmals ist dies aber nur der Idealfall, dass beide Parteien mit der Repräsentation der Ontologien übereinstimmen. Deshalb werden Ontologien gemappt um, die im Normalfall unterschiedlichen, Wissensbasen miteinander zu verbinden. Global as View (GAV) bzw. Local as View (LAV) sind zwei verschiedene Ansätze bzw. Sichtweisen im Ontology Mapping. Definition Global-as-View (GAV): It is assumed that both ontologies describe exactly the same set of objects. As a result, semantic relations are interpreted in the same way as axioms in the ontologies. There are special cases of this assumption, where one ontology is regarded as a global schema and describes the set of all objects, other ontologies are assumed to describe subsets of these objects. [2] Definition Local-as-View (LAV): It is not assumed that ontologies describe the same set of objects. This means that mappings and ontology axioms normally have different semantics. There are variations of this assumption in the sense that sometimes it is assumed that the sets of objects are completely disjoint and sometimes they are assumed to overlap each other. [2]

132 128 M. Buthut Ein globales Schema vereint dabei alle Objekte aller beteiligten Ontologien. Eine bestimmte Ontologie bildet dann eine Untermenge des globalen Schemas. Ein globales Schema ist leichter zu verwenden, aber es beherbergt den Nachteil, dass bei sich ändernden oder wachsenden Datenquellen bzw. Ontologien jedesmal ein neues globales Schema erstellt werden muss. Gegenteilig dazu verhält sich LAV. Das ganze wird genau anders herum betrachtet und so werden alle Konzepte der Datenquellen mit Begriffen des zu integrierenden Schemas erzeugt. An dieser Stelle erschwert man zwar das ausführen von Anfragen, da dem System explizit bekannt gegeben werden muss wie er die Anfrage mappt. Aber dafür muss nun nicht mehr bei Änderungen der Datenquellen das zu integrierende Schema rekonstruriert werden, sondern nur die Mappings angepasst werden. Bei einer lokalen Sichtweise können Objekte disjunkt zu Objekten in der anderen Ontologie sein. Darüber hinaus können sich die Objekte auch in den Ontologien überlappen. Desweiteren gibt es eine Kombination beider Sichtweisen: Global-Local-as-View (GLAV). Allerdings ist im GLAV Ansatz das korrekte beantworten von Anfragen wenig erforscht, da der Ansatz auch leider alle Schwierigkeiten in sich vereint. Es hat sich in der Praxis bisher gezeigt, dass für Umgebungen in denen sich die Datenquellen oft ändern der LAV Ansatz besser geeigneter ist. 2.2 Formale Einführung in OWL Um nun die beiden Ansätze im Folgenden besser verstehen zu können, werden die formalen Grundlagen für OWL behandelt werden. Eine OWL Ontologie besteht aus Axiomen, Fakten und einer Referenz wie diese in andere Ontologien importiert werden kann. In dieser Arbeit wird sich auf OWL-DL beschränkt, da diese Sprache der SHOIQ(D) Logik entspricht. Eine OWL Ontology ist dann ein Paar i, O i, dabei ist i der Index einer Instanz von der Ontology O. Satz 1 Seien nun C,D,E,F Konzepte und r,s Rollen. Dann können nur folgende Konzepte in der Ontologie O i auftreten: C, i:c, C D, j:e, C (j:e), r.c D, (j:s).c (j:f) Dabei gehört jeder Ausdruck der ohne Index oder mit Index i in O i auftaucht zu der lokalen Sprache O i. Fremde Konzepte j i gehören zu der Sprache O j. Die Konzepte C und D in Satz 1 sind somit lokale Konzepte. Wohingegen E und F fremde Konzepte darstellen. Genauso verhält es sich bei den Rollen r und s. Das bedeutet nun aber das eine Ontologie nur die oben genannten Varianten enthält. Beispielsweise können Konzepte zusammengefügt oder eine Schnittmenge bilden. Ein OWL Space bildet dann eine Familie von Ontologien { i, O i } i I. i j ist die j-fremde Sprache von O i in der lokalen Sprache O j enthalten. Für einen derartigen OWL Space gibt es dann eine Interpretation I. Mit einer Interpretation können dann Ausdrücke auf Korrektheit geprüft werden. Die hier dargestellte Interpretation bildet dabei aber eine globale Sichtweise.

133 Ontology Mapping 129 Ein Mapping wird als das Bestehen einer sematischen Relation angesehen. Beispielsweise werden die beiden Relationen zwischen Ontologien häufig verwendet [3]: Equivalence ( ): Equivalence states that the connected elements represent the same aspect of the real world according to some equivalence criteria. A very strong form of equivalence is equality, if the connected elements represent exactly the same real world object. Containment (, ): Containment states that the element in one ontology represents a more specific aspect of the world than the element in the other ontology. Depending on which of the elements is more specific, the containment relation is defined in the one or in the other direction. 2.3 Beispiele für OWL Mapping und deren Grenzen Es werden nun drei Beispiele behandelt, um auf deren Grenzen beim normalen OWL Mapping einzugehen. Es gibt dabei drei Kategorien in denen das normale OWL Mapping an seine Grenzen stößt [6]: the directionality of information flow: we need to keep track of the source and the target ontology of a specific piece of information local domains: we need to give up the hypothesis that all ontologies are interpreted in a single global domain context mappings: we need to be able to state that two elements (concepts,roles, individuals) of two ontologies, though being (extensionally) different, are contextually related, for instance because they both refer to the same object in the world Beispiel 1 Angenommen zwei Ontologien O 1 und O 2 wollen zusammenarbeiten. O 2 ist dabei eine Erweiterung von O 1, somit importiert O 2 O 1 und fügt ein neues Axiom hinzu. Nun sollen die Axiome die zu O 2 hinzugefügt werden keine Auswirkungen auf O 1 haben. Nun seien A B und C D Axiome in O 1. O 2 dagegen enthält ein Axiom B C. Jetzt wollen wir, dass A D in O 2 aber nicht in O 1 gilt. In normalem OWL Mapping würde ein solches Beispiel nicht umsetzbar sein. Die Folgerung A D ist eine logische Konsequenz der Anweisungen, die im globalen OWL Space enthalten sind. Beide Ontologien würden also nun davon ausgehen, dass A D ist. Dies kann aber unter gewissen Umständen zu Fehlinterpretationen führen. Beispiel 2 Angenommen es gibt eine Ontologie O W CM die zur worldwide organization on car manufacturing gehört. Nun soll diese Ontologie eine standard Beschreibung eines Autos beinhalten. Car soll nun eine Instanz dieser Ontologie sein. Die Ontologie O W CM beinhaltet dabei zwei individuelle Konstanten Diesel und Petrol. Zusätzlich soll es noch folgendes Axiom geben:

134 130 M. Buthut Car ( 1) hasengine. {Diesel, P etrol} wobei Diesel Petrol Das bedeutet nun nichts anderes, als dass ein Auto nur einen Motor haben kann und dieser entweder ein Diesel oder ein Benziner ist. Nun will sich ein Fahrzeughersteller z.b. Ferrari seine O F errari mit der Ontologie O W CM verknüpfen. Dann könnte die Verknüpfung so aussehen: F errari (W CM : car ( 1) (W CM : hasengine). {F 23, F 23}) wobei F23 F34i Ein Ferrari kann dabei nur den Motor F23 oder F34i besitzen. Damit besteht nun aber der Fall, dass die Interpretation des OWL Spaces, der die beiden Ontologien beinhaltet, zu falschen Aussagen kommt. Denn (F 23) I F errari = (Diesel) I W CM oder analog mit F34i. Die Aussage ist damit aber falsch, da Ferrari nur Benziner also Petrol Motoren verbaut. Die Diversität der einzelnen Domänen der beiden Ontologien ist dafür verantwortlich. Beide Domänen besitzen einen anderen Abstraktionsgrad, so ist die Ontologie Ferrari präziser bei der Motorenbeschreibung als die Ontologie der WCM die nur nach Benzin oder Diesel unterscheidet. Beispiel 3 Nun sei O F iat eine Ontologie die Sachverhalte aus Sicht des Fahrzeugherstellers FIAT wiederspiegelt. Dagegen sei nun O Sale eine unabhängige Ontolgie die aus Sicht eines Verkäufers deklariert wurde. Beide enthalten nun ein Konzept Car, das aber sehr unterschiedlich ist und es damit keinen Sinn macht das Konzept des jeweils Anderen zu importieren. Somit gehören die Instanzen dieser Konzepte auch nicht zum jeweils anderen. Sollen diese beiden Ontologien nun verknüpft werden um evtl. einen Mehrwert aus der anderen Ontologie zu erzeugen, dann ist dies mit OWL nicht möglich. Denn für eine Instanz Sale : Car F iat : Car impliziert dies Car I Sale = Car I F iat Damit wären die beiden Interpretationen gleich, auch wenn sie das nicht möglich. Mit diesen Beispielen wurde verdeutlicht das OWL in vielen Szenarios Schwierigkeiten bereiten kann. Daher ist es nötig OWL zu erweitern. Es gibt verschiedene Ansätze und Verfahren um beispielsweise oben genannte Probleme zu lösen. In den folgenden Kapiteln werden zwei Verfahren für derartige Probleme vorgestellt. 2.4 C-OWL Schaut man sich die Funktionsweise von Ontologien und Context einmal näher an, dann fällt auf, dass sie eigentlich sehr konträre Verhaltensweisen aufweisen. Eine Ontologie ist ein gemeinsames und geteiltes Model der Domänen für alle beteiligten Parteien. Das heißt in anderen Worten, dass jeder die gleiche Sicht auf die Ontologie hat. Wohingegen Context ein lokales Modell ist, dass nicht geteilt wird und jede beteiligte Partei hat dabei ihre eigene Sicht auf die Daten.

135 Ontology Mapping Motivation Sowohl Context als auch Ontologien haben beide Stärken und Schwächen. Die Stärke von Ontologien ist es, dass eben genau diese gemeinsame und übereinstimmende Sicht auf die Daten vorhanden ist. Somit ist der automatische Austausch von Daten erst möglich. Aber dafür ist es teilweise schwer eine gemeinsame Sicht zu ermitteln. Bei Änderungen muss die gemeinsame Ontologie jedesmal neu erzeugt werden. Was eigentlich in einem dynamischen Umfeld, wie z.b. dem World Wide Web schwierig ist. Ein Context ist einfacher zu erstellen, da keine Übereinkunft mit den anderen beteiligten Partnern bestehen muss. Für den Datenaustausch sollte aber dennoch limitierte Übereinkunft bestehen. Dies muss aber auch nur für die relevanten Partner gelten. Der Nachteil dabei ist, dass es ein gemeinsames Mapping über die Elemente des Contexts geben muss, um kommunizieren zu können. Für C-OWL wird die Notation für eine Ontologie verwendet und um einige Erweiterungen ergänzt mit denen es möglich ist die Dinge zu modellieren bei denen eine Ontologie an Ihre Grenzen stößt [6] Formale Grundlagen von C-OWL und Beispiele Man modifiziert nun die Definition einer Interpretation in OWL. Dabei ist die Hauptidee, dass die globale Interpretation aufgesplittet wird. Dann besitzt jede Ontologie ihre eigene lokale Interpretation. Nach [6] wird dazu ein Hole definiert. Ein Hole (H) ist ein Paar aus einem nicht leeren Set und einer Funktion. Diese Funktion mappt jede Konstante von O i in ein Element der Domäne, jedes Konzept in der gesamten Domäne und jede Rolle. H erweitert also die Ontologie O i um eine angepasste Interpretation, die jedes Axiomenpaar verifiziert, dass widersprüchlich sein könnte. Zusätzlich muss aber die Erfüllbarkeit gewährleistet bleiben um später des Mapping überhaupt ausführen zu können. Eine OWL Interpretation mit Holes für einen OWL Space ist dann eine Familie lokaler Interpretationen von O i. Entweder ist es dabei eine Interpretation der Sprache L i auf die Domäne von i oder es ist ein Loch für L i auf der Domäne von i. Somit kann jede Interpretation um die lokale Interpretationsbeschreibung erweitert werden. Ontologien mit Löchern können sich in verschiedenen Ontologien auch verschieden verhalten. Deshalb können manche Axiome in einer Ontologie erfüllt sein, dafür aber in anderen evtl. nicht. Mit dieser Definition können wir nun untersuchen was mit Beispiel 1 passiert. Beispiel 4 Beispiel 1 in C-OWL: Nehmen wir eine Interpretation I = {I 1, I 2 } mit Holes an die wie folgt definiert ist: 1. Die Domäne von I 1 = {a, b, c, d}, die Interpretation sind wie folgt: A I1 = {a}, B I1 = {a, b}, C I1 = {c}, D I1 = {c, d} 2. Die Domäne von I 2 = {a, b, c, d} und I 2 = H 2, d.h. I 2 ist ein Loch I ist eine Interpretation für den OWL Space der O 1 und O 2 enthält da ja 1. I 1 = A B, I 1 = C D, und I 1 = A D 2. I 2 = 1 : A 1 : B, I 2 = 1 : B 1 : C, und I 2 = 1 : C 1 : D und I 2 ein Hole ist

136 132 M. Buthut Damit ist es nun möglich, dass die Interpretation O 2 erfüllt ohne dass in O 1 A D gefolgert wird. OWL geht von der Existenz einer einzigen geteilten Domäne aus. Mit anderen Worten gesagt, dass jede Ontologie Eigenschaften des ganzen Universums beschreibt. In den meisten Fällen ist dies aber nicht immer zutreffend, denn eine Ontologie die Autos beschreibt ist nicht dafür gedacht über Medizin zu sprechen. Die Idee in C-OWL ist es lokale Domänen zu schaffen, damit nicht Äpfel mit Birnen verglichen werden. Dabei können sich diese lokalen Domänen überlappen, so dass wir mit dem Fall umgehen können müssen, dass zwei Ontologien auf das selbe Objekt verweisen. Für die OWL Interpretation mit lokalen Domänen wird die Interpretation auf komplexe Konzepte, Rollen und Individuen erweitert. Aufzupassen gilt es wenn j-fremde Konzepte, Rollen und Individuen, die in O i verwendet werden, als ein Objekt interpretiert werden könnten das nicht in der lokalen Domäne von I i ist. Somit müssen alle fremden Konzepte, Rollen oder Individuen eingeschränkt werden [6]. Beispiel 5 Beispiel 2 in C-OWL: Sei nun I = {I W CM, I F errari } eine Interpretation des OWL Spaces der O W CM und O F errari enthält. Die Domäne von W CM enthält dabei zwei Konstanten d 1 und d 2. Diese Kostanten entsprechen den Interpretationen ob ein Auto mit Diesel bzw. Benzin fährt. Die Domäne F errari enthalte auch zwei Konstanten d 1 und d 3, die für F23 bzw. F34i stehen. Somit sei nun: (hasengine) I W CM = { c 1, d 1, c 2, d 2 } wobei c 1 und c 2 Auto Objekte in beiden Domänen sind. Dadurch kann verifiziert werden, dass die Axiome in Beispiel 2 von der Interpretation erfüllt werden und damit kein Ferrari einen Diesel Motor besitzt. Es stehen nun Konzepte, Rollen und Individuen einer Ontologie und deren Domäne lokal zur Verfügung, aber ein Context Mapping erlaubt es festzulegen, dass eine bestimmte Eigenschaft zwischen den Elementen zweier verschiedener Ontologien erhalten bleibt. In Beispiel 3 könnte so aufgebaut sein, dass die Klasse Car in der Ontologie O F iat die selben Autos enthält wie die Klasse Car von O Sale. Dies kann aber nicht mit lokalen Axiomen in der Ontology realisiert werden. Für die Notation von Context Mappings verwendet man Bridge Rules. Diese Rules bilden den Kern des C-OWL Ansatzes damit keine Inkonsistenzen beim Mapping erzeugt werden Bridge Rules Definition 2 Bridge Rules: Eine Bridge Rule von i zu j kann folgendermaßen formalisiert werden, i : x j:y, i:x j:y, i:x j:y, i:x j:y, i:x j : y, dabei können x bzw. y Konzepte, Individuen oder Rollen der Sprachen L i L j sein. und

137 Ontology Mapping 133 Wenn x und y z.b. Konzepte C und D sind dann bedeutet i : x j:y nichts anderes als das das i-lokale Konzept C spezifischer ist als j-lokale Konzept D. Analog dazu impliziert das D spezifischer als C ist, implziert das C und D disjunkt sind, * impliziert Kompatibilität von C und D und impliziert das C und D den gleichen Abstraktionsgrad besitzen. Abbildung 2 verdeutlicht die Anwendung der Bridge Rules und die passenden Mappings an einem grafischen Beispiel. Abbildung 2. Beispiel eines Mappings mit Bridge Rules von Wine zu Vino [6] Ein Mapping von zwei Ontologien ist damit eine Reihe von Bridge Rules zwischen diesen. Für einen OWL Space { i, O i } i I ist M ij ein Mapping von O i zu O j bestehend aus einer Reihe von Bridge Rules von O i zu O j für beliebige i,j. Ein Mapping ist richtungsgebunden, M ij ist nicht die Umkehrung des Mappings M ji. Die Gegenrichtung könnte dabei zum Beispiel die leere Menge liefern. Gleichzeitig ist zu beachten, dass die Importierung von O i in O j nicht das gleiche ist wie das Mapping von O i zu O j mit M ij. Die Informationen gehen zwar in beiden Fällen von i zu j, aber bei der Importierung kopiert O j die Informationen ohne Anpassung. Dagegen übersetzt O j, beim Mapping, die Semantik von O i in seine eigene lokale Semantik. Beispiel 6 Beispiel 3 und Beispiel 2 in C-OWL: Beide beschreiben dieselbe Sichtweise von zwei unterschiedlichen Sichtweisen, somit ist Sale : Car F IAT : Car Die Domänen Relation von O Sale zu O F IAT wäre dann r ij (Car) I Sale = (Car) I F IAT. Context Mappings können aber auch zur besseren Formalisierung von Beispiel 2 eingesetzt werden. Wenn festgelegt werden soll, dass F23 und F34i jeweils Benzin Motoren sind kann dies mit folgenden Bridge Rules formalisiert werden: W CM : P etrol F errari : F 23W CM : P etrol F errari : F 34i

138 134 M. Buthut Natürlich muss für eine C-OWL in der Praxis auch die Syntax angepasst werden. Deshalb besteht eine Context Ontologie aus einem Paar einer OWL Ontologie und einer Reihe von C-OWL Mappings, wobei jedes Mapping aus einer Reihe von Bridge Rules mit der selben Ziel Ontologie besteht. 2.5 DL safe rules In diesem Kapitel wird ein globaler Ansatz für ein Ontology Mapping vorgestellt mit dem heterogene Ontologien verknüpft werden sollen. Für weitere Details wird auf [4] verwiesen Motivation Um die Interoperabilität zwischen verschiedenen Anwendungen, die unterschiedliche Ontologien besitzen, gewährleisten zu könnnen, muss zuerst ein Mapping System formal definiert werden. Im vorherigen Kapitel wurde gezeigt wie C-OWL die Interoperabilität gewährleisten kann. Ein anderer Ansatz ist der OWL-DL safe rule Ansatz. Der grundlegende Gedanke dabei basiert auf deduktiven Datenbanksystemen. Dabei wurde Datalog, eine entscheidbare logische Regelsprache, die ursprünglich für solche Datenbanksysteme entwickelt wurde, mit OWL-DL kombiniert. Als Ergebnis entstand die Semantic Web Rule Language (SWRL). Man sieht das Mapping von OWL-DL Ontologien als eine Übereinstimmung zwischen Anfragen über Ontologien an. OWL bietet nur die Möglichkeit einfache Mappings zwischen den Elementen auszuführen. Im praktischen Einsatz wird aber oft eine komplexere Abfragestruktur als nur Äquivalenz und Zusammenfassung benötigt. Daher wird das Mapping zweier Ontologien mit einer konjunktiven Anfrage (Query) an eine Datenbank repräsentiert. Das Mapping selbst wird durch die Übereinstimmung dieser Queries ausgedrückt. Allerdings ist in der Kombination von OWL und SWRL logisches Schließen unentscheidbar. Um dennoch Entscheidbarkeit zu erhalten entwickelte man die Idee SWRL soweit einzuschränken, dass es entscheidbar wird. Dabei bilden die DL-safe Rules die notwendigen Einschränkungen. Der hier vorgestellte Ansatz verwendet dabei die globale Sichtweise (GAV) Grundlagen Um ein OWL-DL Mapping System einführen zu können müssen erst einige Grundlagen wiederholt werden. Zuerst muss der Begriff konjunktiver Queries über eine SHOIN (D) knowledge base (KB) eingeführt werden. Nach der Definition für konjunktive Queries [7] hat ein Atom die Form P (s 1,..., s n ) bzw. P (s). P kann dabei entweder eine Variable oder ein Individuum der KB sein. Ein Atom ist ein Ground-Atom wenn es keine Variablen enthält und ein DL-Atom wenn P ein SHOIN (D) Konzept bzw. eine abstrakte oder konkrete Rolle ist. Eine konjunktive Query über die KB wird dann als Q (x, y) geschrieben. Dabei repräsentieren x und y eine Reihe von non-distinguished Variablen (mit Existenzquantor gebunden). Definition 3 Eine konjunktive Query Q (x, y) ist dann DL-safe falls jede Variable, die in einem DL-Atom auftaucht, auch in einem Nicht-DL-Atom in Q (x, y) auftaucht.

139 Ontology Mapping 135 Eine Rolle einer SHOIN (D) KB hat desweiteren die Form H Q (x, y). H ist dabei ein Atom und Q (x, y) weiterhin die Query. Definition 4 Eine Rolle ist safe falls jede Variable von H auch in x auftaucht. Eine Rolle ist nur dann DL-safe falls Q (x, y) DL-safe ist. Mit anderen Worten ist eine Query oder eine Rolle dann DL-safe wenn sie sich auf explizit benannte Indviduen bezieht. Um nun automatisch eine Query in eine DL-safe Query zu transformieren wird für jedes α, das in der KB auftaucht, ein spezielles nicht DL Prädikat O (α) eingeführt [4]. Dieses Prädikat wird dann konjunktiv mit der Query verknüpft, um diese DL-safe zu machen. Viele Existenzquantoren sind aber unnötig und komplizieren die Query. Man kann eine Query oftmals vereinfachen und von unnötigen non-distinguished Variablen befreien. Dazu verwendet man die Query-Roll-Up Technik [4] um unnötige Variablen zu entfernen, ohne dabei einen Verlust der Semantik zu erleiden Tree-Like Query Parts Komplexere Queries weisen eine Baumstruktur mit einer Wurzel auf. Mit der Query-Roll-Up Technik ist es möglich unnötige Variablen zu eliminieren in dem die baumartigen Teile einer Query zu einem Konzept reduziert werden. Somit wird die spätere Transformation in DL-safe Queries erleichtert. Beispiel 7 Angenommen folgende konjunktive Query soll transformiert werden: y, z, w : R (x, y) A (y) S (y, z) B (z) T (y, w) C (w) Obige Query besitzt eine baumartige Struktur mit der Wurzel x. Die Existenzquantoren von z und w können dann zum ersten Auftreten von selbigen bewegt werden: y : R (x, y) A (y) [ z : S (y, z) B (z)] [ w : T (y, w) C (w)] Dies wiederum kann weiter transformiert werden: y : R (x, y) A (y) S.B (y) T.C (y) Nach erneutem Durchlauf erhält man mit Transformation für y: R. [A S.B T.C] (x) Wie man sieht könnten die überflüssigen Variablen y, z und w entfernt werden, indem sie in DL transformiert wurden. Mit dieser Vorgehensweis ist es möglich einen Algorithmus zu entwerfen mit dem die Anfragen automatisch von einem System umgeformt und anschließend die Antwort berechnet werden kann. Die Antwort kann dabei nur berechnet werden, falls DL-safety sichergestellt ist, ansonsten wäre die Beantwortung unentscheidbar.

140 136 M. Buthut Algorithmus 1 Algorithmus zur Beantwortung von Queries in einem Ontology Integration System: Vorraussetzung ist ein Integrationssystem IS und eine konjunktive Query Q (x, y) Roll-Up auf baumartige Teile von Q (x, y) Roll-Up auf baumartige Teile der Query Mappings in M Stoppe falls Q (x, y) oder einige Mappings von M nicht DL-safe sind Bilde das ganze als deduktives Datalog Programm (DD) ab Berechne die Antwort von Q (x, y) Die Query wird mit diesem Algorthmus, nach der Sicherstellung der DL-safety, in ein deduktives Datalog Programm abgebildet, da für Datalog effiziente Techniken für deren Ausführung bekannt sind [4] Beispiele Mit folgenden Beispielen sollen die angewandten Techniken noch einmal verdeutlicht werden. Für weitere Informationen und Details wird auf [4] verwiesen. Das Beispiel bezieht sich auf die gewünschte semantische Übereinstimmung zweier heterogener Ontologien. Beide Ontologien modellieren dabei eine Bibliotheks Domäne. Die Quellontologie S und die Zielontolgie T sind in 3 dargestellt. In der Quellontologie schreibt eine Person Publikationen. Die Publikationen können entweder Artikel oder Thesen sein. In der Zielontologie T besitzen Autoren Einträge. Ein Eintrag kann dabei ein Artikel, eine Masterarbeit oder eine Doktorarbeit sein. Sowohl Person als auch Autor besitzen einen Namen und Publikationen sowie Einträge besitzen einen Titel und ein Thema. Abbildung 3. Quell- und Zielontologie [4] Nun werden sechs verschiedene Mappings angewendet, um die beiden Ontologien miteinander zu verknüpfen. Dabei werden die unterschiedlichen Fälle sichtbar und es wird darauf eingangen wie diese mit safe rules abgebildet werden können. Die Mappings sind dazu in Abbildung 4 dargestellt. Das in Abbildung 5 dargestellte Klassendiagramm verdeutlicht den Zusammhang der Mappings aus Abbildung 4 und den Aufbau der Ontologie.

141 Ontology Mapping 137 Abbildung 4. Mappings von Quell- auf Zielontologie [4] Beispiel 8 Mapping m 1 : Das Mapping m 1 in Abbildung 4 bildet die Publikationen samt ihrem Titel auf die dazugehörigen Einträge der Zielontologie ab. Das sound Mapping lässt sich dann formal als folgende Aussage darstellen: x, y : t : Entry (x) t : title (x, y) s : P ublications (x) s : title (x, y) Dieses Mapping enthält dabei keine unbedeutenden Variablen in Q t,1, die zuerst entfernt werden müssten, und kann somit direkt übersetzt werden. Dennoch ist das Mapping nicht Dl-safe, da beide Variablen x und y nicht in nicht-dl Prädikaten in Q s,1 vorkommen. Durch die Bindung mit dem speziellen nicht-dl Prädikat O kann dieses Mapping aber DL-safe werden. Abbildung 5. Aufbau der Ontologien und der Beispielmappings [4]

142 138 M. Buthut x, y : t : Entry (x) t : title (x, y) s : P ublications (x) s : title (x, y) O (x) O (y) Beispiel 9 Mapping m 2 : Das Mapping m 2 bildet die Artikel der Quell Ontologie auf die der Zielontologie ab. Daraus ergibt sich direkt folgendes Konzept: s : Article t : Article Beispiel 10 Mapping m 3 : Das Mapping m 3 zeigt die Verwendung eines komplexen Konzepts in einem Konzept Mapping, dabei werden die Konzepte Thesis der Quellontologie auf die Vereinigung der Konzepte PhDThesis und MasterThesis abgebildet: s : T hesis (t : MasterT hesis t : P hdt hesis) Das verdeutlicht nun, dass es aufgrund der Ausdrucksstärke der Ontologiesprache es möglich ist Disjunktion in Mappings auszudrücken, obwohl die Query Sprache nur Konjunktionen erlaubt. Beispiel 11 Mapping m 4 : Mapping m 4 bildet die Eigenschaft Autor der Quellontologie auf die Zielontologie ab. Durch ein einfaches Rollen Mapping erhält man: s : author t : author Beispiel 12 Mapping m 5 : Mapping m 5 bildet die Personen die Autoren von Publikationen sind auf Autoren der Zielontologie ab. Für eine Query Q s,5 können wir nun die Query Roll-Up Technik verwenden. Die Query ist baumartig aufgebaut mit der charakterisierenden Variable x als Wurzel. Somit kann diese Query wiederum zu folgender, semantisch äquivalenten, Query transformiert werden: Q s,5 (c) : ( s : author.s : P erson) (x) Damit kann nun ein Konzept Mapping angegeben werden: s : author.s : P erson t : Author Vergleicht man nun dieses Mapping mit einem DL-safe Mapping, das man ohne Query Roll-Up erhält, fällt die Varietät beider Mappings auf. Das Mapping in Beispiel 13 bildet nur die Personen, deren Publikationen explizit in der Quellontologie benannt sind, auf die Autoren der Zielontologie ab. Dagegen benötigt Beispiel 12 nur die Existenz einer Publikation. Die Publikation muss dabei nicht explizit benannt sein. Beispiel 13 Mapping m 5 ohne Query Roll-Up: x : t : Author (x) s : P erson (x) s : author (y, x) O (x) O (y)

143 Ontology Mapping 139 Beispiel 14 Mapping m 6 : Mapping m 6 bildet das Topic einer Publikation auf einen Eintrag in der Zielontologie ab. Dabei ist zu beachten, dass Topic ein eigenes Konzept in der Quellontologie ist, wohingegen der Name des Themas in der Zielontolgie als Eigenschaft dargestellt wird. Deshalb ergibt sich folgende Aussage: x, z : t : Entry (x) t : subject (x, z) s : P ublication (x) s : isabout (x, y) s : name (y, z) Auch dieses Mapping ist nicht DL-safe, da weder Q s,6 noch Q t,6 baumartige Querys sind. Das Query Roll-Up kann hier also nicht angewendet werden. Um dennoch ein DL-safe Mapping zu erhalten werden wieder die Variablen x, y und z explizit an benamte Individuen gebunden: x, z : t : Entry (x) t : subject (x, z) s : P ublication (x) s : isabout (x, y) s : name (y, z) O (x) O (y) O (z) 3 Vergleich verschiedener Ontologie Mapping Ansätze In den letzten Abschnitten wurden zwei Ansätze für das Ontology Mapping vorgestellt. Darüber hinaus gibt es noch weitere Verfahren um ein Mapping durchzuführen. In diesem Vergleich werden die unterschiedlichen Ansätze in Distributed First Order Logic (DFOL) übersetzt. Somit erhält man eine gemeinsame Ebene auf der die Möglichkeiten bzw. Unterschiede der Ansätze besser dargestellt werden können. Alle hier verglichenen Mapping Ansätze haben die Gemeinsamkeit, dass sie auf der Description Logic (DL) beruhen. 3.1 Einführung in DFOL DFOL ist ein logisches Framework zur Represäntation von verteiltem Wissen [7]. Zum einen besteht es aus einer Reihe von first order Theorien und zum anderen aus einer Reihe von Axiomen. Die Axiome beschreiben dabei die Beziehungen zwischen den einzelnen Theorien. Damit können Mapping Sprachen folgendermaßen in DFOL ausgedrückt werden: 3.2 C-OWL im DFOL Framework Wie bereits in Defintion 2 dargestellt kann eine Bridge Rule von i zu j fünf Varianten aufweisen wobei x und y weiterhin entweder Konzepte, Rollen oder Individuen bzw. Konstanten sind. Wegen der Erfüllbarkeit der Bridge Rules kann i : x j:y äquivalent mit der Konjunktion der Mappings i : x j:y und i : x j:y dargestellt werden. Desweiteren ist das Mapping i : x j:y mit i : x j : y äquivalent. Schließlich ist i : x j : y zu der Negation des gesamten Mappings i : x j:y äquvivalent. Mit einer Überstzung in DFOL sieht man das selbst die komplerexeren Bridge Rules aus einfacheren aufgebaut werden können. Nur negative Informationen eines Mappings können nicht in DFOL übersetzt werden [7].

144 140 M. Buthut 3.3 OIS im DFOL Framework Ontology Integration Framework (OIS) ist ein alternativer Ansatz für das Ontology Mapping. Für detaillierte Informationen zu OIS wird auf [7] verwiesen. Dieses Framework verwendet auch unterschiedliche Sichtweisen für die Integration. OIS charakterisiert den globalen, den lokalen und den GLAV Ansatz. Trotz unerschiedlicher Sichtweisen sind alle drei Ansätze in der semantischen Betrachtung gleich. Mappings werden als Terme einer gemeinschaftlichen Übereinstimmung zwischen einem lokalen und dem globalen Modell beschrieben. Daher gibt es drei unterschiedliche Formen für eine Übereinstimmung des Mappings: I erfüllt x, y, sound insbesondere die lokale Interpretation D, falls alle Tupel die y in D erfüllen, x in I erfüllen x, y, complete insbesondere die lokale Interpretation D, falls keine anderen Tupel als die y in D erfüllen, x in I erfüllen x, y, exact insbesondere die lokale Interpretation D, falls die Reihe von Tupeln die y in D exakt die Reihe von Tupeln ist die x in I erfüllen Die dritte Form kann dabei wieder äquivalent mit der Konjunktion der beiden ersten Varianten abgebildet werden. Mit anderen Worten ist das exact Mapping die Konjunktion von sound und complete Mapping. Sound und complete Mapping können wiederum in DFOL übersetzt werden. 3.4 DLII im DFOL Framework DLII bezeichnet eine DL für Information Integration [7]. Im Gegensatz zu OIS, das die Domänen in eine globale Domäne einbettet, setzt DLII eine partielle Überlappung der Domänen voraus. Eine Interpretation I assoziiert zu jedem Modell M i eine Domäne i. Diese verschiedenen Modelle werden mittels interschema Aussagen verknüpft. Die Erfüllbarkeit der interschema Aussagen sind dabei so definiert, dass zwischen extensional und intentional Interpretierungen unterschieden wird: ext, int, ext, int sowie ext, int, ext, int. Wiederum kann durch die Konjunktion von dargestellt werden und anschließend in DFOL übersetzt werden. Dabei erkennt man, dass die extensional Interpretation mit der in OIS übereinstimmt und die intentional Interpretation stimmt dabei mit der Semantik eines Mappings in C-OWL überein. 3.5 Fazit Der DFOL Ansatz hat zwei wesentliche Vorteile. Man kann durch die Übersetzung auf eine gemeinsame Ebene Reasoning zwischen verschiedenen Frameworks durchführen. Obwohl DFOL nicht alle Mappings, wie oben beschrieben, übersetzen kann, so deckt es doch die meisten davon ab. Desweiteren kann damit die Aussagekraft der verschiedenen Ansätze auf gleichem Niveau verglichen werden. So bietet zum Beispiel C-OWL nur die Möglichkeit 2-stellige Relationen zwischen Konzepten, Rollen und Individuen zu bilden. DLII und OIS erlauben n-stellige

145 Ontology Mapping 141 Beziehungen zwischen den Elementen die gemappt werden sollen. Viele andere Ansätze erlauben nur positive Verknüpfungen bei einem Mapping. C-OWL beispielsweise erlaubt aber auch Aussagen darüber, dass zwei Elemente nicht äquivalent ( equiv) sind. Auch in Bezug auf die Beziehungen der Domänen lassen sich die Ansätze unterscheiden. Während bei C-OWL die verwendeten Domänen völlig verschieden sein können, werden beispielsweise bei DLII überlappende Domäne vorrausgesetzt. In Abbildung 6 werden die Unterschiede und Gemeinsamkeiten nochmals zusammengefasst. Abbildung 6. Vergleich der Mappings nach [7] Die Aufstellung und die Erkenntnisse, die man bei der Übersetzung in ein einheutliches Framework erzielt hat, erleichtern die Auswahl des richtigen Mapping Ansatzes. Beispielsweise wird für die Integration einer Datenbank ein Modell gewählt werden, dass n-stellige Beziehungen ermöglicht, denn diese stimmen mit Tupeln in relationalen Datenbanken überein. 4 Schluss Die Verbindung zweier Ontologien kann in vielen Anwendungsfälllen Probleme bereiten. Beispielsweise haben zwei Ontologien eine andere Interpretation der Sachverhalte. Es wurden zwei unterschiedliche Ansätze vorgestellt wie ein Ontology Mapping umsetzbar ist, damit dennoch verschiedene Sichtweisen miteinander verbunden werden können.c-owl versucht beim Mapping auftretende Probleme mit sogenannten Bridge Rules zu lösen. Ziel ist es dabei den Vorteil von Context mit denen einer Ontologie zu verknüpfen. OWL-DL dagegen betrachtet das Problem aus der globalen Sichtweise.Es wurde gezeigt wie die OWL Syntax angepasst werden kann, um Erfüllbarkeit zu gewährleisten. Damit können die Aussagen dann in ein Datalog Programm übersetzt und efiizient ausgewertet werden. Im letzen Kapitel wurde darauf eingegangen wie verschiedene Ansätze auf ihre gemeinsame Komponente, der Beschreibungslogik 1.Ordnung, reduziert werden, um damit einen Vergleich zu erhalten. Durch die Varietät der Ansätze ist es nicht einfach den passenden Ansatz zu finden, wenn denn kein Vergleich der Ansätze möglich wäre. Mit den hier vorgestellten Ansätzen wurden die Grundlagen gelegt, damit Maschinen selbstständig Wissensbasen erweitern können. Nächster Schritt ist eine Automatisierung für derartige Abläufe.

146 142 M. Buthut Literatur [1] T. Berners-Lee, J. Hendler, and O. Lassila. The semantic web. Scientific American, 284(5):34 43, May [2] S. Brockmans and P. Haase. A metamodel and uml profile for networked ontologies - a complete reference. Technical report, Universität Karlsruhe (TH), APR [3] S. Brockmans, P. Haase, and H. Stuckenschmidt. Formalism-independent specification of ontology mappings - a metamodeling approach. In R. Meersman, Z. Tari, and et al., editors, OTM 2006 Conferences, LNCS, Montpellier, France, OCT Springer Verlag. [4] P. Haase and B. Motik. A mapping system for the integration of owl-dl ontologies. In IHIS 05: Proceedings of the first international workshop on Interoperability of heterogeneous information systems, pages 9 16, New York, NY, USA, ACM. [5] A. Maedche and B. Motik. Repräsentations- und Anfragesprachen für Ontologien - eine Übersicht. Datenbank-Spektrum, 3(6):43 53, [6] P. Bouquet and F. Giunchiglia and F. van Harmelen and L. Serafini and H. Stuckenschmidt. Cowl: Contextualizing ontologies, [7] L. Serafini, H. Stuckenschmidt, and H. Wache. A formal investigation of mapping language for terminological knowledge. In IJCAI, pages , [8] W3C. Owl web ontology language - overview. owl-features/, Februar 2004.

147 Semantic Web Service Composition Joachim Alpers WS 2007/08 Lehrstuhl Programmierung verteilter Systeme Prof. Dr. Bauer Universität Augsburg Zusammenfassung Web Services dienen dem Aufruf von Methoden in einem verteilten Umfeld. Zur Erweiterung der manuellen Kommunikation zwischen Web Dienst und Benutzer werden Möglichkeiten erforscht, wie die für eine Planungsaufgabe relevanten und verfügbaren Dienste aufzufinden und in den Bearbeitungsprozess einzubinden sind. Dieses Ziel verfolgt die Semantic Web Service Composition. In dieser Seminararbeit soll aufgezeigt werden, welche Ansätze für diese Art der Komposition existieren, wie diese kategorisiert werden können und schließlich soll ein Ansatz speziell herausgegriffen und im Detail erläutert werden. 1 Einleitung Web Services (WS) werden in unternehmensinternen und -übergreifenden verteilten Systemen eingebunden. Ein Hauptziel von verteilten Systemen ist es, die jeweiligen Ressourcenstärken der einzelnen Systemteilnehmer, wie bspw. Rechenleistung oder Speicherplatz, optimal zu nutzen. Damit eine Komponente eines verteilten Systems mit einer anderen kommunizieren kann, müssen definierte Schnittstellen geschaffen werden. Diese geben an, wie Nachrichten gelesen werden müssen und welches die übergebenen Parameter sind. Handelt es sich bei der Kommunikation um eine Anforderung bzw. eine Anfrage zur Lieferung eines Wertes bzw. einer Datenreihe, so spricht man von einer Service-Anfrage. Diese kann über verschiedene Übertragungsmethoden erfolgen, wie bspw. einem entfernten Prozedur- oder Methodenaufruf - Remote Procedure Call (RPC) bzw. Remote Method Invocation (RMI). Bei diesem synchronen Übertragungsprotokoll blockiert der anfragende Client (service requester) so lange, bis der angefragte Server (service provider) den Befehl verarbeitet hat und eine Antwort zurückgeliefert hat. Im Fall von RMI wird dabei die Methode eines entfernten Objekts mit ggf. entfernten Referenzen aufgerufen. Neben der Übertragungsart müssen für ein solches Service-System auch die Schnittstellenbeschreibungen und das Umfeld der Methodeneinbindung definiert werden. In der Common Object Request Broker Architecture (CORBA) geschieht dies durch die Interface Definition Language (IDL) zum einen und Object Request Broker (ORB) zum anderen. Es wird damit ein plattformunabhängiges System geschaffen, in dem Service-Partner über einen Verzeichnisdienst gesucht werden

148 144 J. Alpers und anschließend die Verbindungen dynamisch generiert werden können. Ein solches System wird als Service-orientierte Architektur (SOA) bezeichnet. Ziel einer SOA ist es dem Dienstnutzer die Entwicklung einer vollständigen Applikation zu ersparen und statt dessen Services anzubieten, durch die man sich die gewünschte Funktionalität zusammenstellen kann. Ein menschlicher Benutzer kann über Relevanz eines Web Service bspw. anhand der Signatur relativ problemlos entscheiden. Ziel ist es jedoch die Funktionalität eines WS auch für eine Maschine-Maschine-Kommunikation interpretierbar zu machen und schließlich die Möglichkeit zu bieten, dass Dienste sich automatisch suchen, auffinden, austauschen und interpretieren können, ohne dass Bedeutung (Semantik) verloren geht (siehe Abbildung 1). Ziel der Semantic Web Service Abbildung 1. Konstituenten des Internet (Quelle: [9] S.55) (SWS) -Komposition ist es daher einen Weg zu finden, wie die für ein Planungsziel relevanten und verfügbaren Web Services gefunden werden können und deren Aufruf in geordneter und semantisch sinnvoller Form erfolgen kann. So soll es möglich werden verteilte Dienste zu einer Applikation zu orchestrieren, die jeweils zur Laufzeit neu (dynamisch) zusammensetzbar sind. Die Seminararbeit zeigt in Kapitel 2 die Grundlagen von Web Services und den Stand der Forschung auf. Im Anschluss werden Möglichkeiten zur Semantikdefinition und zur Festlegung von semantischen Beziehungen festgelegt. Nach einer grundlegenden Erläuterung, wie die SWS-Komposition abläuft, sollen bestimmte Planer exemplarisch und im fünften Kapitel schließlich der Model-based Planner (MBP) detailliert erläutert werden. 2 Web Services: Stand und Ziel der Technik 2.1 Grundlagen und Standards von Web Services Web Services sind über standardisierte Schnittstellen zur Verfügung stehende Dienste mit einer wohldefinierten Funktionalität, die mittels der Auszeichnungs-

149 Semantic Web Service Composition 145 sprache XML beschrieben werden. Für WS können folgende Integrationsaspekte aufgezeigt werden (vgl. [17] S.16): 1. Lose Kopplung Dies ermöglicht eine dynamische Bindung von Diensten untereinander zur Laufzeit. 2. Universelle Nutzbarkeit Mit Hilfe von Registern können Dienste im Netz aufgefunden und dort entsprechend ihrer Anwendung beschrieben werden. 3. Standardsprachen Wie bereits erwähnt, werden Web Services durch XML-basierte Sprachen beschrieben. Zwar können die zugrunde liegenden WS-Anwendungen in anderen Sprachen implementiert sein, jedoch werden die Schnittstellen einheitlich in XML definiert. Zur Umsetzung dieser Eigenschaften werden XML-basierte Sprachen eingesetzt, die zur Kommunikation, Beschreibung und Auffindbarkeit von Web Services dienen. Weite Verbreitung finden diese Standards im World Wide Web (WWW), wo sie auf den gängigen Protokollen HTTP oder TCP aufsetzen. Die wichtigsten Konstituenten und Standards im Bereich von Web Services sind: 1. Simple Object Access Protocol (SOAP) Die eigentliche Anfrage und Ergebnisrückgabe des Dienstes erfolgt in SOAP. Eine SOAP-Nachricht besteht aus einer Verpackung (Envelope), wo der Inhalt der Nachricht beschrieben wird, einer Kodierungsinformation, wie die serialisierten Informationen interpretiert werden müssen und schließlich die Übertragungsdefinition, wie die Nachricht über RPC übergeben und dargestellt werden soll (vgl. [17] S.18). 2. Universal Description, Discovery and Integration (UDDI) Eine UDDI-Registry setzt sich aus den Einträgen verschiedener UDDI- Betreiber zusammen und enthält eindeutige Schlüssel für jeden in ihr aufgelisteten Web Service. Sie dient dazu WS anhand des Schlüssels zu identifizieren und durch Beschreibungen für den Nutzer auffindbar zu machen (vgl. [10]). 3. Web Service Definition Language (WSDL) Über WSDL wird beschrieben, welche Daten und Datenformate von einem WS nach Anfrage geliefert werden und wie entsprechende Operationen darauf lauten. Die Beschreibung erfolgt in XML, wobei ein Element die Port-Typen, d.h. eine genaue Adresse der Dienst-Ressourcen und ein weiteres die Parameter, die für einen Funktionsaufruf erforderlich sind, definiert (vgl. [3] S.2). Der Zusammenhang dieser Standards ist Abbildung 2 zu entnehmen: Will ein Nutzer (Requester) einen Dienst für eine bestimmte Aufgabe über eine WSDL- Definition finden, so wendet er sich an einen Dienstverwalter (Broker), der in seiner UDDI-Registry nach entsprechenden Einträgen sucht und den Nutzer zu einem Anbieter (Provider) verweist. Anschließend kommt der Dienstaufruf über SOAP zwischen Requester und Provider zustande.

150 146 J. Alpers Abbildung 2. SOA-Struktur bei Web Services (Quelle: [9] S.54) 2.2 Die Kopplung von Web Services Die Kopplung von Web Services soll einen Austausch von synchronen oder asynchronen Nachrichten ermöglichen, welche zu einer Kette von Interaktionen zusammengefügt werden können und schließlich zu einer abstrakteren und komplexeren Funktionalität beitragen. Da diese Kommunikation von Maschine-zu-Maschine erfolgen soll, ist neben der Syntax die Übereinstimmung folgender Kriterien, wie auch bei der Menschzu-Mensch-Kommunikation, für eine einwandfreie Interpretation unerlässlich (in Anlehnung an (i.a.) [10] S.45/46): 1. Vokabular Das Vokabular bzw. der Zeichenvorrat muss für alle Kommunikationspartner verständlich sein und die jeweils gleiche Bedeutung aufweisen. Beschreiben mehrere Begriffe des Senders den gleichen Sachverhalt, so müssen diese Synonyme auch dem Empfänger bekannt sein. 2. Bedeutung (Semantik) Im Umfeld der menschlichen Kommunikation geht die Bedeutung einher mit der Interpretation der Sachverhalte. Dabei wird mit dem transportierten Vokabular ein Konzept verbunden, welches dem Empfänger bekannt sein muss und die Bedeutung der Nachricht dadurch semantisch erschlossen werden kann. 3. Eindeutigkeit Interpretationsfehler treten des weiteren bei Begriffen mit mehreren Bedeutungen auf, sog. Homonyme. In diesem Fall kann das System keine eindeutige Semantik erkennen und die Nachricht nicht verarbeiten. Um das zu vermeiden, wird das Unified Resource Identifier (URI) -Konzept herangezogen. Durch diese eindeutige Identifikation der Ressourcen kann eine Mehrdeutigkeit vermieden werden. Durch die Definition dieser Kriterien können die Beziehungen von WS ausreichend definiert werden, um ein WS-System zu schaffen. Es kann sich dabei um eine hierarchische Gliederung von Web Diensten einer Domäne (Taxonomie) oder um ein domänenübergreifendes Netz von Beziehungen, einer sog. Ontologie, handeln (i.a. [11] S.53).

151 Semantic Web Service Composition Motivation für eine Semantic Web Service Komposition Wie in der Einleitung beschrieben, ist es das Ziel einer SOA-Umgebung, dass durch die Verwendung von Web Services auf die Programmierung einer proprietären Anwendung verzichtet werden kann. Statt dessen sollen elementare Funktionen bereit gestellt werden, die je nach Bedarf von den Netzwerkteilnehmern angefordert werden können (vgl. [3]). Dabei liegt die besondere Herausforderung darin ein dynamisches Binden der WS zur Laufzeit zu ermöglichen. Es muss möglich sein, dass sich der Planer die Komposition bei jeder Anfrage neu generiert, da die Verfügbarkeit von Diensten im Internet oft nicht gesichert ist oder neue bzw. veraltete WS identifiziert werden müssen. Der Planungsalgorithmus soll anhand von Beschreibungen der WS erkennen, ob diese für das Planungsproblem relevant sind und sie zur Laufzeit einbinden. Daher kommt es zu der Forderung nach aussagekräftigen Beschreibungen und Beschreibungsmodellen, so dass die Ausführungssemantik für Entwickler und Planer ersichtlich wird (vgl. [6] S.449/450). Die bereits etablierten Standards im Bereich Web Services reichen für eine ausreichende Beschreibung der Zusammenstellung nicht aus. So kann zwar durch WSDL die syntaktische Form der ausgetauschten Nachrichten definiert werden, aber keine semantische Information über den Zusammenhang mitgeliefert werden. Es ist daher nötig weitere Standards zu definieren, die dem Planer Informationen darüber liefern, wie er bei der Planung zu verfahren hat. Wichtige Fragestellungen hierbei sind: 1. Welches ist der Ausgangszustand und welches der Zielzustand der Planung? 2. Nach welchen Kriterien soll die Suche nach geeigneten Web Services durchgeführt werden? 3. Inwiefern kann man von einer geschlossenen Welt ausgehen, bei der alle Domäneninformationen ersichtlich sind? 4. Wie soll verfahren werden, wenn ein atomarer Web Service kein oder ein unerwartetes Ergebnis zurückliefert (Nichtdeterminismus)? 3 Semantik bei Web Services 3.1 Nutzen und Notwendigkeit von Semantik und Ontologien im Web Die Herausforderung im Umfeld der Service-orientierten Architekturen besteht darin, Semantik so eindeutig formulieren zu können, dass menschliche Interpretationsvorgänge verzichtbar werden, ohne Semantik zu verlieren. [10] Um dies zu gewährleisten, muss zum einen die Art der Beziehung von WS- Ressourcen untereinander und zum anderen die Nutzung des domänenspezifischen Vokabulars definiert werden. Dabei sind folgende Kriterien zu erfüllen (i.a. [11] S.53):

152 148 J. Alpers 1. Deklaration von Synonymen Werden identische Inhalte mit unterschiedlichen Namen bezeichnet, so muss sichergestellt werden, dass diese untereinander verknüpft sind. 2. Logisches Erschließen von Zusammenhängen und Abstraktionsstufen Es muss für Nutzer eines Dienstes ersichtlich sein, wenn dieser die gleiche Funktionalität bietet wie andere Dienste, die dessen Grundfunktionen einzeln bezeichnen. 3. Erschließen und Zusammenfassen von Grundfunktionalitäten zur Erfüllung geforderter Dienste Die verwendeten Begriffe sollen dem Nutzer aufzeigen können, wie elementare Operationen zur Definition von komplexeren Diensten genutzt werden können. 3.2 Semantikbeschreibung durch RDF Um Web Services automatisiert miteinander kommunizieren zu lassen, muss es möglich sein deren Inhalt, sowie deren Wechselwirkungen und Zusammenhänge mit anderen Diensten in maschinenauswertbarer Form zu beschreiben. Hierfür wurde das Resource Description Framework (RDF) entwickelt, welches u.a. in XML dargestellt werden kann. Das RDF ermöglicht es durch die folgende Tripel- Darstellung Zusammenhänge zwischen WS-Objekten zu definieren: 1. Subjekt (Resource) 2. Prädikat (Property) 3. Objekt (Resource) Jedes dieser Elemente wird jeweils durch das Attribut resource definiert, welches auf einen eindeutigen Unified Resource Identifier (URI) verweist. Semantische Annotation kann also vereinfacht als die Angabe von Web-Ressourcen (Resource) und deren Eigenschaften (Property) angesehen werden. Wie auch für die Validierung von XML-Dokumenten wird für die Definition eines Domänenvokabulars ein RDFS-Schema (RDFS) verwendet. Über dieses ist es möglich Klassen, Eigenschaften, Domänengrößen (Range) und Dokumentationen der Subjekte (resources) zu beschreiben (vgl. [3] S.3). Das Vokabular, welches zur Beschreibung dieser Beziehungen verwendet wird, kann in jeder Domäne anders definiert sein, so dass ein Austausch von RDF-Daten zwischen Domänen mangels Interpretierbarkeit wenig sinnvoll erscheint (vgl. [10] S.46/47). Damit ein Kommunikationsnetz von Web Services entsteht, muss daher eine Ontologie geschaffen werden, also ein System von Zusammenhängen zwischen verschiedenen WS-Komponenten. Dies garantiert, dass das domäneninterne Vokabular auf die gleiche Weise interpretiert werden kann, daher im semantischen Web eindeutig ist und von Servern als auch von Clients dort abgerufen werden kann (vgl. [14] S.26 f.). Dafür muss das in RDFS beschriebene domänenspezifische Vokabular anderen Domänen zugänglich gemacht werden. So können zum einen Synonyme der gleichen Abstraktionsstufe aufeinander verweisen (equivalentclass) und zum anderen kann sichergestellt werden, dass Begriffe unterschiedlicher Abstraktionsstufen nicht zusammen verwendet werden (issubclassof) (vgl. [11] S.53). Ein Ansatz dies umzusetzen stellt OWL-S dar.

153 Semantic Web Service Composition Ontologiegestützte Semantikbeschreibung bei Web Services durch OWL-S Die Vision im Umfeld von Semantic Web ist eine Welt, in der sich weiterentwickelnde Service-Ansammlungen und -Vernetzungen so gestaltet sind, dass Agenten und Applikationen miteinander automatisiert kommunizieren können. Ontologien stellen dabei den Basisbaustein für das Semantic Web dar, weil diese dafür sorgen, dass WS-Systeme ohne manuellen Einfluss interpretierbar werden. Ontologien stellen ein abstraktes Modell mit einem klar definierten Konzept und definierten Bedingungen dar, in dem sich die Entitäten Domänenwissen teilen (vgl. [5] S.3). Durch die Web Ontology Language for Services (OWL-S) ist es möglich solche Ontologien zu definieren. OWL-S ist eine von der W3C entwickelte Sprache, um semantische Web Service-Beschreibungen zu ermöglichen und gilt als Weiterentwicklung der DARPA Agent Markup Language for Services (DAML-S). Sie kann wie die anderen WS-Standards in XML deklariert werden (vgl. [5] S.1). Die Sprache baut auf drei zusammenhängenden Unter-Ontologien auf (vgl. [13]): 1. Profil (Profile) Dieses dient der Beschreibung des WS und dessen Aufgabe. Es hilft dem WS für Agenten auffindbar zu werden. 2. Prozessmodell (Process Model) Hier wird beschrieben, wie der WS funktioniert. Durch die Angabe, welche Prozesschritte und Vorbedingungen für einen bestimmten Output nötig sind, wird der automatisierte Aufruf und die Einbettung in eine WS-Komposition ermöglicht. 3. Fundament (Grounding) Dieses beschreibt die genutzten Formate und Protokolle des WS und damit die möglichen Interaktionsformen. Diese Angaben werden normalerweise in WSDL ausgedrückt. Das Profil und das Prozessmodell müssen so aufeinander abgestimmt sein, dass die im Profil eines Web Service angegebene Funktionalität auch durch das Prozessmodell umgesetzt wird. Dabei gibt es vier zentrale Definitionsbausteine, die in beiden Kategorien beschrieben werden: Input, Output, Vorbedingung (Precondition) und Auswirkungen (Effects). Der Input eines atomaren WS ist der Inhalt einer Nachricht, die ähnlich einem RPC an den Service übergeben wird. Der Output stellt das zurückgelieferte Ergebnis dar. Durch Vorbedingungen und Auswirkungen eines Web Service wird ein globaler Status definiert, der vor der Ausführung eingetreten sein muss bzw. danach eintritt. So kann bei einem Online-Kauf mittels Web Services die Gültigkeit einer Kreditkarte als Vorbedingung, die Eingabe der Kreditkartennummer als Input, die Ausgabe der Kaufbestätigung als Output und die Auslieferung der Ware an den Käufer als Auswirkung definiert werden. Durch diese Definitionsbausteine wird

154 150 J. Alpers es zudem möglich neue Web Services ohne zusätzlichen Programmieraufwand zur Laufzeit aufzufinden und zu benutzen. Inputs und Outputs werden in XML als Unterklassen der Parameter-Klasse abgebildet, welche wiederum die jeweiligen Datentypen als Oberklasse haben. Im folgenden Code-Beispiel einer OWL-Definition in XML ist zum einen die hierarchische Einordnung von Inputwerten zu sehen und zum anderen die Namensraumangaben zu RDF, RDFS und OWL, durch die die entsprechenden Schlüsselwörter definiert werden: <owl:datatypeproperty rdf:id="parametertype"> <rdfs:domain rdf:resource="#parameter"/> [...] <owl:class rdf:id="parameter"> <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#parametertype" /> [...] <owl:class rdf:id="input"> <rdfs:subclassof rdf:resource="#parameter"/> </owl:class> Für die Beschreibung der Vorbedingungen (Preconditions) und Auswirkungen (Effects) wird die Kodierungssprache offen gelassen. Es kann dabei auf die XML- Annotation zurückgegriffen werden oder bspw. die Planning Domain Definition Language (PDDL) genutzt werden (vgl. [13]). Da OWL als WWW-Sprache nicht davon ausgehen kann, alle Informationen für Preconditions und Effects zu kennen, verwendet sie im Gegensatz zu formalen Planungsalgorithmen eine Open-World-Semantics, bei der fehlende Beschreibungen der Planungsdomäne zugelassen sind, jedoch bei AI-Planern für einen Abbruch sorgen können (vgl. [18]). OWL-S unterscheidet drei Prozessarten bei der Einbindung von WS (vgl. [1] S.6): atomare Prozesse, die keine weiteren Unterprozesse beinhalten simple Prozesse, die nicht direkt aufrufbar sind, sondern hinter denen sich atomare oder zusammengesetzte WS verbergen Prozesskompositionen, die Unterprozesse enthalten Handelt es sich nicht um den Aufruf eines einzelnen, atomaren WS, sondern einer sog. Komposition, werden nicht mehr die einzelnen In- und Outputs betrachtet, sondern die Stati, die der Prozess im Laufe der Planung annimmt. Eine solche Prozesskomposition kann mit Flusskonstruktoren und entsprechenden atomaren WS beschrieben werden. Wie im Prozessmodell in Abbildung 3 zu sehen, hat der Client bei Amazon.com die Auswahl, ob er ein Buch über eine der Suchfunktionen (Autor, Künstler, etc.) finden, seinen Einkaufwagen einsehen oder modifizieren, oder eine Sequenz (Sequence) dieser Aktionen durchführen will. In letzterem Fall würde also nach einer erfolgreichen Buchsuche dieses in

155 Semantic Web Service Composition 151 Abbildung 3. Beispiel eines Prozessmodells in OWLS (Quelle: i.a. [14] S.31) den virtuellen Einkaufswagen gelegt werden. Die Blätter dieser Graphdarstellung sind die atomaren Dienste, deren Beschreibung in WSDL erfolgen kann. 4 Verfahren der Semantic Web Service Komposition 4.1 Funktion und Ablauf der SWS Komposition Ähnlich wie beim sog. semantischen Prozessmanagement ist es das Ziel der Web Service Komposition einen höheren Automatisierungsgrad in der Erstellung und Durchführung von Prozessen zu erreichen. Prinzipiell sind zwei Ansätze bei der konkreten Umsetzung einer Web Service Komposition zu unterscheiden: Zum einen bieten Sprachen wie die Business Process Execution Language for Web Services (BPELWS) die Möglichkeit verteilte Web Services miteinander zu verbinden und zu orchestrieren. Dabei fungiert ein Web Service als steuerndes Element, der u.a. regelt in welcher Reihenfolge Nachrichten eintreffen müssen. Es handelt sich um eine syntaktische Orchestration. Daher muss auch jeder neue Prozess manuell über ein jeweils zu definierendes Interaktionsprotokoll mit dem steuernden WS verbunden werden. Die zweite Möglichkeit wird über einen separaten Planer realisiert, der durch verschiedene Algorithmen den Planungsraum durchsucht und bestimmte WS für seinen Zweck zusammenstellt. Um zu wissen, welche Services für die jeweilige Planungsdomäne auszuwählen sind, können durch OWL-S definierte Ontologien genutzt werden. Dadurch soll sicher gestellt werden, dass jede in einem Planungsablauf einbezogene Domäne (Diskurswelt) die genutzte Terminologie gleich versteht und Mehrdeutigkeiten unterbunden werden (vgl. [8] S.3). Statt einem

156 152 J. Alpers zentralen, orchestrierenden Dienst werden bei OWL-S für jeden WS der Ontologie Vorbedingungen (Preconditions) und Auswirkungen (Postconditions) definiert. Durch diese Parameter wird es einem Planer ermöglicht über ein Top-Down- Vorgehen das Auffinden und die Zusammensetzung von Diensten automatisiert vorzunehmen (vgl. [16] und [3]). Der Prozess einer automatischen Zusammenstellung von Web Services kann als abstraktes Modell beschrieben werden, bei dem ein Service Provider verschiedene Web Services zur Nutzung bereitstellt, die wiederum ein Service Requester in Anspruch nehmen kann. Die weiteren Komponenten und der Planungsablauf kann wie folgt dargestellt werden (vgl. Abbildung 4): Abbildung 4. Ablauf der Web Service Komposition (Quelle: [17] S.21) Der Ablauf der Kompositionsplanung kann im Detail in folgende Phasen gegliedert werden (i.a. [17] S.20 f.): 1. Dienst anbieten/ publizieren Um die angebotenen WS bei den Repositories publik zu machen, werden die Beschreibungsdaten der Dienste bspw. über UDDI zur Verfügung gestellt. Neben der Signatur, also Angaben über Datentypen und Operationen des Web Service, müssen für eine automatisierte Planung ebenso Informationen über den Status (State) zur Verfügung stehen, der die Vorbedingungen und Effekte bzw. Nachbedingungen eines Dienstes definiert. 2. Übersetzen Bei der Kommunikation zwischen Benutzer und Planer muss es ersterem möglich sein seine Planungsaufgabe möglichst einfach und standardisiert zu beschreiben. Dazu gehören die Angaben, welche Daten der Requester benötigt, welche er als Input liefert, in welchem Format sie bereitgestellt werden und wie diese in Beziehung stehen. Dieses ist mit Hilfe von Meta- Auszeichnungssprachen wie WSDL oder DAML-S möglich. Der Planer selbst benötigt diese Angaben in formalisierter Form, in der jeweiligen Sprache, in der sein Planungsalgorithmus formuliert ist. Daher muss eine Übersetzung ermöglicht werden, durch die keine semantischen Zusammenhänge verloren gehen.

157 Semantic Web Service Composition Erzeugen eines Prozessmodells zur WS-Komposition Mit den überlieferten Angaben setzt der Planer aus den atomaren Diensten der Service Repository ein Prozessmodell zusammen und gibt dieses zusammen mit der Kontroll- und Datenflussspezifikation an den Übersetzer zurück. 4. Bewertung der Komposition Da es mehrere Web Services geben kann, die ihre Funktionalitäten gleich definiert haben, aber für die Planungsaufgabe weniger wertvolle Ergebnisse liefern, wird durch den Evaluator ein Ranking der zurückgelieferten Service- Kompositionen durchgeführt. 5. Ausführung der WS-Komposition Bei der Ausführung der gewählten Planungskomposition wird eine Sequenz von Nachrichtenaus- und eingängen (Data flow) festgelegt, wobei jedes zurückgelieferte Web Service-Resultat innerhalb der Planung als Inputwert für den nächsten atomaren Dienstaufruf dient. 4.2 Planer für SWS Komposition SHOP 2 Der SHOP2-Planungsalgorithmus ist ein sog. Hierarchical Task Network (HTN) -Planer. HTN-Planern liegt zu Grunde, dass jede Planungsdomäne mit Hilfe einer Ansammlung von Methoden und Operatoren definiert wird. Jede Methode beschreibt, wie eine Planungsaufgabe weiter untergliedert werden kann und gibt eine Ordnung dieser vertikalen Aufrufe vor. Jeder Unterprozess ruft rekursiv entsprechende Methoden auf bis die Ebene der primitiven Dienste erreicht ist, die mit den übergebenen Operatoren aufgerufen werden können. Hierarchische Planer sind besonders für den WS-Bereich geeignet, da zum Erstellen einer Methode nicht der gesamte Aufrufplan der Unterdienste bekannt sein muss.(vgl. [18] S.3). SHOP2 gibt im Gegensatz zu seinem Vorgänger SHOP keine totale, sondern eine partielle Ordnung beim Aufruf der Unterprozesse vor. Dadurch können sich Planungsschritte von unterschiedlichen Planungsaufgaben überschneiden und ermöglichen eine flexiblere Gestaltung der Domänenstruktur. SHOP-Planer generieren ihre Planungsfolgen zudem immer in der Reihenfolge, wie die Dienste später auch ausgeführt werden. Auf diese Weise kennt der Planer bei jedem Planungsschritt den momentanen Status des Systems (vgl. [15] S.379 f.). HTN-Planer sind geeignet für die Planung in vollständig beschriebenen Domänen, in denen partiell geordnete Ausführungssequenzen zur Verfügung stehen. Werden nicht die benötigten Methoden und Ausführungspläne zur Verfügung gestellt, kann der Algorithmus keine adäquate Lösung für das Planungsproblem zurückliefern. Er hängt also stark von der Designqualität der Methoden in den Domänen ab (vgl. [12] OWLS-Xplan Um die Schwäche der HTN-Planer zu übergehen, wurde mit dem OWLS-Xplan der Versuch einer Kombination von HTN- und aktionsbasierter Planung unternommen. Letztere nutzt wie SHOP2 die Information der Domänenmethoden, jedoch befolgen zur Ausführung der Planungsaufgabe nicht die hierarchische Untergliederung

158 154 J. Alpers in Unterprozesse, sondern bedienen sich der atomaren Dienste, die dort angegeben werden. Dafür wird OWL-S und PDDL genutzt. Der Planer konvertiert die Service- und Ontologiebeschreibungen, die ihm in OWL-S vorliegen, durch ein Konvertierungstool (OWL2PDDL) in PDDL. Als Ergebnis erhält man zum einen eine Domänenbeschreibung mit allen Typen, Prädikaten und Aktionen und zum anderen eine Problembeschreibung, die alle Planungsobjekte, den Ausgangszustand und den Zielzustand beschreibt. Diese Informationen nutzt der integrierte AI-Planer von Xplan, um einen Verbindungsgraph zu erstellen, der initialisierte numerische oder literale Operatoren untereinander verbindet und so den Planungsrahmen vorgibt. Der Planer implementiert eine Re-Planning -Komponente, durch die auf Änderungen im globalen Zustand während des Planungsprozess reagiert werden kann (vgl. [12]) Model-based Planner Der MBP stellt einen Vertreter der Artificial Intelligence (AI) -Planer dar und implementiert das Planning as Model Checking -Modell. In diesem werden drei für die Web Service-Komposition wichtige Anforderungen erfüllt (vgl. [16] S.2): 1. Nichtdeterministische Domänen Für einen Requester ist der Output eines WS nicht immer vorhersehbar bevor er nicht wirklich ausgeführt wurde (z.b. ist bei der Buchung eines Flugtickets nicht sicher, ob diese bestätigt wird). 2. Partielle Beobachtbarkeit Der interne Status von WS ist für externe Anfrager i.d.r. nicht einsehbar, sondern nur die jeweiligen Outputs (z.b. ob noch freie Plätze vorhanden sind). 3. Beschreibung komplexer Ziele Die Ziele einer WS-Komposition müssen zeitlichen Bedingungen und Präferenzen angepasst werden können (z.b. soll ein Hotel erst gebucht werden, wenn ein entsprechender Flug reserviert wurde). Im Gegensatz zu HTN-Planern wie SHOP2 werden bei diesen Planern die Planungsziele definiert und nicht eine geordnete Abfolge von Unterprozessaufrufen formuliert (vgl. [15] S.380). Der MBP wird im folgenden Kapitel näher erläutert. 5 Beschreibung eines SWS Kompositions-Planer am Beispiel des MBP 5.1 Aufbau und Algorithmen des Planers Die Planung mit dem MBP ist in zwei Phasen gegliedert: 1. Die Darstellung der Planungsdomäne durch Binary Decision Diagrams (BDD) bzw. NuPDDL. 2. Die Anwendung verschiedener Planungsalgorithmen mit Hilfe eines Symbolic Model Checking (SMC) -Planers.

159 Semantic Web Service Composition Domänenbeschreibung durch BDDs bzw. NuPDDL Durch Binary Decision Diagrams (BDD) ist es möglich, eine Domäne als nichtdeterministisches Zustandsübergangssystem (state transistion system) in Baumstruktur darzustellen. In der BDD-Darstellung werden mehrfach-verwurzelte (multi rooted), azyklische, gerichtete Graphen verwendet, durch die binäre Entscheidungsdiagramme abgebildet werden. Die internen Knoten eines solchen Graphen repräsentieren die Variablen, über die die Funktion definiert ist. Die Blätter des Baums nehmen den Wert 1 oder 0 an. Hierbei ist zu erwähnen, dass die Baumgröße exponential zu der Anzahl enthaltener Variablen ansteigt. Eine Funktion F(X1,X2,X3) kann als Baum dargestellt werden, in dem jeder Knoten auf zwei Kindknoten verweist, wobei die Kante entweder gestrichelt (Wert=0) oder durchgezogen (Wert=1) dargestellt wird (siehe Abbildung 5). Die zugehörige Wahrheitstabelle zeigt für F genau die Werte der Baumblätter von links nach rechts gelesen an (vgl. [4] S.293 f.). Abbildung 5. Beispiel eines BDD-Baums mit Wahrheitstafel ([4] S.293) Im MBP werden durch die Verwendung einer Einheitstabelle (unique table) isomorphe, also bedeutungsgleiche Graphen und dadurch redundante Knoten vermieden. Eine zweite Tabelle (computed table) speichert die zuletzt durchlaufenen Transformationen und erhöht dadurch die Effizienz des Planungsalgorithmus (vgl. [2]). Beim MBP erfolgte diese Darstellung mit Hilfe der aktionsbasierten Sprache AR, die fähig ist auch andere als Wahrheitsvariablen zu verarbeiten, eine serielle Kodierung vorgibt und das Planungproblem als endlichen Automaten darstellt. Neue Versionen des MBP unterstützen statt dessen eine Domänenbeschreibung und -validierung in NuPDDL, die an PDDL angelehnt ist. Letztere wird als Standard in der Deklaration von Inputwerten für AI-Planer gehandhabt und besitzt starke Parallelen zu DAML-S, welche wiederum als Vorgänger von OWL-S gehandhabt wird. Wie bei OWL-S bereits erwähnt, stellt es für AI-Planer ein Problem dar mit einer Open-world assumption (OWA) umzugehen, d.h. dass nicht alle Variablen für die Planung zur Laufzeit zur Verfügung stehen. Ist dies der Fall, so geht der Planer von dem Wahrheitswert False der Variablen aus, obwohl nicht sicher ist, welchen Wert er besitzt. Diesen Umstand bezeichnet man als Negation as

160 156 J. Alpers Failure und er ist besonders für die Planung im dynamischen WWW -Umfeld relevant (vgl. [17] S.24). Zur Beschreibung von Nichtdeterminismus im Initialzustand und von Aktionseffekten wird bei NuPDDL das oneof -Schlüsselwort genutzt. Für den AI-Planer wird dabei die open-world assumption auf eine Closed-World Assumption (CWA) reduziert: (define (domain d)... (:predicates (P1) (P2) (P3) (P4) (P5) (P6))...) (define (problem p)... (:init (and (P1) (oneof (and (P2) (P3)) (P4)) (unknown (P5)))) (:effect (and (P1) (oneof (and (P2) (P3)) (P4)) (unknown (P5))))...) Wie in dem Programmierbeispiel in PDDL zu sehen, kommen nicht alle definierten Prädikate der Domäne auch im Planungsproblem vor (hier P6). Für diese Variablen gilt im Sinne der CWA, dass sie immer den Wert False annehmen. Während P1 immer True sein müsste, müssen entweder P2 und P3 oder aber P4 wahr sein. Der Wahrheitswert von P5 ist für das Modell indifferent. Ein gültiges Modell des Initialzustands wäre bspw.: P1=True; P2=True; P3=True; P4=False; P5=True; P6=False Durch nichtdeterministische Aktionseffekte werden ebenso in dem Programmbeispiel beschrieben. So könnte ein auf den obigen Intialzsutand folgender Zustand wie folgt lauten: P1 =True; P2 =True; P3 =True; P4 =P4; P5 =False; P6 =P6 P4 und P6 können die alten Werte beibehalten, da an diese Variablen keine Bedingungen geknüpft sind. P5 kann beide Wahrheitswerte annehmen. Es können also alle Zustände eingenommen werden, in denen die obige Formel eingehalten wird (vgl. [19]) Planungsdurchführung durch Symbolic Model Checking Symbolic Model Checking (SMC) erlaubt es, große, endliche Zustandssysteme über symbolische Repräsentationstechniken (wie bspw. BDD ) zu durchsuchen. Die Planung wird über endliche Automaten und deren Zustandsübergänge definiert. Um ein effizientes Durchsuchen der Domäne zu gewährleisten, werden Ziele über formalisierte Bedingungen des Planungsverlaufs ausgedrückt. Die Domäne selbst ist als Zustandsübergangssystem (state transition system) mit einer endlichen Anzahl von Zuständen, einer endlichen Anzahl von darauf ausführbaren Aktionen und Zustandsübergangsfunktionen repräsentiert. Planer für SMC weisen folgende Charakteristika auf (vgl. [19], [7] S.403ff.): 1. Die Planungsdomänen stellen nichtdeterministische Zustandsübergangssysteme dar, in denen eine Aktion von einem Zustand zu mehreren, möglichen Zuständen führen kann.

161 Semantic Web Service Composition Durch Formeln der temporalen Logik werden sowohl Zielzustände, also auch zeitlich begrenzte Ziele (temporally extended goals) auf den zu durchlaufenden Planungspfaden definiert. 3. Pläne können bedingtes und iteratives Verhalten aufweisen. 4. Über temporale Formeln können Bedingungen ausgedrückt werden, die den gesamten Planungspfad über gültig sein müssen. 5. Die Suche durch die Modellzustände fungiert über Transformationen der Zustandsbeschreibungsformeln. Planung über SMC ist daher darauf ausgelegt unter nichtdeterministischen und nicht vollständig beschriebenen Domänen zu planen, was sie für die Suche im Bereich der Web Services sehr nützlich macht. Diese Art der Planung ist so konzipiert, dass weder der Grad an Unsicherheit im Planungsraum, noch die zusätzliche Angabe von temporären Zielen die Planer-Performance negativ beeinträchtigen (vgl. GHAL2004 S.404). 5.2 Systematik und Merkmale der Planungsalgorithmen Der MBP stellt ein Tool zur automatischen Erzeugung von Web Service Kompositionen dar, welches dem Entwickler verschiedene Planungsmöglichkeiten für verschiedene Planungsprobleme bietet. Allen Planungsszenarien ist gleich, dass sie in nichtdeterministischen Domänen ausgeführt werden können. Nichtdeterminismus in einer (Planungs)-Umgebung zeichnet sich dadurch aus, dass die Ergebnisse eines Planungslaufs nicht vorherbestimmbar sind und damit nicht reproduzierbar sind Planung nach Grad der Beobachtbarkeit Für den Fall der Planung in nichtdeterministischen Domänen können, je nach Umfang an Informationen, die über die Domänen zum Zeitpunkt der Planungsausführung zur Verfügung stehen, drei weitere Planungsdimensionen unterschieden werden (vgl. [2]): 1. Volle Beobachtbarkeit (Full Observability) In diesem Fall geht man davon aus, dass die Planungsdomänen voll einsehbar und zur Laufzeit bekannt sind. 2. partielle Beobachtbarkeit (Partial Observability) Es sind nur Teile der Domäneninformationen zur Laufzeit bekannt. 3. Keine Beobachtbarkeit (Null Observability) Die Domäne ist dem Planer gänzlich unbekannt. Beobachtbarkeit ist dabei als der Anteil der zur Planung zur Verfügung stehenden Informationen definiert. Je nach Grad der Beobachtbarkeit verwendet der MBP unterschiedliche Planungsalgorithmen. Eine Übersicht über den Aufbau und Ablauf der Planung des MBP ist Abbildung 6 zu entnehmen. Im Falle der teilweisen Beobachtbarkeit (partial observability) wird die Tiefensuche favorisiert. Dazu werden vom Nutzer die beobachtbaren Variablen und die Bedingungen, unter welchen diese beobachtbar sind, in BDD bzw. NuPDDL

162 158 J. Alpers Abbildung 6. Aufbau des Model-based Planner angegeben. Der Ausführungsplan dieser Kategorie besitzt eine Baumstruktur. Die Verzweigungen werden durch die beobachtbaren Variablen vorgegeben. Kann keine Domäneninformation zur Laufzeit abgerufen werden, bedient man sich des Conformant Planning. Diese Planungsart erstellt über eine Breitensuche eine Sequenz von Aktionen, die ohne Kenntnis der Anfangskonditionen immer zum gewünschten Ziel führt. Dafür definiert er zusätzliche Variablen, die zur Planung benötigt werden Planung nach Art der Ausführung Ist eine nichtdeterministische Domäne vollständig oder teilweise bekannt, kann die Erreichung eines Kompositionsziels auf folgende Weise definiert werden (vgl. [2]): 1. Weak Planning Nur manche Ausführungen der Planung führen zum gewünschten Ziel. 2. Strong Planning Für alle Ausführungsvarianten ist sicher, dass das Planungsziel erreicht wird. 3. Strong Cyclic Planning Es werden iterativ verschiedene Strategien nach dem Trial-and-Error-Prinzip durchlaufen. Das Ziel wird in allen Ausführungsfällen erreicht. Die erzeugten Pläne sind Status-Aktions-Tabellen (state-action tables), in denen die auszuführenden Aktionen in Form von Statusmengen dargestellt werden. Weak Planning und Strong Planning nutzen die effizientere Breitensuche, um den Planungsgraphen zu durchlaufen. Dazu geht der Algorithmus vom Zielstatus aus und sucht sich einen Weg zum Initialzustand. Nach jedem Schritt wird ein

163 Semantic Web Service Composition 159 entsprechender Graph in der Status-Aktions-Tabelle erstellt, der im Falle von Weak Planning eine Chance hat zum gewünschten Zielzustand zu gelangen und im Falle von Strong Planning die Erreichung garantiert. Dabei wird iterativ jeder erreichbare Zustand als neuer Ausgangspunkt und damit als neues Planungsziel definiert. Strong Cyclic Planning nutzt zwei mögliche Planungsvarianten: Beim globalen Ansatz wird eine Analyse aller Statusvarianten der Planung vorausgesetzt, wobei sich der lokale Ansatz wie die beiden ersteren Planungsarten über Zwischenzustände der Planung weiterhangelt (vgl. [2]). In der Automatendarstellung der Planungsausführung beschreibt ein gerichteter Graph durch seine Knoten alle Zustände, die durch eine bestimmte Verfahrensweise (Policy) erreicht werden können. Solche Policies sind die möglichen Wege von einem Initialstatus zu einem Endstatus zu gelangen. In Abbildung 7 ist ein Zustandsübergangssystem zu sehen, in dem es mehrere Möglichkeiten gibt vom Initialstatus s1 zum Zielstatus s4 zu gelangen. Abbildung 7. Beispiel eines nichtdeterministischen Zustandsübergangssystems Von s2 aus gesehen gibt es für die Zustandstransition move(l2,l3) zwei nichtdeterministische Zustandsübergangsmöglichkeiten: der Status ändert sich in s3 oder in s5. Der Planungsalgorithmus für Strong Planning garantiert in diesem Beispiel durch seine Policy, dass der Planungsgraph auf jeden Fall zum gewünschten Ziel führt, indem er folgende Aktionen beschreibt (i.a. [7]): {(s1,move(l1,l2))(s2,move(l2,l3))(s3,move(l3,l4))(s5,move(l5,l4))} Egal welcher Pfad von s2 aus genommen wird; er erreicht immer Status s4 (in Abbildung 7 durch die blauen und roten Kanten gekennzeichnet). Der zugehörige Algorithmus beginnt beim Zielstatus der Suche und arbeitet sich über erreichbare Zustände vor zum Anfangsstatus. Er kann in folgende Schritte gegliedert werden (i.a. [7]):

164 160 J. Alpers 1. Input sind der Zielzustand, der Initialzustand und die möglichen Operationen für die Domäne, d.h. Tupel mit Angaben über die Vorbedingungen und Auswirkungen einer Aktion. 2. Solange es weitere Zustandsübergänge gibt und der Initialzustand nicht erreicht ist, wird folgende Suchroutine (StrongPreImage) rekursiv aufgerufen: Gegenwärtiger Zustand (PreImage) = Zielzustand Es werden alle möglichen Zustandsübergänge (Tupel) der gegenwärtigen Zustände zu PreImage hinzugefügt und als neue Ausgangszustände definiert. PreImage enthält also immer die Zustand-Tupel, die zum Zielzustand leiten oder zu Zuständen führen, die Teil des Lösungswegs sind. Im Anschluss werden alle Tupel weggeschnitten, deren Lösungsweg zum Zielstatus bereits bekannt ist. 3. Der Algorithmus terminiert, wenn entweder der Initialzustand in der Zustandsmenge enthalten ist oder keine weiteren Zustände mehr der Policy hinzugefügt werden können. Der Strong Planning-Algorithmus gewährleistet, dass immer eine Lösung gefunden wird oder gibt eine Fehlermeldung zurück, wenn keine starke Lösung existiert, also eine, die garantiert zum Zielstatus führt. Im Fall von Weak Planning wäre der Erfolg eines Planungslaufs nur in deterministischen Domänen garantiert, da dieser Plan im Gegensatz zur Strong Planning Methode nur einen möglichen Pfad für die Zielerreichung angibt, auch wenn dieser nur unter bestimmten Bedingungen zum Ziel führt. In deterministischen Domänen würden Strong und Weak Planning zu identischen Ergebnissen führen, da eine Zielerreichung immer sichergestellt ist (vgl. [7]). Für den Graph in Abbildung 7 wäre folgendes ein Beispiel für eine Weak Planning- Verfahrensweise, welche mit den blauen Kanten dargestellt wird: {(s1,move(l1,l2))(s2,move(l2,l3))(s3,move(l3,l4))} Im Gegensatz zur Strong Planning Policy davor wird die Möglichkeit, dass move(l2,l3) auch zu s5 führen könnte, nicht berücksichtigt, sondern nur ein Weg zum Zielstatus s4 angegeben. Es ist daher nicht sicher, dass s4 auch wirklich erreicht wird, falls der Suchroboter bei Status s5 anlangt. Der dritte, mögliche Suchalgorithmus im Rahmen des SMC ist das Strong Cyclic Planning. In diesem Fall wird ein Weg zur Erreichung des Zielstatus gefunden, der durch mehrere Iterationen des Plandurchlaufs in jedem Fall zum Zielstatus führt. Dabei wird davon ausgegangen, dass bei einem nichtdeterministischen Zustandsübergang nach einer endlichen Anzahl von Wiederholungen der richtige Pfad gewählt wird. In Abbildung 7 stellen die grünen Kanten den Pfad dar, den ein Strong Cyclic Planning-Algorithmus, bei dem Versuch von s1 nach s4 zu gelangen, finden würde. Durch folgenden Zustandsübergang ist nicht sicher, ob der Zustand bei s1 verharren oder ob er sich in s5 ändern würde, also nichtdeterministisch ist: {(s1,move(l1,l4))}

165 Semantic Web Service Composition 161 Durch die Iterationen ist es im Vergleich zum Weak Planning Algorithmus sicherer den Zielstatus zumindest nach einer endlichen Anzahl von Versuchen zu erreichen. Weak Planning kann immer auch einen Pfad abbilden, der in der Menge aller möglichen Strong Planning-Verfahren enthalten ist. So könnte im oben aufgeführten Weak Planning-Beispiel auch der selbe Pfad vom Algorithmus gefunden werden, der im Fall von Strong Cyclic Planning gefunden wurde. Strong Planning-Lösungen sind eine Untergruppe der Strong Cyclic Planning- Lösungen, welche wiederum immer Teil aller möglichen Weak Planning-Lösungen sind (vgl. [7]). Die genannten Planungsvorgehensweisen setzen voraus, dass ein ganz bestimmter, formulierter Endzustand erreicht werden soll. Es können auch Bedingungen ausgedrückt werden, die Auswirkungen auf den Planungsablauf haben. In diesem Fall spricht man von zeitlich erweiterten Zielen (temporally extended goals). Hierbei werden statt dem Endzustand die Zustandsänderungen in Form von Sequenzen beobachtet. Ein Beispiel für ein Solches wäre im Bereich der kommerziellen Web Services die Bedingung, ein Hotel erst zu buchen, wenn der gewünschte Flug auch reserviert werden konnte (vgl. [14] S.31). Erweiterte Ziele können beim MBP über die Computation Tree Logic (CTL) ausgedrückt werden. 6 Zusammenfassung und Fazit Für die Planung von Web Service Kompositionen sind semantische Informationen über die Dienste für ein sinnvolles Kombinieren unerlässlich. Ohne diese Zusatzinformationen ist es für Planer schwierig die für sie relevanten Web Services aufzufinden und deren Terminologie miteinander zu vergleichen. Um Informationen darüber zu erhalten, in welchem Verhältnis Web Dienste zueinander stehen, können durch OWL-S definierte Ontologien genutzt werden. Dadurch kann sicher gestellt werden, dass jede in einem Planungsablauf einbezogene Domäne (Diskurswelt) das genutzte Vokabular gleich versteht und Mehrdeutigkeiten unterbunden werden. In OWL-S selbst ist es durch die Prozessmodellbeschreibung bereits möglich statische Abfolgen bzw. Kompositionen von Diensten zu definieren. Um für das dynamische WWW eine Möglichkeit der nichtdeterministischen Planung zur Laufzeit in ggf. nicht vollständig bekannten Domänen zu bieten, können AI-Planer wie der MBP herangezogen werden. Diese planen anhand von globalen Stati der Planungsdomäne und ihren Diensten und nicht durch den Austausch einzelner Nachrichten. Für die Anwendung des MBP im Bereich der WS ist zu beachten, dass das Verhalten von Web Diensten über eine Menge von Zuständen im Zustandsübergangsgraphen abgebildet wird. Web Dienste definieren jedoch ihr Verhalten in Abhängigkeit vom fortlaufenden Nachrichtenaustausch, so dass ihr Zustand nur selten bekannt ist. Alle diese Ansätze der semantischen Web Service Komposition nutzen neben den normalen Input- und Outputwerten auch Angaben über Vorbedingungen und Auswirkungen, um die semantisch sinnvolle Verknüpfung der Dienste zu gewährleisten. Diese Angaben werden in formalisierter Form sowohl von OWL-S verwendet, als auch in AI-Planern, wo sie durch bedingte Zustände in den entspre-

166 162 J. Alpers chenden Automaten dargestellt werden. Die Angaben unterstützen Web Service Planer dabei u.a. Bedingungen festzulegen, die über den gesamten Planungsverlauf gelten sollen. Durch die Weiterentwicklung des MBP und die Möglichkeit die Domänen in PDDL zu beschreiben, so dass auch externe PDDL-Modelle genutzt werden können, hat zur Kompatibilität mit WS-Standards beigetragen und den Anpassungsaufwand von vorhandenen Daten gesenkt. Auch durch die Möglichkeit der Umwandlung von OWL-S (DAML-S) nach PDDL (vgl. [17]) kann bestehende WS-Semantik genutzt werden und muss nicht in separater Form für AI-Planer neu definiert werden. Literatur [1] u. Beek, Maurice H. ter. A survey on service composition approaches: From industrial standards to formal methods. Istituto di Scienza e Tecnologie dell Informazione, Pisa, Italy, [2] P. C. A. P. M. R. M. T. P. Bertoli. Mbp: a model based planner ITC-IRST, Trento (Italien). [3] B. Biplav Srivastava and J. Koehler. Web service composition - current solutions and open problems. p4ws/papers/srivastava-icaps2003-p4ws.pdf, Abgerufen: , [4] R. E. Bryant. Symbolic boolean manipulation with ordered binary-decision diagrams. School of Computer Science, Carnegie-Mellon University, Pittsburgh [5] A. H. Cardoso, Jorge; Sheth. Semantic web services and web process composition. First International Workshop, SWSWPC, San Diego, CA, USA, Springer Verlag Juli [6] J. Eder. Conceptual modeling of web service conversations. Advanced Information Systems Engineering, Springer Verlag, S , Berlin/Heidelberg, [7] M. Ghallab, D. Nau, and P. Traverso. Automated planning - theory and practice. Morgan Kaufmann Publishers, S , San Fransisco, USA, [8] B. Heinrich and F. Lautenbacher. Semantisches prozessmanagement - ein ansatz zur automatisierten planung von prozessmodellen. ehrstuhl für Betriebswirtschaftslehre, Wirtschaftsinformatik & Financial Engineering; Programmierung verteilter Systeme, Universität Augsburg [9] M. Jeckle. Semantik, odem einer service-orientierten architektur, Abgerufen: [10] M. Jeckle. Semantik und web services: Beschreibung von semantik, Abgerufen: [11] M. u. Jeckle. Semantik und web services: Vokabulare und ontologien, Abgerufen: [12] A. u. Klutsch, Matthias; Gerber. Semantic web service composition planning with owls-xplan. German Research Center for Artificial Intelligence, Saarbrücken, [13] D. E. u. Martin. Owl-s: Semantic markup for web services. Abgerufen:

167 Semantic Web Service Composition 163 [14] M. u. Martin, David; Paolucci. Bringing semantics to web services: The owl-s approach. Semantic Web Services and Web Process Composition Cardoso, Jorge; Sheth,Amit (Hrsg.), First International Workshop, SWSWPC, San Diego, CA, USA, Springer Verlag, Juli [15] D. u. Nau. Shop2: An htn planning system. Journal of Artificial Intelligence Research, Ausg. 20 (2003), S , URL: jair.pdf. [16] M. Pistore. Ws-gen: A tool for the automated composition of semantic web services. [17] J. Rao. Semantic web service composition via logic-based program synthesis. Department of Computer and Information Science, Norwegian University of Science and Technology, Trondheim, Norwegen. [18] B. Sirin, Evren; Parsia. Planning for semantic web services. Computer Science Department, University of Maryland, [19] Website. Mbp:a model based planner. Letztes Update: , Abgerufen:

168 Semantic Web: Proof, Trust und Security Martin Haslinger Universität Augsburg Zusammenfassung In dieser Seminararbeit sollen die Gesichtspunkte Sicherheit (Security), Vertrauen (Trust) und Beweisführung (Proof) im Umfeld des Semantic Web betrachtet werden. Es werden allgemeine Techniken, aktuelle Fortschritte und Ansätze zur Spezifikation und Standardisierung dieser Bereiche aufgezeigt. Zu jedem Aspekt wird weiterhin noch ein Ansatz detaillierter vorgestellt. 1 Einleitung Semantic Web ist neben Web 2.0 und Ajax eines der meistgenutzten Schlagworte im Bezug auf die Zukunft des Internets. Während sich Ajax auf die Präsentation und Web 2.0 auf die Mensch-Mensch Interaktion beziehen, ist das Semantic Web zur Verbesserung der Kommunikation zwischen Rechnern, sogenannten Software Agenten, gedacht. Informationen sollen so aufbereitet werden, daß sie für Maschinen den selben Informationsgehalt darstellen wie für den Menschen. Diese Vision von Tim Berner-Lee vom W3C stammt bereits aus dem Jahr 1998.[5] Die Softwareagenten sollen nicht nur wie bisher nach Schlagworten und Zusammenhängen suchen können, sondern die Inhalte des Webs in ihrer Bedeutung erfassen. Schließlich sollen von ihnen die Daten über mehrere Quellen hinweg zusammengefasst werden, um inhaltlich korrekte Ergebnisse zu liefern. Zur Spezifikation von Semantic Web Diensten hat das W3C mit dem Semantic Web Stack (Abbildung 1) eine mehrschichtige Architektur entworfen. Semantische Web Services basieren demnach auf URI[6] bzw. IRI[13] Resourcen und werden in dem auf XML[8] basierenden RDF[4] beschrieben. Um Abfragen auf den RDF Strukturen zu definieren wird die Sprache SPARQL (SPARQL Protocol and RDF Query Language)[27] verwendet. Regeln für die Behandlung der RDF Daten werden im Rule Interchange Format (RIF)[7] spezifiziert. Das Semantic Web nutzt für die Verarbeitung Ontologien. Um diese wiederzugeben wird das auf RDF basierende OWL[23] genutzt. Bevor jedoch Semantic Web Dienste von Applikationen angesprochen werden, müssen die Daten noch mittels einer vereinheitlichten Logik einen Beweis für ihre Richtigkeit anfügen. Die bisher erwähnten Bestandteile des Stacks sind gemäß Spezifikation zusätzlich über ein Crypto-Verfahren abzusichern. Schließlich sollten noch Informationen bezüglich der Vertrauenswürdigkeit des Inhalts beigefügt werden. Mit dem momentanen Stand der Forschung sind noch nicht all diese Schichten vollständig spezifiziert worden. Während für die unteren Schichten inkl. Abfrage, Regelaustausch und

169 Sem. Web Proof, Trust, Security 165 Abbildung 1. W3C Semantic Web Stack Ontologien bereits Standards existieren, fehlen solche speziell noch in Bereichen Proof und Trust. Als Schwerpunkt dieser Arbeit sollen im weiteren Konzepte und Beispiele für die Bereiche Proof, Trust und Security im Semantic Web dargestellt werden. Dabei werden zunächst Gründe für die Behandlung dieser Bereiche dargelegt, anschließend sollen für die einzelnen Bereiche in der Reihenfolge Security, Trust, Proof jeweils allgemeine Erläuterungen und Konzepte und anschließend ein Überblick über die Konzepte im Umfeld des Semantic Web gegeben werden. Es wird jeweils noch ein konkretes Konzept pro Teilgebiet erläutert: die KAoS Policy Language für Security in Kapitel 2, das transitive Trust Modell am Beispiel von FOAF in Kapitel 3 und die Darstellung von Beweisen mit Hilfe von PML im Semantic Web im vierten Kapitel. 2 Security Der Aspekt der Security ist im Gegensatz zu Trust und Proof nicht als eigenständige Schicht im W3C Web-Stack (Abb. 1) enthalten. Jedoch zieht sich ein Teilbereich der Security, die Verschlüsselung (im Stack mit Crypto bezeichnet),

170 166 M. Haslinger von der URI/IRI- bis zur Proof-Schicht fast durch den kompletten Stack. Im Umfeld des Semantic Web ist es also wichtig alle Schichten gleichsam abzusichern, um keine Sicherheitslücken aufzureißen. Der Gesichtspunkt Security umfasst dabei einen weiten Bereich von Verschlüssung und Privacy bis hin zu Autorisierung und Digital Rights Management (DRM). Ein besonderes Augenmerk muss dabei auf die Schichten gelegt werden, die nicht in klassischen Webanwendung vorhanden sind, sowie die XML Datenstrukturen. 2.1 Klassische Security Mechanismen Einigen dieser Sicherheitsaspekte kann mit bewährten Mitteln begegnet werden, für andere wiederum gibt es aufgrund der fehlenden Berücksichtigung der Semantik keine Lösungsansätze aus dem Umfeld des klassischen Web. Zur Absicherung der Daten gegenüber dem unberechtigtem Zugriff Dritter gibt es heutzutage viele Lösungen. Die bekanntesten sind sicherlich die in der Kommunikation eingesetzten Verfahren OpenPGP[9] und S/MIME[3], sowie das aus dem klassischen WWW bekannte X.509 Public Key Verfahren[19], das bei SSL verschlüsselten Seiten (HTTPS Protokoll) verwendet wird. Speziell für die Verschlüsselung von XML Dokumenten gibt es darüber hinaus noch weniger bekannte Methoden, wie XMLEnc.[21][20] Eine gebräuchliche Methode zur Überprüfung von Zugriffsrechten sind Access Control Lists (ACL), sie werden heute auf vielen Web Seiten in Form von htaccess Dateien und im Betriebssystemumfeld verwendet. Aufgrund ihrer fehlenden Semantik und Aufwändigkeit sind sie aber für das Semantic Web Umfeld nicht brauchbar. Bessere Ansätze finden sich im Bereich der Web Services mit den OASIS 1 Standards Web Service Security (WSS)[1] und Extensible Access Control Markup Language (XACML)[26], sowie der für XML Dokumente ausgelegten XML Role-Based Access Control (X-RBAC).[20][22] Aber auch diese traditionellen Systeme sind nicht geeignet, da sie zumeist einen zentralen Server benötigen, die Semantik weiterhin unberücksichtigt lassen und in größeren verteilten Systemen nicht skalieren. Auch ist es anzuzweifeln, ob eine Trennung in Authentifikation und Zugriffskontrolle weiterhin sinnvoll ist.[15][30] 2.2 Semantische Sicherheitsansätze Während sich traditionelle Ansätze zur Verschlüsselung wie OpenPGP, S/MIME oder XMLEnc weiterhin nutzen lassen, indem sie einfach eingebettet werden, müssen für die Zugriffsverwaltung und Authentifikation neue Möglichkeiten erschloßen werden. Als spezielle Ansätze für das Semantic Web wurden Kombinationen von Web Ontology Language (OWL)[23] und Policy Languages entwickelt. KAoS 2 und Rei 3 sind zwei der bekannteren Projekte in diesem Gebiet

171 Sem. Web Proof, Trust, Security 167 Policies definieren Zugriffsrechte und Regeln, die das Verhalten der Systemkomponenten dynamisch regulieren. Diese können je nach Policy Sprache auch zur Laufzeit angepaßt werden.. Hierbei können sowohl bestehende Policies geändert, als auch neue Policies und Domänen angelegt werden. Dadurch kann dynamisch reagiert werden anstatt das komplette System im voraus zu planen. Die Verwendung von Semantic Web Ontologien hat dabei sowohl Vor- als auch Nachteile. Als Vorteile, die durch die Verwendung von Semantiken entstehen, wären zu nennen: Die Modellierung komplexer Regelsysteme wird vereinfacht. Durch die hohe Anzahl an Abstraktionsebenen in den Ontologien wird die Aussagekraft bezüglich des Kontextes erhöht und Änderungen sind leicht vorzunehmen. Neue Konzepte können den Ontologien dabei leicht hinzugefügt werden. In nicht-semantischen Policy Sprachen ist dies nur schwer zu erreichen. Durch diese gute Anpassbarkeit eignen sich semantische Policies schließlich auch für eine Wiederverwendung in künftigen Systemen und müssen nicht immer von Grund auf neu entstehen. Bestende Policies werden einfach angepaßt und erweitert. Ein großer Vorteil von semantischen Policies ist zudem die ihre Analysierbarkeit. Diese ist wichtig für die Entdeckung von Widersprüchen in den Regeln und vereinfacht den Zugang zu den Policy Informationen, wodurch auch die dynamische Berechnung von Beziehungen zwischen den Policies und der Umgebung möglich werden. Ähnlich wie in Datenbanken kann hierzu gezielt gesucht werden, indem man das Ontologieschema für Abfragen nutzt. Die Analysierbarkeit kann desweiteren für die Verifizierung genutzt werden und erhöht durch das leichte auffinden bestimmter Teile die Effizienz gegenüber Policies ohne Semantik. Jedoch entstehen hierbei auch technische Schwierigkeiten: Die Erzwingung der Regeln ist ein kritischer Punkt. Policies, die speziell für das Semantic Web entwickelt wurden, sind oftmals schwer zu integrieren. Grund dafür ist, daß die Spezifikation der Ontologie basierten Policies von der konkreten Implementierung weit entfernt sein kann. In einer heterogenen Umgebung muß eine Übereinkunft über eine gemeinsam verwendete Ontologie getroffen werden. Als unbestreitbarer Nachteil muß zudem angemerkt werden, daß die Verwendung und Modellierung für den Benutzer nicht leichter wird, sondern die Regeln im Gegenteil schwerer lesbar und verwaltbar werden. Dies kann aber durch graphische Oberflächen, welche einem den Umgang mit der konkreten Syntax abnehmen, verbessert werden.[30][28] Diese Probleme lassen sich zum Teil noch nicht automatisiert lösen. Doch für die Autoren von [28] zeigte sich aus Erfahrungen, daß die genannten Vorteile der Verwendung von Semantic Web Ontologien den Nachteilen deutlich überliegen.

172 168 M. Haslinger 2.3 KAoS Policy Language Am meisten Erwähnung unter den speziell für das Semantic Web entwickelten Policy Languages finden bisher die bereits erwähnten Projekte KAoS und Rei. Die Entwicklung von KAoS begann bereits Mitte der 1990er und dauert bis heute an. Es entwickelte sich aus einer Sammlung plattformunabhängiger Services zur Definition von Policies über eine Policy Language auf DAML Basis zur heutigen auf OWL basierten Version. Es werden Ontologien zur Beschreibung und Beweisführung von Domänen genutzt. Diese Domänen können dabei Personen, Agenten und andere computergestützte Akteure sein. KAoS wird in einer Vielzahl von Anwendungen, wie z.b. Web Services, Mensch-Maschinen Zusammenarbeit in der Raumfahrt oder Kriegsführung, verwendet. KAoS Domain Services stellen die Möglichkeit zur Organisation in Domänen und Subdomänen für Softwarekomponenten, Personen etc. zur Verfügung. KAoS Policy Services erlauben die Spezifikationen von Policies innerhalb der Domänen. Dabei wird zwischen Autorisation, dem Erlauben oder Verbieten bestimmter Vorgänge, und Bedingungen, z.b. der Ausführung einer bestimmter Aktion vor einer anderen, unterschieden. Nennenswert sind, daß KAoS nicht annimmt, daß das Policy gestützte System aus homogenen Komponenten besteht. KAoS kann, wie bereits zuvor vorgestellt, Policies dynamisch zur Laufzeit ändern. Das Framework kann auf eine Vielzahl an Plattformen zur Erzwingung der Policies ausgedehnt werden und ist darauf ausgelegt anpassbar und robust, auch in Bezug auf Angriffe und Ausfälle, zu sein. KAoS Policies sind in der aktuellen Version eine Ontologie auf OWL Basis, die sogenannte KAoS Policy Ontologie (KPO). Es existieren momentan mehr als 100 Klassen und Attribute in der Basisontologie. Eine Policy ansich ist dabei eine Instanz eines der vier vordefinierten Policy Typen. Komplexe Policies werden direkt aus diesen Typen zusammengesetzt. Jede spezifizierte Domäne kann sich entweder nach dem demokratischen oder dem tyrannischen Prinzip verhalten. Es ist also entweder alles erlaubt, was nicht explizit verboten ist oder alles verboten, was nicht explizit erlaubt wird. Konflikte die zwischen verschiedenen Policies auftreten versucht KAoS selbstständig zu lösen. Die Algorithmen dazu wurden als Erweiterung zu Stanfords Java Theorem Prover (JTP)[16] implementiert und in KAoS integriert. Die Lösung der Konflikte erfolgt dabei über Ordnung der Policies nach Präzedenz und wenn nötig Generierung neuer harmonisierender Regeln. Das Reasoning wird bei KAoS ebenfalls mithilfe von JTP bewältigt. In Listing 10.1 ist ein Beispiel analog zu [28] abgebildet. 4 Es modelliert folgenden Sachverhalt in der KAoS Ontologie: professors are permitted to communicate the final examination grade to their students using an encrpted communication only after the approval of the institute s director [28] Die Spezifikation ist zweigeteilt. Der erste (Zeilen 10-31) definiert die Aspekte des regulierten Teils in einer einzigen OWL Klasse. Informationen zum Policy Management befinden sich im zweiten Teil (Zeilen 33-37) und sind damit komplett getrennt. Im ersten Teil werden die drei Restriktionen aufgestellt. In den Zeilen wird definiert, daß die Aktion von einem Professor ausgeführt werden muß. Daß der Empfänger 4 Das Original Beispiel verwendete noch DAML statt OWL. Es wurde an die neuere KAoS Spezifikation angepaßt.

173 Sem. Web Proof, Trust, Security 169 ein Student sein muß wird durch eine zweite Restriktion in den Zeilen bestimmt. Die Bedingung der Zustimmung des Direktors des Institutes ist in den Zeilen als weitere Restriktion definiert. Diese Bedingungen sind in der Klasse der auszuführenden Aktion der verschlüsselten Kommunikation (ab Zeile 10) enthalten. Im zweiten Teil wird schließlich in Zeile 38 die Absenderseite (Subject) als derjenige definiert, der die Einhaltung sicherstellen muß und in Zeile 39 die Priorität der Policy auf 10 gesetzt. Listing KAoS Beispiel <? xml version =" 1.0 "?> 2 < rdf:rdf xmlns:rdf =" http: // /1999/02/22 - rdf - syntax -ns#" xmlns:rdfs =" http: // /2000/01/ rdf - schema #" 4 xmlns:owl =" http: // www. w3. org /2002/07/ owl #" xmlns:xsd =" http: // www. w3. org /2000/10/ XMLSchema #" 6 xmlns:policy =" http: // ontology. coginst. uwf. edu / Policy. owl #" xmlns=" http: // ontology. coginst. uwf. edu / ExamplePolicies / PolicyExample. owl #" > 8 <owl:ontology rdf:about ="" / > <! > 10 <owl:class rdf:id =" ExaminationGradePolicyAction " > <owl:intersectionof rdf:parsetype =" owl:collection " > 12 <owl:class rdf:about =" http: // ontology. coginst. uwf. edu / Action. owl # EncryptedCommunicationAction "/ > 14 <owl:restriction > <owl:onproperty rdf:resource =" http: // ontology. coginst. uwf. edu / Action. owl # performedby "/ > 16 <owl:toclass rdf:resource =" http: // ontology. coginst. uwf. edu / ActorClasses. owl # AgentProfessors "/ > </ owl:restriction > 18 <owl:restriction > 20 <owl:onproperty rdf:resource =" http: // ontology. coginst. uwf. edu / Action. owl # hasdestination "/ > <owl:toclass rdf:resource =" http: // ontology. coginst. uwf. edu / ActorClasses. owl # AgentStudents "/ > 22 </ owl:restriction > 24 <owl:restriction > <owl:onproperty rdf:resource =" http: // ontology. coginst. uwf. edu / Action. owl # hasapproval "/> 26 <owl:toclass rdf:resource =" http: // ontology. coginst. uwf. edu / ActorClasses. owl # AgentInstituteDirector "/ > </ owl:restriction > 28 </ owl:class > 30 </ owl:intersectionof > </ owl:class > 32 <policy:posauthorizationpolicy rdf:id =" ExaminationGradePolicy " > 34 <policy:controls rdf:resource ="# ExaminationGradePolicyAction "/ > <policy:hassiteofenforcement rdf:resource =" http: // ontology. coginst. uwf. edu / Policy. owl # SubjectSite "/> 36 <policy:haspriority >10</ policy:haspriority > <policy:hasupdatetimestamp > </ policy:hasupdatetimestamp > 38 </ policy:posauthorizationpolicy > Zur einfacheren Administration existiert ein KAoS Policy Administration Tool (KPAT) genanntes Werkzeug. Dadurch wird die bereits erwähnte Benutzerfreundlichkeit einer semantischen Policy Language hergestellt. Ohne dieses Programm wäre aufgrund der Komplexität wohl nur eine geringe Verbreitung zu erwarten. Es kann sowohl Policies definieren, anzeigen, analysieren, und Konflikte lösen, als

174 170 M. Haslinger auch Ontologien verwalten. Der Anwender kommt dabei mit den komplexen OWL Strukturen nicht direkt in Kontakt. Diese werden im Hintergrund selbstständig von KPAT erzeugt. Somit ist es auch technisch nicht versierten Nutzer möglich mit KAoS Policies zu arbeiten. Abbildung 2. KPAT Da alle KAoS Policies in reinem OWL repräsentiert werden kann jedes Programm bzw. jede Umgebung eines Drittherstellers eigenständig auf diesen arbeiten unabhängig von KAoS selbst. Dies läßt große Möglichkeit für den Einsatz und die Erweiterung der Policy Language offen. So wird es neben den bereits zuvor erwähnten Projekten auch mit grid computing services der Globus Plattform 5 genutzt. Globus stellt ein effektives Resourcenmanagement, Authentication und lokale Resourcenveralten zur Verfügung, benötigt jedoch zusätzliche Domain und Policy Services. KAoS stellt hierfür eine große Reichweite im Policy Management bereit. Mit Hilfe eines Interfaces zwischen dem Globus Grid und KAoS können diese Policies in der GSI (Grid Security Infrastructure) genutzt werden. Das Interface stellt in diesem Fall selbst einen Grid Service dar. Grid Clients und Dienste können über dieses Interface prüfen, ob eine Aktion gemäß der Policies erlaubt ist. [29] 3 Trust Vertrauen ist heutzutage noch sehr wenig beachtet im Internet, denn bisher sitzen meist Menschen vor dem Rechner und suchen manuell nach Informationen. Dabei weiß jeder für sich selbst, welchen Informationen er vertrauen will und welchen 5