ODRL-Based Provisioning of Thing Artifacts for IoT Applications

Zakaria Maamar

1 a

, Amel Benna

2 b

and Haroune Kechaoui

University of Doha for Science and Technology, Doha, Qatar

Research Center for Scientiﬁc and Technical Information (CERIST), Algiers, Algeria

High School of Computer Science, Algiers, Algeria

Keywords:

Composition, Discovery, IoT, Policy, ODRL, Thing Artifact.

Abstract:

This paper discusses the design and development of Internet-of-Things (IoT) applications based on the novel

concept of Thing Artifact (TA). A TA is multi-faceted having a functionality, life cycle, and interaction ﬂows.

Prior to integrating TAs into an IoT application, they need to be discovered and then, composed. While

existing discovery and composition techniques are functionality-driven, only, this paper demonstrates that

policies regulating the functioning of TAs in terms of what they are permitted to do, are prohibited from

doing, and must do, have an impact on their discovery and composition. These policies are speciﬁed in Open

Digital Rights Language (ODRL). A system implementing and evaluating ODRL-based provisioning of TAs

for IoT applications design and development is presented in the paper, as well.

1 INTRODUCTION

To address the complexity of Internet-of-Things (IoT)

applications design and development, we presented

in (Maamar et al., 2023) the concept of Thing Ar-

tifact (TA). Contrarily to things that are the building

blocks of these applications, a TA leverages the con-

cept of Data Artifact (DA) that is commonly used to

manage data-driven business applications (Nigam and

Caswell, 2003). Because of this leveraging, we pro-

vide a rich description of a TA using 3 cross-cutting

aspects: functionality in term of what a TA does; life-

cycle in term of how a TA behaves; and interaction

ﬂow in term of with whom a TA exchanges mes-

sages. For illustration, we abstracted a smart home

in (Maamar et al., 2023) with multiple collaborative

TAs like smartTV:TA, remoteControl:TA, and motion-

Detector:TA provisioning different functionalities, ex-

posing different lifecycles, and participating in differ-

ent interaction ﬂows.

For a successful buy-in of TAs by the information

and communication technology community, in gen-

eral, and IoT community, in particular, techniques to

deﬁne, discover, and compose TAs are necessary. A

ﬁrst step is to adopt and, most probably, adapt ex-

isting thing techniques like the IoT composer by Kr-

https://orcid.org/0000-0003-4462-8337

https://orcid.org/0000-0002-9076-5001

ishna et al. (Krishna et al., 2019) and ComPOS by

Akesson et al. (

Akesson et al., 2019) (Section 2.3).

However, these techniques overlook the compliance

of TAs with organizations’ business rules. A TA that

responds to invocation requests between 10am and

11am, only, cannot be integrated into an IoT appli-

cation that submits such requests at any time of the

day. The invocation time-period that the IoT appli-

cation imposes on the TA is a decisive factor in its

selection. TAs discovery should go beyond their func-

tionalities by having extra factors like time, location,

and budget.

In this paper, our TAs discovery and composi-

tion techniques resort to Open Digital Rights Lan-

guage (ODRL, (Cano-Benito et al., 2023; W3C,

2018)) to guarantee that TAs’ future uses do not jeop-

ardize IoT applications. This happens by examining

TAs’ ODRL policies during discovery and composi-

tion. A TA that is permitted of sensing during an

ODRL-set time period cannot sense outside this time

period if requested by an IoT application. And, a TA

that is prohibited from communicating some users’

location information can still communicate other in-

formation to an IoT application. In either case, the

rationale of why, when, where, and how TAs will be

used impact their discovery and composition; sensing

is permitted in association with a speciﬁc time period

and communicating is prohibited in association with

some sensitive information. How to enforce these as-

168

Maamar, Z., Benna, A. and Kechaoui, H.

ODRL-Based Provisioning of Thing Artifacts for IoT Applications.

DOI: 10.5220/0012718600003687

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 19th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2024), pages 168-178

ISBN: 978-989-758-696-5; ISSN: 2184-4895

sociations is a question to address.

Being a rights expression language, ODRL poli-

cies consist of permission, prohibition, and duty rules

that control the use of assets like data, service, and

media. ODRL expresses that “something is permitted,

forbidden, or obliged, possibly limited by some con-

straints” (W3C, 2018). Contrarily to assets that are

static in ODRL, our TAs are dynamic as per their life-

cycles requiring a dynamic enactment of rules. For in-

stance, a permission rule for a smartTV:TA is enacted

when this TA takes on the activated state authorizing

the display of programs. And, the same smartTV:TA

taking on the conﬁgured state enacts a prohibition rule

preventing the display of programs. How to consider

the adaptability of rule enactment is another question

to address.

Our contributions are as follows: (i) abstraction of

TAs into assets offering insights into how, why, when,

and where TAs are used, (ii) association of TAs with

ODRL policies allowing a ﬁne-grained deﬁnition and

control, (iii) integration of ODRL policies into TAs

discovery and composition, which means both bet-

ter satisfaction of IoT applications’ requirements and

better awareness of TAs’ capabilities and limitations,

(iv) analysis of ODRL policies to conﬁrm the partici-

pation of TAs in compositions, and (v) demonstration

of the technical doability of ODRL-based discovery

and composition of TAs. The rest of this paper is or-

ganized as follows. Section 2 deﬁnes concepts and

presents related works. Section 3 details how ODRL

impacts TAs discovery and composition. This impact

is technically demonstrated in Section 4. Section 5

includes the conclusion and future work.

2 BACKGROUND

This section presents ODRL, TAs, and some works.

2.1 ODRL

ODRL is an example of rights expression language

that provides a ﬂexible and interoperable information

model, vocabulary, and encoding mechanisms to rep-

resent statements about the usage of assets. An as-

set is an identiﬁable resource or a collection of re-

sources such as data/information, content/media, ap-

plications, and services. ODRL relies on policies to

represent permitted and prohibited actions over a cer-

tain asset as well as required obligations that stake-

holders must meet over this asset as well (De Vos

et al., 2019; W3C, 2018). ODRL information model’s

key constructs are:

• Policy could include one to many permission, pro-

hibition, or duty rules. First, permission allows an

action over an asset if all constraints are satisﬁed

and if all duties are fulﬁlled. Second, prohibition

disallows an action over an asset if all constraints

are satisﬁed. Finally, duty forcibly exercises an

action over an asset or not. It is fulﬁlled when all

constraints are satisﬁed and have been exercised.

• Party is an entity or a collection of entities that

could correspond to a person, group of persons,

organization, or agent. A party can fulﬁll differ-

ent roles including assigner, assignee, informed

party, consented party, consenting party, compen-

sated party, and tracked party.

• Constraint is used either to reﬁne components like

action, party, or collection of assets or to declare

conditions applicable to a rule. Constraints could

be combined using logical operators.

In JSON-LD Listing 1, the assigner (line 7) in

charge of an asset, movie1 (line 6), refers to an agree-

ment policy (line 4) consisting of 2 rules. The per-

mission rule (line 5) is concerned with the display

action (line 9) that an assignee, smart TV (line 8),

executes subject to satisfying the constraint that

is not enabling the permission rule for more than

4 hours (lines 11-15). And, the prohibition

rule (line 17) is concerned with the digitize ac-

tion (line 21) and is associated with the same as-

signee (line 20). Should the assignee execute the

digitize action, then the remedy (line 22) would be

to apply the anonymize action (line 23) to the asset

movie1 (line 24).

Listing 1: ODRL speciﬁcation of movie.

1 {

2 " @co nt e xt ": " http : // www .w 3 . o rg / n s / o dr l . j so n ld ",

3 " uid ": " ht tp : // ex amp le . co m / p o li cy :0 1 " ,

4 " @t yp e " : " Ag r ee m en t " ,

5 " p er m is s io n " : [{

6 " t ar ge t " : " ht tp : // ex am ple . com / a ss et : mov ie 1/" ,

7 " a ss i gn e r " : " http : // ex a mp le . com / Mo v ie P ar t y : o rg : abc ",

8 " a ss i gn e e " : " http : // ex a mp le . com / s mar t - TV /" ,

9 " a ct io n " : " di s pl ay " ,

10 " c o ns tra int ": [{

11 " l e ft O pe r an d ": " m et e re d Ti m e " ,

12 " o pe r at o r " : " i te q " ,

13 " r i gh t Op e ra n d " :{" @v al ue " : "P 4 H " , " @ ty pe ":" xsd :

du r at ion "} ,

14 " unit " : " h tt ps : // www . wik id a ta . or g / w ik i / Q 2 52 3 5 "

}]

15 }] ,

16 " p ro h ib i ti o n " : [{

17 " t ar ge t " : " ht tp : // ex am ple . com / a ss et : mov ie 1/" ,

18 " a ss i gn e r " : " http : // ex a mp le . com / Mo v ie P ar t y : o rg : abc ",

19 " a ss i gn e e " : " http : // ex a mp le . com / s mar t - TV /" ,

20 " a ct io n " : " di g it i ze ",

21 " r em ed y " : [{

22 " a ct io n " : " an on y mi z e " ,

23 " t ar ge t " : " ht tp : // ex am ple . com / a ss et : mov ie 1/"}]

24 }]

25 }

ODRL-Based Provisioning of Thing Artifacts for IoT Applications

169

2.2 Thing Artifact

We brieﬂy deﬁne the concepts of functionality, life

cycle and interaction ﬂow (Maamar et al., 2023).

Deﬁnition 1. A TA is deﬁned by the tuple <

f ,a,D, lc,IF > where f is either a primitive function-

ality f

or a composite functionality f

that the TA

provisions; a is an action that a third party exercises

on a TA’s functionality f ; D is a set of input data {d

}

and output data {d

out

} related to the TA; lc is the

TA’s lifecycle represented as a state diagram (Deﬁni-

tion 2); and IF is a set of interaction ﬂows {i f

} that

are put together on-the-ﬂy based on messages that the

TA sends to peers and receives from peers (Deﬁni-

tion 3).

Deﬁnition 2. A TA’s lifecycle lc is deﬁned

by the couple < S,T >, i.e., lc = s

trans

−→

i+1

trans

i+1

−→ s

i+2

.. .s

j−1

trans

j−1

−→ s

; S is a set of

couples {(s

,{P

i j

})} where s

is a particular state

and {P

i j

} is a set of ODRL policies associated with

this state; and, T is a set of transitions {trans

Deﬁnition 3. A TA’s interaction ﬂow i f

is a set

of messages {m

i j

} that the TA uses to interact with

peers. A message m is deﬁned by the tuple <

id,type, f rom/state,to/state,cnt > where id is a

message’s identiﬁer; type is a pre-deﬁned message;

f rom/state is the sending state in the TA’s lifecycle;

to/state is the receiving state in the lifecycle of a peer

to the TA; and cnt is a content of data conveyed from

the TA to a peer where cnt ⊆ D.

For more details about TAs integration into IoT ap-

plications, readers are invited to consult (Maamar

et al., 2023).

2.3 Related Work

Our current work is at the crossroads of 3 topics,

ODRL (Section 2.1), DA, and IoT discovery and com-

position techniques. To the best of our knowledge,

such techniques for TAs do not exist.

Data Artifacts in Brief. In (Kumaran et al., 2008),

Kumaran et al. propose guidelines that would

assist IT practitioners identify the necessary DAs

for their applications. In (Narendra et al., 2009),

Narendra et al. model BPs using context-based

artifacts and Web services. The authors ab-

stract processes into models that are expressive

(i.e., easy to grasp) for non-IT practitioners and

could be based on DAs. In (Maamar et al., 2010),

Maamar et al. discover and model DAs from busi-

ness requirements. They use a bottom-up anal-

ysis to determine ﬁne-grained data, which are

afterwards aggregated into clusters where each

cluster becomes a potential DA. Next, they de-

rive the operations that act upon the discovered

data clusters. DAs are obtained after grouping

the data and operation clusters together. Finally,

in (Popova et al., 2015), Popova et al. acknowl-

edge the role of DAs in modeling BPs and propose

a set of methods to discover DAs’ lifecycles. The

methods are implemented as software plug-ins for

ProM www.promtools.org, a generic open-source

framework for supporting process mining. Fig. 1

represents a purchase order based on DAs.

Thing Discovery Techniques in Brief. In (Sunthon-

lap et al., 2018), Sunthonlap et al. present Social-

Aware aNd Distributed (SAND) scheme for de-

vice discovery in an IoT ecosystem. Among the

criteria for ranking potential devices, the authors

cite social relationship diversity with reference to

a glucose-level monitor that sends requests to ﬁnd

a glucose analyzer with whom it could collabo-

rate to evaluate a given patient’s glucose level.

The work of Sunthonlap et al. is in line with

the trend of social IoT that blends social comput-

ing with IoT (Atzori et al., 2012; Maamar et al.,

2020b). In (Barnaghi and Sheth, 2016), Barnaghi

and Sheth mention that IoT applications cannot

use existing data and service search, discovery,

and access methods and solutions because of the

number of resources and heterogeneity and com-

plexity of data. This no use is also backed by

Khalil et al. (Khalil et al., 2020). To this end,

Barnaghi and Sheth put forward some require-

ments and challenges for developing a robust and

comprehensive IoT search solution. Requirements

include quality, latency, trust, availability, relia-

bility, and continuity that should impact efﬁcient

access and use of IoT data and services. And,

challenges result from today’s IoT ecosystems that

host billions of dynamic things that make existing

search, discovery, and access techniques inappro-

priate for IoT data and services. In (Pablo Cal-

cina et al., 2016), Pablo Calcina et al. acknowl-

edge that ﬁnding useful devices to perform tasks

is a major challenge for IoT. They examine the

impact of network topologies, centralized, de-

centralized, and hierarchical, on device discov-

ery in terms of discovery time, server-side infras-

tructure, reliability, and network trafﬁc. To ad-

dress security, privacy, and semantic issues when

discovering things, W3C recently recommends

Web of Things (WoT) Discovery standard (W3C,

2023) to allow customers to get a thing’s Thing

Description (TD) that could be registered in a

server, for example. The discovery process in-

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

170

START:

PO created

PO billed

PO checked

into inventory

Order artifact

life-cycle

Customer artifact

life-cycle

User's

request

END:

PO fullfilled

PO updated

Customer

history

verified

Customer

history

updated

Bill prepared

Bill verified

Bill finalized

Bill artifact

life-cycle

Payment

details sent

Payment

completed

Transition Message

Legend

Figure 1: Representation of a DA-based purchase-order BP (Narendra et al., 2009).

cludes 2 phases. The introduction phase relies

on existing mechanisms (e.g., URI and DNS-

based) to request a thing’s TD address (URL).

And, the exploration phase uses this address to

provide the TD after authenticating the requesting

customer. Finally, an extensive analysis of dis-

covery techniques in IoT is presented in (Khalil

et al., 2020). These techniques are classiﬁed into

content-, context-, location-, user-, semantic-, and

resource-based. Despite their multiplicity and va-

riety, constraints on things are overlooked dur-

ing discovery. For instance, a content-based tech-

nique targets readings taken by a sensor. How-

ever, these readings only happen between 2am and

4am, while a future IoT application requires con-

tinuous readings making this sensor unﬁt for the

application. Also, a location-based technique tar-

gets particular locations of users and not things

to discover. Invoking a thing must happen from

a speciﬁc location but this is overlooked in this

technique.

Thing Composition Techniques in Brief.

In (Khaled and Helal, 2018), Khaled and

Helal propose a programming framework to

capture inter-thing relations into IoT applications.

The framework ensures that, on top of things’

services, logical and functional ties between

services are not overlooked by introducing

3 primitives that are thing service, thing relation

(e.g., control/controlled by, drive/driven by, and

extend/extended by), and recipe. In (Krishna

et al., 2019), Krishna et al. acknowledge the

difﬁcult job of composing things due to their het-

erogeneity and suggest a Web-based tool called

IoT Composer. The tool assists users select,

conﬁgure, and bind things together. In (

Akesson

et al., 2019),

Akesson et al. compose services

hosted on IoT devices using ComPOS (Compo-

sition language for Palcom Oblivious Services).

Native services contain computation and interac-

tion with the physical world, while composition

services combine native services into applica-

tions, mediating and adapting messages between

them. In (Ronny et al., 2021), Seiger et al.

suggest HoloFlows to address the complexity of

developing IoT applications for users and domain

experts with limited technical background. Using

HoloFlows, physical sensors and actuators are

mapped onto virtual components to connect

together through virtual wires. In (Maamar et al.,

2020a), Maamar et al. examine thing composition

in the context of thingsourcing. They argue

that by analogy with people who participate in

crowdsourcing, things could “act in the same

way” leading to the formation and management

of a crowd of things from which a group of

selected things would be composed and assigned

users’ demands to complete. Finally, Noura and

Gaedke present the Web of Things Description

Language (WoTDL) ontology to describe key

concepts associated with AI planning for auto-

matic WoT composition (Noura and Gaedke,

2019). For Noura and Gaedke, WoT is the result

of integrating IoT into the Web.

It is clear that the focus of the techniques above is

on functionality, only, while other factors that en-

ODRL-Based Provisioning of Thing Artifacts for IoT Applications

171

able/disable a functionality are overlooked. Per-

mitting a functionality subject to payment and

prohibiting a functionality subject to location

mean better component discovery and composi-

tion. This is discussed in the next section where

ODRL policies deﬁne the factors impacting TAs

discovery and composition.

3 THING ARTIFACTS

PROVISIONING

After presenting a case study, we dedicate the remain-

ing sections to TAs discovery and composition.

3.1 Case Study

Our case study is about a healthcare facility for el-

derly persons. Several studies conﬁrm the bene-

ﬁts of IoT for these people for instance IoT for

seniors: Solutions and Use Cases by Cogniteq

and How can IoT help with elderly care? by

Telef

onica Tech

. A ﬁrst situation in the facility’s

smart living-room exposes 3 TAs, remoteControl:TA,

smartTV:TA, and lightSwitch:TA, providing together a

free-of-interruption watching experience to a group

of persons. The remoteControl:TA is also used to

control the living room’s blinds upon the request of

the smartTV:TA. Another situation exposes 2 extra

TAs, smartWatch:TA and medicalDispenser:TA, syn-

chronizing the automatic release of medicine pills to

a person.

Besides the TAs’ functionalities above like con-

trolling lights, displaying movies, and dispensing

medicines, invoking them to satisfy elderly persons’

demands could be either permitted, prohibited, or

even forced depending on for instance, time of the

day, nature of medicine, and duration of a treatment.

For instance, a medicalDispenser:TA is discovered be-

cause its daily power charging does not conﬂict with

the periods of dispensing medicines. This charging is

integrated into the medicalDispenser:TA’s ODRL per-

missions. And, a smartTV:TA is composed because

it responds to the unique demands of a particular

remoteControl:TA integrated into this smartTV:TA’s

ODRL duties. We discuss how similar situations and

their respective permissions, prohibitions, and duties

impact TAs discovery and composition.

https://tinyurl.com/yae5dmv9.

https://tinyurl.com/yc7neuj7.

3.2 Approach

Fig. 2 illustrates the approach to discover and com-

pose TAs. It runs over 2 stages (preparatory and

development), uses 5 modules (creator, speciﬁer,

discoverer, checker, and composer) and 2 reposito-

ries (TAs and policies), and, ﬁnally enables inter-

actions across all modules and across modules and

repositories. 2 stakeholders (engineer and user) par-

ticipate in the approach as well.

In the preparatory stage, the engineer invokes (1)

the creator to specify (2) TAs that reside in the ecosys-

tem like smart living-room. The engineer could resort

to some W3C standards like the WoT Thing Descrip-

tion (WoT-TD (W3C, 2023)) to specify TAs. However,

this does not fall into the scope of the current work.

Next, details about TAs’ functionalities and lifecycles

are stored in the repository of TAs (3). The content of

this repository is made available for the speciﬁer that

with the assistance of the engineer (4) deﬁnes (4) and

stores the necessary TAs’ ODRL policies in the repos-

itory of policies (5) concluding the preparatory stage.

Because TAs’ interaction ﬂows are generated at run-

time, they are discussed in the development stage.

In the development stage, functionalities to se-

lect, lifecycles to specify, and interactions to ini-

tiate are IoT-application dependent aiming at satis-

fying particular users’ demands such as controlling

TV programs (6). First, based on an IoT applica-

tion’s requirements, the discoverer pulls details from

both the repository of TAs and the repository of poli-

cies to discover and select the necessary TAs as per

Section 3.2.1. This selection considers, on top of

TAs’ functionalities, the permissions, prohibitions,

and obligations of how, when, where, and why to in-

voke these functionalities. Before the checker con-

ﬁrms the participation of the necessary TAs (7) in the

IoT application as per Section 3.2.2, the checker ana-

lyzes how the interaction ﬂows between the selected

TAs’ lifecycles would progress at run-time with re-

spect to their respective ODRL policies. It could hap-

pen that a TA is not among those eligible to invoke a

peer’s functionality or that a peer’s functionality has

some invocation conditions that a TA cannot satisfy.

As a result, either the TA or the peer is discarded

from the under-development IoT application initiating

the discovery of another TA. After the participation

conﬁrmation, i.e., all ODRL policies are satisﬁed, the

checker notiﬁes (8) the composer of the readiness of

the necessary TAs to deploy on run-time platforms (9).

3.2.1 Discovery

Existing discovery techniques of software compo-

nents like Web services (Cheng et al., 2017) and hard-

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

172

Figure 2: General representation of TAs discovery and composition approach.

ware components like IoT devices (Kamel et al., 2021)

extensively depend on these components’ functional-

ities

that, in fact, correspond to the capabilities to

respond to users’ demands. For instance, a Web ser-

vice is discovered because it reports zip code-based

weather forecasts and an IoT device is discovered be-

cause it measures humidity levels in a warehouse. To

improve the outcome of discovery, some techniques

reconcile semantic heterogeneities and/or tap into so-

cial relations between components. While discovery

techniques safely assume a full access to the compo-

nents’ functionalities, they do not pay much attention

to the conditions on both the functionalities and the

actions invoking these functionalities. Although a dis-

covered weather Web service is a “strong” candidate

for integration into a road-trafﬁc monitoring applica-

tion, it will be discarded. The store action that in-

vokes this Web service is conditioned by a speciﬁc

format and duration. However, these two conditions

do not meet the monitoring application’s storage re-

quirements that refer to a different format and dura-

tion. As a result, another Web service whose store ac-

tion’s conditions match the storage requirements will

be selected after discovery. In our work, conditions on

Criteria like quality-of-service and/or quality-of-thing

could narrow down the discovery. However, this is not dis-

cussed further in this paper.

functionalities and actions are part of the permission,

prohibition, and obligation rules in ODRL policies.

Back to Fig. 2 where the discoverer analyzes

the ODRL policies stored in the repository of poli-

cies according to the under-development IoT appli-

cation’s requirements. These policies refer to TAs

that the discoverer will recommend to the composer,

through the checker, for inclusion in the IoT applica-

tion. To illustrate this analysis, let us consider List-

ing 2 related to a smartTV:TA’s functionality that is

smartTV:volume:TA (line 7) with focus on how to am-

plify the volume using the increase action (line 10).

In this Listing, a prohibition rule restricts to amplify

the volume above a certain limit (lines 12-14) dur-

ing night time (lines 15-20). Should an IoT applica-

tion be ﬂexible with any volume at any time of the

day, then this smartTV:TA would be dropped from the

list of candidate TAs for inclusion in this application.

Night-time period restricts the volume level, which is

not in line with the IoT application’s requirements. As

a result, the search for another TA continues.

Listing 2: ODRL speciﬁcation of smartTV:volume:TA.

1 {

2 " @co nt e xt ": " http : // www .w 3 . o rg / n s / o dr l . j so n ld ",

3 " @t yp e " : " Set ",

4 " uid ": " http : / / e x am pl e . com / P ol ic y : 1 2 3 .5 dab 2b 8 b ae 0A " ,

5 " pr o fi le " :

6 " ht tp :// ex am ple . co m / o dr l : p rof il e : 0 5 5 ",

7 " p ro h ib i ti o n " : [{

ODRL-Based Provisioning of Thing Artifacts for IoT Applications

173

8 " t arg et ": " htt p : / / e x am pl e . com / ass et : sma rt T V : v o lu me : TA "

9 " a s si g ne r " : " h tt p : // e xa mp l e . c om / org :3 2 1 " ,

10 " a cti on ": [{

11 " rd f : v al ue " : { " @id ": " od rl :" inc re a se "},

12 " r efi n em e nt ": [

13 {" le f tO p er a nd " : " c ou nt " ,

14 " o pe r at o r " : " g te q " ,

15 " r i gh t Op e ra n d " : " 1 0 "},

16 {" le f tO p er a nd " : " d a te Tim e " ,

17 " o pe r at o r " : " g te q " ,

18 " r i gh t Op e ra n d " : {" @ va lue ": " T 19: 0 0 Z ", " @ty pe "

:" xs d : t im e "}},

19 {" le f tO p er a nd " : " d a te Tim e " ,

20 " o pe r at o r " : " i te q " ,

21 " r i gh t Op e ra n d " :{" @v al ue " : "T 0 8 : 00Z " , " @ t yp e "

:" xs d : t im e "}}

22 {" le f tO p er a nd " : " c ont ex t " ,

23 " o pe r at o r " : " eq " ,

24 " r i gh t Op e ra n d " : {" a c ti vat ed "}}]

25 }]

26 }]

27 }

3.2.2 Composition

Contrarily to what is discussed in Section 2.3 where

the emphasis is on thing composition techniques like

orchestration versus choreography applied to TAs, we

discuss hereafter how the participation of a discovered

TA in an IoT application is either approved or rejected.

This would be based on 2 ODRL constructs: (i) poli-

cies where some are free of assignees and (ii) poten-

tial conditions on rules and/or actions invoking TAs’

functionalities.

Assuming that an IoT application’s composition

schema is already set, e.g., which TAs perform ﬁrst

and what data TAs exchange, we exemplify the com-

position schema with 2 TAs and then, analyze their

approval/rejection’s impacts on completing this com-

position schema. Fig. 3 is a partial representation

of the respective lifecycles of remoteControl:OnOff:TA

and smartTV:OnOff:TA where inter-state messages

(dashed lines) form an interaction ﬂow between these

lifecycles at run-time. We recall that TAs’ lifecy-

cles consist of 5 similar states, prepared, activated,

suspended, failed, and done. However, the sub-

states in the activated state capture the particular-

ities of each TA where used and unused are sub-

states for remoteControl:OnOff:TA for example, and

turned-off, turned-on, and conﬁgured are sub-states

for smartTV:OnOff:TA for example. Having these

2 TAs included in an IoT application for watching

movies would be driven by the exchange of messages

between their respective activated states. Speciﬁc

messages are used as per Table 1.

To begin with, we suggest an ODRL policy for

smartTV:OnOff:TA in Listing 3. Major highlights of

this policy are as follows: agreement type (line 3),

prohibition rule (line 6), list of assignees (lines 9-11),

turn-on action to invoke the functionality (line 13),

state-based conditions on the rule (lines 19-22), and

location-based conditions on the action (lines 14-

Prepared

Activated

used

activation

unused

pause

success

.....

ODRL

policies

ODRL

policies

DoneSuspended

..... .....

remoteControl:OnOff:TA's lifecycle

Prepared

Activated

turned-off

activation

turned-on

pause

success

configured

ODRL

policies

ODRL

policies

DoneSuspended

..... .....

smartTV:OnOff: TA's lifecycle

Legend

Inter-state transitions Inter-state messages

Figure 3: Representation of TAs engaged in interactions.

17). Let us assume a message from remoteCon-

trol:OnOff:TA’s activated:used to smartTV:OnOff:TA’s

activated:turned-off requesting to execute the turn-

on action. Upon message receipt, smartTV:OnOff:TA

loads the ODRL policies linked to activated:turned-off

state and proceeds as follows:

• If remoteControl:OnOff:TA is not in the list of

assignees, then this TA will be rejected from

the IoT application initiating the search for

remoteControl:OnOff:TA

′

as per Section 3.2.1.

Otherwise, checking rules and actions is initiated.

• Assuming that the state-based condition on the

rule is satisﬁed, i.e., the current state is activated,

checking the location-based condition on the ac-

tion is next to ensure that invoking this action

happens from a speciﬁc location. If the check

turns out unsatisﬁed, i.e., remoteControl:OnOff:TA

is in another location, then this TA will be rejected

from the IoT application initiating the search

for remoteControl:OnOff:TA

′

as per Section 3.2.1.

Otherwise, remoteControl:OnOff:TA is approved

for the composition.

Listing 3: ODRL speciﬁcation of smartTV:OnOff:TA.

1 {

2 " @co nt e xt ": " http : // www .w 3 . o rg / n s / o dr l . j so n ld ",

3 " @t yp e " : " A g re e me n t " ,

4 " uid ": " http : / / e x am pl e . com / p ol ic y : 0 0 4 ",

5 " pr o fi le " : " h tt p : // e xa mpl e . c om / od rl : pr o fi le : 0 5" ,

6 " p ro h ib i ti o n " : [{

7 " t ar ge t " : " ht tp : // ex am ple . com / sm art -TV / sm a rt TV : O nO ff

: TA " ,

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

174

8 " a ss i gn e r " : " h tt p : // e xa m pl e . com / sma rt - TV P ro v id e r : 0 0 1

9 " a ss i gn e e " : {

10 " @ ty pe ": " P art y Co l lec t io n ",

11 " s ou rc e " : " ht tp : // ex am ple . com / R e mot e Co n t ro l Li s t /

Li st 1"},

12 " a ct io n " : [{

13 " rd f : v al ue " : {" @ id " : " od rl : turn - on "},

14 r e fi n em e nt " : [{

15 " l e ft O pe r an d ": " sp a ti al " ,

16 " o pe r at o r " : " eq ",

17 " r i gh t Op e ra n d " : {" X"}}]

18 " c o ns tra int ": [{

19 " l e ft O pe r an d ": " co n te xt " ,

20 " o pe r at o r " : " eq ",

21 " r i gh t Op e ra n d " : {" a c ti vat ed "}}] ,

22 " r em ed y " : [{

23 " a ct io n " : " enc ry p te d / s cr a mb l ed t ra n sm i ss i on " ,

24 " t ar ge t " : " ht tp : // ex am ple . com / sm art -TV / sm a rt TV :

di s pl ay : TA "}]}]}]

25 }

26 {

27 " @ ty pe ": " dc : D o cu m en t " ,

28 " @i d " : " h tt p : // e xa mpl e . c om / R em o te C ont r ol /

re m ote C on t ro l : OnO ff :TA ,

29 " dc : ti tl e " : " re m ot e C on t ro l s TA " ,

30 " odrl : p ar tOf ": " h tt p : / / e xam pl e . com / R emo t eC o n tr o lLi s t /

Li st 1"

31 }

4 IMPLEMENTATION AND

EVALUATION

To demonstrate ODRL-based discovery and compo-

sition of TAs using the center for elderly persons, a

system was developed, deployed, and evaluated on a

Windows 11 desktop, 16GB RAM, 4 Cores processor,

and 4 Cores Graphics card with 8GB VRAM (Fig. 4).

We used Visual Studio Code (code.visualstudio.

com, a free open-source lightweight code editor for

JavaScript and TypeScript languages), the progres-

sive JavaScript framework vue (vuejs.org, an open-

source model–view–viewmodel front-end JavaScript

framework for building user interfaces and single-

page applications), Node.js (nodejs.org/en, an asyn-

chronous event-driven JavaScript runtime for cre-

ating networks based on asynchronous operations),

Thingweb Node-WoT (projects.eclipse.org/projects/

iot.thingweb) package (an ofﬁcial reference imple-

mentation of the WoT), Eclipse Mosquitto (mosquitto.

org, an open source message broker), and ODRL val-

idator and evaluator sandbox (odrlapi.appspot.com)

(an online Web application for verifying the status of

ODRL policies).

In Fig. 4’s left panel, the system offers Thing ar-

tifacts, Policies, and Discovery and composition ﬂow

options. First, through the Thing artifacts option that

implements the creator, the engineer deﬁnes TAs us-

ing WoT-TD and stores their deﬁnitions in the repos-

itory of TAs. Regarding TAs’ lifecycles and inter-

action ﬂows, they are included in WoT-TD’s prop-

erties attribute and WoT-TD’s actions and events at-

tributes, respectively. Second, through the Policies

option that implements the speciﬁer, the engineer de-

ﬁnes the TAs’ policies to store in the repository of

policies. For illustration, Listing 4 corresponds to the

WoT-TD of smartTV:volume:TA while referencing the

necessary constructs of policies in line 15. Details

about each policy, e.g., line 18,. are deﬁned separately

like in Listing 2. Finally, the Discovery and compo-

sition ﬂow option implements the discoverer, checker,

and composer according to the user’s case study.

Listing 4: Example of a TA in WoT-TD including policies.

1 {

2 " @co nt e xt ": " h tt ps : // w ww . w 3 . o rg / 2 0 19 / wot /td / v1" ,

3 " @t yp e " : " Th in g " ,

4 " ti tl e " : " sm art TV : v ol ume : TA " ,

5 "id " :" ht tp : // ex am p le . co m / s mar tT V : vo lum e : TA :8 a 0 f dd 0 2 7 a6 2

6 " s ec u r it y D ef i nit i on s ":{" bas ic _ sc ": {. ..}},

7 " sec ur i ty ": [" b as ic_ sc " ],

8 " p ro p er t ie s " : {

9 " f u nct i on a li t y " : {

10 " @ ty pe ": " Od rl : pr op ",

11 " type " : " s tr ing ",

12 " v al ue ": " vol um e " , . ..

13 " f or ms ": [ .. . ]

14 },

15 " p o li c ie s " : {

16 " @ ty pe ": " od rl : p ol i ci es " ,

17 " type " : " a rr ay ",

18 " ui d " : [" ht tp : // ex am ple . com / P ol icy : 1 2 3 . 5 da b 2 b8 bae 0A

"],

19 " f or ms ": [ .. . ] ,

20 ...}}, .. .

21 }

To discover potential TAs, users are prompted to

submit the functionalities they need like toggle, vol-

ume, and control. After a syntactical screening of

the repository of TAs by the discoverer, some TAs

are identiﬁed like smartTV:volume:TA, remoteCon-

trol:TA, and lightSwitch:TA (Fig. 5). Next, the user

selects those TAs that she needs prior to setting cer-

tain requirements on some of these TAs like restrict-

ing smartTV:volume:TA to a maximum value (Fig. 5’s

right panel). The checker veriﬁes the compliance of

these requirements with TAs’ policies like discussed

in Section 3.2.1. No compliance would mean exclud-

ing the concerned TAs and selecting others.

After a successful check of all the TAs, the user

with the assistance of the composer plugs the TAs

together creating a composition ﬂow (Fig. 6). Next,

the checker veriﬁes if the users’ requirements satisfy

the selected TAs’ policies. Finally, the user assigns a

name to the composition ﬂow such as elderly person

whose speciﬁcation is shown in Fig. 6.

After completing the deployment, we evaluated

the system in terms of ﬂood attacks and response

time. In the ﬁrst evaluation, we considered HTTP-

GET ﬂood attacks aka distributed-denial-of-service.

Some results are shown in Table 2. The response

time remained stable even during the ﬂooding, which

meant that the server used the desktop’s resources ef-

ﬁciently. We can also note that the server did not

crash during the ﬂooding, which also conﬁrmed the

efﬁcient use of resources.

ODRL-Based Provisioning of Thing Artifacts for IoT Applications

175

Table 1: Messages exchanged between TAs’ lifecycles.

Type Sender Receiver Description

open TA

.ss

Establishes a communication channel between the sender and receiver

send TA

.ss

Allows the sender to ask the receiver to invoke an action

success TA

.ss

Coupled with send; conﬁrms the acceptance of the action to invoke

fail TA

.ss

Coupled with send; conﬁrms the rejection of the action to invoke

ping TA

.ss

Checks periodically the liveness of the receiver

ack TA

.ss

Coupled with ping; conﬁrms the liveness of the receiver according to a

speciﬁc delay

close TA

.ss

Coupled with open; shut downs a communication channel

Figure 4: Main interface of the system.

Figure 5: Screenshot of TAs discovery, selection, and requirement deﬁnition and check.

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

176

Figure 6: Screenshot of the speciﬁcation of elderly person composition-ﬂow.

Table 2: HTTP-GET ﬂood test results.

Number of

ﬂood requests

Number of

client requests

Average client

response time (ms)

Server

status

100 3 2.134

√

1000 10 2.176

√

10000 10 2.141

√

100000 10 2.351

√

refers to server remaining functional

In the second evaluation, we considered the re-

sponse time of each module of the system deployed

on the desktop. The test consisted of a set of

HTTP GET, POST, and DELETE requests that a

client sends to a module via route endpoints. The

results showed that the response time depends com-

pletely on the complexity of the operation that the

route is executing. For instance, simple GET routes

like policy and thing artifact home-routes had short

response times (e.g., ≈ 0.5ms) unlike the routes that

perform complex operations like discovery (e.g., ≈

0.9ms) that uses Node-WoT to expose things and re-

turn their access links, which is a complex operation.

5 CONCLUSION

This paper presented a TA-based approach to design

and develop IoT applications. Building upon the con-

cept of data artifact, a TA is a chunk of unstructured

information capturing 3 cross-cutting aspects referred

to as functionality, lifecycle, and interaction ﬂow.

Along with deﬁning these aspects, the approach in-

tegrated techniques to discover and compose TAs. A

major feature of these techniques is their compliance

with organizations’ operation rules speciﬁed as ODRL

policies. Different illustrations about this compliance

were included such as a monitoring TA that accepts in-

vocations during a speciﬁc time-period while an op-

eration rule approves invocations at any time of the

day. This discrepancy would lead to dropping this TA

from the list of candidate TAs to integrate in an IoT ap-

plication. The technical doability of TAs discovery

and composition was veriﬁed using an in-house sys-

tem simulating some scenarios in a center for elderly

persons. In term of future work, we would like to

look into the impact of conﬂicting TAs’s ODRL poli-

cies on the correctness of future IoT applications.

REFERENCES

Atzori, L., Iera, A., Morabito, G., and Nitti, M. (2012). The

Social Internet of Things (SIoT) - When Social Net-

works Meet the Internet of Things: Concept, Archi-

tecture and Network Characterization. Computer Net-

works, 56(16).

Barnaghi, P. M. and Sheth, A. P. (2016). On Searching

ODRL-Based Provisioning of Thing Artifacts for IoT Applications

177

the Internet of Things: Requirements and Challenges.

IEEE Intelligent Systems, 31(6).

Cano-Benito, J., Cimmino, A., and Garc

ıa-Castro, R.

(2023). Injecting Data into ODRL privacy Poli-

cies Dynamically with RDF Mappings. In Com-

panion Proceedings of the ACM Web Confer-

ence 2023 (WWW’2023), Austin, TX, USA.

Cheng, B., Shuai Zhao, S., Changbao Li, C., and Jun-

liang Chen, J. (2017). A Web Services Discovery

Approach Based on Mining Underlying Interface Se-

mantics. IEEE Transactions on Knowledge and Data

Engineering, 29(5).

De Vos, M., Kirrane, S., Padget, J., and Satoh, K. (2019).

ODRL Policy Modelling and Compliance Checking.

In Proceedings of RuleML+RR’2019, Bolzano, Italy.

Kamel, M., Yan, Y., Ligeti, P., and Reich, C. (2021). Attred:

Attribute Based Resource Discovery for IoT. Sensors,

21(14).

Khaled, A. and Helal, S. (2018). A Framework for Inter-

Thing Relationships for Programming the Social IoT.

In 4th IEEE World Forum on Internet of Things, WF-

IoT2018, Singapore.

Khalil, K., Elgazzar, K., Seliem, M., and Bayoumi, M.

(2020). Resource Discovery Techniques in the Inter-

net of Things: A Review. Internet Things, 12.

Krishna, A., Le Pallec, M., Mateescu, R., Noirie, L., and

Sala

un, G. (2019). IoT Composer: Composition and

Deployment of IoT Applications. In Companion Pro-

ceedings of ICSE’2019, Montreal, QC, Canada.

Kumaran, S., Liu, R., and Wu, F. Y. (2008). On the Duality

of Information-Centric and Activity-Centric Models

of Business Processes. In Proceedings of the 20th In-

ternational Conference on Advanced Information Sys-

tems Engineering (CAiSE’2008), Montpellier, France.

Maamar, Z., Badr, Y., and Narendra, N. (2010). Business

Artifacts Discovery and Modeling. In Proceedings of

ICSOC’2010, San Francisco, California, USA.

Maamar, Z., Boukadi, K., Kon

e, B., Benslimane, D.,

and Elnaffar, S. (2020a). Thingsourcing to Enable

IoT Collaboration. In Proceedings of WETICE’2020,

France (online).

Maamar, Z., Faci, N., Al-Khafajiy, M., and Murtada, D.

(2023). Thing Artifact-based Design of IoT Ecosys-

tems. Service Oriented Computing and Applications.

(forthcoming).

Maamar, Z., Faci, N., Kajan, E., Purkovic, S., and Ugljanin,

E. (2020b). Process-of-Things: Weaving Film Indus-

try’s Practices into the Internet-of-Things. Internet

Things, 11.

Narendra, N., Badr, Y., Thiran, P., and Maamar, Z. (2009).

Towards a Uniﬁed Approach for Business Process

Modeling Using Context-Based Artifacts and Web

Services. In Proceedings of SCC’2009, Bangalore, In-

dia.

Nigam, A. and Caswell, N. (2003). Business Artifacts: An

Approach to Operational Speciﬁcation. IBM Systems

Journal, 42(3).

Noura, M. and Gaedke, M. (2019). WoTDL: Web of Things

Description Language for Automatic Composition. In

Proceedings of WI’2019, Thessaloniki, Greece.

Pablo Calcina, C., Laisa Caroline Costa, D.,

Marcelo Knorich, Z., and Fl

avio Soares Corr

ea,

d. (2016). Device Discovery Strategies for the IoT. In

Proceedings of ISCE’2016, Sao Paulo, Brazil.

Popova, V., Fahland, D., and Dumas, M. (2015). Artifact

Lifecycle Discovery. International Journal of Coop-

erative Information Systems, 24(1).

Akesson, A., Hedin, G., Nordahl, M., and Magnusson, B.

(2019). ComPOS: Composing Oblivious Services. In

Proceedings of PerIoT’2019, Kyoto, Japan.

Ronny, S., Romina, K., Mandy, K., and Uwe, A. (2021).

HoloFlows: Modelling of Processes for the Internet

of Things in Mixed Reality. Software System Model,

20(5).

Sunthonlap, J., Nguyen, P., Wang, H., Pourhomanyoun, M.,

Zhu, Y., and Ye, Z. (2018). SAND: A Social-Aware

and Distributed Scheme for Device Discovery in the

Internet of Things. In Proceedings of ICNC’2018,

Maui, HI, USA.

W3C (2018). ODRL Information Model 2.2. https://www.

w3.org/TR/2018/REC-odrl-model-20180215/. (Vis-

ited January 2021).

W3C (2023). Web of Things (WoT) Thing Description 1.1.

www.w3.org/TR/wot-thing-description. (Visited De-

cember 2023).

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

178