2.1 Answer set programming

ASP is a declarative paradigm for solving knowledge-intensive computational problems (Brewka et al., Reference Brewka, Eiter and Truszczyński2011; Gebser et al., Reference Gebser, Kaminski, Kaufmann and Schaub2012). The idea of ASP is to represent a problem as a logic program whose models, called answer sets (Gelfond and Lifschitz, Reference Gelfond and Lifschitz1991) correspond to the solutions. A normal ASP logic program Π is a finite set of rules r of the form:

$$ a_{1} :- a_{m+1}, \ldots, a_{n}, not \ a_{n+1}, \ldots, not \ a_{l}. $$

where each a _i is an atom of the form p(t ₁,…,t _k ) with p being a predicate symbol and t ₁, …, t _k terms. Atom a ₁ is called the head atom, head(r), while a _{m + 1} to a _n and not a _{n + 1} to not a _l are referred to as positive and negative body literals. The positive and negative sets of atoms (body ⁺(r) and body ⁻(r), respectively) compose the body of rule r, referred to as body(r). The informal meaning of a normal rule is that if the body is true, then so is the head. A rule r is called a fact if it consists of only one head atom and no body atoms. An integrity constraint r is a rule that contains no head atom. An integrity constraint r is satisfied if body(r) is false. By insisting that integrity constraints are satisfied in an answer set, they effectively rule out answer sets for which this is not the case. An expression is said to be ground if it contains no variables. Furthermore, in the original (non-ground) program, every normal rule or constraint r must be safe; that is, every variable which occurs in r must occur at least once in body ⁺(r). The logic operator not denotes negation as failure, allowing ASP to perform non-monotonic reasoning (Clark, Reference Clark1978). Aggregate functions, denoted as f(S), where S is a set and f can be #count, #min, #max, #sum, or #times, are represented as L _g $\prec$ ₁ f(S) $\prec$ ₂ R _g . Here, f(S) is the aggregate function, $\prec$ ₁, $\prec$ ₂ $\in$ {=,<,≤,>, ≥ }, and L _g (left guard) and R _g (right guard) are terms. Either L _g $\prec$ ₁ or $\prec$ ₂ R _g can be omitted, defaulting to ‘0” and “ + ∞” respectively (Faber et al., Reference Faber, Pfeifer, Leone, Dell’Armi and Ielpa2008). The standard semantics of aggregates include counting, finding the minimum and maximum, summing, and multiplying atoms in a multiset S.

Semantically, a logic program induces a set of stable models, being distinguished models of the program determined by the stable model semantics (Gelfond and Lifschitz, Reference Gelfond and Lifschitz1988). ASP systems like Clingo (Gebser et al., Reference Gebser, Kaminski, Kaufmann and Schaub2014) and DLV (Leone et al., Reference Leone, Pfeifer, Faber, Eiter, Gottlob, Perri and Scarcello2006) use a grounder to replace variables with constants and a solver to search for answer sets.

2.2 DMN

Decision model and notation (DMN) (Object Management Group, 2015) is a standardized modelling language and notation for expressing business rules. It is designed to be easy to use and understand by business experts (Silver and Sayles, Reference Silver and Sayles2016), while still being expressive enough to capture complex decision-making logic. DMN models consist of two main components: a decision requirements diagram (DRD) and one or more decision tables.

The DRD is a graphical representation of the overall structure and dependencies of a DMN model. It shows the connections between the various inputs, decisions, and knowledge sources that are used in the model, making it easier for end-users to interpret and understand the model (Hasić et al., Reference Hasić, Seng and Neureiter2017).

Fig. 1. Example of DMN table determining eligibility for holiday bonus.

Decision tables contain the detailed business logic that is used to make decisions. Each decision table consists of a number of input columns and at least one output column. Rows in the table specify the conditions under which a given output should be produced, based on the values of the input columns. A classical example of a decision table is shown in Figure 1. It defines whether an employee receives a holiday bonus based on their role in the company and the number of years they have worked at the company. The decision table has input columns for the employee’s role and the number of years they have worked, and an output column for whether they receive a bonus. Rows in the table correspond to different kinds of employees and specify for each kind whether they are eligible for a bonus. For example, a manager always receives a holiday bonus while a worker only receives one if they have worked for more than 3 years at the company.

Overall, DMN provides a user-friendly and intuitive way of expressing business rules and decision-making logic, making it well-suited for use in a variety of applications (Sooter et al., Reference Sooter, Hasley, Lario, Rubin and Hasić2019; Hasić and Vanthienen, Reference Hasić and Vanthienen2020). It has already been successfully used in many case studies and is becoming increasingly popular as a modelling language for decision management (Hasić et al., Reference Hasić, Seng and Neureiter2016).

2.3 Event calculus

The event calculus (EC) is a logical formalism used in artificial intelligence and knowledge representation to reason about events and their effects (Kowalski and Sergot, Reference Kowalski and Sergot1986). It is based on first-order logic and has a temporal component, allowing it to represent the changing state of a system over time. The EC has been applied to a wide range of AI tasks, including planning (Eshghi, Reference Eshghi1988; Shanahan, Reference Shanahan2000), cognitive robotics (Shanahan, Reference Shanahan1996, Reference Shanahan1999b), and legal reasoning (Kowalski, Reference Kowalski1995). It has also been used to model the effects of actions in multi-agent systems, allowing for the formalization and analysis of complex interactions between agents (Kowalski and Sadri, Reference Kowalski and Sadri1999). A complete EC model consists both of domain-independent and domain-dependent axioms. The general theory of how properties evolve through time is captured in the domain-independent axioms, which cover notions such as persistence and causality. The domain-dependent axioms, on the other hand, describe which actions affect which fluents under various circumstances in a certain domain and state when these actions do occur.

The original formulation of EC uses circumscription (McCarthy, Reference McCarthy1980), or the minimization of the extensions of predicates, to allow default reasoning. In particular, it reflects the assumptions that (1) the only events that occur are those known to occur and (2) the only effects of events are those that are known. The closed world assumption of most logic programming semantics, including the stable model semantics, allows the same assumptions to be incorporated in an arguably more elegant way. This makes ASP a very suitable formalism for implementing the EC.

Different variants of the EC have been proposed over the years; in this paper, we will use an implementation based on the functional event calculus (FEC) (Ma et al., Reference Ma, Miller, Morgenstern and Patkos2014a) and discrete event calculus (DEC) (Mueller, Reference Mueller2004a).

The FEC extends the EC with non-boolean fluents. This sets the EC on a par with formalisms such as the Situation Calculus in this respect. In the FEC, there are four sorts: A for actions (a, a ′, a ₁, …), F for fluents (f, f ′, f ₁, …), V for values (v, v ′, v ₁, …), and T for timepoints (t, t ′, t ₁, …). The key predicates and functions of the FEC are: Happens ⊆ A × T, ValueOf : F × T → V, CausesValue ⊆ A × F × V × T and PossVal ⊆ F × V. To describe the general relationship between these predicates, two auxiliary predicates are defined: ValueCaused ⊆ F × V × T, OtherValCausedBetween ⊆ F × V × T × T. Here, ValueCaused(F,V,T) means that some action happens at T that gives cause for F to take value V, and OtherValCausedBetween(F,V,T1,T2) means that some action happens at some point in the half-open interval [T1, T2) that gives cause for F to take a value other than V. Note that ‘gives cause” is a weaker notion than the standard ‘causes”: non-deterministic actions do not cause specific predictable effects. For example, rolling a die gives cause for each number to be shown, but we cannot predict which number will be shown. The FEC then consists of the following axioms:

(FEC1) \begin{equation} \text {ValueCaused} (f, v, t) \stackrel {\text {def}}{\equiv } \exists a \Big [\text {Happens}(a, t) \wedge \text {CausesValue}(a, f, v, t)\Big ]\end{equation}

(FEC2) \begin{multline} {\rm OtherValCausedBetween}(f, v, t_1, t_2) \stackrel{{\rm def}}{\equiv }\\ \exists t, v_0 \Big [{\rm ValueCaused}(f, v_0, t) \wedge t_1 \leq t < t_2 \wedge v \neq v_0 \Big ] \end{multline}

(FEC3) \begin{multline} \left [\left ({\rm ValueOf} (f, t_1)=v \vee {\rm ValueCaused}(f, v, t_1)\right ) \wedge t_1 < t_2 \right .\\ \left .\wedge \neg {\rm OtherValCausedBetween}(f, v, t_1, t_2)\right ] \Rightarrow {\rm ValueOf} (f, t_2)=v \end{multline}

(FEC4) \begin{multline} \left [t_1 < t_2 \wedge {\rm OtherValCausedBetween}(f, v, t_1, t_2) \wedge \right . \\ \quad \left . \neg \exists t(t_1 \leqslant t < t_2 \wedge {\rm ValueCaused}(f, v, t))\right ] \Rightarrow {\rm ValueOf} (f, t_2) \neq v \end{multline}

(FEC5) \begin{equation} \text {ValueOf} (f, t)=v \Rightarrow \text {PossVal}(f, v) \end{equation}

The notions of cause, effect, and inertia are captured in the first two FEC axioms. Axiom (FEC3) states that a fluent has a particular value at a particular time if (i) it already had that value at an earlier time or (ii) was given cause to take that value from an earlier time, and in the meantime (including that earlier time) nothing has happened that might give cause for it to take an alternative value. Conversely, (FEC4) states that fluent f cannot have value v at time t ₂ if its most recent causal influences prior to t ₂ do not include a cause for v. Finally, (FEC5) additionally constrains each fluent’s value to be at all times among the set of values defined by PossVal.

The DEC is a version of the EC that models time as a discrete quantity, with events happening at specific points in time (Mueller, Reference Mueller2004a). In the DEC, the duration of events is not represented and events are assumed to happen instantaneously. This makes the DEC well-suited for modeling systems where the duration of events is not important.

3.1 ASP implementation DFEC

In the context of a limited domain, the integration of EC and DEC formulas into ASP programs is feasible, as demonstrated by Kim et al. (Reference Kim, Lee and Palla2009). They showed that it is possible to embed circumscriptive theories into stable models, and thus that ASP is a viable approach to computing circumscriptive theories like EC. Our implementation of the DFEC axioms in ASP, shown in A, is closely related to their implementation of the DEC axioms.

The DFEC implementation is designed to yield, at most, one solution. This deterministic outcome is rooted in the stratified nature of the DFEC. Specifically, when provided with a coherent set of fluents, actions, and effects, the DFEC implementation guarantees there is precisely one solution. A normal logic program Π is stratified if there exists a level mapping f assigning each ground predicate symbol a natural number such that, for every rule r $\in$ Π and every predicate P ₁ and P ₂,

1. 1. if P ₁ occurs in head(r) and P ₂ occurs in body ⁺(r) then f(P ₁) ≥ f(P ₂);

2. 2. if P ₁ occurs in head(r) and P ₂ occurs in body ⁻(r) then f(P ₁) > f(P ₂).

To prove that the ASP implementation of the DFEC is stratified, we introduce such a level mapping. Assigning a level is based on the structure of each atom in the program. Specifically, atoms of the form stoppedIn(J,F,V,I) or startedIn(J,F,V,I) are assigned level I. Atoms of the form initiated(F,V,I), terminated(F,V,I), releasedAt(F,V,I) and valueOf(F,V,I), are assigned level I + 1, while all other atoms are assigned level 0. It can be easily confirmed that this mapping is correct. As an example, consider axiom (DFEC6). In this rule, the level of the head T1 + T2 + 1 is demonstrated to be greater than or equal to the level T1 of the positively occurring atom initiated(F1,V1,T1). Moreover, it is strictly greater than the level of the negatively occurring atom

stoppedIn(T1,F1,V1,T1+T2). Similar verification can be conducted for the remaining axioms, thereby establishing the correctness of the level mapping. The level mapping of the DFEC implementation is provided in B.

4.1 Temporal logic

Some of the domain knowledge that the consultants need to express concerns temporal properties. For instance, overtime starts after an employee has been working for 8 h. We represent such knowledge using the following simple linear time logic:

• An atomic temporal formula is of the form f = v, with f a fluent and v a value from the domain of f;

• If $\phi$ and $\psi$ are temporal formulas, then so are $\phi$ ∧ $\psi$ and $\lnot\phi$ ;

• If $\phi$ is a temporal formula and n $\in \mathbb{N}$ , then [≥n] $\phi$ is a temporal formula, which intuitively represents that $\phi$ has been true for at least the n most recent time points, including the present one.

Given a time line T = (I ₀,I ₁,…) and a time point i ≥ 0, we define that a temporal formula $\phi$ holds in (T,i), denoted as (T,i) ⊨ $\phi$ , as follows:

• For an atomic temporal formula, (T,i) ⊨ f = v if f ^{I _i} = v that is the value of fluent f in the state of the world I _i at time point i is equal to v;

• For a conjunction $\phi$ ∧ $\psi$ , (T,i) ⊨ $\phi$ ∧ $\psi$ if (T,i) ⊨ $\phi$ and (T,i) ⊨ $\psi$ ;

• For a negation $\lnot\phi$ , (T,i) ⊨ $\lnot\phi$ if (T,i) $\nVDash$ $\phi$ ;

• For [≥n] $\phi$ , (T,i) ⊨ [≥n] $\phi$ if i ≥ n and for all i − n < j ≤ i, (T,j) ⊨ $\phi$ .

We also introduce an abbreviation [=n] $\phi$ for the formula [≥n] $\phi$ ∧ $\lnot$ [≥n+1] $\phi$ . As we will show in Section 5.2, this temporal logic is easily defined in ASP.

4.2 Interval logic

The wages of employees are not defined in terms of individual timepoints but in terms of intervals. The consultants can define which fluents are considered relevant for the wages of employees. Within an interval, all the relevant fluents keep their value, that is the boundaries of the interval are timepoints at which the value of a relevant fluent changes. We consider half-open intervals [i,j) where i is a timepoint at which the value of a relevant fluent changes and j is the next such timepoint. An interval property describes a characteristic of an interval. It is either a relevant fluent f, or an aggregate function like length. We denote the value of an interval property p in an interval [i, j) as p ^{[i, j)}. Given a timeline T = (I ₀,I ₁,…), we define this value in the following way:

• For a relevant fluent f, f ^{[i, j)} = f ^{I _i} , that is, the value of fluent f at the start of the interval. Because f is a relevant fluent, this is also the value that f has in all following I _k for k $\in$ [i, j).

• For the aggregate function length, length ^{[i, j)} = j − i.

In addition to interval properties, we also define interval terms. An interval term is an expression that refers to a specific interval. The atomic interval term this refers to the current interval. For an interval term t, next(t) refers to the next interval, and prev(t) to the previous one. Given a sequence of intervals $S = (\mathcal{I}_0, \mathcal{I}_1,\ldots)$ , we define $\mathit{this}^{(S,i)} = \mathcal{I}_i$ and for every interval term t with $t^{(S,i)} = \mathcal{I}_j$ , we define $next(t)^{(S,i)} = \mathcal{I}_{j+1}$ and $prev(t)^{(S,i)} = \mathcal{I}_{j-1}$ .

An interval value is then of the form [t]p and refers to the value of the interval property p for the interval that is indicated by the interval term t. We define this value as [t]p = p ^{t (S,i)} . We define an atomic interval formula as vθw where v and w are two interval values and θ is a comparison operator. Finally, we combine these atomic interval formulas with the standard boolean operators, as usual.

5.1 Discrete functional event calculus

The core of our generic model is an implementation of the simplified version of the DFEC described in Section 3. The timeline considered in our model consists of a number of discrete timepoints 0..n, represented by the time(T) predicate. Each timepoint corresponds to a certain duration in wall-clock time. For the moment, we consider timepoints that are 10 mins long. The ts(Days, Hours, Minutes, Stamp) predicate links a duration expressed in real-world Days, Hours and Minutes to the corresponding timepoint Stamp (lines 2–5).

The situation of the employee at a certain time point is described by a complete set of fluents. Fluents have a domain of possible values. An example is the boolean fluent present, which indicates whether the employee is currently clocked in. At each point in time, a fluent has a certain value, as represented by the predicate value(F,V,T). At timepoint 0, the fluent’s value is specified by the initially(F,V) predicate. The cause(F,V,T) predicate represents that at timepoint T there is a cause for the value of F to change to V, which leads to the current value of F being terminated at T + 1 and the value V being initiated (lines 11–14).

The only reason for a fluent to change is because an action changes it. In general, the effect of an action may depend on the state of the world at the time the action occurs. However, for the moment, we will consider only actions that have the fixed effect of causing a Fluent to take on a specific Value, as represented by the causes(Action,Fluent,Value) predicate on line 21. For now, we define 2 types of actions. A user action is an action that is performed by the user in an intentional way (i.e., the employee). A wall-time action happens at a specific wall-clock time. Both wall-time actions and user actions thus happen at a given absolute time, represented by the userDoes(A,T) and actionTime(A,T) predicates.

With these concepts, we now represent the case-specific knowledge in an easy-to-read tabular representation. The case-specific knowledge for our running example is shown in Figure 4. Each table enumerates a single predicate, for example the first table corresponds to the initially(F,V) predicate, etc.

Fig. 4. Case-specific representation of a basic scenario.

5.2 Conditional effects

The effect of an action may depend on the current state of the world. We describe such a conditional effect with a ccauses(Action, Fluent, Value, Condition) predicate.

Conditions are formatted in the temporal logic of Section 4.1. In the tables, we use a slightly more user-friendly syntax, writing, for example

$$ f1=v1 \wedge [=n] f2=v2 \quad \text {as} \quad f1=v1\ and\ f2 = v2 \ since\ n. $$

In our ASP implementation, we represent each such condition as a set of facts. For instance, the above condition cond1 is represented as follows:

Here the and(C,N) predicate denotes that condition C is a conjunction of N sub-conditions, each represented by a sub(C,I,SC) fact, with 0 ≤ I < N. The holds(Cond,T) predicate specifies whether a condition Cond holds at a certain timepoint T. For Cond = v(F,V), we just check whether Fluent F has Value V (line 25). Cond = since(F,V,D), representing whether a fluent F has had a value V for D timepoints, is defined by two rules. The first rule states that the initiation of V for F at T − 1 marks timepoint T as the start of a period in which F has value V (line 26). The recursive rule on line 27 extends such a period with one timepoint if F still has value V at T. Finally, if Cond is a conjunction, we check whether the number of conjuncts that hold at T matches its total number of conjuncts N (line 28).

We can now represent scenarios where these conditional effects come into play in the tabular representation. In the first table of Figure 5, we specify that a shift starts if an employee clocks in when the workday has already started or when the day starts and the employee is already clocked in.

Fig. 5. Case-specific representation of conditional effects and triggered actions.

5.3 Automatically triggered actions

An action can also be automatically triggered if a certain temporal condition is fulfilled. To specify that an employee’s break is paid as an (official) rest break after their shift has lasted for one hour, we specify an action makeRestBreakPossible, which causes fluent restbreakPossible to be true. Such actions are not performed by the user but happen automatically after a certain fluent F has had a certain value V for a specific duration D, as represented by an after(F,V,D,A) predicate (line 31). Figure 5 represents triggered action makeRestBreakPossible in our tabular form.

5.4 Defined fluents

To avoid repeated use of complex fluent formulas, we introduce defined fluents as defined by Denecker and Ternovska (Reference Denecker and Ternovska2007) and used in action languages like $\mathcal{AL}_d$ (Gelfond and Inclezan, Reference Gelfond and Inclezan2009). The value of a defined fluent is completely determined by the values of the other fluents. Therefore, they provide no additional information about the state of the world; they simply make it easier to track its properties. The value of a defined fluent is defined by a set of rule(F,V,C) facts: if condition C holds, the defined fluent F has the value V (line 32). To cover the case that no rules are applicable, each defined fluent must have a default value (line 33). We do not allow fluents to be defined by negated predicates, therefore there are no cycles in our solution. As stated by Gelfond and Inclezan (Reference Gelfond and Inclezan2013), acyclic behaviour arises when there are no paths from defined fluents to their negations. Given that acyclic behaviour is a sufficient condition for well-foundedness, we can deduce that our defined fluents will consistently have, at most, one value.

For example, to indicate whether an employee is working, we introduce the defined fluent atWork = true if and only if the inertial fluents present and shiftStarted are true. Figure 6 represents this in our tabular representation.

Fig. 6. Case-specific representation of defined and count fluents.

5.5 Count fluents

An employee receives a bonus for any overtime done after they have already worked eight hours. This can be modelled with a third type of fluents, the count fluents. These fluents keep track of the past states of the world by counting the foregoing timepoints in which a certain condition holds, upon a certain timepoint. Each count fluent is defined by a rule of the form countRule(CF,Cond), which specifies that the fluent CF counts the timepoints at which the condition Cond holds (lines 36–39).

In Figure 6, we define the count fluent workedHours, which, at each timepoint, keeps track of how long the fluent atWork has been true up to that point.

Count fluents can also trigger actions. The predicate when(CF,V,A) states that if count fluent CF reaches a certain value V, an action A is triggered. To make sure that an action is not triggered multiple times if the desired value is maintained for multiple timepoints, we state that the value of the count fluent in the previous timepoint should be smaller than the desired value (line 40).

For example, the overtime bonus is applied by triggering an action cumulPremiumAction after eight hours of work. Figure 7, adds this triggered action and its effect to the existing tables for triggered actions and effects (Figures 4 and 5). Note that conditions specifying that a fluent F has had a value V for a duration D are translated in ASP as an after(F,V,D,A) predicate and those that specify value V for a count fluent CF are translated as a when(CF,V,A) predicate.

Fig. 7. Extended case-specific representation of triggered actions and effects.

Fig. 8. Case-specific representation of relevant fluents.

5.6 Reasoning about intervals

Up to now, we have only reasoned about individual timepoints. To calculate the total wages of employees we consider intervals. As described in Section 4, within intervals all of the ‘relevant” fluents keep their value. By restricting attention to only the relevant fluents, we avoid creating too many small intervals. A relevant fluent is annotated by the relevant(Fluent) predicate. We denote the relevant fluents by introducing a new column in the inertial and defined fluent table (Figures 4 and 6), as can be seen in Figure 8. The boundaries of intervals are those timepoints at which the value of at least one relevant fluent changes (lines 41–42).

To define the intervals, we assign an id to each boundary. The intervals are of the form [B(i), B(i+1)), where B(i) denotes the boundary with id i. The stretchesTo(Id,T) predicate denotes that interval Id includes timepoint T. We model this with two rules. The first one states that if the interval includes the previous timepoint T − 1 and timepoint T is not a boundary then the interval includes T as well (line 47). Boundaries themselves are included in the time interval that they start (line 48). Timepoint T is thus a boundary of time interval I + 1 if timepoint T − 1 is included in the previous interval I and T is a boundary (line 46). A boundary thus denotes the start of an interval (intervalFrom(Id,From) predicate) and the end of the previous interval (intervalTo(Id,To) predicate) (lines 44–45).

In principle, there could be as many intervals as there are timepoints. Typically, there will be far fewer. To speed up the program, we assume an upper bound of at most 20 intervals. We require that the final interval id be not used. If this ever happens, the upper bound should be increased. Next, as described in the interval logic of Section 4.2, we define interval terms, such as prev(this) in lines 55 to 57.

To clearly track the characteristics of the interval and avoid repeated use of complex interval formulas, we introduce defined interval properties. The value of a defined property is specified by a set of intRule(P,V,C) facts. If the condition C holds in the current interval, the defined property P has the value V (line 72). These conditions are formatted in the interval logic of Section 4.2. The intHolds(Cond,Id) predicate specifies when a condition for an interval holds. To check whether a condition holds, we define the value of the properties described in the interval logic of Section 4.2. A valueOfProp(P,V,Id) predicate denotes that an interval property P has value V in interval Id. If P is a relevant fluent, this is simply the case if this fluent has that value (line 58). If P = length, its value is the length of interval Id (lines 60–62). The value of an interval atom [IntTerm]P, which we denote in ASP as at(IntTerm,P), is the value of a property P in the interval that IntTerm refers to. We define when two such atom values are equal (line 65), when one atom value is smaller than another (line 69), and when an atom value has a certain value from its domain (line 67). Finally, a conjunction C holds in an interval, if all N of its conjuncts, specified by the iand(C,N) predicate, hold (lines 70–71).

In Figure 9, to specify the wages in a certain interval, we introduce some defined properties. The normalwage property is 20 euros if an employee is working, and 0 if they are not. They receive a nightpremium of 20% for any interval in the night or in the day if the interval precedes an interval in the night, provided that the night interval is larger. Finally, the employee receives an cumulPremium of 25%. Note that compared to the interval logic of Section 4.2 we omit the interval term this in our tables to improve readability.

Fig. 9. Case-specific representation of relevant fluents and output.

5.7 Calculating the total wages

In general, our goal is to compute the wages as a sum $\sum _{interval\ i} totalWage(i)$ with the totalWage property determining the hourly wage in each interval. We translate this to an ASP sum as follows:

In total, an HR consultant only needs 10 tables to specify the specific rules. A concrete scenario can be represented as the single-user action table.

6.1 Static code

The static part of the code contains the non-temporal information, which consists of rules that contain no predicates with a timepoint argument. For example, in the last code listing of the Functional EC paragraph in Section 5.1, the first two lines, which state that user actions and walltime actions are two kinds of actions, are included in the static part, while the last two rules, which define at which timepoints such actions happen, does not. We collect the static code in a subprogram #static(), that takes no parameters.

6.2 Dynamic code

The dynamic program defines the current state of the world in terms of the previous state. It therefore takes two changepoints as parameters. The program first asserts that the current changepoint cp is a new timepoint, which follows the previous changepoint pp. In addition to this, the dynamic program also contains all rules that include predicates that take a timepoint as an argument. These rules typically define the value of some dynamic predicate at T + 1 in terms of the values of dynamic predicates at timepoint T. Such rules now undergo a minor syntactic change, where we replace all such terms T + 1 by the parameter cp of the program and the terms T by its parameter pp. In effect, this change is what allows us to ‘skip ahead” to the next changepoint, instead of having to go through each timepoint individually. This necessitates a number of other small changes in the code, documented online,Footnote ¹ the specifics of which we will not describe in detail.

6.3 Multi-shot solving algorithm

Algorithm 1 shows how the static and dynamic programs can be used to implement the desired behavior, employing clingo’s multi-shot solving. This algorithm uses the following notations: For a program P(x ₁,…x _n ) with parameters x _i and constants c ₁, …, c _n , we denote by AnswerSet(P(c ₁,..,c _n )) the unique answer set of P(c ₁,…,c _n ). For a predicate p, we denote by p ^X the set of all tuples $\vec{c}$ such that $p(\vec{c}) \in X$ .

Algorithm 1 Solving algorithm

At line 1, the static program P _static , is solved. Its answer set provides the upper-bound max of the timeline and the list upfrontPoints of all changepoints that are already known up-front, that is all the time points at which wall-time actions or user actions happen. We also include the greatest time point max in this list, to ensure termination of the while-loop (line 6). In each iteration, this loop instantiates the dynamic program P _dynamic for the next changepoint. The if-test (line 8) distinguishes two cases: either the next changepoint comes from the list upfrontPoints, or else it corresponds to a triggered action. The next timepoints at which such a triggered action occurs are not known up-front but are computed in each iteration of this loop by the function searchNext.

The searchNext algorithm (Algorithm 2) considers both actions that are triggered by a fluent maintaining its value for a certain time, represented by the after-predicate (line 3), and those triggered by a count fluent reaching a certain value, represented by the when-predicate (line 8). The result of the algorithm is the smallest timepoint next > current at which such an action happens (or ∞ if no such timepoint exists). Once the main while-loop of Algorithm 1 ends, the program P _dynamic has been grounded for all changepoints. The predicate boundary now identifies all the timepoints that delineate an interval. The for-loop in line 16 then introduces an identifier i for each such interval [b _i , b _{i + 1}). Finally, these intervals are then passed to the program #intervals, which gathers all of the rules concerning intervals, unchanged from our single-shot implementation.

Algorithm 2 searchNext algorithm

In our solution, we organized our logic program into three distinct modules: static, dynamic, and interval. Importantly, we ensured the independence of these modules by strictly confining the definition of predicates within each module. Even for the dynamic module undergoing iterative grounding and solving with the current and previous changepoint, this principle holds. The introduction of the ’current < possible’ constraint in the searchNext algorithm guarantees a logical sequence, where each changepoint is always greater than the previous one. Since there are no head predicates inferred for both the previous and current changepoint within the same iteration, this design ensures that no ground literals are inferred across different iterations. Our approach aligns with the principles outlined in the module theorem, as described in Section 2.