Im trying to think what is the meaning of serviceType="Catalog" in general?
What should the client assume? It seems that if you want the client to be
able to get the collection as a dataset, then you add a dataset element. If
you want the client to "drill down" further, then a collection or catalogRef
element can do that. What I have removed is the clear association between
the dataset element and the collection, eg that these are the same thing. I
have also made it more cumbersome(need two elements). I agree these are
weaknesses.
The client does not know that these are two different ways of looking
at the same thing -- the key piece of information that was trying to be
conveyed. The client does not have to present both -- maybe
the client only presents THREDDS choices because it has no DODS capabilities,
another client does not present the drill-down because it does have DODS capabilities.
The fact that you can produce a dataset as COARDS vs DIF, etc is also for me
not so great of an example. Rather than modifying the underlying data acess
(eg DODS), it seems simpler to add a metadata element. I admit that this is
just an idea which has not been done yet. And you already have a server that
does in fact modify the data access. But think of it from a client POV.
Should she search through the services looking for a service of type DODS,
subtype COARDS? Or search through the metadata looking for COARDS metadata,
independent of service type?
My point was your metadata tag was services for metadata.
clients that can only handle COARDS metadata would ask for COARDS metadata
services.
DODS already has multiple services -- ascii is not necessarily present, some of the selection interfaces are optional, metadata is optional.A more compelling example would be where the dataset is served up through
FTP and DODS, and ADDE, etc. But then I wonder/doubt whether one URL is
likely to be able to be used for all these services.
>
> I am also concerned about XYZT clients (4D world view) -- how can I
protect
> them against higher (and other) dimensional data (ensemble member count,
> spectral, different kinds of time (forecast start, lead, target time)? I
> could convert to multiple datasets, or spatial grids, but it would be nice
to
> advertise the service. As well as supporting various binary and ascii
data
> formats. Or the THREDDS dataset (as opposed to collection/catalog)
> description...I am not clear of "protect", did you mean "project" ?
Protect -- 4D world clients simply fail when given something else,
I would like them to have an alternative.
> 2) The access for the dataset LEVITUS94 is again via THREDDS (the present
> collection) or via DODS (the access statement). Adding another dataset
inside
> the collection called "Daily" is not the same meaning at all.Sorry, I should have had:
<dataset name="LEVITUS94 dataset" urlPath="SOURCES/.LEVITUS94/dods"/>
<catalogRef xlink:title="Drill down into dataset"
xlink:href=""http://iridl.ldeo.columbia.edu/SOURCES/LEVITUS94/thredds.xml">http://iridl.ldeo.columbia.edu/SOURCES/LEVITUS94/thredds.xml" />In this case the dataset is presented to the user for immediate selection
AND a link is presented for drilling further down.
This is the wrong example: LEVITUS94 was a collection that
was also available through DODS -- now you have lost it completely.
It is an example for the subdatasets ANNUAL, etc, with the flaw that
clients no longer can tell that these are two different ways of getting
the same thing as mentioned above.
Besides, multiple services also will show up in aggregations of THREDDS catalogs -- multiple servers serving the same dataset could be represented as a single entry with multiple services -- in this case, services with identical attributes except for path information.
As I mentioned earlier, not all DODS servers have all the services. Even if they did, it would not hurt to be able to list them.
The main thing service does is to let you specify a type and factor out the
common URL base. then this is passed to "protocol aware" code. Because the
das,dds,dods,info,ascii subservice URLs are always regular in how they are
formed, it seems unnecessary to actually specify them. In principle
subservices are probably useful but some concrete examples are needed.
While I have not given examples, different datasets will have different
> services, which is why I kept specifying using the access tag. Some
datasets
> will be incompatible with certain representations, so the service lists
will
> vary. One could argue that the THREDDS standard collection is a dataset
not
> available via DODS -- certainly that is the case for me.I understand you want to compactly specify what services are available for
datasets. Im not sure we have enough examples to make sure we are doing it
right. I am also oriented towards incremental design, doing what we can get
right and iterating.
OK with me, but we have lost the structure I was trying to express
-- alternate ways of accessing the same object, with emphasis on the same
object.
Benno
-- Dr. M. Benno Blumenthal address@hidden International Research Institute for climate prediction Lamont-Doherty Earth Observatory of Columbia University Palisades NY 10964-8000 (845) 680-4450