# Introduction to Situation Theory Part II

Posted on Tue 12 October 2010 in Situation Theory tutorial

## Fundamentals of Situation Theory

Situation theory is built on a rich ontology of objects including
infons, situations, n-place relations, individuals, spatial and temporal
locations, types, parameters, and polarities. We will adopt the account
in (Devlin 1991) and assign to each of these a corresponding basic type:
*INF*, *SIT*, *RELn*, *IND*, *LOC*, *TIM*, *TYP*, *PAR*, and *POL*. In general we indicate
that an object *x* has type *T* by writing \(x:T\). In general there is no
restriction on the number of elementary types something may have. For
example, we may want to treat an event like a football game as a
situation on one occasion, and as an individual on another
occasion.

### Situations

Situations are first-class objects in situation theory. Situations are
taken to be actual parts of the world and are supposed to correspond to
our every day notion of a situation. Situations are said to support
various informational items, called *infons*. We say that a situation *s*
supports an infon, *σ*, written \(s\vDash \sigma\), if *s*
makes *σ* factual. For example, the current situation in my office, call
it *s'*, supports the infon that an unread copy of Thomas Pynchon's The
Crying of Lot 49 sits on my desk.

Because in general situations are not total worlds, a situation will not
necessarily decide any particular issue raised by an infon. A situation
will either support an infon, or it's dual, or have nothing to say about
the issue. For example, while the situation *s'* supports the fact that
Pynchon's novel sits on my desk unread, my situation has nothing to say
about whether or not that novel is currently sitting on the President's
desk, nor does it decide the issue of whether the Chicago Cubs will win
the World Series in 2020 (or indeed ever).

### Infons

We adopt (Devlin 1991)'s presentation of infons. An infon is an object
that specifies a *propositional issue* of the form

where *R* is an *n*-ary relation, \(p\in
\{0,1\}\) is the polarity of the infon, and objects \(a_1\) through
\(a_n\) are the objects filling in the *n*-ary relation each of some (possibly
different) type *T*. If the polarity is 1 then the infon indicates that
objects \(a_1...a_n\) stand in the relation \(R\). If the polarity is 0, then the
infon indicates that objects \(a_1...a_n\) do not stand in that relation. Note
that an infon is itself neither true nor false whatever its polarity
happens to be. Infons are not the type of objects to which truth values
can be assigned. That is, infons are not propositions; they are
constituents of propositions. Note also that if objects \(a_1...a_n\) are not
of the appropriate type for that infon, then the infon is not
well-formed, at least according to some situation theorists. The
practical effect of this is the exclusion of semantically nonsensical
infons.

In natural language a sentence will typically leave possibly relevant information unstated, either because it is not relevant or because it is implicit in the utterance context. For example, sentence \(S_1\) below leaves out exactly what Roger won:

This information might be supplied by the context in which the sentence is uttered, or the hearer may already know. It may also be the case that the speaker either does not know herself, or does not think it worth being more specific. Whatever the case, our infons will need to be able to handle cases of partial information.

In Devlin's version of situation theory, a relation has a fixed number
of argument places which may be filled or may not be filled with some
object. For any given relation with n argument places, that relation is
saturated if it has n arguments and unsaturated if it has fewer than *n*.
To make this more clear, a more formal definition of an infon follows:

#### Definition 1.1 Infon (Devlin 1991, 115-116)

If *R* is an *n*-place relation and \(a_1..._am | (m=n)\) are
objects appropriate for the argument places \(i_1...i_n\) of *R* and if the
filling of argument places \(i_1...i_m\) is sufficient to satisfy the
minimality conditions for *R*, then for \(p\in \{0,1\}\),
the object \(<<R,a_1...a_m,p>>\) is a well-defined infon. If \(m < n\) then
the infon is unsaturated and if \(m = n\), then it is saturated.

Unsaturated infons leave some of the arguments unfilled and thus
represents a piece of partial information. For example, we might have a
four place relation \(<WonAt, p, g, t, l>\) where *p* is a person, *g* is the
game won at, and *t* and *l* are the spatial and temporal location of the
winning. We could then represent an informational content associated
with the sentence *S_1* by the infon \(<<WonAt, Roger; 1>>\), which as can
be seen does not include *g*, *t*, or *l*.

Other versions of situation theory vary with respect to the aforementioned structure of infons, particularly with regard to the saturation of infons.

### Relations

We will now take a closer look at relations in situation theory. Recall
that a relation is an object of type *RELn*, where *n* is the fixed arity of
the relation. For example, if the relation in an infon is the relation
of *GiftGiving*, then we might have arguments for giver, gift, recipient,
time, and location so that the relation is specified as:

But this specification has a serious defect. To see this all one has to do is to note that any three arbitrary individuals (objects of basic type IND) may fill the first three arguments of the relation. For example, one might have house\to giver, mountain\to recipient, and verb\to gift, indicating that a house gave a verb to a mountain.

To prevent inappropriate objects from filling arguments, we need a more nuanced way to specify argument roles. Clearly our basic types are not sufficient. In the section on types we will see how this may be accomplished. However, before we do, we will introduce some of our remaining basic types: individuals, temporal and spatial locations, and parameters.

### Individuals

Situation theory assumes a world of individuals, parts of the world individuated by some agent or theorist relative scheme of individuation. Individuals are those things that one counts as objects. Individuation presupposes discrimination since what one cannot discriminate, one cannot usually individuate. Individuals need not be atomic. A flashlight may be regarded as an individual, but we might also individuate the parts of a flashlight.

### Spatial and Temporal Locations

Objects of type TIM and LOC represent temporal and spatial locations respectively. A location may be a single moment in time or single point in space, or more commonly, some time interval or spatial region. Two objects of the same temporal or spatial types may overlap, and appropriate operators may be designated to represent such an overlap. Temporal and spatial locations are deemed to be fundamental enough, and useful enough, to be given their own basic types in the ontology. Naturally spatial or temporal objects may also be treated as objects of other types (like individuals, or even situations).

### Parameters

In specifying a set of infons, it is often useful to be able to fill an argument place without having to specify any definite object. Parameters are used to denote an arbitrary object of some type, much like variables in first-order logic. For example, we might want to have a parameter \(\dot{p}:IND\) to represent some as yet unspecified individual. We then could use that parameter in a number of ways, as described below.

An infon which contains a parameter is a parametric infon. A parameter in a parametric infon may be anchored (or bound) to some object having the same type as the parameter. Given a parametric infon σ, σ[f] is the infon obtained by replacing each parameter \(\dot{p}\) in the domain of the anchoring function f and free in σ, with the value \(f(\dot{p})\), which must be of the same type as \(\dot{p}\).

For example, the parameter \(\dot{p}\) in the parametric infon

may be anchored to the person Roger if \(f(\dot{p})=Roger\). We will generally use the term infon to refer to both parametric and non-parametric infons. Terminology varies. Non-parametric infons are often called states of affairs. The term infon was introduced by Devlin to include parametric states of affairs. For more information, see (Devlin 1991, 54).

Parameters like the one above are a little too general to be always useful. For example, suppose that we want \(\dot{p}\) to be anchorable only to persons and not to any arbitrary individual (like a dog or a crayon).

A restricted parameter \(\dot{r}=\dot{p}{\bf \upharpoonright
}C\) is the parameter obtained by restricting a parameter by some
condition *C*, where *C* is a set of non-degenerate infons containing
\(\dot{p}\). For example, we can define a parameter
\(\dot{h}\) to be those individuals
\(\dot{p}:IND\) who are human: \(\dot{h}=\dot{p}{\bf
\upharpoonright }<<IsHuman,\dot{p},1>>\)

We still need to restrict the anchoring function in an appropriate way. We do this now.

#### Definition 1.1 Anchor (Devlin 1991, 55)

Let \(\dot{r}=\dot{p}{\bf \upharpoonright } C\) be a
parameter. Given a situation, *s*, a function *f*, is said to be an anchor
for \(\dot{r}\) in *s* if:

*f*is an anchor for \(\dot{p}\) and for every parameter that occurs free in*C*- for each infon σ in
*C*: \(s\vDash\sigma [f]\) - \(f(\dot{r})=f(\dot{p})\).

### Types

Situation theory regards types as high-level uniformities enabling information flow. We have already introduced the basic types used in situation thoery. One may also build more specific and useful types by type abstraction in which we abstract away from some set of parametric infons. For example, we might have a type of situation, or a type of object, or a type of location. We will construct examples of these types in the next sections.

#### Situation Types

A situation type is a type of situation, the type of situations for
which some condition obtains, like situations involving the Chicago Cubs
losing a ball game, or Charlie Brown trying to kick Lucy's football. The
general form of a situation type is \(T=[\dot{s}|\dot{s}{\rm
\models }I]{\rm \; }\) where \(\dot{s}\) is a
situation parameter and *I* is some infon supported by
\(\dot{s}\). When some situation \(s:T\), then *s* is a situation
supporting the infon *I*.

For example, we can define the type of situation in which I lose a game of chess to my brother Joshua:

A situation \(s:L\) if \(s \vDash <<LoseChessGameTo,Jacob,Joshua,1>>\).

If whether the game is a game of chess is the question at issue, we might propose a more nuanced type such as:

in which case a situation is of that type if it supports both of the infons found in the type definition.

### Object Types

We may define types of object, such as types of individuals, types of locations, types of situations (not to be confused with situation-types), and types of relations. Object types are grounded in some situation.

For example, we might want to define an object type for a state won by
Barack Obama in the 2008 Presidential election. We let our grounding
situation s be the 2008 Presidential election. We define a restricted
parameter \(\dot{u}=ind<<IsUSState,ind,t,1>>\) to sit
for a state in the United States where *t* is the temporal location of the
2008 election. We then define an object type \(W=[\dot{u}|s \vDash <<WonByObama,\dot{u},t,1>>]\).
Given the 2008 Presidental election situation, a U.S. state *u* has type *W* when
\(s \vDash <<WonByObama,u,t,1>>\).

Our use of a parameter \(\dot{u}\) means that when when an
object is of type *W*, then there is a resource situation *r* such that
\(r \vDash <<IsUSState,u,t,1>>\) for some object *u* to which the parameter is
\(\dot{u}\) anchored.

We may also define parametric types, types containing free parameters. For example, instead of grounding the type to a particular grounding situation, we can ground it to some (possibly restricted) range of situations by using a parameter. We work out an example below.

Parametric Type Example: deadlock situations

Let us define a type for the kind of situation in which two arbitrary processes \(\dot{p}_{1}\) and \(\dot{p}_{2}\) are deadlocked due to holding exclusive locks on some pair of resources \(\dot{r}_{1}\) and \(\dot{r}_{2}\).

We first give suitable restrictions for our parameters. We will distinguish our basic parameters from our restricted parameters, when necessary, by spelling out in lower-case the name of the basic parameter type, followed by some subscript, and using the former notation for our restricted parameters.

Let \(ind_1:IND\), \(ind_2:IND\), \(ind_3:IND\), and \(ind_4:IND\) be four basic parameters
of type *IND*, and let \(\dot{s}:SIT\) be a (basic) parameter
of type *SIT*.

Let:

We now define a deadlock situation type DLCK using our parameters.

This is a parametric situation type. A situation will be of this type if there are two processes and resources and a temporal location for which the HOLDS and REQUESTS relations hold.

We can specify the relations *HOLDS* and *REQUESTS* as

where *PROC* and *RESC* are types defined by:

where \(\dot{p}=ind:IND<<process,ind,1>>\) and

where \(\dot{r}=ind:IND<<resource,ind,1>>\).

Before we end this section, a final remark on parameters is necessary.
The use of a parameter in an infon raises the issue of whether there
exists some object to fill the role in the infon's relation, but the use
of the parameter should not be understood as existentially (or
universally) quantifying over something. For example, the use of the
parameter in \(<<IsHuman,\dot{p},1>>\) should not be
interpreted as the proposition that there exists some p such that p is
human in the situation *s*. To get that one must explicitly quantify over
the expression. Instead, parameters are used to reserve argument places
for objects, and to show relationships between these argument places
between infons.

## Next...

In the next article in this series we will give an overview of infon logic.