EN-18223のシリアライゼーションを、整然とした慣用的なJSON-LDに変換してみると、まずその規模の大きさに目を引かれます。ターゲット形式は驚くほど冗長です。
EN 18223は、CEN/CLC JTC 24による規格であり、デジタル製品パスポート（DPP）のデータモデルを定義しています。この規格がEU官報に掲載され次第、すべてのDPPはこの形式に準拠しなければなりません。 この形式では、各値が独自の elementId、dictionaryReference、objectType、valueDataType、および value を持つオブジェクトとなります。3行分のソースデータが20行分になります。
この冗長さがもたらすもの
この冗長さは偶然ではなく、それが何をもたらすのかを理解する価値があります。
これは、セマンティクスがオンライン上で公開されている情報から直接解決できるとはもはや想定できなくなった時点で、必然的に生じるものです。JSON-LDドキュメントは通常、@contextを介して意味を伝えます。これは、読者がフィールドの意味を調べるためにたどるリンクです。
EN 18223は、フィールドの背後にある辞書がECLASSやIEC CDDである場合でも機能しなければなりません。これらはいずれも有料であり、オープンな@context-IRIのように自由に解決できるものではありません。 そのため、この規格では意味を値ごとに明記しています。どの辞書か、どの項目か、どの型か、どの値か、といった具合です。読者がリンクを辿って確認することを期待できない場合、これこそが規格自体の自己記述性を保つ唯一の方法です。
このように解釈すれば、その冗長さは設計上の欠陥ではなく、クローズドな辞書に対する合理的な対応であると言えます。
対照的な例が具体的にあります。私たちが基盤としている用語集――OpenEPCIS DPP Core およびその規制による拡張――は、ref.openepcis.io で公開されており、自由に解決可能です。 たった1つの @context 参照が、クローズドな辞書がそこに書き込まなければならない意味を担っているのです。
なぜ方向性が重要なのか
クローズドな辞書からオープンなセマンティクスを再構築することは、困難な方向性です。その逆は簡単です。
私たちのJSON-LDソースには、EN 18223のモデルが要求するすべての属性がすでに含まれています。すなわち、プロパティへの参照、辞書への参照、値のデータ型、値ごとの言語配列です。 これらは、EN 18223のフラットな「エンティティ-属性-値」構造ではなく、@context-IRIを持つ型付きJSON-LDオブジェクトとして表現されているだけです。
これらのデータから EN 18223 形式のビューを生成することは、単なるフォーマット作業に過ぎません。つまり、既存のフィールドを取り出し、目標とする形式に整えるだけです。
この原理を一言で言えば、オープンな名前空間を持つソースは、あらゆるクローズドな辞書に対して投影を行うため、冗長さは、最初からクローズドな形式で始めた者だけが支払う代償となります。私たちは、最初の記述の段階から意味が明確であったため、そのようなことは決して行いません。
標準的な用語集の代わりに複数の名前空間
私たちのソースがすでにこの形式をとっているのは、偶然ではなく、意図的な決定によるものです。私たちは、あらゆる規制を単一の用語集に無理やり収めようとはしません。
EUのDPP規制（電池、繊維、電子機器、および今後制定されるもの）はそれぞれ、独自のアップストリーム名前空間（GS1、OpenEPCIS DPP Core、および各規制の拡張部分）を維持しています。 これらはすべて、@context配列内に並列に配置されており、上流の命名空間でカバーされていない少数の用語のために、意図的に簡素化されたtranspareo:命名空間と併存しています。
EN 18223は、その序文条項0.2において、ほぼこれと同じことを求めています。すなわち、セクター固有のオントロジーを避け、委任された各法的措置ごとに発行されるオントロジーの並行利用を許可し、水平層を可能な限り汎用的なものに保つことです。
オープンで並列な名前空間に基づくアーキテクチャは、単に規格の意図と整合しているだけではありません。それは、規格自体の設計原則が指し示しているものそのものです。
ストレステスト：Battery Passの属性リスト
その証拠は、このアーキテクチャが、もともとそのために構築されたわけではない辞書をどのように取り込んでいるかにある。
Battery Pass Consortiumの「Data Attribute Long List」（バージョン1.3）は、EN 18223およびGS1のいずれからも独立して逸脱した、3つ目の辞書である： 約100の属性、独自の命名規則、独自のアクセスレベル、そして同コンソーシアムによるバッテリー規則の付属書XIIIの解釈。
我々はこれを既存のデータモデルと照合した。100個の属性のうち91個は、変更されることなく既存の属性タイプに割り当てられた。複数の名前空間を持つソースは、新しい閉じた辞書をさらなる投影として取り込むものであり、再構築を強制するものではない。
規格の現状
EN 18223および、EN 18223が参照する具体的なシリアライゼーション形式を定義する姉妹規格であるEN 18216は、いずれも公表済みの欧州規格です。
これらは、CEN-CENELEC-JTC-24-DPPセットの最初の公開波に含まれており、8つの規格のうち6つがこれに含まれ、残りの2つ（認証およびアクセス権に関するもの）は2026年夏に続く予定である。 EU官報への掲載（これにより調和規格としての地位と適合推定が与えられる）は、2026年半ば頃を予定している。
良い面
こうした点があっても、EN 18223が誤った規格であるわけではありません。冗長さは、すべての辞書が公開されているわけではない世界における相互運用性の代償であり、この規格はその現実を適切に反映しています。
良い点は単純明快です。すでにクリーンなJSON-LDを採用している者にとって、EN 18223は「既存のものを投影する」ものであり、「一から構築する」ものではありません。コストがかかるのは逆の道、つまりクローズドな辞書からスタートした者が誰もが歩まなければならない道です。
最初の行からオープンで解析可能なセマンティクスを基盤としている人にとっては、この規格の冗長性はもはや負担ではなくなります。それは、必要に応じて生成する出力形式となるのです。