-
Notifications
You must be signed in to change notification settings - Fork 14
Expand file tree
/
Copy pathindex.html
More file actions
1025 lines (1007 loc) · 67.5 KB
/
index.html
File metadata and controls
1025 lines (1007 loc) · 67.5 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>RDF Stream Abstract Syntax and Semantics</title>
<meta charset="utf-8" />
<script src="http://www.w3.org/Tools/respec/respec-w3c-common" async="async" class="remove"></script>
<script class="remove">
var respecConfig = {
specStatus: "CG-DRAFT",
shortName: "rdf-stream-semantics",
editors: [
{
name: "Editor 1",
company: "Company 1",
companyURL: "http://example1.com/",
mailto: "ed1@example1.com"
},
{
name: "Editor 2",
company: "Company 2",
companyURL: "http://example2.com/",
mailto: "ed2@example1.com"
}
],
authors: [
{
name: "Tara Athan",
company: "Athan Services",
companyURL: "http://athant.com",
mailto: "taraathan@gmail.com"
},
{
name: "Author 2",
company: "Company 2",
companyURL: "http://example2.com/",
mailto: "auth2@example1.com"
}
],
wg: "RDF Stream Processing Community Group",
wgURI: "https://www.w3.org/community/rsp/",
wgPublicList: "public-rsp",
localBiblio: {
"LINEARCOMPOSITION": {
title: "Multi-device Linear Composition on the Web: Enabling Multi-device Linear Media with HTMLTimingObject and Shared Motion",
href: "https://sites.google.com/site/mediasynchronization/Paper4_Arntzen_webComposition_CR.pdf?attredirects=0&d=1",
authors: [
"Ingar M. Arntzen",
"Njål T. Borch",
"François Daoust",
"Dominique Hazaël-Massieux"
]
},
"BLOGIC": {
title: "Blogic",
href: "http://www.slideshare.net/PatHayes/blogic-iswc-2009-invited-talk",
authors: [
"Pat Hayes"
]
},
"DUL": {
title: "DOLCE+DnS Ultralite (dul)",
href: "http://lov.okfn.org/dataset/lov/vocabs/dul",
authors: [
"Aldo Gangemi"
]
},
"DVB-CSS": {
title: "ETSI TS 103 256-2 V1.1.1 Digital Video Broadcasting (DVB); Companion Screens and Streams; Part 2: Content Identification and Media Synchronization",
href: "http://www.etsi.org/modules/mod_StandardSearch/pdf.png"
},
"SHAREDMOTION": {
title: "Shared Motion",
href: "http://motioncorporation.com"
},
"MEDIASYNC":{
title: "MediaSync",
href: "https://github.com/webtiming/mediasync"
},
"SEQUENCER" : {
title: "Open-source sequencer library",
href: "https://github.com/webtiming/sequencer"
}
},
otherLinks: [
{
key: "Version history",
data: [
{
value: "GitHub streamreasoning/RSP-QL/commits",
href: "https://github.com/streamreasoning/RSP-QL/commits/"
}
]
},
{
key: "Participate",
data: [
{
value: "GitHub streamreasoning/RSP-QL",
href: "https://github.com/streamreasoning/RSP-QL"
},
{
value: "File an issue",
href: "https://github.com/streamreasoning/RSP-QL/issues/new"
},
{
value: "Open issues",
href: "https://github.com/streamreasoning/RSP-QL/issues/"
},
{
value: "Mailing-list (public-rsp@w3.org)",
href: "https://lists.w3.org/Archives/Public/public-rsp/"
}
]
}
],
issueBase: "https://github.com/streamreasoning/RSP-QL/issues/",
githubAPI: "https://api.github.com/repos/streamreasoning/RSP-QL"
};
</script>
<style type="text/css">
table{
border-collapse: collapse;
border-style: hidden hidden none hidden;
}
table thead,
table tbody{
border-bottom: solid;
}
table td,
table th{
border-left: solid;
border-right: solid;
border-bottom: solid thin;
vertical-align: top;
padding: 0.2em;
}</style>
</head>
<body>
<!-- ABSTRACT -->
<section id="abstract"> </section>
<!-- STATUS OF DOCUMENT -->
<section id="sotd">
<p> The specification is intended for discussion within the RDF Stream Processing Community
Group. Its content does not yet represent the consensus of the Community Group. </p>
<p class="warning"> This specification is incomplete. </p>
</section>
<!-- INTRODUCTION -->
<section class="informative" id="intro">
<h2>Introduction</h2>
</section>
<section id="rsp-data-model">
<h2>RSP Data model</h2>
<section id="namespaces-and-prefixes">
<h3>Namespaces and Prefixes</h3>
<p>The metamodel for the abstract syntax of RDF streams is defined in the namespace <code>http://www.w3.org/ns/rsp#</code>
and we use the prefix <code>rsp</code> for this namespace. Additional prefixes used in this document are the following:
</p>
<div style="text-align: left;">
<table class="thinborder" style="margin-left: auto; margin-right: auto;">
<caption id="namespace-table"><a href="#namespace-table">Table 1</a>: Prefix and Namespaces used in this specification</caption> <!-- Table 1-->
<tbody><tr><td><a><b>prefix</b></a></td><td><b>namespace IRI</b></td> <td><b>definition</b></td></tr>
<tr><td><a>rsp</a></td><td><code>http://www.w3.org/ns/rsp#</code></td><td>The RSP rnamespace</td></tr>
<tr><td><a>rdf</a></td><td><code>http://www.w3.org/1999/02/22-rdf-syntax-ns#</code></td><td>The RDF namespace [[!RDF-SCHEMA]]</td></tr>
<tr><td><a>rdfs</a></td><td><code>http://www.w3.org/2000/01/rdf-schema#</code></td><td>The RDFS namespace [[!RDF-SCHEMA]]</td></tr>
<tr><td><a>xsd</a></td><td><code>http://www.w3.org/2000/10/XMLSchema#</code></td><td>XML Schema Namespace [[!XMLSCHEMA11-2]]</td></tr>
<tr><td><a>owl</a></td><td><code>http://www.w3.org/2002/07/owl#</code></td><td>The OWL namespace [[!OWL2-OVERVIEW]]</td></tr>
<tr><td><a>owl-time</a></td><td><code>http://www.w3.org/2006/time#</code></td><td>The OWL-TIME namespace [[OWL-TIME]]</td></tr>
<tr><td><a>prov</a></td><td><code>http://www.w3.org/ns/prov#</code></td>
<td>The PROV namespace [[!PROV-DM]]</td></tr>
<tr><td><a>dul</a></td><td><code>http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#</code></td>
<td>The DOLCE+DnS Ultralet namespace (http://lov.okfn.org/dataset/lov/vocabs/dul) [[DUL]]</td></tr>
<tr><td><a>(others)</a></td><td>(various)</td><td>All other namespace prefixes are used in examples only. <br/> In particular, IRIs starting with "http://example.com" represent<br/> some application-dependent IRI [[!IRI]]</td></tr>
</tbody></table>
</div>
</section>
<section id="temporal-entities-and-timestamp-predicates">
<h3>Temporal Entities and Timestamp Predicates</h3>
<section id="temporal-entities">
<h4>Class of Temporal Entities</h4>
<p>Let T<sup>all</sup> denote the class of all temporal entities. This specification is
neutral regarding the formal specification of temporal entities. </p>
<p>We provide an identifier, <code>rsp:TemporalEntity</code>, for the <code>rdfs:Class</code> of all
temporal entities.</p>
<h5>Instants and Intervals</h5>
<p class="ednote">The following material needs attention from an individual who has
reviewed the literature regarding temporal ontologies, including but not limited to
http://www.omg.org/spec/DTV/1.0/ http://www.ihmc.us/users/phayes/docs/timeCatalog.pdf
http://protege.cim3.net/cgi-bin/wiki.pl?SWRLTemporalOntology
http://dl.acm.org/citation.cfm?id=1741341
http://stl.mie.utoronto.ca/publications/psl-chapter.pdf
There is more detail in https://github.com/streamreasoning/RSP-QL/issues/25</p>
<p>An instant is an instantaneous point of time on underlying axis and is isomorphic to
numbers. Henceforth a time interval is the interval between two instants. A
semi-infinite time interval is an interval where one instant is set to infinite.
Furthermore if both instants are set to infinite, we call the interval bi-infinite. As a
consequence a temporal entity is an entity associated with an instant or a time
interval[Dyreson94,Allen83]. </p>
<p class="ednote">Add a out of scope section</p>
<p class="ednote">Add Stream Profiles and Hierarchies, e.g., combined_time, timepoints,
periods, approximate_point, interval_meeting, owltime_instants and owltime_interval</p>
<aside class="example" title="OWL-Time">
<p>An ontology that contains both the concept of instants and time intervals is the
OWLTime ontology (see <a href="http://www.w3.org/TR/owl-time/"></a>). It defines all
necessary temporal RDF concepts, such as instants, intervals and temporalEntities, and
relations thereon. </p>
</aside>
</section>
<section id="def-timestamp-predicate">
<h4>Timestamp Predicates</h4>
<p> An RSP timestamp predicate <code>P</code> is an <code>rdf:Property</code> with range <code>rsp:TemporalEntity</code> that is
associated, through the <code>rdf:Property</code> <code>rsp:hasTimePlenum</code>, with a unique partially-ordered set (poset) of
temporal entities <code>T<sub>P</sub> ⊆ T<sup>all</sup></code>, called the <em>time plenum</em> of the predicate.
The time plenum is associated, through the <code>rdf:Property</code> <code>rsp:hasPartialOrder</code>,
with a unique partial order <code>≤<sub>P</sub></code> that is in the class
<code>rsp:ChronologicalPartialOrder</code>.</p>
<p>The usual mathematical requirements of a partial order MUST be satisfied by an instance of
<code>rsp:ChronologicalPartialOrder</code>. In particular, for all instances <code>X</code>, <code>Y</code>, <code>Z</code>
of the time plenum, the following properties hold:
</p>
<dl>
<dt>Reflexivity</dt>
<dd><code>X ≤<sub>P</sub> X</code></li></dd>
<dt>Antisymmetry<dt>
<dd> <code>X ≤<sub>P</sub> Y</code> and <code>Y ≤<sub>P</sub> X</code> implies <code>X =
Y</code></dd>
<dt>Transitivity</dt>
<dd><code>X ≤<sub>P</sub> Y</code> and <code>Y ≤<sub>P</sub> Z</code> implies <code>X ≤<sub>P</sub>
Z</code>. </dd>
</dl>
<p>Further, an instance of <code>rsp:ChronologicalPartialOrder</code> MUST respect the natural order of time.</p>
<p>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 ≤<sub>P</sub> 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 class="ednote">The above definition regarding natural order of time depends on the
concept of time instant as the primitive of temporal entities that is universal amoung
temporal ontologies and has a particular chronological order associated with them.
However, not all temporal
ontologies have time instants as their primitives, e.g., OMG.
Further, branching temporal ontologies have a different set of time primitives than linear ones.
So this needs to be fixed.
</p>
</section>
</section>
<section id="def-timestamped-graph">
<h3>Timestamped Graphs</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 named graph defines its own context"</a> (see <a href="#semantics"></a>) and
where a particular triple in the default graph has been designated as the timestamp
triple, with the following constraints:</p>
<ol>
<li>There is exactly one named graph pair <code><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><n, p, t></code>, where <code>n</code> is
defined in the previous item, and <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 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. The objects of any triples that use a timestamp predicate but are not the
timestamp triple of the timestamped graph are not called timestamps.</p>
<p class="ednote">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". </p>
<p class="ednote">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. </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. </p>
<p> A sequence of RDF graphs (or named graph pairs, 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. </p>
<p class="note"> 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. </p>
<p>A <em>literal-timestamped graph</em> is a timestamped graph whose timestamp
<code>t</code> is an <code>rdfs:Literal</code>.</p>
<p class="note">Merge and union of RDF streams with non-literal-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. </p>
<p> The format in the examples of this document 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. 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.
<code>prov:</code>, <code>dul:</code>) are used for readability; their expansions are defined in
<a>Table 1</a>.</p>
<p class="ednote">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.</p>
<aside class="example" id="literal-TSG" title="Literal-Timestamped Graph">
<p>The following timestamped graph contains a named graph pair <code><_:b0, G></code>
where the graph <code>G</code> contains a triple stating that temperature in Berlin is 12.5 C.
The timestamp predicate <code>p</code> used in this example is the [[PROV-O]] property <a
href="https://www.w3.org/TR/prov-o/#generatedAtTime"
><code>prov:generatedAtTime</code></a>. The purpose of this timestamp triple is to add
a temporal aspect to the context of the named graph pair, to the effect that the
temporal entity <code>"2015-01-01T01:00:00Z"^^xsd:dateTime</code> is the time at which
the entity <code>_:b0</code> "was completely created and is available for use". The
details of the semantics of the named graph pair in a timestamped graph are provided in
<a href="#semantics"></a>
</p>
<pre><code class="highlight">_:b0 prov:generatedAtTime "2015-01-01T01:00:00Z"^^xsd:dateTimeStamp .
_:b0 {dbp:Berlin loc:hasPointTempC "12.5"^^xsd:decimal .}</code></pre>
</aside>
<p class="ednote">According to the semantics defined in <a href="#semantics"></a>, the
assertion of the named graph pair means that the graph denoted by <code>:g</code> entails
the triple <code>dbp:Berlin loc:hasPointTempC "12.5"^^xsd:decimal .</code>,
under whatever entailment regime is being considered. It does not assert that triple
directly, nor does it assert that this triple is actually in that graph. Further, it
does not rule out additional entailments of <code>_:b0</code>. 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. </p>
<aside class="example" id="non-literal-TSG" title="Non-Literal-Timestamped Graph">
<p>The following timestamped graph contains a named graph pair <code><:g2, G></code>
where the graph <code>G</code> contains one triple that states that entity
<code>:axel</code> leaves the <code>:BlueRoom</code>. The timestamp predicate used in
this example is the DOLCE+DnS Ultralite property <a
href="http://www.loa-cnr.it/ontologies/DUL.owl#isObservableAt"
><code>dul:isObservableAt</code></a>. The purpose of this timestamp triple is to add
a temporal aspect to the context of the named graph pair, to the effect that there is
some time <code>_:t2</code> at which an observation could have been (or be) made where
the results of that observation are described by the entity <code>:g2</code>. There is
an additional triple in the default graph that compares the observable time to some
other time <code>_:t1</code> using the Allen interval relation <a
href="https://www.w3.org/2006/time#after"><code>owl-time:intervalAfter</code></a> from
[[OWL-TIME]]. </p>
<pre><code class="highlight">
:g2 dul:isObservableAt _:t2.
:g2 {:axel :leave :BlueRoom. }
_:t2 owl-time:intervalAfter _:t1
</code></pre>
</aside>
<p>Given any two timestamped graphs, <code>TSG1</code> and <code>TSG2</code>, we say that
<code>TSG2</code>
<em>covers</em>
<code>TSG1</code> (denoted <code>TSG1 ≲ TSG2</code>) if and only if <code>TSG1</code>
and <code>TSG2</code> have the same timestamp predicate <code>P</code> and the timestamps,
<code>t1</code> and <code>t2</code> resp., satisfy <code>t1 ≤<sub>P</sub> t2</code>,
where <code>≤<sub>P</sub></code> is the temporal partial order associated with the time plenum
of the timestamp predicate <code>P</code>. </p>
<p class="note">The relation <code>≲</code> between timestamped graphs is a preorder (a
reflexive, transitive binary relation). It is not a partial order because it doesn't have
the antisymmetry property (<code>a≲ b</code> and <code>b≲ a</code> implies <code>a
= b</code>.) </p>
<aside class="example highlight" title="Distinct Timestamped Graphs That Cover Each Other">
<p>Two timestamped graphs that have the same timestamp predicate and the same timestamp
but different named graph pairs cover each other, but are not equal. This demonstrates that
the "cover" relation is not antisymmetric. </p>
</aside>
</section>
<section id="rdf-stream">
<h3>RDF Stream</h3>
<p>An <em>RDF stream</em>
<code>S</code> consists of a sequence of timestamped graphs, called its <em>elements</em>, such that
elements sharing the same
timestamp predicate are ordered by the partial order associated with this timestamp predicate.
I.e., if a stream <code>S</code> contains elements <code>S(i)</code> and <code>S(j)</code>
with <code>i < j</code> and <code>S(i)</code> covers <code>S(j)</code>, then the
timestamps of <code>S(i)</code> and <code>S(j)</code> are equal. </p>
<p>If a timestamp predicate occurs in the timestamp triple of an element of an RDF stream, we say
it is a <em>timestamp predicate of the stream.</em></p>
<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. This property is not satisfied by branching temporal structures, but could be a
requirement of some profile.</p>
<p class="ednote">The comparability between any pair of elements of an RDF stream must (or should?) be
completely determined from the default graphs of those elements, or elements that precede at least one of them.
Otherwise the ordering could
be revealed by a subsequent element, inducing retroactively an ordering requirement on
a previous pair of stream elements.</p>
<p>On the following we may refer to RDF stream simply as stream.</p>
<aside class="example" id="literal-rdf-stream" title="RDF Stream">
<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 graph pairs
(<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="highlight"><code>:g1 {...}{:g1,prov:generatedAtTime,t1}
:g2 {...} {:g2, prov:generatedAtTime, t2}
:g3 {...} {:g3, prov:generatedAtTime, t3}
:g4 {...} {:g4, prov:generatedAtTime, t4}
...
</code></pre>
<p>We can expand the content of the graph component of each named graph pair, which is a set of triples:</p>
<pre class="highlight"><code>
:g1 {:axel :isIn :RedRoom. :darko :isIn :RedRoom}
{:g1, prov:generatedAtTime, "2015-06-18T12:00:00Z"^^xsd:dateTime}
:g2 {:axel :isIn :BlueRoom. }
{:g2, prov:generatedAtTime, "2015-06-18T12:00:35"^^xsd:dateTime}
:g3 {:minh :isIn :RedRoom. }
{:g3, prov:generatedAtTime, "2015-06-18T12:02:07"^^xsd:dateTime}
...
</code></pre>
</aside>
<p class="note">There can be multiple graphs with the same timestamp in the stream.</p>
<p class="ednote">It has been pointed out that this statement might be problematic, as graphs
could 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>
</section>
<section id="isomorpism">
<h3>Isomorphism</h3>
<p>Two RDF timestamped graphs TSG1 and TSG2 are <em>isomorphic</em> if and only if there is
a bijection M between the nodes, triples, graphs and named graph pairs in TSG1 and those in
TSG2 such that: <ol>
<li>M maps blank nodes to blank nodes;</li>
<li>M is the identity map on literals and IRIs;</li>
<li>For every triple <s p o>, M(<s, p, o>)= <M(s), M(p), M(o)>;</li>
<li>For every graph G={t1, ..., tn}, M(G)={M(t1), ..., M(tn)};</li>
<li>For every named graph pair NG=<n, G>, M(NG)=<M(n), M(G)>;</li>
<li> M(NG1)=NG2, M(DG1)=DG2, and M(TST1)=TST2, where NG1 is the named graph pair of TSG1, DG1
is the default graph of TSG1, TST1 is the timestamp triple of TSG1, and similarly for
TSG2.</li>
</ol>
</p>
<p class="note"> The definition of timestamped graphs allows blank nodes to be used as graph
names, as well as within triples. </p>
<pre class="example highlight" title="Isomorphic Timestamped Graphs with Blank-Node Graph Names">
<code>:_1 {...} {:_1, prov:generatedAtTime, t1}
</code>
<code>:_2 {...} {:_2, prov:generatedAtTime, t1}
</code>
</pre>
<p>Two RDF streams are <em>S-isomorphic</em> if and only if they have the same set of
elements.</p>
<pre class="example highlight" title="S-Isomorphic Streams with Unique Well-Ordered Timestamp Predicate">
<code>
:g1 {...} {:g1, prov:generatedAtTime, t1}
:g2 {...} {:g2, prov:generatedAtTime, t2}
:g3 {...} {:g3, prov:generatedAtTime, t2}
:g4 {...} {:g4, prov:generatedAtTime, t3}
</code>
<code>
:g1 {...} {:g1, prov:generatedAtTime, t1}
:g3 {...} {:g3, prov:generatedAtTime, t2}
:g2 {...} {:g2, prov:generatedAtTime, t2}
:g4 {...} {:g4, prov:generatedAtTime, t3}
</code>
</pre>
<p>Two RDF streams S1 and S2 are <em>B-isomorphic</em> if and only if there is a bijection M
between the nodes, triples, graphs, named graph pairs, and timestamped graphs in S1 and those
in S2 such that: <ol>
<li>M maps blank nodes to blank nodes;</li>
<li>M is the identity map on literals and IRIs;</li>
<li>For every triple <s p o>, M(<s, p, o>)= <M(s), M(p), M(o)>;</li>
<li>For every graph G={t1, ..., tn}, M(G)={M(t1), ..., M(tn)};</li>
<li>For every named graph pair NG=<n, G>, M(NG)=<M(n), M(G)>;</li>
<li>For every timestamped graph TSG where NG is the named graph pair and DG is the default
graph containing the timestamp triple TST, M(TSG) is a timestamped graph TSG2, with
named graph pair M(NG), default graph M(DG) and timestamp triple M(TST).;</li>
<li>For every i ≥ 1, M(S1(i))=S2(i), where S1(i) is the i-th element of S1 and S2(i)
is the i-the element of S2.</li>
</ol>
</p>
<p class="note">An RDF stream is viewed as being on a single "RDF surface"(see [[BLOGIC]]),
so that blank nodes may be shared between any graphs in the stream. For this reason,
B-isomorphism is defined in terms of a single mapping M for the entire RDF stream rather
than, say, separate mappings for each timestamped graph.</p>
<p>Two RDF streams are <em>isomorphic</em> if there exists an RDF stream that is both
B-isomorphic to one stream and S-isomorphic to the other stream.</p>
<p class="note"> RDF streams that are S-isomorphic are isomorphic. </p>
<p class="note"> RDF streams that are B-isomorphic are isomorphic. </p>
<p>Isomorphic RDF streams MUST have the same semantics. The semantics of RDF streams is
affected by the result of applying window functions (<a href="#window-functions"></a>) as
well as by entailment. Therefore, isomorphic RDF streams SHALL be indistinguishable, up to
isomorphism, with respect to entailment (in any entailment regime), as well as with
respect to the application of window functions. </p>
</section>
<section id="substreams-and-Windows">
<h3>Substreams and Windows</h3>
<p>A <em>substream</em>
<code>S'</code> of an RDF stream <code>S</code> is an RDF stream that is isomorphic to a
subsequence of <code>S</code>.</p>
<p class="note">There are several specializations of the substream relation which are useful
in practice. These include the <em>filter</em> relation, where stream elements are
selected based on satisfaction of some criterion, and the <em>window</em> relation, where
a temporally contiguous portion of the stream is selected. </p>
<p>A <em>window</em>
<code>S'</code> of an RDF stream <code>S</code> is a substream of <code>S</code> such that
if <code>S'(i)</code> and <code>S'(j)</code> are two elements of <code>S'</code> and
<code>S'(i) ≲ S'(j)</code> (i.e., <code>S'(j)</code> covers <code>S'(i)</code>), and
further if <code>S'(i) ≲ S(k) ≲ S'(j)</code> for some element <code>S(k)</code> of
<code>S</code>, then <code>S(k)</code> is an element of <code>S'</code>. </p>
<p class="note">Informally, a window is a temporally-contiguous selection from the original
stream, without gaps.</p>
</section>
</section>
<section id="merge-union">
<h2>Stream Merge and Union Operations</h2>
<p>In order to combine two RDF streams into one, without loss or gratuitous introduction of
entailments, we define two relations, <em>RDF stream merge</em> and <em>RDF stream
union</em>. These relations are inspired by the concepts of similar name for RDF graphs
defined in [[RDF11-Concepts]]. </p>
<p>
<em>RDF stream union</em> is a trinary relation on RDF streams. Let <code>S1</code>,
<code>S2</code>, and <code>S3</code> be RDF streams. We say <code>S3</code> is an <em>RDF
stream union</em> of <code>S1</code> and <code>S2</code> if and only if the set of
elements of <code>S3</code> is equal to the union of the sets of elements of <code>S1</code>
with <code>S2</code>.</p>
<p class="note"> Union is the appropriate relation to consider when combining streams that are
allowed to share blank nodes. Informally, they would be on the same RDF surface. </p>
<aside class="example" title="Union of RDF Streams that Share Blank Nodes">
<pre><code class="highlight">
:g1 {_:1 :isIn :RedRoom. _:2 :isIn :RedRoom} {:g1, prov:generatedAtTime, t1}
:g2 {_:1 :isIn :BlueRoom. } {:g2, prov:generatedAtTime, t2}
:g3 {_:3 :isIn :RedRoom. } {:g3, prov:generatedAtTime, t3}
</code></pre>
is a union of the following two streams: <pre><code class="highlight">
:g1 {_:1 :isIn :RedRoom. _:2 :isIn :RedRoom} {:g1, prov:generatedAtTime, t1}
:g3 {_:3 :isIn :RedRoom. } {:g3, prov:generatedAtTime, t3}
</code></pre>
<pre><code class="highlight">
:g2 {_:1 :isIn :BlueRoom. } {:g2, prov:generatedAtTime, t2}
</code></pre>
</aside>
<p>
<em>RDF stream merge</em> is a trinary relation on RDF streams. Let <code>S1</code>,
<code>S2</code>, and <code>S3</code> be RDF streams. We say <code>S3</code> is an <em>RDF
stream merge</em> of <code>S1</code> and <code>S2</code> if and only if there exist
streams <code>S4</code>, <code>S5</code>, and <code>S6</code>, with <code>S4</code>
isomorphic to <code>S1</code>, <code>S5</code> isomorphic to <code>S2</code>,
<code>S6</code> isomorphic to <code>S3</code>, such that <code>S4</code> and
<code>S5</code> have no blank nodes in common, and <code>S6</code> is the union of
<code>S4</code> with <code>S5</code>.</p>
<p class="note"> Merge is the appropriate relation to consider when joining streams that are
considered to not share blank nodes. Informally, they would be on different RDF surfaces. </p>
<aside class="example" title="Merge of RDF Streams that Do Not Share Blank Nodes">
<pre><code class="highlight">
_:1 {:axel :isIn :RedRoom. :darko :isIn :RedRoom} {_:1, prov:generatedAtTime, t1}
_:2 {:axel :isIn :BlueRoom. } {_:2, prov:generatedAtTime, t2}
_:3 {:minh :isIn :RedRoom. } {_:3, prov:generatedAtTime, t3}
</code></pre>
is a merge of the following two streams: <pre><code class="highlight">
_:1 {:axel :isIn :RedRoom. :darko :isIn :RedRoom} {_:1, prov:generatedAtTime, t1}
_:2 {:minh :isIn :RedRoom. } {_:2, prov:generatedAtTime, t3}
</code></pre>
<pre><code>
_:1 {:axel :isIn :BlueRoom. } {_:1, prov:generatedAtTime, t2}
</code></pre>
</aside>
<p class="note">Given any three RDF streams, the determination of their satisfaction of the
union or merge relation is a purely syntactic computation. That is, it is not necessary to
consider entailments of the RDF streams or to be concerned with the values of literals.</p>
<aside class="ednote">
<p>It should not be hard to show that each relation defines a (deterministic) binary partial
operation on the equivalence classes of isomorphic RDF streams. However, note that this
operation is not purely syntactic. The construction of a union of two streams,
<code>S1</code> and <code>S2</code>, can be accomplished, theoretically, by the
following steps:</p>
<ol>
<li>Construct the set of timestamped graphs <code>R3</code> that is the set union of
elements of <code>S1</code> and <code>S2</code>. </li>
<li>Construct an RDF stream <code>S3</code> from the set <code>R3</code> by placing this
set into a sequential form that satisfies the definitional constraint regarding relative order of
elements, if possible.</li>
</ol>
<p> The second step may require consideration of the values of timestamps or entailments
regarding temporal order in order to <em>sequentialize</em> the set of timestamp graphs.
The construction of a merge is accomplished by performing stream copying to a common
surface before union: </p>
<ol>
<li>Copy both <code>S1</code> and <code>S2</code> to a new RDF surface by renaming blank
nodes that occur in both streams to fresh blank nodes (new to both <code>S1</code> and
<code>S2</code>), producing new streams <code>S1'</code> and <code>S2'</code>. </li>
<li>Form the union of streams <code>S1'</code> and <code>S2'</code>.</li>
</ol>
</aside>
<p class="ednote"> The continuous operation of union or merge of two semi-infinite streams may
not be computable, even when the operation is defined. This is because it may not be
possible to know when an element of one stream might be received that needs to occur before
the latest elements of the other stream. Computability of these continuous operations may be
possible when additional information is available about the streams to be combined, e.g., the
set of timestamp predicates used by each stream and the maximum latency of transmission.
Within some RDF stream profiles, the union and merge operations may be continuously computable
due to the profile constraints.
</p>
</section>
<section id="subclasses">
<h2>RDF Stream Subclasses</h2>
<p class="ednote">This section may be expanded with more subclasses if a need is identified.</p>
<h3>Time-bounded RDF Streams</h3>
<p>A <em>time-bounded-above RDF stream</em> is an RDF Stream where for every timestamp
predicate of the stream, there is a temporal entity in its range that bounds
from above (is greater than or equal to) all timestamps of that predicate in the stream. </p>
<p>A <em>time-bounded-below RDF stream</em> is an RDF Stream where for every timestamp
predicate of the stream, there is a temporal entity in its range that bounds
from below (is less than or equal to) all timestamps of that predicate in the stream. </p>
<p>A <em>time-bounded RDF stream</em> is an RDF Stream that is time-bounded above and
time-bounded below. </p>
<p class="ednote"> Consider the class of timestamp predicates whose associated poset of
temporal entities is <em>pairwise bounded</em>, i.e., has the property that every pair of
temporal entities is bounded, i.e., there exists a temporal entity in the poset that is
greater or equal to both of them and another temporal entity that is less or equal to both
of them. This is a fairly natural property to expect for partial orders on time plenums with "linear topology" (e.g.
[[OWL-TIME]]). However it does not hold in the case of branching time plenums (see <a
href="http://www.ihmc.us/users/phayes/docs/timeCatalog.pdf"
>http://www.ihmc.us/users/phayes/docs/timeCatalog.pdf</a>), because there are incomparable
branches (called paths), which may be considered, e.g., as different worlds (in the sense of
Kripke frames), scenarios (planning usecase), or concurrent processes (process modelling).
It would be a useful property if the class of time-bounded RDF streams were closed under
stream merger and union, and this property would hold, under the current definition, in the
case of pairwise-bounded time plenums, because we could find bounds for the temporal entities
of each timestamp predicate by taking an upper bound of the pair of upper bounds from the
two streams, and similarly for the lower bounds. However, the closure property does not hold
in the case of a branching temporal topology under the above definition of time-bounded. To
achieve the closure property, we would have to allow a number of "upper bounds" for each
timestamp predicate, rather than requiring just one. For example, <br /><br /> Given two
sets, A and B, of entities in a partial order, we say that A bounds B from above iff there
is no element of B that is greater than any element of A, and for every element of B there
is some element of A that is greater than or equal to it. <br /><br /> A
<em>time-bounded-above RDF stream</em> is an RDF Stream where for every timestamp
predicate of the stream, there is a set of temporal entities in its range that
bounds from above all timestamps of that predicate in the stream. </p>
<p class="note"> The class of time-bounded RDF streams using timestamp predicates with
pairwise-bounded time plenums is closed under stream merger and union. </p>
<h3>Temporal-count-bounded RDF Streams</h3>
<p>A <em>temporal-count-bounded RDF stream</em> is an RDF stream where for each timestamp
predicate of the stream, there are a finite number of temporal entities in the
stream that are timestamps for that predicate.</p>
<p class="ednote">The qualifier "temporal" has been added to this term to emphasize that it is
temporal entities that are being counted, not timestamped graphs.</p>
<p class="ednote"> Given an RDF stream whose set of timestamp predicates with pairwise-bounded
temporal entities, then if the stream is temporal-count-bounded it is also time-bounded,
since the upper bound for each timestamp predicate can be taken as an upper bound of the
(finite) set of its timestamps, and similarly for the lower bound. If the definition of
"time-bounded" was changed as in the earlier Editor's Note, then every
temporal-count-bounded RDF stream would be time-bounded. </p>
<p class="note"> Every temporal-count-bounded RDF stream using only timestamp predicates with
pairwise-bounded time plenums is time-bounded. </p>
<p class="note"> The class of temporal-count-bounded RDF streams is closed under stream merger
and union, since the sets of temporal entities for each timestamp predicate in the resulting
stream are the union of the corresponding (finite) sets in the original streams, and so are
finite. </p>
<pre class="example highlight" title="As a pathological example, an RDF stream representing Zeno's paradox using a continuous time plenum (e.g., Julian date) would be time-bounded but not temporal-count-bounded.">
</pre>
<h3>Finite RDF Stream</h3>
<p>A <em>finite RDF stream</em> is an RDF stream of finite length, i.e., with a finite number
of elements in it.</p>
<p class="note"> Clearly, every finite RDF stream is temporal-count-bounded. </p>
<p class="ednote"> Every finite RDF stream using only pairwise-bounded time plenums is
time-bounded. However, this is not the case for branching time plenums. </p>
<p class="note"> Clearly, the class of finite RDF streams is closed under stream merger and
union. </p>
<pre class="example highlight" title="As another pathological example, an RDF stream that contained an infinite set of timestamped graphs all with the same timestamp predicate and timestamp would be temporal-count-bounded but not be finite.">
</pre>
<pre class="example highlight" title="Even more pathological, a temporal-count-bounded stream that uses an infinite set of timestamp predicates would not be finite.">
</pre>
</section>
<section id="window-functions">
<h2>Window Functions</h2>
<p>A <em>window function</em> is a partial function from RDF streams to their windows that
preserves isomorphism. That is, if <code>w</code> is a window function, with isomorphic
streams <code>S1</code> and <code>S2</code> in its domain, then <code>w(S1)</code> is
isomorphic to <code>w(S2)</code>. </p>
<p>A <em>general window function</em> is a window function that is a total function on RDF
streams. </p>
<p class="ednote">The term "window operator" is reserved for later use to return a sequence of
windows.</p>
<p>The most common types of window functions in practice are time-based and count-based.</p>
<section id="time-based-window-functions">
<h3>Time-based Window Functions</h3>
<p>Because the time plenum for each timestamp predicate is partially ordered, we may define a
<em>temporal interval of a timestamp predicate</em> to be an interval, in the usual
sense for partial orders, within its time plenum. </p>
<p class="note">Recall that intervals need not be bounded and need not be closed, and are
specified in terms of two, one or zero inequality conditions based on the partial order or
its induced strict order.</p>
<p>A <em>general time-based window function</em>
<code>w</code> is a general window function specified by a finite set
<code>w<sub>P</sub></code> of timestamp predicates together with temporal intervals
<code>w<sub>J</sub>(P)</code> of each timestamp predicate <code>P</code> in
<code>w<sub>P</sub></code>, such that for every stream <code>S</code>, an element
<code>S(i)</code> of <code>S</code> is an element of <code>w(S)</code> if and only if the
timestamp predicate <code>P</code> of <code>S(i)</code> is in <code>P</code> and the
timestamp <code>t</code> of <code>S(i)</code> is contained in
<code>w<sub>J</sub>(P)</code>. </p>
<p>A <em>time-based window function</em> is the restriction of a general time-based window
function to a subset of RDF streams.</p>
<p class="note">The substream resulting from the application of a time-based window function
is time-bounded.</p>
</section>
<section id="temporal-count-based-window-functions">
<h3>Temporal-count-based Window Functions</h3>
<p>A <em>general temporal-count-based window function</em>
<code>w</code> is a general window function specified by a finite set
<code>w<sub>P</sub></code> of timestamp predicates together with semi-infinite temporal
intervals <code>w<sub>J</sub>(P)</code> of each timestamp predicate <code>P</code> in
<code>w<sub>P</sub></code> with endpoints <code>w<sub>T</sub>(P)</code>, and positive
integers <code>w<sub>N</sub>(P)</code>, for each timestamp predicate <code>P</code> in
<code>w<sub>P</sub></code> such that for every stream <code>S</code>, an element
<code>S(i)</code> of <code>S</code> is an element of <code>w(S)</code> if and only if the
timestamp predicate <code>P</code> of <code>S(i)</code> is in <code>P</code> and <ul>
<li><code>t</code> is the timestamp of <code>S(i)</code>,</li>
<li><code>T(S, P, w)</code> is the set of temporal entities that are timestamps for
elements of <code>S</code> with timestamp predicate <code>P</code>, belong to
<code>w<sub>J</sub>(P)</code>, and belong to the closed interval between
<code>t</code> and <code>w<sub>T</sub>(P)</code>, and</li>
<li>the cardinality of <code>T(S, P, w)</code> is less than or equal to
<code>w<sub>N</sub>(P)</code></li>
</ul>
</p>
<p>A <em>temporal-count-based window function</em> is the restriction of a general
temporal-count-based window function to a subset of RDF streams.</p>
<aside class="note">The above definition of temporal-count-based window function allows the
following characteristics to be set independently for each timestamp predicate of concern: <ul>
<li>future-facing or past-facing orientation,</li>
<li>inclusive or exclusive temporal anchor,</li>
<li>depth.</li>
</ul>
</aside>
<p class="note">The substream resulting from the application of a temporal-count-based
window function is temporal-count-bounded.</p>
<p class="note">Due to the potential for stream elements with incomparable or duplicate
timestamps, the number of elements in the substream having a particular timestamp
predicate is not guaranteed to be equal to the depth specified for the predicate by the
temporal-count-based window. </p>
<p class="note">Temporal-count-based window functions with future-facing orientation on
timestamp predicates whose time plenum is not totally-ordered are not computable, because in
general it is not possible to know, at any point in the reception of the stream, whether
there are further elements of the stream that would be selected by the
temporal-count-based window function.</p>
<p>Applications that require a substream with an exact number <code>N</code> of elements for
a specified timestamp predicate might apply a temporal-count-based window function with
<code>N</code> for the count of temporal entities, and then randomly discard extra
elements, according to some criterion, e.g., extreme elements (maximal or minimal,
depending on the orientation of the counting). However, this extra step causes the process
to be nondeterministic, and hence does not correspond to a function. If elements are
discarded in a nonrandom fashion, e.g., based on their order in the stream sequence, then
this would be a function, but would not preserve isomorphism, and so would not be a window
function. The issue of obtaining a window function that returns an exact number of
elements (for a particular predicate) is handled in the next section, where we define the
concept of window relation, and use it to define an element-count-based window relation.
When restricted to certain kinds of RDF streams, element-count-based window relations are
functional so element-count-based window functions can be defined on such subsets. This
and similar considerations, of importance to implementations, motivate the <a
href="#profiles">RDF Stream profiles</a> as subsets of RDF streams. </p>
</section>
<section id="window-relations">
<h3>Window Relations</h3>
<p>A <em>window relation</em> is a binary relation on RDF streams (a relation having an
extension which is a set of pairs of RDF streams) such that the second element in the pair
is a window of the first element and preserves isomorphism. That is, if <code><S1,
S2></code> is a member of the extension of a window relation <code>W</code>, and
<code>S3</code> and <code>S4</code> are isomorphic to <code>S1</code> and
<code>S2</code>, resp., then <code><S3, S4></code> is also a member of the
extension of <code>W</code>. </p>
<p>A <em>length-based window relation</em>
<code>W</code> is a window relation specified by a set of streams
<code>W<sub>S</sub></code>, a finite set <code>W<sub>P</sub></code> of timestamp
predicates together with the following parameters for each timestamp predicate
<code>p</code> in <code>W<sub>P</sub></code>: <ul>
<li>a semi-infinite temporal interval <code>W<sub>J</sub>(P)</code> of timestamp
predicate <code>P</code> (the interval of <code>P</code>);</li>
<li>a temporal entity <code>W<sub>T</sub>(P)</code> which is the finite endpoint of
<code>W<sub>J</sub>(P)</code> (the temporal reference of <code>P</code>);</li>
<li>a positive integer <code>W<sub>N</sub>(P)</code> (the length for
<code>P</code>)</li>
</ul> The extension of a length-based window relation is defined as follows: Let
<code>S</code> be an RDF stream in <code>W<sub>S</sub></code> with window
<code>S'</code>. Define <code>T(S, P, W)</code> to be the set of temporal entities that
are timestamps for elements of <code>S</code> with timestamp predicate <code>P</code> and
belong to <code>W<sub>J</sub>(P)</code>, and <code>T(S', P)</code> to be the set of
temporal entities that are timestamps for elements of <code>S'</code> with timestamp
predicate <code>P</code>. The pair <code><S, S'></code> is a member of the extension
of <code>W</code> if and only if the cardinality of <code>T(S', P)</code> is equal to the
minimum of <code>W<sub>N</sub>(P)</code> and the cardinality of the set <code>T(S, P,
W)</code> and for each element <code>S'(i)</code> of <code>S'</code>
<ul>
<li>the timestamp predicate <code>P</code> of <code>S'(i)</code> is in
<code>W<sub>P</sub></code>, and</li>
<li> the timestamp <code>t</code> of <code>S'(i)</code> is in
<code>W<sub>J</sub>(P)</code>.</li>
</ul>
</p>
<p>A <em>length-based window function</em>
<code>W</code> on domain <code>W<sub>S</sub></code> is a length-based window relation
where any member <code><S, S'></code> of its extension are such that <code>S</code>
is in <code>W<sub>S</sub></code> and <code>W</code> defines a total function on
<code>W<sub>S</sub></code>.</p>
<p class="ednote">The names "element-count-bounded window relation" and "element-count-bounded window function"
have been proposed, as a replacement of "length-bounded ...". This nomenclature depends on the adoption of
"element" as the term for the individual timestamped graphs in a stream.</p>
</section>
</section>
<!--<h2>References:</h2>
<ul>
<li>EP-SPARQL: a unified language for event processing and stream reasoning.
Anicic, D., Fodor, P., Rudolph, S., & Stojanovic, N. In WWW (p. 635-644). ACM. 2011.</li>
<li>C-SPARQL: a Continuous Query Language for RDF Data Streams.
Barbieri, D. F., Braga, D., Ceri, S., Della Valle, E., & Grossniklaus, M. Int. J. Semantic Computing, 4(1), 3-25. 2010.</li>
<li>Enabling query technologies for the semantic sensor web.
Calbimonte, J.-P., Jeung, H., Corcho, Ó., & Aberer, K. Int. J. Semantic Web Inf. Syst., 8(1), 43-63. 2012.</li>
<li>RSP-QL Semantics: a Unifying Query Model to Explain Heterogeneity of RDF Stream Processing Systems.
D. Dell’Aglio, E. Della Valle, J.-P. Calbimonte, O. Corcho. Int. J. Semantic Web Inf. Syst, 10(4). (in press). 2015.</li>
<li>A Native and Adaptive Approach for Unified Processing of Linked Streams and Linked Data.
Phuoc, D. L., Dao-Tran, M., Parreira, J. X., & Hauswirth, M.In ISWC (Vol. 7031, p. 370-388). Springer. 2011.</li>
<li>LARS: A Logic-based Framework for Analyzing Reasoning over Streams.
Beck, H., Dao-Tran, M., Eiter, T., Fink, M. In AAAI. 2015.</li>
<li>RDF 1.1: On Semantics of RDF Datasets. Zimmerman, Antoine, ed.. 2014. <a href="http://www.w3.org/TR/2014/NOTE-rdf11-datasets-20140225">http://www.w3.org/TR/2014/NOTE-rdf11-datasets-20140225</a>.</li>
</ul>-->
<blockquote>
<p class="note">this example could be integrated to the main text body</p>
<h3>Beyond time instants: intervals & more</h3>
<p>Usign the previously described model, intervals can be specified for a graph in the
following way: Given p1 and p2 representing start and end time predicates, then
<code>(g,p1,t1)</code> and <code>(g,p2,t2)</code> denote that g is defined in an interval
[t1,t2]. As an example:</p>
<pre class="example highlight" title="RDF Stream with Two Timestamp Predicates for One Named Graph Pair"><code>:g_1, :startsAt, "2015-06-18T12:00:00"^^xsd:dateTime
:g_1, :endsAt, "2015-06-18T13:00:00"^^xsd:dateTime
</code></pre>
<p>Or even:</p>
<pre class="example highlight" title="RDF Stream with Interval Timestamp"><code>:g_2 :validBetween
[:startsAt "2015-06-18T12:00:00"^^xsd:dateTime;
:endsAt "2015-06-18T13:00:00"^^xsd:dateTime]
</code></pre>
</blockquote>
<section id="semantics">
<h2>Semantics</h2>
<p> The semantics of a timestamped graph is defined in terms of its semantics as an RDF
Dataset. In particular, the designation of a particular triple in the default graph as the
timestamp triple has no effect on its semantics. </p>
<p>The semantics of timestamped graphs, and consequently of RDF streams, is based on the
semantics formalized in [[RDF11-Datasets]] in the case that each named graph pair defines its own
context.</p>
<p>The following terms are used in the sense of [[RDF11-MT]]: <em>entailment regime,
E-interpretation, blank node, universe, named graph pair, RDF graph, E-entails, default
graph</em>.</p>
<p> An <em>RSP interpretation</em>
<code>I</code> with respect to an entailment regime <code>E</code> is an E-interpretation
extended to named graph pairs, timestamped graphs, RDF datasets, and RDF streams as follows: <ul>
<li>given a mapping <code>A</code> from blank nodes to the universe <code>IR</code> and a
named graph pair <code>ng</code> = <code><n, G></code>, <code>[I+A](ng)</code> is
true if and only if <code>[I+A](n)</code> is an RDF graph that E-entails
<code>G</code>;</li>
<li>for a timestamped graph <code>TSG</code> = <code>< ng, DG></code>, where
<code>DG</code> is the default graph and <code>ng</code> is the named graph pair of
<code>TSG</code>,and a mapping <code>A</code> from blank nodes to the universe
<code>IR</code>, <code>[I+A](TSG)</code> is true if and only if <code>[I+A](DG)</code>
is true and <code>[I+A](ng)</code> is true;</li>
<li><code>I(TSG)</code> true if and only if there exisits a mapping <code>A</code> from
blank nodes to the universe <code>IR</code> such that [I+A](TSG) is true.</li>
<li>for an RDF dataset <code>D</code> = <code>< DG, NG></code>, where <code>DG</code>
is the default graph and <code>NG</code> is the set of named graph pairs of
<code>D</code>, <code>I(D)</code> is true if there exists a mapping <code>A</code>
from blank nodes to the universe <code>IR</code> such that <code>[I+A](DG)</code> is
true and <code>[I+A](ng)</code> is true for every <code>ng</code> in
<code>NG</code>;</li>
<li><code>I(D)</code> is false otherwise.</li>
<li>for an RDF stream <code>S</code>, I(S) is true if and only if if there exists a
mapping <code>A</code> from blank nodes to the universe <code>IR</code> such that for
every element <code>S(i)</code> of <code>S</code>, <code>i ≥ 1</code>,
<code>[I+A](S(i))</code> is true.</li>
</ul> We say that an RSP interpretation <code>I</code> E-satisfies a graph, named graph
pair, timestamped graph, dataset, or stream <code>X</code> (or satisfies <code>A</code>
w.r.t the E-entailment regime) when <code>I(X)</code> is true. </p>
<p>Following standard terminology, we say that a graph, named graph pair, timestamped graph,
dataset, or stream <code>X</code> RSP-E-entails a graph, named graph pair, timestamped graph,
dataset, or stream <code>Y</code> if and only if for every RSP interpretation <code>I</code>
with respect to E-entailment, <code>I</code> E-satisfies <code>Y</code> whenever
<code>I</code> E-satisfies <code>X</code>.</p>
<p class="note">The "RSP" prefix in "RSP-E-entails" may be dropped when neither antecedent nor
consequent is an RDF dataset or named graph pair, as in that case there is no possibility of
alternate dataset semantics.</p>
<p class="ednote">It should be straightforward to prove that isomorphic RDF streams simply
entail each other, and hence are logically equivalent under simple entailment. This should
also hold for other standard entailment regimes, and perhaps should be required for all RSP
entailment regimes.</p>
<p class="ednote"> The notion of RSP-E-entailment is defined here so that it may be used to
support the definition of query semantics under various entailment regimes in the [[RSP-QL
Queries]] document, including simple entailment. A choice was made regarding the semantics
of named graph pairs (i.e., <code>[I+A](ng)</code> is true if and only if
<code>[I+A](n)</code> is an RDF graph that E-entails <code>G</code>) that affects the
semantics of timestamped graphs, datasets, and streams. It remains to be seen if this choice
supports query semantics in a manner that meets the needs of the RSP-QL community. In
particular, it imposes constraints on the denotation of the name of a named graph pair which
may be inconsistent with the domain of a predicate that might be considered for use as a
timestamp predicate (e.g., SSN predicate <code>ssn:observationSamplingTime</code>). </p>
</section>
<section id="profiles">
<h2>Profiles</h2>
<p>It is possible to restrict the abstract syntax for a class of RDF streams. This is often
done in order to facilitate the efficient implementation of certain operations and queries
or to promote more efficient representation. Each such restriction constitutes an <em>RDF
stream profile</em>.</p>
<p>The profiles defined in this document fall into two categories: time-series profiles and
linked-list profiles. Within each category there is a least-restrictive profile and a number
of subprofiles which apply additional restrictions to it.</p>
<section id="timeseries">
<h3>RDF Time-Series Profiles</h3>
<p>This section describes four profiles which are defined through restrictions on the
default graphs of the stream's timestamped graph elements or on the relation between
timestamp values: <ul>
<li>RDF time series</li>
<li>RDF distinct time series</li>
<li>RDF regular time series</li>
<li>RDF distinct regular time series</li>
</ul></p>
<section id="time-series-profile">
<h4>RDF Time-Series Profile</h4>
<p>The RDF Stream Time-Series profile is designed to support high-volume, low-latency
window operations and queries that depend on full knowledge of timestamps.</p>
<p class="ednote">This motivational paragraph needs some work - the above is a place
holder.</p>
<p>An <em>RDF time series</em> is an RDF stream that satisfies the following
properties:</p>
<ol>
<li>The stream uses exactly one timestamp predicate.</li>
<li>The range of this timestamp predicate is xsd:dateTimeStamp.</li>
<li>No two elements in the time series have the same graph name.</li>
</ol>
<aside class="example">
<p><a href="#literal-rdf-stream">Example 4</a> satisfies the first and third
requirements of the time-series profile. However, the range of the predicate
<code>prov:generatedAtTime</code> is not limited to xsd:dateTimeStamp -
non-timezoned values of xsd:dateTime are also permitted.</p>
</aside>
<p class="ednote">If some property (e.g., in the RSP-QL namespace) is defined as a
subproperty of <code>prov:generatedAtTime</code>, then this can be substituted in <a
href="#literal-rdf-stream">Example 4</a>, which will then serve as an example of a
time series. Alternatively, the definition could be changed so that the only requirement
is that the timestamps that occur in the stream belong to xsd:dateTime. </p>
<p class="note">The set of RDF time series is closed under RDF stream merge and union on
time series that use the same timestamp predicate.</p>
</section>
<section id="distinct-time-series-profile">
<h4>RDF Distinct Time-Series Profile</h4>
<p>An "RDF distinct time series" is an RDF time series such that no two elements in the
time series have the same timestamp.</p>
<aside class="example">
<p> A distinct time series example ...</p>
</aside>
<p class="note">An RDF distinct time series has a unique sequential order - it is
S-isomorphic only to itself.</p>
<p class="note">The merge or union of RDF distinct time series is always defined but is
not necessarily an RDF distinct time series, even if the operation is restricted to time
series that use the same timestamp predicate, due to the possibility of duplication of
timestamp. However, the merge or union of RDF distinct time series that use the same
timestamp predicate is always an RDF time series. </p>
<p class="note">The restriction of element-count-based window relations
to distinct time series results in functional
relations. This enables the definition of element-count-based window functions for distinct time series.
Further, the element-count-based window functions are always computable. However, the
time-based window functions are not necessarily computable unless there is a finite
precision to the timestamps, as can be seen from the Zeno's paradox example @@@(this
example hasn't been written up yet, but is mentioned elsewhere). </p>
<p class="ednote">There is going to be a lot more to talk about for RDF time series
relative to queries, but in this document we don't have those definitions.</p>
</section>
<section id="regular-time-series-profile">
<h4>RDF Regular Time-Series Profile</h4> A <em>regular</em> RDF time series is a further
subclass of distinct time series where the duration between timestamps is an integer
multiple of a specified duration, called the <em>spacing</em> of the time series. <aside
class="example">
<p> A regular time series example ...</p>
</aside>
<p class="note"> The restriction of timestamps in the regular time series profile allows
the timestamp to be represented concisely as an integer, provided the spacing is
provided elsewhere, e.g., in metadata. </p>
</section>
<section id="distinct-regular-time-series-profile">
<h4>RDF Distinct Regular Time-Series Profile</h4> A <em>distinct regular</em> RDF time
series is a further subclass of distinct time series that is both a distinct time series
and a regular time series. <aside class="example">