EPOS-DCAT-AP is an extension of the DCAT Application Profile for Research Infrastructures in Environmental and the solid-Earth domains.
The extension is developed and adopted in the framework of the European Plate Observing System (EPOS) in order to capture the diversity and heterogeneity of the assets provided by the EPOS community.
EPOS-DCAT-AP is based on DCAT-AP and uses or extends additional vocabularies (e.g., Schema.org, Hydra).
This document is the result of a collaborative work involving diverse expertise (scientific, technical, semantic) with the purpose of aligning EPOS-DCAT-AP version 2.0 with DCAT-AP version 3.0.
Disclaimer
The content of this document reflects only the author’s view and EPOS [[EPOS]] is not responsible for any use that may be made of the information it contains.
Overview
This document contains version 3.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.
Context
The European Plate Observing System [[EPOS]] is a pan-European Research Infrastructure (RI) for solidEarth sciences included in the Environmental Research Infrastructure Cluster (ENVRI).
A major challenge in EPOS is the integration of multi-disciplinary, multi-organisational, distributed resources and community resources into a single overarching Research Infrastructure - the EPOS Integrated Core Services (ICS). ICS aggregate
and harmonise descriptions of datasets, data products, software and services provided by different Thematic Core Services (TCS). TCS adopt heterogeneous formats, vocabularies, protocols, and standards to represent and make their assets
available.
In order to capture, organise and harmonise information from different sources and to enable semantic interoperability through exchanges of metadata between ICS and TCS, an application profile based on DCAT-AP has been developed, namely
EPOS-DCAT-AP [[EPOS-DCAT-AP]].
EPOS-DCAT-AP is the result of a collaborative work that brought together diverse expertise which aims at increasing accessibility and usability of multidisciplinary data to researchers and other stakeholders.
EPOS-DCAT-AP is adopted successfully in EPOS, however, the set of requirements addressed make this model suitable to be adopted by other Research Infrastructures and to be applied in different contexts.
Scope of this document
The purpose of this document is to align EPOS-DCAT-AP version 2.0 with DCAT-AP version 3 [[DCAT-AP-3]].
A DCAT-AP extension
The EPOS-DCAT-AP specification is designed as an extension of DCAT-AP in conformance with the guidelines for the creation of DCAT-AP extensions [[DCAT-AP-EG]].
The DCAT-AP Application Profile on which this document is based is the DCAT-AP specification v3 [[DCAT-AP-3]].
Profile Encoding
The encoding of the EPOS-DCAT-AP [[EPOS-DCAT-AP]] provides the technical aspects
used for data representation and exchange, ensuring interoperability. An influential choice for achieving interoperability across diverse systems is the adoption of RDF (Resource Description Framework) and the Turtle format.
RDF's structure allows for a flexible and standardized representation of data, promoting a harmonized approach to information exchange.
The preference for Turtle [[Turtle]] as a data exchange format is based on its simplicity and human-readable nature. This choice is crucial for promoting a consistent and clear representation of data, fitting well with the RDF model.
Finally, a Turtle document serves as a textual representation of an RDF graph, offering a compact yet expressive format for articulating the complexities of the graph. An RDF graph, built on triples consisting of a subject, predicate, and object, forms the backbone of this interoperable and standardized representation.
Profile Validation
To verify if the data exchange is (technically) conformant to DCAT-AP, the Shapes Constraint Language (SHACL) [[SHACL]] is defined.
SHACL is designed to provide constraints and validation for RDF graphs and offering several advantages:
Extensibility: SHACL allows for the precise definition of constraints on RDF data. It is designed to be extensible, enabling users to define custom constraint components, which can be reused across multiple shapes and datasets.
Scalable and efficient: SHACL is structured for efficient validation, making it suitable for use with large datasets and complex data models.
Widely adopted: SHACL is a W3C Recommendation for expressing constraints on a RDF knowledge graph, it enjoys broad support among data management tools and libraries, promoting interoperability and reusability. This makes it a more natural fit for data models that need to interoperate with other semantic web resources and standards.
The SHACL constraints for EPOS-DCAT-AP are available at:
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.
Revision history
In 2023, the adoption of W3C DCAT 3 triggered a new alignment for DCAT-AP. W3C DCAT 3 extends the profile with the Dataset Series notion, deprecates the use of some URIs and introducing new URIs in the DCAT namespace for the use case of Dataset versioning.
Classes alignment EPOS-DCAT-AP v3.0 with DCAT-AP v3.0
Properties alignment EPOS-DCAT-AP v3.0 with DCAT-AP v3.0
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]].
Namespaces
The namespace for EPOS-DCAT-AP is: https://www.epos-eu.org/epos-dcat-ap
The namespace prefix is: epos
The Application Profile reuses terms from various existing specifications, following established best practices [[?DWBP]]. The following table indicates the full list of corresponding namespaces used
in this document.
Application Profile Overview
shows a UML diagram of the classes and properties included in the EPOS-DCAT-AP.
EPOS-DCAT-AP UML Class Diagram
Application Profile Classes
Mandatory Classes
Recommended Classes
Optional Classes
Additional classes for EPOS-DCAT-AP
The following classes are included in [[EPOS-DCAT-AP]]:
Equivalent classes for EPOS-DCAT-AP
The following classes are defined as equivalent classes for [[EPOS-DCAT-AP]]:
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.
Class: Address
Mandatory properties
Example
Class: Agent
Mandatory property
Recommended property
Class: Catalog
Mandatory properties
Recommended properties
Optional properties
Class: CatalogRecord
Mandatory properties
Recommended properties
Optional properties
Class: Category
Mandatory properties
Recommended properties
Optional properties
Example
Class: CategoryScheme
Mandatory properties
Recommended properties
Optional properties
Example
Class: Checksum
Mandatory properties
Class: ContactPoint
Recommended properties
Optional properties
Example
Class: DataService
Mandatory properties
Recommended properties
Optional properties
Example
Class: Dataset
Mandatory properties
Recommended properties
Optional properties
Example
Class: Dataset Series
Mandatory properties
Recommended properties
Optional properties
Class: Distribution
Mandatory properties
Recommended properties
Optional properties
Example
Class: Document
Class: Equipment
Mandatory properties
Recommended properties
Optional properties
Example
Class: Facility
Mandatory properties
Recommended properties
Optional properties
Example
Class: Identifier
Mandatory properties
Example
Class: IriTemplate
Mandatory properties
Optional properties
Example
Class: IriTemplateMapping
Mandatory properties
Recommended properties
Optional properties
Example
Class: Kind
Class: LicenseDocument
Recommended property
Class: Location
Recommended properties
Optional properties
Examples
Class: MediaType
Class: Operation
Recommended properties
Optional properties
Example
Class: Organization
Mandatory properties
Recommended properties
Optional properties
Example
Class: PeriodOfTime
Recommended properties
Optional properties
Example
Class: Person
Mandatory properties
Optional properties
Example
Class: PostalAddress
Mandatory properties
Example
Class: Project
Mandatory properties
Recommended properties
Optional properties
Class: PropertyValue
Mandatory properties
Example
Class: ProvenanceStatement
Class: Publication
Mandatory properties
Recommended properties
Optional properties
Class: Relationship
Mandatory properties
Class: RightsStatement
Class: Standard
Class: Service
Mandatory properties
Recommended properties
Optional properties
Example
Class: SoftwareApplication
Mandatory properties
Recommended properties
Optional properties
Example
Class: SoftwareSourceCode
Mandatory properties
Recommended properties
Optional properties
Example
Quick Reference of Classes and Properties
This version of EPOS-DCAT-AP extends [[DCAT-AP]] with additional classes and properties (some of which re-used across classes). They are listed in the following table marked with a prepended “plus” sign (+).
