OWL Web Ontology Language Guide
Deutsche Übersetzung

Original:
http://www.w3.org/TR/2004/REC-owl-guide-20040210/
Diese Übersetzung:
http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.html
Version 1.1 2006/04/12
Übersetzer:
Anton Köstlbacher,
Max Diehn,
Andreas Stephan,

Dieses Dokument ist eine deutsche Übersetzung eines W3C -Textes. Sie enthält möglicherweise Fehler. Sie hat keinerlei durch das W3C legitimierte normative Wirkung. Das maßgebende Dokument ist das englische Original.

Bitte melden Sie Fehler in der deutschen Fassung an den Übersetzer. Die Rechte an dieser deutschen Fassung liegen beim Übersetzer.

W3C

OWL Web Ontology Language
Guide

W3C Empfehlung vom 10.Februar 2004

Diese Version:
http://www.w3.org/TR/2004/REC-owl-guide-20040210/
Neueste Version:
http://www.w3.org/TR/owl-guide/
Vorhergehende Version:
http://www.w3.org/TR/2003/PR-owl-guide-20031215/
Autoren:
Michael K. Smith, Electronic Data Systems, Michael dot Smith at e d s dot com
Chris Welty, IBM Research, Chris dot Welty at u s dot ibm dot com
Deborah L. McGuinness, Stanford University, d l m at k s l dot stanford dot edu

Bitte beachten Sie die errata für dieses Dokument, die normative Korrekturen enthalten können.

Siehe auch Übersetzungen.


Zusammenfassung

Das World Wide Web ähnelt momentan einer schlecht erfassten Geographie. Unsere Einsicht in Dokumente und deren verfügbares Potential basiert auf einer Schlagwortsuche, die durch kluge Verwendung von Beziehungen zwischen Dokumenten und durch typische Anwendungsszenarien begünstigt wird. Die schiere Masse dieser Daten kann ohne die Unterstützung durch mächtige Werkzeuge nicht bewältigt werden. Um dieses Gelände präziser abzubilden, benötigen automatische Agenten maschinenlesbare Beschreibungen des Inhalts und Zugriff auf Webressourcen. Diese Beschreibungen der Informationen müssen den für Menschen lesbaren Versionen hinzugefügt werden.

Die OWL Web Ontology Language wurde entwickelt, um Klassen und Relationen beschreiben zu können, die Webdokumenten und -applikationen innewohnen.

Dieses Dokument demonstriert den Gebrauch von OWL, um

  1. eine Domäne durch die Definition von Klassen und Properties (Eigenschaften) dieser Klassen zu formalisieren,
  2. Individuals zu definieren und ihnen Properties zuzuweisen.
  3. aus diesen Klassen und Individuals, soweit es durch die formale Semantik der OWL Sprache erlaubt ist, Schlussfolgerungen zu ziehen.

Beginnend mit den Grundlagen präsentiert dieser Text stufenweise die Definition der Klassen, Properties und Individuals um später die komplexeren Sprachkomponenten zu behandeln.


Status dieses Dokuments

Dieses Dokument wurde von den W3C Mitgliedern und anderen interessierten Gruppen geprüft und durch den Direktor als W3C Empfehlung bestätigt. Die Rolle des W3C beim Aussprechen dieser Empfehlung besteht darin, die Aufmerksamkeit auf die Spezifikation zu lenken und ihren weitverbreiteten Einsatz zu befördern. Dies verbessert die Funktionalität und Interoperabilität des Webs.

Dies ist einer von sechs Teilen aus denen die W3C Empfehlung für OWL, die Web Ontology Language besteht. Sie wurde von der Web Ontology Arbeitsgruppe als Teil der W3C Semantic Web Activity (Activity Statement, Group Charter) zur Veröffentlichung am 10. Februar 2004 entwickelt.

Der Entwurf von OWL, wie er in früheren Versionen dieser Dokumente angegeben wurde, wurde umfangreich überprüft und erfüllt die technischen Anforderungen der Arbeitsgruppe. Die Arbeitsgruppe hat alle erhaltenen Kommentierungen angesprochen, und wenn notwendig, Änderungen durchgeführt. Änderungen an diesem Dokument seit der vorgeschlagenen Empfehlung sind im Änderungsverzeichnis genau ausgeführt.

Kommentare senden Sie bitte an public-webont-comments@w3.org (Archiv), eine allgemeine Diskussion der verwandten Technologien ist willkommen unter www-rdf-logic@w3.org (Archiv).

Hier finden Sie eine Liste von Implementationen.

Das W3C pflegt eine Liste aller Patentveröffentlichungen, die mit dieser Arbeit verbunden sind.

Dieser Abschnitt beschreibt den Status des Dokuments zum Zeitpunkt der Veröffentlichung. Andere Dokumente können dieses Dokument ersetzen. Eine Liste der aktuellen W3C Veröffentlichungen und die neueste Ausgabe dieses technischen Reports finden Sie im W3C Index technischer Reports unter http://www.w3.org/TR/.


Inhalt


1. Einführung

"Sagen Sie mir, welche Weine ich zu welchem Gang des folgenden Menüs kaufen und servieren soll. Nebenbei bemerkt, ich mag keinen Sauternes."

Es wäre heute schwierig, einen Webagenten zu entwickeln, der imstande wäre, die Weine im Web zu finden, die dieser Anfrage entsprechen. Ein ähnliches Problem wäre es, einen Softwareagenten zu beauftragen, stimmige Reservierungen für eine Reise durchzuführen. (Für weitere Anwendungsbeispiele siehe OWL Requirements Dokument.)

Um diese Art von Auswertungen zu ermöglichen, ist es nötig über Stichworte hinauszugehen und die Bedeutung der im Web beschriebenen Ressourcen zu spezifizieren. Diese zusätzliche Interpretationsschicht fängt die Semantik der Daten ein.

Die OWL Web Ontologie Sprache ist eine Sprache zur Definition und Realisierung von Web Ontologien . Ontologie ist ein aus der Philosophie entliehener Ausdruck, der sich auf die Wissenschaft bezieht, die die unterschiedlichen Arten von Entitäten in der Welt und ihre Beziehungen untereinander zu beschreibt. EineOWL Ontologie kann Beschreibungen von Klassen, Properties und ihren Instanzen beinhalten. Ausgehend von solch einer Ontologie spezifiziert die formale OWL Semantik wie deren logische Konsequenzen abzuleiten sind. Zum Beispiel Fakten, die nicht explizit in der Ontologie vorhanden sind, jedoch aus deren Semantik abgeleitet werden können. Diese Ableitungen können auf einem einzelnen oder auf mehreren verteilten Dokumenten basieren, die mit hilfe kombinierter OWL Mechanismen definiert wurden.

Dieses Dokument ist eine Komponente der Beschreibung von OWL, der Web Ontologie Sprache, welche von der W3C Web Ontologie Arbeitsgruppe (WebOnt) erstellt wurde. Der Abschnitt "Roadmap für dieses Dokument" des OWL-Überlicks ([Overview], 1.1) beschreibt jeden der verschiedenen Teile und wie sie ineinander greifen.

Eine Frage, die sich aufdrängt, wenn man schon wieder einen neuen XML/Web Standard beschreibt, ist: "Was bringt es mir, was XML und XML Schema nicht leisten?" Auf diese Frage gibt es zwei Antworten.

1.1. Die OWL Gattungen

Die OWL Sprache stellt drei zunehmend ausdrucksstarke Untersprachen bereit; diese Untersprachen sind gestaltet worden, um den Bedürfnissen unterschiedlicher Gruppen von Implementierern und Benutzern entgegenzukommen.

Jede dieser Untersprachen ist eine Erweiterung ihres einfacheren Vorgängers. Das gilt sowohl in Bezug darauf, was legal ausgedrückt werden kann, als auch in Bezug darauf, was auf gültige Weise gefolgert werden kann. Die folgende Menge von Beziehungen trifft zu. Die jeweiligen Umkehrungen nicht.

Ontologieentwickler, die OWL verwenden, sollten sich überlegen welche Gattung ihren Bedürfnissen am Besten entgegenkommt. Die Wahl zwischen OWL Lite und OWL DL hängt von dem Ausmaß ab, zu welchem die User die ausdrucksstärkeren Beschränkungsmöglichkeiten, die durch OWL DL bereitgestellt werden, benötigen. Inferenzmaschinen für OWL Lite werden wünschenswerte Eigenschaften hinsichtlich der Verarbeitung besitzen. Inferenzmaschinen für OWL DL, welche mit einer entscheidungsfähigen Untersprache arbeiten, werden einer größeren worst-case Komplexität ausgeliefert sein. Die Wahl zwischen OWL DL und OWL Full hängt in erster Linie von dem Ausmaß ab, zu welchem die User die Fähigkeit von RDF Schema zur Metamodellierung (d.h. zur Definition von Klassen von Klassen) benötigen. Bei der Benutzung von OWL Full ist weniger leicht vorauszusagen, wie es um die Unterstützung von Inferenztätigkeiten bestellt ist. Für mehr Information zu diesem Thema siehe OWL semantics document.

Benutzer, die von RDF zu OWL DL oder OWL Lite migrieren, müssen sicherstellen, dass das ursprüngliche RDF Dokument mit den durch OWL DL und OWL Lite aufgestellten Einschränkungen konform ist. Die Details dieser Einschränkungen werde in Appendix E der OWL Referenz erklärt.

Wo wir Konstrukte einführen, die nur in OWL DL oder OWL Full erlaubt sind, werden diese durch "[OWL DL]" markiert.

1.2. Struktur des Dokuments

Um eine konsistente Menge von Beispielen innerhalb dieses Guides bereitzustellen haben wir eine wine und eine food Ontologie geschaffen. Dies sind OWL DL Ontologien. Ein Teil unserer Diskussion wird sich auf Fähigkeiten von OWL Full beziehen und ist dementsprechend markiert. Die wine und food Ontologien sind wesentlich veränderte Versionen eines Teils der DAML ontology Bibliothek, der eine lange Geschichte hat. Dieser Teil wurde ursprünglich durch McGuinness als CLASSIC- Beispiel für Entscheidungslogik entwickelt, dann zu einem Tutorial für Beschreibungslogik und schließlich zu einem Tutorial für Ontologien erweitert.

In diesem Dokument benutzen wir zur Präsentation der Beispiele die RDF/XML Syntax ([RDF], 5), da wir davon ausgehen, dass XML dem größten Publikum bekannt sein wird. Die normative Syntax für den Austausch von OWL Dokumenten ist RDF/XML. Bitte beachten Sie, dass OWL im Hinblick auf maximale Kompatibilität zu RDF und RDF Schema gestaltet worden ist. Diese XML und RDF Formate sind Teil des OWL Standards.

Alle Beispiele, die in diesem Dokument präsentiert werden, sind aus den in wine.rdf und food.rdf, befindlichen Ontologien entnommen worden. Ausnahmen sind jene Beispiele, die mit  ¬  im unteren rechten Eck markiert sind.


2. Die Struktur von Ontologien

OWL ist ein Teil der Semantic Web Aktivitäten. Diese zielen darauf ab, Resourcen im Web für automatisierte Prozesse zugänglicher zu machen, indem man Informationen über diese Resourcen hinzufügt. Da das Semantic Web von Haus aus ein verteiltes Netz ist, muss es in OWL möglich sein, Information aus verteilten Quellen zu beziehen. Dies wird zum Teil dadurch erreicht, dass Ontologien erlaubt wird, in Beziehung miteinander zu stehen, insbesondere durch expliziten Import von Information aus anderen Ontologien. Ausserdem macht OWL eine open world Annahme. Das bedeutet, dass Beschreibungen von Resourcen nicht auf eine einzige Datei oder einen einzigen Gültigkeitsbereich beschränkt sind. Eine Klasse C1 mag ursprünglich in der Ontologie O1 definiert worden sein, kann jedoch in anderen Ontologien erweitert werden. Die Folgen dieser Erweiterungen von C1 sind monoton. Neue Information kann vorhergehende Information nicht überschreiben. Neue Information kann widersprüchlich sein, aber Fakten und Schlußfolgerungen können nur hinzugefügt, nie entfernt werden.

Der Designer einer Ontologie muß sich der Möglichkeit solcher Widersprüche bewußt sein. Es ist zu erwarten, dass Werkzeuge helfen werden, solche Fälle aufzudecken.

Um eine Ontologie zu schreiben, die unzweideutig interpretiert und durch Softwareagenten genutzt werden kann, benötigen wir für OWL eine Syntax und formale Semantik. OWL ist eine Erweiterung des Vokabulars von [RDF Semantics] RDF. Die OWL Semantik ist definiert in OWL Web Ontology Language Semantics and Abstract Syntax.

2.1. Namespaces

Bevor wir eine Menge von Begriffen benutzen können, muß klar sein, welche spezifischen Vokabularien benutzt werden. Eine Standardkomponente einer Ontologie besteht unter anderem aus einer Menge von XML namespace Deklarationen, welche in einem öffnenden rdf:RDF tag untergebracht werden. Diese Deklarationen verhelfen zu einer unzweideutigen Interpretation von Identifiern und machen den Rest der Ontologiedarstellung viel lesbarer. Eine typische OWL Ontologie beginnt mit einer Namespace Deklaration ähnlich der Folgenden. Natürlich werden die URIs der definierten Ontologien üblicherweise keine w3.org Referenzierungen sein.

<rdf:RDF
    xmlns     ="http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlwine#"
    xmlns:vin ="http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlwine#"
    xml:base  ="http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlwine#"
    xmlns:food="http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlfood#"
    xmlns:owl ="http://www.w3.org/2002/07/owl#"
    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/2001/XMLSchema#">

Die ersten zwei Deklarationen identifizieren den Namespace, welcher mit dieser Ontologie assoziiert wird. Die Erste bildet den Default Namespace, und stellt klar, dass sich qualifizierte Identifier ohne Präfix auf die gegenwärtigen Ontologie beziehen. Die Zweite identifiziert den Namespace der gegenwärtigen Ontologie mit dem Präfix vin:. Die Dritte identifiziert die Basis - URI für dieses Dokument (siehe unten ). Die Vierte identifiziert den Namespace der unterstützenden "food" Ontologie mit dem Präfix food:.

Die fünfte Namespace Deklaration besagt, dass in diesem Dokument Elemente, welche mit dem Präfix owl: versehen werden, sich auf Dinge aus dem Namespace namens http://www.w3.org/2002/07/owl# beziehen. Das ist eine vereinbarte OWL Deklaration, die benutzt wird, um das OWL Vokabular einzuführen.

OWL hängt von Konstrukten ab, die durch RDF, RDFS und XML Schema Datentypen definiert sind. In diesem Dokument bezieht sich das rdf: Präfix auf Dinge, die aus dem Namespace namens http://www.w3.org/1999/02/22-rdf-syntax-ns# stammen. Die nächsten zwei Namespace Deklarationen machen ähnliche Aussagen über die Namespaces RDF Schema (rdfs:) und XML Schema Datentypen (xsd:).

Um das Schreiben von langen URLs zu erleichtern, kann es oft Sinn machen, einen Satz von Entitätendefinitionen in einer Document Type Declaration (DOCTYPE) bereitzustellen, welche den Ontologiedefinitionen voransteht. Die Namen, die durch die Namespace Deklarationen definiert werden, haben nur als Teil von XML Tags Bedeutung. Attributwerte beziehen sich nicht auf den jeweiligen Namespace. Aber in OWL referenzieren wir oft Ontologie Identifier durch Attributwerte. Sie können in ihrer voll expandierten Form geschrieben werden. Ein Beispiel: "http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlwine#merlot". Alternativ können Abkürzungen durch eine ENTITY Definition definiert werden, beispielsweise so:

<!DOCTYPE rdf:RDF [
    <!ENTITY vin  "http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlwine#" >
    <!ENTITY food "http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlfood#" > ]>

Nach diesem Paar von ENTITY Deklarationen können wir den Wert "&vin;merlot" schreiben; er würde zu "http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlwine#merlot". expandieren.

Wichtiger ist vielleicht, dass die rdf:RDF Namespace Deklarationen so vereinfacht werden können, dass Änderungen in den Deklarationen der Entitäten konsistent in der gesamten Ontologie umgesetzt werden.

<rdf:RDF
    xmlns     ="&vin;"
    xmlns:vin ="&vin;"
    xml:base  ="&vin;"
    xmlns:food="&food;"
    xmlns:owl ="http://www.w3.org/2002/07/owl#"
    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/2001/XMLSchema#">

2.2. Ontologie Header

Nachdem die Namespaces eingerichtet sind, binden wir normalerweise einige Aussagen über die Ontologie ein; sie werden unter einem owl:Ontology Tag gruppiert. Diese Tags unterstützen solche kritischen Standardaufgaben wie Kommentierungen, Versionskontrolle und die Einbindung weiterer Ontologien.

<owl:Ontology rdf:about="">
  <rdfs:comment>An example OWL ontology</rdfs:comment>
  <owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/PR-owl-guide-20031215/wine"/>
  <owl:imports rdf:resource="http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlfood"/>
  <rdfs:label>Wine Ontology</rdfs:label>
  ...

Man beachte, dass wir '...' benutzen, um zuzeigen, dass zusätzlicher Text um des Beispiels willen gestrichen wurde.

Das owl:Ontology Element ist der Ort, wo viele der OWL Metadaten für das Dokument zusammengefasst werden. Dies garantiert nicht, dass das Dokument eine Ontologie im klassischen Sinne ist. In manchen Benutzergruppen handeln Ontologien nicht von Individuals sondern nur von den Klassen und Eigenschaften, welche eine Domäne beschreiben. Wenn man OWL benutzt, um eine Sammlung von Instanzdaten zu beschreiben, kann das owl:Ontology Tag verwendet werden, um Versionsinformationen aufzuzeichnen und Definitionen zu importieren, von denen das Dokument abhängt. Folglich wurde der Begriff Ontologie in OWL erweitert, um Instanzdaten mit einzuschließen. (siehe oben).

Mittels rdf:about kann man einen Namen oder eine Referenz für die Ontologie angeben. Wenn, wie im Standardfall, der Wert "" ist, ist der Name der Ontologie die Basis - URI des owl:Ontology Elements. Typischerweise ist das die URI des Dokuments, welches die Ontologie enthält. Eine Ausnahme für diese Regel wäre ein Kontext, der xml:base verwendet; so kann die Basis - URI für ein Element auf einen anderen Wert als der URI des gegenwärtigen Dokuments gesetzt werden.

rdfs:comment stellt die offensichtlich benötigte Möglichkeit für Anmerkungen zur Verfügung.

owl:priorVersion ist ein Standardtag mit dem Zweck, Hinweise für Versionskontrollsysteme bereitzustellen, welche mit Ontologien arbeiten. Ontologieversionierung wird unten weiter diskutiert.

owl:imports stellt einen Mechanismus zum Inkludieren zur Verfügung. owl:imports nimmt ein einzelnes Argument entgegen, welches durch das rdf:resource Attribut identifiziert wird.

Der Import einer weiteren Ontologie bringt auch die gesamte Menge an Aussagen aus jener Ontologie in die gegenwärtige Ontologie. Normalerweise würde dieses mit einer Namespace Deklaration gehandhabt werden. Man beachte den Unterschied zwischen diesen zwei Mechanismen. Die Namespace Deklarationen stellen eine bequeme Methode zur Verfügung, Namen, die in anderen OWL Ontologien definiert wurden, zu referenzieren. owl:imports soll anzeigen, dass man die Aussagen einer Zielontologie inkludieren möchte. Der Import einer weiteren Ontologie O2, importiert auch all jene Ontologien, die O2 importiert.

Man beachte, dass owl:imports nicht immer funktionieren wird. Wie man sich beim Umgang mit dem Semantic Web leicht vorstellen kann, ist der Zugang zu im Web verteilten Ressourcen nicht immer möglich. Werkzeuge müssen sich dieser Situationen stellen; wie sie dies tun, ist in deren Implementierung festzulegen.

Man beachte, dass zur Benutzung des OWL Vokabulars kein Import der owl.rdf Ontologie erforderlich ist. Dieser Import wird auch gar nicht empfohlen.

Zusätzliche Tags, die man sinnvollerweise an dieser Stelle inkludieren könnte, sind unter den Dublin Core Metadaten Tags zu finden. Die Untermenge schließt Tags für einfache Typen oder Strings als Werte ein. Beispiele wären Title, Creator, Description, Publisher und Date (siehe RDF declarations).

Properties, welche als Anmerkungen gedacht sind, sollten durch owl:AnnotationProperty. deklariert werden, so z.B.

<owl:AnnotationProperty rdf:about="&dc;creator" />

OWL stellt noch einige weitere Mechanismen zur Verfügung, um die gegenwärtige Ontologie mit importierten Ontologien zu verbinden (siehe Mapping von Ontologien).

Wir inkludieren auch ein rdfs:label um eine natürlichsprachliche Bezeichnung für unsere Ontologie zu unterstützen.

Die ontology header Definition wird mit dem folgenden Tag geschlossen:

</owl:Ontology>

Diesem Vorspiel folgen die eigentlichen Definitionen, die die Ontologien ausmachen; es wird durch

</rdf:RDF>
geschlossen.

2.3. Datenaggregation und -schutz

Die Fähigkeit von OWL, ontologische Informationen über Instanzen, welche in mehreren Dokumenten erscheinen, auszudrücken, hilft beim konsequenten Verknüpfen von Daten aus unterschiedlichen Quellen. Die zugrundeliegende Semantik unterstützt Schlußfolgerungen aus diesen Daten, was zu unerwarteten Resultaten führen kann. Speziell kann die Möglichkeit, Äquivalenzen mittels owl:sameAs auszudrücken, benutzt werden um festzustellen, dass scheinbar unterschiedliche Individuals tatsächlich dieselben sind. Owl:InverseFunctionalProperty kann ebenfalls genutzt werden um Individuals miteinander zu verbinden. Wenn z.B. eine Eigenschaft wie "SocialSecurityNumber" eine owl:InverseFunctionalProperty ist, könnten zwei verschiedene Individuals als identisch inferiert werden, sofern sie bezüglich dieser Property denselben Wert haben. Wenn Individuals durch solche Mittel als identisch erkannt werden, kann Information aus unterschiedlichen Quellen über sie verschmolzen werden. Diese Aggregation kann benutzt werden, um Fakten festzustellen, die in keiner einzelnen Quelle direkt repräsentiert werden.

Die Fähigkeit des Semantic Web, Information aus unterschiedlichen Quellen zu verknüpfen, ist eine wünschenswerte und mächtige Eigenschaft, welches in vielen Anwendungen genutzt werden kann. Jedoch bringt die Fähigkeit, Daten aus mehreren Quellen zu verschmelzen in Verbindung mit dem Inferenzpotential von OWL auch Mißbrauchsmöglichkeiten mit sich. Benutzer von OWL sollten sich der potentiellen Konsequenzen für das Thema Datenschutz bewußt sein. Ausgeklügelte Lösungen in Sicherheitsfragen zu erarbeiten wuerde den Aufgabenrahmen der Working Group sprengen. Einige Organisationen behandeln diese Themen mit unterschiedlichen Sicherheits- und Präferenzlösungen. Siehe z.B. SAML und P3P.


3. Die Grundbausteine

Die meisten Elemente einer OWL Ontologie betreffen Klassen, Properties, Instanzen von Klassen und Beziehungen zwischen diesen Instanzen. Dieser Abschnitt präsentiert die Sprachkomponenten, die man zur Einführung dieser Elemente braucht.

3.1. Einfache Klassen und Individuals

Viele Anwendungszwecke einer Ontologie hängen von der Fähigkeit ab, Schlussfolgerungen über Individuals zu ziehen. Um das auf brauchbare Weise angehen zu können, benötigen wir einen Mechanismus um die Klassen, zu denen die Individuals gehören und die Properties, welche sie Kraft ihrer Mitgliedschaft in Klassen erben, beschreiben zu können. Man kann immer spezielle Eigenschaften für Individuals festlegen, aber ein großer Teil der Macht von Ontologien gründet auf Schlußfolgerungen, die anhand von Klassen gezogen werden können.

Manchmal wollen wir den Unterschied zwischen einer Klasse als ein Objekt und einer Klassen als eine Menge, die Elemente enthält, betonen. Wir nennen die Menge von Individuals, welche Mitglieder einer Klasse sind, die extension der Klasse.

3.1.1. Einfache benannte Klassen
Class, rdfs:subClassOf

Den grundlegensten Konzepten zu einer Domäne sollten Klassen gegenüberstehen, die die Basis verschiedener Taxonomiebäume bilden. Jede Individual in der OWL Welt ist ein Mitglied der Klasse owl:Thing. Damit ist jede benutzerdefinierte Klasse implizite Subklasse von owl:Thing. Bereichsspezifische Wurzelklassen werden einfach durch die Deklaration einer benannten Klasse definiert. OWL definiert ferner die leere Klasse, owl:Nothing.

Für unsere Beispieldomäne für Weinsorten machen wir uns drei Basisklassen: Winery, Region, und ConsumableThing.

<owl:Class rdf:ID="Winery"/>
<owl:Class rdf:ID="Region"/>
<owl:Class rdf:ID="ConsumableThing"/>

Man beachte, dass wir nur gesagt haben, dass es drei Klassen gibt, welchen diese Namen gegeben wurden, wie man an der 'rdf:ID=' Syntax erkennen kann. Formal wissen wir praktisch nichts über diese Klassen, außer dass es sie gibt; trotz der Verwendung von uns vertrauten englischen Begriffen als Bezeichner. Und obgleich diese Klassen existieren, haben sie keine Mitglieder. Nach Allem, was wir bisher wissen, hätte man sie ebensogut Ding1, Ding2 und Ding3 nennen könnnen.

Es ist wichtig, sich darüber im Klaren zu sein, dass Definitionen inkrementiell aufeinander aufbauen und verteilt sein können. Insbesondere werden wir über Winery später mehr zu sagen haben.

Die Syntax rdf:ID="Region" wird benutzt, um einen Namen als Teil der Klassendefinition einzuführen. Dies ist das rdf:ID Attribut ([RDF], 7.2.22), vergleichbar mit dem von XML her bekannten ID Attribut. Innerhalb dieses Dokuments kann die Klasse Region nun mittels der Bezeichnung #Region referenziert werden, etwa so: rdf:resource="#Region". Andere Ontologien mögen diesen Namen durch Verwendung seiner kompletten Form referenzieren: "http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlwine#Region".

Eine weitere Form der Referenz verwendet die Syntax rdf:about="#Region" um die Definition einer Resource zu erweitern. Diese Verwendung der rdf:about="&ont;#x" Syntax ist für die Erstellung einer verteilten Ontologie ein wichtiges Element. Sie erlaubt die Erweiterung der importierten Definition von x ohne das ursprüngliche Dokument zu modifizieren und unterstützt den inkrementellen Aufbau einer größeren Ontologie.

Nun ist es möglich, sich mit den passenden Identifiern auf die Klassen zu beziehen, die wir in anderen OWL Konstrukten definiert haben. Für die erste Klasse innerhalb dieses Dokuments können wir den relativen Bezeichner #Winery verwenden. Andere Dokumente werden sich ebenfalls auf diese Klasse beziehen wollen. Der vernünftigste Weg, dies anzugehen, ist die Bereitstellung von Namespace- und Entity-Definitionen, die das definierende Dokument als Quelle angeben:

...
<!ENTITY vin  "http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlwine#" >
<!ENTITY food "http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlfood#" >
...
<rdf:RDF xmlns:vin ="http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlwine#"
         xmlns:food="http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlfood#" ... >
...

Mit diesen Definitionen können wir uns auf die winery Klasse entweder per XML Tag vin:Winery oder mit dem Attributwert &vin;Winery beziehen. Es ist immer möglich, eine Ressource durch ihren vollen URI zu referenzieren, hier wäre das http://www.semaweb.org/dokumente/w3/TR/2004/REC-owl-guide-20040210-DE.htmlwine#Winery.

Der fundamentale taxonomische Konstruktor für Klassen ist rdfs:subClassOf. So wird eine speziellere Klasse auf eine allgemeinere Klasse bezogen. Ist X eine Unterklasse von Y, dann ist jede Instanz von X auch eine Instanz von Y. Die rdfs:subClassOf Beziehung ist transitiv. Ist X eine Unterklasse von Y und Y eine Unterklasse von Z, so ist X eine Unterklasse von Z.

<owl:Class rdf:ID="PotableLiquid">
  <rdfs:subClassOf rdf:resource="#ConsumableThing" />
  ...
</owl:Class>

Wir definieren PotableLiquid (Flüssigkeiten, die zum Trinken geeignet sind) als eine Unterklasse von ConsumableThing.

In der Welt webbasierter Ontologien können beide Klassen in getrennten Ontologien definiert werden, welche die Grundbausteine für eine Vielfalt von Ontologien zum Thema Essen und Trinken darstellen. So haben wir es gemacht, sie sind in der food Ontology definiert, welche wir in die wine Ontologie importiert haben. Die food Ontologie beinhaltet eine Handvoll Klassen, etwa Food, EdibleThing, MealCourse und Shellfish, welche nicht in die Sammlung der Angelegenheiten zum Thema Wein gehören aber mit dem wine Vokabular verbunden werden müssen, wenn wir nützliche Schlussfolgerungen ermöglichen wollen. Essen und Wein hängen in dem Sinne, dass sie nötig sind unser Bedürfnis, Wein/Speise Kombinationen zu identifizieren, zusammen.

Eine Klassendefinition hat zwei Teile: zunächst die Einführung eines Namens oder einer Referenz und dann eine Liste von Restriktionen. Jeder der in die Klassendefiniton aufgenommenen Ausdrücke beschränkt die Instanzen der definierten Klasse weiter. Instanzen der definierten Klasse gehören also zur Schnittmenge der Restriktionen. (Beachte aber die Details von owl:equivalentClass.) Bis hierher haben wir nur Beispiele gesehen, die einzelne Restriktionen umfassen, indem sie die neue Klasse als Unterklasse einer anderen benannten Klasse festlegen.

Jetzt wird es möglich, eine einfache (und unvollständige) Definition für die Klasse Wine zu bilden. Wine ist ein PotableLiquid. Wir definieren ferner Pasta als ein EdibleThing.

<owl:Class rdf:ID="Wine">
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/>
  <rdfs:label xml:lang="en">wine</rdfs:label>
  <rdfs:label xml:lang="fr">vin</rdfs:label>
  ...
</owl:Class>

<owl:Class rdf:ID="Pasta">
  <rdfs:subClassOf rdf:resource="#EdibleThing" />
  ...
</owl:Class>

Der Eintrag rdfs:label stellt einen optionalen für Menschen lesbaren Namen für die Klasse bereit; Darstellungswerkzeuge können dies verwenden. Das "lang" Attribut stellt Unterstützung für unterschiedliche Sprachen zur Verfügung. Ein Label ist wie ein Kommentar und trägt nichts zur logischen Interpretation einer Ontologie bei.

Unsere Definiton von Wein ist noch ziemlich unvollständig. Wir wissen nichts über Weine, außer dass sie Dinge und trinkbare Flüssigkeiten sind, aber unser Kenntnisstand reicht aus, um Individuals zu erzeugen und Schlüsse über sie zu ziehen.

3.1.2. Individuals

Neben den Klassen wollen wir auch ihre Mitglieder beschreiben. Wir stellen uns diese als Individuals in unserem Universum aus Dingen vor. Ein solches Individuum wird minimal dadurch eingeführt, dass man es als Mitglied einer Klasse deklariert.

<Region rdf:ID="CentralCoastRegion" />

Man beachte, dass das Folgende bedeutungsgleich zum obigen Beispiel ist:

<owl:Thing rdf:ID="CentralCoastRegion" />

<owl:Thing rdf:about="#CentralCoastRegion">
   <rdf:type rdf:resource="#Region"/>
</owl:Thing>

rdf:type ist eine RDF Property, welche ein Individuum einer Klasse zuordnet, deren Mitglied es dann ist.

An dieser Stelle muss man einige Dinge anmerken. Zunächst haben wir entschieden, dass CentralCoastRegion (eine bestimmte Gegend) Mitglied von Region ist, der Klasse, die alle geographischen Regionen enthält. Zweitens, es ist in dem zwei-teiligen Beispiel nicht erforderlich, dass die zwei Elemente nebeneinander oder auch nur in der selben Datei stehen müssten (allerdings müssten die Namen in so einem Fall um einen URI erweitert werden). Webontologien sind dafür gebaut, verteilt zu sein. Sie können importiert und erweitert werden; so kann man abgeleitete Ontologien erstellen.

Um noch ein paar weitere Klassen für die im nächsten Abschnitt einzuführenden Properties zur Hand zu haben, definieren wir einen Zweig der Grape Taxonomie, mit besonderer Kennzeichnung der Cabernet Sauvignon Rebsorte. Trauben werden in der food Ontologie definiert:

<owl:Class rdf:ID="Grape">
  ...
</owl:Class>

Und in der wine Ontologie haben wir:

<owl:Class rdf:ID="WineGrape">
  <rdfs:subClassOf rdf:resource="&food;Grape" />
</owl:Class>

<WineGrape rdf:ID="CabernetSauvignonGrape" />

Wie im nächsten Abschnitt näher erläutert wird, ist CabernetSauvignonGrape ein Individual, weil es eine einzelne Rebsorte bezeichnet.

3.1.3. Anwendungsorientierte Gestaltung

Einige wichtige Aspekte sind hinsichtlich dem Unterschied zwischen einer Klasse und einem Individual in OWL zu erläutern. Eine Klasse ist einfach ein Name und eine Sammlung von Eigenschaften, die eine Menge von Individuals beschreibt. Individuals sind die Mitglieder dieser Mengen. Daher sollten Klassen den in freier Wildbahn auftretenden Mengen von Dingen in der Domäne unseres Interesses entsprechen, während Individuals den tatsächlichen Entitäten entsprechen sollten, welche in diese Klassen gruppiert werden können.

Bei der Erstellung von Ontologien ist diese Unterscheidung oft auf eine der folgenden zwei Arten verschwommen:

Man beachte, dass die selbe Unterscheidung bei der Behandlung der Wine Klasse auftritt. Die Wine Klasse beschreibt die Menge aller Sorten von Wein, nicht die Menge aller tatsächlichen Flaschen, die jemand erwerben mag. In einer anderen Ontologie könnte jede Instanz von Wine aus der gegenwärtigen Ontologie stattdessen eine Klasse sein, deren Mitglieder alle Flaschen Wein jener Sorte sind. Es ist leicht, sich ein Informationssystem, etwa ein Inventarsystem für einen Weinhändler, vorzustellen, das einzelne Flaschen Wein beachten muss. Die Weinontologie in ihrer jetztigen Form bräuchte die Möglichkeit, Klassen als Instanzen aufzufassen, um solch eine Interpretation zu unterstützen. Man beachte, dass OWL Full solche Ausdrucksvielfalt erlaubt und uns so ermöglicht, eine Weinsorte gleichzeitig als eine Instanz einer Klasse von Weinsorten und als eine eigene Klasse, deren Instanzen Weinflaschen sind, zu behandeln.

Ein ähnlicher Sachverhalt: Die von Weingütern in besonderen Jahren hergestellten Weine werden als Jahrgänge betrachtet. Um den Begriff Jahrgang darzustellen, müssen wir bestimmen, wo in der gegenwärtigen Ontologie er hineinpasst. Eine Instanz der Wine Klasse repräsentiert, wie oben erläutert, eine einzelne Weinsorte, hergestellt von einem bestimmten Weingut, z.B. FormanChardonnay.

Wenn man hinzufügen möchte, dass der im Jahr 2000 produzierte Wein als Jahrgang betrachtet wird, steht man vor einem Problem, denn wir haben nicht die Möglichkeit, eine Teilmenge einer gegebenen Weininstanz darzustellen. Dieser Jahrgang ist keine neue Weinsorte sondern eine besondere Teilmenge dieses Weins, nämlich derjenige aus dem Jahr 2000. Eine Möglichkeit wäre die Verwendung von OWL Full um die Weininstanzen als Klassen mit Unterklassen (Teilmengen) für Jahrgänge zu behandeln. Ein weiterer Weg wäre die Verwendung eines Workarounds, bei dem man Vintage als eine separate Klasse betrachtet, deren Instanzen eine Beziehung zu dem Wein haben, von dem sie ein Jahrgang sind. Zum Beispiel ist FormanChardonnay2000 ein Individual der Klasse Vintage mit einer vintageOf Property, deren Wert der Wine ist, nämlich FormanChardonnay. Wir definieren die Vintage Klasse weiter unten.

Diese Diskussion zielt darauf ab, zu verdeutlichen, dass die Entwicklung einer Ontologie in erster Linie von der beabsichtigten Verwendung getrieben werden sollte. Bei diesen Dingen ist im übrigen ein wichtiger Unterschied zwischen OWL Full und OWL DL zu berücksichtigen: OWL Full erlaubt die Verwendung von Klassen als Instanzen, OWL DL jedoch nicht. Die Weinontologie ist im Hinblick auf OWL DL entworfen worden, daher werden Individuals wie FormanChardonnay nicht gleichzeitig als Klassen behandelt.

3.2. Einfache Properties

Diese Welt der Klassen und Individuals wäre reichlich uninteressant, wenn man nur Taxonomien definieren könnte. Properties lassen es zu, allgemeingültige Fakten über Klassenmitglieder und spezifische Fakten über Individuals anzuführen.

3.2.1. Properties definieren
ObjectProperty, DatatypeProperty, rdfs:subPropertyOf,
rdfs:domain, rdfs:range

Eine Property stellt eine binäre Relation dar. Man unterscheidet zwischen 2 Arten von Properties:

Bei der Definition einer Property gibt es mehrere Wege die Relation einzuschränken. Die Domain (Grundmenge) und Range (Wertebereich) können angegeben werden. Die Property kann als eine Spezialisierung (subproperty) einer bereits exisitierenden Property definiert werden. Noch weitere, ausgeklügeltere Einschränkungen sind möglich, werden jedoch erst später besprochen.

<owl:ObjectProperty rdf:ID="madeFromGrape">
  <rdfs:domain rdf:resource="#Wine"/>
  <rdfs:range rdf:resource="#WineGrape"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="course">
  <rdfs:domain rdf:resource="#Meal" />
  <rdfs:range rdf:resource="#MealCourse" />
</owl:ObjectProperty>

In OWL repräsentiert eine Sequenz von Elementen ohne einen expliziten Operator eine implizite Konjunktion Die Property madeFromGrape hat eine Domain namens Wine und eine range namens WineGrape. Dies bedeutet, dass sie Instanzen der Klasse Wine mit Instanzen der Klasse WineGrapes in Beziehung bringt. Mehrere Domains bedeuten, dass die Domain einer Property, die Schnittmenge der angegebenen Klassen darstellt (selbiges gilt ebenso für Range).

Dies gilt auch für die Property course, welche Meal mit MealCourse verbindet.

Man beachte, dass der Gebrauch von Range- und Domaininformation in OWL sich von Typeninformation in herkömmlichen Programmiersprachen unterscheidet. Nebst anderen Dingen werden Typen in Programmiersprachen zur Konsistenzprüfung herangezogen. In OWL könnte eine Rangeangabe herangezogen werden, um einen Typ abzuleiten, wie z.B.:

<owl:Thing rdf:ID="LindemansBin65Chardonnay">
  <madeFromGrape rdf:resource="#ChardonnayGrape" />
</owl:Thing>                                              ¬ 

Wir können nun ableiten, dass LindemansBin65Chardonnay ein Wein ist, da die Domain von madeFromGrape Wine ist.

Properties können wie Klassen in einer Hierarchie angeordnet werden.

<owl:Class rdf:ID="WineDescriptor" />

<owl:Class rdf:ID="WineColor">
  <rdfs:subClassOf rdf:resource="#WineDescriptor" />
  ...
</owl:Class>

<owl:ObjectProperty rdf:ID="hasWineDescriptor">
  <rdfs:domain rdf:resource="#Wine" />
  <rdfs:range  rdf:resource="#WineDescriptor" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="hasColor">
  <rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" />
  <rdfs:range rdf:resource="#WineColor" />
  ...
</owl:ObjectProperty>

WineDescriptor Properties verbinden Weine mit ihrer Farbe und ihren Geschmackskomponenten, wie Süssigkeit, Körper und Geschmack. hasColor ist eine subproperty der hasWineDescriptor-Property, welche die Range zusätzlich auf WineColor begrenzt. Die rdfs:subPropertyOf-Beziehung bedeutet hier, dass alles mit einer hasColor-Property mit dem Wert X, ebenfalls eine hasWineDescriptor-Property mit dem Wert X besitzt.

Nun bringen wir die locatedIn-Property ein, welche Dinge mit Regionen, aus denen sie stammen, in Verbindung bringt.

<owl:ObjectProperty rdf:ID="locatedIn">
  ...
  <rdfs:domain rdf:resource="http://www.w3.org/2002/07/owl#Thing" />
  <rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>

Man beachte wie Domain und Range von locatedIn definert sind. Die Domain erlaubt allen Dingen in einer Region zu liegen, inklusive der Regionen selbst. Die transitive Ausprägung dieser Relation baut hauptsächlich ein Netzwerk der geographisch darin liegenden Subregionen und Dingen auf. Dinge, in denen sich nichts befindet, können von jeder Klasse sein, wohingegen Dinge, welche noch andere enthalten, Regionen sein müssen.

Nun ist es möglich die Definition von Wine dahingehend auszuweiten, dass ein Wein letztendlich aus einer WineGrape gemacht wird. Ebenso wie Property-Definitionen, bestehen Klassen-Definitionen aus mehereren Unterteilen welche implizit miteinander verbunden sind.

<owl:Class rdf:ID="Wine">
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#madeFromGrape"/>
      <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
    </owl:Restriction> 
  </rdfs:subClassOf>
  ...
</owl:Class>

Die hervorgehobene subclass-Einschränkung oben

    <owl:Restriction>
      <owl:onProperty rdf:resource="#madeFromGrape"/>
      <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
    </owl:Restriction>

definiert eine unbenannte Klasse, welche eine Menge von Dingen mit mindestens einer madeFromGrape-Property darstellt. Wir nennen dies anonyme Klassen. Wird diese Einschränkung in die Wine-Klassendefinition eingebracht, so sagt dies aus, dass Dinge, die Weine sind ebenso Mitglieder dieser anonymen Klasse sind. Das bedeutet, jedes Individual vom Typ Wein muß ebenfalls eine madeFromGrape-Relation aufweisen.

Wir können nun die Klasse Vintage beschreiben, welche schon oben besprochen wurde.

<owl:Class rdf:ID="Vintage">
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#vintageOf"/>
      <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>                                              ¬ 

Die Property vintageOf verbindet eine Vintage mit einem Wine.

<owl:ObjectProperty rdf:ID="vintageOf">
  <rdfs:domain rdf:resource="#Vintage" />
  <rdfs:range  rdf:resource="#Wine" />
</owl:ObjectProperty>                                     ¬ 

Wir setzen Vintages (Jahrgänge) im nächsten Abschnitt mit dem zugehörigen Jahr in Beziehung.

3.2.2. Properties und Datentypen

Wir unterscheiden Properties danach, ob sie entweder Individuals mit Individuals verbinden (Object Properties) oder Individuals mit Datentypen (Datatype Properties). Datatype-Properties können RDF-Literale darstellen oder auch simple Datentypen, gemäß den XML-Schema Datentypen Vereinbarungen.

OWL unterstützt die meisten der in XML-Schema enthaltenen Datentypen. Verweise auf diese Datentypen werden durch die URI-Referenz http://www.w3.org/2001/XMLSchema für den Datentyp gebildet. Die folgenden Datentypen sind für den Gebrauch von OWL empfohlen:

xsd:stringxsd:normalizedStringxsd:boolean
xsd:decimalxsd:floatxsd:double
xsd:integerxsd:nonNegativeIntegerxsd:positiveInteger
xsd:nonPositiveIntegerxsd:negativeInteger
xsd:longxsd:intxsd:shortxsd:byte
xsd:unsignedLongxsd:unsignedIntxsd:unsignedShortxsd:unsignedByte
xsd:hexBinaryxsd:base64Binary
xsd:dateTimexsd:timexsd:datexsd:gYearMonth
xsd:gYearxsd:gMonthDayxsd:gDayxsd:gMonth
xsd:anyURIxsd:tokenxsd:language
xsd:NMTOKENxsd:Namexsd:NCName

Obige Datentypen, plus rdfs:Literal bilden die enthaltenen OWL-Datentypen. Alle OWL-Reasoner müssen xsd:integer und xsd:string-Datentypen unterstützten.

Andere in XML-Schema enthaltenen Datentypen können in OWL Full angewendet werden, jedoch unter Vorbehalt, wie in der OWL Semantics and Abstract Syntax Dokumentation beschrieben ist.

<owl:Class rdf:ID="VintageYear" />

<owl:DatatypeProperty rdf:ID="yearValue">
  <rdfs:domain rdf:resource="#VintageYear" />
  <rdfs:range  rdf:resource="&xsd;positiveInteger"/>
</owl:DatatypeProperty>

Die yearValue-Property verbindet VintageYears mit positiven Integer-Werten. Wir führen nun die hasVintageYear-Property ein, welche Vintage mit unten stehendem VintageYear in Beziehung bringt.

Die OWL Reference ([Reference], 6.2) beschreibt den Gebrauch von owl:oneOf und rdf:List sowie rdf:rest um einen enumerated-Datentyp zu definieren. Das Beispiel zeigt auf, wie die owl:DatatypeProperty, tennisGameScore konstruiert wird, mit einer Range die den Elementen einer Liste von Integer-Werten {0, 15, 30, 40} entspricht.

3.2.3. Properties von Individuals

Zuerst beschreiben wir Region und Winery-Individuals, danach definieren wir unseren ersten Wein, einen Cabernet Sauvignon.

<Region rdf:ID="SantaCruzMountainsRegion">
  <locatedIn rdf:resource="#CaliforniaRegion" />
</Region>

<Winery rdf:ID="SantaCruzMountainVineyard" />

<CabernetSauvignon
  rdf:ID="SantaCruzMountainVineyardCabernetSauvignon" >
  <locatedIn   rdf:resource="#SantaCruzMountainsRegion"/>
  <hasMaker    rdf:resource="#SantaCruzMountainVineyard" />
</CabernetSauvignon>

Dies ist immer noch nicht komplett. Es gibt noch andere Aspekte des Weingeschmacks, welche in der vollständigen Ontolgie definiert sind. Jedoch fügen sich die Teile zusammen. Wir könnten nun beginnen zu folgern, welche Menue-Gänge dieser Wein begleiten könnte. Wir wissen aufgrund obiger Definition, dass das Santa Cruz Mountain-Weingut ihn herstellt. Da es ein Cabernet Sauvignon (siehe wine.rdf) ist, wissen wir, dass es ein trockener Rotwein ist.

Datatype Properties können den Individuals auf ähnliche Weise hinzugefügt werden. Unten beschreiben wir eine Instanz von VintageYear und verbinden sie mit einem spezifischen Wert vom Typ &xsd:positiveInteger.

<VintageYear rdf:ID="Year1998">
  <yearValue rdf:datatype="&xsd;positiveInteger">1998</yearValue>
</VintageYear>

3.3. Property Characteristica

Die nächsten Abschnitte beschreiben einen Mechanismus, welcher gebraucht wird um Properties noch weiter zu spezifizieren. Es ist möglich Property Characteristica zu spezifizieren, welche einen mächtigen Mechanismus für erweitertes Folgern aus einer Property bereitstellt.

3.3.1. TransitiveProperty

Wenn eine Property P als transitiv spezifiziert ist dann gilt für alle x, y, und z:

P(x,y) and P(y,z) implies P(x,z)

Die Property locatedIn ist transitiv.

<owl:ObjectProperty rdf:ID="locatedIn">
  <rdf:type rdf:resource="&owl;TransitiveProperty" />
  <rdfs:domain rdf:resource="&owl;Thing" />
  <rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>

<Region rdf:ID="SantaCruzMountainsRegion">
  <locatedIn rdf:resource="#CaliforniaRegion" />
</Region>

<Region rdf:ID="CaliforniaRegion">
  <locatedIn rdf:resource="#USRegion" />
</Region>

Da die SantaCruzMountainsRegion locatedIn in der CaliforniaRegion ist , muß sie ebenso locatedIn in der USRegion sein, da ja locatedIn transitiv ist.

3.3.2. SymmetricProperty

Wenn eine Property P als symmetrisch markiert ist, dann gilt für alle x und y:

P(x,y) iff P(y,x)

Die Property adjacentRegion ist symmetrisch, wohingegen locatedIn dies nicht ist. Genauer gesagt ist dies bei locatedIn nicht beabsichtigt. Nichts in der momentanen Wein-Ontologie untersagt, dass sie symmetrisch ist.

<owl:ObjectProperty rdf:ID="adjacentRegion">
  <rdf:type rdf:resource="&owl;SymmetricProperty" />
  <rdfs:domain rdf:resource="#Region" />
  <rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>

<Region rdf:ID="MendocinoRegion">
  <locatedIn rdf:resource="#CaliforniaRegion" />
  <adjacentRegion rdf:resource="#SonomaRegion" />
</Region>

Die MendocinoRegion ist der SonomaRegion benachbart und umgekehrt. Die MendocinoRegion liegt in der CaliforniaRegion, jedoch nicht umgekehrt.

3.3.3. FunctionalProperty

Wenn eine Property, P, als functional markiert ist, dann gilt für alle x, y, und z:

P(x,y) and P(x,z) implie y = z

In unserer Wein-Ontologie ist hasVintageYear functional. Ein Wein hat ein einziges Lesejahr. Daher kann ein gegebenes Individual Vintage durch den Gebrauch der hasVintageYear-Property nur mit einem einzigen Jahr in Verbindung gebracht werden, Es ist keine Forderung einer owl:FunctionalProperty, dass alle Elemente der Domain einen Wert besitzen. Siehe hierzu die Diskussion von Vintage cardinality.

<owl:Class rdf:ID="VintageYear" />

<owl:ObjectProperty rdf:ID="hasVintageYear">
  <rdf:type rdf:resource="&owl;FunctionalProperty" />
  <rdfs:domain rdf:resource="#Vintage" />
  <rdfs:range  rdf:resource="#VintageYear" />
</owl:ObjectProperty>

3.3.4. inverseOf

Wenn eine Property P1 als owl:inverseOf P2 markiert ist, dann gilt für alle x und y:

P1(x,y) iff P2(y,x)

Man beachte dass die Syntax für owl:inverseOf einen Propertynamen als Argument verlangt. A iff B bedeutet (A implies B) und (B implies A).

<owl:ObjectProperty rdf:ID="hasMaker">
  <rdf:type rdf:resource="&owl;FunctionalProperty" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="producesWine">
  <owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty>

Wines haben Erzeuger, welche laut der Definition von Wine auf Winerys begrenzt sind. Daher produziert jede Winery eine Menge von Weinen, welche sie als Erzeuger markieren.

3.3.5. InverseFunctionalProperty

Wenn eine Property P als InverseFunctional markiert ist, dann gilt für alle x,y und z:

P(y,x) and P(z,x) implies y = z

Man beachte, dass producesWine in vorhergehendem Abschnitt als inverse functional deklariert wurde. Der Grund liegt darin, dass inverse functional das Gegenteil einer functional property sein muss. Wir hätten hasMaker und producesWine wie folgt definieren können und hätten hierdurch denselben Effekt wie im vorhergehendem Beispiel erreicht.

<owl:ObjectProperty rdf:ID="hasMaker" />

<owl:ObjectProperty rdf:ID="producesWine">
  <rdf:type rdf:resource="&owl;InverseFunctionalProperty" />
  <owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty>                                     ¬ 

Betrachte die Elemente einer Range in einer inversefunctional-Property, wie das Definieren eines Unique-Key in einer Datenbank. owl:InverseFunctional impliziert, dass die Elemente der Range einen einzigartigen Identifier für ein jedes Element der Domain zur Verfügung stellen.

In OWL Full, können wir DatatypeProperty als inverseFunctional markieren. Dies ermöglicht uns einen String als Unique-Key zu identifizieren. In OWL DL sind Literale von owl:Thing getrennt, da OWL DL es nicht erlaubt InverseFunctional auf DatatypeProperty anzuwenden.

3.4. Property Restrictions

Nebst der Kennzeichnung von Property Characteristics, ist es möglich die Range einer Property in spezifischen Kontexten auf verschiedenerlei Art und Weise weiter einzuschränken. Wir machen dies mit property restrictions. Die unterschiedlichen Formen, welche unten beschrieben sind können nur im Kontext einer owl:Restriction angewandt werden. Das owl:onProperty Element gibt die eingeschränkte Property an.

3.4.1. allValuesFrom, someValuesFrom

Wir haben bereits einen Weg gesehen, um die Typen der Elemente einzuschränken, die eine Property ausmachen. Die bisherigen Mechanismen waren global, in der Weise, dass sie auf alle Instanzen einer Property angewandt werden. Die nächsten zwei, allValuesFrom und someValuesFrom, beziehen sich lokal auf die Klassen-Definition, die sie enthält.

Die owl:allValuesFrom Einschränkung verlangt, dass für jede Instanz der Klasse, welche Instanzen der spezifizierten Property hat die Property-Werte alle Mitglieder der Klasse sind, welche im owl:allValuesFrom Abschnitt angegeben ist.

<owl:Class rdf:ID="Wine">
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
  ...
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasMaker" />
      <owl:allValuesFrom rdf:resource="#Winery" />
    </owl:Restriction>
  </rdfs:subClassOf>
  ...
</owl:Class>

Der Hersteller von Wine muss eine Winery sein. Die allValuesFrom Einschränkung bezieht sich auf die hasMaker-Property nur dieser Wine-Klasse . Hersteller von Käse sind nicht von dieser lokalen Einschränkung betroffen.

owl:someValuesFrom ist ähnlich. Wenn wir owl:allValuesFrom durch owl:someValuesFrom in obigem Beispiel ersetzen, würde dies bedeuten, dass mindestens eine der hasMaker-Properties eines Wine, auf ein Individual verweisen muß, welches eine Winery ist.

<owl:Class rdf:ID="Wine">
  <rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasMaker" />
      <owl:someValuesFrom rdf:resource="#Winery" />
    </owl:Restriction>
  </rdfs:subClassOf>
  ...
</owl:Class>                                             ¬ 

Der Unterschied zwischen diesen beiden Formulierungen besteht im Unterschied zwischen einer universellen und einer existenziellen Quantifizierung.

RelationImplikation
allValuesFromFür alle Weine, die einen Hersteller haben, ist dieser Hersteller ein Weingut
someValuesFromFür alle Weine, die mindestens einen Hersteller haben, der ein Weingut ist

Ersteres verlangt von einem Wein nicht, dass er einen Hersteller hat. Wenn er einen oder mehrere hat, müssen alle Weingüter sein. Zweiteres verlangt, dass es mindestens einen Hersteller geben muss, welcher ein Weingut ist, aber es könnte auch Hersteller geben, welche nicht Winzereien sind.

3.4.2. Cardinality

Wir haben bereits Beispiele von Kardinalitätseinschränkungen gesehen. Bis jetzt waren es Ansprüche einer minimale Kardinalität. Ein wenig mehr einschränkend ist owl:cardinality, welche eine exakte Spezifizierung der Elementenanzahl in einer Relation ermöglicht. Zum Beispiel spezifizieren wir Vintage als eine Klasse mit genau genau einem VintageYear.

<owl:Class rdf:ID="Vintage">
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasVintageYear"/>
      <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

Wir spezifizieren hasVintageYear als functionalProperty, was dasselbe ist, wie wenn man sagen würde, dass jede Weinlese nur eine Lesejahr hat. Diese Anwendung der Property auf Vintage, wobei eine Kardinalitäts- Restriktion benutzt wird, macht etwas strenger geltend, dass jede Vintage genau ein VintageYear hat.

Die Werte von Kardinalitäts-Ausdrücken sind in OWL Lite auf 0 und 1 limitiert. Dies ermöglicht dem Benutzer 'mindestens eins', 'nicht mehr als eins', und 'genau eins' anzugeben Positive Integer-Werte, welche nicht 0 und 1 entsprechen sind in OWL DL erlaubt. owl:maxCardinality kann benutzt werden eine obere Abgrenzung zu spezifizeren. owl:minCardinality kann benutzt werden eine untere Abgrenzung zu spezifizeren. Eine Kombination kann dazu benutzt werden eine Property-Kardinalität auf ein numerisches Intervall zu beschränken.

3.4.3. hasValue [OWL DL]

hasValue erlaubt uns Klassen zu spezifizieren, welche auf der Existenz eines bestimmten Property-Wertes basieren. Deshalb ist ein Individual immer dann Mitglied einer solchen Klasse, wann immer letztlich einer dieser Property-Werte der hasValue-Resource entspricht.

<owl:Class rdf:ID="Burgundy">
  ...
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasSugar" />
      <owl:hasValue rdf:resource="#Dry" />
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

Hier deklarieren wir, dass alle Burgundy-Weine trocken sind. Begründet dadurch, dass ihre hasSugar-Property letztendlich einen Wert besitzen muß, welcher Dry entspricht

In Bezug auf allValuesFrom und someValuesFrom stellt es eine lokale Einschränkung dar. Es macht hasSugar angewandt auf Burgundy geltend.

4. Mapping von Ontologien

Damit Ontologien maximale Wirkung entfalten, müssen sie weit verbreitet sein. Um den intellektuellen Aufwand bei der Entwicklung von Ontologien zu minimieren, müssen sie wiederverwendet werden. In der besten aller möglichen Welten, müssen sie zusammengesetzt werden. Beispielsweise könnte man eine Datumsontologie aus einer Quelle einsetzen und eine physikalische Ortsontologie von einer anderen einsetzen, um daraufhin der Ortsangabe die Zeitperiode, in welcher sie gilt, hinzuzufügen.

Es ist wichtig zu verstehen, dass ein großer Teil der Mühe der Ontologieentwicklung im Zusammenführen von Klassen und Properties aufgebracht wird und zwar auf eine Weise, welche die logischen Schlussfolgerungen maximiert. Wir wollen simple Aussagen über die Mitgliedschaft in einer Klasse, um möglichst umfassende und nützliche Schlußfolgerungen ziehen zu können. Dies ist der härteste Teil der Ontologieentwicklung. Wenn es möglich ist sollte man eine bereits existierende Ontologie einsetzen, die schon extensiver Benutzung und Verfeinerung unterzogen wurde.

Eine Menge von Ontologien zusammenzuführen, wird eine Herausforderung sein. Es wird sicherlich auch die Unterstützung von Tools benötigt, um die Konsistenz zu gewährleisten.

4.1. Äquivalenz zwischen Klassen und Properties
equivalentClass, equivalentProperty

Um eine Menge von Teilontologien zu verbinden und als Teil zu einer Dritten hinzuzufügen, sollte man imstande sein, zu kennzeichnen, dass eine bestimmte Klasse oder Property einer Ontologie der Klasse oder Property einer zweiten Ontologie entspricht. Diese Möglichkeit sollte jedoch mit Vorsicht angewandt werden. Sollten die kombinierten Ontologien sich wiedersprechen (alle A's sind B's vs. alle A's sind keine B's) so wird es zu keiner Erweiterung kommen (keine Individuals und Relationen), welche die entstandene Kombination erfüllt.

In der Essensontologie wollen wir Weinmerkmale aus den Beschreibungen von Menügängen zurück zur Weinontologie verlinken. Ein Weg dies zu bewerkstelligen, ist eine Klasse in der Essensontologie zu definieren, um sie daraufhin als äquivalent zu einer bereits bestehenden Wein-Klasse in der Wein-Ontologie zu deklarieren.

<owl:Class rdf:ID="Wine">
  <owl:equivalentClass rdf:resource="&vin;Wine"/>
</owl:Class>

Die Property owl:equivalentClass wird gebraucht um anzugeben, dass zwei Klassen exakt dieselben Instanzen besitzen. Man beachte, dass in OWL DL Klassen nur eine Menge von Individuals bedeuten und nicht selbst Individuals darstellen. In OWL Full, können wir nichtsdestotrotz owl:sameAs zwischen zwei Klassen benutzen, um anzugeben, dass sie in jeder Hinsicht identisch sind.

Natürlich ist obiges Beispiel etwas konstruiert, weil wir, wann immer wir &vin;Wine benutzen würden, auch #Wine benutzen könnten und damit denselben Effekt erzielen würden. Ein wahrscheinlicherer Anwendungsfall würde sich ergeben, wenn wir zwei unabhängig voneinander entwickelte Ontolgien benötigen und festellen, dass sie die URI's O1:foo und O2:bar anwenden, um auf dieselbe Klasse zu referenzieren. owl:equivalentClass könnte benutzt werden, um Beide zusammen zu legen, so dass die Ableitungen aus beiden Ontologien kombiniert sind.

Wir haben bereits gesehen, dass Klassenausdrücke Ziele der rdfs:subClassOf-Konstruktoren sein können. Sie können auch Ziel von rdfs:subClassOf sein. Des Weiteren macht es dies unnötig, Namen für jeden Klassenausdruck zu erfinden und es stellt ein mächtiges Definitionspotential, basierend auf der Erfüllung einer Property, dar.

<owl:Class rdf:ID="TexasThings">
  <owl:equivalentClass>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#locatedIn" />
      <owl:someValuesFrom rdf:resource="#TexasRegion" />
    </owl:Restriction>
  </owl:equivalentClass>
</owl:Class>                                                ¬ 

TexasThings sind exakt die Dinge, welche sich in der Texas-Region befinden. Der Unterschied zwischen dem Gebrauch von owl:equivalentClass hier und den Gebrauch von rdfs:subClassOf ist der Unterschied zwischen einer notwendigen Bedingung und einer notwendigen und hinreichenden Bedingung. Mit rdfs:subClassOf sind Dinge, welche sich in Texas befinden, nicht notwendigerweise TexasThings. Der Gebrauch von owl:equivalentClass sagt jedoch aus, dass etwas, was sich in Texas befindet, auch der Klasse TexasThings zugehörig sein muß.

RelationImplikationen
subClassOfTexasThings(x) impliziert locatedIn(x,y) und TexasRegion(y)
equivalentClassÂÂTexasThings(x) impliziert locatedIn(x,y) und TexasRegion(y)
locatedIn(x,y) und TexasRegion(y) impliziert TexasThings(x)

Um Properties auf ähnliche Weise zusammenzuführen gebrauchen wir owl:equivalentProperty.

4.2. Identität zwischen Individuals
sameAs

Dieser Mechanismus ähnelt denen der Klassen, jedoch deklariert er zwei Individuals als äquivalent. Ein Beispiel wäre:

<Wine rdf:ID="MikesFavoriteWine">
  <owl:sameAs rdf:resource="#StGenevieveTexasWhite" />
</Wine>                                                  ¬ 

Dieses Beispiel hat keinen großen Nutzen. Alles was wir daraus lernen ist, dass Mike billigen Wein mag. Ein typischerer Gebrauch von sameAs wäre, Individuals, welche in unterschiedlichen Dokumenten definiert wurden, gleichzusetzen, als Teil der Vereinigung zweier Ontologien.

Dies bringt uns zu einem wichtigen Punkt. In OWL gibt es nicht die Prämisse einzigartiger Namen . Nur weil zwei Namen sich unterscheiden, heisst das noch nicht, dass sie auf unterschiedliche Individuals verweisen.

In obigen Beispiel gaben wir eine Identität zwischen zwei unterschiedlichen Namen an. Aber es ist genauso möglich, dies für diese Art von Identität abzuleiten. Man erinnere sich an die Folgerungen, welche von einer functionalProperty abgeleitet werden können. Angenommen hasMaker ist functional, so ergibt sich aus folgendem notwendigerweise ein Konflikt.

<owl:Thing rdf:about="#BancroftChardonnay">
  <hasMaker rdf:resource="#Bancroft" />
  <hasMaker rdf:resource="#Beringer" />
</owl:Thing>                                             ¬ 

Solange dies anderen Informationen in unserer Ontologie widerspricht, bedeutet es einfach, Bancroft = Beringer.

Man beachte, dass sameAs zur Gleichstellung zweier Klassen nicht dasselbe ist, wie sie mit equivalentClass gleichzusetzen; stattdessen verursacht es, die beiden Klassen als Individuals zu interpretieren und genügt deshalb, um eine Ontologie als OWL Full zu kategorisieren. In OWL Full könnte sameAs herangezogen werden, um alles gleichzusetzen: eine Klasse und ein Individual, eine Property und eine Klasse, etc., und hat zur Folge, dass beide Argumente als Individuals interpretiert werden.

4.3. Unterschiedliche Individuals
differentFrom, AllDifferent

Dieser Mechanismus stellt das Gegenteil von sameAs zur Verfügung.

<WineSugar rdf:ID="Dry" />

<WineSugar rdf:ID="Sweet">
  <owl:differentFrom rdf:resource="#Dry"/>
</WineSugar>

<WineSugar rdf:ID="OffDry">
  <owl:differentFrom rdf:resource="#Dry"/>
  <owl:differentFrom rdf:resource="#Sweet"/>
</WineSugar>

Dies ist einer der Wege auszusagen, dass diese drei Werte voneinander verschieden sind. Es gibt Fälle, wo es wichtig ist, solche verschiedenen Identitäten zu garantieren. Ohne diese Zuweisungen könnten wir einen Wein beschreiben, der beides ist, sowohl Dry (Trocken), als auch Sweet (Lieblich). Wir haben ausgesagt, dass die Property hasSugar, wenn sie auf einen Wein angewendet wird, nie mehr als einen Wert hat. Wenn wir uns irren würden und zugewiesen hätten, dass ein Wein gleichzeitig Dry und Sweet sein würde, ohne die differentFrom-Elemente von oben, würde dies implizieren, dass Dry und Sweet identisch sind. Mit den obigen Elementen, würden wir hingegen einen Widerspruch erhalten.

Es existiert ein bequemerer Mechanismus, um eine Menge von wechselseitig verschiedenen Individuals zu definieren. Das folgende sagt aus, dass Red, White and Rose paarweise verschieden sind.

<owl:AllDifferent>
  <owl:distinctMembers rdf:parseType="Collection">
    <vin:WineColor rdf:about="#Red" />
    <vin:WineColor rdf:about="#White" />
    <vin:WineColor rdf:about="#Rose" />
  </owl:distinctMembers>
</owl:AllDifferent>

Zu beachten ist, dass owl:distinctMembers nur in Kombination mit owl:AllDifferent benutzt werden kann.

In der Weinontologie gibt es eine owl:AllDifferent-Aussage für alle WineDescriptors. Wir sagen auch aus, dass die WineryS alle verschieden sind. Wenn wir ein neues Weingut in einer anderen Ontologie hinzufügen wollten und zuweisen möchten, dass es von allen, die bisher definiert wurden, verschieden ist, müssten wir die ursprüngliche owl:AllDifferent-Zuweisung ausschneiden, den neuen Erzeuger zur Liste hinzufügen und sie wieder einfügen. Es gibt keinen einfacheren Weg um eine owl:AllDifferent-Aufzählung in OWL DL zu erweitern. In OWL Full sind durch die Benutzung von RDF-Tripeln und rdf:List andere Ansätze möglich.


5. Komplexe Klassen [OWL DL]

OWL bietet weitere Konstruktoren, mit Hilfe derer Klassen erzeugt werden können. Diese Konstruktoren kann man verwenden, um sogenannte Klassenausdrücke zu erstellen. OWL unterstützt die grundlegenden Mengenoperationen, namentlich union (Vereinigung), intersection (Schnittmenge) und complement (Komplementärmenge). Sie heissen owl:unionOf, owl:intersectionOf und owl:complementOf. Außerdem können Klassen aufgezählt werden. Erweiterungen von Klassen können explizit ausgesagt werden durch den oneOf-Konstruktor. Und es ist möglich zuzuweisen, dass Klassenerweiterungen verschieden voneinander sein müssen.

Zu beachten ist, dass Klassenausdrücke eingefügt werden können, ohne dass für jede Klasse ein Name erzeugt werden muss. Dies erlaubt die Benutzung von set operations, um komplexe Klassen aus anonymen Klassen oder Klassen mit Wertbeschränkungen zu erzeugen.

5.1. Mengenoperatoren
intersectionOf, unionOf, complementOf

Erinnern wir uns daran, dass Klassenerweiterungen in OWL Mengen sind, die aus den Indiviuals bestehen, die Mitglieder der Klasse sind. OWL stellt Mittel zur Verfügung, um Klassenerweiterungen zu manipulieren, indem man grundlegende Mengenoperationen verwendet.

5.1.1. Schnittmenge [some uses of OWL DL]

Die folgenden Beispiele zeigen die Verwendung von intersectionOf.

<owl:Class rdf:ID="WhiteWine">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Wine" />
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasColor" />
      <owl:hasValue rdf:resource="#White" />
    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>

Klassen, die durch Mengenoperationen erzeugt wurden, sind eher als Definitionen anzusehen, als das was wir bisher gesehen haben. Die Mitglieder der Klasse sind ausschließlich durch die Mengenoperation spezifiziert. Die obige Konstruktion sagt aus, dass WhiteWine genau die Schnittmenge der Klasse Wine und der Menge der Dinge, die weiße Farbe haben, darstellt. Das heißt, dass wenn etwas weiß ist und ein Wein, ist es eine Instanz von WhiteWine. Ohne eine solche Definition würden wir wissen, dass Weißweine Weine sind und weiß, aber nicht umgekehrt. Dies ist ein wichtiges Werkzeug, um Individuals zu kategorisieren. (Beachte, dass 'rdf:parseType="Collection"' ein syntaktisch notwendiges Element ist.)

<owl:Class rdf:about="#Burgundy">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Wine" />
    <owl:Restriction>
      <owl:onProperty rdf:resource="#locatedIn" />
      <owl:hasValue rdf:resource="#BourgogneRegion" />
    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>

Hier definieren wir Burgundy, um genau die Weine einzuschließen, die mindestens eine locatedIn-Relation zur Region Burgund haben. Wir hätten auch eine neue Klasse ThingsFromBourgogneRegion erzeugen können und diese als eine Klasse in owl:intersectionOf verwenden können. Weil wir aber keine andere Verwendung für ThingsFromBourgogneRegion haben, ist die obige Deklaration kürzer, klarer und sie benötigt keinen neu erdachten Namen.

<owl:Class rdf:ID="WhiteBurgundy">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Burgundy" />
    <owl:Class rdf:about="#WhiteWine" />
  </owl:intersectionOf>
</owl:Class>

Die Klasse WhiteBurgundy schließlich, ist genau die Schnittmenge aus Weißweinen und Burgunder. Burgunder andererseits werden in der französichen Region Burgund erzeugt und sie sind trockene Weine. Demzufolge sind alle Individuals vom Typ Wein, die diese Kriterien erfüllen, Teil der Klassenerweiterung WhiteBurgundy (Weißburgunder).

5.1.2. Vereinigungsmenge [OWL DL]

Das folgende Beispiel zeigt die Verwendung von unionOf. Es wird genauso verwendet wie intersectionOf

<owl:Class rdf:ID="Fruit">
  <owl:unionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#SweetFruit" />
    <owl:Class rdf:about="#NonSweetFruit" />
  </owl:unionOf>
</owl:Class>

Die Klasse Fruit schließt beides ein, die Erweiterung SweetFruit (süße Trauben) und die Erweiterung NonSweetFruit (nicht-süße Trauben).

Beachte nun, wie komplett verschieden diese Vereinigungsmengenkonstruktion vom Folgenden ist.

<owl:Class rdf:ID="Fruit">
  <rdfs:subClassOf rdf:resource="#SweetFruit" />
  <rdfs:subClassOf rdf:resource="#NonSweetFruit" />
</owl:Class>                                             ¬ 

Dies sagt aus, dass die Instanzen von Fruit eine Teilmenge der Schnittmenge aus süßen und nicht-süßen Trauben ist, von der wir erwarten würden, dass sie die leere Menge ist.

5.1.3. Komplemtärmenge [OWL DL]

Das complementOf Konstrukt wählt alle Individuals aus der fraglichen Domäne, die zu keiner bestimmten Klasse gehören. Üblicherweise verweist dies auf eine sehr große Menge von Individuals:

  <owl:Class rdf:ID="ConsumableThing" />

  <owl:Class rdf:ID="NonConsumableThing">
    <owl:complementOf rdf:resource="#ConsumableThing" />
  </owl:Class>

Die Klasse NonConsumableThing schließt als Mitglieder alle Individuen ein, die nicht zur Erweiterung ConsumableThing gehören. Diese Menge schließt alle Wines, Regions, etc. ein. Es ist genaugenommen der Mengenunterschied zwischen owl:Thing und ConsumableThing. Deshalb ist das typische Verwendungsmuster von complementOf die Kombination mit anderen Mengenoperatoren:

<owl:Class rdf:ID="NonFrenchWine">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Wine"/>
    <owl:Class>
      <owl:complementOf>
        <owl:Restriction>
          <owl:onProperty rdf:resource="#locatedIn" />
          <owl:hasValue rdf:resource="#FrenchRegion" />
        </owl:Restriction>
      </owl:complementOf>
    </owl:Class>
  </owl:intersectionOf>
</owl:Class>                                             ¬ 

Dies defniert die Klasse NonFrenchWine als Schnittmenge von Wine mit der Menge aller Dinge, die sich nicht in Frankreich befinden.

5.2. Enumerated Classes
oneOf [OWL DL]

OWL bietet die Mittel, um eine Klasse durch eine direkte Aufzählung ihrer Mitglieder zu spezifizieren. Dies tut man mittels oneOf. Beachtenswert ist, dass diese Defintion die Klassenerweiterung komplett spezifiziert, so dass keine weiteren Individuals als dieser Klasse zugehörig deklariert werden können.

Der folgende Code definiert eine Klasse WineColor deren Mitglieder die Individuals White, Rose, und Red sind.

<owl:Class rdf:ID="WineColor">
  <rdfs:subClassOf rdf:resource="#WineDescriptor"/>
  <owl:oneOf rdf:parseType="Collection">
    <owl:Thing rdf:about="#White"/>
    <owl:Thing rdf:about="#Rose"/>
    <owl:Thing rdf:about="#Red"/>
  </owl:oneOf>
</owl:Class>

Zuallererst muss man verstehen, dass kein anderes Individual eine gültige WineColor sein kann, da die Klasse durch Aufzählung definiert wurde.

Jedes Element des oneOf-Konstrukts muss ein gültig erzeugtes Individual sein. Ein Individual muss zu irgendeiner Klasse gehören. Im obigen Beispiel wurde jedes Individual durch seinen Namen referenziert. Wir haben owl:Thing als ein einfaches Cliché verwendet, um diese Referenz einzuführen. Alternativ könnten wir die Elemente der Menge anhand ihres spezifischen Typs WineColor referenzieren durch:

<owl:Class rdf:ID="WineColor">
  <rdfs:subClassOf rdf:resource="#WineDescriptor"/>
  <owl:oneOf rdf:parseType="Collection">
    <WineColor rdf:about="#White" />
    <WineColor rdf:about="#Rose" />
    <WineColor rdf:about="#Red" />
  </owl:oneOf>
</owl:Class>

Andere, komplexere Beschreibungen von Individuals sind ebenso gültige Elemente des oneOf-Konstrukts, zum Beispiel:

<WineColor rdf:about="#White">
  <rdfs:label>White</rdfs:label>
</WineColor>                                             ¬ 

Für weitere Beispiele zur Verwendung von oneOf, siehe die Referenz.

5.3. Disjoint Classes
disjointWith [OWL DL]

Die Unterschiedlichkeit einer Menge von Klassen kann durch owl:disjointWith ausgedrückt werden. Dies garantiert, dass ein Individual, welches ein Mitglied einer Klasse ist, nicht gleichzeitig Instanz einer anderen spezifizierten Klasse sein kann.

<owl:Class rdf:ID="Pasta">
  <rdfs:subClassOf rdf:resource="#EdibleThing"/>
  <owl:disjointWith rdf:resource="#Meat"/>
  <owl:disjointWith rdf:resource="#Fowl"/>
  <owl:disjointWith rdf:resource="#Seafood"/>
  <owl:disjointWith rdf:resource="#Dessert"/>
  <owl:disjointWith rdf:resource="#Fruit"/>
</owl:Class>

Das Pasta-Beispiel demonstriert mehrere voneinander verschiedene Klassen. Zu beachten ist, dass dies nur aussagt, dass Pasta verschieden von allen anderen dieser Klassen ist. Es weist zum Beispiel nicht zu, dass Meat und Fruit verschieden voneinander sind. Um auszusagen, dass in einer Menge von Klassen alle voneinander verschieden sind, muss es eine owl:disjointWith Zuweisung für jedes Klassenpaar geben.

Eine übliche Anforderung ist es, eine Klasse als die Vereinigungsmenge einer Menge von untereinander verschiedenen Unterklassen zu definieren.

<owl:Class rdf:ID="SweetFruit">
  <rdfs:subClassOf rdf:resource="#EdibleThing" />
</owl:Class>

<owl:Class rdf:ID="NonSweetFruit">
  <rdfs:subClassOf rdf:resource="#EdibleThing" />
  <owl:disjointWith rdf:resource="#SweetFruit" />
</owl:Class>

<owl:Class rdf:ID="Fruit">
  <owl:unionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#SweetFruit" />
    <owl:Class rdf:about="#NonSweetFruit" />
  </owl:unionOf>
</owl:Class>

Hier definieren wir Fruit als genau die Vereinigungsmenge von SweetFruit und NonSweetFruit. Wir wissen auch, dass diese Unterklassen die Klasse Fruit in genau zwei verschiedene Unterklassen aufteilen, weil diese eben voneinander unabhängig sind. Mit steigender Anzahl von voneinader verschiedenen Klassen, steigt die Anzahl der Unabhängigkeitszuweisungen proportional mit n2. Wie auch immer, in den Code-Beispielen haben wir gesehen, dass n typischerweise klein ist.

Wenn n gross ist, gibt es andere Ansätze, um das quadratische Wachsen der Anzahl von Zuweisungen zu vermeiden. Eine dieser Methoden ist in der OWL test suite beschrieben.

Die erläuterte Methode funktioniert wie folgt. Wir beschreiben eine Oberklasse deren Elemente eine Property mit einer Kardinalität von eins besitzen. Das heißt, jede Instanz muss einen und nur einen Wert für diese Property haben. Für jede Unterklasse dieser Oberklasse verlangen wir dann, dass ihre Instanzen einen bestimmten eindeutigen Wert für die Property haben müssen. In diesem Falle können keine der verschiedenen Unterklassen gemeinsame Mitglieder haben.


6. Ontologie Versionierung

Ontologien sind wie Software, sie werden gepflegt und ändern sich deshalb im laufe der Zeit. Innerhalb eines owl:Ontology Elements (erläutert oben), ist es möglich auf eine früher definierte Version einer Ontologie zu verweisen. Die Property owl:priorVersion ist dazu gedacht, diesen Verweis zu ermöglichen und kann verwendet werden um die Geschichte einer Ontologie zu verfolgen.

<owl:Ontology rdf:about="">
  ...
  <owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/CR-owl-guide-20030818/wine"/>
  ...
</owl:Ontology>

Die angezeigte Ontologie ist eine frühere Version derjenigen, die definiert wird.

Versionen einer Ontologie müssen nicht miteinander kompatibel sein. Zum Beispiel kann eine frühere Ontologie Statements enthalten, die der aktuellen Version widersprechen. Innerhalb eines owl:Ontology-Elements verwenden wir owl:backwardCompatibleWith und owl:incompatibleWith um die (In-)Kompatibilität mit früheren Versionen der Ontologie anzuzeigen. Wenn owl:backwardCompatibleWith nicht deklariert wird, so sollte Kompatibilität nicht angenommen werden. Zusätzlich bietet owl:versionInfo einen passenden Ansatzpunkt für Versionierungssysteme. Im Gegensatz zu den drei vorherigen Auszeichnungen ist das Objekt owl:versionInfo ein Literal und die Auszeichnung kann verwendet werden, um zusätzlich zu Ontologien auch zu Klassen oder Properties Anmerkungen zu machen.

Für viele Zwecke ist die Versionsverfolgung auf der Ebene ganzer Ontologien nicht ausreichend. Betreuer möchten vielleicht Versionierungsinformationen für Klassen, Properties und Individuals vorhalten - und auch das kann noch nicht ausreichend sein. Die inkrementelle Natur von Klassenausdrücken in OWL hat zur Folge, dass eine Ontologie einer (benannten) Klasse, die in einer anderen Ontologie definiert ist, Einschränkungen auferlegt und dass diese zusätzlichen Einschränkungen selbst Versionierungsinformationen beinhalten.

OWL Full bietet die Ausdrucksstärke, um jede Art von Zuweisung über eine Klasse zu machen, z.B. dass sie eine Instanz einer anderen Klasse ist, oder dass sie (und nicht ihre Instanzen) eine Property und einen Wert für diese Property besitzt. Dieses Rahmenwerk kann man verwenden, um eine Ontologie aus Klassen und Properties zur Versionsverfolgung aufzubauen. Der OWL-Namespace beinhaltet zwei vordefinierte Klassen, die dafür verwendet werden können: owl:DeprecatedClass und owl:DeprecatedProperty. Sie sind dafür gedacht anzuzeigen, dass die Klasse oder Property sich vorraussichtlich in einer folgenden Version auf inkompatible Weise ändern wird:

...
  <owl:DeprecatedClass rdf:ID="&vin;JugWine" />
  <owl:DeprecatedProperty rdf:ID="&vin;hasSeeds" />
...                                                            ¬ 

Es ist wichtig anzumerken, dass owl:DeprecatedClass und owl:DeprecatedProperty keine zusätzliche Semantik beinhalten und es ist an den Softwareentwicklern und den Benutzern von OWL sicherzustellen, dass sie wie gedacht verwendet werden.


7. Anwendungsbeispiele

Sobald eine Anfangsontologie für eine Domäne zur Verfügung steht, kann eine große Anzahl von Anwendungen entwickelt werden, die diese Ontologie auswerten. In diesem Abschnitt beschreiben wir einige Beispielanwendungen in der Weindomäne.

7.1. Weinportal

Es gibt heute eine große Anzahl von Seiten, die sich selbst als Weinportale bezeichnen. Google zum Beispiel liefert 152,000 Treffer auf die Anfrage "wein portal". Einer der Top-Treffer, eine Seite mit dem Namen "Wine-Portal.com", bietet Zugriff auf eine Vielzahl von Seiten. Viele Seiten, die behaupten, sie wären Weinportale sind hauptsächlich Informationsseiten. Zum Beispiel bietet die auf wine-portal.com an erster Stelle hervorgehobene Seite, 'cork cuisine' (www.corkcuisine.com/) Informationen über passende Weine und Speisen, Weine als Geschenke, etc.

Wenn man sich ein beliebiges Themengebiet durchliest, findet man eine Sammlung von Seiten, die Informationen und manchmal auch Angebote die mit dem Thema zu tun haben, beinhalten. Zum Beispiel beinhaltet 'accessories and gifts' Informationen darüber, wonach man Ausschau halten soll, wenn man spezielles Weinzubehör kauft und es enthält ebenfalls eine bedeutende Anzahl von Onlinehändlern. Eine andere Hauptkategorie, genannt 'shopping' hat eine Unterkategorie 'wine shopping' in der man als Benutzer Online (oder 'street shopping') Shops (nach Ländern sortiert) finden kann. Diese beiden Seiten sind nur zwei der heute vielen Beispiele und sie sind repräsentativ für die allgemeine Vorstellung von einem Weinportal, dass eine Sammlung von Informationen und Diensten, die mit einem speziellen Themengebiet verbunden sind, bietet.

Wenn man diese Seiten etwas genauer betrachtet, ist es nicht klar, inwieweit sie heute auf Ontologien aufbauen. Wenn man zum Beispiel den HTML-Quelltext betrachtet, erhält man keinen Aufschluss über die Verwendung von Ontologien. Wie dem auch sei, es ist klar, dass die Seiten Ontologien hätten verwenden können, wenn Weinontologien verfügbar gewesen wären.

Eine einfache Anwendung von Ontologien in Portalseiten ist es, sie zum Zweck der Organisation und des Browsens zu verwenden. Die Auflistung obiger Kategorien könnte aus den obersten Ebenen der Klassen, die mit Wein zu tun haben, generiert sein. Anfragen könnten Weinontologien verwenden, um Wein betreffende Informationen zu erhalten. Wenn jemand eine Suchanfrage nach einem Term machte, der in der Ontologie enthalten ist, könnte die Frage auf Informationen aus Unterklassen ausgedehnt werden, um mehr relevante Antworten zu finden. Portale könnten dazu gebracht werden, sich in Themengebieten selbst automatisch mit (zu verifizierender) Information zu aktualisieren. Mit sehr mächtigen Schlussfolgerungsfähigkeiten ausgestattet, könnten sie wahrscheinlich sogar Seiten, auf denen Wein verkauft wird, erkennen und es schaffen, diese als Teil des Portals zu integrieren.

7.2. Wein Agent

Wir haben einen Wein Agenten für Vorführungszwecke ins Leben gerufen. In unserem ursprünglichen Design ist es das Ziel des Weinagenten Weine zu Menügängen zu empfehlen. Diese Anwendung verwendet die Ontologie, die diesem Guide zugrunde liegt. Diese Weinontologie ist in der DAML Ontologie Bibliothek erhältlich und trägt den Titel wines.

Ein personalisierbarer Weinagent kann eine Anzahl von Diensten für einen Menschen bieten. Der Agent kann verwendet werden, um Weine auf Basis einer Menge von Bedingungen (wie zum Beispiel, welche Speisen serviert werden) zu empfehlen. Der Agent kann Informationen über einen speziellen Wein oder eine spezielle Klasse von Weinen finden, er kann nach passendem Zubehör für einen Wein suchen (wie ein spezielles Glas passend zur Weinsorte, etc.)

Untenstehend beschreiben wir ein Beispiel eines einfachen prototypischen Systems, das als Studentenprojekt entwickelt wurde.

Stellen Sie sich die folgende Situation vor:

Jemand plant eine Dinner Party und mindestens einer der Gäste ist Weinkenner. Der Gastgeber würde gerne Wein servieren, der gut zu den Gängen des Menues passt. Der Gastgeber würde außerdem gerne als Kenner der bei der Party servierten Weine erscheinen. Der Gastgeber würde außerdem gerne passendes Zubehör bei seinem Abendessen bereit haben. Der Gastgeber könnte sich entschieden haben, eine spezielle auf Tomaten basierende Pastasauce mit frischen Nudeln als Hauptgericht zu servieren.

Um nun zum Essen passende Weine zu servieren, braucht der Gastgeber Informationen über Wein-/Essenskombinationen. Um als Weinkenner zu erscheinen, würde der Gastgeber vom Zugang zu, für den Anlass relevanten, Weininformationen profitieren. Um das angemessene Weinzubehör zu haben, müsste der Gastgeber wissen, welches Zubehör in diesem Rahmen wichtig ist (und welches er sich leisten kann).

Mit einer Weinontologie im Hintergrund kann ein Weinagent, unter Angabe der Beschreibung einer Speise, den Typ Wein empfehlen, den man zum Essen servieren soll. Der Weinagent kann vielleicht einen Zinfandel empfehlen als die Lösung der Wahl für die Speise. Gegeben eine Hintergundontologie, kann er zusätzlich einen speziellen Zinfandel empfehlen, vielleicht Marietta Zinfandel. Unter der Annahme, der Wein soll ein Zinfandel sein, kann er einen Laden ausmachen, wo man entweder eine Auswahl an Zinfandel kaufen kann oder er kann nach einem speziellen Zinfandel, wie Marietta, suchen. Wenn eine Hintergrundontologie mit passenden Quellen für den Weineinkauf gegeben ist (möglicherweise nach Ort des Gastgebers und dem Ort des Weinhändlers gefiltert), könnte der Weinagent auf eine Seite, wie wine.com gehen und eine Suche nach 'zinfandels' durchführen, wobei er eine Liste von Zinfandel-Weinen erhält, die auf dieser Seite zum Verkauf stehen. Der Weinagent könnte versuchen Marietta Zinfandel zu finden, entweder von der Kellerei selbst oder von anderen Verkäufern. Er könnte zum Beispiel (durch eine Suche bei Google oder eine strukturierte Suche in ausgewählten Webseiten) herausfinden, dass winelibrary.com ein Angebot für einen Marietta Zinfandel Jahrgang 1999 zum vergünstigten Preis von $13.99 hat. Der Weinagent könnte zusätzliche Filterinformationen einbeziehen, wie durch den Verbraucher vorgegebene Preisbereiche oder Käuferempfehlungen.

Der Weinagent könnte nun versuchen Informationen über Zinfandel im allgemeinen oder Marietta Zinfandel im speziellen zu finden. Er könnte eine Hintergrundontologie über Weinseiten verwenden, um Informationen über spezielle Weine zu finden. Zum Beispiel könnte die Beschreibung des neuesten Zinfandels eines Weingutes hilfreich sein. Zusätzlich könnten Berichte aus respektablen Quellen, wie dem Wine Spectator nützlich sein. Wenn es keinen Test des Marietta Zinfandel auf einer beliebten Weintestseite gibt, kann es sinnvoll sein, nach verwandten Informationen zu suchen, wie Tests über Zinfandel aus der gleichen Region, in diesem Fall aus Sonoma County, California.

Allgemeine Hintergrundinformation kann ebenfalls nützlich sein. Der Gastgeber könnte auch etwas lesen wollen und könnte an Büchern über Wein im Allgemeinen oder Zinfandel im speziellen interessiert sein. Zum Beispiel könnte der Gastgeber interessiert sein an den Büchern die Amazon.com über Zinfandel anbietet. Der Gastgeber könnte des Weiteren Interesse an Informationen über Weine aus der gleichen Region bekunden und könnte so interessiert an Sonoma Zinfandel sein. Ein Weinagent könnte typisches Hintergrundwissen zur Verfügung haben, welches in Verbindung zu den Hauptwissensbereichen steht. Dieser Weinagent ist zum Beispiel mit dem Zusammenpassen von Essen und Wein beschäftigt. So hat er beides, kostenlose und -pflichtige Informationen auf diesem Gebiet, wie den Artikel von Wine Spectator zu passenden Speisen und Wein.

Der Gastgeber könnte auch angemessenes Weinzubehör vor dem Essen besorgen wollen. Wein wird in Weingläsern serviert und verschiedene Weinsorten sollten am besten in verschiedenen Arten von Gläsern serviert werden. Wenn der Gastgeber eine Speisenfolge ausgewählt hat, zu der ein Zinfandel passend ist, könnte er wissen wollen, dass Riedel ein bekannter Hersteller von Weingläsern ist. Der Gastgeber könnte ebenso auf den Wine Enthusiast (einem anerkannten Lieferanten von Weinezubehör) verwiesen und darauf hingewiesen werden wollen, dass der Wine Enthusiast Riedels Vinum Zinfandel Glass als 4er Set für $63.95 (mit einem Rabatt auf $59.95, wenn man zwei 4er Sets nimmt) im Sortiment hat. Der Gastgeber könnte auch Interesse daran haben, dass Amazon.com Riedels einstieliges Sommelier Zinfandel Glass für $49.99 im Programm hat (und einen Listenpreis von $65.00 angibt). Amazon hat auch das gleiche Vinum Glass im 6er Set (anstatt im 4er, wie bei Wine Enthusiast) für $79.99 zu verkaufen (und gibt einen Listenpreis von $119.40 an). Ein Weinagent könnte eine Vergleichsaufstellung von Glaswaren bieten, die zum Essen passen (d.h., passend für einen Zinfandel sind) und dann bezüglich des Preises oder anderen Kriterien, die aus der Liste von Properties der Ontologie gewählt werden, verglichen werden.

Der Gastgeber könnte auch anderes Weinzubehör in Betracht ziehen. Aus der Ontologie wissen wir, dass Korkenzieher Weinzubehör sind. Die Hintergrundontologie könnte Unterklassen von Korkenziehern beinhalten oder man könnte diese Information auch auf relevanten Weinseiten finden. Der Wine Enthusiast bietet ein Set von Korkenziehern, welches er empfiehlt (mit Beschreibungen der Typen und Preisbereiche). Der Wine Enthusiast unterscheidet Korkenzieher auch nach Typ (Hebel, Kellnermesser, Stationär, Drehen, Pumpen) und der Gastgeber möchte vielleicht Informationen über diese Arten erhalten.

Der Weinagent kann auf verschiedenste Ebenen der Entwicklung getrieben werden, immer abhängig vom Wissen in der Hintergrundontologie der Domäne und Informations- und Serviceseiten. In diesem Beispiel verwendeten wir nur Informationen, die Wein, verschiedene Typen, Essen/Weinkombinationen, einiges Weinzubehör und die verwandten Properties betreffen. Wir könnten dies selbstverständlich ausweiten um mehr Information und mehr Einschränkungen durch den Verbraucher einbeziehen.

Ein in Entwicklung befindliches Beispiel dieses Weinagents steht hier zur Verfügung.


Danksagungen

Dieses Dokument ist das Resultat ausgedehnter Diskussionen innerhalb der Web Ontology Arbeitsgruppe als Ganzes. Die Teilnehmer dieser Arbeitsgruppe waren: Yasser alSafadi, Jean-François Baget, James Barnette, Sean Bechhofer, Jonathan Borden, Frederik Brysse, Stephen Buswell, Jeremy Carroll, Dan Connolly, Peter Crowther, Jonathan Dale, Jos De Roo, David De Roure, Mike Dean, Larry Eshelman, Jérôme Euzenat, Tim Finin, Nicholas Gibbins, Sandro Hawke, Patrick Hayes, Jeff Heflin, Ziv Hellman, James Hendler, Bernard Horan, Masahiro Hori, Ian Horrocks, Jane Hunter, Francesco Iannuzzelli, Rüdiger Klein, Natasha Kravtsova, Ora Lassila, Massimo Marchiori, Deborah McGuinness, Enrico Motta, Leo Obrst, Mehrdad Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Noboru Shimizu, Michael Sintek, Michael K. Smith, John Stanton, Lynn Andrea Stein, Herman ter Horst, David Trastour, Frank van Harmelen, Bernard Vatant, Raphael Volz, Evan Wallace, Christopher Welty, Charles White, and John Yanosy.

Ein früher kritischer Text über komplexe Einschränkungen wurde von Raphael Volz, Forschungszentrum Informatik (FZI) geschrieben. Wesentliche Einsichten bot DAML+OIL Walkthru. Jeremy Carroll, Jerome Euzenat, Jeff Heflin, Kevin Page und Peter F. Patel-Schneider stellten ausgedehnte Berichte bereit. Beim WG Treffen am 8. Oktober 2002 stellten Stephen Buswell, Ruediger Klein, Enrico Motta, und Evan Wallace einen detaillierten Bericht, der zu wesentlichen Änderungen führte, vor. Beim WG Treffen am 10. Januar 2003 stellten Jonathan Dale, Bernard Horan, Guus Schreiber und Jeff Heflin detaillierte Berichte über den Guide vor, die Änderungen zur Folge hatten. Die öffentlichen Berichte boten viele hilfreiche Anregungen und Korrekturen.


OWL Glossar

Attribute
wie in XML
Class Definition
informeller Ausdruck für ein owl:Class Element
Class Description
beschreibt eine OWL Klasse, entweder durch einen Klassennamen oder durch das Spezifizieren einer Klassenerweiterung einer unbenannten anonymen Klasse
Class name
informeller Ausdruck für einen owl:Class rdf:ID Attributwert.
Class
wie in RDF
Component
steht für Teile einer Definition, z.B. die Argumente zu intersection-of in einer Klassendefinition (Class Definition)
Concept
informeller Ausdruck für die Abstraktionen "in der Welt" die durch Ontologien beschrieben werden
Constraint
informeller Ausdruck für die Erörterung des Effekts einer Restriction
Data-valued Property
alternativer Ausdruck für DataType Property
Datatype Property
eine OWL Property, die Individuals mit Datenwerten (data values) verbindet
Datatype
ein RDFS Datentyp, fast immer einer der integrierten non-list XML Schema Datentypen
Element
(1) wie in XML
(2) ein Element einer Menge
Entity
wie in XML
Imports Closure
die Information in einem Ontologiedokument, plus der Information in der Importklausel von Ontologiedokumenten, die durch das Dokument importiert werden
Individual-valued Property
alternativer Ausdruck für Object Property
Individual
eine Instanz einer OWL Klasse, d.h. eine Resource, die zu einer Klassenerweiterung einer OWL Klasse gehört
Instance Of
die Verknüpfung zwischen einem Individual und einer Klasse
Instance
ein Mitglied der Klassenerweiterung einer OWL Klasse
Name
wie in den XML Namespaces
Named Class
eine OWL Klasse mit einem zugehörigen Identifier
Node
wie in RDF Graphen
OWL Class
eine RDFS Klasse, die zur Klassenerweiterung von owl:Class gehört
Object Property
eine OWL Property, die Individuals mit anderen Individuals verbindet
Object
(1) das Objekt eines RDF Tripels
(2)ein alternativer Ausdruck für Individual (aus historischen Gründen verwendet)
Ontology Document
ein Webdokument, das eine Ontology enthält, im allgemeinen zu erkennen am owl:Ontology-Element im Dokument
Ontology
(1) Sammlung von Informationen, die im allgemeinen Informationen über Klassen und Properties beiinhaltet
(2) die Information die ein Ontologiedokument beinhaltet
Property Definition
informeller Ausdruck für ein owl:ObjectProperty-Element und/oder owl:DatatypeProperty-Element
Resource
ein Element der betreffenden RDF-Domäne
Restriction, global
reserviert für Erläuterungen der domain und range von Properties
Restriction, local
[siehe oben]
Restriction
für gewöhnlich ein Teil eines Klassenausdrucks, ein Statement, dass eine Beschränkung ausdrückt, normalerweise lokal
Set
eine mathematische Menge
Statement
wie in RDF Graphen
Type
wie in RDF (rdf:type)
URI reference
wie in RDF
Unnamed Class
eine OWL Klasse ohne zugehörigen Identifier, normalerweise Teile von Restrictions.
Vocabulary
eine Menge von URI references



Begriffsindex und Querverweise

Begriffsindex

BegriffAbschnitt
anonymous class 3.2.1.
class 3.1.3.
cardinality 3.4.2.
complement 5.1.3.
datatype 3.2.1.
datatype property 3.2.1.
domain 3.2.1.
entailed 1.
enumerated 5.
extension 3.1.
instance of 3.1.3.
intersectionOf 5.1.1.
imports 2.2.
individual 3.1.3.
instance 3.1.3.
monotonic 2.
object properties 3.2.1.
ontology 1.
open world 2.
OWL DL 1.1.
OWL Full 1.1.
OWL Lite 1.1.
property 3.2.1.
range 3.2.1.
restriction class 3.4.1.
union 5.1.2.
unique names 4.2.


Querverweise zu Guide, Referenz und Semantik

OWL GuideOWL ReferenceOWL Semantics
owl:AllDifferent / 4.3. owl:AllDifferent owl:AllDifferent
owl:allValuesFrom / 3.4.1. owl:allValuesFrom owl:allValuesFrom
owl:AnnotationProperty / 2.2. owl:AnnotationProperty owl:AnnotationProperty
owl:backwardCompatibleWith / 6. owl:backwardCompatibleWith owl:backwardCompatibleWith
owl:cardinality / 3.4.2. owl:cardinality owl:cardinality
owl:Class / 3.1.1. owl:Class owl:Class
owl:complementOf / 5.1.3. owl:complementOf owl:complementOf
  owl:DataRange owl:DataRange
owl:DatatypeProperty / 3.2.2. owl:DatatypeProperty owl:DatatypeProperty
owl:DeprecatedClass / 6. owl:DeprecatedClass  
owl:DeprecatedProperty / 6. owl:DeprecatedProperty  
owl:differentFrom / 4.3. owl:differentFrom owl:differentFrom
owl:disjointWith / 5.3. owl:disjointWith owl:disjointWith
owl:distinctMembers / 4.3. owl:distinctMembers owl:distinctMembers
owl:equivalentClass / 4.1. owl:equivalentClass owl:equivalentClass
owl:equivalentProperty / 4.1. owl:equivalentProperty owl:equivalentProperty
owl:FunctionalProperty / 3.3. owl:FunctionalProperty owl:FunctionalProperty
owl:hasValue / 3.4.3. owl:hasValue owl:hasValue
owl:imports / 2.2. owl:imports owl:imports
owl:incompatibleWith / 6. owl:incompatibleWith owl:incompatibleWith
owl:intersectionOf / 5.1.1. owl:intersectionOf owl:intersectionOf
owl:InverseFunctionalProperty / 3.3. owl:InverseFunctionalProperty owl:InverseFunctionalProperty
owl:inverseOf / 3.3. owl:inverseOf owl:inverseOf
owl:maxCardinality / 3.4.2. owl:maxCardinality owl:maxCardinality
owl:minCardinality / 3.4.2. owl:minCardinality owl:minCardinality
owl:Nothing / 3.1.1. owl:Nothing owl:Nothing
owl:ObjectProperty / 3.2.1. owl:ObjectProperty owl:ObjectProperty
owl:oneOf / 5.2. owl:oneOf owl:oneOf
owl:onProperty / 3.4. owl:onProperty owl:onProperty
owl:Ontology / 2.2. owl:Ontology owl:Ontology
  owl:OntologyProperty owl:OntologyProperty
owl:priorVersion / 6. owl:priorVersion owl:priorVersion
owl:Restriction / 3.4. owl:Restriction owl:Restriction
owl:sameAs / 4.2. owl:sameAs owl:sameAs
owl:someValuesFrom / 3.4.1. owl:someValuesFrom owl:someValuesFrom
owl:SymmetricProperty / 3.3. owl:SymmetricProperty owl:SymmetricProperty
owl:Thing / 3.1.1. owl:Thing owl:Thing
owl:TransitiveProperty / 3.3. owl:TransitiveProperty owl:TransitiveProperty
owl:unionOf / 5.1.2. owl:unionOf owl:unionOf
owl:versionInfo / 6. owl:versionInfo owl:versionInfo
    rdf:List
    rdf:nil
rdf:type   rdf:type
rdfs:comment / 2.2.   rdfs:comment
rdfs:Datatype / 3.2.2.   rdfs:Datatype
rdfs:domain / 3.2.1. rdfs:domain rdfs:domain
rdfs:label / 3.1.1.   rdfs:label
rdfs:Literal / 3.3.   rdfs:Literal
rdfs:range / 3.2.1. rdfs:range rdfs:range
rdfs:subClassOf / 3.1.1. rdfs:subClassOf rdfs:subClassOf
rdfs:subPropertyOf / 3.2.1. rdfs:subPropertyOf rdfs:subPropertyOf

Literaturnachweis

OWL

[OWL Semantics and Abstract Syntax]
OWL Web Ontology Language Semantics and Abstract Syntax , Peter F. Patel-Schneider, Patrick Hayes, and Ian Horrocks, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-semantics-20040210/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/owl-semantics/.
[OWL Overview]
OWL Web Ontology Language Overview , Deborah L. McGuinness and Frank van Harmelen, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-features-20040210/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/owl-features/.
[OWL Reference]
OWL Web Ontology Language Reference , Mike Dean and Guus Schreiber, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-ref-20040210/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/owl-ref/.
[OWL Requirements]
OWL Web Ontology Language Use Cases and Requirements , Jeff Heflin, Editor. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-webont-req-20040210/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/webont-req/.
[OWL Test Cases]
OWL Web Ontology Language Test Cases , Jeremy J. Carroll and Jos De Roo, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-test-20040210/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/owl-test/.

Verwandte W3C Standards

[RDF]
Resource Description Framework (RDF) Model and Syntax Specification , Ora Lassila, Ralph R. Swick, Editors. World Wide Web Consortium Recommendation, 1999,
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/REC-rdf-syntax/.
[RDFS]
RDF Vocabulary Description Language 1.0: RDF Schema , Dan Brickley and R.V. Guha, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ .
Aktuelle Version erreichbar unter http://www.w3.org/TR/rdf-schema/.
[RDF Concepts]
Resource Description Framework (RDF): Concepts and Abstract Syntax, Graham Klyne and Jeremy J. Carroll, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/rdf-concepts/.
[RDF Semantics]
RDF Semantics , Patrick Hayes, Editor. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/rdf-mt/.
[RDF Syntax]
RDF/XML Syntax Specification (Revised) , Dave Beckett, Editor. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/rdf-syntax-grammar.
[URI]
Uniform Resource Identifiers (URI): Generic Syntax , T. Berners-Lee, R. Fielding, and L. Masinter, IETF Draft Standard August, 1998 (RFC 2396).
[XML Base]
XML Base, Jonathan Marsh, Editor. W3C Recommendation, 27 June 2001,
http://www.w3.org/TR/2001/REC-xmlbase-20010627/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/xmlbase/.
[XML Namespaces]
Namespaces in XML , Tim Bray, Dave Hollander, Andrew Layman, Editors. W3C Recommendation, Jan 1999,
http://www.w3.org/TR/1999/REC-xml-names-19990114/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/REC-xml-names.
[XML]
Extensible Markup Language (XML) 1.0 , Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Editors. W3C Recommendation, 10 February 1998,
http://www.w3.org/TR/1998/REC-xml-19980210.
Aktuelle Version erreichbar unter http://www.w3.org/TR/REC-xml.
[XML Schema 1]
XML Schema Part 1: Structures, Henry S. Thompson, David Beech, Murray Maloney, and Noah Mendelsohn, Editors. W3C Recommendation, 2 May 2001,
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/xmlschema-1/.
[XML Schema 2]
XML Schema Part 2: Datatypes, Paul V. Biron, Ashok Malhotra, Editors. W3C Recommendation, 2 May 2001,
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
Aktuelle Version erreichbar unter http://www.w3.org/TR/xmlschema-2/.

Beispielontologien und -anwendungen

[Integrating Applications]
Integrating Applications on the Semantic Web , James Hendler, Tim Berners-Lee, and Eric Miller. Journal of the Institute of Electrical Engineers of Japan, Vol 122(10), October, 2002, p. 676-680.
[VerticalNet]
Industrial Strength Ontology Management , Aseem Das, Wei Wu, and Deborah L. McGuinness. Stanford Knowledge Systems Laboratory Technical Report KSL-01-09 2001. In the Proceedings of the International Semantic Web Working Symposium, Stanford, CA, July 2001.
[Wine Ontology From Daml.org]
http://www.daml.org/ontologies/76
[Wine Ontology / CLASSIC Tutorial]
Classic Knowledge Representation System Tutorial , Deborah L. McGuinness, Peter F. Patel-Schneider, Richmond H. Thomason, Merryll K. Abrahams, Lori Alperin Resnick, Violetta Cavalli-Sforza, and Cristina Conati. AT&T Bell Laboratories and University of Pittsburgh, 1994.
[Wine Ontology Tutorial]
Ontology Development 101: A Guide to Creating Your First Ontology, Natalya Fridman Noy and Deborah L. McGuinness. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880, March 2001.
[Wine Ontology in CLASSIC]
Living with CLASSIC: When and How to Use a KL-ONE-Like Language , Ronald J. Brachman, Deborah L. McGuinness , Peter F. Patel-Schneider , Lori Alperin Resnick , and Alex Borgida. In Principles of Semantic Networks: Explorations in the representation of knowledge, John Sowa, Editor. Morgan-Kaufmann, San Mateo, California, 1991, pages 401--456.

Verwandte Forschung zu KR-Sprachen

[DAML+OIL]
DAML+OIL W3C Einreichung, Beinhaltet Referenzbeschreibung, Modelltheoretische und axiomatische Semantik, geführtes Durchdenken des Problems and Beispiele.
Annotated DAML+OIL Ontology Markup , Dan Connolly, Frank van Harmelen, Ian Horrocks, Deborah McGuinness, Peter F. Patel-Schneider, Lynn Andrea Stein. Dezember 2001.
[DAML-ONT]
DAML-ONT ursprüngliche Veröffentlichung unter http://www.daml.org/2000/10/daml-ont.html.
[DAML-ONT KIF]
Teilweise Axiomatisierung von DAML-ONT unter http://www.daml.org/2000/10/DAML-Ont-kif-axioms-001107.html.
Definiert in KIF (http://logic.stanford.edu/kif/kif.html).
[Description Logics]
The Description Logic Handbook: Theory, Implementation and Application , Franz Baader, Diego Calvanese, Deborah L. McGuinness, Daniele Nardi, and Peter F. Patel-Schneider, Editors. Cambridge University Press, 2002.
[MCF]
Meta Content Framework Using XML , R.V. Guha and Tim Bray. Netscape Communications, 6 June 1997.
[Part Whole]
A Taxonomy of Part-Whole Relations. M. Winston, R. Chaffin & D. Herrmann. Cognitive Science, 11:417-444, 1987.
[XOL]
XOL: An XML-Based Ontology Exchange Language, Peter D. Karp, Vinay K. Chaudhri, and Jerome F. Thomere. Technical Report 559. AI Center, SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025, Jul 1999.

Hintergrundinformationen und Homepages

[Dublin Core]
Dublin Core Metadata unter Homepage, http://dublincore.org/.
[Dublin Core XML]
Expressing Dublin Core in RDF/XML, Dave Beckett, Eric Brickley, and Dan Brickley.
Dublin Core Metadata Initiative. July 31, 2002,
http://dublincore.org/documents/2001/11/28/dcmes-xml/.
[KAON]
The Karlsruhe Ontology and Semantic Web Tool Suite unter http://kaon.semanticweb.org.
[OIL]
OIL Home Page at http://oil.semanticweb.org/.
[Ontobroker]
Die Ontobroker Homepage unter http://ontobroker.aifb.uni-karlsruhe.de/index_ob.html.
Institute AIFB, University of Karlsruhe.
[Ontoknowledge]
Ontoknowledge Homepage unter http://www.ontoknowledge.org/.
[RDF Home]
RDF: Resource Description Framework. Hintergrundinformationen unter http://www.w3.org/RDF/.
[SHOE]
Simple HTML Ontology Extensions (SHOE) Homepage unter http://www.cs.umd.edu/projects/plus/SHOE/. University of Maryland.
[KR]
KR Home Page unter http://kr.org/.


Anhang A: XML + RDF Grundlagen

Dieser Anhang beinhaltet Links zu Einführungen in die Standards von denen OWL abhängt.

Um die OWL-Syntax vollständig verstehen zu können sollte man mit den Grundlagen der entsprechenden hier aufgeführten W3C- und IETF-Standards vertraut sein. Ein kleine Einführung in XML und RDF bieten die ersten beiden Links.


Anhang B: Geschichte

Das 'Resource Description Framework' (RDF) war die erste Sprache um semantische Informationen über beliebige Resourcen zu repräsentieren, die durch das W3C spezifiziert wurde. RDF Schema (RDFS) ist ein W3C Empfehlungsanwärter als Erweiterung zu RDF um RDF-Vokabulare zu beschreiben. RDFS kann verwendet werden, um Ontologien zu erstellen, ist aber gezielt schlank, mit weniger Ausdruckskraft als OWL.

Wie OWL beinhaltet RDFS Klassen und Properties, sowie Range- und Domain-Einschränkungen für Properties. Es bietet Vererbungshierarchien sowohl für Klassen als auch für Properties. Nach der Veröffentlichung begannen Benutzer nach weiteren Features zu verlangen, wie z.B. Datentypen, Aufzählungen und die Möglichkeit Properties strenger zu definieren.

Weitere Anstrengungen der Forschungsgemeinde untersuchten bereits genau diese Art von Features. Für diejenigen, die tiefer in diesen Hintergrund eintauchen möchten, hier eine unvollständige Liste von Projekten und Sprachen:

Anstatt mit verschiedenen Ontologiesprachen für das Semantic Web weiterzuarbeiten, traf sich eine Gruppe von Forschern, einschließlich vieler Hauptbeteiligter der OIL- und DAML-ONT-Bestrebungen, beim Joint US/EU ad hoc Agent Markup Language Committee, um eine neue Web-Ontologiesprache zu schaffen. Diese Sprache, DAML+OIL, basierend sowohl auf OIL als auch auf DAML-ONT, wurde eingereicht beim W3C als vorgeschlagene Basis für OWL und wurde anschließend ausgewählt als Startpunkt für OWL.

Zusätzlich zu Ontologiesprachen, werden verschiedene Taxonomien und bestehende Ontologien bereits kommerziell verwendet. Auf e-Commerce-Seiten ermöglichen sie maschinelle Kommunikation zwischen Käufer und Verkäufer, vertikale Integration von Märkten und sie erlauben es Beschreibungen auf verschiedenen Marktplätzen wiederzuverwenden. Beispiele für die Erstellung von Ontologien für die Kommerzielle Nutzung sind:

Verschiedene Ontologien über Medizin oder Medikamente wurden entwickelt, um zu helfen die überflutenden Massen von aktuellen medizinischen oder biochemischen Daten, die schwierig in ein zusammenhänges Ganzes zu bringen sind. Eine Hauptinstanz ist das Gene Ontology Consortium das Ontologien definiert für

Diese Seite verweist auch auf Ontologien über

Es werden heute schon umfangreiche Taxonomien verwendet, die reif wären für die Überführung nach OWL. Zum Beispiel definiert das 'North American Industry Classification System' (NAICS) eine Hierarchie für über 1900 Items, die Industriearten identifizieren. NAICS ist auch angebunden an das 'International Standard Industrial Classification System' (ISIC, Revision 3), entwickelt und gepflegt durch die Vereinten Nationen.


Anhang C: Änderungsverzeichnis seit Empfehlungsvorschlag vom 15. Dezember 2003

Anmerkung des Übersetzers:

Das Änderungsverzeichnis des Originaldokuments entnehmen Sie bitte dem demselbigen.