本体工程

本体工程是围绕特定领域，分析需求、定义共享概念与关系、形成形式化本体，并持续验证和维护它的知识建模活动。它关注的不只是术语清单或层级目录，还包括术语间可计算的语义约定及其适用范围。

在计算机与信息系统语境中，本体工程（ontology engineering）指有计划地构建、检验、发布和维护领域本体的一组方法。它的直接产物通常是一份或一组本体：对某个问题领域中的概念、类别、属性、关系和规则作显式、形式化的描述。这里的“工程”强调需求、协作、版本和质量控制，而不是把某种哲学立场写成软件。

“本体”与“本体工程”也要区分：本体是被构建和维护的模型，工程则是确定模型范围、与领域专家协作、选取表达语言、验证及演进它的过程。不同学科对“本体”的定义不完全一致。面向语义数据的常见工作定义是：本体给特定领域的术语赋予可共享、可计算的含义，并说明术语之间的关系。它可被软件用于对数据分类、对齐或按既定语义推出结论；它不是现实本身，也不能覆盖人类知识的所有方面。

一个小例子：如果数据系统要描述图书馆资源，本体可定义“作品”“版本”“作者”等类别，说明“作品由作者创作”“版本是某作品的具体出版形式”等关系，并明确这些词如何区分。实际的某书记录、某位作者的实体标识和出版日期则属于具体实例或事实数据。模型让不同记录能够依相同含义互通，但只有将它用于相应任务并持续核对，才能判断它是否有用。

本体建模应先确定它服务的任务：领域边界是什么，谁会使用或维护，数据来自何处，需要回答什么问题，以及允许怎样扩展。可先写一组“能力问题”（competency questions），例如“某作品有哪些版本？”“作者参与过哪些作品？”再检验拟议本体和实例数据是否足以回答。问题清单帮助确定所需细节，也防止把相关但当前无用的概念全部塞进模型。

随后检查是否有可复用本体、标准词汇或受控术语表。重复造词会导致新模型与其他系统难以对接；直接复用同样不能只复制文件，还要核对定义、许可、维护状态、语言和使用范围。项目可以导入已有模块后作扩展，也可以只映射对方概念而不把所有内容并入本体。重用是设计选择，不代表外部模型一定适合当前任务。

需求与术语讨论通常要反复进行。领域专家可能认为某个概念具有业务区分意义，工程人员则要评估它是否能在模型中精确定义；同一自然语言词也可能在不同组织、学科或地区有不同含义。将名词一对一映射为“类”、动词一对一映射为“关系”只能作为起点，不能替代边界讨论。每个重要词最好同时有自然语言说明、稳定标识以及必要的正例和反例。

在形式模型中，类（class）表示满足某种条件的一组对象，个体（individual）是本体中被单独指称的对象，可以是具体或抽象对象，属性或关系描述对象间的联系或对象的取值。例如“作者”可以是类，“林某”可以是个体，“创作”可以是连接作者与作品的关系，“出版年”则可连接作品版本与日期值。类与实例不是一回事；“某人属于作者类”也不等于“作者类是某个人”。个体可以同时属于多个类别，除非模型明确说明类别互斥。

层级关系要表达定义上的“是一种”，而不是任何相关联系。若“学术专著”是“出版物”的子类，则每个学术专著都应属于出版物；“作品由作者创作”表达的是关系，不应误建成子类关系；“章节是作品的一部分”也不等于“章节是一种作品”。误把“部分—整体”“参与”“位于”等关系写成 subclass-of，会让推理沿着错误语义扩散。

本体中的公理（axiom）把术语的含义和关系写成机器可处理的声明，例如子类、互斥、属性类型、关系的逆向或某个类由哪些条件组成。OWL 2 是一种具有形式语义的本体语言，可表达类、属性、个体和数据值；推理器能够据其语义检查一致性或推出隐含结论。但形式表达越强，建模、维护和推理要求也越高。W3C 的 OWL 2 设有 EL、QL、RL 等不同 profile，以不同表达能力换取不同的推理或查询特性；选择取决于数据规模、模型结构和目标问题，而不是单看语言功能多少。

将领域模型编码为机器可读格式之后，应检查模型本身的逻辑效果。推理器可进行类层级分类、检查某些矛盾，或在公理成立时推出蕴含关系。推理结果严格依赖输入声明和所用语义：若“教师是职员的子类”，系统可以从“甲是教师”推出“甲是职员”；它不能从标签文字本身知道教师在真实机构中的全部职责。规则遗漏、概念混淆或不当地声明互斥，都可能造成意外推论。

本体逻辑与数据字段校验需区分。OWL 的开放世界语义下，数据中没有出现某项信息，不一定表示它为假；OWL 也不是用于保证每条记录都填齐某些字段的通用语法校验器。如果目标是检查 RDF 数据是否具有某属性、属性值是否属于某数据类型、出现次数是否在范围内，可另用 SHACL 等约束语言针对数据图生成验证结果。也就是说，模型语义回答“这些声明逻辑上意味着什么”，数据校验回答“此批记录是否符合所要求的形状或条件”，两种工作可以配合，不能混为一谈。

评估不能只看本体文件是否可解析。可以用能力问题测试覆盖度，针对典型实例检查边界，邀请领域专家审核术语，运行适用的推理器和数据验证器，记录未覆盖案例及争议。外部复用者也需要知道每个类、关系、单位、时间表达和空值约定的含义。模型如果逻辑自洽但无法回答目标问题，或者虽能回答却把不同来源的概念强行合并，也仍需调整。

本体会随领域知识、制度定义、数据来源和使用需求变化。发布时应提供版本号、版本日期、维护者、许可、命名空间或稳定标识、变更记录、弃用说明和兼容策略。对被其他系统引用的概念，直接重命名或改变定义可能使既有映射和查询失效；如果必须调整，应说明旧新术语关系、迁移方式和生效版本。多语言标签可提升可发现性，但翻译标签不能替代正式定义，也不保证不同语言概念边界完全重合。

工程治理还需要安排谁可提出更改、由谁审阅、如何管理跨团队分歧、何时合并版本，以及谁负责响应用户反馈。模块化有助于把稳定的核心词汇和快速变化的应用扩展分开；模块之间也必须说明导入依赖和版本兼容性。若本体承载敏感领域的数据含义，还要处理来源、许可、访问权限和更新周期。单纯发布开放格式，不等于数据可自由再利用或内容必然准确。

分类法或主题词表主要组织概念、标签和较浅层的层级或关联，本体则可进一步给类别、属性和关系写入明确形式语义与逻辑公理。不过，这是表达能力上的常见区别，不意味着所有分类表都很简单，或所有本体都必须使用复杂逻辑。W3C 的 SKOS 就为在 Web 上共享和链接知识组织体系提供通用数据模型；它可支持概念标识、标签、层级和关联，适合许多分类与词表场景。

数据库模式主要服务数据存储、完整性约束和应用读写；面向对象程序里的类通常还关联程序行为。本体的重心是概念及关系的形式含义，OWL 2 不是编程语言，也不是用来规定记录必须具有某个语法字段的数据库框架。实际系统可让数据库承担存储，再由本体描述语义、由验证语言检查记录、由应用执行业务流程。

知识图谱是以关联对象与关系组织具体知识的图结构数据或应用；本体常可作为它的模式或语义层，但本体不等于包含具体事实的图谱，知识图谱也可以采用非 OWL 的模型。由此，本体工程并非“给知识图谱加上层级目录”，而是把某一领域的概念约定做成可讨论、可复用、可检验的正式模型。可参见站内词条“知识图谱”和“语义网”。

当多个系统、团队或研究人员必须以稳定的共同术语交换数据，数据集需要跨领域对齐，或应用确实要依明确公理进行分类和推理时，本体工程具有价值。范围较小的项目可能只需复用或建立轻量词汇表；只有在目标任务需要时，再增加 OWL 的逻辑构件或 SHACL 数据约束。已有成熟标准的领域应先评估能否直接采用、映射或扩展，而非为追求形式完整另造一套术语体系。

其成本包括概念争议的协调、专家时间、标识与映射维护、工具和培训，以及本体更新对下游系统的影响。形式模型也会把设计者的假设显式化；如果参与者的定义不同，模型可能仅把分歧隐藏在技术术语之后。对计算密集的推理或高频变化数据，应先评估语言 profile、数据处理方式与维护能力。若需求只是简易表单校验、简单目录导航或固定业务表，使用数据库约束、术语表或常规数据模型可能更合适。

本体工程的结果不是“唯一正确的世界模型”，而是针对特定目的形成的、定义清楚且可以迭代改进的领域模型。它的质量最终取决于能否帮助使用者准确交流、复用和处理领域数据，并能在现实需求变化时被有序修订。

• Stanford University Protégé：Ontology Development 101
• 万维网联盟：OWL 2 Web Ontology Language Primer（Second Edition）
• 万维网联盟：OWL 2 Web Ontology Language Profiles（Second Edition）
• 万维网联盟：Shapes Constraint Language（SHACL）
• 万维网联盟：SKOS Simple Knowledge Organization System Reference
• 万维网联盟：RDF 1.1 Concepts and Abstract Syntax