Download A Principled Semantics for Logic Programs Updates

An Event-ConditionAction Logic
Programming
Language
J. J. Alferes F. Banti A. Brogi
1
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.
2
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.
3
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).
4
Logic Programs Updates

We consider sequences P1, ... , Pn (Pi) of LPs called
Dynamic Logic Programs (DLPs)


Basic language: generalized logic programs


P1 is the initial program, while the others Pis are updates
The head of a rule can be either a positive or negative literal.
Common ideas:


Stable model approach
Causal rejection principle: A rule is rejected 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).
5
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.
6
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.
7
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 e and adef is a with:
adef ← e and edef ← e.
8
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’>

9
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).
10
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.
11
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.

12
Thanks!
13
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.
14
Example: The Yale shooting
problem

There is a single-shot gun which is initially unloaded,
and some turkeys.


I:
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.
initialize{loaded, moving(X),dead(X) missed(X), hit(X)}
D: effect(loaded.)
← load.
effect(not loaded.)
← shoot(X).
effect (bang.)
← shoot(X).
effect(hit(X) ← not missed(X) ) ← shoot(X).
effect (missed(X) ← not hit(X) ) ← shoot(X).
inertial (loaded)
inertial (dead(X))
moving(X) ← not dead(X).
dead(X) ←hit(X).
15
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.
16
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.
E1: assert(initialize (rubber_loaded))
D1: effect (not dead(X) ← hit(X)) ← rubber _loaded.
effect (not rubber _loaded) ← shoot(X).
E2: assert(D1)
Inertial(rubber_loaded)
17
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.

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.
E2: assert(D2)
not bang ← fails.
not missed(X) ← fails.
not hit(X) ← fails.
18
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 , B and C
into 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.
19