Metadatenstruktur für Daten in Deutschland

Eine der wichtigsten Eigenschaften offener Daten ist der leichte Zugang zu ihnen. Datenjournalisten und Anwendungsentwickler können Daten schneller und besser erschließen, wenn diese in zentralen Portalen auffindbar sind. Da eine zentrale Datenhaltung über Verwaltungs- und Domänengrenzen hinweg aus verschiedenen Gründen kaum umsetzbar ist (heterogene Daten, verteilte Kompetenz, Interessenskonflikte, etc.) und auch wenig sinnvoll ist, wird in der Regel eine dezentrale Datenhaltung mit einem zentralen Metadatenportal genutzt. An prominenter Stelle – etwa daten.berlin.de – werden Informationen zu und Verweise auf die Daten der Datenbereitsteller gesammelt und präsentiert – in Berlin beispielsweise die verschiedener Senatsverwaltungen, der Stadtreinigung und der Verkehrsbetriebe.

Was aber wird neben Name, Beschreibung und Autor in den Metadaten offener Datensätze festgehalten? Diese Frage stellt sich beim Erfassen der Metadaten als auch beim automatischen Austausch von Metadatensätzen, dem sogenannten Harvesting. Nur wenn Struktur und Bedeutung ausreichend einheitlich oder selbsterklärend sind, lässt sich ein zentrales Portal, hier für Deutschland, realisieren, das verschiedene Datenangebote und die Inhalte bestehender Datenkataloge vereinigt.

Einheitliche Metadaten werden in vielen Domänen mit unterschiedlichen Ansätzen und Prioritäten adressiert, beispielsweise für Umweltdaten oder bibliographische Daten (vgl. Studie "Open Government Data Deutschland" Kapitel IV-4.4 zu Metadaten). Für Open Data hat es sich in Europa und Amerika bewährt, die Metadatenstrukturen von CKAN (Comprehensive Knowledge Archive Network) der OKFN zu nutzen. CKAN ist für Open Data der de-facto-Standard für Datenkatalogsoftware.

CKAN tauscht Metadaten im JSON-Format aus. Das einzige Pflichtfeld ist der Name, der zugleich für Nutzer lesbar und URL-freundlich sein sollte, alle anderen Felder sind optional. Zu den Kernfeldern zählen Titel, Beschreibung, Ressourcen (also Datendateien oder -dienste), Lizenz und Ansprechpartner. Weitere Angaben können als JSON-Wörterbuch, d.h. als verschachtelte Schlüssel-Wert-Paare abgelegt werden. Diese Konzentration auf das Wesentliche zusammen mit der großen Flexibilität dürften der Grund für die Verbreitung dieses Metadatenmodells sein.

Im Lauf der Entwicklung von Open Data vor allem in Berlin und Deutschland zeichnete sich jedoch der Wunsch nach mehr Verbindlichkeit ab: Viele Datenbereitsteller und Entwickler wollten festgelegt haben, wo welche Information in welcher Form steht. Um einerseits den minimalen, flexiblen Charakter von CKAN und JSON zu erhalten und gleichzeitig eindeutig festzulegen, wie die Metadaten für GovData aussehen sollen, wurde das JSON-Schema für Open Government Data (OGD) entwickelt.

Die OGD-Metadatenstruktur wird auf GitHub gepflegt. Sie ist nicht nur als Werkzeug gedacht, um valide Metadaten bestimmen zu können, sondern vielmehr als Kommunikationsmittel für Interessierte wie öffentliche Entscheider, Datenbereitsteller, Entwickler und andere Open-Data-Initiativen im deutschsprachigen Raum. Diesen Zwecken dient auch die frühzeitige Veröffentlichung im Beta-Stadium und die öffentlich nachvollziehbare Entwicklung auf GitHub.

Die Metadatenstruktur, die sowohl die Beschreibung von Datensätzen (inkl. von Datendiensten), von Dokumenten und von Applikationen unterstützt, ist wie folgt aufgebaut: Die wichtigsten Eigenschaften werden auf oberster Ebene abgelegt. Dazu gehören: Titel, Bezeichner, Beschreibung, Verantwortliche und Nutzungsbestimmungen. Weiterhin essenziell ist die Liste der Ressourcen, also die eigentlichen Daten, Dokumente oder Applikationen. Wichtigste Eigenschaft jeder Ressource ist wiederum deren URL. Außerdem können je Ressource  Beschreibung und Format vermerkt werden. Dieser Aufbau ermöglicht es beispielsweise, inhaltlich zusammengehörende Dateien als einen Datensatz zu erfassen, für gegebenenfalls verschiedene Zeitabschnitte, in verschiedenen Sprachen oder Formaten. Innerhalb des Bereichs "Extras" werden alle weiteren Angaben gespeichert. Dazu gehören vor allem die zeitliche und räumliche Einordnung, sowie die Angaben zur Herkunft bei importierten Einträgen.

Auf GitHub finden sich neben dem Schema auch eine tabellarische HTML-Darstellung sowie Listen der zu verwendenden Kategorien und Lizenzen. Wir freuen uns auf Kommentare, Verbesserungsvorschläge und Fragen.