NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
----- Original Message ----- Cc: <thredds@xxxxxxxxxxxxxxxx> Sent: Thursday, June 06, 2002 2:54 PM > HI John, > > I realized after I sent my e-mail that I had missed your point, sorry. s'ok > > John Caron wrote: > > > I sympathize with this design, but there are a number of subtle issues that > > I think we need to clarify before we commit to it. Lets follow your line of > > thought, and modify Joe's example to use dataset where he uses entry: > > > > <catalog> > > <service name="X"/> > > <service name="Y"/> > > ... > > > > <dataset name="my_dataset"> > > > > <metadata name="global-metadata" url="..."/> > > <access name="global-X-access"/> > > > > <dataset name="monthly-data"> > > <metadata name="monthly-metadata" url="..."/> > > <access name="X-with-COARDS" serviceType="X" url="..."/> > > <access name="X-with-no-COARDS" serviceType="X" url="..."/> > > <access name="X-flattened-to-2D" serviceType="X" url="http://..."/> > > <access name="Y" serviceType="Y" url="..."/> > > .... > > </dataset> > > > > </dataset> > > > > What is the relationship (if any) between the peers > > > > <access name="global-X-access"/> > > <dataset name="monthly-data"> > > > > The same question asked in a different way: > > > > What is the meaning that <dataset name="monthly-data"> is contained in > > <dataset name="my_dataset">. Do we expect monthly-data to be a subset of > > my_dataset? Do we expect that <access name="X-with-COARDS"/> is some kind > > of subset of <access name="global-X-access"/> > > Yes, a dataset being inside a dataset is exactly the same meaning that a > dataset being in a collection had. > > I am not convinced that access should have a name attribute -- I think that is > a mistake -- if different accesses cannot be distinguished by standard values > of standard tags, clients are not going to make much use of them, so I think > name should not be a standard part of an access. One could allow accesses to > have attributes if a server wants to make a non-standard distinction, but I > think names should be discouraged. My vision of access was to tell software > that it had different ways of accessing the data, not telling users that there > were options. i agree > > COARDS is actually a bit of a confusing example. It is a metadata standard, > however, the problem that I was trying to address is that clients are written > such that if the dataset is not structured precisely as COARDS demands, the > client will fail (XYZT ordering, for example). That is why I called it a > subtype of access, because I wanted to provide an access for clients that > require COARDS. Clearly one could also express the service with an attribute > of access called metadata-standard -- I have no particular attachment to > subtype. One could put togeter a catalog of COARDS-only datasets, and expect COARDS-only apps to use it instead of the general catalog. Its likely we will allow filtering a catalog on serviceType and metadataType which could give the equivalent fuctionality (for clients that use our library). > We also could have an attribute called worldview: that way 2D > clients and 4D clients could express their requirements, and servers might have > an opportunity to fulfill them. Probably have to handle this by negotiation between client with the server. > > One could also solve the problem by having all clients that claim they read > DODS to handle anything that can be served with DODS, but there are not too > many such clients. dont be bitter ;^} In a previous DODS thread I was floating some ideas on how to map DODS structures and sequences into a netcdf API. Not so sure that would really solve the problem. > > Benno > > -- > Dr. M. Benno Blumenthal benno@xxxxxxxxxxxxxxxx > International Research Institute for climate prediction > Lamont-Doherty Earth Observatory of Columbia University > Palisades NY 10964-8000 (845) 680-4450 > > >
thredds archives: