方法论精读 · Methodology

本体开发 101：
先提炼，再拿去用

Noy 与 McGuinness 这份指南只有 25 页（斯坦福，2001 年）。它讲清了本体为何而作、里面装什么、动手前先要认下的三条规则、七步方法、类层级的陷阱、槽面的约束，还有命名约定。本页把整条论证提炼出来，再做一件论文自己做不到的事：拿每条规则去问一个活着的本体。那个本体就在本站，智能体改代码之前先加载它。

全页只用两种标记。101 §x.y 引论文原文，那是论文的主张，不是本站的主张。VLSC 标出本站如何回应这条规则，并点名对应工件，好让这层映射可查，而不只是可信。

7 个步骤 20 个层级陷阱 5 类槽面 24 条清单
01 · 出处

一份 2001 年的指南，早写进了智能体

它写给领域专家，不写给 AI 实验室，成书于 Protégé-2000 与框架系统的年代。论文列出的第一条建本体的理由，是让人和软件智能体对信息结构有一致的理解。这句话在 2001 年读来像套话，如今却是全部要害。

项 内容
标题 Ontology Development 101: A Guide to Creating Your First Ontology（本体开发 101：创建你的第一个本体）
作者 Natalya F. Noy、Deborah L. McGuinness，斯坦福大学
篇幅 25 页，8 节，9 幅图
工具年代 示例用 Protégé-2000，本体库用 Ontolingua，诊断工具用 Chimaera；RDF 与 DAML 在文中还只是 W3C 和 DARPA 正在推进的新东西
贯穿示例 葡萄酒与餐食搭配，源自 CLASSIC 教学知识库（Brachman 等，1991）
思想血缘 Gruber 1993 给定义，Gruninger 与 Fox 1995 提出能力问题，Uschold 与 Gruninger 1996、Gómez-Pérez 1998 是论文指出的另几家方法论，Rosch 1978 讲概括层级
原文 protege.stanford.edu — ontology101.pdf

为什么要建本体：论文给的五条（§1）

取得一致理解

让人和软件智能体对信息结构的理解一致。多个网站若公布同一套底层本体，智能体就能跨站抽取、汇总，再拿去回答查询，或喂给别的应用。

复用领域知识

时间、单位、设备这类概念，一处建好，处处可用。要建大本体，也可以把几份现成的拼起来，或者拿通用本体来扩展。

让假设显式

假设一旦硬编码进程序，就难找、难懂、难改，对不会编程的人尤其如此。写明白了，新读者也才学得会术语。

领域知识独立于操作知识

把任务所属的领域单独描述，解题程序就能独立于领域。同一套配置算法，喂进 PC 零件本体就配 PC，喂进电梯零件本体就配电梯。

便于分析

术语一旦声明出来，就能形式化地分析。要复用或扩展别人的本体时，这一点最要紧。

Often an ontology of the domain is not a goal in itself. Developing an ontology is akin to defining a set of data and their structure for other programs to use.

本体本身往往不是目的。做本体，近似于为别的程序定义一批数据和它们的结构。101 §1 正是这句话，让本体有资格充当智能体的上下文：它是给消费者用的数据，不是立给自己看的纪念碑。

Noy & McGuinness 2001, §1
VLSC。本站的消费者就是智能体。同一套八个顶层概念、同一批关系、同一批不变量，有三种读法：智能体动手前读它当上下文，编辑前门禁读它来拒绝违规，人审查时读它当词汇。一套语义，三方消费。详见 Agentic · 领域本体。
这不是面向对象设计（§ About this guide）。OO 看类的操作属性，也就是它带哪些方法，据此做设计决断；本体看类的结构属性，也就是它是什么、有什么、与什么相关。论文说得很直接：同一个领域，按 OO 建出的类结构和关系，跟按本体建出的，并不一样。
02 · 构件

类、槽、槽面、实例，合起来叫知识库

论文先给出自己的定义，因为 AI 文献里的定义太多，而且彼此矛盾（§2）。

术语 又称 论文的定义（101 §2） 葡萄酒示例
类 class 概念 concept 论域中的一个概念。多数本体以类为主。 Wine、Red Wine、 Pauillac、Winery
槽 slot 角色 role、属性 property 类或实例的属性，描述它的某项特征。 body、maker、color、 produces
槽面 facet 角色限制 role restriction 加在槽上的限制：值类型、允许值、基数、默认值。 body 取值限于 {light, medium, full}；produces 可多值，值必须是 Wine 的实例
实例 instance 个体 individual 类的具体成员。本体加上一批实例，就构成知识库。 Chateau-Morgon-Beaujolais、某家酒庄、某个年份

An ontology together with a set of individual instances of classes constitutes a knowledge base. In reality, there is a fine line where the ontology ends and the knowledge base begins.

本体加上一批类的个体实例，就构成知识库。可在实际上，本体止于何处、知识库始于何处，那条线细得很。101 §2

Noy & McGuinness 2001, §2

落到手上，做本体就是四件事（§2）

定义类→把类排成
分类层级→定义槽
与允许值→为实例
填槽值
VLSC。这四件事在本站一一对得上。类：八个顶层概念，即主体 Agent、物理实体、软件系统、活动、信息对象、能力、策略与约束、证据。关系：把类连起来的那些槽，requests、changes、yields、sampled-as、framed-as，再加上产品族之间的 inherits、consumes、implements、inspired-by。槽面：52 条机器可读约束各自带的 severity、sdd_ref、scope 通配与 patterns。实例：电台 Profile、具体台站、带日期的证据记录。普查日期 2026-09-12。
03 · 三条规则

动手之前先要认下的三条

论文自己说：这几条听来近乎教条，但多数设计决断都得靠它们（§3）。后面每一步，都是这三条的应用。

没有唯一正确的模型

「领域可以有多种建法，条条都成立。哪种最好，几乎总是取决于你打算拿它做什么，以及你预期它往哪儿扩展。」101 §3

必然要迭代

「本体开发必然是迭代过程。」先粗略搭一版，再改，再补细节。初版一旦拿去用，或者拿给领域专家看，几乎必定要改。101 §3

概念要贴近领域

「本体里的概念，应当贴近领域中的对象和关系；对象不论物理还是逻辑都算。」它们多半就是描述该领域时用到的名词和动词。101 §3

论文的自谦，原文照录。「世上没有唯一正确的本体开发方法论，我们也无意定义一种」（§ About this guide）。结论里又说：「任何领域都不存在唯一正确的本体。本体设计是创造性的工作，两个人设计出的本体不会相同……布丁好不好，吃了才知道：本体质量只能靠拿它去用，用到当初为它设计的那些应用里去，才评得出来」（§8）。一套以「用」收尾的方法，必须配上证据。下一节就从这里讲起。
VLSC。本站本体的形状，是第 2、3 条规则定的。概念和约束要跨产品反复出现、并且有证据，才收进来；从不先在白板上设计一套。那些名词和动词来自事故报告和 SDD 裁决，不来自谁觉得好看的分类法。
04 · 方法

七个步骤，依次是

这是指南的主干（§3）。第 4、5 两步紧密交织，论文说它们是本体设计中最要紧的两步；所以论文用 §4、§5 两节回头细讲，本页也一样，见下面第 05、06 节。

步骤 论文问什么 决定性的规则 本站工件
1 定领域与范围 哪个领域？拿来做什么？要回答哪些问题？谁用、谁维护？ 范围由任务塑形。同一个领域，消费者不同，本体就不同。 12 个能力问题，5 份产品族 Profile
2 找现成的来用 已经有什么可以拿来细化、扩展？ 一旦别的系统已经认定了某套词汇，复用就从偏好变成了前提。 W3C SSN/SOSA、PROV-O、OWL-Time、SKOS、SAREF/QUDT 作为概念参照；Hamlib 词汇则是不得不认的复用
3 列出术语 哪些术语是我们要陈述、要向用户解释的？ 先把清单列全，暂且不管概念重叠、术语之间的关系，也不管它是类还是槽。 双语术语表：CommandIntent、Actuation、Observation、StateReport、DeviceAdapter、Protocol Binding、Control Lease……
4 定类与层级 哪些术语指称独立存在的对象？它们怎么概括？ is-a 检验：子类的每个实例，必然也是父类的实例。 八个顶层类；五个产品族互为兄弟；不设人造的中间层
5 定槽 每个类有哪些属性？剩下那些术语各自属于哪个类？ 槽要挂在能有该属性的最概括的那个类上。 requests、changes、yields 等关系；能力槽与协议绑定槽
6 定槽面 值类型、允许值、基数、定义域、值域、默认值各是什么？ 定义域和值域取最概括的，但不能概括过头，绝不能是 THING。 约束的 severity、sdd_ref、scope、patterns；基数则表现为「权威状态所有者唯一」
7 建实例 建哪些个体？粒度多细？槽值填什么？ 个体实例就是应用需要表示的最具体的那些概念。 电台 Profile（FT-710、IC-7300、IC-7300MK2）、带日期的证据记录、公开看板上分了类的 🐞 上报

第 1 步：定领域与范围（§3, Step 1）

四个问题

本体覆盖哪个领域？拿来做什么？要能回答哪类问题？谁用、谁维护？设计过程中答案会变，论文说，但在任一时点上，它们都能替你圈住模型的范围。

范围由任务塑形

论文自己举的例子最清楚：同样是葡萄酒领域，要支持自然语言处理，就得收同义词和词性；要让顾客点酒，就得有零售价；要让采购给酒窖备货，就得有批发价和货况。三个任务，三套本体。

维护者与使用者不同语言

「如果维护本体的人描述领域时用的语言，跟本体使用者的语言不同，那就可能要在两种语言之间给出映射。」101 §3

能力问题 competency questions（§3, Step 1）。先把一批问题写下来：建立在这个本体之上的知识库，应当能回答它们。论文说，这批问题日后就是试金石，用来检验本体是否装够了信息、细节层次是否对路。它只是草稿，不必穷尽。葡萄酒那批问题，从「Bordeaux 是红酒还是白酒」一直到「Napa Zinfandel 哪些年份好」；读完就知道，年份和餐食分类要进范围，酒庄库存和餐厅员工不进。本站对应的是 12 个能力问题，发布在证据纪律一节末的附录里，从「哪个软件系统持有某台电台的权威状态」到「哪项安全主张背后有真实的传感器或观测路径」。
VLSC 与语言映射那条规则。本站每个本体术语都双语维护，是有意为之：CommandIntent 写作控制意图，Field verified 写作现场验证。原因是维护者用一种语言思考，读者中另有一部分人读另一种语言。映射公开写出来，不靠意会。

第 2 步：找现成的来用（§3, Step 2）

几乎总值得先查一遍

「别人做过什么，几乎总值得先看一眼，再判断能否拿过来为本领域、本任务细化和扩展。」

有时是前提，不是偏好

如果你的系统要跟别的应用打交道，而那些应用已经认定了某套本体或受控词汇，复用就不再可选。

形式体系多半不要紧

多数知识表示系统都能导入导出；万一不能，把本体从一种形式体系转成另一种，论文说，通常也不算难。

VLSC：复用的是概念，不是运行时。W3C SOSA/SSN 给出观测、传感器、执行活动这组区分；PROV-O 给出溯源字段；OWL-Time 给出时间区间词汇；SKOS 给出双语概念的写法；SAREF 与 QUDT 给出设备、功能、量三者的分法；WoT Thing Description 给出能力与可供性（affordance）的思路。但这不等于跑一个 RDF 库、图数据库或推理机：本站的本体始终是一份由产品证据支撑的轻量双语契约。另有一处复用是严格意义上的：Hamlib 自己的词汇。MRRC 这一族别无选择，只能认它，因为 rigctld 早就认了。

第 3 步：列出术语（§3, Step 3）

把要陈述、要向用户解释的术语统统写下来，连同它们的属性，以及你想就它们说些什么。这一步只求全：论文说，暂时不必管概念之间是否重叠、术语之间有什么关系、也不必管它算类还是算槽。分拣留给第 4 到 6 步。论文还提醒，第 4 步与第 5 步交织进行：先定义几个类，接着描述它们的属性，再回头补类。

第 4 步：定类与类层级（§3, Step 4）

自顶向下

先立最概括的概念，再逐级特化：Wine 分红、白、桃红；Red Wine 再分 Syrah、Red Burgundy、Cabernet Sauvignon。

自底向上

先立最具体的叶子，再向上归并：Pauillac 与 Margaux 归入 Medoc，Medoc 再归入 Bordeaux。

混合

先立最显眼的几个概念，再向上概括、向下特化。论文说这对多数开发者最省事，因为中间那一层的概念往往最能描述领域（Rosch 1978）。

三种都没有天生更好。选哪种，「很大程度上取决于你对领域的个人看法」。具体做法是：从第 3 步清单里挑术语，要指称独立存在对象的那些，不要描述对象的那些，用前者当层级锚点。然后靠一条检验来排列：若 A 是 B 的父类，则 B 的每个实例必然也是 A 的实例；换句话说，B 是 A 的一种。每瓶 Pinot Noir 必然是红酒，所以 Pinot Noir 是 Red Wine 的子类。101 §3–§4.1

第 5 步：定槽（§3, Step 5）

光有类不够

「仅有类，不足以回答第 1 步列出的能力问题。」第 3 步清单里剩下的术语，多半就成了类的属性。

属性有四类

内在属性，如酒的风味；外在属性，如酒名、产区；部件，物理的或抽象的都算，如一餐的各道菜；与其他个体的关系，如 maker 把一款酒连到一家酒庄。

挂高一点，向下继承

「槽应当挂在能有该属性的最概括的那个类上。」body 与 color 挂在 Wine；tannin level 挂在 Red Wine，因为白酒不用它来描述。子类一律继承。

第 6 步：定槽面（§3, Step 6）

槽面 约束什么 论文的例子
基数 cardinality 一个槽能有几个值：单值还是多值，或者写明下限与上限。上限为 0 也合法，意思是某个子类根本不许填这个槽。 body 单值；produces 多值；grape 下限 1，单一品种酒的上限也是 1
值类型 value type 填进来的是什么值：String、Number（或更细的 Float、Integer）、Boolean、枚举（Protégé-2000 里叫 Symbol），或者 Instance 并列出允许的类。 name 是 String；flavor 取值限于 {strong, moderate, delicate}；produces 的值是 Wine 的实例
定义域 domain 槽挂在哪些类上，也就是它描述谁的属性。 Winery 是 produces 的定义域
值域 range 实例型槽的值允许来自哪些类。 Wine 是 produces 的值域
默认值 default 新建实例时自动填上的便利值。它跟槽值不同，可以改。详见下面第 06 节。 若范围内多数酒都是饱满酒体，就把 body 的默认值设为 "full"
定义域与值域的四步收敛（§3, Step 6）。一，找出能当定义域或值域的最概括的类。二，别概括过头：定义域里的每个类，这个槽都得真能描述；值域里的每个类，都得是潜在填料。论文说，「没人会把值域定成 THING」。三，清单里若同时有某个类和它的子类，删掉子类，它不提供任何新信息。四，若清单列全了 A 的所有子类却没有 A，那就只写 A；若列了 A 的绝大多数子类，也该想想是不是直接写 A 更合适。挂槽同理，因为在把槽挂到类上就等于声明定义域的系统里，两者是一回事：tannin level 挂在 Red Wine 上，不必逐个红葡萄品种去挂，也不能上提到 Wine。
VLSC。第二步正是本站把 Protocol Binding ≠ Capability 立为公理、而不只是当成偏好的原因：能力若声明在一个过泛的值域上（「任何后端都行」），就没有任何测试能证伪它。具体锚点是 audio-pyaudio-rate 这条约束，音频采样率来自后端能力，而不是写死在调用处的机型名 [AD-011，经 V2.9 与 V2.14 修订]。基数在本站不以槽面形式出现，而是以不变量出现：权威状态所有者唯一，串口所有者唯一（ft8 no-direct-serial [AD-008]；ft710 与 modern cat-direct-serial-io [AD-002]）。

第 7 步：建实例（§3, Step 7）

三个动作：选定类，建一个该类的个体，填上槽值。论文给的样例个体是 Chateau-Morgon-Beaujolais，八个槽值：body 轻，color 红，flavor 细致，tannin level 低，grape 是 Gamay（Wine Grape 的实例），maker 是 Chateau-Morgon（Winery 的实例），region 是 Beaujolais（Wine-Region 的实例），sugar 干。这个样例值得留意的一点是：八个值里有三个本身又是别的类的实例。知识库能查，靠的正是这一点，否则就只是一堆字符串。
VLSC。证据都落在实例上。电台 Profile（FT-710、IC-7300、IC-7300MK2）是实例，带能力值；带日期的证据记录是实例，带来源、版本、环境、方法、结果与局限；公开看板上分了类的 🐞 上报也是实例。论文的粒度规则说，个体实例就是知识库中所表示的最具体的概念，本站据此把发布当实例、把电台机型当类：发布要数，机型要描述。
05 · 层级陷阱

类层级出错的二十种走法

论文 §4 是一份缺陷目录，不是教程：「定义了不少新类之后，退后一步，看看长出来的层级是否合这些规矩，很有帮助。」把它当审查清单来读，人能用，智能体也能用。

# 陷阱 规则（101 §4） 为什么会坏
1 把 is-a 读成「跟……有关」 A 是 B 的父类，当且仅当 B 的每个实例必然也是 A 的实例，是「一种」关系。§4.1 沾边就成了子类，继承会把子类没有的属性硬塞给它。
2 单数挂在复数下 不要先立 Wines，再把 Wine 当它的子类。单复数选定一种，全篇一致。§4.1、§6.2 「一款酒不是一种葡萄酒们」。层级就此对领域说了假话。
3 忘了传递性 B ⊂ A、C ⊂ B，则 C ⊂ A。§4.1 挂在高层的约束会悄悄作用到三层以下，那里没人料到有它。
4 直接子类与间接子类不分 直接子类与父类之间不隔别的类：Chardonnay 是 White Wine 的直接子类，不是 Wine 的。§4.1 兄弟分析、「槽挂最概括的类」这两件事都要用直接关系，不能用传递闭包。
5 领域变了，层级没变 白 Zinfandel 出现之后，Zinfandel 必须拆成红、白两个子类，分别挂到不同父类下。§4.1 领域已经动了，本体还在断言某些实例并不具备的颜色。
6 把类和它的名字混为一谈 「类表示领域中的概念，不表示指称这些概念的词。」把 Shrimps 改名 Prawns，其余什么都不必动。§4.1 把换术语当成改模型，下游就跟着重建一遍。
7 同义词当成不同的类 一个概念一个类。同义词、译名、展示名挂成列表，系统不支持就写进文档。§4.1 Shrimp、Prawn、Crevette 三个类，等于一件事实在三处维护。
8 环 A ⊂ B 且 B ⊂ A，等于宣告 A 与 B 等价。§4.1 层级不再是层级，遍历可能不终止。
9 兄弟不在同一概括层级 除根以外，所有兄弟必须处于同一概括层级：White Wine 与 Chardonnay 不是兄弟。根上的类是领域的大分野，不受此限。§4.2 这棵树读起来像一份目录，章和三级节并排。
10 只有一个子类 「一个类若只有一个直接子类，多半是模型有问题，或者本体还不完整。」如同只有一条的项目符号列表。§4.2 要么两类等价，删掉一个；要么缺席的兄弟还没找到。
11 子类超过一打 结构良好的本体，直接子类在两个到一打之间；再往上就该考虑中间层。§4.2 所有酒型平铺在 Wine 下，就埋掉了领域本来就有的 Medoc／Bordeaux、Côtes d'Or／Burgundy 结构。
12 硬造分组类 一长串兄弟若找不到自然的类来归并，就让它平铺：「本体是对真实世界的反映」。§4.2 人造的中间层，领域里没人认得，往后每个实例都得硬塞进去。
13 不敢用多重继承 多重继承是合法的：Port 既是 Red Wine 又是 Dessert Wine，从一个父类继承 sugar = SWEET，从另一个继承 tannin level 与颜色。§4.3 拒绝它，就会长出两棵必须手工同步的平行层级。
14 新类无话可说 子类要有额外属性、不同限制，或参与不同关系，才立得起来；落到实处，它应当新增槽、新增槽值，或覆盖继承来的槽面。§4.4 除了名字之外对父类毫无补充的类，是名字，不是概念。
15 为每个限制立一个子类 不要为槽的每个取值立类，比如 Delicate Wine、Moderate Wine；这种区分属于槽值。§4.4–§4.5 类爆炸，取值的每个侧面都变成树上的一个节点。
16 不承认术语型层级 参考型层级（如疾病分类）可以完全不带属性，仍然值得有：它便于浏览，也让人自己挑概括层级。§4.4 非要每个类都挣来新槽，就会把那些本职工作是组织术语的词汇表压平。
17 实例会迁进迁出的类 「一个个体所属的类，不应当经常变。」Chilled Wine 是属性，不是类。§4.5 拿外在属性当分类标准，实例就会在有生之年换类，连带把继承来的槽面一起带走。
18 明明有层级，却建成实例 概念若构成自然层级，就建成类：所有葡萄酒产区都是类，没有直接实例的标为抽象类。世上没有「子实例」这种东西。§4.6 Bourgogne 若只是实例，就挂不上 Côtes d'Or，自然结构丢了。
19 范围过宽或过窄 不要比应用所需更特化或更概括，「两个方向各多一层也就到头了」；也不必收尽所有属性、所有可想到的关系。§4.7 酒标用纸和虾的做法挤进了餐酒搭配本体。维护成本涨了，能力问题一个没多。
20 不相交没有声明 不可能共享实例的类，要声明不相交：Red Wine 与 White Wine 不相交，Dessert Wine 与 White Wine 则相交。§4.8 不声明，系统就没法指出「同时继承 Riesling 与 Port 的类」是模型错误。

三个最难的决断

立新类，还是取槽值？（§4.5）

两种情形该立类：一，取值不同的概念会变成别的类的槽上的限制；二，这个区分在领域里要紧，你把两边看成不同种类的对象。其余情况留在槽值里。酒的颜色是论文用来印证规则的反例：颜色通常只是槽值，可红酒与白酒配的菜不同、属性也不同，于是 Red Merlot 与 White Merlot 是两个类。

是类，还是实例？（§4.6）

先定应用需要的最细粒度。论文说，能力问题的答案里最具体的那些概念，最适合当个体。只谈餐酒搭配，到 Sterling Vineyards Merlot 就到底了；再加餐厅库存，一瓶瓶酒就成了个体；再要按年份记属性，年份成了实例，那款酒反倒升为类。

收住范围（§4.7）

真命题也可能超出范围。做实验的人当然是生物体，可在实验本体里让 Experimenter 当 Biological Organism 的子类，就会给每个实验者挂上体重、年龄、物种这些槽：全是无关数据，还会坑到复用者。论文更要紧的是后半句：这类决断要写进文档。日后别人拿本体去做别的应用，才知道这条事实是故意不收。

VLSC：第 20 条在本站是活的不变量。声明不相交，模型才可查。本站声明了好几处：发射态与接收态不相交，台站必居其一；权威状态所有者与客户端投影不相交，这才是「客户端可以投影或请求状态，但不能悄悄变成台站权威」的形式内容。同一手也用在证据阶梯上：过程证据（B1–B4，问工程有没有约束）与产品证据（设计目标到现场验证，问行为是否为真）故意声明为不相交，于是再多绿约束也读不出一台架结果。见证据纪律。
VLSC：第 10 到 12 条由证据裁定。五个产品族在同一工程体系下互为兄弟，本站没有为了让树好看而硬造第六个分组类。确有自然的中间概念时才收：RadioBackend 与 RadioCapabilities 把 FT-710 的垂直切片概括成 Modern 平台，这正是第 11 条的解法，中间层来自领域真在用的概念。反向的例子也写明：SunsdrMobile 是 SunMRRC 的客户端，不是产品族。把这一点说清楚，才不至于在它旁边长出一个只有一个子类的分支。
06 · 属性

反向槽，以及默认值与槽值之别

论文 §5 很短，容易被跳过。它的两个主题都关乎冗余与强制，而模型能否被机器信任，正取决于这两件事。

反向槽（§5.1）

Wine 上的 maker 与 Winery 上的 produces，是同一件事说了两遍。两个方向都存，是冗余：应用总能从一个推出另一个。但从知识获取的角度看，两边都留着方便，因为用户这一回手里是酒，下一回手里是酒庄。于是系统自动填反向槽，让知识库保持一致。

值得留下的一条：成对声明，只存一侧，镜像交给系统维护。

默认值与槽值（§5.2）

默认值是便利：多数实例共享某值时，新建实例先填上它，之后可以改。论文说，它不给模型添任何新限制，也不改变模型。

槽值是另一回事。若 Dessert Wine 上 sugar = SWEET 是值，那么它的每个子类和实例都带这个值，改不得。一个是起点，一个是约束。

VLSC：这条区分在本站花过一次事故的钱。FT-710 的音频采样率，本站曾当成固定值：44.1 kHz，挂在机型上。它其实是后端报告的能力。修正记录为 AD-011，经 V2.9 与 V2.14 两次修订，并由 audio-pyaudio-rate 这条约束钉住：采样率来自后端能力。用论文的话说，本该放默认值、或者更好放一次查询的地方，却写成了值，于是模型断言了一件硬件随时可以推翻的事。
VLSC：本站的反向槽，以及哪一侧才有权威。这里确有几对反向关系：台站控制租约的持有者，与持有者名下的台站；CommandIntent 与回应它的 StateReport；🐞 上报，与结案它的那张答复页。镜像一律由服务端维护，客户端不许维护。这条不对称是安全不变量，不是便利：投影可以显示镜像值，但只有权威侧能写。CommandIntent ≠ Actuation 与 Observation → StateReport 说的其实是同一件事：命令不等于确认状态，只有观测才闭合回路。ft710 的 ptt-release-no-verify 是老实写明的例外：TX0 发出去就不回头，因此没有镜像可维护，也没有确认可推断 [AD-007; Ch15; V1.2]。
07 · 命名

「为类和槽定下命名约定，然后守住它」

论文 §6。命名在这里是建模的安全装置，不是修饰：一致性正是防止单复数那类错误的手段，而写明的约定能让人一眼认出某个术语是类还是槽。

决断（101 §6） 论文怎么说 本站约定
先看系统的限制 约定要绕着知识表示系统来定：类、槽、实例是共用一个名字空间还是分开；是否区分大小写；哪些分隔符合法。Protégé-2000 区分大小写、共用一个名字空间，所以类 Winery 与槽 winery 可以并存，两个 winery 就不行。 本站的「系统」是仓库加智能体运行时。名字要同时活得下去：在代码里当标识符，在 harness/index.json 里当键，在约束注册表里当检索词。所以用 ASCII，不用空格，区分大小写。
大小写 系统区分大小写时，类名首字母大写，槽名小写。 类与本体术语用 PascalCase：CommandIntent、StateReport、DeviceAdapter、ControlLease。关系用小写：requests、changes、yields、inherits、consumes、implements、inspired-by。
分隔符 空格、驼峰、下划线或连字符都行；用了分隔符，还得决定每个词是否大写。空格最直观，但未必经得起与其他系统打交道。 约束 ID 用 kebab-case，读起来像一条规矩，而不像一个东西：cat-no-dn、no-direct-serial、poll-stale-guard、vendor-readonly、ptt-authority。多词的本体关系用连字符，同理。
单数还是复数 两者都不更好，实践中单数更常见。选定一种，全篇一致；有些系统还要求你事先声明，不许中途改。一致也正是防止 Wines 底下挂 Wine 的办法。 所有类与术语一律单数：产品族、物理实体、信息对象。复数只出现在散文里，绝不进术语。
前后缀 给槽名加 has- 或 -of，术语自己就表明身份，代价是名字变长。 不用。动词形式的关系（requests、yields）对上 PascalCase 的类，本来就不会认错，再加前缀只是噪音。
不要把种类写进名字 概念名里不要加「class」「property」「slot」这类字。上下文和约定已经说明了它是什么。 照办。唯一有意破例的是证据阶梯：徽章文字自带种类（现场验证、台架待验证），因为徽章会脱离上下文出现在表格和发布说明里。
避免缩写 「用 Cabernet Sauvignon，不用 Cab。」 照办，但有一处要老实交代：无线电领域的受控词汇本身就是缩写，PTT、CAT、SWR、IQ、EFHW、QSO、VFO、DNR。这些是术语，不是简写，双语术语表里给出全称。真正适用的规则是：不许自造缩写。
子类怎么命名 直接子类要么都带父类的名字，要么都不带：Red Wine 与 White Wine，或者 Red 与 White，不能一边带一边不带。 产品名跟着族走：MRRC Universal、MRRC FT-710、MRRC Modern、MRRC-FT8，族标记都在。SunMRRC 保留自己的词根，因为它是另一条轨道上的东西，不是子类。
同义词与译名 许多系统允许给一个类挂一串同义词、译名或展示名；系统不支持，就写进类的文档。§4.1、§6 双语术语表就是这份清单，而且是公开的：控制意图 CommandIntent，执行活动 Actuation，观测活动 Observation，现场验证 Field verified。两个名字，一个概念；绝不做成两个概念。
08 · 检查清单

整份指南压成 24 条

写成人能拿它审模型、智能体能拿它当本体变更验收单的样子。每一条都注了论文出处。

A · 建模之前

  1. 把四个范围问题写下来。
    领域、用途、要回答的问题、谁维护，并标上日期，因为答案会变。§3 Step 1
  2. 起草能力问题。
    它是后面一切的试金石，不必穷尽。§3 Step 1
  3. 先查一遍现成的。
    记下你采纳了什么、只参考了什么、又被迫认定了什么。§3 Step 2
  4. 先列全术语，再分拣。
    算类还是算槽，留到后面定。§3 Step 3

B · 搭层级

  1. 明确选定一种建树方向。
    自顶向下、自底向上，或混合。混合通常最省事，因为中间层的概念最能描述领域。§3 Step 4
  2. 用独立存在的对象当锚点。
    要指称对象的术语，不要描述对象的术语。§3 Step 4
  3. 每对父子都过一遍 is-a 检验。
    子类的每个实例，必然也是父类的实例。§4.1
  4. 兄弟保持在同一概括层级。
    根上的类除外，它们是领域的大分野。§4.2
  5. 子类两个到一打。
    只有一个说明有问题，超过一打就该找中间层，但绝不硬造。§4.2
  6. 不许有环，不许把同义词建成类。
    环等于宣告两类等价；同义词只是同一概念的另一个名字。§4.1

C · 槽与槽面

  1. 槽尽量挂高，但要说得过去。
    挂在能有该属性的最概括的那个类上。§3 Step 5
  2. 给每个属性归类。
    内在、外在、部件，还是与其他个体的关系。§3 Step 5
  3. 声明基数与值类型。
    下限、上限都写；上限为 0 也是合法声明。§3 Step 6
  4. 定义域和值域取概括的，但别到 THING。
    定义域里的每个类，这个槽都真能描述；值域里的每个类都是潜在填料。§3 Step 6
  5. 修剪定义域与值域清单。
    父子同现删子；子类列全了就换成父类；只差几个子类时，也想想父类是不是更合适。§3 Step 6

D · 类、值，还是实例

  1. 无话可说就不立新类。
    要有新属性、新限制，或者新的关系。§4.4
  2. 区分默认留在槽值里。
    除非这些取值会成为别处的限制，或者领域把它们看成不同种类的对象。§4.5
  3. 实例会迁进迁出的，不要建成类。
    冰镇过的酒是属性，不是分类。§4.5
  4. 粒度由能力问题定。
    构成自然层级的概念升为类；没有直接实例的，标成抽象类。§4.6

E · 命名

  1. 约定写下来，然后守住。
    大小写、分隔符、单复数，都要绕着你实际所在的系统来定。§6
  2. 不自造缩写，不把种类写进名字。
    子类命名要么都带父类名，要么都不带。§6.2–§6.4
  3. 一个概念，多个名字。
    同义词和译名挂到类上，绝不升格为兄弟类。§4.1、§6

F · 治理

  1. 排除了什么、为什么，写进文档。
    做实验的人当然是生物体，可这个本体故意不这么建。不写下来，复用者就会被误导。§4.7
  2. 声明不相交，然后拿去用。
    不可能共享实例的类要说清楚，工具才拦得住错误。剩下的评法只有一条：用。§4.8、§8
09 · 本站审计

七个步骤，逐条对着活体本体审

论文要什么，本站有什么，以及本站缺什么。只列成功项的审计等于广告，所以缺口一栏照写。普查日期 2026-09-12；工件都点了名，每一行都可查。

步骤 有没有 锚点 缺口与局限
1 范围与能力问题 有 12 个能力问题已公开；5 份产品族 Profile；范围逐族写明，见产品族 这些问题是散文，不可执行：某个问题变得答不上来时，没有任何构建会失败。
2 复用 有，但只在概念层 W3C SOSA/SSN、PROV-O、OWL-Time、SKOS、WoT TD；ETSI SAREF 与 QUDT；Hamlib 词汇属于被迫认定 没有形式化导入：运行时不从这些名字空间加载任何东西，所以这层对齐全靠人工维护。
3 术语枚举 有 双语核心术语表，12 组对照，公开在附录 除中英对照外没有同义词表。无线电领域的别名，比如 CAT 与 rig control、PTT 与发射触发，没有作为同义词声明。
4 类与层级 有，而且刻意浅 八个顶层类；五个产品族互为兄弟；唯一挣来的中间层是 RadioBackend 与 RadioCapabilities 顶层往下最多两级。这是范围决断，不是疏忽，但也就意味着 is-a 检验很少受到压力。
5 槽 有 requests、changes、yields、sampled-as、framed-as；族间关系 inherits、consumes、implements、inspired-by 关系写在散文和 SVG 图里，没有工具能遍历的 schema。
6 槽面 部分有，而在要紧处比散文更强 三个仓库共 52 条机器可读约束，各带 severity（block ／warn／info）、sdd_ref、scope 通配与 patterns；基数以不变量形式出现：权威状态所有者唯一，串口所有者唯一 这些是加在代码上的强制槽面，不是声明在本体槽上的槽面。关系的定义域与值域从未形式化写过。
7 实例 有 电台 Profile（FT-710、IC-7300、IC-7300MK2）；带日期的证据记录；公开看板上分了类的 🐞 上报 实例散在三处：代码里的 Profile、发布说明、看板。没有共用的标识方案。
§4.8 不相交 写在散文里 发射态与接收态；权威所有者与客户端投影；过程证据 B1–B4 与产品证据（设计目标到现场验证） 没有机器可读的声明，工具拦不住违规，检查靠人读不变量。
§6 命名 有 术语 PascalCase，关系小写，约束 ID kebab-case，类名单数，双语对照公开 约定看得见，却没写下来：它活在工件里，不在智能体能加载的风格文档里。
§8 以用评优 有，而且比论文更强 一套语义三方消费：智能体上下文、PreToolUse(Edit|Write) 门禁、人工审查；阻断可复现（sdd_context.py check 退出码 2） 统计的是被拦下的编辑，不是被回答的能力问题。第 1 步那块试金石，至今靠人。
老实的结论。本站本体强在论文沉默之处：运行时消费、强制、溯源；弱在论文着力之处：定义域与值域没有形式化，不相交没有声明，命名约定没有成文，能力问题不可执行。两半互不抵消。智能体能加载、却推理不动的本体，是一种失败；推理得很漂亮、却没人消费的本体，是另一种失败。
10 · 边界

101 止步之处，以及智能体补上了什么

2026 年读一份 2001 年的指南，得先说清它是站在什么位置写的。以下都不是批评。论文自称是「起点」，而它至今仍是最清楚的那个起点。

除了「用」，没有度量

本体好不好，论文只给一个评法：拿它去用，用到当初为它设计的那些应用里（§8）。点名的工具只有 Chimaera，用来查逻辑正确性和常见设计错误。没有成本模型，没有覆盖度指标，也没有回归这个概念。

时间维度上没有治理

演化只出现过一次，还是白 Zinfandel 的那则轶事（§4.1）。没有版本管理，没有所有权，没有裁决流程，也没交代谁可以改一个类、凭什么证据改。

没有会反抗的消费者

论文设想的消费者是应用和基于知识的系统，它们读模型。它从未设想一种能改代码库的消费者。而恰恰是这种消费者，把本体从文档变成了门禁。

框架系统，不是语义网

槽挂在类上，默认值存在，RDF 与 DAML 在文中还只是正在成形的工作。换成 OWL 2 来读，差别是种类上的：属性是全局的，带已声明的定义域与值域，开放世界假设成立，而且根本没有默认值这回事。

没有责任

整份指南没有一处问：模型错了谁负责，谁有权批准依据它采取的行动，一个决定怎样追回做出它的那个人。

谈节点，不谈边

101 管的是把节点做出含义。它不涉及节点之间那些链接的质量，而恰恰是链接质量决定了一网模型、工具和人会复利，还是只会放大噪音。

智能体的设定补上了什么

本体成为运行时上下文

智能体动手之前就加载它，而不是等出了问题再去查。AGENTS.md、活体 SDD，加上一份不存内容的路由索引；索引不存内容，引用因此永不过时。

槽面变得可强制

severity、sdd_ref、scope 与 patterns，把一条建模规矩变成 PreToolUse 钩子，在编辑落盘之前就能拒绝它，退出码非零就是回执。

溯源成为硬要求

每项主张都带来源、版本、环境、方法、结果、日期与局限。证据只能快照，不能累积：没有截止时间的数字不是测量，是带小数点的传闻。

事故升格为公理

论文的迭代回路在这里有了具体动力：现场事故变成 SDD 裁决，裁决变成机器可读约束，约束拦住事故重来。事故只有变成护栏才算修好。

能力图旁边放一张责任图

每条让某物得以行动的链接，五个问题都要有具名答案：谁供的数据，谁选的目标，谁授权了行动，谁观察了后果，谁能把它停下来。能力链接与责任链接同步增长，递归式改进才可持续。

边质量是姊妹学科

六个属性：语义清晰、来源可追、反馈闭环、权限有界、故障隔离、目标可审查。这是 101 的节点纪律在链接上的对应物。见连接质量。

There is no single correct ontology for any domain. Ontology design is a creative process and no two ontologies designed by different people would be the same. "The proof is in the pudding" — we can assess the quality of our ontology only by using it in applications for which we designed it.

任何领域都不存在唯一正确的本体。本体设计是创造性的工作，两个人设计出的本体不会相同。布丁好不好，吃了才知道：本体质量只能靠拿它去用，用到当初为它设计的那些应用里去，才评得出来。101 §8 而在 2026 年，那个应用里多了一个消费者：它读模型，改代码，而且可能被模型拒绝。

Noy & McGuinness 2001, §8
11 · 参考

出处，以及往下读什么

论文及其血缘

  • Noy 与 McGuinness《Ontology Development 101》（2001）——本页所有 101 §x 引用的出处。
  • Gruber（1993）：本体是显式的规格说明，这个定义由此而来。
  • Gruninger 与 Fox（1995）：能力问题，既用来圈范围，也用来当试金石。
  • Uschold 与 Gruninger（1996）、Gómez-Pérez（1998）：论文指出的另几家方法论。
  • McGuinness 等（2000），Chimaera：查逻辑正确性与常见设计错误的诊断工具。
  • Brachman 等（1991），CLASSIC：葡萄酒与餐食这个示例的来处；Rosch（1978）：概括层级。
  • Duineveld 等（2000），WonderTools?：本体工程工具的比较研究。
别只读方法，去读那个模型

一套方法论值多少，看它在用的时候还剩多少

七个步骤，25 页，都是好见识。有意思的问题是：当本体的消费者还能改代码、还可能被本体拒绝时，这些见识会变成什么。那是主张页要回答的。

智能体工程工程机制博客论文原文 PDF