The teiHeader element should be clearly distinguished from the front matter of the text itself (for which see section ). A composite text, such as a corpus or collection, may contain several headers, as further discussed below. In the general case, however, a TEI-conformant text will contain a single teiHeader element, followed by a single text or facsimile element, or both.

The header element has the following description:

As discussed above, the teiHeader element has five principal components:

Of these, only the fileDesc element is required in all TEI headers; the others are optional. That is, only one of the five components of the TEI header (the fileDesc) is mandatory, and it also has some mandatory components, as further discussed in below. The smallest possible valid TEI Header thus looks like this:

The content of the elements making up a TEI header may be given in any language, not necessarily that of the text to which the header applies, and not necessarily English. As elsewhere, the xml:lang attribute should be used at an appropriate level to specify the language. For example, in the following schematic example, an English text has been given a French header:

In the case of language corpora or collections, it may be desirable to record header information either at the level of the individual components in the corpus or collection, or at the level of the corpus or collection itself (more details concerning the tagging of composite texts are given in section , which should be read in conjunction with the current chapter). A corpus may thus take the form:

The elements occurring within the TEI header may contain several types of content; the following list indicates how these types of content are described in the following sections: free prose Most elements contain simple running prose at some level. Many elements may contain either prose (possibly organized into paragraphs) or more specific elements, which themselves contain prose. In this chapter's descriptions of element content, the phrase prose description should be understood to imply a series of paragraphs, each marked as a p element. The word phrase, by contrast, should be understood to imply character data, interspersed as need be with phrase-level elements, but not organized into paragraphs. For more information on paragraphs, highlighted phrases, lists, etc., see section . grouping elements Elements whose names end with the suffix Stmt (e.g. editionStmt, titleStmt) and the xenoData element enclose a group of specialized elements recording some structured information. In the case of the bibliographic elements, the suffix Stmt is used in names of elements corresponding to the areas of the International Standard Bibliographic Description. For more information on this highly influential family of standards, first proposed in 1969 by the International Federation of Library Associations, see . On the relation between the TEI proposals and other standards for bibliographic description, see further section . In the case of the xenoData element, the specialized elements are not TEI elements, but rather come from some other metadata scheme. In most cases grouping elements may contain prose descriptions as an alternative to the set of specialized elements, thus allowing the encoder to choose whether or not the information concerned should be presented in a structured form or in prose. declarations Elements whose names end with the suffix Decl (e.g. tagsDecl, refsDecl) enclose information about specific encoding practices applied in the electronic text; often these practices are described in coded form. Typically, such information takes the form of a series of declarations, identifying a code with some more complex structure or description. A declaration which applies to more than one text or division of a text need not be repeated in the header of each such text or subdivision. Instead, the decls attribute of each text (or subdivision of the text) to which the declaration applies may be used to supply a cross-reference to it, as further described in section . descriptions Elements whose names end with the suffix Desc (e.g. settingDesc, projectDesc) contain a prose description, possibly, but not necessarily, organized under some specific headings by suggested sub-elements.

The TEI header provides a very rich collection of metadata categories, but makes no claim to be exhaustive. It is certainly the case that individual projects may wish to record specialized metadata which either does not fit within one of the predefined categories identified by the TEI header or requires a more specialized element structure than is proposed here. To overcome this problem, the encoder may elect to define additional elements using the customization methods discussed in . The TEI class system makes such customizations simpler to effect and easier to use in interchange.

These classes are specific to parts of the header:

The titleStmt element is the first component of the fileDesc element, and is mandatory: It contains the title given to the electronic work, together with one or more optional statements of responsibility which identify the encoder, editor, author, compiler, or other parties responsible for it:

The title element contains the chief name of the electronic work, including any alternative title or subtitles it may have. It may be repeated, if the work has more than one title (perhaps in different languages) and takes whatever form is considered appropriate by its creator. Where the electronic work is derived from an existing source text, it is strongly recommended that the title for the former should be derived from the latter, but clearly distinguishable from it, for example by the addition of a phrase such as : an electronic transcription or a digital edition. This will distinguish the electronic work from the source text in citations and in catalogues which contain descriptions of both types of material.

The electronic work will also have an external name (its filename or data set name) or reference number on the computer system where it resides at any time. This name is likely to change frequently, as new copies of the file are made on the computer system. Its form is entirely dependent on the particular computer system in use and thus cannot always easily be transferred from one system to another. Moreover, a given work may be composed of many files. For these reasons, these Guidelines strongly recommend that such names should not be used as the title for any electronic work.

Helpful guidance on the formulation of useful descriptive titles in difficult cases may be found in chapter 25 of ) or another national cataloguing code.

The elements author, editor, sponsor, funder, and principal, are specializations of the more general respStmt element. These elements are used to provide the statements of responsibility which identify the person(s) responsible for the intellectual or artistic content of an item and any corporate bodies from which it emanates.

Any number of such statements may occur within the title statement. At a minimum, identify the author of the text and (where appropriate) the creator of the file. If the bibliographic description is for a corpus, identify the creator of the corpus. Optionally include also names of others involved in the transcription or elaboration of the text, sponsors, and funding agencies. The name of the person responsible for physical data input need not normally be recorded, unless that person is also intellectually responsible for some aspect of the creation of the file.

Where the person whose responsibility is to be documented is not an author, sponsor, funding body, or principal researcher, the respStmt element should be used. This has two subcomponents: a name element identifying a responsible individual or organization, and a resp element indicating the nature of the responsibility. No specific recommendations are made at this time as to appropriate content for the resp: it should make clear the nature of the responsibility concerned, as in the examples below.

Names given may be personal names or corporate names. Give all names in the form in which the persons or bodies wish to be publicly cited. This would usually be the fullest form of the name, including first names.Agencies compiling catalogues of machine-readable files are recommended to use available authority lists, such as the Library of Congress Name Authority List, for all common personal names.

Examples: compiled by P.J. Lucas Poe, Edgar Allen (1809-1849) compiled by James D. Benson Wellcome Institute for the History of Medicine Dominik Wujastyk Wieslaw Mical data entry and proof correction Jan Hajic conversion to TEI-conformant markup

The editionStmt element is the second component of the fileDesc element. It is optional but recommended. It contains either phrases or more specialized elements identifying the edition and those responsible for it:

For printed texts, the word edition applies to the set of all the identical copies of an item produced from one master copy and issued by a particular publishing agency or a group of such agencies. A change in the identity of the distributing body or bodies does not normally constitute a change of edition, while a change in the master copy does.

For electronic texts, the notion of a master copy is not entirely appropriate, since they are far more easily copied and modified than printed ones; nonetheless the term edition may be used for a particular state of a machine-readable text at which substantive changes are made and fixed. Synonymous terms used in these Guidelines are version, level, and release. The words revision and update, by contrast, are used for minor changes to a file which do not amount to a new edition.

No simple rule can specify how substantive changes have to be before they are regarded as producing a new edition, rather than a simple update. The general principle proposed here is that the production of a new edition entails a significant change in the intellectual content of the file, rather than its encoding or appearance. The addition of analytic coding to a text would thus constitute a new edition, while automatic conversion from one coded representation to another would not. Changes relating to the character code or physical storage details, corrections of misspellings, simple changes in the arrangement of the contents and changes in the output format do not normally constitute a new edition, whereas the addition of new information (e.g. a linguistic analysis expressed in part-of-speech tagging, sound or graphics, referential links to external data sets) almost always does.

Clearly, there will always be borderline cases and the matter is somewhat arbitrary. The simplest rule is: if you think that your file is a new edition, then call it such. An edition statement is optional for the first release of a computer file; it is mandatory for each later release, though this requirement cannot be enforced by the parser.

Note that all changes in a file considered significant, whether or not they are regarded as constituting a new edition or simply a new revision, should be independently noted in the revision description section of the file header (see section ).

The edition element should contain phrases describing the edition or version, including the word edition, version, or equivalent, together with a number or date, or terms indicating difference from other editions such as new edition, revised edition etc. Any dates that occur within the edition statement should be marked with the date element. The n attribute of the edition element may be used as elsewhere to supply any formal identification (such as a version number) for the edition.

One or more respStmt elements may also be used to supply statements of responsibility for the edition in question. These may refer to individuals or corporate bodies and can indicate functions such as that of a reviser, or can name the person or body responsible for the provision of supplementary matter, of appendices, etc., in a new edition. For further detail on the respStmt element, see section .

Some examples follow: Second draft, substantially extended, revised, and corrected. Student's edition, June 1987 New annotations by George Brown

The extent element is the third component of the fileDesc element. It is optional.

For printed books, information about the carrier, such as the kind of medium used and its size, are of great importance in cataloguing procedures. The print-oriented rules for bibliographic description of an item's medium and extent need some re-interpretation when applied to electronic media. An electronic file exists as a distinct entity quite independently of its carrier and remains the same intellectual object whether it is stored on a magnetic tape, a CD-ROM, a set of floppy disks, or as a file on a mainframe computer. Since, moreover, these Guidelines are specifically aimed at facilitating transparent document storage and interchange, any purely machine-dependent information should be irrelevant as far as the file header is concerned.

This is particularly true of information about file-type although library-oriented rules for cataloguing often distinguish two types of computer file: data and programs. This distinction is quite difficult to draw in some cases, for example, hypermedia or texts with built in search and retrieval software.

Although it is equally system-dependent, some measure of the size of the computer file may be of use for cataloguing and other practical purposes. Because the measurement and expression of file size is fraught with difficulties, only very general recommendations are possible; the element extent is provided for this purpose. It contains a phrase indicating the size or approximate size of the computer file in one of the following ways: in bytes of a specified length (e.g. 4000 16-bit bytes) as falling within a range of categories, for example: less than 1 Mb between 1 Mb and 5 Mb between 6 Mb and 10 Mb over 10 Mb in terms of any convenient logical units (for example, words or sentences, citations, paragraphs) in terms of any convenient physical units (for example, blocks, disks, tapes)

The use of standard abbreviations for units of quantity is recommended where applicable, here as elsewhere (see ).

Examples: between 1 and 2 Mb 4.2 MiB 4532 bytes 3200 sentences Five 90 mm High Density Diskettes

The measure element and its attributes may be used to supply machine-tractable or normalised versions of the size or sizes given, as in the following example: About four megabytes 245 pages of source material Note that when more than one measure is supplied in a single extent, the implication is that all the measurements apply to the whole resource.

The publicationStmt element is the fourth component of the fileDesc element and is mandatory. Its function is to name the agency by which a resource is made available (for example, a publisher or distributor) and to supply any additional information about the way in which it is made available such as licensing conditions, identifying numbers, etc. It may contain either a simple prose description organized as one or more paragraphs, or the more specialised elements described below.

A structured publication statement must begin with one of the following elements: These elements form the model.publicationStmtPart.agency class; if the agency making the resource available is unknown, but other structured information about it is available, an explicit statement such as publisher unknown should be used.

The publisher is the person or institution by whose authority a given edition of the file is made public. The distributor is the person or institution from whom copies of the text may be obtained. Where a text is not considered formally published, but is nevertheless made available for circulation by some individual or organization, this person or institution is termed the release authority.

Whichever of these elements is chosen, it may be followed by one or more of the following elements, which together form the model.publicationStmtPart.detail class

Here is a simple example: Oxford University Press Oxford 1989 0-19-254705-4

Copyright 1989, Oxford University Press

The model.publicationStmtPart.detail elements all supply additional information relating to the the publisher, distributor, or release authority immediately preceding them. In the following example, Benson is identified as responsible for distribution of some resource at the date and place cited: James D. Benson London 1994

A resource may have (for example) both a publisher and a distributor, or more than one publisher each using different identifiers for the same resource, and so on. For this reason, the sequence of at least one model.publicationStmtPart.agency element followed by zero or more model.publicationStmtPart.detail elements may be repeated as often as necessary.

The following example shows a resource published by one agency (Sigma Press) at one address and date, which is also distributed by another (Oxford Text Archive), with a specified identifier and a different date: Sigma Press

The date element used within publicationStmt always refers to the date of publication, first distribution, or initial release. If the text was created at some other date, this may be recorded using the creation element within the profileDesc element. Other useful dates (such as dates of collection of data) may be given using a note in the notesStmt element.

The availability element may be used, as above, to provide a simple prose statement of any restrictions concerning the distribution of the resource. Alternatively, a more formal statement of the licensing conditions applicable may be provided using the licence element: University of Victoria Humanities Computing and Media Centre Victoria, BC 2011 Distributed under a Creative Commons Attribution-ShareAlike 3.0 Unported License Note here the use of the target attribute to point to a location from which the licence document itself may be obtained. Alternatively, the licence document may simply be contained within the licence element.

The seriesStmt element is the fifth component of the fileDesc element and is optional.

In bibliographic parlance, a series may be defined in one of the following ways: A group of separate items related to one another by the fact that each item bears, in addition to its own title proper, a collective title applying to the group as a whole. The individual items may or may not be numbered. Each of two or more volumes of essays, lectures, articles, or other items, similar in character and issued in sequence. A separately numbered sequence of volumes within a series or serial. The seriesStmt element may contain a prose description or one or more of the following more specific elements:

The idno may be used to supply any identifying number associated with the item, including both standard numbers such as an ISSN and particular issue numbers. (Arabic numerals separated by punctuation are recommended for this purpose: 6.19.33, for example, rather than VI/xix:33). Its type attribute is used to categorize the number further, taking the value ISSN for an ISSN for example.

Examples: ed. by Jan Gonda 1.2 0 345 6789

The notesStmt element is the sixth component of the fileDesc element and is optional. If used, it contains one or more note elements, each containing a single piece of descriptive information of the kind treated as general notes in traditional bibliographic descriptions.

Some information found in the notes area in conventional bibliography has been assigned specific elements in these Guidelines; in particular the following items should be tagged as indicated, rather than as general notes: the nature, scope, artistic form, or purpose of the file; also the genre or other intellectual category to which it may belong: e.g. Text types: newspaper editorials and reportage, science fiction, westerns, and detective stories. These should be formally described within the profileDesc element (section ). an abstract or summary of the content of a document which has been supplied by the encoder because no such abstract forms part of the content of the source. This should be supplied in the abstract element within the profileDesc element (section ). summary description providing a factual, non-evaluative account of the subject content of the file: e.g. Transcribes interviews on general topics with native speakers of English in 17 cities during the spring and summer of 1963. These should also be formally described within the profileDesc element (section ). bibliographic details relating to the source or sources of an electronic text: e.g. Transcribed from the Norton facsimile of the 1623 Folio. These should be formally described in the sourceDesc element (section ). further information relating to publication, distribution, or release of the text, including sources from which the text may be obtained, any restrictions on its use or formal terms on its availability. These should be placed in the appropriate division of the publicationStmt element (section ). publicly documented numbers associated with the file: e.g. ICPSR study number 1803 or Oxford Text Archive text number 1243. These should be placed in an idno element within the appropriate division of the publicationStmt element. International Standard Serial Numbers (ISSN), International Standard Book Numbers (ISBN), and other internationally agreed upon standard numbers that uniquely identify an item, should be treated in the same way, rather than as specialized bibliographic notes.

Nevertheless, the notesStmt element may be used to record potentially significant details about the file and its features, e.g.: dates, when they are relevant to the content or condition of the computer file: e.g. manual dated 1983, Interview wave I: Apr. 1989; wave II: Jan. 1990 names of persons or bodies connected with the technical production, administration, or consulting functions of the effort which produced the file, if these are not named in statements of responsibility in the title or edition statements of the file description: e.g. Historical commentary provided by Mark Cohen availability of the file in an additional medium or information not already recorded about the availability of documentation: e.g. User manual is loose-leaf in eleven paginated sections language of work and abstract, if not encoded in the langUsage element, e.g. Text in English with summaries in French and German The unique name assigned to a serial by the International Serials Data System (ISDS), if not encoded in an idno lists of related publications, either describing the source itself, or concerned with the creation or use of the electronic work, e.g. Texts used in

Each such item of information may be tagged using the general-purpose note element, which is described in section . Groups of notes are contained within the notesStmt element, as in the following example: Historical commentary provided by Mark Cohen. OCR scanning done at University of Toronto. There are advantages, however, to encoding such information with more precise elements elsewhere in the TEI header, when such elements are available. For example, the notes above might be encoded as follows: Mark Cohen historical commentary University of Toronto OCR scanning

The sourceDesc element is the seventh and final component of the fileDesc element. It is a mandatory element and is used to record details of the source or sources from which a computer file is derived. This might be a printed text or manuscript, another computer file, an audio or video recording of some kind, or a combination of these. An electronic file may also have no source, if what is being catalogued is an original text created in electronic form.

The sourceDesc element may contain little more than a simple prose description, or a brief note stating that the document has no source:

Born digital.

Alternatively, it may contain elements drawn from the following three classes:

These classes make available by default a range of ways of providing bibliographic citations which specify the provenance of the text. For written or printed sources, the source may be described in the same way as any other bibliographic citation, using one of the following elements: These elements are described in more detail in section . Using them, a source might be described in very simple terms: The first folio of Shakespeare, prepared by Charlton Hinman (The Norton Facsimile, 1968) or with more elaboration: Eugène Sue Bruxelles et Leipzig C. Muquardt 1846

When the header describes a text derived from some pre-existing TEI-conformant or other digital document, it may be simpler to use the following element, which is designed specifically for documents derived from texts which were born digital: For further discussion see section .

When the module for manuscript description is included in a schema, this class also makes available the following element: This element enables the encoder to record very detailed information about one or more manuscript or analogous sources, as further discussed in .

The model.sourceDescPart class also makes available additional elements when additional modules are included. For example, when the spoken module is included, the sourceDesc element may also include the following special-purpose elements, intended for cases where an electronic text is derived from a spoken text rather than a written one: Full descriptions of these elements and their contents are given in section .

A single electronic text may be derived from multiple source documents, in whole or in part. The sourceDesc may therefore contain a listBibl element grouping together bibl, biblStruct, or msDesc elements for each of the sources concerned. It is also possible to repeat the sourceDesc element in such a case. The decls attribute described in section may be used to associate parts of the encoded text with the bibliographic element from which it derives in either case.

The source description may also include lists of names, persons, places, etc. when these are considered to form part of the source for an encoded document. When such information is recorded using the specialized elements discussed in the namesdates module (), the class model.listLike makes available the following elements to hold such information:

If a computer file (call it B) is derived not from a printed source but from another computer file (call it A) which includes a TEI header, then the source text of computer file B is another computer file, A. The five sections of A's file header will need to be incorporated into the new header for B in slightly differing ways, as listed below: fileDesc A's file description should be copied into the sourceDesc section of B's file description, enclosed within a biblFull element profileDesc A's profileDesc should be copied into B's, in principle unchanged; it may however be expanded by project-specific information relating to B. encodingDesc A's encoding practice may or (more likely) may not be the same as B's. Since the object of the encoding description is to define the relationship between the current file and its source, in principle only changes in encoding practice between A and B need be documented in B. The relationship between A and its source(s) is then only recoverable from the original header of A. In practice it may be more convenient to create a new complete encodingDesc for B based on A's. xenoData B is a new computer file, with a different source than A's source (namely, A). Thus it is unlikely that metadata from other schemes about A or its source can be copied wholesale to B, although there may be similarities. revisionDesc B is a new computer file, and should therefore have a new revision description. If, however, it is felt useful to include some information from A's revisionDesc, for example dates of major updates or versions, such information must be clearly marked as relating to A rather than to B. This concludes the discussion of the fileDesc element and its contents.

The projectDesc element may be used to describe, in prose, the purpose for which a digital resource was created, together with any other relevant information concerning the process by which it was assembled or collected. This is of particular importance for corpora or miscellaneous collections, but may be of use for any text, for example to explain why one kind of encoding practice has been followed rather than another.

For example:

Texts collected for use in the Claremont Shakespeare Clinic, June 1990.

The samplingDecl element may be used to describe, in prose, the rationale and methods used in selecting texts, or parts of text, for inclusion in the resource. It should include information about such matters as the size of individual samples the method or methods by which they were selected the underlying population being sampled the object of the sampling procedure used but is not restricted to these.

Samples of 2000 words taken from the beginning of the text.

It may also include a simple description of any parts of the source text included or excluded.

Text of stories only has been transcribed. Pull quotes, captions, and advertisements have been silently omitted. Any mathematical expressions requiring symbols not present in the ISOnum or ISOpub entity sets have been omitted, and their place marked with a GAP element.

A sampling declaration which applies to more than one text or division of a text need not be repeated in the header of each such text. Instead, the decls attribute of each text (or subdivision of the text) to which the sampling declaration applies may be used to supply a cross-reference to it, as further described in section .

The editorialDecl element is used to provide details of the editorial practices applied during the encoding of a text. It may contain a prose description only, or one or more of a set of specialized elements, members of the TEI model.editorialDeclPart class. Where an encoder wishes to record an editorial policy not specified above, this may be done by adding a new element to this class, using the mechanisms discussed in chapter .

Some of these policy elements carry attributes to support automated processing of certain well-defined editorial decisions; all of them contain a prose description of the editorial principles adopted with respect to the particular feature concerned. Examples of the kinds of questions which these descriptions are intended to answer are given in the list below. correction

Was the text corrected during or after data capture? If so, were corrections made silently or are they marked using the tags described in section ? What principles have been adopted with respect to omissions, truncations, dubious corrections, alternate readings, false starts, repetitions, etc.?

Any information about the editorial principles applied not falling under one of the above headings should be recorded in a distinct list of items. Experience shows that a full record should be kept of decisions relating to editorial principles and encoding practice, both for future users of the text and for the project which produced the text in the first instance. Some simple examples follow:

s elements mark orthographic sentences and are numbered sequentially within their parent div element

An editorial practices declaration which applies to more than one text or division of a text need not be repeated in the header of each such text. Instead, the decls attribute of each text (or subdivision of the text) to which it applies may be used to supply a cross-reference to it, as further described in section .

The tagsDecl element is used to record the following information about the tagging used within a particular text: the namespace to which elements appearing within the transcribed text belong. how often particular elements appear within the text, so that a recipient can validate the integrity of a text during interchange. any comment relating to the usage of particular elements not specified elsewhere in the header. a default rendition applicable to all instances of an element.

This information is conveyed by the following elements:

The tagsDecl element consists of an optional sequence of rendition elements, each of which must bear a unique identifier, followed by an optional sequence of one or more namespace elements, each of which contains a series of tagUsage elements, up to one for each element type from that namespace occurring within the associated text element. Note that these tagUsage elements must be nested within a namespace element, and cannot appear directly within the tagsDecl element.

The content of the rendition element, the value of its selector attribute, and the value of the style attribute are expressed using one of a small number of formally defined style definition languages. For ease of processing, it is strongly recommended to use a single such language throughout an encoding project, although the TEI system permits a mixture.

The element styleDefDecl, a sibling of the tagsDecl element, is used to supply the name of the default style definition language. The name is supplied as the value of the scheme attribute and may take any of the following values: freeInformal free text description cssCascading Stylesheet Language xslfoExtensible Stylesheet Language Formatting Objects otherA user-defined formal description language . The schemeVersion attribute may be used to supply the precise version of the style definition language used, and the content of this element, if any, may supply additional information.

When the style attribute is used, its value must always be expressed using whichever default style definition language is in force. If more than one occurrence of the styleDefDecl is provided, there will be more than one default available, and the decls attribute must be used to select which is applicable in a given context, as discussed in section .

The refsDecl element is used to document the way in which any standard referencing scheme built into the encoding works. It may contain either a series of prose paragraphs or the following specialized elements: Note that not all possible referencing schemes are equally easily supported by current software systems. A choice must be made between the convenience of the encoder and the likely efficiency of the particular software applications envisaged, in this context as in many others. For a more detailed discussion of referencing systems supported by these Guidelines, see section below.

A referencing scheme may be described in one of three ways using this element: as a prose description as a series of pairs of regular expressions and XPaths as a concatenation of sequentially organized milestones Each method is described in more detail below. Only one method can be used within a single refsDecl element.

More than one refsDecl element can be included in the header if more than one canonical reference scheme is to be used in the same document, but the current proposals do not check for mutual inconsistency.

The classDecl element is used to group together definitions or sources for any descriptive classification schemes used by other parts of the header. Each such scheme is represented by a taxonomy element, which may contain either a simple bibliographic citation, or a definition of the descriptive typology concerned; the following elements are used in defining a descriptive classification scheme: The taxonomy element has two slightly different, but related, functions. For well-recognized and documented public classification schemes, such as Dewey or other published descriptive thesauri, it contains simply a bibliographic citation indicating where a full description of a particular taxonomy may be found. Abridged Edition 12 For less easily accessible schemes, the taxonomy element contains a description of the taxonomy itself as well as an optional bibliographic citation. The description consists of a number of category elements, each defining a single category within the given typology. The category is defined by the contents of a nested catDesc element, which may contain either a phrase describing the category, or any number of elements from the model.catDescPart class. When the corpus module is included in a schema, this class provides the textDesc element whose components allow the definition of a text type in terms of a set of situational parameters (see further section ; if the corpus module is not included in a schema, this class is empty and the catDesc element may contain only plain text.

If the category is subdivided, each subdivision is represented by a nested category element, having the same structure. Categories may be nested to an arbitrary depth in order to reflect the hierarchical structure of the taxonomy. Each category element bears a unique xml:id attribute, which is used as the target for catRef elements referring to it. Brown Corpus Press Reportage Daily Sunday National Provincial Political Sports Religion Books Periodicals and tracts

Linkage between a particular text and a category within such a taxonomy is made by means of the catRef element within the textClass element, as described in section . Where the taxonomy permits of classification along more than one dimension, more than one category will be referenced by a particular catRef, as in the following example, which identifies a text with the sub-categories Daily, National, and Political within the category Press Reportage as defined above.

A single category may contain more than one catDesc child, when for example the category is described in more than one language, as in the following example: literatura piękna fiction proza prose poezja poetry dramat drama

The following element is provided to indicate (within the header of a document, or in an external location) that a particular coordinate notation, or a particular datum, has been employed in a text. The default notation is a string containing two real numbers separated by whitespace, of which the first indicates latitude and the second longitude according to the 1984 World Geodetic System (WGS84).

The schemaSpec element contains a schema specification. When this element appears inside encodingDesc, it allows embedding of a schema inside a TEI header; alternatively, this element may be used in the body of an ODD document. The use of ODD files, and their relationship to schemas, is described in detail in .

A schemaSpec element contains all the information needed to generate schemas for a particular TEI customization, and the ODD documentation elements, by reference to the TEI, are more succinct than the schemas derived from them. Therefore you may find it convenient to make a copy of the schemaSpec from your project's ODD document inside the teiHeader itself, in addition to supplying an external schema and/or ODD file; if the XML file becomes separated from its schema, the schema can be regenerated at any time using the information in the schemaSpec element. For example:

It is sometimes convenient to store information relating to the processing of an encoded resource within its header. Typical uses for such information might be: to allow an application to discover that it has previously opened or edited a file, and what version of itself was used to do that; to show (through a date) which application last edited the file to allow for diagnosis of any problems that might have been caused by that application; to allow users to discover information about an application used to edit the file to allow the application to declare an interest in elements of the file which it has edited, so that other applications or human editors may be more wary of making changes to those sections of the file.

The class model.applicationLike provides an element, application, which may be used to record such information within the appInfo element.

Each application element identifies the current state of one software application with regard to the current file. This element is a member of the att.datable class, which provides a variety of attributes for associating this state with a date and time, or a temporal range. The ident and version attributes should be used to uniquely identify the application and its major version number (for example, ImageMarkupTool 1.5). It is not intended that an application should add a new application each time it touches the file.

The following example shows how these elements might be used to document the fact that version 1.5 of an application called Image Markup Tool has an interest in two parts of a document which was last saved on June 6 2006. The parts concerned are accessible at the URLs given as target for the two ptr elements. Image Markup Tool

The elements discussed so far are available to any schema. When the schema in use includes some of the more specialized TEI modules, these make available other more module-specific components of the encoding description. These are discussed fully in the documentation for the module in question, but are also noted briefly here for convenience.

The fsdDecl element is available only when the iso-fs module is included in a schema. Its purpose is to document the feature system declaration (as defined in chapter ) underlying any analytic feature structures (as defined in chapter ) present in the text documented by this header.

The metDecl element is available only when the verse module is included in a schema. Its purpose is to document any metrical notation scheme used in the text, as further discussed in section . It consists either of a prose description or a series of metSym elements.

The variantEncoding element is available only when the textcrit module is included in a schema. Its purpose is to document the method used to encode textual variants in the text, as discussed in section .

The creation element contains phrases describing the origin of the text, e.g. the date and place of its composition. The date and place of composition are often of particular importance for studies of linguistic variation; since such information cannot be inferred with confidence from the bibliographic description of the copy text, the creation element may be used to provide a consistent location for this information: August 1992 Taos, New Mexico

The langUsage element is used within the profileDesc element to describe the languages, sublanguages, registers, dialects, etc. represented within a text. It contains one or more language elements, each of which provides information about a single language, notably the quantity of that language present in the text. Note that this element should not be used to supply information about any non-standard characters or glyphs used by this language; such information should be recorded in the charDecl element in the encoding description (see further ).

A language element may be supplied for each different language used in a document. If used, its ident attribute should specify an appropriate language identifier, as further discussed in section . This is particularly important if extended language identifiers have been used as the value of xml:lang attributes elsewhere in the document.

Here is an example of the use of this element: Québecois Canadian business English British English

The textClass element is used to classify a text in some way.

Text classification may be carried out according to one or more of the following methods: by reference to a recognized international classification such as the Dewey Decimal Classification, the Universal Decimal Classification, the Colon Classification, the Library of Congress Classification, or any other system widely used in library and documentation work by providing a set of keywords, as provided for example by British Library or Library of Congress Cataloguing in Publication data by referencing any other taxonomy of text categories recognized in the field concerned, or peculiar to the material in hand; this may include one based on recurring sets of values for the situational parameters defined in section , or the demographic elements described in section The last of these may be particularly important for dealing with existing corpora or collections, both as a means of avoiding the expense or inconvenience of reclassification and as a means of documenting the organizing principles of such materials.

The following elements are provided for this purpose:

The keywords element simply categorizes an individual text by supplying a list of keywords which may describe its topic or subject matter, its form, date, etc. In some schemes, the order of items in the list is significant, for example, from major topic to minor; in others, the list has an organized substructure of its own. No recommendations are made here as to which method is to be preferred. Wherever possible, such keywords should be taken from a recognized source, such as the British Library/Library of Congress Cataloguing in Publication data in the case of printed books, or a published thesaurus appropriate to the field.

The scheme attribute is used to indicate the source of the keywords used, in the case where such a source exists. If the keywords are taken from an externally defined authority which is available online, this attribute should point directly to it, as in the following examples: Babbage, Charles Mathematicians - Great Britain - Biography English literature -- History and criticism -- Data processing. English literature -- History and criticism -- Theory, etc. English language -- Style -- Data processing. Style, Literary -- Data processing.

If the authority file is not available online, but is generally recognized and commonly cited, a bibliographic description for it should be supplied within the taxonomy element described in section ; the scheme attribute may then reference that taxonomy element by means of its identifier in the usual way: ceremonials fairs street life Charles Welch 1895

If no authority file exists, perhaps because the keywords used were assigned directly by an author, the scheme attribute should be omitted.

Alternatively, if the keyword vocabulary itself is locally defined, the scheme attribute will point to the local definition, which will typically be held in a taxonomy element within the classDecl part of the encoding description (see section ).

The classCode element also categorizes an individual text, by supplying a numerical or other code rather than descriptive terms. Such codes constitute a recognized classification scheme, such as the Dewey Decimal Classification. On this element, the scheme attribute is required; it indicates the source of the classification scheme in the same way as for keywords: this may be a pointer of any kind, either to a TEI element, possibly in the current document, as in the keywords examples above, or to some canonical source for the scheme, as in the following example: 005.756

The catRef element categorizes an individual text by pointing to one or more category elements using the target attribute, which it inherits from the att.pointing class. The category element (which is fully described in section ) holds information about a particular classification or category within a given taxonomy. Each such category must have a unique identifier, which may be supplied as the value of the target attribute for catRef elements which are regarded as falling within the category indicated.

A text may, of course, fall into more than one category, in which case more than one identifier may be supplied as the value for the target attribute on the catRef element, as in the following example:

The scheme attribute may be supplied to specify the taxonomy to which the categories identified by the target attribute belong, if this is not adequately conveyed by the resource pointed to. For example, Here the same text has been classified as of categories b.a4 and b.d2 within the Brown classification scheme (presumed to be available from http://www.example.com/browncorpus), and as of category A45 within the SUC classification scheme documented at the URL given.

In general, it is a matter of style whether to use a single catRef with multiple identifiers in the value of target or multiple catRef elements, each with a single identifier in the value of target. However, note that maintenance of a TEI document with a large number of values within a single target can be cumbersome.

The distinction between the catRef and classCode elements is that the values used as identifying codes are exhaustively enumerated for the former, typically within the TEI header. In the latter case, however, the values use any externally-defined scheme, and therefore may be taken from a more open-ended descriptive classification system.

The main purpose of the abstract element is to supply a brief resume or abstract for an article which was originally published without such a component. An abstract or summary forming part of the document at its creation should usually appear in the front matter (front) of the document.

This paper is a draft studying various aspects of using the TEI as a reference serialization framework for LMF. Comments are welcome to bring this to a useful document for the community.

Abstracts may be provided in multiple languages, distinguished by the xml:lang attribute:

The recent archaeological emphasis on the study of settlement patterns, landscape and palaeoenvironments has shaped and re-shaped our understanding of the Viking settlement of Iceland. This paper reviews the developments in Icelandic archaeology, examining both theoretical and practical advances. Particular attention is paid to new ideas in terms of settlement patterns and resource exploitation. Finally, some of the key studies of the ecological consequences of the Norse landnám are presented.

The same element may be used to provide other summary information supplied by the encoder, perhaps grouped together into a list of discrete items: An annual HBC supply ship is set to the North West Coast for mid-September. Pelly writes to ascertain the British Government's plans for the lands associated with the Oregon Treaty; he wants to know what will happen to the HBC's establishment on the southern Vancouver Island. He adds that a former Crown grant, an 1838 exclusive trade-grant for the lands in question, has yet to expire. The minutes discuss the nature of the HBC's original entitlements and question whether or not, and in what capacity, the Oregon Treaty affects the HBC's position. The majority council further investigation, and to reply cautiously and judiciously to the HBC inquiry.A summary of a meeting with Pelly is offered in order to elucidate the HBC's intentions. Lord Grey calls for greater consideration on the issue of colonization; he asks that Stephen write the Company, asking them to detail their intentions, and to state their legal opinion for entitlement.

The calendarDesc element is used within the profileDesc element to document objects referenced by means of either the calendar attribute on date or the datingMethod attribute on any member of the att.datable class.

This element may contain one or more calendar elements:

Each such element contains one or more paragraphs of description for the calendar system concerned, and also supplies an identifying code for it as the value of its xml:id attribute.

Gregorian calendar

This identifying code may then be referenced from any element supplying a date expressed using that calendar system:

Captain's log stardate 23.9 rounded off to the nearest decimal point...

The correspDesc element is used within the profileDesc element to provide detailed correspondence-specific metadata, concerning in particular the communicative aspects (sending, receiving, forwarding etc.) associated with acts of of correspondence.

This information is complementary to the detailed descriptions of physical objects (such as letters) associated with correspondence activities, which are typically provided by the sourceDesc element.

The correspDesc element contains the elements correspAction and correspContext, describing the actions identified and the context in which the correspondence occurs respectively.

Acts of correspondence typically do not occur in isolation from each other. The correspContext element is used to group references relevant to the item of correspondence being described, typically to other items such as the item to which it is a reply, or the item which replies to it: Previous letter of Chamisso to de La Foye: 16 January 1807 Next letter of Chamisso to de La Foye: 07 May 1810

Many types of correspondence action may be distinguished. The type attribute should be used to indicate the type of action being documented, using values such as those suggested above.

The following simple example uses correspAction to describe the sending of a letter by Adelbert von Chamisso from Vertus on 29 January 1807 to Louis de La Foye at Caen. The date of reception is unknown: Adelbert von Chamisso Vertus Louis de La Foye Caen unknown Note the use of the when attribute described in to provide a normalized form of the date. The content of the date element may also be omitted, since no underlying source is being transcribed.

Several senders, recipients, etc. can be specified for a single correspAction if the action is considered to apply to them all acting as a single group. In the following example two people are considered to have received the communication. Hermann Hesse Ninon Hesse Montagnola

The subtype attribute may be used to further distinguish types of action. In the following example, an e-mail is sent to two people directly and to a third by carbon copy (cc). PN0001 PN0002 PN0003 PN0004

The same person may be associated with many actions. For example, it will often be the case that the author and sender of a message are identical, and that many individual letters will need to be associated with the same person. The sameAs attribute defined in section may be used to indicate that the same name applies to many actions. Its value will usually be the identifier of an element defining the person or name concerned, which is supplied elsewhere in the document.

It is assumed that each correspondence action applies to a single act of communication. It may however be the case that the same physical object is involved in several such acts, if for example person A sends a letter to person B, who then annotates it and sends it on to person C, or if persons A and B both use the same document to convey quite different messages. In such situations, multiple correspDesc elements should be supplied, one for each communication. In the following example, the same document contains distinct messages, sent by two different people to the same destination: correspDesc is used for each separately: John Gneisenau Neihardt Branson (Montgomery) Julius Temple House New York Enid Neihardt Branson (Montgomery) New York