Illustrated with various prototypes in the previous sections the feasibility of realising bottom-up context-awareness is demonstrated. Each of the prototypes made one specific artefact context-aware; however each of the artefacts also reflects a type of entity. To learn and communicate from the experience of building the prototypes it is desirable to describe the result as well as the process by which that was achieved. To reuse the knowledge and also potentially parts of an implementation an efficient way to communicate details of contexts and awareness about entities, as well as about the process has to be found. This is in particular relevant within the research community to make it easier to build on one another’s work. As Ubiquitous Computing and in particular context-awareness is a multi-disciplinary field the communication also has to bridge gaps between subjects.
The aim when describing context aware systems is on one hand to precisely layout the way contexts are established for a particular entity and on the other hand to formulate
it as general as possible, so that transfer and reused for similar entities is easy. A formal way of describing it could be very powerful, however completely formalising the description seems to be not practical with the current understanding of context and awareness.
When describing context and awareness in an entity centred style, further different issues have to be included, such as
• How does the entity, and thus contexts of this entity, related to other entities? • What are major side conditions and requirements stated by the way the entity
is deployed?
• Whether and how the contexts described for the entity are restricted to a wider scenario of use?
• How do contexts relate to each other?
The quest for a way of describing context brings to mind a statement by C. Alexander [Alexander,79,p.67] where the use of patterns is motivated:
“If I consider my life honestly, I see that it is governed by a certain very small number of patterns of events which I take part in over and over again.
Being in bed, having a shower, having breakfast in the kitchen, sitting in my study writing, walking in the garden, […] There are surprisingly few of these patterns of events in any one person’s way of life, perhaps no more than a dozen. […] Of course, the standard patterns of events vary very much from person to person, and from culture to culture.” [Alexander,79,p.67]
Similarly it appears that the number of contexts that are relevant for a single entity is quite small; however, by combining entities in temporal and spatial ways, complex scenarios are generated. Entities and contexts related to these entities seem to be a logical extension of the patterns describing types of places in [Alexander,77], but on a smaller scale. Before describing a pattern language for context the next subsection is meant to recall the origin of pattern languages.
4.5.1 Pattern Languages
In the books “the timeless way of building” [Alexander,79] and “a pattern language” [Alexander,77] Alexander founds a language to describe buildings and architecture on a greater scale by viewing it more from a social perspective than from a constructional. The 253 patterns that are described provide a basic ‘vocabulary’ to express buildings.
“The people can shape buildings for themselves and have done it for centuries, by using languages which I call pattern languages. A pattern language gives each person who uses it the power to create an infinite variety of new and unique buildings, just as his ordinary language gives him the power to create an infinite variety of sentences.” [Alexander,79,p167].
This statement also suggests that the language is already there and that by writing down the pattern language it was discovered rather than created.
Central to the pattern language is that it includes a hierarchy and also that patterns are not to be seen in isolation. The relationships between patterns are an inherent part of the language. It is also apparent that already a subset of patterns forms a language of its own.
These properties and the fact that a pattern language can be constructed using plain language so that it can easily understood without specific knowledge on a notation made it appealing for other research areas, too. It was in particular adapted to the problem of software reuse in the field of software engineering, as given in [Gamma,95]. Recently also researchers in HCI proposed the use of patterns to communicate design solutions [Borchers,01].
Understanding the use of technology in relation to context, especially in a home environment, is researched by a team at the University of Nottingham within Equator [EQUATOR,02]. Here ethnographic studies have been carried out to find typical patterns of usage, of technologies in home environments [Crabtree,01]. To communicate their findings they extended the pattern language described by Alexander with the inclusion of technologies into material arrangements [Crabtree,01a].
4.5.2 A Pattern Language to Describe Contexts and Awareness
The very basic observation by Alexander, from an architect’s viewpoint, is that life is organised around space and takes place in repeating patterns of events, as pointed out in the statement “… these patterns of events which repeat themselves are always
anchored in space” [Alexander,79,p.69]. When taking this further into the domain of
context-aware systems the notion of space and place can be extended so that any entity can be an anchor, considering contexts as, or patterns of, events.
In our research so far we have identified a number of entities and their contexts; however we are far from a comprehensive vocabulary. However even starting out with these few ‘words’ that we have identified so far, can help to form understanding of context and context-awareness. Recognising that only a small number of aspects are addressed, there is no specific order or hierarchy to the patterns.
The pattern language proposed in this section is, like most languages, not static, and as new entities, new contexts, new methods, or new approaches arise additional concepts may be added to the language.
Each pattern has two major logical parts. In the first one the entity and the related contexts are described, it is also placed within a scenario, and relations to other entities, which are similar, are described. In the second part a particular solution of how this particular entity was made context-aware, is described.
Each pattern has a name and a number. As already pointed out in [Alexander,77], the names of the patterns are important because they create the vocabulary which is used to reference the concept described using a pattern. So far numbers are chosen sequentially with developing context-aware artefacts, rather than providing a hierarchical structure.
Then the entity is described. As explained earlier the entity may by a subject, an artefact, or a part of either one. The entity should be as specific as necessary but as general as possible. The entity is often strongly related to the name of the pattern. The entity is followed by a scenario explaining more about the entity, together with
Derived from the scenarios a list of contexts of interest is stated. Here contexts that are particular to an entity are described. Contexts can incorporate what an entity does or what it is used for, the relation to its environment as well as intrinsic properties. Potentially this list can be infinite, however selecting context should be orientated on ‘what is normal’ and leave the ‘odd cases’ out. The contexts that are perceived with the implementation, described later, will be repeated there.
If applicable, it should then be stated to who the contexts are of interest, when this is possible to say. This may be a particular device, the entity itself, or in most cases this is open and not further specified.
Forces are the major constraints to an entity, as described in the previous chapter. In
particular there should be explanations of what important side conditions are for this entity, such as robustness, weight, battery life, and unobtrusiveness.
Then sensing technologies which are used to acquire contexts are described. Here in particular is should be stated which sensing approach (local, distributed, homogenous, or heterogeneous), which sensing perspective (intrinsic, observed), and which physical sensors are selected. When using contexts of other entities as sensors these should be included here as well. Often it is argued that the more sensors and the more diverse they are the better perception is supported [Laerhoven,02], however here the value of the description is to point out what the important sensors are.
Then perception techniques which are deployed to get the contexts are specified (e.g. rules, statistics, and Neural Nets). Here in particular the learning behaviour of the systems is described (fixed, learning phase, adaptive) and motivated.
Also the device architecture, in particular how sensing, perception, and processing is arranged is described. Here in particular the question of how much processing power and storage is available (e.g. processor, ram) and where the processing takes place (e.g. local, in the backend) is discussed. Here the motivation for the selected device architecture should be provided.
Dependent on the device architecture and also on the partners that use context the
such as wireless (e.g. radio and infra-red) or wired, are described and the motivation behind the decision stated. In certain cases there may be no communication.
As an important part, an implementation example is given, providing more details on realisation issues. This may be accompanied by a photo, schematics, code or similar material or may contain references to these materials.
Finally references to other patterns that are related should be stated. Here the references should be ordered in three categories: first patterns where entities are described that are used as a sensor in the current patterns (lower level patters), second patterns that are similar to the current pattern (same level), and third patterns that are using the current pattern as a sensor (higher level patterns).