Re: The Copy-Edit Use Case

In the Semantic Tags thread we discussed having motivatedBy on a
SpecificResource:
    https://lists.w3.org/Archives/Public/public-annotation/2015Apr/0007.html

Which would also allow for this situation, and similar.
Also addresses https://github.com/w3c/web-annotation/issues/11

It needs to be on the SpecificResource rather than the Body itself, as the
body might participate in multiple annotations in different roles.  (A
teacher of one class can be a student of another)

Rob


On Tue, Jun 16, 2015 at 11:29 AM, Doug Schepers <schepers@w3.org> wrote:

> Hi, Davis, all–
>
> A few days ago, I was talking to some developers who have a rough (but
> functional!) implementation of a copy-edit workflow like this (though it
> doesn't yet support our data model). We didn't get into underlying syntax
> of the data model, but instead looked at the UI.
>
> Their UI included not only the selection text and substitution text, but
> also some comment about it, and it occurred to me that each of these bits
> (the substitution text, and the comment) was its own body, each with a
> distinct motivation; fortunately, the Web Annotation Data Model allows for
> an annotation to have multiple bodies; unfortunately, the Data Model (seems
> to?) apply the motivation at the annotation level, not at the body level.
>
> I'm sure there was a motivation for speccing motivations this way, but I
> wonder (Paolo? Rob?) if we can revisit it, so that each body can have its
> own motivation?
>
> Here's what I have in mind…
>
> Given this passage:
>
> "The feeling that you are stupider than you were is what finally interests
> you in the really complex subjects of life: in change, in experience, in
> the ways other people have adjusted to disappointment and narrowed ability.
> You realize that you are no prodigy, your shoulders relax, and you begin to
> look around you, seeing local color unrivaled by blue glows of algebra and
> abstraction.”
> – Nicholson Baker, The Mezzanine
>
> Let's pretend it's found at (the fictional URL):
>  http://www.nicholsonbaker.com/TheMezzanine/
>
> Let's further pretend that I'm Mr. Baker's editor, and strain the bounds
> of credulity by supposing that my suggestion to change the word "change" to
> something more grandiose is well-considered.
>
> I select the word, and a little box pops up for my comment; I type,
> "'Change' is a bit dry, why don't you punch it up a bit?", and select the
> "suggest" option, which opens another text field for the substitution text,
> in which I type, "transformation".
>
> The annotation app represents this in the following JSON-LD:
>
> {
>   "@id": "http://example.org/anno1",
>   "@type": "oa:Annotation",
>   "body": [
>     {
>       "@id": "http://example.org/body1"
>       "motivation": "oa:commenting",
>       "value" : "'Change' is a bit dry, why don't you punch it up a bit?",
>     },
>     {
>       "@id": "http://example.org/body2"
>       "motivation": "oa:editing",
>       "value" : "transformation",
>     }
>   ],
>   "target": {
>     "source": "http://www.nicholsonbaker.com/TheMezzanine/",
>     "selector": {
>       "@id": "http://example.org/selector1",
>       "@type": "oa:TextQuoteSelector",
>       "exact": "change",
>       "prefix": "subjects of life: in ",
>       "suffix": ", in experience, in t"
>     }
>   }
> }
>
> Both of these bodies apply to the target, but each has its own goal in
> doing so, and each could have different representations and options in
> different annotation clients. Obviously, not all annotation clients would
> present such copy-editing features, but that doesn't affect the utility of
> enabling the use-case.
>
> Assuming we can make such a change to the data model, should we also
> explicitly take the extra step to define expected behavior, and perhaps
> even setting conformance criteria? For example, we could define a class of
> conforming User Agent, a Copy-Editing UA, and put requirements on that
> class of UA that when given an annotation with a body with an "editing"
> motivation and a text-quote selector, it must offer the option to
> substitute the "value" of the body for the "exact" of the target selector
> (and if there are multiple bodies with an "editing" motivation, offer each
> as an option).
>
> Would that fit in the data model spec, or should there be another spec
> that defines such behaviors, and which would presumably also talk about how
> to use the Annotation Protocol to create, send, download annotation in the
> Web Annotation Data Model, and how to apply the selectors from the data
> model to anchor them in the document using the RangeFinder API, and so on?
>
> Regards–
> –Doug
>
>
> On 6/16/15 12:25 PM, Salisbury, Davis - Hoboken wrote:
>
>> Hi Doug,
>>
>> Thanks for sharing this part of the conversation. Very useful use
>> cases, and in line with Kryce's recent set involving the "Instructor"
>> and "Student" audience dynamic. This is another variation in regards
>> to making an annotation "pubic" etc.
>>
>> I just want to clarify this part of the use case scenario:
>>
>>  A serious question is, how much more structured would the
>>>> annotation have to be in order to enable this use case?
>>>>
>>>> For example, here's a couple of different conventions of how the
>>>> same copy-editing (ignore the syntax and tokens):
>>>>
>>>> Informal: [[ <link and selectors to fragment> {selection:{their
>>>> chanes were slim}}
>>>>
>>>> (body:{I think you mean, "their chances", not "chanes".}}
>>>> {motivation:{editing}} ]]
>>>>
>>>>
>>>> Formal: [[ <link and selectors to fragment> {selection:{their
>>>> chanes were slim}}
>>>>
>>>> {body:{their chances were slim}} {motivation:{editing}} ]]
>>>>
>>>> The former seems difficult to automatically integrate; the latter
>>>> is easy to do so, but would need to have guidance or clever
>>>> defaults in the annotation UI to elicit the proper formatting
>>>> from the annotator.
>>>>
>>>>
>>>> I think the Web Annotation Working Group, and the Data Model
>>>> spec, would greatly benefit from some pragmatic experience in
>>>> such use cases, to inform how it specifies options like this.
>>>>
>>>
>> I take it this is just in regards to providing the actual
>> substitution text, i.e., if the annotation can be "accepted" in order
>> to literally implement the change, of course there needs to be an
>> exact set of text to act as the accepted text. So yeah, I would think
>> that the second option is really the only viable one, with perhaps
>> any supplementary comments existing as a companion to the replacement
>> text.
>>
>> Thanks, Davis
>>
>> -----Original Message----- From: Doug Schepers
>> [mailto:schepers@w3.org] Sent: Monday, June 15, 2015 1:39 AM To: W3C
>> Public Annotation List Subject: The Copy-Edit Use Case
>>
>> Hi, folks–
>>
>> In a recent side conversation with Wiley and Hypothesis, the talk
>> turned from high-level questions and thoughts to concrete use cases
>> and technical questions. At that point, we agreed to redirect and
>> continue the conversation on this list. (I'm BCCing those
>> participants, in case they want to continue onlist.)
>>
>> To kick off conversation here, I'm going to republish my own initial
>> thoughts from that thread; I won't include any of the parts from
>> others, but to set the stage, the topic was raised of "actionable
>> annotations", and specifically, the copy-editing use case.
>>
>> The notion is that some annotation systems, in addition to doing
>> comments, may allow distributed, interoperable copy-editing
>> functionality. Below, I describe a (somewhat convoluted) example of
>> what that might look like in practice, and some open questions.
>>
>> (My apologies if this seems overly complex, but it's just a
>> strawman. Reactions very welcome.)
>>
>> ==========
>>
>> This [copy-editing action] may be at least partly solved by the
>> "motivation" feature of the Web Annotation Data Model spec [1];
>> specifically, the "editing" value (or something similar, if we need
>> more specific about copy-editing).
>>
>> I'd love to see different authoring/publishing tools integrate
>> copy-editing workflow, to enable use cases like:
>>
>> Reader Anne sees a typo on blog post X by author Dinah, highlights
>> it, and creates an annotation that has the correction as the body,
>> and "editing" as the motivation (via a dropdown or some other UI);
>> they publish the annotation on their own favorite annotation service,
>> setting the access permissions as "public".
>>
>> Reader Baseema, who subscribes to Anne's annotations, reads blog post
>> X. However, because Baseema only subscribes to annotations with the
>> motivations "commenting", "replying", "highlighting", and "tagging",
>> Baseema does not see Anne's annotation, which has the "editing"
>> motivation. Baseema sees the same typo as Anne, and changes their
>> annotation client to "editing" mode, to report the typo; in this
>> mode, Baseema sees all the public "editing" annotations, including
>> the public one by Anne, so Baseema merely "upvotes" Anne's annotation
>> (a simple form of annotation). Anne receives a notification that
>> Baseema has annotated their annotation.
>>
>> Reader Cesar also reads blog post X, and thinks the author has
>> misused a word; Cesar leaves an annotation suggesting a different
>> word, with the "editing" motivation.
>>
>> Author Dina, who wrote the blog post, receives notifications that
>> someone made a public annotation about their blog post with the
>> "editing" motivation. Dina goes into their blog software's authoring
>> interface, and loads those annotations in from the URLs; the blog
>> software, seeing that the motivations are "editing", provides an
>> option to accept the changes; Dina accepts Anne's change with the
>> click of a button, and the correction text replaces the selected text
>> automatically, updating the blog post. Dina doesn't agree with
>> Cesar's word choice, so she clicks a button to reject the annotation,
>> which is then hidden from her view by default; however Dina does
>> change the word to a clearer term (a more advanced or complicated
>> interface might allow this to be an option, giving Cesar positive
>> feedback for helping improve the text). Dina accepts or rejects
>> several other "editing" suggestions, based on their merits.
>>
>> Accepting or rejecting "editing" annotations is itself a simple form
>> of annotation. Anne and Cesar receive notifications that their
>> annotations were annotated by Dina; depending on their service and
>> settings, Baseema may also receive a notification that Anne's
>> annotation was annotated (accepted).
>>
>>
>>
>>
>> A serious question is, how much more structured would the annotation
>> have to be in order to enable this use case?
>>
>> For example, here's a couple of different conventions of how the same
>> copy-editing (ignore the syntax and tokens):
>>
>> Informal: [[ <link and selectors to fragment> {selection:{their
>> chanes were slim}}
>>
>> (body:{I think you mean, "their chances", not "chanes".}}
>> {motivation:{editing}} ]]
>>
>>
>> Formal: [[ <link and selectors to fragment> {selection:{their chanes
>> were slim}}
>>
>> {body:{their chances were slim}} {motivation:{editing}} ]]
>>
>> The former seems difficult to automatically integrate; the latter is
>> easy to do so, but would need to have guidance or clever defaults in
>> the annotation UI to elicit the proper formatting from the
>> annotator.
>>
>>
>> I think the Web Annotation Working Group, and the Data Model spec,
>> would greatly benefit from some pragmatic experience in such use
>> cases, to inform how it specifies options like this.
>>
>>
>> [1] http://www.w3.org/TR/annotation-model/#motivations
>>
>> Regards– –Doug
>>
>>
>


-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305