Re: orthogonality (was Re: New attempt)

----- Original Message -----
From: "Benno Blumenthal" <address@hidden>
To: "John Caron" <address@hidden>
Cc: <address@hidden>
Sent: Thursday, June 06, 2002 2:54 PM
Subject: Re: orthogonality (was Re: New attempt)


> 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          address@hidden
> International Research Institute for climate prediction
> Lamont-Doherty Earth Observatory of Columbia University
> Palisades NY 10964-8000                  (845) 680-4450
>
>
>