基于 Palantir Foundry 官方设计指南与行业实践经验，构建"像真实世界一样直观"的企业知识图谱。
四项原则按优先级排序，七个典型反例正反对照呈现。
Domain-Driven Design — 本体论建模真实世界，而非源数据
本体论的对象应代表语义上有意义的真实世界概念（如"患者""工单""船舶"），而非数据库表、API 响应或电子表格标签页。 链接应代表真实关系（如"该患者到访了该设施"），而非外键或 JOIN 关系的产物。
拿到一个数据集或 CSV，不做任何领域分析，直接将每一列映射为一个属性，把技术元数据（_crm_extracted_at、_crm_sequence）混入业务模型。源数据长什么样，本体论就长什么样。
// 一个 CSV 行 → 一个对象类型，所有列直接映射
OrderData {
order_id, customer_name, customer_email,
product_sku, quantity,
_crm_extracted_at, _crm_sequence, // 技术列也混入
}
先理解领域，再设计模型，最后映射数据源。一条 CSV 可能隐藏了多个实体（订单、客户、产品），需要拆分为独立对象类型并用语义链接关联。技术元数据留在后台数据集，不进入本体论。
// 从同一个 CSV 中识别出三个实体
Order { order_id, quantity } → 链接到 Customer、Product
Customer { name, email }
Product { sku }
// 技术列只存在于后台管道中，不出现在本体论
| ❌ 典型反例：从数据出发 | ✅ 正确模式：从领域出发 |
|---|---|
| 看到数据集 → 直接建模 | 理解领域 → 设计模型 → 映射数据 |
| 属性从源字段 1:1 映射，无筛选 | 属性经过精心筛选，只保留有业务含义的字段 |
| 命名使用源系统缩写（dtLastInspMod） | 命名使用业务语言（lastInspectionDate） |
| 一个 CSV 行直接变成一个对象类型 | 一条数据可能拆分出多个实体（订单→客户+产品+订单） |
| 技术元数据（_crm_extracted_at）混入业务模型 | 技术元数据留在后台数据集，不出现在本体论中 |
🎯 判断标准：一个用户或 AI 代理应该能够无需查阅文档，仅凭直觉就能在本体论中导航——因为它的结构匹配他们对领域的认知方式。
Don't Repeat Yourself — 同一实体只建一次，三次出现则重构
重复的对象类型、冗余的属性和复制粘贴的工作流是维护噩梦和上下文管理问题——对人类和 AI 代理都是如此。 目标是每个概念有唯一的规范化表示，每个操作有唯一的规范化工作流。
三个部门各自独立创建客户对象类型：Sales Customer、Support Customer、Billing Customer——每个都有 name/email/phone，加上各自的特殊字段。三套 Action、三套维护负担，同一客户信息还不一致。
Sales_Customer { name, email, phone, dealSize }
Support_Customer { name, email, phone, ticketHistory }
Billing_Customer { name, email, phone, paymentMethod }
// 同一客户在三个类型中都有记录，信息不一致
创建单一规范化 Customer 类型（方案 A），或使用 Interface 定义共享形状（方案 B）。一次出现是巧合，两次形成模式，三次必须重构。
// 方案 A：单一规范类型（推荐大多数情况）
Customer { name, email, phone, lifecycleStage }
// 方案 B：接口共享（类型形状确有本质差异时）
interface CustomerBase { name, email, phone }
SalesLead implements CustomerBase { + dealSize }
SupportContact implements CustomerBase { + ticketHistory }
Open for Extension, Closed for Modification — 保护核心模型，让构建者扩展它们
一旦一个对象类型、接口或工作流经过验证并投入生产，其核心结构就应保持稳定。 其他团队应该能在不修改核心模型的前提下，通过扩展来添加新能力。
新需求来了就往核心类型上塞属性。Equipment 类型本来只有基本字段，后来加入了认证信息、维护记录、财务折旧……最终膨胀为 150+ 属性、大部分为 null 的"万能对象"。
Equipment {
serialNumber, model, location, // 核心
certificationAuthority, certExpiry, certStatus, // 认证团队加的
depreciationMethod, bookValue, fiscalYear, // 财务团队加的
lastMaintenanceDate, mtbf, sparePartsList, // 维护团队加的
// ... 150+ 属性，大多为 null
}
核心类型保持精简，通过链接扩展类型和接口实现来添加新能力。核心类型不受影响，新能力按需扩展。
// 核心类型保持稳定
Equipment { serialNumber, model, location }
// 认证能力：链接到扩展类型
Equipment → EquipmentCertification { authority, expiry, status }
// 可巡检能力：实现接口
Equipment implements Inspectable { lastInspectionDate, inspectionStatus }
Composition over Deep Hierarchies — 多接口实现，保持可插拔
Foundry 本体论支持通过接口实现多重继承——一个实体可以从多个聚焦的抽象中组合行为， 而不需要陷入单一继承链的泥潭。
💡 关键洞察：构建在 SchedulableResource 接口上的工作流，不做任何修改就能用于 Arena、会议室和车辆——深层继承链永远做不到这一点。
除了四项核心原则，Palantir 还提供了四个关键的结构设计模式，它们是本体论的"语法规则"。
"每个事实只存一次。用派生属性提供便利访问。"
| ❌ Manager.directReportCount = 5（手动维护整数） |
| ✅ Manager.directReportCount = 派生属性（自动计数） |
| ❌ Employee.managerName = "Alice"（复制值） |
| ✅ Employee → manager（链接，自动获取 name） |
⚠️ 超过 ~10k 对象/查询时，考虑有意识地反规范化。
"将语义相关的字段组合为结构体，而非平铺为独立属性。"
| ❌ addressStreet, addressCity, addressState, addressPostalCode…（10 个独立属性） |
| ✅ address { street, city, state, postalCode, geopoint, llmConfidence }（一个结构体） |
💡 特别适用于 AI 输出场景：将主结果、置信度、推理依据打包在一起。
"用接口构建可复用、面向未来的抽象层。"
| ❌ Vehicle、Equipment、Facility 各自独立维护 inspectionDate + inspectionStatus |
| ✅ interface Inspectable { lastInspectionDate, inspectionStatus } — 一次定义，多处实现 |
🔑 能力接口（Inspectable, Schedulable）+ 分类接口（MilitaryAsset, MedicalDevice）
"链接应代表有语义意义的真实关系，而非外键。"
| ❌ Employee → Venture（直接链接，无法记录 role/startDate/allocation） |
| ✅ Employee → VentureStaffing { role, startDate, allocation } → Venture（对象化链接承载元数据） |
📌 关系本身有元数据（日期、角色、状态）→ 使用对象化链接类型。
以下典型反例与前述四项核心原则并非一一对应——它们代表不同维度的常见错误。理解它们的本质，比背诵分类更重要。
症状：手里只有锤子，看什么都像钉子。过度依赖某一种工具来解决所有问题。
// 用 Action 计算区域销售总额（用户需手动触发）
// 用 Pipeline 每分钟轮询一次新传感器数据
// 用 Function 计算 fullName = firstName + lastName
// 每项都用 Pipeline，每项都用 Action...
Action → 需要人工判断或用户输入的操作
Pipeline（批量）→ 聚合、清洗、预计算
Pipeline（流式）→ 持续低延迟处理
Automation → 事件驱动：变化了→该做什么
Function → 跨对象复杂实时计算
派生属性 → 基于链接的动态值
症状：为一个对象类型创建 20+ 个单属性 Action——UpdateFirstName, UpdateLastName, UpdateEmail... 把数据库 CRUD 操作直接暴露给用户。
Employee 的 Action 列表：
· Update Employee First Name
· Update Employee Last Name
· Update Employee Email
· Update Employee Phone
· Update Employee Department
· Update Employee Manager
// ... 20+ 个 Action
Employee 的 Action 列表：
· Update Contact Information
{ firstName, lastName, email, phone }
· Transfer to New Department
{ department, manager, location, effectiveDate }
· Onboard New Employee
{ all required + downstream triggers }
症状：把历史版本建模为独立对象或对象类型——Contract v1, Contract v2, Contract v3 或 Contract 2023, Contract 2024。
Contract_v1 { value: 100K, status: active }
Contract_v2 { value: 120K, status: active }
Contract_v3 { value: 120K, status: amended }
// 哪个是当前版本？链接该指向哪个？
Contract { currentValue: 120K, status: active }
→ ContractAmendment {
amendmentDate, previousValue, newValue, reason }
→ ContractAmendment { ... }
// 一个 Contract 对象 + 链接的变更记录
症状：使用模糊、通用或误导性的名称。用户频繁问"这个属性是什么意思？"
对象类型：Item（什么东西？）
属性：value（金额？数量？评分？）
属性：type（什么的类型？）
属性：date（创建？修改？到期？）
链接：Item → Related Item（什么关系？）
对象类型：Product / SalesOrderLineItem
属性：monetaryValue / quantityOnHand / riskScore
属性：productCategory / serviceTier
属性：orderPlacedDate / contractEffectiveDate
链接：Product → Purchasing Customer
链接：Employee → Supervisor
| ❌ 反模式命名 | ✅ 推荐命名 |
|---|---|
Item | Product / WarehouseInventoryRecord |
dtLastInspMod | lastInspectionDate |
nVAL01 | monetaryValue |
relatedItems（链接） | purchasingCustomers / supplier |
value | monetaryValue / quantityOnHand / riskScore |
单一工具依赖的解药是一个清晰的决策框架。每当你准备实现一个操作时，按以下步骤自查：
是 → Action Type（人类或 AI 代理驱动的决策与输入）
是 → 需要持续低延迟？→ Streaming Pipeline；否则 → Batch Pipeline
是 → Automation（事件驱动，监听本体论变化并编排 Action / 通知）
是 → Function（实时计算）或 派生属性（基于链接的查询时计算）
是 → Pipeline Transform（在数据管道中预计算，零运行时开销）
✅ 人工决策 · 用户编辑 · 输入驱动变更
❌ 批量计算 · 定时更新 · 无人工事件
✅ 批量处理 · 聚合 · 清洗 · 预计算
❌ 实时响应 · 需人工输入 · 对象级事件
✅ 持续低延迟 · 实时看板 · 实时增强
❌ 低频更新 · 人工输入 · 本体论事件
✅ 事件驱动 · 编排 Action · 触发通知
❌ 重数据处理 · 复杂多表 JOIN
✅ 跨对象实时计算 · 校验 · 实时派生
❌ 简单管道计算 · 大批量处理
✅ 基于链接的动态计算 · 自动保持正确
❌ 高频查询（>10k）· 复杂多跳逻辑
以下实践来自学术研究和企业架构社区的共识，与 Palantir 的核心原则互补而非竞争，为你的本体论设计提供更全面的视角。
采用成熟的上层本体论框架（如 gist、BFO、IDEAS）中已定义的通用概念——人、组织、协议、物理事物、时间、事件——而非每次从零开始。 gist 是其中最具实践性的选择，已包含企业建模中最常用的基础类别和关系。
来源：Semantic Arts · gist Ontology · Enterprise Architecture Community将现有的 BPMN 流程图、ER 图、UML 模型通过语义标注转化为本体论实体和关系。例如：BPMN 的活动节点 → 过程实体，数据对象 → 业务实体，决策网关 → 结果实体。 这使得现有企业架构投资可以平滑迁移到语义层，而非推倒重来。
来源：Semantic Lifting Methodology (2024) · BPMN-to-OWL Transformation为每个本体论实体和属性定义治理元数据：Owner（负责人）、Steward（数据管家）、Sponsor（业务发起人）。 这与 Palantir 的"跨团队协作"原则形成补充——光有协作精神不够，还需要明确的问责机制。
来源：Enterprise Ontology Governance · Essential Project · DAMA DMBOK在设计本体论之前，先对实体进行分类，是避免模型混乱的第一道防线。 我们建议将所有实体归入三种类型：业务/数据实体（客观存在的"名词"——客户、产品、设备）、过程实体（业务流程中产生的"动词"——巡检、审批、预警）、结果实体（决策输出后的"产出"——报告、推荐方案、预测结果）。 每创建一个对象类型时，先问：它是哪类实体？如果无法清晰归类，说明领域理解还需加深。
核心本体论（对象类型、接口、链接的定义）应集中治理以确保一致性；但数据填充和领域扩展可以由各业务域分布式负责。 这与 Palantir 的"对扩展开放"原则一脉相承：核心模型统一管控，扩展由各团队自主完成。
来源：Enterprise Ontology Rollout Patterns · Essential Cloud · Knowledge Graph Community不一致的命名是本体论最大的"技术债"——后期修复代价极高。
| 元素 | 规范 |
|---|---|
| 对象类型 | 单数、具体名词：Patient、WorkOrder |
| 属性 | 简洁自明：lastInspectionDate（非 dtLastInspMod） |
| 日期 | 统一后缀：createdDate、effectiveDate |
| 链接 | 双向可读：department ↔ employees |
用语义化的安全策略，而非复制对象类型来实现访问控制。
| 层级 | 控制 |
|---|---|
| 行级 | VIP 患者仅高级员工可见 |
| 列级 | 临床记录仅护理团队可见 |
| 单元级 | VIP + 临床记录 → 仅高级护理团队 |
🚫 不要为安全而复制对象类型（PublicPatient / RestrictedPatient）
Ontology Best Practices — 四项核心设计原则（领域驱动设计、DRY、开闭原则、组合优于继承）
palantir.com/docs/foundry/ontology/ontology-best-practicesOntology Structural Guidance — 规范化与派生属性、结构体、接口、链接类型、命名规范、安全设计
palantir.com/docs/foundry/ontology/ontology-structural-guidanceOntology Anti-Patterns — 八个典型反例：系统孤岛、不作筛选直接映射、部门孤岛、上帝对象、单一工具依赖、操作碎片化、版本即是对象、命名不当
palantir.com/docs/foundry/ontology/ontology-anti-patternsgist Upper Ontology — Semantic Arts 开发的上层企业本体论，包含人、组织、协议、事物、时间、事件等通用概念
semanticarts.com/gistSemantic Lifting Methodology (2024) — BPMN 模型到 OWL 本体论的语义标注与转换方法论
Knowledge Engineering · BPMN-to-OWL TransformationEnterprise Ontology Governance — DAMA DMBOK、Essential Project 的企业本体论治理框架
DAMA International · Enterprise Architecture CommunityOntology-Based Development of Industry 4.0 and 5.0 Solutions — Abonyi, Nagy, Ruppert (Springer, 2024)，知识图谱与语义建模优化复杂系统
Springer · 2024W3C Semantic Web Standards — OWL、SPARQL、SHACL、R2RML 等语义网标准
w3.org/standards/semanticwebEnterprise Ontology Rollout Patterns — 集中式治理 + 分布式填充的推行模式
Essential Cloud · Knowledge Graph Community四项核心原则是优先级排序的指南——发生冲突时，高优先级原则胜出。 理想设计不一定能即刻实现，但命名质量、语义清晰度和安全设计是后期难以修复的不变量——在这些方面绝不妥协。
一个在实际使用中产生价值的小缺陷本体论，远胜于仍在设计中的完美理论模型。