Meine offenen Punkte bei Frictionless Data

Wie ich schon in dem Beitrag Wie läuft es? Reibungslos! geschrieben habe, bin ich ein großer Fan davon, die Metadaten der Daten/Dateien unter Verwendung der Frictionless Data Specification, vor allem mit Tabular Schema maschinenlesbar zu beschreiben. Allerdings sind mir bei der praktischen Arbeit mit Daten noch ein paar Punkte begegnet, die mir bei Frictionless Data noch fehlen. Diese möchte ich im Folgenden beschreiben und Lösungsvorschläge aufzeigen:

Maßeinheiten

Eine entscheidende Information für die richtige Interpretation von Daten ist das Wissen um die Maßeinheit. Ist in der Spalte “Geschwindigkeit” der Wert in km/h oder m/s. Da nur ein Faktor 3,6 beide Maßeinheiten trennt, kann man das selbst als Mensch oft nicht raten - eine Maschine schon gar nicht.

Ich schreibe Maßeinheiten daher in der Eigenschaft unit auf:

{
    "type": "number",
    "name": "Abfluss",
    "description": "Abfluss in m³/s",
    "unit": "m3/s"
}

Als Inhalt kommt dabei UCUM zum Einsatz. Unter https://ucum.nlm.nih.gov/ucum-lhc/demo.html kann man überprüfen, ob man die korrekte UCUM-Syntax verwendet hat.

→ GitHub Issue

CRS

Geographische Koordinaten kann man in unterschiedlichen Koordinatenreferenzsystem (CRS) angeben. WGS84 ist dabei ein gängiges.

Dabei kann ein CRS für eien ganze Datei gelten oder auch nur für einzelne Spalten. Das ist dann der Fall, wenn in einer einzigen Datei Koordinaten in mehreren CRS angegeben werden.

Eine einfache Möglichkeit ist es, das CRS als Eigenschaft einer Spalte anzugeben. Damit sind beide Fälle abgedeckt.

{
  "name" : "geogrLaenge",
  "type" : "number",
  "description": "Lage der Station (Längengrad)",
  "crs": "EPSG:4326"
}

→ GitHub Issue

Semantic Web Properties

Frictionless Data enthält bereits Ansätze, um die beschriebenen Daten im Semantic Web bereitzustellen. Das Tabular Schema sieht vor, dass man mit rdfTypeangeben kann, zu welcher Klasse ein Wert gehört. Für eine vollständige Beschreibung müsste jedoch auch angegeben werden, welche Propertery in einer Spalte angegeben ist.

Mein Vorschlag dafür sieht so aus:

{
  "name" : "geogrLaenge",
  "type" : "number",
  "description": "Lage des Pegels (Längengrad)",
  "rdfProperty": "https://schema.org/longitude"
}

→ GitHub Issue

WKT

Well-Known-Text (WKT) ist eine gebräuchliche Art, geographische Daten zu notieren. Es sollte in einem Frictionless Tabular Schema anzugeben, dass eine Spalte WKT enthält. Die Daten sollten während der Validierung auf syntaktische Korrektheit überprüft werden. Um möglichst rückwärtskompatibel zu sein, könnte man die Kennzeichnung mit der Eigenschaft format (wie schon für URIs und E-Mail-Adressen) vornehmen.

{
  "name": "geometry",
  "type": "string",
  "format": "wkt"
}

→ GitHub Issue

Ignorierte Zeilen am Dateiende

Leider produzieren einige Herausgeber in der öffentlichen Verwaltung CSV-Datei, die mit einigen Zeilen enden, die gar keine Daten enthalten. Typische Inhalte sind Hinweise auf den Herausgeber, gesetzliche Grundlagen der Datenerhebung oder Lizenzinformationen.

Am Anfang einer CSV-Datei lassen sich bereits Zeilen überspringen. Es wäre nützlich, wenn man auch angeben könnte, dass eine bestimmte Anzahl von Zeilen am Ende der CSV-Datei nicht berücksichtigt werden soll.

→ GitHub Issue

Zwei Sorten von Daten in einer CSV-Datei

Vielleicht wäre es besser, für die folgende Situation gar keine Lösung anzubieten, um nicht noch mehr Herausgeber zu dieser komischen Schreibweise anzuregen.

Es gibt Herausgeber in der öffentlichen Verwaltung, die in eine einzige CSV-Dateie mehrere Tabellen stecken. Die CSV-Datei ist grob so aufgebaut:

Kopfzeile Tabelle 1
erste Zeile Tabelle 1
...
letzte Zeile Tabelle 1

Kopfzeile Tabelle 2
erste Zeile Tabelle 2
...
letzte Zeile Tabelle 2

Kopfzeile Tabelle 3
erste Zeile Tabelle 3
...
letzte Zeile Tabelel 3

In so einem Fall wäre es gut, wenn man (vielleicht mit einem regulären Ausdruck) angeben könnte, in welcher Zeile einer CSV-Datei mit dem Lesen begonnen und wo aufgehört werden sollte. Im Beispiel würde die erste Tabelle vom Anfang bis “\n\n” gehen. Die zweite Tabelle würde von eindeutige erste Zeichen der Kopfzeile Tabelle 2 bis “\n\n” gehen. Die dritte Tabelle würde von eindeutige erste Zeichen der Kopfzeile Tabelle 3 bis zum Ende der Datei gehen.


Bild von Pexels auf Pixabay (zugeschnitten)