--- title: "JSON-LD für Digitale Produktpässe (und wo EPCIS 2.0 hineinpasst) — qr3.app Blog" description: "Ein DPP nützt Maschinen nur, wenn er maschinenlesbar ist. Dieser Leitfaden zeigt das echte JSON-LD, das ein qr3-Passport über den Live-Resolver liefert, wie eine URL via Content Negotiation Mensch und Maschine bedient, und wo der komplementäre EPCIS-2.0-Eventstandard hineinpasst." canonical: "https://qr3.app/de/blog/dpp-json-ld-epcis/" lang: "de" robots: "index,follow,max-image-preview:large,max-snippet:-1" --- # JSON-LD für Digitale Produktpässe (und wo EPCIS 2.0 hineinpasst) — qr3.app Blog > Ein DPP nützt Maschinen nur, wenn er maschinenlesbar ist. Dieser Leitfaden zeigt das echte JSON-LD, das ein qr3-Passport über den Live-Resolver liefert, wie eine URL via Content Negotiation Mensch und Maschine bedient, und wo der komplementäre EPCIS-2.0-Eventstandard hineinpasst. Canonical: [← Blog](/de/blog/) [Tutorials](/de/blog/kategorie/tutorials/) 30. Mai 2026 6 min Lesezeit [Tutorials](/de/blog/kategorie/tutorials/) [dpp](/de/blog/tag/dpp/)[json-ld](/de/blog/tag/json-ld/)[epcis](/de/blog/tag/epcis/)[gs1-digital-link](/de/blog/tag/gs1-digital-link/)[interoperability](/de/blog/tag/interoperability/) # JSON-LD für Digitale Produktpässe (und wo EPCIS 2.0 hineinpasst) Ein DPP nützt Maschinen nur, wenn er maschinenlesbar ist. Dieser Leitfaden zeigt das echte JSON-LD, das ein qr3-Passport über den Live-Resolver liefert, wie eine URL via Content Negotiation Mensch und Maschine bedient, und wo der komplementäre EPCIS-2.0-Eventstandard hineinpasst. von **QR3 Redaktion** ![JSON-LD für Digitale Produktpässe (und wo EPCIS 2.0 hineinpasst)](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/dpp-json-ld-epcis/hero.png) Ein Digitaler Produktpass soll von Menschen *und* von Maschinen gelesen werden: dem Wareneingangssystem eines Recyclers, einer Zoll-API, einem Marktplatz-Crawler, dem Skript eines Nachhaltigkeitsprüfers. Eine reine HTML-Seite reicht nicht. Der Pass muss **maschinenlesbar** sein — eine strukturierte Nutzlast, die ein Programm parsen, verknüpfen und auswerten kann, ohne zu scrapen. Dieser Leitfaden richtet sich an Entwickler mit der naheliegenden Anschlussfrage: *Ich habe einen DPP — wie liest eine Maschine ihn tatsächlich?* Die Antwort bei qr3 ist JSON-LD über den öffentlichen Resolver. Wir zeigen die echte Antwort, erklären, wie dieselbe URL Mensch und Maschine bedient, und ordnen dann EPCIS 2.0 — den komplementären GS1-Eventstandard — ein. ## Was Maschinenlesbarkeit für einen DPP bedeutet Maschinenlesbar ist mehr als „liefert JSON". Für einen Produktpass heißt es drei Dinge: - **Strukturiert** — Felder, die ein Parser adressieren kann (`gtin`, `name`, …), keine Prosa zum Scrapen. - **Typisiert und verknüpft** — Begriffe verankert in gemeinsamen Vokabularen, damit `Product` für alle dasselbe bedeutet. Das ist das *Linked Data* in JSON-LD. - **Stabil abrufbar** — eine dauerhafte URL pro Artikel, die ein Skript über die gesamte Produktlebensdauer per `GET` abfragen kann. JSON-LD (JSON for Linking Data) liefert alle drei. Es ist gewöhnliches JSON plus einem `@context`, der jeden Schlüssel auf einen Begriff in einem öffentlichen Vokabular abbildet — hier [schema.org](https://schema.org) und das [GS1-Web-Vokabular](https://gs1.org/voc/). Ein Crawler, der schema.org bereits versteht, versteht den Pass ohne jede Sonderintegration. ## Der DPP als JSON-LD (echtes curl + verifizierte Antwort) Jeder qr3-Pass löst unter einer GS1-Digital-Link-URL auf: `https://qr3.app/dpp/{gtin}/{serial}`. Hänge `?format=jsonld` an, um die Linked-Data-Ansicht anzufordern. Gegen die Live-Batterie-Demo: ``` curl -s "https://qr3.app/dpp/09520000000011/DEMO-BAT-01?format=jsonld" ``` liefert: ``` { "@context": ["https://schema.org", "https://gs1.org/voc/"], "@type": "Product", "gtin": "09520000000011", "name": "EcoMax 5000 (Demo)" } ``` Drei Dinge fallen auf: - `@context` ist ein **Array** aus zwei Vokabularen — schema.org für das allgemeine Web und `gs1.org/voc/` für die GS1-Produktbegriffe. Schlüssel lösen gegen beide auf. - `@type: "Product"` sagt jedem Linked-Data-Konsumenten exakt, um welche Art Entität es sich handelt. - Die Werte (`gtin`, `name`) sind echt und live — das ist die tatsächliche Nutzlast, kein Mock. Genau das ist der Punkt: Das Skript eines Recyclers braucht keinen qr3-spezifischen Client. Es macht ein HTTP-`GET`, parst JSON-LD, das es ohnehin versteht, und liest GTIN und Produktname direkt heraus. ## Eine URL, zwei Zielgruppen: Content Negotiation Dieselbe URL `https://qr3.app/dpp/{gtin}/{serial}` bedient einen menschenfreundlichen HTML-Pass *und* die Maschinenansicht — der Server entscheidet anhand dessen, was der Aufrufer anfordert, was er zurückgibt. Zwei Wege zu fragen: | Du willst | Query-Parameter | Oder Accept-Header | | --- | --- | --- | | Menschliche HTML-Seite | *(Standard)* | `Accept: text/html` | | JSON-LD (Linked Data) | `?format=jsonld` | `Accept: application/ld+json` | | Schlichtes JSON | `?format=json` | — | | Linkset (verwandte Ressourcen) | `?format=linkset` | — | | DCAT-AP (Datensatz-Metadaten) | `?format=dcat-ap` | — | Eine Handykamera, die den QR öffnet, landet also auf dem lesbaren HTML-Pass, während ein Skript dieselbe URL nach `application/ld+json` fragt und strukturierte Daten erhält: ``` # Maschinenansicht per Header-Negotiation — gleiche URL, kein Query-String curl -s -H "Accept: application/ld+json" \ "https://qr3.app/dpp/09520000000011/DEMO-BAT-01" ``` Ein Identifikator, eine URL, viele Repräsentationen. GTIN/Seriennummer bleibt stabil; die *Ansicht* passt sich dem Aufrufer an. Genau das macht einen DPP zugleich langlebig und interoperabel. ## Wo EPCIS 2.0 hineinpasst (Events vs. Pass) Eine häufige Anschlussfrage: *Was ist mit EPCIS — ist das nicht der GS1-Standard dafür?* Wichtige Unterscheidung: - Ein **DPP** ist die **statische Beschreibung eines Produktartikels** — seine Identität, Materialien, CO₂-Fußabdruck, Recyclingfähigkeit. Er beantwortet *„Was ist dieses Ding?"* Das obige JSON-LD ist dieser Schnappschuss. - **EPCIS 2.0** ist der GS1-Standard für **Lieferketten-Events** — die Sichtbarkeitsdaten von *was wann wo und warum geschah*: ein Artikel wurde angelegt, versendet, empfangen, recycelt. Er beantwortet *„Was geschah mit diesem Ding, und wo ist es?"* Sie sind **komplementär, nicht konkurrierend**. Der Pass sagt dir, dass das Produkt eine 5,2-kWh-Batterie mit 35 % Rezyklatanteil ist; eine EPCIS-Eventspur würde dir sagen, dass sie an einem bestimmten Tag in Hamburg gefertigt, über ein Verteilzentrum verschickt und bei einem Recycler angekommen ist. EPCIS 2.0 selbst ist JSON/JSON-LD-freundlich, sodass beide dasselbe Linked-Data-Weltbild und dieselben GS1-Identifikatoren (GTIN + Seriennummer) als Verknüpfungsschlüssel teilen. > **qr3-Scope (präzise):** qr3 **gibt den DPP als JSON-LD aus** — genau das zeigt dieser Beitrag. qr3 bietet **kein** EPCIS-Event-Capture und keine EPCIS-Endpunkte. Behandle EPCIS 2.0 hier als den *konzeptionellen, komplementären* Standard, den du neben einem DPP für vollständige Lieferketten-Rückverfolgbarkeit einsetzen würdest — nicht als qr3-Feature. Das mentale Modell lautet also: Der DPP (qr3, JSON-LD) ist das *Stammdatenblatt* des Produkts; EPCIS 2.0 (separates System) ist sein *Fahrtenbuch*. Dieselben Identifikatoren, zwei beantwortete Fragen. ## Einen DPP erzeugen, der JSON-LD bereitstellt Du musst nichts Besonderes tun, um JSON-LD zu „aktivieren" — lege den Pass an, und der Resolver liefert automatisch jede Repräsentation: ``` import { QR3 } from "@qr3/sdk"; const client = new QR3({ apiKey: process.env.QR3_API_KEY! }); const passport = await client.dpp.create({ gtin: "09520000000011", serial: "SN-00012345", product_name: "PowerCell 5 kWh LFP", manufacturer: "ExampleTech GmbH", origin_country: "DE", category: "battery", market_countries: ["DE", "FR", "AT"], status: "live", battery_data: { capacity_kwh: 5, carbon_footprint_kg: 62, recycled_content_pct: 12, recyclability_pct: 95, }, }); // Der Pass löst nun unter https://qr3.app/dpp/09520000000011/SN-00012345 auf. // Menschen erhalten HTML; Maschinen hängen ?format=jsonld an (oder senden Accept: application/ld+json). console.log(passport.qr.svg); // QR kodiert den GS1 Digital Link zum Resolver ``` Einmal angelegt, beantwortet die Artikel-URL sofort beide Zielgruppen — kein zusätzlicher Publish-Schritt für die Maschinenansicht. ## FAQ **Warum JSON-LD und nicht schlichtes JSON?** Schlichtes JSON ist strukturiert, aber nicht *selbstbeschreibend*: Ein Konsument muss deine Feldnamen lernen. JSON-LD ergänzt `@context` und bildet jeden Schlüssel auf schema.org-/GS1-Begriffe ab, sodass jeder Linked-Data-Konsument es ohne Sonderintegration versteht. Brauchst du nur einen schnellen Lesezugriff, steht weiterhin `?format=json` bereit. **Implementiert qr3 EPCIS 2.0?** Nein. qr3 gibt den DPP als JSON-LD aus. EPCIS 2.0 ist der separate, komplementäre GS1-Standard für Lieferketten-*Events*; du würdest ihn daneben betreiben, verknüpft über die gemeinsame GTIN + Seriennummer. **Wie bekomme ich die Maschinenansicht?** Hänge `?format=jsonld` an die Resolver-URL an oder sende `Accept: application/ld+json`. Beide liefern dieselbe Linked-Data-Nutzlast. **Ist der `@context` stabil?** Er fixiert schema.org plus das GS1-Web-Vokabular (`gs1.org/voc/`) — beides öffentliche, versionierte Vokabulare, sodass sich Konsumenten auf die Begriffsbedeutungen verlassen können. ## Quellen - [JSON-LD 1.1 (W3C Recommendation)](https://www.w3.org/TR/json-ld11/) - [GS1-Web-Vokabular](https://www.gs1.org/voc/) - [GS1 EPCIS und CBV 2.0](https://www.gs1.org/standards/epcis) - [schema.org Product](https://schema.org/Product) - [ESPR — Verordnung (EU) 2024/1781](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) **Kostenlos starten** und einen DPP erzeugen, der JSON-LD bereitstellt: [app.qr3.app/sign-up](https://app.qr3.app/sign-up) Dies sind funktionierende Demos mit fiktiven Produktdaten und Beispiel-GTINs aus dem GS1-Präfix 952. Sie belegen keine zugeteilten Produktkennungen, keinen Registereintrag und keine Zertifizierung. ## Verwandte Beiträge - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/gs1-digital-link-resolver/hero.png) Tutorials Der GS1-Digital-Link-Resolver – erklärt (mit Live-Beispiel) Ein DPP-QR-Code ist kein Link auf eine Webseite — er ist ein GS1 Digital Link, und der Resolver macht aus einem Identifier viele kontextabhängige Antworten. So funktioniert er, mit einem Live-Passport, den du sofort per curl abrufen kannst.](/de/blog/gs1-digital-link-resolver/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/gs1-resolver-test-suite-dpp-links/hero.png) Tutorials GS1 Resolver Test Suite: DPP-Links vor dem Go-live belastbar prüfen Die stabile GS1-Test-Suite macht Resolver 1.2 prüfbar. So testen Sie Redirects, Linksets, CORS, Sprachen und Fehlerfälle vor dem Go-live.](/de/blog/gs1-resolver-test-suite-dpp-links/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/dpp-battery-passport-2027-20260715/hero.png) Branchen-News BatteryPass-Ready startet Testumgebung für den Digitalen Batteriepass Das Konsortium BatteryPass-Ready hat am 24. Juni 2026 eine öffentliche Testumgebung für den Digitalen Batteriepass gestartet – mit Blick auf die EU-Pflicht ab Februar 2027.](/de/blog/dpp-battery-passport-2027-20260715/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/sector-20260713/hero.png) Branchen-News Digitaler Batteriepass 2027: Was Hersteller jetzt wissen müssen Webinare, Open-Source-Tools und neue Normen: Der EU-Batteriepass nimmt Fahrt auf. Ein Überblick über den Stand im Juli 2026 und die offenen Fragen bis Februar 2027.](/de/blog/sector-20260713/) [← Alle Artikel](/de/blog/) [Kostenlos starten](https://app.qr3.app/sign-up)