Readings' list

Anind Dey, Gregory Abowd, Daniel Salber, A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications, Human-Computer Interaction, 16(2-4), 2001.

This paper tries to systemize the task of designing and developing context aware applications.

They start with the various definitions of context given by previous researchers.
Their own definition is the following:

Context: any information that can be used to characterize the situation of entities (i.e. whether a person, place or object) that are considered relevant to the interaction between a user and an application, including the user and the application themselves. Context is typically the location, identity and state of people, groups and computational and physical objects.

The definition doesn't differentiate between automatically and manually acquired information.

Relevant entities whose context is assessed:

Categories, or characteristics of context information:

  1. Identity
  2. Location
  3. Status
  4. Time

These are basic information from whom it is possible to derive related context info.

Context aware functions:

  1. Presentation of information and services: application that present info to the user or use context info to present appropriate selections of actions to the user. (ex car's location on a map.)
  2. Automatically execute a service: applications that trigger a command. (ex mobile that change their mode according to the situation).
  3. Attaching context information for later retrieval: applications tag captured data with relevant context information.

Conceptual Framework for Handling Context

In order to simplify design of context aware functions the authors propose separation between context acquisition and the the use of context in applications. Their principles of software engineering are similar to the ones used for GUI.

Requirements for dealing with Context
  1. Separation of concerns: use a widget or interactor to abstract how the input is collected. Separation from how it is collected to how it is used. Uniform interface to different mechanisms. Querying mechanism and callback.
  2. Context interpretation: context may go through different layers before reaching an application and information from different sensors or applications may be put together to infer more abstract information. The architecture should provide more abstraction in order to be reused by several applications.
  3. Transparent, Distributed Communications: devices used to sense context might be physically distributed. The fact that the communication is distributed should be transparent to both sensors and applications.
  4. Constant availability of Context acquisition: the components that acquire context must be executing independently from the applications that use them. They must be persistent and available all the time.
  5. Context storage and history: a component that acquires context information should maintain a history of all the context it obtains.
  6. Resource discovery: the architecture needs to support a form discovery to know which kind of info the sensor can provide, where it is located and how to communicate with it.
Context Abstractions: Software Component of the Framework

The Conceptual framework proposed include the following components:

Context Widgets

They hide the complexity of the sensors, abstract  context information and provide reusable and customizable building blocks. They encapsulate context information and provide methods to access it.

They encapsulate acquisition and handling of a piece of context information,  but additional abstractions are needed:


Interpretation refers to the process of raising the level of abstraction of a piece of context. Interpreters typically take information from one or more context sources and produces a new piece of context information.


Aggregation refers to collecting multiple pieces of context information that are logically related into a common repository. The need for aggregation comes from the distributed nature of the context information. The application is relived


Components that execute actions on behalf of the applications. For example send an email or a message, or switch on or off a light.


They are responsible for maintaining a registry of what capabilities exist in the framework. This includes knowing what widgets, interpreters, aggregators and services are currently available for use by applications, and which services they provide.