DCAT-AP.de Konventionenhandbuch 2.0

1.4.1 Geometrische Ortsbezüge (dct:spatial mit locn:geometry)

dct:spatial kann sowohl geometrische Ortsbezüge, als auch geografische Ortsbezüge per URI und strukturierte Adressanschriften aufnehmen. Da dies von INSPIRE gefordert wird, liegt der Ortsbezug meist in Form einer Geometrie (z.B. einer Bounding Box) vor.

Beispiel zur Angabe eines Punktes mit Koordinatensystem CRS84 mit locn:geometry:

Verwendungshinweise

Zur Wahrung von Interoperabilität SOLLTEN folgende Typen verwendet werden:

• für jede Geometrie:
  • WKT, GML, und RDF+WKT/GML, entsprechend der GeoSPARQL Spezifikation,
  • KML (Keyhole Markup Language), (Hinweis: KML unterstützt nur die folgenden Geometrien: „point“, „line string“, „linear ring“ und „polygon“.)
  • RDF wie in schema.org Vokabularklassen schema:GeoCoordinates und schema:GeoShape.
• für Punkte: Eine der oben genannten Varianten oder:
  • RDF gemäß W3C Basic Geo (WGS84 lat/long) vocabulary,
  • GeoHash URIs,
  • geo URIs.

Schema.org Eigenschaften sind schema:GeoCoordinates, schema:latitude, schema:longitude.

1.4.2 Geografische Ortsbezüge per URI

Ortsbezüge können auch auf unterschiedliche Weise über einen URI angegeben werden. Dies bedeutet in der Praxis, dass Bezeichnungen aus möglichst langfristig verfügbaren (persistenten) Vokabularen (URI-Systemen) verwendet werden müssen: Dies können in einigen Fällen die vom EU Publication Office gepflegten Listen der Kontinente, Staaten oder Orte sein. In vielen Fällen kann auf GEONAMES zurückgegriffen werden.

Beispiele zur Angabe eines Ortes über Geo-URIs von geonames.org:

• http://www.geonames.org/6695072 - Europäische Union,
• http://www.geonames.org/2950157 - Land Berlin.

Aber auch andere langfristig verfügbare Vokabulare (z.B. die Ortsverzeichnisse der Vermessungsämter) können genutzt werden.

1.4.3 Strukturierte Adressanschriften (dct:spatial mit locn:Address)

Ortsbezüge können auch mit Adressen ausgedrückt werden. Das ISA² Core Location Vocabulary unterstützt im Namensraum locn: strukturierte Adressanschriften.

strukturierte Addressbestandteile von locn:Address und XÖV „Anschrift“

Das Mapping der englischen generischen Adressbestandteile der locn:Address wird in der folgenden Tabelle dargestellt:

Hinweis: Adresszusätze wie „Haus D“; „Apartment 3“ können ggf. in den für Deutschland eigentlich nicht einschlägigen Feldern locn:locatorDesignator und locn:locatorName erfasst werden.

1.4.4 Verwaltungspolitischer Geobezug als URI (dcatde:politicalGeocodingURI)

Der verwaltungspolitische Geobezug als URI (dcatde:politicalGeocodingURI) ist eine dct:spatial-nahe Eigenschaft, die dezidiert in DCAT-AP.de geschaffen wurde, um die Daten der verschiedenen deutschen Verwaltungsträger in einfacher Weise unterscheiden zu können. Dafür wurden mehrere Vokabulare gemäß URI-Konzept definiert, die von den verschiedenen Schlüssel-Listen des Statistischen Bundesamtes abgeleitet wurden. Somit sind für die unterschiedlichen Verwaltungsebenen unterschiedliche Quellen der zu verwendenden URIs vorgesehen:

1.4.5 Ebene des verwaltungspolitischen Geobezug als URI (dcatde:politicalGeocodingLevelURI)

Mit dcatde:politicalGeocodingLevelURI wird die Ebene des verwaltungspolitischen Bezugs (Bund, Land, Kommunen) kodiert. Diese kann damit getrennt vom konkret abgedeckten Gebiet ausgewertet werden.

1.4.6 Verwaltungspolitischer oder fachlicher Geobezug als beschreibender Text (dcatde:geocodingDescription)

Beispielsweise kann ein Datensatz zu einer Studie den geopolitischen Bezug „Region Leipzig und Hamburger Stadtteil Altona“ enthalten. Des Weiteren sind fachliche Bezüge denkbar wie etwa die Abdeckung des Datensatzes eines „Wahlkreises“ oder eines „Abwasserzweckverbandes“ oder einer „überregionalen Arbeitsgruppe“.

1.4.7 Verhältnis der DCAT-AP.de-Eigenschaften zu dct:spatial

Dies geschieht am einfachsten, indem die URIs als geografische Ortsbezüge per URI wiederholt werden. Für die internationale Anschlussfähigkeit können jedoch auch Alternativen verwendet werden.

Für die Bundesländer können die folgenden alternativen GeoNames-URIs genutzt werden:

1.6.1 Sammlungen über den Typ collection (dct:relation, dct:hasVersion, dct:type) (DEPRECATED)

Die Basisspezifikation DCAT vom W3C in der Version 2.0 dokumentiert die Beziehungen zwischen einem Katalog und den darin beschriebenen Datensätzen sowie Beziehungen zwischen Datensätzen und ihren Distributionen. Sie äußert sich jedoch nicht zu vielen anderen fachlich existierenden Verbindungen.

Weitere mögliche fachlich Verbindungen sind Reihen wie etwa Zeitreihen, jährliche Budgettitel oder gleich gegliederte Datensätze mit unterschiedlicher geografischer Abdeckung. Beispiele für das letztgenannte sind etwa Datensätze aus einem Wahlkreis, Wettersensoren einer bestimmten geografischen Region oder äquivalente Repräsentationen mit unterschiedlichen Koordinatensystemen.

Gemäß der Implementation Guideline „How to model data series“ wird eine Sammlung durch den Klammerwert „Collection“ in dct:type abgebildet. Der Begriff "Sammlung" wird im Folgenden synonym für Sammlungen, Gruppen und Reihen von Datensätzen benutzt. Eine Sammlung besteht aus den einzelnen Datensätzen der Sammlung und einem speziellen Datensatz, der (einzig) als Klammerstruktur der Sammlung dient.

Die Datensätze einer Sammlung

• verweisen mit dct:isVersionOf auf die Instanz der Klammerstruktur.

Der Datensatz, der als Klammerstruktur der Sammlung dient

• verweist in dct:type auf <http://dcat-ap.de/def/datasetTypes/collection> und zeigt damit an, eine Klammerstruktur zu sein;
• enthält in der Versionsbezeichnung (owl:VersionInfo) die für die gesamte Sammlung gültige Beschreibung;
• zeigt mittels dct:hasVersion auf die Datensätze, die Teil der Sammlung sind;
• hat keine Distribution.

<rdf:Description rdf:about="http://dataportal.example.eu/datasets/EUBudget">
  <rdf:type rdf:resource="http://www.w3.org/ns/dcat#Dataset"/> 
  <dct:type rdf:resource="http://dcat-ap.de/def/datasetTypes/collection"/> 
  <dct:title xml:lang="en">EU Budget Data</dct:title> 
  <dct:hasVersion rdf:resource="http://dataportal.example.eu/datasets/EUBudget2015"/> 
  <dct:hasVersion rdf:resource="http://dataportal.example.eu/datasets/EUBudget2016"/> 
</rdf:Description>
<rdf:Description rdf:about="http://dataportal.example.eu/datasets/EUBudget2015"> 
  <rdf:type rdf:resource="http://www.w3.org/ns/dcat#Dataset"/> 
  <dct:title xml:lang="en">EU Budget 2015</dct:title> 
  <dct:isVersionOf rdf:resource="http://dataportal.example.eu/datasets/EUBudget"/> 
</rdf:Description>
<rdf:Description rdf:about="http://dataportal.example.eu/datasets/EUBudget2016"> 
  <rdf:type rdf:resource="http://www.w3.org/ns/dcat#Dataset"/> 
  <dct:title xml:lang="en">EU Budget 2016</dct:title> 
  <dct:isVersionOf rdf:resource="http://dataportal.example.eu/datasets/EUBudget"/> 
</rdf:Description>

<rdf:Description rdf:about="http://dataportal.example.eu/datasets/EUBudget">
  <rdf:type rdf:resource="http://www.w3.org/ns/dcat#Dataset"/>
  <dct:title xml:lang="en">EU Budget Data</dct:title>
  <dcat:distribution rdf:resource="http://dataportal.example.eu/datasets/EUBudget2015"/>
  <dcat:distribution rdf:resource="http://dataportal.example.eu/datasets/EUBudget2016"/>
</rdf:Description>
<rdf:Description rdf:about="http://dataportal.example.eu/datasets/EUBudget2015">
  <rdf:type rdf:resource="http://www.w3.org/ns/dcat#Distribution"/>
  <dct:title xml:lang="en">EU Budget 2015</dct:title>
</rdf:Description>
<rdf:Description rdf:about="http://dataportal.example.eu/datasets/EUBudget2016">
  <rdf:type rdf:resource="http://www.w3.org/ns/dcat#Distribution"/>
  <dct:title xml:lang="en">EU Budget 2016</dct:title>
</rdf:Description>

1.8.1 Änderungen und Erhebungsmethoden​

Wesentliche Änderungen zu vorherigen Versionen eines Datensatzes sind eine wichtige Information für User und sollten anzgegeben werden. Dies bezieht sich sowohl auf inhaltliche Erkenntnisse (z.B. "im Vergleich zum Vorjahr hat es folgende Veränderung in den Grunddaten gegeben...") als auch auf (z.B.) Änderungen der Erhebungsmethoden und andere strukturelle Erfassungskriterien ("Erhebungsgebiet erweitert um Gebiet X", "Gebiete Y und Z zusammengelegt", "Veränderung der Kohortengrößen", etc).

Solche Informationen SOLLEN mittels adms:versionNotes als Versionserläuterung angegeben werden. Zusätzlich KÖNNEN sie in der Beschreibung (dct:description) genannt werden.

1.10.1 Verwendung des Musterdatenkatalogs für Kommunen

Bei einem "Musterdatensatz" aus dem "Musterdatenkatalog" handelt es sich nicht um einen Datensatz als solches, der "mustergültig" ist, sondern um ein zusätzliches Ordnungskriterium, das die Vergleichbarkeit zwischen den Kommunen verbessert. (Siehe FAQ: Was ist ein Musterdatensatz?).

Datensätze, die sich einem Ordnungskriterium des Musterdatenkatalog (also einem "Musterdatensatz") zuordnen lassen, können dies unter Verwendung der Eigenschaft dct:references tun. Ein Datensatz sollte immer nur auf einen Musterdatensatz referenzieren.

Zusätzlich wird empfohlen, die relevanten Themen aus dem Musterdatenkatalog als Schlagworte anzuhängen. Die Verwendung von Schlagworten erlaubt die Verbesserung der Auffindbarkeit, ohne dass Betreiber ihre Portale anpassen müssen. Zudem werden die Informationen an das EDP übertragen und bleiben somit auf europäischer Ebene nutzbar.

Die Liste der Themen des Musterdatenkatalogs befindet sich hier: https://musterdatenkatalog.de/def/musterdatensatz/ Die Angaben in der Spalte URI sollen als URI für die Eigenschaft dct:references verwendet werden. Die Literals für die Eigenschaft dcat:keyword können aus der Spalte NAME entnommen werden.

1.12.1 Umgang mit bestehenden IDs

Der Umgang mit den beiden Identifier-Entitäten wird in den DCAT-AP Implementation Guidelines genauer erklärt und hier als Konvention für die an GovData anliefernden Kooperationspartner festgelegt. In der Regel soll in dct:identifier der „Original-“URI des Datensatzes hinterlegt werden.

Das GovData-Portal identifiziert Dubletten von Datensätzen anhand des dct:identifier. Details und detaillierte Beispiele beschreibt Kapitel 1.14 Erkennung von Dubletten (dct:modified, dct:identifier)

1.12.2 Beispiel für weitere IDs

Ein typisches Beispiel für einen Identifier ist ein DOI-Name.

Ein weiterführendes Beispiel, wie adms:Identifier noch genauer beschrieben werden können, findet sich in der DCAT3-Spezifikation.

1.13.1 Kategorien/Themen des Musterdatenkatalogs

Mit Blick auf den Wirkungskreis und die Umsetzbarkeit bei Datenportalen und Datenbereitstellenden wird auf die Einführung eines weiteren Vokabulars für Kategorien verzichtet. Die Vorgaben von DCAT-AP erlauben derzeit zudem keine anderen Kategorien als die des EU Data Theme Vokabulars.

Die Kategorien und Themen des Musterdatenkatalogs sollen daher nicht mit dcat:theme verwendet werden, sondern unter Verwendung von dct:references und dcat:keyword, wie es im Kapitel 1.10.1 Verwendung des Musterdatenkatalogs für Kommunen beschrieben wird.

2.2.1 Vorgaben und Abgrenzung

DCAT-AP bietet verschiedener Felder für die Abbildung von Nutzungsrechten und weiteren Einschränkungen ab. Die Fachgruppe GovData hat beschlossen, für die Datenbereitstellung an GovData eine abschließende Lizenzliste innerhalb des DCAT-AP.de-Namensraums beizubehalten. Sie kann sich auch außerhalb des DCAT-AP.de Releasezyklus ändern.

Die abschließende Liste der verpflichtend zu verwendenden Lizenzen-URIs finden Sie im Kapitel zu kontrollierten Vokabularen.

Ergänzend zur verpflichtenden Angabe einer Lizenz (dct:license) können optional Aussagen über Grad der Zugänglichkeit (dct:accessRights), über Nutzungsbestimmungen (dct:rights) und zu einem Regelwerk (odrl:hasPolicy) gemacht werden. Für GovData ist jedoch die Angabe der Lizenz entscheidend.

<https://example.org/distr-1234> a dcat:Distribution ;
  dct:license <http://dcat-ap.de/def/licenses/dl-by-de/2.0> ;
  dct:rights <https://www.govdata.de/web/guest/lizenzen> .

Mit DCAT-AP 2.0 wurde dct:license auch auf Ebene der dcat:Resource und damit beim dcat:Dataset eingeführt. Für GovData bleibt aber die Angabe auf Ebene der Distribution ausschlaggebend.

Mit diesen Konventionen soll die Anforderung nach einer geschlossenen Lizenzliste umgesetzt und gleichzeitig DCAT-AP-Konformität von DCAT-AP.de eingehalten werden. Es bestehen weiterhin Konventionen zur Namensbildung der URIs, welche bei Neuanlage von URIs zu berücksichtigen sind und welche zu einer harmonisierenden Anpassung der ehemaligen OGD-Lizenzcodes führt.

2.2.2 Angabe von By-Texten

Das Feld dcatde:licenseAttributionByText speichert Angaben (insbes. für Share-Alike Lizenzen), bei denen der By-Text exakt wiedergegeben werden muss. Alternative Namensnennungen aus Autoren oder Herausgebernamen sind hier im Textfeld explizit so anzugeben, wie es der Lizenzgeber vorgesehen hat. Dieses Vorgehen ist temporär notwendig, bis DCAT-AP ein entsprechendes Feld zur Unterstützung der Lizenzangabe einführt.

2.3.1 Status der Distribution (adms:status)

Für den Status einer Distribution wird die Eigenschaft status des Asset Description Metadata Schemas adms verwendet. Für das kontrollierte Vokabular stehen PURL-URIs zur Verfügung. Für den Portalverbund GovData wird vereinbart, die Ausprägung „in Entwicklung“ für Distributionen nicht zu verwenden.

Zu einem Datensatz wird kein eigener Status geführt; vielmehr leitet sich sein Status logisch aus dem Status seiner Distributionen ab. Ein Datensatz wird als „Completed“ betrachtet, wenn mindestens eine seiner Distributionen diesen Status hat. Ein Datensatz wird als „Deprecated“ betrachtet, wenn mindestens eine seiner Distributionen diesen Status und keine den Status „Completed“ hat. Ein Datensatz wird nur als „Withdrawn“ betrachtet, wenn alle ihre Distributionen diesen Status haben.

Beim Entwurf der Metadaten haben Distributionen oft ungeklärte Lizenzverhältnisse, Ansprechpartner, oder sind in der Kategorisierung noch nicht trennscharf. Während die Erfassung von Datensätzen in diesem Status in einem Katalog durchaus Sinn machen kann, ist es in der Regel nicht erwünscht, die Metadaten bereits zu publizieren. Daher werden mit DCAT-AP.de die Status „Completed“, „Withdrawn“ und „Deprecated“ verwendet.

Bevor Elemente mit „Withdrawn“ längerfristig als „zurückgezogen“ markiert werden, SOLLEN sie zuvor für die Dauer von 30 Tagen mit dem adms:status „Deprecated“ als „Nicht mehr empfohlen“ ausgewiesen werden.

2.3.2 Abgrenzung zu dcatap:availability

Der Status der Distribution ist von der Verfügbarkeit (dcatap:availability) zu unterscheiden. Der Staus gibt an, ob eine Distribution z.B. vollständig ist oder aber nicht mehr zur Nutzung empfohlen wird. Die Verfügbarkeit gibt hingegen an, wie lange die Informationen voraussichtlich zur Verfügung stehen werden. Sie betrachtet insbesondere die Stabilität der dcat:accessURL als zentrales Merkmal einer Distribution.

So kann ein z.B. eine Distribution aufgrund eines neueren Dateiformats nicht mehr zur Nutzung empfohlen werden zugleich aber dennoch weiterhin zur Verfügung gestellt werden:

<https://example.org/distr-100> a dcat:Distribution ;
  dcatap:avaliability <http://data.europa.eu/r5r/availability/stable> ;
  adms:status <http://purl.org/adms/status/Deprecated> .

Ein anderer Fall liegt vor, wenn eine Distribution zur Nutzung empfohlen wird, aber z.B. aufgrund einer besonderen Lage oder im Rahmen eines Projektes nur temporär bereitgestellt wird:

<https://example.org/distr-200> a dcat:Distribution ;
  dcatap:avaliability <http://data.europa.eu/r5r/availability/experimental> ;
  adms:status <http://purl.org/adms/status/Completed> .

3.1.1 Art des Herausgebers

Bei Angaben zum Herausgeber KANN dieser mit der Eigenschaft dct:type einem konkreten Typ zugeordnet werden. Dabei MUSS das ADMS-Vokabular verwendet werden. Es kommt eine Untermenge der in DCAT-AP möglichen Werte zum Einsatz.

Die in ADMS vorgesehene Unterscheidung zwischen Forschung und Industrie, Standardisierungsgremien und Nicht-Regierungsorganisationen, Privatpersonen und Firmen, welche sich aus dem historischen Anwendungskontext von ADMS erklärt, wird nicht unterstützt, da diese für die deutsche Zielgruppe von DCAT-AP.de nicht trennscharf abzugrenzen sind.

Mit der für DCAT-AP.de erfolgten Auswahl wird versucht, mit „local“, „regional“ „national“ und „supranational“ die vertikale Verwaltungsstruktur in Deutschland abzubilden. Diese Angaben beziehen sich auf die Einordung des Herausgebers, nicht zwangsläufig auf die Abdeckung des Datensatzes.

5.1.1 Einführung von dcat:DataService​

https://github.com/GovDataOfficial/DCAT-AP.de/issues/53

Der dcat:DataService wird generell so eingeführt, wie er auch in DCAT-AP 2.0 eingeführt wurde. Damit stehen Datenbereitstellern neue und exaktere Möglichkeiten zur Verfügung, Webservices zu beschreiben. Es besteht aber kein Zwang, diese zu nutzen.​ Im Konventionenhandbuch werden Beispiele gegeben, wie ein dcat:DataService modelliert werden kann.

5.1.2 Aufnahme neuer Eigenschaften

https://github.com/GovDataOfficial/DCAT-AP.de/issues/59

Im Konventionenhandbuch erfolgt eine Erläuterung zur Abgrenzung zwischen dct:license, odrl:hasPolice und dct:rights. Diese Eigenschaften wurden zum Teil neu eingeführt.

5.1.3 Neue Verweise auf Dateiformate

https://github.com/GovDataOfficial/DCAT-AP.de/issues/56

Durch die Einführung der Eigenschaften dcat:packageFormat und dcat:compressFormat konnte Konvention 31, die relativ kompliziert und fehleranfällig war, vereinfacht werden.

5.1.4 Abgrenzung plannedAvailability und adms:status deutlich machen

https://github.com/GovDataOfficial/DCAT-AP.de/issues/50

Die Eigenschaft dcatap:availability betrachtet insbesondere die Stabilität der dcat:accessURL als zentrales Merkmal einer Distribution. Ihr Unterschied zu adms:status wird im Konventionenhandbuch beschrieben.

5.1.5 Relationen zw. Datensätzen dct:relation und dct:hasVersion klären​

https://github.com/GovDataOfficial/DCAT-AP.de/issues/49

Setzen des Collections-Features auf DEPRECATED und abwarten auf die dcat:DatasetSeries Lösung von DCAT3 und DCAT-AP. ​

Verbesserung bzw. Fehlerkorrektur der Beschreibung im Konventionenhandbuch.

5.1.6 Kennzeichnung für Markdown

https://github.com/GovDataOfficial/DCAT-AP.de/issues/46

Erläuterung, welche HTML-Tags von GovData interpretiert werden und wie andere Portale mit Markdown umgehen können.

5.1.7 Klare Aussagen zu Distribution

https://github.com/GovDataOfficial/DCAT-AP.de/issues/44

Alle Distributionen eines Datasets müssen weitestgehend die selben Daten beinhalten. Zeitreihen sollen nicht als mehrere Distributionen innerhalb eines Datasets dargestellt werden.

5.1.8 Bei RDF Daten: sneak peek in den Inhalt

https://github.com/GovDataOfficial/DCAT-AP.de/issues/39

Beispiel, wie man einen "sneak peak" mittels adms:sample umsetzen kann.

5.1.9 Angaben zu Spalten einer CSV-Datei​

https://github.com/GovDataOfficial/DCAT-AP.de/issues/32

Beispiel, wie man mittels dct:conformsTo und CSVW beschreiben kann, wie eine CSV-Datei aufgebaut ist.

5.1.10 Weitere Kategorien für Datasets

https://github.com/GovDataOfficial/DCAT-AP.de/issues/33

Verweis auf die Kategorien des Musterdatenkatalogs mittels dcat:keyword und dct:references.

5.1.11 dct:license auch für dcat:Dataset

https://github.com/GovDataOfficial/DCAT-AP.de/issues/25

Zwar kann dcat:Dataset mit einer Lizenz versehen werden, für die Anbindung an GovData müssen die Lizenzen aber weiterhin verpflichtend auf Ebene der Distributionen angegeben werden. ​ Konvention 32 bleibt weiter bestehen und wird erweitert, dass ein dcat:DataService ebenfalls über dct:license verfügen MUSS, wenn die Daten die er ausspielt, eine Lizenz haben.

5.1.12 Geodaten: Änderungen und Erhebungsmethoden

https://github.com/GovDataOfficial/DCAT-AP.de/issues/37

Wie adms:versionNote, auch Änderungen der Erhebungsmethoden, genutzt werden kann, wurde besser beschrieben.

5.1.13 Konv. 1 dcat:contactPoint - Pflichtangaben

https://github.com/GovDataOfficial/DCAT-AP.de/issues/47

Konvention 1 war zu streng und der umgebende Text widersprüchlich. Die Konvention wurde so abgeändert, dass entweder vcard:hasEmail oder vcard:hasURL (Link zum Kontaktformular) angegeben werden muss.​

5.1.14 Kennzeichnung High Value Datasets (HVD) in DCAT-AP.de​

https://github.com/GovDataOfficial/DCAT-AP.de/issues/29

Verwendung der Eigenschaft dct:references, um auf Referenzdatensätze wie ein HVD oder einen Musterdatensatz des Musterdatenkatalogs zu verweisen.​

5.1.15 Weitere Errata

• #59 Kardinalität von adms:versionNotes im UML-Diagramm​ angepasst.
• #51 Begriff "Koordinatenreferenzsystem" statt "Koordinatensystem" verwendet und Beispiele vereinfacht.
• #48 dcatde:contributorID - Formulierung klargestellt und Beispiel geändert.
• #23 Konvention 27/28 - Nicht alle Identifier können als URI übernommen werden, daher Streichung.