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 Strascina3/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). r1. a :- b, c. p(X) :- q(X). d1 :- d2, e1. r1. p(X) :- f(Y,X), g(X,Z). d1 :- d2, e1.

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). r1. a :- b, c. p(X) :- q(X). d1 :- d2, e1. r1. p(X) :- f(Y,X), g(X,Z). d1 :- d2, e1.

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 ← L 1,…,L k when L k+1,…,L m If preconditions L k+1,…,L m are true in current state, add the rule L ← L 1,…,L k 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 ← L 1,…,L k when L k+1,…,L m

14. LUPS – commands To delete rules, we use the retract command retract [event] L ← L 1,…,L k when L k+1,…,L m 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 ← L 1,…,L k when L k+1,…,L m  Cancel a persistent update cancel L ← L 1,…,L k when L k+1,…,L m 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 ω: always L ← L 1,…,L k when L k+1,…,L m,ω effect preconditions action

21. Capabilities (LUPS) 3 main types of actions: Adding a new fluent: ω causes F if … always F when F 1,…,F k,ω (F, F i ’s are fluents)  Rule update always L ← L 1,…,L k when L k+1,…,L m,ω  Actions that, when performed in parallel, have different results  translate into 3 update commands always L 1 when L k+1,…,L m,ω a,not ω b always L 1 when L k+1,…,L m,not ω a,ω b always L 2 when L k+1,…,L m,ω a,ω b  “ω a (x)or ω b cause L 1 if the preconditions hold, and cause L 2 in parallel”

22. Internal Behaviour Rules (LUPS) Specify agent’s reactive internal epistemic state transitions Form is assert L ← L 1,…,L k when L k+1,…,L m 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 Goal 1 at time T, a plan might be: U T-3 = {assert event ω 1 ; assert event ω 2 } U T-1 = {assert event ω 4 ; assert event ω 5 } Strength of LUPS allows conditional events (when) Example – to achieve Goal 2 at time T, a plan might be: U T-3 = {assert event ω 3 when L; assert event ω 6 when not L} U T-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 L k+1,…,L m  LUPS allows a form of action ‘blockage’ – prevent an action from being executed assert not ω when L k+1,…,L m  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. 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 ← L 1,…,L k when L k+1,…,L m,ProcCall(L m+1,…,L n,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 L 1,…,L k  Example assert event runaway@reactions when danger  Can also reactively block actions with assert event not ω@reactions when L 1,…,L k

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(G 1,T 1,A 1,P 1 )@goals when goal(G 1,T 1,A 1,P 1 )@goals, goal(G 2,T 2,A 2,P 2 )@goals, incomp(G 1,G 2 ), P 1 < P 2.

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!