简介：这份教程面向本体建模初学者、知识工程课程学习者以及需要为知识图谱搭建前期本体结构的读者，围绕 Protégé-OWL 编辑器讲解从零构建 OWL 本体的核心流程。压缩包内含 1 个 doc 文档，大小约 393KB，以章节化笔记形式编排，便于按概念查阅和对照软件操作。内容从“本体用于捕获领域知识”切入，依次说明 OWL 本体由个体、属性与类构成，并结合 Pizza 领域示例演示类命名、Disjoint Classes、subclass 层次组织，以及 Object 属性、Datatype 属性、逆属性、函数属性等建模要点，帮助读者理解类与实例、父类与子类之间的关系。文档还提示类名首字母大写、个体需声明是否相同、属性可设反向关系等约定，便于减少后续推理歧义。已有 2262 人学习，适合用作 Protégé 入门练习、课程作业参考和本体结构梳理的轻量资料。
1. 先说清这件事：Protege 构建本体到底在做什么
第一次听到「Protege 构建本体」这几个字，很多人的第一反应是关掉页面：本体听起来像哲学课，Protege 听起来像某种专业仪器，两个词凑在一起更像天书。其实它想做的事很朴素——把某个领域的知识，比如一份披萨菜单里有哪些饼底、哪些配料、配料之间谁包含谁，用机器也能读懂的方式写下来。
你用表格记东西，人看得懂，机器只当它是一串字符。本体把概念排成一棵有层级的树，还顺手写清「谁是谁的子类」「哪个属性只能连一个对象」。写完之后，机器能替你查矛盾，甚至自动把新概念放到该去的位置。
这一篇不讲学术，只陪你走完从装软件到第一次自动推理的全过程。
2. 上手前的地图：OWL 本体里其实只装着三样东西
2.1 个体、类、属性：一份披萨菜单就能讲明白
第一次打开编辑器，左边一排标签页会让人有点懵：Classes、Object properties、Data properties、Individuals，还有 OntoGraf、DL Query 一堆。别急着逐个点，先用一句话记住：整个 OWL 本体只由三块积木组成，其余界面都是这三块积木的不同视角。
类（Classes）是分类，类似菜单上的类目：披萨、饼底、配料、奶酪配料、肉类配料。个体（Individuals）是具体那一份东西：你今晚点的那张玛格丽特披萨，就是一个个体。属性（Properties）是关系：这张披萨「有配料」马苏里拉，这个「有配料」就是属性。
拿生活里的例子对照更清楚。「狗」是类，「你家楼下那只叫旺财的狗」是个体，「旺财的主人是谁」是属性。三者一凑，一句可被机器读懂的话就出来了：旺财 属于 狗；旺财 的主人 是 小明。
| 积木 | 界面位置 | 披萨例子 | 生活例子 |
|---|---|---|---|
| 类 Classes | Classes 标签 | Pizza、PizzaTopping | 狗、动物 |
| 个体 Individuals | Individuals 标签 | 今晚点的这张玛格丽特 | 旺财 |
| 对象属性 Object Property | Object properties 标签 | hasTopping（有配料） | 主人是 |
| 数据属性 Data Property | Data properties 标签 | hasCalorificContentValue（热量） | 体重 12 公斤 |
对象属性和数据属性的区别，新手一开始最容易混。对象属性连接的是两个个体，比如「这张披萨」连着「马苏里拉」；数据属性连接的是个体和一个具体的值，比如「这张披萨」连着数字 250。判断方法就一句：右端如果是另一张「东西」，用对象属性；右端如果是数字、字符串、日期，用数据属性。
还有一个绕不开的词：subclass，子类。「狗」是「动物」的子类，意思是一只狗必然也是动物。这一点和编程语言里的继承看着像，但语义更强——它不是让你少写几行代码，而是推理机做判断时的依据。你把「素食披萨」定义成「只放奶酪或蔬菜配料的披萨」，推理机就能替你找出菜单上哪些披萨符合这个条件。
2.2 为什么值得学：表格记不住的那些事
如果只是想列一份配料清单，Excel 确实更快，这点得诚实说。本体真正开始有价值，是在这三种情况：概念多到几百个、关系交叉复杂、你还希望机器帮你检查有没有自相矛盾。
第一是一致性检查。你把「奶酪配料」和「蔬菜配料」设成互斥，又手滑建了一个同时属于两者的类，推理机会立刻把它标红。这种错误在几千行的表格里靠人眼基本查不出来。
第二是自动分类。你定义「只放奶酪或蔬菜的披萨叫素食披萨」，然后点一下 Classify，推理机会自己把菜单上的玛格丽特、索霍这些披萨挂到素食披萨底下。类的数量上百之后，这件事人工做不完。
第三是可复用。本体存成一个标准格式的文件，别的项目、别的程序都能读，你辛苦整理的那套披萨知识不用重做一遍。这也是为什么数据量一大，很多团队宁可多花一周建本体，也不愿意继续维护一堆口径不一的表格。
反过来说，如果只是十几条数据、关系一条线、只给人看，那就先别上本体，Excel 是真的够用。工具选错比不会用更浪费时间。
2.3 先跑通第一个例子：建出你的第一个类
概念听懂了就得动手，不然过两天全忘。第一个例子不做复杂推理，只把「类」这一层建出来，目标是看到一棵能展开的树。
- 装好编辑器，启动后选择新建一个 OWL 本体，不要选 Frames 那一项。
- 在弹出的对话框里填本体 IRI，可以写成
http://example.com/pizza这样的形式，保存路径选一个自己找得到的文件夹。 - 进入 Entities 标签，左边切到 Classes 页，你会看到顶层已经有一个叫
owl:Thing的类。 - 选中
owl:Thing，点左上角的「添加子类」按钮，输入Pizza，回车。 - 重复上一步，在
owl:Thing下面再加PizzaBase和PizzaTopping两个类。 - 文件菜单里保存，后缀是
.owl。以后双击就能打开。 - 切到 OntoGraf 标签，能看到三个类围着 Thing 排开，这就是你建的第一棵类树。
每一步的白话解释：第 1 步里的 Frames 是这套软件的另一种建模方式，结构和 OWL 不一样，新手混着用会在后面推理时找不到东西，所以一开始就认准 OWL。第 2 步的 IRI 相当于本体的身份证号，随便写一个示例地址没问题，但写完之后别再改，后面引用会用到。第 4 步的owl:Thing是所有类的总根，任何类都是它的子类，所以第一个类永远加在它下面——你可以把 Thing 理解成「所有东西的集合」，披萨、饼底、配料，全都装在这个大筐里。
命名有个小规矩，第 4 步里Pizza首字母大写，多个单词连写时每个单词首字母也大写，比如PizzaTopping。这不是软件强制，是这套领域里通用的写法，和 Java 里类名的习惯一致。属性名反过来，首字母小写，写成hasTopping。个体名随意，但同一批里统一风格。你现在觉得这是小事，等本体长到几百个类、文件发给别人看的时候，命名混乱的代价会立刻显现。
2.4 命名与 Disjoint：两条一开始就该守的规矩
命名规范上面说过，这里补一句实操建议：类名用名词，属性名用动词短语。hasTopping一眼就知道是「有配料」，写成topping就得猜半天。这种小事在建前十个类时无所谓，建到第一百个时就是灾难。
Disjoint 是新手最容易漏掉的一项设置。它的意思是「互斥」：一个个体如果属于这个类，就绝不能同时属于那个类。饼底里的薄脆底和厚底，一张披萨不可能两种都是，这两个类就该设成互斥。
设置方法：在 Classes 页选中ThinAndCrispy，在右侧描述面板下半部分找到 Disjoint With 那一栏，点加号，选DeepPan。设完之后，这两个类之间会有一条虚线连接。
为什么必须设？因为推理机靠互斥关系来发现矛盾。你没有声明奶酪配料和蔬菜配料互斥，一个类同时挂在两边，推理机只会认为「这个东西挺特别，两种都算」，不会报错。声明互斥之后，同样的情况就会高亮成红色。换句话说，互斥是你给推理机划的红线，没划红线，它不会主动怀疑你。
3. 属性 Properties：让类之间长出关系
3.1 对象属性与逆属性：一个「父亲」例子讲透
类树建好之后，本体还只是一堆名字，没有任何关系。属性就是给这些名字之间连线的工具。
举个家庭例子。小明有父亲大明，这句话里的「有父亲」就是一个对象属性，左端是小明，右端是大明。现在把句子反过来读：大明有小明的什么？答案是「有儿子」。于是「有父亲」和「有儿子」构成一对互为反向的属性。本体里管这叫逆属性（Inverse Property）。你只需声明一次，之后只要写下小明有父亲大明，推理机自己就能推出大明有儿子小明。
回到披萨，hasBase和isBaseOf是一对，hasTopping和isToppingOf是一对。有个通用的换算关系值得记住：一个属性的 domain（定义域）就是它逆属性的 range（值域），反过来也成立。这句话现在看有点抽象，等 3.3 讲完 domain 和 range 就通了。
顺带说一个进阶用法：属性能建子属性。hasIngredient（有原料）是个很宽的关系，hasBase（有饼底）和hasTopping（有配料）都是它的子属性。含义是：如果这张披萨有饼底，那它当然也有原料。这层关系和类里的父子关系是一个道理，把范围收窄，推理机就多一条能用的线索。
3.2 七种属性特征，先记住三个常用的
属性除了连线，还能加「特征」，用一句话改掉它的行为。编辑器里在属性描述面板会看到一排勾选框，一共七种。新手不用全记，先记最常用的三个。
| 特征 | 含义 | 披萨/生活例子 | 容易出错的地方 |
|---|---|---|---|
| Functional 单值 | 一个个体最多只能通过该属性连到一个对象 | 一个人只有一个生母 | 不要勾给可传递属性 |
| InverseFunctional 逆单值 | 反过来也单值 | 身份证号只对应一个人 | 和 Functional 不是一回事 |
| Transitive 可传递 | 甲乙有、乙丙有，就能推出甲丙有 | 祖先关系 | 不能同时是 Functional |
| Symmetric 对称 | 甲连乙，则乙连甲 | 朋友 | 和反对称互斥 |
| Antisymmetric 反对称 | 甲连乙，则乙不能连甲 | 父子 | 别和对称一起勾 |
| Reflexive 自反 | 每个个体都和自己有该关系 | 同乡 | 少见，慎用 |
| Irreflexive 非自反 | 个体不能连自己 | 父亲不能是自己 | 常见于人物关系 |
Functional 最值得展开。你声明「有生母」是单值的，然后写下小明的生母是阿珍、小明的生母是阿美。推理机的反应不是报错，而是推出「阿珍和阿美其实是同一个人」。只有当你事先声明阿珍和阿美是不同个体，矛盾才会被标出来。这个细节很能说明本体的性格：它默认尽可能兼容你的说法，除非你明确划了不可逾越的线。
还两条硬规则记一下：属性一旦设成可传递，它的逆属性也必然可传递；可传递的属性不可能是单值的。祖先是典型的可传递而非单值关系——一个人可以有很多祖先，没法只留一个。这类规则不需要背，编辑器在做限制和推理时会暴露出冲突，你踩过一次就记住了。
3.3 Domain 和 Range：给属性划一个活动范围
Domain 和 Range 是给属性画的两道边界。Domain 说明「这条关系的左端应该是什么类」，Range 说明「右端应该是什么类」。
拿hasTopping举例：domain 设成Pizza，range 设成PizzaTopping。含义很直白——能被「有配料」连出去的那一头，是披萨；连进来的那一头，是配料。
关键要理解的是它的推理作用，而不是校验作用。假设你写了「A 有配料 B」，但没声明 A 和 B 是什么类，推理机会根据 domain 和 range 推断：A 应该属于 Pizza，B 应该属于 PizzaTopping。它在帮你补全信息，而不是拦住你。这一点和数据库的外键约束完全不同，很多从数据库转过来的人在这里翻车，以为写了范围就填不进别的东西，其实填得进，只是推理机会顺着推出一些你没说过的结论。
设置方法：选中hasTopping，右侧描述面板有 Domains 和 Ranges 两个区块，各点加号选类。
3.4 跟做：给披萨类挂上三个属性
现在把这一章的动手部分串起来，做完这四步，你的本体就有了骨架。
- 在 Object properties 页新建
hasIngredient，不设 domain 和 range，先当着通配的父属性。 - 再建
hasBase，右键把它设为hasIngredient的子属性；建hasTopping，同样设为子属性。 - 选中
hasTopping，在 Domains 里加Pizza，在 Ranges 里加PizzaTopping。 - 选中
hasBase，Domains 里加Pizza，Ranges 里加PizzaBase；再给它加一个逆属性isBaseOf，domain 和 range 反过来填。
解释一下第 1 步为什么先不设范围：父属性要做的是「通用兜底」，如果一上来就把hasIngredient的 range 限定成某个具体的类，后面它的两个子属性反而不好扩展。第 4 步给hasBase加逆属性时，你先填好正向的 domain 和 range，再建isBaseOf，然后把它的 domain 填PizzaBase、range 填Pizza——这正是 3.1 那句「domain 是逆属性的 range」的具体操作，自己动手填一遍就再也不会记混。
做完之后去 OntoGraf 看一眼，类之间应该已经连上了线。如果线是散乱的，检查是不是把 domain 和 range 填反了。
4. 推理机与限制：让本体开始自己「思考」
4.1 两棵层次树：asserted 和 inferred
前面建的东西都还只是「你写的」。推理机的价值在于算出「你没写但应该成立的」，所以要先把两棵树分清楚。
你手动摆出来的那棵叫 asserted hierarchy，断言层级。推理机算出来的那棵叫 inferred hierarchy，推断层级。启动方法是在 Reasoner 菜单里选一款推理机，然后点 Start reasoner。启动后界面上会出现带黄色或橙色边框的类，表示这些是推断出来的结果。
为什么这件事重要？因为类一多，人会算错。你建了三百个类，某一处父子关系挂错了，靠肉眼复核几乎不可能。推理机每次都从头算一遍，错了立刻红。原文有句话说得直接：没有推理机，大规模本体的健壮性和逻辑性很难保证。
还有一个实用功能是一致性检测。为了看到效果，可以先建一个故意矛盾的类：PizzaTopping下建ProbeInconsistentTopping，让它同时成为CheeseTopping和VegetableTopping的子类，前提是这两个类已经设成互斥。启动推理机，这个类会变成红色，图标高亮。把互斥去掉再点一次 Classify，红色消失。这个来回做一遍，你对「本体能查错」这件事就有体感了。
4.2 三种限制：some、only、min/max
光有关系还不够，你还得能表达「这张披萨至少有奶酪」这种带数量的说法。这就是 Property Restrictions，限制。OWL 里常用的三类：
存在限制（some）：至少有一条这样的关系。写成hasTopping some CheeseTopping，读作「至少有一种奶酪配料」。生活里的对应句子是「我至少从楼下那家店买过一袋饼干」。
全称限制（only）：凡是这条关系连出去，对象都必须是那个类的。写成hasTopping only (CheeseTopping or VegetableTopping)，读作「如果它有配料，那配料只能是奶酪或蔬菜」。注意这句话不保证有配料，它只管「有的话不能是别的」。原文那个计划用家庭的类比挺准：如果有了孩子只能有一个，但不代表一定得有孩子。
基数限制（min / max / exactly）：直接卡数量。写hasTopping min 3表示至少三种配料。注意这里没指定配料具体是什么，等价于hasTopping min 3 Thing，意思是任意三种，不管类型。要卡类型就写hasTopping exactly 4 CheeseTopping，这就是合格基数限制，限定得很死。
4.3 必要条件和充分必要条件：primitive 和 defined
这一节是整篇里最需要慢下来看的地方，也是新手最容易卡住的地方。
只写了必要条件的类，叫 primitive class。它的意思是：「如果某个东西属于这个类，那它必须满足这些条件。」注意方向。它没说「满足这些条件的东西一定属于这个类」。就像「是狗就一定有尾巴」，但「有尾巴的不一定是狗」。
把条件升级成必要条件加充分条件，就成了 defined class。这时两个方向都成立：属于这个类必然满足条件，满足条件也必然属于这个类。
这个差别在编辑器里的操作是：把类描述面板里原本写在 SubClass Of 的那条限制，剪切到 Equivalent To 那一栏。位置一换，性质就变了。
为什么这件事要命？因为你把所有类都写成 primitive，推理机算了半天，什么都不会自动归类。你以为推理机坏了，其实是自己只给了单向条件。这一点我当时也卡了一下午，后来才明白，编辑器不会提醒你写错了，它只会安安静静什么都不做。
4.4 跟做：定义一个素食披萨，看它自动归类
下面这个例子把前面的东西全串起来，做完大概十分钟。
- 在
NamedPizza下建几个具体的披萨类，比如MargheritaPizza，限制条件写成「至少有一个马苏里拉配料、至少有一个番茄配料」。 - 再建
AmericanaPizza，用克隆的方式基于上一个改，多加一条辣香肠配料。 - 建
VegetarianPizza，作为Pizza的子类。 - 给它加限制：
hasTopping only (CheeseTopping or VegetableTopping)。 - 启动推理机，点 Classify。
- 结果会发现玛格丽特和索霍没有变成素食披萨的子类，尽管它们确实只放了奶酪和蔬菜。
第 6 步是重点，千万别以为是操作错了。这是开放世界假设（Open World Assumption）在起作用，意思是：除非你明确说明某件事不存在，否则它就可能存在。你没说玛格丽特「只有」这两样配料，推理机就认为它还可以有别的配料，于是不满足「只放奶酪或蔬菜」这个条件。
解决办法是加封闭公理。在玛格丽特的hasTopping上加一条hasTopping only (MozzarellaTopping or TomatoTopping)，把它的配料清单封死。这时再说「至少有一个马苏里拉、至少有一个番茄、且只有这两类」，条件才算说全。再 Classify，玛格丽特就会出现在素食披萨下面。
同一套逻辑还能串到别处。你可以建SpicyPizza，条件是「配料里有辣的」，给辣味配料都标上辣度属性，Classify 之后美式辣肠披萨会自己跳进去。这种「我定义规则，机器去分类」的体验，是本体和其他数据工具最大的不同。
4.5 再加一条数据属性：热量
对象属性连个体，数据属性连值。拿热量举例：
- 在 Data properties 页新建
hasCalorificContentValue，把它勾成 Functional，因为一张确定的披萨热量是固定的。 - 在 Individuals 页新建个体
ExampleMargherita，类型选MargheritaPizza，给它加一条数据属性断言，类型选整数，值填 250。 - 再建
ExampleSoho，类型选SohoPizza，热量填 800。 - 建
HighCaloriePizza和LowCaloriePizza两个类，作为Pizza的子类。 - 在类表达式编辑器里给前者写
Pizza that hasCalorificContentValue some integer[>= 400]，后者用< 400。 - 把两条都拖到 Equivalent To 里变成充分必要条件。
- Classify，看成员列表。
第 5 步那个方括号是数据类型上的范围限制，写得像个数学区间，实际含义就是「热量值大于等于 400」。第 6 步如果你忘了挪到 Equivalent To，推理机照样什么都不做——和 4.3 说的是同一件事。
5. 避坑与常见问题：五个新手一定会翻车的点
5.1 类图标突然变红
现象：点完 Classify，某个类被标成红色，其他一切正常。
原因：这个类被推理成不一致（inconsistent）。常见组合是同时属于两个互斥类，或者某个单值属性被填了两个不同的值而这两个值又被声明为不同个体。
解决：先看类描述面板里的所有限制，从互斥类开始排查。把可疑的限制一条条临时删掉再 Classify，能最快定位到是哪一条闯的祸。
5.2 加了限制，Classify 之后毫无变化
现象：明明给类写了条件，推理机启动着，点 Classify，一个子类都没多出来。
原因：多半是条件写在了 SubClass Of 里，只构成必要条件。系统不会提示你，它只是安静地什么都不推导。
解决：把那条限制剪切到 Equivalent To。还不动，就检查两个地方：推理机是否真的启动了（菜单里应有停止选项），以及是否切到了 inferred 视图而不是 asserted 视图。
5.3 用了 only，结果和预期不一样
现象：给一个类写了「只放蔬菜配料」，可实际只放蔬菜的类没有被归进去。
原因：开放世界假设。only 只管「不许有别的东西」，不管「有没有东西」。缺少存在限制，机器认为这个类可能一个配料都没有。
解决：同时补上 some 条件，再用 only 把范围封死。两条合起来才是完整表达：至少有一类，且只能这几类。
5.4 打开软件后建的模型结构不对
现象：跟着教程做，别人的界面里有 Object properties，自己的建立出来的东西却有 Slots 之类的字段，或者文件打开方式一团乱。
原因：新建时选成了 Frames 编辑器。这套工具支持两种建模方式，结构和术语都不一样，两者混着学必然混乱。
解决：重新建一个，选 OWL 那一项。之前建好的 Frames 文件不能靠改后缀转换，别在这上面耗时间。
5.5 文件发给别人打不开，或者内容缺一截
现象：本体在自己机器上好好的，拷给别人打开，类少了一半，或者引用全部失效。
原因：本体开头的 IRI 没设，或者中途改过 IRI；也可能是保存时选错了格式，存成了别的序列化。
解决：新建的第一步就把 IRI 定好，之后不再动。保存时确认后缀是.owl。发给别人之前，自己关掉软件重新打开一次文件，能正常展开再发。
6. 下一步学什么：从披萨菜单走到你自己的领域
披萨例子是最好的练习场，但它终究只是练习场。接下来有三条路，按推荐顺序排。
第一条，换成你自己的领域重做一遍。别小看这一步，从披萨换成你熟悉的东西，比如公司内部的系统清单、实验室的设备分类、游戏的装备体系，你会立刻发现自己哪些地方是真懂了、哪些只是照着点。判断标准很简单：能不能不看书，独立建出三层类树加五个属性，并且让推理机正确归类一次。
第二条，补设计模式。原文里提到的 Value Partition 就是一例：它不属于任何本体语言，是一种建模范式，作用类似于编程里的设计模式。做法是建一个ValuePartition类，下面挂子类SpicinessValuePartition，再往下是Hot、Medium、Mild三个个体，然后用一条单值属性把辣度挂到配料上，最后用Hot or Medium or Mild在 Equivalent To 里做覆盖公理。这套做法能让你的分类互斥且完整，比随手建三个类规范得多。
第三条，学怎么用本体。建出来是给人看还是给程序读，决定了你下一步该学什么。想让程序读，就去了解查询语言和读写本体的编程接口；想让人看，就把 OntoGraf 和 DL Query 用熟。DL Query 尤其值得花半小时，它能让你直接问「有哪些披萨热量超过 400 且配料里没有肉」，比一层层点开类树快得多。
| 阶段 | 练什么 | 检验标准 |
|---|---|---|
| 入门 | 披萨本体完整走一遍 | 素食披萨能被自动归类 |
| 迁移 | 换成自己的领域重建 | 不看教程能独立完成类树和属性 |
| 规范 | Value Partition 等设计模式 | 分类互斥且覆盖完整 |
| 使用 | DL Query 与程序读写 | 能一条查询问出目标个体 |
最后给一个具体技巧，也是我踩过最贵的一次坑之后养成的习惯：动手之前先在纸上画。画一棵三层树，把属性用箭头标在类与类之间，箭头旁边写清 domain 和 range；再用另一种颜色标出哪几个类互斥、哪几个属性是单值。这张纸画完，打开软件基本就是照着抄，半小时能建完的东西不会拖成三小时。反过来，跳过这步直接开软件，建到一半大概率要推倒重来。
从那以后我每次新建本体，都强制自己先在纸上把类树和属性箭头画一遍，画不出来就说明还没想清楚，再回去想。希望帮到你。
本文还有配套的精品资源，点击获取
