Palantir Study 13｜Interface 等高级类型：四种抽象怎么选

恒川工业的 BA 在白板上画了一个 Facility，准备让 Plant 和 Warehouse 都“继承”它。开发人员只问了一句：“初版应用做在 Workshop，而 Interface 目前不受 Workshop 支持，这个抽象准备交付给谁？”

会议安静了下来。

抽象不是把相似字段圈在一起，也不是让模型显得高级。它必须为真实消费方消除重复，同时不能制造产品支持、权限和迁移上的新债务。

本篇要解决的问题

上一篇解决了对象身份：ERP M-1042、WMS MAT1042-SH 和供应商门户 P-8821 经过规则确认后，才共同指向 Material / MAT-0001042。

身份稳定以后，重复开始出现：Plant 和 Warehouse 都有名称与位置；多个对象都有风险等级和生效日期；520 EA 总被拆成数量和单位；同一物料编码规则在 Pipeline 和 Ontology 中重复校验。

这些问题分别该交给 Interface、Shared Property、Struct 还是 Value Type？又在什么时候应该坚持使用普通 Object Type 和 Property？

一句话定义：
Ontology
 的高级类型构件，是在已有 Object Type 与 Property 之上复用对象能力、属性元数据、复合值结构或字段语义的建模机制；它们减少的是被证实的重复，不是代替具体
业务对象
。

“高级类型系统”是本系列对四类构件的教学分组，不是 Palantir 对外提供的一个独立产品名称。

先放回 Palantir 架构：四个词并不在同一层

它们都服务于 Foundry 管理的 Ontology，但职责和生命周期不同。

Interface 与 Object Type 都是 Ontology type，但一个抽象、一个具体。Shared Property 与 Struct 解决 Property 层的问题。Value Type 能用于 Ontology，却与 Space 绑定。Palantir：Value types overview

一张选择表：它们各自在复用什么

这四项并非成熟度阶梯。项目不会从 Local Property “升级”到 Struct，再升级成 Interface。它们回答的是四类不同问题。

Interface：统一的是对象能力，不是对象数据

接口（Interface）是一种抽象 Ontology type，用来描述 Object Type 应有的形状和能力。它可以包含 interface properties、Link Type constraints、Action Type constraints 与 metadata；一个 Object Type 可以实现多个 Interface。Interface 没有 backing dataset，不能直接实例化为 Object。Palantir：Interfaces overview

在恒川，具体对象仍然是：

• Plant / PLANT-EAST，由 ERP/MES 主数据支撑；

• Warehouse / WH-E01 与 Warehouse / WH-S02，由 WMS 支撑。

候选 Facility Interface 可以要求实现者提供 facilityName、location 等共同能力。它不产生一条名为 Facility-001 的记录，也不把 Plant 与 Warehouse 两份 datasource 合成一张表。

Interface 的价值出现在消费端。假设已确认两个工作流：TypeScript v2 Function 跨 Plant 与 Warehouse 检索供应节点；TypeScript OSDK 应用通过共同 API 展示设施。此时新增 ColdStorage Object Type 并实现 Facility，已有工作流可以少做一次按具体类型重构。

但若唯一消费方是初版 Workshop 页面，就不应为想象中的未来先建 Interface。按 2026-08-08 官方页面，当前支持面如下：

这张表是带日期的产品事实，不是永久能力承诺。项目发布超过 30 天或目标 enrollment 不同时，应重新打开官方文档核验。

在 Ontology Manager 中，建设者会看到带虚线边框图标的 Interface，配置属性与约束，再由具体 Object Type 实现。运营用户看到的仍应是 Plant、Warehouse 及其业务操作。

Shared Property：统一 metadata，不统一值

共享属性（Shared Property）是可被多个 Object Type 使用的 Property。它让团队一致建模，并在一个位置集中维护 Property metadata；各 Object Type 背后的数据仍然分别存在。Palantir：Shared properties overview

恒川可评估 externalReference Shared Property：Plant 从 ERP 取得外部编码，Warehouse 从 WMS 取得外部编码。两边共用名称、描述和展示语义，但各自的值和 datasource 仍然独立。

Ontology Manager 为 Shared Property 提供独立管理页面，并用地球图标标识。集中维护意味着一次 metadata 修改可能影响多个 Object Type，因此必须有 Owner 和变更评审。

以下情况不值得共享：两个字段都叫“状态”，但一个表示仓库营业状态，另一个表示缺料处置状态。名字相同不等于业务语义相同。若硬合成一个 Shared Property，只会把差异藏进枚举和说明文字。

Struct：把多个字段作为一个复合值

结构体（Struct）是 Ontology Property 的一种 base type，用一个有 schema 的 Property 容纳多个字段。上游字段可以来自不同数据源，但在定义到 Ontology 前，必须先转换为单一 struct type column。Palantir：Structs overview

例如 AP-2048 的调拨量可以候选建为：

transferQuantity = { amount: 520, unit: "EA" }

当金额和币种、数量和单位在该场景中必须作为一个整体读取和编辑，Struct 比两个彼此可能错配的普通字段更清楚。但“放在一起显示”不是充分理由。

如果某个字段组合需要独立 Primary Key、Link、Action、权限或生命周期，它已经更像一个业务对象。例如一条可被批准、撤销和对账的调拨任务，不应藏进 Allocation Proposal 的 Struct，而应评估独立 Object Type。

Struct 还有几条不能绕过的当前限制：

• 深度只有一层，不能嵌套，且至少包含一个字段；

• 当前字段类型只支持官方清单中的 primitive types；

• 数组中的 Struct 查询可能分别匹配不同元素的字段，不能想当然地按同一个元素成对命中；

• 不支持 Object Storage v1，因此对象数据必须走支持 Struct 的 Object Storage v2 路径；

• 当前只能从 Dataset 与 Restricted View 创建；OSDK 支持因语言而异，Functions 的参数和编辑能力也要按语言核验。

在产品里，建设者先在上游形成 struct column，再在 Ontology Manager 定义 Struct/Property 映射。当前 Action 可以创建或修改 Struct 值，Workshop 可以显示并把它作为变量使用，但这不等于所有入口都完整支持。

Value Type：统一“这个值是什么意思”

值类型（Value Type）是对 primitive field type 的语义包装，附加 metadata 与 constraints。Property 回答“哪个对象拥有哪个特征”，Value Type 回答“这个值属于什么领域类型、必须满足什么约束”。Palantir：Value types overview

恒川可为 canonical material ID 评估 MaterialId Value Type：底层仍是 STRING，但它明确表示跨系统归并后的物料身份，并可加入受控格式校验。Pipeline 字段和 Material.canonicalMaterialId Property 可以复用同一语义，不必每处依赖列名和说明猜测。

若 WarehouseCode 只在 Warehouse 一个 Property 上出现，Local Property 已经足够；同一语义进入多个 Pipeline、Object Type 或参数后，才评估 Value Type。

Value Type 与 Space 关联，只能在定义它的 Space 内使用；Default ontology 不可用。它还受权限和版本治理。“跨平台复用”不等于跨所有 Space 全局可见。Palantir：Value types overview

建设者定义 Value Type 后，可在 Builder pipeline 字段和 Ontology Property 上使用。变更约束前要检查版本兼容、既有数据与消费方。

四种错误抽象，怎样伤害缺料处置

抽象还会进入函数签名、Action 参数、SDK、权限和发布包。提前抽象未必专业；先获得复用证据，才有资格抽象。

BA 工作台：Ontology Abstraction Decision Card

Ontology Abstraction Decision Card 是本系列的 BA 实施资产，不是 Palantir 官方固定模板。它用于方案设计和变更评审，要求每个抽象候选同时说明收益、消费者和反证条件。

对其他三类候选，BA 可用同一张卡快速给出结论：

一套可以直接执行的决策顺序

本系列建议“至少两个具体 Object Type、两个已确认消费者”后再评估 Interface。这是实施归纳，不是 Palantir 官方准入规则；它的目的，是让抽象由使用证据驱动。

结论：抽象必须服务运行

Interface 复用对象的形状和能力；Shared Property 复用 Property metadata；Struct 把多个字段组成一个 Property 值；Value Type 复用值的领域语义和约束。四者都不能自动共享对象数据，也不能代替对象身份、Link、Action 和权限设计。

在恒川，Facility 是否成立，不取决于 Plant 和 Warehouse 看起来相似，而取决于是否有受支持的共同工作流。transferQuantity 是否成为 Struct，也不取决于页面排版，而取决于它是不是不可分的值，并能穿过 OSv2、数据源与消费入口的限制。

模型现在已经能表达“谁、有什么特征、怎样复用”。但缺料处置还有一个更难的问题：availableQuantity=760 EA 是此刻状态、每日快照，还是一段时间序列？供应商承诺从 8 月 12 日改到 8 月 18 日，应该覆盖当前值，还是保留为业务事件和当时证据？

本文依据 Palantir 公开资料、本地阅读笔记及实施研究整理，与 Palantir Technologies 无官方关联。“Ontology 高级类型系统”分组和 
Ontology Abstraction Decision Card 不是 Palantir 官方独立产品或固定模板。产品能力与支持矩阵可能变化，请以官方文档和目标环境为准。