本体工程：知识图谱的Schema设计

本体（Ontology）是知识图谱的骨架，决定了图谱能表达什么知识、回答什么问题。本文从本体基本概念出发，介绍OWL/RDF标准、设计方法论和常见模式，帮助实践者设计出高质量的知识图谱Schema。

一、本体基础概念

1.1 什么是本体

本体 = 对某个领域中概念及其关系的形式化表达

类比理解：
  数据库Schema ≈ 定义表结构（列名、类型、约束）
  本体Schema   ≈ 定义概念结构（类、属性、关系、推理规则）

关键区别：
  数据库Schema: 描述数据"长什么样"（结构）
  本体:         描述世界"是什么样"（语义）

本体的核心要素：
├── 类（Class）：概念的集合（如"人"、"公司"）
├── 属性（Property）：类的特征
│   ├── 数据属性（Datatype Property）：值为字面量（名称、年龄）
│   └── 对象属性（Object Property）：值为另一个实体（工作于、隶属于）
├── 实例（Instance）：类的具体个体（"张三"是"人"的实例）
├── 关系（Relation）：类/实例间的语义连接
└── 公理（Axiom）：约束和推理规则

1.2 本体的表达层次

层次	名称	表达能力	工具/标准	示例
L1	受控词汇表	术语列表	SKOS	主题词表
L2	分类法	层次分类	简单分类	产品分类树
L3	关系网络	多种关系	RDF/RDFS	知识图谱
L4	全本体	推理规则	OWL	语义网
L5	逻辑理论	一阶逻辑	FOL	学术研究

实践建议：大多数企业知识图谱在L3（关系网络）层次就足够，只有需要自动推理时才需要L4。

二、标准与技术

2.1 RDF（Resource Description Framework）

RDF核心: 一切知识用三元组表达

三元组: (主语, 谓语, 宾语) = (Subject, Predicate, Object)

示例:
  (张三, 工作于, 华为)     → (:张三)-[:工作于]->(:华为)
  (张三, 年龄, 35)        → :张三 的 年龄属性=35
  (华为, 类型, 公司)       → :华为 是 :公司 的实例
  (华为, 总部在, 深圳)     → (:华为)-[:总部在]->(:深圳)

RDF序列化格式:
├── Turtle (.ttl) - 最易读
├── N-Triples (.nt) - 最简单
├── RDF/XML (.rdf) - 最早的格式
├── JSON-LD (.jsonld) - Web友好
└── N-Quads (.nq) - 支持命名图

Turtle格式示例：

@prefix ex: <http://example.org/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# 定义类
ex:Person rdf:type rdfs:Class .
ex:Company rdf:type rdfs:Class .

# 定义属性
ex:worksAt rdf:type rdf:Property ;
    rdfs:domain ex:Person ;
    rdfs:range ex:Company .

ex:age rdf:type rdf:Property ;
    rdfs:domain ex:Person ;
    rdfs:range xsd:integer .

# 创建实例
ex:zhangsan rdf:type ex:Person ;
    ex:name "张三" ;
    ex:age 35 ;
    ex:worksAt ex:huawei .

ex:huawei rdf:type ex:Company ;
    ex:name "华为技术有限公司" ;
    ex:headquarteredIn ex:shenzhen .

2.2 RDFS（RDF Schema）

RDFS在RDF基础上增加:
├── rdfs:Class - 定义类
├── rdfs:subClassOf - 类的继承
├── rdfs:domain - 属性的定义域
├── rdfs:range - 属性的值域
├── rdfs:label - 人类可读标签
└── rdfs:comment - 描述信息

示例:
  ex:Employee rdfs:subClassOf ex:Person .
  ex:Manager rdfs:subClassOf ex:Employee .

  推理: 如果 张三 rdf:type ex:Manager
  则自动推出: 张三 rdf:type ex:Employee
  且自动推出: 张三 rdf:type ex:Person

2.3 OWL（Web Ontology Language）

OWL在RDFS基础上增加更强的表达和推理能力:

类的构造:
├── owl:unionOf - 联合类（A或B）
├── owl:intersectionOf - 交集类（A且B）
├── owl:complementOf - 补集类（非A）
├── owl:equivalentClass - 等价类
└── owl:disjointWith - 互斥类

属性约束:
├── owl:FunctionalProperty - 函数属性（最多一个值）
├── owl:InverseFunctionalProperty - 反函数属性
├── owl:TransitiveProperty - 传递属性
├── owl:SymmetricProperty - 对称属性
├── owl:inverseOf - 逆属性
├── owl:cardinality - 基数约束
└── owl:allValuesFrom / owl:someValuesFrom - 值约束

OWL子语言（按表达力递增）:
├── OWL Lite - 最简单，分类层次+简单约束
├── OWL DL - 描述逻辑，平衡表达力与可判定性
└── OWL Full - 完整表达力，但推理可能不可判定

OWL实际示例：

@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix ex: <http://example.org/> .

# 函数属性：每个人只有一个身份证号
ex:idNumber rdf:type owl:FunctionalProperty, owl:DatatypeProperty ;
    rdfs:domain ex:Person ;
    rdfs:range xsd:string .

# 反函数属性：每个身份证号唯一标识一个人
ex:idNumber rdf:type owl:InverseFunctionalProperty .

# 对称属性：如果A认识B，则B认识A
ex:knows rdf:type owl:SymmetricProperty .

# 传递属性：如果A是B的上级，B是C的上级，则A是C的上级
ex:supervises rdf:type owl:TransitiveProperty .

# 逆属性：雇佣 和 受雇于 互为逆属性
ex:employs owl:inverseOf ex:employedBy .

# 互斥类：男性和女性互斥
ex:Male owl:disjointWith ex:Female .

# 基数约束：每个部门至少有1个经理
ex:Department rdfs:subClassOf [
    rdf:type owl:Restriction ;
    owl:onProperty ex:hasManager ;
    owl:minCardinality "1"^^xsd:nonNegativeInteger
] .

三、本体设计方法论

3.1 设计流程

本体设计七步法（Noy & McGuinness 改良版）：

Step 1: 明确目的与范围
├── 这个本体要回答什么问题？
├── 谁是主要用户？
├── 本体的边界在哪里？
└── 输出: 能力问题清单（Competency Questions）

Step 2: 复用已有本体
├── 搜索已有本体（LOV、BioPortal等）
├── 评估可复用性（覆盖度、质量、许可）
├── 决定复用策略（直接引用/扩展/映射）
└── 输出: 可复用本体列表

Step 3: 枚举关键概念
├── 领域专家头脑风暴
├── 从文档/数据库中提取候选概念
├── 不分层次，先求全面
└── 输出: 概念候选列表

Step 4: 定义类层次
├── 自顶向下：从通用到具体
├── 自底向上：从实例到抽象
├── 中间结合法（推荐）
├── 注意is-a关系的正确性
└── 输出: 类层次结构图

Step 5: 定义属性
├── 每个类需要什么数据属性
├── 属性的数据类型和约束
├── 属性的继承关系
└── 输出: 属性定义表

Step 6: 定义关系
├── 类与类之间的对象属性
├── 关系的方向和基数
├── 关系的约束（域/值域/基数）
└── 输出: 关系定义表

Step 7: 验证与迭代
├── 用能力问题验证本体
├── 导入样本数据测试
├── 领域专家评审
├── 迭代改进
└── 输出: 验证报告 + 最终本体

3.2 能力问题（Competency Questions）

CQ定义: 本体应该能回答的问题列表

示例（电商领域）:
CQ1: 某个产品属于哪个类别？
CQ2: 某个类别下有哪些子类别？
CQ3: 某个产品有哪些可选配件？
CQ4: 某个客户购买了哪些产品？
CQ5: 哪些产品适用15天退货政策？
CQ6: 某个产品的常见故障及解决方案是什么？
CQ7: 哪些产品与某产品经常一起购买？

验证方法:
  对每个CQ，构造相应的SPARQL/Cypher查询
  如果无法构造查询 → 本体缺少必要的类/属性/关系
  如果查询无结果 → 实例数据不足或建模有误

四、常见设计模式

4.1 时间模式

模式1: 属性带时间戳
  (张三)-[:WORKS_AT {from: 2020, to: 2025}]->(华为)
  简单但查询复杂

模式2: 事件节点（推荐）
  (张三)-[:HAD_EMPLOYMENT]->(就职事件)
  (就职事件)-[:AT]->(华为)
  (就职事件) {startDate: 2020, endDate: 2025}
  灵活，可扩展

模式3: 时间切片
  (张三_2020)-[:WORKS_AT]->(华为)
  (张三_2025)-[:WORKS_AT]->(腾讯)
  (张三_2020)-[:SAME_AS]->(张三)
  适合时态推理，但节点膨胀

4.2 角色模式

问题: 一个人可以同时是员工、客户、供应商

方案A: 多标签
  (:Person:Employee:Customer {name: "张三"})
  简单但角色属性混在一起

方案B: 角色节点（推荐）
  (张三:Person)-[:HAS_ROLE]->(r1:EmployeeRole {department: "研发"})
  (张三:Person)-[:HAS_ROLE]->(r2:CustomerRole {tier: "VIP"})
  清晰分离，可独立管理

方案C: 上下文图
  在不同命名图中表达不同角色
  最灵活但实现复杂

4.3 量化模式

问题: 如何表达 "张三买了3个苹果，每个5元"

方案: 中间节点（推荐）
  (张三)-[:PLACED]->(订单1:Order)
  (订单1)-[:CONTAINS]->(行项1:OrderLine {quantity: 3, unitPrice: 5})
  (行项1)-[:ITEM]->(苹果:Product)

4.4 层次分类模式

产品分类层次:
  (电子产品:Category)
    └──[:SUB_CATEGORY]──(手机:Category)
      └──[:SUB_CATEGORY]──(智能手机:Category)
        └──[:SUB_CATEGORY]──(旗舰手机:Category)

查询: 某个类别及其所有子类别下的产品
  MATCH (c:Category {name: "电子产品"})
        -[:SUB_CATEGORY*0..]->(sub:Category)
        <-[:BELONGS_TO]-(p:Product)
  RETURN p.name, sub.name AS category

五、工具与平台

5.1 本体编辑工具

工具	类型	优势	适用场景
Protege	桌面应用	功能最全、学术标准	OWL本体设计
WebVOWL	Web可视化	直观展示本体结构	沟通与展示
TopBraid	企业级	协作+数据管理	大型企业
draw.io	通用绘图	简单灵活	快速草图
LLM辅助	AI工具	快速生成初稿	概念探索

5.2 知名复用本体

本体	领域	规模	许可
Schema.org	通用/Web	800+类型	Creative Commons
Dublin Core	文档元数据	15个核心元素	开放
FOAF	社交网络	~20个类	开放
FIBO	金融	1000+概念	EDM Council
SNOMED CT	医学	35万+概念	需授权
Wikidata	百科	1亿+实体	CC0

六、实践建议

6.1 设计原则

本体设计十条原则：

1. 目的驱动: 没有通用完美本体，只有适合场景的本体
2. 最小可行: 先设计核心概念，逐步扩展
3. 复用优先: 不要重新发明轮子
4. 避免过度建模: 不需要的概念不要建模
5. 命名一致: 统一命名规范（CamelCase/snake_case）
6. 文档化: 每个类/属性/关系都要有描述
7. 验证驱动: 用能力问题验证设计
8. 版本管理: 本体也需要版本控制
9. 协作设计: 领域专家+知识工程师共同参与
10. 迭代演化: 本体不是一次性产出，需要持续演化

6.2 常见错误

错误	问题	修正
is-a误用	"轮胎 is-a 汽车"	"轮胎 part-of 汽车"
类vs实例混淆	"iPhone 16"设为类	"iPhone 16"是"手机"类的实例
过度继承	深达10层的类层次	扁平化，3-5层即可
属性泛滥	一个类50个属性	拆分为子类或关联节点
忽视逆关系	只有"雇佣"没有"受雇于"	定义逆关系

本体设计是知识工程的核心技能。好的本体既能忠实反映领域知识，又能高效支撑查询和推理。关键在于平衡表达力与复杂度，从业务问题出发，迭代完善。

---

Maurice | maurice_wen@proton.me