Jeśli przełożymy czysty, idiomatyczny JSON-LD na serializację zgodną z normą EN 18223, od razu rzuca się w oczy jego rozmach. Format docelowy jest uderzająco rozbudowany.
EN 18223 to norma CEN/CLC JTC 24, która definiuje model danych cyfrowego paszportu produktu (DPP) - formę, do której każdy DPP będzie musiał się dostosować, gdy tylko norma zostanie opublikowana w Dzienniku Urzędowym UE. W tej formie każda wartość staje się obiektem z własnym elementId, dictionaryReference, objectType, valueDataType i value. Trzy wiersze danych źródłowych zamieniają się w dwadzieścia.
Co daje ta rozbudowa
Ta rozbudowanie jest przypadkowa i warto zrozumieć, co dzięki niej zyskujemy.
Jest to to, czym staje się semantyka, gdy nie można już zakładać, że jest ona otwarcie dostępna online. Dokument JSON-LD zazwyczaj przekazuje znaczenie poprzez @context: link, pod którym czytelnik może sprawdzić, co oznacza dane pole.
Norma EN 18223 musi działać nawet wtedy, gdy słownik stojący za polem to ECLASS lub IEC CDD - oba są płatne, a żadnego z nich nie da się zidentyfikować za darmo, tak jak w przypadku otwartego IRI @context. Dlatego norma określa znaczenie dla każdej wartości z osobna: który słownik, który wpis, jaki typ, jaka wartość. Tylko w ten sposób pozostaje ona samopisująca, gdy nie można polegać na tym, że czytelnik będzie klikał dalej.
W tym ujęciu rozbudowana forma nie jest błędem konstrukcyjnym, lecz racjonalną odpowiedzią na zamknięte słowniki.
Kontrast jest wyraźny. Słowniki, na których się opieramy - OpenEPCIS DPP Core i jego rozszerzenia wynikające z rozporządzeń - są opublikowane na zasadach otwartego dostępu pod adresem ref.openepcis.io i pozostają swobodnie rozdzielalne. Pojedyncze odwołanie @context niesie ze sobą znaczenie, które musi zostać zapisane w zamkniętym słowniku.
Dlaczego kierunek ma znaczenie
Rekonstruowanie otwartej semantyki na podstawie zamkniętego słownika to trudny kierunek działania. W odwrotnym kierunku jest to proste.
Nasze źródło JSON-LD zawiera już wszystkie atrybuty wymagane przez model normy EN 18223: odwołanie do właściwości, odwołanie do słownika, typ danych wartości oraz tablicę języków dla każdej wartości. Są one jednak wyrażone wyłącznie jako typizowane obiekty JSON-LD z identyfikatorami IRI @context, a nie w płaskiej strukturze „entity-attribute-value” wymaganej przez normę EN 18223.
Wygenerowanie widoku zgodnego z normą EN 18223 na podstawie tych danych jest zadaniem formatowania: polega na wykorzystaniu już istniejących pól i nadaniu im docelowej formy.
Zasada w jednym zdaniu: źródło z otwartymi przestrzeniami nazw tworzy projekcję z każdego zamkniętego słownika, tak więc rozbudowanie jest ceną, którą płaci tylko ten, kto zaczął od zamkniętego słownika. My nigdy tego nie robimy, ponieważ znaczenie było obecne od samego początku pisania.
Liczne przestrzenie nazw zamiast kanonicznego słownika
To, że nasze źródło ma już tę formę, jest świadomą decyzją, a nie przypadkiem. Nie wtłaczamy każdego rozporządzenia do jednego słownika.
Każde rozporządzenie UE dotyczące DPP - dotyczące baterii, tekstyliów, elektroniki oraz te, które jeszcze nadejdą - zachowuje własną przestrzeń nazw nadrzędną: przestrzeń GS1, przestrzeń OpenEPCIS DPP Core oraz przestrzeń danego rozszerzenia rozporządzenia. Wszystkie znajdują się równolegle w tablicy @context, obok celowo uproszczonej przestrzeni nazw transpareo: przeznaczonej dla nielicznych pojęć, których nie obejmuje żadna z przestrzeni nazw wyższego poziomu.
Norma EN 18223 w swojej własnej klauzuli wstępnej 0.2 wymaga niemal dokładnie tego: unikania ontologii specyficznych dla poszczególnych sektorów, zezwalania na równoległe stosowanie ontologii wydawanych dla każdego delegowanego aktu prawnego oraz utrzymywania warstwy horyzontalnej w jak najbardziej ogólnym kształcie.
Architektura oparta na otwartych, równoległych przestrzeniach nazw jest nie tylko zgodna z intencją normy. Jest ona tym, na co wskazuje sama zasada projektowa normy.
Test wytrzymałościowy: lista atrybutów Battery Pass
Dowodem na to jest sposób, w jaki architektura przyjmuje słownik, do obsługi którego nigdy nie została stworzona.
Długa lista atrybutów danych (Data Attribute Long List) konsorcjum Battery Pass, wersja 1.3, stanowi trzeci słownik, który odbiega niezależnie zarówno od normy EN 18223, jak i od standardu GS1: około 100 atrybutów, własna nomenklatura, własne poziomy dostępu, interpretacja załącznika XIII do rozporządzenia w sprawie baterii przedstawiona przez konsorcjum.
Porównaliśmy go z naszym istniejącym modelem danych. 91 ze 100 atrybutów trafiło bez zmian do już istniejących typów właściwości. Źródło oparte na wielości przestrzeni nazw traktuje nowy, zamknięty słownik jako kolejną projekcję - nie wymusza to przebudowy.
Stan normy
EN 18223 oraz jej norma siostrzana EN 18216, która definiuje konkretny format serializacji, do którego odwołuje się EN 18223, są normami europejskimi, które zostały opublikowane.
Należą one do pierwszej opublikowanej serii zestawu CEN-CENELEC-JTC-24-DPP: sześć z ośmiu norm, a pozostałe dwie - dotyczące uwierzytelniania i praw dostępu - pojawią się w ciągu lata 2026 roku. Ich publikacja w Dzienniku Urzędowym UE, nadająca im status norm zharmonizowanych i domniemanie zgodności, spodziewana jest w połowie 2026 roku.
Pozytywna strona
Żadna z tych kwestii nie sprawia, że norma EN 18223 jest niewłaściwa. Rozbudowana struktura jest uczciwą ceną za interoperacyjność w świecie, w którym nie każdy słownik jest otwarty, a norma ta odpowiada realiom tego świata.
Pozytywna strona jest prosta: dla tych, którzy już korzystają z czystego JSON-LD, norma EN 18223 stanowi jedynie projekcję, a nie budowę od podstaw. Kosztownym kierunkiem jest ten drugi - ten, którym musi podążać każdy, kto zaczynał od zamkniętego słownika.
Dla tych, którzy od pierwszego wiersza opierają się na otwartej, rozdzielalnej semantyce, rozbudowany charakter normy przestaje być obciążeniem. Staje się formatem wyjściowym, który generuje się w razie potrzeby.