- From: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Date: Wed, 24 Jun 2015 15:46:59 -0400
- To: Robert Sanderson <azaroth42@gmail.com>
- Cc: Ivan Herman <ivan@w3.org>, Chris Birk <cmbirk@gmail.com>, Doug Schepers <schepers@w3.org>, Jacob Jett <jjett2@illinois.edu>, W3C Public Annotation List <public-annotation@w3.org>
- Message-ID: <CAFPX2kCWavnZuXOYgy7YOUCS35vdQ873XOZsB5zcuFK8q2Q7Bw@mail.gmail.com>
Rob,
could these two cases co-exist?
{
"body" : [
{
"role" : "edit",
"content" : "literalcontent"
}
…
]
}
{
"body" : [
{
"role" : "edit",
"content" : {
"@id": "http://youtube.com/somevideo"
}
}
…
]
}
In other words, we use the shortcut for the literals (that cannot be reused
anyway) and the verbose way with resources?
Paolo
On Wed, Jun 24, 2015 at 3:44 PM, Robert Sanderson <azaroth42@gmail.com>
wrote:
>
> For once I disagree with Paolo! (Put it in your calendars!)
>
> If every body had a role, I think there would be no need for motivation.
> And the motivation would potentially be both confusing and unactionable.
> For example:
>
> {
> motivation: tagging,
> body: {
> role: commenting,
> resource: http://youtube.com/somevideo
> }
> }
>
> In that case, it seems like the motivation and the role of the body are
> completely at odds and the client has no way to understand the intent?
>
>
> On Wed, Jun 24, 2015 at 5:03 AM, Paolo Ciccarese <
> paolo.ciccarese@gmail.com> wrote:
>
>> I guess that is true if we allow the range of "content" to be either a
>> Literal or another Resource as we do now for 'body' and 'Simple Textual
>> Bodies'.
>> I was assuming the range of content to be always a Resource, but you are
>> right, that is unnecessary.
>>
>> I would just recommend to stick to 'role' for Bodies and 'motivation' for
>> the Annotation as I strongly believe those are different things.
>> in Doug example the motivation is 'editing' and within that motivation we
>> have bodies with different roles.
>>
>> Best,
>> Paolo
>>
>> On Wed, Jun 24, 2015 at 5:19 AM, Ivan Herman <ivan@w3.org> wrote:
>>
>>> Actually… In the example below, I would expect that
>>>
>>> {
>>> "body" : [
>>> {
>>> "role" : "edit",
>>> "content" : "newcontent"
>>> }
>>> …
>>> ]
>>> }
>>>
>>> which is analogous to the fact that we may have a string as a body. So,
>>> in fact, this is pretty much the same as what Doug had in mind a while ago,
>>> and also analogous to what Rob proposed. Ie, aren't you all in a wild
>>> agreement?
>>>
>>> Ivan
>>>
>>> P.S. Except that Doug, without realizing, invented the concept of a
>>> blank node, ie, a resource whose identifier is not explicit:-)
>>>
>>>
>>>
>>> > On 23 Jun 2015, at 22:07 , Paolo Ciccarese <paolo.ciccarese@gmail.com>
>>> wrote:
>>> >
>>> > Doug,
>>> > I am assuming this is not acceptable compromise as already too verbose?
>>> >
>>> > {
>>> > "body": [
>>> > {
>>> > "role": "edit",
>>> > "content": {
>>> > "value": "newcontent"
>>> > }
>>> > },
>>> > {
>>> > "role": "comment",
>>> > "content": {
>>> > "value": "This needed changing"
>>> > }
>>> > }
>>> > ]
>>> > }
>>> >
>>> > On Tue, Jun 23, 2015 at 2:32 PM, Robert Sanderson <azaroth42@gmail.com>
>>> wrote:
>>> >
>>> > The issue is the inability to have community specific motivations be
>>> processable without RDF level inferencing (e.g. that hasEdit is a sub
>>> property of hasBody)
>>> >
>>> > Rob
>>> >
>>> > On Tue, Jun 23, 2015 at 11:31 AM, Chris Birk <cmbirk@gmail.com> wrote:
>>> > I agree with keeping the model flexible, and I agree with having
>>> multiple bodies. The concern with having motivation on a body level is
>>> query complexity.
>>> >
>>> > If I want to grab all annotations that are editing content, I have to
>>> first grab *all* annotations, and then iterate through their bodies to
>>> check for the ‘editing’ motivation. If the motivation is on an annotation
>>> level, this is much simpler.
>>> >
>>> > I wasn’t present for the original model decisions, so I apologize if
>>> I’m re-hashing a previous issue here, but one solution would be simply
>>> moving the motivations to a top-level annotation attribute key. For
>>> example, instead of having
>>> > --
>>> > {
>>> > "body": [
>>> > {
>>> > “motivation”: “edit”,
>>> > “value”: “new content"
>>> > },
>>> > {
>>> > “motivation”: “comment”,
>>> > “value”: “This needed changing"
>>> > }
>>> > ]
>>> > }
>>> > ---
>>> > changing to
>>> > ---
>>> > {
>>> > ...
>>> > “edits”: [
>>> > {
>>> > ...
>>> > }
>>> > ],
>>> > “comments”: [
>>> > {
>>> > …
>>> > }
>>> > ]
>>> > ...
>>> > }
>>> > —
>>> >
>>> > Where “edits”, “comments”, etc. are optional elements that coincide
>>> with our list of acceptable motivations and take the place of “body”. It
>>> would be much simpler to determine what the annotation contains. It would
>>> seem to me this would be much simpler for implementers to deal with.
>>> >
>>> > I’m sure there are drawbacks I’m not thinking of here, but thought I
>>> would throw that model out there while we’re discussing motivations.
>>> >
>>> > Another solution that would fit with the current model is to keep a
>>> list of all contained motivations at the top-level ( and keep the
>>> individual motivations attached to the bodies ). This method seems pretty
>>> “hacky”, but at least you would have an idea of what the annotation
>>> contained. Grabbing all annotations with motivation:edit would still be
>>> relatively costly.
>>> >
>>> >
>>> > - Chris
>>> > @cmbirk
>>> > (317) 418-9384
>>> >
>>> > On Tuesday, Jun 23, 2015 at 12:56 PM, Doug Schepers <schepers@w3.org>,
>>> wrote:
>>> > Hi, folks–
>>> >
>>> > Forgive me for (still) not understanding some of the subtleties of the
>>> > issues here; I'll try to make a cogent argument anyway.
>>> >
>>> > I'm strongly against the notion of restricting the number of bodies (or
>>> > targets) in an annotation.
>>> >
>>> > I look at it from the perspective of an annotator (that is, the
>>> end-user):
>>> >
>>> > Abby selects some text (the word "Julie"); she selects the "annotate"
>>> > option from some menu (e.g. context-menu, sidebar, popup, menu-bar,
>>> > keyboard shortcut, whatever). A dialog pops up, giving her the option
>>> of
>>> > leaving a comment, offering a suggested change, adding tags, and so on.
>>> > She types the comment, "Julie should be Julia, as mentioned in
>>> paragraph
>>> > 2"; she types the suggested change, "Julia"; she adds the tags,
>>> "#typo",
>>> > and "#personalname", and "#sigh".
>>> >
>>> > The resulting annotation has a single target (the word "Julie"), and 3
>>> > bodies (the comment, the replacement text, and the tags).
>>> >
>>> > A machine thinks that all these bodies apply to the target; it knows
>>> > that the replacement text is meant to substitute for the selection text
>>> > (the target); it knows that each of the tags should somehow be indexed
>>> > for search with this target and body. But it doesn't know what any of
>>> > the content /means/.
>>> >
>>> > The machine doesn't know that Abby referred both to the target and to
>>> > the instance of "Julia" in paragraph 2; it only knows about the
>>> explicit
>>> > link to the target, "Julie"; a human can use the information in the
>>> > content body, but the machine can't (unless it's a smarter machine than
>>> > we're talking about today).
>>> >
>>> > The machine doesn't know that Abby added the tag "#typo" as a signal
>>> for
>>> > the kind of correction she was offering, or that she added the tag
>>> > "#personalname" as a note for herself for a different project she's
>>> > working on, or why she added the tag "#sigh"; in fact, another human
>>> > probably wouldn't know what the tag "#sigh" means… was she bored? is
>>> she
>>> > irritated at all the typos, in which case the tag "#sigh" is actually
>>> > kind of an annotation on the tag "#typo"? was it a wistful sigh because
>>> > she loves Julia?
>>> >
>>> > None of this matters to the machine, which only needs to perform a set
>>> > of tasks:
>>> > 1) present the human reader/editor with the information, and let the
>>> > human decide if they want to accept the change;
>>> > 2) provide an affordance (say, a button) to change the selection text
>>> > with the replacement text;
>>> > 3) if the human decides to make the change, perform the change
>>> operation.
>>> >
>>> > That's it. There are other ancillary tasks, like letting users to
>>> > whole-text searches or tagged-index searches, and so on, but for the
>>> > core task we're talking about, the machine doesn't need to be any
>>> > smarter than that.
>>> >
>>> > The idea of separating out this annotation into its constituent parts
>>> > seems like overkill. I think it would surprise Abby to find that once
>>> > she's published what she saw as a single annotation, that it's broken
>>> up
>>> > into multiple annotations that have to be shared or used separately,
>>> and
>>> > she can't find her suggested change because the tag body wasn't indexed
>>> > with the replacement-text body or the comment body, and so on. To her,
>>> > it was a single act of creation, and it should be modeled that way; the
>>> > only thing we know about her intent was that she made a single
>>> > annotation, and that should be preserved.
>>> >
>>> > Maybe another annotation interface might offer different, discrete
>>> > options that elicit a different act of creation from the user, but the
>>> > data model shouldn't constrain that.
>>> >
>>> >
>>> > As argued before, there is ambiguity in this kind of annotation…
>>> >
>>> > The ambiguity arises in part because we have made a data structure that
>>> > is easy to generate and manipulate, so it is "lossy" with regards to
>>> all
>>> > the expressiveness and inter- and intra-linkages it could have, but
>>> > those would come at the price of complexity of format and stringent
>>> > requirements on the user to disambiguate intent via the UI.
>>> >
>>> > The ambiguity mainly arises because of the nature of humans, who
>>> > generate and detect complex patterns of behavior, and who have limited
>>> > means to express their thoughts or intents.
>>> >
>>> > We can't solve either of these issues. We can only decrease the
>>> > ambiguity a bit.
>>> >
>>> > Maybe another annotator, Beth, is far more precise in her annotations,
>>> > such that there is almost no ambiguity; she separates out her
>>> > annotations and is always exactly on point, she replies to her own
>>> > annotations if there is any potential ambiguity; that's even easier for
>>> > machines to "understand". But maybe another annotator, Chuck, is far
>>> > more ambiguous in his annotations, suggesting irrelevant and irreverent
>>> > changes, and adding comments and tags that are unhelpful or even
>>> > contradictory.
>>> >
>>> > Web Annotations should allow for this full range of expression, even at
>>> > the expense of machine comprehension.
>>> >
>>> > Please, let's try to keep the model simple by default, and slightly
>>> more
>>> > complex for more complicated scenarios, and limit the concessions we
>>> > make for machines when humans are the real end-users.
>>> >
>>> >
>>> > To Paolo's points about motivations vs roles, or how we structure the
>>> > annotations, or having different serializations for JSON and JSON-LD,
>>> > I'm open to any of these suggestions; I suggested "motivation" because
>>> > it seemed like it met a need, but if it has to be modeled a different
>>> > way, that's okay, too.
>>> >
>>> >
>>> > Finally, I want to suggest that if we go down a path of architectural
>>> > purity and complexity, the data model is far less likely to be adopted
>>> > by authoring tools, so let's keep that in mind.
>>> >
>>> > Regards–
>>> > –Doug
>>> >
>>> > On 6/21/15 9:17 PM, Paolo Ciccarese wrote:
>>> > > I personally think the problem is originated by the overloaded
>>> meaning
>>> > > that ‘motivatedBy’ gained with time. Originally we were using types
>>> and
>>> > > we were subclassing Annotation to specify the desire annotation type
>>> > > (for instance Comment). To avoid the types proliferation and
>>> potential
>>> > > incompatibility, we move away from that construct and we introduced
>>> > > ‘motivatedBy’.
>>> > >
>>> > > "The Motivation for an Annotation is a reason for its creation”, why
>>> we
>>> > > created an annotation is not necessarily describing how the
>>> annotation
>>> > > is shaped. The ‘motivatedBy’ for an edit is “oa:editing” weather or
>>> not
>>> > > one or more description, tags, link to existing documents are
>>> provided.
>>> > > I always thought that assuming that given a ‘motivatedBy’ I should
>>> know
>>> > > exactly how to ‘read' the annotation is a bit of a stretch… it never
>>> > > worked for me and as the current discussion proves, it does not work
>>> for
>>> > > other use cases.
>>> > >
>>> > > I’ve always considered the bookmark in Firefox as a good example. A
>>> > > bookmark consists of a URL, a description and tags. The motivation is
>>> > > still ‘bookmarking’ and the multiple bodies allow to connect all of
>>> that
>>> > > in one single annotation. It is true though that in this specific
>>> case
>>> > > we don’t have interpretation issues as the Tags are modeled with a
>>> > > specific construct and we have only one textual body.
>>> > >
>>> > > Any time I needed to model something more complex, in Domeo, I
>>> resorted
>>> > > to structured bodies and named graphs as I get all the flexibility I
>>> > > need by defining precisely the role of each item of the body.
>>> However,
>>> > > that increases the complexity of the resulting artifact.
>>> > >
>>> > > If we had to play with the current rules and introduce a role for
>>> each
>>> > > body of the annotation, one way would be to add a node like we did
>>> for
>>> > > Semantic Tags. But that will be verbose.
>>> > >
>>> > > Another way would be to change the rules and have a JSON format that
>>> > > is a compact version of the JSON-LD format, so that what Doug
>>> proposed -
>>> > > using something like hasRole in place of motivatedBy - makes sense in
>>> > > JSON and would be shaped with an intermediate node in JSON-LD. I am
>>> not
>>> > > sure somebody mentioned this already (many threads of emails went by
>>> on
>>> > > this topic) and I am not sure this would be a good idea for
>>> > > interoperability reasons.
>>> > >
>>> > > Yet another way I could think of, forgetting for a second JSON-LD,
>>> is to
>>> > > create a map of bodies so that in simple cases I would just look at
>>> the
>>> > > values of the map… and when I need to define roles I could attach
>>> that
>>> > > to the keys. Like a "bodies map".
>>> > >
>>> > > Paolo
>>> > >
>>> > >
>>> > > On Sun, Jun 21, 2015 at 6:02 PM, Robert Sanderson <
>>> azaroth42@gmail.com
>>> > > <mailto:azaroth42@gmail.com>> wrote:
>>> > >
>>> > >
>>> > > Ivan, Jacob,
>>> > >
>>> > > Yes, the pre-CG models only allowed for one body and multiple
>>> > > targets. The discussion in the CG was similar to the current one
>>> > > (one comment with several tags, edit text with reason, etc) and the
>>> > > desire to keep them as a single annotation, which led to multiple
>>> > > bodies and multiple targets.
>>> > >
>>> > > While it would be a departure from the CG's model, if there's a
>>> > > consistent, acceptable and simpler model that supports the same use
>>> > > cases, it would be good to go with that :)
>>> > >
>>> > > Rob
>>> > >
>>> > >
>>> > >
>>> > > On Sun, Jun 21, 2015 at 2:52 PM, Jacob Jett <jjett2@illinois.edu
>>> > > <mailto:jjett2@illinois.edu>> wrote:
>>> > >
>>> > > Hi Ivan,
>>> > >
>>> > > As memory serves multiple bodies and multiple targets were never
>>> > > restricted by the CG. In fact, as I recall it was designed to
>>> > > allow a number of bodies that apply equally to a number of
>>> > > targets within the context of the same motivation. This might
>>> > > have been a variety of the tagging use case that got spun out as
>>> > > a "needed" alternative to choices and composites.
>>> > >
>>> > > Regards,
>>> > >
>>> > > Jacob
>>> > >
>>> > >
>>> > >
>>> > > _____________________________________________________
>>> > > Jacob Jett
>>> > > Research Assistant
>>> > > Center for Informatics Research in Science and Scholarship
>>> > > The Graduate School of Library and Information Science
>>> > > University of Illinois at Urbana-Champaign
>>> > > 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
>>> > > (217) 244-2164 <tel:%28217%29%20244-2164>
>>> > > jjett2@illinois.edu <mailto:jjett2@illinois.edu>
>>> > >
>>> > >
>>> > > On Sun, Jun 21, 2015 at 8:47 AM, Ivan Herman <ivan@w3.org
>>> > > <mailto:ivan@w3.org>> wrote:
>>> > >
>>> > > Rob,
>>> > >
>>> > > I am sympathetic to your proposal. However, we owe to
>>> > > ourselves to look at the reasons why we departed from the
>>> > > restriction of the Annotation CG's document and introduced
>>> > > multiple bodies. Shame on me, but I do not remember the
>>> > > reasons we made the change, and I did not find the traces in
>>> > > the mailing list. Can you remind me/us (or point at the
>>> > > relevant mails) of the issues we thought of solving by
>>> > > allowing multiple bodies?
>>> > >
>>> > > Thanks
>>> > >
>>> > > Ivan
>>> > >
>>> > >
>>> > > On Fri, June 19, 2015 4:16 pm, Robert Sanderson wrote:
>>> > > > Tim, all,
>>> > > >
>>> > > > On Fri, Jun 19, 2015 at 9:06 AM, Timothy Cole
>>> > > <t-cole3@illinois.edu <mailto:t-cole3@illinois.edu>> wrote:
>>> > > >
>>> > > >> In my mind, allowing body-level motivations, at least
>>> > > for the use cases so
>>> > > >> far proposed, is simply a way to conflate what should be
>>> > > separate
>>> > > >> annotation graphs.
>>> > > >>
>>> > > >
>>> > > >
>>> > > >
>>> > > >> For example, should the protocol have a way of allowing
>>> > > posting of
>>> > > >> multiple (related or chained) annotations in a single
>>> > > transaction? (Does it
>>> > > >> already?)
>>> > > >>
>>> > > >
>>> > > > It does not. LDP does not have a notion of transactions
>>> > > at all. And (as
>>> > > > you know) we don't have a notion of sets/lists of
>>> > > annotations beyond the
>>> > > > unordered containership.
>>> > > >
>>> > > >
>>> > > >> Anyway, I don’t want to flog a dead horse, but since
>>> > > Doug asked directly
>>> > > >> about slippery slopes, I did want to elaborate on the
>>> > > trouble we might get
>>> > > >> ourselves into if we allow multiple bodies that relate
>>> > > to multiple targets
>>> > > >> and to each other in substantively different ways. I
>>> > > still do think there
>>> > > >> is a slippery slope potential here.
>>> > > >>
>>> > > >
>>> > > > This seems like a good opportunity to re-evaluate
>>> > > multiple bodies as a
>>> > > > feature at all. To my knowledge, all multiple body use
>>> > > cases have been for
>>> > > > different motivations. Most frequently it has been
>>> > > comment plus tags that
>>> > > > are all really about the same target. If we went to a
>>> > > multiple annotation
>>> > > > model for edit + comment, we could more reliably also go
>>> > > to a multiple
>>> > > > annotation model for tag(s) + comment as well. Then the
>>> > > individual
>>> > > > annotations could be addressed individually, for example
>>> > > to moderate a tag
>>> > > > without at the same time moderating the comment, or vice
>>> > > versa.
>>> > > >
>>> > > > Rob
>>> > > >
>>> > > > --
>>> > > > Rob Sanderson
>>> > > > Information Standards Advocate
>>> > > > Digital Library Systems and Services
>>> > > > Stanford, CA 94305
>>> > > >
>>> > >
>>> > >
>>> > > --
>>> > > Ivan Herman, W3C Team
>>> > > URL: http://www.w3.org/People/Ivan/
>>> > > FOAF: http://www.ivan-herman.net/foaf.rdf
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Rob Sanderson
>>> > > Information Standards Advocate
>>> > > Digital Library Systems and Services
>>> > > Stanford, CA 94305
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Dr. Paolo Ciccarese
>>> > > Principal Knowledge and Software Engineer at PerkinElmer Innovation
>>> Lab
>>> > > Assistant Professor in Neurology at Harvard Medical School
>>> > > Assistant in Neuroscience at Mass General Hospital
>>> > > ORCID: http://orcid.org/0000-0002-5156-2703
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Rob Sanderson
>>> > Information Standards Advocate
>>> > Digital Library Systems and Services
>>> > Stanford, CA 94305
>>> >
>>> >
>>> >
>>> > --
>>> > Dr. Paolo Ciccarese
>>> > Principal Knowledge and Software Engineer at PerkinElmer Innovation Lab
>>> > Assistant Professor in Neurology at Harvard Medical School
>>> > Assistant in Neuroscience at Mass General Hospital
>>> > ORCID: http://orcid.org/0000-0002-5156-2703
>>>
>>>
>>> ----
>>> Ivan Herman, W3C
>>> Digital Publishing Activity Lead
>>> Home: http://www.w3.org/People/Ivan/
>>> mobile: +31-641044153
>>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Dr. Paolo Ciccarese
>> Principal Knowledge and Software Engineer at PerkinElmer Innovation Lab
>> Assistant Professor in Neurology at Harvard Medical School
>>
>> Assistant in Neuroscience at Mass General Hospital
>> ORCID: http://orcid.org/0000-0002-5156-2703
>>
>
>
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
>
--
Dr. Paolo Ciccarese
Principal Knowledge and Software Engineer at PerkinElmer Innovation Lab
Assistant Professor in Neurology at Harvard Medical School
Assistant in Neuroscience at Mass General Hospital
ORCID: http://orcid.org/0000-0002-5156-2703
Received on Wednesday, 24 June 2015 19:47:29 UTC