- From: Doug Schepers <schepers@w3.org>
- Date: Tue, 23 Jun 2015 18:41:36 -0400
- To: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- CC: Robert Sanderson <azaroth42@gmail.com>, Chris Birk <cmbirk@gmail.com>, Ivan Herman <ivan@w3.org>, Jacob Jett <jjett2@illinois.edu>, Web Annotation <public-annotation@w3.org>
Hi, Paolo–
Thanks for explaining. I'm afraid I don't understand your explanation,
but I'll keep gnawing on it.
(In particular, I don't know why you needed to choose 'role' vs
'motivation', nor really what is meant by a "blank node".)
For now, I'll accept that this is somehow what's necessary to satisfy
the constraint. If this works for others, it works for me.
Regards–
–Doug
On 6/23/15 5:33 PM, Paolo Ciccarese wrote:
> Basically what I called 'content' is the old body concept.
> So this is introducing the level of indirection we have for Semantic Tags.
> That way the 'role' (not motivation on purpose) is not going to attach
> directly to a URL of a webpage in the global space but to a blank node.
>
> {
> "body": [
> {
> "role": "edit",
> "content": {
> "value": "newcontent"
> }
> },
> {
> "role": "comment",
> "content": {
> "@id": "http://example.org/EDITexplanation.html"
> }
> }
> ]
> }
>
> On Tue, Jun 23, 2015 at 5:23 PM, Doug Schepers <schepers@w3.org
> <mailto:schepers@w3.org>> wrote:
>
> Hi, Paolo–
>
> Actually, that works fine for me.
>
> It's slightly more verbose, but it's not unreasonable. Can you
> describe how this is functionally different than what I suggested in
> the other thread [1]?
>
> For example:
>
> {
> "body": [
> {
> "role": "edit",
> "value": "newcontent"
> },
> {
> "role": "comment",
> "value": "This needed changing"
> }
> ]
> }
>
>
> [1]
> https://lists.w3.org/Archives/Public/public-annotation/2015Jun/0107.html
>
>
> Regards–
> –Doug
>
> On 6/23/15 4:07 PM, Paolo Ciccarese 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 <mailto:azaroth42@gmail.com>
> <mailto:azaroth42@gmail.com <mailto: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 <mailto:cmbirk@gmail.com>
> <mailto:cmbirk@gmail.com <mailto: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 <tel:%28317%29%20418-9384> <tel:%28317%29%20418-9384>
>
> On Tuesday, Jun 23, 2015 at 12:56 PM, Doug Schepers
> <schepers@w3.org <mailto:schepers@w3.org>
> <mailto:schepers@w3.org <mailto: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>
> <mailto:azaroth42@gmail.com <mailto:azaroth42@gmail.com>>
> > <mailto:azaroth42@gmail.com
> <mailto:azaroth42@gmail.com> <mailto: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>
> <mailto:jjett2@illinois.edu <mailto:jjett2@illinois.edu>>
> > <mailto:jjett2@illinois.edu
> <mailto:jjett2@illinois.edu> <mailto: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>
> <tel:%28217%29%20244-2164>
> <tel:%28217%29%20244-2164>
> >jjett2@illinois.edu <mailto:jjett2@illinois.edu>
> <mailto:jjett2@illinois.edu <mailto:jjett2@illinois.edu>>
> <mailto:jjett2@illinois.edu
> <mailto:jjett2@illinois.edu> <mailto: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> <mailto:ivan@w3.org
> <mailto:ivan@w3.org>>
> > <mailto:ivan@w3.org <mailto:ivan@w3.org>
> <mailto: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> <mailto:t-cole3@illinois.edu
> <mailto:t-cole3@illinois.edu>>
> <mailto:t-cole3@illinois.edu
> <mailto:t-cole3@illinois.edu> <mailto: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
>
>
>
>
> --
> Dr. Paolo Ciccarese
> ORCID: http://orcid.org/0000-0002-5156-2703
Received on Tuesday, 23 June 2015 22:41:41 UTC