Re: BP #24 Provide Real-time access

Hi Annette,

Yes I like this and add it just the way you articulated it.

Thanks!

Eric

On Mon, Feb 2, 2015 at 4:09 PM, Annette Greiner <amgreiner@lbl.gov> wrote:

> Hi Eric,
> I like the addition, especially the fact that you list the main factors in
> deciding the requirements. I’m assuming that you mean those as factors to
> decide whether real-time access in the API is needed at all. That may not
> be clear to someone who hasn’t already been thinking about that question,
> though. What do you think of starting that new sentence like “The necessity
> of providing real-time access for a given application will need to be
> evaluated…”?
> -Annette
> --
> Annette Greiner
> NERSC Data and Analytics Services
> Lawrence Berkeley National Laboratory
> 510-495-2935
>
> On Feb 2, 2015, at 7:15 AM, Eric Stephan <ericphb@gmail.com> wrote:
>
> Annette,
>
> I've been doing some thinking about this,  What do you think of this:
>
> Eric S
>
> Original Why:
>
> The presence of real-time data on the web enables access to critical time
> sensitive data, and encourages the development of real-time web
> applications. Real-time access is dependent on real-time data producers
> making their data readily available to the data publisher. In addition to
> making pubished data accessible, data publishers may provide additional
> information describing data gaps, data errors and anomolies, and
> publication delays.
>
> Modified:
>
> The presence of real-time data on the web enables access to critical time
> sensitive data, and encourages the development of real-time web
> applications. Real-time access is dependent on real-time data producers
> making their data readily available to the data publisher to meet consumer
> needs. * Each application real-time access requirements will need to be
> evaluated on a case by case basis considering refresh rates, latency
> introduced by data post processing steps, **infrastructure availability
> to support real-time access, and the data needed by consumers.  *
>
>  In addition to making published data accessible, data publishers may
> provide additional information describing data gaps, data errors
> and anomalies, and publication delays.
>
> On Sun, Feb 1, 2015 at 12:17 PM, Eric <ericphb@gmail.com> wrote:
>
>> It's a good question Annette.  It is something we haven't formally
>> defined yet.
>>
>>  I'd really appreciate adding this data intensive perspective in
>> implementation.
>>
>> It also brings to mind what we publish on the web.  Do we publish the
>> kitchen sink or do we filter?
>>
>> Please feel free to amend and add.
>>
>> Eric
>> Sent from my iPhone
>>
>> On Feb 1, 2015, at 11:42 AM, Annette Greiner <amgreiner@lbl.gov> wrote:
>>
>> I have a question about real-time data. When we say "data that is
>> produced in real time," what does that mean? Is that a collection rate? I
>> think the choice of whether to make data available real-time involves more
>> than the frequency at which it is collected. For example, data from an
>> accelerator like the LHC gets collected at an extremely high rate, but it
>> is released in bulk. Maybe the rule should be more about whether individual
>> values are updated frequently (how frequently?) on an ongoing basis.
>> -Annette
>>
>> Sent from my iPhone
>>
>> On Feb 1, 2015, at 10:58 AM, Eric Stephan <ericphb@gmail.com> wrote:
>>
>> I've modified BP #24 [1] based on Phil's guidance [2] and referring to
>> the earlier templates.  I won't make any more additions today, hopefully
>> will be back to it tomorrow morning.
>>
>> Thanks,
>>
>> Eric S.
>>
>>
>> References
>>
>> [1] http://w3c.github.io/dwbp/bp.html#AccessRealTime
>> <http://w3c.github.io/dwbp/bp.html#BulkAccess>
>> [2] http://lists.w3.org/Archives/Public/public-dwbp-wg/2015Jan/0303.html
>>
>>
>
>