本体论工程实践方法
斯坦福：本体论设计方法没有公认的方法论
这个领域没有唯一正确的建模方式。最佳方案取决于你设想的应用和你预期的扩展。
Ontology development is necessarily an iterative process。本体开发必然是一个迭代过程。
你组织的概念应当贴近领域里的对象和关系。这些概念通常就是人们描述这个领域时用的名词和动词。
Ontology Development 101: A Guide to Creating Your First Ontology， 作者是 Stanford 大学的 Natalya F. Noy 和 Deborah L. McGuinness。 OpenAlex 记录到这篇文献的引用数是 4593 次
Stardog：不要建包罗万象的「super ontology」
Stardog 反复劝人不要建「super ontology」，也就是不要指望建一套包罗万象的本体，并给这个主张配了完整的论证，可以拆成四层。
- 第一层是前提。Stardog 在讲关系建模的那一节里写道，知识图谱「are purpose-built for the fluctuating nature of knowledge. They easily accept new data, new definitions, and new requirements.」这句话的意思是，知识图谱天生就是为知识的流动变化而设计的，它能轻松接纳新数据、新定义和新需求。知识图谱既然是为增量设计的，你一次定型一套大本体，就和它的本质相反。
- 第二层是直接因果。Stardog 只给了一句明确的因果判断：「Over-specification will hinder extensibility.」也就是过度规格化会损害扩展性。Stardog 没有展开推导，它把这句当结论直接给出。
- 第三层是「够用」的判定标准。Stardog 要求你「Keep it small to start; just enough to answer your business questions.」也就是先做小，做到足够回答你的业务问题就行。它给的判断办法是「defining the required entities and property relationships」，也就是看你能不能把回答业务问题所需的实体和属性关系定义出来。这把尺子把「完整」的含义从「包罗万象」改成了「对当前问题够用」。
- 第四层是配套的经验规则，也是最有操作性的一层。Stardog 给了一个具体的范围上限：单次建模花不超过两周，看的实体不超过 5 到 10 个。它的推理是反向的，原文是「If you look at your questions, and they require more than 5-10 entities for you to understand and model, it is probably too big of a question, and you should go back to step one and refine your scope.」也就是说，如果实体数量超了，Stardog 认为问题出在业务问题本身太大，不在你的建模能力不够，所以你要退回去缩小范围。Stardog 另外给了两条：信息一开始变得难以驾驭，你就缩小聚焦；不要「business modeling for modeling's sake」，也就是为建模而建模。到了验收环节，它要求你双向检查，原文是「Verify that your ontology is complete enough to answer any queries, but not so built out that it hinders future additions.」也就是本体要足够回答问题，又没有建到妨碍以后追加的程度。
Stardog 没有给出量化的规模上限，也没有举出过度规格化导致项目失败的具体案例。它的论证形态是重申立场加经验规则，原文用的措辞是「we're going to insist」，这是表态度，不是做证明。所以这条建议的强度属于行业经验，不属于经过验证的结论。
（Stardog: Building a knowledge graph）
Palantir 把本体定位成决策的表示
Palantir 官方把每一个运营决策拆成四个部分（Why create an Ontology?）：
| 组成 | 含义 |
|---|---|
| Data | 决策所依据的信息 |
| Logic | 评估决策的启发式与计算过程 |
| Action | 所选决策的编排与执行 |
| Security | 决策符合运营策略的保证 |
Palantir 在文档里直接点明了本体的定位：「The Ontology represents the decisions in an enterprise, not simply the data.」
Palantir 在同一页还给了一个比喻：数据对象是本体的「名词」（semantic），动作是本体的「动词」（kinetic）。
Palantir 的四条本体设计原则
These four principles are derived from extensive field experience across government and commercial implementations. They are presented in priority order. In cases of conflict, higher-priority principles take precedence.
| 优先级 | 原则 | 核心意思 |
|---|---|---|
| 1 | Domain-driven design | 你建模真实世界，不建模源数据 |
| 2 | Do not repeat yourself | 你把同一个东西建了三遍，就该重构（rule of three） |
| 3 | Open for extension, closed for modification | 软件设计开闭原则（OCP）：对外开放扩展，关闭修改 |
| 4 | Composition over deep hierarchies | 做组合设计，不搞深继承链 |
Palantir 给这四条原则排了优先级，这一点很实用。你遇到两条原则互相冲突的时候，按序号取高的那条就行，不用每次重新争论。
官方给了一条明确的操作顺序：先理解领域，再设计对象模型，最后映射数据
Palantir 在这一页的 best practices 里，第一条要求你「Identify real-world entities before looking at source schemas」。最后一条写着：
Model the domain, then map the data: Understand the domain, then design the object model, then map source data into that model. Do not attempt to look at the data and replicate its shape.
Palantir 在同一页列出的反面做法有这些：
- 你建的对象类型照抄源系统的表，没有照领域实体建
- 你把属性从源字段 1:1 搬过来，不做任何筛选
- 你的命名沿用了源系统的习惯（
dtLastInspMod），没有用业务语言（lastInspectionDate） - 你看着数据来设计模型，没有先去理解领域
- 一行源数据里其实有好几个实体，你却把它们建成了一个对象类型
Palantir 举的例子很直观。一张 CSV 表里含 order_id、customer_name、customer_email、product_sku、quantity 五列。这五列描述的是至少三个实体（Order、Customer、Product），不是单独一个实体。
RDF 是本体的事实标准
RDF 的设计目标是描述资源，让机器能处理网上的数据。它是个通用的数据模型，目的是任何领域的陈述都能表达，和本体没有绑定关系。
RDF 的模型适合承载本体。 因为它把一切压成三元组，类也是一个节点，属性也是一个节点，于是你可以对它们下断言。这种"什么都一样"的统一性，正是"模式也是数据"能成立的根源。
RDF 规定的是数据模型
RDF 是 W3C 的一个标准，规定的是数据模型。它不是软件，不是数据库，也不是文件格式。全名 Resource Description Framework。它只规定两件事：
- 数据长什么样：三元组、IRI、字面量、空白节点、图。
- 怎么用文字写出来：一套序列化语法。
其他一概不管。所以在项目里用到多种层次的技术方案：
| 层 | 标准或技术 | 你项目里的对应物 |
|---|---|---|
| 数据模型 | RDF | 三元组、IRI、字面量、空白节点 |
| 序列化语法 | Turtle、N-Triples、JSON-LD、RDF/XML | ontology.ttl、knowledge_docs.ttl |
| 模式词汇 | RDFS、OWL | 空的，第 9 课要补 |
| 查询语言 | SPARQL | 你写的 SELECT、INSERT |
| 校验 | SHACL | 没用到 |
| 存储引擎 | 不属于 RDF 标准 | TDB2 |
| 服务器 | 不属于 RDF 标准 | Fuseki |
RDF 数据模型基本规则
- 一条边（三元组）固定三部分：主语、谓词、宾语。
- 谓词只能是 IRI。字面量不行，空白节点也不行。
- 主语只能是 IRI 或空白节点。字面量不行。
- 宾语可以是 IRI、空白节点、字面量。
- 图是三元组的集合。同一条三元组不能出现两次，插入重复的三元组等于什么都没做。
- 方向属于数据本身。A→B 和 B→A 是两条不同的边，可以同时存在。
- 同一对节点之间可以有多条边，靠谓词区分。
- 可以自环，主语和宾语是同一个 IRI。
- 同一个 IRI 可以出现在任何位置，包括谓词位。
谁是节点，谁能放在哪个位置
图的节点等于所有主语加所有宾语。谓词不算节点，它是边上的标签。
| 种类 | 有名字吗 | 主语 | 谓词 | 宾语 |
|---|---|---|---|---|
| IRI | 有，全局唯一 | 能 | 能 | 能 |
| 空白节点 | 没有 | 能 | 不能 | 能 |
| 字面量 | 是值本身 | 不能 | 不能 | 能 |
- IRI 是引用语义。 名字一样才是同一个东西。
gwa:scenario_1和gwa:scenario_01是两个不同节点。 - 字面量是值语义。 内容一样就是同一个值，谈不上区分。字面量没有"它自己"，只有内容。
- 空白节点是有存在、没名字。 名字只在当前这一份文件内部有效，导出再导入会被重新分配。所以不能靠空白节点做跨库合并。
- 跨库合并的判据是"两个 IRI 是不是同一个字符串"，不是"字段值是否相等"。
- 身份不存放在数据里的某个字段，而是那个东西的名字本身。所以不需要先找到一行才能指称它。
本体层与数据层
- 本体层（TBox）：三元组说的是类、属性这些词本身。
- 数据层（ABox）：三元组说的是实例。
- 两层用同一套模型、同一套 IRI、同一种三元组。差别只在主语和宾语指的是谁。
rdf:type属于数据层，因为它断言"这个实例属于那个类"，主语是实例。- 本体是可选的。RDF 图可以完全没有本体。
- 本体写进去以后能推出新三元组（靠
rdfs:subClassOf、rdfs:domain、rdfs:range），这需要引擎开推理。Fuseki 默认不开。 - 这份图的本体层是空的：
rdfs:和owl:的三元组 0 条。文件名叫ontology.ttl，里面装的全是实例数据。
一句话对照：
数据层： gwa:scenario_1 gwa:core_object gwa:bo_FinancingAsset 本体层： gwa:core_object rdfs:range gwa:BusinessObject
两条形状一样，区别在第二条谈论的对象是 core_object 这个谓词自己。