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 Monday, 15 June 2015 05:39:29 UTC