Diplomarbeit Semantic Web & Caché

Transkript

1 Johann Wolfgang Goethe-Universität Frankfurt am Main Fachbereich Biologie und Informatik (15) Institut für Informatik Lehrstuhl für Datenbanken und Informationssysteme Diplomarbeit Semantic Web & Caché Objektorientierte Speicherung des RDF-Modells in die postrelationale Datenbank Caché von InterSystems vorgelegt von: Christoph Karwoth Betreuer: Herr Karsten Tolle Bearbeitungszeitraum: 28. Mai bis 13. Dezember 2004 Erstprüfer: Herr Prof. Dott.-Ing. R. V. Zicari

2 Kurzfassung 2

3 Kurzfassung 3 Kurzfassung Die Nutzung von RDF wird immer öfter in Anspruch genommen um eine Katalogisierung der Flut von Daten im Internet zu ermöglichen. Doch auch diese Beschreibungen müssen gespeichert, ausgewertet, analysiert und überprüft werden. So entsteht Bedarf nach einer guten Umgebung, um diese Aspekte umzusetzen und RDF weiter zu etablieren. Die Datenbank Caché von InterSystems als postrelationale Datenbank bietet viele Eigenschaften, welche dem RDF-Modell ähneln und somit eine Speicherung unterstützen. Es existieren zwar Modelle für relationale Datenbanken, doch sie können Eigenschaften wie objektorientierte Datenstruktur oder multidimensionale Variablen nicht. In dieser Arbeit wird ein RDF-Modell für Caché entwickelt, welches RDF-Daten in objektorientierter Form speichert. Zusätzlich wird eine Schnittstelle für den Import der RDF-Daten nach Caché präsentiert und implementiert. Schlagwörter: Semantic Web, RDF, InterSystems, Caché, postrelationale Datenbanken Abstract RDF is widely used in order to catalogue the chaos of data across the internet. But these descriptions must be stored, evaluated, analyzed and verified. This creates the need to search for an environment to realize these aspects and strengthen RDFs influence. InterSystems postrelational database Caché exposes many features that are similar to RDF and provide persistence with semantic part. Some models for relational databases exist but these lack features like object-oriented data-structures and multidimensional variables. The aim of this thesis is to develop an RDF model for Caché that saves RDF data in an object-oriented form. Furthermore an interface for importing RDF data will be presented and implemented. Keywords: semantic web, RDF, InterSystems, Caché, postrelational database

4 Abstract 4

5 Erklärung 5 Erklärung Hiermit erkläre ich, dass ich die vorliegende Diplomarbeit selbständig angefertigt habe. Es wurden nur die in der Arbeit ausdrücklich benannten Quellen und Hilfsmittel benutzt. Wörtlich oder sinngemäß übernommenes Gedankengut habe ich als solches kenntlich gemacht. Ort, Datum Unterschrift

6 Erklärung 6

7 Inhaltsverzeichnis 7 Inhaltsverzeichnis Kurzfassung...3 Abstract...3 Erklärung...5 Inhaltsverzeichnis...7 Abbildungsverzeichnis...10 Abkürzungsverzeichnis...11 Vorwort Einleitung Grundlagen Begriffe in Rahmen dieser Arbeit RDF RDF Graph & Tripeldarstellung RDF/XML RDFS- Resource Description Framework Schema Caché von InterSystems MUMPS der Urknall von Caché Caché postrelationale Datenbank Anwendungsumgebung Datenhandhabung Vergleich zu OO-Programmiersprachen Schnittstellen Ziele Stand der Technik RDF Serialisierung Relationale Abbildung von RDF RDF Applikationen & Tools Semantic Web Framework - Jena RDF-S Parser und Validierer Caché, XML und RDF...21

8 Inhaltsverzeichnis 8 5 Viele Wege von RDF nach Caché RDF und relationale Schnittstellen RDF und objektorientierte Schnittstellen Import als XML ActiveX und WSDL Java Caché Server Pages (CSP) SOAP Interne Lösung mit Caché Script Entscheidung: Die Mischung macht s Der Trade Off zwischen Caché und RDF Gemeinsamkeiten Differenzen RDF in Caché Metaschema RDF-Resource RDF-Property RDF-Class RDF-Container RDF-Collection RDF-Statement Erweiterung von Metaschema RDF Schema Ressourcen Beschreibung - Objekte und Dokumente Beschreibung der Ressource durch mehrere Statements Mehrfachverwendung einer Ressource Literale Anonyme Knoten Ressourcenbeschreibung wird zum Schema Listen, Objekte oder Multi-Globals Verwaltung von RDF Vorgehensweise bei der Importierung der RDF-Daten Tauglichkeit von Caché für RDF Vorteile von Caché Nachteile Zusammenfassung, offene Fragen und Ausblick Zusammenfassung Ausblick und offene Fragen...21

9 9.2.1 Entfernen von vorhandenen Ressourcen Namespaces Kompilier & Rollback Export Semantikprüfung Weitere Zusatzfunktionen Weitere Prüfungen des Modells SOAP Erweiterung...21 Anhang...21 Anhang I...21 Anhang II...21 Anhang III...21 Anhang IV...21 Anhang V...21 Literaturverzeichnis...21 Stichwortverzeichnis

10 Abbildungsverzeichnis 10 Abbildungsverzeichnis Abbildung 1-1. Zusammenhang und Inhalt der Arbeit...15 Abbildung 2-1. Zusammensetzung eines Statements...19 Abbildung 2-2. Ressource...19 Abbildung 2-3. In Caché Studio werden die Caché-Klassen bequem programmiert...21 Abbildung 2-4. Der Caché Explorer dient zur Übersicht über den Inhalt der Datenbank...21 Abbildung 2-5. Im Caché Terminal können Daten eingegeben werden oder Routinen aufgerufen werden...21 Abbildung 2-6. Der SQL-Manager erlaubt Betrachtung der Daten aus der Relationalen Seite Abbildung 2-7. Die Systemarchitektur von Caché...21 Abbildung 2-8. Klassentypen...21 Abbildung 2-9. Persistente und eingebettete Klassen...21 Abbildung 4-1. Jena Architektur [Jena-Sematic]...21 Abbildung 5-1. Wie kommt man von RDF zu Caché?...21 Abbildung 5-2. Möglichkeit der Nutzung von Cachés XML-Import mit Zwischenschritt...21 Abbildung 5-3. Zusammenarbeit von Web- und Datenbankenserver bei der Verarbeitung einer CSP-Seite...21 Abbildung 5-4. Webservice für RDF Import einer beliebigen RDF-Datei Abbildung 5-5. Verbindung von RDF über Java zu Caché...21 Abbildung 7-1. Schematischer Aufbau von RDF...21 Abbildung 7-2. Ansicht von Global ^MetaSchema.RDFType im Caché-Explorer...21 Abbildung 7-3. Zusammensetzung von MetaSchema im Caché. In den Caché- Klassen sind die Caché-Properties aufgelistet...21 Abbildung 7-4. Nutzung der rdf:type und rdfs:subclassof Properties in RDF Abbildung 7-5. Darstellung von Ressourcen erfolgt in Caché in zwei Komponenten als Klasse und Instanz...21 Abbildung 7-6. Im SQL-Manager können die eingefügten Literale eingesehen werden...21 Abbildung Grafische Oberfläche des Java-Import-Clients....21

11 Abkürzungsverzeichnis 11 Abkürzungsverzeichnis CS Caché Script Ist die interne objektorientierte Programmiersprache von Caché. CSP Caché Server Pages Webservice für Internet und Intranet von Caché, der u. a. dynamische HTML Seite bzw. XML-Dateien aus der Datenbank generiert. GUI Graphical User Interface Graphische Benutzerschnittstelle, welche die Interaktion mit einem Benutzer erleichtert. JDBC Java Database Connectivity Standardschnittstelle in Java für relationale Datenbanken zur SQL Interaktion. MUMPS Massachusetts General Hospital Utility Multi-Programming System Ist die Vorversion von Caché, auf welcher Caché aufbaut. ODBC Open Database Connectivity Standardschnittstelle für relationale Datenbanken zu SQL Interaktion auf der Windowsplattform. OID Objektidentität Ist eine eindeutige Bezeichnung eines Objektes in Caché, welches sich aus dem Namen der Klasse und einer eindeutigen Nummer zusammensetzt. OO Objektorientiert Ein Ansatz zur Modellierung eines Verhaltens als Objekt, durch Objektklassen und Instanzen. Dabei wird das Objekt durch Eigenschaften und Methoden abgebildet und ermöglicht ein Kapselung von weiteren Objekten. OREF Objektreferenz Eine eindeutige Referenz für eine im Speicher (RAM) erstellte Instanz eines Objektes.

12 Abkürzungsverzeichnis 12 RDF Resource Description Framework Eine von World Wide Web Consortium (WC3) entwickelte Möglichkeit der Beschreibung von unter anderen Internetressourcen als Metadata. RDFS RDF-Schema Erweiterung von RDF, welche ermöglicht die Definition vom Vokabular und die Beschreibung benutzterspezifische Klassen von Ressourcen. RDF/XML RDF - Modell in XML Format Eine Möglichkeit RDF zu Serialisieren und zu Speichern. SOAP Simple Object Access Protokol Ein Webservice, der Daten im XML Form zum Austausch in Internet nutzt. SQL Structured Query Language Eine weit verbreitete Abfragesprache für relationale Datenbanken. URI Uniform Resource Identifier Stellt eine eindeutige Identifizierung einer Ressource, nicht nur in Netzwerk. Die bekanntesten URI-Formen sind http, mailto und ftp. URIref URI Reference Eine genaue Identifizierung innerhalb einer Ressource, welche durch das Zeichen # angedeutet wird. Dieses Zeichen dient zur Trennung von URI und der Sektion. W3C World Wide Web Consortium Eine Gemeinschaft, welche über die Vorgaben im WWW entscheidet. WWW World Wide Web Ein weltweites Netzwerk, in dem Informationen in digitaler Form ausgetauscht werden können. XML Extensible Markup Language Eine Beschreibung von Dokumenten in Textform, welche durch Ausdrücke (Tags) wie in HMTL strukturiert werden kann.

13 Vorwort 13 Vorwort Die hier vorgestellte Diplomarbeit ist an der Professur Datenbanken und Informationssysteme des Fachbereiches Biologie und Informatik der Johann Wolfgang Goethe Universität Frankfurt am Main entstanden. Ein Ansporn zur Wahl dieses Themas war die Erfahrung das ersten Mal mit einer postrelationalen Datenbank, insbesondere dem sehr interessanten Konzept von Caché, arbeiten zu können. Zusätzlich ergab sich auch die Möglichkeit einen tiefen Einblick in das Semantic Web zu bekommen, besonders bei Resource Description Framework (RDF). Aber auch die Aufgabe zwei verschiedene Systeme zusammen fügen zu können. Diese Arbeit sollte ohne Kenntnisse von CachéScript oder Semantic Web gelesen und verstanden werden können. In Kapitel 2 Grundlagen werden alle Begrifflichkeiten geklärt, welche gebraucht werden, um diese Arbeit zu verstehen. Es wird jedoch vorausgesetzt, dass der Leser über Grundkenntnisse des objektorientierten Ansatzes verfügt und die allgemeinen Begrifflichkeiten aus dem Bereich der Datenbanken kennt. Über Rückmeldungen in Form von konstruktiver Kritik, Anregungen oder Verbesserungsvorschläge an meine adresse (municio@web.de), freue ich mich sehr. Unter der Adresse sowie unter kann die Diplomarbeit, wie auch alle zugehörigen implementierten Dateien, bezogen werden. Herzlichen Dank an meinen Betreuer Karsten Tolle, der immer konstruktive Fragen und Anregungen eingebracht hat, an Karin Schatz-Cairoli für sehr guten Support seitens InterSystems Darmstadt, sowie an die Korrekturleser dieser Arbeit Tatiana Wagner, Nadine Busch und Leschek Karwoth. Die Ideen für Struktur und Gliederungen dieser Arbeit habe ich aus Dokumentvorlage für Diplomarbeiten und andere wissenschaftliche Arbeiten 1 von Prof. Dr. Wolf-Fritz Riekert, an den gleichfalls mein Dank gilt. Zuletzt gebührt mein Dank meinen, Eltern die mich mit vollem Einsatz über mein ganzes Studium unterstützt haben. Diese Diplomarbeit wurde mittels Microsoft Word XP und Adobe Acrobat 6.0 nach den Regeln der neuen Rechtschreibung erstellt. 1 Zugriff am unter v.hdm-stuttgart.de/~riekert/theses/, v.hdm-stuttgart.de/~riekert/

14 1 Einleitung 14 1 Einleitung Im Durchschnitt produziert jeder Mensch - Mann, Frau und Kind - in einem Jahr 333 MByte an digitalen Daten, rechnet Imation vor. Was die große Mehrzahl der Menschen in ihrem Leben jedoch tatsächlich zu Papier bringt, würde nicht einmal fünf Disketten füllen. [...] Alleine die im World Wide Web veröffentlichten Texte, Bilder und Videos betragen laut Imation etwa zehn Petabyte [CHIP-Imation]. Der Anstieg der Daten im World Wide Web (WWW) ist nicht zu übersehen und bringt immer wieder beeindruckende Zahlen zum Vorschein. Damit aber in diesem unendlich weiten Internet brauchbare Informationen gefunden werden können, reicht bei weitem eine sinnlose Suche nach übereinstimmenden Wörtern auf den Homepages nicht aus. Um auf die gewünschten Daten besser zugreifen zu können, hat das World Wide Web Consortium (W3C) das Semantic Web ins Leben gerufen. W3C zählt über 350 Mitglieder, welche aus großen und kleineren Firmen in aller Welt kommen [W3C- Home]. Diese neue Richtung bestand aus einem Resource Description Framework (RDF), welches ermöglichen sollte, Metadaten maschinell auszuwerten. Aus diesem Grund wurde für die praktische Anwendung von RDF das weit verbreitete Extensible Markup Language (XML) verwendet. Dieses Gespann nennt man auch RDF/XML [RDF-Home]. Dieses Serialisierung hat auch Anwendung in der Suchmaschine Google [GOOGLE] gefunden, um die Suche zu optimieren. Der XML Standart hat sich mittlerweile sehr stark verbreitet und kaum eine Datenbank verfügt nicht über eine entsprechende Schnittstelle, um XML Daten zu importieren. Bei RDF ist das noch nicht der Fall obwohl, die RDF-Struktur eine Erweiterung von XML darstellt, reicht es nicht aus, eine RDF/XML Datei einfach zu importieren, da RDF einen objektorientierten (OO) Ansatz verfolgt. Damit werden objektorientierte Datenbanken angesprochen, die über entsprechende Strukturen verfügen, um RDF im vollen Umfang zu speichern. Caché von Intersystems ist eine objektorientierte Datenbank, welche in der Lage ist, RDF-Daten zu speichern und zu verwalten. Um zu entscheiden, ob es überhaupt eine Importierung von RDF-Daten nach Caché in Frage kommt, werde ich im Kapitel 2 die Grundlagen und Stärken von RDF und Caché unter die Lupe nehmen. Da RDF im Gegensatz zu XML den OO-Ansatz verfolgt, gibt es hier andere Anforderungen an ein Importierungsinterface. In wie weit der OO-Ansatz und die Ausnutzung von Cachés Möglichkeiten genutzt werden können, muss klargestellt werden. Diese Ziele werden in Kapitel 3 erarbeitet.

15 1 Einleitung 15 In Kapitel 4 werde ich dem Stand der Technik erläutern, da RDF im Internet eine bedeutende Rolle spielt, findet man Anwendungen, welche sich bereits mit dem Problem beschäftigen. Dabei gilt es zu untersuchen in wie weit diese unserem Problem entsprechen. Caché bietet einiges an Schnittstellen für die Kommunikation mit anderen Systemen. Diese werden im Kapitel 5 untersucht und ein geeignetes auszuwählen. Ein direkter Vergleich von RDF und Caché erfolgt im Kapitel 6. Anschließend werden im Kapitel 7 die Details über die interne Verwaltung und Handhabung von RDF-Strukturen in Caché erarbeitet. Danach erfolgt die Auswertung des Modells im Kapitel 8. Die Zusammenfassung, alle Kritikpunkte, Anregungen und offene Fragen, die während der Erarbeitung und Entwicklung sich ergeben haben, finden ihren Platz im Kapitel 9. Die folgende Abbildung stellt den Inhalt der Arbeit graphisch dar: Abbildung 1-1. Zusammenhang und Inhalt der Arbeit

16 2 Grundlagen 16 2 Grundlagen Das Semantic Web ist einer der großen Begriffe, der auch diese Arbeit prägt. Das Semantic Web liefert einen allgemeinen Rahmen, welcher erlaubt, über Anwendungen, Unternehmen und Gemeinschaftsgrenzen geteilt und wiederverwendet zu werden. Es ist eine gemeinschaftliche Bemühung, die durch W3C mit Teilnahme von vielen Forschern und von industriellen Partnern verfolgt wird. Es basiert auf dem Resource Description Framework (RDF), der eine Vielzahl von Anwendungen mit Benutzung von XML für Syntax und URIs für die Namensgebung integriert [W3C-SW]. Deshalb wird das RDF Konzept im Abschnitt 2.2 RDF genau erläutert. Auf der anderen Seite hat man die postrelationale 2 Datenbank Caché von Intersystems [Caché-Home]. Diese objektorientierte Datenbank besitzt einen SQL sowie multidimensionalen Datenzugriff. Sie ist ausgerüstet mit einer kompletten Entwicklungsumgebung für Web- und Client/Server- Applikationen und ist optimiert für Hochleistungstransaktionsverarbeitung und Echtzeitanalyse der Daten. Im Kapitel 2.3 Caché wird dann auf die Detail- und Anwendungsmöglichkeiten eingegangen. 2.1 Begriffe in Rahmen dieser Arbeit Da es sich um zwei unabhängige Systeme bei RDF und Caché handelt gibt es begriffliche Überschneidungen, deren Bedeutung sich stark unterscheidet. Wenn man von einer Klasse spricht, so ist das im Kontext mit Caché die Beschreibung eines Objektes in Caché, welches in Caché Script (CS) geschrieben worden ist. Eine Klasse in RDF entspricht einer Instanz oder Unterklasse von der rdfs:class Ressource (siehe Anhang I). Um die Eindeutigkeit der Begriffe zu gewährleisten wird im folgenden Caché bzw. RDF als Präfix eingefügt. RDF-Klasse ist die rdfs:class Ressource oder eine RDF-Instanz bzw. eine Unterklasse von rdfs:class. Das kann direkt oder indirekt erfolgen (siehe Anhang I). Caché-Klasse ist die Beschreibung eines Caché-Objektes mittels CachéScript (siehe Kapitel ). RDF-Eigenschaft sind entsprechen den Prädikaten eines Statements, können aber selbst beschrieben werden. RDF-Eigenschaft ist die rdfs:property Res- 2 Datenbanktechnologie, welche komplexe Strukturen abbilden kann und nicht nur auf zwei Dimensionale Tabellen beschränkt ist, sowie einen objektorientierten Ansatz besitzt.

17 2 Grundlagen 17 source oder eine RDF-Instanz bzw. Unterklasse von rdfs:property. Das kann direkt oder indirekt erfolgen (siehe Anhang I). (Caché-) Property ist die Klasseneigenschaft bzw. die Variable einer Caché- Klasse. RDF-Instanz ist eine Ressource, welche mittels rdf:type auf ihre RDF-Klasse referenziert wird. Dies wird hier im engeren Sinne betrachtet. Das heißt, dass nur die direkte Verbindung gemeint ist, welche in rdf:type eingetragen ist. Caché-Instanz ist die Instanz einer Caché-Klasse, welche sich im temporären oder persistenten Speicher befindet. In temporären Zustand besitzt sie eine Referenz (REF) und im persistenten Zustand eine Identitätsnummer (ID) (siehe Kapitel ). RDF-Collection ist die Menge von rdfs:bag, rdfs:seq und rdfs:alt Ressourcen oder eine RDF-Instanz bzw. Unterklasse von den drei Ressourcen. Das kann direkt oder indirekt erfolgen (siehe Anhang I). Caché-Collection ist ein Element aus CS. Dabei sind die Liste oder das Array als Variante zugelassen. (siehe Kapitel ). RDF-Objekt ist die Ressource mit ihre RDF Beschreibung bzw. so wie sie im Graphen dargestellt wird. Caché-Objekt ist die Caché-Klassen und Caché-Instanzen mit ihren Werten gemeint. RDF-Namespaces ein Namensraum, welcher in RDF ist eine Datei in welcher die Beschreibung eines Schemas steht. Caché-Namespaces ein Namensraum, welcher in Caché die Klassenstruktur der Caché-Klassen vorgibt. Wird als Punktsyntax vor dem Klassenamen gekennzeichnet. 2.2 RDF Das Resource Description Framework (RDF) stellt ein Universalformat für Daten im Web dar. RDF ist eine Sprache, welche das Darstellen von Informationen über Ressourcen im World Wide Web (WWW) ermöglicht. Eine der Anwendungsmöglichkeiten dieser Metadaten ist, die Informationen einer Internetressource bzw. einer Internetseite über den Autor, Erstelldatum, Copyright etc. abzulegen. Es besteht nicht nur die Möglichkeit die Internetressourcen zu beschreiben, sondern es können auch Gegenstände der realen Welt katalogisiert werden. Ein Paradebeispiel hierfür ist ein Online-Shop. Hier können Beschreibungen hinterlegt werden, die auch maschinell ausgewertet werden

18 2 Grundlagen 18 können. Damit kann ein Produkt genau beschrieben und dessen Eigenschaften hervorgehoben werden. Als Beispiel nehme ich einen Online-Shop der Motorräder und Zubehör verkauft. Die Marke allein reich nicht, um das gewünschte Modell zu finden, geschweige mit anderen zu vergleichen. Da aber alle Motorräder gleiche Attribute haben, wie z.b. Hubraum, Leistung in KW/PS, Farbe, etc. können diese ebenfalls hinterlegt werden. Aufgrund der Tatsache, dass sich die gewöhnliche Websuche auf Übereinstimung der Wörter beschränkt, ist ein Vergleich nur sehr schwer und umständlich möglich. Um dies anzubieten, muss eine Datenbank im Shop integriert sein, die einen Vergleich ermöglicht. Doch da jeder Shop eine andere Datenbank benutzt, ist ein globaler Vergleich vergeblich. Mit RDF könnte man eine entsprechende Auswertung vornehmen. Dies ist möglich, da RDF mit folgenden Eigenschaften aufgebaut worden ist [RDF-FAQ]: o o o o Kompatibilität von Daten maschinell verständliche Semantik von Metadaten bessere Präzision in der Webdurchforschung als Ganztextsuche future-proofing Anwendungen als Schemata entwickeln Auch wenn das RDF ein Modell zur Darstellung von Sinnesdaten ist, schlägt W3C RDF in drei Formen vor: o Graph (siehe Kapitel 2.2.1) o Tripelkonstruktion (siehe Kapitel 2.2.1) o RDF/XML Format. (siehe Kapitel 2.2.1) Doch bevor die Darstellungen genauer verdeutlicht werden sollten die Begrifflichkeiten geklärt werden RDF Graph & Tripeldarstellung Das Grundprinzip von RDF besteht aus drei Elementen: Subjekt, Prädikat, Objekt. Das Subjekt ist die Ressource, welche beschrieben werden soll. Das Prädikat ist die Eigenschaft der Beschreibung und das Objekt beinhaltet die Beschreibung des Subjekts. Ein Statement ist der Zusammenhang von Subjekt, Prädikat und Objekt. Das Statement in Abbildung 2-1 sagt aus, dass einen Autor hat, der unter der URI zu finden ist.

19 2 Grundlagen 19 Abbildung 2-1. Zusammensetzung eines Statements Als Tripeldarstellung würde es so aussehen: < < > < wobei wenn man ein Präfix ex mit dem Trennzeichen : benutzt, der einen Namespace mit der URI darstellt, würde es so aussehen: ex:my.htm ex:author.htm ex:i_am.htm Die Darstellung unseren Statements als Graph ist in Abbildung 2-1 praktisch integrierert. Die genauen Spezifikationen sind von [RDF-Home] zu entnehmen. Bei genauerer Betrachtung erkennt man, dass nicht nur das Subjekt, sondern auch das Prädikat und Objekt Ressourcen sind. Das ist kein Zufall, da das Motto von W3C für RDF lautet alles ist eine Ressource (Abbildung 2-2a). Natürlich gibt es Ausnahmen und diese bilden die Literale (Abbildung 2-2b). Literale sind im Gegensatz einfachen Zeichenketten, Ziffern oder Datumsangaben. Sie besitzen keine weiteren Beschreibungen und treten als Blätter des RDFs auf, wobei auch eine beliebige Ressource ein Blatt sein kann. Abbildung 2-2. Ressource

20 2 Grundlagen RDF/XML Das W3C empfiehlt für die Implementierung der RDF-Daten das RDF/XML Format. Dieses hat nicht nur die Eigenschaft, dass es maschinell verarbeitbar ist und von Menschen lesbar, sondern auch wie XML, gut von HTML verarbeitbar. Hier durch kann es auf Webseiten integriert werden, ohne dass der Browser Probleme bekommt, da bekanntlich unbekannte HTML Befehle einfach übergangen werden. Dadurch steht der RDF-Eigenschaft als Metadaten nichts im Wege, um das Suchen durch diverse Suchmaschinen zu verbessern. Die Syntax wird wie schon aus HTML und XML bekannt mit dem Zeichen < begonnen und mit > abgeschlossen. Auch die Weite des Tags wird mit </ terminiert. Um das RDF/XML besser zu verstehen wird es an einem Beispielonlineshop vorgestellt, welcher Krafträder und Zubehör anbietet: Beispiel 1: Kraftradshop in RDF/XML 1. <?xml version="1.0"?> 2. <!DOCTYPE rdf:rdf [<!ENTITY xsd " 3. <rdf:rdf xmlns:rdf=" 4. xmlns:exmshop=" 5. <rdf:description rdf:id="lk636"> 6. <exmshop:kategorie rdf:datatype="&xsd;string">zubehör </exmshop:kategorie> 7. <exmshop:bezeichnung rdf:datatype="&xsd;string"> Lenkkopflager</exmshop:kategorie> 8. <exmshop:hersteller rdf:datatype="&xsd;string">kawasaki </exmshop:hertseller> 9. <exmshop:model rdf:datatype="&xsd;string">zxr 6 Ninja </exmshop:model> 10. <exmshop:ccm rdf:datatype="&xsd;integer">636</exmshop:ccm> 11. <exmshop:preis rdf:="&xsd;decimal"> </exmshop:preis> 12. <exmshop:ps rdf:datatype="&xsd;integer">92</exmshop:ps> 13. </rdf:description>...andere Beschreibungen der Artikel im Shop </rdf:rdf>

21 2 Grundlagen 21 In Beispiel 1 sieht man eine Beschreibung eines Artikels in unserem Shop. Die Zeile 1. kündet an, dass XML-Ausdrücke folgen werden und deren Version wird angegeben. In der Zeile 2. wird ein Verweis auf die Substitutionen der Sonderzeichen gemacht. In der Zeile 3. beginnt ein rdf:rdf Element, welches RDF repräsentiert und in Zeile 14. mit /rdf:rdf endet. Nach rdf:rdf folgt eine XML-Namespace Deklaration, welche ein xmlns Attribut des rdf:rdf Start-Ausdrucks repräsentiert. Dahinter verbergen sich alle Grundausdrücke von RDF. In Zeile 4. wird ein neues xmlns Attribut einem Namespace hinzugefügt, welcher den Präfix exmshop: hat, der auf URI verweist. Ab Zeile 5. wird eine Artikel-, bzw. eine Itembeschreibung mit rdf:descriptoion erstellt. Diese Beschreibung wird mit /rdf:description in der Zeile 13. beendet. Dabei bekommt der Artikel eine Identifikationsnummer (ID), welche durch die Zeichenkette Lk636 hier dargestellt wird. Danach folgen die Attribute des Artikels. In Zeile 6. steht das erste Attribut mit der Ressource Zubehör mit der Klasse exmotoshop:kategorie, welches aus dem Datentyp XML- String besteht. Zeile sind analog zu Zeile 6. aufgebaut und schildern die anderen Attribute des Lk636 Items. Die Zeile 13. schließt die Beschreibung des Lk636 I- tems. Und abschließend wird in der Zeile 14. die RDF Beschreibung geschlossen RDFS- Resource Description Framework Schema Das RDF-Schema (RDFS) ermöglicht die Definition vom Vokabular, das die Beschreibung benutzterspezifische Klassen von Ressourcen erlaubt. RDFS ist die Ergänzung zu RDF. Damit kann man komplexere Datenstrukturen abbilden. Es lassen sich auch neue Eigenschaften erstellen, die man selbst definiert. Diese können dann durch die Vererbung die Instanzen von übergeordneten Eigenschaften erhalten. Das gleiche gilt für Ressourcen, die ebenfalls einer eigenen Definition bedürfen. Doch RDFS beinhaltet in seinem Vokabular nicht die Eigenschaften bzw. Klassen, um diese benutzerspezifschen Datentypen zu kreieren. Viel mehr gibt RDFS an, welche Eigenschaften und Ressourcen benutzt werden, um die Datentypen darzustellen. Das RDFS System erinnert in einigen Fällen, wie z.b. Vererbung oder erweiterbares Metaschema, an eine objektorientierte Sprache wie Java oder C++. Doch es gibt Indizien, die gravierende Abweichungen aufweisen. Dazu zählen Eigenschaften wie unabhängige Speicherung der Eigenschaften von der Ressource, also autarke Eigenschaften und die Möglichkeit Eigenschaften mehrfach zu belegen, wie es in einer Datenbank üblich ist. Auch Mehrfachvererbung ist nicht ganz gängig in der OO-Programmierung. Bis auf die Ausnahme von C++ und Caché Object Script (siehe Kapitel 2.2), sind meist nur einfach Vererbungen möglich.

22 2 Grundlagen Caché von InterSystems Seit 1978 sind InterSystems [INTERSYSTEMS] tätig und haben sich fest am Markt etabliert. Ihren Anwendungstechnologien werden weltweit von mehr als 4 Millionen Anwendern 3 in Anspruch genommen. Einen besonders großen Anteil von Anwendungen in Caché findet man im pharmazeutischen Bereich. Obwohl sie ihren Sitz in Cambridge, USA, sind sie mit Niederlassungen in über 20 Ländern für Support und Erstellung von Enterprise-Applikationen vertreten. Der deutsche Sitz von InterSystems ist in Darmstadt MUMPS der Urknall von Caché Den Ursprung von Caché findet man 1966 am Massachusetts General Hospital. Dort in der Abteilung für Computerwissenschaft wird die Programmiersprache Massachusetts General Hospital Utility Multi-Programming System (MUMPS) entwickelt. Drei Jahre später wird im Massachusetts General Hospital die erste medizinische Krankenhausanwendung, welche unter MUMPS läuft, in Betrieb genommen schafft MUMPS den Sprung über den großen Teich nach Europa und es wird die MUMPS U- sers Group Europe gegründet wird MUMPS zum ISO-Standart und es setz sich immer mehr der Begriff M-Technologie durch. Im Jahre 1996 werden Begriffe wie Multidimensional und Postrelational kreiert und erfolgreich von Herstellern Micronetics und InterSystems vermarktet und damit folgen sie dem Trend der Zeit. Ende 1997 wird von InterSystems Caché auf dem Markt eingeführt. Ein Jahr später übernehmen Intersystems die Produkte von Micronetics und werden damit alleiniger Anbieter auf dem M-Markt wird eine Linux-Version von Caché auf den Markt gebracht, wobei die Clients noch immer auf Windowsrechner fixiert sind. [MUMPS-HIS] Der Aktuelle stand von Caché ist die Version Caché postrelationale Datenbank Seit den Anfängen der Datenbanken mit proprietärem Datenschema hat sich einiges getan. Damals hatte jede Firma einen eigenen Standart, der zu den anderen völlig inkompatibel und nicht auf einer öffentlichen Plattform spezifiziert war. Diesem Datenchaos machten die relationalen Datenbanken ein Ende. Die Abfragesprache SQL wurde zum großen Standart, doch heute stößt man immer öfter an die Grenzen von relationalen Datenbanken bei Performance, Skalierbarkeit und Bedienfreundlichkeit. 3 Quelle: (stand Juni 04 ) 4 zu Verfügung stehende Version am

23 2 Grundlagen 23 Trotz Einfachheit der tabellarischen Strukturen, welche durch die elegante Abfragesprache SQL abgerundet wird, ist es kaum möglich die Prozesse in der realen Welt abzubilden. Durch die zweidimensionale Beschränkung explodieren die Probleme schnell in unüberschaubare Menge von Tabelle, welche wiederum durch Methoden, wie z.b. Left Outer Joins, immense Rechenzeit in Anspruch nehmen. Zusätzlich tendieren die Programmiersprachen und andere Entwicklungsanwendungen in Richtung der objektorientierten Daten. Das Konzept der objektorientierten Technologien ist schon von Grund auf anders und inkompatibel zu relationalen Datenbanken. Als postrelationales Produkt vereint Caché eine objektorientierte Datenbank, Hochleistungs-SQL und einen multidimensionalen Datenzugriff( ) [Caché-Tech]. Diese Kreuzung aus relationalen und objektorientierten Daten bietet Caché an. Der Begriff postrelational beschreib die Datenbankkonzepte, die zeitlich nach dem relationalen Modell entwickelt wurden. Damit umfasst dieser Begriff auch verschachtelte, multidimensionale und objektorientierte Datenbanken, deren aller Grundidee ist, Daten der realen Welt besser abzubilden Anwendungsumgebung Caché besitzt eigene Entwicklungswerkzeuge. Da diese für das Erreichen des Ziels dieser Diplomarbeit nicht unerheblich sind, werden die wichtigsten in diesem Abschnitt kurz vorgestellt. Nach der Installation von Caché sind sie bequem über den blauen Cachéwürfel in der Windows Tray-Leiste erreichbar. Caché Studio Caché Studio ist die grafische Programmieroberfläche, in welcher die Definition der Objektklassen erfolgt. Es wird in Caché eigenen Scriptsprache Caché Object Script oder Caché Basic programmiert. Unter bestimmten Umständen sind auch andere Programmiersprachen wie Java oder Visual Basic zulässig [CACHÈ-DOKU]. Hier erfolgt auch die Kompilierung und die Projektion der Klassen nach Java. Die Projektion ermöglicht die Verbindung zur RDF (Kapitel 5.2.3).

24 2 Grundlagen 24 Abbildung 2-3. In Caché Studio werden die Caché-Klassen bequem programmiert Caché Explorer Im Caché Explorer darf man sich unter anderem die Globals für Datenbanken und Namespaces anschauen. Dabei handelt es sich um globale Variablen, die systemweit verfügbar sind (siehe Datenhandhabung). Außerdem werden hier auch die Routinen und Klassen der jeweiligen Datenbanken aufgelistet. Abbildung 2-4. Der Caché Explorer dient zur Übersicht über den Inhalt der Datenbank

25 2 Grundlagen 25 Caché Terminal Über das Caché Terminal kann man sich auf der Kommandoebene in die Datenbank einloggen und entsprechende Datensätze auflisten, anschauen und ändern oder einfach Routinen aufrufen. Er wird hier benutzt um eine Funktion bei der Installation anzustoßen, welche die DB für RDF-Import vorbereitet. Abbildung 2-5. Im Caché Terminal können Daten eingegeben werden oder Routinen aufgerufen werden. Caché SQL-Manager Der SQL-Manager erlaubt dem User die Ansicht in die gespeicherten Daten aus der Relationalen sicht. So können Importierte RDF-Daten wie Literale in Tabellenform Angeschaut werden. Abbildung 2-6 zeigt den SQL-Manager.

26 2 Grundlagen 26 Abbildung 2-6. Der SQL-Manager erlaubt Betrachtung der Daten aus der Relationalen Seite Datenhandhabung Um eine sinnvolle Abbildung von RDF-Strukturen in Caché zu erreichen, muss Cachés Datenhandhabung unter die Lupe genommen werden. Wie schon erwähnt, ist Caché fähig ein objektorientiertes Modell zu handhaben und besitzt eine SQL Unterstützung. Die SQL Seite eignet sich optimal für Reporting- und Auswertungszwecke. Auf der anderen Seite möchte kaum ein Programmierer gerne auf die Vorzüge der objektorientierten Programmiersprache verzichten. Dieser Trade-Off wurde von Intersystems durch Unified Data Architecture erreicht (siehe Abbildung 2-7). Es ist nicht objekt-relationales Mapping, welches zu großen Performanceproblemen führt, sondern eine einzige Definition, die sowohl als Objektklasse, als auch als relationale Tabelle funktioniert. Bei der Erstellung einer Objektklassendefinition in Caché wird automatisch auch eine SQL-fähige Beschreibung generiert. Analog erzeugt Caché bei einer Importierung von DDL-Beschreibung einer relationalen Tabelle eine Objektbeschreibung der Daten und ermöglicht sofortigen Objektzugriff.

27 2 Grundlagen 27 Abbildung 2-7. Die Systemarchitektur von Caché Objektmodell In Caché wurde das Objektmodell nach dem ODMG-Standard der Object Data Management Group entwickelt [OA-Caché]. Dadurch unterstützt Caché in vollem Umfang alle Grundkonzepte moderner Objekttechnologie. Dazu gehören Vererbung, Polymorphismus und Persistenz. Die Klassen werden durch Klassendefinitionen bestimmt, welche aus Objekten mit eindeutigen Identifikatoren und Literalen mit einem Wert bestehen. Sie können Caché-Properties enthalten und geben dem Benutzer Kontrolle über den Zugriff und die Validierung ihrer Werte. Die Caché-Properties können aus Literalen, Referenzen auf Objekte, eingebettete Objekte oder bidirektionale Bezüge zwischen persistenten Objekten bestehen. Außerdem können die Klassen Methoden oder Methodengeneratoren enthalten. Klassentypen In Caché wird grundsächlich zwischen Datentypenklassen und Objektklassen unterschieden. Die ganze Struktur wird in Abbildung 2-8 genauer dargestellt. 5 Quelle [OA-Caché], Seite 29.

28 2 Grundlagen 28 Abbildung 2-8. Klassentypen 6 Zu den Datentypenklassen zählen alle Literale wie Strings, Integer etc. Objektklassen beinhalten Objekte, welche in nicht-registrierte und registrierte Objektklassen weiter unterteilt werden. Die nicht-registrierten Objektklassen werden nicht von Caché automatisch verwaltet und die Objektidentität (OID) wie auch Objektreferenz (OREF) muss selbst nachgepflegt werden. Außerdem unterliegen die nicht-registrierten Objektklassen weiteren Einschränkungen. Das System allokiert keinen Speicher für diese Objekte und es werden weder Polymorphismus noch Swizzling unterstützt. Anders ist es bei den registrierten Objekten, da sie über alle Methoden zur Steuerung des Objektverhaltens im Speicher verfügen. Sie sind transiente Objekte, solange sie nur instanziert sind. Sie haben aber die Möglichkeit dauerhaft in der Datenbank gespeichert zu werden und damit automatisch eine OID zu bekommen. Zusätzlich haben die registrierten Klassen die Eigenschaft des Polymorphismus. Es gibt zudem zwei Spezialisierungen von registrierten Objekten. Die einbettbaren Objektklassen werden zwar im Speicher mit normaler OREF versehen, doch bei der persistenten Speicherung in der Datenbank werden sie serialisiert als Teil des umgebenen Objektes gespeichert. Damit besitzt die einbettbare Objektklasse auch keine eigene OID und kann nicht direkt von anderen Objekten angesprochen werden. Die zweite Art der registrierten Objektklassen sind die persistenten Objektklassen. Sie können auch dauerhaft gespeichert werden, bekommen aber immer eine eindeutige OID vom System zugewiesen. Deshalb können sie unabhängig voneinander in der Datenbank gespeichert werden und direkt von anderen Objekten angepackt werden. Die folgende Abbildung 2-9 stellt dieses graphisch nochmals dar. 6 Quelle [OA-Caché], Seite 32

29 2 Grundlagen 29 Abbildung 2-9. Persistente und eingebettete Klassen Objektbezüge Objektreferenzen (OREF) und Objektidentitäten (OID) sind nicht die einzigen Möglichkeiten auf Objekte zuzugreifen. Innerhalb eins Namespaces, also innerhalb einer Datenbank auf dem Caché-Server, ist die OID die eindeutige Referenz um auf gespeicherte Daten zuzugreifen. Sie besteht aus den Klassennamen und einer Identität (ID). Der Befehl um ein gespeichertes Objekt zu laden lautet: Set object = ##class(myapp.person).%open(oid) Die ID wiederum ist eindeutig gegenüber aller Daten einer Klasse und aller ihrer Unterklassen. Deshalb benutzt Caché eine etwas andere Funktion um es zu öffnen: Set object = ##class(myapp.person).%openid(id) Außer der Identifizierung der Objekte an sich, können auch Relationen verwendet werden, welche von Caché unterstützt werden. Es ist die Eltern-Kind (Parent-Child) und One-To-Many Beziehung. Beide bieten eine bidirektionale Beziehung zwischen genau zwei persistenten Objekten. Der Unterschied zwischen den beiden ist, dass One-To- Many Beziehungen unabhängig sind und Eltern-Kind Beziehungen abhängig sind. Die abhängigen Beziehungen haben den großen Vorteil, dass Caché die Relationen verwaltet. Wenn das Elternobjekt entfernt wird, werden auch die Kinderobjekte automatisch entfernt. Leider sind die Beziehungen auf zwei Objektklassen beschränkt. Die Beziehungen sind auf Instanzen der Klassen bezogen. So kann eine Elternklasseninstanz mit

30 2 Grundlagen 30 mehreren Kindklasseinstanzen in Beziehung stehen. One-To-One und Many-To-Many Beziehungen werden nicht unterstützt. Die Klasse %ObjektHandle gehört zu den Systemklassen von Caché. Man erkennt es an dem Vorzeichen %. Einem Property mit der Instanz dieser Klasse können Instanzen beliebiger Klassen zugewiesen werden. Somit kann es bei Zuweisungen verwendet werden, wenn die Klassen nicht bekannt sind, oder keine homogenen Klassen in Frage kommen List und Array Collection In Caché darf jedes Property als eine Caché-Collection gestaltet werden. Diese Collection ist dann in der Lage mehrere Objekte vom Typ dieser Property zu verwalten. Dabei unterscheidet man bei den Collections in Listen und Arrays. Die Listen sind unsortiert und können einfacher verwaltet werden. Eine List Collection erkennt man an der Definition in Caché-Script an [collection=list] Erweiterung an deren Properties. Sie verfügen über die einfache Insert(element) Funktion, welche das Hinzufügen der Elemente (Literale, Referenzen oder Objekte) in der Liste sehr einfach macht. Das Deklarieren von Listen sieht wie Folgt aus: Set list1 As MyApp.Person [collection = list]; Die Arrays werden streng nach einem Key (Schlüssel) sortiert, der bei dem Einfügen vom Element mitgegeben werden muss. Der Key kann eine Zahlen oder eine Zeichenkette sein. Nach diesem Key werden dann die Elemente im Array sortiert. Der Vorteil von Arrays gegenüber Listen ist, dass der Key zur Existenz und eindeutigen Identifizierung genutzt werden kann. Dieses wird durch die Bereitstellung der Funktion IsDefinied(key) vereinfacht um die Existenz eines Schlüssels zu prüfen. Das Array erkennt man an dem [collection=array] Zusatz bei den Properties. Das Deklarieren von Listen sieht wie Folgt aus: Set array1 As MyApp.Person [collection = array]; Beide Collections stehen noch mehr Funktionen zur Verwaltung von Elementen zur Verfügung. Eine vollständige Liste der Funktionen findet sich unter [Caché-Doku] Globale und multidimensionale Variable Die globalen Variablen stehen nicht nur in der Caché Datenbank überall zu Verfügung, sie werden auch persistent gespeichert. Im Gegensatz zu den lokalen Variablen, welche im Caché ObjectScript angewendet werden, werden sie nicht über den Befehl New() instanziert und können über den exklusiven Kill Befehl nicht gelöscht werden. Alle globalen Variablen werden mit einem Zikumfelx ( ^ ) am Anfang der Variable kenntlich gemacht.

31 2 Grundlagen 31 Die multidimensionalen Variablen bilden so was wie eine multidimensioanle Collection vom Typ Array (Siehe Kapitel 2.2.5). Auch hier wird eine Sortierung nach einem Key vorgenommen. Dieser ist als Zahl, Zeichenkette oder Funktion definierbar und man kann ihn in jeder Dimension frei wählen. Weiterhin brauchen diese Variable keine festen Vorgaben über die Höhe der Dimension. So können die Daten in erster Dimension mit verschiedenen Keys wie Folgt gespeichert werden: Set multistorage(1000) = Zahl Set multistorage( Frankfurt ) = Stadt Set multistorage( Main ) = Fluss Selbe Variable, wäre eine Speicherung der zweiten Dimension wie Folgt: Set multistorage( Frankfurt, Bundesland ) = Hessen Set multistorage( Frankfurt, Uni ) = J.W. Goethe Universität Set multistorage( Main, Bundesland ) = Hessen, Bayern, Baden-Württemberg Vereinfacht wird die Handhabung durch mehrere Funktionen, welche zur Verfügung gestellt werden. Eine vollständige Liste der Funktionen findet sich unter [Caché- Doku]. Die multidimensionale Variable ist aber als lokale Variable nicht Speicherfähig. Nur die globale Verwendung kann persistent in der Datenbank gespeichert werden Vergleich zu OO-Programmiersprachen Wie schon erwähnt ist Caché ein Objektmodell nach dem ODMG-Standard der Object Data Management Group. Es fängt an bei der Punkt-Syntax und endet bei Vererbung. Natürlich hat die Caché-Syntax ihre eigene Besonderheiten, aber über Caché Object Script lässt sich mit Objekten wie in Java oder C++ arbeiten. Es sind sogar in Methoden der Caché Objekten auch Codestücke anderer Programmiersprachen wie Java und Visual Basic erlaubt. Auch die Projektion der Klassen in Java, EJB oder C++ ist möglich. Schwächen weist Caché nur noch bei der Package-Struktur auf, die zurzeit nur als Infrastruktur für das Menü dient und nicht mal bei der Speicherung beachtet wird und dass die Objekte nicht namespaceübergreifend wirken. Lediglich die Mehrfachvererbung, die nur von C++ unterstützt wird, sticht heraus Schnittstellen Standardmäßig ist Caché über die IP und den Port 1972 lokal erreichbar. Wie man aus der Abbildung 2-6 unschwer erkennt, existieren über der Unified Data Architecture und deren zwei Datendarstellungsformen einige Schnittstellen für andere bzw. externe Systeme. Relationale Schnittstellen: o ODBC o JDBC

32 1 32 Objektorientierte Schnittstellen: o XML o ActiveX o Java o Enterprice Java Beans (EBJ) o SOAP Objektorientiert und relationale Schnittstellen: o Caché Server Pages (CSP) CSP ist die von InterSystems integrierte Möglichkeit Web-Anwendungen zu entwickeln. Es unterstützt HTML, XML und andere Markup Languages. Außerdem bietet es eine prozedurale Programmierumgebung und Dynamic Server Pages.

33 3 Ziele 33 3 Ziele Wie schon in der Einleitung erwähnt, besteht der Bedarf an Speicherung von RDF in bestehenden Datenbanksystemen. Dies ist bei XML schon längst gang und gebe. Doch in der Praxis ist der Austausch von RDF noch in den Kinderschuhen. Nachdem im Kapitel 2 Grundlagen von RDF und Caché detailliert besprochen wurden, erweist sich Caché durchaus als eine Datenbank, welche auch vielen Eigenschaften von RDF mächtig ist. Durch die objektorientierte Technologie dürfte die Abbildung der autarken Eigenschaften möglich sein. Auch das Statement alles ist eine Ressource könnte angewendet werden. Zusätzlich besteht die Gemeinsamkeit bei Mehrfachvererbung. Aus diesen Gründen liegt der Gedanke nahe, eine Abbildung von RDF-Modellen in Caché zur Speicherung nachzubilden. Zunächst gilt es, eine geeignete Schnittstelle zu wählen, welche optimal für die Datenübertragung und Übermittlung der Strukturen ist. Im zweiten Schritt ist es nötig, ein Modell in Caché zu konstruieren, welches die Struktur von RDF aufnehmen kann. Das Modell muss für alle gültigen RDF-Daten kompatibel sein. Weiterhin soll es den objektorientierten Ansatz verfolgen und deren Vor- und Nachteile hervorheben. Dabei soll besonders auf die Möglichkeiten von Caché eingegangen werden um das Modell optimal zu gestalten. So sollen RDF-Daten in Caché mehr Aussagekraft bekommen. Außerdem muss das Modell den folgenden Ansprüchen gerecht werden: - Einfachheit: Die Importierung soll einfach für den User sein, ohne Erstellung von selbst definierten Tabellen. - Vollständigkeit: Alle gültigen RDF-Daten müssen importierbar sein. - Transparenz: RDF Daten sollen in Caché wieder zu finden sein. - Erweiterbarkeit: Es soll möglich sein, Abfragen und Auswertung der Daten durchzuführen und unter Umständen ein Export durchführbar sein. - Akzeptable Performance: Eine optimierte Importierung und schnelle und bequeme Abfrage des Modells.

34 4 Stand der Technik 34 4 Stand der Technik Das W3C schlägt zur Darstellung von RDF 7 Graph, N-Tripple oder das RDF/XML Format vor. Für die Datenübertragung im Internet eignet sich besonders RDF/XML. Nicht nur als Text-Datei (standalone RDF/XML), sondern auch im HTML- Code eingebunden (eingebettete RDF/XML) kann RDF abgelegt werden. Da bekanntlich HTML unbekannte Ausdrücke einfach ignoriert, ist es auch die optimale Möglichkeit RDF zu übertragen. Das XML Format hat sich als Übertragungsmedium im Internet sehr bewehrt. Da RDF/XML auf XML basiert, nutzt es XML Vorteile. In diesem Kapitel wird auf die abweichenden Syntaxen vom RDF hingewiesen und ob es eine Syntax gibt, die sich besonders für die Importierung eignet. Weiterhin werden Applikationen und Tools vorgestellt, die sich mit dem Thema der RDF-Speicherung in Datenbanken beschäftigen, bzw. hier hilfreich sein könnten. Im Abschluss wird ein kurzer Überblick gegeben, wie weit Caché RDF entgegenkommt. 4.1 RDF Serialisierung Ein Bild sagt mehr als tausend Worte und damit ist RDF in der Graphdarstellung für den Menschen leicht lesbar und überschaubar. Doch für die Datenübertragung im Internet müssen die Informationen serialisiert werden. Selbstverständlich ist die RDF/XML Form die Serialisierung von RDF. Dabei ist die XML-Syntax für eine effiziente Speicherung nicht geeignet. Das RDF ist kein XML-Dialekt, sondern hat ein eigenes Datenmodell, welches sich von der XML-Baumstruktur stark unterscheidet. Weiterhin ist XML-Syntax nicht eindeutig [SpeicherungRDF]. Die Überlegung ist, ob es doch eine Serialisierung gibt, die über eine einfache XML Schnittstelle in eine Datenbank importiert werden kann. Auch wenn W3C eine genaue Richtlinie angibt, existieren doch verschiedene leicht von einander abweichende RDF/XML Strukturen. Eine der alternativen Serialisierung bietet TriX [TriX]. Dort befindet sich in experimentellem Status eine neue Syntax in den Startlöchern. J. Carroll und P. Stickler entwickeln eine RDF/XML Form, die sich eng an der N-Tripple Form orientiert. Sie versuchen den RDF Graphen mit dem geringsten Aufwand im XML darzustellen. Außerdem geben sie dem so dargestellten Graphen Namen, damit diese später als Teilgraphen weiter verwenden können. Zusätz- 7 aktueller stand von RDF ist vom und ist unter / zu finden.

35 4 Stand der Technik 35 lich bietet dieses Format mehr Übersichtlichkeit beim lesen des Dokuments. Hier ein Beispiel aus [TriX-Paper]: Beispiel 2. R DF in TriX. <?xml-stylesheet type="text/xml" href=" <graphset xmlns=" xmlns:eg=" > <graph> <triple> <qname> eg:bob </qname> <qname> eg:wife </qname> <qname> eg:mary </qname> </triple> <triple> <qname> eg:bob </qname> <qname> eg:name </qname> <plainliteral>bob</plainliteral> </triple> <triple> <qname> eg:mary </qname> <qname> eg:age </qname> <integer> 32 </integer> </triple> </graph> </graphset> Egal wie man die RDF/XML umbiegt, um RDF zu serialisieren bleiben die Modelle von RDF und XML unterschiedlich. Doch wie man im Kapitel sieht, besteht eine Möglichkeit RDF über die XML-Schnittstelle von Caché zu Importieren. 4.2 Relationale Abbildung von RDF Es existieren bereits Lösungen um RDF in relationalen Datenbanken zu speichern. Einerseits gibt es den generischen Ansatz (GenRepr), welcher auf der strukturellen Abstraktion des Modells basiert. Dabei werden die Schemainformationen und Ressourcenbeschreibungen in je einer Tabelle gespeichert. Dieser einfache Ansatz ist von keinem Schema abhängig. Wenn man aber auf das Schema von RDF Wert legt, sollte man zu der spezifischen Repräsentation (SpecRepr) greifen. In SpecRepr werden Tabellen für rdfs:class, rdfs:subclassof, rdfs:property, rdfs:subpropertyof. rdf:domain und rdf.range erstellt. Je nach Spezialisierungsgrad können es mehr Tabellen werden. Die Daten werden dann in Subtabellen gespeichert, welche Subklassstruktur von der rdfs:subclassof bzw. rdfs:subpropertyof haben. Hierbei ist eine korrekte Implementierung der Daten nur durch die Existenz eines Schemas zu gewährleistet. Eine Zusammenfassung dieser Ansätze findet man auch unter [SpeicherungRDF].

36 4 Stand der Technik RDF Applikationen & Tools RDF findet immer mehr Anwendung im Web. Somit werden immer mehr Applikationen für Semantic Web geschrieben. Die Palette reicht von Desktop Tools wie RDFPic [RDFPic], welches erlaubt direkt RDF-Metadaten in Bildern abzulegen, über Informationsportale mit RDF Abfragesprachen RQL bzw. erql [erql], sowie Parser und Validierer, bis zu Anwendungen wie Jena [HP-Jena], welche bereits eine Schnittelle zu Datenbanken anbieten. Im folgenden werden Applikationen betrachtet, welche für diese Arbeit von Interesse sind Semantic Web Framework - Jena Jena ist ein Java Framework für die Erstellung von Semantic Web Applikationen. Sie ist open source und in Verbindung mit der HP Labs Semantic Web 8 entwickelt worden [HP-Jena]. Ein durchaus umfangreiches Projekt, welches einen RDF Import und Export in RDF/XML, N3 und Tripeldarstellung Syntax ermöglicht. Außerdem bringt sie eine eigene Abfragesprache RDQL mit. Alles erfolgt über die Java Database Connectivity (JDBC) Schnittstelle, womit alle relationalen Datenbanken, welche über eine JDBC Schnittstelle verfügen, angesprochen werden können. Doch auch die aktuelle Version weist Schwächen auf, wie man aus der FAQ erfährt: Jena2 does not do a good job in checking the validity of the database [HP- Jena-FAQ]. Auch durch die relationale JDBC Schnittstelle können die objektorientierten Aspekte nur schlecht abgebildet werden. Dadurch können Vorteile wie die Nutzung von eingebetteten Elementen nicht ausgeschöpft werden. Das folgende Bild 4-1 zeigt die komplette Struktur von Jena: 8 HP Labs Semantic Web ist unter zu finden. 9 stand September 2004