As a group, you will need to make and document decisions about how to handle encoding and publishing your texts. Below are some of the topics you should consider as you plan to encode your texts; it is almost certain that your individual documents will bring up additional phenomena that you will need to decide how to handle. Before you begin encoding, read through this page carefully; you should also read the sample document with basic encoding principles and the “Poor Robin” examples.
Making decisions about encoding
Phrase-level encoding
As a project, decide which phrase-level elements from your documents you want to tag. Review the WWP’s list of elements as well as the full list of TEI elements here. You might be particularly interested in the elements from the “Names and dates” module.
Questions to consider:
- What features are significant for your project (names of persons, places, organizations? quotations and titles? rhetorical and linguistic devices? dialogue?) and which elements will you use to tag those phenomena?
- Where might you use @type to capture additional details about the elements in your encoded texts?
- What values do you want to use with @type?
- Are there any elements that you would like to use but that are not provided by the TEI? If so, you can use @type with a constrained set of values on an appropriate “generic” element. See the instructions here.
Organizing your texts
You will also want to consider the organization of your texts. The TEI provides many elements for encoding each document’s organization—the whole text goes in the <text> element; you have <front>, <body>, and <back> for the front matter, body of the text, and back matter; you have <div> for major textual divisions, and you have <p> for paragraphs and <ab> for paragraph-sized chunks of text that aren’t actually paragraphs.
Questions to consider:
- What values do you want to use for @type on <div>? See an example list here.
- Are there other aspects of the organization you want to specify? For example, if you have poetry, you might also want to use @type on <lg> (line group) to distinguish sonnets from limericks.
Rendition
As a project, you’ll want to consider what kinds of rendition you are interested in. “Rendition” describes the appearances of a text, and might include information on typography, alignment, ornamentation, use of decorative initial capitals, etc. You’ll want to specify any aspects of the rendition you have decided not to record and articulate how you made such decisions. For example, it’s likely that you will consider the presence of italicized type significant no matter what approaches your project takes. However, levels of indentation might feel out of scope for the work you’re doing.
Since encoding is a process of controlled information loss, most projects have to decide which features are not relevant for their work (and the research done by their users) or are simply too expensive (in time, and, often, actual money) to record. For example, the WWP devotes a fair amount of time to recording renditional details (see the rendition section of the internal documentation to get a sense of how much time), but the project nonetheless does not record some things—changes in font size, for example. So, think about which aspects of the rendition are important to you and decide how you want to encode them. As a group, you will also decide which aspects of your documents’ appearance you will not be encoding and record those decisions in your editorial declaration.
Forme work
You will also want to consider what kinds of “forme work” you are interested in and how you’ll standardize the encoding of these features. Forme work includes page numbers, catchwords, signature marks, etc. See the TEI’s explanation of the <fw> element for more information. There might be some aspects of the forme work you will choose not to record, just as with rendition. Document these decisions as well.
Regularization and physical bibliography
You will need to decide how to handle missing or unclear text, handwritten annotations, text that you can’t read but can supply in from your own reading or another source, and other aspects of the materiality of your documents. You will also need to consider your handling of regularization: do you want to regularize original spellings? how do you want to handle typesetting errors? how do you want to represent the “long s” (ſ) character? Note: to enter characters like ſ that are not on your keyboard, you will need Unicode–the WWP has a quick guide here; this guide has some common code points and setup instructions for Mac users; PC users can insert these code points with the “Insert from Character Map” option under “Edit” in Oxygen, if you enter the code point in the search box and select “Character entity – hexadecimal.”
For an example of one approach to regularization, see the WWP’s statement on regularization and for more on encoding of physical bibliography, see the set of slides that begin here.
Interpretation and analysis
As a project, you will also want to decide what kinds of analytical encoding you’d like to do. To create a list of interpretive classifications, follow the example here. You can apply your interpretive concepts to any element using the @ana attribute—if you want to apply analysis to a segment of text that is not already in an element, wrap that segment of text in <seg>.
For example:
You should define each <interp> in your documents (in an “editorial” <div> in the <back>), but you’ll also want to include a list of these in your editorial declaration, and you might choose to expand on these and add examples there.
Other editorial interventions
You may also want to add notes or links to sources with more information. You can use the <ref> element with a @target attribute to fill in links to outside resources; you can use the <note> element to add annotations and the @target attribute to link those notes to the sections of your text you wish to annotate.
Making decisions about display
We will be using TEI Boilerplate to publish our documents; this is a resource that allows you to easily publish TEI documents online. If you save your TEI document in the “content” folder from the TEI exercise package, you can open it with the Firefox browser (just go to “Open” from the browser and then navigate to your document) to see what it will look like online. If you want to edit the display of your document, you can make changes in the “custom.css” file in the “css” folder in the TEI exercise folder. You can also see an example custom css file here.
TEI Boilerplate is not a substitute for a fully customized web publication system, but it will allow you to make relatively simple tweaks to your display. You can make choices about the color of elements marked with particular interpretive analyses, for example. You can also choose to display or suppress certain features (such as page numbers, or your editorial divisions). And, you can consider other ways the web interface can convey information about your encoding. For example, you may want unclear text to show up in brackets or you may want the contents of the @extent attribute to appear in the web display.
I will be on hand to help you edit your css files and I can also put your final versions online so that they can be viewed by anyone with the link (regardless of browser). But, you are responsible for thoughtfully deciding what kinds of display will best serve your documents and audience—and for explaining those decisions in your editorial declaration.
Writing your editorial declaration
Your editorial declaration should explain all of the significant decisions that you made in your encoding and publication processes; this document should be directed toward the audience who will be reading your documents and it should be clearly written and well organized. As you know, there are a great many decisions that comprise the encoding process; as editors, you need to be able to articulate these clearly so that readers will understand what they are seeing when they look at your documents. Your editorial declaration should also articulate the decisions you made about the display of your documents—again, write this document with the primary goal of enabling a reader to understand and evaluate the documents you have edited and published.
