← → 翻页 · B 静态 · ESC 索引
本体开发 101 · 方法指南
01 / 34
NATALYA F. NOY / DEBORAH L. MCGUINNESS · STANFORD

本体开发
101

从共同词汇到可复用知识模型：把一篇经典指南转译成可执行的建模方法。
来源 · ontology101.pdf
瑞士风 · IKB · 2026.05.19
本体开发 101 · 瑞士 / IKB
02 / 34
01
为什么需要本体
02
本体由什么构成
03
七步开发流程
04
建模决策与命名纪律
前提 · 共同词汇
03 / 34

本体不是词典。
它是一个领域的
可执行共识。

形式化术语 · 关系 · 限制
本体开发 101 · 瑞士 / IKB
04 / 34
为什么开发 · 五个动机

为什么要开发本体

原文把本体的价值压缩成五个动机：共享、复用、显式化、解耦和分析。

01

共享理解

让人和软件代理对信息结构形成共同理解。

02

复用知识

已有领域模型可以导入、扩展，而不是每次从零开始。

03

显式假设

把世界假设从代码里拿出来，便于查找、解释和修改。

04

领域 / 操作解耦

同一配置算法可适配个人电脑，也可适配电梯。

05

分析领域知识

形式化术语后，才能检查一致性和可扩展性。

Σ

服务应用

本体通常不是终点，而是应用和代理的输入数据。

定义 · 本体
05 / 34
形式化
显式描述
本体 = 类 + 槽 + 限制

本体描述领域概念、概念属性，以及属性值的限制。加上个体实例以后，就构成一个知识库。

本体开发 101 · 瑞士 / IKB
06 / 34
内部结构 · 三个层次

本体的三个层次

类定义概念，槽定义属性和关系，限制定义边界；实例把抽象模型落到具体对象。

类

类 / 概念

葡萄酒、酒庄、食物这样的领域对象集合。

槽

槽 / 属性

酒体、酿造者、出品酒款等属性或对象关系。

限制

限制 / 约束

值类型、允许值、基数、范围和默认值。

本体层次关系图
本体层次关系图图示
本体开发 101 · 瑞士 / IKB
07 / 34
方法 · 七步流程

一条从范围到实例的开发线

这不是瀑布流程，而是可反复修正的知识工程循环。

七步迭代流程图
七步迭代流程图图示
01
范围
02
复用
03
术语
04
类层级
05
槽
06
限制
07
实例
迭代设计 · 修订、细化，并用应用验证
本体开发 101 · 瑞士 / IKB
08 / 34
建模前 · 三条规则

三条底层规则

它们贯穿原文所有设计建议，决定后续每一次取舍。

01

没有唯一正确模型

最佳方案取决于应用目标和预期扩展。

01
02

开发必然迭代

先粗略建模，再评估、调试、细化。

02
03

贴近领域对象

概念应贴近领域里的对象和关系，通常是名词与动词。

03
本体开发 101 · 瑞士 / IKB
09 / 34
第 01 步 / 07
01
范围
第 1 步 · 范围

先限定领域和范围

一开始要回答：覆盖什么领域、用于什么任务、回答什么问题、由谁维护。

领域
覆盖边界
只纳入应用需要的对象与关系。葡萄酒配餐不需要酒庄员工管理。
纳入什么
用途
目标任务
餐厅推荐、库存分析、自然语言处理会导向不同属性粒度。
为何存在
维护者
用户维护
维护者与使用者语言不同，就要考虑术语映射和展示名。
谁来维护
本体开发 101 · 瑞士 / IKB
10 / 34
第 01 步 / 07
01
范围
能力问题

能力问题是范围的试金石

它们不必穷尽，但必须能检验本体是否有足够信息回答真实问题。

Q01

选择葡萄酒时应考虑哪些特征？

问题直接反推必须建模的概念和属性。

Q02

波尔多是红葡萄酒还是白葡萄酒？

问题直接反推必须建模的概念和属性。

Q03

赤霞珠适合海鲜吗？

问题直接反推必须建模的概念和属性。

Q04

烤肉的最佳配酒是什么？

问题直接反推必须建模的概念和属性。

Q05

哪些特征影响与菜品的适配？

问题直接反推必须建模的概念和属性。

Q06

年份会改变香气或酒体吗？

这类问题会迫使模型纳入年份。

本体开发 101 · 瑞士 / IKB
11 / 34
第 02 步 / 07
02
复用
第 2 步 · 复用

先查已有本体，再决定从零开始

A 复用
导入 / 扩展

如果系统要与既有应用或受控词汇交互，复用几乎是要求。形式差异通常可以转换。

  • 已有领域本体库
  • 行业受控词表
  • 分类目录与标准编码
B 新建
完全新建

当没有相关模型，或教学目标要求完整演示设计过程，才从空白结构开始。

  • 保留术语列表
  • 明确建模假设
  • 记录未复用原因
本体开发 101 · 瑞士 / IKB
12 / 34
第 03 步 / 07
03
术语
第 3 步 · 术语

先枚举术语，不急着分类

这一页故意把术语摊开：不要先判断类、槽或实例。

葡萄酒01
葡萄02
酒庄03
产地04
颜色05
酒体06
风味07
甜度08
鱼类09
红肉10
白葡萄酒11
年份12
12

术语表越完整，后续层级和属性设计越少遗漏。

本体开发 101 · 瑞士 / IKB
13 / 34
第 04 步 / 07
04
类
第 4 步 · 类层级

三种建类路径

没有一种路径天然更好，关键是让层级服务应用目标。

01 自上而下
从一般到具体

先定义葡萄酒、食物，再向下分红葡萄酒、白葡萄酒、西拉。

  • 适合系统性视角
  • 容易形成清晰上位概念
  • 风险是过早抽象
02 自下而上 / 组合
从样例到中层

从波亚克、玛歌这类叶子开始，归并到梅多克、波尔多；或先抓最显著概念。

  • 贴近专家直觉
  • 中层概念通常最有描述力
  • 风险是层级不均
本体开发 101 · 瑞士 / IKB
14 / 34
第 04 步 / 07
04
类
类层级测试

只问：是不是一种？

如果 B 是 A 的子类，那么 B 的每个实例也必须是 A 的实例。

种类关系层级测试图
种类关系层级测试图图示
传递关系 · 每个波亚克也都是葡萄酒
本体开发 101 · 瑞士 / IKB
15 / 34
第 05 步 / 07
05
槽
第 5 步 · 槽

槽让类拥有内部结构

类本身不足以回答能力问题；属性和关系必须附着在最一般且正确的类上。

01

内在属性

味道、酒体等对象内在属性。

02

外在描述

名称、产地等外在描述。

03

组成部分

餐食的菜品等整体-部分结构。

04

对象关系

酿造者、葡萄品种等个体之间的关系。

05

继承属性

葡萄酒的槽会被红葡萄酒、白葡萄酒继承。

06

挂在上层

把酒体和颜色放在葡萄酒，而不是每个子类。

本体开发 101 · 瑞士 / IKB
16 / 34
第 06 步 / 07
06
限制
第 6 步 · 限制

限制定义槽的边界

它决定一个槽能填什么、填几个、从哪个类中取值。

限制边界图
限制边界图图示
名称
文本
槽值类型
价格
数字
槽值类型
是否起泡
布尔
槽值类型
出品酒款
实例
槽值类型
本体开发 101 · 瑞士 / IKB
17 / 34
第 06 步 / 07
06
限制
基数 / 值域 / 定义域 / 默认值
— 01

基数

单值、多值、最小值、最大值。

— 02

值类型

文本、数字、布尔、枚举、实例。

— 03

定义域 / 值域

定义域是槽描述的类；值域是可作为槽值的类。

— 04

默认值

方便录入，不是不可变约束。

本体开发 101 · 瑞士 / IKB
18 / 34
第 06 步 / 07
06
限制
范围规则

范围：一般但不过宽

用父类覆盖合理子类，但不要把任何对象都放进来。

不佳 过宽
任意事物

把“出品”的范围设成最泛的“任意事物”，会让任何对象都可能成为填充值。

  • 约束失效
  • 验证能力下降
  • 语义过度松散
较好 足够一般
葡萄酒

用“葡萄酒”覆盖红葡萄酒、白葡萄酒、桃红葡萄酒的所有子类，不重复列举。

  • 删掉被父类覆盖的子类
  • 若覆盖全部子类，改用父类
  • 保留真实可填对象边界
本体开发 101 · 瑞士 / IKB
19 / 34
第 07 步 / 07
07
实例
第 7 步 · 实例

实例把模型落到具体对象

创建实例需要选择类、创建个体、填入槽值。

类
博若莱
先选择最合适的类作为归属。
实例
摩贡酒庄酒款
具体酒款成为知识库中的个体。
槽值
轻盈 / 红色 / 干型
填入酒体、颜色、风味、葡萄、酿造者等槽值。
本体开发 101 · 瑞士 / IKB
20 / 34
层级质量

类层级的四个错误信号

01循环继承

A 是 B 的子类，同时 B 又是 A 的子类。

02单复数混用

“葡萄酒”不应成为“葡萄酒们”的子类。

03同层不一致

“白葡萄酒”与“霞多丽”不该作为同级类。

04只有一个子类

只有一个直接子类，通常意味着模型不完整或无增量。

本体开发 101 · 瑞士 / IKB
21 / 34
2—12
健康同层类

许多结构良好的本体，每个类有两个到十几个直接子类。

1
单子类警报

如果只有一个子类，先问它是否真的增加信息。

12+
中间层警报

如果直接子类超过十几个，通常需要引入自然中间类。

0
人工分类

如果领域现实中没有自然分类，就不要为了整齐硬造类。

本体开发 101 · 瑞士 / IKB
22 / 34
何时建类

什么时候应该新建一个类

经验规则
有新增语义，才新增类。
01

新增属性

子类拥有父类没有的槽。

02

不同限制

继承槽的限制或固定值不同。

03

不同关系

它参与父类不参与的关系。

本体开发 101 · 瑞士 / IKB
23 / 34
类还是槽值

“白葡萄酒”是类，还是“颜色”的值？

槽值 影响较低
仅作描述

如果颜色对应用规则没有特殊影响，只是标签打印或展示字段，就用属性值。

  • 模型更扁平
  • 减少无意义类
  • 适合低粒度任务
类 影响较高
成为对象种类

如果不同颜色对应不同配餐规则、属性和关系，就建成不同类。

  • 影响其他槽的限制
  • 领域专家视作不同种类
  • 实例归属不应频繁变化
本体开发 101 · 瑞士 / IKB
24 / 34
类还是实例

类与实例的边界，由应用粒度决定

01

能力问题的最具体答案，通常是实例。

02

如果术语形成自然层级，它们应成为类。

03

如果需要记录每个年份，酒款可能变成类，年份成为实例。

04

如果做库存管理，单瓶酒也可能是实例。

类与实例边界图
类与实例边界图图示
范围纪律
25 / 34
限制模型范围
不要把整个世界
塞进本体。

只比应用多建模一点点：最多向上或向下额外一层。无关属性会污染实例，增加维护负担。

范围本身就是设计约束。
本体开发 101 · 瑞士 / IKB
26 / 34
互斥 / 反向 / 默认 / 命名
— 01

互斥类

声明互斥类，可帮助系统发现错误多重归属。

— 02

反向槽

“酿造者”与“出品”可互相推导，减少不一致。

— 03

默认值

默认值只是录入便利，不是不可变槽值。

— 04

命名规范

命名规范是最低成本的建模质量控制。

本体开发 101 · 瑞士 / IKB
27 / 34
反向槽

双向关系，只维护一次事实

葡萄酒 酿造者
梅洛酒款

只录入“这款酒由星岭酒庄酿造”。

  • 正向录入
  • 用户视角自然
  • 减少重复劳动
一次录入
⇄

系统根据反向槽，自动维护另一侧事实。

酒庄 出品
星岭酒庄

“出品酒款”列表自动加入梅洛酒款，保持知识库一致。

  • 反向推导
  • 一致性校验
  • 双入口知识采集
本体开发 101 · 瑞士 / IKB
28 / 34
命名规范

命名规范能直接防错

原文最后单独讲命名，因为命名会影响可读性、工具互操作和建模误差。

01

类名大写，槽名小写

如“葡萄酒 / 酿造者”

02

单复数保持一致

不要同时建“葡萄酒”和“葡萄酒们”

03

多词分隔固定

多词术语只选一种写法并坚持使用

04

少用缩写

完整名称优于内部简称

05

不要加“类”后缀

上下文已经说明它是类或槽

06

兄弟类命名对齐

红葡萄酒 / 白葡萄酒，而不是红葡萄酒 / 白色

本体开发 101 · 瑞士 / IKB
29 / 34
质量规格 · 本体开发 101
一份可用本体的
验收规格
本体质量验收图
本体质量验收图图示
范围
01

回答能力问题，不吞并无关世界。

结构
02

类层级满足“是一种”，同层类粒度一致。

约束
03

槽的定义域、值域、基数不松不紧。

质量只能通过目标应用中的使用效果来评估；也就是“能否在实际使用中证明自己”。

创作过程
30 / 34
没有单一
正确本体
质量要在使用中证明

两个设计者会做出不同模型。应用目标、领域理解、扩展预期，都会影响最终结构。

本体开发 101 · 瑞士 / IKB
31 / 34
操作手册 · 检查清单

建模前后各检查一次

把原文建议变成可执行检查项。

能力问题01
复用扫描02
术语清单03
种类关系测试04
同层类检查05
槽附着点06
定义域 / 值域07
基数08
默认值09
反向槽10
命名规范11
范围裁剪12
12

每一项都对应原文中的一个常见错误或设计取舍。

转译 · 面向现代团队
32 / 34
把领域知识
从人的脑子
搬到机器
能检查的结构里。

今天的智能代理、搜索、推荐、企业知识库，仍然会遇到同一个问题：术语不统一，关系不显式，假设藏在实现里。

最后一页
33 / 34
本体开发 101
先约定世界，
再自动化世界。

本体开发的本质不是画树，而是让某个领域的对象、关系和限制足够明确，能够被共享、复用、分析和执行。

共享 · 复用 · 分析
Noy 与 McGuinness
34 / 34
收束
结论

先建模领域，
再用应用验证。

本体的质量不在图上，而在它能不能支撑应用回答正确问题。
本体开发 101 · 瑞士 IKB
2026.05.19
三条规则
结束
01

从问题开始

能力问题决定范围。

02

用“是一种”测试层级

每个子类实例都必须也是父类实例。

03

让应用检验模型

最终质量由目标应用中的使用效果决定。

→ 完 · 方法札记结束