%sysfs; %dtdmods; ]>
TEI P2: Chapter II.2: The TEI Header Derived from TEI P1, chapter 4, with much additional material from working papers of TR6 and AI2. 19 Aug 92 MSM : published draft of chapter 22, TEI Header 13 Aug 92 MSM : and more revision 5 Aug 92 LB : more revision 21ff Jul 92 MSM : Recast as per Chicago tech review meeting, revise 21 May 92 LB : To Chicago 20 May 92 LB : Printed first complete draft; proofed; generated dtds; checked models of all elements ... 18 May 92 LB : Reorganized all files again (twice); checked all tagdocs; 16 May 92 LB : Lots more work on partics and setting; refs.decl 25 Apr 92 LB : Added new section 253 on text.class, renumbered 17 Jan 92 LB : Split into separate files; revised for new ODD 22 Dec 91 LB : First draft to TD for comment 18 Dec 91 LB : Started to incorporate new materials from TR6 & AI2 14 Dec 91 LB : Editorial changes as per TDM2; substantial rewriting 8 Dec 91 LB : Changed tagging from P1 to ODD and applied name changes from TDM2
Guidelines for Electronic Text Encoding and Interchange Chapter 22, The TEI Header Edited by C. M. Sperberg-McQueen and Lou Burnard TEI P2, chapter 22 19 August 1992 &p2.ids; Core Tags and General Rules The TEI Header

This chapter addresses the problems of describing an encoded work so that the text itself, its source, its encoding, and its revisions are all thoroughly documented. Such documentation is equally necessary for scholars using the texts, for software processing them, and for cataloguers in libraries and archives. Together these descriptions and declarations provide an electronic analogue to the title page attached to a printed work. They also constitute an equivalent for the content of the code books or introductory manuals customarily accompanying electronic data sets.

Every TEI-conformant text must carry such a set of descriptions, prefixed to it and encoded as described in this chapter. The set is known as the TEI header, tagged TeiHeader, and it has four major parts: a file description, tagged fileDesc, containing a full bibliographical description of the computer file itself, from which a user of the text could derive a proper bibliographic citation, or which a librarian or archivist could use in creating a catalogue entry recording its presence within a library or archive. The file description also includes information about the source or sources from which the electronic text was derived. The TEI elements used to encode a file description are described in section below. an encoding description, tagged encodingDesc, which describes the relationship between an electronic text and its source or sources. It allows for detailed description of whether (or how) the text was normalized during transcription, how the encoder resolved ambiguities in the source, what levels of encoding or analysis were applied, and similar matters. The TEI elements used to encode the encoding description are described in section below. a text profile, tagged profileDesc, containing classificatory and contextual information about the text, such as its subject matter, the situation in which it was produced, the individuals described by or participating in producing it, and so forth. Such a text profile is of particular use in highly structured composite texts such as corpora or language collections, where it is often highly desirable to enforce a controlled descriptive vocabulary or to perform retrievals from a body of text in terms of text type or origin. The text profile may however be of use in any form of automatic text processing. The TEI elements used to encode the profile description are described in section below. a revision history, tagged revisionDesc, which allows the encoder to provide a history of changes made during the development of the electronic text. The revision history is important for version control and for resolving questions about the history of a file. The TEI elements used to encode the revision description are described in section below.

A TEI header can be a very large and complex document, or it may be a very simple one. Some application areas (for example, the construction of language corpora and the transcription of spoken texts) will require more specialized and detailed information than others. The present proposals therefore define both a core set of elements, (all of which may be used without formality in any TEI header) and additional tagsets, which may be invoked as extensions as needed. For more details of this extension mechanism, see chapter ; the header extensions are fully described in chapter , which should be read in conjunction with the present chapter.

The next two sections of the present chapter briefly introduce the overall structure of the header, and the kinds of data it may contain. This is followed by a detailed description of all the constituent elements which may be used in the core header. Section , at the end of the present chapter, discusses the recommended content of a minimal TEI header, and its relation to standard library cataloguing practices. Organization of the TEI Header The TeiHeader and Its Components

The TeiHeader element should be clearly distinguished both from the SGML prolog, which comprises the SGML declaration and the document type declaration (see chapter ), and 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 element.

The header element has the following description: supplies the descriptive and declarative information making up an electronic title page prefixed to every TEI-conformant text. Attributes include: specifies the kind of document to which the header is attached. Sample values include: the header is attached to a single text. the header is attached to a corpus.

As discussed above, the TeiHeader element has four principal components: contains a full bibliographic description of an electronic file. documents the relationship between an electronic text and the source or sources from which it was derived. provides a detailed description of non-bibliographic aspects of a text, specifically the languages and sublanguages used, the situation in which it was produced, the participants and their setting. summarizes the revision history for a file.

Of these, only the fileDesc element is required in all TEI headers; the others are optional. The full form of a TEI header is thus: ... ... ... ... ]]> while a minimal header takes the form: ... ]]>

In the case of language corpora or collections, it may be desirable to record header information either at the level of individual components in the corpus or collection, or once for all at the level of the corpus or collection itself, or at both levels. More details concerning the tagging of composite texts are given in section , which should be read in conjunction with the current chapter. An optional type attribute may also be supplied on the TeiHeader element to indicate whether the header applies to a corpus or a single text. A corpus may thus take the form: ... ... ... ... ... ]]>

The tags required for the TEI header are defined in the DTD file teihdr2 which first defines the TeiHeader element: ]]>

Then it defines the rest of the header elements, embedding the DTD fragments found later in this chapter: ]]> Types of Content in the TEI Header

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:

Elements whose names end with the suffix Stmt (e.g. editionStmt, situationStmt) usually 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. On the relation between the TEI proposals and other standards for bibliographic description, see further section .

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.

This section describes the fileDesc element, which is the first component of the TEIHeader element.

The bibliographic description of a machine-readable text resembles in structure that of a book, an article, or any other kind of textual object. The file description element of the TEI header has therefore been closely modelled on existing standards in library cataloguing; it should thus provide enough information to allow users to give standard bibliographic references to the electronic text, and to allow cataloguers to catalogue it. Bibliographic citations occurring elsewhere in the header, and also in the text itself, are derived from the same model (on bibliographic citations in general, see further section ). See further section .

The bibliographic description of the electronic text (not its source) is given in the mandatory fileDesc element: contains a full bibliographic description of an electronic file.

The fileDesc element contains three mandatory elements and four optional elements, each of which is described in more detail in sections to below. These elements are listed below in the order in which they must be given within the fileDesc element. groups information about the title of a work and those responsible for its intellectual content. groups information relating to one edition of a text. describes the approximate size of the electronic text as stored on some carrier medium, specified in any convenient units. groups information concerning the publication or distribution of an electronic or other text. groups information about the series, if any, to which a publication belongs. collects together any notes providing information about a text additional to that recorded in other parts of the bibliographic description. supplies a bibliographic description of the copy text(s) from which an electronic text was derived or generated.

A file description containing all possible subelements has the following structure: ... ... ... ... ... ... ... ]]> Several of these elements may be omitted; a minimal file description has the following structure: ... ... ... ]]>

The fileDesc itself has the following formal definition: ]]> The Title Statement

The titleStmt element is the first component of the fileDesc element, and is mandatory: groups information about the title of a work and those responsible for its intellectual content. It contains the title given to the electronic work, together with optionally one or more statements of responsibility which identify the encoder, author, compiler, or other parties responsible for it: the title or chief name of a work, including any alternative titles or subtitles. primary statement of responsibility for a bibliographic item, for example the name of a single author, institution or organization, or of several such. specifies the name of a sponsoring organization or institution. specifies the name of an individual, institution, or organization responsible for the funding of a project or text. supplies the name of the principal researcher responsible for the creation of an electronic text. supplies information about someone other than an author, sponsor, funder or principal researcher responsible for the intellectual content of a text, edition, recording, or series. contains a phrase describing the nature of a person's intellectual responsibility. contains a proper noun.

The title element contains the chief name of the file, including any alternative title or subtitles it may have. It may be repeated, if the file 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 also be derived from the latter, but that it should be clearly distinguishable from it. For example, do not call the computer file A Sanskrit-English Dictionary, based upon the St. Petersburg Lexicons. Call it, rather, Sanskrit-English Dictionary, based upon the St. Petersburg Lexicons: a machine readable transcription. If you wish to retain some or all of the title of the source text in the title of the computer file, then introduce one of the following phrases: [title of source]: a machine readable transcription. [title of source]: electronic edition. A machine readable version of: [title of source]. This will distinguish the computer file from the source text in citations and in catalogues which contain descriptions of both types of material.

The computer file will almost certainly 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. For these reasons, these Guidelines strongly recommend that such names should not be used as the title for any computer file.

Helpful guidance on the formulation of useful descriptive titles in difficult cases may be found in the Anglo-American Cataloguing Rules (AACR 2), chapter 25, or in equivalent national-level bibliographical documentation.

Michael Gorman and Paul W. Winkler, eds., Anglo-American Cataloguing Rules, Second Edition (Chicago: American Library Association; London: Library Association; Ottawa: Canadian Library Association, 1978).

The specialized elements author, sponsor, funder, and principal, and the more general resp provide the statements of responsibility which identify the persons responsible for the intellectual or artistic content of an item and any corporate bodies from which it emanates.

Any number of statements of responsibility may occur within the title statement. At a minimum, identify the author of the text and the creator of the machine-readable file. If the bibliographic description is for a corpus, identify the creator of the corpus. These identifications are mandatory when applicable, though not enforceable by the SGML parser. 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 resp element should be used. This has two subcomponents: a name element identifying a responsible individual or organization, and a role element indicating the nature of the responsibility. No specific recommendations are made at this time as to appropriate content for the role: 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: Capgrave's Life of St. John Norbert: a machine-readable transcription compiled by P.J. Lucas ]]> Two stories by Edgar Allen Poe: electronic version Poe, Edgar Allen (1809-1849) compiled by James D. Benson ]]> Yogadarśanam (arthāt yogasūtrap¯⃛ha&hdot;): a machine readable transcription. The Yogasūutras of Patañjali: a machine readable transcription. Wellcome Institute for the History of Medicine Dominik Wujastyk Wieslaw Mical data entry and proof correction Jan Hajic conversion to TEI-conformant markup ]]>

The formal definition of the titleStmt element and its constituents is as follows: ]]> The Edition Statement

The editionStmt element is the second component of the fileDesc element. It is optional but recommended. groups information relating to one edition of a text. It contains either phrases or more specialized elements identifying the edition and those responsible for it: describes the particularities of one edition of a text. supplies information about someone other than an author, sponsor, funder or principal researcher responsible for the intellectual content of a text, edition, recording, or series. contains a proper noun. contains a phrase describing the nature of a person's intellectual responsibility.

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. The addition of new information (e.g. a linguistic analysis expressed in part-of-speech tagging, sound or graphics, referential links to external datasets) almost always does constitute a new edition.

Clearly, there are always border line 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 machine-readable file; it is mandatory for each later release, though this requirement cannot be enforced by the SGML parser.

Note that all changes in a file, 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 resp 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 resp element, see section .

Some examples follow: Second draft, substantially extended, revised, and corrected. ]]> Student's edition, June 1987 New annotations by George Brown ]]> The formal definition of the editionStmt element is as follows: ]]> Type and Extent of File

The extent element is the third component of the fileDesc element. It is optional. describes the approximate size of the electronic text as stored on some carrier medium, specified in any convenient units.

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, the TEI 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. However, since all files covered by the TEI guidelines are of the same kind, SGML representations, it is unnecessary to specify the file type separately.

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)

Examples: between 1 16-bit Mb and 2 16-bitMb 4532 bytes 3200 sentences 5 3.5" High Density Diskettes ]]> The extent element has the following formal declaration: ]]> Publication, Distribution, etc.

The publicationStmt element is the fourth component of the fileDesc element and is mandatory. groups information concerning the publication or distribution of an electronic or other text. It may contain either a simple prose description, or groups of the elements described below: provides the name of the organization responsible for the publication or distribution of a bibliographic item. supplies the name of a person or other agency responsible for the distribution of a text. supplies the name of a person or other agency responsible for making an electronic file available, other than a publisher or distributor.

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.

At least one of these three elements must be present, unless the entire publication statement is given as prose. Each may be followed by one or more of the following elements, in the following order: contains the name of, or a reference to, a place. contains a postal or other address, for example of a publisher, distributor, etc. supplies any standard or non-standard number used to identify a bibliographic item. Attributes include: categorizes the number, for example as an ISBN or other standard series. supplies information about the availability of a text, for example any restrictions on its use or distribution, its copyright status, etc. Attributes include: supplies a code identifying the current availability of the text. Sample values include: the text is freely available. the status of the text is unknown. the text is not freely available. contains a date in any format.

Note that the dates, places, etc., given in the publication statement relate to the publisher, distributor, or release authority most recently mentioned. If the text was created at some date other than its date of publication, its date of creation should be given within the profileDesc element, not in the publication statement. Give any other useful dates (e.g., dates of collection of data) in a note.

Additional detailed tagsets may be used for the encoding of names, dates and addresses, as further described in section and section .

Examples: Oxford University Press Oxford 1989 0-19-254705-4 ]]> James D. Benson London 1984 ]]> Sigma Press 1991

21 High Street, Wilmslow, Cheshire M24 3DF
Oxford Text Archive 1256

Available with prior consent of depositor for purposes of academic research and teaching only. ]]>

The publication statement and its components are formally defined as follows: ]]> The Series Statement

The seriesStmt element is the fifth component of the fileDesc element and is optional. groups information about the series, if any, to which a publication belongs.

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: a title used to identify a series of publications, each of which has its own monographic title. supplies any standard or non-standard number used to identify a bibliographic item. supplies information about someone other than an author, sponsor, funder or principal researcher responsible for the intellectual content of a text, edition, recording, or series. contains a phrase describing the nature of a person's intellectual responsibility. contains a proper noun.

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 (e.g., 6.19.33, not VI/xix:33). Its type attribute is used to categorize the number further, taking the value ISSN for an ISSN for example.

Examples: Machine-Readable Texts for the Study of Indian Literature ed. by Jan Gonda 1.2 0 345 6789 ]]> The series.statement has the following formal definition: ]]> Its components are all defined elsewhere. The Notes Statement

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. collects together any notes providing information about a text additional to that recorded in other parts of the bibliographic description. contains a note or annotation.

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 ). 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: 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). lists of related publications, either describing the source itself, or concerned with the creation or use of the machine-readable file, e.g. Texts used in Computation into Criticism (Oxford, 1987).

Each such item of information should 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. ]]> The notes statement has the following formal definition: ]]> The Source Description

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. supplies a bibliographic description of the copy text(s) from which an electronic text was derived or generated.

The sourceDesc element may contain a simple prose description, or, more usefully, a bibliographic citation of some kind specifying the provenance of the text. For written or printed sources, the source should be described in the same way as any other bibliographic citation, using one of the following elements: contains a loosely-structured bibliographic citation of which the sub-components may or may not be explicitly tagged. contains a structured bibliographic citation, in which only bibliographic subelements appear and in a specified order. contains a fully-structured bibliographic citation, in which all components of the TEI file description are present. contains a list of bibliographic citations of any kind. These elements are described in more detail in section .

When the header describes a transcription of spoken material, 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: contains a citation giving details of the script used for a spoken text. describes a set of recordings used in transcription of a spoken text. Full descriptions of these elements and their contents are given in section .

The sourceDesc element may contain a mixture of one or more of the above elements, as in the following examples: The first folio of Shakespeare, prepared by Charlton Hinman (The Norton Facsimile, 1968) ]]>

No source: created in machine-readable form.

]]> Eugène Sue Martin, l'enfant trouvé <titlePiece>Mémoires d'un valet de chambre <imprint> <city>Bruxelles et Leipzig <publisher>C. Muquardt <date>1846 </imprint> </citn.struct> </sourceDesc> ]]> </eg> <p>The source description itself has the following formal definition: <eg id=d223> <![ CDATA [ <!-- 22.2.7: The source description --> <!ELEMENT sourceDesc - - (p | citn | citn.full | citn.struct | list.citn | scriptStmt | recordingStmt)+ > <!ATTLIST sourceDesc %a.global; > <!-- This fragment is used in sec. 22.1.1 --> ]]> </eg> <div3 id='hd31'><head>Computer Files Derived from Other Computer Files <p>If a machine-readable text (call it B) is based not on a printed source but upon another machine-readable text (call it A) which includes a TEI file header, then the source text of computer file B is another computer file, A. The four sections of A's file header will need to be incorporated into the new header for B in slightly differing ways, as listed below: <list type=gloss> <label>fileDesc <item>A's file description should be copied into the <gi>sourceDesc</gi> section of B's file description, enclosed within a <gi>citnFull</gi> element (see section <xref target=p2.235>). <!-- was: target='p2.235'>). --> <!-- was: target='CObibl'>). --> <label>profileDesc<item>A's <gi>profileDesc</gi> should be copied into B's, in principle unchanged. <label>encodingDesc <item>A's coding practice may or (more likely) may not be the same as B's. Since the object of the coding 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 <gi>encodingDesc</gi> for B based on A's. <label>revisionDesc <item>B is a new electronic file, and should therefore have a new revision description. If, however, it is felt useful to include some information from A's <gi>revisionDesc</gi>, for example dates of major updates or versions, such information must be clearly marked as relating to A rather than to B. </list> <div3 id='hd32'><head>Computer Files Composed of Transcribed Speech <p>Where an electronic text is derived from a spoken text rather than a written one, it will usually be desirable to record additional information about the recording or broadcast which constitutes its source. Several additional elements are provided for this purpose within the source description element: <list type=gloss> <label><gi>scriptStmt</gi></label> <item>contains a citation giving details of the script used for a spoken text.</item> <label><gi>recordingStmt</gi></label> <item>describes a set of recordings used in transcription of a spoken text.</item> <label><gi>recording</gi></label> <item>details of an audio or video recording event used as the source of a spoken text, either directly or from a public broadcast. Attributes include: <list type=gloss> <label><att>type</att></label> <item>the kind of recording. Sample values include: <list type=gloss> <label><term>audio</term></label> <item>audio recording</item> <label><term>video</term></label> <item>audio and video recording</item> </list></item> <label><att>dur</att></label> <item>the original duration of the recording.</item> </list> </item> <label><gi>equipment</gi></label> <item>provides technical details of the equipment and media used for an audio or video recording used as the source for a spoken text.</item> <label><gi>broadcast</gi></label> <item>describes a broadcast used as the source of a spoken text.</item> </list> <p>Note that detailed information about the participants or setting of an interview or other transcript of spoken language should be recorded in the appropriate division of the profile description, discussed in chapter <xref target='AH'>, rather than as part of the source description. The source description is used to hold information only about the source from which the transcribed speech was taken, for example, any script being read and any technical details of how the recording was produced. If the source was a previously-created transcript, it should be treated in the same way as any other source text. <p>The <gi>scriptStmt</gi> element should be used where it is known that one or more of the participants in a spoken text is speaking from a previously prepared script. The script itself should be documented in the same way as any other written text, using one of the three citation tags mentioned above. Utterances or groups of utterances may be linked to the script concerned by means of the <att>decls</att> attribute, described in section <xref target=p2.3431>. <!-- was: target='p2.3431'>. --> <!-- or : target='sp31'>. --> <eg><![ CDATA[ <sourceStmt> <scriptStmt id=CNN12> <citn><author>CNN Network News <title>News headlines <date>12 Jun 1991 </citn> </scriptStmt> <!-- this script statement might be used to document the parts of a spoken transcript which included a news broadcast --> <!-- possibly other script statements or recording statements follow --> </sourceStmt> ]]> </eg> <p>The <gi>recordingStmt</gi> is used to group together information relating to the recordings from which the spoken text was transcribed. The element may contain either a prose description or, more helpfully, one or more <gi>recording</gi> elements, each corresponding with a particular recording. The linkage between utterances or groups of utterances and the relevant recording statement is made by means of the <att>decls</att> attribute, described in section <xref target=p2.3431>. <!-- was: target=p2.3431>. --> <!-- was: target=sp31>. --> <p>The <gi>recording</gi> element should be used to provide a description of how and by whom a recording was made. This information may be a prose description, within which such items as statements of responsibility, names, places and dates should be identified using the appropriate phrase level tags. The <gi>recording</gi> element takes two additional attributes, as indicated above: <att>type</att> is used to specify the kind of recording concerned and <att>dur</att> to specify its length. <p>In addition, descriptive information relating to the kind of recording equipment used should be specified using the <gi>equipment</gi> element. Where a recording is taken from a public broadcast, details of the broadcast should be given using the <gi>broadcast</gi> element described further below. Specialized collections may wish to add further sub-elements to these major components. Note however that this element should be used only for information relating to the recording process itself; information about the setting or participants (for example) is recorded elsewhere: see sections <xref target=AH2> and <xref target=AH3> below. <!-- was: xref target=hd44 and xref target=hd45 --> <eg><![ CDATA[ <recording type=video> U-matic recording made by college audio-visual department staff,available as PAL-standard VHS transfer or sound-only casssette </recording> ]]> </eg> <eg><![ CDATA[ <recording type=audio dur="30 mins"> <resp> <role>Location recording by</role> <name>Sound Services Ltd.</name> </resp> <equipment> Multiple close microphones mixed down to stereo Digital Audio Tape, standard play, 44.1 KHz sampling frequency </equipment> <date>12 Jan 1987</date> </recording> ]]> </eg> <p>When a recording has been made from a public broadcast, details of the broadcast itself should be supplied within the <gi>recording</gi> element, as a nested <gi>broadcast</gi> element. A broadcast is closely analogous to a publication and the <gi>broadcast</gi> element should therefore contain one or the other of the bibliographic citation elements <gi>citn</gi>, <gi>citn.struct</gi> or <gi>citn.full</gi>. The broadcasting agency responsible for a broadcast is regarded as its author, while other participants (for example interviewers, interviewees, directors, producers, etc.) should be specified using the <gi>resp</gi> or <gi>editor</gi> element with an appropriate <gi>role</gi> (see further section <xref target=p2.235>). <!-- was: target='p2.235'>). --> <!-- was: target=cobibl>). --> <eg><![ CDATA[ <recording type=audio duration="10 mins"> <equipment><p>Recorded from FM Radio to chrome tape.</p></> <broadcast> <citn> <title>Interview on foreign policy</> <author>BBC Radio 5</> <editor role=interviewer>Robin Day</> <editor role=interviewee>Margaret Thatcher</> <series>The World Tonight</> <date>27 Nov 1989</> </citn> </broadcast> </recording> ]]> </eg> <p>When a broadcast contains several distinct recordings (for example a compilation), additional <gi>recording</gi> elements may be further nested within the <gi>broadcast</gi> element. <eg><![ CDATA[ <recording dur=100> <broadcast> <!-- details of broadcast --> <recording> <!-- details of broadcast recording --> </recording> </broadcast> </recording> ]]> </eg> <!-- need a real example here --> <!-- damn straight. -msm --> <p>Formal definitions for the elements discussed in this section are as follows: <eg id=d2231> <![ CDATA [ <!-- 22.2.9: --> <!ELEMENT scriptStmt - - (p+ | citn | citn.full | citn.struct) > <!ATTLIST scriptStmt %a.global; > <!ELEMENT recordingStmt - - (p+ | recording+ ) > <!ATTLIST recordingStmt %a.global; > <!ELEMENT recording - - (p+ | (resp | equipment | broadcast)*) > <!ATTLIST recording %a.global; type (audio | video) audio dur CDATA #IMPLIED > <!ELEMENT equipment - o (p+) > <!ATTLIST equipment %a.global; > <!ELEMENT broadcast - - (p+ | citn | citn.struct | citn.full) > <!ATTLIST broadcast %a.global; > ]]> </eg> <p>This concludes the discussion of the <gi>fileDesc</gi> element and its contents. <!-- &p2.hd4; &p2.hd5; --> <!-- swopped these two around as per Chicago meeting --> <!-- (also needed extensive changes to text and dtd) --> <!-- but left ids unchanged for now --> <!-- Revisions: --> <!-- 92-08-19 : MSM : Change straggling refs to ANALYSIS --> <!-- 92-08-18 : MSM : revisions as per LB talk --> <!-- 92-08-18 : MSM : change -isa- -ise- to -iza- -ize- --> <!-- 92-08-17 : MSM : Change ANALYSIS to INTERP --> <!-- 92-08-14 : MSM : revisions, clarifications --> <!-- 2 Aug 92: further revisions for consistency (LB) --> <!-- 25 Jul 92 : MSM : names updated, ids updated --> <div2 id='hd5'><head>The Encoding Description</head> <p>The <gi>encodingDesc</gi> element is the second major subdivision of the TEI header. It specifies the methods and editorial principles which governed the transcription or encoding of the text in hand and may also include sets of coded definitions used by other components of the header. Though not formally required, its use is highly recommended. <list type=gloss> <label><gi>encodingDesc</gi></label> <item>documents the relationship between an electronic text and the source or sources from which it was derived.</item> </list> The content of the encoding description may be a prose description, or it may contain elements from the following list, in the order given: <list type=gloss> <label><gi>projectDesc</gi></label> <item>describes in detail the aim or purpose for which an electronic file was encoded, together with any other relevant information concerning the process by which it was assembled or collected.</item> <label><gi>samplingDecl</gi></label> <item>contains a prose description of the rationale and methods used in sampling texts in the creation of a corpus or collection.</item> <label><gi>editorialDecl</gi></label> <item>provides details of editorial principles and practices applied during the encoding of a text.</item> <label><gi>refsDecl</gi></label> <item>specifies how canonical references are constructed for this text.</item> <label><gi>classDecl</gi></label> <item>contains one or more taxonomies defining any classificatory codes used elsewhere in the text.</item> </list> Each of these elements is further described and formally defined in the appropriate section below. The encoding description itself is defined as follows: <eg id=d225> <![ CDATA [ <!-- 22.3: The encoding description --> <!ELEMENT encodingDesc - - ((p+) | (projectDesc?, samplingDecl?, editorialDecl?, refsDecl*, classDecl?)) > <!ATTLIST encodingDesc %a.global; > <!-- ... declarations from section 22.3.1 --> <!-- (The project description) --> <!-- go here ... --> <!-- ... declarations from section 22.3.2 --> <!-- (The sampling declaration) --> <!-- go here ... --> <!-- ... declarations from section 22.3.3 --> <!-- (The editorial practices declaration) --> <!-- go here ... --> <!-- ... declarations from section 22.3.4.3 --> <!-- (The reference scheme declaration) --> <!-- go here ... --> <!-- ... declarations from section 22.3.5 --> <!-- (The classification declaration) --> <!-- go here ... --> <!-- This fragment is used in sec. 22.1.1 --> ]]> </eg> <div3 id='hd51'><head>The Project Description</head> <p>The <gi>projectDesc</gi> element is the first of the five optional subdivisions of the <gi>encodingDesc</gi> element. It may be used to describe, in prose, the purpose for which the electronic file was encoded, 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. <list type=gloss> <label><gi>projectDesc</gi></label> <item>describes in detail the aim or purpose for which an electronic file was encoded, together with any other relevant information concerning the process by which it was assembled or collected.</item> </list> <p>For example: <eg> <![ CDATA[ <encodingDesc> <projectDesc><p>Texts collected for use in the Claremont Shakespeare Clinic, June 1990. </encodingDesc> ]]> </eg> <p>This element has the following formal declaration: <eg id=d2251> <![ CDATA [ <!-- 22.3.1: The project description --> <!ELEMENT projectDesc - o (p+) > <!ATTLIST projectDesc %a.global; > <!-- This fragment is used in sec. 22.3 --> ]]> </eg> <div3 id='hd52'><head>The Sampling Declaration</head> <p>The <gi>samplingDesc</gi> element is the second of the five optional subdivisions of the <gi>encodingDesc</gi> element. It contains a prose description of the rationale and methods used in sampling texts, for example to create a representative corpus. <list type=gloss> <label><gi>samplingDecl</gi></label> <item>contains a prose description of the rationale and methods used in sampling texts in the creation of a corpus or collection.</item> </list> It should include information about such matters as <list type=bullets> <item>the size of individual samples <item>the method or methods by which they were selected <item>the underlying population being sampled <item>the object of the sampling procedure used </list> but is not restricted to these. It may also include a simple description of any parts of the source text included or excluded. <!-- should attributes be used for sample size, etc? -LB --> <!-- if it would help automatic processing yes. but i --> <!-- doubt it. so no. -msm --> <eg> <![ CDATA [ <samplingDecl> <p>Samples of 2000 words taken from the beginning of the text. </samplingDecl> ]]> </eg> <p>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 <att>decls</att> 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 <xref target=p2.3431>. <!-- was: target=p2.3431>. --> <!-- was: target=SP31>. --> This element has the following formal declaration: <eg id=d2252> <![ CDATA [ <!-- 22.3.2: The sampling declaration --> <!ELEMENT samplingDecl - o (p+) > <!ATTLIST samplingDecl %a.global; > <!-- This fragment is used in sec. 22.3 --> ]]> </eg> <div3 id='hd53'><head>The Editorial Practices Declaration</head> <p>The <gi>editorialDecl</gi> element is the third of the five optional subdivisions of the <gi>encodingDesc</gi> element. It is used to provide details of the editorial practices applied during the encoding of a text. <list type=gloss> <label><gi>editorialDecl</gi></label> <item>provides details of editorial principles and practices applied during the encoding of a text.</item> </list> It may contain a prose description only, or one or more of the following specialized elements: <list type=gloss> <label><gi>correction</gi></label> <item>states how and under what circumstances corrections have been made in the text. Attributes include: <list type=gloss> <label><att>status</att></label> <item>indicates the degree of correction applied to the text. Sample values include: <list type=gloss> <label><term>high</term></label> <item>the text has been thoroughly checked and proofread.</item> <label><term>medium</term></label> <item>the text has been checked at least once.</item> <label><term>low</term></label> <item>the text has not been checked.</item> <label><term>unknown</term></label> <item>the correction status of the text is unknown.</item> </list></item> <label><att>method</att></label> <item>indicates the method adopted to indicate corrections within the text. Sample values include: <list type=gloss> <label><term>silent</term></label> <item>corrections have been made silently</item> <label><term>tags</term></label> <item>corrections have been represented using editorial tags</item> </list></item> </list> </item> <label><gi>normalization</gi></label> <item>indicates the extent of normalization or regularization of the original source carried out in converting it to electronic form. Attributes include: <list type=gloss> <label><att>source</att></label> <item>indicates the authority for any normalization carried out.</item> <label><att>method</att></label> <item>indicates the method adopted to indicate normalizations within the text. Sample values include: <list type=gloss> <label><term>silent</term></label> <item>normalization made silently</item> <label><term>tags</term></label> <item>normalization represented using editorial tags</item> </list></item> </list> </item> <label><gi>quotation</gi></label> <item>specifies editorial practice adopted with respect to quotation marks in the original. Attributes include: <list type=gloss> <label><att>marks</att></label> <item>indicates whether or not quotation marks have been retained as content within the text. Sample values include: <list type=gloss> <label><term>none</term></label> <item>no quotation marks have been retained</item> <label><term>some</term></label> <item>some quotation marks have been retained</item> <label><term>all</term></label> <item>all quotation marks have been retained</item> </list></item> <label><att>form</att></label> <item>indicates how quotation marks are indicated within the text. Sample values include: <list type=gloss> <label><term>data</term></label> <item>quotation marks are retained as data.</item> <label><term>rend</term></label> <item>the <att>rendition</att> attribute is consistently used to indicate the form of quotation marks.</item> <label><term>std</term></label> <item>use of quotation marks has been standardized.</item> <label><term>nonstd</term></label> <item>quotation marks are represented inconsistently.</item> <label><term>unknown</term></label> <item>use of quotation marks is unknown.</item> </list></item> </list> </item> <label><gi>hyphenation</gi></label> <item>summarizes the way in which hyphenation in a source text has been treated in an encoded version of it. Attributes include: <list type=gloss> <label><att>eol</att></label> <item>indicates whether or not end-of-line hyphenation has been retained in a text. Sample values include: <list type=gloss> <label><term>all</term></label> <item>all end-of-line hyphenation has been retained, even though the lineation of the original may not have been.</item> <label><term>some</term></label> <item>end-of-line hyphenation has been retained in some cases.</item> <label><term>hard</term></label> <item>all `soft' end-of-line hyphenation has been removed: any remaining hyphenation represents `hard hyphens'.</item> <label><term>none</term></label> <item>all end-of-line hyphenation has been removed: any remaining hyphenation occurred within the line.</item> </list></item> </list> </item> <label><gi>segmentation</gi></label> <item>describes the principles according to which the text has been segmented, for example into sentences, tone-units, graphemic strata, etc.</item> <label><gi>stdVals</gi></label> <item>specifies the format used when standardized date or number values are supplied.</item> <label><gi>interpretation</gi></label> <item>describes scope of any analytic or interpretive information added to the text in addition to the transcription.</item> </list> Some of these 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 listed below, in the same order as the list above. <list type=gloss> <label><gi>correction</gi> <item>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 <xref target='p2.47'>? What principles <!-- was: target='p2.47' --> <!-- was: target='COedit'--> have been adopted with respect to omissions, truncations, dubious corrections, alternate readings, false starts, repetitions, etc.? <label><gi>normalization</gi> <item>Was the text normalized, for example by regularizing any non-standard spellings, dialect forms, etc.? If so, were normalizations performed silently or are they marked using the tags described in section <xref target='p2.47'>? <!-- was: target='p2.47' --> <!-- was: target='COedit' --> What authority was used for the regularization? Also, what principles were used when normalizing dates or numbers to provide the standard values for the <att>value</att> attribute described in sections <xref target='p2.23a'> and <xref target='p2.23b'> <!-- was: target='p2.23a' and target='p2.23b' --> <!-- was: target='COnums' and target='COdate' --> and what format used for them? <label><gi>quotation</gi> <item>How were quotation marks processed? Are apostrophes and quotation marks distinguished? How? Are quotation marks retained as content in the text or replaced by markup? Was the <att>rendition</att> attribute used to record the specific appearance of any quotation marks removed from the text? Are there any special conventions regarding for example the use of single or double quotation marks when nested? Is the file consistent in its practice or has this not been checked? <label><gi>hyphenation</gi> <item>Does the encoding distinguish <q>soft</q> and <q>hard</q> hyphens? What principle has been adopted with respect to end-of-line hyphenation where source lineation has not been retained? Have soft hyphens been silently removed, and if so what is the effect on lineation and pagination? <label><gi>segmentation</gi> <item>How is the text segmented? If neutral <gi>s</gi> segmentation units have been used to divide up the text for analysis, how are they marked and how was the segmentation arrived at? <label><gi>stdVals</gi> <item>What standardization methods underly any standardized values supplied for numeric values or dates? If the <att>value</att> attribute described in section <xref target='p2.23b'> has been used, <!-- was: target='p2.23b' --> <!-- was: target='COdate' --> in what format are its values presented? <label><gi>interpretation</gi> <item>Has any analytic or interpretive information, for example part of speech tagging (see section <xref target='p2.452'>) or <!-- was: target='p2.452' --> <!-- was: target='LG' --> literary analysis (see section <xref target='p2.451'>), been included in <!-- was: target='p2.451' --> <!-- was: target='LT' --> the text? If so, how was it generated? How was it encoded? </list> <p>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. <!-- Need at least one example! But I don't have time to --> <!-- to add one. in haste, -msm --> A simple example follows: <eg> <![ CDATA [ <editorialDecl id=E2> <interpretation> <p>The part of speech analysis applied throughout section 4 was added by hand and has not been checked. <correction><p>Errors in transcription controlled by using the WordPerfect spelling checker. <normalization source=W9> <p>All words converted to Modern American spelling using Websters 9th Collegiate dictionary. <quotation marks=all form=std> <p>All opening quotation marks converted to &odq; all closing quotation marks converted to &cdq;. </editorialDecl> ]]> </eg> <!-- an unresolved problem: where do I store the full citation --> <!-- to which 'W9' is meant to be pointing at? --> <p>These elements are formally defined as follows: <eg id=d2253> <![ CDATA [ <!-- 22.3.3: The editorial practices declaration --> <!ELEMENT editorialDecl - o ( p+ | (correction | normalization | quotation | hyphenation | analysis | segmentation | std.vals)*) > <!ATTLIST editorialDecl %a.global; > <!ELEMENT correction - o (p+) > <!ATTLIST correction %a.global; status (high | medium | low | unknown) unknown method (silent | tags) silent > <!ELEMENT normalization - o (p+) > <!ATTLIST normalization %a.global; source CDATA #IMPLIED method (silent|tags) silent > <!ELEMENT quotation - o (p+) > <!ATTLIST quotation %a.global; marks (none | some | all) all form (data | rend | std | nonstd | unknown) unknown > <!ELEMENT hyphenation - o (p+) > <!ATTLIST hyphenation %a.global; eol (all|some|none) some > <!ELEMENT segmentation - o (p+) > <!ATTLIST segmentation %a.global; > <!ELEMENT stdVals - o (p+) > <!ATTLIST stdVals %a.global; > <!ELEMENT interpretation - o (p+) > <!ATTLIST interpretation %a.global; > <!-- This fragment is used in sec. 22.3 --> ]]> </eg> 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 <att>decls</att> 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 <xref target=p2.3431>. <!-- was: target=p2.3431>. --> <!-- was: target=SP31>. --> <div3 id='hd54'><head>The Reference System Declaration <p>The <gi>refsDecl</gi> element is the fourth of the five optional subdivisions of the <gi>encodingDesc</gi> element. It is used to document the way in which any standard referencing scheme built into the encoding works, either as a series of prose paragraphs or by using the following specialized elements: <list type=gloss> <label><gi>refsDecl</gi></label> <item>specifies how canonical references are constructed for this text. Attributes include: <list type=gloss> <label><att>doctype</att></label> <item>identifies the <term>document type</term> within which this reference declaration is used.</item> </list> </item> <label><gi>step</gi></label> <item>specifies one component of a canonical reference defined by the <q>stepwise</q> method.</item> <label><gi>state</gi></label> <item>specifies one component of a canonical reference defined by the <q>milestone</q> method.</item> </list> 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 <xref target=p2.232> below. <!-- was: target=COrsys> --> <!-- was: target=p2.232> --> <p>A referencing scheme may be described in one of three ways using this element: <list type=bullets> <item>as a prose description <item>as a series of hierarchically defined <term>steps</term> <item>as a concatenation of sequentially organized <term>milestones</term> </list> Each method is described in more detail below. Only one method can be used within a single <gi>refsDecl</gi> element; reference systems which depend on a combination of hierarchically defined and milestone style tags can therefore only be described by the first method. <p>More than one <gi>refsDecl</gi> 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. A reference declaration can only describe the referencing system applicable to a single document type; if therefore concurrent document types are in use (as discussed in section <xref target=p2.232>), <!-- was: target=p2.x>), --> <!-- was: target=corsys), --> a <gi>refsDecl</gi> element must be supplied for each; the <att>doctype</att> attribute should be used to specify the document type to which the declaration relates. <div4 id=hd54p><head>Prose method</head> <p>The referencing scheme specified within the <gi>refsDecl</gi> may be simply a prose description. It should contain information about which elements carry identifying information, and whether this information is represented as attribute values or as content. Any special rules about how the information is to be interpreted when reading or generating a reference string should also be specified here. As noted above, this method must be used if the referencing system used uses both the hierarchic document structure and milestone tagging; this mixed procedure is therefore not recommended for automatic processing. <eg><![ CDATA[ <refsDecl> <p>The N attribute of each text in this corpus carries a unique identifying code for the whole text. The title of the text is held as the content of the first HEAD element within each text. The N attribute on each DIV1 and DIV2 contains the canonical reference for for each such division, in the form 'XX.yyy', where XX is the book number in Roman numerals, and yyy the section number in arabic. Line breaks are marked by empty LINEBREAK tags, each of which includes the through line number in Casaubon's edition as the value of its N attribute. <p>The through line number and the text identifier uniquely identify any line. A canonical reference may be made up by concatenating the the N values from the text, div1 or div2 and calculating the line number within each part. </refsDecl> ]]> </eg> <div4 id='hd54s'><head>Stepwise method</head> <p>This method defines each reference as a series of <term>steps</term>, each of which corresponds to a step down the document tree; each step down the tree narrows the scope within which the next step can be taken. The <gi>refsDecl</gi> element must specify the steps, delimiters and lengths to be used by an application program, both when constructing references for a given location and when interpreting canonical references within a given document hierarchy. It does so by supplying one or more <gi>step</gi> elements, each of which specifies one or more target elements, a target value to be found there (either as content of the element, or as a value for a specified attribute), and optionally either a delimiter or a length for the corresponding reference string. <list type=gloss> <label><gi>step</gi></label> <item>specifies one component of a canonical reference defined by the <q>stepwise</q> method. Attributes include: <list type=gloss> <label><att>gi</att></label> <item>the name of the element for which a reference component is to be constructed.</item> <label><att>att</att></label> <item>the name of the attribute whose value gives the reference component for this step.</item> <label><att>delim</att></label> <item>supplies a delimiting string following the reference component.</item> <label><att>length</att></label> <item>specifies the fixed length of the reference component.</item> </list> </item> </list> <p>For example, the reference <q>Matthew 5:29</q> might be constructed by stepping down the tree to find an element labelled as the <q>Matthew</q> node, then within that to the <q>5</q> node, and finally, within that, to the <q>29</q> node. The following declarations would be required: <eg> <![ CDATA [ <refsDecl> <step gi=div1 att=n delim=' '> <step gi=div2 att=n delim=':'> <step gi=div3 att=n> </refsDecl> ]]> </eg> As this example also shows, the steps of such a reference are typically separated by fixed character sequences, called <term>delimiters</term>. In this example, the delimiters are a space (following <q>Matthew</q>) and a colon (following the chapter number). An alternative to the use of delimiters is to specify a fixed length for each step of the reference: for example, the same reference might be given as <q>MAT05029</q>, assuming a fixed length of 3 for the first step, 2 for the second and 3 for the third. <eg> <![ CDATA [ <refsDecl> <step gi=div1 att=n length=3> <step gi=div2 att=n length=2> <step gi=div3 att=n length=3> </refsDecl> ]]> </eg> The order in which the <gi>step</gi> elements are supplied corresponds with the order of elements within the reference, with the largest (that is, the one nearest the top of the document hierarchy) item first and the smallest last. <p>For a description of the processing required when a canonical reference defined by <gi>step</gi> elements is to be recognized, and examples of its use, see chapter <xref target=cref>. <!-- following material deleted (regretfully) as too detailed: should --> <!-- all go to section CREF --> <div4 id=hd54m><head>Milestone method</head> <p>This method is appropriate when only <q>milestone</q> tags (see section <xref target=p2.2325>) are available to provide the <!-- was: target=p2.232ms --> <!-- was: target=p2.2325 --> <!-- was: target=COrsys5 --> required referencing information. It cannot be combined with the stepwise referencing method discussed in the previous section. <p>A reference based on milestone tags concatenates the values specified by one or more such tags. Since each tag marks the point at which a value changes, it may be regarded as specifying the <term>state</term> of a variable. A reference declaration using this method therefore specifies the individual components of the canonical reference as a sequence of <gi>state</gi> elements: <list type=gloss> <label><gi>state</gi></label> <item>specifies one component of a canonical reference defined by the <q>milestone</q> method. Attributes include: <list type=gloss> <label><att>ed</att></label> <item>indicates which edition or version the milestone applies to.</item> <label><att>unit</att></label> <item>indicates what kind of section is changing at this milestone. Sample values include: <list type=gloss> <label><term>page</term></label> <item>page breaks in the reference edition.</item> <label><term>column</term></label> <item>column breaks.</item> <label><term>line</term></label> <item>line breaks.</item> <label><term>book</term></label> <item>any units termed <q>book</q>,<q>liber</q>, etc.</item> <label><term>poem</term></label> <item>individual poems in a collection.</item> <label><term>canto</term></label> <item>cantos or other major sections of a poem.</item> <label><term>stanza</term></label> <item>stanzas within a poem, book, or canto.</item> <label><term>act</term></label> <item>acts within a play.</item> <label><term>scene</term></label> <item>scenes within a play or act.</item> <label><term>section</term></label> <item>sections of any kind.</item> <label><term>absent</term></label> <item>passages not present in the reference edition.</item> </list></item> <label><att>delim</att></label> <item>supplies a delimiting string following the reference component.</item> <label><att>length</att></label> <item>specifies the fixed length of the reference component.</item> </list> </item> </list> <p>For example, the reference <q>Matthew 12:34</q> might be thought of as representing the state of three variables: the <q>book</q> variable is in state <q>Matthew</q>; the <q>chapter</q> variable is in state <q>12</q>, and the <q>verse</q> variable is in state <q>34</q>. If milestone tagging has been used, there should be a tag marking the point in the text at which each of the above <q>variables</q> changes its state.<note place=foot>On the milestone tag itself, what are here referred to as <q>variables</q> are identified by the combination of the <att>ed</att> and <att>unit</att> attributes.</note> To find <q>Matthew 12:34</q> therefore an application must scan left to right through the text, monitoring changes in the state of each of these three variables as it does so. When all three are simultaneously in the required state, the desired point will have been reached. There may of course be several such points. <p>The <att>delim</att> and <att>length</att> attributes are used to specify components of a canonical reference using this method in exactly the same way as for the stepwise method described in the preceding section. The other attributes are used to determine which instances of <gi>milestone</gi> tags in the text are to be checked for state-changes. A state-change is signalled whenever a new <gi>milestone</gi> tag is found with <att>unit</att> and, optionally, <att>ed</att> attributes identical to those of the <gi>state</gi> element in question. The value for the new state may be given explicitly by the <att>n</att> attribute on the <gi>milestone</gi> element, or it may be implied, if the <att>n</att> attribute is not specified. <p>For example, for canonical references in the form <q>xx.yyy</q> where the <q>xx</q> represents the page number in the first edition, and <q>yyy</q> the line number within this page, a reference system declaration such as the following would be appropriate: <eg><![ CDATA[ <refsDecl> <state ed='first' unit='page' delim='.' length=2> <state ed='first' unit='line' length=4> </refsDecl> ]]> </eg> This implies that milestone tags of the form <eg><![ CDATA[ <milestone ed='first' unit=page n='II'> <milestone ed='first' unit=line> ]]> </eg> will be found throughout the text, marking the positions at which page and line numbers change. Note that no value has been specified for the <att>n</att> attribute on the second milestone tag above; this implies that its value at each state change is monotonically increased. For more detail on the use of milestone tags, see section <xref target=p2.2325>. <!-- was: target=p2.232ms> --> <!-- was: target=COrsys5 > --> <!-- following algorithm should also be moved to CREF --> <p>The milestone referencing scheme, though conceptually simple, is not and cannot be supported by an SGML parser. Its use places a correspondingly greater burden of verification and accuracy on the encoder. <p>The elements discussed in this section are formally defined as follows: <eg id=d2254> <![ CDATA [ <!-- 22.3.4.3: The reference scheme declaration --> <!ELEMENT refsDecl - o (p+ | step+ | state+) > <!ATTLIST refsDecl %a.global; doctype NAME TEI.2 > <!ELEMENT step - o EMPTY > <!ATTLIST step %a.global; att NAME #IMPLIED gi NAME #IMPLIED length NUMBER #IMPLIED delim CDATA #IMPLIED > <!ELEMENT state - o EMPTY > <!ATTLIST state %a.global; ed CDATA #IMPLIED unit CDATA #REQUIRED length NUMBER #IMPLIED delim CDATA #IMPLIED > <!-- This fragment is used in sec. 22.3 --> ]]> </eg> <p>A reference system 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 <att>decls</att> 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 <xref target=p2.3431>. <!-- was: target=SP31>. --> <!-- was: target=p2.3431>. --> <!> <div3 id=hd55><head>The Classification Declaration</head> <p>The <gi>classDecl</gi> element is the last of the five optional subdivisions of the <gi>encodingDesc</gi> element. It 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 <gi>taxonomy</gi> 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: <list type=gloss> <label><gi>classDecl</gi></label> <item>contains one or more taxonomies defining any classificatory codes used elsewhere in the text.</item> <label><gi>taxonomy</gi></label> <item>defines a typology used to classify texts either implicitly, by means of a bibliographic citation, or explicitly by a structured taxonomy.</item> <label><gi>category</gi></label> <item>contains an individual descriptive category, possibly nested within a superordinate category, within a user-defined taxonomy.</item> <label><gi>catDesc</gi></label> <item>describes some category within a taxonomy or text typology, either in the form of a brief prose description or in terms of the situational parameters used by the TEI formal <gi>textDesc</gi>.</item> </list> The <gi>taxonomy</gi> 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. <eg><![ CDATA[ <taxonomy id=DDC12> <citn><title>Dewey Decimal Classification 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 a textDesc element defining it in terms of the situational parameters discussed in section . 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 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. ]]>

The elements discussed here have the following formal definitions: ]]> The Profile Description

The profileDesc element is the third major subdivision of the TEI Header. It is an optional element, the purpose of which is to enable information characterizing various descriptive aspects of a text or a corpus to be recorded within a single unified framework. provides a detailed description of non-bibliographic aspects of a text, specifically the languages and sublanguages used, the situation in which it was produced, the participants and their setting. In principle, almost any component of the header might be of importance as a means of characterizing a text. The author of a written text, its title or its date of publication, may all be regarded as characterizing it at least as strongly as any of the parameters discussed in this section. The rule of thumb applied has been to exclude from discussion here most of the information which generally forms part of a standard bibliographic style description, if only because such information has already been included elsewhere in the TEI header.

The core profileDesc element has three optional components, represented by the following elements: contains information about the creation of a text. describes the languages, sublanguages, registers, dialects etc. represented within a text. groups information which describes the nature or topic of a text in terms of a standard classification scheme, thesaurus, etc. These elements are further described in the remainder of this section.

Three other elements may also appear within the profileDesc element, when the additional tag set for the TEI header is in use: provides a description of a text in terms of its situational parameters. describes the identifiable speakers, voices or other participants in a linguistic interaction. describes the setting or settings within which a language interaction takes place, either as a prose description or as a series of setting elements. For descriptions of these elements, see chapter .

The profile description itself has the following formal definition: ]]> Creation

The creation element contains phrases describing the origin of the text, e.g. the date and place of its composition. contains information about the creation of a text. 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 formal declaration of creation is as follows: ]]> Language Usage

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 takes attributes specifying the writing system used (see section ) and the quantity of that language present in the text. Following the language elements, prose description may also be added to specify further relevant information. describes the languages, sublanguages, registers, dialects etc. represented within a text. characterizes a single language or sublanguage used within a text. Attributes include: specifies the identifier for the writing system declaration for this language (e.g. eng, fra, deu) specifies the entity containing the writing system declaration used for representing texts in this language. specifies the approximate percentage (by volume) of the text which uses this language.

Each language element links the document to the formal writing system declaration defining that language and its script; for that reason, its use is recommended. The wsd attribute must give the name of an entity containing a writing system declaration; typically, this will be an external file declared in the document type declaration. For example, ]> ... Middle High German Modern standard German ... ]]>

When two sublanguages share the same language code and writing system declaration but are distinguished in the langUsage element, only one of the language elements should bear the id attribute: Québecois Canadian business English British English ]]> or, less formally,

Approximately 60% of the text is in Québecois, the remainder being equally divided between Canadian business English and British English. ]]>

The langUsage and language elements have the following formal definitions: ]]> The Text Classification

The second component of the core profileDesc element is the textClass element. This element is used to classify a text 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 tags are provided for this purpose: contains a list of keywords or phrases identifying the topic or nature of a text. Attributes include: identifies the controlled vocabulary within which the set of keywords concerned is defined. contains the classification code used for this text in some standard classification system. Attributes include: identifies the classification system or taxonomy in use. specifies one or more defined categories within some taxonomy or text typology. Attributes include: identifies the categories concerned

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 should be used to indicate the source of the keywords used. This is done by supplying the value used for the id attribute of a taxonomy element within which further details of the source concerned may be found. The taxonomy element occurs in the classDecl part of the encoding declarations within the TEI Header and is described in section . For example: Data base management SQL (Computer program language) ]]> English literature -- History and criticism -- Data processing. English literature -- History and criticism -- Theory, etc. English language -- Style -- Data processing. Style, Literary -- Data processing. ]]>

The classCode element also categorizes an individual text, by supplying a numerical or other code used in a recognized classification scheme, such as the Dewey Decimal Classification. The scheme attribute is used to indicate the source of the classification scheme, in the same way as for the keywords element, as in the following example: 005.756 QA76.9 ]]> 820.285 PR21 ]]>

The catRef element categorizes an individual text by pointing to one or more category elements. 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 will be supplied as the value for the target attribute on the catRef element, as in the following example: ]]>

Where more than one descriptive taxonomy is used to characterize the texts in a corpus or collection, the scheme attribute should be supplied to specify the taxonomy to which the categories identified by the target attribute belong. For example, ]]> Here the same text has been classified as of categories B12 and B15 within the Brown classification scheme, and as of category A45 within the SUC classification scheme.

The distinction between the catRef and classCode elements is that the values used as identifying codes must be defined somewhere within the header for the former, but not the latter.

The elements described in this section have the following formal definitions: ]]> The Revision Description

The final subelement of the TEI header, the revisionDesc element, provides a detailed change log in which each change made to a text may be recorded. Its use is optional but highly recommended. It provides essential information for the administration of large numbers of files which are being updated, corrected, or otherwise modified as well as extremely useful documentation for files being passed from researcher to researcher or system to system. Without change logs, it is easy to confuse different versions of a file, or to remain unaware of small but important changes made in the file by some earlier link in the chain of distribution. No change should be made in any TEI-conformant file without corresponding entries being made in the change log. summarizes the revision history for a file.

The log consists of a list of entries, one for each change. This may be encoded using either the regular list element, as described in section or as a series of special purpose change elements, each of which has the following constituents: contains a proper noun. provides a description of the change made. contains a date in any format. The name element indicates who made the change, If a number is to be associated with one or more changes (for example, a revision number), use the global n attribute on the change element to supply it.

It is recommended to give changes in reverse chronological order, most recent first.

For example: 6/3/91: EMB < > changes completed. 5/25/91: EMB File format updated. 9/3/90: EMB Changes to make a prettier printed version. 5/25/90: EMB Stuart's corrections entered 2/90: N.N. Sent to Stuart Curran for proofreading. 1/22/90: N.N. Corrections made to file; 10/89: John G. Fitzgerald, Julia M. Deisler and Deborah Hirsch. Proofread. 8/89: Amy E. Frisch Input begun ]]>

The formal definition of the revisionDesc element is thus as follows: ]]> Minimal and Recommended Headers

The TEI header allows for the provision of a very large amount of information concerning the text itself, its source, encodings and revisions of it, as well as a wealth of descriptive information such as the languages it uses and the situation within which it was produced, the setting and identity of participants within it. This diversity and richness reflects the diversity of uses to which it is envisaged that electronic texts conforming to these Guidelines will be put. It is emphatically not intended that all of the elements described above should be present in every TEI Header.

The amount of encoding in a header will depend both on the nature and the intended use of the text. At one extreme, an encoder may expect that the header will be needed only to provide a bibliographic identification of the text adequate to local needs. At the other, wishing to ensure that their texts can be used for the widest range of applications, encoders will want to document as explicitly as possible both bibliographic and descriptive information, in such a way that no prior or ancillary knowledge about the text is needed in order to process it. The header in such a case will be very full, approximating to the kind of documentation often supplied in the form of a manual. Most texts will lie somewhere between these extremes; textual corpora in particular will tend more to the latter extreme.

For each element discussed above, an indication is given in the general alphabetical index (section ) as to whether its encoding is regarded in general as required, recommended or optional. Clearly, all elements relating to descriptive matters such as text classification or description must be optional in the general case, though for certain kinds of analysis their presence will be mandatory. This section therefore confines itself to demonstrating the minimal and recommended levels of encoding of the bibliographic information held by the TEI header.

Supplying only the minimal level of encoding required, the TEI header of a single printed text might look like the following example: Thomas Paine: Common sense, a machine-readable transcript compiled by Jon K Adams Oxford Text Archive The complete writings of Thomas Paine, collected and edited by Phillip S. Foner (New York, Citadel Press, 1945) ]]>

The only mandatory component of the TEI Header is the fileDesc element. Within this, titleStmt, publicationStmt and sourceDesc are all required constituents. Within the title statement, a title is required, and an author should be specified, even if it is unknown, as should some additional statement of responsibility, here given by the resp element. Within the publicationStmt, a publisher, distributor or other agency responsible for the file must be specified. Finally, the source description should contain at the least a loosely structured bibliographic citation identifying the source of the electronic text if (as is usually the case) there is one.

We now present the same example header, expanded to include additionally recommended information, adequate to most bibliographic purposes, in particular to allow for the creation of an AACR2-conformant bibliographic record. We have also added information about the encoding principles used in this (imaginary) encoding, about the text itself (in the form of Library of Congress subject headings), and about the revision of the file. Common sense, a machine-readable transcript Paine, Thomas (1737-1809) compiled by Jon K Adams 1986 Oxford Text Archive.

Oxford University Computing Services, 13 Banbury Road, Oxford OX2 6RB, UK Brief notes on the text are in a supplementary file. Foner, Philip S. The collected writings of Thomas Paine New York Citadel Press 1945

Editorial notes in the Foner edition have not been reproduced.

Blank lines and multiple blank spaces, including paragraph indents, have not been preserved.

The following errors in the Foner edition have been corrected: p. 13 l. 7 cotemporaries contemporaries p. 28 l. 26 [comma] [period] p. 84 l. 4 kin kind p. 95 l. 1 stuggle struggle p. 101 l. 4 certainy certainty p. 167 l. 6 than that p. 209 l. 24 publshed published

No normalization beyond that performed by Foner, if any.

All double quotation marks rendered with ", all single quotation marks with apostrophe.

Hyphenated words that appear at the end of the line in the Foner edition have been reformed.

Standard date values are given in ISO form: yyyy-mm-dd.

Compound proper names are marked.

Dates are marked.

Italics are recorded without interpretation. Library of Congress Subject Headings Library of Congress Classification 1774 English. Political science United States -- Politics and government -- Revolution, 1775-1783 JC 177 1996-01-22 CMSMcQfinished proofreading 1995-10-30 L.B. finished proofreading 1995-07-20 R.G. finished proofreading 1995-07-04 R.G. finished data entry 1995-01-15 R.G. began data entry ]]>

Many other examples of recommended usage for the elements discussed in this chapter are provided here, in the reference index and in the associated tutorials. Note for Library Cataloguers

A strong motivation in preparing the material in this chapter was to provide in the TEI file header, a viable chief source of information for cataloguing the machine-readable data file. The file header is not a library catalogue record, and so will not make all of the distinctions essential in standard library work. It also includes much information generally excluded from standard bibliographic descriptions. It is the intention of the developers, however, to ensure that the information required for a catalogue record be retrievable from the TEI file header, and moreover that the mapping from the one to the other be as simple and straightforward as possible. Where the correspondence is not obvious, it may prove useful to consult one of the works which were influential in developing the content of the TEI file header.

These include: Alphabetical List of Tags &hdtags;