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

How to combine event stream reasoning with
transactions for the Semantic Web
Ana Sofia Gomes and José Júlio Alferes
NOVA LINCS, Universidade NOVA de Lisboa,
August 5, 2015
José Alferes (NOVA LINCS) Combining Streams with Transactions August 5, 2015 1 / 16

Example: Acting upon traﬃc violations
Consider a scenario where the police wants to monitor, detect and act
upon traﬃc 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 traﬃc violations

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

Required Ingredients
The sensor network (of course!)

Data published by the sensors in some processable way

Combining data from diﬀerent 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 traﬃc
violations

E.g. publish data in RDF
violations

Semantic Sensor Web ontologies
violations

Complex event detection languages
violations

Ontologies (e.g. in OWL)
violations

Ontologies (e.g. in OWL)
violations
Event-Condition-Action rules

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

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

Our goal
Goal
Combine in a declarative, rule-based language all the above described
requirements:
detection of complex events
combining events with ontological data
deﬁnition of reactive rules
ability to deﬁne transactions

Our goal
Goal
Combine in a declarative, rule-based language all the above described
requirements:
detection of complex events
combining events with ontological data
deﬁnition of reactive rules
ability to deﬁne transactions
We do this based on an extension of Transaction Logic, called T Rev

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 diﬀerent semantics of state change
Reasoning about what primitives are true in a state, and state
transitions is outsourced to Oracles

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

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

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

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

Example
{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
r(e1) ← c.ins
o(e1) ← o(b.ins)

Example
{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
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

Interpretations and states
Deﬁnition (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 )

Interpretations and states
Deﬁnition (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 deﬁnition 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

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.

Deﬁnition (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 iﬀ 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)}

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) ∈
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) ∈

Example in T Rev
Application speciﬁc 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 .

Example in T Rev
Deﬁnition of transactions
processViolation(P, DT, V) ← fineCost(V, Cost) ⊗ isDriver(P, D)⊗
fineIssued(P, D, DT, Cost).ins ⊗ notifyFine(P, D, DT, Cost)

Example in T Rev
Deﬁnition 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)

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:dateTime DT2).ins) ∧ o((Obs2 ov:readBy sensor1).ins))]
∧ (DT1 < DT2)

Example in T Rev
Event Detection
o(passingWrongWay(P, DT1)) ←
∧ o((Obs1 ov:dateTime DT1).ins) ∧ o((Obs1 ov:readBy sensor2).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)

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.

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 : dateTime 1426325213516 ;

ov : dateTime 1426325213000 ;
ov : dateTime 1426325213516 ;
Since, from the ontology, heavyVehicle vehicle,
o((ov:obs1 ov:vehicleDetected motorVehicle).ins) holds in the
same transition as o((ov:obs1).ins)

ov : dateTime 1426325213000 ;
ov : dateTime 1426325213516 ;
Similarly o((ov:obs2 ov:vehicleDetected motorVehicle).ins)
holds together with o((ov:obs1).ins)

ov : dateTime 1426325213000 ;
ov : dateTime 1426325213516 ;
So, o(passingWrongWay("01-01-AA", 1426325213000) holds in the
same transition where actions (ov:obs1).ins ⊗ (ov:obs2).ins occur

ov : dateTime 1426325213000 ;
ov : dateTime 1426325213516 ;
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 ﬁned and notiﬁed for the infraction of
passing the road in the wrong way

Conclusions
We proposed a set of oracle instantiations to make T Rev
useful for
domains involving sensor networks and Semantic Web technologies

Conclusions
useful for
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

Conclusions
useful for
to these events
As in stream reasoning, we can use the domain’s application
knowledge to reason about what complex events occur

Conclusions
useful for
to these events
All this is done by a single rule-based language, with a clearly deﬁned
declarative semantics

Conclusions
useful for
to these events
All this is done by a single rule-based language, with a clearly deﬁned
declarative semantics
The semantics is equipped with correct proof procedures that serve as
basis for implementations (cf. presentation this morning in RR)

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

More Related Content

Viewers also liked

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

More from RuleML

Recently uploaded

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