Dey’s doctoral dissertation provides a set of requirements for a context-aware framework, and discusses an implementation of such a framework: the Context Toolkit. (Sorry, didn’t read all of it)

Major contributions (from dissertation):

  • identification of a novel design process for building context-aware applications;
  • identification of requirements to support the building and evolution of context-aware applications,
    resulting in a conceptual framework that both “lowers the floor” (i.e. makes it easier for designers
    to build applications) and “raises the ceiling” (i.e. increases the ability of designers to build more
    sophisticated applications) in terms of providing this support;
  • two programming abstractions to facilitate the design of context-aware applications: the context
    component abstraction (including widgets, aggregators, interpreters and services) and the situation
    abstraction;
  • building of a variety of applications that cover a large portion of the design space for context-
    aware computing; and,
  • building of the Context Toolkit that supports the above requirements, design process and
    programming abstractions, allowing us and others to use it as a research testbed to investigate new
    problems in context-aware computing such as the situation programming abstraction and dealing
    with ambiguous context and controlling access to context.

Three general problems were identified for context-aware computing:

  1. lack of variety of sensors for a given context type
  2. lack of variety of context types
  3. inability to evolve applications

Design Process, adapted from (Abowd, Dey et al, 1998):

  • Specification: Specify the problem being addressed and a high-level solution.
  • Specify the context-aware behaviors to implement.
  • Determine what collection of context is required for these behaviors to be executed, using any context-acquisition mechanisms that already exist.
  • Acquisition: Determine what new hardware or sensors is needed to provide that context.
    • Install the sensor on the platform it requires.
    • Understand exactly what kind of data the sensor provides.
    • If no (API) is available, write software that speaks the protocol used by the sensor protocol used by the sensor.
    • If there is an API, learn to use the API to communicate with the sensor.
    • Determine how to query the sensor and how to be notified when changes occur.
    • Store the context.
    • Interpret the context, if applicable.
  • Delivery: Provide methods to support the delivery of context to one or more, possibly remote, applications.
  • Reception: Acquire and work with the context.
    • Determine where the relevant sensors are and how to communicate with each
    • Request and receive the context.
    • Analyze the information to determine usefulness.
  • Action: If context is useful, perform context-aware behavior.
    • Analyze the context treating it as an independent variable or by combining it with other information collected in the past or present.
    • Choose context-aware behavior to perform.

Features required by developers:

  • context specification
  • separation of concerns and context handling
  • context interpretation
  • transparent distributed communications
  • constant availability of context acquisition
  • context storage
  • resource discovery

existing context architectures summary
Components of the Context Toolkit:

Context Toolkit Components

Typical Interaction

context widget

example context aggregator

Dey provides two main approaches at increasing the amount of information that can be transferred from humans to computers:

  1. improving the language used to represent knowledge to computers
  2. increasing the amount of situational information that computers can sense

Improving the language requires humans to continue to explicitly provide information to the computer, whereas increasing the amount of situational information enables computers to enrich the explicit knowledge with relevant implicit knowledge. Both methods are complementary and useful (necessary?) in creating a shared understanding, or what (Clark, Brennan, 1991) calls “grounding”. Context-aware computing frees users from having to increase the level of input to computers; this is also helpful because humans are not very good at deciding what parts of the environment is relevant and worth expressing. Having computers automatically sense and encode environmental information also enables the possibility of calm computing (Weiser and Brown, 1997). Contextual awareness is even more important in mobile and ubiquitous computing environments because information needs vary and change as users move across and even between different environments.

Dey’s definition of “context”:

Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an applicaiton, including the user and application themselves.

Several types of contexts are identified to be of the most importance: location, identity, time, and activity. Because they can be used to “characterize the situation of a particular entity”, on top of answering questions of who, what, when, and where.

Next he defined “context-aware”:

A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task.


At the time of the dissertation, two taxonomies exist: (Schilit, Adams, et al, 1994) identifies classes of context-aware applications, while (Pascoe 1998) identifies core features of context-awareness. Schilit identifies two main classes of context-aware applications: proximate selection and automatic contextual reconfiguration.

Proximate selection basically emphasizes that selections that are most likely relevant to the user so that she can more easily find and perform the desired action.

Automatic contextual reconfiguration are applications that automatically retrieve information for the user, and there are 2 subclasses:

  1. contextual command – services that are made available depending on the current context, but must be executed by the user manually
  2. context-triggered actions – services that are executed automatically based on the current context

Pascoe identifies the following features of a context-aware system:

  1. contextual sensing – augment the user’s sensory system by detecting contextual information and presenting it to the user. This is similar to proximate selection.
  2. contextual adaptation – execute or modify a server automatically based on the current context. This is similar to context-triggered actions
  3. contextual resource discovery – “locate and exploit resources and services that are relevant to the user’s context”. This is similar to automatic contextual reconfiguration.
  4. contextual augmentation – “ability to associate digital data with the user’s context”. The example provided is leaving digital messages with specific objects or locations for other users (I think this is called “urban markup”). This is not addressed by (Schilit, Adams et al)

Combining the two taxonomies, Dey proposes his own:

  1. presentation of information and services to a user
  2. automatic execution of a service
  3. tagging of context to information for later retrieval

Advertisements