----- Original Message -----
Sent: Friday, June 14, 2002 10:13 AM
> In the spirit of wouldn't-it-be-nice, I'll put out a request for a better
> I think we are missing the boat a bit with respect to the metadata tag,
but I am
> not sure of the solution. Consider GCMD, for example. You have
> as one of the metadata types, but from a client point-of-view, that is
> than what can be done.
> Consider for example, HELLERMAN, which is a GCMDID. With that id, I can
> the GCMD for many versions of the metadata, including I suppose the DIF
> itsself (though offhand I do not know how to construct the URL to get the
> Sample url (html):
> Obviously if I am writing an HTML client, the html version would be nice.
> am editing DIFs, I probably want the DIF version, etc.
> So are these different metadata? Or are they metadata-services on the
> metadata, i.e. I can get it translated by various servers?
Currently there is a documentation element and a metadata element:
"A documentation element contains or refers to content that should be
displayed to an end-user when making selections from the catalog. The
content may be HTML or plain text. We call this kind of content "human
"A metadata element contains or refers to structured information about
datasets, which is used by client programs to properly display or search for
the dataset. Typically, metadata is not displayed to an end-user when
making selections from the catalog, although it may be useful to make it
optionally available. We call this kind of content "machine readable"
For GCMD, I would expect us to add some GCMD-specific code in our client
libraries to take maximal advantage of the GCMD DIF metadata, but its not
obvious that there are lots of different variation of the DIF metadata for a
For documentation elements that are displayed to humans, I would expect the
catalog builder to select what they think are the best links that will be
useful to humans browsing the catalog, and use the link title to indicate