Map clean, idiomatic JSON-LD into the EN 18223 serialization and the first thing you notice is the size. The target format is strikingly verbose.
EN 18223 is the CEN/CLC JTC 24 standard that defines the Digital Product Passport’s data model, the shape every DPP has to fit once the standard is cited in the EU Official Journal. In that shape, every value becomes an object with its own elementId, dictionaryReference, objectType, valueDataType and value. Three lines of source data turn into twenty.
What the verbosity actually pays for
The verbosity is not accidental, and it is worth understanding what it buys.
It is what semantics look like once you can no longer assume they are openly resolvable online. A JSON-LD document normally carries meaning through an @context: a link the reader follows to look up what a field means.
EN 18223 has to work even when the dictionary behind a field is ECLASS or IEC CDD - both paywalled, neither freely dereferenceable the way an open @context IRI is. So the standard inlines the meaning value by value: which dictionary, which entry, what type, what value. That is the only way to stay self-describing when you cannot count on the reader clicking through.
Read that way, the verbosity is not a design failure. It is a rational response to closed dictionaries.
The contrast is concrete. The vocabularies we build on - the OpenEPCIS DPP Core and its regulation extensions - are published openly at ref.openepcis.io and stay freely dereferenceable. A single @context reference carries the meaning a closed dictionary has to inline.
Why the direction matters
Reconstructing open semantics from a closed dictionary is the hard direction of travel. Going the other way is easy.
Our JSON-LD source already carries every attribute EN 18223’s model asks for: a property reference, a dictionary reference, a value data type, a per-value language array. They are just expressed on typed JSON-LD objects with @context IRIs, instead of EN 18223’s flat entity-attribute-value wrapper.
Producing an EN 18223 view of that data is a formatting exercise: take the fields that already exist and lay them out in the target shape.
The principle in one sentence: an open-namespace source turns any closed dictionary into a projection, so the verbosity is a cost you only pay if you started closed. We never do, because the meaning was there from the first write.
Namespace plurality, not one canonical vocabulary
That our source already has this shape is a deliberate choice, not an accident. We do not force every regulation into one vocabulary.
Each EU DPP regulation - battery, textile, electronics, and the ones still to come - keeps its own upstream namespace: GS1’s, OpenEPCIS DPP Core’s, the regulation’s own extension. All of them sit in parallel inside one @context array, next to a deliberately thin transpareo: namespace for the handful of terms nothing upstream covers.
EN 18223 asks for almost exactly this in its own introductory clause 0.2: avoid sector-specific ontologies, allow parallel usage of the ontologies issued per delegated act, keep the horizontal layer as general as possible.
An architecture built on open, parallel namespaces is not merely compatible with the standard’s intent. It is what the standard’s own design principle points to.
A stress test: the Battery Pass attribute list
The proof is in how the architecture absorbs a dictionary it was never built for.
The Battery Pass Consortium’s Data Attribute Long List, version 1.3, is a third dictionary that diverges independently from both EN 18223 and GS1: about 100 attributes, its own naming, its own access tiers, a consortium reading of the Battery Regulation’s Annex XIII.
We mapped it against our existing data model. 91 of the 100 attributes landed on property types that already existed, unchanged. A source built on plural namespaces absorbs a new closed dictionary as one more projection - it does not force a redesign.
Where the standard stands
EN 18223 and its sibling EN 18216, which defines the concrete wire serialization EN 18223 defers to, are both published European Standards.
They sit in the first published wave of the CEN-CENELEC JTC 24 DPP set: six of the eight standards, with the remaining two, on authentication and access rights, following over the summer of 2026. Their citation in the EU Official Journal, which confers harmonised status and the presumption of conformity, is expected around mid-2026.
The bright side
None of this makes EN 18223 the wrong standard. The verbosity is the honest cost of interoperability in a world where not every dictionary is open, and the standard handles that world well.
The bright side is simply this: if you are already on clean JSON-LD, meeting EN 18223 is a projection, not a rebuild. The expensive direction is the other one - the one anyone who started from a closed dictionary has to travel.
Build on open, resolvable semantics from the first write, and the standard’s verbosity stops being a tax you pay. It becomes an output format you generate on demand.