JSON-LD and Schema.org for Digital Product Passports

Šis raksts vēl nav pieejams jūsu valodā, tāpēc tas tiek rādīts angļu valodā.

Understanding JSON-LD and Its Relevance to DPPs

JSON-LD (JavaScript Object Notation for Linked Data) is a method of encoding linked data using JSON. It provides a way to add semantic meaning to data structures that would otherwise be meaningful only to the specific application that created them. For Digital Product Passports, JSON-LD transforms product data from application-specific records into universally interpretable knowledge that any system, from search engines to regulatory databases to recycling facility software, can understand without prior agreement on data formats.

The core innovation of JSON-LD is the @context declaration, which maps the property names used in a JSON document to globally unique identifiers (URIs) that define their meaning. When a DPP includes a property called "material", the @context specifies whether this refers to Schema.org's definition of material, a domain-specific vocabulary for product composition, or some other semantic definition. This disambiguation is essential in a multi-stakeholder ecosystem where different organisations may use the same terms to mean different things.

JSON-LD is fully compatible with standard JSON, any valid JSON-LD document is also valid JSON. This means that systems that are not JSON-LD-aware can still parse and use the data, ignoring the semantic annotations. This backwards compatibility makes JSON-LD an ideal choice for DPP data exchange, as it allows gradual adoption without requiring all participants in the ecosystem to upgrade simultaneously.

Schema.org Vocabularies for Product Data

Schema.org provides the most widely adopted vocabulary for structured product data on the web. Originally created by Google, Microsoft, Yahoo, and Yandex to improve search engine understanding of web content, Schema.org has evolved into a comprehensive vocabulary covering products, organisations, events, actions, and much more. Its relevance to DPPs stems from its broad adoption, extensive product-related types, and active maintenance by a multi-stakeholder community.

The Schema.org Product type provides the foundation for DPP structured data. Key properties include:

• name, description, and identifier for basic product identification
• manufacturer and brand linking to Organisation entities
• material specifying the materials used in the product
• weight, width, height, and depth for physical dimensions
• gtin, mpn, and sku for standardised product identifiers
• hasEnergyConsumptionDetails linking to energy efficiency data
• additionalProperty for extending the schema with DPP-specific data points

While Schema.org covers many product attributes, DPP-specific data requirements, such as disassembly instructions, recycled content percentages, and substance of concern declarations, extend beyond the current Schema.org vocabulary. JSON-LD's extensibility handles this elegantly: DPP-specific vocabularies can be combined with Schema.org terms in the same document, leveraging Schema.org's broad recognition for common properties whilst using specialised vocabularies for domain-specific data.

For an overview of how DPP data standards work together, see our guide on DPP data interoperability standards.

Implementing JSON-LD for DPP Data Exchange

A practical JSON-LD implementation for DPPs begins with defining the @context that maps your DPP data model to semantic vocabularies. A typical DPP context combines Schema.org for general product properties with domain-specific vocabularies for environmental and regulatory data.

The structure of a DPP JSON-LD document follows a consistent pattern. The @context declaration appears at the top level, mapping short property names to their full semantic URIs. The @type property identifies the primary entity type (typically schema:Product). The @id property provides a globally unique identifier for the DPP, typically a URL that resolves to the full DPP data when accessed.

Nested entities within the DPP, materials, components, certifications, each carry their own @type and @id, creating a linked data graph that represents the full product structure. A material entity might link to its supplier (an Organisation entity), its environmental impact data (using environmental vocabulary properties), and its certification status (linking to a Certification entity with verifiable credentials).

Content negotiation enables a single DPP URL to serve different representations depending on the requester's needs. A web browser requesting text/html receives a human-readable passport page. An API client requesting application/ld+json receives the full JSON-LD document. A search engine crawler receives embedded JSON-LD within the HTML page. This multi-format approach from a single URL is fundamental to the DPP vision of universal accessibility. Learn more about identifier standards in our GS1 Digital Link guide.

Practical JSON-LD Structure for Digital Product Passports

Building a complete JSON-LD structure for a DPP requires careful consideration of how product data maps to semantic types. The top-level structure establishes the context and identifies the product, whilst nested objects describe materials, environmental metrics, compliance status, and lifecycle information.

The @context section should reference Schema.org as the default vocabulary and declare prefixes for any additional vocabularies used. Common additional vocabularies for DPPs include GS1 vocabularies for supply chain data, UNECE vocabularies for units of measurement, and emerging DPP-specific vocabularies being developed under ESPR implementing acts.

Product identification should use globally recognised identifiers wherever possible. The GS1 GTIN (Global Trade Item Number) mapped to the schema:gtin property provides unambiguous product identification. The DPP's own UUID, expressed as a URL through the @id property, provides a resolvable link to the full passport data. Multiple identifiers can coexist, enabling different systems to locate the same DPP using whichever identifier they have available.

Environmental data within the JSON-LD structure benefits from explicit unit declarations. Rather than assuming that a carbon footprint value is in kilogrammes of CO2 equivalent, the JSON-LD structure should explicitly declare the unit using a recognised vocabulary such as QUDT (Quantities, Units, Dimensions, and Types) or UN/CEFACT unit codes. This explicitness prevents misinterpretation when data crosses system and organisational boundaries.

Provenance metadata, who contributed each piece of data, when it was contributed, and under what authority, should be embedded within the JSON-LD structure using properties from vocabularies such as PROV-O (the W3C Provenance Ontology). This creates an auditable trail of data contributions that supports regulatory verification without requiring access to the DPP platform's internal records.

Search Engine Optimisation with DPP Structured Data

JSON-LD structured data embedded in DPP web pages provides significant search engine optimisation benefits. Google and other search engines use structured data to generate rich results, enhanced search listings that display product information, ratings, availability, and other details directly in search results.

For public-facing DPP pages, embedding JSON-LD structured data enables search engines to understand and display product sustainability information alongside standard product details. A rich result for a product page might display the product's energy efficiency rating, recycled content percentage, or durability score, information that increasingly influences consumer click-through rates.

The implementation pattern for embedded JSON-LD is straightforward: a script tag with type="application/ld+json" in the HTML head or body contains the complete JSON-LD document. This approach is search engine friendly, does not affect page rendering, and can be generated server-side as part of the normal page rendering process.

Structured data testing tools, Google's Rich Results Test, Schema.org's validator, and JSON-LD Playground, should be used to verify that embedded DPP structured data is correctly formatted and recognised by search engines. Common issues include missing required properties, incorrect nesting, and @context declarations that do not resolve correctly.

Beyond individual product pages, structured data can enhance organisational pages, product catalogue pages, and sustainability report pages. An organisation page with correct Schema.org Organisation markup, linked to its products via the makesOffer or manufacturer properties, creates a connected knowledge graph that search engines can traverse to understand the relationship between a company and its products.

Linked Data Principles for DPP Interoperability

JSON-LD is an implementation of the broader linked data paradigm, which follows four principles articulated by Tim Berners-Lee: use URIs to name things, use HTTP URIs so that those names can be looked up, provide useful information when someone looks up a URI, and include links to other URIs to enable discovery of related information.

Applied to DPPs, these principles mean that every entity in the DPP ecosystem, every product, material, supplier, certification, and lifecycle event, should have a globally unique, resolvable URI. When a recycler encounters a material URI in a DPP, they should be able to resolve that URI to retrieve detailed information about the material's properties, handling requirements, and recycling pathways.

Interlinking between DPPs creates a web of product data that enables powerful queries across the entire ecosystem. A regulator could traverse links from a product's DPP to its component DPPs to their material supplier records, verifying compliance at every level of the supply chain without requiring access to any single centralised database.

The practical challenge of linked data is maintaining resolvable URIs over time. Products have long lifecycles, a building material might remain in use for decades. The URIs in its DPP must remain resolvable throughout that period, requiring stable hosting, thoughtful URI design that avoids embedding volatile information (such as current owner or server name) in URIs, and institutional commitment to long-term data stewardship.

For practical guidance on implementing DPP identifiers using GS1 standards, which align well with linked data principles, see our GS1 Digital Link complete guide.

Extending Schema.org for DPP-Specific Requirements

While Schema.org provides a solid foundation for product structured data, DPP-specific requirements necessitate vocabulary extensions. The Schema.org extension mechanism supports this through the additionalProperty pattern and through community-developed extensions that add new types and properties.

The additionalProperty approach uses Schema.org's PropertyValue type to add arbitrary named properties to any entity. This is flexible but loses the semantic precision of dedicated vocabulary terms, a property named "recycledContent" as an additionalProperty is less machine-interpretable than a dedicated vocabulary term with a formal definition, expected value type, and relationship to other terms.

Dedicated DPP vocabulary development is underway through several standardisation efforts. The CIRPASS-2 project, funded by the European Commission, is piloting DPP data models, and the harmonised standards EN 18216 to EN 18223, cited by the Commission in July 2026, fix the data exchange, identifier, carrier, storage, API and interoperability framework that ESPR-compliant DPPs must follow, with sector vocabularies set by each delegated act. This vocabulary will define terms for product circularity metrics, material composition declarations, and lifecycle event types with the semantic precision that additionalProperty lacks.

In the interim, organisations implementing DPPs should use Schema.org terms wherever they exist, extend with additionalProperty for DPP-specific data, and plan for migration to dedicated DPP vocabulary terms as they become standardised. JSON-LD's context mechanism makes this migration relatively painless, updating the @context to point to new vocabulary URIs can change the semantic interpretation of existing data without modifying the data itself.

Validation and Quality Assurance for DPP JSON-LD

Validation of DPP JSON-LD data must operate at multiple levels: syntactic validation (is it valid JSON?), structural validation (does it conform to the expected JSON-LD structure?), semantic validation (do the vocabulary terms make sense in context?), and business rule validation (does the data meet DPP regulatory requirements?).

JSON Schema can validate the structural aspects of DPP JSON-LD documents, ensuring that required fields are present, values are of the correct type, and arrays contain the expected number of elements. However, JSON Schema operates on the JSON level and does not understand JSON-LD semantics, it cannot verify that @context references resolve correctly or that linked data identifiers are valid URIs.

SHACL (Shapes Constraint Language) provides semantic validation for linked data, enabling constraints such as "every Product must have at least one material declaration" or "carbon footprint values must be non-negative numbers with an associated unit." SHACL validation ensures that DPP data is not just structurally correct but semantically meaningful and internally consistent.

Automated validation pipelines should process all DPP data at the point of entry, whether submitted via API, file upload, or web form, and provide immediate, actionable feedback when validation fails. The validation report should distinguish between errors (data that cannot be accepted) and warnings (data that is technically valid but may indicate quality issues), enabling data contributors to prioritise their corrections.

Continuous monitoring of published DPP data catches issues that point-of-entry validation may miss: broken links to referenced resources, expired certifications that have not been renewed, and data that has become inconsistent with updated DPP requirements. Automated monitoring with alerting ensures that DPP data quality is maintained throughout the product lifecycle, not just at the point of initial publication.

Getting Started with JSON-LD for Your DPP Implementation

Implementing JSON-LD for your DPPs does not require a complete system overhaul. Start by adding JSON-LD structured data to your existing public product pages, this provides immediate SEO benefits and establishes the foundation for richer DPP data as your implementation matures.

Use Schema.org's Product type as your starting point, populating as many standard properties as your current data allows. Name, description, manufacturer, GTIN, and material are the minimum useful set. Add environmental properties using additionalProperty as your sustainability data becomes available. Each incremental addition of structured data increases the value of your DPP to consumers, search engines, and downstream data consumers.

Test your JSON-LD output rigorously using available validation tools. Parse the JSON to verify syntactic correctness, validate against your JSON Schema to verify structural compliance, and test with search engine structured data tools to verify that the data is correctly interpreted. Automated testing should be integrated into your deployment pipeline to catch regressions before they reach production.

For a comprehensive starting point on DPP creation, including structured data considerations, see our guide on what is a Digital Product Passport. JSON-LD and Schema.org provide the semantic layer that transforms your DPP data from a compliance document into a machine-readable knowledge resource that serves consumers, regulators, and the broader circular economy ecosystem.