第2章 TEIヘッダー

目次

• 2.1TEIヘッダーの構成
• 2.2ファイルの記述
• 2.3符号化に関する記述
• 2.4プロファイルの記述
• 2.5非TEIメタデータ
• 2.6改訂の記述
• 2.7最低限のヘッダーと推奨ヘッダー
• 2.8図書館の目録担当者向けの注記
• 2.9TEIヘッダーモジュール

本章では、テキスト自体やそのソース、符号化、およびその改訂が全て徹底的に文書化されているように符号化した作品を記述するという問題に対応している。このような文書化は、テキストを利用する学者や、テキストを処理するソフトウェア、図書館や文書館の目録作成者にとっても同様に必要である。これらの記述と宣言を一緒になすことによって、印刷された著作物に添付されるタイトルページの電子的アナログ版を作成することができる。また、電子データセットに付随するコードブックや入門書の内容に相当するものでもある。

すべてのTEI準拠のテキストには、この章で説明するように、このような記述のセットを先頭に付けてエンコードしなければならない。このセットはTEIヘッダーと呼ばれteiHeaderとしてタグ付けされ、5つの主な部分によって構成されている。

1. ファイルの記述はfileDescとしてタグ付けされ、コンピュータファイル自体の完全な書誌学的記述を含み、そこからテキストの利用者が適切な書誌学的引用情報を導き出すことができるもの、あるいは図書館やアーカイブ内でその存在を記録するカタログ項目を作成する際に図書館員やアーキビストが使用することができるものである。ここでいうコンピュータファイルという用語は、これが複数の異なるオペレーティングシステムファイルに格納されている場合であっても、ヘッダーによって記述された全体の実体または文書を指すものとして理解されるべきである。ファイルの記述には、電子文書がどのような単一の、または、複数のソースから派生したかについての情報も含まれる。ファイル記述を符号化するために使用されるTEI要素については、後述のセクション2.2ファイルの記述で説明する。
2. 符号化記述はencodingDescとタグ付けされ、電子テキストとその単一の、または、複数のソースとの関係を記述する。これにより、転写時にテキストが正規化されたかどうか（またはどのように）、符号化する者がソースの曖昧さをどのように解決したか、どのレベルの符号化や解析が適用されたかなどを詳細に記述することができる。符号化記述をエンコードするために使用されるTEI要素については、後述のセクション2.3符号化に関する記述で説明する。
3. テキストプロファイルはprofileDescとしてタグ付けされ、そのテキストの主題、それが作成された状況、それを作成した人物、またはそれの作成に参加した人物など、テキストに関する分類情報と文脈情報を含む。このようなテキストプロファイルは、コーパスや言語コレクションのような高度に構造化された複合テキストで特に利用され、制御された記述的語彙を強制したり、テキストの種類や出自の観点からテキストの本文から検索を実行したりすることが非常に望ましい場合がある。ただし、テキストプロファイルは、任意の形式の自動テキスト処理で使用することができる。プロファイル記述をエンコードするために使用されるTEI要素については、後述のセクション2.4プロファイルの記述で説明する。
4. コンテナ要素はxenoDataとタグ付けされ、非TEIスキーム（すなわち、TEI名前空間の要素以外の）からのメタデータを容易に含めることを可能にする。例えば、エンコードされた文書のMARCレコードは、MARCXMLやMODSを使用して含めることができる。ハーベスティングのための単純なメタデータのセットは、ダブリンコアでエンコードされたものを含む可能性もある。
5. 改訂履歴はrevisionDescとタグ付けされ、電子テキストの開発中に施された変更点の履歴を符号化する者が提供できるようにしている。改訂履歴はバージョン管理やファイルの履歴に関する疑問を解決する上で重要である。改訂記述をエンコードするために使用される TEI 要素については、後述のセクション2.6改訂の記述で説明する。

TEIヘッダーは、非常に大きく複雑なオブジェクトである場合もあれば、非常に単純なオブジェクトである場合もある。いくつかのアプリケーション領域（例えば、言語コーパスの構築や音声テキストの書き起こしなど）では、他の領域よりも専門的で詳細な情報を必要とする場合がある。したがって、本提案では、要素のコアセット（これらはすべてTEIヘッダーで形式を問わずに使用できる）と、スキーマ内に追加の専門モジュールを含む結果としてヘッダー内で利用可能になるいくつかの追加要素の両方を定義している。例えば、言語コーパスのためのモジュール（第15章言語コーパスで記述）が使用されている場合、その章で詳しく説明されているように、いくつかの追加要素が利用可能である。

本章の次のセクションでは、ヘッダーの全体的な構造とそれに含まれるデータの種類を簡単に紹介する。これに続いて、コアヘッダーで使われうるすべての構成要素の詳細な説明がある。本章の最後にあるセクション2.7最低限のヘッダーと推奨ヘッダーでは、最小のTEIヘッダーの推奨内容と、標準的な図書館の目録作成方法との関係について述べている。

teiHeader要素は、テキスト自体の前付（これについてはセクション4.5前付を参照）とは明確に区別されるべきである。コーパスやコレクションのような複合テキストは、後述するように、複数のヘッダーを含むことがある。しかし、一般的なケースでは、TEIに準拠したテキストは、単一のteiHeader要素と、それに続く 単一のtextまたはfacsimile要素、あるいはその両方を含む。

ヘッダー要素は、以下の記述を有している。

• <teiHeader> (TEIヘッダー[TEI header]) 全てのTEI準拠テキストが伴う、電子版のタイトルページを構成する、記述的・宣言的情報を示す．

上述の通り、teiHeader要素には5つの主な構成要素が含まれている。

• <fileDesc> (ファイル記述[file description]) 電子ファイルに関する完全な書誌情報を示す．
• <encodingDesc> (符号化記述[encoding description]) 電子テキストとその元資料との関係を記述する．
• <profileDesc> (テキストプロファイル記述[text-profile description]) 特に、使われた言語や特殊言語、作成されたときの状況、参加者や参加者の設定など、テキストの書誌情報的ではない諸側面の詳細な解説をする．
• <xenoData> (非TEIメタデータ[non-TEI metadata]) 非TEI形式のメタデータを配置できるコンテナ要素を提供している。
• <revisionDesc> (改訂記述[revision description]) ファイルの改訂履歴を要約する．

これらのうち、fileDesc要素のみが全てのTEIヘッダーにおいて必要となっており、残りは任意で使用する。つまり、TEIヘッダーが有している5つの構成要素のうち必須となっているのは1つだけであり（fileDesc）、後述の2.2 ファイルの記述で詳しく述べている通り、fileDescにもいくつかの必須の構成要素が含まれている。したがって、最小限の妥当なTEIヘッダーは以下の通りである。

<teiHeader>
 <fileDesc>
  <titleStmt>
   <title>
<!– title of the resource –>
   </title>
  </titleStmt>
  <publicationStmt>
   <p>
<!– Information about distribution of the resource –>
   </p>
  </publicationStmt>
  <sourceDesc>
   <p>
<!– Information about source from which the resource derives –>
   </p>
  </sourceDesc>
 </fileDesc>
</teiHeader>

bibliography 

TEIヘッダーを構成する要素の内容は、ヘッダーが適用されるテキストの言語であるとは限らず、必ずしも英語であるとは限らず、任意の言語でよい。他の場所と同様に、@xml:lang属性を適切なレベルで使用して言語を指定すべきである。例えば、以下の模式的な例では、英語のテキストにフランス語のヘッダーを与えている。

<TEI xmlns=”http://www.tei-c.org/ns/1.0″>
 <teiHeader xml:lang=”fr”>
<!– … –>
 </teiHeader>
 <text xml:lang=”en”>
<!– … –>
 </text>
</TEI>

bibliography 

言語コーパスやコレクションの場合、コーパスやコレクションの個々の構成要素のレベルで、あるいはコーパスやコレクション自体のレベルで、ヘッダー情報を記録することが望ましい可能性がある。（複合テキストのタグ付けについての詳細は、本章と併せて一読すべき第15章言語コーパスを参照すること）。そのため、コーパスは次のような形をとることができる。

<teiCorpus xmlns=”http://www.tei-c.org/ns/1.0″>
 <teiHeader>
<!– corpus-level metadata here –>
 </teiHeader>
 <TEI>
  <teiHeader>
<!– metadata specific to this text here –>
  </teiHeader>
  <text>
<!– … –>
  </text>
 </TEI>
 <TEI>
  <teiHeader>
<!– metadata specific to this text here –>
  </teiHeader>
  <text>
<!– … –>
  </text>
 </TEI>
</teiCorpus>

bibliography 

TEIヘッダー内の要素は、いくつかのタイプの内容を含んでいてもよい。以下のリストは、これらのタイプの内容がどのように記述されているのかを示している。

free prose

ほとんどの要素は、ある程度のレベルで単純な散文を含む。多くの要素は、散文（場合によっては段落に編成されている）か、それ自体が散文を含むより具体的な要素を含んでいる。この章の要素内容の説明では、散文の記述というフレーズは、それぞれがp要素としてマークされた一連の段落を含意するものとして理解されるべきである。対照的に、フレーズという単語は、必要に応じてフレーズレベルの要素が散りばめられているが、段落には編成されていない文字データを意味すると理解されるべきである。段落、ハイライトしているフレーズ、リストなどの詳細についてはセクション3.1段落を参照すること。

grouping elements

接尾辞Stmtで終わる名前の要素（例えばeditionStmt、titleStmt）やxenoData要素は何らかの構造化情報を記録した専門要素群を包含している。書誌要素の場合、接尾辞Stmtは、国際標準書誌記述の「エリア」に対応する要素の名称に使用される。¹  xenoData要素の場合は、専門要素はTEI要素ではなく、むしろその他の何らかのメタデータのスキームに由来している。ほとんどの場合、グループ化要素は、専門化された要素のセットの代わりに散文の記述を含むことがあり、これにより、符号化する者は関連する情報を構造化された形式で提示するか、散文で提示するかを選択することができる。

declarations

接尾辞Declで終わる名前の要素（例えばtagsDecl、refsDecl）は、電子テキストに適用される特定の符号化方式に関する情報を含んでいる。しばしば、これらの実行はコード化された形式で記述される。典型的には、このような情報は、より複雑な構造や記述を持つコードを識別するための一連の宣言の形を取る。複数のテキスト又は一つのテキストの部分に適用される宣言は、そのようなテキストや下位区分のそれぞれのヘッダーで繰り返される必要はない。その代わりに、宣言が適用される各テキスト（又はテキストの下位区分）の@decls属性はセクション15.3テキストと文脈情報の関連付けでさらに説明しているように、それへの相互参照を提供するために使用してもよい。

descriptions

接尾辞Descで終わる名前の要素（例えばsettingDesc、projectDesc）は散文的な記述を含んでいる可能性があるが、必ずしもそうではなく、提案された下位要素による特定の見出しの下に整理されている。

TEIヘッダーはメタデータカテゴリの非常に豊富なコレクションを提供しているが、網羅的であるとは主張していない。個々のプロジェクトが、TEIヘッダーによって特定された定義済みのカテゴリのいずれかに収まらない、あるいはここで提案されているよりも特殊な要素構造を必要とする特殊なメタデータを記録したいと思うことも間違いなく考えられる。この問題を解決するために、符号化する者はセクション23.3 カスタム化で説明したカスタマイズ方法を使用して、追加の要素を定義することができる。TEI クラスシステムを使用すると、このようなカスタマイズがより簡単になり、交換での使用が容易になる。

これらのクラスはヘッダーの部分に固有のものである。

• model.applicationLike ヘッダー内ヘッダーで、文書に関するアプリケーション固有の情報を記録する要素をグループ化する．

• model.availabilityPart 利用可能ステートメントの一部にある、テキストのlicenceやparagraphなどの要素をグループ化する。

• model.catDescPart TEIヘッダーヘッダーのCategory Description（カテゴリー記述）の構成要素をまとめる．

• model.editorialDeclPart editorialDeclの要素中で使われ、複数回出現可能な要素をグループ化する．

• model.encodingDescPart は、要素encodingDesc内で使われ、複数回出現可能な要素をグループ化する。

• model.profileDescPart 要素profileDesc内で使われ、複数回出現可能な要素をまとめる．

• model.teiHeaderPart TEIヘッダーヘッダー内で2回以上出現しうる、上位レベルの要素をまとめる．

• model.sourceDescPart 要素sourceDesc内で、複数回出現可能な要素をまとめる．

• model.textDescPart 例えば、状況パラメータの項目などに関して、テキストを分類するための要素をまとめる．

本節ではteiHeader要素の最初の構成要素であるfileDescについて説明する。

機械可読またはデジタルテキストの書誌記述は、書籍、論文、または他の種類のテキストオブジェクトの構造に似ている。したがって、TEIヘッダーのファイル記述要素は、図書館目録作成における既存の標準に密接にモデル化されており、ユーザーが電子テキストに標準的な書誌参照を与え、目録作成者がそれを目録作成できるようにするのに十分な情報を提供しなければならない。ヘッダーの他の場所にある書誌引用および本文自体にある書誌引用は同じモデルに基づいている（書誌引用一般につい ては、セクション3.11文献と参考文献を参照すること）。また、セクション2.8図書館の目録担当者向けの注記を参照すること。

電子テキストの書誌記述は、必須のfileDesc要素によって提供されなければならない。

• <fileDesc> (ファイル記述[file description]) 電子ファイルに関する完全な書誌情報を含む．

fileDescには3つの必須の要素と4つの任意の要素が含まれており、それぞれについては後述のセクション2.2.1 タイトルに関する言明からセクション2.2.6 注記に関する言明にかけて詳細に記述している。これらの要素は下記に列挙し、fileDesc要素に与えなくてはならない順序で示している。

• <titleStmt> (タイトルに関する言明[title statement]) 作品や知的内容に責任のあるもののタイトルに関する情報をまとめる
• <editionStmt> (エディションに関する言明[edition statement]) テキストのエディションに関する情報をまとめる．
• <extent> デジタル・非デジタルテキストの、または、何らかのキャリア媒体のおよその大きさを任意の単位で示す．
• <publicationStmt> (出版に関する言明[publication statement]) 電子テキストまたは別の形式のテキストの出版や頒布に関する情報をまとめる．
• <seriesStmt> (シリーズに関する言明[series statement]) もしあれば、出版物が属するされたシリーズの情報をまとめる．
• <notesStmt> (注記に関する言明[notes statement]) 当該書誌情報の他の部分で記録されているものに追加されたテキストに関する注釈をまとめる．
• <sourceDesc> (ソースの記述[source description]) 電子テキストが作られたソーステキストの情報を示す．デジタル化されたテキストの場合は、典型的には、書誌学的な記述か、以前に存在しなかったテキストの「born digital」といったフレーズである.

全てのありうる下位要素を含めた完全なファイル記述は、次のようになる。

<teiHeader>
 <fileDesc>
  <titleStmt>
   <title>
<!– title of the resource –>
   </title>
  </titleStmt>
  <editionStmt>
   <p>
<!– information about the edition of the resource –>
   </p>
  </editionStmt>
  <extent>
<!– description of the size of the resource –>
  </extent>
  <publicationStmt>
   <p>
<!– information about the distribution of the resource –>
   </p>
  </publicationStmt>
  <seriesStmt>
   <p>
<!– information about any series to which the resource belongs –>
   </p>
  </seriesStmt>
  <notesStmt>
   <note>
<!– notes on other aspects of the resource –>
   </note>
  </notesStmt>
  <sourceDesc>
   <p>
<!– information about the source from which the resource was derived –>
   </p>
  </sourceDesc>
 </fileDesc>
</teiHeader>

bibliography 

これらの要素のうち、必要なのはtitleStmt、publicationStmt、およびsourceDescのみであり、他は有用と思われる場合を除き省略してよい。

titleStmt要素はfileDesc要素の最初の構成要素であり、必須である。

• <titleStmt> (タイトルに関する言明[title statement]) 作品や知的内容に責任のあるもののタイトルに関する情報をまとめる．

この要素には電子作品に与えられているタイトルとともに、エンコーダーや編集者、著者、編纂者、またはその他の責任を負う関係者を特定している責任に関する言明（statements of responsibility）が任意で1つ以上含まれている。

• <title> あらゆる作品の完全なタイトルが含まれる。
• <author> 書誌情報における、著作者(個人・団体)の名前を示す．書誌項目における歴任者を示す第一位の記述を示す．
• <editor> 書誌情報における、第二位の責任者を示す．個人、団体、組織, 編集者、編 纂者、翻訳者の名前など．
• <sponsor> 支援を行う組織や団体の名前を示す．
• <funder> (出資機関[funding body]) テキストやプロジェクトの資金提供に責任を持つ個人、団体、組織の名前を 示す．
• <principal> (主任研究者[principal researcher]) 電子テキストの生成に責任のある中心的な研究者の名前を示す．
• <respStmt> (責任に関する言明[statement of responsibility]) 著者や編集者など特定の役割を示す要素が充分ではない場合に、テキスト、 版、記録などの知的内容に関する責任を示す．
• <resp> (責任[responsibility]) 人物の知的責任の性質を示す文章を含む．
• <name> (名前、固有名詞[name, proper noun]) 固有名詞もしくは名詞句を含む。

title要素は、電子著作物の主タイトルを含み、付与されている可能性がある別タイトルやサブタイトルも含む。作品が複数のタイトル(あるいは異なる言語も含め)を持っていたり、その作成者が適切と考える形式であれば、繰り返し記述できる。電子著作物が既存の原文から派生したものである場合、前者のタイトルは後者のものに由来したものであるべきだが、例えば、「: an electronic transcription」や「a digital edition」といったフレーズの追加によって、明確に区別できるようにすることが強く推奨される。これにより、両方のタイプの資料の説明を含む引用やカタログの中で、電子著作物と原文を区別することができる。

また、電子著作物には、常に存在するコンピュータシステム上の外部名（その「ファイル名」または「データセット名」）または参照番号を有することになる。この名前は、ファイルの新しいコピーがコンピュータシステム上で作成されるため、頻繁に変更される可能性がある。その形式は使用中の特定のコンピュータシステムに完全に依存しているため、常にあるシステムから別のシステムに簡単に転送することはできない。さらに、作品の中には多数のファイルによって構成されているものがあることも考えられる。これらの理由から、本ガイドラインでは、そのような名称を電子的著作物のtitleとして使用すべきではないことを強く推奨する。

困難な場合に有用な記述的タイトルの策定に関する有益なガイダンスは、英米目録規則 (2002–2005)) の第25章または他の国のカタロギングコードにおいて用意されている。

author、editor、sponsor、funder、およびprincipalの各要素は、より一般的なrespStmt要素を特化させたものである。これらの要素は、品目の知的または芸術的内容に責任のある人物とそれが由来する法人を特定する責任に関する言明を提供するために使用されている。

このような言明は、タイトル言明の中にいくつでも入れることができる。最低限、本文の作成者および（適切な場合には）ファイルの作成者を特定する。書誌記述がコーパスのためのものである場合は、コーパスの作成者を特定する。必要に応じて、本文の転写または精緻化に関与した他の関係者、スポンサー、資金提供機関の名前も含める。物理的なデータ入力に責任を持つ人の名前は、その人がファイルの作成に知的な責任を持つ場合を除き、通常は記録する必要はない。

文書化されるべき責任者が著者、スポンサー、資金提供機関、あるいは主任研究者ではない場合は、respStmt要素を使用すべきである。これには、責任のある個人または組織を識別するname要素と、責任の性質を示すresp要素の 2 つの下位構成要素がある。respの適切な内容については、現時点では具体的な推奨はしていない。以下の例のように、関連する責任の性質を明確にすべきである。

与えられた名前は、個人名であっても法人名であってもよい。全ての氏名は、個人または団体が公に引用されることを希望する形式で記入する。これは通常、下の名前を含めた氏名の完全な形である。²

例:

<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ḥ):
   a digital edition.</title>
 <title>The Yogasūtras of Patañjali:
   a digital edition.</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>

editionStmt要素はfileDesc要素における2つ目の構成要素である。任意であるが、指定することを勧める。

• <editionStmt> (エディションに関する言明[edition statement]) 版に関する情報をまとめる．

フレーズと、エディションとそれに対して責任を負う者を特定するより特化した要素のいずれかを含んでいる。

• <edition> テキストの版の詳細を示す．
• <respStmt> (責任に関する言明[statement of responsibility]) 著者や編集者など特定の役割を示す要素が充分ではない場合に、テキスト、 版、記録、シリーズなどの知的内容に関する責任を示す．書誌作品の制作や頒布において役割を果たした個人や組織に関する情報を符号化するのに使ってもよい．
• <name> (名前、固有名詞[name, proper noun]) 固有名詞や固有名詞句を含む．
• <resp> (責任[responsibility]) 人物の知的責任、もしくは作品の制作や頒布における組織の役割の性質を表す一節を示す．

印刷されたテキストの場合、エディション（版）という言葉は、特定の出版団体またはそのような団体のグループによって発行された、1つの原本から作成されたアイテムのすべての同一の複写のセットに適用される。頒布機関の身元が変わっても通常はエディションの変更にはならないが、原本が変わるとエディションの変更が発生する。

電子テキストの場合、印刷されたものよりもはるかにコピーや修正が容易であるため、「原本」という概念は完全には適切ではないが、それにもかかわらず、エディションという用語は、実質的な変更が加えられ、修正された機械可読テキストの特定の状態に使われることがある。本ガイドラインで使用される同義語には、バージョン、レベル、リリースなどがある。対照的に、改訂と更新という言葉は、新しいエディションにはならないファイルの微小な変更を施した場合に用いる。

単なる更新ではなく新版とみなされる前に、「実質的な」変更がどのようなものかを特定できるようなシンプルなルールはない。新版の制作は、ファイルの符号化や外観ではなく、ファイルの知的内容の重要な変更を伴うということを、一般的な原則としてここでは提案している。テキストへの分析的コーディングの追加はこのようにして新版を構成することになるが、一方でコーディングされた表現から別の表現への自動的な変換は新版を構成するとはみなされない。文字コードや物理的な保存の詳細に関する変更、誤字脱字の修正、内容の配置の単純な変更、出力形式の変更は通常は新版を構成しないが、新しい情報の追加（例えば、品詞のタグ付け、音声やグラフィック、外部データセットへの参照リンクなどで表現された言語分析）は、ほとんどの場合、新版とみなされる。

明らかに、ボーダーラインのケースが常にあり、問題はやや恣意的である。最も簡単なルールとしては、ファイルが新版であると考える場合にそのように名づけることである。エディションに関する言明は、コンピュータファイルの最初のリリースでは任意であるが、それ以降のリリースでは必須である。ただし、この必要性はパーサーによって強制されることはできない。

重要と考えられるファイルにおける全ての変更点は、それが新版とみなされるか、単に新しい改訂とみなされるかにかかわらず、ファイルヘッダーの改訂記述セクションに個別に記述しなければならないことに注意する（セクション2.6改訂の記述を参照）。

edition要素には、 版やバージョンといった語句や、またはそれらに相当する語句、番号や日付、または新版、改訂版などの他の版との違いを示す語句を含めて、版またはバージョンを記述しなければならない。エディションに関する言明の中にある日付はdate要素でマークするべきである。他の場所と同様に、そのエディションの正式な識別情報（バージョン番号など）を提供するためにedition要素の@n属性を使用してもよい。

問題となっているエディションの責任に関する言明を提供するために1つ以上のrespStmt要素を使用してもよい。これらは個人または法人のことを指してもよく、改訂者のような機能を示してもよく、さらに新版の付録や付録などの提供に責任を持つ個人または法人の名前を示してもよい。respStmt要素の詳細については、セクション3.11文献と参考文献を参照のこと。

以下にいくつかの例を示す。

<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>

extent要素はfileDesc要素の3つ目の構成要素であり、その使用は任意である。

• <extent> 任意の単位で示されるデジタル又は非デジタルのあるキャリア媒体もしくは何らかの他のオブジェクトに保存されるテキストのおよその大きさを記述する．

印刷された書籍の場合、使用されている媒体の種類や大きさなどの担体に関する情報は、目録作成手順において非常に重要である。項目の媒体および範囲の書誌記述に関する印刷物指向の規則は、電子媒体に適用する場合には、再解釈が必要である。電子ファイルは、そのキャリアとは全く独立した実体として存在し、磁気テープ、CD-ROM、フロッピーディスクのセット、またはメインフレームコンピュータ上のファイルなどの保存媒体にかかわらず同一の知的対象物としてあり続ける。さらに、本ガイドラインは、透明な文書の保存と交換を容易にすることを特に目的としているため、ファイルヘッダーに関する限り、純粋に機械に依存する情報は無関係であるべきである。

これは特にファイルタイプに関する情報について当てはまるが、カタログ作成のための図書館指向の規則では「データ」と「プログラム」という2種類のコンピュータファイルを区別していることが多い。この区別は、ハイパーメディアや検索・取得ソフトウェアを内蔵したテキストなどの場合においては線引きが極めて難しくなる。

同等にシステムに依存しているものの、コンピュータファイルのサイズを測定することは、カタログ作成やその他の実用的な目的のために役立つ可能性がある。ファイルサイズの測定と表現は困難なため、非常に一般的な推奨しかできない。extent要素はこの目的のために提供されているのである。この要素では以下のいずれかの方法でコンピュータファイルのサイズまたはおおよそのサイズを示すフレーズが含まれている。

• 指定の長さのバイト（例えば「4000 16-bit bytes」)
• 以下のようなカテゴリの範囲に収まるサイズとして表現
  • 1 Mb以下
  • 1 Mb – 5 Mb
  • 6 Mb – 10 Mb
  • 10 Mb以上
• 便利な論理的単位（例えば単語や文、引用、段落などの数）
• 便利な物理的単位（例えばブロック、ディスク、テープの個数）

他でも同じように、ここでも数量単位の標準的な略語が適切な場合には推奨される。（http://physics.nist.gov/cuu/Units/binary.htmlを参照）。

例:

<extent>between 1 and
2 Mb</extent>
<extent>4.2 MiB</extent>
<extent>4532 bytes</extent>
<extent>3200 sentences</extent>
<extent>Five 90 mm High Density Diskettes</extent>

measure 要素とその属性は、次の例のように、所与のサイズの機械が追跡可能、もしくは、正規化されたバージョンを供給するために使用されうる。

<extent>
 <measure unit=”MiB” quantity=”4.2″>About four megabytes</measure>
 <measure unit=”pages” quantity=”245″>245 pages of source
   material</measure>
</extent>

ここで注意していただきたいのは、単一のextentに1つ以上のmeasureが含まれている場合、個々の値はそれぞれにリソース全体を指していることを意味しているという点である。

publicationStmt要素はfileDesc要素の4つ目の構成要素であり、必須要素である。本要素の機能は、リソースを入手可能にした機関を特定し（例えば出版者や頒布者）、さらにライセンシングの条件や識別番号など、利用可能に至った方法に関する追加情報を供給することを目的としている。

• <publicationStmt> (出版に関する言明[publication statement]) 電子テキストなどのテキストの出版や頒布に関する情報をまとめる．

簡単な散文の記述を1つ以上の段落として整理したものか、下記に示すより特化した要素を含む。

構造化した出版に関する言明は以下のいずれかの要素から始まらなくてはならない。

• <publisher> 書誌項目の出版や頒布に責任のある団体の名前を示す．
• <distributor> テキストの頒布に責任を持つ人物または団体の名前を示す．
• <authority> (リリースに関する権限[release authority]) 電子データの作成に責任のある個人または団体の名前を示す．出版者や頒布者ではない．

これらの要素はmodel.publicationStmtPart.agencyクラスを形成している。リソースを利用可能にしている機関が不明であるもののそれに関する他の構造化された情報が利用可能な場合は、「出版者不明」のように明示的に記述する必要がある。

出版者とは、ファイルのある版が公開される権限を持つ個人または機関のことである。頒布者とは、テキストのコピーをそこから入手できる個人または機関のことである。テキストが正式に出版されたとは考えられないが、それにもかかわらず何らかの個人や組織によって流通のために利用できるようにされている場合、この個人や組織はリリース・オーソリティと呼ばれる。

これらの要素のいずれを選択しても、以下の要素の1つ以上が後に続くことがあり、これらの要素を合わせてmodel.publicationStmtPart.detailクラスを形成している。

• <pubPlace> (出版場所[publication place]) 書誌項目が出版された場所の名前を示す．
• <address> 郵便配達情報を示す．例えば、出版者、組織、個人の住所など．
• <idno> (識別子[identifier]) 書誌項目、人物、タイトル、機関などといった何らかのオブジェクトを識別するために用いられる識別子のあらゆる形式を、標準化された方法で示す．

• <availability> テキストの利用可能性に関する情報を示す．例えば、その使用や頒布、 著作権、それに適用可能なあらゆるライセンスに関する制限など．

• <date> あらゆる形式での日付を含んでいる．
• <licence> そのテキストに適応可能なライセンスやほかの法的な合意に関する情報を含んでいる．

簡単な例を以下に示す。

<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>

model.publicationStmtPart.detail要素はすべて、その直前にある出版者、頒布者、またはリリース権限に関連する追加情報を提供する。以下の例では、Bensonは引用されている日付と場所で行われた何らかのリソースの頒布に責任があると特定されている。

<publicationStmt>
 <authority>James D. Benson</authority>
 <pubPlace>London</pubPlace>
 <date>1994</date>
</publicationStmt>

リソースは(例えば)出版者と頒布者の両方を持っていてもよいし、複数の出版者がそれぞれ同じリソースに対して異なる識別子を使用していてもよい。このため、少なくとも1つのmodel.publicationStmtPart.agency要素の後に続く0個以上のmodel.publicationStmtPart.detail要素のシーケンスは、必要に応じて繰り返してもよい。

以下の例は、ある機関（Sigma Press）がある住所と日付で発行したリソースを、別の機関（Oxford Text Archive）が指定した識別子と異なる日付で頒布していることを示している。

<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>
 <date>1994</date>
</publicationStmt>

publicationStmt内で使用されるdate要素は、常に出版日、最初の頒布日、または最初のリリース日を参照している。テキストが他の日付で作成されていた場合、profileDesc要素内のcreation要素を用いて記録することができる。その他の有用な日付（データの収集日など）はnotesStmt要素内の注記を使って与えてもよい。

上述のように、availability要素は、リソースの頒布に関する制限事項を簡単な平文で記述するために使用してもよい。あるいはlicence要素を使用して、適用されるライセンス条件のより形式的な記述を提供することもできる。

<publicationStmt>
 <publisher>University of Victoria Humanities Computing and Media Centre</publisher>
 <pubPlace>Victoria, BC</pubPlace>
 <date>2011</date>
 <availability status=”restricted”>
  <licence target=”http://creativecommons.org/licenses/by-sa/3.0/”> Distributed under a Creative Commons Attribution-ShareAlike 3.0 Unported License
  </licence>
 </availability>
</publicationStmt>

ここで、ライセンス文書自体を取得できる場所を指すために @target属性を使用している点に注意すべきである。または、ライセンスの文言は単にlicence要素の中に含まれていてもよい。

seriesStmt要素はfileDesc要素の5つ目の構成要素であり、任意である。

• <seriesStmt> (シリーズの言明[series statement]) その出版物が属するシリーズ（もしあれば）の情報をまとめる．

書誌学的な用語では、シリーズは次のいずれかの方法で定義することができる。

• 各項目が、それ自身の適切なタイトルに加えて、そのグループ全体に適用される集合的なタイトルを持つという事実によって、互いに関連している別個の項目のグループ。個々の項目には番号が付けられている場合と付けられていない場合がある。
• エッセイ、講演会、論文、その他の項目のうち、類似した性質を持ち、順番に発行された2冊以上の巻物。
• シリーズまたはシリアルの中において個別に採番された一連の巻。

seriesStmt要素は散文の記述または以下の具体的な要素を1つ以上含めることができる。

• <title> あらゆる種類の作品の完全なタイトルを示す．
• <idno> (識別子[identifier]) 書誌項目、人物、タイトル、機関などといった何らかのオブジェクトを識別するために用いられる識別子のあらゆる形式を、標準化された方法で示す．
• <respStmt> (責任に関する言明[statement of responsibility]) 著者や編集者など特定の役割を示す要素が充分ではない場合に、テキスト、 版、記録、シリーズなどの知的内容に関する責任を示す．書誌作品の制作や頒布において役割を果たした個人や組織に関する情報を符号化するのに使ってもよい．
• <resp> (責任[responsibility]) 人物の知的責任、もしくは作品の制作や頒布における組織の役割の性質を表す一節を示す．
• <name> (名前、固有名詞[name, proper noun]) 固有名詞や固有名詞句を含む．

idnoはISSNのような標準番号と特定の発行番号の両方を含む、アイテムに関連付けられた任意の識別番号を提供するために使用することができる。(この目的に向けて、例えば、VI/xix:33などよりも「6.19.33」といった、句読点で分けたアラビア数字の活用を勧める)。その@type属性は、例えばISSNの場合は「ISSN」という値を取り、番号をさらに分類するために使用される。

例:

<seriesStmt>
 <title level=”s”>Machine-Readable Texts for the Study of
   Indian Literature</title>
 <respStmt>
  <resp>ed. by</resp>
  <name>Jan Gonda</name>
 </respStmt>
 <biblScope unit=”volume”>1.2</biblScope>
 <idno type=”ISSN”>0 345 6789</idno>
</seriesStmt>

notesStmt要素はfileDesc要素の6つ目の構成要素であり、任意である。活用する場合、1つ以上のnote要素を含み、それぞれが従来の書誌的な記述における「一般的な注記」として扱われている種類の説明情報を一つ含んでいる。

• <notesStmt> (注記に関する宣言[notes statement]) 当該書誌情報の別の部分に記録されている、テキストに関する附属的な情報を記述したすべての注記をまとめる。
• <note> 注釈・コメントを含む．

従来の書誌では注記のなかで認められた情報の中には、本ガイドラインで、特定の要素が割り当てられているものもある。特に以下の項目については、一般的な注記としてではなく、指定通りのタグ付けをすべきである。

• ファイルの性質、範囲、芸術的形態、または目的。また、それが属する可能性のあるジャンルまたはその他の知的カテゴリー。例えば、「テキストの種類：新聞の社説とルポルタージュ、SF、西部劇、探偵小説」。これらの情報は、profileDesc要素の中で形式的に記述すべきである（セクション2.4 プロファイルの記述）。
• エンコーダーが与えた文書の内容に関する要旨または要約。このような要旨は原資料の内容を構成していないためである。これらの情報は、profileDesc要素の内のabstract要素で記述すべきである（セクション2.4 プロファイルの記述）。
• ファイルの内容に関する事実関係や非評価的な説明に関する要約的記述。例えば、「1963年の春と夏の間に17の都市で行われた、英語を母国語とする人たちに対する一般的な話題を扱ったインタビューの文字起こし」。これらもprofileDesc要素の中に形式的に記述すべきである。（セクション2.4 プロファイルの記述）。
• 電子テキストの出典または出典に関連する書誌詳細。例：「1623年版Folioのノートン・ファクシミリから転写された」。これらはsourceDesc要素に形式的に記述すべきである（セクション2.2.7ソースに関する記述）。
• テキストの出版、頒布、公開に関する追加情報。これには、テキストを入手できるソース元、その使用に関する制限情報や利用可能性に関する正式な条件が含まれる。これらはpublicationStmt要素における適切な部分に記述すべきである（セクション2.2.4出版、頒布、ライセンスなど）。
• ファイルに関連付けられた公的な文書番号。例：「ICPSR study number 1803」や「Oxford Text Archive text number 1243」。これらの情報は、publicationStmt要素で適切に区分されたidno要素内に記述されるべきである。国際標準逐次刊行物番号（ISSN）、国際標準図書番号（ISBN）、およびその他の国際的に合意された品目を一意に識別する標準番号は、特別な書誌学的注釈としてではなく、同じ仕方で扱われるべきである。

しかしながら、notesStmt要素は、以下に例示するような、ファイルとその特徴に関する潜在的に重要な詳細情報を記録するために使用されてもよい。

• コンピュータファイルの内容または状態に関連する場合の日付情報。「manual dated 1983」、「Interview wave I: Apr. 1989」、「wave II: Jan. 1990」など。
• ファイル記述のタイトルまたは版情報に作成責任者の情報が記載されていない場合、そのファイル作成に費やしたエフォートに関する技術や管理、またはコンサルティング機能にかかわった個人または組織の名前。例：「マーク・コーエンによる歴史学的解説」。
• 追加の媒体でのファイルの利用可能性、または文書の利用可能性について既に記録されているわけではない情報。例：「ユーザーマニュアルは11のページに分けられたルーズリーフです。」
• langUsage要素で符号化されていない場合は、作品と概要の言語情報。例えば「本文は英語、概要はフランス語とドイツ語」など。
• idnoに符号化されていない場合、国際逐次刊行物データシステム(ISDS)で逐次刊行物に割り当てられた一意の名前。
• 関連出版物のリストで、出典そのものを記述しているか、電子作品の作成や利用に関係するもの。例えば「Burrows (1987)に用いられたテキスト」など。

このような情報の各項目はセクション3.8注記、注釈、および索引で説明した汎用のnote要素を使用してタグ付けすることができる。以下の例のように、注記のグループはnotesStmt要素の中に含まれる。

<notesStmt>
 <note>Historical commentary provided by Mark Cohen.</note>
 <note>OCR scanning done at University of Toronto.</note>
</notesStmt>

しかし、TEIヘッダー内の別の場所でより正確な要素を用いて符号化できるのであれば、そのようにした方がよい。例えば、上記の注記は、以下のように符号化可能である。

<titleStmt>
 <title>…</title>
 <respStmt>
  <persName>Mark Cohen</persName>
  <resp>historical commentary</resp>
 </respStmt>
 <respStmt>
  <orgName>University of Toronto</orgName>
  <resp>OCR scanning</resp>
 </respStmt>
</titleStmt>

sourceDescはfileDesc要素の7つ目（そして最後の）要素である。これは必須の要素であり、コンピュータファイルを派生したソースの詳細を記録するために用いる。これは印刷されているテキストや手稿本であったり、別のコンピュータファイル、ある種の音声や動画、またはこれらの組み合わせなどが考えられる。目録が作成されている元のテキストが電子形式で作成された場合、電子ファイルでもソースがない場合がある。

• <sourceDesc> (ソースに関する記述[source description])デジタルテキストの場合、典型的には書誌学的記述である電子テキストがそこから作られた、もしくは派生したソース、もしくは以前には存在しなかったテキストのための「born digital」のようなフレーズといった情報を示す．

sourceDesc要素は簡単な散文の記述や、文書にはソースがないことを明記している簡単な注記を含む。

<sourceDesc>
 <p>Born digital.</p>
</sourceDesc>

別に、以下の3クラスから取得した要素を含んでいることがある。

• model.biblLike 書誌情報を含む要素をまとめる．

• model.sourceDescPart 要素sourceDesc内で、複数回出現可能な要素をまとめる．

• model.listLike リスト相当の要素をまとめる．

これらのクラスは、テキストのソースを指定する書誌引用の提供方法の範囲をデフォルトで利用できるようにしている。書面または印刷されたソースについては、以下の要素のいずれかを用いて、他の書誌引用情報と同様の方法で記述することができる。

• <bibl> (書誌引用情報[bibliographic citation]) 厳密でない構造を持つ書誌情報の引用を含む．下位要素が明示されていたり、 いなかったりする．
• <biblStruct> (構造を持つ書誌引用情報[structured bibliographic citation]) 構造を持った書誌情報を示す．そこでは書誌情報を示す下位要素が決められた順番で出現する．
• <listBibl> (引用リスト[citation list]) 書誌項目引用のリストを示す．

これらの要素についてはセクション3.11文献と参考文献でより詳しく記述している。これらを用いて、非常に簡単な用語でソースを記述することができる。

<sourceDesc>
 <bibl>The first folio of Shakespeare, prepared by
   Charlton Hinman (The Norton Facsimile, 1968)</bibl>
</sourceDesc>

あるいは、さらに詳細化していくと次の通りになる。

<sourceDesc>
 <biblStruct xml: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 when=”1846″>1846</date>
   </imprint>
  </monogr>
 </biblStruct>
</sourceDesc>

ヘッダーに既存のTEI準拠文書やその他のデジタル文書から派生したテキストを記述する場合は、「ボーンデジタル」なテキストから派生した文書を特に対象として設計した次の要素を使用した方が簡単な場合がある。

• <biblFull> (完全な構造をもつ書誌引用情報[fully structured bibliographic citation]) 厳密な構造を持つ書誌情報を示す．TEIのファイル記述の全要素は、ここ に記述される．

詳しい説明についてはセクション2.2.8他のコンピュータファイルから派生したコンピュータファイルを参照すること。

原稿の記述に関するモジュールをスキーマに含める場合、本クラスにより以下の要素が利用可能になる。

• <msDesc> (手稿本に関する記述[manuscript description]) 単一の識別可能な手稿本、もしくは初期の印刷本のようなテキストを持つ他のオブジェクトの解説を示す．

この要素によりエンコーダーが1つ以上の原稿やアナログの情報源について非常に細かい情報を記録することが可能になる。詳細は第10章 原稿の記述で述べている。

model.sourceDescPartクラスも追加のモジュールが含まれた際に追加の要素を利用可能にしている。例えば、音声モジュールを含める場合、sourceDesc要素は以下の特別な目的を持った要素も含める可能性がある。これらの要素は電子テキストを音声テキストから導出する場合に用いることを想定している。

• <scriptStmt> (台本に関する言明script statement]) 発話テキストで使われている台本の詳細に関する引用を示す．
• <recordingStmt> (録音・録画に関する言明[recording statement]) 発話テキストの転記の元になる録音、録画されたものを示す．

これらの要素とその内容に関する詳しい記述はセクション8.2 文字起こししたスピーチの情報源の文書化において提供している。

単一の電子テキストは、全体または部分的に複数の文書から派生したものであってもよい。そのため、sourceDescは、それぞれの当該ソースについて、msDesc、bibl、およびbiblStruct要素をグループ化したlistBibl要素を含んでもよい。また、そのような場合にはsourceDesc要素を繰り返すことも可能である。@decls属性（セクション15.3テキストと文脈情報の関連付けにて記述）は、いずれの場合も、符号化されたテキストの一部を、それが由来する書誌要素に関連付けるために使用してもよい。

ソースの記述には、これらが符号化文書の出典の一部を形成していると考えられる場合には、名前、人、場所などのリストも含めることができる。このような情報がnamesdatesモジュール（第13章 Names, Dates, People, and Places）で論じられている特殊な要素を用いて記録される場合、model.listLikeクラスはそのような情報を保持するために次の要素を利用できるようにする。

• <listNym> (正規化した名前のリスト[list of canonical names]) 別名、すなわち、一般的に使われている名前のリストを示す．
• <listOrg> (機関のリスト[list of organizations]) 特定可能な団体に関する情報を示す解説のリストを示す．
• <listPerson> (人物のリスト[list of persons]) 特定可能な個人やグループに関する情報のリストを示す．例えば、言語交流の参加者や、歴史資料中で参照される人物など．
• <listPlace> (場所のリスト[list of places]) 場所のリストを示す．選択的に、場所間の(包含関係ではなく)関連性を 示すリストが続く．

あるコンピュータファイル（これをBと呼ぶ）が、印刷されたソースからではなく、TEIヘッダーを含む別のコンピュータファイル（これをAと呼ぶ）から派生した場合、コンピュータファイルBのソーステキストは、コンピュータファイルAである。以下に示すように、Aのファイルヘッダーにおける5つのセクションは少しずつ異なる方法でBの新しいヘッダーに組み込む必要がある。

fileDesc

Aのファイル記述は、Bのファイル記述のsourceDescセクションにコピーされ、biblFull要素で囲まれる。

profileDesc

AのprofileDescは原則として変更されずにBのものにコピーされる。ただし、プロジェクト特有のBに関する情報によって拡大されることがある。

encodingDesc

A の符号化方法は、B の符号化と同じであってもなくても構わない。符号化記述の目的は、現在のファイルとそのソースとの関係を定義することであるため、 原則として、AとBの間の符号化方法の変更だけをBで文書化する必要がある。Aとそのソースとの関係は、Aの元のヘッダーからしか復元できない。実際には、Aのものを元にしてB用の完全なencodingDescを新たに作成した方が便利な可能性がある。

xenoData

Bは、Aのソース（すなわち、A）を持つ新しいコンピュータファイルである。したがって、類似点はあるかもしれないものの、Aやそのソースに関する他のスキームのメタデータをBに卸してコピーできる可能性は低い。

revisionDesc

Bは新しいコンピュータファイルであるため、新しい改訂の記述を持つべきである。しかし、主要なアップデートやバージョンの日付など、AのrevisionDescからいくつかの情報を含めることが有用であると思われる場合、そのような情報は、BではなくAに関連するものであることを明確にマークする必要がある。

以上で、fileDesc要素とその内容についての説明を終える。

encodingDesc要素は、TEIヘッダーの2つ目の主な下位区分である。この要素は、手元のテキストの転写や符号化を制御する方法や編集の原則を規定し、ヘッダーの他のコンポーネントで使用されるコード化された定義のセットを含むこともある。正式には必須ではないが、その使用を強く推奨する。

• <encodingDesc> (符号化に関する記述[encoding description]) 電子テキストとその元資料との関係を示す．

符号化記述にはあらゆる組み合わせのテキストの段落が含まれていることが考えられ、 p要素を用いてマークアップし、model.encodingDescPartクラスから取得した特化型の要素も併用している。デフォルトで、本クラスでは以下の要素が利用可能である。

• <projectDesc> (プロジェクトに関する記述[project description]) 制作過程に関する情報も含めて、電子ファイルが作られた目的の詳細を示す．
• <samplingDecl> (サンプリング宣言[sampling declaration]) コーパス等を作成する際、テキストを標本化する原理や手法に関する、散文による解説を含む．
• <editorialDecl> (編集慣習の宣言[editorial practice declaration]) テキストを符号化する際に適用される編集方針や編集方法の詳細を示す．
• <tagsDecl> (タグ付けの宣言[tagging declaration]) タグ付けに関する詳細な情報を示す．
• <styleDefDecl> (スタイル定義言語の宣言[style definition language declartion]) スタイルあるいはレンダリング情報を文書内の別の箇所へ提供するための形式的な言語を指定。スキーマの具体的なバージョンも提供できる.
• <refsDecl>(参照の宣言[references declaration]) そのテキストのための、標準的な参照の作られ方を示す．
• <classDecl> (分類宣言[classification declarations]) 当該テキスト中で使用されている分類コードを定義する、ひとつ以上の分類法を示す．
• <geoDecl> (地理座標の宣言[geographic coordinates declaration]) 当該文書中にある要素geoの内容が表す座標の表記法や位置測定基準を示す．
• <unitDecl> (単位宣言[unit declarations]) は国際単位系に属していない測定単位に関する情報を提供している。
• <schemaSpec> (スキーマの仕様[schema specification]) TEI準拠のスキーマや文書を示す．
• <schemaRef> (スキーマ参照[schema reference]) 関連するカスタマイズファイルやスキーマファイルを記述するか指す.

各要素については適切な節でさらに詳しく説明する。その他のモジュールも本クラスを拡張することができる。例はセクション2.3.12モジュール特有の宣言で示している。

projectDesc要素は、デジタルリソースが作成された目的と、集められたまたは収集された理由に関する関連情報を散文によって説明するために用いることができる。これはコーパスや雑多なコレクションでは特に重要であるが、例えば、ある種類の符号化をなぜ他の種類より優先したのかを説明するなど、どのようなテキストにも使える。

• <projectDesc> (プロジェクト記述[project description]) 制作過程に関する情報も含めて、電子ファイルが符号化された目的の詳細を示す．

例えば:

<encodingDesc>
 <projectDesc>
  <p>Texts collected for use in the
     Claremont Shakespeare Clinic, June 1990.</p>
 </projectDesc>
</encodingDesc>

samplingDecl要素は、散文によってテキストあるいはテキストの一部をリソースに含めるために選択した際に用いた根拠と手法を記述するために用いることができる。

• <samplingDecl> (サンプリング宣言[sampling declaration]) コーパス等を作成する際、テキストを標本化する原理や手法に関する、散文による解説を含む．

ここでは以下のような情報を含めるべきである。

• 個別サンプルのサイズ
• サンプルの選択に用いた方法
• サンプル対象の母集団
• サンプリング手順に用いたオブジェクト

ただし、これらに限られている訳ではない。

<samplingDecl>
 <p>Samples of 2000 words taken from the beginning of the text.</p>
</samplingDecl>

含めた（あるいは除外した）元のテキストの如何なる部分の簡単な説明を含めてもよい。

<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>

複数のテキスト又はテキストの区分に適用されるサンプリング宣言は、そのような各テキストのヘッダーにおいて繰り返される必要はない。代わりに、セクション15.3テキストと文脈情報の関連付けで詳述するように、サンプリング宣言が適用される各テキスト（又はそのテキストのサブ区分）のdecls属性は、それに対する相互参照を提供するために用いてもよい。

editorialDecl要素はテキストの符号化の細に応用した編集の慣習の詳細を提供する上で用いる。

• <editorialDecl> (編集慣習の宣言[editorial practice declaration]) テキストを符号化する際に適用される編集方針や編集方法の詳細を示す．

散文の記述のみを含む場合も、model.editorialDeclPartクラスのメンバーである特殊な要素のセットを1つ以上含むこともある。エンコーダーが上記に指定されていない編集方針を記録したい場合はセクション23.3 カスタム化で説明したメカニズムを使用して、本クラスに新しい要素を追加することで行うことができる。

これらのポリシー要素の中には、明確に定義された編集上の決定の自動処理をサポートするための属性を持つものもあるが、それらの要素はどれも関係する特定の機能に関して採用された編集上の原則の説明を含んでいる。これらの記述が回答しようとしている質問の種類の例を以下のリストに示す。

correction

• <correction> (修正原則[correction principles]) テキスト中に施された修正の状況や方法を示す．

データ取得中、またはデータ取得後にテキストが修正されているか？もしそうであれば、修正は黙って行われたのか、あるいはセクション3.4簡単な編集上の変更で説明されているタグを使ってマークされているのか？省略、切り捨て、疑わしい訂正、代替的な読み方、誤った開始、繰り返しなどに関して、どのような原則が採用されているのか？

normalization

• <normalization> 元資料が電子形式に変換される際に施される正規化の程度を示す．

[att.global.source]

この要素の何らかの側面を示すソースを指定する。

@method

当該テキストに施された正規化の方法を示す．

テキストは正規化されていたか？もしそうならば、正規化は黙って行われたのか、あるいはセクション3.4簡単な編集上の変更で説明されているタグを使ってマークされていたか？正規化にはどのような権限が使われたのか? また、セクション3.5.3数字と測定値で説明されている@value属性の標準値を提供するために数字を正規化する際に、どのような原則が使われ、どのような形式が使われたのか?

punctuation

• <punctuation>は、元の文における句読点に関する編集上の慣習を指定する。

元のソースに存在する句読点は保持されているか？それらは要素pcで識別されているのか、マークアップによって暗示されているのか？保持されている場合、関連する要素に対してどのように配置されているのか？例えば、カンマやピリオドは、フレーズや文章をマークする要素の内側や外側に表示されているだろうか？

quotation

• <quotation> 元資料にあった引用をどのように編集したのかを示す．

引用符はどのように処理されているのか？アポストロフィーと引用符は区別されているか？どのように処理されているのか？引用符はテキストの内容として保持されているのか、それともマークアップによって置き換えられているのか？例えば、ネストされた場合のシングルクォーテーションマークやダブルクォーテーションマークの使用について、特別な規則はないか？そのファイルはその慣習に一貫性があるか、あるいはチェックされていないのか？引用符のエンコード方法についてはセクション3.3.3引用句を参照すること。

hyphenation

• <hyphenation> ソーステキストにあるハイフンが、符号化された版ではどのように扱われたかを要約する．

符号化は「ソフト」ハイフンと「ハード」ハイフンを区別しているか？原文の改行が保持されていない場合、行末のハイフネーションに関してどのような原則が採用されているのか？ソフトハイフンは黙って除去されているのか、また除去されている場合、改行やページネーションへの影響はどのようになっているのか？ハイフネーションをエンコードする方法についてはセクション3.2.2ハイフネーションを参照すること。

segmentation

• <segmentation> 当該テキストを分割した基準を示す．例えば、文、音単位、書記層など．

テキストはどのように分割されているのか？分析に向けてテキストを分割するために sやseg分割ユニットを用いている場合、それらはどのようにマークされ、分割はどのようにして達成されているのか？

stdVals

• <stdVals> (標準値[standard values]) 標準的な日付や数値を示す形式を特定する．

ほとんどの場合、標準化された値を持つ属性（日付のwhen属性やwhen-iso属性など）は、定義されたW3CやISOのデータ型に準拠する必要がある。これが適切でない場合、提供された値の基礎となる標準化方法を記述するためにこの要素を使用することがある。

interpretation

• <interpretation> 転記されたテキストに付加された、分析または解釈情報の範囲を示す．

分析的または「解釈的」な情報が提供されているか、つまり自明ではないと思われる情報や論争の可能性があると思われる情報が提供されているか？あるとすれば、それはどのように生成されたのか？どのように符号化されたのか？素性構造解析が使用されている場合、fsdDecl要素（セクション18.11素性システムの宣言）は存在しているか？

上述の見出しのいずれにも該当しない適用された編集原理に関する情報は、別の項目リストに記録しておくべきである。経験的からは、テキストの将来の利用者のためにも、またテキストを最初に生成したプロジェクトのためにも、編集原則と符号化の実践に関する決定の完全な記録を保持するべきであることが示されている。いくつかの簡単な例を以下に示す。

<editorialDecl>
 <segmentation>
  <p>
   <gi>s</gi> elements mark orthographic sentences and
     are numbered sequentially
     within their parent <gi>div</gi> element
  </p>
 </segmentation>
 <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=”http://szotar.sztaki.hu/webster/”>
  <p>All words converted to Modern American spelling following
     Websters 9th Collegiate dictionary.</p>
 </normalization>
 <quotation marks=”all”>
  <p>All opening quotation marks represented by entity reference
  <ident type=”ge”>odq</ident>; all closing quotation marks
     represented by entity reference <ident type=”ge”>cdq</ident>.</p>
 </quotation>
</editorialDecl>

複数のテキスト又はテキストの区分に適用される編集習慣の宣言は、そのような各テキストのヘッダーの中で繰り返す必要はない。その代わり、宣言が適用される各テキスト（またはテキストのサブ区分）の@decls属性は、セクション15.3テキストと文脈情報の関連付けで詳しく説明しているように、そのテキストへの相互参照を提供するために使用してもよい。

tagsDecl要素は、特定の文書内で用いたタグに関して、以下の情報を記録するために用いる。

• 転写したテキスト内に現れる要素が所属する名前空間。
• 特定の要素がテキスト内に表れる頻度（相互交換時にテキストの整合性を受信者が検証できるようにするため）。
• ヘッダーの別の箇所で説明していない特定の要素の利用に関するコメント。
• 要素の全ての例に適用可能なデフォルトの描出。

これらの情報は、以下の要素によって伝えられる。

• <rendition> 元資料テキスト中にある、ひとつ以上の要素の描出や現れ方に関する情報を 示す．

• att.styleDef はフォーマットやレンダリング情報を提供するための形式的な定義言語の名称を指定する属性を提供する。

• <namespace> 当該要素が属する名前空間の形式名を示す．
• <tagUsage> テキスト中にある特定要素の使い方に関する情報を示す．

tagsDecl要素は規定的ではなく記述的である。使用する場合、それを含むTEI文書の慣習を単に文書化しているに過ぎない。対照的に、TEI カスタマイズファイルを構成する要素（第22章 文書化の要素で説明）は多くの文書で期待される慣習を文書化したものであり、規定的に使用することができる。文書の実際の状態とtagsDeclによって文書化されている状態の間に矛盾がある場合は後者を修正すべきである。文書とカスタマイズファイルやそこから派生したスキーマで要求されるものとの間に矛盾がある場合、通常は文書の方を修正を必要がある。

tagsDecl要素は、それぞれが一意の識別子を持たなければならないrendition要素のオプションのシーケンスから構成され、その後に1つ以上のnamespace要素のオプションのシーケンスが続き、それぞれが一連のtagUsage要素を含み、関連するtext要素内で発生するその名前空間からの各要素タイプに対して最大1つの要素を含む。これらのtagUsage要素はnamespace要素の中に入れネストしなければならず、tagsDecl要素内で直接現れることはできないことに注意していただきたい。

rendition要素を使用することにより、符号化する者は元のソースで 1 つ以上の要素がどのようにレンダリングされるか、以下のいずれかの方法で指定することができる:

• 非公式な散文の記述を使用
• CSS や XSL-FO のような標準スタイルシート言語を使用
• プロジェクト定義の形式言語を使用

そのような1つ以上の仕様は、2通りの方法で文書の要素に関連付けられてもよい:

• 任意のrendition要素の@selector属性は、それが適用される要素の集合を選択するために使用することができる。
• グローバルな@rendition属性は、任意の要素でその描出を示すために使われ、与えられたデフォルト値を上書きしたり補完したりすることができる。

グローバル@rend及び@style属性は、要素のレンダリングを記述するために使用することもできる。セクション1.3.1.1.3 レンディションインジケータも参照すること。

rendition要素の内容は、散文やプロジェクト定義の形式言語を用いてソース素材の外観を記述してもよいし、カスケーディング・スタイル・シート（CSS）言語 (Bos et al. (eds.) (2011)) のような標準言語や、W3Cの拡張可能なスタイルシート言語 (Berglund (ed.) (2006))の一部を形成しているフォーマッティングのセマンティクスを指定するためのXML語彙を用いてもよい。 styleDefDecl要素 (セクション2.3.5 デフォルトのスタイル定義言語の宣言) は、これらのうちのどれがデフォルトで適用されるかを指定するためにencodingDescの中で与えられてもよく、@scheme属性を用いて1つ以上の特定のrendition要素に対して上書きされてもよい。

1つ以上の要素でデフォルトのレンディションを示すための推奨される方法はrenditionの @scheme属性とともに @selector属性を使用することである。例えば、テキストのfrontのすべての段落が大きなフォントで表示され、上下に大きな余白がある一方で、本文（body）の段落は通常のフォントサイズで表示され、上下に余白がないとする。@schemeと一緒に@selectorを使用することで、CSSセレクターを使って段落の文脈ごとに異なるスタイリングを指定する効率的な方法を提供する:

<rendition scheme=”css” selector=”front p”>
font-size: 110%;
margin-top: 0.5em;
margin-bottom: 0.5em;
</rendition>

<rendition scheme=”css” selector=”body p”>
font-size: 100%;
margin-top: 0;
margin-bottom: 0;
</rendition>

以下の拡張版の例では、次の図に示しているような20世紀初期の一般的なタイトルページの捉え方を検討する:

bibliography

タイトルページに情報を符号化するための要素についてはセクション4.6 タイトルページで提示している。ここではrendition要素とそれに対応する属性を使って、視覚情報の一部を符号化する方法について検討する。

最初に、保持したいソースページのレンディションの各側面のためにrendition要素を定義する。CSSの詳細はBos et al. (eds.) (2011)に記載されているが、ここでは単にフォントサイズやスタイル、文字や行間、色などを記述するための語彙を提供するために使用する。この符号化の目的はオリジナルを記述することであって、どのように複製すべきかを指定することではないことに注意すること。

<styleDefDecl scheme=”css”
 schemeVersion=”2.1″/>
<!– … –>
<tagsDecl>
 <rendition xml:id=”center”>text-align: center;</rendition>
 <rendition xml:id=”small”>font-size: small;</rendition>
 <rendition xml:id=”large”>font-size: large;</rendition>
 <rendition xml:id=”x-large”>font-size: x-large;</rendition>
 <rendition xml:id=”xx-large”>font-size: xx-large</rendition>
 <rendition xml:id=”expanded”>letter-spacing: +3pt;</rendition>
 <rendition xml:id=”x-space”>line-height: 150%;</rendition>
 <rendition xml:id=”xx-space”>line-height: 200%;</rendition>
 <rendition xml:id=”red”>color: red;</rendition>
</tagsDecl>

グローバルな@rendition属性を用いて、上述のレンディションの特徴が適用される要素を指定できるようになった。例えば、タイトルページを以下の通り符号化できる:

<titlePage>
 <docTitle rendition=”#center #x-space”>
  <titlePart>
   <lb/>
   <hi rendition=”#x-large”>THE POEMS</hi>
   <lb/>
   <hi rendition=”#small”>OF</hi>
   <lb/>
   <hi rendition=”#red #xx-large”>ALGERNON CHARLES SWINBURNE</hi>
   <lb/>
   <hi rendition=”#large #xx-space”>IN SIX VOLUMES</hi>
  </titlePart>
  <titlePart rendition=”#xx-space”>
   <lb/> VOLUME I.
  <lb/>
   <hi rendition=”#red #x-large”>POEMS AND BALLADS</hi>
   <lb/>
   <hi rendition=”#x-space”>FIRST SERIES</hi>
  </titlePart>
 </docTitle>
 <docImprint rendition=”#center”>
  <lb/>
  <pubPlace rendition=”#xx-space”>LONDON</pubPlace>
  <lb/>
  <publisher rendition=”#red #expanded”>CHATTO &amp; WINDUS</publisher>
  <lb/>
  <docDate when=”1904″ rendition=”#small”>1904</docDate>
 </docImprint>
</titlePage>

bibliography 

スタイル定義言語としてCSSが使用されている場合、@scope属性を使用してCSSの擬似要素を指定することができる。これらの疑似要素は、与えられたテキストの一部にのみ適用されるスタイリングを指定するために使用する。例えば、first-letter疑似要素は、対象となる要素の最初の文字に適用されるスタイリングを定義する一方で、beforeとafterの疑似要素は、要素の内容の前後に追加する必要のある文字を追加するために、”content “プロパティと一緒に頻繁に利用でき、ソースの外観により近いものにすることができる。

例えば、あるテキストがq要素を使ってエンコードされていて、引用符で囲まれているが、引用符自体は符号化からその都度省略されていると仮定すると、以下のようなレンディションのセットになる:

<rendition xml:id=”quoteBefore”
 scheme=”css” scope=”before”>content:
‘“’;</rendition>
<rendition xml:id=”quoteAfter” scheme=”css”
 scope=”after”>content:
‘”’;</rendition>

これは疑似要素quoteBeforeとquoteAfterを予め定義しておくために用いることができる。q要素が最初と最後の引用マークによってソースにおいて実際にレンダリングされている場合は以下の通り符号化できる:

<q rendition=”#quoteBefore #quoteAfter”>Four score and seven years
ago…</q>

上述したように、各namespace要素は、存在する場合、それが現れるteiHeaderに関連付けられた最も外のtext要素内で発生する、与えられた名前空間からの各要素タイプのtagUsage要素を最大 1 回まで含むべきである。³  tagUsageはテキスト内で要素が発生した回数のカウントを提供するために用いることもでき、値は@occurs属性として与えられる。また、追加的な使用法情報を保持するために使用することもでき、要素自体の中で実行中の散文として提供される。

例えば:

<tagUsage gi=”hi” occurs=”28″> Used only to mark English words italicised in the copy text.
</tagUsage>

これは、hi要素が問題のtext要素の中で合計28回出現しており、符号化する者が斜字体の英単語のみをマークするために使用したことを示している。

@withId属性は、以下の例が示す通り、問題の要素のうちグローバル@xml:id属性の値を持つ要素の出現の数を指定するために、任意で用いることができる:

<tagUsage gi=”pb” occurs=”321″ withId=”321″> Marks page breaks in the York
(1734) edition only </tagUsage>

これは、それぞれに識別子が提供されていたpb要素が321回発生したことを示している。

tagUsage要素の内容は自動処理の影響を受けない。したがって、符号化記述の他の構成要素で既に規定されている情報を保持するために使用してはならない。TEIに準拠した文書ではtagUsage要素や @occurs属性を提供することは求められていないが、提供する場合は、カウントが関連するtextに存在している要素の数に対応していなければならない。

rendition要素の内容、@selector属性の値、及び@style属性の値は、形式的に定義された少数のスタイル定義言語のうちの1つを使って表現する。処理を容易にするために、TEIシステムでは混在を許可しているが、符号化プロジェクト全体で単一のスタイル定義言語を使用することを強く推奨している。

tagsDecl要素の兄弟であるstyleDefDecl要素を用いてデフォルトのスタイル定義言語の名前を提供する。この名前は @scheme属性の値として提供し、以下の値のいずれかを取ることができる:

free

非公式の自由形式のテキスト記述

css

カスケーディング・スタイルシート

xslfo

拡張可能なスタイルシート言語フォーマットオブジェクト

other

ユーザーが定義する形式的な記述言語

@schemeVersion属性は、使用されるスタイル定義言語の正確なバージョンを提供するために使用することができ、この要素の内容がある場合には追加情報を提供することができる。

@style属性を使用する場合、その値は常に、デフォルトのスタイル定義言語のいずれかを使用して表現されなければならない。styleDefDeclが複数与えられている場合には、利用可能なデフォルトが一つ以上あり、セクション15.3テキストと文脈情報の関連付けで述べているように、与えられた文脈で適用可能なものを選択するために@decls属性を使用しなければならない。 

refsDecl要素は符号化に組み込まれた標準的な参照スキームがどのように動作するかを文書化するために使用する。

• <refsDecl> (参照の宣言[reference declaration]) テキストのための標準的な参照の作られ方を示す．

一連の散文的な段落か、または以下の特化した要素を含んでいる:

• <cRefPattern> (標準的な参照パターン[canonical reference pattern]) URIへの標準的参照を変形する、表現・変形パターンを示す．
• <refState> (参照状態[reference state]) マイルストーン要素の手法として定義されている標準的な参照の構成要素をひとつ示す．
• att.patternReplacement は正規表現の一致と置換に関する属性を提供している。

現在のソフトウェアシステムでは、すべての参照方式が同じように簡単にサポートされているわけではないことに注意する必要がある。多くの他の文脈と同様に、この文脈では、エンコーダーの利便性と、想定される特定のソフトウェアアプリケーションの効率性との間で選択しなくてはならない。本ガイドラインでサポートされている参照システムに関する詳しい説明については、下記のセクション3.10 参照システムを参照すること。

参照スキームは、この要素を使用して3つの方法のうちの1つを用いて記述することができる。

• 散文の記述として
• 一連の正規表現とXPathのペアとして
• 逐次的に整理したマイルストーンの連結として

各方法について、以下に詳細を記述する。単一のrefsDecl要素内で使用できる方法は1つだけである。

複数の正規参照スキームを同じ文書で使用する場合には、複数のrefsDecl要素をヘッダーに含めることができるが、現在の提案では相互的な不整合について確認していない。

参照スキームはrefsDecl内で簡単な平文の記述で指定することができる。このような記述は、どの要素が識別情報を持ち、その情報が属性値として表現されているのか、それとも内容として表現されているのかを示すべきである。また、参照文字列を読み込んだり生成したりする際に、その情報がどのように解釈されるかについてのあらゆる特別なルールもここで指定する必要がある。このような散文記述は自動処理できないため、このような正規参照システムの構造を指定する方法は自動処理に対しては推奨されない。

例えば:

<refsDecl>
 <p>The <att>n</att> 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 <gi>head</gi> element within each
   text. The <att>n</att> attribute on each <gi>div1</gi> and
 <gi>div2</gi> 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 <gi>lb</gi> elements, each of which includes the
   through line number in Casaubon’s edition as the value of its
 <gi>n</gi> 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
 <gi>n</gi> values from the <gi>text</gi>, <gi>div1</gi>, or
 <gi>div2</gi> and calculating the line number within each part.</p>
</refsDecl>

この方法では最初に多大な努力を費やす必要が生じることが多いが、非常に柔軟な対応を可能にしている。詳しくは、セクション16.2.5正規参照を参照すること。

• <cRefPattern> (標準的な参照パターン[canonical reference pattern]) URIへの標準的参照を変形する、表現・変形パターンを示す．

この方法は、必要な参照情報を提供できるのが「マイルストーン」タグ（セクション3.10.3マイルストーンの要素を参照）のみである場合に適している。前節で説明した検索置換参照法では真似できる機能しか提供していないが、適用される場合には、比較的簡素化された表記法を提供できている。

マイルストーンタグに基づく参照は、1つ以上のタグで指定された値を連結する。各タグは値が変更されるポイントを示しているので、変数のrefStateを指定しているとみなすことができる。そのため、本方法を採用した参照宣言は、正規参照の個々の構成要素を一連のrefState要素として指定する。

• <refState> (参照状態[reference state]) マイルストーン要素の手法として定義されている標準的な参照の構成要素をひとつ示す．

• att.milestoneUnit は特定のマイルストーンにおいて変更されているセクションの種類を示す属性を提供する。

例えば、参照「Matthew 12:34」（マタイによる福音書12章34節）は、3つの変数の状態を表していると考えられる – 本の変数bookの変数は「Matthew」の状態にあり、章の変数chapterは「12」の状態にあり、節の変数verseは「34」の状態にある。マイルストーンタグが使用されている場合、上記の「変数」のそれぞれがその状態を変化させた時点を示すタグがテキスト内にあるはずである。⁴したがって、「Matthew 12:34」を見つけるためには、アプリケーションはテキストを左から右へスキャンし、これら3つの変数のそれぞれの状態の変化を監視する必要がある。3つの変数が同時に必要な状態になった際、目的のポイントに到達したことになる。もちろん、そのようなポイントはいくつかある可能性がある。

@delim属性と@length属性は、前節で説明したステップワイズ法と全く同じ方法で、この方法を使用して正規参照の構成要素を指定するために用いる。その他の属性は、テキスト内のmilestoneタグのどのインスタンスが状態変化をチェックするかを決定するために用いられる。状態変化は、新しいmilestoneタグが、@unit属性と、任意で当該のrefState要素の属性と同一の@ed属性を持つものが見つかるたびに通知される。新しい状態の値は、milestone要素の@n属性によって明示的に与えられる場合もあれば、@n属性が指定されていなけれは暗示的に与えられることもある。

例えば、xx.yyy形式の正規参照の場合、xxは初版のページ番号、yyyはこのページ内の行番号を表し、以下のような参照システム宣言が適切であろう。

<refsDecl>
 <refState ed=”first” unit=”page” length=”2″
  delim=”.”/>
 <refState ed=”first” unit=”line” length=”3″/>
</refsDecl>

bibliography 

これは、マイルストーンタグの形式が次の通りであることを示唆している。

<milestone n=”II” ed=”first” unit=”page”/>
<milestone ed=”first” unit=”line”/>

bibliography 

この形式がテキスト全体で確認され、ページ数や行数が変更した位置をマークしている。上述の2つ目のマイルストーンタグの@n属性では値が設定されていない点に注目していただきたい。これは、各状態変化におけるその値が単調に増加していることを意味している。マイルストーンタグの使用に関する詳細についてはセクション3.10.3マイルストーンの要素を参照すること。

マイルストーンの参照スキームは概念的には単純であるが、一般的なXMLパーサーでは対応していない。この方式を使用すると、エンコーダーに検証と精度の負担が大きくなる。

複数のテキストやテキストの分割に適用される参照システム宣言は、各テキストのヘッダーで繰り返す必要はない。その代わり、宣言が適用される各テキスト（又はテキストの下位区分）の@decls属性は、セクション15.3テキストと文脈情報の関連付けで詳しく説明しているように、そのテキストへの相互参照を提供するために使用してもよい。

classDecl要素は、ヘッダーの他の部分や文書内の他の場所で使われている記述的分類スキームの定義やソースをまとめるために用いられている。このような各スキームは、単純な書誌引用又は当該記述的類型論の定義のいずれかを含むことができるtaxonomy要素によって表される。記述的分類スキームを定義する際には、次の要素を用いる。

• <classDecl> (分類宣言[classification declarations]) 当該テキスト中で使用されている分類コードを定義する、ひとつ以上の分類法を示す．
• <taxonomy> テキストの類型を、書誌引用情報で暗示的に、又は構造化された分類法で明示的に定義する．
• <category> 記述的な分類項目を示す．利用者が定義した分類法の元に上位分類項目中にネストしてもよい．
• <catDesc> (カテゴリの記述[category description]) テキスト分類や分類法における分類項目を示す．簡単な散文記述またはTEI のtextDescで使用される状況パラメータで示される．

taxonomy要素は、2つのわずかに異なりつつも関連する機能を持っている。デューイや他の出版された記述的シソーラスのような、広く認知され文書化されている公的な分類スキームについては、特定の分類法の完全な記述がどこで見つかるかを示す書誌引用を単純に含んでいる。

<taxonomy xml:id=”DDC12″>
 <bibl>
  <title>Dewey Decimal Classification</title>
  <edition>Abridged Edition 12</edition>
 </bibl>
</taxonomy>

あまりアクセスしにくいスキームでは、taxonomy要素は、分類法自体の記述と、オプションの書誌引用を含む。説明は、いくつかのcategory要素によって構成されており、それぞれが与えられた諸類型内の単一のカテゴリーを定義する。カテゴリは、ネストしたcatDesc要素の内容によって定義され、カテゴリを記述するフレーズや、model.catDescPartクラスから取得した任意の数の要素のいずれかを含むことができる。コーパスモジュールがスキーマに含まれている場合、このクラスはtextDesc要素を提供し、そのコンポーネントは「状況パラメータ」のセットの観点からテキストタイプの定義を可能にする（セクション15.2.1テキストの記述を参照すること）。コーパスモジュールがスキーマに含まれていない場合、クラスは空となり、catDesc要素はプレーンテキストのみを含むことができる。

カテゴリが下位区分へ分割されている場合、各下位区分は、同じ構造を持つネストしたcategory要素で表現される。分類法の階層構造を反映するために、カテゴリは任意の深さまでネストすることができる。各category要素は一意の@xml:id属性を持ち、それを参照するcatRef要素の対象として使用される。

<taxonomy xml:id=”b”>
 <bibl>Brown Corpus</bibl>
 <category xml:id=”b.a”>
  <catDesc>Press Reportage</catDesc>
  <category xml:id=”b.a1″>
   <catDesc>Daily</catDesc>
  </category>
  <category xml:id=”b.a2″>
   <catDesc>Sunday</catDesc>
  </category>
  <category xml:id=”b.a3″>
   <catDesc>National</catDesc>
  </category>
  <category xml:id=”b.a4″>
   <catDesc>Provincial</catDesc>
  </category>
  <category xml:id=”b.a5″>
   <catDesc>Political</catDesc>
  </category>
  <category xml:id=”b.a6″>
   <catDesc>Sports</catDesc>
  </category>
 </category>
 <category xml:id=”b.d”>
  <catDesc>Religion</catDesc>
  <category xml:id=”b.d1″>
   <catDesc>Books</catDesc>
  </category>
  <category xml:id=”b.d2″>
   <catDesc>Periodicals and tracts</catDesc>
  </category>
 </category>
</taxonomy>

このような分類内での特定のテキストとカテゴリの間における繋がりはtextClass要素にあるcatRef要素によって実現しているが、これはセクション2.4.3テキストの分類で説明している通りである。さらに粒度の細かい分析が望まれる場合は、次の省略された例の通り、テキスト内の要素の@ana属性をカテゴリに向けることができる。

<taxonomy>
 <category xml:id=”poe”>
  <catDesc>Poetry</catDesc>
  <category xml:id=”sonn”>
   <catDesc>Sonnet</catDesc>
   <category xml:id=”shakesSonn”>
    <catDesc>Shakespearean Sonnet</catDesc>
   </category>
   <category xml:id=”petraSonn”>
    <catDesc>Petrarchan Sonnet</catDesc>
   </category>
  </category>
  <category xml:id=”met”>
   <catDesc>Metrical Categories</catDesc>
   <category xml:id=”ft”>
    <catDesc>Metrical Feet</catDesc>
    <category xml:id=”iamb”>
     <catDesc>Iambic</catDesc>
    </category>
    <category xml:id=”troch”>
     <catDesc>trochaic</catDesc>
    </category>
   </category>
   <category xml:id=”ftNm”>
    <catDesc>Number of feet</catDesc>
    <category xml:id=”penta”>
     <catDesc>>Pentameter</catDesc>
    </category>
    <category xml:id=”tetra”>
     <catDesc>>Tetrameter</catDesc>
    </category>
   </category>
  </category>
 </category>
</taxonomy>
<!– elsewhere in document –>
<lg ana=”#shakesSonnet #iamb #penta”>
 <l>Shall I compare thee to a summer’s day</l>
<!– … –>
</lg>

bibliography 

分類体系が1つ以上の次元に沿った分類を許容している場合、上記で定義した「Press Reportage」カテゴリに含まれている「Daily」「National」「Political」の各下位カテゴリを用いてテキストを識別している次の例のように、特定のcatRefが複数のカテゴリを参照する。

<catRef target=”#b.a1 #b.a3 #b.a5″/>

bibliography 

単一のcategoryには子であるcatDescが複数含まれていることもある。この例としては、カテゴリが複数の言語によって記述されている場合が考えられ、下記に記述例を示している。

<category xml:id=”lit”>
 <catDesc xml:lang=”pl”>literatura piękna</catDesc>
 <catDesc xml:lang=”en”>fiction</catDesc>
 <category xml:id=”litProza”>
  <catDesc xml:lang=”pl”>proza</catDesc>
  <catDesc xml:lang=”en”>prose</catDesc>
 </category>
 <category xml:id=”litPoezja”>
  <catDesc xml:lang=”pl”>poezja</catDesc>
  <catDesc xml:lang=”en”>poetry</catDesc>
 </category>
 <category xml:id=”litDramat”>
  <catDesc xml:lang=”pl”>dramat</catDesc>
  <catDesc xml:lang=”en”>drama</catDesc>
 </category>
</category>

以下の要素は、テキスト内で特定の座標記法または特定のデータが採用されていることを（文書のヘッダー内で、または外部の場所で）示すために提供されている。デフォルトの記法は、空白で区切られた2つの実数を含む文字列であり、1984年世界測地系（WGS84）に従った緯度と経度を示している。

• <geoDecl> (地理座標の宣言[geographic coordinates declaration]) 当該文書中のgeo要素の内容として表現される地理的座標のための表記法と測地系を示す．

文書が国際単位系にリストされていない測定単位を使用している場合、その定義と起源および等価物に関する情報を提供するために、符号化記述の中でunitDecl要素を使用することができる。

• <unitDecl> (単位宣言[unit declarations])は国際単位系に属していない測定単位に関する情報を提供している。

unitDeclはtext内のunit要素でマークされることがある測定単位を記述するのに役立つ1つ以上のunitDef子要素を含む。

• <unitDef> (単位定義[unit definition]) は特定の測定単位に関連する記述情報を含む。
• <unit>はあらゆる種類の公式または非公式なシステムにおける測定単位を参照する記号、単語または語句を含む。
• <conversion>はある測定単位を別の測定単位で計算する方法を定義する。

• att.formula 数式を定義する上で用いる属性を提供する。

unitDef内で、単位間の変換に関連する情報を格納するためにconversion要素を使用することができる。conversion要素は、特別な属性のペアである@fromUnitと@toUnitを保持しており、これらの属性は、(@fromUnitに格納されている）ある単位から（@toUnitに格納されている）別の単位への計算の方向を示すのに役立つ。これらの単位間の関係を定義するための数学的計算は、以下の例に示すように、@formulaに格納していてもよい。@formula属性はXPathで表現された値を取り、パスナビゲーションで使用される前方スラッシュと混同されないように、区分は「div」で表現されなければならないことを意味する。

<encodingDesc>
 <unitDecl>
  <unitDef xml:id=”keel” type=”weight”>
   <label>keel</label>
   <placeName ref=”#england”/>
   <conversion fromUnit=”#chalder”
    toUnit=”#keel” formula=”$fromUnit * 20″ from=”1421″
    to=”1676″/>
   <conversion fromUnit=”#chalder”
    toUnit=”#keel” formula=”$fromUnit * 16″ from=”1676″
    to=”1824″/>
   <desc>Keel was a unit measuring weight of coal. It had been equal to 20 chalders from 1421 to 1676, and it was made to be equivalent to 16 chalders from 1676 to 1824.</desc>
  </unitDef>
  <unitDef xml:id=”chalder” type=”weight”>
   <label>chalder</label>
   <placeName ref=”#england”/>
   <conversion fromUnit=”#bushel”
    toUnit=”#chalder” formula=”$fromUnit * 32″ from=”1421″
    to=”1676″/>
   <conversion fromUnit=”#bushel”
    toUnit=”#chalder” formula=”$fromUnit * 36″ from=”1676″
    to=”1824″/>
   <desc>Chalder was a unit measuring weight of coal. It had been equal to 32 bushels from 1421 to 1676, and it was made to be equivalent to 36 bushels from 1676 to 1824.</desc>
  </unitDef>
  <unitDef xml:id=”bushel” type=”weight”>
   <label>bushel</label>
   <placeName ref=”#england”/>
   <desc>Bushel was a unit measuring weight of coal.</desc>
  </unitDef>
 </unitDecl>
</encodingDesc>

bibliography 

<encodingDesc>
 <unitDecl>
  <unitDef xml:id=”Celsius”
   type=”temperature”>
   <label>Celsius or Centigrade scale</label>
   <conversion fromUnit=”#Fahrenheit”
    toUnit=”#Celsius” formula=”($fromUnit – 32) * (5 div 9)”/>
   <desc>To convert from the Fahrenheit to the Celsius scale, subtract 32 from the Celsius temperature and multiply by 5/9.</desc>
  </unitDef>
 </unitDecl>
</encodingDesc>

bibliography 

schemaSpec要素はスキーマの仕様を包含している。この要素がencodingDescの中に現れると、TEI ODDカスタマイズファイルをTEIヘッダーの中に埋め込むことができる。代替方法としては、本要素をODDドキュメントのbodyで用いることも可能である。ODDファイルの使用とスキーマとの関係については第22章 文書化の要素で詳しく説明している。

schemaSpec要素には、特定のTEIカスタマイズのためのスキーマを生成するために必要なすべての情報が含まれており、TEIを参照することで、ODDドキュメント要素はそこから派生したスキーマよりも簡潔になる。そのため、外部スキーマやODDファイルを提供するだけでなく、プロジェクトのODDドキュメントからteiHeader自体の中にschemaSpecのコピーを作成しておくと便利になる。XML ファイルがスキーマから分離された場合、スキーマはschemaSpec要素の情報を使っていつでも再生成することができる。例えば:

<encodingDesc>
<!– Other encoding description elements… –>
 <schemaSpec ident=”myTEICustomization”
  docLang=”en” prefix=”tei_” xml:lang=”en” source=”#NONE”>
  <moduleRef key=”core”/>
  <moduleRef key=”tei”/>
  <moduleRef key=”header”/>
  <moduleRef key=”textstructure”/>
 </schemaSpec>
</encodingDesc>

bibliography 

または、schemaRef要素を用いて外部ODDカスタマイズファイルやスキーマを指定することも可能である。異なるソースやワークフローの段階、あるいは形式に対しschemaRef要素を1つ以上提供することができる。

<schemaRef type=”interchangeODD”
 url=”http://www.tei-c.org/release/xml/tei/custom/odd/tei_lite.odd”/>
<schemaRef type=”interchangeRNG”
 url=”http://www.tei-c.org/release/xml/tei/custom/odd/tei_lite.rng”/>
<schemaRef type=”projectODD”
 url=”file:///schema/project.odd”/>

bibliography 

@url属性は、prefixDefが文書化している私用URI構文を含め、如何なるURIポインターの形式を取ってもよい。

符号化されたリソースの処理に関連する情報をそのヘッダー内に格納しておくと便利な場合がある。そのような情報の典型的な用途は次のようなものである。

• アプリケーションが以前にファイルを開いたり編集したりしたことを発見できるようにし、そのためにどのバージョンのアプリケーションが使用されたかを知ることができるようにする。
• どのアプリケーションが最後にファイルを編集したかを(日付を通して)表示し、そのアプリケーションによって引き起こされたかもしれない問題の診断を可能にする。
• ユーザーがファイルを編集するために使用されたアプリケーションに関する情報を発見できるようにする。
• アプリケーションが編集したファイルの要素に対して利害関係を宣言することを許可することによって、他のアプリケーションや人間の編集者がファイルのその部分に対する変更についてより慎重になるように促す。

model.applicationLikeクラスではapplicationを提供し、appInfo要素内の情報を記録するために用いられている。

• <appInfo> (アプリケーション情報[application information]) TEIファイルを編集したアプリケーションに関する情報を記録する．
• <application> 当該文書に作用するアプリケーションに関する情報を示す．

各application要素はカレントファイルについてソフトウェア・アプリケーションの現在の状態を特定する。この要素はatt.datableクラスのメンバーであり、日時や時間的な範囲と状態を関連づける様々な属性を提供している。@ident属性と@version属性も用いてアプリケーションとその主なバージョン番号を一意に識別すべきである（例えばImageMarkupTool 1.5）。ファイルに触るごとに新たなapplicationをアプリケーションを追加すべきということは意図していない。

以下の例では、「Image Markup Tool」と呼ばれるアプリケーションのバージョン1.5が2006年6月6日に最後に保存された文書において2箇所について利害関係がある場合にこれらの要素をどのように活用し記述できるのかを示している。関心対象となっている部分は2つのptr要素がターゲットとして設定しているURLよりアクセスできる。

<appInfo>
 <application version=”1.5″
  ident=”ImageMarkupTool” notAfter=”2006-06-01″>
  <label>Image Markup Tool</label>
  <ptr target=”#P1″/>
  <ptr target=”#P2″/>
 </application>
</appInfo>

これまでに説明した要素は、どのスキーマでも利用可能である。使用しているスキーマに特殊なTEIモジュールが含まれている場合、これらの要素を使用することで、符号化記述の他のモジュール固有のコンポーネントを利用できるようになる。これらについては、問題のモジュールの文書で詳しく説明しているが、便宜上、ここでも簡単に説明している。

fsdDecl要素はiso-fsモジュールがスキーマに含まれている場合にのみ利用可能である。この要素の目的は、ヘッダーによって文書化されたテキストの中に存在する分析的素性構造（第18章素性構造で定義している）の基礎となる素性システム宣言（セクション18.11素性システムの宣言で定義している）を文書化することである。

metDecl要素は、verseモジュールがスキーマに含まれている場合にのみ利用可能である。その目的は、セクション6.4押韻と韻律分析でさらに議論されているように、テキストで使用されるあらゆる計量記法スキームを文書化することである。これは、散文の記述または一連のmetSym要素のいずれかで構成されている。

variantEncoding 要素はtextcritモジュールがスキーマに含まれている場合にのみ利用可能である。その目的は、セクション12.2校勘情報とテキストのリンクで説明したように、テキスト中のテキストバリアントをエンコードするために使用される方法を文書化することである。

profileDesc要素はTEIヘッダーにおける3つ目の主要な下位区分である。これは任意の要素であり、テキストまたはコーパスの様々な記述的観点を特徴づける情報を単一の単体フレームワークにおいて記録できるようにすることを目的として設けられている。

• <profileDesc>(テキストプロファイル記述[text-profile description]) テキストの、書誌情報的ではない詳細な解説を示す．例えば、言語や特殊言語、生成されたときの状況、参加者など．

原則として、ヘッダーにおけるほぼ全ての構成要素は、テキストを特徴づける手段として重要であると考えることができる。文章の著者、そのタイトルまたは出版日はすべて、少なくとも本節で論じたいずれかのパラメータと同程度に、その文章を特徴づけるものと捉えることができる。ここで適用している経験則は、情報がすでにTEI ヘッダーの他の場所に含まれているため、一般的に標準的な書誌スタイル記述の一部を形成する情報の大部分をここでの説明から除外することを意図している。

profileDesc要素にはmodel.profileDescPartクラスから取得した要素も含まれている。本クラスにデフォルトで含まれているメンバーは以下の通りである。

• <abstract> 符号化する者によって既存のソース文書の前に付加された要約または形式的な概要を含む．
• <creation> テキストの作成に関する情報を示す．
• <langUsage> (使用言語[language usage]) テキスト中にある言語、特殊言語、言語使用域、方言などを示す．
• <textClass> (テキストの分類[text classification]) 標準的な分類スキーム、分類語彙などにより、テキストの性格や話題を示す情報をまとめる．
• <correspDesc> (通信の記述[correspondence description]) 1回分の通信行為に関係する行動に関する記述を含んでいる．
• <calendarDesc> (暦の記述[calendar description]) テキスト内に含まれている日時の表現に用いられている暦の体系の記述を含んでいる．

これらの要素は本節の残りでさらに詳しく説明する。

corpusモジュール（第15章言語コーパスで説明）をスキーマに含める場合、profileDesc要素内においてさらに3つの要素が利用可能になる。

• <textDesc> (テキストの記述[text description]) 状況パラメータに関するテキストの情報を示す．
• <particDesc> (参加の記述[participation description]) あらゆる種類のテキストにおける、言語交流での、特定可能な発話者、声、その他の参加者、もしくは、名前を呼ばれた、或いは、テキスト、エディション、又はメタデータにおいて言及された人物を記述する．
• <settingDesc> (設定の記述[setting description]) 言語交流が行われた状況設定、もしくは、言語交流が行われなければ、テキスト、エディション、又はメタデータの中で言及された別の場所を記述する．

これらの要素に関する記述についてはセクション15.2文脈情報を参照すること。

一次情報源の転写に関するtranscrモジュール（第11章一次情報源の表現で記述）をスキーマに含める場合、profileDesc要素内においてさらに以下の要素が利用可能になる。

• <handNotes>ソーステキストにある特定された異なる筆致を記録する、ひとつ以上の handNote要素を示す．
• <listTranspose> 転置の一覧を供給し、それぞれが一般的にメタ記号を通じて文書における箇所を示す．

handNotes要素の説明についてはセクション11.3.2.1筆跡を参照すること。この目的は、いくつかのhandNote要素をグループ化することであり、それぞれが写本内で識別された異なる手または同等のものを記述している。handNote要素は、msdescriptionモジュール（第10章手稿本の記述で説明）がスキーマに含まれている場合、構造化された手稿本の説明の中にも現れることができる。このため、handNote要素は実際にはヘッダモジュール内で宣言されるが、スキーマにアクセスできるのはtranscrモジュールまたはmsdescriptionモジュールのいずれかがスキーマに含まれている場合のみである。セクション11.3.2.1 文書における手における説明も参照すること。

listTranspose要素についてはセクション11.3.4.5転置で詳しく述べている。

creation要素はテキストの起源を記述するフレーズ、例えばそれが構成された日付と場所といった情報を含んでいる。

• <creation> テキストの作成に関する情報を示す．

構成の日付と場所は、言語的変種の研究にとって特に重要であることが多い。このような情報は、コピーテキストの書誌記述からは確信を持って推測することができないので、この情報のための一貫した場所を提供するためにcreation要素を使用してもよい。

<creation>
 <date when=”1992-08″>August 1992</date>
 <rs type=”city”>Taos, New Mexico</rs>
</creation>

langUsage要素はprofileDesc要素内で用い、テキスト内で確認されている言語、特殊言語、言語使用域、方言等を記述している。language要素を1つ以上含んでおり、それぞれが単一の言語に関する情報、特にテキスト内の当該言語の量について提供している。この要素はその言語で用いられる非標準文字やグリフに関する情報を提供するために用いるべきではない点に注意していただきたい。そのような情報は、符号化記述の中のcharDecl要素に記録されるべきである（詳しくは第5章 文字、グリフ、書字モードを参照）。

• <langUsage> (使用言語[language usage]) テキスト中にある言語、特殊言語、言語使用域、方言などを示す．
• <language> テキスト中にあるひとつの言語または特殊言語を示す．

language要素は文書内に含まれている各言語に対して提供できる。これを用いる場合には、@ident属性の適切な言語識別子を指定すべきである（セクションvi.1 言語の識別で詳しく述べている）。これは、拡張した言語識別子が@xml:lang属性の値として文書内の別の箇所で用いられている場合には特に重要になる。

以下の本要素の使用に関する例を示す。

<langUsage>
 <language ident=”fr-CA” usage=”60″>Québecois</language>
 <language ident=”en-CA” usage=”20″>Canadian business English</language>
 <language ident=”en-GB” usage=”20″>British English</language>
</langUsage>

textClass要素は何らかの形でテキストを分類するために用いる。

• <textClass> (テキストの分類[text classification]) 標準的な分類スキーム、分類語彙などにより、テキストの性格や話題を示す情報をまとめる．

テキストの分類は、以下のいずれかの方法で行うことができる。

• デューイ十進分類、万国十進分類、コロン分類、米国議会図書館分類、または図書館や文書化作業で広く使用されているその他のシステムなど、国際的に認められている分類を参照すること。
• 例えば、大英図書館や米国議会図書館の出版物目録データで提供されているように、キーワードのセットを提供することによる方法
• 当該分野で認識されているその他のテキストカテゴリの分類法や手元の資料の観点からは珍しい方法。セクション15.2.1 テキストの記述で定義されている状況パラメータやセクション15.2.2 参加者の記述で説明されている人口統計学的要素に対する反復的な値のセットに基づくものが含まれる。

これらのうち最後のものは、既存のコーパスやコレクションを扱う上で特に重要で、再分類にかかるコストや不便さを避けるための手段としても、そのような資料の構成原理を文書化するための手段としても重要である。

この目的のため、以下の要素が提供されている。

• <keywords> テキストの話題や性格を特定するキーワードや句のリストを示す．

• <classCode> (分類コード[classification code]) 当該テキストで使用されている、ある分類体系の規格に従った分類コードを示す．

• <catRef> (カテゴリ参照[category reference]) 分類法やテキスト類型論の中で定義されたひとつ以上の分類項目を特定する．

keywords要素は、そのトピックや主題、形式、日付などを記述するキーワードのリストを与えることで、個々のテキストを単純に分類している。いくつかのスキーマでは主要なトピックからマイナーなものへといったようにリスト内の項目の順序が重要であり、他のスキーマでは、リストが独自の組織化された下位構造を有している。どの方法が好ましいかについては、ここでは推奨はしない。可能な限り、そのようなキーワードは、印刷された書籍の場合は大英図書館や米国議会図書館の出版物目録データや、その分野に適した出版されたシソーラスなど、認知された情報源から取得することが望ましい。

@scheme属性は、そのような情報源が存在する場合には、使用されるキーワードの情報源を示すために用いられる。キーワードがオンラインで利用可能な外部に定義された典拠から取得したものである場合は、次の例のように、本属性はそれを直接指すべきである。

<keywords scheme=”http://classificationweb.net”>
 <term>Babbage, Charles</term>
 <term>Mathematicians – Great Britain – Biography</term>
</keywords>

<keywords scheme=”http://id.loc.gov/authorities/about.html#lcsh”>
 <term>English literature — History and criticism — Data processing.</term>
 <term>English literature — History and criticism — Theory, etc.</term>
 <term>English language — Style — Data processing.</term>
 <term>Style, Literary — Data processing.</term>
</keywords>

権威ファイルがオンラインで利用できないものの一般的に認識されており引用されている場合は、taxonomy要素（セクション2.3.7分類の宣言で説明）の中で、そのための書誌記述を提供することが望ましい。@scheme属性は通常の方法でその識別子を用いてtaxonomy要素を参照してもよい。

<keywords scheme=”#welch”>
 <term>ceremonials</term>
 <term>fairs</term>
 <term>street life</term>
</keywords>
<!– elsewhere in the document –>
<taxonomy xml:id=”welch”>
 <bibl>
  <title>Notes on London Municipal Literature, and a Suggested
     Scheme for Its Classification</title>
  <author>Charles Welch</author>
  <edition>1895</edition>
 </bibl>
</taxonomy>

使用されたキーワードが作成者によって直接割り当てられていたなどの理由のため権威ファイルが存在しない場合は@scheme属性は省略されるべきである。

または、キーワードの語彙自体が局所的に定義されている場合、@scheme属性は局所的な定義を指すが、これは通常符合化記述におけるclassDeclクラスのtaxonomy要素に保持されている（セクション2.3.7分類の宣言を参照）。

また、classCode要素は記述的な用語ではなく数値又は他のコードを与えることによって、個々のテキストを分類する。このようなコードは、デューイ十進分類のような認識された分類スキームを構成する。この要素では、@scheme属性が必須であり、キーワードの場合と同様に、分類スキームのソースを示している。これは上述のkeywordsの例のようにTEI要素へ、または次の例のようにスキームの標準的なソースへ向いているポインターが考えられる。例えば、

<classCode scheme=”http://www.udcc.org/udcsummary/php/index.php”>005.756</classCode>

catRef要素はatt.pointingクラスから継承した@target属性を用い、1つ以上のcategory要素を指すことによって個々のテキストを分類する。category要素（セクション2.3.7分類の宣言で詳しく説明している）は与えられた分類法における特定の分類又は分類に関する情報を保持している。そのような各カテゴリは、一意な識別子を持たなければならず、それは、示されたカテゴリ内に属するとみなされるcatRef要素のための@target属性の値として与えられてもよい。

もちろん、テキストは1つ以上のカテゴリに入ることがあり、その場合、以下の例のように、catRef要素の@target属性の値として複数の識別子を提供することがある。

<catRef target=”#b.a4 #b.d2″/>

bibliography 

指しているリソースによって適切に伝わっていない場合は、@scheme属性は、@target属性によって識別されたカテゴリが属する分類体系を指定するために提供してもよい。例を挙げる。

<catRef target=”#b.a4 #b.d2″
 scheme=”http://www.example.com/browncorpus”/>
<catRef target=”http://www.example.com/SUC/#A45″/>

bibliography 

ここでは、Brown分類スキーム（http://www.example.com/browncorpusより利用可能と仮定）内のカテゴリb.a4とb.d2として同じテキストを分類しており、指定のURLにおいて文書化されているSUC分類スキーマでは「A45」カテゴリとして分類している。

一般的に、@target値に複数の識別子を持つ単一のcatRefを使用するか、@target値に単一の識別子を持つ複数のcatRef要素を使用するかはスタイルの問題である。ただし、1つの@target内に多数の値を持つTEI文書のメンテナンスは煩雑であることに注意すべきである。

catRef要素とclassCode要素の違いは、識別コードとして使用される値が、前者の場合、通常はTEIヘッダー内で網羅的に列挙されていることである。しかし、後者の場合、値は外部で定義された任意のスキームを使用するため、より自由度の高い記述的分類システムから取得することができる。

abstract要素の主な目的は、元の出版物に要旨が伴っていない場合に記事の簡単な要約または要旨を提供することである。文書の生成時にその一部を形成している要旨や要約は通常は文書の前付 (front) に現れる。

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

要旨は複数の言語で提供することができ、@xml:lang属性によって区別する。

<profileDesc>
 <abstract xml:lang=”en”>
  <p>The recent archaeological emphasis
     on the study of settlement patterns,
     landscape and palaeoenvironments has
     shaped and re-shaped our understanding
     of the Viking settlement of Iceland.
     This paper reviews the developments
     in Icelandic archaeology, examining
     both theoretical and practical advances.
     Particular attention is paid to new
     ideas in terms of settlement patterns
     and resource exploitation. Finally,
     some of the key studies of the ecological
     consequences of the Norse
  <foreign xml:lang=”is”>landnám</foreign>
     are presented. </p>
 </abstract>
 <abstract xml:lang=”fr”>
  <p>L’accent récent des
     recherches archéologiques sur l’étude des
     configurations spatiales des colonies, de la
     géographie des sites ainsi que des éléments
     paléo-environnementaux nous mène à réexaminer
     et réévaluer nos connaissances acquises sur
     la colonisation de l’Islande par les Vikings.
     Cet article passe en revue le développement
     de l’archéologie islandaise en examinant les
     progrès théoriques et pratiques en la matière.
     Une attention particulière est portée sur
     l’étude des configurations spatiales des
     colonies ainsi qu’une considération des
     questions d’exploitation des ressources.
     Finalement, l’article présente un aperçu des
     études principales qui traitent des
     conséquences écologiques du
  <foreign xml:lang=”is”>landnám</foreign>
     islandais.</p>
 </abstract>
</profileDesc>

符号化する者が供給した他の要約情報を提供する目的でも同じ要素を用いることができ、別々の項目としてまとめてリスト化することもできる。

<profileDesc>
 <abstract>
  <list>
   <item>An annual HBC supply ship is
       set to the North West Coast for mid-September.</item>
   <item>
    <name key=”pelly_jh”>Pelly</name> writes
       to ascertain the British Government’s plans
       for the lands associated with the Oregon Treaty;
       he wants to know what will happen to the HBC’s
       establishment on the southern <name type=”place”
     key=”vancouver_island”>Vancouver Island</name>.
       He adds that a former Crown grant, an 1838 exclusive
       trade-grant for the lands in question, has yet to
       expire.</item>
   <item>The minutes discuss the nature of the HBC’s
       original entitlements and question whether or not,
       and in what capacity, the Oregon Treaty affects the
       HBC’s position. The majority council further
       investigation, and to reply cautiously and
       judiciously to the HBC inquiry.</item>
   <item>A
       summary of a meeting with <name key=”pelly_jh”>Pelly</name> is offered in
       order to elucidate the HBC’s intentions.</item>
   <item>
    <name key=”grey_hg”>Lord Grey</name> calls
       for greater consideration on the issue of
       colonization; he asks that <name key=”stephen_j”>Stephen</name> write the Company,
       asking them to detail their intentions, and to
       state their legal opinion for entitlement.
   </item>
  </list>
 </abstract>
</profileDesc>

calendarDesc要素はprofileDesc要素の中で、dateの@calendar属性またはatt.datableクラスの任意のメンバーの@datingMethod属性のいずれかによって参照されるオブジェクトを文書化するために使用される。

• <calendarDesc> (暦の記述[calendar description]) 当該テキスト内に含まれている日時の表現に用いられている暦の体系の記述を含んでいる。

この要素は、1つ以上のcalendar要素を含むことができる。

• <calendar> 当該テキスト内の日時形式で用いられる暦または日付体系を記述する。

このような各要素は、当該暦の体系の説明の一つ以上の段落を含み、また、そのxml:id属性の値として、その暦の体系の識別コードを提供する。

<calendarDesc>
 <calendar xml:id=”Gregorian”>
  <p>Gregorian calendar</p>
 </calendar>
 <calendar xml:id=”Stardate”>
  <p>Fictional Stardate (from Star Trek series)</p>
 </calendar>
 <calendar xml:id=”BP”>
  <p>Calendar years before present (measured from 1950)</p>
 </calendar>
</calendarDesc>

識別コードは、その暦の体系を用いて表現する日付を提供するどの要素によっても参照できる。

<p>Captain’s log <date calendar=”#stardate”>stardate 23.9 rounded off
   to the nearest decimal point</date>…</p>

teiHeaderにおけるcalendar要素と併せた日付の諸属性の使用に関する詳細についてはセクション13.3.7.4 非グレゴリオ暦の使用を参照すること。

correspDesc要素は、profileDesc要素の中で使用され、特に通信行為に関連付けられた通信的側面（送信、受信、転送など）に関する、詳細な通信固有のメタデータを提供する。

この情報は、通常、sourceDesc要素によって提供される、通信行為に関連する物理的オブジェクト（手紙など）の詳細な記述を補完するものである。

• <correspDesc> (書簡の記述[correspondence description]) 1回分の通信行為に関係する行動に関する記述を含んでいる。

correspDesc要素には、特定されたアクションと、その対応行為が発生したコンテキストをそれぞれ記述した要素correspActionとcorrespContextが含まれる。

• <correspAction> (通信行為[correspondence action])は、メッセージの送受信やその他の通信行為に関連する場所、人や組織名、日付を構造的に記述したものである。

• <correspContext> (通信の文脈[correspondence context]) 当該通信に関係し、その前後に行われた通信に対する参照を提供。

通信の行為は、一般的には互いに別々に発生することはない。correspContext要素は、記述されている通信の項目に関連する参照をグループ化するために使用され、一般的には、返信先の項目や、それに返信する項目などの他の項目への参照を提供する。

<correspContext>
 <ref type=”prev” target=”#CLF0102″>Previous letter of <persName>Chamisso</persName> to <persName>de La
     Foye</persName>: <date when=”1807-01-16″>16 January 1807</date>
 </ref>
 <ref type=”next” target=”#CLF0104″>Next letter of <persName>Chamisso</persName> to <persName>de La Foye</persName>:
 <date when=”1810-05-07″>07 May 1810</date>
 </ref>
</correspContext>

多くのタイプの対応アクションが区別されてもよい。@type属性は、上記のような値を使用して、文書化されるアクションのタイプを示すために使用されるべきである。

以下の簡単な例では、アデルバート・フォン・シャミッソが1807年1月29日にヴェルテュからカーンにいるルイ・デ・ラ・フォイ宛に手紙を送ったことを、correspActionを使用して説明している。デ・ラ・フォイが手紙を受け取った日付は不明である。

<correspAction type=”sent”>
 <persName>Adelbert von Chamisso</persName>
 <placeName>Vertus</placeName>
 <date when=”1807-01-29″/>
</correspAction>
<correspAction type=”received”>
 <persName>Louis de La Foye</persName>
 <placeName>Caen</placeName>
 <date>unknown</date>
</correspAction>

セクション3.5.4 日付と時間で説明されている@when属性を使用することで正規化された日付を提供している点に注目していただきたい。ソースを転写していないため、date要素の内容は省略することができる。

1つのcorrespActionに対して複数の送信者、受信者等を指定することができるが、その全てが1つのグループとして行動していると考えられる場合には、複数の送信者、受信者等を指定することができる。以下の例では、2名が通信内容を受信したと仮定する。

<correspAction type=”received”>
 <persName>Hermann Hesse</persName>
 <persName>Ninon Hesse</persName>
 <placeName>Montagnola</placeName>
</correspAction>

@subtype属性は、アクションのタイプをさらに区別するために使用することができる。以下の例では、電子メールを2人に直接宛て、3人目には「カーボンコピー」(cc)として送信している。

<correspAction type=”sent”>
 <persName>PN0001</persName>
 <date when=”1999-06-02″/>
</correspAction>
<correspAction type=”received” subtype=”to”>
 <persName>PN0002</persName>
</correspAction>
<correspAction type=”received” subtype=”to”>
 <persName>PN0003</persName>
</correspAction>
<correspAction type=”received” subtype=”cc”>
 <persName>PN0004</persName>
</correspAction>

同一人物が複数のアクションに関連付けられることがある。例えば、メッセージの作成者と送信者が同一である場合が多く、多くの個別の文字を同一人物に関連付ける必要がある。@sameAs属性（セクション16.6 Identical Elements and Virtual Copiesで定義）は、同じ名前が多くのアクションに適用されることを示すために使用される可能性がある。その値は、通常、文書の他の場所で提供される、関係する人や名前を定義する要素の識別子となる。

<correspAction type=”sent”>
 <name sameAs=”#author”/>
</correspAction>

bibliography 

各対応行為は、一つの通信行為に適用されると仮定している。しかし、例えば、人Aが人Bに手紙を送り、人Bがそれに注釈をつけて人Cに送る場合や、人Aと人Bが同じ文書を使って全く異なるメッセージを伝える場合など、同じ物理的なオブジェクトが複数の行為に関与している場合がある。このような場合には、通信ごとに複数のcorrespDesc要素を与える必要がある。以下の例では、同じ文書には異なるメッセージが含まれており、異なる人が同じ宛先に送信した場合には、それぞれに対応したcorrespDescを使用している。

<correspDesc xml:id=”message1″>
 <correspAction type=”sent”>
  <persName>John Gneisenau Neihardt</persName>
  <placeName>Branson (Montgomery)</placeName>
  <date when=”1932-12-17″/>
 </correspAction>
 <correspAction type=”received”>
  <persName xml:id=”JTH”>Julius Temple House</persName>
  <placeName>New York</placeName>
 </correspAction>
</correspDesc>
<correspDesc xml:id=”message2″>
 <correspAction type=”sent”>
  <persName>Enid Neihardt</persName>
  <placeName>Branson (Montgomery)</placeName>
  <date when=”1932-12-17″/>
 </correspAction>
 <correspAction type=”received”>
  <persName sameAs=”#JTH”/>
  <placeName>New York</placeName>
 </correspAction>
</correspDesc>

プロジェクトは、TEI文書に関するメタデータを複数の形式やシステムで維持することが多い。例えば、プロジェクトは、エンコードしようとする文書セットの書誌情報のデータベースを持っているかもしれない。このデータベースから、MARCレコードとteiHeaderの両方が生成される。その後、文書はエンコードされ、その間に追加の情報が手動でteiHeaderに追加される。その後、文書がウェブ上で公開されると、リソースを発見するためのダブリンコアレコードが生成される。TEI以外のメタデータの一部または全部をTEIファイルに格納することが有利な場合もある。

このような非TEIデータは、TEIへの適合性に影響を与えないため、TEIファイル内のどこにでも（ルート要素以外の）配置することができる。しかし、このようなデータは1つの場所にまとめておいた方が、人間が管理しやすくなる。さらに、このようにグループ化することで、TEIスキーマに対するファイルの検証中に、TEI以外のデータがエラーとして誤ってフラグを立ててしまうことを容易に回避することができる。fileDescの後かつ任意のrevisionDescの前にTEIヘッダーに現れるxenoData要素はこのために用意されている。

• <xenoData> (非TEIメタデータ[non-TEI metadata]) 非TEI形式のメタデータを配置できるコンテナ要素を提供している。

xenoData 要素はTEI要素以外の情報を含むことができる。TEIの外部からの1つ以上の要素⁵ または非XMLテキスト形式のデータを含めることができる。⁶

以下の例では、接頭辞 rdf は名前空間 http://www.w3.org/1999/02/22-rdf-syntax-ns# に、接頭辞 dc は名前空間 http://purl.org/dc/elements/1.1/ に、接頭辞 cc は名前空間 http://web.resource.org/cc/ にバインドされている。

<xenoData>
 <rdf:RDF>
  <cc:Work rdf:about=””>
   <dc:title>Applied Software Project Management – review</dc:title>
   <dc:type rdf:resource=”http://purl.org/dc/dcmitype/Text”/>
   <dc:license rdf:resource=”http://creativecommons.org/licenses/by-sa/2.0/uk/”/>
  </cc:Work>
  <cc:License rdf:about=”http://creativecommons.org/licenses/by-sa/2.0/uk/”>
   <cc:permits rdf:resource=”http://web.resource.org/cc/Reproduction”/>
   <cc:permits rdf:resource=”http://web.resource.org/cc/Distribution”/>
   <cc:requires rdf:resource=”http://web.resource.org/cc/Notice”/>
   <cc:requires rdf:resource=”http://web.resource.org/cc/Attribution”/>
   <cc:permits rdf:resource=”http://web.resource.org/cc/DerivativeWorks”/>
   <cc:requires rdf:resource=”http://web.resource.org/cc/ShareAlike”/>
  </cc:License>
 </rdf:RDF>
</xenoData>

TEIヘッダーの最後のサブ要素であるrevisionDesc要素は、テキストに加えられた各変更を記録するための詳細な変更ログを提供する。この使用は任意であるものの、強く推奨されるものである。これは、更新、修正、またはその他の方法で変更された大量のファイルの管理に不可欠な情報を提供し、研究者から研究者へ、またはシステムからシステムへと渡されるファイルのための非常に有用なドキュメントを提供する。変更ログがなければ、ファイルの異なるバージョンを混乱させてしまったり、頒布の連鎖の中のいくつかの初期のリンクによってファイルに加えられた小さくも重要な変更に気づかないままでいてしまうことは容易に起こりうる。変更ログに対応するエントリを作成せずに、TEI 準拠のファイルに重大な変更を加えるべきではない。

• <revisionDesc> (改訂記述[revision description]) ファイルの改訂履歴を要約する．
• <listChange> ソースのテキストの作成まはた符号化したテキストの改訂と関連する変更点の記述をグループ化する。
• <change> 研究者間で共有されている電子テキストの特定の版に対して施された変更や 修正を示す．

改訂記述の主な目的は、ヘッダーの先頭に付けられたテキストの変更を記録することである。しかし、ヘッダー自体の重要な変更についても（もちろん、改訂記述自体以外の）エントリを含めることが推奨されている。少なくとも、ヘッダの作成日を示すエントリを提供すべきである。

ログは、各変更ごとに1つのエントリのリストで構成されている。変更点はグループ化し、セクション11.7変更点と改訂の識別で説明しているlistChange要素を用いるか、セクション3.7リストで説明している単純なlist要素を用いて整理することができる。あるいは、change要素の単純なシーケンスを与えることもできる。各change要素には、その日付と責任者を示すためにそれぞれwhen属性とwho属性を与えてもよい。変更自体の説明は、単純なフレーズから複数の段落に至るまでの範囲で記述できる。番号が1つ以上の変更点に関連付いている場合(例えば、改訂番号)は、グローバル@n属性を使ってそれを示すことができる。

変更点は、時系列を逆にして最新の記入事項から順に記載することを勧める。

例えば:

<!– … –><revisionDesc>
 <change n=”RCS:1.39″ when=”2007-08-08″
  who=”#jwernimo.lrv”>Changed <val>drama.verse</val>
  <gi>lg</gi>s to <gi>p</gi>s. <note>we have opened a discussion about the need for a new
     value for <att>type</att> of <gi>lg</gi>, <val>drama.free.verse</val>, in order to address
     the verse of Behn which is not in regular iambic pentameter. For the time being these
     instances are marked with a comment note until we are able to fully consider the best way
     to encode these instances.</note>
 </change>
 <change n=”RCS:1.33″ when=”2007-06-28″
  who=”#pcaton.xzc”>Added <att>key</att> and <att>reg</att>
   to <gi>name</gi>s.</change>
 <change n=”RCS:1.31″ when=”2006-12-04″
  who=”#wgui.ner”>Completed renovation. Validated.</change>
</revisionDesc>

上述の例では、@who属性は同じヘッダー内の前方にあるtitleStmtに含まれるrespStmt要素に向いている。

<titleStmt>
 <title>The Amorous Prince, or, the Curious Husband, 1671</title>
 <author>
  <persName ref=”#abehn.aeh”>Behn, Aphra</persName>
 </author>
 <respStmt xml:id=”pcaton.xzc”>
  <persName>Caton, Paul</persName>
  <resp>electronic publication editor</resp>
 </respStmt>
 <respStmt xml:id=”wgui.ner”>
  <persName>Gui, Weihsin</persName>
  <resp>encoder</resp>
 </respStmt>
 <respStmt xml:id=”jwernimo.lrv”>
  <persName>Wernimont, Jacqueline</persName>
  <resp>encoder</resp>
 </respStmt>
</titleStmt>

しかし、この人物に対してrespStmtを使用しなければならないという要件はなく、また、示された要素が同じ文書に含まれていなければならないという要件もない。例えば、プロジェクトは、セクション15.2.2 参加者の記述に記載されているperson要素を使用して、その中で代表されたすべての要員をリストアップした別の文書を保持してもよい。

TEIヘッダーでは、テキスト自体、出典、符号化、改訂に関する非常に多くの情報と、使用言語や制作状況、参加者の設定やアイデンティティなどの豊富な記述情報を提供することができる。この多様性と豊かさは、本ガイドラインに準拠した電子テキストが想定される用途の多様性を反映するものである。上述のすべての要素がすべてのTEIヘッダーに存在しなければならないということは意図していない点は強調しなければならない。

ヘッダー内の符号化の量は、テキストの性質と意図された用途の両方に依存する。一方の極端な例では、符号化する者が現地のニーズに適切なテキストの書誌識別を提供するためだけにヘッダーが必要になることを期待しているかもしれない。他方では、自分のテキストを最も広範な用途に使用できるようにしたいと考える符号化する者は、可能な限り書誌情報と記述情報の両方を明示的に文書化し、テキストを処理するためにテキストに関する事前知識や補助的知識を必要としないようにしたいと考えるだろう。このような場合のヘッダーは非常に充実したものになり、マニュアルの形で提供されるような文書に近いものになる。ほとんどのテキストは、これらの両極端の間のどこかに位置している。本節の残りの部分では、まず最小限の符号化レベルを示し、次に、TEIヘッダーが保持する書誌情報として一般的に推奨される符号化レベルを示す。

必要最小限の符号化レベルのみを提供すると、1つのテキストに対するTEIヘッダーは以下の例のようになる。

<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>

TEIヘッダーにおいて唯一必須であるのはfileDesc要素のみである。この中で、titleStmt、publicationStmt、およびsourceDescはすべて必須の構成要素である。タイトル文の中では、タイトルは必須であり、著者はたとえ不明であっても指定されなければならず、同時に追加の責任表示もrespStmt要素を通じて提供すべきである。publicationStmtの中には、ファイルに責任を持つ出版者、頒布者、またはその他の機関を指定しなければならない。最後に、ソースの記述には、電子テキストのソースがある場合には（通常そうであるように）、その電子テキストの原典を特定する、少なくともゆるく構造化された書誌引用情報を含めるべきである。

ここでは、ほとんどの書誌を示すのに十分な、特にAACR2に準拠した書誌レコードの作成を可能にするため、推奨情報を追加的に含めるように同じヘッダーを拡張した例を示す。また、この（想像上の）符号化で使用されている符号化原則、テキストそのもの（米国議会図書館の件名見出しの形式で）、およびファイルの改訂に関する情報も追加されている。

<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”>
<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>The values of <att>when-iso</att> on the <gi>time</gi>
         element always end in the format <val>HH:MM</val> or
<val>HH</val>; i.e., seconds, fractions thereof, and time
         zone designators are not present.</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 xml:id=”lcsh”>
<bibl>Library of Congress Subject Headings</bibl>
</taxonomy>
<taxonomy xml:id=”lc”>
<bibl>Library of Congress Classification</bibl>
</taxonomy>
</classDecl>
</encodingDesc>
<profileDesc>
<creation>
<date>1774</date>
</creation>
<langUsage>
<language ident=”en” usage=”100″>English.</language>
</langUsage>
<textClass>
<keywords scheme=”#lcsh”>
<term>Political science</term>
<term>United States — Politics and government —
         Revolution, 1775-1783</term>
</keywords>
<classCode scheme=”#lc”>JC 177</classCode>
</textClass>
</profileDesc>
<revisionDesc>
<change when=”1996-01-22″ who=”#MSM”> finished proofreading </change>
<change when=”1995-10-30″ who=”#LB”> finished proofreading </change>
<change notBefore=”1995-07-04″ who=”#RG”> finished data entry at end of term </change>
<change notAfter=”1995-01-01″ who=”#RG”> began data entry before New Year 1995 </change>
</revisionDesc>
</teiHeader>

この章で述べている要素に関する推奨される使用例については、本章や参照インデックス、および関連するチュートリアルで提供している。

本章の資料を作成した強い動機は、TEIヘッダーにおいてコンピュータファイルの目録作成のための可能な主要情報源を提供することであった。TEIヘッダーは図書館の目録記録ではないため、標準的な図書館業務に不可欠なすべての区別を行うことはできない。また、標準的な書誌記述から一般的に除外されている多くの情報を含んでいる。しかし、カタログレコードに必要な情報をTEIファイルヘッダーから検索できるようにし、さらに両者の対応付けが可能な限りシンプルで簡単になるようにすることが開発者の意図である。対応が明らかでない場合は、TEIヘッダーの内容の開発に影響を与えた著作物の一つを参照することが有用である。これらには次のようなものがある。

ISBD

ISBD: International Standard Bibliographic Description（国際標準書誌記述）とは、書誌項目の記述にどのような情報を記載すべきかを定めた国際標準規格である。2011年に刊行された統合版までは、ISBD(G)と呼ばれる一般規格と、モノグラフ用のISBD(M)、電子資料用のISBD(ER)など、資料の種類ごとに分かれたISBDが存在していたが、2011年に刊行された統合版ではISBD(G)とISBD(ER)の2種類のISBDが発行された。これらのISBDは、主なISBD(G)と一般的な方式は同じであるが、検討されている資料に応じて適切な解釈がなされている。

AACR2

Anglo-American Cataloguing Rules（英米目録規則）（第2版）は1978年に発行され、2005年まで定期的に改訂が行われている。AACR2は、英語圏の一般図書館における目録作成のためのガイドラインである。AACR2は、明示的にISBD(G)とその補助であるISBDの大枠に基づいており、書誌項目の記述方法や、主題や名称の見出し、統一されたタイトルなどのアクセスポイントをどのように作成するかを記述している。他国の目録コードも存在し、その中にはAssociation française de normalisation (AFNOR)が発行しているZ44シリーズの規格、Regeln für die alphabetische Katalogisierung in wissenschaftlichen Bibliotheken (RAK-WB)、Regole italiane di catalogazione per autore (RICA)、そして、Система стандартов по информации, библиотечному и издательскому делуБиблиографическая запись. Библиографическое описание. Общие требования и правила составления (ГОСТ 7.1)などがある。

ANSI Z39.29

American National Standard for Bibliographic References（書誌参考文献の米国標準規格）は、書誌目録、作業終了リスト、出版物の抄録と索引付けにおける参考文献、およびコンピュータ化された書誌データベースからの出力に使用する書誌参考文献を規定する米国の国家規格である。改訂版は国家情報標準化機構（NISO）が維持している。関連する ISO規格は ISO690である。その他の関連する国家規格には、BS 5605:1990、BS 6371:1983、DIN 1505-2、およびГОСТ 7.0.5がある。

TEIのファイル記述要素はISBD領域に基づいているので、ファイル記述の内容をTEI文書のカタログレコードの基礎とすることは可能なはずである。しかし、TEIガイドラインの寛容な性質は、TEIファイル記述を使用する際に、AACR2や他国のカタログ作成コードの比較的厳しい推奨事項との間に乖離を生じさせる可能性があることにカタログ作成者は注意しなければならない。以下のような相違点は、TEIヘッダーからのカタログレコードの自動生成を妨げる可能性がある。

• TEIガイドラインでは、正規化された大文字と句読点を使用して「情報の主要な出典」からテキストを転記することを要求していない。
• TEIタイトルの言明は、国別目録コードで規定されているのと同じ方法で、構成タイトルを分類しなくても良い。
• TEIタイトルの言明には、著者、編集者、その他の責任者が、正規化されていない名称で別々の要素に含まれており、必ずしも単一の責任文を含むものではない。
• 典拠となるカタログレコードの主項目や追加項目（カタログレコードがファイルされている名前やタイトルの見出し）を指定する場所は、TEIヘッダーの中にはない。
• TEIヘッダーは、件名見出しに特定の語彙を使用することを要求するものではなく、同時に件名見出しの使用を要求するものでもない。

本章で説明したモジュールは以下の構成要素を提供している。

モジュール header: ヘッダーヘッダーモジュール

• 定義済み要素: abstract appInfo application authority availability biblFull cRefPattern calendar calendarDesc catDesc catRef category change classCode classDecl conversion correction correspAction correspContext correspDesc creation distributor edition editionStmt editorialDecl encodingDesc extent fileDesc funder geoDecl handNote hyphenation idno interpretation keywords langUsage language licence listChange listPrefixDef namespace normalization notesStmt prefixDef principal profileDesc projectDesc publicationStmt punctuation quotation refState refsDecl rendition revisionDesc samplingDecl schemaRef scriptNote segmentation seriesStmt sourceDesc sponsor stdVals styleDefDecl tagUsage tagsDecl taxonomy teiHeader textClass titleStmt unitDecl unitDef xenoData
• 定義済みクラス: att.patternReplacement

TEIスキーマを形成するモジュールの選定と組み合わせについてはセクションセクション1.2 TEIスキーマの定義で記述している。

1. 1969年に国際図書館連盟（International Federation of Library Associations）によって最初に提案されたこの影響力の強い規格群の詳細については、http://www.ifla.org/VII/s13/pubs/isbd.htmを参照のこと。TEI の提案と他の書誌記述の標準との関係についてはセクション2.8図書館の目録作成者向けの注記を参照すること。
2. 機械可読なファイルの目録を作成する機関に対しては、連邦議会図書館の名前権限リストのような利用可能な一般的な個人名の権限リストを使用することを推奨する。
3. TEIコーパス（第15章 言語コーパス）の場合、コーパスヘッダーのtagsDeclはコーパス全体のタグ使用状況を記述し、個々のテキストヘッダーは当該の個々のテキストのタグ使用状況を記述する。
4. milestoneタグ自体では、「変数」と呼ばれるものは@ed属性と@unit属性の組み合わせによって識別される。
5. XML文書の中で異なる名前空間からの要素を混合する場合、これらの非TEI要素の名前空間は要素自身か祖先の要素で宣言されなければならない。
6. XML 文書内でテキストを使用する場合はいつものように、特定の文字は通常の形式では使用できず、「エスケープ」しなければならない。これらの中で最も一般的なものは LESS-THAN SIGN (‘<‘, U+003C) と AMPERSAND (‘&’, U+0026) で、それぞれ < と & でエスケープすることができる。文字リファレンスを参照すること。