⚠️ DEPRECATED: This version of the specification (Release 5) is deprecated. Please refer to the latest version.
Abstract
The HealthDCAT Application Profile (HealthDCAT-AP) is a domain-specific metadata model designed to support the implementation of the secondary use framework under the European Health Data Space (EHDS).
HealthDCAT-AP introduces new properties that enable semantically consistent dataset descriptions, structured for automated exchange and federation across catalogues. This ensures that metadata can be processed and integrated into local, regional, national and EU-level catalogues, including the one operated by the central platform of the HealthData@EU infrastructure.
A distinctive feature of HealthDCAT-AP is its explicit classification of dataset access rights into three categories: non-public, restricted, and public. Each category is defined with specific technical requirements.
In addition, new controlled vocabularies have been developed to harmonise property values, thereby ensuring comparability and interoperability of dataset descriptions across Member States.
Introduction
Context
The Health extension of DCAT-AP is being developped by the European Commission DG SANTE to fulfil the requirements of Article 77 of Regulation (EU) 2025/327 [[OJ L, 2025/327, 5.3.2025]] establishing the European Health Data Space (EHDS).
Article 77(requires Health Data Access Bodies (HDABs) to publish public catalogues describing the datasets they are responsible for, under the secondary use framework including their content, holders, and access conditions. These catalogues are a core component of the EHDS infrastructure: they are intended to inform potential data users about what data exists, who holds it, and under what terms it may be accessed for secondary use.
The purpose of HealthDCAT-AP is to ensure that datasets made available for secondary use are described in a clear, consistent and comparable manner across the Union.
This harmonisation is essential to:
Guarantee transparency and legal certainty for health data holders;
Avoid fragmentation in the way dataset information is presented across Member States;
Enable the federation of national catalogues into the EU dataset catalogue operated by the HealthData@EU infrastructure;
Improve the cross-border discoverability, findabilityand interoperability of health datasets.
Scope of HealthDCAT-AP in Release 5
Health DCAT-AP is developed by the European Commission DG SANTE in successive iterations. The DG SANTE implementation can be accessed in the HealthData@EU Central Platform, where a dedicated database was developed to store, display, search, and filter Health DCAT-AP-compliant datasets. Ccompliance of the datasets is assured through the microservice – HealthData@EU Validator (a customised implementation of the Interoperability Test Bed).
Additionally, the below tools are available for the users, to facilitate their work with HealthDCAt-AP:
Dataset Descriptions Assistant - which is a user interface designed to assist data holders in creating structured dataset descriptions aligned with the HealthDCAT-AP specification. It provides a dynamic, user-friendly form that promotes metadata quality, consistency, and compliance, while adapting to the dataset's Access Rights.
Metadata Model Explorer - which is an implementation support tool designed to help users apply the HealthDCAT-AP specification. It presents, through a user-friendly interface, the metadata elements used to describe datasets intended for secondary use of electronic health data in the European Union. For each element, it displays definitions, cardinalities, usage notes and RDF examples, enabling consistent implementation across Member States.
Scope of the Application Profile : Enhancing DCAT-AP for the secondary use of health data
The HealthDCAT-AP designed as an extension of the DCAT-AP incorporates its principal classes such as dcat:Catalog, dcat:CatalogRecord, dcat:Dataset, dcat:Distribution, and dcat:DataService.
This extension leverages RDF's flexible architecture to enhance metadata capabilities without compromising the stability of existing or under-development catalog systems. By integrating new metadata elements as triples, the extension enriches the metadata model without altering established structures.
To ensure interoperability, the extension adheres to several principles:
It meets the minimal conformance criteria of DCAT-AP.
Newly introduced classes and properties must not replicate the functionality of existing DCAT-AP components.
It incorporates mandatory controlled vocabularies from DCAT-AP and may introduce additional vocabularies.
Modifications to property cardinalities are allowed under the following conditions:
- Mandatory properties retain their required status.
- Recommended properties may be classified as optional or mandatory.
- Optional properties can be made mandatory
- Recommended and optional properties may be removed based on the extension's specific needs.
To effectively extend DCAT-AP, several best practices are recommended:
Reviewing and potentially integrating metadata properties from related extensions such as StatDCAT-AP for statistical data and GeoDCAT-AP for geospatial data.
Prioritising vocabularies used in DCAT-AP for metadata property selection, with key vocabularies such as Dublin Core-DCMI Metadata Terms, Asset Description Metadata Schema (ADMS), PROV-O: The PROV Ontology, ODRL Information Model, as well as considering Data Privacy Vocabulary (DPV), Schema.org, and Data Quality Vocabulary (DQV).
Using EU-controlled vocabularies maintained by the Publications Office to define metadata property values, which should be:
- Openly licensed.
- Managed by a reputable institution.
- Well-documented.
- Multi-lingual, ideally covering all official EU languages.
- Comprising a manageable number of terms to facilitate broad resource classification.
- Identified by URIs, with each URI directing to detailed documentation about the term.
- Supported by clear persistence and versioning policies.
This structured approach to developing HealthDCAT-AP ensures that the metadata model is enhanced while maintaining interoperability and compliance with established standards, thereby supporting a more interconnected and accessible digital health ecosystem.
The development of the HealthDCAT extension is an ongoing iterative process that will extend beyond the pilot project, incorporating continuous feedback and contributions from the stakeholder community. This document specifies a first iteration of the HealthDCAT-AP extension, a customised adaptation of the EU DCAT Application Profile. It adapts the DCAT data model specifically for health-related catalogued resources, in alignment with the Regulation on the European Health Data Space [[OJ L, 2025/327, 5.3.2025]]. This customisation facilitates the management and dissemination of health data within the regulatory framework, enhancing its accessibility and utility for health data users.
For applications to comply with HealthDCAT-AP, they MUST first conform to DCAT-AP. Additionally, these applications MUST adhere to the specified constraints and usage guidelines, following conformance statements similar to those outlined in DCAT-AP.
Provider requirements
In order to conform to this Application Profile, an application that provides metadata MUST:
Provide a description of the Catalogue, including at least the mandatory properties specified for the class Catalogue.
Provide descriptions of Datasets in the Catalogue, including at least the mandatory properties for the class Dataset.
Provide descriptions of Distributions of Datasets in the Catalogue, including at least, for health data with non public access level, a distribution for the Health Data Access Body responsible for providing access to health data and including at least the mandatory properties for the class Distribution.
Provide descriptions of all other classes such as Agents, Contact Points, Access Rights, etc.
The application of the controlled vocabularies as described in section [[[#controlled-vocs]]].
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
personal electronic health data means data concerning health and genetic data, processed in an electronic form; [[OJ L, 2025/327, 5.3.2025 Art.2.2(a)]]
non-personal electronic health data means electronic health data other than personal electronic health data, including both data that have been anonymised so that they no longer relate to an identified or identifiable natural person (the 'data subject') and data that have never related to a data subject; [[OJ L, 2025/327, 5.3.2025 Art.2.2(b)]]
health data holder means any natural or legal person, public authority, agency or other body in the healthcare or the care sectors, including reimbursement services where necessary, as well as any natural or legal person developing products or services intended for the health, healthcare or care sectors, developing or manufacturing wellness applications, performing research in relation to the healthcare or care sectors or acting as a mortality registry, as well as any Union institution, body, office or agency, that has either:
(i) the right or obligation, in accordance with applicable Union or national law and in its capacity as a controller or joint controller, to process personal electronic health data for the provision of healthcare or care or for the purposes of public health, reimbursement, research, innovation, policymaking, official statistics or patient safety or for regulatory purposes; or
(ii) the ability to make available non-personal electronic health data through the control of the technical design of a product and related services, including by registering, providing, restricting access to or exchanging such data; [[OJ L, 2025/327, 5.3.2025 Art.2.2(t)]]
Health Data Access Body Bodies that are responsible for processing the health data applications and granting access to electronic health data for secondary use if the application is accepted.
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.
Application refers to the usage context of the specification. It may be abstract, for instance covering a data theme such as mobility data, but also it may refer to specific tools like open data portals.
For DCAT-AP the usage scope is broad and in the first place taking into account the European legal context.
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
Prefix
Namespace IRI
adms
http://www.w3.org/ns/adms#
csvw
http://www.w3.org/ns/csvw#
dcat
http://www.w3.org/ns/dcat#
dcatap
http://data.europa.eu/r5r/
dct
http://purl.org/dc/terms/
dctype
http://purl.org/dc/dcmitype/
dpv
https://w3id.org/dpv#
dqv
http://www.w3.org/ns/dqv#
foaf
http://xmlns.com/foaf/0.1/
healthdcatap
http://healthdataportal.eu/ns/health#
locn
http://www.w3.org/ns/locn#
odrl
http://www.w3.org/ns/odrl/2/
owl
http://www.w3.org/2002/07/owl#
prov
http://www.w3.org/ns/prov#
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs
http://www.w3.org/2000/01/rdf-schema#
skos
http://www.w3.org/2004/02/skos/core#
spdx
http://spdx.org/rdf/terms#
time
http://www.w3.org/2006/time#
vcard
http://www.w3.org/2006/vcard/ns#
xsd
http://www.w3.org/2001/XMLSchema#
Overview
HealthDCAT-AP is an extension of DCAT-AP.
This application profile is meant to provide a DCAT-AP-conformant representation of metadata specific to health datasets in scope of the EHDS Regulation [[OJ L, 2025/327, 5.3.2025]].
HealthDCAT-AP extends DCAT-AP by including:
additional classes and properties;
additional recommendations on the use of classes and properties;
additional controlled vocabularies.
HealthDCAT Application profile diagram
An overview of HealthDCAT-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:
No ranges for data properties are shown, because some of them are expressed as unions of XSD types
The figure contain the key classes with some important supporting classes. Other object properties (relationships) are listed as properties on the UML class with their target range.
The class dcat:Resource has been included to ease to see the connection with W3C DCAT. DCAT-AP treats it as an abstract notion.
The cardinalities and qualifications are included in the figure.
HealthDCAT-AP UML Class Diagram for Non-public Health Data Access Level
The following diagram illustrates the HealthDCAT-AP extension to DCAT-AP 3.0, specifically designed for non-public health data access levels within the European Health Data Space framework.
HealthDCAT-AP UML Class Diagram for Non-public Health Data Access Level
HealthDCAT-AP UML Class Diagram for Restricted Health Data Access Level
The following diagram illustrates the HealthDCAT-AP extension to DCAT-AP 3.0, specifically designed for restricted health data access levels.
HealthDCAT-AP UML Class Diagram for Restricted Health Data Access Level
HealthDCAT-AP UML Class Diagram for Public Health Data Access Level
The following diagram illustrates the HealthDCAT-AP extension to DCAT-AP 3.0, specifically designed for public health data access levels.
HealthDCAT-AP UML Class Diagram for Public Health Data Access Level
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 :
A: reused as-is defined and expressed in DCAT-AP
E: reused with additional usage notes or additional restrictions compared to DCAT-AP
P: HealthDCAT-AP profile specific extension where DCAT-AP had no requirements earlier on specified
This reuse qualification assessement is with respect to a specific version of HealthDCAT-AP.
Therefore it may vary over time when new versions of HealthDCAT-AP are created.
Health Data Access Body supporting access to data in the Member State.
Usage Note
Health Data Access Body Bodies that are responsible for processing the health data applications and granting access to electronic health data for secondary use if the application is accepted. contant point is mandatory.
Contact information that can be used to contact the Agent.
This property points to a contact point (Individual, Organization, Location, Group) that can answer questions about the dataset. Details on how to describe these are provided under class vcard:Kind.
Agent responsible for making the health data resource available.
Usage Note
A Publisher is generally the agent responsible for making the health data resource available to the research and development community for use within applicable legal frameworks. It may be the health data holder or the organisation facilitating access on behalf of the data holder. In the EHDS context, this includes health data holders who directly publish data, intermediary organisations that facilitate access, and designated authorities like Health Data Access Bodies (HDABs) that manage access permissions and data distribution.
This property indicates the category of the publisher, such as governmental body, academic institution, healthcare provider, or data intermediary.
The NAL Health Publisher Types (EHDS) must be used.
Indicates whether the Publisher is recognized as a trusted data holder under relevant health data governance frameworks.
This property specifies if the publisher has been formally designated or certified as a trusted entity for handling and distributing health data under applicable regulatory frameworks.
The legislation that mandates the creation or management of the Catalogue.
The legislation that mandates the creation or management of the Catalogue.
The ELI of the EHDS was published in March 2025 and can now be included as the applicable legislation, value ofr EHDS Regulation (http://data.europa.eu/eli/reg/2025/327/oj) if applicable
As multiple legislations may apply to the resource the maximum cardinality is not limited.
A catalogue whose contents are of interest in the context of this catalogue.
For certain research projects, multiple catalogs may need to be organized in a nested manner. This property serves to connect the different catalogs with each other.
Each catalog contains one or more datasets. This property serves to link datasets to a catalogue. Therefore, a dataset is always contained inside a catalogue.
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.
A related Catalogue that is part of the described Catalogue.
Use this property to establish another catalogue in this catalogue.
A related resource that is included either physically or logically in the described resource.
A statement that specifies rights associated with the Catalogue.
A statement that concerns all rights not addressed in fields License or Rights, such as copyright statements. Everything that is not covered with licence.
A site or end-point (Data Service) that is listed in the Catalogue.
Some datasets may have real-time Data Services (e.g., Beacon API counting individuals). IT teams should define the relationship between the catalog and the Data Service via this property.
The start and end date of the period that the catalogue covers.
This property makes use of a Period of Time class.
This property makes use of the class dct:PeriodOfTime (more details on PeriodOfTime class tab ).
The start and end of the interval SHOULD be given by using properties dcat:startDate or time:hasBeginning, and dcat:endDate or time:hasEnd, respectively.
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 mandatory controlled vocabulary for dcat:theme.
The status of the catalogue record in the context of editorial flow of the dataset and data service descriptions.
This property indicates the current status of the catalogue record as part of the editorial workflow governing the management and curation of dataset and data service descriptions. It may reflect stages such as "draft", "under review", "published", "deprecated", or "archived".
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 intent with this range to require the explicit use of the class Catalogued Record. As abstract class, an subclass should be used.
The legislation that mandates the creation or management of the Data Service.
The legislation that mandates the creation or management of the Daistribution.
The ELI of the EHDS was published in March 2025 and can now be included as the applicable legislation, the value must include the ELI of the EHDS Regulation (http://data.europa.eu/eli/reg/2025/327/oj) if applicable.
As multiple legislations may apply to the resource the maximum cardinality is not limited.
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.
Contact information that can be used for sending comments about the Data Service.
This property informs about a contact point (Individual, Organization, Location, Group) that can answer questions about the DataService. Details on how to describe these are provided under class vcard:Kind.
Provide specific details about the data service series here, complementing the description of the related Dataset.
This field can be repeated for different language versions of the description.
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 dct:conformsTo is used to indicate the general standard or specification that the endpoints implement.
Provides technical documentation that explains how to access and interact with the data service's endpoint.
The root location or primary endpoint of the service (an IRI).
Provide the URL of the endpoint that users can interact with to access the data service. This should be a direct link to the service's endpoint, such as an API URL, SPARQL endpoint, or similar.
The structure that can be returned by querying the endpointURL.
This property can be used to describe a media format in more detail than "media type" when needed. Instances of this property should use a value from the file type NAL
An entity (organisation) responsible for making the Data Service available.
The organization or individual responsible for making the data service available. In the context of data services, the publisher is typically the organization that manages or provides access to the service. For details, see the class Agent.
This property refers to a collection of data that this data service can distribute.
This property connects the Data Service class to its corresponding dataset(s), ensuring every data service links to at least one dcat:Dataset. While essential for metadata implementation teams on each node.
This property may use a controlled vocabulary. In the Health Data Catalogue, any entry from the controlled vocabulary can be used to describe the theme of the DataService.
example: 'HEAL' (http://publications.europa.eu/resource/authority/data-theme/HEAL) . for a DataService which has the Health theme.
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]]].
The health category to which this dataset belongs as described in the Commission Regulation on the European Health Data Space laying down a list of categories of electronic data for secondary use, Art.51.
A mandatory controlled vocabulary denoting health data within the scope of the Commission Regulation is provided.
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).
The legislation that mandates the creation or management of the Dataset Series.
The legislation that mandates the creation or management of the Dataset Series.
The ELI of the EHDS was published in March 2025 and can now be included as the applicable legislation, value ofr EHDS Regulation (http://data.europa.eu/eli/reg/2025/327/oj) if applicable
As multiple legislations may apply to the resource the maximum cardinality is not limited.
Contact information that can be used for sending comments about the Dataset Series.
This property informs about a contact point (Individual, Organization, Location, Group) that can answer questions about the Dataset Series. Details on how to describe these are provided under class vcard:Kind.
This property can be repeated for parallel language versions.
It is recommended to provide an indication about the dimensions the Dataset Series evolves.
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.
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.
The values must be data typed as either xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth
Example: 2023-12-10T13:16:10.246Z.
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.
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.
The values must be data typed as either xsd:date, xsd:dateTime, xsd:gYear or xsd:gYearMonth
Example: 2023-12-10T13:16:10.246Z.
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.
The legislation that mandates the creation or management of the Distribution.
Reference the specific legal instruments that require or govern the creation, management, and provision of this distribution, particularly the European Health Data Space Regulation.
Provide detailed information about the distribution's content, format characteristics, intended use cases, and any special considerations for health data usage.
A licence under which the Distribution is made available.
Reference the legal terms and conditions governing access, use, and redistribution of this distribution, ensuring compliance with health data regulations.
An established schema to which the described Distribution conforms.
Reference technical standards, data models, or schema specifications (e.g., HL7 FHIR, OMOP CDM) that define the structure and semantics of this distribution.
The media type of the Distribution as defined in the official register of media types managed by IANA.
Specify the precise IANA media type (e.g., application/json, text/csv, application/fhir+json) to enable proper content handling by consuming applications.
The status of the distribution in the context of maturity lifecycle.
Indicate the lifecycle stage using controlled vocabulary (Completed, Deprecated, Under Development, Withdrawn) to inform users about distribution reliability and future availability.
Provide a descriptive name that clearly identifies this specific distribution format, version, or subset to distinguish it from other distributions of the same dataset.
Note that the class Kind is the parent class for the four explicit types of vCard (Individual, Organization, Location, Group).
It is mandatory to provide at least either an email or a contact form from e.g. a service desk.
Properties
For this entity the following properties are defined: contact page
, email
A webpage that either allows to make contact (i.e. a webform) or the information contains how to get into contact.
It is recommended to provide at least either an email or a contact form from e.g. a service desk.
A webpage that either allows to make contact (i.e. a webform) or the information contains how to get into contact.
It is recommended to provide at least either an email or a contact form from e.g. a service desk.
When naming a contact point this information needs to be further specified with additional information, i.e., an email address. This email address does not need to be a direct contact to the person responsible for the management of the data, it could be a generic information email.
The email address has to be provided starting with mailto: prefix.
For example: mailto:info@example.com / mailto: jane.doe@example.com
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
.
The CSVW (CSV on the Web) specification provides a framework for describing tabular data and its metadata. In the context of HealthDCAT-AP, CSVW is used to define variable dictionaries that describe the structure and meaning of synthetic, anonymized health data samples.
This specification defines the dictionary of variables that will be linked via the dcat:downloadURL of the sample distribution. The download URL provides a synthetic, anonymized example of the real data, and the dictionary describes the variables used in that example. The CSVW vocabulary enables detailed documentation of each variable including its technical name, human-readable title, description, datatype, and semantic relationships.
The following three entities work together to provide comprehensive variable documentation:
Table Group - The top-level container that organizes one or more CSV tables
Table - Represents a single CSV file with its metadata and variable definitions
Column - Describes individual variables (columns) within the CSV file
This specification defines the dictionary of variables that will be linked via the dcat:downloadURL of the sample distribution. The download URL provides a synthetic, anonymized example of the real data, and the dictionary describes the variables used in that example.
Variable (column) defines metadata about one field in the CSV file.
Each variable (column) node defines characteristics such as name, title, datatype, etc., for one column of the CSV. Should be either a blank node or IRI referring to a csvw:Column.
A Technical name given to the Variable as it appears in the CSV file.
Technical variable name required to match a column header in the CSV file (synthetic, anonymized representation of the real data), can appear in multiple languages.
Used to provide human-readable information about the variable (column). Can appear in multiple languages. This is especially helpful for variable documentation.
Specifies the expected datatype of the values in the column.
Should match the label of one of the CSVW types as defined in the Built-in datatypes from XML Schema. https://w3c.github.io/csvw/metadata/#datatypes Example: string, integer, boolean ...
A URI template used to define the RDF predicate associated with the values in the column, relative to each row.
The propertyUrl may point to standard, controlled vocabularies, or ontologies that define the semantic meaning of the column. For example: csvw:propertyUrl <http://publications.europa.eu/resource/authority/country> For advanced usage, refer to the official specification: https://www.w3.org/TR/tabular-metadata/#propertyurl
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.
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.
In HealthDCAT-AP, a Concept is used to denote codes within a codelist. In section [[[#controlled-vocs]]] the expectations are elaborated in more detail.
Properties
For this entity the following properties are defined: preferred label
.
In HealthDCAT-AP, a Concept Scheme is used to denote a codelist. In [[[#controlled-vocs]]]. Controlled Vocabularies the expectations are elaborated in more detail. the user must provide either : dct:title, rdfs:label or skos:prefLabel.
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.
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.
Legal basis used to justify processing of data or use of technology in accordance with a law.
Usage Note
Legal basis (plural: legal bases) are defined by legislations and regulations, whose applicability is usually restricted to specific jurisdictions which can be represented using dpv:hasJurisdiction or dpv:hasLaw. Legal basis can be used without such declarations, e.g. 'Consent', however their interpretation will require association with a law, e.g. 'EU GDPR'.
Properties
This specification does not impose any additional requirements to properties for this entity.
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.
Data directly or indirectly associated or related to an individual.
Usage Note
This definition of personal data encompasses the concepts used in GDPR Art.4-1 for 'personal data' and ISO/IEC 2700 for 'personally identifiable information (PII)'.
Properties
This specification does not impose any additional requirements to properties for this entity.
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.
This class represents the Purpose or Goal of processing data or using technology.
Usage Note
The purpose or goal here is intended to sufficiently describe the intention or objective of why the data or technology is being used, and should be broader than mere technical descriptions of achieving a capability. For example, "Analyse Data" is an abstract purpose with no indication of what the analyses is for as compared to a purpose such as "Marketing" or "Service Provision" which provide clarity and comprehension of the 'purpose' and can be enhanced with additional descriptions.
Properties
This specification does not impose any additional requirements to properties for this entity.
An annotation that associates a resource (especially, a dataset or a distribution) to another resource (for example, a document) that certifies the resource's quality according to a set of quality assessment rules.
Usage Note
Instances of this class are annotations pointing to quality certificates.
Properties
This specification does not impose any additional requirements to properties for this entity.
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.
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).
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.
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.
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:
Be published under an open licence.
Be operated and/or maintained by an institution of the European Union, by a recognised standards organisation or another trusted organisation.
Be properly documented.
Have labels in multiple languages, ideally in all official languages of the European Union.
Contain a relatively small number of terms (e.g. 10-25) that are general enough to enable a wide range of resources to be classified.
Have terms that are identified by URIs with each URI resolving to documentation about the term.
Have associated persistence and versioning policies.
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.
Expected usage of controlled vocabularies
To increase the interoperability, the value spaces of properties can be further harmonised using shared controlled vocabularies.
This kind of restriction may be subject to a varying interpretation on what the expected usage of a controlled vocabulary is.
To ensure a common interpretation the following expectations are defined:
The property MUST use as range values codes from {codelist}
This expectation results in that the value space is closed under the codelist.
Validation systems SHOULD produce errors.
All profiles in the ecosystem MUST avoid conflicts by creating subproperties.
The property MUST have at least one value from {codelist}
This expectation makes the value space minimally constrained.
Validation systems SHOULD produce warnings.
All profiles in the ecosystem MUST adopt this interpretation in case they want to restrict the value space.
Adopting the former expectation will lead to cross-profile interpretations challenges.
The property IS RECOMMENDED to use as range values codes from {codelist}
The value space is closed under the codelist, but other values are tolerated.
Recommending means expressing a strong preference.
To make this stronger direction towards harmonisation visible in the data exchanges, validation systems SHOULD produce warnings.
The property MAY use as range values codes from {codelist}
The value space is closed under the codelist, but other values are accepted.
This expectation is more a hint to be used.
As there is no obligation nor strongly suggestion expressed here, the use of other codelists is valid is all cases.
Therefore validation systems MAY produce warnings but users are free to ignore them.
No validation in this case is also acceptable.
The first two (and preferably also the others) SHOULD only be used for requirements that can be verified by a machine.
If the validation can only be realised with the involvement of humans, then a less strong requirement (RECOMMMENDED or MAY) is used,
even if the intention is to be very strict.
This is to ensure that the provided SHACL representations correspond closely to all use cases possible.
Stronger enforcements are left for implementations as they have control on actual data exchange.
Controlled vocabularies to be used
The tables below show the usage of the codelists with the expected qualification.
Properties with controlled vocabularies that MUST be used for the listed properties
The list of terms for the health category to which this dataset belongs as described in the Commission Regulation on the European Health Data Space laying down a list of categories of electronic data for secondary use, Art. 51
The members listed are considered a controlled vocabulary of supported compression formats.
* For IANA media-type IRIs, SHACL enforcement is implemented via regex pattern (warning severity) due to lack of an official RDF list; the constraint remains normative “MUST”.
Properties with AT LEAST 1 value from the controlled vocabularies
The 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.
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.
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.
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.
GeoDCAT-AP has introduced a number of specific properties.
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.
As a technical note: While both approaches represent equivalent effort for publishers of datasets and editors of the specifications overall, their governance models differ.
For the first approach using direct properties, the relationship definition occurs within the profile/extension.
The governance is external for the second approach using codelists. This may lead to unwanted overhead, e.g. to manage mappings between the distinct codelists different profiles may use.
The impact between both is primary operational on querying the data catalogue. Direct properties support simple queries. Codelists necessitate complex queries, often extended with dynamic mapping logic between the external lists.
It should be noted that, even if the second 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. As long the first approach is actively be used, the second approach is thus limited for use to a profile specific context.
For that reason, it is recommended to use the direct properties including the ones defined by GeoDCAT-AP such as custodian, distributor, originator, principalInvestigator, processor, resourceProvider in favor of the second approach using the prov:qualifiedAttribution.
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:
The string is free text. Examples are descriptions and labels. Such text may be translated into several languages.
The string is an appellation of a ‘named entity’. Examples are names of organisations or persons. These names may have parallel versions in other languages but those versions don’t need to be literal translations.
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:
Datasets are the conceptual entity denoting a collection of data.
Distributions are specific representations of a dataset, described with the intent to facilitate the delivery of the data as file to a reuser. The access URL (preferably download URL) will provide a simple way to obtain (download) the content of the dataset in the representation specified by the distribution. The obtained (downloaded) content is fully determined by the publisher of the distribution. Only after obtaining the data the (re)user can change the data according to its needs.
Anything that has not the intent to provide a downloadable representation of a dataset is a data service. Data services offer smarter, more interactive ways to the data.
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:
To introduce a Dataset Series only if the publisher has the intent to manage a collection of datasets. Dataset Series with a single dataset in the collection should be avoided.
Dataset Series without a dataset in the collection should be avoided. In that case, publishers should ensure that the metadata, in particular, the life cycle metadata is up to date.
For instance, if dataset get retracted and as consequence the collection becomes empty, then publishers should consider to retract also the Dataset Series.
In case, publishers use persistent identifiers, then this should be reflected in the status of the Dataset Series.
A Dataset Series is an conceptual dataset without distributions.
When interpreting a Dataset Series as a Dataset, then it is expected that the directly associated Distributions contain the data that is the union of all Datasets in the collection.
But the presence of these Distributions raise semantical conflicts such as whether the property of the Dataset Series frequency refers to the update frequency of the associated Distributions or the update frequency of the collection. To avoid these semantical conflicts, it is recommended not to associate distributions with a Dataset Series.
The members of a Dataset Series should be described in such a way that without the knowledge of the Dataset Series, the metadata is interpreted correctly. The existence of a dataset should not be based on the membership in a Dataset Series. The interpretation of a member with its associated Distributions and Data Services is conform the above guidelines.
Whenever a Data Service is providing access to all the data of a Dataset Series, i.e. the union of all datasets in the collection of the Dataset Series,
then the Data Service may refer to the Dataset Series using serves dataset.
The ensures that whenever in the future the Dataset Series is extended with new Datasets the Data Service description does not need to be adapted.
In that case the Dataset Series should also be considered as a DCAT-AP Dataset.
Keep the usage simple. Complex nesting such as Dataset Series being a member of Dataset Series, or Dataset belonging to multiple Dataset Series are to be handled with care.
While from a data knowledge graph these nestings are feasible and not so problematic, it must be realised that these complicate the presentation on a webpage.
Since data portal representations are the main communication from metadata owners to potential data consumers and there is no clear expectations
on how to present the members of a Dataset Series in a UI (e.g. because ordering is not imposed), DCAT-AP users may not expect from other portals which harvest and process their Dataset Series, that these are more than a collection of Datasets.
Any interpretation, such as the collection is ordered, or grouped according to time or any wellknown dimension, is a specific expectation beyond the agreemenents made in DCAT-AP.
Conceptually, a Dataset Series is a special kind of Dataset. It is recommended to apply the same metadata quality of Datasets to Dataset Series (see [[[#quick-reference]]] ). The dedicated usage guidelines for Dataset Series and the Dataset members of a Dataset Series take priority over the generic DCAT-AP Dataset guidelines.
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.
Support for implementation
Implementing the DCAT-AP data specification in a data exchange between two systems raises also technical questions.
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 HealtDCAT-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 HealthDCAT-AP catalogue expressed in a RDF serialization is valid.
More on the validation and the provided SHACL shapes can be found in section [[[#validation-of-healthdcat-ap]]].
Validation of HealthDCAT-AP
Validation of datasets against HealthDCAT-AP is implemented as a two-stage approach that recognises HealthDCAT-AP as an extension of DCAT-AP.
First, each dataset is validated against the baseline DCAT-AP specification to ensure conformance by importing the DCAT-AP via owl:imports statements.
Subsequently, HealthDCAT-AP–specific constraints are applied, encompassing the Base profile checks for all levels of validation , Base, vocabularies, recommended properties, ranges.
the following SHACL templates are provided:
public-shapes.ttl: constraints concerning existence, domain and literal range, and cardinalities for health data with public access level.
restricted-shapes.ttl: constraints concerning existence, domain and literal range, and cardinalities for health data with restricted access level.
non-public-shapes.ttl: constraints concerning existence, domain and literal range, and cardinalities for health data with non-public access level.
range.ttl: constraints concerning object range common for all access levels
mdr-vocabularies.shape.ttl : constraints concerning the usage of controlled vocabularies common for all access levels.
The shapes constraint files provide for each class mentioned in HealthDCAT-AP, and having additional properties defined, a template with the corresponding constraints. Class membership constraints are not present in the shapes constraints files. These are collected in the range constraint file.
public-shapes_recommended.ttl: constraints concerning existence of recommended properties for health data with public access level.
restricted-shapes_recommended.ttl: constraints concerning existence of recommended properties for health data with restricted access level.
non-public-shapes_recommended.ttl: constraints concerning existence of recommended properties for health data with non-public access level.
In order to validate a health dataset 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.
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.
This section illustrates the HealthDCAT-AP specification with RDF examples for key properties and their usage.
Number Of Unique Individuals (healthdcatap:numberOfUniqueIndividuals)
Population Coverage (healthdcatap:populationCoverage)
Retention Period (healthdcatap:retentionPeriod)
Qualified Attribution (prov:qualifiedAttribution)
Was Generated By (prov:wasGeneratedBy)
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.
dct:hasVersion is replaced by dcat:hasVersion.
dct:isVersionOf is replaced by dcat:isVersionOf.
owl:versionInfo is replaced by dcat:version.
Acknowledgments
The current version of HealthDCAT-AP was prepared by the European Commission.
It builds upon the work developed by Sciensano [BE] - Pascal Derycke and the Norwegian Directorate of Health – Helsedirektoratet [NO] - Truls Korsgaard - under the EHDS2 Pilot project (EU4H-2021-PJ2 Project 101079839).
We gratefully acknowledge the contributions made to this document by all members of the EHDS2 Pilot working group & SEMIC.
