king 
hree 
bute 
alue 
may 
) the 
IS is 
) be 
nore 
dy. 
and 
as a 
the 
the 
as a 
rea 
n be 
ion. 
, for 
ies" 
vely 
> or 
ship 
itity 
late 
| be 
d at 
| for 
ted. 
ter, 
lex 
0 Or 
le, a 
e (a 
>, in 
ving 
nce 
le a 
be 
ting 
it to 
ther 
tion 
‘the 
lity 
the 
In 
can 
and 
y is 
and 
y to 
ran 
ther 
and 
be 
old 
some potential for the integration of data from different 
sources. 
Sticking with the hydrological example, a river may have 
an attribute called position. We know that the position of 
a river is linear in nature, but if we are dealing with data 
from a variety of sources, the actual representation of the 
position may take a variety of forms. Small rivers may 
have their positions defined by single lines of co-ordinates, 
while larger ones may have theirs defined by very long, thin 
polygons. Another possibility is that a river’s position 
may have been determined by remote sensing techniques, 
and be defined by a long, thin block of pixels. This raises a 
problem when it comes to declaring the type of position 
in the river entity type definition 
Each of the representations described above is fundamentally 
different, and yet because of the linearity of what they are 
representing, they have some common conceptual qualities. 
The concept of length, for example, is often important for 
linear features, as is the ability to identify segments along the 
length of a feature. A general attribute value type called 
linear could be defined as a descendant of the general 
type, attribute value. It would specify a common 
state and set of behaviours for all linear positions. Any 
attribute value with 1inear as an ancestor would then have 
the state and behaviour enabling it to be treated as we would 
expect to be able to treat a linear position. Three useful 
descendants of linear could be defined — e.g. 
vector line,polygonal line and raster line. 
The implementation of functions to compute the lengths of 
these different representations of position would, of course, 
be very different. The functionality would be there, 
however, and would work for any descendant of 1inear. 
More will be said about this during the discussion of the 
implementation of the framework. For now, it is sufficient 
to note that if the type for position is declared as 
linear, then it is quite allowable for an attribute value of 
any of the more specialised types to be associated with that 
attribute. 
Another important modelling concept which the framework 
supports is that of aggregation — the ability to handle 
complex entities. Some entities can be seen as collections 
of other entities. A road system, for example can be 
seen as a collection of roads and junctions. Complex 
entities could be handled by using is part of 
relationships. The framework, however, supports the 
representation of complex entities directly, without requiring 
the use of relationships. In the same way that entities can 
have attributes, complex entities can have components as 
well. A component has a type declared for it which defines 
what kind of entity (or, indeed, complex entity) can be taken 
as a value. A complex entity may be composed of single 
components or groups of components. A land parcel, 
for example, may consist of one plot, and zero or more 
buildings. 
It should be clear from what has been said, that, at least in 
terms of the kind of model that can be built, the framework 
which has been developed can be described as object- 
oriented. The general types — entity, relationship and 
attribute_value — can be seen as classes which specify state 
and behaviour and which can be specialised. More 
specialised descendant types allow uniquely identifiable 
components to be generated (which can be seen as objects — 
instances of classes), and these allow useful models of the 
real world to be built. Some of these components 
correspond directly to items of interest in the real world 
757 
(entities and relationships), while others are dedicated to 
storing information about them (attribute values). At the 
moment, no attempt has been made to incorporate 
components in the model which represent phenomena (such 
as elevation) in any way. It is hoped that future 
developments will address this deficiency. 
It was mentioned that all the types — entity, relationship and 
attribute value — specify state and behaviour. Attribute 
values were described as having specialised operations 
defined for them (recall the distance type). It was also stated 
that entities could have specialised operations defined, as 
well as the most basic ones used for setting attributes and so 
on. As a demonstration of this, consider the following 
example : 
À road system isa complex entity with road and 
junction entities for components. All three entity 
types have an attribute, position, specified for them. 
Forthe road system type, the type for positionis 
declared as network. For the road type, it is declared 
as linear, and for the junction type, itis nodal. 
In a particular model, a road_system entity is 
associated with a bunch of road and junction 
entities. The position attributess of the roads are of 
type vector line, while those of the junctions 
are of type vector point. These attribute value 
types are descendants of linear and nodal 
respectively. 
The positions of the roads and junctions are also 
tied together into an attribute value of a more complex 
type — a vector network, which is a descendant of 
network. This attribute value is taken by the 
road system as the value for its position attribute. 
Attribute values of type net work (and its descendants) 
have the functionality to compute the shortest path 
between two nodals which are part of it. If an 
appropriate querying mechanism is in place on top of the 
framework, it should therefore be possible to establish 
what the shortest route between two junctions in the 
road system is. 
By selecting two junctions, the vector points 
which represent their positions can be found. These can 
then be used as input to the shortest path function 
of the vector network associated with the 
road system. This function should return a list of 
vector lines, and by comparing these to those 
defining the positions of the roads, it should be 
possible to determine the shortest route between the 
chosen junctions in terms of the roads that must be 
followed. This route may then be saved as an entity of 
type route. 
This method of finding the shortest route depends a lot 
on the knowledge of users, and it should be possible to 
specify a shortest route operation in the 
road system type. Such an operation would accept 
two junctions as its input, and return a list of road 
entities, or even a route entity, as its result. It would 
automatically perform the selections and comparisons 
outlined above, hiding the processes and the 
representations from the users. 
Specifying the kind of information hiding behaviour that has 
been outlined for the road system entity type is possible