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. OpenGov-Studie Abschnitt Metadaten). Für Open Data hat es sich in Europa und Amerika bewährt, die Metadaten-Strukturen 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 OGPD aussehen sollen, entwickeln wir das JSON-Schema für Open Government Data (OGD).

Die OGD-Metadaten-Struktur wird auf github.com 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.com.

Die Metadaten-Struktur, 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.com 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.

Creative Commons Lizenzvertrag
Dieses Werk bzw. Inhalt steht unter einer Creative Commons Namensnennung 3.0 Unported Lizenz.

Am 25. September 2012 trafen sich Vertreter aus Bayern, Bremen, Berlin, Baden-Württemberg und Hamburg als auch vom PortalU und von GDI-DE an unserem Institut Fraunhofer FOKUS in Berlin, um mit uns über die Metadaten-Struktur für OGDP zu diskutieren. Zudem wurde besprochen, wie bestehende Datenangebote in die OGDP überführt werden können.

Unter Harvesting versteht man das Zusammenführen von Metadaten aus verschiedenen Katalogen. Im Rahmen der OGPD werden die Metadaten der genannten Workshop-Teilnehmer sowie von DESTATIS geharvestet, insoweit sie den Minimalkriterien für Open Data entsprechen: Es werden nur solche Datensätze, Dokumente oder Applikationen übernommen, die eine frei zugängliche elektronische Ressource, eine Beschreibung und eine wohl definierte Lizenz haben.

Dazu habe ich die vorgeschlagene Metadatenstruktur erläutert. Sie wurde insbesondere bzgl. eindeutiger Bezeichner zur eindeutigen Rückverfolgung der Herkunft und zur Erkennung von Dubletten, des Umgangs mit Kontaktangaben, der Erkennung offener Lizenzen als auch der geographischen Abdeckung nachjustiert. Zudem wurden die Hauptkategorien zur Einordnung der Datensätze, Dokumente und Applikationen diskutiert und in die folgenden 14 Hauptkategorien zusammengefasst:

  • Wirtschaft und Arbeit
  • Transport und Verkehr
  • Umwelt und Klima
  • Geographie, Geologie und Geobasisdaten
  • Gesundheit
  • Verbraucherschutz
  • Infrastruktur, Bauen und Wohnen
  • Bildung und Wissenschaft
  • Öffentliche Verwaltung, Haushalt und Steuern
  • Gesetze und Justiz
  • Soziales
  • Kultur, Freizeit, Sport und Tourismus
  • Bevölkerung
  • Politik und Wahlen

Diese Hauptkategorien dienen der prinzipiellen Einordnung und werden um spezifische, beispielsweise fachspezifische, Unterkategorien ergänzt. Für das Harvesten werden bestehende Kategorisierungen wie beispielsweise in INSPIRE oder EVAS auf diese 14 Kategorien abgebildet.

Nach Klärung der Metadaten-Struktur als Zielstruktur für bereitzustellende Daten, Dokumente und Applikationen wurden verschiedene Wege zur Bereitstellung/Aufbereitung der Bestände im OGPD besprochen. Im Ergebnis werden vier verschiedene Wege realisiert und angeboten werden:

  • Passives Bereitstellen per CSW, das beispielsweise für den Geodatenkatalog und  PortalU angewendet wird
  • Passives Bereitstellen per CKAN/JSON, was beispielsweise bei Berlin, Hamburg und Bremen genutzt wird
  • Aktives Bereitstellen per CKAN-API, was beispielsweise von Bayern genutzt werden wird
  • Manuelles Eintragen per Formular, das beispielsweise vom Bundesministerium der Finanzen für die Haushaltsdaten genutzt werden wird

Das Hauptergebnis unseres Harvesting-Workshops ist sicher die überarbeitete Metadaten-Struktur, die nun unter https://github.com/fraunhoferfokus/ogd-metadata, Kurzlink: http://s.fhg.de/ogd-metadata verfügbar ist.

Das Führen der Metadaten-Struktur für OGPD auf GitHub erlaubt eine transparente, kooperative Pflege durch Versionskontrolle. Änderungswünsche können veröffentlicht werden, die Historie der Metadaten-Struktur wird dokumentiert und der aktuelle Stand ist jederzeit sichtbar.

Gerade haben Florian Marienfeld und Thomas Scheel noch eine HTML-Darstellung des JSON-Schemas der Metadaten-Struktur für OGPD aufgenommen, die die Metadaten-Struktur lesbarer und einfacher verständlich macht: http://htmlpreview.github.com/?https://github.com/fraunhoferfokus/ogd-metadata/blob/master/OGPD_JSON_Schema.html, Kurzlink: http://s.fhg.de/ogd-metadata-html

Wir freuen uns auf Eure Hinweise und Vorschläge zur Metadaten-Struktur und/oder zum Harvesten – gerne direkt unter GitHub, aber ebenso gerne hier.

Creative Commons Lizenzvertrag
Dieses Werk bzw. Inhalt steht unter einer Creative Commons Namensnennung 3.0 Unported Lizenz.