本体论与领域建模

我想落地的部分

放到软件实践里，本体建模关心的是领域里有哪些概念、它们之间有什么关系、这些关系受什么约束。拿“论文”“主张”“证据”来说，它们不是三个随手贴的标签：一条主张要说明由什么材料支持，材料又要说明来自哪里。

写成约束大概是这样（示意）：

主张 --由...支持--> 证据      （一条主张至少要有一条证据，否则状态只能是“待核验”）
证据 --出自--> 论文           （每条证据必须指向一篇具体的论文和页码/段落）
论文 --使用--> 数据集

有了这几条，系统就能检查出“这条主张没有证据”或者“这条证据说不出出自哪篇论文”，而不只是存一段文字。

本博客用的是一个刻意做小的学习本体，只有四种节点：概念、设计模式、实践、文章。它用来组织公开的知识，不涉及任何公司的内部业务模型。

三件事不要混为一谈

• 本体描述领域里的对象和关系。
• 动作契约描述工具的输入、前置条件和输出。
• 程序校验和权限控制决定哪些操作真的能执行。

拿报销场景对照一下：“发票属于员工”“报销单引用制度条款”是本体层面的关系；create_reimbursement_ticket 要哪些参数、前置条件是员工已确认，是动作契约；执行前检查 INV-102 是不是当前员工的发票，是程序校验。三层各管各的，哪层缺了，另外两层也补不上。

把规则写进提示词，不等于程序已经守住了这条规则；手上有一张 知识图谱，也不等于已经有了推理能力。

待验证

后续在 研究 Agent 里比较：有显式领域模型和没有的时候，系统在处理来源缺失、不当比较这两类问题上有什么差别。

参考入口

W3C OWL 2 Overview 是后续学习入口，不代表当前已经实现 OWL 推理。