RE: The Copy-Edit Use Case

Agreed Doug, I would have liked to have edited that email hah hah.

-----Original Message-----
From: Doug Schepers [mailto:schepers@w3.org] 
Sent: Tuesday, June 16, 2015 2:31 PM
To: Salisbury, Davis - Hoboken; W3C Public Annotation List
Subject: Re: The Copy-Edit Use Case

Too bad we don't have a copy-edit annotation feature on our email archives. :P

On 6/16/15 12:35 PM, Salisbury, Davis - Hoboken wrote:
> Yikes! That was supposed to say "public", i.e.:
>
>>> "This is another variation in regards to making an annotation 'public' etc."
>
> Obviously I need to eat lunch.
>
> Sorry about that folks.
>
> Regards,
> Davis
>
> -----Original Message-----
> From: Salisbury, Davis - Hoboken [mailto:dsalisbury@wiley.com]
> Sent: Tuesday, June 16, 2015 12:26 PM
> To: Doug Schepers; W3C Public Annotation List
> Subject: RE: The Copy-Edit Use Case
>
> 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:48:21 UTC