So far we have been looking mostly at two very basic functions that markup can perform: identifying the boundaries of textual features and naming textual features.

These are both really important functions—fundamental to the ways markup can be useful to us. Knowing the boundaries of things and distinguishing between them are essential to the foundation of text encoding.

We might think of this kind of markup as being almost like clothing: it closely follows the form of the feature it's surrounding, it draws our attention to it, it marks out its boundaries (although, not always in a "natural" way).

In this tutorial, we are going to move beyond this basic concept of markup to consider some more complex things that markup can help us do. This includes creating information-bearing links between things and establishing connections between parallel structures. These mechanisms allow us to create information structures with the markup that don't necessarily follow the shape of the text, are not limited by its boundaries.

Notes and annotations are one very important form of structural complexity. They serve as a hypertextual fork in the textual stream. For example, a footnote sprouts off from the text at a certain point. It is not technically meant to be read where it occurs on the page, and in many ways sits apart from the rest of the text. Endnotes follow a similar principle, in that they're not meant to be read as a whole all at once. There's instead 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 (except in certain special cases for which annotation or annotationBlock may be used). These can be classified to indicate responsibility, or to indicate what kind of note (using any classification system that seems useful, e.g. annotation, correction, hypothesis, context, gloss, etc.)

You can see from the target attribute on note where the notes are anchored in the text. In this example, we're illustrating several different levels of annotation. The notes that use anchor are placed at a specific point, such as where the asterisk or superscripted number appears on the page (but note that in this case we don't know anything very specific about what the annotation is really annotating).

We can also anchor our notes to other bits of markup—the things that are being annotated. So for example, we can annotate a specific name, a specific quotation, an arbitrary word not already marked up, and a location in the text (all examples in the example).

The notes themselves can go anywhere; the example here has the notes into a special division in the back matter.

In addition, there may be some kinds of annotation that can be handled other ways, not with note but with something more flexible; in future slides we will discuss contextual encoding, which records additional information about entities referenced in the text (for example, regularized versions of names, brief notes, standardized data). If you are interested in a more detailed look at this topic, see our Contextual Encoding Primer.

This example shows how to markup and describe figures or images. This particular image contains a heading (transcribed from the source): the head element; the graphic with url contains a link to the source of the image. The figDesc element allows us to provide a description of the image, for the sake of accessibility. This element is especially useful if you want to encode a text when you don't have the rights to the page images. A caption (transcribed from the source) is also included, encoded using the ab element. We use the ab (or anonymous block) element when we encounter textual chunks that aren't exactly paragraphs, but still need to be marked with some type of chunk-like element. A transcription of the writing that is found within the graphic is recorded using the floatingText element.

If you do have access and rights to page images, it is sometimes useful to associate facsimiles of pages and parts of pages with your transcribed and encoded document: The facs attribute is available on any element; it points to an image file, either whole page or just a detail. You can use it to associate parts of your encoded document with a facsimile.

We've been talking about showing page images and facsimiles, which is a great way to give a very accurate representation of the source, but doesn't give us access to data about how the source document looked. When we want to include that data in our transcription, we can do so using the rend attribute, which is available on all TEI elements.

If you just want to say one simple thing about the appearance of an element (eg. italics, centered, bold, and so on) you can use the simple keyword approach at the top of this slide.

If you need to say more than one thing about the rendition of a given element, then you need to provide some internal structure inside the rend attribute. One way to do this is with something known as rendition ladders (which are not in wide use, but are fairly elegant). Another approach would be to use CSS style descriptors on the style attribute.

If you're not using the CSS method (i.e. you want to use the rend attribute), you make up the values yourself. The TEI does not provide any suggested values, so you can make up the attribute values according to what your project needs.

The TEI also provides a method for you to define different hands that appear in your text. The handNotes element allows you to describe the appearance of different handwritings, as well as defining whose hand is being described.

The hand attribute indicates which hand you are asserting wrote a given passage. For elements that do not have a hand attribute (e.g., item) or when handwriting changes in the middle of a passage, the handShift element is used, and the new attribute allows you to point to a specific hand in the handNotes, which essentially says this new hand starts here.

We can also represent a plurality of editorial opinions or textual witnesses as a piece of critical apparatus, using the app element. The optional lem gives the reading of the "base text", and the two rdg elements each represent a different editorial view of what the text really means (i.e a "reading"), each associated with a particular witness, represented by the wit attribute.

What if we have a plurality of readings because we have multiple witnesses? Here's an example of a hypothetical text that is a critical amalgam of two separate witnesses with slight local differences. The witnesses themselves are documented in a listWit element, and the individual readings are associated with the appropriate witness using the wit attribute. Note that you can associate a given reading with more than one witness if that's more economical.

We've gone over a fair number of TEI elements with quite specific purposes so far, and there are hundreds more out there—the TEI has anticipated a large number of textual features that we're going to want to encode, and created elements for them. However, the universe of texts is much larger than the universe of the TEI, and the TEI knows this. It can't possibly anticipate all the things people are going to want to encode, and even if it could, that's not a good way to design an encoding system.

Instead, the TEI provides a set of generic elements that encoders can use to encode the unforeseen. In these generic elements, instead of giving the element itself a very specific meaning (for instance, personal name, stage direction), the element itself carries almost no meaning at all: it just says "thing!". The semantics, the meaning of the element, is carried in an attribute value, which can be made up by the encoder.

As we show here, there are three main generic elements in TEI, one for each structural level: At the division level, we've already encountered the div element, from which we can fabricate chapters and sections and things of that scale. At the chunk level (things like paragraphs and lists), we have the ab element (stands for "anonymous block"). At the word or phrase level, we have the seg element (short for "segment"). There are also two generic empty elements that can replace more specific empty elements, like pb or handShift: milestone and anchor. Milestone is generally used for regularly repeating structures, like pages and signatures. Anchors, as we saw earlier, are often used for things like footnotes and endnotes.

As a thought experiment, let's think about XML overlap. If you think back to the first tutorial in this primer, when we discussed XML overlap, you may remember that we discussed that you can't have elements that aren't perfectly nested. In some cases, the simplest option may be to mark the beginning and end point of a given textual feature with empty elements. (As a reminder, empty elements are recorded like start tags, but with a forward slash after the element name and before the final angle bracket, like so: <emptyElement />). Milestone elements are the generic empty elements that allow us to mark where textual features begin and/or end.

Milestone elements are the most common empty elements you will encounter in a TEI document. We talked about this just a moment ago, but milestone elements divide the text into segments according to some system: pages, columns, lines. It 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). The particular example on this page is dividing the page up into signatures.

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.

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. A classic example of this we find in additions and deletions; authors often add large chunks of stuff, or delete parts of things that don't match the textual structure.

We can mark these types of textual features 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. We then create a link between the two so that we can be clear about where the thing we're marking up begins and ends.

In this example, we see a large chunk of deleted text and a large chunk of added. In the first example, we cannot simply place the start- and end-tags for a del element where the delSpan and anchor elements are because that would create XML overlap (bad!). The second example wouldn't work with add because that's a phrase-level element (and therefore must go inside p, rather than outside. In both of these cases empty elements provide us with a solution.

Sometimes XML structures don't perfectly represent the way that we think about texts. For example, in dramatic poetry, sometimes l (individual lines) are separated across sp elements. In the examples, we see some blank verse, with iambic pentameter lines divided between two characters. In this case, the TEI allows us to use fragmentation to show that these are a part of a single content object.

In these cases, we encode the content object (in this case the metrical line) as multiple separate XML elements. We then indicate that each XML element is only a partial element. Optionally, we can have each partial element indicate which is the next piece of the whole content object.

TEI provides two methods for doing this (the second is on the following slide). The one in the example uses the part attribute to indicate that the lines are divided. The part attribute can be used for serial cases (when all fragments are in sequential order).

This attribute is available on the l, lg, div, seg, ab, s, cl, phr, w, m, and c elements.

Another method for addressing fragmentation comes from the next and prev attributes. These attributes are available on every element. This method is commonly used on elements like said or quote that begin in the middle of one paragraph or line, and end in the next. In order to indicate fragmentation this way, you should put an xml:id on each line. You then use the next and prev attributes to indicate which element comes before or after the element listed.

For example: A person using the TEI encountered a very long bit of text. He cried, How can I ever encode this element if it crosses a paragraph?

I want to indicate that there is only one utterance, but the paragraph interrupts it! And I can't start the element in the middle of a paragraph, because that would cause xml:overlap!

Please skip this slide, it is specific to our workshops.