Minimum HealthDCAT-AP elements

 
 
We propose categorising health datasets (i.e.: datasets in scope of Art.51) into three distinct categories:
Based on this categorisation, we can further discuss the minimum metadata elements required for a HealthDCAT-AP record by taking into account existing applicable EU legislations.
EHDS Regulation Article 77) Dataset description and dataset catalogue
4. ... The Commission shall, by means of implementing acts, set out the minimum elements health data holders are to provide for datasets and the characteristics of those elements.
Non-personal electronic health data available as [open data]
The original scope of the DCAT-AP specification was to enable the description and exchange of publicly accessible Open Data across Open Data Portals in Europe. The dct:accessRights property, combined with the controlled vocabulary 'Access Rights' maintained by the Publications Office, allows data users to identify datasets as Open Data.
The access-right authority table is a controlled vocabulary listing the access rights or restrictions to resources. It is designed for but not limited to DCAT descriptions of datasets. This authority table is maintained by the Publications Office of the European Union and disseminated on the EU Vocabularies website.

PUBLIC: Publicly accessible by everyone. Usage note: Permissible obstacles include registration and request for API keys, as long as anyone can request such registration and/or API keys.
DCAT-AP 3.0 minimum elements
The minimum elements required in a DCAT-AP 3.0 metadata record are the 'title' and 'description.' If a dataset distribution is included, the 'access URL' also becomes mandatory.
DCAT-AP 3.0 Dataset

title

Literal

1..*

A name given to the Dataset.

This property can be repeated for parallel language versions of the name.

description

Literal

1..*

A free-text account of the Dataset.

This property can be repeated for parallel language versions of the description.
DCAT-AP 3.0 Distribution

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.
For 'non-personal electronic health data,' the EHDS Regulation mandates that the data must be open and accessible, which necessitates the inclusion of at least one distribution. However, this requirement is not addressed by the minimum metadata elements defined in DCAT-AP 3.0.
EHDS Regulation Article 60) Duties of the health data holders (open data)
5. Health data holders of non-personal electronic health data shall provide access to data through trusted open databases to ensure unrestricted access for all users and data storage and preservation. Trusted open public databases shall have in place robust, transparent and sustainable governance and a transparent model of user access.
This requirement is addressed by the minimum metadata elements defined in DCAT-AP High-Value Datasets:
DCAT-AP HVD minimum elements
The High-Value Datasets Implementing Regulation has introduced minimum elements to enhance metadata quality, thereby increasing the level of reuse for a selected group of core datasets within the public sector–namely Geospatial, Earth Observation and Environment, Meteorological, Statistics, Companies and Company Ownership, and Mobility. For instance, the 'Applicable Legislation' property, introduced in DCAT-AP version 3.0, is defined as a mandatory metadata element. Furthermore, any HVD metadata record must include at least one dataset distribution, a requirement also expressed in the European Health Data Space (EHDS) Regulation, as specified in Whereas 6 and expected in HealthDCAT-AP.
DCAT-AP HVD Dataset

applicable legislation

Legal Resource

1..*

The legislation that mandates the creation or management of the Dataset.

For HVD the value must include the ELI http://data.europa.eu/eli/reg_impl/2023/138/oj.

As multiple legislations may apply to the resource the maximum cardinality is not limited.

dataset distribution

Distribution

1..*

An available Distribution for the Dataset.

The HVD IR is a quality improvement of existing datasets. The intention is that HVD datasets are publicly and open accessible. Therefore a Distribution is expected to be present. (Article 3.1)
The High-Value Datasets Implementing Regulation has also introduced a mandatory controlled vocabulary to classify datasets according to defined core datasets by the IR. The 'Health' doesn't belong to the core datasets in scope of the HVD IR.

HVD Category

Concept

1..*

The HVD category to which this Dataset belongs.
However, a dataset under the scope of the High-Value Datasets Implementing Regulation (HVD IR) can also fall within the scope of the EHDS Regulation. To effectively populate health dataset catalogues with High-Value Datasets, we propose aligning the HealthDCAT-AP minimum elements with those of DCAT-AP HVD. Metadata conforming to DCAT-AP 3.0 can only be considered valid if at least one distribution is available. The 'applicable legislation' property should enable filtering for High-Value Datasets that fall under the EHDS. Expecting HVD data holders to consistently tag the 'applicable legislation' with the EHDS Regulation may be unrealistic. Therefore, Health Data Access Bodies need to consider an automatic metadata enrichment process based on sufficient indicators that a dataset is within the scope of the EHDS Regulation. Implementing a centralised open AI service to automate this filtering task could be an efficient and effective solution. Reminder: Nearly 27,000 records are labelled as health-related datasets using the DCAT 'theme' property, which requires the use of the Dataset Theme Vocabulary maintained by the EC Publications Office.
DCAT-AP HVD Distribution

applicable legislation

Legal Resource

1..*

The legislation that mandates the creation or management of the Distribution

For HVD the value must include the ELI http://data.europa.eu/eli/reg_impl/2023/138/oj.

As multiple legislations may apply to the resource the maximum cardinality is not limited.
Non health personal electronic data available as non-public data [Protected data]

RESTRICTED: Only available under certain conditions. Usage note: This category may include resources that require payment, resources shared under non-disclosure agreements, resources for which the publisher or owner has not yet decided if they can be publicly released.
The Data Governance Act introduced the concepts of NSIP (National Single Information Point) metadata and non-open NSIP data that can be searched in the European Data portal as European Register for Protected Data. These data according to the DGA can be health datasets and would fail in the scope of the EHDS Regulation. The exercise of defining HealthDCAT-AP minimum metadata elements implies to consider the requirements introduced by the DGA for non-open data. The minimum NSIP metadata elements include information on publishers and conditions for the re-use of data (both relating to the dataset metadata level; dct:publisher and dct:rights) as well as information on the format and size of individual distributions (dct:format and dcat:byteSize).
The Data Governance Act does not provide concrete technical instructions for the implementation of the NSIPs and the ERPD, neither on the technology or data level. The harvesting guidelines presented here are therefore based on an interpretation of the relevant articles of the Data Governance Act. This concerns in particular Articles 5-8 of the Data Governance Act.
...
Metadata that can be identified as being mandatory from the Data Governance Act are therefore mapped into DCAT-AP properties and must be structured correspondingly by NSIPs to enable harvesting. This relates to the requested information on the titles of datasets, their descriptions, their publisher, conditions for reuse and access procedure, format, and size.
The following metadata is mandatory for NSIP datasets:

Property

URI

Range

Usage note

Cardinality

Title (M)

dct:title *

rdfs:Literal

This property contains a name given to the Dataset. This property can be repeated for parallel language versions of the name.

1..n

Description (M)

dct:description *

rdfs:Literal

This property contains a free-text account of the Dataset. This property can be repeated for parallel language versions of the description.

1..n

Publisher (M)

dct:publisher

foaf:Agent

This property refers to an entity (organisation) responsible for making the Dataset available.

1..1

Access rights (M)

dct:accessRights

dct:RightsStatement

This property refers to information that indicates whether the dataset is open data, has access restrictions, or is not public. From the controlled vocabulary of the Publications Office of the EU 6, the following codes should be used for NSIP data: 'non-public' or 'restricted'. "open" is prohibited for NSIP data.

1..1

Distribution (M)

dct:distribution

dcat:Distribution

Distribution(s) available for a dataset.

1..n

 
The following metadata is mandatory for NSIP Distributions:

Property

URI

Range

Usage note

Cardinality

Format (M)

dct:format

dct:MediaTypeOrExtent

This property refers to the file format of the Distribution.

You can only specify one format per Distribution. If an NSIP offers the same data in different formats, each format must be specified as a separate distribution.

1..1

Size (M)

dcat:byteSize

rdfs:Literal

The size in bytes can be approximated (as a decimal) if the precise size is not known. If data is offered via an API or other endpoint, size should refer to the overall size of the underlying dataset.

1..1

Access procedure (M)

dcat:accessURL *

rdfs:Resource

A URL of a Website that enables either access to the described data or that contains information on how to request the data.

1..n

Conditions for re-use (Rights) (M)

dct:rights

dct:RightsStatement

This property refers to a statement that specifies rights associated with the Distribution.

1..1
Considering that a non-open NSIP dataset may fall within the scope of the EHDS Regulation, we propose aligning the HealthDCAT-AP minimum elements for non-personal electronic health data, available as non-open data, with those of NSIP metadata. The mandatory NSIP metadata for distributions is well-suited for accessing datasets without requiring a data request or permit application. However, it may be insufficient for personal electronic health data, where a formal application process must be managed by a Health Data Access Body.
Health personal electronic data [Sensitive data]
When a data request or permit application is required, the following minimum metadata elements have been discussed and proposed, along with the rationale behind the decisions on their cardinality

NON PUBLIC: Not publicly accessible for privacy, security or other reasons. Usage note: This category may include resources that contain sensitive or personal information.
Mandatory properties of HealthDCAT-AP for personal electronic health data

Property

Reasoning about cardinality's decision

Access rights

If information on data access is not provided, we cannot determine if the dataset needs to be linked to an application form. Therefore, health data holders MUST classify their datasets as either PUBLIC, RESTRICTED, or NON-PUBLIC. For HealthDCAT-AP, we will use only PUBLIC and NON-PUBLIC categories:

PUBLIC: Publicly accessible by everyone. Note: "Permissible obstacles include registration and request for API keys, as long as anyone can request such registration and/or API keys."

NON-PUBLIC: Not publicly accessible for privacy, security, or other reasons. Note: This category may include resources with sensitive or personal information.

If a dataset is PUBLIC, the metadata MUST include a distribution with an access URL or download link, as per the EHDS Regulation. If it is NON-PUBLIC, the metadata MUST include a distribution with a HDAB landing page or equivalent authority, according to the EHDS Regulation.

Applicable legislations

This property is essential for efficiently managing metadata records in a catalogue with multiple DCAT application profiles. Without a proper filter, customising an API to filter datasets is challenging. This information helps knowledgeable data users understand the reuse conditions of datasets.

A HDAB could automatically add the EHDS Regulation to this property for all metadata records in its dataset catalogue. A dataset can be in scope of multiple Directives and Regulations. Ex: INSPIRE health Theme Another example: a statistical population dataset (Census) is not dct:theme= HEAL but applicable legislation is HVD and EHDS.

(Comment: The conformsTo property in the catalogRecord class offers another filtering option if the DCAT Application Profile is provided, though this is more technical.) Upload mandatory condition to the EU health Data catalogue: applicableLegislation= EHDS (ELI link)

Contact point

A contact point should always be available for data users seeking more information about a dataset. This way, data users don't need to determine whether to contact the creators, publishers, or HDABs; the contact point serves as the dataset's "helpdesk."

Dataset distribution

In HealthDCAT-AP, there is always at least one distribution available. For sensitive data, this is typically an HDAB landing page. For data with public access rights, it may be a landing page, a direct download link, or a data service. Access to the data may require users to log in.

Description

Mandatory in DCAT-AP

Geographical coverage

Do all datasets listed in Art. 51 have a geographical signature? It appears they do, but this needs confirmation. This property is an important filter when considering populations. Providing geographical coverage can be technically challenging due to various possibilities. We recommend using controlled vocabularies for this property (see the usage note of DCAT-AP 3). Associating these vocabularies with spatial geometries would be beneficial.

Health category

Within a domain-specific catalogue, efficiently categorising datasets is essential for helping data users navigate and find relevant datasets more easily. Can TEHDAS2 assist in defining short labels for all categories in Art. 51, which is challenging for data holders? Additionally, could it be possible to develop a tool that automatically selects the correct category for data holders?

Health data access body

For all datasets where dct:type=personal data and/or dct:accessRights=non public, a HDAB or equivalent authority acts as a data access gateway, making this property mandatory. (This use case should be included in the Implementing Act for high impact datasets.)

If dct:accessRights=public, there's no need for the HDAB contact point, but a HDAB may choose to add it to metadata records in its catalogue. HDABs will need to update many metadata records from various sources. To include its catalogue in the central health EU catalogue, this property is mandatory. This means HealthDCAT-AP is an application profile supporting the healthDATA@EU infrastructure.

Health theme

Similar to keywords, but designed for machines, the health theme property relies on Wikidata–a large-scale, human-readable, machine-readable, multilingual, multidisciplinary, centralised, editable, structured, and linked knowledge base. This significantly enhances the quality and usability of dataset descriptions for machines. Evaluating the use of Wikidata and confirming its suitability could be an activity for TEHDAS2.

Identifier

DCAT-AP HVD rational on identifiers

To ensure the operational management of metadata records, Identifiers are defined as mandatory PURI for HealthDCAT-AP for high impact datasets

Keyword

It is important to include relevant keywords that characterise the dataset. While always applicable, this should be restricted to the main keywords. Data holders should avoid copy-pasting extensive lists and instead limit the keywords to 10-15 per language. For instance, if it consists of code values, it is preferable to use the property "code values" or to provide access to the codebook in adms:sample (consider to use CSV on the Web to describe the variables)

Provenance

It (dataset lineage) provides transparency about the origins and history of a dataset, ensuring data reliability and trustworthiness. It helps users understand how the dataset was created, modified, and by whom, which is crucial for assessing its quality and relevance. TEHDAS2 could work on improving the usage note

Publisher

The publisher acts as the data holder and is accountable for making the dataset accessible.

Publisher note

Understanding the nature of the publisher provides valuable context for the dataset and can be indicative of its overall quality. For example, a dataset published by a research institute may have higher credibility and reliability compared to others.

Publisher type

The same rationales apply as for Publisher Type, but they should be provided as full text.

Purpose

It explicitly explains why the data was collected and outlines its primary use. Do we need a definition of primary users and secondary users? "Peer reviewed journals would like to have this information listed, whether you reuse the data or are the original creator of the data set or not."

Sample

Mandatory (experimental) for personal electronic health data, this DCAT-AP 3.0 property is particularly valuable for sensitive data. It allows the exposure of a dataset representation artefact, such as mock-up data, synthetic data, anonymous data, or a codebook (data dictionary) that reveals the dataset's structure.

Theme

All records in the HDABs' catalogues must tag datasets as related to health using the OP CR entry "HEAL."

Title

Mandatory in DCAT-AP 3.0

Data type

Art. 33 encompasses both personal and non-personal electronic health data. It is crucial to distinguish between these data types, as defined by the Controlled Vocabulary (CV) that can be applied. The CV includes entries such as geospatial data, statistical data, ontologies, etc. We propose adding personal data to this CV. For more information, you can refer to the EU Vocabularies concept scheme: https://op.europa.eu/en/web/eu-vocabularies/concept-scheme/-/resource?uri=http://publications.europa.eu/resource/authority/dataset-type Additionally, does Art. 33 include ontologies, such as the Rare Diseases Ontology? This exercise is part of TEHDAS2's comparison of Art. 33 and the Dataset-type authority table.
Recommended properties of HealthDCAT-AP for personal electronic health data

Analytics

This property has been introduced in HealthDCAT-AP to expose metrics and insights about the dataset. It is of the type Distribution, similar to dct:distribution and adms:sample, as it also represents data. However, it should not be considered a standard distribution of the dataset itself. Instead, it may take the form of an analytics dashboard (advanced use case), a technical report (statistical data), or an API for querying the dataset. It does not provide any direct download or subset possibilities of the dataset. The ECDC Atlas, used in testing HealthDCAT-AP, perfectly illustrates the use of this property.

Code values

This property can enhance discoverability. For instance, a data user might search for a specific disease using a coding system like ICD-10. Moreover, this property is designed to be machine-actionable, facilitating automated processes and searches.

Coding systems

This property indicates the readiness of the dataset for reuse and can enhance its discoverability. For instance, a data user might search for datasets that utilise ICD-10 for coding diseases. Additionally, this property is designed to be machine-actionable, facilitating automated processes and searches.

Conforms to

This property provides information on the readiness of the dataset for reuse. It can improve the discoverability of a dataset. A data user might search for a dataset compliant to the OMOP data model.

Documentation

Publishing documentation about datasets is a valuable and common practice that enhances understanding of the dataset. However, maintaining publicly available documentation can be challenging for data holders. Documentation serves as a quality element in the Regulation.

frequency

 

is referenced by

FAIR I3: (Meta)data include qualified references to other (meta)data.

Landing page

A landing page is defined as "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" (DCAT-AP 3).

Support for implementation: We need to explicitly define two concurrent properties:

1.         dcat:landingPage

in the dataset class (Optional): This property refers to a web page that provides comprehensive access to the dataset and related information.

2.         dcat:accessURL

in the Distribution class (Mandatory): This is a URL that gives access to a specific distribution of the dataset. The resource at the access URL may include information on how to obtain the dataset.

Considering that in HealthDCAT-AP a distribution always exists and that the access URL is a mandatory property within a distribution, we need to clarify whether the landing page should also be a mandatory property and what specific information (URI) it should contain. In any case, it is a recommended property.

Language

A data user expects to have this information when it pertains to health data if applicable.

Legal basis

The collection of personal data must always have a legal basis under the GDPR. If such a legal basis exists, it should be provided to help data users better understand the premise of the dataset's (secondary) use.

Maximum typical age

Applicable only for population datasets. Useful filter to explore a catalogue. This concept of typical age exists in several health dataset catalogues.

Minimum typical age

Applicable only for population datasets. Useful filter to explore a catalogue. This concept of typical age exists in several health dataset catalogues.

Number of Records

Referring to Art. 8 of the Data Governance Act: "... with relevant information describing the available data, including at least the data format and size and the conditions for their re-use," one can observe that specifying the size is mandatory. Beyond offering quantitative information, it allows the data user to estimate the 'value' of the dataset.

Number of unique individual

Beyond providing quantitative information, it enables the data user to estimate the 'value' of the dataset.

Personal data

Understanding the nature of the publisher provides valuable context for the dataset and can be indicative of its overall quality. For example, a dataset published by a research institute may have higher credibility and reliability compared to others.

Population coverage

Definition: 'A description of the population within the dataset.' This is important for understanding the dataset, but it is only applicable if the dataset contains a population.

quality annotation

EHDS reg. Whereas (59) The data quality and utility label should not prevent datasets from being made available through the EHDS

Related resource (dct:relation)

FAIR I3: (Meta)data include qualified references to other (meta)data. All relationships to other datasets and resources help to understand how a dataset has been used and, ultimately, how it can be used. This practice extends the dataset's DCAT knowledge graph.

Source (A related dataset dct:source)

FAIR I3: (Meta)data include qualified references to other (meta)data. Relationships to other datasets and resources help understand how a dataset has been used and how it can be used in the future. This process extends the dataset's DCAT knowledge graph.

Temporal coverage

The Temporal Coverage property, defined by two timestamps (start date and end date), specifies the period that the dataset covers. If data collection is ongoing, no end date is provided. Is this approach sufficient? (It could be discussed in TEHDAS2. Keep it simple.)

Temporal resolution

It is an asset to have this information as it allows one to determine the reuse applicability.
Optional properties of HealthDCAT-AP for personal electronic health data

Retention period

If the dataset must be deleted after a specific date, this property is mandatory, as the dataset cannot be included in the EU central dataset catalogue "basket." However, the metadata record must remain available because some publications may reference it.

Spatial resolution (meters)

Rarely applicable, except for geospatial data.

Version

A good practice in data management is to maintain a versioning strategy for datasets. While not essential for the discoverability and understanding of the dataset, it is up to the data holder to decide whether to provide this information.

...

 
Conclusion
In summary, DCAT-AP metadata can populate a health dataset catalogue if it meets specific criteria, depending on the type of health data being described:

  • [Open data] HealthDCAT-AP for non-personal electronic health data is categorised by applying the filter condition dcat:theme=HEAL. For open data under the High-Value Datasets Implementing Regulation (HVD IR), essential metadata fields such as dct:title, dct:description, dcatap:applicableLegislation=ELI HVD, and distribution elements like Access URL must be provided.
  • [Protected data] For non-open data under the Data Governance Act (DGA), additional fields, including dct:accessRights=restricted, dct:publisher, and distribution details such as format, size, and re-use conditions, are required.
  • [Sensitive Data] HealthDCAT-AP for personal electronic health data requires a more specific filter condition: dcat:theme=HEAL + dct:type=personal_data. This activates additional cardinalities in HealthDCAT-AP to ensure metadata completeness, including fields such as Access Rights, Applicable Legislation, Contact Point, Dataset Distribution, Description, Geographical Coverage, Health Category, Health Data Access Body, Identifier, Publisher, Purpose, and more.

HealthDCAT-AP defines three conditional sets of minimum metadata elements depending on the sensitivity of the data, reflecting the variety of datasets in scope under the EHDS Regulation (Article 33). This flexibility ensures that both personal and non-personal health data are appropriately managed and described, supporting the diverse needs of health data governance.
HealthDCAT-AP cardinalities depending of the access right on the dataset:

PUBLIC

RESTRICTED

NON_PUBLIC

 

Mandatory properties

 

dct:description: rdfs:Literal [1..n]

dct:title: rdfs:Literal [1..n]

dct:identifier: rdfs:Literal: xsd:anyURI [1..n]

dcatap:applicableLegislation rdfs:Resource [1..n]

dcat:theme (dct:subject): skos:Concept [1..n]

dct:accessRights: dct:RightsStatement [1..1]

dcat:distribution: dcat:Distribution [1..n]

healthdcatap:hdab foaf:Agent [1..1]

heathdcatap:healthCategory: (dct:subject) skos:Concept [1..n]

 

dct:description: rdfs:Literal [1..n]
dct:title: rdfs:Literal [1..n]

dct:identifier: rdfs:Literal: xsd:anyURI [1..n]

dcatap:applicableLegislation rdfs:Resource [1..n]

dcat:theme (dct:subject): skos:Concept [1..n]

dct:accessRights: dct:RightsStatement [1..1]

dct:publisher: foaf:Agent [1..1]

dcat:distribution: dcat:Distribution [1..n]

healthdcatap:hdab foaf:Agent [1..1]

heathdcatap:healthCategory: (dct:subject) skos:Concept [1..n]

 

adms:sample: dcat:Distribution [1..n]

dcat:contactPoint: vcard:Kind [1..n]

dcat:distribution: dcat:Distribution [1..n]

dcat:keyword: rdfs:Literal [1..n]

dcat:theme (dct:subject): skos:Concept [1..n]

dcatap:applicableLegislation rdfs:Resource [1..n]

dct:accessRights: dct:RightsStatement [1..1]

dct:description: rdfs:Literal [1..n]

dct:identifier: rdfs:Literal: xsd:anyURI [1..n]

dct:provenance: dct:ProvenanceStatement [1..n]

dct:publisher: foaf:Agent [1..1]

dct:spatial: dct:Location [1..n]

dct:title: rdfs:Literal [1..n]

dct:type: skos:Concept [1..1]

dpv:hasPurpose dpv:Purpose [1..n]

healthdcatap:hdab foaf:Agent [1..1]

heathdcatap:healthCategory: (dct:subject) skos:Concept [1..n]

healthdcatap:healthTheme: (dct:subject) skos:Concept [1..n]

 

 

Recommended properties

 

dcat:contactPoint: vcard:Kind [0..n]

dcat:keyword: rdfs:Literal [0..n]

dcat:contactPoint: vcard:Kind [0..n]

dcat:keyword: rdfs:Literal [0..n]

dcat:landingPage: foaf:Document [0..n]

dcat:temporalResolution rdfs:Literal: xsd:duration [0..1]

dct:accrualPeriodicity: dct:Frequency [0..1]

dct:conformsTo: dct:Standard [0..n]

dct:isReferencedBy: rdfs:Resource [0..n]

dct:language: dct:LinguisticSystem [0..n]

dct:relation: rdfs:Resource [0..n]

dct:source: dcat:Dataset [0..n]

dct:temporal: dct:PeriodOfTime [0..n]

dpv:hasLegalBasis dpv:LegalBasis [1..n]

dpv:hasPersonalData dpv:PersonalData [0..n]

dqv:hasQualityAnnotation dqv:QualityCertificate [1..n]

foaf:page: foaf:Document [0..n]

healthdcatap:analytics: dcat:Distribution [0..n]

healthdcatap:hasCodeValues: skos:Concept [0..n]

healthdcatap:hasCodingSystem dct:Standard [0..n]
healthdcatap:minTypicalAge rdfs:nonNegativInteger [1..1]
healthdcatap:maxTypicalAge rdfs:nonNegativInteger [1..1]
healthdcatap:numberofRecords rdfs:nonNegativInteger 1..1]
healthdcatap:numberofUniqueIndividuals rdfs:nonNegativInteger 1..1]

healthdcatap:populationCoverage rdfs:Literal [1..n]

 

 

Optional properties

 

adms:identifier: adms:Identifier [0..n]

adms:sample: dcat:Distribution [0..n]

adms:versionNotes: rdfs:Literal [0..n]

dcat:landingPage: foaf:Document [0..n]

dcat:qualifiedRelation: dcat:Relationship [0..n]

dcat:spatialResolutionInMeters: rdfs:Literal: xsd:decimal [0..1]

dcat:temporalResolution rdfs:Literal: xsd:duration [0..1]

dct:accrualPeriodicity: dct:Frequency [0..1]

dct:alternative: rdfs:Literal [0..1]

dct:conformsTo: dct:Standard [0..n]

dct:creator: foaf:Agent [0..n]

dct:hasVersion: dcat:Dataset [0..n]

dct:inSeries: dcat:DataSeries [0..n]

dct:isReferencedBy: rdfs:Resource [0..n]

dct:issued: rdfs:Literal: xsd:date [0..1]

dct:language: dct:LinguisticSystem [0..n]

dct:modified: rdfs:Literal: xsd:date [0..1]

dct:provenance: dct:ProvenanceStatement [0..n]

dct:publisher: foaf:Agent [0..1]

dct:relation: rdfs:Resource [0..n]

dct:source: dcat:Dataset [0..n]

dct:spatial: dct:Location [0..n]

dct:temporal: dct:PeriodOfTime [0..n]

dct:type: skos:Concept [0..1]

dpv:hasLegalBasis dpv:LegalBasis [0..n]

dpv:hasPersonalData dpv:PersonalData [0..n]

dpv:hasPurpose dpv:Purpose [0..n]

dqv:hasQualityAnnotation dqv:QualityCertificate [0..n]

foaf:page: foaf:Document [0..n]

healthdcatap:analytics: dcat:Distribution [0..n]

healthdcatap:hasCodeValues: skos:Concept [0..n]

healthdcatap:hasCodingSystem dct:Standard [0..n]

healthdcatap:healthTheme: (dct:subject) skos:Concept [0..n]

healthdcatap:maxTypicalAge rdfs:nonNegativInteger [0..1]

healthdcatap:minTypicalAge rdfs:nonNegativInteger [0..1]

healthdcatap:numberofRecords rdfs:nonNegativInteger [0..1]
healthdcatap:numberofUniqueIndividuals rdfs:nonNegativInteger [0..1]

healthdcatap:populationCoverage rdfs:Literal [0..n]

healthdcatap:retentionPeriod dct:PeriodOfTime [0..1]

owl:versionInfo: rdfs:Literal [0..1]

prov:qualifiedAttribution prov:attribution [0..n]

prov:wasGeneratedBy: prov:Activity [0..n]

 

adms:identifier: adms:Identifier [0..n]

adms:sample: dcat:Distribution [0..n]

adms:versionNotes: rdfs:Literal [0..n]

dcat:landingPage: foaf:Document [0..n]

dcat:qualifiedRelation: dcat:Relationship [0..n]

dcat:spatialResolutionInMeters: rdfs:Literal: xsd:decimal [0..1]

dcat:temporalResolution rdfs:Literal: xsd:duration [0..1]

dct:accrualPeriodicity: dct:Frequency [0..1]

dct:alternative: rdfs:Literal [0..1]

dct:conformsTo: dct:Standard [0..n]

dct:creator: foaf:Agent [0..n]

dct:hasVersion: dcat:Dataset [0..n]

dct:inSeries: dcat:DataSeries [0..n]

dct:isReferencedBy: rdfs:Resource [0..n]

dct:issued: rdfs:Literal: xsd:date [0..1]

dct:language: dct:LinguisticSystem [0..n]

dct:modified: rdfs:Literal: xsd:date [0..1]

dct:provenance: dct:ProvenanceStatement [0..n]

dct:relation: rdfs:Resource [0..n]

dct:source: dcat:Dataset [0..n]

dct:spatial: dct:Location [0..n]

dct:temporal: dct:PeriodOfTime [0..n]

dct:type: skos:Concept [0..1]

dpv:hasLegalBasis dpv:LegalBasis [0..n]

dpv:hasPersonalData dpv:PersonalData [0..n]

dpv:hasPurpose dpv:Purpose [0..n]

dqv:hasQualityAnnotation dqv:QualityCertificate [0..n]

foaf:page: foaf:Document [0..n]

healthdcatap:analytics: dcat:Distribution [0..n]

healthdcatap:hasCodeValues: skos:Concept [0..n]

healthdcatap:hasCodingSystem dct:Standard [0..n]

healthdcatap:healthTheme: (dct:subject) skos:Concept [0..n]

healthdcatap:maxTypicalAge rdfs:nonNegativInteger [0..1]

healthdcatap:minTypicalAge rdfs:nonNegativInteger [0..1]

healthdcatap:numberofRecords rdfs:nonNegativInteger [0..1]
healthdcatap:numberofUniqueIndividuals rdfs:nonNegativInteger [0..1]

healthdcatap:populationCoverage rdfs:Literal [0..n]

healthdcatap:retentionPeriod dct:PeriodOfTime [0..1]

owl:versionInfo: rdfs:Literal [0..1]

prov:qualifiedAttribution prov:attribution [0..n]

prov:wasGeneratedBy: prov:Activity [0..n]

adms:identifier: adms:Identifier [0..n]

adms:versionNotes: rdfs:Literal [0..n]

dcat:qualifiedRelation: dcat:Relationship [0..n]

dcat:spatialResolutionInMeters: rdfs:Literal: xsd:decimal [0..1]

dct:alternative: rdfs:Literal [0..1]

dct:creator: foaf:Agent [0..n]

dct:hasVersion: dcat:Dataset [0..n]

dct:inSeries: dcat:DataSeries [0..n]

dct:issued: rdfs:Literal: xsd:date [0..1]

dct:modified: rdfs:Literal: xsd:date [0..1]

healthdcatap:retentionPeriod dct:PeriodOfTime [0..1]

owl:versionInfo: rdfs:Literal [0..1]

prov:qualifiedAttribution prov:attribution [0..n]

prov:wasGeneratedBy: prov:Activity [0..n]
The most recent version of HealthDCAT-AP cardinalities is available at https://HealthDCAT-AP.github.io