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:
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):