├── README.md ├── Example_RDF_Streams ├── RGN_Location_TempC_Minute_Berlin.json ├── RGN_Location_TempC_Minute_Madrid.json ├── RGN_Location_TempC_Minute_Paris.json ├── Location_Subject.json ├── Location_Schedule_Harris_1024.json ├── README.md ├── RGN_Location_TempC_Minute_Merged.json ├── RGN_Location_TempC_Minute_Merged_b.json ├── RGN_Location_TempC_Minute_Merged_w_rank.json ├── Location_Schedule_Harris_1023.json ├── Location_Schedule_Harris.json ├── Location_Schedule_Harris_w_rank.json ├── BGN_Location_TempC_Minute_Berlin.json ├── BGN_Location_TempC_Minute_Madrid.json ├── BGN_Location_TempC_Minute_Paris.json ├── json-ld │ └── BGN_Location_TempC_Minute_Paris.json ├── BGN_Location_TempC_Minute_Unioned.json └── BGN_Location_TempC_Minute_Merged.json ├── DEBS Challenge 2015 data.md ├── srbench └── queries.md ├── Example_of_RSP-QL_query.md ├── TimeVocab.owl ├── LICENSE ├── Semantics.md ├── RSP-QL Sample Queries.md ├── Serialization.md └── Abstract Syntax and Semantics Document └── index.html /README.md: -------------------------------------------------------------------------------- 1 | RSP-QL 2 | ====== 3 | 4 | Home of RSP-QL syntax and semantics discussion of the W3C Community Group on RDF Stream Processing [1]. 5 | 6 | [1] https://www.w3.org/community/rsp/ 7 | -------------------------------------------------------------------------------- /Example_RDF_Streams/RGN_Location_TempC_Minute_Berlin.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | }, 12 | "source": {"@id": "http://example.org/data-sources/"} 13 | }, 14 | "@graph": [ 15 | { 16 | "@id": "source:Berlin_1", 17 | "observedAt": "2015-01-01T01:01:00" 18 | }, 19 | { 20 | "@id": "source:Berlin_2", 21 | "observedAt": "2015-01-01T01:02:00" 22 | }, 23 | { 24 | "@id": "source:Berlin_3", 25 | "observedAt": "2015-01-01T01:03:00" 26 | } 27 | ] 28 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/RGN_Location_TempC_Minute_Madrid.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | }, 12 | "source": {"@id": "http://example.org/data-sources/"} 13 | }, 14 | "@graph": [ 15 | { 16 | "@id": "source:Madrid_1", 17 | "observedAt": "2015-01-01T01:01:00" 18 | }, 19 | { 20 | "@id": "source:Madrid_2", 21 | "observedAt": "2015-01-01T01:02:00" 22 | }, 23 | { 24 | "@id": "source:Madrid_3", 25 | "observedAt": "2015-01-01T01:03:00" 26 | } 27 | ] 28 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/RGN_Location_TempC_Minute_Paris.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | }, 12 | "source": {"@id": "http://example.org/data-sources/"} 13 | }, 14 | "@graph": [ 15 | { 16 | "@id": "source:Paris_1", 17 | "observedAt": "2015-01-01T01:01:00" 18 | }, 19 | { 20 | "@id": "source:Paris_2", 21 | "observedAt": "2015-01-01T01:02:00" 22 | }, 23 | { 24 | "@id": "source:Paris_3", 25 | "observedAt": "2015-01-01T01:03:00" 26 | } 27 | ] 28 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/Location_Subject.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasLocation": { 9 | "@id": "http://example.org/property-vocabulary#hasLocation", 10 | } 11 | }, 12 | "@graph": [ 13 | { 14 | "@id": "_:1", 15 | "observedAt": "2015-01-01T01:00:00", 16 | "@graph": [ 17 | { 18 | "@id": "_:Subject_A", 19 | "hasLocation": "X" 20 | } 21 | ] 22 | }, 23 | { 24 | "@id": "_:2", 25 | "observedAt": "2015-01-01T01:01:00", 26 | "@graph": [ 27 | { 28 | "@id": "_:Subject_A", 29 | "hasLocation": "X" 30 | }, 31 | { 32 | "@id": "_:Subject_B", 33 | "hasLocation": "Y" 34 | } 35 | ] 36 | }, 37 | { 38 | "@id": "_:3", 39 | "observedAt": "2015-01-01T01:02:00", 40 | "@graph": [ 41 | { 42 | "@id": "_:Subject_B", 43 | "hasLocation": "X" 44 | } 45 | ] 46 | } 47 | ] 48 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/Location_Schedule_Harris_1024.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "time": "http://www.w3.org/2006/time#", 5 | "class": "http://www.example.org/class#", 6 | "room": "http://www.example.org/room#", 7 | "scheduledDuring": { 8 | "@id": "http://www.example.org/property-vocabulary#scheduledDuring", 9 | "@type": "time:Interval" 10 | }, 11 | "hasLocation": { 12 | "@id": "http://www.example.org/property-vocabulary#hasLocation", 13 | } 14 | }, 15 | "@graph": [ 16 | { 17 | "@id": "_:1", 18 | "scheduledDuring": [ 19 | {"time:hasBeginning": "2015-02-05T09:00:00", 20 | "time:durationDescriptionDataType": "P2H" 21 | } 22 | ], 23 | "@graph": [ 24 | { 25 | "@id": "class:Mathematics_402", 26 | "hasLocation": "room:Harris_1024" 27 | } 28 | ] 29 | }, 30 | { 31 | "@id": "_:2", 32 | "scheduledDuring": [ 33 | {"time:hasBeginning": "2015-02-05T11:00:00", 34 | "time:durationDescriptionDataType": "P4H" 35 | } 36 | ], 37 | "@graph": [ 38 | { 39 | "@id": "class:FineArt_208", 40 | "hasLocation": "room:Harris_1024" 41 | } 42 | ] 43 | } 44 | ] 45 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/README.md: -------------------------------------------------------------------------------- 1 | * Examples starting with "BGN" are RDF Stream examples that have bnode graph names. 2 | * Examples starting with "RGN" are RDF Stream examples that have IRI graph names. 3 | * Examples entitled "..._Location_TempC_Minute_(some city name).json" are RDF stream examples with 4 | data about temperature observations at a single location, given by the city name. 5 | * Examples with "Merged" in the name are the result of the merger of other RDF streams, where the 6 | merging operation requires renaming of blank nodes when necessary to keep them distinct. 7 | E.g., "RGN_Location_TempC_Minute_Merged.json" is the result of merging "RGN_Location_TempC_Minute_Berlin.json", "RGN_Location_TempC_Minute_Madrid.json", 8 | and "RGN_Location_TempC_Minute_Paris.json" 9 | * Examples with "Union" in the name are the result of the union of other RDF streams, where the streams are allowed 10 | to share blank nodes (i.e. they are on the same "surface"). 11 | * Examples with suffix "_b", "_c", ... are alternate serializations of the same RDF stream as the example without the suffix. 12 | * Examples with "rank" in the name are not JSON-LD, but are an extended description that includes an integer "rank". This value corresponds to the number of timestamped graphs in the stream that are less than or equal to the given timestamped graph (including itself). 13 | -------------------------------------------------------------------------------- /Example_RDF_Streams/RGN_Location_TempC_Minute_Merged.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | }, 12 | "source": {"@id": "http://example.org/data-sources/"} 13 | }, 14 | "@graph": [ 15 | { 16 | "@id": "source:Berlin_1", 17 | "observedAt": "2015-01-01T01:01:00" 18 | }, 19 | { 20 | "@id": "source:Madrid_1", 21 | "observedAt": "2015-01-01T01:01:00" 22 | }, 23 | { 24 | "@id": "source:Paris_1", 25 | "observedAt": "2015-01-01T01:01:00" 26 | }, 27 | { 28 | "@id": "source:Berlin_2", 29 | "observedAt": "2015-01-01T01:02:00" 30 | }, 31 | { 32 | "@id": "source:Madrid_2", 33 | "observedAt": "2015-01-01T01:02:00" 34 | }, 35 | { 36 | "@id": "source:Paris_2", 37 | "observedAt": "2015-01-01T01:02:00" 38 | }, 39 | { 40 | "@id": "source:Berlin_3", 41 | "observedAt": "2015-01-01T01:03:00" 42 | }, 43 | { 44 | "@id": "source:Madrid_3", 45 | "observedAt": "2015-01-01T01:03:00" 46 | }, 47 | { 48 | "@id": "source:Paris_3", 49 | "observedAt": "2015-01-01T01:03:00" 50 | } 51 | ] 52 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/RGN_Location_TempC_Minute_Merged_b.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | }, 12 | "source": {"@id": "http://example.org/data-sources/"} 13 | }, 14 | "@graph": [ 15 | { 16 | "@id": "source:Madrid_1", 17 | "observedAt": "2015-01-01T01:01:00" 18 | }, 19 | { 20 | "@id": "source:Berlin_1", 21 | "observedAt": "2015-01-01T01:01:00" 22 | }, 23 | { 24 | "@id": "source:Paris_1", 25 | "observedAt": "2015-01-01T01:01:00" 26 | }, 27 | { 28 | "@id": "source:Paris_2", 29 | "observedAt": "2015-01-01T01:02:00" 30 | }, 31 | { 32 | "@id": "source:Berlin_2", 33 | "observedAt": "2015-01-01T01:02:00" 34 | }, 35 | { 36 | "@id": "source:Madrid_2", 37 | "observedAt": "2015-01-01T01:02:00" 38 | }, 39 | { 40 | "@id": "source:Berlin_3", 41 | "observedAt": "2015-01-01T01:03:00" 42 | }, 43 | { 44 | "@id": "source:Madrid_3", 45 | "observedAt": "2015-01-01T01:03:00" 46 | }, 47 | { 48 | "@id": "source:Paris_3", 49 | "observedAt": "2015-01-01T01:03:00" 50 | } 51 | ] 52 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/RGN_Location_TempC_Minute_Merged_w_rank.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | }, 12 | "source": {"@id": "http://example.org/data-sources/"} 13 | }, 14 | "@graph": [ 15 | [3, { 16 | "@id": "source:Berlin_1", 17 | "observedAt": "2015-01-01T01:01:00" 18 | }], 19 | [3, { 20 | "@id": "source:Madrid_1", 21 | "observedAt": "2015-01-01T01:01:00" 22 | }], 23 | [3, { 24 | "@id": "source:Paris_1", 25 | "observedAt": "2015-01-01T01:01:00" 26 | }], 27 | [6, { 28 | "@id": "source:Berlin_2", 29 | "observedAt": "2015-01-01T01:02:00" 30 | }], 31 | [6, { 32 | "@id": "source:Madrid_2", 33 | "observedAt": "2015-01-01T01:02:00" 34 | }], 35 | [6, { 36 | "@id": "source:Paris_2", 37 | "observedAt": "2015-01-01T01:02:00" 38 | }], 39 | [9, { 40 | "@id": "source:Berlin_3", 41 | "observedAt": "2015-01-01T01:03:00" 42 | }], 43 | [9, { 44 | "@id": "source:Madrid_3", 45 | "observedAt": "2015-01-01T01:03:00" 46 | }], 47 | [9, { 48 | "@id": "source:Paris_3", 49 | "observedAt": "2015-01-01T01:03:00" 50 | }] 51 | ] 52 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/Location_Schedule_Harris_1023.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "time": "http://www.w3.org/2006/time#", 5 | "class": "http://www.example.org/class#", 6 | "room": "http://www.example.org/room#", 7 | "scheduledDuring": { 8 | "@id": "http://www.example.org/property-vocabulary#scheduledDuring", 9 | "@type": "time:Interval" 10 | }, 11 | "hasLocation": { 12 | "@id": "http://www.example.org/property-vocabulary#hasLocation", 13 | } 14 | }, 15 | "@graph": [ 16 | { 17 | "@id": "_:1", 18 | "scheduledDuring": [ 19 | {"time:hasBeginning": "2015-02-05T10:00:00", 20 | "time:durationDescriptionDataType": "P1H" 21 | } 22 | ], 23 | "@graph": [ 24 | { 25 | "@id": "class:Physics_101", 26 | "hasLocation": "room:Harris_1023" 27 | } 28 | ] 29 | }, 30 | { 31 | "@id": "_:2", 32 | "scheduledDuring": [ 33 | {"time:hasBeginning": "2015-02-05T11:00:00", 34 | "time:durationDescriptionDataType": "P2H" 35 | } 36 | ], 37 | "@graph": [ 38 | { 39 | "@id": "class:English_305", 40 | "hasLocation": "room:Harris_1023" 41 | } 42 | ] 43 | }, 44 | { 45 | "@id": "_:3", 46 | "scheduledDuring": [ 47 | {"time:hasBeginning": "2015-02-05T13:00:00", 48 | "time:durationDescriptionDataType": "P2H" 49 | } 50 | ], 51 | "@graph": [ 52 | { 53 | "@id": "class:ComputerScience_503", 54 | "hasLocation": "room:Harris_1023" 55 | } 56 | ] 57 | } 58 | ] 59 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/Location_Schedule_Harris.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "time": "http://www.w3.org/2006/time#", 5 | "class": "http://www.example.org/class#", 6 | "room": "http://www.example.org/room#", 7 | "scheduledDuring": { 8 | "@id": "http://www.example.org/property-vocabulary#scheduledDuring", 9 | "@type": "time:Interval" 10 | }, 11 | "hasLocation": {"@id": "http://www.example.org/property-vocabulary#hasLocation"} 12 | }, 13 | "@graph": [ 14 | { 15 | "@id": "_:1", 16 | "scheduledDuring": [{ 17 | "time:hasBeginning": "2015-02-05T09:00:00", 18 | "time:durationDescriptionDataType": "P2H" 19 | }], 20 | "@graph": [{ 21 | "@id": "class:Mathematics_402", 22 | "hasLocation": "room:Harris_1024" 23 | }] 24 | }, 25 | { 26 | "@id": "_:2", 27 | "scheduledDuring": [{ 28 | "time:hasBeginning": "2015-02-05T10:00:00", 29 | "time:durationDescriptionDataType": "P1H" 30 | }], 31 | "@graph": [{ 32 | "@id": "class:Physics_101", 33 | "hasLocation": "room:Harris_1023" 34 | }] 35 | }, 36 | { 37 | "@id": "_:3", 38 | "scheduledDuring": [{ 39 | "time:hasBeginning": "2015-02-05T11:00:00", 40 | "time:durationDescriptionDataType": "P4H" 41 | }], 42 | "@graph": [{ 43 | "@id": "class:FineArt_208", 44 | "hasLocation": "room:Harris_1024" 45 | }] 46 | }, 47 | { 48 | "@id": "_:4", 49 | "scheduledDuring": [{ 50 | "time:hasBeginning": "2015-02-05T11:00:00", 51 | "time:durationDescriptionDataType": "P2H" 52 | }], 53 | "@graph": [{ 54 | "@id": "class:English_305", 55 | "hasLocation": "room:Harris_1023" 56 | }] 57 | }, 58 | { 59 | "@id": "_:5", 60 | "scheduledDuring": [{ 61 | "time:hasBeginning": "2015-02-05T13:00:00", 62 | "time:durationDescriptionDataType": "P2H" 63 | }], 64 | "@graph": [{ 65 | "@id": "class:ComputerScience_503", 66 | "hasLocation": "room:Harris_1023" 67 | }] 68 | } 69 | ] 70 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/Location_Schedule_Harris_w_rank.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "time": "http://www.w3.org/2006/time#", 5 | "class": "http://www.example.org/class#", 6 | "room": "http://www.example.org/room#", 7 | "scheduledDuring": { 8 | "@id": "http://www.example.org/property-vocabulary#scheduledDuring", 9 | "@type": "time:Interval" 10 | }, 11 | "hasLocation": {"@id": "http://www.example.org/property-vocabulary#hasLocation"} 12 | }, 13 | "@graph": [ 14 | [1,{ 15 | "@id": "_:1", 16 | "scheduledDuring": [{ 17 | "time:hasBeginning": "2015-02-05T09:00:00", 18 | "time:durationDescriptionDataType": "P2H" 19 | }], 20 | "@graph": [{ 21 | "@id": "class:Mathematics_402", 22 | "hasLocation": "room:Harris_1024" 23 | }] 24 | }], 25 | [1,{ 26 | "@id": "_:2", 27 | "scheduledDuring": [{ 28 | "time:hasBeginning": "2015-02-05T10:00:00", 29 | "time:durationDescriptionDataType": "P1H" 30 | }], 31 | "@graph": [{ 32 | "@id": "class:Physics_101", 33 | "hasLocation": "room:Harris_1023" 34 | }] 35 | }], 36 | [3,{ 37 | "@id": "_:3", 38 | "scheduledDuring": [{ 39 | "time:hasBeginning": "2015-02-05T11:00:00", 40 | "time:durationDescriptionDataType": "P4H" 41 | }], 42 | "@graph": [{ 43 | "@id": "class:FineArt_208", 44 | "hasLocation": "room:Harris_1024" 45 | }] 46 | }], 47 | [3,{ 48 | "@id": "_:4", 49 | "scheduledDuring": [{ 50 | "time:hasBeginning": "2015-02-05T11:00:00", 51 | "time:durationDescriptionDataType": "P2H" 52 | }], 53 | "@graph": [{ 54 | "@id": "class:English_305", 55 | "hasLocation": "room:Harris_1023" 56 | }] 57 | }], 58 | [4,{ 59 | "@id": "_:5", 60 | "scheduledDuring": [{ 61 | "time:hasBeginning": "2015-02-05T13:00:00", 62 | "time:durationDescriptionDataType": "P2H" 63 | }], 64 | "@graph": [{ 65 | "@id": "class:ComputerScience_503", 66 | "hasLocation": "room:Harris_1023" 67 | }] 68 | }] 69 | ] 70 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/BGN_Location_TempC_Minute_Berlin.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | } 12 | }, 13 | "@graph": [ 14 | { 15 | "@id": "_:1", 16 | "observedAt": "2015-01-01T01:00:00", 17 | "@graph": [ 18 | { 19 | "@id": "Berlin", 20 | "hasTemp": "12.5" 21 | } 22 | ] 23 | }, 24 | { 25 | "@id": "_:2", 26 | "observedAt": "2015-01-01T01:01:00", 27 | "@graph": [ 28 | { 29 | "@id": "Berlin", 30 | "hasTemp": "12.5" 31 | } 32 | ] 33 | }, 34 | { 35 | "@id": "_:3", 36 | "observedAt": "2015-01-01T01:02:00", 37 | "@graph": [ 38 | { 39 | "@id": "Berlin", 40 | "hasTemp": "12.0" 41 | } 42 | ] 43 | }, 44 | { 45 | "@id": "_:4", 46 | "observedAt": "2015-01-01T01:03:00", 47 | "@graph": [ 48 | { 49 | "@id": "Berlin", 50 | "hasTemp": "11.5" 51 | } 52 | ] 53 | }, 54 | { 55 | "@id": "_:5", 56 | "observedAt": "2015-01-01T01:04:00", 57 | "@graph": [ 58 | { 59 | "@id": "Berlin", 60 | "hasTemp": "11.0" 61 | } 62 | ] 63 | }, 64 | { 65 | "@id": "_:6", 66 | "observedAt": "2015-01-01T01:05:00", 67 | "@graph": [ 68 | { 69 | "@id": "Berlin", 70 | "hasTemp": "10.5" 71 | } 72 | ] 73 | }, 74 | { 75 | "@id": "_:7", 76 | "observedAt": "2015-01-01T01:06:00", 77 | "@graph": [ 78 | { 79 | "@id": "Berlin", 80 | "hasTemp": "10.0" 81 | } 82 | ] 83 | }, 84 | { 85 | "@id": "_:9", 86 | "observedAt": "2015-01-01T01:08:00", 87 | "@graph": [ 88 | { 89 | "@id": "Berlin", 90 | "hasTemp": "9.0" 91 | } 92 | ] 93 | }, 94 | { 95 | "@id": "_:10", 96 | "observedAt": "2015-01-01T01:10:00", 97 | "@graph": [ 98 | { 99 | "@id": "Berlin", 100 | "hasTemp": "8.5" 101 | } 102 | ] 103 | } 104 | ] 105 | } -------------------------------------------------------------------------------- /DEBS Challenge 2015 data.md: -------------------------------------------------------------------------------- 1 | DEBS 2015 Grand Challenge example data: http://www.debs2015.org/call-grand-challenge.html 2 | ====== 3 | 4 | Data source : http://chriswhong.com/open-data/foil_nyc_taxi/ 5 | 6 | 7 | ##Data 8 | 9 | Provided data consists of reports of taxi trips including starting point, drop-off point, corresponding timestamps, and information related to the payment. Data are reported at the end of the trip, i.e., upon arrive in the order of the drop-off timestamps. 10 | The specific attributes are listed below: 11 | 12 | * medallion an md5sum of the identifier of the taxi - vehicle bound 13 | * hack_license an md5sum of the identifier for the taxi license 14 | * pickup_datetime time when the passenger(s) were picked up 15 | * dropoff_datetime time when the passenger(s) were dropped off 16 | * trip_time_in_secs duration of the trip 17 | * trip_distance trip distance in miles 18 | * pickup_longitude longitude coordinate of the pickup location 19 | * pickup_latitude latitude coordinate of the pickup location 20 | * dropoff_longitude longitude coordinate of the drop-off location 21 | * dropoff_latitude latitude coordinate of the drop-off location 22 | * payment_type the payment method - credit card or cash 23 | * fare_amount fare amount in dollars 24 | * surcharge surcharge in dollars 25 | * mta_tax tax in dollars 26 | * tip_amount tip in dollars 27 | * tolls_amount bridge and tunnel tolls in dollars 28 | * total_amount total paid amount in dollars 29 | 30 | Following are the two lines from the data file: 31 | 32 | ``` 33 | 07290D3599E7A0D62097A346EFCC1FB5,E7750A37CAB07D0DFF0AF7E3573AC141,2013-01-01 00:00:00,2013-01-01 00:02:00,120,0.44,-73.956528,40.716976,-73.962440,40.715008,CSH,3.50,0.50,0.50,0.00,0.00,4.50 34 | 22D70BF00EEB0ADC83BA8177BB861991,3FF2709163DE7036FCAA4E5A3324E4BF,2013-01-01 00:02:00,2013-01-01 00:02:00,0,0.00,0.000000,0.000000,0.000000,0.000000,CSH,27.00,0.00,0.50,0.00,0.00,27.50 35 | ``` 36 | 37 | 38 | 39 | ### Query 1: Frequent Routes 40 | 41 | Find the top 10 most frequent routes during the last 30 minutes. A route is represented by a starting grid cell and an ending grid cell. All routes completed within the last 30 minutes are considered for the query. 42 | 43 | ### Query 2: Profitable Areas 44 | 45 | Identify areas that are currently most profitable for taxi drivers. The profitability of an area is determined by dividing the area profit by the number of empty taxis in that area within the last 15 minutes. The profit that originates from an area is computed by calculating the median fare + tip for trips that started in the area and ended within the last 15 minutes. The number of empty taxis in an area is the sum of taxis that had a drop-off location in that area less than 30 minutes ago and had no following pickup yet. 46 | 47 | -------------------------------------------------------------------------------- /Example_RDF_Streams/BGN_Location_TempC_Minute_Madrid.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | } 12 | }, 13 | "@graph": [ 14 | { 15 | "@id": "_:1", 16 | "observedAt": "2015-01-01T01:00:00", 17 | "@graph": [ 18 | { 19 | "@id": "Madrid", 20 | "hasTemp": "8" 21 | } 22 | ] 23 | }, 24 | { 25 | "@id": "_:2", 26 | "observedAt": "2015-01-01T01:01:00", 27 | "@graph": [ 28 | { 29 | "@id": "Madrid", 30 | "hasTemp": "9" 31 | } 32 | ] 33 | }, 34 | { 35 | "@id": "_:3", 36 | "observedAt": "2015-01-01T01:02:00", 37 | "@graph": [ 38 | { 39 | "@id": "Madrid", 40 | "hasTemp": "9" 41 | } 42 | ] 43 | }, 44 | { 45 | "@id": "_:4", 46 | "observedAt": "2015-01-01T01:03:00", 47 | "@graph": [ 48 | { 49 | "@id": "Madrid", 50 | "hasTemp": "9" 51 | } 52 | ] 53 | }, 54 | { 55 | "@id": "_:5", 56 | "observedAt": "2015-01-01T01:04:00", 57 | "@graph": [ 58 | { 59 | "@id": "Madrid", 60 | "hasTemp": "9" 61 | } 62 | ] 63 | }, 64 | { 65 | "@id": "_:6", 66 | "observedAt": "2015-01-01T01:05:00", 67 | "@graph": [ 68 | { 69 | "@id": "Madrid", 70 | "hasTemp": "9" 71 | } 72 | ] 73 | }, 74 | { 75 | "@id": "_:7", 76 | "observedAt": "2015-01-01T01:06:00", 77 | "@graph": [ 78 | { 79 | "@id": "Madrid", 80 | "hasTemp": "9" 81 | } 82 | ] 83 | }, 84 | { 85 | "@id": "_:8", 86 | "observedAt": "2015-01-01T01:07:00", 87 | "@graph": [ 88 | { 89 | "@id": "Madrid", 90 | "hasTemp": "9" 91 | } 92 | ] 93 | }, 94 | { 95 | "@id": "_:9", 96 | "observedAt": "2015-01-01T01:08:00", 97 | "@graph": [ 98 | { 99 | "@id": "Madrid", 100 | "hasTemp": "9" 101 | } 102 | ] 103 | }, 104 | { 105 | "@id": "_:10", 106 | "observedAt": "2015-01-01T01:10:00", 107 | "@graph": [ 108 | { 109 | "@id": "Madrid", 110 | "hasTemp": "9" 111 | } 112 | ] 113 | } 114 | ] 115 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/BGN_Location_TempC_Minute_Paris.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | } 12 | }, 13 | "@graph": [ 14 | { 15 | "@id": "_:1", 16 | "observedAt": "2015-01-01T01:00:00", 17 | "@graph": [ 18 | { 19 | "@id": "Paris", 20 | "hasTemp": "8.2" 21 | } 22 | ] 23 | }, 24 | { 25 | "@id": "_:2", 26 | "observedAt": "2015-01-01T01:01:00", 27 | "@graph": [ 28 | { 29 | "@id": "Paris", 30 | "hasTemp": "8.3" 31 | } 32 | ] 33 | }, 34 | { 35 | "@id": "_:3", 36 | "observedAt": "2015-01-01T01:02:00", 37 | "@graph": [ 38 | { 39 | "@id": "Paris", 40 | "hasTemp": "8.4" 41 | } 42 | ] 43 | }, 44 | { 45 | "@id": "_:4", 46 | "observedAt": "2015-01-01T01:03:00", 47 | "@graph": [ 48 | { 49 | "@id": "Paris", 50 | "hasTemp": "8.5" 51 | } 52 | ] 53 | }, 54 | { 55 | "@id": "_:5", 56 | "observedAt": "2015-01-01T01:04:00", 57 | "@graph": [ 58 | { 59 | "@id": "Paris", 60 | "hasTemp": "8.6" 61 | } 62 | ] 63 | }, 64 | { 65 | "@id": "_:6", 66 | "observedAt": "2015-01-01T01:05:00", 67 | "@graph": [ 68 | { 69 | "@id": "Paris", 70 | "hasTemp": "8.7" 71 | } 72 | ] 73 | }, 74 | { 75 | "@id": "_:7", 76 | "observedAt": "2015-01-01T01:06:00", 77 | "@graph": [ 78 | { 79 | "@id": "Paris", 80 | "hasTemp": "8.8" 81 | } 82 | ] 83 | }, 84 | { 85 | "@id": "_:8", 86 | "observedAt": "2015-01-01T01:07:00", 87 | "@graph": [ 88 | { 89 | "@id": "Paris", 90 | "hasTemp": "8.9" 91 | } 92 | ] 93 | }, 94 | { 95 | "@id": "_:9", 96 | "observedAt": "2015-01-01T01:08:00", 97 | "@graph": [ 98 | { 99 | "@id": "Paris", 100 | "hasTemp": "9.0" 101 | } 102 | ] 103 | }, 104 | { 105 | "@id": "_:10", 106 | "observedAt": "2015-01-01T01:10:00", 107 | "@graph": [ 108 | { 109 | "@id": "Paris", 110 | "hasTemp": "9.1" 111 | } 112 | ] 113 | } 114 | ] 115 | } -------------------------------------------------------------------------------- /Example_RDF_Streams/json-ld/BGN_Location_TempC_Minute_Paris.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | } 12 | }, 13 | "@graph": [ 14 | { 15 | "@id": "_:1", 16 | "observedAt": "2015-01-01T01:00:00", 17 | "@graph": [ 18 | { 19 | "@id": "Paris", 20 | "hasTemp": "8.2" 21 | } 22 | ] 23 | }, 24 | { 25 | "@id": "_:2", 26 | "observedAt": "2015-01-01T01:01:00", 27 | "@graph": [ 28 | { 29 | "@id": "Paris", 30 | "hasTemp": "8.3" 31 | } 32 | ] 33 | }, 34 | { 35 | "@id": "_:3", 36 | "observedAt": "2015-01-01T01:02:00", 37 | "@graph": [ 38 | { 39 | "@id": "Paris", 40 | "hasTemp": "8.4" 41 | } 42 | ] 43 | }, 44 | { 45 | "@id": "_:4", 46 | "observedAt": "2015-01-01T01:03:00", 47 | "@graph": [ 48 | { 49 | "@id": "Paris", 50 | "hasTemp": "8.5" 51 | } 52 | ] 53 | }, 54 | { 55 | "@id": "_:5", 56 | "observedAt": "2015-01-01T01:04:00", 57 | "@graph": [ 58 | { 59 | "@id": "Paris", 60 | "hasTemp": "8.6" 61 | } 62 | ] 63 | }, 64 | { 65 | "@id": "_:6", 66 | "observedAt": "2015-01-01T01:05:00", 67 | "@graph": [ 68 | { 69 | "@id": "Paris", 70 | "hasTemp": "8.7" 71 | } 72 | ] 73 | }, 74 | { 75 | "@id": "_:7", 76 | "observedAt": "2015-01-01T01:06:00", 77 | "@graph": [ 78 | { 79 | "@id": "Paris", 80 | "hasTemp": "8.8" 81 | } 82 | ] 83 | }, 84 | { 85 | "@id": "_:8", 86 | "observedAt": "2015-01-01T01:07:00", 87 | "@graph": [ 88 | { 89 | "@id": "Paris", 90 | "hasTemp": "8.9" 91 | } 92 | ] 93 | }, 94 | { 95 | "@id": "_:9", 96 | "observedAt": "2015-01-01T01:08:00", 97 | "@graph": [ 98 | { 99 | "@id": "Paris", 100 | "hasTemp": "9.0" 101 | } 102 | ] 103 | }, 104 | { 105 | "@id": "_:10", 106 | "observedAt": "2015-01-01T01:10:00", 107 | "@graph": [ 108 | { 109 | "@id": "Paris", 110 | "hasTemp": "9.1" 111 | } 112 | ] 113 | } 114 | ] 115 | } -------------------------------------------------------------------------------- /srbench/queries.md: -------------------------------------------------------------------------------- 1 | Srbench queries 2 | =============== 3 | 4 | Taken from [http://www.w3.org/wiki/SRBench] 5 | 6 | ##Q1. Get the rainfall observed once in an hour. 7 | 8 | PREFIX om-owl: 9 | PREFIX weather: 10 | PREFIX srbench: 11 | SELECT ISTREAM ?sensor ?value ?uom 12 | FROM NAMED WINDOW ON STREAM srbench:observations [RANGE PT1H] AS :win 13 | WHERE { 14 | WINDOW :win { 15 | ?observation om-owl:procedure ?sensor ; 16 | a weather:RainfallObservation ; 17 | om-owl:result ?result . 18 | ?result om-owl:floatValue ?value ; 19 | om-owl:uom ?uom . 20 | }} 21 | 22 | ##Q4. Get the average wind speed at the stations where the air temperature is >32 degrees in the last hour, every 10 minutes. 23 | 24 | PREFIX om-owl: 25 | PREFIX weather: 26 | PREFIX xsd: 27 | 28 | SELECT ISTREAM ?sensor (AVG(?windSpeed) AS ?averageWindSpeed) 29 | (AVG(?temperature) AS ?averageTemperature) 30 | FROM NAMED WINDOW ON STREAM srbench:observations [RANGE PT3H SLIDE PT10M] AS :win 31 | WHERE { 32 | WINDOW :win { 33 | ?temperatureObservation om-owl:procedure ?sensor ; 34 | a weather:TemperatureObservation ; 35 | om-owl:result ?temperatureResult . 36 | ?temperatureResult om-owl:floatValue ?temperature ; 37 | om-owl:uom ?uom . 38 | FILTER(?temperature > "32"^^xsd:float ) 39 | ?windSpeedObservation om-owl:procedure ?sensor ; 40 | a weather:WindSpeedObservation ; 41 | om-owl:result [ om-owl:floatValue ?windSpeed ] . 42 | }} 43 | GROUP BY ?sensor 44 | 45 | ##Q5. Detect if a station is observing a blizzard. 46 | 47 | PREFIX om-owl: 48 | PREFIX weather: 49 | PREFIX xsd: 50 | 51 | CONSTRUCT ISTREAM{ ?sensor om-owl:generatedObservation [a weather:Blizzard] } 52 | FROM NAMED WINDOW ON STREAM srbench:observations [RANGE PT3H SLIDE PT10M] AS :win 53 | WHERE { 54 | WINDOW :win { 55 | SELECT ?sensor 56 | WHERE { 57 | ?sensor om-owl:generatedObservation [a weather:SnowfallObservation] ; 58 | om-owl:generatedObservation ?o1 ; 59 | om-owl:generatedObservation ?o2 . 60 | ?o1 a weather:TemperatureObservation ; 61 | om-owl:observedProperty weather:_AirTemperature ; 62 | om-owl:result [om-owl:floatValue ?temperature] . 63 | ?o2 a weather:WindObservation ; 64 | om-owl:observedProperty weather:_WindSpeed ; 65 | om-owl:result [om-owl:floatValue ?windSpeed] . 66 | } 67 | GROUP BY ?sensor 68 | HAVING ( AVG(?temperature) < "32"^^xsd:float && # fahrenheit 69 | MIN(?windSpeed) > "40.0"^^xsd:float ) #milesPerHour 70 | } 71 | } 72 | 73 | ##Q10. Get the locations where a heavy snowfall has been observed in the last day. 74 | 75 | PREFIX om-owl: 76 | PREFIX weather: 77 | PREFIX wgs84_pos: 78 | 79 | SELECT ISTREAM ?lat ?long ?alt 80 | FROM NAMED WINDOW ON STREAM srbench:observations [RANGE PT1H] AS :win 81 | FROM 82 | WHERE { 83 | WINDOW :w { 84 | ?sensor om-owl:generatedObservation [a weather:SnowfallObservation] . 85 | } 86 | ?sensor om-owl:processLocation ?sensorLocation . 87 | ?sensorLocation wgs84_pos:alt ?alt ; 88 | wgs84_pos:lat ?lat ; 89 | wgs84_pos:long ?long . 90 | } 91 | -------------------------------------------------------------------------------- /Example_of_RSP-QL_query.md: -------------------------------------------------------------------------------- 1 | This query continuously look for bars where people are falling in love like [http://en.wikipedia.org/wiki/Francesca_da_Rimini#In_Inferno Paolo and Francesca in Dante's Divine Comedy] because of a book by [http://en.wikipedia.org/wiki/Galehaut Gallehault]. 2 | 3 | The query checks : 4 | * over the default graph containing the points of interest (POIs) of http://somesocialnetwork.org/ that the POI is a bar. 5 | * over the a 4 hour long window on the stream from http://someinvasivesensornetwork.org, that pairs of people entered in the poi in different moments (if they enter together they get discarted). 6 | * over the same stream, with a time window of 30 minutes in the past, that pairs of those people have been staying close by for at least 30 minutes. Note: that this may require some resoning being the property isCloseBy symmetric. 7 | * over the same stream but with a short time window of 10 minutes, that the same pairs exit together. 8 | 9 | As output, for each bar, it streams out an RDF graph with the list of pairs and the total number of pairs that felt in love. 10 | 11 | Note that this example query covers features of C-SPARQL, CQELS, and SPARQL-Stream as well as new features missing in all RSP languages: 12 | * From C-SPARQL it takes the REGISTER clause, the FROM STREAM clause as dataset clause, the AT clause to access the timestamp (in C-SPARQL, AT is implemented with the timestamp() function) and the aggregates (which are computed in parallel without shrinking the result set, but extending it). 13 | * From CQELS it takes the idea of the STREAM keyword in the WHERE clause, herein defined as WINDOW. 14 | * From SPARQL-Stream it takes the ISTREAM clasue, that ask the RSP engine to use the R2S operator, and the notion of windows in the past. 15 | 16 | Differently from a previous version of this query, it no longer covers features of EP-SPARQL such as SEQ or the getDuration() function. This reflects the decision to layer the complex event processing language on a continuous querying one. 17 | 18 | The new features are: 19 | * the usage of an IRI to identify the query (and its stream of results) 20 | * the optional UNDER ENTAILMENT REGIME clause #PW: what is the main motivation for making the entailment regime explicit? basically, i like it, but am not sure, if it would/could lead to conflicts. for instance, an engine, which implements our RSP syntax, would need to be capable of the specified entailment regimes. and i am not sure, if/how this should be ensured. 21 | * the FROM NAMED WINDOW ON STREAM <> <> AS << window name>> clause in the dataset declaration 22 | * the WINDOW keyword in the WHERE clause 23 | 24 | ``` 25 | PREFIX e: 26 | PREFIX s: 27 | PREFIX g: 28 | PREFIX : 29 | REGISTER STREAM :GallehaultWasTheBar 30 | UNDER ENTAILMENT REGIME 31 | AS 32 | CONSTRUCT ISTREAM { 33 | ?poi rdf:type :Gallehault ; 34 | :count ?howmanycouples ; 35 | :for (?somebody ?someoneelse) 36 | } 37 | FROM NAMED WINDOW :veryLongWindow ON s:1 [RANGE PT4H STEP PT1H] 38 | FROM NAMED WINDOW :longWindow ON s:1 [FROM NOW-PT35M TO NOW-PT5M STEP PT5M] 39 | FROM NAMED WINDOW :shortWindow ON s:1 [RANGE PT10M STEP PT5M] 40 | FROM NAMED GRAPH g:SocialGraph 41 | FROM GRAPH g:POIs 42 | WHERE { 43 | ?poi rdf:type e:bar . 44 | WINDOW :veryLongWindow { 45 | {?somebody e:enters ?poi} BEGIN AT ?t3 46 | {?someoneelse e:enters ?poi} BEGIN AT ?t4 47 | FILTER(?t3>?t4) 48 | } 49 | WINDOW :longWindow { 50 | { 51 | ?somebody e:isCloseTo ?someoneelse 52 | MINUS { ?somebody e:isCloseTo ?yetanotherone . FILTER (?yetanotherone != ?someoneelse) } 53 | } WITH DURATION ?duration 54 | FILTER (?duration>="PT30M"^^xsd:duration) 55 | } 56 | WINDOW :shortWindow { 57 | { ?somebody e:exits ?bar} BEGIN AT ?t1 58 | { ?someoneelse e:exits ?bar } BEGIN AT ?t2 59 | FILTER (abs(?t2-?t1)<"PT1M"^^xsd:duration ) 60 | } 61 | GRAPH g:SocialGraph { 62 | FILTER NOT EXIST { ?somebody e:knows ?someoneelse } 63 | } 64 | FILTER (?somebody != ?someoneelse) 65 | } 66 | AGGREGATE { 67 | GROUP BY ?poi 68 | COUNT(?somebody) AS ?howmanycouples 69 | } 70 | ``` 71 | -------------------------------------------------------------------------------- /Example_RDF_Streams/BGN_Location_TempC_Minute_Unioned.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | } 12 | }, 13 | "@graph": [ 14 | { 15 | "@id": "_:1", 16 | "observedAt": "2015-01-01T01:00:00", 17 | "@graph": [ 18 | { 19 | "@id": "Berlin", 20 | "hasTemp": "12.5" 21 | }, 22 | { 23 | "@id": "Madrid", 24 | "hasTemp": "8" 25 | }, 26 | { 27 | "@id": "Paris", 28 | "hasTemp": "8.2" 29 | } 30 | ] 31 | }, 32 | { 33 | "@id": "_:2", 34 | "observedAt": "2015-01-01T01:01:00", 35 | "@graph": [ 36 | { 37 | "@id": "Berlin", 38 | "hasTemp": "12.5" 39 | }, 40 | { 41 | "@id": "Madrid", 42 | "hasTemp": "9" 43 | }, 44 | { 45 | "@id": "Paris", 46 | "hasTemp": "8.3" 47 | } 48 | ] 49 | }, 50 | { 51 | "@id": "_:3", 52 | "observedAt": "2015-01-01T01:02:00", 53 | "@graph": [ 54 | { 55 | "@id": "Berlin", 56 | "hasTemp": "12.0" 57 | }, 58 | { 59 | "@id": "Madrid", 60 | "hasTemp": "9" 61 | }, 62 | { 63 | "@id": "Paris", 64 | "hasTemp": "8.4" 65 | } 66 | ] 67 | }, 68 | { 69 | "@id": "_:4", 70 | "observedAt": "2015-01-01T01:03:00", 71 | "@graph": [ 72 | { 73 | "@id": "Berlin", 74 | "hasTemp": "11.5" 75 | }, 76 | { 77 | "@id": "Madrid", 78 | "hasTemp": "9" 79 | }, 80 | { 81 | "@id": "Paris", 82 | "hasTemp": "8.5" 83 | } 84 | ] 85 | }, 86 | { 87 | "@id": "_:5", 88 | "observedAt": "2015-01-01T01:04:00", 89 | "@graph": [ 90 | { 91 | "@id": "Berlin", 92 | "hasTemp": "11.0" 93 | }, 94 | { 95 | "@id": "Madrid", 96 | "hasTemp": "9" 97 | }, 98 | { 99 | "@id": "Paris", 100 | "hasTemp": "8.6" 101 | } 102 | ] 103 | }, 104 | { 105 | "@id": "_:6", 106 | "observedAt": "2015-01-01T01:05:00", 107 | "@graph": [ 108 | { 109 | "@id": "Berlin", 110 | "hasTemp": "10.5" 111 | }, 112 | { 113 | "@id": "Madrid", 114 | "hasTemp": "9" 115 | }, 116 | { 117 | "@id": "Paris", 118 | "hasTemp": "8.7" 119 | } 120 | ] 121 | }, 122 | { 123 | "@id": "_:7", 124 | "observedAt": "2015-01-01T01:06:00", 125 | "@graph": [ 126 | { 127 | "@id": "Berlin", 128 | "hasTemp": "10.0" 129 | }, 130 | { 131 | "@id": "Madrid", 132 | "hasTemp": "9" 133 | }, 134 | { 135 | "@id": "Paris", 136 | "hasTemp": "8.8" 137 | } 138 | ] 139 | }, 140 | { 141 | "@id": "_:8", 142 | "observedAt": "2015-01-01T01:07:00", 143 | "@graph": [ 144 | { 145 | "@id": "Madrid", 146 | "hasTemp": "9" 147 | }, 148 | { 149 | "@id": "Paris", 150 | "hasTemp": "8.9" 151 | } 152 | ] 153 | }, 154 | { 155 | "@id": "_:9", 156 | "observedAt": "2015-01-01T01:08:00", 157 | "@graph": [ 158 | { 159 | "@id": "Berlin", 160 | "hasTemp": "9.0" 161 | }, 162 | { 163 | "@id": "Madrid", 164 | "hasTemp": "9" 165 | }, 166 | { 167 | "@id": "Paris", 168 | "hasTemp": "9.0" 169 | } 170 | ] 171 | }, 172 | { 173 | "@id": "_:10", 174 | "observedAt": "2015-01-01T01:10:00", 175 | "@graph": [ 176 | { 177 | "@id": "Berlin", 178 | "hasTemp": "8.5" 179 | }, 180 | { 181 | "@id": "Madrid", 182 | "hasTemp": "9" 183 | }, 184 | { 185 | "@id": "Paris", 186 | "hasTemp": "9.1" 187 | } 188 | ] 189 | } 190 | ] 191 | } -------------------------------------------------------------------------------- /TimeVocab.owl: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 8 | 9 | 10 | ]> 11 | 12 | 13 | 20 | 21 | Microvocabulary capturing relations between streamed graphs and time instants. We reuse, i.e. specialize, from PROV ontology. 22 | 23 | 24 | 25 | 26 | 27 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | endsAtTime 42 | The time instant at which the validity of a graph ends. 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | generatedAtTime 53 | The time instant at which a graph was generated (do we also need observedAt cf. https://github.com/streamreasoning/RSP-QL/issues/11#issuecomment-112418620?) . 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | receivedAtTime 64 | The time instant at which a graph was received by an engine. 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | startsAtTime 74 | The time instant at which the validity of a graph starts. 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | transmittedAtTime 85 | The time instant at which a graph was transmitted to an engine. 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 | -------------------------------------------------------------------------------- /Example_RDF_Streams/BGN_Location_TempC_Minute_Merged.json: -------------------------------------------------------------------------------- 1 | { 2 | "@context": { 3 | "@vocab": "http://www.example.org/data-vocabulary#", 4 | "observedAt": { 5 | "@id": "http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#observationSamplingTime", 6 | "@type": "http://www.w3.org/2001/XMLSchema#dateTime" 7 | }, 8 | "hasTemp": { 9 | "@id": "http://example.org/property-vocabulary#hasPointTempC", 10 | "@type": "http://www.w3.org/2001/XMLSchema#decimal" 11 | } 12 | }, 13 | "@graph": [ 14 | { 15 | "@id": "_:1", 16 | "observedAt": "2015-01-01T01:00:00", 17 | "@graph": [{ 18 | "@id": "Berlin", 19 | "hasTemp": 12.5 20 | }] 21 | }, 22 | { 23 | "@id": "_:2", 24 | "observedAt": "2015-01-01T01:00:00", 25 | "@graph": [{ 26 | "@id": "Madrid", 27 | "hasTemp": 8 28 | }] 29 | }, 30 | { 31 | "@id": "_:3", 32 | "observedAt": "2015-01-01T01:00:00", 33 | "@graph": [{ 34 | "@id": "Paris", 35 | "hasTemp": 8.2 36 | }] 37 | }, 38 | { 39 | "@id": "_:4", 40 | "observedAt": "2015-01-01T01:01:00", 41 | "@graph": [{ 42 | "@id": "Berlin", 43 | "hasTemp": 12.5 44 | }] 45 | }, 46 | { 47 | "@id": "_:5", 48 | "observedAt": "2015-01-01T01:01:00", 49 | "@graph": [{ 50 | "@id": "Madrid", 51 | "hasTemp": 9 52 | }] 53 | }, 54 | { 55 | "@id": "_:6", 56 | "observedAt": "2015-01-01T01:01:00", 57 | "@graph": [{ 58 | "@id": "Paris", 59 | "hasTemp": 8.3 60 | }] 61 | }, 62 | { 63 | "@id": "_:7", 64 | "observedAt": "2015-01-01T01:02:00", 65 | "@graph": [{ 66 | "@id": "Berlin", 67 | "hasTemp": 12 68 | }] 69 | }, 70 | { 71 | "@id": "_:8", 72 | "observedAt": "2015-01-01T01:02:00", 73 | "@graph": [{ 74 | "@id": "Madrid", 75 | "hasTemp": 9 76 | }] 77 | }, 78 | { 79 | "@id": "_:9", 80 | "observedAt": "2015-01-01T01:02:00", 81 | "@graph": [{ 82 | "@id": "Paris", 83 | "hasTemp": 8.4 84 | }] 85 | }, 86 | { 87 | "@id": "_:10", 88 | "observedAt": "2015-01-01T01:03:00", 89 | "@graph": [{ 90 | "@id": "Berlin", 91 | "hasTemp": 11.5 92 | }] 93 | }, 94 | { 95 | "@id": "_:11", 96 | "observedAt": "2015-01-01T01:03:00", 97 | "@graph": [{ 98 | "@id": "Madrid", 99 | "hasTemp": 9 100 | }] 101 | }, 102 | { 103 | "@id": "_:12", 104 | "observedAt": "2015-01-01T01:03:00", 105 | "@graph": [{ 106 | "@id": "Paris", 107 | "hasTemp": 8.5 108 | }] 109 | }, 110 | { 111 | "@id": "_:13", 112 | "observedAt": "2015-01-01T01:04:00", 113 | "@graph": [{ 114 | "@id": "Berlin", 115 | "hasTemp": 11 116 | }] 117 | }, 118 | { 119 | "@id": "_:14", 120 | "observedAt": "2015-01-01T01:04:00", 121 | "@graph": [{ 122 | "@id": "Madrid", 123 | "hasTemp": 9 124 | }] 125 | }, 126 | { 127 | "@id": "_:15", 128 | "observedAt": "2015-01-01T01:04:00", 129 | "@graph": [{ 130 | "@id": "Paris", 131 | "hasTemp": 8.6 132 | }] 133 | }, 134 | { 135 | "@id": "_:16", 136 | "observedAt": "2015-01-01T01:05:00", 137 | "@graph": [{ 138 | "@id": "Berlin", 139 | "hasTemp": 10.5 140 | }] 141 | }, 142 | { 143 | "@id": "_:17", 144 | "observedAt": "2015-01-01T01:05:00", 145 | "@graph": [{ 146 | "@id": "Madrid", 147 | "hasTemp": 9 148 | }] 149 | }, 150 | { 151 | "@id": "_:18", 152 | "observedAt": "2015-01-01T01:05:00", 153 | "@graph": [{ 154 | "@id": "Paris", 155 | "hasTemp": 8.7 156 | }] 157 | }, 158 | { 159 | "@id": "_:19", 160 | "observedAt": "2015-01-01T01:06:00", 161 | "@graph": [{ 162 | "@id": "Berlin", 163 | "hasTemp": 10 164 | }] 165 | }, 166 | { 167 | "@id": "_:20", 168 | "observedAt": "2015-01-01T01:06:00", 169 | "@graph": [{ 170 | "@id": "Madrid", 171 | "hasTemp": 9 172 | }] 173 | }, 174 | { 175 | "@id": "_:21", 176 | "observedAt": "2015-01-01T01:06:00", 177 | "@graph": [{ 178 | "@id": "Paris", 179 | "hasTemp": 8.8 180 | }] 181 | }, 182 | { 183 | "@id": "_:22", 184 | "observedAt": "2015-01-01T01:07:00", 185 | "@graph": [{ 186 | "@id": "Madrid", 187 | "hasTemp": 9 188 | }] 189 | }, 190 | { 191 | "@id": "_:23", 192 | "observedAt": "2015-01-01T01:07:00", 193 | "@graph": [{ 194 | "@id": "Paris", 195 | "hasTemp": 8.9 196 | }] 197 | }, 198 | { 199 | "@id": "_:24", 200 | "observedAt": "2015-01-01T01:08:00", 201 | "@graph": [{ 202 | "@id": "Berlin", 203 | "hasTemp": 9 204 | }] 205 | }, 206 | { 207 | "@id": "_:25", 208 | "observedAt": "2015-01-01T01:08:00", 209 | "@graph": [{ 210 | "@id": "Madrid", 211 | "hasTemp": 9 212 | }] 213 | }, 214 | { 215 | "@id": "_:26", 216 | "observedAt": "2015-01-01T01:08:00", 217 | "@graph": [{ 218 | "@id": "Paris", 219 | "hasTemp": 9 220 | }] 221 | }, 222 | { 223 | "@id": "_:27", 224 | "observedAt": "2015-01-01T01:10:00", 225 | "@graph": [{ 226 | "@id": "Berlin", 227 | "hasTemp": 8.5 228 | }] 229 | }, 230 | { 231 | "@id": "_:28", 232 | "observedAt": "2015-01-01T01:10:00", 233 | "@graph": [{ 234 | "@id": "Madrid", 235 | "hasTemp": 9 236 | }] 237 | }, 238 | { 239 | "@id": "_:29", 240 | "observedAt": "2015-01-01T01:10:00", 241 | "@graph": [{ 242 | "@id": "Paris", 243 | "hasTemp": 9.1 244 | }] 245 | } 246 | ] 247 | } -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "{}" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright {yyyy} {name of copyright owner} 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | 203 | -------------------------------------------------------------------------------- /Semantics.md: -------------------------------------------------------------------------------- 1 | # RSP-QL Semantics 2 | 3 | ## RSP Data model 4 | 5 | ### Temporal entities 6 | Let T denote the set of temporal entities. This specification is neutral regarding the formal specification of temporal entities. 7 | 8 | #### Instants and Intervals 9 | Following the concepts of the Time Ontology (http://www.w3.org/TR/owl-time/), a temporal entity can be a time instant or a time interval. 10 | 11 | ### Timestamped graph 12 | A *timestamped graph* is defined as an RDF Dataset under the RDF Dataset semantics that [each graph defines its own context](http://www.w3.org/TR/2014/NOTE-rdf11-datasets-20140225/#each-named-graph-defines-its-own-context) with the following constraints. 13 | 14 | 1. There is a single named graph pair (n, g) in the RDF Dataset (where `g` is an [RDF graph](http://www.w3.org/TR/rdf11-concepts/#section-rdf-graph), and `n` is an IRI or blank node). 15 | 2. There is a ~~single~~ triple in the default graph of the RDF Dataset, and it has the form (n, p, t), where `n` is defined in the previous item, `p` is a predicate that captures the relationship between the temporal entity `t`, called the timestamp, and the graph `g`. 16 | 17 | Limitations of the definition: 18 | * does **not** allow the default graph of a timestamped graph to have more than triple. 19 | 20 | > **Discussion:** There could be multiple timestamps associated with a graph `g`, e.g. a start time and an end time, or a generated time and a system processing time. The predicate `p` should be drawn from a community agreed vocabulary ([Issue 10](https://github.com/streamreasoning/RSP-QL/issues/10)). 21 | 22 | > **Discussion:** More than one triple may be necessary to represent the time metadata for each graph. 23 | 24 | #### Example: 25 | The following timestamped graph `:g1` contains 2 triples that state that Darko and Axel are in the Red Room. The `p` predicate used in this example is the PROV ``prov:generatedAtTime`. In this example the named graph `:g1` contains the data contents (triples). The format in the example follows [TriG](http://www.w3.org/TR/trig/), although does not imply any specific serialization or formatting, it simply shows the data structured according to the RDF stream model. Prefixes (e.g. `prov:`) are used for readability. 26 | 27 | ``` 28 | :g1 {:axel :isIn :RedRoom. :darko :isIn :RedRoom} {:g1,prov:generatedAtTime,"2001-10-26T21:32:52"} 29 | ``` 30 | 31 | 32 | ### RDF Stream 33 | A *RDF stream* `S` consists of a sequence of timestamped graphs whose elements sharing the same predicate are ordered by the partial order associated with this predicate on the timestamps. 34 | 35 | **Order:** The partial order must respect the natural order of time. In particular, if every time instant within the closure of temporal entity `X` is earlier than every time instant within the closure of temporal entity `Y`, then `X <= Y` (where closure of a time instant `t` is defined as the degenerate interval `[t, t]`, and closure of an interval is defined in the usual way) 36 | 37 | Furthermore, the usual mathematical requirements of a partial order apply: 38 | 39 | - a) Reflexivity `X <= X` 40 | - b) Antisymmetry `X <= Y` and `Y <= X` implies `X = Y` 41 | - c) Transitivity `X <= Y` and `Y <= Z` implies `X <= Z`. 42 | 43 | On the following we may refer to RDF stream simply as stream. 44 | 45 | #### Example: 46 | A stream produces data that indicates where a person is at a given time. The `p` predicate used in this example is the PROV ``prov:generatedAtTime`. In this example the named graphs (`:g1`,`:g2`, etc.) contain the streaming data contents (for brevity the contents are represented by the dots `...`). 47 | 48 | ``` 49 | :g1 {...}{:g1,prov:generatedAtTime,t1} 50 | :g2 {...}{:g2,prov:generatedAtTime,t2} 51 | :g3 {...}{:g3,prov:generatedAtTime,t3} 52 | :g4 {...}{:g4,prov:generatedAtTime,t4} 53 | ... 54 | ``` 55 | 56 | We can expand the content of each named graph, which is a set of triples: 57 | 58 | ``` 59 | :g1 {:axel :isIn :RedRoom. :darko :isIn :RedRoom} {:g1,prov:generatedAtTime,t1} 60 | :g2 {:axel :isIn :BlueRoom. } {:g2,prov:generatedAtTime,t2} 61 | :g3 {:minh :isIn :RedRoom. } {:g3,prov:generatedAtTime,t3} 62 | ... 63 | ``` 64 | 65 | > **Discussion**: Given a certain `p`, elements on the stream having that predicate are ordered according to `t`. If the stream contains elements s1 and s2 associated with the same predicate, with s1 preceding s2, then it should not be the case that the timestamp of s1 is greater than the timestamp of s2. 66 | 67 | **Observation:** There can be multiple graphs with the same timestamp in the stream. 68 | > It has been pointed out that this statement might be problematic, as graphs cold no longer be used for punctuation purposes. Comparatively, we have not found a constraint on this in similar models e.g. CQL: *there could be zero, one, or multiple elements with the same timestamp in a stream*. To verify. 69 | 70 | 71 | ### Substream 72 | A *substream* (also known as window) `S'` of a stream `S` is a subsequence of `S`. 73 | 74 | 75 | #### Time-bounded Substream 76 | A *time-bounded substream* is defined by two time instances providing a lower bound `t_l` and an upper bound `t_u` where `t_l <= t_u`. A timestamped graph `(g_i,p_i,t_i)` is in the time-bounded substream if and only if `t_l <= t_i <= t_u`. 77 | 78 | #### Count-bounded Substream 79 | A *count-bounded substream* is defined by a time instance `t` and an integer value `n` that represents the number of timestamped graphs to include in the count-bounded substream. The count-bounded substream consists of the `n` timestamped graphs at or before time instance `t`. That is, a timestamped graph `(g_i,p_i,t_i)` is in the count-bounded substream if and only if there are less than or equal to `n` timestamped graphs between it and the time instance `t`. 80 | 81 | Note that a bounded substream maintains the timestamped graph contexts of the original stream. 82 | 83 | > See [Issue 11](https://github.com/streamreasoning/RSP-QL/issues/11). 84 | 85 | 86 | ### Stream Snapshot 87 | A *stream snapshot* consists of the union of all triples in a bounded substream. 88 | 89 | 90 | ## Stream Operators 91 | 92 | ### Window functions 93 | 94 | > Note: Window operator is reserved for later use to return time-varying graphs. Window functions work on a time instant. 95 | 96 | > Note: In the following, we take the case where temporal entities in the stream are time instants. 97 | 98 | > Open Issue: [Issue 18](https://github.com/streamreasoning/RSP-QL/issues/18) 99 | 100 | A *window function* wι of type ι takes as input a stream `S`, a predicate `p`, a time instant `t`, called the reference time point, and a vector of window parameters `x` for type ι and returns a substream `S'` of `S` that contains only timestamped graphs associated with `p` and timestamps valid at `t` according ι and `x`. 101 | 102 | The most common types of windows in practice are time-based and count-based. We associate them with the window functions wτ, w#, respectively. They take a fixed size ranging back in time from a reference time point `t`. These functions work as follows. 103 | 104 | #### Time-based window functions 105 | 106 | `x = (l,d)`, where `l ∈ N ∪ {∞}` and `d ∈ N`. The function wτ(S,p,t,x) returns the substream of S that contains all timestamped graphs associated with predicate `p` of the last `l` time units relative to a pivot time point `t'` derived from `t` and the step size `d` (Todo: MD: a figure to illustrate). We use `l = ∞` to take all previous timestamped graphs. 107 | 108 | Formally: 109 | 110 | wτ(S,p,t,(l,d)) = {((n,g),p,t1)∈ S ∣ t'-l < t1 ≤ t'}, 111 | 112 | where t'= ⌊t/d⌋ \cdot d 113 | 114 | #### Count-based window functions 115 | 116 | `x = (l)`, where `l ∈ N`. The function w#(S,p,t,x) selects a substream S1 of `S` based on the time instant `t'` satisfying that: 117 | * for every t' < t'' ≤ t, there are fewer than `l` timestamped graphs associated with predicate `p` in `S` from `t''` to `t`, 118 | * there are at least `l` timestamped graphs associated with predicate `p` in `S` from `t'` to `t`. 119 | 120 | Elements from S1 are those ((ni,gi),p,ti) from `S` having ti ≥ t'. In case there are more than `l` timestamped graphs associated with predicate `p` in `S` from `t'` to `t`, only timestamped graphs at `t'` are removed at random. 121 | 122 | Formally: 123 | 124 | w#(S,p,t,(l)) = {((n,g),p,t'') ∈ S ∣ t' < t'' ≤ t} ∪ X(S|p[t',t'], l - #S|p[t'+1,t]), 125 | 126 | where 127 | 128 | * S|p[t1,t2] = {((n,g),p,t'') ∈ S ∣ t1 ≤ t'' ≤ t2}, 129 | * #S|p[t1,t2] is the number of elements of this set, 130 | * `t'` satisfies that #S|p[t',t] ≥ l and #S|p[t'+1,t] < l 131 | 132 | 133 | ## RSP-QL Definition 134 | 135 | An *RSP-QL query* `Q` is a tuple `Q = (SE,SDS,QF)` where `SE` is an RSP-QL algebraic expression, 136 | `SDS` is an RSP-QL dataset and `QF` is the Query Form 137 | 138 | ### RSP-QL Dataset 139 | An *RSP-QL dataset* `SDS` is defined as the set of: a default graph `G_0`, n named graphs `G_i` and m named 140 | time-varying graphs obtained by the application of time-based sliding windows over `p` streams: 141 | ``` 142 | SDS ={G0, 143 | (u1,G1), . . . , (un,Gn), 144 | (w1,W1(S1)), . . . , (wj ,Wj(S1)), 145 | (wj+1,Wj+1(S2)), . . . , (wk,Wk(S2)), 146 | . . . 147 | (wl,Wl(Sp)), . . . , (wm,Wm(Sp))} 148 | ``` 149 | 150 | Notice that different windows can be applied to the same stream `Si` in the same SDS. 151 | 152 | 153 | #### Time-varying graphs 154 | A *time-varying graph* `G` is a function that relates time instants `t ∈ T` to RDF graphs: 155 | 156 | ``` 157 | G : T → {g | g is an RDF graph} 158 | ``` 159 | 160 | An *instantaneous RDF graph* `G(t)` is the RDF graph identified by the time-varying graph `G` at the given time instant `t`. 161 | 162 | ## RSP-QL Continuous Evaluation 163 | 164 | We extend the definition of SPARQL evaluation semantics to take into account the time dimension: we add a third parameter, evaluation time t, in the eval function signature. 165 | 166 | Given an RSP-QL dataset SDS, an algebraic expression SE and an evaluation time instant t, we define 167 | 168 | eval(SDS(G), SE, t) 169 | 170 | as the evaluation of SE at time t with respect to the RSP-QL dataset SDS having active timevarying graph G. 171 | This new concept requires a revision of the definitions of the existing SPARQL evaluation of algebraic operators. 172 | 173 | ## References: 174 | * EP-SPARQL: a unified language for event processing and stream reasoning. 175 | Anicic, D., Fodor, P., Rudolph, S., & Stojanovic, N. In WWW (p. 635-644). ACM. 2011. 176 | * C-SPARQL: a Continuous Query Language for RDF Data Streams. 177 | Barbieri, D. F., Braga, D., Ceri, S., Della Valle, E., & Grossniklaus, M. Int. J. Semantic Computing, 4(1), 3-25. 2010. 178 | * Enabling query technologies for the semantic sensor web. 179 | Calbimonte, J.-P., Jeung, H., Corcho, Ó., & Aberer, K. Int. J. Semantic Web Inf. Syst., 8(1), 43-63. 2012. 180 | * RSP-QL Semantics: a Unifying Query Model to Explain Heterogeneity of RDF Stream Processing Systems. 181 | D. Dell’Aglio, E. Della Valle, J.-P. Calbimonte, O. Corcho. Int. J. Semantic Web Inf. Syst, 10(4). (in press). 2015. 182 | * A Native and Adaptive Approach for Unified Processing of Linked Streams and Linked Data. 183 | Phuoc, D. L., Dao-Tran, M., Parreira, J. X., & Hauswirth, M.In ISWC (Vol. 7031, p. 370-388). Springer. 2011. 184 | * LARS: A Logic-based Framework for Analyzing Reasoning over Streams. 185 | Beck, H., Dao-Tran, M., Eiter, T., Fink, M. In AAAI. 2015. 186 | * RDF 1.1: On Semantics of RDF Datasets. Zimmerman, Antoine, ed.. 2014. http://www.w3.org/TR/2014/NOTE-rdf11-datasets-20140225. 187 | 188 | > this example could be integrated to the main text body 189 | > ### Beyond time instants: intervals & more 190 | > 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 `(g,p1,t1)` and `(g,p2,t2)` denote that g is defined in an interval [t1,t2]. As an example: 191 | > ```` 192 | :g_1, :startsAt, "2015-06-18T12:00:00"^^xsd:dateTime 193 | :g_1, :endsAt, "2015-06-18T13:00:00"^^xsd:dateTime 194 | ``` 195 | > Or even: 196 | ``` 197 | :g_2 :validBetween 198 | [:startsAt "2015-06-18T12:00:00"^^xsd:dateTime; 199 | :endsAt "2015-06-18T13:00:00"^^xsd:dateTime] 200 | ``` 201 | 202 | -------------------------------------------------------------------------------- /RSP-QL Sample Queries.md: -------------------------------------------------------------------------------- 1 | #RSP-QL Example Queries 2 | 3 | This query set is based on the data of the DEBS challenge 2015 (see [DEBS Challenge 2015 data] (https://github.com/streamreasoning/RSP-QL/blob/master/DEBS%20Challenge%202015%20data.md ) ) 4 | 5 | ## Data 6 | 7 | We have not agreed on a simple schema and structure of the streams (how many streams, and the contents of each one. For each contributing query please explain your data assumptions. 8 | 9 | ## Queries 10 | 11 | ### Query 1 12 | 13 | (added by jpc) 14 | 15 | This query simply shows the use of a sliding window in RSP-QL. It intends to get the number of taxi rides that exceeded 2 miles in the last hour. 16 | 17 | This is a simple example of the structure of a portion of the data as an RDF stream. The stream (http://debs2015.org/streams/trips) outputs a graph per ride when the user is dropped off. E.g. : 18 | 19 | ``` 20 | @prefix debs: . 21 | @prefix prov: . 22 | @prefix wgs84: . 23 | 24 | :t1 { 25 | :pickup1 prov:startedAtTime "2013-01-01T00:00:00"^^xsd:dateTime; 26 | prov:atLocation [wgs84:lat 40.716976; wgs84:long -73.956528]. 27 | :dropoff1 prov:startedAtTime "2013-01-01T00:10:00"^^xsd:dateTime; 28 | prov:atLocation [wgs84:lat 41.716976; wgs84:long -73.956528]. 29 | :trip1 debs:dropoff :dropoff1; 30 | debs:pickup :pickup1; 31 | debs:taxi :taxi25; 32 | debs:duration 35; 33 | debs:distance 1.5; 34 | debs:paymentType "CSH"; 35 | debs:fare 3.50; 36 | debs:surcharge 0.50; 37 | debs:tax 0.50; 38 | debs:tip 0.00; 39 | debs:tolls 0.00. 40 | } 41 | 42 | ``` 43 | 44 | The query: 45 | 46 | ``` 47 | PREFIX debs: 48 | prefix s: 49 | 50 | SELECT COUNT(?ride) as ?rideCount 51 | FROM NAMED WINDOW :wind ON s:trips [RANGE PT1H STEP PT1H] 52 | WHERE { 53 | WINDOW :win { 54 | ?ride debs:distance ?distance 55 | FILTER(?distance>2) 56 | }} 57 | ``` 58 | 59 | The data about taxis can be in a different stored graph: 60 | http://debs2015.org/data/taxis 61 | 62 | ``` 63 | @prefix debs: . 64 | 65 | :taxi3 debs:medallion "07290D3599E7A0D62097A346EFCC1FB5"; 66 | debs:license "E7750A37CAB07D0DFF0AF7E3573AC141". 67 | ``` 68 | 69 | About data units. they are not included in the data stream (although they could) but we could also specify them through class restrictions: 70 | 71 | ``` 72 | @prefix unit:. 73 | 74 | :Trip rdf:type owl:Class; 75 | rdfs:subClassOf [ rdf:type owl:Restriction ; 76 | owl:onProperty :distanceUnit ; 77 | owl:someValuesFrom [ rdf:type owl:Class ; 78 | owl:oneOf (unit:meter)] 79 | 80 | ``` 81 | 82 | ### Query 2 83 | (by Alessandra) 84 | 85 | 86 | The input stream contains fares and trip data described as in http://chriswhong.com/open-data/foil_nyc_taxi/ 87 | 88 | The first query generates a graph whenever more than 20 taxis have the same drop off location within 30 minutes. I thought I needed two windows to do that but I think that is not necessary. Would be interesting to change it to get the number of taxis that are arriving at a location and leaving that location within 30 min (e.g. to spot events or things happening or other patterns). I have used drop off location as the exact location, probably a notion of distance (e.g. within distance 3 from that location) would make more sense. 89 | 90 | ``` 91 | PREFIX debs: 92 | PREFIX s: 93 | 94 | REGISTER STREAM :query AS 95 | 96 | SELECT ?location (count(distinct ?taxi) as ?taxinumber 97 | FROM NAMED WINDOW :w1 ON s [RANGE PT1h step PT30M] 98 | WHERE { 99 | ?location a :dropoffLocation. 100 | WINDOW :w1 { 101 | ?taxi debs:dropoff ?location. 102 | } 103 | GROUPBY ?location 104 | HAVING (?taxinumber >= 20) 105 | } 106 | ``` 107 | 108 | ### Query 3 109 | (by Alessandra) 110 | 111 | The second query is a variation of the second query of the DEBS challenge. It uses subquery to generate the top 3 profitable pickup locations in the last 30 minutes. 112 | The highest profit is defined as the total amount of fares collected at a pick_up location in the last 30 minutes. I am not sure about subqueries like that, but aggregates in the WHERE of a CONSTRUCT wouldn't work I believe? 113 | 114 | ``` 115 | PREFIX debs: 116 | PREFIX s: 117 | 118 | REGISTER STREAM :query AS 119 | 120 | CONSTRUCT ISTREAM 121 | { 122 | ?location debs:profit ?totalamount 123 | } 124 | 125 | FROM NAMED WINDOW :w1 ON s [RANGE PT30M step PT15M] 126 | 127 | WHERE 128 | { 129 | { SELECT (SUM(?amount) AS ?totalamount) ?location 130 | { 131 | WINDOW :w1 132 | { 133 | ?taxi debs:pickup ?location 134 | ?location debs:amount ?amount 135 | } 136 | 137 | GROUP BY ?location 138 | ORDER BY desc(?totalamount) 139 | LIMIT 3 140 | 141 | } 142 | } 143 | ``` 144 | 145 | ### Query 4 146 | 147 | (by Bernhard) 148 | 149 | The data set that is used as a "RDF"ed version of http://www.debs2015.org/call-grand-challenge.html 150 | Temporal data is encoded in the W3C's Time Ontology and spatial data in OpenGIS' ontology. 151 | 152 | "Uber Ride of Glory Query" 153 | 154 | ``` 155 | PREFIX debs: 156 | PREFIX tstream: 157 | PREFIX time: 158 | PREFIX geodata: 159 | PREFIX geo: 160 | PREFIX geof: 161 | PREFIX wgs84: 162 | 163 | SELECT ?time ?district 164 | FROM NAMED WINDOW :wind ON tstream:rides [RANGE PT6H STEP PT6H] 165 | WHERE { 166 | WINDOW :wind { 167 | #Dropoff 168 | ?ride debs:dropoff_latitude ?lat; 169 | debs:dropoff_longitude ?lng; 170 | debs:dropoff_datetime ?time. 171 | ?time time:hour ?drop_hour. 172 | ?feature geo:hasGeometry ?dropGeom; 173 | wgs84:lat ?lat; 174 | wgs84:lng ?lng; 175 | geodata:district ?district. 176 | FILTER(?drop_hour < 4) 177 | FILTER(22 < ?drop_hour) 178 | } 179 | Window :wind { 180 | #Pickup 181 | ?ride debs:pickup_latitude ?lat; 182 | debs:pickup_longitude ?lng; 183 | debs:pickup_datetime ?time. 184 | ?time time:hour ?pick_hour. 185 | ?place geo:hasGeometry ?pickGeom; 186 | wgs84:lat ?lat; 187 | wgs84:lng ?lng; 188 | geodata:district ?district. 189 | FILTER(?pick_hour < 4) 190 | FILTER(22 < ?pick_hour) 191 | } 192 | #RoG drop off location has to differ max 0.1 from the first 193 | # has to differ at least for one hour 194 | FILTER (?pick_hour - ?drop_hour > 1) 195 | FILTER (geof:distance(?dropGeom, ?pickGeom, units:mile, 0.1)) 196 | } 197 | ``` 198 | 199 | 200 | ### Query 5 201 | (by Bernhard) 202 | 203 | Most profitable Trips 204 | 205 | ``` 206 | PREFIX debs: 207 | PREFIX tstream: 208 | 209 | SELECT ?distance (?amount - ?tax -?tips -?tolls) AS ?profit 210 | FROM NAMED WINDOW :wind ON tstream:rides [RANGE PT1H STEP PT1H] 211 | WHERE { 212 | WINDOW :wind { 213 | ?ride debs:trip_distance ?distance; 214 | debs:total_amount ?amount; 215 | debs:mta_tax ?tax; 216 | debs:tip_amount ?tips; 217 | debs:tolls_amount ?tolls. 218 | } 219 | } 220 | ``` 221 | 222 | ### Query 6 223 | (by Fariz) 224 | 225 | Lucky taxi rides (taxi rides that did not meet any red traffic light 226 | -- always get the green ones) in the last 1 hour 227 | 228 | Feature: Negation using NOT EXISTS 229 | 230 | Data: 231 | 232 | ``` 233 | @prefix debs: . 234 | @prefix ex: . 235 | 236 | { 237 | :ride1 debs:byTaxi :taxi1; 238 | debs:pickupAt "2013-01-01 00:00:00"; 239 | debs:dropoffAt "2013-01-01 00:02:00"; 240 | debs:distance 3; 241 | ex:stoppedAt :trafficLight1, :trafficLight2 } 242 | 243 | # :ride2 didn't meet any red traffic light 244 | { 245 | :ride2 debs:byTaxi :taxi2; 246 | debs:pickupAt "2013-01-01 00:00:00"; 247 | debs:dropoffAt "2013-01-01 00:03:00"; 248 | debs:distance 2 } 249 | ``` 250 | 251 | Query: 252 | 253 | ``` 254 | PREFIX debs: 255 | PREFIX s: 256 | PREFIX ex: 257 | 258 | SELECT ?luckyRide 259 | FROM NAMED WINDOW :win ON s:rides [RANGE PT1H STEP PT1H] 260 | WHERE { 261 | WINDOW :win { 262 | ?luckyRide debs:byTaxi ?taxi . 263 | FILTER NOT EXISTS {?luckyRide ex:stoppedAt ?trafficLight} 264 | }} 265 | ``` 266 | 267 | 268 | ### Query 7 269 | (by Peter) 270 | 271 | In which neighborhoods did pickups increase in the last hour compared to the previous hour? 272 | In other words: Where did demand for taxis rise in the last hour? Combining with static knowledge from geonames about neighbourhoods. 273 | 274 | Alternatives: 275 | In which neighborhoods did pickups decrease in the last hour compared to the previous hour? 276 | In which neighborhoods did dropoffs increase in the last hour compared to the previous hour? 277 | In which neighborhoods did dropoffss decrease in the last hour compared to the previous hour? 278 | 279 | Query: 280 | 281 | ``` 282 | PREFIX debs: 283 | PREFIX s: 284 | PREFIX gn: 285 | PREFIX ex: 286 | PREFIX geof: 287 | 288 | SELECT ?neighbourhood ( COUNT(?newPickups) / COUNT(?oldPickups) AS ?increase ) 289 | FROM NAMED WINDOW :newPickups ON s:rides [RANGE PT1H STEP PT1H] 290 | FROM NAMED WINDOW :oldPickups ON s:rides [FROM NOW-PT2H TO NOW-PT1H STEP PT1H] 291 | FROM GRAPH gn:geonames 292 | 293 | WHERE { 294 | ?oldPickups gn:neighbourhood ?neighbourhood 295 | ?newPickups gn:neighbourhood ?neighbourhood 296 | WINDOW :newPickups { 297 | ?newPickups debs:pickup_latitude ?nlat 298 | ?newPickups debs:pickup_longitude ?nlon 299 | } 300 | WINDOW :oldPickups { 301 | ?oldPickups debs:pickup_latitude ?olat 302 | ?oldPickups debs:pickup_longitude ?olon 303 | } 304 | FILTER ( ?increase >= 1.2 ) #increase by 20% 305 | 306 | } 307 | ``` 308 | 309 | ### Query 8 310 | (by Bernhard) 311 | 312 | New Query to reflect on the last discussed changes (combining static and streaming data) 313 | Find profitable spots to drive to (integration of GeoNames to get the street name of the drop spot) 314 | 315 | ``` 316 | PREFIX debs: 317 | PREFIX tstream: 318 | PREFIX ogc: 319 | PREFIX geom: 320 | PREFIX wgs84: 321 | PREFIX geonames: 322 | 323 | SELECT ?strName ?profit 324 | FROM 325 | WHERE { 326 | ?poi geonames:street ?strName; 327 | geom:geometry ?point. 328 | { 329 | #aggregate the profit per poi 330 | SELECT SUM(?total - ?tax - ?tips) ?as ?profit ?point 331 | FROM NAMED WINDOW :spot ON tstream: [RANGE PT6H STEP PT6H] 332 | WINDOW :spot { 333 | ?ride debs:fare_amount ?total; 334 | debs:mta_tax ?tax; 335 | debs:tip_amount ?tips. 336 | { 337 | # Data transformation (Lng,Lat) => geometry 338 | CONSTRUCT 339 | { 340 | ?ride ?point. 341 | ?point a geom:Geometry, geom:Point. 342 | ?point ogc:asWKT ?wktLit. 343 | ?point wgs84:lat ?lat. 344 | ?point wgs84:long ?lng. 345 | } 346 | WHERE { 347 | ?ride debs:dropoff_latitude ?dropLat; 348 | debs:dropoff_longitude ?dropLong; 349 | BIND(STRDT(?dropLat, xsd:double) AS ?lat) 350 | BIND(STRDT(?dropLong, xsd:double) AS ?lng) 351 | BIND(STRDT(CONCAT("POINT(",?dropLong," ",?dropLat,")"), ogc:wktLiteral) AS ?wktLit) 352 | } 353 | } 354 | GROUP BY ?point 355 | } 356 | } 357 | } 358 | ``` 359 | 360 | Other query examples (to be formulated): 361 | * Find profitable spots to drive to (combination with event data): Where is an event (ending) right now (get public event data) and where are not many pickups in the last 30min? 362 | * Merge taxi complaints (https://nycopendata.socrata.com/Social-Services/311-Service-Requests-from-2010-to-Present/erm2-nwe9) with trips: in which neighborhoods have there been most complaints divided by trips (complaint rate per trip) in the last hour? 363 | * Event detection: Many (increased) outgoing trips at same area in last 30min 364 | * Most efficient taxi driver = fastest pickup after dropoff in the last hour ~ shortest time empty 365 | * Least efficient taxi driver = slowest pickup after dropoff in the last hour ~ longest time empty 366 | * Empty taxis in a certain radius: how many taxis had a dropoff in the last 10 mins around my location? (option: dropoff, but not a new pickup) 367 | * Empty times: at which locations/cells did the longest time pass after dropoffs until a new pickup for the same taxi occurred? 368 | * What are the most used routes between neighborhoods? i.e. taxi routes from district a to district b? 369 | * Detect traffic congestion: comparing 2 windows, speed of trips in area has decreased... 370 | * Where does most tipping occur? 371 | * Where are most taxis empty currently? 372 | * Patterns? can we capture if one user goes from A to B, then after some time from B to C, etc.? 373 | * Can we combine taxi availability data with real-time public transport data to determine whether taking a taxi or a public bus for a given ride right now? 374 | -------------------------------------------------------------------------------- /Serialization.md: -------------------------------------------------------------------------------- 1 | ## Serialization 2 | The definition above describes an **abstract** data model for a timestamped graph because it is based on an RDF Dataset, which is an abstract entity. The serialization of such timestamped graphs is an additional issue. A timestamped graph *could* be serialized in an existing format for RDF Datasets, e.g. [Trig](http://www.w3.org/TR/2014/REC-trig-20140225/). However, the Trig syntax does not provide abbreviations for the special cases that arise for a timestamped graph. Therefore, we must introduce a new concrete syntax for timestamped graphs. There are several syntactic categories. 3 | #### 'n' is a blank node. 4 | The intention is that this blank node will not be shared with any other RDF graphs or RDF Datasets. Therefore, it can be represented implicitly, meaning processors will generate a new blank node for each timestamped graph they receive. As an illustration, the serialization could take the form of a space-separated tuple surrounded by parentheses: (g p t). For example, a serialization of a timestamped graph containing two triples would appear as follows 5 | ``` 6 | ( 7 | { 8 | _:b foaf:name "Alice" . 9 | _:b foaf:mbox . 10 | } 11 | 12 | "2012-11-02T19:14:23+01:00"^^xsd:dateTime 13 | ) 14 | ``` 15 | When we say "a timestamped graph contains two triples", that is shorthand for "a timestamped graph whose named graph contains two triples" 16 | This syntax could potentially be abbreviated further by making some assumptions, e.g. 17 | * the predicate is always an absolute IRI 18 | * the timestamp is by default of datatype xsd:dateTime 19 | With these assumptions, most of the delimiting characters become unnecessary, and the timestamped graph could be serialized so: 20 | ``` 21 | ( 22 | { 23 | _:b foaf:name "Alice" . 24 | _:b foaf:mbox . 25 | } 26 | http://streamreasoning.org/timeVocab#startsAtTime 27 | 2012-11-02T19:14:23+01:00 28 | ) 29 | ``` 30 | #### 'n' is an IRI and the named graph is included explicitly. 31 | As an illustration, the serialization could take the form of a space-separated qudruple surrounded by parentheses: (n g p t). For example: 32 | ``` 33 | ( 34 | 35 | { 36 | _:b foaf:name "Alice" . 37 | _:b foaf:mbox . 38 | } 39 | 40 | "2012-11-02T19:14:23+01:00"^^xsd:dateTime 41 | ) 42 | ``` 43 | This could potentially be abbreviated further by making some assumptions in addition to those from the previous case, e.g. 44 | * the name of the named graph is always an absolute IRI 45 | With these assumptions, most of the delimiting characters become unnecessary, and the timestamped graph could be serialized so: 46 | ``` 47 | ( 48 | http://example.org/alice 49 | { 50 | _:b foaf:name "Alice" . 51 | _:b foaf:mbox . 52 | } 53 | http://streamreasoning.org/timeVocab#startsAtTime 54 | 2012-11-02T19:14:23+01:00 55 | ) 56 | ``` 57 | 58 | #### 'n' is an IRI and the named graph is obtained by dereferencing that IRI. 59 | As an illustration, the serialization could take the form of a space-separated tuple surrounded by parentheses: (n p t). For example: 60 | ``` 61 | ( 62 | 63 | 64 | "2012-11-02T19:14:23+01:00"^^xsd:dateTime 65 | ) 66 | ``` 67 | This could potentially be abbreviated further by making the assumptions as in the previous cases. 68 | With these assumptions, most of the delimiting characters become unnecessary, and the timestamped graph could be serialized so: 69 | ``` 70 | ( 71 | http://example.org/alice 72 | http://streamreasoning.org/timeVocab#startsAtTime 73 | 2012-11-02T19:14:23+01:00 74 | ) 75 | ``` 76 | Although there may be further abbreviations possible for these special cases, it is also desirable to be able to extend this syntax to additional cases. For example, consider situations where 77 | * the timestamp is not in the xsd:dateTime datatype. In this case the full form for a literal could be used, "2012-11-02"^^xsd:date 78 | * the timestamp is complex, e.g. an interval. In this case, a [nested unlabelled blank node](http://www.w3.org/TR/2014/REC-turtle-20140225/#unlabeled-bnodes) could be used. 79 | * the same named graph is referenced by more than one timestamping triple, with timestamps corresponding to different events. In this case a larger tuple, e.g. (g p1 t1 p2 t2) could be used. 80 | 81 | Further abbreviations may be considered after a broader range of extensions has been examined. 82 | 83 | Note that each of the concrete examples above describes an RDF Dataset - there is a uniform abstract data model for timestamped graphs, independent of the form taken in the concrete syntax. 84 | 85 | ## JSON-LD Serialization 86 | 87 | This section describes a potential [JSON-LD](http://www.w3.org/TR/json-ld/) serialization for timestamped graphs. We will exemplify the syntax on the following graphs: 88 | 89 | G1: ****: 90 | * Generated: 2015-01-15 91 | * Recorded: 2015-01-17 92 | ``` 93 | . 94 | "http://example.org/person/Alasdair" . 95 | "http://example.org/person/Tara" . 96 | "Jean Paul Calbimonte" . 97 | 98 | . 99 | "http://example.org/person/Tara" . 100 | "Alasdair Gray" . 101 | ``` 102 | 103 | G2:****: 104 | * Generated: 2015-01-16 105 | * Recorded: 2015-01-17 106 | ``` 107 | . 108 | "http://example.org/person/Alasdair" .. 109 | "Tara Athan" . 110 | ``` 111 | 112 | ### Graphs are exchanged in 'independent' files/streams 113 | 114 | In this case, each graph is a [JSON object](http://www.w3.org/TR/json-ld/#dfn-json-object). Each file can define its own [context](http://www.w3.org/TR/json-ld/#the-context) (shortcuts). 115 | 116 | G1: 117 | ``` 118 | { 119 | "@context": { 120 | "generatedAt": { 121 | "@id": "http://www.w3.org/ns/prov#generatedAtTime", 122 | "@type": "http://www.w3.org/2001/XMLSchema#date" 123 | }, 124 | "recordedAt": { 125 | "@id": "http://www.w3.org/ns/prov#recordedAt", 126 | "@type": "http://www.w3.org/2001/XMLSchema#date" 127 | }, 128 | "Person": "http://xmlns.com/foaf/0.1/Person", 129 | "name": "http://xmlns.com/foaf/0.1/name", 130 | "knows": "http://xmlns.com/foaf/0.1/knows" 131 | }, 132 | "@id": "http://example.org/graphs/1", 133 | "generatedAt": "2015-01-15", 134 | "recordedAt": "2015-01-17", 135 | "@graph": 136 | [ 137 | { 138 | "@id": "http://example.org/person/Jean-Paul", 139 | "@type": "Person", 140 | "name": "Jean Paul Calbimonte", 141 | "knows": ["http://example.org/person/Alasdair","http://example.org/person/Tara"] 142 | }, 143 | { 144 | "@id": "http://http://example.org/person/Alisdair", 145 | "@type": "Person", 146 | "name": "Alasdair Gray", 147 | "knows": "http://example.org/person/Tara" 148 | } 149 | ] 150 | } 151 | ``` 152 | See in [JSON-LD playground](http://tinyurl.com/pe5dp8f) 153 | 154 | G2: 155 | ``` 156 | { 157 | "@context": { 158 | "generatedAt": { 159 | "@id": "http://www.w3.org/ns/prov#generatedAtTime", 160 | "@type": "http://www.w3.org/2001/XMLSchema#date" 161 | }, 162 | "recordedAt": { 163 | "@id": "http://www.w3.org/ns/prov#recordedAt", 164 | "@type": "http://www.w3.org/2001/XMLSchema#date" 165 | }, 166 | "Person": "http://xmlns.com/foaf/0.1/Person", 167 | "name": "http://xmlns.com/foaf/0.1/name", 168 | "knows": "http://xmlns.com/foaf/0.1/knows" 169 | }, 170 | "@id": "http://example.org/graphs/2", 171 | "generatedAt": "2015-01-16", 172 | "recordedAt": "2015-01-17", 173 | "@graph": 174 | [ 175 | { 176 | "@id": "http://example.org/person/Tara", 177 | "@type": "Person", 178 | "name": "Tara Athan", 179 | "knows": "http://example.org/person/Alisdair" 180 | } 181 | ] 182 | } 183 | ``` 184 | See in [JSON-LD playground](http://tinyurl.com/p3zyu5n) 185 | 186 | ### Graphs are exchanged in the same file/stream 187 | 188 | In this case, several graphs are aggregated in the same file or stream. In such case we could use a shared context to reuse shortcuts between different graphs, and also define 'internal' contexts so that specific shortcuts are defined for a graph. 189 | 190 | #### Array of @graph keywords with shared context 191 | 192 | All graphs are expressed in an array inside the default graph. The [context](http://www.w3.org/TR/json-ld/#the-context) (shortcuts) defined in the default graphcan be reused by all graphs. 193 | ``` 194 | { 195 | "@context": { 196 | "generatedAt": { 197 | "@id": "http://www.w3.org/ns/prov#generatedAtTime", 198 | "@type": "http://www.w3.org/2001/XMLSchema#date" 199 | }, 200 | "recordedAt": { 201 | "@id": "http://www.w3.org/ns/prov#recordedAt", 202 | "@type": "http://www.w3.org/2001/XMLSchema#date" 203 | }, 204 | "Person": "http://xmlns.com/foaf/0.1/Person", 205 | "name": "http://xmlns.com/foaf/0.1/name", 206 | "knows": "http://xmlns.com/foaf/0.1/knows" 207 | }, 208 | "@graph": 209 | [ 210 | { 211 | "@id": "http://example.org/graphs/1", 212 | "generatedAt": "2015-01-15", 213 | "recordedAt": "2015-01-17", 214 | "@graph": 215 | [ 216 | { 217 | "@id": "http://example.org/person/Jean-Paul", 218 | "@type": "Person", 219 | "name": "Jean Paul Calbimonte", 220 | "knows": ["http://example.org/person/Alasdair","http://example.org/person/Tara"] 221 | }, 222 | { 223 | "@id": "http://http://example.org/person/Alisdair", 224 | "@type": "Person", 225 | "name": "Alasdair Gray", 226 | "knows": "http://example.org/person/Tara" 227 | } 228 | ] 229 | }, 230 | { 231 | "@id": "http://example.org/graphs/2", 232 | "generatedAt": "2015-01-16", 233 | "recordedAt": "2015-01-17", 234 | "@graph": 235 | [ 236 | { 237 | "@id": "http://example.org/person/Tara", 238 | "@type": "Person", 239 | "name": "Tara Athan", 240 | "knows": "http://example.org/person/Alasdair" 241 | } 242 | ] 243 | } 244 | ] 245 | } 246 | ``` 247 | See in [JSON-LD playground](http://tinyurl.com/o877ky6) 248 | 249 | #### Mixing shared and 'internal' contexts 250 | 251 | Besides the shared context, each graph can define own its own context. Duplicate context terms are overridden using a most-recently-defined-wins mechanism. In the following example, we have defined an "example" prefix ( "example": "http://example.org/person/") just for the second graph. 252 | 253 | ``` 254 | { 255 | "@context": { 256 | "generatedAt": { 257 | "@id": "http://www.w3.org/ns/prov#generatedAtTime", 258 | "@type": "http://www.w3.org/2001/XMLSchema#date" 259 | }, 260 | "recordedAt": { 261 | "@id": "http://www.w3.org/ns/prov#recordedAt", 262 | "@type": "http://www.w3.org/2001/XMLSchema#date" 263 | }, 264 | "Person": "http://xmlns.com/foaf/0.1/Person", 265 | "name": "http://xmlns.com/foaf/0.1/name", 266 | "knows": "http://xmlns.com/foaf/0.1/knows" 267 | }, 268 | "@graph": 269 | [ 270 | { 271 | "@id": "http://example.org/graphs/1", 272 | "generatedAt": "2015-01-15", 273 | "recordedAt": "2015-01-17", 274 | "@graph": 275 | [ 276 | { 277 | "@id": "http://example.org/person/Jean-Paul", 278 | "@type": "Person", 279 | "name": "Jean Paul Calbimonte", 280 | "knows": ["http://example.org/person/Alasdair","http://example.org/person/Tara"] 281 | }, 282 | { 283 | "@id": "http://http://example.org/person/Alisdair", 284 | "@type": "Person", 285 | "name": "Alasdair Gray", 286 | "knows": "http://example.org/person/Tara" 287 | } 288 | ] 289 | }, 290 | { 291 | "@id": "http://example.org/graphs/2", 292 | "generatedAt": "2015-01-16", 293 | "recordedAt": "2015-01-17", 294 | "@graph": 295 | [ 296 | { 297 | "@context": { 298 | "example": "http://example.org/person/" 299 | }, 300 | "@id": "example:Tara", 301 | "@type": "Person", 302 | "name": "Tara Athan", 303 | "knows": { 304 | "@id": "example:Alisdair" 305 | } 306 | 307 | } 308 | ] 309 | } 310 | ] 311 | } 312 | ``` 313 | See in [JSON-LD playground](http://tinyurl.com/pbcez6j) 314 | 315 | #### Array of @graph keywords with NO shared context 316 | 317 | All graphs are expressed in an array with no shared [context](http://www.w3.org/TR/json-ld/#the-context). 318 | ``` 319 | [ 320 | { 321 | "@context": { 322 | "generatedAt": { 323 | "@id": "http://www.w3.org/ns/prov#generatedAtTime", 324 | "@type": "http://www.w3.org/2001/XMLSchema#date" 325 | }, 326 | "recordedAt": { 327 | "@id": "http://www.w3.org/ns/prov#recordedAt", 328 | "@type": "http://www.w3.org/2001/XMLSchema#date" 329 | }, 330 | "Person": "http://xmlns.com/foaf/0.1/Person", 331 | "name": "http://xmlns.com/foaf/0.1/name", 332 | "knows": "http://xmlns.com/foaf/0.1/knows" 333 | }, 334 | "@id": "http://example.org/graphs/1", 335 | "generatedAt": "2015-01-15", 336 | "recordedAt": "2015-01-17", 337 | "@graph": 338 | [ 339 | { 340 | "@id": "http://example.org/person/Jean-Paul", 341 | "@type": "Person", 342 | "name": "Jean Paul Calbimonte", 343 | "knows": ["http://example.org/person/Alasdair","http://example.org/person/Tara"] 344 | }, 345 | { 346 | "@id": "http://http://example.org/person/Alisdair", 347 | "@type": "Person", 348 | "name": "Alasdair Gray", 349 | "knows": "http://example.org/person/Tara" 350 | } 351 | ] 352 | }, 353 | { 354 | "@context": { 355 | "generatedAt": { 356 | "@id": "http://www.w3.org/ns/prov#generatedAtTime", 357 | "@type": "http://www.w3.org/2001/XMLSchema#date" 358 | }, 359 | "recordedAt": { 360 | "@id": "http://www.w3.org/ns/prov#recordedAt", 361 | "@type": "http://www.w3.org/2001/XMLSchema#date" 362 | }, 363 | "Person": "http://xmlns.com/foaf/0.1/Person", 364 | "name": "http://xmlns.com/foaf/0.1/name", 365 | "knows": "http://xmlns.com/foaf/0.1/knows" 366 | }, 367 | "@id": "http://example.org/graphs/2", 368 | "generatedAt": "2015-01-16", 369 | "recordedAt": "2015-01-17", 370 | "@graph": 371 | [ 372 | { 373 | "@id": "http://example.org/person/Tara", 374 | "@type": "Person", 375 | "name": "Tara Athan", 376 | "knows": "http://example.org/person/Alisdair" 377 | } 378 | ] 379 | } 380 | ] 381 | ``` 382 | See in [JSON-LD playground](http://tinyurl.com/ogh7sve) 383 | 384 | ### Graph 'n' is a blank node 385 | 386 | Regardless of wheter graphs are exchanged in the same file/stream or not, the graph name can be a blank node by ommiting the "@id" keyword in the graph definition. The following example shows this feature in the case of aggregating both graphs in a file/stream: 387 | 388 | ``` 389 | 390 | "@context": { 391 | "generatedAt": { 392 | "@id": "http://www.w3.org/ns/prov#generatedAtTime", 393 | "@type": "http://www.w3.org/2001/XMLSchema#date" 394 | }, 395 | "recordedAt": { 396 | "@id": "http://www.w3.org/ns/prov#recordedAt", 397 | "@type": "http://www.w3.org/2001/XMLSchema#date" 398 | }, 399 | "Person": "http://xmlns.com/foaf/0.1/Person", 400 | "name": "http://xmlns.com/foaf/0.1/name", 401 | "knows": "http://xmlns.com/foaf/0.1/knows" 402 | }, 403 | "@graph": 404 | [ 405 | { 406 | "generatedAt": "2015-01-15", 407 | "recordedAt": "2015-01-17", 408 | "@graph": 409 | [ 410 | { 411 | "@id": "http://example.org/person/Jean-Paul", 412 | "@type": "Person", 413 | "name": "Jean Paul Calbimonte", 414 | "knows": ["http://example.org/person/Alasdair","http://example.org/person/Tara"] 415 | }, 416 | { 417 | "@id": "http://http://example.org/person/Alisdair", 418 | "@type": "Person", 419 | "name": "Alasdair Gray", 420 | "knows": "http://example.org/person/Tara" 421 | } 422 | ] 423 | }, 424 | { 425 | "generatedAt": "2015-01-16", 426 | "recordedAt": "2015-01-17", 427 | "@graph": 428 | [ 429 | { 430 | "@id": "http://example.org/person/Tara", 431 | "@type": "Person", 432 | "name": "Tara Athan", 433 | "knows": "http://http://example.org/person/Alisdair" 434 | } 435 | ] 436 | } 437 | ] 438 | } 439 | ``` 440 | See in [JSON-LD playground](http://tinyurl.com/nbx6zql) 441 | 442 | 443 | -------------------------------------------------------------------------------- /Abstract Syntax and Semantics Document/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | RDF Stream Abstract Syntax and Semantics 5 | 6 | 7 | 133 | 150 | 151 | 152 | 153 |
154 | 155 |
156 |

The specification is intended for discussion within the RDF Stream Processing Community 157 | Group. Its content does not yet represent the consensus of the Community Group.

158 |

This specification is incomplete.

159 |
160 | 161 |
162 |

Introduction

163 | 164 |
165 | 166 |
167 |

RSP Data model

168 |
169 |

Namespaces and Prefixes

170 |

The metamodel for the abstract syntax of RDF streams is defined in the namespace http://www.w3.org/ns/rsp# 171 | and we use the prefix rsp for this namespace. Additional prefixes used in this document are the following: 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 |
Table 1: Prefix and Namespaces used in this specification
prefixnamespace IRI definition
rsphttp://www.w3.org/ns/rsp#The RSP rnamespace
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#The RDF namespace [[!RDF-SCHEMA]]
rdfshttp://www.w3.org/2000/01/rdf-schema#The RDFS namespace [[!RDF-SCHEMA]]
xsdhttp://www.w3.org/2000/10/XMLSchema#XML Schema Namespace [[!XMLSCHEMA11-2]]
owlhttp://www.w3.org/2002/07/owl#The OWL namespace [[!OWL2-OVERVIEW]]
owl-timehttp://www.w3.org/2006/time#The OWL-TIME namespace [[OWL-TIME]]
provhttp://www.w3.org/ns/prov#The PROV namespace [[!PROV-DM]]
dulhttp://www.ontologydesignpatterns.org/ont/dul/DUL.owl#The DOLCE+DnS Ultralet namespace (http://lov.okfn.org/dataset/lov/vocabs/dul) [[DUL]]
(others)(various)All other namespace prefixes are used in examples only.
In particular, IRIs starting with "http://example.com" represent
some application-dependent IRI [[!IRI]]
198 |
199 |
200 |
201 |

Temporal Entities and Timestamp Predicates

202 |
203 |

Class of Temporal Entities

204 |

Let Tall denote the class of all temporal entities. This specification is 205 | neutral regarding the formal specification of temporal entities.

206 |

We provide an identifier, rsp:TemporalEntity, for the rdfs:Class of all 207 | temporal entities.

208 |
Instants and Intervals
209 |

The following material needs attention from an individual who has 210 | reviewed the literature regarding temporal ontologies, including but not limited to 211 | http://www.omg.org/spec/DTV/1.0/ http://www.ihmc.us/users/phayes/docs/timeCatalog.pdf 212 | http://protege.cim3.net/cgi-bin/wiki.pl?SWRLTemporalOntology 213 | http://dl.acm.org/citation.cfm?id=1741341 214 | http://stl.mie.utoronto.ca/publications/psl-chapter.pdf 215 | There is more detail in https://github.com/streamreasoning/RSP-QL/issues/25

216 |

An instant is an instantaneous point of time on underlying axis and is isomorphic to 217 | numbers. Henceforth a time interval is the interval between two instants. A 218 | semi-infinite time interval is an interval where one instant is set to infinite. 219 | Furthermore if both instants are set to infinite, we call the interval bi-infinite. As a 220 | consequence a temporal entity is an entity associated with an instant or a time 221 | interval[Dyreson94,Allen83].

222 |

Add a out of scope section

223 |

Add Stream Profiles and Hierarchies, e.g., combined_time, timepoints, 224 | periods, approximate_point, interval_meeting, owltime_instants and owltime_interval

225 | 231 |
232 |
233 |

Timestamp Predicates

234 |

An RSP timestamp predicate P is an rdf:Property with range rsp:TemporalEntity that is 235 | associated, through the rdf:Property rsp:hasTimePlenum, with a unique partially-ordered set (poset) of 236 | temporal entities TP ⊆ Tall, called the time plenum of the predicate. 237 | The time plenum is associated, through the rdf:Property rsp:hasPartialOrder, 238 | with a unique partial order ≤P that is in the class 239 | rsp:ChronologicalPartialOrder.

240 |

The usual mathematical requirements of a partial order MUST be satisfied by an instance of 241 | rsp:ChronologicalPartialOrder. In particular, for all instances X, Y, Z 242 | of the time plenum, the following properties hold: 243 |

244 |
245 |
Reflexivity
246 |
X ≤P X
247 |
Antisymmetry
248 |
X ≤P Y and Y ≤P X implies X = 249 | Y
250 |
Transitivity
251 |
X ≤P Y and Y ≤P Z implies X ≤P 252 | Z.
253 |
254 |

Further, an instance of rsp:ChronologicalPartialOrder MUST respect the natural order of time.

255 |

In 256 | particular, if every time instant within the closure of temporal entity X 257 | is earlier than every time instant within the closure of temporal entity Y, 258 | then X ≤P Y (where closure of a time instant t is defined as 259 | the degenerate interval [t, t], and closure of an interval is defined in 260 | the usual way)

261 |

The above definition regarding natural order of time depends on the 262 | concept of time instant as the primitive of temporal entities that is universal amoung 263 | temporal ontologies and has a particular chronological order associated with them. 264 | However, not all temporal 265 | ontologies have time instants as their primitives, e.g., OMG. 266 | Further, branching temporal ontologies have a different set of time primitives than linear ones. 267 | So this needs to be fixed. 268 |

269 |
270 |
271 |
272 |

Timestamped Graphs

273 |

A timestamped graph is defined as an RDF Dataset under the RDF Dataset semantics 274 | that "each named graph defines its own context" (see ) and 277 | where a particular triple in the default graph has been designated as the timestamp 278 | triple, with the following constraints:

279 |
    280 |
  1. There is exactly one named graph pair <n, G> in the RDF Dataset (where 281 | G is an RDF graph, and n is an IRI or blank node).
    2. 283 |
  2. The timestamp triple has the form <n, p, t>, where n is 284 | defined in the previous item, and p is a timestamp predicate that captures 285 | the relationship between the temporal entity t, called the timestamp, and 286 | the graph G.
    3. 287 |
288 |

There may be multiple triples in the default graph, including multiple 289 | triples using timestamp predicates, but exactly one triple must be designated as the 290 | timestamp triple. The objects of any triples that use a timestamp predicate but are not the 291 | timestamp triple of the timestamped graph are not called timestamps.

292 |

Due to the assertion of the timestamp triple, the context referred to in 293 | "each named graph defines its own context" has a temporal aspect to it. Other aspects of 294 | this context may be asserted by additional triples in the default graph of the timestamped 295 | graph. Such triples are not required to have timestamp predicates, and thus may be about 296 | non-temporal aspects of the context, e.g., the authority or the sensor device. That is, we 297 | require the context to have a temporal aspect to it, but the context is not limited to 298 | temporal aspects. Thus, it would be misleading to call it a "temporal context".

299 |

The part of the definition above that points to RDF Dataset semantics 300 | really belongs in the semantics section, not in this definition, which should be purely 301 | syntax. We need additional informative text that gives the motivation for these 302 | definitions.

303 |

This definition does not permit the timestamp to be omitted, which is one 304 | of the data structures that is considered to be in-scope by the requirements document.

305 |

A sequence of RDF graphs (or named graphs, or RDF datasets) MAY be physically received 306 | by an RSP engine, which MAY then create an RDF stream from it by adding timestamps, e.g. 307 | indicating the time of arrival. The original sequence is not itself an RDF stream.

308 |

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

312 |

A literal-timestamped graph is a timestamped graph whose timestamp 313 | t is an rdfs:Literal.

314 |

Merge and union of RDF streams with non-literal-timestamped graphs may not 315 | be defined. See .

316 |

The timestamp predicate p may be drawn from a community 317 | agreed vocabulary (Issue 318 | 10). The timestamp predicate may also be user-defined.

319 |

The format in the examples of this document follows TriG, although does not imply any specific serialization or formatting; it simply 321 | shows the data structured according to the RDF stream model. When the default graph of a 322 | timestamped graph contains only one triple, this must be the timestamp triple, so there is 323 | no need of an additional format to designate it. In examples of timestamped graphs having 324 | more than one triple in the default graph, the first triple of the default graph to occur 325 | in the serialization is assumed to be the timestamp triple. Prefixes (e.g. 326 | prov:, dul:) are used for readability; their expansions are defined in 327 | Table 1.

328 |

A non-normative subsection should be created to hold all the information 329 | about the formatting of examples, and there the expansion of all prefixes that are used in 330 | examples can be defined.

331 | 347 |

According to the semantics defined in , the 348 | assertion of the named graph pair means that the graph denoted by :g entails 349 | the two triples :axel :isIn :RedRoom and :darko :isIn :RedRoom, 350 | under whatever entailment regime is being considered. It does not assert those triples 351 | directly, nor does it assert that these triples are actually in that graph. Further, it 352 | does not rule out additional entailments of :g. These details are best 353 | explained in the semantics section itself, although it would probably be helpful to have 354 | some informative explanation near the beginning to avoid confusion.

355 | 375 |

Given any two timestamped graphs, TSG1 and TSG2, we say that 376 | TSG2 377 | covers 378 | TSG1 (denoted TSG1 ≲ TSG2) if and only if TSG1 379 | and TSG2 have the same timestamp predicate P and the timestamps, 380 | t1 and t2 resp., satisfy t1 ≤P t2, 381 | where ≤P is the temporal partial order associated with the time plenum 382 | of the timestamp predicate P.

383 |

The relation ≲ between timestamped graphs is a preorder (a 384 | reflexive, transitive binary relation). It is not a partial order because it doesn't have 385 | the antisymmetry property (a≲ b and b≲ a implies a 386 | = b.)

387 | 392 |
393 |
394 |

RDF Stream

395 |

An RDF stream 396 | S consists of a sequence of timestamped graphs, called its elements, such that 397 | elements sharing the same 398 | timestamp predicate are ordered by the partial order associated with this timestamp predicate. 399 | I.e., if a stream S contains elements S(i) and S(j) 400 | with i < j and S(i) covers S(j), then the 401 | timestamps of S(i) and S(j) are equal.

402 |

If a timestamp predicate occurs in the timestamp triple of an element of an RDF stream, we say 403 | it is a timestamp predicate of the stream.

404 |

Time-boundedness properties on RDF streams behave better if it is required 405 | that the set of temporal entities for each timestamp predicate is pairwise bounded. I.e., 406 | for each pair of temporal entities in the set, there is a temporal entity in the set that is 407 | an upper bound of both, as well as a temporal entity in the set that is a lower bound of 408 | both. This property is not satisfied by branching temporal structures, but could be a 409 | requirement of some profile.

410 |

The comparability between any pair of elements of an RDF stream must (or should?) be 411 | completely determined from the default graphs of those elements, or elements that precede at least one of them. 412 | Otherwise the ordering could 413 | be revealed by a subsequent element, inducing retroactively an ordering requirement on 414 | a previous pair of stream elements.

415 |

On the following we may refer to RDF stream simply as stream.

416 | 439 |

There can be multiple graphs with the same timestamp in the stream.

440 |

It has been pointed out that this statement might be problematic, as graphs 441 | could no longer be used for punctuation purposes. Comparatively, we have not found a 442 | constraint on this in similar models e.g., CQL: there could be zero, one, or multiple 443 | elements with the same timestamp in a stream.

444 |
445 |
446 |

Isomorphism

447 |

Two RDF timestamped graphs TSG1 and TSG2 are isomorphic if and only if there is 448 | a bijection M between the nodes, triples, graphs and named graphs in TSG1 and those in 449 | TSG2 such that:

    450 |
  1. M maps blank nodes to blank nodes;
    2. 451 |
  2. M is the identity map on literals and IRIs;
    3. 452 |
  3. For every triple <s p o>, M(<s, p, o>)= <M(s), M(p), M(o)>;
    4. 453 |
  4. For every graph G={t1, ..., tn}, M(G)={M(t1), ..., M(tn)};
    5. 454 |
  5. For every named graph NG=<n, G>, M(NG)=<M(n), M(G)>;
    6. 455 |
  6. M(NG1)=NG2, M(DG1)=DG2, and M(TST1)=TST2, where NG1 is the named graph of TSG1, DG1 456 | is the default graph of TSG1, TST1 is the timestamp triple of TSG1, and similarly for 457 | TSG2.
    7. 458 |
459 |

460 |

The definition of timestamped graphs allows blank nodes to be used as graph 461 | names, as well as within triples.

462 | 
 463 | :_1 {...} {:_1, prov:generatedAtTime, t1}
 464 | 
 465 | 
 466 | :_2 {...} {:_2, prov:generatedAtTime, t1}
 467 | 
 468 |       
 469 |
470 |

Two RDF streams are S-isomorphic if and only if they have the same set of 471 | elements.

472 | 
 473 | 
 474 | :g1 {...} {:g1, prov:generatedAtTime, t1}
 475 | :g2 {...} {:g2, prov:generatedAtTime, t2}
 476 | :g3 {...} {:g3, prov:generatedAtTime, t2}
 477 | :g4 {...} {:g4, prov:generatedAtTime, t3}
 478 | 
 479 | 
 480 | 
 481 | :g1 {...} {:g1, prov:generatedAtTime, t1}
 482 | :g3 {...} {:g3, prov:generatedAtTime, t2}
 483 | :g2 {...} {:g2, prov:generatedAtTime, t2}
 484 | :g4 {...} {:g4, prov:generatedAtTime, t3}
 485 | 
 486 |
487 |

Two RDF streams S1 and S2 are B-isomorphic if and only if there is a bijection M 488 | between the nodes, triples, graphs, named graphs, and timestamped graphs that occur in S1 and those 489 | that occur in S2 such that:

    490 |
  1. M maps blank nodes to blank nodes;
    2. 491 |
  2. M is the identity map on literals and IRIs;
    3. 492 |
  3. For every triple <s p o>, M(<s, p, o>)= <M(s), M(p), M(o)>;
    4. 493 |
  4. For every graph G={t1, ..., tn}, M(G)={M(t1), ..., M(tn)};
    5. 494 |
  5. For every named graph NG=<n, G>, M(NG)=<M(n), M(G)>;
    6. 495 |
  6. For every timestamped graph TSG where NG is the named graph and DG is the default 496 | graph containing the timestamp triple TST, M(TSG) is a timestamped graph TSG2, with 497 | named graph M(NG), default graph M(DG) and timestamp triple M(TST).;
    7. 498 |
  7. For every i ≥ 1, M(S1(i))=S2(i), where S1(i) is the i-th element of S1 and S2(i) 499 | is the i-the element of S2.
    8. 500 |
501 |

502 |

An RDF stream is viewed as being on a single "RDF surface"(see [[BLOGIC]]), 503 | so that blank nodes may be shared between any graphs in the stream. For this reason, 504 | B-isomorphism is defined in terms of a single mapping M for the entire RDF stream rather 505 | than, say, separate mappings for each timestamped graph.

506 |

Two RDF streams are isomorphic if there exists an RDF stream that is both 507 | B-isomorphic to one stream and S-isomorphic to the other stream.

508 |

RDF streams that are S-isomorphic are isomorphic.

509 |

RDF streams that are B-isomorphic are isomorphic.

510 |

Isomorphic RDF streams MUST have the same semantics. The semantics of RDF streams is 511 | affected by the result of applying window functions () as 512 | well as by entailment. Therefore, isomorphic RDF streams SHALL be indistinguishable, up to 513 | isomorphism, with respect to entailment (in any entailment regime), as well as with 514 | respect to the application of window functions.

515 |
516 |
517 |

Substreams and Windows

518 |

A substream 519 | S' of an RDF stream S is an RDF stream that is isomorphic to a 520 | subsequence of S.

521 |

There are several specializations of the substream relation which are useful 522 | in practice. These include the filter relation, where stream elements are 523 | selected based on satisfaction of some criterion, and the window relation, where 524 | a temporally contiguous portion of the stream is selected.

525 |

A window 526 | S' of an RDF stream S is a substream of S such that 527 | if S'(i) and S'(j) are two elements of S' and 528 | S'(i) ≲ S'(j) (i.e., S'(j) covers S'(i)), and 529 | further if S'(i) ≲ S(k) ≲ S'(j) for some element S(k) of 530 | S, then S(k) is an element of S'.

531 |

Informally, a window is a temporally-contiguous selection from the original 532 | stream, without gaps.

533 |
534 |
535 |
536 |

Stream Merge and Union Operations

537 |

In order to combine two RDF streams into one, without loss or gratuitous introduction of 538 | entailments, we define two relations, RDF stream merge and RDF stream 539 | union. These relations are inspired by the concepts of similar name for RDF graphs 540 | defined in [[RDF11-Concepts]].

541 |

542 | RDF stream union is a trinary relation on RDF streams. Let S1, 543 | S2, and S3 be RDF streams. We say S3 is an RDF 544 | stream union of S1 and S2 if and only if the set of 545 | elements of S3 is equal to the union of the sets of elements of S1 546 | with S2.

547 |

Union is the appropriate relation to consider when combining streams that are 548 | allowed to share blank nodes. Informally, they would be on the same RDF surface.

549 | 563 |

564 | RDF stream merge is a trinary relation on RDF streams. Let S1, 565 | S2, and S3 be RDF streams. We say S3 is an RDF 566 | stream merge of S1 and S2 if and only if there exist 567 | streams S4, S5, and S6, with S4 568 | isomorphic to S1, S5 isomorphic to S2, 569 | S6 isomorphic to S3, such that S4 and 570 | S5 have no blank nodes in common, and S6 is the union of 571 | S4 with S5.

572 |

Merge is the appropriate relation to consider when joining streams that are 573 | considered to not share blank nodes. Informally, they would be on different RDF surfaces.

574 | 588 |

Given any three RDF streams, the determination of their satisfaction of the 589 | union or merge relation is a purely syntactic computation. That is, it is not necessary to 590 | consider entailments of the RDF streams or to be concerned with the values of literals.

591 | 615 |

The continuous operation of union or merge of two semi-infinite streams may 616 | not be computable, even when the operation is defined. This is because it may not be 617 | possible to know when an element of one stream might be received that needs to occur before 618 | the latest elements of the other stream. Computability of these continuous operations may be 619 | possible when additional information is available about the streams to be combined, e.g., the 620 | set of timestamp predicates used by each stream and the maximum latency of transmission. 621 | Within some RDF stream profiles, the union and merge operations may be continuously computable 622 | due to the profile constraints. 623 |

624 |
625 |
626 |

RDF Stream Subclasses

627 |

This section may be expanded with more subclasses if a need is identified.

628 |

Time-bounded RDF Streams

629 |

A time-bounded-above RDF stream is an RDF Stream where for every timestamp 630 | predicate of the stream, there is a temporal entity in its range that bounds 631 | from above (is greater than or equal to) all timestamps of that predicate in the stream.

632 |

A time-bounded-below RDF stream is an RDF Stream where for every timestamp 633 | predicate of the stream, there is a temporal entity in its range that bounds 634 | from below (is less than or equal to) all timestamps of that predicate in the stream.

635 |

A time-bounded RDF stream is an RDF Stream that is time-bounded above and 636 | time-bounded below.

637 |

Consider the class of timestamp predicates whose associated poset of 638 | temporal entities is pairwise bounded, i.e., has the property that every pair of 639 | temporal entities is bounded, i.e., there exists a temporal entity in the poset that is 640 | greater or equal to both of them and another temporal entity that is less or equal to both 641 | of them. This is a fairly natural property to expect for partial orders on time plenums with "linear topology" (e.g. 642 | [[OWL-TIME]]). However it does not hold in the case of branching time plenums (see http://www.ihmc.us/users/phayes/docs/timeCatalog.pdf), because there are incomparable 645 | branches (called paths), which may be considered, e.g., as different worlds (in the sense of 646 | Kripke frames), scenarios (planning usecase), or concurrent processes (process modelling). 647 | It would be a useful property if the class of time-bounded RDF streams were closed under 648 | stream merger and union, and this property would hold, under the current definition, in the 649 | case of pairwise-bounded time plenums, because we could find bounds for the temporal entities 650 | of each timestamp predicate by taking an upper bound of the pair of upper bounds from the 651 | two streams, and similarly for the lower bounds. However, the closure property does not hold 652 | in the case of a branching temporal topology under the above definition of time-bounded. To 653 | achieve the closure property, we would have to allow a number of "upper bounds" for each 654 | timestamp predicate, rather than requiring just one. For example,

Given two 655 | sets, A and B, of entities in a partial order, we say that A bounds B from above iff there 656 | is no element of B that is greater than any element of A, and for every element of B there 657 | is some element of A that is greater than or equal to it.

A 658 | time-bounded-above RDF stream is an RDF Stream where for every timestamp 659 | predicate of the stream, there is a set of temporal entities in its range that 660 | bounds from above all timestamps of that predicate in the stream.

661 |

The class of time-bounded RDF streams using timestamp predicates with 662 | pairwise-bounded time plenums is closed under stream merger and union.

663 |

Temporal-count-bounded RDF Streams

664 |

A temporal-count-bounded RDF stream is an RDF stream where for each timestamp 665 | predicate of the stream, there are a finite number of temporal entities in the 666 | stream that are timestamps for that predicate.

667 |

The qualifier "temporal" has been added to this term to emphasize that it is 668 | temporal entities that are being counted, not timestamped graphs.

669 |

Given an RDF stream whose set of timestamp predicates with pairwise-bounded 670 | temporal entities, then if the stream is temporal-count-bounded it is also time-bounded, 671 | since the upper bound for each timestamp predicate can be taken as an upper bound of the 672 | (finite) set of its timestamps, and similarly for the lower bound. If the definition of 673 | "time-bounded" was changed as in the earlier Editor's Note, then every 674 | temporal-count-bounded RDF stream would be time-bounded.

675 |

Every temporal-count-bounded RDF stream using only timestamp predicates with 676 | pairwise-bounded time plenums is time-bounded.

677 |

The class of temporal-count-bounded RDF streams is closed under stream merger 678 | and union, since the sets of temporal entities for each timestamp predicate in the resulting 679 | stream are the union of the corresponding (finite) sets in the original streams, and so are 680 | finite.

681 | 
          
 682 |
683 |

Finite RDF Stream

684 |

A finite RDF stream is an RDF stream of finite length, i.e., with a finite number 685 | of elements in it.

686 |

Clearly, every finite RDF stream is temporal-count-bounded.

687 |

Every finite RDF stream using only pairwise-bounded time plenums is 688 | time-bounded. However, this is not the case for branching time plenums.

689 |

Clearly, the class of finite RDF streams is closed under stream merger and 690 | union.

691 | 
 692 |
693 | 
 694 |
695 |
696 |
697 |

Window Functions

698 |

A window function is a partial function from RDF streams to their windows that 699 | preserves isomorphism. That is, if w is a window function, with isomorphic 700 | streams S1 and S2 in its domain, then w(S1) is 701 | isomorphic to w(S2).

702 |

A general window function is a window function that is a total function on RDF 703 | streams.

704 |

The term "window operator" is reserved for later use to return a sequence of 705 | windows.

706 |

The most common types of window functions in practice are time-based and count-based.

707 |
708 |

Time-based Window Functions

709 |

Because the time plenum for each timestamp predicate is partially ordered, we may define a 710 | temporal interval of a timestamp predicate to be an interval, in the usual 711 | sense for partial orders, within its time plenum.

712 |

Recall that intervals need not be bounded and need not be closed, and are 713 | specified in terms of two, one or zero inequality conditions based on the partial order or 714 | its induced strict order.

715 |

A general time-based window function 716 | w is a general window function specified by a finite set 717 | wP of timestamp predicates together with temporal intervals 718 | wJ(P) of each timestamp predicate P in 719 | wP, such that for every stream S, an element 720 | S(i) of S is an element of w(S) if and only if the 721 | timestamp predicate P of S(i) is in P and the 722 | timestamp t of S(i) is contained in 723 | wJ(P).

724 |

A time-based window function is the restriction of a general time-based window 725 | function to a subset of RDF streams.

726 |

The substream resulting from the application of a time-based window function 727 | is time-bounded.

728 |
729 |
730 |

Temporal-count-based Window Functions

731 |

A general temporal-count-based window function 732 | w is a general window function specified by a finite set 733 | wP of timestamp predicates together with semi-infinite temporal 734 | intervals wJ(P) of each timestamp predicate P in 735 | wP with endpoints wT(P), and positive 736 | integers wN(P), for each timestamp predicate P in 737 | wP such that for every stream S, an element 738 | S(i) of S is an element of w(S) if and only if the 739 | timestamp predicate P of S(i) is in P and

    740 |
  • t is the timestamp of S(i),
    • 741 |
  • T(S, P, w) is the set of temporal entities that are timestamps for 742 | elements of S with timestamp predicate P, belong to 743 | wJ(P), and belong to the closed interval between 744 | t and wT(P), and
    • 745 |
  • the cardinality of T(S, P, w) is less than or equal to 746 | wN(P)
    • 747 | 748 |
749 |

750 |

A temporal-count-based window function is the restriction of a general 751 | temporal-count-based window function to a subset of RDF streams.

752 | 759 |

The substream resulting from the application of a temporal-count-based 760 | window function is temporal-count-bounded.

761 |

Due to the potential for stream elements with incomparable or duplicate 762 | timestamps, the number of elements in the substream having a particular timestamp 763 | predicate is not guaranteed to be equal to the depth specified for the predicate by the 764 | temporal-count-based window.

765 |

Temporal-count-based window functions with future-facing orientation on 766 | timestamp predicates whose time plenum is not totally-ordered are not computable, because in 767 | general it is not possible to know, at any point in the reception of the stream, whether 768 | there are further elements of the stream that would be selected by the 769 | temporal-count-based window function.

770 |

Applications that require a substream with an exact number N of elements for 771 | a specified timestamp predicate might apply a temporal-count-based window function with 772 | N for the count of temporal entities, and then randomly discard extra 773 | elements, according to some criterion, e.g., extreme elements (maximal or minimal, 774 | depending on the orientation of the counting). However, this extra step causes the process 775 | to be nondeterministic, and hence does not correspond to a function. If elements are 776 | discarded in a nonrandom fashion, e.g., based on their order in the stream sequence, then 777 | this would be a function, but would not preserve isomorphism, and so would not be a window 778 | function. The issue of obtaining a window function that returns an exact number of 779 | elements (for a particular predicate) is handled in the next section, where we define the 780 | concept of window relation, and use it to define an element-count-based window relation. 781 | When restricted to certain kinds of RDF streams, element-count-based window relations are 782 | functional so element-count-based window functions can be defined on such subsets. This 783 | and similar considerations, of importance to implementations, motivate the RDF Stream profiles as subsets of RDF streams.

785 |
786 |
787 |

Window Relations

788 |

A window relation is a binary relation on RDF streams (a relation having an 789 | extension which is a set of pairs of RDF streams) such that the second element in the pair 790 | is a window of the first element and preserves isomorphism. That is, if <S1, 791 | S2> is a member of the extension of a window relation W, and 792 | S3 and S4 are isomorphic to S1 and 793 | S2, resp., then <S3, S4> is also a member of the 794 | extension of W.

795 |

A length-based window relation 796 | W is a window relation specified by a set of streams 797 | WS, a finite set WP of timestamp 798 | predicates together with the following parameters for each timestamp predicate 799 | p in WP:

    800 |
  • a semi-infinite temporal interval WJ(P) of timestamp 801 | predicate P (the interval of P);
    • 802 |
  • a temporal entity WT(P) which is the finite endpoint of 803 | WJ(P) (the temporal reference of P);
    • 804 |
  • a positive integer WN(P) (the length for 805 | P)
    • 806 |
The extension of a length-based window relation is defined as follows: Let 807 | S be an RDF stream in WS with window 808 | S'. Define T(S, P, W) to be the set of temporal entities that 809 | are timestamps for elements of S with timestamp predicate P and 810 | belong to WJ(P), and T(S', P) to be the set of 811 | temporal entities that are timestamps for elements of S' with timestamp 812 | predicate P. The pair <S, S'> is a member of the extension 813 | of W if and only if the cardinality of T(S', P) is equal to the 814 | minimum of WN(P) and the cardinality of the set T(S, P, 815 | W) and for each element S'(i) of S' 816 |
    817 |
  • the timestamp predicate P of S'(i) is in 818 | WP, and
    • 819 |
  • the timestamp t of S'(i) is in 820 | WJ(P).
    • 821 |
822 |

823 |

A length-based window function 824 | W on domain WS is a length-based window relation 825 | where any member <S, S'> of its extension are such that S 826 | is in WS and W defines a total function on 827 | WS.

828 |

The names "element-count-bounded window relation" and "element-count-bounded window function" 829 | have been proposed, as a replacement of "length-bounded ...". This nomenclature depends on the adoption of 830 | "element" as the term for the individual timestamped graphs in a stream.

831 |
832 |
833 | 850 |
851 |

this example could be integrated to the main text body

852 |

Beyond time instants: intervals & more

853 |

Usign the previously described model, intervals can be specified for a graph in the 854 | following way: Given p1 and p2 representing start and end time predicates, then 855 | (g,p1,t1) and (g,p2,t2) denote that g is defined in an interval 856 | [t1,t2]. As an example:

857 | 
:g_1, :startsAt, "2015-06-18T12:00:00"^^xsd:dateTime
 858 | :g_1, :endsAt, "2015-06-18T13:00:00"^^xsd:dateTime
 859 |
860 |

Or even:

861 | 
:g_2 :validBetween
 862 |     [:startsAt "2015-06-18T12:00:00"^^xsd:dateTime;
 863 |     :endsAt "2015-06-18T13:00:00"^^xsd:dateTime]
 864 |
865 |
866 |
867 |

Semantics

868 |

The semantics of a timestamped graph is defined in terms of its semantics as an RDF 869 | Dataset. In particular, the designation of a particular triple in the default graph as the 870 | timestamp triple has no effect on its semantics.

871 |

The semantics of timestamped graphs, and consequently of RDF streams, is based on the 872 | semantics formalized in [[RDF11-Datasets]] in the case that each named graph defines its own 873 | context.

874 |

The following terms are used in the sense of [[RDF11-MT]]: entailment regime, 875 | E-interpretation, blank node, universe, named graph pair, RDF graph, E-entails, default 876 | graph.

877 |

An RSP interpretation 878 | I with respect to an entailment regime E is an E-interpretation 879 | extended to named graphs, timestamped graphs, RDF datasets, and RDF streams as follows:

    880 |
  • given a mapping A from blank nodes to the universe IR and a 881 | named graph pair ng = <n, G>, [I+A](ng) is 882 | true if and only if [I+A](n) is an RDF graph that E-entails 883 | G;
    • 884 |
  • for a timestamped graph TSG = < ng, DG>, where 885 | DG is the default graph and ng is the named graph pair of 886 | TSG,and a mapping A from blank nodes to the universe 887 | IR, [I+A](TSG) is true if and only if [I+A](DG) 888 | is true and [I+A](ng) is true;
    • 889 |
  • I(TSG) true if and only if there exisits a mapping A from 890 | blank nodes to the universe IR such that [I+A](TSG) is true.
    • 891 |
  • for an RDF dataset D = < DG, NG>, where DG 892 | is the default graph and NG is the set of named graph pairs of 893 | D, I(D) is true if there exists a mapping A 894 | from blank nodes to the universe IR such that [I+A](DG) is 895 | true and [I+A](ng) is true for every ng in 896 | NG;
    • 897 |
  • I(D) is false otherwise.
    • 898 |
  • for an RDF stream S, I(S) is true if and only if if there exists a 899 | mapping A from blank nodes to the universe IR such that for 900 | every element S(i) of S, i ≥ 1, 901 | [I+A](S(i)) is true.
    • 902 |
We say that an RSP interpretation I E-satisfies a graph, named graph 903 | pair, timestamped graph, dataset, or stream X (or satisfies A 904 | w.r.t the E-entailment regime) when I(X) is true.

905 |

Following standard terminology, we say that a graph, named graph, timestamped graph, 906 | dataset, or stream X RSP-E-entails a graph, named graph, timestamped graph, 907 | dataset, or stream Y if and only if for every RSP interpretation I 908 | with respect to E-entailment, I E-satisfies Y whenever 909 | I E-satisfies X.

910 |

The "RSP" prefix in "RSP-E-entails" may be dropped when neither antecedent nor 911 | consequent is an RDF dataset or named graph, as in that case there is no possibility of 912 | alternate dataset semantics.

913 |

It should be straightforward to prove that isomorphic RDF streams simply 914 | entail each other, and hence are logically equivalent under simple entailment. This should 915 | also hold for other standard entailment regimes, and perhaps should be required for all RSP 916 | entailment regimes.

917 |

The notion of RSP-E-entailment is defined here so that it may be used to 918 | support the definition of query semantics under various entailment regimes in the [[RSP-QL 919 | Queries]] document, including simple entailment. A choice was made regarding the semantics 920 | of named graph pairs (i.e., [I+A](ng) is true if and only if 921 | [I+A](n) is an RDF graph that E-entails G) that affects the 922 | semantics of timestamped graphs, datasets, and streams. It remains to be seen if this choice 923 | supports query semantics in a manner that meets the needs of the RSP-QL community. In 924 | particular, it imposes constraints on the denotation of the name of a named graph pair which 925 | may be inconsistent with the domain of a predicate that might be considered for use as a 926 | timestamp predicate (e.g., SSN predicate ssn:observationSamplingTime).

927 |
928 |
929 |

Profiles

930 |

It is possible to restrict the abstract syntax for a class of RDF streams. This is often 931 | done in order to facilitate the efficient implementation of certain operations and queries 932 | or to promote more efficient representation. Each such restriction constitutes an RDF 933 | stream profile.

934 |

The profiles defined in this document fall into two categories: time-series profiles and 935 | linked-list profiles. Within each category there is a least-restrictive profile and a number 936 | of subprofiles which apply additional restrictions to it.

937 |
938 |

RDF Time-Series Profiles

939 |

This section describes four profiles which are defined through restrictions on the 940 | default graphs of the stream's timestamped graph elements or on the relation between 941 | timestamp values:

    942 |
  • RDF time series
    • 943 |
  • RDF distinct time series
    • 944 |
  • RDF regular time series
    • 945 |
  • RDF distinct regular time series
    • 946 |

947 |
948 |

RDF Time-Series Profile

949 |

The RDF Stream Time-Series profile is designed to support high-volume, low-latency 950 | window operations and queries that depend on full knowledge of timestamps.

951 |

This motivational paragraph needs some work - the above is a place 952 | holder.

953 |

An RDF time series is an RDF stream that satisfies the following 954 | properties:

955 |
    956 |
  1. The stream uses exactly one timestamp predicate.
    2. 957 |
  2. The range of this timestamp predicate is xsd:dateTimeStamp.
    3. 958 |
  3. No two elements in the time series have the same graph name.
    4. 959 |
960 | 966 |

If some property (e.g., in the RSP-QL namespace) is defined as a 967 | subproperty of prov:generatedAtTime, then this can be substituted in Example 4, which will then serve as an example of a 969 | time series. Alternatively, the definition could be changed so that the only requirement 970 | is that the timestamps that occur in the stream belong to xsd:dateTime.

971 |

The set of RDF time series is closed under RDF stream merge and union on 972 | time series that use the same timestamp predicate.

973 |
974 |
975 |

RDF Distinct Time-Series Profile

976 |

An "RDF distinct time series" is an RDF time series such that no two elements in the 977 | time series have the same timestamp.

978 | 981 |

An RDF distinct time series has a unique sequential order - it is 982 | S-isomorphic only to itself.

983 |

The merge or union of RDF distinct time series is always defined but is 984 | not necessarily an RDF distinct time series, even if the operation is restricted to time 985 | series that use the same timestamp predicate, due to the possibility of duplication of 986 | timestamp. However, the merge or union of RDF distinct time series that use the same 987 | timestamp predicate is always an RDF time series.

988 |

The restriction of element-count-based window relations 989 | to distinct time series results in functional 990 | relations. This enables the definition of element-count-based window functions for distinct time series. 991 | Further, the element-count-based window functions are always computable. However, the 992 | time-based window functions are not necessarily computable unless there is a finite 993 | precision to the timestamps, as can be seen from the Zeno's paradox example @@@(this 994 | example hasn't been written up yet, but is mentioned elsewhere).

995 |

There is going to be a lot more to talk about for RDF time series 996 | relative to queries, but in this document we don't have those definitions.

997 |
998 |
999 |

RDF Regular Time-Series Profile

A regular RDF time series is a further 1000 | subclass of distinct time series where the duration between timestamps is an integer 1001 | multiple of a specified duration, called the spacing of the time series. 1005 |

The restriction of timestamps in the regular time series profile allows 1006 | the timestamp to be represented concisely as an integer, provided the spacing is 1007 | provided elsewhere, e.g., in metadata.

1008 |
1009 |
1010 |

RDF Distinct Regular Time-Series Profile

A distinct regular RDF time 1011 | series is a further subclass of distinct time series that is both a distinct time series 1012 | and a regular time series. 1015 |

@@@motivate this profile

1016 |
1017 |
1018 |
1019 |

RDF Linked-List Profiles

1020 |
1021 | 1033 |
1034 | 1035 |
1036 | 1037 | 1038 | --------------------------------------------------------------------------------