key: cord-0265068-4zn0rf68
authors: Dukes, Mark
title: Stakeholder utility measures for declarative processes and their use in process comparisons
date: 2022-02-07
journal: nan
DOI: 10.1109/tcss.2021.3092285
sha: e2684cf108811425417c54443dba8adb51a2cad0
doc_id: 265068
cord_uid: 4zn0rf68

We present a method for calculating and analyzing stakeholder utilities of processes that arise in, but are not limited to, the social sciences. These areas include business process analysis, healthcare workflow analysis and policy process analysis. This method is quite general and applicable to any situation in which declarative-type constraints of a modal and/or temporal nature play a part. A declarative process is a process in which activities may freely happen while respecting a set of constraints. For such a process, anything may happen so long as it is not explicitly forbidden. Declarative processes have been used and studied as models of business and healthcare workflows by several authors. In considering a declarative process as a model of some system it is natural to consider how the process behaves with respect to stakeholders. We derive a measure for stakeholder utility that can be applied in a very general setting. This derivation is achieved by listing a collection a properties which we argue such a stakeholder utility function ought to satisfy, and then using these to show a very specific form must hold for such a utility. The utility measure depends on the set of unique traces of the declarative process, and calculating this set requires a combinatorial analysis of the declarative graph that represents the process. This builds on previous work of the author wherein the combinatorial diversity metrics for declarative processes were derived for use in policy process analysis. The collection of stakeholder utilities can themselves then be used to form a metric with which we can compare different declarative processes to one another. These are illustrated using several examples of declarative processes that already exist in the literature.

We present a method for calculating and analyzing stakeholder utilities of processes that arise in, but are not limited to, the social sciences. These areas include business process analysis [18] , healthcare workflow analysis [3] , [10] , [13] and policy process analysis [11] , [1] , [6] , [7] . This method is quite general and applicable to any situation in which declarativetype constraints play a part. A declarative process D is a pair consisting of a set of activities, and a list of constraints detailing how these activities may happen in relation to one another. For such a process, anything may happen so long as it is not explicitly forbidden by the constraint set.

Declarative processes have been used as models of business and healthcare workflows by several authors [18] , [14] , [19] . The notion of a declarative process is an attractive one: simply IEEE declare the constraints on activities in a system and then let the system run or evolve according to these constraints. An execution of such a system is a (potentially infinite) listing of the activities in the order they occur, i.e. they satisfy all of the constraints that define the system. Such listings are called traces. Two immediate concerns arise: Is there a sensible way to quantify stakeholder satisfaction for such processes? Is there a sensible way to compare two processes with regard to stakeholder satisfaction? In this paper we will take a first look at answers to these questions. The work we present in this paper is new in that it does not necessarily build on any existing body of work in the literature. The closest work by other authors to what we are examining seems to be the topic of similarity measures for business process models [4] , [15] , [17] , however none of the material in those papers is necessarily applicable to the modelling framework that we are considering.

In considering a declarative process as a model of some system it is natural to consider how the process behaves with respect to stakeholders. Our previous paper [5] introduced several metrics related to the combinatorial diversity of a declarative process for use in policy process analysis. The purpose of that paper was to derive a metric that satisfied various properties and represented, to an extent, how 'free' a given declarative process was to happen. In this paper we have a different aim in mind. We will consider stakeholders in the declarative process and utilities for these stakeholders, and derive a measure for stakeholder utility. This is done by focusing on a class of representatives for a declarative process (the set of unique traces) and determining the solution to a collection of properties which we argue such a stakeholder utility function should satisfy. Calculating the set of unique traces requires a combinatorial analysis of the declarative graph that represents the declarative process. We then use these stakeholder utilities in order to give a method for comparing declarative processes. These are illustrated using several examples of declarative processes that already exist in the literature.

In Section 2 we introduce a declarative process and define the set of unique traces for a declarative process. In Section 3 we will present an algorithm for calculating the set of unique traces and discuss how this can be optimized. In Section 4 we consider stakeholders in a declarative process and suppose that each stakeholder will have a preference for or against each of the unique traces of the declarative process. We state and explain some reasonable properties that a utility function for a stakeholder should satisfy, and solving the equations that these properties imply gives an expression for the stakeholder utility function. We then illustrate these new concepts by ap-arXiv:2202.03520v1 [cs.AI] 7 Feb 2022 plying them to the Patient Handler declarative process. Three different versions of the Patient Handler declarative process (Examples 4.3 and 4.4) already appear in the literature. We calculate the stakeholder utility vector, the vector of all utility functions for a given process, for several examples and discuss the results. In Section 5 we use the stakeholder utility vector to give a method for comparing different declarative processes with respect to a prescribed set of stakeholder preferences. This method uses 2 -norm minimization but, as we show, is robust to 'noise' in the system. We illustrate this method by comparing three declarative processes in the paper. In Section 6 we conclude with a discussion of what we have shown.

Let us first introduce some standard notation and terminology related to declarative processes [18] , [5] . Let Σ be a set of activities and let Σ * be the set of all possible sequences that one can form whose entries are element of Σ. That is

where denotes the empty sequence. A trace is a sequence of activities σ = (e 1 , . . . , e n ) ∈ Σ * . An event is an occurrence of an activity in a trace.

A declarative constraint is a constraint on the activities in a process. We require a language through which to express temporal and modal aspects of these activities, and the natural choice for this is linear temporal logic [8] . Linear temporal logic (LTL) is an extension of propositional logic L P that includes temporal modal operators X or • (neXt), U (Until), F or (Finally), G or 2 (Globally), R (Release), W (Weak until) and M (strong release). As an example, given two activities a and b in Σ, we may wish to specify that event b must happen as a response to event a. In LTL one would represent this by the LTL formula G(a ⇒ Fb), which can be read as "it is globally true that (a occurs implies b occurs at some point after a)". However, the semantics of the Declare framework [16] , [19] are easier to grasp in this respect and uses resp(a, b) for G(a ⇒ Fb). A list of some popular Declare expressions along with their LTL equivalents is given in Figure 2 . For readability, in this paper we will consider the constraints as expressed in Declare.

We say that a trace σ satisfies the constraint resp(a, b) if any occurrence of a in the trace will feature an occurrence of b to its right. To represent this we write σ |= resp(a, b). It may be the case that a and b are not events in σ, in which case σ certainly satisfies the constraint resp(a, b). If Const is a set of constraints, then we will write σ |= Const if σ |= x for all x ∈ Const.

Let us consider the trace σ = (3, 3, 2, 4, 1, 4) with Σ = {1, 2, 3, 4, 5}. The trace σ satisfies the declarative constraint resp(2, 1), i.e. σ |= resp(2, 1) since event 1 happens after event 2 in σ. However, both σ |= resp(2, 3) and σ |= resp(2, 5) are false.

Definition 2.1. A declarative process is a process on a set of activities Σ that satisfies all conditions in a set Const of declarative constraints. We will represent this as a pair D = (Σ, Const). The set of traces of the process is

Restrictions on the beginning and ending of these processes may be incorporated into the constraint set using declarative constraints. (3, 5) , succ (1, 4) , notsucc(4, 2)}. Examples of traces for this process include , (2), (1, 2, 3, 5, 4) , (2, 2) , (2, 2, . . . , 2, 3), and (2, 2, . . .). There are will be an infinite number of traces, so |Traces(D)| = ∞.

How should one approach analysing declarative processes? In theory one could derive a measure from simply looking at the two constraint listings that define them. A difficulty with this approach is that there are many different types of relations that can link two activities. The interactions between these constraints are consequently far more involved than, say, those represented by directed edges in a graph and studying the resulting graph properties.

An alternative way to consider and analyse such systems is to study the set of traces, Traces(D), of the declarative process. A drawback to this is that such a set can be infinite as in Example 2.2. We might then consider finite versions of the process that contain only traces of finite length [12] , however the drawback in this case is more serious in that in the application areas we envisage, the occurrence of an activity (at some time perhaps far in the future) is more critical to our analysis than, say, a million occurrences of two activities up to the point of trace truncation.

This consideration leads us to considering traces in which an activity of Σ occurs at most once in a trace. In our first paper [5] on this subject we were able to justify this consideration as 'first passage/time traces'. No choice of projection from a set of infinite objects to a set of finite objects comes without a drawback. However we feel that the considerations of the application area combined with the notion of first passage times make this the best set of representatives for our consideration. We note that this could be specified at the constraint level by including into the set of constraints a declarative constraint on every activity that it can not happen more than once. An equivalent way to consider this is to simply look at the subset of traces that contain at most once occurrence of every event. 

Event a occurs at least once Fa initial(a) Event a is first to occur a resp(a, b)

If event a occurs, then event b occurs after a G(a ⇒ Fb) chainresp(a, b)

If event a occurs, then event b occurs G(a ⇒ Nb) immediately after a prec(a, b) Event b occurs only if preceded by event a (¬b)Wa succ(a, b) Event a occurs iff it is followed by event b G(a ⇒ Fb) ∧ ((¬b)Wa) not − coexist(a, b) Events a and b cannot coexist b ¬(Fa ⇔ Fb) Figure 3 . Illustration of the declarative process Patient Handler (that we will refer to as PH1) from [19] The set |Traces(D)| = ∞ while

Example 2.5 (After Dinner). The following is a description of the house rules for a child between the end of dinner and going to bed. After dinner is finished (and it must be finished) the table must be tidied. If they want to do a jigsaw that the table must have been tidied beforehand. The doing of a jigsaw means this jigsaw must be tidied away afterwards. The child can watch a bedtime television show only after finishing dinner. The child cannot get ready for bed before the jigsaw has been tidied away (in the event it needs to be). The child cannot get ready for bed before watching the bedtime show. The child cannot get ready for bed before tidying the table.

To model this as a declarative process, label the events as follows: The above description translates into the following constraint set (see Figure 2 for an illustration of the constraints):

succ (3, 4) , notsucc(6, 4), notsucc(6, 5), notsucc(6, 2)}. and to the declarative process D AD1 = ({1, 2, 3, 4, 5, 6}, Const AD1 ). As a declarative process, it is easy to see that Traces(D AD1 ) will have an infinite size. As a process, it is clear from the description that each of the activities is intended to happen at most once.

To analyse this declarative process, we are interested in UniqueTraces(D AD1 ), which is This set reveals that, through the rules the parents laid down, the child does not necessarily have to ever get ready for bed (as evidenced by eight traces that do not contain activity 6), and satisfies all the rules they must follow. If one now includes the rule that activity 6 must happen, i.e.

then one finds those traces that the parents intended in the first place: (1, 2, 5, 6) , (1, 5, 2, 6) , (1, 2, 3, 4, 6) , (1, 2, 3, 4, 5, 6) , (1, 2, 3, 5, 4, 6) , (1, 2, 5, 3, 4, 6),

(1, 5, 2, 3, 4, 6)}.

In order to generate the set of unique traces of a declarative process, we have to consider all events that can occur in such a trace. This can be any subset X of the set of activities Σ. We must then consider all the different permutations of events in X to see if such a sequence satisfies the set of constraints. Algorithm 1 gives a simple procedure for doing this.

for π ∈ Permutations(X) do 5: if π |= Const then 6:

The above algorithm will of course be dependent upon the size of Σ and the number of of times 'satisfies' is called will be 2.718|Σ|! For example, if Σ has 7 activities then 2.718|Σ|! = 2.718 × 7 × 6 × · · · × 1 = 13700. This fact will lead to an exponential slowdown for every extra activity that is considered in Σ. Consequently, the runtime on an average PC will increase from minutes to double digit-hours as |Σ| goes from 9 to 15.

We can remove needless checking by stripping a declarative process down to a smaller smaller core process. This is done by removing the equivalent of leaves from the constraint list (and by extension the activity set). For example, if we have a declarative process D = (Σ, Const) and the only appearance of activity j, say, in Const is as resp(i, j), then we can construct UniqueTraces(D) from UniqueTraces(D ) where D = (Σ\{j}, Const\{resp(i, j)} by using a simple resp leaf addition procedure as given in Algorithm 2.

This procedure is useful in that it allows us to consider decompose stakeholder satisfaction for the declarative process on a smaller process. If activity j features in G i for some stakeholder S i then it will be possible to re-specify G i on the smaller process while conditioning on the position/absence-of activity i in any traces. It also allows us to gain some insights into the distribution of activities within the set of unique traces. This information is useful in tracking the evolution of the unique traces and could be utilized in later work to provide bounds on certain aspects of the declarative process.

Algorithms 3 and 4 deal with the declarative constraints prec and succ, respectively. Similar algorithms can be given for other declarative constrains and these allow for the calculation Algorithm 2 Generating UniqueTraces(D) from UniqueTraces(D ) where j ∈ Σ and D contains the additional constraint resp(i, j)

for σ ∈ UniqueTraces(D ) do 4: if i ∈ σ then 5: for k ∈ {index(σ, i), . . . , length(σ)} do 6: µ ← σ with j inserted after the kth entry 7: if µ |= Const then 8:

for k ∈ {index(σ, i), . . . , length(σ)} do 12: µ ← σ with j inserted after the kth entry 13: if µ |= Const then 14: A ← A ∪ {µ} 15: return A of the unique traces of declarative processes of significantly larger size. We have calculated unique traces for declarative processes on 23 activities using these algorithms but have not yet had cause to consider larger systems. It is important to mention that declarative processes having the same number of activities will not necessarily have the same run-times. This is especially true when it comes to declarative constraints that are more involved. A time complexity study of different divideand-conquer approaches would be a welcome addition to this body of work.

Generating UniqueTraces(D) from UniqueTraces(D ) where j ∈ Σ and D contains the additional constraint prec(i, j)

µ ← σ with j inserted after the kth entry 8: if µ |= Const then 9:

A ← A ∪ {µ} 10: return A

To every declarative process D = (Σ, Const) we may consider a set of stake-holders S = S(D) := {S 1 , . . . , S m }. These stake-holders have an interest in aspects of the declarative process such as the execution order or existence of particular activities. As such there are some traces that are more desirable than others for these stakeholders.

For example, one stake-holder might prefer an execution of the declarative process wherein a particular activity happens (be it at the end of the process or at any stage of the process). Another preference might be that an activity a Algorithm 4 Generating UniqueTraces(D) from UniqueTraces(D ) where j ∈ Σ and D contains the additional constraint succ(i, j)

for σ ∈ UniqueTraces(D ) do 4: if i ∈ σ then 5: for k ∈ {index(σ, i), . . . , length(σ)} do 6: µ ← σ with j inserted after the kth entry 7: if µ |= Const then 8:

return A happens iff activity b happens afterwards. It might be the case that a stake-holder is happy with any one of a collection of activities happening, or is insistent that a particular collection of activities must all happen (at least at some point).

In stating preferences for stake-holders, we are not considering these preferences to have any dynamic implications on how the process unfolds. In this sense it is best to assume stakeholders preferences are private during the execution of such a process. Our measure will compare the number of outcomes of such a process to the number of outcomes that are preferable to a given stakeholder. We are therefore not trying to determine the best outcomes of such a process, but instead consider how well a process behaves in relation to stake-holder preferences.

A stake-holder preference will be represented by an LTL expression. We will denote the LTL expression that corresponds to a 'desirable/good' outcome for stakeholder S i by G i and define G = (G 1 , . . . , G m ). The declarative system along with the stake-holders and their (private) preferences is represented by a triple T = (D, S, G) that we will call a declarative stakeholder system. A more involved analysis might involve a partial ordering of preferred outcomes with scores assigned to each. In this paper we will restrict ourselves to a binary measure of whether a given trace is 'good' for a particular stake-holder. For stake-holder S i , let us define

This is the set of 'good' outcomes of the declarative process for S i .

We wish to associate a utility u i to stake-holder S i that represents their satisfaction with declarative stakeholder system T = (D, S, G). We make the following reasoned assumptions on u i (T ). Assumption 5 The utility should possess a scaling property so that a doubling of |UniqueTraces| does not mean that a doubling of |GoodTraces i (D)| is required to achieve the same utility. However, if one sets f (x, b) to simply be a function g(x/b) that is increasing, then we rule out being able to incorporate important aspects with relation to how such a utility should behave with respect to different scalings. In order to accommodate Assumption 5 let us assume f (x, b) = g(x)/g(b) for some function g(x). With regard to the properties of f outlined above, these imply that g(x) must satisfy the following:

The function g is not a direct measure of utility, but represents the weight attached to the number of desirable traces for stake-holder S i . Consider instances of GoodTraces i (D) that have 0, 1, 2, and 100, valid traces (this is similar to what was considered in [5] ). An empty GoodTraces i (D) indicates no desirable executions of the process for user S i . If GoodTraces i (D) consists of a single trace then it is better (for S i ) than the previous case of no traces. If GoodTraces i (D) consists of 2 traces then it is certainly better (for S i ) than a process that only has one trace. However, we would consider a set of preferred traces having 101 traces to be better, but only marginally, to a process that has 100 traces.

The simplest function that represents this situation is one that is inversely proportional to its argument, i.e. satisfies the differential equation g (x) = k 1 /(x + k 2 ). In order for the general solution to this, g(x) = k 1 ln(x + k 2 ) + c for constants k, c, to represent our situation we must have k 1 > 0. If there is no trace in the set of desirable outcomes, then we will have g(0) = k 1 ln(k 2 ) + c. In order for this to equal 0, we must have k 2 = 1 and c = 0 and this implies g(x) = k 1 ln(x + 1).

This now gives us the required expression for the utility function for stake-holder S i : 

Example 4.2 (After Dinner cont'd). Consider the two declarative processes D AD1 and D AD2 from Example 2.5. Suppose that the two stake-holders are S 1 , the child, and S 2 , the parents and S = {S 1 , S 2 }. We will consider some different forms for G 1 and G 2 and calculate their utility in order to see how the declarative processes compare for the stake-holders. Note that |UniqueTraces(D AD1 )| = 16 and |UniqueTraces(D AD2 )| = 8. Before doing this, let us reiterate a point made at the beginning of this section. In this study, once a preference for one stakeholder is stated, it is natural to assume that that stake-holder will engage in some activities to force a preferential outcome. This certainly might be the case and, in the case of two stake-holders having somewhat complementary preferences, it might be considered as a competition. Our purpose is not to study how effective such stake-holders are in forcing the outcome of a process. (A stake-holder might not be involved in the execution of a process or have any impact on the activities of that process.) Instead, our goal is to analyse how 'good' a declarative process is in relation to stated stake-holder preferences.

(i) On a given evening, the child has a desire to watch the bedtime show after dinner. The parents are interested in the child getting ready for bed. To assign LTL expressions to these events, we have G 1 = participation(5) and G 2 = participation(6).

Given these expressions, we find that there are 12 traces in UniqueTraces(D AD1 ) that contain activity 5, so |GoodTraces 1 (D AD1 )| = 12. There are 8 activities in UniqueTraces(D AD1 ) that contain activity 6, so |GoodTraces 2 (D AD1 )| = 6. These values allow us to calculate utilities for the declarative process AD1: Likewise, for the second declarative process D AD2 we find that |GoodTraces 1 (D AD2 )| = 6 and |GoodTraces 2 (D AD1 )| = 8, from which we calculate the utilities: The first stake-holders utility is better with process AD1 whereas the opposite is true for the second stake-holder. (ii) On a given evening, the child has a particular wish to do their jigsaw and then watch the bedtime show before tidying the jigsaw. The parents, for some reason or another, would rather that the child not watch television after dinner and before going to bed. The LTL expressions corresponding to these propositions are

There are 2 traces in UniqueTraces(D AD1 ) that satisfy G 1 and 4 traces in UniqueTraces(D AD1 ) that satisfy G 2 . There is a single trace in UniqueTraces(D AD2 ) that satisfies G 1 and 2 traces in UniqueTraces(D AD2 ) that satisfy G 2 . The utilities for the two different stake-holders for both declarative processes are now: For this choice of G , we see that both users would therefore have a preference for process AD1 over AD2. Discussion: In this example we have considered the two declarative processes D AD1 and D AD2 . We have seen how we can compare these two processes with respect to two different preferences for the two different stake-holders. There is no reason to limit the number of stake-holders to two. Our method shows that in one of these cases, the utilities calculated indicate a clear preference for one declarative process over another. For the other set of preferences, that is not the case. [19] that is illustrated in Figure 3 . This is a process for handling a patient at the first aid department in a hospital with a suspected arm fracture and comprises eight activities. The patient is initially examined by a medical professional (activity 1) and the init constraint on this activity means it is the first activity that occurs in any execution of this process. Activity 5 'medication' shares no constraints with any other processes, however the init constraint on activity 1 forbids activity 5 from occurring first. Two constraints warrant further explanation:

• The 1of4 constraint indicates that at least one of the four constraints 3,4,6,8 must happen. This constraint is not conditional on other constraints or activities, and so rules out the situation whereby activity 1 happens (patient examined) followed by them being given medication (activity 5) for what is a sore arm. We are not sure why this possibility was ruled out in the original model but will not alter it since it adds to the diversity of the underlying process. Furthermore, since we are dealing with representatives of traces, one could argue that this is represented by the trace (1, 5, 8) whereby the patient simply chooses not to wear a sling. • The 'optional response' from activity 3 to activity 7 is different to the normal response in that if activity 3 happens then 7 may or may not occur afterwards. However if activity 3 does not occur then activity 7 certainly cannot occur. Of course neither 3 nor 7 need occur and this constraint is still satisfied. The unique traces of the declarative process D P H1 are summarized in Figure 6 . Let us now consider some stakeholders in this process. Recall that stakeholders do not have to have an active role in a process but may have some clear preferences regarding observed executions of the process. Stakeholder S 1 The first stakeholder is the patient who is presenting to the emergency department. This patient has a phobia of surgery and is averse to medication. The LTL proposition that models the stakeholder's preferences is

Stakeholder S 2 The second stakeholder is the X-ray department who are overwhelmed by the number of X-rays that are needed. The LTL proposition that models the stakeholder's preferences is

Stakeholder S 3 The third stakeholder is the surgery department who have a very small team and do not have the resources to dedicate to removing casts before surgery. The LTL proposition that models the stakeholder's preferences is succ(3, 6) ).

Stakeholder S 4 The fourth stakeholder is the hospital itself. Resources are often scare and a patient who needs multiple resources can be costly (both in work and time) for the hospital. An avoidance of the overuse of multiple costly resources is preferred. An instance of this is a patient who is initially given a sling, their arm does not improve, and so an X-ray indicates a fixation is the best option. This fixation does not solve the problem and surgery is required, followed by rehabilitation. The hospital has noticed that in the past there have been several such 'expensive' instances among patients who have revisited multiple times. This process execution is represented by the unique trace σ = (1, 8, 2, 4, 3, 7) . The LTL proposition that models the stakeholder's preferences is (3, 7) ).

Stakeholder S 5 The fifth stakeholder is the pharmaceutical industry. In this instance it benefits when patients are prescribed medication or their medications are used during surgery. The LTL proposition that models the stakeholders preferences for this process is

Examining the traces in UniqueTraces(D P H1 ) with respect to the five stakeholders we find (GoodTraces 1 (D P H1 ) , . . . , GoodTraces 5 (D P H1 )) = (11, 3, 389, 452, 448) . . In this example we will consider a modified patient handler process that we call Patient Handler 2 and is motivated by an example given in Mertens et al. [14] . The process we look at is a simplified version of the one given in [14] since in that paper the authors introduced a more general declarative framework that captured aspects of a healthcare process that was not captured by the original declarative process given in [19] . The concerns of [14] are quite different to ours and our purpose in looking at that declarative process is to have a second process to compare the first process PH1 to.

With these points in mind we will describe two simplified versions of Patient Handler 2 that we will refer to as PH2a and PH2b. The difference between these two is that PH2b contains an additional activity (activity 11 in Figure 4 ) that does not feature in Patient Handler 1 but which we find interesting to include for comparison purposes.

In this modification of Patient Handler 1, we have attempted to preserve the labelling of similar activities. In Patient Handler 1 there was one activity (activity 5) for the patient being given medication. Patient Handler 2 considers a collection of different medications, and those medications that correspond to the old activity 5 have been labelled 51, 52, and 53 in order to provide a comparison between the two processes. Moreover, there are now activities for prescribing anti-inflammatory and anti-coagulation drugs after surgery. These did not feature in PH1. Information about the unique traces of the two processes D P H2a and D P H2b can be found in Figures 7 and  8 , respectively.

Let us consider stakeholders in these processes precisely as with did in PH1. As activity 11 (physiotherapy) does not impact on any of the preferences for the stakeholders S 1 , . . ., S 6 , we will assume that the expressions for stakeholder preferences for PH2a and PH2b are the same.

Stakeholder S 1 The patient who has a phobia of surgery and is averse to medication. The LTL proposition that models the stakeholder's preferences is now

∨ participation(52) ∨ participation(53) ∨ participation(9) ∨ participation (10)).

Stakeholder S 2 The overwhelmed X-ray department. The LTL proposition that models the stakeholder's preferences is the same as before

Stakeholder S 3 The under-staffed surgery department. The LTL proposition that models the stakeholder's preferences is the same as before (6)) succ(3, 6) ).

Stakeholder S 4 The hospital that would like to cut down on a particularly common overuse of its resources. The LTL proposition that models the stakeholder's preferences is the same: 7) ).

Stakeholder S 5 The pharmaceutical industry that benefits when patients are prescribed or given medications. The LTL proposition that models the stakeholder's preferences is

∨ participation(52) ∨ participation(53) ∨ participation(9) ∨ participation(10).

Examining the traces in UniqueTraces(D P H2a ) and UniqueTraces(D P H2b ) with respect to the five stakeholders we find (GoodTraces 1 (D P H2a ), . . . , GoodTraces 5 (D P H2a )) =(324, 1457048, 16316590, 16285678, 16316266) and (GoodTraces 1 (D P H2b ) , . . . , GoodTraces 5 (D P H2b )) = (1952, 16316590, 199143708, 198749700, 199141756) .

The collection of utilities for the declarative stakeholder system T P H2a = (D P H2a , S, G) is: 

The stakeholder utility vector of a declarative stakeholder system is a vector of values between 0 and 1 in which the ith entry represents the utility to user i. With the notation we have been using, we have the u(T ) = (u 1 (T ), . . . , u m (T )).

The optimal outcome for all stakeholders would be for u(T ) = (1, 1, . . . , 1). Given a collection of declarative processes D 1 , . . . , D t , in order to determine which declarative process is 'optimal' with respect to all stakeholders, one can simply determine the stakeholder utility vector that is closest to (1, 1, . . . , 1) in Euclidean m-space. This is done by using the Euclidean norm, also known as the 2 -norm, of a vector in m-space:

Using this we determine which declarative stakeholder system The minimum of these is H(T P H2b ) and so the declarative stakeholder system P H2b is the optimal choice from the set {P H1, P H2a, P H2b}.

The method of 2 -norm minimization is known to be sensitive to a moderate change in one of the values. In our setting this might amount to a single stakeholder's utility changing dramatically. In order to make our method more robust to such changes, we consider the optimal declarative processes for all possible subsets of stakeholders and make an informed decision from this based on what we observe.

Given a subset X = {i 1 , . . . , i k } of stakeholders S = (S 1 , . . . , S m ), let us consider the reduced stakeholder utility vector for those entries given in X:

For every such vector u (X) we will consider the declarative process that minimizes the 2 -norm from it to the best case utility (1, 1, . . . , 1) ∈ R |X| . The result will be a list of 2 |S| − 1 declarative processes. Let H (X) (T ) := u (X) (T ) − (1, 1, . . . , 1) 2 . We then use the information given in this list to determine the optimal choice of declarative process for all stakeholders.

Example 5.2. Let us consider PH1, PH2a and PH2b in Example 5.1. The table in Figure 5 records the reduced stakeholder utility vectors for all possible subsets of stakeholders. For each we record in the rightmost column the optimal choice of process.

• Of the 5 + 1 = 6 subsets X of S having size |X| ≥ |S| − 1 = 4, we see that the optimal choice is PH2b since it appears as the answer in 5 of the 6 cases. • Of the 10 + 5 + 1 = 16 subsets X of S having size |X| ≥ |S|/2 we see that the optimal choice is PH2b since it appears as the answer in 12 of the 16 cases. • Of the 2 5 −1 = 31 non-empty subsets X of S we see that the optimal choice of strategy is PH2b since it appears as the answer in 20 of the 31 cases. Each of these agrees with what we found in Example 5.1 when the subset of interest X is the set of all stakeholders S. There appears to be no clear reason to consider that either of the other processes could be optimal for this particular collection of stakeholders.

The previous example highlights the reasoning and analysis that allows us to conclude that a particular declarative process is the optimal one for particular set of stakeholders. The data in Table 5 might have been different and so to address this let us make the following comments in relation to what one should do in that event:

A. Choosing between optimal answers for X = S and X ⊂ S Let us suppose that the optimal choice in Figure 5 was not necessarily the same as the optimal choice for the other subsets of S that we considered. How should one go about deciding on an answer that can be considered robust? There are several things to consider in this setting. In the list below the word 'optimal' signifies it is optimal with respect to frequency. Suppose that • Process T all is optimal for X = S. • Process T almostall is optimal among {X : X ⊆ S with X = ∅ and |X| ≥ |S| − 1}.

• Process T morethanhalf is optimal among {X : X ⊆ S with X = ∅ and |X| ≥ |S|/2}.

• Process T any is optimal among

With these notions defined we can make the following observations.

1) If all = almostall then, in the absence of any other information, the optimal choice of declarative process is clearly D all . 2) If all = almostall then it would seem that the optimal choice of declarative process needs to be considered. If our motivation is to decide on a process that is strictly optimal for all stakeholders then D all is that process. However process D almostall could be considered as an alternative in the event that (a) the difference between H(T all ) and H(T almostall ) is very small and/or (b) if there is uncertainty about whether one of the stakeholders should be considered an active stakeholder at the time.

If almostall = morethanhalf then a stronger case could be made for choosing D almostall over D all , however if almostall = morethanhalf then we cannot make that case.

3) The process D any might seem an odd one to consider.

However it can come into play in the event that we do not know what collection of (declared) stakeholders are active stakeholders in some execution of a process. We end this section with a brief summary of the method:

To compare the declarative stakeholder systems T 1 = (D 1 , S, G), . . ., T n = (D n , S, G):

Step 1 We remind ourselves that due regard must be given to stakeholder preferences in light of different declarative systems (cf. expression G 1 for stakeholder S 1 in Patient Handler 2 to the G 1 in Patient Handler 1).

Step 2 Use Theorem 4.1 to calculate the stakeholder utility vectors u(T i ) = (u 1 (T i ), . . . , u m (T i )) for all n different declarative stakeholder systems.

Step 3 For each of the 2 m − 1 non-empty subsets X of {S 1 , . . . , S m }, Determine the j ∈ {1, . . . , n} that minimizes H (X) (T j ) and denote this index by Optimal(X).

Step 4 Given the collection of optimal answers {Optimal(X) : S ⊇ X = ∅}, analyse the four different answers (T all , T almostall , T morethanhalf , T any ) one gets from Section 1 in order to determine the optimal process for this collection of declarative stakeholder systems.

Subset H (X) (T P H1 ), H (X) (T P H2a ), H (X) (T P H2b ) 

In this paper we have presented a method for quantifying stakeholder utility for declarative processes. This method allows us to decide which of a collection of declarative processes is optimal in light of stakeholder preferences. As far as we are aware, there is currently no known method in the literature for performing this type of quantification and comparison.

Our method relies on constructing a set of representative traces for a declarative process followed by considering a function on subsets of these representatives that are deemed good with respect to stakeholder preferences. The assumptions we have used in this analysis are elementary and in subsequent work more general versions might be considered. For example, attributing values to traces for particular stakeholders that are different to the indicator function on traces used to determine membership of GoodTraces. Our technique will faithfully model declarative systems for which unique traces are good representatives, and we consider this to be the case with processes whose activities happen at most once during any execution. Many real life processes that one finds in the application areas of business process models, healthcare workflow analysis, and policy process analysis can be seen to be such systems. Again, in subsequent work it may well be worth considering allowing activities to happen, say, at most twice but such an allowance will naturally lead to further complexity in the calculations that are necessary.

A challenge in this analysis is constructing the set of unique traces of a declarative process. This challenging enumeration problem is a computationally demanding task since the more activities in a declarative process the more time and space this will take. However, this can be overcome in part by a combinatorial analysis of the declarative process graph as was evidenced by the discussion of the core of a declarative process in Section 3 along with the algorithmic considerations. The paper lays the foundation for further investigations into this area of declarative system analysis and provides the technical backdrop to new research into policy process analysis (see [2] 

A Declarative Model of the Policy Process

A declarative analysis of the Chinese Covid-19 emergency response

Testing Careflow Process Execution Conformance by Translating a Graphical Language to Computational Logic

Similarity of business process models: Metrics and evaluation

Combinatorial diversity metrics for declarative processes: an application to policy process analysis

Public Policy Modeling and Applications: state-of-the-art and perspectives

Modeling Complex Systems for Public Policies

Manydimensional modal logics: theory and applications

Declarative Event-Based Workflow as Distributed Dynamic Condition Response Graphs. PLACES 2010

Declarative Modelling and Safe Distribution of Healthcare Workflows

Studying Public Policy: Principles and Processes. Fourth Edition

LTLf satisfiability checking

Integrated Declarative Process and Decision Discovery of the Emergency Care Process

Enhancing Declarative Process Models with DMN Decision Logic

Similarity of Business Process Models -A State-of-the-Art Analysis

DECLARE: Full support for loosely-structured processes

Novel Parallel Business Process Similarity Methods Based on Weighted-Tree Declarative Pattern Models

Process Mining: Data Science in Action

Declarative workflows: Balancing between flexibility and support

Summary of the unique traces for Patient Handler D P H2a UniqueTraces(D P H2b )

Figure 8. Summary of the unique traces for Patient Handler D P H2b