Eins der Hauptziele des Prototyps GovData.de ist es, möglichst viele offene Datensätze aus Deutschland in einem Katalog zu vereinigen. Der größte Teil wird dabei automatisch durch so genannte Harvester importiert. In diesem Artikel geben wir Ihnen eine Übersicht, welche Werkzeuge dabei zum Einsatz gekommen sind, und wie diese sich bewährt haben.

In früheren Artikeln hatten wir dargestellt, dass eine auf CKAN basierende Metadaten-Struktur eingesetzt wird. Außerdem berichteten wir über einen Workshop mit Betreibern der zu erntendenen Kataloge. Dabei wurden vier verschiedene Import-Wege vorgestellt: JSON-Import, CKAN-CKAN-Harvesting, CSW-ISO19115-Harvesting und CKAN-REST-API. In der Praxis haben sich sich vor allem die ersten drei Wege bewährt.

Mähdrescher

Harvesting im großen Stil
(Foto: JSmith Photo,
Lizenz: Creative Commons keine Bearbeitung)

Beim JSON-Import nennen die Betreiber der zu integrierenden Kataloge einmalig eine HTTP-URL, unter der wir tagesaktuell eine JSON-Datei abrufen können, die alle Datensätze enthält. Dieses Verfahren wurde bei Bremen, Bayern und Moers eingesetzt. Mit wenigen Feedbackschleifen konnten die Bereitsteller ihre individuellen JSON-Export-Werkzeuge so optimieren, dass eine reibungslose Integration der Metadaten möglich ist. Zunächst wurden die Metadaten einmalig mit dem Unixprogramm wget geladen, ggf. mit einem Python-Skript minimal angepasst und abschließend mit der Python-Bibliothek ckanclient ins GovData.de-CKAN geladen. Aktuell integrieren wir diese Schritte in ein eigenes CKAN-Harvesting-Plugin, was das regelmäßige Harvesting erleichtert.

Das CKAN-CKAN-Harvesting wird in den Portalen von Hamburg, Berlin, Rostock und Rheinland-Pfalz eingesetzt. Theoretisch kann hierfür die CKAN-Harvesting-Erweiterung ckanext-harvest ohne weitere Entwicklung oder Konfiguration benutzt werden, da die Bereitsteller sich an der vorgeschlagenen Metadaten-Struktur orientieren. In der Praxis müssen jedoch viele Details beachtet werden: Das Übernehmen der Kategorien (CKAN: „groups“) etwa funktioniert nur mit kleinen Tricks, teilweise wird die Zuordnung CKAN.author ↔ „Veröffentlichende Stelle“ nicht konsequent umgesetzt, der Umgang mit dem lokal eindeutigen CKAN.name und .id muss gut überlegt sein und Großbuchstaben und Sonderzeichen in den tags, also Schlagwörtern, werden nicht einwandfrei übertragen. Außerdem müssen Schlagwörter und Titel auch hier teilweise ergänzt werden, da beispielsweise der Hamburger Metadaten-Katalog natürlich nicht alle Datensätze mit „Hamburg“ verschlagwortet. Technisch ist dieser Weg trotz allem sehr elegant, da unter anderem bei jeder Aktualisierung tatsächlich nur die zwischenzeitlich geänderten Datensätze übertragen werden.

Etwas komplizierter ist der Import von Geometadaten, die nach dem Standard ISO19115 kodiert sind (vgl. Seite des AK Metadaten). Das liegt meines Erachtens daran, dass Geodaten ganz anders verteilt und konsumiert werden (sollten) als bei offenen Daten üblich. Dort wird von Produkten gesprochen, häufig CDs oder Papierkarten, die zwar anhand der Metadaten erfasst und gefunden werden, es folgt dann aber üblicherweise der Abschluss eines Vertrags und die gezielte Übergabe der Daten vom Bereitsteller an den Vertragspartner. Dementsprechend erhalten die für Open Data zentralen Angaben „Online-Ressource“ und „Lizenz“ sowohl im Standard als auch in der Benutzung durch die Datenbereitsteller nur sehr geringe Bedeutung. Hinzu kommt, dass das sehr umfangreiche (Meta-)Datenmodell von Bundesland zu Bundesland mit unterschiedlichen Profilen eingesetzt wird, so dass es schwierig ist, z. B. die veröffentlichende Stelle in allen Datensätzen des ganz Deutschland umfassenden Geoportal.de zu identifizieren.

Aus diesem Grund wurden der Import von Geoportal.de und PortalU.de vertagt. Sehr wohl konnten aber auf dem ISO19115-Weg destatis, die Regionaldatenbank und das Open-Data-Angebot des Niedersächsischen Umweltministeriums teilweise importiert werden. Hier wurde der Standard sehr konsistent umgesetzt und die Lizenzfrage pauschal geklärt (DL-DE-BY bzw. UDL). Wir haben für das Harvesten eine Variante der CKAN-Erweiterung ckanext-spatial entwickelt. Diese passt den ansonsten üblichen CSW-Client (Catalog Service for the Web) an destatis die Regionalstatistik an: Hier werden statt CSW gezippte XML-Dateien per HTTP verteilt. Beim Niedersächsischen Umweltministerium werden die relevanten Datensätze durch eine CSW-Anfrage nach „opendataident“ gefunden. Übrigens setzt Hamburg ebenfalls den CSW-Harvester ein, um Metadaten aus dem Hamburger Metadaten-Katalog in ein Hamburger CKAN zu übertragen.

Harvesting-Architektur

Harvesting-Architektur

Die ersten beiden Importer basieren nur auf der Erweiterung ckanext-harvest und wurden daher direkt im Produktiv-CKAN von GovData.de installiert. Der ISO-Harvester basiert jedoch auf der recht umfangreichen Erweiterung ckanext-spatial und wird daher auf einem getrennten Rechner betrieben. In einem weiteren Schritt werden die Datensätze dann in den eigentlichen Datenkatalog übertragen.

Beim weiteren Entwickeln von diesen und neuen Harvestern müssen nach unserer Einschätzung folgende Probleme adressiert werden:

  • Unterschiedliches Verständnis: Was genau sind Daten, Dokumente, Apps? Wie ordnen sich Dienste ein? Welche Bedeutung haben Zeitstempel, wenn Metadaten über mehrere Kataloge hinweg geharvestet werden?
  • Die Vereinheitlichung von Schlagwörter: Wie löst man mehrdeutige und unterschiedliche Bezeichnungen für identische Bedeutungen auf (Homonyme und Synonyme)? Wie fasst man ähnliche Tags zusammen (tag curation)?
  • Dubletten erkennen: Bisher bilden doppelt erfasste Daten bei GovData.de aus organisatorischen Gründen die Ausnahme. Doch je mehr Kataloge miteinander vernetzt werden, desto genauer muss darauf geachtet werden, dass anhand der Felder metadata_original_portal und metadata_original_id Dubletten zuverlässig erkannt werden.
  • Synchronisation statt Harvesting: Heute ist meist klar von wo nach wo geharvestet wird, aber auch hier sind Herausforderungen absehbar: Beispielsweise ist Berlin an den Datensätzen von destatis interessiert, die das Schlagwort Berlin enthalten; das Hochschulbibliothekszentrum des Landes Nordrhein-Westfalen (hbz) hat seine Open Data Exporte schon seit langem bei thedatahub.org registriert, sie gehören jedoch auch zu GovData.de.

Der letzte Punkt ist auch heute schon zu beobachten: Wer harvestet, wird auch geharvestet. Die GovData.de-Metadaten finden sich bei offenedaten.de. Möglicherweise wird es ein Harvesting Richtung EU und in weitere Spezialkataloge geben. Wir hoffen, dass wir durch das Freigeben der CKAN-API und das Pflegen der Metadaten-Struktur diese Prozesse unterstützen können.

Zusammenfassend lässt sich sagen, dass das Harvesting einen wesentlichen Teil der Arbeit bei GovData.de ausgemacht hat und durchaus einen entsprechenden Mehrwert bietet. Um hier kontinuierlich besser zu werden, ist viel kleinteilige Arbeit notwendig. Die Abstimmung zwischen den Bereitstellern und Katalogbetreibern sollte idealerweise zu einer nachlaufenden Standardisierung der Metadaten-Struktur und Katalog-Schnittstellen führen.

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

Print Friendly

Über den Autor: Florian Marienfeld

Keine Kommentare

  1. Pingback: Open Data | Pearltrees

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.