Schema 设计：实体类型与关系类型

第 10 章 · 知识图谱

有了 RDFS/OWL 的语法，还要回答： 画哪些类、哪些关系、怎么命名、怎么保证数据符合 Schema。Schema 设计决定了图谱是否好查、好扩展、好与上下游对齐。类划得太细会碎片化、太粗会丢失语义；关系命名不清会导致融合时对不上；不校验一致性，脏数据会悄悄破坏推理与查询。本章讲类型体系设计原则、实体类型的划分与层次、关系类型的命名与定义域/值域，以及Schema 与数据的一致性如何保障与迭代。

一、类型体系设计原则

设计实体类型（Class）体系时，可遵循几条原则，在「表达力」与「可维护性」之间取得平衡。

适度抽象

类不宜过多过细（每个实体一个类会碎片化），也不宜过少过粗（「万物皆 Thing」无法支撑查询与约束）。按业务可区分、可查询、可复用的粒度划分，通常 2～4 层子类足够。

无重叠、无遗漏

同层子类之间尽量互斥（一个实体不应同时属于两个语义重叠的类）；覆盖上尽量完整（业务中出现的实体都能归入某类）。若允许多分类，需在文档中说明用途。

可扩展

为后续新增类型留空间：命名空间统一、层次上预留「其他」或领域子类入口；避免把业务枚举直接压平成类名，导致每加一个枚举就改 Schema。

与业务对齐

类与关系要对应业务术语与流程，便于领域专家参与评审；若与已有标准或行业本体（如 FIBO、SNOMED 片段）对齐，可注明映射关系，利于融合。

Schema 设计原则：适度抽象、无重叠无遗漏、可扩展、与业务对齐

二、实体类型（Class）的划分与层次

实体类型对应「图中节点属于哪一类」。划分时通常先确定顶层（如 Thing、Agent、Event、Place、Concept），再按领域逐层细化。

顶层类：可与上层本体对齐，如 Agent（人、组织）、PhysicalObject、AbstractConcept、Event、Time 等。
领域子类：在顶层下扩展，如 Agent → Person、Organization；Person → Scientist、Politician（若业务需要区分）；Place → City、Country。
单继承 vs 多分类：RDFS/OWL 允许一个实体有多个 rdf:type（多分类），例如某人既是 Person 又是 Scientist。单继承层次便于推理与展示；多分类更灵活，但需约定「主类型」与「角色类型」的用法，避免查询时歧义。
层次深度：一般 2～4 层即可；过深会增加维护成本，且子类间差异可能更适合用「关系 + 属性」表达而非继续拆类。

实体类型层次：Thing → Agent/Place/Concept → Person/Organization/Scientist 等

三、关系类型（Property）的命名与定义域/值域

关系类型的命名应一致、无歧义、可读。常见约定：用动词或动词短语（created、locatedIn、worksFor）；同一命名空间内避免近义词混用（若用 created 就不要再加 createdBy 作为另一属性名，而用 inverseOf 表达）；命名与领域术语一致，便于文档与对齐。

定义域（domain）与值域（range）声明「谁可以有这条关系、指向什么」。domain/range 可设为单个类或多个类的并；过严会排斥合理数据，过松则失去约束意义。通常用「主要」的类作为 domain/range，若有例外可在文档中说明，或用 OWL 的并/交表达。关系类型也建议分层：顶层通用关系（如 partOf、locatedIn）与领域专用关系（如 prescribedFor、compliesWith）分开管理，便于复用与扩展。

推荐：created、birthPlace、worksFor、locatedIn — 动词或动词短语，一致风格。
避免：create、creator、is_created_by 混用；或 relation1、prop_2 等无语义命名。

关系类型：为 created、locatedIn 等声明 domain 与 range

四、Schema 与数据的一致性

Schema 一旦发布，数据应符合其约束，否则推理与查询会得到意外结果。一致性保障可从以下几方面入手。

类型检查：每个实体应有至少一个 rdf:type 指向 Schema 中的类；可定期扫描「无类型」或「类型不在 Schema 中」的节点。
domain/range 校验：对每条三元组检查：主体是否属于该属性 domain 的类（或其子类）、客体是否属于 range 的类或为合规字面量。违反者可打标、告警或阻止入库。
推理与约束：若使用 OWL，推理机可发现「不可满足」的类、矛盾的公理；也可用 SHACL 等做形状约束（Shapes Constraint Language），对图做更细的校验。
迭代演进：Schema 会随业务变化；变更时需版本化、留变更记录，并对历史数据做迁移或兼容策略（如新类、新属性逐步填充，旧数据分批校验）。

数据写入 / 导入 → 类型检查 → domain/range 校验 → 推理（可选） → 一致性报告

一致性保障流程：从写入到校验、推理与报告

Schema、数据与校验的闭环：不一致时反馈到数据或 Schema 迭代

一句话： 类型体系设计遵循适度抽象、无重叠无遗漏、可扩展、与业务对齐。实体类型按顶层→领域→子类划分，2～4 层为宜；可单继承或多分类，需约定清晰。关系类型命名一致、无歧义，并声明 domain/range 便于校验与推理。一致性通过类型检查、domain/range 校验、推理与 SHACL 等保障，Schema 与数据需迭代演进并形成闭环。

实践： 为当前项目列一张「类清单」和「关系清单」，每项注明 domain/range 与用途；再抽一小份数据做一致性扫描（无类型节点、违反 domain/range 的三元组），据此迭代 Schema 或清洗数据。

五、小结

类型体系设计原则：适度抽象、无重叠无遗漏、可扩展、与业务对齐。实体类型从顶层类到领域子类分层，单继承或多分类需约定；层次深度 2～4 层常见。关系类型命名规范、声明 domain/range，便于校验与复用。Schema 与数据一致性依赖类型检查、domain/range 校验、推理与约束（如 SHACL），并随业务迭代 Schema、形成校验闭环。下一章讲身份与 URI 设计、命名空间，把实体的全局唯一标识与持久化策略说清楚。