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

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

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

LPNMR

Drawback: LP usually represents static environmentsConflict – 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

MINERVA

Agent Architecture design based on dynamic representation of several system aspects and a evolving them via state transitions

Named after the Roman goddess Minervagoddess of wisdom (amongst other things)

Topics

Background of (M)DLP and LUPS

MINERVA overall architecture

Labouring sub-agents

Dynamic Logic Programming

Sequence of logic programseach 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.

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.

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

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

LUPS

“Interpretation update” – no goodex. 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

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

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

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

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

cancel L ← L1,…,Lk when Lk+1,…,Lm

cancel and retract – not the same

Overall Architecture

Common KB

Contains knowledge about the agent and others

Components – MDLP or LUPSCapabilities

Intentions

Goals

Plans

Reactions

Object Knowledge Base

Internal Behaviour Rules

Internal Clock (???)

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 systemrepresent α’s view of their evolution in time

Dialoguer sub-agent – interactions w/ other agents

Capabilities (LUPS)

Describes actions and effects possible of agent

Easy to describe since LUPS describes states and transitions

Typically, for each action ω:always L ← L1,…,Lk when Lk+1,…,Lm,ω

effect preconditions action

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 updatealways L ← 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”

Internal Behaviour Rules (LUPS)

Specify agent’s reactive internal epistemic state transitions

Form isassert L ← L1,…,Lk when Lk+1,…,Lm

Assert this rule if these conditions are true now.

exampleassert jail(X) ← abortion(X) when gov(repub)

assert not jail(X) ← abortion(X) when gov(dem)

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

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 ω3 when L; assert event ω6 when not L}

UT-2 = {assert event ω1; assert event ω2}

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

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

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);

Sub-Agents

Sub-Agents

Evaluate and manipulate Common KB

Can interface with environment, other agents

Different specialities provides modularity

Each has a LUPS program describing its behaviourMeta-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

Sub-Agents

PresentSensor

Dialoguer

Actuator

Effector

Reactor

Planner

Goal Manager

Scheduler

Learner

Contradiction Remover

Others

Sensor

Gets input from environment

Procedure Call SensorProc(Rule)

Can assert into Object KB byassert Rule when SensorProc(Rule)

Can act as a filter – decide what input to accept

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

Exampleassert 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

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(ω).

Effector

At each cycle – evaluates LUPS commandsCapabilities and Behaviour rules

These don’t belong exclusively to Effector

Planner can access

Capabilities – prior successful action execution

Behaviour – doesn’t require

Reactor

Has reactive rulesif 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

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

Goal Manager

Deal with conflicting goalsasserted by other sub-agents

possibly originating from other agents

Works on the Goals structurecan delete goals, change priorities, etc.

Example of two incompatible goals being handledretract goal(G1,T1,A1,P1)@goals when

goal(G1,T1,A1,P1)@goals, goal(G2,T2,A2,P2)@goals,

incomp(G1,G2), P1 < P2.

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

Exampleassert Π@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(Π).

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

Ian’s Diagnosis

Looks a little complicated,

but sounds cool enough to

want to give it a shot!