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
 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.

3
4
 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

5
 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

6
 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

7
8
 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]

9
 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.

10
 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).

11
12
 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

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

13
 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.

14
 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

15
 (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.

16
 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.

17
 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.

18
 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.

19
 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/)

20
 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.

21
 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/)

22
 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.

23
 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 5: Tagging bei del.icio.us

Abbildung 4: Tagging bei YouTube

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

24
 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.

25
26
 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.

27
 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.

28
 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);
[…]
}
}

29
 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.

30
 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);
[…]
}

31
 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]).

32
 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.

33
 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

34
 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

35
 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

36
 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].

37
 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

38
 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 zeigt 35. 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]

39
 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/

40
 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.

41
 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

42
 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]

43
44
 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

45
 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.

46
 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)

47
 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].

48
 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]

49
 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

50
 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]

51
 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.

52
 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.

53
54
 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.

55
56
 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.

57
 [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.

58
 [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 McGuinness, D. / van Harmelen, Frank. OWL Web

2004] 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.

59
 [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

60