March 2006

Event-Condition-Action rules for the Semantic Web

Alex Poulovassilis, Birkbeck, U. of London

March 2006

Overview

1. Reactivity over XML and RDF2. The SeLeNe project3. XML ECA Language4. RDFTL – an RDF ECA Language

March 2006

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

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

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

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

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

Application services

User Registration LO RegistrationTrails andAdaptation

Management Services

Collaboration

Event and Change Notification ServiceView and Query

Services

Update Service Syndication Service

Presentation Services

Access Services

Locate Service Information Service Sign-On ServiceCommunication

Service

Taxonomiesof LO Topics and

Objectives

LOSchemas andDescriptions

User ProfileSchemas andDescriptions

{RDF/S

March 2006

Self e-learning Network

Self e-learning Network

PEER

SITE

SITE

SITE

SITE

SITE

SITE

SITE

SITESITE

Course

Program Module

Lesson

ppt

CSCourses

AICourses

IEEE LOM

ACM CSS

LO

Objectives

Custom Sch.

Lesson

March 2006

LO Metadata Standards,

Ontologies

<tag1> <tag2> <tag3></tag1>

<tag1> <tag2> <tag3></tag1>

Learning Objects

LO Metadata

March 2006

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

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

The SeLeNe Learner Profile

m es sages

goals

SeLeNe :Lea rn ingO b jective

IMS-R C D :C om petency

D efinition

D escr ip tion

C atalog

IMS-LIP :com petenc y

Title

Entry

IMS-L IP:QC LQu a lifica tio n s

PAPI:Pe rs o n a l In fo

Learning Topic(Ta xo n o m ye le m e n t)

IMS -L IP:In te re sts

LOProviders

SeLeNe:Learning S tyle

T axo nomy Style

learnings tyle preference

SeLeNe :His to ry

SeLeNe:Notifications

PAPI & SeLeNe:Pre fe re n ce s

New L OsUpdated

LO s

New Use rs

goa ldescr ip tio n

goa l top ic

D esc riptiveVerb Annotation

Priority

Acces s ibility

D ate

p re fe re nces

IMS-L IP:G o a ls

LEARNER

March 2006

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

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

March 2006

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

March 2006

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

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

Example RDFTL ruleON INSERT resource() AS INSTANCE OF LearningObjectIF $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);;

Checks for triggering event

Carries out the action associatedwith this rule (i.e. notifies learner128 that there is a new LO of interest)

Checks to see if the conditionis met (i.e. if the inserted resourceis on the topic of one of user 128’s learning goals)

SeLeNe Information space128

Learner

rdf:type

Goal 1Objective X

goal

goal_descriptionC++

goal_topic

C++Course

Keenoy

LOM:contributedBy

LOM:subjectLOM:subject

Notifications messagesnew_LOs Notifications messagesnew_LOs

March 2006

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

RDFTL P2P Deployment

March 2006

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

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

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

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

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

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

HyperCup vs Full Net, 10% replication, varying peergroups

March 2006

HyperCup, replication 90%, varying peergroups

March 2006

HyperCup, replication 10%, varying rules

March 2006

Simulation, Full Net, replication 10%

March 2006

Simulation, HyperCup, 10% and 90% replication

March 2006

Simulation, HyperCup, varying rules

March 2006

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

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)