Re: [model] Proposal: Allow motivatedBy on SpecificResource

That being said, if the bodies are assumed to be independent, then Jacob’s argument holds true that a comment must annotate the edit.


I strongly agree with the fact that one of the strongest aspects of the annotation model is that the annotation is in some way “about” the target, and that the comment should be an annotation on the edit.  If someone “resolves” ( if we decide to have some concept of resolution ) the edit, the comment cannot stand alone.


- Chris @cmbirk

(317) 418-9384

On Thu, Jun 18, 2015 at 10:04 AM, Jacob Jett <jjett2@illinois.edu> wrote:

> Hi Doug,
> This is an issue we discussed in the community group to some length. I'll
> try to address your points in-line below.
> On Thu, Jun 18, 2015 at 2:24 AM, Doug Schepers <schepers@w3.org> wrote:
>> Hi, Tim, Rob–
>>
>> On 6/17/15 12:47 PM, Timothy Cole wrote:
>>
>>> Rob-
>>>
>>> Consistent with Ray’s comments on today’s call about the copy-edit
>>> use case, I think your use cases are better addressed by separate
>>> annotations rather than by the added complications of motivations
>>> added to annotation bodies.
>>>
>>
>> Is that really what Ray was saying? I understood him differently. In the
>> past, he's argued for having multiple bodies in the same annotation,
>> each with its own motivation [1].
>>
>>
> You're right, Ray has argued for multiple body annotations in the past but,
> that was not my understanding of what he was saying yesterday. The problem
> is ambiguity. People are well equipped to handle ambiguities and our
> natural language is loaded with features that exploit them. Machines are
> ill-equipped to manage them.
>>
>>  As you correctly point out, at the very least to allow motivation on
>>> the body you would have to create your bodies as SpecificResources
>>> which is an additional complication. I would argue that this is true
>>> even if the body is textual, i.e., since the text string is not
>>> inherently a replacement except in the context of the annotation
>>> (though I accept this is a nuance we could probably ignore without
>>> much harm).
>>>
>>
>> I agree that requiring a SpecificResource as a body is an additional
>> complication; I would argue that in the default case, we shouldn't need
>> that, even if we include a separate motivation on each body.
>>
>>
>>  To Doug’s point about keeping simple use cases simple, it is much
>>> simpler from a modeling perspective to have one annotation which is
>>> the correction itself and another annotation (as needed) that
>>> explains the rationale for the correction.
>>>
>>
>> I'm not sure I agree that it is simpler, nor that it matches expectations.
>>
>>
> I'm not certain what you're going for with expectations here. If there is a
> notion that a user could just load up a bunch of annotations into onto a
> single target through a single oa:Annotation node, then as this discussion
> highlights, the roles that the individual bodies play are ambiguous to the
> machine.
> I know we want to do this for the sake of efficiencies. If I have a bunch
> of tags to apply to a single target, it's quicker and easier to just wrap
> them up into one annotation. This works okay when I have a single
> motivation that describes the role that all of the bodies are playing.
>> Let's assume each annotation is a distinct document, not just a data
>> structure. From a storage, sharing, and client perspective, splitting
>> those up into separate documents seems like a bad idea, and doesn't seem
>> like it would capture the intent of the annotator, who thought they were
>> making a single annotation.
>>
>>
> This is quite a stretch. We actually have no way of capturing annotator
> intentions. They might be annotating simply because they're feeling
> contrary.
> In the case of annotating in the context of editorial workflows, Bob Morris
> and Phil Morris in the CG face-to-face meetings both argued that having a
> distinct expectation property is significantly helpful (and IMO necessary)
> to capture annotator intentions (inasmuch as is possible without some kind
> of thought police) and at the very least can be leveraged by machines to
> execute any desired edits.
> Unfortunately this use case is something of a slippery slope for us. In the
> CG, no one wanted a property that expressed expectations because it further
> complicated what was (and is) already a complex model. If we need to fully
> integrate the editorial use case then we probably need to re-examine this
> CG decision.
>>  In simple copy-edit cases, the second annotation would rarely be
>>> needed (more specific motivations on the annotation might be needed
>>> – e.g., edit-insertion, edit-deletion, edit-replacement,
>>> edit-transpose, …). When the second annotation is needed, e.g., a
>>> comment about supporting the edit, keeping it separate from the
>>> copy-edit annotation would allow for the use a multi-target
>>> annotations, e.g., “these 10 proposed edits (each its own
>>> annotation) were all needed because….” – that’s a single annotation
>>> targeting the ten copy-edit annotations.
>>>
>>
>> I agree that you can model it this way, if you're applying a single
>> annotation needs to target multiple other annotations, but I also think
>> that you should be able to maintain a simple association (multiple
>> bodies) for the more common case when you have a single body with an
>> "edit" motivation and an accompanying body with a "comment" motivation,
>> both applying to the same target.
>>
> I'm not sure what we're going for with this kind of structure. What is my
> annotation consuming client supposed to do with it? How am I supposed to
> interpret an annotation that both edits the target and comments on the
> target?
> I mean, it seems clear that for the sake of efficiency we have clearly let
> a bunch of semantic infelicities creep in. If I understand the intention
> correctly, it is not the case that the annotator is commenting on the
> target; rather, the intention was to comment on the act of editing, was it
> not?
> Because of the way the annotation model is built, there's no way to
> actually get that interpretation out of the annotation, even if we have a
> motivation on each body. At best the machine will see the following "body A
> an edit annotating target 1", "body B a comment annotating target 1". There
> is no way to get the desired interpretation -- "body B a comment annotating
> [edit annotating target 1]"
> As Ray and Tim both point out, the only way to make the semantics work is
> if the comment is a separate annotation targeting the annotation that
> asserts the edit.
>> I understand that that may introduce some ambiguous entailment about
>> whether the "comment" body is meant to apply to the "edit" body, the
>> target, or both. But I believe that in many cases, that annotation
>> author's intent is subject to multiple interpretations (e.g. "I'm
>> suggesting the target be changed, because…", "I'm suggesting this
>> replacement be used, because…", and "I'm suggesting the target be
>> changed to this specific replacement, because…" are all intrinsic and
>> valid interpretations; human language and motivation is messy, and no
>> amount of prescriptive modeling will change that).
>>
>>
>>  And of course that copy-edit annotations are modeled as individual
>>> annotation is easily hidden from the human editor by the interface
>>> when appropriate – e.g., change all occurrences of Rbb to Rob looks
>>> to the human editor like a single copy-edit in the interface. The
>>> fact that there is a Rbb to Rob copy-edit annotation for each of the
>>> 10 occurrences of Rbb in the document is handled by the software
>>> behind the interface.
>>>
>>
>> Wouldn't that be better modeled as a single annotation, with a single
>> "edit" body and 10 different targets?
>>
> Yes. You still cannot use a second body in that annotation to comment on
> the editing because the act of editing is not the target of that body. The
> semantics only work if the comment is an annotation targeting the "edit"
> annotation that has 10 different targets.
>> Obviously, it depends on the workflow, and what the tool lets you do.
>>
>> (A sophisticated copy-edit annotation tool might let you search the text
>> and automatically create targets for all instances of a word or phrase;
>> for that matter, it might even offer a corrected spelling, or find
>> misspelled word for evaluation… but I digress.)
>>
>>
>>  As for the other use cases you mention, I think the same logic
>>> applies:
>>>
>>> * A single annotation that has both tags and a comment about the
>>> target is really a tagging annotation and commenting annotation or a
>>> tagging annotation and comment annotation on the tagging annotation.
>>> (Note in this case that there is a nuanced distinction possible by
>>> keeping the annotations separate that is not possible when you
>>> conflate.)
>>>
>>
>> There's also a nuanced distinction possible by keeping the annotations
>> together that is not possible when you separate them. Again, true intent
>> is hard to nail down.
>>
>>
> As noted, we have no way to prognosticate on intentions. At best we can
> make some assumptions but, assumptions are dangerous things. Seems like
> there's a popular idiom for this...
> If we want to capture and remark upon annotator intentions (beyond simple
> motivations) then we need additional properties. Again this article (
> http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3817185/) seems highly
> pertinent. Not only have the authors extended the CG annotation model with
> an expectation property that describes what the workflow is supposed to do
> with the edit but they also have a property that captures evidence that
> supports why the edit is necessary.
> Ultimately though, the addition of more properties means the model will
> become more complicated...so we should probably tread lightly and consider
> to what extent we can really support editorial workflows and what should be
> left for them to add to the model through extensions.
>>
>>  * A single annotation that has a moderation up-vote, and a comment
>>> explaining why the moderation should be considered is an up-vote
>>> annotation and an explanation annotation on the up-vote annotation
>>> (note, not an explanation annotation targeting what is being voted
>>> on).
>>>
>>
>> Again, I don't think it's always simple to make that judgment, at least
>> not without requiring the annotator to jump through too many hoops.
>>
> Here's the crux of the matter. Efficiency (or --forgive me for being
> blunt-- laziness). Sometimes the annotator has to jump through hoops or
> they simply can't have all of the functionality that they desire. We could
> conflate the edit and the comment but then it is never the case that the
> comment is actually about the edit. The way multiple bodies (and single
> bodies too) work, is that *THEY ARE ALWAYS ABOUT THE TARGET*. Sorry, I
> don't think that I could stress that enough. It's the primary feature of
> the annotation model. A body is "about" the target (in some way, even if
> that isn't a topical way).
> The use case you describe with two bodies possessing different motivations,
> even though the motivations are different, the bodies still apply to the
> *same* target. If they don't then what you're describing does not conform
> to the annotation model (and I personally find the semantics weird -- I'm
> no longer sure what it's trying to tell me; there's an edit of the target
> and a comment about the target but not really because it's secretly about
> the edit...but the model doesn't support that interpretation of the graph's
> chain of assertions...)
>> If I have a single annotation with a comment and a tag, is my tag about
>> the target content or about my comment, or both (or neither, and I'm
>> irrelevantly expressing my mood)? It depends on my specific intent.
>>
> Actually, it must be about the target. That's the primary tenant of the
> model...
> ...and as for specific intentions...where was my crystal ball again?
>> Yes, we could allow the user to control that, but can you imagine how
>> user-hostile such a UI/UX would have to be? People don't tend to like
>> pedantic user interfaces.
>>
>>
>>  Finally, my reason for mentioning more complex copy editing use
>>> cases was meant to invoke the slippery slope argument, if we make a
>>> model change to allow annotations on bodies to make our annotations
>>> more human-readable and to save on the number of annotations minted
>>> in order to address simple use cases, we can anticipate that users
>>> will abuse this capacity to handle arbitrarily complex use cases
>>> conflating what should be distinct annotations.  There’s no
>>> reasonable way to preclude this and I just don’t yet see the carrot
>>> for introducing motivation at the body level – but I’m willing to be
>>> convinced if someone can come up with the use case that can only be
>>> handled by motivation on the body (rather than separation into
>>> separate annotations with motivation on the annotation).
>>>
>>
>> Can you explain what slippery slope you're talking about? What kind of
>> arbitrarily complex use cases do you have in mind?
>>
>> The slippery slope is two fold.
> 1) If the annotation model is to work as you propose then we can no longer
> rely on bodies being "about" the targets. This implies that the following
> sections (http://www.w3.org/TR/annotation-model/#introduction) and (
> http://www.w3.org/TR/annotation-model/#annotation) will require major
> revisions with regards to their scoping statements and explanations.
> 2) The editorial workflow is a use case we must accommodate then it has
> been adequately demonstrated (here (
> http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3817185/) and elsewhere) that
> additional properties on multiple entities in the model are likely
> necessary.
>>
>> (Keep reading for my replies to Rob…)
>>
>>  -Tim Cole
>>>
>>> *From:*Robert Sanderson [mailto:azaroth42@gmail.com] *Sent:*
>>> Tuesday, June 16, 2015 3:55 PM *To:* Web Annotation *Subject:*
>>> [model] Proposal: Allow motivatedBy on SpecificResource
>>>
>>> Currently the motivation for an Annotation is associated only with
>>> the Annotation, however the different bodies of a single Annotation
>>> may have different motivations for their inclusion.
>>>
>>
>> That's my goal, yes.
>>
>>
>>  The current model:
>>> http://www.w3.org/TR/annotation-model/#motivations
>>>
>>> Use cases that have come up include:
>>>
>>> * A single annotation that has a body that is the replacement edit
>>> for the target, and a body that is a comment about the change
>>>
>>> * Motivations cannot be associated directly with the body resource,
>>> as the body may be used in multiple annotations, with different
>>> motivations. They might also be the target of a different
>>> Annotation, and motivation is exclusively tied to the Annotation that
>>> asserts it.
>>>
>>> Therefore, a SpecificResource is needed to stand for the resource in
>>> the context of the Annotation.
>>>
>>
>> Can you explain the necessity for this a bit more?
>>
> If the body is a b-node (i.e., a string of text) then it'll have a
> different identity in every annotation...that means you'd have to annotate
> every instance. Whereas if it's a specific resource then it has one unique
> global identity and you need only annotate it once.
>> We should definitely enable the case where someone can reference the same
>> body in multiple annotations, but not at the expense of complicating the
>> most common case, where a body applies to a single annotation.
>>
>> Isn't there some approach that would allow the body to have a motivation
>> directly, while also allowing a SpecificResource to model a more complex
>> use case?
>>
>>
>>
>>  By associating the Motivation with the SpecificResource we would be
>>> clear regarding which resource the motivation applies to.
>>>
>>> If the Annotation and a SpecificResource both assert a motivation,
>>> the SpecificResource's motivation would take precedence for its
>>> source resource.
>>>
>>
>> Couldn't this precedence of ordering (in CSS, this is called the
>> "specificity of the cascade") equally apply to a body, not just a
>> SpecificResource?
>>
>> [1]
>> https://lists.w3.org/Archives/Public/public-annotation/2015Mar/0056.html
>>
>> Regards–
>> –Doug
>>
>>
>>
> Apologies for sounding flip. What is being suggested isn't just an added
> feature to the model to service a single use case. It has direct
> implications for the model's core semantics, that the body's content can
> *reliably* be interpreted as being "about" the target's content in some
> manner. If some of the bodies are actually about other bodies or the
> relationship between those bodies and the targets, then the model's
> semantics are no longer reliable...
> Regards,
> Jacob
>>
>>
>>  This would allow, for example:
>>>
>>> <> a oa:Annotation ;
>>>
>>> oa:hasBody _:tag1sr, _:comment1sr ;
>>>
>>> oa:hasTarget <http://example.org/paris.jpg >
>>>
>>>
>>>  .
>>
>>>
>>> _:tag1sr a oa:SpecificResource ;
>>>
>>> oa:motivatedBy oa:tagging ;
>>>
>>> oa:hasSource _:tag1 .
>>>
>>> _:tag1 a oa:EmbeddedContent ;
>>>
>>> rdf:value "paris" .
>>>
>>> _:comment1sr a oa:SpecificResource ;
>>>
>>> oa:motivatedBy oa:commenting ;
>>>
>>> oa:hasSource _:comment1 .
>>>
>>> _:comment1 a oa:EmbeddedContent ;
>>>
>>> rdf:value "I think this is photo is of Paris because I can see the
>>> Eiffel Tower."
>>>
>>> Rob
>>>
>>>
>>> --
>>>
>>> Rob Sanderson
>>>
>>> Information Standards Advocate
>>>
>>> Digital Library Systems and Services
>>>
>>> Stanford, CA 94305
>>>
>>>
>>