RE: [model] Proposal: Allow motivatedBy on SpecificResource

 From: Doug Schepers [mailto:schepers@w3.org]
> 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?   ...

Yes and no.  If you have an edit to apply to a resource, and a comment on that edit, I am not arguing that they should be separate annotations on the resource. Rather that the comment should be an annotation on the edit.  That's what I said at the call, and I think Tim was trying to characterize it correctly but gave the abbreviated version.

...In the past,
> he's argued for having multiple bodies in the same annotation, each with its
> own motivation [1].

I don't think I have argued that, and at present, I am not convinced either way.   If we model it as separate annotations on the resource, as Rob argues, there isn't any way (presently) to associate the comment with the edit.  However, let's say we allow both the edit and comment bodies in the same annotation each with its own motivation.   I'm not sure that solves the problem.  Suppose someone submits an edit and an unrelated comment both in the same annotation.  How would you indicate that the separate bodies are related or not, and how they are related.  This could get pretty complicated. 

Tim argues that  in order to allow motivation on the body you would have to create the body as a SpecificResource.  But I'm not sure why.

Is the reason that you cannot just say:

oa:hasBody <body1>

but instead you have to create an intermediate resource so that you can include the motivation property.
e.g.
<spbody> a oa:SpecificResource ;
    oa:hasSource <body1> ;
    oa:hasSelector <selector1>  ;
  oa:motivatedBy  oa:Commenting .

But it seems to me you could instead create a blank node:

oa:hasBody     xyz 
xyz   oa:hasSource <body1> ;
  oa:motivatedBy  oa:Commenting .

You may have to tweak a definition or two to do this, but it seems like creating a specific resource is an unnecessary workaround. 

Perhaps I'm misunderstanding.

Ray

> 
> 
> > 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 13:06:53 UTC