RE: [model] Proposal: Allow motivatedBy on SpecificResource

If the “motivation” for motivations at the body level is strictly efficiency – i.e. why create ten annotations when you can create one -  then just adopt the rule (and state it in the model) that when there are multiple bodies, they are assumed to be independent of one another (i.e. no “expectation” that any one of the bodies bears any relationship to any  other body).

Do that, and I would support body motivations.

Ray

From: jgjett@gmail.com [mailto:jgjett@gmail.com] On Behalf Of Jacob Jett
Sent: Thursday, June 18, 2015 10:02 AM
To: Doug Schepers
Cc: Cole, Timothy W; Robert Sanderson; Web Annotation
Subject: Re: [model] Proposal: Allow motivatedBy on SpecificResource

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