Re: Annotations which notify of changes

We experimented with PubSubHubub (PSH) using SPARQLPush [1] in an early
version of FilteredPush [2] for  semantically supported notifications of
annotations. These include, but are not limited to, actionable annotations
about resource change proposals and the resulting action,   We had several
issues, some of which it looks like ResourceSync can deal with but others,
perhaps by intent, not.  In some deployments the biggest issue with pushing
certain  annotations was that in some cases, consuming applications were
behind firewalls that limited what we can push.  However, those clients
typically were managing resources, e.g. databases, that were separately
exposed on the web and needed to be synchronized to some other resource,
but can only be done through the "invisible" client. However, it could be
assumed that the client can make  http GET requests on port 80 to  http
servers that would deliver the synchronization advice.  I can't tell how or
if ResourceSync would manage this use case, but I wouldn't think it hard.

We have a more general requirement than ResourceSync seems to cover (though
it looks extensible...).  Namely, in the first instance we generate OA
annotations that contain \assertions/ that a certain resource \should/ be
changed in various ways. We modeled this with a proposed addition to OA
called "Expectation", which covers, at the moment, only the standard models
of SQL changes, along with one named "SolveWithMoreData". The latter means
that the annotator claims a change is needed, but doesn't know what it
should be [3]. My quick reading of the ResourceSync documentation is that
it suffers the same issue we do, namely that if one wants add types more
than the specified ones, then new types must be added at the ontology
level, putting an added burden on consuming applications to be able to
interpret the new type.

Our consuming synchronization targets have carefully controlled authority
as to whether to actually make the recommended synchronization. As to what
\actually/ happened to the target resource, we prefer to relegate that to
annotation conversations---i.e. the consumer of the oa:Annotation that
advises a change  produces an oa:Annotation whose target is the original
annotation,  and reports whether or not it accepted the suggested change.
 That helps us keep a provenance of the synchronizations (e.g. "I changed
my resource because you changed yours even though I think you're wrong.")

Finally, with SPARQLPush, we had difficulty keeping provenance because the
annotation data were kept in a triple store that had to be defended against
annotations being semantically polluted by the addition of triples shared
with other annotations.  For reasons having to do with other data
harvesting concerns of our applications, we found it more convenient to use
a document store for the annotations and RDFize them on demand.  I know
others use quad stores to solve this problem, but we live in a world where
there are potentially billions of resources that might need changing on
quality control grounds or to signal initial creation and scalability
worried us.

Bob Morris

[1] https://code.google.com/p/sparqlpush/
[2] http://wiki.filteredpush.org/
[3]
http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0076093


On Fri, Jun 20, 2014 at 3:24 PM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
> Hi Patrick,
>
> It's certainly not crazy, and I don't know of a solution other than the
> ResourceSync option that Herbert describes.
> I think this would be a great use case to take forwards to the API
> component of the W3C Working Group discussion, not only between systems but
> also at an internal level so that we have a robust event system within a
> client side (e.g. javascript) API for browsers.
>
> Thanks!
>
> Rob
>
>
>
> On Tue, Jun 17, 2014 at 3: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
>>
>
>
>
> --
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305
>



-- 
Robert A. Morris

Emeritus Professor  of Computer Science
UMASS-Boston
100 Morrissey Blvd
Boston, MA 02125-3390


Filtered Push Project
Harvard University Herbaria
Harvard University

email: morris.bob@gmail.com
web: http://efg.cs.umb.edu/
web: http://wiki.filteredpush.org
http://www.cs.umb.edu/~ram
===
The content of this communication is made entirely on my
own behalf and in no way should be deemed to express
official positions of The University of Massachusetts at Boston or Harvard
University.