semantic web 0 (0) 1 ios press situation-driven multi-purpose adaptation in the web … · semantic...
TRANSCRIPT
Semantic Web 0 (0) 1 1IOS Press
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
Situation-Driven Multi-Purpose Adaptation inthe Web of ThingsMehdi Terdjimi a, Lionel Médini b and Michael Mrissa c
a Aidaxis, 26 rue Louis Guérin 69100 Villeurbanne, FranceE-mail: [email protected] Univ Lyon, LIRIS, Université Lyon 1 - CNRS UMR5205 F-69622, FranceE-mail: [email protected] Innorenew, SloveniaE-mail: [email protected]
Abstract. Existing adaptation solutions for Web of Things (WoT) applications are tightly coupled with application domains.We propose a generic solution that relies on Semantic Web standards to make adaptation decisions for various concerns, usingcontextual information. We formalize multi-purpose adaptation rules to infer and rank adaptation possibilities. We proposemeta-rules to construct situation-driven sets of adaptation rules at application design time. As such, we propose a multi-layeredtheoretical framework that reduces the number of rules to produce coherent sets of adaptation decisions in various situations. Weevaluate the correctness and coverage of this framework on a sustainable agriculture scenario.
Keywords: Web of Things, Contextual Adaptation
1. Introduction
The ambition of the Web of Things (WoT) is to pro-vide a layer on top of the Internet of Things (IoT),where physical devices (things) can be involved insoftware applications in a standardized, interoperableand secure manner1. To do so, existing WoT specifi-cations rely on Web standards and semantic descrip-tions based on description logics (RDF [1], RDF-S [2],OWL2 [3]). WoT standards at large thus define seman-tic vocabularies to model physical data [4] (SemanticSensor Networks2) and devices (Thing Description3),as well as architectural elements (servient4, scriptingAPI5) reused in projects to design actual WoT applica-tions.
1https://www.w3.org/WoT/2https://www.w3.org/TR/vocab-ssn/3https://w3c.github.io/wot-thing-description/4https://w3c.github.io/wot-architecture/
#sec-servient-architecture5https://w3c.github.io/wot-scripting-api/
In the ASAWoO project6, we proposed a component-based framework to ease the development of such ap-plications in diverse domains (industry, healthcare,agriculture...). This framework [5] allows semanticallydescribing and running applications, so that their soft-ware elements (descriptions, code) are decoupled fromphysical (things, network) setups. The variety of tech-nical constraints, applications and tasks imposes WoTstandards and their implementations to cope with num-bers of situations: an application must be able to run ondifferent things, use different data sources and performseveral tasks.
Yet, contextual adaptation in such applications is amajor challenge. Existing adaptation solutions are ei-ther tightly coupled with their application domains (asthey rely on domain-specific context models) or of-fered as standalone software components that hardlyfit in Web-based and semantic architectures. The setsof adaptation goals are usually difficult to extend fornewly identified purposes, as it requires redefining the
6https://liris.cnrs.fr/asawoo/
1570-0844/0-1900/$35.00 c© 0 – IOS Press and the authors. All rights reserved
2 Situation-Driven Multi-Purpose Adaptation in the Web of Things
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
whole context model and – in worst cases – reconsid-ering the adaptation process itself. This leads to in-tegration, performance and maintainability problems.Hence, there is a need for an adaptation approach ableto remain independent from application domains andto comply with Web standards (e.g. resource-orientedarchitectures, semantic Web, Web of things) by design.The ASAWoO framework proposes a context manage-ment component that copes with these constraints. It isloosely coupled with semantic descriptions of relevantresources - including the application domain - and ap-plies generic reasoning techniques to enable domain-specific adaptation in WoT applications.
In this paper, we tackle the research question ofmulti-purpose contextual adaptation in WoT applica-tions. We aim to provide an adaptive solution thatbrings together contextual information and adaptationpurposes, to generate adaptation rules in both user-friendly and generic ways. We formally describe thetheoretical adaptation framework that supports contextmanagement and detail the design of adaptation rules.Our contributions are listed as follows:
1. A theoretical adaptation framework to supportdomain-independent multi-purpose adaptation
2. A generic model for/set of meta-rules to gener-ate adaptation rules that will in turn allow to inferranked adaptation possibilities
3. A comprehensive solution for both designers andexperts to efficiently process context models andadaptation rules using an incremental reasoningengine
This paper is structured as follows. In Section 2,we overview related work on adaptation classificationand WoT-based solutions. In Section 4, we formal-ize our contributions on domain independent multi-purpose context adaptation. In Section 5, we describethe meta-adaptation rule engine that allow generatingadaptation rules at design time. In Section 6, we eval-uate our solution on a sustainable agriculture scenario,on various situations. In Section 7, we open a discus-sion regarding the questions brought by our solution.We conclude this paper in Section 8.
2. Related work: semantic approaches foradaptation in the Web of Things
[6] classify adaptation approaches according to sev-eral characteristics: functional vs. nonfunctional, de-signed vs. unanticipated, predictable vs. unpredictable,
third-party vs. self-adaptive (i.e. provoked by the adap-tation software itself) and business-specific vs. generic.Another adaptation classification from [7] includes thenotions of anticipation (as the degree of anticipationto changes) and domain-specificity (as the level ofparametrization of the adaptation solution) as well. Italso introduces two additional characteristics to posi-tion adaptation solutions: tools (denotes whether theadaptation solution comes with a dedicated develop-ment environment or a runtime monitoring environ-ment) and scope (describes the extent of the adap-tation process over the application components andservices). In this work, we target generic and largelyscoped contextual adaptation techniques. In this sec-tion, we position our research with respect to existingwork on generic adaptation, semantics-based adapta-tion, semantics-based WoT solutions, and adaptationrule generation.
2.1. Generic adaptation frameworks
Several techniques can be used to adapt a soft-ware system to contextual parameters: service con-figuration, service substitution and adaptation plan-ning [6, 8] [7, 4.4]. The following adaptation frame-works illustrate these techniques and stress their ad-vantages and drawbacks for generic adaptation ap-proaches.
In [9], the authors provide a service configurationadaptation approach that is generic and based on ref-erence models. It aims to ease the design of adaptationsolutions for business processes that are shared by var-ious participants, based on a multidimensional contextmodel and complex transformation rules. The fact thata service configuration engine has to generate numer-ous parameters makes such an approach strongly para-metric and does not guarantee optimal adaptation de-cisions. Moreover, it is more difficult for a domain ex-pert to completely formalize the transformation func-tion than to express its behavior in natural language.
In the Adaptive CORBA Template (ACT) [10], theauthors propose a service substitution approach for dy-namic adaptation based on CORBA middleware inter-ceptors. Such interceptors can be registered, unregis-tered and enhanced at runtime, thus producing adapta-tion cases that are not known in advance. This frame-work is domain-independent, partially anticipatory asit preconfigures so-called adaptive CORBA templatesand its adaptation scope can address different tasksthrough the use of rule-based interceptors. In this sense– and even though it requires the CORBA middleware,
Situation-Driven Multi-Purpose Adaptation in the Web of Things 3
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
which is neither tailored for resource-limited devicesand nor compliant with Web standards - it is close tomore recent approaches such as aspect-oriented adap-tation [11], as well as to substitution of service-basedapplications [12], or more generally to adaptation indynamic, component-based middlewares.
WComp [13] is an aspect-oriented, Web service-based middleware that relies on the Aspect of As-sembly (AA) aproach to provide compositional adap-tation of event-based services, depending on contextchanges. The adaptation decision relies on aspect-oriented concepts, such as joint points, pointcuts, ad-vices, etc.
The FraSCAti platform [14] aims to extend the Ser-vice Component Architecture (SCA) [15] by provid-ing reflexive behavior for service oriented architecturecomponents. To do so, each component is associatedto a generic container (at a meta level of the architec-ture) that includes several services such as componentidentity, lifecycle, hierarchy, wiring, etc.
The Mobility and ADaptation enAbling Middle-ware (MADAM) framework [16] applies an adaptationplanning approach to ease the development of adap-tive solutions. At request time, it chooses the combi-nation of available services to compose a response toa particular user’s need. To do so, it provides severalmanagers (context, configuration and adaptation man-agers) that allow for decoupled adaptation processes.Moreover, it relies on "context reasoners", which aregeneric means to locate sensor data processing in theadaptation workflow. In the perspectives, the authorsforesee to reuse this approach using Web services andsemantic Web technologies.
2.2. Semantics-based adaptation approaches
By essence, context is metadata. Behind the well-known definition of context by Anind Dey [17] "Con-text is any information that can be used to character-ize the situation of an entity[...]" emerges the notionof information annotation, and therefore of generat-ing graphs of interrelated pieces of data. The seman-tic Web was built to ease and to standardize the cre-ation, handling, querying and transformation of suchgraphs [18]. Hence, it appears quite relevant to use se-mantic web languages (RDF, RDF-S, OWL)7 to modelcontextual information, as well as to reason about con-textual data to make adaptation decisions.
7https://www.w3.org/2001/sw/interest/
[19] present a semantic adaptation framework formultimedia documents in which they describe docu-ments as sets of parts related by constraints. Althoughthey only apply adaptation to this domain, their for-malization makes their approach quite reusable, eventhough they use an on-purpose graph matching algo-rithm rather than classical reasoning tools. The workpresented in [20] proposes a generic approach basedon the semantization of sensor data and a context in-telligence module, that partly relies on a semantic rea-soner to provide adaptation propositions. However, tothe best of our knowledge, [21] describes the first workto use both rule-based reasoning for context adapta-tion, as well as the expressivity of high-level descrip-tion logics constructs available in OWL relations.
Hence, the potential offered by Web-based reason-ing and semantic technologies could provide adapta-tion in WoT applications in a generic, flexible andreusable manner, for multiple and high-level purposes.In this view, we intend to comply with Web standardsfor data exchange (SOSA/SSN vocabularies, StreamsAPI8) and with the W3C WoT Working Group specifi-cations (Thing Description, Servient), while designingour adaptation solution for WoT applications.
2.3. Semantics-based WoT platforms
To reason about contextual data, semantic adapta-tion tools must first gather semantized data. In theWoT application field, not all platforms provide se-mantic data to their components. Actually, only re-cent advances in the WoT aim to bring together theSemantic Web with Web standards, on top of the In-ternet of Things. UBIWARE [22] uses semantic an-notations to describe agents and behavioral tasks, toprovide interoperability and reusability of these defini-tions. SPITFIRE [23] unites RESTful approaches us-ing CoAP [24] with OWL/RDFS and SPARQL9 forconstraint devices. Sense2Web [25] allows publishingsensor data and measurements on the Web through aSPARQL endpoint, but still has to be coupled with afunctional solution to provide a complete WoT appli-cation capable of managing any type of thing (sensoror actuator). The M3 framework provides a more com-prehensive and domain-independent approach througha dedicated vocabulary to describe sensors, togetherwith the tools to reason about these descriptions anddeduce application templates [26]. While these ap-
8https://www.w3.org/TR/streams-api/9https://www.w3.org/TR/rdf-sparql-query/
4 Situation-Driven Multi-Purpose Adaptation in the Web of Things
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
proaches facilitate things interoperability and WoT ap-plication development, they do not tackle the adapta-tion concern.
2.4. Automatic generation of rules
Dynamic context-aware environments involve alarge number of parameters (system resources, per-ceived environment, user preferences, etc.). Defin-ing an analytical workflow starting from all these pa-rameters and resulting in an adaptation decision isa complex task [27–29] that is often achieved usingrules. This large number of parameters causes a "rule-explosion" problem [27] that would, in theory, forceapplication developers to state all possible parametercombinations to make sure that every situation willmeet an adaptation plan. In this section, we presentsome approaches that prevent developers from issuingall these rules. The first approach is based on reuti-lization. S-LOR [30] allows sharing rules as LinkedData using a Linked Open Data vocabulary, and pro-vides means to integrate those rules in semantic rea-soners through the Jena API. Though this approachis promising, the rules that have been shared yet aredesigned for the interpretation of sensor data as se-mantic information rather than for adaptation. Anotherapproach is to reduce the coupling between applica-tions and adaptation solutions by automatically pro-ducing domain-specific rules from generic representa-tions. Still, challenges remain in the domain of rulesgeneration. [31] propose a business rule design frame-work that relies on the Semantics of Business Vocab-ulary and Business Rules (SBVR) formalism10. Themethod described in [32] generates such rules in thesame manner, while providing a semantic formaliza-tion of them as SPARQL queries. However, both meth-ods requires application users and domain experts toexpress each rule in natural language and are intendedfor functional purposes only.
The reflexive method presented in [33] allows gen-erating on-the-fly adaptation rules based to support dy-namic changes on a system. However, this adaptationsolution is exclusively nonfunctional, centralized, andmay not scale in environments with numerous con-nected objects. This method also does not provideadaptation possibilities ranking, and therefore cannotensure optimal adaptation decisions. The solution pre-sented in [34] infers rules with respect to contextual
10http://www.omg.org/spec/SBVR/
information, referred as the user’s behavior. This how-ever requires sufficient data to provide significant ac-curacy. Such method is appropriate for recommendersystems, but not for adaptive systems on critical do-mains (such as security, healthcare, driving, etc.), asthey require highly accurate adaptation rules as soonas the application starts.
3. Scenario
To illustrate our approach and contributions, weconsider a vineyard-watering application. This appli-cation detects parts of the field that need to be watered,while taking environmental conditions into account.A WoT infrastructure hosts this application, which in-cludes a cloud infrastructure, several wireless gate-ways as well as an irrigation system composed of ge-olocated watering agribots and drones that embed aGPS sensor and a thermal camera. Drones and agri-bots have the ability to move over/across the field todetect/water given parts of the field.
While the application is active, several sensors(which are placed on each part of the field) regularlysend data to agribots to adapt their behavior with re-spect to the information given (e.g. the presence of en-tities would disable their moving and watering func-tionalities). Drones possess a thermo-sensing cameraalong with a CPU to process field images. If a dronecannot process a picture (due to limited memory orhigh CPU usage), it sends the picture to another droneto fulfill the task. The drone then communicates withthe suitable agribots to take care of the parts that lackwatering. Other devices consist in a desktop computerto host the WoT infrastructure, as well as a tablet al-lowing users to remotely monitor the system.
In this scenario, the WoT application is designedas a hierarchy of functionalities, with the ManageWa-tering functionality on top of it. The latter is com-posed of several functionalities, among which Spray-Water and DetectWateringNeeds, which implies Take-HdPicture, ProcessPicture and TransferPicture. Com-plex processing task can be be executed either on thecloud platform, or on the device itself. We considera field equiped with an anemometer, a thermometerand a pluviometer to sense actual weather conditions.Drones are equiped with a GPS sensor, a thermal cam-era, a Wifi and a Bluetooth network interfaces, and areable to sense their hardware status (battery level, stor-age capacity, CPU usage, storage space).
Situation-Driven Multi-Purpose Adaptation in the Web of Things 5
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
4. Contextual Adaptation in the WoT
The ASAWoO project issued a freely available WoTplatform11. This platform is a runtime environmentfor WoT applications that are composed of high-levelfunctionalities, constructed on top of the capabilitiesavailable through the things APIs and provided by theirmanufacturers.
To build such applications, the ASAWoO approachstates that each physical thing has its own avatar [5].An avatar is a form of servient implementation: it pro-vides a virtual representation of this thing as a Web re-source, monitors and controls the capabilities of thisthing, and augments its interaction patterns by expos-ing application functionalities. Avatars expose func-tionalities that can either be atomic (i.e. directly im-plemented by the thing physical capabilities), or com-posed by lower-level functionalities.
Within the ASAWoO platform, an avatar has acomponent-based architecture that allows its elements(aka "managers") to exchange semantic data. Man-agers are designed to tackle different concerns: net-work disconnections, social interactions, and naturallydynamic adaptation. In particular, managers allow theimplementation, composition, exposition, communi-cation with and location of the object functionalities.Hence, each of them deals with a specific purpose, andthese purposes may require adaptation to the context.
4.1. Contextual Modeling
In our previous work from [35], we have shown thatcontextual information can be diverse amongst appli-cation domains. Most of the literature group informa-tion thematically. We hereafter formalize concepts re-lated to the context and its adaptation.
A contextual instance is a high-level piece of con-textual information. In our work, contextual instancescan be either inserted at design time as semantic infor-mation by WoT application designers (e.g. user prefer-ences, regional settings, device static information, etc.)or inferred at design time from raw sensor data usingrule-based semantic reasoning. We group these contex-tual instances in thematic sets called contextual dimen-sions.
11https://asawoo.gitlab.io/
4.1.1. Contextual DimensionLet i be a contextual instance, i.e. a high-level, se-
mantized piece of contextual data. We define contex-tual dimensions as follows:
Definition 1 (Contextual dimension). A contextual di-mension d represents the set of contextual instancesneeded for any adaptation purpose, regarding a giventype of observation (temperature, location, etc.).
d = {id}, d ∈ D where D is the set of availableobservations that are relevant for the application.
For instance, in our scenario, we use “Temperature”as a contextual dimension, which groups the followingcontextual instances: {Hot,Warm,Cold}.
4.1.2. Adaptation PurposeWoT application execution can rely on different
types of adaptation we call adaptation purposes. Toavoid the redefinition of specific contextual dimen-sions and allow the instantiation of reusable domain-specific context models, we have propose a meta-model for context in WoT application. This meta-model relies on cross-domain adaptation purposes andpromotes the usage of identical reasoning mechanismsfor any application domain, through common ontolog-ical concepts. We formally define an adaptation pur-pose as follows:
Definition 2 (Adaptation purpose). An adaptationpurpose ap represents the set of contextual instancesrelated to a certain type of adaptation, as describedabove.
ap = {iap}, ap ∈ AP .
In the ASAWoO platform, the different managersthat compose the avatar architecture require the setAP = {Imp,Comp, Exp, Prtcl,CdL} of adaptationpurposes explained below:
– Imp Finding the best capability to implement anatomic functionality,
– Comp Finding the best lower-level functionalitiesto take part in a functionality composition (ex-posed by either the local avatar or other avatars),
– Exp Deciding whether to expose or not a func-tionality to other avatars and users,
– Prtcl Finding the most suitable network protocolto communicate with the thing during the execu-tion of a functionality,
– CdL Finding the optimal location for applicationcode modules (e.g. on the thing processing unit,on a closeby gateway or on a cloud infrastruc-ture).
6 Situation-Driven Multi-Purpose Adaptation in the Web of Things
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
While for the Exp purpose, the adaptation possibili-ties are either to expose a functionality or not, the pos-sibilities for the other purposes may be multiple.
4.1.3. Multi-Purpose Context ModelThe meta-model we have proposed allows to build
multi-purpose context models using both contextualdimensions and adaptation purposes. At adaptation so-lution design time, WoT application designers discusswith domain experts to determine the appropriate con-textual dimensions and adaptation purposes compos-ing the context model, as well as the contextual in-stances that will populate the model at runtime. We de-fine such models as follows:
Definition 3 (Context model). A context model Mis a two-dimensional set of contextual instances cor-responding to both adaptation purposes APM andcontextual dimensions DM. Within a given modelM,dimensions and adaptation purposes are respectivelydisjoint in DM and APM.M = APM × DM = {iapM,dM} where apM ∈
APM and dM ∈ DM.
The context model for our scenario is composed ofthe following dimensions: Wind, Dryness, Tempera-ture, Location, Battery, Memory, CPU and Resolution.For each purpose, we have different sets of contextualinstances, depending of the adaptation needs. These in-stances are depicted in Figure 1. Sometimes, a dimen-sion may not be useful for a given purpose. In that case,its list of instances is marked as not applicable (n/a) onthe figure.
We justify our adaptation purposes association withdimensions as follows:
– Imp Choice of capability to implement TakeHd-Picture depending on the available memory andCPU on the device, as well as on its camera reso-lution.
– Comp Composition of DetectWateringNeeds de-pending on the drone location and battery level(sufficient to move towards the field to take pic-tures from), as well as on its available storagespace (to save pictures taken).
– Exp Exposition of the functionality SprayWaterrequiring acceptable weather conditions.
– Prtcl Choice of protocol to send pictures withTransferPicture depending on the device locationand on its battery level (as some protocols aremore energy consuming).
– CdL Location of the ProcessPicture functionalitycode depending on available memory, battery and
CPU on the device. The code can be deployed ei-ther on the device itself or on the cloud.
4.2. Contextual Adaptation Workflow
The solution we propose relies on adaptation plan-ning. In our previous work [36], we have presenteda contextual adaptation solution that infers ready-to-query adaptation possibilities for multiple adaptationpurposes from both static information and raw sensordata using semantic reasoning. The work we have pro-posed in [37] details the runtime process: when an-other manager needs to make an adaptation decisionconcerning a particular purpose, it sends an adapta-tion question to the context manager. Processing suchquestions is reduced to a simple purpose-dependentSPARQL SELECT query to the endpoint. The steps ofthis workflow are depicted in Figure 2 and detailed inthe subsections below.
4.2.1. Semantization stepThe contextual adaptation solution we have pro-
posed in [36] relies on semantized contextual instancesimplemented as RDF triples. At runtime, sensor dataare sent to avatars and are converted into RDF triplesby the appropriate manager. For instance, a such man-ager could generate the graph shown in Listing 1:
Listing 1: Example of a semantized temperature observation basedon SOSA and SSN (in N3).
1 @prefix sosa: <http://www.w3.org/ns/sosa/> .
2 @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
3 @prefix qudt-1-1: <http://qudt.org/1.1/schema/qudt#> .
4 @prefix qudt-unit-1-1: <http://qudt.org/1.1/vocab/unit#> .
56 <observation/1087> rdf:type
sosa:Observation ;7 sosa:resultTime "2018-12-14T12:00:00Z
"^^xsd:dateTime ;8 sosa:hasFeatureOfInterest <Air?lat
=45.80902&long=4.94993> ;9 sosa:hasResult [10 a qudt-1-1:QuantityValue ;11 qudt-1-1:unit
qudt-unit-1-1:DegreeCelsius ;12 qudt-1-1:numericValue "20.388"^^
xsd:double ] .
Situation-Driven Multi-Purpose Adaptation in the Web of Things 7
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
Wind Dryness Temperature Location Battery Memory CPU Resolution
Imp n/an/a n/a n/a n/a HighCPUPict LowCPUPict
HD AvgQuality LowQuality
Comp n/a n/a CloseToField FarFromField
HighBattComp LowBattComp n/a
Prtcl n/an/a n/a Close Far
HighBattPrtcl LowBattPrtcl n/a n/a
CdL n/a n/a n/a n/a HighBattCode LowBattCode
HighMemCode LowMemCode
HighCPUCode LowCPUCode
HighMemPict LowMemPict
HighMemComp LowMemComp n/an/a
Contextual Dimensions
ExpDry Wet
Flooded
StrongWind BreezeNoWind
Hot Warm Cold
Contextual Instances
n/a n/a n/an/a
Adaptation Purposes
n/a
n/a
n/a
Fig. 1. The context model of our scenario.
Fig. 2. The contextual adaptation workflow
4.2.2. Transformation stepAs soon as numerical values are semantized as RDF
triples, they are inserted into the avatar internal seman-tic reasoner to be transformed into contextual instancesusing transformation rules. Transformation rules re-lies on thresholds and upper limits provided by expertsto infer appropriate contextual instances. For example,inserting the observation in Listing 1 will infer the con-textual instance Warm, considering the threshold be-tween Cold and Warm is 20 degrees.
At runtime, contextual instances are inserted inand deleted from the semantic repository, which isequipped with both a SPARQL endpoint and an OWL2RL incremental reasoner. Context models are instanti-ated this way; each cell of the matrix contain one con-textual instance, or is empty in the case of a contex-tual dimension is not applicable for a given adaptationpurpose (e.g. the dimension “Location” and Imp in ourscenario).
We define subsets of instantiated contextual modelsas contextual situations. A contextual situation is iden-tified by domain experts to design appropriate adapta-tion rules in response of these situations. We define itas follows:
Definition 4 (Contextual situation). A contextual situ-ation ς is a subset of an instantiated context model thatcharacterizes a salient situation identified by domainexperts.ς = {i j,k} where j ∈ AP ∪ ∅ and k ∈ D ∪ ∅
For example, in our scenario, the experts referto a situation “FarDroneWithLowBatteryForTrans-fer” which consists in the set of contextual instances{Far, LowBatteryPrtcl}.
4.2.3. Adaptation stepAdaptation possibilities are triples inferred using
business-specific adaptation rules at the insertion ofcontextual instances, and removed at their deletion us-ing incremental reasoning. Their subject is the func-tionality to be adapted in the application, the predicateis related to the purpose, and the object is the adapta-tion candidate12. Table 1 below shows the possibilitytriple patterns for each purpose.
12An adaptation candidate is an available resource that can satisfythe given adaptation purpose, i.e. of the type corresponding to thispurpose. For instance, for the Prtcl purpose, it must be a protocolimplemented on the device network interface.
8 Situation-Driven Multi-Purpose Adaptation in the Web of Things
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
Table 1Patterns of possibility triples for each adaptation purpose.
Purpose Subject Type Predicate Object Type
Imp Functionality hasS uitableCapabilityForImplementation Capability
Comp FunctionalityhasS uitableFunctionalityToTakePartInComposition
Functionality
Exp Functionality hasExposability Exposability
Prtcl Functionality hasS uitableProtocol Protocol
CdL Functionality hasS uitableCodeLocation CodeLocation
Definition 5 (Adaptation possibility). An adaptationpossibility p associates an adaptation candidate to afunctionality to be adapted, with respect to an adapta-tion purpose. The set of possibilities for the same adap-tation purpose is denoted P.
p f ,ap : f , ap → c where f is a functionality, c is acandidate and p f ,ap ∈ P f ,ap.
For instance, in our scenario, the adaptation of com-munication protocols for the TransferPicture function-ality may have either Wifi of Bluetooth protocols asadaptation candidates.
Adaptation possibilities are inferred from contex-tual instances using adaptation rules. Adaptation ruleshave similar patterns, regardless of their adaptationpurposes: the body of the rule is a conjunction of con-textual instances, i.e. a contextual situation, and thehead of the rule is a set of adaptation possibilities.
Definition 6 (Adaptation rule). An adaptation rule isa conjunctive rule in the form:
∧k6|ς| ik → P where
ik ∈ ς is a contextual instance and P a set of inferredadaptation possibilities p. Each purpose ap ∈ AP isassociated to a setRap of adaptation rules.
In ASAWoO, contextual instances that trigger adap-tation possibilities are respectively associated to capa-bility instances for Imp, and to functionality instancesfor Comp. An example of adaptation rule in our sce-nario isi f {Dry, Breeze, Warm}then {(SprayWater hasExposability Exposable)}
4.2.4. ScoringTo allow an optimal decision amongst several adap-
tation possibilities regarding a particular contextualsituation at runtime, our solution relies on scoring.This score is determined as follows. At design time,each possible contextual situation is presented to thedomain expert. The expert then suggests an appropri-ate response to this situation, to allow the WoT appli-
cation designer to determine which capabilities/func-tionalities are the most/least appropriate to implemen-t/compose a functionality, which functionalities shouldnot be executed (i.e. should not be exposed to clients),which protocols shoud be used, or where the function-ality code should be located. The “most/least” degreeis thereafter interpreted as a score for this adaptationpossibility with respect to the observed situation.
Making binary decisions then consists in selectingan adaptation possibility if its score equals 1. Findingthe best candidate for another purpose consists in se-lecting the possibility with the highest score.
Definition 7 (Scoring function). Each instance of acontext model is associated to a scoring function s fthat depends on its situation and allows to weight sev-eral adaptation possibilities. As scoring function re-sults will be summed for each adaptation purpose,their results are normalized by the number of consid-ered dimensions.
s f : iapM,dM , ς → {spn},∀pn ∈ P f ,apM with spn ∈[0; 1
|DM| ].
Definition 8 (Adaptation score). An adaptation scores is a numeric value that allows to weight an adap-tation possibility for an adaptation purpose. Scoresare normalized, situation-dependent and obtained us-ing scoring functions.
sς, f ,ap,p =∑|DM|
k=1 Πp(s f (iapM,k, ς)) with Πp theprojection of the result set of s f on the possibility pand 0 6 sς,ap,p 6 1.
To determine the score of a composition candidatefor the Cmp purpose, we calculate the average of eachfunctionality scores that are part of the composition.Hence, if a functionality can be composed in severalways, the composition with the highest score would bechosen.
Situation-Driven Multi-Purpose Adaptation in the Web of Things 9
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
4.2.5. Decision stepAdaptation possibilities are queried at runtime, us-
ing adaptation questions. These questions are formu-lated as SPARQL SELECT queries. Their pattern isbased on the vocabulary described in Definition 5:subjects are the components to adapt (a capability ora functionality), predicates are based on the adapta-tion purpose, and objects are the adaptation candidates.Adaptation possibilities are linked with their purpose-based score through blank node reification, so thateach possibility is ranked using an ORDER BY clauseon the scores. The pattern of a generic SPARQL-basedadaptation question is the following:
Listing 2: General SPARQL expression of an adaptation question.
1 PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
2 SELECT ?adaptationPossibility ?score {3 [] rdf:subject ?componentToBeAdapted ;4 rdf:predicate ?adaptationPurpose ;5 rdf:object ?adaptationPossibility ;6 rdf:value ?score . }7 ORDER BY ?score
The adaptation question for the Exp purpose requiresan additional FILTER clause on the score (this scoremust be strictly positive to allow exposability). In thenext section, we propose a generic way to design adap-tation rules and determine scores by relying on metaadaptation rules.
5. Advanced adaptation rule management
Providing fully automatic generation of adaptationrules without any interaction from users, experts or ap-plication designers is a very long term challenge. Still,we believe that the involvement of each participant inthe WoT application design process can be simplifiedand reduced. In this work, we improve the declarativityof this process by proposing a method to generate rulesat application design time. Moreover, we are aware thatunder certain circumstances (such as crisis), applica-tions should behave in different manners (e.g. adopta degraded mode to ensure users’ safety). Hence, wealso introduce the notion of situation-based rule gen-eration, which also reduces the number of adaptationrules.
In this section, we present how we build adapta-tion rules at design time and detail our meta adapta-tion rule engine that generates scored adaptation rules.
This engine 1) generates contextual situations, 2) gen-erates adaptation possibilities, 3) combines these ele-ments with scoring functions to apply a score on eachadaptation possibility, and 4) outputs a set of adapta-tion rules using the situations and the scored adapta-tion possibilities.
5.1. Meta adaptation rule engine main components
The meta adaptation rule engine generates a set ofadaptation rules at design time. This process can beexecuted as soon as the context model is designed,yet before starting the adaptive solution (as it actuallyrequires adaptation rules to work). This engine relieson a triplestore that supports SPARQL SELECT andCONSTRUCT queries, and takes semantically anno-tated information as input. The architecture of the metaadaptation rule engine is depicted in Figure 3 and isdetailed in the subsections below.
5.2. Situation Generation
At first, the context model is loaded into the enginetriple store by the solution designer. The engine takesthe contextual dimensions, the contextual instancesand the adaptation purposes from the loaded model,as input. An example of imported purpose, dimension,and instance is listed in Listing 3 below. We use thesemantic relationships between contexutal instances i,dimensions d ∈ DM and purposes ap ∈ APM fromDefinitions 1 to 3.
Listing 3: Example of data inserted onto the triplestore to generatesituations (in N3).
1 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
2 @prefix asawoo-ctx: <http://liris.cnrs.fr/asawoo/vocab/context.owl#>.
3 @prefix asawoo-wtr: <http://liris.cnrs.fr/asawoo/vocab/watering-application.owl#>.
45 # Exposition Purpose6 asawoo-wtr:Exp rdf:type
asawoo-ctx:AdaptationPurpose ;7 asawoo-ctx:purposePredicate
asawoo-ctx:hasExposability .89 # Wind Dimension10 asawoo-wtr:Wind rdf:type
asawoo-ctx:ContextualDimension .11
10 Situation-Driven Multi-Purpose Adaptation in the Web of Things
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
Fig. 3. The meta adaptation rule engine, its components and inputs.
12 # NoWind Instance13 asawoo-wtr:NoWind rdf:type
asawoo-ctx:ContextualInstance ;14 asawoo-ctx:instanceFromDimension
asawoo-wtr:Wind ;15 asawoo-ctx:instanceForPurpose
asawoo-wtr:Exp .
Then, the situation generation module sends aSPARQL query to the triplestore to determine eachpossible contextual situation, for each purpose. Algo-rithm 1 below generates such query. As stated in Defi-nition 4, each contextual situation ς is a set of distinctcontextual instances i j,k, where j ∈ AP and k ∈ D.
ALGORITHM 1: SPARQL situation query generationData: An adaptation purpose ap and a set D of
contextual dimensions that compose the contextmodel.
Result: A SPARQL query that determines eachpossible contextual situation for ap.
query← generateS electQuery(),instancesVariables← [ ]
foreach D ∈ D doi← generateNewInstanceVariable()instancesVariables.push(i)query.appendBody(”OPTIONAL { ”)query.appendBody(”i rdf:type
ContextualInstance”)query.appendBody(”i instanceForPurpose ap”)query.appendBody(”i instanceFromDimension d”)query.appendBody(” }”)
query.setDistinctVariables(instancesVariables)return query
In Algorithm 1, the function generateNewInstanceVariable()is used to create a new variable to be selected, the
function appendBody() adds a triple pattern (or OP-TIONAL clause) in the body of the query, and thefunction setDistinctVariables() adds a DISTINCTclause with the corresponding variables to be selected.
5.3. Adaptation Possibility Generation
The adaptation possibility generation step producesadaptation possibilities using the application domainfunctionalities, the architecture information related tocandidates (protocols, code hosts), and the adaptationpurposes. To do so, it populates the triplestore withthese semantically-annotated information and gener-ates a graph of adaptation possibilities for each pur-pose, using the following query:
Listing 4: CONSTRUCT query to retrieve the graph of adaptationpossibilities.
1 PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
2 PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
3 PREFIX asawoo-ctx: <http://liris.cnrs.fr/asawoo/vocab/context.owl#>
4 CONSTRUCT {5 ?adapted ?possibilityPred ?candidate6 }7 WHERE {8 ?purpose asawoo-ctx:purposePredicate9 ?possibilityPred .10 ?possibilityPred rdfs:domain11 ?adaptedClass .12 ?possibilityPred rdfs:range13 ?candidateClass .1415 ?adapted rdf:type ?adaptedClass .16 ?candidate rdf:type ?candidateClass .17 }
Situation-Driven Multi-Purpose Adaptation in the Web of Things 11
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
In Listing 4, the triple patterns at lines 6-8 allow re-trieving the adaptation purposes domains and ranges,so that each possibility is generated through the CON-STRUCT pattern (line 4). The adapted/candidate andtheir classes from lines 9 and 10 refer to the subjectsand objects enumerated in Section 4 – Table 1. The setP of adaptation possibilities generated in this processis based on Definition 5.
5.4. Score management
To calculate possibility scores for each situation, thescore application step combines contextual situationswith adaptation possibilities and their scoring func-tions. Scoring functions are represented as triples, asfollows:
– their rdf:type is asawoo-ctx:ScoringFunction,– they are linked respectively to a dimension and
to an adaptation purpose through the objectproperties asawoo-ctx:applicableTo and asawoo-ctx:forDimension,
– they are reified using the object property asawoo-ctx:scores,
– this reification includes four object properties,based on Definition 8• asawoo-ctx:forCandidate for the adaptation
possibility candidate p,• asawoo-ctx:forAdapted for the adapted func-
tionality f ,• asawoo-ctx:withInstance for the contextual
instance i,• rdf:value for the score s.
These relationships are based on the formalizationof the scoring function s f detailed in Definition 7. Be-low is an example of scoring function for the Blue-tooth candidate, to adapt the communication protocolto transfer a picture (in N3 syntax):
Listing 5: N3 description of a scoring function (Battery dimensionand Prtcl purpose).
1 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
2 @prefix asawoo-ctx: <http://liris.cnrs.fr/asawoo/vocab/context.owl#>.
3 @prefix asawoo-wtr: <http://liris.cnrs.fr/asawoo/vocab/watering-application.owl#>.
45 asawoo-wtr:F1 rdf:type
asawoo-ctx:ScoringFunction .
6 asawoo-wtr:F1 asawoo-ctx:applicableToasawoo-wtr:Prtcl .
7 asawoo-wtr:F1 asawoo-ctx:forDimensionasawoo-wtr:Battery .
89 asawoo-wtr:F1 asawoo-ctx:scores [10 asawoo-ctx:forCandidate
asawoo-wtr:Bluetooth ;11 asawoo-ctx:forAdapted
asawoo-wtr:TransferPicture ;12 asawoo-ctx:withInstance
asawoo-wtr:HighBattery ;13 rdf:value "0.5"^^xsd:double ] .
After importing instances, scoring functions andpossibilities, the SPARQL query from Listing 6 be-low is processed, to calculate scores for each group(contextual situation, adapted functionality, possibilitycandidate). Line 4-6 select the atoms that will com-pose each respective adaptation rule, compute the to-tal score of the possibility candidate with the SUMaggregate (line 5), and retrieve each contextual in-stance from the current contextual situation using theGROUP_CONCAT aggregate at line 6 (these two ag-gregates come with the corresponding GROUP BY atline 19). Lines 8-10 link the adaptation possibility withthe contextual situation. Line 12 retrieves the scor-ing functions applicable to the current purpose. Lines13-17 then retrieve the score of each contextual in-stance that belongs to the current contextual situation,by reification.
Listing 6: SPARQL query that retrieves each group of atomscomposing the scored adaptation rules.
1 PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
2 PREFIX asawoo-ctx: <http://liris.cnrs.fr/asawoo/vocab/context.owl#>
34 SELECT DISTINCT ?adapted ?purposePred ?
candidate5 (SUM(?score) AS ?candidateScore)6 (GROUP_CONCAT(?contextInstance) AS ?
instances) {7 ?adapted ?purposePred ?candidate .8 ?purpose asawoo-ctx:purposePredicate
?purposePred .9 ?contextSituation
asawoo-ctx:containsInstance ?contextInstance .
1011 ?scoringFunction
asawoo-ctx:applicableTo ?purpose.
12 Situation-Driven Multi-Purpose Adaptation in the Web of Things
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
12 ?scoringFunction asawoo-ctx:scores [13 asawoo-ctx:withInstance ?
contextInstance ;14 asawoo-ctx:forCandidate ?candidate
;15 asawoo-ctx:forAdapted ?adapted16 rdf:value ?score ]17 } GROUP BY ?adapted ?purposePred18 ?candidate ?contextSituation
Afterwards, each score is divided by the number ofeffective contextual instances from each contextual sit-uation, to avoid invalid score computation if a contex-tual instance is missing (e.g. when a sensor is unableto send data).
5.5. Adaptation Rule Generation
The adaptive rule generation step produces a set ofadaptation rules (in the form detailed in Definition 6)using the SELECT bindings returned by the scoringapplication step. Algorithm 2 below details this pro-cess.
ALGORITHM 2: Scored adaptation rule generationData: A set B of SPARQL bindings with the variables {
adapted, purposePredicate, candidate,candidateS core, instances } corresponding tothe scoring application output.
Result: A set R of conjunctive adaptation rules.R← [ ]foreach b ∈ B do
cause← new Con junction()foreach atom ∈ b.instances do
cause.addCon junctiveAtom(”atomasawoo-ctx:isEffectiveInstance xsd:true”)
consequence← new Con junction()consequence.addCon junctiveAtom(” _:blankNode
rdf:subject b.adapted”)consequence.addCon junctiveAtom(” _:blankNode
rdf:predicate b.purposePredicate”)consequence.addCon junctiveAtom(” _:blankNode
rdf:object b.candidate”)consequence.addCon junctiveAtom(” _:blankNode
rdf:value b.candidateS core”)tmpRule← R.getRuleWithCause(cause)if tmpRule ! = null then
tmpRule.addConsequence(consequence) ;else R.push(new Rule(cause, consequence));
return R
In Algorithm 2, causes and consequences are gener-ated using the function addCon junctiveAtom(), which
adds an atom (a triple) in the conjunction. The causeis a conjunction of contextual instances, and theconsequence is a set of scored adaptation possibil-ity (i.e. a set of reified blank nodes, as describedin the Definition 5 from Section 4). The predicateasawoo-ctx:isEffectiveInstance denotesthe current presence of contextual instances in themodel, which would trigger the suitable adaptationrules. At each loop, if a rule with the generated causealready exists in the set (getRuleWithCause() func-tion), the generated consequence is added this al-ready existing rule (addConsequence() function). Oth-erwise, a new adaptation rule is created and added tothe set of adaptation rules. After this step, the metaadaptation rule engine finally outputs the set of adap-tation rules, to be integrated onto each avatar reasoner.
6. Evaluation
In this section, we present two different kinds ofevaluations of our situation-based approach. We firstevaluate its correctness by ensuring the adaptation re-sults correspond to the expected adaptation results fordifferent situations. Second, we verify that our ap-proach covers every kind of adaptation question for ev-ery situation. In both cases, we evaluate our theoret-ical solution through the sustainable agriculture sce-nario described in Section 3. We ran all experimentson a Dell OptiPlex 780 - Core 2 Duo E8400 @ 3 GHzand used Stardog 4.2.313 as a triplestore.
6.1. Situation-based adaptation correctness
We evaluate the correctness of our solution, i.e. wecheck that the adaptation rules generated by our so-lution produces the expected scored adaptation possi-bilities, with respect to the purposes described in theprevious subsection. We consider the following situa-tions: 1a) and 1b) are two different situations for theimplementation of TakeHdPicture by different drones(distinct storage capacities and camera resolutions);2a) and 2b) are two different drone situations for thecomposition of DetectWateringNeeds (distinct loca-tions and storage capacities); 3) queries the SprayWa-ter exposability during a flood; 4) requires the Trans-ferPicture to choose a protocol in low-battery condi-tions for a far drone; and 5) require to find the accurateProcessPicture code location in a situation with a lowCPU availability and a low battery level.
13http://stardog.com/
Situation-Driven Multi-Purpose Adaptation in the Web of Things 13
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
6.1.1. Situations 1a and 1b: Heterogeneous drones interms of storage and camera resolution
The functionality TakeHdPicture can be imple-mented by two different drones with distinct situations.We expect an optimal decision, otherwise the water-ing needs detection would fail. We consider drone 1,which has high storage capacity but has a low qualitycamera, and drone 2, which has limited storage capac-ity but is equipped with a HD camera.
Table 2Situations 1a/1b implementation scores.
Drone CPU availability Score
#1 High 0.6
#1 Low 0.3
#2 High 0.7
#2 Low 0.4
Table 2 shows the scores obtained for the implemen-tation of TakeHdPicture for each drone, with varyingCPU availabilities. Results shows that the camera qual-ity is the most impacting contextual information to de-termine the implementation of TakeHdPicture. How-ever, a low quality drone will always be preferred overa HD one if it has both higher storage capacity and highCPU availability. This means that taking a high defini-tion picture when having low storage capacity with abusy CPU does not ensure acceptable response times,and can even cause disruptions in worst cases.
6.1.2. Situations 2a and 2b: Heterogeneous drones interms of storage, located over different parts ofthe field
Table 3Situations 2a/2b composition scores.
Drone Battery level Score
#3 High 0.6
#3 Low 0.3
#4 High 0.7
#4 Low 0.4
Two drones can take pictures to detect the wateringneeds. As these drones experience different situations,an optimal choice is expected to limit the energy andtime consumptions on drones. We consider drone 3,which is far from the field but has high storage capac-ity, and drone 4, which is closer from the field but hasa lower storage capacity.
We choose to vary the battery levels of drones. Ta-ble 3 details the scores obtained for the compositionof DetectWateringNeeds for each drone. As expected,results shows that drones closer from the field are al-ways preferred to take pictures. Further more, on thisadaptation configuration, having a low battery level ona drone significantly lowers its composition score (re-gardless of its location).
6.1.3. Situation 3: FloodThe system must determine if the weather condi-
tion is satisfiable to expose the SprayWater functional-ity. In a flood situation, the Temperature and Wind di-mensions have no impact; as long as the contextual in-stance “Flooded” is present, the score of the possibil-ity (S prayWater hasExposability Exposable) is al-ways 0. Thus, the functionality of SprayWater is neverexposable for this situation.
Table 4Situation 3 exposability scores.
Wind Temp. Score
StrongWind Hot 0.4
StrongWind Warm 0.4
StrongWind Cold 0.4
Breeze Hot 0.7
Breeze Warm 0.7
Breeze Cold 0.7
NoWind Hot 0.7
NoWind Warm 0.7
NoWind Cold 0.7
The scores obtained in Table 4 also show that thecontextual dimension Temperature has no impact onscores whatsoever, and that the Breeze and NoWindinstances from the Wind dimension produce identicalscores. Thus, this adaptation configuration also takesinto account stormy weather situations.
6.1.4. Situation 4: Picture transmission to a far dronewith low battery
In this situation, a drone must send a picture of thefield to an another one in order to process it. However,the only drone able to receive is far, and the one thatsends the picture has a low battery level. The systemmust choose the best protocol to use, to save as muchbattery level as possible and to send the picture withacceptable delays.
Table 5 shows that the adaptation configurationstrongly favors Wifi if the picture receiver is too far.
14 Situation-Driven Multi-Purpose Adaptation in the Web of Things
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
Table 5Situation 4 protocols scores.
Protocol (far) Score
Bluetooth 0.1
Wifi 0.6
Protocol (close) Score
Bluetooth 0.7
Wifi 0.6
Indeed, Bluetooth has a limited range. However, Blue-tooth has a slightly higher score if drones are closefrom each other (regardless of the battery level). Still,as it consumes more battery than Wifi, using Bluetoothis also viable.
6.1.5. Situation 5: Code host and execution for adrone with limited capacities
In this situation, the system must determine the bestsolution to provide picture processing on a drone withlimited capacities. It must determine the best locationto host and execute this functionality, in order to pro-cess pictures as fast as possible.
Table 6Situation 5 code locations scores.
Storagecapacity
Dronelocationscore
Cloudlocationscore
Low 0 1
High 0.3 0.9
Results from Table 5 show that the adaptation con-figuration prevents from locating the ProcessPicturefunctionality code on the device. It also shows that ahigh storage capacity is not enough for the device to bethe optimal code location. In this configuration, we ex-pect at least one more resource (either CPU or batterylevel) to be “High”, to allow a score >= 0.7 for locat-ing the code on the device. For this reason, the currentsituation always favors the cloud as the code location.
6.2. Adaptation coverage
The adaptation coverage means that each possiblecontextual situation (i.e. each identified contextual in-stances conjunctions) necessarily produces an adapta-tion possibility. Our solution provides adaptation cov-erage by design, i.e. as long as the contextual dimen-sion and its instances cover the necessary range for agiven contextual information. This coverage applies to
each adaptation purpose, independently of the domain.The number of dimensions is not limited, and can beprojected on each adaptation purpose. We define theadaptation solution coverage for a given application asfollows.
Definition 9 (Adaptation Solution Coverage). LetAPbe the set of adaptation purposes for an adaptationsolution ∆. Let ap ∈ AP be an adaptation purpose,and S ap = {ς1, ..., ςn} a set composed of each possiblecontextual situations for ap. Let R be the set of adap-tation rules for ∆. We assume that each rule in R hasdistinct causes. The number of possible situations fora purpose ap is |S ap| = |ς1 × ... × ςn| =
∏ni=1 |ςn|.
Thus, the coverage of ∆ corresponds to the number ofdistinct causes divided by the sum of all possible situ-ations for each adaptation purpose, i.e.
Cov(∆) =|R|∑m
j=1 |S (apm)| ,m = |AP|
For the evaluated scenario, our adaptation solution∆ outputs 59 rules with unique causes (|R| = 59). Foreach purpose, we have the following number of situa-tions:
|S (Exp)| = 3× 3× 3 = 27 (1)
|S (Imp)| = 2× 2× 3 = 12 (2)
|S (Comp)| = 2× 2× 2 (3)
|S (Prtcl)| = 2× 2 = 4 (4)
|S (CdL)| = 2× 2× 2 = 4 (5)
The total number of situations is thereforeS (AP)| = |S (Exp)| + |S (Imp)| + |S (Comp)| +
|S (Prtcl)|+ |S (CdL)| = 27 + 12 + 8 + 4 + 8 = 59
Thus, we ensured a total coverage asCov(∆) = |R|
|S (AP)| = 5959 = 1.
7. Discussion
In this work, we chose to rely on a semantic infras-tructure to perform adaptation. The choice of using se-mantic reasoning is questionable. Indeed, our wholeadaptive solution takes raw sensor data – a number – asinput, infers contextual instances from these data, andattributes a score to adaptation possibilities regardinga set of contextual instances, which is also a number.However, the meaning of the score number is not thesame. In a sense, scoring allows each type of informa-tion to be compared to each other, without consider-
Situation-Driven Multi-Purpose Adaptation in the Web of Things 15
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
ing the data units and ranges. Semantics also providereusability through linked open vocabularies14 and do-main knowledge expertise ontologies15, in an interop-erable manner. Being a proven standard, OWL guaran-tees the inference correctness at all expressivity levels(being AL+ in our solution). Thus, having a correctadaptation requires consistent rules and scores, whichdepends on the design of the rules and the scoringfunctions rather than on the adaptation solution. To en-sure this, we always keep the correct orders betweenadaptation possibility scores during the rule enginetransformation processes, as we always compute theaverage amongst each individual contextual instancescore related to a given possibility.
7.1. Runtime performance
In this work, we propose a semi-anticipated adap-tation planning approach. At design time, the applica-tion designer and experts pave the way for generatingadaptation possibilities and situation-based adaptationrules. These possibilities and rules are inferred at run-time and triggered by context change events. In thissense, this approach can be considered anticipated, asit pre-processes some (most of the) necessary elementon which the adaptation planning is based. However,plans are not yet available at context change. Actualadaptation planning corresponds to the selection of anadaptation possibility (if any), which depends on thescores of these possibilities that are computed at re-quest time (i.e. unanticipatedly). This strategy allowsreconciling the cost and benefits of relying on an in-ference engine. Indeed, while inferences are processedat runtime, they are not triggered when an adaptationrequest arises, but can be processed in parallel. The in-ference results are only integrated in the context graphwhen they have all been inferred, so that the graphthat is queried for adaptation always keep consistent.Moreover, performance also comes from the fact thatwe use an incremental reasoner16 that only recomputesthe parts of the graph that are impacted by contextchanges. In [36], we have evaluated the time perfor-
14Linked Open Vocabularies (LOV) – http://lov.okfn.org/dataset/lov/
15Linked Open Vocabularies for Internet of Things (LOV4IoT) –http://sensormeasurement.appspot.com/?p=ontologies
16Incremental reasoning allows capitalizing on previous reason-ing process. The inferred information is continuously maintained ina graph, and the algorithm only processes the knowledge impactedby new insertions and deletions. In this work we used the HyLAR(https://github.com/ucbl/HyLAR-Reasoner/) reasoner.
mance of the adaptation process. The processing timeswere respectively less than 650ms and 30ms for thecontextual data integration and the adaptation decisionprocesses17.
7.2. Optimization of adaptation rule set
The choice of dimensions and instances is also cru-cial to pre-reduce the set of adaptation rules. The num-ber of instances per dimension is fixed by semantiza-tion thresholds, which allow inferring contextual in-stances regarding a raw value range. The fuzzy logic-based solution proposed in [38] shows that discretiza-tion considerably reduces the number of rules pro-duced for an adaptation solution. This is one of thereasons we developed the concept of context situation,which also aims at identifying and targeting as soon aspossible a given “type of adaptation”, and at optimiz-ing the rule according to this target. Moreover, from ahuman-centered point of view, the notion context sit-uation is also easy to handle by domain experts as itcopes with the way they model application domains.As such, it is provided as a tool to facilitate the interac-tions between domain experts and application design-ers.
7.3. Genericity and adaptability of our approach
In our approach, adaptation rules always infer “pos-itive” answers, i.e. our adaptation solution is not builtupon negative assumptions. This way, the system rea-sons about contextual information in a open-world as-sumption: the absence of data does not imply that thecontextual information is false or invalid, but rather isunknown. By relying on the open-world assumptioncharacteristic of OWL, we avoid to unexpectedly blockapplication functionalities because a data is missing,or not available, or if it takes longer to transfer. More-over, the scoring functions can take into account thisimprecision by normalizing scores according to thenumber of actually available observations (aka dimen-sions). This makes our approach dynamically adaptiveto context changes.
On the long run, our approach can also be adaptedthroughout projects and platforms. dimensions can beremoved or added at design time. In turn, adaptation
17For data integration, we have assumed one second as the com-monly admitted threshold upon which the user’s attention stops fo-cusing on the current task. The decision step is however time critical;we have fixed its acceptable response time to 100ms.
16 Situation-Driven Multi-Purpose Adaptation in the Web of Things
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
purposes can vary according to the platform needs.For instance, at some point of the software mainte-nance cycle, the adaptation solution may require an ad-ditional adaptation purpose (corresponding to a newidentified adaptation need). In that case, the applica-tion designers have to identify the possible candidatesfor this purpose as well as their nature (identified asobjects in Section 4 – Table 1). They must also identifythe contextual dimensions and their set of contextualinstances, as well as the scoring functions required toprovide adaptation for this purpose.
8. Conclusion
In this paper, we propose a solution to provide multi-purpose context adaptation in WoT applications. Oursolution relies on a semantic WoT platform, able toincrementally reason about contextual information tosupport situation-based adaptation for multiple pur-poses. We formalize the notions of multi-purpose andsituation-based adaptations, and detail how this pro-cess generates adaptation rules in a declarative way,through the use of a meta adaptation rule engine. Ourapproach defines sets of adaptation possibilities foreach adaptation purpose, that are scored using scoringfunctions. We present our implementation of this en-gine and evaluate it on a sustainable agriculture sce-nario, for several situations and on different criteria(corectness and coverage). We discuss the positioningof our semantic approach and its performance (in termsof computation times) and adaptability.
Our perspectives include dynamically generatingscoring functions to reduce the design time of applica-tion design. We also aim at integrating semantizationrules as in S-LOR, to generate contextual instances in areusable manner, and to combine the deterministic in-ferences used to make adaptation decisions with prob-abilistic feedback learned from of previous adaptationdecisions using probabilistic ontologies using for in-stance PR-OWL [39].
Acknowledgements
This work is supported by the French ANR (AgenceNationale de la Recherche) under the grant number<ANR-13-INFR-012>.
References
[1] F. Manola, E. Miller, B. McBride et al., RDF primer, W3C rec-ommendation 10(1–107) (2004), 6.
[2] D. Brickley, R.V. Guha and B. McBride, RDF Schema 1.1,W3C recommendation 25 (2014), 2004–2014.
[3] P. Hitzler, M. Krötzsch, B. Parsia, P.F. Patel-Schneider andS. Rudolph (eds), OWL 2 Web Ontology Language: Primer,W3C Recommendation, 27 October 2009, Available at http://www.w3.org/TR/owl2-primer/.
[4] A. Haller, K. Janowicz, S.J. Cox, M. Lefrançois, K. Taylor,D. Le Phuoc, J. Lieberman, R. García-Castro, R. Atkinson andC. Stadler, The SOSA/SSN ontology: a joint WeC and OGCstandard specifying the semantics of sensors observations actu-ation and sampling, in: Semantic Web, Vol. 1, IOS Press, 2018,pp. 1–19.
[5] M. Mrissa, L. Médini, J.-P. Jamont, N. Le Sommer andJ. Laplace, An avatar architecture for the web of things, IEEEInternet Computing 19(2) (2015), 30–38.
[6] F. Barbier, E. Cariou, O.L. Goaer and S. Pierre, Software Adap-tation: Classification and a Case Study with State Chart XML.,IEEE Software 32(5) (2015).
[7] J. Fox and S. Clarke, Exploring approaches to dynamic adapta-tion, in: Proceedings of the 3rd International DiscCoTec Work-shop on Middleware-Application Interaction, ACM, 2009,pp. 19–24.
[8] K. Hanney, M. Keane, B. Smyth and P. Cunningham, Systems,tasks and adaptation knowledge: Revealing some revealing de-pendencies, in: International Conference on Case-Based Rea-soning, Springer, 1995, pp. 461–470.
[9] J. Becker, P. Delfmann and R. Knackstedt, Adaptive refer-ence modeling: integrating configurative and generic adapta-tion techniques for information models, in: Reference Model-ing, Springer, 2007, pp. 27–58.
[10] S.M. Sadjadi and P.K. McKinley, ACT: An adaptive CORBAtemplate to support unanticipated adaptation, in: DistributedComputing Systems, 2004. Proceedings. 24th InternationalConference on, IEEE, 2004, pp. 74–83.
[11] W. Kongdenfha, R. Saint-Paul, B. Benatallah and F. Casati, Anaspect-oriented framework for service adaptation, in: Interna-tional Conference on Service-Oriented Computing, Springer,2006.
[12] C. Zeginis and D. Plexousakis, Web service adaptation: Stateof the art and research challenges, Self 2 (2010), 5.
[13] J.-Y. Tigli, S. Lavirotte, G. Rey, V. Hourdin, D. Cheung-Foo-Wo, E. Callegari and M. Riveill, WComp middleware for ubiq-uitous computing: Aspects and composite event-based Webservices, annals of telecommunications-annales des télécom-munications 64(3–4) (2009).
[14] L. Seinturier, P. Merle, D. Fournier, N. Dolet, V. Schiavoni andJ.-B. Stefani, Reconfigurable sca applications with the frascatiplatform, in: Services Computing, 2009. SCC’09. IEEE Inter-national Conference on, IEEE, 2009, pp. 268–275.
[15] M. Beisiegel, H. Blohm, D. Booz, J.-J. Dubray, A.C. Inter-face21, M. Edwards, D. Ferguson, J. Mischkinsky, M. Nallyand G. Pavlik, Service component architecture, Building sys-tems using a Service Oriented Architecture. BEA, IBM, Inter-face21, IONA, Oracle, SAP, Siebel, Sybase, white paper, ver-sion 9 (2007).
Situation-Driven Multi-Purpose Adaptation in the Web of Things 17
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
[16] M. Mikalsen, N. Paspallis, J. Floch, E. Stav, G.A. Papadopou-los and A. Chimaris, Distributed context management in a mo-bility and adaptation enabling middleware (madam), in: Pro-ceedings of the 2006 ACM symposium on Applied computing,ACM, 2006, pp. 733–734.
[17] A.K. Dey, Understanding and using context, Personal andubiquitous computing 5(1) (2001), 4–7.
[18] T. Berners-Lee, J. Hendler, O. Lassila et al., The semantic web,Scientific american 284(5) (2001), 28–37.
[19] S. Laborie, J. Euzenat and N. Layaïda, Semantic adaptationof multimedia documents, Multimedia tools and applications55(3) (2011), 379–398.
[20] C. Baladron, J.M. Aguiar, B. Carro, L. Calavia, A. Cadenasand A. Sanchez-Esguevillas, Framework for intelligent serviceadaptation to user’s context in next generation networks, IEEECommunications Magazine 50(3) (2012).
[21] X.H. Wang, D.Q. Zhang, T. Gu and H.K. Pung, Ontology basedcontext modeling and reasoning using OWL, in: PervasiveComputing and Communications Workshops, 2004. Proceed-ings of the Second IEEE Annual Conference on, Ieee, 2004,pp. 18–22.
[22] A. Katasonov, O. Kaykova, O. Khriyenko, S. Nikitin andV.Y. Terziyan, Smart Semantic Middleware for the Internet ofThings. (2008).
[23] D. Pfisterer, K. Romer, D. Bimschas, O. Kleine, R. Mietz,C. Truong, H. Hasemann, A. Kröller, M. Pagel, M. Hauswirthet al., SPITFIRE: toward a semantic web of things, IEEE Com-munications Magazine 49(11) (2011), 40–48.
[24] Z. Shelby, K. Hartke and C. Bormann, The constrained appli-cation protocol (CoAP) (2014).
[25] P. Barnaghi and M. Presser, Publishing linked sensor data, in:Proceedings of the 3rd International Conference on SemanticSensor Networks-Volume 668, CEUR-WS. org, 2010, pp. 1–16.
[26] A. Gyrard, S.K. Datta, C. Bonnet and K. Boudaoud, Cross-domain Internet of Things application development: M3 frame-work and evaluation, in: Future Internet of Things and Cloud(FiCloud), 2015 3rd International Conference on, IEEE, 2015,pp. 9–16.
[27] S.-N. Chuang and A.T. Chan, Dynamic QoS adaptation for mo-bile middleware, IEEE Transactions on Software Engineering34(6) (2008), 738–752.
[28] K. Kakousis, N. Paspallis and G.A. Papadopoulos, A surveyof software adaptation in mobile and ubiquitous computing,Enterprise Information Systems 4(4) (2010), 355–389.
[29] J. Floch, S. Hallsteinsen, E. Stav, F. Eliassen, K. Lund andE. Gjorven, Using architecture models for runtime adaptability,IEEE software 23(2) (2006), 62–70.
[30] A. Gyrard, M. Serrano, J.B. Jares, S.K. Datta and M.I. Ali,Sensor-based Linked Open Rules (S-LOR): An AutomatedRule Discovery Approach for IoT Applications and its use inSmart Cities, in: Proceedings of the 26th International Con-ference Companion on World Wide Web, International WorldWide Web Conferences Steering Committee, 2017, p. .
[31] A. Boussadi, C. Bousquet, B. Sabatier, T. Caruba, P. Durieux,P. Degoulet et al., A business rules design framework for apharmaceutical validation and alert system, Methods of infor-mation in medicine 50(1) (2011), 36.
[32] C.K. Emani, Automatic detection and semantic formalisationof business rules, in: European Semantic Web Conference,Springer, 2014, pp. 834–844.
[33] J. Andersson, M. Ericsson and W. Lowe, Automatic rulederivation for adaptive architectures, in: Software Architecture,2008. WICSA 2008. Seventh Working IEEE/IFIP Conferenceon, IEEE, 2008, pp. 323–326.
[34] J. Hong, E.-H. Suh, J. Kim and S. Kim, Context-aware systemfor proactive personalized service based on context history, Ex-pert Systems with Applications 36(4) (2009), 7448–7457.
[35] M. Terdjimi, L. Médini and M. Mrissa, Towards a Meta-modelfor Context in the Web of Things, in: Karlsruhe Service SummitWorkshop, 2016.
[36] M. Terdjimi, L. Médini, M. Mrissa and M. Maleshkova, Multi-purpose Adaptation in the Web of Things, in: CONTEXT-17,2017.
[37] M. Terdjimi, L. Médini, M. Mrissa and N. Le Sommer, Anavatar-based adaptation workflow for the web of things, in: En-abling Technologies: Infrastructure for Collaborative Enter-prises (WETICE), 2016 IEEE 25th International Conferenceon, IEEE, 2016, pp. 62–67.
[38] M. Beggas, L. Médini, F. Laforest and M.T. Laskri, Towardsan ideal service QoS in fuzzy logic-based adaptation planningmiddleware, Journal of Systems and Software 92 (2014), 71–81.
[39] P.C.G. Da Costa, K.B. Laskey and K.J. Laskey, PR-OWL: ABayesian ontology language for the semantic web, in: Un-certainty Reasoning for the Semantic Web I, Springer, 2006,pp. 88–107.
[40] M. Salehie and L. Tahvildari, Self-adaptive software: Land-scape and research challenges, ACM Transactions on Au-tonomous and Adaptive Systems (TAAS) 4(2) (2009), 14.
[41] R.T. Fielding, Architectural styles and the design of network-based software architectures, PhD thesis, University of Califor-nia, Irvine, 2000.
[42] A. Gyrard, C. Bonnet, K. Boudaoud and M. Serrano, Assistingiot projects and developers in designing interoperable seman-tic web of things applications, in: Data Science and Data In-tensive Systems (DSDIS), 2015 IEEE International Conferenceon, IEEE, 2015, pp. 659–666.
[43] F.D. Macías-Escrivá, R. Haber, R. del Toro and V. Hernan-dez, Self-adaptive systems: A survey of current approaches, re-search challenges and applications, Expert Systems with Appli-cations 40(18) (2013), 7267–7279.
[44] J.-P. Jamont, L. Médini and M. Mrissa, A web-based agent-oriented approach to address heterogeneity in cooperativeembedded systems, in: Trends in Practical Applications ofHeterogeneous Multi-Agent Systems. The PAAMS Collection,Springer, 2014, pp. 45–52.
[45] D. Zeng, S. Guo and Z. Cheng, The web of things: A survey,JCM 6(6) (2011), 424–438.
[46] G. Montenegro, N. Kushalnagar, J. Hui and D. Culler, Trans-mission of IPv6 packets over IEEE 802.15. 4 networks, Tech-nical Report, 2007.
[47] F. Scioscia and M. Ruta, Building a Semantic Web of Things:issues and perspectives in information compression, in: Seman-tic Computing, 2009. ICSC’09. IEEE International Conferenceon, IEEE, 2009, pp. 589–594.
[48] M. Ruta, F. Scioscia and E. Di Sciascio, Enabling the semanticweb of things: Framework and architecture, in: Semantic Com-puting (ICSC), 2012 IEEE Sixth International Conference on,IEEE, 2012, pp. 345–347.
[49] F. Baader, The description logic handbook: Theory, implemen-tation and applications, Cambridge university press, 2003.
18 Situation-Driven Multi-Purpose Adaptation in the Web of Things
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
25 25
26 26
27 27
28 28
29 29
30 30
31 31
32 32
33 33
34 34
35 35
36 36
37 37
38 38
39 39
40 40
41 41
42 42
43 43
44 44
45 45
46 46
47 47
48 48
49 49
50 50
51 51
[50] A. Gyrard, C. Bonnet and K. Boudaoud, Helping IoT applica-tion developers with sensor-based linked open rules, in: SSN2014, 7th International Workshop on Semantic Sensor Net-works in conjunction with the 13th International SemanticWeb Conference (ISWC 2014), 19-23 October 2014, Riva DelGarda, Italy, Vol. 10, 2014.
[51] C. Yu and L. Popa, Semantic adaptation of schema mappingswhen schemas evolve, in: Proceedings of the 31st interna-tional conference on Very large data bases, VLDB Endow-ment, 2005, pp. 1006–1017.
[52] M.K. Asadi and J.-C. Dufourd, Context-aware semantic adap-tation of multimedia presentations, in: Multimedia and Expo,2005. ICME 2005. IEEE International Conference on, IEEE,2005, pp. 362–365.
[53] F. Boulanger, C. Hardebolle, C. Jacquet and D. Marcadet, Se-mantic adaptation for models of computation, in: Applicationof Concurrency to System Design (ACSD), 2011 11th Interna-tional Conference on, IEEE, 2011, pp. 153–162.
[54] M. Baldoni, C. Baroglio, V. Patti and L. Torasso, Reasoningabout learning object metadata for adapting SCORM course-
ware, Engineering the Adaptive Web., CS-Report (2004), 04–18.
[55] M. Zufferey and H. Kosch, Semantic adaptation of multime-dia content, in: Multimedia Signal Processing and Communi-cations, 48th International Symposium ELMAR-2006 focusedon, IEEE, 2006, pp. 319–322.
[56] D.G. Sampson, M.D. Lytras, G. Wagner and P. Diaz, Ontolo-gies and the Semantic Web for E-learning, Educational Tech-nology & Society 7(4) (2004), 26–28.
[57] M. Bertini, R. Cucchiara, A. Bimbo and A. Prati, Semanticadaptation of sport videos with user-centred performance anal-ysis, IEEE Transactions on Multimedia 8(3) (2006), 433–443.
[58] D. Ejigu, M. Scuturici and L. Brunie, An ontology-based ap-proach to context modeling and reasoning in pervasive com-puting, in: Pervasive Computing and Communications Work-shops, 2007. PerCom Workshops’ 07. Fifth Annual IEEE Inter-national Conference on, IEEE, 2007, pp. 14–19.