[Esip-discovery] metadata in atom feeds
jeffmc at unavco.org
Mon Jun 25 08:17:41 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,
The service end points for the LiDAR collections are NLAS specific and
do not follow any standard conventions. They allow you to do the
subsetting and product generation that is available through the web form:
I see that for other data (e.g., netcdf) I am not adding the opendap
links. I also see that I am not adding the file download links. I'll add
support for that.
> gmd:identificationInfo, gmd:contact, gmi:platform elements (not gmd or gmi
> schema valid), and what the non-namespace qualified elements (fields,
What isn't valid with those elements? I'll pass the info along to the
developer who defined those mappings.
> 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.
RAMADDA provides a very flexible metadata model. It can support DIF,
THREDDS and most any other metadata schema along with quite a large
number of custom metadata elements. Each of these metadata types can
then have mappings into various output formats (i.e., crosswalk). I
believe the above cited elements are DIF.
> 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
Oh, I see that now about the <content> element:
We want to have something in the atom feed that grouped the extra
metadata. Any suggestions? Maybe a <metadata> tag?
> 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.
The problem with having common conventions is you end up with a
monstrosity like ISO - a big old kitchen sink of metadata types. But,
as big a metadata type system as it is we couldn't even find metadata
elements for describing some very basic metadata like the data
dictionary in the LiDAR entries.
More information about the Esip-discovery