implementation of Clarify Definition of Timestamped Graph Re Multiplicity of Timestamp Triples

[greenTara]

implementing #28 as well as #29

also add terminology and notes about explicit versus implicit timestampls

[greenTara]

Kia - would you pleae review this pull request, especially in regard to handling the case where the timestamp is not a literal. I believe this is the key feature that will allow your usecase to be handled.

[kiat]

sure!

[greenTara]

It looks like this pull request was closed accidentally.

[greenTara]

One aspect of this material that I think still needs improvement is the examples. The ones given use a placeholder for the timestamp, so it's not at all clear what that is intended to be.

I think we should replace all such placeholders with actual values - literals or IRIs, as the case may be.
In the existing examples I would use literals (xsd:dateTime) for the timestamps. So then it would also be helpful to have an example where the timestamp is given as an IRI, and the relative order is expressed through a "before" predicate in the default graph.

I was wondering if we could use the scenario of the existing example as the basis for an event-oriented stream of this type. Say, the events are when individuals enter or leave a location. Each individual would naturally have a temporal (total) ordering to their location-changing events (let's suppose there is some time lag in between leaving somewhere and entering somewhere else.. Each location would also have a temporal (partial) ordering on individuals entering and leaving, supposing that simultaneous entry or departure of multiple individuals is allowed. Does that make sense?

[jpcik]

the definition does not allow it, but in practice, graphs without timestamps can be timestamped by an RSP engine, e.g. on arrival. I think this can be added as a comment, so that we fulfill the requirement, or at least provide an acceptable solution.

[greenTara]

What that appears to be, to me, is a sequence of graphs (or named graphs, or RDF datasets) physically being received by an RSP engine, which then creates a stream from it by attaching timestamps. That's a great way to create a stream, but we should not say that the sequence of graphs (or whatever) is itself an RDF stream. Does that fit with your thinking?

[greenTara]

The graph in the example does not state the type of the entities named ex:Darko and ex:Axel, so the information that these represent people would be external (they could be cats or robots). The graph that is part of the named graph pair also does not include any information about the time of this observation. The timestamped graph (which is not actually a graph) does contain information about a temporal context. The information is that the named graph pair was generated at that temporal entity. Whether this temporal entity is related to the time when some observation was made, or the time when these entities were actually in that location, would have to come from external information, i.e. a model regarding the relationship of the "generated at" timestamp to the time of occurrence of the observation.

I am okay with adding additional information about what is asserted in this example, in particular from the timestamp predicate, but it is necessary to limit it to only what is explicitly asserted. Alternatively, the usecase from which the example arises could be described, but this might be more confusing, because not everything about the usecase is explicitly asserted in this simple example.

[greenTara]

@kiat - I would also like to add an event-oriented example in this section where the timestamp is not an rdf:Literal, but is, say, an owl:TemporalEntity (an implicitly timestamped graph). I was thinking in terms of something like this:

:g1 {:axel :enters :RedRoom.} 
{:g1, :observedAtTime, _:t1. _:t1, owl:after, _:t0. }

This would be preparatory for an RDF stream where each element is asserted to be observed owl:after the previous element of the stream.

The predicate ":observedAtTime" is a placeholder until more details are available on timestamp predicates.

Your suggestions on how to improve the example are welcome.

[greenTara]

@kiat, @jpcik I am wondering if we could merge this pull request now and close the issue #28 , as we now have a definition that clarifies the multiplicity of triples in the default graph, as well as an example, in the linked-list style, showing two triples in the default graph.

There is surely more to be done to improve this section, but I think we could close that issue (provided it is satisfactorily resolved in your view) and start a new one for further improvements.

[jpcik]

yes, I think that should cover #28

[greenTara]

close #28

[greenTara]

close #29