Effecting edits via electronic annotations

P.J. Brown
Department of Computer Science, University of Exeter, Exeter EX4 4QF, UK
e-mail: P.J.Brown@exeter.ac.uk

ABSTRACT

Todo

Introduction

Annotation has a variety of uses. Our purpose here is to examine one usage, the reviewing of documents by third parties, and see how electronic annotations can help.

The need

A common sequence of events is:

  1. an author writes a document. We call this the base document.
  2. a second person, who we will call the reviewer, is asked, either by the author or a third party (e.g. an editor), to comment on the document. The reviewer makes two types of suggestion. The first is a set of comments. Often there is one comment that applies to the whole document, i.e. an overall review, and a lot of individual comments attached to particular parts of the document, e.g. paragraphs or words. Each individual comment has an anchor, which specifies the part of the document the comment is attached to. The second type of suggestion, a much more specific one, is an explicit edit: the reviewer suggests insertions, deletions or replacements to the original. We call these edit-annotations. Edit-annotations may range from corrections of typos to suggested rewordings of whole paragraphs. Edit-annotations may have comments attached to them, e.g. `This [suggested rewording] is more likely to appeal to an international audience'. Occasionally edit-annotations may be relatively complex `macro' operations, such as interchanging two paragraphs.
  3. the reviewer's suggestions are passed back to the author.
  4. the author produces a revised paper, i.e. creates a new base document. When doing this the author will sometimes accept a reviewer's suggestion and sometimes will ignore or change it.
We call the above the reviewing process.

Performing the reviewing process using paper

If the reviewing process is performed using paper, it works reasonably well. Indeed paper has been used successfully for hundreds of years. The reviewer writes her suggestions as annotations on the paper, and perhaps writes a separate sheet with her overall comments. Each annotation is anchored to a part of the document; the anchor is often specified by circling it. There is no formal mechanism for having different types of suggestion, but conventions such as proof-reading marks may be used to achieve this, e.g. to show insertions and deletions.

The main weakness of the reviewing process using paper is at the last above stage, i.e. stage (4). The author may accidentally overlook some of the reviewer's suggestions, and, for suggested edits, may accidentally perform them wrongly. There may also be problems in reading the reviewer's handwriting.

Another weakness of paper may apply in the third stage when author and reviewer are far apart. The postal system may need to be used to transmit the document, or an imperfect facsimile system may be used.

Nevertheless, people have learned to live with these weaknesses.

Performing the reviewing process electronically

The purpose of this paper is to examine how the reviewing process can be done electronically. The reviewer has an electronic copy of the paper, and adds electronic annotations to it: these can easily be transmitted back to the author. Of course, the reviewing process is already often done electronically in practice, though often only at a very basic level: the reviewer may produce a single electronic document that refers to the base document by means such as `page 6, line 5'. We wish to explore carrying the process to the level where the reviewer can specify her suggested edits by annotations, and the author can then choose to effect a suggested edit: i.e. to cause the original original document to be changed according to the reviewer's instructions. This avoids re-typing and the chance of error.

The specific focus of this paper is on effecting edits, since we believe that this is of interest and great potential benefit. One way of differentiating an edit-annotation from other forms of annotation is that the former can be effected to change the content of the base document.

An aid to effecting annotations is for the review to give a type to each edit-annotation such as `comment', `insertion', etc. We refer to this later.

User interface for the reviewer

A reviewer of a document on paper cannot change what is printed on the paper. Thus he needs to write his comments in the margins, or, e.g. when the document is double-spaced, between the lines.

For an electronic document it is possible to provide an interface where the image of the base document is changed. Thus if the reviewer suggests adding a new sentence, this can be added within the original document, and the rest of the original document shifted down to make room. Clearly the reviewer's comments need to be differentiated from the original. One way of doing this, if the original is in black-and-white, is to use colour for for the reviewer's comments.

Thus in designing an interface for electronic reviewing there is a choice between (a) using an interface that closely mirrors what the reviewer of a paper document would do (e.g. comments in margins), or (b) taking advantage of the flexibility of electronic documents to produce an interface natural for the task. Overall we favour (b), though many reviewers may initially favour (a), since it is a familiar practice.

One existing approach that uses (b) is Fluid Annotations (Zellweger et al, 2001). Fluid Annotations are, in fact, designed to cover all sorts of annotation -- not just edit-annotations. They are, however, especially appropriate for edit-annotations.

Multiple reviewers

Often there are several reviewers of the same base document. For refereeing of journal articles, it is usually required that the separate referees are independent of one another, and do not see their fellow referee's comments until after the refereeing process is complete. This situation can therefore be regarded at a set of independent single reviews, and does not require special treatment. (However a merging tool, which shows all the referee's annotations together, may be useful to the author.)

Sometimes there may be collaborative reviewing: many referees adding their comments to the same document. The comments may even contradict what a previous referee has said. This "groupware" situation is covered by several existing annotation systems, but is not our interest here. We therefore have not made special provision for it.

Our approach

We are performing an experiment to test the value and practicality of effecting annotations. As a starting point we need a notation for representing edit-annotations -- and one which covers other sorts of annotations too. We chose a simple HTML-based notation -- see below. An alternative would have been to follow the notation used by an existing annotation system, but unfortunately there is no standardisation here, and we do not want to be too tied to a particular system.

We also need tools to:

  1. display the annotations on a document.
  2. create and change annotations. This will be used by reviewers and perhaps by authors too. Clearly annotations can be created by hand, just by writing HTML, but for a production application a tool with a visual interface is needed. This could, in principle, be any existing annotation system that the user likes, coupled with a small utility to convert its notation into our simple HTML-based one.
  3. effect edit-annotations. This will perform replacements, insertions and deletions, but will leave any annotations that are not edit-annotations unchanged.

Todo: user can view annotations or annotations as done; browser support not good, but Opera seems best -- but user still needs to choose the style; currently crude -- easier authorship tools could be added; problems: nesting, effecting not done yet, links to relative-addressed files.

Use of HTML

Our experiment used HTML. Thus it was assumed the base document was written in HTML. The use of HTML has especial advantages if the base document and its annotations are to be shared by publishing them on the web. Obviously our experiment could have used a notation other than HTML, e.g. one based on the use of Word.

In our experiment annotations are also written in HTML, and are embedded in the base document. Thus text that is to act as an anchor has extra HTML mark-up to indicate its role. Documents and their annotations can be displayed using any browser.

How a reviewer would work

We imagine that a reviewer using our experimental software will work as follows:

  1. either to load the base document via the web (perhaps from a secure site that only allows designated reviewers to see the document), or to receive the base document by e-mail.
  2. to annotate the base document. This may be done with a special annotation tool with a visual interface, as we discussed above.
  3. to save the document locally. (There are well-known problems with saving an HTML document locally. One arises when the web document contains URLs that are relative to where the web document was originally stored, e.g. HREF="xxx.html"; this problem can be solved by adding an extra BASE element to the base document.)
  4. when the reviewer is satisfied her work is complete, she can send the annotated base document back to the author or editor.

Representation of annotations within the source

In a previous document, on the concepts of annotation, we identified the three parts of an annotation as the anchor, the annotating document and some metadata. Thus for an edit-annotation representing a replacement, the anchor would be the material to be replaced, the annotating document would be the material to replace the anchor, and the metadata might be a comment explaining the reason for the replacement. Here, because we have a more specialised form of annotation, we use more specialised terminology. We continue to use the term `anchor', but we use the term addition to represent the annotating document. We distinguish two sorts of metadata: commentary is metadata about the base document, and explanation is metadata about an insertion, deletion or replacement. (One purpose of this division into two is that, if edit-annotations are effected, commentary will remain, but explanation will disappear since the attached edit-annotation will have disappeared from the base document.) Commentary can be used to cover any annotations that are not edit-annotations.

As an example of the use of our terminology, for a replacement in the base document, the anchor will be the material to be replaced, an addition will represent the material to be entered in its place, and there may be a commentary describing the purpose of the replacement. All these components are represented by HTML mark-up, embedded in the base document. The HTML is designed so that the base document and its annotation can readily be displayed by any browser: all that is needed is style sheets to display annotations in the required way. We use CSS: at the moment the best browser support for CSS appears to come with Opera.

In practical applications this HTML will rarely be written directly by the user; instead, as we have said, it will be generated via a visual user interface that allows users to create and edit annotations on a base document. Given this, the prime aim of the HTML is to be easy for a browser to display; in particular it includes some redundancy to help achieve this aim.

Annotations are represented using SPAN, or, at the paragraph level, DIV. Each SPAN/DIV has a class attribute indicating its type. SPAN/DIVs are used both to mark the anchors, and to show the additions. There are four sorts of annotation: insertion, deletion, replacement and comment. The classes used for anchors of these are:

  1. ac, meaning the anchor of a comment, i.e. an instance where there is commentary but nothing else.
  2. ad, meaning the anchor of a deletion (which may also have an explanation attached).
  3. ar, meaning the anchor of a replacement (which may also have an explanation attached).

Each anchor is immediately followed by the appropriate additions. (Actually the class name on an anchor is redundant, as the class can be deduced from the additions that follow it. However, following the design principle above, it is there to help the browser: for example, to display different classes of anchor in different colours.)

HTML mark-up for additions

Additions, like anchors, are enclosed in a SPAN or DIV. The class of the SPAN or DIV gives the class of the addition:

  1. i, meaning the material to be inserted. An insertion does not have an anchor; its addition is placed where the insertion is to go. (To be exact, an insertion has a null anchor -- the point of insertion -- and null anchors do not cause any HTML to be generated.)
  2. r, meaning the material to act as a replacement. This is preceded by an anchor, which shows what is to be replaced.
  3. c, meaning some commentary. This may or may not be attached to an anchor, depending on whether the author wants to attach the commentary to a point in the base document, e.g. "add more here" or, say, to a sequence of words within it, e.g. "reword this". If there is no anchor, i.e. there is a null anchor, no HTML is generated for the anchor.
  4. ex, meaning some explanation. For an explanation of an insertion or replacement this should follow (1) or (2) above. For a deletion it should immediately follow the anchor for the deletion.

The only possible addition for a deletion is explanation.

Example of HTML mark-up

The following example of the HTML mark-up for an annotation shows the replacement of "working paper" by "article" with the explanation "ideas are now firm".

... <span class="ar">working paper</span><span class="r">article</span>
<span class="ex">ideas are now firm</span> ...

Syntactic matters

We have stated some rules for the form of our HTML, e.g that certain constructions should follow the anchor. Strictly speaking there should be a syntax checker to make sure the rules are obeyed, especially if the HTML has been directly produced or edited by the author. However, many feel that checking is not in the spirit of HTML.

There are further syntactic matters that apply to the base document. Firstly, HTML elements must be properly nested. It is therefore not allowable, for instance, to use the text "word1 <EM>word2" as an anchor (i.e. taking one word not in italics plus the first word of an italicised phrase), since the nesting rules of HTML requite that, if <EM> lies within a SPAN or DIV, then the closing </EM> must do so too.

Secondly, our HTML does not put any significant constraints on the syntax of the base document: the only limitation is that the base document must not use SPAN or DIV with the classes we have used.

Results and conclusions

Watch this space.

References