Introduction to INSTANS

Transcription

1 Introduction to INSTANS Mikko Rinne, Seppo Törmä, Esko Nuutila Department of Computer Science and Engineering Distributed Systems Group

2 INSTANS *) Event Processing Platform Based on the Rete-algorithm Performs continuous evaluation of incoming RDF data against multiple interconnected SPARQL queries When all the conditions of a query are matched, the result is instantly available. Event Processing Network 1. Event Producer (e.g. INSTANS) 2. Event Channel (RDF) 3. Event Processing Agent (INSTANS) 2. Event Channel (RDF) 4. Event Consumer (e.g. INSTANS) *) Incremental engine for STANding Sparql

3 INSTANS Phases 1. Compilation Queries parsed into abstract syntax trees Syntax trees translated into a Rete network with shared structure Rete network translated into a set of Lisp functions 2. Execution An α-matcher receives commands to add and remove triples and calls add or remove methods of corresponding α-nodes Rete network propagates changes through a β network Fully satisfied rule conditions are executed, causing add and remove triple commands to be fed into output connectors and / or in a feedback loop to the α-matcher

4 Event Processing Based on SPARQL SPARQL is tailor-made to query RDF data SPARQL 1.1 Update supports INSERT operations, enabling Memory: Storing data to named graphs Communication between SPARQL queries Stepwise processing of data Applications can be constructed entirely of SPARQL Queries Query 1: Conditionally INSERT <triple> Bindings in Rete Query 2: Use <triple> as input

5 Rete-Net!1 "1:! a event:event 1 "2:! event:time! 3 "3:! tl:at! 5 Translation of SPARQL-Queries into an incremental processor Each input triple propagates according to the queries and resulting states are saved within the structure When a complete query is matched, results are immediately available Query: Y1 SELECT?event WHERE {?event a event:event ; event:7me?7me.?7me tl:at?d<m. FILTER ( hours(?day7me) = 10 ) } Process flow:?event 2?event!2 :e1?event 1 Each condi7on corresponds to an α- node. α1 matches with sample input :e1 a event:event. 2 :e1 propagates to β2 and is stored there. 3 α2 matches with :e1 event:,me _:b1, where _:b1 is a blank node. Input from β2 matches with?event in Y2. 4 :e1 and _:b1 propagate un7l β3. 5 α3 matches with input _:b1 tl:at T10:05:00 ˆˆxsd:dateTime. 6 In Y3 _:b1 is equal in both incoming branches and can be eliminated. 7 :e1 and T10:05:00 ˆˆxsd:dateTime reach filter1. The condi7on hour = 10 is true. 8 :e1 is selected as a result. Y2 4!3?event,?time?event,?time :e1 _:b1?event,?time Y3 filter1 select1?event,?daytime?event?time,?daytime Drop _:b1 :e1 10:05

6 Close Friends Example Mobile clients emit location updates Service produces a nearby notification if two friends come geographically close to each other 1. Static input (RDF Store) Configuration 2. Event Producer (RDF Stream) 5. Event Consumer Mobile Client 3. Event Channel 4. Event Processing Agent Network

7 Close Friends Collaborative SPARQL Update Rules Query 1: Maintain only the latest registration in the workspace Query 2: Insert a nearby detection marker Query 3: Emit notifications Query 4: Delete nearby status No duplicate detections due to window repetition Input buffer management is handled by SPARQL

8 Close Friends Queries Query 1) Window-query: DELETE { <bind event to variables>} WHERE { <bind event to variables> FILTER EXISTS {?event2 event:agent?person ; event:time [tl:at?dttm2]. FILTER (?dttm <?dttm2) } } Query 2) Nearby detection INSERT {?person1 :nearby?person2 } WHERE {?person1 foaf:knows?person2. <bind events for p1+p2> # Check proximity in space and time FILTER ((abs(?lat2-?lat1)<0.01) && (abs(?long2-?long1)<0.01) && (abs(hours(?dttm2)*60+minutes(?dttm2) -hours(?dttm1)*60-minutes(?dttm1))<10)) # Don't insert, if the relation already exists FILTER NOT EXISTS {?person1 :nearby?person2}} Query 3) Notification: SELECT?person1?person2 WHERE {?person1 :nearby?person2 } Query 4) Removal of ``nearby'' status: DELETE {?person1 :nearby?person2 } WHERE {?person1 foaf:knows?person2. <bind events for p1+p2> FILTER ( (abs(?lat2-?lat1)>0.02) (abs(? long2-?long1)>0.02)) FILTER EXISTS {?person1 :nearby?person2 } }

9 Continuous Processing vs. Window Repetition Continuous processing of SPARQL queries has benefits over window repetition Instantaneous availability of results No duplicate detections due to overlapping windows No missing detections on window borders No repeated processing over the same data Window lengths typically based either on time or number of triples Based on the assumption that each triple marks a standalone event Heterogeneous event formats needed to support all types of sensor input

10 Processing of Timed Events The asynchronous nature of INSTANS means that all input is processed when it arrives For synchronized operations, synthetic events can be generated at specific points in time Detection of a missing event Compilation of a report Timed events can be created as an RDF streaming service Current INSTANS implementation using a special timergraph and a set of special predicates INSERT { GRAPH < {?event <tp:timer_sec>?timevalue } } WHERE {?event <:seconds>?timevalue } Start a five-second timer: <:5sec_pulse> <:seconds> "5"^^<xsd:integer>

11 !1 "1:! a <ffd:assigneddelivery> "2:! <ffd:assignbid>! "3:! <ffd:committedpickuptime>! Rete Y1 Example Query:?request?request :req1 2?request,?bid INSERT {?request <tp:7mer_min>?rela7ve7me } WHERE {?request a <ffd:assigneddelivery> ; <ffd:assignbid>?bid.?bid <ffd:commi<edpickuptime>?rela7ve7me }!2?request Y2?bid,?relativetime Process flow: 1 Each condi7on corresponds to an α- node. α1 matches with sample input <:req1> a <ffd:assigneddelivery>. 2 <:req1> propagates to β2 and is stored there. 3 α2 matches with <:req1> <ffd:assignbid> <:bid1>. Input from β2 matches with?request in Y2. 4 <:req1> and <:bid1> propagate un7l β3. 5 α3 matches with input <:bid1> <ffd:commiledpickuptime> "15"^^<xsd:integer>. 6 In Y3 <:req1> and <:bid1> are joined with 15 ^^<xsd:integer> 7 A new triple <:req1> <tp:,mer_min> 15 ^^<xsd:integer> is inserted into the main graph.?request,?bid!3 4 :req1 :bid1?request,?bid 6 :req1 :bid1 15 Y3?request,?relativetime 7 insert1

12 INSTANS Summary Continuous incremental matching using the Retealgorithm No query repetition over windows No RDF or SPARQL extensions needed so far Compatible with current RDF and SPARQL tools Good interoperability in multi-vendor multi-actor environments Support of heterogeneous events Event format can evolve independently of event processing application Based on SPARQL Query + Update Application can be built entirely out of collaborating SPARQL queries Access to linked open data, future possibilities for inference

13 Event Processing with Semantic Web Technologies INSTANS: SPARQL RDF Rete

14 References Rinne, M., Nuutila, E., Törmä, S.: INSTANS: High-Performance Event Processing with Standard RDF and SPARQL. Poster in ISWC2012. Rinne, M., Abdullah, H., Törmä, S., Nuutila, E.: Processing Heterogeneous RDF Events with Standing SPARQL Update Rules. In: Meersman, R., Dillon, T. (eds.) OTM 2012 Conferences, Part II. pp Springer-Verlag (2012) Rinne, M., Törmä, S., Nuutila, E.: SPARQL-Based Applications for RDF-Encoded Sensor Data. In: 5th International Workshop on Semantic Sensor Networks (2012) Abdullah, H., Rinne, M., Törmä, S., Nuutila, E.: Efficient matching of SPARQL subscriptions using Rete. In: Proceedings of the 27th Symposium On Applied Computing (Mar 2012)