In earlier versions of the TEI, much of this information had to be encoded in ad hoc ways, separate from the encoded document. With a few exceptions (such as the regularization of names or the expression of interpretive information), the TEI did not provide for contextual information in the encoded document.

In TEI P5, there is much more extensive provision for this kind of information, through additions like ographies. These are like local authority lists that you create. These lists include the personography for information about people (prosopography), placeography for information about places (gazetteer), bibliography for citations, and orgography for information about organizations.

You can also apply keywords to the text as a whole which allows you to mark thematic or interpretive information to specific places in the text.

Contextual information can go in a few places. The first is in the teiHeader which provides a space for textual classifications (in classDecl and taxonomy), document-level keywords (in textClass), and a space for providing information about persons in your text (in particDesc).

For the information that does not go in your TEI header, use the standOff element. (It goes after the teiHeader, either before or after the text; most of us prefer before.) You can put ographies, interpretiave keywords, annotations, cast lists (e.g., for those speaking parts for which there is no entry in the source document), pointers (e.g., links and alts, likely collected into linkGrp and altGrp, etc.

Let's take a look at personographies first, since everyone will have references to people in some fashion (whether it be the persons working on the encoding or people named in your text).

Personograpies are local name authority files, where you keep information you want to express about the people named in your project.Your personography can be simple or very detailed; you may just want to record a standardized version of a person's name, or you might want to record detailed information about their life and activities (like a miniature, structured biography).

You can keep your personography locally in the file you are encoding, or somewhere external. If your list of people is very large, or you have several files that reference the same people, you may want to consider keeping your personography in another file.

We'll look first at personography. A few key points to note to start out: A personography ike a local name authority file: a place where you keep the information you want to express about the people named in your text It can be simple or very detailed: you might want to record just a standardized version of the the person's name, or you might want to record detailed information about their life and activities: almost like a miniature biography It can be kept in your encoded file or maintained externally: if you have a very large list of people, or if you need to share personographic data between multiple files, it may be better to maintain it externally. For our purposes, we're going to show how to encode it right in your encoded file.

Since a personography is a local authority file, each person element should get an identifier. This identifier is used to create an association between the reference in the text and the appropriate person entry in the personography.

Note that this allows us to create links between different ographies. So for example, you could link to a placeography from your personography, as you reference specific birth and death places.

The linking mechanism for all name-like elements (as well as referring string, or rs) is the ref attribute. This attribute allows us to point from a reference to its referent—or from the name in the text to the personography entry. Examples using the ref attribute are included in the two p elements.

So the basic essence of a personography is the management of the identity of individual people: so that we can say in our encoding of the text, we're specifically talking about this person here. So if there are two John Smiths in your texts, you can differentiate between them, even though they have the same name.

One of the things we can add to our basic identity management is what we might term simple demographic facts, or facts about the person that may lend themselves to formalization.

It's important to note here that formalization is the key to making your personographic data useful. The sample paragraph at the bottom of the slide contains the same informational content (to a human reader) as the encoded sample. However, it is dramatically less useful as data because it cannot be programmatically searched and processed.

Note as well that there are two kinds of elements here: those that are intended to capture some specific piece of information (e.g. nationality), and generic elements (trait and state) that provide a way to model unforeseen facts for which there isn't a pre-made element.

Take a minute to consider the data you have in your project: do you have information analogous to what's shown here that you want to model? What facts-about-people do you want to manage that aren't represented here?

Another important dimension of personographic information is time and biography: things that happen to people, states they pass through, facts that have a specific timespan in their lives. We've added some examples of these time-specific peices of information, for instance: education, residence, affiliations.

This is an area where the type and nature of the information is likely to vary a great deal from project to project, and where questions of quantity and useful granularity really come up. How much information of this kind will you use and what will you use it for? How do you plan to use it? That is, why is it worth representing in this form rather than as a short prose paragraph? Since capturing this information is very labor-intensive and thus expensive, you will want to make sure that you have a foreseeable use for the contextual information you encode.

Placeography is the awkward term used in the TEI world for encoded gazetteers and other aggregations of information about places.

They are very similar to personographies...but for places! Each place has an identifier, and the basic function here is to disambiguate between places (but also to provide a place to store whatever additional detail you want to represent).

It's worth thinking here about what detail you do want to represent. Compared with people, places have more common public significance, and as a result they are better documented in public places. Resources like Google Earth, Wikipedia, or geonames.org have a lot of basic data about places already (some of it very systematic and well-formalized). So if you're storing information locally you should be clear on why that's worth doing. It could be because you have more information, or could be because it's easier to work with if it's in your own format. However, it's good to keep in mind that you have external resources available to you.

It is also worth noting that places in a placeography can be linked to maps via geographic information data.

The example here shows several different kinds of places and the range of information you can represent: Places with a formal identity (cities, states) Places with a more individual or project-specific significance (e.g. people's homes) Addresses with detailed location data Locations marked by latitude and longitude Information about climate, population (and potentially other data as well, using trait)

There may be other types of information about places that you want to record. In these cases, you can customize the TEI (see our Customization Primer) and create new elements and attributes that record this type of information.

In addition to these very fully-developed ographies, the TEI provides three others: Orgography (concerning organizations) Bibliography (concerning published items) A generic ography for whatever other kind of entity you are capturing information about

The provision for bibliography is long-standing, familiar, and detailed and we won't cover it here.

The provision for orgography and the generic ography is essentially the same: in each case, you're given a few basic elements (orgName or label plus desc) with which to describe the entity and its properties. For simple data that doesn't need much formalization, this is OK, but it doesn't yield much analytical power (compared with the treatment of persons and places). The TEI does provide customization mechanisms, so that you can formalize these ographies better. For the discussion and tutorials for customizing the TEI, see our Customization Primer.

Interpretive keywords are a controlled vocabulary of interpretive terms (which might be derived from some standard thesaurus or might be invented by your project). They can be grouped, but they are essentially a flat structure—basically, the processor does not care about how they are grouped, but it may be useful for you to group them as an encoder or reader. The idea is that these are concepts or terms representing themes in the text that you want to identify consistently. For instance, this would be useful for supporting searches in cases when the text's own terminology is variable or where old spelling, language variation, etc., make ordinary word searching difficult.

This example is from the WWP and deals with themes that appear in the contextual essays and exhibits that comment on texts in WWO (and potentially could be used to tag these same themes in WWO texts as well).

Note that this information could also go in a separate file, especially if it will be referenced by multiple files.

The taxonomy element is useful when you want to create a more hierarchical set of terms, and where the different levels of the hierarchy are themselves important: for instance, users might want to search on a more general term and retrieve all items that are tagged with its child terms: e.g. all the fiction.

This example is from the WWP and deals with the genres of our texts.

Note that the TEI does provide a place for this in the header, but if it's to be referenced from multiple files it makes more sense to maintain it in a separate file, and then either include it with XInclude (which is how the WWP handles interpretive classifications) or reference it remotely. There are benefits to both versions: duplicating interpretive classifications in each teiHeader and creating a separate file with all of your interpretive classifications. You can use either method, depending on your preferences.

This example shows a variety of ways of associating these different types of topical identifications with the text. So, for example, terms from our taxonomy can be associated with the entire document, using textClass. Additionally, terms from either our taxonomy or our interp elements can be associated with the entire transcription or with specific parts of it.

Note that the ana attribute is global, which means that you can use it anywhere.