SmartEnv as a network of ontology patterns

Abstract

In this article we outline the details of an ontology, called SmartEnv, proposed as a representational model to assist the development process of smart (i.e., sensorized) environments. The SmartEnv ontology is described in terms of its modules representing different aspects including physical and conceptual aspects of a smart environment. We propose the use of the Ontology Design Pattern (ODP) paradigm in order to modularize our proposed solution, while at the same time avoiding strong dependencies between the modules in order to manage the representational complexity of the ontology. The ODP paradigm and related methodologies enable incremental construction of ontologies by first creating and then linking small modules. Most modules (patterns) of the SmartEnv ontology are inspired by, and aligned with, the Semantic Sensor Network (SSN) ontology, however with extra interlinks to provide further precision and cover more representational aspects.

The result is a network of 8 ontology patterns together forming a generic representation for a smart environment. The patterns have been submitted to the ODP portal and are available on-line at stable URIs.

1. Introduction

Applications of sensorized environments that provide domestic monitoring and cognitive assistance services for their inhabitants/users are increasing. An example of such an application is health care monitoring and services, where patients are being monitored and cared for in their own living environment. In order to support the use of artificial intelligence techniques for automating the provision of these services, it is necessary to describe the capabilities of the various aspects of such environments. These descriptions include physical aspects (e.g., the structure of the environment, sensor network setting or entities), as well as conceptual aspects (e.g., events or activities of the users), and can be modeled in ontologies. According to [21], there is a general list of questions about the inhabitants of smart homes (as an example of smart environments), which many of the suggested knowledge models in the literature aim to address. This list includes questions about the location of the inhabitant, the activity that the inhabitant carries out, the intention behind the activity, the time when the activity is detected, etc. Although the representational models (i.e., ontologies) target the same goal, they differ in terms of the level of generality as well as their reasoning efficiency.

Due to the dependencies between the aforementioned features, such an ontology can easily become large and complex; moreover, it may need to be updated over time, e.g., when sensors/robots with new kinds of features are added to (or removed from) the environment, or when the monitoring requirements of the environment change. Additionally, when we use ontologies in a system that requires near real-time reasoning and reactions by the system, the reasoning complexity is an essential parameter of the ontologies. For these reasons, we propose the use of a network of ontology modules, which is called SmartEnv and could be considered as a set of interlinked content Ontology Design Patterns (ODPs) [15] due to their generic applicability to the domain and our deliberate effort to minimize their ontological commitments, while maintaining functionality. According to the principles of ODP modeling, the ontological commitments should be minimized by first creating small modules, and then linking them together, instead of designing a large monolithic ontology from scratch as a comprehensive representation of the entire domain [7].

Before going to the details of our proposed ontology, in Section 2, we first motivate how and why our suggested SmartEnv ontology is required and compare the available ontologies with the given requirement list. In Section 3, we shortly introduce the project whose requirements led us to the development of the SmartEnv ontology in the form of a network of ontology modules. In Section 4, we explain the 8 ontology patterns (modules) used in SmartEnv ontology. The SmartEnv ontology, as the result of specializing the relations between modules along with its application is presented in Section 5. A discussion on our approach is given in Section 6, where the paper is concluded by giving remarks concerning future developments.

2. Motivation and background

2.1. Representational requirements

During the requirements analysis process, we considered a number of (conceptual) aspects of smart environments to be covered in the ontologies. For further clarification, some aspects are explained based on a set of high-level competency questions (CQs) (only examples are given here due to space restrictions). The detailed CQs for each of the patterns can be found inside the ODP itself, as annotations of its OWL file, and on its page in the ODP portal:

Observation/sensing  Observing (i.e., monitoring) of an object or a place is the main motivation why the environment is sensorized. A representation model is required to answer questions such as what can be observed by a certain sensor? To what object is a sensor attached? What is the location of the object, and what does the sensor measure? Can the sensor or its holding object move?

Agents  Agents (e.g., inhabitants of a home) are the main characters whose activities, locations, or more specific parameters such as safety and health are usually the main reason behind any observation process in a smart environment. A representation model is required to answer questions such as what are the possible activities of the agent? Can the agent be targeted by sensors? Where is the agent now? What is the agent doing now?

Activities/events  Any changes in a smart environment are represented in the form of an event or an activity. Questions such as when an event has occurred, or why such event was recognized, can be answered by representing activities in terms of their preconditions.

Objects  Physical objects are also directly or indirectly the target of the observation process in order to recognize activities in a smart environment. We represent objects to answer questions about their state (being in a specific situation), locations, or the events or activities in which they are involved.

Network set-up  In order to set-up a smart environment a sensor network deployment related to the observation process, is indispensable. A network representation model is used to answer any question regarding the hardware and software configuration of a network, its components and their locations.

Spatial aspect  Any physical entity such as objects, agents, and places in a smart environment has a geometrical aspect based on which their spatial relations with the environment can be represented.

Temporal aspect  Similar to spatial aspects, the temporal aspects are the main basis of an observation process. A temporal representation model is used to answer questions such as when the occurrence of an activity is realized. It also allows us to define activities based on the temporal relations with their preconditions.

Given the aforementioned general list of high level concepts required to represent a smart environment, in the following, we overview the literature on the sensor-related ontologies.

2.2. Overview of sensor-related ontologies

Sensing and in general sensor-related details of smart environments as one of their integral computational aspects has been widely studied in the literature [4,14,21]. Although the “re-usability” has always been advertised as an essential features of ontologies, there is a large number of adhocly designed sensor-related ontologies in the literature, many of which are not even available online. This number increases when the idea behind the design of these ontologies is getting more specific, for example for activity recognition purposes [21]. One important task in designing ontologies for smart environments is to identify the activities of an agent in the environment, for instance in the case of a smart home, these could be activities such as “sleeping”, “watching TV”, “cooking” etc. In addition to being able to identify an activity, we also need to represent the time and location where the activity is carried out. Ontologies suggested for recognizing daily activities are rarely relying on upper-level ontologies [20,24], which usually result in a lower reusability. Concerning the re-usability of ontologies, [25] proposes a top-level ontology that provides a formal and generic representation of activities sharable between different domains. However, apart from the activity representation, in the aforementioned work there is no representation of the other aspects of a smart environment. With the focus on smart environments, [18] introduces the Casas Ontology (COSE) being able to represent sensors, buildings, occupants and human activities, which is publicly available. However, there are no representation details provided to show that the offered light-weight model relies on available upper-level ontologies, or even that it is possible to align it to such ontologies. Furthermore, both the spatial and temporal aspects are poorly represented and there is no support for the representation of the sensor network at all. Likewise, the COBRA-ONT ontology, which also provides a representational model for pervasive computing environments, lacks an alignment with an upper level ontology, and does not contain an explicit temporal representation model [9]. Two other ontologies related to context-awareness in sensorized environments are SOUPA [10] and DogOnt [8]. Although there are a number of working applications of these ontologies, both are lacking some representational aspects. For instance, in SOUPA, we are not able to define devices (as part of the network modules) and their configurations and functionalities. DogOnt also provides a limited object representation with no support for their dynamic features. Comparing with the above mentioned ontologies, the ontology introduced in [1] is more complete in terms of localisation and temporality. It also considers the required representational basis for environmental changes (e.g., events). However, what is missing is again an alignment to an upper level ontology, and although it has been claimed that the ontology is per se generic enough to be used in different domains, it is not obvious how it relates to commonly used upper ontologies and standards.

There are also few approaches in the literature proposing more general ontologies for IoT-related domains, regardless of their applications. The Semantic Sensor Network (SSN) ontology [12] is introduced as a generic and reusable knowledge model for sensor-related environments. The first version of SSN1

¹

https://www.w3.org/2005/Incubator/ssn/ssnx/ssn.

was relying on the upper level ontology DUL2 ²

DOLCE Ultra Light: www.ontologydesignpatterns.org/ont/dul/DUL.owl.

and took a remarkable step towards the reusability of ontologies [12]. However, the representational details in the first version of SSN could cause an excessive processing query time. That is why some lighter instantiations of SSN, such as IoT-Lite have been introduced [6]. Due to its light weight (in terms of expressivity), IoT-Lite allows us to define some relevant IoT-related concepts to support interoperability of heterogeneous sensor data. Although the vocabularies used in IoT-Lite are aligned with their generalized counterparts, the representation of the key concepts in sensor-related environment that are discussed in Section 2.1 such as sensor, action and observation, is limited [22].

Regarding the load of the representational details in SSN bringing up excessive processing time, the W3C Spatial Data on the Web Working Group has proposed an updated version of SSN as a W3C recommendation with no import of the DUL ontology as its basis [17]. The new version of SSN provides a basis for some required concepts (e.g., sensor, observation, platform, etc.) in representing a smart environment. Although the new SSN is not based on DUL, a specific alignment module is also provided, which can be used if needed.

In this paper, we propose a generic ontology for smart (sensorized) environments (with at least one inhabitant/user) based on SSN. There are a number of works in the literature inspired by the old version of SSN [2,23]. However, since the basis of our proposed ontology is the new version of SSN, we do not go through the details of old-SSN-inspired work, as their differences with our proposed ontology will be similar to the differences between the old and new version of SSN. In our design, we rely on the general concepts given in the new version of the SSN ontology and extend/specialize them in order to cover all the representational requirements given in Section 2.1. This extension, which will be explained in the remaining sections of the paper, is focusing on both static (such as objects, deployment or network set-up) and dynamic (such as temporal and spatial, activity and event) concepts.

Regarding the design pattern approach, the ODP techniques underpinning our approach make it similar to the work proposed in [19], which introduces a generic Stimulus-Sensor-Observation ontology design pattern for representing observation-based data on the Semantic Web, although their focus is much more limited. Moreover, the focus of the work presented in [22] is on designing a core domain IoT ontology and proposes a reasonable categorization of high level concepts. What makes our approach different, however, is first its more comprehensive coverage of concepts, and also the provided representational details of the aforementioned aspects of a smart environment.

As said above, our proposed ontology can be seen as a network of modules whose basis are extracted from SSN. Each module is represented in the form of a pattern, as general as possible with the least possible dependencies on the other patterns. Doing so helps us to realize the main links in the eventual ontology. We can consequently make a stable and at the same time flexible network of concepts that can be updated with the minimum change propagation on the entire ontology, and where individual patterns can also be used in isolation for some specific reasoning tasks (e.g., in order to avoid issues with reasoning complexity or clashes in the relations to foundational ontologies).

3. Use case: Ecare@home project

In order to set the stage and explain the background of our work, we will here briefly describe the project where the ontology modules were developed. We also introduce a reasoning example that will be used throughout the paper to exemplify the use of the modules.

The E-care@home project aims at providing a comprehensive IoT-based healthcare system, including state of the art communication protocols and high-level analysis of data from various types of sensors, combined with information from personal health records, and other background information, both generic and specific to a person. The main scenario is that of an elderly person who has some specific needs and potential medical conditions, but is still living at home. In order to increase the safety of the person, and reduce the frequency of appointments needed at a care facility, the patient and caregivers have agreed to fit the patients home with some sensors and a communication device, such as a tablet with a specific application installed. The challenge is to integrate and reason over all the information both from the sensors and the medical records at once, and derive the most likely conclusion, e.g., the current situation that the patient is in, the cause of some events, and the best action for the system to take next. This is quite a typical scenario for sensor-based monitoring systems, hence, it has enabled us to generalise our specific requirements (mentioned earlier in Section 2.1) and provide a solution that we believe is highly reusable by other systems, regardless of the domain where such situation awareness and monitoring is required.

3.1. A sample scenario

Throughout this paper we will use the following example to illustrate our modules:

Let us assume we are monitoring a patient with severe COPD (Chronic Obstructive Pulmonary Disease). Since one effect of the disease is lung function reduction, patients tend to have a hard time to remain active. A reduced level of activity in their daily lives may be an indication of a worsening of the condition. The level of activity is furthermore seen as an important contextual background information for interpreting readings from medical sensors and self assessments, such as perceived breathlessness or oxygen saturation. Therefore one task of the E-care@home system is to create a time-line of the patient’s daily activities. One possible (simplified) example of such an inference, based on sensor observations could be that the patient is watching TV as long as the person is seated on the couch in the living room and the TV is on. For performing this inference, we need at least two sensors attached to objects located in the living room: one that registers the couch occupancy and one that records the on/off status of the TV. Moreover, we need information about the patient, as an actor (or agent) whose activities can be observed through sensing processes implemented by these sensors. We also need several layers of abstraction in terms of observed events, i.e., both low-level manifestations, such as that the TV is on, and complex events that are composed of (sequences or sets) of such manifestations, such as the notion of watching TV, as well as reasoning mechanisms to derive the latter from the former.

Fig. 1.

SmartEnv Ontology based on its 8 building blocks in the form of ontology patterns.

4. SmartEnv ontology – Overview

In the previous section, we discussed the existing ontologies that have inspired our work, and the reasons why none of them cover all the requirements. In this section, we briefly provide an overview of the overall ontology network that we propose as a solution to this problem. Figure 1 represents an abstract overview of the overall ontology in terms of its modules and their relations. The figure is somewhat simplified in order to be more readable, e.g., most inverse relations have been omitted as well as some of the alignments to external classes and properties. In the following section we then go into details of the individual modules and their axiomatization.

The SmartEnv ontology3

³

https://w3id.org/smartenvironment/smartenv.owl.

is composed of 8 ontology modules which are publicly available. Each module is representing a single principal feature of a smart environment. The requirements for the modules of the SmartEnv ontology are formalized based on the reasoning requirements, derived from the high-level requirements presented earlier in Section 2.1. As we will see in the following subsections, most of the modules are extending other ontologies such as SSN and DUL. The name of the concepts and relations taken from the aforementioned ontologies are represented in the form of shortened IRI referring to the OWL definition of the concepts.

In this section we only provide the Description Logic (DL) notations of the classes and properties. To further clarify, in Section 5.1 we provide examples showing how these DL notations are used to populate the SmartEnv ontology.

4.1. Time pattern

The pattern Time4

⁴

https://w3id.org/smartenvironment/patterns/time.owl.

represents any temporal entities that we may use to represent things in a smart environment. In order to represent the temporal aspect of such environments, we have designed the pattern Time which is mainly an extension of the OWL-Time ontology, a W3C recommendation for describing temporal concepts [13].

The OWL-Time ontology provides precise representation for temporal entities in the form of either time instant or temporal duration. In the context of smart environments, we, however, require more specific temporal representation that allows us to also represent relative temporal distance (for example, between an event and its preconditions). By relative, we mean the temporal distance is indicated without knowing the specific timestamps located within a specific distance to a given time point (e.g., the event cooking is recognized at time-stamp t only if we know at least between 20 to 10 seconds before that, someone has been around the stove, regardless of the exact time t).

For this, we have extended the OWL-Time ontology and introduce it as our Time ontology pattern. In this pattern, we define three types of temporal entities representing time instants, time intervals and temporal distances. In the following, we go to the details of the classes, where the two prefixes owl-time and se-time refer to the URIs of the OWL-Time ontology, and our Time ontology pattern, respectively:

se-time:TemporalEntity is subsumed by the class owl-time:TemporalEntity : $$\begin{array}{ll}\hfill & \mathtt{\text{se-time:TemporalEntity}}⊑\\ \text{(1)}& \hfill & \mathtt{\text{owl-time:TemporalEntity}}.\end{array}$$

It is also equivalent to the union of the three classes se-time:Instant, se-time:Interval and se-time:TemporalDistance as follows: $$\begin{array}{ll}\hfill & \mathtt{\text{se-time:TemporalEntity}}\equiv \\ \hfill & \mathtt{\text{se-time:Instant}}\bigsqcup \mathtt{\text{se-time:Interval}}\bigsqcup \\ \text{(2)}& \hfill & \mathtt{\text{se-time:TemporalDistance}}.\end{array}$$

se-time:Instant According to OWL-Time, an instance of the time instant is assumed to represent a temporal entity with zero extent or duration. The subsumption of this class in our Time pattern, i.e., se-time:Instant, is specialized to also include a date-time-stamp value supposed to be modeled by this class as follows, where the prefix xsd also refers to http://www.w3.org/2001/XMLSchema : $$\begin{array}{ll}\hfill & \mathtt{\text{se-time:Instant}}⊑\mathtt{\text{owl-time:Instant}}\sqcap \\ \hfill & \mathtt{\text{se-time:TemporalEntity}}\sqcap \\ \text{(3)}& \hfill & =1\mathtt{\text{owl-time:inXSDDateTimeStamp}}.\mathrm{(}\mathtt{\text{xsd:dateTimeStamp}}\mathrm{)}.\end{array}$$

se-time:Interval is likewise a specialization of the class owl-time:Interval and represents a temporal entity with an extent or duration. Our specialization includes more representational details of a duration whose starting time is known as follows: $$\begin{array}{ll}\hfill & \mathtt{\text{se-time:Interval}}⊑\mathtt{\text{owl-time:Interval}}\sqcap \\ \hfill & \mathtt{\text{se-time:TemporalEntity}}\sqcap \\ \hfill & =1\mathtt{\text{owl-time:hasBeginning}}.\mathrm{(}\mathtt{\text{se-time:Instant}}\mathrm{)}\sqcap \\ \text{(4)}& \hfill & =1\mathtt{\text{owl-time:hasDuration}}.\mathrm{(}\mathtt{\text{se-time:TimeDuration}}\mathrm{)}.\end{array}$$

se-time:TimeDuration which is used in the aforementioned DL expression is a simple specialization of the class owl-time:TimeDuration. Given the fact that the class owl-time:TimeDuration represents the duration of a temporal extent expressed as a number scaled by a temporal unit, we can model the class se-time:TimeDuration to also be able to provide both the temporal length along with the temporal unit of the duration as follows: $$\begin{array}{ll}\hfill & \mathtt{\text{se-time:TimeDuration}}⊑\mathtt{\text{owl-time:TimeDuration}}\\ \hfill & \mathit{where}:\\ \hfill & \mathtt{\text{owl-time:TimeDuration}}⊑\\ \hfill & \mathtt{\text{owl-time:TemporalDuration}}\sqcap \\ \hfill & =1\mathtt{\text{owl-time:numericDuration}}.\mathrm{(}\mathtt{\text{xsd:decimal}}\mathrm{)}\sqcap \\ \text{(5)}& \hfill & =1\mathtt{\text{owl-time:unitType}}.\mathrm{(}\mathtt{\text{owl-time:TemporalUnit}}\mathrm{)}.\end{array}$$

se-time:TemporalDistance is finally the temporal concept that is needed to represent an interval whose starting-time in terms of a date-time value is unknown and is set relative to another time-position, with a specific distance. More specifically, a temporal distance is used when we need to explain a temporal constraint for an event or an activity whose preconditions need to be captured during a specific period of time located at certain distance with the time stamp of the event. In the Time pattern, we have defined this class in the form of two separate temporal durations with the same ending point as follows: $$\begin{array}{ll}\hfill & \mathtt{\text{se-time:TemporalDistance}}⊑\\ \hfill & \mathtt{\text{se-time:TemporalEntity}}\sqcap \\ \hfill & \exists \mathtt{\text{owl-time:before}}.\mathtt{\text{se-time:Instant}}\sqcap \\ \text{(6)}& \hfill & =2\mathtt{\text{owl-time:hasDuration}}.\mathrm{(}\mathtt{\text{se-time:Duration}}\mathrm{)}.\end{array}$$

The object property owl-time:before indicates that the time instant is the target time that is temporally positioned not behind the two durations. Figure 2 represents how we define a temporal distance using two time durations temporally located before the given time-stamp t at which an event is expected to occur.

Fig. 2.

Representation of relative temporal distance calculated based on 2 time durations from a given time point t.

4.2. Geometry pattern

Apart from the temporal aspect, in a sensorized environment, specifically when there are mobile agents such as robots, the representational model needs to also cover the spatial aspects of entities including the topology of objects, rooms, etc. For instance, there are many situations where we need to localize objects relative to the physical position of the user. For this, encoding the spatial relations between entities is essential (e.g., “the kitchen is next to the living-room” or “the living room is located at the right side of the robot”.). For this, we have designed a pattern called Geometry5

⁵

https://w3id.org/smartenvironment/patterns/geometry.owl

relying on the upper level spatial-related ontology GeoSPARQL [5] and the Open Time and Space Core Vocabularies [13]. The OGC GeoSPARQL standard together with the Open Time and Space Core Vocabulary Specification (which provides qualitative directional relations) define an adequate vocabulary for representing geospatial data enabling qualitative spatial reasoning based on geometrical computations. The extension that we made upon these two ontologies is given in the following, where the prefixes se-geometry, geop and ns, refers to the Geometry pattern, GeoSPARQL ontology and the Open Time and Space Core Vocabularies, respectively:

se-geometry:SpatialObject  is subsumed by the class geop:Feature . According to GeoSPARQL, a feature represents a spatial object that has a geometry. We constrain the definition by saying that each feature is also in a spatial and directional relations with at least one another spatial object: $$\begin{array}{ll}\hfill & \mathtt{\text{se-geometry:SpatialObject}}⊑\mathtt{\text{geop:Feature}}\sqcap \\ \hfill & \exists \mathtt{\text{geop:hasGeometry}}.\mathtt{\text{geop:Geometry}}\sqcap \\ \hfill & \exists \mathtt{\text{se-geometry:hasSpatialRelation.se-geometry:}}\\ \text{(7)}& \hfill & \phantom{\exists \mathtt{\text{se-geometry:hasSpatialRelation.}}}\mathtt{\text{SpatialObject}}.\end{array}$$

se-geometry:hasSpatialRelation  is an object property subsuming all the basic RCC-8 [11] topological relations (e.g., geop:sfContains  ⊑ se-geometry:hasSpatialRelation, geop:sfOverlaps  ⊑ se-geometry:hasSpatialRelation, etc.). Furthermore, this object property subsumes a more specialized object property called se-geometry:hasDescriptiveSpatialRelation, which is defined to subsume all the qualitative spatial relations (including descriptive directional relations) in the Open Time and Space Core Vocabularies (such as ns:northOf, ns:nextTo, ns:near, etc.): $$\begin{array}{ll}\hfill & \mathtt{\text{se-geometry:hasDescriptiveSpatialRelation}}⊑\\ \text{(8)}& \hfill & \mathtt{\text{se-geometry:hasSpatialRelation}}.\end{array}$$ Where (due to the lack of space we have excluded the prefix se-geometry from all the following entities): $$\begin{array}{ll}\hfill & \top ⊑\forall {\mathtt{\text{hasSpatialRelation}}}^{-}.\mathtt{\text{SpatialObject}}\\ \hfill & \top ⊑\forall \mathtt{\text{hasSpatialRelation}}.\mathtt{\text{SpatialObject}}.\end{array}$$

4.3. Situation pattern

A “situation” illustrates a specific state of a “feature of interest” (e.g., the temperature of the living room is warm). By feature of interest we refer the concept defined in the SSN ontology as an object which is the interest of the observation process. Although states are usually time dependent, we decided to keep the representation of a situation as abstract as possible for the sake of generality. The concept of situation can be augmented with the concept of time in other patterns such as event-related patterns which are associated with temporal properties (see Section 4.8).

In order to represent various situations (related to feature of interests) in a smart environment we have designed the pattern Situation6

⁶

https://w3id.org/smartenvironment/patterns/situation.owl.

that contains two classes State and Situation where the individuals of the former express the individuals of the latter class. In the following, we describe the representational details of these two classes, where the prefixes se-situ, dul, ssn and sosa refer to the URIs of the pattern Situation, DULCE, SSN and SOSA7 ⁷

SOSA is one of the ontologies imported to SSN [17].

ontologies, respectively:

se-situ:State represent a class whose individuals are assumed to declaratively express a feature of interest regardless of how this expression is realized. According to DUL, the class dul:InformationObject allows us to define any piece of information such as a text, a word, etc., independently from how it is concretely realized. We found this definition suitable to be specialized and be the basis of the class se-situ:State as follows: $$\begin{array}{ll}\hfill & \mathtt{\text{se-situ:State}}⊑\mathtt{\text{dul:InformationObject}}\sqcap \\ \text{(9)}& \hfill & \exists \mathtt{\text{dul:expresses}}.\mathtt{\text{se-situ:Situation}}.\end{array}$$

se-situ:Situation is subsumed by the class dul:Situation . A situation in a smart environment can be more specialized and expressed by a specific property of a feature of interest (i.e., the class sosa:FeatureOfInterest, e.g., temperature of the living room) and its state (e.g., warm). Therefore, the definition of the class also includes three axioms that determine the relations between a feature of interest, its property and its relevant state. These axioms rely on the object property dul:isExpressedBy : $$\begin{array}{ll}\hfill & \mathtt{\text{se-situ:Situation}}⊑\mathtt{\text{dul:Situation}}\sqcap \\ \hfill & \exists \mathtt{\text{dul:isExpressedBy}}.\mathtt{\text{sosa:FeatureOfInterest}}\sqcap \\ \hfill & \exists \mathtt{\text{dul:isExpressedBy}}.\mathtt{\text{se-situ:State}}\sqcap \\ \text{(10)}& \hfill & \exists \mathtt{\text{ssn:forProperty}}.\mathtt{\text{ssn:Property}}.\end{array}$$

4.4. Sensing pattern

A sensing process is simply defined as the process of monitoring a specific property of a feature of interest using a sensing device. In order to represent such concept, we have designed the pattern Sensing8

⁸

https://w3id.org/smartenvironment/patterns/sensing.owl.

which is highly relying on the SSN ontology allowing us to model establishment of a sensing process. In the following we explain the classes as the specialization of concepts in SSN where the prefixes se-sensing, sosa and ssn refer to the URI of the pattern Sensing, SOSA (used in SSN) and the SSN ontologies, respectively:

se-sensing:Sensor is the specialization of the class sosa:Sensor. This class is designed to represent any sensing device used in an observation process with its own configuration that includes the sampling rate, data type of its outputs, etc. $$\begin{array}{ll}\hfill & \mathtt{\text{se-sensing:Sensor}}⊑\mathtt{\text{sosa:Sensor}}\sqcap \\ \hfill & \exists \mathtt{\text{sosa:madeObservation}}.\mathtt{\text{se-sensing:Observation}}\sqcap \\ \text{(11)}& \hfill & \exists \mathtt{\text{ssn:implements}}.\mathtt{\text{se-sensing:ConfigurationProcedure}}.\end{array}$$

se-sensing:Observation is subsumed by the class sosa:Observation and represents a monitoring process that has been setup to observe the behavior of a feature of interest. $$\begin{array}{ll}\hfill & \mathtt{\text{se-sensing:Observation}}⊑\\ \hfill & \mathtt{\text{sosa:Observation}}\sqcap \\ \text{(12)}& \hfill & \exists \mathtt{\text{sosa:madeBySensor}}.\mathtt{\text{se-sensing:Sensor}}\sqcap .\end{array}$$

It is worth mentioning that the information about the feature of interest, its properties, sensors’ results, etc., is provided by the definition of the class sosa:Observation given in the SSN ontology [17].

se-sensing:ConfigurationProcedure as a procedure allows us to define specific configuration required for each sensor to be used in an observation process. These configurations can include setting up the sampling rate of the sensor, the types of sensor data, etc., that can be defined according to the application. A very generic definition of this class is given in the following: $$\begin{array}{ll}\hfill & \mathtt{\text{se-sensing:ConfigurationProcedure}}⊑\\ \hfill & \mathtt{\text{sosa:Procedure}}\sqcap \\ \text{(13)}& \hfill & \exists \mathtt{\text{ssn:implementedBy}}.\mathtt{\text{se-sensing:Sensor}}.\end{array}$$

4.5. Place pattern

The meaning of a place in the context of smart environments is twofold. First, by a place we mean the entire smart environment which holds the deployment of a sensor network and might also be composed of several sections. The second meaning of a place refers to each section of the main place with a specific identity that can be as such seen as a location for different objects. Given this preliminary definition, the pattern Place9

⁹

https://w3id.org/smartenvironment/patterns/place.owl.

defines a place as a specialization of the class dul:PhysicalPlace with the following details, where the prefixes se-place, sosa, ssn and dul refer to the URI of the pattern Place, SOSA (used in SSN), SSN and DUL ontologies, respectively:

se-place:SmartEnvironment represents the entire environment as a physical place (i.e., dul:PhysicalPlace ) that is also assumed to hold a deployment of a sensor network. This class, therefore, has to also be subsumed by the class sosa:Platform, which according to SSN, provides a link to a deployment process (i.e. an instance of the class ssn:Deployment ): $$\begin{array}{ll}\hfill & \mathtt{\text{se-place:SmartEnvironment}}⊑\\ \hfill & \mathtt{\text{dul:PhysicalPlace}}\sqcap \\ \hfill & \mathtt{\text{sosa:Platform}}\sqcap \\ \text{(14)}& \hfill & \exists \mathtt{\text{dul:hasPart}}.\mathtt{\text{se-place:Section}}.\end{array}$$

The information required to define an instance of the se-place:SmartEnvironment as a platform used in a deployment process is provided by the class sosa:Platform in the SSN ontology [17].

se-place:Section represents spatial sections as parts of a smart environment. Each section defines a physical place that can accommodate different objects. Furthermore, each spatial section in a smart environment has a geometry and therefore, can be in spatial relations with the other sections. In order to reflect such properties, we have specialized the definition by adding a subsumption relation with the class se-geometry:SpatialObject defined in the Geometry pattern: $$\begin{array}{ll}\hfill & \mathtt{\text{se-place:Section}}⊑\mathtt{\text{dul:PhysicalPlace}}\sqcap \\ \hfill & \mathtt{\text{se-geometry:SpatialObject}}\sqcap \\ \hfill & \forall \mathtt{\text{dul:isLocationOf}}.\mathtt{\text{dul:PhysicalObject}}\sqcap \\ \text{(15)}& \hfill & \exists \mathtt{\text{dul:isPartOf}}.\mathtt{\text{se-place:SmartEnvironment}}.\end{array}$$

4.6. Network pattern

A network in a smart environment is defined as a system containing different types of devices such as nodes and node stations. By node, we mean a communication module that indicates either a sending or a receiving data module in a network. It is worth mentioning that the current design of the Network Pattern only supports the request/response communication paradigm.

Each node depending on its type can be a part of a node station representing another type of device that contributes in establishing a network. Each node station contains a node along with other things including a sensor, power supplies, batteries etc.

The whole process of a network set-up regardless of its exact technical details is represented by a non-physical concept called deployment. The pattern Network10

¹⁰

https://w3id.org/smartenvironment/patterns/network.owl.

unifies the representation of environment automation installations that can be found in different systems. In the following we give the definition of the concepts in the Network pattern, where the prefixes se-network and ssn refer to the Network pattern and the SSN ontology, respectively:

se-network:Deployment extends the class ssn:Deployment and explains a platform (e.g., a smart environment) upon which a network is deployed: $$\begin{array}{ll}\hfill & \mathtt{\text{se-network:Deployment}}⊑\mathtt{\text{ssn:Deployment}}\sqcap \\ \text{(16)}& \hfill & \exists \mathtt{\text{ssn:deployedSystem}}.\mathtt{\text{se-network:Network}}.\end{array}$$

The information related to the platform is inherited from the superclass ssn:Deployment in the SSN ontology [17].

se-network:Network is defined as a special type of system that has a deployment and is composed of a number of subsystems as follows: $$\begin{array}{ll}\hfill & \mathtt{\text{se-network:Network}}⊑\mathtt{\text{ssn:System}}\sqcap \\ \hfill & \exists \mathtt{\text{ssn:hasDeployment}}.\mathtt{\text{se-network:Deployment}}\sqcap \\ \text{(17)}& \hfill & \exists \mathtt{\text{ssn:hasSubsystem}}.\mathtt{\text{se-network:NodeStation}}.\end{array}$$

se-network:NetworkModule describes the network modules as a system in the form of node stations and nodes contributing in sending and receiving data within a sensor network in the context of a smart environment: $$\begin{array}{}\text{(18)}& \hfill & \mathtt{\text{se-network:NetworkModule}}⊑\mathtt{\text{ssn:System}}.\end{array}$$

se-network:NodeStation represents a network module categorized into two types of data sending module (i.e., se-network:SenderNodeStation) and data receiving module (i.e., se-network:ReceiverNodeStation). Each node station as a system ( ssn:System ) is located on a platform (e.g., as we will see in Section 4.7 a node holder) in the environment and holds a number of nodes as its sub-systems: $$\begin{array}{ll}\hfill & \mathtt{\text{se-network:NodeStation}}⊑\\ \hfill & \mathtt{\text{se-network:NetworkModule}}\sqcap \\ \text{(19)}& \hfill & \forall \mathtt{\text{ssn:hasSubSystem}}.\mathtt{\text{se-network:Node}}.\end{array}$$

se-network:Node likewise represents a network module that either in the form of se-network:DataReceiverNode or a se-network:DataSenderNode plays a role in transferring data: $$\begin{array}{}\text{(20)}& \hfill & \mathtt{\text{se-network:Node}}⊑\mathtt{\text{se-network:NetworkModule}}.\end{array}$$

se-network:DataReceiverNode as its name indicates, models a node (as part of a node station) which receives data coming from sensors (or more specifically from sender modules): $$\begin{array}{ll}\hfill & \mathtt{\text{se-network:DataReceiverNode}}⊑\mathtt{\text{se-network:Node}}\sqcap \\ \hfill & \exists \mathtt{\text{se-network:receivesDataFrom}}.\mathtt{\text{se-network:DataSender}}\\ \text{(21)}& \hfill & \phantom{\phantom{}}\mathtt{\text{Node}}.\end{array}$$

se-network:DataSenderNode also models a node which as a part of a node station sends sensor data (to a receiver): $$\begin{array}{ll}\hfill & \mathtt{\text{se-network:DataSenderNode}}⊑\mathtt{\text{se-network:Node}}\sqcap \\ \hfill & \exists \mathtt{\text{se-network:sendsDataTo}}.\mathtt{\text{se-network:DataReceiver}}\\ \text{(22)}& \hfill & \phantom{}\mathtt{\text{Node}}.\end{array}$$

se-network:ReceiverNodeStation defines a node station which holds a data receiver node as its part (sub-system): $$\begin{array}{ll}\hfill & \mathtt{\text{se-network:ReceiverNodeStation}}⊑\\ \hfill & \mathtt{\text{se-network:NodeStation}}\sqcap \\ \text{(23)}& \hfill & \forall \mathtt{\text{ssn:hasSubSystem}}.\mathtt{\text{se-network:DataReceiverNode}}.\end{array}$$

se-network:SenderNodeStation likewise represents a node station which is assumed to contain both a data sender node and also sensing devices (sensors): $$\begin{array}{ll}\hfill & \mathtt{\text{se-network:SenderNodeStation}}⊑\\ \hfill & \mathtt{\text{se-network:NodeStation}}\sqcap \\ \hfill & \forall \mathtt{\text{ssn:hasSubSystem}}.\mathtt{\text{se-network:DataSenderNode}}\sqcap \\ \text{(24)}& \hfill & \exists \mathtt{\text{ssn:hasSubSystem}}.\mathtt{\text{sosa:Sensor}}.\end{array}$$

se-network:receivesDataFrom is an object property providing the relation between a se-network:DataReceiverNode and a se-network:DataSenderNode. It is also the inverse of the object property se-network:sendsDataTo as follows (the prefix se-network has been excluded): $$\begin{array}{ll}\hfill & \top ⊑\forall \mathtt{\text{receivesDataFrom}}.\mathtt{\text{DataSenderNode}}\\ \hfill & \top ⊑\forall {\mathtt{\text{receivesDataFrom}}}^{-}.\mathtt{\text{DataReceiverNode}}\\ \text{(25)}& \hfill & \mathtt{\text{receivesDataFrom}}\equiv {\mathtt{\text{sendsDataTo}}}^{-}.\end{array}$$

4.7. Object pattern

The pattern Object11

¹¹

https://w3id.org/smartenvironment/patterns/object.owl

allows us to define objects based on their important features or abilities in the context of smart environments. The class dul:PhysicalObject provides a suitable representational basis for the objects’ taxonomy, which we have categorized into two types of smart objects and node holders. By smart object we refer to those objects that are the interest of an observation process (i.e., feature of interest). Due to the usual difficulties of installing sensors in a smart home, it is common to use some other objects (i.e. node holders) to host sensors. This separation provided by this pattern is specifically useful for other computational modules such as a configuration planner one of whose tasks is checking the status/functionality of sensors by sending a robot to their locations.

Each smart object (or a feature of interest) has at least a property to be observed. Another categorization of smart objects that has been considered in the object pattern, is about their mobility. An objects is considered as mobile only if its location as one of its properties, can change. In order to also be able to reflect the spatial relations between objects (e.g., the “fridge is connected to the cupboard”), or between an object and a place (e.g., “the bed is located at the left side of the bedroom”), it is required to define objects in a smart environment also as a se-geometry:SpatialObject defined in the pattern Geometry (see Section 4.2).

In the following, we represent the DL notations of each object type along with their properties, where the prefixes se-object, dul and ssn refer to the Object pattern, DUL and SSN ontologies, respectively:

se-object:Object as the main class of the Object pattern is subsumed by the class dul:PhysicalObject . The class definition is specialized according to the aforementioned description about different types of objects that we can have in a smart environment: $$\begin{array}{ll}\hfill & \mathtt{\text{se-object:Object}}⊑\mathtt{\text{dul:PhysicalObject}}\sqcap \\ \hfill & \mathtt{\text{se-geometry:SpatialObject}}\sqcap \\ \text{(26)}& \hfill & \exists \mathtt{\text{dul:hasLocation}}.\mathtt{\text{dul:PhysicalPlace}}.\end{array}$$

se-object:SmartObject as an object also considered as a feature of interest due to its property/properties which is/are the interest of an observation process. For this to be represented, we have defined a smart object also as a subclass of sosa:FeatureOfInterest which provides the relation between the object and its properties: $$\begin{array}{ll}\hfill & \mathtt{\text{se-object:SmartObject}}⊑\mathtt{\text{se-object:Object}}\sqcap \\ \text{(27)}& \hfill & \mathtt{\text{sosa:FeatureOfInterest}}.\end{array}$$

se-object:NodeHolder  also as an object is also considered as a platform that can host (hold) a device (a node) in a sensor network. In this way, we can differentiate between the objects, namely those that are the interest of the observation, and the objects which, as the holder of sensors, are used for sensor localization processes. $$\begin{array}{ll}\hfill & \mathtt{\text{se-object:NodeHolder}}⊑\mathtt{\text{se-object:Object}}\sqcap \\ \text{(28)}& \hfill & \mathtt{\text{sosa:Platform}}.\end{array}$$

se-object:MobileObject  defines a movable object that can be found at different places in the environment. In other words, there is an observable property of interest called “Location” for mobile objects: $$\begin{array}{ll}\hfill & \mathtt{\text{se-object:MobileObject}}⊑\mathtt{\text{se-object:Object}}\sqcap \\ \text{(29)}& \hfill & \exists \mathtt{\text{ssn:hasProperty}}.\mathtt{\text{se-object:Location}}\mathrm{,}\end{array}$$ where12 ¹²

According to the SSN ontology: sosa:ObservableProperty ⊑ ssn:Property .

$$\begin{array}{ll}\hfill & \mathtt{\text{se-object:Location}}⊑\mathtt{\text{sosa:ObservableProperty}}\sqcap \\ \hfill & \exists \mathtt{\text{ssn:isPropertyOf}}.\mathtt{\text{se-object:MobileObject}}.\end{array}$$

se-object:Agent  The class se-object:MobileObject can be further specialized and form another type of objects that are able to be proactive and participate in some events. The class se-object:Agent subsumed by the class dul:Agent allows us to represent inhabitants of an environment (e.g., humans, pets, etc.), that can be involved in an activity or an event (e.g., a person is an agent at home as he/she is often involved in various activities such as “sitting on couch”). Each agent can own, as its constituent, some objects (i.e., se-obeject:Object) whose location depends on the location of the agent. More specifically, a constituent can express other objects physically attached to the agent. However, a constituent does not need to be permanently attached to the agent. For instance, a chair might be deemed as a constituent as long as it is held by the agent (this relation to the constituent is borrowed from se-dul:Agent). $$\begin{array}{ll}\hfill & \mathtt{\text{se-object:Agent}}⊑\mathtt{\text{dul:Agent}}\sqcap \\ \hfill & \mathtt{\text{se-object:MobileObject}}\sqcap \\ \text{(30)}& \hfill & \forall \mathtt{\text{dul:isParticipantIn}}.\mathtt{\text{dul:Event}}.\end{array}$$

4.8. Event pattern

The pattern Event13

¹³

https://w3id.org/smartenvironment/patterns/event.owl

is an extension of the representation of events in DUL. In this extension we have defined two different types of events including a manifestation and complex event. By manifestation, we refer to those events that can be directly captured from sensor data and represent the occurrence of a smart home situation through a sensing process. However, the latter event type, as its name indicates, represents more complicated events whose occurrence depends on several preconditions [2]. Each precondition as such represents a specific situation assumed to be observed within an interval with a specific temporal distance to the event’s occurrence time. Furthermore, the pattern Time which is per se based on the OWL-Time ontology, can provide the required basis to represent the temporal properties of the smart environment to capture changes in the form of events or activities. In the following we provide the representation of each class where the prefixes se-event, se-time and dul refer to the patterns Event, Time and the DUL ontology:

Table 1

Linked modules in SmartEnv ontology

Module(1) Name	Module(2) Name	Axiom
Network	Place	$\mathtt{\text{se-network:Deployment}}⊑\exists \mathtt{\text{ssn:deployedOnPlatform}}.\mathtt{\text{se-place:SmartEnvironment}}$
Network	Object	$\mathtt{\text{se-network:NodeStation}}⊑\exists \mathtt{\text{sosa:isHostedBy}}.\mathtt{\text{se-object:NodeHolder}}$
Event	Object	$\mathtt{\text{se-event:Event}}⊑\exists \mathtt{\text{dul:hasParticipant}}.\mathtt{\text{se-object:Agent}}$
Event	Situation	$\mathtt{\text{se-event:Manifestation}}⊑\exists \mathtt{\text{dul:isEventIncludedIn}}.\mathtt{\text{se-situ:Situation}}$
Event	Situation	$\mathtt{\text{se-event:EventCondition}}⊑\exists \mathtt{\text{dul:isSettingFor}}.\mathtt{\text{se-situ:Situation}}$
Object	Event	$\mathtt{\text{se-object:Agent}}⊑\exists \mathtt{\text{dul:isParticipantIn}}.\mathtt{\text{se-event:Event}}$
Object	Place	$\mathtt{\text{se-object:Object}}⊑\exists \mathtt{\text{dul:hasLocation}}.\mathtt{\text{se-place:Section}}$
Object	Network	$\mathtt{\text{se-object:NodeHolder}}⊑\exists \mathtt{\text{sosa:hosts}}.\mathtt{\text{se-network:NodeStation}}$
Place	Network	$\mathtt{\text{se-place:SmartEnvironment}}⊑\exists \mathtt{\text{ssn:inDeployment}}.\mathtt{\text{se-network:Deployment}}$
Place	Object	$\mathtt{\text{se-place:Section}}⊑\exists \mathtt{\text{dul:isLocationOf}}.\mathtt{\text{se-object:Object}}$
Network	Sensing	$\mathtt{\text{se-network:SenderNodeStation}}⊑\exists \mathtt{\text{ssn:hasSubSystem}}.\mathtt{\text{se-sensing:Sensor}}$

se-event:Event as a general event class is subsumed by the class dul:Event . According to DUL, each event is expected to be observable at/within a dul:TimeInterval . On the other hand, the pattern Time provides a general representation for temporal entities including time interval and temporal distances. Furthermore, as mentioned in Section 4.7, an event can have an agent (a proactive object) as its participant. Given the aforementioned explanations, we define the class se-event:Event as follows: $$\begin{array}{ll}\hfill & \mathtt{\text{se-event:Event}}⊑\mathtt{\text{dul:Event}}\sqcap \\ \hfill & \forall \mathtt{\text{dul:hasParticipant}}.\mathtt{\text{dul:Agent}}\sqcap \\ \text{(31)}& \hfill & \exists \mathtt{\text{dul:isObservableAt}}.\mathtt{\text{se-time:Interval}}.\end{array}$$

In order to complete the above class definition, we have also defined the class se-time:Interval from the pattern Time as the sub class of the dul:TimeInterval : $$\begin{array}{}\text{(32)}& \hfill & \mathtt{\text{se-time:Interval}}⊑\mathtt{\text{dul:TimeInterval}}.\end{array}$$

se-event:Manifestation as a specialized version of the class se-event:Event indicates a situation (as we will see later, it is more specifically a se-situ:Situation) directly captured from sensor data: $$\begin{array}{ll}\hfill & \mathtt{\text{se-event:Manifestation}}⊑\mathtt{\text{se-event:Event}}\sqcap \\ \text{(33)}& \hfill & \exists \mathtt{\text{dul:isEventIncludedIn}}.\mathtt{\text{dul:Situation}}.\end{array}$$

se-event:ComplexEvent as a specialized version of the class se-event:Event and represents an event whose occurrence depends on capturing a number of preconditions represented as situations: $$\begin{array}{ll}\hfill & \mathtt{\text{se-event:ComplexEvent}}⊑\mathtt{\text{se-event:Event}}\sqcap \\ \text{(34)}& \hfill & \exists \mathtt{\text{dul:hasPrecondition}}.\mathtt{\text{se-event:EventCondition}}.\end{array}$$

se-event:EventCondition as a dul:Situation represents preconditions of a complex event (in the form of a situation: se-situ:Situation) which are needed to be captured within a specific temporal distance from the time-stamp of the complex event, where by temporal distance we refer to (se-time:TemporalDistance) (see Section 4.1): $$\begin{array}{ll}\hfill & \mathtt{\text{se-event:EventCondition}}⊑\mathtt{\text{dul:Situation}}\sqcap \\ \hfill & \exists \mathtt{\text{dul:isPreconditionOf}}.\mathtt{\text{se-event:ComplexEvent}}\sqcap \\ \hfill & \exists \mathtt{\text{dul:isObservableAt}}.\mathtt{\text{se-time:TemporalDistance}}\sqcap \\ \text{(35)}& \hfill & \exists \mathtt{\text{dul:isSettingFor}}.\mathtt{\text{dul:Situation}}.\end{array}$$

5. SmartEnv ontology – construction

In this section, we show how by integrating the 8 separate ontology module, the SmartEnv ontology,14

¹⁴

https://w3id.org/smartenvironment/smartenv.owl

representing different aspects of a smart environment, is constructed (see Fig. 1).

The SmartEnv ontology is formed as the result of importing all the 8 modules. The connection between each pair of modules is accomplished by specializing the definition of concepts in each module and then linking them together. For instance, the class se-network:Deployment used in the pattern Network is further specialized via the link to the class se-place:SmartEnvironment in the pattern Place: $$\begin{array}{ll}\hfill & \mathtt{\text{se-network:Deployment}}⊑\\ \hfill & \exists \mathtt{\text{ssn:deployedOnPlatform}}.\mathtt{\text{se-place:SmartEnvironment}}.\end{array}$$

All the specialized relations between modules illustrated in Fig. 1, are also listed in Table 1. For further clarification, in the following we exemplify the population process of SmartEnv for representation of a smart home as an example of a smart environment.

5.1. SmartEnv population

We have developed SmartEnv in E-care@home to be used as the representation model of the data that is gathered from a deployment test bed in Örebro University called Ängen, a sensorized apartment which provides functional facilities for the research development including Ambient Intelligence (AMI) solutions. One of the relevant applications of context reasoning in E-care@home is Activity recognition of Daily Living (ADL) as well as monitoring of other features of interest such as the physiological and health-related parameters of the users. For this, we have equipped Ängen with a number of both environmental15

¹⁵

Due to the ethical concerns, we have avoided using cameras in E-care@home.

(e.g., pressure sensor, light sensor, motion sensor, etc.) and medical sensors. Before running the observation process, we need to initialize the ontology with all the equipments including the network modules, objects, their locations as well as the activities or events that we are interested to recognize. In our preliminary set-up we equipped Ängen with 14 different sensors at different sections (rooms) of Ängen. The following axioms are examples of statements used in SmartEnv population. For the sake of declarativity, these examples are either in the form of a unary predicate (class instantiation) or a binary predicate (positive object property assertions):

It is worth mentioning that apart from the A-box, the population also includes a process of extension of the T-box in order to define more specialized subclasses of SmartEnv. We first define Ängen in the ontology as a smart environment which as a living place of an elderly person is composed of one living room, 2 bedrooms, one bathroom and one kitchen. $$\begin{array}{ll}\hfill & \mathtt{\text{* Smart Environment Description:}}\\ \hfill & \mathtt{\text{se-place:SmartEnvironment(}}\mathtt{\text{ä}}\mathtt{\text{ngen)}}.\\ \hfill & \mathtt{\text{LivingRoom}}⊑\mathtt{\text{se-place:Section}}\\ \hfill & \mathtt{\text{BedRoom}}⊑\mathtt{\text{se-place:Section}}\\ \hfill & \mathtt{\text{BathRoom}}⊑\mathtt{\text{se-place:Section}}\\ \hfill & \mathtt{\text{Kitchen}}⊑\mathtt{\text{se-place:Section}}\\ \hfill & \mathtt{\text{LivingRoom(livingroom1)}}.\\ \hfill & \mathtt{\text{Kitchen(kitchen1)}}.\\ \hfill & \mathtt{\text{BathRoom(bathroom1)}}.\\ \hfill & \mathtt{\text{BedRoom(bedroom1)}}.\\ \hfill & \mathtt{\text{BedRoom(bedroom2)}}.\\ \hfill & \mathtt{\text{dul:hasPart(}}\mathtt{\text{ä}}\mathtt{\text{ngen, livingroom1)}}.\\ \hfill & \mathtt{\text{dul:hasPart(}}\mathtt{\text{ä}}\mathtt{\text{ngen, kitchen1)}}.\\ \hfill & \mathtt{\text{dul:hasPart(}}\mathtt{\text{ä}}\mathtt{\text{ngen, bathroom1)}}.\\ \hfill & \mathtt{\text{dul:hasPart(}}\mathtt{\text{ä}}\mathtt{\text{ngen, bedroom1)}}.\\ \hfill & \mathtt{\text{dul:hasPart(}}\mathtt{\text{ä}}\mathtt{\text{ngen, bedroom2)}}.\end{array}$$

Given the structure of the environment, we continue the population process with the objects, their properties and locations. Due to the lack of space, we focus only on a single object (a couch) and show how we represent it’s location with a pressure sensor attached to it to monitor the couch occupancy: $$\begin{array}{ll}\hfill & \mathtt{\text{* Object Description:}}\\ \hfill & \mathtt{\text{Couch}}⊑\mathtt{\text{se-object:SmartObject}}\\ \hfill & \mathtt{\text{Couch(couch1)}}.\\ \hfill & \mathtt{\text{ssn:Property(pressure)}}.\\ \hfill & \mathtt{\text{ssn:hasProperty(couch1, pressure)}}.\\ \hfill & \mathtt{\text{dul:hasLocation(couch1, livingroom1)}}.\end{array}$$

Next, we define the network such as its deployment in Ängen, nodes and node stations: $$\begin{array}{ll}\hfill & \mathtt{\text{* Network Description:}}\\ \hfill & \mathtt{\text{se-network:Network(network1)}}.\\ \hfill & \mathtt{\text{se-network:Deployment(deployment1)}}.\\ \hfill & \mathtt{\text{ssn:inDeployment(}}\mathtt{\text{ä}}\mathtt{\text{ngen, deployment1)}}.\\ \hfill & \mathtt{\text{se-network:NetworkModule(nodeStation1)}}.\\ \hfill & \mathtt{\text{ssn:hasSubSystem(network1, nodeStation1)}}.\end{array}$$

The network is deployed in order to implement the observation process which is initialized by assigning the sensors to the feature of interests, or in other words, smart objects with their properties, which in our case is the pressure on the couch: $$\begin{array}{ll}\hfill & \mathtt{\text{* Sensing Description:}}\\ \hfill & \mathtt{\text{PressureSensor}}⊑\mathtt{\text{se-sensing:Sensor}}\\ \hfill & \mathtt{\text{PressureSensor(sensor1)}}.\\ \hfill & \mathtt{\text{ssn:hasSubSystem(nodeStation1, sensor1)}}.\\ \hfill & \mathtt{\text{se-sensing:Observation(observation1)}}.\\ \hfill & \mathtt{\text{sosa:hasFeatureOfInterest(observation1, couch1)}}.\\ \hfill & \mathtt{\text{sosa:observedProperty(observation1, pressure)}}.\end{array}$$

Activities or events as the realization of situations in the environment need to be defined in the ontology. For this, we first define the two possible situations related to the couch and its pressure property: $$\begin{array}{ll}\hfill & \mathtt{\text{* Situation Description:}}\\ \hfill & \mathtt{\text{se-situ:Situation(couchPressed)}}.\\ \hfill & \mathtt{\text{dul:isExpressedBy(couchPressed, couch1)}}.\\ \hfill & \mathtt{\text{dul:isExpressedBy(couchPressed, on)}}.\\ \hfill & \mathtt{\text{se-situ:Situation(couchUnPressed)}}.\\ \hfill & \mathtt{\text{dul:isExpressedBy(couchUnPressed, couch1)}}.\\ \hfill & \mathtt{\text{dul:isExpressedBy(couchUnPressed, off)}}.\end{array}$$

Then observation processes associated with an inference process is able to report the timestamps at which an event or whatever that can change the situation of the environment, occur. For this to be possible, we have to define activities (e.g., sitting on the couch) in the ontology based on the given situations. Assuming the sitting activity is realized when the pressure sensor attached to the couch is triggered, the ontology is populated as follows: $$\begin{array}{ll}\hfill & \mathtt{\text{* Event Description:}}\\ \hfill & \mathtt{\text{Sitting}}⊑\mathtt{\text{se-event:ComplexEvent}}\\ \hfill & \mathtt{\text{SittingCondition}}⊑\mathtt{\text{se-event:EventCondition}}\\ \hfill & \mathtt{\text{dul:hasPrecondition(Sitting, SittingCondition)}}.\\ \hfill & \mathtt{\text{dul:isSettingFor(SittingCondition, couchPressed)}}.\\ \hfill & \mathtt{\text{se-time:TemporalDistance(distance)}}.\\ \hfill & \mathtt{\text{se-time:TimeDuration(duration1)}}.\\ \hfill & \mathtt{\text{se-time:TimeDuration(duration2)}}.\\ \hfill & \mathtt{\text{owl-time:numericDuration(duration1, 0)}}.\\ \hfill & \mathtt{\text{owl-time:numericDuration(duration2, 0)}}.\\ \hfill & \mathtt{\text{owl-time:hasDuration(distance, duration1)}}.\\ \hfill & \mathtt{\text{owl-time:hasDuration(distance, duration2)}}.\\ \hfill & \mathtt{\text{dul:isObservableAt(SittingCondition, distance)}}.\end{array}$$

The mentioned above axioms define a temporal distance (i.e., distance) which is defined based on two time durations (duration1 and duration2 both with length zero (i.e., they are referring to the same time point t (see Fig. 2)). In other words, the precondition of the event sitting needs to be captured exactly when the sitting activity occurs. Once the pressure sensor is triggered we immediately (with no delay) infer the sitting event.

Given the populated ontology as explained above we can start observing the environment where each sensor is assigned to a feature of interest to detect changes and consequently recognize the related events/activities. In order to map the stream of sensor data into our representation model, we need a reasoner. Depending on the features of the domain, the level of uncertainty and complexity, we may apply different reasoning method (monotonic or non-monotonic). Due to the inherent uncertainty of sensor systems, we decided to apply a non-monotonic reasoner which is based on stable model semantics [16]. The details how the ontological axioms are converted to the rules understandable by the non-monotonic reasoner (AnswerSet Solver) which is out of the scope of this paper, can be found in [3].

The mentioned above population process can be extended in order to cover all the objects, sensors and the equipments existing in the environment. During one of our test runs, the SmartEnv ontology was first populated with the static information about the Ängen set-up which totally resulted in 172 specialisations (i.e. subclasses) of the ODP classes, and 203 individuals. Given this instantiated ontology, the observation process is then able to feed the ontology with the instances of manifestations corresponding to the changes detected in sensor outputs. For instance, monitoring a person doing different sorts of activities (such as cooking, watching TV, etc.) in Ängen resulted about 200 additional individuals, describing the situations captured from the environment. These individuals, which are related to different classes including the manifestation and the subclasses of the complex event class, makes the ontology reasoning-ready for different purposes, such as configuration planning or context recognition in multi-inhabitant environments. The example scenario outlined in Section 3 is only one among a multitude of activities that are relevant to detect in the context of the E-care@home project.

6. Discussion & future work

In this paper, we proposed a network of ontology patterns targeting the representational aspects (such as sensing process, network configuration, objects’ taxonomy, event representation, topological representation, etc.) of smart environments. The final ontology is formed by integrating the proposed patterns representing a smart environment. In order to avoid the complex design issues as the result of dependencies between the representational aspects, we have applied the ODP approach as an incremental methodology in designing ontologies. The ODP approach allows us to start by first creating general and small patterns for each aspect and then link them together. In this way, regardless of its size, the ontology becomes flexible for further updates with the least possible change cost.

The majority of the ontology modules constituting the SmartEnv ontology are mainly relying on SSN and DUL ontologies, however with a number of specializations, either in the form of extension of class hierarchies or updating links between concepts.

However, reusing existing vocabularies from SSN or DUL was not a straightforward process. There are a number of generic concepts whose definitions make them a suitable basis for other context-related concepts. For instance, the class dul:InformationObject ) which is used as the super class of the class se-situ:State. Finding such generic concepts can be time consuming. A means to support the use of existing vocabularies (including both concepts and object properties) and/or patterns without the need for creating or importing such classes would ease the process to a considerable extent.

The network of ontology patterns may in the future be equipped with more patterns required to cover other aspects of a smart environment. One aspect that we are currently investigating concerns the habits of the users (inhabitants) whose definitions (in terms of preconditions) are not necessarily clear at the time when we populate the ontology. For this, as a next step, we may either generalize the event pattern or add a new ontology module to capture such concepts that allow us to relate some activities of the user to his/her habits based on their repetitions.