Figure 1 describes the proposed architecture of the rsine service (Notification Service frame). The service on the left side of the figure is intended to give an overview on the components interacting internally, whereas the notification service on the right side is a second instance of the framework installed on a remote location on the Web.

Our approach uses a Change Handler that mediates between the Managed RDF store and the rsine service. In our implementation we provide a Change Handler (rsineVad[1]) that can be used for Virtuoso Servers. However, in environments that rely on different RDF storage backends such as openRDF Sesame,

Fig. 1. Conceptual overview

a custom Change Handler that fits to the internals of the used storage solution must be implemented.

The rsine service continuously observes changes to the data held by a Managed RDF Store on the triple level, i.e., every time a triple is added, updated or removed the framework is triggered. The triple change events are then passed to the Changeset Service which converts the received triple changes to changesets expressed in the Changeset [2] ontology and persists them to an internal Changeset Store.

A subscriber who is interested in receiving notifications can subscribe by sending a subscription document to the service that contains SPARQL queries and information about the preferred notification channel (e.g., email, Twitter). The queries from the subscription document select resources the subscriber is interested in and access both the data contained in the Managed RDF Store as well as in the Changeset Store. The results of these queries, can then be disseminated through the desired channels. Before dissemination, the Results Formatter formats the query results into human-readable form by using the template provided in the subscription document.

Rsine can also send (“forward”) local dataset changes to remote rsine instances on the Web (small Notification Service box). This feature is useful to get notifications whenever resources in datasets on different servers reference each other. Due to space limitations we refer to deliverable D5.3.1 for a detailed coverage of the workflows for both local and forwarded dataset changes.

Subscribing for Notifications

Subscriptions are RDF documents that are sent to the rsine service by HTTP POST. They consist of two mandatory parts: (i) a query which specifies the resources the subscriber is interested to get notifications about and (ii) at least one notifier that defines the way notification messages should be disseminated. A basic example is provided in Listing 1 (prefixes omitted, for an in-depth coverage we refer to the online documentation[3]).

Listing 1. Rsine Subscription.

Stack Integration

In order to showcase the capabilities of rsine, we integrated it with two exemplary components of the LOD2 stack: The PoolParty Thesaurus Server (PPT) and Pebbles. PPT is a tool for taxonomy experts to develop thesauri and publish them as Linked Data using SKOS. Pebbles is a Web application that provides a GUI to manage RDF metadata for XML documents. For testing the integration we used the stack installation operated by Wolters Kluwer Germany (WKD).

PPT builds on OpenRDF Sesame infrastructure for persisting RDF data. In order to provide interoperability between PPT and rsine, we implemented a subclass of RepositoryConnectionListenerAdapter. It intercepts the triple changes and, before handing them down to the triple store for persistence, announces them to rsine's HTTP interface.

Pebbles uses Virtuoso as storage backend. The only task for integrating rsine with Pebbles was thus to deploy the rsineVad package from the rsine repository to the Virtuoso instance. RsineVad is an extension to Virtuoso that configures database triggers and stored procedures so that all triple changes Pebbles performs to are communicated to rsine.

Notification Scenarios

WKD specified in total 13 scenarios for notifications that are described in detail in deliverable D7.3. They are divided into scenarios that are important in a thesaurus development process (e.g., to “follow all changes such as deletion, linking or editing of concepts”) and scenarios from metadata editing with Pebbles (e.g., “Follow all changes of the document metadata”). We were able to support all but one requirements from the thesaurus development scenario and implemented one metadata editing scenario as a proof-of-concept. Furthermore, we adapted 9 checks for potential controlled vocabulary quality problems from our earlier work[4] and converted them for use with rsine. Among them are, e.g., checks for cyclic hierarchical relations or concepts with conflicting (i.e., identical) preferred labels.

  • [1]
  • [2]
  • [3]
  • [4] qSKOS controlled vocabulary quality checker,
< Prev   CONTENTS   Next >