Skip to content
Branch: master
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

DCAT-AP 2.0.0 release notes

  • Alignment with W3C DCAT 2.0 which introduces the ability to share data services.
  • In order to steer towards quality metadata descriptions, the implementation of a number of properties are recommended or made mandatory;
  • Removal of non-existing controlled vocabularies adms:change_type;
  • Addition of a new property dcatap:availability that indicates the planned availability of the distribution;
  • Coherency improvements on the specification and its distributions;
  • The alignment with W3C DCAT 2.0 resulted in the replacement of the URIs with respect to the last DCAT-AP release 1.2.1. Namely, for describing a Period of Time the DCAT native properties dcat:startDate and dcat:endDate will be used instead of schema:startDate or schema:endDate. A dedicated set of SHACL validation rules are provided in order to support catalogue’s owners in the identification of the issue.
  • The supporting distributions, namely the common JSON-LD context and the SHACL templates are improved. To increase their reuse, the distributions are now released under the CC-BY 4.0 licence.

The complete list of addressed topics can be found in the issue list, having the label release:2.0.0-november2019.

updates to supporting distributions


The context file is aligned with the specification in terms of the used labels. The used labels in the specification are in British English. Therefore the context file maps the British English terms to the corresponding URIs. E.g.

"Catalogue": "",

The context file distinguishes between objectproperties (e.g. language in the example below) and dataproperties (e.g. title). The context does not support language tagged literals (e.g. description) as JSON-LD context mappings require to make an explicit choice.

{ "@context": { ... }, 
 "@id" : "",
 "@type" : "Catalogue",
 "language" : "",
 "title" : "European Data Portal",
 "description" : {
   "en" : "The strategic objective of the European Data Portal is to improve accessibility and increase the value of Open Data"
 "dataset" : [ {"@id": "", 
                "@type": "Dataset"
              {"@id": "", 
               "@type": "Dataset"}

Catalogue owners can use the context extension mechanism to add and overwrite the mappings according to their needs.

The above example corresponds to the following RDF triples

<> <> _:b0 .
<> <> <> .
<> <> "European Data Portal" .
<> <> <> .
<> <> <> .
<> <> <> .
<> <> <> .
<> <> <> .

Identifying URI changes

DCAT-AP 2.0.0 implements a URI change for the properties startDate and endDate. To identify the existence of the old URIs in the catalogue, the SHACL rules in dcat-ap_2.0.0_shacl_deprecateduris.ttl can be executed.

validating DCAT-AP

To check whether a catalogue satisfies the DCAT-AP 2.0.0 specification the SHACL files can be used:

The first file provides for each class mentioned in DCAT-AP and having additional properties defined a template with the corresponding constraints. In order to validate a catalogue additional data might be required to import into the validator, such as the controlled vocabularies. These have to be retrieved from the appropriate places.

You can’t perform that action at this time.