本章以Palantir的系列博客为基础，初步探讨如何实现本体工程的构建。整体上看，一项本体工程大概包含下述几部分：

• 对象和链接类型 (Object and Link Types): 定义组织的语义是通过将现有的数据源映射为 ontology 中的对象、属性和链接来实现的。这远远超出了数据编目或模式设计的范围，ontology 能够为你提供强大的基础，以支持最终用户的工作流程，包括对所有字段的丰富元数据管理，以及针对所有变更实施的精细安全与治理机制。
• 操作类型与函数 (Action Types and Functions): 组织的动力学机制——即在遵循组织管理和控制规则的同时实现变革——在 Ontology 中通过各种动作类型和函数来定义。这些动作类型允许你收集组织中操作员的数据，或者协调与现有系统连接的决策过程；而各种函数则提供了一种方式来编写和扩展具有任意复杂度的业务逻辑。
• 接口 (Interfaces): 接口是一种本体类型，它描述了对象类型的形态及其功能。其实现了对象类型的多态性，使得我们可以以一种一致的方式对具有共同形态的对象类型进行建模和交互处理。
• 属性 (Property): 对象类型的属性，指的是现实世界中某个实体或事件的特定特征所对应的模式定义。属性值则指对象上某个属性的值，或者该现实世界实体或事件的单个实例的值。共享属性是指可以在本体中的多种对象类型上使用的属性
• 角色 (Roles): 角色是核心的权限管理者。类似于在 Foundry 文件系统中的角色机制，Ontology 中的角色也用于授予对本体资源的访问权限。角色可以在 Ontology 层面进行分配，也可以针对具体的资源进行设置。
• 对象视图 (Object Views): 对象视图是集中管理所有与特定对象相关的信息和工作流程的枢纽。其中包括关于该对象的关键信息、所有关联的对象、相关指标，以及与该对象相关的分析、仪表盘和应用程序等。

如何设计本体工程

对象类型与链接类型

对象类型

对象类型 (Object Type) 是指现实世界中某个实体或事件的模式定义。一个对象或对象实例 (Object or Object Instance) 指的是某个对象类型的单个实例；一个对象则对应现实世界中的某个单一实体或事件。一个对象集 (Object Set) 则是由多个对象实例组成的集合，也就是说，一个对象集代表了现实世界中一组实体或事件。

创建对象类型和实例的一个例子
在 Ontology Manager 中，您可以创建一种 Flight 对象类型，用于定义“所有航班”或该类型所有对象的特性。一个对象指的是 Flight 对象类型的单个实例，例如“JFK → SFO 2021-02-24”或“TLV → LHR 2020-04-16”。而像“所有到达的航班”这样的对象集合则代表了一个对象集。

在 Ontology 中，各个概念在数据集的结构中都有对应的概念，例如对象类型的定义与数据集中的数据集定义类似；而对象本身的定义则类似于数据集中的行定义。对象集的定义则类似于数据集中被筛选出的行集。例如，一个 Employee 数据集可以定义“所有员工行”的架构。在这种情况下，单行数据就代表一个员工，比如“Melissa Chang”、“Akriti Patel”或“Diego Rodriguez”。如果你根据任期来筛选数据集，就会得到一组代表“所有长期任职的员工”的行集。

与其说是一种抽象的数据模型，不如说“Foundry Ontology”是将每个本体概念映射到组织实际数据的一种方式。通过这种方式，这些数据资产能够用于支持现实世界中的各种应用。在用户应用中创建并显示对象时，只需在 Ontology Manager 中为某个对象类型添加相应的数据来源即可。例如，要创建 Employee 类型的对象，组织只需为 Employee 对象类型添加数据来源，然后将员工信息和其他企业数据链接到 Ontology 中。

链接类型

链接类型是一种用于定义两个对象类型之间关系的模式定义。链接指的是同一本体中两个对象之间关系的单个实例。同一类型的两个对象之间也可以存在链接关系，例如可以在 Employee 对象类型及其自身之间定义链接类型Direct Report ↔ Manager 。

创建链接类型和实例的一个例子
在 Ontology Manager 中，你也可以创建一种链接类型，将Flight 对象类型与Aircraft 对象类型连接起来，从而定义Scheduled Flight 和Assigned Aircraft 之间的关系。这种链接指的是Scheduled Flight → Assigned Aircraft 链接类型的单个实例，比如“JFK → SFO 24-02-2021”这个关系，以及与之对应的飞机型号“Boeing 737-123”。

注意，不同本体之间对象类型之间的链接是不被支持的。在这种情况下，您可能需要使用统一的本体来解决问题。这句话简单理解就是，不同的两套理论之间内容是无法构建联系的，因为体系都不一样，故而无法建立联系。

链接类型是一种双向类型：它总是具有两个方向，分别对应于它所关联的两个对象类型。链接类型的每个方向都可以独立地被访问，并且每个方向都有自己的显示名称和 API 名称。例如，一个Flight ↔ Aircraft 链接类型包括一个Flight 方向和一个Aircraft 方向。在代码中，调用flight.assignedAircraft.get() 可以访问链接类型的 Aircraft 方向，以获取分配给某个航班的飞机信息；而调用aircraft.flights.all() 则可以访问Flight 方向，以获取该飞机所负责的航班信息。

另外，可以在同一两个对象类型之间定义多种不同的链接类型。每种链接类型都代表一种独立的现实世界中的关系，而不是对现有关系的反向描述。例如，除了表示已分配飞机的Flight ↔ Aircraft 链接类型之外，还可以定义第二种独立的Flight ↔ Aircraft 链接类型，用于表示预定的维护记录。每种链接类型都需要具有唯一的 API 名称，这样应用程序就能区分不同的关系。

在 Ontology 中，那些核心概念在数据集的结构中也有相应的对应概念。Ontology 中对链接类型的定义，相当于两个数据集之间进行的连接操作；而链接的定义则相当于将某一行数据与另一个数据集中同一行的字段进行连接。例如，你可以将Employee 数据集与Company 数据集进行连接，从而探究Employees 与Employers 之间的关系。在连接后的数据集中，将“Melissa Chang”与她的雇主“Acme, Inc.”进行连接的那一行数据，就代表了一个链接。

与其说是一种抽象的数据模型，不如说“Foundry Ontology”是将每个本体概念映射到组织实际的数据上。通过这种方式，这些数据资产能够用于支持现实世界中的各种应用。在用户应用中，可以通过在 Ontology Manager 中为链接类型所引用的对象类型添加数据来源来创建和展示链接。对于那些对象类型之间存在多对多关系的链接类型，则还需要为这些链接类型本身添加数据来源。例如，要创建类型为Employee → Employer 的链接，组织就需要为Employee 和Company 这两个对象类型添加数据来源，并将它们的员工信息和其他企业数据连接到 Ontology 中。

操作类型与函数

操作类型

在 ontology 中，用户可以通过执行各种操作来对对象、属性和链接进行修改。操作是一种能够改变一个或多个对象属性的单一事务，这些操作是基于用户定义的逻辑来执行的。通过这种方式，用户可以在考虑整体目标的同时，管理和处理数据，而无需专注于对特定属性的编辑。一个动作类型指的是用户可以一次性执行的一系列对对象、属性值以及链接的修改或编辑操作。此外，它还包括在提交动作时所产生的各种副作用行为。

创建操作类型的一个例子
在 Ontology Manager 中，你可以创建一种名为 Assign Employee 的动作类型，用于定义用户如何更改给定 Employee 对象中的 role 属性值。这种动作类型可能需要一个参数定义，使用户能够以标准化的形式输入新的角色信息。此外，该类型还可以包含一些规则，用于自动在 Employee 对象和新的 Manager 对象之间创建链接。

与其说是一种抽象的数据模型，不如说“Foundry Ontology”是将每个本体概念映射到组织实际的数据上。这样一来，这些数据资产就能够为现实世界中的应用提供支持。随着用户决策和洞察被转化为对 Ontology 的修改，这些数据资产的价值和丰富性也会不断提升。

对对象、属性值和链接所做的任何更改，当用户执行操作时，都将提交到本体，并将反映在所有用户应用程序中。同样，相同的操作逻辑和验证可以在所有面向用户的应用程序中提供，确保对本体的一致编辑。包含用户编辑的最新版本的对象数据将被捕获在对象类型的回写数据集中。

函数

函数使得代码编写者能够编写出可以在操作环境中快速执行的逻辑。这些逻辑会在服务器端的一个隔离环境中被执行。这种机制适用于那些旨在支持决策过程的仪表盘和应用程序等场景。该功能提供了针对基于 ontology 的逻辑编辑的一流支持。这包括读取各种对象类型的属性、遍历链接关系，以及灵活地进行 ontology 的编辑操作。

函数的常见使用场景包括：

• 返回对象集或变量值，以便用于 Workshop 中。
• 通过 Workshop 提供的功能支持列，在派生表列中显示转换后的数值。
• 将对象类型的值汇总后用于展示在 Workshop 图表中。
• 对 ontology 对象进行复杂的编辑，通过一种由函数支持的操作来更新多个对象。
• 在后端运行逻辑，以将信息返回到 Slate 的前端界面中展示。
• 计算自定义指标或汇总数据，以便显示在 Quiver 中。
• 通过查询外部系统来利用其功能，从而丰富本体中的各种对象。
• 在 Pipeline Builder 中，将 Python 函数作为辅助容器来使用。

接口

接口是一种本体类型，用于描述某个对象类型的形态及其功能。接口使得具有相同形态的对象类型能够进行一致的建模和交互。例如， Facility 接口可能包含 Facility Name 和 Location 属性。 Facility 可以由诸如 Airport 、 Manufacturing Plant 或 Maintenance Hangar 这样的对象类型来实现，而这些对象类型各自可能包含额外的特定于类型的属性。

一个接口由接口属性、链接类型约束、操作类型约束以及关于该接口的元数据组成。接口属性可以在接口级别进行定义（推荐这样做），也可以使用共享属性来定义。多个对象类型都可以实现某个接口。

就像编程语言中的接口一样，你可以扩展一个接口来创建子接口，子接口可以继承父接口的特性，同时还可以在子接口中添加新的、更具体的属性。然后，各种对象类型可以实现该接口，表明它们符合该接口的定义。一个对象类型可以实现多个接口，以便在不同场景中使用。此外，接口也可以扩展多个其他接口，甚至包括那些又扩展其他接口的接口，这样就能实现通过多层接口来继承属性的效果。

在 Ontology 中，不同接口之间以及不同对象类型之间存在着功能上的差异，同时也存在风格上的差异。对象类型是非常具体的；它们由共享或局部属性来定义模式，由包含属性值的数据集来支持，并且可以实例化为具体的对象。相比之下，接口是抽象的概念；它们由接口属性来定义模式，不依赖于数据集，也无法直接实例化，而必须作为特定类型的对象来实例化。

属性

对象类型的属性，指的是现实世界中某个实体或事件的特定特征所对应的模式定义。属性值则指对象上某个属性的值，或者该现实世界实体或事件的单个实例的值。在 Ontology 中，各种概念与数据集结构中的相应元素相对应。在 Ontology 中，一个属性的定义相当于数据集中的一列，而属性值的定义则相当于数据集中的某个字段。

属性基础类型	可以作为标题键吗？	可以作为主键吗？	备注
String、Integer、Short	是	是	常用类型。
Date、Timestamp	是	不建议	时间值通常不适合作为主键，因为存储格式与显示格式不同，可能导致意外冲突或唯一性问题。多数情况下建议使用 String。
Boolean、Byte、Long	是	不建议	Boolean 会将对象类型限制为最多两个对象实例。Byte 属性只能在 Actions 中通过 Integer 参数赋值，因此多数情况下建议使用 Integer。Long 在 JavaScript 中存在表示问题，并非所有前端库和代码都能很好处理大于 1e15 的 Long 值。多数情况下建议使用 String。
Float、Double、Decimal	是	否
Vector	否	否
Array	是	否	Array 属性不能包含 null 元素。如果 Array 的内部类型不能作为标题属性，则该 Array 属性也不能作为标题属性。Object Storage V2 不支持嵌套数组。
Struct	否	否	Struct 属性不支持嵌套，字段也不能是数组。关于支持的字段类型，请参考 Struct 文档。
Media Reference、Time Series、Attachment	否	否
Geopoint	是	否	Geopoint 的值以逗号分隔的字符串形式存储，格式为latitude,longitude，例如57.64911,10.40744。
Geoshape	否	否
Marking	否	否
Cipher	是	否

角色与权限

查看、编辑和管理本体资源的权限是通过 Palantir 平台的文件系统 Compass 来管理的。本体资源被存储在一个项目中，而该项目的设置决定了谁可以查看、编辑和管理这些资源。这种基于项目的权限管理方式取代了之前的权限模型：本体角色机制以及由数据源生成的权限。它具有多种优势：

• 统一权限模型 (Unified Permission Model): ontology 资源使用与其他资源类型相同的权限系统。因此，你只需在一个地方学习和管理权限问题即可。
• 批量管理 (Bulk Management): 在项目或文件夹级别设置权限，从而能够同时控制多个资源的访问权限，这样就无需为每个单独的项目设置权限了。
• 权限说明 (Permissions Explainability): 在“安全”选项卡中，可以查看用于查看和编辑某个对象类型的必要权限，以及查看实例或执行操作的必要权限。
• 额外的隐私控制措施 (Additional Privacy Controls): 通过标记或将其置于用户没有权限访问的角色范围内，来隐藏敏感的本体资源。
• Compass 策划基础功能 (Compass Curation Primitives): 通过使用资源包和标签来组织本体资源；同时，利用角色分配或标记功能将不相关的资源隐藏起来，使用户无法访问这些资源。

对象视图

对象视图是可重复使用的对象数据表示形式。它们充当了与对象相关的所有信息的中心枢纽，包含了关于对象的关键信息，如属性数据、对象链接以及相关应用等，其包含两种类型：

• 标准对象视图 (Standard Object Views): 这是一种标准化、即插即用的表示方式，能够自动反映某个对象类型的配置信息。标准对象视图适用于所有对象类型，能够提供一种一致的方式来查看对象数据，而无需进行任何配置操作。了解更多关于标准对象视图的信息。
• 配置的对象视图 (Configured Object Views): 这些可完全自定义的表示形式是通过 Workshop 工具构建的，您可以对其进行配置，以为目标工作流程提供特定的体验。当某个配置好的对象视图被创建后，它就会成为默认的视图；不过用户仍然可以随时切换回标准的对象视图。

标准对象视图与配置好的对象视图一起存在，作为一级查看选项。当没有创建配置好的对象视图时，标准对象视图会默认显示；而一旦创建了配置好的对象视图，标准对象视图仍然可以访问。用户可以根据需要随时在标准对象视图和配置好的对象视图之间进行切换。

无论是标准对象视图还是配置好的对象视图，都有两种不同的外形规格可供选择，从而满足不同需求下的细节展示要求。这些不同的外形规格使得对象数据在不同工作流程中的呈现方式更加灵活：

• 完整对象视图 (Full Object Views): 对某个对象的全面概述，包含了所有相关信息的深入展示。
• 面板对象视图 (Panel Object Views): 该工具旨在与其他应用程序集成，重点在于展示特定工作流程中最关键的数据。

为什么要创建本体工程

在更深入前，首先需要问一个问题：为什么要创建本体工程？

本体工程体现了企业的决策过程，而不仅仅是数据本身。借助这一体系，组织能够基于不断变化的内外条件，实时做出最佳决策。传统的数据架构无法体现决策过程中的推理过程以及后续采取的行动，因此限制了学习的进行以及人工智能的应用。传统的分析架构无法将计算与现实世界联系起来，因此与实际操作相脱节。相比之下，以决策为中心的本体工程体系 (Decision-Centric Ontology) 能够将人类和代理直接连接到实际操作中，从而应对组织面临的最严峻挑战。

理解 Ontology 的价值

Palantir 将每一个运营决策模型化为四个组成部分：

• 数据 (Data): 用于做出决策的信息。
• 逻辑 (Logic): 用于评估决策的启发式方法和计算过程。
• 行动 (Action): 对所选决策的实施与执行过程。
• 安全性 (Security): 确保该决策符合相关操作规范。

Palantir Ontology 将这四种元素整合为一个可扩展、动态化的协作资源，从而能够根据组织不断变化的状况和需求来做出决策。

数据

本体工程不仅包括各种数据来源——结构化数据、实时数据、边缘数据源、非结构化存储库、图像数据等——还包括终端用户和决策者在做出决策时所生成的数据。 这种“决策数据”包含了关于特定决策的背景信息、各种可评估的选项，以及所选决策带来的后续影响。将各种企业数据与决策数据整合在一起，需要一种不同于传统数据库管理解决方案的架构，因为传统解决方案更适用于报表生成和分析需求。

Palantir Ontology 将数据整合到了企业中全面、精确的语义表示中。各种操作数据来源（如 ERP 系统、MES 系统、WMS 系统等）可以与其他来自物联网和边缘系统的数据流、非结构化数据存储库的相关数据、地理空间数据等进行同步处理并赋予其上下文信息。Ontology 将这些数据来源以对象、属性和链接的形式整合起来，这些元素能够实时更新，并可以直接嵌入到决策流程中。

逻辑

存储在 Ontology 中的数据得到了推理或逻辑的补充，这些推理或逻辑决定了何时以及如何做出特定的决策。决策逻辑的例子包括核心业务系统中的简单业务逻辑、使用云数据科学工作台维护的预测模型，以及利用多个数据源来制定运营计划的优化模型。

随着代理式编排技术 (agentic orchestration) 的出现，利用人工智能驱动的推理能力来利用这些逻辑资源就变得至关重要了。确定性函数、算法以及传统的统计过程可以作为操作工具，与大型语言模型和多模态模型的非确定性推理相结合，从而发挥出更大的作用。

Ontology 能够将所有逻辑资源——即决定决策制定的计算过程和算法——相互连接并赋予上下文意义，从而方便人类和智能体进行理解。这些资源包括与客户互动相关的业务逻辑，通常存在于CRM 和 ERP 系统 中；推动传统机器学习发展的建模逻辑，这些逻辑分布在各种数据科学环境中；以及那些与特定领域工具相关的规划、优化和仿真算法。

Ontology 的灵活“逻辑绑定”范式提供了一种统一的接口，使得可以构建能够整合来自不同环境中的异构逻辑资源的工作流程。这些环境包括本地数据中心、企业云环境、SaaS 环境，甚至是 Palantir 平台本身。这一特性使得将基于代理 (agent-driven) 的推理能力引入到需要处理多种逻辑关系的决策场景中成为可能，而这类场景过去一直属于人类用户的专属领域。

行动

当信息（数据）和推理（逻辑）都被整合到统一的表示形式中后，下一步就是执行和协调这些决策本身。能够在实时情况下做出决策，正是使操作系统区别于分析系统的关键所在。

Ontology 能够天然地将企业中的各种行为进行建模，形成一个统一的、以决策为中心的模型体系。如果将 Ontology 中的数据元素视为企业的“名词”（即语义上的、现实世界中的对象和链接），那么这些行为就可以被看作“动词”（即现实世界中的具体执行动作）。在每个由 Ontology 驱动的工作流程中，这些名词和动词都会通过人类或人工智能的推理被整合起来，形成完整的句子，这其中包含了各种逻辑元素。

将数据整合到语言模型中，并将其与用于评估决策的逻辑相结合是非常有价值的做法。不过，这种做法最终还是有限制的，因为除非这些决策能够以一种能够相互关联的方式与运营系统同步处理，使得每个决策都能为下一个决策提供指导，否则这种做法仍然难以发挥最大作用。而本体工程则使得人类和智能体的操作可以安全地作为场景来实施，这些操作可以使用与数据及逻辑基础元素相同的精细访问控制机制来进行管理，并且可以安全地写入到每一个企业级基础结构中（如事务系统、边缘设备、自定义应用程序等）。

安全性

在运营环境中，人类与代理之间的交互需要严格的安全与治理机制，这些机制必须超越传统基于角色的数据管理策略。Palantir 提供的一种安全架构结合了多种保护措施：

• 基于标记、目标和角色的政策 (Marking-, purpose-, and role-based policies)
• 在数据、逻辑、操作以及应用程序构件之间流动的动态谱系 (Dynamic lineage that flows across data, logic, action, and application artifacts)
• 一套完整的集成式变更与发布管理工具，适用于人工驱动的工作流程以及自动化工作流程 (A full suite of integrated change and release management tools that apply across both human-driven and agentic workflows)

细粒度策略 (Granular Policies) 可以限制代理人员以及人类在 ontology 中访问敏感或依赖于上下文的信息。这些策略在运行时会根据每次交互动态生成，结合了针对底层数据集施加的行级和列级限制、特定用户组的属性（包括通过 SSO 访问的用户）、贯穿底层数据管道的安全标记等要素来制定相应的访问控制规则。

工具的使用 (Tool Usage) 是通过相同的安全架构来动态控制的，该架构同时负责管理数据访问以及所有形式的内存访问。这样至少可以确保，任何工具的调用都依赖于对本体中基础对象、属性和链接的访问权限。此外，工具还可以包含依赖于详细提交标准的运行时验证机制。

每一个代理或人类行为都依赖于精确的授权许可，这些许可明确规定了允许进行的操作范围。这样能够有效防止意外的情况发生，比如查询跨越组织边界的数据，或者使用与未明确指定的外部系统连接的工具。此外，这种方式还能防止其他形式的特权滥用行为。

由于代理负责生成详细的遥测数据，因此日志的安全性与传输成为一个至关重要的问题。Palantir 允许管理员控制特定项目、工作流程以及代理之间对日志的访问权限。数据标记以及其他主动安全机制用于管理日志的访问权限，这些机制同样适用于对底层数据、逻辑以及操作基元的访问权限管理。

一个典型故事
Onyx 是一家医疗设备制造商，突然遇到外科口罩关键原材料供应中断。由于生产计划紧张、客户需求上升，这次中断可能影响大量未完成订单。
Onyx 先通过企业 Ontology 整合供应商、仓库、工厂、配送和客户订单数据，快速找出哪些生产线、库存和客户订单受到影响。然后，供应链团队调用接入 Ontology 的预测模型、分配模型和生产优化器，在沙盒场景中模拟不同材料替换和产能重排方案。
与此同时，Onyx 的 Disruption Bot 扫描企业数据、历史处置记录和可用模型，提出了一个人类分析师尚未考虑的新材料重新分配方案。该方案先在 Ontology 场景中模拟，再交给人类分析师审核。
方案通过后，Ontology 将决策转化为一组受控动作：仓库系统通过 API 更新，三个 ERP 系统通过 Ontology 连接器更新，生产计划系统通过异步文件接收变更。所有动作都有权限控制、测试机制、日志记录和审计能力。
危机结束后，这次决策的全部过程被记录下来，包括数据、模型、动作、人类审核和执行结果。这些记录会成为未来 Agent 决策、模型微调和组织流程优化的经验来源。

本体中的模型

将模型映射到 Ontology，可以理解为：把模型从一个独立的技术组件，纳入企业本体所描述的业务世界中。模型的输入、输出和使用场景不再只是字段、特征或数值，而是被绑定到具体的业务对象、属性和关系上。例如，模型输出的不是一个孤立的分数，而是某个客户订单的履约风险、某条生产线的预计延迟，或某种产品在未来一周的需求预测。这样具有三点优势：

• 可解释性 (Interpretability): 因为所有建模结果都是用现实世界的概念来定义的（比如某种物体的属性），所以用户无需理解机器学习原理就能使用建模结果。用户只需与诸如预测、估算或分类等简单的概念进行交互即可。
• 规模经济 (Economies of scale): 与其每个建模项目都是为特定用例而专门设计的，不如让建模成果随着时间的推移不断积累起来，为后续用例提供支持。例如，为一个特定用例生成的预测结果可以立即应用于其他用例，从而避免重复工作，并更快地为用户带来价值。
• 大规模的连通性 (Connectivity at scale): 通过整合机器学习模型，Ontology 成为了组织的单一权威来源，Ontology 不再只是企业数据的统一语义层，也开始成为企业逻辑的统一承载层。数据描述企业当前发生了什么，模型则表达企业对未来变化的判断和预期。当预测模型、优化模型、分类模型和仿真模型都被映射到 Ontology 中时，企业就能够在统一的业务语义空间里模拟不同决策的影响。

本体感知应用 (Ontology-Aware Applications)

Palantir Foundry 包含了一系列为在 Ontology 上原生运行而开发的应用程序。这些基于对象的应用程序共同构成了一个强大的分析和运营平台，能够支持多种使用场景和不同的用户需求：

• 对象视图 (Object Views): 对象视图是所有与特定对象相关的信息和工作流程的集中展示平台。这包括关于该对象的关键“背景数据”、所有关联对象、相关关键指标，以及指向该对象相关的分析工具、仪表盘和应用程序的链接或嵌入内容。
• 对象浏览器 (Object Explorer): 用于查询 ontology 层中各类对象的搜索与分析工具。用户可以灵活地构建搜索查询，从简单的过滤条件到复杂的搜索操作，以找到感兴趣的对象。之后，他们可以通过探索视图来查看这些对象集，或者将其以结果表格的形式呈现。此外，用户还可以比较不同对象集之间的差异，并对这些对象集执行批量操作（例如恢复数据）。最后，用户可以将这些对象集导出，或者将其打开在兼容的应用程序中，比如 Workshop。
• 容器 (Quiver): 通过可视化的点击式界面以及强大的图表库，使得在 ontology 层能够执行高级分析工作。Quiver 可以用于支持从简单的线性分析到包含聚合和统计功能的复杂分析等多种分析任务。此外，Quiver 还支持对时间序列数据的分析。Quiver 的分析结果可以被整理成只读的仪表盘，以便更广泛地共享和使用。
• 研讨会 (Workshop): 允许在 Ontology 层上直接构建无需编写代码的应用程序。在 Workshop 中构建的应用程序比其他类似的点选式工具所创建的应用程序更加动态和互动。通过利用高质量的布局设计以及易于使用且功能丰富的事件系统，Workshop 应用程序旨在实现与自定义 React 应用程序同样优秀的易用性和高质量体验。
• 面板 (Slate): 一种灵活的 Foundry 应用程序构建工具，可以与 Ontology 层进行交互，也可以直接与 Foundry 的数据集进行交互。基于 Web 开发范式，Slate 提供了丰富的可视化定制选项，并且拥有广泛的可用功能。
• 基平台 (Carbon): 能够整合多个资源或应用程序，为操作用户打造高度定制化的工作空间。通过整合各种分析结果（如仪表盘、Workshop 或 Slate 中的应用程序），以及诸如对象视图和对象浏览器这样的现成功能，Carbon 使得工作流程构建者能够完成最后的定制工作，从而为用户提供高度定制且实用的体验。
• 地图 (Map): 允许你在地理空间环境中整合和分析各种对象及其他数据。

Foundry Application	Primary Use Case	Workflow Style	Configuration Model	Objects or Datasets
Object Explorer 对象浏览器	Discovery 发现	Workflow-specific 特定于工作流程的运作方式	Walk-up usable 可立即使用的	Objects 对象
Quiver 颤抖	Discovery & Analysis / Analysis & Dashboards 发现与分析 / 分析与报表面板	Exploratory (for Analytical mode); workflow-specific (for Dashboard mode) 用于分析模式的探索性操作；用于仪表板模式的工作流特定功能	Walk-up usable (for Analytical mode); customizable (for Dashboard mode) 可随时使用的功能（适用于分析模式）；可自定义设置（适用于仪表盘模式）	Objects 对象
Workshop 研讨会/培训课程	Applications & Dashboards 应用程序与仪表板	Workflow-specific 特定于工作流程的运作方式	Customizable 可定制	Objects 对象
Slate 石板	Applications & Dashboards (complex) 应用程序与仪表板（复杂功能）	Workflow-specific 特定于工作流程的运作方式	Customizable 可定制	Objects (recommended) and Datasets 对象（推荐使用）和数据集
Map 地图	Geospatial 地理空间信息	Exploratory or Workflow-specific 探索性操作或特定于工作流程的操作	Walk-up usable 可立即使用的	Objects 对象

Palantir 的 Ontology Building 文档体系

Palantir 的 Ontology Building 文档体系组织如下：

Ontology building
├── Overview
├── Why create Ontology
├── Models in Ontology
├── Core concepts
├── Ontology-aware applications
├── Define Ontologies
│   ├── Ontologies
│   │   ├── Overview
│   │   ├── Branching the ontology
│   │   ├── Review proposals
│   │   ├── Shared ontologies
│   │   ├── Migrating between ontologies
│   │   └── Usage
│   ├── Object and link types
│   │   ├── Types reference
│   │   ├── Object types
│   │   ├── Properties
│   │   ├── Structs
│   │   ├── Shared properties
│   │   ├── Link types
│   │   ├── Object and link edits
│   │   ├── Value types
│   │   ├── Metadata
│   │   ├── Object type groups
│   │   └── Marketplace products
│   ├── Action types
│   │   ├── Overview
│   │   ├── Getting started
│   │   ├── Use actions
│   │   ├── Rules
│   │   ├── Parameters
│   │   ├── Submission criteria
│   │   ├── Function-backed actions
│   │   ├── Side effects
│   │   ├── Upload media and attachments
│   │   ├── Inline edits
│   │   ├── Permissions
│   │   ├── Monitoring
│   │   ├── Undo and revert
│   │   ├── Branching
│   │   └── Metrics and logs
│   ├── Functions
│   │   ├── Overview
│   │   ├── Feature support by language
│   │   ├── Getting started
│   │   ├── Types reference
│   │   ├── Branching
│   │   ├── Function management
│   │   ├── Function consumption
│   │   ├── Ontology edits
│   │   ├── API Gateway
│   │   ├── Notifications
│   │   ├── TypeScript v2
│   │   ├── Python
│   │   ├── TypeScript v1
│   │   ├── Functions on objects
│   │   ├── Functions on models
│   │   ├── Function interfaces
│   │   ├── Language models in functions
│   │   ├── Aliases
│   │   └── Unit testing
│   ├── Interfaces
│   │   ├── Overview
│   │   ├── Create interface
│   │   ├── Implement interface
│   │   ├── Edit interface
│   │   ├── Link types
│   │   ├── Action type constraints
│   │   ├── Extend interface
│   │   └── Metadata
│   └── Ontology design
│       ├── Best practices
│       ├── Structural guidance
│       └── Anti-patterns
├── Ontology search
│   ├── Semantic search
│   ├── Document processing
│   ├── Multimodal and embedding models
│   ├── Ontology augmented generation
│   ├── Palantir-provided models workflow
│   ├── Custom models workflow
│   ├── Search syntax
│   ├── Derived properties
│   └── Ontology scenarios
├── Applications
│   ├── Object Explorer
│   ├── Object Monitors [Sunset]
│   ├── Object Views
│   ├── Ontology Manager
│   ├── Vertex
│   ├── Machinery
│   ├── Foundry Rules
│   └── Map
├── Dynamic Scheduling
│   ├── Overview
│   ├── Getting started
│   ├── Core concepts
│   ├── Ontology primitives
│   ├── Gantt Chart widget
│   ├── Suggestion functions
│   ├── Search functions
│   ├── Validation rules
│   ├── Inline metrics
│   ├── Row-level interactions
│   ├── Schedule layer-level interactions
│   ├── Program Scheduling widget
│   └── Scheduling Calendar widget
├── Ontology architecture
│   ├── Overview and getting started
│   ├── OSv1 / OSv2 breaking changes
│   ├── Migration
│   ├── Aggregation considerations
│   ├── Object permissioning
│   ├── Indexing
│   ├── Object edits and materializations
│   └── Object databases
└── Release notes