Thing’in Core Modules

Semantic Management

Model & Ontology

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 avatar attributes,
the avatar subparts,
the relations with other avatars.

The description language adopted inside Ziggy is RDF/OWL (used for web semantics).

Ontology Lookup Service

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…

-*find concepts containing « fire » inside their name.

-*find concepts containing « fire » inside their commentaries.

Enrichment

Use of the ontologies to make direct inferences of links: inverse, symmetric, equivalence

Object Management

CRUD on Graph

Property graph

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 Graph

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

Access Modalities

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 Trigger (follow Object)

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)

Id Managment

Ziggy should provide a identification process for each object.
-*Unique, universal ?

Time Management

State Historization

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

Link Historization

Graph Historization

Analytics