Persistentes Speichern von RDF-Daten

Transkript

1 Persistentes Speichern von RDF-Daten Alexander Haupt Abstract RDF erlangt besonders im Kontext des Semantic Web eine immer größere Bedeutung. Die zukünftig zu erwartenden großen Mengen an Daten im RDF-Format verlangen nach effizienten Methoden zu ihrer dauerhaften Speicherung. Im Folgenden wird ein Überblick über RDF, die Problematik bei dessen Speicherung sowie eine Auswahl an Systemen vorgestellt, die diese mit Hilfe relationaler Technologien zu lösen versuchen. Dabei werden einige wesentliche Merkmale der Anfragesprachen RQL und RDQL angesprochen. Insgesamt wird ein genereller Einblick in die Problematik der persistenten Speicherung von RDF-Daten gegeben. 1 Einführung Die folgenden Abschnitte geben eine kurze Einführung in RDF und stellen die Prinzipien der persistenten Speicherung von RDF-Daten dar. Im Anschluß daran werden die Architekturen und Anfragesprachen zweier Systeme vorgestellt, die relationale Datenbanken zur Speicherung nutzen. Dabei wird insbesondere auch auf die einzelnen Datenbankschemata eingegangen. 1.1 RDF Das Resource Description Framework [1] verwendet ein Tripel-Konzept, um sowohl konkrete als auch abstrakte Dinge beschreiben und Wissen repräsentieren zu können. Jedes Tripel besteht aus einem Subjekt, einem Prädikat (Eigenschaft) und einem Objekt und wird auch als Aussage (engl. statement) bezeichnet. Im Allgemeinen wird eine Aussage als <S,A,O> oder A(S,O) notiert. Die Tatsache, daß diese Seminararbeit das Thema RDF trägt, läßt sich ausdrücken als <Seminararbeit,hatThema,RDF> oder auch als hatthema(seminararbeit,rdf). Eine Aussage lässt sich dabei als zwei durch eine gerichtete Kante verbundene Knoten interpretieren. Die Knoten repräsentieren Subjekte oder Objekte und können entweder ein Literal, ein URI oder ein leer sein (blank node). Kanten sind immer mit URIs beschriftet, die wiederum auf Eigenschaften verweisen, die wiederum Resourcen sind. Mehr zum Thema URIs ist unter [2] zu finden. Um eine Aussagen direkt referenzieren zu können, muss man sie verdinglichen (engl. to reify) [3]. Das geschieht im Allgemeinen wiederum durch die Bildung von Triplets, die die entsprechende Aussage, also dessen Subjekt, Prädikat, Objekt und auch den Typ (hier: rdf:statement) beschreiben. Durch diese gegenseitige Referenzierung mittels gerichteter und beschrifteter Kanten lassen sich ganze Graphen aufbauen und somit Datenstrukturen erzeugen, die z.b. weit über das Konzept der Objektorientierung hinausgehen. RDF selbst beschränkt in keiner Weise die Anzahl oder den Typ von Objekteigenschaften. Entsprechend dem Grundgedanken des Semantic Web sind aus gegebenen RDF-Daten leicht Ableitungen und Folgerungen von Fakten möglich, die nicht in Form einer expliziten Aussage existieren. Die Web Ontology Language (OWL) [4] und RDF Schema (RDFS) [5] erweitern RDF um vordefinierte Prädikate wie z.b. rdfs:subclassof. Mit ihnen lassen sich Ontologien aufbauen, d.h. Konzepte z.b. durch Hierarchien in Beziehung setzen. 2 Speicherung von RDF-Daten Der Umgang mit größeren Mengen an RDF-Daten erfordert Techniken zu ihrer dauerhaften Speicherung. Prinzipiell kann man RDF-Daten auf der strukturellen Ebene als Tripel, auf der semantischen Ebene als Graph und syntaktisch mit Hilfe von XML darstellen. Für eine persistente Speicherung liegt die Serialisierung mittels XML zwar nahe, birgt aber etliche Einschränkungen bezüglich der Semantik von RDF. Das größte Problem ist die fehlende Eindeutigkeit einer solchen Serialisierung und die aufwändige Erschließung der für RDF typischen Querbeziehungen [6] bei Anfagen und Update-Operationen.

2 2.1 Verwendung relationaler Datenbanken Aufgrund der hohen Performanz und der langen Erfahrung mit relationalen Datenbanken wird heute versucht, diese auch zum Speichern von RDF-Daten zu verwenden. Dabei sind jedoch etliche grundlegende Probleme zu lösen. Ein starker Widerspruch besteht darin, das Literale in RDF keinen Typ besitzen müssen. Relationale Datenbanken sind im Gegensatz dazu stark typisiert. Die einzelnen Attribute eines RDF- Objektes können implizit zahlreichen Datentypen angehören, also Integer, Boolean etc. Des Weiteren ist die Länge von Literalen und URIs in RDF nicht beschränkt. Die Speicherung einer sehr langen Zeichenkette erfordert jedoch die Verwendung eines BLOBs in der Datenbank. Eine Folge dessen sind möglicherweise Einbußen in der Performanz des Datenbankmanagementsystems (DBMS) und größerer Platzbedarf aufgrund zusätzlicher explizit zu pflegenden Informationen zum RDF-Datentyp. Für den Einsatz von Datenbanken sprechen der Erfahrungsstand und die weit fortgeschrittene Technik in diesem Bereich. DBMS sind heutzutage weit verbreitet, für nahezu alle Plattformen entwickelt und frei verfügbar. Der hohe Standardisierungsgrad, die einfache Verwendung von Abstraktionsschichten und die daraus resultierende Portabilität sind weitere Gründe. 2.2 Entwicklung von Datenbankschemata Der einfache Ansatz zur persistenten Speicherung von RDF-Triplets ist die Verwendung von drei Tabellen. Dabei werden jeweils die Ressourcen und Literale in separaten Tabellen gespeichert. Die dritte Tabelle enthält die einzelnen Aussagen in Form von Referenzen auf Werte in den übrigen drei Tabellen. Dieses Verfahren ist äußerst speichereffizient, da jedes Literal und jede URI nur einmal abgespeichert werden muß, unabhängig von der Anzahl der Aussagen, in denen sie enthalten sind. Durch ein Zusammenlegen der ersten beiden Tabellen kann unter Umständen sogar noch mehr Platz gespart werden, allerdings verliert man Informationen über die Rolle des Wertes, ob es sich um einen URI oder ein Literal handelt. Dieses einfache Schema ist zwar vollständig normalisiert und extrem speichereffizient, allerdings wird bereits für die Materialisierung eines einzelnen Statements ein Drei-Wege- Join benötigt. Die Performanz der Abfragen leidet darunter erheblich. In einer verbesserten Variante für tripletbasierte Schemata werden die Literale und URIs eines Aussage bis zu einer bestimmten Länge direkt in der Aussagen- Tabelle gespeichert. Erst bei Überschreiten eines Schwellwertes werden sie in die entsprechenden URIbzw. Literal-Tabellen geschrieben und wie vorher in der Aussagen-Tabelle referenziert. Abbildung 1 zeigt beispielhaft ein derart optimiertes Schema. Durch dieses Verfahren lassen sich Aussagen bis zu einer bestimmten Größe ohne Joins abfragen, was bis zu einer Verdopplung der Abfragegeschwindigkeit führt [8]. Durch eine Veränderung des Schwellwertes können Anwender das Verhältnis zwischen Geschwindigkeit und Platzbedarf beeinflussen. Aussagen-Tabelle Subjekt Prädikat Objekt lib:seminararbeit dc:topic 10 lib:seminararbeit dc:author Alexander Haupt 5 dc:description 11 Subjekte-Tabelle Id URI 5 namespace:langersampleuri Objekte-Tabelle Id Wert Persistentes Speichern von RDF-Daten in relationalen Datenbanken mit spezial [...] Dieses Papier beschreibt grundlegende Strukturen [...] Abbildung 1. Optimiertes tripelbasiertes Schema 2.3 Spezialisierung mit Eigenschaftstabellen Häufig sind Muster in RDF-Daten zu finden. Das bedeutet, eine große Menge von Subjekten ist gleichartig und besitzt dieselben Attribute. Hier kann man sich noch mehr dem klassischen Datenbankdesign nähern und alle diese gleichartigen Subjekte mitsamt ihren Attributen in einer einzigen Relation speichern. In [8] wird diese als Property Table zusätzlich eingeführt. Diese Art Tabellen enthalten die Subjekte in einer und jedes ihrer Attribute in jeweils einer weiteren Spalte. Im Idealfall lassen sich die Werte der Attribute eines einzelnen Subjekts mit einer einzigen Anfrage an die Datenbank abfragen, was je nach Struktur der RDF-Daten einen bedeutenden Geschwindigkeitszuwachs ergibt. Dieses Prinzip eignet sich sehr gut zur Speicherung von verdinglichten Aussagen, deren Struktur ja beständig ist. Abbildung 2 zeigt eine Eigenschaftstabelle, in der sowohl Literale, URIs als auch Referenzen verwendet werden. Subjekt Thema Autor lib:seminararbeit 10 Alexander Haupt lib:studienarbeit Social Net Analysis 18 Abbildung 2. Eine einfache Eigenschaftstabelle

3 Große Datenmengen lassen sich mittels Data-Mining- Algorithmen nach häufig auftretenden Mustern durchsuchen, um anhand der Ergebnisse möglicherweise Eigenschaftstabellen zu implementieren. Ebenso stellen vorhandene RDF-Schema-Dateien eine gute Quelle für derartige Mustererkennung dar. 2.4 Objektrelationales Schema Oft werden mit Hilfe von RDF bestimmte hierarchische Zusammenhänge beschrieben. Objektrelationale Datenbanken wie zum Beispiel PostgreSQL [9] erlauben es, diese Hierarchien bereits auf ihrer Schemaebene abzubilden. Beispielsweise kann die Beziehung rdfs:subclassof in der Datenbank durch eine entsprechende Beziehung subtableof zwischen zwei Tabellen abgebildet werden. Dadurch wird speziell das Folgern (engl. inference) von Unterklassenbeziehungen aus den Daten erleichtert. 3 Speichersysteme für RDF-Daten Die verfügbaren Systeme zur Speicherung von RDF- Daten unterscheiden sich unter anderem in der Art und Weise der internen Speicherung der Daten und der unterstützten Anfragesprache und somit der Abfragemächtigkeit. Die meisten benutzen Triplets als internes Datenmodell, andere Graphen. Die folgende Liste gibt einen Überblick über eine kleine Auswahl von Systemen [10-14] auf Basis relationaler Technologien. In den darauffolgenden Abschnitten werden zwei Vertreter näher vorgestellt. System DB-Datenmodell Anfragesprache Jena2 Triplets RDQL RDFStore Triplets RDQL Sesame Graph RDQL ICS-RDF Suite Graph RQL KAON Graph RQL TRIPLE Triplets ähnlich F-Logic Schnittstelle für Anwendungen, die damit prinzipiell jede beliebige darunterliegende RDF-Datenquelle zum Speichern und Abfragen nutzen können. Eine Modell- Schicht wandelt die Anfragen der Anwendungen in spezielle Anfragen an die Graphenschnittstelle um. Die darunter liegenden Schichten übersetzen diese wiederum in einzelne Abfragen an das DBMS, in welchem die den Graph bildenden Strukturen als Tripel gespeichert sind. Als Anfragesprache wird RDQL unterstützt, die in Abschnitt 4.1 vorgestellt wird. Abbildung 4. Jena 2 - Vereinfachte Architektur 3.2 Sesame Sesame [12] folgt einem weit generischeren Ansatz bezüglich der Datenspeicherung. Seine konsequent modulare Architektur und die Verwendung von RALs (Repository Abstraction Layers) [6] erlauben die Anbindung an eine beliebige Datenquelle, zum Beispiel Datenbanken, dateibasierte RDF-Datenbasen oder beliebige Netzdienste. RALs werden als spezialisierte Mediatoren zwischen die funktionalen Module des Programms und die Datenquelle geschaltet. Für die Verwendung einer relationalen Datenbank benutzt der für Sesame entwickelte RAL das oben beschriebene objekt-relationale Schema. Die folgende Abbildung zeigt den Aufbau von Sesame: Abbildung 3. Auswahl an RDF-Speichersystemen 3.1 Jena 2 Das Jena Semantic Web Framework [10] in der Version 2 integriert mehrere Werkzeuge zu einem umfangreichen Open-Source-Werkzeugkasten zur Erstellung von Semantic Web-Anwendungen. Es enthält neben einer RDF/OWL-API einen RDF/XML-Parser und die Fähigkeit, sich zum persistenten Speichern von RDF- Daten über JDBC an jede relationale Datenbanken zu binden. Spezielle Unterstützung gibt es für MySQL, PostgreSQL und Oracle 9i. Jena 2 verwendet zum einen das oben beschriebene verbesserte Tabellenschema sowie die ebenfalls beschriebenen Eigenschaftstabellen. Jenas getrennte Architektur bietet eine Abbildung 5. Sesames Architektur, aus [6]

4 4 Anfragesprachen Sowohl Jena als auch Sesame Beide nehmen Anfragen in entgegen, verarbeiten und optimieren diese intern, bevor sie schließlich in möglichst wenigen klassischen SQL-Anfragen an das Repository weitergereicht werden, wo möglicherweise weitere Optimierungsarbeit geleistet wird. Wie verläuft die Suche genau? Aufgrund der einfachen Repräsentation von RDF-Daten als Tripel liegt die Vorgehensweise nahe, Tripel per Matching-Verfahren zu suchen. Man besetzt dazu <S,P,O> jeweils mit einem konkreten Wert oder einer Variablen und erhält darauf die Menge aller passenden (matching) Triplets. Im extremen Fall, bei Verwendung von drei Variablen, besteht die Antwort aus allen in der Datenbasis enthaltenen Triplets. Für komplexere Abfragen, gibt es jedoch komplexere Sprachen, von denen hier zwei Vertreter vorgestellt werden, die in Jena, Sesame und KAON eingesetzt werden. 4.1 RDQL RDQL [16], im Zusammenhang mit Jena bei Hewlett- Packard entwickelt, ist eine Ableitung von SquishQL. Es erweitert das obige Matching-Verfahren um die Möglichkeit, Variablen über mehrere Triplets hinweg binden zu können, zum Beispiel durch eine transitive Verknüpfung. Dabei können jeweils Subjekt, Objekt und Prädikat mit Konstanten oder Variablen besetzt werden. Eine SQL-ähnliche Syntax erlaubt das einfache Formulieren solcher Anfragen. Abbildung 6 zeigt eine Beispielanfrage, bei der nach einer Ressourcen gefragt wird, die das Attribut info:age besitzt und dessen Wert mindestens 24 beträgt. Der Namensraum des Attributs info:age wird mit angegeben. SELECT?resource FROM < WHERE (?resource info:age?age) AND?age >= 24 USING info FOR < Abbildung 6. Query mit Variablenbindung Die Anfrage gibt eine Menge von gültigen Belegungen der Variablen resource zurück, die die Bindung in der WHERE-Klausel erfüllen. Charakteristisch für SquishQL/RDQL ist die Unterteilung der Anfrage in bindende, also die Ergebnismenge vergrößernde (WHERE-Klausel), als auch restriktive, die Anfragemenge verkleinernde Elemente enthalten sind (AND- Klausel). Letztere werden auch als Filter bezeichnet. 4.2 RQL RQL [17] basiert auf der Object Query Language (OQL) und arbeitet in Sesame auf einem formalen Graphenmodell, wodurch sich weitreichende Möglichkeiten der gleichzeitigen Navigation und Suche sowohl in den RDF- als auch in den Ontologie- und Schemadaten ergeben. Zur Suche werden auch Informationen aus dem Schema verwendet. Auch in RQL werden Variablen gebunden. Abbildung 7 zeigt eine erweiterte Variante der obigen RDQL- Anfrage in RQL-Syntax. Die Rückgabemenge enthält alle Ressourcen X1, die Bedingungen der FROM- Klausel genügen. Die darin enthaltenen Variablen X3 und X4 werden erst in der WHERE-Klausel an Konstanten gebunden. SELECT X1 FROM {X1;ns1:Student}ns1:first_name{X3}, {X1;ns1:Students}ns1:last_name{X4} WHERE X3="*alexander*" AND X4="*haupt*" USING NAMESPACE ns1=& Abbildung 6. Query mit Variablenbindung 5 Schlußfolgerung Bei der persistenten Speicherung von RDF-Daten wurden die ersten Hürden genommen. Es existiert eine Vielzahl an Frameworks, die durch unterschiedliche Herangehensweisen die Problematik zu lösen versuchen. Die Verwendung von DBMS erweist sich dabei offensichtlich als gute Wahl, wenn auch zu viel Performanz bisher nur durch in Handarbeit angepaßte Schemata erreicht wird. Ein generelles relationales Schema für die Haltung von RDF-Daten ist wünschenswert. Ein derartige Datenbasis sollte in der Lage sein, alle Operationen auf RDF-Daten selbst durchführen können und gleichzeitig das Folgern Reifikation implementieren. Der mögliche Verlust an Performanz durch das Dogma der totalen Portabilität ist in einigen Systemen noch genauer zu untersuchen. 6 Referenzen [1] W3C, Resource Description Framework, [2] RFC Uniform Resource Identifiers (URI): Generic Syntax, [3] W3C, RDF Semantics, [4] W3C, Web Ontology Language, [5] RDF Schema, [6] J. Broekstra et.al, "Sesame: An Architecture for Storing and Querying RDF Data and Schema Information", The Semantic Web - ISWC 2002: First International

5 Semantic Web Conference, Proceedings, [7] Dave Beckett, Jan Grant: "Mapping Semantic Web Data with RDBMSes", W3C Semantic Web Advanced Development for Europe, Report, 2003, bms_mapping_report/ [8] Wilkinson et.al., "Efficient RDF Storage and Retrieval in Jena2", First International Workshop on Semantic Web and Databases, Proceedings, 2003, tal.pdf, S.15 [9] PostgreSQL, freie objekt-relationale Datenbank, [10] HP Research, "Jena 2 - A Semantic Web Framework", [11] RDFStore, Perl API for RDF Storage, [12] Sesame, [13] ICS-RDF Suite: "High-level Scalable Tools for the Semantic Web", [14] KAON, "Open-Source Ontology Management Infrastructure", [15] Ronald Bourret, "XML Database Products", 2004, [16] HP, RDQL RDF Data Query Language, [17] G. Karvounarakis et.al., "RQL: A Declarative Query Language for RDF", The Eleventh International World Wide Web Conference (WWW'02), Honolulu, /www2002.pdf