Dieser Artikel verrät Ihnen, was ein Auto mitten in einem Fluss mit Ontologien und Softwareentwicklung zu tun haben könnte und warum Sie Ihrem Auto-Navigationssystem nicht blind vertrauen sollten. Am Beispiel der Sprache DAML+OIL wird der praxisrelevante Mehrwert von Ontologien für die Nutzung und Verteilung von Informationen dargestellt.

Am 25. Dezember 1998 machte ein Autofahrer die feuchte Erfahrung, dass man sich nicht blind auf Auto-Navigationssysteme verlassen sollte. Der weiter geradeaus-Anweisung folgend fuhr er seinen Wagen mitten in die Havel, da dem System entgangen war, dass die zur Überquerung benötigte Autofähre gerade am gegenüberliegenden Ufer lag [1]. Wie konnte es zu diesem Fehler kommen und wie lassen sich solche Fehleinschätzungen in Zukunft vermeiden? Um diese Fragen zu klären wollen wir uns im Folgenden mit der Idee der Web-Ontologien vertraut machen.

Was sind Ontologien?
Der Begriff der Ontologie kommt ursprünglich aus der Philosophie und dort aus dem Gebiet der Seinslehre. Im Kontext der Informationstechnologie hat sich unter anderen die Definition von Gruber [2] etabliert. Laut dieser ist eine Ontologie eine explicit specification of shared conceptualisation. Um diese abstrakte Definition mit Leben zu füllen, wollen wir einen kurzen Abstecher in die Wissenschaft der Zeichen, die Semiotik [3], wagen. Ogden und Richards [4] beschreiben anhand des so genannten meaning triangle, wie die Verknüpfung von einem Symbol (Bezeichner) zu einem Objekt (dem Bezeichneten) entsteht. Zwischen den beiden gibt es wie in Abbildung 1 deutlich wird keine direkte, sondern nur eine mittelbare Beziehung. Der Bezeichner zeigt also nicht direkt auf das Bezeichnete, sondern auf ein Konzept, eine Idee des Bezeichneten. Der Begriff Ente zeigt also nicht auf das eine konkrete Tier vor unseren Füßen, sondern auf das Konzept in unserer Vorstellung, welches die Enten als Tiere repräsentiert. Solche Konzepte sind essenziell für die menschliche - und, wie wir im Folgenden sehen werden, auch für die maschinelle - Kommunikation. Dies liegt unter anderem daran, dass die Zuordnung zwischen Bezeichner und Bezeichnetem nicht immer eindeutig ist. In unserem Beispiel kann der Bezeichner Ente sowohl auf das Tier als auch auf das berühmte Studentenauto mit dem selben Namen oder etwa auf die Zeitungsente zeigen. Unterschieden werden die drei aber eindeutig durch die zugrunde liegenden Konzepte: einerseits das Konzept eines Autos, andererseits das eines Tiers. Ontologien sind der Versuch, die Konzepte, anhand derer wir kommunizieren, eindeutig zu beschreiben.

Abb. 1: Das Bedeutungsdreieck nach Ogden und Richards

Die Notwendigkeit einer eindeutigen Zuordnung von Zeichen über Konzept zu Bezeichnetem beschreibt Davenport [5] wie folgt: People can't share knowledge if they don't speak a common language. Während einem menschlichen Benutzer zumindest in den meisten Fällen zugetraut werden kann, anhand des Kontexts zu erkennen, ob die Ente als Tier oder Auto gemeint ist, gilt dies für Maschinen keineswegs. Ohne weiteres könnte man Davenports Aussage daher auch auf die maschinelle Kommunikation anwenden: Systeme sind nur dann in der Lage, erfolgreich zusammenzuarbeiten, wenn sie eine gemeinsame Auffassung der Kommunikationsinhalte teilen.

Anwendungsgebiete von Ontologien
In der Informationstechnologie werden Ontologien inzwischen vielseitig und mit zunehmender Intensität eingesetzt und haben den Status eines rein akademischen Betätigungsfeldes verlassen. Grob lassen sich die Anwendungsszenarien für Ontologien nach Jasper [6] in vier Gruppen gliedern:

• Neutral Authoring: Ontologien können dazu genutzt werden, Informationen anwendungsunabhängig in einer grundlegenden Ontologiesprache zu beschreiben und anschließend bei Bedarf in weitere Zielsprachen zu übersetzen. Dies fördert vor allem die Wiederverwertbarkeit und Wartbarkeit von Informationen.
• Ontologien als Spezifikationen: Mittels Ontologien kann ein Grundvokabular definiert werden, welches später als Basis für die Entwicklung von Software dient. Neben der Wiederverwertbarkeit und Wartbarkeit unterstützt dieses Verfahren auch die Dokumentation der Software. Die in dieser Ontologie aufgestellten Annahmen über das Grundvokabular trennen zudem die Logik der Applikation von deren konkreter Umsetzung in einer Programmiersprache.
• Gemeinsamer Zugang zu Informationen: Wie bereits beschrieben, ist es für menschliche und maschinelle Kommunikation notwendig, dass die Partner das selbe wohldefinierte Vokabular nutzen. Dies kann mit Ontologien erreicht und somit Interoperabilität ermöglicht werden. Der Fokus dieses Szenarios liegt also auf dem gemeinsamen Zugriff auf explizit spezifiziertes Vokabular.
• Ontologie-basierte Suche: Mittels Ontologien können das Suchen nach Informationen erleichtert und die Treffsicherheit von Suchmaschinen verbessert werden. Die Suchmaschine wäre in der Lage, nicht mehr nur nach bloßem Schlagwortvorkommen, sondern auch nach Assoziationen und Beziehungen zwischen Dingen zu suchen.

Die einzelnen Anwendungsszenarien haben teilweise unscharfe Grenzen und gehen ineinander über. In diesem Artikel liegt der Schwerpunkt vor allem auf der Spezifizierung eines expliziten Grundvokabulars, das später als Basis einer Applikation genutzt werden könnte.

Das Auto in der Havel
Was hat nun das Auto in der Havel mit Ontologien zu tun? Sehr viel, wie Sie sehen werden. Das Navigationssystem des Pkw machte möglicherweise keinen Unterschied zwischen Verbindungen, die durchgängig verfügbar sind (wie etwa einer Landstraße) und solchen, die nur temporär nutzbar sind (in diesem Fall die Fähre). Um es im Sinne von Ontologien auszudrücken, war das Konzept hinter dem Begriff Fähre nicht vorhanden oder es berücksichtigte nicht, dass eine Fähre nicht zeitunabhängig als Verbindung genutzt werden kann [7].

Im Folgenden soll Schritt für Schritt eine Ontologie erstellt werden, welche Fähren als temporäre Verbindungen beschreibt, die nur zu bestimmten Uhrzeiten nutzbar sind. Zudem wollen wir Fähren in Autofähren und Katamarane unterscheiden, wobei letztere über keine Fahrzeugstellplätze verfügen.

DAML+OIL
Bei DAML+OIL [8] handelt es sich um eine Ontologiebeschreibungssprache, die als Synthese der Sprachen DAML (DARPA Agent Markup Language) und OIL (Ontology Inference Layer) entstanden ist. Dabei nutzt DAML+OIL die vom World Wide Web Consortium (W3C) spezifizierte Sprache RDF (Resource Description Framework) [9] und bildet auf XML ab. Da RDF bereits in einer früheren Ausgabe dieses Magazins beschrieben wurde (XML & Web Services Magazin 1.2003), soll hier nicht weiter darauf eingegangen werden. Mittels DAML+OIL werden wir im Folgenden eine Ontologie von Fähren spezifizieren, die eine Fahrt in die Havel möglicherweise verhindert hätte. Um den Rahmen des Artikels nicht zu sprengen, werden wir dabei nur auf einige wenige Konzepte eingehen und diese nur insofern erläutern, als sie für das Verständnis der Ontologie nötig sind.

Jede DAML+OIL-Ontologie beginnt mit der Definition von Namensräumen:

<rdf:RDF

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

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:xsd ="http://www.w3.org/2000/10/XMLSchema#"

xmlns:daml="http://www.daml.org/2001/03/daml+OIL#"

>

In diesem Fall werden nur die Standard-Namensräume für XML-S, RDF, RDF-S und DAML+OIL definiert. Da einer der Hauptvorteile von Ontologien in deren Wiederverwendbarkeit liegt, würde man hier auch externe Ontologien einbinden. Diese kann man beispielsweise in der DAML Ontology Library [10] finden.

Im nächsten Schritt wird deklariert, dass es sich um eine Ontologie handelt. Zudem werden üblicherweise ein Versionshinweis und ein kurzer Kommentar zu Inhalt und Anwendungsgebiet angegeben:

<daml:Ontology rdf:about="">

<daml:versionInfo>$ faehre.daml, v 1.0 $</daml:versionInfo>

<rdfs:comment>

Eine stark vereinfachte, unvollstaendige Ontologie ueber Faehren.

</rdfs:comment>

<daml:imports rdf:resource="http://www.daml.org/2001/03/daml+OIL"/>

</daml:Ontology>

Anschließend werden die Standard-DAML+OIL-Ontologien mittels der imports-Funktion hinzugeladen. Diese sind selbst wiederum in DAML+OIL und RDF beschrieben. Wenn Sie sich bei der Verwendung eines DAML+OIL-Elements einmal nicht schlüssig sein sollten, hilft ein Blick in diese Definitionen meistens einen großen Schritt weiter.

Als nächstes spezifizieren wir eine Klasse aller Dinge, die Verbindungen von einem Ort zu einem anderen darstellen. Bei einer vollständigen Ontologie müsste man auch das Konzept Ort beschreiben sowie festlegen, dass jede Verbindung einen Start- und einen Zielort hat. Wir beschränken uns hier jedoch auf das Nötigste. Alternativ könnten an dieser Stelle zum Beispiel die Klasse Location aus der Geofile-Ontologie [11] eingebunden werden.

<daml:Class rdf:ID="Verkehrsverbindung">

<rdfs:label>Verkehrsverbindung</rdfs:label>

<rdfs:comment>

Eine Superklasse fuer Verkehrsverbindungen von einem Ort zum anderen.

Eine Strecke von Muenster nach Borkum kann als eine geordnete Zusammensetzung verschiedener Verbindungen von Orten gesehen werden. Dabei soll eine Verkehrsverbindung immer nur ueber ein Transportmedium laufen. Also z.B. die Bahnverbindung von Muenster nach Emden als eine Verbindung und eine naechste per Faehre von Emden nach Borkum.

</rdfs:comment>

</daml:Class>

Nun leiten wir von Verkehrsverbindung zwei Subklassen mittels des Elements subClassOf ab. Die eine enthält permanente (z.B. Straßen), die andere temporäre Verbindungen (z.B. Fähren) (siehe Listing 1).

Listing 1

<daml:Class rdf:ID="PermanenteVerbindungen">

<rdfs:label>PermanenteVerbindungen</rdfs:label>

<rdfs:subClassOf rdf:resource="#Verkehrsverbindung"/>

<rdfs:comment>

Verkehrsverbindungen die permanent benutzbar sind. Klassen

Wie Landstraße oder Autobahn erben von dieser Superklasse.

</rdfs:comment>

</daml:Class>



<daml:Class rdf:ID="TemporaereVerbindungen">

<rdfs:label>TemporaereVerbindungen</rdfs:label>

<rdfs:subClassOf rdf:resource="#Verkehrsverbindung"/>

<rdfs:comment>

Verkehrsverbindungen die temporaer benutzbar sind. Klassen

Wie Faehre erben von dieser Superklasse.

</rdfs:comment>

<daml:disjointWith rdf:resource="#PermanenteVerbindungen"/>

</daml:Class>

Das Element disjointWith bedeutet, dass eine Verbindung immer nur entweder permanent oder temporär sein kann, aber nie beides gleichzeitig. Wenn wir also später die Klasse der Fähren spezifizieren, so kann diese nur entweder von der einen oder der anderen Klasse erben.

Im Folgenden definieren wir eine Eigenschaft, die jeweils den nächsten Zeitpunkt beschreibt, an dem eine temporäre Verbindung verfügbar ist:

<rdf:Property rdf:ID="istVerfuegbar">

<rdfs:comment>

Eine generische Eigenschaft die die Verfuegbarkeit von temporaeren

Verbindungen beschreibt

</rdfs:comment>

</rdf:Property>

Eine der Forderungen, die an Ontologien gestellt werden, ist, dass sie so allgemein wie möglich gehalten werden sollen. Dies ist vor allem für die geforderte Wiederverwendbarkeit von Bedeutung. Eine zu spezielle Ontologie könnte nicht oder nicht effektiv erweitert werden. Daher definieren wir istVerfuegbar hier nur als RDF-Property und sagen somit nur aus, dass es sich um eine Eigenschaft handelt. In einem späteren Schritt werden wir weitere Festlegungen treffen. Der Vorteil dieses Verfahrens ist, dass die Sichtbarkeit dieser späteren Spezifizierung nur lokal und nicht global ist, doch dazu später mehr.

Als nächstes fügen wir unserer Ontologie eine Eigenschaft hinzu, welche die Anzahl von Fahrzeugstellplätzen auf einer Fähre beschreibt. Diese Eigenschaft ist sehr konkret, da sie nur für Fähren (und eventuell andere Verkehrsmittel wie die Bahn) genutzt werden soll. Daher benutzen wir für ihre Spezifikation das Element daml:DatatypeProperty. DAML+OIL unterscheidet zwischen DatatypeProperty und ObjectProperty. Der Kasten Eigenschaften in DAML+OIL erläutert die Unterschiede zwischen diesen beiden Eigenschaften.

<daml:DatatypeProperty rdf:ID="Fahrzeugstellplaetze">

<rdfs:comment>

Anzahl von Fahrzeugstellplaetzen in einem Transportmedium

</rdfs:comment>

<rdfs:domain rdf:resource="#Transportmedium"/>

<rdfs:range rdf:resource="http://www.w3.org/2000/10/XMLSchema#nonNegativeInteger"/>

</daml:DatatypeProperty>

Mittels des Elements rdfs:domain definieren wir, dass die Eigenschaft Fahrzeugstellplaetze zum Konzept von Transportmedien gehört und nur dort genutzt werden kann. Über die rdfs:range-Eigenschaft legen wir den Wertebereich fest, der für diese Eigenschaft erlaubt ist. In unserem Fall kann die Anzahl der Stellplätze sinnvollerweise nur positive ganze Zahlen inklusive der Zahl 0 annehmen.

Gerüstet mit diesen Eigenschaften erschaffen wir nun eine Superklasse der Transportmedien, über die wir nur aussagen wollen, dass sie über die Eigenschaft Fahrzeugstellplaetze verfügt und selbst eine Subklasse von TemporaereVerbindungen ist:

<daml:Class rdf:ID="Transportmedium">

<rdfs:label>Transportmedium</rdfs:label>

<rdfs:comment>

Superklasse fuer alle Transportmedien.

</rdfs:comment>

<rdfs:subClassOf rdf:resource="#TemporaereVerbindungen"/>

<rdfs:subClassOf>

<daml:Restriction daml:cardinality="1">

<daml:onProperty rdf:resource="#Fahrzeugstellplaetze"/>

</daml:Restriction>

</rdfs:subClassOf>

</daml:Class>

Sie werden sich nun fragen, was es an dieser Stelle mit dem zweiten rdfs:subClassOf-Element innerhalb der Klasse der Transportmedien auf sich hat. Dies hat mit der engen Beziehung von OIL zur mathematischen Mengenlehre zu tun und drückt folgende Idee aus: Es wird eine anonyme Subklasse der Dinge erschaffen, die genau einmal über die Eigenschaft Fahrzeugstellplaetze verfügen. Aus der Schachtelung dieser unbenannten Klasse innerhalb der Klasse der Transportmedien ergibt sich die Aussage, dass ein Transportmedium eine Subklasse der Klasse aller Dinge ist, die über Fahrzeugstellplätze verfügen. Vereinfacht gesagt verfügt ein Transportmedium über eine Anzahl an Stellplätzen.

Als nächstes fügen wir unserer Ontologie das Konzept der Fähre hinzu:

<daml:Class rdf:ID="Faehre">

<rdfs:label>Faehre</rdfs:label>

<rdfs:comment>

Fortbewegungsmittel ueber Wasser

</rdfs:comment>

<rdfs:subClassOf rdf:resource="#Transportmedium"/>

<rdfs:subClassOf>

<daml:Restriction daml:cardinality="1">

<daml:onProperty rdf:resource="#istVerfuegbar"/>

<daml:toClass rdf:resource="http://www.w3.org/2000/10/XMLSchema#time"/>

</daml:Restriction>

</rdfs:subClassOf>

</daml:Class>

An dieser Stelle spezifizieren wir nun auch die oben erschaffene Eigenschaft istVerfuegbar und fordern, dass es sich dabei um den XML Schema-Datentyp time, also eine Uhrzeit, handeln muss. Hier kommt die oben angesprochene Sichtbarkeit zum Tragen. Die Einschränkung auf den Typ time gilt nur innerhalb der Klasse der Fähren. Eine Gebirgsstraße, die nur im Sommer befahren werden darf, könnte also ebenfalls die istVerfuegbar Eigenschaft nutzen und im Unterschied zu dem hier dargestellten Fall einen Jahresabschnitt [12] als Datentyp fordern.

Zuletzt spezifizieren wir noch zwei Subklassen der Fähre, die Autofähre und den Katamaran, welcher im Gegensatz zur erstgenannten über keine Fahrzeugstellplätze verfügt (siehe Listing 2). Auch hier gilt der Ansatz, dass ein Katamaran eine Subklasse der Klasse der Dinge ist die über genau keinen Stellplatz verfügen.

Listing 2

<daml:Class rdf:ID="Autofaehre">

<rdfs:label>Autofaehre</rdfs:label>

<rdfs:subClassOf rdf:resource="#Faehre"/>

</daml:Class>



<daml:Class rdf:ID="Katamaran">

<rdfs:label>Katamaran</rdfs:label>

<rdfs:subClassOf rdf:resource="#Faehre"/>

<daml:disjointWith rdf:resource="#Autofaehre"/>

<rdfs:subClassOf>

<daml:Restriction>

<daml:onProperty rdf:resource="#Fahrzeugstellplaetze"/>

<daml:hasValue>0</daml:hasValue>

</daml:Restriction>

</rdfs:subClassOf>

</daml:Class>

Abschließend möchten wir als Beispiel zwei Instanzen erschaffen:

<faehre:Autofaehre rdf:ID="Autofaehre1">

<rdfs:label>Autofaehre1</rdfs:label>

<faehre:istVerfuegbar><xsd:time rdf:value="16:15:00"/></faehre:istVerfuegbar>

<faehre:Fahrzeugstellplaetze>42</faehre:Fahrzeugstellplaetze>

</faehre:Autofaehre>

Diese Instanz folgt dem von uns festgelegten Konzept für Autofähren, eine Validierung der Ontologie würde also keine Fehler melden. Anders sieht es bei dem folgenden Katamaran aus:

<faehre:Katamaran rdf:ID="Katamaran2">

<rdfs:label>Katamaran2</rdfs:label>

<faehre:istVerfuegbar><xsd:time rdf:value="16:45:00"/></faehre:istVerfuegbar>

<faehre:Fahrzeugstellplaetze>1</faehre:Fahrzeugstellplaetze>

</faehre:Katamaran>

Entgegen unseren Festlegungen verfügt dieser Katamaran über einen Stellplatz für Fahrzeuge. Dies haben wir jedoch in unserem Konzept für Katamarane grundsätzlich ausgeschlossen. Eine Validierung würde eine Verletzung der hasValue-Restriction ergeben, denn es ist nur der Wert 0 erlaubt. Wie DAML-Dokumente validiert werden können, erläutert der Kasten Validierung von DAML+OIL-Dokumenten. Mittels </rdf:RDF> beenden wir unsere Ontologie.

Was haben wir erreicht? Wir haben eine Unterscheidung zwischen temporären und permanenten Verkehrsverbindungen erstellt und Fähren als Dinge definiert, die zu einer bestimmten Uhrzeit verfügbar sind und entweder über Stellplätze für Fahrzeuge verfügen oder, im Fall des Katamarans, nur Personen befördern können. Ein Software-Agent wie zum Beispiel ein Routenplaner oder Navigationssystem kann mittels unserer Festlegungen erkennen, dass ein Katamaran für den Weg von Emden nach Borkum nicht geeignet ist, wenn wir mit einem PKW reisen, und dass die geeignete Autofähre nicht jederzeit verfügbar ist. Ein unfreiwilliges Bad in der Ems würde uns somit erspart bleiben. Wenn Sie sich an die oben erwähnten Einsatzgebiete von Ontologien erinnern, kann unsere Ontologie sowohl als Basis für unsere Navigationssoftware dienen als auch Kunden und anderen Interessierten zur Verfügung gestellt werden, um klarzustellen, auf welchen Annahmen unser System basiert. Dies ist ein erster Schritt zur Interoperabilität, denn die Ontologie erlaubt uns, das selbe Konzept mit anderen Diensten zu teilen. Eine Software, die unsere Ontologie nutzt, wird beispielsweise zwangsläufig die Verfügbarkeit der Fähren berücksichtigen und diese nicht als permanente Verbindungen ansehen.

Zudem ist es uns gelungen, die Anwendungslogik von der softwaretechnischen Umsetzung zu trennen. Die Ideen und Konzepte, auf denen unsere Software basiert, befinden sich in einem externen, selbsterklärenden Dokument und sind nicht im Quellcode unserer Anwendung versteckt. Im Gegensatz zu Technologien wie UML ist unser Konzept maschinenlesbar und lässt sich zudem samt einzelner Instanzen validieren.

Eigenschaften in DAML+OIL
DAML+OIL unterscheidet zwischen zwei Typen von Eigenschaften, den ObjectProperties und den DatatypeProperties. Im ersten Fall wird dabei ein Objekt mit einem anderen über die Eigenschaft in Beziehung gebracht. So könnte zum Beispiel eine istBesitzVon-ObjectProperty zwischen Fähre und Reederei bestehen. Im Falle der DatatypeProperties wird ein Objekt in Beziehung mit einem Datentyp gesetzt, wie im Fall der Fahrzeugstellplaetze. Das Objekt Transportmedium hat also eine nicht negative Anzahl x von Stellplätzen.

Validierung von DAML+OIL-Dokumenten
Für die Kontrolle der erstellten Ontologien eignet sich der DAML-Validator, den Sie unter www.daml.org/validator/ downloaden können. Alternativ ist es ebenfalls möglich, die Ontologien dort online prüfen zu lassen. Der Umgang mit dem Validator erfordert jedoch etwas Geduld und gute Programmier- und XML-Kenntnisse, da die Fehlermeldungen teilweise recht kryptisch sind. Wundern Sie sich zudem nicht, wenn viele der im Internet verfügbaren DAML-Ontologien vom Validator als fehlerhaft bezeichnet werden. Sowohl die Sprache DAML+OIL als auch der Validator befinden sich selbst noch im Prozess der Entwicklung.

Ausblick
Mit der zunehmenden Automatisierung auf der einen Seite und der Entstehung des Semantic Webs und der Web Services auf der anderen Seite wächst der Bedarf an maschinenlesbarem und explizit spezifiziertem Vokabular. So ist automatisiertes Service Chaining nur denkbar, wenn die einzelnen Services die selben Konzepte referenzieren. Mit DAML for Services (DAML-S) [13] entsteht zur Zeit eine Sprache, die genau an dieser Stelle ansetzt. Von Seiten des World Wide Web-Konsortiums entsteht mit der Web Ontology Language (OWL) [14] eine an DAML angelehnte Sprache für Web-Ontologien.

Die Forschungsarbeit im Bereich Web-Ontologien und semantische Probleme im allgemeinen erfolgte innerhalb des EU-Projekts Bridge-IT [15] und der Münsteraner Forschungsgruppe MUSIL [16], daher gilt beiden mein besonderer Dank.

Links und Literatur

• [1] Hamburger Abendblatt, 28.12.1998, S.15
• [2] T.R. Gruber,Toward Principles for the Design of Ontologies Used for Knowledge Sharing, International Journal of Human Computer Studies (43:5/6), 1995, pp. 907-928.
• [3] Einführung in die Semiotik: Jürgen Trabant, Elemente der Semiotik, Tübingen, Basel, Francke Verlag, 1996
• [4] Charles K. Ogden, Ivor A. Richards, The Meaning of Meaning. London, 1923
• [5] T. H. Davenport, L. Prusak,. Working knowledge: how organizatons manage what they know, Boston, MA., Harvard Business School Press, 1998
• [6] M. Uschold, R. Jasper, A framework for understanding and classifying ontology applications, Proceedings of the IJCAI-99 workshop on ontologies and Problem-Solving Methods (KRR5), vol. 18, Stockholm, Sweden, 1999
• [7] hier wird das Havel Problem aus ontologischer Sichtweise genauer betrachtet: musil.uni-muenster.de/documents/UCSDtalk.ppt
• [8] www.daml.org/
• [9] www.w3c.org/RDF/
• [10] www.daml.org/ontologies/
• [11] www.daml.org/2001/02/geofile/geofile-ont.daml#Location
• [12] ontobroker.semanticweb.org/ontos/compontos/tourism_II1.daml#Jahresabschnitt
• [13] www.daml.org/services/daml-s/0.7/
• [14] www.w3.org/TR/owl-ref/
• [15] www.bridge-it.info/
• [16] musil.uni-muenster.de/