http://www.diva-portal.org

This is the published version of a paper published in Semantic Web.

Citation for the original published paper (version of record):

Alirezaie, M., Hammar, K., Blomqvist, E. (2018)SmartEnv as a Network of Ontology PatternsSemantic Web

Access to the published version may require subscription.

N.B. When citing this work, cite the original published paper.

Permanent link to this version:http://urn.kb.se/resolve?urn=urn:nbn:se:oru:diva-67889

Semantic Web 0 (0) 1 1IOS Press

SmartEnv as a Network of Ontology PatternsMarjan Alirezaie a,∗, Karl Hammar b, Eva Blomqvist c

a Center for Applied Autonomous Sensor Systems, Örebro University, Sweden - marjan.alirezaie@oru.seb SICS - East Swedish ICT, Linköping, Sweden, and Jönköping University, Sweden - karl@karlhammar.comc SICS - East Swedish ICT, Linköping, Sweden - eva.blomqvist@liu.se

Abstract. In this article we outline the details of an ontology, called SmartEnv, proposed as a representational model to assistthe development process of smart (i.e., sensorized) environments. The SmartEnv ontology is described in terms of its modulesrepresenting different aspects including physical and conceptual aspects of a smart environment. We propose the use of theOntology Design Pattern (ODP) paradigm in order to modularize our proposed solution, while at the same time avoiding strongdependencies between the modules in order to manage the representational complexity of the ontology. The ODP paradigmand related methodologies enable incremental construction of ontologies by first creating and then linking small modules. Mostmodules (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 patternshave been submitted to the ODP portal and are available on-line at stable URIs.

Keywords: Smart Environments, SmartEnv Ontology, Ontology Design Pattern, Semantic Sensor Network

1. Introduction

Applications of sensorized environments thatprovide domestic monitoring and cognitive assistanceservices for their inhabitants/users are increasing.An example of such an application is healthcare monitoring and services, where patientsare being monitored and cared for in their ownliving environment. In order to support the useof artificial intelligence techniques for automatingthe provision of these services, it is necessary todescribe the capabilities of the various aspects of suchenvironments. These descriptions include physicalaspects (e.g., the structure of the environment, sensornetwork setting or entities), as well as conceptualaspects (e.g., events or activities of the users), andcan be modeled in ontologies. According to [1], thereis a general list of questions about the inhabitants ofsmart homes (as an example of smart environments),which many of the suggested knowledge models in theliterature aim to address. This list includes questions

*

about the location of the inhabitant, the activity thatthe inhabitant carries out, the intention behind theactivity, 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 levelof generality as well as their reasoning efficiency.

Due to the dependencies between theaforementioned features, such an ontology can easilybecome large and complex; moreover, it may needto be updated over time, e.g., when sensors/robotswith new kinds of features are added to (or removedfrom) the environment, or when the monitoringrequirements of the environment change. Additionally,when we use ontologies in a system that requiresnear real-time reasoning and reactions by the system,the reasoning complexity is an essential parameterof the ontologies. For these reasons, we proposethe use of a network of ontology modules, whichis called SmartEnv and could be considered as aset of interlinked content Ontology Design Patterns(ODPs) [15] due to their generic applicability tothe domain and our deliberate effort to minimizetheir ontological commitments, while maintaining

1570-0844/0-1900/$35.00 c© 0 – IOS Press and the authors. All rights reserved

2 Alirezaie et al. / SmartEnv as a Network of Ontology Patterns

functionality. According to the principles of ODPmodeling, the ontological commitments should beminimized by first creating small modules, and thenlinking them together, instead of designing a largemonolithic ontology from scratch as a comprehensiverepresentation of the entire domain [16].

Before going to the details of our proposedontology, in section2, we first motivate how andwhy our suggested SmartEnv ontology is requiredand compare the available ontologies with the givenrequirement list. In section 3, we shortly introduce theproject whose requirements led us to the developmentof the SmartEnv ontology in the form of a networkof ontology modules. In section 4, we explain the8 ontology patterns (modules) used in SmartEnvontology. The SmartEnv ontology, as the result ofspecializing the relations between modules along withits application is presented in section 5. A discussionon our approach is given in section 6, where the paperis concluded by giving remarks concerning futuredevelopments.

2. Motivation and Background

2.1. Representational Requirements

During the requirements analysis process, weconsidered a number of (conceptual) aspects ofsmart environments to be covered in the ontologies.For further clarification, some aspects are explainedbased on a set of high-level competency questions(CQs) (only examples are given here due to spacerestrictions). The detailed CQs for each of the patternscan be found inside the ODP itself, as annotations ofits 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 whythe environment is sensorized. A representation modelis required to answer questions such as what can beobserved by a certain sensor? To what object is asensor attached? What is the location of the object, andwhat does the sensor measure? Can the sensor or itsholding object move?

Agents Agents (e.g, inhabitants of a home) arethe main characters whose activities, locations, ormore specific parameters such as safety and healthare usually the main reason behind any observationprocess in a smart environment. A representationmodel is required to answer questions such as what are

the possible activities of the agent? Can the agent betargeted by sensors? Where is the agent now? What isthe agent doing now?

Activities/Events Any changes in a smartenvironment are represented in the form of an eventor an activity. Questions such as when an event hasoccurred, or why such event was recognized, can beanswered by representing activities in terms of theirpreconditions.

Objects Physical objects are also directly orindirectly the target of the observation process in orderto recognize activities in a smart environment. Werepresent objects to answer questions about their state(being in a specific situation), locations, or the eventsor activities in which they are involved.

Network set-up In order to set-up a smartenvironment a sensor network deployment related tothe observation process, is indispensable. A networkrepresentation model is used to answer any questionregarding the hardware and software configuration ofa network, its components and their locations.

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

Temporal aspect Similar to spatial aspects, thetemporal aspects are the main basis of an observationprocess. A temporal representation model is used toanswer questions such as when the occurrence ofan activity is realized. It also allows us to defineactivities based on the temporal relations with theirpreconditions.

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

2.2. Overview of Sensor-Related Ontologies

Sensing and in general sensor-related detailsof smart environments as one of their integralcomputational aspects has been widely studied in theliterature [2,18,1]. Although the “re-usability” hasalways been advertised as an essential features ofontologies, there is a large number of adhocly designedsensor-related ontologies in the literature, many ofwhich are not even available online. This numberincreases when the idea behind the design of these

Alirezaie et al. / SmartEnv as a Network of Ontology Patterns 3

ontologies is getting more specific, for example foractivity recognition purposes [1]. One important taskin designing ontologies for smart environments is toidentify the activities of an agent in the environment,for instance in the case of a smart home, thesecould be activities such as “sleeping”, “watchingTV”, “cooking” etc. In addition to being able toidentify an activity, we also need to represent thetime and location where the activity is carried out.Ontologies suggested for recognizing daily activitiesare rarely relying on upper-level ontologies [19,20], which usually result in a lower reusability.Concerning the re-usability of ontologies, [3] proposesa top-level ontology that provides a formal andgeneric representation of activities sharable betweendifferent domains. However, apart from the activityrepresentation, in the aforementioned work there isno representation of the other aspects of a smartenvironment. With the focus on smart environments,[4] introduces the Casas Ontology (COSE) being ableto represent sensors, buildings, occupants and humanactivities, which is publicly available. However, thereare no representation details provided to show thatthe offered light-weight model relies on availableupper-level ontologies, or even that it is possible toalign it to such ontologies. Furthermore, both thespatial and temporal aspects are poorly representedand there is no support for the representation of thesensor network at all. Likewise, the COBRA-ONTontology, which also provides a representationalmodel for pervasive computing environments, lacks analignment with an upper level ontology, and does notcontain an explicit temporal representation model [5].Two other ontologies related to context-awarenessin sensorized environments are SOUPA [7] andDogOnt [8]. Although there are a number of workingapplications of these ontologies, both are lacking somerepresentational aspects. For instance, in SOUPA, weare not able to define devices (as part of the networkmodules) and their configurations and functionalities.DogOnt also provides a limited object representationwith no support for their dynamic features. Comparingwith the above mentioned ontologies, the ontologyintroduced in [6] is more complete in terms oflocalisation and temporality. It also considers therequired representational basis for environmentalchanges (e.g., events). However, what is missing isagain an alignment to an upper level ontology, andalthough it has been claimed that the ontology is perse generic enough to be used in different domains, it

is not obvious how it relates to commonly used upperontologies and standards.

There are also few approaches in the literatureproposing more general ontologies for IoT-relateddomains, regardless of their applications. TheSemantic Sensor Network (SSN) ontology [21] isintroduced as a generic and reusable knowledge modelfor sensor-related environments. The first version ofSSN1 was relying on the upper level ontology DUL2

and took a remarkable step towards the reusabilityof ontologies [21]. However, the representationaldetails in the first version of SSN could cause anexcessive processing time at query time. That iswhy some lighter instantiations of SSN, such asIoT-Lite have been introduced [9]. Due to its lightweight (in terms of expressivity), this ontology allowsus to define some relevant IoT-related concepts tosupport interoperability of heterogeneous sensor data.Although the vocabularies used in IoT-Lite are alignedwith their generalized counterparts, the representationof the key concepts in sensor-related environment (i.e.,those discussed in section 2.1 such as sensor, actionand observation) are limited [26].

Regarding the load of the representational detailsin SSN bringing up excessive processing time, theW3C Spatial Data on the Web Working Group hasproposed an updated version of SSN3 as a W3Crecommendation with no import of the DUL ontologyas its basis [12]. The new version of SSN providesa basis for some required concepts (e.g., sensor,observation, platform, etc.) in representing a smartenvironment. Although the new SSN is not based onDUL, a specific alignment module is also provided,which can be used if needed.

In this paper, we propose a generic ontology forsmart (sensorized) environments (with at least oneinhabitant/user) based on SSN. There are a numberof works in the literature inspired by the old versionof SSN [22,23]. However, since the basis of ourproposed ontology is the new version of SSN, wedo not go through the details of old-SSN-inspiredwork, as their differences with our proposed ontologywill be similar to the differences between the oldand new version of SSN. In our design, we rely onthe general concepts given in the new version of theSSN ontology and extend/specialize them in order tocover all the representational requirements given in

1https://www.w3.org/2005/Incubator/ssn/ssnx/ssn2DOLCE Ultra Light: www.ontologydesignpatterns.org/ont/dul/DUL.owl3https://www.w3.org/TR/vocab-ssn/

4 Alirezaie et al. / SmartEnv as a Network of Ontology Patterns

section 2.1. This extension, which will be explained inthe remaining sections of the paper, is focusing on bothstatic (such as objects, deployment or network set-up)and dynamic (such as temporal and spatial, activity andevent) concepts.

Regarding the design pattern approach, the ODPtechniques underpinning our approach make it similarto the work proposed in [25], which introduces ageneric Stimulus-Sensor-Observation ontology designpattern for representing observation-based data on theSemantic Web, although their focus is much morelimited. Moreover, the focus of the work presentedin [26] is on designing a core domain IoT ontologyand proposes a reasonable categorization of highlevel concepts. What makes our approach different,however, is first its more comprehensive coverageof concepts, and also the provided representationaldetails of the aforementioned aspects of a smartenvironment.

As said above, our proposed ontology can be seenas a network of modules whose basis are extractedfrom SSN. Each module is represented in the formof a pattern, as general as possible with the leastpossible dependencies on the other patterns. Doingso helps us to realize the main links in the eventualontology. We can consequently make a stable and atthe same time flexible network of concepts that canbe updated with the minimum change propagation onthe entire ontology, and where individual patterns canalso be used in isolation for some specific reasoningtasks (e.g., in order to avoid issues with reasoningcomplexity or clashes in the relations to foundationalontologies).

3. Use Case: Ecare@Home Project

In order to set the stage and explain the backgroundof our work, we will here briefly describe the projectwhere the ontology modules were developed. Wealso introduce a reasoning example that will be usedthroughout the paper to exemplify the use of themodules.

The E-care@home project aims at providing acomprehensive IoT-based healthcare system, includingstate of the art communication protocols and high-levelanalysis of data from various types of sensors,combined with information from personal healthrecords, and other background information, bothgeneric and specific to a person. The main scenario isthat of an elderly person who has some specific needs

and potential medical conditions, but is still living athome. In order to increase the safety of the person,and reduce the frequency of appointments needed ata care facility, the patient and caregivers have agreedto fit the patients home with some sensors and acommunication device, such as a tablet with a specificapplication installed. The challenge is to integrate andreason over all the information both from the sensorsand the medical records at once, and derive the mostlikely conclusion, e.g., the current situation that thepatient is in, the cause of some events, and the bestaction for the system to take next. This is quite atypical scenario for sensor-based monitoring systems,hence, it has enabled us to generalise our specificrequirements (mentioned earlier in section 2.1) andprovide a solution that we believe is highly reusableby other systems, regardless of the domain where suchsituation awareness and monitoring is required.

3.1. A Sample Scenario

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

Let us assume we are monitoring a patientwith severe COPD (Chronic Obstructive PulmonaryDisease). Since one effect of the disease is lungfunction reduction, patients tend to have a hard timeto remain active. A reduced level of activity in theirdaily lives may be an indication of a worsening ofthe condition. The level of activity is furthermore seenas an important contextual background informationfor interpreting readings from medical sensors andself assessments, such as perceived breathlessnessor oxygen saturation. Therefore one task of theE-care@home system is to create a time-line of thepatient’s daily activities. One possible (simplified)example of such an inference, based on sensorobservations could be that the patient is watching TVas long as the person is seated on the couch in theliving room and the TV is on. For performing thisinference, we need at least two sensors attached toobjects located in the living room: one that registersthe coach occupancy and one that records the on/offstatus of the TV. Moreover, we need information aboutthe patient, as an actor (or agent) whose activities canbe observed through sensing processes implementedby these sensors. We also need several layers ofabstraction in terms of observed events, i.e., bothlow-level manifestations, such as that the TV is on,and complex events that are composed of (sequencesor sets) of such manifestations, such as the notion

Alirezaie et al. / SmartEnv as a Network of Ontology Patterns 5

of watching TV, as well as reasoning mechanisms toderive the latter from the former.

4. SmartEnv Ontology – Overview

In the previous section, we discussed the existingontologies that have inspired our work, and the reasonswhy none of them cover all the requirements. In thissection, we briefly provide an overview of the overallontology network that we propose as a solution tothis problem. Figure 1 represents an abstract overviewof the overall ontology in terms of its modules andtheir relations. The figure is somewhat simplified inorder to be more readable, e.g., most inverse relationshave been omitted as well as some of the alignmentsto external classes and properties. In the followingsection we then go into details of the individualmodules and their axiomatization.

The SmartEnv ontology4 is composed of 8 ontologymodules which are publicly available. Each moduleis representing a single principal feature of a smartenvironment. The requirements for the modules ofthe SmartEnv ontology are formalized based on thereasoning requirements, derived from the high-levelrequirements presented earlier in section 2.1. Aswe will see in the following subsections, most ofthe modules are extending other ontologies suchas SSN and DUL. The name of the concepts andrelations taken from the aforementioned ontologies arerepresented in the form of shortened IRI referring tothe OWL definition of the concepts.

In this section we only provide the DescriptionLogic (DL) notations of the classes and properties.To further clarify, in section 5.1 we provide examplesshowing how these DL notations are used to populatethe SmartEnv ontology.

4.1. Time Pattern

The pattern Time5 represents any temporal entitiesthat we may use to represent things in a smartenvironment. In order to represent the temporal aspectof such environments, we have designed the patternTime which is mainly an extension of the OWL-Timeontology, a W3C recommendation for describingtemporal concepts [10].

4https://w3id.org/smartenvironment/smartenv.owl5https://w3id.org/smartenvironment/patterns/time.owl

The OWL-Time ontology provides preciserepresentation for temporal entities in the form ofeither time instant or temporal duration. In the contextof smart environments, we, however, require morespecific temporal representation that allows us to alsorepresent relative temporal distance (for example,between an event and its preconditions). By relative,we mean the temporal distance is indicated withoutknowing the specific timestamps located within aspecific distance to a given time point (e.g., the eventcooking is recognized at time-stamp t only if weknow at least between 20 to 10 seconds before that,someone has been around the stove, regardless of theexact time t).

For this, we have extended the OWL-Time ontologyand introduce it as our Time ontology pattern. Inthis pattern, we define three types of temporal entitiesrepresenting time instants, time intervals and temporaldistances. In the following, we go to the details of theclasses, where the two prefixes owl-time and se-time

refer to the URIs of the OWL-Time ontology, and ourTime ontology pattern, respectively:

se-time:TemporalEntity is subsumed by theclass owl-time:TemporalEntity:

se-time:TemporalEntity v (1)

owl-time:TemporalEntity

It is also equivalent to the union of the threeclasses se-time:Instant, se-time:Interval andse-time:TemporalDistance as follows:

se-time:TemporalEntity ≡ (2)

se-time:Instant t se-time:Interval t

se-time:TemporalDistance

se-time:Instant According to OWL-Time, aninstance of the time instant is assumed to representa temporal entity with zero extent or duration. Thesubsumption of this class in our Time pattern, i.e.,se-time:Instant, is specialized to also include adate-time-stamp value supposed to be modeled by thisclass as follows, where the prefix xsd also refers tohttp://www.w3.org/2001/XMLSchema:

se-time:Instant v owl-time:Instant u (3)

se-time:TemporalEntity u

= 1 owl-time:inXSDDateTimeStamp.(xsd:dateTimeStamp)

6 Alirezaie et al. / SmartEnv as a Network of Ontology Patterns

Geometry

se-geometry:SpatialObject

geop:Geometry

geop:hasGeometry

se-object:Agent⊑ dul:Agent

se-object:Object⊑ dul:Object

se-object:NodeHolder⊑ sosa:Platform

se:object-SmartObject

Object

se-object:MobileObject

Place

se-place:SmartEnvironment⊑ dul:PhysicalPlace⊑ sosa:Platform

dul:hasPart

dul:hasLocation

hasSpatialRelation

Network

Node

NodeStation

ssn:hasSubSystem

Deployment⊑ ssn:Deployment

NetworkModule⊑ ssn:System

ssn:hasDeployment

se-place:Section⊑ dul:PhysicalPlace

ssn:inDeployment

Situation

Situation⊑ dul:Situation

sosa:FeatureOfInterest ssn:Propertyssn:hasProperty

State⊑ dul:InformationObject

dul:isExpressedBy

dul:isExpressedByssn:forProperty

sosa:hosts

Network⊑ ssn:System

ssn:hasSubSystem

Event

Event⊑ dul:Event

Manifestation ComplexEvent

EventCondition

dul:hasPrecondition

dul:isEventIncludedIndul:isSettingFor

dul:hasParticipant

Time

Interval⊑ owl-time:Interval

TemporalDistance

Interval⊑ owl-time:Interval⊑ dul:TimeInterval

TemporalEntity⊑ owl-time:TemporalEntity

dul:isObservableAt

dul:isObservableAt

Sensing

Observation⊑ sosa:Observation

ConfigurationProcedure⊑ sosa:Procedure

Sensor⊑ sosa:Sensor

ssn:implements

sosa:madeObservation

sosa:hasFeatureOfInterestsosa:observedProperty

SenderNodeStation

ssn:hasSubSystem

Ontology Pattern SubSumption

Object Property (based on existential

restriction or cardinality)

OWL Class

External Class

Legend

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

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:

se-time:Interval v owl-time:Interval u (4)

se-time:TemporalEntity u

= 1 owl-time:hasBeginning.(se-time:Instant) u

= 1 owl-time:hasDuration.(se-time:TimeDuration)

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:

se-time:TimeDuration v owl-time:TimeDuration (5)

where :

owl-time:TimeDuration v

owl-time:TemporalDuration u

= 1 owl-time:numericDuration.(xsd:decimal) u

= 1 owl-time:unitType.(owl-time:TemporalUnit)

se-time:TemporalDistance is finally thetemporal concept that is needed to represent an intervalwhose starting-time in terms of a date-time value isunknown and is set relative to another time-position,with a specific distance. More specifically, atemporal distance is used when we need to explain atemporal constraint for an event or an activity whosepreconditions need to be captured during a specificperiod of time located at certain distance with thetime stamp of the event. In the Time pattern, we havedefined this class in the form of two separate temporaldurations with the same ending point as follows:

se-time:TemporalDistance v (6)

se-time:TemporalEntity u

∃ owl-time:before.se-time:Instant u

= 2 owl-time:hasDuration.(se-time:Duration)

Alirezaie et al. / SmartEnv as a Network of Ontology Patterns 7

(event is captured at time t)t

TimeDuration #1

TimeDuration #2

TemporalDistance to t

t-duration#1t-duration#2

Fig. 2. Representation of relative temporal distance calculated basedon 2 time durations from a given time point t.

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

4.2. Geometry Pattern

Apart from the temporal aspect, in a sensorizedenvironment, specifically when there are mobile agentssuch as robots, the representational model needs toalso cover the spatial aspects of entities includingthe topology of objects, rooms, etc. For instance,there are many situations where we need to localizeobjects relative to the physical position of the user. Forthis, encoding the spatial relations between entities isessential (e.g., “the kitchen is next to the living-room”or “the living room is located at the right side of therobot”.). For this, we have designed a pattern calledGeometry6 relying on the upper level spatial-relatedontology GeoSPARQL [27] and the Open Time andSpace Core Vocabularies [10]. The OGC GeoSPARQLstandard together with the Open Time and Space CoreVocabulary Specification (which provides qualitativedirectional relations) define an adequate vocabularyfor representing geospatial data enabling qualitativespatial reasoning based on geometrical computations.The extension that we made upon these two ontologiesis given in the following, where the prefixesse-geometry, geop and ns, refers to the Geometrypattern, GeoSPARQL ontology and the Open Time andSpace Core Vocabularies, respectively:

se-geometry:SpatialObject is subsumed by the classgeop:Feature. According to GeoSPARQL, a featurerepresents a spatial object that has a geometry. Weconstrain the definition by saying that each feature isalso in a spatial and directional relations with at leastone another spatial object:

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

se-geometry:SpatialObject v geop:Feature u (7)

∃ geop:hasGeometry.geop:Geometry u

∃ se-geometry:hasSpatialRelation.se-geometry:SpatialObject

se-geometry:hasSpatialRelation is anobject property subsuming all the basicRCC-8 [28] topological relations (e.g.,geop:sfContains v se-geometry:hasSpatialRelation,geop:sfOverlaps v se-geometry:hasSpatialRelation,etc.). Furthermore, this object property subsumesa more specialized object property calledse-geometry:hasDescriptiveSpatialRelation, which isdefined to subsume all the qualitative spatial relations(including descriptive directional relations) in theOpen Time and Space Core Vocabularies (such asns:northOf, ns:nextTo, ns:near, etc.):

se-geometry:hasDescriptiveSpatialRelation v (8)

se-geometry:hasSpatialRelation

Where (due to the lack of space we have excluded theprefix se-geometry from all the following entities):

> v ∀ hasSpatialRelation− .SpatialObject

> v ∀ hasSpatialRelation.SpatialObject

4.3. Situation Pattern

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

In order to represent various situations (related tofeature of interests) in a smart environment we havedesigned the pattern Situation7 that contains twoclasses State and Situation where the individuals of the

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

8 Alirezaie et al. / SmartEnv as a Network of Ontology Patterns

former express the individuals of the latter class. In thefollowing, we describe the representational details ofthese two classes, where the prefixes se-situ, dul, ssnand sosa refer to the URIs of the pattern Situation,DULCE, SSN and SOSA8 ontologies, respectively:

se-situ:State represent a class whoseindividuals are assumed to declaratively expressa feature of interest regardless of how thisexpression is realized. According to DUL, the classdul:InformationObject allows us to define any piece ofinformation such as a text, a word, etc., independentlyfrom how it is concretely realized. We found thisdefinition suitable to be specialized and be as the basisof the class se-situ:State as follows:

se-situ:State v dul:InformationObject u (9)

∃ dul:expresses.se-situ:Situation

se-situ:Situation is subsumed by the classdul:Situation. A situation in a smart environmentcan be more specialized and expressed by a specificproperty of a feature of interest (i.e., the classsosa:FeatureOfInterest, e.g., temperature of the livingroom) and its state (e.g., warm). Therefore, thedefinition of the class also includes three axioms thatdetermine the relations between a feature of interest,its property and its relevant state. These axioms rely onthe object property dul:isExpressedBy:

se-situ:Situation v dul:Situation u (10)

= 1 dul:isExpressedBy.sosa:FeatureOfInterest u

= 1 dul:isExpressedBy.se-situ:State u

= 1 ssn:forProperty.ssn:Property

4.4. Sensing Pattern

A sensing process is simply defined as the processof monitoring a specific property of a feature ofinterest using a sensing device. In order to representsuch concept, we have designed the pattern Sensing9

which is highly relying on the SSN ontology allowingus to model establishment of a sensing process.In the following we explain the classes as thespecialization of concepts in SSN where the prefixesse-sensingse-sensing, sosa and ssn refer to the URI ofthe pattern Sensing, SOSA (used in SSN) and the SSNontologies, respectively:

8SOSA is one of the ontologies imported to SSN [12]9https://w3id.org/smartenvironment/patterns/sensing.owl

se-sensing:Sensor is subsumed by the classsosa:Sensor and represents a sensing device used in anobservation process and has its own configuration, asfollows:

se-sensing:Sensor v sosa:Sensor u (11)

∃ sosa:madeObservation.se-sensing:Observation u

= 1 ssn:implements.se-sensing:ConfigurationProcedure u

= 1 dul:isExpressedBy.se-situ:State

As we will see in Section 4.8, the relationbetween an event and the sensing process supposedto capture it, is indirectly provided via the twoclasses of sosa:FeatureOfInterest or more specificallyse-object:SmartObject also used in the classse-situ:Situation (see Figure. 1).

se-sensing:Observation which is used inthe definition of se-sensing:Sensor is also subsumed bythe class sosa:Observation representing a monitoringprocess of a feature of interest as follows:

se-sensing:Observation v (12)

sosa:Observation u

∃ sosa:madeBySensor.se-sensing:Sensor u

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

se-sensing:ConfigurationProcedure asa procedure allows us to define specific configurationrequired for each sensor to be used in an observationprocess. These configurations can include settingup the sampling rate of the sensor, the types ofsensor data, etc., that can be defined according to theapplication. A very generic definition of this class isgiven in the following:

se-sensing:ConfigurationProcedure v (13)

sosa:Procedure u

= 1 ssn:implementedBy.se-sensing:Sensor

4.5. Place Pattern

The meaning of a place in the context of smartenvironments is twofold. First, by a place we mean theentire smart environment which holds the deploymentof a sensor network and might also be composedof several sections. The second meaning of a placerefers to each section of the main place with a specific

Alirezaie et al. / SmartEnv as a Network of Ontology Patterns 9

identity that can be as such seen as a location fordifferent objects. Given this preliminary definition, thepattern Place10 defines a place as a specialization ofthe class dul:PhysicalPlace with the following details,where the prefixes se-place, sosa, ssn and dul refer tothe URI of the pattern Place, SOSA (used in SSN),SSN and DUL ontologies, respectively:

se-place:SmartEnvironment representsthe entire environment as a physical place (i.e.,DUL:PhysicalPlace) that is also assumed to hold adeployment 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 adeployment process (i.e. an instance of the classssn:Deployment):

se-place:SmartEnvironment v (14)

dul:PhysicalPlace u

sosa:Platform u

∃ dul:hasPart.se-place:Section

The information required to define an instanceof the se-place:SmartEnvironment as a platform usedin a deployment process is provided by the classsosa:Platform in the SSN ontology [12].

se-place:Section represents spatial sectionsas parts of a smart environment. Each section definesa physical place that can accommodate differentobjects. Furthermore, each spatial section in a smartenvironment has a geometry and therefore, can bein spatial relations with the other sections. In orderto reflect such properties, we have specialized thedefinition by adding a subsumption relation with theclass se-geometry:SpatialObject defined inthe Geometry pattern:

se-place:Section v dul:PhysicalPlace u (15)

se-geometry:SpatialObject u

∃ dul:isLocationOf.dul:PhysicalObject u

∃ dul:isPartOf.S martEnv

4.6. Network Pattern

A network in a smart environment is defined asa system containing different types of devices suchas nodes and node stations. By node, we mean acommunication module that indicates either a sendingor a receiving data module in a network. Each node

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

depending on its type can be a part of a node stationrepresenting another type of device that contributes inestablishing a network. Each node station contains anode along with other things including a sensor, powersupplies, batteries etc.

The whole process of a network set-up regardlessof its exact technical details is represented by anon-physical concept called deployment. The patternNetwork11 unifies the representation of environmentautomation installations that can be found in differentsystems. In the following we give the definition of theconcepts in the Network pattern, where the prefixesse-network and ssn refer to the Network pattern andthe SSN ontology, respectively:

se-network:Deployment extends the classssn:Deployment and explains a platform (e.g., a smartenvironment) upon which a network is deployed:

se-network:Deployment v ssn:Deployment u (16)

∃ ssn:deployedSystem.se-network:Network

The information related to the platform is inheritedfrom the superclass ssn:Deployment in the SSNontology [12].

se-network:Network is defined as a specialtype of system that has a deployment and is composedof a number of subsystems as follows:

se-network:Network v ssn:System u (17)

∃ ssn:hasDeployment.se-network:Deployment u

∃ ssn:hasSubsystem.se-network:NodeStation

se-network:NetworkModule describes thenetwork modules as a system in the form of nodestations and nodes contributing in sending andreceiving data within a sensor network in the contextof a smart environment:

se-network:NetworkModule v ssn:System (18)

se-network:NetworkModule ≡ se-network:Node t (19)

se-network:NodeStation

se-network:NodeStation as anetwork module has two types ofa se-network:SenderNodeStation or ase-network:ReceiverNodeStation), which (as assn:System) is located on a platform (e.g., as we will

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

10 Alirezaie et al. / SmartEnv as a Network of Ontology Patterns

see in section 4.7 a node holder) in the environmentand can contain a number of nodes as its sub-systems:

se-network:NodeStation v (20)

se-network:NetworkModule u

∃ ssn:hasSubSystem.se-network:Node

se-network:Node likewise representsa network module that either in theform of se-network:DataReceiverNode or ase-network:DataSenderNode plays a role in transferringdata:

se-network:Node v se-network:NetworkModule (21)

se-network:DataReceiverNode as its nameindicates, models a node (as part of a node station)which receives data coming from sensors (or morespecifically from sender modules):

se-network:DataReceiverNode v Node u (22)

∃ se-network:receivesDataFrom.se-network:DataSenderNode

se-network:DataSenderNode also models anode which as a part of a node station sends sensordata (to a receiver):

se-network:DataSenderNode v Node u (23)

∃ se-network:sendsDataTo.se-network:DataReceiverNode

se-network:ReceiverNodeStationdefines a node station which holds a data receivernode as its part (sub-system):

se-network:ReceiverNodeStation v (24)

se-network:NodeStation u

∃ ssn:hasSubSystem.se-network:DataReceiverNode

se-network:SenderNodeStation likewiserepresents a node station which is assumed to containboth a data sender node and also sensing devices(sensors):

se-network:SenderNodeStation v (25)

se-network:NodeStation u

∃ ssn:hasSubSystem.se-network:DataSenderNode u

∃ ssn:hasSubSystem.sosa:Sensor

se-network:receivesDataFrom isan object property providing the relationbetween a se-network:DataReceiverNode and ase-network:DataSenderNode. It is also the inverse of the

object property se-network:sendsDataTo as follows (theprefix se-network has been excluded):

> v ∀ receivesDataFrom.DataSenderNode (26)

> v ∀ receivesDataFrom− .DataReceiverNode

receivesDataFrom ≡ sendsDataTo−

4.7. Object Pattern

The pattern Object12 allows us to define objectsbased on their important features or abilities inthe context of smart environments. The classdul:PhysicalObject provides a suitable representationalbasis for the objects’ taxonomy, which we havecategorized into two types of smart objects and nodeholders. By smart object we refer to those objectsthat are the interest of an observation process (i.e,feature of interest). Due to the usual difficulties ofinstalling sensors in a smart home, it is common touse some other objects (i.e. node holders) to hostsensors. This separation provided by this pattern isspecifically useful for other computational modulessuch as a configuration planner one of whose tasks ischecking the status/functionality of sensors by sendinga robot to their locations.

Each smart object (or a feature of interest) has atleast a property to be observed. Another categorizationof smart objects that has been considered in theobject pattern, is about their mobility. An objectsis considered as mobile only if its location as oneof its properties, can change. In order to also beable 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 bedis located at the left side of the bedroom”), it isrequired to define objects in a smart environment asloas a se-geometry:SpatialObject defined in the patternGeometry (see Section 4.2).

In the following, we represent the DL notations ofeach object type along with their properties, wherethe prefixes se-object, dul and ssn refer to the Objectpatter, DUL and SSN ontologies, respectively:

se-object:Object as the main class ofthe Object pattern is subsumed by the classdul:PhysicalObject. The class definition is specializedaccording to the aforementioned description aboutdifferent types of objects that we can have in a smartenvironment:

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

Alirezaie et al. / SmartEnv as a Network of Ontology Patterns 11

se-object:Object v dul:PhysicalObject u (27)

se-geometry:SpatialObject u

∃ dul:hasLocation.dul:PhysicalPlace

se-object:SmartObject as an object alsoconsidered as a feature of interest due to itsproperty/properties which is/are the interest of anobservation process. For this to be represented, wehave defined a smart object also as a subclass ofsosa:FeatureOfInterest which provides the relationbetween the object and its properties:

se-object:SmartObject v se-object:Object u (28)

sosa:FeatureOfInterest

se-object:NodeHolder also as an object is alsoconsidered as a platform that can host (hold) a device(a node) in a sensor network. In this way, we candifferentiate between the objects, namely those thatare the interest of the observation, and the objectswhich, as the holder of sensors, are used for sensorlocalization processes.

se-object:NodeHolder v se-object:Object u (29)

sosa:Platform

se-object:MobileObject defines a movable objectcan be found at different places in the environment. Inother words, there is a observable property of interestcalled “Location” for mobile objects:

se-object:MobileObject v se-object:Object u (30)

∃ ssn:hasProperty.se-object:Location

where13

se-object:Location v sosa:ObservableProperty u

∃ ssn:isPropertyOf.se-object:MobileObject

se-object:Agent The class se-object:MobileObject

can be further specialized and form another type ofobjects that are able to be proactive and participate insome events. The class se-object:Agent subsumed bythe class dul:Agent allows us to represents inhabitantsof an environment (e.g., humans, pets, etc.), that canbe involved in an activity or an event (e.g., a person isan agent at home as he/she is often involved in various

13According to the SSN ontology: sosa:ObservableProperty vssn:Property

activities such as “sitting on couch”). Each agent canown, as its constituent, at least one se-obeject:Object

whose location depends on the location of the agent.More specifically, a constituent can express otherobjects physically attached to the agent. However, aconstituent does not need to be permanently attachedto the agent. For instance, a chair might be deemed asa constituent as long as it is held by the agent.

se-object:Agent v dul:Agent u (31)

se-object:MobileObject u

∃ dul:hasConstituent.se-object:Object u

∃ dul:isParticipantIn.dul:Event

4.8. Event Pattern

The pattern Event14 is an extension of therepresentation of events in DUL. In this extensionwe have defined two different types of eventsincluding a manifestation and complex event. Bymanifestation, we refer to those events that can bedirectly captured from sensor data and represent theoccurrence of a smart home situation through a sensingprocess. However, the latter event type, as its nameindicates, represents more complicated events whoseoccurrence depends on several preconditions [23].Each precondition as such represents a specificsituation assumed to be observed within an intervalwith a specific temporal distance to the event’soccurrence time. Furthermore, the pattern Time whichis per se based on the OWL-Time ontology, canprovide the required basis to represent the temporalproperties of the smart environment to capture changesin the form of events or activities. In the followingwe provide the representation of each class where theprefixes se-event, se-time and dul refer to the patternsEvent, Time and the DUL ontology:

se-event:Event as a general event class issubsumed by the class dul:Event. According to DUL,each event is expected to be observable at/withina dul:TimeInterval. On the other hand, the patternTime provides a general representation for temporalentities including time interval and temporal distances.Furthermore, as mentioned in Section 4.7, an event hasat least one agent (a proactive object) as its participant.Given the aforementioned explanations, we define theclass se-event:Event as follows:

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

12 Alirezaie et al. / SmartEnv as a Network of Ontology Patterns

se-event:Event v dul:Event u (32)

∃ DUL:hasParticipant.dul:Agent u

∃ DUL:isObservableAt.se-time:Interval

In order to complete the above class definition, wehave also defined the class se-time:Interval from thepattern Time as the sub class of the dul:TimeInterval:

se-time:Interval v dul:TimeInterval (33)

se-event:Manifestation as a specializedversion of the class se-event:Event indicates a situation(as we will see later, it is more specifically ase-situ:Situation) directly captured from sensor data:

se-event:Manifestation v se-event:Event u (34)

∃ dul:isEventIncludedIn.dul:Situation

se-event:ComplexEvent as a specializedversion of the class se-event:Event and representsan event whose occurrence depends on capturing anumber of preconditions represented as situations:

se-event:ComplexEvent v se-event:Event u (35)

∃ dul:hasPrecondition.se-event:EventCondition

se-event:EventCondition as adul:Situation represents preconditions of a complexevent (in the form of a situation: se-situ:Situation)which are needed to be captured within a specifictemporal distance from the time-stamp of the complexevent, where by temporal distance we refer to(se-time:TemporalDistance) (see section 4.1):

se-event:EventCondition v dul:Situation u (36)

∃ dul:isPreconditionOf.se-event:ComplexEvent u

∃ dul:isObservableAt.se-time:TemporalDistance u

∃ dul:isSettingFor.dul:Situation

5. SmartEnv Ontology – Construction

In this section, we show how by integrating the 8separate ontology module, the SmartEnv ontology15,representing different aspects of a smart environment,is constructed (see Figure. 1).

The SmartEnv ontology is formed as the resultof importing all the 8 modules. The connection

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

between each pair of modules is accomplished byspecializing the definition of concepts in each moduleand then linking them together. For instance, the classse-network:Deployment used in the pattern Networkis further specialized via the link to the classse-place:SmartEnvironment in the pattern Place:

se-network:Deployment v

∃ ssn:deployedOnPlatform.se-place:SmartEnvironment

All the specialized relations between modulesillustrated in Figure 1, are also listed in Table 1. Forfurther clarification, in the following we exemplify thepopulation process of SmartEnv for representation ofa smart home as an example of a smart environment.

5.1. SmartEnv Population

We have developed SmartEnv in E-care@home tobe used as the representation model of the data thatis gathered from a deployment test bed in ÖrebroUniversity called Ängen, a sensorized apartmentwhich provides functional facilities for the researchdevelopment including Ambient Intelligence (AMI)solutions. One of the relevant applications of contextreasoning in E-care@home is Activity recognition ofDaily Living (ADL) as well as the monitoring theother features of interest such as the physiologicaland health-related parameters of the users. For this,we have equipped Ängen with a number of bothenvironmental16 (e.g., pressure sensor, light sensor,motion sensor, etc.) and medical sensors. Beforerunning the observation process, we need to initializethe ontology with all the equipments including thenetwork modules, objects, their locations as wellas the activities or events that we are interested torecognize. In our preliminary set-up we equippedÄngen with 14 different sensors at different sections(rooms) of Ängen. The following axioms are examplesof statements used in SmartEnv population. For thesake of declarativity, these examples are either in theform of a unary predicate (class instantiation) or abinary predicate (positive object property assertions):

We first define Ängen in the ontology as a smartenvironment which as a living place of an elderlyperson is composed of one living room, 2 bedrooms,one bathroom and one kitchen.

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

Alirezaie et al. / SmartEnv as a Network of Ontology Patterns 13

Table 1Linked modules in SmartEnv ontology.

Module(1) Name Module(2) Name Axiom

Network Place se-network:Deployment v ∃ ssn:deployedOnPlatform.se-place:SmartEnvironment

Network Object se-network:NodeStation v ∃ sosa:isHostedBy.se-object:NodeHolder

Event Object se-event:Event v ∃ dul:hasParticipant.se-object:Agent

Event Situation se-event:Manifestation v ∃ dul:isEventIncludedIn.se-situ:Situation

Event Situation se-event:EventCondition v ∃ dul:isSettingFor.se-situ:Situation

Object Event se-object:Agent v ∃ dul:isParticipantIn.se-event:Event

Object Place se-object:Object v ∃ dul:hasLocation.se-place:Section

Object Network se-object:NodeHolder v ∃ sosa:hosts.se-network:NodeStation

Place Network se-place:SmartEnvironment v ∃ inDeployment.se-network:Deployment

Place Object se-place:Section v ∃ dul:isLocationOf.se-object:Object

Network Sensing se-network:SenderNodeStation v ∃ ssn:hasSubSystem.se-sensing:Sensor

* Smart Environment Description:

se-place:SmartEnvironment(ängen).

LivingRoom v se-place:Section

BedRoom v se-place:Section

BathRoom v se-place:Section

Kitchen v se-place:Section

LivingRoom(livingroom1).

Kitchen(kitchen1).

BathRoom(bathroom1).

BedRoom(bedroom1).

BedRoom(bedroom2).

dul:hasPart(ängen, livingroom1).

dul:hasPart(ängen, kitchen1).

dul:hasPart(ängen, bathroom1).

dul:hasPart(ängen, bedroom1).

dul:hasPart(ängen, bedroom2).

Given the structure of the environment, wecontinue the population process with the objects, theirproperties and locations. Due to the lack of space,we focus only on a single object (a couch) and showhow we represent it’s location with a pressure sensorattached to it to monitor the coach occupancy:

* Object Description:

Couch v se-object:SmartObject

Couch(couch1).

ssn:Property(pressure).

ssn:hasProperty(couch1, pressure).

dul:hasLocation(couch1, livingroom1).

Next, we define the network such as its deploymentin Ängen, nodes and node stations:

* Network Description:

se-network:Network(network1).

se-network:Deployment(deployment1).

ssn:inDeployment(ängen, deployment1).

se-network:NetworkModule(nodeStateion1).

ssn:hasSubSystem(network1, nodeStateion1).

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:

* Sensing Description:

PressureSensor v se-sensing:Sensor

PressureSensor(sensor1).

ssn:hasSubSystem(nodeStateion1, sensor1).

se-sensing:Observation(observation1).

sosa:hasFeatureOfInterest(observation1, couch1).

sosa:observedProperty(observation1, pressure).

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:

* Situation Description:

se-situ:Situation(couchPressed).

dul:isExpressedBy(couchPressed, couch1).

dul:isExpressedBy(couchPressed, on).

se-situ:Situation(couchUnPressed).

dul:isExpressedBy(couchUnPressed, couch1).

dul:isExpressedBy(couchUnPressed, off).

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:

14 Alirezaie et al. / SmartEnv as a Network of Ontology Patterns

* Event Description:

Sitting v se-event:ComplexEvent

SittingCondition v se-event:EventCondition

dul:hasPrecondition(Sitting, SittingCondition).

dul:isSettingFor(SittingCondition, couchPressed).

se-time:TemporalDistance(distance).

se-time:TimeDuration(duration1).

se-time:TimeDuration(duration2).

owl-time:numericDuration(duration1, 0).

owl-time:numericDuration(duration2, 0).

owl-time:hasDuration(distance, duration1).

owl-time:hasDuration(distance, duration2).

dul:isObservableAt(SittingCondition, distance).

The mentioned above axioms define a temporaldistance (i.e., distance) which is defined based ontwo time durations (duration1 and duration2 bothwith length zero (i.e., they are referring to the sametime point t (see Figure. 2)). In other words, theprecondition of the event sitting needs to be capturedexactly when the sitting activity occurs. Once thepressure sensor is triggered we immediately (with nodelay) infer the sitting event.

Given the populated ontology as explained abovewe can start observing the environment where eachsensor is assigned to a feature of interest to detectchanges and consequently recognize the relatedevents/activities. In order to map the stream of sensordata into our representation model, we need a reasoner.Depending on the features of the domain, the level ofuncertainty and complexity, we may apply differentreasoning method (monotonic or non-monotonic). Dueto the inherent uncertainty of sensor systems, wedecided to apply a non-monotonic reasoner which isbased on stable model semantics [13]. The detailshow the ontological axioms are converted to therules understandable by the non-monotonic reasoner(AnswerSet Solver) which is out of the scope of thispaper, can be found in [14].

The mentioned above population process can beextended in order to cover all the objects, sensorsand the equipments existing in the environment.During one of our test runs, the SmartEnv ontologywas first populated with the static informationabout the Ängen set-up which totally resulted in172 specialisations (i.e. subclasses) of the ODPclasses, and 203 individuals. Given this instantiatedontology, the observation process is then able to feedthe ontology with the instances of manifestations

corresponding to the changes detected in sensoroutputs. For instance, monitoring a person doingdifferent sorts of activities (such as cooking, watchingTV, etc.) in Ängen resulted about 200 additionalindividuals, describing the situations captured fromthe environment. These individuals, which are relatedto different classes including the manifestation andthe subclasses of the complex event class, makes theontology reasoning-ready for different purposes, suchas configuration planning or context recognition inmulti-inhabitant environments. The example scenariooutlined in Section 3 is only one among a multitude ofactivities that are relevant to detect in the context of theE-care@home project.

6. Discussion & Future Work

In this paper, we proposed a network of ontologypatterns targeting the representational aspects(such as sensing process, network configuration,objects’ taxonomy, event representation, topologicalrepresentation, etc.) of smart environments. Thefinal ontology is formed by integrating the proposedpatterns representing a smart environment. In orderto avoid the complex design issues as the result ofdependencies between the representational aspects,we have applied the ODP approach as an incrementalmethodology in designing ontologies. The ODPapproach allows us to start by first creating generaland small patterns for each aspect and then linkthem together. In this way, regardless of its size, theontology becomes flexible for further updates with theleast possible change cost.

The majority of the ontology modules constitutingthe SmartEnv ontology are mainly relying on SSNand DUL ontologies, however with a number ofspecializations, either in the form of extension of classhierarchies or updating links between concepts.

However, reusing existing vocabularies fromSSN or DUL was not a straightforward process.There are a number of generic concepts whosedefinitions make them a suitable basis for othercontext-related concepts. For instance, the classdul:InformationObject) which is used as the superclass of the class se-situState. Finding suchgeneric concepts can be time consuming. A meansto support the use of existing vocabularies (includingboth concepts and object properties) and/or patternswithout the need for creating or importing such classeswould ease the process to a considerable extent.

The network of ontology patterns may in the futurebe equipped with more patterns required to cover

Alirezaie et al. / SmartEnv as a Network of Ontology Patterns 15

other aspects of a smart environment. One aspect thatwe are currently investigating concerns the habits ofthe users (inhabitants) whose definitions (in terms ofpreconditions) are not necessarily clear at the timewhen we populate the ontology. For this, as a next step,we may either generalize the event pattern or add a newontology module to capture such concepts that allowus to relate some activities of the user to his/her habitsbased on their repetitions.Acknowledgments:

The work is supported by the project E-care@homefunded by the Swedish Knowledge Foundation2015-2019.

References

[1] Nguyen, T. V. and Lim, W. and Nguyen, H. and Choi, D. andLee, C.: Context Ontology Implementation for Smart Home.CoRR abs/1007.1273, (2010)

[2] Garvita Bajaj and Rachit Agarwal and Pushpendra Singh andNikolaos Georgantas and Valérie Issarny: A study of existingOntologies in the IoT-domain. CoRR, (2017)

[3] Ye, J., Stevenson, G. T., and Dobson, S. A.: A top-level ontologyfor smart environments. Pervasive and Mobile Computing, 7(3),359-378, (2011). DOI: 10.1016/j.pmcj.2011.02.002

[4] Holder, L.B., and Wemlinger, Z.: The COSE Ontology:Bringing the Semantic Web to Smart Environments. ICOST(2011).

[5] Chen, H., Finin, T. and Joshi, A.: An ontology for context-awarepervasive computing environments. Special Issue on Ontologiesfor Distributed Systems, Knowledge Engineering Review, Vol.18, pp.197âAS207 (2003).

[6] Abdulrazak, B. , Chikhaoui, B. , Gouin-Vallerand, C. , Fraikin,B.: A standard ontology for smart spaces. International Journalof Web and Grid Services. 6, 3, 244-268, (2010)

[7] Harry Chen, Tim Finin, and Anupam Joshi: The SOUPAOntology for Pervasive Computing. Ontologies for agents:Theory and experiences. 233–258, (2004)

[8] Bonino, D. and Corno, F.: Dogont - ontology modellingfor intelligent domotic environments. Proceedings of theInternational Semantic Web Conference, Vol. 5318 of LectureNotes in Computer Science, Springer, pp.790-803 (2008).

[9] Maria Bermudez-Edo, Tarek Elsaleh, Payam Barnaghi, andKerry Taylor. IoT-Lite: A lightweight semantic model forthe internet of things and its use with dynamic semantics.Personal Ubiquitous Comput. 21, 3 (June 2017), 475-487. DOI:https://doi.org/10.1007/s00779-017-1010-8

[10] Jerry R. Hobbs and Feng Pan: Time Ontology in OWL:https://www.w3.org/TR/owl-time/ (2017)

[11] Alber Sanchez and Jim Jones: Open Timeand Space Core Vocabulary Specification:https:http://www.observedchange.com/tisc/ns/ (2013)

[12] Rob Atkinson, Raul Garcia-Castro, Joshua Lieberman andClaus Stadler: Semantic Sensor Network Ontology- W3CRecommendation: https://www.w3.org/TR/vocab-ssn/ (2017)

[13] Gebser M., Kaminski R., Kaufmann B., Ostrowski M., SchaubT., Thiele S: Engineering an Incremental ASP Solver. In:Garcia de la Banda M., Pontelli E. (eds) Logic Programming.

Lecture Notes in Computer Science, vol 5366. Springer, Berlin,Heidelberg (2008)

[14] Alirezaie, Marjan and Renoux, Jennifer and KÃuckemann,Uwe and Kristoffersson, Annica and Karlsson, Lars andBlomqvist, Eva and Tsiftes, Nicolas and Voigt, Thiemoand Loutfi, Amy: An Ontology-based Context-aware Systemfor Smart Homes: E-care@home. Sensors, vol 17. ISSN:1424-8220, DOI:10.3390/s17071586 (2017)

[15] Gangemi, A. and Presutti, V.: Ontology Design Patterns.Handbook on Ontologies. International Handbooks onInformation Systems (2009)

[16] Blomqvist, E. and Hitzler, P. and Janowicz, K. and Krisnadhi,A. and Narock, T. and Solanki, M.: Considerations regardingOntology Design Patterns. Journal Semantic Web, 7, 1-7 (2016)

[17] Alexander, C. and Ishikawa, S. and Silverstein, M.: A PatternLanguage: Towns, Buildings, Construction. (1977)

[18] Roger D. Eastman; Craig I. Schlenoff; Stephen B.Balakirsky; Tsai Hong Hong: A Sensor Ontology LiteratureReview.(NISTIR) - 7908 (2013)

[19] Tao, G. and Xiao, H.W. and Hung, K.P. and Da, Q.Z.: AnOntology-based Context Model in Intelligent Environments. Int.Conf. on Communication Network and Distributed SystemsModeling and Simulation - 270–275 (2004)

[20] Nguyen, T.A. and Raspitzu, A. and Aiello, M.: Ontology-basedoffice activity recognition with applications for energy savings.Journal of Ambient Intelligence and Humanized Computing -667–681 (2014)

[21] Compton, M. and Barnaghi, P. and Bermudez, L. andGarcia-Castro, R. and Corcho, Ó. and Cox, S. and Graybeal, J.and Hauswirth, M. and Henson, C. and Herzog, A. and Huang,V. and Janowicz, K. and Kelsey, W. D. and Phuoc, D. L. andLefort, L. and Leggieri, M. and Neuhaus, H. and Nikolov, A.and Page, K. and Passant, A. and Sheth, A. and Taylor, K.: TheSSN Ontology of the W3C Semantic Sensor Network IncubatorGroup. Web Semantics: Science, Services and Agents on theWorld Wide Web. Elsevier, 17, (2012).

[22] Sezer, O. B. and Can, S. Z. and Dogdu, E.: Developmentof a smart home ontology and the implementation of asemantic sensor network simulator: Int. Conf. on CollaborationTechnologies and Systems (CTS), (2015)

[23] Alirezaie, M. and Loutfi, A.: Reasoning for Improved SensorData Interpretation in a Smart Home. ARCOE-Logic WorkshopNotes, pp. 1-12, (2014)

[24] Cox, Simon J.D.: Ontology for observations and samplingfeatures, with alignments to existing models. Semantic WebJournal pp. 1-18, (2016)

[25] Janowicz, K. and Compton, M.: TheStimulus-Sensor-Observation Ontology Design Pattern andits Integration into the Semantic Sensor Network Ontology.Workshop on Semantic Sensor Networks, SSN (2010)

[26] Seydoux, N. and Drira, K. and Hernandez, N. and Monteil, T.:IoT-O, a Core-Domain IoT Ontology to Represent ConnectedDevices Networks: Int. Conf. on Knowledge Engineering andKnowledge Management (EKAW), 561–576, (2016)

[27] Battle, R. and Kolas, D.: Enabling the Geospatial SemanticWeb with Parliament and GeoSPARQL. Semantic Web Journalpp. 355–370, (2012)

[28] Cohn, A. G. and Bennett, B. and Gooday, J. and Gotts,M.: Qualitative Spatial Representation and Reasoning withthe Region Connection Calculus. GeoInformatica, 1, 275-316,(1997)