Re: Annotation creation and updates

On Sat, Apr 26, 2014 at 2:57 PM, Herbert Van de Sompel <hvdsomp@gmail.com>wrote:

> On Apr 26, 2014, at 10:01, Paolo Ciccarese <paolo.ciccarese@gmail.com>
> wrote:
>
> I do agree with that kind of approach... in case of versioning.
>
> I wrote this page in the OACG wiki almost two years ago and is basically
> the same idea:
> http://www.w3.org/community/openannotation/wiki/Versioning
>
> The outlined versioning approach is implemented for both annotations and
> annotation sets in Domeo since a while now and it works fine.
> We don't use Memento though, I implemented versioning directly in the
> Domeo framework.
>
>
> I would be most happy to help out in mapping how your internal versioning
> approach can be exposed in an interoperable manner aligned with Memento. It
> seems to me that you have all the hooks in place to make that happen.
>
>
+1


>
> In Annotopia I will serve versioning as well at one point (in fact I need
> it for connecting Domeo) but I also wanted to have the simple option with
> no versioning create/update.
>
>
> If versioning is not important, I am not sure that the difference between
> created/updated date matters that much either. After all, created/updated
> dates are a very weak form of versioning ...
>

I am still trying to cover basic use cases we have and to offer a low level
entry. In some cases creation and updates are important even if you don't
know exactly what happened in between. And in some others it is just easier
to not do full versioning.

Sometimes creation/update can be used between versions also. For instance,
typos could be qualified as part of the same version (+update) in some
context. Then a new version is generated when the actual meaning changes.
As Bob said these methods are context dependent.


>
> So, maybe the conclusion is that oa:annotatedAt is good enough:
> - in case of versioning, it expresses the creation date of the versioned
> annotation
> - in case of no versioning, it expresses the most recent update date of
> the non-versioned annotation
>

Ok, this is a viable interpretation and it is fully compliant with the
current OA Model with both versioning and no versioning.
I can use annotatedAt with that semantics.

I will manage the 'weak versioning' with completely different properties.

Best,
Paolo



>
> Herbert
>
>
> Best,
> Paolo
>
>
>
>
>
> On Sat, Apr 26, 2014 at 11:50 AM, Herbert Van de Sompel <hvdsomp@gmail.com
> > wrote:
>
>> Hi Paolo,
>>
>> I was actually thinking - in cases where versioning matters - to create a
>> new annotation (ie a new URI-Ai) per annotation. Which would mean that
>> oa:annotatedAt always is the creation date in these annotations. There is
>> no such thing as an updated date. Then, the various URI-Ai can be related
>> in a PROV graph. In addition, one could then have a generic URI-A where the
>> most recent version of the annotation is always accessible. The PROV graph
>> can be linked from all of the URI-Ai as well as from URI-A.
>>
>> What I describe is a versioning mechanism that is frequently used on the
>> web. Its relation to Memento with regard to version navigation is described
>> in http://mementoweb.org/guide/howto/ . The only difference between what
>> is described in that document and what I describe for versioned annotations
>> is the PROV graph, which fulfills the function of a Memento TimeMap.
>> Actually, the PROV graph is kind of a TimeMap on steroids and the paper I
>> referenced, yesterday, shows that such a PROV graph can be used for
>> datetime negotiation as specified in the Memento protocol. Obviously, you
>> could just use simple TimeMaps, not PROV graphs, to relate versions. But
>> then you would leave the RDF world & you would lose the ability to express
>> provenance information other than version URIs and version datetimes.
>>
>> Cheers
>>
>> Herbert
>>
>> On Apr 25, 2014, at 19:52, Paolo Ciccarese <paolo.ciccarese@gmail.com>
>> wrote:
>>
>> I have no problem in having separate provenance graph. In fact I already
>> manage provenance graphs that keep track of many other things (client,
>> organization...). These can be obtained on demand with separate calls then
>> those for regular Annotation.
>>
>> However, what I am trying to do is rather simple (basically equivalent to
>> Bob's last example). For more complex use cases I would resort to full
>> versioning.
>>
>> The creation/update is something not only useful for Domeo/Annotopia but
>> seems also basic stuff for annotator.js (see:
>> http://docs.annotatorjs.org/en/latest/annotation-format.html ) where you
>> have 'created' and 'updated'. As HarvardX is producing annotator.js format,
>> I need to translate that into Open Annotation without losing information.
>>
>> I am assuming Herbert is suggesting to have only oa:Annotation and a
>> oa:annotatedAt. Then... oa:annotatedAt would be the creation date when the
>> annotation is created and the update date when the annotation is updated.
>> To know if an Annotation is just created or updated you would need to query
>> the provenance graph. Herbert, is that what you meant?
>>
>> If this is the case, isn't it asking for too much complexity when a
>> simple created/updated withing the Annotation instance would be just enough?
>>
>> Paolo
>>
>>
>>
>>
>> On Fri, Apr 25, 2014 at 3:38 PM, Bob Morris <morris.bob@gmail.com> wrote:
>>
>>> Hmmm.  Come to think of it, consider  parsing in natural English
>>> ("subject predicate object"), we would expect that it is not the
>>> Target, but rather the oa:Annotation that is being annotatedAt
>>> 2014-02-17T09:46:11EST, . At the very least, to preserve your model
>>> and natural English, the creation predicates would need changing to a
>>> form like the pav:  forms, which suggests that (a)the pav: forms are
>>> enough alone (b) the breadth of the PROV expressiveness is so high
>>> that, has Herbert et al. suggest,  OA could express its use as
>>> connected by a single top-level provenance predicate
>>> ("oa:hasProvenance") with rdfs:range in PROV, perhaps along with some
>>> minimal expected prov terms.
>>>
>>> None of the above is meant to address your questions about what should
>>> be the nature of update history.  IMO this is a very domain-specific
>>> issue.  For example,  the scientific names of species change over
>>> time, each change associated with a publication.  The order of these
>>> changes and the provenance of citations of them, is very relevant and
>>> ,sadly, often impossible to memorialize in one or another relational
>>> database.  Thus  arguably, if a set of annotations is about species,
>>> then having nothing but "original" and "latest" updates to an
>>> annotation might be far from enough.  On the other hand, consider an
>>> annotation of <http://mbta.com/commuterRailLine/Fitchburg#> which has
>>> Body a train schedule object. This might well do with only a
>>> 'lastUpdate' attribute.
>>>
>>> Bob
>>>
>>>
>>> On Fri, Apr 25, 2014 at 11:09 AM, Paolo Ciccarese
>>> <paolo.ciccarese@gmail.com> wrote:
>>> > Dear all,
>>> > I am currently developing the Annotopia Open Annotation server
>>> [1][2][3] and
>>> > there are a few topics that I believe would be wise to discuss in the
>>> > mailing list in order to collect some additional feedback.
>>> >
>>> > I will start with one topic: keeping track of annotation creation and
>>> update
>>> > (date/agent).
>>> >
>>> > I collected some non conclusive thoughts here:
>>> >
>>> http://hcklab.blogspot.com/2014/04/annotopia-creationupdates-with-open.html
>>> >
>>> > No versioning for now. If that is of interest, months ago, I wrote some
>>> > thoughts here:
>>> http://www.w3.org/community/openannotation/wiki/Versioning
>>> >
>>> > In short, I am currently thinking of using PAV [4] with something like
>>> this:
>>> >
>>> > {
>>> >     "@id" : "
>>> http://host/s/annotation/830ED7EE-BF7B-4A18-8AE1-A9AF96AC135B",
>>> >     "@type" : "oa:Annotation",
>>> >     "annotatedAt" : "2014-02-17T09:46:11EST",
>>> >     "annotatedBy" : {
>>> >       "@id" : "http://orcid.org/0000-0002-5156-2703",
>>> >       "@type" : "foaf:Person",
>>> >       "name" : "Paolo Ciccarese"
>>> >     },
>>> >     "pav:createdOn" : "2014-02-17T09:48:11EST",
>>> >     "pav:createdBy" : {
>>> >       "@id" : "http://orcid.org/0000-0002-5156-2703",
>>> >       "@type" : "foaf:Person",
>>> >       "name" : "Paolo Ciccarese"
>>> >     },
>>> >     "pav:lastUpdateOn" : "2014-03-11T11:46:11EST",
>>> >     "pav:lastUpdateBy" : {
>>> >       "@id" : "http://example.org/johndoe",
>>> >       "@type" : "foaf:Person",
>>> >       "name" : "John Doe"
>>> >     }
>>> > ...
>>> > }
>>> >
>>> > Where:
>>> > (i) 'createdOn/createdBy' for the original creation on the (Annotopia)
>>> > server
>>> > (ii) 'lastUpdateOn/lastUpdateBy' for the last update on the (Annotopia)
>>> > server
>>> >
>>> > Question is: what is 'annotatedAt' going to indicate once the
>>> annotation has
>>> > been updated? The original creation or the latest update? In fact, some
>>> > application will understand only the 'annotatedAt' property.
>>> >
>>> > Another option I have, to keep the actual annotation pure OA, is to
>>> collect
>>> > the additional provenance data in a separate provenance graph that can
>>> be
>>> > provided on demand by who can understand it.
>>> >
>>> > Any thoughts?
>>> >
>>> > Best,
>>> > Paolo
>>> >
>>> > [1] GitHub (Code/wiki): https://github.com/Annotopia/AtSmartStorage
>>> > [2] Slides (living documentation):
>>> >
>>> http://www.slideshare.net/paolociccarese/annotopia-overview-by-paolo-ciccarese
>>> > [3] Talk @ 'I Annotate 2014'
>>> https://www.youtube.com/watch?v=UGvUbFv0Zl8
>>> > [4] PAV: http://www.jbiomedsem.com/content/4/1/37
>>> >
>>>
>>
>
>
> --
> Dr. Paolo Ciccarese
> Assistant Professor of Neurology, Harvard Medical School
> Assistant in Neuroscience, Massachusetts General Hospital
> Senior Information Scientist, MGH Biomedical Informatics Core
>
> CONFIDENTIALITY NOTICE: This message is intended only for the
> addressee(s), may contain information that is considered
> to be sensitive or confidential and may not be forwarded or disclosed to
> any other party without the permission of the sender.
> If you have received this message in error, please notify the sender
> immediately.
>
>


-- 
Dr. Paolo Ciccarese
Assistant Professor of Neurology, Harvard Medical School
Assistant in Neuroscience, Massachusetts General Hospital
Senior Information Scientist, MGH Biomedical Informatics Core

CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s),
may contain information that is considered
to be sensitive or confidential and may not be forwarded or disclosed to
any other party without the permission of the sender.
If you have received this message in error, please notify the sender
immediately.