Situation Modelling

Dey was among the first to refer to situational abstraction [35]. He described it as a level above widgets, interpreters and aggregators, i.e. in current terms a level above the context management system. Dey’s motivation in defining the term situation was to support context-aware designers to focus on the ‘heart of the design process’. He proposed that a tool which focused at the situation level would free the designer of lower-level concerns, so the designer could focus on the features, reactions and adaptations for the ubicomp system.

Bettini et al. [17] provide a diagram which illustrates Dey’s references to the situation level. For clarity, their diagram has been reproduced here in Figure 3.1. The diagram illustrates the three layers of abstraction for sensor data and context, which Bettini et al. define. At the base of this triangle is low-level context information, which is data

in its least processed form, direct from the source, e.g. sensor outputs. The middle layer is characterised by some semantic interpretation, while still formatted in such a way that the data is composable and reusable. Finally, the top layer, situation relationships, is most closely aligned with Dey’s description of the situation level.

Bettini et al.’s definition of the situation level refers to situational relationships as a collection of situations. Dey refers to a situation as a collection of states. Although the language is different, the fundamental meaning is the same. Both are describing a highly abstracted level of context which is heavily focused at the application layer.

Figure 3.1: Bettini et al.’s diagram of the layers of context [17].

Henricksen and Indulska [50] were among the first to formalise Dey’s early definition of situation abstraction in their work on the Context Modelling Language (CML). CML provides a formal example of a situation specification model, which uses predicate logic to describe the relationships between fact types (information) from the deployment environment. CML provides constructs to describe context for the purpose of prototyping and fine-tuning context-aware applications, and so can model metatdata as well as contextual information. Although this means that CML extends beyond situation specification, it is fundamentally relevant to situation specification.

CML is based around information tuples, which aggregate information through the use of logical expressions. The main fact types defined by CML are Person, Device,Activity andLocation. CML also defines some fact types for communication resources in a ubicomp environment, however this issue was ruled out of scope in the background chapter, so within the bounds of this thesis, these fact types are not discussed. In terms of relationships CML defines located at (i.e. containment

or physical coordinates), located near (i.e. proximity), engaged in (i.e. a user’s relationship to an activity) and permitted to use (i.e. resource permissions). CML also makes use of logical relationships including ∧ (and), ∨ (or), ¬ (not). This combination enables CML to address both logical and spatial relationships in situation specifications. Henricksen and Indulska define a situation (S) as:

S(v1, . . . , vn) :φ

where

{v1, . . . , vn}= Set of free variables

φ =Logical expression

Clear et al. [28, 27] have completed work on situation specification to support their work on SituVis, a visualisation tool for situational analysis. SituVis provides intuitive views of situations specifications, using Parallel Coordinate Visualisation, which plots discrete pieces of information on a set of parallel vertical axes, each axis representing a type of context. As part of this work, Clear et al. developed a formal definition of a situation specification:

A situation specification consists of one or more assertions about context that are conjoined using the logical operators AND (∧), OR (∨) and NOT (¬). Assertions may comprise further domain-specific expressions on context, given that the required semantics are available.

This provides the formal language required in order to chart situational data. Additionally, it takes steps beyond previous efforts by contributing towards formally differentiating between interpreted context and a situation specification. The work by Clear et al. is not limited to situation specification. This work also looks at the relationships that can occur between situations, i.e. in terms of overlap between situations or situations that subsume other situations. In this way SituVis enables evaluation and analysis of situations with a view to uncovering potential conflicts, and so affords designers an opportunity to gain better understanding of the situation space.

Nishikawa et al. [80] use a computation tree logic (CTL) approach to situation specification, in their tool UbiREAL. Their aim is to validate a system implementation using a specification defined in CTL. Using this approach, Nishikawa et al. use multiple situation specifications together to define a service specification. To achieve this, it is necessary to create a formal situation definition that can be used with the CTL language. The authors define the state of the environment (U) as a tuple (R, D), where R is the set of all rooms and D the set of all devices, as follows:

U = (R, D) where:

R ={r1, . . . , rn}

D={d1, . . . , dn}

Within these definitions,rj ∈Rhas attributes: position (pos), shape and size (base),

capacity (cap), temperature (temp), humidity (humid), heat capacity (heatcap), illumination (illum), and acoustic volume (vol). Attributes are denoted asrj.temp,

using temperature as an example. dj ∈ D has attributes: room (r), position in a

room (pos), and state (state). Attributes for devices are denoted in the same way, for exampledj.r denotes the room attribute of devicedj, i.e. the room in which the

device is deployed.

In addition to specifying the environment, Nishikawa et al. use CTL to define a situational system specification. This specification is rule based, where the set of rules, AP = {l1, . . . , ln}, define the system. Each rule is comprised of a condition

and an action, i.e. li = (ci, ai). The authors have not provided a full list of operators,

however they use examples such as the following as illustrations:

(Exist(u1, r1)∧28≤r1.temp∧70≤r1.humid, Aircon1.on(24,60))

This example specifies that when user u1 is in room r1, and temperature and

humidity are more than 28C and 70% respectively, Aircon1 should be switched

Based on this discussion it can be seen that situation models must address the attributes of and relationships between users, entities and locations. This falls in line with Dey’s early discussion on situational abstraction in which he recognises these as the basic elements of a situation [35].