[Esip-discovery] Service Casting and Data Casting confusion

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

On Jul 26, 2011, at 5:47 PM, Sky Bristol wrote:

<snip>
> Note on future direction...
> 
> The overall discovery process of having data providers cast out their stuff seems pretty sound. The bar for entry with an ATOM feed is pretty low, and the specification really has most of what is needed to facilitate basic discovery and understanding of a pretty wide variety of items. Links to access points or further information are one of the most important parts of working with an item, and the service casting method seems pretty well founded for that dynamic. An alternate approach we might consider would be to use URIs in place of the "scast" convention on rel and then facilitate some form of URI library or registry (perhaps using ESIP as the coordinator). The registry would then provide further information on the meaning and purpose of various types of links and could cross between standards and protocols beyond ATOM/RSS.
> 
> For instance, I might want to include a URI that points to something more specific that tells an application that the link is specifically to an OGC-WMS version 1.1.1 instead of the generic scast:serviceEndpoint. I might also want to include a link to the ISO19137 XML rendering of an item's metadata so that an application could go get that view of the item if needed.

Sky,
  We are actually moving partially in this direction by proposing specific rel URIs for "well-known" standards.  The current Discovery Change Proposal-2 is doing exactly that.  See http://wiki.esipfed.org/index.php/Discovery_Change_Proposal-2, and you are welcome to vote as well.  
  We did not envision using a registry at this point, though, just proposing each specific standard protocol as a part of the ESIP Discovery Conventions.  THis is not very scalable, but manageable if the number of standards to be supported is small (a dozen or less).

--
Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185