Once a researcher is freed from the confines of using only local data, he or she will soon discover that there is a wealth of data available on the Internet, and nearly all of it is stored in formats incompatible with her own. Worse, the data formats are often mutually incompatible, rendering the confusion complete. OPeNDAP provides a solution applicable to a great many such problems.
When an OPeNDAP server retrieves data from some distant machine, that data may be in any of several file formats supported by OPeNDAP. The server translates the data, however, into an intermediate format for transmission. Upon receipt of the messages containing data, the OPeNDAP client software unpacks the data into the form expected by the calling client program and returns it to that program. Because all data must be translated into the same intermediate format, OPeNDAP becomes a powerful format translator for datasets. In effect, this means that a program designed to read and display JGOFS data can look at the OPeNDAP data catalog and see everything as JGOFS datasets. A netCDF program can look at those same datasets, from that same catalog, and think they are all in netCDF format. This system of translation allows a researcher to ignore the question of formats and concentrate on the data alone.
Of course, there are some translations that cannot be done
transparently, if they can be done at all. Consider a two-dimensional
array of satellite sea-surface temperature measurements. Assume the
data is stored in netCDF format on some machine called
satt.uri.edu. The data might be uniquely specified by some URL,
say http://satt.uri.edu/sst/010694.nc. However, were a user to
feed that URL to a JGOFS-originated OPeNDAP client designed to draw
property vs. depth graphs of station data, no translation facility
would be able to map the original data into a form accommodated by the
client program.
The issues of data models and data translation are important ones to the data provider. These issues are discussed in detail in Section 6.1.2