Cari2020 Rodrigue Aimé Djeumen Djatcha

A role-based collaborative process design
on crowdsourcing systems
Rodrigue Aimé Djeumen Djatcha
Faculty of Sciences, University of Douala, Cameroon
LIRIMA FUCHSIA Team
CARI’2020
African Conference on Research in Computer Science and Applied Mathematics
Polytech School of Thiès, Senegal
October 2020
R.A. Djeumen D. (Univ. Douala & Fuchsia) A role-based collaborative process design CARI’2020 1

Case study: crowdsourced road maintenance activity
Consider a city participatory management case, with ﬁve stakeholders
categories involved:
1 Citizens (BOB, JANE, ALICE,...) provide information on the state of city roads and
determine which ones to maintain as priority;
2 Urban Information System (URBANIS), an infrastructure dedicated to collect, store,
process and broadcast information city wide;
3 Cleaning Company (CLEANING_CO), in charge of road cleaning, waste management,...;
4 Road maintenance company (ROAD_CO);
5 City council (DOUALA1), made up of elected representatives in charge of city
management.

A targeted road maintenance activity, with participation of all stakeholders, can be carried out by
the process depicted below
each stakeholder has both infrastructure mechanisms and functional goals in the system,
namely:
BOB, JANE, ALICE infrastructures, offer SENSOR and CITIZEN functionalities,
URBANIS infrastructure offer IS functionality,
CLEANING_CO infrastructure offer CLEANER functionality,
...

The process described above takes place on a collaborative system context having
various characteristics:
1 There is a clear separation between stakeholder’s infrastructure mechanisms and
functional goals,
infrastructure mechanisms simply termed actor, describes intrinsic skills;
functional goal termed role describing business skills.
2 each actor can play one or more roles to provide precise services,
3 multiple instances of the same role could exist in the process (i.e. different ways of
providing same services),
4 several actors (the crowd) can play the same role instance, then services provided are
crowd services,
5 service calls may not be hierarchically organized.
Such a system is a crowdsourcing system, as it is a set of multi-skilled independent
stakeholders which potentially provide precise services on request.

Problematic
A crowdsourcing system can be seen both as:
a software architecture style, inspired by service-oriented architectures, but with
service calls not often hierarchically organized,
that allows you to build an application by assembling a suite of small services, or
organized groups of services (roles).
a set of services, interacting in a dynamic context, for solving a given problem.
In such a system, the concept of role is central because, each actor involved
must have a clear framework within which to collaborate with other actors.
The role speciﬁes both what the system expects from a stakeholder, but also what a
stakeholder expects from the system, thus avoiding access to information (or tasks) that are
not necessary.
But...
Traditionally, collaborative systems lose ﬂexibility as soon as their design is role-oriented,
because only static role description mechanisms, based on intuitive concepts, are available.

Solutions
The problem, is solved in four steps:
1 defining clearly what an outsourceable task or crowd task is,
by introducing a crowdsourcing tasking model,
2 specify roles clearly and rigorously, while ensuring flexibility for
collaboration,
this is achieved by the interfaces of roles concept,
3 providing role switching mechanisms,
4 providing an abstract basis, for crowdsourcing system design and
workflow monitoring and checking mechanisms.
Goal
Being able to partially or completely specify crowdsourcing system processes,
by means of roles involved in a given context.

Outline
2 Grammatical tasking Model speciﬁcation
Role, Business skills
Crowd tasks, Crowd Role
Interface of role
Basic operations on role interface
3 Collaboration, collaboration schemes and Workﬂows
4 Activity in collaborative context
5 Actor of a crowdsourcing system
6 Conclusion

Specifying Role (r) & Business skills (G)
A role r is given by a couple (G,R) where
G is a guarded attribute grammar (GAG) specifying role r business skills,
R it’s associated interface of role.
Business skills are expressed as grammar production rules (or business
rules), describing job decomposition, in the form
s0 → T0···Tm s1 ···sn s0 ···sp (1)
where:
s0 is a deﬁned service,
T0···Tm are intrinsic skills,
s1 ···sn are used services,
s0 ···sp are crowd tasks or crowd services.

Crowd tasks (si) & Crowd role specification
Crowd tasks are defined by business rules like
si → T0···Tm (0 ≤ i ≤ p)
i.e they are type of services requiring only intrinsic skills, to be carried out
and so, they are autonomous services.
Consider a business rule s0 → T0···Tm
In fact s0 is a potentially outsourceable task, it can be defined and used
in the same role (or used by another role);
rather s0 is an outsourced task, so it is only defined in an autonomous role,
term crowd role, and only used by a requester role.
By convention, a crowd role is autonomous and only define outsourced
tasks, and we say a crowd role supply only crowd services.

Interface of role (R)
An interface of role R is an abstraction of a role r business skills as a tuple (•R,R,R•),
specifying services provided (R•) by r, which external services are required (•R) to carry them
out and the potential dependencies between required and provided services (R).
As an example, an Information System (IS) basically collect, store, process and broadcast
information among the city. It can be orchestrated on request (req) to conjointly select a targeted
road for maintenance, using business skills:
selectRoad → COLLECT STORE PROCESS BROADCAST req clSnap tagPicture
selectRoad → PROCESS BROADCAST req snap tagPicture
alert → ε
(2)
with associated interface of role
•IS = clSnap,snap,tagPicture,req
IS = (clSnap,selectRoad),(snap,selectRoad),(tagPicture,selectRoad),(req,selectRoad),(_,alert)
IS• = {selectRoad,alert}
(3)

Role interface basic operations
Let R1 and R2 be two interfaces of roles, associated to roles r1 and r2 respectively and O a
given subset of services.
Three basic operations on interfaces are deﬁne below:
Restriction ( ): R1 O reconﬁgure role r1 so that, only its provided services elements of O are
enabled; useful when just some skills of a multi-skilled role are needed.
Cascade composition test ( , ): cascade composition of roles r1 and r2 holds iff
R•
1 ∩ •R2 = /0∧•R1 ∩R•
2 = /0. We denote R1 R2 their cascade product test
(or R2 R1 since this operation is commutative).
Direct Product(×) consider R1 and R2 two composable role interfaces. If R•
1∩•R2 = /0 and
R•
2 ∩•R1 = /0 , the composition is the (direct) product of R1 and R2, denoted
by R1 ×R2. Note that R1 ×R2 = R1 ∪R1 and so •(R1 ×R2) = •R1 ∪•R2 and
(R1 ×R2)• = R•
1 ∪R•
2.

Outline
Defining role collaboration
Collaboration schemes
Workflow of a service
Workflow factorization
6 Conclusion

Deﬁning role collaboration
A role r1 = (G1,R1) potentially depends on a role r2 = (G2,R2) iff R1 R2 holds; and •R1 ∩R•
2 are
services provided (or required) in that dependence.
Two roles r1 and r2 are in a direct collaboration iff r1 potentially depends on r2 or r2 potentially depends on
r1 (i.e. R1 R2 or R2 R1), and we denote (•R1 ∩R•
2 ,r2,r1) resp. (•R2 ∩R•
1 ,r1,r2) that collaboration,
labeled by •R1 ∩R•
2 , the set of services for which r1 and r2 collaborate,
r1 being the services requester (resp. provider),
r2 is the provider (resp. requester) of those services.
r1 and r2 will be in an indirect collaboration iff ∃rk = (Gk ,Rk ) such that R1 Rk R2 holds.

Collaboration schemes
Consider a reasoning context R below, in which each role ri is member with associated interface
Ri (0 ≤ i ≤ 6)
For a given role rk in the context, it’s potential direct collaborations rPDG(rk ,R) can be
processed as follow
rPDG(rk ,R)
| rk = ri = if Rk Ri then rPDG(rk ,R/{ri })∪{(•Rk ∩R•
i ,ri ,rk )}
| rk == ri = rPDG(rk ,R/{ri })
such that
rPDG(r3,R)= {({x},r0,r3), ({x},r4,r3), ({t},r2,r3), ({w},r1,r3)}

The induced potential dependencies graph (iPDG) or collaboration scheme of that context, is
then processed as
iPDG(R,R ) =
if (ri in R) and (R = /0) then rPDG(ri ,R ∪R ) ∪ iPDG (R {ri },R )
with
iPDG(R, /0) = {({a},r5,r0),({m},r6,r4),({y},r0,r2),
({z},r1,r2),({w},r1,r3),({x},r4,r3),
({x},r0,r3),({t},r2,r3)}
(4)

Potential workflow of a service
From the context R depict by collaboration scheme iPDG(R, /0), an induced workflow of a
service, describes how this service will be issued and which roles are involved.
For instance, workflow of service u is given below:
workflow({u},R) = { (x,r4,r3),(x,r0,r3), (t,r2,r3),(m,r6,r4), (a,r5,r0),(y,r0,r2),(z,r1,r2)}

A collaboration scheme may include several alternatives in supplying the same service.
In a given context, factorizing is being able to transform cases such as for a role r3,
requesting service x, so that we have service x potential suppliers list;
An F −collaboration is a triplet (•R0 ∩R•
1 ,{r1,···rm},r0), where r1,···rm are potential providers of services
elements of set •R0 ∩R•
i (1 ≤ i ≤ m) and r0 is the requester for those services (with
•R0 ∩R•
1 = ··· = •R0 ∩R•
m).
A factorized collaboration scheme is then a potential dependency graph, possibly consisting
of collaborations (i.e (•R0 ∩R•
1,r1,r0)), and F −collaborations ((•R0 ∩R•
i ,{r1,···rm},r0)) if
necessary.

Outline
Activity: deﬁnition and some properties
Decomposition
Realisability
6 Conclusion

Activity and some properties
An activity for a given service s0, in a context R, is a couple activitys0
= (s0,workflow({s0},R)),
viewed as supplying service s0, using by workflow({s0},R).
Equivalence
Two activities activitys0
and activitys1
are equivalent, and we denote by activitys0
≡ activitys1
, iff s0 = s1 and
workflow({s0},R) ≡ workflow({s1},R) i.e they deliver the same service in context R, by different ways.
Atomicity
An activity activitys0
= (s0,workflow(s0,R)) is atomic, iff for all (s0,ri ,rj ) and (s0,rk ,rj ) in workflow(s0,R),
ri = rk .

Activity decomposition
Consider below an E-administration activity for issuing civil status certiﬁcates
The above activity can be broken down into two atomic sub-activities, representing individually
the different possibilities of issuing a civil status certiﬁcate.

An activity with associated factorized workflow C , can progressively be fragmented into a set of
atomic activities C,
decomp(C ,C) = forall c in C
if |provider(c)| == 1 then //c is like (•R0 ∩R•
1 ,{r1},r0)
decomp(C {c},insert(c,C))
else
if |provider(c)| > 1 then //c is like (•R0 ∩R•
1 ,{r1,··· ,r|c|},r0)
decomp(C {c},mdup(c,C))
as long as there are several occurrences of the same role r in an activity, this activity is broken down into
new activities containing a single role occurrence r.
Consider activitys0
= (s0,workflow0(s0,R)) and activitys0
= (s0, workflow1(s0,R)) two activities, where
activitys0
≡ activitys0
.
activitys0
is decomposable to activitys0
if and only if
workflow0(s0,R) = workflow1(s0,R) and factorize(workflow0(s0,R)) = workflow1(s0,R)

Activity realisability
Realizability refers to the possibility of carrying out an activity, in a finite number of stages, and rendering
provided service.
This assumes that all necessary roles are available instantly; we say it is a favorable context.
Termination of an activity, is conditioned by the fact that its workflow must roles triggers.
realizable(/0,_) = (True, /0) //the workflow is realizable
realizable(Serv, /0) = (False,Serv) //not realizable, Serv are required services
realizable(Serv,c ∈ C)
| Serv ∩ label(c) == /0 =realizable(Serv ∪ req,C {c})
| Serv ∩ label(c) = /0 =realizable(Serv ∪ req,C {c})
where
Serv = Serv (x ∈ Serv ∧ x /∈ label(c))
req = dependOn(label(c), provider(c))
An activity activitys0
= (s0,workflow(s0,R)) is
quasi realizable, if at least one of its atomic forms obtained by decomposition, ends; i.e there is a
C ∈ decomp(workflow(s0,R), /0) such that realisable({s0},C) = (True, /0);
realizable, if all it’s atomic forms end; i.e. for all C ∈ decomp(workflow(s0,R), /0),
realisable({s0},C) = (True, /0).

Outline
Deﬁnitions and constraints
Playing a role
6 Conclusion

Actor, deﬁnition and constraints
An actor aτ is given by a couple (Rτ,Cτ), where Rτ is the set of potential roles that actor can
play, and Cτ is the set of constraints on those potential roles.
Let aτ = (Rτ,Cτ) an actor, ri and rj two roles; association between actor aτ and roles ri and rj is
materialized by ri ,rj ∈Rτ. We will say for instance that ri ,rj are actor’s aτ potential roles.
Four constraint values can be deﬁned on actor’s potential roles:
1 Dcr or nothing for no constraint;
2 Imp (ri ,rj ) indicating that if actor aτ plays role ri , then he must also play role rj ;
3 Eqv (ri ,rj ) in case both Imp (ri ,rj ) and Imp (rj ,ri ) holds;
4 Phb (ri ,rj ) and so, actor aτ playing role ri , cannot play role rj .

Actor playing a role
(a) Actor aτ playing two roles (b) Workﬂow simpliﬁed by the
direct product of R0 and R1
(c) An actor involved in two parallel
activities
(d) Several actors playing same role r2
in an activity

Consider three primitives
play aτ,{ri }1≤i≤|Rτ| ,activitys0
{cstrk }1≤k≤N
indicating that aτ potentially can play roles {ri }1≤i≤|Rτ| in
activity activitys0
, with constraints {cstrk }1≤k≤N ;
play (aτ,ri ,activitys0
)cstrk
to express that aτ potentially can play the roles ri in activity activitys0
,
according to the constraint cstrk , with
play aτ,{ri }1≤i≤|Rτ| ,activitys0
{cstrk }1≤k≤N
=
1≤i≤|Rτ|
)cstrk
play (aτ,Ri ,activitys0
) expressing that aτ actually plays the role ri whose interface is Ri , in activity
activitys0
"play" relationship
)Dcr = play (aτ,Ri ,activitys0
)
)Imp(ri ,rj ) = play (aτ,Ri ×Rj ,activitys0
)
)Eqv(ri ,rj ) = play (aτ,Ri ×Rj ,activitys0
)
or play (aτ,Rj ×Ri ,activitys0
)
)Phb(ri ,rj ) = play (aτ,Ri ,activitys0
)
and not play (aτ,Rj ,activitys0
)
(5)

Conclusion and perspectives
This work is a prelude to a role-based design approach, for distributed collaborative
systems.
An immediate continuation is to reconsider a more complex system, as co-creative and
innovative crowdsourcing systems,
i.e a context where there are no pre-established rules,
clarify conception of those type of processes, and describe interactions
between actors.

Thanks for your attention

Cari2020 Rodrigue Aimé Djeumen Djatcha

Recommended

Recommended

More Related Content

Similar to Cari2020 Rodrigue Aimé Djeumen Djatcha

Similar to Cari2020 Rodrigue Aimé Djeumen Djatcha (20)

More from Mokhtar SELLAMI

More from Mokhtar SELLAMI (15)

Recently uploaded

Recently uploaded (20)

Cari2020 Rodrigue Aimé Djeumen Djatcha