Suparna De; Yuchao Zhou; Klaus Moessner Institute for Communication Systems (ICS), Department of Electrical and Electronic Engineering, University of Surrey, Surrey, United Kingdom
The Web of Things (WoT) paradigm enables access to physical world things and their data through standard Web protocols. This provides interoperability at the hardware and communication protocol level, but does not add intelligence to the things or facilitate unambiguous interpretation of their data. The evolution of the WoT towards the semantic WoT offers the promise of meeting the interoperability challenge through the use of semantic Web technologies. The W3C Web of Things initiative encourages the use of common vocabularies to ensure interoperability and a common understanding of the domain knowledge. Ontologies provide a structured, common formalism to the disparate elements of the WoT and can form the basis of a common knowledge base. The research community and standardisation bodies have developed numerous ontologies describing the elements of the WoT and associated domains. A comprehensive review of the various proposed ontologies is needed to facilitate the adoption and reuse of the available models. This survey reviews the current state-of-the-art in WoT ontologies, which are presented from two perspectives: cross-domain ontologies which are classified into device, service, data and localisation models, and domain ontologies, which are presented from an environmental and user-oriented perspective.
Ontology; Web of Things; Context modeling survey; Device and service ontology; Smart home model; Smart city
This work is supported by the collaborative European Union and Ministry of Internal Affairs and Communication (MIC), Japan, Research and Innovation action, iKaaS under EU Grant number 643262. The first author also acknowledges funding support from the TagItSmart! collaborative project supported by the European Horizon 2020 programme, contract number: 688061.
The Internet of Things (IoT) is envisaged to impact significantly the lives of citizens and offer new business opportunities through digital innovation in the integration of the physical and digital worlds. The first step in the IoT vision has been interconnectivity between physical world objects. The main drivers for further IoT development are enabling things-to-things communications and integration of things data with applications to lead the way towards context-aware solutions and smart cyber-physical systems. This has led to the next step of connecting things to the Web; leading to the emergence of the Web of Things (WoT). The WoT principles are not limited to Web access, but extend to “Web Linking for resource description and discovery, resource directories and security” [29], through Internet Engineering Task Force (IETF) protocols such as Constrained Application Protocol (CoAP) [52] and lightweight HTTP implementations. The WoT enables interaction of things and systems through Application Programming Interfaces (APIs) exposing things data and metadata. However, true integration is hampered by the fact that “many devices do not speak the same language and cannot exchange data across different gateways and smart hubs” [53]. To illustrate, the data generated by things about their ambient environment may have a defined structure in a known format (e.g. JSON/CSV/XML), but the data models and schemas adopted are different and not always compatible. Additionally, they may be represented in different units and include additional information. This leads us to the ‘interoperability’ challenge, which has been recognised by industry alliance bodies such as the Alliance for Internet of Things Innovation (AIOTI)1 and in the European IoT research roadmap [61] as key to achieving “convergence in the long term” [53]. Recent research has led to the unanimous conclusion that semantic technologies can be the driver for integration and interoperability [66,29,39], by enabling the semantic annotation of IoT devices and data. This has been termed as the progression towards a semantic Web of Things (SWoT) in the literature [29], as the basis for achieving a common understanding of the various entities forming part of the IoT. This evolution is recognised as a seamless extension of the IoT towards achieving wide-scale interoperability and a move towards horizontal open systems and platforms that can support multiple applications. A recent report [6] on interoperability for the WoT, by industry and standards experts, highlights the role of semantic interoperability to unlock value across the different domains (such as cities, factories, retail environments etc.) of the WoT.
Specifically, the use of semantic Web-based modelling techniques (RDF models and OWL ontologies) can enable a homogeneous and scalable means to access WoT information. Ontologies can capture the various facets in a common, formalised structure as well as the inter-relationships between the things to form the domain knowledge of the WoT. Semantic interoperability can enable the use of things/objects and data across application domains as well as data exchange across the value chain [53]. However, given the massive scale of the things involved in the IoT, the “creation of a unitary ontology to define all the resources and manage all the aspects related to them seems to be impossible” [39]. The semantic annotations need to capture the capabilities of the heterogeneous objects forming part of the WoT in order to enable their search and discovery, the location of these objects (as part of a set of context features) as well as the information they can provide [61]. This leads to the need for domain specific ontologies. Practitioners also need knowledge of the existence of the various domain specific ontologies and an assessment of the applicability of these towards applications such as search and discovery, data analytics and data fusion in different domains such as smart cities, assisted living, home automation etc. Thus, it becomes quite important to have a clear framework in place that facilitates a clear use of the different available ontologies from a data and context-awareness perspective. In addition to the four ontology design principles of lightweight-ness, completeness, compatibility and modularity as identified in [67], various requirements for the elements to be modelled by WoT specific ontologies have been identified [39,72,29,67]:
• WoT ontologies need to address the representation of not only the thing specific (such as sensors, devices, actuators, smart objects) heterogeneity of the WoT with the necessary level of abstraction, but also capture the distributed environment context in which they operate.
• Since WoT smart objects provide services individually or in cooperation, this also needs to be taken into account.
• The data generated by smart objects needs to be precisely and effectively modelled so that it can be represented, reasoned upon and used to drive higher-level processes such as data manipulation and fusion.
• The semantic representations should facilitate extensible annotations, i.e. from minimal to elaborate descriptions.
• With WoT objects typically being energy-constrained and operating in dynamic environments, capturing the notion of quality of the available services and generated data assumes importance.
• With mobile objects increasingly contributing as data sensors in the WoT, associating the generated data with the location of sensing and the object identity becomes crucial so that the data can be corroborated and combined to generate knowledge about the ambient environment state.
A number of ontologies and context models have been proposed by the research community addressing different parts of the above requirements, leading to a substantive body of ontological models that can be candidates for a wide variety of WoT applications. A survey and analysis of current ontologies is presented in this book chapter. Additionally, we will focus on a definition of a taxonomy to capture the various elements of the WoT as modelled by the various available ontologies. An analysis of the available ontological models in terms of different facets and domain applicability will also be presented through a mix of comparison measures.
The remainder of this chapter is organised as follows: based on the requirements identified above, we developed the taxonomy for the survey of ontology modelling efforts in the WoT in Section 1.2, along with a number of measures for comparing the surveyed ontologies. Sections 1.3–1.4 detail the specific approaches from existing state of the art that propose ontologies that fit into the defined classification model. Where applicable, the ontologies are described in the context of the European research projects within which they were defined. A discussion of the findings and future outlook is presented in Section 1.5, before providing concluding remarks in Section 1.6.
Existing studies surveying WoT ontologies include a survey of existing IoT ontologies and vocabularies along five identified conceptual groups [36] of sensors/actuators; global and local coordinates; communication endpoint; observations, features of interest, units and dimensions; and vendor, version, deployment time. The authors only aim at identifying ontologies that can be used to semantically describe a specific set of real world devices that include a weather station, fan and an electric meter, with the service perspective notably missing as well as ontologies capturing data. Prominent device/sensor, data and service ontologies are listed in [39], whereas [25] discusses ontologies proposed for describing sensors and those covering WoT domains such as smart cities, ambient assisted living (AAL) and generally cyber-physical systems. A review of some of the existing ontology models and their comparison along the aspects of dynamics, concepts modelled, scale and mobility is presented in [70]. However, these approaches are limited by the absence of a classification and comparison scheme and a comprehensive listing of available WoT ontologies. The taxonomy proposed in this book chapter extends the ontology categories outlined in [39], while taking cognizance of the features commented upon in [70].
Existing research on ontologies for the WoT defines models for the various entities forming part of the WoT, viz. devices, services, sensors etc. either in isolation or as part of an interconnected suite of ontologies. In addition, there are ontologies that cover the allied context representation tasks. The taxonomy developed in this chapter considers a two layered approach: cross-domain and domain-specific ontologies, as shown in Fig. 1.1. A similar demarcation is also outlined in the WoT semantic interoperability report [6]. The cross-domain ontologies consist of WoT concepts that are shared across the domains and vertical application silos. These include the core WoT elements as identified in the literature, including things, sensors, services etc. as well as shared concepts related to quantities, units and location. The domain ontologies, on the other hand, relate to specific application domains, such as smart home, ambient assisted living (AAL), etc. and often reference the cross domain ontologies. Moreover, the cross domain ontologies are classified into four perspectives: (1) device models, including smart object or resource models and more specific sensor ontologies, (2) service ontologies, that cover the provision of WoT device functionalities as services, (3) data ontologies, that represent the semantic annotation of both instantaneous and streaming data and (4) localisation ontologies, that capture both indoor and outdoor locations, such as geographical features. The domain ontologies provide the context to the cross domain models. These are classified according to two main perspectives: (1) environment models, that cover home/office/public buildings environment and the agriculture domain and (2) user-oriented ontologies, focussing on user activity recognition, ambient intelligence and WoT-enabled learning scenarios. The developed taxonomy is presented in Fig. 1.2.
To gain a quick while in-depth overview of the various models, we define a number of dimensions against which the existing works can be compared. These are explained as follows:
• Modelled concepts: indicates the elements modelled in the ontology
• Language: specifies the modelling language formalism, e.g. RDF, OWL
• Links to domain ontologies: refers to possible ontology relationships that link to existing third-party ontologies covering different domains such as location, units of measurement for data etc. Referring to existing domain ontologies offers the possibility of having more interconnected device descriptions, by forming Linked Data [8] and thereby contributing to the Web of Data vision
• Notion of quality: with increasing number of mobile sensing units contributing to the data pool of the WoT, including Quality of Service (QoS) and QoI (Quality of Information) attributes in the semantic annotations can help applications to discriminate between WoT services offering similar functionalities
• Application domain: indicates the application domain to which the ontology instantiations have been applied. These may be generic applications such as for sensor search and discovery or refer to the IoT application areas as identified in [62], such as smart health, smart living, smart manufacturing etc.
• Prototype/tool: refers to any applicable proof-of-concept software which makes use of the ontology instantiations
Table 1.1 provides a summary of the surveyed works against the comparison dimensions outlined above. It is evident that most existing approaches define a suite of inter-linked ontologies covering a combination of the device, service and data aspects along with possibly the physical locations that the device inhabits.
Table 1.1
Comparison of WoT Cross-Domain and Domain Ontologies
Ontology | Modelled Concepts | Language | Links to Domain Ontologies | Notion of Quality | Application Domain | Prototype or Tool |
oneM2M Base ontology [42] | Thing, device, service | OWL-DL | – | no | Domain independent | Illustrative mappings defined to SSN and SAREF ontologies |
IoT-A ontology [20] | Entity, resource, service | OWL-DL | DBpedia, FOAF, OWL-S, QUDV, QUDT | no | Associations between objects and services, service composition and search | Sense2Web platform |
Jin et al. [32] | Device, resource, service | OWL | FOAF, GeoNames | no | Quality rating of services, service selection | – |
Chun et al. [15] | Entity, device, resource, service, event | OWL | – | no | Service event recognition | IoT-DS (directory service) |
PT-SOA [74] | Physical thing, Service | OWL | – | no | Emergency rescue | – |
iCore Virtual Object (VO) [34] | VO, ICT, non-ICT objects | OWL | – | yes | VO composition | Ambient Assisted Living demonstrator |
Christophe et al. [14] | VO | OWL | FOAF, GeoNames | no | VO search | – |
VO (Zhou et al.) [71] | VO, O&M data | OWL-DL | WGS84, Geohash | no | O&M data discovery | Web-based GUI for O&M data discovery |
SSN [16] | Sensor, system, observation, feature | OWL-DL | DOLCE-Ultralite | no | Sensing for manufacturing, WoT infrastructures, SWE linked data infrastructure | SPITFIRE FP7 project event model, semantic sensor Web, SemsorGrid4Enva environment management framework |
CSIRO sensor ontology [41] | Sensor deployment, operation | OWL | OWL-S | yes | data integration, search, classification and workflows | – |
OntoSensor [50] | Sensor, capabilities, measures | OWL | IEEE SUMO, ISO 19115, SensorML, GML | no | extended by service oriented sensor data ontology [35] | – |
Semantic Actuator Network (SAN) [56] | actuator | OWL-DL | SSN, QU | no | Earthquake emergency | part of the Earthquake Emergency (EEM) ontology |
Actuator ontology [64] | actuator | OWL | – | no | Actuator discovery and invocation | policy-based home care system |
IoT.est service ontology [67] | Service, test, platform, location, QoS, QoI | OWL-DL | IoT-A entity, resource ontologies, OWL-S, WGS84, CF-features | yes | Sensor service discovery, service composition | – |
Qu et al. [45] | Service, status, location | OWL | OWL-S | no | selection, combination and control of entity services | – |
ForwarDS-IoT service ontology [24] | Sensor, actuator, service | OWL | OWL-S | no | Discovery services | ForwarDS-IoT discovery service |
Linked USDL [60] | Service, business entity | RDF | – | no | Enterprise IT integration | – |
SSD ontology [28] | Service, server profile | OWL | – | no | Automated WoT service deployment | – |
Service oriented sensor data ontology [35] | Sensor service | OWL | OntoSensor, SUMO, GML | no | Service query | – |
IoT-based service integration ontology (IIO) [51] | Service, topic, user | OWL | – | no | Smart office | Integrated Semantic Service Platform |
Wang et al. [65] | Sensor observation data | RDF | DBpedia | no | Reasoning for weather conditions at specific locations | – |
SemSOS O&M-OWL [27] | Sensor O&M data | RDF | – | no | Weather condition reasoning | SemSOS tool |
SensorData [3] | Sensor O&M data | RDF | NASA SWEET | no | – | – |
LinkedSensorData [43] | Sensor O&M data | RDF | GeoNames | no | Weather (hurricane and blizzard observations in the United States) | Semantic Sensor Web application |
Barnaghi et al. [5] | Sensor O&M data | RDF | DBPedia, GeoNames | no | Sensor metadata publication, query | Linked Sensor Data platform (sensor description publication and visualisation) |
LSM [38] | Sensor O&M data | RDF | DBPedia, GeoNames | no | Sensor data discovery | Linked Sensor middleware |
SEEK Extensible Observation Ontology (OBOE) [12] | Sensor O&M data | OWL-DL | – | no | coastal ecosystems | ontology linkb |
Stream Annotation Ontology (SAO) [37] | Sensor O&M data streams | OWL-DL | – | yes | Smart city traffic use case | – |
Barnaghi et al. [4] | Sensor O&M data streams | OWL-DL | DBPedia, GeoNames | no | Sensor data clustering | – |
NASA SWEET | Representation, Process, Phenomena, Matter, Realm, Human Activities, Property, State, Relation | OWL, RDF | – | no | Sensor observations annotation, mobile applications | Projects such as Trickscityc, SemSerGrid4Env |
QUDV | Data, Unit, Scale, Quantity, Dimension | OWL | – | no | Entity, resource attribute annotation References to QUDV instances in IoT-A entity and resource ontology, IoT.est service ontology | – |
QUDT | Unit, Dimension, Quantity | OWL, RDF | – | no | Entity, resource, unit of measurement annotation | Water quality vocabulary [54], IoT-A entity and resource ontology, IoT.est service ontology |
UO | Quality, Unit | OBO, OWL, RDF | part of the Phenotype and Trait Ontology (PATO) frameworkd | no | – | Beta Cell Genomics database, BioAssay Ontology, Electrophysiology Ontology, ISA software suite, Neural Electromagnetic Ontologies |
OM | Unit of Measure, System of Units, Quantity, Measure, Measurement Scale, Dimension | OWL2 | – | no | – | TI Food and Nutritione |
MUO | BaseUnit, ComplexDerivedUnit, DerivedUnit, MetricUnit, PhysicalQuality, Prefix, QualityValue, SIUnit, SimpleDerivedUnit, UnitOfMeasurement | RDF | – | no | – | – |
Indoor location ontology [19] | Indoor locations such as place, premises | OWL-DL | – | no | Associations between physical things and WoT services | – |
Indoor location ontology [63] | Indoor locations in a university campus | OWL-DL | – | no | Sensor service discovery | – |
GeoNames | geographical features | OWL | – | no | Location specification in other ontologies through linked data | – |
CityGML | virtual 3D city model | OWL-DL | – | no | City level location specification in other ontologies | – |
DBpedia Place | cities and region features | RDF | – | no | Location specification in other ontologies through linked data | – |
WGS84 | Latitude, longitude, altitude | RDF | – | no | Geo-coordinate tagging in many ontologies | – |
DogOnt [9] | Home structural elements, appliances | RDF, OWL | – | no | Smart home | Power consumption estimation in smart homes |
SAREF [17] | Appliances, their functions and services, energy profile | RDF | WGS84, OWL-Time | no | Reference ontology for smart appliances | – |
Home environment ontology [33] | Home structural elements, appliances, computing and peripheral devices | OWL | – | no | Dynamic home environment status | intelligent home service framework (iHSF) |
BOnSAI [58] | Building, location, devices (hardware and communication protocol) | OWL | CoDAMoS | yes | Smart building (automation) | Smart IHU project |
Chahuara et al. [13] | Rooms in a home, objects, status | OWL2 | – | no | Home automation | Voice reactive smart home |
ThinkHome [47] | Building structure, energy providers, resources, comfort | OWL-DL | – | no | Energy efficiency of white and brown goods | ThinkHome project (energy efficiency and thermal comfort) |
SmartHomeWeather [57] | Weather report, source, weather phenomena | OWL2 | Measurement Units Ontology (MUO), OWL-Time, WGS84 | no | Rule reasoning to monitor weather values over time | – |
Phenonet [30] | Crop trials (crop, treatment, plot, genotype) | OWL | Automatic Weather Station ontology, CF ontology, QU, SSN | no | Agriculture Meteorology | Phenonet-OpenIoT middleware |
Context-aware infrastructure and functional activity ontology [68] | location, sensors, object, context human posture, functional activity | RDF | – | no | Human activity recognition | ontology based activity recognition (OBAR) system, part of a Recommender Management Framework |
Efthymiou et al., [21] | Computational entity, event, activity, person, location, environment | OWL | – | no | Smart classroom | - |
Assisted Living ontology [75] | Person, health, time and core (activity ontology) [21] | OWL | W3C time ontology, activity ontology of Efthymiou et al., [21] | no | Activity recognition | Daily living assistance component |
User profile ontology [55] | User profile (capability, interest, preference, education, health), context, location, activity | OWL | – | no | Reasoning to provide customised support for daily activities | MobileSAGE project (assistance services to people with dementia) |
IMS-LD [59] | Learning objects (devices), learner activity record | – | – | no | e-learning | – |
u-learning object model [31] | Learner, tutor, device, content object | – | – | no | e-learning | Self-directed u-learning service |
a http://www.semsorgrid4env.eu/.
b https://sonet.ecoinformatics.org/semtools-svn/ontologies.
c https://bioportal.bioontology.org/ontologies/SWEET.
Most of the ontologies in the WoT are drawn from early efforts in the Wireless Sensor Network (WSN) area to model sensors and actuators. However, recently, efforts have been made to extend the semantic efforts to model WoT-specific elements, including things and the functionalities they provide. Since sensors still represent a sizeable section of the things in the WoT, the semantic modelling efforts for them are presented in a separate section.
With the IoT domain providing the possibility of everyday objects providing real world data to the Internet, the associated models should include metadata describing the objects to provide context to the descriptions.
One of the first EU research initiatives in the IoT area, the IoT-A project,2 defined the IoT domain model [7], identifying the main concepts of the IoT and the inter-relationships between them. A semantic model [20] for entities, resources and services was also proposed, with resources forming the software representation of device functionalities. The focus of interactions by human users or software agents was identified to be the ‘entity’. An entity is modeled to have attributes that tie it to the domain (i.e. observable or actionable features), location attributes as well as type and identifier specifications. Also captured are optional temporal features and links to known vocabularies for specifying ownership. The resources provide some form of physical access to the entity. The resource model specifies resource types (e.g. sensor/actuator/gateway node), the location of the corresponding device as well as a link to the service model that exposes the resource capabilities. The location can be defined in terms of the geographical coordinates, to an external ontology instance such as that in GeoNames3 or through an URI to a local location ontology, such as that which provides detailed location description of rooms and buildings in a campus [18]. A simplified version of the resource model proposed in [20] is shown in Fig. 1.3.
A similar device and entity model is proposed in [32] and in [15] with resources identified as the computational element of a device and categorised as on-device or network resource to represent events in an IoT environment.
A domain independent ontology from the oneM2M standards initiative is the oneM2M Base ontology [42], shown in Fig. 1.4, that features a Thing as its root concept. A root class thing represents an entity in the oneM2M system, and its refinement, the Device class represents a thing which can interact electronically with the environment. A device has 1 or more functionalities (i.e. capabilities) which are exposed to the network through services. The functionality may in turn relate to actuation on the environment (controllingFunctionality) or sensing real world aspects (measuringFunctionality).
In contrast to the entity-resource modelling constructs reviewed above, Zhu et al. [74] define a PT-SOA ontology for physical things (PTs) and services in the cyber-physical domain, where they model the PTs as providers (and recipients) of services. The PT ontology has 4 classes: physical profile to depict the things physical properties, any constituent PT and components; operation profile to specify the resources required for its operation, control mechanisms, maintenance and physical constraints when providing services; context to depict the dynamic state of the PT and the scheduled service specification for scheduling the PT to serve multiple requests to its provided services.
The EU ICT-FP7 project iCore4 defined the concept of a Virtual Object (VO) as the virtual representation of a real world object, such as sensors, devices, or everyday objects, in order to abstract the technical heterogeneity of the possible objects in the IoT. The VO model was defined [34] to support the cognitive management of virtual objects. Each VO concept in the model represents an Information and Communication Technologies (ICT) object, which in turn is associated to a non-ICT object. The model also specifies the VO function in terms of locations and functions of the ICT object. The functions of ICT objects are further expressed as Input, Output, Cost, and Utility. Output is also bound with OutputMetadata to describe its data. A similar VO concept is also outlined by Christophe et al. [14] who present a semantic model for representing virtual objects, to define the structure and capabilities of objects. The model reuses FOAF vocabulary to indicate the owner of objects, and links to the GeoNames ontology to show the location of the corresponding smart space. A simplified version of the iCore VO ontology was adopted in [71], focussing on the data provisioning capabilities of a VO. The VO concept was used to represent different sensing objects, including those with no fixed locations (e.g. sensors mounted on public transport). The VO metadata proposed in this work includes the VO ID, name, type, a Boolean property indicating if the underlying real world object is mobile and the location, expressed in terms of a WGS84 modelled latitude, longitude and a geohash5 value.
Early modelling efforts for sensor and actuator networks were driven by the Sensor Web Enablement (SWE) initiative [10] of the Open Geospatial Consortium (OGC) which defined a set of XML schemas and standards aimed at discovering Web accessible sensor networks and archived data. The widely accepted sensor ontology, which builds upon the SWE initiatives, is the SSN ontology [16] from the W3Cs Incubator Group on Semantic Sensor Networks6 to describe sensors and sensor networks. The SSN ontology describes sensors from a number of perspectives [26], including those representing: a) Sensor: definition of a sensor, to include anything that can estimate or calculate the value of a phenomenon, the sensing procedure and what is being sensed, b) System: to model systems of sensors and their deployment, c) Feature: the property being sensed and, d) Observation: observation values and their metadata. The different modules of the SSN ontology are shown in Fig. 1.5. The SSN ontology, however, does not include modelling aspects for features of interest, units of measurement and domain knowledge that are related to sensor data and need to be associated with the observed data to support autonomous data communications and efficient reasoning and decision making processes. Extensions to other components in the IoT domain are not specified in the ontology.
The CSIRO sensor ontology [41] was the precursor of the W3C SSN sensor ontology. It provides a semantic description of sensors in terms of the sensor grounding (platform, dimensions, calibration, power-source and access mechanism) and operation specification (operation, process and results). Concepts for sensor measurements are not part of the ontology. Moreover, similar to the SSN ontology, concepts for domain knowledge, units of measurement, location etc. are not included. Thus, more modelling concepts are needed to link the sensor descriptions to sensor measurements and then to the real-world objects in the WoT domain. Previous sensor description models include OntoSensor [50] which constructs an ontology-based descriptive specification model for sensors by excerpting parts of SensorML [11] descriptions and extending the IEEE Suggested Upper Merged Ontology (SUMO).7 However, it does not provide a descriptive model for observation and measurement data.
In contrast to generic thing or device ontologies which may be applied to sensor or actuator instantiations, a number of recent research initiatives have specifically looked at modelling actuators and their functionalities by extending the SSN ontology. The Semantic Actuator Network (SAN) ontology [56] proposes the Actuator-Stimulus-Operation modelling pattern as analogous to the Sensor-Stimulus-Operation pattern of the SSN ontology. According to this model, an actuator is an object that modifies an environment property by producing a stimulus. The Operation concept describes the dynamic description of an actuator by defining the actuator operation that modifies the property of a specific feature of interest. The feature and property perspective are the same as in the SSN ontology, with the only change being that features and properties are ‘changed by actuators instead of being’ sensed.
A simplified actuator ontology for home care systems has been proposed by Wang et al. [64] where an actuator is modelled as a refinement of a Device and provides a Service. A service in turn supports a number of Operations which have zero or more Parameters. The Actuator class is further sub-classed into concepts suited to the home domain, such as Alarm, DVDPlayer, Light, MobilePhone, and TV.
The wide adoption of the SSN ontology and its extensions as well as the possibility of semantic annotation of generic objects through the available ontologies can lay credence to the claim that “the solutions for the representation of ‘things’ have reached a mature stage” [26]. However, to address the heterogeneity of the functionalities provided by the things, a higher abstraction level is required. This is typically achieved through services, as detailed in the next section.
To facilitate the development of large-scale, loosely coupled WoT applications, researchers have been applying service-oriented principles to decouple the sensing/actuating functionalities of the WoT things and their hosts. The main tenet has been to abstract the things functionalities and capabilities in terms of standard service interfaces to support uniform service operations.
The semantic annotation methodology of Web Services has been adopted in the WoT domain by researchers to expose services offered by the smart objects. The modelled services provide functionalities to provide information about entities they are associated with or to manipulate the physical properties of the related entities or their surrounding environment. The OWL-S model for SOAP/WSDL services is based on the Profile-Process-Grounding pattern and much of the complexity stems from the process modelling. Semantic modelling efforts in the WoT area apply a modified version of the OWL-S modelling constructs, which is referred to as the profile-model-grounding design pattern, where the profile and grounding are adapted from OWL-S and refined to fit RESTful services and the model excludes process modelling and is based on the atomic service modelling in OWL-S and RESTful service modelling in hREST. The service profile represents the non-functional aspects of the service; what the service is. The service model defines the functional aspects of the service to describe its behaviour and the grounding describes the access details of the service.
The IoT-A project applied the OWL-S principles to service modelling as part of their entity-resource-service ontology suite. The service model [20] represents the functionalities provided by the resource in terms of the IOPE (input, output, precondition, effect) terms. The input and output types are detailed by linking to defined concepts in the QU ontologies.8 The service model also specifies the service area (i.e. the observed area for ‘sensing services’ and the operation area for ‘actuating services’) and the service schedule (to specify time constraints on service availability).
Similar service ontology models have been proposed in [32] and applied to calculating service cost for service selection and in [15] for identifying service related events in IoT environments.
The IoT.est project9 focussed on the senor-as-a-service paradigm [44] and proposed a semantic IoT service description model for knowledge representation [67]. The design aims to balance the trade-off between being lightweight and completeness in addition to focussing on modularity. They adopt the design pattern of [18] for modelling in the WoT domain, and provide a service model which can be accessed through SOAP/WSDL and RESTful services. The service model applies the OWL-S [40] principles to define a service profile which includes the service name, category, QoS and location; a service model which defines the operations allowed on the service; and the grounding which describes the interaction elements, (e.g. endpoint addresses and communication protocols), and captures the RESTful resources (e.g. Input/Output parameters and the corresponding access URLs). Quality of Service (QoS) and Quality of Information (QoI), are also modelled, including relationships that link to the ‘service’ class. The defined ontology also incorporates test features to enable automated test case creation and execution. The designed test model enables model-based testing of IoT service capabilities and automated test data creation. The various modules of the service ontology are shown in Fig. 1.6.
The OWL-S specification also forms the basis of the dynamic service ontology proposed in [45] to model transactions in the IoT domain. The service profile element of OWL-S is expanded with a ServiceStatus class to describe the current status of entity services. The ServiceStatus class is defined in terms of a name (as string), location (as latitude, longitude or other physical locations), current status (which can take 3 values: atomic, composite or simple status), complicating count (representing the number of concurrent services) and waiting sequence (representing the transactions waiting on the entity). The ServiceStatus class instance values support the selection, combination and control of entity services.
The semantic information model in the ForwarDS-IoT discovery service [24] also applies the profile-model-grounding pattern of OWL-S to describe services. The Service class is linked to both the Sensor and Actuator classes in the information model through the exposes property.
In contrast to the above approaches, the PT-SOA ontology model [74] applies the OWL-S constructs of process-profile-grounding as is. The Service class is linked to a PT instance through the providedBy and appliedTo properties, as a service is provided by a physical thing and may also be applied to, i.e. influence, another thing. The conventional OWL-S ontology is extended with the context precondition and context effect classes to specify the dynamic requirements and subsequent effects of each service of a PT.
Thoma et al. [60] outline a service description for sensor node services in an RDF version of USDL (Unified Service Description Language). The main focus of the semantic annotation of sensor nodes and network services is their integration with enterprise IT systems. The description model specifies the interaction protocol (including input and output parameters), the service model, provider details, links to the service executable, legal conditions and the service providing business entity. The Semantic Service Description (SSD) ontology [28] aims to support the translation of platform-specific configuration into semantic metadata to achieve interoperability between services offered by physical objects and deployment platforms. The proposed ontology has a main concept of ServiceObject which is defined in terms of 3 main classes: Property, Capability and Server Profile. Each class property value is defined as a key-value pair. The Property class describes the static properties of the underlying object, the capability class describes the data provided by the service in terms of its name, data type, data unit and condition. The server profile contains classes and properties describing the server name, URL and the available server actions such as deploy, uninstall and update. Each action comprises of HTTP methods such as GET, POST, PUT, UPDATE, user request destination, HTTP header and content.
The work presented in [35] proposes an ontology-based model for service oriented sensor data and networks. The ontology consists of three main classes: ServiceProperty, LocationProperty, and PhysicalProperty. ServiceProperty explains the functionality of a service, while properties in the other two components describe contextual and physical characteristics of the sensor nodes in wireless sensor network architecture. The system, however, does not specify how sensor data will be described and interpreted in a sensor network application.
The service ontology defined as part of the IoT-based service integration ontology (IIO) [51] represents services in a smart city. It is represented in terms of a Topic, defined by developers and used to distinguish between service offerings in the city. The service class is further defined in terms of the Method concept (Create, Read, Update, Delete methods) to reference WoT resources, URLs and repositories to reference the service platform, and links to the User class.
As the next step to the semantic modelling of the physical objects of the WoT and their capabilities exposed as services, it is necessary to review the information available from such resources, either as a result from their interactions or from the observation of the ambient environment. Data ontologies in the WoT mainly describe Observation and Measurement (O&M) data, mostly focusing on how data is generated, what the data is and what real world phenomena or features may be related to the data. In addition, metadata on when and where the data is generated is usually included. This section presents both data ontologies designed for annotating instantaneous and streaming O&M data.
A number of works have looked at extending the syntactic XML OGC schemas to semantic models to link the domain knowledge to external schemas and enable cross-domain query and reasoning. Annotation of observation data with external temporal and geographical concepts using the Linked Data principles is demonstrated in [65]. In this work, observations are annotated with time (at which they occurred) and location concepts published by DBpedia.10 This work does not address annotating a series of observations and its subsequent storage or querying over past data. In the Linked Sensor Middleware (LSM) and in [5], sensor data is annotated using relevant links to concepts in DBpedia and GeoNames. However, in these approaches, the focus is on provisioning the sensed data through common interfaces.
Semantic data models to manage sensor data are also presented in [27,43,3] with ontology models based on OGCs O&M standard. The models defined in [27,43] attach a time stamp to each observation using OWL-time ontology.11 The key concepts modelled in the SemSOS O&M-OWL ontology [27] are observation, process, feature (abstraction of real-world entity) and phenomenon (property of a feature that can be sensed or measured). The observation location, result data and sampling time are also captured. The O&M concepts are aligned to SensorML and the feature and phenomenon concepts pertain to the weather domain. In [43], the authors retrieve observational data from a number of weather stations in the US and develop a method to convert this raw textual data into RDF. The model captures the time, location and type attributes of the observation data. Location information is linked to concepts in GeoNames to enable answering queries related to location of sensors near a place name. The SensorData ontology [3] defines a semantic form of the OGC SWE common data model. Each SWE data record encompasses the quantity being measured and associates it with instances of the NASA SWEET ontology12 to specify measurement units. A similar approach to separate the observations from the entity being observed is presented in the SEEK Extensible Observation Ontology (OBOE) [12], which has a core observation ontology, units extension, and a further extension for domain use (coastal ecosystems). Each observation is modelled to have a measurement, with an example provided for a coastal ecosystem domain. The concepts in the OBOE ontology would require to be extended to include generic features of possible IoT smart objects. Also, placeholders to include sensor descriptions from other ontologies would be required.
The VO ontology in [71] incorporates Information elements to represent the O&M data sensed by the VOs. Each information instance has a name and semanticURI that specifies the type of the observed feature (e.g. temperature) in terms of an instance in an external domain model, for instance, the vocabulary of climate and forecast features (CF) taxonomy.13 The actual O&M data is represented through a literal value, its unit of measurement drawn from vocabularies such as the ontology, the time the measurement was recorded and the location of measurement as specified by a geohash string.
As pointed out in a recent survey of WoT search techniques [73], much of the work on sensor data streams has focused on using sensor Data Stream Management Systems (DSMS) that employ continuous queries over the data streams. However, a couple of recent works have investigated semantic annotation of sensor streams.
The O&M data attributes modelled in [4] include ID, timestamp, value, unit (using SWEET ontology), datatype, location (expressed as a geohash) as well as links to external metadata (such as DBpedia and GeoNames).
The Stream Annotation Ontology (SAO) [37] extends the SSN ontologys observation concept through the StreamData class that captures segment or points of the O&M stream, linked to time intervals or time instants.
A discussion of WoT data ontologies is incomplete without presenting the ontology efforts for describing units of measurement that are vital for representing data measurements. Unit of Measurement (UoM) is one important aspect of sensor observation data as it helps to avoid ambiguous information from sensor values and provides explicit meaning to the sensed data.
NASAs Semantic Web for Earth and Environment Terminology (SWEET) defines concepts of Representation, Realm, Phenomena, Processes, Human Activities, Matter, etc. It also defines Property, State, and Relation to express relationships between the concepts. Units are defined in NASA SWEET by using Unidatas UDUnits,14 providing conversion factors between various units [46]. Unlike NASA SWEET, W3C Quantities, Units, Dimensions and Values (QUDV)15 focuses more on data-related concepts. It defines modules of Data, Unit, Scale, Quantity, and Dimension for expressing values. Multiple Classes and Properties are defined under related modules for detailed expression. Focusing on terminology used in science and engineering, Quantities, Units, Dimensions and Data Types Ontologies (QUDT16) aims to provide a consistent vocabulary, which can be used by both human and machines, while maintaining extensibility. In order to enable interoperability and data exchange between information systems without ambiguities, it defines three main classes of Dimension, Quantity and Unit. The simple Units Ontology (UO) [23] is defined and classified with respect to different kinds of unit, such as acceleration unit, density unit, etc. Similarly, Ontology of Units of Measure and Related Concepts (OM) [49] also defines classes based on quantity and related kinds. An early ontological effort for representing units was the Measurement Units Ontology (MUO)17 that follows the Unified Code for Units of Measure (UCUM) [22], and defines basic classes such as BaseUnit, DerivedUnit, etc. and relationships (e.g. derivesFrom, numericalValue, etc.). A survey of other UoM ontologies is described in [48].
A number of generic location models at different levels of granularity (city-wide, buildings) have been proposed to support the modelling of the core WoT elements outlined in the preceding sections and to provide location context to the modelled entities.
The indoor location ontology in [19] is used to describe a place and its location relatively to others, to allow reasoning on adjacency, access etc. the place concept is further refined into building, premise and floor. These concepts are formally defined in terms of logical OWL-DL predicates, e.g. a building is defined as a place not contained in any other place and containing at least one floor. Premises are further refined into Room, House, Shop etc. Properties interlinking the various place concepts are also defined, including those defining containment, adjacency (including directions), access and inclusion. A similar indoor location ontology is defined in [63] representing buildings, floors, laboratories and meeting rooms in a university campus. For representing wider, city-scale location features, the GeoNames geographical database is an important source as it provides user-friendly location names or geographical coordinates of geographical features and captures the associated contextual information on region containment and distance among locations. Following the linked data principles, ontology instances in other domain independent models (e.g. device, service etc.) can refer to GeoNames place names through the unique URI to enable semantic reasoning related to relative positioning. The WGS84 RDF model [2] is a simple vocabulary for representing latitude, longitude and altitude information of a geographical point.
The CityGML ontology18 is an OWL version of the CityGML standard that has created by generating the classes, properties and axioms from the CityGML XML schemas, which aim at representing virtual 3D city models. The city space representation is based on the Geography Markup Language version 3.1.1 (GML3) and includes concepts for land use, vegetation, tunnel, transportation, water body, bridge, building etc. The DBpedia RDF dataset also hosts unique semantic identifiers and descriptions for cities and region features around the world as instances of the Place concept in the DBpedia ontology, containing properties defining region containment as a hierarchy of places and other information. The DBpedia instances can also enable location-aware semantic reasoning in WoT applications.
This section presents ontologies that model the home/office/public buildings environment along with associated applications and influencing factors such as energy efficiency and thermal control of building elements. Also presented is the ontology that extends the SSN sensor ontology to the agriculture domain.
The domotics application domain has been the focus of a number of research applications and modelling efforts due to increasing numbers of ‘smart’ home appliances being shipped that can interact among themselves and overall, contribute to the ‘smart home’ vision.
The DogOnt ontology [9] supports device and network independent description of homes, including both ‘controllable’ (i.e. appliances) and ‘structural’ (e.g. room, garden, garage) elements. Defined properties link these elements to their functionality, defined in terms of notification, query and control functionalities, state and communication components. The Smart Appliances REFerence (SAREF) ontology19 [17] has been proposed to abstract the communication protocol heterogeneity and energy profiles of appliances in the smart home domain. It contains the generic concepts derived from the semantic annotation of other assets (standards, protocols, devices, datamodels etc.) in the smart appliances domain. It has a core concept of a Device which represents objects found in households, public buildings and offices. Each device offers functions through associated commands. A function is presented to the network through a Service, which specifies the input and output parameters. Each device is also characterized by an Energy/Power profile to optimize energy efficiency within a building environment. The home environment ontology proposed by Joo et al. [33] models home structural elements such as door, window, boiler etc. as well as a number of appliances that may be found in a typical home, including appliances (fridge, toaster, microwave oven), peripheral devices (camera, microphone etc.), computing devices (PC, home server, set-top box etc.) and sensing devices (e.g. location and security sensor). The developed home ontology is used to support service classification and execution as part of the intelligent home service framework (iHSF). The smart Building Ontology for Ambient Intelligence (BOnSAI) [58] includes concepts for functionality (services) of devices along with their communication protocol specification, environment, users and context. A simplified model of different types of rooms in a home, objects located in these different rooms along with their current state is modelled in [13].
In contrast to the above ontologies that focus on the smart objects within the home environment, the ‘ThinkHome’ ontology [47] has an energy and user comfort focus, with concepts defined for the building structure, actor (human user and software agent), comfort, energy providers, process and resource. The ontology enables the self-regulation of the cooling system according to a defined schedule. The ‘SmartHomeWeather’ ontology [57] facilitates predictive control of home elements such as window opening, garden irrigation etc. The weather ontology models the weather report and its source, the weather state and weather phenomena (such as wind, temperature, cloud cover, humidity, precipitation, sun position etc.). As presented above, the domotics area has received a substantive research attention and has been the driver for a number of semantic modelling efforts. The different themes captured in the different models are depicted in Fig. 1.7.
The Phenonet ontology [30] extends the SSN ontology to the agriculture meteorology domain and links sensor descriptions and data to information about crop trials. The Phenonet part of the ontology defines the main concepts of crop, the Treatment and its type, the crop genotype and the plot characteristics, including soilSlice. The SamplingFeature class links the samples from the plot and soilSlice class to the ssn:Sensor class. The ontology facilitates automatic annotation of sensor data streams, enables discovery of resource from trial data sets and provides a standard way to publish crop trial experiments data.
This section presents ontology efforts that focus on human activities, including learning scenarios and the home care (or assisted living) scenarios.
Most of the ontology modeling efforts in the AAL domain have focused on activity recognition and ambient intelligence, with some also aiming to capture user modeling and personalization. The context-aware infrastructure ontology and the functional activity ontology have been proposed as part of the ontology based activity recognition (OBAR) system [68]. Concepts such as location, sensors, object and context are modelled in the infrastructure ontology to provide context to the Human Posture and Functional Activity classes of the functional activity ontology. The system applies Semantic Web Rule Language (SWRL) reasoning to infer 13 activities, including ‘eating & drinking’, ‘take a bath’ etc. and a range of human postures such as ‘standing’, ‘sitting’ or ‘lying down’.
Real-time activity recognition is the focus on the ontology presented in Efthymiou et al., [21] which represents concepts such as Computational entity, Person, Activity, Simple Event and Environment. Information obtained from sensors is stored in the Computational entity class, with the knowledge inferred from reasoning on the stored data applied to the Simple Event class. Events are included in an Activity, which has a beginning and end time. The Person class is linked to the Activity class through the participates in property.
The Assisted Living ontology [75] defines a number of modules covering different aspects, including Person Profile encompassing the persons habits, impairment and preferences; Health encompassing disease, its symptoms and treatment aspects; W3C time ontology; and a Core ontology that is imported from the activity recognition ontology of [21]. The ontology modules enable rule-based and case-based reasoning to deduce activities and take into account a persons health.
The user profile ontology [55] in the MobileSage project is aimed at user modelling and personalisation reasoning to provide assistance services to people with dementia. The profile aspects are modelled through five classes: CapabilityProfile, InterestProfile, PreferenceProfile, EducationProfile and HealthProfile. The ambient environment is modelled through Context, Location and Activity classes.
The IMS Learning Design (IMS-LD) ontology [59] provides a semantic representation of learning resources and smart objects, while taking into account the learners activities. The ontology defines Learning Objects as addressable digital or physical learning resources, which could take the form of Web resources or physical resources attached with IoT devices such as sensors, actuators or tags. Smart Learning Objects are abstracted as virtual objects which have properties describing their functionalities, location and status. The Learning Record Store models the data collected as a result of the learners activity and use of the Learning Objects. The associated xAPI ontology adds semantic meaning to the collected data.
A different perspective is captured in the u-learning object model [31], which captures the relationships between the learner, the learning resources and the educational content. The core concept is that of a service object that links to the Learner, Device object and Content object classes. The Content object can be text/image/video/audio and is further defined through metadata such as an object profile, attribute container, time and location.
This section presents a discussion of the findings from the review of the existing work and an outlook towards the future direction of WoT ontology modelling based on the authors experience in knowledge modelling in the WoT field over the course of several IoT related European projects. The discussion section is structured following the classification defined in this chapter.
The abstraction of the physical world things provides access to the data already produced by the things, while decoupling the physical things and the data they generate. The abstraction process also facilitates data processing steps such as aggregation, which could not be possible at the physical thing level. The service abstractions enable access to the virtual things as Web services or RESTful services. The review of the entity, virtual thing (resource), service and data ontologies reveals that most research works define semantic models for a combination of these concepts. Fig. 1.8 depicts how these crucial WoT concepts are interrelated.
As far as sensor ontologies are concerned, the SSN ontology is now the de-facto standard and starting point for all modelling efforts in the sensor domain, as evidenced by its wide adoption and numerous extensions, as listed in [1]. The ontologies for representing things have also reached a critical mass and the concepts in different ontology modelling efforts have begun to converge. An important development allied to the data ontologies, and which is related to an issue that is going to gain prominence as the data sources in the WoT continue to grow, is the W3C provenance ontology.20 The ontology models concepts which can help to uniquely identify and trace the data source generators. The ontology can be crucial in deciding whether data can be trusted and how it should be integrated with other diverse information sources.
The drive towards smart cities has motivated a number of research works and modelling efforts in allied domains such as smart home, AAL and smart appliances. Also receiving research attention are modelling efforts in buildings representation along with the energy profile and usage in buildings. The importance of domain ontologies as providing the core resource for reasoning about a domain and context is evident from the developed applications and prototypes that make use of these ontologies.
As also depicted in Fig. 1.2 through the dotted lines, we do not claim completeness of the presented categorisation and review of domain ontologies. The domains reviewed here include those that have received substantial research modelling efforts (e.g. home automation and AAL), or have formed part of large trials (e.g. agriculture meteorology). Other specific domains that have been modelled included some specific airports (e.g. Rome Fiumicino21 and Malpensa22 airports), smart grids23 and smart environments.24 The READY4SmartCities project25 maintains a catalogue of ontologies and datasets relevant to the smart cities and smart home domain.
The study presented in the previous sections shows that ontology modelling efforts have largely concentrated on the active objects of the WoT, i.e. devices, specifically sensors (and to some extent actuators), the data produced by such objects and the abstraction of their interaction methods through service models. The other focus has been on conversion of existing syntactic models, such as those in XML, into their semantic form, as evidenced by the body of sensor related ontologies drawing on the OGC XML schemas. However, future modelling efforts need to take into account the emergence of smart tags, such as printed electronic sensors and dynamic QR codes, that can attach to passive objects to enable them to form part of the WoT. The ontologies would need to take into account the dynamic capabilities of the smart tags, such as their different encoding and scanning processes, their reactions to environmental factors such as temperature, humidity, light and the possible reaction states they can undergo. Ontology models for smart tags can allow everyday passive objects to form part of the WoT and open up new mass-market applications such as evidence of tampering in logistics, product provenance etc. by enabling semantic reasoning of their status and captured data.
A good practice in ontology modelling for the WoT has been to publish the metadata as linked data, which links to other data items in different sources (e.g., domain knowledge bases and existing linked data cloud). Regarding the storage of the ontology instances, especially with regard to those of the data ontologies, a combination of centralised and distributed methods is suitable with the WoT object and service metadata in a centralised repository and the more dynamic data streams in distributed stores. To encourage the use of ontologies by practitioners and application developers, ontology designers also need to consider developing annotation tools that can make the task of creating semantic annotations of WoT objects and provisioned services, according to the defined ontologies, easier. The annotation tools need to support the CRUD (Create, Read, Update, Delete) methods which translate into publishing, reading, updating and deleting WoT concept descriptions and can ideally be implemented through a graphical user interface, as achieved in [20]. Also of importance is the ability to create linkages to existing ontology instance or data repositories in accordance with the linked data principles.