Woops realized that I simply responded to John. Peter -- Peter Cornillon Graduate School of Oceanography - Telephone: (401) 874-6283 University of Rhode Island - FAX: (401) 874-6728 Narragansett RI 02882 USA - Internet: address@hidden
--- Begin Message ---
- To: John Caron <address@hidden>
- Subject: Re: latest Catalog XML
- From: address@hidden
- Date: Sat, 08 Jun 2002 10:43:55 -0400Hi all, An interesting discussion. I wrestled a bit with this around the time of the DODS developers meeting last January. I have attached a table that I put together to help me keep track of the issues. I think that you have progressed way beyond this, but thought that you might find it interesting anyway. Peter John Caron wrote: > > heres another strawman, incorporating our latest discussions: > > http://www.unidata.ucar.edu/projects/THREDDS/xml/InvCatalog.0.6d.dtd > > Recent changes: > > 1) Collections as datasets. Ethan and I think the cleanest way to allow > "collections as datasets" is to allow nested datasets. Collections remain > just groups of datasets. A Collection as a dataset is done as a dataset with > nested datasets. Nested dataset elements (Joe's meaning #2) should imply (in > some way we need to clarify better) nested datasets (Joe's meaning #1 and > #3). > > 2) allow compound services again. I have talked myself into that these will > be often useful. > > 3) services are now contained within any collection, rather than having to > be all in the top catalog element. They are scoped by the collection they > are in (so we no longer use ID, since those are global). This makes a > catalogRef have (almost) the same semantics as a collection. > > 4) a catalog now only has exactly one collection element. (i considered > eliminating catalog but i think its better this way). > > 5) "attribute" changed to "property" (tired of saying "the attribute > attribute") > > 6) access element can specify an absolute URL with a serverType -or- a > reletive URL with a serverID. > > Unless I get a barrage of objections, I will document this in more detail > ASAP. I will be gone for a week starting next Tuesdy, so Ethan will continue > the conversation as needed. Hopefully, we can converge soon and take a > break! I think I have incorporated all the good ideas i have heard in this > discussion. Have I left out something, or do you think any feature is not > worth the complexity? -- Peter Cornillon Graduate School of Oceanography - Telephone: (401) 874-6283 University of Rhode Island - FAX: (401) 874-6728 Narragansett RI 02882 USA - Internet: address@hiddenTitle: Oceanology International
OPeNDAP Data Objects, Collections and Sets
- OPeNDAP Data Objects are the data retrieved by any OPeNDAP URL (constrained or unconstrained).
- a portion of a satellite image
- a mooring record
- OPeNDAP Datasets (or OPeNDAP Granules) are OPeNDAP Data Objects accessed by an unconstrained URL.
- a satellite image
- a mooring record
- a NetCDF file that contains all satellite images in a given projection from a specific sensor
- OPeNDAP Data Collections are collections of OPeNDAP Datasets that are accessible either
- as a new OPeNDAP Dataset via an OPeNDAP Aggregation Server, or
- as a list of OPeNDAP Datasets via a File Server.
- all satellite images in a given projection from a specific sensor
- a collection of mooring records
Note that the list of OPeNDAP Datasets accessed via an unconstrained request to an OPeNDAP File Server is also an OPeNDAP Dataset.
- are all of the meteorological or oceanographic data at a site that the data provider considers to be logically connected. Could be an OPeNDAP Dataset, an OPeNDAP Data Collection or a group of OPeNDAP Datasets that are not formally linked from an OPeNDAP perspective.
- all satellite images in a given projection from a specific sensor for which neither an OPeNDAP File Server nor an OPeNDAP Aggregation Server exist
- a NetCDF file that contains all satellite images in a given projection
--- End Message ---
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.