简介：面向知识图谱与语义网入门者的 Protégé 本体构建教程，以 Protégé-OWL 编辑器为主线，帮助读者从零理解本体的作用，并完成一个可操作的领域建模实例。压缩包内包含 1 个 doc 文档，约 393KB；文档以图文讲解为主，篇幅集中、便于通读，适合作为课堂讲义或自学提纲。内容围绕 OWL 本体展开：先说明本体用于捕获领域知识，再拆解 Individuals、Properties、Classes 三要素，并借 Pizza 案例演示类命名规范、Thing 根类、Disjoint Classes 判定、subclass 继承关系，以及 Object 属性与 Datatype 属性的区别、逆属性与函数型属性的含义，最后介绍在 OWL 工具中创建类与子类的实际操作。已有 2262 人学习，可帮助读者建立规范建模思路，理解继承、互斥与属性约束等常见概念，为后续使用 Protégé 搭建自己的本体打下基础。
1. 从一张配方表开始：Protégé 本体构建到底在解决什么
接手一个配方知识库时，最麻烦的往往不是数据量，而是没人说得清“低脂”和“健康”之间到底是什么关系，各家 Excel 里的分类标准也对不上。Protégé 本体构建说到底就是把这类含糊表述写成带逻辑约束的类定义，再交给推理机替你回答。这份教程走的是 Protégé-OWL 编辑器路线，不是老的 Frames 分支，核心动作只有四个：搭类层级、配对象属性、写 Restriction、跑一致性检查，产出是一个能被推理、能导出、能被外部程序消费的.owl文件。它适合已经会画 ER 图、但没碰过描述逻辑的数据建模同学，也适合装完 Protégé 打开界面不知道先点哪里的工程师。下面按能复现的顺序走，中间会标出哪些操作看着无害、实际会把本体做废。
2. 类骨架与对象属性：把披萨领域拆成可推理的 Classes 和 Properties
示例领域用披萨，不是为了好玩，而是它天然有“整体—部分”（饼底、顶料属于披萨）和“类别—实例”（某一份披萨属于某个类）两层结构，正好覆盖本体建模最容易混的两组关系。这一章的目标是把类树和属性骨架立起来，先不管约束，让 Protégé 里有一张能看的图。
2.1 顶层类、命名约定与 IRI：动手前先把地基填了
打开 Protégé 后的第一件事不是画类，而是点开 Active ontology 面板，把 Ontology IRI 和 Default prefix 填掉。默认值通常带着本机用户名和一串临时编号，等到要导出给别人引用、或者类 IRI 被写进下游程序时再改，就得批量重写，代价很大。我一般直接定成http://example.org/pizza-onto#这种短而稳定的形式，后面的类都挂在这个前缀下。这一步在界面上不显眼，但它决定了你后面所有实体的全名，属于改一次疼一次的操作。
命名上坚持一套约定，比事后统一省事得多。类用大驼峰，属性以小写开头、动词或has/is前缀，个体用大驼峰加语义后缀，这套约定和 Java 里的类命名习惯接近，团队里没人会认错。
| 元素类型 | 命名风格 | 示例 | 说明 |
|---|---|---|---|
| Class | 大驼峰 | PizzaTopping | 单数名词，不加复数 |
| Object Property | 小写开头，动词短语 | hasTopping | 有向，读起来像一句话 |
| Data Property | 小写开头 | hasCalorificContentValue | 指向字面量，不指向个体 |
| Individual | 大驼峰 + 后缀 | ExamplePizzaA | 与类名区分开 |
类树的第一刀切在Thing下面。Thing是 OWL 内置的顶层类，表示所有个体的集合，所有类最终都是它的子类，删不掉也不用建。常见的新手动作是先造一个叫Entity或者Object的万能父类，再把所有东西塞进去，这在描述逻辑里没有任何收益，反而让后面的自动分类多出一层噪音。我建议直接按领域分三支：Pizza、PizzaBase、PizzaTopping，PizzaTopping下再分CheeseTopping、MeatTopping、VegetableTopping、SeaFoodTopping四支，每个叶子类对应一种具体食材。
# 类层级（缩进表示 subclass-of） Thing ├── Pizza │ └── NamedPizza │ ├── ClassicCheesePizza │ ├── PepperoniPizza │ ├── HotSpicyPizza │ └── OliveCheesePizza ├── PizzaBase │ ├── ThinAndCrispy │ └── DeepPan └── PizzaTopping ├── CheeseTopping（Mozzarella、Parmesan） ├── MeatTopping（Ham、Pepperoni、Salami、SpicyBeef） ├── VegetableTopping（Caper、Mushroom、Olive、Onion、Tomato…） └── SeaFoodTopping（Anchovy、Prawn、Tuna）操作路径很短：Entities 标签 → Classes 面板 → 选中Thing→ 点 Add subclass → 输入类名回车，重复即可。注意NamedPizza这一层别省，后面要区分“有名字的具体披萨”和“用条件定义出来的匿名披萨类”，没有这一层，自动分类的结果会全糊在Pizza下面。
2.2 Disjoint：省掉这一步，后面的一致性检查等于没做
Disjoint 的意思是“互斥”：如果一个个体是类 A 的实例，那它就不可能是类 B 的实例。饼底的ThinAndCrispy和DeepPan必须互斥，一份披萨不可能同时是薄底和厚底；顶料里CheeseTopping和VegetableTopping也要互斥，否则第 4 章那个故意制造矛盾的类根本造不出来。这一步的界面位置在类选中后右侧的 Description 面板，Disjoint With 那一栏点加号，把对端类选进来。
几个容易踩的细节：
- 互斥是两两的，给三个类设互斥，等于声明它们中任意两个都不能同时成立，不用手动两两加一遍（Protégé 里逐个添加即可，语义上等价）。
- 子类和父类之间不能设 Disjoint。
Mozzarella是CheeseTopping的子类，如果你把它和CheeseTopping设成互斥，Mozzarella立刻变成不可满足类，推理机一点就红。 - 多继承在本体里是合法的：一个类可以同时挂在两个父类下面，比如
HotSpicyPizza既可以属于NamedPizza，也可以属于后面定义的SpicyPizza。这本身不是问题，但如果两个父类恰好被声明为 Disjoint，这个类就会变成 unsatisfiable，而且 Protégé 不会主动弹窗告诉你，只是图标变色。
很多教程把 Disjoint 放在很后面讲，实际做下来，它是本体“能被推理”的前提之一。没有互斥声明，推理机看到的是一堆可以随意重叠的集合，一致性检查几乎永远通过，你也就永远发现不了自己写错的约束。
2.3 Object Property：domain/range 是推理公理，不是类型校验
属性这一层要建两组：hasBase/isBaseOf，hasTopping/isToppingOf，再加一个更泛的父属性hasIngredient，让hasBase和hasTopping都成为它的子属性。父属性的价值在于可以写一条通用约束覆盖所有子属性，不用对每个属性重复一遍。
Inverse 在 Protégé 里只需设一边：选中hasBase，在 Description 面板的 Inverse Of 里选isBaseOf，另一侧会自动同步，因为 OWL 里这就是一条对称的公理。domain 和 range 的填法也简单，hasTopping的 domain 填Pizza，range 填PizzaTopping。但这里有个必须讲清楚的点，否则后面一定出问题。
domain/range 在 OWL 里是推断规则，不是数据校验器。你声明了hasTopping的 domain 是Pizza，当本体里出现任何一条a hasTopping b的断言，推理机会直接推出a属于Pizza类，哪怕你原本想说的是“某个套餐包含顶料”。这不是 bug，是描述逻辑的语义。血泪经验是：领域里关系复杂时，宁可不设全局 domain/range，把约束写进具体类的表达式里，比如给Pizza加一条hasTopping some PizzaTopping，作用范围可控，也不会污染其他分支。
| 属性 | 类型 | domain | range | inverse |
|---|---|---|---|---|
hasIngredient | Object | 不设 | 不设 | isIngredientOf |
hasBase | Object | Pizza | PizzaBase | isBaseOf |
hasTopping | Object | Pizza | PizzaTopping | isToppingOf |
isBaseOf | Object | PizzaBase | Pizza | hasBase |
isToppingOf | Object | PizzaTopping | Pizza | hasTopping |
有一点原文讲得很到位：一个属性的 domain 通常就是它逆属性的 range，反过来也成立。所以设完hasTopping的 domain/range 之后，isToppingOf那一侧其实已经被隐含定义了，不需要再填一遍，填了也不会错，但要意识到这是同一条语义的两种写法。
3. 属性特征与三类 Restriction：让“至少一层奶酪”变成机器能读的约束
类树只是名词表，真正让本体有推理能力的是属性特征和类表达式。这一章把 OWL 里最容易被写错的两块拆开：七个属性特征各自约束什么，以及 some / only / hasValue / 基数限制这四种写法在语义上的差别。写完这一章，你的本体应该能表达“素食披萨只允许奶酪和蔬菜顶料”这种级别的话。
3.1 七种属性特征：选错一个，整个分支跟着歪
属性特征在选中属性后的 Characteristics 面板里勾选，勾错不会立刻报错，但会在推理阶段以奇怪的方式体现出来，属于典型的黑匣子问题。
| 特征 | 语义 | 适用场景 | 使用建议 |
|---|---|---|---|
| Functional | 给定个体最多一个值 | hasBirthMother | 一个人只有一个生母 |
| InverseFunctional | 逆属性是 Functional | hasBirthMother的逆 | 一个人可以是多人的生母 |
| Transitive | a→b、b→c 推出 a→c | hasAncestor | 不可与 Functional 同用 |
| Symmetric | a→b 推出 b→a | hasSibling | 关系可反向 |
| Asymmetric | a→b 时 b→a 不成立 | hasParent | 不能用于自身关系 |
| Reflexive | 每个个体都指向自身 | 极少用 | 会产生大量隐含三元组 |
| Irreflexive | 只能连接不同个体 | hasParent | 父子不能是同一人 |
两个互斥组合必须先记住。第一，传递属性不能同时是函数式的：如果hasAncestor是 Functional，那么 a 的祖先 b 和祖先 c 会被推成同一个人，而传递性又会不断产生新的祖先，两者叠加直接把本体推向不一致。第二，Symmetric 和 Asymmetric 不能同时声明，这是逻辑上的直接矛盾。原文里“传递属性的逆属性也应该是传递的”这条也值得记住，hasAncestor和hasDescendant要一起勾 Transitive，否则推理结果只对一半。
在披萨域里，实际用到的特征不多：hasCalorificContentValue应该是 Functional，因为一份确定的披萨热量是固定的；hasSpiciness也是 Functional，一种顶料只有一种辣度。其余的属性特征保持默认即可，功能特征不是勾得越多越专业。
3.2 三类 Restriction：some、only、hasValue 与基数
Restriction 是 OWL 描述类的核心手段，它描述的是一个匿名类——没有名字、由条件圈定的一批个体。Protégé 里通过类选中后在 Superclasses 面板点加号，选择 Class expression editor 输入表达式，或者用内置的 restriction creator 一步步选。
第一类是量词限制，分存在和全称两种：
some（存在限制）：至少有一个通过该属性的关系指向指定类。写hasTopping some CheeseTopping，表示这个披萨至少有一层奶酪。only（全称限制）：所有通过该属性的关系都必须指向指定类，但允许一个都没有。写hasTopping only (CheeseTopping or VegetableTopping)，表示如果有顶料，只能是这两类，但可以完全没有顶料。
only允许空集这一点，是新手最容易漏的。原文用计划生育做类比很贴切：政策说“最多一个”，没说“必须有一个”。所以only不能替代some，要表达“至少一层且只能是奶酪”，两个限制都得写。
第二类是基数限制，用min、max、exactly表达数量。给Pizza加一条hasTopping min 3，等价于hasTopping min 3 Thing，意思是至少三种顶料且不限定类型。想限定类型就写 qualified 形式：hasTopping exactly 4 CheeseTopping，四种顶料且全是奶酪，这个用来定义四奶酪披萨很顺手。
第三类是hasValue，指向一个具体个体而不是一个类。比如给Mozzarella加hasCountryOfOrigin value OriginA，表示这种奶酪的产地就是那一个个体。它和some的区别在于：some的对象是一个类下的任意个体，hasValue锁定到一个指名道姓的个体。
# 用类表达式编辑器输入的写法（每条对应一个 Superclasses 条目） Pizza and hasBase some PizzaBase # 至少有一个饼底 Pizza and hasTopping some CheeseTopping # 至少一层奶酪 Pizza and hasTopping min 3 # 至少三种顶料，不限类型 Pizza and hasTopping exactly 4 CheeseTopping # 恰好四种奶酪顶料 Mozzarella and hasCountryOfOrigin value OriginA # 产地锁定到某个个体最后一行还牵扯到一个独立知识点：枚举类。把OriginRegion类选中，在 Equivalent To 里输入{OriginA, OriginB, OriginC, OriginD}，表示这个类的外延恰好是这四个个体，没有第五个。它常和hasValue配合使用，把“产地只能是这四个之一”这件事写死。
3.3 primitive 与 defined：必要条件写在 Superclasses，充要条件才进 Equivalent To
这是 Protégé 里最关键也最容易忽略的一个面板划分。Superclasses 里写的是必要条件：如果某个体属于这个类，那么它必须满足这些条件。但反过来不成立——满足条件的不一定被归进这个类。只有把表达式放进 Equivalent To，才构成充要条件，这个类才叫做 defined class，推理机才会主动把符合条件的个体或子类归到它下面。
只写了必要条件的类叫 primitive class，图标和 defined class 在 Protégé 里有区别，一眼能看出来。很多人的困惑“我明明定义了素食披萨，为什么自动分类之后什么都没变”，根子就在这里：条件写在 Superclasses 里，推理机只拿它做检查，不做归类。操作上就是把 Superclasses 里那条表达式剪切到 Equivalent To 面板，再重新 Classify。
必要条件可以有多条，累加即可；充要条件一般只写一条组合表达式，写成A and B and C的形式。这两者的取舍标准很实际：如果你希望推理机帮你发现“某个类定义错了”，用必要条件；如果你希望推理机帮你把新类自动挂到正确位置，必须用充要条件。
3.4 Datatype Property：把热量值变成可分类的条件
对象属性连接个体与个体，数据类型属性连接个体与字面量。建一个hasCalorificContentValue，range 设为xsd:integer，并在 Characteristics 里勾上 Functional。然后建两个个体ExamplePizzaA和ExamplePizzaB，类型分别指向两个具体披萨类，再各加一条 Data Property assertion，值填 250 和 800。
有了数据，就能用数据范围写类定义。给HighCaloriePizza设 Equivalent To：Pizza and hasCalorificContentValue some xsd:integer[>= 400]，LowCaloriePizza用< 400。这里的方括号是数据范围语法，写在类表达式编辑器里，不是正则也不是伪代码。Classify 之后，ExamplePizzaB会自动出现在HighCaloriePizza下面，因为它满足充要条件。
顺手提一句：所有披萨都有热量值这件事，用一条Pizza and hasCalorificContentValue some xsd:integer表达即可，它保证每个披萨至少有一个整型热量值，但不限制具体数值。数据属性设成 Functional 之后，如果同一个个体被断言了两个不同的热量值，一致性检查会直接报不一致，这比在应用层写校验规则可靠得多。
4. 推理机实战：一致性检查、自动分类与 OWA 的两个反直觉结论
前面三章建的是“断言层级”，也就是你手动敲进去的结构。推理机负责算出“推断层级”，两套层级叠在一起才是本体的完整视图。这一章的三个动作建议按顺序做一遍：先启动推理机看两套层级，再故意造一个矛盾类验证它真在工作，最后用开放世界假设解释一次“为什么明明定义了却不归类”。
4.1 启动推理机与两套层级
Protégé 的 Reasoner 菜单里可以选推理机，随附的通常是 Fact++，也有 HermiT、Pellet、ELK 等可选。选中之后点 Start reasoner，界面不会有明显变化，只是类名旁边多了推断出来的父子关系，或者在类面板里出现推断出的高亮。原文把这两套层级分得很清楚：手动构造的叫 asserted hierarchy，推理机算出来的叫 inferred hierarchy。
实际操作中，我习惯先看一眼有没有红色的类，再看Thing下面有没有意外多出来的分支。红色代表 unsatisfiable，即这个类不可能有实例，通常意味着约束写矛盾了。这一步不需要任何额外配置，属于每次改完本体都该跑一遍的固定动作。
推理机的选择上有个经验：Fact++ 快，但在某些运行环境下启动会直接失败或者卡住；HermiT 稳，对 OWL 2 的支持也更完整，缺点是本体规模大时慢一些。做教学示例和小规模本体，两者差别不大；真到成百上千个类的时候，先拿 HermiT 跑通逻辑，再换快的做迭代。
4.2 一致性检查：造一个矛盾类试试
验证推理机是否真的在干活，最直接的办法是故意制造一个不可能成立的类。建一个ProbeInconsistentTopping，让它同时是CheeseTopping和VegetableTopping的子类，而这两个类在第 2 章已经设成 Disjoint。Classify 之后，这个类会被标红，因为它要求一个个体同时属于两个互斥的类。
# 制造矛盾：两个父类互斥，子类不可能有实例 ProbeInconsistentTopping SubClassOf: CheeseTopping SubClassOf: VegetableTopping看到红色之后，把CheeseTopping和VegetableTopping之间的 Disjoint 声明删掉，再 Classify，红色消失。这一删一加，是本体验证推理链路是否通畅最快的办法，比读十页文档有效。验证完记得把探测类删掉，否则它会一直挂在本体里，下游工具读到会困惑。
4.3 开放世界假设：为什么“只有奶酪和蔬菜”的披萨没被归类
这是全篇最反直觉的一段。定义一个VegetarianPizza，Equivalent To 写Pizza and hasTopping only (CheeseTopping or VegetableTopping)，再把ClassicCheesePizza和OliveCheesePizza定义成有奶酪顶料、有蔬菜顶料的具体类。按直觉，它们该被归进VegetarianPizza，但 Classify 之后什么都没有发生。
原因在开放世界假设（OWA）：除非本体里明确声明“不存在其他顶料”，否则推理机认为可能还有未声明的顶料。你只说了“至少有一层奶酪、至少有一层蔬菜”，没说“没有别的”，所以它不能断定这两个类满足only条件。这和数据库的封闭世界假设正好相反，也是做过关系库的人转过来最容易翻车的地方。
解决办法是封闭公理：显式声明顶料的全部可能范围。给ClassicCheesePizza加一条hasTopping only (MozzarellaTopping or TomatoTopping)，等于告诉推理机“除了这两类，不可能有别的顶料”。加上之后重新 Classify，它才会被归到VegetarianPizza下面。这个操作在原文里叫 closure axiom，实际项目里我一般写成“在叶子类上一次性写全 only 列表”，而不是在父类上写，避免继承下来把子类的可能性也封死。
顺带一个同样基于 OWA 的现象：建一个NonVegetarianPizza，定义为Pizza and not VegetarianPizza，再建一个UnclosedPizza，只写hasTopping some MozzarellaTopping而没有任何封闭公理。Classify 之后你会发现这个类既不在素食分支，也不在非素食分支——因为推理机无法确定它到底是不是素食。这不是推理机坏了，是信息不足，属于合格建模者应该能解释清楚的行为。
4.4 Value Partition：用枚举类 + 覆盖公理管住取值范围
辣度这种东西特别适合用设计模式处理，而不是散落在各个类里写死。做法是：在Thing下建一个ValuePartition类，其下建SpicinessValuePartition，再往下建Hot、Medium、Mild三个互斥子类。然后给SpicinessValuePartition的 Equivalent To 写{Hot, Medium, Mild}或者Hot or Medium or Mild，这就是覆盖公理，表示辣度取值不会超出这三种。
配合对象属性hasSpiciness（勾 Functional），就可以给PepperTopping及其子类统一加必要条件hasSpiciness some Hot，再定义SpicyPizza为Pizza and hasTopping some (PizzaTopping and hasSpiciness some Hot)。这里括号里的部分描述的是一个匿名类：既是顶料、又特别辣。Classify 之后，带辣味顶料的披萨会自动归到SpicyPizza，不需要手工维护继承关系。
Value Partition 不属于 OWL 语言本身，它是建模经验沉淀下来的模式，类似面向对象里的设计模式。它的价值在于“取值封闭 + 互斥”，两者一起写，才能在推理阶段真的把范围管住；只写枚举不写互斥，Hot和Mild依然可以同时成立，分类结果就没有意义。
5. 避坑排查：五个让本体白做的操作及修复路径
这一章按“现象 → 原因 → 解决”列，每条都是我实际改别人本体时遇到过的。
现象一：定义好的类在 Classify 之后没有归到任何位置，推理机也不报错。原因：条件全部写在 Superclasses 面板，类还是 primitive class，推理机只把它当检查条件，不当分类依据。 解决：确认类图标是否为 defined。把核心表达式剪切到 Equivalent To 面板，重新 Start reasoner。判断标准很简单——只有写了充要条件的类才会被自动归位，必要条件写得再多也不会。
现象二：给hasTopping设了 domain 之后，一堆本来不相干的类跑到了Pizza下面。原因：domain/range 是推断公理，任何带这条属性的个体都会被推出属于 domain 类，属于“推理污染”，不是配置错误。 解决：删掉全局 domain/range，改成在具体类的表达式里写hasTopping some PizzaTopping；如果必须保留全局声明，就要接受推断结果并重新整理类树，别在推断层级上手工覆盖。
现象三：素食披萨定义得没问题，具体披萨就是不归类。原因：开放世界假设，没有封闭公理，推理机认为还可能存在未声明的顶料。 解决：在叶子类上加hasTopping only (...)把范围封死，或者在通用父类上写全 only 列表。改完一定要重新 Classify，只看 asserted 层级看不出变化。
现象四：点 Start reasoner 之后界面卡死或者直接报错退出。原因：推理机二进制与当前运行环境不匹配，或者本体引用了外部 ontology、规模超出默认堆内存。 解决：换 HermiT 先跑通；在启动参数里加大堆内存（-Xmx调到 2g 以上再试）；检查 Active ontology 里的 Imports 有没有拉进不需要的外部本体，先把 imports 清空再逐个加回来定位。
现象五：两个属性特征组合之后，整个本体变成 inconsistent。原因：Transitive + Functional 同时勾选，会让传递链上的多个个体被推成同一个；Symmetric + Asymmetric 同时声明则是直接矛盾。 解决：传递属性只用于祖先、包含这类层级关系，需要唯一值时改用逆属性上的 InverseFunctional；对称与非对称二选一，拿不准就不勾。
6. 交付前用 DL Query 做回归：一份能反复跑的验收动作
本体做完不是看一眼类树就算完。改一个 Restriction 可能连带影响十几个类的归类结果，靠肉眼比对不现实。Protégé 自带的 DL Query 面板可以当轻量回归测试用：它接受类表达式，返回满足条件的个体和子类，改完约束点一下 Execute，结果变了就说明有回归。
我一般固定存四条查询，覆盖四类语义：
| 查询表达式 | 预期结果 | 验证的能力 |
|---|---|---|
hasTopping some CheeseTopping | 所有含奶酪的披萨 | 存在限制是否生效 |
hasTopping only (CheeseTopping or VegetableTopping) | 封闭后的素食类 | 全称限制与封闭公理 |
hasCalorificContentValue some xsd:integer[>= 400] | 高热量披萨 | 数据范围限制 |
hasTopping exactly 4 CheeseTopping | 四奶酪披萨 | 受限基数限制 |
执行时把 Instances 勾上，返回的是个体列表；把 Subclasses 勾上，返回的是被推断出来的子类。改完任意一条 Restriction，四条一起重跑，哪条结果集缩水或膨胀了，问题就定位在对应那块。这套动作做熟之后，一次完整回归不到一分钟，比重新读一遍类树靠谱得多。
还有一个容易被忽略的收尾动作：导出前检查一遍 IRI 是否稳定、有没有留下探测用的临时类、ProbeInconsistentTopping之类的验证类是否清干净。本体文件和代码一样，会被人引用、被下游程序解析，留下脏数据比留个 TODO 麻烦得多。
从那以后我每次交付本体前，都会把这四条 DL Query 连同封闭公理一起跑一遍，再把推理机关掉、重新打开一次确认结果可复现——推断层级依赖推理机，不同推理机对同一本体的分类结果偶尔会有细微差异，这件事吃过一次亏就记住了。希望帮到你。
本文还有配套的精品资源，点击获取
