Protocol

Overview（概要）

本プロトコルは ODS-RAM の L4「Metadata Exchange」に対応する Fundamental Protocol であり、データの所在や意味に関するメタデータを連携し、分散環境でのデータ発見性と意味判断を成立させるものである。 メタデータは、情報モデルとしてRDF(Resource Description Framework)を採用し、データモデルとしてJSON-LD 形式やTurtle形式を採用する。データやサービスの提供者がこのメタデータを公開することで、データやサービスの発見や解釈、利用が容易になる。また、この基盤的なプロトコルの上位プロトコルとして、Discovery and Search 等を用いることで、データやサービスがネットワーク上で分散的に存在しても、Open Dataspaces全体が透過的に一つのシステムとして機能することを可能にする。 このメタデータは、モビリティやサプライチェーンといった実社会におけるエンティティと、クラウド上のデータやサービスのアクセスを対応づけることを主に意図されているが、前者は必須ではない。

concept 1

必須とする後者のメタデータにより、サービスの外部仕様がグローバルに意味解決可能となるように接地（意味定義を明確化）され、さらに、そこへのアクセスに必要な諸情報（宛先を含む）が明確になる。

concept 2

これらのメタデータは、一般のWebアプリケーションサーバ/クライアントの側に構築される。すなわち、メタデータサーバは、アプリケーションサーバからメタデータを静的あるいは動的に取得する。 メタデータクライアントは、アプリケーションクライアントに対してメタデータを提供する。ここで、設計方針としては、通常のWebアプリケーションシステムがデータベース指向のシステム要件（トランザクション、リアルタイム性、高スループット）を満たすものであるのに対して、メタデータ関連のシステムは、広域環境で多種多様なデータの中から必要なデータを発見することを重視する代償として、データの一貫性等は一旦犠牲にし、必要に応じて追加するものとする。 そもそも実世界のデータや、既存のアプリケーションサーバ等のシステムの多様データを統一的なメタデータとして形式を変換し複製する以上、メタデータ管理を厳密に一貫性管理をする必要がる用途は限られていることを前提としている。

concept 2

---

Abstract Normative Specification（抽象仕様）

Concepts and Roles（概念および役割）

Role	説明
事業ドメイン（Business Domain）	特定のビジネス領域。事業ドメインごとにDiscovery Service等の共通サービスが構築され得る。
データ/サービス提供者(Provider)	事業ドメインに関するデータ/サービスを提供する。複数のリソースを管理することができる。
データ/サービス利用者(Consumer)	データ/サービス提供者のデータ/サービスを利用する。
リソース（Resource）	実社会における物理的・論理的な実体（エンティティ）と対応する、Open Dataspaces上で管理される情報。例えば、ドローンといった物理的な実体から、航路といった論理的な実体、企業間の商取引関係なども含まれる。Open Dataspaces内において、Discovery Serviceの検索対象となる。
メタデータサーバ（Metadata Server）	メタデータをRDFとして公開する。Metadata Endpointで外部からの取得要求を受け付け、静的データについてはMetadata Storeから取得し、動的データについてはApplication Serverなどに随時取得しにいく。
メタデータストア（Metadata Store）	メタデータをRDFとして格納する。主に静的データを扱う。
メタデータクライアント（Metadata Client）	メタデータを取得する。ブラウザの場合は、javascriptライブラリなど
メタデータエンドポイント（Metadata Endpoint）	Metadata ServerにおけるRDF取得エンドポイント。SPARQLエンドポイントも含む。
アプリケーションサーバ（Application Server）	データ/サービス提供者の業務アプリケーションサーバ。一般のアプリケーションサーバを含む。
アプリケーションクライアント（Application Client）	業務アプリケーションを利用するクライアント。専用ソフトウェア、あるいはブラウザ

---

Scope（適用範囲）

• RDFメタデータ公開

• RDF Patch同期

• SPARQL取得

---

Normative Requirements（規定要件）

• shall: メタデータは、RDFで表現されなければならない。

  • Rationale: メタデータで表される意味（セマンティクス）の表現方法を統一し、相互運用性を確保するため。

• shall: メタデータには、データ授受あるいはサービス提供に関わるインターフェースの意味定義が、グローバルに意味解決可能な形で含まれなければならない（e.g. SAMM）。

  • Rationale: インターフェースの意味が曖昧では、データの受取り手やサービスの利用者が、意図しない利用になってしまうため。

• shall: メタデータには、データあるいはサービス提供者が持つインターフェースの宛先情報を含まなければならない。

  • Rationale: 分散システムを一つのOpen Dataspaceとして透過的に見せるには、どこからでも、適切なアクセス管理のもと、そのサービスをグローバルにアクセス可能にする必要があるため。

• should: メタデータは JSON-LD 形式で送受信されることを原則とする。

  • Rationale: Webベース実装との親和性が高く、広範な実装実績があるため。

• should: データあるいはサービス提供者が、実社会における何らかの物理的・論理的な実体と関連する場合、これをメタデータとして持つことを原則とする。

  • Rationale: 実社会における実体と関連するサービスをネットワーク上で対応づけることが可能となるため。

• should: 前記の実社会における何らかの物理的・論理的な実体が、他の提供者に関する実体と関連する場合、この参照関係をメタデータとして持つことを原則とする。

  • Rationale: 参照関係を辿ることで、他の提供者を発見し、システム全体の相互運用性を高めることができるため。

• may: メタデータの差分を管理する機構が提供されてもよい（e.g. RDF Patch）。Eventual Consistencyを前提とするが、Lineage、タイムスタンプ、バージョン管理などで差分が管理されることが望ましい。

  • Rationale: 強い一貫性を必要とはしないものの、メタデータの鮮度が重要となる場合もあるため。

---

Non-functional / Cross-layer Requirements

• Identity & Trust（L3） と連携可能であること。

• メタデータ自体へのアクセスにも、適切なアクセス管理が必要な場合には、Identity & Trust（L3）と連携し、権限管理がされること。

• RDFモデルはODSセマンティクス方針に準拠する。

---

メタデータ

メタデータは、データやサービスを提供するシステムからメタデータサーバに提供され公開される。他のサービス提供者のメタデータを参照する、あるいはDiscovery Serviceに公開されるなどで、他のシステムから参照可能となる。

メタデータは、データやサービスの意味定義や宛先情報に関わるサービスメタデータと、実社会における実体と対応するリソースメタデータから構成される。サービスメタデータは、サービス仕様自体の記述、これを当該環境に展開した状態（インスタンス）などから構成されるが、サービス仕様自体の記述は、別のメタデータサーバに格納され、これを参照するなどで表現される。当該サービスに独自な仕様は当該メタデータサーバに格納されうる。サービスメタデータは、リソースメタデータから参照され得る。サービス仕様の記述は、SAMMなどを用いてAspect Modelとして記述される。

サービスメタデータ全体構造

サービスメタデータは、二つのパートで構成される

{
  "@context": { ... },
  "@graph": [ ... ]
}

項目名	型	必須	説明
@context	object	○	名前空間定義
@graph	array	○	データ/サービス提供者に関するメタデータの中身

---

名前空間定義　　@context

@context は、メタデータで使用されるプレフィックスと名前空間との対応を定義する。

• 名前空間として以下を使用する。

  • @prefix http: http://www.w2.org/2011/http# .

  • @prefix dcterms: http://purl.org/dc/terms/ .

  • @prefix xsd: http://www.w2.org/2001/XMLSchema# .

  • @prefix ods: https://github.com/ODS-DFS-L4/ods/ .

  • Aspect Modelを定義した名前空間 例：@prefix uasl: <urn:samm:com.foo.uasl:0.5.3#> .

  • APIを定義したドメインアプリケーションAPI定義ファイルが使用する名前空間 例：@prefix api: <https://uasl.foo.com/0.5.3/api#> .

  • ドメインアプリケーション用の名前空間 自社の名前空間を明示 例:@prefix inst: <http://www.example.com/uasl/instance#> .

    • 省略のprefixは使用せずprefixはinstを使用して明示する。

• ドメインアプリケーションのインスタンスは、ods:DomainApp型として定義する。

  • dcterms:conformsTo を使用してAspect ModelとAPI定義と明示的に紐づける。

  • Aspect Modelでドメインアプリケーションのプロパティとしたものは、実際の値を設定する。

  • ods:hasBaseEndpointを使ってAPIのベースEndpointを示す。

    • APIベースエンドポイントはods:BaseEndpointクラス（ods:DomainAppEndpointのサブクラス）として定義する。

  • ods:hasSparqlEndpointを使ってSPARQL用のEndpointを示す。

    • SPARQLエンドポイントはods:SparqlEndpointクラス（ods:DomainAppEndpointのサブクラス）として定義する。

  • ods:hasEndpointを使って各API用のEndpointを示す。

    • 各APIエンドポイントはods:DomainAppEndpointクラス（ods:DomainAppEndpointのサブクラス）として定義する。

  • ods:accessURLプロパティを使って各エンドポイントのURLを示す。

キー	型	説明
dcterms	string (URI)	Dublin Core Terms
rdf	string (URI)	RDF名前空間
api	string (URI)	API識別用名前空間
inst	string (URI)	インスタンス識別用名前空間
ods	string (URI)	ODS（Open Dataspace）関連
service	string (URI)	サービス定義

---

データ/サービス提供者に関するメタデータ @graph

@graph は次の複数のオブジェクトから構成される。

• DomainApp ：ドメインアプリケーション全体を表す。

• DomainAppEndpoint ：SAMMによって定義されたエンドポイントのURI情報を表す。

• BaseEndpoint ：REST APIのエンドポイントの共通部分のURI情報を表す。

• SparqlEndpoint ：SPARQL用のエンドポイント情報を表す。

---

DomainApp

DomainAppはドメインアプリケーション全体を表す。

構造

{
  "@id": "inst:MyServiceProd",
  "@type": "ods:DomainApp",
  "dcterms:conformsTo": [ ... ],
  "ods:hasBaseEndpoint": { ... },
  "ods:hasEndpoint": [ ... ],
  "ods:hasSparqlEndpoint": { ... },
  "service:serviceProviderName": { ... }
}

---

DomainAppEndpoint

DomainAppEndpointはSAMMによって定義されたエンドポイントのURI情報を表す。

共通構造

{
  "@id": "inst:xxxEndpoint",
  "@type": "ods:DomainAppEndpoint",
  "service:xxxRequestUri": {
    "@type": "http://www.w3.org/2001/XMLSchema#anyURI",
    "@value": "https://example.com/api/v1/path"
  }
}

---

BaseEndpoint

BaseEndpointはREST APIのエンドポイントの共通部分のURI情報を表す。

{
  "@id": "inst:myServiceBaseEndpoint",
  "@type": "ods:BaseEndpoint",
  "ods:accessURL": {
    "@type": "http://www.w3.org/2001/XMLSchema#anyURI",
    "@value": "https://example.com/api/v1"
  }
}

---

SparqlEndpoint

SparqlEndpointはSPARQL用のエンドポイント情報を表す。

{
  "@id": "inst:myServiceSparqlEndpoint",
  "@type": "ods:SparqlEndpoint",
  "ods:accessURL": {
    "@type": "http://www.w3.org/2001/XMLSchema#anyURI",
    "@value": "https://example.com/sparql"
  }
}

リソースメタデータ

リソースメタデータは、当該用途のアプリケーションが生成・管理する様々な形式のデータをRDFにより表現し、共通の語彙により意味を持たせた、ドメイン内データのメタデータである。ドメイン依存であるため、具体例は、binding.mdで挙げる。

共通仕様

(1) 基本構造

• 本データは JSON-LD により RDF を表現する

• 各ファイルは以下を基本単位とする

{
  "@context": { ... },
  "@graph": [ ... ]
}

要素	説明
@context	名前空間定義、語彙定義
@graph	RDFリソースの配列

ID表現

• 各エンティティは @id により一意に識別される

• HTTP URI形式を採用

例:

http://localhost:8080/resource/aircraft/{UUID}

データ型

• リテラル値は @value + @type で明示

• 主な型

  • xsd:string

  • xsd:integer

  • xsd:double

  • xsd:boolean

  • xsd:dateTime

---

Message Types（メッセージ種類）

種類	送信元 ⇒ 送信先	説明
sparqlQuery	Metadata Client ⇒ Metadata Endpoint	RDF取得
patchNotify	Metadata Endpoint ⇒ Metadata Client	差分通知

---

Protocol Flow（プロトコルフロー）

---

Error Handling（エラー処理）

本プロトコルで使用されるエラー処理について記す。

エラー種別	説明	エラー発生時の対応
RDF形式エラー	JSON-LD不正	入力修正
Endpoint接続不可	ネットワーク問題	再試行
Patch不整合	差分順序問題	再同期

References

Michael Franklin, Alon Halevy, David Maier, "From Databases to Dataspaces: A New Abstraction for Information Management", SIGMOD Record, Vol. 34, No.4, Dec. 2005