Location Dependent Query Processing

Vijay Kumar

Ayse Y. Seydim, Margaret H. Dunham

Department of Computer Science and
Engineering
Southern Methodist University
Dallas, TX 75275-0122

Computer Science Telecommunications

University of Missouri-Kansas City
Kansas City, MO 64110

kumar@cstp.umkc.edu

yasemin(mhd)@engr.smu.edu

L ocation Dependent Data (LDD) is dened as \data whose

value is determined by the location to which it is related"
[15]. Local yellow pages, local even ts, hotel and restaurant
information are some of the examples of these data. Location dependence in queries implies that the information
ask ed is related to a location but the location is not explicitly known when the query is asked. F or example, \What are
the names and addresses of the restaurants within 5 miles?"
asks to nd the restaurants within 5 miles of the current
position of the query issuer. In order to provide the answer
to the query, rst we have to know the location of the issuer.
Query can then be bound to this location. When we nd out
the issuer's location, the query becomes Location Aware
since, this special location attribute is explicitly stated to
be the issuer's location. In this manner, a query including
an y location related attribute in its predicates is dened as
a Location Aware Query (LAQ).

ABSTRACT

The adv ances in wireless and mobile computing allow a

mobile user to perform a wide range of aplications once
limited to non-mobile hard wired computing environments.
As the geographical position of a mobile user is becoming
more trackable, users need to pull data which are related to
their location, perhaps seeking information about unfamiliar places or local lifestyle data. In these requests, a location attribute has to be identied in order to provide more
ecient access to location dependent data, whose value is
determined by the location to which it is related. Local yellow pages, localev en ts, and weather information are some
of the examples of these data.

In this paper, we giv e a formalization of location relatedness

in queries. We dierentiate location dependence and location aw arenessand provide thorough examples to support
our approach.

1.

In this paper, we give a general view of location relatedness

in the queries. We distinguish betw een locationa w areness
and location dependence and provide a formalization of the
approach. We also illustrate the dierentiation by examples.

INTRODUCTION

Location of an object or a person is its geographical position on the earth with respect to a reference point. This
information can be characterized by using a number of differen t represen tations including latitude/longitude/altitude
or street addresses, etc. and by giving granularit y, accuracy
and rate of change (velocity). With the technological advances in cellular communications and sensing appliances,
location of people has become more real-time and trackable
[7]. Locationrepresen tation may include timestamp information as it may be related to a moving object/person [5],
[16], [18] and may be represented in v arious ways. Location
can be estimated by using dierent methodologies, and will
become an information as common as date information.

2. LOCATION AND QUERIES

Queries asked in the mobile environment may have slightly

dierent structure from traditional database queries. In this
section, we examine the dierences and propose approaches
to process these. Obviously, there will be location related
and non-location related attributes in these queries. When
the user is moving, to answer an y location based request,
it may become necessary to identify location related attributes. Sometimes the statement of the query will not
ha ve any location related attribute but the way it is stated
will have an implication that the query issuer's current position is in volved in the selection criteria. The implied location related attribute has to be addedthe
to query and
corresponding LDD is used to answer it. An investigation
of implementation issues of location dependent query processing can be found in [17]. We presen t a formalization for
the location identication in queries and give examples in
the follo wing subsections.

This material is based upon w ork supported by the National Science Foundation under Grant No. IIS-9979458
yThis material is based upon w ork supported by the National Science Foundation under Grant No. IIS-9979453

Permission to make digital or hard copies of part or all of this work or

personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers, or to redistribute to lists, requires prior
specific permission and/or a fee.
MobiDE 2001 USA
Copyright 2001 ACM 1-58113-412-6/01/05$5.00

2.1 Formalization with a Distinction of Location

Suppose a database, D,Sconsists of a set of base relations; R1 ,

R2 , ..., Rn , where D = ni=1 Ri , and let each attribute set of
a relation be denoted as ARi . The union of attributes of each

47

relation will give the attribute

S set of the whole database D,
which is denoted as, AD = ni=1 ARi . Note that, relations
may have the same attributes, but AD gives the distinct
attribute set that are used in database D.

1
0
0
1

Corresponding to each attribute aij in a relation Ri , is a

set domij , which is the domain of j th attribute of Ri . A
domain is said to be an arbitrary, non-empty set, nite or
countably innite [10]. The domain set of any attribute is
identied by the semantics or relatedness to the meaning of
the attribute in the database. For example; domain set of
a CityName attribute for Texas state contains city names
like fDallas, Houston, San Antonio, ...g. This relatedness
for the domain is normally determined by human beings.

(a) rectangle window

AD(LR) =

ARi (LR) and

AD(N LR)

S
S
=
n

i=1
n

i=1

D (LR)

(c) circle window

the operation. For example, intersection, union, or equal

operators illustrate dierent operations depending on their
application on non-spatial or spatial attributes. We use the
classication in Table 1 for non-spatial and spatial operators. The list is not an exhaustive list, and they are the
operators dened on the general geometry class by Open
GIS Consortium [19]. The spatial operators listed in Table
1 are dened at a general level for all basic spatial data types
(points, lines, regions). More complicated spatial operators
can be dened based on these elementary types to perform
more complex operations. It is also discussed in [1] that even
more theoretical research is necessary to dene the complete
set of operators.

Given a database D and its attribute set AD , if the location relatedness is distinguishable, the attribute set of
the database consists of attributes from Location Related
(LR) domains and Non-Location Related (NLR) domains. So we can then write,

[A

(b) half circle window

11
00
00
11

Figure 1: Orientation and Windowing Interpretation

We assume individual attributes of relations can be distinguished to be elements of Location Related (LR) or NonLocation Related (NLR) domains. For example; CityName
is a Location Related attribute name and its domain is also
LR. On the other hand, LastName is a Non-Location Related attribute name and its domain has no relation to any
location.

AD = AD(N LR)

11
00
00
11

Denition 2. An LR-Operator is an operator which has

LR-Attributes as its operands. Similarly, if the operands are
all NLR-Attributes then the operator is an NLR-Operator.

, where

All spatial operators (e.g.intersect) are LR-Operators. However, there are denitely more LR-Operators than spatial
operators. This is because an LR-Operator may be stated
based not only on a spatial concept but also on the direction of movement of the query issuer. A mobile client has an
orientation. Thus, LR-Operators include operators such as
\straight ahead". Spatial operators are used to compare two
spatial objects which are static. An LR-Operator may compare attributes for objects which are moving. One or both
of these objects may be moving. Therefore, not only can the
operator compare attributes for the spatial properties of the
objects, but also the orientation.

ARi (N LR)

Denition 1. Let the relation Ri contain the attributes,

aij , 1  j  k and is shown by Ri = fai1 , ai2 , ..., aik g. If
an attribute aij of relation Ri is distinguished as \location
related", we call aij as an LR-Attribute and Ri as an LRRelation. Otherwise, attribute is \non-location related"
and stated as NLR-Attribute. If all attributes of Ri are
NLR-Attributes then relation Ri is called NLR-Relation.
In that case, ARi (LR) = f g.

An LR-Operator may have ltering and orientation arguments with it. With ltering, we mean using a restrictive
area within which the desired data is selected. For a \closest" operator, one can think of a circle area around the query
issuer to access the related data. Orientation may not be
important in this case. If we think about a \straight ahead"
operator, we have to dene a window to select an area ahead
of the direction of the user. Here, the operator itself denes
a direction for the movement.

Spatial data is used to describe \data that pertains to the

space occupied by the objects in a database" [16]. Spatial
data are geometric and consist of points, lines, rectangles,
polygons, surfaces, volumes, and data of even higher dimension. Inherently, spatial data are \location related".
Some attributes of spatial data like name, do not contain any
\embedding space" [11] notion or relationship. These are
considered as non-spatial properties. Non-spatial attributes
of spatial relations can also be viewed as NLR-Attributes
according to our denition above. However, any spatial relation dened is an LR-Relation.

The example for dierent interpretations of a ltering window is shown in Figure 1. Depending on the window interpretation, the data related to an area of a half circle,
a rectangle, or a square have to be selected to access the
related data reply to the query. In the gure, (a) shows a
rectangular area of selection for the related data. (b) and (c)
show half circular and circular selection respectively. Data
do not have to be spatial, even though the results may not
be accurate. We do not concentrate on the creation of special LR-Operators, and we give the example for clarication.

Operations performed on attributes are dened according

to the properties of their operands. Whether it is a unary
or binary operator, which requires one or two operands respectively, some operators can be used in both non-spatial
and spatial domains [1]. However, the meaning is interpreted depending on the domain of the attributes used in

48

Table 1: Non-Spatial and Spatial Operators

Operator
Operator
Operators
Type
Group
Non-Spatial
Comparison
<, , =, >, 
Set
union, intersection, dierence ([, \, )
Boolean
and, or, not (_, ^, :)
Spatial
Basic
SpatialReference, Envelope, Export,
IsEmpty, IsSimple, Boundary
Topological
Equal, Disjoint, Intersect,
Touch, Cross, Within,
Contains, Overlap, Relate
Spatial Analysis
Distance, Buer, ConvexHull,
Intersection, Union, Dierence,
SymDierence
On the other hand, we have to incorporate this window concept for selecting the location related data from a traditional
database. We now dene the predicates in a query.

a mixture of them in a Compound Predicate form. We can

now dene a query including the location relatedness notion.

A Simple Predicate is dened as an expression with one

operator and one or two operands, which is of the form SP
= op1 pi or SP = pj op2 pk , where op1 is a unary operator and compatible with pi , and op2 is a binary operator
and compatible with both pj , and pk . pj and pk are also
compatible with each other. Either one of pj or pk can be a
constant from the same domain as the other operand. Here,
operands are either attributes or constants.

Denition 5. A query consists of relations, attributes,

predicates, and operations used to produce a result. We
dene a query Q, with a set of these, QR , QA , QP and QO
which correspond to relations, attributes and predicates
in Q and operations to produce the result respectively. We
can then write :

Q = fQR , QA , QP , QO g, and
QS = fissue(Q)g

Operands in a Simple Predicate have to be compatible as

being from the same domains. For example, one can use
comparison operators as an operator and compare the attribute CityName with a constant \Dallas" but not with a
constant 2001 since they have dierent domains.

where QS is the result set after the execution of the query

Q against a given database state.
Note that, QA designates the attributes used in the query,
not all the attributes of its relation. Operations are data
manipulation operations like select, project, join, etc.. Once
we distinguish the location relatedness, we can then decompose a query to LR attributes, predicates and relations and
write the query as :

A Compare Predicate dened in [14] is a type of Simple

Predicate. With a similar approach, we will not include 6= in
our studies, as it brings complexity in predicate evaluation.
Since we are concentrating on the query processing issues
of location dependent data, without loss of generality, we
ignore the 6= comparison.

Q = fQR(LR) , QR(N LR) , QA(LR) , QA(N LR) ,

QP (LR) , QP (N LR) , QO g

Denition 3. A Simple LR-Predicate is a Simple Predicate where the operator is an LR-Operator and the operands
are from LR-domains. A Simple NLR-Predicate is a Simple Predicate which has an NLR-Operator and operands are
both from NLR-domains.

Denition 6. If all the predicates used in a query are Simple NLR-Predicates, i.e. QA(LR) =  and QP (LR) = ,
then the query is called a Non-Location Related Query
(NLR-Query). The relation may be an LR-Relation, but
if only NLR-Attributes are selected, query is still an NLRQuery.

Denition 4. A Compound Predicate is disjunction (_

predicate) of conjunctions (^ predicates) of Simple Predicates which can be dened as follows:

In selection, if all attributes are selected (e.g. with \*"

in SQL), and the relation itself is a LR-Relation, then the
result set will have LR-Attributes. Whether the relation is
a LR-Relation or not, the specied and selected attributes
in the query are sucient to call a query an NLR-Query.
Note that in an LDD data store, there may be both kinds
of relations. Example 1 illustrates an NLR-Query.

CP = (SP11 ^ SP12 ^ ... ^ SP1n ) _

... _ (SPm1 ^ SPm2 ^ ... ^ SPmr )
Here, each SPij is a Simple Predicate.
In standard relational operations, selection, projection and
join, predicates used for the production of results may be
either Simple LR-Predicates or Simple NLR-Predicates or

From its denition, the project operation eliminates the undesired attribute columns from the result set or selects the

49

desired ones only. If the attributes are not in the selection

criteria but in the desired attributes for the projection operation, then these attributes must also be included in the
attribute set of the query, QA .

Denition 8. If the projected attribute is the location of

the selected tuple, or the result set includes only the location
attribute, then we refer to these kind of queries as a special
kind of LAQ, and call a Location Query (LQ).

Example 1. Suppose we have the query \Find the lead actor's name in the movie \Casablanca"." where the relational
algebra expression is :

Example 3. A query \Where is Person A?" is an LAQ

and uses an LQ to nd the person A's location. This query
is independent of the query issuer's location. However, the
question \Where" carries a meaning that we should include
the location attribute from the Relation \USERS" and nd
the corresponding value from the data store.

ActorN ame (M ovieN ame=\Casablanca00 ) (MOV IES )

In this query, no location attribute is involved. We thus

have:

ActiveLocation (P ersonI d=\A00 ) (USERS )

QR = fMOVIESg ) QR(N LR) = fMOVIESg

QR = fUSERSg ) QR(LR) = fUSERSg

QA = fMovieName, ActorNameg
) QA(N LR) = fMovieName, ActorNameg

QA = fActiveLocation, PersonIdg
) QA(LR) = fActiveLocationg, QA(N LR) = fPersonIdg

QP = fMovieName = \Casablanca"g
) QP (N LR) = fMovieName = \Casablanca"g

QP = fPersonId = \A"g
) QP (N LR) = fPersonId = \A"g

QO = fselect, projectg

QO = fselect, projectg

As is seen from the above sets, there is no LR-Attribute or

LR-Predicate, so this query is an NLR Query .

We assume ActiveLocation is a location attribute of Relation

\USERS". If the location attribute of Relation \USERS"
were City, then ActiveLocation is to be a city name for this
relation. Some other examples of LAQs are :

2.2 Location Aware Queries

We dene Location Aware Queries as follows:





Denition 7. If a query, Q, includes at least one Simple

LR-Predicate in its predicate set, QP , or at least one LRAttribute in its attribute set, QA , then it is called a Location Aware Query (LAQ). An LAQ produces the same
result set independent of the place it is issued.

How is the weather in San Antonio?

Find ATMs within 5 miles of Hotel X. [16]
Find the services at location X. [16]

2.3 Location Dependent Queries

In Location Dependent Query Processing, we see a specic

type of predicate in which the location attribute is xed but
the constant to which it is compared changes depending on
the query issue location. As mentioned before, the predicate
is actually hidden in the query statement. For example, the
query \Find hotels within 5 miles." has the implied meaning
of \Find hotels within 5 miles of my current location." This
current location must be found and bound to the query. We
assume that some location service is used to provide this
location. This process of binding the current location to the
query is referred to as location binding.

Example 2. Suppose we are given the query \Find movie

theaters in Richardson.". This can be stated as:

T heaterN ame;Address (Address=\Richardson00 ) (T HEAT ERS )

QR = fTHEATERSg ) QR(LR) = fTHEATERSg
QA = fTheaterName, Addressg
) QA(LR) = fAddressg, QA(N LR) = fTheaterNameg

For now, we assume that Address only includes the county

names.

Denition 9. Location Binding can be dened as assigning a location value to an LR-Predicate variable.

QP = fAddress = \Richardson"g
) QP (LR) = fAddress = \Richardson"g

We also dene an Active Location Predicate to represent the

Simple Predicate involved in an LDQ.

QO = fselect, projectg

Denition 10. An Active Location Predicate is a Simple Predicate with a specic attribute name which is of the
form, ActiveLocation = Here, where ActiveLocation is
the xed attribute name and Here is a variable which is
assigned a location value after Location Binding.

If a query is issued to nd out a location value, it is obvious

that this query has a LR-Attribute in its attribute set. We
dierentiate these as special types of LAQs and call them as
Location Queries (LQs).

50

An Active Location Predicate is a Simple LR-Predicate

since it involves a location related attribute and a location
value.

data which changes depending on a location. In [3] LDD is

dened as spatial replicas depending on a data region it is
included. The query processing approaches based on physical organization of data and location binding to queries are
discussed also in [8].

Denition 11. If the result set of the query, Qs , changes

depending on the location of the query issuer, then the query
is called a Location Dependent Query (LDQ). In an
LDQ, the Active Location Predicate is hidden when the
query is stated and current location of the issuer is implied
for \Here". An LDQ becomes location aware, an LAQ,
when the Active Location Predicate is bound to a location.

Most research to date not only has concentrated on query

processing issues for location databases but also on the Moving Object Databases (MOD) [18], [20]. Moving Object
Database (MOD) Queries are queries in which the answer
depends not only on the database contents (location), but
also on the time at which the query is asked. Direction of
movement and the speed is included in the modeling of the
MOD, which is treated as a special kind of spatio-temporal
database. These works views location dependent applications as MOD applications. In [18], MOD queries have been
classied as instantaneous, continuous and persistent query
types. These kinds of queries actually carry the application
or business logic within their type classication. Some MOD
query examples are as follows:

Example 4. Suppose the the query \Find the closest theaters." is issued when the client is in Richardson. When this
query is stated, there is no specication of Active Location
Predicate. When the \closest" operator is processed, however, a second operand will be produced by using the Active
Location Predicate, so we will add this to the predicate set
to get:

T heaterN ame;Address (closest(Address;H ere) (T HEAT ERS )

The query has the additional implicit predicate of \ActiveLocation = Here". After location binding occurs, \Here"
will be replaced with \Richardson". We thus have:

QR = fTHEATERSg ) QR(LR) = fTHEATERSg

QA(N LR) = fTheaterNameg

QP = fclosest(Address, Here), Address = ActiveLocation,
ActiveLocation = Here, Here = \Richardson"g
) QP (LR) = QP

Notice that a type of preprocessing is needed in these kind

of queries to add the Active Location Predicate, and we will
also need a Location Binding for. Other examples for LDQs
are :

3.




Where is the nearest doctor? [6]

Retrieve the objects whose speed in the direction of the

X-axis doubles within 10 minutes. (persistent)

[21] identies queries according to their access to location information. In all types mentioned by [21], Location Binding
is assumed to be a \cell id" binding to the query. If the
queries are Local, e.g. \List the local hotels", the database
search starts from the current Base Station (cell) to the root
until the results are found. If they are Non-Local, the query
is redirected to the corresponding cell where the local replies
are forwarded to the current cell. Geographically-Clustered
and Geographically-Dispersed queries have to be processed
in cell basis. Another type, Nearest query has to be processed in the current cell and the nearest cell to the farthest
until satised.

QO = fselect, project, closestg

Where is Person A with respect to here? or How far

is Person A?

Find Chinese restaurants within 5 minutes on my path.

(continuous)

However, a \How far is person A?" query will get dierent

results depending on the query issuer's location and also if
Person A is moving. This query needs location binding and
calculation for the distance. In [9] states this query as an
LAQ, whereas we see it as an LDQ.

QA = fTheaterName, Addressg
) QA(LR) = fAddress, ActiveLocation, Hereg,

Find the hotels that I will reach within 5 minutes. (instantaneous)

In these research studies, we don't see any clear dierentiation between location dependence and location awareness
in queries and applications. We think the main dierence
between a location dependent query and a location aware
query is the Location Binding, and the fact that this process converts the former type of query into the latter. This
dierentiation also implies an implementation approach. A
location query requires nding the current location, and we
assume this is processed using a Location Service provided
by a Position Determining Technology vendor. With this
assumption in mind, our work diers in the classication of
query types from the MOD queries. We summarize the relationships of the query types in Table 21 . We also see these
MOD queries as special cases of our LDQs.
1
In the Table, S/M shows whether the object asked is Sta-

Find closest restaurants and hotels. [2]

REMARKS ON RELATED RESEARCH

Querying location dependent information in mobile environment has been seen as an important research area and most
of the work to date has studied data management issues of
mobile objects and their location information. [6],[12],[13]
are some of the work which concentrate on querying location information, the frequent update and inaccuracy problems which may occur mostly in wireless operator databases.
Similar to ours, [4] and [2] view LDQs as asking values of

51

Table 2: Summary of Relationships of Query Types

Operators
Time
Object Issue Location
Query
Used
Involved Asked Loc. Attribute
Result
Non-Spatial
No
S/M
N/A
No
non-spatial
data
LAQ
LR-Operator
Maybe
S/M
N/A
Yes
location
or LDD
LDQ
LR-Operator
Maybe
S/M
Yes
No
location
(here) (hidden)
or LDD
LQ
equal
Maybe
S/M
N/A
Yes
location
MODQ LR-Operator
Yes
M
N/A
Yes
location
Spatial
Spatial Op.
Maybe
S/M
N/A
Yes
spatial or
non-spatial
data
Spatio- LR-Operator
Yes
S/M
N/A
Yes
spatial or
temporal
non-spatial
data
Query
Type
NLR-Q

4.

and thus an implementation approach. We have proposed

a software architecture, Location Dependent Services Manager (LDSM), which can be used to realize this translation
[17]. Implementation of an LDSM prototype is currently
underway.

QUERY TRANSLATION IN LDQ PROCESSING

Notice that an LDQ goes through several stages prior to

being processed :
Find the closest hotels !
Find the hotels within 5 miles !
Find the hotels within 5 miles radius of Cell Id = 3.
Find the hotels with 75205 < zipcode < 75206.

6. REFERENCES

[1] E. Clementini and P. Di Felice. Spatial operators.

SIGMOD Record, 29(3):31{38, September 2000.
[2] M. H. Dunham and A. Helal. Mobile computing and
databases: Anything new? SIGMOD Record,
24(4):5{9, December 1995.

These stages dier depending on the granularity of the location bound and the location granularity of the database.
We have proposed a middleware architecture to perform this
translation and to preprocess/postprocess the LDQs [17].
Functions of the middleware can be summarized as:

determine the validity (and type) of the query and

request the Position Determining service to provide a
location to which the LDQ is bound

determine the location granularity which will be used

by the target data server and convert the query into
the correct format for it




5.

[3] M. H. Dunham and V. Kumar. Location dependent

data and its management in mobile databases. In
R. Wagner, editor, Ninth International Workshop on
Database and Expert System Applications, DEXA'98,
pages 414{419, Vienna, Austria, August 1998. IEEE
Computer Society.
[4] G. H. Forman and J. Zahorjan. The challenges of
mobile computing. Computer, pages 38{47, April 1994.
[5] R. H. Guting, M. H. Bohlen, M. Erwig, C. S. Jensen,
N. A. Lorentzos, M. Schneider, and M. Vazirgiannis.
A foundation for representing and querying moving
objects. ACM Transactions on Database Systems
(TODS), 25(1):1{42, March 2000.
[6] T. Imielinski and B. R. Badrinath. Data management
for mobile computing. SIGMOD Record, 22(1):34{39,
March 1993.

decompose the query into pieces for dierent servers

and send each to the target server for processes
receive the query results and perform any needed ltering to reduce the result set size
combine results from multiple servers and put into format desired by user

[7] A. Krikelis. Location-dependent multimedia

computing. IEEE Concurrency, 7(2):13{15, April-June
1999.
[8] V. Kumar and M. H. Dunham. Dening location data
dependency, transaction mobility and commitment.
Technical Report 98-CSE-01, Southern Methodist
University, Dallas, TX, 1998.

SUMMARY AND CONCLUSION

In this paper, we have presented a query formalization which

would encompass all types of previously proposed query
models (both location dependent and non-location dependent). Our view for Location Dependent Queries and Location Aware Queries implicitly indicate a translation process
tionary or Mobile. LR-Operators set includes Spatial Operators and more complex ones including time and orientation
(straight ahead, within, closest, nearby, in, etc.), i.e. LROperators  Spatial Operators.

[9] H. Maass. Location-aware mobile applications based

on directory services. ACM Baltzer Journal on Mobile
Networks and Applications (MONET), 3:157{173,
1998.

52

[10] D. Maier. The Theory of Relational Databases.

Computer Science Press Inc., 1983.
[11] J. Nievergelt and P. Widmayer. Spatial data
structures: Concepts and design choices. In M. van
Kreveld, J. Nievergelt, T. Ross, and P. Widmayer,
editors, Algorithmic Foundations of Geographic
Information Systems, volume 1340 of Lecture Notes in
Computer Science, chapter 6, pages 153{197. Springer,
1997.
[12] E. Pitoura and B. Bhargava. Building information
systems for mobile environments. In Third
International Conference on Information and
Knowledge Management, CIKM'94, pages 371{378,
Gathesburg, MD, USA, November 1994. ACM.
[13] E. Pitoura and G. Samaras. Locating objects in
mobile computing. IEEE Transactions on Knowledge
and Data Engineering, 2000. accepted, to appear..
[14] Q. Ren. Semantic Caching in Mobile Computing. PhD
thesis, Southern Methodist University, Computer
Science and Engineering, Dallas, TX 75205, February
2000.
[15] Q. Ren and M. H. Dunham. Using semantic caching
to manage location dependent data in mobile
computing. In Sixth Annual International Conference
on Mobile Computing and Networking, MobiCom
2000, pages 210{221, Boston, MA, USA, August 2000.
ACM SIGMOBILE.
[16] H. Samet and W. G. Aref. Spatial data models and
query processing. In W. Kim, editor, Modern Database
Systems - The Object Model, Interoperability and
Beyond. ACM Press, New York, NY, USA, 1995.
[17] A. Y. Seydim and M. H. Dunham. Location
dependent query processing: Overview of a
framework. submitted paper, web page,
http://www.engr.smu.edu/yasemin/arch.pdf, 2000.
[18] A. P. Sistla, O. Wolfson, S. Chamberlain, and S. Dao.
Modeling and querying moving objects. In IEEE
Thirteenth International Conference on Data
Engineering (ICDE'97), pages 422{432, Birmingham,
U.K., April 1997. IEEE Computer Society.
[19] The OpenGIS Consortium. OpenGIS simple features
specication for SQL. Technical report, OpenGIS,
http://www.opengis.org/techno/specs.htm, March
1998.
[20] O. Wolfson, B. Xu, S. Chamberlain, and L. Jiang.
Moving objects databases: Issues and solutions. In
International Conference on Scientic and Statistical
Database Management, (SSDBM'98), pages 111{122,
Capri, Italy, July 1998.
[21] J. Xu and L. D. K. Querying location-dependent data
in wireless cellular environment. In W3C and WAP
Workshop on Position Dependent Information
Services, France, February 15-16 2000.

53