- From: Emanuele Della Valle <emanuele.dellavalle@polimi.it>
- Date: Thu, 18 Dec 2014 15:11:01 +0000
- To: Roland Stühmer <mail@roland-stuehmer.de>
- CC: "public-rsp@w3.org" <public-rsp@w3.org>
Hello Robin and Roland, I answer in line > On 15 Dec 2014, at 11:17, Roland Stühmer <mail@roland-stuehmer.de> wrote: > > Hello Robin, all! > > Am 15.12.2014 um 08:46 schrieb Robin Keskisärkkä: >> Thanks for the response Emanuele. Just to clarify, since only one triple >> is used in each graph pattern with a BEGIN AT. I assume we regard the >> individual triples in each graph to be associated with the specific >> timestamps of the originally streamed graph, so that a graph can be >> referenced using it's associated timestamp, e.g.: >> { ?somebody e:enters ?poi; g:drunk "false"} BEGIN AT ?t >> expresses that "somebody" entered "poi" and was at the same point in >> time not "drunk" within the same window? > > 'Not "drunk" within the same window' is true but 'Not "drunk" at the > same point in time' is not: > > 1.: It is reasonable to require that triples are associated with graphs > and as such are timestamped (like graphs are). > > 2.: However, there can be cases a triple e.g. { ?somebody e:enters ?poi > } could result from several graphs e.g. in a time window. Then we need a > way to uniquely select/associate one graph for such a triple. (An > example would be to use the triple with the *newest* graph for the > BEGIN/END operators.) > > There is no conclusion here. However, I think we need a better semantics > or re-think those graph-oriented operators. I agree there is no conclusion. In the C-SPARQL language when multiple triples with different timestamp are in the window we let the timestamp function, which operates at triple pattern level, access only the most recent timestamp. So the query SELECT ?somebody ?poi (timestamp(?somebody e:enters ?poi) AS ?t1) (timestamp(?somebody g:drunk “false” ) AS ?t2) FROM STREAM <http:// … > [RANGE 1h STEP 10m] WHERE { ?somebody e:enters ?poi; g:drunk “false” } on the stream [20:00] bob e:enters bar1 [20:10] bob g:drunk “false” [20:40] bob g:drunk “true” [20:50] bob g:drunk “false” at 20:00 gives no results because bob g:drunk “false” has not entered the window, yet at 20:10 gives as result bob, bar1, 20:00, 20:10 at 20:20 gives as result bob, bar1, 20:00, 20:10 because C-SPARQL only supports R-STREAM operator at 20:30 gives as result bob, bar1, 20:00, 20:10 see above at 20:40 gives as result bob, bar1, 20:00, 20:10 see above and because nowhere we state that bob g:drunk “true” means that bob g:drunk “false” cannot be any longer true at 20:50 gives as result bob, bar1, 20:00, 20:50 because the timestamp function returns only the most recent at 21:00 gives no results because bob e:enters bar1 exit the window With the query SELECT ID-STREAM ?somebody ?poi ?t UNDER ENTAILMENT REGIME <….rif> FROM STREAM <http:// … > [RANGE 1h STEP 10m] WHERE { ?somebody e:enters ?poi; g:drunk “false” } BEGIN AT ?t and the rule: a person can either be drunk or not drunk I would expect the following answers at 20:00 gives no results because bob g:drunk “false” has not entered the window, yet at 20:10 gives as result bob, bar1, 20:10 on the I-STREAM at 20:20 gives no results because RSP-QL has the I-STREAM and the D-STREAM operators at 20:30 gives no results see above at 20:40 gives as result bob, bar1, 20:10 on the D-STREAM because of the rule at 20:50 gives as result bob, bar1, 20:50 because bob is no longer drunk at 21:00 gives no results because bob e:enters bar1 exit the window Too much? I hope not :-P I may not find the time to write again to the RSP community before the winter break: Merry Christmas and Happy New Year! Emanuele
Received on Thursday, 18 December 2014 15:12:45 UTC