Re: The Copy-Edit Use Case

Feels a bit late now but, motivation itself was a response to use cases for
exactly the types of the editorial workflows being discussed. This article
by Bob Morris (http://www.ncbi.nlm.nih.gov/pubmed/24223697) describing such
a workflow in the FilteredPush project might be relevant.

One of the open questions that lingers on is whether or not annotations
with motivated specific resources also need expectations for what actions
will be taken relative to particular motivations. With the additional
editorial workflow use cases emerging is the idea of expectation something
we need to re-examine?

Regards,

Jacob



_____________________________________________________
Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu

On Tue, Jun 16, 2015 at 3:40 PM, Siegman, Tzviya - Hoboken <
tsiegman@wiley.com> wrote:

> Motivations can be gleaned from Chicago Manual of Style or similar
> proofreaders' marks: http://www.chicagomanualofstyle.org/tools_proof.html.
>
> Tzviya Siegman
> Digital Book Standards & Capabilities Lead
> Wiley
> 201-748-6884
> tsiegman@wiley.com
>
> -----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
> >
>
>