A Context-Aware Preference Database System

Transcription

1 J. PERVASIVE COMPUT. & COMM. (), MARCH 005. TROUBADOR PUBLISHING LTD) A Context-Aware Preferene Database System Kostas Stefanidis Department of Computer Siene, University of Ioannina,, [email protected] Evaggelia Pitoura Department of Computer Siene, University of Ioannina,, [email protected] Panos Vassiliadis Department of Computer Siene, University of Ioannina,, [email protected] Reeived: January XX 005; revised: November XX 005 Abstrat A ontext-aware system is a system that uses ontext to provide relevant information or servies to its users. While there has been a variety of ontext middleware infrastrutures and ontext-aware appliations, little work has been done on integrating ontext into database management systems. In this paper, we onsider a preferene database system that supports ontext-aware queries, that is, queries whose results depend on the ontext at the time of their submission. We propose using data ubes to store the dependenies between ontext-dependent preferenes and database relations and OLAP tehniques for proessing ontext-aware queries. This allows for the manipulation of the aptured ontext data at various levels of abstration, for instane, in the ase of a ontext parameter representing loation, preferenes an be expressed for example at the level of a ity, the level of a ountry or both. To improve query performane, we use an auxiliary data struture, alled ontext tree. The ontext tree stores results of past ontext-aware queries indexed by the ontext of their exeution. Finally, we outline the implementation of a prototype ontext-aware restaurant reommender. Index Terms ontext, preferene, OLAP, ontext-awareness, querying proessing I. INTRODUCTION Context is any information that an be used to haraterize the situation of an entity. An entity is a person, plae or objet that is onsidered relevant to the interation between a user and an appliation, inluding the user and the appliation themselves []. There are various types of ontext inluding time, loation, and available omputing and ommuniation resoures. A system is ontext-aware, if it uses ontext to provide relevant information and/or servies to the user, where relevany depends on the user s task. Although there has been a lot of work on developing a variety of ontext infrastrutures and ontext-aware middleware and appliations (for example, the Context Toolkit [] and the Dartmouth Solar System [3]), there has been only little work on integrating ontext information into databases. Most of this work has foused on a partiular type of ontext, that of loation, mainly in the ontext of moving objet databases. In this paper, we investigate the use of ontext in relational database management systems. We onsider ontext-aware queries whih are queries whose results depend on the ontext at the time of their submission. In partiular, users express their preferenes on speifi attributes of a relation. Suh Fig.. Restaurant(rid, name, phone, region, uisine) User(uid, name, phone, address, ) The database shema of our running example. preferenes depend on ontext, that is, they may have different values depending on ontext. We model ontext as a finite set of speial-purpose attributes, alled ontext parameters. Examples of ontext parameters are loation, weather and the type of omputing devie in use. A ontext state is an assignment of values to ontext parameters. Users express their preferenes on speifi database instanes based on a single ontext parameter. Suh basi preferenes, i.e., preferenes assoiating database relations with a single ontext attribute, are ombined to ompute aggregate preferenes that inlude more than one ontext parameter. As an example, onsider a database shema with information about restaurants and users (Fig. ). In this appliation, we onsider two ontext parameters as relevant: loation and weather. Users have preferenes about restaurants that they express by providing a numerial sore between 0 and that quantifies their degree of interest for a restaurant. The degree of interest of a user for a restaurant depends on the values of the two relevant ontext parameters. For instane, a user may want to eat different kinds of food depending on the urrent weather onditions. For example, user Mary may give to restaurant Zoloushka that serves Russian food a higher sore when the weather is rainy than when the weather is sunny. Furthermore, the urrent user s loation affets the result of a query, for example, a user may prefer restaurants that are nearby her urrent loation. The user provides suh preferene sores that depend on a single ontext parameter, in this example, preferene sores that depend on loation and preferene sores that depend on weather. These basi preferenes are then ombined to produe an aggregate sore that depends on more than one ontext parameter. In addition, a user an speify preferenes without giving values for all ontext parameters. In partiular, the speial value * for a ontext parameter denotes that the user preferene does not depend on it. We store simple preferenes in data ubes, following the

2 J. PERVASIVE COMPUT. & COMM. (), MARCH 005. TROUBADOR PUBLISHING LTD) OLAP paradigm. An advantage of using ubes and OLAP tehniques is that they provide the apability of using hierarhies to introdue different levels of abstration for the aptured ontext data. For instane, this allow us to aggregate data along say the loation ontext parameter, by for example, grouping preferenes for all ities of a speifi ountry. We show how ontext-aware preferene queries are proessed and the role of OLAP tehniques in their manipulation. Aggregate preferenes are not expliitly stored. To improve performane, we propose storing aggregate preferenes omputed as results of previous queries using an auxiliary data struture alled ontext tree. A path in the ontext tree orresponds to an assignment of values to ontext parameters, that is, to a ontext state, for whih the aggregate sore has been previously omputed. Results stored in a ontext tree are re-used to speed-up query proessing. We also show how searh in the ontext tree an be improved using a variation of a Bloom-based filter for testing membership in the tree. As a proof-of-onept, we have implemented a simple appliation that allows users to express their preferenes regarding our running example of a restaurant database. These preferenes depend on two ontext parameters, loation and weather. Users an pose preferene queries whose results depend on ontext. Contributions. Summarizing, we make the following ontributions: We provide a logial model for the representation of user preferenes and ontext-related information. The impat of ontext information on the evaluation of user preferenes is expliitly traed. We demonstrate how our model an be integrated in a relational DBMS using data ubes for storing ontextdependent preferenes. We investigate the usage of On-Line Analytial Proessing (OLAP) tehniques for the manipulation of ontextaware query operations. We propose a speial data struture termed ontext tree for storing previously omputed aggregate sores that indexes these results based on the ontext parameters. Paper Organization. The rest of this paper is strutured as follows. Setion II introdues our preferene model, while Setion III fouses on how preferenes are stored. Setion IV disusses query proessing in our framework. Setion V introdues the ontext tree for storing aggregate preferenes. Our prototype implementation is outlined in Setion VI, while related work is presented in Setion VII. Setion VIII onludes the paper with a summary of our ontributions. II. A LOGICAL MODEL FOR CONTEXT AND USER PREFERENCES Our model is based on relating ontext and database relations through preferenes. First, we present the fundamental onepts related to ontext modeling. Then, we proeed to define user preferenes. A. Modeling Context The modeling of ontext relies on several fundamental onepts. As usual, domains represent the available types and olletions of values of the system. Context parameters refer to the available set of attributes that the database designer will hose to represent ontext. At any point in time, a ontext state refers to an instantiation of the ontext parameters at this point. Context parameters are extended with OLAP-like hierarhies, in order to enable a riher set of query operations to be applied over them. Domains. A domain is an infinitely ountable set of values. All domains are enrihed with a speial value for representing NULL, the semantis of whih refers to our lak of knowledge. Attributes and Relations. As usual, we assume a ountable olletion of attribute names. Eah attribute A i is haraterized by a name and a domain dom(a i ). A relation shema is a finite set of attributes and a relation instane is a finite subset of the Cartesian produt of the domains of the relation shema [4]. Context Parameters. Context is modeled through a finite set of speial-purpose attributes, alled ontext parameters ( i ). For a given appliation X, we define its ontext environment C X as a set of n ontext parameters {,,..., n }. Context State. In general, a ontext state is an assignment of values to ontext parameters. The ontext state at time instant t is a tuple with the values of the ontext parameters at time instant t, CS X (t) = { (t), (t),... n (t)}, where i (t) is the value of the ontext parameter i at timepoint t. For instane, assuming loation and weather as ontext parameters, a ontext state an be: CS(urrent) = {Aropolis, sunny}. Hierarhies for Attributes. It is possible for an attribute to partiipate in an assoiated hierarhy of levels of aggregated data i.e., it an be viewed from different levels of detail. Formally, an attribute hierarhy is a lattie of attributes alled levels for the purpose of the hierarhy L = (L,..., L m, ALL). We require that the upper bound of the lattie is always the level ALL, so that we an group all the values into the single value all. The lower bound of the lattie is alled the detailed level of the parameter. For instane, let us onsider the hierarhy loation of Fig.. Levels of loation are Region, City, Country, and ALL. Region is the most detailed level. Level ALL is the most oarse level for all the levels of a hierarhy. Aggregating to the level ALL of a hierarhy ignores the respetive parameter in the grouping (i.e., pratially groups the data with respet to all the other parameters, exept for this partiular one). The relationship between the values of the ontext levels is ahieved through the use of the set of an L L funtions. A funtion an L L assigns a value of the domain of L to a value of the domain of L. For instane, an City Region (Aropolis) = Athens. A formal definition of these hierarhies an be found in [5]. Dynami and Stati Context Parameters. We distinguish between two kinds of ontext parameters: (a) stati and (b) dynami ontext parameters. Stati ontext parameters take

3 STEFANIDIS, PITOURA, VASSILIADIS: A CONTEXT-AWARE PREFERENCE DATABASE SYSTEM 3 ALL all Country City Athens Region Aropolis Kifisia Fig.. Hierarhies on loation. Ioannina Perama TABLE I NOTATIONS Name Notation Attribute A i Domain of A i dom(a i) Context parameter i Context environment for an appliation X C X Context state at time instant t CS(t) Weight for a ontext parameter i w i as value a simple value out of their domain. Dynami ontext parameters on the other hand, are instantiated by the appliation of a funtion, the result of whih is an instane of the domain of the ontext parameter. In our example, we assume that weather is a stati parameter, i.e., eah new value for weather is derived by an expliit update. On the other hand, loation is a dynami parameter. In partiular, loation is defined as a funtion of time and in that way, we an ompute the value of this parameter at the point we want to use it, without the need for ontinuous expliit updates. Defining appropriate funtions and proedures for determining the value of a dynami ontext parameter in the urrent or some future time instant is beyond the sope of this paper. There has been related work in the ontext of managing the loation of moving objets [6]. B. Contextual Preferenes In this setion, we define how a ontext state affets the results of a query. In our model, eah user expresses his/her preferene by providing a numerial sore between 0 and [7]. This sore expresses a degree of interest, whih is a real number. Value indiates extreme interest. In reverse, value 0 indiates no interest for a preferene. The speial value for a preferene means that there is a user s veto for the preferene. Furthermore, the value represents that any value is aeptable. More speifially, we divide preferenes into basi (onerning a single ontext parameter) and aggregate ones (onerning a ombination of ontext parameters): ) Basi Preferenes: Eah basi preferene is desribed by (a) a ontext parameter i, (b) a set of non-ontext parameters A i, and () a degree of interest, i.e., a real number between 0 and. So, for the ontext parameter i, we have: preferene basii ( i, A k+,..., A n ) = interest sore i. In our referene example (Fig ), there are two ontext parameters, loation and weather. Also, the set of non-ontext parameters are attributes about restaurants and users. Assume a user Mary and a restaurant alled BeauBrummel loated near Aropolis in Athens that serves F renh uisine. M ary likes to eat F renh uisine when the weather is loudy, so she assigns high sores to BeauBrummel when she is in Aropolis and the weather is loudy expressed by the following basi preferenes: preferene basi (Aropolis, BeauBrummel, Mary) = 0.8, preferene basi (loudy, BeauBrummel, Mary) = 0.9. ) Aggregate preferenes: Eah aggregate preferene is derived from a ombination of basi preferenes. The aggregate ALL L... L Fig. 3. The hierarhy tree for parameter L. preferene is expressed by a set of ontext parameters i and a set of non-ontext parameters A i and has a degree of interest: preferene(,... k, A k+,..., A n ) = interest sore. The interest sore of the aggregate preferene is a value funtion of the individuals sores (the degrees of the basi preferenes). The value funtion presribes how to ombine basi preferenes to produe the aggregate sore, aording to the user s profile. In this paper, we assume that value funtions are based on a weighted average of the simple preferenes. Users define in their profile how the basi sores ontribute to the aggregate ones, by giving a weight to eah ontext parameter. So, if the weight for a ontext parameter is w i and interest sore i is the sore defined by the assoiated basi preferene, then the aggregate interest sore will be: interest sore = w interest sore w k interest sore k. For instane, in the previous example if the weight of loation is 0.6 and the weight of weather is 0.4, the preferene has sore: = 0.84 (from the above value funtion). That is, we have: pref erene(aropolis, loudy, BeauBrummel, M ary) = Table I summarizes all notations used in our model. C. Inheriting Preferenes When the ontext parameter of a basi preferene partiipates in different levels of a hierarhy, users an express their preferene in any level, as well in more than one level. For example, M ary an denote that the restaurant Beau Brummel has interest sore 0.8 when she is at Kifisia and 0.6 when she is in Athens. Note that in the hierarhy of loation the ity of Athens is one level up the region of Kifisia. The tree of Fig. 3 represents the different levels of hierarhy for a ontext parameter. For the parameter L, let L, L,..., L m, ALL be the different levels of the hierarhy, whih an take various different values. There is a hierarhy tree, for

4 4 J. PERVASIVE COMPUT. & COMM. (), MARCH 005. TROUBADOR PUBLISHING LTD) Aropolis Athens all Ioannina Salonia Kifisia Cyprus Perama User Fig. 5. Loation User Restaurants Restaurants Data ubes for eah ontext parameter. Weather Fig. 4. The hierarhy tree of loation. eah ombination of non-ontext parameters. In our referene example (Fig. 4), there is a hierarhy tree for eah user profile and for a speifi restaurant that represents the interest sores of the user for the restaurants, aordingly to the ontext parameter s hierarhy. The root of the tree onerns level ALL with the single value all. The values of a ertain dimension level L are found in the same level of the tree (e.g., Athens and Ioannina, being both members of the dimension level City, are found at the same level of the tree in Fig. 4). The anestor relationships an L L are translated to parent-hild relationships in the tree (e.g., the node is the parent of the node Athens). Eah node is haraterized by a sore value for the preferene onerning the ombination of the non-ontext attributes with the ontext value of the node. If the query onditions refer to a level of the tree in whih there is no expliit sore given by the user, we propose three ways to find the appropriate sore for a preferene. In the first approah, we traverse the tree upwards until we find the first predeessor for whih a sore is speified. In this ase, we assume that, a user that defines a sore for a speifi level, impliitly defines the same sore for all the lower levels. In the seond approah, we ompute the average sore of all the suessors of the immediately lower level. Finally, following a hybrid approah, we an ompute a weighted average sore ombining the sores from both the predeessor and the suessors. In any of the above ases, if no sore is defined at any level of the hierarhy, there is a default sore of 0.5 for value all. Take for example, Fig. 4 that depits a hierarhy for a user (Mary) and a restaurant (BeauBrummel). So, for instane the restaurant Beau Brummel has sore 0.8 when Mary is near Aropolis, 0.7 when she is in Kifisia, and 0.9 when she is in Ioannina. The root of the hierarhy has the default sore 0.5. These degrees of interest sores, exept the last one, have been expliitly defined by the user in her profile. If the query onditions refer to Athens, for whih there is no sore, the first approah gives sore 0.5, beause this is the first available predeessor s sore. If we hoose the seond approah, this leads to sore ( )/ = 0.75, while the third one produes a weighted ombination of the above sores. D. Disussion To failitate the proedure of expressing interests, the system may provide sets of pre-speified profiles with speifi ontext-dependent preferene values for the non-ontext parameters as well as default weights for omputing the aggregate sores. In this ase, instead of expliitly speifying basi and aggregate preferenes for the non-ontext parameters, users may just selet the profile that best mathes their interests from the set of the available ones. By doing so, the user adopts the preferenes speified by the seleted profile. Finally, sine the fous of this work is on effiiently ombining preferenes and database operations, our working assumption is that preferenes are expliitly speified by users. Alternatively, preferenes may be dedued by the previous behavior of the user, for instane by using data mining tehniques on the history of the user database aesses. The issue of impliitly inferring preferenes is orthogonal to the work presented in this paper. There has been some previous work on the topi [8], that an be integrated in our approah. III. THE STORAGE MODEL In this setion, we disuss the implementation of our ontext model in relational DBMS strutures. First, we disuss the storage of preferenes and then the storage of attribute hierarhies. A. Storing Basi Preferenes There is a straightforward way to store our ontext and preferene information in the database. We organize preferenes as data ubes, following the OLAP paradigm [5]. In partiular, we store basi user preferenes in hyperubes, or simply, ubes. The number of data ubes is equal with the number of ontext parameters, i.e., we have one ube for eah parameter, as shown in Fig. 5. In eah ube, there is a dimension for restaurants, a dimension for users and a dimension for the ontext parameter. In eah ell of the ube, we store the degree of interest for a speifi preferene. This way, we maintain the sore for a user, a restaurant and a ontext parameter. Formally, a ube is defined as a finite set of attributes C = ( i, A,..., A n, M), where i is a ontext parameter, A,..., A n are non-ontext attributes and M is the interest sore. The values of a ube are the values of the orresponding preferene rules. A relational table implements suh a ube in a straightforward fashion. The primary key of the table is i, A,...,A n. If there exist dimension tables representing hierarhies (see next), we employ foreign keys for the attributes orresponding to these dimensions. Our shema whih is based on the lassial star shema is depited in Fig. 6. As we an see, there are two fat tables,

5 STEFANIDIS, PITOURA, VASSILIADIS: A CONTEXT-AWARE PREFERENCE DATABASE SYSTEM 5 Users uid name phone address e mail Fat_Weather rid uid weather sore Fat_Loation rid uid lid sore Restaurants rid name phone region uisine Loation lid ountry Fig. 6. The two fat tables of our shema (one for eah ontext parameter) and the dimension tables for Users and Restaurants. F at Loation and F at W eather. The dimension tables are: U sers and Restaurants. These are dimension tables for both fat tables. B. Storing Context Hierarhies An advantage of using ubes to store user preferenes is that they provide the apability of using hierarhies to introdue different levels of abstrations of the aptured ontext data [9]. In that way, we an have a hierarhy on a given ontext dimension. Context dimension hierarhies give the opportunity to the appliation to use a ombination of data between the fat and the dimension tables on one of the ontext parameters. The typial way to store data in databases is shown in Fig. 7 (left). In this modeling, we assign an attribute for eah level in the hierarhy. We also assign an artifiial key to effiiently implement referenes to the dimension table. The ontents of the table are the values of the an L L funtions of the hierarhy. The denormalized tables of this kind, partiipating in a database shema (often alled a star shema) suffer from the fat that there exists exatly one row for eah value of the lowest level of the hierarhy, but no rows expliitly representing values of higher levels of the hierarhy. Therefore, if we want to express preferenes at a higher level of the hierarhy, we need to extend this modeling (assume for example that we wish to express the preferenes of Mary when she is in Cyprus, independently of the speifi region, or ity of Cyprus she is found at). To this end, in our model, we use an extension of this approah, as shown in the right of Fig. 7. In this kind of dimension tables, we introdue a dediated tuple for eah value at any level of the hierarhy. We populate attributes of lower levels with N U LLs. To explain the partiular level that a value partiipates at, we also introdue a level indiator attribute. Dimension levels are assigned attribute numbers through a topologial sort of the lattie. C. Storing the Value Funtions The omputation of aggregate preferenes refers to the omposition of simple basi preferenes, in order to ompute the aggregate ones. The tehnique used for this involves using weights for eah of the parameters. Eah aggregate preferene involves (a) a set of k ontext parameters -i.e., ubes and (b) a ity region G_ID Region City Country 3 Fig. 7. Aropolis Kefalari Perama Athens Athens Ioannina G_ID Region City Country Aropolis Kefalari Polihni NULL NULL NULL NULL Athens Athens Salonia Athens Salonia NULL NULL Cyprus A typial (left) and an extended dimension table (right). set of n non-ontext parameters, ommon to all ontext ubes: preferene(,... k, A k+,..., A n ) = interest sore The non-ontext parameters pin the values of the aggregate sores to speifi numbers and then, the individual sores for eah ontext parameter are olleted from eah ontext table. Reall that the formula for omputing an aggregate preferene is: interest sore = w interest sore w k interest sore k. Therefore, the only extra information that needs to be stored onerns the weights employed for the omputation of the formula. To this end, we employ a speial purpose table AggSores(w,...,w k, A k+,...,a n ). The value for eah ontext parameter w i is the weight for the respetive interest sore and the value for eah non-ontext attribute A j is the speifi value uniquely determining the aggregate preferene. For instane, in our running example, the table AggSores has the attributes Loation weight, W eather weight and U ser and Restaurant. A reord in this table an be (0.6, 0.4, Mary, Beau Brummel). Assume that from Mary s profile, we know that Beau Brummel has interest sore at the urrent loation 0.8 and at the urrent weather 0.9, then, the aggregate sore is: = D. Storing Aggregate Preferenes Aggregated preferenes are not expliitly stored in our system. The main reason is spae and time effiieny, sine this would require maintaining a ontext ube for eah ontext state and for eah ombination of non-ontext attributes. Assume that the ontext environment C X has n ontext parameters {,,..., n } and that the ardinality of the domain dom( i ) of eah parameter i is (for simpliity) m. This means that there are m n potential ontext states, leading to a very large number of ontext ubes and prohibitively high osts for their maintenane. Note that some of the m n ontext states may not be useful, sine they may orrespond to ombinations of values of ontext parameters that represent ontext states that are not valid or have a very small probability of being queried. Furthermore, some ontext parameters or ontext states may be more popular for some non-ontext parameters (e.g., users) than for others, thus making the storage of all states for all non-ontext parameters unjustifiable. Finally, retrieving speifi entries of suh ubes is not very effiient, sine it would require building and maintaining indexes on various ombinations of the ontext parameters. For these reasons, we hoose to store only previously omputed aggregate sores. We also propose using an auxiliary data struture that we all the ontext tree to index them (desribed in Setion V). Level 3 3

6 6 J. PERVASIVE COMPUT. & COMM. (), MARCH 005. TROUBADOR PUBLISHING LTD) IV. QUERYING CONTEXT In this setion, we lassify the query operations that an be posed to our ontext-aware DBMS, by exploiting the ombined information on preferenes and ontext. A. Queries with Basi Preferenes Firstly, there are queries exeuted without the need for the omputation of an aggregate sore. In this ategory of queries, users expliitly define that they are not interested in speifi ontext parameters. For example, the following query omputes the users preferenes diretly. Query Look for Mary s most preferable restaurants near Aropolis, independently of the status of weather. In SQL, the query is: SELECT R.name, F L.sore FROM Users U, Restaurants R, F at Loation FL, Loation L WHERE U.uid = F L.uid AND R.rid = F L.rid AND L.lid = FL.lid AND U.name = Mary AND L.loation = Aropolis ORDER BY FL.sore DESC; Another similar query would be Look for the users near Aropolis that prefer restaurant Beau Brummel independently of weather that may be used for instane to advertise a speifi restaurant to the visitors of Aropolis. B. Queries with Aggregate Preferenes Another type of queries involves the omputation of aggregate sores from simple ones. For example, the following query needs to ompute an aggregate sore: Query Look for Mary s most preferable restaurants (in the urrent ontext). The exeution of Query leads to the exeution of the following subqueries (we suppose that CS(urrent) = {Aropolis, sunny}): SELECT R.name, F L.sore FROM Users U, Restaurants R, F at Loation FL, Loation L WHERE U.name = Mary AND U.uid = FL.uid AND R.rid = F L.rid AND L.lid = F L.lid AND urrent loation = Aropolis ; and SELECT R.name, F W.sore FROM Users U, Restaurants R, Fat Weather FW WHERE U.name = Mary AND U.uid = FW.uid AND R.rid = FW.rid AND urrent weather = sunny ; Using the results of subqueries, we alulate the aggregate sores for restaurants using the value funtion, as desribed above. In this ase, we obtain the most preferable Mary s restaurants. C. Computing Aggregate Sores The tehnique used for proessing queries involving aggregate sores (e.g., Query above) is the following. ) First, we selet speifi values for Users and for the ontext parameter. For instane, for the first ube a seletion ould be on a value of loation, e.g., Aropolis and for a value of user, e.g., Mary. ) Seond, having pinned all dimension attributes to a speifi value, we have all the preferene interest sores available. In fat, the individual sores for eah ontext parameter are olleted from eah ontext table (although this pratially involves a relational join on all non-ontext parameters, it is quite more easy to simply ollet the values from the respetive ubes from a set of point queries over them). So, we an ompute the aggregate sore of a preferene by using a value funtion (as desribed in the previous setions). 3) In the ontext of an OLAP session, the aggregate sores just omputed for a user an be stored in a new transient ube. As with ubes onerning basi preferenes, a ube onerning aggregate preferenes has one attribute for eah ontext and non-ontext parameter and an extra attribute for the interest sore. Then, the user an reuse the result of a query, by just using the last ube, without exeuting all the above steps. In Setion V, we desribe a spae-effiient struture for storing suh results. D. Traditional OLAP operators OLAP provides a prinipled way of querying information. The traditional tehniques for relational querying are enrihed with speial purpose query operators, suh as roll-up and drill-down [0], [5]. Slie-n-Die. The die operator on a data set orresponds to a seletion (in the relational sense) of values on eah dimension. A slie is a seletion on one of the N dimensions of the ube. A die operator an be implemented as a sequene of slies. Simple preferene queries an be omputed using slie operators. For instane, Query an be implemented using slie operations on User and Loation. Roll-up. The roll-up operation provides an aggregation on one dimension. Assume that the user has exeuted Query over the database and reeives an unsatisfatory small number of answers. Then, she an deide that is worth broadening the sope of the searh and investigate the broader Athens area for interesting restaurants. In this ase, a roll-up operation on loation an generate a ube that uses ities instead of regions. The following query express this roll-up operation in SQL: Query 3 SELECT R.name, F L.sore FROM Users U, Restaurants R, F at Loation FL, Loation L WHERE U.uid = F L.uid AND R.rid = F L.rid AND L.lid = FL.lid AND U.name = Mary AND

7 STEFANIDIS, PITOURA, VASSILIADIS: A CONTEXT-AWARE PREFERENCE DATABASE SYSTEM 7 L.ity = Athens ORDER BY FL.sore DESC; Drill-down. Similarly, drill-down is the reverse operation, i.e., when we have the result of a query whih inludes restaurants that are loated in Athens, we an take a result that inludes restaurants loated at Aropolis, using the drill-down operator. V. CACHING CONTEXT STATES In this setion, we disuss issues regarding improving the performane of our system. In partiular, we disuss how we an store (ahe) results about previous queries exeuted at a speifi ontext, so that these results an be re-used. First, we desribe a hierarhial data struture, alled ontext tree, that is used to index these results. Then, we show how searh in this data struture an be improved using an additional hashbased index to test for membership in the ontext tree. A. The Context Tree Assume that the ontext environment C X has n ontext parameters {,,..., n }. An alternative way to store aggregate preferenes uses a ontext tree, as shown in Fig. 8. The ontext tree is used to store aggregate preferenes that were omputed as results of previous queries, so that these results an be re-used by subsequent ones. There is one ontext tree per user or per system-defined profile (i.e., per group of users with similar interests, see Setion II-D). The maximum height of the ontext tree is equal to the number of ontext parameters plus one. Eah ontext parameter is mapped onto one of the levels of the tree and there is one additional level for the leaves. For simpliity, assume that ontext parameter i is mapped to level i. A path from the root to a leaf of the ontext tree orresponds to a ontext state, i.e., an assignment of values to ontext parameters. At the leaf nodes, we store a list of ids, e.g., restaurant ids, along with their aggregate sores for the assoiated ontext state, that is, for the path from the root leading to them. Instead of storing aggregate values for all non-ontext parameters, to be storage-effiient, we just store the top-k ids (keys), that is the ids of the items having the k-highest aggregate sores for the path leading to them. The motivation is that this allows us to provide users with a fast answer with the data items that best math their query. Only if more than k-results are needed, additional omputation will be initiated. The list of ids is sorted in dereasing order aording to their sores. The ontext tree is onstruted inrementally eah time a ontext-aware query is omputed. Eah non-leaf node at level k ontains ells of the form [key, pointer], where key is equal to kj dom( k ) for a value of the ontext parameter k that appeared in some previously omputed ontext query. The pointer of eah ell points to the node at the next lower level (level k + ) ontaining all the distint values of the next ontext parameter (parameter k+ ) that appeared in the same ontext query with kj. In addition, key may take the speial value any, whih orresponds to the lak of the speifiation of the assoiated ontext parameter in the query. Fig any 3 any 3 5 any any n n3 n A ontext tree. n top_k list {(id, sore)} For example, assume two ontext parameters, loation and weather and that weather is assigned to level m of the tree and loation to the level just below it, level m +. Then, take for instane a query, where the user speifies weather = loudy, but gives no value for loation. Then, there will be a ell [loudy, pointer] at level m pointing to a node at level m+ ontaining a ell [any, pointer]. Initially, the ontext tree is empty, that is the root node ontains a single ell of the form [any, null]. The way that the ontext parameters are assigned to the levels of the ontext tree affets its size. As a simple heuristi, ontext parameters are assigned to levels based on the ardinality of their domains: the smaller the number of distint values a ontext parameter takes, the higher it appears in the ontext tree. In summary, a ontext tree for n ontext parameters satisfies the following properties: It is a direted ayli graph with a single root node. There are at most n+ levels, eah one of the first n of them orresponding to a ontext parameter and the last one to the level of the leaf nodes. Eah non-leaf node at level k maintains ells of the form [key, pointer] where key dom( k ) for some value of k that appeared in a query or key = any. No two ells within the same node ontain the same key value. The pointer points to a node at level k + having ells with key values whih appeared in the same query with the key. Eah leaf node stores a set of sorted pointers to data. In Fig. 9, we present a set of ontext preferenes as expressed in four previously submitted queries. Assume again that we have two ontext parameters, weather and loation and for the sake of the example that weather is assigned to the first level of the tree and loation to the next one. Leaf nodes store the ids of the top-k restaurants, that is the restaurants with the top-k highest aggregate sores. For these preferene queries, the ontext tree of Fig. 0 is onstruted as follows. For the first preferene (loudy/p laka), the first path of the tree (the leftmost one) is onstruted. The next preferene (loudy/aropolis) has the same value for the ontext parameter weather with the first one, so we do not add any new ell to the root node. Next, we add a ell for Aropolis to the node that the root points to. The third preferene (sunny/p laka) has value sunny for weather and this leads to the reation of a new ell in the root node. As before, the last preferene

8 8 J. PERVASIVE COMPUT. & COMM. (), MARCH 005. TROUBADOR PUBLISHING LTD) query / loudy / Plaka query / loudy / Aropolis query 3 / sunny / Plaka query 4 / loudy / * Element a H (a) = P H (a) = P H (a) = P 3 3 Bit vetor v Fig. 9. A set of aggregate preferenes. H (a) = P 4 4 loudy sunny Fig.. A Bloom filter with f=4 hash funtions. Plaka Aropolis any Plaka top_k top_k top_k top_k Fig. 0. The ontext tree for the preferene of Fig 9. (/loudy/ ) has a loudy value and so, the remaining path for that preferene has as a predeessor the loudy ell of the root. The any ell is added at the orresponding node of the seond level for the operator of this preferene. When a query is issued, we first hek whether there exists a ontext state that mathes it in the ontext tree. If so, we retrieve the top-k results from the assoiated leaf node. Otherwise, we ompute the answer and insert the new ontext state in the tree. There is a number of interesting variations. For instane, instead of storing the results of all queries, we may just store the results of the most frequently requested ones. This an be easily implemented by assoiating a ounter with eah path and replaing (deleting) from the tree the path that is less frequently used. The ontext tree resembles the Dwarf data struture [] used to ompute and store data ubes. Whereas Dwarf is built by sanning the fat table and inludes all existing ombinations of values for all ube dimensions, the ontext tree is inrementally omputed, eah time a preferene query is evaluated and inludes only paths (ontext states) previously queried. Furthermore, Dwarf leaf nodes ontain aggregate values, whereas the ontext tree leaf nodes ontain ordered sets. B. Bloom-Based Index for the Context Tree In order to improve the query performane of the ontext tree, we propose using Bloom filters []. A Bloom filter is a main-memory data struture that supports very effiient membership queries. When a new query for a ontext state is submitted by the user, instead of searhing the ontext tree for a mathing ontext state, the Bloom-based data struture is onduted first. Given a ontext state, the Bloom-based data struture provides a quik answer on whether this state exists in the tree. If the ontext state does not exist, then retrieving the entire ontext tree is avoided. ) Bloom Filters Preliminaries: A Bloom filter is a spaeeffiient probabilisti data struture that is used to test whether or not an element is a member of a set. This method is used for representing a set A = a, a,..., a l of l elements (also alled keys) to support membership queries (is element a in set A?). The idea is to alloate a vetor v of m bits (Fig. ), initially all set to 0, and then hoose f independent hash funtions, h, h,..., h f, eah with range to m. For eah element a, the bits at positions h (a), h (a),..., h f (a) in v are set to. A partiular bit might be set to multiple times, but only the first hange has an effet. Given a query for b we hek the bits at positions h (b), h (b),...,h f (b). If any of them is 0, then ertainly b is not in the set A. Otherwise we onjeture that b is in the set although there is a ertain probability that we are wrong. This is alled a false positive (or a false drop) and it is the payoff for Bloom filters ompatness. The parameters k and f should be hosen suh that the probability of a false positive (and hene a false hit) is aeptable. Although false positives are possible, there are no false negatives. The probability of a false positive for an element not in the set, or the false positive rate, an be alulated in a straightforward fashion, given the assumption that hash funtions are perfetly random. After all the elements of A are hashed into the Bloom filter, the probability that a speifi bit is still 0 is ( /m) f l e f l/m, where m is the size of the Bloom filter, f is the number of hash funtions and l is the number of elements that we index in the filter. In their original form, Bloom filters provided support only for simple keyword queries and not for path queries suh as those representing ontext states. To this end, in our previous work we have introdued multi-level Bloom filters, namely Breadth and Depth Bloom filters [3], [4] to test for membership of path queries. ) Multi-level Bloom Filters: Let a ontext tree T for n ontext parameters and let the level of the root be level. There are two ways to hash the tree, orresponding to its breadth and depth first traversal. The Breadth Bloom Filter (BBF) for a ontext tree T for n ontext parameters is a set of n Bloom filters {BBF, BBF,..., BBF n }, where eah Bloom filter, BBF i, orresponds to an internal (i.e., non leaf) level i of the ontext tree, that is, there is one filter for eah ontext parameter i. In eah BBF i, we insert all keys that appear in ells in nodes at level i of the ontext tree. For example, the BBF for the ontext tree of Fig. 0 is a set of two Bloom filters (Fig. ). Depth Bloom filters provide an alternative way to summarize ontext trees. We use different Bloom filters to hash paths of different lengths. The Depth Bloom Filter (DBF ) for a ontext tree T for n ontext parameters is a set of Bloom filters {DBF 0, DBF, DBF,...,DBF m }, m n. There is one Bloom filter, denoted DBF i, for eah path of the tree with

9 STEFANIDIS, PITOURA, VASSILIADIS: A CONTEXT-AWARE PREFERENCE DATABASE SYSTEM 9 BBF BBF Fig.. The BBF for the ontext tree of Fig 0. loudy OR sunny OR any Plaka OR Aropolis OR any User Input Context Preferenes Query Query Proessing Results Context State DBF 0 0 DBF 0 Paths of length 0 Paths of length Fig. 3. The DBF for the ontext tree of Fig 0. (loudy OR sunny OR Plaka OR Aropolis OR any) (loudy / Plaka OR loudy / Aropolis OR sunny / Plaka OR loudy / any) length i, that is, having (i+) nodes, where we insert all paths of length i. Note that a path with length i < n orresponds to a ontext state in whih there are values speified only for the first i parameters. Note that we insert paths as a whole, we do not hash eah element of the path separately; instead, we hash their onatenation. The DBF for the ontext tree in Fig. 0 is a set of two Bloom filters (Fig. 3). Let a a path a /a /.../a p orresponding to a ontext state with p ontext parameters. In the ase of a BBF, to hek whether a path a /a /.../a p orresponding to a ontext state exists, eah level i from to p of the filter is heked for the orresponding a i. The test is positive, if we have a hit for all elements in the path. In the ase of DBF, we first hek whether all elements in the path expression appear in DBF 0. Then, for a query of length p, every sub-path of the query with length to p is heked at the orresponding level. If we have a math for all sub-paths, then we onlude that the path may exist in the ontext tree, else we have a miss. When omparing the two filters, DBF works better (has a smaller false positive ratio) than BBF [3]. The reason is that when using BBFs, a new kind of false positive appears. Consider the tree of Fig. 0 and the query: sunny/aropolis. We have a math for sunny at BBF and for Aropolis at BBF ; thus we falsely dedue that the path exists. However, DBFs is less spae effiient, sine the number of paths is very large. This the reason, that we may not keep Bloom filters for paths of all lengths but instead we may keep paths up to a maximum length m. VI. PROTOTYPE IMPLEMENTATION: PREFERENCE RESTAURANT GUIDE Figure 4 depits the overall system arhiteture of a preferene database system. The Context-Aware Preferene Database Management System (DBMS) stores both database relations and preferenes that relate the ontext-dependent attributes of the relations with the ontext parameters. To proess ontext-dependent queries, preferenes are taken into aount to present the results based on their preferene sore at the speified ontext state. We assume that the values of the urrent ontext state are provided as input to our system. Fig. 4. Database. Context Aware Preferene DBMS Data Overall system arhiteture of a Context-Dependent Preferene To demonstrate the feasibility of our approah, we have developed a prototype appliation based on our referene example. The appliation is alled Preferene Restaurant Guide and maintains information about restaurants and users. Its shema is the one depited in Fig. 6. We onsider two ontext parameters as relevant: loation and weather. The prototype appliation is build on top of Orale 8i, using Borland JBuilder 7. The prototype implements all modules of our approah exept of the ontext tree. When a user joins the system, she registers her attributes and then, she selets whih ontext parameters she onsiders as relevant. Then, users express their preferenes about restaurants by providing a numerial sore between 0 and. The degree of interest that a user expresses for a restaurant depends on the values of the ontext parameters, she onsiders as relevant. If more than one ontext parameter is defined as relevant, i.e, both loation and weather, weights are speified to express how eah parameter affets the omputation of the aggregate sore. Besides user registration, the other part of the appliation inludes query proessing. Query proessing runs in two modes: ontext-aware and non ontext-aware. In the non ontextaware mode, preferenes are ignored. In the ontext-aware mode, the user speifies the values of the ontext parameters she is interested in, and the results are sorted aording to the user s preferene in the speified ontext state. When no values are speified for the ontext parameters, the default ontext state that orresponds to the urrent ontext state is used. In addition, a user may use an OLAP operator to exeute a roll-up or a drill-down to the results of a query. For example, suppose a result that ontains restaurants loated in the region of Aropolis. A single roll up provides restaurants in the ity of Athens. Suppose that user Mary is at Aropolis and the weather is sunny, i.e., the urrent ontext state is CS(urrent) = {Aropolis, sunny}. M ary would like to know the best restaurants, aording to her preferenes, that are loated at Aropolis, independently of the weather. This is an example of a query involving only basi preferenes. The result of this query is depited in Fig. 5 (left). In Fig. 5 (enter) the results of a query involving aggregate preferenes in the urrent ontext are depited. If M ary hooses to use an OLAP operator to exeute a roll up to the results of the query, the appliation returns the restaurants that are loated in the ity of Athens. The results of this operation are shown Fig. 5 (right).

10 0 J. PERVASIVE COMPUT. & COMM. (), MARCH 005. TROUBADOR PUBLISHING LTD) Fig. 5. The results of a query involving a basi preferene on loation (left), on both loation and weather (enter), and a roll up to inlude results in Athens (right). VII. RELATED WORK Although, there is muh researh on loation-aware query proessing in the area of spatio-temporal databases, integrating other forms of ontext in query proessing is a rather new researh topi. A. Context and Queries In the ontext-aware querying proessing framework of [5], there is no notion of preferenes, instead ontext attributes are treated as normal attributes of relations. Query proessing is divided into three-phases: query pre-proessing, query exeution and query post-proessing. Query preproessing is performed in two steps: a query refinement and a ontext binding step. The goal of the query refinement step is to further onstraint the query ondition by means of different ontextual information. Context binding instantiates the ontextual attributes involved in the refined query with exat values. After query exeution, at the query postproessing phase, the results are sorted. External servies may then be invoked for the delivering of results to the users. Five ontext-aware strategies are defined. Strategy refers to queries that onsider the urrent value of ontext as their referene point, for example suh queries inlude looking for the losest restaurant, the next flight, the shortest route. To implement them, the ontextual attributes are bound to their urrent values. Strategy inludes queries that aess fats about the past (i.e., history data) whih are realled based on the relevant ontext. In this ase, arhived data are linked based on their ommon ontextual attributes. Strategy 3 onsiders ontext as an additional onstraint to the query. A given query is refined to inlude relevant onstraint rules. Strategy 4 redues the result set by ordering the produed results based on the user profile. This is ahieved by using an assoiated sorting rule. Strategy 5 onsiders the delivery and presentation of results to the user by observing related delivery rules. This framework is orthogonal to our approah and a potential extension of our work inludes enrihing our model with onstraints involving ontext attributes. The Context Relational Model (CR) introdued in [6] is an extended relational model that allows attributes to exist under some ontexts or to have different values under different ontexts. CR treats ontext as a first-lass itizen at the level of data models, whereas in our approah, we use the traditional relational model to apture ontext as well as ontext-dependent preferenes. B. Preferenes in Databases In this paper, we use ontext to onfine database querying by seleting as results the best mathing tuples based on the user preferenes. This is ahieved by defining preferenes based on ontext, so that under a speifi ontext a tuple is preferred over another. The researh literature on preferenes is extensive. In partiular, in the ontext of database queries, there are two different approahes for expressing preferenes: a quantitative and a qualitative one. With the quantitative approah, preferenes are expressed indiretly by using soring funtions that assoiate a numerial sore with every tuple of the query answer. In our work, we have adapted the general quantitative framework of [7], sine it is more easy for users to employ. In this framework, a preferene is expressed by the user for an entity. Entities are desribed by reord types whih are sets of named fields, where eah field an take values from a ertain type. The * symbol is used to math any elements of that type. Preferenes are expressed as funtions that map entities of a given reord type to a numerial sore. A set of preferenes an be ombined using a generi ombine operator whih is instantiated with a value funtion. For example, the preferene of a user for restaurants an be expressed as preferene(uisine), with values preferene(chinese) = 0., preferene(greek) = 0.8 and preferene(other) = 0.. In the quantitative framework of [7], user preferenes are stored as degrees of interest in atomi query elements (suh as individual seletion or join onditions) instead of interests in speifi attribute values. The degree of interest expresses the interest of a person to inlude the assoiated ondition into the qualifiation of a given query. Speifi rules are speified for deriving preferene of omplex queries by building on stored atomi ones. The results of a query are ranked based on the estimated degree of interest in the ombination of preferenes they satisfy. Our approah an be generalized for this framework as well, either by inluding ontextual parameters in the atomi query elements or by making the degree of interest for eah atomi query element depend on ontext. There is also some similarity with the work done in the ontext of the PREFER system [8] for proessing ranked

11 STEFANIDIS, PITOURA, VASSILIADIS: A CONTEXT-AWARE PREFERENCE DATABASE SYSTEM queries that is, queries that return the top objets of a database aording to a preferene funtion. The fous of this work is on a different topi: how to answer ranked queries using materialized ranked views. In the qualitative approah (for example, [9]), the preferenes between the tuples in the answer to a query are speified diretly, typially using binary preferene relations. For example, one may express that restaurant is preferred from restaurant if their opening hours are the same and its prie is lower. This framework an also be readily extended to inlude ontext. For instane, one may express that restaurant is preferred from restaurant if their opening hours are the same, its prie is lower and it is loser to the urrent user s loation. A logial qualitative framework is presented in [9] for formulating preferenes as preferene formulas. The preferene formula is a first-order formula defining a preferene relation between two tuples. Both the quantitative and the qualitative approahed an be integrated with query proessing. Relevant in this respet is researh on top-k mathing results and on skylines. In top-k queries [0], users speify target values for ertain attributes, without requiring exat mathes to these values in return. Instead, the result to suh queries is typially a rank of the top-k tuples that best math the given attribute values. The skyline [] is defined as those tuples of a relation that are not dominated by any other tuple. A tuple dominates another tuple if it is as good or better in all dimensions and better in at least one dimension. Finally, the work in [] fouses on indutively onstruting omplex preferenes by means of various preferene onstrutors. C. Storing Context An important issue is what is an appropriate model for storing ontext. Besides storing the urrent ontext for building ontext-aware systems and appliations, there is growing effort to extrat interesting knowledge (suh rules, regularities, onstraints, patterns) from large olletions of ontext data. Storing ontext data using data ubes, alled ontext ubes, is proposed in [9] for developing ontext-aware appliations that use arhive sensor data. The ontext ube provides a multidimensional model of ontext data where eah dimension presents a ontext dimension of interest. The ontext ube also provides a number of tools for aessing, interpreting and aggregating ontext data by using onept relationships defined within the real ontext of the appliation. In this work, data ubes are used to store historial ontext data and to extrat interesting knowledge from olletions of ontext data. Also, a ube an be used to reate new ontext from analysis of the existing data. In our work, we use data ubes for storing ontext-dependent preferenes and answering related queries. Besides queries, ontext parameters, suh as loation and time, have been used to determine whih data to repliate in mobile information systems [3]. In this approah, ontext parameters are alled extensions. Finally, ontext has been used in the area of multidatabase systems to resolve semanti differenes, e.g., [4], [5], [6] and as a general mehanism for partitioning information bases [7]. VIII. SUMMARY The use of ontext is important in many appliations suh as in pervasive omputing where it is important that users reeive only relevant information. In this paper, we onsider integrating ontext with query proessing, so that when a user poses a query in a database, the result depends on ontext. In partiular, eah user indiates preferenes on speifi attribute values of a relation. Suh preferenes depend on ontext. We store preferenes in data ubes and show how OLAP tehniques an be used to ompute ontext-aware queries, that is queries whose results depend on ontext. In order to improve the performane of our system, we introdue a hierarhial data struture, alled ontext tree. We use this tree to index results from previous queries. Finally, we demonstrate the feasibility of our approah through a prototype appliation regarding a ontext-aware preferene restaurant guide. ACKNOWLEDGMENT This work was partially funded by the General Seretariat of Researh and Tehnology of through a grant for supporting bilateral researh ooperations between and Australia (DECA). REFERENCES [] A. K. Dey. Understanding and Using Context. Personal and Ubiquitous Computing, 5(): 4 7, 00. [] D. Salber, A. K. Dey, G. D. Abowd. The Context Toolkit: Aiding the Development of Context-Enabled Appliations. CHI Conferene on Human Fators in Computing Systems, , 999. [3] G. Chen, M. Li, and D. Kotz. Design and implementation of a largesale ontext fusion network. International Conferene on Mobile and Ubiquitous Systems: Networking and Servies, 004. [4] E. F. Codd. A relational model of data for large shared data banks. Communiations of ACM, 3(6): , 970. [5] P. Vassiliadis and S. Skiadopoulos. Modelling and Optimization Issues for Multidimensional Databases. International Conferene on Advaned Information Systems Engineering, , 000. [6] P. Sistla, O. Wolfson, S. Chamberlain and S. Dao. Modeling and Querying Moving Objets. International Conferene on Data Engineering, 4 43, 997. [7] R. Agrawal and E. L. Wimmers. A Framework for Expressing and Combining Preferenes. ACM SIGMOD International Conferene on Management of Data, , 000. [8] S. Chaudhuri, G. Das, V. Hristidis and G. Weikum. Probabilisti Ranking of Database Query Results. International Conferene on Very Large Data Bases, 004. [9] L. Harvel, L. Liu, G. D. Abowd, Y-X. Lim, C. Sheibe and C. Chathamr. Flexible and Effetive Manipulation of Sensed Context. International Conferene on Pervasive Computing, 5 68, 004. [0] J. Gray, S. Chaudhuri, A. Bosworth, A. Layman, D. Reihart, M. Venkatrao, F. Pellow and H. Pirahesh. Data Cube: A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub-Totals. Data Mining and Knowledge Disovery, 997. [] Y. Sismanis, A. Deligiannakis, N. Roussopoulos and Y. Kotidis. Dwarf: Shrinking the PetaCube. ACM SIGMOD International Conferene on Management of Data, 00. [] B. H. Bloom. Spae/time trade-offs in hash oding with allowable errors. Communiations of ACM, 3(7): 4 46, 970. [3] G. Koloniari and E. Pitoura. Bloom-Based Filters for Hierarhial Data. International Workshop on Distributed Data Strutures and Algorithms, 003. [4] G. Koloniari and E. Pitoura. Filters for XML-based Servie. Disovery in Pervasive Computing, 47(4): , 004. [5] L. Feng, P. M. G. Apers and W. Jonker. Towards Context-Aware Data Management for Ambient Intelligene. International Conferene on Database and Expert Systems Appliations, 004.

12 J. PERVASIVE COMPUT. & COMM. (), MARCH 005. TROUBADOR PUBLISHING LTD) [6] Y. Roussos, Y. Stavrakas and V. Pavlaki. Towards a Context-Aware Relational Model. International Workshop on Context Representation and Reasoning, 005. [7] G. Koutrika and Y. Ioannidis. Personalization of Queries in Database Systems. International Conferene on Data Engineering, 004. [8] V. Hristidis and Y. Papakonstantinou. Algorithms and appliations for answering ranked queries using ranked views. Very Large Data Bases, 3(): 49 70, 004. [9] J. Chomiki. Preferene Formulas in Relational Queries. ACM Transations on Database Systems, 8(4): , 003. [0] S. Chaudhuri and L. Gravano. Evaluating Top-k Seletion Queries. International Conferene on Very Large Data Bases, , 999. [] S. Bfrzsfnyi, D. Kossmann and K. Stoker. The Skyline Operator. International Conferene on Data Engineering, 4 430, 00. [] W. Kiesling. Foundations of Preferenes in Database Systems. International Conferene on Very Large Data Bases, 3 3, 00. [3] H. Höpfner and K.-U. Sattler. Semanti Repliation in Mobile Federated Information Systems. International Workshop on Engineering Federated Information Systems, 36 4, 003. [4] V. Kashyap and A. Sheth. So Far (Shematially) yet So Near (Semantially). IFIP TC/WG.6 Conferene on Semantis of Interoperable Database Systems, 83 3, 99. [5] A. Ouksel and C. Naiman. Coordinating Context Building in Heterogeneous Information Systems. Journal of Intelligent Information Systems, 3(): 5 83, 994. [6] E. Siore, M. Siegel and A. Rosenthal. Using Semanti Values to Failitate Interoperability Among Heterogeneous Information Systems. ACM Transations on Database Systems, 9(): 54 90, 994. [7] J. Mylopoulos and R. Motshnig-Pitrik. Partitioning Information Bases with Contexts. International Conferene on Cooperative Information Systems, 44 54, 995. Panos Vassiliadis reeived his PhD from the National Tehnial University of Athens in 000. He joined the Department of Computer Siene of the University of Ioannina as a leturer in 00. Currently, Dr. Vassiliadis is also a member of the Distributed Management of Data (DMOD) Laboratory ( His researh interests inlude data warehousing, web servies and database design and modeling. Dr. Vassiliadis has published more than 5 papers in refereed journals and international onferenes in the above areas. More information is available at pvassil. Kostas Stefanidis is a PhD andidate in the Department of Computer Siene at the University of Ioannina,. He reeived his MS degree in 005 and his BS degree in 003 from the University of Ioannina, both in Computer Siene. From 00 until now, he is a member of the Distributed Management of Data (DMOD) Laboratory ( His researh interests inlude Database and Distributed Systems. Evaggelia Pitoura reeived her B.S. from the Department of Computer Siene and Engineering of the University of Patras, in 990 and her M.S. and Ph.D. in omputer siene from Purdue University in 993 and 995, respetively. Sine September 995, she is on the faulty of the Department of Computer Siene of the University of Ioannina,. She is also a member of the Distributed Management of Data (DMOD) Laboratory ( Her main researh interests are in data management for mobile and peer-to-peer omputing. Her publiations inlude several artiles in international journals and onferenes and a book on mobile omputing. She reeived the best paper award in the IEEE ICDE 999. She serves regularly in the program ommittees of most of the top onferenes in distributed systems and data management.