Ontologies

An ontology is an artifact which stores ontological resources or entities, including the following:

• Object types
• Link types
• Action types
• Interfaces
• Shared properties
• Object type groups

We call these resources Ontology resources. An ontology can either be private and assigned to a single organization or shared among multiple organizations. Shared ontologies allow users of different organizations to share data and workflows safely. Grouping entities in ontologies ensures that only users of the specified organizations can access ontological entities.

Relation with spaces

An ontology is mapped 1:1 with a space. When a new space is created, a corresponding ontology with the same name is simultaneously created with the same organization markings as the space. A private space will map to a private ontology, while a shared space will map to a shared ontology.

Private vs. shared ontologies

Which kind of ontology you need depends on how many organizations must work with the same object types, link types, and action types. Organizations enforce strict separation between groups of users and resources, and in most cases a company has a single organization. Only members and guest members of an organization applied to an ontology can be granted access to the resources it holds.

When to use a private ontology

Choose a private ontology when everyone who needs the objects belongs to one organization. This covers most workflows.

For example, Sky Industries builds a Flight Alert Inbox application for its own support team. The application uses the Flight, Flight Alert, Delay, and Aircraft object types, the link types that connect them, and the action types its users apply. All of these describe Sky Industries operations, and only Sky Industries employees should see them. Sky Industries builds the workflow in its private space, so the ontology mapped to that space restricts every one of those resources to the Sky Industries organization.

Several teams share this single ontology: the operational consumers who use the application, the application developers who build it, and the pipeline developers who maintain its backing data. Working with other teams is not a reason to create a second ontology. To control which teams can reach which resources, grant roles to groups on the projects that hold those resources.

When to use a shared ontology

Choose a shared ontology when people in two or more organizations must work with the same objects.

Continuing the example, Sunrise Airline wants to reduce the aircraft delays caused by maintenance issues, and agrees to combine its maintenance data with Sky Industries flight delay data. The two companies need one set of object types that spans both: maintenance issues from Sunrise Airline data, linked to Aircraft and Delay objects built from Sky Industries data. Analysts at both companies must be able to open those objects and apply the same action types. A private ontology cannot support this: it is restricted to a single organization, so users at the other company cannot be granted access to its resources.

Instead, an administrator creates a shared space with both the Sky Industries and Sunrise Airline organizations applied. The shared ontology created alongside that space carries both organization markings, so analysts at both companies can be granted access to the joint object types, link types, and action types. Each company keeps its own private space and private ontology for the data and workflows it does not want to share.

For a step-by-step walkthrough of this scenario, including how to create the organization, the spaces, and the shared project, review Workflow: Cross-organization collaboration. For more details on shared ontologies, review Shared ontologies.