深度解析 Palantir Ontology：从亚里士多德到企业数据操作系统的灵魂概念

Ontology 的演化时间线
======================

  公元前 350 年        亚里士多德《范畴篇》
       │              "存在的事物有哪些基本类别？"
       │
       ▼
  1960-1980 年        AI 知识表示（KR）
       │              语义网络、框架系统（Frame）
       │              "如何让计算机理解世界？"
       │
       ▼
  1990 年代           Tom Gruber 的定义
       │              "Ontology 是对概念化的明确规范"
       │
       ▼
  2001 年             Tim Berners-Lee 语义网（Semantic Web）
       │              RDF、OWL、SPARQL
       │              "让机器理解网页内容"
       │
       ▼
  2004 年             Palantir 成立
       │              "让分析师理解情报数据"
       │
       ▼
  2008-2014 年        Gotham Ontology 成熟
       │              "把 Ontology 从学术概念变成可运行的产品"
       │
       ▼
  2014 年             Foundry 发布
       │              "把 Ontology 推广到企业市场"
       │
       ▼
  2023 年             AIP 发布
       │              "LLM 通过 Ontology 理解和操作企业数据"
       │
       ▼
  2024-2025 年        Ontology 成为行业标准讨论
                      "每个企业都需要自己的 Ontology"

ObjectType: Employee（员工）
===============================

  属性（Properties）:
  ┌──────────────┬──────────┬──────────┬────────────────┐
  │ 属性名        │ 类型     │ 必填     │ 说明           │
  ├──────────────┼──────────┼──────────┼────────────────┤
  │ employeeId   │ String   │ ✅ (PK)  │ 员工编号       │
  │ name         │ String   │ ✅       │ 姓名           │
  │ department   │ String   │ ✅       │ 部门           │
  │ title        │ String   │ ❌       │ 职位           │
  │ hireDate     │ Date     │ ✅       │ 入职日期       │
  │ salary       │ Decimal  │ ✅       │ 薪资           │
  │ email        │ String   │ ✅       │ 邮箱           │
  │ location     │ GeoPoint │ ❌       │ 办公地点       │
  └──────────────┴──────────┴──────────┴────────────────┘

  派生属性（Derived Properties）:
  ┌──────────────────┬──────────────────────────────────────┐
  │ tenure           │ today() - hireDate （工龄）           │
  │ teamSize         │ count（直接下属）                       │
  │ totalCompensation│ salary + bonus + stock_value          │
  │ flightRisk       │ ML 模型预测的离职风险                  │
  └──────────────────┴──────────────────────────────────────┘

  安全 & 权限：
  ┌──────────────────┬──────────────────────────────────────┐
  │ salary 属性      │ 只有 HR + 直接上级 + C-Suite 可见     │
  │ flightRisk 属性  │ 只有 HR 可见                          │
  │ 整个 ObjectType  │ 所有登录用户可见（但受属性级权限控制）  │
  └──────────────────┴──────────────────────────────────────┘

LinkType 示例
==============

  Employee ──REPORTS_TO──→ Employee
  │                        │
  │ 属性：                   │
  │ - since: Date          │
  │ - dotted_line: Boolean │
  │                        │
  │ 约束：                   │
  │ - 基数： 1:N （一个员工一个直接上级，可有多个下属）
  │ - 方向性： 有向
  └────────────────────────┘

  Employee ──WORKS_ON──→ Project
  │                      │
  │ 属性：                 │
  │ - role: String       │
  │ - allocation: Float  │ (e.g., 0.5 = 50% 时间）
  │ - startDate: Date    │
  │                      │
  │ 约束：                 │
  │ - 基数： N:M （多对多）
  └──────────────────────┘

  Project ──DEPENDS_ON──→ Project
  │                       │
  │ 属性：                  │
  │ - dependencyType:     │
  │   "BLOCKS" | "SOFT"   │
  │                       │
  │ 约束：                  │
  │ - 无环（DAG 约束）
  └───────────────────────┘

# ActionType 定义示例

class TransferEmployeeAction:
    """将员工从一个部门转到另一个部门"""

    # 输入参数
    parameters:
        employee: ObjectType["Employee"]      # 要转移的员工
        target_department: String             # 目标部门
        effective_date: Date                  # 生效日期
        reason: String                        # 原因

    # 前置条件（Preconditions）
    preconditions:
        - employee.status == "ACTIVE"
        - target_department in VALID_DEPARTMENTS
        - requesting_user.role in ["HR_MANAGER", "DEPARTMENT_HEAD"]

    # 副作用（Side Effects）
    effects:
        - employee.department = target_department
        - employee.REPORTS_TO = target_department.head
        - CREATE AuditLog(action="TRANSFER", employee=employee,
                          from=employee.department, to=target_department)
        - NOTIFY target_department.head
        - NOTIFY employee

    # 权限
    permissions:
        - HR_MANAGER: can execute for any employee
        - DEPARTMENT_HEAD: can execute for own department employees only

    # 审批流
    approval:
        - if employee.level >= "DIRECTOR":
            requires_approval_from: ["VP_HR", "CEO"]
        - else:
            requires_approval_from: ["HR_MANAGER"]

派生属性示例
=============

  基础属性 → 派生属性
  ═══════════════════

  1. 简单计算：
     Order.total_amount = sum(OrderLine.quantity * OrderLine.unit_price)

  2. 跨对象聚合：
     Customer.lifetime_value = sum（所有关联 Order 的 total_amount)

  3. 时间窗口计算：
     Equipment.avg_daily_output_30d = avg（最近 30 天的 daily_output)

  4. 条件计算：
     Supplier.risk_level =
       CASE
         WHEN quality_issues_90d > 5 THEN "HIGH"
         WHEN quality_issues_90d > 2 THEN "MEDIUM"
         ELSE "LOW"
       END

  5. ML 模型推理：
     Customer.churn_probability = ml_model("churn_predictor",
                                            features=[tenure, usage_trend,
                                                      support_tickets_90d,
                                                      contract_renewal_date])

  6. 图遍历计算：
     Person.degrees_from_suspect = shortest_path(Person, SuspectList,
                                                  via=CONTACTED | MET_WITH)

  派生属性依赖图（DAG）:
  ┌───────────────────────────────────────────────┐
  │                                               │
  │  OrderLine.unit_price ──┐                     │
  │  OrderLine.quantity ────┼→ Order.total_amount  │
  │                         │        │             │
  │                         │        ▼             │
  │                         └→ Customer.LTV        │
  │                                  │             │
  │  Customer.tenure ───────────────┐│             │
  │  Customer.support_tickets ──────┼┤             │
  │  Customer.usage_trend ──────────┤│             │
  │                                 ▼▼             │
  │                        Customer.churn_prob     │
  │                                                │
  └───────────────────────────────────────────────┘

  关键规则：
  - 派生属性只能依赖基础属性或其他派生属性
  - 依赖关系必须形成 DAG（无环）
  - 当基础属性变化时，下游派生属性自动重算
  - 计算可以是实时的或批量的（根据性能需求配置）

ER 图 vs. Ontology 的区别
==========================

ER 图描述的是 "数据存储结构":
  ┌──────────────┐          ┌──────────────┐
  │ employees    │          │ departments  │
  │──────────────│          │──────────────│
  │ id      (PK) │    FK    │ id      (PK) │
  │ name         │─────────→│ name         │
  │ dept_id (FK) │          │ head_id (FK) │
  │ salary       │          │ budget       │
  │ hire_date    │          └──────────────┘
  └──────────────┘

  问题：
  1. 没有业务语义 —— "dept_id" 是什么关系？上级？归属？
  2. 没有派生属性 —— "工龄"不在表里
  3. 没有操作定义 —— "转部门"怎么做？
  4. 没有权限模型 —— 谁能看 salary？
  5. 没有业务规则 —— 转部门需要审批吗？

Ontology 描述的是 "业务世界模型":
  ┌──────────────┐          ┌──────────────┐
  │ Employee     │          │ Department   │
  │──────────────│          │──────────────│
  │ name         │          │ name         │
  │ salary [L]   │──BELONGS_TO──→│ budget  │
  │ tenure [D]   │          │ headcount [D]│
  │ flightRisk[D]│          │ avgTenure [D]│
  └──────────────┘          └──────────────┘
        │
        │  Actions:
        │  - TransferDepartment （需要审批）
        │  - Promote （需要 HR + 上级确认）
        │  - UpdateSalary （需要 CompBand 校验）
        │
  [L] = 受权限保护    [D] = 派生属性    Actions = 可执行操作

Ontology 类型生命周期
=====================

  ┌──────────┐     发布      ┌──────────┐
  │  DRAFT   │ ───────────→  │  ACTIVE  │
  │  草稿    │               │  活跃    │
  │          │               │          │
  │ 可自由   │               │ 生产使用 │
  │ 修改     │               │ 修改受控 │
  └──────────┘               └────┬─────┘
       ▲                          │
       │                     弃用（添加替代方案标注）
       │                          │
       │                          ▼
       │                   ┌──────────────┐
       │                   │ DEPRECATED   │
       │   回滚到草稿       │ 已弃用       │
       │   （罕见）         │              │
       └───────────────────│ 仍可查询     │
                           │ 不可新建实例  │
                           └──────┬───────┘
                                  │
                             归档（数据迁移完成后）
                                  │
                                  ▼
                           ┌──────────────┐
                           │  ARCHIVED    │
                           │  已归档       │
                           │              │
                           │ 只读         │
                           │ 历史审计     │
                           └──────────────┘

向后兼容策略
============

  变更类型         兼容性      策略
  ──────────────────────────────────
  添加可选属性      安全       旧应用忽略新属性
  添加派生属性      安全       旧应用不受影响
  添加 ActionType   安全       旧应用不调用即可
  重命名属性       需迁移      提供别名过渡期
  删除属性         破坏性      先 DEPRECATED → 迁移 → 再删除
  修改属性类型      破坏性      创建新属性 + 迁移 + 弃用旧属性
  删除 ObjectType  破坏性      DEPRECATED → ARCHIVED

"建模一次，处处使用" 示意图
============================

                    ┌──────────────────┐
                    │    Ontology      │
                    │                  │
                    │  ObjectType:     │
                    │   Employee       │
                    │   Department     │
                    │   Project        │
                    └────────┬─────────┘
                             │
            ┌────────────────┼────────────────┐
            │                │                │
            ▼                ▼                ▼
     ┌──────────┐    ┌──────────┐    ┌──────────┐
     │ 仪表板   │    │ 移动 App │    │ API      │
     │ Dashboard│    │ Mobile   │    │ (OSDK)   │
     └──────────┘    └──────────┘    └──────────┘
            │                │                │
            ▼                ▼                ▼
     ┌──────────┐    ┌──────────┐    ┌──────────┐
     │ Pipeline │    │ AIP/LLM  │    │ 报表     │
     │ 数据管道 │    │ AI 分析  │    │ Report   │
     └──────────┘    └──────────┘    └──────────┘

  所有这些应用共享同一个 Ontology。
  当 Ontology 变化时，所有应用自动感知。
  不需要为每个应用单独建模。

# 场景 1: HR 仪表板
# 直接使用 Employee ObjectType 的属性和派生属性
dashboard.add_chart(
    type="bar",
    data=ontology.Employee.group_by("department")
                          .aggregate(count(), avg("salary")),
    title="各部门人数与平均薪资"
)

# 场景 2: 审批流 App
# 使用 Employee ObjectType 的 ActionType
app.register_action(
    action=ontology.Employee.actions.TransferDepartment,
    ui="form",
    approval_chain=ontology.Employee.actions.TransferDepartment.approval
)

# 场景 3: API（OSDK）
# 外部系统通过 API 访问同一个 Ontology
@osdk.endpoint("/employees/{id}")
def get_employee(id: str) -> Employee:
    return ontology.Employee.get(id)
    # 自动应用权限控制： 调用者看不到 salary 除非有权限

# 场景 4: AIP（LLM 集成）
# LLM 通过 Ontology 理解业务数据
aip_query = "列出工龄超过 10 年、离职风险高于 70% 的资深员工"
# AIP 将自然语言转换为 Ontology 查询：
# ontology.Employee.filter(tenure > 10, flightRisk > 0.7)
# 并自动应用调用者的权限

# 场景 5: 数据管道
# ETL 过程写入同一个 Ontology
pipeline.transform(
    source="raw_hr_data",
    target=ontology.Employee,
    mapping={
        "emp_no": "employeeId",
        "full_name": ["firstName", "lastName"],  # 拆分
        "dept_code": lambda x: ontology.Department.resolve(x)  # 外键解析
    }
)

Ontology 锁定的四层结构
========================

  第 1 层： 数据锁定 (Data Lock-in)
  ┌────────────────────────────────────────────┐
  │ 企业的核心数据已经被整合到 Ontology 中      │
  │ 迁移 = 重做所有数据管道 + 映射 + 清洗       │
  │ 成本： $$$                                   │
  └────────────────────────────────────────────┘
         │
         ▼
  第 2 层： 模型锁定 (Model Lock-in)
  ┌────────────────────────────────────────────┐
  │ 企业的业务逻辑编码在 ObjectType/LinkType/   │
  │ ActionType/DerivedProperty 中               │
  │ 迁移 = 重新定义所有业务模型                  │
  │ 成本： $$$$                                  │
  └────────────────────────────────────────────┘
         │
         ▼
  第 3 层： 应用锁定 (Application Lock-in)
  ┌────────────────────────────────────────────┐
  │ 数十个仪表板、App、API、管道基于 Ontology   │
  │ 迁移 = 重建所有下游应用                     │
  │ 成本： $$$$$                                │
  └────────────────────────────────────────────┘
         │
         ▼
  第 4 层： 认知锁定 (Cognitive Lock-in)
  ┌────────────────────────────────────────────┐
  │ 团队已经习惯用 Ontology 的思维方式          │
  │ "Customer 有 LTV"、"Order 有 FULFILLED_BY"  │
  │ 成为团队的共同语言                          │
  │ 迁移 = 改变整个组织的思维方式               │
  │ 成本： 无价                                  │
  └────────────────────────────────────────────┘

价值 = f(ObjectType 数量， LinkType 数量， 用户数， 应用数）

  为什么超线性？
  - 10 个 ObjectType 之间可能有 45 种关系 (C(10,2))
  - 20 个 ObjectType 之间可能有 190 种关系 (C(20,2))
  - 每增加一个 ObjectType，它可以与所有已有类型产生关联
  - 每个新关联可能产生新的派生属性和 Action
  - 每个新派生属性可能驱动新的仪表板和应用

对比维度： 关系的语义丰富度
===========================

ER 图中的关系：
  employees.dept_id → departments.id

  这告诉你：
  ✅ 两个表有外键关联
  ❌ 这是什么业务关系？（归属？管理？临时借调？）
  ❌ 这个关系有属性吗？（从什么时候开始？）
  ❌ 这个关系有方向吗？
  ❌ 这个关系有基数约束吗？（除了 1:N）

Ontology 中的关系：
  Employee ──BELONGS_TO──→ Department
    │ since: Date
    │ primary: Boolean
    │ cardinality: N:1

  Employee ──TEMPORARILY_ASSIGNED_TO──→ Department
    │ since: Date
    │ until: Date
    │ reason: String
    │ cardinality: N:M

  两个完全不同的业务关系，在 ER 图中是同一个外键。

对比维度： 运行时能力
=====================

UML 类图：
  ┌──────────────────┐
  │ Employee         │
  ├──────────────────┤
  │ - name: String   │
  │ - salary: double │
  ├──────────────────┤
  │ + getName()      │
  │ + setSalary()    │
  │ + transfer()     │
  └──────────────────┘

  这是一个设计时的蓝图。它需要被编译成代码才能运行。
  修改 UML → 修改代码 → 编译 → 测试 → 部署

Palantir Ontology:
  ObjectType Employee 是一个运行时对象。
  修改 ObjectType → 立即生效（热更新）。
  不需要重新编译、不需要重新部署。

  这就像修改 Excel 公式 vs. 修改 Java 代码的区别。