Showcase: a layered approach to creating interoperable Digital Battery Passports
From 18 February 2027, the EU Battery Regulation requires a digital product passport (DPP) for electric vehicle batteries, batteries for light means of transport (such as e-bikes and e-scooters) and industrial batteries above 2 kWh. For manufacturers and their software vendors, the question is no longer whether to build one, but how to build it correctly and in a way that others can actually use.
A passport can contain all the required information and still be difficult to exchange or process automatically, because different organisations use different names, structures and interpretations for the same battery data.
To prevent this, several parties each define a part of the DPP: the European Commission and industry define generic concepts, sector organisations add battery-specific concepts, and experts translate the requirements into machine-readable rules. These parts have to fit together. Within CIRPASS-2, we developed a Battery DPP Template that shows how these contributions come together in one concrete, machine-validatable DPP, and how Semantic Treehouse turns that template into implementation support. The approach follows the semantic architecture that the European Commission describes in the DPP Registry Semantic Data Guide (v1.0, October 2026).
This showcase is written for two groups. If you are involved in DPP standardisation, it shows how the layers and the parties behind them fit together. If you are an IT architect at a manufacturer or another party that must provide a DPP, it shows how your Battery DPP can be compliant, using an EV battery as an example.
Batteries are just one example. The same approach can be applied to other product groups. Are you curious how this could work for your sector? Get in touch via Discord or mail Linda Oosterheert.
After regulation comes semantics
A Battery DPP contains information about topics such as battery identification, chemistry, performance, durability and state records.
However, agreeing that this information should be exchanged is only the first step. Organisations and systems must also share an understanding of:
- what each data element means;
- how data elements relate to each other;
- which information is mandatory or optional;
- which datatypes and controlled values may be used;
- which requirements apply to a specific battery category.
Without these shared definitions and rules, two systems may appear to exchange the same information while interpreting or structuring it differently.
No single party can make these agreements alone. The European Interoperability Framework (EIF) distinguishes legal, organisational, semantic and technical interoperability, and calls keeping these levels aligned interoperability governance: the regulation sets the legal requirements, sector organisations and companies agree on meaning, and implementers need technical specifications that reflect both. For DPPs, this means that the European Commission, standardisation bodies, sector organisations and companies each contribute a part, and those parts must fit together.
The CIRPASS-2 Battery DPP Template addresses this by connecting shared semantics developed in the CIRPASS-2 project, sector-specific concepts and machine-checkable validation rules.
A layered approach
The Battery DPP Template is composed of three reusable semantic building blocks, each with its own owners. In line with the Semantic Data Guide of the EC, these building blocks are organised in layers:
- a core layer with concepts that apply to every DPP;
- a product group layer, in this case batteries;
- where needed, product sub-groups, for batteries: electric vehicle (EVB), light means of transport (LMT) and industrial (IND) batteries.
1. Core layer: CIRPASS-2 Core Ontology
The Core Ontology defines concepts that are relevant across all product groups, such as products, DPPs, actors, facilities, materials, documents, life cycle assessment (LCA) and other properties.
By defining these concepts in the core layer, they can be reused by every product group.
Who: this layer is typically developed by the European Commission together with industry partners, as part of the EU standardisation process for DPPs.
2. Product group layer: CIRPASS-2 Battery Ontology
The Battery Ontology extends the core layer with concepts and controlled vocabularies that are specific to batteries. This includes concepts related to:
- battery chemistry;
- performance;
- state records;
- durability;
- exposure;
- labels.
This product group layer provides a shared meaning for battery-specific information while continuing to reuse the generic concepts from the core layer.
Who: a product group layer is usually developed by a sectoral standardisation body, by the EU together with industry, or by an industry consortium such as Battery Pass.
3. Product group and sub-group shapes: Battery SHACL Shapes
SHACL (Shapes Constraint Language) is a W3C standard for describing rules that data must meet. The Battery SHACL Shapes translate requirements into such machine-checkable constraints. These constraints can specify, for example:
- whether an attribute is mandatory, optional or conditional;
- how many times an attribute may occur;
- which datatype must be used;
- which controlled values are allowed;
- which requirements apply to a specific product sub-group: EVB (electric vehicle), LMT (light means of transport) or IND (industrial) batteries.
Together, the shapes form a conformance profile for the battery passport. They are based on Annex XIII of Regulation (EU) 2023/1542, which lists the information a battery passport must contain: each requirement is translated into one or more constraints, such as whether an attribute is mandatory and which values are allowed. The shapes also follow the BatteryPass-Ready Long List v1.3, an industry-developed list of data attributes for the battery passport that is based on that same Annex.
Who: usually the same parties as the product group layer, but often different people. Where the ontology describes what information means, the shapes express the stricter requirements a passport must meet.
All three building blocks are published on the DPP Vocabulary Hub.
Explore the building blocks on the DPP Vocabulary Hub →
4. DPP Template
The Battery DPP Template imports and integrates the Core Ontology, the Battery Ontology and the Battery SHACL Shapes. Each layer adds something specific:
| Layer | Created by | Role |
|---|---|---|
| Core layer (Core Ontology) | European Commission with industry partners, within EU standardisation | provides generic DPP concepts |
| + Product group layer (Battery Ontology) | sectoral standardisation body, the EU with industry, or an industry consortium such as Battery Pass | adds battery-specific concepts and controlled vocabularies |
| + Product group and sub-group shapes (Battery SHACL Shapes) | usually the same parties as the product group layer | define machine-checkable rules and constraints |
| = Battery DPP Template | a standardisation body, usually the sectoral standardisation body | provides a concrete and validatable model for implementing a Battery DPP |
Together, these building blocks form a concrete model that defines:
- which information should be included;
- how that information is structured;
- what the information means;
- which validation rules apply.
Rather than creating a completely separate model for every implementation, the template composes reusable semantic assets into a DPP model for a particular product category and use case.
The same overall pattern applies to each product sub-group (EVB, LMT and IND), with sub-group-specific attributes and constraints.
This separation makes it possible to manage and publish the different building blocks independently, while bringing them together in a practical template.
From template to implementation
Many parties work on a DPP Template, but in the end it has to work in the IT systems of the companies that must provide a passport. That is why Semantic Treehouse does not stop at documentation: from the same template, it generates implementation artefacts based on open standards that developers already know.
| Generated artefact | Helps you to |
|---|---|
| JSON Schema | validate JSON-based DPP data and generate code from it |
| OpenAPI | design and build APIs that publish or retrieve DPP data |
| XML Schema (XSD) | integrate the DPP into existing XML-based systems |
| SHACL | validate DPP data as linked data against the regulatory rules |
| JSON-LD / Turtle examples | start from a correct example instead of a blank page |
Because all artefacts are derived from one template, they stay consistent with each other and with the underlying definitions. When the regulation or the template changes, a new template version results in updated artefacts, so implementations can follow without starting over.
Developers no longer have to translate legal text into data structures themselves. They can use standard tooling, such as code generators, API frameworks and validators, and focus on connecting their own product data.
A worked example: an EV Battery DPP
To make the template tangible, the showcase includes a worked EV battery example.
The example demonstrates how an actual Battery DPP instance can use the concepts and structures defined by the template. It connects the individual values in the passport to shared definitions from the Core and Battery Ontologies.
The EV battery example is available in machine-readable formats, including JSON-LD and Turtle.
This makes it possible to inspect the DPP both as a human-readable structure and as data that can be processed by software.
Each attribute in the EV Battery DPP can be traced back to its definition, source ontology and applicable validation rule. For battery chemistry, for example, you can see:
- the value included in the EV Battery DPP;
- the corresponding concept in the Battery Ontology;
- the controlled vocabulary used for that value;
- the SHACL rule that determines whether the value is valid.
This creates a traceable connection between the concrete passport data and its underlying semantic and regulatory foundations.
What happens when the data is incorrect?
A key part of the showcase is validation.
The DPP Validator checks whether a Battery DPP instance conforms to its template. Through that template, the instance is also checked against the product group and core layers and the underlying validation rules. DPPs in XML, JSON and JSON-LD can be validated against their corresponding schemas.
The value of validation becomes especially clear when a DPP contains an error. Examples include:
- a mandatory attribute is missing;
- a text value is provided where a number is expected;
- a value does not come from the prescribed controlled vocabulary;
- an attribute is used for the wrong product sub-group;
- a required relationship between two elements is missing.
Instead of only reporting that the DPP is invalid, the validation result can point to the specific attribute and constraint that caused the problem.
This allows developers and data providers to correct the DPP before exchanging or publishing it.
Conclusion
The Battery DPP Template shows that turning regulation into a usable DPP is a joint effort, and that this effort pays off at implementation time.
- IT architects at battery manufacturers and other parties that must provide a DPP get a ready-to-use starting point aligned with Regulation (EU) 2023/1542. Instead of interpreting the regulation themselves, they build on the generated artefacts and check their passports with the DPP Validator before publishing. Software vendors and DPP service providers can do the same: build a solution once, on open standards, and offer it to many customers.
- People involved in DPP standardisation can reuse the core layer and only define what is specific to their product group. Semantic Treehouse provides the versioning and governance to publish and maintain these templates, and makes the result directly usable for implementers.
This layered approach matches the semantic architecture in the European Commission's DPP Registry Semantic Data Guide. Semantic Treehouse supports this architecture: it takes care of versioning, governance and publication of each layer, so that every layer can be maintained independently and implementers always know which version they build on.
The approach is not battery-specific: any product group can reuse the core layer, add its own concepts and SHACL rules, and publish the result as a DPP Template on the Vocabulary Hub. This showcase works top-down, from shared ontologies and regulation towards a template, but Semantic Treehouse also supports bottom-up: start from the data you already have and map the resulting model to shared standards like the CIRPASS-2 Core Ontology or others.
Want to know more? Read about creating a model from sample data and how mapping specifications connect bottom-up models to top-down ontologies.