本文将进一步深入本体的构建，进一步基于 Palantir 系统深入探索本体工程构建的结构化方法。

分支 (Branching)

在进一步深入本体前，我们首先要了解分支 (Branching) 这一概念。其一般常见于软件开发，善用分支可以使项目推进得到较好的协调。

分支工作流程 (Branching workflow) 主要包含下述步骤：

• 创建分支 (Create a Branch)
• 做出改动 (Make Changes)
• 提出合并 (Create Proposal)
• 审核改动 (Review Changes)
• 实现合并 (Merge Changes)

分支和提案的生命周期 (Branch and proposal lifecycle)

分支的生命周期

当创建一个分支后，其状态会被设置为“活跃”。此后，该分支可以进入以下状态之一：非活跃、已归档或已合并。四种可用的分支状态定义如下：

• 活跃 (Active): 指的是正在被处理或正在进行合并过程的分支。在活跃状态下，该分支上构建或索引的数据会被保留下来，直到该分支不再处于活跃状态为止。
• 非活跃 (Inactive): 当一个分支在设定的无活动期间后，会自动被标记为非活动状态。在这种情况下，该分支中的本体资源会被从索引中移除，并且数据会在指定的天数后被删除。处于非活动状态的分支中的资源构建将立即失效。当某个分支被标记为非活动状态时，该分支的负责人会收到一封电子邮件通知，同时还会收到平台内的通知。
• 已归档 (Archived): 指的是那些不再被维护的分支。归档操作通常是手动进行的。分支负责人会收到一封电子邮件通知，同时会在平台上收到提示。在已归档的分支上进行索引删除、构建失败或数据删除等操作，其效果与对不活跃分支的操作相同。曾经修改过的元数据会被保留下来，而且已归档的分支仍然可以被恢复。已归档的分支不会出现在分支选择器中，但可以在“全局分支管理”应用程序中打开和恢复这些分支。
• 已合并 (Merged): 该分支的提案已合并到其他分支中。已合并的分支是不可恢复的，不会出现在分支选择器中，只能通过全局分支应用程序访问。

提案的生命周期

提案可能处于三种状态之一：

• 开放状态 (Open): 指正在执行或已获批准的提案。
• 已合并(Merged): 该提案已合并到main 分支中。
• 已关闭(Closed): 该提案已关闭，并未被合并。

为本体创建分支 (Branching the ontology)

在需要拓展本体或者对本体做出改进时，可以创建分支；同时分支保护会被触发，用于进行资源保护。

其余部分和 Github 的 Branching+PR 类似。

审核提案

一个本体提案可以类比于版本控制系统中的“拉取请求 (PR)”。这些提案作为一种机制，用于审查和批准在独立分支中所做的修改，之后再将这些修改整合到main 中。

在本体之间迁移本体资源

每个本体资源都会自动链接到其创建时的本体。在资源创建后，用户可以将其在不同本体之间移动。在多个本体之间迁移资源时，资源的权限也会发生相应的变化。不过，这种变化不会影响底层数据和输入数据源的权限。当在多个本体之间迁移对象时，所有编辑内容都将被保留下来。

计算资源使用

计算资源使用：本体索引处理 (Compute usage: Ontology indexing)

Foundry 的 Ontology 将对象存储在一个 Ontology 索引中，这种存储格式旨在实现快速访问。Foundry 数据集中的数据可以是任意大小或格式，因此需要对数据进行处理，以使其适合存储在 Ontology 索引中。这个过程被称为 Ontology 索引化，可以应用于任意大小的数据集和对象。Ontology 索引化的处理成本以计算秒为单位衡量。

Ontology Indexing 利用基于 Spark 的并行处理技术，能够读取任意大的数据集，并将其转换为 Ontology 格式。执行索引任务所消耗的计算资源数量，取决于计算节点的数量以及索引任务本身的总执行时间。

Ontology 索引任务会在 Foundry 的 Builds 应用程序中显示，并且会附加到正在被索引的对象上。Ontology 索引任务属于 Spark 任务，因此可以被归类为并行化的批处理计算任务。因此，Ontology 索引任务可以像其他任务一样在相同的后端上进行性能评估，比如代码仓库的转换任务以及 Contour 查询任务。

索引任务可以根据其触发方式进行分类：

• 本体索引作业将数据集索引到本体后端中。这些计算资源用于从数据集中生成已索引的对象。
• 在 Ontology 导出作业中，会保留在 Ontology 中直接进行的修改内容，这些修改会被迁移到 Foundry 的数据集中。与完整索引作业相比，这些导出作业通常规模较小，因为它们处理的修改内容通常只是整个对象集的一小部分。

计算资源使用：通过本体查询实现计算用途 (Compute usage with Ontology queries)

对象类型与对象集 (Object Types and Object Sets)

对象类型是指实体本身的语义表示（例如，对象的名称和属性）。一个对象类型对应着一个对象集，而对象集包含了具体的对象本身。对象集的大小取决于传入数据集的行数，以及由 Ontology 操作所创建和删除的对象数量。

查询类型 (Query Types)

包括过滤、聚合、搜索范围以及写回操作等。每种查询类型都需要进行计算处理。

通过本体查询来调查 Foundry 的计算使用情况

在 Ontology 查询中，计算资源的分配有多种方式。通常情况下，计算资源会分配给发起查询的实体。不过，如果不存在可用于生成计算资源的已保存实体（例如通过 API 获取），那么计算资源就会分配给被查询的实体本身。如果在一个请求中查询多个实体，那么计算资源就会平均分配给这些实体。

对象集服务的限制 (Object Set Service Limitations)

对象集服务（OSS）负责从知识库中查询和获取对象。该服务采用分层执行策略，以平衡性能与可扩展性，能够根据查询的规模和复杂性自动选择最佳执行方式。

OSS 采用分层执行策略，能够自动选择最适合处理您查询的方法：

• 推送到存储层 (Pushdown to storage layer): 对于简单的查询，OSS 直接将操作推送到存储层，以利用索引化数据结构带来的优势。这是最快的执行路径，且所需的计算资源最少。
• 内存执行模式 (In-memory execution): 对于需要更复杂操作的查询，OSS 会将数据加载到内存中，以实现快速处理。这种方式适用于中等规模的查询场景。
• 基于 Spark 的执行方式 (Spark-based execution): 对于超出内存处理能力的大规模查询，OSS 会自动切换到基于 Spark 的分布式计算方式。虽然这种方式可以处理更大规模的对象集，但也会带来额外的延迟和计算资源消耗。

Strategy	When Used	Performance	Compute Cost	Use Cases
Pushdown to storage 将物品推入存储区域	Simple filters and aggregations 简单的过滤和汇总功能	Fastest 最快的	Lowest 最低的	Basic queries that can be resolved by indexed lookups 可以通过索引查询来解析的基本查询
In-memory execution 内存中执行	Object sets ≤100k 对象数量 ≤100k	Fast 快速	Moderate 中等程度	Most Search Arounds, moderate-scale queries 大多数搜索查询，中等规模的查询
Spark-based execution 基于 Spark 的执行方式	Object sets >100k 对象数量超过 10 万	Slower (higher latency) 较慢的（延迟较高）	Higher 更高	Large-scale Search Arounds, complex multi-step queries 大规模搜索操作，复杂的多步骤查询

本体设计：最佳实践 (Ontology design: Best practices)

现在，可以整理出本体设计的最佳实践。一个设计良好的 ontology 能够创建出一个统一的、直观的组织结构表示方式，从而实现数据的无缝集成、跨职能协作以及强大的数据分析能力。以下指南是 Ontology 设计的一项实用清单。在适用的情况下，每一项指南都基于一个核心设计原则、反模式或结构建议来制定。

• 模拟现实，而非系统 (Model reality, not systems): 对象类型应该代表现实世界中的实体，而不是单个源系统或部门的表现形式。
  • 设计原则 (Design principle): 领域驱动设计
• 我们刻意进行了这样的筛选 (Curate intentionally): 每个属性都应具有明确的企业或技术价值。
  • 结构性建议 (Structural recommendation): 规范化处理以及衍生出的属性
• 跨团队合作 (Collaborate across teams): Ontology 的设计应该涉及多个部门或团队的参与者。孤立的团队是导致工作重复的主要原因之一。
  • 设计原则 (Design principle): 避免重复使用相同的代码
• 保持对象类型的明确性 (Keep object types focused): 每种对象类型都应该代表一个独立的实体。
  • 设计原则 (Design principle): 领域驱动设计
• 选择合适的工具 (Choose the right tool): 对于人类决策，使用相应的操作类型；而对于自动化转换，则使用相应的流程。
  • 反模式 (Anti-pattern): 金锤定律
• 使用接口进行抽象 (Use interfaces for abstraction): 当实体具有共同特征时，通过接口来建模抽象，而不是创建大量分散的对象类型。
  • 设计原则 (Design principle): 优先使用组合结构，而非深层次的层次化结构
• 记录你的决策 (Document your decisions): 在 Ontology Manager 中记录对象类型、属性和关联信息。

核心设计原则 (Core design principles)

这四条原则源自于在政府和商业领域中的广泛实践经验。它们按照优先级顺序排列。在存在冲突的情况下，优先级较高的原则会优先适用。

Priority (优先级)	Principle (原则)	Core idea (核心思想)
1	Domain-driven design 领域驱动设计	Model the real world, not the source data. 模拟现实世界的情况，而不是使用原始数据。
2	Don’t repeat yourself 不要重复同样的内容	If you built the same thing three times, refactor. 如果你重复构建了同一个项目三次，那么就需要进行重构了。
3	Open for extension, closed for modification 对扩展开放，对修改关闭	Protect core models. Enable builders to extend them. 保护核心模型。让开发者能够对其进行扩展。
4	Composition over deep hierarchies 优先组合而非深层结构	Favor multiple inheritance via interfaces. Keep things pluggable. 通过接口实现多重继承功能。保持组件的可插拔性。

领域驱动设计

本体模型建模现实世界，而非源数据。
The Ontology models the real world, not the source data.

本体工程的对象应该代表具有语义意义的现实世界概念 （例如Patient 、WorkOrder 或Vessel ），而不是数据库表、API 响应或电子表格标签页。链接则应该表示现实世界中的关系（“这位患者曾到这家医疗机构就诊”），而不是连接键或外部键的伪象。

当被要求“为数据集构建一个本体”时，不要急于将第 1 列映射到各种属性上，而是要考虑整个系统的结构。这种“厨房水槽”反模式会导致生成的本体只反映源系统的结构特点，而忽略了其中的有用语义。一个设计良好的本体应该易于使用；用户或 AI 代理能够轻松导航这个本体，因为它的结构与他们已有的领域认知方式相匹配。(作者按：即精简原则，不因谨慎导致冗杂 )

例如，一个包含列order_id 、customer_name 、customer_email 、product_sku 和quantity 的 CSV 文件，它描述的是至少三个现实世界中的实体，而不是只有一个实体。

✗ Avoid                                    ✓ Prefer
──────────────────────────────────────   ──────────────────────────────────────
OrderData                                  Order
  - order_id                                 - order_id
  - customer_name                            - quantity
  - customer_email                →          - Links to → Customer, Product
  - product_sku
  - quantity                               Customer
                                             - name
(One object type mirroring the CSV)          - email

                                           Product
                                             - sku

                                           (Three object types modeling the domain)

一些反模式及其影响包括：

Problem (问题)	Impact (影响)
Unintuitive model 不直观的模型	Users and AI agents cannot navigate the Ontology naturally because the structure does not match how they think about the domain. 用户和人工智能代理无法自然地浏览本体 (Ontology)，因为该结构与他们对该领域的思维方式不匹配。
Fragile coupling to source 与源系统的脆弱耦合	Schema changes in source systems break Ontology consumers because the Ontology mirrors source structure rather than abstracting over it. 源系统中的模式 (schema) 变更会破坏本体的消费者，因为本体直接镜像了源结构，而不是对其进行抽象处理。
Missed relationships 遗漏的关系	Entities embedded as columns (likecustomer_name on an order) cannot be linked, searched, or reasoned about independently. 那些以列的形式嵌入的实体（比如订单中的customer_name）无法被独立链接、搜索或进行逻辑推理。
Poor reuse 较差的复用性	Object types shaped by one system’s schema are difficult for other teams or use cases to adopt. 由某个系统的模式塑造的对象类型，其他团队或应用场景很难采用。

一些最佳实践包括：

• 在查看源模式之前，先确定现实世界中的实体 (Identify real-world entities before looking at source schemas): 与领域相关的人士合作，明确哪些概念是重要的。通常，一个数据集会描述多个实体。
• 与观察相分离的身份 (Separate identity from observation): 如果一行数据代表了一个关于实体的测量或事件，那么实体和观察对象很可能是不同的对象类型。
• 为人类提供直观的命名方式 (Name things for humans): API 的名称应该易于理解且能够自述其含义。建议使用person.children 而不是person.linkedChildPersonObjects 。同样，建议使用equipment.lastInspectionDate 而不是equipment.dtLastInspMod 。
• 了解领域的特点，然后设计对象模型 (Model the domain, then map the data): 先了解领域的特点，然后再设计对象模型；接着将源数据映射到该模型中。不要试图直接模仿数据的形态来设计模型。
• 将非语义类型标记为隐藏 (Mark non-semantic types as hidden): 当非语义类型（即那些用于技术目的而非用于建模现实世界实体的类型）对于特定工作流程来说是必要的时，可以将其标记为隐藏状态，这样就能保持本体结构的整洁。这些类型仍然可供开发者在构建应用程序时使用。

避免重复使用相同的信息 (Don’t repeat yourself)

如果你重复构建了同一个项目三次，那么就需要进行重构了。
If you built the same thing three times, refactor.

重复的对象类型、多余的属性，以及复制粘贴式的工作流程，都是维护上的负担，也是处理上下文管理问题时的难点。无论是人类还是需要理解 ontology 的人工智能代理，都面临这样的挑战。我们的目标是为每个概念提供单一的规范化表示方式，为对该概念进行的每项操作制定单一的标准化流程。“三例法则”是实施这一原则的实际指导原则：第一个实例属于巧合，第二个实例则呈现某种模式，而第三个实例则意味着是时候进行重构了。

一些反模式包括：

• 多种对象类型共享相同的属性和类似的关联关系。
• 同样的派生属性逻辑或操作逻辑在多种类型中都有出现。
• 不同的团队为了不同的目的而创造了几乎相同的物体类型。
• 这些复制粘贴式的工作流程在不同类型中存在一些差异。

Problem (问题)	Impact (影响)
Maintenance burden 维护负担	Changes must be replicated across every duplicate. Missed updates causedata drift between copies. 这些更改必须被复制到每一个副本中。未及时更新会导致副本之间出现数据漂移。
Ambiguous context 上下文模糊	Users and AI agents cannot determine which of several near-identical types iscanonical. 用户和人工智能代理无法确定在多个几乎相同的类型中，哪个才是规范版本。
Inconsistent behavior 行为不一致	Duplicatedaction orderived property logic diverges over time, producing conflicting results. 重复的操作或派生属性逻辑会随着时间推移产生分歧，导致结果冲突。
Wasted development effort 开发资源浪费	Teams re-build the same thing in slightly different forms instead of collaborating on oneshared model. 各团队只是以略有不同的形式重复开发相同的事物，而不是合作维护一个共享模型。

✗ Avoid                                    ✓ Prefer
──────────────────────────────────────   ──────────────────────────────────────
Sales Customer                             Customer (single canonical type)
  - name                                     - name
  - email                                    - email
  - phone                                    - phone
                                             - salesStatus
Support Customer                   →         - supportTier
  - name                                     - billingAccountId
  - email
  - phone                                 — OR, if shapes are genuinely distinct —

Billing Customer                           Interface: CustomerBase
  - name                                     - name
  - email                                    - email
  - phone                                    - phone

(Three types, three sets of actions,       Implemented by: SalesLead, SupportContact,
 three maintenance burdens)                BillingAccount

一些最佳实践包括：

• 检查重复项 (Audit for duplicates): 如果多个对象类型具有相同的形状（相同的属性、类似的链接和动作），那么需要确定它们是否应该被归为同一类型，并赋予一个独特的属性；还是应该实现某个共享接口。
• 整合共享逻辑 (Consolidate shared logic): 如果相同的派生属性或操作逻辑出现在多个类型中，将其提取出来，形成一个接口或共享函数。
• 统一特定团队的副本 (Unify team-specific copies): 当不同的团队创建了几乎相同的对象类型时，将它们合并为单一的规范化表示形式，同时具备适当的安全防护或过滤功能。
• 遵循“三法则” (Apply the rule of three): 如果有一个副本是可行的，那还算可以接受。如果有两个副本有问题，那就有警示信号了。如果有三个副本都有问题，那就需要重新设计了。

开源拓展，也不影响闭源优化 (Open for extension, closed for modification)

保护核心模型，同时让开发者也能对其进行扩展。 Protect core models. Enable builders to extend them.

一旦某个对象类型、接口或工作流程经过测试并投入生产使用，那么它的核心结构就应该保持稳定。组织中的其他开发人员和团队可以在此基础上进行扩展，添加新的实现了特定接口的对象，或者创建新的工作流程来使用现有的对象，而无需修改核心模型。

一些反模式及其影响包括：

• 经常对已建立的对象类型进行修改，而这些修改会逐级影响到依赖这些对象的应用程序。
• 新的使用场景需要修改现有的核心类型，而不是对其进行扩展。
• 团队需要编辑共享的界面或操作，以满足各自团队的具体需求。
• 某个团队扩展中的安全变更，可能会无意中影响到其他用户的使用体验。

Problem (问题)	Impact (影响)
Breaking changes 破坏性变更	对核心类型的修改可能会破坏全组织内依赖的应用程序 (applications)、动作 (actions) 和工作流程 (workflows)。
Scope creep 范围蔓延	核心类型会为每个新的使用场景不断累积属性和逻辑，逐渐演变成上帝对象 (God Object)。
Entangled ownership 所有权交织	多个团队修改同一个核心类型，从而导致合并冲突 (merge conflicts) 和责任划分不清。
Security leakage 安全漏洞	在没有清晰边界的情况下扩展核心类型，可能会无意中扩大数据访问权限 (data access)。

✗ Avoid                                    ✓ Prefer
──────────────────────────────────────   ──────────────────────────────────────
Modify the core Equipment type:            Extend without modifying core:

Equipment                                  Equipment (unchanged)
  - serialNumber                             - serialNumber
  - manufacturer                             - manufacturer
  - certificationAuthority   (new)   →       - Links to → Equipment Certification
  - certificationExpiry      (new)
  - certificationStatus      (new)         Equipment Certification (new linked type)
  - lastCertAudit            (new)           - certificationAuthority
                                             - certificationExpiry
(Four new properties, null for all           - certificationStatus
 non-certified equipment, existing           - lastCertificationAudit
 consumers must handle the change)
                                           New interface: Certifiable
                                             - certificationStatus
                                             - certificationExpiry

                                           (Core type untouched, new capability
                                            added via linked type and interface)

一些最佳实践包括：

• 确定什么是至关重要的 (Identify what is essential): 找出哪些属性和联系确实对这个实体至关重要。把这些内容固定下来。
• 设计可扩展性 (Design for extension): 在创建核心类型和接口时，要考虑到其他人可能会在此基础上进行扩展。为链接的扩展类型和新接口实现留出空间。
• 选择扩展而非修改 (Extend rather than modify): 在对现有模型进行添加时，需要考虑该添加内容是属于核心类型，还是属于一种扩展内容——比如一个新的关联对象类型、新的接口实现，或者新的属性命名空间。
• 遵守安全边界 (Enforce security boundaries): 核心数据模型应具有明确定义的安全边界，这样在扩展 Ontology 时就不会无意中增加访问权限的范围。

在深层层次结构中进行组合 (Composition over deep hierarchies)

通过接口实现多重继承功能，保持组件的可插拔性。 Favor multiple inheritance via interfaces. Keep things pluggable.

Foundry 的 Ontology 通过接口实现了多重继承机制，因此一个实体可以从多个特定抽象中组合行为，而非仅依赖于单一的继承链。

一些反模式及其影响包括：

• 那些具有深度单继承链的结构，其中子类型仅用于组合父类的功能特性。
• 像SchedulableBuilding 或InspectableVehicle 这样的“组合”类型，它们将两个无关的概念合并为一种类型。
• 工作流程与特定类型的对象紧密关联，因为它们可以在共享的接口上进行操作。
• 为某个实体添加新功能需要重新调整其继承链结构。

Problem (问题)	Impact (影响)
Combinatorial explosion 组合爆炸	每一种新的功能组合都需要在层级结构中引入一种新的中间类型 (intermediate type)。
Brittle hierarchies 脆弱的层级结构	对父类型 (parent type) 的修改会以不可预测的方式级联影响到所有的子类型 (descendants)。
Limited reuse 有限的复用性	基于链条深处某个特定类型构建的工作流 (workflow) 无法被其他具有相同功能的类型复用。
Semantic distortion 语义扭曲	那些人为拼凑的父类型（例如SchedulableBuilding）并不代表现实世界的概念，这违反了领域驱动设计 (domain-driven design) 原则。

✗ Avoid                                    ✓ Prefer
──────────────────────────────────────   ──────────────────────────────────────
Deep single-inheritance:                   Composed interfaces:

Asset                                      Interface: Building
  └── PhysicalAsset                          - address
        └── Building                         - squareFootage
              └── SchedulableBuilding
                    └── Arena              Interface: SchedulableResource
                                             - schedulingCalendar
(Every new combination of capabilities       - bookingPolicy
 requires a new intermediate type.
 A SchedulableWarehouse would need         Arena implements both:
 yet another branch.)                        Building + SchedulableResource
                                             - arenaName
                                             - seatingCapacity

                                           (Adding SchedulableWarehouse only
                                            requires implementing the same two
                                            interfaces — no new hierarchy needed.)

一些最佳实践包括：

• 设计基于功能或角色的交互界面 (Design interfaces around capabilities or roles): 使用如 Inspectable 、 Schedulable 、 Billable 或 Depreciable 这样的特定界面来表示特定的行为或属性集。
• 使用分类接口进行汇总 (Use taxonomic interfaces for aggregation): 分类标识接口（例如，由 Aircraft 、 Vessel 、 GroundVehicle 实现的 MilitaryAsset 接口）非常适合用于详细调查或类似的汇总工作流程。
• 面向接口的工作流设计 (Target interfaces in workflows): 在构建动作、函数和应用程序时，尽可能以目标接口为基准。基于 SchedulableResource 接口构建的工作流可以适用于各种环境，如场地、会议室和车辆等，而无需进行任何修改。
• 实现多接口而非单一继承 (Compose rather than inherit): 通过实现多个接口来扩展功能，而不是试图通过单一的继承关系来实现功能。当一个实体需要多种功能时，应该分别实现多个接口，而不是试图将其纳入一个复杂的单一继承链中。

关于本体设计更细致的结构指导，请参考本体设计：结构指导，反模式则请参考本体设计：反模式。

本体结构各部分的细节补充

该部分为上一篇文章 对本体工程各部分的描述提供了更细节的创建方法。

设置对象类型 (Create Object Type)

对象类型的元数据 (Object Type Metadata)

对象类型的元数据包括：

• 图标 (Icon): 可以选择默认的图标来定制该对象类型的图标和颜色；当用户在应用程序中查看此类对象时，就会看到这个图标和颜色。
• 名称 (Name): 这是用于标识访问此类对象的用户应用程序中的对象的名称。
• 别名 (Aliases): 当用户搜索此类对象时，这些额外提供的术语将会帮助找到该对象。
• 复数形式 (Plural Name): 这个名称会被显示给所有在用户应用程序中访问多个此类对象的人。
• 描述 (Description): 为在用户应用程序中访问此类对象时提供解释性文本。例如，当用户在对象浏览器中进行搜索时，他们会看到该对象类型的相关描述。
• 群体 (Groups): 选择此对象类型是否将属于某个群体。这是一种组织本体结构的方法，有助于更容易地筛选出后续需要处理的对象类型。
• 数据来源(Backing Datasource): 作为此类对象属性值所使用的数据来源。

为对象类型创建属性

每种对象类型至少需要一个属性。这是因为对象类型需要唯一标识它们的主键。此外，向导还允许你添加任何其他所需的属性。在“属性”步骤中，你需要选择一个主键和标题键：

• 标题键(Title Key): 用作该类型对象显示名称的属性。例如，将full name 属性设置为Employee 对象类型的标题键后，该属性的值会被用作每个名义上的Employee 对象的显示名称，比如“Melissa Chang”、“Akriti Patel”或“Diego Rodriguez”。
• 主键(Primary Key): 这个属性充当了每个对象实例的唯一标识符。在后台数据源中，每一行数据都必须拥有唯一的值作为该属性的值。例如，employee ID 属性的值将被用来将“Melissa Chang”识别为组织内一个独特的员工。

关于主键的一些注意点
在分配主键之前，请务必检查数据来源中是否存在重复的主键。所选主键必须对于数据来源中的每条记录都是唯一的。
主键应该是确定性的。如果主键不是确定性生成的，并且在构建过程中发生变化，那么相关的编辑内容可能会丢失，对象的链接也可能消失。这种情况会发生是因为，在本体编辑中，编辑内容是与对象的主键相关联的。如果构建过程没有正确协调，可能会导致链接 ID 的更新失败，从而使得链接失效。为了确保主键的确定性，应该定义相应的处理逻辑，使得主键能够基于单个列或多列组合来生成。避免使用编号行或随机生成的键，因为这些方法可能会导致主键在多次构建过程中发生变化。

接口字段命名指南 (API Naming Guidelines)

对象类型 API 的名称遵循统一的编码规范。对象类型的 API 名称必须满足以下要求：

• 以一个大写的字母开头，并且只包含字母数字字符
• 这些单词应该使用 PascalCase 格式书写（也称为 UpperCamelCase，即复合词中的每个单词的首字母都大写；例如：“ThisExampleName”）
• 在所有对象类型中都要保持独特性
• 长度应在 1 到 100 个字符之间

某个属性的 API 名称必须满足以下条件：

• 以一个小写字母开头，并且只包含字母和数字字符
• 应使用 CamelCase 格式书写（即，在复合词中，每个单词的第一个字母在第一个单词之后都大写；例如：“thisExampleName”）
• 在同一对象类型下的所有属性中保持独特性
• 长度应在 1 到 100 个字符之间

Metadata reference (元数据参考)

在本体 (Ontology) 中，一个对象类型 (Object type) 由以下元数据表示：

• ID (标识符): 对象的唯一标识符，主要用于在配置应用程序时引用此类对象。例如，employee 可能是Employee 对象类型的 ID。
• RID (资源标识符): Foundry 为每个资源自动生成的唯一标识符。某个对象类型的 RID 会在整个平台的错误信息中被引用。
• Icon (图标): 一种图片和颜色组合，用作对象类型的视觉标识，在用户查看此类对象时显示。例如，人物图标可用于表示Employee 对象类型。
• Display name (显示名称): 用户在访问此类对象时看到的名称。例如，Employee 对象类型的显示名称可能是Employee。
• Plural display name (复数形式显示名称): 在用户应用程序中，用于显示访问多个此类对象时的名称。例如，Employee 对象类型的复数显示名称可能是Employees。
• Description (描述): 关于该对象类型的解释性文本，供用户阅读。例如，Employee 对象类型的描述可能是All full-time and part-time employees of Organization X。
• Groups (组): 一个标签，用于帮助你对对象类型进行分类。例如，Employee 对象类型可能属于HR 和Employee 360 组。
• API name (API 名称): 在代码中程序化地引用对象类型时所使用的名称。例如，Employee 对象类型的 API 名称可能是Employee。更多关于 API 名称的信息请参考相关文档。
• Visibility (可见性): 用于指示用户应用程序该如何突出显示该对象类型。prominent（醒目）对象类型会让应用程序首先向用户展示该对象类型，而hidden（隐藏）对象类型则不会出现在用户应用程序中。默认情况下，Employee 对象类型的可见性为normal（正常）。
• Status (状态): 这是一个向用户和其他本体 (Ontology) 构建者提供的信号，表明该对象类型在开发过程中所处的阶段。该状态可以是active（活跃）、experimental（实验性）或deprecated（已弃用）。默认情况下，Employee 对象类型的状态为experimental。有关状态的更多信息，请阅读相关说明。
• Index status (索引状态): 指该对象类型及其支持的数据源在最后一次重新索引时的状态。该状态可以是success（成功）、failed（失败）或not started（未开始）。关于索引状态的更多信息，请参考相关说明。
• Writeback (写入回执): 该字段用于指示该对象类型是否生成了写入回执数据集，以及是否允许终端用户对这类对象进行编辑（enabled 或disabled）。更多关于写入回执数据集的信息请参见相关文档。

设置对象类型的属性

编辑属性类型的元数据 (Edit a property type’s metadata)

用于编辑属性元数据的选项被集中显示在四个不同的标签页中，这些标签页提供了以下配置选项：

• 显示名称与描述 (Display Name and Description): 选择现有的显示名称或描述以编辑其中的文本。
• 状态 (Status): 选择现有的状态以打开下拉菜单，从中可以选择deprecated 、experimental 和active 状态。
• API 名称 (API Name): 选择现有的 API 名称，以便更改其值。
• 键 (Keys): 用于表明某个属性是对象的类型键还是主键。
• 值格式设置 (Value Formatting): 对属性的值应用一种特殊的格式化方式，使得它们在应用程序中更易于阅读。
• 条件格式 (Conditional Formatting): 对某个属性应用规则，以决定其在界面中的显示方式。
• 属性基础类型 (Property Base Type): 从下拉菜单中选择属性的基础类型。属性的类型决定了可以对属性值执行哪些操作。
• 类型类 (Type Classes): 将类型类作为额外的元数据应用起来，这些元数据可以被应用程序进行解释。
• 可见性 (Visibility): 选择现有的可见性选项，将会弹出一个下拉菜单，其中包含可用的可见性选项。 prominent 这样的属性会被应用到应用程序中，使得用户首先看到这个属性。而 hidden 这样的属性则不会出现在用户的应用程序界面中。

数值格式化 (Value Formatting)

数值格式化为一种对属性的值进行特殊处理的过程，它将原始数值转换为更易于阅读的格式。在下面的图片中，左侧（未格式化之前）展示了weight 和value 列的数值。右侧（已格式化之后）则对weight 列应用了单位“kg”，而value 列则以更简洁的形式显示，并添加了货币符号“$100K”。这些都是数值格式化的例子。此外，Ontology 还支持日期和时间格式化的处理，以及用户 ID、资源 ID 和工件 GID 的格式化。

条件格式化 (Conditional Formatting)

条件格式设置允许对任何属性进行规则配置，并决定在用户界面的应用中该属性的值应该如何显示（例如颜色、对齐方式等）。当您在 Ontology Manager 中配置条件格式时，这些格式规则会在对象浏览器、对象视图、Quiver 以及 Workshop 中生效。

Label (标签)	Description (描述)	Usage (使用方式)
A	Switch between aStandard rule, anAlways true rule, or aMath rule. 可以在标准规则、始终生效的规则，以及数学规则之间切换。	UseAlways true as a fallback in case your other rules don’t match. In the example above, we could have grey as the fallback case when neither of the type values match. 在其他规则无法适用时，请始终使用“总是为真”作为备选方案。在上面的例子中，当 type 两个值都不符合时，我们可以使用灰色作为备选方案。 Use aMath rule when you want to run math operators on some of your properties. 当需要对某些属性执行数学运算时，可以使用数学规则。
B	The rule will always be applied to the property from which you selectedAdd a rule; however, this dropdown allows you to choose to apply the rule based on the value of another property. 该规则将始终适用于你选择添加规则的那个属性。不过，你还可以选择根据另一个属性的值来应用该规则。	In the case above, assume we want to color the value forType in red when the value ofPerformance factor drops underneath a certain threshold. We would choosePerformance factor in our logic instead ofType; however, the color would still show onType. 在上面的例子中，假设当我们看到Performance factor 的值低于某个阈值时，我们希望将Type 的值标记为红色。在这种情况下，我们应该选择Performance factor 作为逻辑中的目标值，而不是Type；不过，该颜色仍然会显示在Type 上。
C	Types of comparisons available are based on the type of the property. For example, for stringsString comparison andIs null are available. For numeric types,Numeric range orExact numeric match are available. 可用的比较类型取决于所处理的属性类型。例如，对于字符串类型，可以提供字符串比较以及是否为空值的比较。对于数值类型，则可以提供数值范围比较或精确数值匹配等比较方式。	To color the type in grey if the value is null, select this dropdown and chooseIs null instead ofString comparison. 如果 type 的值为空，希望将其颜色设置为灰色，请选择该下拉选项，并选择“为空”而不是字符串比较。
D	Subtypes of comparisons,String comparison hasIs exactly,Contains,Starts with, etc. 字符串比较有多种类型，包括“完全相等”、“包含”、“以…开头”等。	Use this to color all plane type values thatStart with “A32”. 使用这个工具来为所有以“A32”开头的平面值进行着色。
E	Compare against a constant or a property reference. 将结果与常量或属性引用进行比较。	In this case, we are specifically looking for the constant “A320”, but we could also add a reference from another property from the same object type. 在这种情况下，我们特别在寻找名为“A320”的常量。不过，我们也可以从同一对象类型的另一个属性中获取参考值。
F	Toggle between aTrue orFalse rule. 在“真”与“假”的规则之间切换。	To color all planes in blue that are not A320, switch this toFalse. 要将所有不是 A320 飞机的飞机涂成蓝色，请将此选项设置为False。
Formatting 格式化	UseBlueprint colors and intents or add your own custom color. You can also switch alignment. 可以使用预设的颜色和样式，或者选择自己设计的颜色。同时，也可以切换不同的对齐方式。	Switch between hex, RGB orBlueprint colors based on need; you can also align the boxes on the right hand side for easier readability for numbers. 根据需求在十六进制颜色、RGB 颜色或蓝图颜色之间切换；你也可以将右侧的方框对齐，以便更清晰地显示数字。
Preview 预览版	View how conditional formatting appears in various contexts. 查看条件格式在不同情境下的表现情况。	Preview anObjects table or aProperty card. 可以预览对象表或属性卡片的内容。

Metadata reference (元数据参考)

A property is represented in the Ontology by the following metadata: 在本体 (Ontology) 中，一个属性由以下元数据表示：

• ID: 对象的唯一标识符，主要用于在配置应用程序时引用该资源。例如，start-date 可能是开始日期资源的 ID。
• Display name (显示名称): 用户在访问该属性的值时看到的名称。例如，start date 属性的显示名称可能是Start date。
• Description (描述): 关于该属性的说明性文本，用户可以阅读。例如，start date 属性的描述可能是The day the employee began new hire training。
• RID (资源标识符): Foundry 为每个资源自动生成的唯一标识符。在某个平台上，当出现错误时，会引用该资源的 RID 来进行错误提示。
• Status (状态): 这是一个向用户和其他本体 (Ontology) 构建者提供的信号，表明该属性在开发过程中的所处阶段。该状态可以是active（活跃）、experimental（实验性）或deprecated（已弃用）。默认情况下，start date 属性的状态为experimental。有关状态的更多信息，请参见相关说明。
• API name (API 名称): 这是在代码中通过程序引用该属性时使用的名称。例如，start date 属性的 API 名称可能是startDate。更多关于 API 名称的信息请参考相关文档。
• Keys (键): 表示该属性是对象类型的标题键还是主键。
  • Title key (标题键): 用于作为此类对象显示名称的属性。例如，将full name 属性设置为Employee 对象的标题键后，就可以使用该属性的值作为每个对象的显示名称，比如将“Melissa Chang”和“Diego Rodriguez”这两个名义上的员工名称作为相应的对象显示名称。
  • Primary key (主键): 作为每个对象实例的唯一标识符的属性，这意味着后台数据源中的每一行都必须拥有不同的值。例如，employee number 属性的值可以用来识别“Melissa Chang”作为组织内唯一的员工。
• Base type (基础类型): 它代表了该属性的数值类型，并决定了用户在应用程序中可以使用哪些操作。例如，start date 属性就属于基础类型date。用户应用程序允许你使用这个属性来配置时间线小部件。
• Value formatting (值格式设置): 根据属性的基础类型，可以对数值、日期和时间格式进行设置。此外，还可以对用户 ID 和资源 ID 进行格式设置，将原始值转换为更易于理解的格式，以便在用户应用程序中使用。更多关于值格式设置的信息请参见相关文档。
• Conditional formatting (条件格式): 针对某个属性设定的规则，这些规则决定了该属性的值在用户界面中的显示方式（如颜色、对齐方式等）。例如，您可以设定一个规则，当start date 属性的值比两周前的值还小时，将full name 属性的值显示为绿色，这样就能在用户界面上突出显示新入职的员工。更多关于条件格式的信息请点击了解。
• Type classes (类型类): 这些额外的元数据由用户应用程序进行解释。更多关于类型类的信息请参考相关文档。
• Render hints (渲染提示): 这些提示向用户应用程序提供了关于如何渲染某些属性的信息，这些属性可能与同一基础类型中大多数属性不同。可以使用许多渲染提示来影响对象类型在重新索引时的性能。例如，如果认为用户不会使用start date 属性进行搜索或排序操作，那么可以取消选择searchable 和sortable 渲染提示，从而提高对象类型的重新索引性能。更多关于渲染提示的信息请参考相关文档。
• Visibility (可见性): 这是一个指示，用于告诉用户应用程序该属性应如何被突出显示。prominent（醒目）属性会促使应用程序首先向用户展示该属性，而hidden（隐藏）属性则不会出现在用户应用程序中。默认情况下，start date 这样的属性具有normal（正常）的可见性。

Learn more about creating and configuring properties in the Ontology and about validation requirements for property metadata. 了解更多关于在本体 (Ontology) 中创建和配置属性的信息，以及关于属性元数据验证要求的内容。

Some property base types have limited support. These types are indicated with theLimited support tag which is visible in the property base type picker. 某些属性基础类型得到了有限的支持。这些类型会用Limited support 标签标识出来，该标签会在属性基础类型选择器中显示。

• byte: Properties of this type cannot be used within action types.
  这种类型的属性无法在动作类型中使用。
• decimal: Properties of this type cannot be used within action types as the precision cannot be guaranteed when updating this data type due to the conversion between JSON and Java.
  这种类型的属性无法在动作类型中使用，因为在更新这种数据类型时，由于 JSON 与 Java 之间的转换问题，无法保证精度。
  This type is also not supported inObject Storage V2.
  这种类型在对象存储 V2 (Object Storage V2) 中也不被支持。
• float: Properties of this type cannot be used within action types.
  这种类型的属性无法在动作类型中使用。
• short: Properties of this type cannot be used within action types.
  这种类型的属性无法在动作类型中使用。
• vector: Vectors can only be queried byKNN.
  向量只能通过 KNN 方法进行查询。
  The max vector dimension is 2048.
  最大向量维度为 2048。

更多诸如必需属性、强制性控制属性、基础类型、属性减负、派生属性的内容请参考 Palantir 官方的对应文档。

另外，属性部分还有比较重要的一点就是共享属性 (Shared Properties)，通过使用共享属性，不同类型的对象能够采用一致的数据建模方式，同时还能实现对属性元数据的集中管理。

A shared property is represented in the Ontology by the following metadata: 在本体 (Ontology) 中，这种共享属性由以下元数据表示：

• Name (名称): 该共享属性的名称。
• Description (描述): 关于共享属性的说明性文本，用户应用程序可以阅读该文本。例如，start date 共享属性的描述可能是The day the employee began new hire training。
• RID (资源标识符): Foundry 为每个资源自动生成的唯一标识符。在某个平台上，当出现错误时，会引用该资源的 RID 来进行错误提示。
• Base type (基础类型): 它代表了该属性的数值类型，并决定了用户在应用程序中可以使用哪些操作。例如，start date 属性就属于基础类型date。用户应用程序允许你使用这个属性来配置时间线小部件。
• Value formatting (值格式设置): 根据属性的基础类型，可以对数值、日期和时间格式、用户 ID 以及资源 ID 进行格式设置。这样就能将原始值转换为更易于理解的格式，以便在用户应用程序中使用。了解更多关于值格式设置的信息。
• Type classes (类型类): 这些额外的元数据由用户应用程序进行解释。更多关于类型类的信息请点击了解。
• Render hints (渲染提示): 这些提示向用户应用程序提供关于如何渲染某些属性的信息，这些属性可能与同一基础类型中大多数属性不同。可以使用许多渲染提示来影响定义该属性的对象类型在重新索引时的性能。例如，如果认为用户应用程序不会搜索或排序start date 属性，那么可以取消选择searchable 和sortable 渲染提示，从而提高Employee 对象类型在重新索引时的性能。了解更多关于渲染提示的信息。
• Visibility (可见性): 这是一个指示，用于告诉用户应用程序该属性应如何被突出显示。prominent（醒目）属性会促使应用程序首先向用户展示该属性，而hidden（隐藏）属性则不会出现在用户应用程序中。默认情况下，start date 这样的属性具有normal（正常）的可见性。
• Usage (用途): 使用共享属性的对象类型。例如，start date 这个属性可以被Employee、Contractor 以及其他在本体 (Ontology) 中的对象类型所使用。

设置本体的结构/框架 (Structs)

“结构”是一种本体属性基础类型，它允许用户创建包含多个字段的基于模式的属性。结构属性是由结构类型的数据集列生成的。只要在这些属性被定义在本体中之前进行了转换，使其变为单一的结构类型列，那么结构属性字段就可以来自不同的数据源。

关于对象属性结构体建模的示例
许多常见的对象属性可以建模为结构体。例如，一个包含First Name 和Last Name 字段的Full Name 属性，或者一个包含Street 、City 、Postal Code 和Country 字段的Address 属性。

结构属性的约束条件如下：

• 结构具有一层深度，且不能嵌套其他结构
• 结构必须至少包含一个字段
• 目前支持以下字段类型：BOOLEAN、BYTE、DATE、DECIMAL、DOUBLE、FLOAT、GEOPOINT、INTEGER、LONG、SHORT、STRING、TIMESTAMP。

结构属性根据私有性，可以划分为局部属性 (local property) 和共享属性 (shared property) 。 结构体属性可以同时使用局部属性和共享属性类型。在将局部属性类型转换为共享属性类型时，需要重新映射结构体中的字段。由共享属性类型支持的局部结构体属性类型会继承共享属性类型的字段，除了结构体字段的标识符（RIDs）之外。结构体的字段元数据（显示名称、描述、别名等）则会从共享属性类型继承过来，但具有保留原始 RIDs 的结构体字段仍然保持原样。

另外，Palantir 为结构属性设计了结构体主字段，允许指定结构的核心值和附加元数据。例如，一个Address 结构体可能包含streetName 和postalCode 作为其核心值，而像collectionDate 和collectorName 这样的字段则代表用于描述如何获取Address 的元数据。

许多结构化数据的属性都遵循这种模式：一个或多个字段包含了在应用中最值得展示的主要数据，而其他字段则提供了上下文信息、跟踪数据或审计相关细节。

那些支持结构体主字段的应用程序会仅以简洁的视图形式展示主字段，比如 Workshop 中的对象表和对象列表控件。同时，用户也可以通过扩展视图或悬停显示来查看整个结构体。这样，用户可以快速浏览最重要的数据，而不需要查看每一个结构体字段。不过，在需要的时候，用户仍然可以查看整个结构体。

应用程序以多种方式支持主字段：

• 仅显示主要字段 (Main fields only): 在表格或摘要卡片等简洁视图中，只显示主要字段。
• 鼠标悬停在主要字段上时显示的内容 (Main fields with hover): 默认情况下，鼠标悬停在某个字段上时会显示该字段的内容，同时还会显示相关的元数据信息。
• 完整结构 (Full struct): 在需要完整信息的详细视图或表单中显示所有字段。

设置链接类型

在 Palantir 中，链接类型包括：

• 对象类型的外键 (Object type foreign keys): 支持“一对一”和“多对一”两种关联类型。此选项允许您选择表示外键的属性，这些属性对应的就是所需对象的主键。
  • 外键是一种存在于某一对象类型上的属性，它存储着另一对象类型的主键的值。这种关系实际上代表了两种对象类型之间的现实世界中的关联。这个概念类似于关系数据库中的外键机制，即一个表中的列引用了另一个表的主键列。在一对一或一对多类型的关联中，需要定义外键属性和主键属性。一个对象类型的外键属性必须引用另一个对象类型的主键属性。该种链接类型包括一对一基数关系、一对多关系、多对一关系、多对多基数关系。
• 连接表数据集 (Join table dataset): 适用于“多对多”类型的关联关系。此选项允许您使用连接表数据集来支持关联关系。
  • 在多对多关系的基数中，需要选择一个数据源，该数据源能够包含第一个对象类型的主键与第二个对象类型的主键之间所有可能的链接组合
• 对象型链接类型 (Backing object type): 这种链接类型基于对象进行扩展，具有多对一的基础关系，为对象类型作为链接类型存储解决方案提供了高级支持。
  • 选择在前提条件中创建的对象类型，以表示想要的链接类型。左边的对象和右边的对象分别代表两个将被链接在一起的实体。中间的那个对象则充当中介角色，提供有关这两个实体之间连接的额外元数据，从而支持链接的建立。

具体案例

• Tail Number 属性是Aircraft 对象类型的主键，它能够唯一标识每一架飞机。而Flight 对象类型中的Flight Tail Number 属性则是外键，它代表了那些被分配到特定航班上的飞机。当Aircraft 的Tail Number 与Flight 的Flight Tail Number 相匹配时，就会在Aircraft 和Flight 对象类型之间建立关联。

在选定链接类型的种类后，接下来就可以定义链接类型的名称了。命名时，需要为链接类型的每一侧输入一个显示名称。链接类型恰好有两部分，每一部分对应一种对象类型；每一侧都表示对该对象类型的链接。

例如，Aircraft 对象类型的显示名称描述了从Flight 到Aircraft 的链接。你可以选择Assigned Aircraft 作为显示名称，因为在一个Flight 中有一个Assigned Aircraft 。由于这两部分都是为同一链接类型而配置的，因此该链接类型可以双向遍历；不需要为反向方向定义单独的链接类型。更多细节请参考方向性部分。

链接类型的 API 名称必须遵循以下规则：

• 以一个小写字母开头，并且只包含字母和数字字符
• 在与同一对象类型相关的所有链接类型中，都保持独特性
• 长度应在 1 到 100 个字符之间
• 使用NFKC标准化
• 不应被用作保留关键字

Link type metadata reference (链接类型元数据参考)

在 Foundry 本体 (Ontology) 中，链接类型通过以下元数据来表示：

• ID: 这是一种独特的链接类型标识符，主要用于在配置应用程序时引用此类链接。例如，employee-employer 可能是定义在Employee 和Company 对象类型之间的链接类型的 ID。
• RID (资源标识符): 这是 Foundry 为每个资源自动生成的唯一标识符。在平台的各种错误信息中，都会引用某个链接类型的 RID。
• Status (状态): 这是一个向用户和其他本体 (Ontology) 构建者提供的信号，表明该链接类型在开发过程中的所处阶段。该状态可以是active（活跃）、experimental（实验性）或deprecated（已弃用）。默认情况下，Employee → Employer 链接类型的状态为experimental。有关状态的更多信息，请阅读相关说明。
• Object types (对象类型): 通过链接类型定义来关联的对象类型。例如，Employee → Employer 链接类型会引用Employee 和Company 对象类型。
• Cardinality (基数): 它告诉应用程序，在链接类型中，每种对象类型是包含单个对象还是多个对象。例如，在链接类型Employee → Employer 中，Employee 对象类型的基数为many（多），而Company 对象类型的基数为one（单），因为通常会有多个员工关联到一个雇主。而在链接类型Direct Report ↔ Manager 中，如果直接下属可以拥有多个上级，同时上级也可以拥有多个直接下属，那么Employee 对象类型的基数将变为many。
• Key (键): 用于创建链接的属性或列。
  • One-to-one / One-to-many (一对一 / 一对多): 在一对一或一对多基数链接类型中，一个对象类型的属性（外键）指的是另一个对象类型的主键属性。这种外键与主键之间的关联定义了对象之间的链接。例如，在Employee → Employer 链接类型中，Employee 对象类型可能有一个employer ID 属性（外键），该属性指向Company 对象类型的company ID 属性（主键）。
  • Many-to-many (多对多): 在多对多关联类型的链接中，一个包含主键对的表用于定义两个对象之间的关联。这种链接类型需要指定一个连接表，同时还需要指定这些主键的映射关系，以便应用程序能够知道连接表中的哪些列对应着关联类型中哪些对象的主键。例如，支持Direct Report ↔ Manager 链接类型的连接表可能包含employee numbers 对，每对employee numbers 对应一个Direct Report ↔ Manager 关联。
• Display name (显示名称): 这是用户在访问此类链接时看到的名称。链接类型的两侧都有显示名称。链接类型的每一侧都对应着某个对象类型的链接。例如，在Employee → Employer 链接类型中，Employee 对象类型的显示名称为Employee，Company 对象类型的显示名称为Employer。
• Plural display name (复数显示名称): 当用户应用程序中包含多种关联对象类型时，访问此类链接时显示的名称即为复数形式。例如，在Employee → Employer 链接类型中，Employee 对象类型的复数显示名称为Employees；而Company 对象类型则没有复数显示名称，因为每位员工只能对应一家公司。
• API name (API 名称): 这是在代码中通过编程方式引用链接类型所使用的名称。链接类型中的 API 名称可以用来获取该类型的对象。例如，如果Employee → Employer 链接类型中Employee 侧的 API 名称为employee，那么调用Company.employee.get() 将会返回与Company 对象相关联的Employee 对象。了解更多关于 API 名称的信息。
• Visibility (可见性): 用于指示用户应用程序如何显示链接类型的某一侧内容。链接类型的prominent（醒目）一侧会让应用程序首先向用户展示这一侧的内容。而链接类型的hidden（隐藏）一侧则不会出现在用户界面中。默认情况下，员工和公司相关的链接类型的normal（正常）一侧是可见的。
• Type classes (类型类): 这些额外的元数据由用户应用程序进行解释。更多关于类型类的信息请参考相关文档。

设置值类型 (Value Types)

值类型是对字段类型的语义化封装，它包含了元数据和约束条件，这些特性能够提升类型的安全性、增强表达能力，并提供额外的上下文信息。值类型封装了特定领域的数据类型，并且能够以一种可在整个平台上复用的方式执行数据验证。与对象类型、属性、链接类型或其他用于构建 ontology 的类型不同，值类型与平台中的某个空间相关联。一个空间可以包含多个 ontology。值类型只能在其被定义的空间中使用。默认 ontology 并不支持使用值类型。

数据集中的字段类型和属性基础类型反映了编程语言中的基本类型。这些类型与具体领域无关，不会提供任何领域上下文信息。相比之下，值类型则能够捕捉数据的上下文和语义含义，并实现对数据的验证。用户可以直接从值类型中获取数据含义，而无需依赖诸如列名或属性描述等周围信息。此外，值类型还会在构建管道和本体中强制执行验证约束，从而确保数据集成器和本体管理器能够在数据流和模型中实现正确的语义类型标注。

以下这些应用场景都支持使用值类型：

• 为对象类型的属性分配一个值类型。
• 为共享属性分配一个值类型。
• 通过使用logical type cast 表达式为Pipeline Builder 的管道属性分配一种值类型，并在向目标对象写入数据时选择该值类型。

值类型具有版本控制功能，以便处理会引入变化的修改以及不会造成变化的修改。值类型的版本包含两部分：元数据和约束条件。元数据中的名称、描述以及 apiName 等字段可以在需要时进行更改。而定义该类型验证规则的约束条件则是不可变的。

如果您选择更新某个值类型的约束条件，则会创建该值类型的新的版本。如果您的值类型没有消费者，您可以自由修改这些约束条件。然而，如果您对约束条件进行了破坏性修改，而您的价值类型仍然有消费者，那么我们建议放弃当前的值类型，创建一个新的版本。这种方法可以避免潜在的运行时错误和数据不一致性的问题。

值类型约束条件 (Value Type Constraints)

每种值类型都可以选择定义一些约束条件，以强制实施数据验证。 在“值类型管理器”应用程序中创建新的值类型时，可以配置这些约束条件。以下列出了可用的值类型约束条件，以及它们可以应用于哪些基础类型：

• 枚举：一种表示一组固定允许值的约束条件
  • 有效的基类型包括：String、Boolean、Decimal、Double、Float、Integer 或 Short。
  • 对于字符串属性，这些枚举值可以选择具有大小写敏感特性，也可以不区分大小写。
• 范围：允许的值的最小值、最大值或范围
  • 有效的基类型包括：Decimal、Double、Float、Integer、Short、Date、Timestamp、String 或 Array。
  • 对于字符串属性来说，字符串的长度是有限制的。
  • 对于数组属性来说，数组的大小是有限制的。
• 字符串
  • 正则表达式：字符串必须符合该正则表达式模式。只有当属性值的子字符串满足正则表达式的条件时，正则表达式验证才会通过。
  • RID：该字符串必须是一个有效的 RID。
  • UUID：该字符串必须是一个有效的 UUID 标识符。
• 数组
  • 唯一性：数组中的所有元素都必须唯一。
  • 嵌套：可以对数组的元素施加值类型约束。例如，可以对数组中的每个字符串施加正则表达式约束。
• 结构
  • 元素约束：结构体字段标识符与值类型引用之间的映射关系。其中，结构体字段标识符指明了应应用该值类型的结构体组件。

操作类型各部分的细节补充

在 ontology 中，用户可以通过执行各种操作来对对象、属性和链接进行修改。操作是一种能够改变一个或多个对象属性的单一事务，这些操作是基于用户定义的逻辑来执行的。 通过这种方式，用户可以在考虑整体目标的同时，管理和处理数据，而无需专注于对特定属性的编辑。

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

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

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

本体规则 (Ontology Rules)

本体规则可以修改 ontology 中的特定元素。它们可以创建、修改或删除现有类型的对象和链接。若要创建或删除一对多或一对一的链接，就需要使用对象规则，并且需要修改对象上的外键属性。详细内容见Palantir 官方文档。

参数

参数是某个操作类型的输入参数。它们充当了规则与其他应用程序（如 Workshop、Slate 和 Object Views）之间的接口。 参数被看作是可以存储外部值的变量。每个参数都有一个类型，该类型决定了它可以接受哪种类型的值。除了类型之外，参数还拥有多种其他可能的配置选项。每个参数都可以单独进行配置，例如是否要在表单中显示该参数，或者是否允许用户对其进行修改。

参数可以设置为默认值，这样就能显示固定的值或所选对象的属性，本地默认值（例如，工作区中的变量）始终优先于全局默认值。

提交标准 (Submission Criteria)

提交标准（之前称为验证规则）是决定某个操作是否能够被提交的条件。这些提交标准有助于将业务逻辑编码到数据编辑权限中，从而确保 Ontology 数据的质量以及编辑过程的合规性。提交标准是通过结合上下文中的条件（如用户或参数）以及静态信息来构建的，从而形成一个逻辑性的判断准则 。这些提交标准可以包含对象、关系甚至用户信息，以决定是否能够提交某个操作。

一个关于航空公司的例子
例如，一家航空公司可能想要修改特定航班上使用的飞机型号。所配置的功能允许用户更换与 Flight 对象关联的 Aircraft 对象。不过，该航空公司只希望某些特定用户（如航班调度员）能够使用这一功能，以确保只有仍在服役的飞机被使用。通过使用提交标准，管理员可以确保在满足某些条件后才允许用户提交修改飞机型号的操作请求。这些条件包括用户的所属组以及飞机当前的状态。

提交标准包括条件和运算符。 条件是指用于控制参数或用户属性值的单一语句。运算符则用于组合和嵌套不同的条件。通过使用各种操作符，我们可以创建出更复杂的语句，从而模拟企业的业务流程和需求。 只有满足所有提交条件后，才能提交操作。这一点与用户是否可以编辑某个操作类型无关。虽然一个对象类型可以包含多种操作类型，用于添加、修改或删除对象，但每种操作类型都有独立的提交条件。

作者按
这里其实就和统计推断扯上关系了，可以通过逻辑运算符的组合甚至更复杂的一些逻辑关系和断言来实现提交标准的构造，从而判定操作的合规性。

在执行操作时，需要注意通知和外部系统更新：

• 通知 (Notifications): 通知功能允许你灵活地配置在某个操作执行时如何通知用户。这包括向平台上的用户发送电子邮件的功能。
• Webhooks: Webhooks 使你能够以非常灵活的方式连接到 Foundry 之外的系统，包括向 REST API 或 ERP 系统发送请求。这使你能够向组织内的其他系统发送指令，或者通过集成消息系统更灵活地向用户发送通知。

操作失败的类型

操作指标包含多种可能出现的故障类别。这些类别包括：

• 参数无效错误 (Invalid Parameter Failure): 提交的操作中包含了一些无效的参数，这些参数不符合该操作的规范。
• 规模限制突破 (Scale Limit Failure): 此操作影响的对象类型数量超过了允许的限度。
• 认证失败 (Authentication Failure): 该用户未能满足该操作的安全提交标准。
• 副作用失败 (Side Effect Failure): 该操作因网络钩子问题或配置错误的副作用而失败。
• 功能故障 (Function Failure): 该操作失败，原因是相关功能出现了问题。这种故障模式仅适用于那些依赖特定功能的操作。
• 用户可见功能故障 (User-facing Function Failure): 支持该功能的操作出现了错误，该错误会被显示给用户。这种故障模式仅发生在支持功能驱动的操作中。
• 冲突导致失败 (Conflict Failure): 由于冲突的出现，比如同时发生了修改操作，导致任务未能完成。
• 未分类的故障 (Unclassified Failure): 该故障并不属于上述任何一类。

操作日志 (Action Log)

操作日志将所有操作提交视为对象类型，以便在这些对象相关的 Foundry 工具中进行分析和展示。可以将操作日志中的对象类型作为决策流程的输入，同时用于监控本体中的变化。

操作是修改本体并触发相关副作用的主要方式。通常，这些本体修改是特定决策的结果，或者伴随着数据审计需求而实施。操作日志简化了代表这些决策和数据编辑的对象类型的生成与维护工作。为了便于识别，所有操作日志中的对象类型都会以 [LOG] 作为前缀。

默认情况下，操作日志对象类型会存储以下信息：

• 动作 RID (Action RID): 单个动作提交的唯一标识符
• 动作类型 RID (Action type RID): 用于唯一标识某个特定动作类型的标识符
• 动作类型版本 (Action type version): 随着每个动作类型的更新，版本号会自动递增。
• 时间戳 (Timestamp): 动作提交的 UTC 时间戳
• 用户ID (UserId): 用于提交操作的多用户 ID
• 被编辑的对象 (Edited objects): 所有通过此操作被编辑的对象的主键值。注意，除了主键之外，存储编辑对象的其他属性是不被支持的。
• 可选-摘要 (Summary): 一个可自定义的字符串，用于描述该操作的具体内容。
• 可选-参数值 (Parameter values)
• 可选-对象引用参数的属性值 (Property values of object reference parameters) （如果启用了 allow multiple values 功能，则对象引用参数不支持此功能）