Warum wir Daten verlinken müssen

Man stelle sich vor, es gäbe keine Links im WWW. Oder noch besser: Wir packen linkfreie HTML-Dokumente in ein Zip-Archiv und bieten dieses zum Download an. Klingt total bescheuert? Ist es auch. Denn mit einem „World Wide Web“ hat das dann nichts mehr zu tun.

Aber wie gehen wir eigentlich mit Daten um? Die Einsicht, dass Rohdaten in maschinenlesbarer Form veröffentlicht werden müssen, breitet sich so langsam aus. Doch reicht das wirklich aus? Ist es in Ordnung CSV- oder XML-Dateien in ZIP-Archive zu packen und zum Download anzubieten, wie es zum Beispiel data.gov tut? Es ist ein Segen im Vergleich zum Vorgehen deutscher Behörden, die Daten in PDF-Dokumenten oder Flash-Anwendungen verstecken, oder sie ganz vom Internet fern halten. Aber es ist nicht so wie es sein sollte. Es ist genauso irrsinnig wie der oben beschriebene Umgang mit HTML-Dokumenten.

Wir brauchen keine Website von der man Daten herunterladen kann. Wir benötigen ein Web aus Daten. Die Daten selbst müssen zu einem weltweiten, grenzenlosen Netz werden. Niemand geringeres als der Erfinder des WWW, Tim Berners-Lee fordert eben dies schon seit 2006. Er beschreibt 4 Grundprinzipien für „Linked Data“:

  1. Use URIs as names for things
  2. Use HTTP URIs so that people can look up those names
  3. When someone looks up a URI, provide useful information, using the standards (RDF, SPARQL)
  4. Include links to other URIs. so that they can discover more things

Die Regeln sind im Grunde genommen sehr einfach. Und doch verlangen sie ein grundlegendes Umdenken im Umgang mit Daten und dem Web insgesamt. Die erste Regel verlangt, dass wir URIs verwenden um Dinge zu benennen. Wir identifzieren bereits Webseiten über URIs – genauer: URLs – und auch die besagten ZIP-Pakete werden so identifiziert. Hier muss der erste Umdenkprozess ansetzen: Wir identifzieren nicht mehr nur Webseiten und Dateien über URIs, sondern alle möglichen Dinge. Der Begriff „Ding“ beschränkt sich dabei nicht auf konkrete, physische Objekte sondern umfasst prinzipiell alles Exisitente oder Denkbare, auch Personen, Organisationen, abstrakte Konzepte, Themengebiete, Termine und ähnliches fallen darunter.

Die zweite Regel hat einen eher technischen Hintergrund. HTTP-URIs haben schlicht den Vorteil, dass sie über das Domain Name System auflösbar sind.1 Dies ist nötig um die dritte Regel zu erfüllen: Über die URI müssen nützliche Informationen über das identifzierte „Ding“ abrufbar sein. Dass nur strukturierte Rohdaten in offenen Formaten wirklich nützlich sind, weiß jeder der die Open Data Principles verinnerlicht hat. Doch Berners-Lee fordert ausdrücklich Standards wie RDF und SPARQL.

Nie gehört? Womöglich, denn die meisten maschinenlesbaren Daten die im Web zu finden sind, liegen in Form von XML oder CSV vor. Ich werde an dieser Stelle zumindest kurz auf RDF eingehen. Wo liegt das Problem bei CSV? Das Problem sollte spätestens klar werden, wenn man einen Blick auf diese Datei wirft und versucht folgende Fragen zu beantworten:

  1. Welche Daten sind in der Datei enthalten? Worum geht es?
  2. Was bedeutet ein einzelner Datensatz / eine Zeile dieser Datei?
  3. Was bedeutet der Wert in Spalte 3 (und den anderen Spalten)?

CSV-Dateien sind nur verwertbar, wenn die Bedeutung der Daten zwischen den Kommunikationspartnern (d.h. dem der die Daten bereitstellt und demjenigen der sie weiter verarbeitet) abgestimmt ist. Außerdem muss die Bedeutung in die Anwendungen, die die Daten nutzen wollen implementiert werden. Unterschiedliche Anwendungen und sogar unterschiedliche Versionen der gleichen Anwendung könnten die Daten völlig unterschiedlich interpretieren, da die Bedeutung der Daten aus ihnen selbst nicht hervorgeht.

Anders bei RDF: Dieses Datenmodell speichert Informationen in Form von sogenannten „Tripeln“, bestehend aus Subjekt, Prädikat und Objekt. Subjekt ist die Ressource (das „Ding“), die beschrieben wird, Prädikat ist die Aussage die wir über diese Ressource treffen und Objekt ist der Wert oder Gegenstand dieser Aussage. Der Satz „Koblenz liegt am Rhein“ ist im Grunde genommen ein RDF-Tripel bei dem „Koblenz“ das Subjekt, „liegt am“ das Prädikat und „Rhein“ das Objekt ist. RDF ist lediglich ein Modell, und als solches nicht an eine spezielle Syntax gebunden. Die wichtigsten Notationsweisen stellt dieser Artikel vor.

RDF ordnet Daten in den Kontext ihrer Bedeutung ein. Während in einer CSV-Datei vermutlich in irgendeiner Spalte einfach nur das Wort „Rhein“ stehen würde, enthält das RDF-Modell die komplette Aussage „Koblenz liegt am Rhein“. Ein Web aus Daten entsteht jedoch erst durch Beachtung der vierten Regel: Wir verlinken unsere Daten und erschließen so neue Zusammenhänge! Für unser Beispiel bedeutet dies, dass „Koblenz“ und „Rhein“ nicht einfach Datenwerte sind, sondern Ressourcen die über eine URI identifiziert werden, bei deren Abruf weitere nützliche Informationen geladen werden (Regel 3!). Zum Beispiel könnten wir durch Abruf der Ressource „Rhein“ Informationen über dessen Länge finden, oder welche Städte noch an diesem Fluss liegen (Bzw. die Information, dass es sich dabei überhaupt um einen Fluss handelt!). Das enorme Potential, das die Verlinkung von Daten bietet, kann durch den folgenden RDF-Graphen bestenfalls angedeutet werden:

Ziel ist es, ein weltweites Netz aus Daten zu schaffen, in dem Informationsbestände nicht mehr voneinander abgeschottet in Datenbanken und ZIP-Archiven vermotten, sondern einen globalen Informationsraum bilden, der uns völlig neue und unerwartete Informationszusammenhänge offenbaren wird.

Weitere Informationen zu Linked Data gibt es in der entsprechenden Kategorie in meinem Blog. Dort folgen in unregelmäßigen Abständen kleinere Artikel zum Thema. Eine detailliertere Betrachtung bietet meine Studienarbeit „Chancen und Techniken von Linked Data“. Schreibt einfach in die Kommentare was ihr Näheres zu Linked Data wissen möchtet. Ansonsten bietet linkeddata.org einen guten Ausgangspunkt für eigene Recherchen.

1 Es gibt zum Beispiel Spezial-URIs für ISBN, die auf den ersten Blick hervorragend scheinen um Bücher zu identifzieren. Da diese aber nicht auflösbar (vereinfacht gesagt: über den Browser abrufbar) sind, sollte man sie für den Aufbau eines Webs aus Daten nicht verwenden, sondern sich auf die etablierten HTTP-URIs beschränken.

Dieser Artikel ist zuerst im Blog des Open Data Network erschienen. Der Autor ist Angelo Veltens.


11 Ergänzungen

  1. Ich habe gerade so meine Probleme mit der Regel „Use URIs as names for things“. Du hast zwar beschrieben, dass das nicht nur für physische Dinge gelten muss, aber mir fehlt gerade der Bezug zu realen Projekten. Wenn ich z.B. einen Datensatz über die Anzahl an Artikeln in einer bestimmten Datenbank pro Jahr veröffentliche, wo soll ich da URIs unterbringen?

    2001: 10.000
    2002: 12.000
    2003: 20.000
    2004: 60.000

    Das Dokument soll wahrscheinlich eher RDF sein, wenn ich dich richtig verstanden habe (also „10.000 of person in 2001“ oder so), aber was soll ich dann mit deiner Aussage über URIs in Bezug auf Daten anfangen? Nur dass Dokumente nicht zum zip-Download bereitstehen sollen? Das wäre für mich eine zu einfache Antwort…

    1. @Stefan:

      Vorweg: es gibt nie „die eine“ richtige Lösung, aber ich denke man könnte dein Beispiel wie folgt Umsetzen:

      Die Ressource die du beschreiben willst ist die Datenbank, denn dazu möchtest du eine Aussage treffen. Die DB könnte z.B. über folgende URI identifiziert werden: http://example.com/articledb

      Auch die einzelnen Artikelstände könnten an dieser Stelle wieder als eigene Ressourcen umgesetzt werden, da es sich ja nicht einfach um einen Datenwert handelt, sondern eine Kombination aus Jahr und Anzahl.

      Eine mögliche Lösung hab ich mal schnell in N3 in einem Pseudo-Vokabular runtergetippt:

      <http://example.com/articledb&gt;
        <foo:articlecount>
          <http://example.com/articledb#stand2001&gt;,
          <http://example.com/articledb#stand2002&gt;,
          <http://example.com/articledb#stand2003&gt;,
          <http://example.com/articledb#stand2004&gt;.

      <http://example.com/articledb#stand2001&gt;
        <foo:count> „10000“;
        <foo:year> „2001“.

      <http://example.com/articledb#stand2002&gt;
        <foo:count> „12000“;
        <foo:year> „2002“.

  2. die institutiontn der eu können das auch besonders gut. wenn du manchmal 200 dokumente durchflöhen willst, aund alle sind im .pdf-format – DA kommt freude auf.

  3. wo wir schon mal dabei sind. ein li-Tag gehört in ein ul oder ein ol-Tag. und nicht direkt in ein blockquote-Tag. Die Qualität des Codes lässt bei netzpolitik zu wünschen übrig ;)

  4. Der Hinweis auf ISBN-URIs ist eher ein gutes Beispiel dafür dass HTTP-URIs nicht in jedem Fall das Nonplusultra sind und dass RDF alleine nicht Glückseligmachend ist. Denn trotz RDF ist anscheinend nicht klar, dass eine ISBN eben nicht ein Buch identifiziert sondern eine oder mehrere Ausgaben eines Buches. Wohin soll so eine URL aufgelöst werden? Auf die Webseite des Verlages der morgen schon pleite ist oder seine Internetpräsenz umstrukturiert hat? Auf eine der vielen Bibliothek, die sich eh nicht einigen können? Die Hinweise im Artikel sind zwar richtig, aber was eigentlich zählt sind Dokumentation der Daten und Tools um sie zu verarbeiten. Für RDF gibt es zufällig viele Tools und es können gut gemeinsam nutzbare Datenbeschreibungen erstellt werden (wer hip sein will, nennt es Ontologie). Aber RDF ist nicht das Ziel sondern ein Mittel zum Ziel.

  5. Man kriegt einen ganz guten Eindruck von Linked Data, wenn man sich etwas Zeit nimmt um in http://dbpedia.org/ herumzuwühlen. Da wird auch deutlich, was noch alles zu tun ist, damit das richtig nützlich werden kann.

    Bei der ganzen Sache darf ja nicht vergessen werden, dass ein großer Teil der Daten im Web falsch, nicht nachprüfbar, oder nur vorläufig richtig ist. Der „wissenschaftliche“ Ansatz wäre daher, jedem Tripel (das ja eine Behauptung darstellt) noch ein „wer hat das behauptet?“ anzuhängen. Also, woher kommt eigentlich die Annahme, der Rhein sei 1324 Kilometer lang?

    RDF hat für diesen Zweck ein sehr praktisches Konstrukt, das sich Reifizierung nennt. Damit wird auch ein Aussagetripel wiederum zu einem „Ding“, das als Subjekt oder Objekt weiterer Tripel fungieren kann. Also z.B. „(Tüdelbüdel sagt (Rhein hat_Länge 1324km))“.

  6. XML wäre zumindest schon mal ein Anfang. XML lässt sich ja beliebig verarbeiten und steht in vielen Programmen bereits zur Verfügung, während RDF noch nicht so breit unterstützt wird. Ich finde es ganz nett, wenn ich etwa Statistiken von Stat. Bundesamt einbinden könnte, statt ein paar labrige Daten rauszukopieren.

  7. Gründe warum es nie im großen passieren wird

    1. Manche Infos müssen veröffentlicht werden, sollen aber nicht wirklich für die Öffentlichkeit gut zu finden sein, da es den Firmen, Behörden etc. z.B. peinlich ist

    2. Es ist sehr viel Arbeit, Daten zu verlinken. Man müsste sehr viel mehr Arbeit und Zeit aufwenden, um z.B. Texte zu erstellen.

    3. Manche daten sollen als Einzeldatum benutzt werden, aber die Masse der Daten bietet Missbrauchspotenzial.

    4. Es gibt ja durchaus Schnittstellen um genau diese Dateien zu finden. Z.B. Google

    5. Erstellung von Dokumenten und damit von Wissen ist nur noch gut Ausgebildeten Menschen möglich. Gerade das jeder Hinz daten erstellen kann, ist auch ein sehr großer Vorteil. Wenn es zu schwer würde Daten zu erstellen, wäre es ein priveligiertes Netz und das will ich nicht.

    Es gibt bestimmt viel mehr, was einen kritischen Blick erfordert.

  8. Ich bevorzuge Daten die für Menschen lesbar sind und entsprechend aufbereitet wurden.
    Wenn ich die Entwicklung der Einwohnerzahl von Koblenz wissen möchte, ist es mir völlig egal ob das an Saar oder Elbe liegt, 5 Ökozonen hat und da jährlich 2 Junkies sterben.

  9. Ein sehr schöner Artikel für Semantic-Web-Newbies. Im Umfeld auf netzpolitik.org sollte man das allerdings so nicht stehen lassen:

    Eine Diskussion darüber, welche Daten von wem zwischen welchen Systemen ausgetauscht werden dürfen/sollten ist meines Erachtens DRINGEND notwendig.

    Habe dazu letzte Woche auf carta.info schon einiges am Beispiel StreetView und Geotagging geschrieben.
    Wir werden hier noch einige „lustige“ Dinge zB im Bereich Personensuche erleben. Was INDECT gerade erforscht, ist nach dem Stand der KI für Privatunternehmen (!) verfügbar.

Dieser Artikel ist älter als ein Jahr, daher sind die Ergänzungen geschlossen.