--- title: "JSON-LD за цифрови продуктови паспорти (и къде се вписва EPCIS 2.0) — qr3.app Blog" description: "Един DPP е полезен за машините само ако е машинночетим. Това ръководство показва реалния JSON-LD, който паспорт на qr3 предоставя чрез живия resolver, как един URL обслужва едновременно хора и машини чрез договаряне на съдържанието, и къде се вписва допълващият стандарт за събития EPCIS 2.0." canonical: "https://qr3.app/bg/blog/dpp-json-ld-epcis/" lang: "bg" robots: "index,follow,max-image-preview:large,max-snippet:-1" --- # JSON-LD за цифрови продуктови паспорти (и къде се вписва EPCIS 2.0) — qr3.app Blog > Един DPP е полезен за машините само ако е машинночетим. Това ръководство показва реалния JSON-LD, който паспорт на qr3 предоставя чрез живия resolver, как един URL обслужва едновременно хора и машини чрез договаряне на съдържанието, и къде се вписва допълващият стандарт за събития EPCIS 2.0. Canonical: [← Блог](/bg/blog/) [Ръководства](/bg/blog/category/tutorials/) 30 май 2026 г. 6 мин четене [Ръководства](/bg/blog/category/tutorials/) [dpp](/bg/blog/tag/dpp/)[json-ld](/bg/blog/tag/json-ld/)[epcis](/bg/blog/tag/epcis/)[gs1-digital-link](/bg/blog/tag/gs1-digital-link/)[interoperability](/bg/blog/tag/interoperability/) # JSON-LD за цифрови продуктови паспорти (и къде се вписва EPCIS 2.0) Един DPP е полезен за машините само ако е машинночетим. Това ръководство показва реалния JSON-LD, който паспорт на qr3 предоставя чрез живия resolver, как един URL обслужва едновременно хора и машини чрез договаряне на съдържанието, и къде се вписва допълващият стандарт за събития EPCIS 2.0. от **QR3 Redaktion** ![JSON-LD за цифрови продуктови паспорти (и къде се вписва EPCIS 2.0)](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/dpp-json-ld-epcis/hero.png) Един цифров продуктов паспорт е предназначен да бъде четен от хора *и* от машини: приемната система на рециклатор, митническо API, обхождащ маркетплейс краулер, скрипт на одитор по устойчивост. HTML страница само за хора не е достатъчна. Паспортът трябва да бъде **машинночетим** — структуриран товар, който програма може да разбере, свърже и обработи логически, без да го извлича чрез скрейпинг. Това ръководство е за разработчици, които задават очевидния следващ въпрос: *след като вече имам DPP, как машината реално го прочита?* Отговорът за qr3 е JSON-LD през публичния resolver. Ще покажем реалния отговор, ще обясним как един и същи URL обслужва хора и машини, и след това ще поставим EPCIS 2.0 — допълващия стандарт за събития на GS1 — в контекст. ## Какво означава машинна четимост за един DPP Машинна четимост е нещо повече от „връща JSON“. За един продуктов паспорт тя означава три неща: - **Структуриран** — полета, които парсер може да адресира (`gtin`, `name`, …), а не проза за скрейпинг. - **Типизиран и свързан** — термини, закотвени в споделени речници, така че `Product` да означава едно и също за всички. Това е *Linked Data* в JSON-LD. - **Стабилен за извличане** — един траен URL за всеки артикул, който скрипт може да `GET`-не през целия живот на продукта. JSON-LD (JSON for Linking Data) осигурява и трите. Това е обикновен JSON плюс `@context`, който съпоставя всеки ключ с термин в публичен речник — тук [schema.org](https://schema.org) и [GS1 Web Vocabulary](https://gs1.org/voc/). Краулер, който вече разбира schema.org, разбира паспорта с нулева персонализирана интеграция. ## DPP като JSON-LD (реален curl + проверен отговор) Всеки паспорт на qr3 се разрешава на URL по GS1 Digital Link: `https://qr3.app/dpp/{gtin}/{serial}`. Добавете `?format=jsonld`, за да поискате изгледа Linked Data. Срещу живото демо за батерия: ``` curl -s "https://qr3.app/dpp/09520000000011/DEMO-BAT-01?format=jsonld" ``` връща: ``` { "@context": ["https://schema.org", "https://gs1.org/voc/"], "@type": "Product", "gtin": "09520000000011", "name": "EcoMax 5000 (Demo)" } ``` Три неща, които заслужават внимание: - `@context` е **масив** от два речника — schema.org за общата мрежа и `gs1.org/voc/` за продуктовите термини на GS1. Ключовете се разрешават срещу и двата. - `@type: "Product"` казва на всеки потребител на Linked Data точно какъв тип същност е това. - Стойностите (`gtin`, `name`) са реални и живи — това е действителният товар, а не макет. В това е целият смисъл: скриптът на рециклатор не се нуждае от специфичен за qr3 клиент. Той прави HTTP `GET`, разбира JSON-LD, който вече познава, и чете GTIN и името на продукта направо. ## Един URL, две аудитории: договаряне на съдържанието Един и същи URL `https://qr3.app/dpp/{gtin}/{serial}` обслужва удобен за хора HTML паспорт *и* машинния изглед — сървърът решава какво да върне въз основа на това, което поиска извикващият. Два начина да поискате: | Искате | Query параметър | Или Accept хедър | | --- | --- | --- | | Човешка HTML страница | *(по подразбиране)* | `Accept: text/html` | | JSON-LD (Linked Data) | `?format=jsonld` | `Accept: application/ld+json` | | Обикновен JSON | `?format=json` | — | | Linkset (свързани ресурси) | `?format=linkset` | — | | DCAT-AP (метаданни за набор от данни) | `?format=dcat-ap` | — | Така камерата на телефон, която отваря QR кода, попада на четимия HTML паспорт, докато скрипт иска от *идентичния* URL `application/ld+json` и получава структурирани данни: ``` # Машинен изглед чрез договаряне с хедър — същият URL, без query string curl -s -H "Accept: application/ld+json" \ "https://qr3.app/dpp/09520000000011/DEMO-BAT-01" ``` Един идентификатор, един URL, много представяния. GTIN/serial остава стабилен; *изгледът* се адаптира към извикващия. Точно това прави един DPP едновременно траен и оперативно съвместим. ## Къде се вписва EPCIS 2.0 (събития срещу паспорт) Често следва въпросът: *а какво ще кажете за EPCIS — не е ли това стандартът на GS1 за това?* Важно разграничение: - Един **DPP** е **статичното описание на един продуктов артикул** — неговата идентичност, материали, въглероден отпечатък, рециклируемост. Той отговаря на въпроса *„какво е това нещо?“* JSON-LD по-горе е този моментен снимка. - **EPCIS 2.0** е стандартът на GS1 за **събития във веригата на доставки** — данните за видимост на *какво се е случило, къде, кога и защо*: артикул е въведен в обращение, изпратен, получен, рециклиран. Той отговаря на въпроса *„какво се случи с това нещо и къде е то?“* Те са **допълващи се, а не конкуриращи се**. Паспортът ви казва, че продуктът е батерия от 5,2 kWh с 35% рециклирано съдържание; верига от EPCIS събития би ви казала, че е произведена в Хамбург на дадена дата, изпратена през дистрибуционен център и пристигнала при рециклатор. Самият EPCIS 2.0 е дружелюбен към JSON/JSON-LD, така че двата споделят един и същи мироглед на Linked Data и едни и същи идентификатори на GS1 (GTIN + serial) като ключ за обединяване. > **Обхват на qr3 (бъдете точни):** qr3 **извежда DPP като JSON-LD** — точно това демонстрира тази публикация. qr3 **не** предоставя улавяне на EPCIS събития или EPCIS крайни точки. Третирайте EPCIS 2.0 тук като *концептуалния, допълващ* стандарт, който бихте възприели заедно с един DPP за пълна проследимост на веригата на доставки, а не като функция на qr3. И така, мисловният модел е: DPP-то (qr3, JSON-LD) е *листът с идентичността* на продукта; EPCIS 2.0 (отделна система) е неговият *дневник на пътуването*. Едни и същи идентификатори, отговор на два въпроса. ## Генериране на DPP, който предоставя JSON-LD Не правите нищо специално, за да „активирате“ JSON-LD — създайте паспорта и resolver-ът обслужва всяко представяне автоматично: ``` 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, }, }); // The passport now resolves at https://qr3.app/dpp/09520000000011/SN-00012345 // Humans get HTML; machines append ?format=jsonld (or send Accept: application/ld+json). console.log(passport.qr.svg); // QR encodes the GS1 Digital Link to the resolver ``` След като бъде създаден, URL-ът на артикула отговаря на двете аудитории незабавно — без допълнителна стъпка за публикуване за машинния изглед. ## Често задавани въпроси **Защо JSON-LD, а не обикновен JSON?** Обикновеният JSON е структуриран, но не е *самоописващ се*: потребителят трябва да научи имената на полетата ви. JSON-LD добавя `@context`, съпоставяйки всеки ключ с термини на schema.org / GS1, така че всеки потребител на Linked Data го разбира без персонализирана интеграция. Ако ви е нужно само бързо прочитане, `?format=json` все още е наличен. **Реализира ли qr3 EPCIS 2.0?** Не. qr3 извежда DPP като JSON-LD. EPCIS 2.0 е отделният, допълващ стандарт на GS1 за *събития* във веригата на доставки; бихте го пуснали успоредно, обединен чрез споделените GTIN + serial. **Как да получа машинния изглед?** Добавете `?format=jsonld` към URL-а на resolver-а или изпратете `Accept: application/ld+json`. И двата връщат един и същи товар Linked Data. **Стабилен ли е `@context`?** Той фиксира schema.org плюс GS1 Web Vocabulary (`gs1.org/voc/`) — и двата публични, версионирани речника, така че потребителите могат да разчитат на значенията на термините. ## Източници - [JSON-LD 1.1 (W3C Recommendation)](https://www.w3.org/TR/json-ld11/) - [GS1 Web Vocabulary](https://www.gs1.org/voc/) - [GS1 EPCIS and CBV 2.0](https://www.gs1.org/standards/epcis) - [schema.org Product](https://schema.org/Product) - [ESPR — Regulation (EU) 2024/1781](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) **Започнете безплатно** и създайте DPP, който предоставя JSON-LD: [app.qr3.app/sign-up](https://app.qr3.app/sign-up) Това са работещи демонстрации с измислени продуктови данни и примерни GTIN от префикса GS1 952. Те не доказват присвоени продуктови идентификатори, вписване в регистър или сертификация. ## Свързани статии - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/gs1-digital-link-resolver/hero.png) Ръководства GS1 Digital Link резолверът, обяснен (с жив пример) QR кодът на DPP не е връзка към уеб страница — той е GS1 Digital Link, а резолверът превръща един идентификатор в множество контекстно зависими отговори. Ето как работи това, заедно с жив паспорт, който можете да извикате с curl точно сега.](/bg/blog/gs1-digital-link-resolver/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/gs1-resolver-test-suite-dpp-links/hero.png) Ръководства Тестов пакет за резолвери: DPP-връзките да бъдат надеждно проверени преди пускане в продукция Стабилният тестов пакет на GS1 позволява проверка на Resolver 1.2. Така можете да тествате пренасочвания, набори от връзки, CORS, езици и грешки преди пускане в продукция.](/bg/blog/gs1-resolver-test-suite-dpp-links/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/dpp-battery-passport-2027-20260715/hero.png) Новини от бранша BatteryPass-Ready стартира тестова среда за цифровия паспорт на батерията На 24 юни 2026 г. консорциумът BatteryPass-Ready стартира публична тестова среда за цифровия паспорт на батерията с оглед на задължението на ЕС от февруари 2027 г.](/bg/blog/dpp-battery-passport-2027-20260715/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/sector-20260713/hero.png) Новини от бранша Дигитален паспорт на батерията 2027: Какво трябва да знаят производителите сега Уебинари, инструменти с отворен код и нови стандарти: паспортът на батерията на ЕС набира скорост. Преглед на състоянието през юли 2026 г. и откритите въпроси до февруари 2027 г.](/bg/blog/sector-20260713/) [← Всички статии](/bg/blog/) [Започни безплатно](https://app.qr3.app/sign-up)