Persistentes Speichern von RDF-Daten
Alexander Haupt
haupt@informatik.hu-berlin.de
Abstract
RDF erlangt besonders im Kontext des Semantic Web
eine immer größere Bedeutung. Die zukünftig zu er-
wartenden großen Mengen an Daten im RDF-Format
verlangen nach effizienten Methoden zu ihrer dauer-
haften 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 versu-
chen. Dabei werden einige wesentliche Merkmale der
Anfragesprachen RQL und RDQL angesprochen.
Insgesamt wird ein genereller Einblick in die Proble-
matik der persistenten Speicherung von RDF-Daten
gegeben.
1 Einführung
Die folgenden Abschnitte geben eine kurze Einfüh-
rung 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äsentie-
ren 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 ver-
bundene Knoten interpretieren. Die Knoten repräsen-
tieren Subjekte oder Objekte und können entweder ein
Literal, ein URI oder ein leer sein (blank node). Kan-
ten 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 Bil-
dung von Triplets, die die entsprechende Aussage, also
dessen Subjekt, Prädikat, Objekt und auch den Typ
(hier: rdf:Statement) beschreiben. Durch diese gegen-
seitige Referenzierung mittels gerichteter und be-
schrifteter 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 ge-
gebenen RDF-Daten leicht Ableitungen und Folgerun-
gen von Fakten möglich, die nicht in Form einer expli-
ziten 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 Serialisie-
rung mittels XML zwar nahe, birgt aber etliche Ein-
schrä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.1 Verwendung relationaler Datenbanken
Aufgrund der hohen Performanz und der langen Erfah-
rung mit relationalen Datenbanken wird heute ver-
sucht, 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üs-
sen. 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 be-
schränkt. Die Speicherung einer sehr langen Zeichen-
kette erfordert jedoch die Verwendung eines BLOBs
in der Datenbank. Eine Folge dessen sind möglicher-
weise Einbußen in der Performanz des Datenbankma-
nagementsystems (DBMS) und größerer Platzbedarf
aufgrund zusätzlicher explizit zu pflegenden Informa-
tionen zum RDF-Datentyp.
Für den Einsatz von Datenbanken sprechen der Erfah-
rungsstand und die weit fortgeschrittene Technik in
diesem Bereich. DBMS sind heutzutage weit verbrei-
tet, für nahezu alle Plattformen entwickelt und frei
verfügbar. Der hohe Standardisierungsgrad, die einfa-
che 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 Referen-
zen 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 Mate-
rialisierung 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 URI-
bzw. 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ön-
nen Anwender das Verhältnis zwischen Geschwindig-
keit und Platzbedarf beeinflussen.Aussagen-Tabelle
Subjekt Prädikat Objekt
lib:seminararbeit dc:topic 10
lib:seminararbeit dc:author Alexander Haupt
5 dc:description 11Subjekte-Tabelle
Id URI
5 namespace:langersampleuriObjekte-Tabelle
Id Wert
10
Persistentes Speichern von
RDF-Daten in relationalen
Datenbanken mit spezial [...]
11
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 gleich-
artig 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 einge-
führt. Diese Art Tabellen enthalten die Subjekte in
einer und jedes ihrer Attribute in jeweils einer weite-
ren Spalte. Im Idealfall lassen sich die Werte der At-
tribute eines einzelnen Subjekts mit einer einzigen
Anfrage an die Datenbank abfragen, was je nach
Struktur der RDF-Daten einen bedeutenden Ge-
schwindigkeitszuwachs ergibt. Dieses Prinzip eignet
sich sehr gut zur Speicherung von verdinglichten Aus-
sagen, 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

Große Datenmengen lassen sich mittels Data-Mining-
Algorithmen nach häufig auftretenden Mustern durch-
suchen, um anhand der Ergebnisse möglicherweise
Eigenschaftstabellen zu implementieren. Ebenso stel-
len vorhandene RDF-Schema-Dateien eine gute Quelle
für derartige Mustererkennung dar.
2.4 Objektrelationales Schema
Oft werden mit Hilfe von RDF bestimmte hierarchi-
sche Zusammenhänge beschrieben. Objektrelationale
Datenbanken wie zum Beispiel PostgreSQL [9] erlau-
ben es, diese Hierarchien bereits auf ihrer Schemaebe-
ne abzubilden. Beispielsweise kann die Beziehung
rdfs:subClassOf in der Datenbank durch eine entspre-
chende Beziehung subTableOf zwischen zwei Tabel-
len abgebildet werden. Dadurch wird speziell das
Folgern (engl. inference) von Unterklassenbeziehun-
gen 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 Abfrage-
mächtigkeit. Die meisten benutzen Triplets als internes
Datenmodell, andere Graphen. Die folgende Liste gibt
einen Überblick über eine kleine Auswahl von Syste-
men [10-14] auf Basis relationaler Technologien. In
den darauffolgenden Abschnitten werden zwei Ver-
treter 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
Abbildung 3. Auswahl an RDF-Speichersystemen
3.1 Jena 2
Das Jena Semantic Web Framework [10] in der Versi-
on 2 integriert mehrere Werkzeuge zu einem umfang-
reichen 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 Tabellen-
schema sowie die ebenfalls beschriebenen Eigen-
schaftstabellen. Jenas getrennte Architektur bietet eine
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 Tri-
pel 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 An-
bindung 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 5. Sesames Architektur, aus [6]

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 wer-
den, 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 ent-
haltenen 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 einfa-
che 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 <http://hu.berlin.de/people>
WHERE (?resource info:age ?age)
AND ?age >= 24
USING info FOR <http://hu-berlin.de/peopleInfo#>
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 Anfrage-
menge 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öglich-
keiten der gleichzeitigen Navigation und Suche so-
wohl in den RDF- als auch in den Ontologie- und
Schemadaten ergeben. Zur Suche werden auch Infor-
mationen 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 Kon-
stanten 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=& http://hu-berlin.de/peopleInfo#>
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 versu-
chen. Die Verwendung von DBMS erweist sich dabei
offensichtlich als gute Wahl, wenn auch zu viel Per-
formanz bisher nur durch in Handarbeit angepaßte
Schemata erreicht wird. Ein generelles relationales
Schema für die Haltung von RDF-Daten ist wün-
schenswert. Ein derartige Datenbasis sollte in der Lage
sein, alle Operationen auf RDF-Daten selbst durchfüh-
ren 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,
http://www.w3.org/RDF/
[2] RFC 2396 - Uniform Resource Identifiers (URI): Ge-
neric Syntax, http://www.isi.edu/in-notes/rfc2396.txt
[3] W3C, RDF Semantics, http://www.w3.org/TR/rdf-mt/
[4] W3C, Web Ontology Language,
http://www.w3.org/TR/owl-features/
[5] RDF Schema, http://www.w3.org/TR/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