Context Information

Let us consider more precisely what context functions will be needed in the framework to support the authoring and triggering of stick-e notes. Capturing context will involve communicating with external sensor devices (be they hardware or software) in order to establish the current values of different context elements. For example, the framework

#141] [Herring 1996 - #59]) receiver attached to a handheld computer to obtain the current location of the user. Of course, a user may supply the value of a context element manually (e.g. “I am at the library”) but generally it is automatically captured context data that is of most value. Either way, the captured context element values need to be modelled in some form of structure within the framework, such as a latitude and longitude data structure to hold the location data generated from a GPS receiver. There may also be a need for higher level structuring of this data such as representing points, rectangles and polygons in the case of a location context element, and different formats in which it may occur, e.g. latitude and longitude, ordnance survey grid reference (within the U.K.), post codes, etc. To facilitate the matching of stick-e notes with the current context, mechanisms should be provided to compare, convert and manipulate these structures. Considering location data, we may want to check if two points match, to check whether a point is within a rectangle, to convert from latitude and longitude to ordnance survey grid reference units, to calculate the distance between two points, to move a point west by 100 metres, etc. Although we have only used the location context element as an example, the same general facilities described are required for all types of context element to enable the attaching and matching of stick-e notes with the current context.

There are potentially hundreds of useful context elements ranging from physical conditions, such as a temperature reading, to more conceptual conditions, such as the mood of the user. It is clearly beyond the scope of this research to develop support for all conceivable context elements, instead we concentrate on a few of the most useful ones: location, with, and time. This allows stick-e notes to be attached to places, people (or

other objects such as equipment), and times of day respectively. Although we concentrate on

these context elements it is our aim is to develop a generic framework that will support the addition of many other types of context element at a later date. That is, we are more

interested in designing the general representation scheme in which different context elements reside rather than developing the individual esoteric context elements themselves.

Chapter 2: Stick-e Notes - a Metaphor for Context-Aware Applications Point Rectangle Location Context Element With …

Figure 2. Simplified context class hierarchy.

We have considered context from an object oriented perspective and have formulated a class hierarchy headed by a generic context element class from which various types of more specific context element are derived, as is shown in simplified form in Figure 2. The top-level ContextElement class is essentially just a grouping class under which all

the different types of context element reside. The second-level classes represent a particular type of context element, such as a location, and define the common interface that all the more specialised derived classes have to implement. Derived from these classes there may be several layers of specialisation of context element before reaching an instanciable class (the hierarchy maybe arbitrarily deep), but for the sake of simplicity we have derived the instanciable classes of Point and Rectangle directly from the Location class.

We can view the hierarchy as having four types of classes:

Base Class: acts as an ‘umbrella’ class from which all context elements are derived. Type Classes: define the interface for particular types of context element.

Specialisation Classes: define more esoteric versions of a general type.

Instanciable Classes: the classes that can be instantiated and used to model the value of a context element. Note that in many cases there will probably be some blurring of the boundaries between specialisation and instanciable classes.

This hierarchy of different classes facilitates the incremental development of context support, where new types of context element and new implementations of existing types may be added by the application developer as and when needed. For the moment

hierarchical structure also makes it possible to deal with context elements at various levels of abstraction. For example, an underlying location polygon could be presented and manipulated directly as a location polygon class, or in the more abstract form of a general location class, or even in the completely generic form of the context element base class. This allows the framework and clients to work at high levels of abstraction and hence be able to seamlessly accommodate future additions to the context hierarchy that are added beneath their operating level of abstraction. Extensibility is desirable in many applications but absolutely critical in a context-aware framework because it is simply an impossible task to even conceive of all the different types of context element that may be useful let alone to provide support for them all.

In our framework we have separated the facilities for structuring, working with, and generally representing context information from those facilities responsible for the automated capture of context through communication with external hardware or software sensor devices. The aim of this separation is to disconnect context data from specific sensors, allowing for a more general-purpose context representation that can more readily support the addition of new sensor devices.

Similarly to the context elements, there is a plethora of sensor devices (in the form of both software and hardware) that can supply data about the current context. These sensors can be grouped into categories in much the same way as the context element hierarchy, i.e. by the type of context element data that they supply. This results in a sensor class hierarchy that somewhat mirrors the context element hierarchy.

Note that sensor classes should not be mistaken for the physical sensor devices themselves. They are merely pieces of software that provide a standard communication medium for obtaining the context element data provided by a particular type of sensor device. In fact, it is quite possible that we could have more than one sensor class representing the same physical sensor device if it can provide multiple types of data, e.g. a GPS receiver that supplies location, orientation and time context elements. In such a case the physical sensor device will be represented logically within the sensor hierarchy as three separate sensor classes, one for extracting location information, one for extracting orientation information, and one for extracting temporal information.

Chapter 2: Stick-e Notes - a Metaphor for Context-Aware Applications GPS Sensor A-Badge Sensor Location Sensor Sensor With Sensor …

Figure 3. Simplified sensor device class hierarchy.

The construction of the sensor hierarchy is illustrated in Figure 3. As with the context hierarchy, there are four different types of class:

Base Class: acts as an ‘umbrella’ class from which all sensor devices are derived and records the general state of the sensor device (if it has been checked, if it is not working, etc.).

Type Classes: define the sensor interface for sensor devices that provide a particular type of context element. For example, a location sensor class could define a GetLocation() method that all derived location sensor classes would

subsequently have to implement.

Specialisation Classes: define more esoteric versions of a general type of sensor, i.e. they may provide additional interface methods specific to that class of sensor device.

Instanciable Classes: the classes that can be instantiated and used to extract data from a particular sensor device. As with the context hierarchy, in many cases there may be a blurring of the boundaries between specialisation and instanciable classes. Organising sensor devices by the type of context element they supply makes for a flexible hierarchy that can readily accommodate new sensors beneath a standard interface. The standard interface for each context element sensor, specified in the type and specialisation classes, allows sensors to be accessed in a generic fashion so that no extra programming effort is required to incorporate a new sensor device into a client program. For example, the location sensor class may define a GetLocation() method

return a location context element that may be a reference to any class of location objects. That is, the returned location may be in any of the possible forms, such as a

Point or Rectangle, whichever is most appropriate for that particular sensor device.

The clients of the framework will often not be interested in communicating with specific sensors, they will simply want to retrieve the current value of a particular context element. For example, a client may enquire as to what their current location is; from the client’s perspective the type of sensor device used to retrieve that location is immaterial. That is, clients often want to work at the level of acquiring the current value of a context element rather than at the level of finding, instantiating, and communicating with sensor devices.

In order to achieve this level of generality we created a SeEnvironment object that

provides access to the current value of context elements such as location, and which utilises all the available sensor devices to provide the best data transparently to the client. It is a centralised framework resource that any client may access through generic context element accessor methods, e.g. GetLocation(), GetWith(), GetTime(), etc.

The client is also able to specify the specific type of context element that the returned value should be compatible with if need be.

In addition to accessing context elements automatically captured from sensors, the

SeEnvironment object also manages pretend contexts that allow the user to simulate the

value of a context element, e.g. to pretend to be in a particular location. This is useful not only for supplying values of context elements that cannot be easily automatically obtained (e.g. capturing the user’s emotional state) but also in enabling the user to preview or review stick-e notes that will trigger in a specified context by pretending to be there now. There are differences in representing pretend contexts as opposed to real ones due to the fact that they need not necessarily obey the same laws of physics. In the case of location context elements there is no reason why a user could not pretend to be in two or more discrete places at once, indeed, this ability can be most useful. For example, pretending to stand outside of the fish and chip shop in Trewoon and the Cornish pasty shop in Truro in order to peruse and compare the information presented by an electronic culinary guide of Cornwall.

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