拡張されたEN-18223シリアライゼーションを、正確で慣用的なJSON-LDに変換してみると、まずその規模の大きさが目につきます。この形式は著しく冗長です。
EN 18223は、デジタル製品パスポートのシステム相互運用性に関するCEN/CLC JTC 24の規格であり、その第4条ではセマンティックモデルが、第5.2条ではシリアライゼーションが定義されている。このシリアライゼーションには2つの形式がある。 運用時の圧縮シリアライゼーションでは、各値の elementId をオブジェクトキーとして使用し、dictionaryReference および valueDataType はデータ辞書による解決に委ねられます。 拡張形式ではすべてが明示的に記述されます。各値は、独自の elementId、dictionaryReference、objectType、valueDataType、および value を持つオブジェクトとなり、3行分のソースデータが20行になります。
この冗長さがもたらすもの
この冗長さは偶然ではなく、それが何をもたらすのかを理解する価値があります。
これは、セマンティクスがオンライン上で公開されている辞書によって解決できると想定できなくなった瞬間に、必然的に生じるものです。JSON-LDドキュメントは通常、@contextを通じて意味を伝えます。これは、読者がフィールドの意味を調べるためにたどるリンクです。
この圧縮された形式が機能するのは、読者がフィールドの背後にある辞書を参照できる場合に限られます。しかし、その辞書が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.3において、ほぼこれと同じことを求めています。すなわち、セクター固有のオントロジーを避け、委任された各法的措置ごとに発行されるオントロジーの並行利用を許可し、水平層を可能な限り汎用的なものに保つことです。
オープンで並列な名前空間に基づくアーキテクチャは、単に規格の意図と整合しているだけではありません。それは、規格自体の設計原則が指し示しているものそのものです。
ストレステスト：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年夏に続く予定です。 これら6つの規格は、2026年7月15日に実施決定（EU）2026/1736号によりEU官報に掲載され、これにより調和規格としての地位、ひいてはESPRの第10条および第11条への適合推定が与えられました。
良い面
これらの点はいずれも、EN 18223が誤った規格であることを意味するものではありません。冗長さは、すべての辞書が公開されているわけではない世界における相互運用性の代償であり、この規格はそうした現実を適切に反映しています。
良い点は単純明快です。すでにクリーンなJSON-LDを採用している者にとって、EN 18223は「投影」であり、「新規構築」ではありません。コストがかかるのは逆の道、つまりクローズドな辞書から始めた者が誰もが通らなければならない道です。
最初の行から、オープンで解析可能なセマンティクスを基盤としている人にとっては、この規格の冗長性はもはや負担とはなりません。それは、必要に応じて生成する出力形式となるのです。