A Comprehensive Semantic Model for Smart Object Description and Request Resolution in the Internet of Things

Procedia Computer Science 83 ( 2016 ) 147 – 154

1877-0509 © 2016 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

Peer-review under responsibility of the Conference Program Chairs doi: 10.1016/j.procs.2016.04.110

ScienceDirect

The 7th International Conference on Ambient Systems, Networks and Technologies

(ANT 2016)

A comprehensive semantic model for smart object description and

request resolution in the internet of things

Ali Yachir

_{*, Badis Djamaa}

_{, Ahmed Mecheti}

_,

_{Yacine Amirat}

_{and Mohamed Aissani}

b_{LISSI Laboratory, University Paris-Est Créteil (UPEC)94400 Vitry-sur-Seine, Paris, France}

Abstract

The Internet of Things is a natural continuity of the Ambient Intelligence where smart and ambient environments are built by integrating a large number of interconnected smart objects with heterogeneous capabilities abstracted as software services. The aim is to design cross-domain applications that compose and select most relevant services, which best match user requirements and closely meet the specified quality-of-service level. However, semantic description and representation of such smart devices, including their hosted services and their provided real world data, is still a challenging issue. Semantic Web technologies are seen as a promising tool for this purpose. Indeed, applying these technologies in the Internet of Things enables smart objects to efficiently share their data, exchange their services and cooperate to better satisfy both functional and non-functional user requirements. In this paper, we propose a new semantic model for smart objects description and users request resolution using ontological techniques combined with description logics. Such a model facilitates intelligent functions, including reasoning over service data and semantic interoperability enabling among devices. A case study for smart environment monitoring has been proposed to illustrate the effectiveness and usability of our approach.

© 2016 The Authors. Published by Elsevier B.V.

Peer-review under responsibility of the Conference Program Chairs.

Keywords:Internet of Things; Ambient Intelligence; Smart Environments; Semantic Model; Service and Device Description; Description Logics; Semantic Web Technologies; Ontology; QoS Evaluation; Request Description, Request Resolution.

* Corresponding author. E-mail address: [email protected]

© 2016 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

1.Introduction

The convergence of the Ambient Intelligence (AmI) and the Internet of Things (IoT)1,2,3 _{envisions a world where}

varieties of objects (i.e. things), with sensing and actuation capabilities, are connected to the Internet and can be joined, all the time and everywhere, through small portable devices like Smartphones. These objects can individually provide services or cooperate to provide value-added services that none of them could provide alone. The overall challenge; however, is how to achieve interoperability among such heterogeneous objects and how to represent effectively their provided IoT data. In other words, how to abstract IoT devices’resources as software services, independently from the application domain, considering the interplay between those devices and the physical world. This includes both the state of the devices themselves and their relationships with the main entities of our surroundings (e.g. persons, places and appliances). Semantic Web technologies are a promising initiative to overcome these issues. The Semantic Web community has been working on approaches to make the Web machine-readable4 _{and IoT data meanings more comprehensive using reasoning techniques. This facilitates automatic service}

composition and selection as well as advanced tasks involving smart devices such as device management5_{, query}

processing6_{, and application-level services}7_.

Various research works have been proposed in recent years to improve interoperability between heterogeneous IoT devices using semantic web technologies8-18_{. In reference}9_{, a novel framework for the Semantic Web of Things}

based on a backward-compatible extension of the Constrained Application Protocol (CoAP) is proposed. In reference10_{, instead of using a predefined vocabulary to tag devices in the Haystack framework, an ontology design}

pattern is proposed. In reference11_{, a semantic description of IoT devices, based on the RESTdesc format}12_{, is}

proposed to deal with automatic and self-configurable service composition in highly dynamic and resource-constrained environments using CoAP. The proposed approach extends the work presented in reference13 _{to manage}

the physical states of IoT devices and their provided services. In reference14_{,Sensor Markup Language (SenML)}15

and Resource Description Framework (RDF) are adopted to represent devices’ parameters. In reference16_{, a semantic}

approach is proposed for robots interaction with humans, agents and systems using natural language. In reference17_,

an ontology-based framework is proposed to discover, search, use and share information and services of residential environment devices. In reference18_{, a description ontology is proposed for the IoT domain by integrating and}

extending existing work with some concepts such as: IoT service modeling, Quality of Services (QoS), Quality of Information (QoI), and IoT service test.

The works discussed above show that some semantic models have been proposed and used to represent, reason and manipulate IoT devices. Nevertheless, current solutions only allow simplistic data-oriented representation of IoT devices without representing the whole smart environment. It is not clearly explained how the proposed models can link between the different entities of the physical world and the virtual services provided by IoT devices. In other words, it is not clearly answered to which entities IoT devices are attached; which entities they might control; in which space are they located; and which services (context, event and/or action) they might provide? Full semantic device/service representation models should answer such questions. Moreover, user requirements should be involved in such models and a similarity degree between user requests and the available devices/services should also be provided.

To overcome the aforementioned shortcomings of existing work, we propose in this paper, a new semantic model that supports both IoT devices and user request descriptions. The present work is in the continuity of previous works conducted in our laboratory 19,20,21_{. It focuses on interoperability at the data and knowledge level of IoT devices. On}

the one hand, IoT devices description comprises a description of the physical device itself along with its hosted services. On the other hand, user request description includes functional and non-functional requirements. By combining several domain ontologies with description logics, compatible with widely used semantic models, the proposed approach promotes reuse and support more efficient inference in the IoT. The rest of this paper is organized as follows. Section II presents the proposed semantic model describing IoT devices. This is followed by an explanation of the user request description and resolution approach in Section III. Section IV describes the Living Lab and the use-case scenario for user assistance in an Ambient-Assisted Living (AAL) environment. Finally, Section V gives conclusions and ideas for future work.

2.Semantic model description

The proposed knowledge model comprises two main descriptions: device description and service description. As shown in Fig.1., the device description part is structured around four main entities namely: space, person,appliance

and device. Space describes different regions and locations inside the ambient environment. Person refers to inhabitants or users of the ambient environment and may wear one or several devices. Appliance can represent physical equipments such as TVs and fridges or more general software applications. Device is the key entity that takes control of the three aforementioned entities. It refers to a physical object that can be a sensor or an actuator. It should be noted that these two functionalities are not exclusive. A particular device may act as an actuator equipped with sensing capabilities. Generally, a device is power-constrained and communicates over low-power and lossy links. Notice that, a device may remotely control a physically separated appliance or may alternatively be embedded in the appliance itself. For instance, an IR sensor can remotely control a TV whereas a temperature sensor can be embedded on a mobile robot. Device description part is enhanced through semantic annotation of its main entities and their corresponding properties according to a shared domain conceptualization (i.e., ontology). Each entity is semantically described in its own reference ontology where each concept possesses its own properties. An ontological property refers to a characteristic (attribute or relationship) of a concept, a sub concept or an individual of the entity in question. For example, taking the person entity, a patient is a sub concept that has as properties: cardiac rate, body temperature and blood pressure. Regarding the device entity, properties describe specific attributes of the device and its relationships with the other entities of the ambient environment such as persons, spaces and appliances, as shown in Fig.1. for instance, a device has four mains direct relationships: a device may be worn by a person or embedded on an appliance. It can also control an appliance and obviously, it is located at a given space. Particularly, this last relation can be omitted and therefore inferred with the specified rule inTable 1, using Description Logics (DL).

Fig. 1. Devices and services description model.

The service description part is structured around a core concept called Ambient Service (AS), which represents a software resource provided by a device. From this point of view, the dynamics of the surrounding environment will be controlled at any time by executing a set of ambient services. First, an ambient service can control directly a physical devices or appliances such as lights, TVs and sensors. For instance, a service “switchOnLight” can change the status of a controlled light from “off” to “on”. Second, an ambient service can control a person through wearable devices. For example, a person can wear a body temperature sensor and a service “getBodyTemperature” can return

Device Appliance Provides Controls Person Space Device properties Appliance properties Person properties Space properties Located at Located at Located at Worn by Has Has Has Has Has

Output parameters Observed parameters QoS parameters Effects

Ambient Service Embedded on Dev ice descriptio n Serv ice descriptio n

the body temperature of this person. Third, an ambient service can control a space region equipped with devices. For example, a temperature sensor device, installed in a kitchen, can provide “getTemperature” service, which returns the temperature of the given kitchen. More formally, an ambient service refers to a concrete action or operation that can be performed on an ambient environment. Such an action can be achieved by any logical or physical transformation function that can take some data as inputs and produce some data as outputs. These latter can be produced in the form of event, context or effect on the environment with some quality of service level, as shown in Table 2. Produced event and context are annotated respectively as observed and output parameters, whereas the produced effect is seen as the result of the performed control.

Table 1. Rule of device location inference Table 2. Annotation of an ambient service.

2.1.Output and Observed parameters description

Output parameters represent contextual parameters that are provided by an ambient service as output data such as temperature, humidity, luminosity, etc. To enhance their semantic interpretation, output parameters should be concepts, sub concepts or individuals in a well-known ontology denoted as a reference ontology. This ontology can describes property attributes of an entity belonging to the device description part. It makes a semantic relation

between an ambient service and the controlled entities in the environment. For example, a concept “Room1” in the

space ontology can have as a property attribute temperature in a reference ontology “RO” describing sensors’

observations. Let a temperature sensor be a device located in “Room1” that provides an ambient service called

getTemperature. The output parameter of this service is named temperature to meet the common vocabulary used in

the ontology RO. Contrary to an output parameter that can be provided only on demand, an observed parameter can be observed continuously by an ambient service and notified using subscription/notification mechanism. Notifications can be sent periodically or just when the status of the observed parameter changes. Table 3 gives annotations of output and observed parameters of an ambient service.

Table 3. Annotation of output and observed parameters of an ambient service.

2.2.Effects and QoS description

RDF statements, in a Subject-Predicate-Object structure, represent an effect of a service. In each RDF triple, OWL classes express the subject and the object, whereas OWL properties express the predicate. Hence, the RDF statements describe the causal effect of an ambient service as a triple including an entity (“subject”), a property

(“predicate”), and the value of the property (“object”), where this value can be another entity, an attribute or a

literal. As an example, a causal effect of a service “switchOnLight” can be represented as Effect (light, hasStatus, on). In addition, a causal effect of a service “mediaPlayerController” has the following effect on the media player application: (Media player, hasStatus, started). Like the output parameters, an effect should express a relation between an ambient service and its controlled entity. For that reason, the subject of an effect should be a concept, a sub concept or an individual from the reference ontology representing the controlled entity. The predicate and the object of an effect should be respectively a property relationship and a property attribute of the controlled entity (i.e. subject). Table 4 gives annotation of the effect of an ambient service.

Regarding the quality of service (QoS), we distinguish the quality characterizing an ambient service and the quality characterizing the device hosting such service. First, an ambient service as a software resource possesses its proper QoS parameters such as energy consumption, service reliability and response time. Energy consumption

reflects the overall energy consumption during the execution of a service or the amount of energy consumed for the delivery of this service, whereas the parameter service reliability quantifies the number of missed output data, i.e.

„‹‡–‡”˜‹…‡ ؠ …–‹‘ ِ ׌Šƒ•˜‡–Ǥ „•‡”˜‡†ƒ”ƒ‡–‡”• ׫ ׌Šƒ•‘–‡š–Ǥ —–’—–ƒ”ƒ‡–‡”• ׫ ׌Šƒ•‘–”‘ŽǤ ˆˆ‡…–• ׫ ׌Šƒ•—ƒŽ‹–›Ǥ ‘ƒ”ƒ‡–‡”• ሺǫ †‹•‘”›ǫ ’ሻ᦬ሺǫ ’‹•‘…ƒ–‡†–ǫ •ሻ ֜ǫ †‹•‘…ƒ–‡†–ǫ • ሺǫ †‹•„‡††‡†ǫ ƒሻ᦬ሺǫ ƒ‹•‘…ƒ–‡†–ǫ •ሻ ֜ǫ †‹•‘…ƒ–‡†–ǫ • —–’—–ƒ”ƒ‡–‡”• َ‡˜‹…‡Ǥ ”‘’‡”–‹‡• ׫ ‡”•‘Ǥ ”‘’‡”–‹‡• ׫ ’ƒ…‡Ǥ ”‘’‡”–‹‡• ׫ ’’Ž‹ƒ…‡Ǥ ”‘’‡”–‹‡• „•‡”˜‡†ƒ”ƒ‡–‡”• ؠ —–’—–ƒ”ƒ‡–‡”• ِ ׌Šƒ•‘–‹ˆ‹…ƒ–‹‘Ǥ ሺ‡”‹‘† ׫ Šƒ‰‡ሻ

the number of received parameters among the set of requested parameters from the service. Response time

represents the required time by a service to respond to a given inputs. For instance, two ambient services can have different response time even that they are provided by the same device. Second, the quality of a device is described by means of its properties and capabilities. Such description is represented by conjunctive concept expressions referring to the same ontology. For example, the SSN-XG ontology defined in reference22 _{can be used to describe}

the measuring features of a sensor. Measurement capabilities are expressed as subclasses of the

ssn:MeasurementCapability class. Each specific subclass of ssn:MeasurementCapability has a set of measurement

properties such as range detection, sampling frequency and accuracy. Furthermore, a sensor is related to a subclass

of ssn:EnergyDevice through the ssn:hasSubSystem property to model its energy source.Table 5 gives annotation of

a quality of service (QoS).

Table 4. Annotation of an effect of an ambient service Table 5. Annotation of a quality of service (QoS).

3.User request description and resolution

3.1.User request description

The user request is focused around a main topic denoted requested subject. Generally, a user needs to set or get information about a specific entity which can be a device, a space, a person or an appliance. For this reason, the

requested subject is formalized as a concept, a sub concept or an individual from one of the four mains

aforementioned entities with respect to their referenced ontologies. Moreover, a user needs to know or control a specific characteristic of the requested entity. Such characteristic is formulized as an ontological property of the requested entity and denoted requested subject property. This property denotes the effective user functional requirements and refers to a context, an event or an effect about the requested entity. Furthermore, the user request can include some non-functional requirements denoted as required QoS level. This level specifies a minimum score threshold required for the quality of service. Only ambient services providing quality higher than the required QoS

level are returned to the user. This allows to modulate the granularity of service selection and to limit data transfers

when many ambient services are available. To compute a score of an ambient service, user should specify in its request the relative importance accorded for each required QoS parameter. This importance is formulized by weights

Wi from 1 to 6, i.e. from low to high importance as follow: (Wi = 1,very low), (Wi = 2, low), (Wi = 3, medium), (Wi

= 4, quite high), (Wi = 5, high), et (Wi = 6, very high). Consequently, a user request is described by four mains

components as follow: (requested subject, requested subject property, required QoS level, required QoS

parameters). Table 6 gives annotation of the user request.

Table 6. Annotation of the user request. Table 7. Request resolution rule (3R).

3.2.User request resolution

User request resolution is based on the inference rule named request resolution rule denoted 3R, depicted in Table 7. This rule tries to infer all candidate ambient services that satisfy functional requirements provided in the user request using two main steps. First, 3R infers all devices that have a direct or indirect relation with the

ˆˆ‡…– ؠ׌Šƒ•Ǥ —„Œ‡…– ِ ׌Šƒ•Ǥ ”‡†‹…ƒ–‡ ِ ׌Šƒ•Ǥ „Œ‡…– —„Œ‡…– َ‡˜‹…‡ ׫ ‡”•‘ ׫ ’ƒ…‡ ׫ ’’Ž‹ƒ…‡ ”‡†‹…ƒ–‡ َ —„Œ‡…–Ǥ ‡Žƒ–‹‘•Š‹’”‘’‡”–› „Œ‡…– َ —„Œ‡…–Ǥ ––”‹„—–‡”‘’‡”–›׫ Ž‹–‡”ƒŽ ‡“—‡•–‡†—„Œ‡…– َ‡˜‹…‡ ׫ ‡”•‘ ׫ ’ƒ…‡ ׫ ’’Ž‹ƒ…‡ ‡“—‡•–‡†—„Œ‡…–”‘’‡”–› َ ‡“—‡•–‡†—„Œ‡…–Ǥ ”‘’‡”–‹‡• ‡“—‹”‡†‘ ؠ ‡“—‹”‡†‡˜‹…‡‘ ׫ ‡“—‹”‡†‡”˜‹…‡‘ ‡“—‹”‡†‡˜‹…‡‘ َ ‡˜‹…‡‘ ‡“—‹”‡†‡”˜‹…‡‘ َ „‹‡–‡”˜‹…‡‘ —ƒŽ‹–› ؠ ‡˜‹…‡—ƒŽ‹–› ׫ „‹‡–‡”˜‹…‡—ƒŽ‹–› ‡˜‹…‡—ƒŽ‹–› َ ‡˜‹…‡Ǥ ”‘’‡”–‹‡• „‹‡–‡”˜‹…‡—ƒŽ‹–› َ „‹‡–‡”˜‹…‡Ǥ ‘ƒ”ƒ‡–‡”• ‘†‹†ƒ–‡‡˜‹…‡ ؠ ‡˜‹…‡ ِ ׌Šƒ•‡Žƒ–‹‘•Š‹’”‘’‡”–›ሺ‡“—‡•–‡†—„Œ‡…–ሻ ‘†‹†ƒ–‡‡”˜‹…‡ ؠ „‹‡–‡”˜‹…‡ ِ ׌‹•”‘˜‹†‡†›ሺ‘†‹†ƒ–‡‡˜‹…‡ሻ ِ ሺ׌Šƒ•„•‡”˜‡†ƒ”ƒ‡–‡”•ሺ‡“—‡•–‡†—„Œ‡…–”‘’‡”–›ሻ ׫ ׌Šƒ•—–’—–ƒ”ƒ‡–‡”•ሺ‡“—‡•–‡†—„Œ‡…–”‘’‡”–›ሻ ׫ ׌Šƒ•ˆˆ‡…–•ሺ‡“—‡•–‡†—„Œ‡…–”‘’‡”–›ሻ)

requested subject. Second, for each obtained candidate device, 3R cheeks if there are provided ambient services that meet requested subject property. Verification is done using the reference ontology and according to the provided

requested subject property. If this property is a context, verification is performed through output parameters. When

the property is an event, verification is done through observed parameters whereas if it is an effect, verification is performed through controlled parameters. After application of the request resolution rule, we obtain a list of pair

(candidate device, candidate ambient service). Each pair is evaluated according both to the quality provided by the

candidate device and its corresponding candidate ambient services. QoS evaluation is based on the weights provided

in the user request. But, before proceeding to this evaluation, QoS parameters are first normalized as follow. Let

QoSi,jbe the value of the quality parameter i of the device or service j. QoSi,jis obtained by transforming the value Vi,,j‘ˆthe quality parameter i, initially provided by the device or service j, to a value between 0 and 1. To do this,

first a deviation Di,,jbetween the initial value Vi,,jand the maximum value of the quality parameter i, noted Max (QoSi), is computed using formula 1. Max (QoSi) can be calculated according to the range values of the parameter i.

For example, for values expressed as a percentage, Max (QoSi) =100% while values expressed in a bounded

interval, Max (QoSi) is the maximum bound of this interval. When there is no information about the max value, Max (QoSi) is the maximum of all available values for the parameter i. After computing the deviation Di,,j, the values of QoSi,j can be calculated using the formula 2 and formula 3 which correspond respectively to the case of

minimization and maximization of the parameter i. Then, the expected quality of service provided by a service or a device j, noted QoSj, is computed using formula 4. This estimation takes into account the user’s preferences

specified as weights Wi for each quality parameter i to reflect its relative importance to the user. The obtained value

for QoSj remains between 0 and 1. Finally, the quality of a pair (candidate device, candidate ambient service) is the

average of expected qualities both for the candidate device and the candidate ambient service. ܦ௜ǡ௝ൌ ܯܽݔሺܳ݋ܵ௜ሻ െ ܸ௜ǡ௝ǥ ሺͳሻǢ ܳ݋ܵ௜ǡ௝ൌ ܦ௜ǡ௝ ܯܽݔሺܳ݋ܵ௜ሻ ǥ ሺʹሻ ܳ݋ܵ_௜ǡ௝ൌ ͳ െ_{ܯܽݔሺܳ݋ܵ}ܦ௜ǡ௝ ௜ሻ ǥ ሺ͵ሻǢ ܳ݋ܵ௝ൌ σ ܹ௜ ௜כ ܳ݋ܵ௜ǡ௝ σ ܹ௜ ௜ ǥ ሺͶሻ

4.Use case scenario description

The Living Lab used for experiments includes different components: 1) A robot companion (Kompai); 2) Display devices: Smartphone, screen display of the robot companion and PC monitor; 3) A set of sensors to observe events related to the context of an elderly person at home, such as: cameras, RFID tags, ambient sensors (temperature, humidity, luminosity) and various detectors (fall, presence, smoke, etc.); and 4) A set of actuators for controlling remote devices such as micro wave, TV, light and Fridge, as shown in Fig.2. (a). The ambient services are implemented using the Ubistruct middleware. The description of the living lab and the Ubistruct middleware are reported in the following video http://youtube/XicBDjGSxYc. For example, the Imote2 device is described and published with respect to the proposed model as shown in Fig.2. (b). This device provides four main IoT Resources

namely: Temperature, Humidity, Luminosity and Acceleration through four ambient services: getTemperature,

getHumidity, getLuminosity and getAcceleration respectively. The three former services return respectively

temperature, humidity and luminosity as an ambient climate defined in the reference ontology shown in Fig.2. (c). The latter service returns accelerations according to the three main axes X, Y and Z. However, acceleration information is useful only when the device is worn by a person or embedded in a mobile appliance such as robot.

In our scenario, a user requests the temperature of the kitchen “KITCHEN#05”. In this request, devices with medium lifetime battery, medium sampling frequency and large measurement range are required. For instance, large measurement range indicates that the device is able to take both low and high values of temperature. Moreover, services with high response time, low energy consumption and very high reliability are also needed. According to these specifications and using concepts defined in the domain ontology (see Fig.2. (c)), the request is described as follows: (KITCHEN#05, Output: (Temperature), 0.6, Required QoS parameters) where Required QoS parameters are described in Table 8. After applying the 3R rule (see Table 7), two candidate ambient services are inferred:

Fig. 2. (a) LISSI ubiquitous platform overview; (b) instantiated semantic model; (c) parameter reference ontology

The different values of the quality parameters of the candidate devices and ambient services are depicted in Table 9. We provide three values (Vi,j; Di,j; QoSi,j) for each quality parameter i such as: Vi,j is the initial value of the quality parameter i, provided by the device or service j whereas Di,j and QoSi,j are computed using respectively formulas 1 and 2 or 3.

Table 8. Required QoS parameters description.

Table 9. Quality parameters of the candidate devices and ambient services.

Device/ Service Energy Level Detection Range Sampling Frequency Reliability Response time Energy cost

IMOTE2SENSOR#04 (50; 50; 0.5) (10;5;0.66) (5;0;1) - - TELOSBSENSOR#08 (70;30;0.7) (15;0;1) (2;3;0.4) - - getTemperature, TELOSBSENSOR#08 - - - (0.7;0.3;0.7) (70;0;0) (10;90;0.9) getTemperature, IMOTE2SENSOR#04 - - - (0.9;0.1;0.9) (50;20;0.28) (20;80;0.8)

From the user’s preferences specified in Table 8and using the correspondence mentioned in section 3.1, the quality parameters are weighted as follow: (energy level, high, w=5); (detection range, high, w=5); (sampling frequency, medium, w=3); (reliability, very high, w=6); (response time, medium, w=3); and (energy consumption, high, w=5). After applying the formula 4, we obtain QoS=0.7 for the couple (getTemperature, IMOTE2SENSOR#04) and QoS=0.68for the couple (getTemperature, TELOSBSENSOR#08). As the minimum score threshold required for the quality of service is 0.6, the two candidate services are selected and returned to the end user.

Legend: : instance Of, : sub Concept, : property Person

Space Device

Living_Room Kitchen Sensor

Imote2Sensor TelosBSensor Actuator IMOTE2SENSOR#04 TELOSBSENSOR#08 IMOTE2SENSOR#03 LIVING_ROOM#10 locatedAt wornBy KITCHEN#05 locatedAt locatedAt

Temperature Humidity Luminosity getTemperature getHumidity getLuminosity

Acceleration getAcceleration TV#01 CleodeSensor (TV, hasStatus, On) switchOnTV switchOffTV Appliance TV Light Fridge locatedAt Controls (TV, hasStatus, Off) UBEEZPLUG#09

hasEffect hasEffect hasOutput hasOutput hasOutput hasOutput

UBEEZPLUG#15 ALI Controls D o main On tolo gy Inst an ces provides provides provides (c) (b) (a) QoSIMOTE2SENSOR#04= (0.5*5+0.66*5+1*3)/(5+5+3)=0.67

QoSgetTemperature IMOTE2SENSOR#04= (0.9*6+0.28*3+0.8*5)/ (6+3+5)=0.73

QoS=(0.67+0.73)/2=0.70 QoSTELOSBSENSOR#08= (0.7*5+1*5+0.4*3)/ (5+5+3)=0.74 QoSgetTemperatureTELOSBSENSOR#08= (0.7*6+0*3+0.9*5)/ (6+3+5)=0.62 QoS=(0.74+0.62)/2=0.68 hasProperty ‡“—‹”‡†‘ƒ”ƒ‡–‡”• ؠ ‡“—‹”‡†‡˜‹…‡‘ ׫ ‡“—‹”‡†„‹‡–‡”˜‹…‡‘ ‡“—‹”‡†‡˜‹…‡‘ ؠ Šƒ•ƒ––‡”›”‘’‡”–›Ǥ ሺ‹‰Šሻ ِ Šƒ•‡ƒ•—”‡‡–”‘’‡”–›Ǥ ሺŠƒ•ƒ‰‡ሺ‹‰Šሻ ِ Šƒ• ”‡“—‡…›ሺ‡†‹—ሻሻ ‡“—‹”‡†„‹‡–‡”˜‹…‡‘ ؠ Šƒ•‡•’‘•‡‹‡Ǥ ሺ‡†‹—ሻ ِ Šƒ•‡”‰›‘•—’–‹‘Ǥ ሺ‹‰Šሻ ِ Šƒ•‡Ž‹ƒ„‹Ž‹–›Ǥ ሺ‡”›‹‰Šሻ

5.Conclusion and future work

In this paper, we have presented a new semantic model for IoT devices description and user request resolution. On the one hand, an IoT device, as a central entity of the proposed model, is represented by its proper attributes and its relationships with the other entities of the ambient environment namely persons, spaces and appliances. The services, provided by an IoT device, are also described by their proper attributes including outputs, events, effects and QoS parameters. These attributes are annotated with a well-defined meaning according to a common ontology. On the other hand, user request is described using both functional and non-functional requirements. Functional requirements are resolved using description logics while non-functional requirements are evaluated according to the provided quality of service levels by the available devices/services. As a future work, it is still necessary to conduct further empirical evaluations of the proposed approach. We plan implementing an automatic approach for IoT devices and services classification in the Framework proposed in19 _{based on the described semantic model. We are}

also currently working on semantic enhancement of CoAP resources using the proposed approach.

References

1. P. Suresh, J. V. Daniel, V. Parthasarathy, and R. H. Aswathy, ĀA state of the art review on the Internet of Things (IoT) history, technology and fields of

deployment,āin Proc. IEEE Int. Conf. Sci., Eng. Manage. Res. (ICSEMR’14), Chennai, India, Nov. 2014, pp. 1̢8.

2. P. Rashidi , A. Mihailidis,ĀA survey on ambient-assisted living tools for older adults,āIEEE J. Biomed. Health Informat., vol. 17, no. 3, pp. 579̢590, 2013. 3. G. Acampora, D. J. Cook, P. Rashidi, and A. V. Vasilakos, A survey on ambient intelligence in healthcare,ā Proc. IEEE, vol. 101, no. 12, pp. 2470̢2494, 2013.

4. M. Maleshkova, C. Pedrinaci, and J. Domingue. ĀInvestigating Web APIs on the World Wide Web”. In Proc. ECOWS, Ayia Napa, Cyprus, 2010.

5. S. Avancha, C. Patel, and A. Joshi, “Ontology-driven adaptive sensor networks,” in First Annual International Conference on Mobile and Ubiquitous Systems,

Networking and Services, 2004, pp. 194–202.

6. M. Compton, H. Neuhaus, K. Taylor, and K. Tran, “Reasoning about sensors and compositions,” Proc. Semantic Sensor Networks, p. 33, 2009.

7. G. Jiang, W. Chung, and G. Cybenko, “Semantic agent technologies for tactical sensor networks,” in 2003 SPIE Conference on Aero Sense, 2003, pp. 21–25. 8. P. Barnaghi, W. Wang, C. Henson and K. Taylor. “Semantics for the Internet ofThings: Early Progress and Back to the Future”. International journal on Semantic

web and information systems. Volume 8, Issue 1. 2012.

9. M. Ruta, F. Scioscia, A. Pinto, E. Di Sciascio, F. Gramegna, S. Ieva, and G. Loseto. “Resource annotation, dissemination and discovery in the Semantic Web of

Things: a CoAP-based framework”. IEEE Internet of Things and IEEE Cyber, Physical and Social Computing. DOI 10.1109/GreenCom-iThings-CPSCom.2013

10. V. Charpenay, S. Kabisch, D. Anicic and H. Kosch. “An Ontology Design Pattern for IoT Device Tagging Systems”. 5th IEEE International Conference on the Internet of Things (IoT). 26-28 oct 2015. Seoul, South Korean.

11. M. Kovatsch, Y-N. Hassan and S. Mayer. “Practical Semantics for the Internet of Things: Physical States, Device Mashups, and Open Questions”. 5th IEEE

International Conference on the Internet of Things (IoT), 26-28 oct 2015. Seoul, South Korean, P 54-61.

12. R. Verborgh, V. Haerinck, T. Steiner, D. Van Deursen, S. Van Hoecke, J. De Roo, R. Van de Walle, and J. G. Vallès. “Functional Composition of Sensor Web

APIs”. In Proc. SSN, Boston, USA, 2012.

13. S. Mayer, N. Inhelder, R. Verborgh, R. V. de Walle, and F. Mattern. “Configuration of Smart Environments Made Simple - Combining Visual Modeling with

Semantic Metadata and Reasoning”. In Proc. IoT, Cambridge, MA, USA, 2014.

14. X. Su, H. Zhang, J. Riekki, A. Keranen, J-K. Nurminen, and L. Du. “Connecting IoT Sensors to Knowledge-Based Systems by Transforming SenML to RDF”. 5th

International Conference on Ambient Systems, Networks and Technologies (ANT-2014).

15. C. Jennings, Z. Shelby, J. Arkko, “Media Types for Sensor Markup Language (SENML)”, http://tools.ietf.org/id/draft-jennings-senml-10.txt. 2013-04-25.

16. N. Ayari, A. Chibani, Y. Amirat, and E. T. Matson, ĀA novel approach based on commonsense knowledge representation and reasoning in open world for

intelligent ambient assisted living services,ā in Proc. IEEE/RSJ Int. Conf. Intell. Robot. Syst. (IROS’15), 2015, pp. 6007̢6013.

17. A. Albreshne, A. Ait Lahcen, J. Pasquiera. “Using a Residential Environment Domain Ontology for Discovering and Integrating Smart Objects in Complex Scenarios”. International Workshop on Enabling ICT for Smart Buildings (ICT-SB 2014).

18. W. Wang, S. De, R. Toenjes, E. Reetz, and K. Moessner. ĀA Comprehensive Ontology for Knowledge Representation in the Internet of Things”. In the 11th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), 25-27 June 2012.

19. A. Yachir, Y. Amirat, A. Chibani, and N. Badache, ĀEvent-Aware Framework for Dynamic Services Discovery and Selection in the Context of Ambient

Intelligence and Internet of Things”. In IEEE Transactions on Automation Science and Engineering 2015, DOI: 10.1109/TASE.2015.2499792.

20. A. Yachir, Y. Amirat, A. Chibani, and N. Badache, ĀTowards an event aware approach for ubiquitous computing based on automatic service composition and

selection,ā Ann. Telecommun., vol. 67, no. 7̢8, pp. 341̢353, 2012.

21. A. Yachir, Y. Amirat, K. Tari, and A. Chibani, ĀQoS based framework for ubiquitous robotic services composition,ā in Proc. IEEE/RSJ Int. Conf. Intell. Robot.

Syst., (IROS’09), St. Louis, MO, USA, Oct. 11̢15, 2009, pp. 2019̢2026.

22. M. Compton, P. Barnaghi, L. Bermudez, R. Garcia-Castro, O. Corcho, S. Cox, J. Graybeal, M. Hauswirth, C. Henson, A. Herzog, et al. “The SSN ontology of the