Re: [model] Proposal: Allow motivatedBy on SpecificResource

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