Derived series

Derived series allow users to save and replicate calculations and transformations typically applied to raw (non-derived) time series. By saving this data as Palantir resources, derived series can be shared and saved to the Ontology. Once in the Ontology, derived series behave as raw time series but are calculated on the fly. This eliminates the need to manage or store derived data or duplicate those calculations across the platform.

The following guide explains how to create a derived series in Quiver and save it to the Ontology for use in the platform.

Requirements

The sections below explain the requirements you must follow while creating derived series.

Logic requirements

1. Derived series logic is templated against the root object type and, therefore, must operate on a single root object. If the logic requires time series input on another object type, that object type must be set up as a sensor object type.

For example, the Object time series property card in Quiver allows the selection of time series properties on the current object type as well as time series data on its sensor object types:

2. When creating derived series on linked sensors, they should be accessed from root object type in Quiver rather than doing a search around manually.

3. Aside from time series properties, property references are only templated if they are directly referenced in a Time series formula card using the @ symbol.

Permission requirements

To save a derived series, object type edit permissions are required on the bound object type.

To use automatic Ontology saving, the same permissions are required to configure the necessary sensor object types and Action types. You must also satisfy the submission criteria for the Action types. Additionally, you must be able to view the objects of both the root object type and the sensor object type. Object types with Restricted View data sources are supported; however, if a user can view a root object, they should also be able to view all of its linked sensor objects (and vice versa) for a given derived series.

Sensor object type requirements for automatic Ontology saving

1. The primary key of a sensor object type that is used for automatic saving to the Ontology must be of type String.
2. The sensor object type must be stored with Object Storage V2; this is required for Actions to write to time series properties.
3. The sensor object type must have edits enabled.
4. There must be a single one-to-many cardinality link between the root object type and sensor object type, with the root object type on the "one" side.

Action type requirements for automatic Ontology saving

Automatically saving a derived series to the Ontology is performed through Actions on the sensor object type.

If any of the following requirements are not met, you will not be able to select the Action type for automatic Ontology writes:

1. Each Action type must have a single rule.
2. The Action type parameters must not use constraints that limit what values can be provided. Similarly, the Action type parameters must not use overrides that result in a value constraint. These are strictly disallowed, even if the constraint is reasonable.
3. The Action type should not have unused parameters. If a parameter is unused, it cannot be configured as required.
4. Properties that are not provided a value are considered unmapped. Parameters for unmapped sensor object properties must be configured as "not required". Foreign key properties on the sensor object type that are not for the root object type are always unmapped.
5. The Action type submission criteria must not use parameter-based conditions.

You must create three separate Action types: create, modify, and delete. The rules for these Action type are listed below.

Create object Action type

Rule: Each property type uses a parameter of the same type and edits all properties of the object type. If you are using Ontology Manager to configure an Action type, you must manually create a string parameter for your primary key from the Form tab to the left.

Modify object Action type

Rule: Similar to the Create object Action type, the Modify object Action type should use parameters that are the same type as the associated property types and should edit all properties besides the primary key.

Delete object Action type

Rule: Configure the Delete object Action type to delete a sensor object type. No further property or parameter configuration is required.

Learn more about creating derived series in the next section.