Research issues in context-aware retrieval: the weather

Peter Brown

Department of Computer Science, University of Exeter, Exeter EX4 4QF, UK
P.J.Brown@ex.ac.uk

ABSTRACT

Context-aware information retrieval often relates to mobile outdoor users. In such applications the weather is a potentially important field, or set of fields, in the user's current context, since a user's decision making is often based on the weather, and the information provided should reflect the sort of decisions he is likely to make. This note explores how weather fields may be set and used.

Introduction

Context-aware applications involve the supply of information -- either proactively or interactively -- according to the user's current context. Usually the user is mobile. The current context is normally set automatically using sensors such as GPS, or (perhaps periodic) connections to outside servers that supply contextual fields such as traffic state or, the subject of this note, weather information. Furthermore the current context may also have fields set directly by the user, such as their preferences and interests, together with fields that are synthesised by "intelligent" sensors, such as a sensor that tries to deduce whether a user is busy.

The fact that the user is normally mobile has a profound effect on context-aware applications. This is for two reasons: firstly the user is likely to have a hand-held device with a limited screen; secondly the user is quite likely to be busy on another task, and using the hand-held device is an interruption to that. The conclusion from this is that, when information is delivered to the user, every effort must be made to ensure it is relevant and therefore potentially useful.

If an application is supplying information according to the user's current context, then in many cases the weather is a potentially valuable field of the current context: it affects the information the user needs, and indeed their decision-making. For example we have been working with a database of attractions supplied by South West Tourism, and we deliver to the user a ranked list of possible attractions they might visit. The ranking is determined by the user's current context: obviously their location is an important component of this, but the likely weather is equally important. In particular the weather can be used to help ensure the information delivered really is relevant.

Thus there is a need for a weather server to supply, to the retrieval engine, the weather at any given location. (Indeed such servers already exist, e.g. for the WAP market, though we here try to look beyond what the present generation offers.) This note explores how weather information can be provided and used. As a starting point, it is worth noting that there are three types of context-aware application as regards the use of the current context:

In the archetypical case the current context is just used to retrieve other information, e.g. the tourist's current location is used in retrieving information about tourist sites nearby.
In a slightly more elaborate case some fields of the current context and used in setting other fields before stage 1 above occurs. The weather is an obvious example here: the location field may be fed to the weather server, which then supplies the weather for that location; the enhanced current context, consisting of location and weather fields -- and doubtless others too -- is used to retrieve other information.
In some cases the current context itself may be of interest to the user: for example the user might be interested in their location, as detected by their GPS sensor, say, or in the weather field mooted above; in such cases the current context is an end in itself, and no retrieval activity need occur. Most current weather servers are used in this way. We believe, however, that the biggest future markets lie in using the weather, together with other information, to deliver relevant information to the user.

Time

The most obvious need is for a weather forecast, i.e. the weather relating to a time in the future, but, interestingly, there are also needs for the weather at the present and in the past. In more detail the three cases are as follows:

Future:: the need is for a forecast of the weather for some future time interval. This could be used in almost any outside application, but tourism is an especially good example. In the simplest case if the weather is wet this biases the retrieval towards indoor activities, whereas if hot and dry the bias might be towards beaches. The weather forecast should relate as closely as possible to the user's current location. In the simplest case the weather server might have pre-written forecasts for predefined areas (like most weather information on the web today), and will select the one that best matches the user's current location. A more sophisticated forecast could be made on-the-fly, using dynamic information about the progress of weather fronts, and perhaps using subsidiary information derived from the user's current location (their height above sea level, for example) together with user's preferences (e.g. for marine information); the forecast can then be closely tailored to the current user -- indeed its content might be tailored too: for some users pollen counts are significant, for others they are not. Since users are mobile there is scope for a further level of sophistication: taking into account the user's forecast location. If, for example, the user is travelling at 60 mph in a generally SW direction, then the forecast might be adjusted automaticly to cover the area the user was travelling towards -- though obviously this needs to be done in moderation as the user may well change direction or stop.
Present:: in some applications, such as vehicle fleet tracking, the user is different (and at a different location) from the objects for which current contexts are being recorded, such as lorries. In such applications, the present weather for each of the tracked objects might be needed by the user, perhaps a fleet manager who is sitting in an office.
Past:: in many context-aware applications, the current context is, partly or wholely, simulated rather than real. Thus the user can pretend to be in a different place, and at a time in the past, and to retrieve information for that context. (One class of such application, which may become popular, is sharing experiences with a distant loved one: you pretend you are in the context that the loved one is/was in.) Such applications may need the weather (at the simulated place and time) as an aid to retrieval; indeed the weather itself may be what the user wants to retrieve.
Ideally a weather server should cover past, present and future in a uniform way.

Getting information back from the users

As electronic sensors, connected to the mobile user's computer, get cheaper and smaller, users will carry increasing numbers of them: some of these may relate to the current weather and environment, e.g. air pressure, air temperature, relative humidity. In most applications the mobile users are requesters of information, but they could also be exploited as providers, e.g. they could report back, to a central repository, the current values of their weather sensors. (Indeed the information might be provided without any extra action at all: if the users are making regular requests to a central retrieval server, supplying their current context with each request, then the retrieval server can retain the weather information as a side-effect.) From a weather forecasting viewpoint the users can be regarded as a huge number of miniature weather stations. Of course there are lots of imperfections: the users will be amateurs, perhaps with poorly calibrated sensors; the users are likely to be unevenly distributed at any one time, and there will not necessarily be a user anywhere near a desired location; some of the user's will be in artificial environments, such as in a building. However there are intriguing possibilities of extracting some high-quality information from a mass of low-quality information, and moreover this information may come at negligible cost.

Triggering on weather conditions

A key component on context-aware applications is triggering, i.e. proactively supplying the user with information when their context matches certain conditions. A promising case is weather warnings, i.e. triggering based on the user's location, height above sea level, the weather, and a time period (which will normally be in the future, e.g. the next 12 hours). Warnings to take frost precautions are an obvious example.

Research issues and market opportunity

There are research issues in providing and representing weather information for context-aware applications, and in exploiting the inter-relationships between contextual fields in order to create a whole retrieval system that is greater than the sum of its parts. All experience tells us that the key to success is providing information that is really relevant to the user, and effective integration of weather information is one route to enabling high-precision information.

The market for context-ware services has just begun, and we believe that there will be increasing opportunities for consortia of information providers to create products that provide really valuable information, far beyond the relatively simplistic systems we see today.

At Exeter we already have a context-aware retrieval engine that is capable of using the weather and other contextual fields to retrieve information. We are keen to work with information and service providers to exploit this.

Link to summary page for context-aware retrieval work