OGD 2.0 claims to be interoperable with DCAT-AP. However Interoperability should require, that it is always possible to map a dataset conformant with one standard to a dataset conformant with the other standard (even if one has to accept some loss of information in the mapping). This doesn’t not seem to be the case with OGD 2.0 and DCAT-AP.
For the Catalogue DCAT-AP makes description and publisher mandatory. OGD 2.0 has only an optional description field and no Publisher. Therefore a OGD 2.0 conformant catalogue entry cannot be conformant to DCAT-AP. OGD 2.0 requires an ID which DCAT-AP does not necessarily provide (recommended). There may be DCAT-AP conformant catalogue entry may not be OGD 2.0 conformant
Similarly, for an Element (i.e. dataset) OGD 2.0 has the mandatory properties publishing status and lizenceID, both of which only may be present at distribution level in DCAT-AP. If the distributions of a single dataset differ in this respect a OGD 2.0 conformant harvesting would require the dataset to be duplicated. While this might be possible, if the respective information is not given, the datasets will not be conformant with OGD2.0. The latter also applies to the property “Category”.
OGD 2.0 nimmt für sich in Anspruch mit DCAT-AP interoperable zu sein. Dies sollte jedoch bedeuten, dass es immer möglich ist einen Datensatz, der zu dem einen Standard konform ist, auf einen mit dem anderen Standard konformen Datensatz abzubilden. Dies scheint für OGD 2.0 und DCAT-AP jedoch nicht zuzutreffen.
Für den Katalog sind in DCAT-AP Beschreibung und Herausgeber (Publisher) verpflichtend. OGD 2.0 enhält nur die optionale Beschreibung und keinen Herausgeber. Daher kann ein OGD 2.0 konformer Katalog-Eintrag nicht zu DCAT-AP konform sein. OGD 2.0 verlangt eine ID die DCAT-AP nicht zwingend bereitstellt (optional). Es kann DCAT-AP konforme Katalog-Einträge geben, die nicht zu OGD 2.0 konform sind.
In ähnlicher Weise weist OGD 2.0 für das Element (den Datensatz)die verpflichtenden Eigenschaften veröffentlichungsstatus und lizenzID aus, welche DCAT-AP auf Ebene der Ressource führen kann. Wenn die Ressourcen eines Datensatzes sich in dieser Hinsicht unterscheiden, müsste der Datensatz für ein OGD 2.0 konformes Harvesting dupliziert werden. Während dies machbar sein könnte, wird der Datensatz jedenfalls nicht zu OGD 2.0 konform sein, wenn die entsprechende Information gar nicht vorhanden ist. Letzeres trifft auch auf die Eigenschaft „Kategorie“.
Comments
+1. Either ODG-2.0 should be interoperable by definition (i.e. matching required fields) or a mapping from DCAT-AP to ODG-2.0 and back should be standardized. Such a mapping would need to be suitable for automatic application, for example by data harvesters.
Die Idee, direkt das Mapping von DCAT-AP zu OGD-2.0 und umgekehrt zu beschreiben ist sehr gut! Wobei mir immer noch nicht klar ist, wozu man OGD benötigt, wenn es bereits DCAT / GeoDCAT gibt und dazu eine entsprechende Mapping-Vorschrift um von und zu ISO-Metadaten zu kommen.
Einen Standard für etwas macht man ja gerade, weil es bisher "Wildwuchs" gibt. Ein Standard ist aber dann überflüssig, wenn es bereits unterschiedliche Lösungsmögilchkeiten gibt, auf deren Basis man Erweiterungen oder Einschränkungen vornehmen kann. So ist es mir hier beim Lesen der diversen CodeLists in OGD 2.0 vorgekommen. Die Codelisten kommen manchmal von ISO, manchmal von woanders her und gelegentlich wurde etwas zusammengewürfelt, was offenkundig nicht zusammen passt oder aber wo zu sehen ist, dass dort etwas fehlt. Da habe ich mich gefragt, wer wohl auf so eine Zusammenstellung gekommen ist.
Zur von Frau Loddenkemper gestellten Frage nach den Hintergründen, warum wir den neuen Metadatenstandard entwickeln, haben wir bei uns im Portal einen Bereich zur Standardisierung eingerichtet (https://www.govdata.de/standardisierung ). Dort sind auch die weitere Planungen dargestellt und weitergehende Dokumente verlinkt. Das Thema steht seit 2013 auf der Standardisierungsagenda des IT-Planungsrates.
@Gkst Govdata
Die Seite kannte ich schon. Ich habe mir sie nun aber nochmals angesehen und bin dort über den Hinweis auf den deutschsprachigen Metadatenverbund auf das folgende Dokument gestoßen:
https://www.data.gv.at/wp-content/uploads/2013/08/Gegenüberstellung_MDS_DACH.pdf
Dort steht auf Seite 30 "Das entstehende Europäische (Meta-datenportal wird DCAT-AP als Auszeichnungsvokabular verwenden... Zielsetzung des europäischen (Meta-)datenportals ist es, von den nationalen Datenportalen die dortigen Metadaten automatisiert zu harvesten und zentral verfügbar zu machen. Die bereits bestehenden nationalen Datenportale müssen daher danach trachten, ihre Daten in einer Weise zu beschreiben, dass diese vom zentralen Datenportal bezogen werden können."
Wenn ich jetzt sehe, dass es für sehr umfangreiche ISO-Metadaten bereits GeoDCAT für die Transformation gibt, um die ISO-Metadaten möglichst inhaltlich verlustfrei nach DCAT zu bringen, dann stelle ich mir die Frage, wie die Transformation dieser ISO-Metadaten in Zukunft praktisch ablaufen soll.
Soll ich inhaltlich umfangreichere ISO-Metadaten zu OGD 2.0 wandeln und die inhaltlichen Verluste akzeptieren? Und vom zentralen GovData Portal für Deutschland werden dann daraus wiederum DCAT-Metadaten gemacht und für die Europäische Union bereitgestellt? - Wobei es auch da Unwegsamkeiten bezüglich des Inhaltes geben mag? - Da wäre es doch aus meiner Sicht inhaltlich sinnvoller, gleich von ISO zu GeoDCAT zu gehen. Dies könnte dann direkt vom Europäischen Portal eingelesen werden. Auf welchem Wege sollen ISO-Metadaten in das OpenData Portal Deutschland gelangen und wie sollen sie dann widerum verlustfrei zum Ausgangsmetadatum in das Europäische Metadatenportal kommen?
Ich sehe momentan eine Doppelbelastung (also doppelte Kosten) für die Bereitsteller von ISO-Metadaten, die nun schauen müssen, dass ihre ISO-Metadaten einmal zu GeoDCAT (Europäisches OpenData Portal) und ein andermal zu OGD (also dem GovData Portal für Deutschland) transformiert werden müssen, wobei OGD eben eine eigene Erfindung von Deutschland ist, die auch noch zusätzlich von z.B. den Metadatenstandards von Österreich und der Schweiz inhaltlich abweicht.
Mir persönlich ist daher immer noch nicht klar, warum OGD einen Vorteil gegenüber einem angepassten und z.B. erweiterten DCAT-Profil besitzt. Dies steht leider nicht auf der genannten Internetseite. Möglicherweise habe ich die exakte Begründung jedoch überlesen.
A list of reasons against using DCAT-AP was provided in the comment https://joinup.ec.europa.eu/asset/ogd2_0/issue/dcat-ap#comment-18465 But I think that all of them were refuted by now. See the other comments in https://joinup.ec.europa.eu/discussion/dcat-ap
Ich habe noch einmal herausgesucht, was das folgende Papier zu diesem Thema zu sagen hatte.
Bundesministerium des Innern: "Open Government Data Deutschland - Eine Studie zu Open Government in Deutschland im Auftrag des Bundesministerium des Innern", Juli 2012
(Download: https://www.verwaltung-innovativ.de/SharedDocs/Publikationen/eGovernmen…)
"Hinsichtlich Metadatenstandards ist festzuhalten, dass sowohl ISO/CSW als auch DCAT/CKAN nahtlos unterstützt werden müssen. Angesichts der gewünschten Flexibilität und der EU-weiten und Domänen-übergreifenden Verbreitung wird DCAT/CKAN als interner Standard empfohlen." (Seite 13 unten, Seite 384 unten)Kapitel 4.4 "Metadaten" ab Seite 424 beschreibt explizit, dass keine Inselllösung gewünscht ist.
"In jedem Fall wird es Aufgabe der OGPD sein, Metadaten beider Standards von Datenbereitstellern zu akzeptieren, insbesondere um ein Harvesting zu ermöglichen, also einen regelmäßigen automatischen Import von Metadaten. Dies gilt unabhängig davon, welchen Standard OGPD intern einsetzt. Denn es kann nicht von Datenbereitstellern verlangt werden, dass sie vom einen in das andere Format konvertieren oder neu implementieren, falls sie bereits einen Metadatenkatalog befüllen." (Seite 426)
"Mit der Verwendung von DCAT/CKAN muss allerdings sichergestellt werden, dass die bereits umfangreich vorhandenen Metadaten, wie die zu Geo- und Umweltdaten, ohne Aufwand und ohne Informationsverluste integriert werden können, soweit diese für Open Data relevant sind, also aufrufbare Referenzen zu maschinenverarbeitbaren Ressourcen und leicht nachvollziehbare Nutzungsbestimmungen aufweisen. Damit die dezentrale Erweiterbarkeit schlussendlich nicht in einer unübersichtlichen, nicht handhabbaren Menge von beliebigen Feldern, Bezeichnern und Schlüsselwörtern endet, muss das kontinuierliche Beobachten und Pflegen von eingesetzten Linked-Data-Konzepten als eine zentrale Aufgabe der OGPD verstanden werden." (Seite 426-427)Ich vermisse daher im bestehenden Dokument eine entsprechend Darstellung der Harvesting-Architektur. Wie ist beabsichtigt, die ISO-Welt mit der OpenData-Welt entsprechend zu verbinden? Werden entsprechende ISO2OGD20 Mapping-Tabellen noch entwickelt werden?