🤝

Property GraphとRDF の違いと選択方法

koki takeishi

2025/04/20に公開

 はじめにナレッジグラフを扱う際に、オントロジー設計やGraphDBの選定などで、Property Graphを使うのか、RDFを使うのかという選択がまずあるみたいです。
どんな違いがあるか、どちらを選択するかをDeep Research結果を踏まえて考えてみます。
ちなみに、Property GraphとRDF以外でメジャーなモデルに下記があるそうです。
その他メジャーなモデル


モデル
主眼
データ単位と特徴
代表実装／標準
こんなとき便利


Topic Maps (ISO 13250)
「主題 (topic)」中心の知識編成
• Topic・Association・Occurrence の 3 成分• 同一主題のマージ規則が仕様で定義
ISO 13250-2 TMDM データモデル、TMQL/TMCL クエリ・スキーマ言語 Isotopic Maps
・ドキュメント集合を“話題別”に整理したい・同一概念の多義解消や索引付けが重要

ハイパーグラフ (HyperGraph Model)
n 項関係を素直に表現
• エッジが複数ノード／他エッジへ接続 (= ハイパーエッジ)• 再帰的ラベル付けでメタ関係を持てる
HyperGraphDB ― オープンソース分散 DB。原子 (atom) がノード/エッジに共通 API Database of Databases
・分子構造・サプライチェーンなど n > 2 の関係が多い・推論よりも複雑構造の格納／検索が重要

エンティティ‑リレーション強型モデル (TypeDB/Grakn)
型安全 + 推論
• Entity / Attribute / Relation / Role をスキーマで明示• n‑ary 関係と多重継承を標準サポート• ルール推論・制約検証を DB レイヤで実施
TypeDB 3.x + TypeQL (高水準パターンマッチ) TypeDB
・ドメイン概念をそのまま型で表現したい・アプリ側でなく DB に一貫性チェックを任せたい



 1. 概観 ― どちらも「グラフ」だが設計思想が違う

モデル
主な設計目的
規格
代表実装



RDF (Resource Description Framework)
Webで意味情報を共有・統合するための“リンクトデータ”基盤
W3C RDF1.1(2014)
Virtuoso, GraphDB, Amazon Neptune など


Property Graph (Labeled Property Graph, LPG)
アプリケーションで高速に“つながり”を検索・更新するエンジン
ISO/IEC GQL(2024)
Neo4j Enterprise, TigerGraph, MemGraph など


 2. コアデータ構造

要素
RDF
Property Graph


最小単位

Triple = (subject, predicate, object)

Node ↔ Relationship（矢印）
両方に Property (key‑value) と Label


ノード
URI / blank node / literal
任意 ID（数値・文字列）、ラベル集合、プロパティ

エッジ
predicate＝URI。エッジ自体にプロパティなし (RDF-starは除く)
ラベル付き。エッジそのものにプロパティ可

グラフ単位
“RDF グラフ”と “RDF Dataset” (複数グラフの束)
データベースごとに 1 つ以上のグラフを保持

スキーマ
vocabulary (rdf:type), rdfs:Class, owl:Class 等
ベンダ固有のスキーマ記述／GQL type

識別子
IRI/URL がグローバル一意
実装依存（数値 ID や UUID）


 3. モデリング例（人が友人を「知っている」）
 RDF (Turtle)@prefix ex: <http://example.com/> .
ex:alice  ex:knows  ex:bob .
ex:alice  ex:age    29 .
Turtle は、RDF の triple を 簡潔に人間が読み書きしやすく するための記法

 Property Graph (Cypher)CREATE (a:Person {name:'Alice', age:29})
CREATE (b:Person {name:'Bob'})
CREATE (a)-[:KNOWS {since:2019}]->(b);
Cypher ではエッジ自体 (KNOWS) に属性 since を直接付与できる点が対照的。

 4. セマンティクスと推論

観点
RDF
Property Graph


世界仮定

Open World: 未知＝不明

Closed Worldが前提になる実装が多い 参考


推論エンジン
RDFS / OWL / SHACL によるクラス継承・制約・ルール
パターンマッチやアプリ側ロジック。GQL で型制約が策定中

スキーマ表現
Vocabulary (rdf:type) と Ontology
ラベル＋プロパティ型（Neo4j Constraints 等）、GQL schema

得意分野
異種データ統合、Linked Data、意味推論、データ共有
リアルタイム分析、探索的トラバーサル、アプリケーション埋め込み

https://flur.ee/fluree-blog/rdf-versus-lpg/
!Open World Assumption：RDFはオープンワールド仮定に基づいて動作します。つまり、まだ知られていない、あるいは不完全な情報を許容します。RDFでは、既存の情報を変更することなく、新しい情報を追加できます。一方、ラベル付きプロパティグラフは、知られていない情報は誤りであると仮定しますが、これは多くの状況で正確ではない可能性があります。
!Semantic Expressiveness：RDFの最も優れた点の一つは、意味を明示的に表現できることです。RDFは主語-述語-目的語の文を用いることで、知識を豊かかつ正確に表現することができます。これは、異なる分野の知識をより効果的に結び付け、分析できることを意味します。一方、ラベル付きプロパティグラフでは、複雑な知識を表現したり、高度な分析を実行したりすることが困難な場合があります。

 5. クエリ言語

機能

SPARQL 1.1 (RDF)

Cypher/Gremlin/GQL (Property Graph)


パターンマッチ
?s ex:knows ?o .
MATCH (s)-[:KNOWS]->(o)

可変長パス
ex:knows+
(:Person)-[:KNOWS*1..]->(:Person)

推論付き検索

owl:TransitiveProperty 等を考慮
基本はサブグラフ探索

更新
INSERT DATA { … }

CREATE, MERGE, SET, DELETE



 6. 強みと課題

項目
RDF
Property Graph


相互運用
グローバル IRI と既存語彙 (FOAF, Schema.org) を再利用しやすい
アプリ内完結が多く標準語彙が少ない

推論・厳密性
OWL による論理推論と SHACL での妥当性検証
型安全は GQL で整備中／制約は実装依存

性能 (OLTP)
トリプル総数が多いと深いトラバーサルが遅くなる傾向
ノード/リレーションを直接格納し高速

開発生産性
Web API との親和性が高いが JSON 直列化は冗長になりがち
Cypher が SQL ライクで理解しやすい


 7. オントロジー／スキーマ設計の観点

目的
RDF オントロジーを使うメリット
Property Graph でのやり方


語彙統一・再利用
FOAF、Schema.org など既存語彙をURI 単位で参照できる。相互運用が高い
ラベル名の衝突を利用者側で回避。外部語彙との正式な同一視は困難

推論
RDFS/OWL による継承・制約推論がエンジンで自動実行
パターンマッチやアプリケーションコードで実装。形式推論は限定的

時間・履歴
“named graph” でバージョンを分けたり、prov:generatedAtTime で時刻メタを付与
エッジ／ノードのプロパティに valid_from, valid_to 等を直接保持しやすい

SHACL/Shex によるデータ整合性
W3C 標準
多くは独自 (Neo4j Constraints など)。GQL で型＋制約が策定中


 8. 選択の指針RDF が向くケース
異なるドメインをまたぐ データ統合／公開（Linked Data）
推論や厳密な語彙管理が不可欠なエンタープライズ・ナレッジグラフ
規制・標準準拠が強い（政府オープンデータ等）
Property Graph が向くケース
ソーシャル・ネットワーク、レコメンドなど高速トラバーサルを多用
エッジメタ情報を多く持ち、アプリで頻繁に更新されるワークロード
RDB に近い開発体験（Cypher/GQL）を好むアプリ開発チーム
ハイブリッド
RDF ⇄ LPG 相互変換ツール（データ仮想化／ETL）があり、

マスターデータは RDF、アプリケーション層は Property Graph といった分離も実践される。

 9. 互換性と最新動向
ISO GQL 2024 により Property Graph のクエリ言語が国際標準化されたGQL標準公開
各ベンダは RDF インポート/エクスポート機能 を実装（Neo4j では n10s プラグインなど）ne04j公式

 まとめRDF は “意味と互換性” を最優先に設計されたセマンティック Web 基盤。

Property Graph は “アプリ実装と探索性能” を最優先に設計されたデータベースモデル。
両者は相互変換が可能で、RDF-starや SHACL、そして ISO GQL 2024 の登場により機能ギャップは縮まりつつあります。要件（データ連携か、リアルタイム分析か、推論か）を軸に選択・ハイブリッド導入を検討する必要がありそうです。
個人的には、下記の考えが良さそうかなと。
https://neo4j.com/blog/knowledge-graph/rdf-vs-property-graphs-knowledge-graphs/
!現代のベストプラクティスは両方の考え方を取り入れています。プロパティグラフをデフォルトで使用し、RDFの世界の組織化原則（タクソノミー、オントロジー）を技術的な前提条件としてではなく、システムで必要なときにレイヤー化する方が実用的です。

モデル	主眼	データ単位と特徴	代表実装／標準	こんなとき便利
Topic Maps (ISO 13250)	「主題 (topic)」中心の知識編成	• Topic・Association・Occurrence の 3 成分• 同一主題のマージ規則が仕様で定義	ISO 13250-2 TMDM データモデル、TMQL/TMCL クエリ・スキーマ言語 Isotopic Maps	・ドキュメント集合を“話題別”に整理したい・同一概念の多義解消や索引付けが重要
ハイパーグラフ (HyperGraph Model)	n 項関係を素直に表現	• エッジが複数ノード／他エッジへ接続 (= ハイパーエッジ)• 再帰的ラベル付けでメタ関係を持てる	HyperGraphDB ― オープンソース分散 DB。原子 (atom) がノード/エッジに共通 API Database of Databases	・分子構造・サプライチェーンなど n > 2 の関係が多い・推論よりも複雑構造の格納／検索が重要
エンティティ‑リレーション強型モデル (TypeDB/Grakn)	型安全 + 推論	• Entity / Attribute / Relation / Role をスキーマで明示• n‑ary 関係と多重継承を標準サポート• ルール推論・制約検証を DB レイヤで実施	TypeDB 3.x + TypeQL (高水準パターンマッチ) TypeDB	・ドメイン概念をそのまま型で表現したい・アプリ側でなく DB に一貫性チェックを任せたい

モデル	主な設計目的	規格	代表実装
RDF (Resource Description Framework)	Webで意味情報を共有・統合するための“リンクトデータ”基盤	W3C RDF1.1(2014)	Virtuoso, GraphDB, Amazon Neptune など
Property Graph (Labeled Property Graph, LPG)	アプリケーションで高速に“つながり”を検索・更新するエンジン	ISO/IEC GQL(2024)	Neo4j Enterprise, TigerGraph, MemGraph など

要素	RDF	Property Graph
最小単位	Triple = (subject, predicate, object)	Node ↔ Relationship（矢印）両方に Property (key‑value) と Label
ノード	URI / blank node / literal	任意 ID（数値・文字列）、ラベル集合、プロパティ
エッジ	predicate＝URI。エッジ自体にプロパティなし (RDF-starは除く)	ラベル付き。エッジそのものにプロパティ可
グラフ単位	“RDF グラフ”と “RDF Dataset” (複数グラフの束)	データベースごとに 1 つ以上のグラフを保持
スキーマ	vocabulary (rdf:type), rdfs:Class, owl:Class 等	ベンダ固有のスキーマ記述／GQL type
識別子	IRI/URL がグローバル一意	実装依存（数値 ID や UUID）

観点	RDF	Property Graph
世界仮定	Open World: 未知＝不明	Closed Worldが前提になる実装が多い参考
推論エンジン	RDFS / OWL / SHACL によるクラス継承・制約・ルール	パターンマッチやアプリ側ロジック。GQL で型制約が策定中
スキーマ表現	Vocabulary (rdf:type) と Ontology	ラベル＋プロパティ型（Neo4j Constraints 等）、GQL schema
得意分野	異種データ統合、Linked Data、意味推論、データ共有	リアルタイム分析、探索的トラバーサル、アプリケーション埋め込み

機能	SPARQL 1.1 (RDF)	Cypher/Gremlin/GQL (Property Graph)
パターンマッチ	`?s ex:knows ?o .`	`MATCH (s)-[:KNOWS]->(o)`
可変長パス	`ex:knows+`	`(:Person)-[:KNOWS*1..]->(:Person)`
推論付き検索	`owl:TransitiveProperty` 等を考慮	基本はサブグラフ探索
更新	`INSERT DATA { … }`	`CREATE`, `MERGE`, `SET`, `DELETE`

項目	RDF	Property Graph
相互運用	グローバル IRI と既存語彙 (FOAF, Schema.org) を再利用しやすい	アプリ内完結が多く標準語彙が少ない
推論・厳密性	OWL による論理推論と SHACL での妥当性検証	型安全は GQL で整備中／制約は実装依存
性能 (OLTP)	トリプル総数が多いと深いトラバーサルが遅くなる傾向	ノード/リレーションを直接格納し高速
開発生産性	Web API との親和性が高いが JSON 直列化は冗長になりがち	Cypher が SQL ライクで理解しやすい

目的	RDF オントロジーを使うメリット	Property Graph でのやり方
語彙統一・再利用	FOAF、Schema.org など既存語彙をURI 単位で参照できる。相互運用が高い	ラベル名の衝突を利用者側で回避。外部語彙との正式な同一視は困難
推論	RDFS/OWL による継承・制約推論がエンジンで自動実行	パターンマッチやアプリケーションコードで実装。形式推論は限定的
時間・履歴	“named graph” でバージョンを分けたり、`prov:generatedAtTime` で時刻メタを付与	エッジ／ノードのプロパティに `valid_from`, `valid_to` 等を直接保持しやすい
SHACL/Shex によるデータ整合性	W3C 標準	多くは独自 (Neo4j Constraints など)。GQL で型＋制約が策定中

ヘッドウォータース

株式会社ヘッドウォータースのテックブログです。 AIエージェント、生成AI、LLM、Azureのサービスや資格、IoT、XR系などData&AIとApp modernizeに関して幅広く投稿します！

はじめに

1. 概観 ― どちらも「グラフ」だが設計思想が違う

2. コアデータ構造

3. モデリング例（人が友人を「知っている」）

RDF (Turtle)

Property Graph (Cypher)

4. セマンティクスと推論

5. クエリ言語

6. 強みと課題

7. オントロジー／スキーマ設計の観点

8. 選択の指針

9. 互換性と最新動向

まとめ

Discussion