Ⅰ
PHILOSOPHY
什么存在？它们最一般的类别和关系是什么？
人、事件、数字、性质、组织——哪些算“存在者”？一个范畴系统像是在现实上划分关节，但哲学史并不保证只有一套唯一正确的切法。
关键提醒：分类不是中性的容器，它携带你对世界的承诺。
一次从哲学到运营系统的认知实验
世界里，
什么算作一个东西？
本体论先决定“我们承认什么存在”，再决定“它们如何相关”。到了企业系统，真正困难的还多一步： 谁能依据什么逻辑，让现实发生改变？
- 01
- 看见范畴
- 02
- 建立共同含义
- 03
- 把决策接回现实
关系 / RELATIONS →
抽象 / ABSTRACTION →
这不是现实本身，而是三种“看现实”的镜头。镜头一换，同一个世界会显出不同的对象与关系。
本体 是对一个世界的共同承诺：有什么、如何相关、什么变化合法。
THREE LENSES / 三重镜头
同一个词，跨过三道门
不要急着背定义。先看每一层到底想解决什么问题。
Ⅱ
COMPUTATION
怎样让人和机器对一个领域里的词，理解得足够一致？
计算机本体把类、实例、属性、关系和约束显式化。它不必回答宇宙最终由什么构成，只要清楚规定“在这个任务里，我们假定什么存在”。
关键能力：共享含义、减少概念漂移、检查一致性、推出隐含事实。
Ⅲ
OPERATIONS / PALANTIR
怎样把共同含义接到实时数据、业务逻辑与可治理的行动？
Palantir 把语义元素称为组织的“名词”，把 Actions 视为“动词”，再用函数、模型、权限、情境和审计把句子补完整。目标不是描述完世界，而是更好地做决定。
关键差异：从 semantic graph 走向 governed decision loop。
CONCEPT LADDER / 概念阶梯
它和分类法、Schema、知识图谱、数字孪生到底差在哪？
逐级增加承诺。后一级不是取代前一级，而是把它带进更完整的问题空间。
它主要回答
A 属于哪一类？
增加：层级与归类。
还没有：丰富关系、行为和现实状态。
ANATOMY OF AN OPERATIONAL ONTOLOGY
一条业务句子，如何变成运行结构
点击下面五个层次，看“订单因缺料而风险上升，随后执行跨厂调拨”如何被拆开。
THE ENTERPRISE SENTENCE / 企业句子
订单 O-1042 受材料 M17 约束 经缺料模型评估 执行跨厂调拨 仅由运营负责人批准 并记录履约结果
SEMANTIC / 语义层
把业务世界变成可共享的名词与关系
Object Type 定义实体或事件；Property 描述特征；Link 表示现实关系。重点不是复制表结构，而是让对象贴近业务如何思考。
Order —requires→ Material —availableAt→ Plant
LIVE SCENARIO / 互动情境
让一次缺料，沿本体传播
下面是基于 Palantir 供应链材料抽象出的教学模拟，所有公司、订单与数值均为虚构。你将看见语义、逻辑、行动、权限和反馈如何形成闭环。
受影响订单
0
个
风险敞口
¥0
教学数值
预计履约率
98%
未来 7 天
DECISION LINEAGE / 决策轨迹
- 网络稳定：所有对象已同步，尚无风险事件。
DATA世界现在怎样
→
LOGIC可能发生什么
→
ACTION选择改变什么
→
SECURITY谁有权改变
→
OUTCOME改变是否奏效
FIELD GUIDE / 实战手册
别从“把所有数据本体化”开始
从一个真实决策开始，用问题压出结构，再让结构经受行动检验。
01 先写能力问题，不先画类图 Competency questions
例如：“某个原料停供时，哪些订单会受影响？有哪些替代方案？谁可以批准？”这些问题决定模型需要的范围与精度。
问题 → 需要的对象/关系/逻辑/动作
02 和领域专家找现实对象 Model reality, not source systems
先识别订单、设备、人员、事件和身份，再把 ERP 表、API、传感器与文档映射上去。不要让系统边界冒充业务边界。
WorkOrder ≠ erp_t_wo_hdr_v2
03 建立规范身份与语义 Canonical identity
规定主键、别名、单位、时间语义、来源血缘和冲突规则。没有规范身份，“同一个客户”会在不同系统里变成多个人。
source IDs → canonical object → traceable lineage
04 先让只读解释成立 Observe before acting
让使用者能沿关系回答能力问题，检查数据新鲜度和缺口，再接入预测、优化、规则与情境模拟。
facts → links → explanation → scenario
05 把决策做成受控动作 Actions with rails
动作要有清晰参数、校验、提交条件、审批、幂等、审计与失败恢复。自动数据变换留在 pipeline；人或 agent 的选择才进入 Action。
proposal → validation → authorization → writeback
06 记录结果，让本体持续学习 Decision lineage & outcome
保留当时的数据版本、使用的逻辑、备选方案、谁做了决定、执行了什么、结果如何。没有 outcome，只有流水账，没有反馈回路。
context + choice + action + outcome → next decision
ANTI-PATTERNS / 反模式雷达
本体项目最常见的六种走偏
Kitchen Sink
把源表每列 1:1 搬进对象，连脏命名和偶然结构也一起永久化。
部门副本
销售、财务、供应链各造一个 Customer，身份和动作从此分裂。
万能动作
把所有自动处理都塞进 Action，混淆了数据变换和业务决策。
深继承树
为每种能力组合制造新类型，最终没有人敢移动上层节点。
只有图，没有动词
关系可以浏览，却不能受控地建议、批准、执行和追踪结果。
模型即现实
忘记模型服务于任务，把一个版本的组织语言固化为唯一真相。
PUBLISHED FIELD SIGNALS / 公开案例信号
从对象关系，走到可衡量的干预
以下数字来自 Palantir 官方案例材料，用于理解机制，不视为独立效果评估或可复制承诺。
GLOBAL INDUSTRIAL MANUFACTURER
库存优化
100,000
种产品被纳入网络级优化
把原料、生产、产能、工厂资产和物流成本连接到统一网络，向约 150 名计划人员标记过量库存，并捕获干预效果。
查看 Palantir 官方案例 →
GENERAL MILLS
物流决策
70%+
系统建议被人类接受（官方披露）
约 200 张主数据与运营表形成连接基础，优化器跨订单、约束、产能和成本提出建议；接受或拒绝也成为决策数据。
查看官方案例 PDF →
AIRBUS A350
生产协同
30%+
A350 生产加速（官方披露）
排程、班次、部件、交付与缺陷不再只是分散数据；它们构成生产团队面对变化时共同导航的依赖网络。
查看 Palantir 制造业材料 →KNOWLEDGE CHECK / 理解校准
你已经不再把本体当作“高级 ER 图”了吗？
三道题，检查你是否抓住了边界，而不只是记住术语。
QUESTION 1 / 3
一个 ERP 表 `order_header`，应该直接对应一个 Ontology Object Type 吗？
请选择一个答案。答错不会扣分；解释比得分更重要。
SOURCES & BOUNDARIES / 来源与边界
把模型当作可质疑的承诺
本页综合权威哲学资料、开放标准、知识工程文献与 Palantir 官方材料。结论中的综合判断已与原始事实分开表达。
哲学与知识工程
本体不会自动修复坏数据
身份解析、时效、缺失、冲突与血缘仍是持续的工程和治理工作。
行动价值越高，行动风险也越高
外部副作用、幂等、审批、回滚、读写权限和下游权限传播必须单独设计。
没有唯一正确的领域本体
好坏取决于用途、扩展性、可维护性，以及它能否在真实应用中回答问题。