Ontology peering（本体对等连接（Ontology peering））¶

Ontology peering enables you to synchronize object and link types from your ontology to an ontology on another enrollment across a peer connection.

Key concepts¶

Object references and mappings¶

You can reference a singular object or a set of objects across Palantir applications by its unique RID. The act of peering translates ontology RIDs that are specific to each enrollment across the connection to ensure users can reference the correct object when operating in applications within their enrollment. Before you enable peering and configure a peer connection, these object references only refer to the enrollment-specific RID. This translation is necessary to synchronize a Gotham file, such as a Gaia map, between two enrollments.

To perform this translation, create an object type mapping to define how an object type and its properties are translated across a peer connection. You do not need to map every property; however, you must map any properties you wish to peer over the established connection.

Types of ontology data peering¶

Source data peering¶

Source data is Ontology data from backing datasources, like datasets or Restricted Views. Source data peering is currently unidirectional. This means that when source data peering is set up, one enrollment is providing all the source data, and no source data can flow the other way.

You may not need to configure source data peering if both enrollments receive data from the same upstream source systems. If this the case, then you should configure action data peering to synchronize user edits across the two enrollments. Additionally, you will not need to configure source data peering for object types that do not have source data, meaning they are generated entirely from user actions.

Review the information below to learn more about source data peering's current capabilities and limitations:

Cloud-to-edge source data peering: Source data peering between cloud and edge enrollments is supported.
Cloud-to-cloud source data peering: Currently, the only way to peer source data from a cloud enrollment to another cloud enrollment is through object types backed by direct datasources. If your object types are backed by another source, like a dataset or Restricted View, then you should synchronize source data across enrollments using the Foundry connector.
Dataset synchronization: You can use the Foundry connector to synchronize an object type's backing dataset or stream between enrollments before establishing a peering connection to synchronize action-based edits. Source data peering does not enable you to peer objects on cloud enrollments backed by a dataset or stream to another cloud enrollment where the remote object is also backed by a separate dataset or stream.
Streams: For cloud enrollments, streams can serve as both an object type's datasource and a direct datasource's feed. The former does not support actions or peering, the latter case supports actions, peering those actions, as well as source data exports and imports.
Only synchronize changed objects: Source data peering only synchronizes objects that change based on backing dataset updates. As an example, if your object type's backing dataset's most recent snapshot transaction only includes changes to five objects, then only those five objects will be synchronized.

Action data peering¶

Action data is ontology data derived from user changes submitted as an action on an object, such as creating, editing, or deleting an object or link. You can configure action data peering between cloud and edge Foundry enrollments.

You can establish bidirectional action data peering between any number of peer connections, and that data will peer in real-time. Additionally, action data peering is eventually consistent: if a real-time action peer fails, then Peer Manager will attempt to resend the data until it is acknowledged by the remote enrollment.

Review the information below to learn more about the current capabilities and limitations for action data peering:

Dataset support: You can peer object types backed by datasets, Restricted Views, and direct datasources, including multi-datasource object types.
Property matching: Action data peering defines a specific property-to-property mapping between two object types. The properties do not need to have the same API name, but in order for a property to peer, both object type's property's type must be the same, such as string or double.
Selected property peering: Action data peering can peer a subset of properties, as opposed to all properties, on an object type.
Unsupported property types: Certain property types are not yet supported by action data peering:
Cipher text
Time series via a linked sensor object type
Vector
Stream-backed object types: Action data peering on a stream-backed object type is not yet supported.

Link type peering¶

Link types define the relationship between two object types and peer automatically alongside object types containing the link properties. Review the guidance below to ensure your object's links peer correctly when configuring an ontology peering relationship.

Foreign key relationships: Links are stored as properties on the object, so there is no specific set up required to peer foreign key links. Rather, they are peered when both linked objects are peered, provided that the link type is defined in both Ontology instances.
Join table dataset relationships: Used for many-to-many links, you must configure these to peer. The join table may contain source data from backing datasources, and the links can receive user edits. Similar to an object type, a many-to-many link type can contain both source data and action data.
Backing object relationships: Used for many-to-many links, the link is shared when both linked objects and the backing object are peered.

Peering and automations¶

When an object type receives updates through ontology peering, those peered changes can trigger Automate automations that monitor the object type. In environments that have peering connections where similar automation logic runs on both sides, this can cause duplicated or unintended side effects.

To prevent this, you can configure an automation to skip events that originate from peering patches. Learn more about this setting in the Automate condition settings documentation.

Configure ontology peering¶

Learn more about configuring ontology peering in Peer Manager.

中文翻译¶

本体对等连接（Ontology peering）¶

本体对等连接使您能够通过对等连接（peer connection），将本体中的对象（object）和链接类型（link type）同步到另一个注册环境（enrollment）的本体中。

关键概念¶

对象引用与映射¶

您可以通过唯一的RID在Palantir应用程序中引用单个对象或一组对象。对等连接机制会将每个注册环境特有的本体RID进行转换，确保用户在其自身注册环境的应用程序中操作时能够引用正确的对象。在启用对等连接并配置对等连接之前，这些对象引用仅指向注册环境特定的RID。这种转换对于在两个注册环境之间同步Gotham文件（如Gaia地图）是必要的。

要执行此转换，请创建对象类型映射（object type mapping），以定义对象类型及其属性如何通过对等连接进行转换。您无需映射所有属性；但必须映射您希望通过已建立连接进行对等同步的任何属性。

本体数据对等连接的类型¶

源数据对等连接（Source data peering）¶

源数据是指来自底层数据源（如数据集或受限视图）的本体数据。源数据对等连接目前是单向的。这意味着设置源数据对等连接后，一个注册环境提供所有源数据，而源数据无法反向流动。

如果两个注册环境从相同的上游源系统接收数据，则可能无需配置源数据对等连接。在这种情况下，您应配置操作数据对等连接以同步两个注册环境之间的用户编辑。此外，对于没有源数据的对象类型（即完全由用户操作生成的对象类型），也无需配置源数据对等连接。

请查看以下信息，了解源数据对等连接的当前功能与限制：

云端到边缘的源数据对等连接： 支持云端与边缘注册环境之间的源数据对等连接。
云端到云端的源数据对等连接： 目前，将源数据从云端注册环境对等连接到另一个云端注册环境的唯一方式是通过由直接数据源（direct datasource）支持的对象类型。如果您的对象类型由其他源（如数据集或受限视图）支持，则应使用Foundry连接器（Foundry connector）跨注册环境同步源数据。
数据集同步： 您可以使用Foundry连接器在建立对等连接以同步基于操作的编辑之前，跨注册环境同步对象类型的底层数据集或流。源数据对等连接不支持将云端注册环境中由数据集或流支持的对象对等连接到另一个云端注册环境，其中远程对象也由单独的数据集或流支持。
流（Streams）： 对于云端注册环境，流既可以作为对象类型的数据源，也可以作为直接数据源的输入。前者不支持操作或对等连接，后者支持操作、操作对等连接以及源数据的导出和导入。
仅同步变更的对象： 源数据对等连接仅同步基于底层数据集更新而变更的对象。例如，如果对象类型的底层数据集最近的快照（snapshot）事务仅包含对五个对象的更改，则仅这五个对象会被同步。

操作数据对等连接（Action data peering）¶

操作（Action）数据是指用户通过提交操作（如创建、编辑或删除对象或链接）对对象进行更改后衍生的本体数据。您可以在云端和边缘Foundry注册环境之间配置操作数据对等连接。

您可以在任意数量的对等连接之间建立双向操作数据对等连接，且数据将实时同步。此外，操作数据对等连接是最终一致性的：如果实时操作对等连接失败，Peer Manager将尝试重新发送数据，直到远程注册环境确认接收。

请查看以下信息，了解操作数据对等连接的当前功能与限制：

数据集支持： 您可以对等连接由数据集、受限视图和直接数据源（包括多数据源对象类型（multi-datasource object types））支持的对象类型。
属性匹配： 操作数据对等连接定义了两个对象类型之间的特定属性到属性映射。属性无需具有相同的API名称，但为了进行对等连接，两个对象类型的属性类型必须相同，例如string或double。
选定属性对等连接： 操作数据对等连接可以对对象类型的属性子集（而非全部属性）进行对等连接。
不支持的属性类型： 操作数据对等连接目前不支持以下属性类型：
密文（Cipher text）
通过链接的传感器对象类型实现的时间序列（Time series）
向量（Vector）
流支持的对象类型： 尚不支持对由流支持的对象类型进行操作数据对等连接。

链接类型对等连接（Link type peering）¶

链接类型定义了两个对象类型之间的关系，并会随包含链接属性的对象类型自动进行对等连接。请查看以下指南，确保在配置本体对等连接关系时对象的链接能够正确对等连接。

外键关系： 链接作为属性存储在对象上，因此无需专门设置即可对等连接外键链接。相反，当两个链接的对象都被对等连接时，只要链接类型在两个本体实例中均已定义，链接就会自动对等连接。
连接表数据集关系： 用于多对多链接，您必须配置这些链接以进行对等连接。连接表可能包含来自底层数据源的源数据，并且链接可以接收用户编辑。与对象类型类似，多对多链接类型可以同时包含源数据和操作数据。
支持对象关系： 用于多对多链接，当两个链接的对象和支持对象都被对等连接时，链接会被共享。

对等连接与自动化¶

当对象类型通过本体对等连接接收更新时，这些对等连接的更改可能会触发监控该对象类型的自动化（Automate）流程。在具有对等连接且两侧运行类似自动化逻辑的环境中，这可能导致重复或意外的副作用。

为防止这种情况，您可以配置自动化以跳过源自对等连接补丁的事件。有关此设置的更多信息，请参阅自动化条件设置文档。

配置本体对等连接¶

了解如何在Peer Manager中配置本体对等连接。