W3C home > Mailing lists > Public > public-openannotation@w3.org > June 2014

Re: Annotations which notify of changes

From: Herbert van de Sompel <hvdsomp@gmail.com>
Date: Thu, 19 Jun 2014 04:24:32 -0600
Message-ID: <CAOywMHeFTqxeLKfgkDOWgyQNgcrJQF+-7sJM7=zP=bFOg_f9Mw@mail.gmail.com>
To: Patrick Cuba <cubap@slu.edu>
Cc: public-openannotation <public-openannotation@w3.org>, Herbert van de Sompel <hvdsomp@gmail.com>
Hi Patrick,

What you describe can be achieved using ResourceSync Change
Notifications. The approach to discover where notifications will be
sent using the ResourceSync approach is not as you describe (i.e. not
embedded in an annotation) but rather external to it. The reason is
that the ResourceSync solution is designed to be usable for all kinds
of URI-identified resources, not just annotations.

Details about ResourceSync Change Notifications are available at
http://www.openarchives.org/rs/notification . But in short:

* Change (create / update / delete ) notifications pertaining to a set
of resources are published on a "channel" using the PubSubHubbub
protocol. PubSubHubbub calls this channel a "topic URI".  So one could
imagine having such a channel for a collection of annotations.

* The channel can be discovered through discovery of a so-called
ResourceSync Capability List. Such a list provides information about
various resource synchronization capabilities that are supported for a
set of resources. One of those capabilities is Change Notifications.
The full ResourceSync spec defines many more syncing capabilities.

* The Capability List itself is discovered by means of an HTTP Link
header in which a link with the relation type "resourcesync" is

So, in essence, if an application wants to remain informed about
changes to an annotation it does the following:

* HTTP HEAD on the URI of the annotation to find the HTTP Link header
and in it the link with the "resourcesync" relation type that points
at the URI of the Capability List.

* Obtain the Capability List by dereferencing the URI that was just found.

* Parse the Capability List to find the information about where Change
Notifications are available. This yields the channel (topic URI) and
the URI of a PubSubHUbbub hub that is willing to relay the

* Subscribe to the Hub indicating the channel (topic URI) of interest.

* From then on receive notifications about changes to any resources
covered by the channel, e.g. the collection of annotations.

This all may sound a tad complicated but it's actually really
straightforward in practice. We just demonstrated ResourceSync
notifications at work at OR 2014; these notifications were about
additions to the CORE repository.

Python libraries that were used for the demo (for publisher, hub, and
subscriber) are available at



On Tue, Jun 17, 2014 at 4:09 PM, Patrick Cuba <cubap@slu.edu> wrote:
> context: OAC (and SharedCanvas and IIIF) in web applications for manuscript
> studies using linked open data structures.
> Annotation update notification service:
> Is there a place in a spec for an annotation which carries an endpoint with
> it to notify about updates? Certainly not all annotation stores or
> applications would honor this, but if they did it may improve the lives of
> large repositories that share much of their data.
> For example:
> <anno> a oa:Annotation ;
> eg:onUpdate "example.com/anno-notify" .
> When someone (some machine) updates this annotation, the new annotation URI
> can be sent to the endpoint where it would be consumed by some service so
> the watcher would know something happened.
> Perhaps for a cleaner world, there is a separate digital object that is a
> Notifier like:
> <Notifier> a eg:Notification ;
> eg:watches <anno> ;
> eg:onUpdate "example.com/anno-notify" ;
> eg:onTargeted "example.com/anno-notify" ;
> eg:onEmbodied "example.com/anno-notify" .
> If I support it, I can look for these Notifiers on the graph when I make
> changes or a store may register them independently if Stanford decides to
> start following whose publicly using their manifests without just sending a
> robot out for a stroll every once in an iteration.
> I imagine a public annotation store can do this outside of standards without
> too much grief, but it may be something an annotation generator (or creator)
> would want to attach to an annotation regardless of the location.
> Is this crazy or already possible? Events are closely tied to the annotation
> objects developers create in web applications with great effect, but to
> attach events/watchers to annotations in the wild may be a step too far.
> Patrick Cuba
> Center for Digital Humanities
> Saint Louis University

Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library

Received on Thursday, 19 June 2014 10:25:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:26 UTC