Hi, comments below
----- Original Message -----
<thredds@xxxxxxxxxxxxxxxx>
Sent: Tuesday, June 04, 2002 12:23 PM
> Hi John,
>
> Thanks for the response. I have a couple of thoughts:
>
> 1) serviceType="Catalog" is the same as catalogRef elements, that is true,
> *but* what I was trying to express is that the datasets that are available
via
> dods are also available as THREDDS catalogs. You have deleted that
information
> -- in your version, datasets are only available as DODS datasets. And
deleting
> the suffix part destroys the compact representation of compound services
for
> servers that uses suffixes, i.e. ingrid and typed-file servers (http,ftp,
etc,
> with a fileextension convention), and servers that have query-based urls
with
> one tag that distinguished the format of the response. I only had two
> services to make the example clear -- many servers are going to have
multiple
> services, that was the point, and I have many more services that could be
> described once THREDDS matures. For example, a lot of clients are
written to
> COARDS -- I can generate metadata and datasets that conform, though
frequently
> that is a poor description of the data. But if the client insists, and
> THREDDS allows the constraint, the servers and clients could communicate.
> The metadata tag is really a set of services for metadata (i.e. metadata
as
> DIF, etc), which you are certain will alway be multiple.
Really I am playing devils advocate for simplicity, so I am just looking to
see what happens to try to fit your examples into the current (sort of
simple) design. So really we need a concrete example that could make good
use of a compound service.
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 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?
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" ?
It seems that you are trying to provide various services within this catalog
framework. I see that you provide a lot of these through an HTML interface
in INGRID. I think here we want catalogs and any associated services to be
useable by client software, so they have to be very clearly defined to be
useful, much more so than an HTML page that can assume human intelligence.
Some concrete examples would be good.
>
>
>
> 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"; />
In this case the dataset is presented to the user for immediate selection
AND a link is presented for drilling further down.
Now in your case the equivilent is:
<access serviceID="IngridDataset" urlPATH="SOURCES/.LEVITUS94/"/>
and because the "IngridDataset" service has a contained service of type
"Catalog" the user should know that she can drill down further into this
dataset? Should the rule be to present this catalog as a catalogRef ?
>
> 3) I thought multiple documents was more analagous to to multiple
datasets
> within a collection, leaving documentation as the unnamed tag within a
> collection. I am also concerned about having names for datasets and
titles for
> documentation -- seems unnecessarily confusing to give different names to
the
> same concept in different contexts. But documentation tags work for me
as
> well as document tags.
Yes, good point I started using "title" to follow XLink, maybe we should
propagate that to dataset for consistency.
Right now, documentation means "present this to the user during dataset
selection". With xlink:show semantics, I thought that we could accomodate
what you are doing with your "view" HTML pages.
>
> So can we go back to the suffix attribute? And multiple services?
Datasets
> as collections, or access allowed as an subelement of a collection?
(After
> all, why not be able to serve collection metadata in multiple ways?)
Anyone else have opinions on this?
>
> Compound does not have to be the only service with sub services: perhaps
you
> should restructure DODS as a service with das,dds,dods,info,ascii
subservices?
> Likewise for OpenGIS?
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.
