Re: new version of the example of RSP-QL query

Dear Emanuele,

I took a closer look at the update, and I believe that the comment in my previous mail applies to the current version: The matches on the :veryLongWindow will include both symmetric cases, which is good for filtering on the <isCloseTo> and <knows> criteria, but will result in duplicates at the aggregation phase unless something is done.

I also have a few other questions / comments:

1) Assuming that the entry times of <somebody> and <someoneElse> are close to each other, how is it prevented that they are not matched four times for the four separate windows that they occur in?

2) To me the :longWindow criteria seems to be checking, whether the triple <somebody> <isCloseTo> <someoneelse> occurs within (any) 30-minute window with 5-minute increments. Yet the specification asks for "people have been staying close by for at least 30 minutes". How is the length-of-staying-close covered in the :longWindow section?

3) In the beginning of the query there is a variable ?poi and towards the end ?bar is used (I'm looking at the version in the wiki link<https://www.w3.org/community/rsp/wiki/Example_of_RSP-QL_query> at the moment). Was this intentional, or a typo?

My default assumption would be that the query produces...

2 (symmetric) * 4 (veryLongWindow) * 6 (a single isCloseTo triple would occur in six windows) * X (the number of isCloseTo triples during the stay)

...matches for a single couple, i.e. 48 or more. How does it filter down to count each couple only once?

BR,

Mikko


On 11. Dec 2014, at 23:11, Emanuele Della Valle <emanuele.dellavalle@polimi.it<mailto:emanuele.dellavalle@polimi.it>> wrote:

Dear Robin,

thanks for asking. I answer in line.

On 11 Dec 2014, at 17:16, Robin Keskisärkkä <robin.keskisarkka@liu.se<mailto:robin.keskisarkka@liu.se>> wrote:

Hi!
I looked at the most recent version of the RSP-QL syntax and was just wondering if someone could clarify a few of the concepts for me that I found to be a little bit confusing since I missed the last call.

- What does the 'UNDER ENTAILMENT REGIME <...>' signify?

I mean that the query has to be evaluated under a given entailment regime. In the C-SPARQL Engine recently we add support for RIF entailment regime.

- Does a window consist of triples or a set of graphs?

Nice question, in my opinion, a window is a graph in the dataset against which the WHERE clause is evaluated.

If graphs, can they be individually referenced (e.g. named graphs)?

no, in my opinion, they cannot.

- Does the 'BEGIN AT' apply to triples or graphs?

it applies to graph patterns. If the graph pattern is a triple the evaluation is straight forward because every triple as a timestamp (i.e., the one of the named graph on the stream it was transmitted). If it is a BGP, then things get more tricky. If the BGP is all match within a single named graph on the stream it was transmitted, it is as simple as for the triple patter. If it is matched across named graphs, Allen algebra suggests to take the max of the time stamps.

Over semantics can be meaningful. For instance, in the C-SPARQL language we allow to apply a similar clause (i.e., the timestamp function) only to triple patterns and we return the max of the timestamps of the triples matching the pattern.

- Why is the aggregate part a separate clause, why not only GROUP BY and COUNT(...) AS …?

This is part of the original C-SPARQL language proposal. It allows to compute and aggregate without shrinking the result set, but decorating it. More information can be found in section 3.4 of this paper (also attached, since it is hard to find):

Davide Francesco Barbieri, Daniele Braga, Stefano Ceri, Emanuele Della Valle, Michael Grossniklaus: C-SPARQL: a Continuous Query Language for RDF Data Streams. Int. J. Semantic Computing 4(1): 3-25 (2010)

http://dx.doi.org/10.1142/S1793351X10000936

- Can a window defined that has no name?

yes, in my opinion, it that case the triples end up in the default graph of the dataset against which the WHERE clause is evaluated.

Cheers,

Emanuele

<J2_C-SPARQL-semantics_IJSC-2010.pdf>