- From: Herbert van de Sompel <hvdsomp@gmail.com>
- Date: Thu, 19 Jun 2014 04:24:32 -0600
- 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 provided. 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 notifications. * 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 https://github.com/hariharshankar/resourcesync_push Cheers Herbert 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 http://public.lanl.gov/herbertv/ ==
Received on Thursday, 19 June 2014 10:25:00 UTC