Re: RSP Data Model

Dear Emanuele,

Thank you for the fuller explanation, and I agree with the problems you highlight. However as Avi points out, these are implementation level details. I, like Avi, would like us to have a data model independent of implementation details.

If we do go down the route of only permitting one graph at any given time point, is this also determined by the predicate, i.e. would we allow the following:
(g_1, p_1, t_1), (g_2, p_2, t_1)
where p_1 ≠ p_2?

Another question, drawn from a real-world use case of monitoring coastal flooding, is how do we support multiple sensors all taking a reading at 10:00 and publishing on the same stream. From the users perspective they view all the readings having taken place instantaneously although in reality due to clock drift they will not have been. While one option would be to have each sensor publish on its own stream, there is a need to eventually merge and query these as a single stream. Thus there is a need to support multiple timestamped graphs on a single stream with the same timestamp.

Best regards,

Alasdair


On 14 June 2015 at 09:00:02, Abraham Bernstein (bernstein@ifi.uzh.ch<mailto:bernstein@ifi.uzh.ch>) wrote:

Dear Emanuele, dear all

I wonder whether we are mixing two issues here. One is the data model of time-annotated graphs. The other is a system model that, as you indicate, is much easier to deine if you can make some assumptions about how the triples (or graph fragments) arrive (in order, monotonically increasing, etc.).

I would propose to disentangle the two. In other words, I would propose a well-founded time-based data model combined with a set of assertions that we expect to hold on streams.

Best

Avi



On 12.06.2015, at 18:16, Emanuele Della Valle <emanuele.dellavalle@polimi.it<mailto:emanuele.dellavalle@polimi.it>> wrote:

Dear Alasdair,

a problem I run into went I implemented the timestamped model in real use cases is that you need to wait for all contemporaneous triples with the same timestamp, before processing them. They arrive to the RSP engine one after each other, so the arrival time is always increasing, but they all carry the some timestamp. If you assume that timestamp are not decreasing, an RSP engine knows it can start the processing as soon as a triple with a larger timestamp arrives, but what if the stream stay silent? How does the RSP engine distinguish the case of a delayed triple (still contemporaneous to those it has already got) from the case it is waiting because nothing is transmitted on the stream? In the C-SPARQL engine we decided to give up with the possibility to treat the application time and we only relay on the receiving time. This is also what STREAM does. It is know as the best effort approach. Esper can work in best effort mode, but you can also send an event to say the time is past. This is call external time control. This time keeping event is a form of punctuation. It means, I told you all I have to say at this point in time.

If graphs are timestamped with a strictly increasing timestamp, then as soon as the RSP engine gets the entire graph, it can process it. In other words, the boundary of the graph is a form of punctuation. If another graph with the same timestamp can follow, than you’re back into the problem you cannot distinguish if you are waiting for a delayed graph with the same timestamp from the case the stream is silent.

I hope I expressed myself in a clearer way this time.

Best Regards,

Emanuele

PS I’m in favour of multiple time annotations and I agree that interval-based semantics matters.




On 12 Jun 2015, at 18:31, Gray, Alasdair J G <A.J.G.Gray@hw.ac.uk<mailto:A.J.G.Gray@hw.ac.uk>> wrote:

Dear Emanuele,

I don’t quite follow the punctuation argument meaning that we can only have one graph at any given time point.
(Unfortunately I’m on the train home and cannot access the article that you linked.)

We still have the gain over the traditional streaming RDF model in that all triples conforming to a given observation will be contained in the graph. So why does having more than one graph at a given time point cause a problem?
(Sorry if I am missing something obvious)

Best regards,

Alasdair


On 12 June 2015 at 08:49:40, Emanuele Della Valle (emanuele.dellavalle@polimi.it<mailto:emanuele.dellavalle@polimi.it>) wrote:

Dear Alasdair, and all

thanks for the report. I would like to point out that the sentence “There can be multiple graphs with the same timestamp” is, in my opinion, a bad choice. It will prevent graphs to be interpreted as a form of punctuation [1] and this was one of the most important gain of the version of RSP Data Model discussed in Berlin (i.e., graphs with strictly increasing timestamps). The lack of punctuation is a problem of the “traditional" timestamped triples data model where contemporary triples must be admitted.

Best regards,

Emanuele

[1] http://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_285



On 11 Jun 2015, at 18:37, Gray, Alasdair J G <A.J.G.Gray@hw.ac.uk<mailto:A.J.G.Gray@hw.ac.uk>> wrote:

Hi All,

During the ESWC RSP Workshop we had a breakout group focus on defining the RSP data model. I was charged with the action of updating the semantics document with the agreed model.

You can find the updated data model at
https://github.com/streamreasoning/RSP-QL/blob/master/Semantics.md


Best regards,

Alasdair

--
Alasdair J G Gray
Lecturer, Heriot-Watt University
Web: http://www.alasdairjggray.co.uk<http://www.alasdairjggray.co.uk/>
ORCID: http://orcid.org/0000-0002-5711-4872

Twitter: @gray_alasdair
Telephone: +44 131 451 3429
Office: EM 1.39



We invite research leaders and ambitious early career researchers to join us in leading and driving research in key inter-disciplinary themes. Please see www.hw.ac.uk/researchleaders<http://www.hw.ac.uk/researchleaders> for further information and how to apply.

Heriot-Watt University is a Scottish charity registered under charity number SC000278.

--
Alasdair J G Gray
Lecturer, Heriot-Watt University
Web: http://www.alasdairjggray.co.uk<http://www.alasdairjggray.co.uk/>
ORCID: http://orcid.org/0000-0002-5711-4872

Twitter: @gray_alasdair
Telephone: +44 131 451 3429
Office: EM 1.39



We invite research leaders and ambitious early career researchers to join us in leading and driving research in key inter-disciplinary themes. Please see www.hw.ac.uk/researchleaders<http://www.hw.ac.uk/researchleaders> for further information and how to apply.

Heriot-Watt University is a Scottish charity registered under charity number SC000278.


-----------------------------------------------------------------
|  Professor Abraham Bernstein, PhD
|  University of Zürich, Department of Informatics
|  web: http://www.ifi.uzh.ch/ddis/bernstein.html


--
Alasdair J G Gray
Lecturer, Heriot-Watt University
Web: http://www.alasdairjggray.co.uk

ORCID: http://orcid.org/0000-0002-5711-4872

Twitter: @gray_alasdair
Telephone: +44 131 451 3429
Office: EM 1.39


----- 
We invite research leaders and ambitious early career researchers to 
join us in leading and driving research in key inter-disciplinary themes. 
Please see www.hw.ac.uk/researchleaders for further information and how
to apply.

Heriot-Watt University is a Scottish charity
registered under charity number SC000278.