This article describes the concept of creating structured views of multiple Twins on the Trusted Twin platform.
The purpose of this article is to provide system architects and developers with conceptual knowledge required to design solutions on the Trusted Twin platform. For developer resources, please consult the Trusted Twin docs website.
5 min read.
Shared processes (i.e., processes involving multiple cooperating organizations) usually operate on specific shared objects (i.e., Twins). As Twins tie together all knowledge provided by all partners and act as conceptual “brackets” for the data, they are the most important objects in operational data sharing. Trusted Twin shared object concept
Sometimes it is necessary to have access to structured views of multiple Twins. Such structured views can be useful for, among others, advanced search or ML/AI training or analysis.
The Trusted Twin platform supports two types of such structured views: Indexes and Timeseries. Both structured views, once defined and configured, are being automatically updated every time Twins’ properties change. Therefore, they always hold current data.
The Trusted Twin platform stores Indexes and Timeseries tables in dedicated instances of relational databases, created individually for each account. This is to provide the highest possible level of security (i.e., data separation), but also to allow direct database access and execution of SQL queries for the account.
Indexes hold a set of properties of selected Twins (i.e., values from account’s Ledger attached to the given Twin). Each Index is a separate database table. Multiple Indexes can be created by a single account.
Each Index is defined as:
- a Twin selection rule, Trusted Twin access rules concept
- list of properties and their types,
- list of templates for calculating values of the properties Trusted Twin templates concept
Every time the value of an Entry in the Twin’s Ledger is changed, the Twin selection rule is evaluated. If the rule resolves to True, the values of properties are calculated and the corresponding row is inserted/updated. If it evaluates to False, the new row is not inserted or the corresponding row is deleted. Therefore, the given index stores only information about the Twins selected by the Twin selection rule. A single Twin can be represented in a single Index only once.
Timeseries hold a series of measurements. They differ from Indexes in that the primary key is defined as a tuple containing a Twin UUID and a timestamp, not just a Twin UUID. Each Timeseries is a separate database table. Multiple Timeseries can be created by a single account.
Each Timeseries is defined as:
- list of dimensions and their types,
- list of measurements and their types,
- a timestamp default template,
- dimensions default templates,
- measurements default templates.
Timeseries do not use Twin selection rules (refer to Indexes) as they are configured as Entry properties directly in the Ledger. Every time a value of an Entry with a timeseries property set is changed, the corresponding row holding timestamp, dimensions and measurements is appended to the Timeseries table. Once appended, rows stay in the Timeseries table for the defined retention period.
Tips & tricks
- If you need historical values of Ledger Entries, but do not require structured views of Twins, you can use the standard History service.
- Indexes and Timeseries are configured in a slightly different way. Indexes are configured outside the Ledger and are based on Twin selection rules. Timeseries are configured directly in the Ledger Entries as properties.
- The Trusted Twin platform allows for direct access to Indexes and Timeseries tables.