This website is no longer being maintained as of June 2010.
For current DLF information please go to:
TEI Text Encoding in Libraries
Guidelines for Best Encoding Practices
Version 2.1 (March 27, 2006)
Comments to Matthew Gibson
(msg2d at virginia dot edu)
This document has been superceded by version 3.
This document is also available as a TEI document
I. Introduction and History
The Text Encoding Initiative Guidelines for Electronic Text Encoding and Interchange (referred to as the TEI Guidelines) were first published in 1994 and represent a tremendous achievement in electronic text standards by providing a highly sophisticated structure for encoding electronic text. Digital librarians have benefited greatly from the standardization provided by these guidelines, and the potential for interoperability and long-term preservation of digital collections facilitated by their wide adoption.
In 1998, the Digital Library Federation (DLF) sponsored the TEI and XML in Digital Libraries Workshop at the Library of Congress to discuss the use of the TEI Guidelines in libraries for electronic text, and to create a set of best practices for librarians implementing them. From this workshop, three working groups were formed the members of which represented some of the largest and most mature digital library programs in the U.S. Group 2 was charged with developing a set of recommendations for libraries using the TEI Guidelines in electronic text encoding. This group included the following representatives from six libraries:
At the ALA mid-winter (January 1999), the DLF task force revised a draft set of best practices, called TEI Text Encoding in Libraries: Guidelines for Best Practices (referred to as TEI in Libraries Guidelines). The revised recommendations were circulated to the conference working group in May 1999 and presented at the joint annual meeting of the Association of Computers and the Humanities and Association of Literary and Linguistic Computing in June 1999. Version 1.0 was circulated for comments in August 1999. These guidelines were endorsed by the DLF, and have been used by many digital libraries, including those of the task force members, as a model for their own local best practices. Libraries, museums and end-users have benefitted from a set of best practices for electronic text in a number of ways, including better interoperability between electronic text collections, better documented practices among digital libraries, and a starting point for discussion of best practices with commercial publishers regarding electronic text creation.
Written in 1998, this first iteration of TEI in Libraries Guidelines made no mention of XML, XSLT, or any of the other powerful tools that have now become common parlance and practice in creating digital documents and collections. Based on these important changes in markup technology, it came to the attention of the DLF and members of the original Task Force that the TEI in Libraries Guidelines required substantial revision. In 2002, the TEI Consortium published a new edition of the complete TEI Guidelines that conformed to XML specifications. In order to remain useful, the TEI in Libraries Guidelines had to be updated to reflect these developments.
Furthermore, librarians need more guidance than the original TEI in Libraries Guidelines provided. There are many library-specific encoding issues which need to be addressed and documented to ensure consistency. The intention of this document is to provide recommended paths of encoding for these issues.
In addition, these library guidelines have the potential to be much more useful if they can serve as a training document from which librarians can learn about text encoding and addressing particular encoding challenges. To fulfill this role, the guidelines require more examples and detailed explanations, giving documentation of the use of TEI in a library context. Librarians also need a set of standards and best practices for vendors and publishers who create electronic text for digital libraries, so that these collections adhere to the same archival standards as locally-created electronic text collections. With detailed guidelines that could serve as an encoding specification, librarians might encourage vendors to follow the principles in these standards, to facilitate the long-term preservation of commercially published electronic text collections, and more readily allow for cross-collection searching.
In order to facilitate the evolution of this document, another DLF-sponsored Task Force—some of the representatives of which were on the original Task Force—met on October 24-25, 2003 at the Cosmos Club in Washington, D.C.:
These representatives met to revise the original TEI in Libraries Guidelines in order that they:
After producing version 2.0 of the Guidelines, this group (with some changes in membership) met again at the Cosmos Club on February 13-14, 2006. Those in attendance were:
This group of continues to meet and based upon their discussions and resolutions, the following guidelines will continue to be updated and enhanced.
II. General Overview and Comments
These recommendations are for libraries using the XML version of the TEILite DTD (teixlite). There are many different library text digitization projects, for different purposes. With this in mind, the Task Force has attempted to make these recommendations as inclusive as possible by developing a series of encoding levels. These levels are meant to allow for a range of practice, from wholly automated text creation and encoding, to encoding that requires expert content knowledge, analysis, and editing.
Recommendations for Levels 1-4 are intended for projects wishing to create encoded electronic text with structural markup, but minimal semantic or content markup. Also, the encoding levels are cumulative: encoding requirements at each level incorporate the requirements of lower levels. Levels 1-4 allow the conversion and encoding of texts to be performed without the assistance of deep content knowledge and can be enriched with more markup at any time. Level 5, in contrast, requires scholarly analysis.
These recommendations are concerned with the text portion of a TEI-encoded document. While there are modest requirements for including certain information about encoding level in the TEI Header, a separate set of recommendations, now integrated into this document, was developed to address issues concerning TEI Header contents to MARC-format bibliographic data (see the <teiHeader> Document from Working Group 1).
III. General Recommendations
Note: all recommendations that follow are based on P4:2004.
IV. The TEI Header (based on June 16, 2001 Draft)
At the TEI and XML in Digital Libraries Workshop that was held at the Library of Congress in July 1998, several working groups were formed to consider various aspects of the Text Encoding Initiative. Group 1 was charged to recommend some best practices for TEI Header content and to review the relationship between the Text Encoding Initiative header and MARC. To this end, representatives of the University of Virginia Library and the University of Michigan Library gathered in Ann Arbor in early October 1998 to develop a recommended practice guide. This work was assisted by similar efforts that had taken place in the United Kingdom under the auspices of the Oxford Text Archive the previous year. The following document represents a draft of those recommended practices. It has been submitted to various constituencies for comment.
Working Assumptions
A TEI Header can serve many publics. Headers can be created in a text center and reflect the center's standards, or they can serve as the basis for other types of metadata system records produced by other agencies. Headers can function in detached form as records in a catalog, as a title page inherent to the document, or as a source for index displays.
In addition, a header may describe a collection of documents, a single item, or a portion of an item. Variances in TEI Header content can result from making different choices of what is being described.
A TEI Header may not have a one to one correspondence with a MARC record. One TEI Header may have multiple MARC analytic records, or one MARC record may be used to describe a collection of TEI documents with individual headers.
A TEI Header serves several purposes. It may contain an historical background on how the file has been treated. It can extend the information of a classic catalog record. The Text Center and/or cataloging agency can act as the gatekeeper for creators by providing standards for content.
Does the TEI Header act as the electronic title page or as a catalog record? Is it integral to the document it describes or independent? Depending on the community being served, the TEI elements will reflect the interest of that community. Nonetheless, it is possible to describe a set of "best practices" that will produce compatible content while accommodating this variety of purposes. Compatibility of content encourages a more understandable set of results when information about assorted items is displayed as a set of search results, a contents list, or an index, and it allows for more reasonable conversion of content information from TEI tags to elements of other metadata sets when this action seems advisable.
It is a traditional practice of librarianship to agree upon where in a document and in what order of preference one should look to identify the title, author, etc., of that document. This permits a certain consistency in terminology and allows for a certain amount of authentication of content. We recommend the following preferences to those who create headers and to those who attempt to use headers to create traditional catalog records that are compliant with AACR2 and ISBD(ER) rules.
As a member of the academic community, the header creator/editor has a responsibility to verify, whenever humanly possible, the intellectual source for an electronic document that presents itself without any information regarding its source or authorship.
Chief Sources of Information for Several Types of Electronic Resources Are:
*Verified means that the cataloger/editor has established for him/herself that the information represented as title information is an accurate representation of content.

Element Recommendations for the teiHeader
<teiHeader type="____">
Standards which apply to the header, e.g., <teiHeader type="ISBD(ER)">, <teiHeader type="AACR2">
<title type="____">Only uniform title and main title should be entered here, e.g., <titleType="uniform"> or <titleType="main">. See <sourceDesc> for other title forms for documents where a user might seek the documents under titles other than those assigned. Where a title is provided by the header creator rather than the document creator, the title should be enclosed in square brackets using standard English language conventions for editorial insertion.
<author>Author of original source (electronic or print) should be entered into the <author> element before the <respStmt>. Use discrete elements within <author> element for "last name", "first name", "middle name", "date", "position title" to allow future flexibility in display, indexing, and in transferring to MARC. Whenever possible, establish or use nationally established forms of names. The name should be inverted and entered in the established form.
<editor>Editor of original source (electronic or print) should be entered into the <editor> element before the <respStmt>.
<respStmt>The editor (also compiler, illustrator) of an electronic version should be entered into the appropriate element in the <respStmt>. The name should be inverted and entered in the established form.
<editionStmt>Caution: Remind users that the edition statement here refers to the electronic piece--not the original item. This field should be used sparingly as there are currently no standards as to when versions become editions. Users should refer to the instructions in the TEI manual.
<extent>Use the standard text "ca.**** kilobytes".
<publicationStmt>Caution: This statement describes the electronic file.
<publisher>The publisher is whoever has collected the electronic text and has made decisions concerning it.
<distributor>The distributor is whoever makes the electronic text available.
<idno>Any unique identification number determined by the publisher.
<availability>Use specialized elements when anticipating sharing of the header or free text if only local usage is expected. Caution: Know your audience.
<date>Refers to the date of the publication of the electronic document. For most purposes, the year date (yyyy) will be adequate. If greater detail is required, enter dates as yyyymmdd.
<seriesStmt>Whenever possible, establish the national authority file authorized form for the electronic locally created series.
<notesStmt>Optional, depending on display decisions. Should be used for indicating questionable attributions for title, author, etc.
<sourceDesc>In order to effectively represent the source(s) when many documents are represented by the TEI Header, we see the need for structured elements that minimally allow us to identify parent-child and component relationships. In the absence of these structures, we suggest that multiple source descriptions be employed with relationships described in free text. Relationships also could be useful in other portions of the TEI Header. Cataloger may need to do research to establish the original source.
<bibl> or <biblStruct> or <biblFull>Prefer <biblFull> to allow searching on parts of the description.
<title>It is possible to have multiple <title> fields in <biblFull>. Alternative titles (cover, running, spine titles) should be entered in separate <title> fields in the <biblFull> field in the <sourceDesc> where they are searchable.
<author>If the name of the author(s) in the originating source differs from the established form, include here the form from the source tagged <author type="alternate">.
<editionStmt>Enter edition statement as found on the original source.
<extent>Enter physical description for the original source.
<publicationStmt> <publisher>Don't repeat field. Enter multiple publishers divided by semicolons.
<pubPlace>Don't repeat field. Enter multiple publishers divided by semicolons.
<date>Imprint date for the original source. For most purposes, the year date (yyyy) will be adequate. If greater detail is required, enter dates as yyyymmdd.
<idno>In this location, <idno> refers to identification numbers for the source document. They can be used to indicate the source's location in an individual institution's collection. If a formal standard location system is being used, indicate the nature of the system, e.g., <idno type="LC call number">.
<seriesStmt>Establish via national authority file the series statement of original document.
<notes>Caution: Notes made here should refer to the original source.
<projectDesc>Enter a description of the purpose for which the electronic file was encoded.
<editorialDecl>Enter general and specific statements about how the electronic file has been treated. Record here editorial decisions made during encoding.
<refsDecl><refsDecl> seems a possibility for adminis- trative metadata, e.g., pagination and page sequencing.
<classDecl> <taxonomy id="____">If used, identify the appropriate taxonomy definitions or descriptive sources in the <taxonomy> element followed by id, e.g., <taxonomy id="LCSH">, <taxonomy id="AAT">.
<creation>      <date>Use the date as it comes from the creator. For most purposes, the year date (yyyy) will be adequate. If greater detail is required, enter dates as yyymmdd.
<langUsage>Language usage is specified by document creators. Use standard language names.
<language id="____">Use the ISO 639-2 standard (which is the same as the MARC language codes).
<textClass>True classification numbers as opposed to call numbers can be entered here.
Use for uncontrolled terms.
<keywords scheme="____">
Use for controlled vocabulary as specified in <encodingDesc> taxonomy id. Example: scheme="LCSH"
<change> <resp> <item>
Use the specific codes to note revisions rather than free text description. Include the entire date (e.g., 19991101).
Minimal TEI Header Recommendation
Repeat the <biblFull> field, as appropriate, if there is more than one source for the electronic item. See some examples in context ...
Recommended Additions to the teixlite DTD
Acknowledgments and Bibliography
V. Encoding Levels
V.1. LEVEL 1: Fully Automated Conversion and Encoding
Purpose: To create electronic text with the primary purpose of keyword searching and linking to page images. The primary advantage in using the teixlite DTD at this level is that a TEI Header is attached to the text file.
Rationale: The text is subordinate to the page image, and is not intended to stand alone as an electronic text (without page images).
Texts at Level 1 can be created and encoded by fully automated means, using uncorrected OCR of page images ("dirty OCR"), exporting from existing electronic text files, or actually not including any text at all. Only those elements that are necessary to divide the text from the header and facilitate linking to page images are used. Encoding is performed automatically based on artifacts of the OCR or other document creation process (page breaks, for example) and metadata collected during the imaging or preparation process. This encoding is both minimal and reliable, and does not typically require extensive review of each page of each text.
Level 1 texts are not intended to be adequate for textual analysis; they are more likely to be suited to the goals of a preservation unit or mass digitization initiative. Though their encoding is minimal, Level 1 texts are fully valid XML texts. In addition to taking advantage of the TEI Header, using the teixlite DTD--with the consistency suggested by these guidelines--allows Level 1 texts to be compatible with more richly encoded teixlite texts (that also follow these guidelines) for searching, for example. Further encoding based on document structures or content analysis can be added to a Level 1 text at any time.
Level 1 is most suitable for projects with the following characteristics:
If no type= attribute is specified, a type= of "section" should be presumed (type="section").
At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using <p> in order that the document be open to being extended to other encoding levels).
Required in Level 1. Page images can be linked to the text using the value of id=. Because IDs are unique, using them on pagebreak elements makes it easier to ensure correct linkages to page image filenames. Page numbers can be supplied with the n= attribute to record the number that is on the page. The Task Force sees the use of METS here as having a tremendous advantage. METS/TEI page turning documentation will be included in the near future.
Basic Structural Example:
<TEI.2 id="someid">
[Source and processing information goes here]
<pb id="p00000001" n="1"/>
[main body of the unmarked up plain text begins here]
<pb id="p00000002" n="2"/>
[more plain text goes here with appropriate page breaks interspersed] ...
<pb id="p00000145" n="145"/>
[more plain text]
<pb id="p00000146" n="146"/>
[text ends here]
See an example in context...
V.2. LEVEL 2: Minimal Encoding
Purpose: To create electronic text for full-text searching, linking to page images, and identifying simple structural hierarchy to improve navigation.
Rationale: The text is subordinate to the page image, though navigational markers (textual divisions, heads) are captured. The text could stand alone as electronic text (without page images) if the accuracy of its contents is suitable to its intended use and it is not necessary to display low-level typographic or structural information. Level 2 requires a set of elements more granular than those of Level 1, including bibliographic or structural information below the monographic or volume level.
Though texts at Level 2 can be created and encoded by automated means, based on the typographic elements in the electronic file (for example, bold centered text at the top of the page surrounded by whitespace indicates a new chapter head, and thus a new division), it is not likely to be absolutely reliable across a large body of material. Level 2 encoding requires some human intervention to identify each textual division and heading. Level 2 texts do not require any specialist knowledge or manual intervention below the section level.
Level 2 texts are not intended to be displayed separately from their page images. Level 2 encoding of sections and heads provides greater navigational possibilities than Level 1 encoding, and enables searching to be restricted within particular textual divisions (for example, searching for two phrases within the same chapter).
Level 2 is most suitable for projects with the following characteristics:
All elements specified in Level 1 plus the following:
<front>, <back>Optional
<div1>type="section" is the default attribute value. It is recommended that the n= attribute be included to record the sequence of divisions.
<head>Required if present
<p>One "container" element per div is required.
Basic Structural Example:
<TEI.2 id="someid">
[Source and processing information goes here]
<text id="someotherid">
[titlepage information, table of contents, prefaces, etc.]
<div1 type="chapter" n="1">
<head>Chapter 1</head>
<p>[text of Chapter 1 goes here interspersed with <pb/> elements pointing to page images]</p>
<div1 type="chapter" n="2">
<head>Chapter 2</head>
<p>[text of Chapter 2 goes here interspersed with <pb/> elements pointing to page images]</p>
<div1 type="chapter" n="3">
<head>Chapter 3</head>
[text of Chapter 3 goes here interspersed with <pb/> elements pointing to page images]
<div1 type="chapter" n="4">
<head>Chapter 4</head>
[text of Chapter 4 goes here interspersed with <pb/> elements pointing to page images]
[optional text of backmatter, appendices, etc.]
See an example in context...
V.3. LEVEL 3: Simple Analysis
Purpose: To create text that can stand alone as electronic text and identifies hierarchy and typography without content analysis being of primary importance.
Rationale: Level 3 texts can be created from scratch or by the relatively easy conversion of existing HTML or word-processing documents. Encoding offers the advantage of the TEI Header, interoperability with other TEI collections, and extensibility to higher levels of encoding. Level 3 generally requires some human editing, but the features to be encoded are determined by the appearance of the text and not specialized content analysis.
Level 3 texts identify front and back matter, and all paragraph breaks. The finer granularity of tagging these features, as well as figures, notes, and all changes of typography, allows a range of options for display, delivery, and searching. For example, one has the option of identifying and, therefore, specifying the display charactersitics of different typographic styles, and regularizing the display and placement of note text.
Level 3 texts can stand alone as text without page images and, therefore, can be uploaded, downloaded and delivered quickly, and require less storage space than digital collections with page images. However, the simple level of structural anaylsis and absence of specialized content analysis reflected in Level 3 tagging may make it desirable for some, depending on project priorities, to include page images in order to provide users with a fuller set of resources.
Level 3 is most suitable for projects with the following characteristics:
All elements specified in Levels 1 and 2, plus the following:
<front>, <back>Required if present.
<p>Required for paragraph breaks in prose; may be used for stanzas using <lb/> for line breaks in verse.
<list> and <item>May be used in this level to indicate ordered and unordered list structures.
<table>, <row>, and <cell>May be used to indicate table structures.
<figure>Required to indicate figures other than page images.
<hi>Required to indicate changes in typeface; rend attribute is optional.
<note>All notes must be encoded. It is also recommended that notes that extend beyond one page be combined into one <note> element. Marginal notes, without reference, should occur at the beginning of the paragraph to which they refer, with the value of the place attribute as "margin".
<lb>May be used to force line breaks.
NOTE ON <note>:
It may be desirable to move footnotes from their original location in the text. If left at the bottom of a page, a note may become included in another paragraph or section of the encoded text, and thus separated from its reference. There are options for placement of footnotes if they are moved:
Basic Structural Example forthcoming ...
V.4. LEVEL 4: Basic Content Analysis
Purpose: To create text that can stand alone as electronic text, identifies hierarchy and typography, specifies function of textual and structural elements, and describes the nature of the content and not merely its appearance. This level is not meant to encode or identify all structural, semantic or bibliographic features of the text.
Rationale: Greater description of function and content allows for:
Texts encoded at Level 4 are able to stand alone as part of a library collection, and do not require page images in order for them to be read by students, scholars and general readers. This level of TEI encoding allows them to be displayed or printed in a variety of ways suitable for classroom or scholarly use.
Level 4 texts contain elements and attributes that describe content. For example, lines of verse are tagged with <l>; the <p> element is reserved for true paragraphs. Features of the text that may contribute to meaning, such as indentation of verse lines and typographic change, are preserved. These are textual features that are not encoded at lower levels and that allow the text to be used and understood fully independent of images.
The ability to stand alone as text means that Level 4 texts are more nimble and robust for exercises such as format repurposing and textual analysis.
Finally, functionally accurate tagging in Level 4 texts allows them to be searched or displayed in sophisticated ways. For example, a searcher could limit his or her search in a dramatic text to stage directions or to the speeches of a particular character. In a volume of poetry published by subscription, a search could be confined to names that appear in lists, thus limiting a search to names of people who subscribed to a particular volume. This ability to limit searches becomes more significant as textbases become larger, and thus is of great importance to the library community as it attempts to build into the initial design and implementation of textbases features needed to enhance interoperability.
Level 4 is most suitable for projects with the following characteristics:
General Level 4 Recommendations:
See some examples in context...
Level 4 Prose:
See an example in context...
Level 4 Drama:
See an example in context...
Level 4 Oral History:
See an example in context...
Level 4 Verse:
See an example in context...
Level 4 Front and Back Matter:
It is recommended that all prefaces, tables of contents, afterwords, appendices, endnotes and apparatus be encoded. For publisher's advertisements, indexes, and glossaries or other front or back matter that isn't considered of primary importance to the text, there are three options:
See an example in context...
V.5. LEVEL 5: Scholarly Encoding Projects
Level 5 texts are those that require subject knowledge, and encode semantic, linguistic, prosodic or other elements beyond a basic structural level.
VI. General Guidelines for Attribute Usage
Like divisional markers, attributes should be specified in a hierarchy of order. The rationale for this hierarchy of order is that if you are using procedural scripting languages to transform or manipulate text, it is much easier to have consitent and predictable attribute sequences than not. The basic rule is that broader and more global information be defined before those attributes that further qualify or constrict that information:
return to top >>
Copyright © 2006 Digital Library Federation. All rights reserved.
Last updated: Friday, January 31, 2020
Link: Digital CollectionsLink: Digital ProductionLink: Digital PreservationLink: Use, users, and user supportLink: Build: Digital Library Architectures, Systems, and Tools
Bibliotheca AlexandrinaBritish LibraryCalifornia Digital LibraryCarnegie Mellon UniversityColumbia UniversityCornell UniversityCouncil on Library and Information ResourcesDartmouth CollegeEmory UniversityHarvard UniversityIndiana UniversityJohns Hopkins UniversityLibrary of CongressMassachusetts Institute of TechnologyNew York Public LibraryNew York UniversityNorth Carolina State UniversityOxford UniversityPennsylvania State UniversityPrinceton UniversityRice UniversityStanford UniversityUniversity of California, BerkeleyUniversity of California, Los AngelesUniversity of ChicagoUniversity of Illinois at Urbana-ChampaignUniversity of MichiganUniversity of MinnesotaUniversity of PennsylvaniaUniversity of Southern CaliforniaUniversity of TennesseeUniversity of Texas at AustinUniversity of VirginiaUniversity of WashingtonU.S. National Archives and Records AdministrationU.S. National Library of MedicineYale UniversityCoalition for Networked Information (CNI)Inter-university Consortium for Political and Social Research (ICPSR)Joint Information Systems Committee (JISC)Los Alamos National Laboratory Research Library OCLC Online Computer Library CenterDLF Executive Director