RDFTL: An EventConditionAction Language for RDF - PowerPoint PPT Presentation


PPT – RDFTL: An EventConditionAction Language for RDF PowerPoint presentation | free to download - id: 15c1b9-ZWJlN


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

RDFTL: An EventConditionAction Language for RDF


RDFTL: An Event-Condition-Action Language for RDF. George Papamarkos. Alexandra Poulovassilis. Peter T. Wood. School of Computer Science and Information Systems ... – PowerPoint PPT presentation

Number of Views:31
Avg rating:3.0/5.0
Slides: 20
Provided by: GDP4
Learn more at: http://www.dcs.bbk.ac.uk


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: RDFTL: An EventConditionAction Language for RDF

RDFTL An Event-Condition-Action Language for RDF
  • George Papamarkos
  • Alexandra Poulovassilis
  • Peter T. Wood
  • School of Computer Science and Information
  • Birkbeck University of London

  • 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

  • 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

  • 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
  • SeLeNes 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,

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 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 source nodes of
    arcs that have triggered the rule

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
    Inserts/deletes/updates an arc specified by

Example of LO Metadata
Example of User Metadata
Example RDFTL rule
  • ON INSERT resource()target(dctype)Book/
  • target(bbkannotation)/
  • element()target(dctype)Review
  • IF delta/source()/source()
  • target(dcsubject)Computer Science
  • DO LET reviews
  • resource(http//www.dcs.bbk.ac.uk/users
  • target(bbkreview) 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
    128s reviews collection and the new review.

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
  • At each SP there is an installation of the ECA

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

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

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

Indexing in Peers and Super Peers
Local annotated RDFS
Combined annotated RDFS
Local annotated RDFS
Registering an ECA rule (contd)
  • An new ECA rule registered at a SP is also sent
    to all neighbouring SPs that may be relevant to
    it determined from the SP ID annotations on the
    originating SPs 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

Maintaining the Rule Bases
  • If a peer changes a schema node annotation from
    1 to 0 this information is propagated to its
  • The annotation of each rule in SPs rule base is
  • If as a result there is a rule which is no longer
    relevant to this peer group it can be deactivated
    in SPs rule base (not deleted, as it may later
    become relevant again)

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 SPs 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 SPs 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

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 Ps ID
  • If so, it sends P the rules event query to
    evaluate (this may involve distributed query
  • If the condition is true, the SP generates the
    necessary messages from the actions part of the
    rule for distributed action execution

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
About PowerShow.com