Ao mapear JSON-LD limpo e idiomático para a serialização EN 18223, o que salta à vista em primeiro lugar é a sua extensão. O formato de destino é notavelmente prolixo.
A EN 18223 é a norma do CEN/CLC JTC 24 que define o modelo de dados do Passaporte Digital do Produto (DPP) - o formato ao qual todos os DPP têm de se adequar assim que a norma for publicada no Jornal Oficial da UE. Nesta forma, cada valor transforma-se num objeto com o seu próprio elementId, dictionaryReference, objectType, valueDataType e value. Três linhas de dados de origem passam a ser vinte.
O que esta prolixidade proporciona
A prolixidade não é por acaso, e vale a pena compreender o que ela proporciona.
É nisso que a semântica se transforma assim que já não se pode partir do princípio de que é abertamente consultá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 norma EN 18223 tem de funcionar mesmo quando o dicionário por trás de um campo é o ECLASS ou o IEC CDD - ambos pagos, nenhum deles livremente acessível como um IRI @context aberto. Por isso, a norma especifica o significado valor a valor: qual o dicionário, qual a entrada, qual o tipo, qual o valor. Só assim se mantém autodescritiva, quando não se pode contar com o facto de o leitor clicar para consultar.
Lida desta forma, a prolixidade não é um erro de conceçã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.
Gerar 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 é um preço que só paga quem começou de forma fechada. Nunca fazemos isso, porque o significado estava presente desde a primeira redação.
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 um acaso. 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, o da respetiva extensão do regulamento. Todos 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.2, 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, de forma independente, 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-la 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 em 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 para o qual a EN 18223 remete - são ambas normas europeias publicadas.
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. A sua publicação no Jornal Oficial da UE, que lhes confere o estatuto harmonizado e a presunção de conformidade, está prevista para meados de 2026.
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 de raiz. 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.
