diff --git a/Abstract Syntax and Semantics Document/index.html b/Abstract Syntax and Semantics Document/index.html index 7d1df46..0e0c50c 100644 --- a/Abstract Syntax and Semantics Document/index.html +++ b/Abstract Syntax and Semantics Document/index.html @@ -156,40 +156,114 @@
Following the concepts of the Time Ontology (http://www.w3.org/TR/owl-time/), a temporal entity can be a time instant or a time interval.
- +A timestamped graph is defined as an RDF Dataset under the RDF Dataset semantics that each graph defines its own context with the following constraints.
+A timestamped graph is defined as an RDF Dataset under the RDF Dataset semantics that "each named graph defines its own context" (see ) and where a particular triple in the default graph has been designated as the timestamp triple, with the following constraints:
g
is an RDF graph, and n
is an IRI or blank node).n
is defined in the previous item, p
is a predicate that captures the relationship between the temporal entity t
, called the timestamp, and the graph g
.<n, G>
in the RDF Dataset (where G
is an RDF graph, and n
is an IRI or blank node).<n, p, t>
, where n
is defined in the previous item, and p
is a timestamp predicate that captures the relationship between the temporal entity t
, called the timestamp, and the graph G
.Limitations of the definition:
- --- -Discussion: There could be multiple timestamps associated with a graph
+g
, e.g. a start time and an end time, or a generated time and a system processing time. The predicatep
should be drawn from a community agreed vocabulary (Issue 10).There may be multiple triples in the default graph, including multiple triples using timestamp predicates, + but exactly one triple must be designated as the timestamp triple.
+Due to the assertion of the timestamp triple, the context referred to in "each named graph defines its own context" has a temporal aspect to it. + Other aspects of this context may be asserted by additional triples in the default graph of the timestamped graph. + Such triples are not required to have timestamp predicates, and thus may be about non-temporal aspects of the context, + e.g. the authority or the sensor device. + That is, we require the context to have a temporal aspect to it, but the context is not limited to temporal aspects. + Thus, it would be misleading to call it a "temporal context". +
+The part of the definition above that points to RDF Dataset semantics really belongs in the semantics section, not + in this definition, which should be purely syntax. + We need additional informative text that gives the motivation for these definitions. +
-Discussion: More than one triple may be necessary to represent the time metadata for each graph.
-
The following timestamped graph :g1
contains 2 triples that state that Darko and Axel are in the Red Room. The p
predicate used in this example is the PROV `prov:generatedAtTime
. In this example the named graph :g1
contains the data contents (triples). The format in the example follows TriG, although does not imply any specific serialization or formatting, it simply shows the data structured according to the RDF stream model. Prefixes (e.g. prov:
) are used for readability.
This definition does not permit the timestamp to be omitted, which is one of the data structures + that is considered to be in-scope by the requirements document. +
++ A sequence of RDF graphs (or named graphs, or RDF datasets) MAY be physically received by an RSP engine, + which MAY then create an RDF stream from it by adding timestamps, e.g. indicating the time of arrival. + The original sequence is not itself an RDF stream. +
++ This definition allows the timestamp to be an IRI or blanknode. + Additional information about the timestamp may be provided in the default graph (e.g. through properties in the OWL Time Ontology), + but this is not required by the definition of timestamped graph. +
+ +A literal-timestamped graph is a timestamped graph whose timestamp t
is an rdf:Literal.
Merge and union of RDF streams with non-literal-timestamped graphs may not be defined. See .
+ +The timestamp predicate p
may be drawn from a community agreed
+ vocabulary (Issue 10).
+ The timestamp predicate may also be user-defined.
+
+ The format in the examples of this document follows TriG, although does not imply any specific serialization or formatting;
+ it simply shows the data structured according to the RDF stream model.
+ When the default graph of a timestamped graph contains only one triple, this must be the timestamp triple, so there is no need of an additional format to designate it.
+ In examples of timestamped graphs having more than one triple in the default graph, the first triple of the default graph to occur in the serialization
+ is assumed to be the timestamp triple.
+ Prefixes (e.g. prov:
, dul:
) are used, without explicitly defining their expansion, for readability.
A non-normative subsection should be created to hold all the information about the formatting of examples, and there + the expansion of all prefixes that are used in examples can be defined.
+ + + +According to the semantics defined in , the assertion of the named graph pair
+ means that the graph denoted by :g
entails the two triples :axel :isIn :RedRoom
+ and :darko :isIn :RedRoom
, under whatever entailment regime is being considered.
+ It does not assert those triples directly, nor does it assert that these triples
+ are actually in that graph. Further, it does not rule out additional entailments of :g
.
+ These details are best explained in the semantics section itself, although it would probably be helpful
+ to have some informative explanation near the beginning to avoid confusion.
+
A RDF stream S
consists of a sequence of timestamped graphs whose elements sharing the same predicate are ordered by the partial order associated with this predicate on the timestamps.
An RDF stream S
consists of a sequence of timestamped graphs whose elements sharing the same predicate are ordered by the partial order associated with this predicate on the timestamps. I.e., if a stream S
contains elements S(i)
and S(j)
with i < j
whose timestamp triples contain the same timestamp predicate p
, then it should not be the case that the timestamp of S(i)
is greater than the timestamp of S(j)
.
Order: The partial order must respect the natural order of time. In particular, if every time instant within the closure of temporal entity X
is earlier than every time instant within the closure of temporal entity Y
, then X <= Y
(where closure of a time instant t
is defined as the degenerate interval [t, t]
, and closure of an interval is defined in the usual way)
Order: The partial order MUST respect the natural order of time. In particular, if every time instant within the closure of temporal entity X
is earlier than every time instant within the closure of temporal entity Y
, then X <= Y
(where closure of a time instant t
is defined as the degenerate interval [t, t]
, and closure of an interval is defined in the usual way)
Furthermore, the usual mathematical requirements of a partial order apply:
@@ -198,37 +272,41 @@X <= Y
and Y <= X
implies X = Y
X <= Y
and Y <= Z
implies X <= Z
. Time-boundedness properties on RDF streams behave better if it is required that the set of temporal entities for each timestamp predicate is pairwise bounded. I.e., for each pair of temporal entities in the set, there is a temporal entity in the set that is an upper bound of both, as well as a temporal entity in the set that is a lower bound of both.
+ +The comparability between any pair of elements of an RDF stream must be completely determined + from the default graphs of the elements. + Otherwise the ordering could be revealed by a subsequent element, inducing retroactively an + ordering requirement on previous stream elements.
On the following we may refer to RDF stream simply as stream.
--- -Discussion: Given a certain
-p
, elements on the stream having that predicate are ordered according tot
. If the stream contains elements s1 and s2 associated with the same predicate, with s1 preceding s2, then it should not be the case that the timestamp of s1 is greater than the timestamp of s2.
Observation: There can be multiple graphs with the same timestamp in the stream.
+There can be multiple graphs with the same timestamp in the stream.
--+It has been pointed out that this statement might be problematic, as graphs cold no longer be used for punctuation purposes. Comparatively, we have not found a constraint on this in similar models e.g. CQL: there could be zero, one, or multiple elements with the same timestamp in a stream. To verify.
-
It has been pointed out that this statement might be problematic, as graphs cold no longer be used for punctuation purposes. Comparatively, we have not found a constraint on this in similar models e.g. CQL: there could be zero, one, or multiple elements with the same timestamp in a stream.