Equivalence Group

Until now, we use a concept of Thing and Projection. The projection denotes the view of a thing by a service (multiple services could have different views of a same thing). Then the concept of Thing represent a way to define an equivalence between projection (all these projections are views of a same physical thing).

The modelization has flaws:

  • for most of objects, there is only one projection, then we have a one to one instanciation for projection-thing. from a storage point of view is not effecient.
  • infer that 2 projections refer to a smae thing is not a simple task. And in most of the cases, this gathering will occur after the creation of projection.
  • the concept of Thing is a equivalence class where the criteria is "as the same physical id".

Then we propose to drop these flaws. We introduce the concept of Equivalence Group (EG), that is manage independly of the projections.

An Equivalence Group is shaped by criterias. A set of projections that considerated as equivalent from a certain point of view. One could define Equivalence Groups base on MAC address, then all the projections that have the same MAC address should be gathered. One other user could define EG based on geo-loc, or based on an age attribute, etc.

Due to the impact on the database: (1) the EG will be managed in an asynchronously way and with a eventual consistency. For the first version, we target only a simple functions to build the EG. EG.function(projection)->hash (uid of a EG of the given type, or NONE if it is impossible to class the projection); (2) The scope of impacted projections should be limited by (domain and/or classes).

The API should cope with this new concept with specific verbs (CRUD):

  • EG Factory : EGF (filter, #function)
  • EG Instance : (Id, EGF.id)