Internet of Things (IoT) data are mostly cloistered in closed IoT infrastructures and vertically integrated applications, failing to leverage the potential interlinking of corresponding APIs. We propose a data model based on JSON-LD, in which semantics are added to Web of Things (WoT) APIs, enhancing their interoperability and evolvability by the composition of nested contexts factoring out shared generic categories. According to this model, we present the blueprint of a framework to automatically and iteratively enrich and interconnect WoT APIs, through a process of resource crawl, syntax extraction, semantic annotation and context generation. Based on our propositions, we demonstrate the idea of cross-fertilizing data with a scenario involving three separate IoT infrastructures, showing how their data are linked and interoperated.
Many existing Internet of Things (IoT) infrastructures are little more than dedicated
stovepipes that connect one set of sensor devices to a few applications, or watertight
silos in exclusive mastery of a single operator, stakeholder (as for e.g. metering
infrastructures) or manufacturer (as for the newish breed of “connected devices”). The
provision of IoT services through APIs relies on such infrastructures, which vary
widely in scope, scale, genericity, and the levels of abstraction of the data they
provide access to. We refer the IoT APIs as Web of Things (WoT) [
A key challenge of WoT API development is the semantic interoperability of data exposed by APIs, which refers to the capability of not only matching data, but also automatically interpreting them. This challenge comes from the heterogeneity of IoT ‘things” (from electronic devices to physical objects), the variety of their data models, the scarcity of explicit data descriptions, and the limited accessibility of data locked inside IoT infrastructures.
In response to this, we propose the idea to cross-fertilize data through WoT APIs
exposed by existing infrastructures. By cross-fertilize, we mean “extract and
propagate semantics to connect, exchange and explore data via semantic links, thus
providing enhanced data understanding and uncovering additional knowledge”. We first
propose an RDF-based data model with JSON-LD [
To illustrate our contribution, we present a smart building configuration containing
a room and a corridor on the same floor managed by different IoT infrastructures. The
room contains a presence sensor and an electrical door lock using FIWARE [
Following Linked Data principles [
either be defined within the same JSON-LD document or by referencing URIs containing context definitions. By referring URIs, the syntax and semantics in a JSONLD description are separated into two documents to ensure the evolvability of model: whenever a semantic update is required, we simply update the context definition in a different URI without making any change in the JSON-LD description. Context composition. JSON-LD supports the composition of several contexts for one document. By context composition, we are able to specify different abstraction levels for semantics included in a JSON-LD document, and promote the reuse of semantic definitions. Higher abstraction levels link data from different domains, while lower abstraction levels link data from the same subdomain. The complete JSON-LD context results from the composition of contexts in different levels.
Compatibility with JSON. JSON-LD is totally compatible with plain JSON, and the compatibility allows directly updating JSON-LD descriptions to IoT APIs based on JSON without making any further change in APIs side.
To take full advantage of JSON-LD, we specify three levels of abstraction for JSONLD contexts. In particular, the value of the “@context” is defined as a URI of a document containing the context definition by composing contexts from different abstraction levels. In the following, we introduce each abstraction level.
Generic IoT Context: Generic IoT context defines common concepts (e.g., thing vs. device, location, time, name, attribute) shared by all domains of IoT. A JSON-LD document refers to only one such context.
Objective: Generic IoT context is used to match and link data from different domains through the common concepts used, if any.
Reference Ontologies: Generic IoT context adopts standard domain-independent
ontologies such as OneM2M ontology [
Domain-specific Context: Domain-specific context defines vocabularies (e.g., SoilHumiditySensor) related to the subdomains of IoT (e.g, Smart Agriculture, Smart Cities and Smart Home). A JSON-LD context can combine one or more domainspecific contexts (e.g. smart energy and smart buildings) since possible it corresponds to devices and data from different subdomains.
Objective: Domain-specific context is used to match and link data from the same subdomain.
Reference Ontologies: Domain-specific context references standard
domaindependent ontologies such as SAREF [
Vendor/Technology-specific Context: Vendor/Technology-specific context provides references for specific terms related to device manufacturers (e.g., Philips® and Netatmo®), protocols (e.g., ZigBee and Z-Wave), or technologies (e.g., CoAP). A JSON-LD context can combine one or more vendor//technology specific contexts since it possible contains data from different vendors/technologies.
Objective: Vendor/Technology specific context aims at mapping vendor/technology
specific terms with generic IoT and domain-specific ontologies to link data.
Reference Ontologies: Vendor/Technology specific context firstly maps
vendor/technology specific vocabularies with generic IoT or domain-specific reference
ontologies; if mapping relation cannot be found, ontologies (e.g., Z-Wave Ontology
[
URI: http://lab.wot-rdf.org/jsonld/thermostat1 { "@context":"http://lab.wotrdf.org/jsonld/context/building", "@id": "http://lab.wot-rdf.org/jsonld/thermostat1", "status": "ok", "body": { "temperature": 21.7, "unit": "Celsius"}, "module_name": "Inside", "rf_status": 161}
{"@context": [ "http://lab.wot-rdf.org/jsonld/GenericIoTContext", "http://lab.wot-rdf.org/jsonld/SmartHomeContext", "http://lab.wot-rdf.org/jsonld/NetatmoContext"]}
{"@context": { "m2m": "http://www.onem2m.org/ontology/Base_Ontology/" "status": "m2m:hasOperationState", "body": "m2m:hasOutput", "unit": "m2m:concerns" }}
{"@context": { "saref": "http://ontology.tno.nl/saref#", "biopax": "http://www.biopax.org/release/biopax-level3.owl#", "temperature": "biopax:temperature" }}
{"@context": { "schema": "http://schema.org/", "m2m": http://www.onem2m.org/ontology/Base_Ontology/, "module_name": "m2m:isPartOf", "rf_status": "netatmo:radioStatus" }} Listing 1. Thermostat example 3
We present the framework of semantics extraction and propagation, which is designed to generate semantic data based on the previous model from WoT APIs. The framework is illustrated in Fig. 1.
REST Entrypoint(s) t()s n i o p d n E L Q R A P S
Formalized JSON-LD TripleStore
URI Graphs General RDF Syntax Graphs Matching Reasoning Clustering Classifying
Finally RDF triples represented in JSON-LD are stored in a triplestore that provides a
SPARQL endpoint for user and application queries.
3.1
Most of IoT infrastructures expose REST APIs for user queries. In order to fully
explore the APIs, a REST crawler is expected to automatically discover REST resources
by following links from REST entry point(s). According to the design principle
HATEOAS of REST, REST resources descriptions must have well-defined ways in
which they expose links to related resources [
In our framework, the REST crawler applies a recursive process of identifying the format of resources, extracting relationships from resource descriptions and generating a RDF graph connecting different resources identified by URIs.
In our scenario, all three distinct IoT infrastructures use REST as their architectural style. Fig. 2 presents the entry points and URI graphs constructed by REST crawler.
eonpternypHoAinBt eFnItWryApoRiEnt eNnetrtaytpmooin®t http://my.openhab.org/rest/items http://lab.fiware.org/room1/ https://api.netatmo.com/api/devicelist/ /smartbulb1 /door1
/presencesensor1 /presencesensor1 /dooractuator1 /thermostat1 Syntax extractor extracts information from discovered resource descriptions and creates from these a stub RDF graph for future semantic annotation.
More than one way transforms hierarchical serialization formats into graphs, and
here we present a recursive method to generate a RDF graph from JSON-based
resource description. Other serialization formats are firstly transformed into JSON and
then are processed in our framework. JSON is built on two base structures, either a
collection of key/value pairs or an array. The extraction process is introduced as
follows: 1) A first subject is generated by use of the JSON-based resource URI; 2) for a
collection of key/value pairs, the keys are used to generate predicates in RDF graph
while the values are regarded as the objects. In case that the value of a key k is
another JSON object obj instead of a simple data type, an anonymous node anode is created
as the object of the key k, and anode is the subject of the key/value pair of obj; 3) for
an array of values, the predicate is regarded as “rdf: predicate”, while the value
elements in array are RDF objects. 4) An elimination algorithm introduced in [
In order to provide semantics for WoT APIs, semantic annotator updates the stub RDF graphs from syntax extractor by associating RDF elements i.e., nodes and arcs, with three levels of context reference ontologies. The semantic annotator proceeds with an iterative process of the following four steps.
Keywords Matching. The descriptions of RDF elements are matched against
ontologies elements i.e., classes and properties. We adopt the semantic matching algorithm
introduced in [
Semantic Reasoning. This step firstly infers the classes and properties in RDF graphs based on ontology property’s domain and range: for a RDF statement, if the predicate between two RDF nodes is identified, the classes of the subject and object can be inferred based on the domain and range of the predicate; equivalently for the contrary case. Secondly, this step infers RDF graph elements following semantic rules which come from the axioms in ontology definitions.
Classifying. This step analyzes graph elements’ connections with other elements and
use pre-trained classifier to refine RDF element. Here we adopt the ontology
classification algorithm introduced in [
Each internal step runs for sequent. At the end of one cycle, the generated RDF graph is sent to the first step to start a new cycle, because certain graph elements deduced by latter steps can possibly be used by previous steps to identify graph elements. The RDF graph automatically and incrementally propagates through such iteration. The iteration stops when the graph has not changed from the previous iteration.
Fig. 3 presents the simplified output graph of semantic annotator, while a detailed
graph is presented in [
dogont:Floor dogont:Room
rdf:type rdf:type dosgmorndadtfr::toLtbygiupgolehnbtt1i:dncooggnotaniitnt:ehsmassSednosgordorfn:tt:ypPprreeredssefe:nntyccepedsSeoeengnsosonortr1:hasSensorrdmfd:2otymopr:e1harsodToohmgino1gndRt:oheglaaodstAnoiotgc:nhotuanast:tAhocartsuSdaeotnogsroonrtth:rdeTfrh:mteyorpmsetaots1tat presencesensor1 dogont:Door doorrdafc:ttuyapteor1
dogont:DoorActuator In order to transform RDF graphs into JSON-LD documents, context generator transforms the result from semantic annotator to formalized JSON-LD documents with three abstraction levels of contexts as defined before.
Since tools exist to transform RDF between different serialization formats [
After generation, IoT data from different sources are connected by the generic IoT context, and IoT data from the same subdomain are also connected through the domain-specific context.
Fig. 4 summarizes the idea of cross-fertilizing IoT data based on our propositions. Semantics extraction and propagation framework connects WoT-RDF infrastructure and IoT infrastructures by constructing RDF graphs from IoT REST interfaces and generating JSON-LD descriptions based on our data model. WoT-RDF infrastructure provides two views for the linked IoT data: general RDF graphs for SPARQL query, and JSON-LD documents to connect IoT infrastructures. Three parts of ontologies respectively provides semantics in three abstraction levels.
Regarding queries, users are able to not only perform local queries through REST APIs of individual IoT infrastructures, but also query through SPARQL endpoints in WoT-RDF infrastructure to get global information between IoT infrastructures and deduce explicit knowledge. Moreover, JSON-LD documents are also stored in WoTRDF infrastructure and are used to update IoT infrastructure-side descriptions (for open IoT infrastructure such as FIWARE). By such updates users are able to locally perform queries via individual infrastructure APIs to get additional semantics and interconnected information.
JSON-LD is a promising evolutionary solution to cross-fertilize data through existing WoT APIs, maintaining full backward compatibility if needed. A framework has been presented to generate, by iterative propagation, specified JSON-LD data from WoT interfaces, and a WoT-RDF “superstructure” has been introduced to interoperate existing WoT infrastructures from the semantic level. This idea has been proposed as a solution for further opening and “semanticizing” the APIs of FIWARE, which is itself a high-level open infrastructure, but it can be taken up, as we have shown as a minimal pragmatic interoperability solution between existing platforms or infrastructures, taken as they are, without the need to subsume, replace or even alter them.