Skriptum

Bachelorarbeit: RDF als Verknüpfungsmethode zwischen geisteswissenschaftlichen Forschungsdaten und Geometrien am Beispiel des Projektes „Inschriften im Bezugssystem des Raumes“

von Michael Haft

Einleitung

‹1› Die „Digital Humanities“¹⁾ (DH) verstehen sich als Schnittstelle zwischen kulturwissenschaftlicher Fachinformatik und Computerlinguistik einerseits, sowie dem Feld der Geistes- und Kulturwissenschaften andererseits. Diese Synthese eröffnet neue und spannende Forschungsfelder. Die Vermittlerfunktion der DH macht in diesem Zusammenhang Möglichkeiten und Techniken der Informatik beispielsweise für die Geschichtswissenschaften nutzbar und ‚rückübersetzt‘ geisteswissenschaftliche Fragestellungen im Hinblick auf ihre technische Umsetzung.

‹2› Durch diesen gegenseitigen Austausch von Erfahrungen und Herangehensweisen lassen sich neue Perspektiven interdisziplinärer und augmentierter Forschung im Spannungsfeld zwischen Geistes- und Computerwissenschaft (Informatik) erschließen und nutzbar machen. Das durch das „Bundesministerium für Bildung und Forschung“²⁾ (BMBF) auf drei Jahre geförderte³⁾ Projekt „Inschriften im Bezugssystem des Raumes“⁴⁾ (IBR) ist genau in diesem Spannungsfeld angesiedelt.

‹3› IBR ist ein Verbundprojekt des „Instituts für Raumbezogene Informations- und Messtechnik – i3mainz der Fachhochschule Mainz“⁵⁾ (i3), der „Digitalen Akademie der Akademie der Wissenschaften und der Literatur Mainz“⁶⁾ (DA) und des interakademischen Projektes „Die Deutschen Inschriften des Mittelalters und der frühen Neuzeit“⁷⁾ (DI) hier in seiner Form als Onlineedition „Deutsche Inschriften Online“⁸⁾ (DIO). Die geoinformatischen Bestandteile des Projektes werden vom i3mainz geleistet. Die Digitale Akademie versteht sich als Konzeptions-, Entwicklungs- und Forschungseinrichtung im Feld der Digital Humanities und formt auf diese Weise ein Bindeglied zwischen technischen und geisteswissenschaftlichen Projektbestandteilen. Die geisteswissenschaftliche Komponente stellen die Inschriftenbände der Deutschen Inschriften in ihrer digitalisierten und aufbereiteten Form dar, welche dem IBR-Projekt als Fachdatenrepositorium zur Verfügung stehen.

‹4› Inschriften⁹⁾ besitzen drei grundsätzliche, auswertbare Bedeutungsebenen: Text, Träger und Position im Raum. Der Kategorie Raum erfährt dabei oft die geringste Auswertung. IBR beabsichtigt, existierende Lösungen der Informationstechnik in der Inschriftenforschung mit Anwendungen der Geoinformatik zu kombinieren, um diese Forschungslücke nutzbringend aufzuarbeiten. Die dafür zu entwickelnden Werkzeuge sollen die räumliche Erfassung der 3D-Geometrie von Inschriften, die standardisierte Bereitstellung der Daten und die informationstechnische Modellierung topologischer und semantischer Bezüge ermöglichen. Die in diesem Bedeutungsnetz entstehende Zuordnung räumlicher Bezüge ermöglicht neue inhaltliche Verknüpfungen von Inschriften und anepigraphen Objekten. Im Rahmen einer Referenzstudie soll an einem ausgewählten Standort (Liebfrauenkirche Oberwesel) ein Modell entwickelt werden.¹⁰⁾

‹5› Der Schwerpunkt dieser Arbeit liegt auf der Fragestellung, inwieweit mit Hilfe des „Resource Description Frameworks“¹¹⁾ (RDF) topologische und semantische Beziehungen zwischen geisteswissenschaftlichen Forschungsdaten und -objekten – in diesem Fall mittelalterliche und frühneuzeitliche¹²⁾ Inschriften – und dem sie umgebenden Raum bzw. darin vorhanden Geometrien – Punkten, Linien, Flächen oder Körpern in einer 3D-Punktwolke – hergestellt und ausgedrückt werden können. Da sowohl die einzelnen Inschriftenträger, als auch die spezifischen Geometrien jeweils über einen „Uniform Ressource Identifier“¹³⁾ (URI) eindeutig adressierbar sind, bietet RDF eine gute Möglichkeit die einzelnen Ressourcen zu verknüpfen. Die Auswahl eines passenden RDF-Store (Tripel Store) für diese Aufgabe, ist ebenfalls Bestandteil dieser Arbeit. Abschließend soll ein adäquates RDF-Vokabular ausgewählt werden, welches auf der einen Seite die räumlichen Komponenten abdeckt, auf der anderen Seite die geisteswissenschaftlichen Aspekte berücksichtigt. Im Schlussteil der Arbeit wird zudem noch auf weitere Projekte verwiesen, die an ähnlichen Fragestellungen arbeiten.

‹6› Da sich das Projekt zu großen Teilen noch in einem work in progress-Stadium befindet, werden in den Code- und Konfigurationsbeispielen dieses Artikels beispielhafte und im weitesten Sinne sprechende, also ihre Funktion wiedergebende, URLs verwendet. Dies dient zum einen der weiteren Illustration der Funktion, zum anderen soll vermieden werden, durch eine maßgebliche Festlegung der Anzahl wie der Form der URLs die weitere Entwicklung des Projektes vorschnell festzuschreiben.

Theoretische Grundlagen

‹7› In diesem Kapitel werden die Grundlagen des Themas dargestellt sowie die eingesetzten Technologien bzw. Techniken näher erklärt.

‹8› Zuerst wird Grundlegendes zum sogenannten Semantic Web ausgeführt und kurz mit seinen Vorgängern verglichen. Im Anschluss erfolgt in enger Anlehnung an das Buch „Semantic Web – Grundlagen“¹⁴⁾ eine ausführliche Beschreibung von RDF als Sprache des Semantic Web. Danach gilt es, die wichtigsten RDF-Schema Sprachmittel aufzuzeigen. Hieran anschließend werden die Grundzüge von REST erklärt, die RDF Abfragesprache SPARQL erläutert und einige grundlegende Punkte zu Tripel Stores angefügt.

Semantic Web

‹9› Das „Semantic Web“¹⁵⁾ wird gemeinhin als „Web 3.0“¹⁶⁾ bezeichnet und geht unter anderem auf eine Idee und Arbeiten von Tim Berners-Lee¹⁷⁾ zurück. Berners-Lee ist Direktor des „World Wide Web Consortium“¹⁸⁾ (W3C).

‹10› Beim „Web 1.0“ wurden Daten/Informationen auf statischen Webseiten bereitgestellt. Es erfolgte gar keine oder nur eine geringe Interaktion der Seite mit dem Benutzer. Die Informationen wurden meistens von Institutionen (Universitäten, Große Unternehmen, etc.) zur Verfügung gestellt und hatten durch diese Erstellungsschranke oftmals eine hohe inhaltliche Qualität.

‹11› Das „Web 2.0“ erlaubt dem Benutzer mit Webseiten und anderen Nutzern zu interagieren, selbst Inhalte zu erstellen, Informationen (über sich) mit anderen zu teilen und an deren Informationen teilzuhaben. Dadurch wurde eine soziale Komponente in das Web übertragen. Als Beispiel für die gemeinsame Erstellung und Pflege von Daten sei hier Wikipedia genannt, für die soziale Komponente Facebook erwähnt.

‹12› Eine kursorische Gegenüberstellung der drei „Versionen des Web“ stellt die obige Tabelle zur Verfügung.¹⁹⁾

‹13› Beim Semantic Web geht es nicht mehr nur um die Bereitstellung von Daten oder um dynamische Inhalte und Userinteraktion, sondern vor allem um die semantische, also bedeutungstragende, Verknüpfung der Inhalte untereinander und die Möglichkeit automatisch (neue) Beziehungen zwischen Inhalten herzustellen oder abzuleiten. Dazu muss der Computer in die Lage versetzt werden, Inhalte zu erfassen und zu „verstehen“²⁰⁾ bzw. zu verarbeiten, um auf diese Weise Informationen zu extrahieren. „Das Semantic Web steht [somit] für die Idee die Informationen von vornherein in einer Art und Weise zur Verfügung zu stellen, die deren Verarbeitung durch Maschinen ermöglicht.“²¹⁾ Die Sprache des Semantic Web ist RDF.

RDF

‹14› Das „Ressource Description Framework“²²⁾ (RDF) bietet eine formalisiert Art und Weise über (abstrakte) Ressourcen (formalisierte) Aussagen zu tätigen.²³⁾ Dadurch werden Beziehungen zwischen jeweils zwei Ressourcen hergestellt. Diese Aussagen (statements) haben immer die Form Subjekt – Prädikat – Objekt und werden als (RDF-) Tripel bezeichnet. Das Prädikat (Property) beschreibt die Beziehung zwischen Subjekt und Objekt (Ressourcen) genauer: Es ist immer vom Subjekt zum Objekt gerichtet („Pfeil“) und weder dem Einen noch dem Anderen untergeordnet. RDF ist propertyzentriert, es geht also immer um Eigenschaften zwischen Ressourcen und man könnte die Tripel ebenfalls so beschreiben Ressource – Property – Ressource. Eine solche Beziehung kann sich gut als Graph vorgestellt und dadurch visualisiert werden. Wenn zum Beispiel der Sachverhalt „Berlin ist Hauptstadt“ mittels RDF modelliert werden soll, könnte dies in einer graphischen Repräsentation folgendermaßen aussehen:

‹15› Wie das Beispiel (Abb. 1) zeigt, werden in der Graphenrepräsentation, Ressourcen (im obigen Fall das Subjekt „Berlin“ und das Objekt „Hauptstadt“) als Ovale dargestellt, und durch einen beschrifteten Pfeil (Prädikat/Property) verbunden. Ein weiteres wichtiges Merkmal von RDF ist, dass die Namen/Benennungen eindeutig sein müssen. „Um Verwechslungen zwischen verschiedenen Knoten bzw. Ressourcen auszuschließen, verwendet RDF grundsätzlich URIs zur Bezeichnung aller Ressourcen.“²⁴⁾ Somit ist Abb. 1 zwar ein Graph, aber kein RDF-Graph. „In der Regel sind Knoten und Kanten eines RDF-Graphen immer mit URIs beschriftet, um sie eindeutig zu beschreiben. Ausgenommen von dieser Regel sind lediglich Datenwerte (Literale), bei denen man keine URIs verwendet und sogenannte ‚Blank-Nodes‘, die keinerlei Bezeichnung tragen.“²⁵⁾ Auf beides wird später noch genauer eingegangen. Die URIs werden allerdings nur zur eindeutigen Benennung bzw. Identifizierung benutzt und verweisen nicht gezwungenermaßen auf Web-Ressourcen. Sie sind in diesem Zusammenhang somit nicht als „Uniform Resource Locator“²⁶⁾ (URL) zu verstehen.

‹16› Schon jetzt stellt sich die Frage des „Namensraums“²⁷⁾ (namespace) der URIs. Laut Konvention wird hierbei am besten eine Domain in eigener Regie verwendet. Auf diese Weise kann sichergestellt werden, dass eine benutzte URI²⁸⁾ nicht bereits einer anderen Ressource zugeordnet wurde. Wird zum Beispiel http:// de.wikipedia.org/wiki/Berlin genutzt, wäre es genauso möglich http:// www.berlin.de/ zu nutzen. Die beiden Seiten beschreiben Deutschlands Hauptstadt Berlin, jedoch mit einem völlig unterschiedlichen (menschen- aber nicht maschinenlesbaren) Inhalt der Seite. Der deutsche DBpedia²⁹⁾ Eintrag zu Berlin dbpedia.org/page/Berlin beschreibt ebenfalls Deutschlands Hauptstadt Berlin, wobei hier allerdings strukturierte Informationen über Berlin – in maschinenlesbarer Form aufgearbeitet – zu finden sind.

Abbildung 1: erstes Graphbeispiel - no URIs

‹17› Alles in allem gibt es viele Möglichkeiten Berlin zu referenzieren, man sollte sich also auf eine der zahlreichen Möglichkeiten festlegen und diese konsistent nutzen. Nun ist es sicherlich einfach für bekannte Orte, Sehenswürdigkeiten, Personen, etc. eine schon vorhandene Ressource im Internet zu finden, aber für weniger bekannte Entitäten, abstrakte Konzepte oder gar eine privat erstellte CD mit Urlaubsbildern ist dies nicht möglich. Da im Rahmen des IBR-Projektes eine Webseite erstellt und für diese auch eine DNS-Domain registriert wurde, hat das Team den Namensraum http:// ontology.spatialhumanities.de/ für die eindeutige Zuordnung von Vokabularien ausgewählt. Wird diese Adresse in einem Browser aufgerufen, erscheint nur einen Fehler 404, da die Seite über keinerlei Inhalte verfügt. Die Sub-Domain, wurde wie schon oben erwähnt, nur erstellt, um einen eigenen und eindeutigen Namensraum zu erhalten und damit sicherzustellen, dass die verwendeten Ressourcen im Projektkontext eindeutig benannt werden können. Wird nun das Beispiel aus Abb. 1 mit URIs versehen, sieht es folgendermaßen aus:²⁹⁾

Abbildung 2: RDF-Graphbeispiel - mit URIs

‹18› Durch die durchgängige Benutzung von URIs, ist dieser nun im Gegensatz zu Abb. 1 ein vollwertiger RDF-Graph. Im Gegenzug kann dieser Sachverhalt aus dem obigen Beispiel auch umgekehrt dargestellt werden, sodass man sagt die Hauptstadt heißt Berlin. Wenn wir diese Umkehr in der Graphenrepräsentation darstellen, könnte es wie in Abb. 3 modelliert werden:

Abbildung 3: RDF-Graphbeispiel - ungetyptes Literal

‹19› In diesem Graph fällt im Gegensatz zum vorherigen auf, dass Berlin nun in Anführungszeichen dargestellt und von einem Rechteck umrandet wird. In Abb. 3 fassen wir den Namen der Hauptstadt als konkreten Datenwert auf. „Datenwerte werden in RDF durch sogenannte Literale²⁹⁾ dargestellt.“³⁰⁾ Literale können dabei Wahrheits- und Datumswerte sein, Namen (wie Berlin), Zahlen (42) oder zum Beispiel auch Texte („Hallo Adam, ...“) darstellen.

‹20› In Abb. 3 ist Berlin als Literal ohne Typenzuweisung, als sogenanntes ungetyptes Literal dargestellt. Soll nun eine Postleitzahl darstellt werden – zum Beispiel die der Dresdner Altstadt um den Hauptbahnhof – nämlich 01069, fällt auf, dass bei dieser Information die Darstellung der führenden Null wichtig ist. Wird diese Information nun als Zahl (integer) interpretiert, passiert es normalerweise, dass die führende Null abgeschnitten wird. Daher sollte diese Information nicht als Zahl kodiert werden sondern als Zeichenkette (string) bzw. direkt als PLZ wenn dieser Datentyp vorhanden ist. „In RDF ist es deshalb vorgesehen, Literale mit Datentypen zu versehen. Die Datentypen werden dabei durch URIs eindeutig identifiziert, sind aber ansonsten im Prinzip sehr frei wählbar. In der Praxis sind allerdings vor allem solche Datentyp-URIs sinnvoll, die allgemein bekannt sind und von vielen Programmen erkannt und unterstützt werden. Daher empfiehlt RDF die Verwendung der Datentypen von XML Schema.“³¹⁾ „RDF selbst kennt keine eigenen Datentypen.“³²⁾ Für eine vollständige Liste der XML Schema Datentypen sei an dieser Stelle verwiesen auf → www.w3.org/TR/xmlschema-2/. Ein Beispiel mit einem getypten Literal zeigt Abb. 4.

Abbildung 4: RDF-Graphbeispiel - getyptes Literal

‹21› Wie man hier sehen kann, wird der Wert des Literals genau wie in Abb. 3 wieder in Anführungszeichen geschrieben. Direkt dahinter stehen nun aber zwei Zirkumflexzeichen³²⁾ und daran anschließend die Datentyp-URI. Durch diese Angabe wird dem Literal der Datentyp string zugewiesen. „Die Interpretation dieser Angabe wird durch einen Datentyp festgelegt.“³³⁾ Alle ungetypten Literale werden in RDF als nicht näher spezifizierte Zeichenketten behandelt. „Eine [...] Besonderheit von Literalen ist, dass sie nie der Ausgangspunkt von Kanten eines RDF-Graphen [kein Subjekt] sein können.“³⁴⁾ Ebenso als Kanten selbst (Prädikate) dürfen Literale nicht vorkommen. Die RDF-Graphrepräsentation ist zwar für den Menschen leicht verständlich³⁵⁾, „aber sie ist für die Verarbeitung […] in Computersystemen denkbar ungeeignet.“³⁶⁾ Um einen Graphen in ein für den Computer besser zu verarbeitendes Format zu übersetzen, muss dieser serialisiert werden. Da RDF-Graphen im Allgemeinen „lichte Graphen“³⁷⁾ sind, wurde bei RDF die Möglichkeit gewählt, den Graphen durch seine Kanten zu beschreiben. Ein RDF Dokument ist also eine vollständige Liste der Kanten des RDF-Graphen. Jede dieser Kanten wird als RDF Tripel (Subjekt – Prädikat – Objekt) dargestellt.³⁸⁾ Der ursprüngliche Graph ist aus der (vollständigen) Tripelliste rekonstruierbar.

‹22› Die aktuell verbreitetsten Formate für diese Listendarstellung sind RDF/XML³⁹⁾ und die „Terse RDF Triple Language“⁴⁰⁾ (Turtle). Obwohl Turtle eine kompaktere Darstellung ermöglicht und aktuell als inoffizieller Standard gilt, findet RDF/XML noch umfangreich Anwendung. Ein Grund dafür ist, dass für viele Programmiersprachen Bibliotheken für den Umgang mit XML zur Verfügung stehen. Bibliotheken für die Arbeit mit Turtle sind im Vergleich zu XML bisher weniger häufig anzutreffen. In RDF/XML werden die Tripel – wie der Name schon vermuten lässt – in einer XML-Struktur abgelegt. Für die Arbeit mit RDF/XML – und später Turtle – dient folgender RDF-Graph als Beispiel:

Abbildung 5: RDF-Graph - Koordinaten lokalisieren Inschrift

‹23› Eine Beschreibung des Graphen aus Abb. 5 mittels RDF/XML, könnte das folgendermaßen aussehen:

1 <?xml version="1.0" encoding="utf8"?>
2 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:voc="http://ontology.spatialhumanities.de/predicates/">
3  	<rdf:Description rdf:about="http://store.spatialhumanities.de/coords/0003">
4  		<voc:locates>
5  			<rdf:Description rdf:about="http://www.inschriften.net/data/di058/articles/di058-0006">
6  			</rdf:Description>
7  		</voc:locates>
8  	</rdf:Description>
9 </rdf:RDF>

‹24› Nach der obligatorischen Angabe der XML Version in Zeile 1, wird in Zeile 2 als Erstes ein Knoten vom Typ rdf:RDF geöffnet, welcher im Allgemeinen als Wurzel eines RDF/XML Dokumentes verwendet wird. Weiterführend in dieser Zeile werden die Namensräume für RDF und unser Vokabular definiert. Die Abkürzung rdf: als Namensraumbezeichner zu benutzen ist lediglich Konvention, sie kann aber auch nach Belieben anders benannt werden.⁴⁰⁾ Das Objekt http:// www.inschriften.net/data/di058/articles/di058-0006 (Zeile 5 und 6) wird von dem Prädikatknoten umschlossen (Zeilen 4 und 7), welcher selber wiederum innerhalb des Subjektknotens (Zeilen 3 und 8) steht. Für ein weiteres Tripel würde nach Zeile 8 ein weiterer rdf:Description Knoten eingefügt, darin dann wieder ein Prädikatenknoten innerhalb dessen sich der Objektknoten befindet, und so weiter und so fort. Das <rdf:Description> Element beinhaltet die Beschreibung der Ressource, welche durch rdf:about identifiziert wird.⁴¹⁾ Um die Übersichtlichkeit und die Lesbarkeit von RDF/XML zu erhöhen, gibt es mehrere Möglichkeiten: Als ersten Schritt kann man sich Namensräume definieren und damit die URIs abkürzen. Als zweiten Schritt kann man sich sogenannte base:URIs definieren und als drittes, da es sich hierbei um ein XML-Dokument handelt, XML-Entitäten benutzen.⁴²⁾ Wendet man dies auf das obige Beispiel an, sieht es folgendermaßen aus:

1 
2 
3 <rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:voc="http://ontology.spatialhumanities.de/predicates/" xml:base="http://store.spatialhumanities.de/coords/">
4 	<rdf:description rdf:about="0003">
5 		<voc:lokalisiert rdf:resource="&dio58;di058-0006">
6 	</voc:lokalisiert></rdf:description>
7 </rdf:rdf>

‹25› Auf den ersten Blick fällt auf, dass das XML, welches den selben Sachverhalt beschreibt zwei Zeilen kürzer ist obwohl eine weitere Zeile (2) hinzugekommen ist. In Zeile 5 wird die in Zeile 2 definierte !ENTITY benutzt. Sie ist dadurch erheblich kürzer und übersichtlicher. Bei Verwendung von relativen URIs in den Attributen (Zeile 4), werden diese um die mit xml:base definierte Basis-URI ergänzt. Das Objekt wird als Attribut rdf:resource in den jetzt selbstschließenden Prädikatknoten eingefügt (Zeile 5). Das darzustellende Tripel ist im zweiten Beispiel nun in drei Zeilen (4–6) niederschreibbar, statt wie vorher in sechs Zeilen (3–8). Diese Maßnahmen erhöhen die Lesbarkeit erheblich und verringern bei umfangreichen Dokumenten die Schreibarbeit und somit auch die Fehleranfälligkeit.

‹26› Wenn das Beispiel aus Abb. 5 in Turtle dargestellt werden soll, sieht es folgendermaßen aus:

1 <http://store.spatialhumanities.de/coords/0003>
  <http://ontology.spatialhumanities.de/predicates/locates>
  <http://www.inschriften.net/data/di058/articles/di058-0006> .

‹27› In der Turtlesyntax werden Subjekt – Prädikat – Objekt jeweils durch ein Leerzeichen getrennt hintereinander geschrieben und URIs in spitze Klammern eingeschlossen. Literale werden wie in der Graphendarstellung nicht in spitze Klammern, sondern in normale Anführungszeichen eingeschlossen. Am Ende jeder Zeile bzw. jedes Tripels steht ein Punkt. Tabulatoren und Zeilenschaltungen werden überlesen und können somit zum Beispiel für bessere Lesbarkeit nach Belieben eingefügt werden. Um die Übersichtlichkeit, die Lesbarkeit und den Arbeitskomfort bei Turtle weiter zu erhöhen, kann man sich – am Anfang des Dokumentes – sogenannte Präfixe (Namensräume) definieren und damit im Folgenden die URIs abkürzen. Diese dürfen dann allerdings nicht mehr in spitze Klammern geschrieben werden. Ein entsprechend gekürztes Turtledokument für Abb. 5 könnte so aussehen:⁴³⁾

1 @prefix cord: <http://store.spatialhumanities.de/coords/> .
2 @prefix pred: <http://ontology.spatialhumanities.de/predicates/>.
3 @prefix hild: <http://www.inschriften.net/data/di058/articles/> .
4
5 cord:0003	pred:locates	hild:di058-0006 .

‹28› Wie zu erkennen ist, lässt sich die Zeile mit dem eigentlichen Tripel (5) gut lesen, passt jetzt wirklich in eine Zeile und muss nicht wie im ersten Turtlebeispiel auf drei Zeilen umgebrochen werden.

‹29› Die Turtlesyntax ist eine Untermenge zur „Notation 3“⁴⁴⁾ (N3) Syntax und eine Obermenge zur „N-Triples“⁴⁵⁾ (N) Syntax. Ursprünglich wurde, unter anderem von Tim Berners-Lee, die N Syntax entwickelt, war aber (für RDF) zu umfangreich⁴⁶⁾ und wurde dann auf die N3 Syntax reduziert. Damit konnte man die einzelnen Tripel gut beschreiben, wobei darin Konstrukte fehlten um effizient mit größeren Mengen an Tripeln umgehen zu können. Daraufhin wurden unter anderem einige Kurzschreibweisen wieder hinzugenommen und so entstand als Ergebnis die zurzeit als inoffizieller Standard geltende Turtlesyntax.⁴⁷⁾

‹30› Abschließend sei noch auf einige wichtige RDF Sprachkonstrukte eingegangen. Zunächst werden Möglichkeiten zur kürzeren Beschreibung von mehreren Tripeln mit dem selben Subjekt bzw. mit dem selben Subjekt und dem selben Prädikat vorgestellt. Dazu sei folgender RDF-Graph gegeben (Abb. 6):

Abbildung 6: RDF - Graph mit identischem Subjekt und teils identischen Prädikaten

‹31› Eine Serialisierung in Turtle würde abgesehen von den verschieden Präfixen ohne weitere Turtlesprachmittel so aussehen:

1 @prefix loca: <http://store.spatialhumanities.de/locations/> .
2 @prefix pred: <http://ontology.spatialhumanities.de/predicates/> .
3 @prefix hild: <http://www.inschriften.net/data/di058/articles/> .
4
5 hild:di058-0006	pred:isOppositeFrom	hild:di058-0010 .
6 hild:di058-0006	pred:isVisibleFrom	hild:di058-0012 .
7 hild:di058-0006	pred:isVisibleFrom	loca:0001 .

‹32› Hier wird sichtbar, dass in den Tripeln mehrfach dasselbe Subjekt <http://www.inschriften.net/data/di058/articles/di058-0006>, zweimal zusätzlich sogar dasselbe Prädikat <http://ontology.spatialhumanities.de/predicates/isVisibleFrom> vorhanden ist. Genau für diese beiden Anwendungsfälle bietet Turtle Kurzschreibweisen an. Mit einem Semikolon werden Tripel mit demselben Subjekt getrennt, ein Komma separiert Tripel, welche sich das Subjekt und das Prädikat teilen. Am Ende einer solchen Struktur steht ein Punkt. In folgendem Turtlebeispiel wurden diese beiden Kurzschreibweisen benutzt. Auch dieses Beispiel serialisiert den RDF-Graphen aus Abb. 6.⁴⁸⁾

1  hild:di058-0006	pred:isOppositeFrom	hild:di058-0010 ;
2 			pred:isVisibleFrom	hild:di058-0012 ,
3 				        	loca:0001 .

‹33› Alle Tripel teilen sich dasselbe Subjekt (dargestellt durch das Semikolon) und die Zeilen 2 und 3 teilen sich zusätzlich dasselbe Prädikat (dargestellt durch das Komma). Für die anderen Fälle in diesem Zusammenhang (selbes Objekt, selbes Prädikat aber unterschiedliche Subjekte, ...) existieren in Turtle keine Kurzschreibweisen.

‹34› Als weiteren Punkt seien hier noch mehrwertige Bezeichner und in diesem Zusammenhang sogenannte „Blank Nodes“ (Leere Knoten) erwähnt. Es soll zum Beispiel folgender Sachverhalt mit RDF formalisieren werden. In einer Poststelle wurden Nachrichten mit entsprechenden (Zusatz-) Informationen versandt:

• 1956 gesendet von Mainz nach Berlin: „Hallo Adam“

• 1962 gesendet von München nach Mainz: „Gutes Wetter“

• 1964 gesendet von Berlin nach Hamburg: „Test Test“

• …

Abbildung 7: Modellierung Poststelle Nachrichten

‹35› Wie zu erkennen ist, hat eine Nachricht viele von ihr abhängende Eigenschaften und in einer Poststelle existieren sicherlich viele Nachrichten. Je nach Ausprägung hat eine Nachricht verschiedene Eigenschaftswerte für das Jahr, den Text, die Quelle und das Ziel. Die Nachricht ist also ein mehrwertiger Bezeichner und in jeder Ausprägung verschieden von den anderen. Das heißt, es existiert nicht die eine Nachricht, welche mit einer URI eindeutig benennbar wäre, sondern es existieren viele unterschiedliche Ausprägungen davon; trotz allem sind es jeweils Nachrichten. Um dies in RDF sinnvoll abzubilden, existieren die sogenannten „Leeren Knoten“. Sie sind Hilfsknoten für die jeweilige Ausprägung, an denen die entsprechenden Eigenschaftswerte hängen. Eine graphische Modellierung für die ersten beiden Nachrichten zeigt Abb. 7.⁴⁹⁾ Für weitere Nachrichten wird jeweils ein weiterer Leerer Knoten mit den entsprechenden Eigenschaftswerten hinzugefügt. Eine Serialisierung des Graphen aus Abb. 7 könnte in Turtle folgendermaßen aussehen:

1 @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
2 @prefix wiki: <https://de.wikipedia.org/wiki/> .
3
4 wiki:Postamt	wiki:Nachricht
5 		[	wiki:Jahr	"1956"^^xsd:integer ;
6 			wiki:Text	"Hallo Adam"^^xsd:string ;
7 			wiki:Quelle	wiki:Mainz ;
8 			wiki:Ziel	wiki:Berlin ] ,
9
10 		[	wiki:Jahr	"1962"^^xsd:integer ;
11 			wiki:Text	"Gutes Wetter"^^xsd:string ;
12 			wiki:Quelle	wiki:München ;
13 			wiki:Ziel	wiki:Mainz ] .

‹36› Die Einträge innerhalb der eckigen Klammern gehören jeweils zusammen und bilden die eigentliche Ausprägung des jeweiligen Leeren Knotens. Diese Darstellung ist eine weitere in Turtle vorhandene Kurzschreibweise. Die einzelnen Zeilen würden normalerweise so aussehen:

1 wiki:Postamt	wiki:Nachricht	_:id1 .
2 _:id1			wiki:Jahr		"1956"^^xsd:integer ;
3  			wiki:Text		"Hallo Adam"^^xsd:string ;
4  			wiki:Quelle		wiki:Mainz ;
5 			wiki:Ziel		wiki:Berlin .

‹37› Die IDs müssen im gesamten RDF-Dokument eindeutig sein. Leere Knoten sind nur für Subjekte und Objekte zulässig. Dies ist auch insofern plausibel, da ein Prädikat niemals ein Knoten ist.

‹38› An vorletzter Stelle sei noch auf die Gruppierung von Elementen mittels RDF eingegangen. Diese erfolgt in RDF in Listen, wobei offene Listen als Container, abgeschlossene Listen als Collections bezeichnet werden. „Container und Listen sind lediglich Kurzschreibweisen für RDF-Graphen […]. Sie haben darüber hinaus keinerlei formale Bedeutung [...].“⁵⁰⁾ Die in RDF möglichen Containerformate sind rdf:Bag, rdf:Seq und rdf:Alt. Die Unterschiede zwischen diesen Formaten fasst Tabelle 1 zusammen.⁵¹⁾ rdf:Seq beschreibt eine Sequenz von Ressourcen oder Literalen, also eine geordnete Liste. rdf:Alt beschreibt sich ausschließende Alternativen von Elementen. rdf:Bag kann als ungeordnete Liste verstanden werden,⁵²⁾ und benutzt werden, wenn die beiden anderen Formate nicht möglich sind.

‹39› Die Kurzschreibweise für Collections in der Turtle-Syntax ist die Zusammenfassung innerhalb runder Klammern. Ein gutes Beispiel für eine Collection sind die „Arabischen Ziffern“⁵³⁾ 0 bis 9. Es ist unstrittig, dass diese Liste mit ihren zehn Elementen abgeschlossen ist. Wenn wir dies in Turtle darstellen, sieht es wie folgt aus:

1 @prefix wiki: <https://de.wikipedia.org/wiki/> .
2 @prefix pred: <http://ontology.spatialhumanities.de/predicates/> .
3
4 wiki:Arabische_Ziffer	pred:contains
5 	( "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" ) .

‹40› Abschließend zu RDF wird noch die sogenannte Reifizierung erwähnt. Reifizierung ist eine Methode, Aussagen über andere Aussagen zu treffen. Dazu wird in RDF das Tripel – die Aussage – über das eine Aussage getroffen werden soll, mittels RDF Syntax in seine Bestandteile zerlegt und ein zentraler Leerer Knoten eingeführt, welcher das gesamte Ursprungstripel repräsentiert. Es muss nicht zwingend ein Leerer Knoten sein, diesem Knoten kann eine URI zugewiesen werden. Weiterhin werden als Prädikat-Objekt-Konstrukt die einzelnen Bestandteile des Ursprungstripels – also das Subjekt, das Prädikat und das Objekt – und eines für die Typisierung angefügt. Somit sind Tripel vorhanden mit denen man Ursprungstripel beschreiben kann. RDF ist damit in der Lage sich selbst (syntaktisch) zu beschreiben. Die dafür notwendigen RDF-Sprachelemente sind: rdf:subject, rdf:predicate und rdf:object sowie rdf:statement.

‹41› Zusätzlich zu den ([...]RDF[...]) Reifikations-Properties gibt es im RDFS-Vokabular noch rdf:statement als Klassenbezeichner, der dazu verwendet werden kann, den ‚zentralen‘ Knoten eines reifizierten Tripels zu kennzeichnen.⁵⁴⁾

‹42› Ein Beispiel: Wir möchten die Aussage „Reifizierung - ist - ‚Aussagen über Aussagen treffen‘“ um die Information ergänzen, dass uns eben dieser Sachverhalt durch den Autor dieser Arbeit erklärt wird. Abb. 8 veranschaulicht das Prinzip der Reifizierung:

Abbildung 8: Prinzip Reifizierung

‹43› Wenn wir diesen Sachverhalt in RDF überführen und in Turtle darstellen sieht es wie folgt aus:

1 @prefix dbpe:	<http://de.dbpedia.org/page/> .
2 @prefix pred:	<http://triple.spatialhumanities.de/vocabulary/> .
3 @prefix wiki:	<https://de.wikipedia.org/wiki/> .
4 @prefix rdf:	<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
5 @prefix rdfs:	<http://www.w3.org/2000/01/rdf-schema#> .
6 
7 wiki:autor	pred:explains
8 	[	rdf:subject		dbpe:reifizierung ;
9 		rdf:predicate	        rdfs:isDefinedBy ;
10 		rdf:object		"Aussagen über Aussagen zu treffen" ;
11 		rdf:type		rdf:statement ] .

Die erläuterten Beispiele sollen als Einführung in die RDF Grundlagen genügen.⁵⁴⁾

RDF-Schema (RDFS) und dessen Sprachkonstrukte

‹44› Das RDF-Schema⁵⁵⁾ (RDFS) ist ein spezielles RDF-Vokabular. Es stellt Klassen, Eigenschaften (properties) und Hierarchien für RDF zur Verfügung. Weiterhin können Definitions- und Wertebereiche für entsprechend klassifizierte oder typisierte Ressourcen festgelegt sowie Annotationsmöglichkeiten eingebracht werden. Mit all diesen neuen Features bietet sich nun die Möglichkeit, von der reinen RDF-Wissensrepräsentation zu einer semantischen Beschreibung überzugehen. Hierzu werden im Folgenden die Sprachmittel der eben genannten Teilbereiche kurz vorgestellt. Alle Beispiele sind in der Turtle-Syntax verfasst und es gelten folgende Präfixdefinitionen:

1 @prefix rdf:	<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
2 @prefix rdfs:	<http://www.w3.org/2000/01/rdf-schema#> .
3 @prefix xsd:	<http://www.w3.org/2001/XMLSchema#> .
4 @prefix shclass: <http://ontology.spatialhumanities.de/classes/> .
5 @prefix pred:	<http://ontology.spatialhumanities.de/predicates/> .
6 @prefix main: <http://www.inschriften.net/data/dio01/articles/> .

Klassen und Klassenhierarchien

7 #Klasse und davon abgeleitete Klasse (Klassenhierarchie)
8 shclass:inscription	rdf:type	rdfs:Class .
9 shclass:inscription	rdfs:SubClassOf	rdfs:Ressource .
10 shclass:tumba	rdf:type	rdfs:Class .
11 shclass:tumba        rdfs:SubClassOf	shclass:inscription .
12 main:dio001-sn1-0023	rdf:type	shclass:tumba .

‹45› Noch zu erwähnen ist die Möglichkeit von Kommentaren innerhalb eines RDF-Dokumentes. Diese werden in Turtle mit einem # eingeleitet und gelten bis zum nächsten Zeilenumbruch (Zeile 7). Bei RDF/XML können ganz normal XML-Kommentare verwendet werden.

‹46› In Zeile 8 ist demonstriert, wie die Ressource shclass:inscription als Klasse definiert und typisiert wird. Um darzustellen, dass eine Klasse ein Teilbereich einer anderen Klasse ist, benutzt man rdfs:SubClassOf. Zeile 9 beschreibt, dass die Klasse der Inschriften ein Teil der allgemeinen (vordefinierten) Klasse der Ressourcen ist. In den Zeilen 10 und 11 wird eine weitere Unterklasse, die Klasse der Tumbenplatten (tumba⁵⁶⁾), als eine Spezialisierung der allgemeineren Klasse der Inschriften definiert. Zeile 12 ordnet eine Inschrift dieser Klasse der Tumbenplatten zu. Da Klassenstrukturen in RDF transitiv sind, ist die spezielle Ausprägung der Tumbenplatte main:dio001-sn1-0023 somit vom Typ shclass:tumba, shclass:inscription und rdfs:Ressource. Mit diesen Sprachmitteln können weit verzweigte Klassenhierarchien abgebildet werden.

Properties und Propertyhierarchien

13 #Eigenschaften (properties) und davon abgeleitete Eigenschaften (Eigenschaftshierarchie)
14 pred:isVisibleFrom	rdf:type		rdf:Property .
15 pred:isAccessibleFrom	rdfs:SubPropertyOf	pred:isVisibleFrom .

‹47› An Sakralorten kommt es oft vor, dass Inschriften sichtbar aber aufgrund von Absperrungen nicht zugänglich sind. Dieser Sachverhalt soll nun mit RDFS-Sprachmitteln formalisiert werden. In Zeile 14 wird dem Prädikat isVisibleFrom der Typ Eigenschaft zugewiesen und in Zeile 15 isAccessibleFrom als Teileigenschaft davon definiert (rdfs:SubPropertyOf). rdf:Property ist die allgemeine und vordefinierte Klasse der Eigenschaften. Durch die auch hier geltende Transitivität können entsprechend weit verzweigte Hierarchien erstellt werden.

Definitions- und Wertebereiche (Constraints)

16 #Domainkonstrukt -> Die Property hasAge soll nur auf die Klasse der Inschriften angewendet werden können.
17 #Subjekttypisierung
18 pred:hasAge	rdfs:domain	shclass:inscription .
19 
20 #Rangekonstrukt -> Ein Alter soll immer eine positive, ganze Zahl sein.
21 #Objekttypisierung
22 pred:hasAge	rdfs:range	xsd:nonNegativeInteger .

‹48› Um festlegen zu können, dass Eigenschaften nur für bestimmte Klassen gelten oder nur bestimmte Werte annehmen können, bringt RDFS sogenannte Constraints (Einschränkungen) mit. Um festzulegen, dass ein Prädikat nur auf bestimmte Subjekte angewendet werden kann, – also einen bestimmten Definitionsbereich hat – wird rdfs:domain benutzt. In Zeile 18 wird definiert, dass das Subjekt, auf welches das Prädikat hasAge angewendet werden kann, immer von der Klasse inscription sein muss. Eine ähnliche Einschränkung kann für Objekte vorgenommen werden, also für den Wertebereich. Dazu wird in Zeile 22 mittels rdfs:range definiert, dass das Alter immer eine positive und ganzzahlige Zahl (xsd:nonNegativeInteger) sein muss. Es wird somit ausgeschlossen, dass bestimmte Prädikate auf sämtliche möglichen Objekte angewendet werden können, in diesem Zusammenhang kann auch von Subjekt- und Objekttypisierung gesprochen werden.

Annotationseigenschaften und Sprachangaben

23 #Label, Comments und Sprachangaben
24 shclass:tumba	rdfs:label	"Tumbenplatte"@de .
25 shclass:tumba	rdfs:label	"tumba"@en .
26 shclass:tumba	rdfs:comment	"slab from a tomb monument"@en .
27 shclass:tumba	rdfs:comment	"Eine Tumbenplatte ist die spezielle Form des Deckels auf einem Grabmal, ..."@de .

‹49› Um Ressourcen ausführlicher zu beschreiben, bietet RDFS die Sprachmittel rdfs:label (Zeilen 24 und 25) und rdfs:comment (Zeilen 26 und 27) an. Dabei stellt rdfs:label eine Etikettierung des Subjektes dar, während rdfs:comment eine ausführlichere Beschreibung des Subjektes ermöglicht. Außerdem ist hier die mögliche Spezifikation einer Sprache für Literale dargestellt.

‹50› RDF-Schema bietet neben den wichtigsten und hier vorgestellten, noch weitere Sprachmittel. Eine vollständige Liste der RDFS-Sprachkonstrukte findet sich unter der offiziellen Webressource www.w3.org/2000/01/rdf-schema.⁵⁷⁾ RDFS bietet die Möglichkeit, innerhalb von RDF sogenannte „lightweight Ontologien“⁵⁸⁾ zu erstellen. Falls weitergehende semantische Sprachmittel benötigt werden und umfangreichere Ontologien⁵⁹⁾ erstellt werden sollen, ist es erforderlich auf andere Mittel zurückzugreifen. Eine Möglichkeit dafür wäre die „Web Ontology Language“⁶⁰⁾ (OWL). Beides ist aber zurzeit für IBR nicht erforderlich und wird im Rahmen dieses Beitrags daher nicht weiter ausgeführt.

REST

‹51› Das Akronym REST steht für „Representational State Transfer“ und geht auf die Dissertation⁶¹⁾ von Roy Fielding zurück. REST ist ein Architekturstil, um einzelne Ressourcen oder ganze Datenbestände sowohl für Menschen als auch für Maschinen in lesbarer und verarbeitbarer Form zur Verfügung zu stellen, aber es ist kein fest definierter Standard! Nach Fieldung sollen die Ressourcen bzw. der Service folgende Anforderungen erfüllen:

1. Adressierbarkeit: Die einzelnen Ressourcen müssen über eine URI eindeutig identifiziert werden können.

2. Zustandslosigkeit: Es existieren keine Sessions, denn jeder Request enthält alle notwendigen Informationen um diesen abzuschließen und kann dadurch zustandslos sein.⁶²⁾ Anfragen sind also unabhängig voneinander.

3. Einheitliche Schnittstelle: Es wird ein einheitlicher Satz von Standardmethoden verlangt, um auf die Ressourcen zuzugreifen. Im Falle der Benutzung von HTTP sind dies unter anderem GET, PUT, POST, DELETE, HEAD und OPTIONS.

4. Entkopplung von Ressourcen und Repräsentation: Für eine Ressource können verschiedene Repräsentationen (XML, JSON) vorliegen und je nach Anforderung durch den Client entsprechend ausgeliefert werden.⁶³⁾

‹52› Über eine REST-Schnittstelle kann somit ein Datenbestand abgefragt und gegebenenfalls auch geändert oder gelöscht werden, ohne dass die genaue Struktur der Daten im Hintergrund bekannt ist. Man kann, wenn diese Methoden implementiert und die entsprechenden Berechtigungen vorhandenen sind, Daten an- bzw. abfragen (GET), Daten erstellen (POST) und ändern (PUT) sowie wieder löschen (DELETE). Dazu muss allerdings noch gesagt gesagt werden, dass POST und PUT in REST unscharf verwendet werden. Ein PUT einer noch nicht existierenden Ressource kann je nach Schnittstelle als „Änderung“ verstanden werden, welche die Ressource erzeugt. Gleichermaßen muss ein POST nicht zwingend nur Ressourcen erzeugen sondern kann auch bestimmte Eigenschaften einer Gruppe schon existierender Ressourcen verändern. Hier zeigt sich die fehlende Standardisierung.

‹53› Prinzipiell wird kein bestimmtes Protokoll von REST vorgegeben, aber die Kommunikation erfolgt meistens über das HTTP-Protokoll. Mittels (HTTP-)Content Negotiation wird über Header-Informationen (Accept) unter anderem das Rückgabeformat gesteuert. Dies ist in den meisten Fällen XML ('Accept: application/xml') oder JSON ('Accept: application/json'). Eine Website, die REST implementiert, muss nicht notwendigerweise alle genannten Methoden zur Verfügung stellen. Die URIs zu den einzelnen Datensätzen sollten strukturiert und verständlich sein. REST soll im Rahmen des IBR-Projektes zur Kommunikation der verschiedenen Softwarekomponenten untereinander eingesetzt werden.

Tripel Store

‹54› Ein RDF- oder Tripel Store ist eine Datenbank, die speziell dafür ausgelegt wurde RDF-Tripel effizient zu speichern, Abfragen zu beantworten und im Allgemeinen damit zu interagieren. Im Gegensatz zu normalen Datenbanken handelt es sich hierbei theoretisch um eine einzelne flache Tabelle mit drei Spalten, jeweils eine für die Subjekte, Prädikate und Objekte. Zumindest wird dies nach Außen so dargestellt. Die interne Struktur eines Tripel Store ist natürlich komplexer. Um zum Beispiel bei einer großen Anzahl an Tripeln noch effizient darauf abfragen zu können, sind ausgefeilte Indexstrukturen erforderlich. Da jede Beziehung in einem RDF-Graphen durch ein Tripel beschrieben wird und die einzelnen Bestandteile der Tripels noch klassifiziert (Subjekt und Objekt) bzw. typisiert (Prädikat) werden können, entsteht hier schnell eine große Anzahl an Tripeln.

SPARQL

‹55› SPARQL⁶⁴⁾ steht als rekursives Akronym für „SPARQL Protocole And RDF Query Language“ und ist eine SQL ähnliche Abfragesprache für RDF-Graphen. Es können mit SPARQL komplexe Anfragen gestellt und die Darstellung der Ergebnisse beeinflusst werden. Als Anfragemuster werden RDF-Graphen verwendet und in der Turtle-Syntax serialisiert beschrieben. „Allerdings führt SPARQL zusätzliche Anfragevariablen ein, die man dazu verwenden kann, bestimmte Elemente im Anfragegraphen als Ergebnis zu ermitteln.“⁶⁵⁾ Eine SPARQL-Abfrage besteht aus drei Teilen. Am Anfang werden mit dem Schlüsselwort PREFIX gegebenenfalls nötige Präfixe definiert:

1 PREFIX hild: <http://www.inschriften.net/data/di058/articles/>

Es wird hier kein Punkt am Ende der Zeile geschrieben!

2 SELECT *

„Das Schlüsselwort SELECT bestimmt allgemein das Ausgabeformat […]“.⁶⁶⁾ Das Sternchen steht hier als Wildcard und es werden alle angefragten Variablen im WHERE Ausdruck zurückgeliefert.

3 WHERE { ?s ?p ?o }

Mit dem Schlüsselwort WHERE wird die eigentliche Anfrage eingeleitet. Alles innerhalb der geschweiften Klammern hinter WHERE gilt als Anfragemuster.

‹56› Es wird also zunächst beschrieben (selektiert), welche Rückgabe(werte) ausgegeben werden sollen und dann welche Bedingungen diese Werte erfüllen müssen. Wobei ?s für das Subjekt steht, ?p für das Prädikat und ?o für das Objekt. Dies entspricht der allgemeinen Konvention, prinzipiell können die Variablennamen frei gewählt werden. Obige Abfrage zum Beispiel gibt alle Tripel des Stores zurück. Die Präfixdefinition ist in diesem Fall unnötig, wurde hier aber zu Erklärungszwecken eingefügt.

‹57› Mit „SPARQL Update“⁶⁷⁾ steht eine von SPARQL abgeleitete Aktualisierungssprache (update language) für RDF-Graphen zur Verfügung, die auch das Aktualisieren (Insert, Delete, ...) von Graphen ermöglicht und nicht nur die reine Anfrage von Daten.

‹58› Ein oft verwendeter Begriff im Zusammenhang mit SPARQL ist der sogenannte SPARQL-Endpoint. Dies ist im einfachsten Fall eine URI an die SPARQL-konforme Anfragen gestellt werden können und von welcher die zur Anfrage passenden Ergebnisse zurückgeliefert werden.⁶⁸⁾

‹59› Für weitergehende Informationen dazu sei auf die offizielle Spezifikation www.w3.org/TR/sparql11-overview/ und auf Hitzler, et. al., Seite 202 bis 233 verwiesen. Im Fall von IBR soll SPARQL später benutzt werden, um eine umfängliche Möglichkeit zu Verfügung zu haben, die im Tripel Store abgelegten Daten abzufragen.

Prädikatenvokabularien inklusive Klassifizierungen und deren Anwendung

‹60› In diesem Kapitel werden die erstellten Prädikatenvokabularien und die zugehörigen Klassifizierungen einerseits für die räumliche Komponente und andererseits für die geisteswissenschaftliche Komponente vorgestellt. Hierbei liegt der Fokus auf letzterer, da in diesem Bereich eine komplett eigene Entwicklung des Vokabulars notwendig war; daher erfolgt eine ausführlichere Darstellung. An diese anschließend wird beispielhaft gezeigt, wie mit den Vokabularien gegebenenfalls neue geisteswissenschaftliche Fragestellungen abgeleitet werden könnten. Am Ende des Kapitels wird beispielhaft ein Inschriftenträger mittels der vorgestellten Prädikate in seinen räumlichen Kontext eingeordnet.

Räumliches Prädikatenvokabular und zugehörige Klassifizierungen

‹61› Für den räumlichen Teil des Prädikatenvokabulars wurde zunächst das 9-Intersection-Model⁶⁹⁾ evaluiert. Die jeweiligen Teile dieses Modells beschreiben erstens acht verschiedene Body-Body-Relations, also Raumbeziehungen zwischen zwei verschiedenen Körpern. Zweitens neunzehn verschiedene Body-Line-Relations, also räumliche Beziehungen zwischen einem Körper und einer Linie und drittens neunzehn verschiedene Body-Surface-Relations, also Raumbeziehungen zwischen Körpern und (Ober-) Flächen. Die Beziehungen zwischen Körpern und Linien werden im Fall von IBR nicht benötigt. Aber Beziehungen zwischen zwei Körpern und vor allem Beziehungen zwischen Körpern und Oberflächen erschienen anfänglich relevant. Zumal sicherlich gesagt werden kann, dass Inschriften ohne zugehörige Trägeroberflächen nicht denkbar sind. Bei der weiteren Arbeit stellte sich jedoch heraus, dass diese Relationen für den IBR-Anwendungsfall viel zu umfänglich sind. Somit wurde dieser Ansatz (vorerst) wieder verworfen. Als zweites wurde die Spatial Relations Ontology⁷⁰⁾ betrachtet, welche eine W3C konforme Ontologie für geospatiale Relationen ist. Diese beinhaltet die Prädikate: 1km Grid Reference, 20km Grid Reference, contains, disjoint, easting, equal, northing und touches. Es stellte sich heraus, dass diese Ontologie eher dafür geeignet ist, im größeren Maßstab (als innerhalb von Gebäuden) bzw. auf Karten angewendet zu werden. Beispiele dafür sind zum einen die beiden Grid Referenzen und zum anderen die Prädikate easting und northing. Wenn wir diese für den IBR Anwendungsfall höchstwahrscheinlich nicht benötigten Prädikate entfernen, verbleiben noch contains, disjoint, equal und touches. Diese vier Prädikate wurden vorerst beibehalten und durch weitere eigene Prädikate ergänzt. Um nun Richtungen von bestimmten Punkten oder Objekten angeben zu können, wurden hier die Himmelsrichtungen als Prädikate eingeführt (pred:northOf, pred:westOf, pred:southOf und pred:eastOf). Dazugehörend wurde ein Normalenvektor ergänzt (pred:isNormalizedBy), um für die Objekte die Ausrichtung im Raum beschreiben zu können. Abschließend für die Prädikate wurde noch pred:isLocatedBy hinzugenommen, um einem Objekt Geometrien und/oder Koordinaten im lokalen Koordinatensystem⁷¹⁾ des allgemeinen (Kirchen-) Objektes zuordnen zu können. Als Klassifizierungen wurden hier Koordinaten, Orte und Geometrien gewählt. In Turtle repräsentiert durch shclass:coordinates, shclass:location und shclass:geometry.

Geisteswissenschaftliches Prädikatenvokabular und zugehörige Klassifizierungen

‹62› Eine Suchmaschine für Ontologien ist http://swoogle.umbc.edu/ (Zugriff 14.07.2013). Wenn als Suchbegriff „humanities rdf“ benutzt wird, werden 11 Treffer erzielt in einer Gesamtauswahl von über 10.000 Ontologien. Die Relation der insgesamt vorhanden Ontologien und der erzielten Treffer (0,11%) zeigt, dass im Bereich der Geisteswissenschaften bis jetzt nur wenige RDF-Vokabulare vorhanden sind. Die wenigen existenten, waren für den speziellen IBR Anwendungsfall nicht geeignet⁷²⁾, nicht (öffentlich) erreichbar⁷³⁾ oder mit nur fünf Klassen⁷⁴⁾ sehr beschränkt einsetzbar. Daher wurde beschlossen ein eigenes englisches RDF-Vokabular für Inschriften aufzubauen.

‹63› Da von Grund auf neu mit der Prädikatsvergabe begonnen wurde, sollte mit einem möglichst kleinen und überschaubaren Vokabular angefangen und dann geprüft werden, welches Wissen modelliert bzw. was daraus an neuem Wissen abgeleitet werden soll und kann. Bei der zukünftigen Arbeit mit diesem begrenzten Vokabular wird es sicherlich zu der Feststellung kommen, dass noch weitere Prädikate durchaus sinnvoll oder sogar notwendig sind. Diese werden dem Vokabular hinzugefügt und es wird wiederholt dahingehend geprüft, inwieweit auf Basis des erweiterten Vokabulars neues Wissen abgeleitet werden kann. Dieser Prozess wird so lange wiederholt bis sich einem Vokabular mit – für den aktuellen Anwendungsfall – ausreichenden Prädikaten angenähert wurde. Die Entwicklung des Vokabulars ist also ein „iterativer Prozess“, welcher weiterhin fortgesetzt werden wird.

‹64› Die in diesem Artikel benutzten beispielhaften geisteswissenschaftlichen Prädikate im IBR-Projekt sind nachfolgend ausführlich dargestellt. Ein geeigneter Namensraum für die Prädikate ist http:// ontology.spatialhumanities.de/predicates/.

‹65› Präfixdefinitionen für die Prädikate und deren Hierarchie in der Turtle-Syntax:

1 @prefix rdf:	<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
2 @prefix rdfs:	<http://www.w3.org/2000/01/rdf-schema#> .
3 @prefix xsd:	<http://www.w3.org/2001/XMLSchema#> .
4 @prefix shclass: <http://ontology.spatialhumanities.de/classes/> .
5 @prefix pred:	<http://ontology.spatialhumanities.de/predicates/> .

‹66› Als eines der ersten Prädikate wurde die Sichtbarkeit in das Prädikatenvokabular eingefügt, also von welchen Orten aus eine Inschrift oder andere Punkte gesehen werden können.

6 # Prädikat sichtbarVon
7 pred:isVisibleFrom	rdf:type		rdf:Property .
8 pred:isVisibleFrom	rdfs:domain		shclass:inscription .
9 pred:isVisibleFrom	rdfs:domain		shclass:location .
10 pred:isVisibleFrom	rdfs:domain		shclass:coordinates .
11 pred:isVisibleFrom	rdfs:range		shclass:inscription .
12 pred:isVisibleFrom	rdfs:range		shclass:location .
13 pred:isVisibleFrom	rdfs:range		shclass:coordinates .

‹67› Das Prädikat wird in Zeile 7 definiert, außerdem wurden Definitions- und Wertebereiche festgelegt (Zeile 8 bis 13).

‹68› Als zweites Prädikat wurde istZugänglichVon eingeführt. Oftmals sind Orte oder Inschriften in Kirchen nicht zugänglich, aber trotzdem sichtbar. Deshalb wurde dieses Prädikat von istSichtbarVon abgeleitet.

14 # Prädikat zugänglichVon
15 pred:isAccessibleFrom	rdf:type		rdf:Property .
16 pred:isAccessibleFrom	rdfs:SubPropertyOf	pred:isVisibleFrom .

‹69› Das Prädikat ist mit isAccessibleFrom bezeichnet (Zeile 15) und von isVisibleFrom mittels rdfs:SubPropertyOf abgeleitet (Zeile 16). Weiterhin wurden die Klassen der Orte und Koordinaten als Definitions- und Wertebereiche festgelegt, zusätzlich für den Definitionsbereich noch die Klasse der Inschriften.⁷⁵⁾ Dies ist zurzeit das einzige abgeleitete Prädikat in IBR. Die meisten Inschriften sind datierbar, daher wurde ein Prädikat für das Alter (hasAge) eingeführt.

17 pred:hasAge			rdf:type		rdf:Property
18 pred:hasAge			rdfs:domain		shclass:inscription .
19 pred:hasAge			rdfs:range		xsd:nonNegativeInteger .

‹70› Es wird das Prädikat definiert (Zeile 17), festgelegt, dass es nur auf die Klasse der Inschriften angewendet werden kann (Zeile 18) und das es eine positive, ganze Zahl sein muss (Zeile 19).

‹71› Als nächstes Prädikat ist isLocatedOppositeFrom hinzugekommen, um ausdrücken zu können, dass sich ein Objekte gegenüber von einem Anderen befindet.

20 pred:isLocatedOppositeFrom	rdf:type		rdf:Property .

‹72› Es gelten die Klassen der Orte, der Koordinaten und der Inschriften als Definitions- und Wertebereiche für das Prädikat (auch hier nicht in Turtle dargestellt). Für einen Geisteswissenschaftler ist die Information wichtig, ob eine Inschrift beispielsweise an einer Stelle an der im Mittelalter kirchliche Prozessionen⁷⁶⁾ vorbeiführten liegt, also prägnanter als andere Inschriften platziert wurde. Dafür wurde das Prädikat onPathOfProcession hinzugefügt.

21 pred:onPathOfProcession	rdf:type		rdf:Property .

‹73› Der Definitionsbereich ist die Klasse der Inschriften. Für den Wertebereich wurde für dieses und alle weiteren hier vorgestellten Prädikate vorerst rdfs:Literal gewählt.

‹74› Es existieren in Kirchen Orte oder Bereiche die nur an ausgewählten Tagen oder in bestimmten Zeiträumen sichtbar oder geöffnet sind.⁷⁷⁾ Dafür wurden die Prädikate pred:OpenOn und pred:viewableOn dem Vokabular hinzugefügt. Abschließend wurden testweise drei Prädikate eingefügt, um aussagen zu können, dass sich ein Objekt innerhalb von etwas Anderem befindet. Dafür wurden die Prädikate pred:locatedIn (befindetSichIn), pred:within (liegtInnerhalbVon) und pred:enclosedBy (wirdUmschloßenVon) definiert. Mögliche Literalwerte dafür wären zum Beispiel: das Seiten- oder Mittelschiff, der Kreuzgang, der Altarbereich/-raum oder eine Kapelle.⁷⁸⁾ Die Prädikatenhierarchie als RDF-Graph darzustellen ist an dieser Stelle nicht sinnvoll, da zurzeit nur ein abgeleitetes Prädikat existiert und der Graph sonst nur Knoten ohne weitere Beziehungen darstellen würde. Als vorerst letztes Prädikat wurde noch pred:isAnnotatedBy ergänzt, um im späteren Projektverlauf Kommentare⁷⁹⁾ zu den Inschriftenträgern zu ermöglichen.

‹75› Nachfolgend werden die bis zum Zeitpunkt der Entstehung dieses Beitrags in Benutzung befindlichen Klassen vorgestellt. Der Namensraum für eigene Klassen sei in IBR beispielhaft http:// ontology.spatialhumanities.de/classes/. Präfixdefinitionen für Klassen und das Klassenbeispiel in der Turtle-Syntax:

1 @prefix shclass:	<http://ontology.spatialhumanities.de/classes/> .
2 @prefix rdf:	<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
3 @prefix rdfs:	<http://www.w3.org/2000/01/rdf-schema#> .

‹76› Da innerhalb von IBR „Die Deutschen Inschriften“ als Datengrundlage benutzt wird, stand eine Oberklasse der Klassenhierarchie gezwungenermaßen schnell fest. Es ist die Klasse der Inschriften, welche von der allgemeinen Klasse der Ressourcen abgeleitet ist. Als Klassenbezeichner wurde hier inscription verwendet (Zeilen 6 und 7).

4 ## Klassen IBR und davon abgeleitete Klassen (Klassenhierarchie)
5 #Klasse Inschrift
6 shclass:inscription	rdf:type	rdfs:Class .
7 shclass:inscription	rdfs:SubClassOf	rdfs:Ressource .

‹77› Als erste Unterklasse der Klasse der Inschriften wurde die Klasse der Tumbenplatten in das Vokabular eingebracht. Eine Tumbenplatte ist die spezielle Form der Abdeckung eines Grabmals. Als Klassenbezeichner wurde hier tumba benutzt (Zeile 9 und 10).

8 #Klasse Tumbenplatte
9 shclass:tumba		rdf:type	rdfs:Class .
10 shclass:tumba	rdfs:SubClassOf	shclass:inscription .

‹78› Des Weiteren lassen sich die Inschriften nach dem gesellschaftlichen Stand bzw. dem sozialen Status der Bezugsperson differenzieren.

11 #Oberklasse der sozialen Klassen
12 shclass:socialClass	rdf:type	rdfs:Class .
13 shclass:socialClass	rdfs:SubClassOf	rdfs:Ressource .

‹79› Dazu wurde eine Oberklasse mit dem Klassenbezeichner socialClass gewählt und von der allgemeinen Klasse der Ressourcen abgeleitet. Von socialClass abgeleitet wurden die Klassen der einzelnen sozialen Stände.

14 #Klasse Klerus
15 shclass:clergy	rdf:type	rdfs:Class .
16 shclass:clergy	rdfs:SubClassOf	shclass:socialClass .

‹80› Als erstes ist hier die Klasse der Personen des geistlichen Stands (Kleriker) zu nennen. Diese Klasse hat den Bezeichner clergy erhalten (Zeilen 15 und 16).

17 #Klasse Adel
18 shclass:noble	rdf:type	rdfs:Class .
19 shclass:noble	rdfs:SubClassOf	shclass:socialClass .

‹81› Als zweites ist die Klasse der Personen des weltlichen Adelsstands ausgewählt worden, mit dem Klassenbezeichner noble (Zeilen 18 und 19).

20 #Klasse Bürger
21 shclass:citizen	rdf:type	rdfs:Class .
22 shclass:citizen	rdfs:SubClassOf	shclass:socialClass .

‹82› Als letzte soziale Klasse wurden mit dem Klassenbezeichner citizen die Angehörigen des (städtischen) Bürgertums definiert (Zeilen 21 und 22).

23 #Label und Comments für die Klassen, incl. Sprachangaben
24 shclass:tumba	rdfs:label	"Tumbenplatte"@de .
25 shclass:tumba	rdfs:label	"tumba"@en .
26 shclass:tumba	rdfs:comment	"slab from a tomb monument"@en .
27 shclass:tumba	rdfs:comment	"Eine Tumbenplatte ist die spezielle Form des Deckels auf einem Grabmal, ..."@de .

‹83› Die Klasse der Tumbenplatten wurde beispielhaft in Deutsch sowie in Englisch kommentiert und etikettiert (Zeilen 27 bis 30).

Abbildung 9: IBR – RDF – Klassenhierarchie

‹84› Diese Klassenhierarchie als Graph dargestellt zeigt Abb. 9. Darin wurden obige Präfixdefinitionen verwendet und die explizite Typisierung als Klasse weggelassen, um eine sinnvolle Darstellung zu ermöglichen.

Möglichkeiten der Wissensgewinnung aus Entitäten, welche mit dem Prädikatenvokabular verbunden sind

‹85› Nachfolgend werden beispielhaft zwei mögliche Fälle konstruiert, die zu beleuchten versuchen, wie sich mit den bis jetzt implementierten Prädikaten und Klassen neue geisteswissenschaftliche Fragestellungen beantworten lassen:

‹86› Im ersten Fall nehmen wir an, dass alle Inschriften auf einer Seite der Kirche zur gesellschaftlichen Schicht des Adels gehören. Nun stellt sich heraus, zum Beispiel durch eine erfolgte Klassifizierung der entsprechenden Inschriften nach der sozialen Klasse (shclass:socialClass und davon abgeleitete Klassen) dass auf der gegenüberliegenden Seite der Kirche alle Inschriften zur gesellschaftlichen Schicht des Klerus gehören.

‹87› Im zweiten Fall nehmen wir an, dass sich durch die Benutzung des Prädikates pred:isVisibleFrom feststellen lässt, dass bestimmte Punkte oder Inschriften nicht vom Altarbereich der Kirche aus sichtbar sind (dessen Benutzung im Mittelalter generell Angehörigen des Klerus vorbehalten war), wohl aber von den Bereichen der Kirche, die im Mittelalter vorwiegend von Laien genutzt wurden. Ein räumlich trennendes Element stellt hierbei eine sogenannte Chorschranke (Lettner) dar.

‹88› In beiden Fällen ergeben sich für einen Geisteswissenschaftler interessante neue Fragestellungen. Warum sind im ersten Fall auf der einen Seite der Kirche nur Inschriften des Adel aufgestellt und auf der gegenüberliegenden Seite nur solche des Klerus? Wieso sind Inschriften aus der gesellschaftlichen Schicht des Bürgertum auf keiner der beiden Seiten vorhanden? Warum war es gegebenenfalls wichtig, dass eine bestimmte Inschrift für die Laien prägnant platziert wurde und für den Klerus im Rahmen seiner sakralen Handlungen nicht sichtbar war?

‹89› Daher sind im Rahmen des IBR Projektes weitere geisteswissenschaftliche Fragestellungen zu entwickeln, welche mit dem hier vorgestellten und gegebenenfalls auf neue Fragestellungen hin anzupassenden bzw. zu erweiternden Vokabular beantwortet werden können.

Verknüpfung von Inschriftenträgern mit dem sie umgebenden Raume mittels der Prädikatenvokabulare

‹90› In diesem Kapitel soll beispielhaft gezeigt werden, wie mit dem vorgestellten Prädikatenvokabular und den entsprechenden Klassifizierungen sinnvolle Verknüpfungen zwischen den Inschriftenträgern und dem sie umgebenden Raum hergestellt werden können. Dazu sei der Graph aus Abb. 10 gegeben; der darin in Beziehung gesetzte Inschriftschriftenträger bzw. der dazugehörige DIO-Artikel, ist in seiner HTML-Repräsentation unter www.inschriften.net/dio001/0023/ verfügbar.⁸⁰⁾

Abbildung 10: Inschriftenträger im Netz der ihn umgebenden Raumelemente

‹91› Die in Abb. 10 verwendeten Präfixe dienen wie üblich der besseren Darstellung und sind wie folgt definiert:

1 # Basic
2 @prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
3 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
4 # IBR
5 @prefix shclass: <http://ontology.spatialhumanities.de/classes/> .
6 @prefix pred: <http://ontology.spatialhumanities.de/predicates/> .
7 @prefix loc:  <http://store.spatialhumanities.de/rest/locations/> . 
8 @prefix geom: <http://store.spatialhumanities.de/rest/geometries/> . 
9 @prefix anno: <http://annotation.spatialhumanities.de/rest/> .
10 # DIO
11 @prefix main: <http://www.inschriften.net/data/dio01/articles/> .

‹92› Mittels der bereits vorgestellten und in Abb. 10 benutzten Prädikate lässt sich über diesen Inschriftenträger folgendes aussagen: Der Inschriftenträger mit der ID main:dio001-sn1-0023 ist sichtbar von einer anderen Inschrift und liegt gegenüber einer dritten Inschrift. Er befindet sich innerhalb des Langhauses⁸⁰⁾ und liegt an einer Stelle, an der die Osterprozession vorbeiführte. Der Inschriftenträger ist zugänglich von dem Ort, der durch die ID loc:A38 genauer spezifiziert wird und er ist von einer bestimmten Geometrie (Form) umschlossen. Des Weiteren wird er von einem durch die ID anno:Z42 spezifizierten Kommentar genauer beschrieben.

‹93› Die letzten drei Aussagen haben Bezug zu anderen Komponenten der IBR-Informationsarchitektur.⁸¹⁾ Zum einen wird dies der Annotation Store sein, welcher sich noch der Konzeptionsphase befindet. Zum anderen ist dies der sogenannte Spatial Store, welcher eine mittels terrestrischem Laserscanning erstellte 3D-Punktwolke des Kirchenobjektes und die daraus abgeleiteten Geometrien enthält. Die letztgenannte Komponente wird zurzeit durch das FH-Institut i3 mainz entwickelt. Diese beiden Komponenten werden hier nicht näher behandelt.

‹94› Über die beiden in Abb. 10 dargestellten Klassifizierungen lässt sich weiterhin aussagen: Der Inschriftenträger mit der ID main:dio001-sn1-0023 ist eine Tumbenplatte vom Grabmal eines Klerikers. Mittels dieser Klassifikation konnte also der erste Satz des zugehörigen DIO-Artikels „Tumbenplatte des Erzbischofs Siegfried III. von Eppstein“⁸²⁾ semantisch annotiert werden.

‹95› Wie in diesem Beispiel aufgezeigt, kann durch die Benutzung der entsprechenden Prädikate und der dazugehörigen Klassifizierungen ein Inschriftenträger in seinem räumlichen Kontext sowohl beschrieben als auch präziser eingeordnet werden. Damit zeigt sich, dass sich mittels RDF die in dieser Arbeit gestellte Fragestellung gut beantworten lässt. Die Schwierigkeit besteht dabei schlicht darin, ein für den jeweiligen Anwendungsfall geeignetes Vokabular zu finden bzw. dieses selber zu erstellen. Ob das vorgestellte Vokabular alle in DIO vorhandenen Raumbezüge sinnvoll abbilden kann, wird der weitere Projektverlauf zeigen. Grundlegend ist RDF jedoch sehr gut geeignet die Raumbezüge geisteswissenschaftlicher Forschungsdaten formalisiert zu beschreiben und somit auch abfragbar zu machen. Weiterhin ist RDF ein effektives Instrument zur Herstellung semantischer Bezüge zwischen geisteswissenschaftlichen Fachdaten einerseits und Raumgeometrien andererseits.

Auswahl eines geeigneten Tripel Stores und die technische Umsetzung

‹96› In diesem Kapitel werden die für einen Einsatz eines Tripel Stores im IBR Projekt zu erfüllenden Kriterien aufgeführt sowie die in Frage kommenden Kandidaten (inklusive Quelltextbeispielen) genauer beschreiben. Am Ende des Kapitels findet ein tabellarischer Vergleich der Kandidaten und der von ihnen erfüllten Kriterien statt.

Kriterien zur Auswahl

‹97› Die von dem Tripel Store zu erfüllenden Kriterien, welcher im Projekt eingesetzt werden soll, sind nachfolgend beschrieben. Die ursprüngliche Auswahl der Tripel Stores abseits der Kriterien erfolgte nach einer Internetrecherche. Hier wurde zudem darauf geachtet, dass die Stores in unterschiedlichen Programmiersprachen geschrieben wurden, um gegebenenfalls vorhandene Beschränkungen durch die verwendete Sprache ausschließen zu können.

‹98› Kriterien:

1. Der Store muss „freie Software“ im Bereich öffentlicher Institutionen die finanziellen Mittel meist begrenzt sind,⁸³⁾ bzw. „Open Source“⁸⁴⁾ sein, weil:
   • im Allgemeinen offene Software als sicherer angesehen wird,
   • sich nicht an einen Anbieter gebunden wird,
   • durch den offenliegenden Quellcode leichter Anpassungen vorgenommen werden können und
   • nachvollziehbar ist wie die Software arbeitet (no „black box“).

2. Der Store sollte in einer bekannten Programmiersprache geschrieben sein bzw. es sollte die Möglichkeit vorhanden sein, den Store über PlugIns oder ähnliches an zukünftige Erfordernisse anzupassen.
3. Verarbeitung von Tripeln in der Turtle-Syntax, da in IBR als zu benutzender Standard festgelegt.
4. SPARQL-Support, um effizient auf den Datenbestand abfragen zu können.
5. REST-Funktionalität/Schnittstelle, da die unterschiedlichen Komponenten im IBR Projekt über REST miteinander kommunizieren sollen.
6. Aktive Weiterentwicklung des Produktes und daraus folgend die Zukunftssicherheit.
7. Der Installationsaufwand sollte in einem vertretbarem Rahmen liegen.
8. Als optionale Anforderung gilt eine Konfigurations- bzw. Administrationsoberfläche, um eine komfortablere Interaktion mit dem Store zu ermöglichen.

Kandidaten

‹99› Im Folgenden werden drei ausgesuchte und getestete Kandidaten ausführlich vorgestellt. Zunächst wird am Anfang des jeweiligen Kapitels auf die Erfüllung der oben definierten Kriterien eingegangen, anschließend anhand von Quelltextbeispielen die Interaktion mit dem jeweiligen Store gezeigt. Bei einer gegebenenfalls vorhanden Administrationsoberfläche soll diese ebenfalls beschrieben werden.

Semsol ARC2

‹100› „Semsol ARC2“⁸⁵⁾ (ARC2) stellt eine PHP-Bibliothek zur Verfügung, um mit RDF zu arbeiten. Es beinhaltet außerdem einen MySQL-basierten Tripel Store mit SPARQL-Support. ARC2 ist Open Source und freie Software. Es wird kein (Web-)Interface zur Verfügung gestellt. ARC2 kann über PlugIns erweitert werden und bietet Turtle- und SPARQL-Support. Eine REST-Schnittstelle ist leider nicht standardmäßig implementiert und müsste somit über ein Plugin selbst hinzugefügt werden. ARC2 wird nicht mehr aktiv weiterentwickelt.⁸⁶⁾

‹101› Der vollständige Quellcode kann direkt aus dem öffentlichen Git Repository github.com/semsol/arc2 bezogen werden. Eine „Installation“ im eigentlichen Sinne ist nicht notwendig. Die Bibliothek wird aus dem Internet heruntergeladen und in ein beliebiges Verzeichnis entpackt, auf das aus den die Bibliothek benutzenden PHP-Programmen zugegriffen werden kann. Des Weiteren benötigt man einen Webserver, welcher PHP interpretieren kann und den Zugriff auf eine MySQL Datenbank auf der ausführenden Maschine.

‹102› Um mit ARC2 zu arbeiten muss als Erstes die statische ARC2 Klasse eingebunden werden, dies geschieht mit:

1 <?php include_once("semsol-arc2/ARC2.php"); ?>

‹103› Für alle folgenden PHP Quelltextbeispiele gilt, dass sie innerhalb von <?php … ?> stehen. Jetzt kann der Store und die Datenbank bzw. der Datenbankzugriff konfiguriert (Zeilen 2 bis 11) und dann instanziiert werden (Zeile 12).

2 $config = array(
3 /* db */
4 'db_name' => 'arc2',
5 'db_user' => 'arc2',
6 'db_pwd' => 'arc2',
7 /* store */
8 'store_name' => 'arc_tests',
9 /* stop after 100 errors */
10 'max_errors' => 100,
11 );
12 $store = ARC2::getStore($config);

‹104› Nun steht in $store (siehe Zeile 12) die volle Funktionalität des Tripel Store zur Verfügung.

‹105› In Zeile 14 werden die benötigten Datenbanktabellen angelegt, sofern diese nicht schon vorhanden sind (Zeile 13).

13 if (!$store->isSetUp()) {
14 $store->setUp();
15 }

‹106› Zu Testzwecken wird der Store zurückgesetzt und somit geleert (Zeile 16),

16 $store->reset();

um anschließend Testdaten in der Turtle Syntax in den Store einzufügen. Dazu werden in Zeile 17 mehrere Tripel definiert und in Zeile 18 an den Store gesendet.

17 $q = 'INSERT INTO <http://triple.spatialhumanities.de/>
   { <http://example.org/Berlin> <http://example.org/ist>
   <http://example.org/Hauptstadt> . <http://example.org/Hauptstadt>
   <http://example.org/heisst> "Berlin" .}';
18 $returnValue = $store->query($q, 'raw', '', true);

‹107› In $returnValue steht in Falle des Löschens ein Array mit Werten für die Anzahl der gelöschten Datensätze ("t_count") und die zum Laden benötigte Zeit ("load_time"). Ein solches Array könnte folgendermaßen aussehen:

a) array(2) {
b) ["t_count"]=>
c) int(2)
d) ["load_time"]=>
e) float(0.0155)
f) }

‹108› Als nächstes soll eine SPARQL Abfrage an den Store gestellt werden, die alle gespeicherten Tripel zurückgibt. Dazu reicht es diese Abfrage zu definieren (Zeilen 19 bis 21) und dann die Anfrage an den Store zu senden (Zeile 22).

19 $q = '
20 	SELECT * WHERE { ?subject ?predicate ?object}
21 ';
22 if ($rows = $store->query($q, 'rows')) {
23 foreach ($rows as $row) {
24 	$r .= '<li>' . $row['subject'] ."\t". $row['predicate'] ."\t". 
   $row['object'] . '<li>';
25 	//...
26  }
27 }

‹109› In $rows (siehe Zeile 22) steht das Ergebnis der SPARQL-Abfrage in Form eines zweidimensionalen Arrays zur Verfügung und kann entsprechend weiterverarbeitet werden (Zeile 23 bis 26). Der erste Dimension des Ergebnisarrays ist numerisch und entspricht der von 0 beginnenden, fortlaufenden Nummer der gefundenen Datensätze. Die zweite Dimension enthält dann jeweils die in der SPARQL Abfrage definierten Abfragevariablen ('subject') und zusätzlich die dazugehörigen Typisierungen ('subject type') als Schüssel. Ein solches Ergebnisarray könnte (ausschnittsweise) folgendermaßen aussehen:

a) [0]=>
b) array(6) {
c) ["subject"]=>
d) string(29) "http://example.org/Hauptstadt"
e) ["subject type"]=>
f) string(3) "uri"
g) ["predicate"]=>
h) string(25) "http://example.org/heisst"
i) ["predicate type"]=>
j) string(3) "uri"
k) ["object"]=>
l) string(6) "Berlin"
m) ["object type"]=>
n) string(7) "literal"
o) }

‹110› Der zweite Parameter der query()-Methode (Zeile 22) ist optional und spezifiziert das Rückgabeformat genauer. Im obigen Fall besteht nur Interesse an den Ergebnissen und nicht zum Beispiel an der Ausführungszeit der Abfrage. Um Daten aus dem Store wieder zu löschen, wird analog zum Einfügen von Daten (siehe Zeile 17 und 18) vorgegangen.

28 $q = 'DELETE FROM <http://triple.spatialhumanities.de/>
   { <http://example.org/Berlin> <http://example.org/ist>
   <http://example.org/Hauptstadt> . }';
29 $returnValue = $store->query($q, 'raw', '', true);

‹111› In Zeile 28 ist spezifiziert, was gelöscht werden soll und in Zeile 29 wird die Anfrage an den Store gesendet. $returnValue enthält danach ein ähnlich dem INSERT INTO (siehe Zeile 17) aufgebautes Rückgabearray, hier allerdings mit den Arrayschlüsseln ["t_count"], ["delete_time"] und ["index_update_time"].

‹112› Als weiteres Feature bietet ARC2 einen allgemeinen und mehrere formatspezifische⁸⁷⁾ RDF-Parser an. Der allgemeine Parser wird instanziiert mit:

30 $parser = ARC2::getRDFParser();

‹113› ARC2 hat eine eingebaute RDF-Formaterkennung, somit reicht der allgemeine Parser in den meisten Fällen und ist auch entsprechend vielseitiger einsetzbar.

31 $base = '';
32 $data = '<http://example.org/Hauptstadt> <http://example.org/heisst>
   "Berlin" .';
33 $parser->parse($base, $data);

‹114› In den Zeilen 31 und 32 werden die benötigten Variablen gesetzt. $base könnte für sogenannte „named graphs“ benutzt werden. Hier wird der Standard Graph benutzt. $data enthält ein Tripel in der Turtle Syntax. In Zeile 33 erfolgt das eigentliche Parsen der Daten. Es ist hier auch möglich, URLs zu RDF-Dokumenten⁸⁸⁾ oder lokal gespeicherte RDF-Dateien⁸⁹⁾ zu verwenden. Um nun für eine einfache Weiterverarbeitung ein flaches Array mit den Tripeln zu bekommen, gehen wir wie in Zeile 34 vor.

34 $triples = $parser->getTriples();

‹115› Nun kann man die Tripels zum Beispiel ausgeben (Zeilen 35 bis 41):

35 for ($i = 0, $i_max = count($triples); $i < $i_max; $i++) {
36 	$triple = $triples[$i];
37 	foreach($triple as $key => $value){
38 		echo $key.': '.$value.'<br />';
39 		echo "\n";
40 	}
41 }

‹116› Der Parser bietet die Möglichkeit, dass so erstellte Tripelarray in die bekannten RDF-Formate umzuwandeln, beispielhaft für Turtle und JSON in den Zeilen 42 und 43 dargestellt.

42 $turtle_doc = $parser->toTurtle($triples);
43 $json_doc = $parser->toRDFJSON($triples);

‹117› Die jeweilige Variable kann man dann zum Beispiel mit echo(); ausgeben. Für JSON sieht die Ausgabe dann folgendermaßen aus:

44 JSON:
45 {
46   "http://example.org/Hauptstadt" : {
47     "http://example.org/heisst" : [
48       { "value" : "Berlin", "type" : "literal" }
49     ]
50   }
51 }

‹118› ARC2 bietet darüber hinaus noch diverse andere Funktionen, aber dies soll als Test genügen. Für weitergehende Informationen sei an dieser Stelle auf die ARC2 Wiki⁹⁰⁾ verwiesen. Der vollständige Quellcode des Beispiels wird auf Anfrage gerne zur Verfügung gestellt.

Sesame

‹119› „OpenRDF Sesame“⁹¹⁾ (Sesame) ist ein Open Source Java Framework um RDF-Daten zu speichern und abzufragen.⁹²⁾ Sesame ist plugin-fähig und bietet sowohl Turtle- als auch SPARQL-Support. Es verfügt über eine eingebaute REST-Schnittstelle und wird aktiv weiterentwickelt. Sesame bezeichnet sich selbst als De-facto-Standard für die Verarbeitung von RDF-Daten.⁹³⁾ Bei einer kurzen diesbezüglichen Webrecherche konnte die Behauptung im Allgemeinen nachvollzogen werden. Es gibt Installationen von Sesame unter anderem bei pharmazeutischen Betrieben, bei Verlagen, Museen und im öffentlichen Bereich.⁹⁴⁾ Auf der Mailinglist sesame-general⁹⁵⁾ werden pro Monat zwischen 50 und 140 Einträge gepostet. Diese Zahlen sind seit Anfang 2010 stabil.

‹120› Besonders positiv aufgefallen ist das Webinterface, welches eine zentrale Konfigurations-, Administrations- und Zugriffsmöglichkeit auf alle Daten des Stores und dessen Einstellungen bietet. Somit wird der Bedienkomfort erhöht und auch Usern die nicht systemnah ausgebildet sind, eine Möglichkeit zum Arbeiten mit diesem Store gegeben.

‹121› Als Kritikpunkt zeigt sich bei Sesame allerdings, dass es auf Java aufsetzt bzw. in Java geschrieben ist. Dies sollte vor einem Einsatz gründlich überdacht werden, da immer wieder schwerwiegende Java-Sicherheitslücken bekannt werden, deren Beseitigung durch den Hersteller oftmals lange Zeit in Anspruch nimmt.⁹⁶⁾ Der Quellcode kann direkt aus dem öffentlichen Git Repository https://bitbucket.org/openrdf/sesame/src⁹⁷⁾ bezogen werden.

‹122› Sesame ist in zwei Module aufgeteilt. Zum einen die sogenannte (openrdf-) Workbench, welche das zentrale Konfigurations- und Administrationsinterface als Webanwendung zur Verfügung stellt. Zum anderen (openrdf-) Sesame, das über die vorhandene REST-Schnittstelle die Inhalte des Tripel Stores nach außen zur Verfügung stellt. Über diese Schnittstelle können zum einen SPARQL Anfragen an das System gestellt werden, zum anderen über vordefinierte URL-Segmente die zum Beispiel im Store vorhandenen Repositories oder deren Größe (Anzahl der enthaltenen Tripel) ausgegeben werden. Die Installation gestaltet sich etwas schwieriger als bei ARC2, da zusätzlich ein Java Web Application Deploymenttool benötigt wird. Die Wahl fiel auf den Apache Tomcat⁹⁸⁾ – eine in diesem Bereich weit verbreitete Software. Der Apache-Webserver wird im Projekt ohnehin schon eingesetzt. Die beiden Sesame Module – workbench und sesame – können als Dateien vom Typ .war von einer⁹⁹⁾ der Websites des dänischen Herstellers Aduna¹⁰⁰⁾ heruntergeladen werden. Nach dem umfangreichen Setup und der entsprechenden Konfiguration von Tomcat konnten die WAR-Dateien über das grafische Tomcat Backend einfach und schnell zur Anwendung gebracht werden. Von diesem Punkt an steht die volle Funktionalität von Sesame zur Verfügung.

Abbildung 11: IBR Repository in openrdf -Workbench

‹123› Die Arbeit mit der Sesameoberfläche gestaltete sich nicht schwer. Nach dem Aufruf der Workbench ohne weitere URL-Segemente wird als Erstes auf die Übersicht aller im Store vorhandenen Repositories weitergeleitet. Dort können Repositories ausgewählt, gelöscht oder neu angelegt werden. Bei Auswahl eines vorhandenen Repositories erfolgt eine Übersichtsanzeige ähnlich Abb. 11. Die Übersicht bietet Funktionen, um mit den Daten des ausgewählten Repositories weiter zu arbeiten. Im linken Menü stehen daneben die Punkte Explore und Modify zur Verfügung. Der Menüpunkt System bietet Informationen zur Applikation selbst (bspw. die Versionsnummer), zur Laufzeitumgebung (OS Version, Java Version etc.) und zur Speichernutzung.

‹124› Unter dem Punkt Explore lassen sich acht verschiedene Unterpunkte mit folgenden Funktionen auswählen:

• Summary gibt eine kurze Zusammenfassung zum Repository, siehe auch Abb. 11.
• Namespaces: Hier können die vorhandenen Namensräume angezeigt, verändert oder gelöscht werden. Neue Namensräume hinzuzufügen ist ebenfalls möglich.
• Contexts: Kontexte können zum Gruppieren von Statements unter einem gemeinsamen Gruppenindentifikator benutzt werden. Für weitere Informationen zu Kontexten bei Sesame sei an dieser Stelle auf die Dokumentation¹⁰⁰⁾ verwiesen.
• Types: Unter diesem Punkt sind alle im Store vorhandenen Typisierungen zu finden.
• Explore: Nach Eingabe einer Ressource oder eines Prädikates können hier alle Vorkommnisse der jeweiligen Ressource bzw. des entsprechenden Prädikates tabellarisch angezeigt werden. URIs können dabei sowohl vollständig als auch mit Namensräumen abgekürzt angegeben werden. Eine nicht korrekte Eingabe resultiert konsequenterweise in eine leere Ergebnistabelle.
• Query: Unter diesem Punkt hat man die Möglichkeit direkt SPARQL-Abfragen an das Repository zu senden. Das Ergebnis wird auch hier tabellarisch dargestellt. Abfragen können für spätere Verwendung auch gespeichert werden.
• Saved Queries: Eine Übersicht über alle bisher gespeicherten Abfragen mit der Möglichkeit diese auszuführen, anzuzeigen, zu editieren oder zu löschen.
• Export: Sesame stellt unter diesem Punkt die Möglichkeit zum Export des gesamten Datenbestandes des aktuellen Repositories zur Verfügung. Nach Auswahl des gewünschten Formates – es stehen hier neun verschieden Formate zur Auswahl, unter anderem RDF/XML, RDF/JSON und Turtle – , genügt ein Klick auf Download und es wird automatisch ein entsprechender Dump generiert und zum Download angeboten.

‹125› Unter dem Punkt Modify stehen vier weitere Unterpunkte mit folgenden Funktionen zur Verfügung:

• SPARQL Update: Dieser Punkt erlaubt SPARQL Update¹⁰¹⁾ zu nutzen. Damit können sogennante „named Graphs“ aktualisiert werden. Sesame stellt einen default graph zur Verfügung. Alle weiteren Graphen müssen eigenständig benannt werden.
• Add: Hier können Daten hinzugefügt werden. Einerseits besteht die Möglichkeit eine URL einzugeben, welche die einzufügenden RDF-Daten bereitstellt. Andererseits kann man ein lokal vorhandenes RDF-File in das Repository hochladen. Ein Textfeld für die manuelle Eingabe von RDF-Daten steht ebenfalls zur Verfügung. Des Weiteren kann eine base URI und ein Kontext eingegeben sowie das Datenformat¹⁰²⁾ ausgewählt werden.
• Remove: Hier lassen sich einzelne oder mehre Statements entfernen. Dazu steht jeweils ein Feld für Subjekt, Prädikat und Objekt¹⁰³⁾ zur Verfügung. Hierbei muss mindestens eines der vorhandenen Felder ausgefüllt werden. Die Anderen sind optional. Es werden alle Statements gelöscht, welche die eingegebenen Kriterien erfüllen.
• Clear: Löscht sämtliche Statements des ausgewählten Repositories.

‹126› Die REST-Schnittstelle von Sesame zu nutzen, gestaltet sich nicht schwierig. Die folgenden PHP-Beispiele – unter Benutzung der cURL-Bibliothek¹⁰⁴⁾ – veranschaulichen dies: Als Erstes wird eine der Methoden (size) benutzt, die Sesame als Ressourcen zur Verfügung stellt. Diese gibt die Anzahl der Datensätze des angefragten Repositories zurück.¹⁰⁵⁾

1 $url = "http://localhost:8080/openrdf-sesame/repositories/ibrdemo/size"; 
2 $ch = curl_init(); 
3 
4 curl_setopt($ch, CURLOPT_URL, $url); 
5 curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); 
6 curl_setopt($ch, CURLOPT_HTTPGET, true); 
7 
8 $response = curl_exec($ch); 
9 
10 curl_close($ch);

‹127› In Zeile 1 wird die abzufragenden URL gesetzt und in Zeile 2 wird cURL initialisiert. In den Zeilen 4-6 werden die Optionen von cURL gesetzt; wichtig ist hier Zeile 6 in der explizit die HTTP Request Methode auf GET gesetzt wird. In Zeile 8 wird die Abfrage ausgeführt und in Zeile 10 die Verbindung geschlossen. In der Variable $response steht das Ergebnis zur weiteren Verarbeitung zur Verfügung.

‹128› Im folgenden zweiten Beispiel wollen wir nun alle Datensätze aus dem Repository abfragen.

11 $url = "http://localhost:8080/openrdf-sesame/repositories/ibrdemo/statements"; 
12 $headers = array( "Accept: application/xml" ); 
13 $ch = curl_init(); 
14 
15 curl_setopt($ch, CURLOPT_URL, $url); 
16 curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); 
17 curl_setopt($ch, CURLOPT_HTTPGET, true); 
18 curl_setopt($ch, CURLOPT_HEADER, ture); 
19 curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); 
20 
21 $response = curl_exec($ch); 
22 
23 curl_close($ch);

‹129› Ähnlich dem Ablauf im ersten Beispiel wird hier die anzufragende URL definiert (Zeile 11), cURL initialisiert (Zeile 12), die gewünschten Optionen gesetzt (Zeilen 15-19), die Abfrage ausgeführt (Zeile 21) und die Verbindung geschlossen (Zeile 23). Wichtig in diesem Beispiel ist der sogenannte Accept Header. Über diesen wird bei REST-Abfragen das Rückgabeformat gesetzt. In den Zeilen 12 und 19 legen wir fest, dass wir XML zurückgegeben haben möchten. In der Variable $response steht wie gewohnt das Ergebnis (als XML) zur weiteren Verarbeitung zur Verfügung.

‹130› Als nächstes sollen nun einige Datensätze zum Repository hinzugefügt werden (POST).

24 $url = "http://localhost:8080/openrdf-sesame/repositories/ibrdemo/statements"; 
25 $postData = "<http://store.spatialhumanities.de/rest/featA38>
    <http://triple.spatialhumanities.de/vocabulary/locates>
    <http://www.inschriften.net/hildesheim/inschrift/nr/DI58-0012> .
26 <http://annotation.spatialhumanities.de/rest/annoZ42>
    <http://triple.spatialhumanities.de/vocabulary/belongsto>
    <http://www.inschriften.net/hildesheim/inschrift/nr/DI58-0012> .";
27 $headers = array('Content-type: application/x-turtle;charset=UTF-8'); 
28 $ch = curl_init(); 
29 
30 curl_setopt($ch,CURLOPT_URL, $url); 
31 curl_setopt($ch,CURLOPT_POST, 1); 
32 curl_setopt($ch,CURLOPT_POSTFIELDS, $postData); 
33 curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); 
34 
35 $response = curl_exec($ch); 
36 $headerInfo = curl_getinfo($ch, CURLINFO_HTTP_CODE); 
37 
38 curl_close($ch); 
39 
40 //HTTP Status 204 means no Content, which is what we want 
41 if ($headerInfo == 204){ 
42 	echo ('POST ok'); 
43 }else{ 
44 	//Fehlerbehandlung 
45 }

‹131› Das gezeigte Beispiel ist ähnlich wie die anderen aufgebaut. Die zentralen Punkte sind hier zum einen, dass wir natürlich die Daten benötigen, die wir senden wollen (Zeile 25 und 26), zum anderen müssen wir hier wieder einen entsprechenden Header setzen, damit das System weiß, welcher Art die Daten sind, die wir ihm senden. Dies geschieht in Zeile 27 mit dem Setzen des entsprechenden Content-types.¹⁰⁶⁾ In diesem Beispiel senden wir Daten im Turtle Format. Für weitere mögliche Content-types, die Sesame akzeptiert, sei hier auf die entsprechende Tabelle im Anhang 1 verwiesen. Wenn man hier einen falschen oder gar keinen Content-type angibt, antwortet das System mit dem HTTP Status Code 415 (Unsupported Media Type). In den Zeilen 30–33 werden die benötigten (POST-) Optionen gesetzt, danach die Abfrage gesendet (Zeile 35) und in Zeile 36 noch die Response Header-Informationen zur späteren Auswertung geholt. Im Falle von POST wollen wir hier nicht den HTTP Status Code 200 sondern 204 – was „no Content“ bedeutet – zurückgegeben bekommen, da wir hier keinen Inhalt zurück erwarten. 204 bedeutet in diesem Fall, dass der Request erfolgreich war.

‹132› Im letzten Beispiel soll noch gezeigt werden, wie SPARQL benutzt werden kann, um mit Sesame zu interagieren.

46 $server = "http://localhost:8080"; 
47 $queryBaseUrl = "/openrdf-sesame/repositories/ibrdemo?query="; 
48 $query = "SELECT * WHERE {?subject ?predicate ?object}"; 
49 //urlencoding queryString 
50 $urlencodedQuery = urlencode($query); 
51 $headers = array( "Accept: application/sparql-results+xml" ); 
52 
53 $ch = curl_init(); 
54 
55 curl_setopt($ch, CURLOPT_URL, $server.$queryBaseUrl.$urlencodedQuery); 
56 curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); 
57 curl_setopt($ch, CURLOPT_HTTPGET, true); 
58 curl_setopt($ch, CURLOPT_HEADER, ture); 
59 curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); 
60 
61 $response = curl_exec($ch); 
62 
63 curl_close($ch);

‹133› Ähnlich wie in den vorhergehenden Beispielen, werden zuerst die entsprechenden Variablen gefüllt (Zeilen 46 bis 51), dann cURL initialisiert (Zeile 53), die benötigten Optionen gesetzt (Zeilen 55 bis 59), danach die Abfrage ausgeführt (Zeile 61) und dann die Verbindung beendet (Zeile 63). Das Ergebnis steht wie gewohnt in der Variable $response zur weiteren Benutzung/Verarbeitung zur Verfügung.

‹134› Im Vergleich zu den anderen Beispielen hat sich hier Folgendes geändert: Zum einen muss hier ein anderer Accept Header¹⁰⁷⁾ mit dem Typ "Accept: application/sparql-results+xml" gesetzt (Zeile 51) und zum anderen muss der Query String url-kodiert (urlencode()¹⁰⁸⁾) werden (Zeile 50). Da Query-Strings unter anderem Leerzeichen beinhalten und teilweise auch Zeichen enthalten können, die keine Repräsentation im ASCII-Standard besitzen und somit nicht in URLs zulässig sind,¹⁰⁹⁾ muss der Query-String entsprechend kodiert werden. Auch Sesame kann weit mehr leisten als hier vorgestellt, für weiterführende Informationen sei an dieser Stelle auf die Online Dokumentation¹¹⁰⁾ verwiesen. Der vollständige Quellcode des Beispiels und die Ausgabe werden auf Anfrage gerne zur Verfügung gestellt.

Redland

‹135› Die „Redland RDF Libraries“¹¹¹⁾ sind eine Sammlung von Bibliotheken für verschiedene Teilbereiche der Arbeit mit RDF und durch die Programmierung in C besonders systemnah. Die verschiedenen Bibliotheken sind freie Software und Open Source. Als Erste ist hier die „Raptor RDF Syntax Library“¹¹²⁾ (Raptor) zu nennen. Raptor stellt Parsing- und Serialisierungsfunktionalität für verschiedene RDF Formate zur Verfügung und beherrscht alle gängigen RDF Formate, unter anderem auch die Turtle-Syntax. Die zweite Bibliothek ist die „Rasqal RDF Query Library“¹¹³⁾ (Rasqal). Rasqal stellt Abfragefunktionalitäten zur Verfügung und beherrscht SPARQL. Als dritte Komponente ist die „Redland RDF Library“ (Redland) zu nennen. Sie stellt die API und den Tripel Store zur Verfügung und benötigt Raptor und Rasqal. Als optionale Komponente lässt sich noch die „Redland librdf Language Bindings“¹¹⁴⁾ (Language Bindings) einbinden. Damit werden APIs für Perl, PHP, Python und Ruby bereitgestellt, außerdem auch eine experimentelle API für LUA.¹¹⁵⁾ Durch die genannten APIs ist die Software deutlich breiter einsetzbar, wird doch oft die Programmierung in C als große Einstiegshürde empfunden. Redland bietet keine REST-Schnittstelle und keine Oberfläche an. Durch den offenen und freien Quellcode ist es auch bei Redland möglich, das Produkt zu erweitern. Der Quellcode kann direkt von der Website¹¹⁶⁾ heruntergeladen oder aus dem öffentlichen Git Repository¹¹⁷⁾ bezogen werden, in dem auch die aktive Weiterentwicklung gut nachzuvollziehen ist. Die letzten Release Versionen sind von Anfang des Jahres 2013.

‹136› Die Arbeit mit Redland gestaltete sich anfangs schwierig. Die Dokumentation zu PHP umfasst zwei Zeilen und ein offizielles Beispiel existiert nicht.¹¹⁸⁾ Als Erstes wird hier die Klassenbibliothek eingebunden (Zeile 1).

1 require_once('LibRDF/LibRDF.php');
2 $store = new LibRDF_Storage($world, "mysql", $storageName = "db1", $options = "new='yes',host='127.0.0.1',database='redland',user='redland','password='redland'");
3 $model = new LibRDF_Model($store);

‹137› Danach werden ein Store (welcher alle Models beinhaltet) und ein Model instanziiert (Zeile 2 und 3). Wenn man in Zeile 2 new LibRDF_Storage()keine Argumente mitgibt, wird ein sogenannter In-Memory-Store im Arbeitsspeicher angelegt. Dieser ist allerdings nicht persistent. Deshalb wurde an dieser Stelle auf eine MySQL Datenbank zurückgegriffen.

4 $statements = "@prefix hild:	<http://www.inschriften.net/data/di058/articles/> . 
 @prefix pred:	<http://ontology.spatialhumanities.de/predicates/> . 
 @prefix spat:	<http://store.spatialhumanities.de/rest/> . 
 @prefix anno:	<http://annotation.spatialhumanities.de/rest/> .
  
 spat:featA38	pred:locates	hild:DI58-0012 .
 anno:annoZ42	pred:belongsto	hild:DI58-0012 .";

‹138› In Zeile 4 definieren wir einen String welcher einige Präfixdefinitionen und zwei Tripel enthält.

5 $model->loadStatementsFromString(new LibRDF_Parser('turtle'), $statements); 
6 //load more statements in RDF/XML Format from local uri 
7 $model->loadStatementsFromURI(	new LibRDF_Parser('rdfxml'),'http://localhost/bachelorarbeit/beispieltripel/RDF-XML-Inschrift_klassifizieren.xml');

‹139› In Zeile 5 wird der String aus Zeile 4 dem Model hinzufügt. Wichtig hierbei ist, dass das RDF-Format für den Parser explizit angegebenen werden muss. In Zeile 7 wird ein RDF/XML File von einer (lokalen) URI geladen. Der Inhalt dieser Datei findet sich im Anhang 2. Hierbei ist es wieder wichtig, das entsprechende Format anzugeben. Nachdem wir nun Testdaten in dem Model haben, können Abfragen darauf gestellt werden. Wir benutzen wie auch in den anderen Beispielen eine SPARQL-Abfrage. Im vorliegenden Fall sollen alle vorhandenen Tripel abgefragt werden. Der Abfragestring dazu wird in Zeile 8 definiert, der Query in Zeile 9 ausgeführt.

8 $query = new LibRDF_Query("SELECT * WHERE {?subject ?predicate ?object}", NULL, 'sparql'); 
9 $results = $query->execute($model);

‹140› In $results steht das Ergebnis der Abfrage zur weiteren Verarbeitung zur Verfügung. Die Variablennamen, die wir im SPARQL-Query benutzt haben, stehen als Arrayschlüssel in den einzelnen Ergebnissen zur Verfügung (siehe Zeile 11). Eine Ausgaberoutine dafür könnte so aussehen:

10 foreach ($results as $result) { 
11 	echo htmlspecialchars($result['subject'].' '.	$result['predicate'].' '.$result['object']); 
12 	echo" <br />\n"; 
13 }

‹141› Zum Entfernen von Datensätzen geht man folgendermaßen vor:¹¹⁹⁾

14 $sub = 'http://store.spatialhumanities.de/rest/featA38'; 
15 $pred = 'http://ontology.spatialhumanities.de/predicates/locates'; 
16 $obj =  'http://www.inschriften.net/data/di058/articles/di058-0012'; 
17 $statementToRemove = new LibRDF_Statement( 
18 	new LibRDF_URINode($sub), 
19 	new LibRDF_URINode($pred),
20 	new LibRDF_URINode($obj) 
21 ); 
22 $model->removeStatement($statementToRemove);

‹142› In den Zeilen 17 bis 21 erzeugen wir ein Statement aus URI Nodes, welches wir aus dem Model entfernen möchten. In Zeile 22 wird das Entfernen des Statements ausgeführt. Als abschließende Demonstration sei hier noch das Serialisieren in verschiedene Formate vorgestellt.

23 //Statements in Model to XML
24 $statementsXML = $model->serializeStatements(new LibRDF_Serializer('rdfxml'));
25
26 //Statements in Model to Turtle
27 $statementsTurtle = $model->serializeStatements(new LibRDF_Serializer('turtle'));
28 
29 //Statements in Model to JSON
30 $statementsJSON = $model->serializeStatements(new LibRDF_Serializer('json'));

‹143› Das Serialisieren in die verschieden Formate ist relativ einfach. Man ruft die Methode serializeStatements() des Models auf und übergibt dieser einen Serializer mit dem gewünschten Format. Beispielhaft für RDF/XML (Zeile 24), Turtle (Zeile 27) und JSON (Zeile 30). Die Rückgabe der jeweiligen Funktion enthält einen (vorformatierten) String im jeweiligen Format, welcher dann zum Beispiel zur Ausgabe auf einer Webseite oder zum Schreiben in eine Datei benutzt werden kann.

‹144› Dies schließt den Test von redland ab. Aber auch redland besitzt größeres Leistungspotential, für Weiteres sei an dieser Stelle auf die C API-Dokumentation verwiesen.¹²⁰⁾

Vergleich der drei Tripel Stores

‹145› Nach der ausführlichen Beschreibung der drei verschiedenen Tripel Stores soll nun eine Gegenüberstellung anhand der geforderten Kriterien erfolgen.

‹146› Sowohl ARC2 als auch Redland bieten von Hause aus leider keine REST-Schnittstelle an und eine Oberfläche fehlt ebenfalls. ARC2 wird nicht mehr aktiv weiterentwickelt und ist somit nicht zukunftsfähig. Bei Redland fällt der sehr hohe Installationsaufwand negativ auf. Sesame erfüllt als einziger der getesteten Kandidaten alle der geforderten Kriterien und der Installationsaufwand ist vertretbar. Des Weiteren greift Pundit¹²¹⁾ zur Speicherung seiner RDF-Tripel ebenfalls auf Sesame zurück. Dies ist ein weiter Pluspunkt für Sesame im Rahmen des IBR-Projektes, da Aufwand gespart werden kann, wenn nicht zwei verschiedene Tripel Stores im Projekt eingesetzt werden und Sesame die obigen Voraussetzungen erfüllt. Da Sesame hinsichtlich der Anfoderungskriterien am besten abgeschnitten hat, fällt die Auswahl auf diese Implementierung eines Tripel Stores.

Aufgetretene Probleme

‹147› ARC2 erfordert für den ungeübten Anwender eine hohe Einarbeitungszeit, da die Dokumentation stellenweise recht knapp gehalten ist. Des Weiteren gilt die Software als stabil und es sind keine weiteren Änderungen bzw. Erweiterungen an der Funktionalität geplant. ARC2 wird somit nicht aktiv weiterentwickelt, obwohl eventuell auftretende Probleme/Bugs noch behoben werden sollen. Somit ist die Zukunftsfähigkeit des Systems, gerade im Hinblick auf das regelmäßige Erscheinen neuer PHP Versionen und den damit verbundenen, möglichen Konsequenzen für die Lauffähigkeit der PHP Software, nicht hundertprozentig gewährleistet.

‹148› Die Installation des Redland Gesamtpakets unter Xubuntu war äußerst kompliziert. Die Bibliotheken der verschiedenen Teile von Redland bzw. die Voraussetzungen dazu (die Raptor RDF Syntax Library, die Rasqal RDF Query Library, die Redland RDF API und die Redland librdf Language Bindings) werden teilweise in den Repositories von Ubuntu angeboten. Doch die Installation daraus schlug fehl, weil die bereitgestellten Versionen der Bibliotheken untereinander nicht kompatibel waren. Die Versionsinkompatibilitäten konnten erst nach einer längeren Internetrecherche herausgefunden werden. Es war außerdem nicht möglich, eine Übersicht der untereinander kompatiblen Versionen von Redland zu finden. Daraufhin wurden alle Bibliotheken vom System entfernt und der jeweilige und aktuellste Quellcode der einzelnen Bibliotheken – der auf der Website¹²²⁾ zur Verfügung stand – heruntergeladen und neu kompiliert. Hierbei war es allerdings wichtig, die Reihenfolge bzw. die Abhängigkeiten der Bibliotheken untereinander zu beachten. Weiterhin wurden alle kompilierten Bibliotheken im Verzeichnis /usr/local/lib abgelegt und konnten somit standardmäßig nicht gefunden werden. Hierbei war wiederholt eine eigenhändige Anpassung nötig. Nach diesen Anpassungen funktionierten die mitgelieferten (und in C geschriebenen) Beispiele allerdings tadellos. Die Dokumentation zur Arbeit mit dem PHP Interface von Redland ist unzureichend.¹²³⁾ Der entscheidende Hinweis, dass für eine Nutzung noch weitere Software aus dem Ubuntu Repository und ein PHP Pear Packet notwendig waren, konnte jedoch inklusive PHP-Beispiel¹²⁴⁾ gefunden werden. Festgestellt wurde weiterhin, dass die PHP-API nicht alle Methoden von redland zur Verfügung stellt. Als Beispiel dafür sei die Methode librdf_query_results_to_string2()¹²⁵⁾ angeführt, welche dazu dient Abfrageergebnisse für eine Ausgabe bzw. zum Ausspielen syntaktisch (Turtle, RDF/XML, ...) aufzubereiten.

Related Works

‹149› In diesem Kapitel möchte ich einerseits auf Tools aus dem Bereich der semantischen Annotation von Webressourcen und andererseits auf Projekte, welche ähnliche Fragestellungen wie IBR bearbeiten, verweisen. Dazu werden diese, abgesehen von Pundit welches im Rahmen von IBR schon einer ersten Evaluation unterzogen wurde, kurz vorgestellt, und auf weiterführende Informationen dazu verwiesen.

‹150› Pundit¹²⁶⁾ ist ein Tool zur semantischen Annotation von Webressourcen. Da im Fall von IBR alle gegebenenfalls zu annotierenden Ressourcen (die einzelnen DIO Inschriftendatensätze) einzeln im Web erreichbar und abrufbar sind und auf sie jeweils per URI eindeutig zugegriffen werden kann, könnte Pundit benutzen werden, um diese zu annotieren. Diese Annotationen werden nach dem „W3C Open Annotation Standard“¹²⁷⁾ durchgeführt bzw. erstellt. Pundit wird von der italienischen Firma net7¹²⁸⁾ entwickelt und ist außerdem einer der beiden Finalisten zum „LODLAM SUMMIT 2013“.¹²⁹⁾ Es ist Open Source, befindet sich allerdings noch in der Entwicklungsphase und die benötigte Serverkomponente steht noch nicht für den Download und somit für die unabhängige und eigene Verwendung zu Verfügung. Der Download des Testclients funktioniert auch bei mehrmaligen Versuchen noch nicht. Man erhält zurzeit immer einen Zugriffsfehler. Es existiert natürlich die Möglichkeit das öffentliche Github Repository¹³⁰⁾ zu benutzen. Hier besteht das Problem, dass man dabei auf eine Entwicklungs- und keine stabile Version zugreift und somit die Wahrscheinlichkeit von Fehlern entsprechend höher ist. Für einen Produktiveinsatz ist eine Entwicklungsversion entsprechend nicht zu empfehlen. Was allerdings gut funktioniert ist das sogenannte Pundit Bookmarklet.¹³¹⁾ Eine Videodemonstration in der die Leistungsfähigkeit des Bookmarklets gezeigt wird, kann direkt auf der Website¹³²⁾ angesehen werden. Man kann mit dem Bookmarklet auf jeder Webseite eigene Annotationen hinzufügen. Dafür wird lediglich eine Open-ID¹³³⁾ benötigt, welche man sich kostenfrei bei vielen Internetgrößen erstellen kann oder gegebenenfalls sogar schon besitzt. Beispielsweise sind Accounts von Google, YAHOO! oder flickr Open-IDs. Für eine ausführlichere aber sicherlich unvollständige Liste von Open-ID Providern siehe http://openid.net/get-an-openid/. Pundit basiert auf RDF und benutzt für die derzeitige öffentliche Demo- und Testinstallation serverseitig¹³⁴⁾ Sesame als Tripel Store.

‹151› SALSAH¹³⁵⁾ ist eine in PHP geschriebene „virtuelle Forschungsumgebung (VRE) und ein in seiner Entwicklung schon weit fortgeschrittenes Annotationstool für digitale Faksimiles. In naher Zukunft sollen weitere Medien (Ton, Text, …) hinzukommen.“¹³⁶⁾ SALSAH wurde vom an der Universität Basel ansäßigen „digital humanities Lab“ entwickelt und wird aktuell im Rahmen einer Forschungsförderung weiterentwickelt.

‹152› Loomp¹³⁷⁾ ist ein semantisches Annotationstool für Webressourcen, welches an der „Freien Universität Berlin“¹³⁸⁾ (FU Berlin) zurzeit aktiv entwickelt wird. Die Zielgruppe des Tools ist eine breitere Öffentlichkeit und nicht nur speziell versierte Nutzer. Dabei baut Loomp auf RDF auf und setzt zu dessen Speicherung im Hintergrund einen Tripel Store ein. Es unterstützt dadurch das sogenannte Semantic Content Authoring, also die Entwicklung semantischen Inhaltes.

‹153› Sowohl SALSAH als auch Loomp werden im Rahmen von IBR in naher Zukunft als weitere Tools zur semantischen Annotation getestet werden und danach in der Leistungsfähigkeit dem momentan in der IBR-Testphase befindlichen Pundit gegenübergestellt.

‹154› Zwei Projekte, die an ähnlichen Fragestellungen arbeiten wie das IBR, sind zum einen „Maya Arch 3D“¹³⁹⁾ (Maya) und zum anderen „Relationen im Raum“¹⁴⁰⁾ (RiR). Beides sind DH- Projekte und werden aktuell vom BMBF auf drei Jahre gefördert.

‹156› Maya hat unter anderem das Ziel, „eine geo-referenzierte Datenbank über eine archäologische Stätte in Honduras, mit darin enthaltenen hoch detaillierten Informationen […] über Inschriften“ zu erstellen und ein „[...] Abfrage- und Analysetool für archäologische Fragestellungen wie die Analyse von […] räumlichen und zeitlichen Ausrichtungen von […] Inschriften.“¹⁴¹⁾ zu erstellen.

‹157› RiR hat als Ziel, „die Analyse und die Visualisierung räumlicher Relationen zwischen Grabmalen jüdischer Friedhöfe [...] mit dem Fokus auf dem Einzelobjekt“. Wobei hier geisteswissenschaftliche Fragestellung wie „Wie verhält sich das Einzelobjekt zum lokalen, räumlichen Ensemble der Einzelobjekte und dem weiteren Umfeld; im Bezug auf Familien / Abkunft / Gender / Funktionen / … oder Belegung in zeitlicher Perspektive – Datierung [...]“ geklärt werden sollen.¹⁴²⁾

‹158› Zusammenfassend kann gesagt werden, dass einerseits der Bereich der (semantischen) Annotation von Webressourcen und andererseits die Beschreibung von räumlichen Relationen geisteswissenschaftlicher Forschungsobjekte Gegenstand aktueller Forschung ist und schon jetzt benutzbare Demo- oder Testversion von entsprechenden Tools vorhanden sind.

Fazit und Ausblick

‹159› In diesem Beitrag konnte gezeigt werden, dass RDF dazu geeignet ist, geisteswissenschaftliche Forschungsobjekte und den sie umgebenden Raum in Beziehung zueinander zu setzen. Geisteswissenschaftliche Forschungsobjekte waren hierbei in Form textuell beschriebener Inschriftenträger und der Raumkontext in Form von anderen Inschriftenträgern, Raumpunkten oder -geometrien gegeben. Das dabei iterativ entwickelte Vokabular ermöglicht es grundlegende topologische und semantische Beziehungen auszudrücken. Dadurch können dem am Raumkontext der Inschriften interessierten Geisteswissenschaftler Möglichkeiten an die Hand gegeben werden, diesen Kontext genauer zu erforschen.

‹160› Des Weiteren konnte ein Tripel Store gefunden werden, der alle im Projekt aufgestellten Kriterien erfüllt. Durch diese Auswahl steht dem IBR Projekt eine grundlegende Softwarekomponente zu Verfügung.

‹161› Im Folgenden möchte ich noch einen kurzen Ausblick darauf geben, wie dieses Thema weiterbearbeitet werden kann bzw. welche anschließenden Möglichkeiten sich in den bearbeiteten Kontexten bieten. Erstens könnten weitere Iterationen zum Ausbau des RDF-Vokabulars durchgeführt werden. Zweitens bietet sich die Prüfung einer automatisierten Ableitung bzw. Herstellung von Beziehungen an. Drittens erscheint eine Diskussion der Möglichkeiten der Visualisierung der Raumbezüge vielversprechend.

‹162› Wie schon in Kapitel Geisteswissenschaftliches Prädikatenvokabular und zugehörige Klassifizierung erwähnt, war und ist die Erstellung eines solchen Vokabulars ein iterativer Prozess. Dieser kann und muss sicherlich noch einige Zeit fortgeführt werden, um ein noch besser geeignetes bzw. angepassteres Vokabular zu erreichen. Dieser Prozess benötigt allerdings weitere konkrete Fragestellungen aus dem geisteswissenschaftlichen Bereich, die sich mit dem Vokabular beantworten lassen sollen. Wenn diese vorhanden sind, wird sich die Qualität des Vokabulars in den folgenden Interationsstufen erheblich verbessern lassen.

‹163› Eine weitere Möglichkeit wäre, im Rahmen einer Folgestudie zu prüfen, inwieweit diese Beziehungen automatisiert hergestellt und abgeleitet werden können.

‹164› Auch das Gebiet der Visualisierungsmöglichkeiten für die in dieser Arbeit hergestellten, exemplarischen Beziehungen zwischen den Inschriften und den sie umgebenden Raum wäre ein interessantes Feld für weiterführende Forschungstätigkeiten.

‹165› Nicht unerwähnt bleiben dürfen die besonderen Ausgangsbedingungen des Forschungsvorhabens dieser Arbeit, konkret benannt, die Schnittstellenposition des Unterfangens zwischen Epigraphik und Informatik. Zu Beginn erwies es sich als schwierig, mit den im Projekt beteiligten Geisteswissenschaftlern fachlich zu kommunizieren ohne Missverständnisse zu produzieren. Am Anfang existierten teils sehr unterschiedliche Sicht- und Ausdrucksweisen, sodass ein gemeinsames Vokabular bzw. Begriffe erst genau definiert werden mussten. Zum Beispiel haben Objekte für einen Informatiker natürlich eine andere Bedeutung als für einen Geisteswissenschaftler. Im umgekehrten Fall hat der Begriff Raumkontext für den Geisteswissenschaftler eine weitreichendere Bedeutung als für den Informatiker. Als Beispiel hierzu sei erwähnt, das in einer der ersten Iterationsstufen eine händische Auszeichnung auf einem Ausdruck des DIO Artikels mit der Nummer 23¹⁴³⁾ der Stadt Mainz, teilweise Namen als Raumkontext ausgezeichnet wurden. Diese Namen bezeichneten nicht etwa auf der Inschrift genannte Personen, sondern solche von Wissenschaftlern, die über diese und andere Inschriften in der regionalen Umgebung des Aufstellungsortes Informationen zusammengetragen hatten.

‹166› Die Findung einer „gemeinsamen Sprache“ erscheint zunächst zeitaufwendig und mühsam für alle Beteiligten. Dennoch ist gerade durch diesen Prozess ein produktiver Austausch von Forschungskonzepten und -methoden zwischen beiden Fachrichtungen erst möglich. Insgesamt können auf diese Weise Ergebnisse erzielt werden, die einer Disziplin allein wahrscheinlich verschlossen geblieben wären.

Abbildungsverzeichnis

• Abbildung 1: erstes Graphbeispiel - no URIs
• Abbildung 2: RDF-Graphbeispiel - mit URIs
• Abbildung 3: RDF-Graphbeispiel - ungetyptes Literal
• Abbildung 4: RDF-Graphbeispiel - getyptes Literal
• Abbildung 5: RDF-Graph - Koordinaten lokalisieren Inschrift
• Abbildung 6: RDF - Graph mit identischem Subjekt und teils identischen Prädikaten
• Abbildung 7: Modellierung Poststelle Nachrichten
• Abbildung 8: Prinzip Reifizierung
• Abbildung 9: IBR – RDF – Klassenhierarchie
• Abbildung 10: Inschriftenträger im Netz der ihn umgebenden Raumelemente
• Abbildung 11: IBR Repository in openrdf -Workbench

Literaturverzeichnis

Anhang 1: Übersicht der verwendbaren Content-/Mime Types bei Sesame

Table 1. MIME types for RDF formats

Table 2. MIME types for variable binding formats

Anhang 2: RDF-XML-Inschrift_klassifizieren.xml

RDF-XML-Inschrift_klassifizieren.xml

1 <?xml version="1.0"?>
2 <rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"<br />3          xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4          xmlns:classes="http://ontology.spatialhumanities.de/classes/">
5 	<rdfs:Class rdf:about="http://ontology.spatialhumanities.de/classes/inscription" />
6 	<classes:inscription rdf:about="http://www.inschriften.net/data/di058/articles/di058-0012" />
7 </rdf:RDF>

Fußnoten

1. Siehe auch → http://www.dig-hum.de/ (Zugriff 14.07.2013). Alle Onlineressourcen können im Kapitel Webseiten und Onlineressourcen des Literaturverzeichnisses gefunden werden. »
2. Siehe auch → http://www.bmbf.de/ (Zugriff 14.07.2013). »
3. Siehe auch → http://foerderportal.bund.de/foekat/jsp/SucheAction.do?actionMode=view&fkz=01UG1233A (Zugriff 14.07.2013). »
4. Siehe auch → http://www.spatialhumanities.de/ibr/ (Zugriff 14.07.2013). »
5. Siehe auch → http://www.i3mainz.fh-mainz.de/Article3.html (Zugriff 14.07.2013). »
6. Siehe auch → http://www.digitale-akademie.de/ (Zugriff 14.07.2013). Die DA ist an der Akademie der Wissenschaften und der Literatur Mainz angesiedelt. Siehe auch → http://www.adwmainz.de/ (Zugriff 14.07.2013). »
7. Siehe auch → http://adw-goe.de/forschung/forschungsprojekte-akademienprogramm/deutsche-inschriften/ (Zugriff 14.07.2013). »
8. Siehe auch → http://www.inschriften.net/ (Zugriff 14.07.2013). »
9. Für eine praxisbezogene Einführung in die Epigraphik siehe:→ Moos, Paul Sebastian; Nikitsch, Eberhard J.: Blick in die Historikerwerkstatt: Die Arbeitswelt des Epigraphikers. Historische Hilfswissenschaft und ihre Bedeutung für Geschichte und Wissenschaft – ein römischer Erfahrungsbericht. In: Skriptum 2 (2012), Nr. 1, URN: urn:nbn:de:0289-2012050312, (Zugriff 14.07.2013) und Kloos, Rudolf M.: Einführung in die Epigraphik des Mittelalters und der frühen Neuzeit. Darmstadt, 2. Aufl. 1992. »
10. Vergleiche IBR Projektantrag. Der Projektantrag konnte vom Autor im Rahmen der Projektarbeit eingesehen werden, die Weitergabe war jedoch leider nicht möglich. Teile des Antrages sind jedoch im Wortlaut in die Projektbeschreibung auf der Projektwebseite eingeflossen und können dort nachgelesen werden. Siehe auch → http://www.spatialhumanities.de/ibr/ (Zugriff 14.07.2013). »
11. Siehe Kapitel RDF und siehe auch → http://www.w3.org/RDF/ (Zugriff 14.07.2013). »
12. Das Mittelalter wird datiert vom ca. 6. bis 15. Jahrhundert, direkt daran anschließend die frühe Neuzeit ca. bis zum Übergang vom 18. zum 19. Jahrhundert. Diese Datierungen sind Gegenstand geschichtswissenschaftlicher Diskussion. Im Rahmen dieses Beitrags ist obige Datierung völlig ausreichend. Vergleiche dazu auch → Knefelkamp, Ulrich: Das Mittelalter. Paderborn, 2. Aufl. 2003, ab Seite 12 oder Hartmann, Martina, Mittelalterliche Geschichte studieren. Konstanz, 2. Aufl. 2007, Seite 43 und ausführlicher auf den Seiten 42-49. »
13. Siehe auch → http://www.w3.org/wiki/URI (Zugriff 14.07.2013). Siehe auch → http://www.ietf.org/rfc/rfc3986.txt (Zugriff 14.07.2013). »
14. Das Buch von Hitzler, Pascal; Krötzsch, Markus; Rudolph, Sebastian; Sure, York: Semantic Web – Grundlagen. Berlin/Heidelberg 2008 kann zurzeit als eines der primären Werke in deutscher Sprache in diesem Bereich angesehen werden. Siehe auch Literaturempfehlung von → http://de.slideshare.net/seso81/3-sprachen-des-semantic-web-rdf (Zugriff 14.07.2013). »
15. Siehe auch → http://semanticweb.org/wiki/Main_Page (Zugriff 14.07.2013). »
16. Siehe auch → http://www.itwissen.info/definition/lexikon/Web-3-0-web-3-0.html (Zugriff 14.07.2013). »
17. Siehe auch → http://www.w3.org/People/Berners-Lee/ (Zugriff 14.07.2013). »
18. Siehe auch → http://www.w3.org/ (Zugriff 14.07.2013). »
19. Reduziert von: http://alyonakay.files.wordpress.com/2012/09/websummary2.jpg?w=510 (Zugriff 14.07.2013), das englische Vokabular wurde übernommen. Grafische Übersichten dieser Art finden sich mit zahlreichen Variationen auf vielen weiteren Webseiten (vor allem Weblogs), die hier nicht alle genannt werden können. Die Variationsvielfalt zeigt, dass die verschiedenen „Webversionen“ keinesfalls als klar voneinander getrennt oder als präzise definiert verstanden werden dürfen. »
20. Mit Verständnis ist hier nicht die menschliche Eigenschaft der intellektuellen Erfassung des Zusammenhangs gemeint, sondern die im Rahmen des jeweiligen und dem Computer bekannten Zusammenhangs mögliche Interpretation der Inhalte. »
21. Hitzler, et. al., S. 11. »
22. Siehe auch → http://www.w3.org/RDF/  (Zugriff 14.07.2013). »
23. Siehe auch abstract von → http://www.w3.org/TR/rdf-schema/  (Zugriff 14.07.2013). »
24. Hitzler, et. al., S. 38. »
25. Hitzler, et. al., S. 38. »
26. Siehe auch → http://www.w3.org/TR/url/  (Zugriff 14.07.2013). »
27. Siehe auch → http://www.w3.org/2005/07/13-nsuri (Zugriff 14.07.2013). »
28. Siehe auch → http://www.w3.org/TR/cooluris/ (Zugriff 14.07.2013). »
29. Siehe auch → http://www.w3.org/TR/rdf-concepts/#section-Literals (Zugriff 14.07.2013). »
30. Hitzler, et. al., S. 39. »
31. Hitzler, et. al., S. 50. »
32. Siehe auch → http://de.wikipedia.org/w/index.php?title=Zirkumflex&oldid=118923256  (Zugriff 14.07.2013). »
33. Hitzler, et. al., S. 39. »
34. Hitzler, et. al., S. 39. »
35. Dies gilt nur für kleinere Graphen. Mit einer wachsenden Anzahl an Tripeln wird der Graph entsprechend unübersichtlicher. Spätestens bei einer dreistelligen Anzahl an Tripeln, ist ein Graph auch für den Menschen nur noch sehr schwer bis nicht mehr erfassbar. »
36. Hitzler, et. al., S. 40. »
37. Ein lichter Graph weist, in Relation zu seinen Knoten, wenige Kanten auf. Wenn n die Anzahl der Knoten ist, dann ist die Anzahl der Kanten sehr viel kleiner als n². Siehe auch → http://know-center.tugraz.at/wp-content/uploads/2012/05/thesis_kandlhofer.pdf, Seite 19 (Zugriff 14.07.2013) sowie → http://altlasten.lutz.donnerhacke.de/mitarb/lutz/vortrag/fh-info9.pdf, Seite 4 (Zugriff 14.07.2013).  »
38. Siehe auch → Hitzler, et. al., Kapitel 3.2.1, Seite 40. »
39. Siehe auch → http://www.w3.org/TR/rdf-syntax-grammar/  (Zugriff 14.07.2013). »
40. Siehe auch Hitzler, et. al., S. 43. »
41. Siehe auch → http://www.w3schools.com/rdf/rdf_example.asp (Zugriff 14.07.2013). »
42. Siehe auch Hitzler, et. al., Seiten 46 und 47. »
43. hild wurde als Präfix für DI058 benutzt, weil Band 58 der „Deutschen Inschriften“ die Inschriften der Stadt Hildesheim umfasst. Siehe auch → http://www.inschriften.net/hildesheim/inschriften.html  (Zugriff 14.07.2013).  »
44. Vergleiche → http://www.w3.org/TeamSubmission/n3/ (Zugriff 14.07.2013). »
45. Vergleiche → http://www.w3.org/TR/rdf-testcases/#ntriples (Zugriff 14.07.2013). »
46. So ist es zum Beispiel mit dieser Notation N möglich in RDF ungültige Graphen zu modellieren. »
47. Vergleiche auch Hitzler, et. al., S. 40. »
48. Es gelten die selben Präfixdefinitionen wie im vorhergehenden Turtlebeispiel. »
49. Die im Graphen benutzten Präfixe „wiki:“ und „xsd:“ sind zu ersetzen durch „http://de.wikipedia.org/wiki/“ bzw. „http://www.w3.org/2001/XMLSchema“. Sie wurden an dieser Stelle in den Graphen eingefügt um eine übersichtliche und lesbare Darstellung zu ermöglichen. Außerdem wird die Jahresangabe hier als Datentyp integer interpretiert, da sie für diesen Fall als eigenständige Zahl und nicht als Datum angesehen wird. »
50. Hitzler, et. al., S. 59. »
51. Siehe auch Dengel, Seiten 120 und 121. »
52. Siehe auch Hitzler, et. al., S. 61. »
53. Indische Zahlschrift in der europäischen Darstellung. Siehe auch → http://de.wikipedia.org/w/index.php?title=Indische_Zahlschrift&oldid=117857787 (Zugriff 14.07.2013). »
54. Für weitergehende Informationen zu den Grundlagen von RDF sei auf Hitzler, et. al., Seiten 36–88 und Dengel, Seiten 109–125 verwiesen, sowie auf die offiziellen Onlineressourcen http://www.w3.org/RDF/ und http://www.w3.org/standards/techs/rdf. Eine vollständige Liste der RDF-Sprachkonstrukte kann unter der offiziellen Webressource http://www.w3.org/1999/02/22-rdf-syntax-ns gefunden werden (Zugriff jeweils am 14.07.2013). »
55. Siehe auch → http://www.w3.org/TR/rdf-schema/ (Zugriff 14.07.2013). »
56. Es existiert kein spezieller bzw. geeigneter englischer Begriff für eine Tumbenplatte. Es müsste eine umschreibende Erklärung im Englischen gefunden werden, wie zum Beispiel: „Slab from a tomb monument.“ Dies wäre aber für einen Klassennamen eine unvorteilhafte Konstruktion und so wurde an dieser Stelle tumba gewählt. »
57. Zugriff 14.07.2013 »
58. Siehe auch Zoulfa, El Jerroudi: Eine interaktive Vorgehensweise für den Vergleich und die Integration von Ontologien. Lohmar-Köln 2010, S. 15. »
59. Für weitereführende Informationen zu Ontologien sie hier verweisen auf Zoulfa und Stuckenschmidt, Heiner: Ontologien. Konzepte, Technologien und Anwendungen. Berlin/Heidelberg, 2. Aufl. 2011. »
60. Siehe auch → http://www.w3.org/TR/owl2-overview/ (Zugriff 14.07.2013). Siehe auch → http://www.w3.org/TR/owl-semantics/ (Zugriff 14.07.2013). »
61. Siehe auch Fielding, Roy Thomas: Architectural Styles and the Design of Network-based Software Architectures. University of California 2000. »
62. Fielding, S. 93. »
63. 1. bis 4. mit Text und Informationen von → https://blog.mittwald.de/webentwicklung/restful-webservices-1-was-ist-das-uberhaupt/ (Zugriff 14.07.2013). Siehe auch → https://restful-api-design.readthedocs.org/ (Zugriff 14.07.2013). Siehe auch → http://blog.2partsmagic.com/restful-uri-design/ (Zugriff 14.07.2013). »
64. Siehe auch → http://www.w3.org/TR/sparql11-overview/ (Zugriff 14.07.2013). »
65. Hitzler, et. al., S. 202. »
66. Hitzler, et. al., S. 203. »
67. Siehe auch → http://www.w3.org/TR/2013/REC-sparql11-update-20130321/ (Zugriff 14.07.2013). »
68. Siehe auch → http://answers.semanticweb.com/questions/3629/what-is-sparql-endpoint (Zugriff 14.07.2013). »
69. Siehe dazu auch Coors, Volker; Zipf, Alexander: 3D-Geoinformationssysteme, Grundlagen und Anwendungen. Heidelberg 2004, Seite 101 und 102. »
70. Siehe auch → http://data.ordnancesurvey.co.uk/ontology/spatialrelations/  (Zugriff 14.07.2013), zur owl-file, Siehe auch → http://www.ordnancesurvey.co.uk/oswebsite/ontology/spatialrelations.owl  (Zugriff 14.07.2013). »
71. Die interne Georeferenzierung kann wiederum zu einem externen Koordinatensystem in Beziehung gesetzt werden, zum Beispiel durch die entsprechenden GPS-Koordinaten der Kirche. »
72. Siehe auch → http://wiki.creativecommons.org/Special:ExportRDF/Stanford_University_%E2%80%93_Center_for_Computer_Assisted_Research_in_the_Humanities_%28CCARH%29 (Zugriff 14.07.2013). »
73. Siehe auch → http://www.semantic-humanities.net/.rdf (Zugriff 14.07.2013). Die Domain ist nicht mehr registriert und steht wieder zur Verfügung, laut http://whois.domaintools.com/semantic-humanities.net (Zugriff 14.07.2013). »
74. Siehe auch → http://tw.rpi.edu/wiki/Special:ExportRDF/Category:Humanities (Zugriff 14.07.2013). »
75. Aus Platzgründen wurden diese fünf Tripel für die Domain und Range hier nicht dargestellt und weiterhin werden für die folgenden Prädikate die Defintions- und Wertebereiche nur kurz textuell beschreiben und nicht mehr im Quelltext dargestellt. »
76. Dies könnten zum Beispiel Oster-, Pfingst- oder Weihnachtsprozessionen sein. »
77. Der kleine Seitenaltar, der einem bestimmten Heiligen gewidmet ist, wird beispielsweise nur zu dessen Gedenktag geöffnet. »
78. Im Englischen entsprechend: side aisle / central aisle / cloister / altar area / altar room / chapel. »
79. Annotationen; dafür wird im Kapitel Related Works unter anderem auf einige Tools zum semantischen annotieren von Ressourcen verwiesen. »
80. „nave“ ist die englische Bezeichnung für das Langhaus, welches das Mittelschiff und die Seitenschiffe bis zum Altar umfasst. »
81. Unter anderem ist die IBR-Informationsarchitektur auf dem Projektposter dargestellt. Siehe auch → http://www.spatialhumanities.de/fileadmin/user_upload/poster_deutsch_klein.pdf (Zugriff 14.07.2013). »
82. Siehe auch → http://www.inschriften.net/mainz/inschrift/nr/dio001-sn1-0023.html (Zugriff 14.07.2013). »
83. Siehe auch → http://de.wikipedia.org/w/index.php?title=Freie_Software&oldid=120494813 (Zugriff 14.07.2013). »
84. Siehe auch → http://de.wikipedia.org/w/index.php?title=Open_Source&oldid=119604735 (Zugriff 14.07.2013). »
85. Siehe auch → https://github.com/semsol/arc2/wiki (Zugriff 14.07.2013). »
86. Siehe auch Punkt History unter → https://github.com/semsol/arc2/wiki (Zugriff 14.07.2013). Siehe auch → Kapitel Aufgetretene Probleme »
87. Zum Beispiel RDF/XML oder Turtle. Diese kann man sich instanziieren mit: $parser = ARC2::getRDFXMLParser(); bzw. mit $parser = ARC2::getTurtleParser();. »
88. Zum Beispiel mit: $parser->parse('http://example.com/test.rdf');. »
89. Zum Beispiel mit: $parser->parse('data/test.ttl');. »
90. Siehe auch → https://github.com/semsol/arc2/wiki (Zugriff 14.07.2013). »
91. Siehe auch → http://www.openrdf.org/index.jsp (Zugriff 14.07.2013). »
92. Siehe auch → http://www.openrdf.org/doc/sesame2/users/ch01.html (Zugriff 14.07.2013). »
93. Siehe auch → http://www.openrdf.org/about.jsp (Zugriff 14.07.2013). »
94. Siehe auch → http://www.openrdf.org/consulting.jsp (Zugriff 14.07.2013). »
95. Siehe auch → http://sourceforge.net/mailarchive/forum.php?forum_name=sesame-general (Zugriff 14.07.2013). »
96. Siehe auch → http://www.heise.de/security/meldung/Oracle-schliesst-40-Luecken-in-Java-SE-1889170.html (Zugriff 14.07.2013). »
97. Zugriff 14.07.2013. »
98. Siehe auch → http://tomcat.apache.org/ (Zugriff 14.07.2013). »
99. Siehe auch → http://www.openrdf.org/download.jsp (Zugriff 14.07.2013). »
100. Zu Kontexten in Sesame siehe auch → http://www.openrdf.org/doc/sesame2/users/ch08.html#d0e1238 (Zugriff 14.07.2013). »
101. Siehe auch → http://www.w3.org/Submission/SPARQL-Update/ (Zugriff 14.07.2013). »
102. RDF/XML, RDF/JSON, Turtle, ... »
103. Ein Punkt für Kontexte ist hier auch vorhanden. »
104. Siehe auch → http://php.net/manual/de/book.curl.php (Zugriff 14.07.2013). »
105. Für eine ausführliche Übersicht der verfügbaren Ressourcen. Siehe auch → http://www.openrdf.org/doc/sesame2/system/ch08.html#d0e179.(Zugriff 14.07.2013). »
106. Siehe auch → http://www.openrdf.org/doc/sesame2/system/ch08.html#d0e764 (Zugriff 14.07.2013). »
107. Für weitere zulässige Accept Header für SPARQL Abfragen an Sesame sei hier auf die entsprechende Tabellen im Anhang 1 verwiesen. »
108. Siehe auch → http://www.w3schools.com/tags/ref_urlencode.asp (Zugriff 14.07.2013).  »
109. Siehe auch → http://tools.ietf.org/html/rfc3986 (Zugriff 14.07.2013). »
110. Siehe auch → http://www.openrdf.org/documentation.jsp (Zugriff 14.07.2013). »
111. Siehe auch → http://librdf.org/ (Zugriff 14.07.2013). »
112. Siehe auch → http://librdf.org/raptor/ (Zugriff 14.07.2013). »
113. Siehe auch → http://librdf.org/rasqal/ (Zugriff 14.07.2013). »
114. Siehe auch → http://librdf.org/bindings/ (Zugriff 14.07.2013). »
115. Für weitere Informationen zu LUA siehe auch → http://www.lua.org/ (Zugriff 14.07.2013). »
116. Siehe auch → http://download.librdf.org/source/ (Zugriff 14.07.2013). »
117. Siehe auch → https://github.com/dajobe (Zugriff 14.07.2013). »
118. Weiteres dazu findet sich im Kapitel Aufgetretene Probleme. Mit dem dort beschriebenen Beispiel konnte letztlich doch ein Test mit redland durchgeführt werden. »
119. Zur besseren Lesbarkeit in dieser Arbeit, wurden in Zeilen 14 bis 16 Variablen definiert und dann in Zeilen 18 bis 20 entsprechend benutzt. »
120. Siehe auch → http://librdf.org/docs/api/index.html (Zugriff 14.07.2013). »
121. Siehe Kapitel Related Work »
122. Siehe auch → http://librdf.org/ (Zugriff 14.07.2013). »
123. Beckett, Dave, Redland librdf Language Bindings - PHP Interface: http://librdf.org/docs/php.html (Zugriff 14.07.2013). »
124. Ostrowski, Felix, Dead Simple: RDF and SPARQL using PHP: http://blog.literarymachine.net/?p=5 (Zugriff 14.07.2013). »
125. Siehe auch → http://librdf.org/docs/api/redland-query-results.html#librdf-query-results-to-string2 (Zugriff 14.07.2013). »
126. Siehe auch → http://thepund.it/ (Zugriff 14.07.2013). »
127. Siehe auch → http://www.openannotation.org/spec/core/ (Zugriff 14.07.2013). »
128. Siehe auch → http://www.netseven.it/ (Zugriff 14.07.2013). »
129. Siehe auch → http://summit2013.lodlam.net/2013/05/15/announcing-lodlam-challenge-heat-2-finalists/ (Zugriff 14.07.2013). »
130. Siehe auch → https://github.com/net7/pundit/ (Zugriff 14.07.2013). Siehe auch → http://de.wikipedia.org/w/index.php?title=Bookmarklet&oldid=115460380 (Zugriff 14.07.2013). »
131. Siehe auch → http://thepund.it/bm/demo-timeline/ (Zugriff 14.07.2013). »
132. Siehe Pundit Screencast auf → http://www.thepund.it/introductory-videos/ (Zugriff 14.07.2013). »
133. Siehe auch → http://openid.net/ (Zugriff 14.07.2013). »
134. Siehe auch → http://metasound.dibet.univpm.it/annotationserver/ (Zugriff 14.07.2013). »
135. Als Akronym für „System for Annotation and Linkage of Sources in Arts and Humanities“ »
136. zusammengefasst von → http://www.dhlab.unibas.ch/index.php/de/forschung/salsah (Zugriff 14.07.2013) »
137. Siehe auch → http://loomp.org/(Zugriff 14.07.2013). »
138. Siehe auch → http://www.fu-berlin.de/(Zugriff 14.07.2013). »
139. Siehe auch → http://mayaarch3d.org/(Zugriff 14.07.2013). »
140. Siehe auch → http://www.steinheim-institut.de/wiki/index.php/RiR (Zugriff 14.07.2013). ‹155› Siehe auch → http://www.textgrid.de/fileadmin/praesentationen/tg-summit-2012/praesentation- relationen-raum.pdf (Zugriff 14.07.2013). »
141. Eigene Übersetzung von → http://mayaarch3d.org/research/goals-and-methods/ (Zugriff 14.07.2013). »
142. Zusammengefasst aus → http://www.textgrid.de/fileadmin/praesentationen/tg-summit-2012/praesentation-relationen-raum.pdf Seite 7, (Zugriff 14.07.2013). »
143. Siehe auch → http://www.inschriften.net/mainz/inschrift/nr/dio001-sn1-0023.htm (Zugriff 14.07.2013). »

Dieses Werk steht unter einer Creative Commons Namensnennung-Nicht kommerziell-Keine Bearbeitung 3.0 Deutschland Lizenz (CC-BY-NC-ND 3.0 DE).

Namensnennung — Sie müssen den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.

Nicht kommerziell — Sie dürfen das Material nicht für kommerzielle Zwecke nutzen.

Keine Bearbeitung erlaubt — Sie dürfen diesen Inhalt nicht bearbeiten, abwandeln oder in anderer Weise verändern.

Zum Zitationshinweis springen

Autoreninformation

Michael Haft ist Student der Informatik und der Physik in den Studiengängen Bachelor of Science und Diplom. Außerdem ist er Mitarbeiter im Projekt „Inschriften im Bezugssystem des Raums“ der Akademie der Wissenschaften und der Literatur Mainz.

PDF-Download

• RDF als Verknüpfungsmethode zwischen geisteswissenschaftlichen Forschungsdaten und Geometrien am Beispiel des Projektes „Inschriften im Bezugssystem des Raumes“ – von Michael Haft
• Gesamtausgabe Skriptum 3 (2013), Heft 2

Kategorien

Epoche

• Alte Geschichte
• Byzantinistik
• Digital Humanities
• Europäisches Mittelalter
• Geschichtsdidaktik
• Musikgeschichte
• Neuere Geschichte
• Neueste Geschichte
• Osteuropäische Geschichte
• Zeitgeschichte

Textgenre

• Abschlussarbeit
• Editorial
• Essay
• Rezension
• Seminararbeit
• Unterrichtsentwurf
• Vereinsbericht
• Werkstattbericht

Zitationshinweis:

Michael Haft: RDF als Verknüpfungsmethode zwischen geisteswissenschaftlichen Forschungsdaten und Geometrien am Beispiel des Projektes „Inschriften im Bezugssystem des Raumes“, in: Skriptum 3 (2013), Nr. 2, URN: urn:nbn:de:0289-2013120622, Abs. XY [Datum des Zugriffes].

Sie sind hier:

• Archiv»
• Jahrgang 3 (2013)»
• Heft 2»
• RDF als Verknüpfungsmethode zwischen geisteswissenschaftlichen Forschungsdaten und Geometrien am Beispiel des Projektes „Inschriften im Bezugssystem des Raumes“

Weitere Informationen

• Linkliste
• Datenschutz
• Benutzungshinweise
• Technologien & Materialien