Geographic Data Handling in a Deductive Object-Oriented ... - CiteSeerX

Appeared in Proc. 5th International Conference on Database and Expert Systems Applications (DEXA'94), Springer Verlag, ed. D Karagiannis, pp. 445-454, 1994 Geographic Data Handling in a Deductive Object-Oriented Database

Alia I. Abdelmoty, Norman W. Paton, M. Howard Williams, Alvaro A.A. Fernandes, Maria L. Barja, Andrew Dinn Department of Computing and Electrical Engineering, Heriot-Watt University Riccarton, Edinburgh EH14 4AS, Scotland, UK e-mail: @cee.hw.ac.uk phone: +44-31-449-5111 ; fax: +44-31-451-3431

Abstract.

This paper describes how a deductive object-oriented database (DOOD) can be used to support the storage and management of data which is typical of that found in geographic information systems (GIS). This is done with two aims in mind: to illustrate how a combination of deductive and object-oriented facilities can be applied eectively in an advanced application, thereby motivating the development of DOOD systems; and to show how geographic database systems stand to gain from the utilisation of advanced data modelling and inference facilities as supported by a DOOD. The paper describes the DOOD system which has been used for prototyping a range of geographic concepts, presents a framework for the structural organisation of GIS data using an object-oriented data model, and shows how a logic query language can be used within this structural framework to perform a range of analyses. Keywords: Object-Oriented Databases, Deductive Databases, Geographic Information Systems, Spatial Databases

1 Introduction Geographic information systems (GISs) present a major challenge to the developers of advanced databases. The complexity of the data to be modelled { which may be richly structured, spatially distributed, time-variant and subject to complex operations { strains the relational model, which has been shown to be inadequate for many geographic applications [WHM90, Ege92]. Systems have been proposed for managing geographic data which add explicit support for spatial data types into the relational model [Gut88, AS91], but such systems retain the widely recognised weaknesses of relational systems for handling the aspatial aspects of geographic applications, thereby diluting the gains achieved as a result of incorporating spatial data types and operations. Ongoing research in the database community has led to the development of two principal successors to the relational model { deductive databases and object-oriented databases. Both of these approaches have 1

signi cant strengths. Deductive databases have a formal basis in rst order logic, support expressive declarative querying, and bene t from substantial experience with query optimisation strategies. Objectoriented databases support rich facilities for representing both structural and behavioural information, are normally associated with computationally complete programming languages, and are suitable for use in a range of applications where relational database systems have been found to be inappropriate. However, both of these categories of system also have weaknesses. Deductive databases lack semantic modelling facilities, and normally support limited update mechanisms. Object-oriented database systems are rarely based upon formal semantic models, and often lack declarative query languages. Thus it can be argued that these systems have complementary areas of strength and weakness, and that any system which can combine the two paradigms in a way which uses their respective strengths to overcome their respective weaknesses would be an eective platform for a range of novel and conventional applications. This paper presents an approach to the combined use of deductive and object-oriented facilities for the management of geographic data. It is shown how object-oriented modelling constructs can be used to capture the structural semantics of a range of geographic concepts, and how deductive rules can be used to infer the existence of complex relationships within a geographic database. The paper is structured as follows. Section 2 outlines the principal facilities of the DOOD system which is being used with geographic applications. Section 3 indicates how the modelling facilities of the DOOD can be used to describe a range of geographic concepts. Section 4 shows how deduction can be used in this context to infer the existence of additional relationships between geographic concepts. Conclusions are presented in section 5.

2 ROCK & ROLL - A Deductive Object Oriented Database This section presents an informal overview of the ROCK (Rule Object Computation Kernel) & ROLL (Rule Object Logic Language) DOOD system, further details of which can be found in [FBPW93, FWP94]. ROCK & ROLL has three principal components { an object-oriented data model (OM), a logic query language (ROLL), and an imperative manipulation language (ROCK). The relationships between these components are illustrated in gure 1. In ROCK & ROLL, the object-oriented data model has been used as the basis for the design of the other components. The data model describes the structural characteristics of the data which can be processed by both the logic and imperative languages, and thus the two programming languages can be integrated in a way which avoids the introduction of the impedance mismatch [BPF+ 94]. Support for the two languages enables the user to select the programming paradigm which is most suitable for particular tasks within a complex application, and thus allows the bene ts of both a deductive database and an imperative programming language in a single system. The focus of this paper is on the combined use of the logic language and the data model { further details of the imperative language can be found in [FBPW93], and of the integration of the imperative and logic languages in [BPF+ 94].

2

Applications

Queries

Imperative

Logic

Language

Language

ROCK

&

ROLL

OO Data Model

OM

Figure 1: Relationship between the principal components in the architecture.

2.1 Data Model In this section a brief informal account of the model is given in order to provide an introduction to the terminology used later in the paper. The object-oriented model informally described below has been formalised in [FWP93] as a class of rst-order theories [Men87] called object theories (OTs). This section gives an informal overview of the concepts used to model an application domain both structurally and behaviourally. Atomic values and compound data items are called primary objects and secondary objects respectively. Each object is assigned an object type, and must conform to the structure associated with that type. Every secondary object has a unique object identi er. A type de nition can describe references of two kinds. The rst kind of (optional) reference de nition is used to model the properties of the type. This results, for each type, in a possibly empty set of type names which are the attributes of the type. For example, the following de nition indicates that a road has a single property of type roadName: type road properties: roadName; ... end-type

The second kind of (optional) reference de nition, which is referred to as the construction of the type, is used to distinguish the fundamental structural characteristic of a type from its other stored properties. 3

A type can be structured by association, sequentiation or aggregation, which support the modelling of sets, lists and tuples, respectively. For example, the following de nition indicates that a road, as well as having the attribute roadName, is constructed as an association of roadSegment objects (represented by curly brackets): type road properties: roadName; { roadSegment }; ... end-type

The update semantics of the construction of an object enable support for notions such as composite objects, as outlined in [FWP93]. Schema diagrams for the data model can be constructed using the following notation. Secondary object types are represented using rectangles, primary object types using ellipses, and operations as roundcornered rectangles. Labelled directed edges represent modelling features thus: { attribution, 4{ N L N specialisation, { aggregation, { association, and  { sequentiation. Unlabelled directed edges represent the aliasing of type names. This notation is used to describe part of a geographic database in gure 2. Shaded types in this gure are discussed later. The behavioural properties of objects are de ned using methods. The signatures of public methods are included as part of the de nition of a type. Every type is associated with a class of the same name as the type. The class speci es the private properties of the type and gives the code which implements the methods. The intention is that the type speci es all that a user of the type needs to know in order to use the type, while method code and other implementation details are speci ed in the class. Methods can be implemented using either the imperative language ROCK [FBPW93] or the logic language ROLL. Example ROLL methods are given in sections 2.2 and 4. Lack of space precludes a comprehensive description of ROCK, which is presented in [FBPW93], although a small example is given in section 4.2.

2.2 Logic Language ROLL is a Horn clause language. Familiarity with the latter subclass of rst-order languages is assumed at the level of [CGT90]. The ROLL alphabet consists of logic variables, constant symbols and predicate symbols, but not function symbols. The set of constant symbols is the set of names of values (e.g. 5, "Edinburgh", true). There is no need for object identi ers to appear as constant symbols in ROLL expressions, as speci c objects are either passed into a ROLL expression from ROCK, or are retrieved from the extensional database. The set of predicate symbols is the set of operation names declared by operation interfaces. It follows that ROLL queries abide by strict encapsulation. A ROLL term  is either a ROLL constant or a (logical) variable. A ROLL atom has the form: 4

exit

exits

Path

FlowSegment

majorRoad

motorWay

roadName

busRoute

busNumber

time

bound

On

busNumbers

roadSegment

road

f_inside

bound

availability

roadJunction

busStop

Inside

Site touching parcelName

category cityCentre

landParcel

district

city

owner

name

Enclosure

price

Figure 2: Application schema showing the structure of some of the involved objects.

(1 ; : : :; n )@ which is read as \send the message with the arguments 1 ; : : :; n to the object ". An operation interface : T1  : : :  Tn is assumed to be de ned, such that each i denotes an instance of Ti , where Ti  Ti . If n = 0 then @ =def ()@. A ROLL literal L is a ROLL atom A or a negated ROLL atom :A. As usual, an atom is referred to as a positive literal, a negated atom as a negative literal. A ROLL clause is a disjunction of literals of which at most one is positive. A clause containing a single literal is called a unit clause. The notion of a ROLL fact (a positive unit clause) though wellde ned [FWP93], is not relevant in the context of the ROCK & ROLL system because the asserted facts that describe the state of an object at any point in time are encapsulated and are only made available in computations as responses to message-sends. A ROLL rule is a clause with exactly one positive literal and with at least one negative literal. The positive literal is referred to as the head, the set of negative 0

0

5

literals is referred to as the body. The usual convention is followed of rewriting a clause as a reverse implication, i.e. head `:-' body. The following are examples of ROLL queries and rules over the schema presented graphically in gure 2. 1. The following query retrieves as bindings for LP the landParcel objects which are associated with the owner "Acme Products", and which have a price greater than 1000. get_owner@LP == "Acme Products", get_price@LP == P, P > 1000.

This example uses a number of facilities which bear explanation: the operator == denotes uni cation; methods with the pre x get are generated automatically by the system to allow access to the structural characteristics of an object; such methods can be invoked from either ROCK or ROLL, with the syntax for the latter case illustrated above for the methods get owner and get price; the results of the messages get owner and get price, each of which are sent to landParcel objects bound to the logic variable LP, are uni ed with the constant Acme Products and the variable P respectively; this syntax is also used to allow ROLL to invoke side-eect free methods implemented using ROCK; ROLL queries and methods are strongly typed, and a type inference system is used to infer types for logic variables { for example, that the logic variable LP is associated with the type landParcel is inferred from the fact that the methods get owner and get price are applicable to objects of type landParcel; in this example there is no explicit iteration over the instances of landParcel { the ROLL query evaluator optimises a query, and plants iterators within the evaluation graph wherever there is no other way of obtaining a binding for a logic variable associated with an object type. 2. The following method de nition introduces a method called roads attached to the class district, which retrieves as bindings for Road the road objects which pass through the district which is the recipient of the message, namely District. class district ... roads(Road)@District :get_roadSegment@Inside == Segment, get_district@Inside == District, get_member@Road == Segment. ... end-class

In this example, it can be seen that rules are associated with object classes, thereby allowing the rule base to be organised in an object-oriented manner. That the variable District is of type district is established from the fact that it ful lls the role of message recipient in the method de nition which is speci ed within the class district. The system generated method get member is used to retrieve the objects which are stored within an object constructed by association, in this case the association Road. 6

3 Object-Oriented Modelling of the Geographic Domain In de ning a geographic entity, two kinds of property can be distinguished: descriptive properties and spatial properties. The former refers to textual and numeric information (e.g. the name and rate of

ow of a river, the density of population of a region), while the latter specify spatial characteristics of that entity, i.e. its shape and location. The current generation of GISs [Mor86] is characterised by the presence of:

 Distinct underlying representations: a dichotomy exists between the systems used for the repre-

sentation and manipulation of the spatial and aspatial aspects of an application [LPV93] (e.g. a relational DBMS for managing aspatial data and specialised systems for managing the spatial data) with an integration layer to link them. Even with recent proposals for integration of both aspects through extended DBMSs, classi cation of phenomena in the system is split between geometric and semantic, which limits homogeneous abstraction of structure and behaviour.

 Data source dependence: two categories of geographic data source can be recognized, which yield

vector data (usually from manual digitization of paper maps producing points, lines and polygons) and raster data (from scanned maps and remote sensing producing pixels) [Arn89]. The spatial representations of geographic objects in these two forms are dierent, both in terms of structure and in the geometric operations which can be eciently supported (for example, network analysis is best done with an underlying vector representation, while map overlay is computationally easier with a raster representation). Current GISs are restricted to only one of these categories due to the strong link between the representation of the application level concepts and the geometric data structures. The need for GISs to support transparent access to both forms is widely recognized [PLD90, EE89].

With a view to overcoming the above problems a three level conceptual model for the geographic domain is proposed, in which a level of geographic abstract data types acts as a buer between the geometric level of representation, where only the graphical aspects of the data are modelled, and the level where application concepts are modelled. Figure 3 illustrates the mapping between the three levels, which is discussed in more detail later. The indirect mapping from the object to the geometric level using geographic abstract data types (GADTs) has the following motivations:

 To conceptualise the geographic phenomena in a way which groups their spatial and descriptive

aspects from both a structural and behavioural point of view { a step towards developing a uni ed spatial DBMS.

 To decouple the modelling of a geographic phenomenon from its underlying spatial representation { a step towards data source independence.

 To provide an extensible base of abstractions which can be customized for dierent geographic applications { a step towards application independence. 7

Object Level

GADT Level

Geometric Level

polygon (vector)

city

Enclosure pointset (raster)

Figure 3: Example types from the three levels of representation showing the indirect mapping between the object and the geometric levels. In what follows a brief overview is given of the three levels and their representation using the ROCK & ROLL data model.

3.1 Application Level Concepts Figure 2 shows a sample schema of part of a geographic application. The shaded object types in the gure are sample GADTs which are discussed in the next subsection. Application objects are modelled as specializations of GADTs, from which structure and behaviour are inherited. Spatial hierarchies of geographic concepts are represented using the modelling constructs aggregation, association and sequentiation. For example, a city is a set of districts. Objects can have complex object types as attributes, for example, the type motorWay has an attribute exits which is a set of exit objects. The example schema shows both the exibility and directness of representation of the geographic domain concepts using the semantic constructs provided by the data model. Furthermore, lower level details are hidden from the application level using the GADTs introduced in the next subsection.

3.2 Geographic Abstract Data Types Figure 4 presents the structure of some of the GADTs used in gure 2. For example:

 An Enclosure is a representation of a real world object enclosing a property or an activity which

has an areal spatial representation. Examples include house, district, city, etc. The spatial representation of the enclosure is hidden as one of its attributes, and is chosen in this case to generalize both the polygon (vector) and the pointset (raster) representations, thus allowing objects from dierent data sources to be homogeneously modelled. Spatial operations such as overlap, inside and adjacent are de ned on the class Enclosure, and implemented on both its spatial representations. 8

adjacent

Polygon E_spatial_rep

overlap Enclosure PointSet Inside

Theme

S_spatial_rep

Scale

Symbol

on_FlowSegment Point Site inside_Enclosure

F_spatial_rep

Destination

Source

Direction

Capacity Line

FlowSegment

connect

cross

Figure 4: Examples of structure of some GADTs.

 A FlowSegment is a representation of a real world concept used to move resources or carry ow of

a commodity from one location to another, and having a linear spatial representation. Examples include segments of: roads, rivers, railways, power transmission lines, etc. A ow segment has attributes such as direction to indicate if ow is one-way or 2-way, and ow capacity. Its source is a real world object represented spatially as as a point (Site), as is its destination. An example of a source or destination is a roadJunction on a roadSegment. Again, the spatial representation of the object hides its geometric representation, and operations de ned on FlowSegments such as connect and cross are propagated to the appropriate representation.

More complex objects can be built using the above GADTs, such as the Path in gure 2, which represents a list of FlowSegments, where a busRoute is a specialisation of Path representing an ordered set of roadSegments. Depending upon their spatial characteristics, objects can be linked to more than one GADT by attribution and inheritance. For example, a city in gure 2 is modelled as a specialisation of Enclosure which represents its real physical extent, but also has an attribute cityCentre which is a Site for manipulation at smaller scales.

9

yCoordinate

xCoordinate

pointset

length

point

line

polygon

lineset

polyset geo

color

style

line_width

Figure 5: Examples of structures on the geometric level of representation.

3.3 The Geometric Level of Representation Figure 5 shows sample types from the geometric level of representation. Spatial operations on the application level objects map to operations on the geometric level through the GADTs. For example, the overlay operation between two thematic maps, e.g. soil types and rain-fall maps, is interpreted as an overlap operation between their component regions, represented as Enclosures. Such an operation is implemented as an intersection operation over the spatial representation of the Enclosure objects, where the method of implementation may be dierent for the two spatial representations. Similarly, a fusion operation on a thematic map is a union operation on the geometric level. Spatial indexes can be used at this level to enhance spatial search [Sam90].

4 Deductive Inference in a Geographic Database Section 3 has shown that the rich semantic modelling constructs oered by the object data model described in section 2.1 have allowed the realisation of a three level conceptual model for the geographic domain. Such a conceptual model is useful for the representation of complex geographic phenomena, possibly mapping to dierent spatial representations, which is one of the main issues in geographic data modelling. This process also provides an eective framework within which operations representing spatial relationships can be developed. 10

En2 En1

En3

En3

En1 Fs1

(a)

(b)

Figure 6: De ning the overlap operation on two Enclosures using a third Enclosure in (a) and a FlowSegment in (b). By virtue of possessing a location in space, geographic objects exhibit spatial relationships with all other objects in this space. Ad-hoc spatial relationships between objects in a GDB, which are a consequence of their relative positions, are very common in GIS queries. For example, the following are typical:

   

Which dwellings are adjacent to a post oce? Which dwellings are down-stream of a given chemical factory on a river and south-of a given city? Which dwellings are within 1/2 hour driving distance from a given shopping centre? Which dwellings are within an area of 10 miles of a hospital?

The above queries represent examples of four main categories of spatial relationships in a GDB, namely, topologic, metric, orientation and direction [EH90]. It is generally accepted that it is not practical and sometimes not feasible to store all such relationships explicitly. Considerations such as storage overheads, frequency of usage and the computational cost of derivation are used in assessing which spatial relationships to store and which to derive. In most GISs, such as ARC/INFO [Mor86], some topological relationships are stored at the geometric level of representation supported by their underlying data structures, and computational geometry is used for the dynamic evaluation of others. Using computational geometry requires transition between the geometric and the object levels of representation, which can result in signi cant computational overheads. More recently, qualitative spatial reasoning over some of the above relationships has been proposed [Ege91, CCR93] as a complementary mechanism to computational geometry for the derivation of spatial relationships. This section illustrates how deduction can be used to support the inference of spatial relationships [AWP93].

4.1 Inference of Spatial Relationships Spatial relationship composition, i.e. the deduction of a relationship between two objects given their relationship with a common intermediate object, is used in the following examples to illustrate spatial reasoning in a GDB.

Inferring Relationships between two Enclosures 11

Figure 6 shows dierent situations where an enclosure En1 can be said to overlap the enclosure En3. In 6(a) En1 is held to overlap En3 because it overlaps En2 and En2 is inside En3. In gure 6(b) En1 is held to overlap En3 because En1 is on the flowSegment Fs1 and Fs1 is inside En3. These observations can be incorporated into a de nition of overlap as shown below: class enclosure ... overlap(En3)@En1 :inside(En2)@En1, inside(En2)@En3:enclosure. overlap(En3)@En1 :on_flowSegment(En1)@Fs1, inside(Fs1)@En3:enclosure. ... end-class

In the above example, the sux : associated with some of the variables is used to give hints to the type inference system, which is otherwise unable to infer an unambiguous type for each variable in this case.

Inferring Relationships between a Site and an Enclosure

An example of the use of recursive rules in method de nitions is illustrated in the between two flowSegments as follows:

path

relationship

class flowSegment ... path(Fs2)@Fs1 :get_Destination@Fs1 == Connection, get_Source@Fs2 == Connection. path(Fs2)@Fs1 :path(Fs3)@Fs1, path(Fs2)@Fs3. ... end-class

The transitivity property of the inside relationship (A inside B and B inside C , implies A inside C ) is used in the de nition of the following relationship between objects of type Site and Enclosure to minimise the amount of information which has to be stored directly: class site ...

12

inside(Encl)@Site :inside(Site)@Encl1:enclosure, inside(Encl1)@Encl:enclosure. inside(Encl)@Site :on_flowSegment(Site)@Fs, inside(Fs)@Encl:enclosure. ... end-class

4.2 Using Rules on Application Level Concepts Methods over application level classes in gure 2 can also be de ned using rules. For example, motorWaysInCity is an operation de ned on the object class city to determine which instances of the class motorWay pass through a particular city object. class city ... motorWaysInCity(M)@City :get_member@M:motorWay == RS, get_roadSegment@Inside:inside == RS, get_district@Inside == District, get_member@City

== District.

... end-class

In the above example, the class inside is used to represent a relationship between roadSegments and districts. As ROLL queries and methods are optimised, the order in which the subgoals within a query or rule are entered does not determine how it is evaluated. In practice, ROLL queries are evaluated bottom-up after being optimised using a technique based upon Static Filtering [KL90], exploiting the fact that the object manager supports a wide range of access paths to database objects. A query which calls this method to retrieve the motorWays passing through the city of Glasgow can be written as follows: var mset := [{M} | get_name@City == "Glasgow", motorWaysInCity(M)@City]

This example shows how the result of a ROLL query can be assigned to a variable in the imperative programming language ROCK [BPF+ 94]. The embedded query is enclosed in square brackets, the result being the set of objects M which satisfy the goal expressed to the right of the |. It is possible to process the set assigned to mset using the normal facilities of ROCK. For example, the following program would print out the roadName of every motorWay in mset: 13

foreach o in mset do write get_roadName@o, nl;

Note that as ROLL is a logic language, it is possible to run the method motorWaysInCity with dierent variable bindings, i.e. to nd the motorWay objects associated with a given city, to nd the city objects through which a given motorWay passes, to nd out if a given motorWay passes through a given city, or to nd out which motorWays pass though which cities. More details on the combined use of ROCK & ROLL are presented in [FBPW93, BPF+ 94].

5 Conclusions This paper has presented a new approach to the modelling and management of geographic data in a GIS, using a deductive object-oriented database system. The approach has two main features:

 A three level conceptual model for structuring geographic data, with the underlying geometric layer

accessed through a collection of geographic abstract data types, which are in turn referenced by application level concepts. The model facilitates the eective modelling of complex geographic phenomena with possibly dierent underlying spatial representations.

 Spatial reasoning rules for the derivation of implicit spatial relationships which are too numerous to store in the database. Rules for the derivation of such relationships are complementary to computational geometry algorithms which are usually associated with large computation costs.

This approach to geographic data modelling is being prototyped using the deductive object-oriented database system ROCK & ROLL, where the following features have been exploited:

 An expressive object-oriented data model which can directly capture the structural characteristics of a range of geographic concepts at dierent levels of abstraction.

 A fully integrated logic language, which can be used to infer the existence of spatial or aspatial relationships between geographic concepts, which are typically too numerous to store.

 A fully integrated imperative database programming language, which can be used for manipulating

the database, but which also complements the logic language for retrieval tasks in this domain, where the execution of complex geometric algorithms is central to the eciency of the overall system { such algorithms are normally implemented using an imperative style.

Acknowledgements The work that resulted in this paper has been funded by the Science and Engi-

neering Research Council through the IEATP programme, and their support is duly acknowledged. We would also like to thank Dr. Keith G. Jeery of Rutherford Appleton Laboratory for useful discussions on the subject of this paper, and Dr. J.M.P. Quinn representing ICL and Mr Neil Smith of Ordnance Survey as the industrial partners in the project. 14

References [Arn89] [AS91] [AWP93] [BPF+ 94] [CCR93] [CGT90] [EE89] [Ege91] [Ege92] [EH90] [FBPW93] [FWP93] [FWP94] [Gut88] [KL90] [LPV93] [Men87] [Mor86]

S. Arno. Geographic Information Systems: A Management Perspective. WDL Publications, Ottawa, Canada, 1989. W.G. Aref and H. Samet. Extending a DBMS with Spatial Operations. In O. Gunther and H.J. Scheck, editors, Advances in Spatial Databases, 2nd Symposium, SSD'91, Lecture Notes in Computer Science, 525, pages 299{318, Zurich, Switzerland., 1991. Springer-Verlag. Alia I. Abdelmoty, M.Howard Williams, and Norman .W. Paton. Deduction and Deductive Databases for Geographic Data Handling. In Design and Implementation of Large Spatial Databases, Third International Symposium, SSD '93, LNCS 692, pages 443{464. Springer Verlag, June 1993. M.L. Barja, N.W. Paton, A.A.A. Fernandes, M.H. Williams, and A. Dinn. An Eective Deductive Object-Oriented Database Through Language Integration. In submitted for publication, 1994. Z. Cui, A.G. Cohn, and D.A. Randell. Qualitative and Topological Relationships in Spatial Databases. In Design and Implementation of Large Spatial Databases, Third Symposium SSD '93, LNCS 692, pages 396{315. Springer Verlag, June 1993. Stefano Ceri, Georg Gottlob, and Letizia Tanca. Logic Programming and Databases. Springer-Verlag, Berlin, 1990. ISBN 3-540-51728-6, ISBN 0-387-51728-6. R. Espelid and J.A. Eileng. A Raster-To-Vector-Conversion System Producing High Quality Geometric Entities. In The 6th Scandinavian Conference on Image Analysis, pages 1247{1253, Oulu, Finland, 1989. M.J. Egenhofer. Reasoning About Binary Topological Relations. In O. Gunther and H.J. Scheck, editors, Advances in Spatial Databases, 2nd Symposium, SSD'91, Lecture Notes in Computer Science, 525, pages 143{161, Zurich, Switzerland., 1991. Springer-Verlag. M.J. Egenhofer. Why not SQL! Int. J. Geographic Information Systems, 6(2):71{85, 1992. M.J. Egenhofer and J.R. Herring. A Mathematical Framework for the De nition of Topological Relationships. In Proceedings of the 4th international Symposium on Spatial Data Handling, volume 2, pages 803{13, 1990. A.A.A. Fernandes, M.L. Barja, N.W. Paton, and M.H. Williams. A Deductive Object-Oriented Database for Data Intensive Application Development. In Advances in Databases: Proceedings of the 11th British National Conference on Databases (BNCOD 11), LNCS 696, pages 176{198, Keele, UK, July 1993. Springer-Verlag. ISBN 3-540-56921-9, 0-387-56921-9. Alvaro A.A. Fernandes, M. Howard Williams, and Norman W. Paton. An Axiomatic Approach to Deductive Object-Oriented Databases. Technical Report TR93002, Department of Computing and Electrical Engineering, Heriot-Watt University, April 1993. Alvaro A.A. Fernandes, M. Howard Williams, and Norman W. Paton. A Logical Query Language for an Object-Oriented Data Model. In N.W. Paton and M.H. Williams, editors, Proceedings of First International Workshop on Rules in Database Systems, pages 234{250. Springer-Verlag, 1994. R.H. Guting. Geo-Relational Algebra: A Model and Query Language for Geometric Database Systems. In J.W. Schmidt and M. Missiko, editors, Advances in Database Technology- EDBT'88, Lecture Notes in Computer Science, pages 506{527, Venice, Italy, 1988. Spriger Verlag. M. Kifer and E. Lozinskii. On Compile-Time Query Optimization In Deductive Databases By Means Of Static Filtering. TODS, 15(3):385{426, 1990. T. Laurue, D. Pastre, and Y. Viemont. Strong Integration of Spatial Domains and Operators in a Relational Database System. In Design and Implementation of Large Spatial Databases, Third Symposium SSD '93, LNCS 692, pages 53{72. Springer Verlag, June 1993. Elliott Mendelson. Introduction to Mathematical Logic. Mathematics Series. The Wadsworth & Brooks/Cole, Monterey,CA, 3rd edition, 1987. ISBN 0-534-06624-0. S. Morehouse. ARC/INFO: A Geo-Relational Model for Spatial Information. In Proceedings of 7th Int. Symposium on Computer Assisted Cartography, pages 388{398, Washington, DC, 1986.

15

[PLD90]

J.M. Piwowar, E.F. Ledrew, and D.J. Dudycha. Integration of Spatial Data in Vector and Raster Formats in a Geographic Information System Environment. Int. J. Geographic Information Systems, 4(4):429{444, 1990. [Sam90] H. Samet. Heirarchial Data Structures For Spatial Reasoning. In Mapping and Spatial Modeling for Navigation, pages 41{58. Springer-Verlag, 1990. [WHM90] M.F. Worboys, H.M. Hearnshaw, and D.J. Maguire. Object-Oriented Data Modelling for Spatial Databases. Int. J. Geographic Information Systems, 4(4):369{383, 1990.

16