Seminar Multimedia. RDF Resource Description Framework RDF and the Semantic Web. Heiko Naumann Sommersemester 2004

Transkript

1 Seminar Multimedia RDF Resource Description Framework RDF and the Semantic Web Heiko Naumann Sommersemester 2004 FH Gießen-Friedberg Professor Kneisel

2 Inhaltsverzeichnis 1. Abstract 2. Vorwort 3. Resource Description Framework Einführung 3.1. History 3.2. Aufteilung der Spezifikationen 4. Das Konzept 4.1. Das RDF Triple 4.2. RDF Graphen 4.3. N3 und N-Triples 5. Die RDF Syntax 5.1. RDF/XML Notation: Einstieg 5.2. Eine Resource als Objekt 5.3. parsetype Objekttypen 5.4. Blank nodes leere Knoten 5.5. Gruppierung von Informationen: Bag und Seq 6. RDF Schema 6.1. Das Schema-Konzept 6.2. Ein eigenes Schema 7. Ein RDF Vokabular 7.1. Anwendungsbeispiel: PostCon 7.2. Ermittlung der Attribute 7.3. Prototyp 7.4. Dublin Core : Fremde Schemata 8. RDF in der Praxis 8.1. RDQL: Abfragen á la SQL 8.2. Kommerzielle Produkte mit RDF 9. Fazit 10. Quellen

3 1. Abstract This document provides fundamental information about the Resource Description Framework (RDF) as documented and specified by the W3C Consortium. It focusses on the syntax and the concepts behind RDF. It briefly discusses the origin and first steps in the RDF history, including aims of the RDF specification. You will be shown how data is represented within RDF, how metadata is structured and recorded using different syntax, mainly focussed on the RDF/XML Notation. Different data models will be displayed, and you will learn how to describe the properties of any document or resource using the RDF/XML Syntax. Furtheron, the essay introduces the building, validating and usage of RDF Schema, building an own validated vocabulary and the use of external Schema, such as the Dublin Core. Finally it introduces some examples where RDF is or was used and where RDF will be growing important in future. 2. Vorwort Das World Wide Web hat sich als zentrale Informationsplattform etabliert und ist heute eine der primären Quellen zur Informationsbeschaffung. Aufgrund seiner dezentralen Verwaltung und der unüberschaubaren Anzahl an Anbietern stellt sich die Strukturierung und Auswertung der gebotenen Daten jedoch als Hauptproblem dar. Somit wird immer klarer, dass die Vereinheitlichung und semantische Analyse der Daten zukünftig im Vordergrund stehen wird. Zwar lassen sich Informationen in beliebiger Tiefe schon heute im globalen Netzwerk auffinden, jedoch lässt die Qualität der Daten und der Suche danach teilweise sehr zu wünschen übrig. Moderne Suchmaschinen arbeiten immer noch zumeist auf Basis einer reinen Textanalyse und geben wenig Aufschluss über die Inhalt, Herkunft und Verlässlichkeit der Daten. Um den unerschöpflichen Pool an Informationen jedoch effektiv zu durchsuchen, auszuwerten und verarbeiten zu können, benötigt man auch semantische Angaben. HTML, die vorherrschende Sprache zur Darstellung von Informationen, ist diesem Anspruch nicht gewachsen. Zwar ist HTML als Derivat von XML eine Beschreibungssprache, beschränkt sich aber auf die Spezifikation von Darstellungsregeln der Daten. Somit sind Informationen über den Inhalt, deren Struktur und semantische Abhängigkeiten derzeit kaum zu analysieren. Abhilfe soll der Ansatz des Semantic Web bieten. Ein solches semantisches Web beschränkt sich nicht mehr auf die reine Abbildung der Daten, sondern bietet z.b. weiterführende Angaben zur Informationsstruktur und dem eigentlichen Dokumentinhalt. Dazu dienen so genannte Metadaten, also eine Beschreibungssprache, die zusätzliche Informationen zum Inhalt des Dokumentes beinhalten. Ziel dabei ist es, detaillierte Rückschlüsse auf die gebotenen Daten zuzulassen, deren Quelle und Verlässlichkeit zu überprüfen und gegebenenfalls eine automatisierte Auswertung der Inhalte zu ermöglichen (ohne die syntaktische Struktur beachten zu müssen).

4 Nachfolgend wird das RDF (Resource Description Framework) vorgestellt, das auf einer Empfehlung des W3C basiert. Das RDF ist ein Modell zur Beschreibung von Daten, respektive der Inhalte eines Dokuments. 3. Resource Description Framework Einführung 3.1. History RDF ist eng mit den Entwürfen eines Semantic Web verbunden, beschränkt sich aber nicht auf dieses Anwendungsgebiet. RDF ist dazu bestimmt, eine Datenquelle oder andere Daten genauer zu spezifizieren. Die Spezifikation des Modells und der Syntax von RDF stammt vom W3C- Konsortium, wohl am besten bekannt für die Standardisierung von HTML für das WWW. Der erste Entwurf die Basis für das heutige RDF stammt aus dem Jahre 1997 und basiert auf den Entwürfen von Ora Lassila und Ralph Swick. Jene hatten sich mit den Möglichkeiten des Datenaustauschs von automatisierten Prozessen beschäftigt und dazu ein Konzept mit Hilfe einer Metasprache verwendet wurde die RDF Modell- und Syntaxspezifikation veröffentlicht, wiederum in Kooperation mit den beiden Autoren. Schon im Jahre 2000 folgte die Spezifikation für RDF Schemata Aufteilung der Spezifikationen Die erste Spezifikation von RDF war in nur einem Dokument verfasst worden. Bald wurde jedoch klar, dass dies nicht ausreichen würde, und so gibt es heute gleich sechs Dokumente, die die verschiedenen Aspekte von RDF gemeinsam abdecken. Das sind wie folgt: RDF/XML Syntax Specification Die empfohlene Serialisierungs-Technik. Neben der Darstellung in N-Triples und der N3 Notation ist die RDF/XML Notation am meisten verbreitet RDF Vocabulary Description Language 1.0 (RDF Schema) Definiert das Vokabular, den Sprachumfang des RDF und die Relation der Elemente untereinander quasi die Grammatik RDF Concepts and Abstract Syntax Definiert die grundlegenden Konzepte und Strukturen in RDF und bildet somit eine solide, konsistente Basis für Weiterentwicklungen RDF Semantics siehe RDF Primer Bietet Anwendungsbeispiele und Beschreibungen zur Verwendung von RDF Beschreibt Problemstellungen, die sich aus der Spezifikation ergeben und bietet Lösungsbeispiele, wie sie von der RDF Core Group vorgeschlagen werden.

5 4. Das Konzept 4.1. Das RDF Triple Das grundlegende Konzept basiert auf einer Beschreibung des Dokumentes bzw. der Information der Datenquelle. Diese Beschreibung kann, ähnlich der Grammatik einer realen Sprache, in einer Satzform ausgedrückt werden. In RDF wird dies mit Hilfe von so genannten Triples dargestellt. So wie wir einem deutschen Satz stets die Grundelemente Subjekt und Prädikat haben (ggf. gefolgt von einem Prädikat), so finden sich bei RDF stets eine Ressource, ein Prädikat und ein Objekt wieder. Die Ressource repräsentiert dabei die Quelle der Information, im folgenden Beispiel eine Internet-Seite. Das Prädikat ist stets eine Eigenschaft (Property) des Dokumentes. Die Eigenschaft kann eine Verwaltungsinformation der Quelle sein, Korrelationen zu anderen Quellen oder andere Charakteristika spezifizieren. Das Objekt wiederum ist dann der nominelle Wert der Eigenschaft. An einem einfachen Beispiel lässt sich ein Triple erklären. Nehmen wir als Beispiel ein HTML-Dokument; dieses Dokument hat einen Verfasser und ein Erstellungsdatum. Aus diesen Informationen lassen sich zwei einfache Sätze bilden: Das Dokument wurde verfasst von Tim Berners-Lee. Das Dokument wurde verfasst am Um diesen Sachverhalt in einem Triple auszudrücken, extrahieren wir nun die Informationen der Sätze. In beiden Sätzen ist der Gegenstand, um den es geht, das Dokument. In RDF entspricht dies der Resource. Das Prädikat beschreibt die Information, die zur Ressource gegeben wird. Das Objekt enthält letztendlich den Wert des Prädikates, im Beispiel Tim Berners-Lee bzw Allgemein ausgedrückt sieht die Beziehung so aus: <Resource> hat <Prädikat> = <Objekt> Im Beispiel: <Dokument> hat <Verfasser> = <Tim Berners-Lee> <Dokument> hat <Erstellungsdatum> = < > Da man mit RDF natürlich keine allgemeinen Informationen dokumentieren möchte, sondern Eigenschaften einer spezifischen Quelle, muss die Resource eindeutig sein. Dies wird durch eine URI (Unified Resource Identifier), also einem eindeutigen Indentifizierer erreicht. In unserem Beispiel hat das Dokument eine eindeutige URL (Unified Resource Locator), eine Sonderform der URI, welches auf dem bekannten http-protokoll basiert.

6 Somit müssen wir Dokument durch seine URI ersetzen, um die Informationsquelle eindeutig zu bestimmen: < hat <Verfasser> = <Tim Berners-Lee> Mit diesem Triple wird nun der eindeutig identifizierten Ressource eine Eigenschaft zugewiesen, nämlich ein Verfasser (und dessen Name). Dies mag einem bekannt vorkommen. Mit den Meta Tags ( Author ) kann man diese Eigenschaft in HTML bereits ausdrücken. RDF geht jedoch viel weiter. Man kann in dieser Form beliebige Informationen ausdrücken, nicht nur Verwaltungsinformationen wie den Autor, sondern auch beliebige Informationen innerhalb der Seite RDF Graphen Aus verschiedenen Gründen hat sich zur Beschreibung und Darstellung von RDF- Triples der RDF-Graph durchgesetzt. Zum einen ist die Darstellung als Graph für den Menschen besser zu lesen und zu verstehen. Darüber hinaus gibt es RDF Datenmodelle, die sich einfach nicht in der RDF/XML-Notation (siehe entsprechendes Kapitel) darstellen lassen. Ein RDF Graph erinnert nicht zufällig an die UML-Notation. Jeder Graph repräsentiert jeweils ein Triple und enthält ein Subjekt, ein Prädikat und ein Objekt. Das Subjekt des Statements wird durch einen viereckigen Kasten dargestellt, das Prädikat zeigt als gerichteter Graph auf den viereckigen Kasten mit dem Objekt. Beispiel: So lassen sich mit Hilfe einer Verknüpfung von atomaren, sehr einfachen Graphen auch sehr komplexe semantische Strukturen darstellen N3 und N-Triples Der offizielle Standard für RDF ist aufgrund der Empfehlung vom W3C die RDF/XML-Form. Trotzdem trifft man auch auf Verfechter einer anderen Darstellungsform, N3 genannt. Die Basisstruktur für N3 ist wie folgt aufgebaut: Subjekt Prädikat Objekt. Die Bestandteile sind jeweils durch Leerzeichen getrennt, das Triple anschließend mit einem Punkt geschlossen. In einem einfachen Beispiel kann das folgendermaßen aussehen:

7 < < Hans Mustermann. Dies kann mit Hilfe von XML-qualifizierten Namespaces (QNames) weiter vereinfacht werden. Dabei werden im Dokument Konstanten im Namespace deklariert und o.g. Beispiel kann wie folgt dargestellt werden: <bbd:index.html> dc:creator Hans Mustermann. Ich will an dieser Stelle aber nicht allzu tief in die N3-Notation einsteigen. Im weiteren Verlauf wird RDF anhand der RDF/XML Spezifikation erklärt. Trotzdem will ich noch kurz ein N3-Derivat vorstellen: N-Triples. N-Triples sind eine Untermenge von N3, dementsprechend gleich aufgebaut. Zusätzlich sind Kommentare in der Form # comment zulässig. So genannte blank nodes, also unbenannte Subjekte, werden in der Form _:namestring dargestellt. 5. Die RDF Syntax 5.1. RDF/XML Notation: Einstieg Anhand einiger kleiner Beispiele möchte ich nun auf die Syntax von RDF eingehen. Dabei will ich aufzeigen, wie die Informationen in RDF/XML dargestellt, kodiert und verschachtelt werden. Das Verfahren nennt sich Serialisierung und bezeichnet die Darstellung von RDF Graphen in einer konsistenten, einheitlichen Textform. <?xml version= 1.0?> <rdf:rdf xmlns:rdf= xmlns:pstcn= > <rdf:description rdf:about= > <pstcn:author>heiko Naumann</pstcn:author> <pstcn:datum> </pstcn:datum> </rdf:description> </rdf:rdf> In diesem Beispiel findet man die Grundelemente von RDF/XML wieder. Wenn man bereits mit HTML oder XML gearbeitet hat, so fällt die gleiche, verschachtelte Struktur in Form von öffnenden und schließenden Tags auf. Die Elemente sind wie folgt:

8 <?xml version= 1.0?> Der Initialisierungs-Tag mit der Information, dass es sich hierbei um XML bzw. RDF/XML handelt. <rdf:rdf xmlns:rdf= xmlns:pstcn= >.. </rdf:rdf> Initialisierung des RDF-Blocks. Analog zu HTML wird der Block mit einem </rdf> Block geschlossen. Die beiden enthaltenen Zeilen xmlns:xxx definieren XML Namespaces (QNames), auf die ich im weiteren Verlauf genauer eingehen werde. Mit diesen Namespaces lassen sich verschiedene (eigene und fremde) Sprachdefinitionen gemeinsam in einem Dokument verbinden. Dies bildet ein zentrales Konzept von RDF. Die Namespaces lassen sich im weiteren Verlauf über ihre Identifizierer (rdf bzw. pstcn) direkt ansprechen und deren Elemente können verwendet werden. <rdf:description rdf:about= > <pstcn:author>heiko Naumann</pstcn:author> <pstcn:datum> </pstcn:date> </rdf:description> In diesem Block befindet sich die Beschreibung des Dokumentes und somit der eigentliche Informationsgehalt. Im öffnenden Tag des Beschreibungsblockes <rdf:description> wird nun auch die Quelle eindeutig benannt, auf die sich die nachfolgenden Informationen beziehen, nämlich rdf:about= Abschließend der eigentliche Inhalt, die beschreibenden Metadaten, welche sich im Description-Block befinden: <pstcn:author>heiko Naumann</pstcn:author> <pstcn:datum> </pstcn:date> Hier wird auch der Vorteil der RDF/XML Notation deutlich. Diese Darstellungsweise ist erheblich einfacher zu lesen als die N3-Notation. Zum einen, weil die Struktur bereits von HTML bekannt ist. Zum anderen, weil die Art der Information direkt zu lesen ist und nicht indirekt über die Referenzierung des Schemas bestimmt wird. Im Beispiel sieht man, dass Heiko Naumann der Autor des Dokumentes ist, welches am erstellt wurde.

9 Beide Metainformationen author und datum werden mit dem Namespace pstcn: qualifiziert. Das heißt, sie sind Bestandteil eines selbst definierten Vokabulars Eine Resource als Objekt Nun könnte es vorkommen, dass eine Ressource das Objekt eines Prädikates ist. Z.B. könnte der Artikel eine Unterseite einer gesamten Serie ist, und man dies auch in der Beschreibung deutlich machen kann. Im Kontext wäre es sinnvoll, zumindest den Titel der Serie zu benennen und damit auch eine Abhängigkeit der beiden Ressourcen untereinander deutlich zu machen. In RDF/XML wird dies am Beispiel wie folgt gelöst: <?xml version= 1.0?> <rdf:rdf xmlns:rdf= xmlns:pstcn= > <rdf:description rdf:about= > <pstcn:author>heiko Naumann</pstcn:author> <pstcn:datum> </pstcn:datum> <pstcn:subpageof rdf:resource= > </rdf:description> <rdf:description rdf:about= > <pstcn:titel>eine Serie</pstcn:titel> </rdf:description> </rdf:rdf> Die Änderungen sind fett markiert. Wie man sieht, ist es gar nicht so schwer. Im Beispiel wird nun dem Prädikat einfach ein anderes Dokument zugewiesen. Anschließend können dieser Ressource weitere Eigenschaften zugefügt werden. Eine Eigenschaft eines Dokumentes muss also nicht zwangsläufig aus einem Literal bestehen, sondern kann durchaus auch eine andere Ressource ein anderes Subjekt sein. Interessant ist in solchen Fällen immer, sich den daraus resultierenden Graphen anzuschauen. Am Graphen kann man sehr einfach ablesen, ob die Serialisierung die erwünschte Aussage korrekt darstellt, semantisch korrekt ist parsetype Objekttypen In den bisherigen Beispielen war anhand der Struktur immer klar zu sehen, ob es sich bei einem Objekt um ein Literal oder eine Ressource handelt. Es gibt allerdings Situationen, in denen gerade die automatisierte Verarbeitung nicht

10 klar entscheiden kann, um was es sich bei dem angeführten Objekt handelt bzw. wo es anfängt und endet. So ist es z.b. denkbar, dass ein Objekt HTML-, XML- oder sogar RDF-Text beinhaltet. Um klarzustellen, dass diese Teile nicht interpretiert werden sollen, kann man direkt angeben, wie das Objekt geparst werden soll. Dies geschieht mit dem Attribut parsetype: <pstcn:author parsetype= Literal ><rdf>heiko Naumann</rdf></pstcn:author> Somit weiß der Parser, dass das zwischen den Tags stehende Objekt als Literal behandelt werden soll, also evtl. mögliche Interpretationen des Inhalts nicht erfolgen sollen. Umgekehrt kann man aber auch anweisen, dass ein offensichtliches Literal wie eine Ressource behandelt werden soll: <pstcn:author parsetype= Resource > <pstcn:name>heiko Naumann</pstcn:name> </pstcn:author> In diesem Beispiel ist allerdings zu beachten, dass die Angabe pstcn:name keineswegs selbst als Ressource behandelt wird. Vielmehr ist das Objekt author eine Ressource, während der Name ein Prädikat des Objektes author ist. Im zugehörigen Graphen sieht man deutlich, wie dieses Konstrukt in RDF interpretiert wird. Da der Ressource author keine eindeutige ID zugeordnet ist, wird an dieser Stelle eine blank node, also ein leerer Knoten eingefügt. Dieser Knoten besitzt nun zwar keine eindeutige, globale Identität, wohl aber eine valide Eigenschaft, nämlich ein Name. Dieses Konstrukt eines leeren Knotens kommt in RDF häufig vor, daher möchte ich es an dieser Stelle gesondert betrachten Blank nodes leere Knoten Ein leerer Knoten entsteht in RDF immer dann, wenn einer Ressource kein eindeutiger Identifizierer zugeordnet wird (oder werden kann). Blank nodes sind in RDF durchaus erwünschte Konstrukte und vergleichbar mit dem Wert NULL in diversen Programmiersprachen oder relationalen Datenbanken. Ein leerer Knoten kann z.b. bedeuten, dass eine solche Ressource zwar besteht, ihr Wert aber zur Zeit nicht ermittelt werden kann. Somit ist er ein Platzhalter, der zur Laufzeit oder einem weiteren Parserdurchgang später ermittelt wird. Innerhalb eines Dokumentes kann es durchaus mehrere leere Knoten geben. Dennoch muss gewährleistet sein, dass man gezielt und eindeutig auf die Informationen des Knotens zugreifen kann. Daher generiert ein RDF-Parser zur Laufzeit eine eindeutige ID, mit der der Knoten adressiert werden kann. Um ohne Kenntnis der ID trotzdem auf blank nodes zugreifen zu können, kann man diese ID aber auch explizit selbst generieren: <?xml version= 1.0?> <rdf:rdf xmlns:rdf= xmlns:pstcn= >

11 <rdf:description rdf:about= > <pstcn:author>heiko Naumann</pstcn:author> <pstcn:datum> </pstcn:date> <pstcn:subpageof rdf:nodeid= beispid > </rdf:description> <rdf:description rdf:nodeid= beispid > <pstcn:titel>eine Serie</pstcn:titel> </rdf:description> </rdf:rdf> Wie man sieht, funktioniert dies einfach, indem man mit Hilfe von nodeid eine eigene, eindeutige ID zuordnet und wie eine Ressource behandelt. Der RDF Validator liefert folgenden Graphen für dieses Beispiel wie man sieht, hat der dem leeren Knoten den Namen beispid gegeben: 5.5. Gruppierung von Informationen: Bag und Seq Oftmals ist es erforderlich, eine Anzahl von Informationen zu gruppieren. Dabei ist es wichtig, ob die Informationen wirklich als Gruppe oder als Sammlung von Einzelinformationen angesehen werden sollen. Möchte man z.b. eine Anzahl von Daten aufzählen, die inhaltlich disjunkt sind, so ist folgende Darstellung durchaus sinnvoll: <rdf:description rdf:about= > <pstcn:contains>inhalt</pstcn:contains> <pstcn:contains>review</pstcn:contains> <pstcn:contains>zusammenfassung</pstcn:contains> </rdf:description> Hier werden verschiedene Inhalte der Seite aufgeführt. Mit dieser Darstellung ist aber keinerlei Zusammenhang zwischen den Daten ersichtlich. Braucht man eine solche Struktur nicht, reicht diese Art der Darstellung. Besteht aber eine inhaltliche Verbindung oder sogar hierarchische Struktur innerhalb der Informationen, so möchte man diese auch in der Beschreibung darstellen. Zu diesem Zweck kennt RDF die Konstrukte rdf:bag bzw. rdf:seq. Grundsätzlich werden beide Konstrukte gleich behandelt, rdf:seq impliziert allerdings eine feste, inhaltliche Reihenfolge der Daten, während rdf:bag eher eine lose Sammlung ohne Anspruch einer bestimmten Reihenfolge darstellt.

12 Syntaktisch sieht das ganze so aus: <rdf:description rdf:about= > <pstcn:menu> <rdf:seq> <rdf:_1 rdf:resource= /> <rdf:_2 rdf:resource= /> <rdf:_3 rdf:resource= /> </rdf:seq> </pstcn:menu> </rdf:description> Statt der expliziten Hierarchie mittels rdf:_1 kann auch rdf:li benutzt werden (Der li Tag ist aus HTML hinlänglich bekannt). Dies ist allerdings eine veraltete Schreibweise und wird vom Parser im Allgemeinen automatisch in die hierarchische Schreibweise überführt. Außerdem kann man sich in so einem Fall nicht auf die implizite Reihenfolge der Aufzählung verlassen nicht notwendigerweise wird die Reihenfolge der Aufzählung entsprechen. Wie man sieht, wird das Menü vom RDF Validator als leerer Knoten interpretiert. Diesem Knoten ordnet er neben einer generischen ID nun einen Typen (Seq) und 3 Ressourcen mit den entsprechenden Links zu. 6. RDF Schema 6.1. Das Schema-Konzept In den bisherigen Beispielen haben wir bereits einiges über die Syntax von RDF erfahren. Wir haben Befehle aus verschiedenen Namespaces kennengelernt und benutzt sowohl grundlegende RDF-Befehle und Konzepte, wie auch selbst definierte Befehle und Strukturen. Jetzt ist es an der Zeit, etwas mehr über diese sogenannten RDF Schemata zu lernen. Wie wir bereits gesehen haben, werden die verschiedenen Beschreibungswerkzeuge in RDF über ihren Qualifizierer angesprochen und eindeutig adressiert. Ein Befehl wie rdf:description ist dem Basisvokabular von RDF entliehen und wird sehr oft benutzt. Alle Befehle aus den Beispielen, die mit dem Qualifizierer pstcn: angesprochen wurden, stammen jedoch aus einem eigens definierten Vokabular. Genau darin liegt die Stärke und Flexibilität von RDF. Jeder Befehl bzw. Befehlssatz in RDF ist in einem zugehörigen Schema beschrieben und genau definiert. Darin sind auch Abhängigkeiten, Zuordnungen und Hierarchien beschrieben. Zwar wird ein RDF-File nicht grundsätzlich von jeder automatisierten Bearbeitung auf ihre semantische Richtigkeit überprüft, also gegen ihre Definition im Schema abgeglichen (Der RDF Validator vom W3C-Konsortium nimmt eine solche

13 Validierung z.b. nicht vor). Von vielen Automaten wird jedoch eine solche Überprüfung durchgeführt und dient auch zum tieferen Verständnis der vorliegenden Daten. Die Basis aller RDF-Schemata bildet das Core Schema mit seinen Elementen. Dieses Konzept greift die Idee von Klassen und Vererbung gemäß den Konzepten in OO- Sprachen auf. Somit liegt jedem eigenen Konstrukt eine oder mehrere dieser Klassen zugrunde, ebenso wie die weiterführenden Elemente zur Formalisierung von Eigenschaften. Klassen im RDF Schema sind grundsätzlich an ihrer Schreibweise zu erkennen sie werden per Konvention immer groß geschrieben und unterscheiden sich somit schon optisch von Attributen eines Objektes. Im Core Schema sind nur einige wenige Klassen definiert, die jedoch die Grundlage aller Unterklassen bilden (müssen). Dieses Konzept garantiert die Konsistenz und Portierbarkeit von RDF. Alle Ableitungen dieser Klassen, seien es die offiziellen RDF-Elemente oder zu eigenen Zwecken definierte, lassen sich auf folgende Fundamente zurückführen: rdfs:resource rdfs:class rdfs:literal rdfs:xmlliteral rdfs:container rdfs:containermembershipproperty rdfs:datatype Mit diesen Klassen lassen sich, und müssen sich alle anderen Konstrukte abbilden lassen. Wie man aus diesen Bestandteilen nun einen eigenen Befehlssatz konstruieren kann, zeigt das nächste Kapitel. Zur Definition vom Attributen steht innerhalb des Basis RDF-Schemas noch eine Anzahl weiterer Befehle zur Verfügung: rdf:statement rdf:bag; rdf:seq and rdf:alt rdf:list rdf:property 6.2. Ein eigenes RDF Schema Wie wird nun ein eigenes Schema gebildet? Zuerst erfolgt die Ableitung der zu definierenden Klasse von einer Basisklasse. Der neuen Klasse können kann Attribute zugeordnet werden, wie in folgendem Beispiel ersichtlich wird: <?xml version= 1.0?> <rdf:rdf xmlns:rdf= xmlns:rdfs= xmlns:pstcn= > <rdfs:class rdf:about= > <rdfs:subclassof rdf:resource= /> </rdfs:class>

14 <rdf:property rdf:about= > <rdfs:domain rdf:resource= /> </rdf:property> <rdf:property rdf:about= > <rdfs:domain rdf:resource= /> </rdf:property> </rdf:rdf> Was passiert hier? Zuerst wird das zugrunde liegende Schema definiert, defaultmässig das folgende Schema vom W3C-Konsortium: xmlns:rdfs= Nachfolgende Definitionen sind also allesamt von diesem Schema und seinen enthaltenen Klassen abgeleitet (Die Klassen wurden etwas weiter oben vorgestellt). Dann wird die neue Klasse deklariert und mit der entsprechenden Basisklasse verbunden. In unserem Beispiel wird die Klasse DiaryEntry als eine Ableitung von Resource definiert: <rdfs:class rdf:about= > <rdfs:subclassof rdf:resource= /> </rdfs:class> Damit erbt die Klasse DiaryEntry alle Eigenschaften von Resource. Darüber hinaus bekommt der Tagebucheintrag zwei weitere Eigenschaften, nämlich einen Autor und ein Datum: <rdf:property rdf:about= > <rdfs:domain rdf:resource= /> </rdf:property> <rdf:property rdf:about= > <rdfs:domain rdf:resource= /> </rdf:property> Der Zusatz domain bewirkt, dass die Eigenschaft an genau diese Klasse gebunden, also ihr zugeordnet wird. Das Ergebnis dieser Operation ist eine selbst definierte Klasse DiaryEntry, welche bestimmte vererbte, und die beiden neuen Attribute autor und datum hat. Der zugehörige Graph des Validator ist in diesem Format zwar schlecht zu lesen, aber man erkennt hier die Beziehungen und Vererbungen der Klassen :

15 Diesen Details können und sollten auch Angaben im Klartext zugefügt werden, um eine besser Lesbarkeit für den Menschen zu gewährleisten. Dies wird mit folgenden Angaben erreicht: <rdf:property rdf:about= > <rdfs:domain rdf:resource= /> <rdfs:label xml:lang= de >Autor</rdfs:label> <rdfs:comment xml:lang= de >Der Name des Verfassers vom Dokument</rdfs:comment/> </rdf:property> Der Tag label enthält den Namen des Attributes in menschlicher Sprache. Es kann sinnvoll oder notwendig sein, für den rdf-namen die ungarische Notation o.ä. zu nutzen, label ist dann umso wichtiger zum Verständnis. comment enthält, wie der Name schon sagt, einen Kommentar zum Attribut. Hier sollte eine Beschreibung des erwarteten Inhaltes stehen und ggf. ergänzende Angaben zum Format o.ä. Beide Tags wurden hier mit dem Zusatz xml:lang= de versehen, um die Sprache zu definieren. So können die Angaben durchaus mehrfach in verschiedenen Sprachen enthalten sein, und so eine multilinguale Unterstützung ermöglichen. Ein weiteres Beispiel für Vererbung findet sich beim type-attribut. Eigentlich wird dies in den meisten fällen nicht explizit angegeben. In folgendem Beispiel kann man sich allerdings das type-attribut im Zusammenhang mit dem Vererbungs-Prinzip zunutze machen: <rdfs:class rdf:about= > <rdfs:subclassof rdf:resource= /> </rdfs:class> <rdfs:class rdf:about= > <rdfs:subclassof rdf:resource= /> </rdfs:class > <rdfs:class rdf:about= > <rdfs:subclassof rdf:resource= /> </rdfs:class > Wir haben hier eine Klasse Artikel, die eine Unterklasse von Resource ist. Von Artikel abgeleitet sind nun zwei weitere Klassen definiert WebArt und PrintArt. Möchten wir nun ein Attribut definieren, das beide Klassen als Argumente erwartet, so müssen wir dies nicht zwangsläufig für beide Namen separat bestimmen. Mit folgendem Befehl richten wir ein Attribut ein, das einen Artikel als Wert erwartet oder eine von Artikel abgeleitete Klasse: <rdfs:class rdf:about= > <rdfs:subclassof rdf:resource= /> </rdfs:class > <rdf:property rdf:about= > <rdfs:domain rdf:resource= /> <rdfs:range rdf:resource= /> </rdf:property> Wie man sieht, besitzt die neue Klasse Review nun ein Attribut vom Typ ueber. Da ein solches Review genauso über einen Webartikel wie über einen Printartikel verfasst werden kann, müssen beide Typen akzeptiert werden.

16 Dies wird mit rdfs:range erreicht. Mögliche Attributwerte können somit vom Typ Artikel und allen davon abgeleiteten Klassen sein. 7. Ein RDF Vokabular 7.1. Anwendungsbeispiel: PostCon Nun haben wir sowohl grundlegende Kenntnisse über die Syntax von RDF/XML erworben, als auch erste Einblicke in die Erstellung eines eigenen RDF Schemas. Nun stellt sich die Frage, wann und zu welchem Zweck man RDF einsetzen kann bzw. sollte. Allgemein kann man diese Frage nicht beantworten. RDF ist überall dort denkbar, wo man weiterführende und logische Informationen zu seinen Daten anbieten und verarbeiten möchte. Im Buch, das diesem Seminar als Hauptquelle dient, ist ein anschauliches Beispiel im WWW dargestellt, das ich an dieser Stelle ebenfalls benutzen möchte: das PostCon- Vokabular. Diesem RDF-Schema und Vokabular liegt das Problem der veralteten Informationen zugrunde. Jeder kennt im heutigen WWW das Problem von veralteten Seiten und/oder gänzlich unauffindbaren Seiten bzw. toten Links. HTML bzw. die Server haben keine Möglichkeit, genauere Informationen über die Aktualität der Seite zu liefern, bei nicht vorhandenen Seiten bietet der 404 Error ebenfalls wenig Information. So sind beispielsweise folgende Daten zu einer Seite interessant: - Wann wurde die Seite erstellt, ggf. wann zuletzt bearbeitet? - Ist der Inhalt aktuell bzw. gibt es ein due date? - Ist die Seite Teil einer Serie mit mehr Informationen? - Wer ist verantwortlich für den Inhalt? usw.

17 Findet man die Seite nicht, so wünscht man sich z.b. folgende Informationen: - Existiert eine solche Seite überhaupt, bzw. hat sie existiert? - Ist die Seite gelöscht bzw. verschoben worden? - Warum ist die Seite gelöscht bzw. verschoben? - Gibt es eine Umleitung bzw. einen Verweis auf eine andere Quelle? usw. Unser PostCon-Vokabular soll nun definiert werden, um genau solche Informationen zur Verfügung zu stellen Ermittlung der Attribute An erster Stelle gilt es, die benötigten Attribute und Klassen festzulegen, die man zu diesem Zweck benötigt. Das Beispiel von Shelley Powers ist sehr umfangreich und bietet weitreichende Informationen über das Dokument. Zur Vereinfachung werde ich auf einige Teile verzichten und mich auf folgende Elemente beschränken: Content Bio: Title (Titel des Dokuments) Resource Abstract (Auszug / Teaser des Inhalts) Resource Description (Beschreibung des Inhalts) Creation date (Erstellungsdatum) Content Author (Ersteller) Content Owner (Verantwortlicher für Inhalt) Relevanz: Content Status (z.b. ist der Inhalt noch gültig?) Subject (Worum geht es im Dokument?) Relevancy Expiration (Ab wann sind die Infos veraltet?) References (Externe Verweise im Dokument) Referenced by (Externe Verweise auf das Dokument) History: Movement (verschoben nach) Reason (Warum verschoben?) Date (Wann verschoben?) Type (Art der Verschiebung add/move) Alle anderen, von Shelley Powers bearbeiteten Angaben würden den Umfang des Seminars sprengen und werden von mir nicht berücksichtigt.

18 7.3. Prototyp Es empfiehlt sich, vor der Erstellung der konkreten Schemas an einem Beispieldokument prototypisch zu entwickeln. Es lässt sich somit leichter ermitteln, ob die Angaben wie gewünscht repräsentiert werden und vom Validator korrekt interpretiert. Dazu gehen wir nun schrittweise vor und entwickeln zuerst einen Rumpf für das Vokabular: <?xml version= 1.0?> <rdf:rdf xmlns:rdf= xmlns:pstcn= xml:base= > <pstcn:resource rdf:about= artikel01.html > <pstcn:bio /> <pstcn:relevancy /> <pstcn:history /> </pstcn:resource> </rdf:rdf> Somit haben wir bereits den Rumpf zur Beschreibung unseres Dokumentes. Im Prinzip kann man nun damit beginnen, konkrete Inhalte für den Prototyp einzufügen und dabei gleich Anpassung in der Struktur zu machen. Im Beispiel fangen wir mit dem oberen Element <pstcn:bio /> an und fügen nun konkrete Inhalte ein. Weiterhin werden wir bio als Resource ausweisen und somit aus der Biographie des Dokumentes eines eigenen, leeren Knoten generieren: <?xml version= 1.0?> <rdf:rdf xmlns:rdf= xmlns:pstcn= xml:base= > <pstcn:resource rdf:about= artikel01.html > <pstcn:bio parsetype= Resource > <pstcn:title>titel des Dokumentes</pstcn:title> <pstcn:abstract>teaser aus dem Dokument. Empty</pstcn:abstract> <pstcn:description>teil 1 einer Serie über xyz</pstcn:description> <pstcn:datecreated> </pstcn:datecreated> <pstcn:author>heiko Naumann</pstcn:author> <pstcn:owner>fh Giessen-Friedberg</pstcn:owner> </pstcn:bio> <pstcn:relevancy /> <pstcn:history /> </pstcn:resource> </rdf:rdf> Wie man sieht, werden dem leeren Knoten bio nun diverse Attribute zugefügt. Und zwar genau jene, die wir als geforderte Eigenschaften für die Biographie des Dokumentes weiter oben festgelegt haben. Da der RDF-Validator die RDF-Syntax nicht gegen das (noch nicht bestehende) Schema abgleicht, kann man o.g. Code nun auch validieren lassen. Dabei erkennt

19 man, ob die gewünschte Hierarchie erreicht ist. Im Prinzip haben wir, wenn wir nun die restlichen Angaben einpflegen, bereits ein komplettes Vokabular vorbereitet. Eine Besonderheit ist allerdings bei der History bzw. den Movements zu beachten. Ein Dokument kann durchaus mehrfach verschoben werden, was auch in der Struktur des Arguments deutlich werden muss. Das vollständige Beispiel sieht nun so aus: <?xml version= 1.0?> <rdf:rdf xmlns:rdf= xmlns:pstcn= xml:base= > <pstcn:resource rdf:about= artikel01.html > <pstcn:bio rdf:parsetype= Resource > <pstcn:title>titel des Dokumentes</pstcn:title> <pstcn:abstract>teaser aus dem Dokument. Empty</pstcn:abstract> <pstcn:description>teil 1 einer Serie über xyz</pstcn:description> <pstcn:datecreated> </pstcn:datecreated> <pstcn:author>heiko Naumann</pstcn:author> <pstcn:owner>fh Giessen-Friedberg</pstcn:owner> </pstcn:bio> <pstcn:relevancy rdf:parsetype= Resource > <pstcn:currentstatus>active</pstcn:currentstatus> <pstcn:description>teil 1 einer Serie über xyz</pstcn:description> <pstcn:expires> </pstcn:expires> <pstcn:references rdf:resource= /> <pstcn:referencedby rdf:resource= /> </pstcn:relevancy> <pstcn:history> <rdf:seq> <rdf:_1 rdf:resource= /> <rdf:_2 rdf:resource= /> <rdf:_3 rdf:resource= /> </rdf:seq> </pstcn:history> </pstcn:resource> <!-Related Resources-> <pstcn:movement rdf:about= > <pstcn:movementtype>add</pstcn:movementtype> <pstcn:reason>new Article</pstcn:reason> <pstcn:date> </pstcn:date> </pstcn:movement> <pstcn:movement rdf:about= > <pstcn:movementtype>move</pstcn:movementtype> <pstcn:reason>move zu veraltet.de</pstcn:reason> <pstcn:date> </pstcn:date> </pstcn:movement> <pstcn:movement rdf:about= > <pstcn:movementtype>move</pstcn:movementtype> <pstcn:reason>move to mydomain.de</pstcn:reason> <pstcn:date> </pstcn:date> </pstcn:movement> </rdf:rdf>

20 Interessant ist nebenbei betrachten die Zeile <!-Related Resources->. Dies ist ein XMLkonformer Kommentar, mit dem sich weitere Anmerkungen einfügen und das Dokument übersichtlicher gliedern lässt. Besonders beachtenswert ist die Konstruktion der History. Wie man sieht, ist das Dokument mehrfach verschoben worden. Dies wird hier durch einen Container Seq realisiert. In dieser Sequenz werden 3 Ressourcen angegeben, die die 3 URLs der Verschiebungen sind. Per Definition beinhaltet jede Verschiebung aber mehrere Attribute, demnach muss eine Verschiebung (Movement) eine eigene Klasse sein. Die genaueren Angaben zu den URLs werden dann anschließend und außerhalb der Resource eigenständig behandelt. Es ist durchaus erlaubt und korrekt, Ressourcen, die Attribute sind, auch außerhalb der Klammern zu definieren. Darin besteht einer der großen Unterschiede zu normalem XML und ein entscheidender Vorteil bezüglich der Flexibilität der Syntax. Im Graphen ist so auch die sogenannte Striped Syntax zu erkennen, die in RDF/XML gefordert ist. Die History ist ein Attribut des beschriebenen Dokuments. Innerhalb der History findet sich die Sequenz als leerer Knoten, der die 3 Ressourcen als Attribute besitzt. Die außerhalb definierten Ressourcen wiederum sind eigene, leere Knoten, welche alle Attribute einer Verschiebung jeweils als Attribut besitzen. Das hört sich zwar kompliziert an, ist aber sehr leicht zu erkennen und bildet ein gängiges Grundprinzip von RDF/XML. Damit kann man jederzeit alle möglichen Kombinationen der Sprache erkennen und verstehen Dublin Core : Fremde Schemata Als anschauliches Beispiel macht es Sinn, alle Attribute und Klassen selbst zu definieren. Somit lernt man den Aufbau kennen und versteht die Ideen von RDF/XML. Bei ständiger Verwendung macht es jedoch wenig Sinn, das Rad ständig neu zu erfinden. Dann wird man entweder auf eigene, bereits vorhandene Schemata zurückgreifen oder öffentliche Standardschemata bemühen. Eines dieser Schemata ist das Dublin Core Metadata Element Set. Hier finden sich einige grundlegende Attribute zur fertigen Verwendung. Diese standardisierten Attribute sind weit verbreitet und lassen sich gut verwenden, um eigene Schemata zu erweitern und zu ergänzen. Folgende Attribute sind im Dublin Core Schema (DC) bereits vorhanden: title (Name der Ressource) creator (Ersteller der Ressource) subject (Thema bzw. Inhalt des Dokuments) description (Beschreibung des Inhalts) public (Flag für Veröffentlichung) contributor (Ergänzung zum Ersteller, z.b. ein Zweitautor) date (Datumsformat) type (Art des Dokumentes) format (Format des Dokumentes, z.b. doc) identifier (ID oder eindeutiger Identifizierer)

21 source (Referenz zu einer Quelle, die zugrunde liegt) language (Sprachversion) relation (Beziehung zu einer anderen Ressource) coverage (Thema bzw. Fokus des Inhaltes) rights (Informationen zu Rechten und Copyrights) Dies sind einige, aber nicht alle Attribute, die man im Dublin Core zur Verwendung findet. Es empfielt sich allerdings, vor der Verwendung eines solches Attributes nähere Informationen darüber einzuholen. Implizite Strukturen des Attributes oder die Properties / Klassen, von denen sie abgeleitet wurden, können entscheiden über die sinnvolle Verwendung des DC. Vergleichen wir das Dublin Core Schema mit unserem PostCon Schema, so fallen gewisse Übereinstimmungen auf. Manche Elemente lassens ich somit durch DC ausdrücken, ohne sie selbst noch einmal definieren zu müssen. Am Beispiel der bio kommen wir somit zu folgendem Ergebnis: <pstcn:bio rdf:parsetype= Resource > <dc:title>titel des Dokumentes</dc:title> <pstcn:abstract>teaser aus dem Dokument. Empty</pstcn:abstract> <dc:description>teil 1 einer Serie über xyz</dc:description> <pstcn:datecreated> </pstcn:datecreated> <dc:creator>heiko Naumann</dc:creator> <dc:rights>fh Giessen-Friedberg</dc:rights> </pstcn:bio> Mit diesen Angaben lässt sich nun das Schema definieren, das unserem Vokabular zugrunde liegt: Das pstcn. Dies geschieht im allgemeinen genau so, wie oben bereits beschrieben. Elemente, die wir nun vom Dublin Core übernommen haben, müssen natürlich nicht noch einmal definiert werden. Das führt dann zu folgendem Schema: <?xml version= 1.0?> <rdf:rdf xmlns:rdf= xmlns:rdfs= > <rdfs:class rdf:about= > <rdfs:isdefinedby rdf:resource= /> <rdfs:label xml:lang= de >Web Resource</rdfs:label> <rdfs:comment xml:lang= de > Web Resource managed with PostCon System </rdfs:comment> <rdfs:subclassof rdf:resource= /> </rdfs:class> <rdfs:class rdf:about= > <rdfs:isdefinedby rdf:resource= /> <rdfs:label xml:lang= de >Web Resource Verschiebung</rdfs:label> <rdfs:comment xml:lang= de > Eine Verschiebung des Dokumentes </rdfs:comment> <rdfs:subclassof rdf:resource= /> </rdfs:class> <rdf:property rdf:about= > <rdfs:isdefinedby rdf:resource= /> <rdfs:label xml:lang= de >Biographie der Ressource</rdfs:label>

22 <rdfs:comment xml:lang= de >Historische Infos zur Ressource </rdfs:comment> <rdfs:range rdf:resource= /> <rdfs:domain rdf:resource= /> </rdf:property> <rdf:property rdf:about= > <rdfs:isdefinedby rdf:resource= /> <rdfs:label xml:lang= de >Status</rdfs:label> <rdfs:comment xml:lang= de >Aktueller Status des Dokuments </rdfs:comment> <rdfs:range rdf:resource= /> <rdfs:domain rdf:resource= /> </rdf:property>... </rdf:rdf> Die restlichen Attribute, welche noch nicht vom DC übernommen sind, definieren sich analog zu bio. Einziger Unterschied werden die jeweiligen Namen und gegebenenfalls die Art der erwarteten Wert sein (rdfs:range). 8. RDF in der Praxis Wir haben im Laufe des Seminars erfahren, wie wir mit Hilfe von RDF bzw. RDF/XML eine Quelle (in diesem Beispiel eine Webseite) mit genaueren Informationen versehen können. RDF mit seinen grundlegenden Konzepten gibt uns dazu die Möglichkeit. Wie RDF in der Realität bereits heute Anwendung findet, blieb bisher unklar. Das große Problem bei der Erstellung dieses Seminars ist die Informationsbeschaffung hierüber. Da RDF keine Sprache in diesem Sinne ist, sondern ein Konzept zur Beschreibung von Daten und Metadaten, erkennen wir RDF in der Praxis nur schwer. Es gibt verschiedene Ansätze, wie und wo RDF verwendet werden kann und mit welchen Tools, Parsern und Hilfsmittel es verarbeitet wird. Im Mittelpunkt wird immer die Technologie stehen, mit der das RDF Konzept letztendlich umgesetzt worden ist. Gerade wo XML draufsteht, ist heutzutage oft RDF im Hintergund. Oftmals bleibt es aber unerwähnt oder verschwimmt durch die Konvergenz mit anderen Sprachen und Konzepten. Nachfolgend möchte ich nur einige wenige Beispiele nennen, bei denen RDF zur Anwendung kommt und zu welchem Zweck man es genutzt hat RDQL: Abfragen á la SQL Die in RDF/XML verfassten Daten müssen natürlich, um sie auswerten zu können, auch in irgendeiner Form geparst werden können. Gerade semantische Abhängigkeiten und Beziehung von Ressourcen untereinander benötigen eine Möglichkeit, gezielt ausgewertet werden zu können. Dies erledigen eine Vielzahl von mehr oder weniger kleinen Programmen. Ein Werkzeug zur Auswertung von RDF ist RDQL eine mit SQL vergleichbare Query

23 Language. RDQL bietet verschiedene Abfragen wie select, from, where and using, ist also direkt vergleichbar mit SQL. Ich kann zwar an dieser Stelle nicht darauf eingehen, wie genau diese Abfragen verarbeitet werden die Verarbeitung variiert je nach Tool, API und Scriptsprache aber die Möglichkeiten sind erstaunlich. Mit einem Code wie dem folgenden kann man somit innerhalb von RDF Dateien gezielt nach Abhängigkeiten oder logischen Einheiten suchen. Ebenso, als wenn man komplexe logische Abfragen bei einer relationalen Datenbank macht. SELECT?date WHERE (?resource, <rdf:type>, <pstcn:movement>), (?resource, <pstcn:movementtype>,?value), (?resource, <dc:date>,?date) AND (?value eq Add ) USING pstcn FOR rdf FOR dc FOR < Mit einer solchen Abfrage kann man z.b. ein Datum abfragen für Ressourcen mit einer Verschiebung vom Typ Add. Interfaces für verschiedene Programiersprachen sind verfügbar. Die meisten Tools und APIs sind zwar für JAVA bestimmt, aber solche Abfragen lassen sich z.b. durch das sog. Query-O-Matic Lite auch in PHP durchführen und sind somit weit verbreitet Kommerzielle Produkte mit RDF Neben verschiedenen Tools, die sich auf die Darstellung und das Parsen von RDF- Files für Webanwendungen spezialisiert haben, findet RDF auch Verwendung in einigen kommerziellen Programmen. Diese haben das Konzept von RDF zunutze gemacht, um interne oder externe Informationen in Form von RDF zu dokumentieren, zu speichern und somit strukturiert zur weiteren Verwendung zu dokumentieren. Neben zumeist JAVA-basierten Tools wie Brownsauce ( verwendet z.b. Mozilla RDF. Gerade die Verwendung von strukturierten RDF-Bäumen hat dazu geführt, dass Mozilla- Komponenten vielseitig verwendbar sind. Netscape nutzt RDF z.b. dazu, benutzerspezifische Strukturen intern zu speichern und zu verwalten. So werden die Bookmarks und die History des Browsers intern mit RDF dokumentiert und verarbeitet. Ein weiterer, sehr interessanter Ansatz findet sich bei fast allen Produkten aus dem Hause Adobe. Adobe hat sich mit XMP ein Derivat von RDF entwickelt, dass es sogar ermöglicht, RDF-ähnliche Strukturen in binäre Dateien einzubinden und somit z.b. innerhalb von Bildern und Graphiken weitreichende Verwaltungsinformationen strukturiert abzulegen.

24 9. Fazit RDF ermöglicht es, in Form von relativ simplen Ausdrücken mehr oder weniger komplexe Sachverhalte strukturiert zu verwalten, speichern und auszuwerten. Die Nutzungsmöglichkeiten von RDF sind nahezu unbegrenzt und finden sich überall, wo Metadaten verarbeitet werden müssen. Im Laufe der Recherchen für dieses Seminar hat sich für mich jedoch gezeigt, dass die Annäherung an RDF verhältnismäßig schwierig ist. Da RDF eben keine eigenständige Sprache ist und niemals eigenständig auftritt, bleibt die genaue Verwertung der RDF- Informationen etwas unklar. Wo RDF Verwendung findet, ist es tief im Inneren von Applikationen gekapselt und kann nur schwer anschaulich vermittelt werden. Somit ist die Speicherung jener Zusatzinformationen in Form von RDF/XML nicht sehr komplex, die Auswertung und Verarbeitung der Daten jedoch alles andere als trivial. Während die Verwendung in Suchmaschinen wohl die zugänglichste und am besten verständliche Anwendung von RDF ist, geht die Praxistauglichkeit weit darüber hinaus. Gerade im Hinblick auf die immer weiter steigende Komplexität von Daten und die globale Vernetzung von Datenbeständen wird der Bedarf zur Gliederung und semantischen Verarbeitung der gebotenen Daten parallel ansteigen. RDF bietet hierzu die geeigneten Hilfsmittel. RDF alleine ist jedoch kein Allheilmittel. Es ist Aufgabe der Spftwarehersteller und Content Provider, den o.g. Bedarf zu erkennen und mit Hilfe von standardisierten Methoden zunehmend einheitlich zu dokumentieren. So kann die unkontrollierte und schwer zu beherrschende Informationsschwemme im WWW irgendwann sinnvoll und effizient genutzt werden und somit das WWW zu dem werden, wozu es ursprünglich gedacht war: Eine universelle, interpretier- und kontrollierbare Informationsquelle 10. Quellen O Reilly: Practical RDF by Shelley Powers, 1. Auflage 2003 ISBN RDF Validator based on RDF Documentation and Specification based on