Why Open Dataspacesのまとめ

Why Open Dataspacesのまとめ
https://www.ipa.go.jp/digital/architecture/reports/open-dataspaces-design-philosophy.html
https://www.ipa.go.jp/digital/architecture/documents/rcu1hd000000chgw-att/WhyOpenDataspaces_jp.pdf

Transcript

1. I N T E R N A L S T U D Y S E S S I O N Why Open Dataspaces 設計思想とアーキテクチャパラダイム Leveraging distributed data management for inter-organization and global interoperability April 2026 KEY WORDS: dataspaces, data mesh, ontology, semantic layer, usage control, Agentic AI, DDD
2. A B O U T 本書の目的と位置づけ Open Data Spaces (ODS) とは 国や組織ごとの多様性を尊重する、オープンでスケーラブルな 分散データマネジメントの技術コンセプトの名称。 IPA デジタルアーキテクチャ・デザインセンター (DADC) が技術的な設計統括を行う。 Open Dataspaces（一般技術名称） データスペース原著論文 (2005) とデータメッシュ (2019) を源流とす る、新世代の分散データマネジメント技術の総称 ODS（固有名称） 上記パラダイムを具体化するIPA主導の技術コンセプト。International Data Spaces / Eclipse Data Spaces とは出自・設計指針が異なる 出典: IPA『Why Open Dataspaces』pp.4, 9 (CC BY 4.0) Why Open Dataspaces｜社内勉強会 2 / 32
3. A G E N D A 本日のアジェンダ 1 イントロ データ枯渇とダークデータ AI時代のデータ戦略 2 パラダイム変遷 集約→分散 Push&Ingest → Serving&Pull 3 データメッシュ 組織内・部門間 4原則とその限界 4 Classical Dataspaces 組織間・国境間 2005年原著論文の思想 5 Open Dataspaces 設計指針と3つの柱 DAD / OSI / IUC 6 DPQM AQの最小単位 Data & Ontology Product 7 3つの柱（詳細） OSI / DAD / IUC 半分以上のボリューム 8 サービスモデル 実装パターン 分散 / 連邦 / HSM Why Open Dataspaces｜社内勉強会 3 / 32
4. 1 . イ ン ト ロ ダク シ ョ ン 2026年「データ枯渇元年」 Agentic AI時代、学習データの供給制約が顕在化 2026 データ枯渇元年 特に高品質データは 2026〜2032 年に枯渇する可能性 AIの性能を決める3変数（Scaling Laws） モデル規模 パラメータ数 計算能力 半導体・電力・通信の激戦区 学習データ量 供給制約が社会的に未認識 ⚠ 出典: Epoch AI (2024) “Will We Run Out of Data?” Why Open Dataspaces｜社内勉強会 4 / 32
6. 1 . イ ン ト ロ ダク シ ョ ン リアルデータ vs 合成データ データ枯渇への補完供給源は2つ。両者は優劣ではなく相互補完 リアルデータ Real Data ✓ 特徴 実世界の観測・取引データ （業務データ／設計図／IoTセンシング 等） ⚠ 課題 プライバシー・営業秘密により 取得と共有の障壁が高い 合成データ Synthetic Data ✓ 特徴 モデル・統計手法による人工生成。 供給総量を拡大しやすい ⚠ 課題 再帰利用で多様性喪失 = モデル崩壊リスク → リアルデータの供給は必須 最適戦略: リアルデータを保持しつつ両者を組み合わせ、再帰汚染を最小化するデータ戦略の設計 Why Open Dataspaces｜社内勉強会 5 / 32
7. 1 . イ ン ト ロ ダク シ ョ ン リアルデータにおけるダークデータの比率 世界の年間リアルデータ総量 (2025) 175 ZB / 年 消費者由来: 71 ZB エンタープライズ由来: 104 ZB 複製除去後の有効量: 17.5 ZB うち ダークデータ: 約 16 ZB 出典: NEDO (2025) ダークデータとは インターネット非公開のまま企業内に留まっているリアルデータ。潜在的な 学習・推論資源としての価値を持つが、そのままでは利用に供せないケース が多い。 利用を阻む2つの構造的要因 01 偏りと品質汚染 そのまま使うと学習・推論の精度を下げる要素を含むことが多い 02 文脈フィルタリング必須 ビジネス上の目的・文脈に即したキュレーションが利用の前提 Why Open Dataspaces｜社内勉強会 6 / 32
9. 1 . イ ン ト ロ ダク シ ョ ン GIGO とドメインコンテクスト 量ではなく「品質」が最大の障壁。品質は組織の自律的責任単位 = ドメインに依存する Garbage-In, Garbage-Out (GIGO): 利用目的と整合性のないデータを大量に取り込めば、むしろ利用結果の精度や汎用性を損なう。 さらに価値を生まないランニングコストが財務を圧迫する。 Agentic AI時代の検討論点 論 点 1 コンテクスト付与 ダークデータにどのようにドメインコンテク ストを与えるか 論 点 2 経営資本化 コンテクストを付与したデータを、将来 キャッシュフローを生む経営資本として機能 させるか 論 点 3 分散管理 企業・国境を横断して分散するデータとコン テクストを、どのようにマネジメントすべき か 結論: コンテクストこそドメイン固有の財産。データを「プロダクト」として提供・制御することが企業価値を定義する時代 Why Open Dataspaces｜社内勉強会 7 / 32
10. 2 . パ ラ ダイム 変 遷 集約から分散へ: データマネジメントの変遷 ビッグデータ 3Vs を乗り越え、現在は Complexity の時代 Hadoop/HDFS、Amazon S3 など大規模ストレージ NoSQL (MongoDB, Cassandra)、JSON、ETL Kafka、Flink、Spark などスト リーム処理 散逸・分断・異質なまま存在す るダークデータへの対応 Complexityは技術的のみならず、産業・ビジネス・社会的・組織的・法制度的な多面的側面を持つ Why Open Dataspaces｜社内勉強会 8 / 32
11. 2 . パ ラ ダイム 変 遷 データマネジメントシステム世代変遷 Complexity に抗う 4 世代。だが全てが「集約 (Push and Ingest)」パラダイムの延長 第 0 世 代 DBMS 古典的関係型。スキーマ固 定・SQL 対象: BI中心 第 1 世 代 Data Warehouse 構造化データの集約と分析最 適化 対象: BI/DI 第 2 世 代 Data Lake 半・非構造データを低コスト で蓄積 対象: BI/DI/ML 第 3 世 代 Data Lakehouse DWHとDLの統合。AI/ML親 和性が拡大 対象: AI-native Time to Value (TtV) は改善したが、Aggregation中心のパラダイムから脱却できていない Why Open Dataspaces｜社内勉強会 9 / 32
12. 2 . パ ラ ダイム 変 遷 Push and Ingest パラダイムの限界 シンプル組織では機能するが、ドメインが多様な組織ではスケーラビリティの壁に衝突 Push and Ingest （従来） すべてを一箇所に集約・保存・処理 ✕ 中央集権型データ基盤の最適化を徹底 ✕ Biz / Dev / Ops ✕ の分業が前提 加工過程でコンテクストが失われる ✕ 利用者は意味・制約・条件をコードから推測 ✕ Serving and Pull （データメッシュ） ✓ データは生み出したドメインが保持 ✓ ドメインオーナーがプロダクトとして提供 ✓ Biz / Dev / Ops の融合が最適解 ✓ コンテクストはドメイン単位で保持される ✓ 分散 × 社会技術的アプローチ Zhamak Dehghani (2019, 2022) によるパラダイムシフトの提唱 Why Open Dataspaces｜社内勉強会 10 / 32
13. 3 . デ ー タ メ ッ シ ュ データメッシュの 4 原則 01 Domain Ownership ドメインオーナー自身がデータを所有・責任を持 つ 02 Data as a Product オペレーションの副産物ではなく、明示的に設 計・提供される商品として扱う 03 Self-Serve Data Platform ドメインが自律的に運用できるセルフサービス型 のプラットフォーム 04 Federated Computational Governance 連邦型の計算可能なガバナンスによる横断的な秩 序 従来の中央集権型アーキテクチャに対する重要な転換点 Why Open Dataspaces｜社内勉強会 11 / 32
14. 3 . デ ー タ メ ッ シ ュ データメッシュの限界: Governance Complexity 組織内の部門間連携を暗黙の前提とするため、組織境界を越えると課題が顕在化 W h e r e t o g e t 所在と同一性の問題 例: OEM契約先の製造実績はどこで取得可能か? 「6AX-10K Industrial Robot」と「Robot 10kg Standard Model」は同一機体か? W h a t t o m e a n 意味の問題 例: 広報チームの Alice は本当に広報部門所属か? 「高度」は標高なのか対地高度なのか? W h o a n d H o w t o u s e 利用条件の問題 例: アクセス者 (Agentic AI) はどの会社の運用か? このストリーミングデータは単位時間あたりいく らか? BI以外の二次利用は? スケーリングに伴う Governance Complexity の問題 — 組織・国境を横断するとガバナンスコストは爆発する Why Open Dataspaces｜社内勉強会 12 / 32
15. 4 . C l a s s i c a l D a t a s p a c e s 米国での「データスペース」誕生の背景 2005年、UC Berkeley の Franklin ら DBMS を補完する「新たな抽象化」として提唱 原 著 論 文 Franklin, Halevy, Maier (2005) “From databases to dataspaces: a new abstraction for information management” 扱う対象 = HCoD Heterogeneous Collection of the Data 組織に分断された異質なデータコレクション データスペースの特徴 参加者 (participant) と関係 (relationships) で定義される 参加者は RDB / XML / 文書DB / ウェブサービス 等のデータソース 構造化・半構造・非構造データいずれも参加可能 2以上の参加者のいかなる関係性もモデリング可能 ネスト構造・重複構造でも存在しうる アクセスルールは異なる性質のスペース間で共有 中央集権的 Push and Ingest と明確に異なるアプローチ。個々のソースの上に「空間 (spaces)」を定立 Why Open Dataspaces｜社内勉強会 13 / 32
16. 4 . C l a s s i c a l D a t a s p a c e s Open Dataspaces の理論的な源流 2つの源流を継承し、組織・国境横断の Governance Complexity に応える Classical Dataspaces (2005, 米国) HCoD に対する抽象化概念。DBMS の補完として「空間」を定立 Data Mesh (2019, Dehghani) Serving and Pull のパラダイム。DDDベース・4原則による分散 Open Dataspaces 部門間 → 組織間 → 国境間のデータマネジメント DFFT (Data Free Flow with Trust, 2019 G20大阪) の理念を技術的に具体化 Inter-Department → Inter-Organization 継承: Serving and Pull 型 + Domain-Driven Design + 4原則 Why Open Dataspaces｜社内勉強会 14 / 32
19. 5 . O p e n D a t a s p a c e s 3 つの柱 — 秩序と緩やかな規律 組織横断 × Agentic AIを前提に、3つの柱で透過的な SSOT と価値還元メカニズムを実現 W h e r e t o g e t DAD Data Addressability & Discoverability データの「存在」と「同一性」を保証し、関係性 を提供する緩やかな検索機構 W h a t t o m e a n OSI Ontology and Semantic Interoperability データモデルから情報モデルを分離し、推測では なく知識でデータを扱う W h o & H o w t o u s e IUC Identity and Usage Control Trust by Design の思想で、認証・認可・利用条 件を柔軟に設計 プロトコルは疎結合・後方互換を設計段階でビルトイン。Minimal Yet Viable な段階導入を重視 Why Open Dataspaces｜社内勉強会 15 / 32
20. 5 . O p e n D a t a s p a c e s 設計指針 — 3 つの根幹原則 01 ベンダーロックインの回避 マルチクラウド・クラウドレス動作を前提とし、特定企業のサービス・商品に依存しないベンダーフリー設計 02 制度的ロックインの回避 特定法域の制度的・規制的要件を技術仕様から明示的に分離。グローバル適応可能な設計とローカライゼーション 03 プロダクトライクでサービス志向の設計 解くべき課題はマーケットにある。Make Money, Save Money に資するか。PMF を目指したアジャイル検証 注: ここでいう「Open」はデータをインターネット公開することではなく、3つのロックインからの開放を意味する Why Open Dataspaces｜社内勉強会 16 / 32
21. 6 . D P Q M アーキテクチャ最小単位 — Double-Product Quanta Model データメッシュの AQ (Data Product) に Ontology Product を加え、表裏一体の構成単位とする データメッシュ Single-Product AQ Data Product 意味と構造が同一スキーマに混在 → 意味の変更 = スキーマ破壊 An Open Dataspace = 2以上の AQ からなる Architectural Quantum (AQM) Why Open Dataspaces｜社内勉強会 17 / 32
23. 6 . D P Q M OWA と CWA の二層構造 — 選択的な厳格性 DPQMの強さ=均質な完全性強制ではなく、システム全体の開放性を維持しつつ選択的に厳格化 OWA Open World Assumption（開世界仮説） 「真と判断できないことは、偽ではないとみなす」 適用: Ontology Product • ドメインオーナーの自己宣言を積極的に包摂 • 発展途上の不完全な記述も排除しない • 結果整合性 (Eventual Consistency) • 静的検索に親和性 (例: 航空の航路情報) CWA Closed World Assumption（閉世界仮説） 「真と判断できないことは、偽であるとみなす」 適用: Data Product（選択的） • 信頼性・完全性・一貫性の明示的保証が必要な領域 • 強い一貫性 (Strong Consistency) • 動的変動データの同期が必要 (例: 運航管理) • Data Trust の検証可能インターフェース 集合論の束縛からの解放 — 現実世界を有限集合として事前定義することは不可能 Why Open Dataspaces｜社内勉強会 18 / 32
24. 6 . D P Q M 基本用語と機能レイヤー AQ と AQM の関係 製造企業 (生産) Data + Ontology Product 卸売業 (物品) Data + Ontology Product Wholesale Distribution Dataspace (AQM) 多元的・重層的な集合関係を含む総体 = Open Dataspaces AQ の機能レイヤー (4層) L4 Semantic / Ontology Layer 意味・制約・推論 L3 Identity Layer 実在性・認証・認可 L2 Transaction Management マルチモーダル抽象化・通信 L1 API Gateway Layer 疎結合なエントリポイント Identity/認証・認可は L3 に集約 — 信頼は横断的パースペクティブとして分離 前提 (Assumption): ①自己宣言的提供 ②不完全性で排除しない ③利用者は明示的保証を求める Why Open Dataspaces｜社内勉強会 19 / 32
25. 柱 1 : O S I データモデルから情報モデルを分離する 最も原始的でスケーラビリティの枷となる問題 = 意味 (semantics) データモデル Data Product Role: Reflecting Reality 観測された事実としての要素を格納。 DBMSのスキーマ・テーブル相当。 効率的な保存・取得・更新が重視される。 一度記録された事実は原則として過去に遡って変更されない。 情報モデル Ontology Product Role: Knowledge Unit 事実をどのように解釈・関連付け・制約・操作するかの意味を表現。 分類・同一性・前提条件・禁止事項といった意味論的な構造を担う。 運用の変化に応じて更新され、時間を遡って再解釈されうる。 意味の進化を、データ構造の破壊ではなく「再解釈」として扱うための DPQM の強み Why Open Dataspaces｜社内勉強会 20 / 32
26. 柱 1 : O S I 実装レイヤー — RDF / RDFS / OWL Semantic Web 技術スタックにより、知識単位として分散的に拡張可能な構造を提供 AQ Data Product Ontology Product レベル Data Model Information Model(狭義) Semantics Ontology 表現 Multi-Modal Raw Data RDF / RDF* RDF Schema OWL 目的 Reflecting Reality Knowledge Unit Vocabulary & Structure Validation & Reasoning RDF / RDF* — Subject–Predicate–Object のグラフモデル。意味未確定でも関係を保持して分散拡張 RDFS — 語彙 (vocabulary) と構造 (structure) を与える基礎層 OWL — 妥当性・排他性等の制約を定義。推論器により意味推論と意味的矛盾検出を実現 『A Little Semantics Goes a Long Way』 Why Open Dataspaces｜社内勉強会 21 / 32
27. 柱 1 : O S I Semantic Gap と Dynamic Ontology 推測 (Guess) から知識 (Knowledge) へ — LLM × Ontology の相補性 例 : 航 空 の 「 高 度 」 MSL (Mean Sea Level / 平均海面基準の標高) vs AGL (Above Ground Level / 対地高度) 同一概念として誤統合 → 負債の蓄積 → 運航管理インシデント Semantic Gap 特定ドメインの自己定義から生じる意味的差異。Ontologyが明示制約 (例: 高度は必ず一つの基準に属する / MSL≠AGL) → 論理的不整合と してエラー返却 Ontological Gap Ontology同士のギャップ。Vocabulary/単位変換/同一性判断。労働集 約的なクロスウォーク → LLM補完でスケール化 Dynamic Ontology: LLMが対応関係の仮説を提示し、Ontology構造で検証・制約。Human-in-the-loopで補助輪を段階的に外す Why Open Dataspaces｜社内勉強会 22 / 32
28. 柱 2 : D A D Addressability — 「存在」と「同一性」の保証 Addressability を欠いたデータは「存在しないのと同義」 2つの独立エンドポイント Ontology Endpoint 意味・構造へのエントリポイント。IRI でグローバル一意 Data Endpoint 実データソースへのエントリポイント Webの名前解決概念に依拠した、AQがOpen Dataspacesに現れるための唯一の 存在証明の接点 同一性の保証 — IRI International Resource Identifier Manufacturer: “6AX-10K Industrial Robot” Wholesale: “Robot 10kg Standard Model” Logistics: “Pallet#12345 / SKU-ROB-10KG-JP” ↓ IRI で結ぶ グローバルでユニークな識別子 — ドメイン固有の内部識別子は温存 後付けで「同一の実体について話している」と合意できる手段を提供 Why Open Dataspaces｜社内勉強会 23 / 32
29. 柱 2 : D A D Discoverability — 2 段階クエリ 完全な答えを返す検索機構ではなく、関係性を提供する緩やかな検索機構 S T E P 1 Ontology Query 任意のキーワードに対して Best Effort Result (= データカタログ) を提示 ✓ 意味のグラフを返す ✓ 完全性は保証しない ✓ OWA に親和 S T E P 2 Data Query Best Effort Result のグラフをベースに、紐づく Data Endpoint へアクセス ✓ 完全性が要求される領域 ✓ 選択的 CWA / Data Trust ✓ SLOに基づく品質アセスメント 動的ビューワーとしてのデータカタログ: CKAN型の静的リポジトリではなく、クエリ依存で都度 Best Effort Result として生成される Why Open Dataspaces｜社内勉強会 24 / 32
30. 柱 2 : D A D 分散カタログと Discovery Service 都度の全対全クエリは非効率。Web検索エンジンをモデルにしたインデキシング / クローリング Distributed Catalog 分散カタログ • ディスカバリ結果のローカルキャッシュ • インデックス / 横断クローリング • 計算量とランニングコスト最適化 • 各ドメインが自律的に参照可能 Discovery Service ディスカバリーサービス • 分散カタログや最初の Ontology Endpoint を 発見するための仲介機能の総称 • 利用者が Open Dataspaces をより効率的に 探索可能にする • Ontology Product 自体にも IUC が適用 (企業秘密に該当する場合もあるため) 補論: Data Trust = 完全性についての保証とリネージュの検証可能インターフェース (ODS Data Trust Assessment Protocol) Why Open Dataspaces｜社内勉強会 25 / 32
31. 柱 3 : I U C Trust by Design — アイデンティティの分解 「認証された主体」と「信頼してよい主体」を同一視しない — 信頼は設計対象 1 実在性の検証 Identity Proofing Q: 現実世界のどの個人・組織に対応するか? どの法人に雇用・運用され、どの契約に紐づく立場 で、それはいつまで有効か 2 認証 Authentication Q: 主体は主張するアイデンティティの所有者 か? アカウント、証明書、API Key など 3 認可 Authorization Q: この資源に対して、今、この操作をしてよい か? 設備A稼働ログは閲覧可、設備B制御APIは不可 など 組織の流動性により成立しない3つの暗黙前提: ① 組織境界の固定 ② 主体の同一性の自明 ③ 認証できた主体 = 信頼してよい主体 Why Open Dataspaces｜社内勉強会 26 / 32
32. 柱 3 : I U C アクセス制御 — Graph-to-Graph Control ゼロトラスト前提。PEP/PDP モデルで ReBAC + Ontology グラフを組み合わせる ゼロトラスト: PEP / PDP モデル PEP Policy Enforcement Endpoint APIゲートウェイ / クエリサーバーに配置。リクエストが通過する地点 PDP Policy Decision Endpoint ドメインごとに配置。アクセス可否を一元判断。監査・説明責任を集約 Graph-to-Graph Control ReBAC (Relationship-Based Access Control) + Ontology の 2つのグラフを連携 Ontology = 意味的な境界を定義 (どこまでが同一の資源・同一のコンテクストか) アクセスポリシーグラフ = 主体-資源の関係 (所属・契約・委任・属性) から許可を導出 PDP は確率的推測ではなく、関係の評価 / 導出 (infer) を行う Alice が人間/クローラー/Agentic AI であっても、同じグラフで推論可能 注: RBAC / ABAC 等、他のポリシー言語採用を否定するものではない。AuthZEN の標準化動向も進行中 Why Open Dataspaces｜社内勉強会 27 / 32
33. 柱 3 : I U C 利用制御 — 非対称性の補正 アクセス制御を拡張した権利・義務的概念。Classical Dataspaces には存在しなかった後付け概念 Usage Control = “the specification and enforcement of restrictions regulating what must(not) happen to data” (Steinbuss et al. 2021) ① 権利義務関係の非対称性 一度アクセス許可した相手に対し、用途・条件を制御する術が なければ、資源を無配慮に提供し続けることになる ② 価格決定権の非対称性 補正なき市場原理では、価格決定権は実質的にデータ利用者が 握ることになり、市場の失敗を招く可能性 利用制御の技術的手段の多様性 — 単一プロトコルで硬直化させない Contract Negotiation データ契約による交換・交渉 ブロックチェーン秘密計算 BI/DI領域 (例: カーボンフットプリント) Data Clean Room AI領域での差分プライバシー学習 Machine Unlearning 先端研究中の忘却技術 市場からの要件由来ではなく、制度要件由来の技術的手段を強制することは、適合コストを強いることになる Why Open Dataspaces｜社内勉強会 28 / 32
34. 柱 3 : I U C 補論: 電子契約 / 精算・課金 (オプショナル) ODS Protocols の一部として、サードパーティ接続を想定したインターフェースのみ提供 O P T I O N A L Heuristic Contracting Protocol 電子契約行為 (e-Contracting) 締結結果を PDP に反映するところまでが所掌範囲。独自の契約交渉手順は含 まず、既存の電子契約サービスと接続。 機械完結にこだわらず、法務部などの Human-in-the-loop コールバックも許 容。 O P T I O N A L Clearing and Payment Protocol 精算・課金 / 決済行為 Data Product 利用に際したエンドポイントを提供。契約行為と同様、第三者 サービスとの接続が前提。 データマーケットプレイスといった高度なサービスの基盤となる。 Common Functionality: トランザクションの横断的なログ・モニタリングとしてイベント検知・アラート・通知を実現 Why Open Dataspaces｜社内勉強会 29 / 32
35. 8 . サ ー ビ スモ デル 実装パターン — 分散型 / 連邦型 / HSM D i s t r i b u t e d 分散型サービスモデル ドメインオーナー自身が Self-Serve Data Platform を構築し、DPQM に基づいて Data Product / Ontology Product を提供 デジタル財源のある大企業向け F e d e r a t e d 連邦型サービスモデル ソフトウェアスタックを DSSP (Dataspace Service Provider) が代理提供。ドメイン オーナーはProduct提供に責任を持つ 中小企業やリソース制約下でも導入可能 H S M Hybrid Service Model 分散型 × 連邦型の混成。ドメインオーナー自 身と DSSP 仲介の両経路でオンボード 実例: 車載蓄電池CFP (OEM+Tier1+Tier2) DSSP (Dataspace Service Provider) = Classical Dataspaces 由来。仲介者 (Intermediaries) として Open Dataspaces の裾野を拡大する重要プレイヤー Why Open Dataspaces｜社内勉強会 30 / 32
37. S U M M A RY まとめ — Open Dataspaces の本質 Open Dataspaces は、国や組織ごとの多様性を尊重する、オープンでスケーラブルな分散データマネジメント技術 『データに飲み込まれる世界』における、企業の最も本質的な生存戦略 1 3つの柱 DAD / OSI / IUC — 秩序と緩やかな 規律 2 DPQM Data × Ontology Product の表裏一 体設計 3 OWA基調 選択的な厳格性で CWA を内包 4 段階導入 Minimal Yet Viable + 疎結合プロトコ ル 5 3ロックイン回避 ベンダー / 制度 / 硬直的設計 6 Agentic AI対応 推測から知識へ, Dynamic Ontology コンテクストこそドメイン固有の財産 — データを「プロダクト」として提供・制御することが企業価値を定義する Why Open Dataspaces｜社内勉強会 31 / 32
38. R E F E R E N C E S 参考文献・さらなる学習リソース 主要参考文献 • Franklin, Halevy, Maier (2005) “From databases to dataspaces” • Halevy, Franklin, Maier (2006) “Principles of Dataspace Systems” • Dehghani Z. (2019) “How to Move Beyond a Monolithic Data Lake…” • Dehghani Z. (2022) Data Mesh (O’Reilly) • Otto B. et al. (2016) Industrial Data Space Whitepaper (Fraunhofer) • Steinbuss S. et al. (2021) Usage Control in IDS • Epoch AI (2024) “Will We Run Out of Data?” • NEDO (2025) Data Spaces Market Size Study • METI / IPA (2025) Ouranos Ecosystem Dataspaces RAM Whitepaper 次に読むべきドキュメント ODS-RAM Reference Architecture Model — 具体的な設計物 ODS Protocols 各プロトコル技術仕様 (Trust / Usage / Contracting 等) ODS Middleware 参照実装 OSS ソースコード Contact: IPA デジタルアーキテクチャ・デザインセンター dadc-ods-ml@ipa.go.jp “伽藍とバザールの理念を胸に、全世界のOSSコミュニティの力を信じて前進させる” — 津田通隆 Why Open Dataspaces｜社内勉強会 32 / 32