---
title: "Multi-Component DPPs: An E-Bike Walkthrough | OpenEPCIS Docs | OpenEPCIS - an open-core, GS1-compliant EPCIS implementation."
canonical_url: "https://openepcis.io/de/docs/digital-product-passport/multi-component-example"
last_updated: "2026-06-28T23:26:20.435Z"
meta:
  author: "benelog GmbH & Co. KG"
  description: "How a composite product references separately-passported components via standard GS1 Digital Link and EPCIS aggregation"
  keywords: "Multi-component DPP, e-bike passport, component traceability, EPCIS AggregationEvent"
  "og:description": "How a composite product references separately-passported components via standard GS1 Digital Link and EPCIS aggregation"
  "og:title": "Multi-Component DPPs: An E-Bike Walkthrough"
  "twitter:description": "How a composite product references separately-passported components via standard GS1 Digital Link and EPCIS aggregation"
  "twitter:title": "Multi-Component DPPs: An E-Bike Walkthrough"
---

</h2>Home

``

# **Multi-Component DPPs: An E-Bike Walkthrough** How a composite product references separately-passported components via standard GS1 Digital Link and EPCIS aggregation [~~example~~](https://openepcis.io/de/tags/example)· [~~components~~](https://openepcis.io/de/tags/components)· [~~aggregation~~](https://openepcis.io/de/tags/aggregation)· [~~cirpass2~~](https://openepcis.io/de/tags/cirpass2)· 4 min read ## Overview Complex products — e-bikes, EVs, industrial equipment — are made of parts that each have their own regulatory profile. A battery falls under EU 2023/1542, an electronic motor controller under WEEE and ESPR, a leather saddle potentially under ESPR plus EUDR. Trying to cram every datum into one monolithic passport quickly turns the document into a kitchen sink no audience actually wants. The cleaner pattern: **each component is itself an identified, resolvable product.** The composite product just _references_ its components by their Digital Link URLs. Consumers, recyclers, regulators and customs officers each follow the link they care about and land on a focused passport. > **Status of this pattern.** Component linking is an active topic in CIRPASS-2 and adjacent specs. There is no canonical OpenEPCIS property like `**dpp:hasPart**` yet — the worked example below uses **EPCIS Aggregation events** to express the parent ↔ child relationship, which is part of the published EPCIS 2.0 spec and works today without inventing vocabulary. ## The e-bike, by regulation | **Component** | **Primary regulation** | **DPP module that fits** |
| --- | --- | --- | | Frame | ESPR 2024/1781 | DPP core | | Battery pack | EU 2023/1542 | Battery DPP | | Motor + controller | ESPR + WEEE | Electronics DPP | | Leather saddle | ESPR (+ EUDR for the leather) | Textile + EUDR | | Tires | Future ESPR delegated act | DPP core | Each row is an independently-identifiable product with its own GTIN, its own serial, its own resolver entry, and its own passport. ## Pattern: composite product references components The composite product gets one Digital Link URL. Its passport carries a small list of component URLs — each one resolves on its own to a focused passport built from the right DPP module. Conceptually:![An e-bike passport linking its component passports](https://openepcis.io/diagrams/dpp-multi-component-ebike-light.svg)![An e-bike passport linking its component passports](https://openepcis.io/diagrams/dpp-multi-component-ebike-dark.svg) The e-bike's own JSON-LD only needs the composite-level data: brand, model, dimensions, headline circularity claims, plus a list of component URLs. Each component URL is the canonical Digital Link of _that_ component's passport — no embedding, no duplication. ## Expressing the composition: EPCIS AggregationEvent EPCIS 2.0 already models "X is made of Y, Z, …" as an **AggregationEvent**: a `**parentID**` plus a list of `**childEPCs**`. This is the no-invention way to make the parent ↔ child relationship machine-readable today.```
{
  "@context": ["https://ref.gs1.org/standards/epcis/epcis-context.jsonld"],
  "type": "EPCISDocument",
  "schemaVersion": "2.0",
  "epcisBody": {
    "eventList": [{
      "type": "AggregationEvent",
      "eventTime": "2025-01-25T14:00:00Z",
      "eventTimeZoneOffset": "+01:00",
      "action": "ADD",
      "bizStep": "assembling",
      "disposition": "active",
      "parentID": "https://id.gs1.org/01/09521234000010/21/EBIKE-2025-001",
      "childEPCs": [
        "https://id.gs1.org/01/09521234000027/21/BAT-EBIKE-001",
        "https://id.gs1.org/01/09521234000034/21/MOTOR-001",
        "https://id.gs1.org/01/09521234000041/21/SADDLE-001",
        "https://id.gs1.org/01/09521234000058/21/FRAME-001"
      ],
      "readPoint": { "id": "https://id.gs1.org/414/9521234000010" }
    }]
  }
}
``` When the e-bike is later disassembled (a component being replaced under warranty, a recycler stripping it for materials) the inverse is the same shape with `**action: "DELETE"**` — the components survive the parent, they just stop being aggregated to it. The history is queryable per-serial through the EPCIS query API. ## What clients see at resolution time - **Consumer** scans the e-bike → the resolver returns the composite passport (brand, model, recycling instructions, links to component passports). They can drill into the battery for State-of-Health, or the saddle for material composition. - **Authorised recycler** scans the same e-bike with credentials → same composite passport, plus access-controlled fields (full BOM, hazardous-substance disclosures, disassembly sequence). - **Customs officer** scanning the saddle directly → leather + EUDR passport, EUIS reference, plot-of-origin coordinates, due-diligence statement. - **Battery technician** scanning the battery directly → battery passport with the latest SoH event from the EPCIS query, no need to go via the e-bike. The same Digital Link primitives (`**Accept**`, `**?linkType=**`, access tier) that drive single-product resolution drive component-level resolution. See [DPP Resolution Flow](https://openepcis.io/docs/digital-product-passport/dpp-resolution-flow) for the end-to-end picture. ## Why this pattern is worth the effort - **Regulatory clarity** — each component lines up to one regulator, not five. - **Independent lifecycle** — replacing a battery just publishes a new component passport and an aggregation update; the e-bike's main passport doesn't churn. - **Audience-appropriate payloads** — a consumer-grade UI never has to hide WEEE codes; a recycler API never has to skim past the marketing description. - **Circular economy** — recovered components keep their full history (events, certifications, hazard data) as they're re-aggregated into a new product. ## What's left to standardise Today there is no single agreed JSON-LD predicate to say "this composite passport references these component passports" — different specs (CIRPASS-2 bridges, Catena-X industry-core, sector-specific drafts) propose different shapes. Until that lands, the EPCIS AggregationEvent shown above is the safest published way to express the relationship, and OpenEPCIS will follow whichever CIRPASS-2 / GS1 outcome becomes the standard. ## Next steps - [DPP Resolution Flow](https://openepcis.io/docs/digital-product-passport/dpp-resolution-flow) - [Battery DPP](https://openepcis.io/docs/digital-product-passport/battery-dpp) - [Electronics DPP](https://openepcis.io/docs/digital-product-passport/electronics) - [Textile DPP](https://openepcis.io/docs/digital-product-passport/textile) - [EUDR](https://openepcis.io/docs/digital-product-passport/eudr)