Re: The Copy-Edit Use Case

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
>

Received on Tuesday, 16 June 2015 18:29:35 UTC