Smart environments require collaboration of multi-platform sensors operated by multiple parties. Proprietary event processing solutions lack interoperation exibility, leading to overlapping functions that can waste hardware and communication resources. Our goal is to show the applicability of standard RDF and SPARQL { including SPARQL 1.1 Update { for complex event processing tasks. If found feasible, event processing would enjoy the bene ts of semantic web technologies: crossdomain interoperability, exible representation and query capabilities, interrelating disjoint vocabularies, reasoning over event content, and enriching events with linked data. To enable event processing with standard RDF/SPARQL we have created Instans, a high-performance Rete-based platform for continuous execution of interconnected SPARQL queries.
Complex event processing is currently more dominated by proprietary systems and vertical products than open technologies. In the future, however, internetconnected people and things moving between smart spaces in smart cities will create a huge volume of events in a multi-actor, multi-platform environment.
Semantic web technologies enable exible representation of events in RDF and advanced speci cation of event patterns with SPARQL. They provide possibilities to reason about event content and to enrich events with linked open data available in the web. Semantic web standards have clear potential to improve the interoperability and o er new capabilities in complex event processing.
A major event processing application can hardly be created out of a single
SPARQL query. The INSERT operation in SPARQL 1.1 Update introduced a
critical new property: By inserting data into a graph, collaborating SPARQL
queries can store intermediate results and communicate with each other. On an
environment supporting simultaneous, continuous evaluation of multiple queries,
SPARQL can be used to create entire event processing applications [
After nding no other platform for incremental processing of multiple SPARQL
1.1 queries, we created Instans. Based on the tried and tested Rete-algorithm
[
Here we extend the discussion in [
INSTANS Event Processing Platform
Instans1 [
The structure of Instans is illustrated in Fig. 1. The system consists of the Rete engine and the input and output connectors, which can interface with the network, triple stores, les or other processes. The Rete engine has four components: 1. Rete network, 2. -matcher, 3. Rule instance queue, 4. Instance executor. The -matcher and the Rete network are capable of nding all SPARQL rule conditions satisfying the current set of triples. During runtime the -matcher receives commands to add and remove triples. The matcher nds the -nodes of the Rete that match the triples and calls the add or remove methods of those nodes. The changes propagate through the -network and eventually fully satis ed rule conditions enter the rule nodes, which add new rule instances (with 1 Incremental eNgine for STANding Sparql, http://cse.aalto. /instans/ variable bindings) to the rule instance queue. The instance executor executes the rule instances, which causes add and remove triple commands to be fed into the output connectors. The rule instance execution also feeds add and remove triple commands to the -matcher, resulting in new rule instances. Instans operation over an example query is illustrated in Fig. 2. The query selects events occurring between 10 and 11 am. The asynchronous nature of Instans means that all input !1 "1: ! a event:event "2: ! event:time !
"3: ! tl:at ! 1 3
5
?time, ?daytime
is processed when it arrives. To manage periodic actions and missing events, the
concept of timed events is introduced [
!2 Query: SELECT ?event WHERE { ?event a event:Event ; event:7me ?7me . ?7me tl:at ?day7me . FILTER ( hours(?day7me) = 10 ) } Process flow: ① Each condi7on corresponds to an α-‐node. α1 matches
with sample input “:e1 a event:Event”. ② “:e1” propagates to β2 and is stored there. ③ α2 matches with “:e1 event:,me _:b1”, where “_:b1” is a blank node. Input from β2 matches with “?event” in Y2. ④ “:e1” and “_:b1” propagate un7l β3. ⑤ α3 matches with input “_:b1 tl:at
“2011-‐10-‐03T10:05:00”ˆˆxsd:dateTime”. ⑥ In Y3 “_:b1” is equal in both incoming branches and
can be eliminated. ⑦ “:e1” and “2011-‐10-‐03T10:05:00”ˆˆxsd:dateTime
reach filter1. The condi7on “hour = 10” is true. ⑧ “:e1” is selected as a result.
:e1 ?event
Y2 4
?event, ?time ?event, ?time !3
:e1 _:b1 ?event, ?time 6 7 8
Y3 filter1
?event select1 ?event, ?daytime
Drop _:b1 :e1 10:05 SPARQL query matching such a triple reacts to the change and carries out the de ned actions. No extensions to SPARQL are needed to support timed events.
Performance of Instans in terms of noti cation delay was compared to
CSPARQL [
The feasibility of the central paradigm of Instans { continuous incremental matching of multiple SPARQL queries supporting inter-query communication { has so far been supported by empirical tests. When complemented with support for timed events, we have found no showstopper problems which would render the approach unusable for any complex event processing task.
The performance of Instans is higher compared to systems based on repeated execution of queries at xed time intervals (or triple counts); they cannot practically compete with Instans whose noti cation delays are in the order of milliseconds. Instans avoids redundant computation: each event is processed immediately on arrival and only once through the Rete network, network structures are shared across similar queries, and intermediate results are memorized.