RDFTL: An EventConditionAction Language for RDF

About This Presentation

Title:

RDFTL: An EventConditionAction Language for RDF

Description:

RDFTL: An Event-Condition-Action Language for RDF. George Papamarkos. Alexandra Poulovassilis. Peter T. Wood. School of Computer Science and Information Systems ... – PowerPoint PPT presentation

Number of Views:36

Avg rating:3.0/5.0

Slides: 20

Provided by: GDP4

Category:

more less

Transcript and Presenter's Notes

Title: RDFTL: An EventConditionAction Language for RDF

1
RDFTL An Event-Condition-Action Language for RDF

George Papamarkos
Alexandra Poulovassilis
Peter T. Wood
School of Computer Science and Information
Systems
Birkbeck University of London

2
Introduction

RDF is one of the technologies emerging to
realise the vision of the Semantic Web
The use of RDF in dynamic applications that
require timely notification of metadata changes
raises the need for mechanisms for monitoring and
reacting to such changes
Event-Condition-Action Rules are a natural
candidate to fulfill these needs
This paper presents a language for defining ECA
rules on RDF repositories, focusing on syntax,
semantics, and an implementation architecture for
centralised and distributed environments

3
Introduction

This work has been largely motivated by our work
on the SeLeNe project (www.dcs.bbk.ac.uk/selene/)
Its goal is to investigate techniques for
managing evolving RDF repositories of educational
metadata, and providing a syndication and
personalisation services over such repositories
Peers in a SeLeNe (self e-learning network) store
RDF/S descriptions relating to learning objects
(LOs) registered with the SeLeNe and also
relating to users of the SeLeNe

4
Introduction

A SeLeNe may be deployed in a centralised or
distributed environment
In a centralised environment one peer server
manages all RDF/S descriptions in a distributed
environment each peer manages some fragment
SeLeNes reactive functionality, to be provided
by ECA rules, includes
automatic notification to users of the
registration of new LOs of interest to them
automatic notification to users of changes in the
description of LOs of interest to them
automatic propagation of changes in the
description of one resource to other, related,
resources

5
The RDFTL Language

Event Part
(INSERT DELETE) e where e is a path expression
that evaluates to a set of nodes. The rule is
triggered if this set of nodes contains a
new/deleted node. The variable delta has as its
set of instantiations the new/deleted nodes
(INSERT DELETE UPDATE) triple The rule is
triggered if an arc matching triple is inserted,
deleted or updated. The variable delta has as
its set of instantiations the source nodes of
arcs that have triggered the rule

6
The RDFTL Language

Condition Part
Consists of conjunctions, disjunctions and
negations of path expressions, which may
reference the delta variable. The rule fires if
this expression evaluates to true.
Actions
(INSERT DELETE) e Inserts/deletes resource(s)
specified by e
(INSERT DELETE UPDATE) triple
Inserts/deletes/updates an arc specified by
triple

7
Example of LO Metadata
8
Example of User Metadata
9
Example RDFTL rule

ON INSERT resource()target(dctype)Book/
target(bbkannotation)/
element()target(dctype)Review
IF delta/source()/source()
target(dcsubject)Computer Science
DO LET reviews
resource(http//www.dcs.bbk.ac.uk/users
/128)/
target(bbkreview) IN
INSERT (reviews, seq, delta)
Event Part Checks if a review has been added
for a book
Condition Part Holds if the subject of the
book is CS
Action Part Inserts a new edge between user
128s reviews collection and the new review.

10
RDFTL Deployment

Deployment of RDFTL may be in a centralised,
mediated or P2P environment see the paper for a
discussion of the first two
In a P2P environment, we assume a super-peer
architecture where each super-peer server may be
coordinating a group of peer servers, as well as
itself possibly hosting a fragment of the RDF/S
metadata
At each SP there is an installation of the ECA
Engine

11
RDFTL Implementation

See paper for details of syntax, path query
semantics, and rule execution semantics
An RDFTL ECA Engine provides an active wrapper
over a passive RDF repository, exploiting the
query, storage and update functionality of the
repository (currently RDFSuite from ICS-FORTH)
The ECA Engine consists of a rule interpretor,
event detector, condition evaluator and action
scheduler

12
Registering an ECA rule

ECA rules are generated by application services
running at peers
When a new rule is generated at a peer, it is
sent to the super-peer for storage
There, the event/condition/action parts of the
rule are annotated with the local peers that are
relevant to the rule
This is determined by keeping an index at each
peer and super-peer

13
Peer/Super Peer Indexes

Each peer maintains an annotated copy of its
local RDF Schema, with 0 and 1 indicating
whether or not a node has data of this type at
this peer
This information is also propagated to the peers
SP where a combined annotated RDF Schema is
maintained from all peers in this SPs peer group
and also the remote SPs with which this SP is
connected
Any change of in the annotation of an SPs schema
is propagated to its neighbouring SPs
Each SP also keeps for each node annotated with a
1 in its schema a resource index i.e. a list of
the resources of this type referenced by its peer
group

14
Indexing in Peers and Super Peers
SP1
SP2
Local annotated RDFS
P1
0
1
1
1
1
1
Combined annotated RDFS
P2
r1,r2,r4
Local annotated RDFS
15
Registering an ECA rule (contd)

An new ECA rule registered at a SP is also sent
to all neighbouring SPs that may be relevant to
it determined from the SP ID annotations on the
originating SPs schema
These SPs repeat the process of matching each
part of the rule against their schemas and
storing the rule in their rule base if it is
relevant to any of their peer group

16
Maintaining the Rule Bases

If a peer changes a schema node annotation from
1 to 0 this information is propagated to its
SP
The annotation of each rule in SPs rule base is
updated
If as a result there is a rule which is no longer
relevant to this peer group it can be deactivated
in SPs rule base (not deleted, as it may later
become relevant again)

17
Maintaining the Rule Bases

If a peer changes a schema node annotation from
0 to 1 this information is again propagated
to its SP and each rule in SPs rule base is
again updated
If the schema at the SP now has a node whose
annotation has changed from 0 to 1 this is
notified to the SPs neighbours
They send to the SP their ECA rules which are
relevant to the change. They also recursively
request from their neighbours such rules, and
propagate such rules back to the SP

18
Rule triggering and execution

If an event E occurs at a peer P, this notifies
its SP
The SP determines if E may trigger a rule
annotated with Ps ID
If so, it sends P the rules event query to
evaluate (this may involve distributed query
processing)
If the condition is true, the SP generates the
necessary messages from the actions part of the
rule for distributed action execution

19
Ongoing Work

Developing algorithms for matching rule event,
condition and action part with schema indexes
Defining the message syntax between peers.
Defining coordination with query processing
Producing a prototype implementation
Experimantation/evaluation/evolution
Transactional aspects of ECA rules in P2P
environments

Write a Comment

User Comments (0)