Linked Open Data

Eine kurze Einführung in Linked Open Data

Ursprünglich geschrieben im Dezember 2010, aktualisiert 2011

Vorbemerkungen

Der untenstehende Text ist ein Auszug aus einer Proseminararbeit aus dem Jahr 2010. 2011 registrierte ich eine Domain und schrieb ein paar Blog-Einträge über Neuerungen im Bereich von Linked Open Data. Kurzum: Es interessierte keine größere Menschenmasse und schließlich schloss ich den Blog. Dennoch finde ich das Thema Linked Open Data nach wie vor interessant. Wenn auch nicht immer unter dem Titel Linked Open Data, finden sich inzwischen viele Teilbereiche die durchaus davon profitieren, dass man öffentlich verfügbare Dokumente automatisch und komplett maschinell so auswerten kann, dass diese neue Erkenntnisse liefern. Klingt spannend? Ein kurzer Einstieg in die Thematik folgt.

Aktuelles aus dem Jahr 2011

Technisch ist Open Data schon seit längerer Zeit möglich. Sei es durch Standards wie SPARQL, RDF, XML oder ganz einfach durch das bloße Bereitstellen von Informationen im Web.
Doch in der letzten Zeit tut sich einiges in Sachen (Linked) Open Data auch abseits von ausgefeilten technischen Spezifikationen. So bietet Berlin sein eigenes Data-Portal seit dem Herbst diesen Jahres an. Dort findet man immerhin schon einige interessante Datensätze über Bevölkerungsentwicklung, Bildung und ähnliches. Die Datensätze stehen dabei meist in .XLS oder CSV-Dateien zur Verfügung. Diese lassen sich zumindest eingeschränkt auch weiterverwenden – wirklich gut austauschen lassen sie sich allerdings bisher nicht. Doch ein erster Schritt ist getan und hilft sicherlich interessierten Bürgern einen Einblick in die Berliner Daten zu bekommen – vielleicht finden sich auch engagierte Blogger und Journalisten die aus diesen Daten leichter lesbare Informationen zusammenstellen. Immerhin: Die ersten Daten dafür sind da.

Auch auf EU-Ebene bemüht man sich inzwischen um offene Ansätze. Und in der Schweiz finden sich Nutzer rund um Open Data [die ursprüngliche URL zum Open Data Camp besteht mittlerweile nichtmehr] zusammen. In Großbritannien legt man sich im Namen von Transparenz mächtig ins Zeug – data.gov.uk bietet eine Vielzahl an Datensätzen. Schlechte Nachrichten kommen allerdings von der anderen Seite des Atlantiks. In den USA gibt es seit längerer Zeit diverse öffentliche Data-Portale. Einigen davon droht allerdings langfristig aufgrund von Budgetkürzungen die Schließung – oder zumindest eine drastische Kürzung der Mittel.

Was ist eigentlich Linked Data?

Der Begriff Linked Open Data bezieht sich auf eine Ansammlung von Best practices für das Veröffentlichen von Informationen und für das Verbinden von strukturierten Daten im Netz. Linked Open Data ist begrifflich dabei eng mit dem semantischen Web verwoben, womit sich die Frage stellt worin sich diese Ausdrücke überhaupt unterscheiden. Tim Berners-Lee wird zu den Unterschied vom semantischen Web und Linked Data wie folgt zitiert: Linked Data is the Semantic Web done right. Demnach umschreiben beide Begriffe ähnliche Themen. Wobei Linked Open Data eher die konzeptionellen Ideen und die Festlegung elementarer Schlüssel-Technologien meint. Der Term semantisches Web hingegen beschreibt eine Ansammlung verschiedenster Technologien und Unterkonzepte, die Weiterentwicklungen hin zu maschinenlesbaren Web-Dokumenten betreffen, um die Auswertung der Informationen erheblich zu erleichtern. Linked Open Data wird im Folgendem als Unter-Konzept des semantischen Webs aufgefasst werden.

Warum braucht man ein Konzept wie Linked Open Data?

Das Web lebt von den Hyperlinks in HTML-Dokumenten auf andere, verwandte Dokumente. Somit können relevante, ähnliche Dokumente aufgefunden werden. Dennoch ist es recht schwer relevante Informationen aus den Web-Dokumenten automatisch und maschinell zu extrahieren. Die Dokumente im Web sind in der Regel nur für Menschen mitsamt ihrer Semantik auswertbar. Dies liegt primär an der Heterogenität der vorhanden Informationen. Beispiele für diese Heterogenität sind verschiedenen Sprachen, Zeichensätze, Formate und die unterschiedliche Anordnung der Information. Zudem setzen viele Dokumente implizites Wissen voraus, also Wissen das sich nur aus der Informationsaggregation ergibt. Um dieses Problem zu lösen könnte man künstliche Intelligenz einsetzen wollen um Maschinen in die Lage zu versetzten die Daten zu verstehen. Linked Open Data jedoch wählt einen anderen Weg, es sollen Web-Informationen strukturiert, in einem maschinenlesbaren Format aufgearbeitet werden – um somit die automatische Auswertung zu ermöglichen. Um das Konzept von Linked Open Data zu ermöglichen, werden verschiedene Prinzipien und offene Standards, die auch auf dieser Seite erklärt werden, verwendet.

Rating

Tim Berners-Lee stellte sogenannte Design Issues auf, die prinzipiell das Konzept von "Linked Open Data” beschreiben. So sollen URIs zur Bezeichnung von Dingen verwendet werden, die sich mittels HTTP nachschlagen lassen. Zudem sollen nützliche Informationen angeboten werden, sobald jemand die URI nachschlägt. Hierfür wurden die Standards RDF und SPARQL ausgewählt, welche jedoch erst später im Konzept von Linked Open Data eingeführt wurden. Außerdem soll beim Nachschlagen der URI auf weitere URIs verwiesen werden, die dem Thema ähneln oder in sonstiger Weise nützlich sind. Zusätzlich zu den Design Issues stellte Tim Berners Lee eine Art Bewertungssystem für Informationen im Web vor. Das 2010 veröffentlichte System hat 5 aufeinander aufbauende Stufen und dient der Beurteilung von Daten. In der ersten Stufe müssen Informationen einfach nur im Web verfügbar sein. Dies ist einfach zu veröffentlichen und gegebenenfalls für Menschen informativ. In der zweiten Stufe müssen die Informationen zudem in einem maschinenlesbaren Format vorliegen. Das Format darf dabei proprietär sein. Dies ermöglicht eine eingeschränkte Weiterverarbeitung, wobei die Veröffentlichung und Erstellung weiterhin einfach bleibt. Kritisch ist allerdings die Abhängigkeit von proprietären Formaten. In der dritten Stufe muss außerdem ein offenes Format Verwendung finden, sodass keine Abhängigkeit von bestimmten Anbietern mehr besteht. In einer vierten Stufe soll von RDF und SPARQL Gebrauch gemacht werden. Was eine anspruchsvolle Erstellung mit sich zieht. Um die fünfte Stufe zu erreichen sollen zudem Verweise auf andere Referenzen in die Informationen eingearbeitet werden.

XML

Ein wichtiger Standard im semantischen Web und damit auch bei Linked Open Data ist XML.

Auch wenn Tim Berners Lees “Design Issues” zu Linked Open Data, XML nicht explizit erwähnen, soll XML hier aufgrund seiner weiten Verbreitung kurz erwähnt werden. Zudem wird RDF, welches an späterer Stelle eingeführt wird, in der Praxis häufig kombiniert mit XML eingesetzt. So ist beispielsweise der Validator des World Wide Web Consortiums für RDF-Dokumente nur XML-Doukente mit eingebetteten RDF lesen, RDF in anderen Notationen kann nicht geparst werden (Stand: März 2011).

Eignung

XML steht für “Extensible Markup Language” was sich auf deutsch als “erweiterbare Auszeichnungssprache” lesen ließe. XML existiert seit 1998 als Empfehlung des World Wide Web Consortiums. Es handelt sich bei XML um eine Markup-Sprache, die ähnlich wie HTML funktioniert, sich jedoch generischer verhält, da es möglich ist eigene Tags zu verwenden und eine eigene logische Struktur für ein beliebiges Dokument anzulegen.
XML eignet sich dabei für verschiedenste Einsatzzwecke, so kann man mit XML Informationen zwischen verschiedenen Anwendungen austauschen (Stichwort: SOAP), da die Dateien plattform- und implementierungs-unabhängig sind. Zudem können mittels Vektorgrafiken beschreiben (SVG) oder mathematische und chemische Formeln dargestellt (MathML bzw. CML) werden. Die Einsatzzwecke von XML variieren also sehr stark da sich mittels XML Dokumente sehr individuelle Sachverhalte ausdrücken lassen.

Aufbau und Markup

XML-Dokumente besitzen sowohl eine logische als auch eine physische Struktur. Physisch sind XML Dokumente gespeicherte Einheiten (auch: Entities). Logisch hingegen besteht ein XML-Dokument hingegen aus Elementen und Attributen, sowie einem optionalen Prolog. XML strukturiert die einzelnen Informationen der Elemente mittels sogenannter “Tags”. Zur Bildung eines Tags wird einfach ein Begriff in eckige Klammern gesetzt, wobei die einzelnen Tags zudem baumartig verschachtelt werden dürfen. Jedes Tag kann zusätzlich optionale Attribute haben. Die Attribute werden dazu in die Klammern des jeweiligen Tags geschrieben und ihnen in Anführungszeichen ein Wert bzw. eine Referenz zugewiesen. Es können vorgefertigte XML-Tags verwendet werden, XML gestattet es jedoch auch beliebige neue Tags zu definieren. Diese Tags müssen jedoch zuvor in einem speziellen Dokument definiert werden, dem sogenannten Document Type Definition (DTD).

XML Dokumente können durch eine optionale Deklaration über XML-Version und Charakter Encoding eingeläutet werden.
Im Körper eines XML-Dokuments steht zuerst das Wurzelelement. Innerhalb des Wurzelelements können sowohl leere als auch “nicht leere” Elemente vorkommen. “Nicht leere” Elemente beginnen mit einem Start-Tag und enden mit einem End-Tag.

DTDs

DTDs werden dazu verwendet Strukturen und Grammatiken von XML-Dokumenten darzustellen. Es ist in DTD nicht möglich, zwischen Texten und Zahlen zu unterscheiden. Ein weiterer Nachteil ist die Tatsache, dass die DTD in einer eigenen Sprache abgefasst werden muss. Außerdem kennt die DTD keine Namensräume. Falls eigene Tags definiert wurden, sollte eine Referenz zur entsprechenden DTD in dem XML-Dokument angegeben werden.

Beispiele

Das folgende Beispiel zeigt die Angestellten einer Firma und die Hierarchie dieser Mitarbeiter sowie das Geschlecht eines einzelnen Mitarbeiters. Als Wurzel-Element ist das Tag “Firmenangehoerige” anzusehen. Boss der Firma ist “Andrea”, wobei die Hierarchie weitere Bosse kennt. So ist beispielsweise Angela der Boss von Guido. Zu sehen ist dies an der Eigenschaft “MitarbeiterNR” und “NRvonBoss”, die jeweils als Attribute verwendet werden.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Firmenangehoerige SYSTEM "Firmenangehoerige1.dtd">
<Firmenangehoerige>
<Boss MitarbeiterNR="n_1" NRvonBoss="n_1">
    <Name>Andrea</Name>
    <Geschlecht>w</Geschlecht>
        <Mitarbeiter MitarbeiterNR="n_2" NRvonBoss="n_1">
        <Name>Claudia</Name>
        <Geschlecht>w</Geschlecht>
            <Mitarbeiter MitarbeiterNR="n_3" NRvonBoss="n_2">
            <Name>Angela</Name>
            <Geschlecht>w</Geschlecht>
                <Mitarbeiter MitarbeiterNR="n_4" NRvonBoss="n_3">
                <Name>Guido</Name>
                <Geschlecht>m</Geschlecht>
                </Mitarbeiter>
                <Mitarbeiter MitarbeiterNR="n_5" NRvonBoss="n_3">
                <Name>Hanna</Name>
                <Geschlecht>w</Geschlecht>
                </Mitarbeiter>
            </Mitarbeiter>
        </Mitarbeiter>
</Boss>
</Firmenangehoerige>

Die dazugehörige DTD:

<!— Firmenangehoerige1.dtd —>
<!ELEMENT Firmenangehoerige (Boss)>
<!ELEMENT Name (#PCDATA)>
<!ELEMENT Geschlecht (#PCDATA)>
<!ELEMENT Boss (Name,Geschlecht,Mitarbeiter+)>
<!ELEMENT Mitarbeiter (Name,Geschlecht,Mitarbeiter*)>
<!ATTLIST Mitarbeiter MitarbeiterNR ID #REQUIRED>
<!ATTLIST Mitarbeiter NRvonBoss IDREF #REQUIRED>
<!ATTLIST Boss MitarbeiterNR ID #REQUIRED>
<!ATTLIST Boss NRvonBoss IDREF #IMPLIED>

Die Einzelnen Elemente werden jeweils mit Hilfe von eckigen Klammern in denen das Schlüsselwort "Element" gefolgt von dem Namen des Elements steht, deklariert. Nach dem Namen des Elements folgen in runden Klammern welche Elemente innerhalb des jeweiligen Elements vorkommen dürfen. Elemente können innerhalb eines Elements in verschiedensten Anzahlen vorkommen. So darf im oben gezeigten Beispiel das Element "Boss" nur einmal innerhalb des Elements "Firmenangehoerige" vorkommen, kann jedoch auch leer sein. In dem Element Boss hingegen muss zumindest einmal das Element "Mitarbeiter" vorkommen. Das Element "Mitarbeiter" kann beliebig oft innerhalb von sich selbst vorkommen.
Das Beispiel ist an die Hierarchien innerhalb eines Unternehmens angelehnt, so ist davon auszugehen das es nur einen übergeordneten Boss (im Sinne eines Geschäftsführers) für das gesamte Unternehmen gibt. Ein Boss muss jedoch zumindest einen Mitarbeiter haben, da er sonst die Eigenschaft eines Boss nicht erfüllt etc.

RDF

Einführung und Syntax

Die Abkürzung RDF steht für “Resource Description Framework” und behebt Unzulänglichkeiten bei XML.
Während XML als Baumstruktur organisiert ist, ist RDF nicht als Baumstruktur anzusehen, sondern als gerichteter
Graph.
Mit der Beschreibung von RDF können Daten intuitiv beschrieben werden. Zusätzlich können Informationen leicht an beliebigen Stellen integriert werden.

Ausdrucksmöglichkeiten

RDF lässt sich in verschiedenen Varianten Darstellen. So ist es möglich RDF in XML einzubetten (“RDF/XML”). Es ist jedoch auch möglich auf eine Einbettung in andere Markup-Sprachen zu verzichten und RDF in einer kompakten Schreibweise darzustellen, wie z.B. der Notation3(N3)

Während in XML die Darstellung von Aussagen wie, “John mag Marmorkuchen” (verhältnismäßig) schwierig durch die Baum-Struktur sind. Ist eine solche Aussage in RDF verhältnismäßig leicht dargestellt:


exampel.org/John
example.org/mag
example.org/Marmorkuchen

Die einzelnen Zeilen entsprechen dabei jeweils Subjekt, Prädikat und Objekt. Der gesamte Ausdruck wird als RDF-Tripel bezeichnet.
Ein Subjekt kann dabei eine URI sein oder leer, das Prädikat kann ausschließlich eine URI sein, ein Objekt hingegen kann aus einer URI bestehen oder leer sein oder einen speziellen Wert besitzen, einem sogenannten Literal (siehe bitloeffel.de).
Die Darstellung des Codes entspricht die eines einfachen gerichteten Graphens, Subjekt und Prädikat sind dabei Knoten, das Prädikat die Kante die die beiden Knoten verbindet.

Beispiele

Es gibt auch einige Konstrukte um die Notation abzukürzen, z.B. durch sogenannte Präfixe:


@prefix prfx:<http://example.org/> .
prfx:Fabian prfx:mag prfx:Marmorkuchen.

Ein Präfix wird definiert durch

@prefix
gefolgt von dem Präfixbezeichner einem Doppelpunkt und der entsprechenden URI. Wobei die URI in eckigen Klammern steht. Die Aussage wird mit einem Punkt abgeschlossen.
Danach kann der definierte Präfix beliebig oft verwendet werden. Um den Präfix zu verwenden wird einfach der Präfix gefolgt von einem Doppelpunkt und dem Rest der URI verwendet. Um diesen Ausdruck brauchen keine eckigen Klammern mehr gesetzt werden.

RDF-Tripel können nicht nur durch Präfixe vereinfacht werden. So ist es auch denkbar, dass in einem RDF-Dokument ein Subjekt öfter als einmal benötigt wird. In diesem Fall ließen sich verschiedene RDF-Tripel mit einem Subjekt zusammenfassen.

@prefix prfx:<http://example.org/> .
prfx:John prfx:mag prfx:Marmorkuchen;
            prfx:studiertIn prfx:Passau;
            prfx:mag prfx:Blaubeerpfannkuchen .

Statt der ausgeschriebenen Version:

@prefix prfx:<http://example.org/> .
prfx:John prfx:mag prfx:Marmorkuchen .
prfx:John prfx:studiertIn prfx:Passau .
prfx:John prfx:mag prfx:Blaubeerpfannkuchen.

Die Unterschiede zwischen den Fassungen sind marginal. So wird nur bei dem ersten RDF-Tripel das Subjekt genannt. Statt die Aussage jetzt mit einem Punkt zu beenden wird das Semikolon eingeführt. Die Aussage wird erst mit dem letzten RDF-Tripel beendet. Die Zeilen-Einrückungen der verkürzten Fassung sind nur zur Verdeutlichung und können ebenso weggelassen werden, ohne einen Semantikverlust zur Folge zur haben.

Auch komplexere Sachverhalte lassen sich mittels RDF ausdrücken. So ist es gegeben falls nicht immer gewünscht an die Form von “Subjekt”, “Prädikat” und “Objekt” gebunden zu sein. Bei Rezepten ist es beispielsweise nötig zu jedem Rezept eine Zutat mit einer bestimmten Menge zuzuordnen. In RDF kann man diesen Sachverhalt ausdrücken in dem man leere Knoten einführt.

@prefix prfx:<http://example.org/kochen/> .
@prefix xmls:<http://www.w3.org/2001/XMLSchema#> .
prfx:Blaubeerpfannkuchen prfx:bestehtAus
           ( _:exn1 _:exn2 _:exn3 _:exn4) .
_:exn1 prfx:istZutat prfx:Milch;
       prfx:mengeInMl "250"^^xmls:integer .
_:exn2 prfx:istZutat prfx:Mehl;
       prfx:mengeInG "150"^^xmls:integer .
_:exn3 prfx:istZutat prfx:Blaubeeren;
       prfx:mengeInG "350"^^xmls:integer .
_:exn4 prfx:istZutat prfx:Eier;
       prfx:mengeInStk "4"^^xmls:integer .
prfx:Blaubeeren
prfx:Saison "Sommer, Herbst";
prfx:Region "Mitteleuropa".

Leere Knoten können mit

_:bezeichner
erstellt werden. Durch

prfx:Blaubeerpfannkuchen prfx:bestehtAus
           ( _:exn1 _:exn2 _:exn3 _:exn4) .

wird der Sachverhalt

prfx:Blaubeerpfannkuchen prfx:bestehtAus _:exn1 .
prfx:Blaubeerpfannkuchen prfx:bestehtAus _:exn2 .
(...)

abgekürzt.
Zusätzlich werden hier Literale verwendet, wie sie im XML-Schema des W3Cs vorgesehen wurden. Dazu wird der Wert an entsprechender Stelle in doppelte Anführungszeichen gesetzt. Falls der Datentyp ein einfacher String seien soll muss nun kein Datentyp angegeben werden. Andernfalls empfiehlt sich die explizite Angabe des Datentyps.

Aussagen lassen sich wie zuvor erwähnt auch als RDF/XML darstellen:

<?xml version="1.0"?>
<rdf:RDF xmlns:prfx="http://example.org/"
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
	<rdf:Description rdf:about="http://example.org/John">
<prfx:mag rdf:resource="http://example.org/Marmorkuchen" />
<prfx:studiertIn rdf:resource="http://example.org/Passau" />
<prfx:mag rdf:resource="http://example.org/Blaubeerpfannkuchen" />
	</rdf:Description>
</rdf:RDF>

Für diese Darstellung wird im Vergleich zur Notation3 erheblich mehr Quelltext benötigt. Jedoch lässt sich RDF/XML aufgrund der breiten Softwareunterstützung verhältnismäßig leicht verarbeiten.