Re: Semantics for modification of annotations

Yes, this is a sane approach you are suggesting. You can also associate a
prov:Agent with the :modifying1 activity to say who did the change.

:modifying1 prov:wasAssociatedWith :johndoe .

:johndoe a prov:Person ;
  foaf:name "John Doe" .

The only thing now is that you need to filter for invalidated annotations
as they would still say they annotate a given resource, you can either do
that by moving them to a separate archival graph, or by closing the world
and do a negative filter on prov: invalidated in a Sparql query.

In a distributed system you might end up with a fork, and not know which
revision is the new HEAD so to speak.

You can use pav:hasCurrentVersion from a unversioned generalization of the
annotations if you need to declare the "official latest version". This is
for obvious reason not available in an inverse direction..

http://purl.org/pav/html#http://purl.org/pav/hasCurrentVersion

In PAV we also has pav:previous version as a specialization of
prov:wasRevisonOf.
http://purl.org/pav/html#http://purl.org/pav/previous version

This comes with the transitive super property pav:earlierVersion to find
all the earlier versions, and is also sub property of prov:alternateOf.
 On 17 Oct 2014 10:50, <philip.kershaw@stfc.ac.uk> wrote:

> Thanks for the help.  I think it makes sense to use PROV-O given OA uses
> it anyway.
>
> Assuming an oa:Annotation is modelled on a prov:Entity (
> http://openannotation.org/spec/core/appendices.html#ProvMapping) I can
> use prov:wasRevisionOf to point from the new annotation to the one it
> replaces.  If I define an activity of modifying this can be used to link
> back from the deleted annotation to the new annotation:
>
> newAnno1 a oa:Annotation ;
>         prov:wasRevisionOf deletedAnno1 ;
>         prov:wasGeneratedBy modifying1 .
>
> deletedAnno1 a oa:Annotation ;
>         prov:wasInvalidatedBy modifying1 .
>
> modifying1 a prov:Activity ;
>         prov:invalidated deletedAnno1 ;
>         prov:generated newAnno1 .
>
> Cheers,
> Phil
>
> On 15 Oct 2014, at 19:43, Benjamin Young <bigbluehat@hypothes.is> wrote:
>
> > Depending on how you accept and store the changes (and how you wish to
> > represent them later), you could use Dublin Core terms such as
> > replaces, isReplacedBy, isVersionOf, etc.
> >
> > They're in use in the RDFa of the DCMI Metadata Terms page:
> > http://dublincore.org/documents/2012/06/14/dcmi-terms/
> >
> > There is also RFC 5829 "Link Relation Types for Simple Version
> > Navigation between Web Resources"
> > http://tools.ietf.org/html/rfc5829
> >
> > The format of the later is more terse (in either the HTTP headers or
> > in the markup), but may not get you the RDF-based semantic value for
> > your graph storage--as I'm not sure how these link relationships are
> > considered in the RDF tooling world (though I'd be interested to
> > learn, if anyone knows).
> >
> > Hope something in there was helpful!
> > Benjamin
> > --
> > Developer Advocate
> > http://hypothes.is/
> >
> > On Wed, Oct 15, 2014 at 12:21 PM,  <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.
> >>
>
> --
> Scanned by iCritical.
>
>