[Esip-discovery] metadata in atom feeds

[Jeff McWhirter]

Hi Steve,

> 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:
https://nlas.unavco.org/repository/entry/show?entryid=fdcc5945-1dc8-4d6b-beb2-93cf452e9a60&output=points.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: 
http://tools.ietf.org/html/rfc4287#section-4.1.3
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
> page.
>
> 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.

-Jeff