rsep-ql: a query model to capture event pattern matching in rdf stream processing languages

A Query Model to Capture Event Pattern Matching in RDF Stream Processing Languages

Daniele Dell’Aglio, Minh Dao-Tran, Jean-Paul Calbimonte,

Danh Le Phuoc and Emanuele Della Valle

[email protected] http://dellaglio.org @dandellaglio

Bologna, Italy, 21.11.2016

http://dellaglio.org/

RDF Stream Processing

StreamProcessing

RDF

&

SPARQL

RDF Stream

Processing (RSP)

Real-time

processing of

highly dynamic

data

Semantic Web

technologies for

data exchange

through the Web

2/20 EKAW, 21 November 2016A Query Model to Capture Event Patterns in RSP languages

Stream Processing and RSP

In literature there are two different main approaches to

process streams

Data Stream Management Systems (DSMSs)

Aggregations and filters

Relies on the notion of sliding window

DSMS-inspired RSPs: C-SPARQL, CQELS, SPARQLstream

Complex Event Processors (CEPs)

Search of relevant patterns in the stream

Non-equi-join on timestamps (after, before, etc.)

CEP-inspired RSP: EP-SPARQL

C-SPARQL offers some CEP features through a timestamp function


The problem

Execution 7 8 9

EP-SPARQL

(unrestricted)

:a, :c [1,5]

:b, :d [3,5]

:b, :d [3,7]

:a, :c [1,9]

EP-SPARQL

(chronological)

:a, :c [1,5]

:b, :d [3,5]

EP-SPARQL

(recent)

:b, :d [3,5]

:b, :d [3,7]

C-SPARQL

(sl. win. 7,1)

:b, :d [3,7]

Who is listening to who?

{?att :isIn ?room}

SEQ

{?spe :talksIn ?room}

G1 G2 G3 G4

t

{:a :isIn :rRoom}

{:b :isIn :bRoom}

{:c :talksIn :rRoom,

:d :talksIn :bRoom}

{:d :talksIn :bRoom}

G6

{:e :isIn :bRoom}

S G5

{:c :talksIn :rRoom}

3 5 91 7 8


Motivation

In the context of evaluation of the CEP operators over

RDF streams, how can the behaviour of existing systems

be captured, compared and contrasted?

Why do we need it?

• Comparison and contrast

• Interoperability

• Study RDF Stream Processing related problems

• Standard RSP query language

RSEP-QL as a reference model for RSP query languages


Data model: RDF streams and windows

An RDF stream is an (infinite) ordered sequence of time-

annotated data items (RDF graphs)

t

𝕎(3,1,0)

𝕃(1)

𝑊(2,5]

G1 G2 G3 G4

t

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

S G5


3 5 91 7 8

Window

Landmark window

Sliding window


Operators

Event Processing operators

• EVENT w P (Basic Event Pattern)

• E1 SEQ E2

• FIRST E1

• LAST E1

• MATCH to describe an event pattern

Stream Processing operators

SPARQL operators


Evaluation Semantics

The SPARQL evaluation function is defined as

⟦𝑃⟧𝐷𝑆(𝐺)

The RSEP-QL evaluation function is ⟪⋅⟫ 𝑜,𝑐𝑡

• t is the evaluation time instant

• 𝑜, 𝑐 is an additional window to identify the portion of

the data on which the event may happen

Event pattern evaluation produces event mappings

𝜇, 𝑡1, 𝑡2• 𝜇 is a solution mapping

• 𝑡1 and 𝑡2 denote the time inverval justifying 𝜇


Basic Event Pattern: EVENT w P

Look for mappings in graphs selected by the windows

Example: ⟪EVENT 𝕃(0) {?spe :talksIn ?room}⟫ 0,77

𝑊 0,7 , 𝕃(0)

G ?spe ?room 𝒕𝟏, 𝒕𝟐

𝐺3 :c :rRoom 5,5

𝐺3 :d :bRoom 5,5

𝐺4 :d :bRoom 7,7

G1 G2 G3 G4

t

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

S G5


3 5 91 7 8


Basic Event Pattern: EVENT w P

Example: ⟪EVENT 𝕃(5) {?spe :talksIn ?room}⟫ 0,77

𝑊 0,7

G ?spe ?room 𝒕𝟏, 𝒕𝟐

𝐺4 :d :bRoom 7,7

𝕃(5)𝑊 0,7 𝕃(5)

G1 G2 G3 G4

t

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

S G5


3 5 91 7 8


E1 SEQ E2

Event mappings that matches 𝐸2 should be joined with

event mappings from 𝐸1 that are:

Compatible – the solution mappings in the event mappings

should be compatible

Before – the interval that justifies the first solution mapping

should finish before the interval that justifies the second one

opens


Example

⟪EVENT 𝕃(0) {?att :isIn ?room} SEQ EVENT 𝕃(0) {?spe :talksIn ?room} ⟫(0,8]8

𝑊 0,8 , 𝕃(0)

G1 G2 G3 G4

t

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

?spe ?room 𝒕𝟏, 𝒕𝟐

:c :rRoom 5,5

:d :bRoom 5,5

:d :bRoom 7,7

?att ?room 𝒕𝟏, 𝒕𝟐

:a :rRoom 1,1

:b :bRoom 3,3

:e :bRoom 8,8

?att ?spe ?room 𝒕𝟏, 𝒕𝟐

S G5


3 5 91 7 8


Example



:c :rRoom 5,5

:d :bRoom 5,5

:d :bRoom 7,7


:a :rRoom 1,1

:b :bRoom 3,3

:e :bRoom 8,8


𝑊 0,8 , 𝕃(0)

G1 G2 G3 G4

t3 5 91

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

7

S G5


8


Example



:c :rRoom 5,5

:d :bRoom 5,5

:d :bRoom 7,7


:a :rRoom 1,1

:b :bRoom 3,3

:e :bRoom 8,8


𝑊 0,8 , 𝕃(0)

G1 G2 G3 G4

t3 5 91

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

7

S G5


8

not compatible


Example



:c :rRoom 5,5

:d :bRoom 5,5

:d :bRoom 7,7


:a :rRoom 1,1

:b :bRoom 3,3

:e :bRoom 8,8


𝑊 0,8 , 𝕃(0)

G1 G2 G3 G4

t3 5 91

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

7

S G5


8

not compatiblenot before


Example



:c :rRoom 5,5

:d :bRoom 5,5

:d :bRoom 7,7


:a :rRoom 1,1

:b :bRoom 3,3

:e :bRoom 8,8


:b :d :bRoom 3,5

𝑊 0,8 , 𝕃(0)

G1 G2 G3 G4

t3 5 91

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

7

S G5


8

not compatiblenot before


Example



:c :rRoom 5,5

:d :bRoom 5,5

:d :bRoom 7,7


:a :rRoom 1,1

:b :bRoom 3,3

:e :bRoom 8,8


:b :d :bRoom 3,5

:a :c :rRoom 1,5

:b :d :bRoom 3,7

𝑊 0,8 , 𝕃(0)

G1 G2 G3 G4

t3 5 91

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

7

S G5


8


SEQc, SEQr and SEQn

We need futher SEQ operators to model the behaviour

of the engines

They basically works as SEQ, with some additional constraint

To model the engines we analysed, we defined:

SEQ

SEQc

SEQr

SEQn


E1 SEQc E2

If there are two output event mappings with the same solution mapping,

SEQc considers the least recent one

⟪EVENT 𝕃(0) {?att :isIn ?room} SEQc EVENT 𝕃(0) {?spe :talksIn ?room}⟫(0,8]8


:c :rRoom 5,5

:d :bRoom 5,5

:d :bRoom 7,7


:a :rRoom 1,1

:b :bRoom 3,3

:e :bRoom 8,8


:a :c :rRoom 1,5

:b :d :bRoom 3,5

:b :d :bRoom 3,7

G1 G2 G3 G4

t3 5 91

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

7

S G5


8


E1 SEQr E2

If there are two output event mappings with the same solution mapping,

SEQr considers the most recent one

⟪EVENT 𝕃(0) {?att :isIn ?room} SEQr EVENT 𝕃(0) {?spe :talksIn ?room}⟫(0,8]8


:c :rRoom 5,5

:d :bRoom 5,5

:d :bRoom 7,7


:a :rRoom 1,1

:b :bRoom 3,3

:e :bRoom 8,8


:a :c :rRoom 1,5

:b :d :bRoom 3,5

:b :d :bRoom 3,7

G1 G2 G3 G4

t3 5 91

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

7

S G5


8


E1 SEQn E2

If there are two input event mappings with the same solution mapping,

SEQn considers the most recent one

⟪EVENT 𝕃(0) {?att :isIn ?room} SEQn EVENT 𝕃(0) {?spe :talksIn ?room}⟫(0,8]8


:c :rRoom 5,5

:d :bRoom 5,5

:d :bRoom 7,7


:a :rRoom 1,1

:b :bRoom 3,3

:e :bRoom 8,8


:a :c :rRoom 1,5

:b :d :bRoom 3,7

G1 G2 G3 G4

t3 5 91

{:a :isIn :rRoom}

{:b :isIn :bRoom}


:d :talksIn :bRoom}


G6

{:e :isIn :bRoom}

7

S G5


8


Consumption policies

The evaluations in a sequence are not always independent

Some data may be involved in the current evaluation only if it

was not before

We need a mechanism to move this information between

evaluations

Consumption policies are functions to describe the input for

the next evaluation

Two policies for our needs

𝒫𝑢: the input is the one selected by the window

𝒫𝑛: the input is the one selected by the window and that

was not used to produce results in the previous

evaluations


Captured behaviours

System Window

operator

Sequencing

operator

Consumption

policy

EP-SPARQL

(unrestricted)

Landmark SEQ 𝒫𝑢

EP-SPARQL

(chronological)

Landmark SEQc 𝒫𝑛

EP-SPARQL

(recent)

Landmark SEQr 𝒫𝑛

C-SPARQL Sliding SEQn 𝒫𝑢


Conclusions

The dynamics introduced in the continuous query

evlauation process have not been totally understood

Not fully captured by existing models

RSEP-QL captures those dynamics, and the behaviours of

existing RDF Stream Processing engines

CEP-based (today’s talk)

DSMS-based (RSP-QL)

What’s next

Extension of futher operators (NOT, DURING)

Further investigation about the relation of RSEP-QL with other

models (SPARQL, LARS)


Thank you! Questions?

A Query Model to Capture Event Pattern Matching in RDF Stream Processing Languages

Daniele Dell’Aglio, Minh Dao-Tran, Jean-Paul Calbimonte,

Danh Le Phuoc and Emanuele Della Valle

[email protected]

http://dellaglio.org

@dandellaglio


mailto:[email protected]

http://dellaglio.org/

rsep-ql: a query model to capture event pattern matching in rdf stream processing languages

Data & Analytics