Minerva a dynamic logic programming agent architecture
1 / 40

MINERVA – A Dynamic Logic Programming Agent Architecture - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' MINERVA – A Dynamic Logic Programming Agent Architecture' - ozzy

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Minerva a dynamic logic programming agent architecture

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


  • 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


  • 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


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


  • Background of (M)DLP and LUPS

  • MINERVA overall architecture

  • Labouring sub-agents

Dynamic logic programming
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


a :- b, c.

p(X) :- q(X).

d1 :- d2, e1.


p(X) :- f(Y,X),


d1 :- d2, e1.


a :- b, c.

p(X) :- q(X).

Dynamic logic programming1
Dynamic Logic Programming

  • DLP  Situation Calculus

  • MDLP – generalized, more expressive

    • “societal” view – inter- and intra- agent relationships

  • Transitioning between states???


a :- b, c.

p(X) :- q(X).

d1 :- d2, e1.


p(X) :- f(Y,X),


d1 :- d2, e1.


a :- b, c.

p(X) :- q(X).


  • 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


  • 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


  • “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

Lups commands
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 commands1
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 commands2
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 commands3
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

Common kb
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 (???)

Object kb mdlp
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

Capabilities lups
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

Capabilities lups1
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”

Internal behaviour rules lups
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)

Goals dlp
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
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}

Plans mdlp1
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
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
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 agents1

  • 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

Sub agents2

  • Present

    • Sensor

    • Dialoguer

    • Actuator

    • Effector

    • Reactor

    • Planner

    • Goal Manager

    • Scheduler

    • Learner

    • Contradiction Remover

    • Others


  • 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


  • 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 [email protected] when MsgFrom(Agent,Goal,Time,Rule).

    assert msgTo(Agent,Goal,plan(Goal,Plan,Cond)@reactions

    when goal(Goal,Time,Agent,- )@goals, Agentα,



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


  • 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


  • Has reactive rules

    • if executed, produce an action to perform

      assert event ω@reactions when L1,…,Lk

  • Example

    assert event [email protected] when danger

  • Can also reactively block actions with

    assert event not ω@reactions when L1,…,Lk


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


  • 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 [email protected], SchedulePlans(Π).

    assertΠ@intentions when not goal(-,-,-,-)@goals, [email protected], ScheduleReactions(Π).

    assertΠ@intentions when goal(G,-,-,-)@goals, plan(G,-,-)@plans,

    [email protected], CombineSchedule(Π).


  • 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
Ian’s Diagnosis

Looks a little complicated,

but sounds cool enough to

want to give it a shot!