International Journal of Distributed Systems and Technologies, x(x), x-x,
Semantic Interoperability on the
Internet of Things:
The Semantic Smart Gateway
Framework
1
Konstantinos Kotis* , VTT Technical Research Centre of Finland, FI
Artem Katasonov, VTT Technical Research Centre of Finland, FI
Abstract
Internet of Things should be able to integrate an extremely large amount of distributed and heterogeneous entities.
To tackle heterogeneity, these entities will need to be consistently and formally represented and managed
(registered, aligned, composed and queried) trough suitable abstraction technologies. Two distinct types of these
entities are a) sensing/actuating devices that observe some features of interest or act on some other entities (call it
‘smart entities’), and b) applications that utilize the data sensed from or sent to the smart entities (call it ‘control
entities’). The aim of this paper is to present the Semantic Smart Gateway Framework for supporting semantic
interoperability between these types of heterogeneous IoT entities. More specifically, the paper describes an
ontology as the key technology for the abstraction and semantic registration of these entities, towards supporting
their automated deployment. The paper also described the alignment of IoT entities and of their exchanged
messages. More important, the paper presents a use case scenario and a proof-of-concept implementation.
Keywords: Semantic Registry, Ontology, Internet of Things, Semantic Interoperability, Ontology Alignment
Introduction
Internet of Things enables a global connectivity between the real world and a virtual
world of millions of distributed entities (observed subjects / objects, sensing / actuating / identity
/ embedded devices, software applications / services), connects things, not only places or people,
and brings real-time machine-published big data to the users of the existing Web.
The ‘things’ on the IoT are various physical entities that are of some interest to humans,
e.g. a heater to control, a package to track, an industrial machine to monitor, the air temperature
in a room to measure, the motion in a room to detect. Depending on the nature of these ‘things’,
different technologies for connecting them to the IoT are used: a) identity devices (e.g. RFID
tags or barcodes), b) sensing and actuating devices (e.g. temperature and other sensors, cameras
for cars’ register plate recognition, and actuators like remotely-controlled door locks or window
blind controls), and c) embedded electronics (e.g. industrial machinery, home electronics, smart
phones and wearable devices that have embedded parts e.g. processors, data storages, sensors
and actuators).
1
This work was carried out during the tenure of an ERCIM "Alain Bensoussan" Fellowship Programme. This Programme is supported by the
Marie Curie Co-funding of Regional, National and International Programmes (COFUND) of the European Commission.
* Corresponding Author: Please contact him at kotis@aegean.gr
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
Due to the large diversity of millions of devices, and the consequent distribution of their
storage and data analysis resources in order to handle the problem of big data, IoT requires
interoperability at multiple levels. On the hardware side, such problems have to be addressed as
handling a capability mismatch between traditional Internet hosts and small devices, as well as
handling widely differing communication and processing capabilities in different devices. In the
interface between the device and network domains, IoT gateways will provide a common
interface towards many heterogeneous devices and networks. Some IoT devices, e.g. home
electronic appliances will be likely connected directly to the Internet without such middle-boxes.
For the communication between heterogeneous IoT devices and applications towards the
automated deployment of latter in environments where the former have been already deployed,
there is currently a gap of a facilitator technology (interface). Third-party applications that are
developed without being aware of devices’ data models (descriptions), but being generic in the
sense of being capable of running on various IoT device sets, will not be possible to be
automatically deployed. Such inability is caused by the semantic gap between heterogeneous
data of both types of entities i.e. devices and applications. Such a gap can be bridged by aligning
the meaning of data that both types of entities may ‘carry’ and use these alignments for their
semantic matchmaking.
Based on the above ascertainments, distributed and heterogeneous IoT entities need to be
consistently, explicitly and formally represented and managed (registered, aligned, composed,
and discovered) through suitable abstraction technologies i.e. ontologies. Such a representation
and management capability will enable their seamless integration in different application
domains of IoT, such as smart home, ambient assisted living, transportation, etc., in a way that
deployment of third-party generic applications in non-expert end-users’ IoT settings will be
performed automatically, with minimum involvement of both non-experts and experts.
In this paper we focus on the use of semantic technologies, for the automated deployment
of heterogeneous and distributed IoT entities, supporting the following three distinct tasks: a) the
semantic registration of IoT entities, b) the alignment of IoT entities’ metadata and use of these
alignments for their matchmaking, and c) the alignment of the semantics of the data of the
messages that are exchanged between these IoT entities during device-to-application
communication. We view the deployment of third-party generic applications in such settings as
an automated process that hides from end-users the complexity of tasks such as ontology
alignment and semantic matchmaking of IoT entities. These complex tasks are not expected to be
performed by non-expert end-users but rather they should be supported by an expert third-party
service provider e.g. an IoT semantic interoperability as a service (SIaaS) provider that acts as a
mediator between IoT application providers and consumers, placing the ontology alignment and
semantic matchmaking tasks of the deployment process of IoT entities in a mediation layer of the
IoT stack.
In this paper, we consider ontologies as a key technology to solve the problem of
automating the deployment of applications in heterogeneous IoT environments, allowing any IoT
entity to unambiguously convey the meaning of data/information they ‘carry’. The aim of the
presented ontology as an abstraction technology is to hide heterogeneity of IoT entities, acting as
a mediator between IoT application providers and consumers, and to support their semantic
matchmaking. Acting as a mediator, the ontology objective is to be used by the interested
stakeholders independently as a registry for the semantic registration of IoT entities, i.e. by the
IoT application providers/developers that will register their software and by the IoT application
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
consumers/users and IoT device owners that will register their sensing/actuating/embedded
devices and the associations of these devices with the observed subjects/objects. The ontology
(as a semantic registry) must be engineered in an efficient and effective way, so that the
alignment and matchmaking of IoT entities (by appropriate software tools of a Semantic Smart
Gateway Framework,) will be facilitated.
The work reported in this paper is particularly motivated by our vision of an open and
interoperable IoT, where at least the following four related requirements must be satisfied:
Ability to have gradually growing IoT environments, contrasted to the need to install and
interconnect all IoT devices and software at once
Ability to interconnect IoT entities from different vendors
Ability of 3rd parties to develop software applications for IoT environments, contrasted
to applications coming only from the devices’ vendors.
Ability to develop applications that are generic in the sense of running on various IoT
device sets (different vendors, same purpose), contrasted to developing applications for a
very particular configurations of devices.
The paper is an extension of the work introduced by Kotis & Katasonov (2012). More
specifically, the paper extends the previous work by a) presenting a new scenario and elaborating
on this for extracting revised requirements of the implemented Semantic Smart Gateway
Framework (SSGF) architecture, b) implementing the proposed components of the SSGF i.e. the
semantic registry and the alignment of IoT entities, and c) validating and evaluating the
implemented toolset based on the scenario and on open evaluation datasets of Ontology
Alignment Evaluation Initiative (OAEI).
The paper is structured as follows: motivation and related work of this paper is presented
in the corresponding homonym section. Next two sections present a use case matchmaking and
deployment scenario for IoT entities and a description of the overall SSGF approach.
Furthermore, the paper provides a section for the description of the developed ontology as a
semantic registry, based on an indicative scenario of its use. The last section of this paper, just
before the concluding remarks and future plans section, outlines implementation and evaluation
information of the presented approach.
Motivation and Related Work
The main motivation of this work is driven by the need to support the automation of the
process of the deployment of applications in distributed and heterogeneous IoT settings, with the
minimum human involvement at the end-users’ side i.e. providers and consumers of IoT
applications, and with minimum human involvement at the experts-side i.e. experts on ontology
alignment and matchmaking of IoT entities. As already introduced, such a process can be
realized through an ontology acting as a semantic registry and by a set of tools for the alignment
and matchmaking of the semantically registered (in the ontology) IoT entities.
Based on the abovementioned motivations and also on the ‘abstraction level challenge”
of the Semantic Sensor Web (Corcho & Garcia-Castro, 2010) and from the future work
directions of the W3C XG’s final report on the Semantic Sensor Network (SSN) ontology
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
(Barnaghi, Compton, Corcho, Castro, Graybeal, Herzog, Janowicz, Neuhaus, Nikolov, & Page,
2011) we identified the lack of a set of high-level abstractions of IoT entities any of the existing
related work.
More specifically, we identified the lack of the notion of a smart entity (SE) which
corresponds to an abstract representation of the association between a)
sensing/actuating/embedded/identity devices, b) features of interest that they are observe, and c)
software agents that are responsible for the entity’s conceptualization (domain ontology) and for
entity’s functionality (provided as a service).
In addition, existing works do not represent applications as IoT entities, similarly to SEs.
In our context, we refer to these entities as control entities (CE). This lack of conceptualization
of both types of IoT entities prohibits the task of automated alignment and matchmaking and,
consequently, the automated deployment of them in heterogeneous IoT environments.
Last but not least, most of the existing IoT or sensor-related ontologies represent IoT
devices only partially e.g. sensing devices in SSN ontology. This need for representing richer
information related to IoT entities and their properties conforms also with one of the challenges
of Semantic Web research in terms of smart entities, reported by Sabou (2010) i.e. the
representation of a variety of information regarding smart objects on the IoT.
In the work of Christophe, Verdot & Toubiana (2011) authors present ongoing work
towards an ontological framework for the representation and retrieval of connected smart objects
in the Web of Things (Guinard, Trifa & Wilde, 2010). The notion of a virtual object is partially
in alignment with the smart entity notion presented in this paper. Also, the aim of this related
work for discovering similarities between connected objects is in alignment with the aim of our
ontology. Having said that, the related ontologies were not available for reuse and quite limited
information was provided in the related research paper regarding the devised conceptualizations.
More importantly, this work does not reuse the SSN ontology which is the latest W3C
representational effort to reach consensus on the description of sensed data and observations.
In the related work reported by Hachem, Teixeira & Issarny (2011), author state that has
devised a global ontology for the IoT domain. The work emphasizes the representation of
devices and also the composition and estimation of measurements. However, the work does not
reuse generic and widely-agreed ontologies such as the DUL and SSN ontologies. Most
importantly, this work does not represent the complete knowledge related to all types of IoT
entities and to their alignment. Finally, they are not publicly available for reaching consensus and
for reusing them.
Related work in SOFIA (Honkola, Tyrkkö, Laine, Lappeteläinen, Luukkala, PantsarSyväniemi, Ovaska, Eteläperä, Kiljander, Bellavista, Toninelli, Montanari, Manzaroli, Zamagni,
Cinotti, Scipioni, Azzoni, Luccaroni, Laura, Pucci, Corongiu, Ozcelebi, & Bhardwaj, 2010),
SENSEI (Barnaghi, 2010), SemSorGrid4Env (Gray, García-Castro, Kyzirakos, Karpathiotakis,
Calbimonte, Page, Sadler, Frazer, Galpin, Fernandes, Paton, Corcho, Koubarakis, De Roure,
Martinez, & Gómez-Pérez, 2011), and HYDRA (Eisenhauer, Rosengren, & Antolin, 2009)
projects has been focusing more on middleware frameworks rather than on the modeling of
related knowledge, regarding sensors in smart spaces or federated sensor networks towards
solving small or large-scale data integration problems. A latest effort within the SWISSExperiment (Calbimonte, Jeung, Corcho, & Aberer, 2011) project emphasizes the use of W3C
XG SSN ontology in a large-scale federated sensor network for semantic data sensor search
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
(Calbimonte, Jeung, Corcho, & Aberer, 2011). The SSN ontology is a domain-independent
ontology that describes sensors and observations for use in sensor network and sensor web
applications, by merging sensor-focused, observation-focused and system-focused views
(considering and integrating most of the conceptualization efforts of the other related projects).
The SSN ontology has been devised by taking into consideration the aforementioned related
projects, so reusing it in our work was a key design decision. The aim and scope of the
ontologies developed for these projects are a subset of the one presented in this paper since they
focus only on sensing devices-related information and do not abstract into the higher-level
notions of smart and control entities, towards supporting their alignment and matchmaking (for
automating the deployment of applications in heterogeneous IoT environments).
An IoT conceptual model presented as part of the IoT-A project (Nettsträter, 2012)
defines abstractions of IoT entities as virtual entities but in a different way, i.e. a virtual entity is
a model of a physical entity e.g. a human, a car or even a temperature sensor. Also, this ontology
does not represent applications as IoT entities that can be semantically registered similarly to
smart entities. Last but not least, the ontology fails to follow widely accepted and agreed
ontology design patterns such as the one for modeling sensors and observations as the StimulusSensor-Observation Ontology Design Pattern (Janowicz & Compton, 2010) and it does not reuse
any existing high-level ontology e.g. DUL, or IoT/Sensors-Network-related ontology, e.g. SSN.
In addition, the work presented in this paper is also motivated by the related work of
decentralized semantic coordination of agents in P2P systems (Cudré-Mauroux, Suchit, & Karl,
2007; Spiliopoulos & Vouros, 2012) in respect to the automatic and self-organization of
schema/ontology mappings towards ‘healing’ incorrect mappings of entities in distributed smart
spaces.
Concluding, the modeling and ontology creation effort presented in this paper does not
attempt to compete against related ones but, in contrast, it strives towards reusing them where
and when possible, in order to better support its aim, objectives and scope in the most efficient
and effective way. Furthermore, the presented approach follows a different path from related
modern works that are influenced by the Linked Open Data (LOD) paradigm. In such works,
Linked Data is used as the integrating technology for heterogeneous data of distributed
information spaces from different domains, as the one reported in Graube, Pfeffer, Ziegler, and
Urbas (2012).
An IoT entities’ matchmaking and deployment scenario
In our scenario we have used the domain of home automation, pointing on the need for an
IoT semantic interoperability provider to act as a mediator between home automation/building
management application providers and consumers. The actors of this scenario are shown in Table
1.
Roles
Entities
Consumers
IoT application consumers (and infrastructure owners): buy IoT devices and applications for
their house
IoT infrastructure and data providers: sell sensors, actuators, gateway boxes for home
automation, IoT data feeds from the Cloud
Providers
IoT application providers: sell applications for the IoT home automation/building
management domain
IoT semantic interoperability providers: provide a platform (as a service) for the semantic
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
registry and the alignment/matchmaking of IoT entities. Acts as a mediator for the
deployment of IoT entities
Table 1. Real world physical entities and their consumers and providers in IoT domain
In the same real world, other physical entities are also involved, entities that are related to the
IoT infrastructure, data and applications, provided by different vendors. In Table 2 we outline
examples of such physical entities, organized according to the actors that provide/consume them.
Table 2. Real world physical entities: IoT infrastructure, data and applications/services
Roles
IoT application consumers and
infrastructure owners (e.g. Mary)
IoT infrastructure and IoT data
providers
IoT application providers (e.g.
building management company,
offering security and energy saving
applications/services)
IoT semantic interoperability
providers
a.
b.
c.
a.
b.
c.
d.
e.
Entities
House
Alarm lights/lamp
Air-condition
Vendor-A Temperature sensor
Vendor-B Motion detection sensor
Vendor-C Switch actuator
Vendor-D Luminosity sensor
Vendor-E Gateway box
a. Provider’s application for security monitoring
b. Provider’s application for energy monitoring
a. Semantic registry
b. Semantic interoperability software Platform
(tools for IoT entities’ ontology alignment,
matchmaking, message translation, message
transformation, etc)
Mary is leaving home for a holiday and wants to manage the security and the energy
consumption of her house while abroad. She contacts a building management (BM) service
provider where she is informed about the availability, cost and deployment requirements of the
company’s related applications as a service (AaaS), i.e. a) a security service, and b) an energy
saving service. The necessary infrastructure (equipment) for these services to be able to run is
not provided by BM so Mary is instructed to buy them from a third-party company. The
necessary sensor/actuator devices that Mary bought i.e. a temperature sensor, a motion detection
sensor, a luminosity sensor and two switch actuators, are able to connect to the outside world i.e.
to the Internet, via a gateway box that she also bought from a different vendor. As instructed by
BM, Mary uses the Web interface of an IoT semantic interoperability provider in order to
register the installed IoT equipment. Via a Web interface, the IoT semantic interoperability
provider service allows Mary to simply describe (e.g. using a template-driven form) the installed
infrastructure and provide information on a) their ID and address e.g. URI, b) what physical
entities they are associated with (observe or act on), and c) the approximate labels for the
required input and output data that will be exchanged with the BM IoT application/service
provider. Using the same Web interface, the BM IoT application provider registers the
applications that Mary bought for the security and energy saving of her house. At this point it
must be noted that between the IoT infrastructure in Mary’s house and the IoT semantic
interoperability provider, an additional actor such as an IoT data provider (e.g. COSM) may be
used to store the data coming from Mary’s IoT personal infrastructure, i.e. sensor data. Also, it
must be noted that the MB IoT application provider may have (or not) already associated some
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
domain ontology with the input/output data required for the application to function (annotate the
input/output parameters of the related service using the semantics of a domain ontology, in our
case, a building automation/management ontology). In fact, domain ontologies may or may be
not used from all actors during the automated deployment of heterogeneous IoT entities. For
instance, Mary may register her own IoT smart entities by just providing some free-text labels to
describe their input/output functionality. These labels could be also browsed by a Web-provided
domain ontology for home automation, if available.
Both Mary and BM have the freedom to initiate the deployment process of the registered
applications in Mary’s IoT registered infrastructure, at any time after the registration of all
involved IoT entities. By the execution of the deployment process, the IoT semantic
interoperability provider service executes the alignment and matchmaking tasks for the input and
output parameters of the applications (control entities) against the input and output parameters of
the services related to Mary’s IoT infrastructure (smart entities). These first tasks match the IoT
entities in order to identify which smart entities that ‘live’ in Mary’s house are appropriate for
the applications/services (that Mary bought) to function. The matched entities are stored in the
ontology appropriately (using subclass axioms). Right after this matchmaking and discovery
stage, the deployment process initiates another task in order this time to align the data ‘carried’
in the communication messages that are exchanged between the already matched (from previous
tasks) IoT entities. This latter alignment task is also required since application developers and
IoT device vendors have the freedom to describe the input/output data of their IoT entities in
different ways i.e. using different domain ontologies. These alignments are also stored in the
ontology appropriately (using the corresponding alignment cell structures).
At the end of a successful alignment and matchmaking of IoT entities process, the IoT
semantic interoperability provider service notifies Mary and BM that the deployment process is
successfully ended and that the services are ready to run. The IoT semantic interoperability
provider is responsible for resolving any conflicts in the matchmaking and alignment process
during the deployment process, without involving Mary at any stage of this. The IoT semantic
interoperability provider service is a (semi-)automated service that allows experts’ involvement
for the validation of the alignment and matchmaking tasks.
The Semantic Smart Gateway Framework
In this paper we propose an IoT Semantic Smart Gateway Framework (IoT-SSGF) which
provides a semantic registry for IoT entities (via an IoT ontology abstraction) and a set of tools
that support the a) registered entities’ data message format transformation (from
XML/JSON/URI to OWL), b) the automatic alignment of these transformations, c) the
matchmaking of registered IoT entities. Peers (providers or consumers of IoT entities) must be
able to register new entities or retrieve already registered ones that match certain
properties/criteria. Newly added heterogeneous entities, carrying their vendors’ ontological
descriptions (or other types of metadata) for describing properties of the devices or data they
carry, must be coordinated by aligning their ontology definitions with the definitions of other
related entities.
The IoT-ontology proposed in this paper supports the IoT-SSGF by representing different
types of IoT entities that are fundamental parts of IoT domain, as well as by associating ontology
definitions related to the alignment of ontologies (mapping cells of correspondent alignments
between ontological classes and properties). The IoT-ontology can be views as part of the IoTCopyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
SSGF. The other part of the SSGF is a toolset that utilizes the semantic descriptions of registered
IoT entities towards achieving their automated deployment in IoT environments.
As abovementioned, in case IoT entities are not equipped with ontological descriptions of
their data, a transformation step (e.g. JSON to OWL representation format) must be performed.
An overview of the proposed “Smart Proxy” implementation of the SSGF that implements this
transformation step and also the ontology alignment of two individual entities (in this case, of a
smart entity and of a control entity) is depicted in Figure 1. An “ontology wizard” component is
responsible for transforming IoT device’s and application’s messages that are exchanged
between each other or via a gateway (e.g. ThereGate) from JSON or XML or URI format to
ontological definitions of OWL classes and properties, as well as to refine those sets using some
heuristic rules (e.g. to handle structural issues). The two sets of ontology definitions, one set for
the device and one for the application, are then processed by the “ontology alignment”
component in order to obtain their similarities and compute alignments between them. These
alignments (computed at the deployment time) are then used by a “message translator”
component at run-time for a bi-directional translation of messages.
The SSGF implementation has been preliminarily evaluated and there are still some open
issues that need to be treated in future work. Such issues are related to the degree and state of
human involvement for the refinement of learned ontological definitions and the validation of the
computed alignments.
Figure 1. The “Smart Proxy” implementation of the proposed SSGF
The Semantic Registry
A formal and explicit representation of all types of IoT entities and their associations is
required in order to serve as the semantic registry of the related to the above scenario real-world
instances. Such an abstraction technology is needed in order to a) abstract (hide) the
technological heterogeneity that derives from the vast amount of heterogeneous IoT entities, b)
abstract (hide) the semantic heterogeneity that derives from the use of heterogeneous domain
ontologies to semantically annotate the data of those IoT entities.
The abstract world of our scenario includes (but not limited to) the abstract entities
presented in Table 3, organized according to the different levels of the physical world that we
have identified. Examples from the scenario are provided for each level of the IoT abstract-world
entities.
Table 3. Abstract world: IoT abstract entities and example instantiations from the scenario
IoT entities
Smart entities (SE)
abstracting Mary’s
physical world
Control entities (CE)
abstracting IoT
application/service
Example Instantiations
a.
b.
c.
d.
e.
a.
A-SE_1 actuator-smart entity: switch actuator associated with a lamp
A-SE_2 actuator-smart entity: switch actuator associated with an air-condition
S-SE_1 sensor-smart entity: motion detection sensor associated with Mary's living room
S-SE_2 sensor-smart entity: temperature sensor associated with Mary’s living room)
S-SE _3 sensor-smart entity: sunlight sensor associated with Mary’s living room)
CE_1 control entity: abstraction of a simple smart home application for monitoring light
in a room based on movement detection. Example application logic: IF motion is
detected in Mary’s living room THEN light switch actuator switches on the lamp. The
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
providers’ physical
world)
CE is instantiated based on the application logic.
b. CE_2 control entity: abstraction of a simple smart home application for monitoring room
temperature via smart phone app. Example application logic: IF temperature is higher
than 30 degrees Celsius in Mary’s living room THEN air condition switch actuator acts
on LG air condition, setting the power on. The CE is instantiated based on the
application logic.
The ontology’s individual objectives are outlined in the following list:
support the semantic registration of heterogeneous IoT entities offered by infrastructure
or application/service providers and used by application/service consumers
support the alignment of semantic descriptions of registered IoT entities (by representing
the alignment input i.e. smart and control entities, and the alignment output i.e. aligned
entities in the form of subclass axioms between them)
support the matchmaking of registered IoT entities based on the discovered alignments
(by executing proper SPARQL queries on the updated with the alignments ontology)
support the alignment of communication messages between matched IoT entities (by
representing the alignment input i.e. example IoT entities’ communication message
templates, and the alignment output i.e. aligned data descriptions of communication
messages stored as instances of mapping cells of the related ontology alignments)
Based on the abovementioned objectives, the ontology’s high-level requirements are
outlined in the following paragraphs.
Requirement 1: An IoT ontology must represent any IoT physical entity that needs to be
registered, managed and involved in the deployment of IoT applications. The IoT physical
entities include (but not limited to) the following:
1. Hardware entities
a. Sensing devices, actuating devices, identity devices, embedded devices
b. Physical entities/features of interest to be observed or to be changed (change their
state by acting on them) e.g. home appliances, food products, transportation
media, building spaces, etc.
2. Software entities
a. Applications
b. Software agents
c. Services
Requirement 2: An IoT ontology must represent high-level IoT entities as abstractions of
physical entities’ associations. The IoT high-level entities include the following:
1. Smart entities: an abstract representation of an association between
a. Sensing or actuating or embedded or identity devices
b. Features of interest that they are related to
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
c. Software agents that are responsible for the entity’s conceptualization (domain
ontology) and for entity’s functionality (provided as a service).
2. Control entities: an abstract representation of an association between
a. Applications
b. Features of interest that they are related to
c. Software agents that are responsible for the entity’s conceptualization (domain
ontology) and for entity’s functionality (provided as a service).
Requirement 3: An IoT ontology must facilitate the representation of ontology alignmentrelated information, as this is captured in the two distinct alignment tasks:
1. Alignments between IoT entities, based on the semantic descriptions of input/output
parameters that application developers (for control entities) and end-users (for smart
entities) provide.
2. Alignments between semantic descriptions of communication messages between matched
IoT entities, based on the semantic description that application developers (for control
entities) and device vendors (for sensing/actuating/identity/embedded devices) provide.
The proposed ontology is engineered using a layered approach (Figure 2).
Conceptualizations related to sensing and observations were reused from the SSN ontology (ssn
prefix) and high-level generic ones from the DUL ontology (dul prefix). On the limitation of
existing ontologies to fully meet the requirements for the proposed IoT-ontology, the paper
introduces the definition of new concepts and properties a) for the representation of higher-level
entities of the IoT world i.e. smart entities and control entities, as associations between physical
entities (sensing/actuating/embedded/identity devices, features of interest, software agents,
applications and services), and b) for the representation of IoT entities’ alignment information.
For these new concepts/properties, we introduce two additional layers in the IoT-ontology, i.e.
the IoT entities layer and the IoT entities’ alignment layer. The iot prefix will be used for the IoT
entities layer of the proposed IoT-ontology namespace. Last but not least, the align prefix for the
namespace will be used for the IoT entities’ alignment layer.
Figure 2. IoT-ontology layers, indicating dependencies of different
namespaces
In respect to the SSN ontology, our work can be viewed as an extension to it, by adding
two new ontology layers (Figure 2) to support the requirements for an IoT-ontology as these are
identified in this paper: the layer for representing IoT entities (IoT entities layer) and the layer
for representing IoT entities’ alignments (IoT entities alignment layer). Nevertheless, the
proposed ontology extends the type of devices associated with different features of interest and
goes beyond the notion of a sensing device i.e. adds the notions of actuating, identity and
embedded devices. In addition, it introduces the notion of related services (actuating, observation
and identity communication services) that are provided by associated software agents.
IoT entities layer
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
iot:IoT_Entity
The highest (top-level) concept of the IoT entities layer is the concept iot:IoT_Entity
(Figure 3), specified as an Internet of Things entity that has a distinct, separate situation,
existence or view and is consistent with ('satisfying') a description on a set of entities. It is a
subclass of ssn:Situation (a social object that satisfies some description) and of
ssn:FeatureOfInterest (a relation between an observation and the entity whose quality was
observed) restriction to some dul:PhysicalObject (any object that has a proper space region).
Furthermore, an IoT_entity is conceptualized by a software agent via an ontology, and this is
defined as a property dul:isConceptualizedBy with restriction to some iot:SoftwareAgent that
dul:conceptualizes some iot:Ontology and iot:providesService some iot:Service. The
iot:SmartEntity and iot:ControlEntity are direct subclasses of iot:IoT_Entity.
Figure 3. IoT_Entity definition in Protégé 4.2 notation showing the asserted
and inherited axioms (as classes) in separate panes
Since, ssn:Situation and dul:PhysicalObject are defined in the imported namespaces (ssn
and dul respectively), we do not present here their definition in detail. In this paper we present
the definitions only for classes/properties defined in iot and align namespace.
iot:SmartEntity
An iot:SmartEntity (Figure 4) is an iot:IoT_Entity that represents the association between
exactly one dul:PhysicalObject observed and some other objects (dul:includesObject) such as an
ssn:Sensor, an iot:Actuator, an iot:EmbeddedDevice, or an iot:Identifier. The observation is
represented using the ssn:featureOfInterest property restriction to dul:PhysicalObject i.e. a
relation between an observation and the entity whose quality was observed e.g. in an observation
of the weight of a person, the feature of interest is the person and the quality is weight. An
iot:SmartEntity has an (inherited) property dul:isConceptualizedBy with restriction to some
iot:SoftwareAgent that dul:conceptualizes some iot:Ontology and iot:providesService some
iot:Service.
Figure 4. SmartEntity definition in Protégé 4.2 notation
iot:ControlEntity
An iot:ControlEntity (Figure 5) is an iot:IoT_Entity that represents some control
behavior/application logic. An iot:ControlEntity instance will to be matched to one or more
instances of an iot:SmartEntity in order to achieve a specific application domain goal e.g. to
monitor and adjust temperature in a room based on the sensed data. An iot:ControlEntity has an
(inherited) property dul:isConceptualizedBy with restriction to some iot:Application (which is
subclass of iot:SoftwareAgent) that dul:conceptualizes some iot:Ontology and
iot:providesService some iot:Service.
Figure 5. ControlEntity definition in Protégé 4.2 notation
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
Due to paper length limitations, the rest classes/properties of the IoT entities layer can be
viewed in N3/Turtle notation in the example presented in the evaluation section of this paper and
also in the OWL implementation of the proposed ontology at
https://dl.dropbox.com/u/1311500/IoT-Ontology/IoT-Ontology.zip and at http://purl.org/IoT/iot.
A hierarchical view of the classes of all layers is also provided in the Appendix A.
IoT entities’ alignment level
As already stated, the key for true interoperability of IoT entities towards their automated
deployment is to support their alignment and matchmaking of their data semantics (at
deployment time). This must be done with minimum human involvement at expert’s side i.e. at
the SIaaS providers side, and with minimum human involvement at non-experts end-users’ side
i.e. at the IoT services/applications consuming point (e.g. at Mary’s house). The goal here is to
compute and store alignments in such a consistent and formal way that they could be utilized
later on for the communication of the IoT entities (at runtime). The IoT-ontology considers the
representation of ontology alignments in the way presented in the following paragraphs.
iot:OntologyAlignment
An iot:OntologyAlignment (Figure 6) is a dul:Description for representing ontology
alignments via iot:aligns restriction on exactly two instances of an iot:Ontology. It
iot:hasAlignmentCell restriction on zero or more instances of an iot:AlignmentCell. IoT entities
are linked to their ontology alignments via the iot:Ontology class of the iot:aligns property
restriction.
Figure 6. OntologyAlignment definition in Protégé 4.2 notation
align:AlignmentCell
Based on the ODP initiative design pattern for alignments (Janowicz & Compton, 2010)
and on the Alignment API (David, Euzenat, Scharffe & Trojahn, 2011), an
iot:OntologyAlignment has zero or more instances of an iot:AlignmentCell (Figure 7). An
iot:AlignmentCell is a dul:Description and a align:Cell, representing the structure and type of an
alignment cell between an align:entity1 and an align:entity2 (i.e. ontology classes or properties).
It also represents the correspondence (align:relation) that holds between them (i.e. equivalence,
subsumption, etc), and the measurement (align:measure) of the confidence value (in the interval
[0,1]) of this correspondence.
Figure 7. AlignmentCell definition in Protégé 4.2 notation
Methodological issues
The engineering of the proposed IoT-ontology follows an evolutionary and open
development process, towards the definition of a set of shared and community-agreed
representational primitives with which to model the IoT domain of knowledge (Gruber, 2009).
Based on the requirements gathered in the context of latest IoT-related research projects and
motivated by key challenges reported in latest related research reports/papers, mostly from the
SSN and IoT community, the main methodological decision is to reuse and extend existing
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
conceptualizations and ODP patterns, and at the same time to improvise new ones towards
supporting the aim and scope of the proposed ontology. Due to received (and expected) feedback
from members of the SW and IoT community, a versioning strategy is also considered. Finally,
the evaluation of each ontology version, in addition to the argumentation-based evaluation
process, as proposed by HCOME OE methodology (Kotis, Papasalouros, Vouros, Pappas, &
Zoumpatianos, 2011), is currently performed by experimentally using instantiated versions of the
ontology with a proof-of-concept prototype of early IoT-SSGF implementations (Smart Proxy
toolset).
Implementation & Evaluation
Semantic Registration and Matchmaking
We have used Protégé 4.2 Alpha and HermiT 1.3.6 reasoning engine to formalize
conceptualizations and check inconsistencies of the proposed ontology. We have also used
OpenRDF Sesame 2.6 as a semantic data store, for the instantiation and querying of example
individuals. For the IoT-SSGF implementation, we have developed custom Java tools that
support a) the transformation of JSON/XML/URI messages to OWL, b) the automated alignment
and matchmaking of OWL specifications (concepts/properties), and c) the bi-directional
translation of IoT entities’ messages using pre-computed alignments.
The presented OWL version (v2.1) of the developed ontology reuses ssn, dul and align
namespaces. A zip file with the related .owl files can be retrieved from
https://dl.dropbox.com/u/1311500/IoT-Ontology/IoT-Ontology.zip and http://purl.org/IoT/iot.
In the N3/Turtle example use of the ontology provided below, for the sake of brevity,
only the most relevant properties for IoT entities’ registration are presented.
Let a physical object of interest, a lamp, be registered (by the end-user) in the repository
as:
:Lamp a dul:DesignedArtifact, :LampType .
:LampType a owl:Class; rdfs:label "Light"@en .
The label “Light” was provided by a human (the end-user of IoT application and
infrastructure owner, e.g. Mary) as a free-form annotation of the class of the object.
Let then an actuating device, the remote-controlled electrical socket, be registered as:
:Switch a iot:Actuator, iot:ActuatingDevice.
and the association of the lamp and the device (lamp is plugged into and thus controlled
through the socket) is expressed as a smart lamp entity:
:SmartLamp a iot:SmartEntity;
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
ssn:featureOfInterest :Lamp;
dul:includesObject :Switch.
The service provided by :SmartLamp, the :LightSwitchService, is also registered in the
repository but is omitted here.
Another smart entity, i.e. a smart room entity is described below. Its feature of interest is
a room:
:E023 a iot:Room .
The sensing device associated with this physical entity is a motion detector:
:MotionDetector a ssn:Sensor, ssn:SensingDevice .
The smart room entity is registered in the ontology as follows:
:SmartRoom a iot:SmartEntity;
ssn:featureOfInterest :E023;
dul:includesObject :MotionDetector;
dul:isConceptualizedBy [
a iot:SoftwareAgent;
iot:providesService :DetectionService
].
The service provided by this smart entity through its associated software agent is
registered as follows (only the output’s description is given here for simplicity):
:DetectionService a iot:Service;
ssn:hasOutput [
a iot:InformMessage;
dul:expresses [ a : MotionDetectorSignalType ];
dul:isRealizedBy [
a iot:CommunicationMessage;
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
rdfs:label "MotionDetectorSignal";
iot:hasTemplate "{'list': [ { 'timeStamp': 1333450241.736228, 'signal':
'PropertiesChanged', 'data': { 'MotionDetected': true }, 'IDeviceId': 23 } ], 'until':
1333450241.741899, 'tobj': 'signals' }"
]
];
iot:hasAccessAddress
<http://192.168.50.1/api/signals/listen?ids=23> .
:MotionDetectorSignalType a owl:Class;
rdfs:subClassOf ssn:Property;
rdfs:label "Motion"@en.
The label “Motion” was also provided by a human (the end-user of IoT application and
infrastructure owner, e.g. Mary) as a free-form annotation of the type of information expressed
by the output of the above service.
Now let us assume that a generic application has been developed, implementing the
function “switch a light when a movement is detected in the room”. This application will be
registered in the ontology (by the IoT service provider and application developer) as an
application that provides some light service and conceptualizes a control entity:
:Control a iot:ControlEntity;
dul:isConceptualizedBy :Application .
:Application a iot:Application;
iot:providesService :LightService .
The instantiation of the specific service that the IoT service provider (application
developer) provides is described as follows:
:LightService a iot:Service;
ssn:hasOutput [
a iot:QueryMessage;
dul:isRealizedBy [
a iot:CommunicationMessage;
rdfs:label "Monitor";
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
iot:hasTemplate "token=X"
];
iot:hasTarget "?entity ssn:featureOfInterest [a iot:Room]; dul:isConceptualizedBy
[iot:providesService ?this]. ?this ssn:hasOutput [dul:expresses [ a
<http://www.vtt.fi/IoT/test/app1#HasMovement> ] ]"
];
ssn:hasInput [
a iot:InformMessage;
dul:isRealizedBy [
a iot:CommunicationMessage;
rdfs:label "MovementDetectorResponse";
iot:hasTemplate "<event><type>movement</type><value>false</value></event>"
]
];
ssn:hasOutput [
a iot:CommandMessage;
dul:isRealizedBy [
a iot:CommunicationMessage;
rdfs:label "Switch";
iot:hasTemplate
"<command><type>switch</type><value>1</value><token>X</token></command>"
];
iot:hasTarget "?entity ssn:featureOfInterest [a
<http://www.vtt.fi/IoT/test/app1#LightingDevice>]; dul:isConceptualizedBy
[iot:providesService ?this]"
].
Additionally, the custom classes used in iot:hasTarget SPARQL patterns have to be
defined along with the application registration:
app1:HasMovement a owl:Class;
rdfs:label "HasMovement"@en.
app1:LightingDevice a owl:Class;
rdfs:label "LightingDevice"@en.
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
The Smart Proxy toolset utilizes the abovementioned registrations using the following
steps in order:
1. Apply the ontology alignment task on the registrations as a whole, aligning classes
:LampType (label “Light”) and :MotionDetectorSignalType (label “Motion”) with
app1:LightingDevice and app1:HasMovement, correspondingly. Such alignments are
stored in the ontology using subclass axioms, e.g. :LampType rdfs:subClassOf
app1:LightingDevice.
2. Perform the matchmaking between the registered application and the smart entities by
executing patterns of the iot:hasTarget-related SPARQL queries. For “Monitor” query,
the pattern uses IoT-ontology to define the application’s requirements for a sensing
service that expresses a “hasMovement” property of a room. For the “Switch” command,
the pattern express the application’s requirement for an actuating service provided by a
smart entity associated with a “LightingDevice” feature of interest. Although these
patterns are simple for presentation issues, they can be made as complex as needed within
the borders of expressivity power of the IoT-ontology. The alignment performed in step 1
will ensure that the results are properly returned. Variable “?this” will contain in each
case the service sought for.
3. Process the message data format examples given with iot:hasTemplate for both the smart
entities’ services and the control entity’s application. This is done by first generating an
OWL-based ontology representation for given JSON or XML and then applying the
ontology alignment toolset on those. As a result, “MotionDetected” attribute in
:DetectionService’s JSON output will get mapped with the “value“ XML tag in the
application :LightService’s MovementDetectorResponse input. Similarly, all other
patterns defined with the application and smart entity registrations are aligned. Such
alignments are stored into the repository simply as values of the properties of
iot:AlignmentCell class (align layer).
In Figure 8 we depict a snapshot of the IoT-ontology and example domain ontologies’
metadata and data generated with the presented scenario and the proof-of-concept
implementation.
Figure 8. Example snapshot graph of IoT entities’ metadata and data,
showing also the link between the IoT ontology from the domain ontologies
needed to describe domain-specific data.
Ontology Alignment tools
The problem of computing alignments between ontologies can be formally described as
follows: Given two ontologies O1 = (S1, A1), O2 = (S2, A2) (where Si denotes the signature and Ai
the set of axioms that specify the intended meaning of terms in Si) and an element (class or
property) Ei1 in the signature S1 of O1, locate a corresponding element Ej2 in S2, such that a
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
mapping relation (Ei1, Ej2, r) holds between them. r can be any relation such as the equivalence
) or the subsumption ( ) axiom or any other semantic relation e.g. meronym. For any such
correspondence a mapping method may relate a value that represents the preference to relating
Ei1 with Ej2 via r. If there is not such a preference, we assume that the method equally prefers any
such assessed relation for the element E1. The correspondence is denoted by (Ei1, Ej2, r, ). The
set of computed mapping relations produces the mapping function f:S1 S2 that must preserve
the semantics of representation: i.e. all models of axioms A2 must be models of the translated A1
axioms: i.e. A2 f(A1).
In the context of SSGF and Smart Proxy implementation, we have developed two
experimental ontology alignment tools: AUTOMSv2 (Automating the Synthesis of Ontology
Mapping Methods) and ASE (Aligning Smart Entities).
AUTOMSv2 (Kotis, Katasonov & Leino, 2012) is an automated ontology alignment tool
based on its early version (AUTOMS) in 2006. It computes 1:1 (one to one) alignments of two
input domain ontologies in OWL, discovering equivalences between ontology elements, both
classes and properties. The features that this new version integrates are summarized in the
following points:
It is implemented with the widely used open source Java Alignment API
It synthesizes alignment methods at various levels and types (lexical, structural, instancebased, vector-based, lexicon-based) with the capability to aggregate their alignments
using different aggregation operators (union, Pythagorean means)
It implements an alignment-methods’ configuration strategy based on ontology profiling
information (size, features, etc.)
It integrates state-of-the-art alignment methods with standard Alignment API methods
Implements a language translation method for non-English ontology elements
On the other hand, ASE tool is based on experience gained by the development of
AUTOMSv2. The development process of this tool has been driven by our motivation to use the
ontology alignment functionality as part of the Smart Proxy approach for the matchmaking of
IoT entities. More specifically, ASE supports the automated deployment of applications on
environments that IoT devices (sensors and actuators) have been already deployed. It computes
1:1 (one to one) alignments of two input domain ontologies in OWL, discovering equivalence
and subsumption axioms between ontology elements, both classes and properties. The features
that this tool integrates are summarized in the following points:
It is implemented with the widely used open source Java Alignment API
It synthesizes lexical and lexicon-based alignment methods, using union aggregation
operator
It integrates state-of-the-art alignment methods with standard and extended methods from
the Java Alignment API
Implements a language translation method for non-English ontology elements
Comparing with AUTOMSv2, in ASE
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
We do not implement a profiling and configuration strategy, but instead we use a fixed
synthesis method based on experience and observation of AUTOMSv2 behavior and also
on specific performance requirements that the application domain of IoT and the specific
Smart Proxy approach have been implied,
We implement the discovery of subsumption relations between concept/property pairs, in
addition to equivalences,
We implement a new method for translating Non-English ontologies, a method that is
based on the Microsoft Bing Translator API
We implement some utility functions for handling compound terms
ASE can be seen as a subversion of AUTOMSv2 ontology alignment tool, in the sense
that it uses a specific synthesis configuration strategy of AUTOMSv2 alignment methods. The
synthesis of alignment methods that exploit different types of information may discover different
types of relations between elements have been already proved to be of great benefit (Euzenat,
Meilicke, Stuckenschmidt, Shvaiko, & Trojahn, 2011; Kotis & Lanzenberger, 2008; Shvaiko &
Euzenat, 2012). ASE configuration is based on the requirement that the related input ontology
definitions in the application domain that this tool is used are very often flat (no structure), have
no instances (unpopulated), have very few concepts/properties (1 to 5 in most cases), have no
expressive axioms, and compound terms are very common.
In ASE we follow a modern synthesis strategy, which performs composition of results at
different levels: the resulted alignments of individual methods are combined using specific
operators, e.g. by taking the union of results. Given a set of k alignment methods (e.g. stringbased, WordNet-based), each method computes different confidence values concerning any
assessed relation (E1, E2, r). The synthesis of these k methods aims to compute an alignment of
the input ontologies, with respect to the confidence values of the individual methods. Trimming
of the resulted correspondences in terms of a threshold confidence value is also performed for
optimization.
The alignment algorithm followed in this work is outlined in the following steps:
Step 0: If non-English names of labels of entities are detected, translate input ontology
into an English-language copy of it.
Step 1: For each integrated alignment method k compute correspondence (E i1, Ej2, r, )
between elements of the two domain ontologies.
Step 3: Apply trimming process by allowing agents to change a variable threshold value
(of ) for each alignments set Sk or for the alignments of a synthesized method
Step 4: Apply synthesis of methods at different levels (currently using union aggregation
operator) to the resulted set of alignments Sk .
Consider two alignment methods (Figure 9), m and m', also called matchers, that are
selected based on a fixed synthesis configuration method and used for aligning two input
ontologies o and o´. In case of translation needed, this is performed before entering m and m´
respectively. The resulting alignments are aggregated/merged in a, using an aggregation operator
(union is the current one used), resulting in another alignment A´´´ which will be improved by
another alignment method m'' resulting to the final alignment A´´´´.
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
Figure 9. General description of the ontology alignment process, extended
with the profiling and configuration functionality
ASE and AUTOMSv2 tools have been extensively evaluated in the OAEI 2011.5 and
OAEI 2012 contests/campaigns and results can be obtained from the related web pages and
workshop papers (http://oaei.ontologymatching.org/). We conjecture that although our aim was
not to compete with other tools in the context of these contests, we managed to obtain above
average results for both implementations. However, we plan to improve the precision and recall
scores of our alignment methods by further evaluation and testing tasks and also by developing a
custom evaluation dataset (with ontologies that conform to the requirements of the IoT domain).
In addition, since our tools were not able to fully compute alignments for all large ontologies in
OAEI datasets, we plan to elaborate on a more scalable ontology matching approach in terms of
both the size of input ontologies as well as the number of them i.e. beyond 1:1 mapping (Sellami,
Benharkat & Amghar, 2012).
Concluding Remarks
This paper has presented the IoT-ontology and Smart Proxy toolset towards realizing the
Semantic Smart Gateway Framework. Specifically, the paper presents several tasks of a semantic
interoperability approach for the automated deployment process of generic IoT applications in
environments where heterogeneous IoT devices have been previously deployed. The paper
presented a scenario to support the need for a semantic registry for IoT entities in order to a)
abstract (hide) their technological heterogeneity, b) abstract (hide) the semantic heterogeneity
that derives from the use of heterogeneous domain ontologies to semantically annotate the data
of those IoT entities.
The work reported in this paper is particularly motivated by our vision of an open and
interoperable IoT, where the ultimate goal is to allow any IoT application/service provider to
develop applications that are generic in the sense of running on various IoT device sets (different
vendors, same purpose), contrasted to developing applications for very particular configurations
or types of devices. The paper has shown that existing semantic technologies do not fully cover
the aim, objectives and scope of the proposed approach, and furthermore, they partially integrate
the required conceptualizations. Based on that, the engineered IoT-ontology reuses widely
accepted and agreed conceptualizations from SSN and DUL ontologies, integrating open
ontology design patterns from the ODP initiative, and at the same time it introduces new ones. In
addition to the description of the conceptualizations of the IoT-ontology, the paper presents an
evaluation of the latest version of the devised ontology, based on a motivating scenario, using an
OWL implementation and a proof-of-concept Java implementation of the IoT-SSGF i.e. the
Smart Proxy toolset for the registration, alignment, matchmaking and querying of heterogeneous
IoT entities.
Future work includes a more elaborated version of the IoT-ontology, a modularization
effort, and verification of its alignment with SSN and DUL. It also includes the investigation of
further engineering requirements of the IoT-ontology in order to support (if needed) the
representation of more complex (composite) IoT entities. Last but not least, a full documentation
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
and detailed report of the proposed ontology will be included in the near future. In terms of the
Smart Proxy implementation of the SSGF approach, future plans include the improvement of the
ontology alignment wizard and alignment tools in terms of heuristics used and precision/ recall
scores obtained, and the experimentation with additional, larger and domain-specific sets of IoT
devices and applications.
Acknowledgements
Authors acknowledge that part of the work presented in this paper has been driven by
requirements that have been specified in the following projects: Internet of Things (TEKES
Finnish project) and iCore (287708 - FP7 Integrated Project). We also thank several anonymous
and eponymous contributors during the argumentation-based ontology evaluation process as well
as the reviewers that provided valuable comments in previous reviews of this content.
References
Barnaghi, P., (2010). Final SENSEI Architecture Framework (Deliverable 3.6), FP7: SENSEI (http://www.senseiproject.eu/).
Barnaghi, P., Compton, M., & Corcho, O., Castro, R., G., Graybeal, J., Herzog, A., Janowicz, K., Neuhaus, H.,
Nikolov, A., & Page K., (2011). Semantic Sensor Network XG Final Report, W3C Incubator Group Report 28 June
2011, Semantic Sensor Network Incubator Group, Laurent Lefort, Cory Henson, Kerry Taylor (eds), Retrieved
October 29, 2012, http://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/.
Calbimonte, J., Jeung, H., Corcho, O., & Aberer, K. (2011). Semantic Sensor Data Search in a Large-Scale
Federated Sensor Network. In Kerry Taylor, Arun Ayyagari, David De Roure (eds), 4th International Workshop on
Semantic Sensor Networks (SSN11): Vol-839 (pp. 23-38), CEUR Workshop Proceedings (CEUR-WS.org)
Christophe, B., Verdot, V., & Toubiana, V. (2011). Searching the 'Web of Things', In Fifth IEEE International
Conference on Semantic Computing (pp. 308 – 315), IEEE Computer Society Press.
Corcho O., & Garcia-Castro, R., (2010). Five Challenges for the Semantic Sensor Web. International journal of
Semantic Web - Interoperability, Usability, Applicability, 1(1), 121-125
Cudré-Mauroux, P., Suchit, A., & Karl, A. (2007). GridVine: An Infrastructure for Peer Information Management
and Large-Scale Collaboration, IEEE Internet Computing, 11(5), 36-44
David, J., Euzenat, J., Scharffe, F., & Trojahn dos Santos C., (2011). The Alignment API 4.0. Semantic Web Interoperability, Usability, Applicability, 2(1), 3-10.
Eisenhauer, M., Rosengren, P., & Antolin, P., (2009). A development platform for integrating wireless devices and
sensors into Ambient Intelligence systems. In 6th Annual IEEE Communications Society Conference on Sensor,
Mesh and Ad Hoc Communications and Networks Workshops, SECON Workshops '09: (pp. 1-9), IEEE Computer
Society Press.
Euzenat, J., Meilicke, C., Stuckenschmidt, H., Shvaiko, P., & Trojahn, C., (2011). Ontology Alignment Evaluation
Initiative: six years of experience. Journal of Data Semantics, 15, 158-192
Graube M., Pfeffer, J., Ziegler, J., & Urbas, L., (2012). International Journal of Distributed Systems and
Technologies, 3(3), 40-52
Gray, A.J.G., García-Castro, R., Kyzirakos, K., Karpathiotakis, M., Calbimonte, J.P., Page, K., Sadler, J., Frazer, A.,
Galpin, I., Fernandes, A., Paton, N.W., Corcho, O., Koubarakis, M., De Roure, D., Martinez, K., & Gómez-Pérez,
A., (2011). A Semantically Enabled Service Architecture for Mashups over Streaming and Stored Data. In 8th
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
extended semantic web conference on the Semantic Web: research and applications - Volume Part II, Vol-6643 (pp.
300-314), LNCS Springer-Verlag.
Gruber, T., (2009). Ontology. In Ling Liu and M. Tamer Özsu (Eds.): Encyclopedia of Database Systems, SpringerVerlag
Guinard, D., Trifa, V., & Wilde, E. (2010). Architecting a Mashable Open World Wide Web of Things, (Tech. Rep.
No. 663), Department of Computer Science, ETH Zurich.
Hachem, S., Teixeira, T., & Issarny, V., (2011). Ontologies for the Internet of Things, In ACM/IFIP/USENIX 12th
International Middleware Conference, Springer
Honkola, J., Tyrkkö, O., Laine, H., Lappeteläinen, A., Luukkala, V., Pantsar-Syväniemi, S., Ovaska, E., Eteläperä,
M., Kiljander, J., Bellavista, P., Toninelli, A., Montanari, R., Manzaroli, D., Zamagni, G., Cinotti, T., Scipioni, S.,
Azzoni, P., Luccaroni, C., Laura, G., Pucci, P., Corongiu, A., Ozcelebi, T., & Bhardwaj, S., (2010). Architecture for
Sofia Interoperability Platform (Deliverable 5.21), ARTEMIS JU SP3 / 100017: Smart Objects for Intelligent
Applications (SOFIA).
Janowicz K. & Compton, M., (2010). The Stimulus-Sensor-Observation Ontology Design Pattern and its Integration
into the Semantic Sensor Network Ontology. In Kerry Taylor, Arun Ayyagari, David De Roure (eds), 3rd
International Workshop on Semantic Sensor Networks (SSN12): Vol-668 (pp. xx-xx), CEUR Workshop
Proceedings (CEUR-WS.org)
Kotis, K., & Katasonov, A. (2012). Semantic Interoperability on the Web of Things: The Smart Gateway
Framework. In Leonard Barolli, Fatos Xhafa, Salvatore Vitabile, and Minoru Uehara (eds), Sixth International
Conference on Complex, Intelligent, and Software Intensive Systems 2012 (pp. 630-635), IEEE Computer Society
Press.
Kotis, K., & Lanzenberger, M., (2008). Ontology Matching: Current Status, Dilemmas and Future Challenges. In
Complex, Intelligent and Software Intensive Systems, 2008, (pp. 924-927), IEEE Computer Society Press.
Kotis, K., Katasonov, A., Leino, J., (2012). Aligning Smart and Control Entities in IoT. In S. Balandin et al. (Eds.):
12th International Conference NEW2AN 2012 and 5th Conference on Internet of Things and Smart Spaces,
ruSMART 2012, Vol-7469, (pp. 39-50), Springer LNCS.
Kotis, K., Papasalouros, A., Vouros, G. A., Pappas, N., & Zoumpatianos, K., (2011). Enhancing the Collective
Knowledge for the Engineering of Ontologies in Open and Socially Constructed Learning Spaces. Journal of
Universal Computer Science, 17(12), 1710-1742
Nettsträter, A. (2012). Internet of Things Architecture (IoT-A) project, Deliverable D1.3 - Architectural Reference
Model for the IoT.
Sabou, M., (2010). Smart Objects: Challenges for Semantic Web Research. Semantic Web - Interoperability,
Usability, Applicability, 1(1), 1-5.
Sellami, S., Benharkat, A., & Amghar, Y. (2010). Towards a More Scalable Schema Matching: A Novel Approach.
International Journal of Distributed Systems and Technologies (IJDST), 1(1), 17–39.
Shvaiko, P., & Euzenat, J., (2012). Ontology matching: state of the art and future challenges. IEEE Transactions on
Knowledge and Data Engineering, PP(99), 1–20.
Spiliopoulos, V., & Vouros, G. A., (2012) Synthesizing Ontology Alignment Methods Using the Max-Sum
Algorithm, IEEE Transactions on Knowledge and Data Engineering, 24(5), 940 – 951.
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
International Journal of Distributed Systems and Technologies, x(x), x-x,
APPENDIX A
Overview of the IoT-ontology class hierarchy – some classes from imported namespaces
are also depicted to support proper visualization of the hierarchy. Iot and align namespace
classes are double-circled and on the right side of the vertical line that devices the depicted
hierarchy.
Figure AppendixA
Copyright © xxxx, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is
prohibited.
View publication stats