Describing%20Events%20and%20Actions%20in%20First-Order%20Temporal%20Logic

1
Describing Events and Actionsin First-Order
Temporal Logic
Computer and Information Science
SeminarUniversity of Otago, 15 August 2003

• Marco Colombetti
• Politecnico di Milanoand Università della
  Svizzera italiana

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

4
Basic temporal operators

• There are both future and past directed basic
  operators
• p p is true now
• Xp p will be true at the next instant
• Xp p was true at the previous instant
• pUq 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
• pUq 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
• Fp p will eventually be true (inclusive of
  present)
• Fp p has been true (inclusive of present)
• Gp p will always be true (inclusive of present)
• Gp p has always been true (inclusive of
  present)
• G p p is always true (in the past, present, and
  future)
• G?p (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 j
• Validity of a formula is defined as truth at all
  states of all models
• j
• Certain formulas are atemporal, in the sense that
  their truth in a model does not depend on the
  state
• Formula j is atemporal if and only
• j ? Gj

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)?? G??Happ(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) ? FSick(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) ? FHapp(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)) ? XCause(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 Quines quotes

• A better approximation can be obtained by using
  Quines quotes
• if j is a formula (possibly belonging to a
  predefined proper sublanguage of the whole
  first-order language in use), then
• ?j?
• denotes a first-order term that provides a
  canonical representation of j
• General axioms
• Happ(e,?j?) ? X?j ? j
• LogPoss(?j?) ? X?j
• Declarable(?j?) ? CountAs(declare(?j?),?j?)

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