Se si mappa un JSON-LD pulito e idiomatico sulla serializzazione EN 18223, la prima cosa che salta all’occhio è la sua estensione. Il formato di destinazione è notevolmente prolisso.
La norma EN 18223 è quella del CEN/CLC JTC 24 che definisce il modello di dati del Passaporto Digitale del Prodotto (DPP) - la forma in cui ogni DPP dovrà essere conforme non appena la norma sarà pubblicata nella Gazzetta Ufficiale dell’UE. In questa forma, ogni valore diventa un oggetto con un proprio elementId, dictionaryReference, objectType, valueDataType e value. Tre righe di dati di origine diventano venti.
Cosa comporta questa prolissità
La prolissità non è casuale, e vale la pena capire cosa comporta.
È ciò che diventa la semantica non appena non si può più dare per scontato che sia risolvibile apertamente online. Un documento JSON-LD veicola normalmente il significato tramite un @context: un link che il lettore segue per verificare il significato di un campo.
La norma EN 18223 deve funzionare anche quando il dizionario alla base di un campo è ECLASS o IEC CDD - entrambi a pagamento, nessuno dei quali risolvibile liberamente come un IRI @context aperto. Pertanto, la norma specifica il significato valore per valore: quale dizionario, quale voce, quale tipo, quale valore. Solo così rimane autosufficiente, quando non si può fare affidamento sul fatto che il lettore clicchi per approfondire.
Letta in questo modo, la prolissità non è un difetto di progettazione, ma una risposta razionale ai dizionari chiusi.
Il contrasto è concreto. I vocabolari su cui ci basiamo - l’OpenEPCIS DPP Core e le sue estensioni normative - sono pubblicati in forma aperta su ref.openepcis.io e rimangono liberamente risolvibili. Un unico riferimento @context racchiude il significato che un dizionario chiuso deve inserire al suo interno.
Perché la direzione è determinante
Ricostruire una semantica aperta a partire da un dizionario chiuso è il percorso più difficile. Al contrario, è semplice.
La nostra fonte JSON-LD contiene già tutti gli attributi richiesti dal modello della norma EN 18223: un riferimento alla proprietà, un riferimento al dizionario, un tipo di dati del valore, un array di lingue per ogni valore. Sono semplicemente espressi come oggetti JSON-LD tipizzati con IRI @context, anziché nella struttura piatta Entity-Attribute-Value della norma EN 18223.
Generare una vista conforme alla norma EN 18223 a partire da questi dati è un’operazione di formattazione: si prendono i campi già esistenti e li si adatta al formato di destinazione.
Il principio in una frase: una fonte con spazi dei nomi aperti trasforma ogni dizionario chiuso in una proiezione, per cui la verbosità è un prezzo che paga solo chi ha iniziato con un approccio chiuso. Noi non lo facciamo mai, perché il significato era presente fin dalla prima stesura.
Spazi dei nomi plurali anziché un vocabolario canonico
Il fatto che la nostra fonte abbia già questa forma è una scelta consapevole, non una coincidenza. Non costringiamo ogni regolamento in un unico vocabolario.
Ogni regolamento DPP dell’UE - batterie, tessili, elettronica e quelli ancora in arrivo - mantiene il proprio spazio dei nomi a monte: quello di GS1, quello dell’OpenEPCIS DPP Core, quello della rispettiva estensione del regolamento. Tutti si trovano in parallelo in un array @context, accanto a uno spazio dei nomi transpareo: volutamente snello per i pochi termini che non sono coperti da alcuno spazio dei nomi a monte.
La norma EN 18223, nella propria clausola introduttiva 0.2, richiede quasi esattamente questo: evitare ontologie specifiche per settore, consentire l’uso parallelo delle ontologie pubblicate per ciascun atto delegato e mantenere il livello orizzontale il più generico possibile.
Un’architettura basata su spazi dei nomi aperti e paralleli non solo è compatibile con l’intento della norma, ma è proprio ciò a cui rimanda il principio di progettazione della norma stessa.
Uno stress test: l’elenco degli attributi del Battery Pass
La prova sta nel modo in cui l’architettura accoglie un dizionario per il quale non è mai stata progettata.
La «Data Attribute Long List» del Battery Pass Consortium, versione 1.3, è un terzo dizionario che si discosta in modo indipendente sia dalla norma EN 18223 che dallo standard GS1: circa 100 attributi, denominazione propria, livelli di accesso propri, un’interpretazione dell’allegato XIII del regolamento sulle batterie da parte del consorzio.
L’abbiamo confrontato con il nostro modello di dati esistente. 91 dei 100 attributi sono stati assegnati senza modifiche a tipi di proprietà già esistenti. Una fonte basata su spazi dei nomi plurali integra un nuovo dizionario chiuso come ulteriore proiezione, senza imporre una ricostruzione.
A che punto è la norma
La norma EN 18223 e la sua norma gemella EN 18216, che definisce il formato di serializzazione concreto a cui fa riferimento la EN 18223, sono entrambe norme europee pubblicate.
Fanno parte della prima ondata pubblicata della serie CEN-CENELEC-JTC-24-DPP: sei delle otto norme; le restanti due - relative all’autenticazione e ai diritti di accesso - seguiranno nel corso dell’estate del 2026. La loro pubblicazione nella Gazzetta ufficiale dell’UE, che conferisce loro lo status di norme armonizzate e la presunzione di conformità, è prevista per la metà del 2026.
Il lato positivo
Nulla di tutto ciò rende la norma EN 18223 una norma sbagliata. La prolissità è il prezzo onesto da pagare per l’interoperabilità in un mondo in cui non tutti i dizionari sono accessibili, e la norma rende giustizia a questo mondo.
Il lato positivo è semplice: per chi utilizza già un JSON-LD pulito, la norma EN 18223 rappresenta un’estensione, non una ricostruzione da zero. La strada più costosa è l’altra: quella che deve percorrere chiunque sia partito da un dizionario chiuso.
Per chi, fin dalla prima riga, si basa su una semantica aperta e risolvibile, la prolissità della norma smette di essere un ostacolo. Diventa un formato di output che si genera all’occorrenza.