[Esip-discovery] metadata in atom feeds
steve.richard at azgs.az.gov
Mon Jun 25 00:34:54 EDT 2012
Jeff-thanks for the information--
Looking at the atom response I think should clarify my question. The
standard atom elements are of course there (id, updated, title, author,
summary, link, content...) and some extensions (time:, georss:), but in
order to understand how to write client software to utilize the links
provided or the information in the <content> element, one would need to
understand the rel="points...." links, the use of MD_metadata,
gmd:identificationInfo, gmd:contact, gmi:platform elements (not gmd or gmi
schema valid), and what the non-namespace qualified elements (fields,
ISO_Topic_Category, Data_Set_Citation, Use_Constraints etc.) are. This is
what requires documentation; a link to the api.html doc in the metadata
would probably be useful.
I only looked at the first entry in detail, but if I were trying to harvest
this atom feed to understand what is offered and how to index the fielded
information, it would be hard and involve guessing. Isn't an
atom:entry/atom:content element supposed to contain the actual resource
anyway, not metadata for the resource? I also think OpenSearch is capable
of describing URL patterns for any MIME type resource, not just atom, and
could include the various search template elements outlined on the api.html
One of the biggest leaps we could make towards simplifying and improving
resource discovery would be to look for common conventions for resource
description encoding, and some patterns for core and extension metadata, and
then use them.
From: Jeff McWhirter [mailto:jeffmc at unavco.org]
Sent: Sunday, June 24, 2012 7:21 PM
To: steve.richard at azgs.az.gov
Cc: esip-discovery at lists.esipfed.org
Subject: Re: [Esip-discovery] proposed marketing pitch for Discovery client
> Jeff-- the Ramadda opensearch.xml link you provided is pretty minimal.
> It only lists the required application/atom+xml output format URL
> pattern. 10 minutes cruising the Ramadda web site didn't reveal any
> additional information on output formats of what the metadata encoding
> conventions in Atom are. It first needs better documentation to be
The atom response provides the standard set of metadata elements.
Depending on what the results are you can get a variety of metadata. For
example, the NLAS LiDAR Collection content provides a number of services and
NLAS specific metadata, e.g.:
Here is the atom result for the fixed search:
We use georss, iso and some custom NLAS specific metadata elements (data
dictionary field definitions).
The opensearch description document produced by ramadda does not reflect the
full suite of search capabilities that RAMADDA provides. This is a
shortcoming of opensearch not of ramadda.
I thought the whole point of following a standard was to not have to know
much about the implementation? What kinds of documentation do you need?
More information about the Esip-discovery