event-condition-action rules for the semantic web alex poulovassilis, birkbeck, u. of london
Post on 31-Dec-2015
24 Views
Preview:
DESCRIPTION
TRANSCRIPT
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)
top related