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

1. Event-Condition-Action rules for the Semantic WebAlex Poulovassilis, Birkbeck, U. of London

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

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

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)

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

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

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

8. 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

9. LO Metadata Standards, Ontologies LO Metadata Learning Objects <tag1> <tag2> <tag3> </tag1>

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

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

12. The SeLeNe Learner Profile

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

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

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

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 $deltahas 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 $deltahas 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.

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

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

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

20. RDFTL P2P Deployment

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

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.

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

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.

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

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

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

28. HyperCup, replication 90%, varying peergroups

29. HyperCup, replication 10%, varying rules

30. Simulation, Full Net, replication 10%

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

32. Simulation, HyperCup, varying rules

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.

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)