Navigation links: up | package

Foundation: State (formerly known as Situation)

N.B. Most of the on-line documentation (including the rest of this page) still uses the older term, Situation rather than State.

In MESSAGE, the world is a collection of ConcreteEntities engaging in Activities. A full description of a world state consists of a description of the state of every ConcreteEntity and Activity within it. A description of a world state is only meaningful in the context of a point in time. The evolution of the world in time can be described fully by a description of the world state at a specific point in time and a list of all the Events in which the world participates before and after that time. This full description is referred to as the world history.

Except in very simple worlds, it is not useful to work with full state or history descriptions. Many facets of the state will not be relevant to the matter in hand. The concept of Situation is introduced to deal with this. A Situation is a macro-level analogue of a world state. It associates a partial description of the world state and event list (i.e. a constraint on the world history) points on the world time-line. The atTime relationship is the formal mechanism for associating a point on the world time line with a Situation that holds at that time. It signifies that at the specified point in time, the world state is one of the set of states consistent with the constraint.

Let us refer to the constraint associated with a Situation as a situation specification. Perhaps the simplest example of a Situation specification is a constraint that an attribute of a given ConreteEntity should have a specific value. There will be (potentially) many points in time at which this specification holds, i.e. many Situation instances correspond to a given situation specification. A situation specification thus defines a Situation class. If the world history is sufficiently well-known, all the instances of a Situation class can be identified. The associated time points will fill a set of intervals on the world timeline, which form the timeline of the Situation class. Note that changes to world states are caused by Actions, which are observable as Events. Consequently, the beginnings and ends of the intervals in a Situation class's timeline are correspond to instances of Events in the world history. The start and end Events of the interval associated with a Situation instance are accessible via the start() and end() operations.

Specialisation of a Situation class corresponds to making the specification more restrictive. Suppose that Situation class B specification is consistent with that of Situation class A, but is more restrictive:

• any world state consistent with B's specification is also consistent with A's
• if at time t, the world can be characterised as an instance of B, then it can also be characterised as an instance of A. It can thus be said that the instances of B are also instances of A, and hence that B is a subset of A
• the instances of B are also instances of A, so we can say that B is a subset of A, and also that
• the timeline of B is a sub-set of the timeline of A
• we can say that B => A (see the implies relationship)

In the above discussion, care has been taken to distinguish between Situation classes and instances. It would be tiresome to be so pedantic all the time, however. Elsewhere, the term Situation will commonly be used. Often, context will make clear whether Situation class or instance is refered to. In particular, if reference is made to a Situation beginning or ending, it should be understood that the reference is to an interval on the timeline of a Situation class.

Linkage to UML

See also

• TimePoint
• Event
• Action
• LogicalRelationship

Comments

• The concept of Situation used here is related to, but not the same as that used in the Situation Calculus (a well-known knowledge representation formalism).