This document describes the CIRPASS-2 [[CIRPASS-2]] ontologies for the European Digital Product Passport (DPP). These ontologies provide a structured way to organise the concepts (classes and properties) required to represent the product attributes required by EU DPP regulations. Cross-sectoral concepts, i.e. those that could be applicable to any product group, are described in the EU DPP Core Ontology (CORE). Sector-specific concepts (e.g. for batteries, tyres and textiles) are described in sector-specific ontologies. The CORE ontology adopts a modular architecture. Sector-specific ontologies may or may not adopt a modular approach depending on implementation choice.

Introduction

The objective of the CIRPASS-2 project is to demonstrate Digital Product Passports in real settings thanks to 13 Lighthouse pilots operating in multiple value chains [[CIRPASS-2]]. To facilitate the understanding and exploitation of DPP data, and thus enable the Digital Circular Economy, the project applies strong semantic interoperability principles in its recommended approach to data sharing. To this end, the project has developed several ontologies that provide machine-readable semantic anchors to the exchanged data, to ensure the unambiguous transmission of meaning within and across sectors. They are organised in two levels ():

• the EU DPP Core Ontology (CORE) captures the cross-sectoral concepts identified in the Ecodesign for Sustainable Products Regulation (ESPR) [[ESPR]] and related acts;
• Sectoral ontologies reuse concepts from CORE as needed and extend it with sector-specific concepts.

The expectation is that all product attributes required by sector-specific regulatory acts will be covered by a combination of concepts (classes and properties) from both CORE and the relevant sector-specific ontology.

Architecture

The CORE is the semantic anchor of the sectoral ontologies: a sectoral ontology specialises CORE concepts, or refers to them, instead of redefining them. The ontologies give the meaning of the data. The content expected in a given passport (which data, with which cardinality and datatype) is described in application profiles, DPP templates and SHACL [[SHACL]] shapes, against which DPP data can be validated on the DPP Vocabulary Hub [[DPP-HUB]].

The architecture follows four principles.

• Modularity. Each module covers one aspect of the regulation, following a modular ontology design [[MOMO]]. Modules are developed by different partners and versioned independently.
• Alignment with the CORE. Sectoral ontologies extend, specialise or map CORE concepts rather than duplicating them. Concepts that several sectors need are proposed for the CORE.
• Reuse before creation. Existing vocabularies are reused where possible, for example SI units in the P_DPP module and schema.org in the ACTOR module.
• Traceability. Every term should carry a definition and a reference to its regulatory or domain source.

The EU DPP Core Ontology

The CORE file declares no term: it only imports the modules, using owl:imports [[OWL2-OVERVIEW]] (). Object properties whose domain and range belong to different modules are grouped in a dedicated module, CONNECTOR, so that the other modules do not depend on each other.

Sectoral ontologies

A sectoral ontology reuses the CORE and adds what the sector needs: sector products are declared as subclasses of eudpp:Product, sector characteristics as subclasses of eudpp:Property or of its subclasses, and concepts missing from the CORE are added locally. The method is described in the CIRPASS-2 guidelines for sector ontology engineering, inspired by LOT [[LOT]].

Three ways of attaching to the CORE are in use (): importing the CORE modules, importing MIREOT extracts (Minimum Information to Reference an External Ontology Term) that hold only the CORE terms actually reused, or referring to CORE terms by IRI without importing them. All three keep the sectoral terms aligned with the CORE. With a full import, the CORE axioms are loaded together with the sectoral ones; a MIREOT extract loads only the reused terms; with references by IRI, the sectoral files stay independent of the CORE files, and the battery ontology states in its metadata the CORE versions it was developed against.

Use cases and competency questions

The functional requirements of the CORE are specified as competency questions in its requirements specification [[CO-REQUIREMENTS]]. gives, for the main use cases, examples of questions that each part of the architecture is designed to answer. The compliance questions are among those that guided the design of the COMP module; the others are illustrative. The competency questions have not yet been formally validated against product data.

Reference documentation

Each ontology has a reference page generated from its file. The index page lists them with their IRI, version and number of terms.

References