Re: Semantics for modification of annotations

One approach would be to use the w3c provenance vocabulary ( http://www.w3.org/TR/2013/REC-prov-o-20130430/ ) moving the old annotation to a collection of entities associated with a 'deprication' activity using the prov:wasInvalidatedBy association.

I think the w3c is still missing a common way of communicating data updates in a common way however. The provenance solution above works within a single authority, but it only records changes rather than allowing one to manage (eg approve, reject, implement etc) a stream of suggested changes from third parties.

Regards,
Dave

Sent from my iPhone

> On 15 Oct 2014, at 17:21, <philip.kershaw@stfc.ac.uk> wrote:
> 
> Hi all,
> 
> I have a question about best practice for modification of annotations.  We have a project CHARMe, where we have built a system based on Open Annotation that enables scientists and researchers to annotate climate science datasets and satellite observations.  This uses a Javascript-based client application for data entry and a server application built on top of Jena to store triples.  There is a simple web service API which uses JSON-LD for its serialisation.  
> 
> Users would like the ability to modify existing annotations, typically to correct minor mistakes made on initial submission.  From a user perspective this is a simple requirement but I’m a conscious that there is a potential can of worms in the way these changes are managed in the triple store.  The existing system has support for deletion of annotations.  In this case annotations are moved to a separate graph to indicate they have deleted status.  One option for modification is to delete the current version and add a new one.  Is the best approach and what if any would be the best way to link between the new annotation and the old version which it supersedes?
> 
> Any help and guidance much appreciated.
> 
> Regards,
> Phil-- 
> Scanned by iCritical.
>