1 / 11

Suitcase example

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). Abortion Example.

chipo
Télécharger la présentation

Suitcase example

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. AbortionExample • 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).

More Related