Application profiles¶
Besides the base profiles there are other profiles included to support other domain specific application profiles.
Note
If you are interested in contributing a profile that might be useful for the wider community check the documentation on writing custom profiles and the contribution guidelines.
HealthDCAT-AP¶
Introduction¶
This extension contains a profile (euro_health_dcat_ap
) for the proposed
HealthDCAT-AP specification.
This is a health-related extension of the DCAT application profile for sharing information about
Catalogues containing Datasets and Data Services descriptions in Europe (DCAT-AP).
The development of a Health DCAT application profile aims to standardize health metadata within the scope of the European Health Data Space (EHDS), fostering greater interoperability, findability and accessibility of electronic health data across the EU.
The goal of this profile is to provide the wider FAIR community and other EU portals with a starting point for implementing HealthDCAT-AP within their own data catalogs.
Note
HealthDCAT-AP is still under active development and not finalized yet. Cardinalities, certain vocabularies and the namespace have not been officially ratified yet. These are expected to be finalized after the public consultation in Q1 2025.
Usage¶
Use the included euro_health_dcat_ap
profile in your configuration:
The HealthDCAT-AP profile is an extension of the DCAT-AP v3 profile and requires ckanext-scheming.
See the documentation on how to set it up. You can use the included
health_dcat_ap.yaml
schema file as a starting point to adapt it to your needs:
This profile has currently no additional settings.
Field Mapping¶
For a full overview of how CKAN dataset fields map to HealthDCAT-AP properties (including DPV fields), refer to the mapping table. This table documents the semantic relationship between CKAN schema fields and RDF predicates used in the euro_health_dcat_ap
profile implementation.
Limitations and deviations¶
As HealthDCAT-AP is still a draft, it is bound to change. There are currently still some inconsistencies in the standard and unclarities regarding certain properties. Below is a short summary of limitations and implementaiton decisions made during development of this profile.
- Cardinalities have not yet been finalized for HealthDCAT-AP. This CKAN schema has taken a very liberal approach and takes all values as strictly optional (no failed validation for missing fields). Note that some mandatory fields are currently impossible to fill with real data e.g. the Health Data Access Body (HDAB) field: the EHDS legislation has not been implemented yet and no HDABs have been formally appointed.
- The HealthDCAT-AP namespace is not formally defined yet. For now,
http://healthdataportal.eu/ns/health#
is used. This will be updated once the final namespace is standardized. - The official examples of the standard uses the
dct:description
property to encode the data purpose. This does not seem to be according to the Data Privacy Vocabulary specification, which proposes a controlled vocabulary. See this issue for the German perspective on this. - The distributions proposed by HealthDCAT-AP, analytics and sample, are not specifically implemented. URIs are linked, the resources themselves are not loaded. For sample, as this is an upstream DCAT-AP property, this can be included once picked up there.
- Documentation (foaf:page) is implemented as an URI. There is some HealthDCAT-AP example data out in the wild that uses a blank node for this and adds several properties, however this is inconsistent with other DCAT implementations.
- DatasetSeries are not supported yet by CKAN, and also not by this profile.
- The quality annotation property has not been implemented due to usage not being completely defined yet.
- There is no multilingual support yet.
- For other properties, any limitations from the DCAT-AP profiles still apply.