Dokumentation von Datensätze – Best Practices?

Hallo in die Runde! Ein Kollege hat mich gestern gefragt, ob es Standards oder sonst Vorgaben/Empfehlungen gibt für wie man offene Datensätze „richtig“ dokumentiert – also wie Datenbereitsteller sichern können, dass Datennutzenden die Struktur und Inhalte eines Datensatzes verstehen.

Ich kenne keine solche Standards oder Empfehlungen, außer für die Dokumentation von APIs (i.e. OpenAPI Specification). Soweit ich gesehen habe, sagen die üblichen Open-Data-Gesetze auch nichts zur Dokumentation.

Kennt ihr was in diesem Bereich – gibt es Empfehlungen oder Best Practices, für wie man offene Datensätze dokumentiert, insbesondere hinsichtlich Struktur oder Inhalte der Dokumentation?

Die Beschreibung sollte etwas zu den Grenzen der Daten sagen, also was ist noch enthalten, was wird man nicht finden. Sind z.B. bei Anlagen nur solche vorhanden, die man wirklich vor Ort sehen kann oder auch solche, die sich noch in Genehmigung befinden. Dann sollte etwas zur Methode der Datenerhebung/Messung gesagt werden. Schön ist es auch immer, wenn noch ein Link angegeben ist, wo man mehr zum Thema erfahren kann. Die anderen wichtigen Dinge (Ort, Zeit, Aktualisierungsintervall usw.) lassen sich über DCAT-Metadaten transportieren.

Für die Beschreibung der Struktur vonTabellen setzen wir in Schleswig-Holstein auf Table Schema. Das enthält Beschreibungen der Felder, Wertebereite und Maßeinheiten. Daraus kann man auch eine menschenlesbare Beschreibung der Attribute erzeugen.

Für Daten in JSON bietet sich JSON-Schema an. Allerdings weiß ich gar nicht, ob man da auch Beschreibungen und Maßeinheiten unterbringen kann.

Hier ist ein Datensatz, den ich gut beschrieben finde: Windkraftanlagen - Datensätze - Open-Data Schleswig-Holstein

Ebenfalls richtig gut gefällt mir die Dokumentation im KBA mit den ausführlichen Referenzhandbüchern, z.B. Kraftfahrt-Bundesamt - 2024

1 „Gefällt mir“

Wie schon erwähnt gibt es da verschiedene Ansätze, je nachdem wie detailliert man beschreiben möchte. Einen Standard stellt DCAT-AP.de zur Beschreibung von offenen Daten in und außerhalb des Verwaltungskontext. Ähnlich agieren auch viele andere europäischen Länder, weil z.B. das europäische Datenportal für offene Daten Beschreibungen mit DCAT-AP (ohne „.de“) vorsieht und so direkt eine gewisse Kompatibilität (heute auch Interoperabilität) gewährleistet ist.

Je weiter man in die Tiefe gehen möchte um den Inhalt der Daten zu beschreiben, umso näher muss man auch an die jeweils zugehörigen Fachcommunities rücken. Z.B. gibt es im Vermessungswesen, im Energiesektor, usw. überall Ansätze, was eine gute Datenbeschreibung ausmacht.

Gemeinsam ist allen zeitgemäßen Ansätzen eine gewisse technologische Basis bezogen auf die Datenmodellierung (siehe RDF und eine gewisse Übereinkunft, dass bespielsweise Angaben zur Wiederverwendbarkeit (Lizenzen!), zu gewissen technischen Aussagen (Dateiformate, Schnittstellen, etc.), Kontaktstellen, um einige zu nennen, unerlässlich für eine gute Auszeichnung sind. Im Sinne einer solchen „best practice“ geben bspw. die FAIR Prinzipien einen sehr guten Leitfaden, auch wenn hier der Blick natürlich aus der Forschung kommt.