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

Re: Annotation creation and updates

From: Benjamin Goering <ben@livefyre.com>
Date: Mon, 28 Apr 2014 23:43:11 -0700
Message-ID: <CAA-ozNZa7-1kwq6fXvxh8YfBYG4GcnCiEnq5ee9GdQNok1hHhQ@mail.gmail.com>
To: Paolo Ciccarese <paolo.ciccarese@gmail.com>
Cc: Herbert Van de Sompel <hvdsomp@gmail.com>, Bob Morris <morris.bob@gmail.com>, public-openannotation <public-openannotation@w3.org>
At Livefyre, for the last few years, we modeled social Content (e.g.
comments, tweets, photos) similarly to what is documented here, especially
wrt Editing.
http://www.w3.org/community/openannotation/wiki/Versioning

An edit was a new post of content, but it replaced another message id.
As Herbert
Van de Sompel <hvdsomp@gmail.com> said, "There is no such thing as an
updated date." (TINSTAAUD). A new message comes in and has a 'replacesId'
field. Any clients, like a widget on a page, would see if it was currently
storing that replacesId and update its display. If it isn't stored on the
client, render it anew.

This 'replacesId' is very similar, and mappable to, pav:previousVersion.

When we aren't streaming updates, but are representing a list of Content
(implicitly at latest versions), we use createdAt and updatedAt to let you
distinguish if the Content has been edited ever. This is useful context to
a reader if there had been discussion around previous versions of the
content. These fields can be thought to be derived from (respectively)
* updatedAt -> pav:createdOn
* createdAt -> the value reached by walking pav:previousVersion until it is
null, then pav:createdOn

If we use OA, it sounds like we can cleanly map to what you're proposing
here

> 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


A new Service I am working on will have versioning in it's problem domain,
so thanks for the pointer towards PAV. :)

--
Benjamin Goering - @bengo
Platform @Livefyre Labs


On Sat, Apr 26, 2014 at 12:49 PM, Paolo Ciccarese <paolo.ciccarese@gmail.com
> wrote:

>
>
>
> 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.
>
Received on Tuesday, 29 April 2014 06:43:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:05 UTC