Università della Svizzera italiana Describing Events and Actions in First-Order Temporal Logic Marco Colombetti Politecnico di Milano and Università della

UniversitàdellaSvizzeraitaliana

QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.

Describing Events and Actionsin First-Order Temporal Logic

Marco Colombetti

Politecnico di Milanoand Università della Svizzera italiana

Computer and Information Science SeminarUniversity of Otago, 15 August 2003

2



Representing events and actions

Many logical systems for reasoning about action use some version of modal or dynamic logic to describe events and actions

Such systems have fairly complex model and proof theories, and as a consequence most practitioners of artificial intelligence and agent-based programming simply ignore them

First-order logic with equality, integrated with temporal operators, is sufficient for many applications involving the representation of events and actions

3



Time: LTL with past

Time is here assumed to be

discrete

linear

infinite both in the past and in the future

states

history or path

4



Basic temporal operators

There are both future and past directed basic operators:

p p is true now

X+p p will be true at the next instant

X–p p was true at the previous instant

pU+q q will eventually be true, and p is going to be true from now (inclusive) until the first

time (exclusive) q becomes true in the future

pU–q q has been true in the past, and p has been true since the last time (exclusive) q has

been true in the past until now (inclusive)

5



Derived operators

Many useful temporal operators can be defined in terms of the basic operators:

F+p p will eventually be true (inclusive of present)

F–p p has been true (inclusive of present)

G+p p will always be true (inclusive of present)

G–p p has always been true (inclusive of present)

G p p is always true (in the past, present, and future)

Gp (read: “g hole”) p has always been true in the past and will always be true in the

future, but may be false now

6



Temporal vs. atemporal statements

The truth of a formula is defined in a model at a given state:

M,s

Validity of a formula is defined as truth at all states of all models:

Certain formulas are atemporal, in the sense that their truth in a model does not depend on the state

Formula is atemporal if and only:

G

7



Events

Intuitively, an event is a change in the state of affairs

An events is typically defined as a state change concerning some object (an individual object with identity):

Example: the door closes

the door is open the door is closed

However:

one may not want to consider any possible state change as an event

one may want to consider events that cannot be viewed, or at least cannot simply be viewed, as state changes (e.g., a flood)

8



Event types

Given a specific application domain, one singles out a number of event types of interest

Such event types can be represented, at an arbitrary degree of detail, by first-order functional terms

Examples:

x hits y: hit(x,y)

object a hits y: hit(a,y)

object a hits object b: hit(a,b)

9



Event tokens

In principle, an event type may have any number of concrete realisations, called event tokens or simply events

The first-order atomic formula

EvType(e,t)

(where the sort of e is event and the sort of t is event-type) means that event e has type t

The formula

Happ(e)

means that event e has just happened

10



Event tokens 2

A useful abbreviation:

Happ(e,t) =def EvType(e,t) Happ(e)

A few axioms:

event types are atemporal: if an event has a type, it has that type forever

EvType(e,t) G EvType(e,t)

every event token has at least one type:

Happ(e) t EvType(e,t)

event tokens are temporally unique: a specific event token may happen only once

Happ(e) GHapp(e)

11



Relationships among types

Any first-order relationship among event types can be described

Identity of types:

t t’

Equivalence of types:

t t’ =def e (EvType(e,t) EvType(e,t’))

Subtype relationship:

t t’ =def e (EvType(e,t) EvType(e,t’))

...

12



Defining event types

An event type can be related to all sorts of preconditions and effects:

Happ(e,ingest(x,y)) Poisonous(y) F+Sick(x)

In particular, an event type can be defined analytically (i.e., in terms of necessary and sufficient conditions) as a state change:

Happ(e,close(x)) X–Closed(x) Closed(x)

X–Closed(x) Closed(x) e Happ(e,close(x))

Happ(e,close(x)) Happ(e’,close(x)) e = e’

13



Causality

When dealing with causality, one should distinguish between (singular) causal links and (universal) causal laws

We assume that causal links, i.e. causal relationships between event tokens, are ontologically primitive. Causal laws are epistemic devices by which we represent known regularities in the occurrence of singular causal links

The formula

Cause(e,e’)

means that event e’ has just been caused by event e

The time direction axiom:

Cause(e,e’) F–Happ(e) Happ(e’)

14



Causal laws

A causal law represents the regular occurrence of causal links between events of given types:

Happ(e,hit(x)) Fragile(x) e’ (EvType(e’,break(x))

X+Cause(e,e’))

Causal laws used in commonsense reasoning tend to be vague, and are therefore difficult to express in classical logic

15



Actions

Actions are events intentionally brought about by agents

An action type is just an event type

An action token is an event token to which (at least) one actor (an individual of sort agent) is associated

Actor(e,x) x is an actor of e

Useful abbreviations:

Done(e,x,t) =def Happ(e,t) Actor(e,x)

Done(x,t) =def e Done(e,x,t)

16



Being an actor

Intuitively, agent x is an actor of an action of type t if and only if x intentionally brings about an event of type t

To avoid an analysis of intentions, we take the Actor predicate as a primitive

This means that the context of an application will have to provide enough evidence for an event to be considered as an action

Example:

Happ(e,query-if(x,y,s)) Actor(e,x)

where query-if(x,y,s) is the event type of sending a FIPA query-if message with sender x, receiver y, and content s

17



Institutional actions

Institutional actions are particularly significant for multiagent system applications

An institutional action is performed by executing a lower-level action, which in the appropriate context counts as a performance of the higher level action thanks to a set of conventions

Example:

lower-level conventional action: raising your hand ...

context: ... if you are a member of a class during a lesson ...

higher-level institutional action: ... counts as a request for permission to ask a question to the teacher

18



Counts as

Contrary to causal relationship, in the case of counts-as relationship only one event is involved: a single event e, of type t, is so to speak “promoted” to type t’ by a counts-as relationship

This means that a counts-as relationship is a relationship among one event token and two event types

On the other hand, here the relation between the two types is the ontological primitive: in fact, the counts-as relationship occurs thanks to a convention, so in this case the “law” (the convention) is prior to the singular occurrences of counts-as relationships

19



Counts as 2

This implies that a counts-as relationship has to be stated at the level of event types, together with the relevant contextual conditions

Class(u) Teacher(u,x) ClassMember(u,y) CountAs(raise-hand(y),req-perm-

query(y,x))

A similar formula defines a convention

Being man-made, it can be expected that conventions can be described with greater rigour and precision than causal laws

20



Logical possibility and authorisation

For the counts-as relationship to hold at the level of action tokens, two further conditions must hold:

the actor must be authorised to perform the institutional action: for example, only the chair of a meeting is authorised to open the meeting

the institutional action must be logically possible: for example, even the chair cannot open a meeting if the meeting is already open!

21



A comment on “can-do conditions”

Many AI approaches to action representation make use of the concept of possibility or “can-do conditions”

There are four different types of can-do conditions:

logical possibility: you cannot open a door that is already open

physical possibility: by normal means, you cannot open a door that is locked

institutional possibility or authorisation: you cannot open a meeting unless you are authorised to do so

deontic possibility or permission: you may be able to open a door even if it is forbidden to do so, but if you do so you enter a state of violation and are liable to a sanction

22



The axiom of institutional actions

The following axiom concerns the performance of institutional action tokens:

Done(e,x,t) CountAs(t,t’) LogPoss(t’) Auth(x,t’)

Done(e,x,t’)

Note that when the antecedent is true, the same action token e has both type t and type t’

Relevant contextual conditions may appear as the antecedents of authorisation:

Class(u) Teacher(u,x) ClassMember(u,y) Auth(y,req-perm-query(y,x)) )

23



Declarations

In many cases (maybe always?), it is possible to perform an institutional action by just declaring that the action is performed or that the effects of the action hold

Examples:

I declare the meeting open

I pronounce you man and wife

A good approximation to this is obtained through the following axiom:

[ Declarable(t) ] CountAs(declare(t),t)

In turn, an act of declaring may performed by sending a suitable message to all interested agents

24



Using Quine’s quotes

A better approximation can be obtained by using Quine’s quotes:

if is a formula (possibly belonging to a predefined proper sublanguage of the whole first-order language in use), then

denotes a first-order term that provides a canonical representation of

General axioms:

Happ(e,) X–

LogPoss() X–

Declarable() CountAs(declare(),)

25



“I declare the meeting open”

Example:

Meeting(m) Declarable(Open(m))

Meeting(m) (Auth(x,Open(m)) Chair(m,x))

From this we can derive:

Meeting(m0) Chair(m0,a) X–Open(m0)

Done(a,declare(Open(m0))) Open(m0)

26



To conclude

We are currently using this approach to define communicative acts as a special kind of institutional actions

The communicative acts are then used to define the semantics of the messages of an Agent Communication Language (this requires branching time instead of linear time)

References:

M. Verdicchio, M. Colombetti, 2003. A logical model of social commitment for agent communication, Proceedings of AAMAS 03, Melbourne

M. Verdicchio, M. Colombetti, 2003. A logical model for agent communication languages, Proceedings of LCMAS 03, Eindhoven

Documents

Università della Svizzera italiana Describing Events and Actions in First-Order Temporal Logic Marco Colombetti Politecnico di Milano and Università della