[Esip-discovery] RFC ready to go?

[Ruth Duerr]

Hi Chris,

I finally did my homework from the ESIP meeting.  I seriously think that there are enough differences between the Discovery cluster's conventions for OpenSearch/Collection Casting and Andy's Datacasting, that the two things should be kept quite separate.  So I disagree with Andy's suggestions below.  I've put a number of comments in the google doc but was unable to actually edit it.  

In any case, DataCasting has its own RFC and I think that is appropriate. 

As for what to call the document, I tend to agree with Andy that there are a lot of technologies that legitimately fall under the heading of "discovery".  The ESIP Discovery cluster has only worked on OpenSearch/Collection Casting, so perhaps the title should reflect that.

Ruth

On Jan 25, 2013, at 4:34 PM, "Bingham, Andrew W (3880)" <andrew.w.bingham at jpl.nasa.gov> wrote:

> Chris et al.,
> 
>  My apologies for not responding earlier – I'm not on the cluster email list and received your recent email only via Nga.
> 
> Below are my  comments to your RFC.
> 
> Andy 
> 
> 
> 
> 1.  Replace Section 7.1.2 with an introduction to Datacasting.  Below is my proposed text – which is intended to clear-up confusion with the peer-reviewed literature.
> 
> 7.1.2 Introduction to Datacasting
> Datacasting is  a publish–subscribe method where a data provider publishes the availability of new data granules (data files) via an XML feed and a data consumer subscribes to the feed to learn about recently available data (Bingham et al., 2009).   The Datacasting Project (http://datacasting.jpl.nasa.gov), which was funded under the NASA ACCESS Program (2005 and 2009), developed an RSS-based specification for the XML feeds, which is termed DatacastingRSS. A NASA RFC for DatacastingRSS is currently under consideration (https://earthdata.nasa.gov/wiki/main/images/a/a6/Datacasting-Standard-RFC-20121108.pdf).  In this specification, data files related to a data set are cast out in a single feed.  Linkages to the data set information is provided via elements embedded in the channel tag;  information related to the data file (spatial and temporal extent, link to the data file, browse representation etc.) are provided via elements embedded in the item tag.  The DatacastingRSS specification also allows for the definition and addition of "custom elements" that allows data providers to add their own elements to the item tag. The default and custom elements within the item tags, enables a Datacasting Feed Reader to filter lists of items so data consumers can discover and utilize specific files. 
>  
> In this RFC, we have slightly modified the definition of the term “Datacasting” - we consider Datacasting as a publish-subscribe method, but we extend its use for announcing the availability of data sets, as well as data files. The Atom specification proposed in this RFC therefore unifies the terminology for publishing data sets and data files.  However, the specification lacks the concept of "custom elements" that exists under DatacastingRSS and therefore limits the number of facets by which a user can discover files.
> 
> References
> Bingham A.W, S. McCleese, T. Stough, R. G. Deen, K. Hussey and N. Toole, 2009, Earth Science Datacasting: Informed Pull and Information Integration, IEEE TRANSACTIONS ON GEOSCIENCE AND REMOTE SENSING, VOL. 47, NO. 10, OCTOBER 2009. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5191107.
> 
> 
> 2.  The title "ESIP Discovery Conventions" is  too broad – I'd like to think that DatacastingRSS is an ESIP Discovery Convention, but obviously does not fit into your RFC!
> A more accurate title would be : Atom-based Discovery Conventions.
> 
> 3.  Include tables illustrating the Atom specification for OpenSearch and Datacasting respectively.  See the DatacastingRSS RFC for an example.
> 
> 
> ---
> Andrew W Bingham
> andrew.bingham at jpl.nasa.gov
> 
> 818-354-1768 (office)
> 818-687-0626 (mobile)
> 
> 
> On 1/24/13 5:21 PM, "Quach, Nga T (388A)" <Nga.T.Chung at jpl.nasa.gov> wrote:
> 
>> 
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: "Lynnes, Christopher S. (GSFC-6102)" <christopher.s.lynnes at nasa.gov>
>>> Date: January 24, 2013, 12:31:54 PM PST
>>> To: "<esip-discovery at lists.esipfed.org>" <esip-discovery at lists.esipfed.org>
>>> Subject: [Esip-discovery] RFC ready to go?
>>> 
>>> In terms of modifications to the ESIP Discovery RFC, it looks like we have reached a stabilization point.  I am now going to import it into MS Word next week, reformat a little and add table of contents.  So if there is anything that still needs changing, speak (or write) now or forever etc etc etc.
>>> 
>>> https://docs.google.com/document/d/1ymt5vsP2jw2YMVnc2B8uEI0BKTHcT4jSNVQzruLIFPA/edit
>>> --
>>> Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185
>>> "Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away" -- A. de Saint-Exupery
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Esip-discovery mailing list
>>> Esip-discovery at lists.esipfed.org
>>> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20130127/c4dbf51a/attachment.html>