属性图与 RDF 的对比与选型
一、属性图模型：节点与边上的键值对
在属性图（Property Graph）模型中，图由节点（Vertex）和边（Edge）组成，且：
- 节点有唯一标识、可选的标签（Label）（表示类型，如 Person、City）、以及若干属性（Property）——键值对，如 name="爱因斯坦", birthYear=1879。
- 边有唯一标识、类型（Type）（如 CREATED、WORKS_AT）、起点与终点节点、以及可选的属性，如 year=1905, confidence=0.95。
与 RDF 的直观区别：RDF 里「边的类型」用谓词 IRI 表示，「节点/边的附加信息」要再拆成多条三元组（例如 (ex:Einstein, ex:birthYear, "1879")）；属性图里一条边本身就可以带多个键值对，无需为每个属性再建一条「边」。属性图允许同一对节点之间有多条同类型或不同类型的边（多重边），每条边有独立 id 和属性。
二、Neo4j 与 TinkerPop
Neo4j 是当前最流行的原生图数据库之一，采用属性图模型。其查询语言 Cypher 用 ASCII 艺术式的模式描述「节点–边–节点」：例如 (a:Person)-[:CREATED]->(b:Concept) 表示「a 是 Person，经 CREATED 边指向 b 是 Concept」。Cypher 语法对程序员友好，支持模式匹配、聚合、路径查询与图算法扩展（如最短路径、PageRank）。Neo4j 提供社区版与企业版，以及 Aura 云服务。
Apache TinkerPop 是图计算框架的抽象层：定义图的结构（节点、边、属性）与遍历 API（Gremlin），不绑定某一家存储。Gremlin 是面向遍历的语言：从某节点出发，一步步「沿出边」「过滤」「取属性」，形成管道式查询。Neo4j、JanusGraph、Amazon Neptune 等都可以通过 TinkerPop 的适配器用 Gremlin 查询。选择「Neo4j + Cypher」还是「TinkerPop + Gremlin + 某后端」取决于是否需要多后端可移植、以及团队对哪种语法更熟。
Neo4j · Cypher
- 属性图原生；Cypher 模式可读性强
- 图算法库（GDS）、可视化与生态成熟
- 单机与分布式（Fabric）部署
TinkerPop · Gremlin
- 抽象 API，可换后端（Neo4j、JanusGraph、Neptune 等）
- 遍历式思维：从起点沿边、过滤、聚合
- 适合需要「同一套代码多存储」的场景
三、RDF 与属性图：表达力、查询、生态对比
两者都能表示「实体 + 关系」的图，但侧重点不同。
表达力：属性图在边与节点上直接挂属性，多值、复杂结构（如边上的时间区间、权重）建模自然；RDF 用三元组表达一切，边上不能直接挂属性，需引入中间节点或重复主体–谓词。反过来，RDF 的全局 IRI、标准本体、推理在跨源融合与语义互操作上更强；属性图更偏「单图、应用内」的灵活建模。
查询：Cypher 的模式写法直观，适合「从模式到结果」的思维；SPARQL 基于图模式与变量绑定，对「多源联邦、语义约束、可选路径」更统一。图算法（最短路径、中心性、社区发现）在属性图栈中往往有现成集成（如 Neo4j GDS），RDF 栈则多依赖外部图计算或自建。
生态：RDF 有 W3C 标准、关联数据、Wikidata/DBpedia、大量本体与推理机；属性图有 Neo4j、Amazon Neptune、Azure Cosmos DB 等产品与云服务，以及 TinkerPop 的跨后端生态。若要做「与开放知识库对齐、多源 RDF 融合」，RDF 更顺；若要做「业务图、图算法、快速上线」，属性图往往更顺手。
| 维度 | RDF / 三元组 | 属性图 |
|---|---|---|
| 表达 | 三元组；边无属性，需拆成三元组或中间节点；IRI 全局唯一，本体与推理标准完善 | 节点与边均可挂键值对；边上属性自然；多用于单图、应用内 |
| 查询 | SPARQL；图模式、联邦、可选路径；推理与规则 | Cypher / Gremlin；模式匹配与遍历；图算法集成常见 |
| 生态 | W3C、关联数据、开放 KG、推理机 | Neo4j、Neptune、Cosmos DB、TinkerPop |
| 典型场景 | 多源融合、语义互操作、开放数据、推理 | 业务图、推荐、风控、图算法、快速建模 |
四、选型考量
没有「谁更好」的绝对结论，只有「更符合当前需求」的选择。可从下面几条线索考虑。
- 多源融合、标准与互操作：要与 Wikidata、DBpedia、行业 RDF 数据集对齐或联邦查询，选 RDF 栈（三元组存储 + SPARQL）更顺；IRI 与本体有助于统一语义。
- 开发效率与产品成熟度：团队更熟悉图数据库与 Cypher、希望快速上线业务图（推荐、风控、关系追溯），属性图与 Neo4j 等产品往往上手更快、文档与案例多。
- 图算法与图计算：若核心需求是最短路径、PageRank、社区发现等，且希望与存储紧耦合，属性图栈（Neo4j GDS、TinkerPop 后端）集成度更高；RDF 栈可外接图计算引擎或导出为图再算。
- 推理与语义：若需要 OWL 推理、规则引擎、类型约束与一致性检查，RDF 栈有成熟推理机与标准；属性图侧多靠应用层或图模式实现类似效果。
- 混合与转换：不少项目会「内部用属性图存储与查询，对外或与开放数据对接时转成 RDF」；或「核心用 RDF，热点子图导出到图库做算法」。两者可以并存，通过 ETL 或视图做转换。
一句话： 属性图的节点与边都可带标签与键值对，边上属性建模自然；Neo4j + Cypher 与 TinkerPop + Gremlin 是主流实现与 API。RDF 用三元组与 IRI 统一表示，标准与推理强、适合多源与语义；属性图适合业务图与图算法、开发效率高。选型时看多源/标准/推理倾向 RDF，看图算法/快速落地倾向属性图，也可混合或做格式转换。
MATCH (a)-[r]->(b) RETURN a,r,b；想对比 RDF，可在同一语义下用 Turtle 写几条三元组，体会「边无属性、需拆成三元组」的差异。
五、小结
属性图模型：节点与边均有唯一 id、标签/类型与键值对属性；边上可直接挂属性，无需像 RDF 那样拆成多条三元组。Neo4j 采用属性图与 Cypher；TinkerPop 提供图抽象与 Gremlin 遍历，可接多种后端。与 RDF 对比：RDF 强在标准、IRI、多源融合与推理；属性图强在边上属性、图算法集成与开发效率。选型依多源/标准/推理选 RDF，依图算法/快速落地选属性图，或混合与转换。下一章进入本体与分类：从 Taxonomy 到 Ontology，为知识图谱赋予共享语义与约束。