Machine-Readable DPP: Formats and Standards

Šis straipsnis dar neišverstas į jūsų kalbą, todėl rodomas anglų kalba.

Why Machine Readability Is Fundamental to DPPs

The EU ESPR regulation requires that Digital Product Passport data be accessible not only to human consumers viewing web pages but also to automated systems that process product information at scale. Customs authorities need to query DPP data programmatically during border inspections. Recycling facilities need to extract material composition data automatically to optimise sorting processes. Retail platforms need to ingest sustainability information for product listings without manual data entry.

Machine readability means that software can parse, interpret, and act upon DPP data without human intervention. This requires standardised data formats, consistent vocabularies, and well-defined protocols for accessing the data. A beautifully designed web page that presents product information clearly to humans but wraps it in unstructured HTML is not machine-readable, a programme cannot reliably extract the carbon footprint value from a paragraph of marketing text.

Implementing machine-readable DPP formats from the start is far more efficient than retrofitting them later. This guide covers the key formats, standards, and implementation approaches for delivering DPP data that serves both human and machine consumers effectively.

JSON-LD: The Preferred Format for Linked DPP Data

JSON-LD (JSON for Linking Data) has emerged as the preferred format for machine-readable DPP data. It extends standard JSON with a context mechanism that maps property names to globally unique identifiers, enabling unambiguous data interpretation across different systems.

A JSON-LD representation of a DPP includes a @context property that references the vocabulary being used, typically Schema.org for general product information, augmented with DPP-specific extensions. This context tells any consuming system exactly what each field means: "carbonFootprint" is not just a string label but a reference to a specific concept with a defined meaning, unit of measurement, and calculation methodology.

The key advantages of JSON-LD for DPPs are its compatibility with standard JSON tooling (any JSON parser can read it), its support for linked data principles (properties and types can reference external definitions), and its adoption by major search engines for structured data. Google, Bing, and other search engines already process JSON-LD embedded in web pages, meaning your DPP data can improve product visibility in search results.

When implementing JSON-LD for your DPP platform, use the @graph structure to represent complex product data with multiple related entities. A product's passport typically includes the product itself, its manufacturer, material components, compliance certifications, and environmental metrics, each as a distinct node in the graph with explicit relationships. This graph structure supports complex queries like "find all products from this manufacturer that contain recycled material above 50%" without requiring bespoke API endpoints.

GS1 Standards for Product Identification and Data Exchange

The GS1 standards suite provides the foundation for product identification in DPP systems. The GS1 Digital Link standard defines how product identifiers are encoded in URLs, enabling a single QR code to serve as both a consumer-facing web link and a machine-readable product identifier.

A GS1 Digital Link URL encodes the Global Trade Item Number (GTIN) and optional serial number in its path structure. For example, https://example.com/01/09506000134352/21/ABC123 identifies a specific product instance. Any system that understands the GS1 Digital Link syntax can extract the GTIN and serial number programmatically, enabling automated product lookups across different DPP platforms.

GS1 also maintains the Electronic Product Code Information Services (EPCIS) standard for recording supply chain events. EPCIS provides a standardised format for answering the "what, when, where, why" questions about products: what product was involved, when the event occurred, where it happened, and why (the business context). DPP platforms that adopt EPCIS for their supply chain event data gain immediate interoperability with the vast ecosystem of supply chain management tools that already support this standard.

Combining GS1 Digital Link for identification with EPCIS for event data and JSON-LD for passport content creates a comprehensive machine-readable DPP architecture. Each standard handles its area of expertise, and their integration through shared identifiers (GTINs) creates a cohesive data model that supports the full range of DPP use cases.

XML and Legacy Integration Formats

Whilst JSON-LD is the modern standard for DPP data, many enterprise systems in supply chain, customs, and regulatory domains still operate on XML-based data exchange. Supporting XML as an alternative output format for your DPP platform ensures compatibility with these systems.

The relevant XML standards for DPP data include GS1 XML (a suite of business message standards used extensively in retail and healthcare supply chains), XBRL (used for reporting sustainability metrics in financial contexts), and ebXML (used for international trade document exchange). Customs authorities in particular may require XML-formatted data that conforms to World Customs Organization standards.

When implementing XML support alongside JSON-LD, maintain a single internal data model and transform it to the requested format at the point of delivery. This ensures consistency, the same underlying data appears regardless of which format the client requests. Use XSLT transformations or dedicated serialisation libraries rather than building separate data pipelines for each format, which would inevitably diverge over time.

For DPP platforms that need to exchange data with ERP systems like SAP or Oracle, the IDoc and BOD formats respectively are often the most pragmatic choice. These systems have native support for their proprietary formats, and attempting to force JSON-LD through them often introduces unnecessary complexity. Provide adapters or middleware that translate between your DPP data model and these enterprise formats.

Content Negotiation for Multi-Format DPP Delivery

A well-implemented DPP platform serves the same product passport in multiple formats from a single URL, selecting the appropriate format based on the client's request. This is achieved through HTTP content negotiation, the client sends an Accept header indicating its preferred format, and the server responds accordingly.

The standard content negotiation configuration for a DPP endpoint should support at minimum:

• text/html, returns a human-readable web page with embedded JSON-LD structured data, served to web browsers and search engine crawlers.
• application/ld+json, returns the pure JSON-LD representation of the passport data, used by linked data clients and semantic web applications.
• application/json, returns a standard JSON representation without the JSON-LD context, used by conventional API clients that do not need linked data features.
• application/xml, returns an XML representation conforming to relevant industry schemas, used by enterprise systems and customs authorities.
• text/turtle, returns an RDF Turtle representation for clients in the semantic web ecosystem that prefer this format over JSON-LD.

Implement content negotiation at the web server or application framework level using the Accept header with quality values. When a client sends Accept: application/ld+json;q=1, application/json;q=0.8, the server should return JSON-LD as the preferred format. When no Accept header is present or it specifies */* (accept anything), default to text/html to provide the best experience for browser users.

Content negotiation enables a single GS1 Digital Link URL to serve every consumer of your DPP data. The same URL that a consumer scans with their phone (receiving HTML) is the same URL a customs system queries programmatically (receiving XML) and the same URL a search engine indexes (receiving JSON-LD). This simplicity is a key design principle of the DPP ecosystem.

Vocabulary and Ontology Standards for DPP Data

Machine readability requires not just structured formats but shared vocabularies, agreed-upon terms and definitions for the concepts represented in DPP data. Without shared vocabularies, one system's "recyclability_score" might mean something entirely different from another system's "recycling_index", even if both contain the same underlying metric.

Schema.org provides the broadest vocabulary for product information, with types like Product, Offer, and Organization and properties like material, weight, and manufacturer. For general product attributes, Schema.org terms should be your first choice because of their wide adoption and tooling support.

The European Commission's standardisation request to CEN and CENELEC has produced the first harmonised DPP standards, EN 18216 to EN 18223 on data exchange protocols, unique identifiers, data carriers, storage and persistence, APIs and system interoperability, cited in Implementing Decision (EU) 2026/1736 of 14 July 2026. Sector vocabularies for ESPR-mandated data fields, such as durability scores, recycled content percentages and substance of concern declarations, follow in each delegated act. As these are finalised, DPP platforms should adopt them to ensure regulatory interoperability.

When existing vocabularies do not cover your data needs, extend them rather than creating entirely new ones. JSON-LD's context mechanism allows you to mix terms from multiple vocabularies in a single document. Use Schema.org for general product attributes, GS1 vocabularies for supply chain identifiers, and your own namespace for proprietary attributes, all within the same JSON-LD document. Document your extensions clearly so that consuming systems can interpret them correctly.

Validating Machine-Readable DPP Outputs

Producing machine-readable data is only valuable if the output is actually valid and parseable. Implement automated validation for every machine-readable format your DPP platform produces.

For JSON-LD, validate against both the JSON Schema for structural correctness and the JSON-LD specification for linked data compliance. Use a JSON-LD processor to verify that the @context resolves correctly, that all type references point to valid vocabulary terms, and that the graph structure is well-formed. The JSON-LD Playground tool is useful for manual verification during development.

Validation checks for machine-readable DPP outputs should cover:

• Syntax validity, the output is well-formed JSON, XML, or other format and can be parsed without errors by standard tools.
• Schema compliance, required fields are present, data types are correct, and values fall within permitted ranges.
• Vocabulary correctness, all property names and type references resolve to valid terms in the declared vocabularies.
• Link integrity, all URLs referenced in the data (document links, related product references, external vocabulary terms) are accessible and return appropriate content.
• Equivalence, the same underlying data is consistently represented across all supported output formats, with no information lost or altered during format transformation.

Include machine-readable output validation in your continuous integration pipeline. Every code change that could affect DPP data serialisation should trigger automated tests that generate outputs in all supported formats and validate them against their respective specifications. This prevents regression, an innocent-looking code change that breaks XML serialisation will be caught before it reaches production.

Implementing Machine-Readable DPPs in Practice

For organisations beginning their machine-readable DPP implementation, a pragmatic starting point is to implement JSON-LD with Schema.org vocabulary and HTML with embedded structured data. These two representations cover the vast majority of use cases, consumer browsing, search engine indexing, and programmatic data access, whilst using widely supported standards with mature tooling.

Start by defining your internal data model based on the DPP interoperability standards relevant to your product categories. Map each internal field to its Schema.org equivalent, noting any fields that require vocabulary extensions. Build serialisers that transform your internal model to JSON-LD and HTML representations, with clear separation between data logic and presentation formatting.

Test your machine-readable outputs rigorously. Use Google's Rich Results Test to verify that search engines can parse your embedded structured data. Use JSON-LD processors to validate your linked data output. Share sample outputs with supply chain partners and ask them to confirm they can parse and interpret the data correctly in their systems.

As your DPP platform matures, add support for additional formats based on actual demand from your ecosystem. If customs authorities require XML, add XML serialisation. If supply chain partners use EPCIS, add event data in that format. Each additional format extends your reach without changing your underlying data model, demonstrating the value of building on standards from the start rather than creating proprietary formats that limit interoperability.

Future Directions in Machine-Readable DPP Standards

The machine-readable DPP landscape is evolving rapidly as the EU ESPR implementation progresses. Several developments will shape the standards ecosystem over the coming years.

The European Commission's delegated acts for specific product categories will define mandatory data fields and their machine-readable representations. These acts will likely reference specific vocabularies and encoding requirements, narrowing the current flexibility in how DPP data is structured. Platforms that have adopted the emerging consensus standards, JSON-LD, GS1 Digital Link, Schema.org, will be well-positioned to adapt to these requirements with minimal changes.

Verifiable Credentials (VCs), based on W3C standards, are emerging as a mechanism for attaching cryptographically verifiable claims to DPP data. A compliance certification could be issued as a VC by an accredited body, allowing any consuming system to verify its authenticity without contacting the issuer. This approach bridges the gap between machine readability and trust, addressing the question of not just what the data says but who said it and whether they are authoritative.

Regardless of how specific standards evolve, the fundamental principle remains constant: DPP data must be structured, standardised, and accessible to both humans and machines. Organisations that invest in machine-readable DPP implementation today are building the foundation for long-term compliance and interoperability in an increasingly connected product data ecosystem.