12 Critical Apparatus

Table of contents

Scholarly editions of texts, especially texts of great antiquity or importance, often record some or all of the known variations among different witnesses to the text. Witnesses to a text may include authorial or other manuscripts, printed editions of the work, early translations, or quotations of a work in other texts. Information concerning variant readings of a text may be accumulated in highly structured form in a critical apparatus of variants. This chapter defines a module for use in encoding such an apparatus of variants, which may be used in conjunction with any of the modules defined in these Guidelines. It also defines an element class which provides extra attributes for some elements of the core tag set when this module is selected.

Information about variant readings (whether or not represented by a critical apparatus in the source text) may be recorded in a series of apparatus entries, each entry documenting one variation, or set of readings, in the text. Elements for the apparatus entry and readings, and for the documentation of the witnesses whose readings are included in the apparatus, are described in section 12.1 The Apparatus Entry, Readings, and Witnesses. Special tags for fragmentary witnesses are described in section 12.1.5 Fragmentary Witnesses. The available methods for embedding the apparatus in the rest of the text, or for linking an external apparatus to the base text, are described in section 12.2 Linking the Apparatus to the Text. Finally, several extra attributes for some tags of the core tag set, made available when the additional tag set for text criticism is selected, are documented in section 11.3.1 Core elements for Transcriptional Work.

Many examples given in this chapter refer to the following texts of the opening (usually just line 1) of Chaucer's Wife of Bath's Prologue, as it appears in each of the four different manuscripts

12.1 The Apparatus Entry, Readings, and Witnesses

This section introduces the fundamental markup methods used to encode textual variations:

The app element is in one sense a more sophisticated and complex version of the choice element introduced in 3.4.1 Apparent Errors as a way of marking points where the encoding of a passage in a single source may be carried out in more than one way. Unlike choice, however, the app element allows for the representation of many different versions of the same passage taken from different sources.

12.1.1 The Apparatus Entry

Individual textual variations are encoded using the app element, which groups together all the readings constituting the variation. The identification of discrete textual variations or apparatus entries is not a purely mechanical process; different editors may group readings differently. No rules are given here as to how to group readings into apparatus entries; the tags given here may be used to group readings in whatever way the editor finds most perspicuous or useful.

The individual apparatus entry is encoded with the app element:
  • app (apparatus entry) contains one entry in a critical apparatus, with an optional lemma and at least one reading.
    type classifies the variation contained in this element according to some convenient typology.
    from identifies the beginning of the lemma in the base text, if necessary.
    to identifies the endpoint of the lemma in the base text, if necessary.
    loc (location) indicates the location of the variation, when the location-referenced method of apparatus markup is used.

The attributes loc, from, and to, are used to link the apparatus entry to the base text, if present. In such cases, several methods may be used for such linkage, each involving a slightly different usage for these attributes. Linkage between text and apparatus is described below in section 12.2 Linking the Apparatus to the Text. For the use of the app element without a base text, see 12.2.3 The Parallel Segmentation Method.

Each app element comprises one or more readings, which in turn are encoded using the rdg or other elements, as described in the next section. A very simple partial apparatus for the first line of the Wife of Bath's Prologue might take a form something like this:
<app>
 <rdg wit="#El">Experience though noon Auctoritee</rdg>
 <rdg wit="#La">Experiment thogh noon Auctoritee</rdg>
 <rdg wit="#Ra2">Eryment though none auctorite</rdg>
</app>
Of course, in practice the apparatus will be somewhat more complex. Specifically, it may be desired to record more obviously that manuscripts El and La agree on the words ‘noon Auctoritee’, to indicate a preference for one reading, etc. The following sections on readings, subvariation, and witness information describe some of the more important complications which can arise.

12.1.2 Readings

Individual readings are the crucial elements in any critical apparatus of variants. The following elements should be used to tag individual readings within an apparatus entry:
  • lem (lemma) contains the lemma, or base text, of a textual variation.
  • rdg (reading) contains a single reading within a textual variation.
N.B. the term lemma is used here in the text-critical sense of ‘the reading accepted as that of the original or of the base text’. This sense differs from that in which the word is used elsewhere in the Guidelines, for example as in the attribute lemma where the intended sense is ‘the root form of an inflected word’, or ‘the heading of an entry in a reference book, especially a dictionary’.

In recording readings within an apparatus entry, the rdg element may always be used; each app must contain at least one rdg.

The lem element may also be used, under some circumstances, to record the base text of the source edition, to mark the readings of a base witness, to indicate the preference of an editor or encoder for a particular reading, or to make clear, in cases of ambiguity, precisely which portion of the main text the variation applies to. Those who prefer to work without the notion of a base text may prefer not to use it at all. How it is used depends in part on the method chosen for linking the apparatus to the text; for more information, see section 12.2 Linking the Apparatus to the Text.

Readings may be encoded individually, or grouped for perspicuity using the rdgGrp element described in section 12.1.3 Indicating Subvariation in Apparatus Entries.

As members of the attribute class att.textCritical, both of these elements inherit the following attributes. Some of these attributes are intelligible only if the reading is ascribed to a single witness; others have no such restriction.
  • att.textCritical defines a set of attributes common to all elements representing variant readings in text critical work.
    wit (witness or witnesses) contains a list of one or more pointers indicating the witnesses which attest to a given reading.
    type classifies the reading according to some useful typology.
    cause classifies the cause for the variant reading, according to any appropriate typology of possible origins.
    varSeq (variant sequence) provides a number indicating the position of this reading in a sequence, when there is reason to presume a sequence to the variants on any one lemma.
    hand signifies the hand responsible for a particular reading in the witness.
    resp (responsible party) identifies the editor responsible for asserting a particular reading in the witness.

The wit attribute identifies the witnesses which have the reading in question. It is required if the apparatus gathers together readings from different witnesses, but may be omitted in an apparatus recording the readings of only one witness, e.g. substitutions, divergent opinions on what is in the witness or on how to expand abbreviations, etc. Even in such a one-witness apparatus, however, the wit attribute may still be useful when it is desired to record the occurrence of a particular reading in some other witness. For other methods of identifying the witnesses to a reading, see section 12.1.4 Witness Information.

The type attribute allows the encoder to classify readings in any convenient way, for example as substantive variants of the lemma:
<app>
 <lem wit="#El #Hg">Experience</lem>
 <rdg wit="#La" type="substantive">Experiment</rdg>
 <rdg wit="#Ra2" type="substantive">Eryment</rdg>
</app>
or as orthographic variants:
<app>
 <lem wit="#El #Ra2">though</lem>
 <rdg wit="#Hg" type="orthographic">thogh</rdg>
 <rdg wit="#La" type="orthographic">thouh</rdg>
</app>
The varSeq and cause attributes may be used to convey information on the sequence and cause of variation. In the following apparatus fragment, the reading Eryment is tagged as sequential to (derived from) the reading Experiment, and the cause is given as loss of the abbreviation for per.
<app>
 <rdg wit="#La" varSeq="1">Experiment</rdg>
 <rdg wit="#Ra2" cause="abbreviation_loss" varSeq="2">Eryment</rdg>
</app>
If a manuscript is written in several hands, and it is desired to report which hand wrote a particular reading, the hand attribute should be used. For example, in the Munich manuscript containing the Carmina Burana, the word alle has been changed to allen:
<l>Swaz hi gât umbe</l>
<l>daz sint alle megede,</l>
<l>die wellent ân man</l>
<l>
 <app>
  <rdg wit="#Mu" varSeq="1" hand="#m1">alle</rdg>
  <rdg
    wit="#Mu"
    cause="nachgetragen"
    varSeq="2"
    hand="#m2">allen</rdg>
 </app>
disen sumer gân.
</l>
Similarly, if a witness is hard to decipher, it may be desired to indicate responsibility for the claim that a particular reading is supported by a particular witness. In line 2212a of Beowulf, for example, the manuscript is read in different ways by different scholars; the editor Klaeber prints one text, using parentheses to indicate his expansion, and records in the apparatus two different accounts of the manuscript reading, by Zupitza and Chambers: 38
<l>se ðe on
<app>
  <rdg wit="#Kl">hea(um) h(æþ)e</rdg>
  <rdg wit="#ms" resp="#Z">heaðo hlæwe</rdg>
  <rdg wit="#ms" resp="#Cha">heaum hope</rdg>
 </app>
</l>
<l>hord beweotode,</l>

The hand and resp attributes are intelligible only on an element recording a reading from a single witness, and should not be used if more than one witness is given on the same rdg or lem element. If more than one witness is given for the reading, they are undefined. To convey this information when the witness is one among several, the witDetail element should be used; see section 12.1.4 Witness Information.

Where there is a greater weight of editorial discussion and interpretation than can conveniently be expressed through the attributes provided on these elements (for example where there are multiple witnesses for a single reading or multiple editorial responsibility for an emendation) this information can be attached to the apparatus in a note, or recorded in the feature structure notation defined in chapter 18 Feature Structures. In particular, such recurring text-critical situations as palaeographic confusion of particular letters, or homœoarchy or homœoteleuton involving specific character groups, may lend themselves to feature structure treatment. Information concerning these recurrent situations may be encoded into database-like fragments within the text which would then be available to sophisticated computer-assisted analysis. Further work remains to be done on such mechanisms, however, and so no examples are given here of the use of feature structures in text-critical apparatus.

The note element may also be used to record the specific wording of notes in the apparatus of the source edition, as here in a transcription of Friedrich Klaeber's note on Beowulf 2207a:
<l n="2207a">syððan Beowulfe
<note resp="#Kl" place="app">Fol. 179a <mentioned>beowulfe</mentioned>.
   Folio 179, with the last page (Fol. 198b), is the worst part of the
   entire MS. It has been freshened up by a later hand, but not always
   correctly. Information on doubtful readings is in the notes of
   Zupitza and Chambers.</note>
</l>
<l n="2207b">brade rice</l>
Notes providing details of the reading of one particular witness should be encoded using the specialized witDetail element described in section 12.1.4 Witness Information.

Encoders should be aware of the distinct fields of use of the attribute values wit, hand, and resp. Broadly, wit identifies the physical entity in which the reading is found (manuscript, clay tablet, papyrus, printed edition); hand refers to the agent responsible for inscribing that reading in that physical entity (scribe, author, inscriber, hand 1, hand 2); resp indicates the scholar responsible for asserting the existence of that reading in that physical entity. In some cases, the categories may blur: a scholar may produce an edition introducing readings for which he or she is responsible; that edition may itself become a witness in a later critical apparatus. Thus, readings introduced as corrections in the earlier edition will be seen in the later apparatus as witnessed by the earlier edition. As observed in the discussion concerning the discrimination of hand and resp in transcription of primary sources in section 11.4.2 Hand, Responsibility, and Certainty Attributes, the division of layers of responsibility through various scholars for particular aspects of a particular reading may require the more complex mechanisms for assigning responsibility described in chapter 21 Certainty, Precision, and Responsibility.

12.1.3 Indicating Subvariation in Apparatus Entries

The rdgGrp element may be used to group readings, either because they have identical values on one or more attributes, or because they are seen as forming a self-contained variant sequence, or for some other reason. This grouping of readings is entirely optional: no such grouping of readings is required.
  • rdgGrp (reading group) within a textual variation, groups two or more readings perceived to have a genetic relationship or other affinity.

The rdgGrp element is a member of class att.textCritical and therefore can carry the wit, type, cause, varSeq, hand, and resp attributes described in the preceding section. When values for any of these attributes are given on a rdgGrp element, the values given are inherited by the rdg or lem elements nested within the reading group, unless overridden by a new specification on the individual reading element.

To indicate that both Hg and La vary only orthographically from the lemma, one might tag both readings <rdg type='orthographic'>, as shown in the preceding section. This fact can be expressed more perspicuously, however, by grouping their readings into a rdgGrp, thus:
<app>
 <lem wit="#El #Ra2">though</lem>
 <rdgGrp type="orthographic">
  <rdg wit="#Hg">thogh</rdg>
  <rdg wit="#La">thouhe</rdg>
 </rdgGrp>
</app>

Similarly, rdgGrp may be used to organize the substantive variants of an apparatus entry. Editors may need to indicate that each of a group of witnesses may be taken as all supporting a particular reading, even though there may be variation concerning the exact form of that reading in, or the degree of support offered by, those witnesses. For example: one may identify three substantive variants on the first word of Chaucer's Wife of Bath's Prologue in the manuscripts: these might be expressed in regularized spelling as Experience, Experiment, and Eriment. In fact, the manuscripts display many different spellings of these words, and a scholar may wish both to show that the manuscripts have all these variant spellings and that these variant spellings actually support only the three regularized spelling forms. One may term these variant spellings as ‘subvariants’ of the regularized spelling forms.

This subvariation can be expressed within an app element by gathering the readings into three groups according to the normalized form of their reading. All the readings within each group may be accounted subvariants of the main reading for the group, which may be indicated by tagging it as a lem element or as <rdg type='groupBase'>.

In this example, the different subvariants on Experience, Experiment, and Eriment are held within three rdgGrp elements nested within the enclosing app element:
<app type="substantive">
 <rdgGrp type="subvariants">
  <lem wit="#El #Hg">Experience</lem>
  <rdg wit="#Ha4">Experiens</rdg>
 </rdgGrp>
 <rdgGrp type="subvariants">
  <lem wit="#Cp #Ld1">Experiment</lem>
  <rdg wit="#La">Ex<g ref="#per"/>iment</rdg>
 </rdgGrp>
 <rdgGrp type="subvariants">
  <lem>Eriment<wit>[unattested]</wit>
  </lem>
  <rdg wit="#Ra2">Eryment</rdg>
 </rdgGrp>
</app>
From this, one may deduce that the regularized reading Experience is supported by all three manuscripts El Hg Ha4, although the spelling differs in Ha4, and that the regularized reading Eriment is supported by Ra2, even though the form differs in that manuscript. Accordingly, an application which recognizes that these apparatus entries show subvariation may then assign all the witnesses instanced as attesting the sub-variants on that lemma as actually supporting the reading of the lemma itself at a higher level of classification. Thus, Ha4 here supports the reading Experience found in El and Hg, even though it is spelt slightly differently in Ha4.
Reading groups may nest recursively, so that variants can be classified to any desired depth. Because apparatus entries may also nest, the app element might also be used to group readings in the same way. The example above is substantially identical to the following, which uses app instead of rdgGrp:
<app n="a1" type="substantive">
 <rdg wit="#El #Hg #Ha4">
  <app n="a2" type="orthographic">
   <lem wit="#El #Hg">Experience</lem>
   <rdg wit="#Ha4">Experiens</rdg>
  </app>
 </rdg>
 <rdg wit="#Cp #Ld1 #La">
  <app n="a3" type="orthographic">
   <lem wit="#Cp #Ld1">Experiment</lem>
   <rdg wit="#La">Ex<g ref="#per"/>iment</rdg>
  </app>
 </rdg>
 <rdg wit="#Ra2">
  <app n="a4" type="orthographic">
   <lem>Eriment<wit>[unattested]</wit>
   </lem>
   <rdg wit="#Ra2">Eryment</rdg>
  </app>
 </rdg>
</app>
This expresses even more clearly than the previous encoding of this material that at the highest level of classification (apparatus entry A1), this variation has three normalized readings, and that the first of these is supported by manuscripts El, Hg, and Ha4; the second by Cp, Ld1, and La; and the third by Ra2. Some encoders may find the use of nested apparatus entries less intuitive than the use of reading groups, however, so both methods of classifying the readings of a variation are allowed.
Reading groups may also be used to bring together variants which form an apparent developmental sequence, and to make clear that other readings are not part of that sequence, as in the following example, which makes clear that the variant sequence experiment to eriment says nothing about the relative priority of experiment and experience:
<app type="substantive">
 <rdgGrp type="subvariants">
  <lem wit="#El #Hg">Experience</lem>
  <rdg wit="#Ha4">Experiens</rdg>
 </rdgGrp>
 <rdgGrp type="sequence">
  <rdgGrp varSeq="1" type="subvariants">
   <lem wit="#Cp #Ld1">Experiment</lem>
   <rdg wit="#La">Ex<g ref="#per"/>iment</rdg>
  </rdgGrp>
  <rdgGrp varSeq="2" cause="abbreviation_loss" resp="#PR">
   <lem>Eriment<wit>[unattested]</wit>
   </lem>
   <rdg wit="#Ra2">Eryment</rdg>
  </rdgGrp>
 </rdgGrp>
</app>

12.1.4 Witness Information

A given reading is associated with the set of witnesses attesting it by listing the witnesses in the wit attribute on the rdg, lem, or rdgGrp element. Special mechanisms, described in the following sections, are needed to associate annotation on a reading with one specific witness among several (section 12.1.4.1 Witness Detail Information), to transcribe witness information verbatim from a source edition (section 12.1.4.2 Witness Information in the Source), and to identify the formal lists of witnesses typically provided in the front matter of critical editions (section 12.1.4.3 The Witness List).

12.1.4.1 Witness Detail Information
When it is desired to give additional information about a particular witness or witnesses for the reading, the information may be given in a witDetail element, pointing to the identifier for that reading and signalling in the value of its wit attribute the witness or witnesses to which the additional information relates.
  • witDetail (witness detail) gives further information about a particular witness, or witnesses, to a particular reading.
    target indicates the identifier for the reading, or readings, to which the witness detail refers.
    wit (witnesses) indicates the sigil or sigla for the witnesses to which the detail refers.
The witDetail element is a specialized form of note, which adds to the attributes of that element the specialized attribute wit, which indicates which witness in particular is being described. Like note, witDetail can be included in the text at the point of attachment, or can point to the reading(s) being annotated with its target attribute. To indicate, on the authority of editor PR, that the Ellesmere manuscript has an ornamental capital in the word Experience, for example, one might write:
<app type="substantive">
 <rdgGrp type="subvariants">
  <lem xml:id="W026" wit="#El #Hg">Experience</lem>
  <rdg wit="#Ha4">Experiens</rdg>
 </rdgGrp>
</app>
<witDetail target="#W026" resp="#PR" wit="#El">Ornamental capital.</witDetail>
This encoding makes clear that the ornamental capital mentioned is in the Ellesmere manuscript, and not in Hengwrt or Ha4.
Like note, witDetail may be used to record the specific wording of information in the source text, even when the information itself is captured in some more formal way elsewhere. The example from the Carmina Burana above (section 12.1.2 Readings), for example, might be extended thus, to record the wording of the note explaining the variant:
<l>Swaz hi gât umbe</l>
<l>daz sint alle megede,</l>
<l>die wellent ân man</l>
<l>
 <app>
  <rdg wit="#Mu" hand="#m1">alle</rdg>
  <rdg xml:id="anon.6.4" wit="#Mu" hand="#m2">allen</rdg>
 </app>
disen sumer gân.
</l>
<witDetail target="#anon.6.4" wit="#Mu">
 <ref>allen</ref>
 <mentioned>n</mentioned> nachgetragen.

</witDetail>

Observe that a single witness detail element may be linked to several different readings (noting, for example, a recurrent phenomena in a particular manuscript) by having the target attribute point at all the readings in question. Similarly, feature structures containing information about the text in a witness (whether retroversion, regularization, or other) can also be linked to specific lem and rdg instances. See chapter 18 Feature Structures.

12.1.4.2 Witness Information in the Source
In the transcription of printed critical editions, it may be desirable to retain for future reference the exact form in which the source edition records the witnesses to a particular reading; this is particularly important in cases of ambiguity in the information, or uncertainty as to the correct interpretation. The wit element may be used to transcribe such lists of witnesses to a particular reading.
  • wit contains a list of one or more sigla of witnesses attesting a given reading, in a textual variation.
The wit list may appear following a rdg, rdgGrp, or lem element in any apparatus entry, and should be used only to transcribe the witness information in the form found in the source. The advantage of holding witness information in the wit attribute of lem or rdg is that an application can check that every sigil identifier has been declared elsewhere in the document. Because the wit attribute has declared datatype of one or more data.pointer values, a check can be made that readings are assigned only to witness sigla which have been identified (using the xml:id attribute) within a listWit element (see section 12.1.4.3 The Witness List). Such checking is more difficult for witness sigla held as the content of a wit element. For this reason, it is recommended that encoders always hold witness information in the wit attribute of lem and rdg, where possible. Thus, as in the examples below, even when a reference to a witness is exactly reproduced in the wit element, the corresponding sigil for that witness can be written into the wit attribute of the matching rdg or lem. However, in cases where it is uncertain how the witness reference contained in the wit element should be interpreted, or where no witness exists, the wit attribute on the matching rdg or lem may be left empty.
<lg type="stanza">
 <l xml:id="Diet1.1">Slăfest du, vriedel ziere?</l>
 <l xml:id="Diet1.2">wan wecket uns leider schiere;</l>
 <l xml:id="Diet1.3">ein vogellīn sŏ wol getăn</l>
 <l xml:id="Diet1.4">daz ist der linden an daz zwī gegăn.</l>
</lg>
<app type="secondary" loc="Diet.1.1">
 <rdg wit="#Kb">slăfst</rdg>
 <wit>K(Ba)</wit>
</app>
<app type="secondary" loc="Diet.1.2">
 <rdg wit="#Kv">Man</rdg>
 <wit>K(V)</wit>
 <rdg wit="#K">weckt</rdg>
 <wit>K (Wackernagel 401)</wit>
 <rdg wit="#Ju">Ich waen ez taget uns schiere</rdg>
 <wit>Jungbluth, Festschr. Pretzel 1963, 122.</wit>
</app>
Of course, the siglum used for a particular witness in the source, as recorded in the wit element, may well differ from that used to indicated the same witness in the wit attribute, as shown particularly in the apparatus for the second line of the poem (Diet.1.2).
12.1.4.3 The Witness List

A list of all identified witnesses should normally be supplied in the front matter of the edition, or in the sourceDesc element of its header. This may be given either as a simple bibliographic list, using the listBibl element described in 3.11 Bibliographic Citations and References, or as a listWit element, which contains a series of witness elements. Each witness element may contain a brief characterisation of the witness, given as one or more prose paragraphs. If more detailed information about a manuscript witness is available, it should be represented using the msDesc element provided by the msdescription module; a msDesc may appear within a listBibl.

Whether information about a particular witness is supplied by means of a bibl, msDesc, or witness element, a unique sigil (siglum) for this source should always be supplied, using the global xml:id attribute. This identifier can then be used elsewhere to refer to this particular witness.
  • listWit (witness list) lists definitions for all the witnesses referred to by a critical apparatus, optionally grouped hierarchically.
  • witness contains either a description of a single witness referred to within the critical apparatus, or a list of witnesses which is to be referred to by a single sigil.
  • msDesc (manuscript description) contains a description of a single identifiable manuscript.
  • bibl (bibliographic citation) contains a loosely-structured bibliographic citation of which the sub-components may or may not be explicitly tagged.
  • listBibl (citation list) contains a list of bibliographic citations of any kind.
The minimal information provided by a witness list is thus the set of sigla for all the witnesses named in the apparatus. For example, the witnesses referenced by the examples of this chapter might simply be listed thus:
<listWit>
 <witness xml:id="Chi3"/>
 <witness xml:id="Ha4"/>
 <witness xml:id="Ju"/>
 <witness xml:id="K"/>
 <witness xml:id="Kb"/>
 <witness xml:id="Kl"/>
 <witness xml:id="Kv"/>
 <witness xml:id="Ld"/>
 <witness xml:id="Ld1"/>
 <witness xml:id="Ln"/>
 <witness xml:id="Mu"/>
 <witness xml:id="Ry2"/>
 <witness xml:id="Wa"/>
 <witness xml:id="X"/>
</listWit>
It is more helpful, however, for witness lists to be somewhat more informative: each witness element should contain at least a brief prose description of the witness, perhaps including a bibliographic citation, as in the following examples:
<listWit>
 <witness xml:id="El">Ellesmere, Huntingdon Library 26.C.9</witness>
 <witness xml:id="Hg">Hengwrt, National Library of Wales,
   Aberystwyth, Peniarth 392D</witness>
 <witness xml:id="Ra2">Bodleian Library Rawlinson Poetic 149
   (see further <ptr target="#MSRP149"/>)</witness>
</listWit>
As the last example shows, the witness description here may be complemented by a reference to a full description of the manuscript supplied elsewhere, typically as the content of a msDesc or bibl element. Alternatively, it may contain a whole paragraph of commentary for each witness :
<listWit>
 <witness xml:id="A">die sog. <soCalled>Kleine (oder alte)
     Heidelberger Liederhandschrift</soCalled>.
 <bibl>Universitätsbibliothek Heidelberg col. pal.
     germ. 357. Pergament, 45 Fll. 18,5 × 13,5 cm.</bibl>
   Wahrscheinlich die älteste der drei großen Hss. Sie
 <quote>datiert aus dem 123. Jahrhundert, etwa um 1275. Ihre Sprache
     weist ins Elsaß, evtl. nach Straßburg. Man geht wohl nicht
     fehl, in ihr eine Sammlung aus dem Stadtpatriziat zu sehen</quote>
   (<bibl>
   <author>Blank</author>, [vgl. <ref>Lit. z. Hss. Bd. 2,
       S. 39</ref>] S. 14</bibl>). Sie enthält 34 namentlich
   genannte Dichter. <quote>Zu den Vorzügen von A gehört, daß
     sie kaum je bewußt geändert hat, so daß sie für
     manche Dichter ... oft den besten Text liefert</quote> (so wohl mit
   Recht <bibl>
   <author>v. Kraus</author>
  </bibl>).</witness>
 <witness xml:id="a">Bezeichnung <bibl>
   <author>Lachmann</author>
  </bibl>s für die von einer 2. Hand auf bl. 40–43
   geschriebenen Strophen der Hs. A.</witness>
 <witness xml:id="B">die <soCalled>Weingartner (Stuttgarter)
     Liederhandschrift</soCalled>. <bibl>Württembergische
     Landesbibliothek Stuttgart, HB XIII poetae germanici 1.
     Pergament, 156 Bll. 15 × 11,5 cm; 25 teils ganzseitig,
     teils halbseitige Miniaturen.</bibl> Kaum vor 1306 in Konstanz
   geschrieben. Sie enthält Lieder von 25 namentlich genannten
   Dichtern. (Dazu kommen Gedichte von einigen ungenannten
   bzw. unbekannten Dichtern, ein Marienlobpreis und eine
   Minnelehre.)</witness>
</listWit>
It would however generally be preferable to represent such detailed information using an appropriately structured msDesc element, as discussed in chapter 10 Manuscript Description. Note also that if the witnesses being recorded are not manuscripts but printed works, it may be preferable to document them using the standard bibl or biblStruct elements described in 3.11 Bibliographic Citations and References, as in this example:
<listBibl>
 <bibl xml:id="bcn_1482">T.Kempis, De la imitació de Jesuchrist e del
   menyspreu del món (trad. Miquel Peres); Barcelona, 1482, Pere
   Posa. Editio princeps.</bibl>
 <bibl xml:id="val_1491">T.Kempis, Del menyspreu del món (trad. Miquel
   Peres); València, 1491.</bibl>
 <bibl xml:id="bcn_1518">T.Kempis, Libre del menysprey del món e de la
   imitació de nostre senyor Déu Jesucrist, (trad. Miquel Peres);
   Barcelona, 1518, Carles Amorós. </bibl>
</listBibl>
In text-critical work it is customary to refer to frequently occurring groups of witnesses by means of a single common sigil. Such sigla may be documented as pseudo-witnesses in their own right by including a nested witness list within the witness list, which uses the sigil for the group as its identifier, and supplies a fuller name for the group in its optional child head element, before listing the other witnesses contained by the group. For example, the Constant Group C of manuscripts comprising witnesses Cp, La, and S12, might be represented as follows:
<listWit>
 <witness xml:id="Ellesmere">Ellesmere, Huntingdon Library 26.C.9</witness>
<!-- ... -->
 <listWit xml:id="Con">
  <head>Constant Group C</head>
  <witness xml:id="Cp">Corpus Christi Oxford MS 198</witness>
  <witness xml:id="La">British Library Lansdowne 851</witness>
  <witness xml:id="Sl2">British Library Sloane MS 1686</witness>
 </listWit>
</listWit>
That the reading Experiment occurs in all three manuscripts can now be indicated simply as follows:
<rdg wit="#Con">Experiment</rdg>
Note that a single witness cannot appear more than once in a witness list, and therefore cannot be assigned to more than one group of witnesses.

Situations commonly arise where there are many more or less fragmentary witnesses, such that there may be quite distinct groups of witnesses for different parts of a text or collection of texts. One may treat this with distinct listWit elements for each different part. Alternatively, one may have a single listWit element at the beginning of the file or in its header listing all the witnesses, partial and complete, for the text, with the attestation of fragmentary witnesses indicated within the apparatus by use of the witStart and witEnd elements described in section 12.1.5 Fragmentary Witnesses.

If a witness list is provided, it may be unnecessary to give, in each apparatus entry, an exhaustive list of the witnesses which agree with the base text. An application program can — in principle — compare the witnesses given for each variant found with those given in the full list of witnesses, subtracting from this list all the witnesses not active at this point (perhaps because of lacuna, or because they contain a variation on a different, overlapping lemma) and thence calculate all the manuscripts agreeing with the base text. In practice, encoders may find it less error-prone to list all witnesses explicitly in each apparatus entry.

12.1.5 Fragmentary Witnesses

If a witness is incomplete (whether a single fragment, a series of fragments, or a relatively complete text with one or more lacunae), it is usually desirable to record explicitly where its preserved portions begin and end. The following empty tags, which may occur within any lem or rdg element, indicate the beginning or end of a fragmentary witness or of a lacuna within a witness:
  • witStart/ (fragmented witness start) indicates the beginning, or resumption, of the text of a fragmentary witness.
  • witEnd/ (fragmented witness end) indicates the end, or suspension, of the text of a fragmentary witness.
  • lacunaStart/ indicates the beginning of a lacuna in the text of a mostly complete textual witness.
  • lacunaEnd/ indicates the end of a lacuna in a mostly complete textual witness.
These elements constitute the class model.rdgPart, members of which are permitted within the elements lem and rdg when the module defined by this chapter is included in a schema.
Suppose a fragment of a manuscript X of the Wife of Bath's Prologue has a physical lacuna, and the text of the manuscript begins with auctorite. In an apparatus this might appear thus, distinguished from the reading of other manuscripts by the presence of the lacunaEnd element:
<app>
 <lem wit="#El #Hg">Auctoritee</lem>
 <rdg wit="#La #Ra2">auctorite</rdg>
 <rdg wit="#X">
  <lacunaEnd/>auctorite</rdg>
</app>
In some cases, the apparatus in the source may commence recording the readings for a particular witness without its being clear whether the previous absence of readings for this witness is due to a lacuna, or to some other reason. The witStart element may be used in this circumstance:
<app>
 <lem wit="#El #Hg">Auctoritee</lem>
 <rdg wit="#La #Ra2">auctorite</rdg>
 <rdg wit="#X">
  <witStart/>auctorite</rdg>
</app>

12.2 Linking the Apparatus to the Text

Three different methods may be used to link a critical apparatus to the text:
  1. the location-referenced method,
  2. the double-end-point-attached method, and
  3. the parallel segmentation method.

Both the location-referenced and the double end-point methods may be used with either in-line or external apparatus, the former dispersed within the base text, the latter held in some separate location, within or outside the document with the base text. The parallel segmentation method does not use the concept of a base text and may only be used for in-line apparatus.

Any document containing app elements requires a variantEncoding declaration in the encodingDesc element of its TEI header, thus:
  • variantEncoding/ declares the method used to encode text-critical variants.
    method indicates which method is used to encode the apparatus of variants.
    location indicates whether the apparatus appears within the running text or external to it.

12.2.1 The Location-referenced Method

The location-referenced method of encoding apparatus provides a convenient method for encoding printed apparatus; in this method as in most printed editions, the apparatus is linked to the base text by indicating explicitly only the block of text on which there is a variant (noted usually by a canonical reference scheme, or by line number in the edition, such as A 137 or Page 15 line 1).

If the location-referenced method is used for an apparatus stored externally to the base text, the TEI header must have the declaration:
<variantEncoding method="location-referenced" location="external"/>
In the body of the document, the base text (here El) will appear:
<text>
 <body>
  <div n="WBP" type="prologue">
   <head>The Prologe of the Wyves Tale of Bathe</head>
   <l n="1">Experience though noon Auctoritee</l>
   <l>Were in this world ...</l>
  </div>
 </body>
</text>
Elsewhere in the document, or in a separate file, the apparatus will appear. On each app element, the loc attribute should be specified to indicate where the variant occurs in the base text.
<app loc="WBP 1">
 <rdg wit="#La">Experiment</rdg>
 <rdg wit="#Ra2">Eryment</rdg>
</app>
If the same text is encoded using in-line storage, the apparatus is dispersed through the base text block to which it refers. In this case, the location of the variant can be read from the line in which it occurs.
<variantEncoding method="location-referenced" location="internal"/>
<!-- ... -->
<l n="1">Experience
<app>
  <rdg wit="#La">Experiment</rdg>
  <rdg wit="#Ra2">Eryment</rdg>
 </app>
though noon Auctoritee</l>
<l>Were in this world ...</l>
Since the location is not required to be exact, the apparatus for a line might also appear at the end of the line:
<l n="1">Experience though noon Auctoritee
<app>
  <rdg wit="#La"> Experiment</rdg>
  <rdg wit="#Ra2"> Eryment</rdg>
 </app>
</l>
<l>Were in this world ...</l>
When the apparatus is linked to the text by means of location references, as shown here, it is not possible to find automatically the precise portion of text varied by the readings. In order to show explicitly what portion of the base text is replaced by the variant readings, the lem element may be used:
<l n="1">Experience though noon Auctoritee
<app>
  <lem wit="#El">Experience</lem>
  <rdg wit="#La">Experiment</rdg>
  <rdg wit="#Ra2">Eryment</rdg>
 </app>
</l>
<l>Were in this world ...</l>
Often the lemma will have no attributes, being simply the ‘base text reading’ and requiring no qualification, but it may optionally carry the normal attributes, as shown here. Some text critics prefer to abbreviate or elide the lemma, in order to save space or trouble; such practice is not forbidden by these Guidelines, but no recommendations are made for conventions of abbreviating the lemma, whether abbreviation of each word, or suppression of all but the first and last word, etc.

Where it is intended that the apparatus be complete enough to allow the reconstruction of the witnesses (or at least of their non-orthographic variations), simple location-reference methods are unlikely to be as successful as the other two methods, which allow the unambiguous reconstruction of the lemma from the encoding. The use of (for example) an XPath expression denoting a text range rather than a simple pointer may however obviate this necessity

12.2.2 The Double End-Point Attachment Method

In the double end-point attachment method, the beginning and end of the lemma in the base text are both explicitly indicated. It thus differs from the location-referenced method, in which only the larger span of text containing the lemma is indicated. Double end-point attachment permits unambiguous matching of each variant reading against its lemma. It or the parallel-segmentation method should be used in all cases where this is desired, for example where the apparatus is intended to enable full reconstruction of the text, or of the substantives, of every witness.

When the double end-point attachment method is used, the from and to attributes of the app element are used to indicate the beginning and ending points of the reading in the base text: their values are identifiers which occur at the locations in question. If no other markup is present there, the beginning and ending points should be marked using the anchor element defined in chapter 16 Linking, Segmentation, and Alignment. In cases where it is not possible to insert anchors within the base text (e.g. where the text is on a read-only medium) the beginning and end of the lemma may be indicated by using the ‘indirect pointing’ mechanisms discussed in chapter 16 Linking, Segmentation, and Alignment. Explicit anchors are more likely to be reliable, and are therefore to be preferred.

The double end-point attachment method may be used with in-line or external apparatus. In the latter case, the base text (here El) will appear with anchor elements inserted at every place where a variant begins or ends (unless some element with an identifier already begins or ends at that point):
<variantEncoding method="double-end-point" location="external"/>
<!-- ... -->
<div n="WBP" type="prologue">
 <head>The Prologe ... </head>
 <l n="1" xml:id="WBP.1">Experience<anchor xml:id="WBP-A2"/> though noon Auctoritee</l>
 <l>Were in this world ...</l>
</div>
The apparatus will be separately encoded:
<app from="#WBP.1" to="#WBP-A2">
 <rdg wit="#La">Experiment</rdg>
 <rdg wit="#Ra2">Eryment</rdg>
</app>
No anchor element is needed at the beginning of the line, since the from attribute can use the identifier for the line as a whole; the lemma is assumed to run from the beginning of the element indicated by the from attribute, to the end of that indicated by the to attribute. If no value is given for to, the lemma runs from the beginning to the end of the element indicated by the from attribute.
When the apparatus is encoded in-line, it is dispersed through the base text. Only the beginning of the lemma need be marked with an anchor, since the app is inserted at the end of the lemma, and itself therefore marks the end of the lemma.
<variantEncoding method="double-end-point" location="internal"/>
<!-- ... -->
<l n="1" xml:id="wbp.1">Experience
<app from="#wbp.1">
  <rdg wit="#La">Experiment</rdg>
  <rdg wit="#Ra2">Eryment</rdg>
 </app>
though noon Auctoritee</l>
<l>Were in this world ...</l>

The lemma need not be repeated within the app element in this method, as it may be extracted reliably from the base text. If an exhaustive list of witnesses is available, it will also not be necessary to specify just which manuscripts agree with the base text to enable reconstruction of witnesses. An application will be able to determine the manuscripts that witness the base reading, by noting which witnesses are attested as having a variant reading, and inferring the base text reading for all others after adjusting for fragmentary witnesses and for witnesses carrying overlapping variant readings.

Alternatively, if it is desired to make an explicit record of the attestation of the base text, the lem element may be embedded within app, carrying the witnesses to the base. Thus
<app from="#WBP.1" to="#WBP-A2">
 <lem wit="#El #Hg">Experience</lem>
 <rdg wit="#La">Experiment</rdg>
 <rdg wit="#Ra2">Eryment</rdg>
</app>
This method is designed to cope with ‘overlapping lemmata’. For example, at line 117 of the Wife of Bath's Prologue, the manuscripts Hg (Hengwrt), El (Ellesmere), and Ha4 (British Library Harleian 7334) read:
Hg
And of so parfit wys a wight ywroght
El
And for what profit was a wight ywroght
Ha4
And in what wise was a wight ywroght
In this case, one might wish to record in what wise was in Ha4 as a single variant for of so parfit wys in Hg, and was a wight in El and Ha4 as a variant on wys a wight in Hg. This method can readily cope with such difficult situations, typically found in large and complex traditions:
<l xml:id="WBP.117" n="117"> And
<anchor xml:id="WBP-A117.1"/> of so parfit
<anchor xml:id="WBP-A117.2"/> wys
<anchor xml:id="WBP-A117.3"/> a wight
<anchor xml:id="WBP-A117.4"/> ywroght
<app from="#WBP-A117.1" to="#WBP-A117.3">
  <lem wit="#Hg">of so parfit wys</lem>
  <rdg wit="#Ha4">in what wise was</rdg>
 </app>
 <app from="#WBP-A117.2" to="#WBP-A117.4">
  <lem wit="#Hg">wys a wight</lem>
  <rdg wit="#El #Ha4">was a wight</rdg>
 </app>
</l>
The parallel segmentation method, to be discussed next, cannot handle overlaps among variants, and would require the individual variants to be split into pieces.

Because creation and interpretation of double end-point attachment apparatus will be lengthy and difficult it is likely that they will usually be created and examined by scholars only with mechanical assistance.

12.2.3 The Parallel Segmentation Method

This method differs from the double end-point attachment method in that all variants at any point of the text are expressed as variants on one another. In this method, no two variations can overlap, although they may nest. Thus, the concepts of a base text and of a lemma become unnecessary: the texts compared are divided into matching segments all synchronized with one another. This permits direct comparison of any span of text in any witness with that in any other witness. It is also very easy with this method for an application to extract the full text of any one witness from the apparatus.

This method will (by definition) always be satisfactory when there are just two texts for comparison (assuming they are in the same language and script). It will also be useful where editors do not wish to privilege a text as the ‘base’ or when editors wish to present parallel texts. It will become less convenient as traditions become more complex and tension develops between the need to segment on the largest variation found and the need to express the finest detail of agreement between witnesses.

In the parallel segmentation method, each segment of text on which there is variation is marked by an app element; each reading is given in a rdg element; if it is desired to single out one reading as preferred, it may be tagged lem:
<variantEncoding method="parallel-segmentation" location="internal"/>
<!-- ... -->
<l n="1">
 <app>
  <lem wit="#El #Hg">Experience</lem>
  <rdg wit="#La">Experiment</rdg>
  <rdg wit="#Ra2">Eryment</rdg>
 </app>
though noon Auctoritee
</l>
<l>Were in this world ...</l>

This method cannot be used with external apparatus: it must be used in-line. Note that apparatus encoded with this method may be translated into the double end-point attachment method and back without loss of information. Where double-end-point-attachment encodings have no overlapping lemmata, translation of these to the parallel segmentation encoding and back will also be possible without loss of information.

For economy, the witnesses to the reading most widely attested need not be stated. Since all manuscripts must be represented in all apparatus entries, it will be possible for an application to read a listWit declaring all the witnesses to the text and then calculate which witnesses have not been named. In the example below, only La and Ra2 are identified explicitly with a reading; an application might successfully infer from this that Experience, whose witnesses are not given, must be attested by El and Hg. To avoid confusion, however, witnesses may be omitted only for a single reading.
<l n="1">
 <app>
  <lem>Experience</lem>
  <rdg wit="#La">Experiment</rdg>
  <rdg wit="#Ra2">Eryment</rdg>
 </app>
though noon Auctoritee
</l>
<l>Were in this world ...</l>

Alternatively, the witnesses for every reading may be stated, as in the first example.

As noted, apparatus entries may nest in this method: if an imaginary fifth manuscript of the text read Auctoritee, though none experience, the variation on the individual words of the line would nest within that for the line as a whole:
<l n="1">
 <app>
  <rdg wit="#Chi3">Auctoritee, though none experience</rdg>
  <rdg>
   <app>
    <rdg wit="#El #Hg">Experience</rdg>
    <rdg wit="#La">Experiment</rdg>
    <rdg wit="#Ra2">Eryment</rdg>
   </app>
   <app>
    <rdg wit="#El #Ra2">though</rdg>
    <rdg wit="#Hg">thogh</rdg>
    <rdg wit="#La">thouh</rdg>
   </app>
   <app>
    <rdg wit="#El #Hg">noon Auctorite</rdg>
    <rdg wit="#La #Ra2">none auctorite</rdg>
   </app>
  </rdg>
 </app>
</l>

Parallel segmentation cannot, however, deal very gracefully with variants which overlap without nesting: such variants must be broken up into pieces in order to keep all witnesses synchronized.

12.3 Using Apparatus Elements in Transcriptions

It is often desirable to record different transcriptions of one stretch of text. These variant transcriptions may be grouped within a single app element. An application may then construct different ‘views’ of the transcription by extraction of the appropriate variant readings from the apparatus elements embedded in the transcription.

For example, alternative expansions can be recorded in several different expan elements, all grouped within an app element. Consider, for example, the three different transcriptions given below of line 105 of the Hengwrt manuscript of Chaucer's The Wife of Bath's Prologue. The last word of the line Virginite is grete perfection is written perfectio followed by two minims over which a bar has been drawn, which has been read in different ways by different scholars. The first transcription, by Elizabeth Solopova, represents the two minims with bar above as a special composite character using the gelement. This transcription notes this as a mark of abbreviation but gives no expansion for it. A second transcriber, F. J. Furnivall, regards the bar as an abbreviation of u, and therefore reads the two minims as an n. A third transcriber, P. G. Ruggiers, regards the bar as an abbreviation of n, reading the minims as u. This information may be held within an app structure, as follows:
Virginite is grete
<app>
 <rdg resp="#ES">perfectio<am>
   <g ref="#ii"/>
  </am>
 </rdg>
 <rdg resp="#FJF">perfectio<ex>u</ex>n</rdg>
 <rdg resp="#PGR">perfectiou<ex>n</ex>
 </rdg>
</app>
This example uses special purpose elements am and ex used to represent abbreviation marks and editorial expansion respectively; these elements are provided by the transcr module documented in chapter 11 Representation of Primary Sources, which should be consulted for further discussion of methods of representing multiple readings of a source.
Editorial notes may also be attached to app structures within transcriptions. Here, editorial preference for Ruggiers' expansion and an explanation of that preference is given:
Virginite is grete
<app>
 <rdg resp="#ES">perfecti<am>
   <g ref="#ii"/>
  </am>
 </rdg>
 <rdg xml:id="f105" resp="#FJF">perfectio<ex>u</ex>n</rdg>
 <rdg xml:id="r105" resp="#PGR">perfectiou<ex>n</ex>
 </rdg>
</app>
<!-- ... <note> appearing elsewhere in the document ... -->
<note target="#r105 #f105">Furnivall's expansion implies that the bar
is an abbreviation for 'u'. There are no certain instances of
this mark as an abbreviation for 'u' in these manuscripts and it is
widely used as an abbreviation for 'n'. Ruggiers' expansion is to
be accepted.</note>

In most cases, elements used to indicate features of a primary textual source may be represented within an app structure simply by nesting them within its readings, just as the abbr and expan elements are nested within the rdg elements in the example just given. However, in cases where the tagged feature extends across a span of text which might itself contain variant readings which it is desired to represent by app structures, some adaptation of the tagging may be necessary. For example, a span of text may be marked in the transcription of the primary source as a single deletion but it may be desirable to represent just a few words from this source as individual deletions within the context of a critical apparatus drawing together readings from this and several other witnesses. In this case, the tagging of the span of words as one deletion may need to be decomposed into a series of one-word deletions for encoding within the apparatus. If it is important to record the fact that all were deleted by the same act, the markup may use the join element or the next and prev attributes defined by chapter 16 Linking, Segmentation, and Alignment.

12.4 Module for Critical Apparatus

The module described in this chapter makes available the following components:
Module textcrit: Critical Apparatus
The selection and combination of modules to form a TEI schema is described in 1.2 Defining a TEI Schema.

↑ Contents « 11 Representation of Primary Sources » 13 Names, Dates, People, and Places

Notes
38.
For the sake of legibility in the example, long marks over vowels are omitted.
↵

[English] [Deutsch] [Español] [Italiano] [Français] [日本語] [한국어] [中文]

TEI Consortium | Feedback
Copyright TEI Consortium 2007 Licensed under the GPL. Copying and redistribution is permitted and encouraged.
Version 1.4.0. Last updated on June 20th 2009.This page generated on 2009-06-21T10:06:14Z