Skip to content

Entity Constraints

Entity constraints is a fundamental piece of configuration in CogTL. It will teach CogTL how to recognize the same entities when they are discovered in different knowledge sources, or reloaded at a later time from the same source.

The fundamental concept of an entity constraint is close to a "primary key" in a relational database, however it can be a bit more complex.

The main and mandatory element of an entity constraint, are the entity type on which the constraint applies, and the identifiers, i.e. the data types of this entity type that have to be unique in the whole knowledge graph (or a specific context).

Simple constraints

For entities types that directly have an identifier under the form of an unique data type, a constraint is very simple. For example, a constraint for a Bank account could be defined on its data type IBAN, which is universally unique.

If two or more data types have to be considered to identify an entity, you can define multiple identifiers in the configuration. For example, in several customer loyalty programs, a Client can be identified by a combination of its name, first name, and birth date or city.

Containment

In some situation, the unicity of an entity depends on one (or more) identifier, but also on a "context", or a "scope" relative to the relations of this entity with other entities. Typically, we are speaking about entities that are "locally unique". For example a City is identified by its data type name, but in the context of a Country (or maybe a Region). For example, "Paris" is unique in France, but not universally unique as a city named "Paris" also exists in Texas, USA.

To be able to express thoses constraints, CogTL allows to express contained constraints. It requires to define a container entity type (Country in our previous example), and the relation type (or a set of relation features) that link the constrained entity type with this container (in our example, typically a relation like is located in).

Remember that CogTL looke for relations that a directed from the Container to the Constrained entity. If your relation type is in the opposite direction, the relation must be followed Backwards.

Conditional application

It is also possible in certain situations that an entity constraint doesn't always apply, depending on other conditions. For example, an IP address can be universally unique, except if it is part of one of the reserved subnets for local area networks (10.0.0.0/8, 192.168.0.0/16, etc), or the loopback interface (127.0.0.1). To address that kind of constraint, a Condition can be expressed to apply the constraint on any IP address except if it is part of one of those subnets.

Warning with conditional constraints

Conditional constraints usage should be used only for exceptional cases, as it requires much more computing, affecting global performances, and can have side effects like unsteady entities, i.e. entities that are deleted and recreated repetitively when sources are reloaded or assertions recalculated.