Resolving inconsistencies and redundancies in declarative process models

Declarative process models deﬁne the behaviour of business processes as a set of constraints. Declarative process discovery aims at inferring such constraints from event logs. Existing discovery techniques verify the satisfaction of candidate constraints over the log, but completely neglect their interactions. As a result, the inferred constraints can be mutually contradicting and their interplay may lead to an inconsistent process model that does not accept any trace. In such a case, the output turns out to be unusable for enactment, simulation or veriﬁcation purposes. In addition, the discovered model contains, in general, redundancies that are due to complex interactions of several constraints and that cannot be cured us-ing existing pruning approaches. We address these problems by proposing a technique that automatically resolves conﬂicts within the discovered models and is more powerful than existing pruning techniques to eliminate redundancies. First, we formally deﬁne the problems of constraint redundancy and conﬂict resolution. Second, we introduce techniques based on the notion of automata-product monoid, which guarantees the consistency of the discovered models and, at the same time, keeps the most interesting constraints in the pruned set. The level of interestingness is dictated by user-speciﬁed prioritisation criteria. We evaluate the devised techniques on a set of real-world event logs.


Introduction
The automated discovery of processes is the branch of the process mining discipline that aims at constructing a process model on the basis of the information reported in event data.The underlying assumption is that the recorded events indicate the sequential execution of the to-be-discovered process activities.The compact and correct representation of the behaviour observed in event data is one of the major concerns of process mining.Process discovery algorithms are classified according to the type of process model that they return, i.e., either procedural or declarative.Procedural process discovery techniques return models that explicitly describe all the possible executions allowed by the process from the beginning to the end.The output of declarative process discovery algorithms consists of a set of constraints, which exert conditions on the enactment of the process activities.The possible exe-cutions are implicitly established as all those ones that respect the given constraints.Mutual strengths and weaknesses of declarative and procedural models are discussed in [1,2] .
One of the advantages of procedural models such as Petri nets is the rich set of formal analysis techniques available.These techniques can, for instance, identify redundancy in terms of implicit places or inconsistencies like deadlocks [3] .In turn, similar facilities are not provided for novel declarative modelling languages like Declare .This is a problem for several reasons.First, we are currently not able to check the consistency of a generated constraint set.Many algorithms that generate Declare models include in the output those constraints that are individually satisfied in the log in more than a given number of cases.The interaction of returned constraints is thereby neglected, with the consequence that subsets of constraints can end up contradicting one another.Second, it is currently unclear whether a given constraint set is free of redundancies.Since there are constraint types that imply one another, it is possible that the generated constraint sets are partially redundant.The lack of formal techniques for handling these two issues is unsatisfactory from both a research and a practical angle.This is also a roadblock for conducting fair comparisons in user experiments when a Petri net without deadlocks and implicit places is compared with a constraint set of unknown consistency and redundancy-freedom.
In this paper, we address the need for formal analysis of Declare models.We define the notion of an automata-product monoid as a formal notion for analysing consistency and local minimality, which is grounded in automata multiplication.Based on this structure, we devise efficient analysis techniques.Our formal concepts have been implemented as part of a process mining tool that we use for our evaluation.By analysing event log benchmarks, we are able to show that inconsistencies and redundancies occur in process models automatically discovered by state-of-the-art tools.First, our technique can take such process models as input and return constraints sets that are consistent.To this end, contradictory subsets are identified and resolved by removing the constraints generating the conflict.Second, our technique eliminates those constraints that do not restrict the behaviour of the process any further, i.e., that do not convey any meaningful information to the output.As a consequence, the returned sets are substantially smaller than the ones provided by prior algorithms, though keeping the expressed behaviour equivalent to the inconsistency-free process.This paper extends the research presented in our former publication [4] with a complete and self-consistent definition of the adopted formal concepts and algorithms.We also provide alternative strategies to be utilised during the redundancy and consistency check, so as to allow for different criteria to prioritise the constraints during the pruning phase.This is of crucial importance, since manipulating a declarative process model towards removal of inconsistencies and redundancies is intrinsically expensive from a computational point of view.Furthermore, we introduce a complementary technique to further reduce the number of redundancies in the models after the first check.Finally, we broadly extend the evaluation with an analysis of our implemented approach over real-world data sets including the event logs provided for the former editions of the BPI challenge.
The paper is structured as follows.Section 2 illustrates intuitively the problems that we tackle with the proposed research work.Section 3 describes the preliminary notions needed to formally contextualise the challenged issues.Section 4 formally specifies the problems of inconsistencies and redundancies in detail.Section 5 defines our formal notion of automata-product monoid, which offers the basis to formalise the techniques for consistency and redundancy checking.Section 6 illustrates the results of our evaluations based on real-world benchmarking data.Section 7 discusses our contributions in the light of related work.Finally, Section 8 concludes the paper.

Motivation
Declarative process models consist of sets of constraints exerted on tasks, which define the rules to be respected during the process execution.A well-established language for modelling declarative processes is Declare [5,6] .Declare defines a set of default templates , which are behavioural rules that refer to parameters in order to abstract from tasks.In Declare , e.g., Init ( x ) is a template imposing that a given parametric task x must be the one with which every process instance starts.End ( x ) specifies that every process instance must terminate with the given task x .Response ( x , y ) states that if task x is carried out, then task y must be eventually executed afterwards.Precedence ( x , y ) imposes that y can only be performed if x has been previously executed.
Let us consider a simple example process having three tasks, a , b , and c .By indicating the execution sequence of tasks with their name, possible enactments that fulfil a process model consisting of Init (a ) and End (c ) are: ( i ) abababc , and ( ii ) ababac .If we consider an event log made of the aforementioned execution sequences and use any declarative discovery algorithm to reveal a declarative pro-cess model that could have generated them, it would correctly return a set of constraints including Init (a ) and End (c ) because they are always satisfied.However, the set of constraints would include also (1) Precedence (a , b ) and ( 2) Precedence (a , c ) , as well as (3) Response (a , c ) and ( 4) Response (b , c ) : those four constraints hold true in the event log as well.Nevertheless, if a is already bound to be the first task to be carried out in every process instance ( Init (a ) ), clearly no other task can be executed if a is not done before.Therefore, the first two constraints can be trivially deduced by Init (a ) .They add no information, yet they contribute to uselessly enlarge the set of constraints returned to the user as the outcome of the discovery.By the same line of reasoning, the third and fourth constraints are superfluous with respect to End (b ) .Intuitively, this example outlines the problem of redundancy , which is one of the two challenges that we tackle with this research work: the objective is to remove from the set of constraints in the discovered process model those ones that do not add information, i.e., that are not restricting the process behaviour any further given the remaining ones.
In the context of declarative process discovery, event logs can be affected by recording errors or report exceptional deviations from the usual enactments [7] .In such cases, constraints that were originally part of the process may be violated in some of the recorded executions.If discovery algorithms take into account only those constraints that always hold true in the event log, a minimum amount of noise might already cause several constraints to be discarded from the returned set [8][9][10] .To circumvent this issue, declarative discovery algorithms offer the possibility to tune a so-called support threshold : it specifies the minimum fraction of cases in which a constraint is fulfilled within the event log to let such constraint be included in the discovered model.However, this comes at the price of possibly having conflicts in the model though: constraints that hold true in a fraction of the event log above the set threshold can contradict other constraints.In such a case, the model becomes unsatisfiable, i.e., it exerts conditions that cannot be met by any possible execution.Such a model would clearly be to no avail to the discovery intents.This issue outlines the problem of inconsistencies in the discovered model, which we challenge in this research paper.
The aim of the presented approach is therefore twofold: given a discovered declarative process model, we want to (1) remove its inconsistencies, and (2) remove its redundancies.To pursue these objectives, we aim at keeping the process behaviour as similar as possible to the original one when removing inconsistencies, and retaining the minimum number of constraints that still represent the same original behaviour while getting rid of the redundancies.The number of combinations of constraints to test for the optimum of both problems is not tractable in practice, because every subset of the original constraints set should be confronted with the others.Our solution instead requires a polynomial number of checks over constraints to provide a sub-optimal yet effective solution.Furthermore, different criteria can be adopted to express (1) the desired behavioural closeness and (2) the preferability of constraints to be retained.To this extent, our solution envisages (1) the relaxation of conditions exerted by the contradicting constraints and (2) different ranking criteria for constraints, respectively.

Declarative process modelling and mining
This section defines the formal background for our research problem.In particular, we introduce and revisit the concepts of event logs and of declarative process modelling and mining.
Notational conventions.We adopt the following notations.Given a set X , ( i ) the multi-set of X is denoted as M ( X ) ; ( ii ) the power-set of X is denoted as P ( X ) ; ( iii ) a sequence of elements x i ∈ X is denoted by the juxtaposition of its elements x 1 x 2 x n ; (i v ) the cardinality of X is denoted as | X |; the same notation applies both to the length of sequences and the cardinality of multisets.
Identifiers in cursive sans-serif format will be written in sansserif letters when assigned to actual parameters.Generic identifiers of tasks, e.g., will be indicated as a , b , and c , whereas concrete assignments of task identifiers will be written as a , b , and c .

Event logs
An event is a system-recorded information reporting on the execution of a task during the execution of a process.Events are labelled with so-called event classes , i.e., task names [11] .We assume that each event uniquely corresponds to the execution of a single task.This assumption builds upon the work on event class reconciliation of Baier et al. [12,13] .We thus abstract every event with its event class, in turn related to a task.A finite sequence of events is named trace .A complete trace represents the execution of a process instance from the beginning to the end.An event log is a collection of traces.If multiple process instances have been executed by conducting the same sequence of tasks, multiple traces in the event log consist of the same sequence of events, accordingly.
Formally, an event log L is a multi-set of traces [14][15][16] .The log alphabet A is the set of symbols identifying all possible tasks and event classes.We write a , b , c to refer to them.Without loss of generality, we also refer to events as occurrences of symbols in A .By denoting the set of sequences of tasks as A * we have that L ∈ M ( A * ) .An example of log is: L = { t 1 , t 2 } where t 1 = abcacbacd and t 2 = ababc .Event logs are the fundamental input of automated process discovery algorithms [14,17] .

Declarative process modelling languages
A declarative process modelling language represents the behaviour of processes by means of constraints, i.e., rules that must not be violated during the execution of process instances.Such rules are meant to be exerted over tasks in the context of temporal structures like imperative process models or logs.To date, Declare is one of the most well-established declarative process modelling languages.It provides a standard library of templates ( repertoire ), i.e., behavioural constraints parametrised over activities.Table 1 lists the constraints that will be considered in this paper.Formally, a template is a predicate C/ n ∈ C , where C is the Declare repertoire and n denotes its arity, i.e., the number of parameters [18] .In this article, we consider constraints of arity not higher than 2, because they constitute the subset of constraints discovered by the majority of declarative process miners [19][20][21] .Nevertheless, the presented approach can be seamlessly extended to the case of constraints of higher arity.Existence templates are unary, whereas relation templates are binary.Formal parameters of constraints are denoted by x and y for binary constraints or as x 1 , . . ., x n for constraints of a generic arity n .We will interchangeably use, e.g., C / 2 or C (x, y ) to denote a template of arity 2. Templates will be denoted as C when their arity is unspecified or clear from the context.

Typical examples of
A constraint is the application of a template over tasks by means of the assignment of its formal parameters to elements in [1, n ] is the set of integers ranging from 1 to n .γ n ( i ) is meant to assign the i -th parameter of C/ n to a task in A , in compliance with the positional notation of the parameters of predicates.The C/ n -constraint resulting from γ n , written Cγ / n , is also represented as C = C(γ n ( 1 ) , . . ., γ n ( n ) ) .For example, Response (b , c ) denotes the constraint resulting from the application of γ In light of the above, and taking inspiration from the tabular representation of behavioural relations in [22,76] , we can define a declarative process model as follows.

Definition 3.1 (Declarative process model) . A declarative process model is a tuple
where: • A is a finite non-empty set of tasks; • C is a finite non-empty repertoire of templates; is a subset of the constraints universe C A , which corresponds to the set of all constraints C that derive from the instantiation of every template C/ n ∈ C with every possible assignment to tasks in A .Please notice that by definition two different assignments γ n and γ n can be applied to the same constraint C/ n .It is the case, e.g, when Response (a , b ) and Response (b , c ) both belong to the declarative process model: Declare is a declarative process modelling language providing the repertoire of templates listed in Table 1 .Having, e.g., As said, events are meant to be recordings of the tasks carried out during the process enactment.Therefore, we will interchangeably interpret Declare rules as ( i ) behavioural relations between tasks in a process model or ( ii ) conditions exerted on the occurrence of events in traces.We will henceforth consider that, e.g., Participation (a ) imposes that every trace contains at least an occurrence of a .Likewise, Response (b , c ) indicates that after the occurrence of b , c occurs afterwards in the trace.Both t 1 and t 2 in the example log L are compliant with Participation (a ) and Response (b , c ) .Such conceptual matching is typical of Declare mining approaches [9,23] , as event logs are used to analyze to what extent constraints are respected by counting the number of fulfilments within traces.

Evaluation and satisfiability of a declarative process model
Since constraints are predicates, they can be evaluated and checked for satisfiability .In particular, as exposed by Räim et al. [24] , every constraint of a declarative process model can be evaluated over traces by adopting a semantics based on linear temporal structures.We thus introduce the notion of evaluation of a constraint over a trace as a function η : If the conditions imposed by the constraint are satisfied by every event in the trace, then the trace fulfils the constraint, i.e., the constraint evaluates to true ( ) over the trace.With a slight abuse of notation, we denote the evaluation of a declarative process model M = A , C , over a trace by means of the same symbol η, and define it as follows: The notion of evaluation of a declarative process model leads to the satisfiability problem, i.e., checking whether there exists a trace over which the model evaluates to true.Hereinafter, we denote the set of traces that satisfy a declarative process model M as its language : Since a declarative process model is evaluated to on a trace t only if all its constraints are evaluated to on t ( Equation 2), given two models M = A , C , and M = A , C , where ⊆ , it follows that L ( M ) ⊆ L M .The declarative process model unsatisfiable, because the two constraints are contradicting, which implies L ( M ∅ ) = ∅ .Notice that also the declarative process model ) .This observation leads to the problem that we want to address: finding and removing contradicting constraints that make declarative process models unsatisfiable.

Discovery of a declarative process model
A declarative process model can be discovered by evaluating all constraints in the constraints universe over the event log and returning all and only those constraints that evaluate to over the event log.However, this would make the discovered model overfitting, with the consequence that if the event log contained errors, then the discovered model would be affected by erroneously discarded or added constraints [25] .To overcome this issue, metrics have been introduced that make the discovered model less prone to faulty log entries.
Taking inspiration from the area of data mining [26] , we adopt the support metric [19,21] .Support assesses the degree of fulfilment of constraints in the event log by scaling the number of traces fulfilling the constraint by the number of traces in the log.
Support is defined as a function σ : being R 0 the set of positive real numbers, computed as follows: Given the example event log from above, L = { t 1 , t 2 } where t 1 = abcacbacd and t 2 = ababc , we have that: σ ( Participation (a ) , L ) = 1 .0 , σ ( Response (b , c ) , L ) = 1 .0 , and σ ( Response (a , b ) , L ) = 0 .5 , because no b follows the last a occurring in t 1 .
Typically, a discovered declarative process model consists of those constraints having a support higher than a user-specified threshold: those that are fulfilled in a significant number of cases belong to the discovered model.However, the amount of constraints that the discovered model consists of is usually overwhelming, when only relying on such criterion.Therefore, metrics for assessing the relevance of constraints have been established, i.e., confidence κ and interest factor ι, which scale the support by the ratio of traces in which the activation occurs, resp.both the constrained tasks occur.Confidence and interest factor are defined as functions κ : Different variants of calculating these metrics have been proposed [19,27,28] .Notice that both κ and ι scale the value of σ by a number included in the range [0, 1].By their definition, it always holds true that given a constraint C and an event log

Declare template types and subsumption
Declare is a declarative process modelling language that provides a repertoire of templates for the specification of constraints over tasks.The list of templates considered in this paper is provided in Table 1 .Here, we describe how the templates are divided into types and constitute a subsumption hierarchy [25,27,29] , as illustrated in Figure 1 .
Examples of constraints in Declare are: ( i ) Participation ( a ), specifying that task a must occur in every trace; ( ii ) AtMostOne ( a ), declaring that a must occur not more than once in a trace; ( iii ) RespondedExistence ( a , b ), imposing that if a occurs in a trace, then also b must occur in the same trace.Participation and AtMostOne are existence templates.Because they exert restrictions on the number of occurrences of a task in a trace, they belong to the type of cardinality constraint templates .Init ( a ) and End ( a ) are existence constraints stating that a must be the first, resp.the last, event occurring in all traces.Therefore, they belong to the type of position constraints .Both their templates are subsumed by Participation , because they imply that the constrained task occurs in every trace in order to be the first or the last one.Figure 1 (a) illustrates the subsumption hierarchy of existence constraint templates.Templates are indicated in solid boxes.The subsumption between templates is drawn with a line starting from the subsumed template and ending in the subsuming one, with an empty triangular arrow recalling the UML IS-A graphical notation.
As Figure 1 (b) illustrates, RespondedExistence ( x , y ) generates an offspring of related relation templates.Its directly subsumed templates ("children") are Response ( x , y ) and Precedence ( y , x ).Response ( a , b ) imposes that eventually after an occurrence of a (the activation), b (the target) must occur.Dually, Precedence ( a , b ) requires that before an occurrence of the activation task b , target task a occurs.Both constraints strengthen the conditions exerted by RespondedExistence by specifying that not only must the target occur, but also in which relative position in the trace (after or before the activation).However, the role of activation and target are swapped in Precedence , w.r.In the subsumption hierarchy of both Response and Precedence , the direct child templates are AlternateResponse and AlternatePrecedence .The concept of alternation strengthens the parent template by adding the condition that between pairs of activation and target, not any other activation occurs.The subsumption hierarchy concludes with ChainResponse and ChainPrecedence : they impose that occurrences of activation and target are immediately adjacent.
The conjunction of a forward-unidirectional relation template and a backward-unidirectional relation template belonging to the same level of the subsumption hierarchy generates the so-called coupling templates: Succession ( x , y ), e.g., holds when both Response ( x , y ) and Precedence ( x , y ) hold true.In addition, the coupling template CoExistence is equal to the conjunction of RespondedExistence and RespondedExistence − .For every coupling template C, a function fw ( C ) and bw (C) are defined that resp.return the related forward-unidirectional relation and the backward-unidirectional relation templates.Hence, fw ( Succession (x, y ) ) = Response (x, y ) and bw ( Succession (x, y )) = Precedence (x, y ) .In Figure 1 (b), the functions fw and bw are indicated by grey arcs labelled as forward and backward , respectively.With a slight abuse of notation, we will adopt function symbols fw and bw not only for templates but also for constraints.
Finally, coupling templates CoExistence , Succession and ChainSuccession correspond to other templates that share the same activations and exert opposite conditions on the targets: Resp., NotCoExistence , NotSuccession and NotChainSuccession .For instance, CoExistence ( a , b ) states that a and b always co-occur in a trace.NotCoExistence ( a , b ) states instead that if either a (resp.b ) occurs in the trace, then b (resp.a ) cannot.Owing to this, NotCoExistence , Not-Succession and NotChainSuccession are named negative templates.Given a negative template, e.g., NotCoExistence , we say that it negates the corresponding coupling template, e.g., CoExistence .Due to the opposite conditions exerted on the targets, the subsumption hierarchy gets also reverted w.r.t. the corresponding negated templates: NotCoExistence NotSuccession NotChainSuccession .In Figure 1 (b), negative templates are graphically linked to their corresponding coupling templates by means of wavy grey arcs labelled as negates .
Based on the concept of subsumption, we can define the notion of relaxation R .R is a unary operator that returns the direct parent in the subsumption hierarchy of a given template.If there exists no parent for the given template, then R returns a predicate that would hold true for any possible trace, i.e., .Formally, given a template C ∈ C , we have: We extend the relaxation operator and the subsumption relation to the domain of constraints, such that, e.g., R( Response

Semantics of DECLARE as regular expressions
A plethora of semantics for Declare templates have been proposed in the literature by relying on different logic-based approaches, including Linear Temporal Logic (LTL) [30,31] , Linear Temporal Logic on Finite Traces (LTL f ) [32,33] , First Order Logic (FOL) formulae over finite ordered traces [27,33] and abductive logic programming [34] .We adopt regular expressions (REs) because they allow us to take advantage of well-established techniques for calculating automata products, which are at the base of our approach.Table 1

lists the translation of templates into regular expressions (REs).
Regular expressions are a formal notation to compactly express finite sequences of characters, a.k.a.matching strings.The syntax of REs consists of any juxtaposition of characters of a given alphabet, optionally grouped by enclosing parentheses ( and ) , to which the following operators can be applied: binary alternation | and concatenation, and the unary Kleene star * .Thus, the regular expression a(bc) * d|e identifies any string starting with a , followed by any number of repetitions of the pattern (sub-string) bc (optionally, none) and closed by either d or e , such as ad , abcd , abcbce and ae .Table 1 adopts the POSIX standard for the following additional shortcut notations: ( i ) .and [ ^ x ] respectively denote any character or any character but x , ( ii ) + and ?operators respectively match from one to any and from none to one occurrences of the preceding pattern.We also make use of ( iii ) the parametric quantifier {, m } , with m integer higher than 0, which specifies the maximum number of repetitions of the preceding pattern, and (i v ) the parametric quantifier { n ,} , with n integer higher than or equal to 0, which specifies the minimum number of repetitions of the preceding pattern.We recall here that ( i ) regular expressions (REs) are closed under the conjunction operation & [35] , and ( ii ) the expressive power of regular expressions (REs) completely covers regular languages [36] , thus ( iii ) since regular grammars are recognisable through REs [36,37] , for every RE, a corresponding deterministic finite state automaton (FSA) exists, accepting all and only the matching strings [38] .The conjunction operator & satisfies commutativity and associativity.Its identity element is .* .

Finite state automata
A (deterministic) FSA is a finite-state labelled transition system A = , S, s 0 , δ, S f , where: is an alphabet; S is the finite nonempty set of states; s 0 ∈ S is the initial state; δ : S × → S is the transition function, i.e., a function that, given a starting state and a character of the alphabet, returns the target state (if defined); S f ⊆ S is the set of final (accepting) states [37] .For the sake of simplicity, we will omit the qualification "deterministic".A finite path π of length n over A is a sequence π = π 1 , . . ., π n of tuples π i = s i −1 , σ i , s i ∈ δ, for which the following conditions hold true: ( i ) π 1 , the first tuple, is such that s 0 = s 0 (i.e., π starts from the initial state of A ) and ( ii ) the starting state of π i is the target state of We overload the L notation by denoting as L ( A ) ⊆ P ( * ) the (possibly infinite) set of strings accepted by A .
FSAs are closed under the product operator × [39] .A product of two FSAs A and A accepts the intersection of languages (sets of accepted strings) of each operand: The product of FSAs is an isomorphism for the conjunction of regular expressions (REs), i.e., the product of two FSAs respectively corresponding to two regular expressions (REs) is equivalent to the FSA that derives from the conjunction of the two regular expressions (REs) [40] : given the regular expressions (REs) r , r , and naming as A the operation leading from an RE to the corresponding FSA, we have that A r & r = A ( r ) × A r .The product operator × is commutative and associative.The identity element for × over the alphabet is . It accepts all strings over : 2

Formalisation of the Problem
In this section, we present the twofold problem tackled in this work.First, we want to avoid that the discovered declarative process models contain inconsistencies, i.e., contradictions among constraints that make the overall model unsatisfiable.Second, we want to minimise the number of constraints in the discovered declarative process models, in particular by eliminating those that are redudant.

The consistency problem
In Section 3.2 , we have introduced the general notions of declarative process model and of its language, defined in terms of the set of traces that satisfy all constraints present in the model.We have also discussed that not all declarative process models are meaningful.One extreme case is the one in which the declarative process In this case, M cannot be used for simulation nor execution, since there exists no trace that satisfies it.In addition, the usage of M to evaluate the compliance of a log confuses the process analyst, since every trace is trivially considered non-compliant.Furthermore, M acts as an absorbing element when composing it with another declarative model M , in the sense that the model resulting from the composition continues to be unsatisfiable, irrespectively of the constraints contained in M .
An unsatisfiable model M = A , C , contains at least one constraint C ∈ that is in conflict with the other constraints , for which no trace exists that satisfies them all.Formally, there is no t ∈ A * such that η( C, t ) = for every C ∈ \ { C } and η C , t = .Addressing the consistency problem means ensuring that a declarative process model is satisfiable, i.e., accepts at least one execution trace.When the process model is unsatisfiable, this requires to identify and remove those constraints that are in conflict.This problem is extremely challenging.In fact, there could be multiple sets of conflicting constraints, each formed by two or more constraint.Their identification is thus inherently intractable, as it requires in the worst case to consider all possible subsets of [41] .Furthermore, once such conflicting sets are singled out, there are in general exponentially many ways of removing constraints belonging to such sets so as to fix the inconsistency.This issue is particularly difficult to manage in the context of declarative process discovery, since each newly discovered constraint could suddenly introduce a conflict with the partial declarative process model discovered so far.
On the other hand, the consistency problem is pervasive in declarative process discovery.To illustrate this, we utilise the event log set of the BPI challenge 2012 [42] .The event log pertains to an application process for personal loans or overdrafts of a Dutch bank.It contains 262,200 events distributed across 24 different possible event classes and 13,087 traces.Process mining tools such as MINERful [27] and Declare Maps Miner [19] generate declarative process models in Declare from event logs.In essence, these models define a set of declarative constraints that collectively determine the allowed and the forbidden traces.
The main idea of declarative process discovery is that the overfitting of the discovered models can be avoided by defining thresholds for parameters such as support, confidence and interest factor.By choosing a support threshold smaller than 100%, we can easily obtain constraint sets that are supported by different parts of the log and that contradicts each other.E.g., when using MINERful on the BPI challenge 2012 event log with a support threshold of 75%, it returns the constraints Participation ( A _ Preaccepted ) , NotChainSuccession ( A _ Preaccepted , W _ Completeren aanvrag ) , and ChainResponse ( A _ Preaccepted , W _ Completeren aanvrag ) , which have an empty set of traces that fulfil all of them.In fact, the first constraint imposes that A _ Preaccepted must be executed at least once, the second constraint imposes that A _ Preaccepted is never directly followed by W _ Completeren aanvrag , whereas the third one requires that if A _ Preaccepted is executed, W _ Completeren aanvrag must immediately follow.Clearly, such inconsistent constraint sets should not be returned by the discovery algorithm.

The minimality problem
The second problem we tackle in this work is minimality.This problem is concerned with the informative content of the discovered declarative process model.The goal is to understand whether all its constraints effectively contribute to the separation between compliant and non-compliant traces, or are instead redundant.Let M = A , C , and let C ∈ be a constraint of M .Intuitively, we say that C is redundant in M if the set of compliant traces (i.e., the language defined by M ) is not affected by the presence of C .
Formally, let M = A , C , \ { C} be the declarative process model obtained from M by removing constraint C .We then have that C In this light, addressing the minimality problem means transforming the discovered declarative process model into one that is language-wise equivalent, but does not contain redundant constraints.Models that contain redundancies are pointlessly difficult to understand for the process analysts, since redundant constraints do not provide any additional information about the permitted and forbidden behaviours.
Like for consistency, this problem is inherently difficult and calls for the application of suitable strategies that find a reasonable trade-off between optimality and computational efficiency.In fact there are, in general, exponentially many ways of making a model redundancy-free.This is, again, particularly critical in the context of declarative process discovery.Every newly discovered constraint could in fact introduce redundancy, which could be removed either by ignoring the newly discovered constraint or by dropping a set of already discovered constraints redundant with the new one.
To show to which extent this problem is present in concrete declarative process modelling languages such as Declare , we recall the fact that Declare templates can be organised in a hierarchy of constraints, depending on a notion of subsumption, as discussed in Section 3.3 .This notion of subsumption is tightly related to that of redundancy, since a constraint can be immediately recognised as redundant if it is subsumed by another constraint present in the partial declarative process model discovered so far.However, we stress the fact that redundancy could be detected, in some cases, only by analysing the model as a whole, and not just considering pairs of constraints.
When using MINERful on the BPI challenge 2012 event log with a support threshold of 75%, it returns the constraints and NotChainSuccession ( A _ Submitted , A _ Accepted ) .The latter constraint is clearly redundant, because the former requires the first task following A _ Submitted to be A _ PartySubmitted .Therefore, no other task but A _ PartySubmitted can directly follow.A fortiori, A _ Submitted and A _ Accepted cannot be in direct succession.Clearly, such redundant constraint pairs should not be returned.

Framing the Problem
In Section 4.1 and Section 4.2 , we have introduced the issues of consistency and redundancy in declarative process models.We now frame these problems in the context of declarative process discovery.
Our goal is to define effective post-processing techniques that, given a previously discovered Declare model M possibly containing inconsistencies and redundancies, manipulate it by removing inconsistencies and reducing redundancies, but still retaining as much as possible its original structure.In this respect, the postprocessing is completely agnostic to the process mining algorithm used to generate the model as well as to the input event log.
This latter assumption makes it impossible to understand how much a variant of the discovered model fits with the log.However, we can at least assume that each single constraint in M retains the support, confidence, and interest factor that were calculated during the discovery phase.These values can be used to decide which constraints have to be prioritised, and ultimately decide whether a variant M of M has to be preferred over another variant M .
In principle, we could obtain an optimal solution by exhaustive enumeration, executing the following steps: 1.The vocabulary A of M is extracted; 2. The set C A of all possible candidate constraints is built; 3. The power-set P C A of all possible subsets of C A , i.e., of all possible Declare models using constraints in C A , is computed; 4. A set of candidate models M over A and C is obtained from P C A , by filtering away those models that are inconsistent or contain redundant constraints; 5.A ranking of the models in M is established, considering their similarity to the original discovered model M .
However, this exhaustive enumeration is unfeasible in the general case, given the fact that it requires to iterate over the exponentially many models in P C A , an intractably huge state space.
Consequently, we devise a heuristic algorithm that mediates between optimality of the solution and computational efficiency.In summary, its main features are the following: • It produces as output a consistent variant of the initial model M .This is a strict, necessary requirement.
• The algorithm works in an incremental fashion, i.e., it constructs the variant of M by iteratively selecting constraints.Once a constraint is added, it is not retracted from the model.This is done by iterating through the candidate constraints in descending order of suitability.The degree of suitability is dictated by an ordering relation that sorts the constraints before the algorithm starts the checking phase.An example of such an ordering relation is the ranking of constraints on the basis of their support, confidence, and interest factor: it makes the algorithm retain the constraints that better fit the log from which they were discovered.On the one hand, this drives our algorithm to favour more suitable constraints and remove less suitable constraints in the case of an inconsistency or a redundancy.On the other hand, this has a positive effect on performance and also guarantees that the algorithm is deterministic.• Due to incrementality, the algorithm is not guaranteed to produce a final variant that is redundancy-free and minimal in the number of constraints, but we still achieve a local minimum.
Our experimental findings show that this local minimum is satisfactory, since the algorithm is able to significantly reduce the number of redundant constraints w.r.t. the state-of-the-art discovery algorithms.

The approach
This section describes how we tackle the problem of finding a non-redundant consistent Declare model in a way that reduces the intractable theoretical complexity.First, we present the algebraic structure on top of which the check of redundancies and conflicts is performed: it bases upon the mapping of the conjunction of Declare constraints to the product of FSAs.Thereafter, we define and discuss the algorithm that allows us to pursue our objective.In particular, we rely on the associativity of the product of FSAs.This property allows us to check every constraint one at a time and include it in a temporary solution.This is done by saving the product of the constraints checked so far with the current one.For the selection of the next candidate constraint to check, we make use of a greedy heuristic, which explores the search space by gathering at every step the constraint that has the highest support or is most likely to imply the highest number of other constraints.Notice that the commutativity of the automata product guarantees that conflicting constraints are found, regardless of the order with which they are checked.The algorithm proceeds without visiting the same node in the search space twice.

Constraints as automata
As already shown in [21] , Declare constraints can be formulated as regular expressions (REs) over the log alphabet.The assumption is that every task in the log alphabet is bi-univocally identified by a character.Thus, traces can be assimilated to finite sequences of characters (i.e., strings) and regular languages represent the traces allowed by a Declare model.A constraint is thus evaluated to true over a trace if and only if the corresponding string is matched by the constraint's regular expression.
Using the POSIX wildcards, we can express, e.g., Init (a ) as a.  1 and explained in [40] .Henceforth, we will refer to such a mapping as As mentioned in Section 3.4 , an RE can always be associated to a deterministic labelled FSA, which accepts all and only those finite strings that match the RE.We name as A the operation leading from an RE to an FSA, thus we have that a Declare constraint can be associated with its corresponding FSA, A C = A E Reg ( C ) .Hence- forth, we also call A C the C -automaton.Under this interpretation, a constraint C is evaluated to true over a trace if and only if its events can be replayed as a finite path on the C -automaton that terminates in an accepting state, i.e., when its corresponding string is accepted by the C -automaton.
Considering an example declarative process model the C -automata of the set of constraints Γ are drawn in Figure 4 shows the product automata that are derived from the intersection of such constraints: is illustrated in Figure 4 (a), and is illustrated in Figure 4 (b).
We remark that by applying A to the RE of a conjunction of constraints, we obtain an FSA that corresponds to the product × of the FSAs for the individual constraints [35] : . Also, we recall that the identity element for FSAs is a single-state automaton whose unique state is both initial and accepting, and has a self-loop for each character in the considered alphabet.
Given a model M = A , C , , we can therefore implicitly describe the set of traces that comply with M as the language accepted by the product of all C -automata (one for every C ∈ ).In the light of this discussion, our approach searches a solution to the problem of finding a non-redundant consistent Declare model within the automata-product monoid , i.e., the associative algebraic structure with identity element (the universe-set of FSAs) and product operation ×.For the automata-product monoid, the property of commutativity holds.

Sorting Constraints
The objective of the algorithm is to visit the constraints in the declarative process model only once.At every visit, the analysed constraint is checked whether it is conflicting or redundant.In the first case, it is relaxed (replaced by the subsuming constraint) and checked again.If the constraint is not subsumed by any another, it is removed from the set of constraints.In case of redundancy, the constraint under analysis is removed from the set of discovered constraints.The order in which the constraints are checked is thus of utmost importance, as it determines their priority.The priority, in turn, implicitly defines the "survival expectation" of a constraint, as constraints that come later in the list are more likely to be pruned if they are either redundant or conflicting.
We identify four notions of ordering relations for declarative process models.Three of them are suitable for all models, i.e., ( i ) order on the degree of activation linkage ≤ , ( ii ) partial order on the type ≤ T , and ( iii ) partial order on the subsumption ≤ ; the last one is specific for discovered models, i.e., (i v ) order on support, confidence, and interest factor ≤ σ κι .
The first ordering relation is based on the notion of degree of activation linkage.Given a constraint C in the template instantiation relation Γ of a model M and its activation C | •, it counts the number of tasks that play the role of target in constraints that share the same activation of C. Formally, Recalling that we consider for unary constraints the activation to coincide with the target, for the example model The (total) order on the degree of activation linkage is thus defined as follows: This relation is meant to sort constraints by the number of tasks that are subject to conditions over the execution of their activation.
The partial order on the type of constraints is driven by the expertise acquired in the last years in the context of Declare discovery [19,29] .In particular, we tend to preserve those constraints that have the potential of inducing the removal of a massive amount of other constraints due to redundancy.As an example, consider the case of the Init template: given a ∈ A , if Init ( a ) holds true, then also the relation constraint Precedence ( a , b ) is guaranteed to hold true for every b ∈ A \ { a } .This means that, in the best case, |A| − 1 constraints will be removed because they are all redundant with Init ( a ).Similarly, consider the positive relation constraint ChainResponse ( a , b ): it implies NotChainSuccession ( a , c ) for every c ∈ A \ { a, b} .Thus, ChainResponse ( a , b ) has the potential of triggering the removal of |A| − 2 negative constraints due to redundancy.Therefore, the ordering by type sorts constraints according to the following ranking from the highest to the lowest: 5. position constraints, 4. cardinality constraints, 3. coupling constraints, 2. forward-and backward-unidirectional relation constraints, 1. negative constraints.
We define the partial order on the subsumption as follows: Those constraints that have the highest likelihood to induce other constraints are ranked the highest by both the last two orderings.Therefore, their application seems to be suitable to prune out the highest number of constraints, especially during the redundancy check.Therefore, we introduce the hybrid ordering relation ≤ T , defined as follows: In essence, it compares the type of constraints C and C .If they are the same, i.e., C ≤ T C ∧ ¬ ( C ≤ T C )) holds true, then the comparison is made on the basis of ≤ .
Finally, for discovered declarative process models, functions σ , κ and ι are defined for constraints.Therefore, the last ordering relation based on these functions can be applied: Such an ordering is meant to give priority to those constraints that are violated the least within the event log or whose constrained activities occur most frequently.The idea is to remove those constraints that are redundant or conflicting starting from those that are less fitting with the event log.
The aforementioned ordering relations are not strict, because they are not asymmetric: for instance, in the example given for the order on the degree of activation linkage, both Init (a ) AlternateResponse (a , b ) and AlternateResponse (a , b ) Init (a ) hold true.Since the number of constraints in a model is finite, we can assume the existence of a strict total order over constraints # s.t.only one of the following three statements holds for every pair of constraints C , C : either ( i Relation # can be based, e.g., on a perfect hash relation, or on an enumeration-based ordering of constraints.This notion allows us to postulate the creation of a strict total order relation ≤ based on a sequential application of any combination 1 , . . ., n of the aforementioned ordering relations ≤ , ≤ T , and ≤ σ κι .This is inductively defined as follows:  We introduce an algorithm henceforth referred to as sortBy , 1 , . . ., n , s .Its input consists of ( i ) a set of constraints , ( ii ) a set of ordering relation symbols 1 , . . ., n over constraints, and ( iii ) a constant s ∈ { ASC , DESC } , specifying whether the sort has to be performed in an ascending (ASC) or descending (DESC) order.It returns a list of constraints ordered on the basis of the strict total order relation 1 , ... , n .
Figure 5 depicts the following example Declare model: The application of sortBy on Γ with the ordering relation symbols and ≤ T returns the following list: The order of constraints deeply affects the way in which the proposed algorithm verifies whether they are contradicting or redundant.The algorithm indeed iterates over the list and checks at every step the current constraint against the ones that have already been processed.Reading the constraints as returned by the { T , } descending sorting, it can be verified that Response (d , e ) is classified as redundant as well as Participation (a ) .The reason why Response (d , e ) is recognised as redundant resides in the fact that it imposes that e occurs after d .However, the already visited constraint Participation (f) and NotCoExistence (f, d ) // Potentially conflicting constraints   Notice that Response (f, h ) is redundant too.In fact, Response (f, g) specifies that if f occurs, then g must occur too.Response (g, h ) imposes that, after g, h must occur.As a consequence, after f, h must also occur.However, Response (g, h ) is checked only as the very last constraint in the list, hence after Response (f, h ) .Therefore, Response (f, h ) cannot be recognised as redundant.The redundancy would be detected if a second iteration was conducted over the list, by considering whether the current constraint is already implied by all the others.This is the reason why our approach provides for such a second check, which comes at the price of a slower computation though.Notice that we execute the second iteration from the last element to the first one so that constraints with lower priority are processed (and in case eliminated) first.
Finally, we remark here that there is no risk of overlooking contradicting constraints.This can be intuitively explained by the fact that a contradicting constraint always leads to an empty model, regardless of whether it is evaluated as first or last.The different order can only affect which constraint among the ones in conflict is checked last and hence classified as contradicting.

The Algorithm
Algorithm 1 outlines the pseudocode of our technique.Its input consists of: ( i ) A Declare model M = A , C , discovered from an event log L ∈ M ( A * ) , bearing a set of constraints defined over log alphabet A and repertoire C , ( ii ) a list of ordering relation symbols 1 , . . ., n , and ( iii ) a boolean flag r II specifying whether a second redundancy check has to be performed or not.For every C ∈ , we assume that its support, confidence, and interest factor are given too, which is the usual condition when M is the output of mining algorithms such as Declare Maps Miner or MIN-ERful.Table 2 (a) shows an example of , i.e., Γ, defined on the log alphabet { a , b , c , d } .We also assume that the same metrics are defined for those constraints that are not in M , yet are either their subsuming, negated, forward or backward versions.For the sake of readability, these additional constraints are not reported in Table 2 .Table 2 (b) shows the output that corresponds to the post-processing of Table 2 (a), provided that the ordering relation symbols provided are ≤ σ κι , ≤ T and r II is false.constraints that are considered as redundant are coloured in grey.Struck-out constraints are those that are in conflict with the others and thus dropped from the returned set.
Given M and its constraints set Γ, the first operation removeSubsumptionHierarchyRedundancies prunes out redundant constraints from based on the subsumption hierarchy.The procedure removes the subsuming constraints if their support is less than or equal to the subsumed ones.Forward and backward constraints are also eliminated if the corresponding coupling constraint has an equivalent support.The result is stored in .The details of this operation have already been described in [27] .The usefulness of this procedure resides in the fact that it reduces the number of candidate constraints to be considered, thus reducing the number of iterations performed by the algorithm.In Table 2 (b), this operation is responsible for the elimination of Participation (a ) , due to the fact that Init (a ) is known to hold true.
Thereafter, we partition into two subsets, i.e.: ( i ) S consisting of those constraints that are verified over the entire event log (i.e., having a support of 1.0), and ( ii ) U containing the remaining constraints.The reason for doing this is that the former is guaranteed to have no conflict: given the fact that constraints are discovered using the alphabet of the event log, those that have a support of 1.0 can be joined, giving rise to a consistent constraint model.
Even though constraints in S are guaranteed to be conflictfree, they could still contain redundancies.Therefore, the following part of the algorithm is dedicated to the elimination of redundant constraints from this set.To check redundancies, we employ the characterisation of constraints in terms of FSAs.Instead, constraints in U may contain both redundancies and inconsistencies.Table 2 (b) presents the partition of M into S and U .
First, we initialise an FSA A to be the identity element w.r.t. the automata product.In other words, A is initialised to accept any sequence of events that map to a task in the log alphabet.This automaton incrementally incorporates the constraints of the input model based on their priority.To set up redundancy elimination in S as well as redundancy and inconsistency elimination in U , we then order their constitutive constraints according to the criteria specified by the user, 1 , . . ., n .The ranking determines the priority with which constraints are analysed.
After the sorting, constraints are stepwise considered for inclusion in the refined model by iterating over the corresponding ranked lists.constraints in S , i.e., C checking whether its generated language L (A C S i ) is included inside L (A ) , which considers the contribution of all constraints processed so far.If this is the case, then the constraint is dropped.Otherwise, A is extended with the contribution of this new constraint (by computing the product A × A C S i ) and is added to the set R of constraints to be returned.In the example of  (a , d ) is analysed after the existence constraints Init (a ) and End (d ) based on the preliminary sorting operation.It thus turns out to be redundant, because Init (a ) and End (d ) already specify that both a and d will occur in every trace.Therefore, they will necessarily always co-occur.
Redundancy and consistency checks of constraints list is performed by the resolveConflictAndRedundancy procedure ( Algorithm 2 ).The procedure checks the consistency of those constraints that are not redundant.The redundancy is, again, checked based on the language inclusion of the language generated by the ) , where A is the automaton that accumulates the contribution of all constraints that have been kept so far.The consistency is checked through a language emptiness test performed over the intersection of L (A C U i ) and L (A ) .This is done by checking that L (A × A C U i ) = ∅ .In case a conflict is detected, we do not immediately drop the conflicting constraint, but we try, instead, to find a more relaxed constraint that retains its intended semantics as much as possible, but does not incur in a conflict.To do so, we use the constraint subsumption hierarchy.In particular, we use the relaxation operator to retrieve the parent constraint of the conflicting one, and we recursively invoke the resolveConflictAndRedundancy procedure over the parent.The recursion terminates when the first nonconflicting ancestor of the conflicting constraint is found or when the top of the hierarchy is reached.The two cases are resp.covered in the example of Table 2 (b) by ChainResponse (b , a ) , replaced Algorithm 2: Algorithm resolveConflictAndRedundancy A, R , C, V , adding a constraint C to the set of constraint R , if it has not already been checked (and thus included in V ), and is neither conflicting nor redundant with the already added constraints.
Input : An FSA A , a set of non-conflicting constraints R , a constraint C, and a list of already checked constraints   (b , c ) .
If the constraint under analysis is a coupling constraint, then we know that it is constituted by the conjunction of a corresponding pair of forward and backward constraints.In this situation, it could be the case that all the relaxations of the coupling constraint along the subsumption hierarchy continue to be conflicting, but the conflict would be removed by just considering either its forward or backward component (or a relaxation thereof).Consequently, we also recursively invoke the resolveConflictAndRedundancy procedure on these two components.
To limit the issue of missing some redundancies, due to the single iterative check over the elements in the constraint lists, a second check can be performed.The technique is slightly different from the one applied before and requires more computational time.For this reason, ( i ) it is performed after the first iteration has taken place, so as to diminish the amount of constraints to be verified, and ( i ) it is an optional functionality, activated by the userspecified flag r II .Its pseudocode is listed in Algorithm 3 .It takes as input a set of non-conflicting constraints R and a list of order relation symbols 1 , . . ., n .First, the product-automaton A R is built that consists of the product of all constraint-automata of elements in R .Thereafter, constraints in R are sorted accord-ing to 1 , . . ., n in ascending order, i.e., the reverse order w.r.t. the first pass (this is because constraints with a lower priority are processed first and eliminated if redundant).The ordered list that comes out of the sorting is R list .For each constraint C in R list , a new product-automaton is built that considers all constraints in R except C .It is hereinafter indicated as R C .The redundancy check is thus performed: if the language accepted by R C is a subset of the language accepted by R , then the declarative process model excluding C is as restrictive as the declarative process model including C .This means that C can be classified as redundant.
The algorithm proceeds iteratively for all remaining constraints in R list .Although every element in the list is visited once, the overall procedure is expensive in terms of computation time because a new product-automaton must be built at every step by the crossproduct of l − 1 constraint-automata, where l is the cardinality of the set of input constraints R .The procedure cannot take advantage of the associativity of the cross-product operation, because temporary automata are built at every step without storing the intermediate result of l − 2 cross-products.However, the additional computational effort is compensated by a higher accuracy in the redundancy-check: in the example of Section 5.2 , the redundant constraint Response (f, h ) would be detected by the second-pass algorithm, whilst it was not captured in the first check.Finally, a last complete pass over constraints in R is done, to check again whether there are subsumption-hierarchy redundancies.If so, R is pruned accordingly.
Complexity of the Algorithm.We close this section by elaborating on the complexity of the algorithm, considering as input the number of constraints contained in the discovered model.To better highlight the different sources of complexity, we consider the overall complexity as well as the complexity obtained from the crude algorithm, without considering the contribution of the automatamanipulating operations.This is particularly important because, even though in the worst case the automata-manipulating operations are exponential in the number of constraints, in practice, they have a nonmonotonic behavior.Consider, for example, the crossproduct operation between an automaton A and the automaton has a number of states bigger than that of A .This is witnessed, e.g., by the automaton in Figure 6 : the size of the automaton of Figure 4 (b), generated by Init (a ) , AlternateResponse (a , b ) , and ChainPrecedence (b , c ) , is bigger than the size of its cross-product with the automaton of AtMostOne (c ) .• O ( n 2 ), if r II is true (i.e., the algorithm includes redundancy double check) and the automata-manipulating operations are considered not part of the algorithm;

e., the algorithm skips redundancy
double check) and the automata-manipulating operations are considered not part of the algorithm.
Proof.As shown in [27] , operation removeSubsumptionHierarchyRedundancies (lines 1 and 18 in Algorithm 1 ) requires a check based on a depth-first visit on a subsumption hierarchy's direct acyclic graph (see Figure 1 ) for every constraint in the input model.For the coupling constraints, also their related forward-and backwardunidirectional relation constraints, are considered.The hierarchy structure is however fixed and the number of steps for the visit are thus limited.In particular, the worst case is represented by ChainSuccession The instructions from line 8 to line 13 of Algorithm 1 are repeated for all constraints in S .Within the loop, A and E Reg operations require O (1), since they are applied to a single constraint.To separate the sources of complexity inherent to the algorithm, and those coming from the manipulation of automata, we explicitly denote the complexity of the language-inclusion check of line 11 and the automata-product of line 12 as T L ⊃ and T A × respectively.With this notation at hand, we get that the loop from line 8 to line 13 of Algorithm 1 can be executed in O (n At line 15 of Algorithm 1 , a loop over the constraints in U starts.For every constraint in U , procedure resolveConflictAn-dRedundancy ( Algorithm 2 ) is invoked.The time complexity of the procedure is affected again by the cross-product operation and the language-check.The recursive calls of lines 10, 12 and 13 are limited and independent of the number of constraints in : the worst case is represented by a ChainSuccession ( a , b ) constraint passed in input as C , because it presents a chain of 4 subsuming constraints (hence, in 4 cases a R ( C ) exists) and has both a forward-and a backward-unidirectional relation constraint" namely ChainResponse ( a , b ) and ChainPrecedence ( a , b ).For each of them, 4 further subsuming constraints exist as well (cf.Figure 1 (b)).The total amount of recursive calls is thus at most 12.However, every invocation of procedure resolveConflictAndRedundancy for each constraint can include in R up to 3 new constraints in place of the passed one, because the subsuming, forward and backward-unidirectional relation constraints, may be added in line 7, executed within the respective recursive invocations at lines 10, 12 and 13.Therefore, | R | ≤ 3 • n , and, in turn, the time required by the loop starting at line 15 of Algorithm 1 is Finally, procedure resolveRedundancies II ( Algorithm 3 ) is invoked if and only if parameter r II is set to (line 17 of Algorithm 1 ).The constraints in R are preliminarily sorted at line 1 of Algorithm 3 , with cost O ( n • log ( n )).Then, automaton A R is built as the crossproduct of all constraints in R .The computational complexity of this step is O (n • T A × ) .Within the loop starting at line 15, for every constraint C ∈ R , the new automaton A R C is built as the cross-product of all constraints in R except C (line 5).Each execution of the cross-product brings, again, a cost of O (n • T A × ) .At line 6, the languages of A R and A R C are compared, with cost T L ⊃ .All in all, the computational cost of resolveRedundancies II is thus To conclude, we notice that the two costs T A × and T L ⊃ can be uniformly represented by a single source of complexity T A , since the inclusion checks all depend on previous cross-product constructions.
Consequently, the overall algorithm runs in time: The three statements of the theorem directly follows, by noticing that computing the cross-product automaton of (at most) n regular expressions is, in the worst case, exponential in n [43,44] , and that the third element of the sum above is only present when r II is true.

Experiments and results
In this section, we illustrate the evaluation of our implemented approach.The approach has been validated in terms of ( i ) efficacy, measured by the number of pruned redundant constraints and detected inconsistencies, and ( ii ) efficiency, measured as computation time.Experiments have been conducted on process models discovered from real-world collections of event logs, provided by the IEEE Task Force on Process Mining on the 3TU Datacentrum platform, 1 i.e., • the event log of a loan application process of a Dutch financial institute, published in the context of the BPI challenge 2012 [42] , • the collection of three event logs of the Volvo IT incident and problem management, resp.describing closed issues, incidents, and open problems, from the BPI challenge 2013 [45] , • the event log of ITIL processes of Rabobank Group ICT, from the BPI challenge 2014 [46] , and • the event log of a road traffic fines management process [47] .
All experiments were run on a machine equipped with an Intel Core i5-3320M, CPU at 2.60GHz, quad-core, Ubuntu Linux 12.04 operating system.The tool was implemented in Java SE 7 and integrated with the MINERful declarative process miner.It can be downloaded at: www.github.com/cdc08x/MINERful .
In the following subsections, we show ( i ) an in-depth analysis of the results obtained by checking consistency and redundancy of the models discovered with MINERful and Declare Maps Miner from the loan application process log and ( ii ) a summary of the results obtained from the redundancy check conducted over the models discovered from all aforementioned logs.We recall here that both MINERful and Declare Maps Miner already provide adhoc techniques to reduce the size of the returned models [19,27] .Nevertheless, no mechanism allows them to remove inconsistencies or those non-trivial redundancies that our approach is able to find out.

Consistency and redundancy checking (BPI challenge 2012)
Here, we describe the outcome of the application of the proposed approach to detect inconsistencies over a declarative process model discovered from the event log provided for the BPI challenge 2012.The BPI challenge 2012 log was chosen for such an analysis because it is the one that presents inconsistencies in the discovered model already at relatively elevated thresholds of support.The event log pertains to an application process for personal loans or overdrafts.It contains 262,200 events distributed across 24 event classes and includes 13,087 traces.With this experiment, we show that our approach is capable of pruning the discovered models by detecting inconsistencies within the constraints discovered by two state-of-the-art declarative process discovery algorithms: MINERful and Declare Maps Miner.We set up both miners to return constraints with a support higher than 75%, a confidence higher than 12.5%, and an interest factor higher than 12.5%.In a realistic scenario, indeed, event logs could contain errors due to recording mistakes or exceptional deviations from the usual execution [7] .Therefore, it makes sense to include those rules that are not fulfilled in the totality of the cases.Since we do not know how many errors or exceptional process enactments affected the log under analysis, we based our choice upon previous studies on the sensitivity of the discovered Declare constraints to the presence of noise in event logs [25] .The levels of confidence and interest factor are motivated by the need to limit the unavoidable increased number of constraints that are included in the result as the support threshold is lowered.
Table 3 summarises the results of the experiment.In the first set of experiments ( Table 3 (a)), we used MINERful.The number of discovered constraints was 306.On top of that, we applied the proposed algorithm, setting , σ κι , T as the ordering relation symbols and r II to false.We obtained 130 constraints in total, with an execution time of 9, 171 milliseconds.

Table 3
Results of the application of the approach on the models discovered from the BPIC 2012 log [43]  ( W _ Completeren aanvraag ) .Both inconsistencies were detected by our algorithm.Note that the percentage of reduction over the set of discovered constraints (that was already pruned based on the subsumption hierarchy) was of 58%.
In the second set of experiments ( Table 3 (b)), we used the Declare Maps Miner.We discovered a set of constraints using the same thresholds for support, confidence and interest factor adopted for the previous experiment.The tool (that provides an ad-hoc technique for pruning) discovered 69 constraints.By applying the proposed algorithm starting from this set, we obtained 41 constraints (with an execution time of 2, 764 milliseconds).The percentage of reduction was still around 40%.
Redundant constraints can be pruned based on complex reduction rules that are not supported by the state-of-the-art declarative process discovery algorithms.For example, from our experiments, we derived that AtMostOne ( A _ Finalized We want to finally remark that the pruning of redundancies of our approach does not alter the behaviour of the returned model.Those constraints that are eliminated are indeed those that can be removed without affecting the way in which the process can be enacted, because they do not restrict the possible executions any further.This is substantially different from the pruning based on thresholds like support, confidence and interest factor that modifies the set of the allowed behaviours.The next subsection illustrates a comprehensive view on the results of redundancy checking performed on a large set of real-world event logs.

Redundancy Checking Analysis
To assess the capability of the proposed approach to identify and prune the redundant constraints from a model, we ran the implemented algorithm on process models discovered from real-world logs.We utilised MINERful to discover the declarative process models from every log provided by the past editions of the BPI challenges in ( i ) 2012, ( ii ) 2013, ( iii ) 2014, and from (i v ) the real-world event log of road traffic fines management process.Hereinafter, we will refer to the respective discovered process models as ( i ) "BPIC 2012", ( ii ) "BPIC 2013/1", "BPIC 2013/2", and "BPIC 2013/3", ( iii ) "BPIC 2014", and (i v ) "Fines".
We have set the support threshold to 75% for the discovery phase.For the first log in the list, we have set the thresholds for confidence and interest factor to 25% and 12.5%, respectively, whereas for the remaining ones we have used the thresholds 12.5% and 6.25%.These values were chosen so as to keep the returned constraints in a range that allowed several computationally intensive routines: ( i ) 226 for BPIC 2012, ( ii ) 30 for BPIC 2013/1, 76 for BPIC 2013/2, and 20 for BPIC 2013/3, ( iii ) 108 for BPIC 2014, and (i v ) 46 for Fines.We have applied our technique on every discovered process model using every combination of defined ordering relations , ≤ T , and ≤ σ κι , plus a random sort used as a baseline.In all the aforementioned cases, the proposed algorithm was run twice: once having the boolean flag r II set to true, thus enabling the second pass over the pruned constraints and once having r II set to false.For every run, we have measured the number of redundancies pruned, the computation time needed, and the average support σ , confidence κ, and interest factor ι of the returned constraints.We use the first metric to assess the efficacy of our approach, the second one to evaluate its efficiency, and the last three to estimate the fitness of the pruned model w.r.t. the original log.
Table 4 shows the obtained results on BPIC 2014 with ( Table 4 (b)) and without ( Table 4 (a)) the second-pass procedure enabled, respectively.The ordering relations are listed in the tables in their order of application.For the sake of readability, only the subscript under the ≥ symbol is shown: hence, e.g., "T " stands for the consecutive application of ordering relations ≤ T and to sort the constraints.In Table 4 (a), the highlighted lines show the best sorting policies when the second pass is not enabled in terms of number of computation time, average support/confidence/interest factor of the returned constraints, and detected redundancies.The results confirm the influence of the adopted sequences of ordering relations on the examined metrics: the lowest computation time is achieved when is applied first (1,027 milliseconds), the highest combination of average σ , κ, ι is shows the effect of the application of the second-pass check: the number of detected inconsistencies considerably raises in the range of 38 to 40 with a tangible gain of 26% to 16 6.6 67% over the first pass.This, however, comes at the price of a far slower computation time, about 10 to 20 times slower, and of a general decrease in terms of average support/confidence/interest factor.We remark here that the number of performed checks remains acceptable despite the second pass: in no case they amount to more than 199, hence not more than twice the number of the constraints in the original model ( 108).This helps the computation time to remain under 40 seconds in all cases.We recall here that an exhaustive search would have required up to approximately 3 × 10 32 checks over an equivalent number of cross-products between automata, thus being computationally infeasible.Table 5 shows the boost effect in terms of detected redundancies given by the second-pass strategy.The highest numbers in terms of pruned redundant constraints are depicted there.Noticeably, 90.265%, 65.217%, and 47.368% of constraints are classified as redundant for BPIC 2012, Fines, and BPIC 2013/2, respectively.This entails that a significant number of constraints could have been omitted from the returned models without altering the set allowed behaviours.
Figure 7 shows the proportion of pruned constraints over all analysed logs using the sorting that worked best in terms of redundancy detection, i.e., T , .The abscissae indicate the types of templates.Triples of bars respectively represent the cumulative number of constraints that sum up ( i ) in all input models, ( ii ) after the first redundancy check, and ( iii ) after the secondpass redundancy check.Horizontal lines describe the average percentage of pruned constraints after the two redundancy check phases, resp.50.4% and 64.03%.Relation constraints in particular tend to be more subject to redundancy, because more than half of them are pruned by the application of the proposed algorithm.This can be due to several factors.First, existence constraints can imply many relation constraints, as in the case, e. Table 6 shows how the sorting order influences the resulting model in all the examined cases.All these results refer to the application of the proposed algorithm only in its first phase, because the second pass tend to alter and level off the metrics of interest.Table 6 (a) presents the sequences of ordering relations that maximise the number of pruned constraints: for all models, ≤ T is the only ordering relation that occurs in every combination.terms of detected redundancies, to a higher computation time, and to an average lower support, with respect to all the values achieved by the other sorting criteria.
The results listed in Table 7 are aggregated on the basis of applied ordering relations.In particular, each of them shows mean and standard deviation values for the metrics under analysis, resp.( i ) Table 7 (a) for the number of pruned constraints, ( ii ) Table 7 (c) for the support, confidence and interest factor of the returned constraints, and ( iii ) Table 7 (b) for the computation time.Highlighted rows evidence the set-ups performing best, i.e., ( i ) T , , allowing for pruning 42.5 constraints on average, ( ii ) , allowing for computation times of 854.33 milliseconds on average, ( iii ) σ κι , , producing constraints that have an average support, confidence, and interest factor of resp.95.331, 45.618, and 30.485.
The outcomes illustrated both in Table 6 and 7 show that the user's choice on the sorting criteria influences the quality of the result in terms of (1) computation time, (2) pruned redundancies, or (3) fitness w.r.t. the event log.(1) When a faster computation is required, the order on the degree of activation linkage should be chosen.This is due to the fact that such a criterion speeds up the building of the product automaton, which is the most expensive operation in terms of computation time.The activations of the constraints with a higher degree of activation linkage are indeed involved as activations of several constraints.Consequently, the higher number of restrictions exerted on the same activation tends to be reflected in a limited number of states and transitions of the associated product-automaton.(2) To maximise the amount of pruned constraints, the partial order on the type and subsumption turns out to be the best choice.Such a criterion was indeed introduced for this purpose.The partial order on the type of constraints tends to rank as first those constraints that entail several other constraints, i.e., those that induce more redundancies.(3) Finally, to keep the constraints with a higher fitness w.r.t. the event log, the order on support, confidence, and interest factor of constraints should be taken into account, because it ranks first those constraints that were fulfilled and activated more often in the event log.As they are ranked first, they are assigned a higher priority when it comes to pruning redundancies out.Because the sorting criteria can be sequentially composed to build a strict total order over the constraints based on the hierarchical application of (partial) orders, different combinations of the aforementioned criteria can be used.The relatively small amount of required running time benefits an interactive selection of the criteria by the users.To further refine the results achieved, the second pass can be enabled at the price of a higher computational effort.
Throughout this section, the results of the application of our approach to real-world benchmark data have been reported and analysed in depth.Experimental evidence has shown that the proposed algorithm can find inconsistencies in the discovered declarative models, which is an unprecedented result in the literature.Furthermore, redundancies are found within the discovered constraint sets, which amounted to approximately one third on average with a single-pass checking, and increased by a supplementary 15% with a second pass.Both achievements were yielded in reasonable computation times: up to 3 seconds for the single-pass and up to 40 seconds for the double-pass.As per the experimental results, the proposed approach enhances the output of both MIN-ERful and Declare Maps Miner, i.e., the two state-of-the-art declarative process miners.The following section examines the works published so far in the literature that deal with topics related to our research endeavour.

Related work
Our research relates to three streams of research: consistency checking for knowledge bases, research on process mining, and specifically research on Declare .Research in the area of knowledge representation has investigated the issue of consistency checking.In particular, in the context of knowledge-based configuration systems, Felfernig et al. [48] have challenged the problem of finding the core cause of inconsistencies within the knowledge base during its update test in terms of minimal conflicting sets (the

Table 7
Average metrics of the processed models.so-called diagnosis).The proposed solution relies on the recursive partitioning of the (extended) constraint satisfaction problem into subproblems, skipping those that do not contain an element of the propagation-specific conflict [49] .In the same research context, the work described in [50] focuses on the detection of non-redundant constraint sets.The approach is again based on a divide-and-conquer approach, which favours, however, those constraints that are ranked higher in a lexicographical order.Differently from such works, we tend to exploit the characteristics of Declare templates in a sequential exploration of possible solutions.As in their proposed solutions, though, we base upon a preference-oriented ranking when deciding which constraints to keep in the returned set.
The idea to apply process mining in the context of workflow management systems has been introduced in [51] .Processes are modelled as directed graphs in which vertices represent the activities and edges stand for the dependencies between them.Cook and Wolf [52] , at the same time, investigate similar issues in the context of software engineering processes.They describe three methods for process discovery: (i) Neural network-based, (ii) purely algorithmic, and (iii) adopting a Markovian approach.The purely algorithmic approach builds a finite state machine where states are fused if their futures (in terms of possible behaviours for the next k steps) are identical.The Markovian approach uses a mixture of algorithmic and statistical methods, so as to cope with noise.However, the results presented in [52] are limited to sequential behaviour only.From [51] onwards, many techniques have been proposed.The α-algorithm [53] and its extensions α ++ [54] , α # [55] , and α $ [56] are algorithmic solutions that exploit behavioural relations between pairs of activities to discover a procedural process model from an event log.Differently from the declarative constraints of Declare , such relations are mutually exclusive: since they do not overlap, they are by construction non-redundant.Behavioural profiles have been introduced by Weidlich et al. [57] as metrics to compare the similarity of procedural process models, as well as to measure the compliance of reported process executions w.r.t. a normative process model [58] .They also partition the product space of activities without semantic overlaps.The work of Polyvyanyy et al. [22] proposes a repertoire of exclusive behavioural relations between pairs of activities, along with a thorough study of their logical and mathematical properties.These behavioural relations are used as a means to analyse or discover procedural models, and cannot be applied to declarative languages.
Our work is related to research on declarative process discovery and modelling.In [9] , the authors introduce the first version of Declare Maps Miner, an approach based on the instantiation of a set of candidate Declare constraints that are checked against an event log to identify the ones that are satisfied in a higher percentage of traces.This approach has been improved in [19] by reducing the number of candidates to be checked through an Apriori algorithm, originally developed by Agrawal and Srikant for mining association rules [59] .In [60] , the same approach has been applied for the repair of Declare models based on log and for guiding the discovery task based on Apriori knowledge provided in different forms.In this work, some simple reduction rules are presented.These reduction rules are, however, not sufficient to detect redundancies due to complex interactions among constraints in a discovered model as demonstrated in our experimentation.In [10,28] , the authors present an approach for the mining of declarative process models expressed through a probabilistic logic.The approach first extracts a set of integrity constraints from a log.Then, the learned constraints are translated into Markov Logic formulae that allow for a probabilistic classification of the traces.In [20,61] , the authors present an approach based on Inductive Logic Programming techniques to discover Declare process models.These approaches are not equipped with techniques for the analysis of the discovered models like the one presented in this paper.In [21,27] , the authors introduce MINERful, a two-step algorithm for the discovery of Declare constraints.As a first step, a knowledge base is built, with information about temporal statistics gathered from logs.Then, the statistical support of constraints is computed by querying that knowledge base.Also these works introduce a basic way to deal with redundancy based on the subsumption hierarchy of Declare templates that is non capable to deal with redundancies due to complex interactions of constraints.In [62] , the authors propose an extension of the approach presented in [21,27] to discover targetbranched Declare constraints, i.e., constraints in which the target parameter is replaced by a disjunction of actual tasks.Here, as well as redundancy reductions based on the subsumption hierarchy of Declare constraints, also different aspects of redundancy are taken into consideration that are characteristic of target-branched Declare , such as set-dominance.
Different logic-based approaches have been used to define the semantics of the Declare templates.In principle, they have been expressed by means of LTL formulae [63] , as in [30,31] .Their interpretation on finite traces with LTL f has been later clarified by [32,33] .In [20] , SCIFF integrity constraints have been used, based on abductive logic programming [34] .Building on the fact that LTL f has the same expressive power as FOL over finite traces [64,65] , the works in [27,33] describe Declare templates in such formal representation.In [66] , Declare constraints are translated into equivalent Petri nets with weighted, reset and inhibitor arcs.In [21,40] , regular expressions (REs) are used to define the semantics of the Declare repertoire.Since REs and Monadic Second Order Logic (MSO) over finite traces [33,67] have equivalent expressiveness, regular expressions (REs) have a higher expressive power than LTL f and, as such, are a suitable language to include the formulation of Declare .This additional expressiveness is exploited in [67] to model Declare meta-constraints that account for compensations and contextual constraints.Interestingly, the techniques presented in this article can be seamlessly applied to such enriched models.
Dynamic Condition Response Graphs (DCR Graphs) [69] are a well-known declarative process modelling language alternative to Declare .They are not directly discussed from the perspective of consistency and redundancy [70] , but can benefit from our work due to their grounding in Büchi automata [71] .
Recently, De Smedt et al. [72] have conducted extensive studies on the so-called "hidden dependencies" [73] , i.e., on the generation of implicit constraints tying activities due to the interaction of other constraints explicitly defined in a process model.The work of De Smedt et al. has lead to an approach that automatically uncovers the hidden dependencies in order to improve the understandability of declarative models.

Conclusion
In this paper, we addressed the problems of eliminating redundant and inconsistent constraint sets that are potentially generated by declarative process mining tools.After providing a formal definition of declarative models, we have formalised the problem and discussed its intractability due to its inherent exponential complexity.Thereupon, we have described our solution based on the notion of automata-product monoid and devised the corresponding analysis algorithms.The evaluation based on our prototypical implementation demonstrates that constraint sets discovered with state-of-the-art declarative process miners can be further pruned such that the result is consistent and locally minimal.
Our approach always finds all the conflicting constraints in a declarative process model.Furthermore, it substantially reduces the size of the discovered models by removing those constraints that do not alter by any means the allowed behaviours.It detects an elevated number of redundancies in process models returned by state-of-the-art discovery algorithms, notwithstanding the fact that they have built-in ad-hoc procedures to circumvent the problem of redundancy.
The sorting criteria adopted to sequentially check the constraints play a crucial role in determining the quality to prioritise in the result.The partial order on the type and subsumption yields a higher number of detected redundancies.The order on support, confidence, and interest factor promotes those constraints that are satisfied the most and involving the most frequent tasks, hence raising the average support, confidence and interest factor of the constraints in the returned model.The order on the degree of activation linkage favours a more efficient computation in terms of time.By choosing which criteria to adopt and in which sequence, the user can thus influence the outcome.Nevertheless, it is in our plans to relieve the human actors from this choice, so as to let them specify the preferred target quality to strive for and make the algorithm automatically find a local optimum by trying different combinations of the aforementioned sorting criteria.Such an extension would be backed by the relatively small computation time required to return the intermediate results to be compared.
As shown in the paper, the approach is capable of processing realworld process models in relatively short time.
Furthermore, we are planning to integrate our approach with the one of De Smedt et al. [72] , which unveils the hidden dependencies among Declare constraints.The latter would drive the search for redundancies seen as dependencies from a core set of constraints, interactively decided by the user.It is also in our plans to involve the users to receive feedback on the outcome of the pruning technique in order to gain a better understanding on the perceived quality of the results, in a similar way to the studies reported in [27,74] .
In future research, we also aim at extending our work towards redundancy freedom, so as to ensure that, although not necessarily minimal, the discovered model is provably free of redundancies.Furthermore, we want to go beyond the pure control-flow perspective and extend our technique to the case of data-and resource-aware declarative process mining.When mining declarative constraints with references to data and resources, one of the challenges is to identify comparable notions of subsumption and causes of inconsistency.We also plan to follow up on experimental research comparing Petri nets and Declare [1,2] .Prior experiments in that regard shed light on the fact that the declarative modelling approach suffered from the lack of consistency and redundancy checks [70,75] .The notions defined in this paper help design declarative and procedural process models that are equally consistent and minimal, such that an unbiased comparison would be feasible.
Declare constraints are Participation (a ) and Response (b , c ) .The former specifies that a must be executed in every process instance.The latter declares that if b is executed, then c must eventually follow.The constrained task of Participation (a ) is a , whereas the constrained tasks of Response (b , c ) are b and c .The template of Participation (a ) is Participation , whilst the template of Response (b , c ) is Response .Participation is an example of existence template, because it asserts conditions on the execution of a single activity.Response is an example of a relation template as it specifies conditions over pairs of activities.For relation templates, activations and targets are defined: the former is a task whose execution imposes obligations on the enactment of another task, i.e., the target.E.g., b is the activation and c is the target of Response (b , c ) , because the execution of b requires c to be executed eventually.
a ) , etc.We respectively indicate activation and target of a template C as C | • and C | ⇒ .Hence, Response (x, y ) | • = x, and Response (x, y ) | ⇒ = y .With a slight abuse of notation, we use the same notation also for constraints: Response (a , b ) | • = a , Response (a , b ) | ⇒ = b .Moreover, we assume that for a template C(x ) of arity 1, activation and target coincide: C

Fig. 1 .
Fig. 1.The subsumption map of Declare templates.Templates are indicated by solid boxes.The subsumption relation is depicted as a line starting from the subsumed template and ending in the subsuming one, with an empty triangular arrow recalling the UML IS-A graphical notation.The coupling constraint templates are linked to the related forward-unidirectional relation constraint and backward-unidirectional relation constraint templates by means of grey arcs.The negative constraint templates are graphically linked to the corresponding coupling constraint templates by means of wavy grey arcs.(a) Existence templates.(b) Relation templates.

Fig. 2 .
Fig. 2. Finite state automata acting as identity element and absorbing element for the automata cross-product operation.(a) Identity element.(b) Absorbing element.
* , and Response (a , b ) as [ ^ a] * (a.* b) * [ ^ a] * .The comprehensive list of transpositions for Declare templates is listed in Table

Fig. 3 .
Fig. 3. FSAs accepting the traces compliant with some Declare constraints over the log alphabet { a , b , c } .(a) Init (a ) .(b) AlternateResponse (a , b ) .(c) ChainPrecedence (b , c ) .E Reg ( C ) , which takes as input a constraint C and returns the cor- responding RE: e.g., E Reg ( Response (a , b ) ) = [ ^ a] * (a.* b) * [ ^ a] * .If we consider the operations of conjunction between Declare constraints ( ∧ ) and intersection between REs ( & ), E Reg is a monoid homomorphism w.r.t.∧ and & .In other words, given two constraints C and C , E Reg C ∧ C = E Reg ( C ) & E Reg C , preserving closure, as- sociativity and the identity element (resp., and .* ).

( 13 )
This relation orders constraints by applying the first ordering relation ≤ 1 to the pair of constraints ( C , C ).If they are such that C ≤ 1 C and C ≤ 1 C , then the comparison by means of ≤ 2 is applied,

Fig. 5 .
Fig. 5.An example of a Declare model.

Algorithm 1 : 1 ← removeSubsumptionHierarchyRedundancies ( ) 2 S ← C ∈ : σ = 1 . 0 /
Algorithm makeConsistent M , 1 , . . ., n , r II , returning the suboptimal solution to the problem of finding a minimal set of non-conflicting constraints in a discovered Declare model.Its input consists of a declarative process model M = A , C , , a list of ordering relation symbols 1 , . . ., n , and a boolean flag r II , enabling a second check for redundancies.Input : A Declare model M = { A , C , } , defined over A .M is a set of constraints for which support, confidence and interest factor are given Output : Set of non-conflicting constraint R /* Initialisation phase */ , are only checked for redundancy, whereas constraints in U , C U i ∈ U list , are checked for both redundancy and consistency.For every constraint C S i ∈ S list , redundancy is checked by leveraging language inclusion.In particular, this is done by computing the FSA A C S

Theorem 5 . 1 .
Given a DECLARE model M containing n constraints, a list 1 , . . ., n of ordering relation symbols, and a boolean flag r II , algorithm makeConsistent M , 1 , . . ., n , r II runs in time • O (2 n ), if the automata-manipulating operations are considered part of the algorithm; ( a , b ), as it can be seen in 1 .It requires at most 6 comparisons: 4 for the subsuming constraints, i.e., Alternate-Succession ( a , b ), Succession ( a , b ), CoExistence ( a , b ), RespondedExistence ( a , b ), and 2 for the forward-and backward-unidirectional relation constraint" resp.ChainResponse ( a , b ) and ChainPrecedence ( a , b ).Both invocations thus cost O ( n ).By construction, operation re-moveSubsumptionHierarchyRedundancies returns a set of constraints such that | | ≤ n .Lines 7 and 14 of Algorithm 1 both apply a sorting algorithm to sets of constraints S and U , respectively.Notice that | S | ≤ n and | U | ≤ n .An efficient algorithm such as merge-sort consequently requires O ( n • log ( n )) for this step.
) becomes redundant due to the presence in combination of AtMostOne ( A _ Partly Submitted ) , Participation ( A _ PartlySubmitted ) , and Alternate Precedence ( A _ PartlySubmitted , A _ Finalized ) .Indeed, Participation ( A _ PartlySubmitted ) and AtMostOne ( A _ PartlySubmitted ) combined ensure that A _ PartlySubmitted occurs exactly once.Then AlternatePrecedence ( A _ PartlySubmitted , A _ Finalized ) ensures that either A _ Finalized does not occur or if it occurs it is preceded by the unique occurrence of A _ PartlySubmitted without the possibilities of other occurrences of A _ Finalized in between.Another example is NotSuccession ( W _ Nabellenoffertes , A _ Submitted ) , which is redundant with the combination of Init ( A _ Submitted ) , AtMostOne ( A _ PartlySubmitted ) , Participation ( A _ PartlySubmitted ) , and ChainSuccession ( A _ Submitted , A _ PartlySubmitted ) .Indeed, AtMostOne ( A _ PartlySubmitted ) and Participation ( A _ Partly Submitted ) ( A _ Submitted , A _ PartlySubmitted ) and Init ( A _ Submitted ) ensures that A _ Submitted occurs only once at the beginning of every trace and, therefore, it can never occur after any other activity.
Figure7shows the proportion of pruned constraints over all analysed logs using the sorting that worked best in terms of redundancy detection, i.e., T , .The abscissae indicate the types of templates.Triples of bars respectively represent the cumulative number of constraints that sum up ( i ) in all input models, ( ii ) after the first redundancy check, and ( iii ) after the secondpass redundancy check.Horizontal lines describe the average percentage of pruned constraints after the two redundancy check phases, resp.50.4% and 64.03%.Relation constraints in particular tend to be more subject to redundancy, because more than half of them are pruned by the application of the proposed algorithm.This can be due to several factors.First, existence constraints can imply many relation constraints, as in the case, e.g., of Participation ( a ), implying that also RespondedExistence ( b , a ) holds true for all b ∈ A \ { a } .Furthermore, non-chain relation constraints are also transitive: therefore, if, e.g., Response ( a , b ) and Response ( b , c ) hold true, also Response ( a , c ) must hold true.Finally, relation templates create a hierarchical structure of subsumptions, thus parents along the hierarchy branches tend to be often pruned out: this is the case, e.g., when ChainPrecedence (a , b ) holds true, thus making AlternatePrecedence (a , b ) , Precedence (a , b ) and RespondedExistence (b , a ) redundant.
trivially accepts any trace consisting of elements of A , because it imposes no constraints.Hence, L ( M I ) = P ( A * ) t. RespondedExistence .Owing to this, RespondedExistence and Response belong to the type of forwardunidirectional relation templates, whereas Precedence is a backwardunidirectional relation template.Technically, given two n -ary templates C , C ∈ C , we say that C is subsumed by C , written C C , if for every trace t ∈ A * and every parameter assignment γ n from the parameters of C to tasks in A , whenever t complies with the instantiation of C with γ n , then t also complies with the instantiation of C with γ n .For binary templates, we write C C − if the subsumption holds by inverting the parameters of C w.r.t.those in C, i.e., by considering templates C (x, y ) and C (y, x ) .We thus have that Re- Merge the C list ← sortBy ( U , 1 , . . ., n , DESC ) // Sort constraints in U in descending order 15 foreach

Table 2
Example of input constraint set processing.

Table 4
[47]lts of the experiments over the model discovered from the BPIC 2014[47]log.

Table 5
Highest amounts of detected redundancies in the process models.

Table 6
(b) lists the sequences of ordering relations that allow for the highest support, confidence and interest factor.As expected, ≤ σ κι is always involved.Table6(c) presents the best achieved computation times.In this case, is always in the list of ordering relations.Finally,Table 6 (d)shows the application of a random sort as a baseline: as expected, the random sort leads to less efficacy in Fig. 7. Redundancy reduction w.r.t.template types.

Table 6
Best set-ups for tests over process models discovered from real-world logs.