Figure 1 describes the proposed architecture of the rsine service (Notiﬁcation Service frame). The service on the left side of the ﬁgure is intended to give an overview on the components interacting internally, whereas the notiﬁcation 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) that can be used for Virtuoso Servers. However, in environments that rely on diﬀerent RDF storage backends such as openRDF Sesame,
Fig. 1. Conceptual overview
a custom Change Handler that ﬁts 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  ontology and persists them to an internal Changeset Store.
A subscriber who is interested in receiving notiﬁcations can subscribe by sending a subscription document to the service that contains SPARQL queries and information about the preferred notiﬁcation 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 Notiﬁcation Service box). This feature is useful to get notiﬁcations whenever resources in datasets on diﬀerent servers reference each other. Due to space limitations we refer to deliverable D5.3.1 for a detailed coverage of the workﬂows 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 speciﬁes the resources the subscriber is interested to get notiﬁcations about and (ii) at least one notifier that deﬁnes the way notiﬁcation messages should be disseminated. A basic example is provided in Listing 1 (preﬁxes omitted, for an in-depth coverage we refer to the online documentation).
Listing 1. Rsine Subscription.
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 conﬁgures database triggers and stored procedures so that all triple changes Pebbles performs to are communicated to rsine.
WKD speciﬁed in total 13 scenarios for notiﬁcations 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 and converted them for use with rsine. Among them are, e.g., checks for cyclic hierarchical relations or concepts with conﬂicting (i.e., identical) preferred labels.