Electronics DPP Implementation Guide

How to assemble an Electronics Digital Product Passport against the published openepcis-dpp-ready electronics vocabulary

electronicsimplementationrepairabilityweeeenergy-label 5 min read

Overview

This guide walks through assembling an electronics DPP that uses only published vocabulary — terms defined in the OpenEPCIS electronics ontology and the GS1 Web Vocabulary. It mirrors the canonical reference passports under extensions/eu/electronics/examples/ in the dpp-ready repo.

Conventions. In JSON-LD documents the property names are bare — the JSON-LD context maps them to the right namespace. So you write "deviceCategory": "Smartphone", not "electronics:deviceCategory". Controlled values likewise come out unprefixed once @vocab is set.

Prerequisites

A GS1 Company Prefix and assigned GTINs for the products you'll passport.
A resolver that can host the linkset for each Digital Link URL (see Resolver Setup).
The electronics JSON-LD context: https://ref.openepcis.io/extensions/eu/electronics/electronics-context.jsonld.
For battery-containing devices (smartphones, laptops, e-scooters), also the battery context. The cleanest pattern for composite products is to expose the embedded battery as its own resolvable DPP (see multi-component example).

Step 1: Identify the device

Every device gets a GS1 Digital Link URL — https://id.gs1.org/01/{GTIN}/21/{serial} for a serialised unit, or just /01/{GTIN} for SKU-level information. The same identifier becomes the id of the passport document and the epcList value in every EPCIS event.

Dual-type the document: "type": ["Product", "Smartphone"] (or Laptop, Display, Server, …, drawn from electronics:DeviceCategory).

Step 2: Repairability — French Index and EU Right-to-Repair grade

The electronics vocabulary supports both repairability methods side by side:

The French Repairability Index is captured as an electronics:RepairabilityIndex block with one electronics:RepairCriterion per scored axis (Documentation, Disassembly, …). The published vocabulary defines electronics:RepairCriterionType; the actual weighting per axis is set by French regulation per product family and is not embedded in the passport.
The EU Right-to-Repair grade is captured as electronics:EURepairabilityClass with one of RepairClassA, RepairClassB, RepairClassC, RepairClassD, RepairClassE.

For the calculation tables and per-family weights, refer to the official French Repairability Index methodology. For replaceability of individual parts use electronics:ReplacementDifficulty (UserReplaceable, ToolRequired, ProfessionalOnly, NotReplaceable).

Step 3: Energy class and EPREL registration

electronics:EnergyEfficiency carries the labelling data. The class itself goes in electronics:EnergyEfficiencyClass (EnergyClassA … EnergyClassG), and the EU Product Registry for Energy Labelling reference goes in electronics:eprelRegistrationNumber. electronics:annualEnergyConsumption captures the declared annual figure when the regulation requires it (washing machines, dishwashers, refrigerators, TVs).

Step 4: WEEE registration (Annex III, six categories)

electronics:WEEECategory is the controlled list from WEEE Directive 2012/19/EU Annex III — the six current categories:

WEEE1_TemperatureExchange — fridges, freezers, heat pumps
WEEE2_ScreensMonitors — TVs, monitors, displays > 100 cm²
WEEE3_Lamps
WEEE4_LargeEquipment — any large appliance > 50 cm
WEEE5_SmallEquipment — small appliances ≤ 50 cm
WEEE6_SmallIT — small IT and telecom equipment ≤ 50 cm

Producer registration goes in electronics:weeeRegistrationNumber with electronics:weeeRegistrationCountry. Take-back / collection program URLs are referenced from the core DPP block dpp:EndOfLifeProgram.

Step 5: Spare-parts policy

electronics:SparePartsAvailability captures the years a manufacturer commits to keeping spare parts available; electronics:SparePartsPricing captures the pricing policy. Each enumerated part type uses electronics:ComponentType (BatteryComponent, DisplayComponent, etc.) with electronics:componentPartNumber, and the difficulty of replacing it is tagged via electronics:ReplacementDifficulty.

Step 6: Software support lifecycle

electronics:SoftwareSupport declares the support commitment. Fields:

electronics:firmwareVersion / electronics:osVersion — current versions installed
electronics:previousVersion / electronics:newVersion — used when recording an update event
electronics:updateType — feature, security, bug fix
electronics:updateSource — provenance (OEM, OS vendor, …)

When a software update happens, it is captured as an EPCIS event referencing these properties (see reference EPCIS examples, specifically software-update.jsonld).

Step 7: Component BOM

For laptops, servers and complex devices the component breakdown lives in electronics:ComponentBOM. Each entry is typed with electronics:ComponentType (BatteryComponent, CameraComponent, ConnectorComponent, CoolingSystemComponent, DisplayComponent, EnclosureComponent, KeyboardComponent, MemoryComponent, MicrophoneComponent, MotherboardComponent, PowerSupplyComponent, ProcessorComponent, SpeakerComponent, StorageComponent, TrackpadComponent) plus electronics:componentPartNumber and the replaceability info from Step 5.

For products that combine an electronic device with a separately-regulated battery, prefer the multi-component pattern — the battery has its own GS1 Digital Link URL and its own passport. See multi-component example.

Step 8: Publish the electronics linkset

The electronics passport is served from an IETF application/linkset+json document (RFC 9264) — one object per anchor identifier, GS1 link relations as full-IRI keys. For a smartphone or laptop you typically want the consumer PIP, EPCIS history (commissioning, repairs, software updates), the repair/service information, the carbon-footprint / energy declaration, and the certification dossier:

{
  "linkset": [
    {
      "anchor": "https://id.gs1.org/01/09521234000013/21/PHONE-2025-001",
      "itemDescription": "EcoOS smartphone",
      "https://ref.gs1.org/voc/defaultLink": [
        { "href": "https://dpp.example.com/electronics/09521234000013/PHONE-2025-001",
          "title": "Electronics passport" }
      ],
      "https://ref.gs1.org/voc/pip": [
        { "href": "https://dpp.example.com/electronics/09521234000013/PHONE-2025-001",
          "title": "Electronics passport (consumer view)",
          "type": "text/html",
          "context": ["ALL"], "public": true }
      ],
      "https://ref.gs1.org/voc/epcis": [
        { "href": "https://api.example.com/events?MATCH_anyEPC=https%3A%2F%2Fid.gs1.org%2F01%2F09521234000013%2F21%2FPHONE-2025-001",
          "title": "EPCIS event history (commissioning, repair, software updates)",
          "type": "application/ld+json",
          "context": ["ALL"], "public": true }
      ],
      "https://ref.gs1.org/voc/serviceInfo": [
        { "href": "https://dpp.example.com/service/09521234000013/PHONE-2025-001",
          "title": "Repair information and spare-parts catalogue",
          "type": "text/html",
          "context": ["ALL"], "public": true }
      ],
      "https://ref.gs1.org/voc/productSustainabilityInfo": [
        { "href": "https://dpp.example.com/sustainability/09521234000013/PHONE-2025-001",
          "title": "Carbon footprint and EPREL energy declaration",
          "type": "application/ld+json",
          "context": ["ALL"], "public": true }
      ],
      "https://ref.gs1.org/voc/certificationInfo": [
        { "href": "https://dpp.example.com/certs/09521234000013/PHONE-2025-001",
          "title": "CE declaration, WEEE registration, conformity reports",
          "type": "application/ld+json",
          "context": ["business", "authority"] }
      ]
    }
  ]
}

The ?linkType= parameter on a resolver URL takes the bare relation name (pip, serviceInfo, productSustainabilityInfo, …). See Resolver Setup for hosting options.

Step 9: EPCIS events

The dpp-ready repo ships reference EPCIS events for the electronics lifecycle:

commissioning.jsonld — device commissioned, baseline metadata captured
ownership-transfer.jsonld — sale or transfer to a new owner
software-update.jsonld — version transition recorded with previousVersion / newVersion
component-replacement.jsonld — repair event with the replaced ComponentType and the new partNumber
weee-disposal.jsonld — end-of-life recorded against the WEEE category

All four follow the EPCIS 2.0 pattern: extension properties at event level (not inside masterDataAvailableFor), the GS1-Extensions header declaring the electronics= namespace.

Validation

A complete electronics DPP should pass three kinds of check:

JSON-LD shape — normalises against the electronics context (no unresolved terms, no @context collisions).
SHACL — instance data satisfies the electronics shapes published with the vocabulary.
JSON Schema — the payload validates against the electronics DPP schema. The repairability index check (criteria sum to total, total within 0–100) is enforced here.

For EPREL registrations, cross-check the published number against the EPREL Database as part of the publishing workflow.

Next steps

Complete examples — links to the canonical smartphone, laptop, display and server passports
Electronics vocabulary browser — full ontology
Multi-component example — for products that combine an electronic device with a separately-regulated battery