A Digital Product Passport under CEN/CENELEC EN 18223 is plain JSON, and it falls out of data you may already publish: good GS1 Web Vocabulary, addressed by a GS1 Digital Link. The same identity can be encoded in different data carriers, from a QR code to NFC and RFID tags. Pick a sample, or paste your own, and press Derive.
Each property becomes an EN 18223 DataElement. Its
dictionaryReference is the property's own vocabulary IRI,
wherever the term is defined, whether GS1, schema.org, or the OpenEPCIS
extensions at ref.openepcis.org, and its valueDataType is the
range the ontology declares for it. The passport's granularity
follows the Digital Link Application Identifiers: a GTIN on its own
describes a model, a GTIN with a lot number a batch, a GTIN with a serial an
item. contentSpecificationIds then lists the dictionaries the
passport actually draws on.
The page runs each example through the same steps a repository would. It
first expands the input with standard JSON-LD processing, which replaces
every shorthand key with the full IRI of the term it stands for. That IRI
is what EN 18223 calls a dictionaryReference. The
JSON-LD expanded view shows this stage directly, so you
can see that netWeight is
https://ref.gs1.org/voc/netWeight while a recycled-content
figure resolves under an OpenEPCIS extension.
EN 18223 is deliberately permissive about what that reference may be. It
types dictionaryReference as a plain string and asks only that
each definition carry a unique identifier that occurs once within its
repository (clause 4.3), with the stated aim of staying open to different
technologies; even digitalProductPassportId only
should use a URI/URL structure. The identifier need not be
resolvable on the web. A resolvable web IRI of the kind GS1 issues is one
option; an opaque identifier such as an IRDI (the IEC 61360 / eCl@ss style
used by the Asset Administration Shell, for example
0173-1#02-AAO677#002) is equally valid under the standard,
even though you cannot fetch it over HTTP. GS1 is stricter in a way that
pays off: a GS1 Digital Link and a GS1 Web Vocabulary term are HTTPS URLs
you can dereference. This derivation keeps that web-native property, so
every dictionaryReference it emits is an IRI you can open in a
browser to retrieve the definition behind it.
From that expanded graph the converter assembles the EN 18223 information
model. Each property becomes a DataElement with its
dictionaryReference, a valueDataType read from the
ontology's declared range, and a value. A nested object such as a quantity
or a carbon-footprint breakdown becomes a DataElementCollection;
a list of values becomes a multi-valued element; a coded value or a document
reference is carried as a single value or a RelatedResource.
Around the data the envelope is filled in: the unique identifier and
granularity from the Digital Link, the schema version, and the
contentSpecificationIds the data drew on.
EN 18223 defines one JSON payload with two serializations. The
compressed form (clause 5.2) is ordinary key-value JSON
keyed by elementId, with the dictionaryReference
and valueDataType held in a data dictionary — which is exactly a
JSON-LD @context. We always carry that operational
@context, so the compressed form is self-describing JSON-LD and
still plain JSON (also written operational). The
expanded form (Annex A) keeps every data element explicit,
which suits validation and machine processing. The same model also serializes
to XML in both the Annex B compressed form and an expanded
analogue, and to Turtle RDF. The View
dropdown only reprojects the passport, so switching is instant.
None of this is written per product. The mapping follows from good GS1 Web Vocabulary and the published ontology, so the battery, textile, electronics, deforestation, packaging, construction, detergent, and food examples all pass through the identical code.