Ao mapear JSON-LD limpo e idiomático para a serialização alargada da norma EN 18223, o que salta à vista em primeiro lugar é a sua extensão. Esta forma é notavelmente prolixa.
A EN 18223 é a norma do CEN/CLC JTC 24 relativa à interoperabilidade do sistema do Passaporte Digital do Produto; a sua cláusula 4 define o modelo semântico e a cláusula 5.2 define a serialização. Esta serialização assume duas formas. A serialização comprimida, utilizada em funcionamento, utiliza o elementId de cada valor como chave do objeto e deixa a resolução de dictionaryReference e valueDataType a cargo do dicionário de dados. A forma alargada expõe tudo: cada valor transforma-se num objeto com o seu próprio elementId, dictionaryReference, objectType, valueDataType e value, e três linhas de dados de origem passam a ser vinte.
O que esta extensão proporciona
Esta extensão não é por acaso, e vale a pena compreender o que ela proporciona.
É o que resta da semântica assim que já não se pode partir do princípio de que esta é abertamente resolvível online. Um documento JSON-LD transmite normalmente significado através de um @context: um link que o leitor segue para consultar o significado de um campo.
A forma compactada só funciona se o leitor puder consultar o dicionário por trás de um campo. Isso falha quando o dicionário é o ECLASS ou o IEC CDD - ambos pagos, nenhum deles consultável gratuitamente como um IRI @context aberto. É aqui que a forma expandida justifica a sua extensão: ela especifica o significado valor a valor - qual o dicionário, qual a entrada, qual o tipo, qual o valor - e mantém-se autodescritiva, caso não se possa contar com que o leitor clique para aceder às informações.
Lida desta forma, a prolixidade não é um erro de construção, mas sim uma resposta racional aos dicionários fechados.
O contraste é concreto. Os vocabulários em que nos baseamos - o OpenEPCIS DPP Core e as suas extensões regulamentares - estão publicados abertamente em ref.openepcis.io e continuam a ser livremente resolvíveis. Uma única referência @context contém o significado que um dicionário fechado tem de inscrever.
Por que razão a direção é determinante
Reconstruir semântica aberta a partir de um dicionário fechado é o caminho mais difícil. O inverso é fácil.
A nossa fonte JSON-LD já contém todos os atributos exigidos pelo modelo da norma EN 18223: uma referência à propriedade, uma referência ao dicionário, um tipo de dados do valor e um array de idiomas por valor. Estes estão apenas expressos em objetos JSON-LD tipados com IRIs @context, em vez de na estrutura plana «Entidade-Atributo-Valor» da norma EN 18223.
Criar uma visualização EN 18223 a partir destes dados é uma tarefa de formatação: pegar nos campos já existentes e adaptá-los ao formato de destino.
O princípio numa frase: uma fonte com espaços de nomes abertos transforma cada dicionário fechado numa projeção, de modo que a prolixidade passa a ser um custo que só quem começou com um sistema fechado tem de suportar. Se o significado estiver aberto desde a primeira redação, esse custo desaparece por si só.
Espaços de nomes plurais em vez de um vocabulário canónico
O facto de a nossa fonte já ter esta forma é uma decisão consciente, não uma coincidência. Não forçamos cada regulamento a encaixar num único vocabulário.
Cada regulamento DPP da UE - baterias, têxteis, eletrónica e os que ainda estão por vir - mantém o seu próprio espaço de nomes a montante: o da GS1, o do OpenEPCIS DPP Core e o da respetiva extensão do regulamento. Todas se encontram em paralelo num array @context, ao lado de um espaço de nomes transpareo: deliberadamente reduzido para os poucos termos que não são abrangidos por nenhum espaço de nomes a montante.
A norma EN 18223 exige, na sua própria cláusula introdutória 0.3, quase exatamente isso: evitar ontologias específicas de setor, permitir a utilização paralela das ontologias publicadas por cada ato delegado e manter a camada horizontal o mais geral possível.
Uma arquitetura baseada em espaços de nomes abertos e paralelos não é apenas compatível com a intenção da norma. É precisamente para isso que aponta o próprio princípio de conceção da norma.
Um teste de resistência: a lista de atributos do Battery Pass
A prova reside na forma como a arquitetura integra um dicionário para o qual nunca foi concebida.
A «Data Attribute Long List» do Battery Pass Consortium, versão 1.3, é um terceiro dicionário que se afasta independentemente tanto da norma EN 18223 como da GS1: cerca de 100 atributos, nomenclatura própria, níveis de acesso próprios, uma interpretação do Anexo XIII do Regulamento das Baterias por parte do Consórcio.
Comparámo-lo com o nosso modelo de dados existente. 91 dos 100 atributos foram atribuídos, sem alterações, a tipos de propriedade já existentes. Uma fonte com espaços de nomes plurais integra um novo dicionário fechado como mais uma projeção - não impõe uma reconstrução.
O estado atual da norma
A EN 18223 e a sua norma irmã, a EN 18216 - que define o formato de serialização concreto a que a EN 18223 remete - são ambas normas europeias harmonizadas.
Fazem parte da primeira vaga publicada do conjunto CEN-CENELEC-JTC-24-DPP: seis das oito normas; as duas restantes - relativas à autenticação e aos direitos de acesso - seguir-se-ão no decorrer do verão de 2026. Estas seis normas foram citadas em 15 de julho de 2026 na Decisão de Execução (UE) 2026/1736, no Jornal Oficial da UE, o que lhes confere o estatuto de normas harmonizadas e, consequentemente, a presunção de conformidade com os artigos 10.º e 11.º do RGPD.
O lado positivo
Nada disto faz da EN 18223 uma norma errada. A prolixidade é o preço honesto da interoperabilidade num mundo em que nem todos os dicionários estão abertos, e a norma faz justiça a esse mundo.
O lado positivo é simples: para quem já utiliza JSON-LD limpo, a EN 18223 é uma projeção, não uma construção a partir do zero. O caminho mais dispendioso é o outro - aquele que todos têm de percorrer quem começou a partir de um dicionário fechado.
Para quem, desde a primeira linha, se baseia numa semântica aberta e resolvível, a prolixidade da norma deixa de ser um obstáculo. Torna-se um formato de saída que se gera quando necessário.