1.3.1.1 WoT Smart Object Ontologies

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,² 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 GeoNames³ 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 iCore⁴ 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 geohash⁵ value.

1.3.1.2 Sensor Ontologies

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 Networks⁶ 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).⁷ 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.

1.3.2.1 OWL-S Based Ontologies

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.⁸ 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 project⁹ 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.

1.3.2.2 Other Service Ontologies

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.

1.3.3.1 Observation and Measurement Data Ontologies

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.¹⁰ 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.¹¹ 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 ontology¹² 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.¹³ 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.

1.3.3.2 Semantic Annotation for Sensor Data Streams

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.

1.3.3.3 Units of Measurement Ontologies

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,¹⁴ providing conversion factors between various units [46]. Unlike NASA SWEET, W3C Quantities, Units, Dimensions and Values (QUDV)¹⁵ 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 (QUDT¹⁶) 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)¹⁷ 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].

1.4.1.1 Home Automation

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) ontology¹⁹ [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.

1.4.1.2 Agriculture Meteorology

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.

1.4.2.1 Ambient Assisted Living (AAL)

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.

1.4.2.2 IoT-Enabled e-Learning

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.