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


> John Caron wrote:
> > I sympathize with this design, but there are a number of subtle issues
> > I think we need to clarify before we commit to it. Lets follow your line
> > 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"
> >       <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
> > 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
> of standard tags, clients are not going to make much use of them, so I
> 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
> think names should be discouraged.   My vision of access was to tell
> that it had different ways of accessing the data, not telling users that
> were options.

i agree

> COARDS is actually a bit of a confusing example.   It is a metadata
> however, the problem that I was trying to address is that clients are
> such that if the dataset is not structured precisely as COARDS demands,
> 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
> 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
> 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
> DODS to handle anything that can be served with DODS, but there are not
> 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.