RDFTL: An Event-Condition-Action 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 3rd Web Dynamics Workshop

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 3rd Web Dynamics Workshop

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 • SeLeNe’s 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 3rd Web Dynamics Workshop

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 $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 source nodes of arcs that have triggered the rule 3rd Web Dynamics Workshop

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 3rd Web Dynamics Workshop

7. Example of LO Metadata 3rd Web Dynamics Workshop

8. Example of User Metadata 3rd Web Dynamics Workshop

9. Example RDFTL rule ON INSERT resource()[target(dc:type)=‘Book’]/ target(bbk:annotation)/ element()[target(dc:type)=‘Review’] IF $delta/source()/source() [target(dc:subject)=‘Computer Science’] DO LET $reviews = resource(http://www.dcs.bbk.ac.uk/users/128)/ target(bbk:review) 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 128’s reviews collection and the new review. 3rd Web Dynamics Workshop

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 3rd Web Dynamics Workshop

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 3rd Web Dynamics Workshop

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 3rd Web Dynamics Workshop

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 peer’s SP where a combined annotated RDF Schema is maintained from all peers in this SP’s peer group and also the remote SPs with which this SP is connected • Any change of in the annotation of an SP’s 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 3rd Web Dynamics Workshop

14. Peer Resource P1 r1,r2,r4,r5 2 P2 Resource index {1} {P2} {1} {P1,P2,SP2} {SP1} {1} {P4,P5,SP1} {P1,P2,SP2} {P4,SP1} {0} {P1} {0} {P1,SP2} {SP1} {P5,P4,SP1} 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 3rd Web Dynamics Workshop

15. Registering an ECA rule (cont’d) • An new ECA rule registered at a SP is also sent to all neighbouring SP’s that may be relevant to it – determined from the SP ID annotations on the originating SP’s 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 3rd Web Dynamics Workshop

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 SP’s 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 SP’s rule base (not deleted, as it may later become relevant again) 3rd Web Dynamics Workshop

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 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 3rd Web Dynamics Workshop

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 P’s ID • If so, it sends P the rule’s 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 3rd Web Dynamics Workshop

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 3rd Web Dynamics Workshop