So far we've been dealing overall with a fairly clean and straightforward view of the document, which we can express more or less as a tree structure

In the real world, however, documents are not really like trees

Or rather, they are like real trees rather than like mathematical trees: overhung with vines, spiderwebs, tree houses, all sorts of other stuff that connects their branches.

Gloss the diagram...

Parallel structures are one of the most important and common (and interesting) document features

Very important for what scholars do: in a sense, when they work with a text is explore and express its plurality of meaning, of textual possibility this is true whether they are acting as editors or as critics: whether they're preparing a new version of the text for publication, or creating a version for their own interpretive use.

But also more generally useful: to show alignment or comparison

First, some large-scale examples of this kind of parallelism: representing a translation

The functional goal in creating these kinds of parallel structures is to be able to let the reader use the parallel texts to make comparisons, see similarities, read the translation against the original, search in one language and get results in the other language, etc.

From the markup standpoint, the essential thing here is to be able to represent the alignment of the two texts, but the question of granularity (of how fine-grained the alignment is) depends on what kinds of functional goals you have

We're not going to cover the mechanisms in detail, because they're complex and tricky, but I want to show you the concept so that if you're thinking about doing this you know the fundamentals of what's involved

Start with showing alignment issues: coarse-grained (text level, stanza level): we can often infer the finer-grained alignment automatically (e.g. in verse where both texts have the same number of lines) fine-grained (line level, potentially below): in cases where more specific alignment is needed specific alignment doesn't scale up; instead, can use out-of-line approach

Explain linking and pointers

Parallelism also exists and may call for representation at a more local level

In these cases it's more like a temporary forking or divergence in the text: a case of multiple possibilities

In these next examples, we're still looking at parallelism, but instead of managing it through a linking mechanism, we're managing it in a different way: through an enclosing element.

These examples don't actually violate the ideal document tree view, but

This approach is useful for smaller and more local examples of parallel text. There are a number of kinds of local editorial changes that are often made in the process of transcription and editing: processes of regularization and correction that are often done silently and noted in an introduction: correction of typographical errors in the source regularization or modernization of spelling and typography expansion of abbreviations

In print-based editing, these choices are exclusionary: whichever kind of reading you decide to show the reader, its complementary version has to be suppressed (it could be indicated in a note or an appendix but it can't typically be displayed as part of the regular reading surface)

In an XML transcription, however, it's possible to represent both (or in principle multiple) readings in a data structure that shows their parallelism and treats them as alternatives, which can then be chosen (displayed, searched, etc.) when desired.

In TEI, this mechanism is the choice element, which represents a moment of textual forking, where instead of a single reading the text offers a choice of readings

Another important form of structural complexity: a hypertextual sprout or fork or jump in the textual stream For example, a footnote: which sprouts off from the text at a certain point Or an endnote, where there's in effect a cross-reference from a place in the text to a subsequent explanation

In TEI, all types of annotations are encoded using the note element these can be classified: to indicate responsibility, to indicate what kind of note (using any classification system that seems useful: e.g. annotation, correction, hypothesis, context, gloss, etc.)

Cross-references and other kinds of references are encoded with ref; NB that the target can point inside or outside the document.

What's at stake here: because the transcription of manuscript materials (and often printed texts as well) involves significant efforts of decipherment and in many cases conjecture or interpretation, and also because primary sources are informationally complex (authorial revision, erasures, missing letters, illegible passages, etc.), a responsible transcription needs to capture not just the end product but also information about the process and the editorial decision-making: not just produce a clean-looking innocent butter-wouldn't-melt-in-its-mouth transcription but preserve information about what was difficult or unclear

conventions for accomplishing this are familiar from print: carets and brackets for marking insertions and deletions, italics to indicate unclear text, footnotes to indicate hypothetical readings or to describe damaged sections

In text markup, the goal is to formalize as much of this information as possible and represent it systematically to classify the reasons for illegibility (where possible), to formalize the rationales for determining whether a given letter is illegible or simply unclear with the goal of making it possible to control the display of the reading surface of the text: to show or hide the deleted words and hypothetical readings, perhaps even to let the reader control the threshold of conjecture at which readings are displayed or hidden ("only show me things you're really certain about")

Next: show basic encoding features: unclear, supplied, gap, add, del

Our next topic: structures that don't fit into the tree at all...

As we've already noted, overlapping structures are a potential problem for all XML encoding

What's interesting for us here, particularly, is to note that many of the classic cases of overlap happen around material features of the text: in fact, one of the reasons we include materiality as a challenge of markup for scholarship is that as an information structure, as something to be represented, materiality so often cuts across the grain of textuality, as we see in the list of examples here.

Particularly common when encoding extant older texts: the encoder does not control structure

generally less common when creating documents

There are a variety of approaches to representing these kinds of overlapping structures in TEI: sometimes you just have one option sometimes there are a few different ways to approach the problem we'll look at the various possibilities; some we've already seen without realizing it

Simplest option: instead of encoding the feature by enclosing it in an element, instead just mark its boundaries with empty elements

The most common case of this is with milestone elements: Elements that divide the text into segments according to some system: pages, columns, lines works perfectly for an information structure which is completely flat and divides up the whole text into parts: page breaks, signatures, reels of a movie i.e. there's nothing in the text that isn't on some page; there's nothing in a paragraph that's not on some line in these cases, you mark the boundaries between segments, so each boundary element marks the end of one segment and the start of the next.

But in addition there are other cases where it's handy to be able to mark the ends of an element at arbitrary places, rather than having to fit the element neatly into the document hierarchy classic example is additions and deletions: authors often add large chunks of stuff, or delete parts of things that don't match the textual structure

For these, as we saw briefly yesterday, we can mark them much more effectively by putting an empty element at each end, sort of like marking the boundaries of an impromptu soccer field by putting your shoes at each end

Then create a link between the two, using the pointing system we talked about yesterday...

Take what is logically a single content object encode it as multiple separate XML elements indicate that each XML element is only a partial element optionally have each partial element indicate which is the next piece of the whole content object

TEI provides 2 methods for doing this; the first is the part= attribute...

The part attribute can be used for serial cases: all fragments are in sequential order no intervening occurrence of same element type that is not part of the aggregate element e.g., good for l but sometimes not q available on l, lg, div, seg, ab, s, cl, phr, w, m, c

The next and prev attributes can be used for any cases: available on every element when additional tagset for segmentation & alignment is used each fragment must bear either next or prev probably better if each fragment bears both