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

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


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.