Heterogenous Temporal
Probabilistic Agents
Prof. Dr. Jürgen Dix
Université Pierre et Marie Curie
Paris, LIP 6
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
1/361
Time and place: Friday, 16th March (salle 847)
15:00–16:00 at LIP 6, site Kennedy.
Website
http://www-poleia.lip6.fr/~charif/
seminaires.html
Work jointly with: Sarit Kraus (Bar-Ilan, IL) and
V.S. Subrahmanian (Maryland, US).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
2/361
About this talk
This talk was held in Paris, Université Pierre et Marie Curie, LIP 6, on
16th March 2007 within the DESIR seminar. It covers much more
material than actually given in the talk.
: notably the
While the first chapter covers
client-server architecture and the code-call mechanism, the second
: they are based on the notion of
chapter treats
an action, and the definition of status sets. Chapter 3 shows how we
: programs the
define a class of
status sets of which can be computed polynomially.
Finally, Chapter 4 contains the main part of the given talk. We show
how our basic framework can be extended by using appropriate
of programs: to handle beliefs, time, probabilities, and
also time + probabilities.
IMPACT's architecture
basic agent programs
efficiently implementable agents
annotations
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
3/361
1. Impact Architecture
Chapter 1. Impact Architecture
1.1
1.2
1.3
1.4
1.5
1.6
1.7
Impact Architecture
Scenarios
Agent/Server
Service Descriptions
Code Call Mechanism
Software Abstractions
Message Box
Summary, References
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
4/361
1. Impact Architecture
We introduce two running examples and the
main idea underlying the IMPACT approach:
the code call mechanism.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
5/361
1. Impact Architecture
1. Scenarios
1.1 Scenarios
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
6/361
1. Impact Architecture
1. Scenarios
USER
user’s
request
multimedia
presentation
Interface Agent
user’s
request
profile
based items
for presentation
Content Determination Agent user’s profile
identify
products
identified
products
Product DB
Agent
product DBs
Prof. Dr. Jürgen Dix · LIP 6, UPM
user-id to be
profiled
Profiling
Agent
request
for credit
info
requested
credit info
Credit
Agent
credit DBs
Panam Seminaire, 17. March 2007
7/361
1. Impact Architecture
1. Scenarios
Controlled Flight into Terrain (CFIT) scenario
modified flight plan
Auto-Pilot
Agent
no-go
areas
GPS
data
merged
location
GPS Agent
Terrain
Agent
Satellite
Agents
terrain (DTED) data
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
8/361
1. Impact Architecture
1. Scenarios
Agents in CHAIN Example
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
9/361
1. Impact Architecture
2. Agent/Server
1.2 Agent/Server
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 10/361
1. Impact Architecture
2. Agent/Server
Four main categories [4]:
1. transducer: Each agent has an associated
“transducer” which converts incoming messages and
requests into a format intelligible to the agent.
Problem: n-agent system may need O(n2 ) transducers
(not desirable).
2. wrapper: inject code into a program to allow it to
communicate.
Principle: each agent has an associated body of code
that is expressed in a common language (or one of
few) languages used by other agents.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
11/361
1. Impact Architecture
2. Agent/Server
3. code rewriting: complete rewriting to implement an
agent.
Problem: Very expensive alternative.
4. mediation approach [7]: all agents communicate
with a “mediator,” which in turn may send messages
to other agents.
The mediation approach has been extensively studied
[?, 2, 3, 1].
Problem: Suppose all communications in the CFIT
example had to go through such a mediator. Then if
the mediator malfunctions or “goes down,” the
system as a whole is liable to collapse, leaving the
plane in a precarious position.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 12/361
1. Impact Architecture
2. Agent/Server
Overall IMPACT Architecture
agent
agent
agent
network
(backbone)
IMPACT server
agent
IMPACT server detail
IMPACT server
Prof. Dr. Jürgen Dix · LIP 6, UPM
REG
YP
THS
TYP
INF
Panam Seminaire, 17. March 2007 13/361
1. Impact Architecture
2. Agent/Server
Server Architecture
An IMPACT Server is a collection of the following
servers:
Registration (REG): creator enters agent to the
system, which services it provides, and who may use
them.
Yellow Pages (YP): Process requests from agents to
find other agents providing some service
(matchmaking).
Thesaurus (THS): requested when agent services are
entered, or YP server performs matchmaking.
Types (TYP): Server maintains a set of class hierarchies
used by different agents and the inclusion
relationship(s).
Interfaces (INF): GUI for human user
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 14/361
1. Impact Architecture
2. Agent/Server
Basic IMPACT Agent Architecture
Action Policy
Security
Messages
In
Messages
Out
Meta-Kn
N
E
T
W
O
R
K
Action
Base
Function Calls
Integrity
Constr.
AGENT
Action
Constr.
Legacy Data
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 15/361
1. Impact Architecture
2. Agent/Server
Agent/Service Registration
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 16/361
1. Impact Architecture
2. Agent/Server
Agent Service Description Language (SDL)
Describe agent services in a simple HTML-style language.
Each service has
a name:
<name> ::= <verb>’:’<nounterm>
<nounterm> ::= <noun> | <noun>’(’<noun>’)’
inputs: (typed) values. Distinguish mandatory and
optional inputs.
outputs: (typed) values
attributes: e.g. cost, response time (optional)
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
17/361
1. Impact Architecture
2. Agent/Server
Example (STORE application):
hSi
classify: user
hMIissn: Stringh\MIi
hIiname: Stringh\Ii
hOiclass: UserProfileh\Oi
h\Si
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 18/361
1. Impact Architecture
3. Service Descriptions
1.3 Service Descriptions
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 19/361
1. Impact Architecture
3. Service Descriptions
Definition 1.1 (Verbs, Nouns, nt(Nouns))
Let Verbs be a set of verbs in English and Nouns a
set of nouns in English.
A noun term is either a noun or an expression
of the form n1 (n2 ) where n1 , n2 are both
nouns.
nt(Nouns) denotes the set of all syntactically
valid noun terms generated by the set Nouns.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 20/361
1. Impact Architecture
3. Service Descriptions
Definition 1.2 (Service Name)
If v ∈ Verbs and nt ∈ nt, then v: nt is called a
service name.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 21/361
1. Impact Architecture
3. Service Descriptions
Service List for the STORE example
AGENT
credit
profiling
productDB
contentDetermin
saleNotification
Prof. Dr. Jürgen Dix · LIP 6, UPM
SERVICES
provide: information(credit)
provide: address
provide: user-profile
classify: user
provide: description(product)
prepare: presentation(product)
identify: items
identify: user-profile
determine: items
Panam Seminaire, 17. March 2007 22/361
1. Impact Architecture
3. Service Descriptions
Service List for the CFIT Scenario
AGENT
autoPilot
satellite
gps
terrain
Prof. Dr. Jürgen Dix · LIP 6, UPM
SERVICE
maintain: course
adjust : course
create: plan(flight)
broadcast : data(GPS)
collect : data(GPS)
merge: data(GPS)
create: information(GPS)
generate: map(terrain)
determine: area(no-go)
Panam Seminaire, 17. March 2007 23/361
1. Impact Architecture
3. Service Descriptions
AGENT
plant
SERVICE
monitor: inventory
determine: amount(part)
order: part
notify: supplier
supplier monitor: available-stock
update: stock
truck
provide: schedule(truck)
manage: freight
ship: freight
Table 1: Service List for the CHAIN example
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 24/361
1. Impact Architecture
3. Service Descriptions
Synonyms and Thesaurus
What if agent a seeks another one offering a
service qs ?
We need to match qs with other services in
the yellow pages.
Example: An agent looks for an agent
offering the service generate: map(ground).
Answer: CFIT terrain agent: ground and
terrain are synonymous.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 25/361
1. Impact Architecture
3. Service Descriptions
Let
Σ be set of English words, such that Σ
contains only verbs or only noun-terms.
∼ be an equivalence relation on Σ.
Definition 1.3 (Σ-node)
A Σ-node is any subset N ⊆ Σ that is closed
under ∼, i.e.
1
2
x ∈ N & y ∈ Σ & y ∼ x ⇒ y ∈ N.
x, y ∈ N ⇒ x ∼ y.
Σ-nodes are equivalence classes of Σ.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 26/361
1. Impact Architecture
3. Service Descriptions
Example: An agent looks for an agent offering
the service generate: map(area).
Answer: CFIT terrain agent: area can be
specialised to terrain.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 27/361
1. Impact Architecture
3. Service Descriptions
Definition 1.4 (Σ-Hierarchy)
A Σ-Hierarchy is a weighted, directed acyclic
graph SH =def (T, E, ℘) such that:
1 T is set of nonempty Σ-nodes;
2 If t1 and t2 are different Σ-nodes in T , then t1
and t2 are disjoint;
+
3 ℘ is a mapping ℘ : E → Z
indicating a
positive distance between two neighbouring
vertices.
Note: no requirement that ℘ satisfies any metric
axioms at this point.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 28/361
1. Impact Architecture
3. Service Descriptions
Verb Hierarchy
compute
2
2
2
create
2
2
3
2
prepare
cancel
change
adjust
maintain
manage
merge
climb
3
generate
find
order
2
3
choose
yaw
3
classify
3
2
determine
provide
identify
locate
view
3
notify
convert
update
perform
2
collect
2
sell
send
broadcast
mail
monitor
ship
Prof. Dr. Jürgen Dix · LIP 6, UPM
present
3
2
respond
return
Verb Hierarchy (Miss.
Labels = 1)
Panam Seminaire, 17. March 2007 29/361
1. Impact Architecture
3. Service Descriptions
Noun Hierarchy
information
advertisement
data
description
document
information(credit)
information(GPS)
brochure
mailList
data(GPS)
description(product)
message
performance
contract
memo
email fax
performance(supplier)
product
2
appliances
2
schedule
userProfile
schedule(shipping)
schedule(truck)
presentation(product)
quantity
2
clothing
presentation
information(product)
title
2
inventory
items stock
wine
amount
spender
supplier
user
2
jewelry shoes
freight stock(available)
stock(committed)
amount(part)
spender(high)
spender(low)
shoes(leather)
spender(veryHigh)
spender(medium)
vehicle
navigation
area
2
airplane
aileron
control
part
truck
sparkPlugs
tires
2
course map path plan route
map(area)
map(ground)
area(noGo)
ground
region
terrain
plan(flight)
map(terrain)
Figure 1: Noun-term Hierarchy
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 30/361
1. Impact Architecture
3. Service Descriptions
Distances
Definition 1.5 (Distance between two terms)
Given a Σ-Hierarchy SH =def (T, E, ℘), the distance
between two terms, w1 , w2 ∈ T , is defined as follows:

0,
if some t ∈ T exists with




w1 , w2 ∈ t;



cost(p
),
if some undirected path

min
between w1 , w2 exists in
dSH (w1 , w2 ) =def


SH
and pmin is the least




cost such path;


∞,
otherwise.
dSH is well defined and satisfies the triangle inequality.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
31/361
1. Impact Architecture
3. Service Descriptions
Hierarchy Browsing Screen Dump
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 32/361
1. Impact Architecture
3. Service Descriptions
Thesaurus Screen Dump
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 33/361
1. Impact Architecture
4. Code Call Mechanism
1.4 Code Call Mechanism
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 34/361
1. Impact Architecture
4. Code Call Mechanism
A definition of agents should not limit the
choice of data structures and algorithms that
an application designer must use.
CFIT: terrain agent on top of existing US
military terrain reasoning software.
Accessing DB’s: For instance, the Product
Database agent productDB in the
STORE example may access some file
structures, as well as some databases.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 35/361
1. Impact Architecture
5. Software Abstractions
1.5 Software Abstractions
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 36/361
1. Impact Architecture
5. Software Abstractions
S = (T
T S ,F
F S ,C
C S ))
Definition 1.6 (S
Characterize the code on top of which an agent
T S ,F
F S ,C
C S ), where:
is built as S =def (T
1 T S is the set of all data types managed by S ,
2 F S is a set of predefined functions which
makes access to the data objects managed by
the agent available to external processes, and
3 C S is a set of type composition operations.
A type composition operator is a partial n-ary
function c which takes as input types τ1 , . . . , τn
and yields as a result a type c(τ1 , . . . , τn ).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
37/361
1. Impact Architecture
5. Software Abstractions
Intuitively:
T S is the set of all data types that are
managed by the agent.
F S intuitively represents the set of all
function calls supported by the package S ’s
application programmer interface (API ).
C S the set of ways of creating new data types
from existing data types.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 38/361
1. Impact Architecture
5. Software Abstractions
Notation: T S? is the closure of T S under the
operations in C S .
More formally:
C S (T
T ) and T S? )
Definition 1.7 (C
a) Given a set T of types, let
T ) =def
C S (T
T
∪
{τ : τ = c(τ1 , . . . , τn ) for some n-ary
c ∈ C S and types τ1 , . . . , τn ∈ T }
S
b) T S? =def i∈N T Si , where
T S0
=def T S ,
i+1
T Si )
TS
=def C S (T
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 39/361
1. Impact Architecture
5. Software Abstractions
CHAIN Revisited
T S =def
{Integer, Location, String, Date, OrderLog, Stock}
OrderLog is a relation having the schema
(client/string, amount/Integer, part_id /String, method /String,
src/Location, dest/Location, pickup_st/date, pickup_et/date),
while Stock is a relation having the schema
(amount/Integer, part_id /String). Location is an
enumerated type containing city names.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 40/361
1. Impact Architecture
5. Software Abstractions
In addition, F S might consist of the functions:
monitorStock (Amount/Integer, Part_id /String) of type
String. This function returns either amount_available
or amount_not_available.
shipFreight
shipFreight(Amount/Integer, Part_id /String, method /String,
Src/Location, Dest/Location). This function, when
executed, updates the order log and logs information
about the order, together with information on (i) the
earliest time the order will be ready for shipping, and
(ii) the latest time by which the order must be picked
up by the shipping vendor.
Notice that this does not mean that the shipment will
in fact be picked up by the airplane agent at that
time.
updateStock (Amount/Integer, Part_id /String). This
function, when executed, updates the inventory of the
Supplier.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 41/361
1. Impact Architecture
5. Software Abstractions
CFIT Revisited
T S =def {Map, Path, Plan, SatelliteReport}.
Special class of maps called DTED Digital Terrain
Elevation Data that specify the elevations of different
regions of the world.
The autoPilot agent’s set of functions F S might contain:
createFlightPlan
createFlightPlan(Location/Map, Flight_route/Path, Nogo/Map)
of type Plan.
The gps agent’s set of functions F S might contain:
mergeGPSData
mergeGPSData(Data1 /SatelliteReport, Data2 /SatelliteReport)
of type SatelliteReport.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 42/361
1. Impact Architecture
5. Software Abstractions
Agent State
Definition 1.8
At any given point t in time, the state of an
agent will refer to a set O S (t) of objects from the
types T S , managed by its internal software code.
An agent may change its state by taking an
action—either triggered internally, or by
processing a message received from another
agent.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 43/361
1. Impact Architecture
5. Software Abstractions
Assumption: Except for appending messages to
an agent a ’s mailbox, another agent b cannot
directly change a ’s state. (However, it might do
so indirectly by shipping the other agent a
message issuing a change request.)
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 44/361
1. Impact Architecture
5. Software Abstractions
The Code Call Mechanism
Code Calls take data from heterogenous DB's
so that such data can be considered as logical
atoms (as terms in predicate logic).
An agent built on top of a piece, S , of
software, may support several API functions,
and it may or may not make all these
functions available to other agents (through
SDL).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 45/361
1. Impact Architecture
5. Software Abstractions
Definition 1.9 (Code Call S : f ( d1 , . . . , dn) )
T S ,F
F S ,CC S ) be a software code. Let f ∈ F S be
Let S =def (T
an n-ary function and d1 , . . . , dn objects or variables such
that each di matches the type requirements of the i’th
argument of f . Then,
S : f (d1 , . . . , dn)
is a code call. A code call is ground, if all di ’s are objects.
S : f ( d1 , . . . , dn) may be read as: execute function f as
defined in package S on the arguments d1 , . . . , dn .
Notation: We also write a : f ( d1 , . . . , dn) instead of
S : f ( d1 , . . . , dn) where S is provided by agent a .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 46/361
1. Impact Architecture
5. Software Abstractions
Assumption on the Output Signature
Without loss of generality, we assume that the
output signature of any code call is a set.
(If a function does not return a set, but rather
returns an atomic value, then that value can be
coerced into a set anyway—by treating the value
as shorthand for the singleton set containing just
the value.)
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
47/361
1. Impact Architecture
5. Software Abstractions
Examples:
1
2
3
supplier : monitorStock
monitorStock((3, part_008)).
The result of this call is either { amount_available }, or
the set { amount_not_available }.
supplier : shipFreight
shipFreight((3, part_008, truck, X, paris)).
Create a pickup schedule for shipping 3 pieces of
part_008 from location X to paris by truck. Until a
value is specified for X, this code call cannot be
executed.
GPS : mergeGPSData
mergeGPSData((S1, S2)) merges two pieces, S1
and S2, of satellite data, but the values of the two
pieces are not stated.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 48/361
1. Impact Architecture
5. Software Abstractions
Variables
root variables: For any type τ ∈ T S there is a set
root(τ ) of “root” variables ranging over τ : a
complex record type having fields f1 , . . . , fn .
For every variable of type τ , X.fi is a variable
of type τi where τi is the type of field fi .
If fi itself has a sub-field g of type γ, then
X.fi .g is a variable of type γ, and so on: path
variables.
For any path variable Y of the form X.path,
where X is a root variable, X is the root of Y,
denoted by root(Y).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 49/361
1. Impact Architecture
5. Software Abstractions
Example 1.10 (CFIT Revisited)
Let X be a (root) variable of type
SatelliteReport denoting the current location
of an airplane.
Then X.2dloc, X.2dloc.x, X.2dloc.y, X.height,
and X.dist are path variables .
For each of the path variables Y, root(Y) = X.
Here, X.2dloc.x, X.2dloc.y, and X.height are of
type Integer, X.2dloc’s type is a record of two
Integer s, and X.dist is of type NonNegative.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 50/361
1. Impact Architecture
5. Software Abstractions
Variable Assignment
Definition 1.11
An assignment of objects to variables is a set
of equations of the form
V1 := o1 , . . . , Vk := ok
where the Vi ’s are (root or path) variables and
the oi ’s are objects.
An assignment is legal, if the types of objects
and corresponding variables match.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 51/361
1. Impact Architecture
5. Software Abstractions
Example 1.12 (CFIT Revisited)
A legal assignment may be
X.height := 50, X.sat_id := iridium_17,
X.dist := 25, X.2dloc.x := 3, X.2dloc.y := −4.
We write this as (50, iridium_17, 25, h3, −4i).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 52/361
1. Impact Architecture
5. Software Abstractions
Code Call Atoms
Code call atoms are logical atoms that are
layered on top of code-calls.
Definition 1.13
If cc is a code call, and X is either a variable, or an
object of the output type of cc, then
in(( X, cc)) ,
not_in(( X, cc)) ,
are called code call atoms. It is ground if no
variable symbols occur anywhere in it.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 53/361
1. Impact Architecture
5. Software Abstractions
A code call atom of the form in(( X, cc)) succeeds just in
case when X can be set to a pointer to one of the
objects in the set of objects returned by executing the
code call.
A code call atom of the form not_in(( X, cc)) succeeds
just in case X is not in the result set returned by cc
(when X is an object), or when X cannot be made to
point to one of the objects returned by executing the
code call.
What effects does this have on the state of an agent?
It is an infinite set of ground code call atoms!
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 54/361
1. Impact Architecture
5. Software Abstractions
Examples:
in(( spender(high), profiling : classifyUser
classifyUser((Johnny_Rich))) .
This code call succeeds just in case the Profiling agent classifies
Johny Rich as a big spender.
not_in(( spender(low), profiling : classifyUser
classifyUser((U))) .
This code call succeeds just in case user U, whose identity must be
instantiated prior to evaluation, is not classified as a low spender
by the profiling agent.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 55/361
1. Impact Architecture
5. Software Abstractions
Definition 1.14 (Code Call Condition)
A code call condition is defined as follows:
1
2
3
4
Every code call atom is a code call condition.
If s and t are either variables or objects, then s = t is a
code call condition.
If s and t are either integers/real valued objects, or are
variables over the integers/reals, then
s < t, s > t, s ≤ t, and s ≥ t are code call conditions.
If χ1 and χ2 are code call conditions, then χ1 & χ2 is a
code call condition.
Any code call condition 1.-3. is atomic.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 56/361
1. Impact Architecture
5. Software Abstractions
Examples:
(1)
1 χ
:
in(( amount_available, supplier : monitorStock
monitorStock((3, part_008))) .
(2)
2 χ
: in(( X, supplier : monitorStock
monitorStock((3, part_008))) & X =
amount_available.
(3)
3 χ
:
(
in( amount_available, supplier : monitorStock
monitorStock((U, part_008)))
(
not_in( amount_available, supplier : monitorStock
monitorStock((U + 1, part_008)))
(
supplier
monitorStock
in( amount_available,
: monitorStock((V, part_009)))
(
supplier
not_in( amount_available,
: monitorStock
monitorStock((V + 1, part_009)))
Prof. Dr. Jürgen Dix · LIP 6, UPM
&
&
&
& U < V.
Panam Seminaire, 17. March 2007
57/361
1. Impact Architecture
5. Software Abstractions
1
in(( X, profiling : classifyUser
classifyUser((Johnny_Rich))) &
(
profiling
classifyUser
in( Y,
: classifyUser((Joe_Foe)))
&
X = Y.
2
in(( spender(medium), profiling : classifyUser
classifyUser((U)))
&
not_in(( spender(high), profiling : classifyUser
classifyUser((U))) .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 58/361
1. Impact Architecture
5. Software Abstractions
Safety
A code call S : f (d1 , . . . , dn) is safe iff each di is
ground.
For evaluation, code call atoms must be ground.
Problem: Given a code call condition
χ1 & . . . , & χn with variables, how to assure that
evaluation of the code calls and comparisons χi
is possible?
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 59/361
1. Impact Architecture
5. Software Abstractions
Example (ctd):
χ(1) is “safe” (evaluate from left to write).
χ(2) is not safe (X, Y uninstantiated).
The code call
in(( X, a : f ( Y))) & in(( Y, a : f ( 2)))
can be evaluated by reordering atomic cc
conditions.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 60/361
1. Impact Architecture
5. Software Abstractions
Definition 1.15 (Safe Code Call (Condition))
A code call condition χ1 & . . . & χn , n ≥ 1, is safe iff there is
a permutation π of 1, . . . , n such that, for i = 1, . . . , n:
1 If χπ(i) is a comparison s1 op s2 , then
1.1 at least one of s1 , s2 is a constant or a variable X such that root(X)
belongs to RVπ (i) =def {root(Y) | ∃j < i s.t. Y occurs in χπ(j) };
1.2 if si is neither a constant nor a variable X such that root(X) ∈ RVπ (i),
then si is a root variable.
2
If χπ(i) = in(( Xπ(i) , ccπ(i)) or χπ(i) = not_in(( Xπ(i) , ccπ(i)) ,
then either Xπ(i) is a root variable, or root(Xπ(i) ) is from
RVπ (i), and the root of each variable Y occurring in
ccπ(i) belongs to RVπ (i).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 61/361
1. Impact Architecture
5. Software Abstractions
If χ = χ1 & · · · , &χn is found safe, we can reorder it by a
permutation π such that χπ(1) & · · · &χπ(n) without
problems.
Checking safety of code call conditions can be efficiently
done (in linear time) at compile time of a program.
Straightforward generalisation:
Definition 1.16 (Safety Modulo Variables)
Let χ be a code call condition, and let X be any set of root
variables. Then, χ is safe modulo X, if χθ is safe, for any
legal assignment θ of objects to the variables in X.
Note: Checking safety of a code call χ modulo X easily
reduces to a check for safety.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 62/361
1. Impact Architecture
5. Software Abstractions
This may be done as follows:
1
2
Find a constant (denoted by c) that does not
occur in χ.
Let θ =def {X = c}, i.e., every variable in X is
set to c.
Check if χθ is safe.
Safety modulo variables X means: When these
variables X are instantiated, the ccc can be
evaluated.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 63/361
1. Impact Architecture
5. Software Abstractions
Definition 1.17 (Algorithm: safe_ccc)
safe_ccc(χ: code call condition;
X: set of root variables)
(? input: code call condition χ = χ1 & · · · &χn ;
(? output: proper reordering
(? χ0 = χπ(1) & · · · &χπ(n) if χ is safe modulo X;
(? otherwise, the output is unsafe ;
Prof. Dr. Jürgen Dix · LIP 6, UPM
?)
?)
?)
?)
Panam Seminaire, 17. March 2007 64/361
1. Impact Architecture
5. Software Abstractions
1. L := χ1 , . . . , χn ;
2. χ := true;
3. while L is not empty do
4. { select all χi1 , . . . , χim from L st. χij is safe modulo X;
5. if m = 0 then return unsafe (exit);
6. else
7. { χ := χ&χi1 & · · · &χim ;
8.
remove χi1 , . . . , χim from L;
9.
X = X ∪ {root(Y) | Y occurs in some χi1 , . . . χim };
10. }
11. }
12. return χ0 ;
end.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 65/361
1. Impact Architecture
5. Software Abstractions
Theorem 1.18 (Safety Computation)
Suppose χ =def χ1 & . . . & χn is a code call
condition. Then, χ is safe modulo a set of root
variables X, if and only if safe_ccc(χ, X) returns a
reordering χ0 of χ. Moreover, for any assignment θ
to the variables in X, χ0 θ is a safe code call
condition which can be evaluated left-to-right.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 66/361
1. Impact Architecture
5. Software Abstractions
A straightforward implementation of safe_ccc runs in
quadratic time, as the number of iterations is bounded
by the number n of constituents χi of χ, and the body
of the while loop can be executed in linear time.
By using appropriate data structures, the algorithm
can be implemented to run in overall linear time.
Briefly, the method is to use cross reference lists of
variable occurrences.
safety of a code call condition χ can be checked by
calling safe_ccc(χ, ∅). Thus, checking the safety of χ,
combined with a reordering of its constituents for
left-to-right execution can be done very efficiently.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 67/361
1. Impact Architecture
5. Software Abstractions
Definition 1.19 (Code Call Solution)
Let χ be a code call condition involving the variables
T S ,F
F S ,C
C S ).
X =def {X1 , . . . , Xn } and let S =def (T
A solution of χ w.r.t. T S in a state O S is a legal assignment
of objects o = o1 , . . . , on to the variables X1 , . . . , Xn ,
written X := o, such that the application of the
assignment makes χ true in state O S .
Sol(χ)T S ,O
O S is the set of all solutions of the code call
condition χ in state O S , and by
O _Sol(χ)T S ,O
OS is the set of all objects appearing in
Sol(χ)T S ,O
OS
(subscripts are occasionally omitted)
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 68/361
1. Impact Architecture
5. Software Abstractions
Existence of ins, del and upd
We assume that F S of code package S includes three functions as
follows:
insS , which takes as input a set of objects O for S and a state O S ,
and returns a new state O S0 = insS (O, O S ) accomplishing the
insertion of the objects in O into O S .
delS , which takes as input a set of objects O for S and a state O S ,
and returns a new state O S0 =def delS (O, O S ) describing the
deletion of the objects in O from O S .
updS , which takes as input a data object o manipulated by S , a
field f of o, and a value v from the domain of the type of o.f —this
function changes the value of the o.f to v. (Can be described in
terms of the preceding two functions.)
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 69/361
1. Impact Architecture
5. Software Abstractions
Executing the function, insFinanceRecord (χ(X))
where χ(X) is a code call condition involving the
(sole) free variable X means:
“Insert, using a FinanceRecord insertion
routine, all objects o such that χ(X) is true
w.r.t. the current agent state when X := o.”
In such a case, the code call condition χ is used to identify the objects
to be inserted, and the insFinanceRecord function specifies the insertion
routine to be used.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 70/361
1. Impact Architecture
5. Software Abstractions
Agent a may manage multiple data types τi with peculiar
insertion routines insτi , i ∈ {1, . . . , n}.
Associate with a an insertion routine insa as follows:
given either a set O of objects (or a code call condition
χ(X) of the above type), insa (χ(X), O S ) is a generic
method that selects which of the insertion routines
insτi , associated with the different data structures,
should be invoked to accomplish the desired insertion.
Assume that an insertion function insa and a deletion
function dela may be associated with any agent a in this
way.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 71/361
1. Impact Architecture
6. Message Box
1.6 Message Box
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 72/361
1. Impact Architecture
1
2
3
6. Message Box
Each agent’s associated software code
includes a special type called Msgbox (short
for message box).
The message box is a buffer that may be filled
(when it sends a message) or flushed (when
it reads the message) by the agent.
In addition, we assume the existence of an
operating-systems level messaging protocol
(e.g., SOCKETS or TCP/IP [8]) that can fill in
(with incoming messages) or flush (when a
message is physically sent off) this buffer.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 73/361
1. Impact Architecture
6. Message Box
The msgbox operates on objects of the form
(i/o,”src”,”dest”,”message”,”time”).
1
2
3
4
5
i/o signifies an incoming or outgoing message
respectively.
”src” specifies the originator
”dest” specifies the destination.
”message” is a table containing triples
(”command”, ”LFlag”, ”Data”),
where ”command” is the name of a command,
”LFlag” a flag, and ”Data” the message content (of
data type Any).
”time” is the time at which the message was sent.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 74/361
1. Impact Architecture
6. Message Box
Message box management – some functions
sendMessage
sendMessage(<dest_agent>, <message>):
Places tuple (o, ”src”, ”dest”, ”message”, ”time”) into
Msgbox. Parameter o signifies an outgoing message,
and ”src” is the agent at hand.
When a call of sendMessage
sendMessage(”dest”, ”message”) is
executed, the state of src
src’s Msgbox changes by the
insertion of the above tuple, denoting the sending of a
message from src to a given destination agent dest
with the message body ”message”.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 75/361
1. Impact Architecture
6. Message Box
getMessages
getMessages():
Read all tuples (i, ”src”, ”a”, ”msg”, ”time”)
from Msgbox of agent a (i flags an incoming
message and ”time” the time at which the
message was received.
Note: returns all messages from all agents to
agent a .
timedGetMessages
timedGetMessages(<op>, <valid>):
Read all tuples
t =def (i, <src>, <agent>, <message>, time)
from Msgbox for which t.time op valid is true,
where op is any of the standard comparison
operators <, >, ≤, ≥, or =.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 76/361
1. Impact Architecture
6. Message Box
Example 1.20 (STORE Revisited)
profiling agent should classify a user U with ssn S, and
needs credit information for U from the credit agent:
1 profiling sends to credit a message M1 of a special
format, e.g., a string ”ask_provideCreditInfo_S_low,”
encoding the request for S’s credit information:
profiling
sendMessage
sendMessage(profiling
profiling, credit
credit, M1 ).
profiling
2 credit reads M1 , using getMessage
getMessage(profiling
profiling)
(periodically, or triggered by M1 ’s arrival), assembles a
message M2 and replies:
credit
sendMessage
sendMessage(credit
credit, profiling
profiling, M2 ).
profiling
3 profiling reads M2 , using getMessage
getMessage(profiling
profiling) (e.g.,
triggered by M2 ’s arrival), and uses M2 to construct
the desired UserProfile.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 77/361
1. Impact Architecture
6. Message Box
Integrity Constraints
Recall: Each agent has an associated agent state, O ,
which is a set of objects (of proper types).
Not every set of such objects may be legal for O .
O must satisfy axioms in general.
Definition 1.21 (Integrity Constraints IC
IC)
An integrity constraint IC is an expression of the form
ψ ⇒ χ
where ψ is a safe code call condition, and χ is an atomic
code call condition such that every root variable in χ
occurs in ψ.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 78/361
1. Impact Architecture
6. Message Box
Examples:
•
S = 123_45_6789
⇒
not_in(( spender(low), profiling : classifyUser
classifyUser((S))) .
•
in(( spender(medium), profiling : classifyUser
classifyUser((S))) )
⇒
not_in(( spender(high), profiling : classifyUser
classifyUser((S)))
•
R.sat_id = sat_1 ⇒ R.2dloc.x ≥ 0.
•
R1.2dloc.x = R2.2dloc.x &
R1.2dloc.y = R2.2dloc.y
⇒
R1.height = R2.height
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 79/361
1. Impact Architecture
6. Message Box
Definition 1.22
Let O S be an agent state and IC = ψ ⇒ χ an integrity
constraint. Then O S satisfies IC, denoted O S |= IC, if for
every legal assignment of objects from O S to the variables
in IC, either ψ is false or χ is true.
Let IC be a (finite) collection of integrity constraints IC,
IC,
and let O S be an agent state. Then O S satisfies IC
denoted O S |= IC
IC, if O S |= IC for every IC ∈ IC
IC.
Note: Integrity constraints are universally quantified. Can
express easily, e.g., functional dependencies in databases.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 80/361
1. Impact Architecture
7. Summary, References
1.7 Summary, References
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 81/361
1. Impact Architecture
7. Summary, References
In order to agentize legacy code, we must make the most
important datatypes and functions of it available.
1
2
3
4
5
The IMPACT code call mechanism abstracts from
given legacy code, S , and declaratively describes its
effects.
It provides functions f named code calls:
S : f ( d1 , . . . , dn) .
To encapsulate these functions in a logical language,
we use code call atoms: in(( X, S : f ( d1 , . . . , dn)) .
Code call atoms can be conjoined, also with
comparisons, and enable code call conditions.
Safety ensures evaluability of code call conditions.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 82/361
1. Impact Architecture
7. Summary, References
[1] Bayardo, R., et al. (1997).
Infosleuth: Agent-based Semantic Integration of
Information in Open and Dynamic Environments.
In J. Peckham (Ed.), Proceedings of ACM SIGMOD
Conference on Management of Data, Tucson, Arizona,
pp. 195–206.
[2] Brink, A., S. Marcus, and V. Subrahmanian (1995).
Heterogeneous Multimedia Reasoning.
IEEE Computer 28(9), 33–39.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 83/361
1. Impact Architecture
7. Summary, References
[3] Chawathe, S., et al. (1994, October).
The TSIMMIS Project: Integration of Heterogeneous
Information Sources.
In Proceedings of the 10th Meeting of the Information
Processing Society of Japan, Tokyo, Japan.
Also available via anonymous FTP from host
db.stanford.edu, file
/pub/chawathe/1994/tsimmis-overview.ps.
[4] Genesereth, M. R. and S. P. Ketchpel (1994).
Software Agents.
Communications of the ACM 37(7), 49–53.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 84/361
1. Impact Architecture
7. Summary, References
[5] Subrahmanian, V., P. Bonatti, J. Dix, T. Eiter, S. Kraus,
F. Özcan, and R. Ross (2000).
Heterogenous Active Agents.
MIT-Press.
[6] Weiss, G. (Ed.) (1999).
Multi-Agent Systems.
MIT-Press.
[7] Wiederhold, G. (1993).
Intelligent Integration of Information.
In Proceedings of ACM SIGMOD Conference on
Management of Data, Washington, DC, pp. 434–437.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 85/361
1. Impact Architecture
7. Summary, References
[8] Wilder, F. (1993).
A Guide to the TCP/IP Protocol Suite.
Artech House.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 86/361
2. Actions and Agent Programs
Chapter 2. Actions and Agent
Programs
2.1
2.2
2.3
2.4
2.5
2.6
Actions and Agent Programs
Action Base
Exec.
Action Constr.
Syntax
Status Sets
Summary
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 87/361
2. Actions and Agent Programs
Here we describe how to program an agent.
This program is a set of rules which have action
status atoms in their heads and code call
conditions (as well as action status atoms) in
their bodies. The semantics of such a program
determines, which actions should be carried
out. But these actions might be incompatible,
so we need to apply a notion of concurrency
(which is a plug-in).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 88/361
2. Actions and Agent Programs
A Single
Actions
agent
Agent Program P
Sem
conc
Set of
Status
Atoms
Code Calls
State O
Actions
to execute
IN
Messages
OUT
Messages
Prof. Dr. Jürgen Dix · LIP 6, UPM
Legacy Data
Update
Panam Seminaire, 17. March 2007 89/361
2. Actions and Agent Programs
Already considered:
Underlying Software Code:
Basic set of data structures and legacy code, S ,
on top of which the agent is built.
The set of all such objects, across all the data
types managed by the software code, is called
the state of the agent at time t .
Integrity Constraints:
The agent has an associated finite set, IC
IC.
These integrity constraints reflect the
expectations, on the part of the designer of
the agent, that the state of the agent must
satisfy.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 90/361
2. Actions and Agent Programs
New
Actions:
Each agent has an associated set of actions.
An action is implemented by a body of code
implemented in any suitable imperative (or
declarative) programming language.
Action Constraints:
Prevent the agent from concurrently executing
certain actions.
Agent Programs:
An agent program is a set of rules, in a
language defined below, that an agent’s
creator might use to specify the principles
according to which the agent behaves, and the
policies governing what actions the agent
takes, from among a possible plethora of
possible actions.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 91/361
2. Actions and Agent Programs
In short, the agent program associated with an
agent encodes the “do’s and don’t’s” of the
agent.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 92/361
2. Actions and Agent Programs
Agent Decision Cycle
1. Every agent manages a set of data types through a set
of well-defined methods.
2. These data types and methods include a message box
data structure, with associated manipulation
algorithms.
3. At a given point t in time, the state of an agent, O ,
reflects the set of data items the agent currently has
access to—these data items must all be of one of the
data types alluded to above.
4. At time t, the agent may receive a set of new messages.
They constitute a change to agent state.
5. The change may trigger some rules in the agent’s
associated Agent Program.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 93/361
2. Actions and Agent Programs
Based on the selected semantics for agent programs, the
agent makes a decision on what actions to actually
perform, in keeping with the rules governing its behavior
encoded in its associated Agent Program.
This computation is made by executing a program called
ComputeSem which computes the semantics of the agent.
6. The actions that are supposed to be performed
according to the selected semantics are then
concurrently executed, using the notion of concurrency,
conc, selected by the agent’s designer.
The agent’s state may (possibly) change as a
consequence of the performance of such actions. In
addition, the message box of other agents may also
change.
7. The cycle continues perpetually.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 94/361
2. Actions and Agent Programs
Definition 2.1 (Agent-Decision-Cycle)
Agent-Decision-Cycle(Curr: agent_state;
IC
IC: integrity constraint set;
AC
AC: action constraint set;
AB : action base;
conc: notion of concurrency;
Newmsg: set of messages )
1. while true do
2. { DoSet := ComputeSem
ComputeSem(Curr, IC
IC, AC
AC, AB
AB, conc, Newmsg);
(? find a set of actions to execute based on messages received ?)
3. Curr := result of executing the single action conc(DoSet); }
end.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 95/361
2. Actions and Agent Programs
Example 2.2 (CFIT Example: Multiagent Interaction)
Every ∆ units of time, the autoPilot agent receives a
message from a clock agent. This message includes a
“Wake” request telling the autoPilot agent to wake up.
The agent program of autoPilot causes the wake action to
be executed, which in turn triggers other actions. These
include:
Executing an action
sendMessage
sendMessage(gps, <service_request>) where
<service_request> of the gps agent requests the
current plane location.
The gps agent executes getAllMsgs and retrieves the
message sent by autoPilot
autoPilot.
The decision program of gps executes this request and
also sendMessage
sendMessage(autoPilot, <answer>) where
<answer> is the answer to the request of autoPilot
autoPilot.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
96/361
2. Actions and Agent Programs
autoPilot executes getAllMsgs and retrieves the
gps.
message sent by gps
The decision program of autoPilot checks if the plane
location sent by gps with the one of the flight plan.
If yes, autoPilot executes the action sleep and goes to sleep for
another ∆ units of time.
If not, autoPilot executes sendMessage
sendMessage(terrain, <request>) where
<request> requests the terrain agent to send the plane elevation at
gps
its current location (gps
gps) as well as the No_go areas.
terrain executes getAllMsgs and retrieves the message
sent by autoPilot
autoPilot.
The decision program of terrain executes this request
autoPilot
and also sendMessage
sendMessage(autoPilot
autoPilot, Ans) where Ans is the
answer to the request of autoPilot
autoPilot.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007
97/361
2. Actions and Agent Programs
autoPilot executes the getAllMsgs action and retrieves
the message sent by terrain
terrain.
autoPilot then executes replan with the new (correct)
plane location and the terrain “no go” areas.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 98/361
2. Actions and Agent Programs
1. Action Base
2.1 Action Base
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 99/361
2. Actions and Agent Programs
1. Action Base
Definition 2.3 (Action; Action Atom)
An action α consists of six components:
Name: A name, usually written α (X1 , . . . , Xn ), where
the Xi ’s are root variables.
Schema: A schema, usually written as (τ1 , . . . , τn ), of
types. Intuitively, this says that the variable Xi
must be of type τi , for all 1 ≤ i ≤ n.
Action Code: This is a body of code that executes the
action.
Pre: A code-call condition χ, called the
α)
precondition of the action, denoted by P re(α
α) must be safe modulo the variables
(Pre(α
X1 ,. . . ,Xn );
α) of code-call conditions;
Add: a set Add (α
α) of code-call conditions.
Del: a set Del (α
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 100/361
2. Actions and Agent Programs
1. Action Base
An action atom is a formula α (t1 , . . . , tn ), where ti is a
term, i.e., an object or a variable, of type τi , for all
i = 1, . . . , n.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 101/361
2. Actions and Agent Programs
1. Action Base
Definition 2.4 (Action Base)
An action base, AB
AB, is any finite collection of actions.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 102/361
2. Actions and Agent Programs
1. Action Base
Item
Classical AI
IMPACT framework
Agent State
Set of logical atoms
Arbitrary data structures
Precondition
Logical formula
Code call condition
Add/delete list
set of ground atoms
Code call condition
Action Implementation
Via add/delete lists
Via arbitrary code
Action Reasoning
Via add/delete lists
Via add list and delete list
We assume that the precondition, add and delete lists associated with
an action, correctly describe the behavior of the action code
associated with the action.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 103/361
2. Actions and Agent Programs
1. Action Base
Example 2.5 (STORE Example Revisited)
The profiling agent might have the following action:
Name:
update_highProfile
update_highProfile(Ssn, Name, Profile)
Schema:
(String, String, UserProfile)
Pre:
in(( spender(high), profiling : classifyUser
classifyUser((Ssn)))
Del:
in(( hSsn, Name, OldProfilei, profiling : all
all((0 highProfile 0))
Add:
in(( hSsn, Name, Profilei, profiling : all
all((0 highProfile 0))
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 104/361
2. Actions and Agent Programs
1. Action Base
This action updates the user profiles of those users who
are high spenders.
In order to determine the high spenders, it first invokes
the classifyUser code call.
After obtaining the target list of users, it updates entries of
those users in the profile database.
The profiling agent may also have similar actions for low
and medium spenders.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 105/361
2. Actions and Agent Programs
1. Action Base
Example 2.6 (CFIT Revisited)
Suppose the autoPilot agent in the CFIT example has the
following action for computing the current plane location:
Name: compute_currentLocation
compute_currentLocation(Report)
Schema: (SatelliteReport)
in(( Report, msgbox : getVar
getVar((Msg.Id, ”Report”)))
Pre:
Del:
in(( OldLoc, autoPilot : location
location(()) .
Add: in(( NewLoc, autoPilot : location
location(()) &
(
in( FlightRoute, autoPilot : getFlightRoute
getFlightRoute(()) &
in(( Velocity, autoPilot : velocity
velocity(()) &
in(( NewLoc, autoPilot : calculateLocation
calculateLocation((OldLoc, FlightRoute, Velocity)))
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 106/361
2. Actions and Agent Programs
1. Action Base
This action requires a satellite report, which is produced
by the gps agent by merging the GPS Data.
Then, it computes the current location of the plane based
on this report as well as the allocated flight route of the
plane.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 107/361
2. Actions and Agent Programs
2. Exec.
2.2 Exec.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 108/361
2. Actions and Agent Programs
2. Exec.
Execution and Concurrency of actions
What is the result of executing an action?
Definition 2.7 ((θ, γ)-Executability)
~ be an action and S = (T
T S ,F
F S ,C
C S ) a software
Let α (X)
code.
~ of α (X)
~ is executable in state O S ,
A ground instance α (X)θ
~
α(X))θ
if, by definition, there exists a solution γ of P re(α
w.r.t. O S .
~ is (θ, γ)-executable in state O S , and
In this case, α (X)
~
α(X), θ, γ) is a feasible execution triple (FET for O S .
(α
~ OS ) we denote the set of all pairs (θ, γ) such
α(X),
By ΘΓ(α
~ θ, γ) is a FET in state O S .
α(X),
that (α
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 109/361
2. Actions and Agent Programs
2. Exec.
Action Execution
Definition 2.8
~ θ, γ) be a FET in state O S . Then the result of
α(X),
Let (α
~ w.r.t. (θ, γ) is the state
executing α (X)
~ θ, γ), O S ) = ins(O
α(X),
Oadd , del(O
Odel , O S )),
apply((α
where
~
α(X)θ)γ)
Oadd = O _Sol(Add (α
and
~
α(X)θ)γ);
Odel = O _Sol(Del (α
i.e., the state resulting if first all objects in solutions of call
~
α(X)θ)γ
conditions from Del (α
on O S are removed, and
then all objects in solutions of call conditions from
~
α(X)θ))γ
Add (α
on O S are inserted.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 110/361
2. Actions and Agent Programs
2. Exec.
Concurrent Actions
Example 2.9 (Concurrency)
α1 , α 2 } on an agent
Consider the set of actions ACS = {α
state O S , where
α 1 : Pre: in(( val, a : f ())
Del: in(( val, a : f ())
Add: {}
α 2 : Pre: in(( val, a : f ())
Del: {}
Add: {}
where in(( val, a : f ()) is true in OS .
Problem: Executing α 1 effects that α 2 is no longer
executable.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 111/361
2. Actions and Agent Programs
2. Exec.
There are many ways to resolve this. This leads to a notion
of concurrency
Definition 2.10
A notion of concurrency is a function, conc, that takes, as
input, a state OS and a set of execution triples AS, and
returns, as output, a single execution triple such that:
1
2
α} is a singleton action, then
if AS = {α
OS , ASi ) = α .
conc(O
~ i ), θi , γi ) for
OS , ASi ) = (α
αi (X
if AS1 ⊆ AS2 and conc(O
i = 1, 2, and α 2 is (θ2 , γ2 )-executable in state O S , then
α 1 is (θ2 , γ2 ) executable in state O S .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 112/361
2. Actions and Agent Programs
2. Exec.
Some Notions of Concurrency
Suppose AS = {α1 , . . . , αn } is a set of actions.
Weakly Concurrent Execution (Naive):
Takes add/del list of all actions αi and executes them in
parallel. (linear complexity in propositional case)
Sequential-Concurrent Execution:
Take some executable sequence απ(1) ,. . . απ(n) .
(nondeterministic; NP-complete)
Full-Concurrent Execution: Checks that every
sequence απ(1) ,. . . απ(n) is executable. (coNP-complete)
Other notions of concurrency might be used in IMPACT by
the agent developer.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 113/361
2. Actions and Agent Programs
2. Exec.
Recall: ins and del are the generic insertion and
deletion function
apply(ACS, O S ):
For any set ACS of actions, the execution of AS on O S
is the execution of the set
~ θ, γ) | α (~t) ∈ AS, α (X)θ
~ = α (~t)θ ground,
α(X),
{(α
~
α(X))}
(θ, γ) ∈ ΘΓ(α
of all FETs stemming from some grounded action in
AS. Then, apply(AS, O S ) denotes the resulting state.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 114/361
2. Actions and Agent Programs
2. Exec.
Definition 2.11 (Weakly Concurrent Execution)
Suppose AS is a set of FETs in the agent state O S . The
weakly concurrent execution of AS in O S , is defined to
be the agent state
Oadd , del(O
Odel , O S )),
apply(AS, O S ) =def ins(O
where
Oadd =def
[
~
α(X)θ)γ),
O _Sol(Add (α
~
α(X),θ,γ)∈AS
(α
Odel =def
[
~
α(X)θ)γ).
O _Sol(Del (α
~
α(X),θ,γ)∈AS
(α
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 115/361
2. Actions and Agent Programs
2. Exec.
Definition 2.12 (Sequential-Concurrent Execution)
~ i , θi , γi )) | 1 ≤ i ≤ n} be a set of FETs on
αi (X
Let AS =def {(α
state O S . Then, AS is S -concurrently executable in O S , if
a permutation π of AS and a sequence of states
O S0 , . . . , O Sn exist where:
O S0 = O S and
~ π(i) ) is (θπ(i) , γπ(i) )-executable in the state O i−1 ,
α π(i) (X
S
for all 1 ≤ i ≤ n, and
~ π(i) , θπ(i) , γπ(i) ), O i−1 ), or all 1 ≤ i ≤ n.
O Si = apply((X
S
Such AS is π -executable, and O Sn is the result of
executing AS[π].
An action set ACS is S-concurrently executable on O S , if
~ θ, γ) | α (~t) ∈ ACS , α (X)θ
~ = α (~t)θ ground, (θ, γ) ∈ ΘΓ(α
~
α(X),
α(X))}
{(α
is S-concurrently executable on O S .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 116/361
2. Actions and Agent Programs
2. Exec.
Definition 2.13 (Full-Concurrent Execution)
~ i , θi , γi )) | 1 ≤ i ≤ n} be a set of FETs
αi (X
Let AS =def {(α
and O S an agent state. Then, AS is is F -concurrently
executable in state O S , if and only if:
1
2
For every permutation π, AS is π-executable.
For any two permutations π1 , π2 of AS, the final states
AS[π1 ] and AS[π2 ], respectively, which result from the
executions are identical.
A set ACS of actions is F -concurrently executable on the
agent state O S , if the set
~ θ, γ) | α (~t) ∈ ACS , α (X)θ
~ = α (~t)θground, (θ, γ) ∈ ΘΓ(α
~
α(X),
α(X))},
{(α
is F -concurrently executable on O S .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 117/361
2. Actions and Agent Programs
2. Exec.
Example 2.14 (Concurrency revisited)
α1 , α 2 } on an agent
Consider the set of actions ACS = {α
state O S , where
α 1 : Pre: in(( val, a : f ())
Del: in(( val, a : f ())
Add: {}
α 2 : Pre: in(( val, a : f ())
Del: {}
Add: {}
where in(( val, a : f ()) is true in O S .
weakly concurrent execution of ACS makes
in(( val, a : f ()) false in the agent state.
ACS is S-concurrently executable: π = α 2 , α 1
ACS is not F -concurrently executable: for
π = identity, ACS is not S-concurrently executable.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 118/361
2. Actions and Agent Programs
2. Exec.
Throughout the rest of this course, we will assume that
the developer of an agent has chosen some notion, conc ,
of concurrent action execution for his agent.
This may vary from one agent to another, but each agent
uses a single notion of concurrency. Thus, when talking
of an agent a, the phrase
“AS is concurrently executable”
is to be considered to be synonymous with the phrase
“AS is concurrently executable w.r.t. the notion conc
used by agent a.”
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 119/361
2. Actions and Agent Programs
3. Action Constr.
2.3 Action Constr.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 120/361
2. Actions and Agent Programs
3. Action Constr.
In some cases, the concurrent execution of
certin actions might not be desired.
Example 2.15 (STORE Example)
Reconsider the profiling agent.
1 If a user is classified as a high spender, then
the profiling agent cannot execute
update_highProfile and update_lowProfile
concurrently.
2 The profiling agent cannot classify a user
profile, if it is simultaneously updating the
profile of that user.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 121/361
2. Actions and Agent Programs
3. Action Constr.
Definition 2.16 (Action Constraint)
An action constraint AC is an expression of the form:
~ 1 ), . . . , α k (X
~ k )} ←- χ
α1 (X
{α
(1)
~ 1 ), . . . , α k (X
~ k ) are action names, and χ is a
where α 1 (X
code call condition.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 122/361
2. Actions and Agent Programs
3. Action Constr.
Example 2.17 (STORE Example Revisited)
The following are action constraints for the above
restrictions on the profiling agent:
1.
{ update_highProfile
update_highProfile(Ssn1, Name1, profile),
update_lowProfile
update_lowProfile(Ssn2, Name2, profile) }←in(( spender(high), profiling : classifyUser
classifyUser((Ssn1))) &
Ssn1 = Ssn2 & Name1 = Name2
2.
{ update_userProfile
update_userProfile(Ssn1, Name1, Profile),
classify_user (Ssn2, Name2) }←Ssn1 = Ssn2 & Name1 = Name2
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 123/361
2. Actions and Agent Programs
3. Action Constr.
Definition 2.18 (Action Constraint Satisfaction)
A set S of ground actions satisfies an action constraint
~ 1 ), . . . , α k (X
~ k )} ←- χ on a state O S , denoted
α1 (X
AC : {α
S, O S |= AC, if there is no legal assignment θ of objects in
~
α1 (X)θ,
O S to the variables in AC such that χθ is true and {α
~
. . . , α k (X)θ} ⊆ S holds.
S satisfies a set AC of actions constraints on O S , denoted
S, O S |= AC
AC, if S, O S |= AC for every AC ∈ AC
AC.
Note: Action constraint satisfaction is hereditary w.r.t. the
set of actions involved, i.e., S, O S |= AC implies that
S 0 , O S |= AC
AC, for every S 0 ⊆ S.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 124/361
2. Actions and Agent Programs
4. Syntax
2.4 Syntax
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 125/361
2. Actions and Agent Programs
4. Syntax
Thus far, we have introduced the following:
S : f ( a1 , . . . , an) ): this provides a single
Software Code Calls (S
framework within which the interoperation of diverse
pieces of software may be accomplished;
OS ): this describes exactly what data objects
Software/Agent states (O
are being managed by a software package at a given
point in time;
IC
Integrity Constraints (IC
IC): this specifies exactly which software
states are “valid” or “legal”;
AB
Action Base (AB
AB): this is a set of actions that an agent can physically
execute (if the preconditions of the action are satisfied
by the software state);
Concurrency Notion (conc): this is a function that merges together a
set of actions an agent is attempting to execute into a
single, coherent action;
AC
Action Constraints (AC
AC): this specifies whether a certain set of
actions is incompatible.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 126/361
2. Actions and Agent Programs
4. Syntax
Definition 2.19 (Action Status Atom)
Suppose α (~t) is an action atom, where ~t is a
vector of terms (variables or objects) matching
the type schema of α . Then, the formulas
α(~t)), F(α
α(~t)), O(α
α(~t)), W(α
α(~t)), and
P(α
α(~t)) are action status atoms.
Do (α
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 127/361
2. Actions and Agent Programs
4. Syntax
α means that the agent is permitted to take
Pα
action α ;
α means that the agent is forbidden from
Fα
taking α ;
α means that the agent is obliged to take
Oα
action α ;
α means that obligation to take action α is
Wα
waived; and,
Do α means that the agent does take action
α.
The set AS = {P, F, O, W, Do } is called the
action status set .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 128/361
2. Actions and Agent Programs
4. Syntax
Definition 2.20 (Action Rule)
An action rule (rule, for short) is a clause r of
the form
Op α(~t) ← L1 , . . . , Ln
(2)
where Op α (~t) is an action status atom, and each
of L1 , . . . , Ln is either an action status atom, or a
code call atom, each of which may be preceded
by a negation sign (¬).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 129/361
2. Actions and Agent Programs
4. Syntax
We require that each rule r be safe in the sense
that:
1 Bcc (r) is safe modulo the root variables
+
occurring explicitly in Bas
(r), and
2 the root of each variable in r occurs in
+
(r).
Bcc (r) ∪ Bas
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 130/361
2. Actions and Agent Programs
4. Syntax
All variables in a rule r are implicitly universally
quantified at the front of the rule.
A rule is positive, if no negation sign occurs in front of
an action status atom.
For any rule r of the form (2), we denote by
H(r), the atom in the head of r,
B(r), the collection of literals in the body;
B − (r) the negative literals in B(r),
B + (r) the positive literals in B(r),
¬.B − (r) the atoms of the negative literals in B − (r).
Finally, the index as (resp., cc) for any of these sets
denotes restriction to the literals involving action
status atoms (resp., code call atoms).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 131/361
2. Actions and Agent Programs
4. Syntax
Definition 2.21 (Agent Program)
An agent program P is a finite collection of rules.
An agent program P is positive, if all its rules are
positive.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 132/361
2. Actions and Agent Programs
4. Syntax
Example 2.22 (Simple Driving Example)
Consider an agent driving in an autonomous car.
Capability: Select the correct driving lane out of
{l_lane, r_lane} to go in, depending on the agent state.
Software code: lane status database
free_lanes(() returns the free lanes.
Code call status : free_lanes
Actions:
go_rightmost
go_rightmost: Pre: void
Add = Del = ∅
drive
drive(X): Pre: in(( X , status : free_lanes
free_lanes(())
Add: go_in(X)
Del: go_in(Y )
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 133/361
2. Actions and Agent Programs
4. Syntax
Agent Program:
r1 :
r2 :
go_rightmost
go_rightmost) ←
O(go_rightmost
drive
go_rightmost
O(drive
drive(r_lane)) ← Do (go_rightmost
go_rightmost)
drive
r3 :
F(drive
drive(X )) ← not_in(( X , status : free_lanes
free_lanes(())
drive
r4 : Do (drive
drive(l_lane)) ← in(( l_lane, status : free_lanes
free_lanes(()) &
drive
F(drive
drive(r_lane))
Note: r1 encodes the “Go Rightmost” norm
Agent program selects, by its semantics (introduced
below), for each lane status the proper lane to go in.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 134/361
2. Actions and Agent Programs
5. Status Sets
2.5 Status Sets
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 135/361
2. Actions and Agent Programs
5. Status Sets
If an agent uses an agent program P , the
question that the agent must answer, over and
over again is:
What is the set of all action status atoms of the
form Do α that are true with respect to P , the
current state, OS , the underlying set AC of
action constraints, and the set IC of underlying
integrity constraints on agent states?
This defines the set of actions that the agent
must execute concurrently.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 136/361
2. Actions and Agent Programs
5. Status Sets
Definition 2.23 (Status Set)
A status set is any set S of ground action status atoms
over S . For any operator Op ∈ {P, Do , F, O, W }, we
α | Op(α
α) ∈ S}.
denote by Op(S) the set Op(S) = {α
Informally, a status set S represents information about the
α) occurs in S,
status of ground actions. If some atom Op(α
then this means that the status Op is true for α .
Note: status sets are not a semantics for agent programs,
but our semantics for Agent Programs build on them.
Intuitively, a “feasible” status set consists of assertions
about the status of actions compatible with (but are not
necessarily enforced) the rules of the agent program and
the underlying action and integrity constraints.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 137/361
2. Actions and Agent Programs
5. Status Sets
Deontic and Action Consistency
Definition 2.24
A status set S is called deontically consistent, if it satisfies
the following rules for every ground action α :
α ∈ S, then Wα
α∈
If Oα
/S
α ∈ S, then Fα
α∈
If Pα
/S
α ∈ S, then O S |= ∃∗ Pre(α
α)
If Pα
∗
α
α),
∃ Pre(α ) . . . existential closure of Pre(α
This ensures that α is executable in O S .
A status set S is called action consistent, if S, O S |= AC
holds.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 138/361
2. Actions and Agent Programs
5. Status Sets
Deontic and Action Closure
Besides consistency, we also wish that the presence of
certain atoms in S entails the presence of other atoms in S.
drive
For example, if Odrive
drive(r_lane) is in S, then we expect that
drive
Pdrive
drive(r_lane) is in S.
Definition 2.25 (Deontic Closure)
Deontic closure of a status set S, denoted D-Cl(S), is the
closure of S under the rule
α ∈ S, then Pα
α ∈ S,
If Oα
where α is any ground action.
S is deontically closed, if S = D-Cl(S).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 139/361
2. Actions and Agent Programs
5. Status Sets
Definition 2.26 (Action Closure)
The action closure of a status set S, denoted
A-Cl(S), is the closure of S under the rules
α ∈ S, then Do α ∈ S,
If Oα
α ∈ S,
If Do α ∈ S, then Pα
where α is any ground action.
Status S is action-closed, if S = A-Cl(S).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 140/361
2. Actions and Agent Programs
5. Status Sets
Proposition
Let S be a status set. Then,
1 A-Cl(S) = S implies D-Cl(S) = S
2 D-Cl(S) ⊆ A-Cl(S), for all S.
A status set S which is consistent and closed is certainly a
meaningful assignment of a status to each ground action.
Note that we may have ground actions α that do not occur
anywhere within a status set—this means that no
commitment about the status of α has been made.
The following definition specifies how we may “close” up
a status set under the rules expressed by an agent
program P .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 141/361
2. Actions and Agent Programs
5. Status Sets
Definition 2.27 (Operator AppP ,O
OS (S))
Suppose P is an agent program, and O S is an agent state.
Then, AppP ,O
OS (S) is defined to be the set of all ground
action status atoms A such that there exists a rule in P
having a ground instance of the form r : A ← L1 , . . . , Ln
such that
1
2
3
4
+
−
Bas
(r) ⊆ S and ¬.Bas
(r) ∩ S = ∅, and
+
every code call χ ∈ Bcc
(r) succeeds in O S , and
−
every code call χ ∈ ¬.Bcc
(r) does not succeed in O S ,
and
α) ∈ B + (r) ∪ {A} such that
for every atom Op(α
Op ∈ {P, O, Do }, the action α is executable in state
OS .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 142/361
2. Actions and Agent Programs
5. Status Sets
Feasible Status Sets
The above notions, combined together, give a formal
notion of “feasible” status set.
Definition 2.28 (Feasible Status Set)
Let P be an agent program and O S an agent state. A
status set S is a feasible status set for P on O S , if the
following holds:
(S1) AppP ,O
OS (S) ⊆ S;
(S2) S is deontically and action consistent;
(S3) S is action closed and deontically closed;
(S4) O S0 |= IC
IC, where O S0 = apply(Do (S), O S ) is the
state which results after taking the actions in
Do (S) on O S (state consistency).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 143/361
2. Actions and Agent Programs
5. Status Sets
In general, action programs may have one, zero, or several
feasible status sets.
Example 2.29 (Simple Driving Example Revisited)
Let O S be such that status : free_lanes
free_lanes(() = {l_lane, r_lane}.
go_rightmost
go_rightmost
Consider S = { Ogo_rightmost
go_rightmost, Do go_rightmost
go_rightmost, Pgo_rightmost
go_rightmost,
drive
drive
drive(r_lane), Do drive
drive(r_lane), Pdrive
drive(r_lane) }.
Odrive
(S1):
go_rightmost , Odrive
drive
AppP ,O
drive(r_lane) } ⊆ S
OS (S) = { Ogo_rightmost
|
{z
}
rule r1
|
{z
rule r2
}
(S2): Obviously, S is deontically and action consistent.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 144/361
2. Actions and Agent Programs
5. Status Sets
(S3): A-Cl(S) = S, thus S is action and deontically
closed.
(S4): state consistency holds (no integrity constraints).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 145/361
2. Actions and Agent Programs
5. Status Sets
Example 2.30
The following (artificial) example shows that
some agent programs may have no feasible
status sets at all.
α ←
Pα
α ←
Fα
Clearly, if the current object state allows α to be
executable, then no status set can satisfy both
the closure under program rules requirement,
and the deontic consistency requirement.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 146/361
2. Actions and Agent Programs
5. Status Sets
Some Properties of Feasible Status Sets
Proposition
Let S be a feasible status set. Then,
α) ∈ S, then OS |= Pre(α
α);
1 If Do (α
α∈
α) ∈
2 If Pα
/ S, then Do (α
/ S;
α ∈ S, then O S |= Pre(α
α);
3 If Oα
α ∈ S, then Fα
α∈
4 If Oα
/ S.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 147/361
2. Actions and Agent Programs
5. Status Sets
Rational Status Sets
Feasible status sets may include status assignments that
are not strictly enforced.
Example 2.31 (Simple Driving Example)
Let again O S be such that status : free_lanes
free_lanes(() = {l_lane, r_lane}.
go_rightmost
go_rightmost
Consider S 0 = { Ogo_rightmost
go_rightmost, Do go_rightmost
go_rightmost, Pgo_rightmost
go_rightmost,
drive
drive
Odrive
drive(r_lane), Do drive
drive(r_lane), Pdrive
drive(r_lane),
drive
Pdrive
drive(l_lane) }.
S 0 is a feasible status set.
drive
Pdrive
drive(l_lane) may be omitted (no “reason” to
include it)
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 148/361
2. Actions and Agent Programs
5. Status Sets
Principle: Each atom Opα in S must be “founded”
through (i) a rule in the agent program, or (ii) through
action/deontic closure rules.
In particular, if execution of actions must be founded.
The notion of a rational status set is postulated to
accommodate this kind of reasoning.
Definition 2.32 (Groundedness; Rational Status Set)
A status set S is grounded, if there exists no status set
S 0 6= S such that S 0 ⊆ S and S 0 satisfies conditions
(S1)–(S3) of a feasible status set.
A status set S is a rational status set, if S is a feasible
status set and S is grounded.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 149/361
2. Actions and Agent Programs
5. Status Sets
Example 2.33 (Driving Example Continued)
Let again O S be such that status : free_lanes
free_lanes(() = {l_lane,
r_lane}.
go_rightmost
go_rightmost
The set S = { Ogo_rightmost
go_rightmost, Do go_rightmost
go_rightmost, Pgo_rightmost
go_rightmost,
drive
drive
Odrive
drive(r_lane), Do drive
drive(r_lane), Pdrive
drive(r_lane) }.
is a rational status set:
S is a feasible status set
Rules r1 and r must fire in any feasible status
set
Thus, by (S1) and (S3) no smaller status set
satisfying (S1)-(S3) exists.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 150/361
2. Actions and Agent Programs
5. Status Sets
Note: Groundedness does not include condition
(S4) of a feasible status set.
A moment of reflection will show that omitting
this condition is indeed appropriate.
Recall that the integrity constraints must be
maintained when the current agent state is
changed into a new one.
If we were to include the condition (S4) in
groundedness, it may happen that the agent is
forced to execute some actions which the
program does not mention, just in order to
maintain the integrity constraints.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 151/361
2. Actions and Agent Programs
5. Status Sets
We define, for every positive program P and
agent state OS , an operator TP ,O
OS that maps a
status set S to another status set.
Definition 2.34 (TP ,O
OS Operator)
Suppose P is an agent program and O S an
agent state. Then, for any status set S,
TP ,O
OS (S) = AppP ,O
OS (S) ∪ D-Cl(S) ∪ A-Cl(S).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 152/361
2. Actions and Agent Programs
5. Status Sets
Lemma 2.35
Let P be an agent program, let O S be any agent
state, and let S be any status set. If S satisfies (S1)
and (S3) of feasibility, then S is pre-fixpoint of
TP ,O
OS , i.e., TP ,O
OS (S) ⊆ S.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 153/361
2. Actions and Agent Programs
5. Status Sets
Theorem 2.36
Let P be a positive agent program, and let O S be
an agent state. Then, S is a rational status set of P
on O S , if and only if S = lfp(TP ,O
OS ) and S is a
feasible status set.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 154/361
2. Actions and Agent Programs
5. Status Sets
Corollary 2.37
Let P be a positive agent program. For every agent
state O S , the rational status set of P (if one exists)
is unique, i.e., if S, S 0 are rational status sets for P
on O S , then S = S 0 .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 155/361
2. Actions and Agent Programs
5. Status Sets
Example 2.38 (Simple Driving Example revisited)
Clearly, the program P of the driving agent is positive.
Let again O S be such that status : free_lanes
free_lanes(() = {l_lane, r_lane}.
TP ,O
OS (∅) = AppP ,O
O S (∅) ∪ D-Cl(∅) ∪ A-Cl(∅)
go_rightmost
drive
= {Ogo_rightmost
go_rightmost, Odrive
drive(r_lane)} ( =: S1 );
TP ,O
(S
)
∪
D-Cl(S
1
1 ) ∪ A-Cl(S1 )
OS (S1 ) = AppP ,O
OS
go_rightmost
go_rightmost
= {Ogo_rightmost
go_rightmost, Do go_rightmost
go_rightmost, Pgo_rightmost
go_rightmost,
drive
drive
Odrive
drive(r_lane), Do drive
drive(r_lane), Pdrive
drive(r_lane)} ( =: S2 );
TP ,O
OS (S2 ) = AppP ,O
OS (S2 ) ∪ D-Cl(S2 ) ∪ A-Cl(S2 )
= S2
S2 coincides with the feasible status set S above. Thus, by
Theorem 2.36, S is a rational status set on O S . Moreover,
S is the unique rational status set.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 156/361
2. Actions and Agent Programs
5. Status Sets
Note: Corollary 2.37 is no longer true in the
presence of negated action status atoms.
We observe the following property on the
existence of a (not necessarily unique) rational
status set.
Proposition
Let P be an agent program. If IC = ∅, then P has
a rational status set if and only if P has a
feasible status set.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 157/361
2. Actions and Agent Programs
5. Status Sets
Example 2.39 (Simple Driving Example revisited)
Since IC = ∅ and S is a feasible status set on the
agent state, we can immediately infer that the
agent program has a rational status set.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 158/361
2. Actions and Agent Programs
5. Status Sets
Reasonable Status Sets
Observation: For agent programs with negation, rational
status sets allow logical contraposition of the program
rules.
Example 2.40
Consider the following program:
α) ← ¬Do (β
β ).
Do (α
α), P(α
α)}, and
It has two rational status sets: S1 = {Do (α
β ), P(β
β )}.
S2 = {Do (β
S2 is obtained by applying the contrapositive of the rule:
β ) ← ¬Do (α
α)
Do (β
However, S2 seems less intuitive than S1 as there is no
β ).
explicit rule in the above program for deriving Do (β
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 159/361
2. Actions and Agent Programs
5. Status Sets
We now introduce the concept of a reasonable
status set.
Note: If contraposition is desired, then the
rational status set approach rather than the
reasonable status set approach should be used.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 160/361
2. Actions and Agent Programs
5. Status Sets
Definition 2.41 (Reasonable Status Set)
Let P be an agent program, O S an agent state, and S a
status set.
1
2
If P is positive, then S is a reasonable status set for P
on O S , iff S is a rational status set for P on O S .
The reduct of P w.r.t. S and O S , denoted by
P , O S ), is the program resulting from the ground
redS (P
instances of the rules in P over O S as follows.
−
1 First, remove every rule r such that Bas (r) ∩ S 6= ∅;
−
2 Remove all atoms in Bas (r) from the remaining
rules.
Then S is a reasonable status set for P w.r.t. O S , if it
P , OS )
is a reasonable status set of the program redS (P
w.r.t. O S .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 161/361
2. Actions and Agent Programs
5. Status Sets
Example 2.42
Consider the program P :
{ Do β ← ¬Do α }.
β } on agent
The reduct of P w.r.t. S = {Do β , Pβ
state O S is the program
P , O S ) = { Do β ← }.
redS (P
Clearly, S is the unique rational status set of
P , OS ), and thus a reasonable status set of
redS (P
P , O S ).
redS (P
Hence, S is a reasonable status set of P .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 162/361
2. Actions and Agent Programs
5. Status Sets
Proposition
Let P be an agent program and O S an agent
state. Then, every reasonable status set of P on
O S is a rational status set of P on O S .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 163/361
2. Actions and Agent Programs
5. Status Sets
Knowledge representation
Reasonable status sets have some benefits with
respect to knowledge representation. For
example, the rule
α
Do α ← ¬Fα
(3)
says that action α is executed by default
(assuming its precondition succeeds), unless it
is explicitly forbidden.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 164/361
2. Actions and Agent Programs
5. Status Sets
Moreover, reasonable (and rational) status sets
are closely related to logic programming
semantics:
Reasonable status sets correspond to answer
sets in LP.
Rational status sets correspond to minimal
models in LP.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 165/361
2. Actions and Agent Programs
6. Summary
2.6 Summary
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 166/361
2. Actions and Agent Programs
6. Summary
This chapter was about the decision making component
of an agent: How to decide what actions to take given
the current state of the world?
1
We introduced actions α .
1
2
3
2
Much like the classical STRIPS-approach: instead of logical atoms,
we consider code call atoms. Actions are implemented by code.
How to concurrently execute actions? We assume given conc.
Actions do have a status: {P, F, O, W, Do }.
The semantics is given by certain status sets of an
agent program:
1
2
3
4
An agent program consists of rules
α ← Opβ
β1 , . . . , Opβ
βn , ccc1 , . . . , cccn .
Opα
A feasible status set is a set of status atoms {Op1 α1 , . . . , Opn αn }
satisfying certain properties.
Rational status sets = Feasible + Groundedness
Reasonable status sets = Rational + Contraposition not allowed
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 167/361
3. Implementing Agents
Chapter 3. Implementing Agents
3.1
3.2
3.3
3.4
3.5
Implementing Agents
Weakly Regular Agents
Regular Agents
IADE
Gofish example
Summary
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 168/361
3. Implementing Agents
1. Weakly Regular Agents
3.1 Weakly Regular Agents
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 169/361
3. Implementing Agents
1. Weakly Regular Agents
Issues:
1
An agent program may have no reasonable
status set (RSS) because of
Deontic conflicts:
Unstable negation:
e.g. Pα ← , Fα ←.
e.g. Do ← ¬Do α.
RSS Semantics is intractable:
We want a class of agent programs with
guaranteed polynomially computable RSS.
⇒ Regular Agents
2
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 170/361
3. Implementing Agents
1. Weakly Regular Agents
First step: Weakly Regular Agent Programs
(WRAPs) Three basic properties:
1. Strong Safety: Rules are safe, and furthermore code
call conditions must some additional
conditions which ensure that they always
return finite answers.
2. Conflict-Freedom: no deontic conflicts
3. Deontic Stratifiability: graceful layering in the spirit of
stratification in logic programs, to prevents
problems with negation.
However, deontic stratification is more
complex than ordinary stratification (due to
deontic modalities).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 171/361
3. Implementing Agents
1. Weakly Regular Agents
Strong Safety
Safety is a syntactic compile-time check.
Safe code call conditions may lead to infinite results at run
time.
Examples:
in(( X, math : geq
geq((25)))
in(( X, math : geq
geq((25))) & in(( Y, math : square
square((X))) & Y ≤ 2000.
Note: Determining whether a function call has finite result
is undecidable
⇒ requires additional input
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 172/361
3. Implementing Agents
1. Weakly Regular Agents
Agent developer must specify a finiteness table
FINTAB of entries
S : f ( a1 , . . . , an) ,<b-pattern>)
(S
where S : f ( a1 , . . . , an) is a code call of the
underlying software code and <b-pattern> is
binding pattern.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 173/361
3. Implementing Agents
1. Weakly Regular Agents
Definition 3.1 (Binding Pattern)
A binding pattern for a code call S : f ( a1 , . . . , an)
is a tuple (bt1 , . . . , btn ) where each bti (called a
binding term) is either:
1
2
A value of type the τi of ai , or
[, denoting that this argument is bound to an
unknown value.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 174/361
3. Implementing Agents
1. Weakly Regular Agents
Example 3.2 (Finiteness Table for AutoPilot Agent)
Code Call
Pattern
autoPilot : readGPSData
readGPSData((SensorId))
autoPilot : calculateLocation
calculateLocation((Location, FlightRoute, Speed))
autoPilot : calculateNFlightRoutes
calculateNFlightRoutes((CurrentLocation, No_go, N))
autoPilot : calculateNFlightRoutes
calculateNFlightRoutes((CurrentLocation, No_go, N))
autoPilot : calculateNFlightRoutes
calculateNFlightRoutes((CurrentLocation, No_go, N))
([)
([, [, [)
([, [, 1)
([, [, 2)
([, [, 3)
readGPSData((·)) and
Note: autoPilot : readGPSData
autoPilot : calculateLocation
calculateLocation((· · ·)) always return a
finite number of answers.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 175/361
3. Implementing Agents
1. Weakly Regular Agents
Subsumption between binding patterns
Definition 3.3 (Ordering on Binding Patterns)
Binding pattern B = (bt1 , . . . , btn ) is equally or
less informative than binding pattern
B 0 = (bt01 , . . . , bt0n ), denoted B B 0 , if, by
definition, for all 1 ≤ i ≤ n, bti ≤ bt0i .
B = (bt1 , . . . , btn ) is more informative than
B 0 = (bt01 , . . . , bt0n ), if B 0 B but not B B.
Trivial:
([, [, . . . , [) is unique least informative binding
Each tuple (v1 , . . . , vn ) of objects is a maximal
informative binding pattern.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 176/361
3. Implementing Agents
1. Weakly Regular Agents
Definition 3.4 (Finiteness)
Let FINTAB be a finite finiteness table and
B = (bt1 , . . . , btn ) a binding pattern associated
with the code call S : f ( · · ·)). Then FINTAB is said
to entail the finiteness of S : f ( bt1 , . . . , btn) if, by
definition, there exists an entry of the form
S : f ( . . .)), (bt01 , . . . , bt0n )i in FINTAB such that
hS
(bt1 , . . . , btn ) is more informative than
(bt01 , . . . , bt0n ).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 177/361
3. Implementing Agents
1. Weakly Regular Agents
Example 3.5 (CFIT Example)
FINTAB entails the finiteness of
autoPilot : readGPSData
readGPSData((5)), but it does not entail the
finiteness of
autoPilot : calculateNFlightRoutes
calculateNFlightRoutes((h221, 379, 433i, ∅, 0))
(since this may have an infinite number of answers),
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 178/361
3. Implementing Agents
1. Weakly Regular Agents
Achieved: finiteness of a code call of the form S : f ( . . .)).
More complex: strong safety of a code call condition.
Infinite answers due to (1) infinity of the complementary
code call or (2) infinitely decreasing value chains in
comparisons.
Assumptions:
1. Function Complement. Every function f has a
complement f (to be considered in the
finiteness table).
2. Downward Finiteness of types. Type τ has the
downward finiteness property, if it has an
associated partial ordering ≤ such that for all
objects x of type τ , the set {o0 | o0 is an object
of type τ and o0 ≤ o} is finite.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 179/361
3. Implementing Agents
1. Weakly Regular Agents
Strongly Safe Actions and Programs
Definition 3.6 (Strongly Safe Action)
~ is strongly safe w.r.t. FINTAB, if
An action α (X)
~ is strongly safe modulo X,
~ and each
α(X)
Preα
~ and Del(α
~ is
α(X)
α(X)
code call from Add(α
strongly safe modulo Y~ , where Y~ includes all
~ and Preα
~
α(X).
root variables in X
Intuition: We should be able to check whether a (ground)
action is safe by evaluating its precondition. If so, we
should be able to evaluate the effects of executing the
action.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 180/361
3. Implementing Agents
1. Weakly Regular Agents
Definition 3.7 (Strongly Safe Agent Program)
A rule r is strongly safe, if it is safe, and Bcc (r) is a
strongly safe code call condition.
An agent program is strongly safe, if all rules in it
are strongly safe.
Important basic notion:
Definition 3.8 (Strong Safety of Code Call Conditions)
A safe code call condition χ = χ1 & . . . & χn is
~ if there is a
strongly safe w.r.t. root variables X,
permutation π witnessing the safety of χ
~ such that χπ(i) is strongly safe modulo
modulo X
~ for each 1 ≤ i ≤ n.
X,
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 181/361
3. Implementing Agents
1. Weakly Regular Agents
~
Strong Safety of χπ(i) modulo X.
χπ(i) is a code call atom.
Here, let the code call of χπ(i) be S : f ( t1 , . . . , tn) and let
the binding pattern
hbt1 , . . . , btn i be defined as follows:
1
2
If ti is a value, then bti =def ti .
Otherwise ti must be a variable whose root occurs
~ or in χπ(j) for some j < i. In this case,
either in X
bti =def [.
Then, χπ(i) is strongly safe if, by definition, FINTAB
entails the finiteness of S : f ( bt1 , . . . , btn) .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 182/361
3. Implementing Agents
1. Weakly Regular Agents
χπ(i) is s 6= t.
In this case, χπ(i) is strongly safe if, by definition, each
of s and t is either a constant or a variable whose root
~ or in χπ(j) for some j < i.
occurs either in X
χπ(i) is s < t or s ≤ t.
In this case, χπ(i) is strongly safe if, by definition, t is
either a constant or a variable whose root occurs either
~ or somewhere in χπ(j) for some j < i.
in X
χπ(i) is s > t or s ≥ t.
In this case, χπ(i) is strongly safe if, by definition, t < s
or t ≤ s, respectively, are strongly safe.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 183/361
3. Implementing Agents
1. Weakly Regular Agents
Conflict-Freedom
Conflict of literals Op(α(~t)) and (¬)Op0 (α(~t0 ))
Examples:
α(a, b, X) and Pα
α(Z, b, c) conflict.
Fα
α(Z, b, c) and Do α (Z, b, c) conflict,
¬Pα
α(a, b, X) and ¬Pα
α(Z, b, c), as
No conflict: Fα
α(Z, b, c) and ¬Do α (Z, b, c).
well as Pα
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 184/361
3. Implementing Agents
1. Weakly Regular Agents
Deontic conflicts might “kill” any feasible status
set.
⇒ Enforce deontic consistency syntactically
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 185/361
3. Implementing Agents
1. Weakly Regular Agents
Two types of deontic conflicts:
1. rule-head conflicts:
Rules r, r0 conflict, if their heads conflict and
their bodies are satisfiable without conflict.
Problem: undecidable over all agent states
⇒ Use sound (but incomplete)
conflict-freedom test cft
(IMPACT supports several cft
cft’s)
2. Intra-rule conflict:
Rule r : Opi (α(~t)) ← . . . , (¬)Opj (α(~t0 )), . . . has
a conflict, if Opi (α(~t)) and (¬)Opj (α(~t0 ))
conflict.
Such conflicts are easily checked.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 186/361
3. Implementing Agents
1. Weakly Regular Agents
Definition 3.9 (Conflicts)
α(~t)) conflicts with
Literal Li = Op (α
α(~t0 )), if
Lj = (¬)Op 0 (α
1 α (~
t) and α (~t0 ) are unifiable,
0
2 the modalities Op and (¬)Op conflict, i.e.,
there is an entry “×” in the following table:
Op \ (¬)Op0
P
F
O
W
Do
Prof. Dr. Jürgen Dix · LIP 6, UPM
P
¬P
×
F
×
×
×
×
¬F
O
×
×
×
×
×
¬O
W
×
×
¬W
Do
¬Do
×
×
×
×
Panam Seminaire, 17. March 2007 187/361
3. Implementing Agents
1. Weakly Regular Agents
Note:
• conflicts-with is symmetric on Op and Op0 .
• conflicts are not preserved under negation.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 188/361
3. Implementing Agents
1. Weakly Regular Agents
Conflicting Rules:
Informally, two rules ri and rj conflict in a given
state, if
they have a unifiable head
conflicting head-modalities,
deontically consistent bodies (under the
unifying substitution), and
their bodies’ code call components must
have a solution.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 189/361
3. Implementing Agents
1. Weakly Regular Agents
Definition 3.10 (Conflicting Rules w.r.t. a State)
Rules
α(~t)) ← B(ri )
ri : Opi (α
β (~t0 )) ← B(rj )
rj : Opj (β
(standardised apart) conflict w.r.t. an agent state O S , if Opi
conflicts with Opj , and there is a substitution θ such that:
α (~tθ) = β (~t0 θ),
(Bcc (ri ) ∧ Bcc (rj ))θγ is true in OS for some substitution
γ that causes (Bcc (ri ) ∧ Bcc(rj ))θ to become ground,
If Opi ∈ {P, Do , O} (resp., Opj ∈ {P, Do , O}) then
α(~tθ) (resp., β (~t0 θ)) is executable in OS , and
(Bas (ri ) ∪ Bas (rj ))θ contains no pair of conflicting
literals.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 190/361
3. Implementing Agents
1. Weakly Regular Agents
Definition 3.11 (Conflict Free Agent Program)
An agent program, P , is conflict free, if
1 There are no conflicting rules ri , rj in P , for
every possible agent state O S (no rule-head
conflicts);
~0
~
2 For any rule Op (α
i α (t)) ← . . . , (¬)Opj (t ), . . . in
α(~t)) and (¬)Opj (α
α(~t0 )) do not
P , Opi (α
conflict (no intra-rule conflicts).
Problem: rule-head conflicts are undecidable.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 191/361
3. Implementing Agents
1. Weakly Regular Agents
Remedy: use incomplete rule-head conflicts
checks.
Definition 3.12 (Conflict-Freedom Test)
A conflict-freedom test is a function
cft : Rules × Rules → {true, false}
such that if cft
cft(r1 , r2 ) = true, then r1 , r2 does not
conflict w.r.t. any agent state O S .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 192/361
3. Implementing Agents
1. Weakly Regular Agents
Definition 3.13 (Conflict-Free Program w.r.t. cft
cft)
An agent program P is conflict free w.r.t. cft
cft, if
cft
cft(ri , rj ) = true, for every distinct ri , rj ∈ P ,
and
P has no intra-rule conflicts.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 193/361
3. Implementing Agents
1. Weakly Regular Agents
Note: Different functions cft possible.
Tradeoff between accuracy and complexity:
The more accurate cft
cft, i.e., less often returns
“false” on arguments (ri , rj ) when in fact ri , rj
do not conflict, the higher is the complexity of
cft
cft.
In IADE , the agent developer can choose one of
several conflict-freedom tests to be used for his
application (and he can add new ones to his
list).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 194/361
3. Implementing Agents
1. Weakly Regular Agents
Some Conflict-Freedomness Tests
Example 3.14 (Head-CFT, cft h )
Let ri ,rj be two rules of the form
α(~t)) ← B(i)
ri : Opi (α
β (~t0 )) ← B(j).
rj : Opj (β
Now let the head conflict-freedom test cft h be as follows,

 true, if either Opi , Opj do not conflict,
cft h (ri , rj ) =
or α (~t) and β (~t0 ) are not unifiable;

false, otherwise.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 195/361
3. Implementing Agents
1. Weakly Regular Agents
Example 3.15 (Body Code Call CFT, cftbcc )
Let the body-code conflict-freedom test cft bcc be as follows:
cft bcc (ri , rj ) =

true,







if either (1) Opi , Opj do not conflict, or
(2) α (~t) and β (t~0 ) are not unifiable, or
(3) Op , Op conflict and (3.1) α (~t), β (t~0 ) are







unifiable via mgu θ and (3.2) Bcc (r1 θ)
Bcc (r2 θ) has a pair of contradictory cc atoms;
otherwise.
false
i
j
Condition (3.2) means that code call atoms in(( X, cc)) and
not_in(( X, cc)) occur in Bcc (r1 θ) ∪Bcc (r2 θ), or comparison
atoms s1 = s2 and s1 6= s2 ; s1 < s2 and s1 ≥ s2 etc.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 196/361
3. Implementing Agents
1. Weakly Regular Agents
Example 3.16 (Body-Modality-CFT, cft bm )
Similar to the previous one, except that action status
atoms are considered instead. cft bm be as follows,
cftbm (ri , rj ) =

true


















Prof. Dr. Jürgen Dix · LIP 6, UPM
false
if Opi , Opj do not conflict or
α (~t), β (t~0 ) are not unifiable or
Opi , Opj conflict, and α (~t), β (t~0 ) are unifiable
via mgu θ and literals (¬)Opiα (t~00 ) in Bas (ri θ)
for i = 1, 2 exist such that (¬)Op1 and (¬)Op2
conflict;
otherwise.
Panam Seminaire, 17. March 2007 197/361
3. Implementing Agents
1. Weakly Regular Agents
Example 3.17 (Precondition-CFT, cft pr )
Often, we might have action status atoms of the
α, Do α , Oα
α in a rule.
form Pα
Simple Driving Scenario:
go_rightmost
go_rightmost) ←
O(go_rightmost
r1 :
drive
go_rightmost
O(drive
drive(r_lane)) ← Do (go_rightmost
go_rightmost)
r2 :
r3 :
r4 :
drive
drive(X )) ← not_in(( X , status : free_lanes
free_lanes(())
F(drive
drive
Do (drive
drive(l_lane)) ← in(( l_lane, status : free_lanes
free_lanes(()) &
drive
drive(r_lane))
F(drive
Note: no intra-rule conflicts.
cft bcc (r3 , r4 ) = cft bm (r3 , r4 ) = true but
cft bm (r2 , r3 ) = false.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 198/361
3. Implementing Agents
1. Weakly Regular Agents
α) of any atom
Let ri? be ri augmented with Pre(α
α, Do α , Oα
α (standardised apart) in ri .
Pα
r1 :
r2 :
r3 :
r4 :
go_rightmost
O(go_rightmost
go_rightmost) ←
drive
go_rightmost
O(drive
drive(r_lane)) ← Do (go_rightmost
go_rightmost) &
in(( r_lane, status : free_lanes
free_lanes(())
drive
F(drive
drive(X )) ← not_in(( X , status : free_lanes
free_lanes(())
drive
Do (drive
drive(l_lane)) ← in(( l_lane, status : free_lanes
free_lanes(()) &
drive
drive(r_lane))
F(drive
Define
true if cft bcc (ri? , rj? ) = true
cft pr (ri , rj ) =
false otherwise.
Then, cft pr (r2 , r3 ) = true, and P is found
head-conflict free.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 199/361
3. Implementing Agents
1. Weakly Regular Agents
Deontic Stratification
Extend the notion of stratified logic program (Apt et al.)
Definition 3.18 (Layering Function)
Let P be an agent program. A layering function ` is a
mapping
` : P → N (= {0, 1, 2, . . .})..
The i-th layer of P w.r.t. ` , denoted P `i , is
P `i = {r ∈ P | ` (r) = i}.
Intuition: Evaluate layer i before layer j, if i < j.
Note: Drop superscript ` if clear from context.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 200/361
3. Implementing Agents
1. Weakly Regular Agents
Example 3.19 (Simple Flight Program)
r1 : Do execute_flight_plan
execute_flight_plan(F_route) ←
in(( automated, autoPilot : pilotStatus
pilotStatus((pilot_message))) ,
Do create_flight_plan
create_flight_plan(No_go,F_route, C_loc)
r2 : O create_flight_plan
create_flight_plan(No_go, F_route, C_loc) ←
adjust_course(No_go, F_route, C_loc)
O adjust_course
r3 : O maintain_course
maintain_course(no_go, flight_route, current_location) ←
in(( automated, autoPilot : pilotStatus
pilotStatus((pilot_message))) ,
¬ O adjust_course
adjust_course(no_go, flight_route, current_location)
r4 : O adjust_course
adjust_course(no_go, flight_route, current_location) ←
adjustAltitude(Altitude)
O adjustAltitude
Simplification: Rules use constant valued
parameters for maintain_course and
adjust_course
adjust_course.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 201/361
3. Implementing Agents
1. Weakly Regular Agents
Layering functions:
` 1 : ` 1 (r4 ) = 0, ` 1 (r2 ) = 1, ` 1 (r3 ) = 1,
` 1 (r1 ) = 2.
Program layers:
P `01 = {r4 }, P `11 = {r2 , r3 }, P `21 = {r1 }.
`2 :
`2 (r4 ) = 0, `2 (ri ) = 1, i ∈ {1, 2, 3}.
`3:
` 3 (ri ) = 0, i ∈ {1, 2, 3, 4}.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 202/361
3. Implementing Agents
1. Weakly Regular Agents
Deontic stratification:
Definition 3.20 (Modality Ordering)
Partial ordering “≤” on M = {P, O, Do , W, F}:
O ≤ Do , O ≤ P, Do ≤ P, and Op ≤ Op , for
each Op ∈ M .
P
W
Do
F
O
Ground action status atoms: Op α ≤ Op 0α if
Op 0 ≤ Op.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 203/361
3. Implementing Agents
1. Weakly Regular Agents
Definition 3.21 (Deontically Stratifiable Program)
An agent program P is deontically stratifiable, if there
exists a layering function ` such that:
α(~t)) ← . . . , Opj (β
β (~t0 )), . . . in P `i
1 For every rule ri : Opi (α
β (t~00 )) ← . . . is a rule in P such that β (~t0 ) and
, if r : Op (β
β (t~00 ) are unifiable and Op ≤ Opj , then ` (r) ≤ ` (ri ).
α(~t)) ← . . . , ¬Opj (β
β (~t0 )), . . . in
2 For every rule ri : Opi (α
β (t~00 )) ← . . . is a rule in P such that β (~t0 )
P `i , if r : Op (β
and β (t~00 ) are unifiable and Op ≤ Opj , then
` (r) < ` (ri ).
Such an ` is called a witness to the stratifiability of P .
P ) . . . The set of all such witnesses.
wtn(P
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 204/361
3. Implementing Agents
1. Weakly Regular Agents
Example 3.22 (Deontic Stratifiability)
Simple Flight Program:
Condition 1) of deontic stratifiability requires
` (r2 ) ≤ ` (r1 )
`(r4 ) ≤ `(r2 ).
Condition 2) requires
` (r4 ) < ` (r3 ).
⇒ ` 1 and ` 2 witness stratifiability of P .
` 3 is not a witness of stratifiability
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 205/361
3. Implementing Agents
1. Weakly Regular Agents
Example 3.23 (Unstratifiable Program)
Let P 0 contain the following rule:
r10 : Do compute_currentLocation
compute_currentLocation(report) ←
¬ Do compute_currentLocation
(report)
Condition 2) requires
` (r10 ) < ` (r10 )
This is impossible P 0 is not deontically
stratifiable.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 206/361
3. Implementing Agents
1. Weakly Regular Agents
Definition of Weak Regularity
Definition 3.24 (Weak Regular Agent Prog. (WRAP ))
Let P be an agent program, FINTAB a finiteness table, and
cft a conflict-freedom test. Then, P is a weak regular
agent program (WRAP ) w.r.t. FINTAB and cft
cft, if the
following holds:
Strong Safety:
All rules in P and actions α in the agent’s
action base are strongly safe w.r.t. FINTAB.
Conflict-Freedom:
P is conflict free under cft
cft.
Deontic Stratifiability:
P is deontically stratifiable.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 207/361
3. Implementing Agents
1. Weakly Regular Agents
Example 3.25 (Sample WRAP )
Simple Flight Program: Suppose that actions are
strongly safe w.r.t. some FINTAB.
P is conflict-free under cft h ;
P is deontically stratified (see above)
⇒ program P is a WRAP .
Add the following rule:
r5 : W create_flight_plan
create_flight_plan(no_go, flight_route, current_location) ←
not_in(( automated, autoPilot : pilotStatus
pilotStatus((pilot_message)))
cft h (r2 , r5 ) = false, and so P is no longer a
WRAP .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 208/361
3. Implementing Agents
1. Weakly Regular Agents
Finally, we arrive at weak regular agents:
Definition 3.26 (Weakly Regular Agent)
An agent a is weakly regular, if
its associated agent program P is weakly
regular
and
the action constraints AC
AC,
the integrity constraints IC
IC, and
the notion of concurrency conc
in the background are all strongly safe.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 209/361
3. Implementing Agents
1. Weakly Regular Agents
Strong safety for constraints and concurrency
notion
Definition 3.27 (Strongly Safe Integrity/Action
Constraints)
An integrity constraint ψ ⇒ χ is strongly safe, if ψ
is strongly safe and χ is strongly safe modulo the
root variables in ψ.
~ 1 ), . . . , α k (X
~ k )} ←- χ is
α1 (X
An action constraint {α
strongly safe if and only if χ is strongly safe.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 210/361
3. Implementing Agents
1. Weakly Regular Agents
Definition 3.28 (Strongly Safe Notion of Concurrency)
A notion of concurrency conc is strongly safe, if
for every set A of actions, if all members of A are
strongly safe, then so is conc(A).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 211/361
3. Implementing Agents
1. Weakly Regular Agents
Properties of Weakly Regular Agents
Every WRAP (in fact, deontically stratifiable
agent program) P has a canonical layering,
given by
P )}.
canP (r) = min{``i (r) | ` i ∈ wtn(P
Every WRAP has either one or no reasonable
status set.
Any WRAP , if integrity and action constraints
are discarded, has a reasonable status set.
Every WRAP has an associated fixpoint
computation method, which computes the
unique reasonable status set:
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 212/361
3. Implementing Agents
2. Regular Agents
3.2 Regular Agents
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 213/361
3. Implementing Agents
2. Regular Agents
Problem:
agent programs (including WRAPs) admit
recursion
Do α ← Do β ,
Do β ← Do γ .
unbounded recursion
send (N1 ))) ←
Do (send
send (N ))) & in(( N1, math : int_Add
Do (send
int_Add((N, 1))) .
Leads to infinite status set!
For agent programs, bounded recursion is
plausible
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 214/361
3. Implementing Agents
2. Regular Agents
Unfolding:
β &Body1
β ←Body2
Do α ←Pβ
Pβ
Do α ←Body1 &Body2
Operator UnfoldP : unfold all positive rules
bodies in P .
Eliminate all positive rule bodies by repeated
unfolding.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 215/361
3. Implementing Agents
2. Regular Agents
Technical realisation
Associate with Opα(X) a prerequisite-free
constraint (PFC) pfc
PFCs: {&, ∨}-closure of code call conditions χ
and negative status literals ¬Opα
Define semantic equivalence of pfc1 , pfc2
over all agent states O S
Note: Equivalence of pfc1 , pfc2 is undecidable
in general
Use a sound (but incomplete) PFC-equivalence
test eqi(pfc1 , pfc2 )
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 216/361
3. Implementing Agents
2. Regular Agents
Definition 3.29 (Regular Agent Program)
A regular agent program (RAP) is a program
which is weakly regular and bounded.
Boundedness means that by repeatedly
unfolding the positive parts of the rules in the
program, we will eventually get rid of all
positive action status atoms, i.e.,
eqi(UnfoldPb , UnfoldPb+1 ) = true
for some b.
b-regular RAP: eqi(UnfoldPb , UnfoldPb+1 ) = true.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 217/361
3. Implementing Agents
2. Regular Agents
Refinement:
Unfolding along levels of P under deontic
stratification `;
Use PFC-equivalence test eqi(i) at layer i.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 218/361
3. Implementing Agents
2. Regular Agents
Definition 3.30 (Regular Agent)
An agent is regular w.r.t. a layering ` and a suite
of PFC equivalence tests eqi(i) , if it is weakly
regular and its associated agent program is
b-regular w.r.t. ` and the eqi(i) , for some b ≥ 0.
Note: Fix eqi(i) , b at compile time: accept/reject
P after ≤ b unfolding steps.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 219/361
3. Implementing Agents
2. Regular Agents
Theorem 3.31 (Regular Agent Algorithm)
There is an algorithm,
P , ` , IC
Reasonable_SS(P
IC, AC
AC, O S ), which given a
P ), strongly safe action
RAP P , a layering ` ∈ wtn(P
constraints AC and integrity constraints IC
IC, and
an agent state O S , computes in finite time the
reasonable status set S of P on O S , if one exists,
and “no” otherwise.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 220/361
3. Implementing Agents
2. Regular Agents
Under further conditions, Reasonable_SS is
polynomial:
Every ground code call S : f ( d1 , . . . , dn) , has a
set of solutions computed in polynomial
time;
no occurrence of a variable in a ’s description
is “loose”.
assembling and executing conc(Do (S), OS )
is possible in polynomial time.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 221/361
3. Implementing Agents
3. IADE
3.3 IADE
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 222/361
3. Implementing Agents
3. IADE
Implementation of the regular agent program
paradigm:
IMPACT Agent Development Environment
(IADE )
Two major parts:
1. Agent Building: Specification part
Easy to use, network accessible GUI for
agent program development:
software code: data types,
functions
actions
rules
...
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 223/361
3. Implementing Agents
3. IADE
2. Agent Testing: Execution Part
Support for compilation and testing of
RAPs
conflict freedom test
finiteness table
program unfolding
status set computation
Allows to view the reasonable status
set of an agent program on the current
agent state.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 224/361
3. Implementing Agents
3. IADE
IADE Main Screen
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 225/361
3. Implementing Agents
3. IADE
IADE Test Dialog Screen (Prior to Program
Testing)
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 226/361
3. Implementing Agents
3. IADE
IADE includes algorithms for checking
safety
strong safety
conflict freedomness
whether an agent program is a WRAP .
IADE implements unfolding of WRAPs (currently,
supported for positive agent programs only).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 227/361
3. Implementing Agents
3. IADE
IADE Test Execution Screen
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 228/361
3. Implementing Agents
3. IADE
After successful test execution phase, the
reasonable status sets is generated.
Options to continue:
“Unfold Info”:
Shows the unfolded program.
“Layer Info”:
Show the layers of the agent program.
“Status Set Info”:
Shows the status set (split in deontic modality
parts).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 229/361
3. Implementing Agents
3. IADE
IADE Unfold Information Screen
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 230/361
3. Implementing Agents
3. IADE
IADE Status Set Screen (P-fragment)
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 231/361
3. Implementing Agents
3. IADE
IADE Infiniteness Table Screen
Specify code calls with infinite results.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 232/361
3. Implementing Agents
3. IADE
IADE Option Selection Screen
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 233/361
3. Implementing Agents
4. Gofish example
3.4 Gofish example
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 234/361
3. Implementing Agents
4. Gofish example
Mythical Gofish country
Task:
Improve Gofish’s Lightning Mail (which
guarantees delivery within 48 hours of
dropoff)
Desideratum:
Flexibility (respect extensions to other
products)
Lightning Mail product allows citizens to send
certain kinds of packages to other citizens in
Gofish.
Packages are dropped, shipped, and delivered.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 235/361
3. Implementing Agents
4. Gofish example
Package Lifecycle Events
DropOff: Describes the package being dropped
off to a Gofish’s Lightning mail
collection point.
DistCenter: Refers to the arrival of the package at
the distribution center closest to the
destination.
Truck: Refers to the loading of the package
into a truck at the destination center.
The truck will deliver the package to
the destination.
Delivery: Refers to the delivery of the package to
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 236/361
3. Implementing Agents
4. Gofish example
Requirements
Multi-stage Notification
Provide a comprehensive information service
about expect mail delivery.
Dropoff: Sender may request to inform recipient about mail drop &
expected delivery.
DistCenter: Email recipient about package arrival at local
distribution center, revise delivery prediction.
Delivery: When loaded into the truck, phone the recipient to tell
when the package will be delivered.
No phone calls between 10pm and 7am !!
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 237/361
3. Implementing Agents
4. Gofish example
Precise Delivery Prediction:
Inform recipients about expected delivery
time as precise as possible.
(Currently, only large unreliable time window
(8am–8pm of a day), but 48h guarantee.)
Predict delivery using a temporal probability
distribution PO,D for delivery from origination
zipcode O to destination zipcode D:
PO,D : [1..48] → [0, 1]
Maintain statistics for determining PO,D (h).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 238/361
3. Implementing Agents
4. Gofish example
Zipcode Monitoring:
Track which zipcodes are not being well
served by the current distribution center
allocated them.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 239/361
3. Implementing Agents
4. Gofish example
Gofish Databases
Lightning Mail has several databases, stored in
relations.
package(Pid,TYpe, Wt,. . . ):
Information about each package.
Pid: package id (string);
PType: this is one of envelope, tube, box (string);
Wt: this is the weight of the package in pounds (real);
Vol: this is the volume of the package in cubic inches (int);
LSender: last name of sender (string);
FSender: first name of sender (string);
LRecip: last name of recipient (string);
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 240/361
3. Implementing Agents
4. Gofish example
FRecip: first name of recipient (string);
RecipTel: Recipient’s phone number (string);
RecipEMail: Recipient’s email address (string);
OrigZip: Zip code of the origin (int);
DestZip: Zip code of the destination (int);
DestStreet: destination street name (string);
DestNum: destination street number (int);
Priority: 1..5 (higher number is higher priority)
Cost: the mailing cost (real).
DropTime: time of package dropoff by the sender (0, 1, 2, . . .)
DelivTime: time of package delivery (-1, if unknown)
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 241/361
3. Implementing Agents
4. Gofish example
events(Package,Event,Time):
Events occurring for each package.
Package: Package ID
Event: Type of event (DropOff,DistCenter,Truck,Delivery)
Time: Time (integer)
Example: (123,Dropoff,2) means that package ’123’ was dropped at time 2.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 242/361
3. Implementing Agents
4. Gofish example
ziptozip(Zip1,Zip2,Time,Number,Tot):
Statistics on past delivery, capturing PO,D .
Zip1: origination zipcode
Zip2: destination zipcode
Time: hour of delivery (1..48)
Number: number of packages delivered within given hours
Tot: total number of delivered packages
Example: (20742,20715,23,30,200) means 15% probability (30/200) that a
package mailed from zip code 20742 to 20715 will arrive in 23 hours exactly.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 243/361
3. Implementing Agents
4. Gofish example
centertohouse(Zip,Time,Number,Tot):
Statistics on past delivery from distribution
center.
Zip: destination zipcode
Time: hour of delivery (1..48)
Number: number of packages delivered within given hours
Tot: total number of delivered packages
Example: (20715,8,11,50) means that 22% (11 of 50) packages intended for
zip code 20715 are delivered in exactly 8 hours from their arrival at the
Distribution center.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 244/361
3. Implementing Agents
4. Gofish example
trucktohouse(Street,Time,Number,Tot,Avg):
Statistics on truck delivery.
Street: destination address
Time: hour of delivery (1..48)
Number: number of packages delivered within given hours
Tot: total number of delivered packages
Example: (campus-drive, 2,5,20) means that there is a 25% (5/20)
probability of package delivery in exactly 2 hours.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 245/361
3. Implementing Agents
4. Gofish example
managers(Zip,Manager,Email): manager email
address
Zip: zip code
Manager: manager of zip code area
Email: email address of the manager
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 246/361
3. Implementing Agents
4. Gofish example
Gofish Multi-Agent System
Gofish agents:
PA
Package Agent (PA
PA): Manages the package
database.
NA
Notification Agent (NA
NA): Inform customers
about estimated arrival time on Dropoff
(optional), DistCenter (email), and Truck
events (phone call, simulated).
NA must obtain the phone number by
interaction with PA, and has direct query
access to statistic databases.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 247/361
3. Implementing Agents
4. Gofish example
ZMA
Zip Monitor Agent (ZMA
ZMA): Send email
messages to all managers responsible for a
certain zip code if it is not served well.
ZMA accesses directly centertohouse and
manager databases.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 248/361
3. Implementing Agents
4. Gofish example
EMA
Event Manager Agent (EMA
EMA): An event
management agent maintains, updates, and
uses the events database. It also maintains
the statistics databases.
EMA receives messages with events from the
Dispatcher Agent and sends them to the
other GoFish Agents.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 249/361
3. Implementing Agents
4. Gofish example
Auxiliary agents:
DA
Dispatcher Agent (DA
DA): Processes incoming
package drop off messages. Maintains small
status DB through which it generates update
events for the Event Manager Agent.
PDA
Package Dropper Agent (PDA
PDA): Creates
packages for drop off, using an address table,
and sends “DropOff” message to the
Dispatcher Agent for processing.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 250/361
3. Implementing Agents
4. Gofish example
Interaction and Message Protocol
Asynchronous interaction via message
exchange
Encode service commands in message
content:
command name
Parameters: marshalling using tokenstring (ts) format
Example: command to get recipient
information from Package Agent, after a
DistCenter event.
get_recipient_info
ts(10,‘DistCenter’) = “10,DistCenter”
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 251/361
3. Implementing Agents
4. Gofish example
Gofish Message description:
# Command
From To
Data (Parameter)
1 DropOff
any EM
ts(Pid,Ptype,Wt,Vol,FSender,LSender,OrigZip,FRecip,LRecip,RecipTel,
RecipEMail,DestNum,DestStreet,DestZip,Priority)
2 add_package EM
PA
ts(Pid,PType,Wt,Vol,FSender,LSender,OrigZip,FRecip,LRecip,RecipTel,
RecipEMail,DestNum,DestStreet,DestZip,Priority,DropTime)
3 send_ziptozip PA
NA
ts(RecipEMail,OrigZip,DestZip,DropTime)
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 252/361
3. Implementing Agents
#
4
5
6
7
8
9
10
11
Command
DistCenter
send_centertohouse
get_recipient_info
recipient_info
Truck
send_trucktohouse
get_recipient_info
recipient_info
From
any
EM
NA
PA
any
EN
NA
PA
To
EM
NA
PA
NA
EM
NA
PA
NA
12
13
14
Delivery
set_delivery _time
statistic_info
any
EM
PA
EM
PA
EM
Prof. Dr. Jürgen Dix · LIP 6, UPM
4. Gofish example
Data (Parameter)
string(Pid)
string(Pid)
ts(Pid,‘DistCenter’)
ts(Pid,‘DistCenter’,RecipTel,RecipEMail,DestZip,DestStreet,DropTime)
string (Pid)
string(Pid)
ts(Pid,‘Truck’)
ts(Pid,‘Truck’,RecipTel,RecipEMail,
DestZip,DestStreet,DropTime)
string(Pid)
ts(Pid,DelivTime)
ts(Pid,OrigZip,DestZip,DestStreet)
Panam Seminaire, 17. March 2007 253/361
3. Implementing Agents
4. Gofish example
Gofish message protocol
De
liv
ery
(12
)
8)
k(
Dr
Event Management
Agent
uc
op
O
statistic_info (14)
DistCenter (4)
set_delivery_time (13)
ff (
1)
ipi
ec
se
nd
_
t_r
ge
add_packages (2)
Tr
Package
Agent
(5)
use
(9)
ho
ter
use
cen toho
d_
ck
sen
tru
d_
sen
zip
toz
ip
en
(3
rec
t_i
)
nf
ipi
o(
en
6,1
t_i
nf
0)
o(
7,1
1)
Notification Agent
(Dispatcher Agent)
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 254/361
3. Implementing Agents
4. Gofish example
GoFish Agent Implementation
Software code OS :
MS Access databases, using JDBC, ODBC
internal (library) packages for message box, text, string
manipulation etc
Agent actions:
send messages
read files
send emails
open popup windows
data projections
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 255/361
3. Implementing Agents
4. Gofish example
Example:
#IMPACT Action Def#
sendStatisticInfo
(
TgtAgent / string, Data / string
);;;;
–>executes
{ sendMessage(
TgtAgent,
0,
Data)
};
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 256/361
3. Implementing Agents
4. Gofish example
Agent Programs:
Small agents have few rules, largest has ∼ 30
rules.
Example: Rule from PA program
Do(sendStatisticInfo(”GFEventManager”, Data)) :Do(setDeliveryTime(PId))
in(Query, Local–>
text:concat(”select * from Package where Pid=’”, PId, ”’”)) &
in(Package, GoFishDB–>JDBC:Sql(Query))
=(OrigZip, Package.OrigZip)
=(DestZip, Package.DestZip)
=(DestStreet, Package.DestStreet)
in(Data, Local–>
text:concat(PId, ” ”, OrigZip, ” ”, DestZip, ” ”, DestStreet)).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 257/361
3. Implementing Agents
5. Summary
3.5 Summary
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 258/361
3. Implementing Agents
5. Summary
Regular Agents: An efficiently implementable
class of agents.
What are suitable syntactic conditions on agent
programs, to ensure polynomial
implementability?
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 259/361
3. Implementing Agents
1
Weakly regular agents:
1
2
3
2
5. Summary
Strong Safety: To ensure that code calls return finitely many
answers
( Finiteness Table).
Conflict-Freedom: The program should be conflict-free (
cft
cft-tests).
Deontic Stratifiability: Problems with negation are ruled out.
Regular Agents: weakly regular +
Unfolding.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 260/361
4. Extensions of IMPACT
Chapter 4. Extensions of IMPACT
4.1
4.2
4.3
4.4
Extensions of IMPACT
Adding Beliefs
Adding Time
Adding Uncertainty
TP Agent Programs
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 261/361
4. Extensions of IMPACT
Beliefs: Agents hold beliefs about other agents.
Dix/Subrahmanian/Pick:
Meta Agent Programs,
Journal of Logic Programming, 46(1–2)*1–60, 2000.
Uncertainty: Available information is uncertain.
Dix/Nanni/Subrahmanian:
Probabilistic Agent Reasoning,
ACM Transactions of Computational Logic, 1(2)*201–245, 2000
Time: Agents make commitments to the future.
Dix/Kraus/Subrahmanian:
Temporal Agent Reasoning,
Artificial Intelligence, 127(1)*87–135, 2001
Time + Uncertainty: Agents use both time and uncertainty.
Dix/Kraus/Subrahmanian:
Heterogenous Temporal Probabilistic Agents,
ACM Transactions of Computational Logic, 7(1)*151–198, 2006
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 262/361
4. Extensions of IMPACT
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 263/361
4. Extensions of IMPACT
A set of enemy vehicle agents: These agents (mostly
tanks) move across free terrain, and their
movements are determined by a program that
the other agents listed below do not have
access to (though they may have beliefs about
this program).
A terrain route planning agent terrain
terrain: Here we extend
the terrain agent so that it also provides a
flight path computation service for helicopters,
through which it plans a flight, given an origin,
a destination, and a set of constraints
specifying the height at which the helicopters
wish to fly.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 264/361
4. Extensions of IMPACT
A tracking agent: which takes as input, a DTED
(Digital Terrain Elevation Data) map,
an id assigned to an enemy agent, and
a time point. It produces as output,
the location of the enemy agent at the
given point in time (if known) as well
as its best guess of what kind of enemy
the agent is. All three of beliefs, time
and uncertainty enter here.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 265/361
4. Extensions of IMPACT
A coordination agent: coordination may not
precisely know the type of a given
enemy vehicle, because of inaccurate
and/or uncertain identification made
by the sensing agent. At any point in
time, it holds some beliefs about the
identity of enemy vehicle.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 266/361
4. Extensions of IMPACT
As the enemy
agent continues along its route, the
coordination agent may be forced to revise
its beliefs, as it becomes apparent that the
actual route being taken by the enemy
vehicle is inconsistent with the expected
route. Furthermore, as time proceeds,
sensing data provided by the tracking agent
may cause the coordination agent to revise
its beliefs about the enemy vehicle type.
Changing beliefs with time.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 267/361
4. Extensions of IMPACT
Beliefs about the enemy agent's reasoning.
The coordination agent may also hold some
beliefs about the enemy agents’ reasoning
capabilities (see the Belief-Semantics Table).
For instance, with a relatively unsophisticated
and disorganized enemy whose command
and control facilities have been destroyed, it
may believe that the enemy does not know
what moves friendly forces are making.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 268/361
4. Extensions of IMPACT
1. Adding Beliefs
4.1 Adding Beliefs
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 269/361
4. Extensions of IMPACT
1. Adding Beliefs
When an agent a reasons about another
agent b , it must have some beliefs about b ’s
underlying action base (what actions can b
take?), b ’s action program (how will b
reason?) etc.
Most important are the beliefs about what
holds in another agents state
b , χ)
Ba (b
In that case, agent a must also have
background information: beliefs about
agent b ’s software package S b : the code call
condition χ has to be contained in S b .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 270/361
4. Extensions of IMPACT
1. Adding Beliefs
Example 4.1 (Belief Atoms In CFIT*)
tank1
B heli1 (tank1
tank1, in(( pos1, tank1 : getPos
getPos(()) )
This belief atom says that the agent, heli1 believes that
tank1’s current state indicates that tank1
tank1’s
agent tank1
current position is pos1.
attack (pos1, pos2))
tank1
B heli1 (tank1
tank1, Fattack
This belief atom says that the agent, heli1 believes that
agent tank1
tank1’s current state indicates that it is
forbidden for tank1 to attack from pos1 to pos2.
tank1
drive
B heli3 (tank1
tank1, Odrive
drive(pos1, pos2, 35))
This belief atom says that the agent, heli3 believes that
agent tank1
tank1’s current state makes it obligatory for
tank1 to drive from location pos1 to pos2 at 35 mph.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 271/361
4. Extensions of IMPACT
1. Adding Beliefs
The precise definition is very complicated!
A nested belief atom of the form
b , Bc (d
d , χ))
Ba (b
does not make sense (because b 6= c ).
Thus every agent keeps track of only its own
beliefs, not those of other agents!!
We can use conjunctions with respect to
b, χ) ∧ B a (cc, χ0 ).
different agents B a (b
We also use different nested levels of beliefs,
b, χ) ∧ B a (cc, B c (d
d, χ0 )).
like B a (b
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 272/361
4. Extensions of IMPACT
1. Adding Beliefs
Example 4.2 (Belief Formulae for CFIT*)
Some belief formulae from BLheli1
, BLtank1
and BLcoord
.
1
2
3
tank1
B heli1 (tank1
tank1, in(( pos1, tank1 : getPosition
getPosition(()) ).
.
It
says that agent heli1
This formula is in BLheli1
1
believes that agent tank1
tank1’s current state indicates that
tank1
tank1’s current position is pos1.
heli1
tank1
B tank1 (heli1
heli1, B heli1 (tank1
tank1, in(( pos1, tank1 : getPosition
getPosition(()) )).
tank1
BL
This formula is in
. It says that agent tank1
2
believes that agent heli1 believes that agent tank1
tank1’s
current position is pos1.
tank1
heli1
tank2
B coord (tank1
tank1, B tank1 (heli1
heli1, B heli1 (tank2
tank2, in(( pos2, tank2 : getPosition
getPosition(()) ))).
This formula is in BLcoord
. It says that agent coord
3
believes that agent tank1 believes that heli1 believes
tank2
tank2’s current position is pos2.Panam Seminaire, 17. March 2007 273/361
Prof. Dr. Jürgenthat
Dix · LIP 6,agent
UPM
4. Extensions of IMPACT
1. Adding Beliefs
However, the following formula does not belong to any of
the above belief languages:
heli1
tank1
B tank1 (heli1
heli1, B tank1 (tank1
tank1, in(( pos1, tank : getPosition
getPosition(()) )).
The reason for this is because in heli1
heli1’s state there can be
tank1.
no beliefs belonging to tank1
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 274/361
4. Extensions of IMPACT
1. Adding Beliefs
Example 4.3 (Basic Belief Table for CFIT* Agents)
We define suitable basic belief tables for agent tank1
tank1.
Agent
heli1
heli2
tank2
Formula
in(( pos1, heli1 : getPosition
getPosition(())
tank1
B heli2 (tank1
tank1, in(( pos1, tank1 : getPosition
getPosition(()) )
Btank2 (heli1
heli1
tank1
heli1, Bheli1 (tank1
tank1, in(( pos3, tank1 : getPosition
getPosition(()) ))
Table 2: A Basic Belief Table for agent tank1
tank1.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 275/361
4. Extensions of IMPACT
1. Adding Beliefs
What kind of operations should we support on
belief tables?
We distinguish between two different types:
1 For a given agent h , other than a , we may
want to select all entries in the table having h
as first argument.
2
For a given belief formula φ , we may be
interested in all those entries, whose second
argument “implies” (w.r.t. some underlying
definition of entailment) the given formula φ .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 276/361
4. Extensions of IMPACT
1. Adding Beliefs
Belief Semantics Table
Agent a may associate different background
theories with different agents: it may assume
that agent h reasons according to semantics
BSemah and assumes that agent h0 adopts a
stronger semantics BSemha0 .
We will store the information in a separate
relational data structure:
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 277/361
4. Extensions of IMPACT
1. Adding Beliefs
Example 4.4 (Belief Semantics Tables for CFIT* Agents)
We briefly describe what suitable Belief
Semantics Table for heli1 and tank1 may look
tank1
like. We define entailment relations BSemheli2
,
heli1
and BSemtank1 . For simplicity we restrict these
entailment relations to belief formulae of level at
most 1, i.e., BLh1 .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 278/361
4. Extensions of IMPACT
1. Adding Beliefs
Example 4.4 (continued)
1
2
BSemheli1
tank1 : The smallest entailment relation satisfying
the schema
Btank1 (tank1.1
tank1.1
tank1.1, χ) → χ.
This says that heli1 believes that all beliefs of tank1
about tank1.1 are actually true: tank1 knows all about
tank1.1
tank1.1.
BSemtank1
heli2 : The smallest entailment relation satisfying
the schema
tank2
tank2.1
B heli2 (tank2
tank2, χ) ∧ B heli2 (tank2.1
tank2.1, χ) → χ.
This says that tank1 believes that if heli2 believes that
χ is true both for tank2 and tank2.1 then this is
actually true.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 279/361
4. Extensions of IMPACT
1. Adding Beliefs
The notion of a semantics used in the belief semantics
table is very general: it can be an arbitrary relation on
BLhi × BLhi .
As an example, consider the following two simple axioms
that can be built into a semantics:
h , χ) ⇒ Bh2 (h
h0 , χ)
(1) Bh2 (h
h , χ) ⇒
χ
(2) Bh 2 (h
The first axiom refers to different agents h , h 0 while the
second combines different levels of belief atoms. In many
applications, however, such axioms will not occur: h = h 0
is fixed and the axioms operate on the same level i of belief
formulae.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 280/361
4. Extensions of IMPACT
1. Adding Beliefs
Suppose an agent a believes that another agent
h 1 reasons according to the feasible semantics,
h 2 reasons according to the rational semantics
etc. It would be nice if this could be encoded as
follows in BSemTa
h1 , Sem feas i
hh
h2 , Sem rat i
hh
h3 , Sem reas i
hh
This is indeed possible.
The idea is to use the semantics Sem of the
b) (that a believes b to have)
action program P a (b
for the evaluation of the belief formulae.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 281/361
4. Extensions of IMPACT
1. Adding Beliefs
Definition 4.5 (Meta Agent Program (map) BP)
A meta agent rule, (mar for short), for agent a is
an expression r of the form
Op α(~t) ← L1 , . . . , Ln
(4)
where Op α(~t) is an action status atom, and each
of L1 , . . . , Ln is either a code call literal, an action
a ,A
A ).
literal or a belief literal from BLit∞ (a
A meta agent program, (map for short), for
agent a is a finite set BP of meta agent rules for
a.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 282/361
4. Extensions of IMPACT
1. Adding Beliefs
Example 4.6 (map’s for CFIT*-Agents)
Let heli1
heli1’s meta agent program be as follows:
tank1
Pattack (P1, P2) ← B heli1 (tank1
tank1, in(( P2, tank1 : getPos
getPos(()) ),
Pfly
fly(P1, P3, A, S), Pattack (P3, P2).
where attack (P1, P2) is an action which means attack
position P2 from position P1. heli1
heli1’s program says heli1
can attack position P2 from P1 if heli1 believes tank1 is in
position P2, heli1 can fly from P1 to another position P3 at
altitude A and speed S, and heli1 can attack position P2
from P3.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 283/361
4. Extensions of IMPACT
1. Adding Beliefs
Example 4.6 (continued)
tank1’s meta agent program be as follows:
Let tank1
attack (P1, P2) ← OdriveRoute
driveRoute
Oattack
driveRoute([P0, P1, P2, P3], S)
tank2
B tank1 (tank2
tank2, in(( P2, tank2 : getPos
getPos(()) ).
If tank1 must drive through a point where it believes
tank2 is, it must attack tank2
tank2.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 284/361
4. Extensions of IMPACT
1. Adding Beliefs
From now on we assume that the software
T S a ,F
F S a ) of each agent a
package S a = (T
contains as distinguished data types
a
1 the belief table BT , and
a
2 the belief semantics table BSemT ,
as well as the corresponding functions
BTaa : B-proj-select(r, h , φ)
BSemTaa : select(agent, =, h ).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 285/361
4. Extensions of IMPACT
1. Adding Beliefs
What is a status set?
Definition 4.7 (Belief Status Set BS)
A belief status set BS of agent a, also written
a), is a set consisting of two kinds of
BS(a
elements:
ground action status atoms over S a and
a ,A
A ) of level greater
belief atoms from BAt∞ (a
or equal to 1.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 286/361
4. Extensions of IMPACT
1. Adding Beliefs
The reason that we do not allow belief atoms of
level 0 is to avoid having code call conditions in
our set. In agent programs without beliefs
(which we want to extend) they are not allowed
(see Definition 2.23 on page 137).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 287/361
4. Extensions of IMPACT
1. Adding Beliefs
A status set must be determined in accordance with
1
2
3
the map BP of agent a ,
the current state O of a ,
AC
the underlying set of action (AC
AC) and integrity
IC
IC) of a .
constraints (IC
In contrast to agent programs without beliefs we now
have to cope with all agents about which a holds
certain beliefs.
Even if the map BP does not contain nested beliefs
(which are allowed), we cannot restrict to belief atoms
of level 1 ( BTa may contain nested beliefs and, by
BSemTa , such nested beliefs may trigger other
beliefs).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 288/361
4. Extensions of IMPACT
1. Adding Beliefs
Definition 4.8 (Extended Code Calls, S ext )
We distinguish between basic and extended code calls.
Basic cc’s refer to S . Extended cc’s refer to a software
package containing
1 the following functions of the belief (semantics) tables:
(a) a : belief _table
_table(() , which returns the full belief table of agent a , as a
h, φ, χB i,
set of triples hh
(b) a : belief _sem_table
_sem_table(() , which returns the full belief semantics table,
a
h, BSemh
as a set of pairs hh
h i,
(c) a : bel _semantics
_semantics((h , φ, ψ)), which returns true when φ |=BSemaa ψ
h
h
and false otherwise.
2
functions, implementing for every sequence σ the
σ ):
beliefs of agent a about σ as described in Γ a (σ
(d)
(e)
(f)
(g)
(h)
a : software_package
σ ),
software_package((σ ), which returns the set S a (σ
σ ),
a : action_base
action_base((σ ) , which returns the set AB a (σ
σ ),
a : action_program
action_program((σ ) , which returns the set P a (σ
σ)
a : integrity_constraints
integrity_constraints((σ ) , which returns the set IC a (σ
σ ),
a : action_constraints
action_constraints((σ ) , which returns the set AC a (σ
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 289/361
4. Extensions of IMPACT
1. Adding Beliefs
Definition 4.8 (continued)
1
the following functions which simulate the
state of another agent b or a sequence σ ,
(i) a : bel _ccc_act
_ccc_act((σ ) , which returns all the code call conditions and
action status atoms that a believes are true in σ ’s state. We write
these objects in the form ”in(( , ) ” (resp. ”Op α” for action status
atoms) in order to distinguish them from those that have to be
checked in a’s state.
(j) a : not_bel _ccc_act
_ccc_act((σ ) , which returns all the code call conditions
and action status atoms that a does not believe to be true in σ ’s
state.
We also write S ext for this extended software
package and distinguish it from the original S
from which we started.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 290/361
4. Extensions of IMPACT
1. Adding Beliefs
We now
1 transform meta agent programs into agent
, (this is a source-to-source
transformation: the belief atoms in a meta
agent program are replaced by suitable code
calls to the new data structures),
take advantage of extended code calls S
.
programs
2
Prof. Dr. Jürgen Dix · LIP 6, UPM
ext
ext
Panam Seminaire, 17. March 2007 291/361
4. Extensions of IMPACT
1. Adding Beliefs
Suppose the belief table does not contain any
belief conditions (i.e., it coincides with its
basic belief table).
Then if χ is any code call condition of agent c ,
the extended code call atom
in(( hcc, χ, truei, a : belief _table
_table(())
corresponds to the belief atom
Ba (cc , χ).
But beliefs can also be triggered by entries in
the belief table and/or in the belief semantics
table!
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 292/361
4. Extensions of IMPACT
1. Adding Beliefs
What happens if the formula χ is not a
code call, but again a belief formula, say
d , χ0 )?
Bc (d
Here is where the inductive definition of
Trans comes in. We map
d , χ0 ))
Ba (cc , Bc (d
to
in(( ”χ0 ”, a : bel _ccc_act
_ccc_act(([cc, d ]))) .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 293/361
4. Extensions of IMPACT
1. Adding Beliefs
Our main theorem states that there is indeed a uniform
Trans from arbitrary meta agent
programs (which can also contain nested beliefs) to agent
programs such that the semantics are preserved:
transformation
Trans
Sem
Sem(BP) = Sem
Sem(Trans
Trans(BP))
(5)
where Sem is either the feasible, rational or reasonable
belief status set semantics.
Trans
BP
−−−−−−−−→
P
x
x
Compatible with 
 old
IC ext
Belief Semantics Sem new
Sem
Closure
Belief Table
BS
Prof. Dr. Jürgen Dix · LIP 6, UPM
Trans
−−−−−−−−→
(6)
S
Panam Seminaire, 17. March 2007 294/361
4. Extensions of IMPACT
2. Adding Time
4.2 Adding Time
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 295/361
4. Extensions of IMPACT
2. Adding Time
Most real-world actions have a duration:
heli
heli: fly(”BA”, ”US”).
It might be important to specify intermediate
timepoints, checkpoints (Definition 4.9), and
to update the current state incrementally at
these prespecified points.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 296/361
4. Extensions of IMPACT
2. Adding Time
Thus, in order to specify a timed action, we
must:
1 Specify the total amount of time it takes
for the action to be “completed”.
2 Specify exactly how the state of the agent
changes while the action is being executed.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 297/361
4. Extensions of IMPACT
2. Adding Time
Definition 4.9 (Checkp. Expr. rel : {X | χ}, abs : {X | χ})
If i ∈ N is a positive integer, then rel : {i} and abs : {i}
are checkpoint expressions.
If χ is a code call condition involving a non-negative,
integer-valued variable X, then rel : {X | χ} and
abs : {X | χ} are checkpoint expressions.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 298/361
4. Extensions of IMPACT
2. Adding Time
Example 4.10 (Rescue: Checkpoints)
This says that a checkpoint occurs at the time
of the start of the action, 100 units later, 200 units
later, and so on.
rel : {100}.
abs : {T | in(( T, clock : time
time(()) & in(( 0, math : remainder
remainder((T, 100))) & T >
This says that a checkpoint occurs at absolute
times 5000, 5100, 5200, and so on.
5000}.
abs : {T |
in(( T, clock : time
time(()) & in(( X, a : getMessage
getMessage((comc))) & X.Time − T = 5}.
This says that a checkpoint occurs at 5 time units after
a message is received from the comc agent.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 299/361
4. Extensions of IMPACT
2. Adding Time
Definition 4.11 (Timed Effect Triple h{chk }, Add , Del i)
A timed effect triple is a triple of the form
h{chk }, Add , Del i where {chk } is a checkpoint
expression, and Add and Del are add lists and
delete lists.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 300/361
4. Extensions of IMPACT
2. Adding Time
Example 4.12 (Rescue: Timed Effect Triples)
The truck agent may use the following timed effect
triple to update its fuel at absolute times 5000, 5100,
5200, and so on.
1st arg :
time(()) & }
abs : {T | in(( T, clock : time
in(( 0, math : remainder
remainder((T, 100))) & T > 5000
2nd arg:{in(( NewFuelLevel, truck : fuelLevel
fuelLevel((Xnow)) }
3rd arg :{in(( OldFuelLevel, truck : fuelLevel
fuelLevel((Xnow − 20))) }
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 301/361
4. Extensions of IMPACT
2. Adding Time
Definition 4.13 (Timed Action)
A timed action α consists of:
Name: A name, usually written α (X1 , . . . , Xn ), where
the Xi ’s are root variables.
Schema: A schema, usually written as (τ1 , . . . , τn ), of
types. Intuitively, this says that the variable Xi
must be of type τi , for all 1 ≤ i ≤ n.
Pre: A code-call condition χ, the precondition of
α)
the action, denoted by Pre(α
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 302/361
4. Extensions of IMPACT
2. Adding Time
Definition 4.13 (continued)
Dur: An expression {i} or {X | χ}. Depending on
the current object state, this expression
α) ∈ N of α .
determines a duration duration(α
α) of timed effect triples such that if
Tet: A set Tet(α
both h{chk }, Add, Deli and h{chk }0 , Add0 , Del0 i
α), then {chk } and {chk }0 have no
are in Tet(α
common solution w.r.t. any object state. The
α) together with Dur(α
α) determines
set Tet(α
α) for action
the set of checkpoints checkpoints(α
α (as defined below).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 303/361
4. Extensions of IMPACT
2. Adding Time
Intuitively, if α is an action that we start
executing at tαstart , then
α) specifies how to compute the
Dur(α
α) of α , and
duration duration(α
α) specifies the checkpoints associated
Tet(α
with action α .
α) and Tet(α
α)
It is important to note that Dur(α
may not specify the duration and checkpoint
times explicitly (even if the associated
checkpoints are of the form abs : {X | χ},
i.e. absolute times). There is a method to
α).
compute duration(α
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 304/361
4. Extensions of IMPACT
2. Adding Time
Definition 4.14 (Temporal Annotation Item tai)
1
2
3
4
Every integer is a temporal annotation item.
The distinguished integer valued variable
Xnow is a temporal annotation item.
Every integer valued variable is a temporal
annotation item.
If tai1 , . . . , tain are temporal annotation items,
and b1 , . . . , bn are integers (positive or
negative), then (b1 tai1 + . . . + bn tain ) is a
temporal annotation item.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 305/361
4. Extensions of IMPACT
2. Adding Time
1, Xnow , Xnow + 3, Xnow + 2v + 4 are all
temporal annotation items if v is an integer
valued variable.
Temporal annotation items, when ground,
evaluate to time points. They are used to
specify a time interval.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 306/361
4. Extensions of IMPACT
2. Adding Time
Definition 4.15 (Temporal Annotation [tai1 , tai2 ])
If tai1 , tai2 are annotation items, then [tai1 , tai2 ] is
a temporal annotation.
[2, 5] is a temporal annotation item
describing the set of time points between 2
and 5 (inclusive).
[2, 3X + 4Y] is a temporal annotation.
When X := 2, Y := 3, this defines the set of
time points between 2 and 18. [Xnow , Xnow + 5]
is a temporal annotation.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 307/361
4. Extensions of IMPACT
2. Adding Time
Definition 4.16 ((Temporal) Action State Condition)
Suppose χ is a (possibly empty) code call
condition, L1 , . . . , Ln are action status literals,
and ta is a temporal annotation. Then:
1 (χ & L1 & . . . & Ln ) is called an action state
condition.
2 (χ & L1 & . . . & Ln ) : ta is called a temporal
action state conjunct (tasc).
3 If χ is empty, then (L1 & . . . & Ln ) : ta is called
a state-independent tasc .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 308/361
4. Extensions of IMPACT
2. Adding Time
Intuitively, when % : ta is ground for some action
state condition %, we may read this as “% is true
at some point in ta”. The following is a simple
tasc.
(in(( X, heli : inventory
inventory((fuel))) & X.Qty < 50) :
[Xnow − 10, Xnow ].
Intuitively, this tasc is true if at some point in
time ti in the last 10 time units, the helicopter
had less than 50 gallons of fuel left.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 309/361
4. Extensions of IMPACT
2. Adding Time
We are now ready to define the most important
syntactic construct of this chapter, a temporal
agent rule.
Definition 4.17 (Temporal Agent Rule/Program T P)
A temporal agent rule is an expression
Op α : [tai1 , tai2 ] ← %1 : ta1 & · · · & %n : tan ,
where Op ∈ {P, Do , F, O, W}, and
%1 : ta1 , . . . , %n : tan are tascs.
A temporal agent program is a finite set of
temporal agent rules.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 310/361
4. Extensions of IMPACT
2. Adding Time
Intuitive Reading of Temporal Agent Rule
“If for all 1 ≤ i ≤ n, there exists a time point ti
such that %i is true at time ti such that either
1
2
%i
is state independent and ti
∈ tai , or
%i is not state independent and ti ≤ tnow
ti is now or is in the past) and ti ∈ tai ,
(i.e.
t ≥ tnow (i.e. now
or in the future) such that tai1 ≤ t ≤ tai2 ”.
then
Op α
is true at some point
Op α : [tai1 , tai2 ] ← %1 : ta1 & · · · & %n : tan ,
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 311/361
4. Extensions of IMPACT
2. Adding Time
“If a prediction package expects a stock to rise K%
after TK units of time and K ≥ 25 then buy the stock at
time (Xnow + TK − 2).”
We assume a prediction package that uses some stock
expertise to predict the change in the value of the
stock in the future.
This function returns a set of pairs of (T, C).
Intuitively, this says that T units from now, the stock
price will change by C percent.
Do buy
buyS : [Xnow + X.T − 2, Xnow + X.T − 2] ←
(in(( X, pred : dest
dest((S))) & X.C ≥ 25) : [Xnow , Xnow ].
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 312/361
4. Extensions of IMPACT
2. Adding Time
Definition 4.18 (Temporal Status Set T Stnow )
A temporal status set T Stnow at time tnow is a
mapping from natural numbers to ordinary
status sets satisfying T Stnow (i) = ∅ for all i > i0
for some i0 ∈ N.
As usual a feasible status set must satisfy
Closure under rules.
Deontic consistency wrt. State History
( Definition 4.19).
Deontic closure.
Checkpoint consistency (
Definition 4.20).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 313/361
4. Extensions of IMPACT
2. Adding Time
As an agent that reasons about time may need to
reason about the current, as well as past states it
was/is in, a notion of state history is needed.
Definition 4.19 (State History Function histtnow )
A state history function histtnow at time tnow is a
partial function from N to agent states such that
histtnow (tnow ) is always defined and for all
i > tnow , histtnow (i) is undefined.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 314/361
4. Extensions of IMPACT
2. Adding Time
The definition of state history does not require that an
agent store the entire past.
1 He may decide to store no past information at all. In
this case, histtnow (i) is defined if and only if i = tnow .
2 He may decide to store information only about the
past i units of time. He stores the agent’s state at
times tnow , (tnow − 1), . . ., (tnow − i), i. e. histtnow is
defined for the following arguments: histtnow (tnow ),
histtnow (tnow − 1), . . ., histtnow (tnow − i).
3 He may decide to store, in addition to the current
state, the history every five time units. That is,
histtnow (tnow ) is defined and for each 0 ≤ i ≤ tnow , if i
mod 5 = 0, then histtnow (i) is defined. Such an agent
may be specified by an agent designer when he
believes that maintaining some (but not all) past
snapshots is adequate for his application’s needs.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 315/361
4. Extensions of IMPACT
2. Adding Time
For a temporal status set to be feasible, at each
checkpoint the state needs to be updated.
The expected future states of the agent need to
satisfy the integrity constraints.
Definition 4.20 (Checkpoint Consistency)
T Stnow is said to be checkpoint consistent at
time tnow if, by definition, for all i > tnow , EO(i)
(see Definition 4.21) satisfies the integrity
constraints IC
IC.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 316/361
4. Extensions of IMPACT
2. Adding Time
Definition 4.21 (Expected States at time t: EO(t))
Suppose the current time is tnow , histtnow is the agent’s state history
function and T Stnow is a temporal status set. The agent’s
are defined as follows:
EO(tnow ) = histtnow (tnow ).
For all time points i > tnow , EO(i) is the result of concurrently
executing
α | Do α ∈ T Snow (i − 1)} ∪
{α
β 0 | Do β ∈ T Snow (j) f or j ≤ i − 1 and i − 1 is a checkpoint
{β
for β and β 0 denotes the action (non-timed) which has
an empty precondition, and whose add and del lists
β ) in state EO(i − 1).}
are as specified by Tet(β
expected
states
We note that that from a certain i0 ∈ N onwards, we have EO(i) = ∅
for all i > i0 (due to the same property for action history/temporal
status set).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 317/361
4. Extensions of IMPACT
3. Adding Uncertainty
4.3 Adding Uncertainty
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 318/361
4. Extensions of IMPACT
3. Adding Uncertainty
In this chapter we extend our framework to deal
with uncertain information. The main
ingredients are
to extend code calls to probabilistic code
calls,
to extend programs to probabilistic agent
programs,
to develop a Kripke style semantics.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 319/361
4. Extensions of IMPACT
3. Adding Uncertainty
Imagine a surveillance example, where
surv : identify
identify((image1)) tries to identify all objects
in a given image: it is well known that this is
an uncertain task.
Some objects may be identified with 100%
certainty, while in other cases, it may only be
possible to say it is either a T-72 tank with
40–50% probability.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 320/361
4. Extensions of IMPACT
3. Adding Uncertainty
Definition 4.22 (Random Variable of Type τ )
A random variable of type τ is a finite set RV of
objects of type τ , together with a probability
distribution ℘ that assigns real numbers in the
unit interval [0, 1] to members of RV such that
Σo∈RV ℘(o) ≤ 1.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 321/361
4. Extensions of IMPACT
3. Adding Uncertainty
Uncertainty can be captured as follows.
Definition 4.23 (Probabilistic CC a :RV f ( d1 , . . . , dn) )
Suppose a : f ( d1 , . . . , dn) is a code call whose
output type is τ . The probabilistic code call
associated with a : f ( d1 , . . . , dn) , denoted
a :RV f ( d1 , . . . , dn) , returns a set of random
variables of type τ when executed.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 322/361
4. Extensions of IMPACT
3. Adding Uncertainty
Example 4.24
Consider the code call surv :RV identify
identify((image1)). This code
call may return the following two random variables.
h{t72, t80}, {ht72, 0.5i, ht80, 0.4i}i
h{t60, t84}, {ht60, 0.3i, ht84, 0.7i}i
This says that the image processing algorithm has
identified two objects in image1:
The first object is either a T-72 or a T-80 tank with
50% and 40% probability, respectively, while
the second object is either a T-60 or a T-84 tank
with 30% and 70% probability respectively.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 323/361
4. Extensions of IMPACT
3. Adding Uncertainty
Probabilistic cc’s and ccc’s look exactly like
ordinary cc’s and ccc’s—however, as a
probabilistic code call returns a set of random
variables, probabilistic code call atoms are
true or false with some probability.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 324/361
4. Extensions of IMPACT
3. Adding Uncertainty
Example 4.25
Consider the probabilistic code call condition
identify((image1))) & in(( a1 , surv :RV turret
turret((X))) .
in(( X, surv :RV identify
This ccc attempts to find all vehicles in “image1” with a
gun turret of type a1. Let us suppose that the first cc is as
on the previous page, but gives back only the first random
variable.
When this result (X) is passed to the second code call, it
returns one random variable with two values—a1 with
probability 30% and a2 with probability 65%.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 325/361
4. Extensions of IMPACT
3. Adding Uncertainty
What is the probability that the code call
condition above is satisfied by a particular
assignment to X?
Let’s suppose X is assigned T72. If all T72’s have
a2-type turrets, then the answer is “0”.
Let’s suppose X is assigned T80.
If the vehicle and turret identification is
independent, then the answer is
“0.4 × 0.3 = 0.12”.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 326/361
4. Extensions of IMPACT
3. Adding Uncertainty
Example 4.26
Suppose we consider a code call cc returning the
following two random variables.
RV1 = h{a, b}, ℘1 i
RV2 = h{b, c}, ℘2 i
Suppose
℘1 (a) = 0.9, ℘1 (b) = 0.1, ℘2 (b) = 0.8, ℘2 (c) = 0.1.
What is the probability that b is in the result
of the code call cc?
Answering this question is problematic.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 327/361
4. Extensions of IMPACT
3. Adding Uncertainty
Definition 4.27 (Probabilistic State of an Agent)
The probabilistic state of an agent a at any
given point t in time, denoted Op (t), consists of
the set of all instantiated data objects and
random variables of types contained in T a .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 328/361
4. Extensions of IMPACT
3. Adding Uncertainty
Definition 4.28 (Satisfying a Code Call Atom)
Suppose a :RV f ( d1 , . . . , dn) is a ground probabilistic code
call and o is an object of the output type of this code call
w.r.t. probabilistic agent state Op . Suppose [`, u] is a
closed, nonempty subinterval of the unit interval [0, 1].
[`,u]
o |=Op in(( X, a :RV f ( d1 , . . . , dn))
if there is a (Y, ℘) in the answer returned by evaluating
a :RV f ( d1 , . . . , dn) w.r.t. Op such that o ∈ Y and
` ≤ ℘(o) ≤ u.
[`,u]
o |=Op not_in(( X, a :RV f (d1 , . . . , dn))
if for all random variables (Y, ℘) returned by evaluating
a :RV f (d1 , . . . , dn) w.r.t. Op , either o ∈
/ Y or ℘(o) ∈
/ [`, u].
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 329/361
4. Extensions of IMPACT
3. Adding Uncertainty
Probabilistic code call conditions are defined in exactly the
same way as code call conditions. However, extending the
above definition of “satisfaction” to probabilistic code call
conditions is highly problematic because (as shown in
Examples 4.25, 4.45)
the probability that a conjunction is true depends not
only on the probabilities of the individual conjuncts,
but also on the dependencies between the events
denoted by these conjuncts.
We allow the user to specify certain strategies.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 330/361
4. Extensions of IMPACT
3. Adding Uncertainty
Definition 4.29 (Probabilistic Conjunction Strategy ⊗)
A probabilistic conjunction strategy is a mapping ⊗
which maps a pair of probability intervals to a single
probability interval satisfying the following axioms:
Bottomline:
[L1 , U1 ] ⊗ [L2 , U2 ] ≤ [min(L1 , L2 ), min(U1 , U2 )] where
[x, y] ≤ [x0 , y 0 ] if x ≤ x0 and y ≤ y 0 .
2 Ignorance:
[L1 , U1 ] ⊗ [L2 , U2 ] ⊆ [max(0, L1 + L2 − 1), min(U1 , U2 )].
3 Identity: When (e1 ∧ e2 ) is consistent and
[L2 , U2 ] = [1, 1], [L1 , U1 ] ⊗ [L2 , U2 ] = [L1 , U1 ].
4 Annihilator: [L1 , U1 ] ⊗ [0, 0] = [0, 0].
5 Commutativity: [L1 , U1 ] ⊗ [L2 , U2 ] = [L2 , U2 ] ⊗ [L1 , U1 ].
6 Associativity: ([L1 , U1 ] ⊗ [L2 , U2 ]) ⊗ [L3 , U3 ] =
[L1 , U1 ] ⊗ ([L2 , U2 ] ⊗ [L3 , U3 ]).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 331/361
1
4. Extensions of IMPACT
3. Adding Uncertainty
The concept of a conjunction strategy is very
general, and has as special cases, the
following well known ways of combining
probabilities.
1 When we do not know the dependencies
between e1 , e2 , we may use the conjunction
strategy ⊗ig defined as ([L1 , U1 ]⊗ig [L2 , U2 ]) ≡
[max(0, L1 + L2 − 1), min(U1 , U2 )].
2 When e1 , e2 have maximal overlap, use the
positive correlation conjunctive strategy ⊗pc
defined as ([L1 , U1 ]⊗pc [L2 , U2 ]) ≡
[min(L1 , L2 ), min(U1 , U2 )].
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 332/361
4. Extensions of IMPACT
3. Adding Uncertainty
3 When e1 , e2 have minimal overlap, use the
negative correlation conjunctive strategy ⊗nc
defined as ([L1 , U1 ]⊗nc [L2 , U2 ]) ≡
[max(0, L1 + L2 − 1), max(0, U1 + U2 − 1)].
4 When the two events occur independently,
use the independence conjunction strategy
([L1 , U1 ]⊗in [L2 , U2 ]) = [L1 · L2 , U1 · U2 ].
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 333/361
4. Extensions of IMPACT
3. Adding Uncertainty
We assume the existence of an annotation
ann
language L
—the constant symbols of Lann are
the reals in the interval [0, 1].
Definition 4.30 (Annotation Item)
We define annotation items inductively:
Every constant and every variable of Lann is
an annotation item.
If f is an annotation function of arity n and
ai1 , . . . , ain are annotation items, then the
term f (ai1 , . . . , ain ) is an annotation item.
An annotation item is ground if no variables
occur in it.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 334/361
4. Extensions of IMPACT
3. Adding Uncertainty
Definition 4.31 (Annotation [ai1 , ai2 ])
If ai1 , ai2 are annotation items, then the term
[ai1 , ai2 ] is an annotation. If ai1 , ai2 are both
ground, then [ai1 , ai2 ] is a ground annotation.
For instance, [0, 0.4], [0.7, 0.9], [0.1, V2 ], [ V4 , V2 ] are all
annotations. The annotation [0.1, V2 ] denotes an
interval only when a value in [0, 1] is assigned to
the variable V.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 335/361
4. Extensions of IMPACT
3. Adding Uncertainty
Definition 4.32 (Annotated CCC χ : h[ai1 , ai2 ], ⊗i)
If χ is a probabilistic code call condition, ⊗ is a
conjunction strategy, and [ai1 , ai2 ] is an
annotation, then χ : h[ai1 , ai2 ], ⊗i is an annotated
code call condition. χ : h[ai1 , ai2 ], ⊗i is ground if
there are no variables in either χ or in [ai1 , ai2 ].
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 336/361
4. Extensions of IMPACT
3. Adding Uncertainty
For example, when X is ground,
in(( X, surv :RV identify
identify((image1))) & in(( a1, surv :RV turret
turret((X))) : h[0.3, 0.
is true if and only if
the probability that X is identified by the surv agent,
and that the turret is identified as being of type a1 lies
between 30 and 50%,
assuming that nothing is known about the
dependencies between turret identifications and
identifications of objects by surv
surv.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 337/361
4. Extensions of IMPACT
3. Adding Uncertainty
Definition 4.33 (Probabilistic Agent Programs PP)
Suppose Γ is an annotated code call condition, and
A, L1 , . . . , Ln are status atoms. Then
A ← Γ & L1 & . . . & Ln
(7)
is a probabilistic action rule.
A probabilistic agent program (pap for short) is a finite set
of probabilistic action rules.
It is important to note in the above definition that in a
probabilistic action rule, status atoms are not
annotated—uncertainty is present only in the state, and
on the basis of this uncertainty, the agent must determine
what it is obliged to do, forbidden from doing, etc.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 338/361
4. Extensions of IMPACT
3. Adding Uncertainty
file((imagedb))) &
Do send_warn(X) ← in(( F, surv : file
in(( X, surv :RV identify
identify((F))) &
in(( a1, surv :RV turret
turret((X))) ) : h[0.7, 1.0], ⊗ig i
¬Fsend_warn(X).
file((imagedb))) &
Fsend_warn(X) ← in(( F, surv : file
in(( X, surv :RV identify
identify((F))) &
in(( L, geo :RV getplnode
getplnode((X.location))) &
in(( L, geo :RV range
range((100, 100, 20))) .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 339/361
4. Extensions of IMPACT
3. Adding Uncertainty
Definition 4.34 (Feasible Probabilistic Status Set)
Suppose PP is an agent program and Op is a probabilistic
agent state. A probabilistic status set PS is feasible for
PP on Op if the following conditions hold:
(PS1): AppPP,O
OS (PS) ⊆ PS (closure under the
program rules);
(PS2): PS is deontically and action consistent
(deontic/action consistency);
(PS3): PS is action closed and deontically closed
(deontic/action closure);
(PS4): PS is state consistent (state consistency).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 340/361
4. Extensions of IMPACT
3. Adding Uncertainty
Definition 4.35 (Deontic and Action Consistency)
A probabilistic status set PS is deontically consistent with
respect to a probabilistic agent state Op if, by definition, it
satisfies the following rules for any ground action α:
If Oα ∈ PS, then Wα ∈
/ PS.
If Pα ∈ PS, then Fα ∈
/ PS.
If Pα ∈ PS, then Op |=[1,1] Pre(α).
A probabilistic status set PS is action consistent w.r.t. Op
if, by definition, for every action constraint of the form
~ 1 ), . . . , αk (X
~ k )} ←- χ
{α1 (X
(8)
~ 1 ), . . . , αk (X
~ k )} 6⊆ Do (PS).
either O p 6|=[1,1] χ or {α1 (X
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 341/361
4. Extensions of IMPACT
3. Adding Uncertainty
Definition 4.36
Let PP be a probabilistic agent program, PS a
probabilistic status set and Op a probabilistic agent state.
Assume further that each random variable contains exactly
one object with probability 1. Then we can define the
following mappings:
Red1 (·), which maps every random variable of the form
h{oRV }, 1i to o: Red1 (h{oRV }, 1i) = o.
Red2 (·), which maps annotated cccs to cccs:
Red2 (χ : h[ai1 , ai2 ], ⊗i) = χ. Red2 (·) is extended
to arbitrary conjunctions of annotated ccs.
Red3 (·), which maps every probabilistic agent program
to a non-probabilistic agent program:
Red3 (A ← Γ & L1 & . . . & Ln ) = A ← Red2 (Γ) & L1 & . . . & Ln .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 342/361
4. Extensions of IMPACT
3. Adding Uncertainty
Theorem 4.37 (Semantics as an Instance of paps )
Suppose all random variables have the form h{objectRV }, 1i.
Then: (χ : h[ai1 , ai2 ], ⊗i is a ground annotated ccc, Op a
probabilistic agent state)
Satisfaction: the satisfaction relations coincide, i.e.
Op |=[ai1 ,ai2 ] χ : h[ai1 , ai2 ], ⊗iiff Op |= Red2 (χ : h[ai1 , ai2 ], ⊗i).
App-Operators: the App-Operators coincide, i.e.
AppRed3 (PP),O
Op (PS).
Op (PS) = AppPP,O
Feasibility: Feasible probabilistic status sets coincide with
feasible status sets under our reductions, i.e. PS
is a feasible probabilistic status set w.r.t. PP if
and only if PS is a feasible status set
w.r.t. Red3 (PP).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 343/361
4. Extensions of IMPACT
3. Adding Uncertainty
Up to now, we assumed:
An action can be executed only if its
precondition is believed by the agent to be
true in the agent state with probability 1.
Every action that is permitted must also have
a precondition that is believed to be true
with probability 1.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 344/361
4. Extensions of IMPACT
3. Adding Uncertainty
Every probabilistic state implicitly determines a set of
(ordinary) states that are “compatible” with it.
Op ))
Definition 4.38 (Compatibility w.r.t. State: COS(O
Let Op be a probabilistic agent state. An (ordinary) agent
state O is said to be compatible with Op if, by definition,
for every ground code call a : f ( d1 , . . . , dn) , it is the case
a : f ( d1 , . . . , dn) , O ), there
that for every object o ∈ eval(a
exists a random variable
a :RV f ( d1 , . . . , dn) , Op ) such that o ∈ X and
(X, ℘) ∈ eval(a
℘(o) > 0, and there is no other object o0 ∈ X such that
a : f ( d1 , . . . , dn) , O ).
o0 ∈ eval(a
Op ).
We use the notation COS(O
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 345/361
4. Extensions of IMPACT
3. Adding Uncertainty
Example 4.39
Consider a probabilistic agent state O p with only two code
calls surv : identify
identify((image1)) and surv : location
location((image1)),
which respectively return the random variables
h{t80, t72, t70}, {ht80, 0.3i, ht72, 0.7i, ht70, 0.0i}i
and h{loc2}, {hloc2, 0.8i}i. The agent states compatible
w.r.t. Op are described in the following table:
State
1
2
3
State
4
5
6
Prof. Dr. Jürgen Dix · LIP 6, UPM
Vehicle
none
t80
t72
Vehicle
none
t80
t72
Location
none
none
none
Location
loc2
loc2
loc2
Panam Seminaire, 17. March 2007 346/361
4. Extensions of IMPACT
Prof. Dr. Jürgen Dix · LIP 6, UPM
3. Adding Uncertainty
Op ))
α(COS(O
Op )
COS(O
if P re(α) is true
in the real state
if P re(α) is false
in the real state
Op ))
α(COS(O
Panam Seminaire, 17. March 2007 347/361
4. Extensions of IMPACT
3. Adding Uncertainty
It would be nice if
agents were able to reason about the effects
of their actions even when they are not
exactly sure what the world state is.
Probabilistic Kripke Structures
actions could be applied even when the
precondition is only true wrt. a certain
probability p < 1.
p-Feasible Status Sets
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 348/361
4. Extensions of IMPACT
4. TP Agent Programs
4.4 TP Agent Programs
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 349/361
4. Extensions of IMPACT
4. TP Agent Programs
Definition 4.40 ((TP-annotation [⊗, h[t1 , t2 ], δi, [`1 , `2 ]]))
A TP-annotation is a triple [⊗, h[t1 , t2 ], δi, [`1 , `2 ]] where ⊗ is
a probabilistic conjunction strategy, h[t1 , t2 ], δi is a
temporal interval with a pdf δ over it, and [`1 , `2 ] is a
probabilistic interval. A TP-annotation is ground if `1 , `2
are ground.
For example, [⊗ig , h[Xnow + 2, Xnow + 7], δu i, [X, X+1
]] is a
2
TP-annotation where ⊗ig represents the “ignorance”
conjunction strategy and δu represents the uniform
distribution. This annotation is not ground due to the
presence of the variable X. However,
[⊗ig , h[Xnow + 2, Xnow + 7], δu i, [0.3, 0.5]] is considered to be
ground.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 350/361
4. Extensions of IMPACT
4. TP Agent Programs
Definition 4.41 ((TP- CCC, TP- ASC))
If χ is a (ground) code call condition (ccc),
(A1 ∧ . . . ∧ An ) is a (ground) action status
condition, and [⊗, h[t1 , t2 ], δi, [`1 , `2 ]] is a (ground)
annotation, then χ : [⊗, h[t1 , t2 ], δi, [`1 , `2 ]] is a
(ground) TP code call condition (TP-ccc), and
(A1 ∧ . . . ∧ An ) : [⊗, h[t1 , t2 ], δi, [`1 , `2 ]] is a
(ground) TP action status condition (TP-asc).
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 351/361
4. Extensions of IMPACT
4. TP Agent Programs
The following is an example TP code call
condition:
in(( c, d : f ( a, b))) : [⊗ig , h[Xnow + 2, Xnow + 7], δu i, [X,
X+1
]].
2
This condition says that there is a probability in
the probabilistic interval [X, X+1
2 ] that at some
time point between Xnow + 2 and Xnow + 7, the
code call d : f ( a, b)) will return c in its output.
Furthermore, for any specific time point in this
time interval, the specific probability that c will
be returned is uniformly distributed.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 352/361
4. Extensions of IMPACT
4. TP Agent Programs
Definition 4.42 (TP-rule)
A temporal probabilistic (TP) rule is an expression
SA0 ← tpccc1 ∧ . . . ∧ tpcccn ∧ asc1 ∧ . . . ∧ ascn ,
where SA0 , asc1 , . . . , ascn are TP- ASC’s, and
tpccc1 , . . . , tpcccm are TP- CCC’s.
A temporal probabilistic (TP) rule is strict if any
annotation that appears in the rule and is associated with
a status atom is of the form [⊗, hti, δi, [1, 1]]. We often write
(A1 ∧ . . . ∧ An ) : [⊗, hti, δi] instead of
(A1 ∧ . . . ∧ An ) : [⊗, h[te1 , te2 ], δi, [`, u]] when at least one
of the Ai ’s is a status atom.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 353/361
4. Extensions of IMPACT
4. TP Agent Programs
Definition 4.43 (TP Agent Program (T PP))
A temporal probabilistic agent program (T PP)
is a finite set of strict TP rules.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 354/361
4. Extensions of IMPACT
4. TP Agent Programs
Example 4.44 (Stock example: T PP)
The following two rules encode the simple stock example
described earlier.
buy(X) : [⊗ig , h[Xnow , Xnow + 5], δu i] ←
Do buy
in(( X, stock : myportfolio
myportfolio(()) )
: [⊗ig , h[Xnow , Xnow ], δu i] ∧
in(( ”yes”, stock : over
over((X, 50))) : [⊗ig , h[Xnow + 10, Xnow + 20], δu i, [0.8, 1]]
Do buy
buy(X) : [⊗ig , h[Xnow , Xnow + 3], δu i] ←
in(( ”no”, stock : myportfolio
myportfolio(()) ∧
in(( ”ok”, stock : diversify
diversify((X))) : [⊗ig , h[Xnow , Xnow ], δu i] ∧
in(( ”yes”, stock : over
over((X, 50))) : [⊗ig , h[Xnow + 10, Xnow + 20], δu i, [0.9, 1]]
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 355/361
4. Extensions of IMPACT
4. TP Agent Programs
Example 4.45 (Stock example and coherence)
Consider a TP CC stock : up
up((P)) asking for an estimate of the
stocks that will go over the value P tomorrow. This TP CC
may return two random variables.
RV1 = h{IBM, HP }, ℘1 i.
RV2 = h{GM, F ord}, ℘2 i.
Either the value of IBM’s stock or HP’s stock will go over P
tomorrow and either the value of GM’s stock or Ford’s
stock will go over P tomorrow. If we assume that ℘1
assigns 0.5 to both IBM and HP and ℘2 assigns 0.7 to GM
and 0.3 to Ford then, we know that the probability of the
value of IBM’s stock to go over P is 0.5.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 356/361
4. Extensions of IMPACT
4. TP Agent Programs
Example 4.46 (continued)
However, suppose that this TP CC returns the following
two random variables.
RV01 = h{IBM, HP }, ℘1 i.
RV02 = h{IBM, F ord}, ℘2 i.
If we assume that ℘1 assigns 0.5 to both IBM and HP and
℘2 assigns 0.7 to Ford and 0.3 to IBM then what is the
probability that the value of IBM will go over P
tomorrow? There is no simple answer and thus we
require the notion of coherence.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 357/361
4. Extensions of IMPACT
4. TP Agent Programs
Definition 4.47 (Coherent set of random variables)
A random variable RV of type τ is a pair
RV = (Obj , ℘) where Obj is a finite set of
elements of type τ and ℘ is a probability
distribution over Obj that assigns real numbers
in the unit interval [0, 1] to members of RV such
that Σo∈Obj ℘(o) ≤ 1. A set S of random variables
of type τ is coherent if, by definition, whenever
we consider two distinct
(Obj 1 , ℘1 ), (Obj 2 , ℘2 ) ∈ S, it is the case that
Obj 1 ∩ Obj 2 = ∅.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 358/361
4. Extensions of IMPACT
4. TP Agent Programs
Definition 4.48 (Temporal probabilistic cc (TP CC))
A temporal probabilistic code call based on cc
TP
of type τ , denoted cc , returns a mapping from
natural numbers to coherent sets of random
variables of type τ .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 359/361
4. Extensions of IMPACT
4. TP Agent Programs
Theorem 4.49 (Computing semantics with DT P )
Let T PP be a strict temporal probabilistic agent
program, and O a state.
ω
1 There is a TPSI ρ compatible with DT P ↑
which is TP deontically closed and temporally
action closed.
2 If ρ is a feasible TPSI, then it is compatible with
DT P ↑ω .
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 360/361
4. Extensions of IMPACT
4. TP Agent Programs
Theorem 4.50 (Complexity)
Suppose the current time is tnow , T PP is a TP
program, O is an agent state, acthisttnow is an
action history and IC is a set of integrity
constraints.
1 The problem of checking whether a given finite
TPSI ρ is feasible or not, can be done in
polynomial time.
2 The problem of checking whether a feasible
finite TPSI ρ exists, is NP-complete.
Prof. Dr. Jürgen Dix · LIP 6, UPM
Panam Seminaire, 17. March 2007 361/361