--- Begin Message ---
- Subject: Re: latest Catalog XML
- Date: Sat, 08 Jun 2002 10:43:55 -0400
Hi 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 ---
