ODRL-Based Resource Deﬁnition in Business Processes

Zakaria Maamar

1 a

, Amel Benna

2 b

, Minglin Li

, Huiru Huang

and Yang Xu

3 c

College of Computing and IT, University of Doha for Science and Technology, Doha, Qatar

Department of Multimedia and Information Systems, CERIST, Algiers, Algeria

School of Computer Science, Fudan University, Shanghai, China

Keywords:

Asset, Business Process, ODRL, Resource, Service.

Abstract:

Despite the popularity of Resource-as-a-Service (RaaS) model, it falls short of providing low-level, ﬂexible

control over resources in terms of which category of users can use them, when and where users can use them,

and how much users need to pay for them. To provide such a control, this paper presents 2 intermediary models

between resources and services referred to as Resource-as-an-Asset (RaaA) and Asset-as-a-Service (AaaS),

respectively. First, resource-related constructs are mapped onto asset-related constructs and then, the same

asset-related constructs are mapped onto service-related constructs. A projection operator is developed to

support construct mappings based on a set of pre-deﬁned rules. To illustrate asset-related constructs, the paper

resorts to the Open Digital Rights Language (ODRL) deﬁning what is permitted, forbidden, or obliged over

an asset. A system implementing construct mappings is presented in the paper as well.

1 INTRODUCTION

In the literature, a Business Process (BP) is a set of

activities/tasks connected together based on a process

model that speciﬁes who does what, where, when, and

why. A plethora of BPs exist ranging from product

procurement to loan approval and claim processing.

In addition to process model speciﬁcation, BPs’

owners proceed with identifying (processing, storage,

and communication) resources that these BPs would

use at run-time. Because resources are valuable as-

sets, frequently costly, and limited (Arias et al., 2018),

providers could be selective when provisioning their

resources using criteria like urgency of demands and

best offers. As a result, BPs’ owners need to respond

to changes of resources by avoiding for instance, to

be locked into particular providers (i.e., BP-resource

strong coupling). A widely adopted solution to ad-

dress the lock-into concern is to abstract resources

into services leading into what the ICT commu-

nity refers to as Anything-as-a-Service (XaaS) model.

Cloud computing has been an excellent showcase of

the beneﬁts of XaaS through SaaS, PaaS, and IaaS

models. However, this abstraction does not offer

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

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

https://orcid.org/0000-0002-0958-8547

providers the means nor the guidelines of how to ei-

ther permit or prohibit the use of their resources to a

speciﬁc category of users, a speciﬁc period of time, a

speciﬁc location, etc. To address this lack of means

and guidelines, we resort to the Open Digital Rights

Language (ODRL, (W3C, 2018)) ﬁrst, to elevate re-

source to the level asset and second, to specify the

policies that would either permit or prohibit the use

of assets abstracting resources.

Thanks to ODRL, we achieve XaaS over 2 stages

where ﬁrst, a resource is exposed as an asset requir-

ing the development of Resource-as-an-Asset (RaaA)

model, and second, an asset is exposed as a ser-

vice also requiring the development of Asset-as-a-

Service (AaaS) model. An immediate beneﬁt of the

RaaA model is the possibility of specifying ahead of

time the context in which the use of a resource would

be either permitted or prohibited without questioning

this resource’s availabilities at run time nor jeopardiz-

ing the execution of BPs. This would give providers

full control of their resources by for instance, desig-

nating particular users of resources, e.g., BPs’ own-

ers, and even rectifying the prohibited uses of re-

sources. Mire beneﬁts of the RaaA model are con-

straining the use of resources with parameters like

maximum capacity and allocated time. AaaS model

would also achieve other beneﬁts like hiding the

intrinsic characteristics of resources exposed as as-

Maamar, Z., Benna, A., Li, M., Huang, H. and Xu, Y.

ODRL-Based Resource Deﬁnition in Business Processes.

DOI: 10.5220/0012047500003538

In Proceedings of the 18th International Conference on Software Technologies (ICSOFT 2023), pages 225-232

ISBN: 978-989-758-665-1; ISSN: 2184-2833

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

225

sets and then, services, and allowing a platform-

independent control of these resources. Section 2 de-

ﬁnes resource and ODRL, and suggests a running ex-

ample. Section 3 presents resource, asset, and service

models and their mappings. Section 4 implements

these mappings. Section 5 concludes the paper and

discusses future work.

2 BACKGROUND

This section presents brieﬂy resource and ODRL and

then, suggests a running example.

2.1 Resource in Brief

The concept of resource is not new in the litera-

ture and has been adopted in different domains like

distributed artiﬁcial intelligence, cloud computing,

and service computing. From a broader perspec-

tive, Baker et al. specialize resource into compu-

tational, consumed, and produced, associating each

type with a separate lifecycle that would stress out

this type’s unique characteristics (Baker et al., 2018).

Lucchim et al. consider resources as “directly-

accessible components handled through a standard

common interface” (Lucchim et al., 2008). Finally,

Hofman adopts everything-as-a-resource as a base

for building seamless interoperable platforms in the

IoT world (Hofman, 2015). To enforce the relation-

ship between consumers of resources and providers of

resources, Maamar et al. deﬁne 5 consumption prop-

erties referred to as unlimited, shareable, limited, lim-

ited but-extensible, and non-shareable (Maamar et al.,

2016). Each property has a lifecycle consisting of

states depicting each the respective actions that con-

sumers and providers are expected to perform. By

analogy with these properties, Pufahl et al. in (Pu-

fahl et al., 2021) mention attributes that describe a re-

source in terms of capabilities, capacities, and avail-

ability at a given point in time, and decompose re-

sources into active and passive.

2.2 ODRL in Brief

ODRL is an example of rights expression languages

providing a ﬂexible and interoperable information

model, vocabulary, and encoding mechanisms to rep-

resent statements about the usage of assets. An asset

is an identiﬁable resource (or collection of resources)

such as data, media, applications, and services. Fig. 1

is an excerpt of ODRL information-model.

Policy could include one to many permission, pro-

hibition, or duty rules. Permission allows an action

over an asset if all constraints are satisﬁed and if all

duties are fulﬁlled. Prohibition disallows an action

over an asset if all constraints are satisﬁed. And, duty

is to exercise an action that can be over an asset or

not. It is fulﬁlled when all constraints are satisﬁed.

Party is an entity or collection of entities that

could correspond to a person, group of persons, or-

ganisation, or agent. A party can fulﬁll different roles

including assigner (issuer of the rule), assignee (re-

cipient of the rule), and tracked party (indicating who

is being traced).

Constraint is used to reﬁne the speciﬁcation of an

action and a party/asset collection or to declare con-

ditions applicable to a rule.

2.3 Running Example

It is about John who is visiting Melissa in Paris. They

agree to meet in a coffee shop next to Melissa’s of-

ﬁce. John can either ride a taxi or take a bus to reach

the coffee shop. It starts when John invokes an on-

line program for itinerary planning so that he would

approximately know how long it would take to reach

the coffee shop. The program is integrated into a Web

site. Prior to deciding on the transportation means,

John checks the weather forecast by invoking another

program that interacts with a dedicated database. Fi-

nally, he accesses the coffee shop’s Web site deployed

on a virtual server to submit a reservation.

In compliance with the RaaS model, existing

practices would bind BPs to on-premise and in-the-

cloud resources through services. However, this bind-

ing would not allow a low-level, ﬂexible control of

these resources. For instance, while databases support

concurrency, identifying particular tasks that would

be eligible for concurrent access as well as the author-

ity that would approve this eligibility is not doable.

Contrarily, ODRL constructs like assignee and as-

signer would help target these tasks and specify this

authority. Another example is how to enforce speciﬁc

time slots or locations. Contrarily, ODRL constructs

like reﬁnement/constraint would achieve this enforce-

ment. Finally, while payment covers a resource as a

whole, paying for speciﬁc operations using a resource

as well as handling the consequences of not fulﬁlling

a payment are not possible. Contrarily, ODRL con-

structs like duty and action with reﬁnement/constraint

would help achieve this targeted payment.

3 CONNECTING CONCEPTS

This section presents the mappings of RaaA onto

AaaS and the operator supporting these mappings.

ICSOFT 2023 - 18th International Conference on Software Technologies

226

Figure 1: Excerpt of ODRL information model diagram.

3.1 Overview

Resource

Service

exposed

as a

(a) Current

Resource

Asset

exposed

as an

Service

exposed

as a

(b) Future

Figure 2: From RaaS to RaaA and then, AaaS.

Fig. 2 (a) is the current practice of concretizing the

RaaS model. Contrarily, Fig. 2 (b) is the future prac-

tice that implements ﬁrst, the RaaA model and then,

the AaaS model. We proceed in Section 3.2 with de-

veloping and/or adopting resource, asset, and service

models. Then, we do the same in Section 3.3 by creat-

ing 3 separate layers, one per model, in a way that the

layers would be semantically connected together us-

ing a speciﬁc operator that would project a construct

from one model to another. Having the AaaS model

on top of the RaaA model addresses some of the

RaaS model’s shortcomings like lack of means for

resource use. Contrarily, the AaaS model accommo-

dates these means using policies that could integrate

permission, prohibition, and obligation rules.

3.2 Model Development

Resource Model. In Fig. 3, Resource as a core class

is connected to Provider class and is described with

a set of functional characteristics captured through a

relevant class. These characteristics depict the pur-

pose of using a resource in terms of processing, stor-

ing, or communicating. Resource is also connected

to another class that is Interface acting as an entry

point (Hintsch et al., 2015) to a particular instantiated

resource at run-time. Practically speaking, an entry

point directs a particular demand of use to a resource

and consists of a set of operations identiﬁed with Op-

eration class. To have a controlled use over instanti-

ated resources at run-time, both Interface and Oper-

ation classes are connected to Non Functional Char-

acteristic class depicting by whom/how/when/where

an instantiated resource is used. Examples of non-

functional characteristics are reported in Table 1.

Table 1: Examples of non-functional characteristics.

Non-functional characteristic Concerned

Name Description Interface Operation

Occurrence single use/multiple uses X

Payment with fees/without fees X

Availability unlimited/limited/... use X X

Chronology speciﬁc order/random order X

Asset Model. We adopt the asset-model diagram de-

picted in Fig. 1 and explained in Section 2.2. Worth

mentioning, in compliance with Fig. 2 (b), the role of

Action class in ﬁrst, identifying what is permitted/pro-

hibited/obliged over an asset and second, setting the

ODRL-Based Resource Deﬁnition in Business Processes

227

Figure 3: Representation of the resource-model diagram.

stage of exposing an asset as a service.

Service Model. In Fig. 4, Service as a core class has

a provider identiﬁed with Provider class, is described

with a set of non-functional characteristics captured

with QoS class, and is associated with several Ser-

vice Level Agreements (SLA) that track the instanti-

ated services’ ongoing provisioning levels to users at

run-time. These users are identiﬁed with Consumer

class. To frame the interactions between consumers

of services and providers of services, SLA are estab-

lished referring to speciﬁc non-functional characteris-

tics. Finally, in Fig. 4, Operation class refers to how

an instantiated service is performed at run time.

3.3 Model Overlay

To achieve the transition from the RaaA model to the

AaaS model as per Fig. 2 (b), we associate this tran-

sition with a projection operator (σ). This operator

would permit in a bottom-up way to semantically cor-

respond a construct, either class or relation along with

their relevant attributes, in a source model into an-

other either a simple or a complex construct in a desti-

nation model. First, simple construct would be either

class or relation along with their relevant attributes.

Second, complex construct would be a set of classes

and relations connecting these classes together. In the

following, C , R , and A stand for class, relation, and

attribute constructs, respectively.

Prior to proceeding with the different projections,

the following points are worth mentioning:

1. When rule class is used, it encompasses permis-

sion, prohibition, and duty classes.

2. When rel(A,B) is used, rel as a relation has A class

as source and B class as destination. The connec-

tion between the 2 classes is set by having rel in-

cluded as an attribute of B datatype in A class.

3. Because party class has a dual role being as-

signer and assignee, this role is differentiated us-

ing function attribute that could be set to either

assigner or assignee. In addition, during the pro-

jection of the asset model’s constructs, party class

appears twice because of the dual role.

Projecting Resources Onto Assets. The resource

model (res) is the source and asset model (ass) is the

destination. Applying σ to the resource model’s con-

structs, i.e., classes, attributes, and relations, would

lead to the following semantic correspondences in the

asset model’s constructs:

1. σ(res:C.Provider) → ass:C .Party allowing to indi-

cate those provisioning resources.

(a) Party.uid ← Provider.uid allowing to uniquely

link the provider to a party.

(b) Party.function ← “assigner” allowing to set the

role of the party using an ODRL-predeﬁned

value that is “assigner”.

2. σ(res:C.Resource) → φ allowing to hide a re-

source from any potential uses.

3. σ(res:C.Interface) → ass:C .Asset allowing to

treat an interface as an asset, which means con-

trolling the use of a resource through its different

interfaces.

(a) Asset.uid ← Interface.uid allowing to uniquely

link the interface to an asset.

(b) Asset.relation ← ”target” allowing to conﬁrm

the control of the interface using an ODRL-

predeﬁned value that is “target”.

4. σ(res:C.Operation) → ass:C .Action allowing to

treat an interface’s operation as an asset’s action.

(a) Action.name ← any uid allowing to set the

name of the action with either a prede-

ﬁned value in compliance with ODRL core-

vocabulary or a new value in compliance with

ODRL proﬁle mechanism.

5. σ(res:C.Functional Characteristic) → φ. The lack

of corresponding constructs is justiﬁed by the fact

that ODRL does not “focus” on assets’ functional

characteristics like what assets are meant for.

6. σ(res:C.Non Functional Characteristic) →

ass:C .Constraint allowing to treat a non-

functional characteristic as a constraint.

(a) Constraint.leftOperand ← any uid allowing to

set the name of the constraint with either a pre-

ICSOFT 2023 - 18th International Conference on Software Technologies

228

Figure 4: Representation of the service-model diagram.

deﬁned value in compliance with ODRL core-

vocabulary or a new value in compliance with

ODRL proﬁle mechanism. This name should

semantically correspond to the non-functional

characteristic’s name to be used as an uid.

(b) Constraint.operator ← “eq” ⊕ “gt” ⊕ ··· al-

lowing to select an operator function that will

set the constraint’s condition to satisfy using an

ODRL-predeﬁned value.

Non Functional Characteristic.value allow-

ing to set the constraint’s value that will be

compared to the leftOperand.

(d) Constraint.unit ←

Non Functional Characteristic.dataType al-

lowing to adopt the data type of the value of

the non-functional characteristic.

The projection of the resource model’s afore-

mentioned classes onto the asset model’s classes

results into a partial overlay of this asset model’s

constructs. Indeed, many classes, of which some

are mandatory

are missing. To consider ODRL

information-model’s mandatory classes and their at-

tributes and to achieve a complete overlay, Policy,

Rule, and Party

classes are considered with focus on

updating their attributes as follows:

1. Policy.uid ← any uid allowing to set the identiﬁer

of the policy that will integrate the necessary rules

that will control the use of an asset related to an

interface.

2. Policy.type ← ”Agreement”⊕ “Offer” ⊕ ··· al-

lowing to set the type of the policy that will

integrate the necessary rules using an ODRL-

predeﬁned value like “Agreement” and “Offer”.

Using “should” and ”may” to describe ODRL con-

structs, we label them as either mandatory or optional.

Though Party is included in the ﬁrst round of pro-

jection as “assigner”, it is included again to identify “as-

signee”.

3. Rule.uid ← any uid allowing to set the identiﬁer

of a rule.

4. Party.uid ← any uid allowing to indicate those

who will be either granted or denied using re-

sources in contrast to those provisioning re-

sources. This assumes that users, referred to

as party, of resources are considered as a non-

functional characteristic.

5. Party.function ← “assignee” allowing to set the

role of the party that will be either granted or de-

nied the use of a resource exposed as an inter-

face using an ODRL-predeﬁned value that is “as-

signee”. This assumes that the party is considered

as a non-functional characteristic.

After examining the different classes, we now

project the relations in the resource model onto the

relevant constructs in the asset model.

1. σ(res:R .provider(C.Resource,C .Provider)) → φ

allowing to hide the relation that exists between

a resource and its provider.

2. σ(res:R .interface(C .Resource,C .Interface)) → φ

allowing to hide the relation that exists between

a resource and its interface.

3. σ(res:R .operation(C .Interface,C.Operation)) →

ass:R .action(C .Rule,C .Action) ∪

ass:R .asset(C .Rule,C .Asset) allows to link an

action corresponding to an operation to an asset

corresponding to an interface through a rule.

(a) Rule.action ← Action allowing to include the

reference of the action in a rule.

(b) Rule.asset ← Asset allowing to include the ref-

erence of the asset in a rule.

4. σ(res:R .functional char(C .Resource,

C .Functional Characteristic)) → φ allowing

to hide the relation that exists between a resource

and its functional characteristics.

5. σ(res:R .non functional char(C .Operation,

C .Non Functional Characteristic)) →

ODRL-Based Resource Deﬁnition in Business Processes

229

ass:R .reﬁnement(C .Action,C .Constraint)) al-

lowing to link a constraint corresponding to

a non-functional characteristic to an action

corresponding to an operation.

(a) Action.reﬁnement ← Constraint allowing to in-

clude the reference of the constraint in an ac-

tion.

6. σ(res:R .non functional char(C .Interface,

C .Non Functional Characteristic)) →

ass:R .constraint(C .Rule,C.Constraint) ∪

ass:R .asset(C .Rule,C .Asset) allowing to link

a constraint corresponding to a non-functional

characteristic to an asset corresponding to an

interface through rules.

(a) Rule.constraint ← Constraint allowing to in-

clude the reference of the constraint in a rule.

(b) Rule.asset ← Asset allowing to include the ref-

erence of the asset in a rule.

By analogy with the partial overlay of the asset

model due to the absence of some classes, we proceed

with the same by considering more relations, permis-

sion, prohibition, obligation, and party, with focus on

updating their attributes as follows:

1. Policy.permission ← Permission allowing to in-

clude the reference of the permission rule in a pol-

icy. This reference corresponds to the relation per-

mission(Policy,Permission).

2. Policy.prohibition ← Prohibition allowing to in-

clude the reference of the prohibition rule in a

policy. This reference corresponds to the relation

prohibition(Policy,Prohibition).

3. Policy.obligation ← Duty allowing to include the

reference of the duty rule in a policy. This

reference corresponds to the relation obliga-

tion(Policy,Duty).

4. Policy.asset ← Asset allowing to include the ref-

erence of the asset in a policy. This reference cor-

responds to the relation asset(Policy,Asset). In-

deed, as asset is common to all rules belonging

to the same policy, we associate it with the Policy

and not Rule construct.

5. Policy.party ← Party allowing to include the ref-

erence of the party in a policy. This reference cor-

responds to the relation party(Policy,Party) where

the party is set as assigner.

6. Rule.party ← Party allowing to include the refer-

ence of the party in a rule. This reference corre-

sponds to the relation party(Rule,Party) where the

party is set as assignee and considered as a non-

functional characteristic.

Projecting Assets Onto Services. After completing

the projection of the resource model’s constructs onto

the asset model’s constructs, we now project these as-

set model’s constructs onto the service model’s con-

structs. Thus, the asset model (ass) is the source and

service model (ser) is the destination. Applying σ

to the asset model’s constructs, i.e., ﬁrst, classes, at-

tributes, and relations, would lead to the following se-

mantic correspondences in the service model’s con-

structs:

1. σ(ass:C .Asset) → ser:C .Service allowing to ex-

pose an asset as a service, which means “shield-

ing” future users from any technical speciﬁcations

related to the asset.

(a) Service.uid ← Asset.uid allowing to uniquely

link the asset to a service.

2. σ(ass:C .Party) → ser:C .Provider subject that

Party.function is set to “assigner”. This projection

allows to expose the party as a provider.

(a) Provider.uid ← Party.uid allows to uniquely

identify the provider of a service.

3. σ(ass:C .Party) → ser:C .Consumer subject that

Party.function is set to “assignee”. This projec-

tion allows to expose the party as a consumer.

(a) Consumer.uid ← Party.uid allows to uniquely

identify the consumer that will be either granted

or denied the invocation of a service.

4. σ(ass:C .Policy) → ser:C .SLA allowing to deﬁne

under the guidance of a service provider the nec-

essary clauses of an agreement between this ser-

vice and a future consumer.

(a) SLA.uid ← Policy.uid allowing to uniquely link

a policy to an agreement.

5. σ(ass:C .Rule) → φ. The lack of corresponding

constructs is justiﬁed by the fact that the service

model does not put any restrictions on for in-

stance, when and where SLAs should be permit-

ted, prohibited, or enforced.

6. σ(ass:C .Action) → ser:C .Operation allowing to

associate an action with a particular operation for

invoking a service.

(a) Operation.uid ← Action.name where name

would be used as the operation’s id.

7. σ(ass:C .Constraint) → ser:C .QoS allowing to de-

velop the non-functional characteristics featuring

the quality-of-service of a service.

(a) QoS.name ← Constraint.leftOperand allowing

to set the non-functional characteristic’s name.

(b) QoS.value ← Constraint.rightOperand allow-

ing to set the non-functional characteristic’s

value.

ICSOFT 2023 - 18th International Conference on Software Technologies

230

to set the condition to satisfy the non-functional

characteristic’s value.

(d) QoS.unit ← Constraint.unit allowing to set the

unit used for the value of the non-functional

characteristic.

After examining the different classes, we now

project the relations in the asset model onto the rele-

vant constructs in the service model.

1. σ(ass:R .permission(C .Policy,C .Permission)) →

φ. The lack of corresponding constructs con-

ﬁrms that SLAs are free of any permissions per-

mitting their enablement. The same applies to

σ(ass:R .prohibition(C .Policy,C .Prohibition)) and

σ(ass:R .obligation(C .Policy,C.Duty)).

2. σ(ass:R .asset (C .Policy,C.Asset)) →

ser:R .sla(C .Service,C .SLA) allowing to link

a SLA corresponding to a policy to a service

corresponding to an asset.

(a) Service.sla ← SLA allowing to include the ref-

erence of the SLA in a service.

3. σ(ass:R .party(C .Policy,C .Party)) →

ser:R .provider(C .SLA,C .Provider) ∪

ser:R .provider(C .Service,C .Provider) allowing to

ensure that the provider that sets a service’s SLAs

corresponding to an assigner will be referenced in

both the SLAs and service associated with these

agreements.

(a) SLA.provider ← Provider allowing to include

the reference of the provider in a SLA.

(b) Service.provider ← Provider allowing to in-

clude the reference of the provider in a service.

4. σ(ass:R .party(C .Rule,C .Party)) → φ allows to

hide the relation that exists between the rule and

party, where Party.function is set to “assignee”.

5. σ(ass:R .constraint(C .Rule,C .Constraint)) → φ al-

lowing to hide the relation that exists between the

rule and constraint.

6. σ(ass:R .action(C .Rule,C.Action)) → φ allowing

to hide the relation that exists between the rule

and action.

7. σ(ass:R .reﬁnement(C .Action,C.Constraint)) → φ

allowing to hide the relation that exists between

the action and constraint.

8. σ(ass:R .permission(C .Policy,C .Permission)) →

φ allowing to hide the relation that exists between

the policy and permission.

9. σ(ass:R .prohibition(C .Policy,C .Prohibition)) → φ

allowing to hide the relation that exists between

the policy and prohibition.

10. σ(ass:R .obligation(C .Policy,C .Duty)) → φ allow-

ing to hide the relation that exists between the pol-

icy and permission.

(a) SLA.consumer ← Consumer allowing to

include the reference of a consumer cor-

responding to an assignee in a SLA.

This reference corresponds to the relation

R .consumer(C .SLA,C .Consumer)

(b) Service.operation ← Operation allowing to in-

clude the reference of an operation in a ser-

vice. This reference corresponds to the relation

R .operation(C .Service,C .Operation)

reference of quality of service in a service.

This reference corresponds to the relation

R .qos(C .Service,C .QoS)

(d) SLA.qos ← Qos allowing to include the

reference of quality of service in a SLA.

This reference corresponds to the relation

R .qos(C .SLA,C .Qos)

4 PROTOTYPE

Developed in Python 3.0 along with using sys, json,

and pyqt5 libraries, the system implementing the pro-

jection operator σ consists of 5 modules, instantia-

tion, R-A projection, A-S projection, A-storage, and

S-storage, and 5 repositories, resources, R-A projec-

tion rules, A-S projection rules, assets, and services.

resource instance, asset instances, and service in-

stances are the system’s outcomes.

To demonstrate how the system is put into action,

we adopt coffee-shop-database as a resource from the

running example. This resource includes many inter-

faces with focus here on DBaccess that implements

read, update, delete, and save operations (Fig. 5’s left

panel). As per Fig. 3, on top of an interface’s non-

functional characteristics like concurrency for DBac-

cess, an operation can also have non-functional char-

acteristics like interactability and availability.

Following resource speciﬁcation through a dedi-

cated editor, R-A projection module is initiated to map

resources speciﬁed in JSON ﬁles onto assets. Fig. 5’s

center panel partially shows the outcome of projecting

the coffee-shop-database resource into ODRL con-

structs such as asset, action, and rule. Among these

constructs that could be set manually, we mention for

instance, a permission rule to read concurrently the

database, a prohibition rule to proscribe updating the

database concurrently and during a speciﬁc period of

time, and an obligation rule to backup the database us-

ing the archive action. Finally, A-S projection mod-

ODRL-Based Resource Deﬁnition in Business Processes

231

Figure 5: Screenshots of resource-asset-service projections.

ule is initiated to project assets into services as per

Fig. 5’s right panel. Here, DBAccess asset has be-

come a service having in compliance with Fig. 4 a

provider, an operation, and a sla, for example. While

some details during A-S projection to specify services

are set automatically because of the pre-deﬁned rules,

the rest like reference to a particular consumer and

QoS are set manually by the end-user.

5 CONCLUSION

This paper presented a customized low-level control

over resources that BPs execution would use at run-

time. We elevated resource to the level of asset and

then, speciﬁed policies that would either permit or

prohibit the use of resources exposed as assets and

afterward, as services. We resorted to ODRL to spec-

ify these policies. We also presented how the double

exposure of resource into asset and then, service was

achieved by developing 2 models, RaaA and AaaS.

A projector operator achieved the double exposure

whose technical doability was veriﬁed based on an in-

house system. In term of future work, we would like

to apply the system to more case studies along with

checking the soundness of RaaA and AaaS models.

REFERENCES

Arias, M., Saavedra, R., Marques Samary, M., Munoz-

Gama, J., and Sepulveda, M. (2018). Human Re-

source Allocation in Business Process Management

and Process Mining: A Systematic Mapping Study.

Management Decision, 56.

Baker, T., Ugljanin, E., Faci, N., Sellami, M., Maamar,

Z., and Kajan, E. (2018). Everything as a Re-

source: Foundations and Illustration through Internet-

of-Things. Computers in Industry, 94.

Hintsch, J., Schr

odl, H., Scheruhn, H., and Turowski, K.

(2015). Industrialization in Cloud Computing with

Enterprise Systems: Order-to-Cash Automation for

SaaS Products. In Proceedings of WI’2015, Os-

nabr

uck, Germany.

Hofman, W. (2015). Towards a Federated Infrastructure for

the Global Data Pipeline. In Proceedings of I3E’2015,

Delft,The Netherlands.

Lucchim, R., Millot, M., and Elfers, C. (2008). Resource

oriented Architecture and REST: Assessment of Im-

pact and Advantage on INSPIRE. JRC Scientiﬁc and

Technical Reports EUR 23397 EN - 2008, JRC Euro-

pean Commission.

Maamar, Z., Faci, N., Sakr, S., Boukhebouze, M., and Bar-

nawi, A. (2016). Network-based Social coordination

of Business Processes. Information Systems, 58.

Pufahl, L., Ihde, S., Stiehle, F., Weske, M., and Weber,

I. (2021). Automatic resource allocation in business

processes: A systematic literature survey. CoRR,

abs/2107.07264.

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

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

ited January 2021).

ICSOFT 2023 - 18th International Conference on Software Technologies

232