[Esip-discovery] Proposal for seasonal / annually-repeating-dates

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

On Jul 26, 2013, at 4:51 PM, Ian Truslove <ian.truslove at nsidc.org> wrote:

> 
> On 7/17/13 1:08 PM, "Lynnes, Christopher S. (GSFC-6102)"
> <christopher.s.lynnes at nasa.gov> wrote:
> 
>> We find ourselves wanting to search a server for a set of repeating date
>> ranges, to support seasonal analysis.  For example, we want all March
>> data over a 12 year period, say, or all data from Dec. 21 to March 20
>> over a 10 year period.
> 
> 
> This is of interest to us, and there's a similar issue for the search
> service's responses. We're wondering what a response for a record which
> covers multiple time ranges might look like.  We came up with using the
> <time:start> and <time:stop> elements per
> http://wiki.esipfed.org/index.php/FederatedSearchConvention#Time_in_Atom_Re
> sponse, and have these two dates be the earliest and latest dates covered.
> This ensures backwards compatibility.

Ian,
  Actually, I thought we backed away from using time:start and time:end in the response, going instead with the single element, expressed as an interval using the '/' operator, e.g.  <dc:date>2002-08-30/2013-02-05</dc:date>

.

> In addition to that, we thought about adding custom namespaced elements to
> describe the actual ranges.  For example (and assuming use of the ESIP URI
> as the namespace identifier), a dataset that covers one day per year over
> a three year period:
> 
>  <entry xmlns:esip="http://esipfed.org/ns/fedsearch/1.0/">
>    <id>http://nsidc.org/blah...</id>
>    <title>Some Dataset</title>
>    <updated>2013-01-01T00:00:00.000Z</updated>
> 
> 
>    <time:start>2010-01-01T12:00:00.000Z</time:start>
> 
>    <time:end>2012-01-02T11:59:59.999Z</time:end>
> 
>    <esip:dateRange start="2010-01-01T12:00:00.000Z"
> end="2010-01-02T11:59:59.999Z" />
>    <esip:dateRange start="2011-01-01T12:00:00.000Z"
> end="2011-01-02T11:59:59.999Z" />
>    <esip:dateRange start="2012-01-01T12:00:00.000Z"
> end="2012-01-02T11:59:59.999Z" />

What is the rationale for putting them in as attributes instead of element content, like the other info?

> 
> 
> 
> 
>    <!-- etc -->
>  </entry>
> 
> Is anyone interested in these types multiple date range coverage?  Is
> there a solution to this that we can steal and not have to create a custom
> solution?
> 
> 
> -Ian.
> 
> 
> 
> 
> --
> Ian Truslove
> National Snow and Ice Data Center
> University of Colorado
> 449 UCB,  Boulder, CO 80309
> 
> 
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

--
Dr. Christopher Lynnes, NASA/GSFC, ph: 301-614-5185