Describing Events and Actions in First-Order Temporal Logic

1. Computer and Information Science SeminarUniversity of Otago, 15 August 2003 Describing Events and Actionsin First-Order Temporal Logic 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 history or path states • 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: pp is true now X+pp will be true at the next instant X–pp was true at the previous instant pU+qq 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–qq 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+pp will eventually be true (inclusive of present) F–pp has been true (inclusive of present) G+pp will always be true (inclusive of present) G–pp has always been true (inclusive of present) G pp 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 isopen the door isclosed • 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 tis 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) =defEvType(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)  GEvType(e,t) • every event token has at least one type: Happ(e)  tEvType(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)  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)  eHapp(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) =defHapp(e,t)  Actor(e,x) Done(x,t) =defeDone(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 typet • 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 questionto 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 typet, 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 tand 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 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