MINERVA – A Dynamic Logic Programming Agent Architecture

1. MINERVA – A Dynamic Logic Programming Agent Architecture João Alexandre Leite, José Júlio Alferes, Luís Moniz Pereira Centro de Inteligência Artificial (CENTRIA) Universidade Nova de Lisboa, Portugal Presented by Ian Strascina 3/8/04

2. Agents • Agents commonly implemented by imperative languages – efficiency • Efficiency not always critical, but clear specification and correctness is • Thus Logic Programming and Non-Monotonic Reasoning (LPNMR) are being (re)evaluated for implementation

3. LPNMR • Provide abstract, generalized solutions to accommodate different problem domains • Strong Declarative & Procedural Semantics – bridges gap between theory and practice. • Several powerful concepts: belief revision, inductive learning, preferences, etc. • The combination of these can allow for a mixture of agents with reactive and rational behaviours

4. LPNMR • Drawback: LP usually represents static environments • Conflict – Agents typically dynamic, acting in dynamic environments • To get around this: Dynamic Logic Programming (DLP) • Represent/Integrate knowledge from different sources which may evolve over time • Multi-Dimensional Dynamic Logic Programming (MDLP) – more expressive • “Language for Dynamic Updates” (LUPS) – specifying changes over time

5. MINERVA • Agent Architecture design based on dynamic representation of several system aspects and a evolving them via state transitions • Named after the Roman goddess Minerva • goddess of wisdom (amongst other things)

6. Topics • Background of (M)DLP and LUPS • MINERVA overall architecture • Labouring sub-agents

7. Dynamic Logic Programming • Sequence of logic programs • each has knowledge about a given state – different time periods, priorities, points of view, etc. • Try to define declarative & procedural semantics given relationships between different states • Declarative semantics – stable models of program consisting of all ‘valid’ rules in that state • Property of inertia r1. a :- b, c. p(X) :- q(X). d1 :- d2, e1. r1. p(X) :- f(Y,X), g(X,Z). d1 :- d2, e1. r1. a :- b, c. p(X) :- q(X).

8. Dynamic Logic Programming • DLP  Situation Calculus • MDLP – generalized, more expressive • “societal” view – inter- and intra- agent relationships • Transitioning between states??? r1. a :- b, c. p(X) :- q(X). d1 :- d2, e1. r1. p(X) :- f(Y,X), g(X,Z). d1 :- d2, e1. r1. a :- b, c. p(X) :- q(X).

9. LUPS • LUPS – “Language for dynamic updates” • language to declaratively specify changes to logic programs • sequentially updates logic program’s KB • The declarative meaning of a sequence of sets of update command in LUPS is defined by the semantics of the DLP generated by those commands

10. LUPS • A sentence U in LUPS – set of simultaneous update commands (actions), that given an existing sequence of logic programs (MDLP), produces a new MDLP with one more logic program • A LUPS program is a sequence of this type of sentence • semantics are defined by the DLP generated by the sequence of commands

11. LUPS • “Interpretation update” – no good • ex. program – only stable model is M={free} free ←not jail. jail ← abortion. • Suppose U={ abortion ← } • Only update of M by U would be {free, abortion} • Doesn’t make sense according to the update • Inertia should be applied to rules, not individual literals

12. LUPS – commands • Simplest command to add a rule to current state assert L ← L1,…,Lk when Lk+1,…,Lm • If preconditions Lk+1,…,Lm are true in current state, add the rule L ← L1,…,Lk to the successor knowledge state • Rule will then remain indefinitely by inertia, unless retracted or defeated by a future update

13. LUPS – commands • Sometimes we don’t want inertia example: wake_up ← alarm_rings • If the alarm rings we will wake up • Want to stay awake if not alarm becomes true (alarm stops ringing) • alarm_ring should not persist by inertia • One-time events assert event L ← L1,…,Lk when Lk+1,…,Lm

14. LUPS – commands • To delete rules, we use the retract command retract [event] L ← L1,…,Lk when Lk+1,…,Lm • This deletes the rule from the next state and continuing onward • If event is specified, the rule is temporarily deleted in the next state

15. LUPS – commands • Assertions – newly incoming information • Effects remain by inertia (unless); assert command itself does not • May want certain update commands to remain in successive consecutive updates • Persistent update commands – “Laws” always [event] L ← L1,…,Lk when Lk+1,…,Lm • Cancel a persistent update cancelL ← L1,…,Lk when Lk+1,…,Lm • cancel and retract – not the same

16. Overall Architecture

18. Common KB • Contains knowledge about the agent and others • Components – MDLP or LUPS • Capabilities • Intentions • Goals • Plans • Reactions • Object Knowledge Base • Internal Behaviour Rules • Internal Clock (???)

19. Object KB (MDLP) • Main component containing knowledge about the world • Represented as a DAG • Sequence of nodes for each sub-agent of agent α • evolution in time • sub-agents manipulate its own node • Sequence of nodes for other agents in system • represent α’s view of their evolution in time • Dialoguer sub-agent – interactions w/ other agents

20. Capabilities (LUPS) • Describes actions and effects possible of agent • Easy to describe since LUPS describes states and transitions • Typically, for each action ω: alwaysL ← L1,…,Lk when Lk+1,…,Lm,ω effect preconditions action

21. Capabilities (LUPS) • 3 main types of actions: • Adding a new fluent: ω causes F if … always F when F1,…,Fk,ω(F, Fi’s are fluents) • Rule update alwaysL ← L1,…,Lk when Lk+1,…,Lm,ω • Actions that, when performed in parallel, have different results • translate into 3 update commands always L1 when Lk+1,…,Lm,ωa,not ωb always L1 when Lk+1,…,Lm,not ωa,ωb always L2 when Lk+1,…,Lm,ωa,ωb • “ωa (x)or ωb cause L1 if the preconditions hold, and cause L2 in parallel”

22. Internal Behaviour Rules (LUPS) • Specify agent’s reactive internal epistemic state transitions • Form is assertL ← L1,…,Lk when Lk+1,…,Lm • Assert this rule if these conditions are true now. • example assert jail(X) ← abortion(X) when gov(repub) assert not jail(X) ← abortion(X) when gov(dem)

23. Goals (DLP) • Each state in DLP contains goals that agent needs to accomplish • goals are of the form goal(Goal,Time,Agent,Priority) • Goal – conj. of literals • Time – time state; related to internal clock??? • Agent – agent where goal originated • Priority – priority of goal • Any sub-agent can assert a goal • Sub-agent Goal-manager can manipulate goals

24. Plans (MDLP) • Action update – set of update commands of the form {assert event ω} ; ω is an action name • Asserting an event is conceptually the same as executing an action • must be an event since action do not persist • Example – to achieve Goal1 at time T, a plan might be: UT-3 = {assert event ω1; assert event ω2} UT-1 = {assert event ω4; assert event ω5} • Strength of LUPS allows conditional events (when) • Example – to achieve Goal2 at time T, a plan might be: UT-3 = {assert event ω3when L; assert event ω6when not L} UT-2 = {assert event ω1; assert event ω2}

25. Plans (MDLP) • Each plan for a goal (Goal) has preconditions (Conditions) • Planner sub-agent generates plans for goal • Asserts plans into Common KB as plan(Goal,Plan,Conditions) • Scheduler sub-agent uses plans and reactions to produce agent intentions

26. Reactions (MDLP) • Simple MDLP – rules just facts denoting actions ω, or negation of actions notω. • Contains sequence of nodes for every sub-agent capable of reacting • Hierarchy of reactions • Sub-agents have a set of LUPS commands of the form assertω when Lk+1,…,Lm • LUPS allows a form of action ‘blockage’ – prevent an action from being executed assert not ω when Lk+1,…,Lm • Deny any assert by lower ranked sub-agent

27. Intentions (MDLP) • Actions agent has committed to • Compiled by Scheduler from plans and reactions • Form is intention(Action,Conditions,Time) • perform action Action at time Time if the Conditions are true • Actuator sub-agent executes intentions • Previous example: (c is current time state) intention(ω3, L, c+1); intention(ω1, -, c+3); intention(ω4, -, c+5); intention(ω6, not L, c+1); intention(ω2,-, c+3); intention(ω5,-, c+5);

28. Sub-Agents

29. Sub-Agents • Evaluate and manipulate Common KB • Can interface with environment, other agents • Different specialities provides modularity • Each has a LUPS program describing its behaviour • Meta-interpreter to execute program • Execution produces states – nodes of the Object KB • Allow private procedure calls – extend LUPS to call them in when statement of a command assert X ← L1,…,Lk when Lk+1,…,Lm,ProcCall(Lm+1,…,Ln,X) • Can read Common KB, but not change

30. Sub-Agents • Present • Sensor • Dialoguer • Actuator • Effector • Reactor • Planner • Goal Manager • Scheduler • Learner • Contradiction Remover • Others

31. Sensor • Gets input from environment • Procedure Call SensorProc(Rule) • Can assert into Object KB by assert Rule when SensorProc(Rule) • Can act as a filter – decide what input to accept

32. Dialoguer • Similar to sensor • Gets inputs from other agents • Updates other agents’ nodes in Object KB • Generate new goals, reply messages, etc. based on received message • Example assert goal(Goal,Time,Agent,- )@goals when MsgFrom(Agent,Goal,Time,Rule), cooperative(Agent). assert Rule@Agent when MsgFrom(Agent,Goal,Time,Rule). assert msgTo(Agent,Goal,plan(Goal,Plan,Cond)@reactions when goal(Goal,Time,Agent,- )@goals, Agentα, plan(Goal,Plan,Cond)@plans

33. Actuator • Executes actions on the environment • Each cycle (of Internal Clock?) – extracts intentions and performs them • Successful? • if so, assert action name in Object KB • Form of LUPS command(s): assert event ωwhen intention(Action,Cond,Time)@intentions, Current(Time), Cond, ActionProc(ω).

34. Effector • At each cycle – evaluates LUPS commands • Capabilities and Behaviour rules • These don’t belong exclusively to Effector • Planner can access • Capabilities – prior successful action execution • Behaviour – doesn’t require

35. Reactor • Has reactive rules • if executed, produce an action to perform assert event ω@reactions when L1,…,Lk • Example assert event runaway@reactions when danger • Can also reactively block actions with assert event not ω@reactions when L1,…,Lk

36. Planner • Can find plans by abduction in LUPS specified scenarios • Uses Object KB, Intentions, Capabilities, and Common Behaviour Rules to find plans • LUPS command for AbductivePlan(Goal,Plan,Cond) assert plan(Goal,Plan,Cond)@plans when goal(Goal,T,-,1)@goals, AbductivePlan(Goal,Plan,Cond) • Other planners can be used – interface w/ LUPS commands

37. Goal Manager • Deal with conflicting goals • asserted by other sub-agents • possibly originating from other agents • Works on the Goals structure • can delete goals, change priorities, etc. • Example of two incompatible goals being handled retract goal(G1,T1,A1,P1)@goals when goal(G1,T1,A1,P1)@goals, goal(G2,T2,A2,P2)@goals, incomp(G1,G2), P1 < P2.

38. Scheduler • Determines intentions based on current state • Acts if there are pending reactions or goals and plans • May be more than 1 specialized scheduling procedure • Example assertΠ@intentions when goal(G,-,-,-)@goals, plan(G,-,-)@plans, not X@reactions, SchedulePlans(Π). assertΠ@intentions when not goal(-,-,-,-)@goals, X@reactions, ScheduleReactions(Π). assertΠ@intentions when goal(G,-,-,-)@goals, plan(G,-,-)@plans, X@reactions, CombineSchedule(Π).

39. Conclusion • Logic Programming provides clear specification and correctness • Dynamic Logic Programming (DLP) provides a way to represent knowledge (possibly from different sources) that evolves over time • sequence of logic programs • different states • MDLP – express added knowledge of environment, other agents • LUPS – specifies transitioning between states in (M)DLP • This together with strong concepts such as intentions, planning, etc. form a solid agent architecture

40. Ian’s Diagnosis Looks a little complicated, but sounds cool enough to want to give it a shot!