Overview

Beta

Interfaces are in a beta state and support for the feature varies across the Palantir platform. Review the current levels of support for more details.

An interface is an Ontology type that describes the shape of an object type and its capabilities. Interfaces provide object type polymorphism, allowing for consistent modeling of and interaction with object types that share a common shape.

An interface is composed of shared properties, interface link types, and metadata about the interface. An interface can be implemented by multiple object types and can extend one another to allow for composability. An interface can extend any number of other interfaces.

Much like interfaces in programming languages, you can extend an interface to compose interfaces together and have object types implement the interface to indicate that those object types conform to the interface definition. When interacting with objects that implement an interface, you can refer to the object, its properties, and its links by both its local API names as well as the API names of any interface which it implements.

Differences between interfaces and object types

There are both functional and stylistic differences between interfaces and object types within the Ontology.

Object types are concrete; they have schemas defined by shared or local properties, are backed by datasets containing property values, and can be instantiated as objects.

By contrast, interfaces are abstract; they have schemas defined by only shared properties, are not backed by datasets, and cannot be instantiated.

Stylistically, interfaces are visually distinguished from object types in the platform by having dashed lines around their icons.

Example interface icon

Types of interfaces

Interface types usually fall into one of two conceptual buckets: capability interfaces and abstract object interfaces. Neither of these are explicit subtypes within the Ontology, but they are helpful terms to discuss and understand how interfaces are frequently used.

Capability interface

A capability interface represents a distinct capability and facilitates that capability’s reuse on all implementing object types. Capability interfaces tend to have a small set of properties and/or links specific to the capability represented. By implementing a capability interface, an object type may be used in the associated capability.

For example, a Schedulable Resource interface could represent the properties and links necessary to support scheduling of an object type. Implementing object types could include Employee, Conference room, Equipment, or any resource modeled as an object type with the necessary properties and links.

Abstract object interface

An abstract object interface represents a "supertype" of two or more object types that share common properties and links. In contrast to capability interfaces, object types that implement an abstract object interface are likely to have more similarities than differences, and may frequently be bucketed together to represent a more generic supertype.

Abstract object interfaces contain any properties and links common to all related object types. For example, an Employee interface might include Name, Email, and Start Date properties, and a Lead/Manager link to another Employee. Object types that would implement Employee could be Full Time Employee, Intern, or Contractor. All of these individual object types will have three common properties and one common link, so it is helpful for consistency and reusability to ensure that these are represented interchangeably.

Interface example

In the example below, we show a Facility abstract object interface that contains three shared properties (Latitude, Longitude and Facility Identifier) and is applied to two object types (Runway and Airport).

Example interface

Applications that are built to work with the Facility interface can interact with any object type that implements the interface through the interface's shared properties and links. If a third object type uses the same interface (Weather Station, for example), the application can use the shared properties for this additional object type with no code changes to the application.

Interface permissions

Interfaces are permissioned through Ontology roles.

Current levels of support

As support for interface Ontology types expands, availability will vary across the Palantir platform.

Interfaces are currently supported in the following applications and services:

Support for interfaces is in development in the following:

  • Ontology SDK:: Use interfaces as an API layer for interacting with implementing object types. Support varies by language (Typescript, Python, and Java).
  • Object Set Service:: Search, sort, and aggregate objects by interfaces.
  • Actions: Define actions using interfaces as inputs for object creation, modification, and deletion operations so all object types that implement the interface may use that action.

Interfaces are not yet supported in the following:

Get started with interfaces

To add interfaces to your Ontology, you can create new interfaces or extend existing ones. Once you have an interface, you can then implement that interface with an object type of the appropriate shape or edit it to better fit your Organization as your Ontology evolves.