SIST EN 18223:2026
(Main)Digital Product Passport - System interoperability
- Abstract
The scope of this document includes:
- the semantic description of a product, including its properties where relevant and the semantic aspects to represent the product lifecycle;
- a common information model allowing for the implementation of data dictionary systems;
- metadata models and formats to be used in exchange and representation, allowing for the integration of dictionaries;
- rules on how to systematically use such metadata models when developing product group specific data models and dictionaries;
- technical and organizational interoperability.
This document follows the approach of standard interoperability layers and proposes the following aspects in this regard.
- Status
- Published
- Public Enquiry End Date
- 18-Sep-2025
- Publication Date
- 15-Jun-2026
- Technical Committee
- DPP - Digital Product Passport
- Current Stage
- 6060 - National Implementation/Publication (Adopted Project)
- Start Date
- 05-Jun-2026
- Due Date
- 10-Aug-2026
- Completion Date
- 16-Jun-2026
(EU) 2024/1781 - Regulation (EU) 2024/1781 of the European Parliament and of the Council of 13 June 2024 establishing a framework for the setting of ecodesign requirements for sustainable products, amending Directive (EU) 2020/1828 and Regulation (EU) 2023/1542 and repealing Directive 2009/125/ECText with EEA relevanceOJ Ref: OJ L, 2026/1736 OJ Date: 15-Jul-2026
SIST EN 18223:2026 is the Slovenian standard identical to EN 18223:2026, a European Standard from CEN on Digital Product Passport - System interoperability. It specifies how a digital product passport can be described semantically and serialized technically so product data can be exchanged, linked to data dictionaries, and used across systems by actors involved in a product's life cycle.
What does SIST EN 18223:2026 specify?
SIST EN 18223:2026 specifies the interoperability layer for the Digital Product Passport (DPP). It covers the semantic description of a product, a common information model for data dictionaries, metadata models and formats for exchange and representation, rules for using those metadata models in product-group-specific models, and technical and organizational interoperability.
The document is organized into five clauses and three annexes. Clause 4 sets out semantic interoperability, Clause 5 sets out technical interoperability, Annex A gives the expanded JSON data model, Annex B gives the compressed XML data model, and Annex ZA links the standard to EU ecodesign requirements.
| Annex | What it covers |
|---|---|
| Annex A | Expanded full data model serialized in JSON |
| Annex B | Data model compressed serialization in XML |
| Annex ZA | Relationship with the essential requirements of (EU) Regulation 2024/1781 |
What are the key requirements of SIST EN 18223:2026?
The DPP semantic model is the core structure
Clause 4 models a DPP as a DigitalProductPassport container that can hold zero or more DataElement entries. In practice, this is the structure that lets a product passport carry both simple facts and nested groups of information in a consistent way.
The standard uses UML class diagrams to show the model, but Clause 4 says the prose text and tables are authoritative if there is any mismatch with the diagrams or JSON view. That matters when teams implement a schema, because the written rules govern the final structure.
The DPP header has defined attributes
Clause 4.1.2.1 states which attributes shall be published for each DPP instance, including digitalProductPassportId, uniqueProductIdentifier, granularity, dppSchemaVersion, dppStatus, lastUpdated, economicOperatorId, facilityId, contentSpecificationIds, and DataElement content. The digitalProductPassportId shall be globally unique and should be based on a URI/URL structure.
This is important in practice because implementers need a stable identifier, a traceable link to the product, and a way to show the passport's version, status, ownership context, and scope. The standard also fixes granularity to model, batch, or item, which tells users how specific the passport is.
Data elements are organized by type
Clause 4.1.2.3 to 4.1.2.8 defines the main data element types: DataElementCollection, SingleValuedDataElement, MultiValuedDataElement, RelatedResource, and MultiLanguageDataElement. elementId shall identify a data element within its local context, and dictionaryReference links it to the semantic definition stored in a repository.
This matters because the standard separates the data point from its definition. That makes it easier to reuse definitions across product groups and to keep passport instances lighter by avoiding repeated semantic text.
Collections, lists, documents and multilingual values each have a different role
DataElementCollection groups named elements and can contain nested collections, single values, lists, and related resources. MultiValuedDataElement contains multiple items of the same type, while RelatedResource is used for documents or certificates and carries a MIME content type, a URL, and an optional language and title. MultiLanguageDataElement stores language-dependent values together with language tags.
For implementers, this means the standard distinguishes between a group of fields, a repeated list, an external file, and the same meaning expressed in several languages. That distinction helps avoid ambiguous data structures in a product passport.
Value typing follows controlled XML Schema rules
Clause 4.1.2.9 allows valueDataType to use XSD data types aligned with W3C XML Schema, with some exclusions. The standard also allows base64 binary support.
This is practical for interoperability because data types have to be predictable across JSON and XML exchanges. Teams need to map their internal values to the allowed types so different systems interpret dates, numbers, URIs, and binary content in the same way.
DPP changes must be tracked and archived
Clause 4.2 says that changes made during the lifetime of a DPP shall be logged and archived according to EN 18221:2026. The change record includes the identifier, timestamp, actor, and changed properties.
This means a passport is not treated as a static file. Users need a change trail for updates to product properties, document replacements, or newly added information, which supports traceability and archiving over time.
Semantic definitions live in repositories
Clause 4.3 describes a decoupled repository model for data dictionaries. Each data point should reference a machine-readable semantic definition stored in a repository, with unique identifiers and unambiguous occurrence inside that repository.
In practice, this allows cross-sector interoperability and mapping between different catalogues. It also supports multilingual use and controlled value lists, while keeping the operational DPP payload smaller.
Technical interoperability defines serialization
Clause 5 says serialization shall follow the Clause 4 model, and the data syntaxes are defined in EN 18216. The standard uses PascalCase for UML classes and camelCase for JSON, XML and UML attributes.
Clause 5 also says an optimized representation can use elementId as the JSON object key, while dictionaryReference and valueDataType stay in external data dictionaries. Annex A provides expanded JSON examples, and Annex B provides compressed XML examples.
What terms does SIST EN 18223:2026 define?
- Interoperability - the ability of entities to exchange items through agreed rules and mechanisms so they can perform their tasks.
- Semantic interoperability - the ability for data shared by systems to be understood as fully defined domain concepts.
- Technical interoperability - the ability that covers the applications and infrastructures linking systems and services.
- Digital Product Passport (DPP) - a digital record of product characteristics throughout its life cycle.
- DPP ID - the unique identifier of one DPP instance.
- DataElement - the abstract base concept for a data point used in the DPP model.
- RelatedResource - a data element used to represent a document or certificate that belongs with the DPP.
- MultiLanguageDataElement - a data element whose value varies with the language associated with it.
Who uses SIST EN 18223:2026?
SIST EN 18223:2026 is aimed at people and systems that create, exchange, manage, or consume DPP data. The introduction names economic operators, manufacturers, distributors, repairers, recyclers and consumers as users of DPP information across value chains.
It is also relevant for software teams, data modelers, standards developers, and organizations building repositories or product-group-specific dictionaries. Clause 5.1 also refers to notified actors, systems and processes involved with the DPP, so the document is useful for integration work, schema design, and implementation of exchange formats.
Which standards are used with SIST EN 18223:2026?
| Standard | What it contributes |
|---|---|
| ISO 8601-1:2019 | Date and time representation used for lastUpdated and other timestamps |
| EN 18219:2026 | Unique identifiers used for products, actors, and facilities |
| EN 18221:2026 | Logging and archiving of DPP changes |
| EN 18216 | Data exchange protocols and data syntaxes used for serialization |
| EN 18220 | Data carriers, named in the DPP standards set in the introduction |
| EN 18222:2026 | APIs for DPP lifecycle management and searchability |
| EN 18239:- | Access rights management, information system security, and business confidentiality |
| EN 18246:- | Data authentication, reliability and integrity |
| ISO/IEC 19505-2 | UML class diagrams used to present the semantic model |
| ISO/IEC 21778:2017 | JSON data interchange syntax used in the serialization rules |
What does the SIST EN 18223:2026 document contain?
The document contains the DPP semantic model, attribute tables for the main classes, and rules for data element types such as collections, single values, multi-valued lists, related resources, and multilingual values. It also includes the allowed value types and the repository approach for linking data points to semantic definitions.
For technical implementation, it provides JSON and XML serialization guidance, naming conventions, and mapping rules between XSD types and JSON types. Annex A and Annex B give worked examples of expanded JSON and compressed XML structures for design and testing work, while Annex ZA maps the standard to EU Regulation 2024/1781.
Get Certified
Connect with accredited certification bodies for this standard
BSI Group
BSI (British Standards Institution) is the business standards company that helps organizations make excellence a habit.
Bureau Veritas
Bureau Veritas is a world leader in laboratory testing, inspection and certification services.
DNV
DNV is an independent assurance and risk management provider.
Sponsored listings
Frequently Asked Questions
SIST EN 18223:2026 is a standard published by the Slovenian Institute for Standardization (SIST). Its full title is "Digital Product Passport - System interoperability". This standard covers: The scope of this document includes: - the semantic description of a product, including its properties where relevant and the semantic aspects to represent the product lifecycle; - a common information model allowing for the implementation of data dictionary systems; - metadata models and formats to be used in exchange and representation, allowing for the integration of dictionaries; - rules on how to systematically use such metadata models when developing product group specific data models and dictionaries; - technical and organizational interoperability. This document follows the approach of standard interoperability layers and proposes the following aspects in this regard.
The scope of this document includes: - the semantic description of a product, including its properties where relevant and the semantic aspects to represent the product lifecycle; - a common information model allowing for the implementation of data dictionary systems; - metadata models and formats to be used in exchange and representation, allowing for the integration of dictionaries; - rules on how to systematically use such metadata models when developing product group specific data models and dictionaries; - technical and organizational interoperability. This document follows the approach of standard interoperability layers and proposes the following aspects in this regard.
SIST EN 18223:2026 is classified under the following ICS (International Classification for Standards) categories: 13.020.20 - Environmental economics. Sustainability; 35.240.63 - IT applications in trade. The ICS classification helps identify the subject area and facilitates finding related standards.
SIST EN 18223:2026 is associated with the following European legislation: EU Directives/Regulations: 2024/1781, (EU) 2024/1781, EUR-PUB; Standardization Mandates: M/604, M/604 AMD 1. When a standard is cited in the Official Journal of the European Union, products manufactured in conformity with it benefit from a presumption of conformity with the essential requirements of the corresponding EU directive or regulation.
SIST EN 18223:2026 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
SLOVENSKI STANDARD
01-julij-2026
Digitalni potni list izdelka - Interoperabilnost sistema
Digital Product Passport - System interoperability
Digitaler Produktpass - System-Interoperabilität
Passeport numérique des produits - Interopérabilité du système
Ta slovenski standard je istoveten z: EN 18223:2026
ICS:
13.020.20 Okoljska ekonomija. Environmental economics.
Trajnostnost Sustainability
35.240.63 Uporabniške rešitve IT v IT applications in trade
trgovini
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EUROPEAN STANDARD EN 18223
NORME EUROPÉENNE
EUROPÄISCHE NORM
May 2026
ICS 13.020.20
English version
Digital Product Passport - System interoperability
Passeport numérique des produits - Interopérabilité Digitaler Produktpass - System-Interoperabilität
du système
This European Standard was approved by CEN on 3 May 2026.
This European Standard was corrected and reissued by the CEN-CENELEC Management Centre on 2 June 2026.
CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and United Kingdom.
CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2026 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 18223:2026 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Semantic interoperability . 6
4.1 Semantic model . 6
4.1.1 General . 6
4.1.2 Semantic model of the digital product passport . 6
4.2 Data model requirements to manage DPP changes .12
4.3 Model for repositories for the data dictionaries .12
5 Technical interoperability .13
5.1 General .13
5.2 Serialization syntax .13
5.2.1 General .13
5.2.2 Naming conventions and built-in types .13
5.2.3 JSON built-in types for values .13
5.2.4 Serialization of the DigitalProductPassport class .14
5.2.5 Serialization of a DataElementCollection .14
5.2.6 Serialization of a SingleValuedDataElement .15
5.2.7 Serialization of a MultiValuedDataElement .15
5.2.8 Serialization of a RelatedResource .16
5.2.9 Serialization of a MultiLanguageDataElement .16
Annex A (normative) Expanded full data model serialized in JSON.17
Annex B (normative) Data model compressed serialization in XML .21
Annex ZA (informative) Relationship between this European Standard and the essential
requirements of (EU) Regulation 2024/1781 aimed to be covered .24
Bibliography .25
European foreword
This document (EN 18223:2026) has been prepared by Technical Committee CEN/CLC/JTC 24 “Digital
product passport – Framework and system”, the secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by November 2026, and conflicting national standards shall
be withdrawn at the latest by November 2026.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request addressed to CEN by the European
Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
Member States.
For relationship with EU Legislation, see informative Annex ZA, which is an integral part of this document.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the United
Kingdom.
Introduction
0.1 Background
A digital product passport (DPP) is a key enabling mechanism to make product information traceable and
accessible across value chains - supporting economic operators, manufacturers, distributors, repairers,
recyclers and consumers to make informed decisions and to support a circular economy. The
implementation of digital product passports will be carried out progressively. Sector-specific initiatives
will determine the precise DPP content and requirements for individual product groups.
To support the implementation of DPPs, 8 standards have been developed so far:
— EN 18219:2026 – Digital product passport – Unique identifiers
— EN 18220:2026 – Digital product passport – Data carriers
— EN 18216:2026 – Digital product passport – Data exchange protocols
— EN 18222:2026 – Digital Product Passport – Application Programming Interfaces (APIs) for the
product passport lifecycle management and searchability
— EN 18223:2026 – Digital Product Passport – System interoperability (this document)
— EN 18221:2026 – Digital product passport – data storage, archiving, and data persistence
— EN 18239:— – Digital Product Passport – access rights management, information system security,
and business confidentiality
— EN 18246:— – Digital Product Passport – Data authentication, reliability and integrity
0.2 Organizational interoperability
Organizational interoperability covers the following aspects:
— easy integration into existing technology frameworks;
— human and machine (software) access.
0.3 Semantic interoperability
Semantic interoperability covers the following aspects:
— allow data structuring with standardized or established data schema languages;
— enable the usage and re-usage of known ontologies or context namespaces;
— avoid sector specific ontologies – allow parallel usage of different ontologies issued by the European
Commission in delegated acts with a horizontal layer as general as possible (technology, ontology and
domain agnostic).
0.4 Technical interoperability
Serialization of data with standardized data format.
Under preparation. Stage at the time of publication: prEN 18239:2025.
Under preparation. Stage at the time of publication: prEN 18246:2025.
1 Scope
The scope of this document includes:
— the semantic description of a product, including its properties where relevant and the semantic
aspects to represent the product lifecycle;
— a common information model allowing for the implementation of data dictionary systems;
— metadata models and formats to be used in exchange and representation, allowing for the integration
of dictionaries;
— rules on how to systematically use such metadata models when developing product group specific
data models and dictionaries;
— technical and organizational interoperability.
This document follows the approach of standard interoperability layers and proposes the following
aspects in this regard.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 8601-1:2019, Date and time — Representations for information interchange — Part 1: Basic rules
EN 18219:2026, Digital product passport - Unique identifiers
EN 18221:2026, Digital product passport - data storage, archiving, and data persistence
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at http://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.1
interoperability
capability of two or more entities to exchange items in accordance with a set of rules and mechanisms
implemented by an interface in each entity, in order to perform their specified tasks
[SOURCE: ISO 18435-1:2009 [1], 3.12]
As impacted by ISO 8601-1:2019/A1:2022.
3.2
semantic interoperability
ability for data shared by systems to be understood at the level of fully defined domain concepts
[SOURCE: ISO 18308 [2], 3.45]
3.3
technical interoperability
ability that covers the applications and infrastructures linking systems and services
3.4
digital product passport
DPP
digital record of product characteristics throughout its life cycle
Note 1 to entry: Example characteristics include environmental sustainability, environmental impact, and
recyclability.
3.5
digital product passport id
DPP ID
unique identifier of an instance of the digital product passport
4 Semantic interoperability
4.1 Semantic model
4.1.1 General
This document uses UML class diagrams ISO/IEC 19505-2 [3] to illustrate the core concepts of a product
and DPP, their data, properties and their relationships. A JSON representation is provided in Clause 5. If
there are discrepancies between the UML diagrams, text and JSON representations the prose text of
Clause 4, including the tables, is authoritative.
4.1.2 Semantic model of the digital product passport
4.1.2.1 Digital product passport
The model presented below in Figure 1 defines what the entities are that compose a digital product
passport instance and the data points it is required to include.
Figure 1 — UML representation of the entities of the semantic model of the DPP
Figure 1 presents the base semantic model of a digital product passport.
The digital product passport is modelled through the class DigitalProductPassport as a digital container
that contains zero to many DataElements.
The model is structured based on the following principles:
— DataElement is an abstract class. It represents the generic concept of a data point. As an abstract class,
it is the common superclass for all other classes, and it is never used directly in a DPP instance.
— DataElementCollection: A concrete subclass of DataElement (see 4.1.2.3) that acts as a container for a
set of other named DataElements. This allows for creating complex structures with mixed data types,
as it can contain SingleValuedDataElements (see 4.1.2.5), MultiValuedDataElements (see 4.1.2.6),
RelatedResource (see 4.1.2.7), and other nested DataElementCollections (see 4.1.2.4).
— SingleValueDataElement: This is the simplest concrete subclass of DataElement. It represents a single
unit of information (see 4.1.2.5).
— MultiValuedDataElement: A concrete subclass of DataElement that contains an ordered list of other
DataElements, all of which shall be of the same type. For example, it can contain a list of
SingleValueDataElements (like an array of numbers) or a list of DataElementCollections (like an array
of similar objects) (see 4.1.2.4).
— Other Concrete subclasses: MultiLanguageDataElement (see 4.1.2.8) and RelatedResource (see
4.1.2.7) are other specialized subclasses of DataElement, used for representing a value in multiple
languages or linking to an external resource, respectively.
The following data points (see Table 1) shall be published as attributes of a digital product passport
instance:
Table 1 — Attributes of the DigitalProductPassport class
Attribute name Description DataType Cardinality
digitalProductPassportId unique identifier of an String [1]
instance of the digital
product passport
uniqueProductIdentifier unique string of characters String formatted according [1]
for the identification of a to EN 18219:2026
product, that also enables a
web link to the digital
product passport
granularity level of granularity of the Enumeration [1]
uniqueProductIdentifier
according to 4.1.2.2
dppSchemaVersion reference standard the String [1]
DPP instance schema
refers to
dppStatus status of the DPP instance String [1]
as digital resource
lastUpdated date and time of the latest String formatted as [1]
update to the DPP instance Timestamp
UTC- based according to
ISO 8601-1:2019
economicOperatorId unique string of characters String formatted according [1]
for the identification of an to EN 18219:2026
actor involved in a
product’s life cycle
facilityId unique string of characters String formatted according [0.1]
for the identification of to EN 18219:2026
locations or buildings
involved in a product’s
value chain or used by
actors involved in a
product’s life cycle
contentSpecificationIds reference to horizontal or String [0.*]
product-type related
content specifications for
the DPP
{DataElement} data elements of DPP DataElement (abstract) [0.*]
as per 4.1.2.3
EXAMPLE Example values for the “dppStatus” attribute are:
— active,
— inactive,
— archived,
— invalid
Any further enumeration value provided by relevant legal acts.
The digitalProductPassportId shall be globally unique and should be based on a URI/URL structure.
{DataElement} is a placeholder for additional content or other attributes of the DPP. The notation
{} means that the naming is not fixed. This includes data points mentioned in ESPR [4], Annex III
and not included in Table 1.
4.1.2.2 Enumeration
Some of the attributes required by the DigitalProductPassport class are enumerations whose values are
predetermined.
The values allowed for the “granularity” attribute are:
— model,
— batch,
— item.
4.1.2.3 DataElement
The DataElement is an abstract class which is the base class for its concrete subclasses:
DataElementCollection (4.1.2.4) SingleValuedDataElement (4.1.2.5), MultiValuedDataElement (4.1.2.6),
RelatedResource (4.1.2.7) and MultiLanguageDataElement (4.1.2.8). It specifies the following attributes
(see Table 2).
Table 2 — Definition of DataElement attributes
Attribute Name Description Datatype Cardinality
The relative identifier of the
DataElement shall be unique
within its location (i.e. in the
DPP or in the level of
DataElementCollection or
elementId MultiValuedDataElement) and it String [1]
is recommended to be unique
in the DPP instance. The
corresponding absolute path of
the data element shall be
unique within the DPP instance.
The reference to the unique
[0.1]
identifier of the data point
dictionaryReference String
specification defined in the
repository/data dictionary
4.1.2.4 DataElementCollection
The DataElementCollection is a collection of DataElements included in the digital product passport entity.
It contains at least one DataElement. This class inherits the attributes elementId and dictionaryReference
from the abstract DataElement class.
The DataElementCollection is an object and as such it can contain semantically different objects. A
DataElementCollection shall contain at least one instance of a DataElement's subclasses
(DataElementCollection, SingleValuedDataElement, MultiValuedDataElement or RelatedResource).
4.1.2.5 SingleValuedDataElement
The SingleValuedDataElement represents a single data point with one value. This class inherits the
attributes elementId and dictionaryReference from the abstract DataElement class and adds the following
specific attributes (see Table 3).
Table 3 — Definition of SingleValuedDataElement attributes
Name Description Datatype Cardinality Example
Contains the data < any JSON
of the value datatype > as
value [1]
encapsulated in described in
the DataElement Clause 5
Specifies the data
type of the value String as
valueDataType needed for the described in [0.1] “xsd:integer”
interpretation of 4.1.2.9
the value data
4.1.2.6 MultiValuedDataElement
The MultiValuedDataElement is a list which contains similar objects of the same data type.
It contains at least one or many DataElements. This class inherits the attributes elementId and
dictionaryReference from the abstract DataElement class and adds the following specific attributes (see
Table 4).
Table 4 — Definition of MultiValuedDataElement attributes
Name Description Datatype Cardinality Example
Specifies the data
type of the value String as
valueDataType needed for the described in [0.1] “xsd:integer”
interpretation of 4.1.2.9
the value data
[DataElement] Data elements of DataElement [0.*]
the same type (abstract)
within the multi
as per 4.1.2.3
valued data
element
[DataElement] is a placeholder for additional content or other attributes of the MultiValuedDataElement.
4.1.2.7 RelatedResource
The RelatedResource is the semantic representation of any instance of a document or certificate that can
be required to be included into a digital product passport instance. This class inherits the attributes
elementId and dictionaryReference from the abstract DataElement class and adds the following specific
attributes (see Table 5).
Table 5 — Definition of RelatedResource attributes
Name Description Datatype Cardinality Example
The IANA Media
Type/MIME type
contentType String [1] “application/pdf”
String formatted as
The link to the
url URL according to [1]
resource
RFC 3986 [5]
String formatted as
localized language tag
with: two (2)
characters language
“en-GB”
The language of
code as in
language the resource, if [0.1] “de-DE”
ISO 639:2023 [6] (e.g
applicable
“de-AT”
“en”), and two (2)
characters country
code as in EN
ISO 3166-1:2020 [7]
Human readable
“Maintenance
resourceTitle title of the String [0.1]
manual”
resource
Additionally, it can include other attributes if required by the relevant legal acts.
4.1.2.8 MultiLanguageDataElement
4.1.2.8.1 General
The MultiLanguageDataElement represents a language dependent data point whose value varies with
respect to the language associated with it. It contains at least one or many MultiLanguageValues (see
4.1.2.8.2). This class inherits the attributes elementId and dictionaryReference from the abstract
DataElement class.
4.1.2.8.2 MultiLanguageValue
The MultiLanguageValue represents a language dependant value. It includes the following metadata
attributes (see Table 6).
Table 6 — Attributes of the MultiLanguageValue object
Name Description Datatype Cardinality Example
Contains the data of
“a product
value the value in the String [1]
description”
MultiLanguageValue
Name Description Datatype Cardinality Example
String formatted as
localized language tag
with: two (2)
Specifies the
“en-gb”
characters language
language of the value
language code as in ISO 639:2023 [1] “de-de”
within the
[6] (e.g “en”), and two
“de-at”
MultiLanguageValue
(2) characters country
code as in EN
ISO 3166-1:2020 [7]
4.1.2.9 Value data type
The valueDataType should allow XSD data types conformant to W3C XML Schema [8] and [9] except:
— the XSD data types that represent a list of values within a single whitespace-separated string (i.e.
ENTITIES, IDREFS, and NMTOKENS) shall not be supported.
— XSD string derived built-in types shall not be supported, and
— the following XSD primitive types shall not be supported: NOTATION, QName.
— base64 binary may be supported
4.2 Data model requirements to manage DPP changes
During its lifetime, the digital product passport may undergo changes that impact the data points to be
declared, like for example the environmental performance. These changes could lead to a modification of
the DPP initially published for a product, either through a change of an existing property or document, or
through the addition of information or a property not in the initial instance. To be properly archived,
every digital product passport lifetime event resulting into a change to a DPP should be kept track of.
Data include for example:
— identifier (e.g. digitalProductPassportId, uniqueProductIdentifier);
— timestamp (when the change occurred);
— actor as per EN 18239 [10] (who made the change);
— changed properties (specific properties modified).
Any changes to a DPP shall be logged and archived according to EN 18221:2026 requirements. Delegated
acts can define to what extent.
4.3 Model for repositories for the data dictionaries
To enable cross-sector semantic interoperability for digital product passport, while avoiding constraints
on how DPP information may be defined and ensuring openness to different technologies (or
technological approaches), a decoupled approach shall be applied. In this approach, data points and their
definitions are managed independently.
Each data point should be associated with a machine-readable semantic definition stored in a repository.
The governance of such repository should be regulation-based, but shall allow for the inclusion of
definitions beyond regulatory requirements where appropriate. Each definition shall have a unique
identifier and shall occur only once within a repository to enable unambiguous referencing. This also
allows for mapping between definitions contained in different semantic catalogues (repositories).
This approach con
...