Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

RuleML2015: How to combine event stream reasoning with transactions for the Semantic Web

963 views

Published on

Semantic Sensor Web is a new trend of research integrating
Semantic Web technologies with sensor networks. It uses Semantic Web
standards to describe both the data produced by the sensors, but also
the sensors and their networks, which enables interoperability of sensor
networks, and provides a way to formally analyze and reason about these
networks. Since sensors produce data at a very high rate, they require
solutions to reason efficiently about what complex events occur based on
the data captured. In this paper we propose T Rev as a solution to combine
the detection of complex events with the execution of transactions
for these domains. T Rev is an abstract logic to model and execute reactive
transactions. The logic is parametric on a pair of oracles defining the
basic primitives of the domain, which makes it suitable for a wide range
of applications. In this paper we provide oracle instantiations combining
RDF/OWL and relational database semantics for T Rev. Afterwards,
based on these oracles, we illustrate how T Rev can be useful for these
domains.

Published in: Science
  • Be the first to comment

RuleML2015: How to combine event stream reasoning with transactions for the Semantic Web

  1. 1. How to combine event stream reasoning with transactions for the Semantic Web Ana Sofia Gomes and Jos´e J´ulio Alferes NOVA LINCS, Universidade NOVA de Lisboa, August 5, 2015 Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 1 / 16
  2. 2. Example: Acting upon traffic violations Consider a scenario where the police wants to monitor, detect and act upon traffic violations based on a sensor network deployed in roads A sensor in such a network can identify plates of vehicles and distinguish between types of vehicles Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 2 / 16
  3. 3. Example: Acting upon traffic violations Consider a scenario where the police wants to monitor, detect and act upon traffic violations based on a sensor network deployed in roads A sensor in such a network can identify plates of vehicles and distinguish between types of vehicles Based on the information that is published by sensors, and information about vehicles, the system must reason about what vehicles are indulging in traffic violations Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 2 / 16
  4. 4. Example: Acting upon traffic violations Consider a scenario where the police wants to monitor, detect and act upon traffic violations based on a sensor network deployed in roads A sensor in such a network can identify plates of vehicles and distinguish between types of vehicles Based on the information that is published by sensors, and information about vehicles, the system must reason about what vehicles are indulging in traffic violations For vehicles found to be violating traffic rules, the system must issue fines and notify the corresponding drivers Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 2 / 16
  5. 5. Required Ingredients The sensor network (of course!) Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 3 / 16
  6. 6. Required Ingredients The sensor network (of course!) Data published by the sensors in some processable way Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 3 / 16
  7. 7. Required Ingredients The sensor network (of course!) Data published by the sensors in some processable way Combining data from different types of sensors, for interoperability Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 3 / 16
  8. 8. Required Ingredients The sensor network (of course!) Data published by the sensors in some processable way Combining data from different types of sensors, for interoperability Detecting complex events, based on atomic data from sensors Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 3 / 16
  9. 9. Required Ingredients The sensor network (of course!) Data published by the sensors in some processable way Combining data from different types of sensors, for interoperability Detecting complex events, based on atomic data from sensors Reasoning with sensor data together with data about vehicles, vehicles types, kinds of violations, etc Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 3 / 16
  10. 10. Required Ingredients The sensor network (of course!) Data published by the sensors in some processable way Combining data from different types of sensors, for interoperability Detecting complex events, based on atomic data from sensors Reasoning with sensor data together with data about vehicles, vehicles types, kinds of violations, etc Expressing rules describing how to act upon the detection of traffic violations Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 3 / 16
  11. 11. Required Ingredients The sensor network (of course!) Data published by the sensors in some processable way E.g. publish data in RDF Combining data from different types of sensors, for interoperability Detecting complex events, based on atomic data from sensors Reasoning with sensor data together with data about vehicles, vehicles types, kinds of violations, etc Expressing rules describing how to act upon the detection of traffic violations Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 3 / 16
  12. 12. Required Ingredients The sensor network (of course!) Data published by the sensors in some processable way E.g. publish data in RDF Combining data from different types of sensors, for interoperability Semantic Sensor Web ontologies Detecting complex events, based on atomic data from sensors Reasoning with sensor data together with data about vehicles, vehicles types, kinds of violations, etc Expressing rules describing how to act upon the detection of traffic violations Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 3 / 16
  13. 13. Required Ingredients The sensor network (of course!) Data published by the sensors in some processable way E.g. publish data in RDF Combining data from different types of sensors, for interoperability Semantic Sensor Web ontologies Detecting complex events, based on atomic data from sensors Complex event detection languages Reasoning with sensor data together with data about vehicles, vehicles types, kinds of violations, etc Expressing rules describing how to act upon the detection of traffic violations Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 3 / 16
  14. 14. Required Ingredients The sensor network (of course!) Data published by the sensors in some processable way E.g. publish data in RDF Combining data from different types of sensors, for interoperability Semantic Sensor Web ontologies Detecting complex events, based on atomic data from sensors Complex event detection languages Reasoning with sensor data together with data about vehicles, vehicles types, kinds of violations, etc Ontologies (e.g. in OWL) Expressing rules describing how to act upon the detection of traffic violations Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 3 / 16
  15. 15. Required Ingredients The sensor network (of course!) Data published by the sensors in some processable way E.g. publish data in RDF Combining data from different types of sensors, for interoperability Semantic Sensor Web ontologies Detecting complex events, based on atomic data from sensors Complex event detection languages Reasoning with sensor data together with data about vehicles, vehicles types, kinds of violations, etc Ontologies (e.g. in OWL) Expressing rules describing how to act upon the detection of traffic violations Event-Condition-Action rules Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 3 / 16
  16. 16. Reactivity Reactivity: the ability to detect and react to changes On event if condition then action Basic Premisses Events can be complex Actions can be complex Events need to be handled as soon as possible Actions may trigger events and indirectly execute other actions Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 4 / 16
  17. 17. Reactivity Reactivity: the ability to detect and react to changes On event if condition then action Basic Premisses Events can be complex Actions can be complex Events need to be handled as soon as possible Actions may trigger events and indirectly execute other actions Actions can be defined as a transaction In our example, issuing a fine and notifying the driver must be defined as a transaction it can never be the case that the fine is issued and the driver is not notified, nor vice-versa Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 4 / 16
  18. 18. Our goal Goal Combine in a declarative, rule-based language all the above described requirements: detection of complex events combining events with ontological data definition of reactive rules ability to define transactions Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 5 / 16
  19. 19. Our goal Goal Combine in a declarative, rule-based language all the above described requirements: detection of complex events combining events with ontological data definition of reactive rules ability to define transactions We do this based on an extension of Transaction Logic, called T Rev Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 5 / 16
  20. 20. Transaction Logic Abstract logic to reason about how a transaction executes Evaluates complex formulas over paths P, D1, . . . , Dn |= φ φ can execute transactionally in program P, over the path D1, . . . , Dn φ causes the Knowledge Base to evolve from state D1 into state Dn Finds the paths where formulas can execute transactionally Transactions and states are abstract T R can use several different semantics of state change Reasoning about what primitives are true in a state, and state transitions is outsourced to Oracles Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 6 / 16
  21. 21. Transaction Logic Can reason about transactions Can also reason about complex events reason about what events have become true in a path P, D1, . . . , Dn |= φ φ occurs over the path D1, . . . , Dn (almost) as expressible as SNOOP’s event algebra (more details in the paper) What is Missing? Reactivity: the ability to reason and react to events T R can reason about transactions and events individually, but not with both simultaneously Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 7 / 16
  22. 22. Transaction Logic with Events (T Rev ) Extends T R with the ability to detect and react to complex events Key Concepts formulas are partitioned into transactions and events transaction formulas depend on what event formulas are true transactions only succeed on paths where all events are responded as a transaction Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 8 / 16
  23. 23. Transaction Logic with Events (T Rev ) Extends T R with the ability to detect and react to complex events Key Concepts formulas are partitioned into transactions and events transaction formulas depend on what event formulas are true transactions only succeed on paths where all events are responded as a transaction if an event is triggered during a transaction, the transaction is expanded with the event response if the event formula o(e) is true on a path π, then this path needs to be expanded with the execution of the transaction r(e) non-monotonic behavior Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 8 / 16
  24. 24. Example p ← a.ins ⊗ b.ins {a} r(e1) {} a.ins o(a.ins) {a, b} {a, b, c} c.inso(e1) o(b.ins) o(c.ins) {a}{} a.ins p o(a.ins) {a, b} o(b.ins) b.ins Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 9 / 16
  25. 25. Example p ← a.ins ⊗ b.ins {a} r(e1) {} a.ins o(a.ins) {a, b} {a, b, c} c.inso(e1) o(b.ins) o(c.ins) {a}{} a.ins p o(a.ins) {a, b} o(b.ins) b.ins p ← a.ins ⊗ b.ins r(e1) ← c.ins o(e1) ← o(b.ins) Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 9 / 16
  26. 26. Example p ← a.ins ⊗ b.ins {a} r(e1) {} a.ins o(a.ins) {a, b} {a, b, c} c.inso(e1) o(b.ins) o(c.ins) {a}{} a.ins p o(a.ins) {a, b} o(b.ins) b.ins p ← a.ins ⊗ b.ins r(e1) ← c.ins o(e1) ← o(b.ins) {a} r(e1) {} a.ins p o(a.ins) {a, b} {a, b, c} c.inso(e1) o(b.ins) o(c.ins) b.ins {a}{} a.ins o(a.ins) { o(e1) o(b.ins) b.ins Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 9 / 16
  27. 27. Interpretations and states Definition (Interpretation) An interpretation M is a mapping assigning a set of atoms to every possible path, with the restrictions (where Di s are states, and ϕ an atom): ϕ ∈ M( D ) if ϕ ∈ Od (D) {ϕ, o(ϕ)} ⊆ M( D1 o(ϕ)→D2 ) if ϕ ∈ Ot(D1, D2) ∧ ϕ ∈ POa o(ϕ) ∈ M( D1 o(ϕ)→D2 ) if o(ϕ) ∈ Ot(D1, D2) ∧ o(ϕ) ∈ POe o(e) ∈ M( D o(e)→D ) Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 10 / 16
  28. 28. Interpretations and states Definition (Interpretation) An interpretation M is a mapping assigning a set of atoms to every possible path, with the restrictions (where Di s are states, and ϕ an atom): ϕ ∈ M( D ) if ϕ ∈ Od (D) {ϕ, o(ϕ)} ⊆ M( D1 o(ϕ)→D2 ) if ϕ ∈ Ot(D1, D2) ∧ ϕ ∈ POa o(ϕ) ∈ M( D1 o(ϕ)→D2 ) if o(ϕ) ∈ Ot(D1, D2) ∧ o(ϕ) ∈ POe o(e) ∈ M( D o(e)→D ) The definition of states depends on the application at hands, and their meaning is formalised by the oracles Od and Ot in the examples of the previous slide, states Di are simply sets of atoms in our motivating example, states are RDF graphs Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 10 / 16
  29. 29. Oracles for RDF graphs Definition (RDF data Oracle) A state is an RDF graph G, i.e., a set of RDF triples of the form (s p o) together with an OWL ontology. The data oracle (Od ) is defined such that Od (G) |= (s p o) iff (s p o) ∈ Closure(G), where Closure(G) is the closure of the graph under the ontology. Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 11 / 16
  30. 30. Oracles for RDF graphs Definition (RDF data Oracle) A state is an RDF graph G, i.e., a set of RDF triples of the form (s p o) together with an OWL ontology. The data oracle (Od ) is defined such that Od (G) |= (s p o) iff (s p o) ∈ Closure(G), where Closure(G) is the closure of the graph under the ontology. Definition (RDF transition Oracle) Let g1 be an RDF graph, i.e., a set of RDF triples of the form (s p o). Ot(D1, D2) |= g1.ins iff both statements are true: D2 = D1 ∪ {(s p o) : (s p o) ∈ g1} and; Ot(D1, D2) = {g1.ins} ∪ {o((s p o).ins) : (s p o) ∈ Closure(D2)Closure(D1)} Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 11 / 16
  31. 31. Oracles for RDF graphs Definition (RDF data Oracle) A state is an RDF graph G, i.e., a set of RDF triples of the form (s p o) together with an OWL ontology. The data oracle (Od ) is defined such that Od (G) |= (s p o) iff (s p o) ∈ Closure(G), where Closure(G) is the closure of the graph under the ontology. Definition (RDF transition Oracle) Let g1 be an RDF graph, i.e., a set of RDF triples of the form (s p o). Ot(D1, D2) |= g1.ins iff both statements are true: D2 = D1 ∪ {(s p o) : (s p o) ∈ g1} and; Ot(D1, D2) = {g1.ins} ∪ {o((s p o).ins) : (s p o) ∈ Closure(D2)Closure(D1)} Ot(D1, D2) |= g1.del iff both statements are true: D2 = D1 ∩ {(s p o) : (s p o) ∈ g1} and; Ot(D1, D2) = {g1.del} ∪ {o((s p o).del) : (s p o) ∈ Closure(D1)Closure(D2)} Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 11 / 16
  32. 32. Example in T Rev Application specific RDF data ov : vehicle rdf : type owl : Class . ov : motorVehicle rdfs : subClassOf ov : vehicle . ov : lightVehicle rdfs : subClassOf ov : motorVehicle . ov : heavyVehicle rdfs : subClassOf ov : vehicle . ov : sensor rdf : type owl : Class . ov : sensor1 rdf : type ov : sensor . ov : sensor2 rdf : type ov : sensor . Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 12 / 16
  33. 33. Example in T Rev Application specific RDF data ov : vehicle rdf : type owl : Class . ov : motorVehicle rdfs : subClassOf ov : vehicle . ov : lightVehicle rdfs : subClassOf ov : motorVehicle . ov : heavyVehicle rdfs : subClassOf ov : vehicle . ov : sensor rdf : type owl : Class . ov : sensor1 rdf : type ov : sensor . ov : sensor2 rdf : type ov : sensor . Definition of transactions processViolation(P, DT, V) ← fineCost(V, Cost) ⊗ isDriver(P, D)⊗ fineIssued(P, D, DT, Cost).ins ⊗ notifyFine(P, D, DT, Cost) Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 12 / 16
  34. 34. Example in T Rev Application specific RDF data ov : vehicle rdf : type owl : Class . ov : motorVehicle rdfs : subClassOf ov : vehicle . ov : lightVehicle rdfs : subClassOf ov : motorVehicle . ov : heavyVehicle rdfs : subClassOf ov : vehicle . ov : sensor rdf : type owl : Class . ov : sensor1 rdf : type ov : sensor . ov : sensor2 rdf : type ov : sensor . Definition of transactions processViolation(P, DT, V) ← fineCost(V, Cost) ⊗ isDriver(P, D)⊗ fineIssued(P, D, DT, Cost).ins ⊗ notifyFine(P, D, DT, Cost) notifyFine(P, D, DT, Cost) ← hasAddress(D, Addr)⊗ sendLetter(D, Addr, P, DT, Cost) Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 12 / 16
  35. 35. Example in T Rev Event Detection o(passingWrongWay(P, DT1)) ← [o((Obs1 ov:plateRead P).ins) ∧ o((Obs1 ov:vehicleDetected motorVehicle).ins) ∧ o((Obs1 ov:dateTime DT1).ins) ∧ o((Obs1 ov:readBy sensor2).ins)] ⊗ [o((Obs2 ov:plateRead P).ins) ∧ o((Obs2 ov:vehicleDetected motorVehicle).ins) ∧ o((Obs2 ov:dateTime DT2).ins) ∧ o((Obs2 ov:readBy sensor1).ins))] ∧ (DT1 < DT2) Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 13 / 16
  36. 36. Example in T Rev Event Detection o(passingWrongWay(P, DT1)) ← [o((Obs1 ov:plateRead P).ins) ∧ o((Obs1 ov:vehicleDetected motorVehicle).ins) ∧ o((Obs1 ov:dateTime DT1).ins) ∧ o((Obs1 ov:readBy sensor2).ins)] ⊗ [o((Obs2 ov:plateRead P).ins) ∧ o((Obs2 ov:vehicleDetected motorVehicle).ins) ∧ o((Obs2 ov:dateTime DT2).ins) ∧ o((Obs2 ov:readBy sensor1).ins))] ∧ (DT1 < DT2) Event Response r(passingWrongWay(P, DT)) ← processViolation(P, DT, wrongWay) Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 13 / 16
  37. 37. Example in T Rev Usage Prove statements of the form: P, S1– |= (ov:obs1).ins ⊗ (ov:obs2).ins . . . where S1 is the initial RDF graph and obsi are the RDF triples observed at each moment. Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 14 / 16
  38. 38. Behaviour in a concrete situation ov : obs1 rdf : type ov : Observation ; ov : plateRead "01-01-AA" ; ov : dateTime 1426325213000 ; ov : vehicleDetected ov : heavyVehicle ; ov : readBy ov : sensor1 . ov : obs2 rdf : type ov : Observation ; ov : plateRead "01-01-AA" ; ov : dateTime 1426325213516 ; ov : vehicleDetected ov : heavyVehicle ; ov : readBy ov : sensor2 . Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 15 / 16
  39. 39. Behaviour in a concrete situation ov : obs1 rdf : type ov : Observation ; ov : plateRead "01-01-AA" ; ov : dateTime 1426325213000 ; ov : vehicleDetected ov : heavyVehicle ; ov : readBy ov : sensor1 . ov : obs2 rdf : type ov : Observation ; ov : plateRead "01-01-AA" ; ov : dateTime 1426325213516 ; ov : vehicleDetected ov : heavyVehicle ; ov : readBy ov : sensor2 . Since, from the ontology, heavyVehicle vehicle, o((ov:obs1 ov:vehicleDetected motorVehicle).ins) holds in the same transition as o((ov:obs1).ins) Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 15 / 16
  40. 40. Behaviour in a concrete situation ov : obs1 rdf : type ov : Observation ; ov : plateRead "01-01-AA" ; ov : dateTime 1426325213000 ; ov : vehicleDetected ov : heavyVehicle ; ov : readBy ov : sensor1 . ov : obs2 rdf : type ov : Observation ; ov : plateRead "01-01-AA" ; ov : dateTime 1426325213516 ; ov : vehicleDetected ov : heavyVehicle ; ov : readBy ov : sensor2 . Since, from the ontology, heavyVehicle vehicle, o((ov:obs1 ov:vehicleDetected motorVehicle).ins) holds in the same transition as o((ov:obs1).ins) Similarly o((ov:obs2 ov:vehicleDetected motorVehicle).ins) holds together with o((ov:obs1).ins) Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 15 / 16
  41. 41. Behaviour in a concrete situation ov : obs1 rdf : type ov : Observation ; ov : plateRead "01-01-AA" ; ov : dateTime 1426325213000 ; ov : vehicleDetected ov : heavyVehicle ; ov : readBy ov : sensor1 . ov : obs2 rdf : type ov : Observation ; ov : plateRead "01-01-AA" ; ov : dateTime 1426325213516 ; ov : vehicleDetected ov : heavyVehicle ; ov : readBy ov : sensor2 . Since, from the ontology, heavyVehicle vehicle, o((ov:obs1 ov:vehicleDetected motorVehicle).ins) holds in the same transition as o((ov:obs1).ins) Similarly o((ov:obs2 ov:vehicleDetected motorVehicle).ins) holds together with o((ov:obs1).ins) So, o(passingWrongWay("01-01-AA", 1426325213000) holds in the same transition where actions (ov:obs1).ins ⊗ (ov:obs2).ins occur Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 15 / 16
  42. 42. Behaviour in a concrete situation ov : obs1 rdf : type ov : Observation ; ov : plateRead "01-01-AA" ; ov : dateTime 1426325213000 ; ov : vehicleDetected ov : heavyVehicle ; ov : readBy ov : sensor1 . ov : obs2 rdf : type ov : Observation ; ov : plateRead "01-01-AA" ; ov : dateTime 1426325213516 ; ov : vehicleDetected ov : heavyVehicle ; ov : readBy ov : sensor2 . Since, from the ontology, heavyVehicle vehicle, o((ov:obs1 ov:vehicleDetected motorVehicle).ins) holds in the same transition as o((ov:obs1).ins) Similarly o((ov:obs2 ov:vehicleDetected motorVehicle).ins) holds together with o((ov:obs1).ins) So, o(passingWrongWay("01-01-AA", 1426325213000) holds in the same transition where actions (ov:obs1).ins ⊗ (ov:obs2).ins occur Thus (ov:obs1).ins ⊗ (ov:obs2).ins only success in a path where the driver of vehicle "01-01-AA" is fined and notified for the infraction of passing the road in the wrong way Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 15 / 16
  43. 43. Conclusions We proposed a set of oracle instantiations to make T Rev useful for domains involving sensor networks and Semantic Web technologies Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 16 / 16
  44. 44. Conclusions We proposed a set of oracle instantiations to make T Rev useful for domains involving sensor networks and Semantic Web technologies We’ve shown how T Rev can be used to reason about what complex events occur, and what transactions need to be executed to respond to these events Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 16 / 16
  45. 45. Conclusions We proposed a set of oracle instantiations to make T Rev useful for domains involving sensor networks and Semantic Web technologies We’ve shown how T Rev can be used to reason about what complex events occur, and what transactions need to be executed to respond to these events As in stream reasoning, we can use the domain’s application knowledge to reason about what complex events occur Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 16 / 16
  46. 46. Conclusions We proposed a set of oracle instantiations to make T Rev useful for domains involving sensor networks and Semantic Web technologies We’ve shown how T Rev can be used to reason about what complex events occur, and what transactions need to be executed to respond to these events As in stream reasoning, we can use the domain’s application knowledge to reason about what complex events occur All this is done by a single rule-based language, with a clearly defined declarative semantics Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 16 / 16
  47. 47. Conclusions We proposed a set of oracle instantiations to make T Rev useful for domains involving sensor networks and Semantic Web technologies We’ve shown how T Rev can be used to reason about what complex events occur, and what transactions need to be executed to respond to these events As in stream reasoning, we can use the domain’s application knowledge to reason about what complex events occur All this is done by a single rule-based language, with a clearly defined declarative semantics The semantics is equipped with correct proof procedures that serve as basis for implementations (cf. presentation this morning in RR) Jos´e Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 16 / 16

×