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

Re: orthogonality (was Re: New attempt)



Joe Wielgosz wrote:
> 
> Oops, forgot to send this one to the list..
> 
> Just for completeness here it is again:
> 
> Hi John,
> 
> I didn't respond directly to all the questions you asked but I hope that
> what I wrote is sufficient...
> 
> John Caron wrote:
> 
> snip..
> 
>  >
>  >>Thus I agree with benno that there is not a very
>  >>meaningful distinction between them (and reconsider my listing of them
>  >>as orthogonal concepts in my previous message).
>  >>
>  >>I wonder if it would be a good idea to merge these concepts and use a
>  >>less loaded word, say "entry", to refer to an entity that has meaning to
>  >>THREDDS and to end users, but not to a data access protocol, i.e.
>  >>
>  >><catalog>
>  >><service name="X"/>
>  >><service name="Y"/>
>  >>...
>  >>
>  >><entry name="my_dataset">
>  >>
>  >>    <metadata name="global-metadata" url="..."/>
>  >>    <access name="global-X-access"/>
>  >>
>  >>    <entry 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="..."/>
>  >>      ....
>  >>    </entry>
>  >>
>  >>
>  >></entry>
>  >>
>  >
>  > Ok so an "entry" meets meaning 1), while an "access" meets meaning 3) (we
>  > dont need to worry about meaning 2) here).
>  >
>  > Some questions:
>  >
>  > 1) Should we understand that all the access elements within an entry are
>  > different versions of the same dataset? Should we disallow:
>  >
>  >      <entry name="monthly-data">
>  >        <metadata name="monthly-metadata" url="..."/>
>  >        <access name="monthly-data from MARS" serviceType="X" url="..."/>
>  >        <access name="monthly-data from VENUS" serviceType="X" url="..."/>
>  >      </entry>
>  >
> 
> No, I was not implying that for an <entry> tag. I would allow your example.
> 
>   > 2) is there any relationship between peer elements, in your example
>   >
>   >      <access name="global-X-access"/>
>   >      <entry name="monthly-data">
> 
> Not necessarily.
> 
> I think what I am trying to suggest is while it may be useful for humans
> to think of some consistent object being accessed via different
> services, this really does not translate it to anything meaningful at
> the machine level.
> 
> Unless we actually try to define some machine-readable relationship
> between the accesses (e.g. Type 1 aggregation, etc - which gets into the
> whole data model can of worms) the only thing a machine can understand
> is a named and described hierarchy of access objects.

But what is the semantics of a hierarchy of access objects? The container
elements "contain" all the contained elements. Obviously I guess but what do we
mean by "contain"? Certainly the relationship between the contained elements can
be pretty loose. But, at least in my model of collection/dataset, a container
elements metadata applies in some way to all the contained elements. Which means
the container element represents some kind of an aggregation of the contained
elements.

Certainly there is no way to enforce that an <access> element and any sibling
<entry> element's  <access> elements have any particular relationship. But what
is the point of building such a catalog except to show some relationship between
the aunt/niece <access> elements.

Can we skirt the "data model can of worms" by trying to discribe different kinds
of containment: "parts of the whole", "parts of the whole that together make up
the whole", etc.

> Of course, something is being lost here from the human's point of view.
> Humans seem to want to make a distinction that is not significant to
> machines:
> 
> "a collection of accesses to some single underlying object"
> vs
> "a collection of accesses to different underlying objects, that share
> some common theme"

> Is this is what <dataset> and <collection> have been intended to mean?
> 
> If this is the case then I would suggest that
> 
> a) this distinction be preserved by allowing both tags to be
> used(possibly renamed if it would clarify things); and
> 
> b) data providers should be encouraged to mark up their catalogs
> appropriately using the two tags, so that THREDDS client UI's can take
> advantage of this to present catalogs in an intuitive way; but
> 
> c) these tags should be completely interchangeable in all other ways
> (i.e. same type in the DTD/Schema, and same API calls, any tag that can
> go in a dataset can also go in a collection), since they are
> semantically equivalent at a machine level.

That seem to capture my view of the difference. I'll rephrase to see if I am
interpretting your description correctly. <collection> elements contain things
that are somehow related. <dataset> elements contain alternate views of an
object (i.e., <access> elements) and views of parts of an object (i.e.,
<dataset> elements, siblings of the objects <access> elements). So <collection>
and <dataset> are defined exactly the same but have different meanings.

Ethan

> Does that make any sense? Benno, would that satisfy you?
> 
> - Joe (ready for a checkup with my ontologist)
> 
>  >
>  >
>  >
>  >
>  >
> 
> --
> Joe Wielgosz
> address@hidden / (707)826-2631
> ---------------------------------------------------
> Center for Ocean-Land-Atmosphere Studies (COLA)
> Institute for Global Environment and Society (IGES)
> http://www.iges.org

-- 
Ethan R. Davis                       Telephone: (303) 497-8155
Software Engineer                    Fax:       (303) 497-8690
UCAR Unidata Program Center          E-mail:    address@hidden
P.O. Box 3000
Boulder, CO  80307-3000              http://www.unidata.ucar.edu/

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.