Issues in Representing Context Information

Having captured the context information there are a number of factors to consider in representing it. With many sources of context there is a degree of error involved, such as the potential +/-100 metre inaccuracy in uncorrected GPS location data (prior to the removal of “selective availability” in 2000; the error is now much improved at +/- 10 metres, but mobile phone system positioning technology is still only accurate to approximately +/-100 metres). In our prototype framework we have provided a simple penumbra model that defines the area around a captured value in which the actual value may lie. However, depending on the application and level of inaccuracy awareness needed, more complex models of error may be required. Taking this to the extreme, the current value for a context element may be described in terms of a probability graph where there is a whole continuous range of likely and not so likely current values. In addition to considering the error of the context element, a way of representing it needs to be chosen, too. For example, with location we need to decide if it is a name/cell based system or a co-ordinate based system, and if its the latter then the number of dimensions (x, y or x, y, z), the shape (point, rectangle, polygon, cube, mass, etc.), the units of measurement (latitude and longitude, metres, etc.), etc. In the framework we experimented with using latitude and longitude as a universal form of

Chapter 2: Stick-e Notes - a Metaphor for Context-Aware Applications

measurement, a common denominator of location types. However, this was not terribly successful as it ignores the fact that different types of location are suited to different situations. For example, a latitude, longitude, and altitude may well accurately define the location of my office but this information is practically useless for most purposes as there is no convenient method of finding out one’s location within a building in such a form. An active badge cell-based system would be much more appropriate in such circumstances. However, for specifying the location of a giraffe in the middle of an African wilderness expanse a latitude and longitude measure would clearly be more useful, allowing us to locate the giraffe with a GPS receiver. Another aspect to this problem is that some location systems may be relative to a particular object rather than to a fixed point of origin on the planet. For example, if an active badge system were to be deployed on a cruise ship there would be no static mapping possible between the location cells and the latitude and longitude co-ordinates. Indeed, for most internal cruise ship applications there probably would not be the need for such a mapping as they would most likely require a ship-relative form of location system. Therefore, rather than trying to enforce a universal location format we believe it is better to use the one that is best for the task at hand and provide support for converting between different formats as and when necessary. This “convert-on-demand” approach can also be applied to the subtle differences in data formats, e.g. converting between the different datums or precisions of a location.

Leonhardt et al’s location service [Leonhardt, Magee 1996 - #81] [Leonhardt and Magee 1996 - #80] attempts to integrate all forms of location through a series of cell- spaces. However, although co-ordinate data such as latitude and longitude from a GPS receiver can be integrated in his model, it does so by transforming an inherently unstable form of location (i.e. precise latitude and longitude measurements of moving objects) into an inherently stable cell-space model, resulting in a high processing overhead in updating/reconfiguring the cell space. It faces the flip side of the problem that we encountered in trying to establish a common-denominator location system using latitude and longitude (although there are more goals that Leonhardt’s location service is trying to achieve than simply providing a universal location format).

Location is a particularly complex context element to represent, with many different forms and units of measurement. However, at least some of the issues faced with

location data formats are likely to be encountered in developing support for other context elements as well.

The issues in representing context that we have considered thus far are low-level ones concerned with the extraction and representation of individual values. Yet more issues are raised when considering higher-level modelling of composite forms of context. For example, the trigger condition of a stick-e note may consist of a number of different context elements. It contains a separate trigger context for each general context element type, with the individual context elements of each list ORed together and the resulting Boolean values for the general context element types ANDed together (except for trigger contexts with no context elements, which are simply discarded). Refer back to Figure 4 for a visual representation of an example trigger condition. Location context elements are particularly suited to this form of logical representation as the relationship between location context elements to which a note is attached must inherently be OR. It is pointless to have a trigger condition that specifies a location trigger context as two different places simultaneously – the stick-e note will simply never trigger as the current location of the user can obviously not be more than one value at a time. It is possible to have such scenarios when using pretend context elements where, as discussed earlier, the normal laws of physics need not apply. However, the ‘impossible contexts’ that pretend context elements present are only used in simulations of current context and are not permitted in the trigger condition of a stick-e note. That is, any combination of contexts can be used as the current pretend context, but the stick-e note must be attached to a real physically possible context. Another possibility for the same-place-at- once scenario could be if we consider the possibility of a composite object whose components can be dispersed. We sacrifice support for attaching stick-e notes to impossible contexts and for modelling composite current context (both of which we do not expect to be widely required in the majority of context-aware applications) in return for a simpler model.

With context elements have different semantics than that of location context elements.

Most notably, it is possible to have two context elements match the current context at the same time. For example, to be with Helena and with Geraldina and with Vince. Therefore modelling the With trigger contexts as a simple OR relationship between context elements is not satisfactory as we may also want to represent an AND

Chapter 2: Stick-e Notes - a Metaphor for Context-Aware Applications

relationship between these context elements. One solution is to extend the context hierarchy to include a With-Group context element, but this would really be only a work- around solution for an inadequate method of expressing the logical relationships. In addition to the AND operator, a NOT operator may also be useful. For example, a

With trigger context that defines: with Vince AND with Helena AND NOT with

Geraldina.

In summary, the trigger condition model works well for the simple location-based sample applications we have developed but it does limit the flexibility of the context that a stick-e note can be attached to. There is a trade-off between providing a simple model that is easily understood and a more sophisticated one that can represent more complex contexts but at the cost of being less immediately understandable. The current model places the emphasis on ease of understandability, which it does this very well: there is little or no ambiguity in what the context specification can mean. However, it does limit the complexity of contexts that can be expressed and is probably too simplistic for many applications. For example, it cannot represent “with Peter in his office or with David in his office”, as a single context. However, providing a full Boolean context logic that can permit any logical combination of context elements will probably be an off-putting interface for the novice user. Perhaps the best way to address this problem in future work would be to provide two independent methods of specifying the context of a stick-e note, the current simple list arrangement by default or, for more sophisticated applications/users, the ability to specify the context in terms of a full Boolean logic.