Introduction

This document contains version 2.0 of the specification for EPOS-DCAT-AP, an extension of the DCAT application profile for Research Infrastructures which allows to increase findability, accessibility, and usability of multidisciplinary resources to researchers and other stakeholders.

Terminology used in the Application Profile

A Vocabulary s a specification that determines the semantics of terms (classes and properties) in a broad context of information exchange. The defined terms are highlyhigly reusable.

An Application Profile is a specification that re-uses terms from one or more base standards (vocabularies), 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.

In the following sections, classes and properties are grouped under headings ‘mandatory’, ‘recommended’ and ‘optional’. These terms have the following meaning:

• Mandatory class: a receiver MUST be able to process information about instances of the class; a sender MUST provide information about instances of the class.
• Recommended class: a receiver MUST be able to process information about instances of the class; a sender 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.
• 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 information for that property; a sender MUST provide information for that property, if such information 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.

The meaning of the terms MUST, MUST NOT, SHOULD and MAY in this section and in the following sections are as defined in [[RFC2119]].

Application Profile Overview

shows a UML diagram of the classes and properties included in the EPOS-DCAT-AP.

Application Profile Classes

Application Profile Properties per Class

A quick reference table of properties per class is included in 4.37 Quick Reference of Classes and Properties. The list of included properties contains all the properties in [[DCAT-AP]], plus a selection of properties from other vocabularies on which EPOS-DCAT-AP expresses additional constraints or on which EPOS-DCAT-AP wants to emphasise their usage.

Examples on the use of these properties, encoded in [[Turtle]], are included in the relevant sections and available from a separate folder.

SHACL Contraints

The SHACL constraints for EPOS-DCAT-AP are available at:

https://github.com/epos-eu/EPOS-DCAT-AP/blob/EPOS-DCAT-AP-v2.0/docs/epos-dcat-ap_v2.0.0_shacl.ttl

They represent a set of integrity constraints used to validate instance shapes with respect to:

• cardinality constraints, both for properties that have a minimum occurrence greater or equal to than 1 (for example, there needs to be at least one occurrence of the mandatory property title of a Dataset) and properties that have an explicit maximum occurrence (for example, there can be a maximum of one licence for a Distribution)
• restrictions concerning ranges (expressed as sh:nodeKind) of properties to avoid that properties, irrespective of whether they are mandatory, recommended or optional, are provided that violate range declarations.