Abstract: Developments in ubiquitous computing and ubiquitous communication, together with intelligent user-friendly interfaces, eventually lead to a world in which computing functionality will be embedded in all kinds of objects, which are capable of recognizing and responding to individual human needs in a seamless, unobtrusive, and often invisible way. Such a vision is coined Ambient Intelligence (AmI), whose aim is to bring information technology to everyone, every home, every school, and every business. An example is a hotel room that can adapt automatically to its customer’s favorite room temperature and music choice. In the AmI world, for computers to be able to fit human environments, they must be in proper size and shape, appropriate for their users, and adaptable to the users’ world; in other words, they should be context-aware. This chapter addresses challenges raised by context-awareness on data management. Characteristics of context and its implications from the standpoints of both users and systems are discussed. Reference to relevant research activities and applicable technologies are meanwhile provided. Six context-aware data management strategies, using context-aware querying as a case in point, are further illustrated. A context-aware data management supporting platform, consisting of context provider, service registry, context processor, and context consumer, is provided, where context-aware data management is situated as context consumers.
In comparison with several other terms like ubiquitous computing, pervasive computing, and wearable computing [14, 54, 64], which share a common vision with AmI on integration of networked embedded devices into people’s background, AmI takes this integration one step further by realizing environments that are sensitive to people’s needs, personalized to their requirements, anticipatory of their behaviors, and responsive to their presence [1, 13, 45, 51]. It thus emphasizes more on greater user-friendliness, user-empowerment, and more effective service support. Such a user-centric focus introduces several basic problems related to natural user interaction, context awareness, and ubiquitous wireless access to information, communication, and services in such environments like home and work space.
Adding intelligence to the ambience of users raises many challenges to data management . High-quality information must be available to any user anytime anywhere and on any device. The implementation of the AmI landscape relies heavily on these constant information flows from numerous sensors and services, monitoring not only the users but also external environments. Here, how to intelligently capture and map the data to appropriate behaviors of users in context is a key issue to be addressed.
This section addresses the impact of AmI, in particular, its context-awareness requirement on data management strategies and solutions. Before eliciting concrete database requirements from AmI, let’s first look at a scenario envisioned in an AmI world.
John is a business man working for a global chain restaurant corporation. One morning just after arriving at the office, he got an urgent message to travel to the headquarters situated in a nearby country for an important decision-making meeting held in the afternoon. Through his electronic personal assistant (PA), John got to know the earliest flight that he could catch up with will depart in 3 hours, and his PA further checked out that there were still some seats available. Considering that he needed to arrange several reports and have them ready on his PA for the meeting, John commanded his PA to find the fastest transportation to the airport, as he wanted to win as much time as possible for his preparation before setting out. There were three choices, i.e., by train, by car, and by shuttle bus. John’s PA queried two separate external databases for the departure times and durations of the train and bus. It meanwhile calculated the approximate time needed to drive to the airport, taking John’s driving speed and traffic status during that period into account. Following the PA’s advice, John arrived at the airport on schedule by his car and boarded the plane.
On the flight, John browsed through several articles issued from a news center. One of them about IT services left him a deep impression. However, at that time, he had not realized the influence of this article on the acceptance of his proposal at the afternoon’s meeting.
John’s speech at the meeting was well received. Specifically, he was able to justify his proposal by referring the attendants to the article that he read a few hours ago in the plane. With the help of John’s PA, this article was re-localized and retrieved from the news center site. This time it was presented clearly on a big screen inside the meeting room.
The meeting finished very late that day. John wanted to go first for dinner before flying back home. His PA recommended a few nearby restaurants that were still open, with an oriental restaurant coming in first, as John’s PA knew that John liked oriental food very much.
It was almost midnight when John’s plane landed on his home city. For safety reason, the PA suggested John taking a route different from the morning one. Although this route was a bit longer, it avoided passing through a dark wood. Accompanied with his private PA, which broadcasted the selected news, John finally arrived home safely.
The above scenario depicts an ambient data management paradigm, distinct from the current conventional one. It breaks away from the traditional stationary desktop computing paradigm, giving users the capability of acquiring the most desirable information anytime anywhere with any lightweight handheld device via wireless communication channel [2, 3]. In the scenario, user’s database access does not occur at a single location in a single context, as in desktop computing, but rather span a multitude of situations and locations covering the office, plane, meeting room, home, and so on.
Till now, decades of efforts have been made in improving content-based data access due to the long-historical stationary database constraint. Nevertheless, AmI promotes us to go further for context-based data access. “Get the report which I prepared last night before dinner in the hotel for this afternoon’s meeting” and “Find restaurants nearby which I have not visited for half a year” are examples of such queries. Apparently, exploiting various context information can assist data managers to better understand users’ information needs, and facilitate them to make the best of data in carrying out daily life and work. From a data manager’s point of view, this context information also provides hints on how to process data requests in the most optimal way, as it carries a kind of semantics related to what, why, when, where, and how to use data sources. We believe that by context-awareness, the interaction and understanding between data managers and users can be enriched than ever.
On the other hand, keeping data managers aware of context entails a thorough re-examination of currently existing data management techniques, raising a number of interesting and challenging questions as follows.
–By context-awareness, can we make data managers more adaptable, responsive, personalized, dynamic, and anticipatory, as charted by AmI, than before?
–Compared with traditional data management, what are the fundamental issues underlying context-aware data management?
–To bring context-awareness feature into data management, how to acquire, categorize, model, and protect context information?
–How to use context information to answer a user’s data request?
–What are the context-aware data management strategies? How to support, manage, and execute these strategies?
–How to provide context-aware data management supports to users? How to design a friendly and easy-to-use context-aware query language for users? How to effectively and efficiently interact with users, given a small device with a constrained computing capability and energy power?
The purpose of this book is to answer these questions.
Context is an essential element in AmI. There are several attempts in the literature to define the notion of context, ranging from being very broad to being very narrow and application-specific.
Broadly, according to Dourish, “Context is a slippery notion. Perhaps appropriately, it is a concept that keeps to the periphery, and slips away when one attempts to define it ”. Dourish opposed seeing context as something separable from the content of an activity. As an example, during a conversation the location of this conversation could turn from context into content when it becomes the subject of the conversation.
Lieberman and Selker viewed context from a computer programming’s perspective. Traditionally, the field of computer science tries to be context-independent: the same input provides the same output, independent of the context of the input . They thus came up with a more concrete definition of context. “Context can be considered to be everything that affects the computation except explicit input and output .”
Getting close to the application side, one of the most cited definitions of context is from Dey et al. “Context is any information that can be used to characterize the situation of an entity. An entity can be a person, place, or object that is considered relevant to the interaction between a user and application, including the user and applications themselves .”
According to Dey, a system is context-aware if it uses context to provide relevant information and services to the user, where relevancy depends on the users’ task. Gray and Salber further clarified the term interaction by indicating whether it points to what is achieved by doing this interaction (e.g., the task), or the interaction itself (e.g., the user interface or dialogue), and provided a definition for sensed context . “Sensed context are properties that characterize a phenomenon. They are sensed and are potentially relevant to the tasks supported by an application or the means by which those tasks are performed .”
From a data management perspective, this book refers context to user’s external objective environment and internal subjective status. It implies user’s information need during the interaction between the user and data management system. Context-awareness is to use context in serving user’s information need .
Based on how context information is acquired, modeled, and treated, Henricksen and Indulska categorized context information into sensed, static, profiled, or derived context . As this categorization is closely related to the way how context information is handled, it is an operational categorization.
The book conceptually distinguishes user-centric context from environmental context, as shown in Figure 1.1.
As AmI evolves from distributed mobile computing , the acquisition of context information inherently takes place among distributed sources in a mobile environment. The characteristics of context are highly influenced and determined by its acquisition way.
A majority of context like location and temperature is sensed through sensors or sensor networks. Data management solutions view a sensor network as a database. Some architectural issues, including sensor modeling, imprecise data replication, data compression and prediction, in-network processing, fault tolerance, and timeliness, etc., are addressed in Ref. [7, 41]. A quality-driven approach is usually adopted where users can indicate the confidence they want from query answers (e.g., ±1∘C of the exact answer).
TinyDB  is another system delivering a database solution to sensor networks. It focuses more on when, where, and how the data is acquired. It works with sensors running the TinyOS operating system, and does processing like filtering and aggregation as much as possible in the network. A TinyOS query example is like
SELECT temp FROM sensors WHERE temp>threshold.
What makes the sensing more complicated is that it is done most of the time by cheap, small, and therefore constrained devices. The limited computing power of such devices incurs unreliability and difficulty in running applications on such a low-level platform . Another serious factor influencing the sensing quality is battery capacity and energy cost. One effective way is to put energy management to a high application level, and switch applications to modes with lower power consumption when idle . There is a trade-off of having a sensor-based database system. On one hand, due to optimization on the sensor level, there is less power spent on transmission, but on the other hand, more power is required by sensors for processing this data.
Being sensed by many different sensors, context information come from diverse distributed sources. To get desirable information from these distributed sources, aggregators are usually used to gather context about an entity (e.g., a person in ). Some special sensor-oriented querying techniques, such as the one developed in Quasar , can also be used to address this issue. This characteristic brings about the requirement of high-interrelation on context-aware data management.
A crucial property of many sorts of context is the continuity, i.e., the user’s context constantly changes. This may lead to a proactiveness requirement on data management and applications . It causes enormous amount of data to be stored, compressed, and discretized, resulting in data impreciseness.
Closely related to the previous characteristic is the mobility of objects from which to get context information. According to Gareth Jones and Peter Brown, mobility is a prime field for context-aware retrieval due to the three reasons : (a) Information is now being made available in situations where it was not available before. (b) A mobile user is often in an unfamiliar environment and needs information about that environment. (c) It is favorable to use context to help to select the information which is needed in this new environment.
Adaptation to the current situation and caching are two techniques to handle the mobility during mobile information access in Ref. .
Mobility draws forth the prominent temporal-spatial character of contextual information. Examples for reasoning with time in temporal ontologies for context-awareness are given in Ref. . Ter Horst et al. introduced the notion of extended spacetime to reason about context events, taking time and space into account . Koile et al. introduced the notion of activity zones, i.e., regions in which the same activities occur, to trigger certain specific events . Harter et al. described a context-aware application which particularly focuses on users’ location using Bats - an ultrasound position determination system . Hightower and Borriello integrated WLAN with ultrasound and infrared tracking technologies, and used particle filters for location estimation .
Due to the characteristics of dynamics, constrained devices, diverse distributed sources, and continuity, etc. there is a high chance that the acquired context information is not perfect. Henricksen and Indulska characterized four types of imperfectness about contextual information .
–Unknown. No information is available about the property.
–Ambiguous. There are several different reports about the property, which could for example be someone who is tracked by GPS and by WLAN.
–Imprecise. The reported information is correct but too imprecise, for example, from a person it is only known that s/ he is in a certain building, but we need the exact room in which he or she is.
–Erroneous. The information about the property is not the same as the actual information.
Gu et al. and Ranganathan et al. provided some modeling solutions for uncertainty by adding a probability predicate [27, 50]. The work of Antifakos et al. demonstrated that indicating the degree of imperfectness of information and using it in the computation can lead to better decision making .
Beyond the traditional so-called “ilities” - nonfunctional requirements like reliability, availability, maintainability, responsiveness, manageability, and scalability, etc., context-awareness raises a number of particular expectations for data management from both users and systems’ perspectives.
184.108.40.206Adaptiveness and Personalization
There is a growing demand for adaptiveness on small and constrained devices in mobile computing environments. For example, choosing whether to fetch the header or the whole e-mail message is subject to the network speed. Adaptiveness and personalization are continuing to be a key to context-aware data management. Three typical ways to achieve personalization are the following .
–Rule-Based Matching (based on user profiles or communities). An example is “If the user is a sportsman, display the sport’s equipment advertisement.”
–Context-Based Matching (depending on the current context). An example is “If the user is on the sport’s page, display the sport’s equipment advertisement.”
–Category-Based Matching (based on attributes/ features). Content producers classify their contents based on certain attributes, and users rate their priorities according to these attributes.
Proactiveness is one of the most important requirements in AmI . It means to process information on behalf of a user in such a way that an action can be taken without requiring his/ her attention . This implies knowing what a user would want to do with the requested information, and detecting his/ her behaviorial patterns. Tennenhouse even coins the new term proactive computing, which stands for the movement from human-centered to human-supervised or even unsupervised computing .
Proactiveness calls for effective information extraction techniques to identify situations and some forms of reasoning mechanisms to determine an appropriate action to take.
The mostly mentioned concern for context-awareness in AmI environments is about users’ privacy, trust, and security. Early work on context-awareness done by Newman et al. evidenced that during experiments in tracing users during the day with badges, users did not wear them because of privacy issues .
Kindberg et al. argued that using visible tangible objects to do transactions (e.g. a barcode scanner) can help make transactions more trusted by the users . But meanwhile, they also point out that some other aspects such as ease-of-use are at least equally important to users.
Gandon and Sadeh proposed to deal with the privacy and security issue through privacy preferences . They used access control rules to express who has the right to see certain context information under different conditions. They also used obfuscation rules to hinder users from certain details, Leonhardt and Magee applied the context-based obfuscation approach to access control, but with a focus on users’ location information .
For systems’ proactiveness to be understandable and controllable by users, traceability is in need . It means that a user should be able to know what is happening in the background, and why it happened. Having the system or tool present-at-hand is a way to realize its traceability . One example is the dashboard of a car, by which the user can have the car present-at-hand in case something goes wrong. Another example is the network signal indicator of a mobile phone. Three system design principles are listed in Ref. .
–Systems should display their own internal states and configuration to the users.
–The deep system structure should be revealed so as to support inspection and adaption.
–Interfaces should offer direct experience of the structures by which information is organized.
Because of highly-constrained sensors and mobile objects, one serious issue confronting context-aware data management is dynamic connection. That is, connection could be lost when a sensor is out of reach or temporary unavailable, and it has to be re-established once available again.
To address this issue, on one hand, we can cache data. On the other hand, observing that information from a disconnected sensor can also be acquired via another sensor or combinations of sensors, Goslar and Schill suggested that a context database should store how to read values instead of the actual values . DeVaul and Pentland presented a dynamic decentralized resource discovery framework. It uses semantic descriptions to see what kind of services are available. Different components can be registered to a directory registration service when they are available, and de-registered when they are not available anymore .
Other applicable techniques toward dynamically interchangeable components include agent techniques and goal-oriented solutions. For example, the goal of finding a certain user’s location can be achieved via WLAN-triangulation. However, when WLAN is not available at the moment, some alternatives like GSM-triangulation or a GPS will be in place.
Dynamics in different connections challenges the underlying data management strategies. A lot of existing data management solutions are based on the assumption that the network topology changes only slowly, which are apparently inapplicable to data management in AmI environments .
Not only does high-level inferred context depend on low-level sensed context but also different kinds of low-level context parameters are interrelated. For instance, the amount of computers in a room and the energy usage of this room are closely related.
The tight interrelation makes it possible to predict some context parameters based on others . Deshpande et al. exploited such interrelations to do optimizations over TinyDB by using correlation between voltage and temperature . However, because contextual data structures are so highly interconnected, when modeling context, we have to ensure that the models are not too complex due to the limited capabilities of human users and local devices. Breaking the data structures down into smaller parts can be a help to address this issue .
220.127.116.11Learning and Reasoning
Due to the interrelationship among different levels of context, some inference mechanisms are needed in order to derive some context from other context.
Schmidt was one of the first who did so by using cues, which take the value of one sensor and provide a symbolic or subsymbolic output . Taking the output cues “the user is running” and “the user has a high pulse,” for example, a context such as “the user is jogging” can be determined.
Confronted with different context information from diverse sensors and possibly from different domains, a flexible context representation mechanism is needed so as to provide conversion among different kinds of context information. Bressan et al. discussed a method of using Prolog rules to convert across different context representations . Such an alternative context representation problem bears similarity to the schema or data integration problem in the database community, which has existed for over 20 years and has extensively been tackled using Description Logics .
18.104.22.168Metadata about Context Information
Metadata about context information are like temporal-spatial features and certainty degree, etc. They indicate the time and place at which a context-associated measurement takes place, accuracy of the measurement, as well as the trade-off between requested accuracy and energy consumption cost, etc. .
Metadata incurs collaboration between the data management side and the sensor side. To deal with context metadata, proper representation of these meta information is demanded in modeling context.
22.214.171.124Storage and Logging of Context Information
Context-awareness requires data management systems to be proactive and to detect patterns according to users’ behaviors. Relevant reactions in response to different contexts thus need to be stored beforehand. A number of questions related to what, where, and how to store context information arise.
Meyers and Kern recommended to store context information at a high level . This has two advantages. First, storage space can be reduced by only storing the high-level context information (e.g., being in a meeting) instead of storing all sensory details like temperature and exact location, since the former can be derived from the latter. The second advantage is that at a high level, more computing power is available for data compression to reduce the enormous amount of sensed context information.
Query is the most fundamental operation users pose to database systems, where context plays an essential role in context-aware querying.
A context-aware query is a query whose query answering depends not only on the data stored but also on the context under which the query is issued.
A context-aware query can thus be viewed as a parameterized query with two parameters – database and context. The same query, raised by different users, or by the same user under different contexts, may lead to different kinds of answer delivery. This is different from the traditional noncontext-aware query, whose answering depends only on the database.
Definition 1. Let db denote a database including both database schemas and database records, and let [[Context]] denote a multidimensional contextual space. A context-aware query is a triple CQ(db, [[Context]]) = (INexp, INimp, OUT), where
–INexp is the explicit query request input from the user;
–INimp is a further constraint over the user’s explicit query request, which makes user’s implicit query assumptions explicit.
–OUT is the query output sent to the user.
A traditional noncontext-aware query is a tuple NCQ(db)=(INexp, OUT), with an explicit query input from the user INexp and a query output OUT to the user.
Context-awareness penetrates three phases of a database query, i.e., user’s query request, system’s query refinement, and query answer .
126.96.36.199User’s Query Request
Strategy 1: Context as On-the-Spot Query Condition
Highly dynamic, intelligent, and responsive ambient environments prompt users to ask ad hoc queries anytime and anywhere. These on-the-spot queries usually involve the current context (like time, location, etc.) as the query referential points. Some typical examples are listed below.
–“Look for the earliest flight that I can catch.” Only the flights whose departure time is later than the current context time are meaningful query candidates.
–“Look for a nearby restaurant for eating.” Only the restaurants near the user and meanwhile are open are useful query results.
–“Look for the fastest route to the airport.” The current context – traffic status must be taken into account in computing the fastest route. Traditional location-dependent queries in wireless mobile environments [20, 32, 38, 58, 59, 65, 66] fall into this scope.
Strategy 2: Context as Recall-Based Query Condition/Query Target
For human users, context under which data was accessed in the past is always easier to remember than detailed data content itself. Identifying data items by context besides content empowers users with more convenient and friendly query capabilities. For example, a user might feel difficult to recall the title of an article. By contrast, the context under which to read the article, such as the place where the article was read, the people present when it was read, or the activity being carried out at the same time, etc., can be easier to remember. In fact, the observation that context can serve as a powerful cue for recall has a solid foundation in the psychological field, where researchers have developed a theory about episodic or autobiographical memory [6, 21, 63]. They noticed that human beings naturally organize the memories for past events into episodes, and that the location of the episode, who was there, what was going on, and what happened before or after are all strong cues for recall . Studies by Eldridge et. al also confirmed this theory and lead to the construction of a prosthetic episodic memory device called memory prosthesis [11, 22, 39], and a wearable rememberance agent .
Here are three query-by-context examples.
–“Look for the article about ‘IT services’ which I read on the plane this morning.” The query condition is based on the previous context time and simultaneous activity.
–“Look for the name of the restaurant which I went to for dinner most frequently last year.” This is an aggregate query whose query condition is context time. In addition to retrieving database content by context, it is also possible to query the context under which a certain database access happens.
–“Look for the place where I read that news about ‘IT services’.” The query condition is based on content, but requesting the past context information location.
188.8.131.52System’s Query Refinement
With Strategies 1 and 2, users can directly pose context-based queries, where context information is explicitly used in query formulation. Beyond that, context itself can also help the database system to better understand user’s need, since it conveys a rich set of semantics related to what, why, when, and where to use the data. In order to make query results truly usable and supportive, thus achieving greater user-friendliness as demanded by AmI, it is desirable to capture such an implicit query background, hidden behind context, and translate it into explicit query constraints. This stage is treated as query refinement stage.
Strategy 3: Context as Query Constraint
The query refinement process infers different kinds of query knowledge from context to make implicit users’ assumptions explicit in their queries.
–Understanding user’s query intention. Database systems aims at facilitating users to find useful information to solve their problems. When a user issues a query, s/he usually has some purpose in mind. For example, s/he retrieves restaurant information in the city because s/ hewants to invite the clients to a lunch in a few minutes according to his/her agenda. In this case, only open restaurants are meaningful to the user, which depends on the current context time. From the system’s point of view, database access should be directed by user’s specific task, and this could be found out from user’s agenda. Here, trying to understand user’s query intention and enforcing corresponding query constraints is an important step to improve the usability of databases.
–Personalizing user’s data request. The usefulness of data is also quite subjective, and varies from context to context even for the same user. For instance, for safety reason, a user driving at midnight does not like the database showing him/her the roads, which need to pass through a dark forest. Also, during the daytime rush hours, the database system should be considerate enough not to return the roads going through the city center, or the sites having traffic jam at that moment.
–Tuning abstraction level of query content. Besides constraining query conditions, context can be exploited to adjust the level and granularity of abstraction for querying of the same data content. For example, a user with a big screen nearby would prefer to display a picture at high-resolution, while with only a handheld mobile device, a low-resolution requirement is fine enough. Similarly, data at a high aggregate/ summarized level is more appropriate than the one at detailed low level, which may otherwise cause the user to scroll down the small screen for reading the answer. Apparently, by tuning the query content to an appropriate level, and integrating this requirement into the query request, query processing and optimization can be performed in a single step, and the cost incurred is proportionate to what the user wants and gets.
184.108.40.206System’s Query Answer
Apart from assisting query formulation, another important use of context for queries in AmI environments is to determine the manner such as what, when, where, and how to deliver query outputs to the users. Clearly, sending query results must not interrupt or distract the users from performing their primary tasks or annoy nearby people. Here are three strategies regarding query output.
Strategy 4: Context as Protective Screen for Sensitive Query Results
In ambient environments, a sheer amount of data will be shared and disseminated in response to different users’ requests. In order to build up trust and confidence to ambient data managers, it is important for the database system to protect sensitive data from being disclosed to the third party. For example, a police querying a traffic accident scene may want the license plates of the damaged cars to be superimposed with a black bar within the query result, if there is any unauthorized person around him/her. As another example, consider the viewing of news items that contain shocking scenes. An adult may access the whole content, however, a child may not. Also, the system may not want an adult to see it in a public environment, given that there may be some children around .
Given the limitation of small devices, it is more convenient for users if the query answer could be sorted in such a way that the most potentially useful items shown in front. Such an ordering work can be performed based on user’s interests, obtained from the profile, For example, if the user likes oriental food, the restaurants serving Asian meals can be displayed ahead of others.
Strategy 6: Context as Guide to Query Result Delivery
The output modality must be adapted to user’s current context. For example, if the user is driving, it would be convenient to have a speech query output. However, if the user is talking with someone, postponing the delivery of query results by giving a vibration alert or screen-displaying the query results will be more appropriate. The presentation of query results on a big screen would be welcomed for a group of people who are interested in the query answer.
In addition, context-aware queries differ in how deep they delve into the context notion, for example, the necessity of time and probability information and the inclusion of confidentiality functions. The execution of context-aware queries also depends on the level of conceptualization of the context to which extent reasoning and inference must be applied to get from low-level to high-level context.
To tackle the challenges of proactiveness, tractability, inference, etc. raised by context-awareness in AmI, a context-aware data management supporting framework consists of four major components, namely, context provider, service registry, context processor, and context consumer, as illustrated in Figure 1.2. Different challenges raised by context-awareness are tackled by different components, as shown in Tables 1.1 and 1.2.
Context providers are responsible for providing context in the form of services, taking into account all characteristics of context. Different kinds of contexts are taken care by different services, like location services, temperature services, and multimodal services, etc. Due to the interrelationship, more reliable information can be sought by combining several context parameters. These services are also responsible for acquiring and supplying metadata about the context, and furthermore can provide part of the privacy and security features at a sensor level.
The communication between context providers and context processors is done via the service registry. The distributed context providers register themselves at the registry.
Context processors access context information, provided by context providers, by doing a request to the registry. The later ensures that only appropriate context processors can have access to certain context information. For example, the body heat of a person returned from a body sensor can only be accessed by his/her delegated context processors. In this way, privacy and security can be accommodated. Another advantage of having a service registry is that it is possible, to dynamically (de-)register services. By doing this, dynamic connections resulting from mobility and the continuous change of context information can be supported. Finally, the service registry can incorporate conversion services which can deal with alternative representations using metadata.
Here, techniques developed in the field of Web services can be applied . For instance, with Jini, a Java-based connection technology, various Jini-compatible devices can form a dynamic network and interact with each other. This requires relatively much processing power which, together with the fact that we are dealing with small constrained devices, leads among others to the question of how much processing power and intelligence shall be injected into context providers.
The context processor stores and logs some of past, present, and future context information related to a user, environments, and corresponding past actions of the user in a context database. For the sake of privacy and security, data in this database is protected using encryption and access rights.
There are two reasons for having this context database available. First, to deal with dynamic connections, caching some context information at the context processor’s side can ensure the consistent providing of user related information, even when a user is not connected to the network.
More importantly, from these logged context information and related actions, the context processor can learn and reason about user’s preferences and behavior patterns which will lead to proactively generated rules by the system. Because of the nature of context, learning and reasoning techniques for metadata, particularly with uncertainty, in the discourse of time and space, appear to be more important than in noncontext-aware computing systems. For instance, according to a user’s context, his/her next possible action can be inferred. In this way, context consumers can adapt to a user based on these rules, by which the system becomes personalized. As an example, consider a person who each time when s/he enters a room, turns on the light. After several times, the proactive rules can be learned by the learner and then stored in the context database. With this rule, the context-aware light button will automatically turn on the light, whenever this user enters the room.
For the context processor, it is important to structure the preferences and rules in a way which is clear to the user, so that s/ he can view and edit them. Furthermore, the rules need to take into account metadata, especially accuracy, among others for giving the user the possibility to specify a minimum accuracy level for triggering a rule. Since the behavior of the consumers is completely based on the rules and preferences stored in the database, the proactiveness in this way becomes traceable.
Note that, in supplying context consumers with these actionable context knowledge, the context processor will invoke a set of privacy and obfuscation rules to avoid the misuse of context and context-awareness.
Context consumers can be either context-aware data management systems or external parties like restaurants, museums, machines, etc., since all of them make use of context during functioning. database management systems (DBMS) are positioned as context consumers.
A context consumer example could be a context-aware multimedia database system, which stores all videos and scenes one watched before. When the person poses to this database a query like “which scene of The Bourne Identity did I watch yesterday before going to the supermarket?”, the system could (if allowed) consult this user’s delegated context processor about the time the user went to the supermarket and based on this, present the right scene to the user.
Subsection gives a series of context-aware database query examples to be executed by a context-aware database management system, which is also a context consumer.
One key requirement for computer systems to be Ambient Intelligent is to be context-aware. This chapter addressed the impact of context-awareness on data management, from context, context-awareness, to context-aware data management platform. Having followed the approach of identifying the characteristics of context in a practical manner in combination with a functional data management architecture, it is possible to say where to tackle which problems and to what extent existing techniques can be used. We can thereby, on one hand, work on context processors, particularly focusing on a context modeling technique to express and store context information, with support for metadata and preference rules. The latter is generated proactively and defined by users. On the other hand, we can focus on context providers and service registry, where existing platforms for providing context information to the context processor can be employed. Desired techniques in delivering context-aware data management solutions will be addressed in the following chapters.
E. Aarts and S. Marzano (eds.). The New Everyday: Visions of Ambient Intelligence, Rotterdam, The Netherlands: 010 Publishing, 2003.
G. D. Abowd, A. Dey, R. Orr, and J. Brotherton. Context-awareness in wearable and ubiquitous computing. Virtual Reality, 3:200–211, 1998.
G. D. Abowd and E. D. Mynatt. Charting past, present, and future research in ubiquitous computing. ACM Transactions on Human-Computer Interaction, 7(1):29–58, 2000.
J. Ahola. Ambient intelligence: Plenty of challenges by 2010. In Proc. of EDBT, Czech Republic: Prague, page 14, March 2002.
S. Antifakos, A. Schwaninger, and B. Schiele. Evaluating the effects of displaying uncertainty in context-aware applications, Proceedings of UbiComp, N. Davies, E. Mynatt, and I. Siio (eds.), Springer-Verlag Heidelberg, pages 54–69, 2004.
L. W. Barsalou. The content and organization of autobiographical memories, Remembering reconsidered: Ecological and traditional approaches to the study of memory, U. Neisser and E. Winograd (eds.), Cambridge University Press, Cambridge, pages 193–243, 1988.
P. Bonnet, J. Gehrke, and P. Seshadri. Towards sensor database systems. In Proc. of MDM, pages 3–14, 2001.
S. Bressan, K. Fynn, C. H. Goh, S. E. Madnick, T. Pena, and M. D. Siegel. Overview of a prolog implementation of the context interchange mediator. In Proc. of the Intl. Conf. and Exhibition on the Practical Applications of Prolog, pages 83–93, 1997.
M. Chalmers. A historical view of context. Journal of Collaborative Computing, 13:223–247, 2004.
G. Chen and D. Kotz. A survey of context-aware mobile computing research. Technical report TR2000-381, Dept. of Computer Science, Dartmouth College, 2000.
H. Chen, T. Finin, and A. Joshi. Semantic web in a pervasive context-aware architecture, In Proc. of AIMS, Seattle, USA, pages 33–40, 2003.
M. Cherniack, M. J. Franklin, and S. B. Zdonik. Data management for pervasive computing. Tutorial at VLDB, Rome, Italy, pages 71–140, 2001.
M. Dertouzos. The future of computing. Scientific American, 281(2):52–55, 1999.
A. Deshpande, C. Guestrin, S. R. Madden, J. M. Hellerstein, and W. Hong. Model-driven data acquisition in sensor networks. In Proc. of VLDB, pages 588–599, 2004.
R. W. DeVaul and A. Pentland. The ektara architecture: The right framework for context-aware wearable and ubiquitous computing applications, MIT Technical Report, USA, 2000.
A. K. Dey. Understanding and using context. Personal Ubiquitous Computing, 5(1):4–7, 2001.
A. K. Dey and G. D. Abowd. Towards a better understanding of context and context-awareness. Technical report GIT-GVU-99-22, Georgia Institute of Technology, 1999.
P. Dourish. What we talk about when we talk about context. Personal and Ubiquitous Computing, 8(1):19–30, 2004.
M. Dunham and V. Kumar. Location dependent data and its management in mobile databases. In Proc. of DEXA, Vienna, Austria, pages 414–419, August 1998.
M. Eldridge, P. Barnard, and D. Bekerian. Autobiographical memory and daily schemas at work. Memory, 2(1):51–74, March 1994.
M. Eldridge, M. Lamming, and M. Flynn. Does a video diary help recall, People and Computers VII, A. Monk, D. Diaper, and M. D. Harrison (eds.), Cambridge University Press, Cambridge, UK, pages 257–269, 1992.
L. Feng, P. M. G. Apers, and W. Jonker. Towards context-aware data management for ambient intelligence. In Proc. of DEXA, pages 422–431, 2004.
F. L. Gandon and N. M. Sadeh. Semantic web technologies to reconcile privacy and context awareness. Web Semantics Journal, 1(3):241–260, 2004.
K. Goslar and A. Schill. Modeling contextual information using active data structures. In Proc. of the Intl. Workshop for Pervasive Information Management, pages 325–334, 2004.
P. D. Gray and D. Salber. Modelling and using sensed context information in the design of interactive applications. In Proc. of the 8th IFIP Intl. Conf. on Engineering for Human-Computer Interaction, Springer–Verlag, pages 317–335, 2001.
T. Gu, H. K. Pung, and D. Q. Zhang. A Bayesian approach for dealing with uncertain contexts. In Proc. of Pervasive Computing, 2004.
A. Harter, A. Hopper, P. Steggles, A. Ward, and P. Webster. The anatomy of a context-aware application. In Proc. of Mobicom, ACM Press, pages 59–68, 1999.
K. Henricksen and J. Indulska. Modelling and using imperfect context information. In Proc. of the Intl. Workshop on Context Modelling and Reasoning (CoMoRea’04), IEEE Computer Society, pages 33–37, 2004.
K. Henricksen, J. Indulska, and A. Rakotonirainy. Modeling context information in pervasive computing systems. In Proc. of Pervasive Computing, pages 167–180, 2002.
J. Hightower and G. Borriello. Particle filters for location estimation in ubiquitous computing: A case study. In N. Davies, E. Mynatt, and I. Siio, editors, Proc. of UbiComp, Heidelberg: Springer–Verlag, pages 88–106, 2004.
T. Imielinski and B. Badrinath. Querying in highly mobile distributed environments. In Proc. of VLDB, Vancouver, CA, pages 41–52, 1992.
G. J. F. Jones and P. J. Brown. Context-aware retrieval for ubiquitous computing environments. In Proc. of the Mobile HCI Workshop on Mobile and Ubiquitous Information Access, Springer, pages 227–243, 2004.
W. Jonker. XML and secure data management in an ambient world. Computer Systems Science and Engineering, 18(5):311–317, September 2003.
T. Kindberg, A. Sellen, and E. Geelhoed. Security and trust in mobile interactions: A study of users perceptions and reasoning, N. Davies, E. Mynatt, and I. Siio (eds.), Proc. of UbiComp, Heidelberg: Springer–Verlag, pages 196–213, 2004.
K. Koile, K. Tollmar, D. Demirdjian, H. Shrobe, and T. Darell. Activity zones for context-aware computing. In Proc. of Ubicomp, pages 90–106, 2003.
P. Korpipaa, M. Koskinen, J. Peltola, S. Makela, and T. Seppanen. Bayesian approach to sensor-based context awareness. Personal Ubiquitous Computing, 7(2):113–124, 2003.
V. Kumar and M. Dunham. Defining location data dependency, transaction mobility and commitment. Technical Report 98-CSE-01, Southern Methodist University, USA, 1998.
M. Lamming, P. Brown, K. Carter, M. Eldridge, M. Flynn, G. Louie, P. Robinson, and A. Sellen. The design of a human memory prosthesis. The Computer, 37(3):153–163, 1994.
M. Lamming and M. Flynn. Forget-Me-Not: Intimate computing in support of human memory. In Proc. of the Intl. Symposium on next Generation Human Interface, pages 125–128, Japan, 1994.
I. Lazaridis, Q. Han, X. Yu, S. Mehrotra, N. Venkatasubramanian, D. V. Kalashnikov, and W. Yang. Quasar: Quality aware sensing architecture. ACM SIGMOD Record, 33(1):26–5, 2004.
U. Leonhardt and J. Magee. Security considerations for a distributed location service. Journal of Network and Systems Management, 6(1):51–70, 1998.
A. Y. Levy. Logic-based techniques in data integration, Logic-based artificial intelligence. Kluwer Academic Publishers, MA, USA, pages 575–595, 2000.
H. A. Lieberman and T. Selker. Out of context: computer systems that adapt to, and learn from, context. IBM Systems Journal, 39(3–4):617–632, 2000.
E. Liikanen. Ambient intelligence in future EU research efforts. News, http://www.ercim.org/publication/Ercim_News/enw47/keynote.html, October 2003.
B. Meyers and A. Kern. <context-aware> schema </context-aware>. In Proc. of the CHI Workshop on The What, Who, When, Where, Why, and How of Context-Awareness, 2000.
W. M. Newman, M. Eldridge, and M. Lamming. Pepys: Generating autobiographies by automatic tracking. In Proc. of the 2nd European Conf. on Computer-Supported Cooperative Work, pages 175–188, 1991.
T. S. Raghu, P. K. Kannan, H. R. Rao, and A. B. Whinston. Dynamic profiling of consumers for customized offerings over the internet: A model and analysis. Decision Support Systems, 32(2):117–134, 2001.
A. Ranganathan, J. Al-Muhtadi, and R. H. Campbell. Reasoning about uncertain contexts in pervasive computing environments. IEEE Pervasive Computing, 3(2):62–70, 2004.
B. J. Rhodes and T. Starner. Remembrance agent – a continuously running automated information retrieval system. In Proc. of the 1st Intl. Conf. on the Practical Application of Intelligent Agents and Multi Agent Technology, pages 487–495, 1996.
M. Satyanarayanan. Accessing information on demand at any location: Mobile information access. IEEE Personal Communications, 3(1):26–33, 1996.
M. Satyanarayanan. Pervasive computing, vision and challenges. IEEE Personal Communications, 6(8):11–17, August 2001.
M. Satyanarayanan. Pervasive computing: Vision and challenges. IEEE Personal Communications, 8:10–7, 2001.
K. Saywitz, G. Bornstein, and E. Geiselman. Effects of cognitive interviewing and practice on children’s recall performance. Applied Psychology, 77(5):3–15, 1992.
A. Schmidt. There is more to context than location. Computers and Graphics Journal, 23(6):893–901, 1999.
A. Seydim, M. Dunham, and V. Kumar. An architecture for location dependent query processing. In Proc. of DEXA, Muich, Germany, pages 549–555, September 2001.
A. Seydim, M. Dunham, and V. Kumar. Location dependent query processing. In Proc. of the 2nd ACM Intl. Workshop on Data Engineering for Wireless and Mobile Access (MobiDE01), Canada, USA, pages 47–53, May 2001.
T. Strang. A context modeling survey. In Proc. of UbiComp Workshop on Advanced Context Modelling, Reasoning and Management, 2004.
D. Tennenhouse. Proactive computing. Communications of the ACM, 43(5):43–50, 2000.
H. ter Horst, M. van Doorn, N. Kravtsova, W. ten Kate, and D. Siahaan. Context-aware music selection using knowledge on the semantic web. In Proc. of the 14th Fourteenth Belgium-Netherlands Conference on Artificial Intelligence, pages 131–138, 2002.
E. Tulving. Elements of Episodic Memory. Oxford University Press, 1983.
M. Weiser. The computer for the 21st century. Scientific American, 165(3):94–104, 1991.
J. Xu and D. Lee. Querying location-dependent data in wireless cellular environments. In Proc. of the WAP Forum/W3C Workshop on Position Dependent Information Services, France: Sophia Antipolis, February 2000.
B. Zheng and D. Lee. Processing location-dependent queries in a multi-cell wireless environments. In Proc. of the 2nd ACM Intl. Workshop on Data Engineering for Wireless and Mobile Access (MobiDE01), Canada, USA, pages 54–6, May 2001.