)BMS uses a different
erface.
onsible for improving
eneity, i.e., geometric
ts, using its open
Schell D., 1995]. The
Dpen Geodata Model,
ta model for all spatio-
object and field based
rvices, OGS. It defines
ng software interfaces.
ur of geoprocessing
nterchange, manage,
pecified in OGM.
e a set of well known
ic building blocks. The
on programming types
strings. The aggregate
ing database aggregate
, and tuple. Moreover
1d temporal primitives
d their own internal
line, areas, surfaces,
GISs are using these
ansformation from one
eword process.
d as properties in the
same real world entity
escriptors in different
ned to handle this type
sed in this paper is
and the semantic
presented in different
er to serve various
mantic conflicts at the
network in a GIS for
rom that in a GIS for
' at the semantic level
strategy based on the
> context interchange
the interpretations
ed in the form of data
logy [Goh C., et al.,
of a conceptualisation.
of the concepts and
onent GIS or a set of
in is implemented in a
ris a paradigm which
] receivers [Siegel M.,
et al., 1991]. This paradigm described how those features can
be realised by showing:
1. How domain and context specific knowledge can be
represented and organised for maximal sharing.
2. How these bodies of knowledge can be used to facilitate the
detection and resolution of semantic conflicts between
different systems.
A context mediator does a number of things each time it
receives a query referencing multiple data sources. First it
compares the contexts of the data sources and receivers to
determine if semantic conflicts exist, and if so, what
concessions need to take place to resolve them. This is referred
to as conflict detection and the information detailing the
conflicts are presented in a conflict table. This query then
undergoes an optimisation process. Optimisation takes number
of forms: a subquery can be reformulated so that constants
referred to in a query are concerted to the context of the data
sources executing that query. Finally, the intermediate answers
obtained form component systems must be merged together
and converted to the context understood by the receiver.
There are two pre-requests for mediation of semantic conflicts:
1. All sources and receivers must describe their contexts
explicitly with respect to a collection of shared ontology,
i.e., expert schema
2. All queries must routed through the context mediator
mentioned above.
It is worth mentioning here that the context interchange
concept is only suited for non spatial databases. However,
merging the OGIS concept and the context interchange concept
will result a proper semantic data sharing mechanism. In the
next section a proposal with such an idea is presented.
Furthermore, a different approach will be followed for
modelling ontology of spatial objects. A canonical model is
presented. This model is based on using OGIS concepts for
defining the syntactic structure and spatial representation of
geographic objects, and metadata and relationship between
objects for building semantics. A rule base stored in the
mediator server accesses the metadata and the knowledge base
for identifying objects and resolving semantic conflicts.
3. ASPATIAL CANONICAL DATA MODEL
The proposed theory for semantic data sharing is based on
building layers of semantics onto the syntactic definition of
geographic objects, Figure 1. At the lowest level of the syntactic
definition we find the classic data structure, i.e., field and
object based approaches. The GIS theory formalises the
topologic relationships amongst objects, uncertainty aspects,
and the handling of geometry and topology of fuzzy objects
[Molenaar M., et al., 1993 a, b and 1995]. Finally the theory
introduces a consistent framework for object hierarchies, i.e.,
generalisation, aggregation, etc. This theory is however
focused on object representation is a single database. OGIS
introduced an elaborate set of common syntactic vocabulary for
spatial object representation for sharing and exchange. The
syntactic part of the canonical data model is based on OGIS
specification mentioned in section 2.1.
A node is a collection of interrelated contexts. Nodes can be
divided into sub-nodes. A sub-node can have one or more
context. A Context refers to the assumptions underlying the
way in which an interoperating agent represents or interprets
International Archives of Photogrammetry and Remote Sensing. Vol. XXXI, Part B3. Vienna 1996
data. A context is defined by one and only one set of semantic
specifications. Contexts can be structured in a hierarchical way.
Hence, semantic specifications of a lower level context are
used as building blocks for those at a higher level. A context
can have one or more sub-contexts. Each context corresponds
to one and only one database. A database in turn is
corresponding to one and only one data model. A data model
consists of one or more hierarchies. A hierarchy is formed by
Semantics Of
Nodes
Semantics Of
Contexts
— -SSemantics
Semantics Of
Hierarchies
Semantics Of
Classes
Object Hierarchies
Uncertainty and
Relati
Fuzzy Relations Syntax &
Topolory Schemata
Field and Object
Based Structures
Figure 1 Syntactic and Semantic Definition
one or more object classes, i.e., intension. A class can have one
or more instances, i.e., extension.
Figure 1 shows the semantics that have to be built onto the
syntax. Object classes, intensions, hierarchies are considered as
syntactic problem while the functional relationships between
classes, within and across hierarchies, are considered as
semantic problem. This is similar to the association concept
between objects [Date C.J., 1995]. The relationship between
hierarchies is the second semantic level. The relation between
contexts, i.e., different databases, is the third semantic level.
Relationship between contexts is defining the relationship
between different GIS applications. The highest level of
semantics is the relationship between nodes.
In the subsequent sections the semantics of classes, hierarchies,
contexts, and nodes, are explained. FGDC metadata standards
and add-hoc knowledge bases will be used simultaneously to
model the two parts of semantics, i.e., metadata and
relationships, respectively.
4. SEMANTIC DATA SHARING: A PROPOSAL
The semantic domain sem (D) is defined as the set of attributes
used to define classes, hierarchies, contexts, and nodes
sem (D) =<Y,, Y,, Yz, ..., Y.> where each Y,; is an attribute.
For each value d in the domain of D the semantics of that value
can be defined in terms of the semantic domain as
sem (d) = <y;, Y2 ys ..., y,» Where y; e domain (Y;)
61
