Semantic Interoperability on the Internet of Things

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