Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 8 commits into from
Mar 3, 2016
Merged

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

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
ad64895
implementation of https://github.com/streamreasoning/RSP-QL/issues/28
greenTara Feb 10, 2016
e5e2ca3
add quote of RDF Dataset semantics section
greenTara Feb 18, 2016
9e6c744
add ednotes about context
greenTara Feb 18, 2016
5c7349e
modify terminology "explicit" => "literal-" and add clarification
greenTara Feb 18, 2016
326ec42
expand explanation of example
greenTara Feb 18, 2016
d35fa1c
make the clause about sequences of graphs without timestamps normative.
greenTara Feb 18, 2016
19e3652
add non-literal example
greenTara Feb 18, 2016
52b3dfb
improve non-literal example with real predicate
greenTara Mar 2, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
99 changes: 60 additions & 39 deletions Abstract Syntax and Semantics Document/index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,40 +156,57 @@ <h3>Temporal entities</h3>
<h4>Instants and Intervals</h4>

<p>Following the concepts of the Time Ontology (<a href="http://www.w3.org/TR/owl-time/">http://www.w3.org/TR/owl-time/</a>), a temporal entity can be a time instant or a time interval.</p>

<section id="def-timestamped-graph">
<h3>Timestamped graph</h3>

<p>A <em>timestamped graph</em> is defined as an RDF Dataset under the RDF Dataset semantics that <a href="http://www.w3.org/TR/2014/NOTE-rdf11-datasets-20140225/#each-named-graph-defines-its-own-context">each graph defines its own context</a> with the following constraints.</p>
<p>A <em>timestamped graph</em> is defined as an RDF Dataset under the RDF Dataset semantics that <a href="http://www.w3.org/TR/2014/NOTE-rdf11-datasets-20140225/#each-named-graph-defines-its-own-context">each graph defines its own context</a> and where a particular triple in the default graph has been designated as the timestamp triple, with the following constraints.</p>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A timestamped graph is defined as an RDF Dataset under the RDF Dataset semantics that each graph defines its own context and where a particular triple in the default graph has been designated as the timestamp triple, with the following constraints.

== maybe better to change to ==>

A timestamped graph is defined to be an RDF Dataset associated with a temporal context under the following constraints:

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

each graph defines its own context is a quote (almost, should actually be "each named graph defines its own context") from the RDF semantics document, and the link is to the section with that name. I would rather put it in quotes, to make this clear. That it is a temporal context is a separate point. I will try to rewrite this sentence to make this more clear.


<ol>
<li>There is a single named graph pair (n, g) in the RDF Dataset (where <code>g</code> is an <a href="http://www.w3.org/TR/rdf11-concepts/#section-rdf-graph">RDF graph</a>, and <code>n</code> is an IRI or blank node).</li>
<li>There is a <del>single</del> triple in the default graph of the RDF Dataset, and it has the form (n, p, t), where <code>n</code> is defined in the previous item, <code>p</code> is a predicate that captures the relationship between the temporal entity <code>t</code>, called the timestamp, and the graph <code>g</code>.</li>
<li>There is exactly one named graph pair <code>&lt;n, G></code> in the RDF Dataset (where <code>G</code> is an <a href="http://www.w3.org/TR/rdf11-concepts/#section-rdf-graph">RDF graph</a>, and <code>n</code> is an IRI or blank node).</li>
<li>The timestamp triple has the form <code>&lt;n, p, t></code>, where <code>n</code> is defined in the previous item, <code>p</code> is a timestamp predicate that captures the relationship between the temporal entity <code>t</code>, called the timestamp, and the graph <code>G</code>.</li>
</ol>

<p>Limitations of the definition:</p>

<ul>
<li>does <strong>not</strong> allow the default graph of a timestamped graph to have more than triple.</li>
</ul>

<blockquote>
<p><strong>Discussion:</strong> There could be multiple timestamps associated with a graph <code>g</code>, e.g. a start time and an end time, or a generated time and a system processing time. The predicate <code>p</code> should be drawn from a community agreed vocabulary (<a href="https://github.com/streamreasoning/RSP-QL/issues/10">Issue 10</a>).</p>
<p class="note">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.</p>

<p class="ednote">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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

</p>
<p class="note">
This definition allows the timestamp to be implicit.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the timestamp? or the timestamp predicate?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This definition allows the timestamp to be implicit.
=>
This definition allows the timestamp to be an IRI or blanknode. Additional information may be provided about it in the default graph (e.g. through properties in the OWL Time Ontology), but this is not required by the definition of timestamped graph.

For example, the timestamp predicate could be an IRI or blank node rather than a literal.
</p>

<p><strong>Discussion:</strong> More than one triple may be necessary to represent the time metadata for each graph.</p>
</blockquote>

<h4>Example:</h4>

<p>The following timestamped graph <code>:g1</code> contains 2 triples that state that Darko and Axel are in the Red Room. The <code>p</code> predicate used in this example is the PROV `<code>prov:generatedAtTime</code>. In this example the named graph <code>:g1</code> contains the data contents (triples). The format in the example follows <a href="http://www.w3.org/TR/trig/">TriG</a>, although does not imply any specific serialization or formatting, it simply shows the data structured according to the RDF stream model. Prefixes (e.g. <code>prov:</code>) are used for readability.</p>

<pre class="example highlight" title="Timestamped Graph with IRI Graph Name and Quads"><code>:g1 {:axel :isIn :RedRoom. :darko :isIn :RedRoom} {:g1,prov:generatedAtTime,"2001-10-26T21:32:52Z"}
<p class="note">An <em>explicitly</em> timestamped graph is a timestamped graph whose timestamp <code>t</code> is a literal.</p>

<p class="ednote">Merge and union of equivalence classes of streams with implicitly timestamped graphs may not be defined. See <a href="#merge-union"></a>.</p>

<p class="ednote">The timestamp predicate <code>p</code> may be drawn from a community agreed
vocabulary (<a href="https://github.com/streamreasoning/RSP-QL/issues/10">Issue 10</a>).
The timestamp predicate may also be user-defined.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably useful if such vocabulary was agreed, or suggested. Perhaps not for now

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In either case, it would be useful to give a general definition of what is required of a timestamp predicate (#26).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think as well it is a good idea to keep the definition general and not fix it to any of the existing time ontologies.

</p>

<aside class="example highlight" title="Explicitly Timestamped Graph">

<p>The following timestamped graph contains a named graph <code>&lt;:g, G></code> where the graph <code>G</code> contains 2 triples that state that Darko and Axel are in the Red Room. The timestampe predicate <code>p</code> used in this example is the PROV `<code>prov:generatedAtTime</code>.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following timestamped graph contains a named graph <:g, G> where the graph G contains 2 triples that state that Darko and Axel are in the Red Room.

--->

The following timestamped graph contains a named graph <:g, G> where the graph G contains 2 triples that state that two people Darko and Axel are in the Red Room at the timepoint "2001-10-26T21:32:52".

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also recommand to change the names used in the example to ex:alice and ex:bob, because they are more common names (more international) and are also used in RDF Semantic documents.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't write the original example, so I don't have a strong opinion on this. There is a precedent of using the names of authors (e.g. Ora Lassila) in RDF examples

The format in the example follows <a href="http://www.w3.org/TR/trig/">TriG</a>, although does not imply any specific serialization or formatting;
it simply shows the data structured according to the RDF stream model.
The default graph contains only 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 the timestamp triple.
Prefixes (e.g. <code>prov:</code>) are used, without explicitly defining their expansion, for readability.</p>

<pre><code>:g1 {:axel :isIn :RedRoom. :darko :isIn :RedRoom} {:g1,prov:generatedAtTime,"2001-10-26T21:32:52Z"}
</code></pre>
</aside>
<p class="ednote">A subsection should be created to hold all the information about the formatting of examples, and here
the expansion of the prefixes can be defined.</p>
</section>

<h3>RDF Stream</h3>

<p>A <em>RDF stream</em> <code>S</code> 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. </p>
<p>An <em>RDF stream</em> <code>S</code> 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 <code>S</code> contains elements <code>S(i)</code> and <code>S(j)</code> with <code>i &lt; j</code> whose timestamp triples contain the same timestamp predicate <code>p</code>, then it should not be the case that the timestamp of <code>S(i)</code> is greater than the timestamp of <code>S(j)</code>. </p>

<p><strong>Order:</strong> The partial order must respect the natural order of time. In particular, if every time instant within the closure of temporal entity <code>X</code> is earlier than every time instant within the closure of temporal entity <code>Y</code>, then <code>X &lt;= Y</code> (where closure of a time instant <code>t</code> is defined as the degenerate interval <code>[t, t]</code>, and closure of an interval is defined in the usual way) </p>
<p><strong>Order:</strong> The partial order MUST respect the natural order of time. In particular, if every time instant within the closure of temporal entity <code>X</code> is earlier than every time instant within the closure of temporal entity <code>Y</code>, then <code>X &lt;= Y</code> (where closure of a time instant <code>t</code> is defined as the degenerate interval <code>[t, t]</code>, and closure of an interval is defined in the usual way) </p>

<p>Furthermore, the usual mathematical requirements of a partial order apply:</p>

Expand All @@ -198,37 +215,41 @@ <h3>RDF Stream</h3>
<li>b) Antisymmetry <code>X &lt;= Y</code> and <code>Y &lt;= X</code> implies <code>X = Y</code></li>
<li>c) Transitivity <code>X &lt;= Y</code> and <code>Y &lt;= Z</code> implies <code>X &lt;= Z</code>. </li>
</ul>

<p class="ednote">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.</p>

<p class="ednote">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.</p>

<p>On the following we may refer to RDF stream simply as stream.</p>

<h4>Example:</h4>
<aside class="example highlight" title="RDF Stream">

<p>A stream produces data that indicates where a person is at a given time. The <code>p</code> predicate used in this example is the PROV `<code>prov:generatedAtTime</code>. In this example the named graphs (<code>:g1</code>,<code>:g2</code>, etc.) contain the streaming data contents (for brevity the contents are represented by the dots <code>...</code>). </p>
<p>An RDF stream produces data that indicates where a person is at a given time. The timestamp predicate <code>p</code> used in this example is the PROV `<code>prov:generatedAtTime</code>. In this example the named graphs (<code>:g1</code>,<code>:g2</code>, etc.) contain the streaming data contents (for brevity the contents are represented by the dots <code>...</code>). </p>

<pre class="example highlight" title="RDF Stream Abbreviated"><code>:g1 {...}{:g1,prov:generatedAtTime,t1}
:g2 {...}{:g2,prov:generatedAtTime,t2}
:g3 {...}{:g3,prov:generatedAtTime,t3}
:g4 {...}{:g4,prov:generatedAtTime,t4}
:g2 {...} {:g2, prov:generatedAtTime, t2}
:g3 {...} {:g3, prov:generatedAtTime, t3}
:g4 {...} {:g4, prov:generatedAtTime, t4}
...
</code></pre>

<p>We can expand the content of each named graph, which is a set of triples:</p>

<pre class="example highlight" title="RDF Stream Expanded"><code>:g1 {:axel :isIn :RedRoom. :darko :isIn :RedRoom} {:g1,prov:generatedAtTime,t1}
:g2 {:axel :isIn :BlueRoom. } {:g2,prov:generatedAtTime,t2}
:g3 {:minh :isIn :RedRoom. } {:g3,prov:generatedAtTime,t3}
<pre class="example highlight" title="RDF Stream Expanded"><code>
:g1 {:axel :isIn :RedRoom. :darko :isIn :RedRoom} {:g1, prov:generatedAtTime, t1}
:g2 {:axel :isIn :BlueRoom. } {:g2, prov:generatedAtTime, t2}
:g3 {:minh :isIn :RedRoom. } {:g3, prov:generatedAtTime, t3}
...
</code></pre>
</p>
</aside>

<blockquote>
<p><strong>Discussion</strong>: Given a certain <code>p</code>, elements on the stream having that predicate are ordered according to <code>t</code>. 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.</p>
</blockquote>

<p><strong>Observation:</strong> There can be multiple graphs with the same timestamp in the stream.</p>
<p class="note">There can be multiple graphs with the same timestamp in the stream.</p>

<blockquote>
<p>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: <em>there could be zero, one, or multiple elements with the same timestamp in a stream</em>. To verify.</p>
</blockquote>
<p class="ednote">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: <em>there could be zero, one, or multiple elements with the same timestamp in a stream</em>.</p>

<h3>Substream</h3>

Expand Down