Interplay of timestamped graph predicate with stream order and time-bounded substreams

[AlasdairGray]

Should the predicate p in a timestamped graph (g,p,t) be considered when deciding upon the order of timestamped graphs in the stream S or when considering which timestamped graphs are included in a time-bounded substream?

[keski]

A stream S consists of a sequence of timestamped graphs (g,p,t), where p is a temporal property and t is a timestamp. A timestamped graph may be associated with multiple temporal properties (e.g., observation time and generated time). The stream is assumed to be ordered with regard to at least one temporal property.

Example:
A sensor registers vehicles at a street crossing. At a defined time interval all observations made since the last output is pushed to the stream, e.g. output at time t_5 is:

(g_1,"generated at",t_5)
(g_2,"generated at",t_5)
(g_3,"generated at",t_5)
(g_1,"observed at",t_1)
(g_2,"observed at",t_2)
(g_3,"observed at",t_3)

The stream is ordered with regard to the temporal property "generated at", and possibly the property "observed at" as well.

Note: If timestamps are assumed to be unique then observations with the same timestamps should be merged into a single timestamped graph.

[AlasdairGray]

Note: If timestamps are assumed to be unique then observations with the same timestamps should be merged into a single timestamped graph.

I don't think that is the correct approach. If we are insisting on unique timestamps then you need to use a finer grained timestamp and give separate timestamps.

However I personally feel that we should not have the limitation of a unique timestamp.

[keski]

I too feel that we should not limit ourselves to unique timestamps. In my mind it is sufficient that a window defines the sequence/set of timestamped graphs that are included in the bounded substream.

[jpcik]

I think as long as t is ordered it should be fine. I think this discussion is related to what was said in the mailing list. The problem is that if i receive (g1,p,t1) and then (g2,p,t1), then you got no way to know if you have to 'wait' for more data. I suspect that this is a serialization/implementation problem. In that case your protocol could take the option of being strict and allow only one graph per (p,t).

[nimonika]

The other (probably implementation specific interpretation) alternative to this is to define the relationship between the graphs themselves using http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#directlyFollows or http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#directlyPrecedes. This of course results in handling more triples than necessary but may provide some flexibility in handling graphs with the same timestamp. I use this as in my scenario, I do have multiple event graphs with the same timestamp.

[keski]

The 'wait' for more data is of course related to the punctuation discussion, which was brought up on the mailing list. Using directlyFollows and directlyPrecedes could be a good idea: 1) directlyFollows allows us to specify the ordering explicitly (e.g. when two graphs have the same timestamp), and 2) directlyPrecedes (or a property we define) can be used to punctuate the stream.

[nimonika]

@keski I use it in pretty much this way, although in my case, punctuation is not really needed. Note that it is also possible to define a weaker interpretation of this using http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#follows