Schlagwort-Archive: Grundprinzipien

Solid

Solid Basics #003 – Immer der Nase nach

Wie finde ich interessante Daten in Solid Pods? Solid arbeitet nach dem Prinzip „Follow your nose“. Sowohl Menschen, als auch Maschinen und Apps können damit, ausgehend vom Social-Web-Profil, weitere interessante Daten finden.

Mit diesem Prinzip, kannst du zum Beispiel die Folien meiner Vorträge in meinem Solid Pod entdecken. Legen wir los!

Ausgangspunkt ist mein Profil unter https://angelo.veltens.org/profile/card. Es verlinkt meine WebID mit einer Vielzahl weiterer Informationen. Wenn du den Link anklickst, öffnet sich der „Solid Data Browser“. Nicht erschrecken: er ist noch sehr hässlich, aber dennoch äußerst nützlich, um „Follow your nose“ zu verdeutlichen.

Relativ weit oben findest du meinen Namen „Angelo Veltens“ gefolgt von „performer In“ und einer Auflistung von „it“. Es handelt sich dabei um Daten-Tripel, die eine Beziehung zwischen mir und weiteren Dingen herstellen.

Alle Bestandteile dieser Tripel sind Links, die wir anklicken können, um zu verstehen was genau dahinter steckt. Klicke mit der mittleren Maustaste auf „performer In“, um den Link in einem neuen Tab zu öffnen. Du befindest dich nun auf schema.org und erfährst:

Event that this person is a performer or participant in.

Beschreibung der Beziehung „performerIn“ bei schema.org.

Wir wissen nun also, dass „perfomer In“ auf Veranstaltungen verweist, auf denen ich aufgetreten bin. Folgen wir dieser Spur weiter! Zurück auf der Profilseite klickst du auf einen der „it“-Links, um Informationen zur jeweiligen Veranstaltung abzurufen. Dort werden wir womöglich auf Vortragsfolien stoßen.

Im Data Browser öffnen sich nun Informationen zur ausgewählten Veranstaltung. Ab jetzt geht es in einer Baumstruktur weiter. Frag mich nicht warum – ich sagte bereits, das User Interface ist murks 🤷‍♂️. Bitte versuche es für den Moment zu akzeptieren und das dahinterliegende Prinzip zu verstehen.

In den Veranstaltungsdaten findest du neben Name und Beschreibung auch einen Punkt „Work Featured“. Klicke auf das kleine Dreieck vor „slides“, um weitere Daten auszuklappen. Der Type „Presentation Digital Document“ lässt erahnen, dass wir die Folien gefunden haben.

Daten eines Events in einer aufklappbaren Baumstruktur. „Work featured“ führt weiter zu den Vortragsfolien.

Um die Folien einzusehen, müssen wir aber noch die konkreten Dateien finden. Davon kann es mehrere geben. Unter „Associated Media“ kannst du einen weiteren Abschnitt „web“ und/oder „pdf“ aufklappen und kommst dort zu konkreten Ausprägungen der Folien (PDF oder HTML). Wenn du nun noch die „Content Url“ aufklappst kannst du die Folien betrachten. (Alternativ kannst du den Wert von „Content Url“ per drag-and-drop in die Browserleiste ziehen – erneut 🤷‍♂️)

Einige Ebenen tiefer finden sich die konkreten Dateien der Vortragsfolien. In diesem Bild als PDF-Dokument.

Wozu der ganze Aufriss?

Zugegeben, das war jetzt nicht nur wegen des Data-Browser-UIs eine schlechte User Experience. Darum geht es hier aber auch gar nicht.

Ein wichtiger Aspekt von Solid ist die grundsätzliche Auffindbarkeit von Daten, ausgehend vom Profil einer Benutzer:in, allein durch das Folgen von Links. In der Praxis wird das, was wir hier mühsam von Hand durchgeführt haben, durch Apps automatisiert.

Wirf einen Blick in den Abschnitt „Talks“ meiner Website. Die Seite macht genau das, was wir gerade getan haben, nur viel schneller und automatisch. Dadurch ist die Seite in der Lage alle Infos, Folien und Videoaufzeichnungen meiner Talks gebündelt und gut zugänglich darzustellen.

Durch die Trennung von Apps und Daten, sind auch andere Webseiten und Anwendungen in der Lage, diese Informationen zu verwerten.

Das Follow-your-nose-Prinzip lässt sich automatisieren. Apps können die Daten dann auch „in hübsch“ anzeigen.

Linked Data

Linked Data: Mehr als nur RDF

Das Beispiel offenerhaushalt.de zeigt, dass zur Partizipation am Web of Data mehr gehört, als die Veröffentlichung von RDF/XML-Daten. Es lohnt sich dennoch, den Schritt zu „Linked Data“ zu gehen.

Die Veröffentlichung von Daten im RDF-Format gehört zu den Linked Data Grundprinzipien, die Tim Berners-Lee aufgestellt hat. Daher freue ich mich, dass immer mehr Open-Data-Projekte neben JSON und XML, auch Daten in einer RDF-Syntax veröffentlichen.

Das allein reicht aber leider nicht aus, um von Linked Data sprechen zu können, wie ich am Beispiel der RDF/XML-Daten von offenerhaushalt.de zeigen möchte.

Rufen wir uns zunächst die Grundprinzipien noch einmal ins Gedächtnis:

  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

Ich werde diese Prinzipien nun nacheinander mit den RDF-Daten des Haushaltspostens „Bundesministerium für Bildung und Forschung“ von offenerhaushalt.de abgleichen, welche sich im Dokument http://bund.offenerhaushalt.de/30.rdf befinden.

[important]Disclaimer: Auch wenn ich in Sachen Linked Data in diesem Artikel einiges an offenerhaushalt.de zu kritisieren habe, möchte ich dies nicht als generelle Kritik am Projekt verstehen. Im Gegenteil: Ich halte das Projekt für ein Vorzeigebeispiel der Open-Data-Bewegung und spreche allen Beteiligten großen Dank und Respekt aus! Meine Kritik ist im Vergleich zu dem, was bereits geleistet wurde, eine Kleinigkeit. Ich möchte sie eher als Anregung verstanden wissen. Auch bin ich gerne bereit zu helfen, wenn Interesse besteht, die offenen Haushaltsdaten ins Web of Data zu hieven.[/important]

Use URIs as names for things

Wesensmerkmal des Web of Data ist, dass dort nicht nur reine Dokumente („Informationsressourcen„), sondern auch Daten über reale und abstrakte „Dinge“ aufzufinden sind. Diese Dinge benötigen einen global eindeutigen Namen. Genau diese Anforderung erfüllen URIs.

Bei der Namensgebung ist zu beachten, dass das „Ding“ welches beschrieben wird und die Dokumente welche es beschreiben unterschiedlich sind und deshalb auch über unterschiedliche URIs identifiziert werden müssen. Getreu dem Merksatz: „Du bist nicht deine Website„!

Das Datendokument http://bund.offenerhaushalt.de/30.rdf beschreibt ein Subjekt namens http://bund.offenerhaushalt.de/30. Unklar bleibt dabei, um was für eine Art von „Ding“ es sich dabei handelt. Ein rdf:type ist nicht hinterlegt.

Nun liegt die Vermutung nahe, dass bei offenerhaushalt.de Haushaltsposten beschrieben werden. Ruft man jedoch die URI http://bund.offenerhaushalt.de/30 im Browser oder mit Hilfe eines Tools wie curl ab, so wird ein HTML-Dokument zurückgeliefert:

user@pc:~$ curl -I http://bund.offenerhaushalt.de/30
HTTP/1.1 200 OK
Date: Wed, 02 May 2012 18:38:32 GMT
Server: Apache/2.2.14 (Ubuntu)
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 73434
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8

Auch wenn man den Accept-Header explizit auf application/rdf+xml oder text/turtle setzt, wird ausschließlich text/html zurück geliefert.

Bei http://bund.offenerhaushalt.de/30 handelt es sich also schlichtweg um ein herkömmliches HTML-Dokument und nicht um einen Haushaltsposten.

Interessant sind unter diesem Aspekt Aussagen wie zum Beispiel folgende¹:

<http://bund.offenerhaushalt.de/30> openhaushalt:is_department "true".

Das HTML-Dokument ist also eine Abteilung, soso 🙂

Wobei wir streng genommen gar nicht wissen können, was openhaushalt:is_department überhaupt bedeutet. Das Prädikat ist nämlich nicht auflösbar, womit wir beim nächsten Punkt angelangt sind:

Use HTTP URIs so that people can look up those names

Die URI des Prädikats erhält man, indem man das Namespace-Prefix durch die Namespace-URI ersetzt. Für openhaushalt:is_department ergibt sich somit http://offenerhaushalt.de/schema/0.3/is_department. Bei Abruf dieser URI erhält man leider nichts weiter als den HTTP-Fehlercode 404: Not Found. Zwar wurden HTTP-URIs verwendet, diese sind aber nicht abrufbar.

Provide useful information

Bei den abrufbaren URIs scheitert es an „nützlichen Informationen“. Wie schon im ersten Abschnitt bemerkt, liefert http://bund.offenerhaushalt.de/30 lediglich ein HTML-Dokument zurück, wohingegen die RDF-Daten eher auf ein abstraktes „Ding“, wie einen Haushaltsposten oder eine Abteilung, hindeuten.

Dieses „Ding“ müsste zunächst einmal einen eigenen Namen bekommen, z.B. http://bund.offenerhaushalt.de/30#item

Beim Abruf mittels Browser würde durch den Wegfall des Fragment-Identifiers weiterhin das HTML-Dokument http://bund.offenerhaushalt.de/30 ausgeliefert werden, wodurch die „nützlichen Informationen“ zumindest für den menschlichen Klienten weiterhin gewährleistet wären.

Fordert ein Client mittels HTTP-Accept-Header jedoch ausdrücklich RDF, dann muss dieses ebenfalls über die URI http://bund.offenerhaushalt.de/30#item respektive http://bund.offenerhaushalt.de/30 verfügbar sein, da der Client entscheidet, welches Datenformat für ihn nützlich ist. Derzeit wird aber immer HTML ausgeliefert.

Nützlich sind die Daten aber auch deshalb nicht, weil die URIs der Prädikate nicht abrufbar sind. Die verwendete Ontologie ist somit ohne API-Dokumentation nicht zu verstehen. Es bleibt unklar, was Prädikate wie openhaushalt:is_department tatsächlich bedeuten. Die RDF-Daten sind damit kein Zugewinn im Vergleich zu z.B. JSON. Die Semantik fehlt in beiden Varianten.

Include links to other URIs

Die Verlinkung beschränkt sich auf andere URIs innerhalb des Projekts offenerhaushalt.de. Eine Verlinkung ins offene Web of Data findet derzeit nicht statt. Problematisch ist auch hier wieder, dass die URIs lediglich HTML-Dokumente identifizieren und somit auch kein „internes Web of Data“ entsteht. Was bleibt sind RDF/XML-Dokumente mit Links zu HTML-Seiten.

Na und?

Nun stellt sich dem ein oder anderen sicher die Frage, wozu man diese manchmal recht akademisch anmutenden Ansätze überhaupt verfolgen sollte? Die offenen Haushaltsdaten, die derzeit vom Projekt angeboten werden, sind zweifelsohne bereits in der vorliegenden Form sehr wertvoll. Die vorliegenden RDF/XML-Daten bieten aber nach meiner Auffassung keinen Mehrwert gegenüber dem JSON-Format. Im Gegenteil: Sie sind für einen Programmierer eher noch schwerer zu verarbeiten.

In Form von Linked Data können die Daten aber ein Potential entfalten, das deutlich über den Status quo hinaus geht. Eindeutige URIs für Haushaltsposten (nicht die HTML-Seiten!) könnten z.B. auch von anderen Projekten genutzt werden um strukturierte Aussagen über diese Haushaltsposten zu treffen. Denkbar wären zum Beispiel Tools zum Bürgerhaushalt, welche ihre Nutzer die Budgets für die einzelnen Haushaltsposten neu verteilen lassen. Dadurch dass alle über die gleichen (durch URIs global benannten!) Haushaltsposten „sprechen“, ist es dabei völlig egal, auf welchem Server mit welchem Tool solch ein Bürgerhaushalt erstellt wurde. Man kann sich das ähnlich vorstellen wie heute Verlinkungen und Pingbacks in der Blogosphäre, nur dass eben nicht über Dokumente/Blogeinträge „gesprochen“ wird, sondern über Daten und Dinge, wie z.B. Haushaltsposten.

Die Verwendung von einheitlichen Ontologien macht diesen Austausch ebenfalls leichter. Zudem wird eine „API“-Dokumentation letztlich überflüssig, wenn die Prädikate der Ontologien im Web abrufbar sind uns sich auf diese Weise selbst erklären.

Fazit

Das Projekt offenerhaushalt.de stellt RDF/XML-Daten bereit, ist damit aber noch kein Teil des Web of Data. Die folgenden Kritikpunkte zeigten sich bei einem Abgleich mit den Linked Data Prinzipien von Tim Berners-Lee:

  1. URIs identifizieren lediglich Dokumente, aber keine „Dinge“ wie Haushaltsposten.
  2. Die „Ontologie“ besteht nur aus toten Links und ist damit genauso ausdruckslos wie JSON.
  3. Es findet keine Content-Negotiation statt, die Wünsche des Clients werden ignoriert.
  4. Aufgrund von 1. kann es auch keine Links auf „Dinge“ geben. Es entsteht somit kein Web of Data.
  5. Es gibt keine Verlinkungen ins Web of Data.

Werden diese Aspekte angepasst und die Linked Data Prinzipien beachtet, können die Daten von offenerhaushalt.de Teil des Web of Data werden und dadurch ihr volles Potential entfalten.

¹ Zur besseren Lesbarkeit verwende ich hier die TURTLE-Notation, obwohl die Daten im Original als RDF/XML vorliegen. Semantisch macht dies keinen Unterschied. 

Linked Data

Alles bekommt eine URI

Im vorherigen Beitrag habe ich einen kurzen Vorgeschmack auf das Thema Linked Data gegeben. Doch was genau hat es damit auf sich? Wie sieht ein „Web of Data“ aus? Lässt es sich mit den heutigen Techniken überhaupt realisieren, oder müssen wir das Internet neu erfinden? Die gute Nachricht lautet: Nein müssen wir nicht. Linked Data beruht im wesentlichen auf 4 einfachen Grundprinzipien, die Tim Berners-Lee 2006 in „Linked Data: Design Issues“ beschrieben hat:

  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 erste Regel fordert, dass wir alles mögliche über URIs identifizieren können. Es geht nicht mehr nur um Dokumente, wie im WWW. Wir wollen Daten bereitstellen, über Personen, Orte, Gegenstände, Organisationen, Pflanzen, Tiere, Gebäude… Daten über alles Mögliche. All diese Dinge bekommen eine URI.

Weiterhin fordert Regel 2, dass als Protokoll HTTP genutzt wird. Das stellt sicher, dass die URI über das Domain Name System auflösbar ist. Das ist keinesfalls selbstverständlich, es gibt nämlich zahlreiche weitere Typen von URIs, zum Beispiel sind auch tel:+1-816-555-1212 und mailto:John.Doe@example.com gültige URIs. Es gibt sogar URIs für ISBN. Jetzt könnte man auf die Idee kommen, dass doch letztere eine wunderbare Möglichkeit wären um Bücher im „Web of Data“ eindeutig zu identifizieren. Nur dummerweise haben solche URIs die Eigenschaft, dass sie eben nicht auflösbar sind, das heißt ich kann damit nichts im Web abrufen.

Genau das erfordert aber die dritte Regel. Hinter unserer URI müssen sich nützliche, standardisierte Informationen verbergen. Zum Beispiel könnte ein Webserver unter dieser URI ein XML-Dokument ausliefern, welches RDF-Daten enthält. RDF ist ein Standard zur Beschreibung von Informationen, sodass diese leicht automatisiert verarbeitet und ausgewertet werden können. Ich werde auf RDF noch genauer in einem späteren Artikel eingehen.

Die vierte und letzte Regel verknüpft unsere Daten miteinander: Die Informationen die wir ausliefern stehen nicht für sich alleine, sondern enthalten selbst wieder URIs und verweisen so auf weiterführende Informationen. Man stelle sich zum Beispiel vor, dass unter einer URI Daten über ein Buch abrufbar sind. Wir erhalten dann zum Beispiel die Information, wieviele Seiten das Buch hat und wann es erschienen ist. Aber anstatt nur den Namen des Autors, enthalten die Daten eine URI, die den Autor selbst identifiziert! Wenn wir diesem Link dann folgen, erhalten wir Informationen über den Autor, zum Beispiel sein Geburtsjahr und Links zu weiteren Büchern die er veröffentlicht hat. Diesen Links können wir wiederum folgen und so das „Web of Data“ erkunden.

Das wars! Vier einfache Grundprinzipien, so einfach wie genial! Praktische Beispiele und nähere Details wie man selbst Linked Data im Web veröffentlichen kann folgen demnächst.