The graphic user interface, GUI, at the global server will 
provide non members with limited access to the federation 
resources. Users at this level will not have the high level of 
semantic tie provided to the federation members. The data 
they request will be provided to them either in the global 
schema specifications or that of the data provider. However, 
this is outside the scope of this paper. 
At the user’s site three components will be added: 1) FGIS 
driver which is similar to the one at the global server. 2) 
Query optimizer which will access the schema and the 
metadata in order to retrieve the required data and/or 
processes. 3) a sharable hierarchical schema and its 
supporting hierarchical metadata. The context tree will be 
further expanded at this level. The schema conforms with 
the OGIS specifications, and the metadata conforms with 
FGDC specifications. 
The Global Serves 
Meta- 
Global 
Data 
-► Schema 
Query 
Optimizer and 
Search Engine 
FGIS Driver 
Query Optimizer and 
Search Engine 
Query Optimizer and 
Search Engine 
i 
Inerface 
! Inerface j 
t, 1, 
t i 
Meta- 
c . Meta-: - 
^ Schema 
, Data 
-4— 
Server 
Data ' 
Server i 
4 
l \ ’ 
1 T 
GIS 
i 
i 
GIS 
GUI 
Figure 5 Federated GIS Testbed 
This architecture will be implemented in 4 phases: 1) at the 
global server a process will start to identify the relevant 
context(s) where the requested objects might reside; 2) 
identifying the semantic relation between the context of the 
service requester and the service provider. This is also done 
at the global server; 3) identifying the relevant classes, i.e., intensions within the context(s). This is done at 
the component database which owns the data; 4) identifying the set of objects, i.e.. extensions. If there 
exist more than one candidate context that satisfy the query, a cost/benefit model can be applied. However 
this is outside the scope of this paper. 
5. Conclusions 
A description is presented in this paper of an architecture for data sharing between heterogeneous 
geographic databases in order to support decision making for watershed management. This architecture 
was supported by a mechanism for semantic data sharing. Building semantics onto the syntactic structure 
of geographic objects allow users to post queries to the underlying federation using their own semantics. 
The system then should automatically resolve semantic differences and reply to the user. Semantics in our 
context here refers metadata and object behavior. Once they are defined objects can be uniquely identified. 
Structuring metadata into a schema and build an inference engine that accesses it as suggested in this paper 
will hide from users the complex and mostly ambiguous metadata. 
We still have a long way before reaching the ultimate goal of providing semantic data exchange 
mechanisms. As a starting point the focus of the research community should be on devising methods for 
capturing, storing, and manipulating semantics of databases in general and geographic databases in 
particular.