* Developing experiments, instrumentation, algorithms, 
and hence new kinds of data is an integral part of 
scientific research. Different science disciplines may 
have valid preferences for different or new data formats 
and tools. The architecture cannot make adherence to 
strict data interchange format standards or the use of 
specific tool sets a precondition of network operation. 
« Scientists collaborate on research projects and 
exchange scientific information in many different 
ways. For example, scientists may want to obtain the 
latest set of re-calibrated satellite data or the outputs of 
a revised earth atmospheric model as inputs to their own 
analysis. The architecture should facilitate this kind of 
collaboration and exchange and extend to new ways of 
collaboration which future technologies may enable. 
* A key objective of the Global Change Research 
Program is the establishment and maintenance of a high 
quality set of earth science parameters for an extended 
period of time which have research community 
consensus [from 'Global Change Data and Information 
System (GCDIS): A Draft Tri-Agency Implementation 
Plan, DOUNASA/NOAA, March 1992]. The research 
community as a whole has been challenged to cooperate 
in the validation, upgrade, and description of this data. 
The architecture needs to support the research 
community in finding relevant data, in the analysis and 
critical review of this data and the publishing and 
dissemination of new and revised data products. 
* The science expertise is distributed on a world-wide 
scale. The architecture should make it possible to 
distribute the appropriate functions and data to where 
the expertise resides. The cooperative endeavor 
envisioned by the GCRP also means that the 
architecture must allow researchers to take advantage of 
the distributed functions and data in collaborative 
efforts. 
» Scientists would like to access scientific information in 
many different ways. The architecture should extend to 
new ways of data access which future technologies may 
enable. Data volume makes it impossible today to 
perform large scale searches on science data based on 
their contents, but the rapid evolution of processing 
and storage technology may change that in the not too 
distant future. 
e The collaboration between geographically distributed 
researchers is limited by current communications 
facilities to file and mail exchanges. In the future, it 
may be possible to exchange data in real time, and view 
and browse them in a coordinated fashion while 
communicating annotations and comments. Such 
developments will have a profound impact on how earth 
science information is accessed and used for research. 
* ]t is a characteristic of global change research that it 
tries to correlate information which spans long periods 
of time, and that experiments may go on for many 
years. Therefore, the architecture must be able to 
accommodate the long term evolution of technology 
and its application to science, but at the same time it 
must provide some measure of stability, e.g., in terms 
of backward compatibility. 
The system architecture for EOSDIS must support both users 
and service providers. The concept of a service is 
32 
synonymous with the concept of data, since data can only be 
accessed through a service (e.g. ftp, DBMS, etc.). The users 
of the system want to be able to find and access relevant 
services within the system as efficiently as possible. 
Service providers want to be able to support the mission 
objectives in terms of capturing and maintaining the 
important data sets, and ultimately providing the best 
services possible to the user community. To achieve the 
latter goal each provider needs the flexibility to organize 
their data and services in the most appropriate way for their 
user community and be free to re- configure existing services 
and add new ones to accommodate new user requirements 
and/or new technological capabilities. 
In this scenario of autonomous service providers, there will 
inevitably be the potential for incompatibilities between 
the services available from the system and a user's query, or 
the tool they are using to access the service(s). The system 
must recognize that incompatibilities will exist and assist 
the user in overcoming them as effectively as possible. 
An important focus for EOS is interdisciplinary science. 
This will lead to user requests which cannot be resolved by a 
single service or even a single service provider. The system 
architecture must therefore support the concept of multi-site 
requests, which must be partitioned and managed between 
several services. An example of this type of request and how 
it might be managed is shown in Figure 2. 
The main objectives of the architecture are, therefore, the 
definition of (a) capabilities which let a scientist locate, 
obtain, or use resources which are available in the network 
(e.g., tools and data); (b) features which would help a 
scientist cope with the ensuing problems, e.g., of 
differences in data formats, terminology, and tool input and 
output requirements; and (c) support functions which would 
make it easier for scientists to collaborate on research 
projects across the network. 
In widening the constraints of the architectural concern from 
the earth observation focus of EOSDIS towards global 
change research, to the wider earth science focus of GCDIS 
and UserDIS, there are many issues which are wider in scope 
than if the EOSDIS requirements alone were being 
considered.. These are discussed in the GCDIS/USerDIS 
study (NASA, 19942) and are summarized below: 
+ There will be considerable variety in the user 
objectives, missions and priorities. Users will also be 
data providers. 
» The architecture must not assume a common 
information model or management system. The 
adoption of evolving standards should be encouraged 
within the GCDIS / UserDIS community, though this 
should be achieved through participation in the 
standards process by the agencies and organizations 
involved rather than the development of specific 
standards for these systems. 
+ There should not be any restrictions on the number of 
providers, their location and the data/services they 
provide. The system must be able to cope successfully 
with dynamic data and network topology. 
All responsibilities for system management or 
development policies and authorities will be voluntary, 
though within a part of the system, such as EOSDIS, can 
be mandated by some management authority. The 
architecture must therefore accommodate autonomously 
managed 
managem 
authentice 
system sh 
network \ 
e The data | 
cost effec 
should av 
providers 
e The archi 
within an 
quality in 
accuracy, 
Taken toget] 
„significant ch 
EOSDIS if it 
major supplie 
important ther 
to achieve wit 
open to future