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

Re: Semantics for modification of annotations

From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Date: Fri, 17 Oct 2014 18:53:55 +0100
Message-ID: <CAPRnXtkzo9Wh1Jg9qypUC7xvGn-3-vayUKt0Qc9Q_t3BySzruA@mail.gmail.com>
To: philip.kershaw@stfc.ac.uk
Cc: dave.lewis@cs.tcd.ie, public-openannotation <public-openannotation@w3.org>, bigbluehat@hypothes.is
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..


In PAV we also has pav:previous version as a specialization of
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.
Received on Friday, 17 October 2014 17:54:24 UTC

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