In the course of the research that was undertaken different projects that relate to context-aware computing have been carried out. In the beginning the understanding was driven from the idea that context can add a new quality to mobile computing devices and applications [Schmidt,98]. At the IMC99 workshop we proposed a tree that offers structure for context. After further developments we realised that having a such a tree is a very pragmatic approach and helpful to implement a certain class of applications, however it lacks generality. In [Schmidt,99] we published a “Working
Model for Context-Aware Mobile Computing” which is presented in the following paragraphs. This model extends the closed tree originally proposed for an open tree model that offers a general structure that can be extended to suit the application domain.
2.2.7.1 A Working Model for Context-Aware Mobile Computing
To structure the concept of context we propose the following model:
• A context describes a situation and the environment, a device or user is in. • A context is identified by a unique name.
• For each context a set of features is relevant.
For each relevant feature a range of values is determined (implicit or explicit) by the context.
In terms of this model, a hierarchically organised feature space for context can be developed. At the top level we propose to distinguish context related to human factors in the widest sense, and context related to the physical environment. For both general categories we propose further classification into three categories each, as shown in Figure 1. We use the six categories at this level to provide a general structure for
context. Within each category, relevant features can be identified, again hierarchically, whose values determine context. Additional context is provided through history that changes in the feature space over time.
Human factors related context is structured into three categories: information on the user (knowledge of habits, emotional state, bio-physiological conditions, etc.), the user’s social environment (co-location of others, social interaction, group dynamics, etc.), and the user’s tasks (spontaneous activity, engaged tasks, general goals, etc.). Likewise, context related to physical environment is structured into three categories: location (absolute position, relative position, co-location, etc.), infrastructure (surrounding resources for computation, communication, task performance, etc.), and physical conditions (noise, light, pressure, etc.).
The described model provides some structure for consideration of context. For pragmatic use of context, the general challenge is to identify the set of relevant features in terms of which a situation or environment can be captured sufficiently. Situations and environments are generally characterised by a large degree of continuity over time, so that context history itself becomes an important feature for approximation of a given situation or environment. Time is implicitly captured in the history.
2.2.7.2 Reconsidering Dimensions – Project TEA
In the research project Technology for Enabled Awareness [TEA,98] we defined context as follows:
“Context awareness is knowledge about the user’s and IT device’s state, including surroundings, situation, and, to a lesser extent, location.”
To describe contexts we moved to a three-dimensional space as depicted in Figure 2, with dimensions Environment, Self, and Activity. A fundamental difference to earlier work was the observation that context is not necessarily related to location.
This is similar to the previous tree structure but discrimination on the top-level is different. With the introduction of a “self” dimension the issue to what context is
related to (device, user, and application) is addressed. Context has many aspects and this model is especially targeted at mobile appliances (e.g. PDAs, phones).
2.2.7.3 Revising the Model and Further Issues
Both models above have been developed with a focus on mobile systems. When developing embedded and stationary context-aware systems [Gellersen,99a], [Schmidt,02] we investigated further approaches. In chapter 4 a bottom-up approach for identifying parameters that are relevant to make things context-aware is presented in more detail.
Within the Smart-Its project [SMART,02], where the notion of collective awareness is a central research issue, it became apparent that the relation between artefacts and other artefacts, or artefacts and humans, is essential for modelling context-aware systems, however at this point such a model has still to be developed.
The following observations conclude the discussion of definitions, characterisations, and models for context, and point out a few issues to consider when re-defining context or proposing a new model:
• Stimulate Discussions. In many cases models or definitions have been weak
or not complete, yet they have led to serious discussions of the subject. Even if
a definition or model only explains part of the issues it can lead to an interesting scientific discussion.
• Revising Viewpoints. Definitions should not to be considered as absolute and
models can evolve or transform. When a model is not useful in a new domain or for new types of contextual information it has to be revised. This does not suggest that the “old” model was bad it’s just a way of moving on and improving.
• Scoping. As explained earlier a very restrictive model usually helps to
efficiently implement systems, whereas a general model can explain everything. Often this issue comes down to an attempt of modelling the whole world vs. modelling a specific application. The purpose of the model or definition should be used to determine the scope. In some cases it may even lead to models on different levels.