注意：以下翻译的准确性尚未经过验证。这是使用 AIP ↗ 从原始英文文本进行的机器翻译。
保护运营应用程序
Ontology资源元数据的授权模型正在从数据源派生的权限更改为Ontology角色。迁移到Ontology角色的文档提供了逐步指南，指导如何进行迁移。Ontology角色尚未普遍适用于所有客户。请联系您的Palantir代表团队以获取有关您特定Foundry安装的信息。
在搭建您的数据基础后，您可以在其基础上开始搭建您的Ontology和一个航班警报收件箱应用程序。目标是为运营用户提供一个有价值的工作流程，同时使安全性易于理解和维护。
Object数据继承数据集权限
在基础数据已经变换后，您可以在Ontology中创建四个Object：Flight、Flight Alert、Delay和Aircraft。为此，创建新的Object类型并选择您已为每个Object搭建的基础数据集。在此过程中，您将数据集中列映射到新Object类型的属性。基础数据集中的每一列将成为新Object类型的一个属性，基础数据集中的每一行将成为Object类型的一个实例。因此，Object类型中的数据将受基础数据集权限的保护。
对于Aircraft对象，数据受 /Sky Industries/Aviation [Ontology]/aircraft 数据集权限的保护。因此，在 Aviation [Ontology] - 只读 组中的用户将能够查看Aircraft对象中的数据。
在创建必要的Object后，您可以根据Object之间的关系创建必要的链接类型。以下是我们的Ontology。
为了支持完整的工作流程，您将希望为某些Object添加数据输出。数据输出允许编辑现有属性值（例如，修复错误的值或更新状态属性），更重要的是，允许捕获新数据和决策，从而随着时间的推移增加价值。
为此，只需在编辑器部分生成一个数据输出数据集。我们建议将编辑后的数据集放在与基础数据集相同的Ontology项目中（例如 Aviation [Ontology]），以便对象上的权限一致。编辑对象的推荐方法是使用操作，这也可以通过API调用。以下是我们的航班警报对象及其数据输出数据集。
授予用户对Ontology数据的访问权限将由您在数据基础中创建并应用的组进行管理。例如，您只需将新用户添加到 Aviation [Ontology] - 只读 组中，他们即可查看所有四个对象的数据：Flight、Flight Alert、Delay和Aircraft。
编辑Ontology
您可以通过使用Ontology角色来控制谁可以编辑Ontology中特定对象类型的配置。Ontology角色使得可以直接在每个Ontology资源（对象类型、链接类型和操作类型）上应用角色。例如，为了让用户编辑Ontology中的Flight Alert对象，他们只需要在Flight Alert对象上拥有Ontology编辑角色，而不需要任何基础数据源的权限。他们可以在每个对象类型的安全性部分管理这些权限。
为用户和/或组授予对象类型上的角色仅赋予他们对象类型定义及其元数据的权限，并不授予数据本身的任何权限。数据的权限由基础数据源上的权限管理。
限制Object实例
稍后我们决定要整合乘客数据，因此我们集成并搭建了乘客数据管道。
出于合规原因，我们可能希望运营用户只能看到他们所在国家的乘客（美国用户只能看到美国乘客，德国用户只能看到德国乘客等）。因为我们的Object类型由数据集支持，其权限与整个数据集绑定。如果我们想限制单个行的权限，我们需要通过受限视图支持我们的Object类型，这是一种对单个数据集进行行权限控制的视图。
在创建受限视图时，我们需要完成以下前提步骤：
- 创建一个全局组，
passenger-data-global-access，以便所有管理用户访问全局乘客数据。 - 确认我们的用户具备必要的地理用户属性（例如
location:country - US）。 - 为受限视图创建一个项目，称为 Customer Information [Restricted]，其中将包含所有现在和将来与客户信息相关的受限视图。这将允许我们将受限视图的访问权限与基础输入数据集分开。
用户属性可以在用户管理UI中手动配置，或从您的SAML设置自动映射。
在完成上述前提条件后，我们可以继续创建受限视图。转到输入数据集资源并选择 创建受限视图，如下所示。
受限视图向导将引导您完成所有步骤。将受限视图保存到我们之前创建的新**Customer Information [Restricted]**项目中。
策略是受限视图的核心部分，因为它决定了用户可以看到哪些行。在此示例中，我们将希望：
- 仅显示用户属性
location:country与数据集中的country列值匹配的行，或者 - 当用户是
passenger-data-global-access组的成员时显示所有行。
以下是具体策略的样子：
在向导完成后，受限视图将被搭建。在搭建完成后，我们可以使用我们的受限视图来支持我们的乘客对象。对象类型将自动继承受限视图策略，并使用该策略限制用户可以看到的对象实例。
将数据添加到数据目录
数据目录是Foundry中经过策划的内容的可浏览视图。虽然Foundry中的每个数据集都可以进行分析，只要您拥有正确的权限，但数据目录中的数据集已被识别为对用户最有用或相关的，并收集在此以便于访问。
在搭建完您的Ontology后，建议您将所有Ontology数据集添加到数据目录中。特别是，Ontology数据输出数据集应添加到您的数据目录中，因为它们是对象数据的规范来源。
授予用户访问您的应用程序
在搭建了Flight、Flight Alert、Delay、Aircraft和Passenger对象后，我们继续按照工作坊文档为运营中心搭建了航班警报收件箱应用程序。鉴于我们希望区分可以编辑航班警报收件箱应用程序和可以编辑Ontology数据的人员，我们将专门为航班警报收件箱应用程序创建一个新项目。新项目将被称为Flight Alert Inbox。
要访问此项目，用户必须满足所有访问要求。由于项目没有关联权限标记，用户需要一个角色并且必须是Sky Industries组织的成员。
运营用户将被添加到Aviation [Ontology] - 只读组以查看航班、航班警报、延误、飞机和乘客数据，并添加到Flight Alert Inbox - 只读组以查看航班警报收件箱应用程序。
应用程序开发者将被添加到Aviation [Ontology] - 只读组以查看航班、航班警报、延误、飞机和乘客数据，并添加到Flight Alert Inbox - 编辑组以便他们可以编辑航班警报收件箱应用程序。
数据管道开发者将被添加到Aviation [Ontology] - 编辑组以编辑航班、航班警报、延误、飞机和乘客数据集，并添加到Flight Alert Inbox - 只读组以便他们可以查看更改后下游的工作流程。
