download as a pdf - Southern California Coastal Ocean Observing ...

Part III. Appendix 2: Data Transportearlier comparison of OPeNDAP’s Grid datatype to FSDM’s Field object, with the Grid’s locationsequence being analogous to the Mech object and the variable values to the Data object. Instead,compare the Field object to the DDS, the Data object to the DataDDS, and the Mesh object to theDAS. FSDM may suggest ways in which the OPeNDAP portion of the early IOOS system can bebrought to the level of expressiveness required in the mature IOOS system. Perhaps the DataDDSwill acquire translational use metadata, as the Data object apparently does. Perhaps the DDS or aroot-DAS will become a directory to metadata distributed among multiple sites and capable of beingupdated and added to over time by users of the data, as the Mesh object can contain more variedinformation than does DAS as presently employed.SRB comes into its own in this aspect of the mature IOOS system: it embodies much thought andeffort at making intentional, coordinated use of a capability provided by the World Wide Web, thatis, that a collection of identifiers of things available over the Web (designated by URIs and URLs)can be constructed and manipulated, modulo synchronization issues, as though they were thethings themselves, provided you have sufficient information about them, that is, metadata. Perhapsthe SRB collection is analogous to the FSDM Field object or the OPeNDAP DDS. Perhaps the collectiongroups all the metadata associated with a data set before or after aggregation and/or subselection.Perhaps the operations envisioned for OPeNDAP/NVODS mediating servers, for example,such as the Aggregation Server or the Restructuring Server, can be viewed as manipulations of SRBcollections and their components.Free choice of semantic models for metadata storageand retrievalThe fifth requirement, that IOOS servers and clients be free to use different semantic models forthe same information, makes a point which may at first seem to contradict some implication ofthe third requirement, which says that information which is potentially or in fact equivalent eithercould be or is transmitted identically. To the extent that two design goals are sought (1: identicaltransmission of equivalent data, and 2: preference for direct, unmediated server-client transactions),the third goal implies that each server will be able to determine whether requested informationcould be expressed in a conventionally agreed upon form and transmit it accordingly. The fifthgoal, however, speaks to the question of the structures imposed upon metadata and means thatusers ought to be able to ask for metadata, that is, information about a data set, in more than justone way and get their answers as well assembled in various patterns. The implications of this desideratumare not entirely clear; all that is evident is that the Data Transport Team would like it tohappen.183