Transcriptional Protocols
General Introduction

What To Do First

The transcriptional protocols are written more as a reference work than as a continuous narrative, and were not intended to introduce new archivists to the arts of electronic editing. As a result, a great deal of redundancy has been built into many entries, which in some cases will duplicate material elsewhere. The narrative introduction to the protocols linked below is not yet complete, but will soon serve as a means of familiarizing archivists with the general features of the Transcriptional Protocols, as well as with common pitfalls and important caveats culled from long experience.

Conventions Used in This Documentation

Directly under the header of each section containing a direct citation of a TEI-conformant element, or any other type of code or routine with a standard, documented specification, you will also find a callout box with links to the specification itself, in this form:

Generally, these links are intended for advanced users. They will take you not to the basic PPEA/SEENET documentation (which in any case will immediately follow the callout box in question), but rather to the international standard lying behind PPEA/SEENET practice. Following these links will not be necessary for a basic understanding of the Protocols, but rather will serve to inform more advanced discussion of proper usage and questions of the need for extension as these may arise. Even if there is no external link associated with a specification, hovering over its name will invoke a tooltip that will explain briefly what the standard is.

General examples illustrating some aspect of markup application, whether they are images or blocks of code, are contained in boxes with a darker background:

Specifications of markup such as the standard attributes of a given tag, and the standard values for those attributes, are contained within a similar box, shifted further to the right, with text in list form:

The values listed in such boxes must be used rigorously in your markup, in exactly the form in which they appear in the bulleted list. Otherwise, later processing and display will be adversely affected. Should you need new attributes or values (or even whole new elements), as you would in this case if you had dug with a toothpick or lancet, you will need to review the TEI discussion on Conformance.

Finally, issues of special importance are highlighted in boxed paragraphs of their own, in this form:

Beginning the Transcription

Version Control and Copy of Record

Maintaining Copy of Record, commonly known as "COR," is a matter of paramount importance, because failing to do so can lose you weeks, months or even years of work.

The problem arises from the possibility of having two or more people working different but initially identical copies of the same file. At this initial stage, the work of only one of the people editing the file can be saved, because everyone's work will overwrite the original file when it comes time to return the file to the drive on which the edition is stored.

Transcribing each passus as an individual file has the advantage of allowing for greater ease in giving a team parts of an edition to work on individually and simultaneously, but even this method has proven subject to corruption of COR when more than one person was issued a copy of the same passus, but for a different work process.

As a result, if you allow anyone else to work on your edition, you will need to keep careful records of who has what files, when they were "checked out," when they were returned, how you vetted them before you allowed them to overwrite the old copies, and so forth.

Making backups of the state of your work before COR transfers in more than one copy and more than one location is most wise, and it is absolutely essential to record COR transfers and work done in comments at the head of each file.

Sometimes, but not always, corrupted COR can be repaired using an application such as Beyond Compare, which has a most generous trial use policy, and which is in any case quite inexpensive and very powerful.

A New File for Each Passus

Transcribe each passus into its own file. Because of the way the Archive's document type definition and its associated entity files have been written, you must name these files on the following pattern, where X is a hypothetical manuscript's sigil, and "passxx" is an abbreviation of "passus" and the passus number:

Designating the prologue as passus 00 (two zeros), and putting a zero before single digit passus will result in their being sorted in order in any directories in the DOS, Windows and Unix environments, which sort in ASCII order. Otherwise, Xprol.sgm/Xprol.xml will always appear at the end of the list, Xpass2.sgm/Xpass2.xml will be sorted with Xpass20.sgm/Xpass20.xml instead of following Xpass1.sgm/Xpass1.xml immediately (which will instead be followed by Xpass11.sgm/Xpass11.xml), and so forth.

Setting up your edition by transcribing each passus into a separate file may seem a needless complication, but it has significant advantages over a single-file method, including management of Copy of Record when you want to have more than one person working on your edition at one time, and economies in use of memory during later machine processing.

Headers and Closing Tags for Each Passus

Each passus, and each line group within any given passus must be opened and closed with a tagset on the following model, which represents a one-line passus, the first passus in hypothetical manuscript with sigil X:

See also Passus Breaks.

Using NoteTab Pro from the Start

It is crucial to use a raw text editor for your transcription instead of a standard word processing program, because programs such as Microsoft Word and Word Perfect can introduce underlying code into your files that is difficult to remove later, even if you save as plain text.

NoteTab Pro is not only a clean raw text editor on the model of Wordpad or Notepad, but also has numerous features that can make your transcription much easier to do. You can for example open all the passus files at once and search them all simultaneously for a given form - and replace that form with something else, either globally or one instance at a time.

NoteTab Pro also has a clip library function - similar to the macros in Microsoft Word - that can be docked to the right or the left side of the workspace. The PPEA and SEENET have developed a custom clip library for its editors that allows automatic application of almost all tags to selected strings of text - a feature that prevents the small errors such as forgetting the forward slash in a closing tag that can lead to large numbers of parsing errors in files.

NoteTab comes in both a paid Pro version for an astonishingly modest price, and in a somewhat reduced free version - NoteTab Light. Both are available at the NoteTab web site.

Text

Individual Characters and Graphs

Thorn, Yogh, and Other Non-ASCII Characters

If you have access to an SGML or XML browser, use the appropriate entity references to represent these characters. The most common special characters in the Latin and Greek alphabets appears in both SGML and XML (Unicode) format in the Entity References section of the Technical Introduction.

It is imperative to use NoteTab Clips for the SGML or XML entity references of frequently used non-ASCII letters, both upper and lower case, and of some marks of punctuation, so as to keep them perfectly regular. If you do not have access to an SGML or XML browser, however, you may find proofreading easier if you make an initial transcription using the short and completely unambiguous alternate representations in the following list:

Each can later be converted to the appropriate Unicode entity reference with a global search/replace.

A Special Case

The manuscript form <3> may represent either <z> or yogh. Transcribe it as <z> when it stands for /z/ or /s/ and yogh when it represents /j/ or the velar spirant.

Allographs

Editors must decide whether it is worthwhile to record allographic forms in any given edition. For instance, the F scribe uses a long <s> as well as a sigma <s> and one other form. He has three forms of <r> which are in free variation and thus carry no information. If you decide that variant letter forms have significance and want to tag them, entity references are the most efficient way to do that; e.g. &sigmas;, &longs;, etc.

Concerning the allographs <i> and <j>: Transcribe <i> as <i> and long <I> as <I>. Use <j> only at the end of series of minims, e.g. <iij> and <hij>, not <iiI> or <hiI>.

Upper- and Lower-Case Letters

It is of great importance that you resolve how to handle transcription of ambiguous upper and lower case letter forms from the start.

Our policy is to follow the scribe's letterforms, but the issue is problematic because some characters have no distinctive upper and lower case forms. For instance, in many late ME hands there is no discernible upper and lower case distinction for <w>, <h>, or sigma <s>. Policy decisions with regard to capitalization can be made only after analysis of each individual manuscript.

For example, the F scribe clearly intended to emphasize the first letter in each line. After the second folio he marked each with a touch of red ink and in general, when distinctive case forms were available, he used upper case forms for the first character in each line. We have therefore used the modern typographic upper case character when, as in the case of <h>, the forms are indistinguishable. In the case of manuscript G, the scribe almost never began a line with a capital letter, so we normalize to the lower case when the letter forms are ambiguous.

Proper Nouns

The capitalization or non-capitalization of proper nouns will need to be decided on a case-by-case basis, judging by the scribal forms in each manuscript. In cases of non-dimorphic letters such as <w>, the editor should reason on the basis of the scribe's general usage. If a scribe appears to use capitalization for proper nouns in free variation with lower case forms, the editor should determine which the scribe chooses most often, and apply that form consistently to doubtful cases.

Punctuation

Use of Entity References

Use entity references for any scribal pointing not appearing in the lower ASCII keyboard, including the following:

Editorial Punctuation

Punctuation introduced by the editor, such as that in the notes, should use the lower ASCII keyboard. In addition, four characters that were formerly represented by entity references in SGML will be represented by their simple lower ASCII equivalents in XML. These are:

A full chart of the entity references used by the Archive is available in the Technical Matters page.

Shadow Hyphens and the TEI <seg> Element

The general rule for marking up punctuation is that any form that might need to be suppressed in a given stylesheet will need to be marked up with a <seg> tag. Other forms of punctuation will not be marked up.

Tilded and Plain Ampersand

Some scribes appear to distinguish between <&> with and without tilde, using the one with a tilde in the English text for "and/ond" and the other without in the Latin and French text for "et." We can record these with &~ if it seems useful, replacing this later with the &tildeamp; (SGML) or &&#771; (XML) entity reference. Or we can simply describe the practice in the introduction.

Displaying Angle Brackets as Such

Displaying angle brackets as such within notes: You will occasionally want to use angled brackets in notes. Entity references must be used so the browser will not mistake the contents of the brackets for a botched SGML or XML tag. To display <X>, for example, enter <X>.

These entity references are not as cryptic as they might seem, since "<" refers to a "less than," and ">" to a "greater than" symbol. Likewise, "(" and ")" refer to "left parenthesis" and "right parenthesis."

Un-rubrished Paraph Indicators

Roman Numerals

Roman numerals in the text or titles are tagged to appear as numerals in the diplomatic text and as words in the critical text. Use the <orig> (=original) and <reg> (=regularized) tags in tandem as follows:

Roman numerals in formework or marginalia require no <reg> tags.

Ambiguous or Illegible Characters

Use the <unclear> tag to indicate where characters are unclear or ambiguous. If they are unclear due to a scribe's attempt at deletion, usually by erasure or overwriting, <unclear> tags should be nested within <del> tags. (See Deletions, especially Example 5.) If the characters cannot be discerned at all, use <damage> or <supplied> tags instead.

Standard attributes of <unclear> are as follows:

Spaces and Gaps

Use the <space> (<space/> = XML) tag to indicate where space is left vacant for characters (most often seen where an intended ornamental capital was never made). If the space is due to an erasure, see the Deletions section. Standard attributes for <space> are as follows:

Note that this tag has no content and therefore need not be closed in SGML, but will need the closing forward slash in XML (<space/>).

Stray Marks, Blots, Stains, and Flourishes

Most flourishes deemed by the editor not to be textually significant are neither transcribed nor tagged, though they should always be mentioned in the description of the paleographic features of the hand in the Front matter, and may be described in a paleographical note in the transcription. Unintentional marks, ink trails, blots, smears, bleed-through, or offset ink are neither noted nor transcribed in any way unless they are textually significant.

In F, for example, we recorded in provisional notes a number of apparently otiose curls written erratically over various letters throughout the manuscript, for though we could not determine what they meant, they appear to have been intended. We did not, however, tag them.

Words

Word Division

Overview

Medieval word division is not steadily consistent with modern usage, and scribal inconsistency of spacing further complicates the matter. Handwritten documents do not present the uniform spacing that modern readers of print have come to expect. In order both to facilitate machine collation and to assist users who will search for specific words, we have decided to resolve the problems of word division by reference to probable scribal meaning. Even in the diplomatic transcriptions,we will not attempt to represent scribal spacing unmediated by reference to meaning.

We follow the word-division of the manuscript as far as practicable, though no attempt is made to represent the variety of spacing between words and letters. The interpretation of the scribe's word-division, though it is generally unambiguous, is occasionally a matter of fine judgment. There is sometimes no obvious space between the indefinite article and the following noun, e.g. afreman (M20.145), but there seems no good purpose in recording these as a single word. A hyphen in the transcription (indicated with <seg type="shadowHyphen">-</seg>) indicates a space in the manuscript within a word, or a compound or phrase conventionally hyphenated today. In doubtful cases we have followed OED and MED to distinguish compounds from phrases. Conversely, some phrases, in particular or elles, at ese and at ones, are written as one word, orelles, atese, atones. Phrases like those are marked with <orig><reg> tags; e.g., <orig>orelles</orig><reg>or elles</reg>

Although we will not attempt to represent every nuance of scribal spacing in the transcript, we will include detailed information in the linguistic descriptions which will accompany each text. It is, therefore, important for each transcriber to collect data during the initial transcription. Provisional tagging and notes will call attention to problematic instances or spacing which requires the transcriber's interpretation. The <orig> / <reg> and <note> tags will be useful at this stage, and may be removed or retained when final decisions about the manuscript are made.

Markup

Compounds

In general, we will attempt to represent -emic significance. Compounds, therefore, present a special case. Historically in a state of transition, they may not always concur with modern usage. In addition, within the same hand, a given "word" may appear variously as a single word or two. In such cases, we will indicate scribal spacing as accurately as possible by using a hyphen to indicate the spaces that separate the morphs. For example, we will follow the scribe in transcribing either "beleve" or "be<seg type="shadowHyphen">-</seg>leve."

Close Calls

Close calls: When there is small space, smaller than that between words and larger than that between letters after one- and two-letter prefixes such as bi-, by-, to-, or a- (apeyre, among, aboue, etc), the initial transcriber will decide whether to use the shadow hyphen (<seg type="shadowHyphen">-</seg>) or to represent one word. Provisional notes can provide important data about scribal patterns. See the Editorial Notes section.

Participles

Grammatical considerations: The graphs "y" and "i" as markers of the past participle are morphemic. When they appear to be separated from the verb stem by a space, we will represent that space by a shadow hyphen (<seg type="shadowHyphen">-</seg>), thus y<seg type="shadowHyphen">-</seg>wro3t, I<seg type="shadowHyphen">-</seg>blessed, y<seg type="shadowHyphen">-</seg>nempned, etc.

Allegorical Names

Allegorical Names: In the documentary texts, shadow hyphens will indicate instances where a scribe has separated the morphs of the central allegorical names Do<seg type="shadowHyphen">-</seg>wel, Do<seg type="shadowHyphen">-</seg>bet, and Do<seg type="shadowHyphen">-</seg>best. Regardless of spacing, other allegorical names will not be hyphenated. This policy applies only to the documentary editions, not to later critical editions.

Abbreviations

Use the <expan> tags to indicate the resolution of standard abbreviations; e.g. p<expan>ro</expan>p<expan>ter</expan>. Editors without an SGML or XML browser may find that proofreading is made easier if the expanded material is put between parentheses initially; e.g. p(ro)p(ter). The essential rule here is that one records the interpretation in tags or parentheses, leaving unambiguous graphs outside them. Eventually parentheses will be replaced with <expan> and </expan>. Highly unusual abbreviations can be placed between tags or parentheses, but each should be followed by a paleographic note. See the Editorial Notes section.

The various forms of <&c.> and <&> will be represented by the entity reference &. We will indicate scribal spacing, either joining or separating the <&>and <c>. We will also indicate a dot if it appears. The <c.>should be expanded. Some possible combinations are as follows:

Some scribes make a distinction between the ampersand indicating the English "and" from one indicating the Latin "et" by the introduction of a tilde over the ampersand for the English word. This may be indicated with its own entity reference:

Word Brevigraphs

SGML and XML allow us to identify the brevigraph we are expanding in the <expan> tag with the attribute abbr. Examples of some of the most common are:

If you choose not to identify the brevigraph, use parentheses or <expan> without abbr as in the Abbreviations section; e.g. (Iesu) would eventually become <expan>Iesu</expan>.

Language Shifts

Use <foreign> tags to mark Latin/French/German text:

The following example shows tagging for "Anima" written in textura, in red ink, in a red box:

The order of tagging in this example - first boxing, then foreign language, then other <hi> - is preferable because of the way in which all or most display technologies such as CSS, XSL, PERL and any other language that relies on the matching of regular patterns will locate and style or process such features. A regular - and thus an expected and predictable - order of nesting will greatly facilitate later display and analysis of your edition.

Occasionally the foreign text and the highlighting are not conterminous, and this introduces a common complication regarding tag nesting. The example below shows <hi> tags nesting within <foreign> tags, where the phrase "in Infernum" appears with the Latin "in" outside the red box enclosing the rubricated, textura "Infernum."

If <foreign> tags are nested within <hi> tags, as in the first of the following examples (where one English word and one Latin word are in a red box), the result will parse perfectly, since the DTD allows for such nesting, but in the cases of boxing, underlining, or any other highlighting that forms a continuous line across white space, the second order of nesting is necessary in order to make the styling appear to be continuous, the way it most likely would in a manuscript:

Unique Readings

The TEI <app> element is used encode unique readings. In the case of unique readings, the "wit" attribute of the <lem> tag contains only the sigil of the manuscript in question. The "wit" attribute of the <rdg> tag may contain only the following standard values:

When the unique reading is clearly the result of a scribal error, <sic> tags nest inside of the <lem> tag to indicate that the variant is unintentional. Recording a scribe's unintentional errors is a means of determining their type and frequency, leading to a clearer picture of the scribe and his habits.

A complete TEI <app> tag array is as follows:

Patterns such as frequent omission of unstressed monosyllables, miscounting of minims, or transposition of words or letters may aid in distinguishing between two scribe's of similar handwriting, or they may corroborate the identification of additional samples of the same hand in other manuscripts.

A textual note may also accompany this tagging, explaining the significance of the reading.

Layout

Line Breaks

Each line in each manuscript in the Archive will be assigned its own number, which will become the "id" attribute value for that line, and must therefore be globally unique. Hence, even if the line is repeated elsewhere verbatim, each of these instances will receive its own unique number. An additional set of attribute values, those in the "n" or "name" attribute of the <l> element will correlate the line numbers to those in the Athlone editions (initially), and eventually to those in the archetype and the critical text. The "n" attribute may therefore repeat at times, if the same line has been copied into a manuscript more than once.

As in the example above, the format for a tag at the beginning of a line always has both an "id" and an "n" attribute, the "id" corresponding to the absolute numerical position of the line in the manuscript, and the "n" (name) corresponding to the line number of the parallel line in the relevant Athlone edition:

Our line number (the "id" of <l>) in this example is F1.3 which corresponds to KD Prologue line 4 (recorded in the "n" attribute).

Each line is ended with the tag </l>. We have in Charlottesville a program for inserting both the line numbers and the line terminal tag.

Since the introduction and placement of line break tags is predicated on the assignment of line numbers and editorial decisions as to what constitutes a line in a given manuscript, further discussion appears under the head Line Numbering in the next section.

Line Numbering Special Issues

Assigning line numbers is fraught with potential pitfalls. The first is in determining what constitutes one line. In Latin passages, it is not always clear whether the scribes intended to write prose, or even verse, as separate lines or as run-ons; i.e.,a physical line break may represent the medieval equivalent of either a "soft return" or "hard return." The scribe's use of boxes, upper or lowercase letters, terminal punctuation and grammatical structures may provide clues to his conception of line divisions in long Latin quotations. Each intended line will been closed in <l> tags as shown above, without regard to its physical arrangement.

Where the physical line breaks do not correspond to the scribe's perception of a new line, we will insert a TEI line break element, <lb> (SGML) or <lb/> (XML). Consider this example from MS L:

The sentence structure seems to dictate that the line would not end at "oraciones." That the scribe would agree is demonstrated by the indentation of "effunderitis" and his decidedly lower case <e>. (The above example has been stripped of all tags but the ones under discussion. In fact, a <foreign> tag is opened before "Vos" and closed after "euometis.")

The line break element, <lb> or <lb/>, should be used to represent a line break within all <marginalia>, <fw>, <add> and <l> tags as well as within notes citing more than one line of text. Since <lb> / <lb/> is an empty element, it does not need a closing tag in its SGML form, though it does need the special form with the forward slash in XML. As a default, it will cause a line break to occur at the point at which it is inserted, under any stylesheet we may develop. In special cases, however, such as in notes, an <lb/> may be given an "n" attribute value that can be used to distinguish it from from other linebreaks, making it possible to suppress or add a line break, or insert a pipe character as needed.

As soon as the transcription has been finished and properly prepared, the PERL scripts for line numbering and tagging should be run.

Paragraph and Strophic Breaks

The tag <lg type="strophe"> is to be inserted at the beginning of a strophe and </lg> at the end.

In some manuscripts, strophes are marked with paraphs or skipped lines or both. Record these, with <lb> for skipped lines and &para; for paraph markers. In most manuscripts, these paraphs are in red, green, and blue. Where the editor has access to the manuscript or a color facsimile, the colors should be recorded in <hi> tags; e. g. <hi rend="bl">&para;</hi>.

Passus Breaks

The tag <div1 type="passus" n="Xpass[number]">--where "X" is the sigil of the manuscript and "[number]" is the number of the passus--should precede the transcription of each passus. The final item, the content of the "n" attribute, will of course change with each passus. The closing tag </div1> is inserted at the end of the passus after any trailer, if there is one. <div1> </div1> is always the outermost container of each passus file.

Where non-standard passus divisions occur, indicate where passus divisions appear in the archetype with this tag: <milestone unit="Bpassus" n="[number]"> (SGML) or <milestone unit="Bpassus" n="[number]"/> (XML). The milestone tag is always empty, so it does not need to be closed in SGML, but in an XML document, it requires the special forward-slash format: <milestone/>.

Foliation

Between the bottom of each leaf and the top of the next, supply a tag such as this:

The transcription of folio 36v follows the tag. Since the <milestone> or <milestone/> tag is always empty, marking only the beginning point of the folio boundary, it need not be closed in SGML, but requires the forward slash format in XML.

The entity attribute value of the <milestone> / <milestone/> above refers to the hyperlinked image for folio 36v of manuscript M. Make certain that your images are named on the regular pattern sigil-folio-side, since this will make it easier to set up a regular and accurate pattern of entity naming for the images and their links in the edition.

Forme Work

The <fw> element identifies material added by the scribes or printers to indicate codicological structure, such as headings, top-of-page titles, catchwords, corrector's marks, guide words for the rubricator in the margin, etc. Attributes of <fw> include:

An "id" attribute is always added as a unique identifier for each instance of formework. This id will be assigned by a Perl script after the other editorial work is completed.

For "type" use only the following categories:

For "place" use only the following categories:

Note that the categories are written as one word, camel cased in all of these sample forme work tags except for "running head":

We do not include modern foliation in our transcription but characterize it in the description of the manuscript in the introduction.

Highlighting and Appearance

The <hi> element is used to describe the various ways scribes might call attention to text, such as by changes in script, size, or color, by underlining or boxing, etc. The only attribute we will need is "rend."

Be aware that <hi> tags, like <foreign> tags, do not carry over past </l> tags, so each line will need to be tagged separately. (See the note on <hi> tag nesting for examples of how <hi> and <foreign> tags may be nested.) If the highlighted text was added after initial copying, the <hi> tags should be nested within <add> tags.

Ornamental Capitals

This tag marks an ornamental capital "N" of 8 lines height followed by a capital "O" and lower case "w". Note that the <o> is the letter <o>, not the digit zero. We do not specify width.

Changes of Script

In the following example, "Danyel" is written in textura:

We are interpreting shifts in type of script as being for the purpose of emphasis or highlighting. The TEI actually has a <handShift> (SGML) / <handShift/> (XML) tag, but as an empty tag, it is less suitable to our use than one might imagine. <emph> tags can be used instead of <hi> tags. I chose the latter because it is more non-committal (HND).

Rubricated and Other Color-Highlighted Words and Phrases, and Otherwise Highlighted Text

In the first example, "Dowel" is rubricated. In the second, the black letters are touched with red ink. In the third example, the "D" alone is touched in red. In the last two examples the initial <D> is written in blue and green ink, respectively.

Underlined Words

The tagging in the following example indicates that "Glotoun" is underlined in text ink (or the color is unknown to the transcriber):

If a scribe clearly intends to underline a word, tag the whole word even if the line begins after the first letter or ends before the last.

Boxed Words and Phrases

Examples of <hi> tagging for underlining are:

Common abbreviations for contents of rend attributes

Three Special Instances of <hi> Tag Use

For a complete discussion of the handling of notes within the transcription, please see the section on Editorial Notes.

Scribal Changes to a Manuscript

Damage

In general, we record only damage made after the manuscript was first written. Those defects already in or on the vellum or paper and written around are not textually significant. We record damage only if it makes the text unclear or illegible.

If the damaged text cannot be transcribed with certainty, use <unclear> tags.

If it is completely illegible (cropped, for example), use <supplied> tags to record the damage and supply the missing text, though only if you wish to supply such text.

The <unclear> or <supplied> elements may be used instead of or in addition to the <damage> tag. Possible attributes and their values are as follows:

Examples:

Additions

Six Elements Mark-Up Additions

There are six elements that we use to tag additions, <add>, <addSpan>, <fw>, <head>, <trailer> and <marginalia>.

<add> and <addSpan>

The <add> tag serves to mark up phrase level text and <addSpan> to mark up larger blocks.

Use add tags for textual matter added to the text after the initial transcription. Forme work and marginalia tags can also be marked when necessary with <add> tags, though in many cases it will be impossible to identify the hand responsible for the addition to the text.

The attribute "place" designates the point at which the addition is made. Use only the following values:

Note that the designations are written as one word, with camel-casing, exactly as they appear. This is of importance for later processing and display. Other attributes of the <add> element are:

The following examples illustrate tagging for words of the poem omitted during initial copying but subsequently supplied, the first above the line by the original scribe, the second careted and written in the right margin by an unidentified hand:

You may wish to reiterate or supplement the information in <add> tags with a note, as in the sample line below:

See the Editorial Notes section for further discussion on the tagging and nesting of notes.

Marginalia Cited in Legacy Notes

If the added material is not meant to be part of the text, put it into <marginalia> or <fw> tags as appropriate. You will in many cases wish to attach an explanatory note as in the following instance where "Stretford" is written in the left margin by a later hand.

Since hand3 is already identified in the header and introduction as a sixteenth-century hand and the information about place and hand appears in the display if asked for, probably the discursive note is unnecessary.

<addSpan>

The <add> tag is used for short sequences of text, single words, or phrases. <addSpan> must be used for larger level additions because <add> tags do not carry over past structural boundaries like </l>. (See the Line Breaks section.) <addSpan> has the same attributes as <add>, with the addition of the attribute "to," which refers to the spot where the added material ends. (There is also the possibility of using the attribute "type," but that would be used only if the added text is not on an original manuscript page.) Instead of the expected closing tag, <addSpan> tags are closed by an <anchor> tag placed at the end of the span of added text. If, for example, two lines were omitted in the body of the text and added by the original scribe in the bottom margin, the tags might appear as follows:

<head> and <trailer>

Headers and trailers such as the passus headers and explicits are marked up with <head> and <trailer> tags, which are documented in the Headers and Closing Tags for Each Passus section.

<fw>

Running titles, guide words, catchwords and signatures and any other forme work are marked up with <fw> tags, documented in the Forme Work section.

<marginalia>

Marginalia are marked up the with the <marginalia> tag, documented in the Marginalia section.

Deletions

As with <add> and <addSpan> above, we use two elements to tag deletions, <del> and <delSpan>. <del> serves to mark up phrase level text and <delSpan> to mark up larger blocks.

Use <del> </del> tags where a word or passage is deleted or marked for deletion by a scribe, annotator, or corrector. The content of these tags may be either the characters that were deleted, if they are legible either under white or ultraviolet light, or symbolic if they are not legible. Symbolic representations of deleted characters should be supplied as folows: one period (.) per character up to five characters when it is possible to determine or guess the number of characters deleted, ...?... for deletions of six to a dozen characters, and ...?...?... for deletions of one half-line or more. In some cases, readers should be told in a paleographical note to consult the manuscript images, and should be given a link to the relevant image.

If the deleted text is unclear, <unclear> tags may be nested within <del> tags (as shown in Example 4 below). <unclear> tags give the option of expressing your degree of confidence in the reading. If the deleted text can be easily read, or, at the opposite extreme, cannot be read at all, there is no need to insert <unclear> tags.

Standard attributes and attribute values for the <del> tag are as follows:

The <del> tag is used for short sequences of text, single words, or phrases. <delSpan> must be used for larger level deletions because <del> tags do not carry over past structural boundaries like </l>. <delSpan> has the same attributes as <del>, with the addition of the "to" attribute, which refers to the spot where the deletion ends. Because <delSpan> and <addSpan> are similar, the example shown in the previous section for <addSpan> should be helpful.

Editorial Intervetion

Editorial Alterations to the Text

Text Supplied

You may use <supplied> tags where text is missing or completely illegible and you can supply it by reference to another source or by conjecture.

Standard attributes for <supplied> are as follows:

Sample <supplied> tags:

Editorial Correction to a Witness

TEI-conformant SGML and XML permit several different ways of marking corrections to the base manuscript by an editor. We have chosen to use the <sic> <corr> tags in tandem to show the manuscript reading and our emendation, respectively, because this will provide the widest range of display options. Note the use of square brackets in the following examples:

The <corr> tag may include the "resp" and "cert" attributes if this more complicated markup seems necessary or useful:

Editor Refrains from Correcting a Witness He Thinks Is Mistaken

A <sic> tag may be used without <corr> if the editor elects not to correct the text. <sic>seten to seten to</sic>

A more complicated tag can be used if the editor wishes not to display a correction but does want to record his opinion.

In this example, "cert" indicates the degree of certainty ascribed by a spineless HND to what he believes is the correct reading, but the displayed text will contain the erroneous reading "mychief." Note that a style sheet can be crafted that will display either the tag or the attribute, so the emendation is in fact made here but not displayed.

Editorial Notes

Editorial Notes within <l> Tags

The Medieval Academy of America and the Chicago Style Manual

IDs and <ref> Tags for Notes within <l> Tags

We will use <note> tags with nested <ref> tags indicating line number, as follows:

All notes must also be assigned an ID number, the value of which is based on the line number in which the note appears. Thus the note above, if it were the first note in the line, would receive the following ID:

Subsequent notes on this line would be numbered "M20.65n2," "M20.65n3," and so forth.

So far we have designated the following note types: codicological, paleographic, linguistic, lexical, historical, source, theological, and textual.

Order of Sigils Listed in Textual Notes

Sigils should be listed in textual notes with the base text sigil first, followed by the beta and alpha sigils in the following order:

This sigil order is based on the stemma constructed by Robert Adams.

We will follow the convention of displaying the Piers Plowman A, B, and C designations in bold type: <hi rend="bold">B</hi>. Other useful values for <hi rend> in notes are "sup" (=superscript) and "it" (=italic).

See the Punctuation section, for how to display angled brackets in notes.

A provisional note one you intend to remove after some issue is resolved may take the following simplified form:

Editorial Notes on Matter Other than Primary Text

Often, you will need to make a note on an element of the manuscript other than the main body of the text, such as formework, headers, trailers and marginalia. Such notes need to be kept to a consistent format as in any other note, except that their <ref> cannot be keyed to the ID of the <l> element in which they appear, since they do not in fact appear inside of an <l>.

Four Basic Conventions: Headers, Interlinear Elements, Formework & Trailers

In such cases, we have developed a single convention with three variants: one for note elements appearing before or within the header of a passus, a second for elements appearing after the headers, either before the first line or between the <l> elements within a passus, a third for formework, and a fourth for those appearing in conjunction with trailers.

Notes Before or Within a <head> Element

We encode notes appearing before or within the <head> element of a passus with the fictitious line number of zero (0) as the content of its <ref> element. Thus, the note in MsM on the marginalium Assit principio... that appears before the first line of the poem is encoded with the content of the <ref> element set to "MP.0:," and with ID's based on this fictitious line number zero (0):

The ID values are not as cryptic as they may seem. "MP.0m1" represents "Manuscript M, Prologue, line zero, marginalium number 1." Likewise, "MP.0mn1" represents "Manuscript M, Prologue, line zero, marginalium number 1, note number 1."

The note itself should be nested inside of the element on which it comments, in this case, inside the <marginalia> element. A note on the content of the header itself would be encoded on exactly the same model, and would also be nested inside of the <head> element:

Notes on Marginalia Appearing After a <head> Element

Notes that need to be made on marginalia appearing after the <head> element (generally between <l> elements) should be assigned the line number of the line nearest to them, with <marginalia> tags and their contents placed immediately above that line in the transcription.

Notes on Formework Appearing After a <head> Element

Formework appearing at the top of a leaf takes the ID of the first line on the leaf, but the catchwords and signatures of various kinds at the foot of a leaf take the number of the last <l> on the leaf:

Notes on Trailers (<trailer>)

Since trailers follow the last line contained within a <div>, and are typically the last element to appear within any <div>, they cannot take as part of their ID value or <ref> content the line number of a following line. Hence, they simply take that of the preceding one, following the rest of the conventions exactly as in the other cases:

Marginalia

The <marginalia> element is used to tag matter not intended to be part of the original poetic text nor forme work. That would include rubrics or glosses intended by the original scribe to be part of the original page as well as annotations, rubrics, glosses, etc. that are supplied by later hands.

Attributes for the marginalia tag include the following:

If the marginal material is pictorial, the most common being a pointing hand, use <figDesc> tags within <figure> tags within <add> tags in a note:

Identifying Hands

For each manuscript, we will identify and describe as many contributing scribal hands as we can distinguish with confidence. A hand recognizably the same in two or more additions or changes to the text (whether by way of marginalia or corrections) should be given an identifying number, and that number will be identified in the document header.

The primary copyists in each manuscript are designated in order of appearance as hand1, hand2, etc., in order of appearance.

A hand not thus characterized will be labeled "handx" in the SGML or XML tags (as neither SGML nor XML permits the use of a question mark, as in "hand?").

Beyond that, editors may use whatever designations they find useful. For example, if the editor is unable to recognize repeated instances of materials written by a hand, various hands may be lumped together, either simply as "handx" or identified by century or style. For instance, one might label one of several fifteenth-century hands as "hand15x" or secretary hands as "hand16saecx" or some other convenient designator.

In cases in which single instances of hands from entirely different, clearly identifiable eras appear, a designation such as hand19 and hand16 might be clearer than a simple handx referring to all such hands taken together. The addition of "x" to the hand designation is intended to make clear the ambiguity of the identification.