Abstract

DCAT-AP is a DCAT profile for sharing information about Catalogues containing Datasets and Data Services descriptions in Europe, under maintenance by the SEMIC action, Interoperable Europe.

This Application Profile provides a minimal common basis within Europe to share Datasets and Data Services cross-border and cross-domain.

Introduction

Context

Around 2010, on behalf of the European Commission the access to public sector information was studied. These studies showed that businesses and citizens faced many difficulties in finding and reusing public sector information. The studies indicated that the availability of the information in a machine-readable format as well as a thin layer of commonly agreed metadata could facilitate data cross-reference and interoperability and therefore considerably enhance its value for reuse. Therefore, to overcome these hurdles, the European Commission invested in policies [[PSI]], data interoperability [[SEMIC]] and infrastructure [[DEU]].

Interoperable Europe, within its mission to stimulate the data interoperability in Europe, manages this specification on the metadata agreements for sharing dataset descriptions between data portals. The governance is taken care by the SEMIC action within Interoperable Europe. Initially, the scope of the specification was the exchange between Open Data Portals in Europa. Although this is still at the core of the specification, DCAT-AP is not limited to public accessible Open Data, but can be applied to any kind of datasets. In the past decade, DCAT-AP has grown from a single specification to a whole ecosystem of related and interconnected specifications.

Scope of the Application Profile

The Application Profile specified in this document is based on the specification of the Data Catalog Vocabulary (DCAT) [[vocab-dcat-3]] developed under the responsibility of the [[[DXWG]]] (DXWG) at W3C.

The objective of this work is to produce a profile of DCAT based on numerous requests for change coming from real-world implementations of the specification listed on GitHub since the previous release. For that the DCAT specification is extended with improved definitions, usage notes and usages constraints such as cardinalities for properties and the usage of controlled vocabularies. Additional classes and properties from other well-known vocabularies are re-used where necessary.

The work does not cover implementation issues like mechanisms for exchange of data and expected behaviour of systems implementing the Application Profile other than what is defined in the Conformance Statement in section [[[#conformance]]]. The section [[[#validation-of-dcat-ap]]] provides SHACL templates and references to the Interoperability Testbed tool for validating a catalogue for compliance with DCAT-AP.

The Application Profile is intended to facilitate data exchange and therefore the classes and properties defined in this document are only relevant for the data to be exchanged; there are no requirements for communicating systems to implement specific technical environments. The only requirement is that the systems can export and import data in RDF in conformance with this Application Profile.

As mentioned in the context, the prime objective of the Application Profile is to enhance data findability and promote reusability. To achieve this goal, datasets should be coherently documented. To enable this, the Application Profile considers several essential aspects, including among others:

These are addressed with the aim to facilitate effective data reuse, allowing users to locate, understand and utilise the available data resources more efficiently.

Revision history

The first DCAT-AP specification was released in September 2013. The subsequent releases 1.1, 1.2 and 1.2.1 improved the specification. These specifications are in line with the first release of the W3C DCAT 1 recommendation [[vocab-dcat-1]]. They express DCAT-AP in terms of Catalogue, Datasets and Distributions. With the adoption of the W3C DCAT 2 recommendation [[vocab-dcat-2]], an alignment process for DCAT-AP was initiated. This resulted in a new release DCAT-AP 2.0.0. The years after this specification was further elaborated in new release 2.0.1, 2.1.0 and 2.1.1. W3C DCAT 2 restructured DCAT by introducing the notions of a generic Catalogued Resource of which Datasets and Data Services are special cases. In 2023, the adoption of W3C DCAT 3 [[vocab-dcat-3]] triggered a new alignment for DCAT-AP. W3C DCAT 3 extends the profile with the Dataset Series notion. This document is the combination of addressing issues raised by the community and this alignment.

Notes on alignment with DCAT 3

The introduction of Dataset Series in DCAT is an additive operation from semantical, data modeling perspective. Therefore the impact on existing DCAT-AP 2.x exchanges is limited. Nevertheless, publishers may face substantial impact on the existing catalogues as the new terminology for Dataset Series may require to revisit the publisher's metadata guidelines. For instance, if the publisher had chosen to document a Dataset Series as a Dataset with multiple Distributions, then the alignment with Dataset Series as expressed in this specification will require a substantial effort. This impact goes beyond the specification and dependent on the usage of the shared information. In the context of DCAT-AP and in line with the conformance expectations, the term Dataset Series will be solely used for resources that are explicitly identified by the class Dataset Series. The situation, as mentioned, where a Dataset has multiple Distributions, will be considered as a Dataset with multiple Distributions and not as a Dataset Series. This way, receivers of DCAT-AP metadata can rely on the classes to process the metadata.

The sole data model impact DCAT 3 creates, is by deprecating the use of some URIs and introducing new URIs in the DCAT namespace for the use case of Dataset versioning. As these properties are optional and since there is an equivalence between the deprecated and the new ones, catalogue owners can easily realign.

To support the review, the changes are also highlighted on the diagram below.

Meeting minutes

The following webinars have been held for the creation of this release

Status

This application profile has the status Candidate Recommendation published at 2024-04-05.

Information about the process and the decisions involved in the creation of this specification are consultable at the Changelog.

License

Copyright © 2023 European Union. All material in this repository is published under the license CC-BY 4.0, unless explicitly otherwise mentioned.

Conformance Statement

Provider requirements

In order to conform to this Application Profile, an application that provides metadata MUST: For the properties listed in the table in section [[[#controlled-vocs]]], the associated controlled vocabularies MUST be used. Additional controlled vocabularies MAY be used. In addition to the mandatory properties, any of the recommended and optional properties defined in section [[[#quick-reference]]] MAY be provided.

Receiver requirements

In order to conform to this Application Profile, an application that receives metadata MUST be able to:
  • Process information for all classes and properties specified in section [[[#quick-reference]]].
  • Process information for all controlled vocabularies specified in section [[[#controlled-vocs]]].
  • "Processing" means that receivers must accept incoming data and transparently provide these data to applications and services. It does neither imply nor prescribe what applications and services finally do with the data (parse, convert, store, make searchable, display to users, etc.).

    Terminology

    An Application Profile is a specification that reuses terms from one or more base standards, adding more specificity by identifying mandatory, recommended and optional elements to be used for a particular application, as well as recommendations for controlled vocabularies to be used.

    A Dataset is a collection of data, published or curated by a single source, and available for access or download in one or more formats. A Data Portal is a Web-based system that contains a data catalogue with descriptions of datasets and provides services enabling discovery and reuse of the datasets.

    Used Prefixes

    PrefixNamespace IRI
    admshttp://www.w3.org/ns/adms#
    dcathttp://www.w3.org/ns/dcat#
    dcataphttp://data.europa.eu/r5r/
    dcthttp://purl.org/dc/terms/
    dctypehttp://purl.org/dc/dcmitype/
    foafhttp://xmlns.com/foaf/0.1/
    locnhttp://www.w3.org/ns/locn#
    odrlhttp://www.w3.org/ns/odrl/2/
    owlhttp://www.w3.org/2002/07/owl#
    provhttp://www.w3.org/ns/prov#
    rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
    rdfshttp://www.w3.org/2000/01/rdf-schema#
    skoshttp://www.w3.org/2004/02/skos/core#
    spdxhttp://spdx.org/rdf/terms#
    timehttp://www.w3.org/2006/time#
    vcardhttp://www.w3.org/2006/vcard/ns#
    xsdhttp://www.w3.org/2001/XMLSchema#

    Overview

    DCAT-AP is a DCAT profile for sharing information about Catalogues containing Datasets and Data Services descriptions in Europe. The core classes of the Application Profile are thus the classes Catalogue, Dataset, Distribution and Data Service. DCAT-AP allows Catalogues of only Datasets, but also Catalogues of only Data Services, but usually it will be a mixture of both. Dataset Series are introduced to further organise the Datasets within a Catalogue. Datasets that are a member of a Dataset Series have additional constraints beyond those applicable for Dataset. These constraints are expressed in the class Dataset member of Dataset Series.

    The properties of the core classes may enforce the existence of other classes. One such important class is the class Agent. However in contrast to the core classes, DCAT-AP leaves a lot of freedom to the implementors to shape them to their needs. Only minimal expectations are expressed by DCAT-AP.

    Elaborated statements about the expectations are found in section [[[#conformance]]] describing DCAT-AP conformance.

    To improve the coherency between shared Dataset, Distribution and Data Service, section [[[#usage-guide-on-datasets-distributions-and-data-services]]] provides additional guidelines.

    The list of included properties contain a selection of the properties from the W3C DCAT 3 specification [[vocab-dcat-3]] on which DCAT-AP expresses additional constraints or on which DCAT-AP wants to emphasise their usage. Any property that is mentioned in DCAT applicable to a class but not explicitly is listed DCAT-AP is considered an optional field for DCAT-AP for that class. It means that for these properties DCAT-AP has no use cases that require additional usage considerations beyond ‘use the property as DCAT specifies’. Properties that are not explicitly listed in this specification have no conformance expectation. From that perspective these are ignored. DCAT-AP acts in this way as a filter for all the possibilities DCAT offers. Nevertheless, to keep the DCAT-AP concise and to the point optional DCAT-AP properties that have no additional usage notes to DCAT may become subject for removal if the usage in the practice is sporadic.

    Application profile diagram

    An overview of DCAT-AP is shown by the UML diagram below. The UML diagram illustrates the specification described in this document. For readability purposes, the representation has been condensed as follows: The cardinalities and qualifications are included in the figure.

    This document describes the usage of the following main entities for a correct usage of the Application Profile:
    | Agent | Catalogue | Catalogue Record | Catalogued Resource | Checksum | Data Service | Dataset | Dataset Series | Distribution | Kind | Licence Document | Location | Relationship |

    The main entities are supported by:
    | Activity | Attribution | Checksum Algorithm | Concept | Concept Scheme | Document | Frequency | Geometry | Identifier | Legal Resource | Linguistic system | Literal | Media type | Period of time | Policy | Provenance Statement | Resource | Rights statement | Role | Standard |

    And supported by these datatypes:
    | Media Type | Media Type or Extent | Temporal Literal | Time instant | xsd:dateTime | xsd:decimal | xsd:duration | xsd:hexBinary | xsd:nonNegativeInteger |

    Main Entities

    The main entities are those that form the core of the Application Profile. The properties and their associated constraints that apply in the context of this profile are listed in a tabular form. Each row corresponds to one property. In addition to the constraints also cross-references are provided to DCAT. To save space, the following abbreviations are used to indicate in short the difference with DCAT:

    This reuse qualification assessement is w.r.t. a specific version of DCAT. Therefore it may vary over time when new versions of DCAT-AP are created.

    Agent

    Definition
    Any entity carrying out actions with respect to the entities Catalogue and the Catalogued Resources.
    Reference in DCAT
    Link
    Usage Note
    If the Agent is an organisation, the use of the Organization Ontology is recommended.
    Properties
    For this entity the following properties are defined: name , type .
    Property Range Card Definition Usage DCAT Reuse
    name Literal 1..* A name of the agent. This property can be repeated for different versions of the name (e.g. the name in different languages). P
    type Concept 0..1 The nature of the agent. P

    Catalogue

    Definition
    A catalogue or repository that hosts the Datasets or Data Services being described.
    Reference in DCAT
    Link
    Properties
    For this entity the following properties are defined: applicable legislation , catalogue , creator , dataset , description , geographical coverage , has part , homepage , language , licence , modification date , publisher , record , release date , rights , service , temporal coverage , themes , title .
    Property Range Card Definition Usage DCAT Reuse
    applicable legislation Legal Resource 0..* The legislation that mandates the creation or management of the Catalog. P
    catalogue Catalogue 0..* A catalogue whose contents are of interest in the context of this catalogue. Link A
    creator Agent 0..1 An entity responsible for the creation of the catalogue. Link A
    dataset Dataset 0..* A Dataset that is part of the Catalogue. As empty Catalogues are usually indications of problems, this property should be combined with the property service to implement an empty Catalogue check. Link A
    description Literal 1..* A free-text account of the Catalogue. This property can be repeated for parallel language versions of the description. Link E
    geographical coverage Location 0..* A geographical area covered by the Catalogue. Link E
    has part Catalogue 0..* A related Catalogue that is part of the described Catalogue. Link E
    homepage Document 0..1 A web page that acts as the main page for the Catalogue. Link E
    language Linguistic system 0..* A language used in the textual metadata describing titles, descriptions, etc. of the Datasets in the Catalogue. This property can be repeated if the metadata is provided in multiple languages. Link E
    licence Licence Document 0..1 A licence under which the Catalogue can be used or reused. Link E
    modification date Temporal Literal 0..1 The most recent date on which the Catalogue was modified. Link E
    publisher Agent 1 An entity (organisation) responsible for making the Catalogue available. Link E
    record Catalogue Record 0..* A Catalogue Record that is part of the Catalogue. Link A
    release date Temporal Literal 0..1 The date of formal issuance (e.g., publication) of the Catalogue. Link E
    rights Rights statement 0..1 A statement that specifies rights associated with the Catalogue. Link E
    service Data Service 0..* A site or end-point (Data Service) that is listed in the Catalogue. As empty Catalogues are usually indications of problems, this property should be combined with the property dataset to implement an empty Catalogue check. Link A
    temporal coverage Period of time 0..* A temporal period that the Catalogue covers. Link A
    themes Concept Scheme 0..* A knowledge organization system used to classify the Resources that are in the Catalogue. This property refers to a knowledge organization system used to classify the Catalogue's Datasets. It must have at least the value NAL:data-theme as this is the manatory controlled vocabulary for dcat:theme. Link E
    title Literal 1..* A name given to the Catalogue. This property can be repeated for parallel language versions of the name. Link E

    Catalogue Record

    Definition
    A description of a Catalogued Resource's entry in the Catalogue.
    Reference in DCAT
    Link
    Properties
    For this entity the following properties are defined: application profile , change type , description , language , listing date , modification date , primary topic , source metadata , title .
    Property Range Card Definition Usage DCAT Reuse
    application profile Standard 0..* An Application Profile that the Catalogued Resource's metadata conforms to. Link E
    change type Concept 0..1 The status of the catalogue record in the context of editorial flow of the dataset and data service descriptions. P
    description Literal 0..* A free-text account of the record. This property can be repeated for parallel language versions of the description. Link E
    language Linguistic system 0..* A language used in the textual metadata describing titles, descriptions, etc. of the Catalogued Resource. This property can be repeated if the metadata is provided in multiple languages. P
    listing date Temporal Literal 0..1 The date on which the description of the Resource was included in the Catalogue. Link E
    modification date Temporal Literal 1 The most recent date on which the Catalogue entry was changed or modified. Link E
    primary topic Catalogued Resource 1 A link to the Dataset, Data service or Catalog described in the record. A catalogue record will refer to one entity in a catalogue. This can be either a Dataset or a Data Service. To ensure an unambigous reading of the cardinality the range is set to Catalogued Resource. However it is not the intend with this range to require the explicit use of the class Catalogued Record. As abstract class, an subclass should be used. Link E
    source metadata Catalogue Record 0..1 The original metadata that was used in creating metadata for the Dataset, Data Service or Dataset Series. P
    title Literal 0..* A name given to the Catalogue Record. This property can be repeated for parallel language versions of the name. Link E

    Catalogued Resource

    Definition
    Resource published or curated by a single agent.
    Reference in DCAT
    Link
    Usage Note
    This class Catalogued Record is an abstract class for DCAT-AP. Therefore only subclasses should be used in a data exchange.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Checksum

    Definition
    A value that allows the contents of a file to be authenticated.
    Reference in DCAT
    Link
    Usage Note
    This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented.
    Properties
    For this entity the following properties are defined: algorithm , checksum value .
    Property Range Card Definition Usage DCAT Reuse
    algorithm Checksum Algorithm 1 The algorithm used to produce the subject Checksum. Link E
    checksum value xsd:hexBinary 1 A lower case hexadecimal encoded digest value produced using a specific algorithm. Link E

    Data Service

    Definition
    A collection of operations that provides access to one or more datasets or data processing functions.
    Reference in DCAT
    Link
    Subclass of
    Catalogued Resource
    Properties
    For this entity the following properties are defined: access rights , applicable legislation , application profile , contact point , description , documentation , endpoint description , endpoint URL , format , keyword , landing page , licence , publisher , serves dataset , theme , title .
    Property Range Card Definition Usage DCAT Reuse
    access rights Rights statement 0..1 Information regarding access or restrictions based on privacy, security, or other policies. Link E
    applicable legislation Legal Resource 0..* The legislation that mandates the creation or management of the Data Service. P
    application profile Standard 0..* An established (technical) standard to which the Data Service conforms. The standards referred here SHOULD describe the Data Service and not the data it serves. The latter is provided by the dataset with which this Data Service is connected. For instance the data service adheres to the OGC WFS API standard, while the associated dataset adheres to the INSPIRE Address data model. Link E
    contact point Kind 0..* Contact information that can be used for sending comments about the Data Service. Link A
    description Literal 0..* A free-text account of the Data Service. This property can be repeated for parallel language versions of the description. Link E
    documentation Document 0..* A page or document about this Data Service P
    endpoint description Resource 0..* A description of the services available via the end-points, including their operations, parameters etc. The property gives specific details of the actual endpoint instances, while the property application profile (dct:conformsTo) is used to indicate the general standard or specification that the endpoints implement. Link A
    endpoint URL Resource 1..* The root location or primary endpoint of the service (an IRI). Link E
    format Media Type or Extent 0..* The structure that can be returned by querying the endpointURL. P
    keyword Literal 0..* A keyword or tag describing the Data Service. Link A
    landing page Document 0..* A web page that provides access to the Data Service and/or additional information. It is intended to point to a landing page at the original data service provider, not to a page on a site of a third party, such as an aggregator. Link E
    licence Licence Document 0..1 A licence under which the Data service is made available. Link E
    publisher Agent 0..1 An entity (organisation) responsible for making the Data Service available. Link E
    serves dataset Dataset 0..* This property refers to a collection of data that this data service can distribute. Link A
    theme Concept 0..* A category of the Data Service. A Data Service may be associated with multiple themes. Link E
    title Literal 1..* A name given to the Data Service. This property can be repeated for parallel language versions of the name. Link E

    Dataset

    Definition
    A conceptual entity that represents the information published.
    Reference in DCAT
    Link
    Usage Note
    If a Dataset is used as part of a Dataset Series, the usage of the properties listed below must be coherent with the associated Dataset Series. For this usage, consult the guidelines in section [[[#UsageGuidelines]]].
    Subclass of
    Catalogued Resource
    Properties
    For this entity the following properties are defined: access rights , applicable legislation , conforms to , contact point , creator , dataset distribution , description , documentation , frequency , geographical coverage , has version , identifier , in series , is referenced by , keyword , landing page , language , modification date , other identifier , provenance , publisher , qualified attribution , qualified relation , related resource , release date , sample , source , spatial resolution , temporal coverage , temporal resolution , theme , title , type , version , version notes , was generated by .
    Property Range Card Definition Usage DCAT Reuse
    access rights Rights statement 0..1 Information that indicates whether the Dataset is publicly accessible, has access restrictions or is not public. Link E
    applicable legislation Legal Resource 0..* The legislation that mandates the creation or management of the Dataset. P
    conforms to Standard 0..* An implementing rule or other specification. Link A
    contact point Kind 0..* Contact information that can be used for sending comments about the Dataset. Link A
    creator Agent 0..* An entity responsible for producing the dataset. Link A
    dataset distribution Distribution 0..* An available Distribution for the Dataset. Link A
    description Literal 1..* A free-text account of the Dataset. This property can be repeated for parallel language versions of the description. Link E
    documentation Document 0..* A page or document about this Dataset. P
    frequency Frequency 0..1 The frequency at which the Dataset is updated. Link E
    geographical coverage Location 0..* A geographic region that is covered by the Dataset. Link E
    has version Dataset 0..* A related Dataset that is a version, edition, or adaptation of the described Dataset. P
    identifier Literal 0..* The main identifier for the Dataset, e.g. the URI or other unique identifier in the context of the Catalogue. Link E
    in series Dataset Series 0..* A dataset series of which the dataset is part. Link E
    is referenced by Resource 0..* A related resource, such as a publication, that references, cites, or otherwise points to the dataset. Link A
    keyword Literal 0..* A keyword or tag describing the Dataset. Link A
    landing page Document 0..* A web page that provides access to the Dataset, its Distributions and/or additional information. It is intended to point to a landing page at the original data provider, not to a page on a site of a third party, such as an aggregator. Link A
    language Linguistic system 0..* A language of the Dataset. This property can be repeated if there are multiple languages in the Dataset. Link E
    modification date Temporal Literal 0..1 The most recent date on which the Dataset was changed or modified. Link E
    other identifier Identifier 0..* A secondary identifier of the Dataset Examples are MAST/ADS [[MASTADS]], DOI [[DOI]], EZID [[EZID]] or W3ID [[W3ID]]. Link E
    provenance Provenance Statement 0..* A statement about the lineage of a Dataset. P
    publisher Agent 0..1 An entity (organisation) responsible for making the Dataset available. Link E
    qualified attribution Attribution 0..* An Agent having some form of responsibility for the resource. Link A
    qualified relation Relationship 0..* A description of a relationship with another resource. Link A
    related resource Resource 0..* A related resource. Link A
    release date Temporal Literal 0..1 The date of formal issuance (e.g., publication) of the Dataset. Link E
    sample Distribution 0..* A sample distribution of the dataset. P
    source Dataset 0..* A related Dataset from which the described Dataset is derived. P
    spatial resolution xsd:decimal 0..* The minimum spatial separation resolvable in a dataset, measured in meters. Link A
    temporal coverage Period of time 0..* A temporal period that the Dataset covers. Link A
    temporal resolution xsd:duration 0..* The minimum time period resolvable in the dataset. Link A
    theme Concept 0..* A category of the Dataset. A Dataset may be associated with multiple themes. Link E
    title Literal 1..* A name given to the Dataset. This property can be repeated for parallel language versions of the name. Link E
    type Concept 0..* A type of the Dataset. A recommended controlled vocabulary data-type is foreseen. Link E
    version Literal 0..1 The version indicator (name or identifier) of a resource. Link A
    version notes Literal 0..* A description of the differences between this version and a previous version of the Dataset. This property can be repeated for parallel language versions of the version notes. P
    was generated by Activity 0..* An activity that generated, or provides the business context for, the creation of the dataset. Link A

    Dataset Series

    Definition
    A collection of datasets that are published separately, but share some characteristics that group them.
    Reference in DCAT
    Link
    Usage Note
    It is recommended to avoid Dataset Series without a dataset in the collection. Therefore at least one Dataset should refer to a Dataset Series using the property in series (dcat:inSeries).
    Subclass of
    Catalogued Resource
    Properties
    For this entity the following properties are defined: applicable legislation , contact point , description , frequency , geographical coverage , modification date , publisher , release date , temporal coverage , title .
    Property Range Card Definition Usage DCAT Reuse
    applicable legislation Legal Resource 0..* The legislation that mandates the creation or management of the Dataset Series. P
    contact point Kind 0..* Contact information that can be used for sending comments about the Dataset Series. Link A
    description Literal 1..* A free-text account of the Dataset Series. This property can be repeated for parallel language versions. It is recommended to provide an indication about the dimensions the Dataset Series evolves. Link E
    frequency Frequency 0..1 The frequency at which the Dataset Series is updated. The frequency of a dataset series is not equal to the frequency of the dataset in the collection. Link E
    geographical coverage Location 0..* A geographic region that is covered by the Dataset Series. When spatial coverage is a dimension in the dataset series then the spatial coverage of each dataset in the collection should be part of the spatial coverage. In that case, an open ended value is recommended, e.g. EU or a broad bounding box covering the expected values. Link A
    modification date Temporal Literal 0..1 The most recent date on which the Dataset Series was changed or modified. This is not equal to the most recent modified dataset in the collection of the dataset series. Link E
    publisher Agent 0..1 An entity (organisation) responsible for ensuring the coherency of the Dataset Series  The publisher of the dataset series may not be the publisher of all datasets.  E.g. a digital archive could take over the publishing of older datasets in the series.  Link E
    release date Temporal Literal 0..1 The date of formal issuance (e.g., publication) of the Dataset Series. The moment when the dataset series was established as a managed resource. This is not equal to the release date of the oldest dataset in the collection of the dataset series. Link E
    temporal coverage Period of time 0..* A temporal period that the Dataset Series covers. When temporal coverage is a dimension in the dataset series then the temporal coverage of each dataset in the collection should be part of the temporal coverage. In that case, an open ended value is recommended, e.g. after 2012. Link A
    title Literal 1..* A name given to the Dataset Series. This property can be repeated for parallel language versions of the name. Link E

    Distribution

    Definition
    A physical embodiment of the Dataset in a particular format.
    Reference in DCAT
    Link
    Properties
    For this entity the following properties are defined: access service , access URL , applicable legislation , availability , byte size , checksum , compression format , description , documentation , download URL , format , has policy , language , licence , linked schemas , media type , modification date , packaging format , release date , rights , spatial resolution , status , temporal resolution , title .
    Property Range Card Definition Usage DCAT Reuse
    access service Data Service 0..* A data service that gives access to the distribution of the dataset. Link A
    access URL Resource 1..* A URL that gives access to a Distribution of the Dataset. The resource at the access URL may contain information about how to get the Dataset. Link E
    applicable legislation Legal Resource 0..* The legislation that mandates the creation or management of the Distribution. P
    availability Concept 0..1 An indication how long it is planned to keep the Distribution of the Dataset available. P
    byte size xsd:nonNegativeInteger 0..1 The size of a Distribution in bytes. Link E
    checksum Checksum 0..1 A mechanism that can be used to verify that the contents of a distribution have not changed. The checksum is related to the downloadURL. Link E
    compression format Media type 0..1 The format of the file in which the data is contained in a compressed form, e.g. to reduce the size of the downloadable file. It SHOULD be expressed using a media type as defined in the official register of media types managed by IANA. Link E
    description Literal 0..* A free-text account of the Distribution. This property can be repeated for parallel language versions of the description. Link E
    documentation Document 0..* A page or document about this Distribution. P
    download URL Resource 0..* A URL that is a direct link to a downloadable file in a given format. Link E
    format Media Type or Extent 0..1 The file format of the Distribution. Link E
    has policy Policy 0..1 The policy expressing the rights associated with the distribution if using the [[ODRL]] vocabulary. Link E
    language Linguistic system 0..* A language used in the Distribution. This property can be repeated if the metadata is provided in multiple languages. P
    licence Licence Document 0..1 A licence under which the Distribution is made available. Link E
    linked schemas Standard 0..* An established schema to which the described Distribution conforms. Link E
    media type Media Type 0..1 The media type of the Distribution as defined in the official register of media types managed by IANA. Link E
    modification date Temporal Literal 0..1 The most recent date on which the Distribution was changed or modified. Link E
    packaging format Media Type 0..1 The format of the file in which one or more data files are grouped together, e.g. to enable a set of related files to be downloaded together. It SHOULD be expressed using a media type as defined in the official register of media types managed by IANA. Link E
    release date Temporal Literal 0..1 The date of formal issuance (e.g., publication) of the Distribution. Link E
    rights Rights statement 0..1 A statement that specifies rights associated with the Distribution. Link E
    spatial resolution xsd:decimal 0..* The minimum spatial separation resolvable in a dataset distribution, measured in meters. Link A
    status Concept 0..1 The status of the distribution in the context of maturity lifecycle. It MUST take one of the values Completed, Deprecated, Under Development, Withdrawn. P
    temporal resolution xsd:duration 0..* The minimum time period resolvable in the dataset distribution. Link A
    title Literal 0..* A name given to the Distribution. This property can be repeated for parallel language versions of the description. Link E

    Kind

    Definition
    A description following the vCard specification, e.g. to provide telephone number and e-mail address for a contact point.
    Usage Note
    Note that the class Kind is the parent class for the four explicit types of vCard (Individual, Organization, Location, Group).
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Licence Document

    Definition
    A legal document giving official permission to do something with a resource.
    Properties
    For this entity the following properties are defined: type .
    Property Range Card Definition Usage DCAT Reuse
    type Concept 0..* A type of licence, e.g. indicating 'public domain' or 'royalties required'. P

    Location

    Definition
    A spatial region or named place.
    Reference in DCAT
    Link
    Usage Note
    It can be represented using a controlled vocabulary or with geographic coordinates. In the latter case, the use of the Core Location Vocabulary is recommended, following the approach described in the GeoDCAT-AP specification.
    Properties
    For this entity the following properties are defined: bbox , centroid , geometry .
    Property Range Card Definition Usage DCAT Reuse
    bbox Literal 0..1 The geographic bounding box of a resource. Link E
    centroid Literal 0..1 The geographic center (centroid) of a resource. Link E
    geometry Geometry 0..1 The corresponding geometry for a resource. Link E

    Relationship

    Definition
    An association class for attaching additional information to a relationship between DCAT Resources.
    Reference in DCAT
    Link
    Properties
    For this entity the following properties are defined: had role , relation .
    Property Range Card Definition Usage DCAT Reuse
    had role Role 1..n A function of an entity or agent with respect to another entity or resource. Link E
    relation Resource 1..n A resource related to the source resource. Link E

    Supportive Entities

    The supportive entities are supporting the main entities in the Application Profile. They are included in the Application Profile because they form the range of properties.

    Activity

    Definition
    An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Attribution

    Definition
    Attribution is the ascribing of an entity to an agent.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Checksum Algorithm

    Definition
    Algorithm for Checksums.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Concept

    Definition
    Properties
    For this entity the following properties are defined: preferred label .
    Property Range Card Definition Usage DCAT Reuse
    preferred label Literal 1..n A preferred label of the concept. This property can be repeated for parallel language versions of the label. P

    Concept Scheme

    Definition
    Properties
    For this entity the following properties are defined: title .
    Property Range Card Definition Usage DCAT Reuse
    title Literal 1..n A name of the concept scheme. May be repeated for different versions of the name P

    Document

    Definition
    A textual resource intended for human consumption that contains information, e.g. a web page about a Dataset.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Frequency

    Definition
    A rate at which something recurs, e.g. the publication of a Dataset.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Geometry

    Definition
    The locn:Geometry class provides the means to identify a location as a point, line, polygon, etc. expressed using coordinates in some coordinate reference system.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Identifier

    Definition
    This is based on the UN/CEFACT Identifier class.
    Usage Note
    An identifier in a particular context, consisting of the
    • content string that is the identifier;
    • an optional identifier for the identifier scheme;
    • an optional identifier for the version of the identifier scheme;
    • an optional identifier for the agency that manages the identifier scheme.
    Properties
    For this entity the following properties are defined: notation .
    Property Range Card Definition Usage DCAT Reuse
    notation Literal 1 A string that is an identifier in the context of the identifier scheme referenced by its datatype. P

    Legal Resource

    Definition
    This class represents the legislation,policy or policies that lie behind the Rules that govern the service.
    Usage Note
    The definition and properties of the Legal Resource class are aligned with the ontology included in "Council conclusions inviting the introduction of the European Legislation Identifier (ELI)". For describing the attributes of a Legal Resource (labels, preferred labels, alternative labels, definition, etc.) we refer to the (ELI) ontology. In this data specification the use is restricted to instances of this class that follow the (ELI) URI guidelines.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Linguistic system

    Definition
    A system of signs, symbols, sounds, gestures, or rules used in communication, e.g. a language.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Literal

    Definition
    A literal value such as a string or integer; Literals may be typed, e.g. as a date according to xsd:date. Literals that contain human-readable text have an optional language tag as defined by BCP 47 [[rfc5646]].
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Media type

    Definition
    A media type, e.g. the format of a computer file.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Period of time

    Definition
    An interval of time that is named or defined by its start and end dates.
    Reference in DCAT
    Link
    Properties
    For this entity the following properties are defined: beginning , end , end date , start date .
    Property Range Card Definition Usage DCAT Reuse
    beginning Time instant 0..1 The beginning of a period or interval. Link E
    end Time instant 0..1 The end of a period or interval. Link E
    end date Temporal Literal 0..1 The end of the period. Link E
    start date Temporal Literal 0..1 The start of the period. Link E

    Policy

    Definition
    A non-empty group of Permissions and/or Prohibitions.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Provenance Statement

    Definition
    A statement of any changes in ownership and custody of a resource since its creation that are significant for its authenticity, integrity, and interpretation.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Resource

    Definition
    Anything described by RDF.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Rights statement

    Definition
    A statement about the intellectual property rights (IPR) held in or over a resource, a legal document giving official permission to do something with a resource, or a statement about access rights.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Role

    Definition
    A role is the function of a resource or agent with respect to another resource, in the context of resource attribution or resource relationships.
    Reference in DCAT
    Link
    Usage Note
    Note it is a subclass of skos:Concept.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Standard

    Definition
    A standard or other specification to which a resource conforms.
    Properties
    This specification does not impose any additional requirements to properties for this entity.

    Datatypes

    The following datatypes are used within this specification.
    Class Definition
    (create issue) A file format or physical medium.
    (create issue) A media type or extent.
    (create issue) rdfs:Literal encoded using the relevant [[ISO8601]] Date and Time compliant string and typed using the appropriate XML Schema datatype (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime).
    (create issue) A temporal entity with zero extent or duration.
    (create issue) Object with integer-valued year, month, day, hour and minute properties, a decimal-valued second property, and a boolean timezoned property.
    (create issue) Decimal represents a subset of the real numbers, which can be represented by decimal numerals. The ·value space· of decimal is the set of numbers that can be obtained by multiplying an integer by a non-positive power of ten, i.e., expressible as i × 10^-n where i and n are integers and n >= 0.
    (create issue) Duration represents a duration of time. The ·value space· of duration is a six-dimensional space where the coordinates designate the Gregorian year, month, day, hour, minute, and second components defined in § 5.5.3.2 of [[ISO8601]], respectively.
    (create issue) Hex-encoded binary data. The ·value space· of hexBinary is the set of finite-length sequences of binary octets.
    (create issue) Number derived from integer by setting the value of minInclusive to be 0.

    Controlled Vocabularies

    Requirements for controlled vocabularies

    The following is a list of requirements that were identified for the controlled vocabularies to be recommended in this Application Profile. Controlled vocabularies SHOULD: These criteria do not intend to define a set of requirements for controlled vocabularies in general; they are only intended to be used for the selection of the controlled vocabularies that are proposed for this Application Profile.

    Controlled vocabularies to be used

    In the table below, a number of properties are listed with controlled vocabularies that MUST be used for the listed properties. The declaration of the following controlled vocabularies as mandatory ensures a minimum level of interoperability.

    Property URIUsed for ClassVocabulary nameUsage note
    dcat:mediaTypeDistributionIANA Media Types
    dcat:themeDatasetDataset Theme VocabularyThe values to be used for this property are the URIs of the concepts in the vocabulary.
    dct:accrualPeriodicityDataset,Dataset SeriesEU Vocabularies Frequency Named Authority List
    dct:formatDistribution,Data Service EU Vocabularies File Type Named Authority List
    dct:languageCatalogue,Dataset, Catalogue Records, DistributionEU Vocabularies Languages Named Authority List
    dct:publisherCatalogue,Dataset,Dataset SeriesEU Vocabularies Corporate bodies Named Authority ListThe Corporate bodies NAL must be used for European institutions and a small set of international organisations. In case of other types of organisations, national, regional or local vocabularies should be used.
    dct:spatialCatalogue,Dataset,Dataset SeriesEU Vocabularies Continents Named Authority List, EU Vocabularies Countries Named Authority List, EU Vocabularies Places Named Authority List, Geonames The EU Vocabularies Name Authority Lists must be used for continents, countries and places that are in those lists; if a particular location is not in one of the mentioned Named Authority Lists, Geonames URIs must be used.
    adms:statusDistributionEU Vocabularies Distribution Status
    dct:typeAgentADMS publisher type vocabulary The list of terms in the ADMS publisher type vocabulary is included in the ADMS specification
    dct:typeLicence DocumentADMS licence type vocabulary The list of terms in the ADMS licence type vocabulary is included in the ADMS specification
    dcatap:availabilityDistributionDistribution availability vocabularyThe list of terms for the avalability levels of a dataset distribution in the DCAT-AP specification.
    spdx:algorithmChecksumChecksum algorithm membersThe members listed are considered a controlled vocabulary of supported checksum algorithms.
    dct:accessRightsDataset, Data ServiceAccess Rights Named Authority ListUse one of the following values (:PUBLIC, :RESTRICTED, :NON_PUBLIC).

    In the table below, a number of properties are listed with controlled vocabularies that MAY be used for the listed properties. The declaration of the following controlled vocabularies as recommended stimulates interoperability.

    Property URIUsed for ClassVocabulary nameUsage note
    dct:typeDatasetDataset-type authority tableThis list of terms provide types of datasets. Its main scope is to support dataset categorisation of the EU Open Data Portal.

    Other controlled vocabularies

    In addition to the proposed common controlled vocabularies, which are mandatory to ensure minimal interoperability, implementers are encouraged to publish and to use further region or domain-specific vocabularies that are available online. While those may not be recognised by general implementations of the Application Profile, they may serve to increase interoperability across applications in the same region or domain. Examples are the full set of concepts in EuroVoc, the CERIF standard vocabularies, the Dewey Decimal Classification and numerous other schemes.

    Legal information

    Providing correct and sufficient legal information is important to create trust by candidate reusers. Without explicit legal information there is a risk involved in the reuse of data, because one has no way of knowing what is allowed. While in the past legislation and initiatives such as Findable, Accessible, Interoperable and Reusable [[FAIR]] data stress the importance of this information, recent legislations, such as the High Value Datasets regulation, have become more demanding by imposing a minimum level of reuse. As a general principle, it is recommended that publishers consult their legal services to provide the appropriate values.

    Within DCAT-AP properties licence, rights and access rights are used to share this information. The basic guidelines for their usage are expressed in the License and Rights statements guideline in DCAT. DCAT-AP implementers SHOULD consult these, in addition with the additional advices for the DCAT-AP usage context provided in this section.

    The general principle is that licences, rights and access rights are expressions in the context of a legislation. It is possible (and allowed) that a EU Member State prescribes specific licences to be used for data published by the public sector. And thus, publishers of that EU Member State will use that in the metadata descriptions. This diversity can be considered a hurdle for cross-border reuse, as the implications of the licence might not be understood by users from another EU Member State.

    This creates a natural tendency to use licences (or rights) which have a wider adoption than national legislation. Unless restricted by national legislation, implementers are encouraged for that reason to use widely recognised licences such as Creative Commons licences. In particular it is advised for [[FAIR]] data to consider CC BY 4.0 (the minimum limit set by the HVD implementing regulation) or more permissive such as licences CC Zero.

    An assessment of data.europa.eu [[DEU]] in 2023 showed that there are different representations to indicate the same licence. To create a more harmonised experience throughout Europe, it is recommended to use the NAL licence maintained by the Publications Office if allowed by national legislation. If local representations are used, then the equivalence with a licence in this NAL should be provided. This mapping is expressed as metadata to local representation. Note that this mapping is not determining the reuse conditions; the legal binding reuse conditions are those that are directly associated with the Distribution or Data Service. Nevertheless, by applying this recommendation, it is possible for a cross-border reuser to get an insight in the reuse conditions without a detailed understanding the local legislation.

    To encourage publishers to provide legal information DCAT-AP recommends to provide licence information. However, in some EU Member States, the term licence has a specific interpretation; in that interpretation the to-be provided legal information cannot be supplied as a document for property licence. In those legislative contexts it is advised to translate this encouragement in appropriate metadata guidelines for the targeted publishers. For instance, such guidelines could state that one must use a set of rights to document the reuse conditions.

    Since legal information may vary per distribution or service, DCAT-AP has adopted from its conception, the strategy to only express legal information at the most concrete level of sharing, i.e. Distribution or Data Service. Suppose licensing information is also given on the Dataset level, there is a possibility that this is in conflict with licensing information on the Distribution, in which case it cannot be established which licence takes precedence. By this strategy, the need for a conflict resolution between legal information at the level of a Dataset (or Dataset Series) and its associated Distributions or Data Services is avoided.

    Despite the above examples provided here are a perfect fit for those that are in scope of 'Open Data', they apply also for data that is beyond the scope of 'Open Data'. E.g. the Data Governance Act requires to provide sufficient legal reuse information such as the fees that apply.

    Agent Roles

    The first version of DCAT Application Profile [[vocab-dcat-1]] had a single property to relate an Agent (typically, an organisation) to a Dataset. The only such ‘agent role’ that could be expressed in that version of the profile is through the property publisher, defined as “An entity responsible for making the dataset available”. A second property is available in that DCAT recommendation [[vocab-dcat-1]], contact point, defined as “Link a dataset to relevant contact information which is provided using vCard”, but this is not an agent role as the value of this property is contact data, rather than a representation of the organisation as such. In specific cases, for example in exchanging data among domain-specific portals, it may be useful to express other, more specific agent roles. In such cases, extensions to DCAT-AP may be defined using additional properties with more specific meanings.

    Two possible approaches have been discussed, particular in the context of the development of the domain-specific GeoDCAT Application Profile [[geodcat-ap]]. The first possible approach is based on the use of a predicate vocabulary that provides a set of properties that represent additional types of relationships between Datasets and Agents. For example, properties could be defined, such as foo:owner, foo:curator or foo:responsibleParty, in addition to the use of existing well-known properties, such as dct:creator and dct:rightsHolder. A possible source for such additional properties is the Roles Named Authority List maintained by the Publications Office of the EU. Other domain-specific sources for additional properties are the INSPIRE Responsible Party roles ,the Library of Congress’ MARC relators and DataCite’s contributor types. To enable the use of such properties, they must be defined as RDF properties with URIs in a well-managed namespace.

    A second approach is based on the use of W3C’s PROV ontology [[prov-o]] which provides a powerful mechanism to express a set of classes, properties, and restrictions that can be used to represent and interchange provenance information generated in different systems and under different contexts. In the context of work on GeoDCAT-AP, a PROV-conformant solution for expressing agent roles was agreed . This solution uses prov:qualifiedAttribution in combination with a dct:type assertion pointing to the code list for Responsible Party Role in the INSPIRE registry. To enable the use of such types, they must be defined with URIs in a well-managed namespace.

    Based on the experience gained with the use of domain-specific extensions for additional ‘agent roles’ in the exchange of information about Datasets and on the requests of implementors and stakeholders, the DCAT Application Profile release 2.0.0 is extended with additional roles as proposed by DCAT Version 2 [[vocab-dcat-2]] that have proven to be useful across domains. Precisely, properties creator, qualified attribution and qualified relation have been added to Dataset class to further facilitate relationships between datasets and agents.

    In the most recent DCAT Version 3 [[vocab-dcat-3]] a dedicated section on the relationship with Agents is provided. The DCAT-AP guidelines for Agents Roles are conformant to this.

    It should be noted that, even if a more expressive approach is used in a particular implementation, the provision of information using dct:publisher for the Catalogue is still mandatory under the rules laid down in the Conformance Statement in section [[[#conformance]]], while the provision of information using dct:publisher is strongly recommended for Dataset. The provision of such information using dct:publisher will ensure interoperability with implementations that use the basic approach of DCAT-AP.

    Accessibility and Multilingual Aspects

    Accessibility in the context of this Application Profile is limited to information about the technical format of distributions of datasets. The properties dcat:mediaType and dct:format provide information that can be used to determine what software can be deployed to process the data. The accessibility of the data within the datasets needs to be taken care of by the software that processes the data and is outside of the scope of this Application Profile.

    Multilingual aspects related to this Application Profile concern all properties whose contents are expressed as strings (i.e. rdfs:Literal) with human-readable text. Wherever such properties are used, the string values are of one of two types:

    Wherever values of properties are expressed with either type of string, the property can be repeated with translations in the case of free text and with parallel versions in case of named entities. For free text, e.g. in the cases of titles, descriptions and keywords, the language tag is mandatory.

    Language tags to be used with rdfs:Literal are defined by BCP47 [[rfc5646]], which allows the use of the "t" extension for text transformations defined in RFC6497 [[rfc6497]] with the field "t0" indicating a machine translation.

    A language tag will look like: "en-t-es-t0-abcd", which conveys the information that the string is in English, translated from Spanish by machine translation using a tool named "abcd".

    For named entities, the language tag is optional and should only be provided if the parallel version of the name is strictly associated with a particular language. For example, the name ‘European Union’ has parallel versions in all official languages of the union, while a name like ‘W3C’ is not associated with a particular language and has no parallel versions.

    For linking to different language versions of associated web pages (e.g. landing pages) or documentation, a content negotiation mechanism may be used whereby different content is served based on the Accept-Languages indicated by the browser. Using such a mechanism, the link to the page or document can resolve to different language versions of the page or document.

    All the occurrences of the property dct:language, which can be repeated if the metadata is provided in multiple languages, MUST have a URI [[rfc3986]] as their object, not a literal string from the ISO 639 code list.

    How multilingual information is handled in systems, for example in indexing and user interfaces, is outside of the scope of this Application Profile.

    General usage guidelines

    Usage guide on Datasets, Distributions and Data Services

    The introduction of Data Services as first class citizens in DCAT 2.0 raised questions about the usage of Data Services and Distributions. This section provides a guideline for publishers what to consider as a Distribution and what as a Data Service.

    A first distinction between distributions and data services is their dependency on a dataset for their existence. A distribution cannot exist without its dataset. It is a specific representation of a dataset (cfr definition W3C Distribution). Whereas a data service is an entity in its own right. It provides access to datasets or it provides data processing functions. The independence also holds between the distributions of a dataset, and the data service which provides access to that dataset. The distributions are not required to be the result of the data service operations. However, they may.

    Many of the properties of distributions are file oriented (downloadURL, format, byte size, checksum, modification date, ...). The relevance of this information is reduced for data services, related information is present in a very different form and thus under different terminology. For instance, data services do and can provide format transformations, language transformations and schema transformations on request. Also the handling of trust is different. While tampering of downloadable content is detected by e.g. checksums, data services create often a trusted channel using security measures such as authentication and encryption. This reduces the need for additional trust checks on the data.

    The difference between downloading a file or accessing the data through a service have resulted in the following guidelines:

    Orthogonal to the nature clarification of distributions and data services, there might be need for a granularity clarification between datasets and distributions. Commonly, at first sight, it is expected that all distributions of a dataset are identical in content, only differing in the representation of the data. But when considering dataset series, this interpretation seems not valid anymore. In the upcoming release of DCAT 3.0, dataset series and dataset versioning are addressed. Implementors are advised to already take this proposal into account when creating guidelines for distributions. Note that this is less an issue between datasets and data services as both are independent entities. Data services usually address the granularity by providing the necessary query interface language so that the user can get the data according its needs.

    These guidelines will be able to capture many access patterns, corresponding to most users' expectations. However there might be cases that are more vague. In that case the DCAT(-AP) community can be questioned for a recommended approach.

    Usage guide on Dataset Series

    Dataset Series can be considered as message from the publisher that the data of a dataset evolves according to one or more dimensions and that this evolution is available via a collection of independent, yet closely related, datasets.

    The need for sharing this grouping explicitly is strongly use case dependent, and therefore as this will require additional metadata management effort by the publisher, the use of Dataset Series is optional. It should fit the objectives. For instance, if a publisher is sharing an active updated dataset accessible via an API, that provides current as historic data, then it is not mandatory to created metadata records for each snapshot per year. Only if these snapshots are created intentionally and the publisher wants to share the life cycle of them with the public, then Dataset Series come into the picture.

    In order to harmonise the use of Dataset Series, the following guidelines are to be considered:

    In general it is expected that the members of Dataset Series are strongly connected. However, there are no common criteria or rules how this connection could be determined. Usually, the shared characteristics are expressed as a data domain, e.g. the population of bees, and some evolution in space and time, e.g. in Greece for the period of 2019-2023, and published by a single publisher. Nevertheless, other characteristics could give raise to the creation of a Dataset Series.

    The DCAT-AP working group has investigated to find and express unique characteristics of Datasets that are members of a Dataset Series. Over time, during the exchanges it became clear that today no consensus exists on restricting the use of Dataset Series to a more limited use. Therefore the DCAT-AP working group has decided to retract the notion of a Dataset Member of a Dataset Series (a subclass of DCAT-AP Datasets). Profile builders may reintroduce this notion when they want to express specific constraints for that usage scope.

    In case the connection is very strong or the result of an automated process, versioning terminology is a natural way to express the connection between the Datasets in the Dataset Series collection. For guidelines on expressing versioning information in DCAT-AP, consult the DCAT guidelines on versioning. As versioning is not always the most appropriate terminology, DCAT introduces properties (e.g. next, previous, inSeries, last, etc.) to interconnect the Dataset Series with its members and among the members themselves. It is recommended to use always these properties in combination with Dataset Series, and versioning when appropriate.

    The membership in a Dataset Series may influence the (descriptive) metadata to highlight differences from other Datasets in the collection. For instance, a usual adaption is the addition of the release data in the title.

    High Value Datasets

    In light of the growing importance of data, the European Commission has adopted an implementing regulation focused on high-value datasets on 21 December 2022 [[HVD]]. The ambition of the High-Value Datasets implementing regulation (HVD IR) is to improve the quality, the accessibility and use of a selective number of core datasets within the public sector. To achieve this the HVD IR sets, among others, requirements on the metadata associated with the disclosed datasets. These requirements can be expressed as additional constraints and usage notes on DCAT-AP and are collected in an annex dedicated to the implementation of the HVD IR [[DCAT-AP-HVD]].

    Support for implementation

    Implementing the DCAT-AP data specification in a data exchange between two systems raises also technical questions.

    JSON-LD context file

    One common technical question is the format in which the data is being exchanged. For DCAT-AP conformance, it is not mandatory that this happens in a RDF serialisation, but the exchanged format SHOULD be unambiguously be transformable into RDF. For the format JSON, a popular format to exchange data between systems, DCAT-AP provides a JSON-LD context file. JSON-LD is a W3C Recommendation [[[json-ld11]]] that provided a standard approach to interpret JSON structures as RDF. The provided JSON-LD context file can be used by implementers to base their data exchange upon, and so create a DCAT-AP conformant data exchange. This JSON-LD context is not normative, i.e. other JSON-LD contexts are allowed to create a a conformant DCAT-AP data exchange.

    The JSON-LD context file downloadable here.

    Identifiers

    For implementers, the requirement to being able to exchange data as RDF impacts the design of the exchange format and the data management. One aspect, the use of identifiers, needs special attention as it influences the interpretation by others. DCAT-AP is used mostly in a harvesting network: where one catalogue harvests from other. By this process, the DCAT-AP metadata descriptions spread through the harvesting network. In contrast to "classical" data exchange patterns where by default identifiers are locally scoped to the exchange context, the RDF format implicitly assumes global, public accessible identifiers (URIs). Harvesting enforces the latter. More on this identifier challenge and possible solution approaches are documented in the the guidelines on identifier management in DCAT-AP.

    Validation

    To verify if the data exchange is (technically) conformant to DCAT-AP, the exchanged data can be validated using the provided SHACL shapes. SHACL is a W3C Recommendation to express constraints on a RDF knowledge graph. The provided SHACL shapes allow to check whether an DCAT-AP catalogue expressed in a RDF serialization is valid. As it should be possible for DCAT-AP conformance to transform the data exchange in RDF, these SHACL shapes can be used in any data exchange context. However, likewise the use of the JSON-LD context, the provided SHACL shapes provide only a start point for implementers.

    The shapes that can be derived from the DCAT-AP specification have the following usage limitations. Shapes may check situations that never occur in the implemented data exchange and result in messages that confuse publishers, or they are too general and more detailed checks should be implemented. For example, the nature of a licence is recommended by DCAT-AP, but most DCAT-AP exchanges assume that based on the URI of the licence this information is known. Thus the check that a licence should have a licence type is considered often not relevant for the individual publishers. However they might support catalogue maintainers to guide individual publishers to use well-documented licence URIs. The case that a title cannot be an empty string and must have a value in a specific language are examples of more detailed constraints that are not present in the provided DCAT-AP SHACL shapes.

    More on the validation and the provided SHACL shapes can be found in section [[[#validation-of-dcat-ap]]].

    Validation of DCAT-AP

    To support the check whether or not a catalogue satisfies the expressed constraints in this Application Profile, the constraints in this specification are expressed using SHACL [[shacl]]. Each constraint in this specification that could be converted into a SHACL expression has been included. As such this collection of SHACL expressions that can be used to build a validation check for a data exchange between two systems. A typical use case is the harvesting of one catalogue into another.

    It is up to the implementers of the data exchange to define the validation they expect. Each data exchange happens within a context, and that context is beyond the SHACL expressions here.

    For instance, it might be known that the exchanged data does not contain the details of the organisations, as they are all uniquely identified by a deferenceable URI. In such case, the rules regarding the check of the mandatory existence of a name for each organisation is probably not relevant. A strict execution of the DCAT-AP SHACL expressions will raise errors, although the data is available through a different channel. In this example, it is valid to not include this check in this validation step.

    The example illustrates that in order to get the right user experience of a validation process, one has to consider what is actually transferred between the systems. And use the constraints that are in scope of the data exchange. To assist this process the SHACL expressions are grouped in distinct files, matching already typical validation setups.

    The first file provides for each class mentioned in DCAT-AP, and having additional properties defined, a template with the corresponding constraints. Class membership constraints are not present in the first file. These are collected in the second file. 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. As support, the following files express the imports (not transitive) according to the SHACL specification, which can be loaded into the Interoperable Europe Testbed. The shacl files are configured in this instance of the Interoperable Europe testbed: https://www.itb.ec.europa.eu/shacl/dcat-ap/upload. More information about the configured validation profiles is https://github.com/ISAITB/validator-resources-dcat-ap.

    In addition to these SHACL shapes extending the approach from DCAT-AP 2.x, the constraints are also provided in a new design where each constraint has got a unique identifier. This new shape is addressing the request for having a design in which DCAT-AP implementers could cherry pick the constraints they want. The shape is downloadable here.

    Example Dataset Series

    This section describes the use of Dataset Series via examples. All examples are fictitious and are created to facilitate the understanding of Dataset Series. This section complements the usage explained in section Dataset series in DCAT 3 [[vocab-dcat-3]], because it illustrates the decision making process when switching from publishing a single Dataset to a Dataset Series.

    Consider the dataset 'Bee population in Greece" published by the Greek Environment Agency. Users can download the data as a CSV or an RDF file.

    Example 1 - Bee population dataset

    To see the evolution in the bee population, the Greek Environment Agency publishes an update each year. This update can be reflected in the DCAT-AP description in various ways.

    The first option is to update and renew the metadata each update. For instance, the temporal coverage changes from the period "2020 - 2022" to "2020 - 2023".

    This solution has as benefit that new information is shared with a minimal effort of publisher. However, this approach removes the previous state of affairs from the metadata and also does not reflect the aggregation and publishing effort for the dataset in the metadata. In some cases this is a desired outcome.

    The alternative option is the creation of a new dataset description. Often this choice is a voluntary decision, however it might be enforced by legislation. Legislation can impose to share an audited dataset reflecting the state of affairs on a reference date.

    The creation of new dataset also impacts the metadata, as the generic title "Bee population" cannot be maintained for both. A publisher must perform a minimal disambiguation effort to make the two datasets distinct.

    Example 2 - Bee population datasets for 2022 and 2023

    Independent of the metadata descriptions, a core decision to take is whether the dataset BeePopulation2022 is also contained in the dataset BeePopulation2023. Either case is valuable and seen in practice.

    However, without expressing any relationships between the datasets this approach has a major drawback: a search on the catalogue for bee population will result in several variants of the same dataset. The catalogue user is not provided with any guidance to select the most recent or most appropriate one. To address that use case, Dataset Series come into the picture. Dataset Series offer a structured approach to order or organise the datasets by the publisher for the catalogue user.

    To support the data portal users, the Greek Environment Agency starts managing a Dataset Series BeePopulation.

    Example 3 - Bee population datasets series

    As the dataset BeePopulation2023 is more recent than BeePopulation2022, a navigation ordering is added.

    Example 4 - Bee population datasets series ordered

    In most cases, the navigation is a single chain sequence, although tree organised structures are not prohibited.

    Similarly as the introduction of a new dataset description, the introduction of a Dataset Series impacts the metadata of the involved datasets.

    For instance the notion of the update frequency becomes more precise. In case of a single dataset description, the statement, in the example below, means that the dataset is updated each year.

    Example 5 - Bee population dataset frequency

    So each year the actual data to which this dataset provides access to changes, and the most recent information can be found via this metadata.

    However; when the publisher will introduce a new dataset description each year, the update frequency of an existing dataset is none. Namely it will not be updated. Without a Dataset Series notion the information of the yearly update is lost.

    Example 6 - Bee population dataset series frequency

    Users expect that metadata of Dataset Series is coherent with the collection of datasets it refers to. Up to 2022, the Greek Environment Agency only had the ability to provide the information for the region of Thessaloniki, and shared that via the spatial coverage.

    Example 7 - Bee population dataset series about Thessaloniki

    From 2023 onwards, data for the region of Athens is also provided. As a consequence, not only the spatial coverage of the new dataset BeePopulation2023 will reflect that, but also the one of the Dataset Series. Namely the geographical coverage of a dataset series will cover the union of all places of each dataset associated with the Dataset Series.

    Example 8 - Bee population dataset series about Thessaloniki and Athens

    A similar coherency concern applies to the temporal coverage of datasets. Publisher are advised to verify the properties title and description to match any reference to temporal and geographical coverage information with the properties.

    The metadata descriptions of a Dataset Series provide insight in how this collection of datasets evolves. The release date of the Dataset Series BeePopulation correspond to the moment the collection has been issued for the first time. In many cases this moment corresponds to the earliest release date of the dataset in the collection. In the example, the Dataset BeePopulation2022 was first issued on 2022-04-01 while shortly after, the Dataset Series was created.

    Example 9 - Bee population dataset series issuing

    This relationship between the issuing date and the oldest dataset in the collection can reduce over time. The Greek Environment Agency and the National History Archives start to collaborate on the use and production of honey. That project results in new datasets on bee populations predating 2022. To make that information visible, the Dataset Series collection is updated with these historic datasets.

    Example 10 - Bee population dataset series with National History Archive

    The modification date of the Dataset Series is the moment the collection has changed. The addition of the historic datasets changes the collection, and thus the modification date of the Dataset Series is set to 2023-06-01.

    Example 11 - Bee population dataset series with modification date

    To make the datasets easier to use, the Greek Environment Agency introduces a new API platform. Via this API platform the datasets are not only downloadable in tabular format, but also in the international Biodiversity JSON format.

    Example 11 - Bee population available in new format
    As such the use of a new API platform has not changed the data denoted by the dataset BeePopulation2023, and so it is not necessary to adapt the modification date of the dataset. Similarly adding or removing distributions to a dataset did not affected the membership of dataset BeePopulation2023 in the Dataset Series. And thus the modification date of the Dataset Series is not adapted.

    To support the users even more, the API platform is extended with a possibility to get life counts of the bee population. This means that there is a dataset which data is updated very frequently, eg. every second. In that case providing a modification date for the dataset becomes a technical challenge, but also it reduces it value. Namely one gets the data at query time.

    Example 12 - Bee population dataset series API life count
    All this can be combined in one dataset series about the Bee population. Doing so, the Bee population dataset series becomes less a structured sequence of yearly snapshots of the Bee population data, but more a collection of datasets around the same topic. Likewise DCAT, DCAT-AP does not limit the use of dataset series to a strict interpretation. Making this approach acceptable. Nevertheless users usually expect that the datasets of a Dataset Series are strongly related, and the notion of a series or sequence is somehow present in the collection. Diverging too far from this interpretation is not recommended. The alternative for dataset series for grouping datasets are catalogues.

    Thus to conclude the example of maintaining a Dataset Series, the Greek Environment Agency has created a Dataset Series about the Bee population in Greece. It contains the dataset with actual life data, the yearly snapshots for 2023 and 2022 and also the historic data of 2000 maintained by the National History Archives.

    Example 13 - Bee population dataset series

    Inverse properties

    The W3C DCAT specification introduces for some relationships two properties which are eachothers inverse. In general, this may lead to situations that data exchanges based on different DCAT profiles require reasoning to align.

    To harmonise the exchange of DCAT based data and reduce the need for inference engines, W3C DCAT imposes implementation guidelines expressing a preference in use. The guidelines state which property must be used while the other, called the inverse, may be used. In a proper DCAT profile the inverse property cannot be used to replace completely the property.

    In line with these guidelines with the objective to reduce the burden of implementers DCAT-AP will follow the W3C guidelines in a more strict way. When a property is subject to this W3C guideline then DCAT-AP will include only the use of this property and not the inverse. Implementers are still free to use the inverse to optimise their data management.

    As note to this discussion: when exchanging DCAT as an RDF graph the impact of the directionality is reduced because

    Quick Reference of Classes and Properties

    This section provides a condensed tabular overview of the mentioned classes and properties in this specification. The properties are grouped under headings mandatory, recommended, optional and deprecated. These terms have the following meaning.
    ClassClass IRIProperty TypePropertyProperty IRI
    Activity
    http://www.w3.org/ns/prov#Activity
    Agent
    http://xmlns.com/foaf/0.1/Agent
    Mandatory name
    http://xmlns.com/foaf/0.1/name
    Agent
    http://xmlns.com/foaf/0.1/Agent
    Recommended type
    http://purl.org/dc/terms/type
    Attribution
    http://www.w3.org/ns/prov#Attribution
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Mandatory description
    http://purl.org/dc/terms/description
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Mandatory publisher
    http://purl.org/dc/terms/publisher
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Mandatory title
    http://purl.org/dc/terms/title
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Recommended dataset
    http://www.w3.org/ns/dcat#dataset
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Recommended geographical coverage
    http://purl.org/dc/terms/spatial
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Recommended homepage
    http://xmlns.com/foaf/0.1/homepage
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Recommended language
    http://purl.org/dc/terms/language
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Recommended licence
    http://purl.org/dc/terms/license
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Recommended modification date
    http://purl.org/dc/terms/modified
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Recommended release date
    http://purl.org/dc/terms/issued
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Recommended service
    http://www.w3.org/ns/dcat#service
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Recommended themes
    http://www.w3.org/ns/dcat#themeTaxonomy
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Optional applicable legislation
    http://data.europa.eu/r5r/applicableLegislation
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Optional catalogue
    http://www.w3.org/ns/dcat#catalog
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Optional creator
    http://purl.org/dc/terms/creator
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Optional has part
    http://purl.org/dc/terms/hasPart
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Optional record
    http://www.w3.org/ns/dcat#record
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Optional rights
    http://purl.org/dc/terms/rights
    Catalogue
    http://www.w3.org/ns/dcat#Catalog
    Optional temporal coverage
    http://purl.org/dc/terms/temporal
    Catalogue Record
    http://www.w3.org/ns/dcat#CatalogRecord
    Mandatory modification date
    http://purl.org/dc/terms/modified
    Catalogue Record
    http://www.w3.org/ns/dcat#CatalogRecord
    Mandatory primary topic
    http://xmlns.com/foaf/0.1/primaryTopic
    Catalogue Record
    http://www.w3.org/ns/dcat#CatalogRecord
    Recommended application profile
    http://purl.org/dc/terms/conformsTo
    Catalogue Record
    http://www.w3.org/ns/dcat#CatalogRecord
    Recommended change type
    http://www.w3.org/ns/adms#status
    Catalogue Record
    http://www.w3.org/ns/dcat#CatalogRecord
    Recommended listing date
    http://purl.org/dc/terms/issued
    Catalogue Record
    http://www.w3.org/ns/dcat#CatalogRecord
    Optional description
    http://purl.org/dc/terms/description
    Catalogue Record
    http://www.w3.org/ns/dcat#CatalogRecord
    Optional language
    http://purl.org/dc/terms/language
    Catalogue Record
    http://www.w3.org/ns/dcat#CatalogRecord
    Optional source metadata
    http://purl.org/dc/terms/source
    Catalogue Record
    http://www.w3.org/ns/dcat#CatalogRecord
    Optional title
    http://purl.org/dc/terms/title
    Catalogued Resource
    http://www.w3.org/ns/dcat#Resource
    Checksum
    http://spdx.org/rdf/terms#Checksum
    Mandatory algorithm
    http://spdx.org/rdf/terms#algorithm
    Checksum
    http://spdx.org/rdf/terms#Checksum
    Mandatory checksum value
    http://spdx.org/rdf/terms#checksumValue
    Checksum Algorithm
    http://spdx.org/rdf/terms#ChecksumAlgorithm
    Concept
    http://www.w3.org/2004/02/skos/core#Concept
    Mandatory preferred label
    http://www.w3.org/2004/02/skos/core#prefLabel
    Concept Scheme
    http://www.w3.org/2004/02/skos/core#ConceptScheme
    Mandatory title
    http://purl.org/dc/terms/title
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Mandatory endpoint URL
    http://www.w3.org/ns/dcat#endpointURL
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Mandatory title
    http://purl.org/dc/terms/title
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Recommended application profile
    http://purl.org/dc/terms/conformsTo
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Recommended contact point
    http://www.w3.org/ns/dcat#contactPoint
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Recommended endpoint description
    http://www.w3.org/ns/dcat#endpointDescription
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Recommended keyword
    http://www.w3.org/ns/dcat#keyword
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Recommended publisher
    http://purl.org/dc/terms/publisher
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Recommended serves dataset
    http://www.w3.org/ns/dcat#servesDataset
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Recommended theme
    http://www.w3.org/ns/dcat#theme
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Optional access rights
    http://purl.org/dc/terms/accessRights
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Optional applicable legislation
    http://data.europa.eu/r5r/applicableLegislation
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Optional description
    http://purl.org/dc/terms/description
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Optional documentation
    http://xmlns.com/foaf/0.1/page
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Optional format
    http://purl.org/dc/terms/format
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Optional landing page
    http://www.w3.org/ns/dcat#landingPage
    Data Service
    http://www.w3.org/ns/dcat#DataService
    Optional licence
    http://purl.org/dc/terms/license
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Mandatory description
    http://purl.org/dc/terms/description
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Mandatory title
    http://purl.org/dc/terms/title
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Recommended contact point
    http://www.w3.org/ns/dcat#contactPoint
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Recommended dataset distribution
    http://www.w3.org/ns/dcat#distribution
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Recommended geographical coverage
    http://purl.org/dc/terms/spatial
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Recommended keyword
    http://www.w3.org/ns/dcat#keyword
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Recommended publisher
    http://purl.org/dc/terms/publisher
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Recommended temporal coverage
    http://purl.org/dc/terms/temporal
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Recommended theme
    http://www.w3.org/ns/dcat#theme
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional access rights
    http://purl.org/dc/terms/accessRights
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional applicable legislation
    http://data.europa.eu/r5r/applicableLegislation
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional conforms to
    http://purl.org/dc/terms/conformsTo
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional creator
    http://purl.org/dc/terms/creator
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional documentation
    http://xmlns.com/foaf/0.1/page
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional frequency
    http://purl.org/dc/terms/accrualPeriodicity
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional has version
    http://www.w3.org/ns/dcat#hasVersion
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional identifier
    http://purl.org/dc/terms/identifier
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional in series
    http://www.w3.org/ns/dcat#inSeries
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional is referenced by
    http://purl.org/dc/terms/isReferencedBy
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional landing page
    http://www.w3.org/ns/dcat#landingPage
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional language
    http://purl.org/dc/terms/language
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional modification date
    http://purl.org/dc/terms/modified
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional other identifier
    http://www.w3.org/ns/adms#identifier
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional provenance
    http://purl.org/dc/terms/provenance
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional qualified attribution
    http://www.w3.org/ns/prov#qualifiedAttribution
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional qualified relation
    http://www.w3.org/ns/dcat#qualifiedRelation
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional related resource
    http://purl.org/dc/terms/relation
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional release date
    http://purl.org/dc/terms/issued
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional sample
    http://www.w3.org/ns/adms#sample
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional source
    http://purl.org/dc/terms/source
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional spatial resolution
    http://www.w3.org/ns/dcat#spatialResolutionInMeters
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional temporal resolution
    http://www.w3.org/ns/dcat#temporalResolution
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional type
    http://purl.org/dc/terms/type
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional version
    http://www.w3.org/ns/dcat#version
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional version notes
    http://www.w3.org/ns/adms#versionNotes
    Dataset
    http://www.w3.org/ns/dcat#Dataset
    Optional was generated by
    http://www.w3.org/ns/prov#wasGeneratedBy
    Dataset Series
    http://www.w3.org/ns/dcat#DatasetSeries
    Mandatory title
    http://purl.org/dc/terms/title
    Dataset Series
    http://www.w3.org/ns/dcat#DatasetSeries
    Recommended contact point
    http://www.w3.org/ns/dcat#contactPoint
    Dataset Series
    http://www.w3.org/ns/dcat#DatasetSeries
    Recommended geographical coverage
    http://purl.org/dc/terms/spatial
    Dataset Series
    http://www.w3.org/ns/dcat#DatasetSeries
    Recommended publisher
    http://purl.org/dc/terms/publisher
    Dataset Series
    http://www.w3.org/ns/dcat#DatasetSeries
    Recommended temporal coverage
    http://purl.org/dc/terms/temporal
    Dataset Series
    http://www.w3.org/ns/dcat#DatasetSeries
    Optional applicable legislation
    http://data.europa.eu/r5r/applicableLegislation
    Dataset Series
    http://www.w3.org/ns/dcat#DatasetSeries
    Optional description
    http://purl.org/dc/terms/description
    Dataset Series
    http://www.w3.org/ns/dcat#DatasetSeries
    Optional frequency
    http://purl.org/dc/terms/accrualPeriodicity
    Dataset Series
    http://www.w3.org/ns/dcat#DatasetSeries
    Optional modification date
    http://purl.org/dc/terms/modified
    Dataset Series
    http://www.w3.org/ns/dcat#DatasetSeries
    Optional release date
    http://purl.org/dc/terms/issued
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Mandatory access URL
    http://www.w3.org/ns/dcat#accessURL
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Recommended format
    http://purl.org/dc/terms/format
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Recommended licence
    http://purl.org/dc/terms/license
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional access service
    http://www.w3.org/ns/dcat#accessService
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional applicable legislation
    http://data.europa.eu/r5r/applicableLegislation
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional availability
    http://data.europa.eu/r5r/availability
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional byte size
    http://www.w3.org/ns/dcat#byteSize
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional checksum
    http://spdx.org/rdf/terms#checksum
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional compression format
    http://www.w3.org/ns/dcat#compressFormat
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional description
    http://purl.org/dc/terms/description
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional documentation
    http://xmlns.com/foaf/0.1/page
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional download URL
    http://www.w3.org/ns/dcat#downloadURL
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional has policy
    http://www.w3.org/ns/odrl/2/hasPolicy
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional language
    http://purl.org/dc/terms/language
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional linked schemas
    http://purl.org/dc/terms/conformsTo
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional media type
    http://www.w3.org/ns/dcat#mediaType
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional modification date
    http://purl.org/dc/terms/modified
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional packaging format
    http://www.w3.org/ns/dcat#packageFormat
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional release date
    http://purl.org/dc/terms/issued
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional rights
    http://purl.org/dc/terms/rights
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional spatial resolution
    http://www.w3.org/ns/dcat#spatialResolutionInMeters
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional status
    http://www.w3.org/ns/adms#status
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional temporal resolution
    http://www.w3.org/ns/dcat#temporalResolution
    Distribution
    http://www.w3.org/ns/dcat#Distribution
    Optional title
    http://purl.org/dc/terms/title
    Document
    http://xmlns.com/foaf/0.1/Document
    Frequency
    http://purl.org/dc/terms/Frequency
    Geometry
    http://www.w3.org/ns/locn#Geometry
    Identifier
    http://www.w3.org/ns/adms#Identifier
    Mandatory notation
    http://www.w3.org/2004/02/skos/core#notation
    Kind
    http://www.w3.org/2006/vcard/ns#Kind
    Legal Resource
    http://data.europa.eu/eli/ontology#LegalResource
    Licence Document
    http://purl.org/dc/terms/LicenseDocument
    Recommended type
    http://purl.org/dc/terms/type
    Linguistic system
    http://purl.org/dc/terms/LinguisticSystem
    Literal
    http://www.w3.org/2000/01/rdf-schema#Literal
    Location
    http://purl.org/dc/terms/Location
    Recommended bbox
    http://www.w3.org/ns/dcat#bbox
    Location
    http://purl.org/dc/terms/Location
    Recommended centroid
    http://www.w3.org/ns/dcat#centroid
    Location
    http://purl.org/dc/terms/Location
    Optional geometry
    http://www.w3.org/ns/locn#geometry
    Media type
    http://purl.org/dc/terms/MediaType
    Period of time
    http://purl.org/dc/terms/PeriodOfTime
    Recommended end date
    http://www.w3.org/ns/dcat#endDate
    Period of time
    http://purl.org/dc/terms/PeriodOfTime
    Recommended start date
    http://www.w3.org/ns/dcat#startDate
    Period of time
    http://purl.org/dc/terms/PeriodOfTime
    Optional beginning
    http://www.w3.org/2006/time#hasBeginning
    Period of time
    http://purl.org/dc/terms/PeriodOfTime
    Optional end
    http://www.w3.org/2006/time#hasEnd
    Policy
    http://www.w3.org/ns/odrl/2/Policy
    Provenance Statement
    http://purl.org/dc/terms/ProvenanceStatement
    Relationship
    http://www.w3.org/ns/dcat#Relationship
    Mandatory had role
    http://www.w3.org/ns/dcat#hadRole
    Relationship
    http://www.w3.org/ns/dcat#Relationship
    Mandatory relation
    http://purl.org/dc/terms/relation
    Resource
    http://www.w3.org/2000/01/rdf-schema#Resource
    Rights statement
    http://purl.org/dc/terms/RightsStatement
    Role
    http://www.w3.org/ns/dcat#Role
    Standard
    http://purl.org/dc/terms/Standard

    Deprecated properties and classes

    The following URIs used in DCAT-AP release 2.x for properties have been deprecated in DCAT-AP 3.0 [[vocab-dcat-3]] in favor for the URIs within the DCAT namespace.

    To identify these deprecations, a SHACL shape is provided.

    Acknowledgments

    The editors gratefully acknowledge the contributions made to this document by all members of the working group.

    This work was elaborated by a Working Group under SEMIC by Interoperable Europe. Interoperable Europe of the European Commission was represented by Pavlina Fragkou. Bert Van Nuffelen, Makx Dekkers, Pavlina Fragkou, Jitse De Cock, Arthur Schiltz, Anastasia Sofou were the editors of the specification.

    Past and current contributors are : Ludger A. Rinsche , Kuldar Aasaga , Anssi Ahlberg , Matej Alic , Miguel Alvarez , Martin Alvarez-Espinar , Stefano Ambrogio , Oystein Asnes , Peter Burian , Luis Daniel Ibáñez , Ine De Visser , Makx Dekkers , Jean Delahousse , Ulrika Domellöf Mattsson , Adina Dragan , Dietmar Gattwinkel , Stijn Goedertier , Casper Gras , Bart Hanssens , Agnieszka Jasiczek , Fabian Kirstein , Jakub Klímek , Nataliia Kovalchuk , Andreas Kuckartz , Christine Laaboudi-Spoiden , Christoph Lange , Petros Likidis , Anja Loddenkemper , Giorgia Lodi , Hagar Lowenthal , Peter Lubrich , Lina Molinas Comet , Anastasija Nikiforova , Geraldine Nolf , Frederik Nordlander , Matthias Palmer , Andrea Perego , Taavi Ploompuu , Ludger Rinsche , Daniele Rizzi , Maik Roth , Fabian Santi , Giampaolo Sellitto , Maxime Servais , Sebastian Sklarß , Michele Spichtig , Emidio Stani , Igor Stefelin , Kees Trautwein , Thomas Tursics , Kristine Ulander , Joeri van der Velde , Sander Van Dooren , Bert Van Nuffelen , William Verbeeck , Thomas Weber , Suzanne Wigard , Christian Wittig , Agnieszka Zajac , Øystein Åsnes .