An Event-Condition-Action Logic Programming Language

1. An Event-Condition-Action Logic Programming Language J. J. Alferes F. Banti A. Brogi

2. Overview • Event Condition Action (ECA) languages. • Updates of (ECA) rules. • Dynamic Logic Programs (DyLPs). • Evolving Reactive Algebraic (ERA) Programs. • Syntax • Semantics • Example of usage. • Parallel with DALI. • Future works.

3. Event Condition Action languages • Fundamental construct: ECA rules On Event if Condition do Action • When an Event occurs, under some Conditions, execute a given Action. • Example On callE(Call,Emp) if office(Emp, N) do forw(Call,N). • Events and Actions can be simple or complex, resulting from the combination of basic ones.

4. Updates of ECA rules. • Problem: • How to update the behaviour of an ECA System? • Example: • Suppose that, whenever an employer is in a working meeting, the phone call must not be forwarded to him. • Solution: • To allow the system to assert new rules and to encode exceptions to existing ECA rules. • Inhibition rules: Rules that specifies when actions are not executed. • Example: When callE(Call,Emp), meeting(Emp,) do not forw(Call,N).

5. Logic Programs Updates • We consider sequences P1, ... , Pn (Pi) of LPs called Dynamic Logic Programs (DLPs) • P1 is the initial program, while the others Pis are updates • Basic language: generalized logic programs • The head of a rule can be either a positive or negative literal. • Common ideas: • Stable model approach • Causal rejection principle: A rule isrejected iff there is a more recent rule whose body is satisfied and is in conflict with the old one. (i.e. the two rules has complementary heads).

6. Syntax of ERA • ECA rules: On Event if Condition do Action • Data and inference rules: L. L0 ← L1, …Ln. • Every Li is an atom or the negation of an atom. • Inhibition rules: When B do not Action. • B is a conjunction of literals and events. • Event is a literal representing a simple or complex event. • Complex event are obtained by an algebra of operators. • Condition is a conjunction of literals. • Action is an atom representing a simple or complex action. • Complex actions are obtained by an algebra of operators.

7. Syntax of ERA Syntax of events: e::= eb |e1٧ e2| e1٨ e2| A(e1, e2,e3)| edef. • Syntax of basic and complex actions: ab::= ax| raise(eb)| assert(r)| retract(r)| define(d). a::= ab| a1► a2 | a1||a2 | IF(C, a1, a2) | adef. • Event and action definitions: edef is e. adef is a.

8. Semantics of ERA • Events are atoms occurring in LP Ei called input programs and represent external inputs and internal events. • Inference system based on the refined semantics of DyLPs. • If an atom “Action” corresponding to an action is inferred, the corresponding action is executed. • Replace On Event if Condition do Action with: Action ← Condition, Event. • Replace When B do not Action with: not Action ← B. • Replace edef is eandadef is a with: adef ← e and edef ← e.

9. Semantics of ERA(cont.) • Add inference rules for deriving literals: e1٧ e2← e1. e1٧ e2← e2.e1٨ e2← e1,e2. • The semantics of actions is given by a transition system describing step by step how the execution of an action affects a program. • The execution of a complex action may require several steps formed by basic actions. < P, Ep, Ei.EF> → G <P’, Ep’..Ei, EF’>

10. Example On callE(Call,Emp) if office(Emp, N) do forw(Call,N). assert(r) r : When callE(Call,emp), meeting(emp) do not forw(Call,N). • New behaviour: every call to emp is forwarded to his mobile phone. assert(r1) ►assert(r2). r1: When callE(Call, emp) do not forw(Call, N). r2 : On callE(Call,emp), mobile(emp,m) do forw(Call,m). Return to previous behaviour: retract(r1) ►retract(r2).

11. Related work: DALI • Dali is a LP-like language for programming agents. E:> Cond, A1, A2,…,An. A1:> Cond, A3, A4, ... A1:> A5, A6,…. • It is possible to define complex actions. • E is always a basic event, no event algebra. • It is not possible to update rules. • Unlike ERA, DALI is implemented.

12. Future works • Transaction ERA. • To provide the possibility to execute actions as transactions. • Local transactions are ACID. • Transactions involving external iterations relays on compensation. • Possibility to use ACID sub-transactions and compensation in the same transaction.

13. Thanks!

14. Future works • A dynamic rule is of the form effect(F ← Body)← Cond. • It means: if Cond is true in this state, then F ← Body is a rule in the next state (and only in that one). • Cond are conjunctions of fluent or action literals. • effect(F ← Body) ← Cond is a macro for: F ← Body, event(F ← Body). assert(event(F ← Cond). ) ← Cond. assert( not event(F ← Cond). ) ← event(F ← Cond) , not assert(event(F ← Cond)). • An inertial declaration is of the form inertial(I) ,where I is a set of fluents which means: all the fluents in I are inertial, i.e. their truth value is preserved from one state to the next one unless changed by the effect of an action. • Inertial(I) is a macro for: assert(prev(F)) ← F. assert(not prev(F)) ← not F.

15. Example: The Yale shooting problem • There is a single-shot gun which is initially unloaded, and some turkeys. • We can load the gun and shoot to one of the turkeys. If we shoot, there is a bang, the gun becomes unloaded, we can hit the turkey or miss it, if we hit a turkey it dies. • A turkey moves iff it is alive. I: initialize{loaded, moving(X),dead(X) missed(X), hit(X)} D: effect(loaded.) ← load. inertial (loaded) effect(not loaded.) ← shoot(X). inertial (dead(X)) effect (bang.) ← shoot(X). moving(X) ← not dead(X). effect(hit(X) ← not missed(X) ) ← shoot(X). dead(X) ←hit(X). effect (missed(X) ← not hit(X) ) ← shoot(X).

16. Comparisons with other works • We compared EAPs with the existing action description languages A , B and the (definite fragment of) C . • For every language we find a linear and modular translation into EAPs: • Hence EAPs are at least as expressive as the considered languages.

17. Describing changes • In practical situations, it may happen that the very rules of the domain change with time • EAPs are of Evolp programs. So, they can be updated by external events. • It is possible to update static rules and the descriptions of the effects of an action. • We consider again the Yale shooting problem. • Let us now consider that after some shots, we acquire rubber bullets. We can now either load the gun with normal bullets or with a rubber bullet, if we shoot with a rubber loaded gun, we never kill a turkey. E2: assert(D1) Inertial(rubber_loaded) E1: assert(initialize (rubber_loaded)) D1: effect (not dead(X) ← hit(X)) ← rubber _loaded. effect (not rubber _loaded) ← shoot(X).

18. Describing changes (cont.) • We use a new macro construct not effect(r) to prevent the effects of an actions under some conditions • Suppose the cylinder of the gun becomes dirty and, whenever one shoots, the gun may either work properly or fail. • If it fails the shoot action has no real effect. E2: assert(D2) not bang ← fails. not missed(X) ← fails. not hit(X) ← fails. E1: assert(initialize{ fails, work}) D2: effect (fails ← not work.) ← shoot(X). effect (work ← not fails.) ← shoot(X). effect (loaded ← fails.) ← loaded. effect(rubber_loaded ← fails) ← rubber_ loaded. effect(loaded←fails)← loaded.

19. Conclusions • Starting for the language for LP updates Evolp, we have defined the new action description language EAPs. • We have shown how to use EAPs by an example. • We have compared EAPs with existing work by showing translations of action languages A , Band Cinto EAPs. • We have shown peculiar capabilities of EAPs to handle changes in the rules of the considered domain and provided an example of such usage.