[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New attempt



----- Original Message -----
From: "Benno Blumenthal" <address@hidden>
To: "John Caron" <address@hidden>
Cc: "THREDDS" <address@hidden>
Sent: Tuesday, June 04, 2002 2:09 PM
Subject: Re: New attempt


> John Caron wrote:
>
> >
> > 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.
>
> >
> >
> > 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.
> >
>
> DODS already has multiple services -- ascii is not necessarily present,
some of
> the selection interfaces are optional, metadata is optional.
>
> >
> > >
> > >  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.

This may be difficult to provide this kind of negotiation in a standard way.
It may be pushing catalogs too far right now. But I would certainly be
willing to discuss it for future versions. Its like the WMS capabilities
feature.

>
> >
> > > 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.
>
> This is the wrong example:  LEVITUS94 was a collection that was also
available
> through DODS -- now you have lost it completely.

Im not sure how i have lost it. The intention is that the user can select it
as a DODS dataset (with the dataset element) or expand its details through
the catalogRef. I admit there is no formal connection between the two
things, the user may or may not be able to infer they are the same thing.

> 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.

I agree its a weakness.

>
> 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.
>
> >
> > 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.
>
> 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.


Right now I dont envision presenting the DODS services seperately to the
user in the catalog selection. The model is that 1) the user selects a
dataset from the catalog (no protocol dependence, no contacting the server
yet) then 2) the app. client reads the dataset and allows further selection
or information (contact server, protocol aware). So it seems to me like it
doesnt make sense to specify das,dds,dods,info,ascii in the catalog since it
is not used until the non-catalog part 2.

>
> >  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.

I will think some more about that, and ask if others have ideas about this
also. I also want to double check that this example:

<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";
/>

accurately reflects the capability you envision, except that there is no
indication that these two are 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
>
>
>


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.