DCAT-AP-ES Technical guide and model

Introduction#

This document presents a detailed specification of the metadata that allows the description of catalogs and reusable data resources.

The metadata is described based on the Semantic Web paradigm, which implements resource description using the standard model for data exchange on the Web, RDF (Resource Description Framework). This approach allows different data cataloging systems to interact and exchange information effectively and consistently, achieving semantic interoperability to facilitate the search and discoverability of data resources, considerably improving their value for reuse.

The application profile, hereinafter DCAT-AP-ES, is the metadata model included in the new version of the Technical Interoperability Standard for Public Sector Information Resources (NTI-RISP), which is currently undergoing administrative processing. The model adopts the guidelines of the European metadata exchange schema DCAT-AP with some additional restrictions and adjustments, an application profile which in turn is based on the DCAT specification, an RDF vocabulary created with the aim of improving interoperability between online data catalogs that has been developed by the Dataset Exchange Working Group since it was published as a W3C recommendation in 2014. The version of the European profile taken as a reference for the development of DCAT-AP-ES is DCAT-AP 2.1.1 together with the elements described in the DCAT-AP HVD 2.2.0 extension to incorporate the modeling of High Value Datasets (High Value Datasets).

As is well known, an open data catalog can consist solely of datasets or data services, although it is usual for it to have both datasets and services and is represented by instances of the classes and properties specified in this model.

This document details the main classes of the application profile: Catalog, Dataset, Distribution and Data Service, as well as other relevant classes for complete descriptive information of the reusable elements cataloged according to the DCAT-AP-ES model. It also specifies the set of controlled vocabularies that must be used to adjust the properties that describe the cataloged elements.

In response to the growing importance of data in society and the economy, the European Commission adopted the Commission Implementing Regulation (EU) 2023/138 (High Value Datasets Implementing Regulation, HVD IR) on December 21, 2022. This regulation establishes clear guidelines for public bodies in the availability of high-value datasets and aims to improve the quality, accessibility and use of a specific set of key data within the public sector. To achieve this, the HVD regulation establishes specific requirements for the metadata associated with published datasets.

DCAT-AP-ES Metadata Model#

The following details the fundamental elements of the model, beginning with the UML diagram, the list of classes, the namespace used in the specification, and the list of controlled vocabularies.

Model Diagram#

The DCAT-AP-ES model is represented below as a UML diagram that illustrates the specification described in this document. To facilitate its interpretation, details that are included in the description of each metadata item in this document are omitted. Fundamentally, key classes and some relevant ones that support the former are included.

DCAT-AP-ES Application Profile Classes#

The most relevant classes used in the model are listed below:

• Catalog. The dcat:Catalog class represents a catalog, which is a dataset in which each individual element is a metadata record describing some resource. The content of a catalog consists of collections of metadata about datasets, data services, or other types of resources, including other catalogs. It functions as a unified access point that facilitates the search and reuse of data resources.
• Catalog Record. The Catalog Record class (dcat:CatalogRecord) describes individual entries within a data catalog, each one being a specific metadata record. A catalog record references an entity in the catalog which can be a dataset or a data service. It is primarily used to explicitly collect provenance information about entries in a catalog.
• Data Service. The Data Service class (dcat:DataService) represents a collection of operations accessible through an interface (API) that provides access to one or more datasets or data processing functions. Its use enables the cataloging of various types of data services, facilitating the implementation of functionalities for the programmatic handling and/or exploitation of data.
• Dataset. The Dataset class (dcat:Dataset) represents a conceptualization of a collection of information published by a single identifiable agent. The notion of dataset is broad with the intention of accommodating the types of resources that arise from a publication context and can be represented in many forms, including numbers, text, images, sound, and other media or types, any of which could be compiled into a dataset.
• Distribution. The Distribution of a dataset class (dcat:Distribution) represents an accessible and reusable form of a dataset, such as a downloadable file.
• Agent. The Agent class (foaf:Agent) is used to represent any organization or person who has competencies to perform actions on a catalog and the cataloged resources. Its main function is to provide concrete references about the different actors who can intervene with different roles in the management of a data catalog.
• Identifier. The (alternative) Identifier class of a dataset (adms:Identifier) is used to express the exclusive reference assigned to a dataset in the context of a given identifier scheme.
• Location. The Location class (dct:Location) is used to identify a geographical region or place. It can be represented using a controlled vocabulary or through the expression of geographical coordinates that delimit a specific area.
• Period of Time. The Validity or Temporal Period class (dct:PeriodOfTime) is used to define a time interval that is delimited by a start date and an end date.
• Checksum. The Resource Control and Verification class (spdx:Checksum) is used to specify the method that is implemented and the result obtained to guarantee the integrity of dataset distributions, that is, that their content has not been altered.
• Relationship. The Relationship between resources class (dcat:Relationship) is used to specify additional information relating to a relationship between resources or agents, providing contextualization about how said resources are interrelated.

Namespaces Used in the Model#

Each property of a class that describes some attribute of the elements of the catalog, catalog record, data service, dataset, distribution, etc., reuses terms from other existing vocabularies. They are specified by a URI determined by the composition of the prefix of the corresponding vocabulary referenced in the namespace of the DCAT-AP-ES model and the name of the class or property. For example, the dct:issued property of the Catalog class is expressed equivalently in its abbreviated and extended form as follows:

The generic vocabularies that make up the namespace reused in the implementation of the DCAT-AP-ES model are listed below:

Controlled Vocabularies Used in the Model#

To ensure consistency and interoperability among data catalogs, DCAT-AP-ES recommends the use of controlled vocabularies for each property. The following table shows the recommended vocabularies, their relationship with the entities explicitly described in the profile, and the corresponding URIs, whose use may be mandatory in some cases according to the model specifications.

DCAT-AP-ES Model Metadata List#

In the DCAT-AP-ES model metadata tables, the following information is specified:

• Metadata: Descriptive name of the metadata element
• Description: Brief explanation of the metadata's function and purpose
• Property: Formal identifier of the metadata in URI form (e.g., dct:title)
• T (Applicability): Type of metadata requirement, if different for high-value datasets (HVD) it is indicated. Types can be:
  • Ob (Mandatory): The publisher must provide this property's information, and the consumer must be able to process it.
  • R (Recommended): The publisher should provide this information if available, the consumer must be able to process it.
  • Op (Optional): The publisher may provide this information, the consumer must be able to process it.
• C (Cardinality): Indicates the minimum and maximum number of occurrences allowed, if different for high-value datasets (HVD) it is indicated. For example, 1..n means at least one, potentially many.
• Range: Data type or class that the metadata value can take, including:
  • Main type: For example, rdfs:Literal, foaf:Agent or dcat:Dataset
  • Additional description: Information about the expected format or structure for the value.

This uniform structure facilitates the implementation and understanding of the DCAT-AP-ES application profile.

Likewise, the application requirement is indicated for each entity of the model - catalog, record, data service, dataset, etc.

Catalog - Class: dcat:Catalog - Mandatory#

Catalog Record - Class: dcat:CatalogRecord - Optional#

Data Service - Class: dcat:DataService - Optional#

Dataset - Class: dcat:Dataset - Mandatory#

Distribution - Class: dcat:Distribution - Recommended#

Agent - Class: foaf:Agent - Mandatory#

Identifier - Class: adms:Identifier - Optional#

Location - Class: dct:Location - Optional#

Period of Time - Class: dct:PeriodOfTime - Optional#

Checksum - Class: spdx:Checksum - Optional#

Relationship - Class: dcat:Relationship - Optional#

Conformance#

DCAT-AP#

SEMIC Guidelines for Publishing DCAT-AP Profiles (DCAT-AP reuse guidelines)#

The DCAT-AP-ES profile has been evaluated against the official SEMIC guidelines for creating DCAT-AP profiles ("How to create your DCAT-AP profile"). The analysis concludes approximately 94% overall conformity, with 3 non-critical actions focused on governance and formal publication of LOD vocabularies. The profile is based on DCAT-AP 2.1.1 and aligns with the main restrictions effectively.

Detailed Results#

Annex 1. Changes in the DCAT-AP-ES model compared to the NTI-RISP (2013) model#

The following details the relationship of changes and updates in the metadata of the DCAT-AP-ES model with respect to the NTI-RISP (2013) metadata model, as well as the relationship of metadata that have been deprecated.

Metadata incorporated into the DCAT-AP-ES model#

Indicated in parentheses is whether the metadata was defined in NTI-RISP or has been incorporated from the DCAT-AP-ES specification:

Obsolete elements from NTI-RISP (2013)#

The following indicates the names of the metadata and properties described in the previous NTI-RISP (2013) model that are obsolete or have changed in DCAT-AP-ES:

• In the Catalog class (dcat:Catalog):
  • Catalog size (dct:extent)
  • Identifier (dct:identifier)

• In the Dataset class (dcat:Dataset):
  • Conditions of use ( dct:license) [1]
  • Resource validity: (dct:valid)
  • Related resources (dct:references)

• In the Distribution class (dcat:Distribution):
  • Additional information about the format (dct:relation) [2]
  • Identifier (dct:identifier)
  • Format (dcat:mediaType) [3]

[1] The dct:license property disappears from the Dataset class and is incorporated into the Distribution class.

[2] The dct:relation property disappears from the Distribution class and is incorporated into the Dataset class, although with a different function than described in NTI-RISP (2013). In this metadata model it is used to specify resources that are somehow related to the dataset.

[3] In DCAT-AP-ES the format property is divided into several, more specifically the property "Format" (dct:format) is added and distinguished from "MIME type format" (dcat:mediaType, which was "Format" in the previous model). The latter in DCAT 2 has as range the more specific class dct:MediaType, instead of the more general dct:MediaTypeOrExtent (which is used in dct:format). This means that the "MIME type format" property (dcat:mediaType) is restricted to be used only with values that are instances of dct:MediaType (IANA media types), excluding other types of nodes that could have been allowed with dct:MediaTypeOrExtent.

Annex 2. DCAT-AP-ES Quick Reference Guide#

The following list includes, alongside the HVD acronym, the properties that are mandatory, recommended or optional and are relevant for the publication of high-value data.

Annex 3. Comparison between DCAT-AP-ES and DCAT-AP#

DCAT-AP-ES is based on DCAT-AP 2.1.1 with the incorporation of elements from the DCAT-AP HVD 2.2.0 extension. Below are the additional specifications that the Spanish model includes with respect to the European versions.

The additional specifications are shown in the following comparative tables, where the header indicates:

• Entity: Class or element of the model (for example, Catalog, Dataset, Distribution, etc.).
• Metadata: Name of the metadata or property.
• Property: Formal name of the property (for example, dct:title).
• T (Applicability): Type of obligation in DCAT-AP-ES (Mandatory, Recommended, Optional).
• DCAT-AP T: Type of obligation in the DCAT-AP profile.
• C (Cardinality): Cardinality in DCAT-AP-ES.
• DCAT-AP C: Cardinality in the DCAT-AP profile.
• Observations: Comments on the change or main difference.

DCAT-AP 2.1.1#

Summary#

Full Detail#

DCAT-AP 3.0.0#

Extensions#

The Extensions section describes how the DCAT-AP-ES model is adapted and extended to meet the specific needs of the Spanish context, incorporating additional requirements such as those relating to high-value datasets (HVD).

DCAT-AP HVD 2.2.0#

Distinctive Features of DCAT-AP-ES#

This annex presents a consolidated view of the additional specificities between DCAT-AP-ES and the European DCAT-AP profiles (versions 2.1.1 and 3.0.0), facilitating understanding of the particularities of the Spanish profile and its specific implementation requirements.

1. Adaptation to the Spanish Context#

• Mandatory use of national taxonomies: DCAT-AP-ES requires the use of the primary sectors taxonomy for thematic classification
• Linguistic requirement: At least one of the languages must be Spanish in multilingual properties
• Organizational identifier normalization: Defines standardized URIs with DIR3 format for public bodies (http://datos.gob.es/recurso/sector-publico/org/Organismo/{ID})

2. Greater Obligation in Metadata#

• DCAT-AP-ES raises numerous properties from Recommended to Mandatory, especially in dcat:Catalog, dcat:Dataset and dcat:DataService
• Defines obligation for key properties such as dct:publisher, dcat:theme and creation/update dates
• Adopts a stricter approach to ensure metadata completeness and interoperability

3. Comprehensive Support for High-Value Data (HVD)#

• Integrates specific requirements for high-value data according to Commission Implementing Regulation (EU) 2023/138
• Defines additional mandatory properties for HVD datasets (dcatap:hvdCategory, dcat:distribution)
• Incorporates dcatap:applicableLegislation as mandatory for HVD distributions

4. Evolution from European Profiles#

• Selectively incorporates DCAT-AP properties such as the mentioned dcatap:applicableLegislation, dcatap:availability and dcatap:hvdCategory
• Updates controlled vocabularies (e.g., for adms:status in dcat:Distribution)

5. Adapted Cardinalities#

• Defines more restrictive cardinalities for greater precision (e.g., dct:publisher requires cardinality 1..1)
• Limits spatial and temporal resolutions to a single instance (0..1)
• Restricts dcat:themeTaxonomy to maximum 3 taxonomies, mandatorily including the Spanish one

6. Aligned with the Legal Data Framework#

• DCAT-AP-ES is an evolution of the NTI-RISP metadata model and the Application Guide that contains it. Therefore, it implements requirements according to Spanish open data regulations (Law 37/2007, of November 16, on the reuse of public sector information and Resolution of February 19, 2013, of the Secretary of State for Public Administrations, approving the Technical Interoperability Standard for Information Resources Reuse).
• Adapts to the ecosystem of related and interconnected specifications (DCAT-AP) in the context of data policies Directive (EU) 2019/1024, interoperability (SEMIC) and infrastructure (EDP) of the European Commission.

Change History#

This section provides an overview of the changes incorporated in DCAT-AP-ES. A complete list of issues closed with this version is accessible at GitHub.

DCAT-AP-ES 1.0.0#

Main Changes#

• Transformation of technical documentation into HTML representation (RESPEC style using MkDocs + Material for MkDocs)
• Integration of updated guidelines and texts related to DCAT-AP-ES
• Update and improvement of cross-references to facilitate navigation
• Correction of numerous typographical errors and conversion issues

Adaptations to Different Sections#

• Introduction: Review to reflect the current context and profile foundations
• Conformance: Update to reflect implementation requirements in the Spanish ecosystem
• Terminology: Updated prefix list with the most recent vocabularies
• Data model: Reorganized structure to improve readability
• Controlled vocabularies: Update of references to authorized vocabularies
• High-Value Datasets (HVD): Full integration of requirements from Implementing Regulation (EU) 2023/138
• Quick reference annex: Automatic generation from the data model to maintain synchronization

Changes Compared to NTI-RISP#

• Complete update of classes and properties according to DCAT-AP
• Removal of obsolete properties and replacement with more appropriate alternatives
• Restructuring to adapt to new requirements of Directive (EU) 2019/1024
• Implementation of specific metadata for High-Value Datasets (HVD)
• Expansion of capabilities to describe data services (APIs and endpoints)

Additional Specifications with DCAT-AP#

• Higher level of obligation in key properties to ensure metadata quality
• Adaptation to the Spanish regulatory framework and its specific requirements
• More restrictive cardinalities to ensure uniformity and precision
• Specific linguistic requirements of the Spanish multilingual context
• Integration with Spanish public body identification systems (DIR3)

Data Model Adaptations#

The following list indicates the additional specifications compared to the previous version (NTI-RISP). It also includes the impact of alignment with the W3C recommendation: DCAT and the European DCAT-AP profile.

• Division of existing descriptive texts into definitions and usage notes following SEMIC best practices
• Alignment with DCAT-AP 2.1.1 and selective adoption of DCAT-AP 3.0.0 elements
• Organization of the profile into main entities, supporting entities, and data types
• Elevation of numerous properties to mandatory to ensure interoperability
• Incorporation of specific aspects for High-Value Data (HVD)
• Adaptation to linguistic requirements and territorial classification of Spain

Specific Requirements for the Spanish Context#

• National taxonomies: Mandatory implementation of the Spanish primary sectors taxonomy
• Linguistic requirement: Spanish mandatory as one of the languages in multilingual properties
• Standardized identifiers: Adoption of the DIR3 scheme for public body identification
• Includes the publisher (dct:publisher) in main entities to trace resource ownership.

Alignment with HVD (High-Value Data)#

• Full integration of the requirements of Implementing Regulation (EU) 2023/138
• Clear definition of additional mandatory properties for HVD datasets
• Incorporation of metadata for traceability and regulatory compliance (applicable legislation, HVD categories)

SHACL and Validation#

• Development of SHACL rules for automatic profile validation
• Inclusion of unique identifiers for each constraint
• Implementation of tests to verify conformance with the profile

Error Corrections#

• Alignment of properties with their definition in original vocabularies
• Correction of cardinalities to reflect specific requirements of the Spanish context
• Improvement of descriptions and usage notes to facilitate correct implementation
• Adjustments to controlled vocabulary references to ensure their availability and persistence