本体与 Schema 设计：图的"数据字典

本文基于模型知识整理（生成时未联网核对），关键结论建议对照经典文献复核。

一句话定义

本体（ontology）定义知识图谱的词汇表与约束——有哪些实体类型、关系类型、属性及层级规则；schema 设计决定图能不能查、会不会退化成"什么都连一切的毛线球"，是从业务问题倒推的建模决策而非技术装饰。

为什么重要

同样一批文档，schema 好的图一条查询出答案；schema 差的图实体爆炸、关系歧义、查询无从下手。图构建失败的项目多数败在 schema：抽取器照着糟糕的 schema 生成高质量垃圾。先定 schema 再抽数据，是图谱工程与传统建库一致的铁律。

前置知识

kp-018（三元组）。

核心概念

• 实体类型（node label）：Person、Organization、Product、Policy、Event……类型即查询的锚点。
• 关系类型（edge type）：语义要单义、方向要明确："SUPPLIES_TO"优于模糊的"关联"；常用大写蛇形命名。
• 属性约束：每个类型的关键属性、必填性、数据类型、时间戳。
• 层级与继承：类型树（Company ⊂ Organization）支持泛化查询，但层级过深徒增复杂度——一般 ≤3 层。
• 复用现成本体：schema.org、FOAF、SKOS 等通用本体可复用词汇，企业内部再扩展私有类型。

原理与机制

从问题倒推 schema（核心方法）：列出系统要回答的 top 20 问题 → 圈出其中的实体与关系 → 形成最小 schema → 用真实问题走查（"这条查询在 schema 上走得通吗"）。反模式是从文档出发"把看到的全建进去"，结果 200 种关系类型、90% 只有一条边。

命名与规范化的坑：

• 实体歧义："苹果"是水果还是公司 → 需要类型 + 消歧标识（kp-023 的实体对齐）。
• 关系粒度："ACQUIRES"（收购）与"INVESTS_IN"（投资参股）要不要合并？取决于业务是否区分控制权——schema 是业务决策。
• 属性 vs 节点：地址是 Person 的属性还是 Address 节点？当地址需要被查询（"在杭州的所有高管"）或复用（多人同址）时必须升格为节点。判据："它会被当查询目标吗？"
• 时态建模：关系随时间变化（任职、持股），要么边带 valid_from/valid_to 属性，要么把"任职事件"建为节点（reified node）——不建模时间的历史查询会答错。

图示

(:Company {name, founded})  ←节点类型+属性
   ──[:SUPPLIES {since, share}]──►  (:Company)
   ──[:OWNS {since}]──────────────► (:Subsidiary ⊂ Company)
(:Person)──[:CEO_OF {from, to}]──►(:Company)
规则: 关系名大写蛇形+方向单义; 时变关系必须带时间属性

实例或案例

• 供应链 KG schema：实体 6 类（公司/物料/产品/工厂/地区/证书）、关系 9 种（供应/生产/位于/认证…）——支持"断供影响面"等全部核心问题，关系类型超过 15 种往往是过度设计的信号。
• 客服知识 KG：产品—版本—故障—解决方案，schema 里给"故障"类型挂"症状关键词"属性，兼容向量检索入口（kp-026 混合架构）。

常见误区

• 误区一："schema 一开始就要完美"。迭代是常态，但必须先有 v1 再抽取；零 schema 的"自由抽取"产出的图几乎不可查询。
• 误区二："关系类型越多越精细越好"。类型爆炸让抽取器无所适从、查询者记不住词汇表；每新增一种类型都要问"哪个核心问题需要它"。
• 误区三："属性和节点随便选"。把需要查询/共享的对象藏进属性（如把公司塞进 Person 的 company 字符串属性），会让后续多跳查询无法表达。

与其他知识点的关系

• kp-018：本体约束三元组集合。
• kp-023：抽取按 schema 进行，LLM 抽取 prompt 即 schema 的翻译。
• kp-025：图查询语言按 schema 写 pattern。

自测题

1. schema 设计的第一步为什么是"列问题"而不是"列实体"？

答：schema 服务于查询；从 top 问题倒推出的类型与关系才有存在依据，从文档顺推会积累大量无查询价值的类型。

1. 什么时候把属性升格为节点？

答：当它需要作为查询目标（按它过滤/聚合）或被多个实体共享复用时（地址、公司、类别）。

1. 时变关系（任职/持股）不建模时间会怎样？

答：新旧事实互相覆盖或并存冲突，"现任/曾任/某年时"类查询必然答错；必须带有效时间属性或事件化建模。

延伸阅读

• Hogan 等, "Knowledge Graphs"（2021）§ 本体设计。
• W3C SKOS / schema.org 文档（可复用词汇表）。
• Neo4j 官方建模指南（graph data modeling）。