- From: Annette Greiner <amgreiner@lbl.gov>
- Date: Mon, 2 Feb 2015 16:09:57 -0800
- To: Eric Stephan <ericphb@gmail.com>
- Cc: Public DWBP WG <public-dwbp-wg@w3.org>
- Message-Id: <E243CAE6-80A5-435A-BBA2-5573D2538459@lbl.gov>
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 >>> [2] http://lists.w3.org/Archives/Public/public-dwbp-wg/2015Jan/0303.html >
Received on Tuesday, 3 February 2015 00:10:32 UTC