Ontologies 资源管理（Ontologies overview）

Ontologies 资源管理（Ontologies overview）：前一篇认识了本体的"零件"，这一篇认识装这些零件的"容器"——Ontology 本身。它是私有还是共享？和 space 是什么关系？什么时候该开第二个？一篇讲清。

原文定义：Ontology 是一个工件（artifact），用来存放本体的资源或实体，也就是我们前面讲的那几类—— 对象类型、链接类型、动作类型等。我们统称它们为 Ontology resources（本体资源）。

一个本体可以是私有的（private），只属于单个组织（organization）；也可以是共享的（shared），在多个组织之间共享。 把实体归到本体里，是为了保证只有指定组织的用户才能访问这些本体实体。

本体和 space（空间）是 1:1 映射的。当你新建一个 space 时， 平台会同时创建一个同名的本体，并带上与该 space 相同的组织标记（markings）。

• 私有 space → 映射出私有本体；
• 共享 space → 映射出共享本体。

所以"建本体"通常不是你手动点出来的，而是建 space 时自动生成的——你后续往里"装"对象类型等资源。

Sky Industries 给自家客服团队做了一个"航班提醒收件箱"应用，用到 Flight、Flight Alert、Delay、Aircraft 这些对象类型，以及把它们连起来的链接类型、用户执行的动作类型。这些只描述 Sky 自己的运营，只有 Sky 员工才该看到。

于是 Sky 在自己的私有 space里搭这套工作流，映射出来的私有本体就把这些资源全部限制在了 Sky 组织内。

Sunrise Airline 想减少由维护问题导致的航班延误，于是同意把自家的维护数据和 Sky 的航班延误数据合并分析。 两家公司需要同一套对象类型，横跨两边：来自 Sunrise 的维护问题，连到来自 Sky 数据的 Aircraft 和 Delay 对象； 两边分析师都要能打开这些对象、执行同样的动作类型。

私有本体做不到这件事——它被限制在单一组织，另一家公司的用户无法被授权访问其资源。 解决办法：管理员创建一个共享 space，同时应用 Sky 和 Sunrise 两个组织；随之生成的共享本体就带上双方的标记， 两边分析师都能被授权访问这批共有的对象/链接/动作类型。两家公司各自仍保留私有 space 与私有本体，装不共享的数据。

原文特别强调一个容易误解的点：创建共享本体，并不会自动让底层数据对每一个应用组织都可见。 如果一个数据集是从某个私有项目引用进共享项目的，它仍然保留来源组织的访问要求—— 另一组织的用户在被放开前，依然看不到那份数据。

↑ 点击展开。换句话说："共享"开放的是"对象定义能被多组织授权"，而不是"数据自动人人可见"。