Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 131 Next »

STATUS: IN DEVELOPMENT

Editors:

Bruna dos Santos Vieira

Dena Tahvidalri (until 29th Feb 2024)

Repository:

Github

Issues

Latest published version:

health-ri-metadata/Formalisation(shacl)/Core/coreRules.shapes.ttl at master · Health-RI/health-ri-metadata (github.com)

Purpose of this document

This document outlines the Plateau 1 Core Metadata Schema, detailing the classes and entities involved and offering implementation guidance (usage notes) for developers at regional nodes. It specifically addresses the schema's design and application but excludes discussion on the national catalog, its onboarding process, and future schema expansions. Additional information and versions are available on GitHub.https://github.com/Health-RI/health-ri-metadata/.

Intended Audience

Designed for a technical audience tasked with implementing the metadata schema and stakeholders interested in a detailed understanding of the core schema.

Introduction

Context

To find and reuse information scattered across different sources, the research community in the Netherlands has agreed to index its resources in a national catalog (add link to portal documentation Lucie Kulhankova ). The national catalog in turn aims to be indexed in international catalogs. One of the necessary conditions to achieve this goal is a common agreement on the minimum elements needed to search, find and reuse such resources. These elements and their properties are components of the Core Metadata Schema.

Scope

The Core Metadata Schema is a formal shared conceptualisation of the requirements to find and reuse information across Health-RI nodes via the national catalog. It represents a set of minimal elements for describing each resource (including dataset) with common metadata. This scope is consistent with the functionality provided in the Plateau 1 National catalog release package (Lucie Kulhankova add link to documentation on plateau 1 and portal development releases).

The core model (see Diagram) can be further extended and specialised to reflect domain-specific requirements (domains may include omics, imaging, etc). Therefore, we expect additional versions to be released according to the requirements of Plateaus 2 and beyond. All versions will be published via https://github.com/Health-RI/health-ri-metadata/.

The core model is being reviewed by the community of nodes that make up the Health-RI ecosystem (see Feedback section). The final release of this version will be a prerequisite for resources to be included in the national catalog (Lucie Kulhankova add Portal link) and benefit from its offered features. How to implement this model and connect to the national catalog is described in the onboarding documentation. The offered features of the national catalog are defined in Plateau 1 (Lucie Kulhankova add link to Plateau 1 doc).

Notes on Alignment

To create the current core metadata schema, we examined existing metadata from the COVID-19 national portal, metadata schema provided by Health-RI nodes (e.g., ABC metadata), and standards used in portals across Europe and beyond (e.g., W3C, DCAT, DCAT-AP). Then, with assistance from metadata specialists from the hub and nodes, we began mapping their classes and properties. The mappings are detailed in the mapping table. Finally, after conceptualisation, we decided to reuse DCAT and DCAT-AP for its implementation. This version of the Core metadata schema includes DCAT v3 and some selected DCAT-AP mandatory classes and their definitions. The most important entities are those that form the core of the DCAT application profile. DCAT-AP is a DCAT application profile for the exchange of information about catalog of datasets and description of data services in Europe. Hence, the Core metadata schema ensures compatibility with international catalogs which also use DCAT-AP. This is mainly because the DCAT application profile covers the identified requirements.

dcat:Resource and other Resource Types

Within DCAT and DCAT-AP, the term "resource" generally encompasses all objects that can be described using RDF. However, there are specific categories and attributes used to indicate the different types of resources:

  • dcat:Dataset is a type of dcat:Resource representing a collection of data

  • dcat:Distribution is a type of dcat:Resourcee representing an available form or representation of a dataset.

  • dcat:Catalogis a type of dcat:Resource representing a collection of datasets.

  • dcat:DataService , introduced in DCAT version 2, is a type of Resource representing a service for accessing data.

  • foaf:Project is a type of dcat:Resource representing project-level information

In DCAT and DCAT-AP, the vocabulary is focused on datasets. Nonetheless, there may arise a requirement to portray a wider variety of resources that are specific to certain domains, like biobanks or patient registries. In such cases, we propose potential scenarios for modifying or augmenting DCAT to accurately depict your resource type.

  • Use dcat:Resource directly: If the asset you are dealing with is not in line with the dcat:Dataset definition, you can use the broader term dcat:Resource. This term allows you to represent almost any type of asset. However, this approach may not be completely clear for users who are trying to understand the essence of the asset. We can de define the asset type further with specific vocabularies over time.

  • Expand with Personalised Classes: If there is a need to represent specific resources, such as biobanks or patient registries, it may be beneficial to supplement the foundational DCAT vocabulary with custom classes. For example:

:Collection a rdfs:Class ;

rdfs:subClassOf dcat:Resource .

and

:PatientRegistry a rdfs:Class ;

rdfs:subClassOf dcat:Dataset .

When creating custom classes, it is essential to provide detailed metadata for each type of resource. This will enable users and systems to distinguish between them and comprehend their subtle differences. For instance, consider the distinction between a collection and a dataset. Therefore, it is crucial to provide specific and unambiguous information to ensure complete understanding.

Feedback via Git Issues

If you wish to extend the model, such as with Resource, and/or create a new concept, please open an issue in Health-RI’s GitHub repository https://github.com/Health-RI/health-ri-metadata/tree/master and provide a clear explanation for the extension. Assign the issue to either ‘brunasv’ or ‘xiaofengleo’, and we will work with you to implement the addition in the next release.

Overview

An overview of the Metadata schema core is presented in the UML diagram depicted below (Fig 1). The UML showcases the primary classes (entities), excluding the detailed definitions such as rdfs:label rdfs:comment. Each block denotes a class and comprises a list of its attributes (properties). If a class is connected to another class by a closed arrow, this signifies that it inherits all properties from the other class. For example, dcat:DatasetSeries inherits from dcat:Dataset which inherits from dcat:Resource. The other arrows, represent relations and contain the type of relation, such as dcat:Dataset connects to a dcat:DatasetSeries via the predicate dcat:inSeries, and include the cardinality, such as dcat:Dataset can be connected via dcat:inSeries to zero or more dcat:DatasetSeries.

Recommended Versus Mandatory

Following the DCAT-AP specification, we distinguish between recommended and mandatory components (classes and properties). The subsequent section clarifies these components under ‘mandatory’ and ‘recommended’ headings. A third category named 'Optional' may be introduced in the future.

In the context of data exchange, the following definitions apply:

  • Mandatory class: a receiver of data MUST be able to process information about instances of the class; a sender of data MUST provide information about instances of the class

  • Recommended class: a sender of data SHOULD provide information about instances of the class; a sender of data MUST provide information about instances of the class if such information is available; a receiver of data MUST be able to process information about instances of the class.

  • Optional class: a receiver MUST be able to process information about instances of the class; a sender MAY provide the information but is not obliged to do so.

  • Mandatory property: a receiver MUST be able to process the information for that property; a sender MUST provide the information for that property.

  • Recommended property: a receiver MUST be able to process the information for that property; a sender SHOULD provide the information for that property if it is available.

  • Optional property: a receiver MUST be able to process the information for that property; a sender MAY provide the information for that property but is not obliged to do so.

Diagram

Terminology

According to DCAT-AP:

  • An Application Profile defines the mandatory, recommended, and optional components for a specific use case by leveraging terminology from foundational standards. Additionally, it suggests standardized vocabularies to maintain consistency in the use of terms and data.

  • A Dataset is a self-contained set of data produced by a specific organization, which can be accessed or downloaded for various uses.

  • A Data Portal is an online platform that offers a catalog of datasets and tools to help users locate and utilize these datasets effectively.

Used Prefixes

Prefix

Namespace IRI

Source

dcat

http://www.w3.org/ns/dcat#

[VOCAB-DCAT]

dct

http://purl.org/dc/terms/

[DCT]

foaf

http://xmlns.com/foaf/0.1/

[FOAF]

owl

http://www.w3.org/2002/07/owl#

[OWL2-SYNTAX]

rdf

http://www.w3.org/1999/02/22-rdf-syntax-ns#

[RDF-SYNTAX-GRAMMAR]

rdfs

http://www.w3.org/2000/01/rdf-schema#

[RDF-SCHEMA]

skos

http://www.w3.org/2004/02/skos/core#

[SKOS-REFERENCE]

time

http://www.w3.org/2006/time#

[OWL-TIME]

xsd

http://www.w3.org/2001/XMLSchema#

[XMLSCHEMA11-2]

Core Metadata Schema Classes

Mandatory Classes

Class name

Definition

Usage Note

URI

Dataset

A resource type.
A collection of data, published or curated by a single agent, and available for access or download in one or more representations.

Used to describe one or more datasets. This describes details about the dataset(s). However, a single dataset can have different ways in which they are made available to potential users. How the data in a dataset can be accessed is defined in the Distribution.

dcat:Dataset

Catalog

A catalog that is listed in the National catalog.

Used to describe a bundle of datasets, data services, biobanks, patient registries, or guidelines together under a single title.

dcat:catalog

Agent

An entity that is associated with catalog and/or Datasets.

If the Agent is an organisation, the use of the Organization Ontology is recommended.

foaf:Agent

Resource

Resource published or curated by a single agent.

This is an abstract class, we do not use this class, instead we use specifications of it (e.g. Dataset). This is mainly for a high level grouping and the reuse of properties.

dcat:Resource

Recommended Classes

Class name

Definition

Usage Note

URI

Distribution

An available distribution of the dataset.

Used to describe the different ways that a single dataset can be made available in. I.e., it can be downloaded or it can be accessed online in one or more distributions (e.g. one in a downloadable .csv file, another file with an access or query webpage)

dcat:Distribution

Dataset Series

A resource type.

Dataset series are defined in [ISO-19115] as a collection of datasets […] sharing common characteristics. However, their use is not limited to geospatial data, although in other domains they can be named differently (e.g., time series, data slices) and defined more or less strictly (see, e.g., the notion of "dataset slice" in [VOCAB-DATA-CUBE]).

With Dataset Series we refer to data, somehow interrelated, that are published separately. An example is budget data split by year and/or country, instead of being made available in a single dataset.

dcat:DatasetSeries

Data Service

A Resource type.
A collection of operations that provides access to one or more datasets or data processing functions.

The kind of service can be indicated using the dcterms:type property. Its value may be taken from a controlled vocabulary that should be defined in the community.

DRAFT EXAMPLE:

dcat:DataService

Project

A project (a collective endeavour of some kind).

Used to describe a project that is connected to one or more datasets. A resource type

foaf:Project

Abstract Classes that DO NOT instantiate (do not populate)

Resource

Resource is a generic concept from the DCAT vocabulary, that is rarely used directly, but indirectly through its extensions. We recommend avoiding using dcat:Resource directly for your document unless the type/class you need is not in this schema.

Class name

Definition

Usage Note

URI

Resource

The class resource, everything.

This class is for grouping and class hierarchy relation purposes.

dcat:Resource

Core Metadata Schema Properties per Class

Catalog

A curated collection of metadata about resources. A web-based data catalog is typically represented as a single instance of this class.

Mandatory Properties

Property name

Definition

URI

rdfs:Range

Usage Note

Cardinality

title

A name given to the resource.

dct:title

rdfs:Literal

The name of the catalog. This is a required field and needs to be unique. 

1..*

description

A free-text account of the record.

dct:description

xsd:string

A brief description of the catalog. It can consist of multiple strings. For example, this catalog describes breast cancer imaging datasets. 

1..*

publisher

The entity responsible for making the resource available.

dct:publisher

foaf:Agent

The organisation or a person that has published the catalog

1..*

dataset

relates every catalog to its containing datasets/

dcat:dataset

dcat:Dataset

The connection to the one or more datasets that this catalog describes.

1..*

Recommended Properties

No recommended properties are identified for this release.

Dataset

A collection of data, published or curated by a single agent, and available for access or download in one or more representations.

Mandatory Properties

Property name

Definition

URI

rdfs:Range

Usage Note

Cardinality

contact point

Relevant contact information for the catalogd resource.

dcat:contactPoint

foaf:Agent

Contact information that can be used, for example, for sending requests to further information or access to the Dataset.

1..*

creator

The entity responsible for producing the resource.

dct:creator

foaf:Agent

An agent (person or organisation) responsible for producing the dataset.

1..*

description

A free-text account of the record

dct:description

rdfs:Literal

xsd:string

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

1..*

Issued

Date of formal issuance (e.g., publication) of the resource.

dct:issued

rdfs:Literal typed as xsd:date or xsd:dateTime

NA

1..*

identifier

A unique identifier of the resource being described or catalogd.

dct:identifier

xsd:string

The main identifier for the Dataset, e.g. the URI or other unique identifier in the context of the catalog.

1..1

modified

Most recent date on which the catalog entry was changed, updated or modified.

dct:modified

xsd:datetime

The most recent date on which the Dataset was changed or modified.

1..*

publisher

The entity responsible for making the resource available.

dct:publisher

foaf:Agent

An agent (organisation or person) responsible for making the Dataset available.

1..*

theme

A main category of the resource. A resource can have multiple themes.

dcat:themeTaxonomy

skos:Concept

It consists of 1 or more IRIs (links) separated by commas. When set, it specifies relevant ontology concepts that classify the dataset. Typically, these can be looked up using the Ontology Lookup Service (OLS) or Bioportal.  

1..*

title

A name given to the record.

dct:title

xsd:string

rdfs:Literal

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

1..*

type

The nature or genre of the resource.

dct:type

skos:Concept

A type of the Dataset. A recommended controlled vocabulary data-type is foreseen.

1..*

License

A legal document under which the resource is made available.

dct:license

dcterms:LicenseDocument

This should contain a URL that provides details regarding the license that is applicable to this dataset.

1..*

relation

defines a relation

dct:relation

foaf:Project

1..*

Recommended Properties

Property name

Definition

URI

rdfs:Range

Usage Note

Cardinality

dataset distribution

An available distribution of the dataset.

dcat:distribution

dcat:Distribution

Use this property to point to the distribution of this dataset when a distribution is available.

0..*

project

connect dataset to the corresponding projects

foaf:Project

xsd:string

Use this property to point to the related project of this dataset when a project is available.

0..*

has version

This resource has a more specific, versioned resource [PAV].

dct:hasVersion

xsd:string

This property refers to a related Dataset that is a version, edition, or adaptation of the described Dataset.

0..*

in series

A dataset series of which the dataset is part.

dcat:inSeries

dcat:DatasetSeries

NA

0..*

Data Service

A collection of operations that provides access to one or more datasets or data processing functions.

Mandatory Properties

Property name

Definition

URI

rdfs:Range

Usage Note

Cardinality

end point URL

The root location or primary endpoint of the service (a Web-resolvable IRI).

dcat:endPointURL

xsd:string

Or

dcat:Resource

NA

1..*

title

A name given to the distribution.

dct:title

xsd:String

rdfs:Literal

NA

1..*

serves dataset

A collection of data that this data service can distribute.

dcat:servesDataset

dcat:Dataset

NA

1..*

Recommended Properties

Property name

Definition

URI

rdfs:Range

Usage Note

Cardinality

end point description

A description of the services available via the end-points, including their operations, parameters etc.

dcat:endpointDescription

dcat:Resource

xsd:string

An endpoint description may be expressed in a machine-readable form, such as an OpenAPI (Swagger) description [OpenAPI], an OGC GetCapabilities response [WFS], [ISO-19142], [WMS], [ISO-19128], a SPARQL Service Description [SPARQL11-SERVICE-DESCRIPTION], an [OpenSearch] or [WSDL20] document, a Hydra API description [HYDRA], else in text or some other informal mode if a formal representation is not possible.

0..*

Distribution

An available distribution of the dataset.

Mandatory Properties

Property name

Definition

URI

rdfs:Range

Usage Note

Cardinality

title

A name given to the distribution.

dct:title

xsd:string

the name of the dataset in combination with the format of the distribution can be used

1..*

access URL

A URL of the resource that gives access to a distribution of the dataset. E.g., landing page, feed, SPARQL endpoint.

dcat:accessURL

xsd:string

This property contains 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.

1..*

media type

The media type of the distribution as defined by IANA [IANA-MEDIA-TYPES].

dcat:mediaType

xsd:string

This property SHOULD be used when the media type of the distribution is defined in IANA [IANA-MEDIA-TYPES], otherwise dcterms:format MAY be used with different values.

1..*

description

A unique identifier of the resource being described or catalog.

dct:description

xsd:string

NA

1..*

Recommended Properties

Property name

Definition

URI

rdfs:Range

Usage Note

Cardinality

access service

A data service that gives access to the distribution of the dataset

dcat:accessService

dcat:DataService

dcat:accessService SHOULD be used to link to a description of a dcat:DataService that can provide access to this distribution.

0..*

download URL

The URL of the downloadable file in a given format. E.g., CSV file or RDF file. The format is indicated by the distribution's dcterms:format and/or dcat:mediaType

dcat:downloadURL

dcat:Resource

xsd:string

NA

0..*

Agent

An entity that is associated with catalog and/or Datasets. Agent can be individuals or organisations, If the Agent is an organisation, the use of the Organization Ontology is recommended.

Mandatory Properties

Property name

Definition

URI

rdfs:Range

Usage Note

Cardinality

name

A name for some thing.

foaf:name

xsd:string

This property contains a name of the agent. This property can be repeated for different versions of the name (e.g. the name in different languages)

1..*

identifier

A unique identifier of the resource being described or catalog.

dct:identifier

xsd:string

1..1

Recommended Properties

No recommended properties are identified for this release.

Project

A project (a collective endeavour of some kind).

Mandatory Properties

Property name

Definition

URI

rdfs:Range

Usage Note

Cardinality

Description

description of the project

dct:description

xsd:string

NA

1..*

identifier

A unique identifier of the resource being described or catalog.

dct:identifier

xsd:string

NA

1.1

title

A name given to the resource.

dct:title

xsd:string

NA

1..*

funded by

An organization funding a project or person.

foaf:fundedBy

foaf:Agent

NA

1..*

relation

link to the project datasets

dct:relation

dct:Dataset

NA

1..*

Recommended Properties

No recommended properties are identified for this release.

Resource

All things described by RDF are called resources, and they are instances of the class dcat:Resource. This is the class of everything. All other classes are subclasses of this class. To read more, go to https://www.w3.org/TR/rdf12-schema/#ch_resource.

  • No labels