Digital Product Passports for the Circular Economy

Abstract

As we live in a world of limited resources, the transition from a linear economic model to a circular model is crucial. The Circular Economy (CE) paradigm aims to maintain material continuity through the cycle of production, consumption and recycling. The Digital Product Passport (DPP) is currently recognised as a critical instrument for advancing CE, serving as a comprehensive digital repository for product lifecycle information. The DPP paradigm fosters transparency and traceability. However, so far there is no agreed-upon standard for technically representing and expressing DPPs. This paper aims to provide a comprehensive analysis of the requirements of a general (cross-sectoral) DPP, and to discuss the representation of a core DPP model. We propose to express this in the form of an ontology network, i.e., a formal model serving as a “translation layer” from raw data to interpreted information, along with SHACL shapes for increased data quality and validation. Despite existing research on DPPs, a comprehensive tool enabling this transition into using DPPs is yet to be developed, making this paper a pioneering exploration into the modelling of a DPP core ontology.

-

Germany CEUR ceur-ws.org

1. Introduction

In a world with limited resources transitioning to a Circular Economy (CE) paradigm is crucial, emphasising the continuity of materials through the production-consumption-recycling loop. This involves implementing the “10 R strategies” [ 1 ], such as refusal, reduction, re-use, refurbishment, and recycling, where strategy efectiveness correlates with material circularity [ 1 ]. The CE concept is integral to initiatives like the European Green Deal, Circular Economy Action Plan, and the Ecodesign for Sustainable Products Regulation (ESPR) [ 2 ], with the Digital Product The 2nd International Workshop on Knowledge Graphs for Sustainability (KG4S2024) – Colocated with the 21st Extended Passport (DPP) serving as a digital repository, capturing comprehensive product information throughout its lifecycle, from creation to end-of-life disposition [ 3, 4, 5 ].

A DPP contains information about a product’s components, origin, and environmental and social impacts throughout its lifecycle [ 2 ]. This foundational data supports the development of CE business models, as discussed in [ 5 ]. The primary objectives of a DPP include enhancing the circularity of products through the 10 R strategies and promoting transparency and traceability of products, materials, and components [ 5 ]. Therefore, a DPP is designed to encompass various data, including manufacturing details (composition, materials, process data), usage documentation for replaced or repaired parts, end-of-life information (collection, sorting, treatment), and life-cycle data like sales volume for waste anticipation and resource assessment [ 5 ].

A distinction is often made between the DPPs themselves and DPP systems [ 4, 6 ]. A DPP is the resulting artifact, or document, containing the life-cycle information of a specific product, while a DPP system is responsible for consolidating and enabling the sharing of all the required information for the various DPPs [ 4 ]. Managing the life-cycle information of DPPs and ensuring interoperability among participating actors are crucial steps towards a CE. However, there is currently no tool for this purpose. This paper advocates building an infrastructure for DPP systems on standards, utilising the Web as a data sharing platform, and discusses a DPP ontology as a “translation layer” to enable efective data management and interoperability, aligned with ongoing DPP projects like CIRPASS1. The analysis and ontology in this paper focus on CE information (i.e., information directly supporting the 10 R strategies), with potential coverage expansion in the future, complemented by SHACL shapes for DPP information validation.

The overarching research question is how semantic interoperability and data sharing for DPP systems can be achieved, by means of ontologies and existing Web standards. However, this paper targets the analysis of the potential, feasibility and requirements of a core DPP ontology, as a vocabulary for DPP systems, while the actual data sharing is left for future work. The ontology is a proof-of-concept that shows the feasibility of the approach, but is still work in progress.

Section 2, reviews work on DPP systems and ontologies. Section 3 outlines the methodology, while the ontology requirements and the proposed DPP ontology network are detailed in Section 4. Section 5 outlines a use case application of the DPP ontology. Section 6 deliberates on the results, while Section 7 summarises findings and outlines future work.

2. Related Work

This section presents work related to the methods and results in the paper, first recent work on DPP systems and then specific work on ontologies.

2.1. Digital Product Passport Systems

Within the scientific community, ongoing research in the CE domain focuses primarily on the conceptual design and sector-specific content of DPPs rather than the underlying technical IT infrastructures, i.e., the DPP systems. A comprehensive overview of existing DPP concepts is, for instance, provided in [ 5 ]. One exception, that considers DPP systems specifically, is [ 4 ], in which 1https://cirpassproject.eu/ (accessed on December 7, 2023) several overarching and general DPP system requirements are identified within 8 requirement categories. Another paper that deals with the definition of a DPP ecosystem (DPPE), which can be compared to a DPP system, is [ 6 ]. They state that “a DPPE is a socio-technical system of systems, which is collaboratively owned by the producers, users, and disposers of products” and they describe further, more detailed aspects of their proposed definition in a structured way [ 6 ]. Also relevant is [ 7 ], in which authors introduce their vision of SPACE_DS, a data space tailored to CE data. The concept emphasises the challenges of creating DPPs, particularly due to privacy and security concerns of data providers, and provides valuable insights for the development of an efective DPP system [ 7 ]. While we base our analysis on the results in [ 4 ], neither of the mentioned works detail DPP systems, nor address semantic interoperability specifically.

We conclude that most research on DPPs focus on conceptually framing and defining them, as well their role in the regulatory and business context of CE. Very little attention has been given to DPP systems, and no work so far has addressed the semantic interoperability technically in DPP system implementation. We address this research gap through exploring DPP ontologies.

2.2. Ontology Related Work

To ground our work in related ontologies, we conducted a review of existing work, studying ontologies for the CE and product domains. These two categories were drawn from an ontology study conducted in [ 8 ], which identified four CE ontologies and ten product ontologies. Additionally, the Onto-DESIDE2 project, including its deliverables on the Circular Economy Ontology Network (CEON)3 [ 9 ], is relevant related work. However, CEON focuses on value networks and CE itself, but not on DPPs directly. Therefore, there is a certain overlap between CEON’s objectives and our objectives for modelling DPPs, but it is not congruent. Hence, we use CEON as a potential alignment opportunity4 rather than a starting point.

Reviewing the four CE ontologies, the Building Circularity Assessment Ontology (BCAO) [ 11 ] was considered. However, our analysis revealed misalignments in conceptualisation and scope, particularly in its emphasis on the construction industry. The Circular Materials and Activities Ontology (CAMO) [ 12 ] partially addressed DPP needs but was also confined to the construction industry. The BiOnto ontology [ 13 ], designed for sustainable bioeconomy and bioproducts, was found unsuitable for DPP purposes due to misalignment with the multifaceted DPP requirements. Finally, the Circular Exchange Ontology (CEO) [ 12 ] exhibited partial suitability for DPP integration, focusing on elements crucial for material exchange within the CE. However, CEO is no longer publicly available, whereas we can only use it as inspiration.

Subsequently, our evaluation extended to the ten product ontologies identified in [ 8 ]. The examination of the Product Life Cycle Ontology for Additive Manufacturing (AMO) [14] concluded that its specialised focus on additive manufacturing processes made it unsuitable for general DPPs. The Building Product Ontology (BPO) [15] was considered potentially and partly relevant for DPPs, particularly in the context of describing building products. However, further investigation is needed to assess its applicability outside its sub-domains. Other product ontologies, including CHAMP [16], GRACE [17], ManuService [18], and VERONTO [19], displayed 2https://ontodeside.eu/ (accessed on December 7, 2023) 3http://w3id.org/CEON (accessed on December 7, 2023) 4The initial alignment result between CEON and DPPO is presented in [ 10 ]. potential for describing manufacturing processes, quality control, and product version management if needed as extensions, but not for the core product focus of a DPP. Overall, while these ontologies show some overlap with our work on core DPP concepts, they are all targeted at more specific domains, or focus on much more detailed information than a general DPP model.

BONSAI-core [20] emerged as a promising candidate for DPP modelling, with its core ontology structure aligned, at least partly, with DPP requirements. More precisely, the DPP core ontology can draw inspiration and align with the BONSAI-core ontology, which captures data specifically for life cycle assessment. Additionally, the PRONTO ontology [ 21], tailored for the comprehensive representation of product information, has been shown to handle diverse product structures within the food industry. However, challenges arise concerning its broader reusability beyond this specific domain, posing a noteworthy obstacle for modelling DPPs spanning diverse industries and product types. For instance, while PRONTO goes into great detail on product families and variants, it does not focus on product information and composition to the extent necessary for DPPs. The PSS ontology [22], designed for Product-Service Systems (PSS), focuses on facilitating communication and integration of heterogeneous data during the PSS lifecycle in the manufacturing domain. However, it is unsuitable for DPP purposes because the DPP paradigm encompasses broader aspects related to the product lifecycle, e.g., transparency and traceability, requiring specific considerations that go beyond the scope of the PSS ontology.

Lastly, the United Nations Standard Products and Services Code (UNSPSC)5, while robust in product and service classification, only partially aligns with DPP needs, emphasising the classification of products rather than addressing the specific requirements of DPP data. For instance, product composition and characteristics are not covered.

In summary, analysing CE and product ontologies ofers insights into their suitability for DPP frameworks, yet none fully meet the DPP scope and requirements, in particular in terms of generality and flexibility. Therefore, we develop a proposed DPP core ontology, leveraging strengths and addressing limitations of the 14 reviewed ontologies, but without direct reuse.

3. Methodology

To fill the research gaps we (1) analyse DPP system requirements and use cases, deriving specific ontological requirements, (2) discuss the modelling of a core DPP ontology network.

3.1. Requirements Analysis Methodology

We distinguish between functional and non-functional ontological requirements, where functional requirements specify tasks of the ontology, e.g., support for answering queries or producing inferences. Similar to [23] we distinguish three types of functional requirements, Competency Questions (CQ) [24], Contextual Statements (CS), and Reasoning Requirements (RR), where the two latter complement CQs in terms of further specifying the axioms needed. Nonfunctional requirements cover cross-cutting aspects, e.g., usability, accessibility, provenance.

Initially, a top-down approach was adopted for defining functional and non-functional ontological requirements, drawn from the DPP system requirements in [ 4 ]. First, the requirements 5https://www.unspsc.org (accessed on December 7, 2023) with implications on the DPP representation and contained information were identified. For instance, one such requirement is that the DPP needs to contain information allowing to assess compliance with the ESPR [ 2 ], which in turn includes concrete requirements of identifying product compositions and in particular regarding substances of concern (i.e., hindering recycling). Next, ontology stories were created based on those requirements, inspired by the eXtreme Design (XD) methodology [25]. Three types of actors were identified; authorities, consumers, and value chain actors. Each with their own perspective on the stories. CQs and other requirements, were then derived from the actor-related stories. For instance, regarding the example on substances of concern, all actors need to be able to retrieve data on what substances of concern the product contains. The resulting CQs are discussed further in Sect. 4.1.

To cover more specific product details, subsequently a bottom-up approach was used to elicit additional functional requirements. This involved examining the 10 R strategies in two distinct use cases (loosely based on the use cases in Onto-DESIDE2): one from the textile industry, focusing on shoes’ reuse, repair, and recycling, and the other from the electronics industry, involving smartphones’ reuse, repair, refurbishment, and recycling. The required DPP information was systematically determined for each R strategy and assigned to the corresponding actors of the value chain. Next, also in this case a set of CQs, CSs and RRs were derived.

Results for both approaches have been discussed with experts from diferent domains, e.g., recycling industry and materials design6. The evaluated set of DPP core ontology requirements are briefly presented in Section 4.1, and available as supplementary material.

3.2. Ontology Design

In order to design an ontology based on these requirements, we first considered the nonfunctional requirements, which clearly specify the need for modularity, extensibility, and lfexibility. Consequently, it is essential not to develop a large monolithic ontology, but rather a set of core modules, together with their underlying Ontology Design Patterns (ODP) [26], where modules can be flexibly used, extended, and modified in response to changing legislation and standards in the area. Such an ontology is commonly referred to as an ontology network. Given these observations, we decided to apply an agile and modular ontology engineering methodology, inspired by eXtreme Design (XD) [25], but adapted for the case at hand. More specifically, we started by identifying the core notions to be covered by a DPP ontology, from the set of requirements, e.g., core concepts, such as the DPP itself, the product it describes, product compositions, and categories of information to be contained in a DPP. We then developed a core ODP describing the most central concepts, and subsequently additional modules.

4. DPP Ontology Network

In this section we describe the elicited requirements and the resulting DPP ontology network7. Including a brief mention of the additional SHACL validation for data quality assurance. 6More specifically, for this initial version one domain expert from Ragn-Sells, and one materials modelling expert, neither which where involved in writing the initial CQs. 7The full list of requirements, and the ontology network itself, can be accessed via the DPP ontology landing page https://w3id.org/dppo/ and our public GitHub repository https://github.com/LiUSemWeb/DPPO

4.1. DPP Core Ontology Requirements

Results of the Top-Down Approach: As described in Section 3.1, for the requirements analysis of the DPP core ontology, we first took a top-down approach by deriving functional and non-functional requirements from the DPP system requirements in [ 4 ]. Our results consist of 37 ontology stories including 67 CQs, 3 CSs (duplicates filtered), and 5 RRs (duplicates filtered), constituting the functional requirements. It is important to state, that the ontology stories including their derived CQs (i.e., functional ontology requirements) are role-based, including the perspective of three actor categories: authorities, value chain actors, and consumers. For the non-functional requirements, we identified 13 categories (duplicates filtered), which are not rolebased, where examples include compliance with standards, modularity, and localisation. Some examples of the functional requirements identified, derived through the top-down approach, are provided in the paper appendix, i.e., in Table 1, and the non-functional requirements in Table 2. Results of the Bottom-Up Approach: For the bottom-up approach (described in Section 3.1), we analysed the “10 R strategies” of the two application domains (textile and electronics, using shoes and smartphones as the example products respectively). This resulted in 7 use case scenarios, and a total set of 32 CQs. The full list of the use case specific functional ontology requirements, derived through the bottom-up approach, is available in the supplementary material7. In Table 3 in the appendix, an example is provided, consisting of the CQs and information per value chain actor for the case “repairing of a shoe”. The value chain actors in this case are: material supplier, manufacturer, and repairer. As seen in Table 3, the repairer asks for specific DPP information (c.f. the CQs, which represent functional requirements of DPP ontology) in order to repair a shoe. This required information is provided by previous actors of the shoe’s value chain, i.e., in this case by the material supplier and the manufacturer. Once the shoe has been repaired, the repairer in turn adds information on the repair to the DPP.

4.2. Description of the DPP Ontology Network

Based on the requirements analysis, a first version of a DPP ontology network has been developed and evaluated. The resulting ontology network contains 5 main modules, where one is a basic ODP. Below, we describe each module separately. All the modules and supporting information, including documentation and visualisations, are available online7. An overview of the ontology network is presented in Figure 1.

DPP ODP – The most foundational module is the DPP ODP, merely defining the two main concepts involved and their relation(s), i.e., the Product and DPP concepts. The ODP states that a DPP describes a Product, and that each DPP may have parts that are other DPPs. Similarly, a Product may have parts that are other Products.

DPP Core – The DPP ODP is then detailed by the DPP core module, where diferent kinds of products are considered, as subclasses of Product, i.e., including components, materials, and substances. This conforms to the definitions listed in the ESPR [ 2 ] proposal, stating for instance that a product is “any physical good that is placed on the market or put into service”, and a component is “a product intended to be incorporated into another product”. Materials and substances are merely mentioned in the ESPR [ 2 ], but not defined. However, from the description it is clear that a material can be built up of substances, and materials make up components. Still, since a material is also a physical good that can be sold, depending on the context the material itself may also be considered a product. In the interest of reusability and lfexibility, these classes are therefore not mutually disjoint. For instance, something that is considered a Component from the perspective of one actor may be considered a Material by another. In essence, this core DPP module is not intended to be a prescriptive definition, but rather reflect how the current directives talk about products and DPPs, i.e., a descriptive model.

DPP Information – A key component of the DPP is the information contained inside it. For describing this information, we utilise reification, i.e., expressing the relation between the DPP, and a piece of information about a Product, as a class, i.e., DPPInformation. In this way we are able to describe this relation further. In this module we define 7 subclasses of DPPInformation, c.f. Figure 1. Products may be linked to a characteristic or quality, a concrete value of the characteristic of quality, and potentially a unit of measure. An example could be that a product has a width (characteristic) of 55 (value) mm (unit), which can then be further annotated with the confidence, measurement method etc.

Product Composition – A special case of DPPInformation is the Composition Information, which is detailed in its own module. This information difers from the other types, since it relates two products to each other (e.g., the Product to the Component), i.e., the partonomy of products, also expressed through a property chain axiom on the hasPart relation. In this way, the direct partonomy of the Products can be inferred from the reified relations, represented as CompositionInformation. In addition, this is where one can extend the ontology network with more detailed compositions, such as chemical compositions of materials and substances. However, for now the focus is on CE-related concepts, such as SubstanceOfConcern, as specified by the ESPR [ 2 ].

DPP Provenance – A module for tracking provenance of DPPs and DPP information, has been included, relating to requirements on being able to track the actors responsible for certain data, as well as timestamps for information validity (immutable statements).

4.3. SHACL Validation

While the ontology modules describe the domain, and can be used to set the general structure of DPPs, they are less suitable for data validation. Acknowledging the need for high quality data, we define a set of SHACL shapes to verify the (structural) validity of DPP information, applicable without employing OWL reasoning. This is similar to [27], where SHACL shapes were proposed as a way of ensuring the consistency of form-based data input for Asset Administration Shell (AAS) [28] submodel templates. The shapes are defined based on a set of assumptions, such as: (1) a DPP must be defined for exactly one product, (2) a DPP must refer to at least one piece of information, (3) a DPP can have multiple DPPs as parts. The full set of shapes resides in the project repository7, but an example is presented in Listing 1 in the appendix.

5. Use Case and Evaluation

In this section we first present a validation in relation to the requirements derived from DPP system requirements and the two use cases. Then we apply the DPP ontology network for annotating data in the context of flat-glass recycling at Ragn-Sells AB 8.

5.1. Requirements Verification

Non-Functional Requirements – Assessing the fulfilment of non-functional requirements is not straight-forward, but in this section we discuss each of the 13 identified non-functional requirements in relation to the DPP ontology network. A number of the requirements are covered through the choice of ontologies, expressed using Web standards, e.g., req. #2 (webstandards), #7 (flexible data model), #6 (dereferencable identifiers), and #9 (in the case of machine usability). Additionally, the requirement #10 (localisation) follows from the use of RDF(S), which allows labels and comments including a language tag, enabling querying based on the language of the information. Further, also the FAIR (Findable, Accessible, Interoperable and Reusable) [29] publishing (#5) is supported by Web standards, together with publishing best practices. 8https://www.ragnsells.com/ (accessed on December 7, 2023)

Requirements related to usability and best practices (#3, #4), are covered through careful documentation of the ontologies, as well as the use of ODPs. For human usability, it is also important to keep the ontology modules small and without excessive complexity. Regarding the ontology best practices (#3), in addition we have used naming conventions, versioning schemes, and permanent dereferencable URIs, etc., all part of best practices.

Regarding the structure and content of the ontology network, choosing an ontology network and not a monolithic ontology is related both to requirements #8 (modularity) and #9 (extensibility and evolvability). Concerning the content of the modules, we have added a specific module on metadata (e.g., provenance) covering #11. Also the requirement of immutable statements (#5) is covered by the provenance module, since it enables stating valid time periods of statements, allowing to keep information even when invalidated. Further, #1 (compliance with regulations) is ensured by the functional requirements being derived from regulations themselves.

The only requirement not covered is the verifiable metadata (#12), where metadata is made available, but where the verification is considered outside the scope, but could be represented as annotations. Additionally, the use and compliance with CE standards (part of #2), needs to be continuously verified, since these standards are still emerging.

Functional Requirements – As verification of the functional requirements, we mapped each CQ to one (or more) SPARQL queries defined using the ontology vocabulary. In total, we document a set of 29 SPARQL queries covering 78 of the CQs defined. 21 CQs were left for future work due to lack of coverage (or only partial coverage) in the ontology. The full set of SPARQL queries is available in the project GitHub repository7.

5.2. Use Case Validation

While the verification that the ontology network fulfills its requirements provides important evidence regarding its applicability and usefulness to support the implementation of DPP systems, it still remains to apply the ontology network at scale and across industry sectors. In this paper we illustrate the applicability by means of a specific use case from the construction domain. For this purpose we use the case of flat glass recycling, which is currently a process being implemented by the recycling company Ragn-Sells AB8 in Sweden. This process enables high quality flat glass to be recycled with maintained quality instead of ending up in landfill. In this case a window constitutes the product in focus, and the intended R-strategy is the recycling of the glass pane of the window. From the perspective of the recycler, i.e., Ragn-Sells, there are several questions that the DPP of a window needs to be able to answer. Some examples are9: (1) What is the type of glass? (2) What is the frame material? (3) Does the window contain any substances of concern - which? (4) Is there a film mounted on the glass? (5) What are the dimensions of the window? (6) Who is the manufacturer responsible for the data?

While the first four questions are intended to assess the recyclability of the window, the fith provides important information for the collection and transport to the recycling facility. The last question is about the provenance of the data, e.g., both for establishing trust, and to be able to contact the organisation in case of missing data. In Figure 2 in the appendix, an example DPP of a window, answering the first three questions is illustrated. The DPP of a window consists 9This is a small excerpt of the actual set of questions, which are being explored in a related project, c.f. Trace4Value: https://trace4value.se/ of two sub-DPPs, where the glass DPP is published by the flat glass manufacturer, the frame DPP is published by the window manufacturer, and so is the overall window DPP. Hence, in the decentralised DPP system scenario, the window and frame DPPs might reside in the data storage of the window manufacturer, while the glass DPP might be stored with the glass manufacturer and merely retrieved on-demand using a query. All annotations, such as labels, and timestamps, have been omitted for readability. It was concluded that the ontology can successfully describe all the necessary data to answer the listed CQs, and the ontology was therefore well-received by Ragn-Sells in their modelling of the flat-glass recycling data.

6. Discussion

This paper presents a first efort in modelling an ontology network for DPP systems. We position our DPP ontology as a preliminary version, acknowledging that it is neither finished nor holistic. The primary objective of this paper was to delineate the challenges inherent in DPP system development, identify key requirements, and discuss the modelling of a core DPP model that acts as a “translation layer” from raw data to interpreted DPP information. Recognising that the DPP ontology presented is a proof-of-concept solution, it still highlights the complexity of the requirements and the modelling decisions involved. While the DPP plays a pivotal role in advancing CE principles, this paper underscores the need for a comprehensive tool to facilitate the transition to using DPPs efectively. It advocates semantic interoperability and data sharing using ontologies and existing Web standards, aligning with ongoing DPP projects such as CIRPASS1 and Onto-DESIDE2. Overall, we believe that ontologies will play a crucial role in realising the vision of general cross-domain DPPs, and the CE as a whole. With our work as the starting point, we can thereby accelerate the transition towards a scalable CE. In summary, our DPP ontology represents a significant first step towards large-scale DPP system implementation, endorsed by positive feedback from recycling industry experts confirming its practical utility.

7. Conclusions and Future Work

Our exploration into the modelling of a DPP core ontology addresses the question of whether ontologies present a feasible approach for DPP system development, in particular for the challenge of semantic interoperability of DPP data. Our proposed DPP ontology network serves as a proof-of-concept, demonstrating the feasibility and potential for ontologies and existing Web standards to enhance semantic interoperability, a crucial component of successful DPP system implementation. We therefore conclude that relying on existing Web standards and best practices is essential. In the future, refinement of the DPP ontology to encompass further DPP requirements is planned (c.f. Section 5.1), as well as alignments to other existing ontologies.

Acknowledgments

This research was supported by the Vinnova-funded project Trace4Value (Dnr. 2021-04323) and the Digital Europe Program project CIRPASS, as well as the Onto-DESIDE project (grant agreement no. 101058682) from the European Union’s Horizon Europe research and innovation programme.

A. Appendix

Actor Perspective Authority

Examples of identified functional DPP core ontology requirements from the top-down approach. # 1. 2. 3. 4. 5. 6. 7.

Req.

Compliance with regulations Compliance with standards Follow best practices Usability (humans & machines) FAIR publishing Dereferencable identifiers Flexible data model # 10. 11. (1) Are there any instructions on how to repair the product? (2) What are the single components of this product? (3) What are the charecteristics of the components? (4) How can the product be disassembled (if needed)? (5) Which spare parts fit the repairing of the product? (6) What is the material composition of the spare parts? Repairer Manufacturer Material Supplier Shoe repair use case: CQs and provided information per value chain actor.

Provides information on: what was broken, what part/component of the product was repaired or replaced, what new components were inserted (if any) and their composition, how was it repaired, by whom, and when Manufacturer of product: Repair instructions (1,5), list of components and their characteristics (2,3), information on the assembly of the components (4).

Manufacturer of the spare parts: DPP of spare parts, with their components and material composition (6) Compostition of materials for original components (3) and spare parts (6)

window_X rdf:type rdf:type material_ALU

rdf:type aboutPart aboutWhole aboutPart aboutWhole aboutWhole aboutPart

owner describes owner frame_DPP contains Information

DPP glass_DPP rdf:type comp_4 rdf:type Composition

Information

Listing 1: The SHACL shape used to validate the main part of a DPP, i.e., instance of the DPP class (prefixes left out for brevity). <DPP-Shape> a sh:NodeShape ; sh:targetClass dpp-odp:DPP ; sh:property [ sh:path dpp-info:containsInformation ; sh:minCount 1; sh:class dpp-info:DPPInformation ] ; sh:property [ sh:path dpp-odp:describes ; sh:minCount 1; sh:maxCount 1; sh:class dpp-odp:Product ] ; sh:property [ sh:path dpp-odp:hasPart ; sh:class dpp-odp:DPP ] .

References

[1] M. Pourjafarian , C. Plociennik , M. H. Rimaz , et.al., A Multi-Stakeholder Digital Product Passport Based on the Asset Administration Shell , in: 2023 IEEE 28th International Conf. on Emerging Technologies and Factory Automation (ETFA) , 2023 , pp. 1 - 8 . doi: 10 .1109/ ETFA54631. 2023 . 10275715 .

[2] Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL establishing a framework for setting ecodesign requirements for sustainable products and repealing Directive 2009 /125/EC, 2022 . URL: https://eur-lex.europa.eu/legal-content/EN/ TXT/?uri=CELEX: 52022PC0142 .

[3] M. Jansen , B. Gerstenberger , J. Bitter-Krahe , H. Berg , J. Sebestyén , J. Schneider , Current approaches to the digital product passport for a circular economy : an overview of projects and initiatives , Technical Report, Wuppertal Institut für Klima , Umwelt, Energie, 2022 . doi: 10 .48506/opus- 8042.

[4] M. Jansen , T. Meisen , C. Plociennik , H. Berg , A. Pomp , W. Windholz, Stop Guessing in the Dark: Identified Requirements for Digital Product Passport Systems , Systems 11 ( 2023 ) 123 . doi: 10 .3390/systems11030123.

[5] C. Plociennik , M. Pourjafarian , et.al., Requirements for a Digital Product Passport to Boost the Circular Economy , in: D. Demmler , D. Krupka , H. Federrath (Eds.), INFORMATIK 2022 , Gesellschaft für Informatik , Bonn, 2022 , pp. 1485 - 1494 . doi: 10 .18420/inf2022_ 127 .

[6] M. R. N. King , P. D. Timms , S. Mountney , A proposed universal definition of a Digital Product Passport Ecosystem (DPPE): Worldviews, discrete capabilities, stakeholder requirements and concerns , Journal of Cleaner Production 384 ( 2023 ) 135538 . doi: 10 .1016/j.jclepro. 2022 . 135538 .

[7] A. Pomp , M. Jansen , H. Berg , T. Meisen, SPACE_DS: Towards a Circular Economy Data Space , in: Companion Proceedings of the ACM Web Conference 2023 , Association for Computing Machinery, 2023 , p. 1500 - 1501 . doi: 10 .1145/3543873.3587685.

[8] H. Li , M. Abd Nikooie Pour , Y. Li , M. Lindecrantz , E. Blomqvist, P. Lambrix , A Survey of General Ontologies for the Cross-Industry Domain of Circular Economy , in: Companion Proceedings of the ACM Web Conference 2023 , WWW '23 Companion, Association for Computing Machinery, 2023 , pp. 731 - 741 . doi: 10 .1145/3543873.3587613.

[9] E. Blomqvist , H. Li , R. Keskisärkkä , M. Lindecrantz , M. Abd Nikooie Pour , Y. Li , P. Lambrix , Cross-domain Modelling-A Network of Core Ontologies for the Circular Economy , in: Proceedings of the 14th Workshop on Ontology Design and Patterns (WOP 2023 ), 2023 .

[10] H. Li , E. Blomqvist , P. Lambrix , Initial and Experimental Ontology Alignment Results in the Circular Economy Domain , in: Proceedings of the 2nd International Workshop on Knowledge Graphs for Sustainability (KG4S2024) , CEUR-WS.org , 2024 .

[11] L. Morkunaite , F. H. Al-Naber , E. Petrova , K. Svidt , An Open Data Platform for Early-Stage Building Circularity Assessment: The Joint Conference CIBW 78 - LDAC 2021 , Proceedings of the 38th International Conference of CIB W78 ( 2021 ) 813 - 822 .

[12] E. Sauter , R. Lemmens , P. Pauwels, CEO and CAMO ontologies: a circulation medium for materials in the construction industry , in: 6th International Symposium on Life-Cycle Civil Engineering (IALCCE) , CRC Press, 2018 , pp. 1645 - 1652 .

[13] C. Bicchielli , N. Biancone , F. Ferri , P. Grifoni, BiOnto: An Ontology for Sustainable 8 .