Re: [model] Proposal: Allow motivatedBy on SpecificResource

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