Impact of Policies on Organizations Engaged in Partnership

Zakaria Maamar

1 a

, Amel Benna

2 b

and Fadwa Yahya

3 c

University of Doha for Science and Technology, Doha, Qatar

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

Prince Sattam bin Abdulaziz University, Al-Kharj, Saudi Arabia

Keywords:

Partnership, Policy, ODRL, Opposition, Support.

Abstract:

This paper discusses how to identify and assess the impact of policies on organizations that engage in part-

nership. Partnership is a viable option for organizations wishing to sustain their growth and reinforce their

competitiveness to respond to ongoing changing business conditions. Because policies regulate organizations’

operations, they could either promote or undermine partnership. In this paper, policies are specialized into

local and partnership, and are speciﬁed in Open Digital Rights Language (ODRL) deﬁning what is permitted

to do, what is prohibited from doing, and what must be done. The paper devises partnership scenarios as a

set of coordinated partnership policies, labels partnership policies as either supportive of or opposing to local

policies based on an impact analysis, and, ﬁnally, implements a policy-based partnership system.

1 INTRODUCTION

To sustain their growth and reinforce their competi-

tiveness, organizations have multiple practical solu-

tions to choose from such as revisiting their business

practices, exploring new markets, and forming part-

nership that is the focus of this paper.

Despite the bright side of partnership because of

beneﬁts like bridging the gap in expertise and knowl-

edge, securing more cash, and saving costs (Oel-

wang, 2022), the road ahead to a successful partner-

ship could sometimes be “bumpy” minimizing any

form of beneﬁt and even, questioning the purpose of

partnership. Organizations could be forced to adjust

their structures and/or functions to accommodate each

other’s (sometimes conﬂicting) work cultures, busi-

ness requirements, regulations, etc. It happens that an

organization has Bring-Your-Own-Device (BYOD)

policy that is not in-line with a partner’s policy that

restricts on-premise access to internal devices, only.

What should organizations do in this case? Should

they develop new policies which could result in ex-

panding the partnership scope? Should they continue

using existing policies which could result in contract-

ing the partnership scope? Or, should they adjust ex-

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

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

https://orcid.org/0000-0003-4661-1344

isting policies which could, also, result in expanding

the partnership scope with the risk of triggering con-

ﬂicts with other policies? These are some questions

that partnering organizations will have to address.

Aligning ourselves with how Rights Expression

Languages (REL) like Open Digital Rights Lan-

guage (ODRL) provide constructs (e.g., policies, con-

straints, and actions) to control (mainly digital) assets

using permission, prohibition, and duty rules (W3C,

2018), we treat organizations’ systems in this paper

as assets and hence, will be the focus of partnership

scenarios. The analysis of these scenarios would re-

sult in labeling partnership policies as either support-

ive or opposing depending on how they impact ex-

isting local policies of each partnering organization.

This impact is a form of either solidiﬁcation or wors-

ening. On the one hand, a solidiﬁcation example is

when a group of employees can now access a part-

nering organization’s systems off-premise; a duty rule

in a partnership policy forces these employees to use

a security protocol that outperforms what a partner-

ing organization deploys. On the other hand, a wors-

ening example is when another group of employees

now see their access privileges reduced; a permis-

sion rule in a partnership policy refers to a system

that is technically incompatible with a partnering or-

ganization’s systems. Although the current literature

focuses on conﬂicting policies as a potential “side ef-

fect” of partnership (Donghun, 2018; Liu et al., 2021;

684

Maamar, Z., Benna, A. and Yahya, F.

Impact of Policies on Organizations Engaged in Partnership.

DOI: 10.5220/0012718500003687

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 684-691

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

Wu and Liu, 2014), our examples illustrate how dif-

ferent we are in the sense of examining the impact

of partnership policies on local policies. Therefore,

as a pre-requisite to any successful partnership, we

raise the following questions: how are partnership

policies coordinated when devising partnership sce-

narios, and why are partnership policies labelled as

either supportive or opposing with respect to solidify-

ing or worsening local policies?

In this paper, our contributions are, but not lim-

ited to, (i) devising partnership scenarios as a set of

coordinated partnership policies,(ii) speciﬁcation of

partnership and local policies in ODRL, (iii) labeling

partnership policies as either supportive of or oppos-

ing to local policies, and (iv) illustration of how part-

nership policies would either solidify or worsen lo-

cal policies based on this labeling. In the following,

Section 2 brieﬂy presents ODRL, some related works,

and a case study. Section 3 analyzes the impact of

policies on partnering organizations. Section 4 tech-

nically demonstrates this impact. Finally, Section 5

concludes the paper and identiﬁes future work.

2 BACKGROUND

After an overview of ODRL and related works, the

rest of this section discusses a case study.

2.1 ODRL in Brief

ODRL provides a ﬂexible and interoperable informa-

tion model, vocabulary, and encoding mechanisms to

represent statements about the usage of assets. An

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

sources such as data/information, content/media, and

services. ODRL adopts policies to represent permit-

ted and prohibited actions over an asset and required

obligations that stakeholders must meet over this asset

as well (W3C, 2018). ODRL key constructs include:

• Policy could include permission, prohibition, or

duty rules. First, permission allows an action over

an asset if all constraints/duties are satisﬁed/ful-

ﬁlled. Second, prohibition disallows an action

over an asset if all constraints are satisﬁed. Fi-

nally, duty forcibly exercises an action over an as-

set 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 be a person, group of persons, organi-

zation, or agent. A party can fulﬁll multiple

roles namely, assigner, assignee, informed party,

consented party, consenting party, compensated

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

also be combined using logical operators.

Multiple works discuss ODRL from different per-

spectives and in different contexts. For instance, Kas-

ten and Grimm use OWL to enrich ODRL with se-

mantics (Kasten and Grimm, 2010). They note that

ODRL is not meant for speciﬁc case studies and

hence, can be adopted in many applications using the

concept of license. As a result, ODRL is attractive to

both policy advocates and ICT practitioners. In an-

other work, Serr

ao et al. develop OpenSDRM sys-

tem that uses ODRL as a REL in 3 different situa-

tions: digital music e-commerce, video-surveillance

data streaming, and controlled access to remote sens-

ing images (Serr

ao et al., 2005). In conjunction with

ODRL, OpenSDRM adopts SOA’s principles along

with its SOAP, UDDI, and WSDL technologies.

2.2 Related Work

To the best of our knowledge, there are not works that

address the issue of policies impacting other policies

in term of either support or opposition. To address

this limitation, we examine conﬂicting policies as a

potential result of partnership.

In (Donghun, 2018), Yoon describes policy con-

ﬂicts to manage research equipment as “the conﬂict

of interest between the government and the scientists

in the public R&D business and its execution by the

central government, local government, public institu-

tion, etc.”. Upon analysis of these conﬂicts’ causes,

5 strategies were devised: formulate policies for re-

search equipment relocation, hold negotiations for

partial concession from one party to another, diffuse

confrontation with respect to the issues causing con-

ﬂicts, mitigate differences between conﬂicting par-

ties, and promote rewards and mutual beneﬁts. All

these strategies address conﬂicts between the govern-

ment and scientists to improve cooperation.

In (Khakpour et al., 2010), Khakpour et al. pro-

pose PobSAM that is an actor-based model for the

development of self-adaptive systems. PobSAM uses

policies to control and adapt systems’ behaviors. In

addition, PobSAM considers a classiﬁcation of con-

ﬂicts that could exist between a system’s policies.

These conﬂict types are expressed using a set of linear

temporal logic patterns that are then, used to analyze

policies and identify potential conﬂicts. Finally, Pob-

SAM adopts static analysis and model checking tech-

nique to verify the correctness of system adaptation.

In (Liu et al., 2021), Liu et al. focus on attribute-

based access control policy deﬁned in eXtensible Ac-

Impact of Policies on Organizations Engaged in Partnership

685

cess Control Markup Language to propose a formal

deﬁnition of conﬂicts between a pair of rules in terms

of explicit, probable, and never. A conﬂict occurs if

there exists a user’s request such as 2 rules having at-

tributes with intersecting value sets that are applicable

for this request, or the decisions of 2 rules like per-

mit and deny are contradicting. A conﬂict is explicit

if (1) one rule shares all attributes with another rule,

(2) the shared attributes have intersecting value sets,

(3) their action sets overlap, and (4) their decisions

are distinct. A conﬂict is probable if the rules’ ac-

tion sets overlap and their decisions are distinct, and

the attributes of rules generated from the main rules

have intersecting value sets. Finally, there is no con-

ﬂict when either the rules’ decisions are the same, the

rules’ action sets do not overlap, or the rules’ deci-

sions are distinct and their action sets overlap. In

either case, the rules are expected to have a subject,

or an object attribute expression (with a particular at-

tribute) that has non-overlapped value sets.

In (Wu and Liu, 2014), Wu and Liu address policy

conﬂicts for collaborative service computing applica-

tions. Services are designed and deployed to work

according to providers’ policies. However, when ser-

vice collaboration is required to accomplish speciﬁc

business tasks, there could be some conﬂicts between

their respective providers. 3 conﬂict types are consid-

ered: duty, interest, and outcome. To address them,

the authors propose a knowledge-augmented logical

analysis framework that includes temporal logic anal-

ysis rules, semantic extensions, reconciliation rules,

and other domain information. First, a temporal ﬁrst-

order logic is used to express policies, so that the ob-

tained logical expressions are analysed to deduce the

existence/absence of conﬂicts between these policies.

This analysis is augmented by a semantic knowledge

base containing among others attribute relationships

and dynamic constraints between attributes. The log-

ical analysis framework uses this information in the

logic reasoning to address the conﬂict.

Regarding ODRL, conﬂicts could occur between

permission and prohibition rules included in the same

policy, or when merging policies because of policy

inheritance and the resultant rules are inconsistent.

To address such conﬂicts, a policy with the conﬂict

property as either perm, prohibit, or invalid could be

used. Perm value means that a permission rule must

override a prohibition rule. Prohibit value means that

a prohibition rule must override a permission rule.

Finally, invalid value applies when the entire policy

is made void because of a conﬂict detected between

rules after a policy merge or inheritance.

The works above address conﬂicting policies us-

ing different techniques. However, there is a limited

emphasis on potential relations like support and op-

position that would capture the impact of policies on

other policies. In this paper, we use constraints to es-

tablish such relations along with using ODRL to spec-

ify these policies and their constraints.

2.3 Case Study

Our case study involves 2 organizations, weRetail

that operates in on-line shopping and weDeliver that

couriers parcels to customers’ locations. weRetail

runs online systems (assets according to ODRL vo-

cabulary) that policies manage in terms of who can

consult what, for what purpose, etc. Listing 1 is a pol-

icy between weRetail (line 6) and a customer (line 7).

The customer sets 48 hours (lines 11-13) prior to the

delivery date as a time limit (lines 15-17) for weRetail

to update (line 9) her order like substituting items and

changing delivery dates. Passed this time limit, the

update is prohibited (line 4) unless weRetail (line 21)

compensates the customer (line 22).

Listing 1: ODRL speciﬁcation for customer orders.

1{" @context ": " ht t p : / / www . w 3 . or g / n s / o d rl . jso n l d " ,

2 " uid " : " http : // example . c om / po l i c y : 3 04 " ,

3 " @ t ype ": " Reques t " ,

4 " p r o hibitio n " : [{

5 " ta r g e t " : " ht t p : / / e x a m p l e . com / w e R e t a i l /

as s e t / C u s t omer O r d e r s " ,

6 " assigner " : " h ttp : // example . com / weRetail " ,

7 " assignee " : " h ttp : // example . com / us e r s /

customer " ,

8 " ac t i o n " : [{

9 " r df : va l u e " : {" @id " : " o drl : u se "},

10 " refi n e m e n t " : [{

11 " le f t O p e r a n d " : " elaps e d T i m e " ,

12 " operator " : " l t ",

13 " ri g h t O p e r a nd " : {" @ v a l ue " : " 4 8 H" , "

@t y p e " : " xs d : d u r a t i o n "},

14 " comme n t " : " l e ss tha n 48 h"},

15 {" l e f t O p e r an d " : " dateTime " ,

16 " operator " : " gt e q " ,

17 " ri g h t O p e r a nd " : " ht t p s : // w ww .

wikidata . org / w i ki / Q 2 0 0 5 8 7 9 3 " ,

18 " comme n t " : " de l i v e r y da te "}]}] ,

19 " re m e d y " : [{

20 " ac t i o n " : " co m p e n s a t e " ,

21 " c o m p e n sat i n g P a r ty " : " h ttp : // e x a m p l e .

co m / weRetail " ,

22 " c o m p e n sate d P a r t y " : " h ttp : // e x ample . co m

/ us e r s / c u s t o m e r "

23 }]}]}

The description above also applies to weDeliver

that has policies like in Listing 2. The main dif-

ferences with Listing 1 reside in the parcel schedul-

ing system that is the asset (line 5), the collection of

employees who are the assignee (lines 7-9), and the

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

686

permission rule (line 4) that is constrained by a duty

rule (line 11). This rule obliges weDeliver’s employ-

ees to request an access consent twice (lines 14-17)

from a consenting party (line 18).

Listing 2: ODRL speciﬁcation for parcel scheduling.

1{" @context " : " ht t p : / / www . w 3. or g / ns / o d rl . jso n l d " ,

2 " uid " : " http : // example . c om / po l i c y : 2 01 " ,

3 " @ t ype ": " Agreem e n t " ,

4 " p e r m is si on " : [{

5 " ta r g e t " : " h ttp : // example . com / weDelive r /

as s e t / p a rce l S c h edu l i n g Sys t e m ",

6 " assigner " : " h ttp : // example . com / weDeliv e r " ,

7 " assignee " :{

8 " @t y p e " : " P a r tyCo l l e c t i on " ,

9 " so u r c e " : " h ttp : // example . com / weDelive r /

employees /"},

10 " ac t i o n " : " e x e c u t e " ,

11 " du ty " : [{

12 " ac t i o n " : [{

13 " r df : va l u e " : {" @id " :" od r l :

obt a i n C o n s en t "},

14 " refi n e m e n t " : [{

15 " le f t O p e r a n d " : " c o u n t " ,

16 " operator " : " e q ",

17 " ri g h t O p e r a nd " : " 2 " ,

18 " un it " : " htt p s : // w ww . wikidata . o rg /

wi k i / Q 1 15 6 3 "}]}],

19 " c o n s e n t ingP a r t y " : " h t tp : // e x a m p l e . co m /

pa r c e l Sch e d u l ing S y s t em / c o n s e n t m en t "}

]}]}

Handling joint customers’ order and delivery

transactions, weRetail and weDeliver combine their

efforts during peak-seasons giving their respective

employees the opportunity of temporarily accessing

each other’s systems while maintaining full control

of these systems (Listings 1 and 2). For instance,

weRetail will schedule, without weDeliver interven-

tion, immediate deliveries to consumers who spend

more than $2000 in a single transaction per day. And,

weDeliver will modify orders’ delivery dates with-

out the intervention of weRetail, should some delivery

time-slots turn out slightly loaded and hence, could be

ﬁlled out with some early deliveries. These 2 scenar-

ios shed light on some requirements that partnership

policies should capture like the temporary nature of

partnership, eligible employees from each organiza-

tion to access each other’s systems, etc. Below are

2 partnership policies exemplifying how local policies

become solidiﬁed and worsened, respectively, based

on how these partnership policies are deﬁned.

1. Partnership policy solidifying Listing 2’s local

policy where a new assignee is linked to an exist-

ing asset. To allow John from weRetail to access

weDeliver’s parcel scheduling system, he has to

be in a speciﬁc location and to secure at least the

same number of access consents from the same

consenting party. In Listing 3, the partnership pol-

icy has John as an assignee who is given access to

the parcel scheduling system as per the agreement

between both organizations. The solidiﬁcation of

Listing 2’s local policy with respect to Listing 3’s

partnership policy is due to both the access from

a speciﬁc location and the adoption of at least the

same number of consents.

Listing 3: ODRL speciﬁcation for a partnership policy (1).

1{" @context " : " ht t p : / / www . w 3. or g / ns / o d rl .

js o n l d " ,

2" uid " : " htt p : // exampl e . c om / p o l i c y : 3 02 " ,

3" @ type ": " Agreement " ,

4" p e r m i ss io n ": [{

5 " ta r g e t " : " h ttp : // example . com / weDelive r /

as s e t / p a rce l S c h edu l i n g Sys t e m ",

6 " assigner " : " h ttp : // example . com / weDeliv e r " ,

7 " assignee " : " h ttp : // example . com / weRetail /

us e r s / Joh n " ,

8 " ac t i o n " : [{

9 " r df : va l u e " : {" @id " : " e x e c u t e "},

10 " refi n e m e n t " : [{

11 " le f t O p e r a n d " : " sp a t i a l " ,

12 " operator " : " e q ",

13 " ri g h t O p e r a nd " : " h t tps : // www . w i k i d a t a .

or g / wi k i / Q 1 83 ? wprov = s rpw 1_ 0 " ,

14 " comme n t " : " G e rmany "}]}] ,

15 " du ty " : [{

16 " ac t i o n " : [{

17 " r df : va l u e " : {" @id " : " o d rl :

obt a i n C o n s en t "},

18 " refi n e m e n t " : [{

19 " le f t O p e r a n d " : " c o u n t " ,

20 " operator " : " gt e q " ,

21 " ri g h t O p e r a nd " : " 2 " ,

22 " un it " : " h t tps : // www . w i k i d a t a . org /

wi k i / Q 1 15 6 3 "}]}],

23 " c o n s e n t ingP a r t y " : " htt p : // e x a m p l e . com /

pa r c e l Sch e d u l ing S y s t em / c o n s e n t m en t "

}]}]}

2. Partnership policy worsening Listing 1’s local

policy where a new assignee is linked to an exist-

ing asset. Should Michael from weDeliver modify

the delivery date of any customer’s order stored

in weRetail’s system, then weDeliver will com-

pensate the customer if the modiﬁed delivery date

happens after the 48 hours time-limit set in List-

ing 4. The worsening of Listing 1’s local policy

with respect to Listing 4’s partnership policy is

due to the additional ﬁnancial compensation.

Listing 4: ODRL speciﬁcation for a partnership policy (2).

1{" @context " : " ht t p : / / www . w 3. or g / ns / o d rl .

js o n l d " ,

2" uid " : " htt p : // exampl e . c om / p o l i c y : 3 05 " ,

3" @ type ": " Agreement " ,

4" p r o h ibitio n " : [{

Impact of Policies on Organizations Engaged in Partnership

687

5 " ta r g e t " : " h ttp : // example . com / weRetail /

as s e t / C u s t omer O r d e r s " ,

6 " assigner " : " h ttp : // example . com / weRetail " ,

7 " assignee " : " h ttp : // example . com / weDeliv e r /

Mich a e l " ,

8 " ac t i o n " : [{

9 " r df : va l u e " : {" @id " : " o drl : m o d i f y "},

10 " refi n e m e n t " : [{

11 " le f t O p e r a n d ": " ela p s e d T i m e " ,

12 " operator " : " l t ",

13 " ri g h t O p e r a nd " : {" @ v a l ue " : " 4 8 H" , "

@t y p e " : " xs d : d u r a t i o n "},

14 " comme n t " : " l e ss tha n 48 h"},

15 {" l e f t O p e r an d " : " dateTime " ,

16 " operator " : " gt e q " ,

17 " ri g h t O p e r a nd " : " h t tps : // www . w i k i d a t a

. o rg / w i k i / Q 2 0 0 5 8 7 9 3 " ,

18 " comme n t " : " de l i v e r y da te "}]}] ,

19 ... ,

20 " re m e d y " : [{

21 " ac t i o n " : " co m p e n s a t e " , . ..}]}]}

3 PARTNERSHIP POLICIES

MANAGEMENT

This section manages policy-based partnership with a

focus. labelling partnership policies as either support-

ive of or opposing to local policies.

3.1 Overview

Fig. 1 represents the chronology of operations that en-

ables partnership between organizations using part-

nership policies and evaluate the impact of partner-

ship policies on these organizations’ local policies. It

begins when organizations

i, j

develop local policies to

manage their own assets (1) and then, engage in part-

nership like in Section 2.3. This engagement initi-

ates developing joint scenarios. For each joint sce-

nario, relevant bodies deﬁne partnership policies (2)

and then, submit them to the policy engine for ver-

iﬁcation prior to their storage like the rest of local

policies in a dedicated repository (3). Once the def-

inition of all policies is complete, they are submit-

ted to the partnership engine that coordinates partner-

ship policies and next, labels them as either support-

ive of or opposing to local policies (4). More details

about policy labeling are given in Section 3.2. Notic-

ing both that supportive partnership policies solidify

local policies and that opposing partnership policies

worsen local policies, organizations

i, j

take measures

to reinforce the solidiﬁcation and offset the worsen-

ing, respectively (5).

Partnership ecosystem

Partnership

policies

Supportive

partnership policies

Local

policies

Local

policies

Management

Assets

Opposing

partnership policies

xor

Policy engine

Partnership engine

Impact

Organization 

i

1 1

2

3 33

4

2

Joint scenarios

definition

Organization 

j

2

application

Local policies

solidification

Local policies

worsening

application

Offsetting

measures

Reinforcement

measures

Measures

5 5

Figure 1: Policy-based management of partnership.

3.2 Labeling Partnership Policies

To label partnership policies as either supportive of

or opposing to local policies, we look into poten-

tial overlaps between their respective constraints. In

ODRL, the constraint construct applies to speciﬁc

constructs namely, action, assignee, rule, and as-

set although constraints are optional in policies. To

label partnership policies, introduce the prohibition-

nulliﬁcation concept and then, adopt ODRL constraint-

structure to label a partnership policy. Fig. 2 summa-

rizes the chronology of operations to adopt and the

conditions to check underpinning this labeling.

Prohibition nulliﬁcation converts a prohibition

rule into a permission rule to ensure an “homoge-

neous” analysis of rules across all partnership and lo-

cal policies. We select permission rule because of the

lack of obligation to trigger a prohibition rule after

conversion. Should a prohibition rule have constraints

on itself, then their complementary constraints will

be integrated into the permission rule. In addition,

should a prohibition rule include remedies that com-

pensate this rule’s violation, then the remedies will

become duty rules in the permission rule.

In ODRL, a constraint structure consists of

2 operands connected by 1 relational operator like

in Listing 1’s lines 10-12 where the leftOperand

is “elapsedTime”, the rightOperand has a value of

A predeﬁned list of ODRL terms exists.

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

688

Analyse PPs & LPs

no

Does PP include

prohibition rules?

no

Analyse constraint relations

per pairwise of constraints

yes

Nullify prohibition

rules

Are they

constraint free?

Do constraint

relations hold?

yes

PP no-labeling

no

PP no-labeling

yes

PP labeling

for all constraints

Figure 2: Flowchart of partnership policies labelling.

48 hours, and the operator is “It”. Thanks to the left-

Operand, we categorize constraint into budget, secu-

rity, time, location, and personnel.

In conjunction with prohibition nulliﬁcation,

we deﬁne constraint relation between P artnership

P olicies (P P ) and L ocal P olicies (L P ) using their

respective constraints, P P

i,C

and L P

j,C

that apply

to the same actions in these policies’ rules. This re-

lation allows to decide on the constraint that a part-

nership policy would use, i.e., P P

i,C

, P P

j,C

, ei-

ther P P

i,C

or P P

j,C

, or neither P P

i,C

nor L P

j,C

leading to label a P P as either supportive of, oppos-

ing to, partially supportive of/opposing to, or neutral to

a L P , respectively. The constraint relations are:

- consolidate(P P

i,C

,L P

j,C

): when initiating

P P

, LP

j,C

takes effect over P P

i,C

. Should the

consolidate relation hold, then P P

will be labeled

as supportive of LP

for that particular constraint

and hence, L P

j,C

will be adopted.

- override(P P

i,C

,L P

j,C

): when initiating P P

P P

i,C

takes effect over L P

j,C

. Should the over-

ride relation hold, then P P

will be labeled as op-

posing to LP

for that particular constraint and

hence, P P

i,C

would be adopted.

- nullify(P P

i,C

,L P

j,C

): when initiating P P

, nei-

ther P P

i,C

nor L P

j,C

takes effect calling for

adjusting P P

i,C

into P P

i,C

′

without violating

L P

j,C

. Should the nullify relation hold, then P P

will be labeled as partially supportive of/opposing

to LP

for that particular constraint and hence,

P P

i,C

′

will be adopted.

- relax(P P

i,C

,L P

j,C

): when initiating P P

, ei-

ther P P

i,C

or L P

j,C

takes effect. Should the

relax relation hold, then P P

will be labeled as

neutral to L P

for that particular constraint and

hence, either P P

i,C

or L P

j,C

will be adopted.

Let us illustrate the discussions above with 3 ex-

amples including the case study. In the ﬁrst ex-

ample, P P

’s and L P

’s constraints are on the ac-

tion construct. We assume that “dateTime“ left-

Operand in these constraints is deﬁned as a time in-

terval ([b

i| j

, e

i| j

]). To reason over time intervals, we

resort to time relations (Allen, 1983):

1. Should equals([b

, e

], [b

, e

]) hold, then re-

lax(P P

i,C

,L P

j,C

) will exist indicating that P P

is time-based neutral to L P

. P P

i,C

’s time in-

terval fully covers LP

j,C

’s time interval and

vice versa.

2. Should during|starts| f inishes([b

, e

], [b

, e

])

hold, then override(P P

i,C

,L P

j,C

) will exist

indicating that P P

is time-based opposing to

L P

. P P

i,C

’s time interval partially covers

L P

j,C

’s time interval.

3. Should contains([b

, e

], [b

, e

]) hold, then con-

solidate(P P

i,C

,L P

j,C

) will exist indicating that

P P

is time-base supportive of LP

. L P

j,C

’s

time interval is totally covered by P P

i,C

’s time

interval.

4. Should precedes|meets([b

, e

], [b

, e

]) hold, then

P P

will not be labelled with regard to LP

5. Should overlaps([b

, e

], [b

, e

] hold, then nullify

(P P

i,C

,L P

j,C

) will exist indicating that P P

is partially time-based supportive of/opposing to

L P

. Some parts of P P

i,C

’s time interval do not

cover L P

j,C

’s time interval leading to adjusting

P P

i,C

’s initial time interval to [b

, e

Another example is the case study where P P ’s

constraints in Listing 3 and L P ’s constraints in List-

ing 2 are on the action construct. To start with, the

execute action is constraint free in the local policy, so

this policy is dropped from the labeling of the part-

nership policy. Let us now focus on the obtainCon-

sent action that is present in both policies. Based

on the respective constraints on this action, consoli-

date(P P

count

,L P

count

) exists because the partnership

policy requires at least the same number of consents

as the local policy does indicating that P P is security-

based supportive of L P .

Impact of Policies on Organizations Engaged in Partnership

689

Figure 3: Labeling of P P

as supportive of L P

Figure 4: Labeling of P P

as opposing to L P

Figure 5: Labeling of P P

as partially supportive of/opposing to L P

4 IMPLEMENTATION

To assess the impact of policies on partnering orga-

nizations’ assets, a system was developed in Java 8

using Eclipse IDE for Java Developers and deployed

on Windows 8 64 bits, 1.4 GHz quad-core proces-

sor CPU, 4GB RAM desktop. It mainly targets

Fig. 1’s partnership engine along with categorizing

constraints (e.g., budget, time, and location), so that

relevant policy managers in the system are enabled.

The source code is released on GitHub at https:

//tinyurl.com/4sc367vn.

The system parses L P s and P P s to identify those

pairwises of L P

and P P

that have similar assets

and similar actions on these assets, so they could en-

gage in supporting and/or opposing relations. The

parsing is taken care of by an in-house JSON parser

developed using json-simple Java library. Then, the

system categorises these pairwises as per their re-

spective constraints. For each categorized L P

and

P P

pairwise, the system selects the adequate pol-

icy manager to label these policies using constraints’

leftOperand. Depending on constraint categories, dif-

ferent tools are used such as Joda-Time java

library

to deal with time and time-interval constraints, and

https://www.joda.org/joda-time/

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

690

World Cities Database

to deal with location con-

straint. This database includes more than 4 million

cities and towns in the world and can be queried to

deﬁne relations like equals, contains, and disjoint be-

tween 2 locations.

To test the system, we adopted LP

and P P

of Listings 2 and 3, respectively, and deﬁned more

for instance, L P

2,3

and P P

2,3

integrating spatial and

dateTime ODRL constraints. An overview of these

policies is as follows: P P

(the use of the parcel

scheduling system as an asset is constrained to a spe-

ciﬁc location that is Tokyo), L P

(the use of the par-

cel scheduling system as an asset is constrained to a

speciﬁc location that is Japan), P P

(the use of the

parcel scheduling system as an asset is constrained to

a speciﬁc time-period that is 2023-11-15 to 2024-01-

15), and L P

(the use of the parcel scheduling system

as an asset is constrained to a speciﬁc time-period that

is 2023-12-01 to 2024-01-31).

Afterwards, we submitted the policies to the sys-

tem for labeling. Fig. 3 shows that P P

is supportive

of L P

due to consolidate relation. Fig. 4 shows that

P P

is opposing to L P

because of override relation.

Finally, Fig. 5 shows that P P

is partially supportive

of/opposing to L P

because of nullify relation.

5 CONCLUSION

This paper discussed partnership as a viable option

for organizations wishing to bridge the gap in exper-

tise and knowledge, to secure more cash, and to save

costs. However, partnership could run into obstacles

minimizing its beneﬁts and even, questioning its pur-

pose when organizations end-up adjusting their struc-

tures and/or functions to accommodate each other’s

(sometimes conﬂicting) work cultures, business re-

quirements, and regulations. These regulations cor-

respond to policies that we specify in ODRL and spe-

cialize into partnership and local. To examine poten-

tial relationship between these 2 types of policies, we

devised partnership scenarios as a set of policies to

coordinate, labeled partnership policies as either sup-

portive of or opposing to local policies, and ﬁnally

demonstrated a system implementing policy-based

partnership targeting a case study involving weRe-

tail that operates in the domain of on-line shopping

and weDeliver that operates in the domain of courier-

ing parcels to customers’ locations. In term of future

work, we would like to deﬁne measures that either

reinforce the solidiﬁcation of or offset the worsening

of local policies, assess the scalability of the system

simplemaps.com/data/world-cities.

when several policies need to be managed, and imple-

ment the reinforcement and offsetting measures.

REFERENCES

Allen, J. (1983). Maintaining Knowledge about Temporal

Intervals. Communications of the ACM, 26(11).

Donghun, Y. (2018). The Policy Conﬂict Research of In-

terested Parties for the Efﬁcient Management of Re-

search Equipment: With Focus on the Government

and the Scientist. Cogent Business & Management,

5(1).

Kasten, A. and Grimm, R. (2010). Making the Semantics

of ODRL and URM Explicit Using Web Ontologies.

In Proceedings of Goods’2010, Namur, Belgium.

Khakpour, N., Khosravi, R., Sirjani, M., and Jalili, S.

(2010). Formal Analysis of Policy-based Self-

Adaptive Systems. In Proceedings of SAC’2010,

Sierre, Switzerland.

Liu, G., Pei, W., Tian, Y., Liu, C., and Li, S. (2021). A

Novel Conﬂict Detection Method for ABAC Security

Policies. Journal of Industrial Information Integra-

tion, 22.

Oelwang, J. (2022). Partnering. Optimism Press.

Serr

ao, C., Dias, M., and Delgado, J. (2005). Using ODRL

to Express Rights for Different Content Usage Sce-

narios. Technical report, Iscte Repository, University

Institute of Lisbon, Portugal, https://repositorio.isct

e-iul.pt/handle/10071/250.

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

w.w3.org/TR/2018/REC- odrl-model- 20180215/.

(Visited January 2022).

Wu, Z. and Liu, Y. (2014). Knowledge Augmented

Policy Conﬂict Analysis for Services Collaboration.

Knowledge-Based Systems, 62.

Impact of Policies on Organizations Engaged in Partnership

691