Context is a decision about what to sense, not a fact waiting to be discovered

Context-aware computing rests on a definition written to fit everything. Context is any information that can be used to characterise the situation of an entity. An entity is a person, place or object relevant to the interaction (Dey, 2001). That breadth is why the definition is useful, and why this second of ten units treats it as a problem, the decision the first unit's proactivity left open. A designer who asks it what to sense gets no answer. The answer turns on a claim about what matters in a situation, and the definition cannot supply that claim. The field later found the same gap from the other side. Context is produced by the people in a situation, and some of it cannot be sensed at all (Dourish, 2004; Bellotti and Edwards, 2001).

Every context-aware product therefore carries a relevance argument, written down or not.

The definition was built to be broad, and breadth was the point

Schilit, Adams and Want (1994) described systems that examine and react to a person's changing context. They set out four categories of application and prototyped instances on the PARCTAB palm-sized computer. They argued that a limited amount of information about a person's proximate environment matters most. Their durable move is a distinction: some context is active, supplied by the user, and some is passive, sensed by the system. Part of what made a situation relevant was therefore treated as stated by a person rather than measured by a device.

Dey (2001) supplied the definition that stuck. He unpacked it into questions of identity, activity, location, time and reason, and argued that its breadth lets it apply without domain-specific assumptions. Abowd and colleagues (1999) tightened the same account into where, who, what and when. They argued that context-aware computing is best judged by the interaction it enables rather than by the sensors it uses. The chosen definition therefore cannot rank candidate signals, because any usable information qualifies.

The alternative was to fix the signals by hand, and one paper shows the shape of that choice. Schmidt, Beigl and Gellersen (1999) fitted a light sensor to a Palm Pilot to drive the backlight. They fitted two mercury switches to a Newton MessagePad so the interface rotated with the device. They then wrote down a feature space for context, split into human factors and physical environment. They also wrote a layered model in which sensors feed cues and cues feed contexts. The prototypes answer the definition's open question, which conditions to sense, by choice rather than derivation. They are demonstrators rather than products, so they show the choice being made, not that it was right.

A definition that admits any information cannot choose a sensor

Dey's own toolkit paper states the consequence. Dey, Abowd and Salber (2001) name three problems: context was ill defined, design models were lacking, and no tools existed to jump-start development. Their answer is architectural. The Context Toolkit separates acquiring context from reacting to it, so an application asks for a kind of context rather than a particular device. The same paper bounds the effort's scope to context that can be inferred from sensors in a physical environment (Dey et al., 2001).

Baldauf, Dustdar and Rosenberg (2007) turned the practice into a general model. They derived a layered framework covering acquisition, modelling, reasoning and distribution, and used it to compare middleware. Their account shows context assembled by a machine: what context is becomes what each layer of the stack passes upward. The commercial framing pressed the other way. Brown, Bovey and Chen (1997) observed that context-aware applications had been crafted by research experts. They argued that building one should become as easy as building a web page. A developer then infers context rather than configuring it by hand. A general abstraction cannot know what a particular product should treat as relevant, so reuse and relevance pull against each other. The toolkit settles the tension with a default, and the default is the argument.

The field built systems the definition could not deliver

Cheverst and colleagues (2000) built and evaluated GUIDE, a handheld tourist guide for Lancaster. It tailored information to personal and environmental context after requirements capture with tourism experts. The personal context a guide can hold is a model of a visitor's interests. The environmental context is a model of place. Neither is the situation that produced the behaviour observed, and the visitor who reads in a second language is a relevance term the guide cannot sense. Chen and Kotz (2000) surveyed a decade of context-aware mobile computing research. They reported that such applications, or the infrastructure to support them, had never been widely available to everyday users.

The critique: context is produced in the moment

Dourish (2004) argued that the representational stance implied by conventional interpretations of context misinterprets the role context plays in everyday human activity. On this reading context is not a stable set of features captured before an interaction starts. It is something the participants produce as it proceeds, so a system that models it in advance models its own assumptions about what will matter.

Bellotti and Edwards (2001) reached a compatible position from design. They argued that there are human aspects of context that cannot be sensed or even inferred by technological means. Such systems therefore cannot be designed simply to act on our behalf, and will have to defer to users. Their warning is sharpest for systems whose applications are isolated from the sensing and inferencing that governs their behaviour. That is exactly the separation the toolkit was built to provide. They propose four design principles for intelligibility and accountability. The relevance argument contains terms the system cannot observe. A design that never defers has therefore replaced the person's reading of the situation with the system's.

The contested question: is context information or interaction?

Three positions are held. The first treats context as information a system represents. Dey (2001), Abowd and colleagues (1999), Dey and colleagues (2001) and Baldauf and colleagues (2007) work inside it. They cite the reuse of architectures and the applications a toolkit made quick to build. Success is coverage and reuse.

The second treats context as interactional. Dourish (2004) holds that the representational stance misreads everyday activity, and Bellotti and Edwards (2001) hold that some relevant context cannot be inferred at all. The design must therefore let the person correct it. Success is whether a person can explain the system's behaviour and contest it.

The third position is that both accounts are secondary to deployment. Chen and Kotz (2000) reported that the infrastructure never reached everyday users. Meegahapola and colleagues (2024) locate a reason in distribution shift, where the training distribution differs from the deployment environment. On this reading even a defensible choice of features may not survive a new population or device.

The evidence that would settle the dispute is a comparison. It holds the sensed features fixed and varies only the handling of the parts a system cannot infer. Suppose the interactional position is right. Then systems that defer should do better on intelligibility and on the outcome. The difference should be largest where the person knows more than the sensors do. That evidence is thin because deployment never arrived (Chen and Kotz, 2000). The strongest counter-evidence is Meegahapola and colleagues (2024), who treat the difficulty as a representation problem better methods can partly solve. Across 14 source-target domain pairs in two multimodal datasets, their unsupervised adaptation method raised classification performance. The gain was up to 12 per cent in area under the curve. It cut regression error by up to 0.13 mean absolute error against direct deployment. A study reporting both an adaptation gain and a deferral gain on the same task would separate the accounts; none here does.

Rated by kind, the representational side rests on architecture and reuse reports rather than on controlled comparison. The interactional side rests on conceptual argument (Dourish, 2004) and on the design reasoning of Bellotti and Edwards (2001). The deployment side rests on one survey (Chen and Kotz, 2000) and on Meegahapola and colleagues' (2024) adaptation results, which measure classification rather than deferral. While the dispute is open, a designer records which parts of a situation the system infers and which it asks the person to confirm. The strongest objection is that the relevance argument may be unreadable in advance, since Dourish (2004) holds that participants produce context as the interaction proceeds.

Where this is heading

Zhang and colleagues (2025) collected smartphone behaviour and environmental data. They abstracted the signals into 16 contextual scenarios. They used prompts built from them to make a conversational assistant more relevant to the user's state. Meegahapola and colleagues (2024) worked the other half, making a model transfer to populations and devices it was not trained on. Against both, Chen and Kotz's (2000) test is unchanged: whether the infrastructure becomes something everyday users actually have. It also raises the value of the intelligibility requirement Bellotti and Edwards (2001) stated twenty-five years ago.

Sources

• Schilit, B., Adams, N. and Want, R. (1994). Context-Aware Computing Applications. 1994 First Workshop on Mobile Computing Systems and Applications. doi:10.1109/wmcsa.1994.16 Described four categories of context-aware application and prototyped instances on the PARCTAB. It originates the active and passive context distinction, so what makes a situation relevant was partly user-supplied from the start.
• Dey, A. K. (2001). Understanding and Using Context. Personal and Ubiquitous Computing. doi:10.1007/s007790170019 Defined context operationally as any information that can characterise the situation of an entity and unpacked it into identity, activity, location, time and reason, arguing the breadth allows use without domain-specific assumptions. That breadth is also what stops the definition saying what a system should sense.
• Abowd, G., Dey, A., Brown, P., Davies, N., Smith, M. T. and Steggles, P. (1999). Towards a Better Understanding of Context and Context-Awareness. HUC. doi:10.1007/3-540-48157-5_29 Sorted context into where, who, what and when, argued it is best judged by the interaction it enables rather than by its sensors, and noted the difficulty of drawing a boundary around context. It locates the criterion of success while leaving the choice of signals open.
• Dey, A., Abowd, G. and Salber, D. (2001). A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications. Human-Computer Interaction. doi:10.1207/s15327051hci16234_02 Named three problems, that context was ill defined, that design models were lacking and that no tools existed, then supplied a framework and the Context Toolkit separating acquisition from reaction. Its own scope is bounded to context inferable from sensors in a physical environment, a decision about what to sense taken as an engineering note.
• Brown, P., Bovey, J. and Chen, X. (1997). Context-aware applications: from the laboratory to the marketplace. IEEE Personal Communications. doi:10.1109/98.626984 Observed that context-aware applications had been crafted by research experts and argued that building one should become as easy as building a web page, requiring context to be inferred rather than configured by hand. A reusable abstraction is a default relevance argument that no abstraction can justify for a particular product.
• Cheverst, K., Davies, N., Mitchell, K., Friday, A. and Efstratiou, C. (2000). Developing a context-aware electronic tourist guide: some issues and experiences. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. doi:10.1145/332040.332047 Built and evaluated GUIDE, a handheld tourist guide that tailored information to personal and environmental context, and reported the quality of the visitor's experience. Its value is the gap between the visitor the system modelled and the behaviour the trial observed.
• Bellotti, V. and Edwards, K. J. (2001). Intelligibility and Accountability: Human Considerations in Context-Aware Systems. Human-Computer Interaction. doi:10.1207/s15327051hci16234_05 Argued that there are human aspects of context that cannot be sensed or even inferred by technological means, so such systems cannot simply act on the user's behalf and must defer to them. It is the strongest statement that the relevance argument contains terms a system cannot observe.
• Dourish, P. (2004). What we talk about when we talk about context. Personal and Ubiquitous Computing. doi:10.1007/s00779-003-0253-8 Argued that the representational stance implied by conventional interpretations of context misinterprets the role context plays in everyday activity, and offered an alternative model for design. It supplies the interactional position, in which context is produced by participants rather than captured in advance.
• Chen, G. and Kotz, D. (2000). A Survey of Context-Aware Mobile Computing Research. Computer Science Technical Report TR2000-381, Dartmouth College. https://digitalcommons.dartmouth.edu/cs_tr/177/ Surveyed context-aware mobile computing research and reported that such applications, or the infrastructure to support them, had never been widely available to everyday users. It supplies the deployment test against which the relevance debate should be judged.
• Baldauf, M., Dustdar, S. and Rosenberg, F. (2007). A survey on context-aware systems. International Journal of Ad Hoc and Ubiquitous Computing. doi:10.1504/ijahuc.2007.014070 Derived a layered framework for context-aware architectures covering acquisition, modelling, reasoning and distribution, and used it to compare middleware and frameworks. It shows context assembled by a machine, the passage between layers treated as the architecture rather than a design choice.
• Meegahapola, L., Hassoune, H. and Gatica-Perez, D. (2024). M3BAT: Unsupervised Domain Adaptation for Multimodal Mobile Sensing with Multi-Branch Adversarial Training. Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies. doi:10.1145/3659591 Addressed distribution shift in multimodal mobile sensing with unsupervised domain adaptation across 14 source-target domain pairs, reporting gains of up to 12 per cent in area under the curve and 0.13 mean absolute error over direct deployment. It is the strongest evidence that transfer is a technical problem better methods can reduce, the counter-argument to the interactional position.
• Zhang, Z., Gao, N., Nie, Z., Pal, S. and Zhang, H. (2025). Context-Aware Intelligent Chatbot Framework Leveraging Mobile Sensing. Companion of the 2025 ACM International Joint Conference on Pervasive and Ubiquitous Computing. doi:10.1145/3714394.3756342 Collected smartphone behaviour and environmental data, abstracted the signals into 16 contextual scenarios and translated them into prompts for a conversational assistant. It shows the relevance decision reappearing inside a model prompt, made in advance and hard to inspect.
• Schmidt, A., Beigl, M. and Gellersen, H. (1999). There is more to context than location. Computers and Graphics. doi:10.1016/s0097-8493(99)00120-x Built a light-sensing Palm Pilot backlight and an orientation-sensing Newton MessagePad, then set out a layered model in which sensors feed cues and cues feed contexts. The features to sense were chosen by hand.