On Modelling Process Aspects With Deontic Event-Calculus

Intuitive and faithful modelling of the compliance requirements about the process aspects is a prerequisite for automated compliance checking. Several formalisms with varying degrees of expressiveness for modelling compliance requirements have been reported in the literature. Deontic event-calculus (DEC) is a normative variant of event-calculus (EC) formalism with predicates to modelled normative requirements. However, currently, DEC does not support capturing normative requirements about the process aspects. In this paper, the authors extend DEC with new deontic predicates to model process aspects of data, time, control flow, and resources. The extended deontic predicates enable DEC to intuitively represent the compliance requirements relevant to aspects of a business process. In addition, the authors report the complexity evaluation of the extended deontic predicates using well-known Halstead’s complexity metrics. Evaluation result demonstrates that the complexity of modelling the compliance rules with DEC predicates is significantly lower even when the complexity of the standard EC is exponential.


INTRODUCTION
Business process compliance provides a means to ensure business practice and processes are aligned with the set of norms that stem from a comprehensive set of rules and legislations related to it. It is a core ingredient of any enterprise which provide a high-level overview of the state-of-the-affairs about how well the enterprise is functioning. It is used to ensure that business processes behave according to the conditions prescribed by the norms, where these conditions may be relevant to one or more aspects of a business process. Any divergent/misbehaviour of the business process may lead to noncompliance, which may subsequently result in severe penalties (Hashmi et al., 2016).
In general, a business process can be understood as a set of logically ordered activities aiming to achieve a specific goal. An aspect of a business process can be understood as the general characteristics (or properties) that define the (logical) structure of the process and/or constraints that are attached to it and can be broadly classified into four different types according to their nature, namely: (i) control-flow, (ii) data, (iii) resources, and (iv) temporal (or time) perspectives. The control-flow aspect is used to define the execution order as well as conditions and constraints of executing such tasks; whereas the resources and data aspects describe the entities (and equipment) and data that are needed in the tasks, respectively. Lastly, the temporal aspect refers to the temporal requirements that are imposed to the enforcement, enactment and retract of a task. Figure 1 illustrates an example of security purchase and advice business process that is subject to the compliance requirements from various German banking regulations, as summarized in Table  1. The process starts with an investment advice request from a client. If the client is a new customer, the investment consultant will then perform preliminary identification, lodgement and legitimation checks before providing any advice to the client. However, if the client is an existing one, his details will be updated, and a custody account will be set up for receiving securities transactions. The advisory sub-process is initiated by the acquisition of new/updated customer information and ends once the security advice is completed. If the customer accepts and approve the advice, then securities purchase contract will be prepared, and the order is recorded. Finally, an invoice will be sent to the customer to conclude the purchase and/or advice.
As can be seen from Table 1, the first two rules, R1 and R2, are related to the ordering (controlflow) of activities; R3 is related to the resources (the two brochures) being received by the customer, R5 prescribes the requirement for the competence of the consultant, and R6 stipulates a principle of handling suspected money laundering cases, etc.
Over the years, different formalisms, such as Linear Temporal Logic (LTL) (Pnueli, 1977), LTL-FO+ (Halle & Villemaire, 2008), Defeasible Logic (DL) (Antoniou et al., 2000), Deontic Logic (DL) (von Wright, 1951), Deontic Logic of violations (Governatori & Rotolo, 2006), π-Logic (Abouzaid & Mullins, 2008), Event-Condition-Action (ECA) (Berndtsson & Mellin, 2009), Computational Tree Logic (CTL) and its variant CTL* (Vardi, 2001) etc., have been reported in the literature to model compliance requirements in the verification process. However, so far, existing approaches focus mainly on the verification of business rules at the process level, little has been done in modelling and verifying different aspects that are stipulated in the tasks. Deontic Event Calculus (hereafter, DEC) (Hashmi et al., 2014) is a deontic variant of Event Calculus (EC) (Kowalski & Sergot, 1986). It is a logical formalism that is expressive enough to intuitively represent different types of (deontic) modalities that appear in legal norms (Hashmi et al., 2016). Hence, in this paper, we extend DEC with new predicates to cater the needs of providing support in process aspects modelling. In addition, we also investigate the complexity of the newly introduced predicates.
The structure of the paper as follows: next we discuss related studies conducted in this space in Section 2, following which we tersely revisit the features of DEC in Section 3. In Section 4, we introduce the new predicates and events, and demonstrate how to intuitively model compliance requirements pertaining business process aspects in Section 5. The complexity analysis is presented in Section 6 before concluding the paper with final remarks and pointers for future work in Section 7.
This paper assumes the reader is familiar with EC (Kowalski & Sergot, 1986). All necessary basic notions and notations that appears without definitions are found in (Hashmi et al., 2014;Kowalski & Sergot, 1986). Lohrmann and Reichert (2010) has considered process aspects from an economic perspective and identified 11 different types of economic resources, namely: (i) process instances value consumption, (ii) materials, (iii) raw materials, (iv) supplies, (v) labour, (vi) capital goods employment, (vii) usebound depreciation, (viii) maintenance, (ix) capital goods provision, (x) time-bound depreciation, and (xi) capital employment, that needs to be considered when evaluating the quality of a business process, and has proposed a quality-related measures to this. In comparison to our work, their discussion covers more on the link between business objectives (of each activity) and their associated outcomes/benefits in terms of economic values, while ours is focusing more on the technical aspects of modelling compliance requirements from the process specifications perspective. Apart from this, as pointed out in the paper, whether their measure can be put into practice is still a subject that need to be investigated. Similar to us, Turetken et al. (2012) divided the process aspects into four different pattern classes, namely: (i) order, (ii) occurrence, (iii) resource, and (iv) time, and has further been divided into 28 patterns. For each pattern, they have also developed a map-ping to linear temporal logic (LTL) or metric temporal logic (MTL) to automatically generate the corresponding statements that can be loaded into their pattern-based compliance framework for compliance verification and monitoring. However, their approach is pretty much concentrated on the temporal and control flow aspects of the business process, and little on the data aspect has been addressed. Knuplesch et al. (2013), on the other hand, proposed the use of extended Compliance Rule Graph (eCRG), a visual notation, for compliance rules modelling. On the top of the four process aspects that we have addressed in this paper, their approach also covers interaction aspect that possibly appears in cross-organizational scenarios and had discussed how the information flow among different entities can be modeled. Each eCRG generated will then be converted into a corresponding first order logic (FOL) formula, which in turn will be evaluated over process traces. In our framework, we have decided not to separate the interaction aspect to a new class as the types of information flow can easily be modeled as fluent in DEC. Besides, the use of EC based formula also helps in simplifying the notations used in representing requirements related to the temporal aspect.

RELATED WORK
Montali and colleagues (Montali et al., 2013;Montali et al., 2014) have formalised Declare using EC and extended it with the notion of port for anchoring constraints to atomic and non-atomic activities. In their framework, a port is a tuple P = ⟨E,A,I,D,O⟩ where E is an event type that belongs to the lifecycle of activity A, D is the set of (internal) attributes implicitly associated to all activities, and I and O are the sets of input and output data identifiers of the port, respectively, and assuming that data corresponding to such identifiers are the same throughout the whole business process. Instead of anchoring directly to the activities, data constraints related information will be anchored to the ports. Besides, such anchors can also be used to associate data conditions restricting the range of matching event occurrences. Even though extensions to other aspects seems possible, their analysis concentrated pretty much only on data aspect and little on other aspects of the business process has been addressed. Pereira and Varajão (2017) have identified eight types of constraints related to the temporal aspect of business processes, namely: (i) activity duration, (ii) process duration, (iii) deadlines, (iv) minimum limit, (v) maximum limit, (vi) fixed date(s), (vii) waiting time, and (viii) negative information, and concluded that present business process management systems provide very limited support to model and manage temporal related information, which have to evolve in the future.
Kumar and Barton (2017) discussed a technique for capturing and validating the compliant behaviour of the temporal constraints on the workflow models. In their approach, the constraints are specified as structural and temporal conditions on the models. However, no support for modelling data and resources constraints is provided. Whereas in the context of a large project, Lam et al. (2020) discussed the process aspects as the compliance dimensions of roles, data, money, and quality but no clear indication on how the normative requirements about these dimensions modelled.
Joost and colleagues (Joost & Hans, 2020), on the other hand, used Event-Calculus to formalise logic for reasoning and modelling the effects of actions resulting from commitment for smart contracts. While commitments by nature may be normative, a commitment might be relevant to data, resource, etc-however, in their work have been discussed as exchange commitments and control commitments. No direct reference is provided associating the business process aspects of data, resources, etc., with the categories of commitments. Besides, they used a generic EC variant that cannot intuitively represent deontic modalities, constraints including contractual commitments (Governatori & Hashmi, 2015;Hashmi et al., 2014).

REVISITING DEONTIC EVENT CALCULUS
EC is a discrete event-based logical formalism that was developed to capture the behaviour of a sequence of event occurrences based on the notion of dynamic (mainly, time-varying) properties of the world, called fluents, which was initiated at some time instance and continuously hold until it is terminated, or interrupted, by some event (Miller & Shanahan, 1999, 2002), and is a first-class object that can be quantified over and appear as arguments to predicates (Shanahan, 1999). Since its inception, EC is one of the widely used and studied logical formalism (Alexiev, 1995;Andrade-Lotero, 2006;Cervesato et al., 1997;Farrell et al., 2004;Sadri & Kowalski, 1995).
DEC, in this regard, is a normative extension of EC proposed by (Hashmi et al., 2014), which addresses the issues of EC's base predicates Initiates and HoldsAt that fail to capture the effects of legal norms when they enter into force. As mentioned in (Hashmi et al., 2016), the major difference between DEC and the standard EC is on the condition of initiation. That is, each (deontic) fluent ∆ in DEC has its own specific set of triggering events, trigger(∆, N), which distinguishably represents the situation that the fluent (∆) enters into force with a delay N after the triggering event occurs. In what follows, we revisit some of the relevant predicates and events offered by DEC, as shown in Table 2 Accordingly, business rules may prescribe conditions stipulating the deadlines until when the specific legal effects associated with the fluent must be achieved, or otherwise a violation is triggered. To capture such conditions, the deadline triggering event, deadline(∆,τ), is used, where ∆ is a fluent and τ represents the time instance until when the fluent must be achieved. Correspondingly, the violation event, violation(∆,τ), is used to signify the fluent ∆ has been violated at time instance τ.
Depending on the applicability conditions and contexts, these two events can be used in combination with the Happens predicate in EC to capture the deontic effects of the rules. For instance, Happens(trigger(∆,N),τ) can be used to signify the occurrence of the triggering event with a delay of N time instance, which cannot be achieved with the EC's Initiates predicate.
The predicate DHoldsAt(∆,τ) signals the situation that the (deontic) fluent ∆ is deontically hold at time instance τ. It is different from its EC counterpart HoldsAt on the grounds of its initiation conditions. An obligation can enters into force in two situations: (a) the obligation enters into force when the triggering event occurs, or (b) the obligation enters into force with some delay after the triggering event occurs (Hashmi et al., 2014).
DTerminates(E,∆,N,τ), on the other hand, captures cases where the (deontic) fluent ∆ is deontically terminated by the event E at time instance τ with some delay N, which can occur in either (i) the fluent cannot be achieved before the deadline, or (ii) the fluent is violated and such violation cannot be repaired, and can be captured using the two deontic events violation and deadline mentioned above.

R1
The customer data must be received before the individual risk assessment can take place.

R2
Customer advisor must provide the two obligatory brochures, WpHG Customer Information and the Basic Information Securities and Capital Investment, to the customer.

R3
The customer advisor must ensure that the customer acknowledges the reception of the two brochures.

R4
After concluding the custody account contract, the customer legitimation and the account documents need to be sent to the market support.

R5
The investment advice needs to be conducted by a customer advisor with a securities competence of level C or above

R6
The customer identification and legitimation must be handled by the customer ad-visor, while suspected cases of money laundering must be checked by an anti-money laundering officer.

R7
Before concluding a custody account contract, the customer advisor needs to wait until the suspected case of anti-money laundering is resolved

R8
The customer information must be updated with every future customer contact.

R9
Stockless custody accounts are charged with a fee of 5 Euro per year. If the fee is not paid, the account is dissolved by market support. The account is reactivated by a new securities purchase.
The fluent ∆ has been triggered with a delay N.
deadline(∆,τ) The fluent ∆ must be fulfilled before time τ, or a violation is triggered.
In some cases, the trigger for the fluent does not only trig-ger the initiation of the fluent but also its termination. This means we have to write expression with the following form: DTerminates(trigger(∆, N), ∆, N, τ). Therefore, to ease readability, in such cases we will use the convention of dropping the re-peated ∆ and N from the arguments of DTerminates, using thus: DTerminates(trigger(∆,N),τ).
Below are some examples demonstrating how DEC can be used to model different types of obligations presented in (Hashmi et al., 2014). For instance, the following axioms that describe when a punctual obligation holds.
Here, the punctual obligation is represented as a deontic fluent O τs φ where O τs denotes an obligation to the fluent φ, τ s is the time that the obligation enters into force, and N is an integer; whereas the triggering event trigger(O τs ∆,N) is used to initiate the obligation. Axiom A2, in the like manner, specifies that the obligation is terminated by the same event that triggered it. Hence, the obligation is terminated at the same time instance as it is initiated, which corresponds to the definition of punctual obligation.
Axiom A3, on the other hand, presents an achievement obligation.
For an achievement obligation, achieving the contents of obligation at least once is enough to comply. Generally, a deadline is attached to an achievement obligation until which the obligation must be fulfilled to avoid any violations.
Axiom A4 models the violation of an achievement obligation when the deadline of the obligation occurs but the contents of the obligation are not achieved with in the deadline. Besides, depending on the obligation conditions, the violation of an achievement obligation may terminate 2 the obligation. The predicate 'ViolationTerminable' is a boolean switch that will be checked whether the obligation is terminable upon violation.
Maintenance obligation is a case of persistent obligation (Hashmi et al., 2016). A maintenance obligation generally holds in an interval, and the contents of maintenance obligation must be complied with for all the instants of the interval in which the obligation is in force. The intuition of a maintenance obligation is captured through persistence obligation: A maintenance obligation will remain in force from τ s and τ e until no other relevant event occurs between the interval impacting the obligation.
The violation is automatically triggered if the obligation contents is not achieved at any time instant in the time interval.

PROCESS ASPECT PREDICATES
As previously discussed, a business process is required to behave according to the conditions prescribed by the legal norms. Any divergence to this may lead to non-compliance where severe penalties can be imposed (Hashmi et al., 2016). In essence, these conditions can be relevant to one or more aspects of a business process, which can be broadly understood as the generic characteristics (or properties) that define the structure of the business process and constraints that are attached to it.
From a business process perspective, there are four distinct aspects that need to be considered, namely: control-flow, data, resources, and temporal (or time). The control flow aspect refers to the execution order, or interdependency, of tasks in a business process, and is affected by constructs such as choice, join, loops, synchronization between tasks (Kiepuszewski et al., 2003;Stroppi et al., 2015). Hence, in general, tasks in a business process can be executed in any order, including concurrent or parallel executions. For instance, a rule may prescribe that after concluding the custody contract, the customer legitimation and the account document needs to be sent to the market support simultaneously.
The data aspect describes what data (or information) is required for a task and looks to see how the business process can deliver, or generate, it from other task(s). In practice, the data can be manifested through different formats, such as different types of datasets, document corpus, images and tables, etc., and can be obtained from users directly, consolidated artefacts from datasets, or immediate results obtained from other tasks through message exchange.
Similar to the data aspect, the resources aspect defines the set of entities that are required by a task (Stroppi et al., 2015;Zur Muehlen, 2004). These entities can either be human resources (e.g., organization's employees (with or without special role), external contractors or collaborators, etc), computer hardware or other equipment, software applications or external computational services or environments, or a combination of both. As one can imagine, resources play a significant role in the performance of the whole business process, it is important that suitable resources should be assured and allocated to the tasks in advance.
The temporal (or time) aspect refers to the enforcement (or execution), enactment or retract of a task within a specific time frame. Accordingly, some tasks in a business process may have conditions that must be fulfilled in a determined time interval or by a given deadline, while other conditions may prescribe that some tasks are to be executed before or after the others. For example, a good delivery contract may specify that an invoice must be sent within 30 days from the date it is issued, and that goods cannot be dispatched without a payment. In this case, it obligatory for the client to pay the invoice before the time of delivery. Hence, the temporal aspect prescribes the set of temporal constraints a process must comply with for the whole duration of its validity.
From the legal reasoning and automaton perspective, the formalism must be able to intuitively model legal norms and conditions attached to the specific rules. This typically includes the conditions attached to various aspects of a business process. The DEC can model legal norms but does not provide support for modeling the conditions related to control flow, data, time, and resources aspect of the business process. Hence, to extend the DEC support for modelling legal norms and associated conditions to process aspects, in this paper, we propose the use of DHoldsAt predicate in DEC to capture the (deontic) fluents that are associated with different process aspects.
Before going into details, we first define the variable ∆[J] = ⋃X ∆[X] be the set of all process aspect related (deontic) fluents, and ∆[X] s.t. X C D R T ∈ , , , be the set of fluents which encapsulates the four aspects mentioned above. Hence, for the set ∆[J] to hold at a particular time instance τ, we have the following process aspect predicate 3 : Notice however that, a compliance rule might prescribe constraints that are relevant to one or more aspects, meaning that some of the fluents above may be empty.
The next task is to associate the process aspects ∆[X] with the fluent for reasoning and verification of the normative constraints that include them.
Definition 1: ∆[X] =⟨∆,X,Idx⟩ is a triplet where ∆ is the fluent attached to an obligation, and Idx maps X ↤ Idx ∶ ⟨C, D, R, T⟩, associating the process aspects with the set of fluents X that encapsulate them.

FORMALIZING SECURITy PURCHASE PROCESS WITH DEC
Using the compliance rules as shown in Table 1, in this section, we are going to demonstrate how DEC can be used to model different process aspects of a business process. As mentioned before, the rules R1 and R2 specify the control-flow conditions such that customer data must be collected before the start of customer's risk assessment and two brochures must be provided by the customer advisor to the customer, respectively. Accordingly, these conditions can be modelled using DEC as follows 4 : Let's examine the details of above axioms. Suppose from R1 the event received data occurs for which from Axiom A1, we drive (trigger(O τs ReceivedData [CA,CD] ,N),τ t ) and from earlier defined process aspect predicate we obtain DHoldsAt(O τs ConductRiskAssessment [CA] ,τ s ), meaning that after receiving customer data (CD) it is obligatory for customer advisor (CA) to conduct the assessment. Notice that resource and data aspect are attached to fluent.
In contrast, R2 prescribes two fluents attached to the obligation, that is, providing basic security information (BSI) brochure and capital investment (CI). For simplicity reasons, we split the two conditions and model them as two separate rules as follow: For R2 suppose that the event security advise occurs at time τ t for which from Axiom A1 we derive (trigger(O τs SecurityAadvise [CA] ,N),τ t ) and from the process aspect predicate we derive DHoldsAt predicate capturing the fluent provide brochures in the predicate that deontically holds at τ t , and process aspect attached to the fluent.
The details of Axioms A10 to A12 are, respectively, similar to the details of axioms for R2. The rule R5, on the other hand, prescribes a condition that only consultants with securities competence level C or above are permitted to provide investment advice to a customer. Here, it should be noted that handling permissions is one of the fundamental requirements for normative modelling and has been argued that any formal language not able to properly model permissions is doomed to capture real-life compliance requirements . In this regard, Governatori and Hashmi (2015) has extended DEC to cater this need by considering the dual relationship 5 between obligation and permission, that is, Oφ =∼P∼φ. Accordingly, the rule R5 can be modelled as follow: Next, the rule R6 prescribes an obligation that the customer identification and customer legitimation must be handled by customer advisor under normal circumstances. However, in case of suspected money laundering, it should be handled by anti-money laundering officer. This separation of duties (SoD) allows companies to streamline their employees according to their capabilities and experiences. Since rule R6 prescribe two separate provisions, we model the rule into two sub-rules as follows: Notice that from a business process execution perspective, R6 is a structural rule prescribing segregation of duty (SoD) constraint and implements a prohibition by assigning the activities to the relevant/appropriate personnel. Axiom A16 implements the prohibition as an obligation based on the duality relation between obligation and prohibition written formally as O∼φ = Fφ, meaning that if it is obligatory not to do φ, then it is prohibited to do φ (Sartor, 2005).
R7, on the other hand, expresses an exception in which customers advisor can conclude a custody account if a resolution of an unresolved money-laundering case is achieved. Essentially, it is important that the language can represent exceptions which in turn is required to correctly understand the distinction between strong and weak permissions 6 . In the legal domain, strong permissions express exceptions to obligations, i.e., derogating obligation with a permission provides an exception to prohibition Stolpe, 2010). In this case, R7 can be expressed as either a permission or a maintenance obligation where the permission represents the exception to the obligation as follows: In contrast, modelling the rule as a maintenance obligation of not concluding a custody account until a money-laundering case is solved represents a prohibition. It has been argued (Hashmi, 2015;Hashmi & Governatori, 2017;Hashmi et al., 2014Hashmi et al., , 2016) that maintenance obligations are suitable for representing prohibitions since maintenance obligations must be complied with for all the instants of the interval in which the obligation is in force.
R8 also prescribes a maintenance obligation which is followed as: The meaning of Axiom A19 is similar to the meaning of axioms for R7. Rule R9, on the other hand, presents interesting case of data and temporal and permission constraints which we model as below: The permission to ChargeAccountFee is represented as fluent by the permission fluent (P τs ChargeAccountFee) which deontically enters into force at time τ s . The event trigger(P τs Stockles sCustodyAccount [CU,CAD] ,N),τ t whose meaning is to initiate the permission to charge the account fee for stockless account, and when the fluent InvestmentAdvise deontically holds when event occurs at τ. The temporal and data process aspects conditions are attached to the fluent.

COMPLEXITy EVALUATION
In this section, we present the complexity evaluation of the ease in terms of efforts and time required to modelling the compliance rules using newly introduced process aspect predicates. For this purpose, we use Halstead Complexity Metrics (HCM) (Halstead, 1977), a well-known software performance and quality metric. We selected the Halstead metrics due to its flexible nature as the metrics can be used to measure the efforts needed to model compliance rules without modifying any existing parameters, which is not possible with other metric tools such as Cyclomatic Complexity and Reachability Matrix (McCabe, 1976) and information flow (Henry & Kafura, 1981). The HCM consists of unique operators and operands to measure the complexity of efforts to write compliance rules which are generally determined before the function can be computed. The operators in HCM cover the commands and program structuring elements such as parenthesis, brackets, commas, etc., whereas operands enumerate variables and consonants (Mendling, 2007;Zasada, 2019). The metrics evaluates the complexity of effort by computing the predicate length, volume, difficulty and effort and time required to model the rules through the formulas shown in Table 3.
Vocabulary (size),n = n 1 + n 2 (1) Predicate Length (size), N = N 1 +N 2 (2) Predicate Volume, V = N x log 2 n  (6) where n 1 and n 2 are the number of unique operators and operands (variables or constants), and N 1 and N 2 , respectively, are the sum of operators and operands occurrences in the program. They are defined as the parameters of complexity measurement before the start of computations.
In principle, the measure of complexity, i.e., the effort of modelling the compliance rules, is directly proportional to the size of operators and operands and the frequency with which they appear in the program. Besides, the metrics can also be extended to measure the correctness of a program with regards to the size, the level of abstraction of the program, and the number of errors delivered (Ferrer et al., 2013). Table 3 illustrate the operators and operands representing various elements of the compliance rules derived as per the following criteria: • Patterns, deontic modalities (i.e., norm types, modality operator etc.), tasks, triggers, events, gateways are enumerated for all flow objects. • Logical operators, sequences, message flows for connectives.
• Process aspects such as time, data and resources, etc., are counted for process aspects.
• No brackets included, and parenthesis enumerated as pairs. • Deontic modality and pattern enumerated per concrete rule.
Notice that HCM is not computed per language but per concrete program covering all characteristics of the language. Hence, the enumeration criteria have been derived based on the characteristics of the language as well as concrete compliance rules. Figure 2 show the HCM values computed for the DEC axioms modelled in Section 4. Given the stable levels of difficulty (D) and sizes (V) of predicate per concrete rule, the time (T) and efforts (E) of modelling the compliance rules relevant to the process aspects with DEC predicates fluctuates across the rules as shown in Figure 2(b). The average time and effort required to model a rule is E =2,751.23 and T =152.85 sec, which is relatively low. This clearly demonstrates that the complexity of modelling the compliance rules with DEC predicates is significantly lower even when the complexity of the standard EC is exponential assuming the relative time and partial order nature, and the precise semantics of the EC (Cervesato et al., 1994). Accordingly, on the rule level, from Figure 2(a) it can be seen that the minimum effort E =1,525.18 and time T =84.73 sec, and the maximum E =4,169.48 and T =231.64 sec, are computed for R1 and R3, respectively. For R1, it is lower because the rule prescribes simple flow related constraint and has not complex structure, thus it can be modelled with simple flow control constructs that is available in almost every modelling language (such as Event-Driven Process Chains (EPC) (Mendling, 2008), BPMN 7 ,etc.). In contrast for other rules, for example, R3 and R6 and R9, respectively, the time and effort to write the rule gradually increase. This is because these rules have complex structure and prescribe multiple process aspects conditions attached to the fluent increasing thus the difficulty of mdoelling the rules. To simplify the modelling process, we split complex rules into distinct DEC axioms. This leads to some axioms containing repetitive elements which increased the relative size (V) of rule. However, as discussed earlier, the size of efforts is directly proportional to the number of operators and operands, and the frequency with which they appear in the axiom. Hence, due to the increase in size of the rules, the time and efforts required to write the rules has been slightly increased, yet such efforts remain relatively small.

CONCLUSION
In this paper, we have extended DEC predicates to intuitively represent normative requirements related to the aspects which is one basic requirement to validate the compliant behaviour of business processes. The extended predicates are expressive and present low complexity in modelling the compliance requirements. At this point we have evaluated the textual complexity of the extended predicates in terms of efforts, difficulty and time required for modelling and the norms. We plan to implement this work to evaluate the efficiency in order to validate the computational complexity of the proposed predicates as the complexity analysis at this stage is relatively small. Moreover, in the context of this paper, we have used the notion of permission in a boarder sense and do make any distinction of the concepts. In literature, however, various classes of permissions exist. We plan to continue this work to address the issue of representing various cases of permissions and exceptions involving the process aspects with DEC. More specifically, we plan to create a catalogue of DEC pattern predicates for modeling types of permissions. On the same note, the scope of used process aspects such as data, resources, time, etc., and the compliance requirements are generic. However, these aspects are granular and may involve more complex process interaction patterns such as iteration, termination, force completion, triggering patterns, etc. We plan to investigate these aspects and develop a comprehensive catalogue of DEC predicate patterns covering compliance requirements about more complex process aspects. The workflow patterns proposed by Nick Russell et al. (2016) can be the starting point toward this direction.

Figure 2. (a) and (b) Halstead metric computations for DEC axioms
Another line of interest is to develop transformations of the proposed predicates such that (legal) norms pertaining business process aspects can be represented using LegalRuleML, and into its equivalent defeasible logic transformations. This can facilitate representing business contracts and performing reasoning about them in a more intuitive and declarative way. Besides, developing such transformations and applying them into some smart contract-based systems e.g., ethereum can extend the language of such systems in a way that users can make their smart contracts explicit and define them declaratively. The methodology proposed by Lam and Hashmi (2019) can be benefited for developing such transformations.

ADDITIONAL FUNDING INFORMATION
The publisher has waived the Open Access Processing fee for this article.
ACKNOWLEDGMENT I sincerely thank Dr Ho-Pun Lam for his sincere and fruitful discussions significantly improving the quality of this manuscript.