Eberhard-Karls-Universität Tübingen Wilhelm-Schickard-Institut für Informatik

Sand 13

D-72076 Tübingen

Studienarbeit

Eingereicht am 5. April 2007 bei Prof. Dr. Herbert Klaeren

Betreuer: Dipl.-Inform. Mandeep Singh Multani

ONTOLOGIEINTEGRATION IM JADE-UMFELD:

EIN ÜBERBLICK

Nils Löber

Am Stadtgraben 19

72070 Tübingen

nils@nils-loeber.de

Matrikelnummer: xxx

Philosophie / EKW / Informatik (M.A.)

12. Fachsemester

2

3

Abstract

Autonome Agentensysteme und das Semantic Web sind zwei höchst viel versprechende

Technologien mit potentiell unerschöpflichen Anwendungsgebieten. Der Gedanke hinter

Agenten ist es, eine anthropomorphe Einheit - den Agenten - zu erschaffen, der seinen

Besitzer in der virtuellen Welt vertritt und in dessen Auftrag handelt. Von dieser Vision ist

die Forschung derzeit noch recht weit entfernt. Es fehlt an technischen und konzeptionellen

wie an rechtlichen Voraussetzungen.

Eines der technischen Probleme, das zu lösen ist, ist das der Semantik („Wie ist

sichergestellt, dass zwei kommunizierende Agenten dasselbe meinen?―), und dort speziell das

der Ontologieintegration. Im Kontext der Informatik sind Ontologien (meist hierarchische)

Datenstrukturen, mit deren Hilfe das domänenspezifische oder allgemeine Weltwissen der

Agenten kodifiziert wird.

Es gibt sowohl das Problem der vertikalen Übersetzung verschiedener Ontologieformate (z.B.

OWL in JADE-Ontologien) als auch das Problem der horizontalen Übersetzung

verschiedener Ontologien ineinander (z.B. Laienterminologie Medizin in Fachterminologie

Medizin oder die Taxonomie amerikanischer Restaurants in die japanischer Restaurants).

Letzteres Problem wird in der vorliegenden Arbeit im Kontext der weit verbreiteten

Agentenplattform JADE untersucht. Dabei wird ohne Anspruch auf Vollständigkeit ein

Überblick über die ontologiebezogenen Features von JADE, über das Problem der

Ontologiezuordnung im Allgemeinen sowie über vorhandene Lösungsansätze im JADE-

Umfeld gegeben.

4

5

INHALT ABBILDUNGSVERZEICHNIS ............................................................................................................. 7

1. EINFÜHRUNG................................................................................................................................... 9

1.1 MOTIVATION ............................................................................................................................. 9

1.2 AUFBAU .................................................................................................................................... 11

2. DAS UMFELD ................................................................................................................................. 13

2.1 AGENTEN .................................................................................................................................. 13

2.1.1 Die FIPA-Standard-Suite ..................................................................................................... 13

2.1.2 Agentenplattform Agentcities .............................................................................................. 14

2.2 JADE ........................................................................................................................................... 15

2.3 ONTOLOGIE ............................................................................................................................. 17

2.3.1 Definition ............................................................................................................................. 17

2.3.2 Forschung ............................................................................................................................. 17

2.4 ONTOLOGIESPRACHEN AUS DEM W3C-UMFELD ........................................................... 18

2.4.1 XML + NS + XML Schema ................................................................................................. 19

2.4.2 RDF und RDF Schema ........................................................................................................ 21

2.4.3 OWL .................................................................................................................................... 23

2.5 EXKURS: FOLKSONOMIES ........................................................................................................ 24

3. ONTOLOGIEIMPLEMENTIERUNG IN JADE ............................................................................. 27

3.1 BAUSTEINE DER ONTOLOGIEIMPLEMENTIERUNG VON JADE ................................... 27

3.2 PROGRAMMATISCHE UMSETZUNG IN JAVA .................................................................. 28

3.3 NACHRICHTENVERSAND ..................................................................................................... 33

3.3.1 Andere Kommunikationssprachen ............................................................................................... 33

3.4 WERKZEUGUNTERSTÜTZTE ONTOLOGIEIMPLEMENTIERUNG IN JADE ................. 34

6

4. ONTOLOGIEZUORDNUNG (ONTOLOGY MAPPING) ............................................................. 35

4.1 BEGRIFFS- und PROBLEMABGRENZUNG .......................................................................... 35

4.2 BASISONTOLOGIEN ............................................................................................................... 38

4.3 METHODEN DER ONTOLOGIEZUORDNUNG .................................................................... 41

5. ONTOLOGIEZUORDNUNG IN JADE .......................................................................................... 45

5.1. FIPA-OA .................................................................................................................................... 45

5.1.1 Anforderungen an den Ontology Agent ............................................................................... 45

5.1.2 Die FIPA-Meta-Ontology .................................................................................................... 46

5.1.3 Die vorgeschlagene Architektur ........................................................................................... 48

5.2 DIE ONTOLOGY MAPPING PLATFORM VON LI/YANG/WU ........................................... 49

5.4 DESIGNÜBERLEGUNGEN ZU ONTOLOGIEZUORDNUNGSPLATTFORMEN ............... 53

6. ZUSAMMENFASSUNG UND AUSBLICK ................................................................................... 55

LITERATURVERZEICHNIS .............................................................................................................. 57

7

ABBILDUNGSVERZEICHNIS

Abbildung 1: Das JADE-GUI mit den zwei Standardagenten DF und AMS und dem GUI-Agenten im

Main-Container ..................................................................................................................................... 15

Abbildung 2: Die FIPA-Referenzarchitektur für Agentenplattformen (aus [Bellifemine et. al 2006]) 16

Abbildung 3: Der Semantic Web Stack des W3C (Quelle: http://www.w3.org/2000/Talks/1206-

xml2k-tbl/slide10-0.html) ..................................................................................................................... 18

Abbildung 4: Tagging bei YouTube ..................................................................................................... 24

Abbildung 5: Tagging bei del.icio.us .................................................................................................... 24

Abbildung 6: Ein getaggter Link in del.icio.us (Detail) ....................................................................... 25

Abbildung 7: Das UI des Beangenerator-Plugins ................................................................................. 34

Abbildung 8: Ein kleiner Ausschnitt der UNSPSC-Taxonomie für Produkte und Dienstleistungen ... 39

Abbildung 9: Ausschnitt aus der Suggested Upper Merged Ontology (SUMO) in HTML-Darstellung

.............................................................................................................................................................. 39

Abbildung 10: Taxonomie verschiedener Ontologiezuordnungsverfahren [Shvaiko 2004]................. 43

Abbildung 11: Das Ontology Service Reference Model aus dem FIPA-Standard XC00086 ............... 48

Abbildung 12: Die Architektur der Ontology Mapping Platform von [Li et al. 2006] ......................... 49

Abbildung 13: Die Benutzeroberfläche der Ontology Mapping Platform nach Schritt 5 [Li et al. 2006]

.............................................................................................................................................................. 51

8

9

1. EINFÜHRUNG

1.1 MOTIVATION

Der Benutzer heutiger, insbesondere vernetzter, Computersysteme, sieht sich einer

frustrierenden Situation ausgesetzt: Zwar sind mittlerweile eine geradezu unüberschaubare

Fülle von Waren und Dienstleistungen über Netzwerkanwendungen wie das WWW

verfügbar, für deren Nutzung muss er sich aber oft mit repetitiven, aber nicht einfach

automatisierbaren Vorgängen plagen. Alleine die Buchung einer Reise wird in den meisten

Fällen den Besuch auf einer Vielzahl von Websites erfordern, die jeweils unterschiedliche

Interfaces und Geschäftsbedingungen haben. Weil aber, trotz der inhaltlich geringen

Unterschiede der Daten der Anbieter, die Schnittstellen sehr verschieden sind (in den meisten

Fällen individuell gestaltete HTML-Seiten) und weil heutigen Programmen die Fähigkeit des

Verstehens von Inhalten abgeht, lässt sich ein solcher Suchvorgang nur schwer

automatisieren.

Tim Berners Lee skizziert einen anschaulichen Use Case für ein zukünftiges WWW, anhand

dessen kontrastiv deutlich wird, wie heute noch selbst relativ triviale Alltagsaufgaben viele

einfache, aber nicht automatisierbare Arbeitsschritte erfordern1:

The entertainment system was belting out the Beatles' "We Can Work It Out" when the

phone rang. When Pete answered, his phone turned the sound down by sending a message to

all the other local devices that had a volume control. His sister, Lucy, was on the line from the

doctor's office: "Mom needs to see a specialist and then has to have a series of physical

therapy sessions. Biweekly or something. I'm going to have my agent set up the

appointments." Pete immediately agreed to share the chauffeuring.

At the doctor's office, Lucy instructed her Semantic Web agent through her handheld Web

browser. The agent promptly retrieved information about Mom's prescribed treatment from

the doctor's agent, looked up several lists of providers, and checked for the ones in-plan for

Mom's insurance within a 20-mile radius of her home and with a rating of excellent or very

good on trusted rating services. It then began trying to find a match between available

appointment times (supplied by the agents of individual providers through their Web sites)

and Pete's and Lucy's busy schedules. (The emphasized keywords indicate terms whose

semantics, or meaning, were defined for the agent through the Semantic Web.)

1 [Berners-Lee 2001]

10

In a few minutes the agent presented them with a plan. Pete didn't like it—University

Hospital was all the way across town from Mom's place, and he'd be driving back in the

middle of rush hour. He set his own agent to redo the search with stricter preferences about

location and time. Lucy's agent, having complete trust in Pete's agent in the context of the

present task, automatically assisted by supplying access certificates and shortcuts to the data it

had already sorted through.

Almost instantly the new plan was presented: a much closer clinic and earlier times—but

there were two warning notes. First, Pete would have to reschedule a couple of his less

important appointments. He checked what they were—not a problem. The other was

something about the insurance company's list failing to include this provider under physical

therapists: "Service type and insurance plan status securely verified by other means," the

agent reassured him.

Um einen solchen Use Case zu unterstützen, sind mindestens drei Technologien nötig: Web

Services (die strukturierte Abfragen auf die Datenbestände von Dienstanbietern

ermöglichen), Agenten (die die „Intelligenz― für einfache zielgerichtete

Koordinationsaufgaben haben) und Standards für maschinenles- und verarbeitbare Inhalte.

Letztere werden seit knapp zehn Jahren unter dem Stichwort Semantic Web diskutiert, haben

allerdings unter der Bezeichnung Knowledge Representation schon eine wesentlich längere

Vorgeschichte. Trotz zahlreicher Anstrengungen vor allem in der akademischen Forschung

ist diesen beiden Technologien der Durchbruch verwehrt geblieben. Um es wiederum mit

Berners-Lee zu sagen:

Knowledge representation, as this technology is often called, is currently in a state

comparable to that of hypertext before the advent of the Web: it is clearly a good idea, and

some very nice demonstrations exist, but it has not yet changed the world. It contains the

seeds of important applications, but to realize its full potential it must be linked into a single

global system.

Eine Voraussetzung für ein solches global interoperables System ist die Verwendung

gemeinsamer, oder zumindest teilweise übersetzbarer Annahmen der Agenten über die

Struktur ihrer Umgebung. Solche Systeme von Annahmen bezeichnet man als Ontologien, in

Anlehnung an jenen Teilbereich der Philosophie, der sich mit den „ersten Dingen―

beschäftigt, also mit den Grundlagen und der Beschaffenheit alles Existierenden. Eine

genauere Bestimmung dieses Begriffes folgt weiter unten. Für den Anfang reicht die

Feststellung, dass zwei Agenten, die nicht zumindest eine teilweise gemeinsame Ontologie

haben, nicht sinnvoll miteinander kommunizieren können.

11

1.2 AUFBAU

Die vorliegende Arbeit soll nach einer kurzen Begriffsbestimmung (Abschnitt 2) die

Fähigkeiten der Ontologierepräsentation in der verbreiteten Open-Source-Agentenplattform

JADE darstellen (Abschnitt 3). Daran schließt sich eine Überblicksdarstellung der

Herausforderungen bei der Ontologieabbildung generell samt den gängigen

Lösungsverfahren (Abschnitt 4). Zum Schluss wird eine Darstellung zweier

Ontologieabbildungsarchitekturen für die JADE-Plattform gegeben (Abschnitt 5), die in

einen zusammenfassenden Endteil überleitet (Abschnitt 6).

12

13

2. DAS UMFELD

2.1 AGENTEN

Im Laufe der Forschung über Agenten haben sich erwartbarerweise zahlreiche Definitionen

des Gegenstandes angesammelt, von denen Franklin und Graesser eine unvollständige

Übersicht erstellt haben [Franklin/Graesser 1997]. Als Essenz aller untersuchten Definitionen

halten sie fest:

An autonomous agent is a system situated within and a part of an environment that senses

that environment and acts on it, over time, in pursuit of its own agenda and so as to effect

what it senses in the future.

Für unseren speziellen Zusammenhang ist an dieser Definition zu ergänzen, dass in einem

Multi-Agent-System (MAS) wie JADE ein starkes Gewicht auf der Interaktion der Agenten

untereinander liegt. Folglich versteht der vorliegende Artikel Agenten also als eine Software,

die mittels Sensoren und Effektoren mit ihrer Umgebung über einen längeren Zeitraum

planvoll und zielgerichtet interagiert – insbesondere mittels des Versandes von Nachrichten

an andere Agenten.

Bei der Implementierung von Agentensystemen tauchen immer wieder die gleichen

Anforderungen auf, z.B. scheduling, message passing, agent discovery und einige mehr,

worauf die Forschung mit einer größeren Zahl von Agentenplattformen reagiert hat, die auf

offenen oder proprietären Verfahren basieren. Eine Übersicht hierzu bieten [Bordini et al.

2006].

2.1.1 Die FIPA-Standard-Suite

Keineswegs der einzige, aber ein weit verbreiteter Standard im Bereich der MAS ist der

FIPA-Standard oder besser gesagt: Die FIPA-Standard-Suite. Die FIPA (Foundation for

Intelligent Physical Agents) ist mittlerweile eine von der IEEE anerkannte

Standardisierungsorganisation, die 1996 in der Schweiz ins Leben gerufen wurde. Die FIPA

hat 33 Mitglieder aus universitärer und kommerzieller Forschung2. Anders als der Name

vermuten lässt („Foundation for Intelligent Physical Agents―), legt die FIPA in ihren

Standardisierungsbemühungen den Fokus nicht etwa auf die Robotik, sondern auf

2Für eine komplette Liste siehe http://www.fipa.org/about/joining.html.

14

Softwareagenten. Im Laufe ihres Bestehens hat die FIPA fast 100 Dokumente produziert, von

denen 25 zu Standards erhoben wurden3. Der relevanteste dieser Standards dürfte die FIPA-

ACL (Agent Communication Language) sein, die von zahlreichen Agentenplattformen

verwendet wird.

2.1.2 Agentenplattform Agentcities

Als praxisnahe Testumgebung für Anwendungen im Bereich der Agenteninteroperabilität

haben sich im Oktober 2001 14 Forschergruppen im Agentcities-Netzwerk

zusammengeschlossen, welches jedem interessierten Forscher ermöglicht, sich dem Netzwerk

mit einer eigenen FIPA-kompatiblen Plattform anzuschließen [Wilmott et al. 2001].

3 Eine Liste dieser Dokumente findet sich unter

http://www.fipa.org/repository/standardspecs.html.

15

2.2 JADE

Eine dieser Plattformen ist das Java Agent Development Framework (JADE), das vor allem

von der Forschungsabteilung der Telecom Italia entwickelt und als Open Source unter der

LGPL freigegeben wurde. JADE liegt zurzeit in der Version 3.4.1 vor. JADE bietet dem

Entwickler eine Laufzeitumgebung, in der die Agenten „leben― können, außerdem eine

Klassenbibliothek für die Entwicklung von Agenten, in der beispielsweise vorgefertigte

Klassen für Agenten-Verhaltensweisen (Behaviours) oder für die Serialisierung von

Nachrichten enthalten sind. Darüber hinaus stellt JADE auch eine grafische

Benutzeroberfläche für die Administration der Plattform und für das Debugging von Agenten

zur Verfügung. So ist es mit dem GUI vor allem möglich, interaktiv Agenten zu starten und

den Nachrichtenfluss zwischen Agenten grafisch zu überwachen.

Abbildung 1: Das JADE-GUI mit den zwei Standardagenten DF und AMS und dem GUI-Agenten im Main-Container

JADE ist als verteiltes System angelegt. Auf jedem Host laufen innerhalb einer Java-VM ein

Main-Container und optional mehrere weitere Container. Jeder Container kann beliebig viele

Agenten beherbergen. Die Container können auf einem Rechner oder verteilt im Netz laufen,

wobei jeder Agent eine eindeutige Adresse in der Form agent@plattform hat, z.B.

DF@nils-ws-xp:1099/JADE. Für die Kommunikation über Rechnergrenzen hinweg

greift JADE auf das RMI-API von Java zurück. Bei Benutzung der Erweiterung LEAP (Light

Extensible Agent Platform) ist auch die Kommunikation über HTTP möglich.

Dem FIPA Standard XC00023 folgend werden auf jedem Rechner innerhalb der Main-

Containers beim Start der Plattform zwei Agenten geladen: Das Agent Management System

16

(AMS) und der Directory Facilitator (DF). Der AMS registriert alle Agenten innerhalb der

Plattform (was auch als „White Page Service― bezeichnet wird) und übt Supervisor-

Funktionen über die anderen Agenten aus, kann also beispielsweise Agenten starten und

beenden. Der DF bietet einen sogenannten Yellow Page Service an, ermöglicht es also

anderen Agenten, bestimmte Services zu finden. In einem Reisebuchungsszenario wäre das

also beispielsweise ein Dienst, der Auskünfte über Hotelreservierungen oder

Mietwagenangebote geben kann.

Abbildung 2: Die FIPA-Referenzarchitektur für Agentenplattformen (aus [Bellifemine et. al 2006])

Bei der Entwicklung von JADE-Agenten stehen für den Programmierer zwei Aufgaben auf

der To-Do-Liste: Zum einen muss er Behaviours für den Agenten definieren und zum

anderen eine domänenspezifische Ontologie, sofern diese noch nicht existiert. Ein Behaviour

eines Agenten kann beispielsweise einschließen, auf Anfrage nach Produkten zu antworten,

oder verzeichnisartige Dienste zur Verfügung zu stellen. Die Summe der Behaviours legt die

Fähigkeiten des Agenten fest. Im Normalfall läuft der Agent dann, sobald er innerhalb eines

konkreten Containers bereitgestellt wurde, auf unbestimmte Zeit.

17

2.3 ONTOLOGIE

2.3.1 Definition

Ebenso wie für den Agentenbegriff gibt es für den Ontologiebegriff keine anerkannte

Standarddefinition. Häufig wird die Definition von Thomas Gruber zitiert:

An ontology is an explicit specification of a conceptualization. […] we can describe the

ontology of a program by defining a set of representational terms. In such an ontology,

definitions associate the names of entities in the universe of discourse (e.g., classes, relations,

functions, or other objects) with human-readable text describing what the names are meant to

denote, and formal axioms that constrain the interpretation and well-formed use of these

terms. [Gruber 1993]

Es geht also bei Ontologien um die formale Repräsentation von Weltwissen, meist bezogen

auf eine bestimmte Anwendungsdomäne, in Form von Begriffen und Beziehungen zwischen

diesen Begriffen. In welcher Form dieses Wissen abgebildet wird, unterscheidet sich in

Details sehr stark von Forschungsprojekt zu Forschungsprojekt. In der Regel gibt es aber eine

Hierarchie von Konzepten (Unterkunft, GewerblicheUnterkunft, Hotel, Kunde, Buchung

usw.) sowie eine Hierarchie von Prädikaten (istBelegt, zahltMitKreditkarte, besitzt,

istGeschäftsfähig etc.). Manche Ontologieimplementiereungen erlauben auch die Definition

von Axiomen, mit denen sich weitaus komplexere Teile des Weltwissens erfassen lassen.

Axiome werden in der Regel mit Varianten der Prädikatenlogik ausgedrückt. Die Ontologie

in Verbindung mit den konkreten Instanzen von Konzepten und Prädikaten, die eine konkrete

Welt aus vielen mit der Ontologie darstellbaren möglichen Welten abbilden, bezeichnet man

manchmal auch als Knowledge Base.4

2.3.2 Forschung

Es gibt aus verschiedenen Feldern der Informatik (vor allem KI-Forschung, der

Datenbankforschung sowie unter dem Stichwort „Semantic Web―) Beiträge zur

Ontologierepräsentation. Eine Übersicht über eine Vielzahl von Forschungsprojekten aus

Universität und Wirtschaft bietet [Gómez-Pérez 2002].

4 Die hier aufgeführten Begriffserklärungen lehnen sich an http://www-ksl-

svc.stanford.edu:5915/doc/frame-editor/glossary-of-terms.html an.

18

2.4 ONTOLOGIESPRACHEN AUS DEM W3C-UMFELD

Für die Darstellung von Ontologien in Form von Nachrichten gibt es etwa zwei dutzend

ausgearbeiteter Spezifikationen5, wobei die momentan verbreitetsten KIF (Knowledge

Interchange Format)6 aus der KI-Forschung sowie RDF(S) und OWL aus dem Semantic

Web-Umfeld sein dürften7. Die einschlägigen W3C-Standards werden gerne in Form eines

Stacks dargestellt (auch als „W3C Semantic Web Layer Cake― bezeichnet). Im Folgenden

soll exemplarisch für Ontologiesprachen im Allgemeinen ein kurzer Überblick über die

ontologierelevanten Schichten daraus gegeben werden.8 Für einen generellen Überblick über

Knowledge Representation-Sprachen im Zusammenhang mit Agenten siehe [Grütter 2006].

Abbildung 3: Der Semantic Web Stack des W3C (Quelle: http://www.w3.org/2000/Talks/1206-xml2k-tbl/slide10-0.html)

5 http://en.wikipedia.org/wiki/Ontology_Languages_%28computer_science%29

6 Weitere Informationen zu KIF finden sich unter http://logic.stanford.edu/kif/dpans.html.

7 Historisch ist auch noch DAML+OIL von Interesse, das aber als Vorgängerversion des

OWL-Standards des W3C aufzufassen ist (vgl. [McGuinness/van Harmelen 2004]).

8 Die Darstellung stützt sich dabei, bis auf die Beispiele, auf [Antoniou/van Harmelen 2004],

wo nicht anders angegeben.

19

2.4.1 XML + NS + XML Schema

XML (Extensible Markup Language)9 ist eine Metasprache, die erlaubt,

Anwendungssprachen zu definieren. XML schafft eine Basis für die Normierung von

Dokumentenformaten, indem es eine Reihe von basalen Mechanismen für die Auszeichnung

von Daten mit Metadaten bereitstellt. Dokumente werden in XML aufgefasst als beschriftete,

geordnete, gerichtete azyklische Graphen mit einem Wurzelknoten. Für diese Datenstruktur

definiert XML eine Serialisierung in Form einer Textdatei, in der (etwas vereinfacht

dargestellt) Text, Tags und Attribute vorkommen können. Ein Beispiel für ein einfaches

XML-Dokument könnte so aussehen:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<companies>

<company name=”SNPP”>

<employees>

<employee id=”123”>Homer Simpson</employee>

<employee id=”123”>Waylon Smithers</employee>

<employee id=”123”>Frank Grimes</employee>

</employees>

</company>

<company>

…

</company>

</companies>

Was XML also leistet, ist die Normierung der menschen- und maschinenlesbaren Annotation

von Daten. Der Nutzen von XML wird schnell deutlich, wenn man an die vielen nicht auf

XML aufbauenden textbasierten und binären Datenformate denkt, für die jeweils eigene

Tools programmiert werden müssen und bei denen sich die Struktur meist aus dem Standort

der Daten in der Datei ergibt (z.B. „alle 500 Bytes beginnt ein neuer Eintrag, von dem die

ersten 20 Bytes ein Firmenname sind―).

In einem XML-Dokument sind beliebige Tags und Attribute in beliebiger Kombination

erlaubt10

. In vielen Anwendungen ist es aber nützlich, diesbezüglich syntaktische

9 Die aktuelle Version das Standards ist 1.1 (http://www.w3.org/TR/2006/REC-xml11-

20060816/)

10 Es dürfen natürlich keine Tags ineinander verschachtelt sein, was sich aus dem obigen Satz

über die Baumstruktur eines XML-Dokumentes auch ergibt.

20

Einschränkungen treffen zu können, um beispielsweise festlegen zu können, dass ein

<employees>-Tag nur innerhalb eines <company>-Tags stehen darf. Für solche Definitionen

stehen eine ganze Reihe von Beschreibungssprachen zur Verfügung11

, von denen DTDs,

Relax NG und XML Schema12

am weitesten verbreitet sein dürften. Mit Hilfe eines Schemas

kann ein Validator feststellen, ob ein bestimmtes XML-Dokument den Anforderungen eines

bestimmten Schemas genügt; Man spricht dann auch davon, das XML-Dokument sei valid in

Bezug auf das Schema.

Reines XML enthält allerdings (ob mit Schema oder ohne) noch keine semantischen

Informationen über die Baumstruktur hinaus. Was (im obigen Beispiel) ein „Employee― ist,

oder welche Beziehung er zu einer „Company― haben könnte, erschließt sich für eine

Software aus dem Dokument nicht.

Will man Elemente aus mehreren Schemata in einem Dokument verwenden, muss es einen

Mechanismus geben, der Namenskollisionen vermeidet. Hier kommt der XML NS-Standard

(XML Namespaces) ins Spiel. Ein Beispiel hierfür13

:

<?xml version="1.0"?>

<!-- initially, the default namespace is "books" -->

<book xmlns='urn:loc.gov:books'

xmlns:isbn='urn:ISBN:0-395-36341-6'>

<title>Cheaper by the Dozen</title>

<isbn:number>1568491379</isbn:number>

</book>

In diesem Beispiel werden zwei Namensräume eingebunden (urn:loc.gov:books und

urn:ISBN:0-395-36341-6). Ersterer ist wirksam, wenn bei einzelnen Tags kein

Namensraum explizit angegeben wird (z.B. im Tag <title>). Letzterer muss bei jedem ihn

verwendenden Tag angegeben werden (z.B. in <isbn:number>).

11 http://en.wikipedia.org/wiki/XML_schema

12 http://www.w3.org/XML/Schema

13 Entnommen aus dem W3C-Standard (http://www.w3.org/TR/REC-xml-names/)

21

2.4.2 RDF und RDF Schema

Wie bereits erwähnt, enthalten XML-Dokumente bis hierhin keine maschinenlesbaren

semantischen Informationen, noch nicht einmal, dass in unseren Dokumenten Aussagen über

Entitäten gemacht werden (schließlich ist dies ja – siehe XHTML – auch nicht immer

automatisch der Fall: Das Fragment <H1><STRONG>Hallo, Welt</STRONG></H1>

kodiert offensichtlich keine Aussage).

Angelehnt an das Entity-Relationship-Modell definiert RDF-Schema eine Semantik, mit der

Aussagen über Entitäten möglich werden. Hier ein einfaches Beispiel14

:

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<rdf:Description rdf:about="http://www.w3.org/">

<dc:title>World Wide Web Consortium</dc:title>

</rdf:Description>

</rdf:RDF>

Hier wird folgende Aussage gemacht: „Die Ressource mit der URL http://www.w3.org/ hat

als Title15

den Wert World Wide Web Consortium―. Dies illustriert eine wichtige Eigenschaft

von RDF, nämlich dass Aussagen in Form von Subjekt-Prädikat-Objekt-Tripeln gemacht

werden.

Darüber hinaus erlaubt RDF Angaben über Datentypen (Integer, String, usw.) für Entitäten

und definiert noch eine Reihe von Containerelementen. RDF erlaubt Aussagen über

Aussagen („P glaubt, dass S wahr ist―). Dies bezeichnet man auch als Reification.

Allerdings ist das Vokabular, über das Aussagen gemacht werden kann, immer noch

unstrukturiert. Abhilfe schafft hier das etwas unglücklich benannte RDF Schema. Die

Benennung ist deshalb etwas unglücklich, weil sie eine Verwandtschaft zu XML Schema

nahe legt. Im Gegensatz dazu definiert RDF Schema allerdings nicht die Struktur von RDF-

Dokumenten (die kann nämlich z.B. in XML Schema definiert werden), sondern die Struktur

14 Quelle: http://www.w3.org/RDF/Validator/

15 Der Namespace-Prefix DC bezieht sich auf Dublin Core, einen Metadatenstandard aus der

Welt der Bibliothekswissenschaft.

22

des Vokabulars, über das bzw. mit dem in RDF-Dokumenten Aussagen gemacht werden.

RDFS stellt zur Definition von Taxonomien unter anderem folgende Konstrukte bereit16

:

Rdfs:Resource - Klasse, die alle Entitäten enthält.

Rdfs:Class - Die Klasse aller Klassen. Rdfs:Class ist Instanz von sich selber.

Rdfs:Literal - Die Klasse aller Literale.

Rdfs:Property - Die Klasse aller Properties (=Prädikate).

Rdfs:subClassOf – Definiert, dass eine Klasse eine Kindklasse einer anderen Klasse

ist.

Rdfs:subPropertyOf – Definiert, dass ein Prädikat Kind von einem anderen Prädikat

ist.

Zur Einschränkung von Prädikaten gibt es unter anderem folgende Konstrukte:

Rdfs:Range – Der Wertebereich eines Prädikats, d.h. die Klassen, welche Objekte

dieses Prädikats sein können.

Rdfs:Domain – Der Definitionsbereich eines Prädikats, d.h. die Klassen, welche

Subjekt dieses Prädikats sein können.

16 Für die vollständige Spezifikation siehe (http://www.w3.org/TR/rdf-schema/)

23

2.4.3 OWL

OWL (Web Ontology Language) basiert auf den zwei älteren Ontologiesprachen DAML und

OIL und ist unterteilt in drei unterschiedlich mächtige Spezifikationen, nämlich OWL Full,

OWL DL und OWL Lite. OWL Full verfügt über die volle prädikatenlogische Mächtigkeit,

ist aber nicht garantiert entscheidbar. OWL Full ist die einzige Sprachvariante, die mit RDFS

abwärtskompatibel ist, da die anderen beiden Sprachvarianten beispielsweise ausschließen,

dass eine Klasse Instanz einer anderen Klasse ist.

Einige der Ausdrücke, die OWL über RDFS hinaus bietet, sind:

Owl:EquivalentClasses, Owl:EquivalentProperties – Gleichheit zwischen Klassen

bzw. zwischen Attributen.

Owl:SameAs, Owl:DifferentFrom – Individuen sind voneinander unterschieden.

Owl:inverseOf – zwei Eigenschaften verhalten sich invers zueinander (z.B. hasChild

und hasParent).

Owl:transitiveProperty, Owl:SymmetricProperty – Transitivität bzw. Symmetrie

zwischen Prädikaten.

Owl:MinCardinality, Owl:MaxCardinality – Kardinalitätsbeschränkungen für

Attribute.

Die erwähnten Ausdrücke bietet schon OWL Lite. OWL DL und Full bieten z.B. darüber

hinaus noch Boolesche Verknüpfungen von Klassen sowie komplexe Ausdrücke (z.B.

Aufzählungen) für Klassen z.B. bei owl:SubClassOf.

24

2.5 EXKURS: FOLKSONOMIES

Während die in Punkt 2.4 genannten Techniken und Sprachen sehr formalisiert und komplex

waren, soll hier kontrastiv eine „Bottom-Up―-Methode zur Metadaten-Annotation erwähnt

werden, nämlich die vor allem bei sogenannten „Web 2.0―-Anwendungen gebräuchlichen

Folksonomies. „Folksonomy― ist ein Kunstwort aus „Folk― und „Taxonomy― und wird von

seinem Erfinder wie folgt definiert17

:

„Folksonomy is the result of personal free tagging of information and objects (anything

with a URL) for one's own retrival. The tagging is done in a social environment (usually

shared and open to others). Folksonomy is created from the act of tagging by the person

consuming the information. The value in this external tagging is derived from people using

their own vocabulary and adding explicit meaning, which may come from inferred

understanding of the information/object. People are not so much categorizing, as providing a

means to connect items (placing hooks) to provide their meaning in their own understanding.‖

[Vander Wal 2007]

Das Konzept ist allerdings leichter gezeigt als erklärt. Zahlreiche Websites wie

Beispielsweise Flickr18

, YouTube19

oder del.icio.us20

erlauben ihren Nutzen, die dort

vorhandenen Daten mit beliebigen Schlagworten zu versehen:

Abbildung 4: Tagging bei YouTube

Abbildung 5: Tagging bei del.icio.us

Folksonomies haben technisch gesehen wenig bis gar nichts mit den oben beschriebenen

Ontologien zu tun: Sie haben weder hierarchische Klassen und Instanzen – sie haben noch

17 Eine stärker formalisierte Definition findet sich in [Schmitz et al. 2006]

18 http://www.flickr.com

19 http://www.youtube.com

20 http://del.icio.us

25

nicht einmal ein kontrolliertes Vokabular, jeder kann jeden Tag verwenden, den er will. Sie

sind allerdings auch ein Verfahren, mit dem Metadaten erzeugt werden. Folksonomies sind

aus zwei Gründen interessant für Entwickler von Agentenanwendungen: Erstens werden auf

Sites wie Flickr oder YouTube in einem Ausmaß Metadaten generiert wie wahrscheinlich in

keiner anderen Anwendung. Dadurch eignen sich diese Sites als Studienobjekt für

kollaborative Praktiken der Metadatenerzeugung21

. Zweitens sind auch die Metadaten als

solche interessant, beispielsweise um sie als weitere Datenquelle bei der Ontologiezuordnung

zu verwenden (vgl. Abschnitt 4.3). Thomas Gruber deutet darüber hinaus in [Gruber 2005]

an, wie Ontologien verwendet werden könnten, um den Wert der reichhaltigen

Metadatenbestände des Web 2.0 noch zu erhöhen.

Aus den Tags in einer Folksonomy und den getaggten Ressourcen müsste sich außerdem mit

statistischen Methoden (unsichere) semantische Information extrahieren lassen, so dass sich

zwischen den Tags zumindest eine Beziehung „hat zu tun mit― ermitteln ließe.

Abbildung 6: Ein getaggter Link in del.icio.us (Detail)

Aus dem oben stehenden Link (und den anderen Links mit denselben Tags) dürfte sich

beispielsweise die Vermutung extrahieren lassen, dass Firefox und Google etwas mit

Computern und Web 2.0 zu tun haben, und dass die angelinkte Website (lifehack.org)

ihrerseits mit all diesen Themen zu tun hat.

21 Interessant in diesem Zusammenhang ist der Artikel [Reif 2006], der mehrere einfach zu

bedienende Tools zur semantischen Annotation vorstellt, die teilweise an Interfaces erinnern,

wie sie z.B. von del.icio.us bekannt sind.

26

27

3. ONTOLOGIEIMPLEMENTIERUNG IN JADE

3.1 BAUSTEINE DER ONTOLOGIEIMPLEMENTIERUNG VON JADE22

JADE bildet Ontologien in Form von Java-Klassen ab, was gegenüber anderen

Darstellungsformen (etwa einem XML-basierten Format wie OWL) den Vorteil einfacher

und unmittelbarer Manipulation der ja ebenfalls Java-basierten Plattenform hat. Der Nachteil

ist, wie weiter unten deutlich werden wird, die größere Codelänge und damit verbunden die

geringere Übersichtlichkeit.

Seit Version 2.5 stellt JADE für die Abbildung von Ontologien eine Reihe von Klassen im

Paket jade.content zur Verfügung. Im Einzelnen gibt es Klassen für Predicates23

(wahre oder

falsche Aussagen über den Zustand der Welt) und Terms (Ausdrücke, die Entitäten in der

Welt bezeichnen). Terms werden unterschieden in Concepts (komplexe Entitäten, die

Gegenstände oder als Sonderfall Agent Actions, also mögliche Aktionen von Agenten,

beschreiben), Primitives (atomische Entitäten, z.B. Strings oder Integers), Aggregates

(zusammengesetzte Entitäten, z.B. Gruppen von Personen), Identifying Referential

Expressions (IRE, logische Ausdrücke mit einer freien Variablen, z.B. alle Mitarbeiter des

WSI) und Variables. Eine spezifische Ontologie besteht dabei nur aus eigenen Predicates,

Concepts und Agent Actions, die anderen Klassen von jade.content können unverändert in

allen Domänenontologien zum Einsatz kommen.

22 Die folgenden zwei Abschnitte stützen sich im Wesentlichen auf [Caire/Cabanillas 2004]

23 Im Folgenden werden alle JADE-spezifischen Termini im Interesse der Eindeutigkeit im

englischsprachigen Original beibehalten.

28

3.2 PROGRAMMATISCHE UMSETZUNG IN JAVA

Die programmatische Umsetzung einer Ontologie läuft grob in drei Schritten ab: Erstens

werden Java-Klassen implementiert, die die Predicates, Concepts und Agent Actions

beeinhalten. Sie werden von den Klassen Predicate, AgentAction und Concept

abgeleitet. Ein Beispiel für eine solche Klasse könnte so aussehen:

public class Company implements Concept {

private String _name;

private Address _address;

public void setName(String name) {

_name=name;

}

public String getName() {

return _name;

}

public void setAddress(Address address) {

_address=address;

}

public Address getAddress() {

return _address;

}

public boolean equals(Company c){

return (_name.equalsIgnoreCase(c.getName()));

}

}

Von diesen Klassen gibt es dann zur Laufzeit so viele Instanzen wie nötig, um die Entitäten

der jeweiligen Domäne (in diesem Fall Firmen) abzubilden. Wie wir gleich sehen werden, ist

die Ontologie selber im Gegensatz dazu als Singleton-Objekt ausgeführt, da sie für alle

Agenten gleich ist.

29

Im zweiten Schritt werden die zuvor angelegten Predicates, AgentActions und

Concepts instanziiert und zu einer konkreten Ontologie zusammengefügt:

public class EmploymentOntology extends Ontology {

[…]

// Der Name der Ontologie

public static final String ONTOLOGY_NAME = "Music-shop-ontology";

// Namen der Concepts, Predicates und Agent Actions

public static final String ORGANIZATION = "ORGANIZATION";

public static final String COMPANY = "COMPANY";

public static final String WORKS_FOR = "WORKS-FOR";

public static final String PERSON = "PERSON";

public static final String ENGAGE = "ENGAGE";

// Die Ontology ist als Singleton-Objekt implementiert

private static Ontology theInstance = new EmploymentOntology();

public static Ontology getInstance() {

return theInstance;

}

private EmploymentOntology() {

[…]

Super (ONTOLOGY_NAME, BasicOntology.getInstance());

add(new ConceptSchema(ORGANIZATION), Organization.class);

add(new ConceptSchema(COMPANY), Company.class);

add(new PredicateSchema(WORKS_FOR), WorksFor.class);

add(new ConceptSchema(PERSON), Person.class);

add(new AgentActionSchema(ENGAGE), Engage.class);

[…]

}

}

30

Als letztes werden die bisher eigenschaftslosen und freischwebenden Elemente der Ontologie

mit Slots bestückt und gegebenenfalls in eine Hierarchie gebracht:

[…]

// Dem Concept Slots zuordnen; entweder Primitives oder andere Concepts

cs = (ConceptSchema)getSchema(COMPANY);

cs.add(COMPANY_NAME,(PrimitiveSchema)getSchema(BasicOntology.STRING));

cs.add(COMPANY_ADDRESS,(ConceptSchema)getSchema(ADDRESS),ObjectSchema.OPTIO

NAL);

// Gegebenenfalls das Concept als Spezialisierung eines anderen Concepts

kennzeichnen

cs.addSuperSchema((ConceptSchema) getSchema(ORGANIZATION))

[…]

Es gibt also zwei Ebenen: Erstens die Ontologie und zweitens die Implementierung der darin

verwendeten Schemata in Form von Java-Klassen. Letztere lassen sich problemlos auch in

mehreren Ontologien verwenden, so kann man z.B. eine einmal entwickelte Person-Klasse in

einer Ontologie zum Thema Beschäftigung genauso verwenden wie in einer Ontologie, die

eine Universität abbildet. In diesem Fall müsste man zusätzlich z.B. ein Predicate

istEingeschrieben entwickeln.

Axiome können nicht in einer JADE-Ontologie abgebildet werden. Um wenigstens einfache

Axiome wie Kardinalitäten abbilden zu können, stellt JADE im Paket

jade.content.schema das Interface facet zur Verfügung, das von den beiden

Klassen CardinalityFacet und TypedAggregateFacet implementiert wird.

Facets kann man den Slots eines ConceptSchemas zuordnen.

31

Zur Laufzeit des Agenten werden dann die Instanzen der domänenspezifischen Concept-

und Predicate-Kindklassen verwendet (in unserem Beispiel sind das ORGANIZATION,

COMPANY, WORKS_FOR usw.), um konkrete Gegenstände der jeweiligen Domäne

abzubilden:

[…]

// Concepts

Company theCompany = new Company();

theCompany.setName(“KrustyCorp”);

Address theAddress = new Address();

theAddress.setStreet(“123 Fake St.”);

theAddress.setCity(“Springfield”);

theCompany.setAddress(theAddress);

Person thePerson = new Person();

thePerson.setName(“Sideshow Mel”);

// Predicate

WorksFor theWorksFor = new WorksFor();

theWorksFor.setPerson(thePerson);

theWorksFor.setCompany(Company);

[…]

JADE geht dabei immer davon aus, dass zwei Agenten dieselbe Ontologie verwenden und

stellt keinerlei Mapping-Mechanismen zur Verfügung. Es gibt lediglich die Möglichkeit,

neue Ontologien auf Basis bestehender Ontologien zu erstellen, womit sich beispielsweise

eine spezifische Ontologie als Teilzweig einer weniger spezifischen Ontologie anhängen

lässt. Dazu wird im privaten Konstruktor der Java-Ontologieklasse der Konstruktor der

Elternklasse aufgerufen, mit einem Verweis auf eine als übergeordnet zu behandelnde, schon

vorhandene Ontologie. Das obige Beispiel müsste also wie folgt modifiziert werden:

import theUpperOntology.*;

private EmploymentOntology() {

[…]

Super (ONTOLOGY_NAME, theUpperOntology.getInstance());

add(new ConceptSchema(ORGANIZATION), Organization.class);

add(new ConceptSchema(COMPANY), Company.class);

add(new PredicateSchema(WORKS_FOR), WorksFor.class);

add(new ConceptSchema(PERSON), Person.class);

add(new AgentActionSchema(ENGAGE), Engage.class);

[…]

}

32

Die fett gesetzten Änderungen bewirken, dass die Ontologie EmploymentOntology nicht

mehr von der JADE-BasicOntology abgeleitet wird, sondern von einer benutzerdefinierten

Ontologie theUpperOntology. Letztere wäre dann sinnvollerweise von der

BasicOntology abgeleitet, da in dieser die Primitives und das für die

Agentenkommunikation nötige Basisvokabular definiert ist. Dieses Basisvokabular ist im

Interface SL0Vocabulary definiert und umfasst solche Konzepte wie AID (Agentenadresse),

ACLMSG (ACL-konforme Nachricht), TRUE_PROPOSITION oder DONE. Der Name

SL0Vocabulary kommt daher, dass in diesem Interface auch die Unterstützung für die FIPA

Semantic Language (SL) implementiert wird, genauer gesagt für FIPA SL Profil 0, also das

kleinste spezifizierte Subset davon (siehe auch [FIPA2002]).

33

3.3 NACHRICHTENVERSAND

Wenn die Ontologie definiert wurde, kann in Nachrichten zwischen Agenten auf Entitäten

der Ontologie Bezug genommen werden.

Eine Nachricht in FIPA-SL, die auf die vorher definierte Ontologie Bezug nimmt, könnte

beispielsweise so aussehen:

(request

:sender(agent-identifier:name agent@zeitarbeitsfirma:1099/JADE)

:receiver (agent-identifier :name hr@krustycorp.com)

:content

((action (agent-identifier :name hr@krustycorp.com)

(Engage :thePersonToEngage (Person :Name "Homer Simpson")

))

:language FIPA-SL

:ontology EmploymentOntology)

In dieser Nachricht schickt der Agent der Zeitarbeitsfirma eine Nachricht an die Firma

„KrustyCorp― mit dem Request, die Person „Homer Simpson― einzustellen. Dabei wurden

die Entitäten Engage und Person in der Ontologie definiert, jeweils mit den passenden Slots

(in diesem Fall thePersonToEngage und Name). Engage ist eine Agent Action, Person

ist ein Concept.

3.3.1 ANDERE KOMMUNIKATIONSSPRACHEN

Nachrichten zwischen Agenten werden entweder in der textbasierten FIPA SL- (Semantic

Language, spezifiziert in [FIPA2002]) oder in der binären JADE-spezifischen LEAP-Sprache

ausgedrückt. Die dafür nötigen Codecs sind im jade.content-Paket enthalten. Der

Programmierer kann auch eigene Codecs erstellen, beispielsweise um andere Sprachen wie

KIF oder OWL-DL zu unterstützen. Dafür muss er das Interface jade.content.lang.Codec

implementieren.Tatsächlich gibt es zumindest eine Implementierung von OWL als Content

Language für JADE24

namens AgentOWL25

.

24 http://agentowl.sourceforge.net/

25 Für einen Vergleich zwischen FIPA SL und OWL siehe [Khalique et al. 2005]. In

[Kalyanpur et al. 2004] wird ein automatisiertes Mapping von OWL auf JADE-Klassen

beschrieben.

34

3.4 WERKZEUGUNTERSTÜTZTE ONTOLOGIEIMPLEMENTIERUNG IN JADE

In der Praxis dürfte die manuelle Entwicklung von Ontologien in Form von Java-Code

deutlich zu aufwendig und fehlerträchtig sein, so dass sich hier der Einsatz von

Codegeneratoren aufdrängt. Für den recht stabil und ausgereift wirkenden Ontologieeditor

Protégé26

kann man hierzu das Beangenerator-Plugin27

verwenden, das allerdings leider nicht

mehr weiterentwickelt wird. Das Plugin erlaubt direkten Export von JADE-Ontology-Klassen

aus Protégé heraus.

Abbildung 7: Das UI des Beangenerator-Plugins

26 http://protege.stanford.edu/

27 http://protege.cim3.net/cgi-bin/wiki.pl?OntologyBeanGenerator

35

4. ONTOLOGIEZUORDNUNG (ONTOLOGY MAPPING)

4.1 BEGRIFFS- und PROBLEMABGRENZUNG

Im Forschungsfeld der semantischen Integration (zu dem sich Ontology Mapping rechnen

lässt) lassen sich verschiedene Teilprobleme unterscheiden, die von verschiedenen Autoren

terminologisch unterschiedlich gefasst werden. An dieser Stelle soll die zumindest für den

europäischen Raum einflussreiche Einteilung des von der EU geförderten KnowledgeWeb-

Projekts dargestellt werden [Bouquet 2005]. Hierbei wird unter einem Mapping eine

semantische Relation zwischen zwei Entitäten aus zwei verschiedenen Ontologien

verstanden. Das in anderen Artikeln bisweilen synonym verwendete Wort Ontology

Alignment wird hier verstanden als eine Menge an Mappings. Als Ontology Translation wird

dann eine Ontology Transformation (also eine Funktion) bezeichnet, die eine Ontology O in

eine Ontology O' überführt (t: O->O'). Als Überbegriff für alle Verfahren, bei denen

Ontologien in Beziehung gebracht werden, wird Ontology Coordination vorgeschlagen. Im

Rahmen der vorliegenden Arbeit wird der Begriff Mapping auch noch für den Prozess der

Herstellung von Mappings verwendet. Welche von beiden Bedeutungen gemeint ist, lässt

sich in der Regel eindeutig aus dem Kontext erschließen.

Innerhalb des Problems des Ontologiemappings lässt sich dann die Problemstellung weiter

aufteilen, und zwar nach der Art der Verschiedenheit der beiden beteiligten Ontologien.

Hierbei unterscheidet Bouquet in einem Modell aus lose aufeinander aufbauenden Schichten

nach syntaktischer, terminologischer, konzeptueller und semiotisch-pragmatischer Ebene.

Die syntaktische Ebene dürfte die noch am wenigsten komplexen Probleme beinhalten. Auf

dieser Ebene geht es um die Unterschiede in der Darstellungsform (im Gegensatz zu den

Inhalten oder Strukturen) von Ontologien oder Knowledge Bases. Dabei kann es sich

zunächst einmal um Syntaxunterschiede zwischen Sprachen handeln, die relativ einfach, im

Fall von reinen XML-Formaten sogar mit gut eingeführten Transformationstechniken wie

XSLT, ineinander überführbar sind. Allerdings wird das Problem komplizierter, wenn wie bei

der Transformation von KIF in OWL Lite (oder auch von OWL Lite in die JADE-eigene

Ontologierepräsentation) die Wissensrepräsentationssprachen unterschiedlich mächtig sind.

Hier muss der Anwender gegebenenfalls mit partiellen oder ungefähren Mappings leben. Ein

Beispiel für ein Mapping auf der syntaktischen Ebene ist das Tool WS2JADE, das im

Rahmen seiner Aufgabe – der Bereitstellung von Web Services für JADE-Agenten – die

36

ontologiebezogenen Informationen aus einer Web Services Description Language (WSDL)-

Datei in eine JADE-Ontologie überführt.

Mappingprobleme auf terminologischer Ebene stellen sich dort ein, wo – mit Wittgenstein

gesprochen – Worte die Gedanken verkleiden, d.h. wo für dieselbe Klasse von Gegenständen

unterschiedliche Begriffe verwendet werden. Ein terminologischer Versatz kann sich z.B.

einstellen, wenn in O1 eine Entität „Car― vorkommt, und O2 eine Entität „Auto―. Beide

Entitäten haben dieselbe Extension (d.h. die Menge der darunter subsumierten Gegenstände

ist identisch), aber ihre Bezeichnung ist unterschiedlich. Dieses Problem tritt nicht nur

zwischen verschiedenen, sondern auch innerhalb ein und derselben natürlichen Sprache auf,

z.B. wenn zwei extensional gleichwertige Entitäten in einer Ontologie z.B. „Auto― und

„Autos― heißen. Komplizierter wird es auch innerhalb derselben Sprache, wenn Polyseme

(paradigmatisches Beispiel: Bank als Kreditinstitut und Bank als Sitzmöbel) oder Synonyme

(Bank und Kreditinstitut) vorkommen. Für Mappingprobleme auf terminologischer Ebene

dürfte der Werkzeugkasten der Computerlinguistik recht gut einsetzbar sein.

Schwieriger ist es, Unterschiede auf konzeptueller Ebene zu behandeln. Hierbei differenziert

Bouquet nach metaphysischen und epistemischen Unterschieden. Erstere betreffen die in

einer Ontologie kodifizierten grundsätzlichen konzeptuellen Festlegungen über die Welt

(bzw. meist über die spezielle Domäne), beispielsweise die Frage, ob Autos eine Blatt-Klasse

in der Ontologiehierarchie sind oder ob es noch fünf Ebenen an Differenzierungen gibt

(PKW/LKW, Kombi/Coupé/Van etc.). Epistemische Unterschiede beziehen sich hingegen

auf die Zuschreibungen, die äquivalenten Entitäten angeheftet werden. Dieses Problem lässt

sich noch relativ einfach lösen, wenn sich die epistemische Differenz darin äußert, dass zwei

Klassen in zwei Ontologien verschiedene Slots haben; In diesem Fall könnte man einfach die

Vereinigungsmenge der Slots beider Klassen bilden. Was aber, wenn sich die Ausstattung der

Klassen logisch widerspricht, wenn sich z.B. Kardinalitäten widersprechen, wenn also

beispielsweise die Klasse „Auto― aus O1 beliebig viele Farben für die Karosserie vorsieht und

die Klasse „Auto― aus O2 nur eine?

In Anlehnung an Forschungsergebnisse aus der KI-Forschung differenziert Bouquet weiter,

indem er terminologische Ungleichheiten in drei Typen aufteilt: Abdeckungsgrad,

Granularität und Perspektive. Unterschiede im Abdeckungsgrad ergeben sich, wenn eine

Ontologie umfangreicher ist als die andere, ihnen also eine geringfügig unterschiedliche

37

Definition ihrer Domäne zugrunde liegt. Die Granularität bezieht sich auf Unterschiede der

Feinkörnigkeit der Weltrepräsenation, wie weiter oben auch schon als Beispiel angeführt: in

der einen Ontologie gibt es nur einen allgemeinen Begriff von Autos, in der anderen ist die

Klasse noch feinkörnig unterteilt. Unterschiede in der Perspektive stellen sich z.B. ein, wenn

Ontologieautoren aus verschiedenen Kulturen eine vermeintlich identische Domäne abbilden.

So dürfte ein japanischer Einwanderer in New York die Domäne „Essen und Ausgehen―

anders konzeptualisieren als ein Einheimischer.28

Zu guter letzt lässt sich noch die semiotisch/pragmatische Ebene betrachten. Hier ist die

intendierte Anwendung der Ontologie zu betrachten. Dieser Aspekt des ontology mappings

dürfte auch am schwersten zu formalisieren sein. Als Beispiel für ein Problem auf dieser

Ebene nennt Bouquet zwei Ontologien, von denen eine die politische Geografie der Erde

abbildet (Kontinente, Länder, etc.) und die andere als Domäne eine Multimedia-Datenbank

hat, in der die Klasse Images/B&W/Europe nicht für das selbe Europa steht wie jenes aus

der Geografie-Ontologie, und zwar nicht wegen terminologischer oder konzeptueller, sondern

wegen pragmatischer Unterschiede: es geht in beiden Fällen um Europa, in einem Fall aber

um den Kontinent oder das Staatengebilde und im anderen Fall um Europa als Label für

Fotos, die in Europa aufgenommen wurden. Auf dieser Ebene scheint für die Zukunft auch

noch eine weitere Begriffsunterscheidung fruchtbar.

28 Ein Beispiel, das diesen Punkt illustriert, findet sich in [Akahani et al. 2002].

38

4.2 BASISONTOLOGIEN

Nachdem es im vorherigen Absatz um die grundsätzlichen Probleme der Ontologiezuordnung

ging, sollen im Folgenden auf der Grundlage eines Surveys von Natalya Noy [Noy 2004]

einige Projekte aus der Forschung erwähnt werden. 29

Forschungen zum Thema Mapping Discovery gibt es sowohl aus der Datenbankforschung

(wo es darum geht, Datenbank- oder XML-Schemata interoperabel zu machen) als auch aus

der Computerlinguistik-/KI-Forschung. Generell sind zwei verschiedene Ansätze zu

unterscheiden: Ansätze mit gemeinsamer Basisontologie und Ansätze ohne gemeinsame

Basisontologie. Unter einer Basisontologie („shared upper ontology―) versteht man eine

Ontologie, die nicht oder nur bedingt domänenspezifisch ist, bzw. die versucht, metaphysisch

möglichst unstrittige Aussagen zu vereinen. Eine Basisontologie könnten beispielsweise

Begriffe wie „Ding―, „Person―, „Tatsache― oder „Beweglicher Gegenstand― enthalten.

Beispiele für existierende Upper Ontologies sind SUMO (Suggested Upper Merged

Ontology)30

und DOLCE31

. Erwähnenswert ist in diesem Zusammenhang auch noch das

WordNet-Projekt32

, das einem Wörterbuch der englischen Sprache semantische

Informationen hinzufügt und somit auch eine Art semistrukturierte Ontologie-Datenbasis

darstellt33

sowie der UNSPSC (United Nations Standard Products and Services Code)34

, eine

Art Taxonomie für eine Vielzahl von Produkten und Dienstleistungen.

29 Eine sehr ausführliche Übersicht über weitere Forschungsprojekte in diesem Feld bieten

[Kalfoglou/Schorlemmer 2005] und [Noy/Stuckenschmidt 2005] sowie [Choi et al. 2006].

30 http://www.ontologyportal.org/

31 http://www.loa-cnr.it/DOLCE.html

32 http://wordnet.princeton.edu/

33 Möglicherweise lassen sich die in 2.5 beschriebenen Folksonomies auf ähnliche Weise

nutzbar machen – als semistrukturierte Datenbasis, die zur Unterstützung bei der

Ontologiezuordnung herangezogen wird.

34 http://www.unspsc.org

39

Abbildung 8: Ein kleiner Ausschnitt der UNSPSC-Taxonomie für Produkte und Dienstleistungen

Das Vorhandensein einer Basisontologie erleichtert das Ontology Mapping wesentlich.

Andererseits setzt es voraus, dass sich möglichst viele, am besten alle

Kommunikationsteilnehmer auf eine Ontologie einigen. Dies ist sicher nicht in allen

Anwendungsszenarien möglich. Insbesondere nicht bei Semantic Web-Anwendungen, wo es

in der Praxis schon schwer genug ist, technische Standards zu etablieren, wie ja die langsame

Annahme von RDF und OWL und die Attraktivität der konzeptionell sehr viel weniger

anspruchsvollen, dabei aber auch weit weniger mächtigen Microformats zeigt35

. Wenn die

Geschichte der Technologien des WWW etwas zeigt, dann, wie schwierig es ist, Standards

durchzusetzen, die „designed by committee― sind – eine Lehre, die vielleicht auch Forscher

und vor allem Entwickler im Agentenumfeld ernst nehmen sollten.

Abbildung 9: Ausschnitt aus der Suggested Upper Merged Ontology (SUMO) in HTML-Darstellung

35 Siehe hierzu beispielsweise [Braun 2007]

40

Ein Ansatz, der nicht auf eine Basisontologie zurückgreifen kann, muss sich unter

Verwendung verschiedener mehr oder weniger raffinierter Heuristiken seine Vermutungen

und sein Wissen über die Zuordnungen zusammenklauben. Die Formulierung deutet schon

an, dass dieser Prozess das ist, was man im Amerikanischen so trefflich als „messy―

beschreiben kann. Im Wesentlichen nutzen die verwendeten Heuristiken lexikalische und

strukturelle Eigenschaften der einzelnen Entitäten sowie der strukturellen Beziehungen

dazwischen (z.B. Vererbung) aus. In Abschnitt 4.3 werden die am häufigsten eingesetzten

Heuristiken beschrieben. Häufig zitierte Projekte, die keine Basisontologie voraussetzen, sind

PROMPT, GLUE, Chimeara und IF-Map.

Als dritter Ansatz ließe sich vielleicht – über den Artikel von Noy hinausgehend – noch die

statische Übersetzung auf Basis einer semiautomatisch oder manuell erstellten

Übersetzungstabelle hinzufügen. Eine solche manuelle Übersetzungstabelle ließe sich auch

mit den ersten beiden beschriebenen Verfahren kombinieren mit dem Ziel, einer auf machine

learning basierenden Mapping-Lösung einen Grundstock an Wissen mitzugeben.

Weitere Forschungsgebiete, die Noy in ihrem Artikel erwähnt und die ob ihrer fundamentalen

Bedeutung auch hier nicht ganz unter den Tisch fallen sollen, sind die Repräsentation von

und das Schlussfolgern mit Mappings. Für die Repräsentation von Mappings nennt Noy

mehrere Verfahren, unter anderem die Speicherung der Übersetzungsregeln selber wiederum

als Instanzen ontologisch strukturierter Klassen. In der Tat gibt es Forschungsprojekte in

dieser Richtung. Für die letztendliche Anwendung der Mappings auf konkrete Ontologien

beispielsweise zur Übersetzung von Anfragen oder zur Ontologiezusammenführung (Merge)

hat das den Vorteil, Quellontologien zusammen mit semantisch repräsentierten Mappings und

Transformationsregeln in einem System zum regelbasierten Schließen wie etwa dem

kommerziellen RACER36

und JESS37

oder dem frei verfügbare Jena Semantic Web

Framework38

verarbeiten zu können.

36 http://www.racer-systems.com

37 http://herzberg.ca.sandia.gov/jess/

38 http://jena.sourceforge.net/

41

4.3 METHODEN DER ONTOLOGIEZUORDNUNG

Ein beträchtlicher Teil der Forschung im Bereich der Ontologiezuordnung konzentriert sich

auf Probleme der terminologischen und konzeptuellen Ebene. Wie oben angekündigt, wird in

diesem Abschnitt ein recht vollständiger Überblick gegeben über die praktischen Ansätze des

tatsächlichen Mappings auf diesen Ebenen, also der Ermittlung von korrekten Zuordnung

zwischen Ontologieteilen oder gesamten Ontologien. Basis dafür sind zwei Surveys: [Abels

et al. 2005] und [Shvaiko 2004].

Zunächst soll aber ein kanonischer Ablauf eines Ontologiemappings vorgestellt werden. Die

folgende Darstellung ist einem Artikel [Ehrig/Staab 2004] entnommen, für den die Autoren

alle ihnen bekannten Mappingverfahren untersucht haben.

1. Normalisierung der Ontologiedarstellungen („Feature engineering―): Die beteiligten

Ontologien werden gegebenenfalls in eine für das Mapping geeignete Darstellung

umgewandelt.

2. Ein Subset der möglichen Entitätenpaare wird ausgewählt.

3. Die Ähnlichkeit der beiden Entitäten wird bewertet. Das Ergebnis ist eine Zahl, die

den Grad der Ähnlichkeit ausdrückt.

4. Gegebenenfalls werden mehrere Ähnlichkeitswerte gewichtet, die durch verschiedene

Ähnlichkeitsermittlungsverfahren zustande gekommen sind.

5. Interpretation: Die Ähnlichkeitswerte werden genutzt, um aus mehreren möglichen

Kandidatenpaaren das beste auszuwählen. Hierbei können auch strukturelle

Eigenschaften der Ontologien einbezogen werden.

6. Einige oder alle der vorangegangenen Schritte werden wiederholt, um ein immer

akkurateres Mapping zu erzielen.

42

Vor allem für die in Schritt 3. und 5. durchzuführenden Berechnungen zählen [Abels et al.

2005] neun verschiedene Klassen von Verfahren auf, ungefähr angeordnet nach steigendem

Implementierungsaufwand und nennen auch für jedes Verfahren Beispielimplementierungen.

Am einfachsten lassen sich Textähnlichkeiten feststellen, z.B. zwischen „Auto― in O1

und „Autos― in O2).

Aus eventuell vorhandenen Beschreibungsfeldern der in der Ontologie enthaltenen

Entitäten lassen sich mit statistischen oder sprachanalytischen Verfahren

Schlüsselwortähnlichkeiten ermitteln.

Mithilfe sprachbasierter Methoden lassen sich Wörter auf gemeinsame Lexeme

zurückführen (z.B. „Haus― und „Häuser― werden bei auf „Haus― zurückgeführt).

Mithilfe einer Datenbank wie dem weiter oben schon genannten WordNet oder

anderen Thesauri lassen sich Synonyme oder im günstigsten Fall auch reichhaltigere

Beziehungen identifizieren.

Eine Vererbungsanalyse sucht z.B. nach gemeinsamen Vorfahren in der

Ontologiehierarchie. So ließe sich beispielsweise das „Auto―-„Autos―-Paar auch

wegen eines in beiden Hierarchien vorhandenen Vorfahren „Fahrzeug― einander

zuordnen.

Bei der Strukturanalyse werden noch weitere strukturelle Merkmale einbezogen, z.B.

Geschwisterklassen oder Attribute der Konzepte.

Falls man nicht nur Ontologien, sondern auch Instanzen zur Verfügung hat, lassen

sich auch diese zur Analyse nutzen; Wenn Beispielsweise alle Instanzen in einem

bestimmten Slot den Wert „EUR― enthalten, lässt sich eventuell ein Bezug zu einer

Klasse „Währung― herstellen (wenn z.B. diese Klasse auch Kindklassen „Euro―,

„Dollar― etc. hat)

Zu guter letzt gibt es auch noch komplexere Verfahren der Graphenanalyse, bei der

auf Basis von Pfaden und Distanzen Ähnlichkeiten kalkuliert werden. Ein solches

Verfahren dürfte besonders im Falle einer gemeinsamen Basisontologie nützlich sein,

weil dann z.B. die Entfernung eines Konzepts von dem spezifischsten

43

Basisontologiekonzept, das beide Ontologien noch anerkennen, herangezogen werden

kann.

Shvaiko verwendet eine andere Einteilung [Shvaiko 2004], die auf oberster Ebene zwischen

Heuristiken und formalen Techniken unterscheidet, wobei erstere „best guesses― und letztere

genaue und begründete Ergebnisse auf Basis formaler Semantiken bieten. Auf der nächsten

Ebene unterscheidet er zwischen Verfahren, die sich mit einzelnen Entitäten der Ontologie

beschäftigen von solchen, die strukturelle Merkmale der Ontologie nutzen. Weiterhin

unterscheidet er zwischen impliziten und expliziten Verfahren, wobei erstere syntaktische

und letztere semantische Informationen zur Ähnlichkeitsermittlung nutzen.

Abbildung 10: Taxonomie verschiedener Ontologiezuordnungsverfahren [Shvaiko 2004]

44

45

5. ONTOLOGIEZUORDNUNG IN JADE

Nachdem im vorherigen Abschnitt ein Einblick in die grundsätzlichen Fragestellungen im

Umfeld der Ontologiezuordnung gegeben wurde, soll es im Folgenden um die konkrete

Umsetzung mit JADE gehen. Dabei sollen weniger die verwendeten Algorithmen als

vielmehr die Software-/Agentenarchitektur in den Blick genommen werden. Dafür wird die

FIPA-Referenzarchitektur sowie ein Entwurf von Li und Kollegen als Beispiel angeführt ([Li

et al. 2006]).

5.1. FIPA-OA

Wie bereits erwähnt, bietet JADE von sich aus keinerlei Mechanismen für die

Ontologiezuordnung. Es gibt aber ein Dokument, das eine Ontologieinfrastruktur für FIPA-

Agenten-Plattformen vorschlägt [FIPA 2001]. Es wurde nicht zum Standard erhoben und

befindet sich somit seit mehr als fünf Jahren unverändert im experimentellen Status.

5.1.1 Anforderungen an den Ontology Agent

Das Dokument spezifiziert die Anforderungen an einen Ontology Agent (OA), der einen oder

mehrere der folgenden Dienste anbieten muss:

Die Auffindbarmachung öffentlich zugänglicher Ontologien in Zusammenarbeit mit

dem Directory Facilitator

Die Wartung und Zugänglichmachung öffentlicher Ontologien (was auch CRUD-

Operationen einschließt)

Ontologiemapping auf allen Ebenen (einschließlich der syntaktischen Ebene)

Auskunft über das semantische Verhältnis zweier Ausdrücke

Die Bestimmung einer gemeinsamen Ontologie für die Kommunikation zwischen

zwei Agenten

46

5.1.2 Die FIPA-Meta-Ontology

Der Standard trifft dabei keine Festlegungen über das verwendete Verfahren zur

Ontologiespeicherung. Für die Kommunikation zwischen Agenten über den

Gegenstandsbereich Ontologien wird aber eine Ontologie namens FIPA-Meta-Ontology

definiert, die auf dem Wissensmodell von OKBC basiert39

. Das OKBC-Wissensmodell wurde

entworfen als gemeinsamer Nenner zwischen verschiedenen KR-Systemen und ist deshalb

ein nahe liegender Kandidat für eine FIPA-OA-Metaontologie.

Im Einzelnen definiert die FIPA-Meta-Ontology Entitäten der folgenden Art:

Classes entsprichen dem, was in Kapitel 3 als concept eingeführt wurde und in etwa

auch dem, was Klassen in der objektorientierten Programmierung sind. Im Gegensatz

dazu stehen Instances; Der Überbegriff für Classes und Instances ist Frames. Die

Classes der FIPA-Meta-Ontology sind : :THING, :CLASS, :INDIVIDUAL,

:NUMBER, :INTEGER, :STRING, :SYMBOL, :LIST

Predicates sind Aussagen über Frames. Einige Beispiele für Prädikate in der FIPA-

Meta-Ontology sind

o (CLASS ?X) – Ist X eine Klasse?

o (INSTANCE-OF ?I ?C) – Ist I eine Instanz von C?

o (<slotname> ?class ?value) – hat der Slot slotname in der Klasse class den

Wert value?

Slots sind in etwa das, was in der OOP Attributen entspricht. Präziser gesagt sind

Slots als Relation über ein Frame und einen Value definiert: (F S V). Der einzige Slot,

den die FIPA-Meta-Ontology definiert, ist ein Kommentarfeld namens

:DOCUMENTATION.

Facets haben in etwa die Funktion von Constraints in relationalen Datenbanken.

Formal sind sie als Relation über Slots definiert; Ein Wert einer Facet sagt aus, dass

ein bestimmter Slots eines bestimmten Frames eine bestimmte Eigenschaft aufweist.

So können z.B. Kardinalitätsbedingungen definiert werden oder, dass im Slot

39 OKBC ist ein API für den Zugriff auf Knowledge Bases. Die Spezifikation findet sich

unter http://www-ksl-svc.stanford.edu:5915/doc/release/okbc/okbc-spec/index.html.

47

Favorite-Food des Frames Fred nur Namen von Frames stehen dürfen, die das

Predicate isEdible erfüllen. Facets in der FIPA-Meta-Ontology sind zum Beispiel

o :VALUE-TYPE (Typeneinschränkung, z.B. nur essbares darf Lieblingsessen

von Fred sein)

o :INVERSE (Inversionsbeziehungen wie „A ist Elternteil von B impliziert, dass

B ist Kind von A―)

o :CARDINALITY (Kardinalitätsbeschränkung, z.B. Slot „Alter― muss genau

einen Eintrag haben)

Slots on Slot Frames lassen sich als Meta-Slots beschreiben, dahingehend, dass sie die

Slots von Frames sind, die Slots beschreiben. Beispiele sind hier:

o :DOMAIN (definiert für einen Slot S, welchen Klassen er zugeordnet sein

kann, z.B. nur die Klasse Fahrzeug und deren Kindklassen können einen Slot

AnzahlDerRäder haben)

o :SLOT-SAME-VALUES (definiert, dass zwei Slots immer den gleichen Wert

haben müssen)

48

5.1.3 Die vorgeschlagene Architektur

Die Autoren des Standards gehen davon aus, dass es von Vorteil ist, das

Ontologiemanagement in einen separaten Agenten auszulagern, weil das leichtgewichtige

Agenten ermöglicht, die sich jeweils auf ihre Spezialaufgabe konzentrieren können.

Auch der OA selber ist relativ leichtgewichtig gehalten, da er die Ontologiespeicherung

speziellen Ontologieservern wie Ontolingua überlässt. Er abstrahiert also auch über

verschiedene Ontologierepräsentationen wie z.B. KIF oder OWL:

Abbildung 11: Das Ontology Service Reference Model aus dem FIPA-Standard XC00086

Neben einem Vorschlag für die Architektur des Ontologiemanagements enthält der Standard

auch Festlegungen über die Umsetzung von ontologiebezogenen Sprechakten in FIPA-SL. Im

Einzelnen wird gefordert, dass der OA die Agent Actions bzw. Sprechakte ASSERT (Einer

Ontologie Predicates hinzufügen), RETRACT (aus einer Ontologie Predicates entfernen),

query-if/query-ref (Informationen über die Ontologie beantworten) und TRANSLATE

(Concept aus einer Ontologie in das entsprechende Concept aus einer anderen Ontologie

übersetzen, soweit möglich) unterstützt. Ein Beispiel für eine Implementierung eines FIPA-

OA (allerdings auf Basis einer etwas älteren Version des Standards) findet sich in [Suguri et

al. 2001].

49

5.2 DIE ONTOLOGY MAPPING PLATFORM VON LI/YANG/WU

Eine elaboriertere Architektur als im Standard vorgeschlagen implementieren [Li et al. 2006].

Ihr Ansatz ist deutlich stärker als der FIPA-OA-Standard auf massiv verteilte Agenten

ausgerichtet, vor allem im Internet und in großen Intranets. Sie charakterisieren

Ontologiebasierte Anwendungen im Web-Umfeld wie folgt:

„[D]istributed (namely ontologies scattered in different places), non-deterministric (in

practice, almost all realistic environments must be regarded as non-deterministic),

heterogeneous (ontologies may have various modelling methods and different

representations), and highly dynamic (the number of organisations/ontologies keeps changing,

the ontology is evolving over time, with many processes concurrently to modify the

environment in ways that an organisation has no control over, heterogeneous systems need to

interact by spanning organisational boundaries and operation effectively within changing

environment).‖

Die vorgeschlagene Architektur bezieht sich nicht auf den FIPA-OA-Standard und

unterscheidet sich auch in einigen Punkten davon deutlich. Die Gemeinsamkeiten sind im

Wesentlichen, dass ähnlich wie der FIPA-OA-Standard auch die hier skizzierte

Agentenplattform unabhängig vom Format der Ontologiespeicherung ist, da von dieser durch

die Wrapper-Komponenten (unten im Diagramm) abstrahiert wird. Außerdem ist die

Funktion des Ontology Agents aus dem FIPA-Standard aufgeteilt auf mehrere Agenten,

nämlich die Functionary Agents und die Ontology Agents. Ein wesentlicher Unterschied ist,

dass die Ontology Mapping Platform ein User Interface vorsieht.

Abbildung 12: Die Architektur der Ontology Mapping Platform von [Li et al. 2006]

50

Im Einzelnen haben die Agenten in dieser Architektur folgende Funktionen:

Der User Agent implementiert das GUI, ist also die einzige Schnittstelle zum

Benutzer.

Der Interface Agent übernimmt die Koordination zwischen den Functionary Agents

und dem User Agent. Wenn also beispielsweise ein Mapping Agent dem Benutzer ein

Mapping vorschlagen möchte, muss er sich dafür an den Interface Agent wenden.

Der Ontology Agent bildet jeweils eine konkrete Ontologie ab. Er stellt primitive

Operationen für die Bearbeitung von Ontologien zur Verfügung (Insert, Traverse)

sowie für die Bearbeitung von gespeicherten Mappings (Append, Search). Der

Ontology Agent speichert außerdem einmal gefundene Mappings (hier in Form einer

Textdatei).

Ontology Agents sind in etwa das, was JDBC-Treiber in der Datenbankwelt sind: Sie

erlauben es, die primitiven Operationen von den komplexeren zu isolieren, wobei

letzte dann in den entsprechenden Bibliotheken (z.B. JDBC, OLEDB, ODBC)

untergebracht sind.

Die Functionary Agents enthalten die eigentlichen Funktionen zur semantischen

Integration:

o Der Thesaurus Agent verwaltet eine List von Synonymen.

o Die Hauptaufgabe des Mapping Agents ist die Entscheidung darüber, ob zwei

Konzepte aus verschiedenen Ontologien dieselbe Bedeutung haben. Dazu

arbeitet er mit dem Thesaurus Agent zusammen. Der Mapping Agent

behandelt also Mappingprobleme auf konzeptueller Ebene.

o Der Integration Agent ermöglicht die Integration zweier Ontologien zu einer

neuen. Hierbei werden auch einfache Unterschiede zwischen den Ontologien

auf konzeptueller Ebene berücksichtigt, indem zwischen Äquivalenz,

Inklusion und Disjunktheit zweier Konzepte unterschieden wird.

Beispielsweise ist „beer― äquivalent zu „suds―, beeinhaltet „stout― und ist

51

disjunkt zu „car―. Für die erzeugte Ontologie wird sofort ein neuer Ontology

Agent aufgesetzt.

o Der Consistency Checking Agent stellt vor allem sicher, dass ein Konzept

nicht zwei disjunkte Elternkonzepte hat. Gegebenenfalls warnt er den User

über solche Inkonsistenzen.

o Der Query Agent bekommt vom Interface Agent eine Suchanfrage und

übernimmt dann die Suche, kommuniziert also mit den Ontology Agents.

Der Ablauf des Programms ist wie folgt:

1. Existierende Ontologien werden importiert (die Ontologien können z.B. in RDF

vorliegen).

2. Für jede Ontologie wird ein Ontology Agent aufgesetzt.

3. Der Benutzer startet den Mapping-Vorgang.

4. Der Benutzer startet den Integrationsvorgang. Dabei wird auf die Ergebnisse aus dem

vorherigen Schritt zurückgegriffen.

5. Das Ergebnis von Schritt 4. wird dem User dargestellt (siehe Abbildung 8.)

Abbildung 13: Die Benutzeroberfläche der Ontology Mapping Platform nach Schritt 5 [Li et al. 2006]

52

Zur Umsetzung in JADE lässt sich noch sagen, dass für die interne Speicherung der

Ontologiedaten auf Java-Ebene die Ontology Mapping Platform nicht die bei JADE

enthaltenen Klassen verwendet, wie sie in Abschnitt 3. dieser Arbeit beschrieben wurden, da

diese keine Änderung zur Laufzeit zulassen: Ontologien werden zur Programmierzeit

entwickelt, zur Laufzeit können nur Änderungen auf Instanzebene gemacht werden. Deshalb

haben Li und Kollegen eigene Klassen zur Repräsentation ontologiebezogener Konzepte

implementiert, und zwar auf Basis der Java-Framework-Klasse JTree.

Außerdem haben sie aus nicht näher genannten Gründen eine eigene, etwas einfache Meta-

Ontologie entwickelt, anstatt die aus dem FIPA-OA-Standard zu verwenden.

53

5.4 DESIGNÜBERLEGUNGEN ZU ONTOLOGIEZUORDNUNGSPLATTFORMEN

Im Folgenden sollen ohne Anspruch auf Vollständigkeit einige Designentscheidungen

angedeutet werden, die beim Entwurf einer Ontologieplattform zu treffen sind. Dabei wird

von einer weltweit skalierbaren Plattform ausgegangen, wie sie für den Einsatz im Internet

erforderlich wäre.

Zu klären ist zunächst, welche Ontology Services die Plattform überhaupt anbieten soll? Hier

sind zumindest Speicherung, Discovery, Mapping und Versionierung zu betrachten. Dann

stellt sich die Frage nach der Aufteilung der Services. Hier gibt es mindestens drei Varianten:

Ein oder mehrere Agents bieten die Dienste an, die Plattform bietet die Dienste an oder jeder

Agent erhält selber (womöglich dynamisch zur Laufzeit) Ontologieverwaltungsfähigkeiten

(Universalagent). Natürlich sind auch Mischungen möglich, so dass zum Beispiel die

Plattform sich um die Ontologiespeicherung kümmert, das Mapping aber von Agenten

übernommen wird.

Hier schließt sich dann die Frage an, ob ein OA nur Gateway zu anderen Ontologydiensten

sein soll oder ob er sie selber anbieten soll, d.h. wie leicht- oder schwergewichtig ein

Ontology Agent sein soll. Insbesondere für Implementierungen in der nahen Zukunft ist es

vielleicht realistisch, zunächst vorhandene Ontologietools wie GLUE oder Chimeara

anzubinden, statt neue Software zu entwickeln.

Außerdem muss entschieden werden, wo und wie Ontologien gespeichert werden und wie

und in welchem Umfang sie übertragen werden sollen. Textbasiert oder in Binärformaten? In

Dateien oder in womöglich speziell auf Ontologieanwendungen zugeschnittenen

Datenbanken? Braucht es eventuell andere Sprachen für die Kommunikation zwischen

Ontologiediensten als für die Kommunikation zum aufrufenden Agenten? Im Zusammenhang

mit Kommunikation und Präsentation stellt sich auch die Frage nach der

Benutzerschnittstelle. Wie viel Einfluss- und Kontrollmöglichkeiten soll der Benutzer haben?

Dies ist vor allem wichtig, da die Erfahrung zeigt, dass Kommunikationskanäle schnell für

Werbung oder gar für kriminelle Zwecke missbraucht werden. Beispielsweise muss in einem

E-Commerce-Szenario verhindert werden, dass ein „Spam-OA― sich für alle Anfragen

zuständig erklärt und auf jede Anfrage nur Werbung zurückliefert.

54

55

6. ZUSAMMENFASSUNG UND AUSBLICK

Diese Studienarbeit hat versucht, einen Überblick zu geben über das Thema

Ontologiezuordnung im Allgemeinen sowie speziell im Zusammenhang mit JADE. Der

bisherige Forschungsstand lässt sich so charakterisieren: Es gibt en gros und en detail noch

viel zu tun, in manchen Bereichen auch in Theorie und Grundlagenforschung, generell in den

Standards und vor allem den Anwendungen.

Der von Tim Berners-Lee in dem Eingangs erwähnten Artikel ausgemalte Use Case scheint

jedenfalls aus heutiger Sicht schon alleine aus technischen Gründen noch ein gutes Stück von

der Realisierung entfernt – ganz zu schweigen von der betriebswirtschaftlichen und

juristischen Seite und dem Fehlen einer weltweit skalierbareren Agenteninfrastruktur.

Diese Studienarbeit hat das Thema Benutzerinteraktion fast komplett ausgespart, was

allerdings nur der notwendigen Begrenzung angesichts des zeitlich beschränkten Rahmens

geschuldet ist. Tatsächlich scheint mir dieses Thema aber von zentraler Bedeutung zu sein.

Gerade aus dem Umfeld der in Kapitel 2 vorgestellten Folksonomies wird klar, dass

zugunsten der Benutzerfreundlichkeit vielleicht Pragmatismus mitunter vorgehen muss vor

der Eleganz des Konzepts. Das Konzept Folksonomy ist sicher alles andere als perfekt,

sondern eher das, was Programmierer als quick and dirty bezeichnen. Ähnliches lässt sich

über HTML auch sagen, aber es hat zweifellos eine enorme Popularisierung des Konzepts

Hypertext mit sich gebracht. Eine interessante Frage (für eine andere Arbeit) wäre also,

welche Zwischenstufen es denn zwischen dem Jetzt und einer Vision von allumfassend

semantisch ausgezeichneten Inhalten mit autonomen Agenten geben könnte.

56

57

LITERATURVERZEICHNIS

[Antoniou/van Harmelen 2004] Antoniou, G. / van Harmelen, F. A semantic web

primer. MIT Press.

[Abels et al. 2005] Abels, S. / Haak, L. / Hahn, A. Identification of

Common Methods Used for Ontology Integration

Tasks. In: Proceedings of the First international

Workshop on interoperability of Heterogeneous

information Systems. S. 75-78. ACM Press.

[Akahani et al. 2002] Akahani, J. / Hiramatsu, K. / Kogure, K. Coordinating

heterogeneous information services based on

approximate ontology translation. In: Proceedings of

AAMAS-2002 Workshop on Agentcities: Challenges in

Open Agent Systems. S. 10-14. Springer.

[Bellifemine et. al 2006] F. Bellifemine / G. Caire et al. JADE programmer's

guide. http://jade.tilab.com/doc/programmersguide.pdf

[Berners-Lee et al. 2001] Berners-Lee, T. / Hendler, J. / Lassila, O. The Semantic

Web. Scientific American, Mai 2001. S. 34-43.

[Bordini et al. 2006] Bordini, H. / Braubach, L. et al. A Survey of

Programming Languages and Platforms for Multi-Agent

Systems. Informatica, 1/2006. S. 33-44

[Bouquet 2005] Bouquet, P. (Hrsg.) Specification of a common

framework for characterizing alignment.

KnowledgeWeb Deliverable D 2.2.1.

http://www.aifb.uni-karlsruhe.de/WBS/phi/pub/kweb-

221.pdf

[Braun 2007] Braun, H. Webstandards im Wandel. Die Krise des

W3C und die Lösungsansätze. c’t. magazin für

computer technik, 1/2007. S. 162.

58

[Caire / Cabanillas 2006] Caire, G. / Cabanillas, D. JADE Tutorial Application-

defined content languages and ontologies.

http://jade.tilab.com/doc/CLOntoSupport.pdf

[Choi et al. 2006] Choi, N. / Song, I. / Han, H. A Survey on Ontology

Mapping. SIGMOD Record, September 2006. S. 34-41.

[Ehrig / Staab 2004] Ehrig, M. / Staab, S. Efficiency of Ontology Mapping

Approahces. http://www.aifb.uni-

karlsruhe.de/WBS/meh/publications/ehrig04efficiencyS

IMIS.pdf

[FIPA 2001] FIPA Ontology Service Specification. Foundation for

Intelligent Physical Agents.

http://www.fipa.org/specs/fipa00086/XC00086C.html

[FIPA 2002] FIPA SL Content Language Specification. Foundation

for Intelligent Physical Agents.

http://www.fipa.org/specs/fipa00008/SC00008I.html

[Franklin / Graesser 1997] Franklin, S. / Graesser, A. Is it an Agent, or Just a

Program?: A Taxonomy for Autonomous Agents. In

Proceedings of the Workshop on intelligent Agents Iii,

Agent theories, Architectures, and Languages. S. 21-35.

Springer.

[Gómez-Pérez 2002] Gómez-Pérez, A (Hrsg.) Deliverable 1.3: A survey on

ontology tools. IST project IST-2000-29243.

http://www.aifb.uni-

karlsruhe.de/WBS/ysu/publications/OntoWeb_Del_1-

3.pdf

[Gruber 1993] Gruber, T.R. A translation approach to portable

ontology specifications. Knowledge Acquisition, Juni

1993. S. 199-220.

59

[Gruber 2005] Ontology of Folksonomy: A Mash-up of Apples and

Oranges. http://tomgruber.org/writing/ontology-of-

folksonomy.htm

[Grütter 2006] Grütter R. Software-Agenten im Semantic Web.

Springer Informatik Spektrum, Februar 2006. S. 3-13.

[Kalfoglou / Schorlemmer 2005] Kalfoglou, Y. / Schorlemmer, M. Ontology Mapping:

The State of the Art.

http://drops.dagstuhl.de/opus/volltexte/2005/40

[Kalyanpur et al. 2004] Kalyanpur, A. / Jiménez, D et al. Automatic Mapping of

OWL Ontologies into Java. In: Proceedings of the

Sixteenth International Conference on Software

Engineering & Knowledge Engineering. S. 98-103.

Springer.

[Khalique et al. 2005] Khalique, S. / Jamshed S. et al. Assessment of OWL

and FIPA-SL as semantic language. In: IEEE

International Conference on Emerging Technologies. S.

536-541. IEEE.

[Li et al. 2006] Li, L. / Baolin, W. / Yun, Y. Implementation of Agent-

based Ontology Mapping and Integration. Technical

Report, Swinburne University. In: IEEE International

Conference on e-Business Engineering (ICEBE'06). S.

208-215. IEEE

[McGuinness / van Harmelen

2004]

McGuinness, D. / van Harmelen, Frank. OWL Web

Ontology Language Overview.

http://www.w3.org/TR/owl-features/ 2004

[Noy 2004] Noy, N. Semantic Integration: A Survey Of Ontology-

Based Approaches. SIGMOD Record, Dezember 2004,

S. 65-70.

60

[Noy / Stuckenschmidt 2005] Noy, N. / Stuckenschmidt, H. Ontology Alignment: An

annotated Bibliography.

http://drops.dagstuhl.de/opus/volltexte/2005/48

[Reif 2006] Reif, G. Semantische Annotation. In: Pellegrini, T /

Blumauer, A. (Hrsg.). Semantic Web. Wege zur

vernetzten Wissensgesellschaft. Springer.

[Schmitz et al.2006] Schmitz, C. et al. Kollaboratives Wissensmanagement.

In: Pellegrini, T / Blumauer, A. (Hrsg.). Semantic Web.

Wege zur vernetzten Wissensgesellschaft. Springer.

[Shvaiko 2004] Shvaiko, P. A classification of schema-based matching

approaches. Technical Report # DIT-04-093.

http://dit.unitn.it/~bouquet/ISWC-04-MCN/papers/13-

Shvaiko.pdf

[Suguri et al. 2001] H. Suguri / Kodama, E. Implementation of FIPA

ontology service. In: Workshop on Ontologies in Agent

Systems, 5th International Conference on Autonomous

Agents.

http://citeseer.ist.psu.edu/suguri01implementation.html

[Willmott et al. 2001] Willmott, S. / Dale, J. et al. Agentcities: A Worldwide

Open Agent Network. AgentLink News November

2001. S. 13-15.

[Vander Wal 2007] Vander Wal, T. Folksonomy.

http://vanderwal.net/folksonomy.html