-
Notifications
You must be signed in to change notification settings - Fork 14
Expand file tree
/
Copy pathindex.html
More file actions
1333 lines (1215 loc) · 71.6 KB
/
index.html
File metadata and controls
1333 lines (1215 loc) · 71.6 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 Processing: Requirements and Design Principles</title>
<meta charset="utf-8">
<script src="http://www.w3.org/Tools/respec/respec-w3c-common"
async class="remove"></script>
<script class="remove">
var respecConfig = {
specStatus: "CG-DRAFT",
edDraftURI: "http://streamreasoning.github.io/RSP-QL/RSP_Requirements_Design_Document/",
shortName: "rdf-stream-semantics",
editors: [
{name: "Jean-Paul Calbimonte",company: "EPFL",companysURL: "http://epfl.ch",mailto: ""}
],
authors: [
{name: "Darko Anicic", company: "SIEMENS AG"},
{name: "Jean-Paul Calbimonte",company: "EPFL",companysURL: "http://epfl.ch",mailto: ""},
{name: "Oscar Corcho", company:"Universidad Politécnica de Madrid and LocaliData"},
{name: "Daniele Dell'Aglio", company:"Politecnico di Milano"},
{name: "Emanuele Della Valle", company:"Politecnico di Milano"},
{name: "Shen Gao", company:"University of Zurich"},
{name: "Alasdair J G Gray", company:"Heriot-Watt University"},
{name: "Danh Le-Phuoc", company:"Insight Centre for Data Analytics"},
{name: "Robin Keskisärkkä", company:"Linköping University"},
{name: "Alejandro Llaves", company:"Universidad Politécnica de Madrid"},
{name: "Alessandra Mileo", company:"Insight Center for Data Analytics"},
{name: "Bernhard Ortner", company:"TU Wien"},
{name: "Adrian Paschke", company:"Freie Universitaet Berlin"},
{name: "Monika Solanki", company:"University of Oxford"},
{name: "Roland Stühmer", company:"IBM"},
{name: "Kia Teymourian", company:"Rice University"},
{name: "Peter Wetz", company:"TU Wien"}
],
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"
]
},
"RSP-USECASES":{
title:"RSP Use Cases",
href:"https://www.w3.org/community/rsp/wiki/Use_cases",
authors:["W3C RSP Community Group"]
},
"MSV": {
title: "The Media State Vector: A unifying concept for multi-device media navigation",
href: "http://dl.acm.org/citation.cfm?doid=2457413.2457427",
authors: [
"Ingar M. Arntzen",
"Njål T. Borch",
"Christopher P. Needham"
]
},
"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"
},
"ALLEN1983":{
title:"Maintaining knowledge about temporal intervals. Communications of the ACM, 26(11), pp.832–843. 1983",
href:"http://dl.acm.org/citation.cfm?id=358434",authors:["Allen, J.F."]
},
"ANICIC2010":{
authors:["Anicic, D.","Fodor, P.","Rudolph, S.","Stühmer, R.","Stojanovic, N.","Studer, R."],
title:"A Rule-Based Language for Complex Event Processing and Reasoning, RR 2010"},
"ANICIC2011":{
authors:["Darko Anicic", "Paul Fodor", "Sebastian Rudolph", "Nenad Stojanovic"],
title:"EP-SPARQL: A Unified Language for Event Processing and Stream Reasoning, WWW 2011"},
"ARASU2006":{
authors:["Arvind Arasu", "Shivnath Babu", "Jennifer Widom"],
title:"The CQL continuous query language: semantic foundations and query execution. VLDB J. 15(2): 121-142 (2006)",
href:"http://dx.doi.org/10.1007/s00778-004-0147-z"},
"SR4LD2014":{
authors:["M. Balduini", "J.-P. Calbimonte", "D. Dell’Aglio", "O. Corcho","E. Della Valle"],
title:"Stream Reasoning for Linked Data Tutorial. Tutorial at the 13th International Semantic Web Conference ISWC. Riva del Garda, Italy October 2014",
href:"http://streamreasoning.org/events/sr4ld2014"},
"CHAKRAVARTHY2009":{
authors:["Sharma Chakravarthy", "Qingchun Jiang"],
title:"Stream Data Processing: A Quality of Service Perspective: Modeling, Scheduling, Load Shedding, and Complex Event Processing. Springer Science & Business Media."
},
"CUGOLA2012":{
authors:["Gianpaolo Cugola","Alessandro Margara"],
title:"Processing flows of information: From data stream to complex event processing. ACM Comput. Surv. 44, 3, Article 15 (June 2012).",
href:"http://dx.doi.org/10.1145/2187671.2187677"},
"ETZION2010":{
authors:["Etzion, O.","Niblett, P."],
title:"Event Processing in Action. Manning Publications Co. (2010)"},
"DELLAGLIO2013":{
authors:["Daniele Dell’Aglio", "Jean-Paul Calbimonte", "Marco Balduini", "Oscar Corcho", "Emanuele Della Valle"],
title:"On Correctness in RDF Stream Processor Benchmarking, The Semantic Web – ISWC 2013 Volume 8219 of the series LNCS pp 326-342",
href:"http://link.springer.com/chapter/10.1007/978-3-642-41338-4_21"},
"DEHGHANZADEH2015":{
authors:["Soheila Dehghanzadeh","Daniele Dell'Aglio","Shen Gao","Emanuele Della Valle","Alessandra Mileo","Abraham Bernstein"],
title:"On Combining RDF Streams and Remotely Stored Background Data. RSP Workshop at ESWC 2015",
href:"https://www.w3.org/community/rsp/files/2015/05/RSP_Workshop_2015_submission_16.pdf"},
"DUL":{
authors:["Gangemi, A."],
title:"DOLCE+DnS Ultralite (DUL) [Link] (2009)",
href:"http://ontologydesignpatterns.org/wiki/Ontology:DOLCE+DnS_Ultralite"},
"GAO2015":{
title:"Running out of Bindings? Integrating Facts and Events in Linked Data Stream Processing. OrdRing 2015@ISWC",
authors:["Shen Gao","Thomas Scharrenbach","Joerg-Uwe Kietz","Abraham Bernstein"]},
"HARTH2011":{
authors:["Harth, A.", "Stühmer, R."],
title:"Publishing Event Streams as Linked Data Karlsruhe Institute of Technology, FZI Forschungszentrum Informatik (2011)",
href:"http://km.aifb.kit.edu/sites/lodstream/"},
"KIAESPER":{
authors:["Kia Teymourian"],
title:"EsperRSP",
href:"https://github.com/kiat/EsperRSP"},
"LUCKHAM2011":{
authors:["Luckham, D. C.", "Schulte, R."],
title:"Event Processing Glossary - Version 2.0 (2011)",
href:"http://www.complexevents.com/2011/08/23/event-processing-glossary-version-2-0/"},
"MAIER2005":{
authors:["Maier, D.", "Li, J.","Tucker, P.","Tufte, K.","Papadimos, V."],
title:"Semantics of Data Streams and Operators Proceedings of the 10th International Conference on Database Theory, Springer-Verlag, 2005, 37-52 [8]"},
"PASCHKE2006":{
authors:["Paschke, A."],
title:"ECA-RuleML: An Approach combining ECA Rules with temporal interval-based KR Event/Action Logics and Transactional Update Logics. CoRR abs/cs/0610167 (2006)",
href:"http://arxiv.org/ftp/cs/papers/0610/0610167.pdf"},
"STONEBRAKER2005":{
authors:["Stonebraker, M.","Çetintemel, U.","Zdonik, S."],
title:"The 8 requirements of real-time stream processing. ACM SIGMOD Record, 34(4), 42-47. 2005."},
"TEYMOURIAN2009":{
authors:["Teymourian, K.","Paschke A."],
title: "Semantic Rule-Based Complex Event Processing. RuleML 2009: 82-92 ",
href:"http://dx.doi.org/10.1007/978-3-642-04985-9_10"},
"TUCKER2003":{
authors:["Tucker, P.","Maier, D.","Sheard, T.","Fegaras, L."],
title:"Exploiting punctuation semantics in continuous data streams Knowledge and Data Engineering, IEEE Transactions on, 2003, 15, 555-568 [7]"}
},
otherLinks: [
{
key: "Version history",
data: [
{
value: "GitHub streamreasoning/RSP-QL/commits",
href: "https://github.com/streamreasoning/RSP-QL/commits/gh-pages"
}
]
},
{
key: "Participate",
data: [
{
value: "W3C RSP Community Group",
href: "https://www.w3.org/community/rsp/"
},{
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">
<h2>Introduction</h2>
<p>Data streams are one of the main sources of information in a wide range of domains and applications,
and it is required to make these streams available at Web scale.
For this to become a reality, we need to define Web standards and guidelines on how to produce and consume structured data streams.
<acronym title="RDF">RDF</acronym> ([[!RDF11-primer]]) is a <acronym title="World Wide Web Consortium">W3C</acronym> recommendation
for structuring and representing data on the Web.
However, this model is based on a traditional persisted-data paradigm, where the focus is on maintaining a bounded set of data elements
in a knowledge base. This paradigm does not fit the case of data streams, where data elements flow continuously over time, forming
unbounded sequences of data.
</p>
<p>In this context, the <a href="https://www.w3.org/community/rsp/">W3C <acronym title="RDF Stream Processing">RSP</acronym> Community
Group</a> has taken the task to explore the existing technical and theoretical proposals that incorporate streams to the RDF model
and to its query language, SPARQL [[!SPARQL11-OVERVIEW]].
More concretely, one of the main goals of the RSP Group is to define a common but extensible core model for RDF stream processing.
It is not the intention of the RSP Group to propose a one-size-fits-all model, which is probably infeasible, but rather a
common ground that can serve as a starting point for RSP engines to be able to interoperate.
</p>
<p>This document proposes a set of requirements for RDF stream processing and design principles for an RDF stream data model and query
language.
The remainder of the document is structured in three parts. First we state the key requirements for the RSP model in
<a href="#requirements">Section 2</a>.
Second we provide a proposal of design principles for a data model that extends RDF to support streams in <a href="#rspmodel">Section 3</a>.
Finally <a href="#rspquery">Section 4</a> describes the design principles for the SPARQL query feature extensions to comprehend the RDF
Stream model.
</p>
</section>
<section id="requirements">
<h2>Requirements</h2>
<p>The requirements for RDF stream processing summarized below are the result of the RSP Group on existing use cases [[RSP-USECASES]], as
well as the needs gathered by analyzing existing works of the state of the art. Many of them are also valid for non-RDF systems
(e.g., see [[STONEBRAKER2005]]) while others come as the result of our individual or joint work on extending RDF for stream processing.
The requirements are stated at a high level, and we do not fully detail them as in the use cases.
The goal is to allow the reader to understand the challenges that RSP systems should be able to address.
</p>
<section>
<h3>Functional Requirements</h3>
<section>
<h4>Abstract Model</h4>
<ol>
<li>RDF streams should be representable in an abstract model and the semantics of this abstract model
should provide the basis of the results of RSP queries.</li>
<li>The RDF stream abstract model should be serialized in concrete formats derived from standard formats
extending beyond the standard format only when necessary.</li>
<li>An RDF stream should be identifiable with an
<a href="http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-IRIs">IRI</a>.</li>
<li>RDF streams may have timestamps based on different notions of time (time instants, intervals) with
different semantics (application, validity, transactional).</li>
In case no timestamp is associated to an RDF stream data element, the system is responsible for managing the
time-based ordering of stream elements.</li>
<li>The RDF stream model should be susceptible to be restricted in order to facilitate implementation
and support efficient representation.</li>
</ol>
</section>
<section>
<h4>Query Language</h4>
<ol>
<li>RSP queries should support combining multiple RDF streams as well as stored RDF (aka static RDF graphs or datasets).</li>
<li>RSP queries should support the minimal set of features identified in this document. </li>
<li>The semantics of the RSP data and query model should allow generating predictable results, so that
correctness of the RSP query process can be evaluated.</li>
<li>RSP queries should be able to access all knowledge explicitly expressed in the stream, including names
of named graphs and triples containing such names.</li>
<li>RSP queries should be able to refer to the named graphs of streams.</li>
</ol>
<p>In addition to these general requirements, we define a set of mandatory features for RSPs that implement query processing
and a set of optional features that they may support.</p>
<section><h4>Mandatory Query Processing Features</h4>
<ol>
<li>RSPs should be able to query streaming data from one or several RDF streams.</li>
<li>RSPs should be able to query data from RDF graphs combined with RDF streams.</li>
<li>RSPs should support <code>SELECT</code> and <code>CONSTRUCT</code> queries.</li>
<li>RSPs should support defining one or more time windows over an RDF stream.</li>
<li>RSPs should support all SPARQL 1.1 [[!SPARQL11-Query]] operators.</li>
<li>RSPs should support nesting RSP queries.</li>
</ol>
</section>
<section><h4>Optional Query Processing Features</h4>
<ol>
<li>RSPs may support defining count-based windows over RDF streams.</li>
<li>RSPs may support <code>RSTREAM</code>, <code>ISTREAM</code> and <code>DSTREAM</code> operators [[ARASU2006]].</li>
<li>RSPs may support sequence operators (a pattern followed by another pattern).</li>
<li>RSPs may support the <code>WITHIN</code> operator (evaluate if a pattern occurs within an interval).</li>
<li>RSPs may support combinations of sequence operators and window operators.</li>
<li>RSPs may support accessing timestamp information of the RDF stream within a query.</li>
</ol>
</section>
</section>
<section>
<h4>RSP Engines</h4>
<ol>
<li>RSPs should be capable of processing streams of data reactively.</li>
<!--<li>RSPs should process streams of data actively and in-stream, without the need of storing them.
Systems may optionally store or archive streams but an RSP should be able to process them applying
sequences of operations as they flow over time.</li>-->
<li>RSP query engines should support a declarative query language derived from (and compatible with) SPARQL,
extended with operators that can consume and produce RDF streams.</li>
<li>RSP engines should be able to query a portion of the knowledge expressed in an RDF stream.</li>
<li>RSP engines should support defining a query that gets continuously executed over the RDF streams,
producing continuous results.</li>
</ol>
</section>
</section>
<section>
<h3>Non-Functional Requirements</h3>
<ol>
<li>The RSP data and query model should be compatible with RDF (e.g., reads it is as part of the dataset)
and SPARQL 1.1 [[!SPARQL11-Query]] (e.g., uses the same operators and query forms).</li>
<li>The RDF stream model should be extensible, so to allow different types of time notions (e.g., application
time) using standard vocabularies.</li>
<li>The RSP query model should allow extensions for specific operators beyond those described in this document
(e.g., other types of windows, CEP derived operators).</li>
<li>The expression of common query constructs should feel intuitive.</li>
</ol>
<p>Requirements related to the performance, throughput, efficiency, availability of the system concern the engines
that implement this model and not the model itself.
</p>
<p class="note">
The use cases could be mapped to these requirements.
</p>
</section>
<section>
<h3>Out of Scope</h3>
<ol>
<li>Record a stream.</li>
</ol>
<p class="note">Other requirements to be added as out of scope. <a href="https://github.com/streamreasoning/RSP-QL/issues/44">Issue</a></p>
</section>
</section>
<section id="rspmodel">
<h2>RSP Data Model: Design Principles</h2>
<p>The data model for representing RDF streams considers unbounded sequences of data elements that flow over time.
More specifically, these data elements are RDF triples, assembled in graphs, as an event or observation typically requires
more than one triple to be represented.
Each of these graphs in the sequence respects a particular order given by time annotations which can be explicit or implicit.
The main considerations for this abstract model are detailed below, first describing the time model, and then the RDF stream model itself.
</p>
<section>
<h3>Time in Stream Data Elements</h3>
<p>The notion of time in an RDF stream is important as it establishes an order among the data elements.
Time annotations (in some cases called timestamps) can be defined in a totally ordered domain with a distance metric.
Time can be represented as:
</p>
<ul>
<li>Time as a point-in-time instant.</li>
<li>Time as an interval (point in time is a special case of this).</li>
</ul>
<p>A convenient time model in this context is the Time Ontology in OWL [[!OWL-TIME]], which defines <code>Instant</code> and
<code>Interval</code> as subclasses of <code>TemporalEntity</code>.
</p>
<p>Within the time model we do not specify mechanisms for dealing with delayed and out of order triples.</p>
</section>
<section>
<h3>RDF Stream</h3>
<p>An RDF stream is a sequence of RDF graphs, including associated metadata, as a flexible mechanism to add time-related metadata.
The RSP group identified the following types of time metadata (although we do not exclude others):
</p>
<ul>
<li><b>production time:</b> when the data element was produced.</li>
<li><b>receiving time:</b> when the data element was made available to the RSP engine.</li>
<li><b>start time</b>, <strong>end time</strong>: when the data element was valid, started, and ended.</li>
</ul>
<p>In many cases the arrival order of the RDF graphs suffices as an “implicit timestamp” attached to each RDF graph.
In such cases the timestamp can be annotated as a <i>system timestamp</i>. In any case, for the abstract model the RDF stream
elements appear to be timestamped, even if this is done at the system level on arrival of data elements.
</p>
<p>An RDF stream processor may attach additional metadata, e.g., describing the time at which it received the data element.
Producers of RDF streams can attach the production time to the RDF graphs they stream. If the RDF graph represents information
with a validity interval, the producer can also attach metadata to describe the start and end time of the validity interval.
</p>
<p>An RDF stream should be defined under the following considerations:</p>
<ul>
<li>An RDF stream should be defined as a potentially unbounded sequence of time-annotated elements.</li>
<li>The time annotation, or timestamp should be defined on a time domain, which we leave open for possible different types of
timestamps and intervals. One example domain is the discrete, linearly ordered, and infinite set of time instants.</li>
<li>Each RDF stream element should contain an RDF graph, which can be identified or not.</li>
<li>Each RDF stream element should indicate a <dfn>timestamp predicate</dfn>, which establishes the RDF predicate
that the timestamp refers to. Examples of a timestamp predicate could include <code>prov:generatedAtTime</code> or
<code>ssn:observationSamplingTime</code>.</li>
<li>Every RDF stream has a unique IRI as an identifier.</li>
</ul>
<p>A key difference wrt previous RDF stream models is the support of streaming graphs instead of triples.
This allows to structure more complex events in a stream, as opposed to plain triples.
For example, an observation typically requires several triples to be described (e.g., observed property, value, time, observer).
Another example is related to the flexibility in timestamping (one vs. two timestamps or application time vs. system time), which
is only possible if timestamps can be attached to an event structure. That cannot be achieved with plain triples.
</p>
<p><b>Running Example:</b> In the following, we use the following example based in social sensing: i.e., people detected in rooms
over time.
URL of the stream: <code><http://example.org/streams/social></code>. Or <code>ex:social</code> if we set the prefix
<code>ex:</code> as <code>http://example.org/streams/</code>.
Sample data on the stream:
</p>
<pre class="example highlight" title="RDF Stream Example"><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>
<pre class="example highlight" title="RDF Stream Example with intervals"><code>
:g1 {:axel :isIn :RedRoom. :darko :isIn :RedRoom} {:g1 :atInterval 2016-03-01T13:00:00Z/2016-03-01T13:00:10Z}
:g2 {:axel :isIn :BlueRoom. } {:g2 :atInterval 2016-03-01T13:00:20Z/2016-03-01T13:00:40Z}
:g3 {:minh :isIn :RedRoom. } {:g3 :atInterval 2016-03-01T13:00:50Z/2016-03-01T13:00:60Z}
...
</code></pre>
</section>
<section>
<h3>Considerations</h3>
<section>
<h4>Punctuation</h4>
<p>A punctuation is a pattern <code>p</code> inserted into the data stream with the meaning that no data
element <code>i</code> matching <code>p</code> will occur further on in the stream [[TUCKER2003]] [[MAIER2005]].
For streams of RDF graphs this can be used like this: A punctuation is a pattern <code>p</code>
inserted into the graph stream with the meaning that no triples <code>i</code> from graph <code>p</code>
will occur further on in the stream.
In order to implement punctuation, special triples (ones that indicate punctuation, e.g.,
<code><:g rsp:punctuate rsp:now></code>) could be employed.
However, as we use the Web stack we can do punctuation out-of-band, i.e., by doing punctuation on a lower
layer of the stack. For example we can communicate through chunked transfer encoding ([[RFC2616]], Section 3.6.1)
from HTTP 1.1 [[HTTP11]].
Each chunk contains a complete graph and the receiver will know that after a chunk is received the event is
completely received and can be processed further in an atomic fashion. There is a guarantee that no triples
for this graph will arrive later. Using HTTP chunked connections no special triples are needed.
</p>
</section>
<section>
<h4>Immutability and Event Derivation</h4>
<p>In many event processing systems [[CUGOLA2012]], events are immutable [[LUCKHAM2011]].
This stems from the definition of what an event is: An event is <i>"an occurrence within a particular system
or domain; it is something that has happened, or is contemplated as having happened"</i> [[ETZION2010]].
So events cannot be made to unhappen.
</p>
<p class="note">
Open Question: Does this apply to all systems/applications/usecases or just to many as stated above?
</p>
<p>Adopting immutability as a general assumption can be very useful for building systems, as it allows more control
over the correctness and predictability of the system, especially in a distributed environment and when consistency
is at stake in a concurrent processing setting.
But then, how can a stream processing agent process events if they are immutable? Every processing task produces
new derived events as results, and as an advantage the underived events are still available for other uses and
remain immutable.
For RSP this means: (1) create a new (unique) graph for the derived event and (2) possibly link back to the base
event(s) thus enabling drill-down or root cause / provenance analysis of the derived event. The links can be made
with <code>DUL:hasConstituent</code> from DOLCE Ultralight [[DUL]], or with sub-properties such as in [[HARTH2011]].
</p>
</section>
</section>
</section>
<section id="rspquery">
<h2>RDF Stream Query Language: Design Principles</h2>
<p>RDF stream query processing languages have been proposed in the past, and some of the features described in this section
have been presented in one or more of these languages. In this section we selected the most prominent query language features,
which we consider would be essential or at least important in a standard RSP query language.
When applicable, we compare with existing query languages, and if necessary, we propose new query constructs or combinations, if
they were not supported in existing languages.
</p>
<section>
<h3>Input</h3>
<p>The input for an RSP query may include streams and stored data. In SPARQL, the query input is encapsulated on a dataset that
declares a default and named graphs. Based on this assumption, an RSP query is posed against an extended dataset, composed of
(potentially):
</p>
<ul>
<li>One or more RDF streams </li>
<li>One or more RDF graphs </li>
</ul>
<p>For stored RDF graphs the declaration of named and unnamed graphs should follow the SPARQL specification of a dataset. For
declaring streams a similar mechanism can be applied.
For example in C-SPARQL this has been achieved with a similar declaration via the <code>FROM</code> clause:
<ul><li><code>FROM STREAM ex:social [… window spec …]</code></li></ul>
As a consequence, windowed streams in this case are merged, so that the result can be accessed in the query body.
Alternatively, in CQELS streams can be accessed individually inside the query body, therefore not requiring a merge
previously:
<ul><li><code>WHERE {STREAM ex:social [… window spec …] { }</code></li></ul>
</p>
<p>The proposed approach should consider the declaration of streams (and window declarations), and the individual usage of
windows inside the query body. We will analyze the window definitions later, but we already show how streams can be declared
in the <code>FROM</code> clause and, thanks to a window identifier, they can be used in the query body:
</p>
<pre class="example highlight" title="RSP-QL: Declaration of a window <code>:win</code> for the <code>ex:social</code> stream."><code>
FROM NAMED WINDOW :win ON ex:social [… window spec …]
</code></pre>
<p>Notice that in a single query one may issue different windows for the same stream (e.g., with different window parameters,
such as size or slide), on multiple streams, or combined with RDF graphs. The following example shows a declaration of multiple
windows on several streams, combined with standard named graph declarations. We omit the window specifications, as they will be
covered later on.</p>
<pre class="example highlight" title="RSP-QL: Declaration of multiple windows for multiple streams."><code>
FROM NAMED WINDOW :win1 ON ex:social [RANGE PT10M]
FROM NAMED WINDOW :win2 ON ex:social [RANGE PT1M]
FROM NAMED WINDOW :win3 ON ex:sensors [RANGE PT1M]
FROM NAMED :people
</code></pre>
</section>
<section>
<h3>Output</h3>
<p>Depending on the Query form (e.g., <code>SELECT</code>, <code>CONSTRUCT</code>), the output can be of a different form.
Also, depending if the results are returned as a stream or as finite sets, the output is of a different type. In summary,
an RSP query answer could have the following types of output:
</p>
<ul>
<li>Sets of bindings: If the query is a <code>SELECT</code> and the result is not streamed.</li>
<li>Stream of bindings: If the query is a <code>SELECT</code> and the result is streamed.</li>
<li>Sets of graphs: If the query is a <code>CONSTRUCT</code> and the result is not streamed.</li>
<li>Stream of graphs: If the query is a <code>CONSTRUCT</code> and the result is streamed.</li>
</ul>
<p class="note">How are the timestamps of the graphs defined in the query results?</p>
<p>Results of a query could be part of a subscription, allowing the query client to obtain results as soon as they are
available, or following subscription rules. These aspects are related to the architecture of an RSP engine, and are not
part of this document.
</p>
</section>
<!-- Overview ================================================================================== -->
<section>
<h3>RDF Stream Operators: Overview</h3>
<p>Following the model as proposed in several previous works, we consider three main classes of operators over RDF streams
and RDF graphs (for more information refer also to [[SR4LD2014]]):
</p>
<ul>
<li><b>S2R:</b> Stream to bounded RDF, which inherits the idea of stream-to-relation
operators in CQL which produce a relation from a stream.</li>
<li><b>R2R:</b> Bounded RDF to RDF, which inherits the idea of relation-to-relation
operators in CQL which produce a relation from one or more other relations.</li>
<li><b>R2S:</b> Bounded RDF to Stream, which inherits the idea of relation-to-stream
operators in CQL which produce a stream from a relation.</li>
</ul>
<p>In addition to these operators, we may consider S2S operators that take and produce a stream (e.g., stream filtering).</p>
<p>In these RSP operators the R denotes finite RDF graphs or mappings, as opposed to unbounded sequences of RDF graphs,
i.e., streams.
In addition to those operators (which can be thought of as part of a RSP Data Manipulation Language (DML) in SQL terms),
there is also the need for a Data Definition Language (DDL) to register a stream, register continuous queries, etc.
Of all known RSP languages, only C-SPARQL has DDL primitives, but they are limited to query registration, e.g.,
<code>REGISTER (QUERY|STREAM) name AS</code>.
</p>
<p>In the case of R2R operators, existing SPARQL 1.1 [[SPARQL11-Query]] operators are already covered by the SPARQL
specification and semantics, and should be supported in an RSP query language (semantics for RDF streams may need
adaptations).
</p>
</section>
<!-- S2S ================================================================================== -->
<section>
<h3>S2S Operators</h3>
<p>While S2S operators can be seen as a combination of S2R and R2S, it can be argued that for some tasks, e.g., stream
filtering or others, it is not necessarily desired that S2R operators must be used. Most window-based RSP systems do
not support this type of operations, and therefore it is not technically possible to define this type of queries in
these systems. Also, the lack of use of S2R operators in this scenario may lead to scalability
issues as the number of stream elements to be considered is never limited.
However, in cases where neither joins nor aggregations are performed, e.g., simple graph pattern matching and filtering, when
past stream elements can be forgotten, this type of query can be of use.
</p>
<section>
<h4>SELECT</h4>
<p>The projection is performed using the <code>SELECT</code> clause that includes the variable names in the query body
that are requested in the results. As mentioned before, existing window-based RSP languages can only operate over
windows and not directly on the streams.
For instance, if we simply want to output who is in which room, following the previous example, this can be a achieved
in CQELS by setting up a time window with any (reasonably small) window size. In this case the window size does not
have any impact on the results, as in CQELS the output is provided as soon as there is a match (also known as a content
change window policy).
</p>
<pre class="example highlight" title="Query: Who is where? in CQELS:"><code>
SELECT ?room ?person
WHERE {
STREAM ex:social [RANGE 1m] {?person :isIn ?room}
}
</code></pre>
<p>In RSP-QL we could be able to omit the window specification altogether.
</p>
<pre class="example highlight" title="Query: Who is where? in RSP-QL:"><code>
SELECT ?room ?person
FROM NAMED WINDOW :win ON ex:social
WHERE {
WINDOW :win {?person :isIn ?room}
}
</code></pre>
</section>
<section>
<h4>FILTER</h4>
<p>The filter operator is a selection as in standard SPARQL. In this case, as it is in the context of a S2S operation, it
follows the same considerations as the previous case. For illustrative purposes we show an example of how such type of query
could be specified.
</p>
<pre class="example highlight" title="Query: Where is Axel at each moment? in RSP-QL"><code>
SELECT ?room
FROM NAMED WINDOW :win ON ex:social
WHERE {
WINDOW :win {?person :isIn ?room. FILTER(?person = :axel) }
}
// Or alternatively this filter can be done simply as a BGP:
SELECT ?room
FROM NAMED WINDOW :win ON ex:social
WHERE {
WINDOW :win {:axel :isIn ?room.}
}
</code></pre>
</section>
<section>
<h4>Aggregations</h4>
<p>Some aggregation functions can also be applied directly over the stream without the need for an S2S operation, e.g.,
MAX, MIN, SUM.
</p>
</section>
<!-- S2R ================================================================================== -->
<section>
<h3>S2R Operators</h3>
<p>Several <a href="http://books.google.it/books?id=MWCfC9OKaToC&pg=PA15&lpg=PA15&dq=%22window+types+and+their+specification+using%22&source=bl&ots=yecRb2UyCc&sig=qtwry0AyDbDZ4bnKEcGnwGFLXXg&hl=en&sa=X&ei=3ufYU_bCGoTI0QXkx4DwCA&redir_esc=y#v=onepage&q=%22window%20types%20and%20their%20specification%20using%22&f=false%7Cdifferent">types of windows</a> exist [[CHAKRAVARTHY2009]]. Those illustrated below are a subset of interest to the RSP community. </p>
<section>
<h4>Time based sliding window</h4>
<p>A time-based sliding windows is defined by two parameters: the window size and the window slide. The size is specified in terms
of a time duration (e.g., 1 minute, 30 seconds, 1.3 days) and indicates that the window content, at time <code>t</code> will
contain only those elements whose timestamps are greater than <code>t-size</code>. The slide parameter, specified as a time duration,
indicates how often the window will be computed, or *slide* over time.
</p>
<p class="note">Additional case: About supporting windows that are not terminated by the current time, e.g., something like a window
from 10 minutes in the past until 5 minutes in the past? <a href="https://github.com/streamreasoning/RSP-QL/issues/49">Issue</a></p>
<p>As an example, consider a query that obtains the rooms where Axel has been in the last 10 minutes,
updating results every minute:
</p>
<pre class="example highlight" title="C-SPARQL:"><code>
REGISTER QUERY TrackAxelSliding AS
SELECT ?room
FROM STREAM ex:social [RANGE 10m SLIDE 1m]
WHERE {
:axel :isIn ?room
}
</code></pre>
<p>The same query can be specified in CQELS.</p>
<pre class="example highlight" title="CQELS:"><code>
SELECT ?room
WHERE {
STREAM ex:social [RANGE 10m SLIDE 1m]
{:axel :isIn ?room}
}
</code></pre>
<p>The results will be different depending on the RSP Engine that is used. For example in C-SPARQL the evaluation of the window is
performed each time the window closes. CQELS does it when the window content needs to be changed, i.e.,
in the event of a new update from incoming streams or the expiration of an element in a window. For a more detailed description of
these differences refer to [[DELLAGLIO2013]].
</p>
<p>In RSP-QL, this query would be written in a similar way,
<pre class="example highlight" title="RSP-QL:"><code>
SELECT ?room
FROM NAMED WINDOW :win ON ex:social [RANGE PT10M SLIDE PT01M]
WHERE {
WINDOW :win { :axel :isIn ?room }
}
</code></pre>
<p>Notice that the window size and slide follow the [[ISO8601]] standard for specifying durations. As the window is declared at the
beginning of the query, and it has an identifier (<code>:win</code> in this example), it can be reused as many times as necessary
in the query body.
</p>
</section>
<section>
<h4>Time-based tumbling window</h4>
<p>This is a special case of the general sliding window, when the size of the slide is equal to the window length. For example: Give
me the room where Axel has been in the last 10 minutes, updating results every 10 minutes.
</p>
<pre class="example highlight" title="CQELS:"><code>
SELECT ?room
WHERE {
STREAM ex:social [RANGE 10m TUMBLING] {:axel :isIn ?room}
}
</code></pre>
<p class="note">In RSP-QL we can use this syntax sugar or even omit the slide and default it to a tumbling window on that case.</p>
</section>
<section>
<h4>Triple-based windows</h4>
<p>In principle, triple-based windows were defined to emulate tuple count windows in CQL-like data stream systems. For example this
query returns the last five entries of a price stream in CQL:</p>
<pre class="example highlight" title="CQL tuple count window"><code>
Select P.price From Prices[Rows 5] as P
</code></pre>
<p>For our example, we can get the last three people detected in the stream with the following C-SPARQL query.</p>
<pre class="example highlight" title="C-SPARQL tripe window"><code>
REGISTER QUERY Track3latest AS
SELECT ?who
FROM STREAM ex:social [RANGE TRIPLES 3]
WHERE {
?who :isIn ?room
}
</code></pre>
<p>In this example it works because each triple in the stream is an event on itself. However, in the general case one event requires
several triples in the stream to be fully described. For example consider a stream containing observations as the following:
</p>
<pre class="example highlight" title="Observation"><code>
:obs1 a ssn:Observation;
ssn:observedBy :sensor1;
ssn:observedProperty :peopleInRoom;
ssn:observedValue :axel;
dul:locatedIn :redRoom.
</code></pre>
<p>If we ask for the latest three triples in the stream, we will not obtain the latest three observations, but only three triples, each one with
incomplete information. For this reason, C-SPARQL triple-based windows are not always useful, although they work as specified.
Other languages such as SPARQLStream do not include support for this altogether, as it has a demonstrated faulty behavior.
In the RSP model discussed in this W3C Community Group, as we allow representing RDF streams as sequences of graphs, rather than
just triples, it should be possible to redefine this operator, with cleaner semantics.
</p>
</section>
<section>
<h4>Count-based window based on Basic Graph Pattern</h4>
<p>This <a href="http://www.w3.org/TR/sparql11-query/#BasicGraphPatterns">BGP</a> count-based window is introduced to overcome the
above limitation of triple-based window on RDF streams defined as sequences of graphs. Instead of counting single triples, this
count-based window will count the groups of triples(subgraphs) that match a certain basic graph pattern.
For example, the above pattern can be used to query the last three observations (filtered by <code>observedValue :axel</code>) as events
composed from a set of triples.
</p>
<pre class="example highlight" title="RSP-QL"><code>
SELECT ?obs ?room
FROM NAMED WINDOW :win ON ex:social [RANGE BGP 3]
WHERE {
?obs a ssn:Observation;
ssn:observedBy ?sensor;
ssn:observedProperty :peopleInRoom;
ssn:observedValue :axel;
due:locatedIn ?room.
}
</code></pre>
<p class="note">The keyword TRIPLES above can be used instead of BGP as it also covers above triple window.</p>
</section>
<section>
<h4>Partitioned Windows (not supported)</h4>
<p>Deal with one input stream and several output streams (i.e., the partitions), over which the query is evaluated.
Partitioned windows are based on knowing the schema, and deciding how to do the partition in a way that simplifies the query. This makes it complicated
for RSP. Example queries (partitioned): In the examples below, we can partition the input stream by dividing it by people's name
and then evaluate the query. (i) Find for each person the time spent until she leaves a room and enters another (time spent in
a room). (ii) Find for each person the time elapsed between a person leaves room A and enters room B, independently of how many
rooms are traversed in between (transition time).
</p>
</section>
<section>
<h4>Predicate-based window (not supported)</h4>
<p>In Predicate-based windows, objects are qualified to be part of the window once they satisfy a certain query predicate. Similarly,
objects expire only when they no longer satisfy a certain predicate. Predicate-based windows are a generalization of time-based
and tuple-count sliding windows, and it needs some sort of caching mechanisms to be implemented.
</p>
<p>Example queries: For each person, continuously report the elapsed time between each two consecutive readings. Only the latest
reading of each person needs to be considered. Once the reading of a person is reported, the previous reading expires. In C-SPARQL
we could in principle simulate predicate-based windows by using a network of queries.
</p>
<pre class="example highlight" title="C-SPARQL"><code>
REGISTER STREAM :s1 AS
CONSTRUCT { :s1 :matches ?who }
FROM STREAM ex:social [RANGE ? STEP ?]
WHERE {
?who :isIn ?room
}
REGISTER QUERY :s2 AS
SELECT ?who
FROM STREAM :s1 [RANGE 3 TRIPLES]
WHERE {
:s1 :matches ?who
}
</code></pre>
<p class="note">It is a first sketch and it may not work as the CQELS one.</p>
<p>In the general case, CQELS also needs nested queries to present such queries. However, in CQELS, there is a syntax for specifying
last mappings that matched a certain basic graph pattern (using the BGP keyword). For example the query that retrieves the last three persons in
the room can be represented via the following query.
</p>
<pre class="example highlight" title="CQELS"><code>
SELECT ?who
WHERE {
STREAM ex:social [RANGE BGP 3] {?who :isIn ?room}
}
</code></pre>
</section>
</section>
<!-- R2R ================================================================================== -->
<section>
<h3>R2R Operators</h3>
<p>The R2R operators are inherited by SPARQL and they should follow the semantics of [[SPARQL11-Query]]. We do not describe them all in
this section but we focus on the most important ones, especially if there are specific details of interest for the RSP community.
</p>
<section>
<h4>SELECT</h4>
<p>We again use the query that returns the rooms and persons every minute.
</p>
<pre class="example highlight" title="RSP-QL"><code>
SELECT ?room ?person
FROM NAMED WINDOW :win ON ex:social [RANGE PT1M SLIDE PT1M]
WHERE {
WINDOW :win { ?person :isIn ?room }
}
</code></pre>
</section>
<section>
<h4>GROUPBY</h4>
<p>Aggregates are important operators in RSP and again we follow the SPARQL 1.1 aggregate semantics. The following example query
illustrates its use: Find a person who has been to more than 5 different rooms during the past 5 minutes:
</p>
<pre class="example highlight" title="C-SPARQL"><code>
REGISTER QUERY FastAndFurious AS
SELECT ?person (count(distinct ?room) as ?rooms)
FROM STREAM <S1> [RANGE 5m TUMBLING]
WHERE {?person :isIn ?room}
GROUPBY ?person
HAVING (?rooms >= 5)
</code></pre>
<pre class="example highlight" title="RSP-QL"><code>
SELECT ?person (count(distinct ?room) as ?rooms)
FROM NAMED WINDOW :win ON ex:social [RANGE PT5M]
WHERE {
WINDOW :win {?person :isIn ?room}
}
GROUPBY ?person
HAVING (?rooms >= 5)
</code></pre>
<p>In a similar way, other aggregates such as SUM, COUNT, MIN, MAX can also be supported.</p>
</section>
<section>
<h4>CONSTRUCT</h4>
<p>The construct query allows to create new graphs based on que query bindings as in SPARQL 1.1. As an example query consider the
following: Detect two different people in the same room for at least three seconds and create a graph of co-presence.
</p>
<pre class="example highlight" title="CQELS"><code>
CONSTRUCT {?p1 :isWith ?p2}
WHERE {
STREAM <s1> [RANGE 3s SLIDE 1s]
{ ?p1 isIn ?room. ?p2 isIn ?room. FILTER(?p1!=?p2)}
}
</code></pre>
<p>An RSP-QL query would follow a similar approach:
</p>
<pre class="example highlight" title="RSP-QL"><code>
CONSTRUCT {?p1 :isWith ?p2}
FROM NAMED WINDOW :win ON ex:social [RANGE PT3S SLIDE PT1S]
WHERE {
WINDOW :win { ?p1 isIn ?room. ?p2 isIn ?room. FILTER(?p1!=?p2)}
}
</code></pre>
<p>However, this query does not ensure that both people are present in the window for the entire three seconds. In EP-SPARQL, there is
a getDURATION() function that could be used for this type of query:
</p>
<pre class="example highlight" title="EP-SPARQL"><code>
CONSTRUCT {?p1 :isWith ?p2 .}
WHERE {STREAM <s1> { ?p1 isIn ?room. } AND {?p2 isIn ?room. }}
FILTER (?p1!=?p2 && getDURATION() < "PT3S"^^xsd:duration)
</code></pre>
</section>
<section>
<h4>OPTIONAL</h4>
<p>The <a href="https://www.w3.org/TR/sparql11-query/#optionals">Optional</a> pattern matching provides the following feature: "if the
optional part does not match, it creates no bindings but does not eliminate the solution" [[SPARQL11-Query]].
As an example consider que following query: detect persons who have entered either room1 or room2 in the past five minutes.
</p>
<pre class="example highlight" title="C-SPARQL"><code>
REGISTER QUERY OptionalQuery AS
SELECT ?person1 ?person2
FROM STREAM <S1> [RANGE 5m TUMBLING]
WHERE {
OPTIONAL {?person1 :isIn :room1}
OPTIONAL {?person2 :isIn :room2}
FILTER(bound(?person1) || bound(?person2))
}
</code></pre>
<p>In CQELS this is not supported, but it could work in two ways: first as in the previous example:
</p>
<pre class="example highlight" title="CQELS version1"><code>
SELECT ?person1 ?person2
WHERE {
STREAM <S1> [RANGE 5M] {
OPTIONAL {?person1 :isIn :room1}
OPTIONAL {?person2 :isIn :room2}
FILTER(bound(?person1) || bound(?person2))
}}
</code></pre>
<p>Alternatively, using two individual sensor streams for room1 and room2 as follows, by using bound filters.</p>
<pre class="example highlight" title="CQELS version2"><code>
SELECT ?person1 ?person2
WHERE {
OPTIONAL { STREAM<S1> [RANGE 5M] {?person1 :isIn :room1}}
OPTIONAL { STREAM<S2> [RANGE 5M] {?person2 :isIn :room2}}
FILTER(bound(?person1) || bound(?person2))
}
</code></pre>
</section>
<section>
<h4>FILTER MINUS</h4>
<p>While the support of this operator is uneven in RSP engines, it is important for use cases where a certain type of negation
is needed. More specifically, it "calculates solutions in the left-hand side that are not compatible with the solutions on the
right-hand side" [[SPARQL11-Query]].
As an example, consider the following query: detect persons who entered room1 without a doctorate during the past five minutes.
</p>
<pre class="example highlight" title="C-SPARQL (should be supported)"><code>
SELECT ?person
FROM STREAM <S1> [RANGE 5m TUMBLING]
FROM NAMED <profile>
WHERE {
{ { ?person :isIn :room1 }
FILTER MINUS
{GRAPH <profile> {?person :hasDegree :doctorate}
}
}
</code></pre>
<p class="note">It may parse, but it may not provide correct results. The problem is that all triples from the windows are merged in
the default graph.<a href="https://github.com/streamreasoning/RSP-QL/issues/50">Issue</a>
</p>
<p>In CQELS this is not supported although it is planned for future releases:</p>
<pre class="example highlight" title="CQELS (not currently supported):"><code>
SELECT ?person
WHERE {
{ STREAM<S1> [RANGE 5m] { ?person :isIn :room1}
MINUS
{GRAPH <profile> {?person :hasDegree :doctorate}
}
}
</code></pre>
<p class="note">What happens if the static part changes during the lifetime of the query?</p>
</section>
</section>
<!-- R2S ================================================================================== -->