Open Data Product Specification (ODPS)

Open Data Product Specification (ODPS)

1. なぜデータに“商品性”が求められるのか

企業は長らく、データを自社の内部資産として扱ってきました。
しかし、生成AIやデータプラットフォームの普及によって、
データは「社内で管理されるもの」から「外部で利用されるもの」へと性格を変えつつあります。

そのとき、問われるのは──データが市場でどのように価値を持ちうるか、ということです。
誰も、仕様も品質も不明なデータを安心して使うことはできません。
「このデータは何を表し、どのように維持され、どんな条件で使えるのか」
──その説明責任こそが、データの“商品性”を規定します。

Open Data Product Specification（ODPS）は、
この「商品性」を技術的に記述するための標準仕様です。
データが“モノ”として取引される時代において、
ODPSはデータを信頼できる商品として提示するための構造と語彙をメタデータ仕様として提供します。

2. Open Data Product Specification

ODPS は、単なるメタデータ仕様ではありません。
価格（pricing）、品質（quality）、ライセンス、SLA、アクセス制御など──
データを流通させるうえで必要となるビジネス・技術・法務の文脈を一体化しています。

DCAT や schema.org が「データが発見できるか（discoverable）」を重視してきたのに対し、
ODPS が焦点を当てるのは「データのビジネス価値（valuable and tradable）」です。

言い換えれば、ODPS は
「どこにデータがあるか」ではなく、
「どんな条件で、どんな品質で、どんな責任のもとに使えるか」
──その全体像を明示する仕組みです。

この仕様によって、データプロバイダは商品カタログのように自らのデータを提示し、
利用者が安心して選び取れる環境を醸成することができます。

ODPS v4.1：主要 10 要素の紹介

ODPS は、データを「商品」として扱うために必要な要素を、10の構成要素として定義しています。
それぞれが、ビジネス・法務・技術・運用 の観点からデータプロダクトの商品性を支える関係にあります。

以降では、Linux Foundationが公開するOpen Data Product Specification v4.1の内容を元に、その構造を解説します。

出典："Open (source) Data Product Specification 4.1 Version | Linux Foundation"

2.1. Open Data Product Specification — details

2.1.1. 概要

details は、データプロダクトの ビジネス情報とガバナンス情報 を定義する要素です。
これは ODPS の中心的な構成要素であり、データプロダクトがどのような目的・属性・品質・可視性を持つかを包括的に記述します。
ここで定義された情報は、マーケットプレイスやカタログの表示内容と直結し、利用者がデータを選ぶ際の判断基準になります。
また、visibility や status によって統制され、「管理された公開」 という新しいデータ文化を支えます。

2.1.2. 主な目的

• データプロダクトを商品として説明する（名称・説明・価値提案）
• 管理・統制のためのガバナンス情報を明示する（可視性・状態・標準準拠など）
• 発見・選択・利用を容易にするカタログ情報を統一仕様で提供する

2.1.3. 構成要素（v4.1）

要素	型 / 属性	説明
details	object (必須)	言語ごとのビジネス情報を束ねるトップレベル要素。多言語対応を想定。
name	string (必須)	データプロダクトの正式名称（最大256文字）。
productID	string (必須)	一意の製品識別子。
visibility	enum (必須)	公開範囲。private, invitation, organisation, dataspace, public のいずれか。
status	enum (必須)	ライフサイクル状態。draft, development, testing, production, sunset, retired など。
type	enum (必須)	製品タイプ。例：dataset, reports, algorithm, data-driven service など。
valueProposition	string	データプロダクトの価値提案（1〜2文で要約）。
description	string	製品の概要説明。
productSeries	string	同一カテゴリや市場向けの製品群に属する場合のシリーズ名。
categories / tags	array	製品の分類・タグ情報。検索・分類に利用。
standards	array	関連する標準や品質規格（例：ISO 8000, ISO 19131）。
productVersion / versionNotes	string	製品のバージョンおよび更新内容。SemVer 準拠。
issues	string	既知の不具合や修正予定を記載。
contentSample	URL	データのサンプル（例：JSON, CSV, XML など）。
logoURL	URL	製品ロゴ画像のURL。
outputFileFormats	array	提供される出力形式（例：JSON, CSV, ZIP）。
brandSlogan	string	製品や組織のスローガン。
useCases	array	関連ユースケース（タイトル、説明、URLを含む）。
recommendedDataProducts	array	併用推奨・代替データプロダクトの参照URL。
created / updated	date (ISO 8601)	作成・最終更新日時。

2.2. Open Data Product Specification — productStrategy

2.2.1. 概要

productStrategy は、データプロダクトの存在意義とビジネス目標を結びつける要素です。
単なる説明ではなく、「このデータが何のためにあり、どんな成果指標に貢献するのか」を仕様として明文化します。
特に上位KPI（contributesToKPI）を中心に、製品レベルKPIや副次的影響（relatedKPIs）を体系的に紐づけるのが特徴です。
これにより、データ活用は単なる運用活動ではなく、「成果に結びつくプロダクトマネジメント」としての地位を得ます。

2.2.2. 主な目的

• データプロダクトの**ビジネス上の意図（intent）**を明示する
• KPIとの定量的接続により、成果責任を明確化する
• 組織戦略（strategicAlignment）との整合性を仕様レベルで保証する

2.2.2. 構成要素（v4.1）

要素	型 / 属性	説明
productStrategy	object	全体ブロック。データプロダクトをビジネス目標と結びつける。
objectives	array (lang-tagged)	データプロダクトが支援するビジネス目標を自然言語で記述。
contributesToKPI	object (必須)	データプロダクトが直接的に責任を負う上位KPI。 属性：id, name, description, unit, target, direction, timeframe, owner, calculation
productKPIs	array	製品レベルで測定されるKPI。上位KPIへの貢献度を可視化する。
relatedKPIs	array	間接的・副次的な影響を測定するKPI。ポジティブ/ネガティブ両面の効果を観察。
strategicAlignment	array (lang-tagged)	上位の戦略文書・政策・企業ビジョンとの整合を示す。例：「Smart City Vision 2030」

2.3. Open Data Product Specification — contract

2.3.1. 概要

contract は、データプロダクトと正式なデータ契約（Data Contract）を結びつける要素です。
ここでは、利用権・責任範囲・技術的期待値などを明文化し、組織間・システム間の相互運用性を担保します。
Open Data Contract Standard（ODCS） や Data Contract Specification（DCS）といった標準規格を参照することで、
データ流通の信頼性とガバナンスを支える仕組みを統一的に表現できます。

2.3.2. 主な目的

• データ提供者と利用者の間で ガバナンス・利用条件・品質責任 を明示する
• 契約仕様を参照可能な形で 構造化し、再利用可能にする
• ODCS / DCS といった標準規格と統合し、異なるプラットフォーム間での一貫性を確保する

2.3.3. 構成要素（v4.1）

要素	型 / 属性	説明
contract	element	データ契約を束ねるトップレベル要素。外部参照またはインライン定義が可能。
id	string	契約の一意識別子（UUIDなど）。
type	enum	契約仕様の標準種別。ODCS（Open Data Contract Standard）または DCS（Data Contract Specification）。
contractVersion	string	利用している契約標準のバージョン番号。データ契約自体の改訂版とは異なる。
contractURL	URL	契約管理サービス上のドキュメントURL。契約内容への外部リンクを指定。
spec	string (YAML)	契約内容を直接 YAML 形式で埋め込むためのオプション要素。
$ref	URI	別ファイルや外部リソースにある契約定義を参照するURI。

2.3.4. 定義方法（3つの選択肢）

1. 外部参照方式 — id, type, contractVersion, contractURL を指定し、外部の Data Contract 管理システム上のドキュメントを参照。
2. インライン定義方式 — spec に YAML 形式で契約を直接埋め込む。
3. 参照ファイル方式 — $ref を使い、別ファイル内に定義された契約仕様を読み込む。

2.3.5. サンプル

外部参照：

product:
  contract:
    id: 02323M123  
    type: ODCS 
    contractVersion: 2.2.2
    contractURL: https://demo.datamesh-manager.com/demo834016807886/dataproducts/9bd53b1b-b51e-41a8-a757-4d33b4cde460

インライン定義：

product:
  contract:
    type: ODCS 
    contractVersion: 2.2.2
    spec:
      # What's this data contract about?
      domain: seller # Domain
      dataProduct: my quantum # Data product name
      version: 1.1.0 # Version (follows semantic versioning)
      status: active
      id: 53581432-6c55-4ba2-a65f-72344a91553a

      # Lots of information
      description:
        purpose: Views built on top of the seller tables.
        limitations: Data based on seller perspective, no buyer information
        usage: Predict sales over time
        authoritativeDefinitions:
          - type: privacy-statement
            url: https://example.com/gdpr.pdf
      tenant: ClimateQuantumInc
      ...

2.4. Open Data Product Specification — SLA

2.4.1. 概要

SLA（Service Level Agreement）は、データプロダクトの品質・性能・可用性に関する合意事項 を定義する要素です。
データ提供者と利用者の間で交わされる “品質契約” として、
「どの程度の更新頻度で」「どのくらい正確に」「どんな応答速度で」
データが提供されるかを機械可読な形式で明示します。

これにより、透明性・説明責任・監査可能性を兼ね備えたデータ提供が可能になります。

2.4.2. 主な目的

• データ品質・可用性に関する 期待値と責任範囲を明示する
• SLAを 機械可読（as code） で定義し、監視・通知システムと統合可能にする
• ベンダーや利用者間で 共通の理解・比較可能性 を確立する

2.4.3. 構造の概要

SLA オブジェクトは大きく2つの部分から構成されます：

1. Declarative（宣言的定義） — 達成すべきSLA目標を定量的に示す部分
2. Executable（実行定義） — モニタリングや検証を自動化するコードを埋め込む部分

2.4.4. 構成要素（v4.1）

要素	型 / 属性	説明
SLA	element	SLA全体を束ねる要素。プロファイル分割や外部参照（$ref）が可能。
$ref	URL / filepath	外部ファイルに定義したSLAを参照。複数のプラン（例：default, premium）を統合的に管理できる。
default / premium / gold	object	SLAプロファイル。default は必須で、ベースラインとなる品質保証内容を示す。
declarative	array	目標値を定義する宣言的パート。各要素が dimension, objective, unit を含む。
executable	array	モニタリングや評価を自動化する “SLA-as-Code” の定義。
dimension	string	測定対象となる品質指標。uptime, responseTime, errorRate などが標準化済み。
objective	integer	達成すべき目標値（例：99）。
unit	enum	単位（例：percent, milliseconds, minutes, days など）。
type	string	モニタリングシステム名（例：prometheus）。
spec	YAML / string / URL	モニタリングコードの内容。PromQLなどを直接記述可能。
reference	URL	利用している監視ツールや仕様書への参照リンク。
support	object	サポート連絡先情報（電話・メール・対応時間・ドキュメントURLなど）。

2.4.5. 標準化された11のSLAディメンション

ディメンション	説明
latency	応答が返るまでの最小遅延時間。
uptime	稼働率（システムが利用可能な時間の割合）。
responseTime	外部リクエスト処理に要する時間。
errorRate	許容されるエラー率（%）。
endOfSupport	サポート終了日。
endOfLife	提供終了日。アクセスも不可になる。
updateFrequency	データの更新頻度。
timeToDetect	問題を検知するまでの平均時間。
timeToNotify	検知後にユーザーへ通知するまでの時間。
timeToRepair	問題修復に要する時間。
emailResponseTime	サポートメールへの応答までの時間。

2.5. Open Data Product Specification — dataQuality

2.5.1. 概要

dataQuality は、データ品質を定量的かつ機械可読な形で定義する要素です。
これは、SLA が「サービス品質」を定義するのに対し、
データそのものの品質（accuracy・completeness・timeliness など） を定義する仕組みです。

組織はこの定義を通じて、データの価値を最大化し、信頼性・再利用性を高めることができます。
ODPS の dataQuality は EDM Council モデルとの互換性を持ち、
技術的検証とビジネス的期待値を橋渡しする設計になっています。

2.5.2. 主な目的

• データ品質を明示的に仕様化し、関係者間で共有・保証できるようにする
• Declarative（宣言的） な品質目標と、Executable（実行的） な検証ロジックを一体化する
• 品質定義を 再利用（profile reference） 可能にし、複数のプラン（default / premium など）を準備する

2.5.3. 構造の概要

dataQuality オブジェクトは 2つの部分から構成されます：

1. Declarative（宣言的定義） — 達成すべき目標値（例：accuracy=98%）を定義する部分。
2. Executable（実行定義） — モニタリングや検証を自動化するコードを埋め込む部分

2.5.4. 構成要素（v4.1）

要素	型 / 属性	説明
dataQuality	element	データ品質全体を束ねる要素。プロファイル化と外部参照に対応。
$ref	URL / filepath	外部ファイルで定義した品質プロファイルを参照。
default / premium / gold	object	品質プロファイル。default は必須でベースライン品質を示す。
declarative	array	宣言的な品質目標の定義。各要素に dimension, objective, unit を含む。
executable	array	品質検証ロジック（as code）を定義。
dimension	enum	測定対象となる品質指標。accuracy, completeness, timeliness など。
objective	integer	目標値（例：95）。
unit	enum	単位（例：percentage, number）。
type	enum	検証ツール名。SodaCL, DQOps, MonteCarlo, Custom など。
version	string	使用ツールのバージョン。
reference	URL	検証ツールやルール定義のドキュメントURL。
spec	YAML / string / URL	品質チェックのコード本体。
displaytitle / description	array	各ディメンションのタイトル・説明（多言語対応）。

2.5.5. 標準化された8つの品質ディメンション

ディメンション	説明
accuracy	データが現実や権威的ソースとどれだけ一致しているか。
completeness	欠損値がないか。必要な属性がすべて埋まっているか。
conformity	定義済みフォーマット・型・値範囲に従っているか。
consistency	異なるデータストア間で内容が矛盾していないか。
coverage	必要なレコードがすべて含まれているか。
timeliness	最新状態を反映しているか。データが遅延していないか。
validity	データが意図する実体・概念を正しく表しているか。
uniqueness	重複がないか。レコードや属性が一意か。

2.6. Open Data Product Specification — pricingPlans

2.6.1. 概要

pricingPlans は、データプロダクトの価格体系を標準化して記述する要素です。
データ提供者にとっては透明性・信頼性・再利用性を高め、
利用者にとっては比較可能でわかりやすい料金体系を提示することを目的としています。

ODPS では、12種類の標準化された料金モデルを定義しており、
サブスクリプション・従量課金・収益分配・フリーミアムなど、実際のデータ経済で一般的な取引形態を網羅します。
さらに、「Pricing Plans as Code」 機能により、定義した料金プランを Stripe や PayPal などの決済ゲートウェイに直接展開できる点が特徴です。

2.6.2. 主な目的

• 透明性の確保：利用者がコスト構造を容易に理解・比較できるようにする。
• 運用効率化：標準化されたプラン構造により、契約・課金・収益分析を自動化。
• 市場拡張性：共通仕様に基づき、マーケットプレイス間での価格情報を相互運用可能にする。

2.6.3. 構成要素（v4.1）

要素	型 / 属性	説明
pricingPlans	element	価格プラン情報をまとめるトップレベル要素。多言語対応が可能（例：en, fr）。
declarative	element	宣言的な料金定義をまとめるブロック。マーケットプレイス上の価格表示に利用。
priceCurrency	string	通貨コード（ISO 4217 準拠、例：EUR, USD）。
price	string	価格または収益分配率。従量課金では1GB単価などの単位ベースで定義。
billingDuration	enum	課金サイクル。day, month, year, instant など。
unit	enum	価格モデル種別。下記の12モデルが定義済み。
maxTransactionQuantity	integer	指定期間あたりの取引上限。0 は無制限を意味。
offering	array	プラン内容の箇条書き。ユーザーに提供する具体的な価値を明示。
paymentGateway	reference	決済ゲートウェイの参照（例：#/product/paymentGateways/stripe）。
dataQuality / SLA / access	reference	品質・SLA・アクセス方式など他要素への参照を定義。
valueAddedTaxIncluded / Percentage	boolean / number	税の扱いを指定（内税／外税・税率）。
validFrom / validTo	datetime	価格の有効期間（ISO 8601形式）。
valueSimulator	URL	Value-based プラン向けの価値シミュレータURL。
notes	string	免責や補足情報などの自由記述欄。
executable	element	「Pricing Plans as Code」定義。決済システムに直接適用可能な CRUP 操作を記述。
type	enum	決済ゲートウェイ種別（Stripe, Checkout, PayPal, Square, Custom）。
spec	YAML / URL / string	実際の API コマンド群（例：stripe products create …）。

2.6.4. 標準で定義される 12 の価格モデル

モデル名	概要
Recurring	定期課金（サブスクリプション型）
One-time-payment	一括購入型。永続利用を前提とする単回支払いモデル。
Pay-as-you-go	利用回数やAPIリクエスト数に基づく従量課金。
Revenue-sharing	収益分配モデル。利用成果に応じて報酬を共有。
Data-volume	転送データ量（GB単位）に基づく課金。
Trial	無料試用期間を設定する販促プラン。
Dynamic-pricing	需給や市場価格に応じて変動する動的価格設定。
Pay-what-you-want	顧客が支払額を自由に決定する任意価格モデル。
Freemium	基本機能無料＋上位機能有料のモデル。
Open-data	原則無料だが、提供コストを回収する場合も想定。
Value-based	顧客が得る価値（効果）に応じて価格を変動させる。
On-request	利用申請制。条件交渉のうえでアクセス権を付与。

2.7. Open Data Product Specification — license

2.7.1. 概要

license は、データプロダクトの利用権・知的財産権・法的条件を明示する要素 です。
データの流通においては、利用者が「どの範囲で・どのような条件で」使用できるかを明確にすることが、
信頼・透明性・法的安定性の基盤になります。

ODPS はこのライセンス情報を 機械可読形式（machine-readable license） で定義できるようにしており、
法務文書レベルの合意を仕様に組み込み、
データ保護・知的財産・責任分担を自動的にトレーサブルに扱うことを目的としています。

2.7.2. 主な目的

• 法的準拠と知的財産保護：データ提供者・利用者双方の権利と義務を明文化。
• 機械可読な合意形成：契約内容を仕様レベルで共有し、システム的に確認可能にする。
• 信頼と透明性の確保：明示的なライセンス条件により、第三者利用・再販などの範囲を統制。

2.7.3. 構成要素（v4.1）

要素	型 / 属性	説明
license	element	ライセンス情報全体をまとめるトップレベル要素。外部参照またはインライン定義が可能。
$ref	URI	外部ライセンス文書（例：Creative Commons, 独自契約）の参照URI。
en	element	言語ごとのライセンス記述。多言語対応を想定（例：en, fr, ja）。
scope	element	ライセンスの適用範囲と目的を定義。
definition	string	契約の目的と背景。ライセンスの意図を明示。
restrictions	string	禁止事項や使用制限（例：再配布・機密情報の転用禁止など）。
geographicalArea	array	ライセンス適用地域（ISO 3166-1 alpha-2 コード形式）。
permanent / exclusive	boolean	永続ライセンス・排他的ライセンスの指定。
rights	array	付与される権利：Reproduction, Distribution, Adaptation, Reselling, Sublicensing など。
termination	element	契約終了および継続条件の定義。noticePeriod, terminationConditions, continuityConditions を含む。
governance	element	ライセンス管理と法的遵守に関する条件を統括。以下の属性を含む：
├ ownership	string	データプロダクトの所有者・権利者。
├ damages	string	契約違反時の損害賠償や違約金の定義。
├ confidentiality	string	秘密保持義務の範囲と条件。
├ applicableLaws	string	準拠法および裁判管轄。例：「Copyright Act 404/1961 (Finland)」。
├ warranties	string	保証および免責事項。
├ audit	string	監査および情報提供義務に関する条項。
└ forceMajeure	string	不可抗力条項（自然災害や戦争等による契約履行免除）。

2.8. Open Data Product Specification — dataAccess

2.8.1. 概要

dataAccess は、ユーザー／マシンがデータプロダクトへ技術的に到達する方法を定義します。
複数の“名前付きアクセス手段”（例：default, API, agent）を並立させ、それぞれに表示名・説明（多言語）／認証方式／仕様参照／実アクセスURLなどのメタデータを付与します。これにより、分析者・開発者・AIエージェントなどペルソナ別の入口 を提供できます。

2.8.2. 主な目的

• アクセス様式の並立：ダウンロード、API、SQL、AIエージェント等を一括定義します。
• 多言語UI対応：name / description を言語タグで持ち、カタログ表示に直結します。
• セキュリティの明示：authenticationMethod で要求水準を明確化します。
• 再利用性：ODPS内の他所（例：pricingPlans）から $ref で参照し、DRYを実現します。
• AIネイティブ対応：outputPorttype: AI で MCP（Model Context Protocol） 等のエージェント接続を記述できます。

2.8.3. 構成要素（v4.1）

要素	型 / 属性	説明
dataAccess	object	ルート要素。複数の“名前付きインターフェース”を子要素として持ちます。
$ref	URI (file/URL)	すべてのアクセス定義を外部ファイルに委譲する場合に使用します（プロファイル一括管理に有用）。
default	object	必須の既定インターフェース。dataAccess を使う場合は必ず定義します。
(任意のキー)	object	例：dataonly, API, agent。用途別の追加インターフェースを自由に定義します。
name	object (lang)	多言語名称（ISO 639-1）。UI表示向け。
description	object (lang)	多言語説明（ISO 639-1）。
outputPorttype	string	出力様式：file, API, SQL, AI, gRPC, sFTP など。
format	string	データ形式（JSON, CSV, XML, zip, GraphQL, MCP など）。
authenticationMethod	string	OAuth, Token, API key, HTTP Basic, none などの認証方式。
specification	string	インターフェース仕様の種類（OAS, RAML, Slate, MCP 等）。
specsURL	URL	機械可読な技術ドキュメント（例：OpenAPI YAML）。
accessURL	URL	実際のエンドポイント／ダウンロードURL。
documentationURL	URL	人間可読の手順書やガイド。
hashType / checksum	string	（任意）ファイル整合性検証のためのハッシュ種別と値。

参照の仕方（例）：access: $ref: '#/dataAccess/default'
pricingPlans など他セクションから、定義済みアクセス手段を再利用できます。

2.8.4. 参照と分割の設計指針

• 一括参照：dataAccess: { $ref: 'https://example.org/dataAccess/all.yaml' }
  　→ すべてのプロファイルを単一ファイルで管理・検証・バージョン付けできます。
• 個別参照：各プロファイル配下で $ref を使う
  　→ チーム別に所有・更新する場合に適します（ファイル数は増えます）。

2.8.5. サンプル

dataAccess:
  default:
    name:        # 多言語
      - en: Access to zipped package
    description:
      - en: Latest Dataset and Resources
    outputPorttype: file
    format: zip
    accessURL: https://example.org/download/latest.zip

  API:
    name:
      - en: Access to API
    description:
      - en: API Access to the Latest Dataset
    outputPorttype: API
    authenticationMethod: OAuth
    specification: OAS
    format: JSON
    accessURL: https://data.cms.gov/data-api/v1/dataset/2/data
    specsURL: https://data.cms.gov/provr-enrollment/api-docs
    documentationURL: https://data.cms.gov/provr-enrollment/docs

  agent:
    name:
      - en: AI Agent access to the data product
    description:
      - en: MCP interface for structured data access and agent interaction.
    outputPorttype: AI
    authenticationMethod: Token
    specification: MCP 2025-03-26
    format: MCP
    specsURL: https://urbanpulse.ai/llms.txt
    documentationURL: https://urbanpulse.ai/llms-full.txt

2.9. Open Data Product Specification — dataHolder

2.9.1. 概要

dataHolder は、データプロダクトを合法的に作成・公開できる組織（または個人） を定義します。
EU Data Governance Act に拠れば、データホルダーとは「当該データに関して法的にアクセス権・共有権を持つ法人・公的機関・国際機関・自然人（ただしデータ主体ではない）」を意味します。
データホルダーは、データの知的財産権（IPR）を保有していない場合でも、契約や法的根拠に基づき、そのデータを運用・共有する権利を有します。
データ提供者とデータ所有者の間で交わされる契約や合意内容は、本仕様のメタデータやライセンス情報としては対象外です。

この要素は、データの法的な出自と組織的責任の所在 を明確化するものであり、
データプロダクトの信頼性・追跡性・責任分担を保証する中心的なメタデータ層です。
特にデータメッシュ環境では、businessDomain により組織的責任と技術的境界を連動させる設計が推奨されます。

2.9.2. 主な目的

• 法的実体の明示：誰がこのデータを「公開・配布できるか」を明文化する。
• 信頼と責任の可視化：企業・公共機関・個人事業体など、データ発行者の透明性を担保する。
• データメッシュ／ドメイン設計と接続：businessDomain によりドメイン単位の所有関係を定義可能。
• 多言語UI対応：en, ja 等の言語コード配下で多言語記述を許容。
• ブランド表現：logoURL, slogan, description により企業アイデンティティを明示。

2.9.3. 構成要素（v4.1）

要素	型 / 属性	説明
dataHolder	element	データホルダー情報を束ねるルート要素。
en / ja / ...	attribute	ISO 639-1 言語コード。UIに表示される言語別情報をまとめる。
legalName	string	必須。 登記上の正式名称（例：MindMote Oy）。
businessID	string	登録事業者ID。各国の商業登記番号など。
contactName	string	担当者名。
email	string	連絡用メールアドレス。
taxID / vatID	string	納税者番号・VAT番号などの識別子。
businessDomain	string	データメッシュ設計上のビジネスドメイン名。
logoURL	URL	組織ロゴへのリンク。
description	string	組織紹介文。業務内容や専門領域を記述。
URL	URL	組織公式サイトURL。
telephone	string	電話番号（E.164形式推奨）。
streetAddress / postalCode / addressRegion / addressLocality / addressCountry	string	住所関連情報。addressCountry は ISO 3166-1 α-2 国コード。
aggregateRating / ratingCount	string / integer	評価平均値と評価件数（マーケットプレイス等で使用可能）。
slogan	string	組織スローガン（ブランド表現用）。
parentOrganization	string	上位組織名。グループ企業等を記述可能。

2.9.4. サンプル

dataHolder:
  en:
    legalName: MindMote Oy
    businessId: 12243434-12
    email: [e-mail]
    taxID: "12243434-12"
    vatID: "12243434-12"
    logoURL: "https://mindmote.fi/logo.png"
    description: "Digital economy services and tools"
    URL: "https://mindmote.fi"
    telephone: "[phone]"
    streetAddress: "Koulukatu 1"
    postalCode: "33100"
    addressRegion: "Pirkanmaa"
    addressLocality: "Tampere"
    addressCountry: "FI"
    slogan: "Smart Data, Simple Decisions"

2.10. Open Data Product Specification — paymentGateways

2.10.1 概要

paymentGateways は、データプロダクトの利用課金・決済処理 をどのように行うかを定義する要素です。
価格プラン（pricingPlans）に金銭取引が伴う場合、この要素を通じて「どの決済システムを用いるか」「どのように構成されているか」を明示します。
Stripe・Axio・独自ゲートウェイなど、複数の支払い手段を名前付きプロファイル（例：default, Agent, premiumStripe）として定義し、再利用・参照（$ref）可能にします。

2.10.2 主な目的

• 決済処理の標準化：価格プランごとに異なる決済処理を、構造化された形式で一元管理。
• 再利用と整合性：$ref により、複数プランから共通ゲートウェイ設定を参照可能。
• AI時代の課金対応：人間ユーザーと AI エージェント双方に対応した支払い手段を併記可能。
• 透明性と自動化：reference と spec により、ドキュメント・実行設定を機械可読化。

2.10.3 構成要素（v4.1）

要素	型 / 属性	説明
paymentGateways	object	すべての決済ゲートウェイ定義を含むルートオブジェクト。各キーは名前付き設定。
$ref	URI / filepath	外部ファイルへの参照（例：https://example.org/gateways/all-packages.yaml）。プロファイルを一括管理可能。
default	object	必須の既定ゲートウェイ。最小構成での互換性を保証。
(任意のキー)	object	任意の追加ゲートウェイ設定（例：Agent, premiumStripe など）。
description	object (lang)	多言語説明（ISO 639-1）。UI表示やカタログ化に利用。
type	string	使用する決済システム（Stripe, Axio, Checkout, Custom 等）。
version	string	対応するAPI・SDK・仕様のバージョン。
reference	URL	外部ドキュメント・開発者向けリファレンス。
spec	string / YAML / URL	実行可能ロジックまたは宣言的設定。YAML, JS snippet, 外部ファイルなどを許容。

2.10.4. サンプル

paymentGateways:
  default:
    description:
      en: API consumption payment gateway for humans
    type: Stripe
    version: 1
    reference: 'https://docs.stripe.com/'
    spec: |
      stripe.createCheckoutSession({
        amount: 100,
        currency: 'usd',
        success_url: 'https://your-platform.com/success',
        cancel_url: 'https://your-platform.com/cancel'
      });

  Agent:
    description:
      en: Payment gateway for AI agents
    type: Axio
    version: 1
    reference: 'https://www.x402.org/'
    spec: |
      paymentMiddleware("0xYourAddress", {"/your-endpoint": "$0.01"});