目次

• EDCの概要と近況
• Dataspace Protocolの概要と特徴
• EDCのサンプルコードからDataspace Protocolを理解する
• まとめ

EDCの概要と近況

多数の企業同士がデータ主権を守りつつデータを連携するための新しい仕組みとして、「データスペース」（※1）が注目されています。データスペースに接続するために利用される、コネクタと呼ばれるソフトウェアに関する開発も継続して行われ、そのような取り組みの一つとして、過去の記事でも取り上げたEDC（※2）があります。

EDCはEclipse Dataspace Componentsの略で、コネクタを実装するためのフレームワークを提供しています。元々はEclipse Dataspace Connectorという名称のプロジェクトでしたが、コネクタに閉じない技術要素を扱う状況を反映して、2022年11月頃にリブランディング（※3）されました。EDCは、非営利団体「International Data Spaces Association（IDSA）」の取り組みにルーツを持つものの、オープンソースソフトウェアとしての開発体制を重視する独立のプロジェクトです。EDCの提供するコードも、IDSのコネクタ（※4）とは、全く異なるものとなっています。

EDCは2023年5月にバージョン0.1.0をリリースした後、継続してセマンティックバージョニングに従ったリリースを継続して出しており、本記事執筆時点での、EDCの最新バージョンは0.3.1です。ある程度、EDCをベースに本格的なコネクタ開発ができる下地が整い始めたとも言えますが、そのバージョン番号が示唆するように、安定したリリース版（1.0.0）が出る前の、過渡的な状況を脱したわけではありません。設計のリファクタリングなどに応じて、コードは日々変化し、互換性に影響するような変更も随時入っています。特に、EDCバージョン0.1.0のリリース前後に行われた、Dataspace Protocol（※5）対応では、インターフェースにも大きな変化が見られました。

Dataspace Protocolの概要と特徴

Dataspace Protocolは、データスペースにおけるデータをやり取りするために、コネクタ同士が連携する際のプロトコル／APIを定めたものです。データスペース技術特有の要件にもとづくものといえるため、ここで掘り下げてみます。

現在のDataspace Protocolは、大きく分けてCatalog、Contract Negotiation、Transfer Processの3つの部分からなります。

Catalog（※6）は、利用可能なデータの一覧を取得するためのものです。リクエストを送信すると、指定したフィルター条件にマッチする、データセットに関する一覧情報が返ってきます。一覧情報（カタログ）はDCAT（Data Catalog Vocabulary）と呼ばれるオントロジー（※7）にもとづいて記述されています。

Contract Negotiation（※8）は、データへのアクセスを要求するためのものです。Catalogに記載されたIDにより、取得対象のデータアセットを指定します。要求を受けた側は、事前に定義されたポリシーに応じて、アクセスを許可するかどうかと、利用条件を決定します。ポリシーは、ODRL（Open Digital Rights Language）と呼ばれる記法／モデル（※9）で記述しておきます。データへのアクセスを許可する場合、その旨を示すContract Agreementと呼ばれる情報が、要求側に返却されます。Contract Negotiationの処理は時間を要する可能性があるため、Contract Agreementはデータ提供側から要求側に対して、後から通知（コールバック）されるような仕様となっています。

Transfer Processは、データの転送を要求するためのものです。Contract Negotiationの結果として得られたContract Agreementを指定し、データ転送処理の要求を行います。具体的にデータを転送する方法については、プロトコルを提供するコネクタの実装次第となります。Dataspace Protocol上は、データ転送要求を受け付けて、その状態を管理し、結果を通知するフローのみが規定されています。実データを提供するエンドポイントから、実際にデータを取得する処理を、要求側（consumer）主体で行う場合はpull、提供側（provider）主体で行う場合はpushと呼ばれ、プロトコルのフローが区別されています。

EDCのサンプルコードからDataspace Protocolを理解する

EDCは、コネクタを実装する際の参考情報として、サンプルコードを提供しています。（※10）サンプルはいくつかあり、コネクタを起動する方法から実際にデータをやり取りする方法まで含めて複数の例が挙げられています。その中でも、コネクタ間でのシンプルなデータ転送を行うサンプルの実行手順（※11）には、Dataspace Protocolの内容にほぼそのまま対応するようなフローが含まれるため、プロトコルを理解する上で有用です。本サンプル内では、以下のような流れでコネクタの利用方法が説明されており、ステップバイステップで理解できるようになっています。

• データ提供者側・利用者側のそれぞれのData Planeインスタンス（データをやり取りする手段の情報）の登録
• データ提供者側でAsset（やり取りするデータの情報）、Policy、Policyと紐づくContractを作成
• データ利用者側でデータ提供者側が作成したAssetやPolicyを含むCatalogを取得
• 上記情報にもとづき、Contractを合意形成
• データ転送の開始、およびデータの取得

なお、本サンプルの実行手順を見ると、curlコマンドでHTTPリクエストを送信していますが、このリクエストはエンドユーザがコネクタの機能を利用するために、EDCコネクタが提供しているmanagement-api（※12）のものであり、Dataspace ProtocolのAPIではない点に注意が必要です。前章で述べた通り、Dataspace ProtocolのAPIは、コネクタがユーザからの要求を処理するために、別のコネクタに対して発行する形で利用されます。ただし今回引用したサンプルの中では、management-apiのレスポンスとして得られる、CatalogやContract Agreementのデータなどは、Dataspace ProtocolのAPIのレスポンスそのままです。

サンプルを起点に一歩踏み込んでDataspace Protocolでやり取りされる情報を確認してみましょう。
データスペースにおけるやり取りは、インターネット経由となる想定を反映して、RESTful APIが事実上の標準的なバインディングとなっています。また、リクエストやレスポンスに付与されるペイロードは、JSON-LD（※13）と呼ばれる形式になっています。例えばCatalogプロトコルに関して、EDCのコネクタ間で送信されるリクエストのペイロードは、以下のような内容になっています。

JSON-LDは、RDFのようなグラフ構造のデータを、JSONの枠組みで表現するためのフォーマットです。DCATやODRLといったオントロジー／情報モデルをベースに定義された、IDSの情報モデル（※14）に対応するために、採用されています。このような、セマンティック・ウェブの技術が取り入れられているのは、将来的にデータセットの意味を、自動的に解釈して処理するためと考えられます。しかし、現時点のEDCにはまだ、セマンティックな処理を活用するようなコードは存在しないため、単に冗長な表現と感じられてしまうかもしれません。

まとめ

本記事では、データスペース技術の実装と現状を理解するために有用な題材として、EDCとDataspace Protocolを紹介しました。現時点ではEDCも、Dataspace Protocolも開発途上にあり、今後も仕様が変化していくと考えられますが、バージョン1.0.0として、仕様が固まる方向に前進している印象です。また本記事で紹介した通り、ヨーロッパを中心に用いられ始めているEDCがDataspace Protocolに対応したことは、当該プロトコルの実用において意味があると考えられます。NTTデータグループではデータスペースに関する技術の調査や研究を今後も継続し、仕様と実用の両面から情報提供してまいります。