Each object can have a representation inside Ziggy : Avatar.
An avatar should respect a model (as UML approach, an avatar is an instance of class).
A model is a public description of
The description language adopted inside Ziggy is RDF/OWL (used for web semantics).
The Ontology Lookup Service (OLS) is the repository of the models that can be used inside Ziggy.
New models can be injected dynamically, nevertheless the ontologies should be validated before it can be used.
OLS provides lookup over the ontologies, find concepts from name, attributes, words inside the description…
Use of the ontologies to make direct inferences of links: inverse, symmetric, equivalence
Store object as document composed of metadata key-value pairs.
Each object is a graph vertex, and the links between objects are the edges.
Each edge is labeled by a document allowing very complex links.
Ziggy data can be seen as a single big graph.
To manage this graph, dedicated functions are proposed to :
Add/update/remove objects (aka vertex) and links (aka edges)
Search on Property graph
Search for a Object from its class (and inherintance), its attributes values, link label values, graph pattern (like SPARQL, not yet implemented).
JD = Search for First Object of class <Person> where (attr[« lastname »] == « Doe ») and (attr[« firstname »] == « John »).
Search for Object of class <Bicycle> where (attr[« age »] == 5) and (edge[« belongs to »] == JD).
Ziggy Core does not provide directly the canal to communicate with the real object but It can store the information (as metadata) to find it (Protocol, address, endpoint, API, …)
Inside Ziggy these information (aka access modalities) are processed as any other metadata.
Ziggy triggers are processes that can send events to listeners.
As Ziggy is a knowledge base of objects, given an object O it’s up to the manager of O to update the O information in Ziggy.
Some service would like to follow O updates, and to avoid a pull approach that will create useless traffic, Ziggy provides a Push approach. The service registers itself to follow O, then upon a modification occurs on O, Ziggy send a notification to the service.
Ziggy Triggers exist for single object or for namespace (objects aggregate in a same bucket)
Ziggy should provide a identification process for each object.
Unique, universal ?
Ziggy provides different functionalities to follow the evolution object during time.
An object attribute can be flagged as <historized state> then all the updates that occur on this attribute will be historized (in a special time series database).
Ziggy provides time series language to request this database
get the timestamped values of the attribute during a time window
get the average/variance of the attribute values during a time window