, zuletzt geändert am
Dieses Dokument ist ebenfalls in in diesem nicht-normativen Format verfügbar: PDF
Copyright © 2017-2022 Creative Commons Namensnennung 4.0 „]init[ AG für GovData“
In Deutschland findet zwischen GovData als zentralem Datenportal einerseits und Datenbereitstellern (z.B. Datenportalen der Bundesländer oder Kommunen) andererseits ein Datenaustausch statt.
Die Fachgruppe GovData hat am 21. November 2016 beschlossen, dass dem Datenaustausch zwischen dem Datenportal GovData und anderen Datenportalen eine deutsche Ableitung des europäischen Metadatenstandards DCAT-AP zugrunde gelegt werden soll. DCAT-AP.de ist die spezifische nationale Anpassung des Application Profiles „DCAT-AP v2.0“ und dient zukünftig als bundesweit einheitlicher Metadatenstandard zum Austausch von Metadaten zu öffentlichen Verwaltungsdaten in Deutschland.
Seit Anfang 2019 werden Metadaten nur noch im Standard DCAT-AP.de entgegengenommen.
Für alle Datenbereitstellenden, die direkt an das GovData-Portal anliefern, wurde von der Fachgruppe GovData für den Wechsel auf DCAT-AP.de 2.0 ein Übergangszeitraum von 9 Montaten nach der Veröffentlichung des Standards. Spätestens dann müssen die Metadaten in der DCAT-AP.de Version 2.0 bereitgestellt werden.
Dieses Konventionenhandbuch erläutert die Ergänzungen, die die DCAT-AP.de Spezifikation gegenüber DCAT-AP vornimmt.
Konventionenhandbuch als normatives RegelungsdokumentErgänzende Regeln adressieren weitere Harmonisierungsbedarfe, die nicht in die allgemeinen Normen der DCAT-AP.de Spezifikation eingegangen sind, weil sie entweder nur für den Austausch mit GovData gedacht sind (für den Austausch zwischen Landes- und Kommunalportalen aber z.B. anders geregelt sein können) oder absehbar einem kürzeren Releasezyklus unterliegen als die Spezifikation. Das Konventionenhandbuch richtet sich an Entwicklungsdienstleister des GovData Portals sowie Datenbereitsteller von Open Data Portalen in Deutschland bzw. Verantwortliche für die Softwareentwicklung dieser Portale.
Für die Nutzung von DCAT-AP.de in anderen Einsatzbereichen können eigene Konventionen vereinbart werden.
Die Begriffe MUSS, SOLL und KANN werden in diesem Dokument entsprechend ihren in RFC2119 definierten Bedeutungen verwendet, wenn und nur wenn sie wie hier gezeigt durchgehend groß geschrieben wurden.
Neben den explizit als nicht-normativ gekennzeichneten Abschnitten sind auch alle Diagramme, Beispiele und Hinweise in diesem Dokument nicht normativ. Alle anderen Angaben sind normativ.
vcard:hasEmail
) oder einen Link zum Kontaktformular oder Chatbot (vcard:hasURL
) enthalten.
dcatde:qualityProcessURI
transportiert werden.
dct:title
, dct:description
) KÖNNEN bei Vorhandensein von Metadaten in mehreren Sprachen wiederholt auftreten. Ist die Sprache nicht Deutsch, so MUSS sie mit den Sprachcodes gemäß BCP473 ausgezeichnet werden. Gibt es für eine Sprache keinen Alpha-2 Code nach ISO 639-1, so ist der Alpha-3 Code nach ISO 639-2 zu verwenden.
dct:spatial
) eines Katalogs, Datensatzes oder Datenservices unter Verwendung von Geometrien und Punkten bezeichnet, MÜSSEN die Koordinatenreferenzsysteme mit angegeben werden.
dct:spatial
) eines Katalogs, Datensatzes oder Datenservices unter Verwendung von Geometrien und Punkten angegeben, so MÜSSEN Koordinaten entsprechend der Achsenanordnung des bezeichneten Koordinatensystems angegeben werden.
dct:spatial
) MÜSSEN WKT, GML, oder RDF+WKT/GML gemäß der GeoSPARQL Spezifikation, KML oder RDF von schema.org verwendet werden.
dct:spatial
) MÜSSEN die für Geometrien zugelassen Werte oder geo URIs, GeoHash URIs oder das W3C Basic Geo (WGS84 lat/long) vocabulary verwendet werden.
dcatde:politicalGeocodingURI
) MUSS zusätzlich zur dct:spatial
bezeichnet werden, wenn die geografische Abdeckung ausgedrückt werden soll und ein Datensatz oder Datenservice das gesamte Bundesgebiet oder das Gebiet einer bestimmten Gemeinde, eines Gemeindeverbandes, eines Kreises, eines Bezirks oder eines Bundeslandes abdeckt.
dcatde:politicalGeocodingLevelURI
) SOLL durch einen URI bezeichnet werden, wenn eine Abdeckung durch den Datensatz oder Datenservice auf abstrakter Verwaltungsebene (Bund, Land, Kreis, Kommunen) gegeben ist.
dcatde:geocodingDescription
) MUSS als Freitextfeld verwendet werden, wenn eine andere geopolitische Codierung der Abdeckung des Datensatzes oder Datenservices nicht möglich oder zu komplex ist.
dcatde:politicalGeocodingURI
ausgedrückten geografischen Bezüge SOLLEN zum Erhalt der europäischen Interoperabilität zugleich bei dct:spatial
(Bundesländer, Kreise und Kommunen) als geografischer Bezug per URI gespiegelt werden.
dcatde:contributorID
) ausweisen.
dcatde:contributorID
angehängt werden. In den Metadaten, die an GovData übermittelt werden darf der Datensatz keine weitere Datenbereitsteller ID-Kennung mit der Aufbauvorschrift http://dcat-ap.de/def/contributors/...
enthalten. Weitere Datenbereitsteller-IDs mit abweichender Aufbauvorschrift dürfen hingegegen bereitgestellt werden.
collections
) KÖNNEN über Datensätze und Distributionen abgebildet werden.
collections
) SOLLEN bevorzugt über Datensätze ausgedrückt werden.
dct:hasVersion
) ausgedrückt werden.
dct:type
<http://dcat-ap.de/def/datasetTypes/collection>
gekennzeichnet werden
dct:spatial
, dcatde:politicalGeocodingURI
, dcatde:politicalGeocodingLevelURI
und dct:temporal
erfasst werden. Nur wenn es dem übergreifenden Verständnis z.B. von Datenreihen dient KÖNNEN zusätzliche Angaben in dct:title
gemacht werden.
dct:source
SOLL nicht verwendet werden.
adms:status
„Completed“, „Deprecated“ oder „Withdrawn“ transportiert werden.
adms:status
„Completed“, „Deprecated“ in DCAT-AP.de konformen Portalen angezeigt werden.
adms:status
„Withdrawn“ zunächst mit „Deprecated“ ausgewiesen werden.
dct:identifier
, so MUSS dieser unverändert weitergegeben werden.
adms:identifier
auflisten. Bestehende Einträge von adms:identifier
MÜSSEN unverändert bleiben.
dct:conformsTo
ausgedrückt werden. angezeigt werden.
dct:format
verwiesen werden. Andernfalls MUSS über das Webformular mittels "CONTRIBUTE" bzw. "BEITRAGEN" eine Aufnahme des Formats beantragt werden.
dcat:DataServices
mit einer Lizenz versehen werden, wenn die Daten die er ausspielt, eine Lizenz haben.
dcatde:licenseAttributionByText
hinterlegt werden.
dct:publisher
MUSS die Organisation eingetragen werden, die den Datensatz (im rechtlichen, nicht technischen Sinne) veröffentlicht, d.h. die entschieden hat, dass Dritten Nutzungsrechte (hilfsweise Zugang) eingeräumt werden.
adms:publishertype
Vokabulars verwendet werden.
dcat:startDate
) oder Ende (dcat:endDate
) angegeben sein.
dcat:downloadURL
als auch als dcat:accessURL
angegeben.
dateStamp
(XPath MD_Metadata/dateStamp
) als Wert der Eigenschaft dct:modified
des Datasets verwendet werden.
dcat:accessService
auf einen dcat:DataService
verweisen, DÜRFEN über keine dcat:downloadURL
verfügen und MÜSSEN in ihrer dcat:accessURL
die dcat:endpointURL
des dcat:DataService
angeben.
dcat:Dataset
dcat:contactPoint
)Daten zu Kontaktmöglichkeiten eines Datensatzes bzw. eines Katalogs können mit dem vCard-Vokabular angegeben werden. Die folgende Untermenge der in vcard möglichen Typen wird besonders empfohlen:
vcard - Vokabular | |
---|---|
vcard:fn |
Name |
vcard:hasEmail |
E-Mailadresse |
vcard:hasTelephone |
Telefonnummer |
vcard:hasURL |
Link zum Kontaktformular (empfohlen) oder zur Webseite |
dcatde:qualityProcessURI
)DCAT-AP.de hat DCAT-AP um das Feld dcatde:qualityProcessURI
erweitert, um auf generelle Informationen über einen Qualitätssicherungsprozess verweisen zu können. Deutsche Datenkataloge des GovData Portalverbundes beschreiben teilweise bereits die Mindestqualitätskriterien, die ein Datensatz erfüllen muss, um in das Datenportal aufgenommen zu werden.
dct:spatial
)Die Angabe zum geografischen oder geometrischen Bezug eines Datensatzes kann in DCAT-AP.de zusätzlich zu dct:spatial
durch die Verwendung der folgenden Eigenschaften erfolgen:
dcatde:politicalGeocodingURI
– administrativer Geobezug als URI,dcatde:politicalGeocodingLevelURI
– Ebene des administrativen Geobezugs als URI,dcatde:geocodingDescription
– verwaltungspolitischer oder fachlicher Geobezug als beschreibender Text.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:
Name | locn:geometry |
URI | http://www.w3.org/ns/locn#geometry |
Range | http://www.w3.org/ns/locn#Geometry |
Definition | Verbindet einen Datensatz mit seiner entsprechenden geometrischen Abdeckung. |
Verwendungshinweise
Zur Wahrung von Interoperabilität SOLLTEN folgende Typen verwendet werden:
Schema.org Eigenschaften sind schema:GeoCoordinates
, schema:latitude
, schema:longitude
.
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:
Aber auch andere langfristig verfügbare Vokabulare (z.B. die Ortsverzeichnisse der Vermessungsämter) können genutzt werden.
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.
Das Mapping der englischen generischen Adressbestandteile der locn:Address wird in der folgenden Tabelle dargestellt:
locn:Address |
deutsches Verständnis | XÖV-Kernkomponente „Anschrift“ | Beispiel |
---|---|---|---|
locn:fullAddress |
Anschrift (Straße, Nr, Postleitzahl, Ort) | Staatsbetrieb Sächsische Informatik Dienste, Riesaer Str. 7, 01129 Dresden | |
locn:poBox |
Postfach | postfach | 1185 |
locn:thoroughfare |
|||
locn:locatorDesignator |
Adresszusatz (Typ) | zusatz | Haus |
locn:locatorName |
Adresszusatz (Name) | zusatz | D |
locn:addressArea |
Ort | ort | Dresden |
locn:postName |
Ortsteil | ortsteil | Pieschen-Süd |
locn:adminUnitL2 |
Land | Sachsen | |
locn:adminUnitL1 |
Staat | DE | |
locn:postCode |
Postleitzahl | postleitzahl | 01129 |
locn:addressId |
ID | id |
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.
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:
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.
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“.
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.
Verwaltungsebene | dcatde:politicalGeocodingURI |
Alternativen für dct:spatial |
---|---|---|
Bund | http://dcat-ap.de/def/politicalGeocoding/level/federal |
MDR Authorities Country Code für Deutschland: http://publications.europa.eu/mdr/resource/authority/country/DEU |
Bundesland | z.B. Berlin: http://dcat-ap.de/def/politicalGeocoding/stateKey/11 |
Geonames Ressourcen, z.B. http://www.geonames.org/2950157 - Land Berlin |
Kommunen | z.B. Halle (Saale): http://dcat-ap.de/def/politicalGeocoding/regionalKey/15002000000 |
Landes Gazetteer z.B. Stadt-Großröhrsdorf https://geodienste.sachsen.de/iwfs_geosn_verwaltungseinheiten/guest?SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&STOREDQUERY_ID=urn:ogc:def:query:OGC-WFS::GetFeatureById&id=auAdmUnitS.14625200 |
Kreis | z.B. Main-Tauber-Kreis: http://dcat-ap.de/def/politicalGeocoding/districtKey/08128 |
Publications Office Code für Main-Tauber-Kreis http://publications.europa.eu/resource/authority/atu/DEU_LKR_MAITAU |
Für die Bundesländer können die folgenden alternativen GeoNames
-URIs genutzt werden:
dcatde:contributorID
)Zur Unterstützung der Kommunikation im Portalverbund und um maschinenverarbeitbare Herkunftsangaben zu ermöglichen, pflegt die Geschäfts- und Koordinierungsstelle eine Liste der Datenbereitsteller des Portals GovData.de. Sie enthält direkte Datenbereitsteller des GovData.de Portals. Diese Liste ändert sich außerhalb des Releasezyklus von DCAT-AP.de.
Neue Datenbereitsteller können jederzeit nach der Aufbauvorschrift dcat-ap.de/def/contributors/
<contributorID>
hinzugefügt werden. Kontaktieren Sie zur Aufnahme neuer Datenbereitsteller bitte die Geschäfts- und Koordinierungsstelle GovData: info@govdata.de.
Die Liste der Datenbereitsteller wird nicht mehr im Konventionenhandbuch selbst gepflegt, sondern lediglich verlinkt. (Siehe 4. Kontrollierte Vokabulare)
_:ds1 dcatde:contributorID <http://dcat-ap.de/def/contributors/transparenzportalHamburg> .
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
dct:isVersionOf
auf die Instanz der Klammerstruktur.Der Datensatz, der als Klammerstruktur der Sammlung dient
dct:type
auf <http://dcat-ap.de/def/datasetTypes/collection>
und zeigt damit an, eine Klammerstruktur zu sein;owl:VersionInfo
) die für die gesamte Sammlung gültige Beschreibung;dct:hasVersion
auf die Datensätze, die Teil der Sammlung sind;<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>
dct:title
)Der Titel eines Datensatzes oder einer Distribution wird in dct:title
hinterlegt. Der Titel sollte dabei
owl:versionInfo
, adms:versionNote
)In DCAT-AP.de findet Versionierung nur auf Datensatzebene mittels der Versionsbezeichnung (owl:versionInfo
), der Versionserläuterung (adms:versionNotes
) und der Beziehungen „Ist Version von“ (dct:isVersionOf
) bzw. „Weitere Version“ (dct:hasVersion
) statt.
Eine Versionierung von Distributionen ist nicht vorgesehen, so dass mit jeder Änderung einer Distribution auch eine Änderung des Datensatzes einhergeht.
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.
dct:relation
)Andere Beziehungen zwischen Datensätzen können mit dct:relation
angedeutet werden. Hier können weitere Beziehungen zu anderen Ressourcen (Datensätze, Datenservices oder Kataloge) und Distributionen abgebildet werden. Ein eigenes DCAT-AP.de Vokabular existiert dabei nicht.
dct:references
)Beziehung zwischen dcat:Resource
und Referenzobjekten, z.B. einer URI eines Referenzdatensatzes des Musterdatenkatalogs für Kommunen oder eine URI eines High-Value-Datasets (noch nicht veröffentlicht) können mit dct:references
abgebildet werden. Dies ist insbesondere für Datensätze relevant.
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.
dct:source
)Die Eigenschaft dct:source
ist in DCAT-AP für den Katalogeintrag ("Original-Metadaten der Ressource") und für Datensätze ("Quelle des Datensatzes") definiert. Sie verweist auf den Datensatz bzw. Katalogeintrag, von dem der beschriebene Datensatz oder Katalogeintrag abgeleitet wurde. Für den GovData-Verbund wird vereinbart, diese Eigenschaft nicht zu benutzen, da ihr einheitlicher Gebrauch kaum umzusetzen wäre.
dct:identifier
, adms:identifier
)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
)
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.
dcat:theme
)Datensätze werden einheitlich mittels des EU Data Theme Vokabulars kategorisiert, welches im Rahmen des Projekts Metadatenregister (MDR) vom Amt für Veröffentlichungen der EU (OPOCE) gepflegt wird.
Deutsche Bezeichnung (EuroVoc) | zu verwendendes MDR Theme |
---|---|
Landwirtschaft, Fischerei, Forstwirtschaft und Nahrungsmittel | http://publications.europa.eu/resource/authority/data-theme/AGRI |
Wirtschaft und Finanzen | http://publications.europa.eu/resource/authority/data-theme/ECON |
Bildung, Kultur und Sport | http://publications.europa.eu/resource/authority/data-theme/EDUC |
Energie | http://publications.europa.eu/resource/authority/data-theme/ENER |
Umwelt | http://publications.europa.eu/resource/authority/data-theme/ENVI |
Gesundheit | http://publications.europa.eu/resource/authority/data-theme/HEAL |
Internationale Themen | http://publications.europa.eu/resource/authority/data-theme/INTR |
Justiz, Rechtssystem und öffentliche Sicherheit | http://publications.europa.eu/resource/authority/data-theme/JUST |
Bevölkerung und Gesellschaft | http://publications.europa.eu/resource/authority/data-theme/SOCI |
Regierung und öffentlicher Sektor | http://publications.europa.eu/resource/authority/data-theme/GOVE |
Regionen und Städte | http://publications.europa.eu/resource/authority/data-theme/REGI |
Wissenschaft und Technologie | http://publications.europa.eu/resource/authority/data-theme/TECH |
Verkehr | http://publications.europa.eu/resource/authority/data-theme/TRAN |
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.
dct:modified
, dct:identifier
)Aktuell werden für das GovData-Portal von unterschiedlichen Portalen identische Datensätze bereitgestellt, die per Mapping aus ISO-Metadaten die DCAT-AP.de Metadaten erzeugt haben. Damit diese Datensätze zuverlässig als Dublette erkannt werden, muss (neben dem Identifier) das Mapping auf dct:modified
bei allen datenbereitstellenden Portalen standardisiert sein.
Hierfür ist das „technische“ Aktualitätsdatum der Metadaten (Daten oder Dienst) im Element dateStamp
(XPath MD_Metadata/dateStamp
) zu verwenden, da es das ausschlaggebende Merkmal für Veränderungen in den Metadaten ist.
Werden mehrere Datensätze mit dem selben dct:identifier
für GovData bereitgestellt, wird der Datensatz mit dem jüngsten Aktualisierungsdatum dct:modified
importiert. Bei einem identischen Datum, wird der zuerst importierte Datensatz behalten. Damit die Dublettenprüfung funktioniert, ist es wichtig, dass der dct:identifier
nicht verändert wird (siehe Kapitel 1.12.1 Umgang mit bestehenden IDs) und zudem das Aktualisierungsdatum dct:modified
gepflegt wird.
Nachfolgend ist das in den Implementation Guidelines im Kapitel „How to manage duplicates“ gegebene Beispiel aufgeführt. Es ist auf die GovData Situation und DCAT-AP.de angepasst:
Das Beispiel zeigt Daten auf 3 Portalen:
Der Original Datensatz wurde in Hamburg eingestellt und zunächst dort veröffentlicht. Da der Datensatz dort veröffentlicht wird, wird ein stabiler Identifier dct:identifier
idealerweise bereits nach den GovData URI-Regeln des "URI-Konzeptes" vergeben:
Beim Harvesten in ein fiktionales regionales “Norddeutschland-Portal” wird ein lokaler Identifier ergänzt, welcher Bedeutung im regionalen Portal erhält. Diese ID ist im Sinne einer „anderen ID“ als adms:identifier
zu speichern. Der bereits vorbelegte globale „identifier“ (dct:identifier
) bleibt dabei unverändert.
Das GovData Portal könnte nun beide Datensätze als Dubletten von Hamburg und vom Norddeutschland-Portal erhalten. Aufgrund des identischen dct:identifier
wird es als Dublette erkannt. Da auch das Aktualisierungsdatum des dct:modified
identisch ist, bleibt der Datensatz im GovData-Portal, der zuerst importiert wurde (vermutlich der Datensatz aus Hamburg), der andere wird abgewiesen.
Ein fiktives "Wirtschaftsdaten-Portal" erweitert den Datensatz aus dem Norddeutschland-Portal um eine weitere Distribution, es wird ein adms:identifier
hinzugefügt und das Aktualisierungsdatum des Datensatzes wird (aufgrund der Erweiterung um eine zusätzliche Distribution) aktualisiert.
Wenn dieser Datensatz aus dem Wirtschaftsdaten-Portal ebenfalls für GovData bereitgestellt wird, wird er aufgrund des identischen dct:identifier
und des jüngeren dct:modified
Datums importiert. Der bereits im GovData-Portal befindliche Datensatz mit dem identischen dct:identifier
und älterem dct:modified
Datum wird gelöscht.
adms:sample
)Sind die Daten eines Datensatzes sehr umfangreich, kann es für den potentiellen Nutzer des Datensatzes wertvoll sein, ein Beispiel der zu erwartenden Daten zu erhalten. Zu diesem Zweck hat DCAT-AP die Eigenschaft adms:sample
eingeführt, die auf eine Distribution zeigt, die als Beispiel fungieren kann.
Die Verwendung dieser Eigenschaft ist insbesondere dann hilfreich, wenn die Daten von einem Datenservice ausgeliefert werden. Wie adms:sample
in diesem Kontext verwendet werden kann, zeigt Beispiel 27.
dcat:Distribution
Laut Definition müssen alle Distributionen eines Datasets weitestgehend die selben Daten beinhalten. Diese können in unterschiedlichen Formaten vorliegen. Weiter gilt:
Werden, wie im letzten Punkt beschrieben, Dokumente mit Erläuterungen als Distribution mit veröffentlicht, sollten diese Dokumentation auch zusätzlich vom Datasatz aus über foaf:page
eingebunden werden.
dct:format
)DCAT-AP sieht zur Kennzeichnung des Dateiformats vor, dass für dct:format
das EU Vokabular "File Type" des Publications Office zu verwenden ist.
Befinden sich die Dateien, die die eigentlichen Informationen enthalten, innerhalb eines Containers, sollte zusätzlich noch das Kompressionsformat (dcat:compressFormat
) bzw. das Paketformat (dcat:packageFormat
) angegeben werden. Ist das dcat:compressFormat
zugleich das dcat:packageFormat
, kann auf die Angabe von dcat:packageFormat
verzichtet werden.
Die bisherige Regelung, Containerformaten über eine URI die z.B. +zip
beinhaltet anzugeben, entfällt mit der Einführung der neuen Eigenschafen.
Die Eigenschaft dct:format
ist gegenüber dcat:mediaType
vorrangig zu benutzten. Alle drei Eigenschaften aus dem dcat-Namensraum (dcat:mediaType
, dcat:compressFormat
und dcat:packageFormat
) verwenden das IANA Vokabular "Media Types".
<https://example.org/distr-just-csv> a dcat:Distribution ;
dcat:downloadURL <https://example.org/download/distr.csv> ;
dct:format <http://publications.europa.eu/resource/authority/file-type/CSV> ;
<https://example.org/distr-csv-gz> a dcat:Distribution ;
dcat:downloadURL <https://example.org/download/distr.csv.gz> ;
dct:format <http://publications.europa.eu/resource/authority/file-type/CSV> ;
dcat:compressFormat <http://www.iana.org/assignments/media-types/application/gzip> .
<https://example.org/distr-csv-zip> a dcat:Distribution ;
dcat:downloadURL <https://example.org/download/distr.zip> ;
dct:format <http://publications.europa.eu/resource/authority/file-type/CSV> ;
dcat:compressFormat <http://www.iana.org/assignments/media-types/application/zip> .
dct:license
)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.
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.
adms:status
, dcatap:availability
)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.
Deutsche Übersetzung | Wert | unterstützt durch DCAT-AP | unterstützt durch GovData |
---|---|---|---|
in Entwicklung | http://purl.org/adms/status/UnderDevelopment | + | - |
Vollständig | http://purl.org/adms/status/Completed | + | + |
Nicht mehr empfohlen | http://purl.org/adms/status/Deprecated | + | + |
Zurückgezogen | http://purl.org/adms/status/Withdrawn | + | + |
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.
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> .
dcat:downloadURL
)Die Eigenschaft dcat:downloadURL
verweist auf den URL der herunterladbaren Datei, die die Daten im angegebenen Format enthält. Dahingehend kann der URL, der mit der Eigenschaft dcat:accessURL
übertragen wird, auch lediglich auf eine Seite verweisen, die darüber informiert, wie auf die Daten zugegriffen werden kann.
dcat:startDate
, dcat:endDate
)Der abgedeckte Zeitraum (dct:temporal
) wird mittels dessen „Startzeitpunkt“ und „Endzeitpunkt“ angegeben. Eine von beiden MUSS (obwohl beide optional sind) für jede Instanz der Klasse dct:PeriodOfTime
vorhanden sein.
dct:conformsTo
)Konformität zu bestehende Standards (für Datensätze oder Distributionen) oder Application Profiles (für Katalogeinträge) kann unter Verwendung der Eigenschaft dct:conformsTo
angezeigt werden.
Wird in einer Distributionen ein maschinenlesbares Format zum Download angeboten, ist ein Verweis darauf, wie die Inhaltsdaten zu verstehen sind, besonders wertvoll für die weitere Verarbeitung der Daten.
Datentyp | Konformitätsangabe (Beispiel) |
---|---|
RDF-Daten | Ontologie im OWL-Format. |
XML-Daten | XML-Schema-Definition im XSD-Format. |
JSON-Daten | JSON-Schema-Definition im JSON-Schema-Format. |
CSV-Daten | Beschreibung des Aufbaus mit Hilfe von CSVW. |
Beispiel für RDF-Daten
Beispiel für XML-Daten
Beispiel für JSON-Daten
Beispiel für CSV-Daten
Die Beschreibung des Schemas und Dialekts hilft Nutzern, insbesondere Programmen, die unten angegebene Beispiel-CSV-Datei korrekt zu interpretieren.
Dabei helfen insbesondere die Informationen, die über csvw:dialect
eingebunden werden.
Aber auch die Angaben zur jeweiligen Spalte in csvw:column
, insbesondere der csvw:datatype
, unterstützt beim Verständnis der Tabelle.
Stadtname | Bundesland (Code) | Einwohner |
---|---|---|
Berlin | BE | 3664088 |
Freie und Hansestadt Hamburg | HH | 1851430 |
München | BY | 1488202 |
Dieses englischsprachige Tutorial geht auf die Verwendung von CSVW mit JSON-LD und weitere Aspekte ein.
dct:publisher
)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.
ADMS PURL-URI | deutsche Entsprechung (Beispiel) | unterstützt in DCAT-AP.de |
---|---|---|
http://purl.org/adms/publishertype/Academia-ScientificOrganisation | - | |
http://purl.org/adms/publishertype/Company | Firma, Unternehmen (z.B. Siemens) | - |
http://purl.org/adms/publishertype/IndustryConsortium | Industriekonsortium | - |
http://purl.org/adms/publishertype/LocalAuthority | kommunale Ebene (z.B. Stadt Köln, Landkreise, Kommunalverbände, etc.) | x |
http://purl.org/adms/publishertype/NationalAuthority | Bundesebene (z.B. Bundesanstalt für Landwirtschaft und Ernährung) | x |
http://purl.org/adms/publishertype/NonGovernmentalOrganisation | - | |
http://purl.org/adms/publishertype/NonProfitOrganisation | - | |
http://purl.org/adms/publishertype/PrivateIndividual(s) | Privatperson(en) | - |
http://purl.org/adms/publishertype/RegionalAuthority | Landesebene (z.B. NRW) | x |
http://purl.org/adms/publishertype/StandardisationBody | - | |
http://purl.org/adms/publishertype/SupraNationalAuthority | EU-Agenturen, UN-Agenturen, (z.B. EPO oder Worldbank) | x |
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.
Die Eigenschaft dct:publisher
ist für Datensätze auf maximal einen Eintrag beschränkt. Zur Realisierung eines erweiterten Rollenkonzeptes wurde dem Vorschlag der DCAT-AP Spezifikation gefolgt und es wurden weitere Rollen:
Dazu werden
dct:publisher
weitere dcterms
-Eigenschaften ergänzt: dct:contributor
und dct:creator
,dcatde:originator
und dcatde:maintainer
.Einen Datensatz KÖNNEN neben dem Herausgeber (erfasst in foaf:Agent
) weitere Stellen als Beteiligte und diese zu einem konkreten Typ zugeordnet werden. Dabei MUSS das ADMS-Vokabular verwendet werden.
Rollen-Name | Definition | URI der Eigenschaft | Verwendete Klasse |
---|---|---|---|
Kontakt | Stellen oder Personen, die kontaktiert werden können, um sich über die Daten zu informieren oder sie zu erwerben. | dcat:contactPoint |
vCard:Kind |
Autor | Stellen oder Personen, die die Daten erstellt haben. | dct:creator |
foaf:Agent |
Bearbeiter | Stellen oder Personen, die die Daten bearbeitet haben. | dct:contributor |
foaf:Agent |
Herausgeber | Stellen oder Personen, die über die Einräumung von Zugang und Nutzungsrechten für Dritte entschieden haben. | dct:publisher |
foaf:Agent |
Urheber | Personen, die Urheberrechte an den Daten besitzen | dcatde:originator |
foaf:Agent , genauer: foaf:Person |
Verwalter | Stellen oder Personen, die Verantwortung und Rechenschaftspflicht für die Daten und ihre angemessene Pflege übernehmen. | dcatde:maintainer |
foaf:Agent |
Das folgende fiktive Beispiel veranschaulicht den Gebrauch von verschiedenen Rollen in DCAT-AP.de:
dcat:DataService
)Zur Unterscheidung von zwischen einer dcat:Distribution
und eines dcat:DataService
besagt die DCAT-AP-Guideline, dass
dcat:accessURL
oder dcat:downloadURL
.Auch diese Abgrenzung lässt einen gewissen Spielraum.
Dieses Bild visualisiert, wie die einzelnen Klassen von DCAT (grau) untereinander in Beziehung stehen. Zusätzlich werden ihre Verbindungen zum eigentlichen Online-Service (grün) und den Fachdaten (blau). Es bietet viele unterschiedliche Modellierungsmöglichkeiten, die noch näher konkretisiert werden sollten. Beispiele, wie ein Dataservice modelliert werden kann, finden sich sowohl bei GeoDCAT als auch bei W3C-DCAT. DCAT-AP hat noch keine Best Practice identifiziert. GovData ist mit dem W3C und den DCAT-AP-Verantwortlichen im weiteren Austausch, um hier weitere Konkretisierungen zu erreichen.
Datenportale wie GovData sind derzeit stark auf Datensätze zentriert. Daher soll zunächst ein Beispiel gegeben werden für einen Datensatz, der zusätzlich über einen Datenservice verfügt:
Ein weiteres, extremes, Beispiel sind Datenservices, die über keine Distributionen und Datensätze verfügen, da sie z.B. lediglich Werte umrechnen oder Abstände zwischen zwei Orten berechnen.
dct:description
)GovData erwartetet in allen Text-Elementen, also insbesondere in der Eigenschaft dct:description
, weitestgehend unformatierten Text. Zusätzlich werden vom Portal folgende HTML-Tags intreptiert: <a></a>
, <li></li>
, <ol></ol>
, <ul></ul>
, <p></p>
, <br>
, <b></b>
, <i></i>
und <u></u>
.
Weitere HTML-Tags oder Markdown-Kennzeichnungen, werden ignoriert. Zeichen die verwendet wurden, um den Text mit Markdown zu formatieren, werden normal angezeigt. Dies reduziert die Lesbarkeit der Texte.
Ohne die Spezifikation umfangreich anzupassen, sind keine Wege bekannt, in RDF-Daten anzugeben, dass ein String mit Markdown formatiert wurde. Wollen andere Portale, die DCAT-AP.de nutzen, Auszeichnungssprachen wie Markdown in Beschreibungen nutzen, müssen sie dies von den Datenbereitstellern fordern oder die Verwendung technisch erkennen können.
DCAT-AP.de administriert verschiedene kontrollierte Vokabulare, die auch unabhängig von der Spezifikation und dem Konventionenhandbuch aktualisiert werden können. Folgende Auflistung stellt diese kontrollierte Vokabulare und ihre Namensräumen dar. Die Details werden in der Spezifikation von DCAT-AP.de beschrieben.
https://github.com/GovDataOfficial/DCAT-AP.de/issues/60
In Version 2.0 ist die größte und offensichtlichste Änderung, die Verwendung von ReSpec, um Spezifikation und Konventionenhandbuch als moderne Web-Version zu veröffentlichen. Dieses Vorgehen ist transparenter, einfacher zu handhaben und einfacher konsistent zu halten. Zusätzlich wird aber auch ein PDF-Export angeboten.
Mit der Umstellung ging eine redaktionelle Überarbeitung der meisten Texten einher. Beispiele, die zuvor als Bild eingefügt waren, wurden in Text überführt. Tabellen wurden zum Teil in eine andere, web-kompatiblere, Darstellungsform überführt. Die Aufteilung des Dokuments wurde ebenfalls leicht angepasst.
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.
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.
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.
plannedAvailability
und adms:status
deutlich machenhttps://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.
dct:relation
und dct:hasVersion
klärenhttps://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.
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.
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.
https://github.com/GovDataOfficial/DCAT-AP.de/issues/39
Beispiel, wie man einen "sneak peak" mittels adms:sample
umsetzen kann.
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.
https://github.com/GovDataOfficial/DCAT-AP.de/issues/33
Verweis auf die Kategorien des Musterdatenkatalogs mittels dcat:keyword
und dct:references
.
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.
https://github.com/GovDataOfficial/DCAT-AP.de/issues/37
Wie adms:versionNote
, auch Änderungen der Erhebungsmethoden, genutzt werden kann, wurde besser beschrieben.
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.
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.
Begriff | Definition/Erklärung |
---|---|
ADMS | Asset Description Metadata Schema |
Application Profile | Spezifikation, die Begrifflichkeiten/Konzepte eines oder mehrerer grundlegender Standards wiederverwendet |
CRS | Coordinate Reference System |
Datenportal | Web-basiertes System, welches einen Datenkatalog beinhaltet |
Datensatz (Dataset) | sinnvolle Sammlung von zusammenhängenden Daten, die von einer einzelnen Quelle veröffentlicht oder kuratiert wird und in einem oder mehreren Formaten erreichbar ist oder als Download zur Verfügung steht |
DEPRECATED | Elemente, die DEPRECATED sind, werden zunächst weiter akzeptiert. Es wird nicht empfohlen, sie neu einzuführen. Im einfachsten Fall ist keine Handlung notwendig, da die Open-World Assumption dazu führt, dass zusätzliche Angaben immer möglich sind. Meistens wird jedoch eine Handlung notwendig, da eine Eigenschaft durch eine neue oder einen neuen Weg ersetzt wird. Beispiele: Wechsel von dcatde:plannedAvailability hin zu dcatap:availability , dcat:granularity . |
DCAT | W3C Data Catalog, ein RDF-Vokabular |
DCAT-AP | ISA² Data Catalogue Application Profile des W3C Data Catalog DCAT |
DCAT-AP.de | Deutsche Adaption des „ISA² Data Catalogue Application Profile“ |
DCT | DCMI Metadata Terms |
DCMI | Dublin Core Metadata Initiative |
Distribution | Logisches Konzept von Metadaten zu einer Ressource die physisch/real erreichbar ist bzw. als Download zur Verfügung steht |
Dublin Core | Metadatenvokabular zur Beschreibung von Dokumenten und anderen Objekten im Internet |
Empfänger | Nutzer von Daten |
EU | European Union |
EU DG Informatics (DIGIT) | Die Generaldirektion Informatik ist innerhalb der Kommission für die Bereitstellung digitaler Dienste zuständig, die andere Kommissionsdienststellen und EU-Institutionen in ihrem Tagesgeschäft unterstützen und die Zusammenarbeit der Behörden in den EU-Ländern fördern. |
EuroVoc | Multilingual Thesaurus of the European Union |
FOAF | Friends of a Friend Vocabulary |
GEMET | General Multilingual Environmental Thesaurus |
GovData | Datenportal für deutsche offene Verwaltungsdaten |
IANA | Internet Assigned Numbers Authority |
INSPIRE | Infrastructure for Spatial Information in the European Community |
ISO | International Standardisation Organization |
Interoperabilität | Fähigkeit zur Zusammenarbeit von verschiedenen Systemen, Techniken oder Organisationen. |
IT-Planungsrat | politisches Steuerungsgremium von Bund und Ländern in Deutschland, welches die Zusammenarbeit im Bereich der Informationstechnik koordiniert |
JSON | JavaScript Object Notation |
JSON-LD | JSON for Linked Data |
KoSIT | Koordinierungsstelle für IT-Standards |
Literal | Eine Zeichenfolge, die zur direkten Darstellung der Werte von Basistypen (z. B. Ganzzahlen, Gleitkommazahlen, Datumsangaben, Zeichenketten) definiert bzw. zulässig ist. |
MDR | Metadata Registry, ein Projekt des Publications Offices of the EU |
Metadaten | Daten, die Informationen über Merkmale anderer Daten enthalten, aber nicht diese Daten selbst. |
Namensraum | Begriff aus der Programmierung: Dabei werden die Namen für Objekte in einer Art Baumstruktur angeordnet und über entsprechende Pfadnamen eindeutig angesprochen. |
OGC | Open Geospatial Consortium |
Open Data | Daten, die von jedermann ohne jegliche Einschränkungen genutzt, weiterverbreitet und weiterverwendet werden dürfen. Quelle: Jörn von Lucke, Christian Geiger: Open Government Data (Frei verfügbare Daten des öffentlichen Sektors). |
OWL | Web Ontology Language |
RDF | Resource Description Framework |
RDF/XML | Notation von RDF in XML |
RDFS | RDF Schema |
RFC | Request for Comments |
Sender | Bereitsteller von Daten |
SKOS | Simple Knowledge Organization System |
SPDX | Software Package Data Exchange |
Turtle | eine Art der Notation von RDF |
UML | Unified Modeling Language (vereinheitlichte Modellierungssprache) |
URI | Uniform Ressource Identifier, besteht aus einer Zeichenfolge, die zur Identifizierung einer abstrakten oder physischen Ressource dient. |
URL | Uniform Ressource Locator |
URN | Uniform Ressource Name |
vCard | vCard Ontologie um Personen und Organisationen zu beschreiben |
WITHDRAWN | Eigenschaften, Klassen und Vokabulare, die WITHDRAWN werden, werden umgehend mit dem Release der neuen Version aus der Spezifikation entfernt. Dabei wird darauf geachtet, dass ihre Nutzung derzeit kaum bzw. nicht-existent ist. Beispiel: adms:status im dcat:CatalogRecord . |
W3C | World Wide Web Consortium |
XÖV | XML in der Öffentlichen Verwaltung |
XSD | XML Schma Part 2: Datatypes Second Edition |