[this is just a rough working draft]

RDF Event Exchange Protocol

Distributed information exchange and manipulation for the Semantic Web.

Summary

This document describes the RDF Event Exchange Protocol or REEP. The protocol provides an extensible Event ontology and a processing approach for its use in distributed information exchange and manipulation applications for the Semantic Web. Within a REEP document, application code may be described as a sub-graph behind an Event instance node, utilizing the RDF model. Since REEP uses an RDF-based format, REEP Event nodes may share application input channels (e.g. an RDF document or feed) with other RDF nodes, while application code within REEP Events may refer or apply to such nodes. Contrary to RDF XML, which provides a static serialization of an RDF graph, REEP provides manipulation instructions regarding a graph, as well as the graph itself or parts of it; in other words the complete lifetime of an RDF graph can be described as a REEP message. A REEP message may or may not be standalone.

Additionally, the document provides suggestive examples on processor behavior and the potential of RDF meta-data about application code and business logic.

Processing Model

RDF parsers do not assume parsing order of nodes is important, since the order of nodes in RDF does not have an effect on the resulting graph. The parse order of graph nodes is considered irrelevant when building the graph, although document order has been a useful in formats used to serialize RDF. One example of such a format is XML, where document order is obeyed by XML parsers.

REEP assumes the order of implicit or explicit Event nodes can be used to naturally describe a sequence of events that effect a target graph. The graph, or parts of it, may be carried in REEP as well. When a REEP processor is used in implicit mode, regular (i.e. non-Event) nodes are considered implicit Events for adding or merging those nodes in the graph. The processing model of REEP is serial, although not necessarily continuous, while an application may use concurrent input channels addressing the same graph.

It is obvious that the additional semantics of the RDF being processed must provide enough information for the parsing and/or processing to decide whether the triple should be disregarded after processing or added to the graph. Disregarded events could be places in secondary storage (file system, database etc.) for historical/versioning or other future processing as it may be required by the business logic or other implementation aspects of an application.

Processor Modes

Implicit Mode

Processing of implicit Event nodes (i.e. regular Nodes added to the graph): true/false. Can be used by the processor to direct all input to Event handlers. Such handlers effectively receive the complete graph as Events.

Addition Mode

Merge VS replace predicates/objects

Inference Mode

Controls inference (true/false).

Modes API

Configuring Modes

setMode(mode-namespace, setting)

Mode Feature Tests

Processors must offer API to check for processor implemented features, meaning modes with specific settings. For example, a SAX Filter processor used to handle Events may not support inference.

Boolean supportsFeature(mode-namespace, setting);

Events

Base Event

All events inherit the BaseEvent Class.

Discuss potentially common attributes regarding authorization, trust, security, workflow, callbacks, sync/async, threaded, reusable)

Submission Events

Differences between ADD/MERGE/REPLACE when it comes to a Node? This doesn't have to be your grandpa's CRUD since we are talking about subgraphs.

PUT/ADD Event

MERGE/UPDATE/REPLACE Event

Implicit Submission Events

Implicit Events when the implicit mode/feature of the processor is set to true and non-Event RDF nodes are simply added to the graph or triple store.

PUT

MERGE

Retrieval Events

Base Retrieval Event

All retreival events extend this one. Property to ask for a specific MIME?

Get Event

Returns a Node (CBD?) via an Answer Event ?

Query Event

Wraps queries in various languages like SPARQL ?

Subscription Event

subscribe to change modifications, classes, instances, conditions? Receive the notifications as a CRUD or other event? Sync use cases?

Answer Event

Answer Events are responses to received Events. They may be synchronous.

Higher Level Events

REEP provides not only a set of tools for basic manipulation of RDF nodes, but also a way to define custom event vocabularies through extension and abstraction, much like regular programming APIs do.

Composite Event

Extending Events

Misc

Use Cases

Advantages

• Events provide a generalized approach to live graphs, usable by tools available today.

• Promoting events such as graph operations to first rate RDF citizens allows the use of a single channel to build and manage a graph.

• The use of parsing order to register events is natural, requires no explicit ordering information. Details on the relationship between events regarding their sequence, like time difference or other relationships can easily be added in event descriptions according to application needs.

• Using parsing order does not conflict with the desired ability to update an RDF graph using any number of documents or streams etc.

• Both generic and custom event vocabularies may be designed using this approach.

Disadvantages

• Non-event aware RDF processors will just add the events to the resulting graph. The events may be useless in the absence of explicit ordering information.

Issues

• How can Events be used without contaminating the graph by default? Possibly an Event recording mode could be used to hook up handlers for Events instead of adding them to the graph.

• Should an Event-aware processor add explicit ordering information to events before passing them to the application?