Design and Development of a Semantic Web based Data Model for Text Analytics

Transkript

1 Rheinische Friedrich-Wilhelms-Universität Bonn Institut für Informatik III Design and Development of a Semantic Web based Data Model for Text Analytics Diplomarbeit Bonn, August 2014 Vorgelegt von: Seyed Navid Nourbakhsh Studiengang Informatik

2 Abstract <TODO: Abstract schreiben> Schlagwörter RDF; NIF; context; REST API; Triplestore; SPARQL;

3 Inhaltsverzeichnis Abbildungsverzeichnis Quellcode Verzeichnis vi vii I. Einleitung 1 1. Einleitung Aufgabenstellung und Zielsetzung Aufbau der Arbeit II. Grundlagen 5 2. Grundlagen Semantic Web Resource Description Framework (RDF) Uniform Resource Identifier (URI) in RDF RDF-Datenmodell Serialisierung von RDF-Dokumenten RDF/XML Terse RDF Triple Language (Turtle) JSON-based Serialization for Linked Data (JSON/LD) SPARQL Protocol and RDF Query Language Technologische Grundlagen Node.JS MongoDB Datenmodell Binary JSON (BSON) III. Natural Language Processing on Linked Data Natural Language Processing on Linked Data Linked open Data (LOD2) NLP Interchange Format (NIF) URI Schemata NIF Core Ontology NIF Profile

4 Inhaltsverzeichnis iv IV. Bedarfsanalyse Bedarfsanalyse context - Lightweight Text Analytics using Linked Data Technische Umsetzung von context Anforderungsanalyse Linked open Data (LOD2) Anforderungsanalyse NLP Interchange Format (NIF) Anforderungen Datenbank Sicherheitsanforderungen Zusammenfassung der Anforderungen V. Design Entscheidungen Design Entscheidungen Auswahl der Datenbank und Framework Openlink Virtuoso Server MongoDB mit RDF Store JS Entscheidung über die Wahl der Datenbank Importierungsarten NLP-Services Datenstruktur für die Überführung in ein RDF-Dokument NLP Interchange Formates (NIF) LOD2 Anforderungen Sicherheitsanforderungen VI. Implementation Implementation Allgemeiner Aufbau RDF-Backend Export der Daten als NIF-Dokument Löschung der Daten aus der Triplestore Datenbank Speicherung in die Triplestore Datenbank NIF Implementierung Aufbau des NIF-Dokumentes Hauptartikel (nif:context) Entitäten (NIF Subklasse) Zeichenzählung im NIF-Dokument SPARQL-Endpoint Anfragen Ausgabe Formate Sicherheit

5 Inhaltsverzeichnis v VII. Evaluation Evaluierung NIF Validator Versuchsaufbau Versuchsdurchführung und Auswertung 83 VIII. Zusammenfassung und Ausblick Zusammenfassung und Ausblick Zusammenfassung Ausblick Literaturverzeichnis 90 Literaturverzeichnis 90 Erklärung 93

6 Abbildungsverzeichnis 2.1. Sprachen und standards des Semantik Webs Ein einfacher RDF-Graph Linked Data Lebenszyklus nach LOD Startseite des Plattoforms context context Erstellung eines neuen Corpuses context Corpus Annotation context Facetten Ansicht Architektur von context Ordnerstruktur context MongoDB Datenbankstruktur von context context - Ansicht zur Erstellung eines neuen Corpus context - Datenbankschema bestehend aus den collections users, corpuses und articles MongoDB Datenbankstruktur von context

7 Quellcode Verzeichnis 2.1. RDF/XML Serialisierter Graph Alternative Darstellung des RDF/XML-Graphen Einfacher Graph in Turtle-Serialisierung Einfacher Graph in JSON/LD Serialisierung Einfache SPARQL Anfrage Erweiterte SPARQL Anfrage mit DISTINCT OPTIONAL LIMIT und FILTER RDF-Backend Funktion zur Exportierung eines Corpuses als NIF-Dokument Funktion zur Annotierung und Speicherung des NIF-Dokuments Speicherung eines Triples in die MongoDB Datenbank mit rdfstorejs Beispiel für ein erstelltes NIF-Dokument Beispiel Ausgabe in RDF/XML Serialisierung Beispiel Ausgabe in JSON/LD Serialisierung Ein Artikel der Pressemitteilung Uni Bonn in der Datenbank Corpus der Pressemitteilungen der Universität Bonn in Datenbank Benutzer der den Corpus der Pressemitteilungen der Universität Bonn erstellt hat in der Datenbank Ein Artikel aus der exportierten NIF-Dokument

8 Teil I. Einleitung

9 1. Einleitung Das World Wide Web hat den Zugang zu Informationen in der Gesellschaft revolutioniert. Noch nie in der Geschichte war es möglich, so schnell und einfach zugang zu derart großen Mengen an Wissen und Informationen zu erhalten. Ebenso ist es nun für jeden Einzelnen ein Leichtes, selbst neues Wissen und Informationen zu veröffentlichen und für ein breites Publikum zugänglich zu machen. Die neuen Technologien führen zu enormen gesellschaftlichen Veränderungen, die vergleichbar mit denen innerhalb der industriellen Revolution sind. Die aktuelle Gesellschaft entwickelt sich immer mehr in Richtung einer Wissensgesellschaft. Durch die deutliche Vereinfachung und dadurch auch Kostensenkung bei der Publikation neuen Wissens, und die damit verbundene Kostensenkung, wird das Meinungsmonopol einzelner Medien und Verlage aufgelöst. Im 20. Jahrhundert hatten nur relativ wenige Medien wie Zeitungen, Fernsehsender und Radiostationen die Möglichkeit, mit ihren Informationen und Texten ein breites Publikum zu erreichen. Doch durch die große Verbreitung des Webs und neuartiger Publikationswerkzeuge wie Blogs und sozialer Netzwerke hat jeder die Möglichkeit, ein Milliarden Publikum zu erreichen. Jedoch führt gerade die Vereinfachung des Publikationsvorganges zu einer regelrechten Informationsexplosion. Eine große Herausforderung in einer solchen Wissens- und Informationsgesellschaft besteht darin, aus den vorhandenen Informationen die wesentlichen und die für den einzelnen Nutzer jeweils interessanten Informationen zu filtern und zu sortieren. Aufgrund der Quantität der täglich hinzukommenden neuen Informationen ist dies für den Einzelnen nicht zu bewältigen. Deshalb bietet es sich an, Computer und Computerprogramme zu verwenden um diese Informationen zu filtern und aufzubereiten. Anderes als Menschen können Computer nicht von sich aus die Bedeutung von Texten erfassen und diese mit anderen in Relation setzen. Für sie sind Wörter nichts anderes als Zeichenketten ohne eine weitere Bedeutung. Um Computer dennoch für die Verarbeitung eines in natürlicher Sprache geschriebenen Textes verwenden zu können, haben sich in der Informatik zwei wesentliche Ansätze zur Lösung dieses Problems herausgebildet. Einerseits gibt es die künstliche Intelligenz, die versucht, die menschlichen Synapsen nachzubilden. Andererseits versucht das Semantic Web, die für die automatische Verarbeitung nötigen Metadaten bereitzustellen. Die künstliche Intelligenz macht in diesem Bereich große Fortschritte, wie das von IBM entwickeltes Programm Watson [Jackson (2011)] zeigt. Dieses Programm ist in der Lage menschliche Gegenspieler in Jeopardy zu schlagen. Jedoch ist die Künstliche Intelligenz im Allgemeinen noch weit von Marktreife entfernt. Das Semantic Web hingegen versucht, einen deutlich einfacheren Weg zu gehen in dem es die Informationen in Maschinenlesbarer und verarbeitbarer form zur Verfügung stellt bzw in einem entsprechenden Format konvertiert.

10 1. Einleitung 3 So kann zum Beispiel bei der Zeichenkette Bonn die Information, dass es sich um eine Stadt handelt deklariert werden. Zusammen mit dem Begriff Stadt sind wiederrum Informationen wie die Einwohnerzahl oder Ortsvorwahl gespeichert. Auf diese Weise kann ein Computerprogramm auf die Frage Wie viele Einwohner hat Berlin? antworten; denn es weiß, eine Stadt ist und hat den entsprechenden Entitätswert Einwohnerzahl gespeichert. Um dabei bessere Ergebnisse zu erzielen, ist es unumgänglich, dass mehrere, je auf einem Einsatzgebiet spezialisierte Computerprogramme, zusammenarbeiten und ihre Ergebnisse in einem standardisierten Format miteinander auszutauschen Aufgabenstellung und Zielsetzung Mit context [Research] stellt das AKSW [Group] eine Webplattform zur Verfügung, mit Hilfe derer Benutzer sehr leicht Texte und Informationen aus diversen Quellen und Eingabeformaten zusammentragen können. Diese werden durch die Benutzung von Linked Data analysiert und mit weiteren Daten angereichert. Beispielsweise können einfache Texte wie Zeitungsartikel eingetragen, mit Hilfe der DBpedia [Auer u. a. (2007)] Datenbank analysiert und deren Entitäten wie Stadt, Firmenname, Land extrahiert weden. Anschließend werden sie dem Benutzer in übersichtlicher Form präsentiert. Der Benutzer hat die Möglichkeit, die angezeigten Informationen anhand ihrer Entitäten zu filtern und zu sortieren. Um unabhängig von der visuellen Präsentation die eingegeben und angereicherten Informationen in einem anderen Programm weiterverarbeiten zu können, ist es notwendig diese in einem standardisierten Format zu konvertieren und anschließend zu exportieren. Um tiefer gehenden Analysen der vorhandenen Informationen durchzuführen, sollte es möglich sein, die gespeicherten Informationen per SPARQL abzufragen. Darüber hinaus ist mittelfristig die Aufnahme des Programmes context in der LOD2-Sammlung (siehe Kapitel 3.1) geplant. Dazu ist im Intercomponent integration requirements [lod2] das Vorhandensein eines SPARQL-Endpoints als Voraussetzung gefordert. Es soll durch diese Arbeit ermöglicht werden, die für die Weiterverarbeitung benötigten Informationen in einem standardisierten Format aus dem Programm context zu exportieren und durch einen SPARQL-Endpoint Anfragen zu stellen Aufbau der Arbeit Der Aufbau der folgenden Kapitel ist eng an die Ziele dieser Arbeit angelehnt. Im zweiten Kapitel werden die für diese Arbeit wesentlichen Grundlagen vermittelt, die für ein vollständiges Verständnis der weiteren Kapitel notwendig sind. Im dritten Kapitel werden die Projekte LOD2 und das Natural language Processing Interchange Format (NIF) vorgestellt. Das vierte Kapitel ermittelt die Anforderungen an einem RDF-backend und formuliert die zu erfüllende Anforderungen. Im fünften Kapitel werden die Design Entscheindungen aufgrund der gestellten

11 1. Einleitung 4 Anforderungen beschrieben. Das sechste Kapitel erläutert die Implementation des Systems. Im siebten Kapitel wird die Evaluation anhand der geforderten Eigenschaft des NIF-Formates durchgeführt. Im achten Kapitel werden die Ergebnisse zusammengefasst bevor abschließend ein kurzer Ausblick auf mögliche Verbesserungen gegeben wird. Beim Schreiben der vorliegenden Arbeit werden wurde auf die Übersetzung viele Englisch Fachbegriffe verzichtet, da sie im Fachliteratur größere Verwendung finden und die deutsche Übersetzung weniger geläufig ist. Zu diesen Wörtern gehören unter anderem RDF-Backend, SPARQL-Endpoint, Overhead und collections. <TODO: Korrektur lesen!1!!!!>

12 Teil II. Grundlagen

13 2. Grundlagen 2.1. Semantic Web Das World Wide Web hat den Zugang zu Informationen in der Gesellschaft revolutioniert. Noch nie war es so einfach, Zugang zu einer derart großen Menge an Informationen zu erhalten. Durch die hohe Verfügbarkeit an Informationen, zumindest in den Industrieländern, ist das World Wide Web in der Lage, die Art, wie wir Informationen wahrnehmen und verbreiten grundlegend zu verändern. Das Internet dringt in immer mehr Lebensbereiche unseres alltäglichen Lebens, von Nachrichten, über Musik bis hin zur öffentlichen Verwaltung ein. Ebenso ist es für den einzelnen Menschen leichter geworden, selbst neues Wissen und Informationen zu veröffentlichen und für ein breites Publikum zugänglich zu machen. So entwickelt sich die Gesellschaft immer mehr in Richtung einer Wissens- und Informationsgesellschaft. Ebenso ist es für den einzelnen Menschen leichter geworden, selbst neues Wissen und Informationen zu veröffentlichen und für ein breites Publikum zugänglich zu machen. So entwickelt sich die Gesellschaft immer mehr in Richtung einer Wissens- und Informationsgesellschaft. Durch die große Verbreitung des Webs und neuartiger Publikationswerkzeuge wie Blogs und sozialer Netzwerke hat jeder die Möglichkeit, einen Milliardenpublikum zu erreichen. Jedoch ist es auch wegen der Vereinfachung des Publikationsvorganges zu einer Regelrechten Informationsexplosion gekommen. [Hitzler u. a. (2008)] Eine große Herausforderung in einer solchen Wissens- und Informationsgesellschaft besteht darin aus den vorhandenen Informationen die wesentlichen und für den einzelnen Nutzer jeweils interessanten zu Filtern und zu sortieren. Aufgrund der Quantität der täglich hinzukommenden neuen Informationen ist dies für den einzelnen nicht zu bewältigen. Deshalb bietet es sich an Computer und Computerprogramme zu benutzen um diese Informationen zu Filtern und aufzubereiten. Anderes als Menschen können Computer nicht von sich aus die Bedeutung von Texten erfassen und diese mit anderen in Beziehung setzen. Für sie sind Wörter nichts anderes als einzelne Zeichenketten ohne weitere Bedeutung [Hitzler u. a. (2008)]. <TODO: etwas umschreiben> Suchmaschinen wie Google oder Bing versuchen, den Benutzer auf der Suche nach Informationen zu unterstützen. Jedoch war die Websuche lange Zeit ausschließlich auf die Suche nach Zeichenketten in Texten und deren Sortierreihenfolge beschränkt. Die Suchmaschinen haben beispielsweise nach dem Begriff Bonn gesucht, indem sie alle Dokumente, welche die Zeichenkette Bonn enthalten aus der Datenbank extrahiert und durch einen Ranking Algorithmus sortiert haben [Lewandowski (2005)]. Sie hatten demnach keine genaueren Kenntnisse darüber, was der Begriff Bonn genau bedeutet. Das Konzept des Semantic Webs beruht auf dem Vorschlag von Tim Berners-Lee, dem Erfinder des WWW und HTMLs [Berners-Lee (2014)]. Er beschrieb im Jahr 2001 seine Vision eines

14 2. Grundlagen 7 Semantic Webs in einem Artikel der Zeitschrift Scientific America [Berners-Lee u. a. (2001)]. In diesem Artikel legt er die technischen Konzepte, nach denen das Semantic Web aufgebaut ist, dar. Er schildert, dass das Semantic Web eine Struktur ins Web einbringen soll, die für Computer leichter zu verarbeiten ist. Beispielsweise sollen bei der Suche nach Bonn nicht nur alle Seiten herausgesucht werden, die den Begriff Bonn enthalten. Stattdessen soll bei einer Suche nach dem Suchbegriff Bonn, die Software explizit wissen, dass es sich bei dem Begriff um eine Stadt handelt, zu deren Eigenschaften auch Postleitzahlen und geografische Koordinaten gehören, sodass sie auch Dokumente anzeigt, bei denen nur die Koordinaten oder die Postleitzahlen angegeben sind. Darüber hinaus soll sie auch Fragen nach z.b. der Einwohnerzahl von Bonn einfach beantworten können. Dazu wird jedes Objekt eindeutig mit einem URI (Uniform Resource Identifier) identifiziert. Hierbei handelt es sich um die Allgemeinform der gängigen URLs (Uniform Resource Locator) wie beispielsweise Das Semantic Web sieht Berners-Lee nicht als ein neues Web, sondern als Erweiterung des vorhandenen Webs, in dem Informationen klar strukturiert vorliegen und so Computer und Menschen ermöglicht, einfacher auf den Kontext der Daten zuzugreifen. Berners-Lee sah die auch schon damals existierenden Techniken XML und RDF (siehe Kapitel 2.1.1) als Grundlage dafür. Mit diesen lassen sich Informationen strukturiert und für Maschinen verarbeitbar erstellen und anzeigen. So könnte der Begriff Bonn in XML ganz einfach mit <city>bonn</city> gekennzeichnet werden. Als zweite Säule beschrieb er die Ontologie als ein Dokument oder eine Datei, welches formal die Beziehung zwischen zwei Termen definiert. Die im Web übliche Form davon sind Taxonomien. Er beschrieb Taxonomien als Klassen von Objekten und deren Beziehung zu einander. Dabei werden den Klassen bestimmte Eigenschaften zugeordnet. Jede Klasse kann dabei auch Unterklassen haben, welche die Eigenschaften der Elternklasse erben. Er sah im Klassenprinzip und deren Beziehungen zu einander eine mächtige Ausdrucksmöglichkeit für das Web. Er beschrieb weiterhin, dass es durch Inferenzregeln möglich ist, weiteres Wissen implizit zu erlangen. Indem beispielsweise formuliert wird: eine Stadt hat eine Telefonvorwahl und jeder Teilnehmer mit dieser Vorwahl befindet sich in dieser Stadt. Mit solchen Inferenzregeln ist es z.b. auch für einen Computer möglich, anhand der mit 0228 beginnenden Telefonnummer der Firma Haribo darauf zu schließen, dass sie ihre Niederlassung in Bonn hat. Als weitere Säule des Semantic Webs sah Berners-Lee sogenannte Agenten, die ihre Erkenntnisse miteinander teilen und bei bestimmten Aufgaben auf andere Agenten mit der jeweiligen Spezialisierung ausweichen. Die Kryptografie mit digitalen Signaturen sollte es den Agenten erlauben, sicherzustellen, dass die Antworten aus einer vertrauenswürdigen Quelle stammen und ihnen die Möglichkeit geben, die Quellen jederzeit zu überprüfen [Berners-Lee u. a. (2001)].

15 2. Grundlagen 8 Für das Semantic Web gelten einige weitere Voraussetzungen. So muss durch einheitliche und offene Standards, der Austausch von Informationen über Anwendung und Plattformgrenzen hinaus gewährleistet sein [Hitzler u. a. (2008)]. Dies wird unter dem Begriff Interoperabilität zusammen gefasst. Diese Standards müssen ebenfalls erweiterbar und Flexibel sein [Hitzler u. a. (2008)] [Berners- Lee u. a. (2001)]. Das World Wide Web Consortium (W3C) hat sich der Schaffung und Erweiterung eines solchen Standards verschrieben [Hitzler u. a. (2008)]. Siehe Abbildung 2.1 für eine Übersicht der verschiedenen Sprachen und Standards des Semantic Webs. <TODO: erklären> Abb. 2.1: Sprachen und standards des Semantik Webs [Quelle: W3.org Resource Description Framework (RDF) Beim Resource Description Framework RDF, handelt es sich um eine von W3C [W3C] verabschiedete formale Sprache zur strukturierten Beschreibung von Informationen [Hitzler u. a. (2008)] [Domingue u. a. (2011)]. RDF bietet eine standardisierte Datenstruktur und ein Modell zur Enkodierung von Daten und Metadaten im Web [Domingue u. a. (2011)]. Die klar strukturierten Daten sollen die Interoperabilität eines dezentralen Systems ermöglichen. Sie sollen dazu führen, dass implizites Wissen, durch Programme explizit gemacht und dem Benutzer zur Verfügung gestellt

16 2. Grundlagen 9 werden kann. Zum Beispiel das anhand der Ortsvorwahl implizit bekannt ist, dass die Firma Haribo seinen Sitz in Bonn hat. Das Wissen wird im RDF als Triple präsentiert. Bei dem Triple handelt es sich um einen gerichteten Graphen, also eine Menge von Knoten, die durch gerichtete Kanten verbunden sind [Hitzler u. a. (2008)]. Die Knoten und Kanten sind mit eindeutigen Bezeichnern beschriftet. Ein Triple besteht aus einem Subjekt, einem Prädikat und einem Objekt. Ein einfacher RDF-Graph ist in der Abbildung 2.2 dargestellt. Sie beschreibt die Relation zwischen context und der Arbeitsgruppe AKSW. In diesem Fall ist context das Subjekt, erstelltvon das Prädikat und AKSW das Objekt. Das Triple beschreibt den einfachen Satz context wurde von AKSW erstellt. Dabei ist zu beachten, dass RDF von einer offenen Welt ausgeht (englisch openworld assumption). Das heißt: wenn in einem Triple keine expliziten Aussagen bezüglich eines Faktes gemacht worden sind, bedeutet dies nicht, dass dieser nicht wahr ist [Domingue u. a. (2011)]. Dies unterscheidet das RDF-Modell von klassischen relationalen Modellen, die davon ausgehen, dass alle Aussagen die nicht explizit angegeben sind, nicht wahr sind. Abb. 2.2: Ein einfacher RDF-Graph Uniform Resource Identifier (URI) in RDF Ein Uniform Resource Identifier URI bezeichnet eine Zeichenkette, die es ermöglicht, eine abstrakte oder physische Ressource zu identifizieren [Berners-Lee u. a. (2005)]. URIs können jede Art von Objekten bezeichnen, die eine eindeutige Identität besitzen. URIs werden innerhalb von RDF dazu eingesetzt, Objekte eindeutig zu identifizieren und Verwechselungen aufgrund des gleichen Bezeichners verhindern [Hitzler u. a. (2008)]. So kann die Bezeichnung address je nach Kontext eine postalische Adresse, eine -Adresse oder auch eine Internet Adresse bezeichnen. Durch die eindeutige Bezeichnung durch URIs wird solche Verwechselungen bei der automatischen Verarbeitung vorgebeugt. Dabei werden im Internet meist Uniform Resource Locators (URL) eingesetzt. Uniform Resource Locators [Berners-Lee u. a. (1994)] sind eine Teilmenge von URIs. Eine URL kann eine komplette Pfadangabe wie oder eine relative Pfadangabe wie /source/doc.html enthalten. Die URI kann außerdem einen Fragmentbezeichner # enthalten, welcher von dem eigentlichen URI getrennt ist [Berners-Lee u. a. (2005)]. Wie in Abbildung 2.2 dargestellt, werden bei RDF meist

17 2. Grundlagen 10 URIs für die eindeutige Bezeichnung der Objekte verwendet. Es werden sowohl Knoten als auch Kanten eines RDF-Graphen mit URIs beschriftet. Dabei spielt es keine Rolle, ob die gegebene URL tatsächlich existiert und ob dort relevante Informationen vorenthalten werden. URLs sind lediglich Referenzen auf die Ressourcen und deren Interpretation hängt von der verarbeitenden Anwendung ab [Hitzler u. a. (2008)] RDF-Datenmodell Das Wissen wird im RDF als Triple, bestehend aus Subjekt, Prädikat und Objekt dargestellt. Das Subjekt ist die Ressource, über die eine Aussage getroffen wird. Das Prädikat beschreibt die Relation zwischen den beiden Ressourcen und deklariert das Subjekt näher. Das Objekt enthält den Wert einer Eigenschaft. Dabei kann es sich um ein Objekt oder einen konstanten Wert handeln. Durch diese Eigenschaften ist es möglich, komplexe Aussagen zu formulieren. So ist die Forschungsgruppe AKSW, die das Objekt in Abbildung 2.2 darstellt, selbst ein Subjekt, da die AKSW-Gruppe wiederum aus einzelnen Mitgliedern und Projekten besteht. Jedes Triple bildet eine abgeschlossene Aussage. Jeder Graph besteht aus einzelnen Aussagen, die miteinander kombiniert werden können [Hitzler u. a. (2008)]. So besteht der Graph aus Abbildung 2.2 aus folgendem Triple bestehend aus <Subjekt, Prädikat, Objekt> < < < Jeder Knoten im Graph kann durch seine URI eindeutig bezeichnet und referenziert werden. Es gibt jedoch Fälle, in denen Knoten keine URI besitzen. Dabei kann es sich um Hilfsknoten handeln oder Knoten, bei denen die URI nicht bekannt ist. Solche leeren Knoten ohne Bezeichner werden als Blank Nodes bezeichnet [Hitzler u. a. (2008)]. Durch die fehlende Bezeichnung dieser Knoten ist es nicht möglich, sie global zu referenzieren. Blank Nodes sind lediglich für die Subjekt- und Objektknoten zulässig [Hitzler u. a. (2008)] Serialisierung von RDF-Dokumenten Wie in den vorherigen Abschnitten erwähnt, werden Daten im RDF als Triple in Form von <Subjekt, Prädikat, Objekt> oder visuell als Graph dargestellt. Die Darstellung als Graph bietet den Nutzern eine schnelle Übersicht über die Daten ist jedoch nicht ohne weiteres maschinenverarbeitbar, was den Zielen von RDF, der eine leichte maschinelle Verarbeitung von Dokumenten fordert, zuwiderläuft [Domingue u. a. (2011)]. So wurden von W3C Mechanismen zur Serialisierung von RDF-Graphen definiert. Bei einer Serialisierung werden komplexe Datenobjekte in lineare Zeichenketten transformiert [Hitzler u. a. (2008)]. Das bedeutet, dass bei RDF der abstrakte Graph

18 2. Grundlagen 11 in eine konkrete Zeichenkette umgewandelt und gespeichert wird ohne dass dabei Daten verloren gehen. Dabei vereinfacht die Eigenschaft das jede Aussage in sich geschlossen ist, die Serialisierung erheblich [Hitzler u. a. (2008)]. Im Folgenden werden die für diese Arbeit wichtigen Serialisierungstandards betrachtet. Alle Serialisierungsstandards haben gemein, dass sie die Texte in Unicode-Format und per Standard UTF-8 enkodiert werden RDF/XML Die XML-basierte Schreibweise von RDF-Graphen ist die am weitesten verbreitete Version. Sie verdankt ihre Popularität nicht zuletzt der großen XML-Unterstützung in allen gängigen Programmiersprachen [Hitzler u. a. (2008)] [Domingue u. a. (2011)]. RDF/XML ist der de-facto Standard, bei der Erstellung von RDF-Graphen. Fast alle Programme mit RDF-Unterstützung, bieten ebenso die Speicherung im XML-Format an [Domingue u. a. (2011)]. Die Serialisierung von RDF-Dokumenten in XML wurde im Jahr 2004 von W3C standardisiert [Beckett (2004)]. Dabei stellen die unterschiedlichen Datenmodelle zwischen RDF und XML kein Problem dar. XML-Dokumente sind hierarchisch als Baum mit einer Wurzel aufgebaut. Die Blätter enthalten die jeweiligen Literale. RDF basiert auf Graphen, die aus einem Triple bestehen. So muss die Kodierung des Triples hierarchisch erfolgen [Hitzler u. a. (2008)]. Dabei werden die Triple nach dem Subjekt geordnet. Der Graph aus der Abbildung 2.2 sieht als RDF/XML kodiert wie folgt aus. Quellcode 2.1: RDF/XML Serialisierter Graph 1 <? xml version=" 1.0" encoding="utf -8"?> 2 <rdf:rdf 3 xmlns:example=" example. com/" 4 xmlns:rdf=" org/1999/02/22 - rdf - syntax -ns#" > 5 <rdf:description rdf:about=" example. com/ context"> 6 <example:erstelltvon rdf:resource=" aksw. org/ About" /> 7 </ rdf:description > 8 </ rdf:rdf > Das im Beispiel Quellcode 2.1 dargestellte Dokument beginnt mit der Angabe über die XML- Version und die UTF-8 Kodierung, welche Optional ist. Jedes RDF/XML-Dokument hat den Knoten rdf:rdf als Wurzel, um das Dokument als RDF zu deklarieren [Domingue u. a. (2011)]. Die Attribute im Wurzelelement werden dazu genutzt Namensräume zu definieren. Im Beispiel werden durch das Element xmlns zwei Namensräume ex: und rdf: deklariert. Das Präfix rdf kann hierbei beliebig gewählt werden, zur besseren Lesbarkeit werden jedoch üblicherweise der Name des Namensraumes als Präfix benutzt [Hitzler u. a. (2008)]. Der Knoten rdf:description leitet die Beschreibung einer Ressource ein. Sie enthält die Graph-Daten und beschreibt das Subjekt und Objekt. Das Prädikat example:erstelltvon wird direkt als Element angelegt. Ein einfacher

19 2. Grundlagen 12 rdf:description Knoten enthält das Attribut rdf:id mit einer ID, welche zu einem URI expandiert wird oder das Attribut rdf:about mit einer URI um die Ressource zu identifizieren und definiert Kindselemente um die Ressource zu beschreiben [Domingue u. a. (2011)]. Das Attribut rdf:resource im Element example:erstelltvon bezeichnet das Objekt des Triples, sodass kein weiteres rdf:description Tag angelegt werden muss. Somit hat example:erstelltvon keinen Inhalt und muss als selbstschließendes Element mit einem / geschlossen werden. Ebenso wäre es möglich, statt rdf:resource ein neues Element mit rdf:description zu erstellen und dort das Objekt anzulegen. Dieses Vorgehen ist im Quellcode 2.2 dargestellt. Dabei wird derselbe Graph wie in Quellcode 2.1 kodiert mit dem Unterschied, dass das Objekt selbst als ein rdf:description Element kodiert ist. Quellcode 2.2: Alternative Darstellung des RDF/XML-Graphen 1 <? xml version=" 1.0" encoding="utf -8"?> 2 <rdf:rdf 3 xmlns:example=" example. com/" 4 xmlns:rdf=" org/1999/02/22 - rdf - syntax -ns#" > 5 <rdf:description rdf:about=" example. com/ context"> 6 <example:erstelltvon > 7 <rdf:description rdf:about=" aksw. org/ About" /> 8 </ example:erstelltvon > 9 </ rdf:description > 10 </ rdf:rdf > Wie dieses einfache Beispiel zeigt, gibt es in XML unterschiedliche Möglichkeiten, denselben Graph zu kodieren. Somit kann der daraus resultierende XML-Baum unterschiedlich sein, obwohl die gleichen Daten kodiert werden. Die XML-Serialisierung von RDF-Dokumenten ist wie bereits erwähnt der am häufigsten genutzte Standard zur Weitergabe von RDF-Daten. Somit wird sie von einer Vielzahl von Programmen unterstützt und sollte für bessere Interoperabilität auch von neuen Programmen unterstützt werden. RDF/XML hat jedoch auch einige Nachteile. So kann die nicht eindeutige Kodierung von Daten mit verschiedenen Plattformen und Programmen zu Fehlern führen. Ebenso verursacht sie durch die Vielzahl von Verschachtlungen von Knoten, Elementen und Attributen einen sehr großen Overhead, welches die Dokumentgröße stark ansteigen lässt und bei sehr großen Datenmengen die Verarbeitung verlangsamt. Außerdem werden RDF/XML-Dokumente schnell unübersichtlich, sodass sich Menschen darin schwerer zurecht finden. Um diese Unzulänglichkeiten zu beseitigen, haben sich neben RDF/XML auch einige andere Datenformate zur Kodierung von RDF-Dokumenten etabliert auf die im Weiteren eingegangen wird.

20 2. Grundlagen Terse RDF Triple Language (Turtle) Die Terse RDF Triple Language oder kurz als Turtle bezeichnet ist ein Serialisierungsmechanismus für RDF-Dokumente. Sie wurde am 25. Februar 2014 als ein neuer Standard zur Serialiserung von RDF-Dokumenten veröffentlicht [Carothers und Prud hommeaux (2014)]. Das in dieser Arbeit benutzte Natural Language Interchange Format (NIF) setzt für die Kodierung der Triple auf das Turtle-Format, weshalb die Grundlagen im Folgenden beschrieben werden. Turtle ermöglicht es wie der Begriff Terse im Namen andeutet, RDF-Graphen in einer sehr kompakten textuellen Form darzustellen. 1 So wird der Graph aus der Abbildung 2.2 in Turtle Syntax wie folgt dargestellt: Quellcode 2.3: Einfacher Graph in Turtle-Serialisierung rdf: < org/1999/02/22 - rdf - syntax -ns#>. example: < example. com/>. 4 < example. com/ context > 5 example: erstelltvon < aksw. org/about >. Das Dokument beginnt mit der Deklaration der Präfixe in Dekorform präfixname:uri. Der Präfixname kann beliebig gewählt werden und wird bei der Verarbeitung durch die Software in einen absoluten URI umgewandelt. Das bedeutet im Quellcode 2-3, dass example:erstelltvon äquivalent ist mit der absoluten URI [Carothers und Prud hommeaux (2014)]. Bei Turtle werden URIs immer in spitzen Klammern < > eingeschlossen. Literale werden in Anführungszeichen eingeschlossen. Es ist ebenso möglich, Literale innerhalb mehrere Anführungszeichen zu platzieren. Dabei darf das Literal selbst diese Zeichenkette nicht enthalten [Carothers und Prud hommeaux (2014)]. Das Triple ist bei Turtle in folgender Form gespeichert: <SubjectURI> PrädikatURI ObjektURI; PrädikatURI ObjektURI. Jedes Triple ist durch einen Semikolon (;) abgeschlossen. Damit ist es möglich, beliebig viele prädikat:objekt Paare für ein Subjekt festzulegen [Domingue u. a. (2011)]. Mehrere Aussagen mit Subjekt:Prädikat Paaren können durch ein Komma getrennt werden. Die Aussagen werden anschließend durch einen Punkt beendet. Leerzeichen und Zeilenumbrüche spielen nur innerhalb von Bezeichnungen eine Rolle und werden ansonsten ignoriert [Hitzler u. a. (2008)]. Unter Turtle ist es ebenfalls möglich, den Datentyp des Literals mit einer XSD-Deklaration anzugeben. Dazu wird mit zwei Zirkumflexen (^^) markiert und dann der Datentyp angegeben, wie zum Beispiel ^^xsd:string.

21 2. Grundlagen 14 Wie man im Beispiel Quellcode 2.3 leicht erkennen kann, ist es mit Turtle möglich RDF-Graphen sehr kompakt und platzsparend zu Serialisieren. Turtle hat ebenfalls den Vorteil, dass sie von Menschen einfacher gelesen werden kann JSON-based Serialization for Linked Data (JSON/LD) Das JSON/LD Format ist wie Turtle ein relativ neues Format zur Serialisierung von RDF- Graphen. Es wurde am 16. Januar 2014 von W3C Veröffentlicht [Lanthaler u. a. (2014)]. Bei JSON/LD werden die RDF Triple in das JavaScript Object Notation Format überführt. Es ist vorrangig für die Benutzung von Linked Data in webbasierten Plattformen und zur Speicherung von Daten in JSON basierenden Datenbaken wie in MongoDB gedacht [Lanthaler u. a. (2014)]. Bei context handelt es sich ebenfalls um eine webbasierten Plattform mit einem SPARQL- Endpoint. Für bessere Interoperabilität mit anderen Diensten und Plattformen wird die Ausgabe der SPARQL Anfragen in JSON/LD Format ebenfalls unterstützt, weshalb im Weiteren kurz auf den Aufbau eingegangen wird. Der Graph aus Abbildung 2.2 wird in JSON/LD Syntax wie folgt dargestellt: 1 { Quellcode 2.4: Einfacher Graph in JSON/LD Serialisierung 2 "@context": { 3 "example": " 4 " erstelltvon": " example. com/ erstelltvon" 5 }, 6 "@id":" example. com/ context", 7 " erstelltvon": " aksw. org/ About" 8 } term wird dazu benutzt um terme auf URIs in JSON/LD ist vergleichbar mit Deklaration im Turtle Format. So ist im Quellcode 2.4 nicht die Angabe der vollständigen URI notwendig, sondern es kann lediglich die abgekürzte Form erstelltvon angegeben werden [Lanthaler u. a. (2014)]. Bei eine großen zahl von Triplen kann die abgekürzte Schreibweise die Übersichtlichkeit deutlich erhöhen und verbraucht dabei weniger Speicherplatz. Es können dabei beliebig viele Terme definiert werden. Im context können für Terme sowohl URIs als auch JSON Objekt angegeben werden. So eingebetteten JSON Objekt werden meist dazu benutzt um zusätzliche Angaben über Typ und Sprache der Daten zu speichern [Lanthaler u. a. (2014)]. In JSON/LD müssen nicht alle Terme im context eingebettet werden, der context kann auch lediglich eine URI mit dem Verweis zu den Daten enthalten [Lanthaler u. a. (2014)].

22 2. Grundlagen 15 Element wird dazu benutzt Knoten global referenzierbar zu gestalten. Mit Element kann ein Standard Präfix deklariert werden der bei allen Termen die keinen eigenen Eintrag unter context haben benutzt wird [Lanthaler u. a. (2014)]. Das JSON/LD Format ist vollständig mit dem JSON Format kompatibel, dies hat den Vorteil das alle Bibliotheken und Programmen die das JSON Format unterstützten auch für JSON/LD benutzt werden können. JSON/LD verbraucht im Vergleich zu RDF/XML weniger Speicherplatz und kann einfacher verarbeitet werden. Es ist auch für Menschen einfacher lesbar als RDF/XML, wenn auch nicht ganz so übersichtlich wie das Turtle Format. Durch die gute Einbindung in Javascript lässt es sich mit nativen mitteln in Javascript verarbeiten, weshalb es große Verbreitung bei Javascript basierten Plattformen findet SPARQL Protocol and RDF Query Language SPARQL steht für SPARQL Protocol and RDF Query Language. SPARQL ist ein Standard für die Abfrage von in RDF spezifizierten Informationen und die Darstellung der entsprechenden Abfrageresultate [Hitzler u. a. (2008)]. Die SPARQL Version 1.0 wurde am 15.Januar 2008 als W3C Empfehlung veröffentlicht, welches ihr den Status eines Standards verliehen hat [Seaborne und Prud hommeaux (2008)]. Die Version 1.0 enthielt lediglich Befehle zur Erstellung von Datenbankanfragen und besaß keine Befehle zur Datenmanipulation innerhalb der Datenbank. Die Funktionen zu Datenmanipulation wurden in der SPARQL Version 1.1, welches am 21. März 2013 als W3C Empfehlung veröffentlicht wurde, ergänzt [Seaborne und Harris (2013)]. Die für diese Arbeit eingesetzte rdfstorejs Bibliothek unterstützt die SPARQL Version 1.0 vollständig und die nur die wichtigsten Befehle der Version 1.1 [rdfstorejscurrent]. Aus diesem Grund und da daten-manipulierende Anfragen bei context die Ausnahme bilden, wird in diesem Kapitel auf die SPARQL Version 1.0 näher eingegangen. So ist, bei der Benutzung des Wortes SPARQL ohne Versionsangabe, immer die SPARQL Version 1.0 gemeint. SPARQL Anfragen sind RDF Basiert und setzen auf eine Turtle (siehe Kapitel ) ähnliche Syntax [Hitzler u. a. (2008)]. SPARQL ist ebenfalls von der Anfragesprache SQL inspiriert und verwendet auch ähnliche Schlüsselwörter wie SELECT oder WHERE. Eine einfache SPARQL Anfrage beginnt mit einem oder mehrere PREFIX Teil, in dem die Präfixe für die aktuelle Anfrage definiert werden. Dabei ist die URL wie im Turtle Format üblich in spitzen Klammern (<>) angegeben. Im Gegensatz zu der Turtle Notation ist hierbei kein abschließender Punkt notwendig [Dengel (2011)]. Eine einfache SPARQL Anfrage ist in Quellcode 2.5 abgebildet. Der im Beispiel definierte Präfix ex: < wird in der weiteren Anfrage statt der vollständigen URL verwendet. So ist der Ausdruck ex:name gleichbedeutend wie Die definierten Präfixe werden bei Anfragen automatisch durch den Parser ergänzt. Das Schlüsselwort SELECT bestimmt wie bei normalen SQL Befehlen das Ausgabeformat. Bei dem Bezeichner?subjekt handelt es sich um die Anfragevariable und er signalisiert für welche Anfragevariablen Rückgabewerte angefordert werden [Hitzler u. a. (2008)]. Das Fragezeichen

23 2. Grundlagen 16? ist nicht Teil des Variablennamens, sondern signalisiert das es sich bei der Zeichenfolge um eine Variable handelt. Durch die Benutzung des Sternchens (*), kann ein Rückgabewert für alle Variablen angefordert werden. Die Anfrage wird durch das Schlüsselwort WHERE eingeleitet. Ihm folgt innerhalb von geschweiften Klammern ein RDF-Triple [Hitzler u. a. (2008)]. Dabei ist das Objekt des Triples mit dem konkreten Wert (ex:name) belegt. Das Subjekt und das Prädikat enthalten nur Variablenbezeichner und können demnach einen beliebigen Wert besitzen. So können Elemente in einem SPARQL Anfrage Triple aus URIs, QNames und Variablen bestehen. Daher kann die im Quellcode 2.5 gestellte Anfrage mit Zeige alle Subjekte aus den Triples die das Objekt enthalten übersetzt werden. 1 PREFIX ex: < example. com/> 2 3 SELECT? subjekt 4 WHERE 5 {? subjekt? praedikat ex: name } Quellcode 2.5: Einfache SPARQL Anfrage Das Ergebnis eine SPARQL-Anfrage ist eine Tabelle von Lösungen, wobei jede Lösung aus einer Menge von Variablenbindungen besteht [Dengel (2011)]. Bei der Anfrage kann bei Literalen optional auch ein Datentyp angegeben werden. Unter SPARQL ist es möglich aus einfachen Graph-Mustern, gruppierende Graph-Muster zu erzeugen. Bei gruppierenden Graph-Mustern ist es möglich bestimmte Bedingungen nur an einen Teil des gesamten Musters zu stellen bzw. eine Teilmuster als optional zu definieren [Hitzler u. a. (2008)]. Dazu werden im SPARQL geschweiften Klammern ({ }) verwendet. Das Schlüsselwort OPTIONAL kennzeichnet eine Bedingung als optional. In Folge muss diese Bedingung nicht bei allen ermittelten Ergebnissen vorkommen, wenn diese jedoch vorkommt, erweitert sie das Ergebnis [Seaborne und Prud hommeaux (2008)]. Eine solche optionale Anfrage ist im Quellcode 2.6 dargestellt. Ähnlich wie in SQL ist die Modifikation der Reihenfolge und Ergebnisse unter SPARQL ebenfalls möglich. Durch die Benutzung des Schlüsselwortes DISTINCT in der SELECT Anfrage werden doppelte Einträge aus der Ergebnismenge entfernt. Mit der Benutzung des Schlüsselwortes LIMIT kann die maximale Anzahl der zurückgelieferten Ergebnisse festgelegt werden. Durch die ORDER BY Klausel, wird das Ergebnis der Anfrage anhand der Werte eine gegebene Variable sortiert [Seaborne und Prud hommeaux (2008)]. Die Benutzung dieser Klauseln, ist in Quellcode 2.6 dargestellt. Ein weiteres Ausdrucksmittel innerhalb von SPARQL sind Filterbedingungen. Durch die Klausel FILTER werden zusätzliche Bedingungen in einer Anfrage formuliert um die Menge der Lösungen weiter einzuschränken. Beispielsweise wird im Quellcode 2.6, die Lösung auf alle Werte, bei denen die Variable?jahrgang einen Wert größer als 1980 besitzt begrenzt. Der große Vorteil der

24 2. Grundlagen 17 FILTER Bedingung ist, dass sie nicht nur auf RDF-Ausdrücke beschränkt ist. So sind Filter mit XPATH oder sogar reguläre Ausdrücke möglich. 1 Quellcode 2.6: Erweiterte SPARQL Anfrage mit DISTINCT OPTIONAL LIMIT und FILTER 2 PREFIX ex: < example. com/> 3 4 SELECT DISTINCT? subjekt 5 WHERE 6 {? subjekt? praedikat ex: name. 7? subjekt ex: year? jahrgang 8 OPTIONAL 9 {? subjekt ex: student? name } 10 FILTER (? jahrgang > 1980 ) 11 } 12 ORDER BY DESC(? name) 13 LIMIT 50 In SPARQL existieren neben der SELECT Anfragen, einige andere Anfrageformen. So liefert die CONSTRUCT Anfrage einen einzigen RDF-Graphen, dessen Einträge durch eine Vorlage definiert wurden, zurück. Dabei wird die Lösung jede Anfrage durch die in der Vorlage angegebenen Variablenbezeichnung ersetzt [Seaborne und Prud hommeaux (2008)]. Die ASK Anfrage wird dazu verwendet um zu Prüfen ob eine SPARQL-Anfrage eine Lösung besitzt. Es werden dabei keine weiteren Informationen über die gefundenen Lösung zurück geliefert. Der Rückgabewert ist dementsprechend boolean [Seaborne und Prud hommeaux (2008)]. Bei der DESCRIBE Anfrage, wird eine Beschreibung der Ressource mit allen möglichen Belegungen für eine angegebenen Variable angefordert.

25 2. Grundlagen Technologische Grundlagen Node.JS Node.JS ist ein Framework zur Entwicklung von serverseitigen Anwendungen auf Javascript basis. Sie wurde im Jahr 2009 von Ryan Dahl veröffentlicht [Roden (2014)]. Node.JS basiert auf Googles Javascript Engine V8 [Roden (2014)]. Die V8 Engine steigert die Performance von Javascript Anwendungen in dem der Code durch einen Just-in-Time Compiler zuerst in Maschinencode übersetzt und danach ausgeführt wird[roden (2014)]. Dies führt zu eine erheblichen Steigerung der Ausführgeschwindigkeit. Node.JS soll das sogenannte C10K Problem lösen, welches verlangt das ein Server in der Lage sein soll Clients gleichzeitig zu bedienen [Roden (2014)]. Dazu wird im Gegensatz zu dem am meisten verbreiteten Apache Webserver nicht für jede Anfrage ein eigener Thread gestartet, sondern alle Anfragen werden von einem einzigen Thread nacheinander bearbeitet. Damit dieser Thread nicht blockiert, verfolgt Node.JS ein eventbasierten und nicht blockierenden Ansatz. Dabei werden Anfragen nach Möglichkeit zu einem Modul delegiert und der Server fährt mit der nächsten Anfrage fort. Sobald das Modul die Anfrage bearbeitet hat, ruft sie eine Callback-Funktion auf die dem Hauptthread signalisiert das Ergebnisse vorliegen. Anschließend fährt Node.JS mit der Bearbeitung der Anfrage fort. Dadurch ist es möglich, innerhalb kurzer Zeit viele Anfragen mit nur einem Thread zu bearbeiten. Node.JS kommt dabei zu gute, dass moderne Webanwendungen meist auf externe Ressourcen wie Datenbanken oder das Dateisystem angewiesen sind und so die meiste Zeit mit dem warten auf die Ergebnisse dieser Ressourcen verbringen. Durch die asynchrone Verarbeitung entfällt dieses Warten [Roden (2014)]. Bei Multiprozessorsystemen, wird für jeden Prozessorkern ein eigener Thread gestartet. Die Kommunikation zwischen den einzelnen Threads erfolgt über TCP/IP, so dass eine Interprozesskommunikation nicht nur auf einen physischen Server beschränkt ist [Roden (2014)], sondern auch über Rechencluster funktioniert. Zusätzlich bietet Node.JS eine gute Unterstützung für das JSON Format an, welches oft bei REST Systemen zum Einsatz kommt. Das JSON Format wird ebenfalls von der in dieser Arbeit weiter entwickelten Anwendung context intensiv benutzt. context ist meist auf APIs und externe Ressourcen angewiesen, wodurch sich Node.JS als Serverplattform für diese Anwendung besonderes gut eignet MongoDB MongoDB ist eine dokumentorientierte NOSQL Datenbank. Die erste Version erschien im Jahr Sie ist in C++ programmiert und steht unter der GNU AGPL 3.0 Lizenz [Edlich u. a. (2011)]

26 2. Grundlagen 19 MongoDB speichert die Daten im Binary JSON (BSON) Format die an das Javascript Object Notation (JSON) Format angelehnt ist. Sie wurde zur Speicherung von großen Datenmengen mit einer möglichst hohen Leistung entwickelt [Roden (2014)]. Sie bietet eine einfache Möglichkeit zur Skalierung und Replikation an. Eine Journaling-Funktion ist ebenfalls vorhanden. Die primäre Interaktionssprache ist Javascript, deshalb arbeitet MongoDB sehr gut mit Node.JS zusammen. MongoDB unterstützt ebenfalls Indizes um die Abfrageperformance zu erhöhen Datenmodell MongoDB ist schemafrei, was bedeutet das vor der Erstellung neuer Daten kein Schema erzeugt werden muss. Dieses wird beim Einfügen der ersten Daten implizit erzeugt [Edlich u. a. (2011)]. Bei MongoDB existieren collections die in etwa mit Tabellen im relationalen Datenbanken vergleichbar sind. In den collections werden die Daten abgelegt. Dabei ist es im Gegensatz zu relationalen Datenbanken nicht notwendig, dass alle Daten die selbe Struktur besitzen. Für eine einfacherer Indizierung und Durchsuchbarkeit ist dies jedoch dennoch ratsam [Edlich u. a. (2011)] Binary JSON (BSON) Das Binary JSON (BSON) Format ist an das JSON Format angelehnt und enthält ebenfalls die Werte in Form von key:value [BSON]. Sie wurde im Vergleich zur JSON um einige Datentypen wie etwa date, document und binary erweitert. Zusätzlich werden dem Dokument einige Metainformationen wie etwa der Längen Präfix hinzugefügt um die Flexibilität und Performance zu erhöhen [BSON]. BSON wird hauptsächlich von der MongoDB Datenbank eingesetzt.

27 Teil III. Natural Language Processing on Linked Data

28 3. Natural Language Processing on Linked Data 3.1. Linked open Data (LOD2) LOD2 ist ein von der Europäischen Union mitfinanziertes Projekt, welches die Verbesserung der Nutzung des Webs als Plattform für Daten- und Informationsintegration zum Ziel hat [Jänicke]. Der LOD2 Stack ist eine Distribution bestehend aus einer Reihe von aufeinander abgestimmten Tools und Programmen, mit deren Hilfe alle notwendigen Verarbeitungsschritte im Lebenszyklus von Linked Data ausgeführt werden können. Zum Lebenszyklus von Linked Data gehört unter anderem das Extrahieren von Informationen, die Erstellung von Linked Data durch Anreicherung mit zusätzlichen Metainformationen und die Vernetzung der gewonnen Daten. Die LOD2 Distribution besteht aus Open-Source Programmen beziehungsweise Programmen die eine kostenlose Nutzung und Anpassung erlauben, dies ermöglicht eine große Verbreitung und Skalierung der eingesetzten Programme [Auer u. a. (2012)]. Darüber hinaus soll die LOD2 Distribution möglichst einfach erweiterbar und anpassbar sein. Für jede Funktionalität gibt es klar definierte Schnittstellen die es anderen Entwicklern ermöglichen an beliebiger Stelle alternative Implementierungen einzusetzen [Auer u. a. (2012)]. Die Architektur des LOD2 Stacks beruht auf drei Säulen [Auer u. a. (2012)]: 1. Softwareintegration und Bereitstellung durch das Debian packaging System. Durch die Verwendung von Debian-Paketen ist die einfache Weitergrabe von Paketen möglich. Darüber hinaus können in Debian-Paketen die Abhängigkeiten und Versionsinformationen zu jeder Komponente angegeben werden, womit sich die Abhängigkeiten zwischen den einzelnen LOD2 Stack Komponenten besser abbilden lassen. Außerdem erlauben Debian-Pakete den individuellen Betrieb von einzelnen Komponenten des LOD2 Stacks auf einem Server. 2. Die Benutzung eines zentralen SPARQL-Endpoints und standardisierte Vokabeln für die bessere Integration und Zusammenarbeit der integrierten Programme. 3. Die Integration innerhalb einer gemeinsamen grafischen Benutzerschnittstelle auf REST Basis. Dabei bleibt die individuelle Benutzeroberfläche jedes eingesetzten Programms erhalten, da sie für ihren Verwendungszweck optimiert worden ist. Stattdessen wurde ein gemeinsamer Einstiegspunkt entwickelt, welcher den Benutzer anschließend auf die Oberfläche des gewünschten Programms weiterleitet.

29 3. Natural Language Processing on Linked Data 22 Abb. 3.1: Linked Data Lebenszyklus nach LOD2 [Quelle: LOD2 Webseite Der Lebenszyklus der Linked Data ist in verschiedene Phasen unterteilt, diese Phasen sind in der Abbildung 3.1 graphisch dargestellt. Für diese Arbeit ist der Punkt Search/Browsing/Exploration von besonderem Interesse. Hierbei setzt context seinen Schwerpunkt auf die Erkundung und Veranschaulichung der Ergebnisse und soll mittelfristig ebenfalls in den LOD2 Stack aufgenommen werden. Dabei soll der Benutzerfeedback ebenfalls an die anderen Schichten weitergegeben werden um deren Ergebnisse zu verbessern [Khalili u. a. (2014)]. Dementsprechend müssen die Voraussetzungen für die Aufnahme im LOD2 Stack bei der Entwicklung des RDF-Backends mitberücksichtigt werden NLP Interchange Format (NIF) Das Natural language Processing Interchange Format (NIF) entstand während der Entwicklung des LOD2 Projektes. Durch die unterschiedlichen Programmen, welche jeweils eigene Eingabeund Ausgabeformate verwenden, wurde der Bedarf an einem einheitlichen Datenaustauschformat zwischen den unterschiedlichen Programmen offensichtlich. Denn nur durch ein einheitliches Datenformat, kann eine reibungslose Zusammenarbeit zwischen den verschiedenen Programmen gewährleistet werden. Durch solch ein einheitliches Datenformat kann außerdem zur Verbesserung der Ergebnisqualität die Ausgabe mehrerer Programme miteinander kombiniert bzw. die Programme nacheinander ausgeführt werden [Hellmann u. a. (2013)]. Das NIF-Format basiert auf das RDF/OWL Format und hat das Ziel, eine bessere Interoperabilität zwischen den unterschiedlichen Natural Language Processing (NLP) Programmen zu ermöglichen. Dabei agiert das NIF-Format in 3 Schichten [Hellmann u. a. (2013)]:

30 3. Natural Language Processing on Linked Data Die Strukturschicht, welche URI Schemata zur Identifizierung von Elementen in Texten verwendet. Die identifizierten Elemente werden anhand der NIF Core Ontology beschrieben. 2. Die konzeptionelle Schicht, welche eine Auswahl an häufig verwendete NLP-Termen enthält. 3. Die Zugriffsschicht auf REST Basis URI Schemata Für leichtere Benutzung innerhalb von NLP-Programmen, ist bei NIF jeder Text bzw. jedes Teilwort des Textes, mit einer eindeutigen URI identifizierbar. Dabei sind alle URI nach RFC 5147 [Wilde und Duerst (2008)] aufgebaut. Die URI wird in einen prefix und einen remainder Abschnitt unterteilt. Diese beiden Abschnitte sind durch einen Separator # von einander getrennt. So können einzelne Teile oder der ganze Text in Form von adressiert werden. Bei Verwendung von #char=0 wird der gesamte Text adressiert [Hellmann u. a. (2013)] NIF Core Ontology Die NIF Core Ontology bietet die Klassen und Eigenschaften zum Beschreiben der Relationen zwischen Teilwörter, Texten und Dokumenten und deren URI Schemata. Dabei ist die Hauptklasse in dieser Ontologie die nif:string Klasse. Die nif:string Klasse beinhaltet alle Wörter über das Unicode Alphabet. Das NIF-Format verwendet die Unicode Normalization Form C (NFC) Kodierung welche durch den RDF Standard für rdf:literal empfohlen wird. Jedes URI Schemata ist eine Subklasse der nif:string Klasse. Es ist ebenfalls möglich, eigene URI Schemata zu definieren, in dem eine Subklasse von nif:string definiert wird. Zeichen werden im NIF-Format in Unicode Points gezählt [Hellmann u. a. (2013)]. Die Dokumentation kann im Feld rdfs:comment erfolgen. Ebenfalls wichtig ist die nif:context OWL Klasse. Diese Klasse ist allen Zeichen im Text zugewiesen und wird zur Berechnung aller Indizes für alle Teilwörter benutzt. So ist es notwendig, dass alle Teilwörter die Relation nif:referencecontext besitzen welches auf eine Instanz von nif:context zeigt. Im Datentyp nif:isstring wird der referenzierte Text gespeichert, der in einem valides NIF-Dokument immer angegeben werden muss [Hellmann (a)] [Hellmann u. a. (2013)] NIF Profile Für das NIF-Format existieren vier Profile die dazu benutzt werden, die Granularität eines Textes fest zu legen. Je nach Profil werden unterschiedliche Mengen an Termen und Klassen zum annotieren von Texten angeboten. Entwickler können den für ihren Anwendungszweck das geeignete Profil auswählen. Derzeit ist lediglich das NIF Simple Profil genauer spezifiziert. Die Spezifikation der restlichen Profile befindet sich noch im Anfangsstadium. Das NIF-Format bietet folgende Profile an [Hellmann u. a. (2013)]:

31 3. Natural Language Processing on Linked Data 24 NIF Simple Das NIF Simple Profil bietet grundlegende Eigenschaften zur Beschreibung und eindeutige Referenzierung von Texten an. NIF Simple unterstützt die Weitergabe des besten Schätzwertes eines NLP-Services. Sie ist das empfohlene Profil in den meisten Anwendungsfällen. Innerhalb des NIF Simple Profils ist der client für das lösen von Inkonsistenzen zuständig. Die confidence (das heißt die Angabe wie sicher der NLP-Service über das ausgegebene Ergebnis ist) kann für jede Entität mit angegeben werden, jedoch ohne alternativen Vorschläge[Hellmann u. a. (2013)] zu beinhalten. In dieser Arbeit kommt das NIF Simple Profil zum Einsatz. NIF Simple Underspecified Beim NIF Simple Underspecified handelt es sich um eine Variation des NIF Simple Profils. Sie soll nur zum Einsatz kommen, wenn das Präfix gleich der annotierten Informationsressource ist. Dieses Profil hat nur ein Triple pro annotierte Entität als Ausgabe, kann jedoch nicht per SPARQL abgefragt werden. Dies hat jedoch das Risiko, dass sie mit der primären Datenquelle nicht immer Synchron läuft [Hellmann u. a. (2013)]. NIF Stanbol Beim NIF Stanbol Profil handelt es sich um ein gegenüber dem NIF Simple erweiterten Profil. So ist es beim NIF Stanbol Profil möglich, alternative Annotationen mit dem jeweiligen confidence Wert und auch die Herkunftsangabe des zur Annotation benutzen NLP- Service mitanzugeben. Das NIF Stanbol Profil ist komplementär gegenüber dem NIF Simple Profil [Hellmann u. a. (2013)] und kann mit Verlust der zusätzlichen Annotationen in das NIF Simple Profil konvertiert werden. NIF OA (Open Annotation) Das NIF Open Annotation Profil bietet das ausdrucksstärkste Modell, erzeugt aber dabei die meisten Triple [Hellmann u. a. (2013)]. Sie ist zu diesem Zeitpunkt jedoch noch nicht im Detail Spezifiziert.

32 Teil IV. Bedarfsanalyse

33 4. Bedarfsanalyse Im vorangegangenen Kapitel wurde eine Einführung in die allgemeinen Grundlagen der verwendeten Konzepte gegeben. Das folgende Kapitel beschäftigt sich konkret mit der Analyse der im vorliegenden Szenario auftretenden Technologien und Methoden. Dazu wird zu Beginn das zu Grunde liegende Projekt context vorgestellt und seine Bestandteile technisch analysiert. Anschließend werden die weiteren Anforderungen an einem RDF-Backend für context analysiert. Dazu gehören die Voraussetzungen für die Aufnahme im LOD2 Stack ebenso wie die Anforderungen des Natural Language Interchange Format (NIF). Abschließend wird auf die Anforderungen der bei der Realisierung von context verwendeten Software und Bibliotheken bzw. deren Limitierungen eingegangen. Aus der Analyse jedes der folgenden Bereiche ergeben sich Anforderungen und Voraussetzungen für die Architektur und Implementierung des RDF-Backends, die beim Entwurf und bei der Implementierung berücksichtigt werden müssen context - Lightweight Text Analytics using Linked Data context ist eine Webplattform, bei dem Benutzer ihre Texte mit Hilfe von Natural Language Processing Techniken analysieren und visualisieren können [Khalili u. a. (2014)]. context wurde von der Arbeitsgruppe AKSW an der Universität Leipzig unter einer Open Source-Lizenz entwickelt. Ursprünglich basierte context auf den Techniken PHP und JavaScript mit der relationalen Datenbank MYSQL als backend. So bezieht sich der zitierte Artikel [Khalili u. a. (2014)] auf diese Version. Zugunsten einer besseren Skalierbarkeit und Erweiterbarkeit der Webplattform, wurde context im März 2014 auf Basis von Node.JS und MongoDB neu entwickelt. Dabei gab es am strukturellen Aufbau und den dahinterstehenden Ideen keine änderungen, jedoch wurde die technische Implementierung grundlegend verändert. Die Neuumsetzung ist zurzeit noch nicht vollständig abgeschlossen und es sind derzeit noch nicht alle Features verfügbar. Die Beschreibungen und Erläuterungen der technischen Umsetzungen in dieser Arbeit beziehen sich - wenn nicht anderes angegeben - auf den Quelltext von context im Branch rdfbackend mit dem aktuellsten Commit vom [Nourbakhsh] <TODO: Commit Datum korrigieren> auf Basis von Node.JS und MongoDB. Die Erarbeitung der Anforderungen eines RDF-Backends für ein System erfordert genaue Kenntnisse über deren Aufbau, deren Struktur und die technische Implementierung des Systems. Aus diesem Grund erfolgt in diesem Kapitel eine detaillierte Erläuterung der Arbeitsweise und des Aufbaus von context. Ausgehend von diesen Kenntnissen werden anschließend Anforderungen

34 4. Bedarfsanalyse 27 Abb. 4.1: Startseite des Plattoforms context an ein RDF-Backend formuliert. Die Hauptzielgruppe von context sind Endbenutzer, denen es ermöglicht werden soll auch ohne Kenntnisse im Semantic Web ausgeklügelte NLP Analyse-Techniken zu verwenden und die Ergebnisse visualisiert dargestellt zu bekommen. Durch die Visualisierung sollen auch komplexe Zusammenhänge und Beziehungen leicht verständlich dargestellt werden [Khalili u. a. (2014)]. Dabei können Daten aus verschiedenen Quellen hinzugefügt werden. Abbildung 4.2 zeigt einen Überblick über der Eingabeformate, die der Benutzer beim Hinzufügen von neuen Daten hat. Dabei wird technisch ein neuer Corpus erstellt, mit dem die importierten Daten verbunden sind. context bietet Möglichkeiten zum Hinzufügen von Daten aus RSS Feeds, Twitter, Webseiten sowie Turtle-Dokumenten und bringt individuelle Parser für die Plattformen Wordpress, Blogger und SlideWiki mit. Die Eingabeoptionen ändern sich je nach gewählter Importierungsart. So muss der Benutzer bei der Wahl der Importierungsart RSS/RDF/ATOM Feed die URL des Webfeeds angeben und bei der Wahl von Direct Input bekommt er ein Textfeld zur direkten Eingabe angezeigt. Die verschiedenen Eingabemöglichkeiten der Daten sind in der Abbildung 4.1 dargestellt. Anschließend hat der Benutzer die Möglichkeit, zwischen verschiedenen Natural Language Processing (NLP) Services zu wählen. Derzeit werden die NLP Services DBpedia Spotlight [Mendes u. a. (2011)] mit insgesamt 10 Sprachen und der NLP-Service Federated knowledge extraction-framework (FOX) [Ngomo u. a. (2011)] unterstützt. Die unterstützten Sprachen bei DBpedia Spotlight sind Englisch, Deutsch, Niederländisch, Französisch, Ungarisch, Italienisch, Portugiesisch, Russisch, Spanisch und Türkisch. DBpedia Spotlight findet Erwähnungen von

35 4. Bedarfsanalyse 28 Abb. 4.2: context Erstellung eines neuen Corpuses DBpedia-Ressourcen aus den unterstützten Sprachen im Text und verlinkt sie zu der hinter der DBPedia stehenden Cloud [Khalili u. a. (2014)]. Damit ist es möglich, zu Begriffen wie Bonn oder City in einem beliebigen Text zusätzliche Informationen abzurufen und den Begriffen im Text in für den Computer verständliche Klassen wie Settlement zuzuordnen.<todo: Kann man es besser ausdrücken?> Bei FOX handelt es sich um einen Wissensextraktion-Framework, der die verschiedenen NLP-Algorithmen benutzt um RDF-Triple mit einer hohen Genauigkeit aus dem Text zu extrahieren [Khalili u. a. (2014)]. Dabei ist FOX derzeit nur auf die Ressourcentypen Personen, Orte und Organisationen beschränkt. Die NLP-Services werden zur Auffindung und Analyse von Entitäten benutzt. Das Hinzufügen neuer NLP-Services und Eingabetypen ist mit sehr geringem Aufwand möglich. Die Auswahlliste der NLP Dienste ist in Abbildung 4.2 unter dem Punkt NLP API dargestellt. Der Benutzer kann ebenfalls eine Sprache unter den von der DBpedia unterstützten Sprachen für den Corpus auswählen. Diese Auswahl wird ebenfalls im Corpus gespeichert. Abschließend vergibt der Benutzer einen beliebigen Namen für den Corpus. Im nächsten Schritt werden die importierten Inhalte mit Hilfe des NLP APIs annotiert und die Entitäten, welche vom gewählten NLP-Service erkannt werden, gezählt und vermerkt. Dies ist in Abbildung 4.3 dargestellt. In dem Beispiel wurde die Annotation API DBpedia- Spotlight-DE angewendet. Dabei wurden 15 Artikel erkannt und verarbeitet. In den Texten dieser Artikel wurden insgesamt 156 Entitäten erkannt.

36 4. Bedarfsanalyse 29 Abb. 4.3: context Corpus Annotation Die Erkennung von Entitäten und die geeignete Visualisierung der Zusammenhänge zwischen den Entitäten ist ein wesentliches Feature von context. Für die Visualisierung stehen verschiedene Ansichten zur Verfügung. Bei der Facettenansicht werden alle Artikel angezeigt. Bei den angezeigten Artikeln werden die erkannten Entitäten farblich gekennzeichnet. Die Facetten Ansicht ist in Abbildung 4.4 dargestellt. Der Benutzer hat bei dieser Ansicht auf der linken Seite die Möglichkeit, die Artikel nach Titeln zu filtern. Es gibt ebenso die Möglichkeit, die Ansicht nach bestimmten DBpedia-Typen wie Place, Organisation oder auch Country zu filtern. Weiter unten lässt sich die Filterung auf die erkannten Entitäten ausweiten. Der Benutzer kann zum Beispiel nur Artikel anzeigen lassen, welche die Entität Wissenschaftsstadt besitzen. Durch diese Filtermöglichkeiten ist es dem Benutzer möglich, unter einer Vielzahl von Nachrichten und Informationen, die für ihn relevanten herauszufiltern und so die Informationen mehrdimensional zu entdecken. Die Ansicht Entity relations zeigt alle entdeckten Entitäten und deren Beziehungen und Verknüpfungen zueinander. Die Ansicht Co-occurrence matrix zeigt die Co-Occurence-Matrix der Entitäten. Dabei reflektiert jede Zelle der Matrix die Grauwertematrix der Entität, abhängig von Entitätstyp und der Häufigkeit der Co-Occurence [Khalili u. a. (2014)]. In Abbildung 4.5 ist die angedachte Architektur von context abgebildet. Der Ablauf stellt sich wie folgt dar:

37 4. Bedarfsanalyse 30 Abb. 4.4: context Facetten Ansicht 1. Zu Beginn werden die Daten aus diversen Quellen gesammelt. Dazu stehen verschiedene Module zur Verfügung oder können selbst erstellt werden. 2. Anschließend werden die Daten durch die NLP-Services verarbeitet. Dazu werden die erkannten Entitäten um neue Informationen und Klassen angereichert und die Informationen der verschiedenen NLP-Services zusammengemischt. 3. Der Benutzer hat die Möglichkeit, die angereicherten Informationen in verschiedenen visuellen Zusammenstellungen zu erkunden. 4. Neben der Visualisierung ist auch eine Feedback-Funktion geplant, mit dem der Benutzer gefundene Unstimmigkeiten bei der Annotation melden kann. Es ergeben sich aus der Analyse in diesem Kapitel folgende Anforderungen an ein RDF-Backend. Die Erstellung der RDF-Ressource muss den Import aus allen Importierungsarten unterstützen. Sie muss ebenso einfach erweiterbar sein, wie das Hinzufügen neuer Importierungsarten möglich ist. Bei der Erstellung der RDF-Ressource müssen alle vorhanden NLP-Services unterstützt werden. Dabei muss die Erweiterbarkeit der NLP-Services ebenfalls unterstützt werden. Die beim erstellen des Corpus eingestellte Sprache muss berücksichtigt werden.

38 4. Bedarfsanalyse 31 Abb. 4.5: Architektur von context [Quelle: context Webseite - ]

39 4. Bedarfsanalyse Technische Umsetzung von context context basiert technisch auf Node.JS (siehe 2.2.1) und MongoDB (siehe 2.2.2). Die Architektur basiert stark auf dem Model View Controller (MVC) Architektur. Durch das MVC-Modell wird die übersichtliche und einfache Weiterentwicklung sichergestellt. Durch die fehlende Unterstützung für Klassenhierarchien der eingesetzten Programmiersprache JavaScript sieht der Aufbau des Projekts als MVC auf den ersten Blick ungewöhnlich aus. Dies lässt sich auf die Ordnerstruktur des Frameworks und der typischen Projektaufteilung von Node.JS zurückführen. Eine Übersicht der Ordnerstruktur ist in Abbildung 4.6 dargestellt. Die Ordner public und views enthalten alle für die Ansicht und die Visualisierung notwendigen Komponenten. Darunter fallen auch die benötigten HTML, CSS, Javascript und Bilddateien. Im Ordner models befinden sich die Datenbankmodelle der verwendeten collections. Die Struktur der Datenbank ist in Abbildung 4.7 dargestellt. Dabei ist zu beachten, dass es sich bei MongoDB um eine dokumentenorientierte NOSQL Datenbank handelt. Dies bedeutet, dass im Gegensatz zu relationalen Datenbanken, die collections (ähnlich wie Tabellen bei relationalen Datenbanksystemen) keine feste Struktur besitzen. Es bedeutet außerdem, dass neue Felder beliebig hinzugefügt und entfernt werden können und dass nicht alle Datensätze alle Felder besitzen müssen. Die genauere Funktionsweise der MongoDB Datenbank ist im Kapitel näher beschrieben. Die context Daten in der Datenbank sind in den drei collections users, corpuses und articles unterteilt. Für die bessere Übersicht sind im Folgenden Referenzen auf bestimmte Felder einer collection in der Form collectionname.feldname angegeben. Die collection users enthält alle für die Benutzerverwaltung benötigten Daten. Diese sind in der Tabelle 4.1 dargestellt.

40 4. Bedarfsanalyse 33 Abb. 4.6: Ordnerstruktur context [Quelle: Github,

41 4. Bedarfsanalyse 34 Abb. 4.7: MongoDB Datenbankstruktur von context Feldname _id username password first_name last_name registration_date Social_networks Beschreibung Die automatisch von MongoDB erstellte Identifikationsnummer für das Dokument. Der Benutzername des erstellten Accounts. Der Benutzername muss dabei eindeutig und einzigartig sein. Das Passwort des Benutzers in Form eines mit Salt und md5 verschlüsselter Strings. -Adresse des Benutzers Der Vorname des Benutzers Der Nachname des Benutzers Das Registrierungsdatum des Benutzers Ein Array, welches den Namen des Netzwerkes und den Benutzernamen bzw. die ID des Benutzers in diesem Netzwerk enthält. Tabelle 4.1.: Felder das collections users Es sei noch einmal darauf hingewiesen, dass bei MongoDB keine festen Tabellenstrukturen existieren und die Daten im auf JSON basierenden Format BSON gespeichert werden. So können auch Arrays mit weiteren Werten als Inhalt eines einzigen Feldes gespeichert werden. Dies geschieht im users-collection bei den Werten des Feldes Social_networks. Für jede neu importierte Quelle wird ein neuer Corpus angelegt. Darin sind die wesentlichen Einstellungen des Corpuses gespeichert. Die In corpuses collection enthaltene Felder sind in der Tabelle 4.2 dargestellt.

42 4. Bedarfsanalyse 35 Feldname _id name processed creation_date nlp_api user input input_type input_count files language Beschreibung Die automatisch von MongoDB erstellte Identifikationsnummer für das Dokument. Der vom Benutzer vergebene Name für den Corpus. Ein Boolescher Wert, der angibt, ob der Corpus bereits verarbeitet worden ist. Das Datum, an dem der Benutzer den Corpus erstellt hat. Der vom Benutzer gewählte NLP-Service für den Corpus. Mit diesem NLP- Service werden alle Artikel des Corpuses Annotiert Die ID des Benutzers, der den Corpus angelegt hat aus der users collection. Die Eingabe des Benutzers für den Corpus. Beispielsweise die URL des RSS Feeds. Der gewählte Eingabe-Typ für diesen Corpus. Wie zum Beispiel RSS Feed, Datei Upload, Wordpress Blog, Facebook etc. Die gewählte Anzahl an Elementen, die von der Eingabequelle importiert werden soll. Ein Array,welches den Dateinamen und Dateipfad der hochgeladenen Datei enthält. Die vom Benutzer gewählte Sprache für den Corpus. Tabelle 4.2.: Felder das collections corpuses Es ist zu beachten, dass das Feld corpuses.user lediglich die ID des jenigen Benutzers aus users._id enthält, der den Corpus erstellt hat und keine Referenz auf dieses Feld ist. Unter MongoDB existieren keine Fremdschlüssel-Beziehungen [MongoDB], so muss das Programm darauf achten bei Änderungen am users._id Schlüssel den entsprechenden Eintrag unter corpuses.user ebenfalls zu aktualisieren. Die collection articles enthält alle Artikel, die zu einem Corpus gehören. Bei der Importierung eines neuen Corpuses wird für jedes zu importierende Element wie beispielsweise einen Blogartikel, ein Tweet oder ein Facebook-Post jeweils ein Dokument in der articles-collection angelegt. Die in articles-collection enthaltene Felder sind in der Tabelle 4.3 dargestellt.

43 4. Bedarfsanalyse 36 Feldname Beschreibung _id Die automatisch von MongoDB erstellte Identifikationsnummer für den erstellten Artikel. uri Enthält die extrahierte URI der Originalquelle. Bei einem RSS Feed beispielsweise die URL zum Originaldokument. title Der extrahierte Titel aus dem Artikel. Die Extraktion folgt aus den entsprechenden Tags des Eingabeformates oder es enthält die ersten Zeichen des Textes. corpuses Ein Array mit den IDs aus der corpuses._id -collection. Sie Signalisiert, zu welchem Corpuses der Artikel dazugehört. Dabei kann ein Artikel zu beliebig vielen Corpuses dazugehören. annotation Enthält die Anfrage und die Antwort des NLP-Services, mit dem der Artikel verarbeitet worden ist. creation_date Das Erstellungsdatum des Originalartikels, falls vorhanden. Bei einem Blog- Post beispielsweise das Datum, an dem der Post erstellt worden ist. source Der Original-Quellcode vor der Entfernung der HTML Tags. processed Ein Boolescher Wert, der angibt, ob der Artikel schon verarbeitet worden ist. plaintext Die Zeichenkette des Artikels nach der Entfernung der HTML Tags. language Die gewählte Sprache des Benutzers für den Corpus, dem der Artikel angehört. entities Ein Array, aus den erkannten Entitäten des NLP-Services. Das Arrays kann beliebig viele Elemente enthalten. Jedes Element hat dabei eigene Entitätswerte. Diese Entitätswerte werden im Weiteren genauer beschrieben. entities.name Enthält den Namen der vom NLP-Service erkannten Entität. entities.uri Enthält den URI der vom NLP-Service erkannten Entität. Beispielsweise zur DBpedia-Ressource. entities.offset Die genaue Position bzw. den Offset der erkannten Zeichenkette vom Beginn des Textes. entities.precision Eine Fließkommaangabe darüber, wie sicher der NLP-Service ist, dass die erkannte Entität korrekt ist. entities._id Eine automatisch von MongoDB erstellte Identifikationsnummer für die Entität. entities.types Ein Array, aus erkannten DBpedia-Typen der Entität. Beispielsweise DBpedia:Company. Tabelle 4.3.: Felder des collections articles Wie bei corpuses collection ist zu beachten, dass articles.corpuses lediglich die ID des Corpuses aus corpuses._id enthält, zu dem der Artikel zugeordnet ist und keine Referenz auf dieses Feld ist. Unter MongoDB existieren keine Fremdschlüssel beziehungen [MongoDB], so muss das Programm darauf achten, bei änderungen am corpuses._id Schlüssel den entsprechenden Eintrag unter articles.corpuses ebenfalls zu aktualisieren.

44 4. Bedarfsanalyse 37 Wie aus der Analyse der von context benutzten collections hervorgeht, werden die Daten in drei collectionen gespeichert. Durch die Struktur von MongoDB kann nicht davon ausgegangen werden, dass diese Felder in jedem Dokument vorhanden sind. Ein Export als RDF-Dokument muss auf die Tatsache Rücksicht nehmen, dass manche Felder nicht vorhanden sind bzw. keinen Wert enthalten. Die nächste wichtige Anforderung für einen Export der Daten besteht darin, zwischen Feldern, welche für die interne Verwaltung von context benötigt werden und Datenwerten aus Dokumenten und collections, die für die Weitergabe von Interesse sind, zu unterscheiden. So sollte beispielsweise das Benutzerpasswort niemals exportiert und weitergegeben werden. Eine andere Anforderung aus diesem Kapitel besteht darin, im Sinne von Semantic Web die Daten in einen sinnvollen Kontext zu setzen damit Computer sie leicht verarbeiten können. Dazu müssen die Daten der collections zusammengefügt und um die nötigen Metadaten angereichert werden Anforderungsanalyse Linked open Data (LOD2) LOD2 ist ein von der Europäischen Union mitfinanziertes Projekt mit dem Ziel, die Nutzung des Webs als Plattform für Daten- und Informationsintegration zu verbessern [Jänicke] (siehe Kapitel 3.1). Mittelfristig ist eine Aufnahme der Software context zur LOD2-Tool-Sammlung geplant. So muss bereits bei der Anforderungsanalyse eines RDF-Backends auf die Voraussetzungen für eine Aufnahme im LOD2-Programm Rücksicht genommen werden. Die Anforderungen des LOD2-Softwarestacks sind unter anderem im Paper How To Contribute to the LOD2 stack [lod2] formuliert. Die in dem Dokument [lod2] formulierten Voraussetzungen sind folgende: Für eine einfache Bereitstellung und Verteilung der Pakete müssen diese als Debian Package zur Verfügung gestellt werden. Die Software-Lizenz muss einen Open Source-Ansatz haben. Diese Lizenz muss dem Endnutzer erlauben, die Software einzusetzen, zu konfigurieren und damit zu interagieren. Für einfachere Integration und Interaktion mit den verschiedenen Komponenten des LOD2- Stacks muss die Software einen SPARQL-Endpunkt bereitstellen sowie darüber Daten aufnehmen und ausgeben können. So muss bei der Erstellung des RDF-Backends auf diese Anforderungen Rücksicht genommen werden.

45 4. Bedarfsanalyse Anforderungsanalyse NLP Interchange Format (NIF) Beim Natural language Processing Interchange Format (NIF) handelt es sich um ein Format zur Weitergabe von Daten, die durch einen NLP-Tool entstanden sind. Mit dem NIF-Format soll der barrierefreie Austausch von Daten zwischen verschiedene NLP-Services und Plattformen ermöglicht und ausgebaut werden. Die Grundlagen des NIF-Formates sind im Kapitel 3.2 näher beschrieben. Wie bereits erwähnt, soll context mittelfristig in den LOD2 Software Stack aufgenommen werden, dabei erleichtert der Einsatz eines für den Datenaustausch standardisierten Formates die Interaktion mit andere Software. Außerdem sollen die internen Daten nach der Verarbeitung durch verschiedene NLP-Services ebenfalls im NIF-Format gespeichert werden [Khalili u. a. (2014)]. So bietet es sich an, dieses Format ebenfalls für den RDF-Backend zu benutzen. Das NIF-Format stellt einige Anforderungen, welche in der NLP Interchange Format (NIF) 2.0 Core Specification [Hellmann (b)] festgehalten sind. Die NIF Core Specification setzt folgende für diese Arbeit wichtigen Anforderungen: Alle Texte müssen zu einem RDF-Literal als Objekt vom Typ nif:isstring konvertiert werden. Alle Texte müssen im Unicode-Normalform C (NFC) vorliegen. Die Unicode-Normalformen definieren die Normalisierung einer Unicode-Zeichenkette [Davis und Dürst (2014)]. Die Normalisierung wird für den Vergleich und die Zählung von zwei Zeichenketten benötigt, da es oft verschiedene Schreibweisen und Kompositionen für die gleiche Zeichenkette gibt. So kann der deutsche Buchstabe ä im Unicoderaum als ein Unicodezeichen mit dem Hex-Wert U+00E4 oder als Komposition des Buchstabens a und des kombinierenden Tremas mit den Hex-Werten U U+0308 geschrieben werden. Beide Schreibweisen sind nach dem Unicode- Standard zulässig [Davis und Dürst (2014)] und beschreiben den gleichen Buchstaben, würden aber bei einem Vergleich der Hex-Werte durch einen Computer nicht das gleiche Ergebnis liefern. Normalisierungen dienen dazu, alle Zeichenketten eines Textes in ein bestimmtes Format zu überführen und dadurch einem Computer den Vergleich von Zeichenketten zu ermöglichen. Bei der Überführung zur Unicode-Normalform C (NFC) wird das Zeichen zuerst dekompositioniert und anschließend wieder kompositioniert [Davis und Dürst (2014)]. Dadurch wird das Zeichen auf seine ursprüngliche Form zurückgebracht und besitzt im Falle von ä nur den Hex-Wert U+00E4 anstelle der Komposition von zwei Hex-Werten. Bei der Normalisierung im Unicode-Normalform D (NFD) würde der Buchstabe ä aus der Komposition von zwei Unicode-Zeichen dargestellt werden. Alle Zeichenketten müssen in Unicode-Codepunkten gezählt werden. Das Zählen von Zeichenketten in Computern ist komplizierter als es auf dem ersten Blick

46 4. Bedarfsanalyse 39 den Anschein hat. Durch die Vielzahl der Standards wie ASCII, UTF-8, UTF-16 und deren Normalisierungen gibt es verschiedene Möglichkeiten, die Zeichen in einem Text zu zählen. Dies fängt schon bei der Zählung des ersten Zeichens an. So gibt es die Möglichkeit, vor dem ersten Buchstaben mit dem Zählen zu beginnen, sodass das erste Zeichen im Text als Zeichen mit der Position 1 gezählt wird. Ebenso ist es auch möglich, mit dem ersten Zeichen zu beginnen, sodass das erste Zeichen die Position 0 hat. Das NIF-Format verlangt, dass das Zählen vor dem ersten Buchstaben beginnt [Hellmann (b)]. Auch die Zählung der Tabstopps kann ein Problem darstellen, wenn unklar ist, ob diese als ein Zeichen, als vier oder als 5 Leerzeichen gezählt werden sollen. Ein weiteres Problem besteht bei der Zählung von Leerzeichen zwischen Wörtern. In manchen Methoden wird nur das erste Leerzeichen nach einem Wort gezählt und die weiteren Leerzeichen bis zum Anfang des nächsten Wortes ignoriert. NIF verlangt in dem Fall, dass alle Leerzeichen zwischen zwei Wörtern mitgezählt werden. Ebenso wichtig für die Zählung ist die oben angegebene Unicode-Normalform C. Falls der Buchstabe ä aus der Komposition von zwei Unicode-Zeichen besteht, wäre der Buchstabe bei einer Zählung 2 Zeichenlang. Bei der NFC-Form ist sie lediglich 1 Zeichen lang. So verlangt NIF, dass die Zeichen im Text als Unicode Punkte gezählt werden [Hellmann (b)]. Ein weiteres Beispiel für Komplikationen bei der Zählung von Zeichen sind Zeilenumbruchzeichen. Unter Windows werden Zeilenumbrüche mit den Symbolen \r \n kodiert unter Unix-Systemen wird der Zeilenumbruch lediglich durch das Symbol \n kodiert. Dies führt dazu, dass bei der Zählung von Unicode-Points ein Zeilenumbruch unter Windows zwei Zeichen hat und unter Linux nur ein Zeichen. NIF verlangt, dass alle Zeichen beim Zeilenumbruch gezählt werden [Hellmann (b)]. Dazu verlangt die NIF-Spezifikation, dass der derjenige, der die Implementierung vornimmt die Ausgabe seines Programmes mit dem NIF-Validation-Tool validiert. Die RDF-Ausgabe aller NIF-Implementationen muss nach dem auf der Homepage der NIF- Spezifikationen befindlichen Validator ein gültiges NIF-Dokument darstellen. [Hellmann (b)]. Für jedes nif:context welches aus einem anderen nif:context stammt, muss der derjenige, der die Implementierung vornimmt einen nif:wasconvertedfrom Herkunftslink angeben [Hellmann (b)].

47 4. Bedarfsanalyse Anforderungen Datenbank context setzt bei der Speicherung der Daten auf die NOSQL-Datenbank MongoDB. Beim MongoDB handelt es sich um eine dokumentenbasierte Datenbank. Diese setzt für die Speicherung der Daten auf das JSON-basierte Format BSON. Die Grundlagen von MongoDB sind im Kapitel beschrieben. Die MongoDB-Datenbank speichert Daten in Form von Schlüssel:Wert (englisch key:value). Dies unterscheidet sie von üblichen Triple-Store-Datenbanken, die auf das Speichern von RDF-Triple spezialisiert sind. So ist eine weitere Anforderung an die Datenbank für das RDF-Backend, dass sie die Speicherung von RDF-Triple erlaubt. Andernfalls soll eine geeignete Form für die Speicherung der RDF-Triple in MongoDB gefunden werden. Eine innerhalb der LOD2 Anforderungen formulierte Voraussetzung für die Aufnahme im LOD2 Software Stack verlangt, dass die Software einen SPARQL-Endpoint besitzt. Die einzusetzende Datenbank muss die SPARQL-Abfragesprache nativ unterstützen oder eine Möglichkeit bieten, die Daten über das SPARQL Protokoll abzufragen. Die Informationen sollen jederzeit aus context heraus hinzugefügt oder verändert werden können. Da dies durch die Vielzahl der Dokumente in context nicht manuell möglich ist, ist eine weitere Anforderung an eine Datenbank für ein RDF-Backend, dass sie die Möglichkeit bietet, RDF-Dokumente im Allgemeinen und im Besonderen NIF-Dokumente automatisch importieren zu können. <TODO: Entscheiden ob alle SPARQL-Endpoint Kursiv oder normal geschrieben werden, ebenso so Node.JS und MongoDB> 4.5. Sicherheitsanforderungen context ist als Software innerhalb von LOD2 Stack aber ebenfalls auch als Webplattform geplant. Zusätzlich wird context als eine Open Source Software vertrieben. Jeder soll es einsetzen und an seine Bedürfnisse anpassen können. Ein RDF-Export, mit dem die Daten aller Benutzer exportiert werden können, stellt für eine solche Plattform ein erhebliches Sicherheits- und Datenschutzrisiko dar. Ein RDF-Export wird für die meisten Endnutzer ohne Kenntnisse im Semantic Web, die die Zielgruppe von context darstellen, von geringem Nutzen sein. Der RDF-Export richtet sich hauptsächlich an Forscher und Entwickler, welche die Daten exportieren und mit anderen Programmen weiter bearbeiten möchten. Aus dieser Sicht ist es offensichtlich, dass der RDF-Export nicht für alle Installationen zur Verfügung zu stehen braucht. So ist es eine weitere Anforderung an das RDF-Backend, dass der Export von Daten bei Bedarf deaktiviert werden kann.

48 4. Bedarfsanalyse 41 Ebenso wie der RDF-Export, stellt der SPARQL-Endpoint ein Sicherheits- und Datenschutzrisiko dar. Durch den SPARQL-Endpoint ist es möglich, beliebige Daten aus den Dokumenten aller Benutzer abzurufen. Durch die SPARQL-Abfragen, die eine zielgerichtete Abfrage und Auswertung ermöglichen, wird dieses Problem noch weiter verschärft. Daraus ergibt sich eine weitere Anforderung an das RDF-Backend. Es muss ebenfalls möglich sein, den Zugriff auf den SPARQL-Endpoint zu sperren, bzw. den SPARQL-Endpoint gänzlich zu deaktivieren. Ein weiteres Sicherheitsrisiko, das durch ein RDF-Backend bzw. durch einen SPARQL-Endpoint entsteht, ist die Veränderung der Dokumente in der Datenbank. Die Abfragesprache SPARQL unterstützt die Veränderung der Daten durch Queries. Ein Angreifer kann diese Möglichkeit nutzen, um das System mit dem SPARQL-Endpoint anzugreifen. Er könnte im Fall von Vandalismus alle Datenbankeinträge aus der Datenbank löschen. Ausgefeiltere Angriffe könnten gezielt Daten in der Datenbank verändern, um die Ergebnisse einer Abfrage zu verfälschen und so dem Benutzer falsche Ergebnisse liefern. Ebenso könnte er beliebig eigene Daten in die Datenbank injizieren. Ein SPARQL-Endpoint ist im Falle von context nur zur Abfrage der vorhandenen Daten gedacht und nicht zum Hinzufügen neuer Daten. Daraus ergibt sich die weitere Anforderung, dass SPARQL-Befehle, welche die Daten in der Datenbank verändern, deaktiviert werden Zusammenfassung der Anforderungen In den vorherigen Abschnitten wurden die Anforderungen an ein RDF-Backend formuliert. Diese werden hier in einer nummerierten Liste zusammengefasst, um einen Gesamtüberblick über das System zu geben und die Anforderungen in einer übersichtlichen Form darzustellen, auf die später verwiesen wird. 1. Das RDF-Backend muss den Import aus allen Importierungsarten unterstützen. 2. Das RDF-Backend muss das Hinzufügen neuer Importierungsarten unterstützen. 3. Das RDF-Backend muss alle vorhanden NLP-Services unterstützen. 4. Das RDF-Backend muss das Hinzufügen neuer NLP-Services unterstützen. 5. Das RDF-Backend muss die beim Erstellen der Ressource gewählte Sprache unterstützen. 6. Beim Export von Artikeln muss darauf Rücksicht genommen werden, dass einige Felder leer sein können. 7. Das RDF-Backend muss die für Datenweitergabe benötigten Felder identifizieren und in geeigneter Form annotieren und exportieren können. 8. Das RDF-Backend muss die zu exportierenden Felder mit den nötigen Metainformationen annotieren und dann exportieren können.

49 4. Bedarfsanalyse Für eine einfache Bereitstellung und Verteilung der Pakete muss es möglich sein, context als Debian Packet zur Verfügung zu stellen. 10. Die Software-Lizenz muss einen Open-Source-Ansatz haben. 11. context muss einen SPARQL-Endpoint zur Verfügung stellen. 12. Alle Texte im RDF-Backend müssen zu einem RDF-Literal als Objekt vom Typ nif:isstring konvertiert werden können. 13. Alle Texte müssen in Unicode-Normalform C (NFC) vorliegen. 14. Alle Zeichenketten im Text müssen in Unicode-Codepunkten gezählt werden. 15. Die RDF-Ausgabe aller NIF-Implementationen muss nach dem auf der Homepage der NIF- Spezifikationen befindlichen Validator ein gültiges NIF-Dokument darstellen. 16. Für jedes nif:context, welches aus einem anderen nif:context stammt, muss der der die Implementierung vornimmt, einen nif:wasconvertedfrom Herkunftslink angeben. 17. Die verwendete Datenbank muss das Speichern von RDF-Triplen erlauben. 18. Die einzusetzende Datenbank muss die SPARQL-Abfragesprache nativ unterstützen oder eine Möglichkeit bieten, die Daten über SPARQL abzufragen. 19. Die Datenbank muss RDF-Dokumente automatisch importieren können. 20. Der RDF-Export muss deaktivierbar sein. 21. Der SPARQL-Endpoint muss deaktivierbar sein. 22. Die Benutzung von SPARQL-Befehlen, welche Daten in der Datenbank verändern, darf nicht möglich sein.

50 Teil V. Design Entscheidungen

51 5. Design Entscheidungen Ausgehend von der Analyse von context im vorangegangenen Kapitel und den daraus abgeleiteten Anforderungen an ein RDF-Backend wird in diesem Kapitel das Konzept für eine Lösung beschrieben. Wie sich im vorherigen Kapitel abgezeichnet hat, sind bei der Entwicklung einer Lösung, die sich nahtlos ins Programm einfügt und nicht als externes Modul wahrgenommen wird, viele Anforderungen und Voraussetzungen zu beachten. Zudem ist die aktuelle Version von context noch in der Entwicklung. So können sich die Datei- und Systemstrukturen entsprechend noch ändern. Im Verlauf der Entwicklung musste auf die Veränderungen im System Rücksicht genommen werden. Auf diese Weise kam die zusätzliche Anforderung auf, dass das zu entwickelnde System möglichst robust und erweiterbar gegenüber Veränderungen in der Software sein soll. Für die Entwicklung eines RDF-Backends müssen einige Designentscheidungen bezüglich einzusetzender Komponenten, Frameworks und der Architektur getroffen werden. Diese sind mit ihren Alternativen sowie den Pro- und Kontra-Argumenten für jede Entscheidung beschrieben Auswahl der Datenbank und Framework Die resultierende Lösung muss über einen SPARQL-Endpoint verfügen, welcher über eine REST API erreichbar ist. Die Datenbank muss die Speicherung von RDF-Triple und Abfragen über das SPARQL Protokoll erlauben. Diese Anforderungen wurden im vorherigen Kapitel wie folgt und mit der angegebenen Nummer formuliert: 11. context muss einen SPARQL-Endpoint zur Verfügung stellen. 17. Die verwendete Datenbank muss das Speichern von RDF-Triplen erlauben. 18. Die einzusetzende Datenbank muss die SPARQL-Abfragesprache nativ unterstützen oder eine Möglichkeit bieten, die Daten über SPARQL abzufragen. 19. Die Datenback muss RDF-Dokumente automatisch importieren können. So muss als erstes eine Entscheidung über die zu benutzende Datenbank und das zu benutzende Framework getroffen werden. Die Wahl der Datenbank und das Framework stellen eine grundlegende Designentscheidung dar. Diese Entscheidung stellt die Weichen für die weitere Systemarchitektur. Aus diesem Grund muss diese Entscheidung zu Beginn getroffen werden. Zu unterscheiden sind zwei grundsätzliche Möglichkeiten: 1. Die Benutzung der Triplestore-Datenbank Openlink Virtuoso Server [virtuoso]. 2. Die Benutzung der Datenbank MongoDB mit einem entsprechenden Framework innerhalb von NodeJS für den Betrieb als Triplestore-Datenbank.

52 5. Design Entscheidungen Openlink Virtuoso Server Beim Openlink Virtuoso Server handelt es sich um einen Multiprotokoll-Server, welcher unter anderem Unterstützung für RDF und SPARQL bietet [virtuoso]. Virtuoso ist ebenfalls im LOD2 Software Stack integriert [virtuoso-lod2]. Virtuoso als Datenbank hat einige Vorteile. Sie ist auf die Benutzung als Triple Store spezialisiert und bietet zahlreiche Möglichkeiten für den Import von Daten, sodass sie die in Anforderung 17 geforderte Speicherung von RDF-Triplen erfüllen kann. Unter anderem wird der Import über das HTTP-Post-Protokoll oder auch über den SPARQL LOAD Befehl unterstützt [virtuoso-rdf]. So kann sie, die in Anforderung 19 geforderte, automatische Importierung der RDF-Dokumente umsetzen. Virtuoso besitzt zudem eine ausgereifte und fein abstimmbare Rechte- und Benutzerverwaltung. Sie unterstützt außerdem zahlreiche Ausgabeformate, mit denen größere Interoperabilität erreicht werden kann [virtuoso-features]. SPARQL-Abfragen und die Administration der Datenbank sind zusätzlich über ein Webinterface und einen REST-Service erreichbar. Damit ist die in Anforderung 11 und 18 formulierte Unterstützung nach SPARQL-Anfragen erfüllt. Durch die vollständige Integration im LOD2 Software Stack ist der Installations- und Wartungsaufwand innerhalb des LOD2-Projektes nach der Aufnahme von context zur LOD2 Stack sehr gering. Jedoch ist context nicht nur als eine Software innerhalb des LOD2 Stacks geplant, sondern soll auch als Stand-Alone Software den Benutzern zur Verfügung stehen. Die Installation einer weiteren Software-Komponente und deren korrekte Konfiguration und Wartung kann viele Interessenten vor der Verwendung von context abschrecken. Derzeit ist für die Installation von context nur die Installation und Konfiguration von Node.JS und MongoDB notwendig. Alle noch benötigten Module werden durch die Node.JS Paketverwaltung installiert. Diese einfache Installation würde durch die Benutzung von Virtuoso verloren gehen. Des Weiteren kann die Änderung der Eingabe-API nach dem Erscheinen einer neuen Version von Virtuoso zu Inkompatibilitäten führen, welche weiteren Wartungsaufwand in context nach sich ziehen MongoDB mit RDF Store JS Die Alternative zu Open Link Virtuoso besteht darin, die von context für die interne Datenverwaltung verwendete Datenbank MongoDB in Verbindung mit dem JavaScript-Framework RDF Store JS [Langanke] zu Nutzen. Bei RDF Store JS handelt es sich um eine JavaScript Implementation eines RDF-Triplestores mit SPARQL Support.

53 5. Design Entscheidungen 46 RDF Store JS hat den großen Vorteil, dass sie bereits in der Paketverwaltung von Node.JS integriert ist und automatisch bei der Installation von context mitinstalliert werden kann. Zu dem speichert RDF Store JS die anfallenden Triple in einer MongoDB-Datenbank, womit sie die aufgestellte Anforderung 17 über die Speicherung von RDF-Triple erfüllt. RDF Store JS bietet ebenfalls die Möglichkeit einen SPARQL-Endpoint zu implementieren. Damit erfüllt sie ebenfalls die aufgestellte Anforderung, über das Anbieten eines SPARQL-Endpoints, mit der Nummer 11. RDF JS Store unterstützt die SPARQL 1.0 Spezifikation vollständig und die wichtigsten Befehle der SPARQL 1.1 Spezifikation [Langanke]. Damit erfüllt sie die aufgestellte Anforderung 18 über die Unterstützung von SPARQL-Abfragen. Durch die direkte Integration innerhalb von Node.JS bietet RDF JS Store zu dem eine JavaScript High level API an, die innerhalb des context Programmcode benutzt werden kann. Damit lässt sich die in Anforderung 19 geforderte automatische Importierung umsetzen. Durch die Benutzung von Node.JS und MongoDB als Datenbank ist die Installation, Konfiguration und Wartung von zusätzlicher Software nicht erforderlich. Alle wichtigen Komponenten werden durch die Node.JS Paketverwaltung installiert und gewartet. Außerdem müssen interessierte Benutzer sich nicht in eine neue Software einarbeiten. Zusätzlich kann bei der Deklaration des Modules innerhalb von NodeJS festgelegt werden, welche Version von RDF Store JS installiert wird. Damit lassen sich Inkompatibilitäten bei unterschiedlichen Benutzern und Versionen der verwendeten Pakete vermeiden Entscheidung über die Wahl der Datenbank Sowohl Virtuoso als auch RDF Store JS erfüllen die aufgestellten Anforderungen an eine Datenbanklösung. Mit beiden Systemen ist es möglich, RDF-Triples zu speichern und über einen SPARQL-Endpoint die gespeicherten Informationen abzufragen. Wenn context ausschließlich innerhalb des LOD2 Stacks arbeiten soll, ist Virtuoso die bessere Wahl da es im Softwarestack zur Verfügung steht und bereits von einer Vielzahl von Programmen innerhalb des LOD2 Stacks verwendet wird. Die Benutzerverwaltung würde es ermöglichen, den Zugriff der Benutzer auf die Daten detailliert fest zu legen. Jedoch ist context als Stand-alone Programm geplant, damit interessierte Nutzer es einfach nutzen und auf ihre Bedürfnisse anzupassen können. Die Voraussetzung für die Installation von weiterer Software würde eine unnötige Hürde darstellen. Zudem kommt noch hinzu, dass es nach der endgültigen Veröffentlichung der JSON/LD Spezifikation, welches gänzlich mit dem JSON

54 5. Design Entscheidungen 47 Format kompatibel ist (siehe Kapitel ), damit zu rechnen ist, dass langfristig die Datenbank MongoDB eine native Unterstützung für RDF-Triple und SPARQL-Abfragen erhält. Darüber hinaus lassen sich durch die Angabe der RDF Store JS Version, die zu installieren ist, Inkompatibilitäten bei der Betreibung des RDF-Backends und SPARQL-Endpoints vermeiden. Aus den oben genannten Gründen wurde die Entscheidung getroffen, RDF Store JS in Verbindung mit MongoDB als Datenbanksystem einzusetzen. Trotz dessen wurde bei der Implementierung darauf geachtet, dass ein Wechsel der Datenbank leicht möglich ist Importierungsarten Die Möglichkeit context bei Bedarf leicht um neue Funktionen zu erweitern wurde von Beginn an bei der Entwicklung berücksichtigt. So ist die Plattform modular aufgebaut. Derzeit unterstützt context 9 verschiedene Formate, wie neue Daten hinzugefügt werden können. Diese sind RSS Feeds, Wordpress Blogs, Blogger Blogs, Twitter, SlideWiki, Webseite, direkte Eingabe, Dateiupload und Turtle-Dokumente. Die Ansicht zum Hinzufügen neuer Daten ist in Abbildung 5.1 dargestellt. In den Anforderungen an einen RDF-Backend ist in der 1. Anforderung die Unterstützung aller dieser Importierungsarten gefordert. Zudem ist in der 2. Anforderung die Unterstützung neuer Importierungsarten gefordert. So muss eine Lösung gefunden werden, um beiden Anforderungen zu genügen. Wie man an den verschiedenen Importierungsarten in der Abbildung 5.1 erkennt, besitzen sie sehr unterschiedliche Datenstrukturen. So besteht ein RSS-Feed aus eine XML-Datei, während das Importieren der Twitter Tweets als JSON-Datei implementiert ist. Es ist nicht möglich Voraussagen über den Inhalt einer hochgeladenen Datei zu machen. Die Herausforderung besteht darin, eine Möglichkeit zu finden, um alle vorhandenen und zukünftigen Importmöglichkeiten zu unterstützen. Eine Möglichkeit besteht darin, für die vorhandenen Importierungsmöglichkeiten jeweils eine eigene callback Funktion zu implementieren, welche beim Hinzufügen der Daten, wie zum Beispiel eines RSS Feeds, aufgerufen wird und die Rohdaten abgreift. Die Daten ließen sich so für das RDF-Backend verwenden. Diese Möglichkeit hat den großen Nachteil, dass für jede Importierungsart eine eigene, auf sie angepasste Callback Funktion erstellt werden muss. Dies erhöht den Wartungsaufwand, da bei jede Änderung der Importierungsart auch die dazugehörige Callback Funktion modifiziert werden muss. Zudem ist es notwendig, beim Erstellen einer neuen Importierungsart eine entsprechende Callback Funktion für das RDF-Backend zu erstellen. Dies führt zu erhöhtem Aufwand bei der Erstellung einer neuen Importierungsart und erhöht wiederum den Wartungsaufwand.

55 5. Design Entscheidungen 48 Abb. 5.1: context - Ansicht zur Erstellung eines neuen Corpus Eine andere Möglichkeit, wird bei der genaueren Analyse des in Abbildung 5.2 dargestellten Datenbankschemas von context deutlich. So ist daraus zu erkennen, dass alle Eingabemöglichkeiten auf die collections corpuses und articles abgebildet werden. Dazu wird die Eingabe, je nach Eingabeart von dem entsprechenden Eingabeparser verarbeitet und die Inhalte in den entsprechenden Datenbankfeldern gespeichert. So wird unabhängig der Eingabeart, der Title der Eingabe im Feld articles.title und die Eingabe selbst in articles.source gespeichert. Durch diese Herangehensweise wird ebenfalls sichergestellt, dass das Ergebnis als RDF die Intentionen des Modulentwicklers widerspiegelt, da dieser genaue Kenntnisse über die Datenstruktur und den Aufbau der Eingabequelle besitzt. Ein Anpassung das RDF-Backends ist demnach nur bei Veränderung des Datenbank Datenmodells notwendig. Zusammengefasst kann gesagt werden, dass durch die ausschließliche Benutzung der gespeicherten Informationen aus den Datenbankfeldern sichergestellt werden, dass das RDF-Backend alle vorhandenen Eingabearten und darüber hinaus alle zukünftigen Eingabearten, bei denen das Datenbankmodell nicht verändert wird, unterstützt. Damit sind die Anforderungen 1 und 2 an das RDF-Backend erfüllt.

56 5. Design Entscheidungen 49 Abb. 5.2: context - Datenbankschema bestehend aus den collections users, corpuses und articles 5.3. NLP-Services Die Möglichkeit, context leicht um neue Module zu erweitern, wurde auch bei der Implementierung der NLP-Services berücksichtigt. context bietet derzeit die NLP-Services DBpedia Spotlight [Mendes u. a. (2011)] in 9 unterschiedlichen Sprachen und das Federated knowledge extraction Framework (FOX) [Ngomo u. a. (2011)] an. Außerdem lässt es sich leicht um neue Dienste erweitern. In den Anforderungen für ein RDF-Backend wird in der Anforderung Nr. 3 die Unterstützung aller vorhandenen NLP-Services gefordert, zusätzlich wird in der Anforderung 4 gefordert, dass später hinzugefügte NLP-Services unterstützt werden sollen. Eine andere nicht als Anforderung geforderte, jedoch bei der Erstellung des Konzeptes zu berücksichtigende Funktion ist die Ausführung verschiedener NLP-Services auf den gleichen Artikel. Durch die Ausführung von verschiedenen NLP-Services wie beispielsweise den beiden derzeit vorhanden, DBPedia Spotlight und FOX auf einen Artikel, ist es möglich, neue Entitäten zu entdecken oder auch bessere Annotationen für die vorhanden Entitäten zu erhalten. Diese Funktion ist derzeit nicht in context implementiert, aber es ist davon auszugehen das es in naher Zukunft implementiert wird. So muss diese Arbeitsweise ebenfalls bei der Unterstützung der NLP-Services berücksichtigt werden. Ähnlich wie bei den Importierungsarten (siehe 5.2) wäre es möglich, eine eigene Callback Funktion für jeden NLP-Service zu erstellen, welche nach der Annotation durch den NLP-Service aufgerufen wird. Dies hätte den Vorteil, dass das RDF-Backend Zugriff auf alle Rohdaten des NLP-Dienstes hat. Jedoch hat diese Möglichkeit, ähnlich wie bei den Importierungsarten, den großen Nachteil, dass für jeden NLP-Service eine entsprechend angepasste Funktion bereitgestellt werden muss. Dies erhöht den Wartungsaufwand, da bei jeder Änderung des NLP-Services

57 5. Design Entscheidungen 50 die Callback Funktion ebenfalls geändert werden muss. Außerdem erhöht das Einbinden einer solchen Callback Funktions den Aufwand für die Erstellung eines neuen NLP-Services. Eine andere Möglichkeit ergibt sich bei der Analyse des in Abbildung 5.2 abgebildeten Datenbankschemas. So ist aus der Abbildung zu erkennen, dass das Feld articles.entites selbst aus einem Array aus fünf Elementen besteht. Dabei wird für jede durch den NLP-Service erkannte Entität im Artikel ein Array, bestehend aus dem Namen, Typen, URI, Offset und Genauigkeitsgrad der Erkennung erstellt. Dabei besteht das Typenfeld selbst wieder aus einem Array mit den erkannten NLP-Service typen der Entität wie Agent, Organisation oder Company. Es sei noch einmal darauf hingewiesen, dass in MongoDB anders als in relationalen Datenbanken, die Speicherung von einem Array als Wert eines Feldes möglich ist. Unter articles.entites.name wird der vom NLP-Service erkannte Name oder die erkannte Stammform der Entität wie zum Beispiel Universität Bonn gespeichert. Als articles.entites.uri wird die eindeutige Identität der erkannten Entität wie zum Beispiel gespeichert. Als articles.entites.offset wird die Position der erkannten Entität im Text als Abstand zur Textanfang gespeichert. So ist zu erkennen, dass alle für das RDF-Backend wichtigen Informationen im Feld articles.entites gespeichert werden, da alle Daten aus verschiedenen NLP-Services zu diesen Feldern gemappt werden. Damit ist es möglich, ohne Kenntnisse über den Aufbau des NLP-Services diese Daten für das RDF-Backend zu nutzen, ohne eine Anpassung für jeden NLP-Service vorzunehmen. Dies gilt so lange, dass das dahinterstehendes Datenmodell nicht verändert wird. Für das RDF-Backend ist es demnach auch unerheblich, aus welcher und auch ob die Daten aus unterschiedlichen NLP-Services gewonnen worden sind. So wurde aus den oben genannten Gründen entschieden, die Unterstützung der verschiedenen NLP-Services durch die Benutzung des Datenbankfeldes articles.entites zu gewährleisten Datenstruktur für die Überführung in ein RDF-Dokument In diesem Abschnitt werden die für das RDF-Backend gewählte Felder und die gründe für deren Auswahl näher erläutert. Zu dem wird das Mapping auf das geeignete Vokabular beschrieben. Für eine bessere Übersicht, sind die collections mit dem Datenmodell von context aus dem letzten Kapitel hier noch einmal abgebildet. Eine weitere Herausforderung bei der Erstellung eines RDF-Backends ist die konkrete Identifizierung der für das RDF-Backend relevanten Felder. So muss zwischen Feldern für die interne Datenverwaltung und konkreten Informationen entlastenden Feldern unterschieden werden. Dabei muss die Sicherheit des Systems und der Benutzer ebenso berücksichtigt werden,

58 5. Design Entscheidungen 51 wie das Interesse daran möglichst viele und genaue Daten weiterzugeben. Darunter fällt beispielsweise, dass die Benutzerpasswörter nie weitergegeben werden dürfen. In den Anforderungen aus dem letzten Kapitel wurden die Anforderungen an ein solches Vorgehen gestellt. In der Anforderung Nummer 7 wurde die Identifizierung und in der Anforderung 8 die Annotation mit zusätzlichen Metainformationen gefordert. Das Hinzufügen der neuen Metainformationen geschieht, in dem die Daten in ein geeignetes Vokabular überführt werden. In der Anforderung Nummer 5 wurde formuliert, dass die beim der Erstellung des corpuses gewählte Sprache auch bei deren Exportierung unterstützt werden soll. Die Anforderung 6 fordert, dass auch auf die Möglichkeit, dass einige Felder nicht existieren oder keinen Inhalt besitzen, Rücksicht genommen werden muss. Es sei darauf hingewiesen, dass es durch die dokumentenbasierten Struktur von MongoDB möglich ist, dass bestimmte Felder nicht existieren. Denn im Gegensatz zu relationalen Datenbanken können bei MongoDB die Felder jedes Dokumentes in eine collection variieren. In diesem Abschnitt werden die für das RDF-Backend gewählten Felder und die Gründe für deren Auswahl näher erläutert. Zudem wird das Mapping auf das geeignete Vokabular beschrieben. Für eine bessere Übersicht, sind die Tabellen mit dem Datenmodell von context aus Kapitel hier noch einmal in der Abbildung 5.3 abgebildet. Abb. 5.3: MongoDB Datenbankstruktur von context Für die Ausgabe als RDF-Dokument wurde das Natural Language Processing Interchangeformat (NIF), das für die Weitergabe von NLP-Daten entwickelt wurde ausgewählt (siehe Kapitel 3.2). Als Vokabular kommt das weitverbreitete Dublin Core Schema, das zur Beschreibung von Internet-Ressourcen verwendet werden kann, zum Einsatz [dublindcmi]. Dabei wird die derzeit

59 5. Design Entscheidungen 52 neueste Fassung das Dublin Core vom verwendet. Als deutsche Übersetzung wird die von der deutschen Nationalbibliothek herausgegebene deutsche Übersetzung des Dublin Cores verwendet [Frodl Christine]. Die articles collection ist die für den RDF-Export relevanteste, denn in dieser collection sind die meisten für den Export relevanten Daten gespeichert. Diese werden nachfolgend beschrieben sowie die Gründe für deren Aufnahme zur Exportierung und dass dazugehörige Mapping auf den standardisierten Vokabular. articles._id Diese von MongoDB automatisch erstellte Identifikationsnummer ist einmalig und kann systemweit zur Identifizierung des Artikels verwendet werden. Sie besteht aus Kleinbuchstaben und ist in Hexadezimal kodiert [Mongodb Object ID]. Durch die Einmaligkeit, mit der eine systemweite Identifizierung möglich ist, kann sie zur eindeutigen Markierung des Artikels innerhalb eines RDF-Dokumentes verwendet werden. Dazu bietet Dublin Core den Term identifier an. Sie ist wie folgt definiert [Frodl Christine]: Eine eindeutige Referenz auf die Ressource innerhalb eines gegebenen Kontexts. Das Feld _id ist eine eindeutige Referenz auf die Ressource innerhalb des Programmes context und kann als identifier verwendet werden. articles.uri Das Feld uri enthält die extrahierte URL der Original quelle. Zum Beispiel enthält sie bei einem RSS-Feed der Pressemitteilungen der Universität Bonn, die genaue URL zu eine Pressemitteilung. Die NIF Core Ontology [Hellmann (a)] hält für diese Ressource den Term sourceurl bereit. Sie ist als URL aus dem der Kontext extrahiert wurde definiert, welcher auf das Feld articles.uri zutrifft. articles.title articles.title ist der aus der Eingabe extrahierte Titel. Die Extraktion des Titels erfolgt innerhalb des für die Eingabeart zuständigen Modules. Sowohl Dublin Core als auch die NIF-Ontology bieten einen Titel Term mit gleichen Eigenschaften an. Der Titel Term wird dabei als ein Namen für die Ressource definiert [Hellmann (a)] [Frodl Christine]. Für eine einfachere Verarbeitung bei der Weitergabe der exportierten RDF-Dokumente wird in dem Fall der nif:title Term verwendet. articles.corpuses Jeder Artikel kann sich in beliebig vielen Corpuse befinden. In diesem Feld sind die ObjektIds der Corpuse, denen der Artikel zugeordnet ist, als Array aus den ObjektIds gespeichert. Durch das Hinzufügen dieser Eigenschaft zum RDF-Dokument lässt sich im Nachhinein die Zugehörigkeit eines Artikels zu einem Corpus ableiten. Zudem kann per SPARQL-Abfrage der Suchbereich auf einen bestimmten Corpus reduziert werden. Demnach ist die Exportierung dieser Eigenschaft sinnvoll.

60 5. Design Entscheidungen 53 Das Dublin Core Vokabular stellt dafür den Term ispartof bereit. Der Term ispartof wird als Ressource, in dem die beschriebene Ressource inkludiert ist definiert [dublindcmi]. So ist -wie bereits beschrieben- ein Artikel Teil eines corpuses und erfüllt die Voraussetzung für diesen Term. Als Wert enthält der Term ispartof die URI des corpuses. articles.annotation Dieses Feld enthält die Rohanfragen an den NLP-Service und die Rohantwort des NLP- Services. Der Inhalt und der Aufbau dieses Feldes unterscheiden sich je nach verwendetem NLP-Service. Zudem werden keine in diesem Feld gespeicherten Informationen für die Weiterbearbeitung durch context verwendet. Demnach ist der Inhalt dieses Feldes als interne Datenmenge zu werten und wird nicht in das RDF-Dokument aufgenommen. articles.creation_date Das Feld enthält das Erstellungsdatum des Artikels. Der Inhalt dieses Feldes wird durch das bei der corpus Erstellung verwendete Eingabeart-Modul bestimmt. Die Aufnahme in das RDF-Dokument ist sinnvoll. Zu diesem zweck wird der Dublin Core Term created mit dem Datentyp date verwendet. articles.source Das Feld enthält die Eingabe in Rohform. Dabei kann es sich um Klartext, HTML oder ein beliebiges Format handeln. Für die Weiterverarbeitung und Überprüfung der Ergebnisse ist das Einfügen der ursprünglichen Eingabe notwendig, weshalb sie im RDF-Dokument aufgenommen wird. Die NIF Ontology bietet den Term wasconvertedfrom an. Jedoch muss beim wasconvertedfrom Term der genaue Ursprung angegeben werden. Im Falle von HTML bedeutet dies, dass der entsprechende XPATH mit angegeben werden muss. context benutzt jedoch reguläre Ausdrücke für die Bearbeitung von HTML-Texten, sodass dieser Term nicht benutzt werden kann. Stattdessen bietet das Dublin Core den weitergefassten Term source an. Source ist als eine verwandte Ressource, von der die beschriebene Ressource abgeleitet ist definiert. Somit wird der Dublin Core Term verwendet. articles.processed articles.processed sagt aus, ob der Artikel bereits annotiert worden ist. Es werden nur RDF-Dokumente aus bereits annotierten Artikeln erstellt. Aus diesem Grund ist der Inhalt dieses Feldes für das RDF-Dokument nicht von Bedeutung. articles.language articles.language enthält den bei der corpus-erstellung gewählte Sprache. Dazu bietet Dublin Core den language Term an, welcher beim Erstellen des RDF-Dokuments verwendet wird. Als Datentyp wird das in RFC 4646 [Phillips und Davis (2009)] definierte Format

61 5. Design Entscheidungen 54 verwendet. Falls keine Sprache angegeben ist, wird der RFC 4646 [Phillips und Davis (2009)] folgend auf die Angabe und (undefined) verzichtet und das Feld nicht exportiert. articles.entities Besteht aus einem Array von Entitäten. Die Werte des Arrays werden im RDF-Dokument übernommen. articles.entities.name Enthält den Namen der vom NLP-Service erkannten Entität. Die NIF-Ontology bietet dafür den Term anchorof an die, dafür verwendet wird. articles.entities.uri Enthält den URI, der vom NLP-Service erkannten Entität. Das Internationalization Tag Set Ontology [Lewis u. a. (2013)] bietet dafür den Term taidentref an welcher für das RDF-Dokument benutzt wird. articles.entities.offset Enthält die genaue Position bzw. den Offset der erkannten Zeichenkette vom Anfang des Textes. Die NIF-Ontology bietet dazu die Terme beginindex und endindex an. Diese werden verwendet. Die Eigenschaft endindex wird durch den Zahl beginindex plus Wortlänge berechnet. articles.entities.precision Die ist eine Fließkommaangabe darüber, wie sicher der NLP-Service ist, dass die erkannte Entität korrekt ist. Für diese Eigenschaft wird das beim Internationalization Tag Set Ontology [Lewis u. a. (2013)] definierte taconfidence Element verwendet. articles.entities.id articles.entities.id enthält eine automatisch von MongoDB erstellte Identifikationsnummer für die Entität. Dies kann dazu benutzt werden, um die Entität eindeutig zu identifizieren. So wird ebenfalls der Dublin Core Term identifier für die Kennzeichnung der Entität verwendet. articles.entities.types Dies enthält ein Array aus den erkannten Entitättypen, zu dem die Entität dazu gehört, wie zum Beispiel Organisation, Ort, Firma. Für diese Eigenschaft wird die das Internationalization Tag Set Ontology [Lewis u. a. (2013)] definierte taclassref Element verwendet.

62 5. Design Entscheidungen 55 Aus den collections corpuses und users werden nur wenige Felder für das RDF-Dokument verwendet, da die meisten Felder nur für die interne Datenverwaltung benutzt werden. So werden nachfolgend nur die benutzten Felder genauer erläutert. corpus.creation_date Dies enthält das Erstellungsdatum des Corpuses. Die Angabe kann sich je nach Eingabeart vom Artikel Datum unterscheiden. So wird beispielsweise bei der Importierung aus RSS- Feeds die jeweilige Datumsangabe aus dem RSS-Feed übernommen, welche nicht mit dem Erstellungsdatum des corpuses übereinstimmen muss. Für die Kennzeichnung dieses Feldes wurde der aus dem Dubline Core stammende Term datesubmitted verwendet. users.username Das Feld enthält den Benutzernamen des Benutzers, welcher den corpus erstellt hat und dem der Artikel zugeordnet ist. Der Inhalt dieses Feldes kann beispielsweise dazu benutzt werden um bei SPARQL-Abfragen den Suchbereich auf einen bestimmten Benutzer zu beschränken. Für die Kennzeichnung dieses Feldes wurde der Dublin Core Term contributor verwendet. Mit der Identifizierung und Zuordnung zu einem Term sind die Anforderungen 7 und 8 erfüllt. Die Felder und deren zugehörige Anordnung ist in der Tabelle 5.1 dargestellt. Bei der Implementierung muss auf die Anforderung 6, welche das umgehen mit leeren Feldern definiert Rücksicht genommen werden. Durch die Benutzung des Dubline Core Terms language und die Benutzung des RFC 4646 [Phillips und Davis (2009)] ist es sichergestellt, dass die gewählte Sprache unterstützt wird.

63 5. Design Entscheidungen 56 Term dcterms:identifier nif:sourceurl nif:title dcterms:ispartof dcterms:created dcterms:source dcterms:language dcterms:datesubmitted dcterms:contributor nif:anchorof itsrdf:taidentref nif:beginindex itsrdf:taconfidence dcterms:identifier itsrdf:taclassref Feldname in der Datenbank articles._id articles.uri articles.title articles.corpuses articles.creation_date articles.source articles.language corpus.creation_date users.username articles.entities.name articles.entities.uri articles.entities.offset articles.entities.precision articles.entities.id articles.entities.types Tabelle 5.1.: Mapping Tabelle 5.5. NLP Interchange Formates (NIF) Die Verwendung des NLP Interchange Formates (NIF) erlaubt die Interoperabilität mit anderen Tools und Programmen. Dazu werden die im Kapitel 5.4 identifizierten Felder mit den nötigen Metadaten angereichert und in ein NIF kompatibles Format überführt. Dabei sind die in 4.6 aufgeführten Anforderungen zu beachten. Die aufgestellte Anforderung Nummer 13 fordert, dass alle Texte im Unicode Normalform C (NFC) vorliegen. Bei den derzeit vorhandenen und zukünftigen Eingabeformaten von context kann nicht davon ausgegangen werden, dass die Eingabe in einer solchen Form vorliegt. Eine Einschränkung der Eingabe auf nur im NFC Form vorliegende Texte wäre eine nicht sinnvolle Einschränkung der Funktionalität von context. So besteht der sinnvolle Weg darin die eingaben in das NFC Format zu konvertieren. So werden während der Erstellung des RDF-Dokumentes alle Texte und der Titel zum NFC Format konvertiert. Die Anforderung 14 formuliert, dass alle Zeichenketten in Unicode Code Points gezählt werden. Dies wird durch die oben angegebene Konvertierung im NFC Format sichergestellt, da nach der Konvertierung im NFC Format jedes Zeichen als ein Code Point vorliegt. Auf die Zählung der Zeichenketten wird im Kapitel Implementierung (siehe Kapitel 6.3 ) eingegangen. Die durch die NIF Spezifikation festgelegte Anforderung 16, welche besagt, dass für alle von einem nif:context stammende Texte ein nif:wasconvertedfrom Herkunftslink angegeben wer-

64 5. Design Entscheidungen 57 den muss, kommt nicht zum Einsatz da jeder Artikel individuell behandelt wird. Somit ist sie automatisch erfüllt. Auf die weiteren formulierten Forderungen 12, 15 und 16 wurden bei der Implementation berücksichtigt. Diese werden im Kapitel 6.3 näher erläutert LOD2 Anforderungen Die Voraussetzungen für eine Aufnahme in den LOD2 Software Stack wurden in den Anforderungen 9, 10 und 11 formuliert. Die Anforderung 9 fordert das die Software als Debian Packet zur Verfügung steht und verteilt werden kann. Durch die Designentscheidung für den Einsatz von MongoDB als Datenbank und rdfstore-js als Bibliothek die im Abschnitt 5.1 getroffen wurde, wird für den Einsatz des RDF-Backends und des SPARQL-Endpoints, keine zusätzlichen Software Komponenten, die in einem Debian Paket angegeben werden müssen benötigt. Die für das RDF-Backend und SPARQL-Endpoint benötigten Bibliotheken werden bei der Installation von context automatisch durch den Paketmanager von Node.JS mit installiert. Demnach ist die Anforderung 9 erfüllt. Die Anforderung 10 besagt, dass die die Software eine Open Source Ansatz haben muss. context steht unter der freizügigen MIT Open Source Lizenz [Group]. Das RDF-Backend ist vollständig in context integriert und steht demnach unter die gleiche Lizenz. Womit diese Anforderung erfüllt ist. Die Anforderung 11 als ein teil der Voraussetzungen für eine Aufnahme im LOD2 Software Stack fordert die Bereitstellung eines SPARQL-Endpoints. Die Bereitstellung des SPARQL-Endpoints ist ein teil dieser Arbeit, so wurden einige Entscheidungen über den Aufbau und Struktur des SPARQL-Endpoints getroffen welche im weiteren erläutert werden. LOD2 spezifiziert keine genaueren Anforderungen an das SPARQL-Endpoint, bis auf deren Existenz [lod2]. So gilt es für den SPARQL-Endpoint eine sinnvolle Spezifikation zu definieren. Als erstes gilt es den abfrage Pfad für die SPARQL abfragen zu bestimmen. context ist Modular aufgebaut und verwendet für die abfrage der Corpus Daten den relativen Pfad /api/. Dieser Programmierlogik zufolge, soll alle Kommunikation nach außen über den Pfad /api/ ablaufen. Demnach ist der SPARQL-Endpoint über den Pfad /api/sparql erreichbar. Im nächsten Schritt ist zu entscheiden, über welches Protokoll anfragen an das SPARQL-Endpoint gestellt werden können. Die rdfstore-js Bibliothek unterstützt derzeit nur die SPARQL Protokoll 1.0 vollständig [rdfstorejscurrent] und nur die wichtigsten Befehle aus SPARQL Protokoll 1.1. Aus diesem Grund wurde entschieden, bei der Umsetzung die SPARQL Version 1.0 zu verwenden. Die SPARQL Protokoll 1.0 Spezifikation besagt, dass der SPARQL-Endpoint das Protokoll HTTP unterstützen muss und über deren Methoden GET und POST abfragbar sein muss [Feigenbaum u. a.

65 5. Design Entscheidungen 58 (2008)]. So wird die Abfrage des SPARQL-Endpoints über HTTP und deren Methoden GET und POST unterstützt. Da es beim erstellen von SPARQL anfragen leicht zu Fehlern kommen kann, wird ebenfalls eine Weboberfläche zur Fehlerbehebung bei den Anfragen zur Verfügung gestellt. Des weiteren besagt die SPARQL Protokoll 1.0 Spezifikation, dass SPARQL anfragen mit der Zeichenkette query= beginnen [Feigenbaum u. a. (2008)]. So werden alle Zeichenketten die der Zeichenkette query= folgen als SPARQL anfrage interpretiert und entsprechend an die Bibliothek rdfstore-js weiter gereicht. Als Ausgabeformate für die Anfragen werden die RDF Serialisierungsformate RDF/ XML und RDF/ JSON-LD unterstützt. Bei den beiden Formaten, handelt es sich um die am häufigsten eingesetzten Serialisierungsformate für RDF. Damit ist sichergestellt, dass die Ausgabe von einer Großzahl von Programmen interpretiert werden kann Sicherheitsanforderungen context ist für den Dualbetrieb als Stand-Alone Plattform und als ein Tool innerhalb des LOD2 Software Stacks geplant. Diese beiden verschiedenen Nutzungsarten stellt für die Sicherheit des RDF-Backends eine Herausforderung dar. Als Stand-Alone Plattform steht die Visualisierung und Annotation der Texte im Vordergrund. Die Zielgruppe bilden dabei Endbenutzer mit wenigen beziehungsweise keine Kenntnisse über das Semantic Web. Beim betrieb innerhalb des LOD2 Projektes sind die Benutzer mehrheitlich Forscher und Entwickler die mehr an die Daten und deren Zusammenhänge interessiert sind und Zugriff auf möglichst viele Daten und Funktionen wünschen. So gilt auch bei den Sicherheitsfunktionen die Interessen beider Gruppen zu berücksichtigen. Die Anforderungen an die Sicherheitsarchitektur sind in den Anforderungen 20, 21 und 22 formuliert. Die Sicherheitsanforderung 20 fordert, dass es die Möglichkeit für die Deaktivierung des RDF- Exports geben muss. Dazu ist eine Konfigurationsmöglichkeit geschaffen worden, um den Zugriff auf dem Pfad /api/nif welches für den RDF Export zuständig ist, vollständig abzuschalten. Durch die Deaktivierung des Pfads ist kein Aufruf der Funktion für den Datenexport möglich. Damit ist die Anforderung 20 erfüllt und die Interessen der beiden oben genannten Gruppen berücksichtigt. Im Selbstständigen betrieb kann der Betreiber die Funktion für den RDF-Export abschalten womit kein Zugriff mehr auf die Daten möglich ist. Die unter 21 angeführte Anforderung, fordert das der SPARQL-Endpoint deaktiviert werden kann. Um die Interessen von Endbenutzer und Entwickler zu berücksichtigen, wird dieser Punkt ebenfalls über einen Eintrag in der Konfigurationsdatei umgesetzt. Der Betreiber kann durch das setzen einer variable den SPARQL-Endpoint aktivieren beziehungsweise deaktivieren. Durch die Trennung der Konfigurationsmöglichkeiten für den RDF-Export und der SPARQL- Endpoint hat ein Betreiber ebenfalls die Möglichkeit eine RDF-Datenbank aus ausgewählten

66 5. Design Entscheidungen 59 Artikeln bzw. Corpuse zu erstellen und anschließend den RDF-Export deaktivieren. Damit kann er SPARQL Abfragen auf diese Daten beschränken. Die Anforderung 22 besagt, das SPARQL Befehle die Veränderungen an den vorhanden Daten in der Datenbank vornehmen nicht möglich bzw. deaktiviert werden können. Diese Sicherheitsfunktion wurde ebenfalls unter der Berücksichtigung der beider Nutzungsgruppen entworfen. Die Veränderung der Daten durch die SPARQL Befehle DELETE,INSERT,LOAD,CREATE,DROP,CLEAR wird durch einen Eintrag in der Konfigurationsdatei gesteuert. In der Standard Konfiguration ist die Veränderung der Daten in der Datenbank deaktiviert. Ferner ist noch zu erwähnen, dass eine striktere Rechteverwaltung in dem für jeden Benutzerrolle oder Benutzer fest gelegt wird, ob dieser Zugriff auf den RDF-Export Funktion bzw SPARQL- Endpoint hat wünschenswert ist. Jedoch unterstützt context derzeit keine Rechteverwaltung auf Benutzer Ebene und auch keine Benutzerrollen. Aus diesem Grund ist die Steuerung der oben genannten Sicherheitsfunktionen nur Global möglich.

67 Teil VI. Implementation

68 6. Implementation In diesem Kapitel werden die konkreten Details der Implementierung behandelt. Als Basis dazu dient die im Kapitel 5 ausgearbeitete System-Architektur und Design. Dazu wurde das dort beschriebene System in 3 Modulen unterteilt, welche jeweils selbstständig arbeiten. Die Module sind das RDF-Export-Modul, welches für den Export der Daten und die Speicherung der Triple zuständig ist, das NIF-Modul welches für die Erstellung des NIF Dokuments zuständig ist und der SPARQL-Endpoint. Durch die Unterteilung in Modulen ist es möglich, das System flexibel und erweiterbar zu gestalten. Die im Kapitel 5 beschriebenen Teilbereiche werden in diesem Kapitel nach ihrer Modulzugehörigkeit zusammengefasst und behandelt. Als erstes wird der Allgemeine Systemaufbau und die benutzten Komponenten beschrieben, anschließend wird die Implementierung jedes Modules näher erläutert Allgemeiner Aufbau context baut auf das Serverseitige JavaScript Plattform Node.JS auf. Dabei setzt context auf die model view controller (MVC) Architektur und ist Modular aufgebaut. Unter context kommt das express 4 Framework [express] und das gulp Build System [gulp] zum Einsatz. Zu dem werden diverse Module aus der Node.JS Repository verwendet. Die Erstinstallation aller Module aus der Repository übernimmt der Node.JS Paketmanager npm mit dem Befehl npm install. Dabei werden alle Module die in der Projektdatei package.js angegeben sind heruntergeladen und installiert. Wie bereits im Kapitel beschrieben, arbeitet Node.JS vollständig asynchron. Dies bedeutet, dass das Programm bei Operationen die auf externen Ressourcen angewiesen sind, nicht auf deren Antwortet wartet, sondern die Ausführung des Programms fortführt. Dazu gehören unter anderem Dateioperationen und Datenbankabfragen. Nachdem die Ergebnisse einer Datenbankabfrage bereitstehen, wird eine callback Funktion ausgeführt, indem die Daten weiterverarbeitet werden können. Durch diese Vorgehensweise kann Node.JS eine Vielzahl paralleler Anfragen verarbeiten. Jedoch muss bei der Programmierung, auf diese Eigenschaft Rücksicht genommen werden. Falls die Ergebnisse der Datenbankanfrage zur weiteren Arbeit benötigt werden, muss der entsprechende Code in die callback Funktion geschrieben werden oder bei der Erstellung der Anfrage explizit angegeben werden das die Anfrage synchron erfolgen soll [Roden (2014)].

69 6. Implementation RDF-Backend Das RDF-Backend-Modul ist für die Bereitstellung der REST API nach außen und die Speicherung des NIF-Dokuments in die MongoDB Datenbank verantwortlich. Sie befindet sich in der Datei /controllers/api/rdfbackend.js. Durch diesen Pfad hält sie sich an die context Code Konvention, bei dem sich alle APIs nach außen im Ordner /controllers/api/ befinden. Das RDF-Backend-Modul stellt als REST API verschiedene Pfade für den Zugriff zur Verfügung. Durch deren Benutzung ist es möglich, je nach Bedarf einen Artikel, einen Corpus oder alle Artikel aus dem System zu Exportieren oder zu Löschen. Durch den Modularen Aufbau des Systems kann das RDF-Backend durch das setzen Variable config.rdfbackend.nifexport auf auf false, in der Konfigurationsdatei config.js ohne negative Auswirkungen auf das restliche System deaktiviert werden Export der Daten als NIF-Dokument Für den RDF-Export werden verschiedene Pfade zur Verfügung gestellt mit deren Hilfe der Benutzer bestimmen kann welche Daten exportiert werden. Nach dem die nötigen Daten von der Datenbank abgefragt worden sind, werden sie in eine geeignete Form gebracht und an das NIF- Modul weitergereicht (siehe Kapitel 6.3). Das Exportieren erfolgt immer auf Artikel ebene. Die notwendigen Daten aus der corpuses und users Collections werden dem jeweiligen Artikel Objekt hinzugefügt. Die für den Export bereitgestellten Pfade sind nachfolgend aufgelistet. Der Ausdruck :id bezeichnet die in der MongoDB Datenbank gespeicherte ID für das jeweilige Feld. /api/nif/article/:id Exportiert den Artikel mit der angegebenen ID als NIF Dokument. Die ID stammt dabei aus dem Feld articles._id /api/nif/corpus/:id Exportiert alle Artikel die teil des Corpuses mit der angegebenen ID sind. Die ID stammt dabei aus dem Feld corpuses._id. /api/nif/user/:id Exportiert alle Artikel die teil der vom Benutzer erstellten Corpuses mit der angegebenen ID sind. Die ID stammt dabei aus dem Feld users._id /api/nif/saveall Exportiert alle in der Datenbank enthaltene Artikel unabhängig vom Benutzer und Corpus.

70 6. Implementation 63 Die Exportfunktion soll anhand der Vorgehensweise beim Exportieren eines Corpuses beschrieben werden. Der Quellcode der Funktion ist in Quellcode 6.1 dargestellt. Der Aufruf der funktion erfolgt durch das senden einer anfrage der Form :id wird bei der Anfrage durch die MongoDB ObjectID des Corpuses wie beispielsweise 53c50fcbe6fa901c10cf1c3b ersetzt. Der Aufruf der Funktion asyncawait in Zeile 1 dient dazu, Node.JS zu deklarieren, dass der Code diese Funktion synchron abzuarbeiten ist. Danach erfolgt eine Überprüfung ob die übergebene ID eine gültige MongoDB ObjectID ist um den Absturz des Programms bei einer ungültigen Eingabe zu verhindern. In der Zeile 8 wird zuerst mit dem Funktionsaufruf getcorpus() überprüft ob der Corpus existiert. Anschließend werden alle Artikel die zum angegebenen Corpus gehören durch den Befehl getcorpusarticles abgerufen. Der Aufruf der await() Funktionen deklariert, dass auf die Ergebnisse das Funktionsaufrufs gewartet werden soll. Anschließend wird jedes Artikel an die articleprocessor() Funktion weitergegeben, welches den übergebenen Artikel, mit Hilfe des NIF-Moduls, in ein NIF-Dokument konvertiert und bei bedarf diesen in der Datenbank speichert. Zum Schluss wird das erstellte Dokument an den Client gesendet. Da bei eine Übertragung im Textform unter Windows die Linux Zeilenumbruchzeichen (\n) in Windows Zeilenumbruchzeichen (\r\n) konvertiert werden und die Zeichenzählung im ausgegebenem NIF-Dokument nicht mehr korrekt wäre, erfolgt die Datenübertragung zum Client im Binärmodus. Dadurch bleiben die Zeilenumbruchzeichen erhalten. Quellcode 6.1: RDF-Backend Funktion zur Exportierung eines Corpuses als NIF-Dokument 1 var savecorpusasrdf= asyncawait( function (req, res, next) { 2 var requestid = req. params.id; 3 if(! isvalidmongodbid( requestid)){ 4 res. send(" Not a valid ID"); 5 return next( new Error( Not a valid MongoDB ID! ID: +requestid)); 6 } 7 await( initialise()); 8 var articles = await( getcorpus( requestid). then( getcorpusarticles)); 9 var nifstring = nifprefix; 10 articles. foreach( function ( article) { 11 nifstring = nifstring + articleprocessor( article); 12 }); 13 sendttl(req, res, nifstring); 14 }); Die übrigen API Pfade funktionieren nach dem gleichen Prinzip. Für die Weiterverarbeitung jedes Artikels wird unabhängig der verwendeten API Pfades, die Funktion articleprocessor() verwendet (siehe Quellcode 6.2). Sie fügt die corpus daten und user Daten zum Artikel hinzu, ruft das NIF-Modul auf und wenn die Option eingeschaltet ist, ruft sie die Speicherfunktion für den Triplestore auf. Das Hinzufügen der corpus und user Daten zum Artikel vor der Erstellung des NIF-Dokuments, hat den Vorteil, dass alle für den Artikel im System vorhandenen Daten im Artikel Objekt vorliegen

71 6. Implementation 64 und somit vom NIF-Modul verwendet werden können. Das erleichtert die zukünftige Erweiterung von context und das NIF-Moduls, da nicht für jedes neu hinzugekommene Feld, dass RDF- Backend angepasst werden muss. So kann im NIF-Module immer davon ausgegangen werden, dass alle im System verfügbaren Informationen zu einem Artikel im übergebenem Array vorliegen. Dabei wird die Eigenschaft der MongoDB Datenbank ausgenutzt, dass im Gegensatz zu relationalen Datenbanken, nicht einzelne Felder abgefragt werden können, sondern immer das ganze Dokument zurück geliefert wird. Durch die Benutzung dieser Eigenschaft, ergeben sich dabei auch keine Nachteile bezüglich der Abfragezeit der Datenbank. Zum Hinzufügen der corpus und user Daten zu jedem Artikel, wird bei einer API Abfrage eine Initialisierungsfunktion aufgerufen (siehe Quellcode 6.1 Zeile 7). In diese Funktion wird eine Liste alle im context gespeicherten corpuse und user abgefragt und in einem Array gespeichert. In den Funktionen addcorpusobjecttoarticle() und adduserobjecttoarticlecorpus() werden die gespeicherten Daten zum jeweiligen corpus und user aus diesem Arrays heraus gefiltert und zum Artikel hinzugefügt. Durch diese Vorgehensweise, ist es nicht notwendig für jeden Artikel eine Datenbankabfrage auszuführen, da alle Daten in den Arrays vorliegen. Durch die Speicherung der corpus und user Daten in Arrays, werden zeitintensive Datenbankabfragen gespart. Wie aus der foreach Schleife im Quellcode 6.1 Zeile erkennbar ist, wird jedes Artikel einzelnd verarbeitet und gespeichert. Durch dieses vorgehen, kann jedes Artikel als ein benannter Graph (englisch named graph) gespeichert werden. Durch die Speicherungs als benannter Graph ist es möglich, auf alle Triple eines Artikels zuzugreifen, diese zu löschen oder auch die Anfragen auf bestimmte Artikel zu begrenzen. Jedoch geht damit ein längerer Laufzeit bei der Speicherung der Artikel einher. Quellcode 6.2: Funktion zur Annotierung und Speicherung des NIF-Dokuments 1 function articleprocessor( articleobject) { 2 if (( articleobject == null) ( articleobject == " undefined")) { 3 return false; 4 } 5 articleobject = addcorpusobjecttoarticle( articleobject); // Hinzufügen der Corpus Daten zum Artikel 6 articleobject = adduserobjecttoarticlecorpus( articleobject); // Hinzufügen der User Daten zum Artikel 7 8 var nifarticle; 9 nifarticle = nifcreator. articletonif( articleobject); // Aufruf des NIF Moduls if ((nifarticle) && (nifarticle!= "undefined")){ 12 if( config. rdfbackend. nifsave === true ) save2rdfstore( nifarticle, articleobject._id); // Speicherung des NIF - Dokuments in die Triplestore Datenbank 13 return nifarticle; 14 } 15 else { 16 return false; 17 } 18 }

72 6. Implementation Löschung der Daten aus der Triplestore Datenbank Wie beim NIF-Export stellt das RDF-Backend verschiedene Pfade und eine REST API zur Löschung der gespeicherten Artikel aus dem Triplestore zur Verfügung. Eine Löschung kann erforderlich sein, wenn ein Benutzer einen Corpus oder einzelne Artikel daraus löscht. Um die Daten zwischen context und dem Triplestore synchron zu halten, ist es dann erforderlich die entsprechenden Daten ebenfalls aus dem Triplestore zu entfernen. Die Löschung der Daten wird durch die Tatsache, dass jedes Artikel als benannter Graph gespeichert ist, deutlich vereinfacht. So muss für die Löschung eines Corpuses, nur die IDs der in ihm enthaltenen Artikel ermittelt werden, um dann die Graphen der entsprechenden Artikel zu löschen. Die für die Löschung bereitgestellten Pfade sind nachfolgend aufgelistet. Diese sind ähnlich wie die Pfade für den NIF-Export aufgebaut. Der Ausdruck :id bezeichnet die in der MongoDB Datenbank gespeicherte ID für das jeweilige Feld und Collection. /api/nif/article/del/:id Löscht den benannten Graphen mit der angegebenen ID aus dem Triplestore. Die ID stammt dabei aus dem Feld articles._id. /api/nif/corpus/del/:id Löscht alle Artikel die teil des Corpuses mit der angegebenen ID sind. Die ID stammt dabei aus dem Feld corpuses._id. /api/nif/user/del/:id Löscht alle Artikel, die teil der vom Benutzer erstellten Corpuse sind. Die ID stammt dabei aus dem Feld users._id und bezeichnet die user ID des Benutzers. /api/nif/deleteall Löscht alle Einträge aus der Triplestore Datenbank unabhängig vom Corpus und Benutzer. Technisch erfolgt dies, in dem rdfstorejs mit der option overwrite initialisiert wird, wodurch alle in der Datenbankenthaltene Felder gelöscht werden. Erwähnenswert ist noch, dass beim Update eines Artikels und das darauf folgende Update des Triples, dieser nicht explizit gelöscht werden muss. Vor dem hinzufügen eines neuen Artikels, wird überprüft ob bereits ein Graph für diesen Artikel existiert. Falls ein entsprechender Graph existiert, wird dieser vor dem Einfügen des neuen Artikels gelöscht Speicherung in die Triplestore Datenbank Die Speicherung der erstellten NIF-Dokumente ist die Voraussetzung für den SPARQL-Endpoint. Dazu wird jedes Artikel als ein einzelner benannter Graph mit dem URI des Artikels in form:

73 6. Implementation 66 1 { Quellcode 6.3: Speicherung eines Triples in die MongoDB Datenbank mit rdfstorejs 2 " subject" : "u: example. com/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571", 3 " predicate" : "u: org/1999/02/22 - rdf - syntax -ns# type", 4 " object" : "u: persistence.uni - leipzig. org/ nlp2rdf/ ontologies/nif - core# String", 5 " graph" : "u: example. com/ context/ article/53 c50fcce6fa901c10cf1c46", 6 "_id" : ObjectId ("53 d526f009f24f841de3478b") 7 } gespeichert. Damit sind die Triple jedes Artikels eindeutig bestimmbar. Diese Lösung wurde im vorherigen Kapitel zur Löschung der Daten verwendet. Zur Speicherung der Daten in die MongoDB Datenbank wird die rdfstorejs [Langanke] Bibliothek verwendet. rdfstorejs bietet einen Highlevel Interface für die Benutzung der Bibliothek an. Damit ist es möglich, dass NIF-Dokument welches ein gültiger turtle [Carothers und Prud hommeaux (2014)] Dokument ist zu Parsen und in die Datenbank einzufügen. Dabei wird das NIF-Dokument in einzelne Triple mit <subject, predicate, object> zerlegt und jedes Triple als ein Dokument in die Datenbank gespeichert. Ein Beispiel Triple welches als ein Dokument gespeichert ist, ist in Quellcode 6.3 abgebildet. Die graph URI ist dabei für alle Triple des Artikels gleich. Die Speicherfunktion prüft für jeden Artikel an Hand der graphuri, ob dieser bereits in der Datenbank vorhanden ist. Falls bereits ein Graph mit der entsprechenden graphuri in der Datenbank existiert, wird dieser vor dem einfügen des Artikels gelöscht. Somit wird sichergestellt, dass immer die aktuelle Version des Artikels im Triplestore gespeichert ist. Die Speicherfunktion ist dabei optional gestaltet. Durch das setzen der variable rdfbackend.nifsave in der Konfigurationsdatei config.js auf false ist es möglich die Speicherung des NIF-Dokuments zu deaktivieren. Dadurch ist es möglich, dass RDF-Backend nur zum Exportieren der Daten als NIF-Dokument zu benutzen. Es ist ebenfalls möglich, die gewünschten Datensätze einmal zu Generieren und in der Datenbank zu speichern und danach die Speicherfunktion zu deaktivieren. Dadurch sind SPARQL anfragen nur auf die bereits gespeicherten Dokumente möglich NIF Implementierung Ein weiterer Schwerpunkt dieser Arbeit, besteht in der Integration des NIF-Dokumenten Formates in context. Die Anforderungen und das entsprechende Mapping der Felder auf das geeignete Vokabular wurde im Kapitel 5.4 näher beschrieben. In diesem Kapitel soll die konkrete

74 6. Implementation 67 Umsetzung erläutert werden. Es sei darauf hingewiesen, dass zwischen der Software context und die aus der NIF Ontologie stammende Bezeichnung Context zu unterscheiden ist. Beide besitzen die gleiche Bezeichnung, was für Verwirrung sorgen kann. Die Bezeichnung context wird immer für die Software verwendet. Für die aus der NIF Ontologie stammende Bezeichnung Context wird immer die Bezeichnung nif:context verwendet. Die NIF-Implementation ist als Modul realisiert und bietet zur Benutzung durch andere Module die beiden Funktionen nifprefix() und article2nif() an. Die nifprefix() Funktion wird ohne Parameter aufgerufen und liefert einen string mit allen verwendeten Präfixe im Turtle Format zurück. Die Funktion article2nif() wird mit dem Parameter Objekt aufgerufen und liefert das annotierte NIF-Dokument zurück. Dabei ist die Zusammensetzung der Präfixe und das NIF-Dokument, die Aufgabe der aufrufenden Funktion. Dies wurde so implementiert um das Modul möglichst allgemein zu halten und das mehrfache einbinden der Präfixe beim mehrmaligen Aufruf des NIF-Moduls, wenn beispielsweise mehrere 100 Artikel annotiert werden, zu vermeiden. Die Zusammensetzung des Präfixes und das NIF-Dokument kann in JavaScript sehr einfach durch den Befehl nifprefix() + article2nif(object) realisiert werden. Im Quellcode 6.4 ist eine Beispielausgabe des NIF-Moduls dargestellt. Aus Platzgründen wird im Quellcode 6.4 nur eine annotierte Entität dargestellt. In den Zeilen 1-7 ist die Ausgabe der nifprefix() Funktion dargestellt. Die Funktion article2nif(object) ist zuständig für die Erstellung des NIF-Dokuments. Dazu wird sie mit dem Parameter articleobject aufgerufen. Beim articleobject handelt es sich um das aus der MongoDB erhaltene Artikel Dokument mit allen Feldern die in Collection articles gespeichert sind. Zusätzlich ist das Objekt um Arrays mit den Felder für die Corpuses zu dem der Artikel dazugehört aus der corpuses collection und mit den Daten des Benutzers der den Corpus erstellt hat aus der users collection angereichert. Damit befinden sich alle im System vorhandenen Daten für den Artikel in diesem Objekt. Durch dieses vorgehen wird sicher gestellt, dass alle Felder die Daten zu einem Artikel erhalten in diesem Objekt vorhanden sind. Damit befinden sich auch in Zukunft im Datenbankschema eingefügte Felder in diesem Objekt und das NIF-Modul kann durch das hinzufügen wenige Zeilen Code um die Unterstützung der Felder erweitert werden. Dabei wird im NIF-Module zwischen dem Artikel selbst und die vom NLP-Service erkannten Entitäten unterschieden und diese werden auch anderes verarbeitet. Beim Artikel selbst handelt es sich um den von der NIF-Spezifikation [Hellmann (a)] festgelegte OWL Subklasse von nif:string, die nif:context klasse, der alle Zeichenketten im Text zugeordnet sind Aufbau des NIF-Dokumentes Die Darstellung eines Artikels als NIF-Dokument ist im Quellcode 6.4 abgebildet. Das Dokument beginnt mit der definition aller benutzten Präfixe in den zeilen 1-7. Die zum Hauptartikel

75 6. Implementation 68 gehörenden Triple sind in den Zeilen 9-24 dargestellt. In den Zeilen ist die annotierte form eines vom NLP-Service erkannte Entität dargestellt Hauptartikel (nif:context) Der Hauptartikel beginnt der NIF Spezifikation [Hellmann (b)] nach immer mit dem Subjekt in spitzen Klammern (<>) (siehe Quellcode 6.4 Zeile 9). Dabei ist das Subjekt, die URI zum Artikel. Zusätzlich verlangt die NIF Spezifikation, dass bei der URI nach dem Separator Raute (#) die Zeichenlänge des Textes durch den Zählungsbeginn 0 und die Zeichenlänge des Textes durch eine Zahl angegeben wird. Falls der gesamte Text betroffen ist, musss die Endlänge nicht mit angegeben werden. Für eine bessere Übersicht, wurde entschieden die gesamt Zeichenlänge des Textes mit anzugeben. Anschließend wird in der Zeile 10 durch nif:string angegeben, dass es sich um die Klasse aller Wörter über das Alphabet der Unicode Zeichen handelt [Hellmann (b)]. Durch die Zeichenkette nif:context wird mitgeteilt, dass es sich um den Haupttext handelt und durch die Angabe nif:rfc5147string wird das URI Schema nach RFC 5147 [Wilde und Duerst (2008)] deklariert. Die Klasse nif:string beinhaltet nach der NIF Spezifikation den Referenztext als Literal. Auf diesen Referenztext beziehen sich alle Zählungen im NIF-Dokument. context fügt bei den Anfragen an NLP-Services den Titel des Dokumentes mit einem Punkt (.) getrennt am Anfang des zu Annotierenden Zeichenkette, damit auch Entitäten innerhalb des Titels annotiert werden. Um die Kompatibilität mit context sicher zu stellen, wird im NIF-Modul ebenfalls der Titel des Artikels mit einem Punkt getrennt zum nif:isstring hinzugefügt. Im Quellcode 6.4 handelt es sich um den Satz Gebündelte Schallwellen zerstören Tumoren. in Zeile 11. Damit ist die in Anforderung 12 (siehe Kapitel 4.6) aufgestellte Anforderung, dass alle Texte zu einem Literal vom Typ nif:isstring konvertiert werden müssen erfüllt. Um die ebenfalls im Kapitel 4.6 aufgestellte Anforderung 13, welches besagt das alle Texte in Unicode Normalform C vorliegen müssen zu erfüllen, wird der Titel und der Artikelinhalt, mit Hilfe der Node.JS Bibliothek unorm [Walling], in Unicode Normalform C konvertiert. Die Prädikaten nif:beginindex und nif:endindex bezeichnen nach der NIF Spezifikation den Anfangsposition und das Endposition der Zeichenkette im nif:isstring. Die Anfangsposition ist im nif:context immer 0. Als wert erhalten dürfen die Prädikate nach der Spezifikation nur Einträge vom typ xsd:nonnegativeinteger enthalten, also nur Ganzzahlen die größer oder gleich 0 sind. Dies wird durch die Benutzung der Konstante 0 für nif:beginindex und durch die Zählung im NFC form bei dem das erste Zeichen die Position 1 hat sichergestellt. Die genaue Zählweise wird im Kapitel erläutert. Das dcterms:identifier Prädikat, enthält die vom MongoDB vergebene eindeutige ID für den Artikel. Sie wird vom typ String deklariert. Das dcterms:ispartof Prädikat definiert, dass der Artikel in einem größeren Kontext in diesem fall ein Corpus enthalten ist. Dafür enthält sie die URI des Corpuses.

76 6. Implementation 69 Die Prädikate dcterms:created und dcterms:datesubmitted enthalten die im Kapitel 5.4 erstelltes mapping für den Erstellungsdatum des Artikels im Arikel Quelle und das Datum an dem der Artikel im System eingetragen wurde. Beide Prädikate haben als Typ xsd:datetime. Dabei wird das im MongoDB enthaltenes Datum in eine gültige datetime Datentyp umgewandelt. Das Prädikat dcterms:contributor enthält den Benutzernamen des Besitzers des Corpuses in dem der Artikel enthalten ist. Das Prädikat itsrdf:taconfidence beschreibt die im Internationalization Tag Set (ITS) [Lewis u. a. (2013)] spezifizierte Eigenschaft, wie sicher sich ein Textanalyse Programm über die angezeigten Ergebnisse ist. Diese Funktion ist noch nicht im context enthalten, so wird der Standardwert von 0.2 ausgegeben. Das Prädikat nif:title enthält den Titel des Artikels als String im Unicode NFC Notation. Der dcterms:language enthält falls vorhanden, die gewählte Artikelsprache im RFC 4646 [Phillips und Davis (2009)] Notation. Das Prädikat nif:sourceurl enthält nach der NIF-Spezifikation die URI des Original Artikels. Das Prädikat dcterms:source enthält die Rohfassung des im nif:isstring Textes vor der Entfernung der HTML zeichen. In der Tabelle 6.1 sind alle oben genannten Prädikate, deren Wert und deren Typ übersichtlich dargestellt. Term Typ Datenbankfeld Baseuri RFC 5147 URI Artikel URI nif:isstring xsd:string articles.source dcterms:identifier xsd:string articles._id dcterms:created xsd:datetime articles.created dcterms:datesubmitted xsd:datetime corpus.creation_date itsrdf:taconfidence xsd:decimal articles.confidence nif:title xsd:string articles.title dcterms:language dcterms:rfc4646 articles.language dcterms:source xsd:string articles.source nif:sourceurl RFC 5147 URI articles.uri dcterms:ispartof RFC 5147 URI corpuses._id dcterms:contributor xsd:string users.username a nif:string - NIF-Metadaten nif:context - NIF-Metadaten nif:rfc5147string - NIF-Metadaten nif:beginindex xsd:nonnegativeinteger vom NIF-Module berechnet. nif:endindex xsd:nonnegativeinteger vom NIF-Module berechnet. Tabelle 6.1.: Mapping der Artikeldaten

77 6. Implementation 70 Quellcode 6.4: Beispiel für ein erstelltes NIF-Dokument rdf: < org/1999/02/22 - rdf - syntax -ns#>. rdfs: < org/2000/01/ rdf - schema#>. owl: < org/2002/07/ owl#>. xsd: < org/2001/ XMLSchema#>. nif: < persistence.uni - leipzig. org/ nlp2rdf/ ontologies/nif - core #>. itsrdf: < org/2005/11/ its/ rdf#>. dcterms: < purl. org/dc/ terms/>. 8 9 <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571> 10 a nif: String, nif: Context, nif: RFC5147String ; 11 nif: isstring """ Gebündelte Schallwellen zerstören Tumoren. Die Klinik für Radiologie am Universitätsklinikum Bonn hat ein neuartiges Gerät für Hochintensiven Fokussierten Ultraschall ( HIFU) in Betrieb genommen. Mit diesem neuen Verfahren lassen sich Tumore gezielt und nicht - invasiv durch die intakte Haut zerstören. Es ist das erste HIFU - Gerät dieser Art im deutschsprachigen Raum, mit dem erstmals nicht nur die Tumorbehandlung, sondern auch eine bildgebende Steuerung über die selbe Ultraschallsonde m öglich ist. Zudem bleibt diese während der ganzen Behandlung außerhalb des Körpers."""^^ xsd: string; 12 nif: beginindex "0"^^ xsd: nonnegativeinteger; 13 nif: endindex "571"^^ xsd: nonnegativeinteger; 14 dcterms: identifier "53 c50fcce6fa901c10cf1c46 "^^ xsd: string ; 15 dcterms: ispartof <http :// :8080/ context/ corpus/53 c50fcbe6fa901c10cf1c3b >; 16 dcterms: created " T08:12:10.000Z"^^ xsd: datetime ; 17 dcterms: datesubmitted " T11:26:03.578Z"^^ xsd: datetime ; 18 dcterms: contributor " navid"^^ xsd: string ; 19 itsrdf: taconfidence "0.2"^^ xsd: decimal ; 20 nif: title """ Gebündelte Schallwellen zerstören Tumoren """^^ xsd: string ; 21 dcterms: language "de"^^ dcterms: RFC4646; 22 nif: sourceurl < www3.uni - bonn.de/ Pressemitteilungen / > ; 23 dcterms: source """ Gebündelte Schallwellen zerstören Tumoren. Die Klinik für Radiologie am Universitätsklinikum Bonn hat ein neuartiges Gerät für Hochintensiven Fokussierten Ultraschall ( HIFU) in Betrieb genommen. Mit diesem neuen Verfahren lassen sich Tumore gezielt und nicht - invasiv durch die intakte Haut zerstören. Es ist das erste HIFU - Gerät dieser Art im deutschsprachigen Raum, mit dem erstmals nicht nur die Tumorbehandlung, sondern auch eine bildgebende Steuerung über die selbe Ultraschallsonde m öglich ist. Zudem bleibt diese während der ganzen Behandlung außerhalb des Körpers."""^^ xsd: string <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =73,98> 28 a nif: String, nif: RFC5147String ; 29 a nif: Word; 30 nif: referencecontext <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571>; 31 nif: anchorof """ Universitätsklinikum Bonn"""^^ xsd: string ; 32 nif: beginindex "73"^^ xsd: nonnegativeinteger; 33 nif: endindex "98"^^ xsd: nonnegativeinteger; 34 itsrdf: taconfidence "1"^^ xsd: decimal ; 35 dcterms: identifier "53 c50fe1e6fa901c10cf1cb7 "^^ xsd: string ; 36 itsrdf: taclassref < dbpedia. org/ ontology/place >; 37 itsrdf: taclassref < dbpedia. org/ ontology/ ArchitecturalStructure >; 38 itsrdf: taclassref < dbpedia. org/ ontology/ Building >; 39 itsrdf: taclassref < dbpedia. org/ ontology/ Hospital >; 40 itsrdf: taidentref < de. dbpedia. org/ resource/ Universitätsklinikum_Bonn >; 41.

78 6. Implementation Entitäten (NIF Subklasse) Bei den Entitäten, handelt es sich um die von dem NLP-Service erkannten Entitäten. Ein Beispiel Eintrag ist in Quellcode 6.4 in den Zeilen dargestellt. Die Entitäten enthalten als Subjekt ebenso wie nif:context die URI des Artikels. Jedoch wird bei dem durch den seperator Raute (#) getrennter teil die Position der Entität innerhalb des Haupttextes (nif:isstring) angegeben. Die Zählung beginnt mit dem ersten Buchstaben der Entität und schleißt mit dem letzten Buchstaben ab. Die Entitäten sind in NIF eine Subklasse der klasse nif:isstring. Sie werden ebenso wie nif:context mit der Bezeichnung nif:string als alle Zeichen über das Unicode Alphabet angegeben und die URI Schema ist durch nif:rfc5147string ebenfalls nach RFC 5147 deklartiert. Alle exportierten Entitäten werden mit a nif:word als ein Wort deklariert. Dabei ist ein nif:word nach der NIF Ontology [Hellmann (a)] sehr allgemein gefasst und beschränkt sich nicht nur auf eine zusammenhängende Zeichenkette, damit können auch Bedeutsamkeitszusammenhängende Wörter bezeichnet werden. So ist im Quellcode 6.4 die Entität Universitätsklinikum Bonn als Wort deklariert, obwohl es im gründe 2 Wörter sind. Da jedoch jedes dieser Wörter für sich eine allgemeine Bedeutung haben, jedoch zusammenhängend eine spezifische Bedeutung haben. Werden diese als nif:word deklariert. Das Prädikat nif:referencecontext ist durch die NIF Spezifikation [Hellmann (b)] gefordert und in der Anforderung 13 formuliert. Sie fordert, dass alle Substrings eine Relation zu eine Instanz von nif:context haben müssen. Dazu kommt die Bezeichnung nif:referencecontext zum Einsatz. Sie enthält als wert die URI von nif:context aus dem die Entität bzw. Substring stammt. nif:anchorof präsentiert als Literal den Wert der URI der Entität. Im falle der Software context ist es der Entitätsname. nif:anchorof enthält als String den Namen der gefundenen Entität. Dabi kann es sich auch um eine abkürzung handeln wie beispielsweise HTC statt High Tech Computer Corporation. nif:beginindex und nif:endindex bezeichnen ebenso wie im nif:context, nach der NIF Spezifikation, die Anfangsposition und das Endposition der Zeichenkette im nif:isstring. Als wert erhalten dürfen die Prädikate nach der NIF-Spezifikation nur Einträge vom typ xsd:nonnegativeinteger enthalten, also nur Ganzzahlen die größer oder gleich 0 sind. itsrdf:taconfidence beschreibt die im Internationalization Tag Set (ITS) [Lewis u. a. (2013)] spezifizierte Eigenschaft, wie sicher sich ein Textanalyse Programm über das zurückgelieferte Ergebnis ist. Dieser Wert wird im Gegensatz zu ihrem Pendant im nif:context vom NLP-Service zurück geliefert und wir für jede Entität angegeben. Bei diesem Wert, handelt es sich um eine Dezimalzahl die zwischen 0 und 1 liegen kann. Quellcode 6.4 ist dieser Wert mit 1 angegeben. Das bedeutet, dass sich das NLP-Service zu 100% sicher ist, dass die zurück gelieferte Entität korrekt ist.

79 6. Implementation 72 dcterms:identifier enthält die vom MongoDB vergebene eindeutige ID für die Entität. Sie wird vom Typ String deklariert. itsrdf:taclassref beschreibt die im Internationalization Tag Set (ITS) [Lewis u. a. (2013)] spezifizierte Entitätstyp. Dabei kann eine Entität zu mehreren Klassen dazu gehören. So gehört die im Quellcode 6.4 dargestellte Entität Universitätsklinikum Bonn zu den Entitätsklassen Place, ArchitecturalStructure, Building, Hospital. itsrdf:taidentref beschreibt die im Internationalization Tag Set (ITS) [Lewis u. a. (2013)] die von der Textanalyse erkannte eindeutiger Bezeichner für die erkannte Entität. Wie z.b. im Quellcode 6.4. Damit kann jede erkannte Entität eindeutig identifiziert werden. In der Tabelle 6.2 sind alle oben genannten Prädikate, deren Wert und deren Typ übersichtlich dargestellt. Term Typ Datenbankfeld EntityURI RFC 5147 URI articleuri nif:anchorof xsd:string articles.entities.name nif:beginindex xsd:nonnegativeinteger articles.entities.offset nif:endindex xsd:nonnegativeinteger vom NIF-Modul berechnet itsrdf:taconfidence xsd:decimal articles.entities.precision dcterms:identifier xsd:string articles.entities._id itsrdf:taclassref RFC 5147 URI articles.entities.types itsrdf:taidentref RFC 5147 URI articles.entities.uri nif:referencecontext RFC 5147 URI articleuri a nif:string - NIF-Metadaten nif:rfc5147string - NIF-Metadaten a nif:word - NIF-Metadaten Tabelle 6.2.: Mapping der Entitäten Zeichenzählung im NIF-Dokument Die NIF-Spezifikation verlangt, dass alle Zeichenketten im Text in Unicode-Codepunkten gezählt werden. Dies wurde in Anforderung 14 (siehe Kapitel 4.6) formuliert. Für die Zählung werden alle Texte mit Hilfe der Node.JS Bibliothek unorm [Walling] in Unicode NFC Form konvertiert und anschließend mit Hilfe der JavaScript Funktionlength gezählt. Damit ist sichergestellt, dass die Zeichen im Text als Unicode Codepunkte gezählt werden. Eine Besonderheit stellt sich bei der Zählung der Positionsangabe von Entitäten im Text heraus. Je nach verwendeter NLP-Service kann diese Angabe variieren. Da manche NLP-Services den Zeilenumbruch unter Windows welches mit \r\n und den Zeilenumbruch unter Linux welches

80 6. Implementation 73 nur mit \n kodiert wird gleich interpretieren und lediglich als nur ein Zeichen zählen. Die NIF- Spezifikation verlangt jedoch, dass alle Codepunkte gezählt werden. So wird der Zeilenumbruch unter Windows mit zwei Zeichen gezählt und der Zeilenumbruch unter Windows nur mit einem Zeichen. Durch die unterschiedlichen Zählweise verschiebt sich die anzugebende Zeichenposition der Entität im Text. Um diesen Fehler abzufangen werden bei jedem Artikel und Entität die Zeichen neu gezählt und die Position der Entität neu bestimmt. Dazu wird bei der in Unicode NFC form konvertiertes Text ab 10 Zeichen vor der gefundenen Entität nach der Entitätszeichenkette (Entitätsname) gesucht und deren Position bestimmt und gespeichert. Durch die Verschiebung der suche ist sichergestellt, dass die Entität auch bei unerwarteten Zeichenfolgen immer gefunden wird SPARQL-Endpoint Das dritte in dieser Arbeit entwickelte Modul für context. Mit hilfe des SPARQL-Endpoints ist es möglich, SPARQL Anfragen an die im Datenbank gespeicherten Triple zu senden. Dazu stellt das Modul eine REST API unter dem Pfad /api/sparql zur Verfügung. Damit sind nicht nur SPARQL Anfragen innerhalb von context, sondern durch jede beliebige Anwendung möglich. In diesem Kapitel soll die konkrete Umsetzung erläutert werden Anfragen Anfragen an das SPARQL-Endpoint sind, der SPARQL 1.0 Spezifikation nach [Feigenbaum u. a. (2008)], über die HTTP GET und POST Methoden möglich. Beide Anfragenmethoden werden unter dem Pfad /api/sparql unterstützt. Bei der HTTP GET Methode wird die Anfrage innerhalb der Anfrage URI integriert [Fielding u. a. (2009)]. Dabei werden alle nicht reservierten Zeichenketten innerhalb der URI Kodiert [Berners- Lee u. a. (2005)]. So werden Leerzeichen durch die Zeichenfolge %20 oder die geöffnete Klammer { durch %7B ersetzt. Die Maximale Zeichenlänge der URI ist innerhalb der Spezifikation nicht begrenzt, aber es wird davor gewarnt URIs mit eine größeren Länge als 255 Bytes (255 ASCII Zeichen) zu verwenden [Fielding u. a. (2009)]. Die Anfrage URI an einem SPARQL-Endpoint bei der Benutzung der HTTP GET Methode sieht die Kodierte URI wie folgt aus So müssen HTTP GET Anfragen zuerst dekodiert werden, das bedeutet in normalform gebracht werden. Das SPARQL-Modul dekodiert die URI bei HTTP GET Anfragen mit Hilfe der JavaScript Befehl decodeuricomponent. So sieht die dekodierte URI wie folgt aus: * {?s?p?o}. Dabei steht der SPARQL 1.0 Spezifikation nach [Feigenbaum u. a. (2008)], die Zeichenkette query vor der SPARQL Anfrage. So zerlegt das SPARQL Modul anfragen anhand des query= Stichwortes und reicht den Befehl weiter. Zu dem wurde im SPARQL-Modul eine Oberfläche zur Fehlerfindung in SPARQL

81 6. Implementation 74 Anfragen zur Verfügung gestellt. Zu diese Oberfläche gelangt der Benutzer in dem er die URL per HTTP GET Methode ohne die query Zeichenkette aufruft. Bei der HTTP POST Methode wird die Anfrage an eine URI nicht innerhalb der URI selbst, sondern innerhalb der Anfrage body gesendet [Fielding u. a. (2009)]. Dadurch ist das Senden größere Datenmengen und Anfragen möglich. Bei HTTP POST Anfragen an das SPARQL-Endpoint muss die Anfrage selbst im query Feld und das Ausgabeformat im Feld outputformat sein. Falls kein outputformat Feld angegeben ist, wird das Ergebnis in die RDF/XML Serialisierung zurück geliefert. Für beide Anfragemethoden wird der SPARQL-Spezifikation nach bei erfolgreiche Anfrage der HTTP Status Code 200 und anschließend die Ergebnisse geliefert [Feigenbaum u. a. (2008)]. Bei Fehlerhaften Anfragen wird der HTTP Status Code 400 zurück geliefert. Dadurch weiß der Client immer ob die Anfrage erfolgreich war oder nicht Ausgabe Formate Das SPARQL-Endpoint Modul unterstützt derzeit zwei Ausgabe Serialisierung Formate. dir RDF/XML Serialisierung und die JSON/LD Serialisierung. Deren Implementierung ist eng an das rdfstorejs Module für ein Standalone Server angelegt. RDF/XML Serialisierung Die RDF/XML Serialisierung liefert die Ergebnisse eine SPARQL Anfrage in RDF/XML format. Dabei werden die in SPARQL 1.0 Spezifikation geforderten bindings erfüllt [Feigenbaum u. a. (2008)]. Eine gekürzte Beispielausgabe für die SPARQL Anfrage SELECT * {?subjekt?praedikat?objekt} ist im Quellcode 6.5 dargestellt. Das Dokument beginnt mit der XML deklaration und zur Zeichenkodierung wird UTF-8 verwendet. Anschließend wird der Namensraum für das Dokument deklariert. Der XML Tag <sparql> markiert das Dokument als ein SPARQL Ergebnis Set. Im <head> tag werden die namen der Variablen wie sie in der SPARQL Anfrage angegeben waren ausgegeben. Die Ergebnisse der Anfrage befinden sich im Knoten<results>. Das <results> Knoten besitzt für jedes zurück geliefertes Ergebnis ein Kindsknoten mit dem Namen <result>. der Knoten <result> wiederum besitzt Kindsknoten mit der Bezeichnung <binding>. Für jede belegte Variable bei der Anfragestellung wird ein <binding> Knoten zurück geliefert. Der <binding> Knoten hat den belegten Variablennamen welches bei der Anfrage formuliert wurde als Attribut name gespeichert. Das <binding> Knoten hat ein Kind. Dabei handelt es sich entweder um das Element uri falls auf eine URI verwiesen wird oder ein literal in allen anderen fällen. Beim literal ist der Datentyp der Variable als Attribut datatype gespeichert. Dabei wird immer die vollständige URI zum definierten Datentyp ausgegeben. Die Datei wird anschließen mit der im SPARQL Spezifikation definierten Medientyp application/sparql-results+xml an den Client gesendet.

82 6. Implementation 75 Quellcode 6.5: Beispiel Ausgabe in RDF/XML Serialisierung 1 <? xml version=" 1.0" encoding="utf -8"?> 2 <sparql xmlns=" org/2005/ sparql - results#"> 3 <head> 4 <variable name=" subjekt"/> 5 <variable name=" praedikat"/> 6 <variable name=" objekt"/> 7 </ head> 8 <results > 9 <result > 10 <binding name=" subjekt"> 11 <uri>http: // :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =12,24</ uri> 12 </ binding > 13 <binding name=" praedikat"> 14 <uri> persistence.uni - leipzig. org/ nlp2rdf/ ontologies/nif - core# anchorof </ uri> 15 </ binding > 16 <binding name=" objekt"> 17 <literal datatype=" org/2001/ XMLSchema# string"> Schallwellen </ literal > 18 </ binding > 19 </ result > 20 <result > 21 <binding name=" subjekt"> 22 <uri>http: // :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =35,42</ uri> 23 </ binding > 24 <binding name=" praedikat"> 25 <uri> persistence.uni - leipzig. org/ nlp2rdf/ ontologies/nif - core# anchorof </ uri> 26 </ binding > 27 <binding name=" objekt"> 28 <literal datatype=" org/2001/ XMLSchema# string"> Tumoren </ literal > 29 </ binding > 30 </ result > 31 <result > 32 <binding name=" subjekt"> 33 <uri>http: // :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =59,69</ uri> 34 </ binding > 35 <binding name=" praedikat"> 36 <uri> persistence.uni - leipzig. org/ nlp2rdf/ ontologies/nif - core# anchorof </ uri> 37 </ binding > 38 <binding name=" objekt"> 39 <literal datatype=" org/2001/ XMLSchema# string"> Radiologie </ literal > 40 </ binding > 41 </ result > 42 </ results > 43 </ xml>

83 6. Implementation 76 <TODO: Die Positionierung korrigieren> JSON LD Serialisierung Die JSON-LD Serialisierung liefert die Ergebnisse eine SPARQL Anfrage in JSON-LD format. Das JSON Format hat den großen vorteil, dass auf JavaScript basierte Webanwendungen sofort mit dem zurück gelieferten Ergebnise weiter arbeiten können ohne zuerst das XML Dokument zu parsen. Außerdem besitzt sie weniger overhead als XML, so das sie eine kleinere Dateigröße besitzt. Die SPARQL 1.0 Spezifikation unterstützt kein JSON format, deshalb wurde für die Umsetzung die JSON/LD Spezifikation von SPARQL 1.1 verwendet [Seaborne (2013)]. Eine Beispiel Ausgabe ist im Quellcode 6.6 dargestellt. Der Aufbau der JSON/LD Datei ähnlet der RDF/XML Serialisierung im vorherigen Abschnitt. Die datei beginnt mit dem Objekt head welches den Mitglied (englisch members) variables gespeichert hat. variables ist ein Array mit je den Schlüssel name und die in der Anfrage belegte Name der Variablen. Neben dem head Objekt existiert auch ein results Objekt. Bei results handelt es sich um ein Array bei dem jedes Ergebniss der Anfrage in einem Array Element gespeichert ist. Jedes Array Element besteht wieder aus Objekten mit dem Namen der belegten Variablen. Im Beispiel Quellcode 6.6 sind es subjekt, praedikat, objekt. Das Subjekt und Prädikat bestehen jeweils aus den Paaren token und value. Das token Element deklariert, ob es sich bei dem Ergebnis um ein URI oder ein Literal handelt. Das Element value gibt den konkreten Wert der variablen an. Bei URIs wird immer die vollständige URI ausgegeben. Das Objekt besteht ebenfalls aus den Paare token und value. Zusätzlich hat sie noch den Paar type welches deklariert um welchen Datentyp es sich bei dem literal handelt. Nach der Erstellung der JSON Datei, wird sie der SPARQL Spezifikation 1.1 folgen als Medientyp application/sparql-results+json an den Client gesendet [Seaborne (2013)]. <TODO: Die Positionierung korrigieren> Sicherheit Bei der Implementierung ist auch die Sicherheit des SPARQL-Endpoints berücksichtigt worden. So sind in der Grundeinstellung die SPARQL Befehle DELETE,INSERT,LOAD,CREATE,DROP, CLEAR, welche Daten in der Datenbank manipulieren können deaktiviert. Dazu werden anfragen nach den Schlüsselwörtern durchsucht und bei deren Auffindung die Anfrage verweigert. Um in bestimmten Einsatzgebieten die Benutzung der obengenannten SPARQL Befehle zu ermöglichen, ist eine Einstellung zu deren aktivierung implementiert worden. Dazu muss in der Konfigurationsdatei config.js die Variable rdfbackend.sparqlupdateoperations auf true gesetzt werden. Mit diese Einstellung entfällt die Durchsuchung der Zeichenkette nach den entsprechenden Befehlen. Zusätzlich wurde auch die möglichkeit geschaffen, den SPARQL- Endpoint gänzlich zu deaktivieren. Dazu muss in der Konfigurationsdatei config.js die Variable rdfbackend.sparqlendpoint auf false gesetzt werden.

84 6. Implementation 77 1 { Quellcode 6.6: Beispiel Ausgabe in JSON/LD Serialisierung 2 "head": { 3 "variables": [ 4 { 5 "name": "subjekt" 6 }, 7 { 8 "name": "praedikat" 9 }, 10 { 11 "name": "objekt" 12 } 13 ] 14 }, 15 "results": [ 16 { 17 "subjekt": { 18 "token": "uri", 19 " value": " http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =12,24" 20 }, 21 "praedikat": { 22 "token": "uri", 23 " value": " persistence.uni - leipzig. org/ nlp2rdf/ ontologies/nif - core# anchorof" 24 }, 25 "objekt": { 26 "token": "literal", 27 "value": "Schallwellen", 28 " type": " org/2001/ XMLSchema# string" 29 } 30 }, 31 { 32 "subjekt": { 33 "token": "uri", 34 " value": " http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =35,42" 35 }, 36 "praedikat": { 37 "token": "uri", 38 " value": " persistence.uni - leipzig. org/ nlp2rdf/ ontologies/nif - core# anchorof" 39 }, 40 "objekt": { 41 "token": "literal", 42 "value": "Tumoren", 43 " type": " org/2001/ XMLSchema# string" 44 } 45 } 46 ] 47 }

85 Teil VII. Evaluation

86 7. Evaluierung Nach der Erläuterung der relevanten Aspekte der Implementierung im vorangegangenen Kapitel, soll in diesem Kapitel die Implementierung des NIF-Modules Evaluiert werden NIF Validator Die NIF-Spezifikation fordert, dass die erstellten NIF-Implementationen die Prüfung durch den auf der Webseite angebotenen Validator bestehen muss. Diese Forderung wurde im Kapitel 4.6 in der Anforderung 15 Formuliert Versuchsaufbau Datenquelle Als Datenquelle kommt ein RSS Feed der Pressemitteilungen der Universität Bonn zum Einsatz. Dieser wurde am unter der Adresse pressemitteilungen-rss/rss abgerufen und besteht aus 15 einzelnen Artikeln. Die Artikel wurden durch den NLP-Service DBPedia-Spotlight in der Sprache Deutsch annotiert. Sie ist in der Datenbank unter der corpis._id = 53c50fcbe6fa901c10cf1c3b erreichbar. Die Einträge in den collections articles, corpuses und users sind in den Quellcodes 7.1, 7.2 und 7.3 dargestellt. Aus Platzgründen ist lediglich ein Artikel aus der collection articles abgebildet. Validator Als Validator kommt die derzeit aktuellste Version des NIF-Validators zum Einsatz. Dieser wurde aus den auf github veröffentlichten Quelltexten nach der Anleitung auf der Webseite erstellt [Brümmer Martin]. Eingabedaten Der NIF-Validator erwartet als Eingabe ein NIF-Dokument. Zur Erstellung des NIF-Dokuments wird das im Kapitel beschriebenes RDF-Backend benutzt. Alle Artikel des Corpuses werden durch den Aufruf des Pfades /api/nif/corpus/ als ein NIF-Dokument unter den Dateinamen 53c50fcbe6fa901c10cf1c3b.ttl gespeichert.

87 7. Evaluierung 80 1 { Quellcode 7.1: Ein Artikel der Pressemitteilung Uni Bonn in der Datenbank 2 "_id" : ObjectId ("53 c50fcce6fa901c10cf1c46"), 3 " uri" : " www3.uni - bonn.de/ Pressemitteilungen / ", 4 " source" : " Die Klinik für Radiologie am Universitätsklinikum Bonn hat ein neuartiges Gerät für Hochintensiven Fokussierten Ultraschall ( HIFU) in Betrieb genommen. Mit diesem neuen Verfahren lassen sich Tumore gezielt und nicht - invasiv durch die intakte Haut zerstören. Es ist das erste HIFU - Gerät dieser Art im deutschsprachigen Raum, mit dem erstmals nicht nur die Tumorbehandlung, sondern auch eine bildgebende Steuerung über die selbe Ultraschallsonde möglich ist. Zudem bleibt diese während der ganzen Behandlung außerhalb des Kö rpers.", 5 "language" : "de", 6 "entities" : [ 7 { 8 "name" : "Schallwellen", 9 " uri" : " de. dbpedia. org/ resource/ Schall", 10 "offset" : 11, 11 " precision" : , 12 "_id" : ObjectId ("53 c50fe1e6fa901c10cf1cba"), 13 "types" : [ 14 " DBpedia: Misc" 15 ] 16 }, 17 { 18 "name" : "Tumoren", 19 " uri" : " de. dbpedia. org/ resource/ Tumor", 20 "offset" : 34, 21 " precision" : , 22 "_id" : ObjectId ("53 c50fe1e6fa901c10cf1cb9"), 23 "types" : [ 24 " DBpedia: Misc" 25 ] 26 }, 27 { 28 "name" : "Radiologie", 29 " uri" : " de. dbpedia. org/ resource/ Radiologie", 30 "offset" : 58, 31 " precision" : 1, 32 "_id" : ObjectId ("53 c50fe1e6fa901c10cf1cb8"), 33 "types" : [ 34 " DBpedia: Misc" 35 ] 36 }, 37 { 38 " name" : " Universitätsklinikum Bonn", 39 " uri" : " de. dbpedia. org/ resource/ Universitätsklinikum_Bonn ", 40 "offset" : 72, 41 " precision" : 1, 42 "_id" : ObjectId ("53 c50fe1e6fa901c10cf1cb7"), 43 "types" : [ 44 " DBpedia: Place",

88 7. Evaluierung " DBpedia: ArchitecturalStructure", 46 " DBpedia: Building", 47 " DBpedia: Hospital" 48 ] 49 }, 50 { 51 "name" : "Ultraschall", 52 " uri" : " de. dbpedia. org/ resource/ Ultraschall", 53 "offset" : 155, 54 " precision" : , 55 "_id" : ObjectId ("53 c50fe1e6fa901c10cf1cb6"), 56 "types" : [ 57 " DBpedia: Misc" 58 ] 59 }, 60 { 61 "name" : "Tumore", 62 " uri" : " de. dbpedia. org/ resource/ Tumor", 63 "offset" : 234, 64 " precision" : , 65 "_id" : ObjectId ("53 c50fe1e6fa901c10cf1cb5"), 66 "types" : [ 67 " DBpedia: Misc" 68 ] 69 }, 70 { 71 "name" : "Haut", 72 " uri" : " de. dbpedia. org/ resource/ Haut", 73 "offset" : 285, 74 " precision" : , 75 "_id" : ObjectId ("53 c50fe1e6fa901c10cf1cb4"), 76 "types" : [ 77 " DBpedia: Misc" 78 ] 79 }, 80 { 81 "name" : "Tumorbehandlung", 82 " uri" : " de. dbpedia. org/ resource/ Tumor", 83 "offset" : 398, 84 " precision" : , 85 "_id" : ObjectId ("53 c50fe1e6fa901c10cf1cb3"), 86 "types" : [ 87 " DBpedia: Misc" 88 ] 89 }, 90 { 91 "name" : "Ultraschallsonde", 92 " uri" : " de. dbpedia. org/ resource/ Sonografie", 93 "offset" : 470, 94 " precision" : , 95 "_id" : ObjectId ("53 c50fe1e6fa901c10cf1cb2"), 96 "types" : [ 97 " DBpedia: Misc" 98 ] 99 }

89 7. Evaluierung ], 101 " processed" : true, 102 "corpuses" : [ 103 ObjectId ("53 c50fcbe6fa901c10cf1c3b") 104 ], 105 " creation_date" : ISODate (" T08:12:10.000Z"), 106 " title" : " Gebündelte Schallwellen zerstören Tumoren", 107 " v" : 0, 108 "annotation" : "" 109 } 1 { Quellcode 7.2: Corpus der Pressemitteilungen der Universität Bonn in Datenbank 2 "_id" : ObjectId ("53 c50fcbe6fa901c10cf1c3b"), 3 " user" : ObjectId (" dc5394c042203f0e7"), 4 "input_type" : "feed", 5 " input" : " www3.uni - bonn.de/ pressemitteilungen - rss/ RSS", 6 " input_count" : 50, 7 "language" : "de", 8 " name" : " Pressemitteilungen Universität Bonn", 9 "files" : [], 10 "nlp_api" : "DBpedia -Spotlight -DE", 11 " creation_date" : ISODate (" T11:26:03.578Z"), 12 " processed" : true, 13 " v" : 0 14 } Quellcode 7.3: Benutzer der den Corpus der Pressemitteilungen der Universität Bonn erstellt hat in der Datenbank 1 { 2 "username" : "navid", 3 "password" : "*******", 4 "first_name" : "Navid", 5 "last_name" : "Nourbakhsh", 6 " " : "[email protected] -bonn.de", 7 "_id" : ObjectId (" dc5394c042203f0e7"), 8 "social_networks" : [], 9 " registration_date" : ISODate (" T14:34:53.119Z"), 10 " v" : 0 11 }

90 7. Evaluierung Versuchsdurchführung und Auswertung Die aus context exportierte NIF-Dokument ist im selben Ordner wie der Validator in die Datei 53c50fcbe6fa901c10cf1c3b.ttl gespeichert. Ein Auszug der Datei ist in Quellcode 7.4 abgebildet. Für den start des Validationsvorganges wird mit der folgenden Zeile aufgerufen: java -jar validate.jar intype file input 53c50fcbe6fa901c10cf1c3b.ttl Der Parameter intype file signalisiert dem Validator das es sich bei den Eingabedaten um eine Datei handelt. Der Parameter input übergibt den Dateinamen an den Validator. Nach dem Aufruf des Validators wird folgende Meldung ausgegeben: [INFO SimpleTestExecutorMonitor] Testing uri [INFO SimpleTestExecutorMonitor] Tests run: 136, Failed: 0, Timeout: 0, Error:0. Individual Errors: 0 0 log messages found (could be debug messages, errors are displayed separately). Die Ausgabe bedeutet, dass 136 verschiedene Tests durchgeführt worden sind und dabei alle durchgeführten Tests erfolgreich verlaufen sind. Das Bestehen der Tests, bedeutet das es sich bei dem Dokument um ein Valides NIF-Dokument handelt. Quellcode 7.4: Ein Artikel aus der exportierten NIF-Dokument 1 <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571> 2 a nif: String, nif: Context, nif: RFC5147String ; 3 nif: isstring """ Gebündelte Schallwellen zerstören Tumoren. Die Klinik für Radiologie am Universitätsklinikum Bonn hat ein neuartiges Gerät für Hochintensiven Fokussierten Ultraschall ( HIFU) in Betrieb genommen. Mit diesem neuen Verfahren lassen sich Tumore gezielt und nicht - invasiv durch die intakte Haut zerstören. Es ist das erste HIFU - Gerät dieser Art im deutschsprachigen Raum, mit dem erstmals nicht nur die Tumorbehandlung, sondern auch eine bildgebende Steuerung über die selbe Ultraschallsonde m öglich ist. Zudem bleibt diese während der ganzen Behandlung außerhalb des Körpers."""^^ xsd: string; 4 nif: beginindex "0"^^ xsd: nonnegativeinteger; 5 nif: endindex "571"^^ xsd: nonnegativeinteger; 6 dcterms: identifier "53 c50fcce6fa901c10cf1c46 "^^ xsd: string ; 7 dcterms: ispartof <http :// :8080/ context/ corpus/53 c50fcbe6fa901c10cf1c3b >; 8 dcterms: created " T08:12:10.000Z"^^ xsd: datetime ; 9 dcterms: datesubmitted " T11:26:03.578Z"^^ xsd: datetime ; 10 dcterms: contributor " navid"^^ xsd: string ; 11 itsrdf: taconfidence "0.2"^^ xsd: decimal ; 12 nif: title """ Gebündelte Schallwellen zerstören Tumoren """^^ xsd: string ; 13 dcterms: language "de"^^ dcterms: RFC4646;

91 7. Evaluierung nif: sourceurl < www3.uni - bonn.de/ Pressemitteilungen / > ; 15 dcterms: source """ Gebündelte Schallwellen zerstören Tumoren. Die Klinik für Radiologie am Universitätsklinikum Bonn hat ein neuartiges Gerät für Hochintensiven Fokussierten Ultraschall ( HIFU) in Betrieb genommen. Mit diesem neuen Verfahren lassen sich Tumore gezielt und nicht - invasiv durch die intakte Haut zerstören. Es ist das erste HIFU - Gerät dieser Art im deutschsprachigen Raum, mit dem erstmals nicht nur die Tumorbehandlung, sondern auch eine bildgebende Steuerung über die selbe Ultraschallsonde m öglich ist. Zudem bleibt diese während der ganzen Behandlung außerhalb des Körpers."""^^ xsd: string <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =12,24> 18 a nif: String, nif: RFC5147String ; 19 a nif: Word; 20 nif: referencecontext <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571>; 21 nif: anchorof """ Schallwellen """^^ xsd: string ; 22 nif: beginindex "12"^^ xsd: nonnegativeinteger; 23 nif: endindex "24"^^ xsd: nonnegativeinteger; 24 itsrdf: taconfidence " "^^ xsd: decimal ; 25 dcterms: identifier "53 c50fe1e6fa901c10cf1cba "^^ xsd: string ; 26 itsrdf: taclassref < dbpedia. org/ ontology/misc >; 27 itsrdf: taidentref < de. dbpedia. org/ resource/ Schall >; <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =35,42> 30 a nif: String, nif: RFC5147String ; 31 a nif: Word; 32 nif: referencecontext <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571>; 33 nif: anchorof """ Tumoren """^^ xsd: string ; 34 nif: beginindex "35"^^ xsd: nonnegativeinteger; 35 nif: endindex "42"^^ xsd: nonnegativeinteger; 36 itsrdf: taconfidence " "^^ xsd: decimal ; 37 dcterms: identifier "53 c50fe1e6fa901c10cf1cb9 "^^ xsd: string ; 38 itsrdf: taclassref < dbpedia. org/ ontology/misc >; 39 itsrdf: taidentref < de. dbpedia. org/ resource/tumor >; <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =59,69> 42 a nif: String, nif: RFC5147String ; 43 a nif: Word; 44 nif: referencecontext <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571>; 45 nif: anchorof """ Radiologie """^^ xsd: string ; 46 nif: beginindex "59"^^ xsd: nonnegativeinteger; 47 nif: endindex "69"^^ xsd: nonnegativeinteger; 48 itsrdf: taconfidence "1"^^ xsd: decimal ; 49 dcterms: identifier "53 c50fe1e6fa901c10cf1cb8 "^^ xsd: string ; 50 itsrdf: taclassref < dbpedia. org/ ontology/misc >; 51 itsrdf: taidentref < de. dbpedia. org/ resource/ Radiologie >; <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =73,98> 54 a nif: String, nif: RFC5147String ; 55 a nif: Word; 56 nif: referencecontext <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571>;

92 7. Evaluierung nif: anchorof """ Universitätsklinikum Bonn"""^^ xsd: string ; 58 nif: beginindex "73"^^ xsd: nonnegativeinteger; 59 nif: endindex "98"^^ xsd: nonnegativeinteger; 60 itsrdf: taconfidence "1"^^ xsd: decimal ; 61 dcterms: identifier "53 c50fe1e6fa901c10cf1cb7 "^^ xsd: string ; 62 itsrdf: taclassref < dbpedia. org/ ontology/place >; 63 itsrdf: taclassref < dbpedia. org/ ontology/ ArchitecturalStructure >; 64 itsrdf: taclassref < dbpedia. org/ ontology/ Building >; 65 itsrdf: taclassref < dbpedia. org/ ontology/ Hospital >; 66 itsrdf: taidentref < de. dbpedia. org/ resource/ Universitätsklinikum_Bonn >; <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =156,167 > 69 a nif: String, nif: RFC5147String ; 70 a nif: Word; 71 nif: referencecontext <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571>; 72 nif: anchorof """ Ultraschall """^^ xsd: string ; 73 nif: beginindex "156"^^ xsd: nonnegativeinteger; 74 nif: endindex "167"^^ xsd: nonnegativeinteger; 75 itsrdf: taconfidence " "^^ xsd: decimal ; 76 dcterms: identifier "53 c50fe1e6fa901c10cf1cb6 "^^ xsd: string ; 77 itsrdf: taclassref < dbpedia. org/ ontology/misc >; 78 itsrdf: taidentref < de. dbpedia. org/ resource/ Ultraschall >; <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =235,241 > 81 a nif: String, nif: RFC5147String ; 82 a nif: Word; 83 nif: referencecontext <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571>; 84 nif: anchorof """ Tumore """^^ xsd: string ; 85 nif: beginindex "235"^^ xsd: nonnegativeinteger; 86 nif: endindex "241"^^ xsd: nonnegativeinteger; 87 itsrdf: taconfidence " "^^ xsd: decimal ; 88 dcterms: identifier "53 c50fe1e6fa901c10cf1cb5 "^^ xsd: string ; 89 itsrdf: taclassref < dbpedia. org/ ontology/misc >; 90 itsrdf: taidentref < de. dbpedia. org/ resource/tumor >; <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =286,290 > 93 a nif: String, nif: RFC5147String ; 94 a nif: Word; 95 nif: referencecontext <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571>; 96 nif: anchorof """ Haut"""^^ xsd: string ; 97 nif: beginindex "286"^^ xsd: nonnegativeinteger; 98 nif: endindex "290"^^ xsd: nonnegativeinteger; 99 itsrdf: taconfidence " "^^ xsd: decimal ; 100 dcterms: identifier "53 c50fe1e6fa901c10cf1cb4 "^^ xsd: string ; 101 itsrdf: taclassref < dbpedia. org/ ontology/misc >; 102 itsrdf: taidentref < de. dbpedia. org/ resource/haut >; <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =399,414 > 105 a nif: String, nif: RFC5147String ; 106 a nif: Word; 107 nif: referencecontext <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571>;

93 7. Evaluierung nif: anchorof """ Tumorbehandlung """^^ xsd: string ; 109 nif: beginindex "399"^^ xsd: nonnegativeinteger; 110 nif: endindex "414"^^ xsd: nonnegativeinteger; 111 itsrdf: taconfidence " "^^ xsd: decimal ; 112 dcterms: identifier "53 c50fe1e6fa901c10cf1cb3 "^^ xsd: string ; 113 itsrdf: taclassref < dbpedia. org/ ontology/misc >; 114 itsrdf: taidentref < de. dbpedia. org/ resource/tumor >; <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =471,487 > 117 a nif: String, nif: RFC5147String ; 118 a nif: Word; 119 nif: referencecontext <http :// :8080/ context/ article/53 c50fcce6fa901c10cf1c46# char =0,571>; 120 nif: anchorof """ Ultraschallsonde """^^ xsd: string ; 121 nif: beginindex "471"^^ xsd: nonnegativeinteger; 122 nif: endindex "487"^^ xsd: nonnegativeinteger; 123 itsrdf: taconfidence " "^^ xsd: decimal ; 124 dcterms: identifier "53 c50fe1e6fa901c10cf1cb2 "^^ xsd: string ; 125 itsrdf: taclassref < dbpedia. org/ ontology/misc >; 126 itsrdf: taidentref < de. dbpedia. org/ resource/ Sonografie >; 127.

94 Teil VIII. Zusammenfassung und Ausblick

95 8. Zusammenfassung und Ausblick 8.1. Zusammenfassung In der vorliegenden Arbeit wurde die Entwicklung eines RDF-Backends bestehend aus eine REST API für das Exportieren der Daten und einem SPARQL-Endpoint für das stellen von SPARQL Anfragen für den semantischen Webplattform context behandelt. Zunächst wurden die Grundlagen des Semantic Web und der verwendeten Techniken von Node.JS und MongoDB erläutert (2). Das dritte Kapitel handelte vom LOD2 Projekt welches die bessere und einfachere Zusammenarbeit von Linked Data Programmen zum Ziel hat. Anschließend wurde das Natural language Processing Interchange Format (NIF) welches im rahmen des LOD2 Projekts Entwickelt wurde und für bessere Interoperabilität zwischen verschiedenen NLP Programmen sorgen soll (3). Das vierte Kapitel ermittelte die Anforderungen jede Teilkomponente an einem RDF-Backend und zeigte welche Eigenschaften und Limitierungen bei dem Entwurf zu berücksichtigen sind (4). Dabei soll die Architektur alle Importierungsarten und vorhandene NLP Services unterstützen und in Zukunft leicht erweiterbar sein. Die Datenbank muss das Speichern von Triplen erlauben und per SPARQL abgefragt werden können. Das NIF-Format verlangt, dass alle Texte im Unicode NFC Format vorliegen und durch den NIF-Validator validiert werden. Die Sicherheitsanforderungen verlangen, dass einzelne teile des RDF-Backends deaktivierbar sein müssen und das Daten nicht per SPARQL Anfragen veränderbar sein dürfen. Im fünften Kapitel wurden die Design Entscheidungen aufgrund der gestellten Anforderungen im vierten Kapitel beschrieben. So setzt das RDF-Backend auf die MongoDB Datenbank mit der Bibliothek rdfstorejs damit context leichter als Standalone Lösung eingesetzt werden kann. Zudem wurden die für den Datenaustausch wichtigen Felder identifiziert und durch ein entsprechendes Mapping in das NIF Format überführt (5). Die Unterstützung aller Importierungsarten und NLP Services, inklusive zukünftig hinzukommende Importierungsarten und NLP Services wird durch das verarbeiten der gespeicherten Daten nach der Annotierung und Speicherung in die Datenbank gewährleistet. Das sechste Kapitel beschreibt die Implementierung das in drei unabhängig arbeitende Modulen aufgeteilten RDF-Backends (6). Das für die Exportierung zuständige Modul implementiert verschiedene Pfade über die ein Artikel, ein Corpus, alle Benutzer Corpuse oder alle Artikel exportiert oder aus der Datenbank entfernt werden können. Die Speicherung der Daten in der Triplestore Datenbank kann deaktiviert werden. Das NIF-Module übernimmt das Mapping der ihr übergebene Felder in ein valides NIF-Dokument wie im fünften Kapitel beschrieben. Außerdem werden alle Texte in Unicode NFC Format konvertiert und die Position zu der Entitäten im Text neu bestimmt. Das SPARQL Modul stellt ein SPARQL-Endpoint mit der vollständigen Unterstützung des SPARQL 1.0 Protokolls zur Verfügung. Die gespeicherten Daten können per HTTP Methoden GET und POST abefragt werden. Als Ausgabeformatten werden RDF/XML und JSON-LD unterstützt.

96 8. Zusammenfassung und Ausblick 89 Die NIF-Spezifikation schreibt die Validierung der ausgegebenen Daten anhand des NIF- Validators vor. So wurde im siebten Kapitel die Evaluation anhand des NIF-Validators für ein erstelltes NIF-Dokument aus den Daten einen Corpuses vorgenommen Ausblick Seit dem viel beachteten Artikel von Tim Berners-Lee über die Idee von Semantic Web hat sich bereits viel verändert. So versucht Google durch die Einführung des Knowledge Graphen im Jahr 2012 [Singhal] nicht mehr nur Zeichenketten in Dokumenten zu suchen sondern auf die Fragen des Benutzers zu antworten. So wird bei der suche nach dem Begriff Universität Bonn die details für das Rheinische Friedrich-Wilhelms-Universität Bonn angezeigt. Durch den großen Marktmacht der Suchmaschinen und in der Hoffnung auf eine bessre Positionierung innerhalb der Suchergebnissen, gehen immer mehr Webseiten dazu über ihre Daten mit Computerverarbeitbare Meta Informationen anzureichern. Bis zur Erfüllung der Vision von Berners-Lee wird es wohl noch lange dauern. Das in diese Arbeit verwendete NIF-Format ist ein guter Schritt in Richtung größere Interoperabilität zwischen verschiedenen NLP Programmen wie sie im LOD2 Stack verwendet werden. Die Spezifikation befindet sich jedoch noch im Entwurf Stadium und die Arbeit dran sind noch nicht endgültig abgeschlossen. Sie hat einige Limitierungen die bei der Erstellung des Mappings für context offensichtlich wurden. So sieht die NIF Spezifikation kein Vokabular zur Kennzeichnung der Sprache vor, so musste der Dublin Core term dcterms:language verwendet werden. Für ein auf Datenaustausch ausgelegtes Format wäre eine Möglichkeit zur Kennzeichnung der Sprache wünschenswert. Darüber hinaus kann beispielsweise bei context der Benutzer eine Sprache und ein NLP-Service auswählen, wobei beide nicht übereinstimmen müssen. Dadurch würde der Text in eine falschen Sprache annotiert werden. Das Problem verschärft sich weiter, wenn Programme versuchen die Sprache eines Textes automatisch zu erkennen. Dabei würde es zwangsläufig zur eine falschen Erkennung der Sprache und dementsprechend die Annotierung oder Kennzeichnung in eine falschen Sprache kommen. Deshalb wäre eine Term mit der unabhängig von der erkannten bzw eingestellten Sprache gekennzeichnet werden kann in welche Sprache ein Text annotiert worden ist nützlich. Für einen bessere Zusammenarbeit zwischen verschiedenen NLP Programmen kann auch die Information durch welches NLP-Service und durch welches Programm der Text bereits bearbeitet worden ist. So kann Beispielsweise die mehrfach Annotierung durch verschiedene Programme mit der DBPedia-Spotlight Service vermieden werden. Die Angeführten Anwendungsfälle und Vorschläge zu deren Lösung wurden der für das NIF-Format zuständige Arbeitsgruppe mitgeteilt und sollen bei der Weiterentwicklung von NIF berücksichtigt werden. <TODO: Abshluss Satz schreiben> <TODO: Anführungszeichen überall Überprüfen und ob es da lieber Kursiv geschrieben wird> <TODO: Entscheiden ob häufige Fremwörter in Kursiv oder normal geschrieben werden>

97 Literaturverzeichnis [Auer u. a. 2007] Auer, Sören ; Bizer, Christian ; Kobilarov, Georgi ; Lehmann, Jens ; Cyganiak, Richard ; Ives, Zachary: Dbpedia: A nucleus for a web of open data. Springer, 2007 [Auer u. a. 2012] Auer, Sören ; Bühmann, Lorenz ; Dirschl, Christian ; Erling, Orri ; Hausenblas, Michael ; Isele, Robert ; Lehmann, Jens ; Martin, Michael ; Mendes, Pablo N. ; Van Nuffelen, Bert u. a.: Managing the life-cycle of linked data with the LOD2 stack. In: The Semantic Web ISWC Springer, 2012, S [Beckett 2004] Beckett, Dave: RDF/XML Syntax Specification (Revised) / W3C. Februar W3C Recommendation. [Berners-Lee 2014] Berners-Lee, Tim: Tim Berners-Lee Biography URL org/people/berners-lee/. Zugriffsdatum: [Berners-Lee u. a. 2005] Berners-Lee, Tim ; Fielding, R ; Masinter, Larry: RFC In: Uniform Resource Identifier (URI): Generic Syntax (2005). URL Zugriffsdatum: Juli 2014 [Berners-Lee u. a. 2001] Berners-Lee, Tim ; Hendler, James ; Lassila, Ora u. a.: The semantic web. In: Scientific american 284 (2001), Nr. 5, S [Berners-Lee u. a. 1994] Berners-Lee, Tim ; Masinter, Larry ; McCahill, Mark u. a.: Uniform resource locators (URL). (1994). URL [Brümmer Martin ] Brümmer Martin, Dimitris K.: NLP2RDF - Software. URL com/nlp2rdf/software. Zugriffsdatum: 06 Juli 2014 [BSON ] : BSON Specification. URL Zugriffsdatum: [Carothers und Prud hommeaux 2014] Carothers, Gavin ; Prud hommeaux, Eric: RDF 1.1 Turtle / W3C. Februar W3C Recommendation. [Davis und Dürst 2014] Davis, Mark ; Dürst, Martin: Unicode normalization forms URL [Dengel 2011] Dengel, Andreas: Semantische Technologien. In: Grundlagen Konzepte Anwendungen. Heidelberg (2011) [Domingue u. a. 2011] Domingue, John ; Fensel, Dieter ; Hendler, James A.: Handbook of semantic web technologies. Bd. 1. Springer, 2011 [dublindcmi ] : DCMI Metadata Terms. URL dcmi-terms/. Zugriffsdatum: Juli 2014 [Edlich u. a. 2011] Edlich, Stefan ; Friedland, Achim ; Hampe, Jens ; Brauer, Benjamin ; Brückner, Markus: NoSQL. Carl Hanser Verlag GmbH & CO. KG, 2011 [express ] : Express - node.js web application framework. URL Zugriffsdatum: Juli 2014 [Feigenbaum u. a. 2008] Feigenbaum, Lee ; Torres, Elias ; Clark, Kendall: SPARQL Protocol for RDF / W3C. Januar W3C Recommendation /

98 Literaturverzeichnis 91 [Fielding u. a. 2009] Fielding, Roy ; Gettys, Jim ; Mogul, Jeffrey ; Frystyk, Henrik ; Masinter, Larry ; Leach, Paul ; Berners-Lee, Tim: Rfc 2616, hypertext transfer protocol http/1.1, In: URL rfc. net/rfc2616. html (2009) [Frodl Christine ] Frodl Christine, Baker T.: Deutsche Übersetzung des Dublin-Core-Metadaten- Elemente-Sets. URL Zugriffsdatum: Juli 2014 [Group ] Group, AKSW R.: ConTexT. URL Zugriffsdatum: 06 Juli 2014 [gulp ] 2014 : gulp.js - The streaming build system. URL Zugriffsdatum: Juli [Hellmann a] Hellmann, Sebastian: NIF 2.0 Core Ontology. URL uni-leipzig.org/nlp2rdf/ontologies/nif-core/nif-core.html. Zugriffsdatum: [Hellmann b] Hellmann, Sebastian: NLP Interchange Format (NIF) 2.0 Core Specification. URL Zugriffsdatum: Juli 2014 [Hellmann u. a. 2013] Hellmann, Sebastian ; Lehmann, Jens ; Auer, Sören: Integrating NLP using Linked Data. In: 12th International Semantic Web Conference. Sydney and Australia : Springer, 2013, S [Hitzler u. a. 2008] Hitzler, Pascal ; Krotzsch, Markus ; Rudolph, Sebastian ; Sure, York: Semantic Web: Grundlagen. (2008) [Jackson 2011] Jackson, Joab: IBM Watson Vanquishes Human Jeopardy Foes. In: PC World 17 (2011) [Jänicke ] Jänicke, Nadine: LOD2. URL Zugriffsdatum: [Khalili u. a. 2014] Khalili, Ali ; Auer, Sören ; Ngomo, Axel-Cyrille N.: context lightweight text analytics using linked data. In: The Semantic Web: Trends and Challenges. Springer, 2014, S [Langanke ] Langanke, Christian: JS RDF store with SPARQL support. URL antoniogarrote/rdfstore-js. Zugriffsdatum: Juli 2014 [Lanthaler u. a. 2014] Lanthaler, Markus ; Sporny, Manu ; Kellogg, Gregg: JSON-LD 1.0 / W3C. Januar W3C Recommendation. [Lewandowski 2005] Lewandowski, Dirk: Web Information Retrieval - Technologien zur Informationssuche im Internet. Frankfurt am Main : DGI-Schrift (Informationswissenschaft 7), 2005 [Lewis u. a. 2013] Lewis, David ; Kosek, Jirka ; Savourel, Yves ; Lommel, Arle ; McCance, Shaun ; Lieske, Christian ; Sasaki, Felix ; Filip, David: Internationalization Tag Set (ITS) Version 2.0 / W3C. Oktober W3C Recommendation. [lod2 ] Nuffelen, Bert van ; Tramp, Sebastian ; Deblieck, Bastiaan: How-To Contibute to the LOD2 stack. URL Zugriffsdatum: [Mendes u. a. 2011] Mendes, Pablo N. ; Jakob, Max ; García-Silva, Andrés ; Bizer, Christian: DBpedia spotlight: shedding light on the web of documents. In: Proceedings of the 7th International Conference on Semantic Systems ACM (Veranst.), 2011, S. 1 8 [MongoDB ] MongoDB: MongoDB Database References. URL manual/reference/database-references/. Zugriffsdatum:

99 [Mongodb Object ID ] : ObjectId. URL object-id/#core-object-id-class. Zugriffsdatum: [Ngomo u. a. 2011] Ngomo, Axel-Cyrille N. ; Heino, Norman ; Lyko, Klaus ; Speck, René ; Kaltenböck, Martin: Scms semantifying content management systems. In: The Semantic Web ISWC Springer, 2011, S [Nourbakhsh ] Nourbakhsh, Navid: context - Lightweight Text Analytics using Linked Data. URL Zugriffsdatum: Juli 2014 [Phillips und Davis 2009] Phillips, A ; Davis, M: RFC4646: Tags for Identifying Languages [rdfstorejscurrent ] Verborgh, Ruben: rdfstore-js. URL rdfstore-js/blob/4d86f7897c9f554f48dedc2641b279deaee3f931/readme.md. Zugriffsdatum: Juli 2014 [Research ] Research, AKSW G.: context. URL [Roden 2014] Roden, G.: Node.js & Co.: Skalierbare, hochperformante und echtzeitfähige Webanwendungen in JavaScript entwickeln. Dpunkt.Verlag GmbH, ISBN [Seaborne 2013] Seaborne, Andy: SPARQL 1.1 Query Results JSON Format / W3C. März W3C Recommendation. [Seaborne und Harris 2013] Seaborne, Andy ; Harris, Steven: SPARQL 1.1 Query Language / W3C. März W3C Recommendation. [Seaborne und Prud hommeaux 2008] Seaborne, Andy ; Prud hommeaux, Eric: SPARQL Query Language for RDF / W3C. Januar W3C Recommendation. [Singhal ] Singhal, Amit: Introducing the Knowledge Graph: things, not strings. URL googleblog.blogspot.co.uk/2012/05/introducing-knowledge-graph-things-not.html. Zugriffsdatum: 06 Juli 2014 [virtuoso ] : OpenLink Virtuoso Server. URL Zugriffsdatum: Juli 2014 [virtuoso-features ] : Virtuoso Universal Server - Feature Comparison Matrix. URL http: //virtuoso.openlinksw.com/features-comparison-matrix/. Zugriffsdatum: Juli 2014 [virtuoso-lod2 ] : OpenLink Virtuoso - LOD2. URL Zugriffsdatum: Juli 2014 [virtuoso-rdf ] : RDF Insert Methods in Virtuoso. URL dataspace/doc/dav/wiki/main/virtrdfinsert. Zugriffsdatum: Juli 2014 [W3C ] : W3C. URL [Walling ] Walling, Bjarke: unorm. URL Zugriffsdatum: Juli 2014 [Wilde und Duerst 2008] Type. (2008) Wilde, Erik ; Duerst, Martin: URI Fragment Identifiers for the text/plain Media

100 Erklärung der selbständigen Arbeit Ich versichere, dass ich die vorliegende Arbeit selbständig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel angefertigt habe, insbesondere sind wörtliche oder sinngemäße Zitate als solche gekennzeichnet. Mir ist bekannt, dass Zuwiderhandlung auch nachträglich zur Aberkennung des Abschlusses führen kann. Bonn, Unterschrift