Re: [model] Proposal: Allow motivatedBy on SpecificResource

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