Re: [model] Proposal: Allow motivatedBy on SpecificResource

That model still suffers from the query complexity I mentioned earlier.

- Chris @cmbirk

(317) 418-9384

On Tue, Jun 23, 2015 at 4:07 PM, 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