Semantic Techniques to Support IoT Interoperability
239
Fig. 7 FitBit API graph
The API graph contains, in this specific case, one Sensor (Google Fit Service),
three methods (step_count, calories_estimate and distance_calculation) and three
parameters (Start and EndTime, which are simple Input Parameters, and Bucket,
which is a complex Output Parameter). Whereas this kind of representation is immediately readable by machines, it still lacks proper contextualization, that is a clear
disambiguation of the meaning of the elements composing it. For this reason, a
Domain Ontology is needed. Domain ontologies provide the semantics necessary to
properly describe terms and entities. Several domain ontologies exist, especially in
the medical field, but a good number of IoT ontologies have also been populated, as
reported in [5]. If we consider a domain ontology, the API Graph can be enriched with
further information: Fig. 7 reports the API Graph of a FitBit sensor, with the basic
methods and parameters elements, but enriched via an external domain ontology with
the “Steps” concepts, use to annotate the “delta” and “step” parameters belonging
to the FitBit. By annotating the entities of the sensors’ ontology, it is possible to
create connections among elements and exploit the reasoning capabilities provided
by semantic technologies. As an instance, if two methods are annotated with the
same concepts, it is likely that they are interrelated and that, in a sensor network,
they could serve the same objective and could be used together. Also, this allows the
discovery of sensors and services used to interact with them. The main drawback is
that annotation is currently done manually, via a semantic annotation window which
is part of the tool. It is still very difficult to avoid human intervention in this phase, as
parameters and methods’ names are not always (if ever) meaningful. Figure 8 shows
the annotation window which can be used to specify connections between elements
of two different ontologies. The tool can operate on whatever ontology it is loaded
with, so it is more of a generic semantic annotator than a sensor specific one. It can
be used to connect individuals of the Parameter, Sensor and Method classes with
each other, or with entities defined in domain ontologies. The tool support the free
239
Fig. 7 FitBit API graph
The API graph contains, in this specific case, one Sensor (Google Fit Service),
three methods (step_count, calories_estimate and distance_calculation) and three
parameters (Start and EndTime, which are simple Input Parameters, and Bucket,
which is a complex Output Parameter). Whereas this kind of representation is immediately readable by machines, it still lacks proper contextualization, that is a clear
disambiguation of the meaning of the elements composing it. For this reason, a
Domain Ontology is needed. Domain ontologies provide the semantics necessary to
properly describe terms and entities. Several domain ontologies exist, especially in
the medical field, but a good number of IoT ontologies have also been populated, as
reported in [5]. If we consider a domain ontology, the API Graph can be enriched with
further information: Fig. 7 reports the API Graph of a FitBit sensor, with the basic
methods and parameters elements, but enriched via an external domain ontology with
the “Steps” concepts, use to annotate the “delta” and “step” parameters belonging
to the FitBit. By annotating the entities of the sensors’ ontology, it is possible to
create connections among elements and exploit the reasoning capabilities provided
by semantic technologies. As an instance, if two methods are annotated with the
same concepts, it is likely that they are interrelated and that, in a sensor network,
they could serve the same objective and could be used together. Also, this allows the
discovery of sensors and services used to interact with them. The main drawback is
that annotation is currently done manually, via a semantic annotation window which
is part of the tool. It is still very difficult to avoid human intervention in this phase, as
parameters and methods’ names are not always (if ever) meaningful. Figure 8 shows
the annotation window which can be used to specify connections between elements
of two different ontologies. The tool can operate on whatever ontology it is loaded
with, so it is more of a generic semantic annotator than a sensor specific one. It can
be used to connect individuals of the Parameter, Sensor and Method classes with
each other, or with entities defined in domain ontologies. The tool support the free