What Is JSON-LD, and Why Use It for DPP Data?

The CIRPASS-2 reference architecture recommends JSON-LD as the default exchange format for the Digital Product Passport. Why not plain JSON? The answer is one word: meaning.

The problem with plain JSON

A field name carries no meaning on its own:

{ "material": "PET", "recycled": 30 }

Thirty per cent of what? By weight or by volume? Post-consumer? Two platforms can use the same field name for different things and nobody notices.

What JSON-LD adds

JSON-LD adds a context that binds each field to a URI with a defined meaning. "recycledContent" then points at a standard concept, and passports produced by two different systems can be mapped automatically.

Crucially, JSON-LD is still JSON. A client that ignores the context reads it as ordinary JSON; a client that uses it resolves the meaning — an ideal property during a transition.

See the EN 18223 core data model and the DPP data model guide.

Relationship to verifiable credentials

W3C Verifiable Credential packages are JSON-LD based, so holding passport data as JSON-LD makes producing signed, verifiable data sets the natural next step. See verifiable credentials.

Working with a resolver

A resolver returns HTML or application/ld+json depending on the request's Accept header, letting one identifier serve consumers and machines alike. See what a resolver service is.

Practical implementation notes

1. Version the context and publish it at a permanent address.
2. Map field names to sector models and document the mapping.
3. Use language-independent codes; resolve language at the presentation layer. See multilingual passports.
4. Add schema validation: JSON-LD gives meaning, JSON Schema gives validity.

Frequently asked questions