nication costs, communication bandwidth, and even the social situation; e.g., whether you are ... Take the canonical context-aware application, an indoor mobile ..... calculate the degree of interest of any complex query condition based on the.
Related Work on Context-Aware Systems Kostas Stefanidis Evaggelia Pitoura Department of Computer Science, University of Ioannina, Greece {kstef, pitoura}@cs.uoi.gr In this work in-progress report, we survey work related to context-aware systems and applications.
1
Types of Context Aware Applications
Schilit [1] notes that three important aspects of context are: where you are, who you are with, and what resources are nearby. Context encompasses more than just the user’s location, because other things of interest are also mobile and changing. Context includes lighting, noise level, network connectivity, communication costs, communication bandwidth, and even the social situation; e.g., whether you are with your manager or with a co-worker. Context has been tied to ubiquitous computing, although the term has had several meanings that differ subtly. One challenge of mobile distributed computing is to exploit the changing environment with a new class of applications that are aware of the context in which they are run. Such context-aware software adapts according to the location of use, the collection of nearby people, hosts, and accessible devices, as well as to changes to such things over time. A system with these capabilities can examine the computing environment and react to changes to the environment. Schilit [1] defines context-aware computing, and describes the four categories of context-aware applications: (a) proximate selection, (b) automatic contextual reconfiguration, (c) contextual information and commands, and (d) contexttriggered actions. Proximate Selection Proximate selection is a user interface technique where the located-objects that are nearby are emphasized or otherwise made easier to choose. In general, proximate selection involves entering two variables, the locus and the selection. However, of particular interest are user interfaces that automatically default the locus to the user’s current location. There are at least three kinds of located-objects that are interesting to select 1
using this technique. The first kind is computer input and output devices that require co-location for use. This includes printers, displays, speakers, facsimiles, video cameras, thermostats, and so on. The second kind is the set of objects that you are already interacting with, and which need to be addressed by a software process. This includes people in the same room to whom you would like to ”beam” a document. The third kind is the set of places one wants to find out about: restaurants, nightclubs, gas stations, and stores, or more generically, exits and entrances. Consider an electronic yellow pages directory that, instead of the ”city” divisions of information, sorts represented businesses according to their distance from the reader. Automatic Contextual Reconfiguration Reconfiguration is the process of adding new components, removing existing components or altering the connections between components. Typical components and connections are servers and their communication channels to clients. However reconfigurable components may also include loadable device drivers, program modules, hardware elements, etc. In the case of context-aware systems, the interesting aspect is how context of use might bring about different system configurations and what these adaptations are. Contextual Information and Commands People’s actions can often be predicted by their situation. There are certain things we do when in the library, kitchen, or office. Contextual information and commands aim to exploit this fact. Queries on contextual information can produce different results according to the context in which they are issued. Similarly, context can parameterize ”contextual commands”, for example, the print command might, by default, print to the nearest printer. Context-Triggered Actions Context-triggered actions are simple IF-THEN rules used to specify how contextaware systems should adapt. Information about context-of-use in a condition clause triggers consequent commands; something like living in a rule-based expert system. A number of applications can be organized in this way. The category of context-aware software is similar to contextual information and commands, except that context-triggered action commands are invoked automatically according to previously specified rules.
2
Definition of Context
While most people tacitly understand what context is, they find it hard to elucidate. Previous definitions of context are done by enumeration of examples or by choosing synonyms for context. A commonly-accepted definition is given by Dey [4]: Definition 1 Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered 2
relevant to the interaction between a user and an application, including the user and applications themselves. This definition makes it easier for an application developer to enumerate the context for a given application scenario. If a piece of information can be used to characterize the situation of a participant in an interaction, then that information is context. Take the canonical context-aware application, an indoor mobile tour guide, as an example. The obvious entities in this example are the user, the application and the tour sites. We will look at two pieces of information weather and the presence of other people - and use the definition to determine whether either one is context. The weather does not affect the application because it is being used indoors. Therefore, it is not context. The presence of other people, however, can be used to characterize the user’s situation. If a user is traveling with other people, then the sites they visit may be of particular interest to her. Therefore, the presence of other people is context because it can be used to characterize the user’s situation. Dey [4] also defines context-aware computing. Definition 2 A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task. Similar to the problem of defining context, researchers have also tried to specify the important features of a context-aware application. Again, these features have tended to be too specific to particular applications. There are three general categories of features that a context-aware application can support: • Presentation of information and services to a user; • Automatic execution of a service for a user; and • Tagging of context to information to support later retrieval
3
Awareness Information Environments in Mobile Computing
Awareness information environments help to support the coordination of workgroups by providing application-independent information to geographically dispersed members of a workgroup about the members at the other sites. Such information typically includes their presence, availability, past and present activities; about shared artifacts; and about various other things that exist or happen at the other sites. Often they consist of sensors capturing information, a server that processes the information, and indicators to present the information to the interested users.
3
Context aware systems provide services and information to mobile users that are adapted to the current context of use (i.e., physical location, other persons nearby, etc.). Furthermore, the current context of the user is used to facilitate contacts and communication between users. Several approaches have defined context models and described different aspects of context taken into account for context-aware systems. In most definitions of context four main dimensions of a context are considered ([5]): • Location: We consider location as a parameter that can be specified in electronic and physical space. An artifact can have a physical position or an electronic location described by URIs or URLs. Location-based services as one type of context aware applications can be based on a mapping between the physical presence of an artifact and the presentation of the corresponding electronic artifact. • Identity: The identity of a person gives access to second level contextual information. In some context-aware applications highly sophisticated user models hold and infer information about the user’s interests, preferences, knowledge and detailed activity logs of physical space movements and electronic artifact manipulations. As described in the following section the identity of a context can also be defined by the group of people that shares a context. • Time: Time is an important dimension for describing a context. Time is an important and natural context for many applications. Time context, such as time of day, week, month and season of a year (e.g., working hours vs. weekend). • Environment or Activity: The environment describes the artifacts and the physical location of the current situation. In several projects approaches for modeling the artifacts and building taxonomies or ontology about their interrelations are used for selecting and presenting information to a user. Also, this paper distinguishes primary and secondary context types. Primary context types describe the situation of an entity and are used as indices for retrieving second level types of contextual information.
4
Context-Aware Mobile Computing
The goal of [2] is to survey the most relevant literature in the area of contextaware mobile computing. Various definitions of ”context” are discussed and the paper presents ways in which context is used. Schmidt try to formally define context, as ”knowledge about the user’s and it device’s state, including surroundings, situation, and to a less extent, ”location”. Combining several context values may generate a more powerful understanding 4
of the current situation. ”Primary” contexts, including location, entity, activity and time, act as indices into other sources of contextual information. For example, knowing the current location and current time, together with the user’s calendar, the application will have a pretty good idea of the user’s current social situation, such as having a meeting, sitting in the class, waiting in the airport, and so on. Also, in this paper Chen and Kotz give their own definition of context. Definition 3 Context is the set of environmental states and settings that either determines an application’s behavior or in which an application event occurs and is interesting to the user. There are two ways to use context: automatically adapt the behaviors according to discovered context (using active context), or present the context to the user on the fly and/or store the context for the user to retrieve later (using passive context). Thus there are two definitions of context aware computing: Definition 4 Active context awareness: an application automatically adapts to discovered context, by changing the application’s behavior. Definition 5 Passive context awareness: an application presents the new or updated context to an interested user or makes the context persistent for the user to retrieve later. Active context-aware computing is more interesting because it leads to new applications on mobile devices and it requires more infrastructure support.
5
The Solar Platform
An Open Platform for Context-Aware Mobile Applications, which called Solar, is presented in [3]. Solar is a middleware platform to help context-aware applications aggregate desired context from heterogeneous sources and to locate environmental services depending on the current context. Context information is derived from an array of diverse information sources, such as location sensors, weather or traffic sensors, computer-network monitors, and the status of computational or human services. While the raw sensor data may be sufficient for some applications, many require the raw data to be transformed or fused with other sensor data before it is useful. By aggregating many sensor inputs to derive higher-level context, applications can adapt more accurately. A fundamental challenge in pervasive computing is to collect raw data from thousands of diverse sensors, process the data into context information, and disseminate the information to hundreds of diverse applications running on thousands of devices, while scaling to large numbers of sources, applications, 5
[badge="VER16481", location= [organization="Dartmouth", building="Sudikoff", room="120" ] timestamp=1023510520 ] (a) A location event
[measyre="location", badge="VER16481", granularity="room", provides="Versus" ]
(b) A source name
$badge−loc = any | [measure="location",badge="VER16481"] [device="camera", color=true, resolutin="640x480", location=$badge−loc:location ] (c) A context−sensitive name for the mobile camera
Figure 1: The event representation and naming mechanism in Solar and users, securing context information from unauthorized uses, and respecting individual’s privacy. In the solar model, context-aware applications respond to context changes by adapting to the new context. These applications are likely to have an eventdriven structure, where context changes are represented as events. An information source publishes events indicating its current state or changes to its state. The sequence of events produced is an event stream. Context-sensitive applications subscribe to event streams that interest them. Solar represents contextual events as a list of hierarchical attribute-value pairs. The internal data structure is a forest with the values at the leaves. An example of an event about the current location of badge numbered ”VER16481” may look like Figure 1(a). Also, Solar name the sources, using an attribute-based naming scheme. Solar uses an approach that keeps the values order-free but allows a tree structure on attribute names (not values) for convenience, exactly like the representation of Solar events. An example name of the source that tracks badge ”VER16481” is shown in Figure 1(b). Traditionally a resource directory is fairly static and assumes that names rarely change after they are registered. Context-aware applications, however, may need to look up names based on context. For example, a context-aware display may want to find all nearby cameras. In this case, the physical location is part of the resource description for each camera, which may move frequently. Automatic name updates should be used; for example, attach an active badge to the camera and arrange to have location changes update the camera’s name. The name is itself context-sensitive. Solar uses an approach that allows the name for a source to change according to context. Solar provides a unique way to automatically manage context-sensitive
6
names by defining the values of contextual attributes to be the output of some sources computing that piece of context. In Figure 1(c) there is an example of such a context-sensitive name for a mobile camera. It first defines a source that tracks the camera’s location (assuming the camera has badge ”VER16481” attached), and then defines the location attribute of that camera to be part of the location event published by the specified source.
6
User Profiles for Caching
In [7], a profile specification scheme is presented that allows identifying items of interest. This scheme supports the specification of data dependencies (e.g., the fact that directions to a hotel from the airport are useful only in the presence of the corresponding airline and hotel reservations). Also, the scheme has the ability to specify thresholds, such as the fact that no more than three restaurant recommendations are useful. These extensions to profile formulation reflect a global view of how a selected item relates to other selected items. A simple language is proposed to express objects of interest. To illustrate this profile language, an example profile is presented in Figure 2. Observe that the profile specification is broken into two parts: the Domain clause (DOMAIN) defines the sets of objects of interest and the Utility clause (UTILITY) specifies the relative values of objects contained in each domain set. The value of each object it might be dependent on the presence of another object. Also, it might depend on how many of them appear in the cache. Thus, 1. A set of objects of interest can have a specific value OR 2. Some of the objects of interest of a set have a value and the rest of them have another value. (UPTO (u, v, w) is a threshold operator: up to u objects have a value of v each, and every object beyond u has a value of w.) OR 3. The value of a set of objects of interest is dependent on the presence of another object of interest. If the last object there is in the cache, the objects take values with the first or the second way. We explain all these in the following example. The Traveler profile might be used to drive data recharging for a traveler about to travel to Boston. Suppose the traveler wants to stay downtown. He needs to get from the airport to a downtown hotel, either by rental car or a shuttle. For a shuttle, he needs a schedule for a company offering shuttle service. For a rental car, he needs rate information for one or more rental car companies and driving directions from the airport to downtown. Even if he takes a shuttle downtown, directions serve some use as they tell him a bit about how to get 7
PROFILE Traveler DOMAIN RC=related.hertz.com Sh="shuttle scheduler" AND "airport" AND "Boston" Di="directions to downtown Boston" AND "airport" Ho="Hotel" AND "downtown Boston" Re="Restaurant Review" AND "downtown Boston" UTILITY U(Re)=1 U(RC[#Di>0])=UPTO(2,2,0) U(Sh)=UPTO(1,3,0) U(Di[#Ho>0])=UPTO(1,1,0) U(Ho[#Di>0 OR #Sh>0])=UPTO(1,2,0) END
Figure 2: A Profile for Data Recharging about the city. He also needs information about downtown hotels, but only if he has received a shuttle schedule or directions telling him how to get to them. Finally, he would like to see reviews for nearby restaurants. The Domain clause of Traveler identifies 5 domain sets specified by expressions resembling inputs to a search engine. In this profile, RC is a set of rental car company web pages that offer details about rates and policies, Sh is a set of shuttle schedules for shuttles heading to downtown from the airport, Di is a set of web pages, text files etc. that give directions from the airport to downtown, Ho is a set of web pages for hotels located in downtown Boston, and Re is a set of reviews for restaurants also located in downtown Boston. The Utility clause of Traveler specifies 5 utility ”equations” (one for each domain set) that capture the data values and dependencies previously described. Every restaurant review has a value of 1. The value of rental car web pages (RC objects) is dependent on the presence of Di objects: the condition, ”[#Di > 0]”, is true if the number of Di objects in the cache (#Di) is greater than 0. This reflects the dependency of the value of rental car data on having driving directions. The value of RC objects also depends on how many of them appear in the cache. ”UPTO (2, 2, 0)” specifies that the first two RC objects carry a value of 2, and that any more found in the cache have no value. This reflects the preference that having 2 rental car web pages in the cache is useful (so that rates and policies can be compared), but that any more than this is unnecessary. UPTO (u, v, w) is a threshold operator: up to u objects have a value of v each, and every object beyond u has a value of w. Sh, Di and Ho objects are defined similarly to RC objects: up to 1 shuttle schedule has value 3; up to 1 set of
8
directions to downtown has value 1 provided that a hotel web pages is in the memory; and up to 1 hotel web page has value 2, provided that either a set of directions or a shuttle schedule are also in the cache. Thus, a cache consisting of two rental car web pages, one set of directions and a hotel web page would have overall value of ((2 + 2) + 1+ 2 =) 7, and a cache consisting of one shuttle schedule, one rental car web pages and two restaurant reviews would have an overall memory value of (3 + 0 + (1 + 1) =) 5.
7
Personalization in Database Systems
[6] refers to a preference model that assigns to each possible atomic query condition a personal degree of interest and provides an intuitive mechanism to calculate the degree of interest of any complex query condition based on the degrees of interest of the participating atomic conditions. The preferences of each user could be marked with the degree of interest on the part of the user are stored in a user profile. Then the system could automatically consider and integrate them into the initial core query avoiding any additional human effort or use of complex interface. A user’s preference of an atomic query element is expressed in the form of a degree of interest, which is a real number in the range [0,1]. A particular user’s preferences over the contents of a database can be expressed on top of personalization graph of the database. This is a directed graph G(V, E), (V is the set of nodes and E is the set of edges), that can be thought of as an extension schema graph. There are three types of nodes in V : 1. Relation nodes. One node for each relation in the schema. 2. Attribute nodes. One node for each attribute of each relation in the schema. 3. Value nodes. One node for each possible value of each attribute of each relation in the schema. Likewise, there are two types of edges in E: 1. Selection edges. An edge from an attribute node to a value node. 2. Join edges. An edge from an attribute node to another attribute node. Two attributes nodes could be connected through two different join edges, in the two possible directions. Consider the database schema below, with information about movie theatres, movies, directors, and actors: theatre(tid,name,phone,region) as th play(tid,mid,date) as pl
9
1
TID THEATRE
TID
1
NAME PHONE
DOWNTOWN MID
MID
MID
REGION 0.8
CAST
PLAY
DATE
0.8
0.9
1
MGENRE GENRE 0.9
MID
0.8
COMEDY
MOVIE
ROLE
0.7
TITLE
THRILLER
ACID 1 1 ACTOR
0.5
YEAR
ADVENTURE
1
ACID
MID DIRECTED
NAME DID 0.9 KIDMAN
1
1
0.7 ROSSELLINI
DID
0.8
DIRECTOR HOPKINS
NAME
0.7 ALLEN 0.9 LYNCH
Figure 3: Personalization graph corresponding to Julie’s profile movie(mid,title,year,plot) as mv cast(mid,acid,award,role) as ca actor(acid,name,sex) as ac directed(mid,did) as dd director(did,name,sex) as di mgenre(mid,genre) as mg Example: Julie prefers theatres located downtown. She is a fan of comedies, enjoy thrillers, and likes adventures to a lesser extent. She is very keen on D. Lynch and N. Kidman, likes A. Hopkins, and finds W. Allen and I. Rosselleni quite interesting. All the above are expressions of interest in selections. She performs searches concerning theatres, movies, actors and directors. Hence, she has preferences expressed over the joins between the corresponding relations, to allow queries on one to take into account her preferences on the others. For example, when Julie asks for movies, she is interested in their directors and to a lesser degree in their actors as well. All of Julie’s preferences are captured in her profile, which is graphically depicted in the personalization graph of Figure 3. These preferences may evolve through time as a result Figure 3 illustrates an instance of Julie’s profile for a given point in time. Note that the level of a user’s desire to include a join into the query qualification may be different depending on which end of the join is already there. For this reason, a join condition may be associated with two different degrees of interest, indicated in the personalization graph with different labels on the
10
two distinct edges that correspond to the join condition, one for each possible direction from the node already included in the query to the one that is not. For example, there are two join edges with different labels between the relations movie and play, because it is more important to take into account information about movies when inquiring on theatres than the other way around. Consider a set PN of N compose-able atomic preferences and the corresponding set DN of the degrees of interest: DN = {di |di : degree of interest in Pi e PN , i = 1 . . . N } For any function f calculating the degree of interest in a transitive preference formed by the atomic preferences in PN , the following must be hold: f(DN ) ≤ min(DN ) In other words, the degree of interest in a transitive preference decreases as it moves further away from the part of the graph that the user mentioned originally in the query. The function f is: f(DN ) = d1 ∗ d2 . . . ∗ dN For example, Julie likes movies starring N. Kidman, expressed as an implicit preference on the condition: movie.mid=cast.mid and cast.acid=actor.acid and actor.name=’Kidman, N.’. The degree of interest associated with the corresponding transitive preference is the product of the degrees of the constituent conditions, which based on her profile, gives 0.8 ∗ 1 ∗ 0.9 = 0.72. Combination of User Preferences Conjunctive Preference. For any function f∧ calculating the degree of interest in the conjunction of the preferences in PN . Disjunctive Preference. For any function f∨ calculating the degree of interest in the disjunction of the preferences in PN . The functions are the following: f∧ (DN ) = 1 − (1 − d1 )(1 − d2 ) . . . (1 − dN ) and f∨ (DN ) = (d1 + d2 + . . . + dN )/N
11
References [1] Norman Adams Bill N. Schilit and Roy Want. Context - Aware Computing Applications. IEEE Workshop on Mobile Computing Systems and Applications, 1994. [2] Guanling Chen and David Kotz. A Survey of Context-Aware Mobile Computing Research. Dartmouth Computer Science Technical Report TR2000381. [3] Guanling Chen and David Kotz. Solar: An Open Platform for ContextAware Mobile Application. In Proceedings of the First International Conference on Pervasive Computing, 2002. [4] Anind K. Dey. Understanding and Using Context. Personal and Ubiquitous Computing, 2001. [5] Tom Gross and Marcus Specht. Awareness in Context - Aware Information Systens. Proc Mensch and Computer 01, 2001. [6] Georgia Koutrika and Yannis E. Ioannidis. Personalized Queries Using a Generalized Preference Model. HDMS, 2004. [7] Michael J. Franklin Mitch Cherniack, Eduardo F. Galvez and Stan Zdonik. Profile-Driven Cache Management. International Conference on Data Engineering, 2003.
12
