Methodische Grundlagen des Semantic Web

Aus Winfwiki

Name der Autoren:	Julia Schomacker, Hannes Scharf, Robert Lacroix
Titel der Arbeit:	"Methodische Grundlagen des Semantic Web"
Hochschule und Studienort:	FOM Hamburg

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Tabellenverzeichnis 4 Einleitung 5 Grundbegriffe 5.1 World Wide Web 5.1.1 Geschichte 5.1.2 W3C 5.1.3 Probleme des Web 5.2 Semantisches Web 5.3 Ontologien 5.4 URI 6 Methodische Grundlagen 6.1 XML 6.1.1 Markup Language 6.1.2 Entstehung und Ziele 6.1.3 Dokumente 6.1.3.1 Wohlgeformtheit und Gültigkeit 6.1.3.2 Markup 6.1.3.3 XML-Deklaration 6.1.3.4 Dokumenttyp-Deklaration 6.1.3.5 Markup-Deklaration 6.1.3.6 Namespace 6.1.3.7 DTD und XML-Schema 6.1.4 Logische Strukturen 6.1.5 Physische Strukturen 6.1.6 Schwächen von XML bei der Wissensrepräsentation 6.2 RDF (Resource Description Framework) 6.2.1 URIs (Eindeutige Bezeichner) 6.2.2 Datenwerte in RDF (Literale) 6.2.3 Syntaxen für RDF 6.2.3.1 Turtle-Syntax 6.2.3.2 XML-basierte Syntax (RDF/XML) 6.3 RDFS (RDF Schema) 6.3.1 Definition von Klassen 6.3.2 Definition von Klassenhierarchien 6.3.3 Definition von Eigenschaftshierarchien 6.3.4 Weitere Ableitungen aus der Nutzung von Eigenschaften 6.3.5 Anmerkungen zu RDFS-Dokumenten 6.3.6 Abgrenzung zwischen RDF und RDFS 6.4 OWL (Web Ontology Language) 6.4.1 Syntax 6.4.2 Elemente zu Klassen 6.4.3 Elemente zu Eigenschaften 6.4.4 Restriktionen von Eigenschaften 6.4.5 Mengen und Aufzählungen 6.4.6 Vergleich zwischen den OWL Versionen 6.5 Vokabulare 6.5.1 Dublin Core 6.5.2 FOAF 6.5.3 MusicBrainz und MusicBrainz XML Metadata Format 6.5.4 DOAP 6.5.5 DOAC 6.5.6 vCard 6.5.7 SIOC 6.6 Einbindung von Metadaten 6.6.1 Eingebettete Metadaten 6.6.2 Verlinkte Metadaten 6.7 SPARQL 7 Schlussbetrachtung 8 Fußnoten 9 Literatur- und Quellenverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
CERN	Conseil Européen pour la Recherche Nucléaire
DC	Dublin Core
DOAC	Description of a Career
DOAP	Description of a Project
DTD	Document Type Definition
eRDF	embedded RDF
FOAF	Friend-of-a-Friend
HTML	Hypertext Markup Language
HTTP	Hypertext Transfer Protocol
IM	Instant Messaging
MMD	MusicBrainz XML Metadata Format
OWA	Open World Assumption
OWL	Web Ontology Language
PIM	Personal Information Manager
RDF	Resource Description Framework
RDFa	RDF in HTML attributes
RDFS	Resource Description Framework Schema
SGML	Standard Generalized Markup Language
SIOC	Semantically Interlinked Online Communities
SKOS	Simple Knowledge Organisation System
SPARQL	SPARQL Protocol and RDF Query Language
SQL	Structured Query Language
UML	Universal Markup Language
URI	Uniform Resource Identifier
URL	Uniform Resource Locator
URN	Uniform Resource Name
UTF	UCS/Unicode Transformation Format
WSDL	Web Service Description Language
W3C	World Wide Web Consortium
WWW	World Wide Web
XHTML	eXtensible Hypertext Markup Language
XML	eXtensible Markup Language

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	RDF-Graph, der die Beziehung zwischen zwei Ressourcen, in diesem Fall Joachim Löw und die Deutsche Nationalmannschaft, beschreibt.
2	RDF-Graph, der den beiden Ressourcen Joachim Löw und die Deutsche Nationalmannschaft jeweils ein Literal des Typs Name zuweist.
3	RDF-Graph, der der Ressource Joachim Löw das Alter 48 vom XML Schema-Datentyp nonNegativInteger und der Deutsche Nationalmannschaft ein ungetyptes Literal Name zuweist.
4	Eigenschaftshierarchie die sich beim Gebrauch von rdfs:subPropertyOf ergibt.
5	Abgrenzung zwischen RDF und RDFS.
6	Ausdrucksfähigkeit der betrachteten Sprachen.

3 Tabellenverzeichnis

Tabelle Nr.	Quelle
1	Eigenschaftshierarchie die sich beim Gebrauch von rdfs:subPropertyOf ergibt[1].
2	Ergebnis der 1. SPARQL-Abfrage.
3	Ergebnis der 2. SPARQL-Abfrage.
4	Ergebnis der 3. SPARQL-Abfrage.

4 Einleitung

„The WWW contains documents intended for human consumption, and those intended for machine processing. The Semantic Web will enhance the latter. The Semantic Web will not understand human language ... The Semantic Web is about machine languages: well-defined, mathematical, boring, but processable. Data, not poetry.“
[Quelle: Tim Berners-Lee]^[2]

Im Rahmen der Globalisierung und insbesondere durch die heutigen Informationstechnologien entstehen immense Wissensbasen, welche zwar über den gesamten Globus verteilt, aber gleichzeitig auch weltweit abrufbar sind. Diese Wissensbasen sind jedoch inhaltlich aufwendig zu pflegen, als auch aktuell zu halten. Ergebnisorientierte Abfragen werden durch die Fülle von – teilweise verwaisten und veralteten – Informationen immer schwieriger. Hier soll das Semantic Web Abhilfe schaffen. Im World Wide Web existieren größtenteils für den Menschen lesbare Dokumente. Gilt es nun diese Dokumente und die sich darauf/darin befindlichen Informationen jedoch gezielt zu finden, wird eine maschinenfreundliche Datenbasis benötigt. An dieser Stelle greift das Semantic Web ein. Es ermöglicht auf Basis von Metadaten, generischen Datenmodellen und Metamodellen strukturierte Datenbasen.

Diese Datenbasen müssen gleichwohl erstellt werden. Hierzu werden unabdingbar Methoden und Standards für eine Interoperabilität benötigt.

5 Grundbegriffe

Durch das Erklären einiger Grundbegriffe erfolgt eine erste Einsicht in das Semantic Web. Zunächst werden die Anfänge des World Wide Web und deren Probleme beschrieben. Darauf folgt die Entwicklung des Semantic Web.

5.1 World Wide Web

Aus dem heutigen Alltagsleben ist das World Wide Web, kurz das Web, nicht mehr wegzudenken. Die stetig anwachsenden Informationen übersteigen die menschliche Vorstellungskraft^[3]. Die Infrastruktur und Organisation des Web bieten gegenüber herkömmlichen Methoden erhebliche Vorteile. Die wichtigsten Einsatzgebiete des www sind heute^[4]:

• Kommunikation, insbesondere Email, aber auch Telefonie und Television
• Suche und Recherche für private, kommerzielle und wissenschaftlich Zwecke
• Electronic Banking
• Electronic Buisness
• Technische Anwendungen, wie Überwachungen und Fernwartungen

5.1.1 Geschichte

Das WWW reicht zurück in das Jahr 1989. Es basiert auf dem Hypertextsystem und wurde von einer Initiative am Hochforschungszentrum CERN in Genf von Tim Berners-Lee entwickelt^[5]. Mit Hilfe von Querverweisen sogenannten Links gelang es ihm, eine Verbindung eines Host mit einer durch URL (Uniform Resource Locator) vertretenen Startseite (Homepage) zu adressieren. Diese Einstiegsseite ermöglicht dann weitere Informationen über Links abzufragen. Unzertrennbar mit der Entwicklung des WWW sind die damit verbundenen Highlevel Internet Protokolle, kurz HTTP (Hypertext Transfer Protocol), sowie die damit verbundene Seitenbeschreibungssprache Hypertext Markup Language, besser bekannt als HTML^[6].

5.1.2 W3C

Im Oktober 1994 gründete Tim Berners-Lee das World Wide Web Consortium (W3C) am Massachusetts Institute of Technology, Laboratory for Computer Science in Zusammenarbeit mit dem CERN, dessen Ziel es ist, durch Protokolle und Richtlinien das langfristige Wachstum des Internets zu gewährleisten^[5].

5.1.3 Probleme des Web

Das Hauptproblem besteht darin, dass eine Vielzahl an Informationen in Form von Dokumenten, welche im Web zur Verfügung stehen, sich auf Stichwort basierende Zeichenketten beziehen. Bekannte Suchmaschinen, wie Google oder Yahoo nutzen Zeichenfolgen als Grundlage der Stichwortsuche^[7]. Wird beispielsweise der Suchbegriff „Joachim Löw“ in die Suchmaschine Google eingegeben, erhält der Suchende eine stichwortbasiertes Ergebnis. Anwenderfreundlicher wäre hier eine semantische Suche. Weitere Probleme bringt die dezentrale Struktur und Organisation des Webs, durch seine Heterogenität der verschiedenen Informationen und Ebenen:

• unterschiedliche Kodierungs- und Datenformate
• die verschiedenen Verwendung von natürlichen Sprachen
• der unterschiedliche Aufbau von homepages

Diese Vielzahl an Informationen in Form von Dokumenten, die über das gesamte Web verteilt sind, machen es schier unmöglich, Suchbegriffe in eindeutige Gruppen einzuteilen.

5.2 Semantisches Web

Die Anwendung semantischer Technologien zur Erschließung von Information im Internet wird als Semantik Web bezeichnet. Die Idee besteht darin, Information in einer Art und Weise aufzubereiten, dass deren Semantik, sprich ihre Bedeutung, von Maschinen verarbeitet werden können^[8]. Dazu hat das W3C in den vergangenen Jahren eine Reihe von Richtlinien und Standards zur Beschreibung von Daten veröffentlicht, die es ermöglichen, Information zwischen unterschiedlichen Anwendungen und Plattformen auszutauschen und zueinander in Beziehung zu setzen. So könnte die Suche nach einer Sehenswürdigkeit, zum Beispiel ein Fußballstadion, über das Mobiltelefon automatisch die Feststellung des Standorts nach sich ziehen und ein Routenplaner aufgerufen werden. Diese Eigenschaft wird auch als Interoperabilität bezeichnet und ist eine wesentliche Voraussetzung für das semantische Web, in welchem die Daten nicht in einer zentralen Datenbank vorrätig gehalten werden, sondern über eine Vielzahl von Quellen verteilt sind.

Eine weitere wichtige Bedingung ist die Herstellung von Eindeutigkeit von Information^[9]. Dies erfolgt über sogenannte URIs (Uniform Resource Identifier). Sie stellen eine Eindeutigkeit des Datenobjektes fest.

Die dritte Bedingung ist, das nicht nur die Daten selbst, sondern auch die Beziehungen zwischen diesen eindeutig beschrieben werden. Die Informationsorganisation erfolgt in Ontologien oder Wissensmodellen. Die Grundlage dafür bilden Beschreibungssprachen wie RDF (Ressource Description Framework) und OWL (Web Ontology Language). Bei RDF werden zum Beispiel zwei Ressourcen in Form einer Aussage miteinander in Beziehung gesetzt^[10]. Die Aussage lässt sich in Form von Subjekt-Pädikat-Objekt verstehen und bildet ein sogenanntes Tripel.

Da die Ausdruckskraft von RDF noch relativ beschränkt ist, wurde zusätzlich OWL entwickelt, um auch komlexere Aussagen und Beziehungen abbilden zu können. Auf der Grundlage prädikikatenlogischer Operatoren können unter anderem Klassen, Hierarchien, Teil- und Schnittmengen sowie Funktionen modelliert werden. Mit SPARQL steht zudem eine Abfragesprache zur Verfügung, in der Ontologien nach bestimmten Aussagen durchsucht und die relevanten Daten extrahiert werden können. Das Social Semantic Web vereint die formalen Methoden der maschinellen Aufbereitung von Information mit den informellen, auf Kollaboration basierenden Methoden der Wissensorganisation. Die Grundlage dafür bilden Vokabulare, wie Dublin Core, FOAF (Friend of a Friend), SIOC (Socially Interlinked Online Communities) u.v.m., die speziell dafür entwickelt wurden, Dokumente, Personen und soziale Beziehungen zu beschreiben, die von Nutzern abgelegten Metadaten zu organisieren und diese in einer maschinenverarbeitbaren Form zur Verfügung zu stellen.

Das Social Semantic Web ist eine konkrete Ausprägung des Semantic Web, dass die automatisierte Bedeutungsverarbeitung in erster Linie dazu einsetzt, um Beziehungen in elektronischen Netzwerken abzubilden und die Interaktion zu unterstützen.

5.3 Ontologien

Wissensmodelle, oder Ontologien, definieren, welche Beziehungen zwischen Informationen erlaubt sind, und welche Bedeutung sie haben^[11]. Somit kann ausgewiesen werden, inwieweit Personen zueinander in Beziehung stehen, und ob sie z.B. Ehepartner, Freunde oder Arbeitskollegen sind. Zusätzlich können Ontologien auch dazu dienen, verborgene Informationen aus Datenbeständen durch logische Operatoren abzuleiten. Denn wenn zum Beispiel David der Sohn von Oliver Kahn ist, kann es sich bei Oliver Kahn nur um den Vater von David handeln. Ontologien können verschiedene Ausprägungen annehmen. Einerseits Folksonomies, ein unverbundenes Vokabular, das aus gemeinschaftlichen Tagging heraus entsteht und hierarchische Klassifikation sogenannten Taxonomien.

5.4 URI

URI (Uniform Resource Identifier) ist ein einheitlicher Bezeichner für abstrakte oder physikalische Ressourcen. Es ist eine Zeichenfolge, die insbesondere zum bezeichnen von Web- Seiten, Web-Diensten und Dateien verwandt wird. Ursprünglich wurden URIs in zwei Untermengen URLs (Uniform Resource Locators) und URNs (Uniform Resource Names) getrennt. URLs werden zum identifizieren Web-adressierbarer Ressourcen verwendet und URNs zum identifizieren von Ressourcen mittels eines vorhandenen oder frei zu vergebenen Namen. Da sich einige URIs keiner der Unterarten zuordnen lässt, steht die strikte Trennung nicht mehr im Vordergrund^[12].

Ein Anteil eines URIs wird als URI-Schema bezeichnet, dass oft hierarchisch aufgebaut ist und den Typ einer URI angibt. http oder mailto (zur Bezeichnung von E-mail Adressen) sind z.B. häufig gebrauchte URI-Schemata.

Schema://[Benutzer[:Passwort]@]Server[:Port]/[Pfad][?Anfrage] 

Die eckigen Klammern in diesem Beispiel zeigen auf, dass die Angabe optional ist. Benutzername und Passwort können z.B. bei der Übertragung von Dateien mit FTP zur Authentifizierung genutzt werden. Server gibt den Domain-Namen oder die IP-Adresse des Servers an und Port kann einen TCP-Port angeben. Der oft hierarchisch zusammengesetzte Pfad wird zusammen mit der nicht hierarchischen Anfrage benutzt, um die Identifikation einer Ressource innerhalb der Server-Domain herzustellen^[12].

http://www.uwe-kern.de/winfwiki/index.php/Fallstudie_Wintersemester_08/09
\__/ \_______________/ \_________________/ \____________________________/
 |          |                  |                 |
Schema     Server             Pfad            Anfrage

Wenn ein Fragment an ein URI angehängt wird, bezeichnet man es als URI-Referenz. Diese werden in RDF häufig zur eindeutigen Referenzierung von Ressoucen verwendet.

6 Methodische Grundlagen

Die Grundlagen werden in diesem Kapitel hierarchisch erläutert. XML stellt die Basistechnologie dar, auf der RDF, RDFS und OWL fußen. Darüber hinaus werden Vokabulare zur Beschreibung und Möglichkeiten der Einbindung von semantischen Metadaten vor-, und abschließend die Abfragesprache SPARQL zur Abfrage von semantischen Wissensbasen dargestellt.

6.1 XML

XML bedeutet eXtensible Markup Language, ist eine Auszeichnungssprache (Markup Language) und beschreibt eine Klasse von Objekten, sogenannte XML-Dokumente, und teilweise das Verhalten der dazugehörigen Software. XML ist eine beschränkte Form von SGML (Standard Generalized Markup Language), so dass XML-Dokumente in der Konstruktion mit SGML-Dokumenten konform sind ^[13]. XML benutzt ebenfalls wie HTML sogenannte Tags zur Auszeichnung. Sie legt die logische Struktur von Dokumenten fest und nicht, wie bei HTML, deren Darstellung. Außerdem ist XML eine Meta-Sprache, die dazu dient, beliebige Markup-Sprachen zu erstellen. Somit kann mit Hilfe von XML auch die Markup Language HTML definiert werden. Die XML-konforme Version von HTML ist XHTML. HTML ist eine spezielle Sprache zum Formatieren und Darstellen von Texten. XML dagegen definiert Sprachen für Dokumente mit ganz verschiedenen Zwecken.

Beispiel:

<Trainer>Joachim Loew</Trainer> trainiert
<Spieler>Sebastian Schweinsteiger</Spieler>

Es werden frei definierte Tags <Trainer> und <Spieler> verwendet.

6.1.1 Markup Language

In Auszeichnungssprachen werden bestimmte Teile von Textdokumenten mit zusätzlichen Informationen versehen. Die Textteile werden ausgezeichnet und annotiert. Es sind Daten, die andere Daten genauer beschreiben und werden Metadaten genannt.

6.1.2 Entstehung und Ziele

Eine XML- Arbeitsgruppe, die Ende der 90er Jahre gegründet wurde, entwickelte in Zusammenarbeit mit dem World Wide Web Consortium XML unter Festlegung folgender Ziele:

1. Einfache Internetnutzung
2. Breites Anwendungsspekrum
3. SGML Kompatibelität gewährleisten
4. Einfache Handhabung der XML-Dokumentverarbeitung
5. XML-Dokumente sollen für Menschen interpretierbar sein
6. Schnelle, präzise und leichte Entwurfentwicklung
7. geringe Bedeutung der Knappheit von XML-Markup

Der erste Entwurf entstand 1996. Am 10.02.1998 wurde XML 1.0 mit Empfehlung des W3C veröffentlicht und Oktober 2000 folgte die 2. Edition von XML 1.0^[14].

6.1.3 Dokumente

Aus einem optionalen Prolog und den eigentlichen XML-Daten besteht ein XML-Dokument. Der Prolog sollte die XML-Deklaration enthalten, eine Referenz auf ein externes Stylesheet und eine Dokumenttyp-Deklaration. XML-Dokumente sind aus Entities (Speicherungseinheiten) aufgebaut und enthalten Daten, die parsed (analysiert) oder unparsed (nicht analysiert) sind. Die Zeichen der analysierte Daten stellen entweder Zeichendaten oder Markup dar.Jedes XML-Dokument hat eine logische und eine physische Struktur. Aus physischer Sicht besteht ein Dokument aus einer Reihe von Entities, die auf andere Entities verweisen können. Jedes Dokument beginnt mit einer Wurzel- oder Dokument-Entity^[13].

Die logische Struktur beinhaltet Deklarationen, Elemente, Kommentare, Zeichenreferenzen und Verarbeitungsanweisungen, die durch ein Markup gekennzeichnet sind. Die beiden Strukturen werden dann korrekt verschachtelt.

XML verlangt zwingend, dass Dokumente wohlgeformt sind. Diese Eigenschaft wird erfüllt, wenn

1. es als Gesamtheit betrachtet zu der mit document bezeichneten Produktion passt,
2. es alle Wohlgeformtheitsbeschränkungen dieser Spezifikation erfüllt und
3. jedes seiner Parsed Entities, welches direkt oder indirekt referenziert wird, wohlgeformt ist. (xml)

6.1.3.1 Wohlgeformtheit und Gültigkeit

XML hat zwei verschiedene Vorstellungen von einem korrekten Dokument. Zum einen ein Dokument mit verständlichem Markup wird als wohlgeformt bezeichnet und zum anderen ist es gültig, wenn in seiner Dokumenttyp-Deklaration die Konformität mit einer DTD (Dokumenttyp-Definition) deklariert wird und es mit dieser DTD tatsächlich konform ist. Ein gültiges XML-Dokument enthält zusätzlich zur Wohlgeformtheit noch eine Dokumenttyp-Definition (DTD)^[13].

Ein wohlgeformtes Dokument sollte u.a .folgende Kriterien erfüllen:

• die XML-Version sollte deklariert sein
• es gibt genau 1 Wurzelelement
• innerhalb des Wurzelelementes sind alle Elemente eindeutig ineinander verschachtelt
• alle nicht-leeren Elemente sind mit Start-Tag und End-Tag markiert
• jeder Start-Tag beginnt mit < und schließt ab mit > und jeder End-Tag beginnt mit </ und schließt ab mit >
• leere Elemente sind entweder mit Start- und End-Tag markiert oder beginnen mit < und schließen ab mit />
• ein Attribut darf nicht zweimal im gleichen Tag vorkommen
• verwendete Entitäten müssen vor ihrer Referenzierung deklariert worden sein

6.1.3.2 Markup

In Dokumenten ist die Funktion des Markup die logische Struktur und die Aufteilung auf den Entities zu beschreiben und besteht aus Start-, End- und Leeres Element-Tag, Entity- und Zeichenreferenzen, Kommentare, usw.^[13]. Markup und Zeichendaten bilden ein XML-Dokument, das als XML-Text bezeichnet wird. Dieser Text wird in Unicode dargestellt und Markup durch Begrenzer (Sonderzeichen) eingegrenzt. Haupsächlich angewandt werden:

• < >
• & ; (Semikolon)

Beispiele:

<start-tag> ... </end-tag> 
<!-- ... -->   Kommentarbegrenzung

6.1.3.3 XML-Deklaration

Enthalten in der XML-Deklaration ist die XML-Version, falls nicht die Unicode-Codierungen verwendet werden, eine Codierungsdeklaration und eine Standalone-Deklaration. Die Standalone-Deklaration liefert Informationen, ob Markup-Deklarationen außerhalb des Dokumentes stehen. Wenn die Markup-Deklaration außerhalb des Dokumentes steht: standalone = "no". Falls keine Standalone-Deklaration vorhanden ist, wird "no" angenommen.

Beispiel:

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

Das Layout wird in einem sogenannten Stylesheet festgehalten.

Beispiel:

<?xml-stylesheet href="...\styles\muster.xsl" type="text/xsl" ?>

6.1.3.4 Dokumenttyp-Deklaration

Sie definiert die Beschränkungen der logischen Strukur und unterstützt die Verwendung von vordefinierten Entities. Nur wenn eine explizite Dokumenttyp-Deklaration und das Dokument, die darin formulierten Beschränkungen enthält, ist ein XML-Dokument gültig.Die Dokumenttyp-Deklaration beinhaltet eine Referenz auf ein externe DTD (engl. Document Type Definition). Sie kann allerdings auch eine intern DTD enthalten, die in der gleichen Einheit gespeichert ist, wie die XML-Daten.
Die Dokumenttyp-Deklaration verweist auf oder beinhaltet Markup-Deklarationen, denen die anschließenden XML-Daten entsprechen sollen und enthält auch den Namen des Wurzelelementes^[13].

Beispiel für ein XML-Dokument mit externer DTD:

<?xml version="1.0" ?> 
<!DOCTYPE gruss SYSTEM "hallo.dtd"> 
<gruss>Hallo Herr Kahn!</gruss> 

"hallo.dtd" ist der System-Identifer und gibt die Adresse einer DTD für das Dokument an.

Beispiel für ein XML-Dokument mit interner DTD:

<?xml version="1.0" ?> 
<!DOCTYPE gruss [
<!ELEMENT gruss (#PCDATA)> 
]>
<gruss>Hallo Herr Kahn!</gruss>

6.1.3.5 Markup-Deklaration

Die Grammatik für eine Klasse bilden Markup-Deklarationen. Es ist eine Elementtyp-Deklaration, eine Attributlisten-Deklaration, eine Entity-Deklaration oder eine Notation-Deklaration und die Grammatik heißt Dokumenttyp-Definition, kurz DTD. Diese verschiedenen Deklarationen stehen teilweise oder ganz innerhalb von Parameter-Entities^[13].

6.1.3.6 Namespace

Ein Namespace (Namensraum) setzt sich zusammen aus einer Menge von XML-Namen, die in einem XML-Dokument verwendet werden. Namensräume werden allgemein wie folgt spezifiziert:

<Element-Name xmlns[:Präfix] = URI>

Sie werden innerhalb des Start-Tags eines Elements deklariert, hier mit dem Namen Element-Name, und sind innerhalb dieses Elements gültig. Die Form einer URI hat der Name und wird als Wert des Attributes xmlns deklariert. Unter Ausnutzung eines vordefinierten XML-Attributes in XML-Dokumente wird es XML konform eingebunden. Optional kann ein Präfix angegeben werden, das durch einen Doppelpunkt vom Attribut-Namen xmlns getrennt wird. Da URIs oft sehr lang sind, kann das Präfix innerhalb des Elementes als Abkürzung für die URI benutzt werden. Weiterhin können URIs gemäß der Spezifikation Zeichen enthalten, die in XML-Dokumenten eigentlich gar nicht erlaubt sind. Wenn kein Präfix angegeben wird es default namespace genannt. Alle Namen, die den Standard-Namensraum benutzen, können ohne Präfix und ohne URI angegeben werden. Es kann allerdings höchstens einen Standard-Namensraum geben. Attribute können nicht mit Namensräumen modularisiert werden, da ihr Name nur lokal für das Element gilt^[15].

6.1.3.7 DTD und XML-Schema

Mittels einer Dokumenttyp Definition (DTD), die formal eine Grammatik ist, wird die zulässige Strukur eines Dokuments festgelegt. Hierzu werden Elementtypen und Attributtypen definiert, die die zulässigen Inhalte der Elemente und die zulässigen Wertebereiche der verwendeten Attribute bestimmen. Die Grammatik enthält zur Definition von Elementtypen Regeln der Form <!ELEMENT EName (Content)> und zur Definition von Attributtypen Regeln der Form <!ATTLIST EName Attr1 AttrType1 Default1 ... Attrk AttrTypek Defaultk>. Innerhalb einer DTD ist die Definition eines Elementtyps global. Zu jedem Elementtyp darf nur genau eine Regel vorgesehen werden. Attributdefinitionen sind hingegen an ein Element gebunden und somit für dieses lokal^[16] .

Der neuere XML-Schema-Standard soll mittelfristig DTDs ersetzen.Jede DTD kann in ein XML Schema überführt werden. Die Grundfunktionalitäten sind ähnlich der DTDs,jedoch gibt es einige Vorteile. Es gibt die mehr Möglichkeiten von Strukurvorgaben, somit kann z.B. die genaue Anzahl von erlaubten verschachtelten Stellen angegeben werden oder es können Elemente so gruppiert werden, dass an definierten Stellen jeweils genau ein Element der Gruppe auftreten darf. Außerdem gibt es die Möglichkeit, vordefinierte XML-Schema-Datentypen zu nutzen und selbst zu erweitern^[17].

6.1.4 Logische Strukturen

Dokumente im Allgemeinen weisen meistens eine hierarchische Struktur, die sogenannte Baumstruktur, auf. Bücher, zum Beispiel, sind in Kapitel unterteilt, und diese sind aus Überschriften, Absätzen usw. zusammengesetzt. In XML werden die logischen Komponenten, in die ein Dokument zerlegt werden kann, Elemente genannt.

Jedes XML-Dokument enthält ein oder mehrere Elemente, die entweder durch Start- und End-Tags oder, im Falle eines leeren Elements, durch ein Leeres-Element-Tag begrenzt sind. Sie enthalten entweder andere Elemente oder den eigentlichen Text des Dokumentes, der als Zeichendaten bezeichnet wird.

Beispiel:

<adresse>
 <name> Oliver Kahn </name> 
 <ort> Muenchen </ort>
</adresse> 

Jedes Element hat einen Typ der durch einen Namen (generic identifier - GI) identifiziert wird. Zusätzlich können den Elementen auch eine Reihe von Eigenschaften zugeordnet werden, die als Attribut bezeichnet werden, wie z.B. ein Sicherheitsattribut, das bestimmte Datensätze nur in Abhängigkeit von der Sicherheitsstufe einer Person freigibt. Attribute bestehen aus einen Namen und einen Wert.

Aufgrund der Baumstruktur wird das Element, das alle anderen Elemente enthält als Wurzelelement oder Dokumentelement bezeichnet. Die Unterelemente untergliedern sich in sogenannte Zweige und Blätter.Beim Wurzelelement muss dessen Start-Tag in der ersten Zeile vom XML-Quellcode stehen, also direkt nach der Deklaration^[18].

Der Zeichensatz, der in XML verwendet wird ist der Unicode. Es ist ein 16-bit Zeichensatz und die ersten 128 Zeichen sind kompatibel mit ASCII. Somit können XML-Dokumente mit Standardeditoren erzeugt werden.

Inhalt eines Elementes heißen alle von Start- und End-Tag umgrenzten Daten und Elemente. Tags bestehen aus genannten XML-Namen, die mit spizen Klammern eingeschlossen sind.

<Trainer>Joachim Loew</Trainer> 

Tags treten immer in Paaren auf. Das End-Tag schließt das Start-Tag. Beim Leeres Dokument-Tag wird ein selbstschließender Tag verwendet

<Fußballmanschaft/>

Attribute hingegen weisen gewissen Aspekten eines Elements Werte zu. Sie enthalten Informationen über die Elemente und können entweder innerhalb eines Start-Tag oder in einem selbstschließenden Tag verwendet werden.

Die Namen der einzelnen Elemente und Attribute werden als XML-Namen bezeichnet. Von der Syntax her müssen XML-Namen

• mit einem Buchstaben oder einem Unterstrich anfangen,
• können auch Zahlen enthalten,
• Groß- und Kleinschreibung muss beachtet werden
• und haben keine Beschränkung in ihrer Länge.

Bei Attributen ist noch zu beachten, dass die zugehörigen Werte direkt nach dem Attributnamen geschrieben werden. Sie werden durch Gleichheitszeichen voneinander getrennt und mit einfachen oder dopellten Anführungszeichen umschlossen.

Kommentare in XML werden wie folgt geschrieben:

<!-- Beispiel Tag mit einem Attribut und Daten als Inhalt -->
<person Titel="Professor">Rudi Studer</Person>
<!-- Beispiel Selbstschließendes Tag mit zwei Attributen -->
<Person Titel="Professor" Name="Rudi Studer" 

xml:lang ist ein spezielles vordefiniertes Attribut, das die Sprache des Dateninhaltes spezifiziert.

Beispiel:

<Fußballnationalmanschaft>
  <Mitglieder Spieler="Stürmer">
    <Name>Lukas Podolski</Name>
      <Land xml:lang="de">
         Deutschland
      </Land>
      <Land xml:lang="en">
         Germany
      </Land>
  </Mitglieder>
</Fußballnationalmanschaft>

Es werden die üblichen Ländercodes verwendet. In diesem Beispiel steht "de" für die deutsche Sprachen und "en" für die Englische.

Gegebenenfalls ist es schwierig zu entscheiden ob besser ein Element mit Inhalt oder als Wertzuweisung zu einem Attribut verwendet wird.Richtlinien zur Benutzung von verschachtelten Elementen und Attributen sollen dies vereinfachen. Verschachtelte Elemente sind vorzuziehen, wenn Daten bereits eine Art eigene Struktur besitzen.
Attribute haben keine Struktur und ihnen kann auch nichts hinzugefügt werden. Die Verwendung von Attributen ist vorzuziehen, wenn Informationen über ein Element ausgedrückt werden soll.

6.1.5 Physische Strukturen

Entities, die sogenannten Speichereinheiten aus denen sich ein XML-Dokument zusammensetzt, können aus einzelnen Zeichen bestehen, aber auch zum Beispiel aus den Text eines Buches. Jede Entity hat einen Namen und gewähren eine Aufteilung der Dokumente in übersichtliche Blöcke. XML-Elemente beschreiben die logische Struktur. Als physikalische Struktur werden durch Entities lokalisierte Byteblöcke bezeichnet. Jedes XML-Dokument besitzt eine Dokument-Entity, die als Ausgangspunkt für den XML-Prozessor dient und auch das gesamte Dokument enthalten darf. Man unterscheidet analysierte (geparste) Entities, deren Inhalt als Ersetzungstext bezeichnet wird und nicht analysierte (ungeparste) Entities, wie z.B. Grafiken, Videos oder einfacher Text. Solche Daten-Entities enthalten kein XML-Markup. Es wird in einer zugeordneten Notation deklariert, ob es sich um GIF, JPEG usw. handelt ^[19]. Allgemeine Entities werden in der DTD deklariert, aber nur innerhalb des XML-Dokumentinhaltes verwendet, während Parameter-Entities nur innerhalb der DTD benutzt werden können.Der Inhalt von internen Entities wird in der Deklaration selber angegeben, während externe Entities in einer separaten Speichereinheit abgelegt sind und über das ganze Internet verteilt sein können. Entities erfüllen demnach unterschiedliche Zwecke, wie z.B.

• dem Repräsentieren von mehrfach vorkommenden Zeichenfolgen
• dem Positionieren von Nicht-XML-Daten in einem XML-Dokument
• der Konstruktion einer DTD
• der Konstruktion eines XML-Dokumentes
• der systemunabhängigen Repräsentanz von Zeichen

6.1.6 Schwächen von XML bei der Wissensrepräsentation

Für die Erstellung strukturierter Dokumente ist XML eine wichtige Basistechnologie, vor allem durch standardisierte Regelung Bäume und Attribute-Wert-Paare zu erzeugen. Allerdings sind XML-Tags auch lediglich Wörter, die wie anfangs erwähnt mehrdeutig sein können und deren Beziehung zueinander nicht eindeutig bestimmt sind. In den folgenden zwei Beispielen wird deutlich das für den Menschen die gewählten tags eine Bedeutung haben. Für eine Maschine jedoch haben sie die gleiche Struktur.

<Fallstudie>Diese Fallstudie </Fallstudie> hat den Titel
<Titel> Methodische Grundlagen des Semantic Web</Titel>

<fdsl>Diese Fallstudie Fallstudie</fdsl> hat den Titel
<zrla>Methodische Grundlagen des Semantic Web </zrla>

Geschickt gewählte Tags können also sehr wohl eine Bedeutung für Menschen haben. Nur für Maschinen sind sie bedeutungslos, sprich ohne Semantik. Somit ist die Stärke von XML, nämlich die universelle Art und Weise für den Datenaustausch von beliebigen Textdokumenten, auch die Schwäche. Denn es fehlt die Möglichkeit die Bedeutung von Annotationen auf eine Art zu kodieren, die maschinenseitige Verarbeitung ermöglicht, bis hin zur automatischen Herleitung von nicht genau gegebenen Informationen. Aus der Sicht des Semantic Web, dient XML als Grundlage zur Definition der Sprachen RDF und OWL.

6.2 RDF (Resource Description Framework)

XML ist eine universelle Sprache, die Austausch und Speicherung von Informationen ermöglicht und die sowohl von Menschen als auch von Maschinen problemlos gelesen und verstanden werden kann. XML macht dahingegen keine Vorschriften darüber, wie die abgelegten Informationen zu interpretieren sind^[20],[21].

Die Semantik geht bei der Speicherung von Informationen in XML verloren und die Anwendung, die eine bestimmte XML-Datei verarbeitet, muss die Struktur, beispielsweise Verschachtelung oder Attribute der Datei kennen und "wissen", welche Information an der jeweiligen Stelle hinterlegt ist und wie sie zu interpretieren ist. Folgendes Beispiel verdeutlicht diese Problematik. Soll die Information

"Joachim Löw trainiert die deutsche Nationalmannschaft"

in XML ausgedrückt werden, gibt es dafür eine Vielzahl von Möglichkeiten:

<Team name="Deutsche Nationalmannschaft">
	<Trainer>Joachim Loew</Trainer>
</Team>

<Person name="Joachim Loew">
	<trainiert>Deutsche Nationalmannschaft</trainiert>
</Person>

<Trainer>
	<Person name="Joachim Loew" team="Deutsche Nationalmannschaft" />
</Trainer>

RDF dagegen ist ein vom W3C standardisiertes Datenmodell^[22], welches Wissen auf eine strukturierte Art und Weise beschreibt, sodass Maschinen die Semantik, also die Bedeutung von Informationen, interpretieren können. Dieses Wissen wird grundsätzlich in so genannten Tripeln zusammengefasst, die aus Subjekt, Prädikat und Objekt^[23] bestehen. Das oben genannte Fußball-Beispiel ist ein solches Tripel. Eine in RDF kodierte Information stellt dabei einen Graphen und keinen Baum dar, da RDF dazu entwickelt wurde, allgemeine Beziehung von Ressourcen zu beschreiben und keine Aussage darüber zu treffen, was hierarchisch dem einen oder anderen unterzuordnen ist (Abbildung 1)^[24],[25].

Informationen in XML werden dagegen in Form eines Baums organisiert, da sich diese gut zur Organisation elektronischer Dokumente eignen, die in den meisten Fällen hierarchisch organisiert sind^[24].

6.2.1 URIs (Eindeutige Bezeichner)

Ressourcen werden in XML mit einfachen Bezeichnern wie <Team> identifiziert. Dies wirft im Grunde genommen zwei Probleme auf. Zum einen wird beispielsweise die Deutsche Fussballnationalmannschaft in einer XML-Datei mit dem Begriff "Deutsche Fussballnationalmannschaft" in einer anderen aber lediglich als "Nationalmannschaft" bezeichnet, da in der Datei ohnehin nur von Fussball die Rede ist. Zwei verschiedene Bezeichner werden also für die selbe Ressource genutzt. Diesem Problem wird damit begegnet, dass so genannte Vokabularien aufgebaut und veröffentlicht werden^[24].

Anders herum kann es passieren, dass unterschiedliche Ressourcen mit dem selben Bezeichner versehen werden, "Nationalmannschaft" kann beispielsweise sowohl die Handball- als auch die Fussballnationalmannschaft meinen. Daher nutzt das Ressource Description Framework Uniform Resource Identifier (URI), eine Verallgemeinerung der aus dem Internetgebrauch bekannten Uniform Resource Locators (URL), die Adressen zu Inhalten darstellen, die über einen Webbrowser abgerufen werden kann. Dadurch können Resourcen mit einem eindeutigen Bezeichner versehen werden, zum Beispiel http://dfb.de/Nationalmannschaft. Inhalte sind unter dieser Adresse nicht hinterlegt und diese URI ist ausschließlich zur Identifizierung der Ressource "Deutsche Fussballnationalmannschaft". Der Vorteil von diesem Vorgehen ist, dass in völlig anderen RDF-Dokumenten Informationen über die Deutsche Fussballnationalmannschaft enthalten sein können und ein Computer mit Hilfe des URI erkennen kann, dass es sich um die selbe Ressource handelt^[24].

6.2.2 Datenwerte in RDF (Literale)

Ressourcen können über so genannte Literale Datenwerte zugewiesen werden. Diese werden ohne weitere Angaben wie Zeichenketten interpretiert und heißen ungetypte Literale (Abbildung 2)^[26].

Sollen Literale bestimmten Datentyps definiert werden, so wird die URI eines Datentyps getrennt von der Zeichenfolge "^^" an den ebenfalls in Anführungsstrichen eingefassten Datentyp angehängt (Abbildung 3). In den meisten Fällen werden die in XML Schema definierten Datentypen verwendet, es können aber auch eigene Datentypen definiert werden, wobei dann die genaue Interpretation des Datentyps der verarbeitenden Anwendung obliegt^[27],[28].

6.2.3 Syntaxen für RDF

Damit RDF unabhängig von spezifischen Anwendungen gelesen und interpretiert werden kann, muss es in einer bestimmten Syntax kodiert werden und kann dabei XML und dessen Vorteile nutzen. Da RDF aber an sich "nur" eine Ansammlung von Tripeln ist, deren Reihenfolge und Hierarchie keine Rolle spielt, gibt es auch andere Möglichkeiten, RDF zu kodieren.

6.2.3.1 Turtle-Syntax

Die einfachste Syntax, um ein Tripel zu speichern, ist die Turtle Syntax, die eine Erweiterung zu der zur RDF-Recommendation gehörenden Syntax N-Triples darstellt, die wiederum auf der von Tim Berners-Lee 1998 vorgeschlagenen Notation 3 (N3) basiert. N3 besitzt komplexere Ausdrücke wie Pfade oder Regeln und stellt eine Obermenge von N-Tripels und Turtle dar. Die beiden letztgenannten beschränken sich dabei auf die Beschreibung zulässiger RDF-Graphen. Der in Abbildung 2 gezeigte Graph wird in Turtle wie folgt ausgedrückt^[30].

<http://example.org/JoachimLoew>
			<http://example.org/trainiert>	<http://dfb.de/Nationalmannschaft> .
<http://example.org/JoachimLoew>
			<http://example.org/Name>	"Joachim Loew" .
<http://dfb.de/Nationalmannschaft>
			<http://example.org/Name>	"Deutsche Nationalmannschaft" .

Dabei werden die Ressourcen Joachim Loew und die Deutsche Nationalmannschaft durch einen eindeutigen Bezeichner (URI) benannt, mit dem Attribut trainiert in Beziehung gesetzt und mit einem Punkt abgeschossen. Zusätzlich werden den beiden Ressourcen über das Attribut Name Literale zugewiesen. URIs werden über spitze Klammern und Literale mit Anführungsstrichen gekennzeichnet, wobei Leerzeichen oder Zeilenumbrüche außerhalb von URIs oder Literalen keine Rolle spielen. Die aus XML bekannten Namensräume existieren auch in der Turtle Syntax, verbessern die Lesbarkeit und werden über das Schlüsselwort @prefix registriert. Danach können Ressourcen und Attribute über den kürzen Namensraumbezeichner angesprochen werden. Anmerkung: Im Folgenden werden die @prefix-Angaben aus Platzgründen weggelassen, sofern sich keine Änderung gegenüber dem jetzt gezeigten Beispiel ergibt^[30].

@prefix ex: <http://example.org/> . 
@prefix dfb: <http://dfb.de/> . 

ex:JoachimLoew			ex:trainiert			dfb:Nationalmannschaft .

Sätze, die sich auf das selbe Subjekt beziehen, können gekürzt werden, in dem hinter das Objekt ein Semikolon gesetzt und das Subjekt weggelassen wird^[30].

ex:JoachimLoew			ex:trainiert			dfb:Nationalmannschaft ;
				ex:geborenIn			ex:Schoenau .

Des Weiteren können Tripel, in denen Subjekt und Prädikat gleich sind, verkürzt dargestellt werden, in dem hinter dem Objekt eine Komma getrennte Liste von weiteren Objekten angehängt und mit dem obligatorischen Punkt abgeschlossen wird^[30].

ex:JoachimLoew			ex:spielteFuer			ex:EintrachtFrankfurt ,
								ex:VfBStuttgart .

6.2.3.2 XML-basierte Syntax (RDF/XML)

Turtle oder ähnliche Darstellungen von RDF können zwar von Menschen und Computern gut gelesen werden, dennoch hat sich die Darstellung in XML wegen der allgemeinen Verbreitung und der Verfügbarkeit von Programmierwerkzeugen durchgesetzt^[31]. Wie oben angesprochen werden Informationen in XML hierarchisch strukturiert, Informationen in RDF aber als gerichtete Graphen. Um der XML-Syntax gerecht zu werden, muss daher eine hierarchische Repräsentation eines Graphen verwendet werden. Dafür wird jeweils das Subjekt als gruppierendes Element genutzt. Das Beispiel aus Abbildung 1 sieht in RDF/XML-Repräsentation wie folgt aus. Anmerkung: Im Folgenden werden die Angabe der XML Version und der Wurzelknoten rdf:RDF aus Platzgründen weggelassen, sofern sich keine Änderung gegenüber dem jetzt gezeigten Beispiel ergibt^[31].

<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	 xmlns:ex ="http://example.org/">

	<rdf:Description rdf:about="http://example.org/JoachimLoew">
		<ex:trainiert>
			<rdf:Description rdf:about="http://dfb.de/Nationalmannschaft" />
		</ex:trainiert>
	</rdf:Description>
 
</rdf:RDF>

Das Dokument beginnt mit der optionalen XML-Versionsangabe, die aus Kompatibilitätsgründen aber angegeben werden sollte, und dem Encoding, wobei aufgrund der immer wichtiger werdenden Internationalisierung in der Regel ein Unicode-Zeichensatz verwendet wird (zumeist UTF-8). Als Wurzelknoten dient <rdf:RDF>, wobei gleichzeitig die verwendeten Namensräume definiert werden. In diesem Fall sind das "rdf" und "ex", wobei statt des Namensraumbezeichners rdf für RDF auch ein Anderer gewählt werden könnte. Ebenfalls aus Gründen der Kompatibilität ist dies allerdings nicht empfehlenswert. Weiterhin werden Subjekt und Objekt über ein rdf:Description Element dargestellt und über den eindeutigen Bezeichner im Attribut rdf:about identifiziert. Das Prädikat wird direkt über das Element ex:trainiert ausgedrückt^[31].

Zuweisung von Datenwerte über Literale erfolgen über den Inhalt von Prädikats-Elementen, das Beispiel aus Abbildung 2 könnte daher wie folgt dargestellt werden^[31].

	<rdf:Description rdf:about="http://example.org/JoachimLoew">
		<ex:Name>Joachim Loew</ex:Name>
		<ex:trainiert>
			<rdf:Description rdf:about="http://dfb.de/Nationalmannschaft">
				<ex:Name>Deutsche Nationalmannschaft</ex:Name>
			</rdf:Description>
		</ex:trainiert>
	</rdf:Description>

Des Weiteren können Literale auch als Attribute von rdf:Description kodiert werden, um Verschachtelung zu vermeiden. Ebenso ist es möglich, die URI des Objekts direkt als Attribut rdf:resource des Prädikats zu speichern, anstatt ein geschachteltes rdf:Description Elements zu nutzen^[32].

	<rdf:Description rdf:about="http://example.org/JoachimLoew" ex:Name="Joachim Loew">
		<ex:trainiert rdf:resource="http://dfb.de/Nationalmannschaft" />
	</rdf:Description>

	<rdf:Description rdf:about="http://dfb.de/Nationalmannschaft" ex:Name="Deutsche Nationalmannschaft" />

Datentypen werden in RDF/XML nicht wie oben angegeben durch die Zeichenfolge "^^" und der URI des Datentyps an das Literal angehängt, sondern durch die Angabe der URI im Attribut rdf:datatype^[33].

	<rdf:Description rdf:about="http://example.org/JoachimLoew">
		<ex:Name rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Joachim Loew</ex:Name>
		<ex:geborenAm rdf:datatype="http://www.w3.org/2001/XMLSchema#date">1960-02-03</ex:geborenAm>
	</rdf:Description>

Mit Hilfe des Attributs rdf:type kann eine Typisierung von Subjekten und Objekten vorgenommen, das heißt sie können in gewisser Weise klassifiziert werden und dem Computer kann informales Wissen vermittelt werden, also Wissen, welches Menschen meist implizit bekannt ist^[34].

	<rdf:Description rdf:about="http://example.org/JoachimLoew">
		<rdf:type rdf:resource="http://dfb.de/Bundestrainer" />
		<rdf:type rdf:resource="http://example.org/Fussballtrainer" />
		<ex:trainiert>
			<rdf:Description rdf:about="http://dfb.de/Nationalmannschaft">
				<rdf:type rdf:resource="http://example.org/Fussballmannschaft" />
			</rdf:Description>
		</ex:trainiert>
	</rdf:Description>

Soll ein Subjekt mit mehreren Objekten in Beziehung gesetzt werden, sieht RDF das Konstrukt von Liste vor. Unterschieden wird zwischen Containern, die eine offene Liste darstellen, und Collections, die eine geschlossene Liste repräsentieren. Letztere signalisiert, dass es keine weiteren Entitäten gibt, die der Liste angehören. Container sagen aus, dass zwar die angegebenen Entitäten zur Liste gehören, es aber noch weitere geben kann, die nicht aufgeführt sind^[35]. Container werden über ein Container-Element, in diesem Fall rdf:Bag, zusammengefasst. Innerhalb des Container-Elemnts werden die Listeneinträge über das Element rdf:li aufgeführt, in deren rdf:resource Attribut die URI zum jeweiligen Objekt hinterlegt ist^[35].

	<rdf:Description rdf:about="http://dfb.de/Nationalmannschaft"> 
		<ex:Spieler>
			<rdf:Bag>
				<rdf:li rdf:resource="http://example.org/MichaelBallack" />
				<rdf:li rdf:resource="http://example.org/MiroslavKlose" />
				<rdf:li rdf:resource="http://example.org/MarioGomez" />
				<rdf:li rdf:resource="http://example.org/LukasPodolski" />
			</rdf:Bag>
		</ex:Spieler>
	</rdf:Description>

Es existieren drei verschiedene Container-Elemente^[35]:

• rdf:Bag: Enthält eine ungeordnete Menge an Listeneinträge. Die Reihenfolge, in der die Listeneinträge aufgeführt sind, spielen keine Rolle. Beispiel: Spieler in einer Fussballmannschaft.
• rdf:Seq: Enthält eine geordnete Menge an Listeneinträgen. Die Reihenfolge, in der die Listeneinträge aufgeführt sind, spielen eine Rolle. Beispiel: Bundesliga-Tabelle.
• rdf:Alt: Enthält eine Menge an Listeneinträgen, die Alternativen darstellen. Beispiel: Mögliche Torhüter einer Fussballmannschaft.

Collections werden mit Hilfe des Attributs parseType mit dem Wert Collection ^[36] am Prädikat bzw. der Eigenschaften gekennzeichnet und enthalten die Mitglieder der Collection als normale Objekte^[37].

	<rdf:Description rdf:about="http://dfb.de/Nationalmannschaft">
 		<ex:Torhueter parseType="Collection">
			<rdf:Description rdf:about="http://example.org/ReneAdler" />
			<rdf:Description rdf:about="http://example.org/TimWiese" />
 		</ex:Torhueter>
 	</rdf:Description>

6.3 RDFS (RDF Schema)

In RDF ist es möglich, Wissen anhand von Subjekt, Prädikat bzw. Eigenschaft und Objekt zu speichern, grundsätzlich kann so jedes Faktenwissen gespeichert werden. RDF Schema gehört wie RDF ebenfalls zu den W3C Recommendations und ist, wie der Name sagt, die Schemasprache von RDF^[38].

Grundsätzlich wird in Schemasprachen Informationen über das eigentliche Dokument oder den Betrachtungsgegenstand gespeichert. XML Schema definiert beispielsweise, wie ein XML-Dokument korrekterweise auszusehen hat und so können XML Parser automatisch entscheiden, ob ein gegebenes XML-Dokument dem Schema entspricht, also valide ist, oder eben nicht. Auch im Umfeld von relationalen Datenbanken werden Schemata verwendet. Dort ist in der Tabellenstruktur hinterlegt, welche Spalten existieren und welche Datentypen diese enthalten^[39].

Bei RDF Schema verhält es sich ähnlich. In RDF Schema werden Informationen hinterlegt, die es erlauben, die Bedeutung des in RDF kodierten Wissens verstehen zu können, das heißt mit Hilfe von Schlussfolgerungen weiteres, informales Wissen erschließen zu können. In RDF kann grundsätzlich jede Aussage über alles gespeichert werden. RDF liefert aber keine Information darüber, wie einzelne Aussagen zu interpretieren sind. Daher definiert RDFS einige Sprachelemente, deren Bedeutung im Standard definiert ist^[39].

Es existieren zwei Arten von Schemasprachen. Klassischerweise wurden Daten und Schema in unterschiedlichen Formaten gespeichert. In der Anfangszeit von XML wurde mit Document Type Definitions (DTD) gearbeitet, die selbst nicht in XML sondern einem eigenen Format gespeichert werden. Datenbankschemata werden in der Regel selbst nicht in Tabellen sondern in einem datenbankspezifischem Organisationsformat abgelegt. Ein modernerer Ansatz ist es, das Format der Daten auch für die Definition des Schemas zu nutzen. Dieser wurde bei der Definition von XML Schema verfolgt, bei dem das Schema selbst XML darstellt. Der Ansatz, Daten und Schema im selben Format zu speichern wurde bei RDF von Anfang an verfolgt und Schemainformationen von RDFS stellen valide RDF Tripels dar. Das W3C Konsortium hat dabei nicht nur aus den Problemen mit XML und DTD (vergleiche Link) gelernt und ein technologisch sinnvollen Standard entworfen, sondern auch die Grundlage dafür gelegt, Schemainformationen über das semantische Web selbst zu verteilen, sollte das einmal nötig werden. Auf die wichtigsten Sprachelemente wird im Folgenden näher eingegangen, wobei aus Platzgründen die übersichtlichere Turtle-Syntax genutzt wird. Grundsätzlich lassen sich die Beispiele unter Nutzung des oben genannten Schemas natürlich auch in RDF/XML darstellen, wobei als Namensraumbezeichner rdfs mit der Zeichenfolge xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" registriert werden muss^[39].

6.3.1 Definition von Klassen

Mit Hilfe des Konstrukts rdfs:Class kann die Zugehörigkeit zu einer Menge beschreiben werden, der Menge der Klassen. Wie oben beschrieben werden Aussagen in RDFS ebenfalls in RDF Syntax kodiert und so können unter Einsatz des schon aus RDF bekannten rdf:type Prädikats folgende Tripel gebildet werden^[39].

ex:Torhueter			rdf:type			rdfs:Class .
ex:Trainer			rdf:type			rdfs:Class .
ex:Stadion			rdf:type			rdfs:Class .

Mit dem Wissen des RDFS Standards kann eine Maschine so ableiten, dass Torhüter eine Klasse repräsentieren^[39].

6.3.2 Definition von Klassenhierarchien

rdfs:subClassOf erlaubt es, Ressourcen Unterklassen zuzuweisen und so Klassenhierarchien aufzubauen, die weitere Schlussfolgerungen zulassen^[40].

ex:Abwehrspieler		rdfs:subClassOf			ex:Feldspieler .
ex:ArneFriedrich		rdf:type			ex:Abwehrspieler .

Aus den gegebenen Tripeln kann abgeleitet werden, dass Arne Friedrich auch ein Feldspieler sein muss, das also Folgendes ebenso gilt^[40].

ex:ArneFriedrich		rdf:type			ex:Feldspieler .

Dean Allemang und Jim Hendler vergleichen dieses Prinzip in ihrem Buch "Semantic Web for the Working Ontologist" mit If/Then Konstrukten aus Programmiersprachen: Wenn eine Resource Mitglied einer Unterklasse ist, dann ist sie auch gleichzeitig Mitglied der Oberklasse. In RDFS nicht enthalten ist eine Methode, die das Verhalten der aus vielen Programmiersprachen bekannten Else Konstruktion abbildet. Da RDFS kein Konstrukt vorsieht, mit dem ausgedrückt werden kann, dass eine Resource nicht Mitglied einer bestimmten Klasse ist, kann aus der fehlenden Mitgliedschaft keine Schlussfolgerung gezogen werden. Solch eine Möglichkeit haben erst ausdrucksfähigere Sprachen wie zum Beispiel die im Weiteren behandelte OWL^[41].

6.3.3 Definition von Eigenschaftshierarchien

Auch für Verben bzw. Eigenschaften sieht RDFS eine Hierarchie vor. Wie bei Klassen sind die spezifischen Eigenschaften unten in der Hierarchie und die Allgemeineren oben angesiedelt. Folgendes Beispiel verdeutlicht den Gebrauch von rdfs:subPropertyOf^[42].

Aus den Tripeln

ex:AbwehrBei			rdfs:subPropertyOf		ex:spieltFuer .
ex:MittelfeldBei		rdfs:subPropertyOf		ex:spieltFuer .
ex:LinkesMittelfeldBei		rdfs:subPropertyOf		ex:MittelfeldBei .
ex:RechtsMittelfeldBei		rdfs:subPropertyOf		ex:MittelfeldBei .

ergibt sich die in Abbildung 4 dargestellte Eigenschaftshierarchie^[1].

Daher kann aus der Aussage

ex:BastianSchweinsteiger	ex:RechtesMittelfeldBei		dfb:Nationalmannschaft .
ex:PiotrTrochoswki		ex:LinksMittelfeldBei		dfb:Nationalmannschaft .

abgeleitet werden, dass ebenso

ex:BastianSchweinsteiger	ex:MittelfeldBei		dfb:Nationalmannschaft .
ex:PiotrTrochoswki		ex:MittelfeldBei		dfb:Nationalmannschaft .

und

ex:BastianSchweinsteiger	ex:spieltFuer			dfb:Nationalmannschaft .
ex:PiotrTrochoswki		ex:spieltFuer			dfb:Nationalmannschaft .

gilt^[1].

6.3.4 Weitere Ableitungen aus der Nutzung von Eigenschaften

rdfs:domain und rdfs:range können dazu verwendet werden, Aussagen über die Relation von Eigenschaften zu Subjekten bzw. Objekten zu treffen. Im Gegensatz dazu steht das eben eingeführte Konstrukt rdfs:subPropertyOf, welches Aussagen darüber trifft, wie Eigenschaften untereinander korrelieren. Wenn eine Eigenschaft in einem gegebenen Tripel verwendet wird und ebenfalls mit Hilfe von rdfs:domain bzw. rdfs:range eine Aussage über diese Eigenschaft existiert, kann abgeleitet werden, zu welcher Klasse das Subjekt, bzw. das Objekt gehören muss. Die Unterschiede zwischen den drei Konstrukten sollen Tabelle 1 und die folgenden Beispiele verdeutlichen^[43].

Beschreibt Beziehung	rdfs:subPropertyOf	rdfs:domain	rdfs:range
zwischen	Eigenschaft	Eigenschaft	Eigenschaft
und	Eigenschaft	Subjekt	Objekt

Tab. 1 Gegenüberstellung rdfs:subPropertyOf, rdfs:domain und rdfs:range^[1].

Wurden die Aussagen

ex:AbwehrBei			rdfs:domain			ex:AbwehrSpieler .
ex:ArneFriedrich		ex:AbwehrBei			dfb:Nationalmannschaft .

über ex:ArneFriedrich und ex:AbwehrSpieler getroffen, so kann geschlussfolgert werden, dass Arne Friedrich ein Abwehrspieler ist^[43].

ex:ArneFriedrich		rdf:type			ex:AbwehrSpieler .

Analog kann rdfs:range dazu genutzt werden, aus den Aussagen

ex:AbwehrBei			rdfs:range			ex:Fussballmannschaft .
ex:ArneFriedrich		ex:AbwehrBei			dfb:Nationalmannschaft .

zu schlussfolgern, dass die Nationalmannschaft eine Fussballmannschaft sein muss^[43].

dfb:Nationalmannschaft		rdf:type			ex:Fussballmannschaft .

6.3.5 Anmerkungen zu RDFS-Dokumenten

Um weitergehende, nicht zur eigentlichen Semantik gehörende Informationen in ein RDFS-Dokument einzufügen, können die Konstrukte rdfs:comment und rdfs:label genutzt werden. Diese Informationen dienen in erster Linie dem Menschen, der ein RDFS-Dokument gegebenenfalls nutzen will. rdfs:label bietet die Möglichkeit, einer Ressource einen besser lesbaren Namen zu geben. Dies kann beispielsweise dazu genutzt werden, in einer graphischen Repräsentation das Label anstelle des URI zu verwenden^[44].

dfb:Nationalmannschaft		rdfs:label			"Deutsche Fussball Nationalmannschaft" .
ex:Michael Ballack		rdfs:label			"Michael Ballack" .

rdfs:comment ist vorgesehen, um Ressourcen mit Kommentaren zu versehen, die deutlich machen, was mit einer bestimmten Ressource genau gemeint ist. Beispielsweise könnte ex:Tor sowohl das Gestell mit Pfosten, Latte und Netz meinen, aber genauso das erzielte Tor, wofür der Ball innerhalb des Torgestells hinter die Linie gebracht werden muss. Um ein Vokabular ohne Missverständnisse nutzen zu können, sind ausdrucksvolle Kommentare äußerst wichtig^[44].

ex:Tor			rdfs:comment		"Gestell mit Pfosten, Latte und Netz, das in einem Sportspiel dazu dient, den Bereich zu markieren,
 						in den der Ball gebracht werden muss." .
ex:ErzieltesTor		rdfs:comment 		"Akt, bei dem der Ball innerhalb des Torgestells hinter die Linie gebracht wird." .

Mit Hilfe von rdfs:seeAlso ist es möglich, weitergehende Informationen zu einer Ressource zu hinterlegen, die bei der Interpretation hilfreich sein könnten. In der Regel sind dies Weblinks^[44].

ex:Nationalmannschaft		rdfs:seeAlso			<http://www.dfb.de/index.php?id=30> .

6.3.6 Abgrenzung zwischen RDF und RDFS

Nachdem nun die wichtigsten Sprachelemente von RDF und RDFS beschrieben sind, zeigt Abbildung 5 die Abgrenzung zwischen RDF und RDFS. Vereinfacht kann festgehalten werden, dass in RDF das Wissen an sich ausgedrückt wird. RDFS dagegen bietet die Möglichkeit, quasi Wissen über das Wissen zu definieren, beispielsweise was mit dem Prädikat ex:trainiert verbunden werden darf^[45].

6.4 OWL (Web Ontology Language)

RDFS als Ontologiesprache bietet bereits eine Vielzahl von Möglichkeiten, Wissen zu formalisieren und zu strukturieren, stößt aber in einigen Fällen an seine Grenzen, da bei der Entwicklung von RDFS wurde darauf geachtet, dass mit Ableitungsalgorithmen auch große Graphen sinnvoll performant und einfach interpretiert werden können^[46]. Beispielsweise gibt es in RDFS keinen Weg auszudrücken, dass für eine Ressource etwas nicht gilt. Auch kann eine fehlende Aussage aufgrund der Open-World-Assumption (OWA), also der Annahme, dass eine Wissensbasis potentiell unvollständig ist^[47], nicht als Grundlage für die Annahme dienen, dass etwas nicht gilt. Beispielsweise ist es in RDFS unmöglich die Tatsache auszudrücken, dass ein Spieler nicht gleichzeitig Trainer sein kann^[46].

ex:MichaelBallack		rdf:type		ex:Spieler .
ex:MichaelBallack		rdf:type		ex:Trainer .

Eine Ontologiesprache, die über die Ausdrucksmöglichkeiten von RDFS hinaus geht, ist die Web Ontology Language, die im Februar 2004 vom W3C standardisiert^[48] wurde und mit OWL abgekürzt wird. Der Buchstabendreher in der Abkürzung ist von Tim Finin, einem Professor der Computerwissenschaften der University of Maryland, Baltimore County (UMBC), in einer Mail^[49] mit einer Reihe von Begründung vorgeschlagen worden, unter anderem dass OWL gegenüber WOL leichter auszusprechen sei und Eulen, im Englischen owl, allgemein mit Weisheit in Verbindung gebracht würden. Bei der Entwicklung von OWL wurde ein Hauptaugenmerk auf das Gleichgewicht zwischen Ausdrucksfähigkeit der Sprache einerseits und möglichst effizienter Schlussfolgerung, also Skalierbarkeit großer Ontologien, andererseits gelegt. Mit steigender Ausdrucksfähigkeit steigt auch der (Rechen-)Aufwand zur Ableitung impliziten Wissens. Es existieren drei verschiedene Teilsprachen von OWL, die jeweils an Ausdrucksstärke zunehmen: OWL Lite, OWL DL (DL steht für Description Logic) und OWL Full. Im Gesamtkontext mit den bisher beschriebenen Sprachen zur Realisierung des Semantischen Webs ergibt sich die in Abbildung 6 dargestellte Rangfolge der Ausdrucksfähigkeit^[46].

6.4.1 Syntax

Grundsätzlich wird auch OWL in RDF(S) kodiert und dies ist auch gleichzeitig die Syntax, in der OWL primär ausgedrückt wird. Im Folgenden wird in Beispielen daher jetzt RDF/XML verwendet. Dennoch sei darauf hingewiesen, dass noch weitere Syntaxen existieren:

• OWL/XML Presentation Syntax, eine nicht RDF-konforme XML Syntax um OWL für Menschen lesbarer zu speichern^[50].
• OWL/Semantics and Abstract Syntax, eine abstrakte Syntax die noch kompakter und lesbarer als OWL/XML und RDF/XML ist^[51].
• Eine auf UML basierende graphische Syntax^[52].

OWL in RDF/XML beginnt wie jedes RDF Dokument mit dem rdf:RDF Wurzelknoten und der Registrierung der Namensraumbezeichner^[53].

<rdf:RDF 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#"> 

Darauf kann ein OWL-Header folgen, in dem die Möglichkeit besteht, andere Ontologien zu importieren und Angaben zu vorherigen Versionen zu machen. Diese Angaben werden im Element owl:Ontology gemacht. Bis auf owl:imports haben alle Angaben informellen Charakter. owl:imports importiert, wie der Name sagt, Ontologien aus den anderen Namensräumen und diese verhalten sich so, wie als wäre der Inhalt in der Ontologie selbst enthalten. Der Import ist dabei transitiv, das heißt importiert die importierte Ontologie weitere Ontologien, gelten diese auch für die ursprüngliche Ontologie^[53].

	<owl:Ontology rdf:about="">
		<rdfs:label>Fussball Ontologie</rdfs:label>
		<rdfs:comment>Enthält Ontologien rund um das Thema Fußball</rdfs:comment>
		<owl:versionInfo rdf:resource="http://example.org/Fussball-v2/" />
		<owl:priorVersion rdf:resource="http://example.org/Fussball-v1/" />
		<owl:imports rdf:resource="http://example.org/Sport" />
	</owl:Ontology>

Darüberhinaus definiert OWL weitere Sprachkonstrukte, wobei auf die Wichtigsten im Weiteren eingegangen wird.

6.4.2 Elemente zu Klassen

OWL-Klassen können mit Hilfe des Konstrukts owl:Class ausgedrückt werden und es können über das bereits bekannte rdfs:subClassOf Klassenhierarchien gebildet werden, da owl:Class eine Unterklasse von rdfs:Class darstellt. Das folgende Beispiel drückt aus, dass Fussballspieler eine Unterklasse von Sportler ist^[54].

	<owl:Class rdf:ID="Fussballspieler">
		<rdfs:subClassOf rdf:resource="#Sportler" />
	</owl:Class>

Über die Angaben owl:disjointWith und owl:equivalentClass kann eine Diskunktheit bzw. eine Äquivalenz ausgedrückt werden. Das Beispiel beschreibt, dass Fussballspieler weder Handball- noch Eishockeyspieler sind und dass Fussballer äquivalent zu Fussballspieler sind, also Synonyme darstellen^[54].

	<owl:Class rdf:about="#Fussballspieler">
		<owl:disjointWith rdf:resource="#Handballspieler" />
		<owl:disjointWith rdf:resource="#Eishockeyspieler" />
		<owl:equivalentClass rdf:resource="#Fussballer" />
	</owl:Class>

owl:Thing und owl:Nothing sind zwei vom OWL-Standard definierte Klassen. owl:Thing enthält alles, ist also Oberklasse von allem, und owl:Nothing enthält nichts, jede andere Klasse ist also Oberklasse davon^[54].

6.4.3 Elemente zu Eigenschaften

OWL unterscheidet zwei verschiedene Arten von Eigenschaften explizit, wobei diese grundsätzlich auch in RDF(S) unterschieden werden, es aber dort keine Sprachkonstrukte existieren, die diese Unterscheidung ausdrücken. Zum Einen Eigenschaften, die Objekte mit Literalen verbindet, also Ressourcen Datenwerte zuordnet. Ein Beispiel dafür ist Alter, Geburtstdatum oder Name und diese Eigenschaften werden in OWL durch den Ausdruck owl:DatatypeProperty gekennzeichnet^[55].

	<owl:DatatypeProperty rdf:ID="Alter">
		<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#nonNegativeInteger" />
	</owl:DatatypeProperty>

Zum Anderen verbinden Eigenschaften zwei Ressourcen miteinander. In dieser Funktion tritt die Eigenschaft als Verb auf, wie zum Beispiel trainiert oder spieltFuer^[55].

	<owl:ObjectProperty rdf:ID="trainiert">
		<rdfs:domain rdf:resource="#Mannschaft" />
		<rdfs:range rdf:resource="#Trainer" />
	</owl:ObjectProperty>

Grundsätzlich können mehrere Angaben von rdfs:domain und rdfs:range gemacht werden, wobei dann die Schnittmenge aller Angaben verwendet wird. Des Weiteren erlaubt OWL, das Gegenteil einer ObjectProperty über die Angabe owl:inverseOf zu definieren^[55].

	<owl:ObjectProperty rdf:ID="trainiert">
		<rdfs:domain rdf:resource="#Mannschaft" />
		<rdfs:range rdf:resource="#Trainer" />
		<owl:inverseOf rdf:resource="#trainiertVon" />
	</owl:ObjectProperty>

Wie bei Klassen kann in OWL unter Einsatz von owl:equivalentProperty auch ausgedrückt werden, dass Eigenschaften äquivalent sind^[55].

	<owl:ObjectProperty rdf:ID="spieltFuer">
		<owl:equivalentProperty rdf:resource="#kicktBei" />
	</owl:ObjectProperty>

6.4.4 Restriktionen von Eigenschaften

Detaillierte Einschränkungen, welche Klassen über Eigenschaften verbunden werden dürfen, können über diverse in OWL eingeführte Sprachkonstrukte ausgedrückt werden. Soll beispielsweise beschrieben werden, dass in ein Fussballstadion nur friedliche Fans gelassen werden sollen, muss die Klasse der Fussballstadien zur Unterklasse von owl:Restriction gemacht werden, die die Elemente owl:onProperty zur Definition der verbindenden Eigenschaften und owl:allValuesFrom zur Definition der erlaubten Objektklassen enthalten^[56].

	<owl:Class rdf:about="#FussballStadion">
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty rdf:resource="#wirdBesuchtVon" />
				<owl:allValuesFrom rdf:resource="#FriedlicherFan" />
			</owl:Restriction>
		</rdfs:subClassOf>
	</owl:Class>

Soll ausgedrückt werden, dass nur eine bestimmte Instanz einer Klasse in der Einschränkung enthalten sein soll, kann statt owl:allValuesFrom owl:hasValue verwendet werden. Über owl:someValuesFrom kann ausgedrückt werden, dass mindestens ein Exemplar der angegebenen Klasse in der in owl:onProperty angegebenen Eigenschaft enthalten sein muss. So kann ausgedrückt werden, dass eine Mannschaft mindestens von einem Trainer trainiert werden muss^[56].

	<owl:Class rdf:about="#Fussballmannschaft">
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty rdf:resource="#wirdTrainiertVon" />
				<owl:someValuesFrom rdf:resource="#Trainer" />
			</owl:Restriction>
		</rdfs:subClassOf>
	</owl:Class>

Kardinalitäten können über die Schlüsselwörter owl:maxCardinality bzw. owl:minCardinalty angegeben werden und so kann zum Beispiel die Aussage getroffen werden, dass jede Fussballmannschaft mindestens einen oder mehrere Trainer haben muss^[56].

	<owl:Class rdf:about="#Fussballmannschaft">
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty rdf:resource="#wirdTrainiertVon" />
				<owl:minCardinalty rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinalty>
			</owl:Restriction>
		</rdfs:subClassOf>
	</owl:Class>

Genauso könnte mit Hilfe von owl:maxCardinality ausgedrückt werden, dass ein Stadion nicht mehr als 60.000 Besucher fasst. Damit beschrieben werden kann, dass mit einer Eigenschaft beispielsweise genau 2 Instanzen verbunden sein dürfen, kann entweder das Konstrukt owl:cardinalty genutzt oder owl:max- und owl:minCardinality auf den gleichen Wert gesetzt werden^[57].

6.4.5 Mengen und Aufzählungen

Komplementär-, Vereinigungs- und Schnittmengen von Klassen lassen sich mit den Konstrukten owl:complementOf, owl:unionOf und owl:intersectionOf ausdrücken. So beschreibt das folgende Beispiel die Tatsache, dass die Menge der Spieler nicht gleichzeitig in der Menge der Trainer sein können. Dabei wird über eine rdfs:subClassOf-Beziehung eine Beziehung mit der Komplementärmenge gebildet^[58].

	<owl:Class rdf:about="#Spieler">
		<rdfs:subClassOf>
			<owl:Class>
				<owl:complementOf rdf:resource="#Trainer" />
			</owl:Class>
		</rdfs:subClassOf>
	</owl:Class>

Das folgende Beispiel erzeugt eine neue Klasse, dass die Vereinigungsmenge von Trainer und Spielern darstellt^[58].

	<owl:Class rdf:ID="Fussballmannschaft">
		<owl:unionOf rdf:parseType="Collection">
			<owl:Class rdf:about="#Spieler" />
			<owl:Class rdf:about="#Trainer" />
		</owl:unionOf>
	</owl:Class>

Analog zu owl:unionOf können mit Hilfe von owl:intersectionOf Schnittmengen gebildet werden. Abschließende Aufzählungen werden mit dem Element owl:oneOf gekennzeichnet. Im Folgenden wird definiert, dass Joachim Löw und Hans-Dieter Flick die Trainer der deutschen Nationalmannschaft sind^[59].

	<owl:Class rdf:about="#TrainerNationalmannschaft">
		<owl:oneOf rdf:parseType="Collection">
			<Person rdf:id="JoachimLoew" />
			<Person rdf:id="HansDieterFlick" />
		</owl:oneOf>
	</owl:Class>

Entgegen der Logik in Datenbanken, wo eindeutige Kennzeichner als unterschiedliche Instanzen interpretiert werden, wird in RDF und ebenso in OWL nicht grundsätzlich angenommen, dass Instanzen unterschiedlich sind, nur weil Name, ID oder URI dies vermuten lassen. Daher führt OWL die Konstrukte owl:AllDifferent, owl:distinctMembers und owl:differentFrom ein^[60]. So kann mit

	<Person rdf:id="TheoZwanziger">
		<owl:differentFrom rdf:resource="#JoachimLoew">
	</Person>

aufgezeigt werden, dass Theo Zwanziger und Joachim Löw nicht die gleichen Personen meint. Aus der Kombination der beiden vorherigen Beispiele kann zusätzlich noch folgende Ableitung gebildet werden: Theo Zwanziger kann kein Trainer der deutschen Nationalmannschaft sein. Um die Unterschiedlichkeit mehrerer Instanzen effizienter auszudrücken, sieht OWL die Konstruktion owl:AllDifferent und owl:distinctMembers vor. Anzumerken ist, dass owl:distinctMembers nicht ohne owl:AllDifferent verwendet werden darf^[60].

	<owl:AllDifferent>
		<owl:distinctMembers rdf:parseType="Collection">
			<Person rdf:about="#JoachimLoew" />
			<Person rdf:about="#HansDieterFlick" />
			<Person rdf:about="#TheoZwanziger" />
		</owl:distinctMembers>
	</owl:AllDifferent>

6.4.6 Vergleich zwischen den OWL Versionen

OWL Full enthält alle in OWL, RDFS und RDF definierten Sprachkonstrukte in jeder Kombination, solange das Ergebnis valides RDF ist. Die volle Variante ist sehr ausdrucksstark, aber aufgrund der fehlenden Typtrennung unentscheidbar^[61],[62]. Entscheidbarkeit heißt, dass mit einem Algorithmus ausgewertet werden kann, ob eine Aussage aus einer Ontologie geschlussfolgert werden kann. Bisher wird OWL Full von Softwareprodukten allerdings kaum unterstützt^[63].

OWL DL ist eine Teilsprache von OWL Full und bringt einige Einschränkungen mit sich, die Entscheidbarkeit erlauben^[64],[65].

• Nur in OWL DL explizit erlaubte RDF(S) Elemente dürfen verwendet werden. Beispielsweise ist die Nutzung von rdfs:Class und rdf:Property verboten.
• Typtrennung: Ressourcen dürfen nur einen Typ gleichzeitig darstellen, das heißt entweder eine Klasse, eine Objekteigenschaft, eine Typeigenschaft, ein Literal oder ein Sprachkonstrukt, das im Standard von OWL, RDFS oder RDF enthalten ist, niermals mehr als eines.
• Diese Trennung muss zusätzlich explizit dargestellt werden. Soll beispielsweise eine Klasse als Oberklasse definiert werden, so muss diese als Klasse definiert werden.
• Konstrukte, die für Objekteigenschaften vorgesehen sind, dürfen nicht für Typeigenschaften verwendet werden (zum Beispiel owl:inverseOf).
• Abstrakte Rollen dürfen nur als rdfs:domain und rdfs:range von owl:equivalentClass oder owl:disjointWith und nur als rdfs:range von rdfs:subClassOf genutzt werden, damit die Ontologie entscheidbar ist.

OWL Lite ist eine Teilsprache von OWL DL, wurde für den einfachen Aufbau von Ontologien entwickelt und bringt daher folgende weitere Einschränkungen mit sich^[64],[65].

• Der Einsatz von owl:oneOf, owl:disjointWith, owl:unionOf, owl:complementOf, und owl:hasValue ist verboten.
• Kardinalitäten dürfen lediglich 0 und 1 enthalten.
• Das Subjekt von owl:equivalentClass und rdfs:subClassOf und das Objekt von rdfs:range muss einen Klassennamen enthalten. Ebenso sind zusätzlich Rollenrestriktionen bei Objekten von owl:allValuesFrom, owl:someValuesFrom und rdf:range.
• owl:equivalentClass darf nicht zwischen abstrakten Klassen verwendet werden.

6.5 Vokabulare

Semantic Webs werden erst möglich, sobald sich Angehörige von Interessengruppen (z.B. Verlage und Autoren, Musiker oder Forscher) auf ein gemeinsames Vokabular – einen gemeinsamen Namensraum – zur Beschreibung und Darstellung ihrer Informationen einigen und diese auch nutzen. Um diesen Umstand zu beseitigen wurden und werden weiterhin zum Teil sehr spezialisierte Namensräume definiert^[66]. Einen umfassenden Überblick über bereits verfügbare und genutzte Schemata/Namensräume liefern die Internetseiten http://schemaweb.info und http://pingthesemanticweb.com/. Mittels dieser Namensräume können gleichartige Informationen in Zusammenhang gebracht werden.

Bei den im Folgenden kurz vorgestellten Vokabularen handelt es sich um Schemata die sich in häufiger Verwendung wiederfinden. Obgleich bereits die unterschiedlichsten Vokabulare für verschiedene Einsatzzwecke definiert sind, ist eine Definition eigener Bezeichner dennoch teilweise unabdingbar^[67],[68].

6.5.1 Dublin Core

Das Metadatenschema Dublin Core ist ein standardisiertes Schema aus 15 Kern- und weiteren Unterelementen. Dublin Core dient in erster Linie der Beschreibung von Dokumenten (Informationsressourcen), insbesondere für digitale Bibliotheken. Über die Beschreibung von z.B. Autor, Mitwirkenden und Verleger hinaus ist es auch möglich Bilder, Filme und Termine mittels DC zu beschreiben^[69],[70].

6.5.2 FOAF

FOAF (friend-of-a-friend) stellt ein Vokabular zur Verfügung, mittels dessen nicht nur Personen, ihre Interessen und Aktivitäten beschrieben werden können, sondern auch Beziehungen von Personen zueinander. Die mit FOAF zur Verfügung gestellten Attribute lassen sich in die folgenden fünf Kategorien 'FOAF Basics', 'Personal Info', 'Online Accounts / IM', 'Projects and Groups' und 'Documents and Images' unterteilen^[71],[72].

6.5.3 MusicBrainz und MusicBrainz XML Metadata Format

Das MusicBrainz Schema stellt Klassen für den Bereich der Musik W3C-konform zur Verfügung. Es werden Bezeichner wie Album, Artist u.a. angeboten. Allerdings hat sich dieses Schema in der Praxis als nicht akzeptanzfähig erwiesen. Daher wurde ein Folgemetadatenformat „MusicBrainz XML Metadata Format“ (MMD) entwickelt, welches ebenfalls Bezeichner rund um den Bereich Musik beinhaltet^[73],[74].

6.5.4 DOAP

DOAP (Description of a Project) stellt ein RDF-Metadatenvokabular zur Verfügung um Softwareprojekte zu beschreiben und wird insbesondere im Open Source-Umfeld eingesetzt. Mittels DOAP lassen sich Projekte und damit verbundene Ressourcen (einschließlich der Teilnehmer-und Web-Ressourcen) beschreiben. Es bietet Interoperabilität mit anderen Metadatenschemata wie FOAF oder Dublin Core. Im Rahmen von DOAP sind drei Klassen definiert, wobei die Klasse „Project“ die Basis darstellt^[75],[76].

6.5.5 DOAC

DOAC (Description of a Career) stellt ein RDF-Metadatenvokabular zur Beschreibung von beruflichen Fähigkeiten sowie Werdegängen zur Verfügung. Ziel des Einsatzes von DOAC-Informationen ist es, Fachkräfte anforderungsgerecht im Internet auffindbar zu machen^[77].

6.5.6 vCard

Das vCard-Schema stellt Klassen (Bezeichner) für elektronische Visitenkarten zur Verfügung. Es handelt sich hierbei um ein standardisiertes Schema. Mittels vCard werden z.B. häufig Telefonverzeichnisse in Mobiltelefonen geführt. Unterschiedliche Anwendungen – insbesondere im Bereich der digitalen Kommunikation (E-Mailclients, Personal Information Manager (PIM) und Groupware-Anwendungen) – bieten Im- und Exportfunktionen für Daten/Dateien im vCard-Format^[78].

6.5.7 SIOC

SIOC (Semantically Interlinked Online Communities) stellt ein RDF-Vokabular zur Beschreibung von Informationen innerhalb von Onlinecommunities zur Verfügung. Diese Communities können z.B. in Form von Blogs, Foren, Newsgroups und Mailinglisten realisiert sein. Mittels SIOC-bezeichneten Informationen können die Inhalte von verschiedenen Communities plattformunabhängig in Zusammenhang gebracht werden^[79].

6.6 Einbindung von Metadaten

Die bisher beschriebenen Methoden haben aufgezeigt, wie Metadaten definiert und abgefragt werden können. Die reine Existenz von diesen Metadaten liefert zwar den Grundstock für das Semantic Web, allerdings liegen Informationen im Internet im Wesentlichen als Dokument (HTML-Seite) und als Multimediainformation vor und es gilt eben diese Inhalte mittels dieser Metadaten zu beschreiben und in Zusammenhang zu bringen. Das Zusammenbringen von Dokumenten und Inhalten mit dazugehörigen Metadaten wird semantische Annotation genannt. Die Verknüpfung des annotierten Dokuments mit seinen Metadaten kann über verschiedene Methoden erfolgen^[80].

6.6.1 Eingebettete Metadaten

Eingebettete Metadaten (engl. embedded data) befinden sich im Dokument selbst. Sie sind im Quelltext des Dokuments enthalten und werden von Browsern für den User nicht zur Anzeige gebracht. Der wesentliche Vorteil dieser Methode beruht darin, dass die Metadaten unmittelbar im Dokument vorhanden sind und so auch ohne Zugriff auf das Internet zur Verfügung stehen^[80].

Bei der Einbettung von Metadaten ist darauf zu achten, dass die Validierungsvorschriften (HTML, XHTML o.ä.) des Dokuments nicht verletzt werden. Um diesem Umstand Rechnung zu tragen wurde vom W3C die RDFa-Spezifikation entwickelt, welche auch gleichzeitig die Empfehlung des W3C zur Einbettung von Metadaten darstellt. Mit RDFa ist es möglich XHTML 1.1 konforme Dokumente um maschinenlesbare Metadaten anzureichern^[81],[82].

Neben RDFa existiert eine weitere Syntax eRDF (embedded RDF) zur direkten Einbettung von Metadaten in Dokumente^[83].

6.6.2 Verlinkte Metadaten

RDF-Metadaten separat in einem eigenen Dokument, im Folgenden als Metadokument bezeichnet, zu speichern und mittels URI auf dieses Metadokument zu verweisen, wird als RDF autodiscovery Link bezeichnet. Die Verknüpfung zwischen annotiertem Dokument und Metadokument kann über zwei verschiedene Methoden erfolgen. Zum einen kann das Dokument ein Link auf das Metadokument besitzen und somit selbst intern auf das Metadokument referenzieren, zum Anderen ist eine externe Referenzierung möglich. Bei der externen Referenzierung wird das Metadokument auf das annotierte Dokument verlinkt^[84],[85].

Elemtentar für die Verlinkung der Metadaten mittels eines Metadokuments ist, dass die Programme (z.B. Webbrowser) die die Dokumente verarbeiten, auch über Zugriff auf das Metadokument verfügen. Daher ist bei Offline-Inhalten die Annotation über eingebettete Metadaten zu bevorzugen^[85].

6.7 SPARQL

Bei SPARQL (SPARQL Protocol and RDF Query Language) handelt es sich um eine deskriptive Anfragesprache, welche für RDF-Datenpools optimiert ist. Neben der Anfragesprache wird mit SPARQL auch ein Protokoll (WSDL-Interface) zum Austausch von Nachrichten auf Basis von XML zur Verfügung gestellt. Das Protokoll wird im Folgenden nicht weiter betrachtet. SPARQL ist die vom W3C entwickelte und empfohlene Anfragesprache für semantische web-Anwendungen. Es ähnelt stark der Datenbanksprache SQL, ist jedoch für den Einsatzzweck (Abfragen auf Wissensbasen) auf RDF-Tripel-Datenmodelle optimiert. So wird erst mit Verwendung von SPARQL ein effizienter Umgang mit dem Semantic Web möglich^[86]. So ist eine Suche aus einem RDF-Graph nach einer oder mehrere Teilmengen anhand bestimmter Bedingungen realisierbar. Als Ergebnis können sowohl Listen als auch RDF ausgegeben werden.

Die aktuelle Version von SPARQL besitzt lediglich Abfragefunktionen, so sind Funktionen zur Datenpflege (wie Inserts, Updates oder Deletes analog SQL) nicht verfügbar. Das W3C war sich dieser Lücken bei der Verabschiedung durchaus bewusst^[87]. Um diese Lücken zu schließen wurde bereits die Arbeit an der SPARQL Update Language (teilweise auch als SPARQL "Next" bezeichnet) aufgenommen. Diese neue Version soll Funktionen zur Pflege von RDF-Graphen beinhalten. Aufgrund des frühen Entwicklungsstandes und der fehlenden Standardisierung wird im Folgenden nur die Sprache und Syntax zur Datenabfrage beleuchtet^[84],[88].

SPARQL-Anfragen werden anhand eines Satzbaus mit Subjekt, Prädikat und Objekt definiert und ähneln vom Aufbau der Turtle-Syntax. Neben einfachen Anfragen in Form von Graph-Mustern, können Anfragen mit Bedingungen für eben diese einzelnen Satzglieder spezifiziert werden. Es werden diverse Funktionen für komplexe Anfragen zur Verfügung gestellt, z.B. Filtern und Sortieren von Anfragen und Ergebnissen.

Für die Beschreibung der Syntax wird im Folgenden auf Tripel aus dem Kapitel "Resource Description Framework" zurückgegriffen.

@prefix ex: <http://example.org/> . 
@prefix dfb: <http://dfb.de/> . 

ex:JoachimLoew			ex:spielteFuer		ex:EintrachtFrankfurt, ex:VfBStuttgart ;
				ex:geborenIn		ex:Schoenau ;	
				ex:geborenAm		"1960-02-03" ;
				ex:trainiert		dfb:Nationalmannschaft .

In SPARQL sieht eine Abfrage, die die Person sucht, welche die Nationalmannschaft trainiert, wie folgt aus:

 PREFIX		ex:<http://example.org/>
 PREFIX		dfb:<http://dfb.de/>
 SELECT ?trainer
   WHERE { 
 	?trainer	ex:trainiert	dfb:Nationalmannschaft .
   }

Als Ergebnis wird

trainer

http://example.org/JoachimLoew

Tab. 2 Ergebnis der 1. SPARQL-Abfrage

zurückgegeben.

Die oben gezeigte Anfrage beinhaltet drei wesentliche Klauseln: PREFIX, SELECT und WHERE.

PREFIX

Mittels Prefixe werden häufig verwendete Namensräume definiert. Sie ersetzen den statischen Teil von häufig verwendeten URLs, insbesondere von Vokabularen und Schemata. Prefixe sind rein syntaktische Hilfen um Anfragen für den Menschen leserlich zu halten. Statt eines Prefixes könnte auch die vollständige URL genutzt werden:

PREFIX		ex:<http://example.org/>
PREFIX		dfb:<http://dfb.de/>
?trainer	ex:trainiert	dfb:Nationalmannschaft .

entspricht somit:

?trainer	<http://example.org/trainiert>	 <http://dfb.de/Nationalmannschaft> .

Die Nutzung von Prefixes verdeutlicht ein weiteres Mal die Ähnlichkeit zur Turtle-Syntax.

SELECT

Mit der SELECT-Klausel wird definiert, welche Informationen nach Verarbeitung der Anfrage als Ergebnis zurückgegeben werden sollen. Die obige Anfrage liefert folglich den Trainer gemäß der weiteren Bedingungen zurück. Anfragen mittels SELECT geben Ergebnisse in Form von Tabellen als Ausgabeformat zurück.

Alternativ zu SELECT kann die Klausel CONSTRUCT verwendet werden. CONSTRUCT gibt Anfrageergebnisse in Form von RDF-Graphen zurück.

WHERE

Durch die WHERE-Klausel wird das Anfragemuster - der sogenannte GRAPH-Pattern definiert -, auf den die Rückgabeergebnisse zutreffen müssen. So sind im Abfragemuster mehrere Variablen möglich. Variablen können durch ? oder $ gekennzeichnet werden. Es ist jedoch der Leserlichkeit dienlich sich eine Konvention innerhalb von Anfragen zu beschränken.

Gesucht wird der Geburtsort und der Name der Person, die die Nationalmannschaft trainiert. In SPARQL sieht die entsprechende Abfrage wie folgt aus:

PREFIX		ex: <http://example.org/>
PREFIX 	dfb: <http://dfb.de/>
SELECT ?trainer ?geburtsort
  WHERE { 
     ?trainer		ex:trainiert	dfb:Nationalmannschaft .
     ?geburtsort	ex:geborenIn	$geburtsort .
  }

Als Ergebnis wird

trainer	geburtsort
http://example.org/JoachimLoew	http://example.org/Schoenau

Tab. 3 Ergebnis der 2. SPARQL-Abfrage

zurückgegeben.

OPTIONAL

Mit der OPTIONAL-Klausel können Informationen abfragt werden, die in den Datenbasen nicht zwingend vorhanden sein müssen. Im folgenden Beispiel wird der Geburtsort, der Name und - sofern bekannt - das Geburtsdatum der Person, die die Nationalmannschaft trainiert gesucht:

PREFIX		ex:<http://example.org/>
PREFIX		dfb:<http://dfb.de/>
SELECT ?trainer ?geburtsort ?gebdat
  WHERE { 
     ?trainer		ex:trainiert	dfb:Nationalmannschaft .
     ?geburtsort	ex:geborenIn	?geburtsort .
     OPTIONAL ( ?trainer	ex:geborenAm	?gebdat . )
  }

Als Ergebnis wird

trainer	geburtsort	gebdat
http://example.org/JoachimLoew	http://example.org/Schoenau	1960-02-03

Tab. 4 Ergebnis der 3. SPARQL-Abfrage

zurückgegeben.

Neben den oben kurz vorgestellten Klauseln zur Abfrage existieren weitere Funktionen DATATYPE (Definition des Datentyps), FILTER (Zusätzliche Bedingungen zur Einschränkung des Ergebnisses), ORDER BY (Sortierung des Abfrageergebnisses) und Weitere zur Erstellung von komplexen Abfragen auf Instanzen von RDF-Dokumenten. Darüber hinaus verfügt SPARQL über Vergleichs- und arithmetische Operatoren zur Differenzierung oder Berechnung von Abfragen und Ergebnissen^[89].

7 Schlussbetrachtung

Durch den ständigen Weiterentwicklungsprozess des World Wide Web werden unzählige Informationen in unterschiedlichen Formen und mittels verschiedenster Techniken generiert. Um diese Informationen semantisch für Maschinen lesbar aufzubereiten, existieren nun seit einiger Zeit die vorgestellten verschiedenen Methoden. Diese Methoden stellen jedoch nur ein grundlegendes Framework, also die Basis, dar. So zeigen noch offene Punkte wie z.B. unstandardisierte oder fehlende Vokabulare, sowie fehlende Datenpflegefunktionen in SPARQL auf, dass der Entwicklungprozess des Frameworks für ein Semantic Web noch lange nicht abgeschlossen ist.

Unabhängig vom genannten Entwicklungsstand beginnt das World Wide Web semantisch zu werden und Informationen sind heute schon gezielter Abrufbar wie es z.B. das Projekt dbpedia.org zeigt.

Die Contentersteller sind nun am Zug, ihre Informationen, ihre Inhalte, zu annotieren. Hierzu bieten die vorgestellten Methoden eine zukunftsorientierte Basis. Als große Herausforderung gilt es, die Ersteller von Inhalten für ein semantisches Netz zu sensibilisieren. Denn die Unwissenheit über die vorgestellten Methoden stellt eine der größten Hürden für ein weltweites gemeinsames Semantic Web ohne Insellösungen dar.

Aber auch das W3C muss seinen Teil mit der Standardisierung von RDFa und dem Entwickeln weiterer notwendiger Funktionen, wie zum Beispiel einer Aktualisierungsmöglichkeit von semantisch vorliegenden Informationen über SPARQL, beitragen und somit eine weitere Vereinfachung zum Aufbau des Semantic Web möglich machen.

8 Fußnoten

1. ↑ ^{1,0 1,1 1,2 1,3} Vgl. Allemang, Hendler (2008), S. 97
2. ↑ Vgl. Berners-Lee (2002)
3. ↑ Vgl. Hitzler et al. (2008), S. 9
4. ↑ Vgl. Ernst (2003), S. 723
5. ↑ ^{5,0 5,1} o.V. W3C (2008) http://www.w3.org/Consortium/
6. ↑ Vgl. Gumm, Sommer (2008), S. 662
7. ↑ Vgl. Hitzler et al. (2008), S. 10
8. ↑ Vgl. Hitzler et al. (2008), S. 11
9. ↑ Vgl. Hitzler et al. (2008), S. 25
10. ↑ Vgl. Klyne, Carroll (2004), http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
11. ↑ Vgl. Hitzler et al. (2008), S. 12
12. ↑ ^{12,0 12,1} Vgl. Hitzler et al. (2008), S. 27
13. ↑ ^{13,0 13,1 13,2 13,3 13,4 13,5} Bray et al. (2000) http://www.w3.org/TR/2000/REC-xml-20001006
14. ↑ Vgl. Klyne, Carroll (2004) http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
15. ↑ Vgl. Hitzler et al. (2008), S. 28
16. ↑ Vgl. Lausen (2005), S. 127
17. ↑ Vgl. Hitzler et al. (2008), S. 22
18. ↑ Vgl. Hitzler et al.(2008), S. 21
19. ↑ Bray et al. (2000) http://www.w3.org/TR/2000/REC-xml-20001006
20. ↑ Vgl. Hitzler et al. (2008), S. 30
21. ↑ Vgl. Antoniou, van Harmelen (2008), S. 9
22. ↑ Vgl. Beckett (2004) http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/
23. ↑ Vgl. Klyne, Carroll (2004) http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-data-model
24. ↑ ^{24,0 24,1 24,2 24,3} Vgl. Hitzler et al. (2008), S. 35 ff.
25. ↑ Vgl. Antoniou, van Harmelen (2008), S. 65
26. ↑ Vgl. Hitzler et al. (2008), S. 38 ff.
27. ↑ Vgl. Hitzler et al. (2008), S. 50
28. ↑ Vgl. Antoniou, van Harmelen (2008), S. 71
29. ↑ Vgl. Manola, Miller (2004) http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#typedliterals
30. ↑ ^{30,0 30,1 30,2 30,3} Vgl. Hitzler et al. (2008), S. 40 ff.
31. ↑ ^{31,0 31,1 31,2 31,3} Vgl. Hitzler et al. (2008), S. 42 ff.
32. ↑ Vgl. Hitzler et al. (2008), S. 44
33. ↑ Vgl. Antoniou, van Harmelen (2008), S. 76
34. ↑ Vgl. Antoniou, van Harmelen (2008), S. 78
35. ↑ ^{35,0 35,1 35,2} Vgl. Antoniou, van Harmelen (2008), S. 79 ff.
36. ↑ Vgl. Beckett (2004) http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#section-Syntax-parsetype-Collection
37. ↑ Vgl. Antoniou, van Harmelen (2008), S. 79
38. ↑ Vgl. Brickley, Guha (2004) http://www.w3.org/TR/2004/REC-rdf-schema-20040210/
39. ↑ ^{39,0 39,1 39,2 39,3 39,4} Vgl. Allemang, Hendler (2008), S. 91 ff.
40. ↑ ^{40,0 40,1} Vgl. Antoniou, van Harmelen (2008), S. 90
41. ↑ Vgl. Allemang, Hendler (2008), S. 95
42. ↑ Vgl. Hitzler et al. (2008), S. 70 ff.
43. ↑ ^{43,0 43,1 43,2} Vgl. Allemang, Hendler (2008), S. 98 ff.
44. ↑ ^{44,0 44,1 44,2} Vgl. Hitzler et al. (2008), S. 81 ff.
45. ↑ Vgl. Antoniou, van Harmelen (2008), S. 88
46. ↑ ^{46,0 46,1 46,2} Vgl. Hitzler et al. (2008), S. 125
47. ↑ Vgl. Hitzler et al. (2008), S. 145
48. ↑ Vgl. Bechhofer et al. (2004) http://www.w3.org/TR/2004/REC-owl-ref-20040210/
49. ↑ Vgl. http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0169.html
50. ↑ Vgl. Hori et al. (2003) http://www.w3.org/TR/2003/NOTE-owl-xmlsyntax-20030611/
51. ↑ Vgl. Patel-Schneider et al. (2004) http://www.w3.org/TR/2004/REC-owl-semantics-20040210/
52. ↑ Vgl. Antoniou, van Harmelen (2008), S. 119
53. ↑ ^{53,0 53,1} Vgl. Antoniou, van Harmelen (2008), S. 120
54. ↑ ^{54,0 54,1 54,2} Vgl. Antoniou, van Harmelen (2008), S. 121
55. ↑ ^{55,0 55,1 55,2 55,3} Vgl. Antoniou, van Harmelen (2008), S. 122 ff.
56. ↑ ^{56,0 56,1 56,2} Vgl. Antoniou, van Harmelen (2008), S. 123 ff.
57. ↑ Vgl. Antoniou, van Harmelen (2008), S. 142
58. ↑ ^{58,0 58,1} Vgl. Antoniou, van Harmelen (2008), S. 127 ff.
59. ↑ Vgl. Hitzler et al. (2008), S. 136
60. ↑ ^{60,0 60,1} Vgl. Antoniou, van Harmelen (2008), S. 129 ff.
61. ↑ Vgl. Hitzler et al. (2008), S. 152
62. ↑ Vgl. Antoniou, van Harmelen (2008), S. 117
63. ↑ Vgl. Hitzler et al. (2008), S. 153
64. ↑ ^{64,0 64,1} Vgl. Hitzler et al. (2008), S. 153 ff.
65. ↑ ^{65,0 65,1} Vgl. Antoniou, van Harmelen (2008), S. 132 ff.
66. ↑ Vgl. Pellegrini, Blumauer (2006), S. 15
67. ↑ http://pingthesemanticweb.com/stats/namespaces.php (zuletzt abgerufen am 20.01.2008) zeigt aktuell genutzte RDF-Namensräume im World Wide Web auf
68. ↑ Vgl. Hitzler et al. (2008), S. 48
69. ↑ Vgl. Pellegrini, Blumauer (2006), S. 86
70. ↑ Vgl. o.V. DCMI (2008)
71. ↑ Vgl. Dodds (2004)
72. ↑ Vgl. Brickley, Miller (2007)
73. ↑ Vgl. o.V. MMV (2004)
74. ↑ Vgl. Friedrich (2006)
75. ↑ Vgl. o.V. DOAP (o.A.)
76. ↑ Vgl. Dumbill (2004)
77. ↑ Vgl. Parada (2006)
78. ↑ Vgl. Dawson, Howes (1998)
79. ↑ Vgl. o.V. SIOC Project (2006)
80. ↑ ^{80,0 80,1} Vgl. Pellegrini, Blumauer (2006), S. 406
81. ↑ Vgl. Adida, Birbeck (2008)
82. ↑ Vgl. Adida, Birbeck et al. (2008)
83. ↑ Unter http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml (zuletzt abgerufen am 17.01.2009) sind weitere Informationen zu eRDF verfügbar.
84. ↑ ^{84,0 84,1} Vgl. o.V. W3C Semantic Web FAQ (2008)
85. ↑ ^{85,0 85,1} Vgl. Pellegrini, Blumauer (2006), S. 407 ff.
86. ↑ Vgl. o.V. SPARQL Press Release (2008)
87. ↑ Vgl. o.V. SPARQL Issues List (o.A.)
88. ↑ Vgl. o.V. SPARQL Update Language (2008)
89. ↑ Vgl. Prud'hommeaux, Seaborne (2008)

9 Literatur- und Quellenverzeichnis

Adida, Birbeck (2008)	Adida, Ben; Birbeck, Mark: RDFa Primer - Bridging the Human and Data Webs, W3C Working Group Note, W3C, 2008, http://www.w3.org/TR/xhtml-rdfa-primer/ (abgerufen am 17.01.2009)
Adida, Birbeck et al. (2008)	Adida, Ben; Birbeck, Mark; McCarron, Shane; Pemberton, Steven: RDFa in XHTML: Syntax and Processing - A collection of attributes and processing rules for extending XHTML to support RDF, W3C, 2008, http://www.w3.org/TR/rdfa-syntax/ (abgerufen am 17.01.2009)
Allemang, Hendler (2008)	Allemang, Dean; Hendler, James: Semantic Web for the Working Ontologist - Modeling in RDF, RDFS and OWL, Morgan Kaufmann Publications, San Francisco, 2008
Antoniou, van Harmelen (2008)	Antoniou, Grigoris; van Harmelen, Frank: A Semantic Web Primer, 2. Auflage, The MIT Press, Cambridge Massachusetts London, 2008
Bechhofer et al. (2004)	Bechhofer, Sean; van Harmelen, Frank; Hendler, Jim; Horrocks, Ian; McGuinness, Deborah L.; Patel-Schneider, Peter F.; Stein, Lynn Andrea: OWL Web Ontology Language - Reference, W3C Recommendation, W3C, 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/ ( abgerufen am 08.01.2009)
Beckett (2004)	Becket, Dave: RDF/XML Syntax Specification (Revised), W3C Recommendation, W3C, 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ (abgerufen am 02.01.2009)
Berners-Lee (2002)	Berners-Lee, Tim: Leserbrief What the Semantic Web Won't Do, Business Week 08.02.2002, New York, 2002 http://www.businessweek.com/magazine/content/02_14/c3777021.htm#B3777023 (abgerufen am 07.01.2009)
Bray et al. (2000)	Bray, Tim; Paoli, Jean; Sperberg-McQueen, C. M.; Maler, Eve: Extensible Markup Language (XML) 1.0, 2. Auflage, W3C Recommendation, W3C, 2000, http://www.w3.org/TR/2000/REC-xml-20001006 (abgerufen am 05.01.2009)
Brickley, Guha (2004)	Brickley, Dan; Guha, R.V.: RDF Vocabulary Description Language 1.0 - RDF Schema, W3C Recommendation, W3C, 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ (abgerufen am 06.01.2009)
Brickley, Miller (2007)	Brickley, Dan; Miller, Libby: FOAF Vocabulary Specification 0.91, o.A., 2007, http://xmlns.com/foaf/spec/ (abgerufen am 12.01.2009)
Dawson, Howes (1998)	Dawson, F.; Howes, T.: vCard MIME Directory Profile, IETF, 1998, http://tools.ietf.org/html/rfc2426 (abgerufen am 09.01.2009)
Dodds (2004)	Dodds, Leigh: An Introduction to FOAF, O'Reilly Media, Inc., Sebastopol, 2004, http://www.xml.com/pub/a/2004/02/04/foaf.html (abgerufen am 12.01.2009)
Dumbill (2004)	Dumbill, Edd: Describe open source projects with XML, Part 3 - A first draft of the DOAP vocabulary, IBM DeveloperWorks, 2004, http://www.ibm.com/developerworks/xml/library/x-osproj3/ (abgerufen am 09.01.2009)
Ehrig (2007)	Ehrig, Marc: Ontology Alignment - Bridging the Semantic Web, Springer-Verlag, Berlin Heidelberg, 2007
Ernst (2003)	Ernst, Hartmut: Grundkurs Informatik, 3. Auflage, Vieweg Verlag, Braunschweig Wiesbaden, 2003
Friedrich (2006)	Friedrich, Matthias: The MusicBrainz XML Metadata Format, o.A., 2006, http://musicbrainz.org/doc/MusicBrainzXMLMetaData (abgerufen am 09.01.2009)
Gumm, Sommer (2008)	Gumm, Heinz Peter; Sommer, Manfred: Einführung in die Informatik, 8. Auflage, Oldenbourg Verlag, München, 2008
Grütter (2008)	Grütter, Rolf: Semantic Web zur Unterstützung von Wissensgemeinschaften, Oldenbourg Verlag, München, 2008
Herman (2006)	Herman, Ivan: Questions (and Answers) on the Semantic Web, W3C, 2006, http://www.w3.org/People/Ivan/CorePresentations/SW_QA/Slides.pdf (abgerufen am 17.01.2008)
Hitzler et al. (2008)	Hitzler, Pascal; Krötzsch, Markus; Rudolph, Sebastian; Sure, York: Semantic Web Grundlagen, Springer-Verlag, Berlin Heidelberg, 2008
Hori et al. (2003)	Hori, Masahiro; Euzenat, Jérôme; Patel-Schneider, Peter F.: OWL Web Ontology Language - XML Presentation Syntax, W3C Note, W3C, 2003, http://www.w3.org/TR/2003/NOTE-owl-xmlsyntax-20030611/ (abgerufen am 04.01.2009)
Klyne, Carroll (2004)	Klyne, Graham; Carroll, Jeremy: Resource Description Framework (RDF) - Concepts and Abstract Syntax, W3C Recommendation, W3C, 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ (abgerufen am 04.01.2009)
Lausen (2005)	Lausen, Georg: Datenbanken: Grundlagen und XML-Technologien, Spektrum Akademischer Verlag, München, 2005
Manola, Miller (2004)	Manola, Frank; Miller, Eric: RDF Primer, W3C Recommendation, W3C, 2004, http://www.w3.org/TR/2004/REC-rdf-primer-20040210/ (abgerufen am 05.01.2009)
o.V. SPARQL Issues List (o.A.)	o.V.: RDF Data Access Working Group - Issues List, W3C, o.A., http://www.w3.org/2001/sw/DataAccess/issues (abgerufen am 17.01.2009)
o.V. SPARQL Press Release (2008)	o.V.: W3C Opens Data on the Web with SPARQL, Presseveröffentlichung, W3C, 2008, http://www.w3.org/2007/12/sparql-pressrelease (abgerufen am 12.01.2009)
o.V. SPARQL Update Language (2008)	o.V.: SPARQL Update Language, W3C, 2008, http://esw.w3.org/topic/SparqlUpdateLanguage (abgerufen am 17.01.2009)
o.V. W3C (2008)	o.V.: About the World Wide Web Consortium (W3C), W3C, 2008, http://www.w3.org/Consortium/ (abgerufen am 15.01.2009)
o.V. W3C Semantic Web FAQ (2008)	o.V..: W3C Semantic Web Frequently Asked Questions, W3C, Stand 27.06.2008, http://www.w3.org/2001/sw/SW-FAQ#rdfxhtml (abgerufen am 15.01.2009)
Parada (2006)	Parada, Ramón Antonio: DOAC: Description of a Career, 2006, http://ramonantonio.net/doac/ (abgerufen am 12.01.2009)
Patel-Schneider et al. (2004)	Patel-Schneider, Peter F.; Hayes, Patrick; Horrocks, Ian: OWL Web Ontology Language - Semantics and Abstract Syntax, W3C Recommendation, W3C, 2004, http://www.w3.org/TR/2004/REC-owl-semantics-20040210/ (abgerufen am 04.01.2009)
Pellegrini, Blumauer (2006)	Pellegrini, Tassilo; Blumauer, Andreas: Semantic Web: Wege zur vernetzten Wissensgesellschaft, Springer-Verlag, Berlin Heidelberg New York, 2006
Prud'hommeaux, Seaborne (2008)	Prud'hommeaux, Eric; Seaborne, Andy: SPARQL Query Language for RDF - W3C Recommendation, W3C, 2008, http://www.w3.org/TR/rdf-sparql-query/ (abgerufen am 12.01.2009)