Critical Apparatus Workgroup

The Critical Apparatus workgroup is part of the TEI special interest group on manuscript SIG:MSS. This page provides a summary of the preliminary discussions regarding the current issues with the critical apparatus chapter.

Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middell (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)

A preliminary vocabulary question

The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.

MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to every branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants.

FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.

MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon.

Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?

RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.

MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot).

JC: Thinks this points to a slight divergent nature at the heart of the current critical apparatus recommendations. That of encoding an apparatus at the site of textual variance and encoding a structured view of a note entirely separate from the edited version of texts. (In mass digitization of critical editions, for example, one might have an <app> in a set of notes at the bottom of the page which are not encoded at the site of variance, or indeed necessarily connected with it.) It is this striving to both be able to encode all sorts of various legacy forms of apparatus as well as simultaneously catering for those who are recording the structure by which they will generate an apparatus in producing some output. So JC would argue that the first of these are apparatus and the second of these is a site/locus of textual variance.

The standpoint of developpers of computer-aided collation tools

Gregor Middell summarized this standpoint for the workgroup in a page on the model of Textual_Variance used in CollateX and Juxta

Issues with the current Critical Apparatus chapter/module

Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand".

Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work.

A reading covering several paragraphs

In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even <div>s.

Use case:

I'm encoding a 19th c. edition of a medieval text, and one of the 
witness has omissions of several paragraphs. Of course, the TEI schema 
won't let me put <p> elements inside an <app>/<lem> element...

- I use the parallel segmentation method
- It is important to me to keep a methodical link between the encoded 
apparatus and the notes noumbers in the original edition (the 
@n of each <app> tag bears the number of the footnote in the original 
edition)

Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. 
The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). 

Transpositions

In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions.

Scalability

In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses.

Refactoring

In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn.

conflicts between individual readings and the semantics of structural markup that surrounds it

In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.