1. Event-Condition-Action rules for the Semantic Web Alex Poulovassilis, Birkbeck, U. of London
March 2006

2. Overview Reactivity over XML and RDF The SeLeNe project
XML ECA Language
RDFTL – an RDF ECA Language
March 2006

3. 1. Reactivity over XML and RDF
standards for storing and exchanging information on the World Wide Web
being increasingly used in distributed web-based applications in areas such as e-business, e-science, e-learning and e-government
such applications may need to be reactive
ECA rules are one way of providing this kind of functionality
in these distributed web-based applications, rules are likely not to be hand-crafted but automatically generated by higher-level presentation and application services
c.f. as in the SeLeNe project
March 2006

4. 2. The SeLeNe project
AN EU FP5 project that ran from 1st November 2002 to 31st January 2004
Has fed into L4All (JISC), Trails (EU) and iClass (EU) projects
Project partners:
Birkbeck
Institute of Education
Foundation for Research and Technology Hellas, Crete (ICS-FORTH)
Laboratoire de Recherche en Informatique (LRI), Paris
University of Cyprus (UCY)
March 2006

5. Motivation for SeLeNe
There are a huge number of learning resources now available on the Web
There are diverse communities of learners, geographically distributed and with a range of educational backgrounds and learning needs
Tools are needed to allow the discovery, sharing and collaborative creation of learning resources
Semantic metadata describing these resources can enable advanced services more powerful than traditional Web techniques
March 2006

6. What is a Self e-Learning Network (SeLeNe)?
Extensive user requirements specification was one of the first parts of the project, defining a SeLeNe’s functionality
A SeLeNe is formed by members of a learning community
instructors, learners and providers (authors)
The community creates a collection of shared Learning Objects (LOs) and their RDF metadata descriptions
Users register and share a LO by providing a metadata description of it; some parts of the metadata can be automatically generated
SeLeNe manages the RDF descriptions, not the LOs themselves
There are also metadata descriptions of a SeLeNe’s learners
March 2006

7. SeLeNe’s Service Architecture
We defined a service-based architecture that provides the full system functionality
There are various deployment options, the most general of which allows the services to be distributed across several sites in a Grid architecture
The project focussed on the services for LO Registration, View and Query Services, Trails & Adaptation, and Event & Change Notification
March 2006

8. Self e-learning Network
IEEE LOM
Custom Sch.
Program
Module
Course
SITE
Lesson
SITE
Self e-learning Network
SITE
PEER
SITE LO
Objectives
SITE
ACM CSS
SITE
SITE
CSCourses
SITE
Lesson
AICourses
ppt
SITE
March 2006

9. LO Metadata Standards, Ontologies LO Metadata Learning Objects
<tag1>
<tag2>
<tag3>
</tag1>
Learning Objects
This slide is adapted from an earlier presentation by Vassilis Christophides – thank you Vassilis!
Vassilis!
March 2006

10. Personalisation in SeLeNe
There are many LOs available to users of a SeLeNe; some will be useful for them and others will not
Personalised access to LOs provides learners with tools to aid the sharing and discovery of useful LOs:
LO registration: Taxonomical descriptions of new LOs are based on the authors’ taxonomical descriptions of the component parts
Views: Learners can browse the LO information space according to the attributes of personal interest to them
Queries: Learners are presented with LOs relevant to their needs
Notification: Learners are notified of the updates and additions to the SeLeNe information space that are relevant to them
March 2006

11. Queries – the SeLeNe Learner Profile (BBK/IoE)
Personalised querying is made possible by the SeLeNe Learner Profile. This includes
Some elements from existing profile metadata schemas: PAPI-Learner, IMS-LIP and IMS-RCD
Some additional SeLeNe metadata elements to record competencies, learning goals and learning styles
An additional history of user activity that will allow the user profile to change over time, automatically being updated by means of a generic set of ECA rules associated with SeLeNe profiles
An additional messages property with a Notifications class as target, for storing personal notifications of new/updated LOs or new users
March 2006

12. The SeLeNe Learner Profile
March 2006

13. Event and Change Notification (BBK)
Presentation and application services may generate Event-Condition-Action (ECA) rules, from appropriate user input, which act over the distributed RDF/S repository like traditional database triggers
Such rules enable notification of
the registration of new LOs of interest to a user
changes to descriptions of particular LOs of interest to them
propagating changes in the taxonomical description of a LO to any composite LOs depending on it
propagating changes in a user’s history of accesses to LOs to the user’s personal profile
March 2006

14. 3. XML ECA Language
we had already designed an XML ECA rule language that uses fragments of XPath and XQuery in the event, condition and action parts (Bailey, Poulovassilis, Wood; WWW 2002)
this work also included the development of conservative techniques for analysing the triggering and activation relationships between such rules
the paper discusses the challenges we faced, in areas such as:
event semantics
action semantics
rule analysis
the paper also compares our language with related work such as Active XQuery and Active XML
The next development plan towards improving the current system implementation, will include deploying the system as a web service and creating a web-based demo of the system under a predefined set of files. The web services will be callable via simple HTTP POST requests and will allow the user to register new rules to the rule base, and perform update actions to the underlying XML data, that, may, in turn, cause some rules to fire. For the future, we plan to add WebDAV support, so as to allow the users to upload their own XML data and monitor their changes using their own rules. The implementation of the system implementing the XML ECA language, will soon be publicly available for every use under the terms of GNU General Public Licence.
March 2006

15. XML ECA Language
we implemented this language in the earlier stages of the SeLeNe project, using DOM over flat files (Bailey, Papamarkos, Poulovassilis, Wood; Web Dynamics 2004, Springer)
the architecture consists of
a rule parser and rule base,
an execution engine (event detector, condition evaluator and action scheduler) and an execution schedule,
a wrapper for interacting with the underlying XML files
the implementation will shortly be made available under the GNU general public licence; plus also a web-based demo of it
this language can also be used also RDF that has been serialised as XML; but we have also developed a new language for RDF ECA rules – RDFTL
The next development plan towards improving the current system implementation, will include deploying the system as a web service and creating a web-based demo of the system under a predefined set of files. The web services will be callable via simple HTTP POST requests and will allow the user to register new rules to the rule base, and perform update actions to the underlying XML data, that, may, in turn, cause some rules to fire. For the future, we plan to add WebDAV support, so as to allow the users to upload their own XML data and monitor their changes using their own rules. The implementation of the system implementing the XML ECA language, will soon be publicly available for every use under the terms of GNU General Public Licence.
March 2006

16. 4. RDFTL – an RDF ECA 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 arcs that have triggered the rule. The components of these arcs can be identified by $delta.source, $delta.arcname, $delta.target etc.
March 2006

17. 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
Action Part, consists of one or more actions of the form
(INSERT | DELETE) e inserts/deletes resource(s) specified by e, or
(INSERT | DELETE | UPDATE) triple Inserts/deletes/updates an arc specified by triple
March 2006

18. SeLeNe Information space
Example RDFTL rule
ON INSERT resource() AS INSTANCE OF LearningObject
IF $delta/target(lom:subject)
= resource(
/target(ims-lip:goal)
/target(ims-lip:goal_description)
/target(selene:goal_topic)
DO LET $new_los :=
resource(
/target(selene:messages)/target(selene:new_LOs)
IN INSERT ($new_los,seq++,$delta);;
Checks for triggering event
Checks to see if the condition is met (i.e. if the inserted resource is on the topic of one of user 128’s learning goals)
Carries out the action associated with this rule (i.e. notifies learner 128 that there is a new LO of interest)
SeLeNe Information space
128
Learner
rdf:type
Goal 1
Objective X
goal
goal_ description
C++
goal_ topic
C++Course
Keenoy
LOM: contributedBy
LOM:subject
LOM:subject
Notifications
messages
new_LOs
Notifications
messages
new_LOs
March 2006

19. RDFTL Deployment
Deployment of RDFTL may be in a centralised, mediated or P2P environment
In a P2P environment, we assume a super-peer architecture where each super-peer server may be coordinating a group of peer servers
At each SP there is an installation of the ECA Engine
Each peer or SP hosts a fragment of the overall RDF/S metadata
Each SP’s RDFS schema is a superset of its peergroup’s individual RDFS schemas
The RDF/S metadata stored at a peer may change over time, and it notifies its supervising SP of changes, so that update its schema and its indexes
March 2006

20. RDFTL P2P Deployment
March 2006

21. RDFTL Implementation
See forthcoming Computer Networks 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 interpreter, event detector, condition evaluator and action scheduler
An ECA rule generated at one site of the network might be replicated, triggered, evaluated, and executed at different sites.
Within the event, condition and action parts of ECA rules there might be references to specific RDF resources i.e. ECA rules may be resource-specific or generic
March 2006

22. 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
From there, the rule will also be forwarded to all other superpeers
A replica of it will be stored at those superpeers where an event may occur that may trigger the rule’s event part
This is e-relevance:
r is e-relevant to a schema S if each of the queries that either appear in the event part of r or are used by the event part through variable references, can be evaluated on S, i.e., each step in each path expression exists in S.
March 2006

23. 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 SP’s rule base is updated
If as a result there is a rule which is no longer e-relevant to this peer group it can be deactivated in SP’s rule base
If a peer changes a schema node annotation from `0’ to `1’ this information is again propagated to its SP and each rule in SP’s 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 SP’s 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
March 2006

24. P2P Rule triggering and execution
The RDF graph is fragmented, and possibly replicated, amongst the peers, and each superpeer manages its own local rule execution schedule.
Each superpeer coordinates the execution of transactions that are initiated by that superpeer, or by any peer in its local peergroup.
Whenever an update u is executed at a peer P, P notifies its supervising superpeer SP.
SP determines whether u may trigger any ECA rule in its rule base whose event part is annotated with P's ID.
If a rule r may have been triggered then SP will send r's event query to P to evaluate.
If r has been triggered, its condition will need to be evaluated, after generating an instantiation of it for each value of the $delta variable if this is present in the condition.
March 2006

25. P2P Rule triggering and execution
If a condition evaluates to true, SP will send each instance of r's action part (one if r is a set-oriented rule, and one or more if r is an instance-oriented rule) to the local peers that are a-relevant to it.
All instances of r's actions part will also be sent to all other superpeers of the network.
All superpeers that are a-relevant to r (see paper) will consult their schemas and access privileges to see if the updates they have received can be scheduled and executed on their local peergroup.
In summary, local execution of the update at the head of a local schedule may cause events to occur; these events may cause rules to fire, modifying the local schedule or remote schedules with new updates to be executed
March 2006

26. P2P Rule Processing Performance
We have developed an analytical performance model for our P2P RDFTL rule processing system
We use as the performance criterion the update response time i.e. the mean time complete all rule processing resulting from a top-level update submitted to one of the peers in the network
We have examined how the update response time varies with the network topology, number of peers, number of rules, and degree of data replication between peers
We have also developed a simulation of the system, and similar performance and scalability results are derived from this simulator as for the analytical model
To our knowledge, this is the first time that a P2P ECA rule processing system has been studied from a performance perspective, employing both analytical and simulation methods
March 2006

27. HyperCup vs Full Net, 10% replication, varying peergroups
March 2006

28. HyperCup, replication 90%, varying peergroups
March 2006

29. HyperCup, replication 10%, varying rules
March 2006

30. Simulation, Full Net, replication 10%
March 2006

31. Simulation, HyperCup, 10% and 90% replication
March 2006

32. Simulation, HyperCup, varying rules
For the analytical model, we have used values up to $n=10,000$ and
$n_{rules}=10,000$, with varying $p_s$, and the same linear trends are
observed.
Similar sets of experiments with different settings of the fixed parameters
have also been conducted and this affects only the absolute performance
values, and not the performance trends, with one exception:
Varying $p_{reduct}$ (the reduction factor at each triggering level
of the `may-be-triggered' probability) between 0 and approximately 0.5
does not affect the performance trends of the system.
However, for values above that, it gives similar performance trends only
for values of $p_s$ (the level of data replication) of up to about 0.4.
For higher values of $p_s$, the update response time becomes non-linear
as the value of $n_{rules}$ or $n$ increases.
This is because the high data replication results in more rules being triggered,
more instances of rule actions being transmitted over the network and hence
an increase in network transmission times. Moreover, the arrival rate of
updates at the queues becomes higher than the rate that they can be served,
causing significant increases of the queue waiting times.
For the experiments described below, $p_{reduct}$ is fixed at 0.2.
March 2006

33. Conclusions and Future Work
Both sets of experiments show that the system performance is significantly reliant on the network topology between superpeers.
In particular, if a HyperCup topology is used for interconnecting the superpeers, then rule processing shows good scalability, pointing to its practical usefulness as a technology for real applications.
For the future we would like to conduct large-scale experiments with the actual RDFTL system itself, possibly using the PlanetLab infrastructure.
As well as giving insight into the actual system behaviour in a real P2P environment, this will allow measurements on actual system workloads and rule sets, which can then be fed into the analytical performance model and the simulator to allow more accurate predictions from these.
March 2006

34. Conclusions and Future work
We have shown the computational completeness and (relational) update completeness of the RDFTL language (George Papamarkos PhD thesis)
We expect the same properties hold for the XML ECA language, which is currently being formally verified (GP)
Although our P2P performance study was for RDFTL ECA rules, we expect similar behaviour would occur for P2P rules operating on other types of data e.g. XML or relational
This is an area of planned future work (Sandeep Mittal)
Also planned for the future is a distributed version of the XML ECA rule system, and its application for P2P data integration in a web services environment (Sandeep Mittal)
March 2006