[Esip-discovery] ESIP Discovery Cluster Telecon, Tuesday, Aug. 9 @ 4:00 ET / 3:00 CT / 2:00 MT / 1:00 PT

[Lynnes, Christopher S. (GSFC-6102)]

On Aug 10, 2011, at 12:43 AM, Hua, Hook (388C) wrote:

> Hi James,
> 
> For Approach #5, we never really discussed what the exact attribute name would be. We only floated the methodology of using a new namespaced attribute. 
> Eric's posting here has a good pros/cons:
> http://wiki.esipfed.org/index.php/Talk:Discovery_Change_Proposal-2
> 
> The difficulty is in how to achieve compliance with RFC 4287 Atom while supporting both "general" (e.g. data link) and "specific" (e.g. OPeNDAP 3.3) relations types in the links.
> http://tools.ietf.org/html/rfc4287#section-4.2.7
> Nothing for "specific" fits with in the current RFC spec. Thus the idea for approach #3 using fragments in URIs was also discussed.
> 
> Approach #1 would work with on general relation type if we treat it like a taxonomy of more specific subclasses of relations. But then we would have to maintain and reference an external taxonomy or ontology. If we are heading towards semantics anyways, then it may not be such a bad approach...
> 
> Also, is anyone familiar enough with OGC OpenSearch on if and how it may be dealing with this type of issue. Perhaps there should be some convergence in the future.


>From what I have seen of OGC OpenSearch, they are not quite as specific as we are.  I believe they are treating data links as simple rel="enclosure".  Remember, when we got initial feedback on DCP-1, there was a recommendation from a member of the OGC community to use only the standard rel values, i.e., "enclosure" for data, "icon" for browse, and "related"(?) for metadata.  For more on the standard link relation types, see: http://www.iana.org/assignments/link-relations/link-relations.xml
--
Christopher Lynnes     
Goddard Earth Sciences Data and Information Center, NASA/GSFC
301-614-5185