Here we illustrate the federating process through a small example from a (semi-)smart building, illustrated in the figure below. Our toy configuration consists of a room and a corridor in the same building. The room is equipped with a presence sensor and a door contact sensor, while the corridor is equipped with a movement sensor and a door sensor for each door in the corridor. These two building entities use two different IoT platforms because they are managed by different stakeholders. The room uses openHAB and the corridor uses FIWARE. These two platforms both use REST as their architectural style and exposes a URI as entry point to represent resources and relations with other resources. At the very beginning, we only get two URIs as two platform entry points without any further information.
In the example, we present how we explore data through two APIs and respectively build two RDF graphs through an extraction and semantic annotation process. Finally we reconcile the identification and the descriptions of the same physical entities described by IoT two platforms and federate two platforms into a large one.
Generally, the process of federating platforms is an iterative process of resource discovery, JSON extraction, semantic annotation, and information inference. This process gradually transforms plainJSON to semantically-rich JSON-LD and enables user query from a higher abstraction level (semantic level) to get global information from different entities.
1. Resource discovery
At the beginning, we only have two URIs as REST entrypoints of openHAB and FIWARE platforms. From the entrypoints, we respectly discover local devices managed by the platforms: a door, a door sensor and a presence sensor are managed by openHAB; a door, a door sensor and a movement sensor managed by FIWARE. The resource discovery result is presented in the figure below.
2. Resource Generation
For each resource discovered, we create a node in RDF graph and link related nodes in REST APIs. the resource generation result is presented in the figure below.
3. JSON extraction
Here, we extract information from resource descriptions based on JSON and respectively add them to the graph. This extraction process is briefly presented as: all JSON keys are represented as arcs in the graph, and all JSON values are transformed to nodes that are target of their correspondent arcs. The extraction result is presented in the figure below. For example, we can see the state of movement sensor 3 is “false”.
4. Semantic annotation
Here we temporarily associate all graph elements with the most general semantic tags to transform the graph to a real semantical RDF graph. All edges are rdf:predicate which is the most general relation between RDF nodes, while all notes are types of rdfs:Resource, the general concept to describe everything.
And then we replace the general semantic tags by more precise semantic tags. The result of semantic annotation is a semantically-rich RDF graph as presented in the figure below. The semantic annotation can be done either manually or automatically, and the annotation methods are out of our discussion scope.
5. Information Inference
After semantic annotation, we deduce implicit knowledge to enrich RDF graphs based on semantics. In our example, the deduced implicit knowledge is as follows:
1. The states of the two doors are obtained by use of the states of their internal devices “Door Sensor”, and thus we have added two nodes “State” linked with two nodes “Door” and two values of “Door Sensor”.
2. After a period of time, we observe that each time the state of “door1” changes, the state of “door301” also changes. Based on this we deduce that the two doors are actually the same entity that is described by two IoT platforms. We add a semantic relation “owl:sameAs” between the two nodes in RDF graph, and the two data from two platforms are then linked. Furthermore, based on the fact that two building entities “Room1” and “Corridor1” share the same entity “Door”, we can infer that “Room1” and “Corridor1” are connected by the “Door”. We thus add the relation “physicallyConnectedTo” between the two nodes and the two platforms are thus federated in our example.
