1. Suitcase example A suitcase has two latches, and is opened whenever both are up: open ← up(l1), up(l2) There is an action of toggling applicable to each latch: assert(up(X)) ← not up(X), toogle(X) assert(not up(X)) ← up(X), toogle(X)

2. Abortion Example Once Republicans take over both Congress and the Presidency they establish the law stating that abortions are punishable by jail assert(jail(X) ← abortion(X)) ← repCongress, repPresident Once Democrats take over both Congress and the Presidency they abolish such a law assert(not jail(X) ← abortion(X)) ← not repCongress, not repPresident Performing an abortion is an event, i.e., a non-inertial update. –I.e. we will have events of the form abortion(mary)… The change of congress is inertial –I.e. The recent change in the congress can be modeled by the event assert(not repCongress)

3. Twice fined example A car-driver looses his license after a second fine. He can regain the license if he undergoes a refresher course at the drivers school. assert(not license ← fined, probation) ← fined assert(probation) ← fined assert(licence) ← attend_school assert(not probation) ← attend_school

4. Bank example An account accepts deposits and withdrawals. The latter are only possible when there is enough balance: assert(balance(Ac,B+C)) ← changeB(Ac,C), balance(Ac,B) assert(not balance(Ac,B)) ← changeB(Ac,C), balance(Ac,B) changeB(Ac,D) ← deposit(Ac,D) changeB(Ac,-W) ← withdraw(Ac,W), balance(Ac,B), B > W. Deposits and withdrawals are added as events. E.g. –{deposit(1012,10), withdraw(1111,5)}

5. Bank examples (cont) The bank now changes its policy, and no longer accepts withdrawals under 50 €. Event: assert( not changeB(Ac,D) ← deposit(Ac,D), D < 50) ) Next VIP accounts are allowed negative balance up to account specified limit: assert( changeB(Ac,-W) ← vip(Ac,L), withdrawl(Ac,W), B+L>W ).

6. Email agent example Personal assistant agent for e-mail management able to: –Perform basic actions of sending, receiving, deleting messages –Storing and moving messages between folders –Filtering spam messages –Sending automatic replies and forwarding –Notifying the user of special situations All of this may depend on user specified criteria The specification may change dynamically

7. EVOLP for e-mail Assistant If the user specifies, once and for all, a consistent set of policies triggering actions, then any existing (commercial) assistant would do the job. But if we allow the user to update its policies, and to specify both positive (e.g. “…must be deleted”) and negative (e.g. “…must not be deleted”) instances, soon the union of all policies becomes inconsistent We cannot expect the user to debug the set of policy rules so as to invalidate all the old rules (instances) contravened by newer ones. Some automatic way to resolve inconsistencies due to updates is needed.

8. EVOLP for e-mail Assistant (cont) EVOLP provides an automatic way of removing inconsistencies due to updates: –With EVOLP the user simply states whatever new is to be done, and let the agent automatically determine which old rules may persist and which not. –We are not presupposing the user is contradictory, but just that he keeps updating its profile EVOLP further allows: –Postponed addition of rules, depending on user specified criteria –Dynamic changes in policies, triggered by internal and/or external conditions –Commands that span over various states –…

9. An EVOLP e-mail Assistant In the following we show some policy rules of the EVOLP e-mail assistant. –A more complete set of rules, and the results given by EVOLP, can be found in the corresponding paper Basic predicates: –New messages come as events of the form: newmsg(Identifier, From, Subject, Body) –Messages are stored via predicates: msg(Identifier, From, Subj, Body, TimeStamp) and in(Identifier, FolderName)

10. Simple e-mail EVOLP rules By default messages are stored in the inbox: assert(msg(M,F,S,B,T)) ← newmsg(M,F,S,B), time(T), not delete(M). assert(in(M,inbox)) ← newmsg(M,F,S,B), not delete(M). assert(not in(M,F)) ← delete(M), in(M,F). Spam messages are to be deleted: delete(M) ← newmsg(M,F,S,B), spam(F,S,B). The definition of spam can be done by LP rules: spam(F,S,B) ← contains(S,credit). This definition can later be updated: not spam(F,S,B) ← contains(F,my_accountant).

11. More e-mail EVOLP rules Messages can be automatically moved to other folders. When that happens (not shown here) the user wants to be notified: notify(M) ← newmsg(M,F,S,B), assert(in(M,F)), assert(not in(M,inbox)). When a message is marked both for deletion and automatic move to another folder, the deletion should prevail: not assert(in(M,F)) ← move(M,F), delete(M). The user is organizing a conference, assigning papers to referees. After receipt of a referee’s acceptance, a new rule is to be added, which forwards to the referee any messages about assigned papers: assert(send(R,S,B1) ← newmsg(M1,F,S,B1), contains(S,Id), assign(Id,R)) ← newmsg(M2,R,Id,B2), contains(B2,accept).