Text Encoding Initiative |
|
The XML Version of the TEI Guidelines5 The TEI Header |
Up: Contents Previous: 4 Languages and Character Sets Next: 6 Elements Available in All TEI Documents
5.1 Organization of the TEI Header 5.6 Minimal and Recommended Headers 5.7 Note for Library Cataloguers Introductory Note (March 2002) 2 A Gentle Introduction to XML 3 Structure of the TEI Document Type Definition 4 Languages and Character Sets 6 Elements Available in All TEI Documents 14 Linking, Segmentation, and Alignment 17 Certainty and Responsibility 18 Transcription of Primary Sources 21 Graphs, Networks, and Trees 22 Tables, Formulae, and Graphics 29 Modifying and Customizing the TEI DTD 32 Algorithm for Recognizing Canonical References 38 Sample Tag Set Documentation 39 Formal Grammar for the TEI-Interchange-Format Subset of SGML |
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 TEI header can be a very large and complex object, 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 3.2 Core, Base, and Additional Tag Sets; the header extensions are fully described in chapter 23 Language Corpora, which should be read in conjunction with the present chapter. The next section of the present chapter briefly introduces 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 5.6 Minimal and Recommended Headers, at the end of the present chapter, discusses the recommended content of a minimal TEI header, and its relation to standard library cataloguing practices. Recommendations relevant to the use of TEI headers as free-standing documents, for interchange among libraries, data archives, and similar institutions may be found in chapter 24 The Independent Header. 5.1 Organization of the TEI Header5.1.1 The TEI Header and Its ComponentsThe <teiHeader> element should be clearly distinguished both from the prolog, which comprises either the XML declaration or the SGML declaration, and the document type declaration (see chapter 2 A Gentle Introduction to XML); and from the front matter of the text itself (for which see section 7.4 Front Matter). A composite text, such as a corpus or collection, may contain several headers, as further discussed below. In the usual 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:
As discussed above, the <teiHeader> element has four principal components:
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: <teiHeader> <fileDesc> <!-- ... --> </fileDesc> <encodingDesc> <!-- ... --> </encodingDesc> <profileDesc> <!-- ... --> </profileDesc> <revisionDesc> <!-- ... --> </revisionDesc> </teiHeader>while a minimal header takes the form: <teiHeader> <fileDesc> <!-- ... --> </fileDesc> </teiHeader> 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 23 Language Corpora, 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: <teiCorpus.2> <teiHeader type='corpus'> <!-- header for corpus-level information --> </teiHeader> <TEI.2> <teiHeader type='text'> <!-- header for text-level information --> </teiHeader> <text> <!-- ... --> </text> </TEI.2> <TEI.2> <teiHeader type='text'> <!-- ... --> </teiHeader> <text> <!-- ... --> </text> </TEI.2> <!-- etc. --> </teiCorpus.2> The tags required for the TEI header are defined in the DTD file teihdr2.dtd which first defines the <teiHeader> element: <!-- 5.1.1: The TEI Header--> <!--teihdr2.dtd Tags for TEI Header.--> <!--Text Encoding Initiative Consortium: Guidelines for Electronic Text Encoding and Interchange. Document TEI P4, 2002. Copyright (c) 2002 TEI Consortium. Permission to copy in any form is granted, provided this notice is included in all copies. These materials may not be altered; modifications to these DTDs should be performed only as specified by the Guidelines, for example in the chapter entitled 'Modifying the TEI DTD' These materials are subject to revision by the TEI Consortium. Current versions are available from the Consortium website at http://www.tei-c.org--> <!ELEMENT teiHeader %om.RR; (fileDesc, encodingDesc*, profileDesc*, revisionDesc?)> <!ATTLIST teiHeader %a.global; type CDATA "text" creator CDATA #IMPLIED status (new | update) "new" date.created %ISO-date; #IMPLIED date.updated %ISO-date; #IMPLIED TEIform CDATA 'teiHeader' > [continued in 5.1.1: ] <!-- end of 5.1.1--> Then it defines the rest of the header elements, embedding the DTD fragments found later in this chapter: <!-- 5.1.1: --> [declarations from 5.2: The file description inserted here ] [declarations from 5.2.7: The source description inserted here ] [declarations from 5.3: The encoding description inserted here ] [declarations from 5.4: The profile description inserted here ] [declarations from 5.5: The Revision Description inserted here ] <!-- end of 5.1.1--> 5.1.2 Types of Content in the TEI HeaderThe 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:
5.2 The File DescriptionThis 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 6.10 Bibliographic Citations and References). See further section 5.7 Note for Library Cataloguers. The bibliographic description of the electronic text (not its source) is given in the mandatory <fileDesc> element:
The <fileDesc> element contains three mandatory elements and four optional elements, each of which is described in more detail in sections 5.2.1 The Title Statement to 5.2.6 The Notes Statement below. These elements are listed below in the order in which they must be given within the <fileDesc> element.
A file description containing all possible subelements has the following structure: <teiHeader> <fileDesc> <titleStmt> <!-- ... --> </titleStmt> <editionStmt> <!-- ... --> </editionStmt> <extent> <!-- ... --> </extent> <publicationStmt> <!-- ... --> </publicationStmt> <seriesStmt> <!-- ... --> </seriesStmt> <notesStmt> <!-- ... --> </notesStmt> <sourceDesc> <!-- ... --> </sourceDesc> </fileDesc> <!-- remainder of TEI Header here --> </teiHeader>Several of these elements may be omitted; a minimal file description has the following structure: <teiHeader> <fileDesc> <titleStmt> <!-- ... --> </titleStmt> <publicationStmt> <!-- ... --> </publicationStmt> <sourceDesc> <!-- ... --> </sourceDesc> </fileDesc> <!-- remainder of TEI Header here --> </teiHeader> The <fileDesc> itself has the following formal definition: <!-- 5.2: The file description--> <!ELEMENT fileDesc %om.RR; (titleStmt, editionStmt?, extent?, publicationStmt, seriesStmt?, notesStmt?, sourceDesc+ ) > <!ATTLIST fileDesc %a.global; TEIform CDATA 'fileDesc' > [declarations from 5.2.1: The title statement inserted here ] [declarations from 5.2.2: The edition statement inserted here ] [declarations from 5.2.3: The extent statement inserted here ] [declarations from 5.2.4: The publication statement inserted here ] [declarations from 5.2.5: The series statement inserted here ] [declarations from 5.2.6: The notes statement inserted here ] <!-- end of 5.2--> 5.2.1 The Title StatementThe <titleStmt> element is the first component of the <fileDesc> element, and is mandatory:
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:
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 Rules67 (AACR 2), chapter 25, or in equivalent national-level bibliographical documentation. The specialized elements <author>, <sponsor>, <funder>, and <principal>, and the more general <respStmt> 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 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 <respStmt> element should be used. This has two subcomponents: a <name> element identifying a responsible individual or organization, and a <resp> element indicating the nature of the responsibility. No specific recommendations are made at this time as to appropriate content for the <resp>: it should make clear the nature of the responsibility concerned, as in the examples below. Names given may be personal names or corporate names. Give all names in the form in which the persons or bodies wish to be publicly cited. This would usually be the fullest form of the name, including first names.68 <titleStmt> <title>Capgrave's Life of St. John Norbert: a machine-readable transcription</title> <respStmt> <resp>compiled by</resp> <name>P.J. Lucas</name> </respStmt> </titleStmt> <titleStmt> <title>Two stories by Edgar Allen Poe: electronic version</title> <author>Poe, Edgar Allen (1809-1849)</author> <respStmt> <resp>compiled by</resp> <name>James D. Benson</name> </respStmt> </titleStmt> <titleStmt> <title>Yogadarśanam (arthāt yogasūtrap¯⃛ha&hdot;): a machine readable transcription.</title> <title>The Yogasūutras of Patañjali: a machine readable transcription.</title> <funder>Wellcome Institute for the History of Medicine</funder> <principal>Dominik Wujastyk</principal> <respStmt><name>Wieslaw Mical</name> <resp>data entry and proof correction</resp> </respStmt> <respStmt><name>Jan Hajic</name> <resp>conversion to TEI-conformant markup</resp></respStmt> </titleStmt> The formal definition of the <titleStmt> element and its constituents is as follows: <!-- 5.2.1: The title statement--> <!ELEMENT titleStmt %om.RO; ((title+, (author | editor | sponsor | funder | principal | respStmt)*))> <!ATTLIST titleStmt %a.global; TEIform CDATA 'titleStmt' > <!ELEMENT sponsor %om.RO; %phrase.seq; > <!ATTLIST sponsor %a.global; TEIform CDATA 'sponsor' > <!ELEMENT funder %om.RO; %phrase.seq; > <!ATTLIST funder %a.global; TEIform CDATA 'funder' > <!ELEMENT principal %om.RO; %phrase.seq;> <!ATTLIST principal %a.global; TEIform CDATA 'principal' > <!--The TITLE, AUTHOR, NAME, RESPSTMT, and RESP elements are declared in file teicore2.dtd, not here.--> <!-- end of 5.2.1--> 5.2.2 The Edition StatementThe <editionStmt> element is the second component of the <fileDesc> element. It is optional but recommended.
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 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 5.5 The Revision Description). The <edition> element should contain phrases describing the edition or version, including the word ‘edition’, ‘version’, or equivalent, together with a number or date, or terms indicating difference from other editions such as ‘new edition’, ‘revised edition’ etc. Any dates that occur within the edition statement should be marked with the <date> element. The n attribute of the <edition> element may be used as elsewhere to supply any formal identification (such as a version number) for the edition. One or more <respStmt> elements may also be used to supply statements of responsibility for the edition in question. These may refer to individuals or corporate bodies and can indicate functions such as that of a reviser, or can name the person or body responsible for the provision of supplementary matter, of appendices, etc., in a new edition. For further detail on the <respStmt> element, see section 6.10 Bibliographic Citations and References. <editionStmt> <edition n='P2'>Second draft, substantially extended, revised, and corrected.</edition> </editionStmt> <editionStmt> <edition>Student's edition, <date>June 1987</date></edition> <respStmt> <resp>New annotations by</resp> <name>George Brown</name> </respStmt> </editionStmt>The formal definition of the <editionStmt> element is as follows: <!-- 5.2.2: The edition statement--> <!ELEMENT editionStmt %om.RO; ( (edition, respStmt*) | p+ )> <!ATTLIST editionStmt %a.global; TEIform CDATA 'editionStmt' > <!ELEMENT edition %om.RO; %phrase.seq;> <!ATTLIST edition %a.global; TEIform CDATA 'edition' > <!-- end of 5.2.2--> 5.2.3 Type and Extent of FileThe <extent> element is the third component of the <fileDesc> element. It is optional.
For printed books, information about the carrier, such as the kind of medium used and its size, are of great importance in cataloguing procedures. The print-oriented rules for bibliographic description of an item's medium and extent need some re-interpretation when applied to electronic media. An electronic file exists as a distinct entity quite independently of its carrier and remains the same intellectual object whether it is stored on a magnetic tape, a CD-ROM, a set of floppy disks, or as a file on a mainframe computer. Since, moreover, these Guidelines are specifically aimed at facilitating transparent document storage and interchange, any purely machine-dependent information should be irrelevant as far as the file header is concerned. This is particularly true of information about file-type although library-oriented rules for cataloguing often distinguish two types of computer file: ‘data’ and ‘programs’. This distinction is quite difficult to draw in some cases, for example, hypermedia or texts with built in search and retrieval software. Although it is equally system-dependent, some measure of the size of the computer file may be of use for cataloguing and other practical purposes. Because the measurement and expression of file size is fraught with difficulties, only very general recommendations are possible; the element <extent> is provided for this purpose. It contains a phrase indicating the size or approximate size of the computer file in one of the following ways:
<extent>between 1 16-bit MB and 2 16-bit MB</extent> <extent>4.2 MiB</extent> <extent>4532 bytes</extent> <extent>3200 sentences</extent> <extent>5 3.5" High Density Diskettes</extent>The <extent> element has the following formal declaration: <!-- 5.2.3: The extent statement--> <!ELEMENT extent %om.RO; %phrase.seq;> <!ATTLIST extent %a.global; TEIform CDATA 'extent' > <!-- end of 5.2.3--> 5.2.4 Publication, Distribution, etc.The <publicationStmt> element is the fourth component of the <fileDesc> element and is mandatory.
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 the above 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:
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 6.4 Names, Numbers, Dates, Abbreviations, and Addresses and chapter 20 Names and Dates. <publicationStmt> <publisher>Oxford University Press</publisher> <pubPlace>Oxford</pubPlace> <date>1989</date> <idno type='ISBN'>0-19-254705-4</idno> <availability><p>Copyright 1989, Oxford University Press </p></availability></publicationStmt> <publicationStmt> <authority>James D. Benson</authority> <pubPlace>London</pubPlace> <date>1984</date></publicationStmt> <publicationStmt> <publisher>Sigma Press</publisher> <address> <addrLine>21 High Street,</addrLine> <addrLine>Wilmslow,</addrLine> <addrLine>Cheshire M24 3DF</addrLine> </address> <date>1991</date> <distributor>Oxford Text Archive</distributor> <idno type='ota'>1256</idno> <availability> <p>Available with prior consent of depositor for purposes of academic research and teaching only.</p> </availability> </publicationStmt> The publication statement and its components are formally defined as follows: <!-- 5.2.4: The publication statement--> <!ELEMENT publicationStmt %om.RO; ( ( p, (%m.Incl;)*)+ | ( (publisher | distributor | authority | pubPlace | address | idno | availability | date ), (%m.Incl;)*)+ )> <!ATTLIST publicationStmt %a.global; TEIform CDATA 'publicationStmt' > <!ELEMENT distributor %om.RO; %phrase.seq;> <!ATTLIST distributor %a.global; TEIform CDATA 'distributor' > <!ELEMENT authority %om.RO; %phrase.seq;> <!ATTLIST authority %a.global; TEIform CDATA 'authority' > <!ELEMENT idno %om.RO; (#PCDATA)> <!ATTLIST idno %a.global; type CDATA #IMPLIED TEIform CDATA 'idno' > <!ELEMENT availability %om.RO; (p+)> <!ATTLIST availability %a.global; status ( free | unknown | restricted ) "unknown" TEIform CDATA 'availability' > <!--The PUBLISHER, PUBPLACE, and ADDRESS elements are defined in file teicore2.dtd.--> <!-- end of 5.2.4--> 5.2.5 The Series StatementThe <seriesStmt> element is the fifth component of the <fileDesc> element and is optional.
In bibliographic parlance, a series may be defined in one of the following ways:
The <seriesStmt> element may contain a prose description or one or more of the following more specific elements:
The <idno> may be used to supply any identifying number associated with the item, including both standard numbers such as an ISSN and particular issue numbers. (Arabic numerals separated by punctuation are recommended for this purpose: 6.19.33, for example, rather than VI/xix:33). Its type attribute is used to categorize the number further, taking the value ISSN for an ISSN for example. <seriesStmt> <title level="s">Machine-Readable Texts for the Study of Indian Literature</title> <respStmt> <resp>ed. by</resp> <name>Jan Gonda</name> </respStmt> <idno type="vol">1.2</idno> <idno type ='ISSN'>0 345 6789</idno> </seriesStmt>The series statement has the following formal definition: <!-- 5.2.5: The series statement--> <!ELEMENT seriesStmt %om.RO; ( (title+, (idno | respStmt)*) | p+ )> <!ATTLIST seriesStmt %a.global; TEIform CDATA 'seriesStmt' > <!-- end of 5.2.5-->Its components are all defined elsewhere. 5.2.6 The Notes StatementThe <notesStmt> element is the sixth component of the <fileDesc> element and is optional. If used, it contains one or more <note> elements, each containing a single piece of descriptive information of the kind treated as `general notes' in traditional bibliographic descriptions.
Some information found in the notes area in conventional bibliography has been assigned specific elements in these Guidelines; in particular the following items should be tagged as indicated, rather than as general notes:
Nevertheless, the <notesStmt> element may be used to record potentially significant details about the file and its features, e.g.:
Each such item of information should be tagged using the general-purpose <note> element, which is described in section 6.8 Notes, Annotation, and Indexing. Groups of notes are contained within the <notesStmt> element, as in the following example: <notesStmt> <note>Historical commentary provided by Mark Cohen.</note> <note>OCR scanning done at University of Toronto.</note> </notesStmt>The notes statement has the following formal definition: <!-- 5.2.6: The notes statement--> <!ELEMENT notesStmt %om.RO; (note+)> <!ATTLIST notesStmt %a.global; TEIform CDATA 'notesStmt' > <!--The NOTE element is defined with the core tags.--> <!-- end of 5.2.6--> 5.2.7 The Source DescriptionThe <sourceDesc> element is the seventh and final component of the <fileDesc> element. It is a mandatory element, and is used to record details of the source or sources from which a computer file is derived. This might be a printed text or manuscript, another computer file, an audio or video recording of some kind, or a combination of these. An electronic file may also have no source, if what is being catalogued is an original text created in electronic form.
The <sourceDesc> element may contain 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:
When the header describes a transcription of spoken material, the <sourceDesc> element may also include the following special-purpose elements, intended for cases where an electronic text is derived from a spoken text rather than a written one:
The <sourceDesc> element may contain a mixture of one or more of the above elements, as in the following examples: <sourceDesc> <bibl>The first folio of Shakespeare, prepared by Charlton Hinman (The Norton Facsimile, 1968)</bibl> </sourceDesc> <sourceDesc> <p>No source: created in machine-readable form.</p> </sourceDesc> <sourceDesc> <biblStruct lang='FR'> <monogr> <author>Eugène Sue</author> <title>Martin, l'enfant trouvé</title> <title type='sub'>Mémoires d'un valet de chambre</title> <imprint> <pubPlace>Bruxelles et Leipzig</pubPlace> <publisher>C. Muquardt</publisher> <date value="1846">1846</date> </imprint> </monogr></biblStruct> </sourceDesc> The source description itself has the following formal definition: <!-- 5.2.7: The source description--> <!ELEMENT sourceDesc %om.RR; (p | bibl | biblFull | biblStruct | listBibl | scriptStmt | recordingStmt )+ > <!ATTLIST sourceDesc %a.global; %a.declarable; TEIform CDATA 'sourceDesc' > [declarations from 5.2.9: Script statement and recording statement inserted here ] <!-- end of 5.2.7--> 5.2.8 Computer Files Derived from Other Computer FilesIf 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:
5.2.9 Computer Files Composed of Transcribed SpeechWhere 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:
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 23 Language Corpora, 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. The <scriptStmt> 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 decls attribute, described in section 23.3 Associating Contextual Information with a Text. <sourceDesc> <scriptStmt id='CNN12'> <bibl> <author>CNN Network News</author> <title>News headlines</title> <date value="1991-06-12">12 Jun 91</date> </bibl> </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 --> </sourceDesc> The <recordingStmt> 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 <recording> 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 decls attribute, described in section 23.3 Associating Contextual Information with a Text. The <recording> 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 <recording> element takes two additional attributes, as indicated above: type is used to specify the kind of recording concerned and dur to specify its length. In addition, descriptive information relating to the kind of recording equipment used should be specified using the <equipment> element. Where a recording is taken from a public broadcast, details of the broadcast should be given using the <broadcast> 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 23.2.3 The Setting Description and 23.2.2 The Participants Description below. <recording type='video'> <p>U-matic recording made by college audio-visual department staff, available as PAL-standard VHS transfer or sound-only casssette</p> </recording> <recording type='audio' dur="30 min"> <respStmt> <resp>Location recording by</resp> <name>Sound Services Ltd.</name> </respStmt> <equipment> <p>Multiple close microphones mixed down to stereo Digital Audio Tape, standard play, 44.1 KHz sampling frequency</p> </equipment> <date>12 Jan 1987</date> </recording> When a recording has been made from a public broadcast, details of the broadcast itself should be supplied within the <recording> element, as a nested <broadcast> element. A broadcast is closely analogous to a publication and the <broadcast> element should therefore contain one or the other of the bibliographic citation elements <bibl>, <biblStruct>, or <biblFull>. 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 <respStmt> or <editor> element with an appropriate <resp> (see further section 6.10 Bibliographic Citations and References). <recording type='audio' dur="10 min"> <equipment><p>Recorded from FM Radio to digital tape</p></equipment> <broadcast> <bibl> <title>Interview on foreign policy</title> <author>BBC Radio 5</author> <respStmt><resp>interviewer</resp><name>Robin Day</name></respStmt> <respStmt><resp>interviewee</resp><name>Margaret Thatcher</name></respStmt> <series><title>The World Tonight</title></series> <note>First broadcast on <date value="1989-11-27">27 Nov 1989</date></note> </bibl> </broadcast> </recording> When a broadcast contains several distinct recordings (for example a compilation), additional <recording> elements may be further nested within the <broadcast> element. <recording dur='100'> <broadcast> <!-- details of broadcast --> <recording> <!-- details of broadcast recording --> </recording> </broadcast> </recording> Formal definitions for the elements discussed in this section are as follows: <!-- 5.2.9: Script statement and recording statement--> <!ELEMENT scriptStmt %om.RR; (p+ | bibl | biblFull | biblStruct)> <!ATTLIST scriptStmt %a.global; %a.declarable; TEIform CDATA 'scriptStmt' > <!ELEMENT recordingStmt %om.RR; (p+ | recording+ )> <!ATTLIST recordingStmt %a.global; TEIform CDATA 'recordingStmt' > <!ELEMENT recording %om.RR; (p+ | (respStmt | equipment | broadcast | date)*)> <!ATTLIST recording %a.global; %a.declarable; type (audio | video) "audio" dur CDATA #IMPLIED TEIform CDATA 'recording' > <!ELEMENT equipment %om.RO; (p+)> <!ATTLIST equipment %a.global; %a.declarable; TEIform CDATA 'equipment' > <!ELEMENT broadcast %om.RR; (p+ | bibl | biblStruct | biblFull | recording)> <!ATTLIST broadcast %a.global; %a.declarable; TEIform CDATA 'broadcast' > <!-- end of 5.2.9--> This concludes the discussion of the <fileDesc> element and its contents. 5.3 The Encoding DescriptionThe <encodingDesc> 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.
<!-- 5.3: The encoding description--> <!ELEMENT encodingDesc %om.RR; (projectDesc*, samplingDecl*, editorialDecl*, tagsDecl?, refsDecl*, classDecl*, metDecl*, fsdDecl*, variantEncoding*, p* )> <!ATTLIST encodingDesc %a.global; TEIform CDATA 'encodingDesc' > [declarations from 5.3.1: The project description inserted here ] [declarations from 5.3.2: The sampling declaration inserted here ] [declarations from 5.3.3: The editorial practices declaration inserted here ] [declarations from 5.3.4: Tag usage and rendition declarations inserted here ] [declarations from 5.3.5.3: The reference scheme declaration inserted here ] [declarations from 5.3.6: The classification declaration inserted here ] [declarations from 5.3.7: The FSD declaration inserted here ] [declarations from 5.3.8: Metrical Notation Declaration inserted here ] [declarations from 5.3.9: Variant-Encoding Declaration inserted here ] <!-- end of 5.3--> 5.3.1 The Project DescriptionThe <projectDesc> element is the first of the nine optional subdivisions of the <encodingDesc> 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.
<encodingDesc> <projectDesc> <p>Texts collected for use in the Claremont Shakespeare Clinic, June 1990.</p> </projectDesc> </encodingDesc> This element has the following formal declaration: <!-- 5.3.1: The project description--> <!ELEMENT projectDesc %om.RO; (p+)> <!ATTLIST projectDesc %a.global; %a.declarable; TEIform CDATA 'projectDesc' > <!-- end of 5.3.1--> 5.3.2 The Sampling DeclarationThe <samplingDecl> element is the second of the nine optional subdivisions of the <encodingDesc> element. It contains a prose description of the rationale and methods used in sampling texts, for example to create a representative corpus.
but is not restricted to these. <samplingDecl> <p>Samples of 2000 words taken from the beginning of the text.</p> </samplingDecl> It may also include a simple description of any parts of the source text included or excluded. <samplingDecl> <p>Text of stories only has been transcribed. Pull quotes, captions, and advertisements have been silently omitted. Any mathematical expressions requiring symbols not present in the ISOnum or ISOpub entity sets have been omitted, and their place marked with a GAP element.</p> </samplingDecl> A sampling declaration which applies to more than one text or division of a text need not be repeated in the header of each such text. Instead, the decls attribute of each text (or subdivision of the text) to which the sampling declaration applies may be used to supply a cross reference to it, as further described in section 23.3 Associating Contextual Information with a Text. This element has the following formal declaration: <!-- 5.3.2: The sampling declaration--> <!ELEMENT samplingDecl %om.RO; (p+)> <!ATTLIST samplingDecl %a.global; %a.declarable; TEIform CDATA 'samplingDecl' > <!-- end of 5.3.2--> 5.3.3 The Editorial Practices DeclarationThe <editorialDecl> element is the third of the nine optional subdivisions of the <encodingDesc> element. It is used to provide details of the editorial practices applied during the encoding of a text.
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. A simple example follows: <editorialDecl id="e2"> <interpretation> <p>The part of speech analysis applied throughout section 4 was added by hand and has not been checked.</p> </interpretation> <correction> <p>Errors in transcription controlled by using the WordPerfect spelling checker.</p> </correction> <normalization source="W9"> <p>All words converted to Modern American spelling using Websters 9th Collegiate dictionary.</p> </normalization> <quotation marks="all" form="std"> <p>All opening quotation marks represented by entity reference ODQ; all closing quotation marks represented by entity reference CDQ.</p> </quotation> </editorialDecl> These elements are formally defined as follows: <!-- 5.3.3: The editorial practices declaration--> <!ELEMENT editorialDecl %om.RO; ( p+ | ((correction | normalization | quotation | hyphenation | interpretation | segmentation | stdVals)+, p*))> <!ATTLIST editorialDecl %a.global; %a.declarable; TEIform CDATA 'editorialDecl' > <!ELEMENT correction %om.RO; (p+)> <!ATTLIST correction %a.global; %a.declarable; status (high | medium | low | unknown) "unknown" method (silent | tags) "silent" TEIform CDATA 'correction' > <!ELEMENT normalization %om.RO; (p+)> <!ATTLIST normalization %a.global; %a.declarable; source CDATA #IMPLIED method ( silent | tags ) "silent" TEIform CDATA 'normalization' > <!ELEMENT quotation %om.RO; (p+)> <!ATTLIST quotation %a.global; %a.declarable; marks ( none | some | all ) "all" form (data | rend | std | nonstd | unknown) "unknown" TEIform CDATA 'quotation' > <!ELEMENT hyphenation %om.RO; (p+)> <!ATTLIST hyphenation %a.global; %a.declarable; eol ( all | some | none ) "some" TEIform CDATA 'hyphenation' > <!ELEMENT segmentation %om.RO; (p+)> <!ATTLIST segmentation %a.global; %a.declarable; TEIform CDATA 'segmentation' > <!ELEMENT stdVals %om.RO; (p+)> <!ATTLIST stdVals %a.global; %a.declarable; TEIform CDATA 'stdVals' > <!ELEMENT interpretation %om.RO; (p+)> <!ATTLIST interpretation %a.global; %a.declarable; TEIform CDATA 'interpretation' > <!-- end of 5.3.3-->An editorial practices declaration which applies to more than one text or division of a text need not be repeated in the header of each such text. Instead, the decls attribute of each text (or subdivision of the text) to which it applies may be used to supply a cross reference to it, as further described in section 23.3 Associating Contextual Information with a Text. 5.3.4 The Tagging DeclarationThe <tagsDecl> element is the fourth of the nine optional subdivisions of the <encodingDesc> element. It is used to record the following information about the tagging used within a particular text:
This information is conveyed by the following elements:
The <tagsDecl> element consists of an optional sequence of <rendition> elements, each of which must bear a unique identifier, followed by a sequence of <tagUsage> elements, one for each distinct element occurring within the outermost <text> element of a TEI document. The <rendition> element defined in this version of the TEI Guidelines is a preliminary proposal only, intended to provide a hook for more detailed specifications of default rendition in later versions. The present proposal allows the encoder to enter an informal description of a rendition, or style, as running prose only. This rendition will be assumed to apply, by default, to all occurrences of an element which names its identifier as the value of the render attribute of the appropriate <tagUsage> element. For element occurrences to which this default rendition does not apply, the encoder should specify an explicit description using the global rend attribute on the elements concerned. For example, the following schematic shows how an encoder might specify that <p> elements are by default to be rendered using one set of specifications identified as style1, while <hi> elements are to use a different set, identified as style2: <tagsDecl> <rendition id="style1"> ... description of one default rendition here ... </rendition> <rendition id="style2"> ... description of another default rendition here ... </rendition> <tagUsage gi="p" render="style1"> ... </tagUsage> <tagUsage gi="hi" render="style2"> ... </tagUsage> <!-- ... --> </tagsDecl> No detailed proposals for the content of the <rendition> element have as yet been formulated. Earlier versions of these Guidelines suggested that specifications derived from, or compatible with, the properties standardized as part of the Document Style and Semantics Specification Language (ISO/IEC 10179) might be useful; the Cascading Stylesheet Language (http://www.w3.org/TR/REC-CSS1) is another possible candidate vehicle for their expression, as is the XML vocabulary for specifying formatting semantics which forms a part of the W3C's Extensible Stylesheet Language (http://www.w3.org/TR/xsl). A <tagsDecl> need not specify any <rendition> element. It must however contain exactly one occurrence of a <tagUsage> element for each distinct element marked within the outermost <text> element associated with the <teiHeader> in which it appears.69 The <tagUsage> element is used to supply a count of the number of occurrences of this element within the text, which is given as the value of its occurs attribute. It may also be used to hold any additional usage information, which is supplied as running prose within the element itself. <tagUsage gi="hi" occurs="28"> Used only to mark English words italicised in the copy text. </tagUsage>This indicates that the <hi> element appears a total of 28 times in the <text> element in question, and that the encoder has used it to mark italicised English phrases only. The ident attribute may optionally be used to specify how many of the occurrences of the element in question bear a value for the global id attribute, as in the following example: <tagUsage gi="pb" occurs="321" ident="321"> Marks page breaks in the York (1734) edition only </tagUsage>This indicates that the <pb> element occurs 321 times, on each of which an identifier is provided. The content of the <tagUsage> element is not susceptible of automatic processing. It should not therefore be used to hold information for which provision is already made by other components of the encoding description. A TEI conformant document is not required to contain a <tagsDecl> element, but if one is present, it must contain <tagUsage> elements for each distinct element marked in the associated text, and the counts specified by their usage attributes must correspond with the number of such elements present in the document, as identified by some conforming processor. <!-- 5.3.4: Tag usage and rendition declarations--> <!ELEMENT tagsDecl %om.RO; (rendition*, tagUsage*) > <!ATTLIST tagsDecl %a.global; TEIform CDATA 'tagsDecl' > <!ELEMENT tagUsage %om.RO; %paraContent; > <!ATTLIST tagUsage %a.global; gi CDATA #REQUIRED occurs CDATA #IMPLIED ident CDATA #IMPLIED render IDREF #IMPLIED TEIform CDATA 'tagUsage' > <!ELEMENT rendition %om.RO; %paraContent; > <!ATTLIST rendition %a.global; TEIform CDATA 'rendition' > <!-- end of 5.3.4--> 5.3.5 The Reference System DeclarationThe <refsDecl> element is the fifth of the nine optional subdivisions of the <encodingDesc> 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:
A referencing scheme may be described in one of three ways using this element:
Each method is described in more detail below. Only one method can be used within a single <refsDecl> element. More than one <refsDecl> element can be included in the header if more than one canonical reference scheme is to be used in the same document, but the current proposals do not check for mutual inconsistency. 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 6.9 Reference Systems), a <refsDecl> element must be supplied for each; the doctype attribute should be used to specify the document type to which the declaration relates. 5.3.5.1 Prose MethodThe referencing scheme may be specified within the <refsDecl> by a simple prose description. Such a description should indicate 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. Such a prose description cannot be processed automatically, and this method of specifying the structure of a canonical reference system is therefore not recommended for automatic processing. <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 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 elements, each of which includes the through line number in Casaubon's edition as the value of its N attribute.</p> <p>The through line number and the text identifier uniquely identify any line. A canonical reference may be made up by concatenating the N values from the TEXT, DIV1, or DIV2 and calculating the line number within each part.</p> </refsDecl> 5.3.5.2 Stepwise MethodThis method defines each reference as a series of steps, each of which corresponds to a single pair of expressions in the TEI extended pointer notation (for which see section 14.2 Extended Pointers). Often, but not always, each step will also correspond to one portion of the canonical reference itself; in many common forms of canonical reference, each step will narrow the scope within which the next step can be taken. The <refsDecl> 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 <step> elements, each of which identifies the type of `reference unit' handled by the step and uses a pair of extended-pointer expressions to indicate the starting and ending pointers of the portion of the document which corresponds to a given portion of the reference string. The element may also give either a delimiter or a length for use in breaking the corresponding reference string up into units.
For example, the reference ‘Matthew 5:29’ might be constructed by stepping down the tree to find an element labelled as the ‘Matthew’ node, then within that to the ‘5’ node, and finally, within that, to the ‘29’ node. The following declarations would be required; the special values %1, %2, and %3 refer here to the strings ‘Matthew’, ‘5’, and ‘29’, respectively. <refsDecl> <step refunit="book" delim=" " from="DESCENDANT (1 DIV1 N %1)"/> <step refunit="chapter" delim=":" from="DESCENDANT (1 DIV2 N %2)"/> <step refunit="verse" from="DESCENDANT (1 DIV3 N %3)"/> </refsDecl>As this example also shows, the steps of such a reference are typically separated by fixed character sequences, called delimiters. In this example, the delimiters are a space (following ‘Matthew’) and a colon (following the chapter number). A processor for canonical references would use the delimiters specified by the delim attributes to break the reference string up into pieces; the pieces would then be used to interpret the %1, etc., in the extended pointer expressions of the from and to attributes. 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 ‘MAT05029’, assuming a fixed length of 3 for the first step, 2 for the second, and 3 for the third. <refsDecl> <step length="3" from="DESCENDANT (1 DIV1 N %1)"/> <step length="2" from="DESCENDANT (1 DIV2 N %2)"/> <step length="3" from="DESCENDANT (1 DIV3 N %3)"/> </refsDecl>The order in which the <step> elements are supplied corresponds here 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. For a description of the processing required when a canonical reference defined by <step> elements is to be recognized, and examples of its use, see chapter 32 Algorithm for Recognizing Canonical References. 5.3.5.3 Milestone MethodThis method is appropriate when only `milestone' tags (see section 6.9.3 Milestone Tags) are available to provide the required referencing information. It does not provide any abilities which cannot be mimicked by the stepwise referencing method discussed in the previous section, but in the cases where it applies, it provides a somewhat simpler notation. 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 state of a variable. A reference declaration using this method therefore specifies the individual components of the canonical reference as a sequence of <state> elements:
For example, the reference ‘Matthew 12:34’ might be thought of as representing the state of three variables: the ‘book’ variable is in state ‘Matthew’; the chapter variable is in state ‘12’, and the verse variable is in state ‘34’. If milestone tagging has been used, there should be a tag marking the point in the text at which each of the above `variables' changes its state.70 To find ‘Matthew 12:34’ 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. The delim and length 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 <mileStone> tags in the text are to be checked for state-changes. A state-change is signalled whenever a new <mileStone> tag is found with unit and, optionally, ed attributes identical to those of the <state> element in question. The value for the new state may be given explicitly by the n attribute on the <mileStone> element, or it may be implied, if the n attribute is not specified. For example, for canonical references in the form ‘xx.yyy’ where the ‘xx’ represents the page number in the first edition, and ‘yyy’ the line number within this page, a reference system declaration such as the following would be appropriate: <refsDecl> <state ed="first" unit="page" length="2" delim="."/> <state ed="first" unit="line" length="3"/> </refsDecl>This implies that milestone tags of the form <milestone n="II" ed="first" unit="page"/> <milestone ed="first" unit="line"/>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 n 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 6.9.3 Milestone Tags. The milestone referencing scheme, though conceptually simple, is not supported by a generic SGML or XML parser. Its use places a correspondingly greater burden of verification and accuracy on the encoder. The elements discussed in this section are formally defined as follows: <!-- 5.3.5.3: The reference scheme declaration--> <!ELEMENT refsDecl %om.RO; (p+ | step+ | state+)> <!ATTLIST refsDecl %a.global; doctype CDATA "TEI.2" TEIform CDATA 'refsDecl' > <!ELEMENT step %om.RO; EMPTY> <!ATTLIST step %a.global; refunit CDATA #IMPLIED length CDATA #IMPLIED delim CDATA #IMPLIED from %extPtr; #REQUIRED to %extPtr; "DITTO" TEIform CDATA 'step' > <!ELEMENT state %om.RO; EMPTY> <!ATTLIST state %a.global; ed CDATA #IMPLIED unit CDATA #REQUIRED length CDATA #IMPLIED delim CDATA #IMPLIED TEIform CDATA 'state' > <!-- end of 5.3.5.3--> 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 decls attribute of each text (or subdivision of the text) to which the declaration applies may be used to supply a cross reference to it, as further described in section 23.3 Associating Contextual Information with a Text. 5.3.6 The Classification DeclarationThe <classDecl> element is the sixth of the nine optional subdivisions of the <encodingDesc> 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 <taxonomy> element, which may contain either a simple bibliographic citation, or a definition of the descriptive typology concerned; the following elements are used in defining a descriptive classification scheme:
<taxonomy id="ddc12"> <bibl> <title>Dewey Decimal Classification</title> <edition>Abridged Edition 12</edition> <!-- etc. --> </bibl> </taxonomy>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 23.2.1 The Text Description. 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. <taxonomy id="b"> <bibl>Brown Corpus</bibl> <category id="b.a"> <catDesc>Press Reportage</catDesc> <category id="b.a1"><catDesc>Daily</catDesc></category> <category id="b.a2"><catDesc>Sunday</catDesc></category> <category id="b.a3"><catDesc>National</catDesc></category> <category id="b.a4"><catDesc>Provincial</catDesc></category> <category id="b.a5"><catDesc>Political</catDesc></category> <category id="b.a6"><catDesc>Sports</catDesc></category> <!-- ... --> </category> <category id="b.d"><catDesc>Religion</catDesc> <category id="b.d1"><catDesc>Books</catDesc></category> <category id="b.d2"><catDesc>Periodicals and tracts</catDesc></category> </category> <!-- ... --> </taxonomy> 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 5.4.3 The Text Classification. 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. <catRef target="b.a1 b.a3 b.a5"/> The elements discussed in this section are defined as follows: <!-- 5.3.6: The classification declaration--> <!ELEMENT classDecl %om.RR; (taxonomy+)> <!ATTLIST classDecl %a.global; TEIform CDATA 'classDecl' > <!ELEMENT taxonomy %om.RR; (category+ | ((bibl | biblStruct | biblFull), category*))> <!ATTLIST taxonomy %a.global; TEIform CDATA 'taxonomy' > <!ELEMENT category %om.RR; (catDesc, category*)> <!ATTLIST category %a.global; TEIform CDATA 'category' > <!ELEMENT catDesc %om.RO; (#PCDATA | %m.phrase; | textDesc )*> <!ATTLIST catDesc %a.global; TEIform CDATA 'catDesc' > <!-- end of 5.3.6--> 5.3.7 The Feature System DeclarationThe <fsdDecl> element is the seventh of the nine optional subdivisions of the <encodingDesc> element. It is used to associate a feature system declaration (as defined in chapter 26 Feature System Declaration) with any analytic feature structures (as defined in chapter 16 Feature Structures) present in the text documented by this header. It has the following description and attributes:
<!DOCTYPE TEI.2 PUBLIC "-//TEI P4//DTD Main Document Type//EN" "tei2.dtd" [ <!-- Declare the fsd notation itself --> <!NOTATION fsd PUBLIC "-//TEI//Feature System Declaration (1994)//EN"> <!-- Declare the external entity containing the FSD --> <!ENTITY myFeatures SYSTEM 'myfeat.fsd' NDATA FSD > ]> <TEI.2> <!-- ... --> </TEI.2>This declaration associate the name myFeatures with an external unparsed entity located by the SYSTEM identifier myfeat.fsd, which uses the FSD notation, itself declared above and associated with an appropriate PUBLIC identifier. 71 This entity name may then be specified within an <fsdDecl> element in the header to inform a processor of the location of the feature system declaration corresponding to a given type of feature structure used within the text, as follows: <teiHeader> <fileDesc> <!-- ... --> </fileDesc> <encodingDesc> <!-- ... --> <fsdDecl type='myA1' fsd='myFeatures'/> <fsdDecl type='myA2' fsd='myFeatures'/> <!-- ... --> </encodingDesc> <!-- ... --> </teiHeader>This header would be attached to a text in which feature structures of types myA1 and myA2 are used. Further details and examples of the use of feature structure analyses and feature system declarations are provided in chapters 16 Feature Structures and 26 Feature System Declaration respectively. The <fsdDecl> element is declared as follows: <!-- 5.3.7: The FSD declaration--> <!ELEMENT fsdDecl %om.RO; EMPTY> <!ATTLIST fsdDecl %a.global; type CDATA #REQUIRED fsd ENTITY #REQUIRED TEIform CDATA 'fsdDecl' > <!-- end of 5.3.7--> 5.3.8 The Metrical Declaration ElementThe <metDecl> element is the eighth of the nine optional subdivisions of the <encodingDesc> element. It is used to document any metrical notation scheme used in the text, as further discussed in section 9.4 Rhyme and Metrical Analysis. It consists either of a prose description or a series of <symbol> elements.
As with other components of the header, metrical notation may be specified either formally or informally. In a formal specification, every symbol used in the metrical notation must be documented by a corresponding <symbol> element; in an informal one, only a brief prose description of the way in which the notation is used need be given. In either case, the optional pattern attribute may be used to supply a regular expression which a processor can use to validate expressions in the intended notation. The following constraints apply:
As a simple example, consider the case of the notation in which metrical prominence, foot and line boundaries are all to be encoded. Legal specifications in this notation may be written for any sequence of metrically prominent or non-prominent features, optionally separated by foot or metrical line boundaries at arbitrary points. Assuming that the symbol ‘1’ is used for metrical prominence, ‘0’ for non-prominence, ‘|’ for foot boundary and ‘/’ for line boundary, then the following declaration achieves this object: <metDecl pattern="((1|0)+\|?/?)*"> <symbol value="1">metrical promimence</symbol> <symbol value="0">metrical non-prominence</symbol> <symbol value="|">foot boundary</symbol> <symbol value="/">metrical line boundary</symbol> </metDecl> The same notation might also be specified less formally, as follows: <metDecl> <p>Metrically prominent syllables are marked '1' and other syllables '0'. Foot divisions are marked by a vertical bar, and line divisions with a solidus.</p> <p>This notation may be applied to any metrical unit, of any size (including, for example, individual feet as well as groups of lines).</p> </metDecl>Note that in this case, because the pattern attribute has not been supplied, no processor can validate met attribute values within the text which use this metrical notation. For more complex cases, it will often be more convenient to define a notation incrementally. The terminal attribute should be used to indicate for a given symbol whether or not it may be re-defined in terms of other symbols used within the same notation. For example, here is a notation for encoding classical metres, in which symbols are provided for the most common types of foot. These symbols are themselves documented within the same notation, in terms of more primitive long and short syllables: <metDecl pattern="[DTIS3A]+"> <symbol n="dactyl" value="D" terminal="N">-oo</symbol> <symbol n="trochee" value="T" terminal="N">-o</symbol> <symbol n="iamb" value="I" terminal="N">o-</symbol> <symbol n="spondee" value="S" terminal="N">--</symbol> <symbol n="tribrach" value="3" terminal="N">ooo</symbol> <symbol n="anapaest" value="A" terminal="N">oo-</symbol> <symbol value="o">short syllable</symbol> <symbol value="-">long syllable</symbol> </metDecl>Note here the use of the global n attribute to supply an additional name for the symbols being documented. For further discussion of this metrical notation and its use in the encoding of verse, see section 9.4 Rhyme and Metrical Analysis. The elements discussed in this section are defined as follows: <!-- 5.3.8: Metrical Notation Declaration--> <!ELEMENT metDecl %om.RO; ((%component.seq;) | (symbol+))> <!ATTLIST metDecl %a.global; %a.declarable; type CDATA "met real" pattern CDATA #IMPLIED TEIform CDATA 'metDecl' > <!ELEMENT symbol %om.RO; %phrase.seq;> <!ATTLIST symbol %a.global; value CDATA #REQUIRED terminal ( Y | N ) "Y" TEIform CDATA 'symbol' > <!-- end of 5.3.8--> 5.3.9 The Variant-Encoding Method ElementThe <variantEncoding> element is the last of the nine optional subdivisions of the <encodingDesc> element. It is used to document the method used to encode textual variants in the text, as discussed in section 19.2 Linking the Apparatus to the Text.
Its formal declaration is as follows: <!-- 5.3.9: Variant-Encoding Declaration--> <!ELEMENT variantEncoding %om.RO; EMPTY> <!ATTLIST variantEncoding %a.global; method (location-referenced | double-end-point | parallel-segmentation) #REQUIRED location (internal | external) #REQUIRED TEIform CDATA 'variantEncoding' > <!-- end of 5.3.9--> 5.4 The Profile DescriptionThe <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.
The core <profileDesc> element has three optional components, represented by the following elements:
Three other elements may also appear within the <profileDesc> element, when the additional tag set for the TEI header is in use:
Finally, the following element can appear in the <profileDesc> element, when the additional tag set for transcription of primary sources is selected:
The profile description itself has the following formal definition: <!-- 5.4: The profile description--> <!ELEMENT profileDesc %om.RR; (creation?, langUsage*, textDesc*,particDesc*, settingDesc*, handList*, textClass*)> <!ATTLIST profileDesc %a.global; TEIform CDATA 'profileDesc' > [declarations from 5.4.1: Creation inserted here ] [declarations from 5.4.2: Language usage inserted here ] [declarations from 5.4.3: Text Classification inserted here ] <!-- end of 5.4--> 5.4.1 CreationThe <creation> element contains phrases describing the origin of the text, e.g. the date and place of its composition.
<creation> <date value="1992-08">August 1992</date> <rs type="city">Taos, New Mexico</rs> </creation> The formal declaration of <creation> is as follows: <!-- 5.4.1: Creation--> <!ELEMENT creation %om.RO; %phrase.seq;> <!ATTLIST creation %a.global; TEIform CDATA 'creation' > <!-- end of 5.4.1--> 5.4.2 Language UsageThe <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 4 Languages and Character Sets) 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.
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 examples and discussion, see 25.6 Linkage between WSD and Main Document. 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: <langUsage> <language id="fr" wsd="wsd.fr" usage="60">Québecois</language> <language id="en" wsd="wsd.en" usage="20">Canadian business English</language> <language wsd="wsd.en" usage="20">British English</language> </langUsage>or, less formally, <langUsage> <language id="fr" wsd="wsd.fr"> </language> <language id="en" wsd="wsd.en"> Approximately two-thirds of the text is in Québecois, the remainder being equally divided between Canadian business English and British English. </language> </langUsage> The <langUsage> and <language> elements have the following formal definitions: <!-- 5.4.2: Language usage--> <!ELEMENT langUsage %om.RO; (p | language)+> <!ATTLIST langUsage %a.global; %a.declarable; TEIform CDATA 'langUsage' > <!ELEMENT language %om.RO; %phrase.seq;> <!ATTLIST language %a.global; wsd ENTITY #IMPLIED usage CDATA #IMPLIED TEIform CDATA 'language' > <!-- end of 5.4.2--> 5.4.3 The Text ClassificationThe 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:
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:
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 5.3.6 The Classification Declaration. For example: <keywords scheme="lcsh"> <list> <item>Data base management</item> <item>SQL (Computer program language)</item> </list> </keywords> <keywords scheme="lcsh"> <list> <item>English literature -- History and criticism -- Data processing.</item> <item>English literature -- History and criticism -- Theory, etc.</item> <item>English language -- Style -- Data processing.</item> <item>Style, Literary -- Data processing.</item> </list> </keywords> 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: <classCode scheme="ddc19">005.756</classCode> <classCode scheme="lc">QA76.9</classCode> <classCode scheme="ddc19">820.285</classCode> <classCode scheme="lc">PR21</classCode> The <catRef> element categorizes an individual text by pointing to one or more <category> elements. The <category> element (which is fully described in section 5.3.6 The Classification Declaration) 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: <catRef target="b1 b2 b5"/> 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, <catRef target="b12 b15" scheme="brown"/> <catRef target="a45" scheme="suc"/>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: <!-- 5.4.3: Text Classification--> <!ELEMENT textClass %om.RR; ((classCode | catRef | keywords)* )> <!ATTLIST textClass %a.global; %a.declarable; TEIform CDATA 'textClass' > <!ELEMENT keywords %om.RO; (term+ | list)> <!ATTLIST keywords %a.global; scheme IDREF #IMPLIED TEIform CDATA 'keywords' > <!ELEMENT classCode %om.RR; %phrase.seq;> <!ATTLIST classCode %a.global; scheme IDREF #IMPLIED TEIform CDATA 'classCode' > <!ELEMENT catRef %om.RO; EMPTY> <!ATTLIST catRef %a.global; target IDREFS #REQUIRED scheme IDREF #IMPLIED TEIform CDATA 'catRef' > <!-- end of 5.4.3--> 5.5 The Revision DescriptionThe 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.
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 6.7 Lists or as a series of special purpose <change> elements, each of which has the following constituents:
It is recommended to give changes in reverse chronological order, most recent first. <revisionDesc> <change n="RCS:1.70"><date value="2001-04-11">Wed, 11 Apr 01</date> <respStmt><name key="zmizuho.zgk">Zoë Mizuho</name> <resp>encoder</resp></respStmt> <item>made correx entries (unfinished from <date value="1999-03-05">March 1999</date>.) all in text not tag. supravalidated.</item> </change> <change n="RCS:1.62"><date value="1999-08-24">Tue, 24 Aug 99</date> <respStmt><name key="jrussom.zxg">Jacque Russom</name> <resp>encoder</resp></respStmt> <item>Removed vuji markup from FOREIGN and BIBL contents; standardized vuji tags.</item> </change> <change n="RCS:1.47"><date value="1999-07-05">Mon, 05 Jul 99</date> <respStmt><name key="edillon.pal">Erica Dillon</name> <resp>encoder</resp></respStmt> <item>Deleted cit elements in Concluding matter, and propagated attributes from this element to the q element. However, only q elements exist in this text, where the quote element actually seems to be more appropriate. This should be looked into.</item> </change> <change n="RCS:1.45"><date value="1999-06-30">Wed, 30 Jun 99</date> <respStmt><name key="cmah.dci">Carole Mah</name> <resp>encoder</resp></respStmt> <item>Fixed n= attribute on PB; they were mis-numbered.</item> </change> <change n="RCS:1.43"><date value="1999-06-18">Fri, 18 Jun 99</date> <respStmt><name key="pcaton.xzc">Paul Caton</name> <resp>Electronic Publications Editor</resp></respStmt> <item>Within FIGURE, moved P to its correct position after FIGDESC. Validated against DTD 1.1.30b</item> </change> <change><date value="1998-07-04">04 July 1998</date> <respStmt><name key="kmessman.yec">Kevin Messman</name> <resp>Encoder</resp></respStmt> <item>Double-proofed and entered final corrections.</item> </change> <change><date value="1997-06-12">12 June 1997</date> <respStmt><name key="lmayer.ins">Lauryn S. Mayer</name> <resp>Encoder</resp></respStmt> <item>Began entering corrections with version 1.1.2a of DTD</item> </change> <change><date value="1997-03-13">13 March 1997</date> <respStmt><name key="lmayer.ins">Lauryn S. Mayer</name> <resp>Encoder</resp></respStmt> <item>Began capture using Author/Editor v. 3.1 on Mac with version 1.0.14 of DTD.</item> </change> </revisionDesc> The formal definition of the <revisionDesc> element is thus as follows: <!-- 5.5: The Revision Description--> <!ELEMENT revisionDesc %om.RR; (list | change+)> <!ATTLIST revisionDesc %a.global; TEIform CDATA 'revisionDesc' > <!ELEMENT change %om.RO; (date, respStmt+, item)> <!ATTLIST change %a.global; TEIform CDATA 'change' > <!--respStmt, item, and date are declared in teicore2.--> <!-- end of 5.5--> 5.6 Minimal and Recommended HeadersThe 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. In the remainder of this section we demonstrate first the minimal, and next a commonly recommended, level of encoding for 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: <teiHeader> <fileDesc> <titleStmt> <title>Thomas Paine: Common sense, a machine-readable transcript</title> <respStmt> <resp>compiled by</resp> <name>Jon K Adams</name> </respStmt> </titleStmt> <publicationStmt> <distributor>Oxford Text Archive</distributor> </publicationStmt> <sourceDesc> <bibl>The complete writings of Thomas Paine, collected and edited by Phillip S. Foner (New York, Citadel Press, 1945)</bibl> </sourceDesc> </fileDesc> </teiHeader> 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 <respStmt> 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. <teiHeader> <fileDesc> <titleStmt> <title>Common sense, a machine-readable transcript</title> <author>Paine, Thomas (1737-1809)</author> <respStmt> <resp>compiled by</resp> <name>Jon K Adams</name> </respStmt> </titleStmt> <editionStmt> <edition> <date>1986</date> </edition> </editionStmt> <publicationStmt> <distributor>Oxford Text Archive.</distributor> <address> <addrLine>Oxford University Computing Services,</addrLine> <addrLine>13 Banbury Road,</addrLine> <addrLine>Oxford OX2 6RB,</addrLine> <addrLine>UK</addrLine> </address> </publicationStmt> <notesStmt> <note>Brief notes on the text are in a supplementary file.</note> </notesStmt> <sourceDesc> <biblStruct> <monogr> <editor>Foner, Philip S.</editor> <title>The collected writings of Thomas Paine</title> <imprint> <pubPlace>New York</pubPlace> <publisher>Citadel Press</publisher> <date>1945</date> </imprint> </monogr> </biblStruct> </sourceDesc> </fileDesc> <encodingDesc> <samplingDecl> <p>Editorial notes in the Foner edition have not been reproduced. </p> <p>Blank lines and multiple blank spaces, including paragraph indents, have not been preserved. </p> </samplingDecl> <editorialDecl> <correction status="high" method="silent"> <p>The following errors in the Foner edition have been corrected: <list> <item>p. 13 l. 7 cotemporaries contemporaries </item> <item>p. 28 l. 26 [comma] [period] </item> <item>p. 84 l. 4 kin kind </item> <item>p. 95 l. 1 stuggle struggle </item> <item>p. 101 l. 4 certainy certainty </item> <item>p. 167 l. 6 than that </item> <item>p. 209 l. 24 publshed published </item> </list> </p> </correction> <normalization> <p>No normalization beyond that performed by Foner, if any. </p> </normalization> <quotation marks="all" form="std"> <p>All double quotation marks rendered with ", all single quotation marks with apostrophe. </p> </quotation> <hyphenation eol="none"> <p>Hyphenated words that appear at the end of the line in the Foner edition have been reformed.</p> </hyphenation> <stdVals> <p>Standard date values are given in ISO form: yyyy-mm-dd. </p> </stdVals> <interpretation> <p>Compound proper names are marked. </p> <p>Dates are marked. </p> <p>Italics are recorded without interpretation. </p> </interpretation> </editorialDecl> <classDecl> <taxonomy id="lcsh"> <bibl>Library of Congress Subject Headings</bibl> </taxonomy> <taxonomy id="lc"> <bibl>Library of Congress Classification</bibl> </taxonomy> </classDecl> </encodingDesc> <profileDesc> <creation> <date>1774</date> </creation> <langUsage> <language id="en" wsd="english" usage="100">English.</language> </langUsage> <textClass> <keywords scheme="lcsh"> <list> <item>Political science</item> <item>United States -- Politics and government — Revolution, 1775-1783</item> </list> </keywords> <classCode scheme="lc">JC 177</classCode> </textClass> </profileDesc> <revisionDesc> <change> <date>1996-01-22</date> <respStmt> <resp>ed</resp> <name>CMSMcQ</name> </respStmt> <item>finished proofreading</item> </change> <change> <date>1995-10-30</date> <respStmt> <resp>ed</resp> <name>L.B. </name> </respStmt> <item>finished proofreading</item> </change> <change> <date>1995-07-20</date> <respStmt> <resp>ed</resp> <name>R.G. </name> </respStmt> <item>finished proofreading</item> </change> <change> <date>1995-07-04</date> <respStmt> <resp>ed</resp> <name>R.G. </name> </respStmt> <item>finished data entry</item> </change> <change> <date>1995-01-15</date> <respStmt> <resp>ed</resp> <name>R.G. </name> </respStmt> <item>began data entry</item> </change> </revisionDesc> </teiHeader> 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. 5.7 Note for Library CataloguersA 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:
|
Up: Contents Previous: 4 Languages and Character Sets Next: 6 Elements Available in All TEI Documents