Ontology（本体）是什么？Palantir 企业本体论的解释、构成与边界

Ontology 是什么？一句话定义

Ontology 是企业现实在软件中的“可操作模型”：它不仅说明企业里有什么、彼此有什么关系，还规定人和 AI 可以依据什么逻辑、在什么权限下采取什么行动，并把行动结果写回真实业务系统。

你也可以把它理解成一张持续更新的“企业作战地图”：

• 地图上的东西不是数据库表，而是业务人员认识的客户、订单、设备、航班、病床、工单、供应商；
• 它不只画出“谁和谁有关”，还装入预测模型、业务规则、优化算法和 LLM；
• 它不只供人查询，还提供审批订单、调整排产、分配人员、更新工单等受控操作；
• 它知道每个人和每个 AI Agent 能看什么、能算什么、能做什么；
• 它记录行动及其结果，使组织可以复盘、评估和继续学习。

这就是 Palantir 把一个原本偏哲学和知识工程的词，发展成企业软件核心概念的地方：Ontology 不再只是“对世界的分类和描述”，而是连接认知、决策与执行的运行系统。 Palantir 将它称为组织的 operational layer（运营层），并在某些场景下称其为企业的 digital twin（数字孪生）；在面向市场的介绍中，又用“Your Business as Code”概括这种思想。1

---

Ontology 这个词原来是什么意思？

Ontology 通常译作“本体”或“本体论”。在哲学中，它讨论“世界上究竟存在什么，以及这些存在如何分类、如何相互关联”。后来，知识工程和计算机科学借用了这个词，用它表示某个领域中概念、属性、关系和规则的形式化表达。

比如，在航空领域，我们可以约定：

• “飞机”“航班”“机场”“机组”是不同类型的实体；
• 航班有起飞时间、状态、出发机场等属性；
• 某架飞机“执行”某个航班，某位员工“属于”某个机组；
• 航班取消、调换飞机、重新分配机组是可以发生的业务行为。

传统本体往往更重视世界如何被准确描述。Palantir 的产品化扩展则进一步追问：

1. 这些概念如何连接企业的真实数据？
2. 决策所需的规则、模型和算法放在哪里？
3. 人或 AI 作出决定后，怎样安全地改变现实业务？
4. 谁有权看、算、改，怎样审计全过程？

因此，本文中的大写 Ontology 主要指 Palantir 的产品与架构概念，而不是哲学意义上的本体论，也不等同于所有知识图谱领域对 ontology 的一般定义。

还需要澄清一点：Palantir 并没有发明 ontology 这个词，也没有发明语义建模、知识图谱或数字孪生。它的重要贡献，是把这些思想与数据集成、业务逻辑、事务操作、安全治理和应用开发结合起来，做成了可以承载企业日常运营的系统。

---

为什么数据库和数据仓库还不够？

一家企业可能已经拥有 ERP、CRM、MES、WMS、数据仓库、湖仓、IoT 平台和文档库。问题却仍然存在：

• 销售系统里有一个客户，财务系统里也有一个客户，二者是不是同一个？
• 表里的 ord_hdr_st 对业务人员和 AI 到底意味着什么？
• 供应商延期会影响哪些物料、工单、产品、客户订单和收入？
• 算法建议“重新分配库存”以后，谁来批准？怎样更新仓储、ERP 和排产系统？
• AI 可以读取哪些价格、患者或国防数据？它能建议，还是可以直接执行？

数据仓库擅长回答“过去发生了什么”，数据湖擅长容纳各种数据，BI 擅长生成报表，但它们通常不会自动给出一套统一的业务语义、决策逻辑、可执行动作和动态权限。Palantir 认为，传统数据架构也很少完整保存一项决定是在什么数据版本上、比较了哪些选项、依据什么逻辑、由谁作出、产生了什么结果。[2]

于是，真正的瓶颈往往不再是“有没有数据”，而是：

企业有没有一层共同的、可计算的业务语言，让人、软件和 AI 都能理解现实，并在现实中安全行动？

Ontology 就是 Palantir 对这个问题的回答。

---

为什么要从“以数据为中心”转向“以决策为中心”？

Palantir 对 Ontology 最关键的表述不是“统一数据”，而是：它表示企业中复杂而相互关联的决策，而不只是数据。[3]

在其框架中，一项运营决策由四类要素共同构成：2

为什么要从“以数据为中心”转向“以决策为中心”？

要素	它回答的问题	企业中的例子
Data（数据）	当前事实是什么？	库存、订单、设备状态、合同、实时传感器、文档
Logic（逻辑）	应该如何判断？	业务规则、预测模型、优化器、仿真、LLM 函数
Action（行动）	决定之后做什么？	调整排产、审批采购、分配工单、更新 ERP
Security（安全）	谁在什么条件下可以做？	行列级权限、用途限制、角色授权、动作审批、审计

这四项不能割裂：

• 只有数据，没有逻辑，系统只能展示事实；
• 有数据和逻辑，没有行动，模型只能提出建议；
• 能行动却没有安全治理，自动化可能造成越权或真实损失；
• 没有反馈记录，组织无法知道建议是否有效，更难持续学习。

Palantir 因此把企业中的对象称为“名词”，把行动称为“动词”。数据提供语义，Action 提供动力，Logic 把二者连成“句子”，Security 则决定谁可以说出并执行这句话。2

---

Ontology 是怎样搭起来的？

1. Objects：把表和字段翻译成业务世界

Ontology 由五个基本构件搭起来：对象类型描述“企业里有哪些东西”，对象是具体实例，属性描述特征，链接类型描述“彼此怎么连”，链接是实例之间的真实关系。先有这层语义，才谈得上后面的行动与权限。

• Object Type（对象类型）：一种现实实体或事件的定义，如“客户”“设备”“航班”“订单”。
• Object（对象）：具体实例，如“设备 A-103”或“订单 SO-2026-001”。
• Property（属性）：对象的特征，如设备状态、订单金额、航班起飞时间。
• Link Type（链接类型）：对象之间关系的定义，如“订单属于客户”“工单使用设备”。
• Link（链接）：两个具体对象之间的一条实际关系。

对熟悉数据库的人，可以先这样类比：[4]

1. Objects：把表和字段翻译成业务世界

数据世界	Ontology 世界
数据集或表	对象类型
一行记录	一个对象
一列	一个属性
一个字段值	一个属性值
Join	链接类型

但这只是入门类比，不能把两者画等号。表通常按照系统、存储或交易需要组织；Ontology 应按照现实业务概念组织。一个 OrderData 表里也许同时混着订单、客户和产品信息，而好的 Ontology 会把它拆成 Order、Customer、Product，再用有业务含义的链接连接起来。[5]

Palantir 的设计原则非常明确：model reality, not systems——建模现实，而不是照搬源系统。[5]

2. Links：让企业从“表格集合”变成关系网络

链接不是为了把两个外键连起来，而是要表达一种业务人员真正关心的关系，例如：

• 患者在哪家机构就诊；
• 员工属于哪个团队；
• 哪台设备参与了哪个工单；
• 哪批物料影响哪些生产任务。

链接可以双向遍历：从航班找飞机，也可以从飞机找它承担的航班。[6] 如果关系本身还有角色、起止日期、分配比例等信息，就应把关系建成一个独立对象，而不是把这些信息硬塞进任意一端。[7]

这种结构使系统和 Agent 可以从一个异常出发，沿着真实业务关系追踪上下游影响，而不必先知道一连串数据库表名和 Join 条件。

3. Actions：把“看见问题”变成“改变业务”

这是 Palantir Ontology 与许多只读语义层或知识图谱最显著的区别。

Action Type（动作类型）定义一项完整业务操作可以怎样修改对象、属性和链接，还可以包含参数、验证条件、权限和副作用。例如，“调岗员工”不是直接改一个数据库字段，而可以同时：[8]

• 修改员工角色；
• 建立与新经理的链接；
• 验证操作者是否属于 HR；
• 通知原经理和新经理；
• 留下完整的动作记录。

动作还可以通过 webhook 连接 Salesforce、SAP 或其他 HTTP 系统，把决定写回现有业务系统。Palantir 区分 writeback 与 side effect：前者在对象变更前执行，外部调用失败时会阻止后续变更；后者在对象变更后执行，更适合尽力而为的通知或多个外部写入。[9]

这意味着 Ontology 不必替换所有 ERP、CRM 和生产系统。它更像一个跨系统的决策与编排层：把分散系统中的状态统一成业务对象，再将获批决定同步回承担交易的系统。

4. Functions 与 Models：把企业推理能力接进来

Function（函数）是可以在服务器端快速运行的代码逻辑。它可以读取对象属性、沿链接查询、聚合对象，也可以通过 Function-backed Action 执行复杂编辑。[10]

函数背后的逻辑不必只有一种：

• 确定性的业务规则；
• 统计模型和传统机器学习；
• 预测、排程或优化算法；
• LLM 或多模态模型；
• 调用多个系统和引擎的组合流程。

当模型输出映射到对象和属性后，普通用户看到的就不再是抽象的模型张量或服务接口，而是业务可理解的“需求预测”“风险分类”“交付时间估计”。Palantir 认为，这种绑定使模型更容易被复用、解释并进入实际工作流。[11]

5. Interfaces：为不同对象抽取共同能力

Ontology 中的 Interface（接口）很像编程语言里的接口。它描述一组共同的属性、关系或动作，但自身不是可实例化对象。例如 Facility 接口可以由机场、工厂、维修机库实现；一个面向 Facility 的工作流就能兼容后来新增的设施类型。[12]

它的意义不仅是技术复用，也是帮助企业建立稳定的共同概念，避免每个部门都重复创造一套“客户”“资产”或“设施”。

---

为什么说 Ontology 不是一张图，而是一整套系统？

Palantir 明确反对把 Ontology 简化为“薄薄的语义层”。官方架构把它概括成 Language、Engine、Toolchain 三个部分：[3]

Language：企业共同语言

它定义对象、属性、链接、动作、自动化和逻辑，也把安全规则嵌入其中。其目标是让业务人员、开发者和 Agent 面对的是同一个世界模型。

Engine：真正承载读写的运行引擎

它支持查询、搜索、聚合、状态订阅、事务更新、批量变更、流数据和与外部系统同步。其后端由元数据服务、对象数据库、Object Set Service、Actions、数据写入编排和 Functions 等多类服务共同组成，而不是一个单体数据库。[13]

Toolchain：让 Ontology 成为应用后端

Ontology SDK（OSDK）可为 TypeScript、Python、Java 等开发环境生成与 Ontology 对应的类型和函数。开发者可以把 Foundry 当作后端，查询对象、提交动作，同时继承平台的权限控制。[14]

因此，更准确的理解是：

企业源系统、数据、文档、传感器、模型
                    ↓
        Ontology Language：业务概念与能力
                    ↓
        Ontology Engine：查询、计算、写入、同步
                    ↓
  应用、分析、自动化、API、SDK、AI Agent
                    ↓
       决策回写真实系统，并形成反馈与审计

---

Ontology 在供应链里怎么跑完一个闭环？

假设一家医疗用品制造商突然收到消息：关键原材料供应商将延期交货。

第一步：理解发生了什么

Ontology 把 ERP 中的订单、WMS 中的库存、MES 中的工单、物流系统中的运输状态和邮件里的供应商通知，映射成供应商、物料、库存、工单、产品、客户订单等对象。

运营人员或 Agent 可以沿链接回答：

延期的是哪种物料 → 哪些工单需要它 → 哪些产品会受影响 → 哪些客户订单可能延迟 → 对收入和关键客户承诺有什么影响？

第二步：提出可行方案

系统调用需求预测、替代料规则、库存调拨算法和排产优化器，生成几种方案：

• 从另一仓库调拨；
• 替换物料；
• 调整多个工厂的生产顺序；
• 将有限库存优先分配给关键订单。

Ontology Scenario 可以把这些改动放入隔离沙箱，比较多个“如果这样做会怎样”的结果，而不立刻改变生产数据；人或 Agent 可以在场景中运行动作和函数，批准后再合并到主 Ontology。[15]

第三步：在权限范围内执行

系统检查：

• Agent 是否能读取价格和客户等级；
• 谁能批准跨区域调拨；
• 哪些动作只能由人最终确认；
• 写回 ERP 和 WMS 前需要满足哪些规则。

审批通过后，Action 同步更新仓储、排产和订单系统。失败调用、输入参数、操作者和结果都可被记录与追踪。

第四步：把结果变成组织记忆

几周后，企业可以比较当时评估过的方案、采用的方案、真实交付结果和成本变化。决策过程不再只存在于会议、聊天记录或少数老员工脑中，而成为可分析的“决策数据”。Palantir 将这种数据—逻辑—行动—反馈闭环视为从辅助决策逐步走向自动化的基础。[2]

---

它和常见技术到底有什么区别？

下面的比较不是非此即彼。一个成熟 Ontology 往往会使用或包含这些技术，但关注点不同。

它和常见技术到底有什么区别？

技术	主要解决什么	与 Palantir Ontology 的差别
数据库/数据仓库	存储、查询和分析数据	Ontology 用业务对象覆盖底层数据，并加入关系、逻辑、动作和权限
数据目录	找到数据资产及负责人	Ontology 不只描述数据资产，还承载面向运营的对象和可执行工作流
语义层/指标层	统一字段、指标和业务口径	Ontology 除“这是什么”外，还定义“能做什么、怎样做、谁能做”
知识图谱	表示实体及其关系，支持图式查询和推理	可以是 Ontology 的语义部分；Palantir 更强调动作、写回、计算和治理
数字孪生	映射现实对象或过程的当前状态	Palantir 将企业级对象、模型、动作和权限整体视为动态数字孪生，而不限于物理设备
API 层	暴露系统能力	OSDK/API 从统一业务模型生成，并携带对象、动作和权限语义
业务流程/BPM	描述和执行流程	Ontology 把流程放在共享对象网络、模型与数据上下文之上
RAG	为 LLM 检索相关文本	Ontology 还能提供结构化对象、链接、业务逻辑和受控工具，不止文本片段

所以，“Ontology 就是知识图谱”不够准确，“Ontology 就是语义层”也不够准确。在 Palantir 的定义里，它更接近“语义模型 + 决策逻辑 + 安全动作 + 运行引擎 + 开发工具链”的组合。[3]

---

为什么 Ontology 对企业 AI 尤其重要？

1. 它解决企业 AI 最缺的“上下文”

通用大模型知道大量公开知识，却不知道你公司的“客户”“缺货”“关键订单”“可替代物料”具体指什么。更不知道这些概念散落在哪些系统里、哪套数据是权威来源、哪些规则必须遵守。

Ontology 把上下文从零散提示词提升为一个持续维护的业务模型。Agent 获取的不只是文本，而是：

• 明确命名的对象和属性；
• 可以遍历的真实业务关系；
• 当前状态与历史行动；
• 可调用的模型、函数和工具；
• 对每次读取和动作生效的权限。

Palantir 的 AIP 架构因此把 Ontology 称作“激活上下文”的系统，并把它放在 Agent、自动化和人机协作应用的共同基础上。[16]

2. 它让 AI 从“回答问题”走向“完成工作”

RAG 通常让 AI 找到几段相关文档，再生成回答。Palantir 的文档也提供了语义搜索、向量嵌入、关键词与向量混合检索等方法。[17]

但真实工作还要求 AI 能够：

1. 查询当前库存和订单；
2. 调用预测或优化模型；
3. 比较多个方案；
4. 提议或执行一个动作；
5. 把结果更新回系统；
6. 接受监控、评估和审计。

也就是说，企业 Agent 需要的不仅是“知识”，还需要被允许使用的工具。在 Palantir 的表述中，Ontology 可以成为“tool factory”：查询、模型、函数和动作都能被包装成供人或 Agent 使用的受控工具。[18]

3. 它给非确定性 AI 加上确定性护栏

LLM 的推理具有概率性，业务规则、授权边界和交易约束则必须尽可能确定。Ontology 可以让 LLM 负责理解意图、生成候选方案或编排步骤，同时让：

• 业务规则负责校验；
• 优化器负责精确计算；
• Action 负责合法状态变更；
• Security 负责实时授权；
• 人类负责高风险最终审批。

这不是让 AI “自由接管企业”，而是逐步扩大其被验证过的行动范围。Palantir 的示例也强调，可以先只允许 Agent 暂存变更、交由人审核，再根据可靠性扩大或收缩自动执行权限。[2]

4. 它为 Agent 提供组织记忆和评估依据

如果每次决策的输入、逻辑、选项、动作和结果都有 lineage（谱系），企业就能判断：

• 哪个 Agent 在哪些场景表现好；
• 哪种模型或提示词导致错误；
• 哪类建议经常被人工否决；
• 哪种行动真正改善了业务指标。

Palantir 的可观测性工具覆盖指标、执行历史、分布式追踪、日志、提示词、Token 使用和错误信息等，用于观察 Ontology 与 AIP 工作流。[19]

---

Ontology 对企业转型意味着什么？

很多“数字化转型”停留在三件事：上线系统、汇总数据、增加报表。Ontology 所代表的更深变化是：

从“系统语言”转向“业务语言”

员工不必先学习数据库表和系统代码，应用与 AI 直接围绕客户、订单、设备和风险工作。

从“部门应用”转向“共享运营模型”

销售、供应链、财务和客服不再各造一个“客户”，而是在权限隔离下使用同一个企业概念。这样才可能形成跨部门工作流。

从“模型项目”转向“模型能力”

预测模型不再是某份报告背后的孤立代码，而可以成为多个工作流共同调用的能力，并以统一业务对象解释输出。[11]

从“洞察”转向“行动闭环”

仪表盘告诉你发生了什么；Ontology 进一步定义谁可以怎样改变它，并把结果写回业务系统。

从“AI Demo”转向“AI 运营”

一个聊天机器人 Demo 可以只靠文档和提示词；一个能够影响库存、生产、患者、资金或关键基础设施的 Agent，则必须拥有稳定语义、明确工具、最小权限、人工接管、测试、监控和审计。

---

怎样建设一个好的 Ontology？

建设好的 Ontology 有六条被反复验证的原则：建模现实而不是照搬源系统、从决策倒推对象、控制对象类型的数量、让 Action 成为一等公民、把权限设计进模型、用真实业务场景验证。

1. 先理解业务领域，再看源数据。 不要把数据库表原样搬过来。
2. 模型现实，不模型组织架构。 不要让每个部门各建一套“客户”。
3. 一个事实尽量只存一次。 需要便利访问时使用派生属性，谨慎权衡性能。
4. 链接必须有业务含义。 不能因为两个表能 Join，就认定它们有值得暴露的业务关系。
5. 动作围绕业务操作设计。 用“批准采购订单”，不要堆出几十个“修改某字段”。
6. 名称要让人和 Agent 都能理解。 用 lastInspectionDate，不要沿用难懂的源系统缩写。
7. 安全边界应与业务边界一致。 默认最小权限，再有意识地开放。
8. 使用真实业务问题验收。 例如，让未参与建模的人和 Agent 分别回答同一组业务问题，记录正确率、耗时、迷路位置和人工帮助次数。[20]
9. 迭代建设，不追求一次性“大一统”。 一个能被使用并持续改进的 Ontology，胜过永远停留在设计阶段的完美蓝图。[5]

常见反模式包括：[21]

• System Silos：按 HR、CRM、门禁等源系统分别建“员工”；
• Kitchen Sink：把所有 ETL 技术字段都暴露成业务属性；
• Department Silos：销售、客服、财务各建自己的客户；
• God Object：用一个有几百个属性的“资产”包揽设备、软件、房产甚至员工；
• Golden Hammer：所有问题都用 Action、Pipeline 或 Function 中的同一种工具硬解；
• Action Sprawl：每改一个字段就建一个动作；
• Time Machine：把同一实体的每个历史版本都建成新对象；
• Misnomer：使用 Item、value、related 等含义模糊的命名。

一个实用的起步方法是：选一个高价值决策，而不是先建“全企业本体”。 从这项决策反推必要对象、关系、逻辑、动作和权限，跑通闭环后再复用和扩展。

---

Ontology 有哪些被神化的地方？

Ontology 是一种强大的架构思想，但不是把旧系统“自动变智能”的魔法。

它不能自动修复坏数据

同一个客户在五个系统里身份冲突，仍需匹配、主数据治理、质量规则和责任人。Ontology 可以统一呈现问题，却不能凭概念图消除问题。

它的难点更多是组织工程，而不只是技术工程

哪些概念是全公司的共同概念？谁拥有定义权？销售和财务对“客户”的理解如何协调？哪些动作可以自动执行？这些都是治理问题。

它需要持续维护

企业、流程、法规和模型都会变化，Ontology 也必须像生产代码一样被版本化、测试、评审和演进。Palantir 自己也强调：结构正确并不等于可用，必须持续用真实任务验证。[20]

安全不是“配置一次就结束”

读取权限、动作权限、日志权限、模型输入输出、写回外部系统和下游数据传播是不同问题。Palantir 文档特别提醒：某些行列级读取控制只约束读取过程，并不会自动保护应用已经收到的响应载荷或模型输出；下游传播仍需相应标记与访问控制。[14]

它不是一个开放的通用标准名称

“Palantir Ontology”首先是一套具体产品架构。其他厂商也可能用知识图谱、语义层、数字孪生、业务对象层或企业上下文层解决相近问题，但能力边界、开放性和迁移成本并不相同。评估时应检查实际的数据接入、查询规模、写回一致性、权限传播、SDK、可观测性和供应商锁定风险，而不是只比较宣传术语。

自动化程度必须与风险匹配

补全客户标签和调拨关键医疗物资不是同一风险等级。低风险动作可以自动执行，高风险动作应采用场景模拟、提交条件、双人审批或人工最终确认。最合理的路径通常是：

只读问答 → 建议 → 暂存方案 → 人工批准执行 → 有边界的自动化

---

怎样判断一个“企业 Ontology”是否名副其实？

当厂商或团队声称自己在建设 Ontology 时，可以问十个问题：

1. 它表示的是现实业务对象，还是换了名字的数据库表？
2. 能否明确表达对象之间的业务关系？
3. 模型、规则和算法能否成为可复用的逻辑能力？
4. 是否存在一等公民式的业务动作，而不只是 CRUD API？
5. 动作能否安全写回现有业务系统？
6. 人和 Agent 是否遵守一致且细粒度的权限？
7. 能否先模拟方案，再提交真实变更？
8. 是否记录从输入、推理、审批到执行结果的完整链路？
9. 开发者能否通过稳定、类型安全的 SDK 构建应用？
10. 业务人员和一个没有隐性背景知识的 Agent，能否沿模型自然找到同一个可信答案？

如果答案只覆盖前两项，它更像语义模型或知识图谱；如果还能覆盖逻辑和查询，它是很好的决策支持层；如果十项大多成立，它才接近 Palantir 所说的 operational Ontology。

---

结语：它是“企业共同现实”的软件表达

理解 Palantir Ontology，最重要的不是记住 Objects、Links、Actions 这些名词，而是看见它背后的架构转变：

企业软件不应只保存分散的记录，而应形成一个人和 AI 共同理解、共同推理、受控行动并持续学习的业务世界。

在这个世界里：

• Objects 和 Links 描述现实是什么；
• Logic 解释怎样判断；
• Actions 规定怎样改变现实；
• Security 决定谁可以在什么条件下做；
• Engine 保证它可以被实时读取、计算、写入和同步；
• Toolchain 让应用与 Agent 都能在同一基础上工作；
• Feedback 和 lineage 让每次决策成为下一次决策的养料。

因此，Ontology 对 AI 行业最重要的启示也许是：企业 AI 的核心竞争力不只在模型本身，更在于企业能否把自己的现实、规则、能力、权限和反馈，组织成 AI 可以安全使用的上下文与工具。

大模型提供通用智力，Ontology 则试图提供组织现实。二者结合，AI 才可能从一个“会说话的模型”，变成一个真正理解业务边界、能够参与企业运营的数字同事。

---

参考文献

[1] Palantir, Ontology building — Overview.

[2] Palantir, Why create an Ontology?.

[3] Palantir, The Ontology system.

[4] Palantir, Ontology — Core concepts.

[5] Palantir, Ontology design: Best practices.

[6] Palantir, Object and link types — Link types overview.

[7] Palantir, Ontology design: Structural guidance.

[8] Palantir, Action types — Overview.

[9] Palantir, Action types — Webhooks.

[10] Palantir, Functions — Overview.

[11] Palantir, Models in the Ontology.

[12] Palantir, Interfaces — Overview.

[13] Palantir, Ontology architecture.

[14] Palantir, Ontology SDK — Overview.

[15] Palantir, Ontology scenarios — Overview.

[16] Palantir, AIP architecture overview.

[17] Palantir, Ontology-augmented generation; 另见 Semantic search — Overview.

[18] Palantir, Ontology — The central system for orchestrating decisions across Human+AI teams.

[19] Palantir, Ontology and AIP observability — Overview.

[20] Palantir, Ontology design: Validation.

[21] Palantir, Ontology design: Anti-patterns.

[22] Palantir, Palantir Foundry Ontology — Your Business as Code.