很多人第一次使用 Protégé 做 Ontology，前几个小时通常非常顺。
先建几个 Class：
Person
Employee
Department
Project
Skill
再建几个 Property：
worksAt
belongsTo
hasSkill
worksOn
然后创建 Individual：
张三
李四
研发部
支付系统
Go
Redis
整个图看起来非常漂亮：
张三
├── belongsTo → 研发部
├── worksOn → 支付系统
├── hasSkill → Go
└── hasSkill → Redis
于是你开始继续扩展。
很快变成：
Employee
BackendEmployee
BackendEngineer
BackendDeveloper
JavaBackendEngineer
SeniorJavaBackendEngineer
JavaDeveloper
Programmer
Developer
TechnicalEmployee
ITEmployee
...
然后 Property 也开始失控：
worksAt
workAt
worksFor
employedBy
belongsToCompany
hasCompany
companyOf
...
半年以后，你打开 Protégé：
这个 Class 到底是谁建的？
worksAt和employedBy有什么区别？Employee 为什么同时是 Person、Staff、Worker、Member？
Department 到底应该是 Class，还是 Individual？
这就是 Ontology 项目非常常见的问题：
不是不会建，而是越建越乱。
今天我们就用 Protégé，重点讲几个真正决定 Ontology 质量的概念：
Class 层级
建模边界
Domain
Range
Disjoint
Equivalent Class
ObjectProperty
Individual
目标不是做一个“看起来很复杂”的知识图谱。
而是做一个：
能长期维护的 Ontology。
项目：
https://github.com/protegeproject/protege
Protégé 本身是开源 OWL Ontology 编辑器，支持 OWL 2，可以可视化编辑 Class、Property、Individual、Domain、Range、Disjoint 等本体结构。
一、先解决第一个问题：Class 到底是什么？
很多程序员第一次建 Ontology，会把 Class 理解成：
数据库表
例如数据库：
employee
department
project
于是 Ontology：
Employee
Department
Project
好像没问题。
但这个理解只能算：
一半正确。
Ontology 的 Class 更准确地说，是：
对一类现实世界对象的“概念定义”。
比如：
Person
代表：
人这一类对象。
Employee
代表：
员工这一类人。
BackendEngineer
代表：
后端工程师这一类员工。
所以 Class 最重要的不是：
存什么字段？
而是：
它描述的是哪一种概念？
二、Class 和 Individual 千万别混
例如：
Department
一般应该是：
Class。
而：
研发部
产品部
财务部
一般是：
Individual。
也就是：
Department
├── 研发部
├── 产品部
└── 财务部
而不是：
Department
├── RDDepartment Class
├── ProductDepartment Class
└── FinanceDepartment Class
除非你的业务中：
研发部门
本身代表一种可进一步实例化的部门类型。
三、一个非常实用的判断方式
问自己一句：
这个东西以后还会不会有多个具体实例？
如果答案是：
会。
通常适合 Class。
比如：
Employee
可以有：
张三
李四
王五
所以 Employee 是 Class。
如果某个东西本身就是：
现实世界中的具体对象
通常适合 Individual。
例如：
北京研发中心
一般就是一个具体组织。
所以应该：
BeijingRDCenter
rdf:type
Department
而不是一定再建一个：
BeijingRDCenter Class
四、最容易犯的错误：把值做成 Class
比如数据库字段：
status
有：
ACTIVE
DISABLED
LEAVE
很多人会建：
Employee
├── ActiveEmployee
├── DisabledEmployee
└── LeaveEmployee
是不是一定错？
不一定。
但首先应该问：
“状态”真的代表一种稳定的概念分类吗？
如果它只是：
业务状态字段
那可能更适合：
DataProperty
例如：
Employee
→ status
→ "ACTIVE"
或者状态建成 Individual：
Employee
→ hasStatus
→ ActiveStatus
而不是疯狂增加 Class。
五、Class 不要复制数据库字段
假设 employee 表：
employee
----------------
id
name
age
status
level
department_id
type
很多人会机械映射：
Employee
Age
Status
Level
Department
EmployeeType
甚至：
Age28
StatusActive
LevelSenior
全部建 Class。
最后 Ontology 就变成：
数据库字段的可视化版本。
这不是 Ontology 最擅长的事情。
Ontology 更应该回答：
什么是员工？
员工和部门是什么关系？
后端工程师是不是员工？
技术负责人和项目有什么关系？
一个部门是不是组织单元？
某种关系是否具有传递性？
也就是：
概念和语义。
六、Class 层级应该表示“is-a”
判断一个 SubClass 是否合理，有一个特别简单的方法：
把它读成一句话：
A is a B
如果成立，继承通常合理。
例如：
BackendEngineer
is a
Employee
合理。
所以：
Employee
└── BackendEngineer
没问题。
再比如：
Employee
is a
Person
也合理。
所以：
Person
└── Employee
└── BackendEngineer
这就是清晰的层级。
七、错误例子：研发部不是 Employee 的子类
有人可能建：
Employee
├── BackendEngineer
├── FrontendEngineer
└── RDDepartment
读一下：
研发部 is a Employee
显然不成立。
研发部应该：
rdf:type Department
然后通过关系：
BackendEngineer
→ belongsTo
→ Department
连接。
八、再举一个典型错误：Go 不应该是 Engineer 子类
错误：
Engineer
├── Java
├── Go
└── Python
读：
Go is an Engineer
显然不对。
更加合理：
Employee
└── Engineer
Skill
└── ProgrammingLanguage
├── Go
├── Java
└── Python
注意：
如果：
Go
Java
Python
是具体语言，
它们还可以直接是：
ProgrammingLanguage
的 Individual。
例如：
Go
rdf:type
ProgrammingLanguage
是否做成 Class，要看你还需不需要继续实例化它。
九、不要为了“树好看”而滥用继承
很多 Protégé 用户特别喜欢把 Class Tree 建得很深：
Thing
└── Entity
└── HumanEntity
└── Person
└── Worker
└── Employee
└── TechnicalEmployee
└── Developer
└── BackendDeveloper
└── JavaBackendDeveloper
看起来很专业。
但真正查询：
张三是什么？
可能得到十层类型。
维护起来非常痛苦。
Class Hierarchy 应该：
尽量表达真正稳定、重要的语义。
而不是为了：
分类越细越高级。
十、我更推荐“浅层 Class + 丰富关系”
例如不要：
SeniorJavaBackendEngineer
直接做成 Class。
可以拆：
张三
rdf:type
BackendEngineer
以及：
张三
hasSkill
Java
再：
张三
hasLevel
Senior
这样比：
SeniorJavaBackendEngineer
更灵活。
为什么？
因为以后还有：
SeniorGoBackendEngineer
SeniorPythonBackendEngineer
JuniorJavaBackendEngineer
如果全部组合成 Class：
技能 × 职级 × 职位 × 部门
Class 会发生：
组合爆炸。
十一、避免 Class 组合爆炸
假设：
职位：3 种
语言：5 种
职级：4 种
如果全部组合：
3 × 5 × 4
=
60 个 Class
例如：
SeniorJavaBackendEngineer
JuniorJavaBackendEngineer
SeniorGoBackendEngineer
MiddlePythonFrontendEngineer
...
完全没必要。
更合理：
Employee
rdf:type
BackendEngineer
Employee
hasSkill
Java
Employee
hasLevel
Senior
用：
多个维度的关系组合。
十二、那什么时候值得创建一个专门 Class？
比如：
GoEngineer
是不是也不应该建？
要看业务。
如果：
GoEngineer
是你系统里经常需要：
查询
推理
授权
规则判断
的核心概念，
可以定义为：
GoEngineer
EquivalentTo
Employee
AND
hasSkill value Go
也就是说：
不手工维护。
而让 Reasoner 自动分类。
这比：
手工给每个人打 GoEngineer 标签
更合理。
十三、Equivalent Class 是解决“派生分类”的好办法
例如定义：
GoEngineer
=
Employee
AND
hasSkill Go
在 Manchester Syntax 中概念上：
Employee
and
hasSkill value Go
那么：
张三
rdf:type Employee
张三
hasSkill Go
Reasoner 可以推出：
张三
rdf:type GoEngineer
这样：
GoEngineer
是：
规则定义出来的概念。
而不是数据库里人工保存的标签。
十四、第二个核心问题：Property 到底怎么命名？
一个 Ontology 很容易出现：
worksAt
workFor
worksFor
employedBy
belongsCompany
companyOfEmployee
这些关系意思极其接近。
最后没人知道该用哪个。
所以 Property 命名最好遵循：
一个概念，一套稳定词汇。
例如员工和公司：
worksFor
反向：
employs
员工与部门：
belongsToDepartment
反向：
hasEmployee
员工和技能：
hasSkill
技能和员工：
如果确实需要：
skillOf
十五、Property 名字应该像“动词”
Class 更像名词：
Employee
Department
Project
Skill
ObjectProperty：
worksFor
belongsTo
hasSkill
usesDatabase
dependsOn
maintains
owns
这会让 Triple 非常自然：
张三
worksFor
A公司
而不是：
张三
employeeCompanyRelation
A公司
尽量让：
Triple 本身能读成一句话。
十六、Domain 和 Range 到底干什么？
假设定义：
worksFor
Domain：
Employee
Range：
Organization
结构：
Employee
│
│ worksFor
↓
Organization
在 Protégé 里可以设置：
Object Property:
worksFor
Domain:
Employee
Range:
Organization
看起来很像：
数据库字段类型。
但需要特别注意：
OWL 的 Domain / Range 不只是“校验”。
十七、这是新手最容易误解的地方
假设：
worksFor
Domain Employee
现在你写：
张三
worksFor
A公司
但没有明确告诉系统：
张三 rdf:type Employee
OWL Reasoner 可能根据 Domain 推出：
张三
rdf:type
Employee
也就是说：
Domain 是推理规则。
不是单纯：
非 Employee 就禁止使用 worksFor。
十八、Range 也是一样
如果：
worksFor
Range Organization
数据：
张三
worksFor
A公司
没有显式写：
A公司
rdf:type Organization
Reasoner 可以推：
A公司
rdf:type
Organization
因此：
Domain / Range
本质上是在告诉系统：
如果出现这种关系，关系两边应该属于什么概念。
十九、Domain/Range 不是 SHACL 验证
这一点一定要和上一篇 pySHACL 区分。
OWL：
worksFor
Domain Employee
发现：
Cat
worksFor
Company
不一定直接告诉你：
Validation Failed。
反而可能推出：
Cat
rdf:type Employee
然后如果：
Cat
又被声明和 Employee：
Disjoint
才可能产生逻辑冲突。
所以：
Domain / Range ≠ 数据校验。
严格数据验证：
谁允许使用 Property？
还是：
SHACL
更合适。
二十、Domain 不要定义得太窄
假设：
hasName
Domain 写：
Employee
后来：
Department
也有 name。
如果你写：
研发部
hasName
"研发部"
Reasoner 可能推出：
研发部
rdf:type
Employee
这显然很荒谬。
原因就是：
hasName 的 Domain 定得太窄。
二十一、hasName 应该怎么办？
可以把 Domain 定得更通用：
Entity
或者：
NamedEntity
也可以：
不设置 Domain。
不要觉得：
每个 Property 必须写 Domain 和 Range。
Ontology 设计里：
不确定时，宁可少约束，也不要错误约束。
错误的语义规则比没有规则更危险。
二十二、多个 Domain 不是“或者”
这又是一个非常容易踩坑的地方。
如果 Property：
hasCode
Domain 同时填写：
Employee
Department
很多人以为意思是：
Employee OR Department
都能使用。
实际上 OWL 的多个 Domain 更接近：
Employee AND Department
也就是说：
只要使用：
hasCode
就可能推出 Subject：
既是 Employee
又是 Department
这通常不是你想要的。
二十三、如果希望 Employee 或 Department 都能用怎么办？
第一种：
建共同父类：
BusinessEntity
├── Employee
└── Department
然后：
hasCode
Domain BusinessEntity
更加合理。
第二种：
如果语义不同，
直接拆成：
employeeCode
departmentCode
两个 DataProperty。
不要为了：
复用 Property
把语义做坏。
二十四、Range 也有同样问题
如果：
relatedTo
Range：
Project
Department
不是简单表示：
Project OR Department。
所以多个 Range 也要谨慎。
本体建模不是：
把所有可能类型都勾上。
而是：
精确定义语义。
二十五、第三个核心：Disjoint Classes
这个功能特别重要，
但很多新手完全不用。
假设：
Person
和：
Department
现实上明显不是同一种东西。
可以：
DisjointClasses(
Person,
Department
)
意思：
一个 Individual 不应该同时属于 Person 和 Department。
二十六、为什么 Disjoint 很有价值？
假设 Mapping 或数据错误：
张三
rdf:type
Person
同时：
张三
rdf:type
Department
如果没有 Disjoint：
Reasoner
可能觉得：
没问题。
因为 OWL 允许一个 Individual 属于多个 Class。
但现实业务：
张三
不可能既是：
人
又是：
部门。
加入：
Person disjointWith Department
Reasoner 就能发现：
Ontology Inconsistent。
二十七、Disjoint 是一种非常强的“常识”
例如：
Person
Organization
Project
Technology
这些顶层概念，
很多时候可以设计成互斥。
例如：
Person
disjointWith
Organization
Project
disjointWith
Person
这样一旦数据分类错：
Reasoner
更容易发现。
二十八、但 Disjoint 也不能乱加
比如：
Employee
和：
Manager
千万不要因为：
Class 名字不同
就设置 Disjoint。
因为：
Manager
完全可能也是：
Employee。
甚至更合理：
Manager
SubClassOf
Employee
二十九、BackendEngineer 和 Manager 能不能 Disjoint？
也不一定。
一个人完全可能：
既是 BackendEngineer
又是 Manager
例如：
技术经理。
所以 Ontology 建模必须基于：
现实世界语义。
而不是：
界面里的树形结构。
三十、多继承本身是正常的
数据库程序员有时不喜欢：
一个对象多个 Class。
但 Ontology 里很常见。
例如张三：
rdf:type Employee
同时：
rdf:type BackendEngineer
还可能：
rdf:type Manager
再：
rdf:type GoEngineer
这些身份可以同时存在。
Ontology：
不是 Java 单继承体系。
三十一、Class Tree 只是展示方式
比如：
BackendEngineer
SubClassOf Employee
Manager
SubClassOf Employee
张三可以：
rdf:type BackendEngineer
rdf:type Manager
这完全没问题。
最终：
张三
├── Employee
├── BackendEngineer
└── Manager
符合真实世界。
三十二、第四个核心：不要把角色和人混为一类
例如：
ProjectManager
这个 Class 到底表示：
一种人
还是：
一个人在某个项目中的角色？
这需要特别小心。
因为现实中：
张三
可能在：
项目 A
是 ProjectManager，
但在：
项目 B
只是 Developer。
如果直接：
张三 rdf:type ProjectManager
就丢失了：
“在哪个项目里是这个角色”
这个上下文。
三十三、这种场景要考虑 Relation Entity
例如建立：
ProjectMembership
实体。
结构：
张三
↓
hasMembership
↓
Membership-001
├── project → Project-A
└── role → ProjectManager
这样就能表达：
张三在 Project-A 中担任 ProjectManager。
同时：
Membership-002
├── project → Project-B
└── role → Developer
更加准确。
三十四、什么时候需要把关系“实体化”？
普通关系：
Employee
→ worksOn
→ Project
如果只需要：
谁参与哪个项目
足够。
但如果关系本身还需要：
加入时间
退出时间
角色
投入比例
状态
来源
那这条关系已经有自己的属性。
这时候可以考虑：
Reification / Relation Entity。
三十五、例如员工项目关系
数据库里通常有：
employee_project
----------------
employee_id
project_id
role
join_time
allocation
如果直接：
张三
worksOn
支付系统
会丢：
role
join_time
allocation
所以建：
ProjectParticipation
更合理。
三十六、结构变成
张三
↓ participatesIn
Participation-001
Participation：
project
→ 支付系统
role
→ BackendDeveloper
joinDate
→ 2026-01-01
allocation
→ 80%
这样关系本身也能拥有信息。
这对：
审计
时序
来源
都更好。
三十七、这和 Graphiti 的 Temporal Edge 是同一个问题方向
前面我们讲：
Graphiti
会给 Fact 增加：
valid_at
invalid_at
本质上也是因为：
一条 Relationship 本身有自己的上下文。
比如：
张三
worksAt
A公司
还需要：
什么时候开始？
什么时候结束？
来源是什么？
所以很多真实知识图谱都会遇到：
“Edge 也需要属性”
这个问题。
三十八、第五个核心：不要把所有信息都做 ObjectProperty
假设 Employee 有：
姓名
年龄
邮箱
简介
如果全部建 Entity：
张三
→ hasAge
→ Age28Entity
张三
→ hasEmail
→ EmailEntity001
就会过度建模。
通常：
name
age
email
更适合：
DataProperty。
例如：
张三
→ name
→ "张三"
张三
→ age
→ 28
三十九、什么时候用 ObjectProperty？
当 Object：
本身值得成为一个独立可连接实体。
例如：
Department
Project
Skill
Company
Database
Technology
Person
所以：
张三
hasSkill
Go
适合 ObjectProperty。
因为 Go 本身还有：
creator
releaseDate
paradigm
website
relatedTechnology
等信息。
四十、什么时候用 DataProperty？
如果值本身只是：
Literal
例如：
姓名
年龄
邮箱
金额
日期
布尔值
通常：
DataProperty
更合适。
可以用一个简单判断：
我以后会不会围绕这个 Object 再连接其他知识？
如果不会：
Literal
往往足够。
四十一、比如城市应该是 String 还是 Entity？
这就要看场景。
简单 CRM：
city = "北京"
DataProperty 就够。
但地理知识图谱：
北京
可能有：
属于中国
面积
人口
下辖行政区
经纬度
那么北京应该：
Entity。
所以：
Ontology 没有绝对正确的细粒度。
取决于：
你的问题是什么。
四十二、这引出最重要的建模原则：Competency Questions
在真正开始建 Ontology 前，
先别打开 Protégé。
先写：
Competency Questions。
也就是：
这个知识模型最终应该回答什么问题？
例如员工知识图谱：
1. 张三属于哪个部门？
2. 哪些员工会 Go？
3. 一个项目有哪些负责人？
4. 某个数据库由谁维护？
5. 哪些系统依赖 Redis？
6. 张三以前在哪个项目工作过？
7. 当前研发部负责人是谁？
这些问题：
决定你的 Ontology 应该建什么。
四十三、不要“先建世界，再找问题”
这是新手非常容易走反的方向。
错误：
我想建一个完整的企业 Ontology。
然后：
员工
部门
办公楼
工位
电脑
鼠标
IP
操作系统
项目
技能
学历
家庭
城市
国家
天气
……
无限扩张。
最后：
什么都有。
但：
谁也不知道有什么用。
更合理：
从问题反推模型。
四十四、例如问题：“哪些员工会 Go？”
至少需要：
Employee
Skill
hasSkill
即可。
没有必要立刻建：
Country
Office
Laptop
四十五、问题：“张三的部门负责人是谁？”
需要：
Employee
Department
belongsTo
hasManager
可能结构：
张三
↓ belongsTo
研发部
↓ hasManager
李四
这就够。
四十六、问题：“支付系统数据库谁维护？”
需要：
SoftwareSystem
Database
Employee
usesDatabase
maintains
图：
支付系统
↓ usesDatabase
PostgreSQL
↑ maintains
李四
Ontology 应该服务这些查询。
四十七、这和 API 设计其实很像
程序员设计 API 时不会说：
先把世界所有接口都设计出来。
而是：
根据业务场景
设计所需接口。
Ontology 一样。
先有：
Query / Use Case
再有：
Ontology。
这个思维会让模型简单很多。
四十八、一个推荐的企业顶层模型
不要一开始几十层。
可以先：
Thing
│
├── Person
│
├── Organization
│
├── OrganizationalUnit
│
├── Project
│
├── SoftwareSystem
│
├── Technology
│
├── Document
│
└── Location
这已经可以覆盖大量场景。
然后逐步细化。
四十九、Person 下再细分
例如：
Person
└── Employee
然后真正有价值时：
Employee
├── Engineer
├── Manager
└── ProductManager
再：
Engineer
├── BackendEngineer
└── FrontendEngineer
不用一次性建 100 个。
五十、Technology 也可以这样
Technology
│
├── ProgrammingLanguage
│
├── Database
│
├── Middleware
└── CloudTechnology
具体：
Go
可以作为：
ProgrammingLanguage
Individual。
PostgreSQL：
Database
Individual。
Redis：
到底：
Database
还是：
Middleware
甚至多个类型，
取决于你的业务语义。
五十一、一个 Individual 可以属于多个 Class
例如：
Redis
可以：
rdf:type
Database
也可以：
rdf:type
CacheTechnology
如果你的模型需要。
Ontology 不要求：
每个东西只能属于一类。
这是图语义的优势。
五十二、Disjoint 可以帮你守住真正的边界
例如顶层：
Person
Organization
Project
Technology
如果确定它们互斥，
可以添加：
DisjointClasses
这样如果：
PostgreSQL
rdf:type Person
同时：
rdf:type Technology
就能暴露错误。
五十三、但不要把所有兄弟 Class 都自动 Disjoint
例如：
Engineer
Manager
并不一定互斥。
BackendEngineer
GoEngineer
更不互斥。
一个人：
可以同时满足。
所以：
Disjoint 表达的是现实约束，不是 UI 分组。
五十四、Protégé 中建议经常跑 Reasoner
建模过程中不要等到最后才运行。
每完成一块：
Class
Property
Domain / Range
Disjoint
Equivalent Class
就跑：
Reasoner
看看：
有没有意外 Class 推断
有没有不一致
有没有奇怪类型
例如你发现：
研发部
突然被推成：
Employee
第一反应应该检查：
Domain / Range。
很可能某个 Property 定义错了。
五十五、Reasoner 可以当成“Ontology 单元测试”
比如预期：
张三
hasSkill Go
然后：
GoEngineer
EquivalentTo
Employee and hasSkill value Go
运行 Reasoner。
应该看到：
张三
rdf:type
GoEngineer
如果没有：
模型可能有问题。
五十六、再建立几个测试 Individual
一个好办法：
在 Ontology 开发期准备：
TestZhangSan
TestDepartment
TestProject
TestSkill
给一些典型关系：
TestZhangSan
belongsTo
RDDepartment
TestZhangSan
hasSkill
Go
然后跑 Reasoner。
看是否得到：
预期推理。
这和软件：
Unit Test
非常像。
五十七、Ontology 和 SHACL 应该配合
Protégé / OWL：
负责：
Class
Hierarchy
Property Semantic
Inverse
Transitive
Equivalent
Disjoint
SHACL：
负责：
name 必须存在
employeeCode 只能一个
邮箱格式
年龄范围
hasSkill 至少一个
也就是：
OWL
负责世界规则
SHACL
负责数据规则
这两个一起用，模型会清晰很多。
五十八、举一个完整 Employee 模型
Class：
Person
└── Employee
├── Engineer
│ ├── BackendEngineer
│ └── FrontendEngineer
└── Manager
组织：
Organization
└── Company
OrganizationalUnit
└── Department
技术：
Technology
├── ProgrammingLanguage
├── Database
└── Middleware
项目：
Project
五十九、ObjectProperty
Employee
→ worksFor
→ Company
Employee
→ belongsTo
→ Department
Employee
→ hasSkill
→ Technology
Employee
→ worksOn
→ Project
Project
→ usesTechnology
→ Technology
Employee
→ maintains
→ Technology
六十、Inverse Property
worksFor
↔
employs
belongsTo
↔
hasMember
worksOn
↔
hasContributor
六十一、DataProperty
Person
→ name
→ string
Employee
→ employeeCode
→ string
Person
→ birthDate
→ date
Project
→ startDate
→ date
不要把所有简单值都做 Entity。
六十二、定义一个派生 Class
比如：
GoEngineer
不要人工维护。
定义：
Engineer
AND
hasSkill value Go
Reasoner 自动分类。
RedisExpert：
Engineer
AND
hasSkill value Redis
这样一个人可以同时：
GoEngineer
RedisExpert
Manager
不冲突。
六十三、再加 Disjoint
真正确定互斥：
Person
disjointWith
Organization
Person
disjointWith
Technology
Project
disjointWith
Person
这种顶层边界很有价值。
六十四、最终图会非常自然
张三
├── rdf:type → BackendEngineer
├── belongsTo → 研发部
├── worksFor → 硅碳智能
├── hasSkill → Go
├── hasSkill → Redis
└── worksOn → 支付系统
支付系统
├── usesTechnology → Go
├── usesTechnology → Redis
└── usesTechnology → PostgreSQL
李四
└── maintains → PostgreSQL
再通过规则：
张三
hasSkill Go
推出：
张三
rdf:type
GoEngineer
这才是真正：
数据 + 语义。
六十五、一个非常实用的建模 Checklist
开始建 Class 前问：
它是“概念”还是具体对象？
如果具体对象：
Individual。
建 SubClass 前问：
A is a B
能不能自然读通？
读不通：
不要继承。
建 Property 前问：
这条 Triple 能不能读成一句话？
例如：
张三 worksFor 公司
清晰。
设 Domain / Range 前问：
我真的希望 Reasoner 根据这个关系推断类型吗？
如果不确定：
不要乱设。
设 Disjoint 前问：
现实世界真的不可能同时属于两类吗？
如果可能：
不要 Disjoint。
建 Class 前再问：
这个分类是不是可以由其他属性推出来？
如果可以：
考虑 Equivalent Class。
六十六、还有一个很重要的问题：命名规范
Class：
PascalCase
例如：
BackendEngineer
ProgrammingLanguage
SoftwareSystem
ObjectProperty：
camelCase
例如：
worksFor
hasSkill
belongsTo
usesDatabase
DataProperty：
name
employeeCode
startDate
email
Individual：
最好使用稳定 ID：
employee_1001
department_001
project_2001
而不是直接：
张三
研发部
作为唯一 IRI。
显示名称：
rdfs:label
可以写：
张三
六十七、为什么 Individual 不建议直接用姓名做 ID？
因为：
张三
可能重名。
还有：
名字会变
简称会变
语言会变。
所以：
IRI
应该尽量稳定。
例如：
https://example.com/employee/1001
然后：
rdfs:label
"张三"
这和数据库：
id
+
name
其实是一个思想。
六十八、IRI 设计非常重要
推荐：
/company/1001
/employee/1001
/project/2001
/skill/go
不要：
/entity/abc123xyz
/entity/abc124xyz
完全看不懂，
也不要：
/张三
过度依赖显示名。
最好：
稳定 + 可预测 + 不依赖展示文本。
六十九、Ontology 版本也要管理
企业 Ontology 不可能永远不变。
比如一开始：
Employee
→ belongsTo
→ Department
后来增加：
BusinessUnit
再后来：
Department
SubClassOf
OrganizationalUnit
所以 Ontology 本身也应该：
Git
管理。
例如：
ontology/
├── company-v1.ttl
├── company-v2.ttl
└── shapes.ttl
更实际：
直接 Git 管理 Turtle / OWL 文件。
每次改：
Class
Property
Domain
Range
Disjoint
都应该 Review。
七十、Ontology 变更其实类似数据库 Migration
比如删除：
worksAt
改成：
worksFor
已有：
100 万 Triple
怎么办？
你不能只是：
Protégé 里改名字
就结束。
需要考虑：
旧数据迁移
Mapping 修改
SPARQL 修改
SHACL 修改
Agent Prompt 修改
所以：
Ontology 也是 API Contract。
不是随便改的。
七十一、一个很好的原则：Ontology 要稳定，数据可以变化
例如：
张三属于研发部
会变化。
张三会 Go
会变化。
但：
Employee
hasSkill
Technology
这种模型尽量稳定。
所以：
Ontology
=
相对稳定的世界结构
Data
=
持续变化的现实事实
这就是很好的分工。
七十二、什么时候模型说明设计得不错？
如果业务人员看到：
Employee
→ belongsTo
→ Department
Employee
→ worksOn
→ Project
Project
→ usesTechnology
→ Technology
基本不用解释：
就能理解。
说明命名和模型比较自然。
如果必须开两小时会：
EntityXRelationY到底是什么意思？
那模型可能已经过度工程化了。
七十三、什么时候说明模型开始变坏？
出现这些信号：
Class 超过几百个，但没人知道怎么用
同义 Property 越来越多
一个实体被创建多次
大量 Class 只是状态值
大量 Class 是多个维度的组合
Domain / Range 到处互相冲突
Reasoner 一运行出现大量意外类型
业务人员看不懂 Triple
都说明：
应该重构 Ontology。
七十四、Ontology 重构不要怕
就像代码：
会重构。
数据库：
会 Migration。
Ontology 一样。
可以：
合并重复 Class
删除无意义层级
统一 Property
调整 Domain / Range
增加 Disjoint
把手工 Class 改为 Equivalent Class
把值型 Class 改成 DataProperty
模型越简单：
往往越容易长期维护。
七十五、最终推荐的一套建模流程
不要一上来打开 Protégé。
第一步：
写问题
系统需要回答哪些问题？
第二步：
找核心名词
例如：
Employee
Department
Project
Technology
形成 Class。
第三步：
找核心动词
例如：
belongsTo
worksOn
hasSkill
usesTechnology
形成 ObjectProperty。
第四步：
区分 Entity 和 Literal
Department
Technology
Project
做 Entity。
name
age
email
做 DataProperty。
第五步：
建最小 Class Hierarchy
确保：
A is a B
成立。
第六步：
设置必要 Domain / Range
不要为了完整而全部填写。
第七步：
加真正确定的 Disjoint
重点守住顶层语义边界。
第八步：
用 Equivalent Class 表达派生分类
例如：
GoEngineer
第九步：
建几个 Test Individual
测试实际数据。
第十步：
跑 Reasoner
检查：
推理是否符合预期。
第十一步：
用 SHACL 校验数据
检查：
数据是否合格。
这才是一套比较完整的 Ontology Development Workflow。
总结
很多人认为 Ontology 难，是因为：
OWL 语法复杂。
其实真正困难的不是语法。
而是：
决定“世界应该怎么被描述”。
你需要不断判断：
这是 Class 还是 Individual？
这是属性还是实体？
这是继承还是关系？
这个 Class 真有必要吗？
Domain 是否太窄？
Range 是否正确？
两个 Class 真的互斥吗？
这个角色需要上下文吗？
这条关系本身是否需要属性？
这个分类能不能由 Reasoner 自动推出？
如果这些问题没想清楚，
Protégé 用得再熟：
Ontology 一样会越来越乱。
我认为建模时最值得记住三句话：
第一，Class 表达稳定的概念，不要复制数据库字段。
第二，优先用“实体 + 关系”组合信息，不要制造 Class 组合爆炸。
第三，Domain、Range、Disjoint 都是语义规则，不是界面里的装饰选项。
最终一个好的 Ontology：
不是：
Class 最多
Property 最多
层级最深。
而是：
用尽量少而稳定的概念，把真实世界中最重要的关系表达清楚。
项目地址：
https://github.com/protegeproject/protege
如果只记住一句话：
