Node

{{#eclipseproject:technology.higgins}}

Introduction

This page describes the Higgins concept of Entity.

It is similar to the Identity Gang Lexicon's definition of Digital Subject. The term was changed to eliminate any possible confusion with the term subject (or data subject) in international privacy law.

A Higgins Entity is a representation of an Entity within a given context. Entitys and Entities are not the same concept. The distinction is subtle but critical. In Higgins the same Entity is usually represented by multiple Entitys in different Contexts.

Definition

• A digital representation of an Entity
• A Entity has zero or more Attributes

Details

• Although not strictly required, almost all Entitys have a single EntityId Attribute in addition to whatever other kinds of Attributes they may have. This EntityId Attribute has a value of type EntityId Data Range and uniquely identifies the Entity within its containing Context.
• Some of the Attributes of an Entity may be references to other Entitys in the same or different Contexts. These are called Entity Relations. For example, an Entity representing the Entity Bob may have a "knows" Entity Relation Attribute pointing to an Entity representing Bob's friend Alice.
• A single person (thing or concept) may be represented as one (or more) Entitys in one Context and (an)other Entitys in other Contexts. By linking or "federating" these disparate Entitys one can gain a more unified view of a given person. Contexts representing different systems, organizations and entire enterprises with widely varying storage and trust models are handled using this Entity linking approach. For example the person "Bob Smith" could be represented as two Entitys; the first having "bsmith" as an EntityId and the second having "bob" as a EntityId. These two Entitys may be in the same or in different Contexts. To express that the "bsmith" is the same person as "bob" an Entity Correlation Attribute would be added to "bsmith" whose value points to "bob".
• Contexts can be nested (e.g. enterprises have sub-organizations, and there are systems within an enterprise/org, etc.) or related through other means (employment/HR system vs. customer system where same person is a customer and an employee). Thus linking the Entitys relevant to those contexts provides an a broader view of a Entity.
• The information contained in one Entity is not necessarily a pure subset of the union of all of the information contained in all of the linked Entitys representing a person taken together. There is no consistency constraint imposed between the Entitys of an person. For example, a person could be represented such that their name was Joe in one Entity in one Context and JoAnn in another Entity in another Context.

Entity Subclasses

Each Context has an associated ontology/schema. This schema must import and build on the terms in HOWL. Within this ontology the Context can define its own Entity subclasses and Attribute types. When defining a Entity subclass, the class definition can place restrictions on the cardinality of Attribute types also defined in the ontology. A given Entity subclass:

• MAY define the minimum cardinality of an Attribute, that is, the minimum number of values allowed (e.g. >=3 values)
  • MAY define the maximum cardinality of an Attribute, that is, the minimum number of values allowed (e.g. <=100 values)

See Also

• ContextId
• EntityId
• Concepts