Re: [model] Proposal: Allow motivatedBy on SpecificResource

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].


> 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.

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.


> 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 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?

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.


> * 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.

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.

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?


(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?

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



> 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
>

Received on Thursday, 18 June 2015 07:24:48 UTC