Von 3 auf 5

5-Sterne Open Data, also Linked Open Data (LOD), gelten als der Goldstandard im Bereich offener Daten. Es ist jedoch nicht nur ziemlich kompliziert, Personen ohne Informatik-Hintergrund die Ideen von LOD zu erklären, sondern auch, entsprechende Daten zu erzeugen. Reicht für das Bearbeiten einer CSV-Datei noch LibreOffice Calc, so sieht das für ein RDF-Dokument schon ganz anders aus. Ist 5 Sterne Open Data für die nächsten Jahre in der Verwaltung nicht zu erreichen? Vielleicht gibt es eine “Abkürzung”.

Wenn ich die 5-Sterne Bewertung für offene Daten erklären, so ist es bis zum dritten Stern immer einfach und alle Anwesenden können gut folgen. Klar, den Umgang mit CSV-Dateien ist man mehr oder weniger gewohnt, auch wenn Microsofts Excel es einem an dieser Stelle besonders schwer macht. Soll man etwas genötigt werden, im hauseigenen Format abzuspeichern? Mindestens LibreOffice Calc Nutzer*innen können mit CSV-Dateien aber in Regel gut umgehen. Nun kommen die verzwickten Stufen vier und fünf. Man muss für den vierten Stern jedem Eintrag einen eindeutigen Identifikator in Form eines Universal Resource Identifier (URI) geben. Das sieht aber in der Tabellenansicht komisch aus. Dass es sinnvoll ist, für jeden Eintrag einen kurzen eindeutigen Identifikator zu verden, bekommt man in der Regel noch erklärt. (Ein Beispiel: Die Badestelle Brasilien in Schönberg hat den Identifikator DESH_PR_0137.)

Zwei Arten LOD

Es werden genau genommen zwei Arten von LOD benötigt, nämlich solche für die Daten und solche für die Metadaten. Letztere findet man schon jetzt gelegentlich, wenn über LOD gesprochen wird, es aber eigentlich nur um Linked Open Metadata geht. Das sind in der Regel einfach nur Sammlungen der DCAT-AP.de Beschreibungen der Datensätze. Über den SPARQL-Endpunkt von GovData kann man z.B. die Metadaten aller Datensätze auf GovData durchsuchen.

Für eine wirklich interessante semantische Suche in den Daten benötigt man noch mehr Informationen. Meine Idee ist nun, die Frictionless Beschreibung (auch Table Schema genannt), mit der der technische Aufbau einer CSV-Dateien erklärt wird, zu verwenden, um die Daten in einer CSV-Datei in LOD umzuwandeln. Immer wenn ein neuer Datensatz ins Open-Data-Portal geladen wird oder wenn ein Datensatz aktualisiert wird, läuft ein automatischer Prozess an, der mit Hilfe der Frictionless Beschreibung die CSV-Datei interpretiert und LOD erzeugt.

Einträge automatisch umwandeln

LOD wird in Form von Tripeln (Subjekt, Prädikat und Objekt) gespeichert. Aufgabe des Transformationsprozesses ist es also aus jeder Zeile einer CSV-Datei einige Triple zu erzeugen. Zu jedem Feld in der Frictionless Beschreibung (das entspricht einer Spalte der CSV-Datei) lässt sich neben dem Datentyp schon heute angeben, zu welchem Typ/welcher RDF-Klasse ein Eintrag gehört (→ siehe Frictionless Table Schema Spezifikation). Dort lässt sich also angeben, dass die oben erwähnte Badestelle mit dem Identifikator DESH_PR_0137 vom Typ https://schema.org/Beach ist.

{
  "type": "string",
  "name": "BADEGEWAESSERID",
  "description": "Allgemein gültiger Identifikations-Code des Badegewässers",
  "constraints": { "required": true  },
  "rdfType": "http://schema.org/Beach"
}

Angenommen der vollständige URI für die Badestelle wären http://example.org/beach/DESH_PR_0137. Dann fehlt uns für die Umwandlung noch die Information, dass wir vor jeden Eintrag in der Spalte BADEGEWAESSERID den Präfix http://example.org/beach/ setzen müssen. Das könnte man angeben, wenn mann die CSV-RDF-Transformation für den Datensatz einrichtet. Eleganter wäre es aber, diese Information auch in der Frictionless Beschreibung unterzubringen, z.B. so:

  { "uriPrefix": "http://example.org/beach/" }

Mit diesen Informationen könnte während des Transformationsprozesses dieses Triple erzeugt werden:

   <http://example.org/beach/DESH_PR_0137>  a  <http://schema.org/Beach>

weitere Eigenschaften

Um die weiteren Einträge der CSV-Datei in Eigenschaften zu transformieren gibt es einen rudimentären, sofort verfügbaren und einen eleganteren Weg, der abere eine Erweiterung der Frictionless Specification benötigt.

einfacher Weg

Für den einfachen Weg erklärt man für den gesamten Datensatz ein Präfix, das vor alle Spaltennamen gesetzt wird, um daraus URIs für die Eigenschaften zu erzeugen. Im Beispiel könnte das https://lod.schleswig-holstein.de/badegewasser# sein. Dann würden Einträge in der Spalte EUANMELDUNG zu https://lod.schleswig-holstein.de/badegewasser#EUANMELDUNG umgewandelt.

Nachteil ist, dass die URIs aller Eigenschaften aus dem selben Namensraum kommen müssen. Verweise auf bestehende Eigeschaften aus anderen Namensräumen könnte man erst über eine “Umleitung” in Form von owl:sameAs-Angaben machen, die aber vermutlich (noch) nicht jede Software versteht.

eleganter Weg

Schöner wäre es, wenn man (wie schon bei den RDF-Typen) direkt an einem Feld in der Frictionless Beschreibung angeben könnte, welcher RDF-Eigenschaft es entspricht. Naheliegend wäre eine Eingabe mit dem Namen rdfProperty. Das sähe dann z.B. so aus:

{
  "type":        "string",
  "name":        "ALLGEMEIN_GEBRAEUCHL_NAME",
  "description": "allgemein gebräuchlicher Name des Badegewässers",
  "rdfProperty": "http://schema.org/name"
}
{
  "name":        "EUANMELDUNG",
  "type":        "date",
  "description": "Zeitpunkt der Anmeldung bei der EU",
  "format":      "%d.%m.%Y",
  "rdfProperty": "https://lod.schleswig-holstein.de/badegewasser#EUANMELDUNG"
}

Ein entsprechendes Issue #806 habe ich schon vor einiger Zeit bei GitHub angelegt.

Damit könnten dann folgende RDF-Daten erzeugt werden:

@prefix schema: <http://schema.org/> .
@prefix bg: <https://lod.schleswig-holstein.de/badegewasser#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://example.org/beach/DESH_PR_0137>
  a schema:Beach ;
  schema:name "Brasilien" ;
  bg:EUANMELDUNG "1991-04-15"^^xsd:date .

noch mehr Semantic Web

In Kombination mit der Eigenschaft uriPrefix lassen sich an dieser Stelle auch Verknüpfungen zu anderen Datenbeständen herstellen. So enthält der Datensatz zu den Badestellen auch eine Kennung des Gewässers, an der die Badestelle liegt, z.B. B3.9610.09.05. Wenn man für dieses Feld noch ein Präfix schreibt (hier fiktiv http://example.org/waterbody/) dann erkennt man langsam, wie sich aus den Datensätze das Semantic Web bildet.

@prefix schema: <http://schema.org/> .
@prefix bg: <https://lod.schleswig-holstein.de/badegewasser#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://example.org/beach/DESH_PR_0137>
  a schema:Beach ;
  schema:name "Brasilien" ;
  bg:EUANMELDUNG "1991-04-15"^^xsd:date ;
  bg:WASSSERKOERPER <http://example.org/waterbody/B3.9610.09.05> . 

Fazit

5-Sterne Open Data klingt für viele nach Zukunft und vielleicht auch abschreckend. Indem man bestehende Technologie kombiniert, ein paar Dinge ergänzt und geschickt miteinander verbindet, kommt man vermutlich schon ein ganzes Stück voran. Möglicherweise liegen die 5-Sterne Open Data also gar nicht mehr in so weiter Ferne.