Introduction

In the Business Process Mining community, many different languages have been proposed to model/describe a process, capturing the many aspects of a work process, ranging from the resource perspective, to the artifact-based and data perspective, up to the control-flow aspects. The latter viewpoint in particular has been subject to intense research activity. Two families of process modeling languages emerged: procedural approaches, such as BPMN 1 , and declarative ones, such as Declare [1,2] and DCR Graphs [3]. Declarative approaches have been introduced to overcome some forms of rigidness derived by procedural ones, with the aim of finding a balance between flexibility and control. Declare in particular, was defined with this aim: allowing the specification of which properties a process instance should exhibit, without specifying the exact steps to achieve them. Since the initial proposal, Declare has been equipped with a formal semantics based on a strict subset of LTL 𝑓 . This enables a straightforward specification of process properties through the use of established formulas.

However, the adoption of a logic-based semantics has also raised a practical issue when dealing with the problem of evaluating if a log is compliant with a process specification. On one side, a log is composed of many traces; on the other side a Declare process specification is composed of many constraints. Typically, in real-world applications, different subsets of traces are compliant with different subsets of constraints. The direct consequence is that a logic-crisp notion of compliance might be difficult or unsatisfactory to identify. In turn, such difficulty could undermine the capacity of a process specification to properly describe the process. In a seminal work [4], the authors tackled the problem by introducing the notion of probabilities into the Declare formalism: each constraint is assigned a probability (and a relational operator). A probabilistic constraint is satisfied over the log if the number of traces satisfying the constraint over the log cardinality achieves the mathematical relation established by the relational operator and the probability assigned. As a practical example, a constraint c 1 with assigned probability (0.9, ≥) is satisfied if the number of traces complaint with c 1 is at least (≥) the 90% of the total traces. In summary, probabilities express the relative frequency of traces, and are employed with such a meaning for the tasks of discovering, monitoring and conformance checking. Nonetheless, when the available log does not represent the whole process domain, the application of the approach [4] by domain expert might be challenging.

In this work, we also tackle the problem of probabilistic conformance checking with Declare constraints, but we propose a different semantics underlying the probabilistic constraints. We introduce the concept of Probabilistic Declarative Process Specification (PDS) starting from Probabilistic Logic Programming (PLP) and the Distribution Semantics [5]. A PLP program under that semantics defines a probability distribution over normal logic programs called worlds. In a PLP program, logic formulas are equipped with a probability, which is interpreted as the probability of them appearing or not in a normal logic program. Similarly, the probability of a Declare constraint is treated as the probability that such constraint will appear (or not) in a possible process specification. The presence or not of a constraint in a process specification tells us how "important" or strong that constraint is. The stronger or more important the constraint, the greater its probability. According to the our semantics, all worlds including one such constraint "inherit" its probability, while those not including the constraint take into account the complement to 1 of its probability. Differently from [4], this probability does not represent a fraction of traces satisfying the constraint, but allows one to model uncertainty in the domain by means of the probability attached to the constraint.

To better clarify our proposal, let us consider the following university course scenario, described with two constraints: (𝑎) it is mildly advised that a student only take the final examination if she has attended all the classes; (𝑏) it is strongly advised that a student attend a practical session only if she attended the corresponding preparatory class. Declare provides the way for expressing such constraints; however, there is no way to specify that rule (𝑎) is "mildly advised", while rule (𝑏) is "strongly advised". Our proposal consists of attaching probabilities to constraints (𝑎) and (𝑏): such values would indicate the probability that each rule would end up in a possible model (process specification), and the probability attached to (𝑏) would be higher than the one attached to (𝑎). By making (𝑎) and (𝑏) probabilistic, we would find four possible process models, and we can formally define the compliance of the students' careers (process traces) towards these four models (i.e., worlds in the Distribution Semantics terminology).

The contribution of this work is the following: we introduce a semantics for probabilistic declarative process specifications, provide a novel notion of compliance, and ground its application on a health protocol. Then, we exploit previous results, and in particular (𝑖) the mapping provided to Declare in terms of the SCIFF modeling language [6] and (𝑖𝑖) the extension of the Distribution Semantics to Abductive Logic Programming (ALP) in the SCIFF Framework [7]. Thanks to the existing work, we can implement our proposed semantics and compute a compliance probability. In order to evaluate the feasibility of our approach, we report some preliminary experimentation over the clinical guideline.

The paper is organized as follows: Section 2 introduces background on Declare and the distribution semantics, Section 3 describes the proposed semantics, Section 4 describes how we perform probabilistic compliance. Section 5 presents first experimental results and Section 6 concludes the paper.

Background

Traces, logs, and the Declare modeling language

In the BPM setting [8] the starting point is the observation of a process execution in terms of the execution of the activities that compose the process. Each execution of the process is usually referred to as a process instance or trace, where the executions of the distinct activities are referred to as distinct activity instances or activity executions. Each activity is characterized by at least a name, and each activity instance is usually denoted with a temporal timestamp. The timestamp provides, within the same trace, a relation order between the different activity executions: it is often the case that traces are represented directly as a sequence of activity names, ordered on the base of the timestamp. Depending on the specific context, the timestamp can be omitted: this is also our choice. Formally, we consider the existence of a finite alphabet of symbols Σ corresponding to the activity names. A trace and a log then are defined as follows:

Definition 1 (Trace 𝑡 and Log ℒ). Given a finite set Σ of symbols (i.e., activity names), a trace 𝑡 is a finite, ordered sequence of symbols over Σ, i.e. 𝑡 ∈ Σ * , where the latter is the infinite set of all the possible finite sentences over Σ. A log ℒ is a finite set of traces.

In a process log, each trace 𝑡 represents a different process instance. Different process instances may have the same trace, although referring to different executions.

Example 1.

Let us suppose that a process is made of activities a, b, c, and d. Σ = {a, b, c, d}. An example of a log might be:

ℒ = {𝑡 1 = ⟨a, b, c⟩, 𝑡 2 = ⟨a, b, a, d⟩, 𝑡 3 = ⟨a, a, d⟩, 𝑡 4 = ⟨a, b, c⟩, 𝑡 5 = ⟨a, b, c⟩}.

The Declare modeling language was initially introduced by [2] and subsequently studied in [9]. Aimed to overcome the "rigidness" of procedural modeling languages, it focuses on modeling processes by specifying what are the relevant properties that a process instance should exhibit, without specifying how these properties should be achieved. To this end, Declare models a process in terms of constraints, sort of rules about activities that can appear in a process execution (i.e., in a trace), with qualitative temporal relations among these activities. A simple example of a Declare constraint is response(a,b), meaning that every occurrence of (the execution of) activity a in a trace should be followed by the occurrence of an activity b.

Declare provides a finite set of constraint patterns, whose arguments should be properly instantiated with the activity names peculiar to the specific process to be modeled. For example, a common pattern is response(x,y) with x and y placeholders to be substituted with proper activities. Another pattern is init(x), that specifies that every process instance should always start with the execution of activity x. Another common pattern is precedence(x,y), that states that every occurrence of the execution of y should be preceded by the execution of x.

Declare provides a graphical representation for the patterns (see Figure 1 for a few examples), and has been equipped with two different formal semantics, both based on logic formalisms. In the original formulation in [2] the semantics was given using the LTL temporal logic; subsequent works have shown the feasibility of adopting the LTL 𝑓 logic [10]: for a recent recap see [11]. A second formal semantics has been proposed in [6], where the SCIFF language and ALP [12] has been exploited.

Both the semantics exploit the idea that each Declare template can be mapped onto one (or more) logic formula 𝜙, and that logical entailment can be used to define the notion of compliance/violation of a trace 𝑡 w.r.t. to a constraint formula 𝜙. With the aim of being the most general, we provide an intuitive definition of compliance/violation, where the meaning of the entailment symbol |= should be referred to the chosen semantics (LTL 𝑓 or ALP).

Definition 2 (Compliance/violation of a trace versus a constraint).

A trace 𝑡 is compliant with a Declare constraint if, named 𝜙 the corresponding logic formula modelling that constraint, it holds: 𝑡 |= 𝜙.

A trace 𝑡 violates a Declare constraint if it does not entail the corresponding formula 𝜙, i.e. if 𝑡 ̸ |= 𝜙.

Definition 3 (Declarative Process Specification, from [11]). A declarative process specification is a tuple DS=(Rep, Σ, 𝐶) where:

• Rep is a finite non-empty set of templates, where each template is a predicate c(𝑥 1 , . . . , 𝑥 𝑚 ) ∈ Rep on variables 𝑥 1 , . . . , 𝑥 𝑚 (with 𝑚 ∈ N the arity of c); • Σ is a finite non-empty set of activity names; • 𝐶 is a finite set of constraints, obtained by instantiating templates from Rep to Σ; we will compactly denote such constraints with c(𝑎 1 , . . . , 𝑎 𝑚 ), 𝑎 1 , . . . , 𝑎 𝑚 ∈ Σ.

Usually the constraints c(𝑎 1 , . . . , 𝑎 𝑚 ) in a DS are considered as being in logical conjunction. The notion of compliance can be then lifted from a trace vs. a constraint towards a trace vs. a DS as follows:

Definition 4 (Compliance of a trace versus a Declarative Process Specification). A trace is compliant with a DS if it entails the conjunction of the formulas 𝜙 𝑖 corresponding to the 𝑐 𝑖 ∈ 𝐶:

𝑡 |= 𝜙 1 ∧ . . . ∧ 𝜙 𝑚

where 𝑚 is the cardinality of 𝐶.

Example 2. Let us consider the log introduced in Example 1, and the following DS (Rep and Σ are omitted for the sake of simplicity):𝐶 = { c 1 = response(a,b) c 2 = init(a) }

Even without considering the corresponding formal semantics, we can notice that:

• 𝑡 1 , 𝑡 4 , and 𝑡 5 are compliant with c 1 ;

• 𝑡 2 is not compliant with c 1 because the second occurrence of activity a is not followed by an occurrence of activity b; • 𝑡 3 is not compliant with c 1 because two occurrences of a are not followed by an occurrence of b;

• 𝑡 1 , . . . , 𝑡 5 are all compliant with c 2 .

Distribution Semantics and Probabilistic Logic Programming

Probabilistic Logic Programming has recently received an increasing attention for its ability to incorporate probability in logic programming. Among various proposals for PLP, the one based on the distribution semantics [5] has gained popularity as being introduced for the PRISM language [5] but is the basis for many other languages such as Probabilistic Logic Programs [13], Probabilistic Horn Abduction (PHA) [14], Independent Choice Logic (ICL) [15], pD [16], Logic Programs with Annotated Disjunctions (LPADs) [17], ProbLog [18] and CP-logic [19]. Such semantics is particularly appealing for its intuitiveness and because efficient inference algorithms were proposed. By combining probability with logic programming, PLP languages are a suitable framework to handle uncertain information.

A program in one of these languages defines a probability distribution over normal logic programs called worlds. The distribution semantics has been defined both for programs that do not contain function symbols, and thus have a finite set of worlds, and for programs that contain them, that have an infinite set of worlds. We consider here the first case for the sake of simplicity, for the treatment of function symbols see [20]. A survey of the distribution semantics in PLP can be found in [21]. In the following, the distribution semantics will be described with reference to LPADs. Formally, an LPAD consists of a finite set of "annotated disjunctive clauses", where the head is a disjunction in which each atom is annotated with a probability. If the body holds true, only one of the atoms in the head will be true with the associated probability. 𝑝 𝑖𝑘 . We denote by 𝑔𝑟𝑜𝑢𝑛𝑑(𝑇 ) the grounding of an LPAD 𝑇 . An atomic choice [15] is a triple (𝑅 𝑖 , 𝜃 𝑗 , 𝑘) where 𝑅 𝑖 ∈ 𝑇 , 𝜃 𝑗 is a substitution that grounds 𝑅 𝑖 and 𝑘 ∈ {1, . . . , 𝑛 𝑖 } identifies one of the head atoms. (𝑅 𝑖 , 𝜃 𝑗 , 𝑘) means that, for the ground clause 𝑅 𝑖 𝜃 𝑗 , the head ℎ 𝑖𝑘 was chosen. A set of atomic choices 𝜅 is consistent if only one head is selected from the same ground clause; we assume independence between the different choices. A composite choice 𝜅 is a consistent set of atomic choices [15]. The probability 𝑃 (𝜅) of a composite choice 𝜅 is the product of the probabilities of the independent atomic choices, i.e. 𝑃 (𝜅) = ∏︀ (𝑅 𝑖 ,𝜃 𝑗 ,𝑘)∈𝜅 𝑝 𝑖𝑘 . A selection 𝜎 is a composite choice that, for each clause 𝑅 𝑖 𝜃 𝑗 in 𝑔𝑟𝑜𝑢𝑛𝑑(𝑇 ), contains an atomic choice (𝑅 𝑖 , 𝜃 𝑗 , 𝑘). If somebody has the flu or hay fever, there is the possibility that he experiences sneezing symptoms with different intensity: if she has the flu, then she might show strong sneezing with probability 0.3, or moderate sneezing with probability 0.5; similarly for the second clause. She might not experience any symptom with probability 0.2 in both cases. We know for sure that Bob has both the flu and hay fever. 𝑇 has 3 • 3 = 9 worlds, as each probabilistic clause has one grounding 𝜃 1 = {𝑋/𝑏𝑜𝑏}. Worlds are shown in Table 1. Given a goal G, its probability 𝑃 (𝐺) can be defined by marginalizing the joint probability of the goal and the worlds:

𝑃 (𝐺) = ∑︁ 𝑤∈𝑊 𝑇 𝑃 (𝐺, 𝑤) = ∑︁ 𝑤∈𝑊 𝑇 𝑃 (𝐺|𝑤)𝑃 (𝑤) = ∑︁ 𝑤∈𝑊 𝑇 :𝑤|=𝐺 𝑃 (𝑤)(1)

The probability of a goal 𝐺 given a world 𝑤 is 𝑃 (𝐺|𝑤) = 1 if 𝑤 |= 𝐺 and 0 otherwise. 𝑃 (𝑤) = 𝑃 (𝑤 𝜎 ) = 𝑃 (𝜎), i.e. is the product of the annotations 𝑝 𝑖𝑘 of the atoms selected in 𝜎. Therefore, the probability of a goal G can be computed by summing the probability of the worlds where the goal is true. In practice, given a goal to solve, it is unfeasible to enumerate all the worlds where 𝐺 is entailed. Inference algorithms, instead, find explanations for a goal: a composite choice 𝜅 is an explanation for 𝐺 if 𝐺 is entailed by every world of 𝑤 𝜅 . In particular, algorithms find a covering set of explanations w.r.t. 𝐺, where a set of composite choices 𝐾 is covering with respect to 𝐺 if every program 𝑤 𝜎 ∈ 𝑊 𝑇 in which 𝐺 is entailed is in 𝑤 𝐾 .

Probabilistic Declarative Process Specifications under the Distribution semantics

In this Section, we propose a semantics for Declarative Process Specifications that is highly inspired by the Distribution Semantics introduced in Section 2.2. First of all, we introduce the notion of probabilistic constraint. Please note that also in Definition 8 of [4] it is adopted the term probabilistic constraint, but that definition includes also a relational operator that we do not need in our semantics.

𝑝 𝑖 :: c 𝑖 (𝑎 1 , . . . , 𝑎 𝑚 )

The probability is to be interpreted as the strength or importance of c 𝑖 . The stronger or more important the constraint, the greater its probability. By applying the Distribution Semantics, a constraint c 𝑖 (. . .) will have a probability 𝑝 𝑖 of being part of a Probabilistic Declarative Process Specification, defined as follows:

Definition 6 (Probabilistic Declarative Process Specification). A Probabilistic Declarative Process Specification PDS is a Declarative Process Specification DS where each constraint c 𝑖 ∈ 𝐷𝑆 is a probabilistic constraint.

We will refer to constraints annotated with probability 𝑝 𝑖 = 1 as crisp constraints. If all the constraints have probability equal to 1, we simply end up having a Declarative Specification as in Def. 3. Probabilities will be omitted when they are equal to 1. We now propose to interpret the probability 𝑝 𝑖 of a constraint borrowing a few concepts from Section 2.2. Definition 7 (Atomic Choice, and its probability). An atomic choice over a probabilistic constraint 𝑝 𝑖 :: c 𝑖 is a couple (c 𝑖 , 𝑒) where 𝑒 ∈ {0, 1}. 𝑒 indicates whether c 𝑖 is chosen to be included in a PDS with probability 𝑝 𝑖 (e = 1), or not with probability 1 − 𝑝 𝑖 (e = 0).

Note that here we do not need the substitution 𝜃 as in the definition of atomic choice in subsection 2.2, since, according to Def. 5, the constraint c 𝑖 is ground.

Definition 8 (Composite Choice, and its probability). A set of atomic choices 𝜅 is consistent if there is only one choice in 𝜅 for each probabilistic constraint c 𝑖 ; we assume independence between the different atomic choices. A composite choice 𝜅 is a consistent set of atomic choices.

The probability 𝑃 (𝜅) of a composite choice 𝜅 is 𝑃 (𝜅) = ∏︀ (c 𝑖 ,1)∈𝜅 𝑝 𝑖 ∏︀ (c 𝑖 ,0)∈𝜅 (1 − 𝑝 𝑖 ), where 𝑝 𝑖 is the probability associated with c 𝑖 . Definition 9 (Selection 𝜎 over a PDS, and its probability). A selection 𝜎 over a Probabilistic Declarative Process Specification is a composite choice that contains an atomic choice (c 𝑖 , 𝑒) for every probabilistic constraint of the PDS. A selection 𝜎 identifies a world in this way:

𝑤 𝜎 = {c 𝑖 |(c 𝑖 , 1) ∈ 𝜎}. The probability of a world 𝑤 𝜎 is 𝑃 (𝑤 𝜎 ) = 𝑃 (𝜎) = ∏︀ (c 𝑖 ,1)∈𝜎 𝑝 𝑖 ∏︀ (c 𝑖 ,0)∈𝜎 (1 − 𝑝 𝑖 ).

Definition 10 (Probability of a DS). Given the set of all selections 𝑆 𝑇 over a Probabilistic Declarative Process Specification, every world 𝑤 𝜎 𝑖 identified by a selection 𝜎 𝑖 ∈ 𝑆 𝑇 is a different Declarative Process Specification 𝐷𝑆 𝑖 , and its probability is 𝑃 (𝐷𝑆 𝑖 ) = 𝑃 (𝑤 𝜎 𝑖 ) = 𝑃 (𝜎 𝑖 ).

A PDS defines a probability distribution over regular (non-probabilistic) DSs that correspond to worlds. Let us consider the following example to better illustrate this concept. The probability of c 1 indicates that the constraint response(a,b) is considered very strong therefore, the more traces satisfy it, the better. The probability of c 2 indicates that the fact that a trace starts with the execution of activity a is rather important, but less than the fact that a is followed by b. For each constraint there are 2 different choices, and this leads to 4 selections and 4 possible worlds; in turn, 4 different regular DS are possible, each one corresponding to a world:

Selection DS 𝑃 (𝐷𝑆 𝑖 ) 𝜎 1 = {(𝑘 1 , 1), (𝑘 2 , 1)} 𝐷𝑆 1 = {response(a,b), init(a)} 𝑃 (𝐷𝑆 1 ) = 0.9 × 0.8 = 0.72 𝜎 2 = {(𝑘 1 , 1), (𝑘 2 , 0)} 𝐷𝑆 2 = {response(a,b)} 𝑃 (𝐷𝑆 2 ) = 0.9 × 0.2 = 0.18 𝜎 3 = {(𝑘 1 , 0), (𝑘 2 , 1)} 𝐷𝑆 3 = {init(a)} 𝑃 (𝐷𝑆 3 ) = 0.1 × 0.8 = 0.08 𝜎 4 = {(𝑘 1 , 0), (𝑘 2 , 0)} 𝐷𝑆 4 = { } 𝑃 (𝐷𝑆 4 ) = 0.1 × 0.2 = 0.02

Example 4 allows us to highlight some characteristics of the semantics proposed in this paper. First of all, we might notice that, thanks to the notion of world, we started from a probabilistic declarative specification, and ended up with a set of non-probabilistic declarative specifications. Secondly, we might notice that each different 𝐷𝑆 𝑖 has its own probability (i.e., the one obtained by the corresponding selection 𝜎 𝑖 ), and that the set of all the possible selections achieves a probability distribution over DSs, i.e.

∑︀ 𝑖 𝑃 (𝐷𝑆 𝑖 ) = 1.

Probabilistic Compliance

In this Section we will define the notion of compliance of a trace w.r.t. a Probabilistic Declarative Process Specification PDS. In doing so, we will heavily rely on the simpler notion of compliance of a trace vs. a DS as in Definition 4. Note that in turn Def. 4 builds upon Def. 2, that abstracts away from the formal Declare semantics (𝐿𝑇 𝐿 𝑓 or ALP). As a consequence, our definition of compliance towards a probabilistic specification is general, and is valid for both 𝐿𝑇 𝐿 𝑓 and ALP. Obviously, in order to compute the compliance, one semantics should be chosen: we will discuss such a choice and the implementation in the next Section.

Definition 11 (Compliance of a trace versus a PDS). Given a a Probabilistic Declarative Process Specification PDS, let us consider all the possible selections 𝜎 𝑖 over PDS, and all the possible Declarative Specification

𝐷𝑆 𝑖 associated with 𝜎 𝑖 . A trace 𝑡 has a probability of compliance w.r.t. a PDS defined as follows:

𝑐𝑜𝑚𝑝(𝑡, 𝑃 𝐷𝑆) = ∑︁ 𝜎 𝑖 : 𝑡 is compliant with 𝐷𝑆 𝑖 𝑃 (𝐷𝑆 𝑖 )(2)

We might observe that, w.r.t. Def. 4, we move forward from a crisp boolean concept towards a degree of compliance: this is an expected consequence of introducing probabilities in the specification. Then, we might notice that the formula above indeed is simply an application of Equation 1 to the process specification domain. Let us apply the notion of compliance of a trace vs. a PDS by considering the following example:

Example 5 (continued from Ex. 4). Consider the PDS of Ex. 4 and the trace 𝑡 1 = ⟨a, b, c⟩: 𝑡 1 is compliant with all 4 𝐷𝑆 𝑖 and, as expected, its probability of compliance is: 𝑐𝑜𝑚𝑝(𝑡 1 , 𝑃 𝐷𝑆) = 𝑃 (𝐷𝑆 1 ) + 𝑃 (𝐷𝑆 2 ) + 𝑃 (𝐷𝑆 3 ) + 𝑃 (𝐷𝑆 4 ) = 0.72 + 0.18 + 0.08 + 0.02 = 1

Let us consider then a trace 𝑡 2 = ⟨c, a, b⟩ and suppose temporarily that c 1 and c 2 are crisp constraints: 𝑡 2 is compliant with c 1 since after a there is b; however it is not compliant with c 2 since 𝑡 2 does not start with a. By considering again the constraint as probabilistic, out of the four declarative specifications 𝐷𝑆 𝑖 , 𝑡 2 is compliant with 𝐷𝑆 2 and 𝐷𝑆 4 , i.e. those specifications that do not contain c 2 . 𝑡 2 probability of compliance is:

𝑐𝑜𝑚𝑝(𝑡 2 , 𝑃 𝐷𝑆) = 𝑃 (𝐷𝑆 2 ) + 𝑃 (𝐷𝑆 4 ) = 0.18 + 0.02 = 0.2 By violating c 2 , which was a rather important constraint as indicated by a probability value of 0.8, the trace has a low degree of compliance vs. the PDS.

Finally, let us consider the trace 𝑡 3 = ⟨c, a⟩. 𝑡 3 is not compliant with c 1 nor with c 2 , considered individually, however it is compliant with the empty specification 𝐷𝑆 4 , so its probability of compliance is not zero but is equal to 𝑃 (𝐷𝑆 4 ) = 0.02.

Example 5 illustrates the intuition behind the idea, proposed in this work, of interpreting the probability of a constraint as its strength or, in other words, how much important it is to satisfy such constraint. In the aforementioned example, trace 𝑡 1 is compliant with both the constraints, hence its degree of compliance is the maximum possible. Trace 𝑡 2 instead is compliant with only one of the two constraints, hence its degree is lower in relation to the strength/importance we have associated to the violated constraint. We might finally notice that trace 𝑡 3 , even if it does not comply with any constraints, still achieves a score. This is a direct consequence of the interpretation of the probability of a constraint as its strength: if the strength 𝑝 𝑖 is lower than 1, then we are saying that we will admit non-compliant traces with a degree (1 − 𝑝 𝑖 ).

In more formal terms, if all the constraints in a PDS have the attached probabilities 𝑝 𝑖 < 1, then there is always a selection 𝜎 * corresponding to including no constraint in the 𝐷𝑆 * (the empty specification), and whose probability is 𝑃 (𝜎 * ) > 0. In Example 4, such a special selection is 𝜎 4 . Every possible trace will be always compliant with 𝐷𝑆 * , since it's empty. Similarly, all the constraints annotated with probability 𝑝 𝑖 = 1 will appear in all the corresponding non-probabilistic DS, as shown in the following example: Example 6. Let us consider the following PDS:

𝐶 = { 0.8 :: response(a,b) (c 1 ) init(a) (c 2 ) }

The corresponding selections and specifications would be:

Selection DS 𝑃 (𝐷𝑆 𝑖 ) 𝜎 1 = {(c 1 , 1)} 𝐷𝑆 1 = {response(a,b), init(a)} 𝑃 (𝐷𝑆 1 ) = 0.8 𝜎 2 = {(c 1 , 0)} 𝐷𝑆 2 = {init(a)} 𝑃 (𝐷𝑆 2 ) = 0.2

Example 6 clearly illustrates how our proposed semantics for PDS accommodates for both probabilistic and non-probabilistic constraints: the latter are treated as mandatory constraints as usual in Process Mining, and the derived specifications 𝐷𝑆 𝑖 will always contain them.

Implementation and Evaluation

For computing the probabilistic compliance of a trace vs a PDS we leveraged on the implementation presented in [22]. This implementation supports reasoning on ALP programs featuring "integrity constraints" similar to those offered by IFF [23], extended with the possibility of annotating them with a probability value. The semantics of these programs, called IFF Prob programs, defines a probability distribution over IFF programs inspired by the distribution semantics, so the IFF Prob implementation could be directly used for our goals. IFF Prob is based on the implementation of the SCIFF proof-procedure. SCIFF [12] is an extension of the IFF proof procedure that also features constraints (à la CLP) and universally quantified abducibles. In [22], the IFF sub-language is extended to the probabilistic case with a new CHR constraint that represents the current explanation (𝑒𝑥𝑝𝑙, 𝑃 ) meaning that, in the current derivation branch, the explanation is 𝑒𝑥𝑝𝑙 and has probability 𝑃 . 𝐸𝑥𝑝𝑙 is a collection of couples (c 𝑖 , 𝑒), holding the constraint c 𝑖 and the Boolean value 𝑒 indicating whether c 1 belongs to 𝑒𝑥𝑝𝑙 or not.

In [9] declare constraints were mapped into a rule-based language known as CLIMB (Computational Logic for the verIfication and Modeling of Business constraints), a specialized subset of the SCIFF language that is based on abductive semantics. This mapping allows declarative models to be converted into sets of executable, logic-based rules. These rules are referred to as integrity constraints since they constrain the courses of interaction to ensure their integrity and compliance with interaction protocols. Each atomic Declare activity can be expressed in CLIMB as a term and is linked to a single time point, allowing its execution to be represented as either happened (H), expected (E), or forbidden. For example, the fact that an atomic activity 𝑎 has happened at time 𝑇 can be denoted by 𝐻(exec(𝑎), 𝑇 ), while 𝐸(exec(𝑎), 𝑇 ) states that 𝑎 is expected to occur at time 𝑇 . We do not consider here forbidden activities. Integrity constraints are of the form 𝐵𝑜𝑑𝑦 → 𝐻𝑒𝑎𝑑, where 𝐵𝑜𝑑𝑦 contains (a conjunction of) happened events, together with constraints on their variables, as well as Prolog predicates; 𝐻𝑒𝑎𝑑 contains (a disjunction of conjunctions of) positive and negative expectations, together with constraints and Prolog predicates, applied on their variables and/or on variables contained in the 𝐵𝑜𝑑𝑦.

We created a Declare process model for elective colorectal surgery based on the ERAS ® (Enhanced Recovery After Surgery) Society guidelines for perioperative care [24], as shown in Figure 2. The model is a PDS written in the CLIMB language, where the protocol activities are subject to both crisp and probabilistic constraints: the former represent strongly recommended practices according to the guidelines, reflecting critical, evidence-supported activities that must be adhered to rigorously, while the latter represent weakly recommended practices, whose associated probability states the importance to apply them in the healthcare flow. Weakly recommended practices may have some degree of flexibility in their implementation due to individual patient needs, local variations in resources and demographics, advancements in medical research, institutional policies, and cultural considerations. The model includes 21 constraints capturing essential perioperative events, from patient admission to post-surgery recovery. Of these, 14 constraints were identified as crisp (𝑝 𝑖 = 1) and 7 as probabilistic. An excerpt of the PDS is: true → 𝐸(exec(program_admission), 0).

( Here, the integrity constraint 𝑐 1 represents the init constraint. It specifies that the process must always start with the event program admission of the patient, occurring at time 0. Obviously, it is a mandatory constraint. Constraint 𝑐 2 represents the response constraint, indicating that whenever the event program admission happens, the pre-operative patient counseling and education must eventually follow at a time T2 later than T1. It's strongly recommended to begin patient counseling after admission into the program and prior to surgical procedures, thus constraints 𝑐 2 and 𝑐 3 are treated as crisp. Instead, 𝑐 4 and 𝑐 5 are modeled as probabilistic precedence constraints since, in the guidelines, preanesthesia and fasting before surgery could sometimes be skipped. The relatively low probability assigned to them derives from the consensus around those specific perioperative practices, suggesting they are generally not enforced for optimal postoperative outcomes. Each event trace was then adapted to the format required by the algorithm, transforming each trace into an interpretation. Every fact has two arguments: the first one is a ground term that records the event name, and the second one is an integer that indicates the timestamp. An example of an interpretation is the following: ℎ𝑎𝑝(𝑒𝑥𝑒𝑐(𝑝𝑟𝑜𝑔𝑟𝑎𝑚_𝑎𝑑𝑚𝑖𝑠𝑠𝑖𝑜𝑛), 0). ℎ𝑎𝑝(𝑒𝑥𝑒𝑐(𝑐𝑜𝑢𝑛𝑠𝑒𝑙𝑖𝑛𝑔), 5). ℎ𝑎𝑝(𝑒𝑥𝑒𝑐(𝑓 𝑎𝑠𝑡𝑖𝑛𝑔), 80).

To perform our experiments we wrote one synthetic trace composed of 21 events, one for each activity of the protocol. The process trace satisfied all the model constraints.

We provide two preliminary scalability tests in order to show how both crisp and probabilistic constraints influence the execution time in computing the probability of compliance of that trace. Experiments were carried out on a Linux machine with Intel ® Xeon ® E5-2630v3 running at 2.40 GHz with 20 GB of RAM and a time limit of 8 hours. In the first test, the number of crisp constraints was kept fixed respectively to 3, 6, 9, and 14 and the number of probabilistic constraints was increased from 1 to 7 at steps of 1. In the second test, the number of probabilistic constraints was kept fixed at 2, 4, and 7 and the number of crisp constraints was increased from 1 to 14 at steps of 1. , showing an exponential trend in execution times as the number of either crisp or probabilistic constraints increases. The impact on the time is higher when using probabilistic constraints: we obtain an exponential trend with 7 probabilistic constraints compared to 14 crisp ones.

Conclusions and Future Work

In this paper, we presented a new semantics for Declare process model specifications which allows one to specify probabilistic constraints representing their strength/importance in a specific process domain. In this way, we can model domains where some constraints are stronger (or weaker) than others. Such models are called Probabilistic Declarative Process Specifications. The underlying semantics is inspired by the distribution semantics from Probabilistic Logic Programming, and abstracts away from the formal Declare semantics (LTL 𝑓 or ALP), aiming at computing the probability of compliance of a trace versus the model. The computation of the compliance relies on an existing algorithm. Preliminary tests show that the time taken for computing the probability has an exponential trend by increasing the number of both crisp and probabilistic constraints. Future work includes: extending experimental evaluation, defining the compliance of a set of traces (log) vs. a PDS; extending the new semantics to manage uncertainty at the level of events, traces or the log itself; studying the profiles of energy consumption when computing the probability of compliance.