Diplomarbeit im Studiengang Informatik. Effiziente Indexstrukturen für zeitabhängige RDF Daten

Transkript

1 Fachbereich 12 Mathematik und Informatik Diplomarbeit im Studiengang Informatik Effiziente Indexstrukturen für zeitabhängige RDF Daten Autor Daniar Achakeyev geboren am in Kharkov, Ukraine Themenstellung und Betreuung: Prof. Dr. B. Seeger Marburg (Lahn), im Februar 2009

2 Zusammenfassung Resource Description Framework (RDF) hat im Laufe der Zeit mehr und mehr an Bedeutung gewonnen. Durch ein einfaches Konzept und eine pragmatische Semantik kann RDF als ein alternatives Modell für die Datenverwaltung in heterogenen Umgebungen in Betracht gezogen werden. Insbesondere eignet sich RDF für Integration von Daten aus verschiedenen Quellen. Nicht zu vergessen, dass RDF das Rückgrat für das Semantische Web und die Basis für die Zukunftsvision vom Zusammenspiel von intelligenten Maschinen bildet. Viele Applikationen aus verschiedenen Bereichen nutzen das Framework für Annotation von Daten und Bereitstellung von Meta-Daten für semantische Analyse. Dabei werden Datenmengen gesammelt, die in Größenordnung von mehreren Gigabytes sind. Diese Größenordnungen von typischen RDF Datenbanken fordern die effiziente Zugriffs- und Anfragefunktionalität. Die Verwaltung von großen Mengen von RDF Daten in Form von speziellen Tabellen in einer relationalen Datenbank hat sich in der Praxis etabliert. Im Laufe der Entwicklung der RDF Datenbanken wurde intensiv der Einsatz von konventionellen Indexstrukturen aus relationalen Datenbanken erforscht. Auch spezielle neue Strukturen, die funktionale Besonderheiten von RDF berücksichtigen, wie die Graphstruktur von RDF, wurden entworfen. Viele Applikationen für RDF verwenden Daten mit temporalem Bezug. Die Arbeit beschäftigt sich mit der Verwaltung von großen Mengen von temporalen RDF Daten. Der Schwerpunkt der Forschung in dem Indexstrukturenbereich für RDF Daten lag bisher auf der Verwaltung von RDF Daten ohne zeitlichen Bezug. Im Zuge der Entwicklung von RDF Indexstrukturen wurde aber auch eine spezielle Indexstruktur für temporale RDF Graphen entworfen. Diese kann limitierte temporale Anfragen ausführen. Im Laufe der Arbeit wird die allgemeine Möglichkeit der Verwendung und Anpassung von temporalen Index- und Zugriffstrukturen für RDF Datenbanken untersucht. Eine der entscheidenden Rollen spielt dabei die effiziente Verarbeitung von komplexen temporalen Anfragen. Dabei wird ähnlich dem relationalen Modell vorgegangen. Zuerst werden theoretische Grundlagen für die Einführung der Zeitdimension in RDF betrachtet. Danach wird anhand der abstrakten temporalen Modelle die Möglichkeit des Einsatzes von temporalen Strukturen aus der relationalen Welt untersucht.

3 Inhaltsverzeichnis 1. Resource Description Framework (RDF) RDF Anfragesprachen RDF Datenbanken Zusammenfassung Zeitdimension in RDF Temporale Modelle in relationalen Datenbanken Zeitsemantik Darstellung von Zeit Temporal RDF Zusammenfassung Zugriffstrukturen für RDF Daten Konventionelle Zugriffstrukturen für RDF Daten Temporale Zugriffstrukturen für RDF Daten Transaktionzeit-Zuggriffstrukturen Validzeit-Indexstrukturen Transaktionszeit und Versionierung in RDF Spezielle Indexe TGRIN Indexstruktur für temporale RDF Graphen Zusammenfassung Implementierung von Indexstrukturen für zeitabhängige RDF Daten in der XXL Bibliothek Indexstrukturen in XXL B+Baum in XXL B+Baum für variabel lange Schlüssel in XXL MVBT in XXL Transaktionszeit-Indexe für RDF in XXL Validzeit-Indexe für RDF in XXL Experimente und Ergebnisse Validzeit-Strukturen Transaktionszeit-Strukturen Schlusswort und Ausblick 84 A. Anhang 86

4 Einleitung Diplomarbeitaufbau Im ersten Kapitel geht es um der Resource Description Framework. Im Kapitel werden syntaktische und semantische Eigenschaften des RDF erläutert. Dabei wird auf die praktische Relevanz von RDF eingegangen. Im Verlauf des Kapitels wird das RDF Datenmodell mit dem Relationalen Modell verglichen. Im Anschluss des Kapitels werden die möglichen Verwaltungstechniken für RDF Daten der Reihe nach präsentiert. Das zweite Kapitel beschäftigt sich mit der Zeitdimension in RDF. In der Einführung des Kapitels werden die Beispiele und Argumentationen für die Notwendigkeit der Verwaltung von zeitabhängigen Daten angegeben. Im ersten Abschnitt werden die formale Methoden und Begriffe für die Zeitdarstellung innerhalb des relationalen Modells vorgestellt. Im zweiten Abschnitt wird eine Möglichkeit, die Modelle aus der relationalen Welt auf das RDF zu übertragen, präsentiert. Im dritten Kapitel geht es um die Zugriffstrukturen für RDF Daten. In der Einführung werden allgemeine Begriffe in Zusammenhang mit Zugriffstrukturen geklärt. Dabei wird für die Notwendigkeit von effizienten Indexstrukturen für RDF Daten argumentiert. Im ersten Abschnitt des Kapitels werden die Zugriffstrukturen für nicht-temporale RDF Daten vorgestellt. Der zweite Abschnitt beschäftigt sich mit temporalen Zugriffstrukturen und ihrer Klassifizierung. Dabei wird der Frage nachgegangen, wie tauglich die Strukturen für die Verwaltung von zeitabhängigen RDF Daten sind. Im letzten Abschnitt werden Indextechniken, die speziell für die Verwaltung von RDF Daten entwickelt wurden präsentiert. Thema des vierten Kapitels ist die Implementierung der Indexstrukturen mit Hilfe der Java- Bibliothek XXL. Es wird unter anderem die in Rahmen der Diplomarbeit entwickelten und bestehenden Strukturen und Algorithmen beschrieben. Im letzten Abschnitt werden die Ergebnisse von Experimenten mit RDF Daten vorgestellt.

5 1. Resource Description Framework (RDF) Der größte Traum in Semantik Web ist es, die Webdaten nicht nur dem Menschen sondern auch den Maschinen verständlich zu machen. In diesem Kapitel geht es zum einen um das Grundgerüst des semantischen Web RDF. Da der Fokus der Arbeit auf der Verwaltung von den RDF Daten liegt, wird es in dem Kapitel weniger auf die Applikationen aus dem Bereich Semantik Web, sondern vielmehr auf die Struktur von RDF eingegangen. Zuerst werden die Architektur des Frameworks vorgestellt. Die Serialiseirungsformate, die Möglichkeit die Daten in einem Relationalen Datenbank Management System (RDBMS) zu verwalten, verschiedene Architekturmodelle für RDF Verwaltung in RDBMS. Zusätzlich werden kurz die Anfragesprachen besprochen RDF RDF ermöglicht Aussagen über Ressourcen zu treffen unter anderem Attribute zu zuordnen und die Beziehungen zwischen den Ressourcen zu beschreiben. Ressource Description Framework besteht aus zwei Komponenten. Die erste ermöglicht salopp ausgedrückt etwas über etwas auszusagen [4]. Die Zweite beschreibt die Beziehungen und Typen von Ressourcen. Eines Ziele bei der Entwicklung des RDF waren die Bereitstellung eines einfachen Datenmodells und einfache Semantik mit beweisbaren Deduktionsregeln. Als Datenmodell für RDF wird ein simples Graphmodell mit dem Grundgerüst RDF Tripel (Subjekt, Prädikat, Objekt) kurz (S,P,O) verwendet. Die Menge von RDF Tripel wird ein RDF Graph genannt. Wobei die Knoten des Graphen sind die Subjekte und Objekte. Die Prädikate stellen die Kanten des Graphen dar. Strukturell ist ein RDF Graph ein direkte beschriftete Graph(vgl. Abbildung Einer der zentralen syntaktischen Bausteine des RDF Graphmodels ist Uniform Resource Identifier (URI) Konzept. Das Framework erweitert und verwendet dieses Konzept zur eindeutigen Beschreibung der Ressourcen. Weitere RDF Konstrukte sind die Literale und leere Knoten. Das Literal ist eine Zeichenkette mit zusätzlichen Information wie die Lokalisationssprache plain Literal oder der Datentyp getypter Literal. Aus einer praktische Perspektive kennt RDF nur einen Datentyp und zwar Zeichenketten, alle anderen Datentypen werden durch den getypter Literal kodiert. Die leeren Knoten sind die Graphknoten mit bezogen auf einen bestimmten Graph lokalen Indentifikatoren. Zusammengeffast hat RDF Tripel folgende syntaktische Struktur: Definition (RDF Tripel) Ein RDF Tripel (S,P,O) ist eine Aussage oder Fakt mit folgende Aufbau: Subjekt S ist entweder ein URI oder ein leerer Knoten. Prädikat P ist ein URI. Objekt O ist entweder ein URI oder ein Literal oder ein leerer Knoten. Ein RDF Graph ist eine Mengen von RDF Tripel. Mit dieser Organisation lassen sich beliebige Aussagen und Beziehungen zwischen denen erstellen. Ursprünglich wurde RDF für Beschreibung von Web-Ressourcen entwickelt. Das Ziel

6 1.1 RDF 6 Abbildung 1.1.: Graphisch wird ein RDF Tripel wie folgt repräsentiert. Die Subjekt- und Objekt- Ressourcen werden als Ovale, Prädikate als gerichtete Kannten und Literale als Rechtecke dargestellt. ist es, ein einfaches Konzept zu Darstellung von Meta-Information anzubieten. Zunächst betrachten wir das Tripel Beispiel auf der Abbildung 1.1, diese entspricht der Aussage Die Ressource hat den Namen Philipps-Universität Marburg. Was uns fehlt ist die Interpretation von diesem Tripel z.b. dass die Ressource eine Universität ist und Name ein Attribut von diesem Typ ist, sogar wissen wir nicht ob der Name eine Beziehung oder ein Attribut ist. Aus diesem Grund sind die Prädikate als URI definiert und können als Knoten von RDF Graphen verwendet werden, damit lassen sich die Aussagen über die Kanten der Graphen erstellen. Für die Interpretation von Prädikaten müssen die Meta-Informationen bzw. das Schema verfügbar sein. Diese Aufgaben übernimmt in RDF das RDF Schema Vokabular (RDF/S). Mit dessen Hilfe können die Attribute und Beziehungen zwischen Ressourcen beschrieben werden. Das ermöglicht maschinelle Interpretation von RDF Daten. Von Vorteil ist auch, dass die Metadaten über Daten auch als RDF Graphen verwaltet werden. An dieser Stelle greift das URI Konzept. Ähnlich wie in relationalen Datenbanken die Metatabellen, die Information über die Tabellen und Attributen mit Datentypen verwalten, werden in RDF die Schemainformationen (wie Beziehungen zwischen den Ressourcen) mit Hilfe des RDF Schema Vokabular repräsentiert. Im Allgemeinen ist RDF/S Vokabular ist definiert durch die Menge von reservierten Wörtern, die für die Beschreibung von Eigenschaften und Beziehungen von und zwischen Ressourcen dienen. Das RDF/S Vokabular definiert Klassen und Eigenschaften für die Gruppen Ressourcen. Für die Modellierung von Beziehungen zwischen den Ressourcen bietet RDF vordefinierte Konzepte wie Klasse (eine Menge von Ressourcen), Instanz eine Klasse und Attributen von Klassen. Hier sind die wichtigsten Klassendefinitionen von RDF/S rdfs:resource, rdf:property, rdfs:literal, rdfs:class. Durch die rdf:property werden die binären Beziehungen zwischen Subjekten und Objekten beschrieben. Die eingebauten Attribute sind z.b. rdf:type, rdfs:subclassof und rdf:subpropertyof. Das eine Ressource zu einer Klasse gehört kann z.b. wie folgt dargestellt werden: [ rdf:type, bsp:universität] [bsp:name, rdf:type, rdf:property] Die Modellierung von Beziehungen mit RDF/S stellt die Grundlage für die semanitschen Analyse. Durch die Zugehörigkeit zu einer Klasse kann z.b. semantische Gleichheit nachgewiesen werden, die transitiven Beziehungen zwischen den Klassen der Beziehungen, erlauben Herleitung von neuen Informationen. Wohl eine der interessanten funktionalen Besonderheiten von RDF ist die Möglichkeit Aussagen über die Tripel zu erstellen. Damit ermöglicht RDF die Metainformation über die RDF Aussagen in RDF Syntax darzustellen. Betrachten wir folgendes Szenario, angenommen wir wollen in unserem RDF System zusätzlich simple Auditfunktionalität anbieten (vgl. Abbildung 1.2). Diese Technik die Aussagen über die Aussagen zu machen wird in RDF als Reification bezeichnet. RDF bietet verschiedene Möglichkeiten die Aussagen über die Aussagen zu machen. Eine Option wäre das Reifications Vokabular von Framework zu benutzten

7 1.1 RDF 7 Abbildung 1.2.: Reification Beispiel. Der Beispielgraph zeigt, wie mit Hilfe von der Reification eine einfache Auditfunktionalität implementiert werden kann. (rdf:statement,rdf:type, rdf:predicate, rdf:subject, rdf:object). Die einfachste Methode die RDF Tripel über Tripel zu erstellen ist wie folgt: [X, rdf:type, rdf:statement] [X, rdf:predicate, bsp:fachbereich] [X, rdf:subject, [X, rdf:object, Über den leeren Knoten X kann die Metainformation beschrieben werden. Die Flexibilität des RDFs erlaubt auch andere Darstellungsmöglichkeiten, es kann z.b. auch das eigene spezifische Vokabular zur Reifications Zwecken erstellt werden. Im nächsten Kapitel wird gezeigt wie dieses Konzept in Zusammenhang mit Zeitabhägigen RDF Daten benutzt werden kann. Im Laufe der Arbeit werde ich folgendes fiktives Beispielsystem verwenden, die einer Wissensdatenbank über deutschen Hochschulen verwaltet. Information sind von jeweiligen Hochschulen als RDF Daten zu Verfügung gestellt. Auch Zugriff auf interne Datenbanken (Deep Web Datenbanken) wird bereitgestellt, neben dem Zugriff wird auch die Schemainformation von Deep Web Datenbanken RDF/S verfügbar gemacht. Die Daten werden dann mit Crawler gesammelt und zu RDF Datenbank hinzugefügt. Zusätzlich bietet das System Suchdienste und Interface für die Kopplung von anderen Diensten. Wissensdatenbank verwaltet unter anderem Informationen über die laufende Forschungsprojekte, Diplom- und Doktorarbeiten, wissenschaftliche Paper, Kooperationspartner etc. Es ist klar, dass die Daten für den Crawler als RDF Metainformationen bereitgestellt wurden. Eine interessante Frage in Zusammenhang mit unserer fiktiven RDF Datenbank ist die Organisation von der Backenddatenbank. Soll ein relationales Modell oder ein RDF für die Backend-Verwaltung verwendet werden? Warum sich die Mühe geben und die Daten mit RDF verwalten, wenn dieselbe Information kann auch in relationalen Modell dargestellt werden. In der Tat haben das RDF Graph Modell und das Relationale Modell viel gemeinsam. Die Beziehungen zwischen den Ressourcen oder die Informationen über Ressourcen können auch in relationalen Modell abgebildet werden. Es kann ein relationales Modell entworfen werden und ein Schema für die Hochschulen Informationsverwaltung für die relationale Datenbank angelegt werden. Das Modell ist aber sehr starr. Die Daten für unser fiktives System kommen aus heterogener Web-Umgebung, mit stark variierenden Schemainformationen von einzelnen Hochschulen z.b. für die Daten, dieselbe Information ausdrücken, können verschieden Datentypen verwendet werden. Durch das Bereitstellen von RDF/S Dokumenten können Beziehungen analysiert werden und in unser System integriert werden. Außerdem ermöglichen wir auch die Semantische Analyse der Daten durch spezielle Dienste zu betreiben z.b. können neue Beziehungen entdeckt werden oder

8 1.1 RDF 8 das System kann präzise neue Forschungskooperationspartner finden. Hätten wir als Backend Modell ein relationales Modell verwendet, müssten wir kontinuierlich das Schema anpassen auf neue Datentypen eventuelle Konverter schreiben, neue Beziehungstabellen anlegen, neue Tabelle für neu entdeckte Konzepte. Auch die maschinelle Interpretation von diesen Daten ist schwieriger. Die Beziehungen - und Attributeninformationen von den Tabellen sind zwar auch in relationalen Modell verfügbar, müssen aber mühsam aus Metatabellen herausgezogen und durch Schlüssel- und Fremdschlüssel-Eigenschaften hergestellt werden, meistens sind diese Informationen unzureichend. Betrachten wir die Tabelle, die das Konzept Hochschule darstellt und die Tabelle, die Fachbereiche verwaltet. Angenommen die beiden stehen durch Fremdschlüssel Eigenschaft in Parent- Child Beziehung zu einander. Ohne entsprechende Zusatzinformation kann nur die Information, dass die beiden Konzepte, die durch die Tabellen repräsentiert sind, miteinander in Beziehung stehen. Die Information, dass der Fachbereich die Einrichtung der jeweiligen Universität ist, ist nicht explizit verfügbar. Natürlich kann ein Beziehungstyp eingeführt werden, der dann diesen Sachverhalt beschreibt. Dann müssen über diesen Beziehungstyp wiederum Metainformationen zu Verfügung gestellt werden. Es kann aber auch eine Hybrid Lösung implementiert werden, indem, vorausgesetzt, dass das Schema nicht so stark mit der Zeit variiert, Backend nach relationalen Modell zu organisieren. Für semantische Analyse der Daten können die Meta-Daten über die Relationalen Modell in RDF/S geschrieben werden, und über Abbildungsmodul für relationales und RDF Modell bereitgestellt werden. Die Flexibilität, die uns RDF bietet, hat auch ihren Preis. Bei Verwendung von relationalem Modell für Backend-Datenbank können wir Normalisierung und anderen Techniken aus relationalen Datenbanken verwenden, das erlaubt ein Hochleistungsystem zu implementieren. Im Laufe der Arbeit wird aber auch gezeigt, wie die Performanz der RDF Datenbanken gesteigert werden kann. RDF und XML Ein weiteres Ziel bei der Entwicklung des RDF war die Verwendung des XML zur Austausch und maschinellen Interpretation von RDF Daten. Aus diesem Grund wird z.b. für getypte Literale das XMLLiteral Konzept verwendet. Die andere Schnittemenge zwischen der RDF und XML Welt ist Repräsentation von RDF Graphen mit Hilfe der XML Notation. Betrachten wir folgenden Beispiel. Beispiel Ein Auszug in XML Format aus unserer Universität Datenbank kann wie folgt serealisiert werden: Phlipps-Universität Marburg hat Fachbereich Mathematik und Informatik. Der Fachbereich bietet zwei Fachrichtungen Mathematik und Informatik. <?xml version="1.0" encoding="utf-8"?> <rdf:rdf xmlns:rdf=" xmlns:bsp=" <rdf:description rdf:about=" <bsp:name>philipps-universität Marburg</bsp:name> <bsp:hatfachbereich rdf:resource = " </rdf:description> <rdf:description rdf:about=" <bsp:fachrichtung> <rdf:bag> <rdf:li>mathematik</rdf:li><rdf:li>informatik</rdf:li> 1 Mit Hilfe von RDF Validator können die RDF Dokumente online validiert werden. Dieser Dienst bietet auch die graphische Repräsentation von RDF XML Dokumenten

9 1.1 RDF 9 </rdf:bag> </bsp:fachrichtung> </rdf:description> </rdf:rdf> Neben der Möglichkeit die Daten mit Hilfe von XML darzustellen, bietet RDF die Option die Daten in einem N-Tripel Format zu repräsentieren.... < <bsp:name> "Philipps-Universität Marburg" Anfragesprachen In vorigen Abschnitten haben wir kennen gelernt, wie die RDF Daten gespeichert und serialisert werden können. Wenden wir uns jetzt der Frage wie die gewünschte Information in RDF Datenbanken aufgesucht wird. Grundsätzlich gibt es verschiedene Möglichkeiten, z.b. unser Beispielsystem kann eine Programmierinterface anbieten. Das ermöglicht selbst einen Algorithmus zum Traversieren des RDF Graphen zu implementieren, vergleichbar mit dem Netzwerkmodell. Das wäre äußerst umständlich bei jeder Anfrage anzugeben, wie die gesuchten Daten berechnet werden können. Gewünscht ist ähnlich wie in relationalen Modell (Tupelkalkül, relationale Algebra 2 ) oder XML (XQuery) eine deklarative Anfragesprache die unabhängig von der physikalischen Implementierung ist. Nach der Definition des RDF Graphen als Menge von Tripel lässt sich ein Graph als eine Tabelle mit drei Attributen (S, P, O) darstellen. Aus diesem Grund können die Parallelen zu relationalen Modell hergestellt werden. In vorigen Abschnitt wurde in Zusammenhang mit RDF ein Graph Datenmodell als Datenmodell vom Framework angesprochen. Aus diesem Blickwinkel lassen sich auch die Konzepte der Anfragesprachen aus der relationalen Datenbanktheorie auf RDF übertragen. Würde diese Tabelle in einer Relationale Datenbank verwaltet, könnten schon bestimmte Anfragen wie Selektion nach einem Tripel und Projektion auf Attribute durchgeführt werden Z.B. (?, P,?) sind alle Tripel die ein bestimmtes Prädikat enthalten. Wir können auch mehr, durch relationale Joins und Tupelvariablen können Graphpfade berechneten werden z.b. (?, P 1, x), (x, P 2,?). In Zusammenhang mit dem Graphdatenmodell können diese Anfragen als Anfragegraphen aufgefasst werden. Allgemein können wir es als die Suche nach allen Teilgraphen im RDF Graphen, die dem Anfragegraphen matchen, betrachten. Dies wird im RDF als Graphmatching bezeichnet. Schon mit drei Operatoren der Relationalen Algebra wie Selektion, Projektion und Join kann die Graphmatching- Funktionalität implementiert werden. Diese stellen auch die theoretische Grundlage für die SPARQL 3 Anfragesprache für RDF dar. Die Sprachsyntax ist in Anlehnung an SQL entwickelt worden. So würde eine Anfrage in SPARQL aussehen, die nach Namen von Projekten, die am Fachbereich Mathematik und Informatik laufen, anfragt. SELECT?Name WHERE {?x rdf:type bsp:projekt. bsp:hasprojekt?x.?x bsp:name?name. } Ein Großteil von Anfragen aus der praktischen Perspektive kann schon mit SPARQL beantwortet werden. Die Ausdruckstärke der Sprache ist aber beschränkt auf SPJ Anfragen. 2 die Sprache ist nicht ganz deklarativ 3 seit 2008 ist SPARQL als Standard Anfragesprache für RDF Daten von W3C festgelegt

10 1.2 RDF Datenbanken 10 SPARQL kann aber nicht mit dem Graphmodell verbundenen Anfragen wie Erreichbarkeitsfrage zwischen zwei Ressourcen beantworten. Diese Art von Anfragen lassen sich nicht mit SPJ Anfragen ausdrücken, da in diesem Fall die Rekursion fehlt. In SPARQL lassen sich nur die einfache Pfad Ausdrücke berechnen, bei denen die Länge des Pfades vorab bekannt ist. Was gewünscht sind, nicht nur Matching- sondern auch Navigationanfargen ähnlich zu XML Anfragesprachen wie XPath und XQuery. Im Zuge der Entwicklung von RDF wurden auch andere Anfragesprachen entwickelt, die auch allgemeine Pfadausdrücke berücksichtigen. Die SPARQL hat sich aber durchgesetzt, ausschlaggebend war dabei die Einfachheit und die gewisse Ähnlichkeit zu SQL. Die typischen Graphanfragen, bei denen der Pfad zwischen Ressource a und b abgefragt wird, oder allgemeine Pfadausdrücke, die z.b. nach dem Pfad von Ressource a nach b suchen, bei dem das Prädikat p 1 nur einmal und p 2 mehrmals vorkommt, können als spezielle Operatoren implementiert werden und SPARQL anreichern. Ein gute Übersicht über die RDF Sprachen bieten folgende Arbeiten [6][7][9]. Eine kurze Einführung in SPARQL bietet [8] RDF Datenbanken Zwei mögliche Serialisierungsformate haben wir in diesem Abschnitt kennen gelernt. Eine Idee für die Verwaltung von RDF Daten ist die Verwendung von XML oder serialisierten N-Tripel Dateien, dabei gibt es ähnlich der Argumentation bei der Verwaltung von relationalen Daten, viele offensichtliche Nachteile. Durch Querverbindung zum relationalen Modell ist es von Vorteil die RDF Daten in einem RDBMS zu verwalten. Dafür spricht nicht nur die Ähnlichkeit von Modellen, sondern auch die praktischen Gründe, wie die Verwaltung von großen Datenmengen, Datenmanipulation mit SQL, Nebenläufigkeit- und Wiederherstellungs- Komponenten, die von den RDBMS angeboten werden. Die Anwendungen für komplexere Semantische Manipulation von RDF Daten können auf den relationalen Datenbanken aufgebaut werden und auf Applikationseebene die benötigte Daten effizient traveresieren. Zudem lässt sich die standard RDF Anfragesprache SPARQL in SQL übersetzten. Die Tatsache dass die RDF Graph eine Menge von RDF Tripel ist, ermöglicht den RDF Graphen direkt die relationale Tabelle zuzuordnen. In der einfachsten Variante könnte eine Tabelle mit Schema Subjekt, Prädikat, Objekt mit einem RDF Graphen assoziiert werden: Beispiel CREATE TABLE TRIPLE_TABLE( RDF_Subject TEXT, RDF_Predicate TEXT, RDF_Object TEXT ); Einfach heißt nicht unbedingt, dass diese Abbildung schlecht ist. Diese Art der Verwaltung wird auch als Tripletable bezeichnet. Im Laufe der Arbeit wird auch gezeigt, dass diese Möglichkeit der Verwaltung von RDF Daten in RDBMS in Bezug auf Effizienz eine gute Wahl ist. Zusätzlich zur Verbesserung der Speicherplatzausnutzung kann eine Mapping Tabelle für Präfixe erstellt werden, die der Übersetzung von Namensräumen dienen kann. Die Tripletable kann auch normalisiert werden, indem eine Hauptabelle für die Graphstruktur und drei Tabellen für das Subjekt, Prädikat und Objekt verwaltet werden, ähnlich dem Star- Schema. Die komplette Normalisierung hält zwar die Konzepte getrennt, bei überwiegend 4 Dabei wurde SQL Syntax von PostgreSQL verwendet. Der TEXT Datentyp steht für die variablen langen Zeichenketten

11 1.2 RDF Datenbanken 11 lesenden Zugriffen werden dann die Joins berechnet, um die Tripel darzustellen (die Effizienz von diesem Modell kann aber ähnlich dem Datawarehouse Ansatz durch die Vorberechnung der Joinindexe gesteigert werden). Eine andere Normalisierung wäre neben der Haupttabelle die Tabelle mit Ressourcen und Tabelle mit Literalen zu verwalten. In vielen RDBMS Systemen sind die Datentypen für Zeichenketten begrenzt auf eine bestimmte Länge, lange Zeichenketten insbesondere Literale können nicht direkt verwaltet werden, dafür gibt es spezielle Datentypen wie CLOB. In [10] z.b. wird eine Hybrid-Lösung vorgeschlagen, neben der Tripletable werde zwei Tabellen mit Datentypen für die Verwaltung von langen Zeichenketten bereitgestellt, eine für Ressourcen und eine für langen Literalen, Falls der Spaltendatentyp die Zeichenkette nicht aufnehmen kann, wird diese in die Zusatztabelle ausgelagert. Zusätzlich, um die Geschwindigkeit von Anfragen zu steigern werden in [10][11] so genannte Property Tabellen eingeführt in diesen werden die Prädikatwerte, die tendieren häufig mit Subjekten aufzutreten und auf gewisse Weise die zu clustern, in eine Zusatztabelle ausgelagert. Diese Prädiaktenwerte werden dann als Attribute der Tabelle dienen. (Z.B. hätten wir die Prädikatenwerte wie Name, istim- Projekt, Geburtsdatum, dann könnte die Tabelle mit folgendem Schema zusätzlich angelegt werden (Subjekt, Name, istimprojekt, Geburtsdatum) ). Diese Erweiterung kann die Anzahl der Join Operationen erheblich reduzieren z.b. bei der Anfrage In welchem Jahr ist Max Mustermann geboren, der im Projekt arbeitet? [13]. Die Anfrage lässt sich in SQL mit zwei Subjekt-Subjekt Joins berechnen: SELECT C.RDF_Object FROM Triple_Table AS A, Triple_Table AS B, Triple_Table AS C WHERE A.RDF_Subject = B.RDF_Subject AND B.RDF_Subject = C.RDF_Subject AND A.RDF_Predicate = Name AND A.RDF_Object = Max Mustermann AND B.RDF_Predicate = istimprojekt AND B.RDF_Object = AND C.RDF_Predicate = Geburtsdatum Mit Hilfe der Property Tabelle dagegen würde man nur eine Selektion benötigen. In [13] wurde eine Besonderheit bei der RDF Daten in TripleTable beobachtet. Häufig ist in vielen RDF Graphen die Anzahl von Beziehungstypen (Prädikaten) im Vergleich zu Subjekten und Objekten nicht so groß. Damit ist die Selektivität des P Attributes vergleichsweise klein. Diese Beobachtung führte dazu, dass die Daten vertikal nach P Attributen partitioniert wurden. Die Idee basiert auch auf den oben beschriebenen Property Tabellen, nur ist diese Lösung viel flexibler. Bei der vertikalen Partitionierung werden pro Prädikatwert eine zweispaltige Tabelle mit führender Spalte für Subjekte und der zweiten Spalte für Objekte erzeugt( Hätten wir wie in unserem kleinerem Beispiel nur die drei Prädikatenwerte Name, istimprojekt, Geburtsdatum, könnten drei Tabellen erzeugt werden). Zwar wird die Anzahl der Joins nicht so stark reduziert wie bei der Property Tabelle Technik, die sind aber sehr effizient ausführbar. Eine zusätzliche Effizienzverbesserung bringt die Verwaltung von zweispaltigen Tabellen in einem Spaltenorientierten RDBMS [13][12] 5. Im Allgemeinen speichern die Spaltenorientierten RDBMS die Daten als zweikomponentige Tupel (Id, Wert zum Spalte-Attribut), damit werden die Tabellen vertikal zerlegt. In normalen RDBMS werden Datenbanktupel reihenweise in Speicherseiten des Externenspeicher verwaltet. Beim Lesen von Daten, bei denen nur ein Teil der Attribute benötigt wird (Projektion), wird das ganze Tupel geladen. Bei der spaltenorineiterten Speicherung werden nur die benötigten Attribute geladen. Das erhöht den Durchsatz und senkt auch die CPU Kosten bei einer späteren Projektion. Allerdings 5 Nähe zur Architektur von Spaltenorientierten RDBMS ist in [51] zu finden

12 1.3 Zusammenfassung 12 wenn eine Teilmenge von Attributen gefragt wird, werden natürlich die Joins benötigt. In diesen Systemen werden aber diverse Optimierungen von Joins vorgenommen, z.b. es werden vorab die Join-Indexe für eventuellen Teilmengen von Attributen berechnet. Zudem sind die internen Spaltentabellen meistens als Indexe organisiert, und die Daten liegen sortiert vor. Das ermöglicht den direkten Einsatz von Sort-Merge-Join Algorthmen. Die spaltenorientierten Systeme sind primär aber für die Daten gedacht, bei denen die Lesezugriffe überwiegend sind, da bei häufigen Einfügen- und Update-Operationen alle internen zweispaltigen Tabellen und Joinindexe modifiziert werden müssen. Bei der Vertikalen Partitionierungstechnik für RDF Daten liegen die Tabellen für Prädikate schon als zweispaltige Tabellen vor. In der Praxis zeigen die RDF Daten auch am häufigsten ein statisches Verhalten. Damit können die Daten in Batch-Modus geladen werden. In [13][12] wird experimentell gezeigt, dass diese Art der Verwaltung der statischen RDF Daten eine der effizientesten ist. Die als erste beschriebene Form der Verwaltung als TripleTable kann aber genau so effizient, ohne Einsatz der spaltenorientierten RDBMS, sein, wenn die Daten richtig indexiert sind[23]. Zudem wurden als Fazit in allen drei Arbeiten experimentelle Vergleiche mit RDF Systemen gemacht, die RDF Daten anders als RDBMS verwalten. Alle diese Systeme haben eine schlechtere Performanz gezeigt als hier angesprochene Verwaltungstechniken Zusammenfassung Seit der Erfindung von RDF hat sich das Framework in dem Zielbereich Web nicht so richtig durchgesetzt. Es gibt aber Anwendungsgebiete bei, denen das RDF aktuell eine große Rolle spielt. In P2P Netzwerken wird zum Beispiel RDF verwendet, um einzelne Knoten einer P2P Netzwerk zu beschreiben. Das ermöglicht eine automatische Suche nach Netzwerknoten, die eine interessante Information, Dienst anbieten. In Biologie wird RDF als Annotationstechnik für Beschreibung von Beziehungen zwischen z.b. Proteinen, biologischen Arten etc. eingesetzt. Für die Abbildung von sozialen Netzwerken wird auch RDF eingesetzt. Unter anderem dient RDF als Basis für Ontologien Entwicklung und Ontology Web Language (OWL). Ganz andere Anwendung findet RDF im Bereitstellen von Metainformation für Multimedia Objekte z.b. mittlerweile besitzen viele digitale Kameras eine Funktionalität, die erlaubt automatisch die Metainformation in RDF mit geschossenen Bilder zu assoziieren, z.b. Ort und Zeit Angaben. In diesem Kapitel wurde weniger auf das Semantik-Web eingegangen. RDF wurde eher aus der technischen Sicht präsentiert. Eine vertiefende Diskussion über Semantik Web wird in[4][3] gut beschrieben. Wir haben die syntaktische Struktur von RDF kennengelernt, die Möglichkeit der semantischen Analyse von Daten mit RDF/S. Die theoretischen Grundlagen von RDF sind in [2] [5] zu finden. Aus der Datenbanksicht bietet RDF ein alternatives Datenmodell für die Verwaltung von Daten. Besondere Vorteile vom Framework sind einfacher syntaktischer Aufbau, wohldefinierte Semantik, Domainunabhägigkeit. Als Fazit lassen sich RDF Daten mit Hilfe eines RDBMS verwalten. Die Standardanfragesprache SPARQL basiert auf SPJ Anfragen, damit lässen sich die Anfragen in SQL übersetzen. Im nächsten Kapitel geht es um die Erweiterung des RDF um die Zeitdimension. Dabei wird versucht zu zeigen, wie die Techniken aus dem verwandten relationalen Modell auf RDF angewendet werden können.

13 2. Zeitdimension in RDF In diesem Kapitel werden Grundbegriffe und die wichtigsten Konzepte aus dem Bereich temporaler Datenbaken erläutert. Die RDF-Tripel stellen ähnlich dem relationalem Modell Fakten und Aussagen über die modellierte Welt dar. Die Aussagen können auch explizit Zeitinformation enthalten, z.b. Information über die zeitliche Gültigkeit eines Faktes, die durch einen Tripel oder durch einen Subgraphen repräsentiert ist. RDF/S erlaubt die Vokabulare flexibel zu schreiben, so dass die Zeitkomponente von intelligenten Maschinen interpretiert und weiterverarbeitet werden kann. Zunächst betrachten wir folgendes Beispiel: Beispiel Folgende RDF XML Darstellung beschreibt die Information, dass Max Mustermann im Projekt Semantic Web von Jahr 2000 bis Jahr 2006 gearbeitet hat <rdf:description rdf:about=" <bsp:position> <bsp:period> <time:from rdf:nodeid="date "/> <time:to rdf:nodeid="date "/> <bsp:projekt rdf:resource = " </bsp:period> </bsp:position> </rdf:description> <rdf:description rdf:nodeid="date "> <time:at rdf:datatype=" </time:at> </rdf:description> <rdf:description rdf:nodeid="date "> <time:at rdf:datatype=" </time:at> </rdf:description>... Im Beispiel wird explizit zeitliche Information verwaltet. Dafür wird ein Zeitvokabular definiert, mit dessen Hilfe der Internetdienst gezielt nach Zeitkomponenten suchen und sie verarbeiten kann. Eine ganz andere Sicht auf die Zeit vermittelt das nächste Beispiel Beispiel Betrachten wir folgendes Szenario (Abbildung 2.1 ): Angenommen nach der Einführung des neuen Content-Management-Systems an der Universität Marburg wurde die Webaddresse des Fachbereichs Mathematik und Informatik geändert. Sämtliche Änderungen wurden von Hochschulrechenzentrum der Uni Marburg an unsere Beispiel-RDF-Datenbank geschickt. Nach einer Revision der Seiten-Struktur wurden die Seiten von abgeschlossen Projekten als gelöscht markiert und nicht mehr verlinkt. Nach einiger Zeit wollte eine Arbeitsgruppe von der Universität N wissen, ob es auch an dem Fachbereich Informatik an der Uni-Marburg Projekte in Bereich Semantik Web gaben. Leider war es durch die propagierten Änderungen unmöglich diese Information zu finden. Um die Änderungen verfolgen zu können wurde dann entschieden auch alte Zustände der Wissensdatenbank zu speichern. Jede 1 Bei der Erstellung von diesem Beispiel wurde folgende Quelle verwendet. Namensraum für time:

14 2.1 Temporale Modelle in relationalen Datenbanken 14 Abbildung 2.1.: Zeitliche Änderungen eines RDF Graphen. Änderungsoperation wie Einfüge-, Lösch und Updateoperation waren mit einem Zeitstempel assoziiert, mit dieser Architektur wäre es möglich zu jeder Zeit vergangene Zustände zu traversieren. Aus beiden Bespielen geht hervor, dass die Interpretation der Zeit in Zusammenhang mit Datenverwaltung sehr unterschiedlich sein kann. Diese Unterschiede werden im Laufe des Kapitels erläutert. Unter anderem werden das Modell zur Zeitrepräsentation vorgestellt, und die Frage, wie sich die unterschiedliche Semantik der Zeit auf Anfragen auswirkt, geklärt. Als erstes werden Zeitbegriffe und formale Modelle aus dem relationalen Modell präsentiert. Danach wird gezeigt, wie diese Begriffe sich auf RDF zeitabhängige Daten übertragen lassen Temporale Modelle in relationalen Datenbanken Dieses Unterkapitel beschäftigt sich mit der Frage, wie sich das relationale Modell um eine Zeitdimension erweitern lässt. Im weiteren Verlauf der Arbeit werden wir sehen, dass die vorgestellten Konzepte sich auch auf RDF zeitabhängige Daten anwenden lassen. Formal können wir die Zeit als geordnete Menge über eine Domain von Elementen (Zeiteinheiten) interpretieren. Aus der theoretischen Perspektive spielt die Granularität von der Menge keine große Rolle. Zusammengefasst können wir die Zeit als folgende Struktur (T, <) temporale Domain definieren: Definition (Temporale Domain) Eine temporale Domain ist eine Struktur T d = (T, <), mit T als Trägermenge von Zeiteinheiten und linearer Ordnung < auf T. Als Trägermenge können z.b. natürliche oder ganze Zahlen N,Z fungieren. Nachdem T d formal definiert ist, kann die temporale Datenbank D t definiert werden. Das relationale Datenbankmodell lässt sich im Allgemeinen in verschiedener Weise mit der Zeitdimension erweitern. Dazu betrachten wir zunächst zwei unterschiedliche, aber von der Ausdruckstärke äquivalente abstrakte temporale Modelle. Die erste Möglichkeit formal die temporale Datenbank zu beschreiben ist eine Funktion zu definieren, die als Eingabe Elemente aus T erhält und als Ausgabe die relationale Datenbank, mit zu diesem Zeitpunkt gültigen Daten, produziert. Die zweite Möglichkeit ist die Einführung von zusätzlichen temporalen Attributen. Im Folgenden werden beide Optionen formaler beschrieben:

15 2.1 Temporale Modelle in relationalen Datenbanken 15 Beim Snapshot Modell werden einzelne Snapshots(Inhalt der Tabellen zu einem Zeitpunkt) der Datenbank, als Ausgabe eine Funktion von T DB(D, ρ) betrachtet, wobei DB(D, ρ) eine Datenbank über Datendomain D mit Schema ρ = {r 1... r n } ist. Der Datentyp von Relationen bei diesem Modell hat dann folgende Signatur T (D n bool). Timestamp Modell: Bei diesem Modell werden Relationen (Tabellen) um ein temporales Attribut erweitert und haben somit folgende Typsignatur T D n bool. Sowohl aus theoretischen als auch aus praktischen Gründen hat das Timestamp Modell mehrere Vorteile. In der Praxis können relationalen Tabellen direkt durch Aufnahme von Zeitattributen auf temporale Relationen erweitert werden. Ein anderer Vorteil ist z.b., die dass die Anfragen nach allen Zeitpunkten fragen, bei denen die Bedingung ϕ erfüllt ist, von der Komplexität sich leichter beantworten lassen, als bei der Umsetzung des Snapshot-Modells. {t : DB = ϕ(t)} Aus diesen Gründen hat sich das Timestamp Modell in relationalen Datenbanken durchgesetzt. Allerdings sind die beiden Modelle von Ausdruckstärke äquivalent Zeitsemantik Die Zeitkomponente im temporalen Modell kann unterschiedliche Interpretation (Semantik) besitzen, z.b. (vgl. Bsp , 2.0.2) ist t in der Relation ein Zeitpunkt des Einfügens eines Tupel oder es ist die Zeit, in der ein Tupel in der modellierten Welt gültig ist. Im folgenden werden die wichtigen Konzepte der temporalen Datenbanken hinsichtlich der Bedeutung der Zeitkomponente vorgestellt. Snapshot Datenbanken sind die Datenbanken, die nur den aktuellen Zustand verwalten (diese werden voll von modernen DBMS unterstützt ( Anfragesprachen, Integritätsbedingungen, Datenstrukturen, Indexstrukturen etc.). Dabei zeichnet sich ein Zustand einer relationalen Datenbank durch den aktuellen Inhalt seiner Tabellen. Datenmanipulierende Operationen einer Datenbank (z.b. UPDATE, INSERT oder DELETE SQL Befehle) erlauben den aktuellen Inhalt zu verändern, gegebenenfalls zu korrigieren und dem Modell anzupassen. Durch diese Operationen ändert sich der Zustand der Datenbank, wobei der vorhergehende Zustand verworfen( vergessen ) wird. In der Praxis gibt es eine Reihe von Anwendungen (z.b. Archivierungssysteme), in denen nicht nur der aktuelle Zustand einer Datenbank, sondern auch die vorhergehenden Zustände (Versionen) von Interesse (vgl. Bsp ) sind. Die Evaluation von Zuständen einer Datenbank über die Zeit wird auch als Historie bezeichnet. Wird dieser Begriff mit dem Snapshot-Modell verglichen, so stellt man fest, dass sie sehr viel gemeinsam haben. Die Datenbanken,die die Historie verwalten, werden als Transaktionszeit-Datenbanken definiert. In dieser Art von Datenbanken ist es möglich deren Versionen zu jedem Zeitpunkt in der Vergangenheit aufzurufen und Anfragen auf diese Version zu stellen. In diesen Anwendungen ist die Zeit durch so genannte Transaktionszeit ausgedrückt, das ist die Zeit, die den Zeitpunkt einer datenmanipulierenden Operation mitprotokolliert. Diese Operationen, die unter anderem zur Korrektur von Daten dienen, operieren auf dem aktuellsten Zustand, und erzeugen somit einen neuen Zustand. Dem Transaktionszeit-Begriff steht die Validzeit gegenüber. Dieser Zeitbegriff beschreibt die Gültigkeit eines Faktes in der modellierten Welt, der durch Datenbanktupel beschrieben ist. Die Schwierigkeit der Verwaltung von Validzeitdaten liegt in der Gewährleistung der Korrektheit der Daten bezüglich ihrer Gültigkeit in der modellierten Welt. In diesen Datenbanken wird stets angestrebt den aktuellen korrekten Zustand zu gewährleisten. Dadurch ist die Semantik von solchen Datenbanken viel komplexer als bei Snapshot-Datenbanken, z.b. in

16 2.1 Temporale Modelle in relationalen Datenbanken 16 Abbildung 2.2.: Die Abbildung veranschaulicht die Zeitbegriffe in relationalen Datenbanken. Quelle [15] Hinsicht auf Anfragen und Gewährleistung von Integritätsbedingungen. Bei der Überführung von einem konsistenten Zustand einer Validzeit-Datenbank in eien neuen Zustand werden alte Zustände (gegebenenfalls auch fehlerhafte Versionen) verworfen und nicht mitgespeichert. Würde man auch diese Zustande mitverwalten, spricht man dann auch von Bitemporalen Datenbanken. Es gibt auch eine dritte Form der Zeit in Datenbanken, eine so genannte userdefinierte Zeit. Sie gilt, um temporale Aspekte von Daten zu beschreiben, die nicht durch oben genannte Zeitdefinitionen abgedeckt sind. Zum Beispiel: Geburtstag-Information von Mitarbeitern der Mitarbeiter-Relation. Diese Zeit ist zwar eng mit der Validzeit verwandt, wird aber ohne große Schwierigkeiten von modernen DBMS unterstützt, da nur Datentypen für interne Repräsentation und Ein-Ausgabe Funktionen für diese Datentypen definiert werden müssen Darstellung von Zeit Ein sehr wichtiger Aspekt, der sehr starken Einfluss auf die praktische Umsetzung hat, ist die Zeitdarstellung. Es gibt drei fundamentale Datentypen für die Zeitdarstellung[16]: Ein einzelner Zeitpunkt. Der drückt z.b. das ein Ereignis zum Zeitpunkt t stattgefunden hat. Die Dauer eines Faktes oder Ereignisses z.b. drei Tage, acht Stunden. Ein Zeitintervall ist ein zu einem Zeitpunkt gebundene Zeitraum. In der Praxis wird im Allgemeinen eine diskrete Domain für die Zeiteinheiten verwendet 2 Ein interessante Fragestellung ist, wie die Zeitintervalle interpretiert werden, als Menge von Punkten eingeschlossen zwischen Start- und Endpunkt oder als ein eigenständige Objekte. Grundsätzlich gibt es zwei unterschiedliche Repräsentationens-Modelle in Datenbanken Punkt- und Intervall-Modell [19] [16]. Je nach Deutung, werden auch unterschiedliche Ergebnisse bei der Anfrageverarbeitung produziert. Das folgende Beispiel erklärt die Unterschiede von den beiden Interpretationen [19]: 2 Seit SQL 92 Standard bietet SQL spezielle Datentypen und Operationen für Zeitdarstellung: DATE, TIME, TIMESTAMP, und TIMEINTERVAL. SQL 99 zusätzlich bietet den PERIOD Datentyp. Wobei der TIME- INTERVAL entspricht der Dauer, und PERIOD dem Zeitintervall in dieser Arbeit verwendete Konvention.

17 2.1 Temporale Modelle in relationalen Datenbanken 17 r1: ID: Interval pn42 [20, 30] pn42 [31, 40] pn42 [41, 50] r2: ID: Interval pn42 [26, 32] Im Beispiel werden auf zwei Tabellen r1 und r2 Differenzoperator angewendet, je nach definierte Semantik erhält man verschiedene Ausgabe. Die werden der Reihe nach besprochen: R1: ID: Intervall pn42 [20, 25] pn42 [33, 50] R2: ID: Interval pn42 [20, 30] pn42 [31, 40] pn42 [41, 50] R3: ID: Interval pn42 [20, 25] pn42 [33, 40] pn42 [41, 50] Bei der ersten Ergebnistabelle, die Semantik der Anfrage kann als Berechnung von allen Einträgen interpretiert werden, die gültig in den Zeitpunkten sind, die nicht in der Tabelle r2 vorhanden sind. Diese Interpretation entspricht dem Punktmodell. Beim genauen Betrachten, stellt man fest, dass bei der Ausgabetabelle zwei [33, 40] und [41, 50] Intervalle zusammengeschmolzen wurden. Das Prozess der Vereinigung von aufeinanderfolgenden oder überlappenden Intervallen von Tupeln mit den gleichem Schlüssel wird Colescing genannt. Die Tabelle R2 ist auf ersten Blick äquivalent zum Ergebnis einer normalen relationalen Differenz. Das kommt daher, dass die Intervalle in diesem Fall, als atomare Werte betrachtet werden. Diese Semantik von Intervallen gehört zum Intervall-Modell. Die Ausgabe-Tabelle R3 besitzt die selbe Semantik wie die erste Ausgabe, der Unterschied ist, dass der Colescing-Schritt ausgelassen wurde. Wird die Funktion, die einzelne Snapshots der Datenbank zu den Zeitpunkten liefert, analog dem Snapshot-Modell auf die Tabellen angewendet, so stell man fest, dass die beiden Ausgabetabellen die selbe Menge von Daten zu jedem Zeitpunkt besitzen. Diese semantische Gleichheit bezüglich allen Snapshots wird als Snapshot-Äquivalenz bezeichnet. Je nach Interpretationen müssen die speziellen Operatoren entwickelt werden, um die gewünschte Ausgabe zu erhalten. Eine weitere Fragestellung ist die Darstellung von Intervallen in Punkt- und Interavall-Modell. In der Praxis werden Zeitintervalle entweder als [x s, x e ] oder [ x s, x e ) dargestellt, wobei letztere Darstellung kleine Vorteile bringt. Betrachten wir das folgende Beispiel[16]. Angenommen wie wollen wissen, ob Intervall I 1 den Intervall I 2 schneidet, bei der Darstellung I 1 = [x s, x e ], I 2 = [y s, y e ] es ist genau dann der Fall, wenn folgende Bedingung erfüllt ist: (x s y e y s x e ) bei Halb-offene Repräsentation gehört zwar der Endpunkt nicht zum Intervall, dafür wird aber Operator durch < ersetzt, dann gilt für I 1 = [ x s, x e ), I 2 = [ y s, y e ) (x s < y e y s < x e ) Aus praktischen Gründen wird die Halb-offene Darstellung bevorzugt. Im Unterschied zu einzelnen Zeitpunkten, sind Zeitintervalle nur partiell geordnet. Dennoch können die Beziehungen auf Intervallen betrachtet werden z.b. Überlappung, liegt erste Intervall vor dem

18 2.2 Temporal RDF 18 zweiten etc. Insgesamt stehen die Intervalle in dreizehn verschiedenen Beziehungen zu einander Temporal RDF Nachdem grundsätzliche Begriffe aus temporalen Datenbanken erläutert wurden, wird in diesem Unterkapitel kurz ein formales Modell zur Anreicherung von RDFs Frameworks mit Zeitsemantik präsentiert. Das Unterkapitel basiert hauptsächlich auf der Arbeit von [20]. In der Arbeit haben die Autoren die formalen Grundlagen aus der temporalen Erweiterung der relationalen Datenbanken für die formale Definition von temporalem RDF verwendet. Es gibt auch eine Reihe von anderen Forschungsarbeiten auf diesem Gebiet[21][22]. In [20] wird das Timestamp-Modell auf RDF angewendet. Ähnlich wie bei der Einführung der Zeitdimension in relationalen Datenbanken können in RDF Framework zwei Möglichkeiten in Betracht gezogen werden. Bei der Verwendung des Snapshots-Modells würden die Zustände des RDF Graphen zu den jeweiligen Zeitpunkten gespeichert. Bei dem Timestamp-Modell wäre eine Möglichkeit die Tripel direkt mit Zeitinformation zu assoziieren. Das erste Modell, ähnlich der relationalen Welt, hat kleine Nachteile z.b. bei der Verwaltung von Validzeit-Daten und Anfrageverarbeitung. Es kann aber für Transaktionszeitdaten verwendet werden, da die Transaktionszeit viel Gemeinsam mit Versionierungskonzept hat (nähe zur Versionierung von RDF Daten wird im nächsten Kapitel beschrieben). Ähnlich wird, wie in vorigen Abschnitt, in[20] argumentiert das Timestamp-Modell besser geeignet als temporales Modell für die Einführung der Zeitdimension in RDF. Das Grundkonzept des Timestemp-Modell in RDF ist Labeling, mit anderen Worten, explizite Assoziation von temporalen Information z.b. Gültigkeitsintervalls mit einem RDF Tripel. Mit diesem Konzept kann sowohl die Validzeit als auch die Transaktionszeit ausgedrückt werden. Für die Interpretation der Intervalle in [20] kann sowohl das Punkt- als auch Intervall Modell für die Anfrageverarbeitung verwendet werden. Durch die Verwendung des Timestamp-Modells lässt sich die Zeitdimension leicht durch die Erweiterung der Tripeltable mit Zeit-Attributen darstellen: CREATE TABLE TRIPLE_TABLE( RDF_Subject TEXT, RDF_Predicate TEXT, RDF_Object TEXT, Start TIMESTAMP, End TIMESTAMP ); Es gibt aber auch eine andere Möglichkeit, nämlich die Zeitkomponenete über die RDF selbst auszudrücken. Dazu werden die Reification-Tripel verwendet. Mit diesem Konzept kann auf die Erweiterung der Tripletable um Zusatzattribute verzichtet werden. Temporalen Annotationsdaten über temporale Tripel werden auch in RDF ausgedrückt und können mit RDF Daten verwaltet werden. Dabei könnten die Reification-Tripel direkt in der Tripeltable von dem temporalen Graphen gespeichert werden. Es kann auch eine Zusatztabelle für diesen Zwecken angelegt werden. Aus den praktischen Sicht gibt es sowohl Vor- und Nachteile bei beiden Techniken. Bei der zweiten Lösung z.b. für die Anfargeverarbeitung müssen erst die Reifications-Tripel berechnet werden, bei der ersten dagegen, ist die Zeitinformation fester Bestandteil eines

19 2.2 Temporal RDF 19 Abbildung 2.3.: A) Beschreibt die Reification mit Bezug auf Punktmodell; B) Temporale Reification mit Intervall-Modell Datenbanktupel. Einer der Vorteilen der zweiten Lösung ist, dass auch Aussagen über die Reifications-Tripel gemacht und mitverwaltet werden können. Bei der ersten Möglichkeit müssen erst durch eine z.b. Mapfunktion die Zeitinteravallinformation auf Reificationsgraphen abgebildet werden. Trotz der offensichtlichen Einfachheit der ersten Technik, wird die zeitliche Vokabular und Reification eingeführt, um die Syntax von temporalen RDF Graphen zu definieren. Dadurch lassen sich Aussagen über die Zeitdimension erstellen, das wiederum ermöglicht semantische Besonderheiten des RDF beizubehalten. In Abbildung 2.3 kann der Beispiel-Reifikationsgraph veranschaulicht werden. Der zentrale Begriff, der in [20] eingeführt wird, ist der Temporalle RDF Graph 3. Im Folgenden wird eine semantische Sicht auf den temporalen RDF Graph präsentiert: Definition (Temporaler RDF Graph) Ein temporale RDF Graph ist die Mengen von temporalen Tripel. Eine temporale RDF Tripel ist ein Triple mit (s,p,o)[t], wobei t ist ein temporales Label. Die Notation (s,p,o)[t 1, t 2 ] bezeichnet die Menge {(s, p, o) [t] t 1 t t 2 } Ein recht simples Konzept, das auf Grundlage des Timestamp-Modells basiert. Trotz dieser Einfachheit lassen sich andere Begriffe aus der formalen Semantik des Frameworks wie Teilgraph, Ableitung und Clousur auf Zeitdimension erweitern[20]. Da die temporale Erweiterung von RDF nach [20] nicht der Bestandteil von RDF ist, wird das Framework um spezielles temporales Vokabular erweitert. Mit diesem Vokabular können dann die Reification-Tripel definiert werden. Die Standardsyntax von RDF kann somit auf temporale Erweiterung angereichert werden( vgl. Abbildunng 2.3 ): 3 Ein geschlossenes Intervall [x a, x e] in dem Modell repräsentiert die linear geordnete Menge von Zeiteinheiten über einer diskreten Domain.

20 2.2 Temporal RDF 20 Definition (Temporales Vokabular nach [20]) Das temporale Vokabular zur Definition von Reification-Tripel besteht aus: temporal (Kurz. tmp), instant (Zeiteinheit), interval(zeitinterval), initial (Startpunkt des Zeitintervalls) und final (Endzeitpunkt). Diese RDF Typen sind von dem Typ property(prädikate). Zusätzlich wird der aktuelle Zeitpunkt durch now dargestellt( mit dem Typ plain Literal). Der Definitonsbreich von instant, initial und final sind die natürlichen Zahlen. Wohl bemerkt, haben die Autoren auf die Standard Reifikationsvokabular von RDF verzichtet, um die Unabhängigkeit der temporalen Erweiterung zu gewährleisten (Es wird z.b. statt rdf:subject tsubj verwendet). Syntaktisch wird der temporale RDF Graph nach [20] wie folgt definiert(vgl. Abbildung 2.3): Definition Syntaktisch das temporale Tripel mit eingeführtem temporalen Vokabular hat eine der folgenden Strukturen: (s,p,o), reif(s,p,o,x) 4, (X, tmp, Y), (Y, instant, n), mit n als natürliche Zahl. Als Abkürzung wird folgende Notation verwendet (s,p,o)[x, Y, n] (s,p,o), reif(s,p,o,x), (X, tmp, Y), (Y, interval, Z), (Z, initial, I), (Z, final, F), wobei F, I natürliche Zahlen sind. Abgekürzt wird mit (s,p,o)[x, Y, I, F ] Temporaler RDF Graph ist definiert dann durch die Menge von temporalen RDF Tripel. Mit Hilfe der Reification und temporalem Vokabular wird in [20] die Einführung des neun Begriffs anonyme Zeit ermöglicht. Durch das Konzept des leeren Knoten können die Zeitangaben von Labels nicht nur als Konstante, sondern auch als Variablen, behandelt werden. Z.B. wenn die Gültigkeit einer Aussage aktuell nicht bekannt ist, kann das durch (s, p, o) : [X] ausgedrückt werden ( mit X als anonyme Zeitvariable, die ausdrückt, dass das Tripel in einer unbekannte Zeit gültig ist). Eine der Anwendungen diese Technik ist Assoziierung von unvollständiger temporaler Information. Anderer Vorteil von diesem Konzept, dass ein nicht-temporaler Graph in einen temporalen RDF Graph umgewandelt werden kann. Zusätzlich ermöglicht die Einführung der Zeitvariablen die Zeitangaben abzuleiten. Ein temporaler RDF Graph, der um die anonyme Zeitvariablen erweitert wird, wird als generalisierter temporaler RDF Graph definiert 5. Die Einführung des generalisierten temporalen RDF Graphen mit Zeitvariablen erlaubt eine Anfragesprache für temporale RDF Daten zu definieren. Die Anfragesprache folgt dem SPARQL-Graph-Matching-Modell und basiert auf der Tableu-Anfragen für einen Graph- Datenmodell. Als kleines Beispiel, betrachten wir folgende Anfrage an unsere Beispiel- Datenbank: Finde alle Projekte in Bereich Semanitk-Web an der Fachbereich Mathematik und Informatik der Uni-Marburg zwischen 2000 und 2006 (X?, type, projekt) (X?, type, projekt) [T?], (X?, gebiet, Semanitk Web) [T?], ( hatprojekt, X?) [T?], 2000 T?, T? Die Sprache muss natürlich eine eingebaute Arithmetik für die Zeitinetravalle bereitstellen. Zusätzlich wurden im Paper die optionale Zusatzoperatoren besprochen, wie Aggregation Max und Min z.b. die Anfragen wie Gibt das längste Zeitintervall in dem die Aussage (s,p,o) gültig war. Die Vertiefende Diskussion über Komplexität und Ausdruckstärke der Sprache und andere Besonderheiten der temporalen Sprachen für RDF sind in [20] beschrieben. 4 reif ist Abkürzung für Reification 5 In [20] vertieft die Semantik der generalisierte temporale RDF Graph präsentiert