TEI の栞
　ガイドライン解題　（試訳）

TEI ガイドラインの栞

�T　基本的特徴と設計目標

　TEI ガイドラインがようやく草案の形で読めるようになったという公表に伴い、このリスト（＊TEI-L：メーリングリスト）は近頃多くの申し込みを受けている。TEI-L は現在、275件以上のアドレスにつながっている。600部に及ぶ草案の下刷りも、いささか多すぎて、第２版ができないうちは年内に捌けないかと初めは思われたが、この調子でいけば８月末にはすべて申し込み済みとなるだろう。

　我々はこれだけ関心を持たれていることを嬉しく思う。このことはつまり、同じテキストを様々な形で利用したり、研究者や関心をもつ人々の間でテキストを交換したり、英語以外の言葉やラテン文字以外の文字を表したりするのに適したテキスト・コーディングのための方法が今日必要であり、その方法こそ通常のテキストだけでなく、どんな種類のテキストであっても有効になると考える点で、大勢の人々が TEI の組織運営者と意見を同じくしているということなのである。

　このリストはガイドラインを改訂するうえで大きな役割を果たすことだろうし、またそれに関連した議論を開始してもらうには、我々編集者が現在の草案の背景となることをときどき話題とすること、いわばネット上での TEI チュートリアルのようなものを提供することがよいアイデアだと思われる。願わくは、これによりリスト参加者からの質問を促し、やがてはこれに類したプロジェクトにも関わる多くの技術的その他の難題を議論するところまでいきたいものだ。ここで初めに述べることのほとんどは、基本的で議論の余地がないように見える（あるいは、実際に無い）ため、才気を好む向きはただちに問題の核心に迫って、議論を開始することを望むだろう。けれども、議論の的になり得ない基本事項というものこそ、もっと手の込んだ、議論の多い問題をきちんと理解するために不可欠であると思われるので、初めはゆっくり行くことにする。好んで議論の多い論点を改めて採り上げていこうとする人も、そういう行き方を考えてよい。

　TEI 作業委員会を務めているこのリストの参加者の多くが、ちょうどよいと思うところでここでの話に積極的に身を投じ、十分に検討し、補ってくれることを願っている。

１　TEI は誰のために？

わりあい簡単なことから始めよう。
　○ TEI は誰のためにあるのか。
　○ 基本的な目標は何か。

　TEI の目標は、研究者間でテキスト資料をやり取りするのにふさわしい、直線的なデータの流れのテキストをコーディングするためのフォーマットを定義することと、どんなテキストの特徴を通常記録するのがよいかについて、これを使う人々に具体的な勧告を行うことである。冒頭（＊本文は、マニュアルの一部か。）に述べたように、TEI は「テキスト・エンコーディング・ガイドラインと文学・語学データの共通交換フォーマットを作るためのイニシアチブ」の謂である。あまり明確でない点について注記すれば、

1. TEI はテキストに関する研究、またはテキストによる研究等にコンピュータを使う人々の社会から生まれ、その人々を主な対象としている。すなわち、文学研究者・語学者・コンピュータ言語学者・歴史家・哲学者・神学者・文献学者・機械翻訳研究者等々、いろいろ名指しできよう。出版業者・データベース業者・ソフトウェア開発者、その他電子テキストに商業的利害のある人々も TEI に興味を持っており、我々と専門的知識を共有する者も多いが、これらは「第一の」対象ではない。もしも研究と出版の要求するものが異なっていたとしたら、TEI は研究者の要求に与することだろう。
   　ただし重要なのは、これがほとんど想像に類する事柄である点に注意することだ。これまでのところ、以上すべてのグループの要求は驚くほど酷似しているのだから。すこぶる具体的に言えば、私はこれまで人文学者の直面する問題で、言語学者の直面する問題と似た点のない問題にぶつかったことはないし、出版業者や商業データベース業者の直面する問題と似た点のない問題に出合ったこともない、ということだ。その逆もまた同じことである。問題は異なって見えるときもあるが、これまでの経験ではほとんどの相違はけっきょく表面的なものであった。研究者のために有効であることは他のアプリケーション（＊適用事例）にとっても有効であるはずだ。従って、実際的な意味でいえば、研究者が第一の対象ではあるが、実際に対象としているのは「あらゆる」形で電子テキストを使って仕事をし、(a) テキストを情報の取りこぼしなく一つのシステムから別のシステムに動かして、(b) テキストを一つ以上の目的で使うことを目指す人なのである。
2. ガイドラインの主な使用法の一つは、交換フォーマットの仕様を定めることである。研究者間・機械間・プログラム間・ネットワーク間での移動に当たっては、そのようなフォーマットがいとも簡単に使われるだろう。こちらのテキストが相手のところに移っていったとき、どのように見えるか、また相手のテキストがこちらに届いたとき、どのように見えてほしいかを記述したものとしてのフォーマットである。交換用フォーマットは何をコーディングするかについて触れるものではなく、それは ASCII コードが小説やマニュアルの書き方を教えないのと同じことである。コーディングされたものは研究者の知的責任の範囲であり、誰もその責任を取り去ることはできない。
3. 他の使用法としては、一般的な用途でテキストをコーディングする人々にとってのガイドとすることが挙げられる（そして人は、そのガイドがその種のコーディングされたテキストのほとんどをカバーすることを望んでいるのだ）。ガイドラインはテキストの特徴をまとめ、多くの人がテキストを使う仕事に有益であるとみなしたそのサンプル・セットをそれぞれの特徴のコーディング方法とあわせて規定するものでなければならない。それらの特徴をすべてコーディングすることは誰にも求めているわけではないにしろ、リストは（正攻法でいくなら）その集団全体が有益であると考えるようなチェックリストとしてまともに扱えるものでなければならない。

　ソフトウェア開発業者もまた、ガイドラインから二つの意味で利益を受けるものでなければならない。入出力フォーマット（または内部ファイル形式であろうとご自由に！）を定義するものであると「同時に」誰もが重要と見なす、テキストの特徴のチェックリストであるということだ。ソフトウェアの対象とする種類のテキストをメーカーが狭い範囲でとらえてしまっているためにいろいろ制約が多いことを体験した人はおそらく多いのではなかろうか。ガイドラインはソフト開発者にとっては、ブレーン・ストーミングのような、考えの幅を広げるような道具として役に立つものでなければならない。

ａ　基本的要件

　テキストのコーディング方式に対する基本的要件は、NEH （＊米国国立人文学基金）が TEI への資金供与を申し出た中で述べたものである。（ NEH 及び EEC、メロン財団[the Mellon Foundation] には緊急に資金援助を仰いだ。それなしには、これほど早く資金繰りはつかなかっただろう。）

　コーディング方式とは、テキスト・データを機械可読形式で表示し、コーディングするあらゆる（組織的な？）方法である。典型的なものとしては、コーディング方式は以下のものを含まなければならない。

1. テキスト中の文字を記録する方法（発音符 [diacritics]・特殊記号・非ローマ字母等を含む。）
2. テキストを連続した一本のデータの流れで表現するやり方（脚注・後注・研究資料・平行テキスト、その他非線形の複雑なデータをいかに扱うかを明らかにする。）
3. テキストの論理的区分を記録する方法（例えば書物・章・段落、幕・場・会話・行、等々）
4. 文学的ないし語学的分析のような分析的情報を記録する方法
5. インライン（行内）コメントと他の付随的な資料とを区切るやり方
6. コーディングしたテキストとコーディング責任者を同定するやり方

　一般的使用に適した一つのコーディング方式を作り出すために、最初に TEI はその方式を開発するための以下のような要件を定めた（1987年の企画準備会議及びそれ以後の作業文書）。

1. 共通交換フォーマットを明らかにする。
2. 新たにテキスト資料をコーディングして作るための一連の勧告を行う。
3. 既存の主要なコーディング方式を調べ、それを記述するメタ言語を開発する可能性を探る。
4. あくまでもガイドラインでなければならず、厳格な要件を集めたものであってはならない。
5. 拡張可能でなければならない。
6. ディバイスとソフトウェアに依存しない。
7. 特定言語に依存しない。
8. 特定アプリケーションに依存しない。

　設計目標としては、ガイドラインは以下の条件を満たすものでなければならないことが明らかにされた。

1. 研究に必要なテキストの特徴を表すのに十分であること。
2. 簡単・明確・具体的であること。
3. 研究者が専用のソフトウェアを使わずに利用できる平易なものであること。
4. テキストの厳密な定義としかも効果的な処理が可能であること。
5. ユーザ定義の拡張の余地があること。
6. 既存の、また新規の標準に適合すること。

　これらのことについては、もし意味が理解できなければ縷々述べてもよいが、ここでは省略する。

ｂ　現在の到達点

　現在の草案は、こうした問題のすべてを解決したり、設計目標のすべてを完全に達成したりするものでは「ない」ことに注意してほしい。それは予定にもなかったことで、難問のいくつかは次期のために意識して残してあるものだ。ここに、上述の目標に照らして到達している位置を記した個人的なチェックリストを挙げておく（別の文書からとったものであることは、重複している個所があることから分かるだろう）。

• 現在の草案（1.0版）は、予想されていたほどは恐らく明確でないにしても、交換フォーマットと勧告の両者ともに明らかにしている。交換フォーマットを定義する際にはもう少し明確にする必要があるかもしれない。
• 既存のコーディング方式の問題については継続して取り組んでいるが、文書には一切まとめていない。
• メタ言語・構文部会は、既存の方式を定義するメタ言語の定式化を実際に検討したが、定式化はしないことに決定した。記述のしかたは散文の形式、および様々な既存のソフトウェア・ツール（例えば、sed のスクリプト、Rexx 実行ファイル、Snobol プログラムから yacc や lex のコードに至るまで）を用いて、特定の方式を TEI 方式に変換するアルゴリズムの形式などになるだろう。
• 現在の版は、諸々の要求というよりは一組のガイドラインであることは確かであり、、ディバイスやソフトウェアに依存するものではない。しかしまた、ソフトウェアの形で十分実装されているわけではない。このことにより、設計が実装の問題で不正にゆがめられることがないという利点はあるが、その方式を実際に試したり検証したりすることが困難になっている。
• 拡張は可能だが、拡張を明らかにする機構は SGML という敷居の高い知識を必要とせずに利用できるようなものにする必要がある。
• どれか一つの言語に加担して、意識的に偏重したというようなことはまったくないが、すでに国際的なデータ処理標準によって非常にうまく採り上げられた以外の言葉の問題を、TEI は解決することはもちろん、表明することもまだしていない。現在の草案は、人々が最もガイダンスを必要とする主題にはまったく触れていない。例えば、ISO 標準が扱っていない、より古い形式の言葉（＊現代語でない表記）、アジアの文字、２方向に綴るテキストの処置（例えば、ヘブライ語と英語）等々である。我々は次期の２年間でこれらの主題を検討する予定だが、いくつかの問題点についてはせいぜい内容を文書化して、これらの問題を扱う既存の方法に注意を促すことができるだけである（例えば、ISO 10646 やユニコードの試みなど。この２つは中国語や他のアジア文字については不幸にも両立しない取り組みとなっている）。
• 研究上周知の要求を取り扱うために適切な「基礎」であると思われるものを規定しているのは確かだが、単に求められている解決の「基礎」だけでなく、解決法それ自体も幾通りか規定するためには、恐らく多くの分野で拡張を行う必要があるだろう。
• できうるかぎり簡単で明確なものにしたが、草案にいくらも残っている曖昧な点については意見を聞いていく予定である。（もう一度繰り返しておこう。明確でない事柄があればお知らせ願いたい。）
• 少なくとも比較的簡単なレベルでは、特別なソフトウェアを必要とせずに使えるはずである。ただし、Nota Bene や Word Perfect、Microsoft Word をふだん使い、これから TEI 準拠ファイルを作ろうとする普通の文学研究者に対して渡せるものを得るまでにはいくらもするべきことが残っている。（自発的なマクロ作成者を求む！）
• 少なくとも現在までのところ、ガイドラインは SGML を定義した ISO 標準（＊ ISO 8879：1986 ）に示された方法で使えるはずである。ただし、TEI ガイドラインを SGML の「適合アプリケーション」として定義することができないかもしれない技術的な理由がいくらかある。これらは、現在のガイドラインでは禁止している SGML の構文の自由度に主に関連している。

　TEI の基本的な目標については、こんなところである。次期の議題は、SGML の基本、コア構造の特徴を表す TEI タグ、TEI 方式における他のコア・タグ、文字コード・セットの問題等に関する討議であろう。その後、より進んだ問題を多少提出できるようになるはずである。

�U　SGML

２　SGML 紹介

　1987年に TEI が最初に定めた基本的目標の一つは、よく使われているコーディング方式によるテキストを情報の取りこぼしなく変換できるだけの表現力に富んだコーディング方式を定義することだった。これにより、すべてのコーディング方式に対して技術的な面で２つの課題が出てくる。つまり、これまで聞いたことのないテキスト分析法もタグによって表せるほど拡張可能でなければならないこと、いかなる方式でタグ付けされたテキスト区切り相互のいかなる構造的関係でも表すことができなければならないことである。

　すでに最初の企画会議の時点で、そうしたコーディング方式のために最も有望な基礎として標準汎用マーク付け言語（ISO 8879、SGML: Standard Generalized Markup Language）を提案した人が何人かいた。また、SGML は TEI の要求を満たすほど強力ではないとか、十分には理解されていない、あるいは冗長だ、素姓が疑わしい、サポートが不十分だ等々、懸念する向きもあった。この懸念がどこまで正しい指摘であるのかは時が経ってみなければ分からないが、現在の時点で、SGML ほどの受容力と応用力に迫りうる対立候補はまったく提議されていない。

　ガイドラインの第２章は、これまで SGML に触れたことのない読者向けに書かれた「やさしい SGML 入門」である。この手の入門類には SGML の起源や開発の歴史、または対立するテキスト処理モデルに対する攻撃にほとんどの手間を費すものが多い。自分たちがこうした入門書を読んできた経験から言えるのは、SGML が実際にどういうものであるのかを明快に述べるうえでこうした方法は必ずしもうまくいっていないということだ。我々は、きわめて明快な叙述を行うように努め、攻撃などはしばらく脇へおくことにしよう。

３　テキストとその構造

　ところで、SGML というのはいったい何か。そう、ちょうど Fortran やＣ、パスカルがアルゴリズムを表現できる言語であるのと同じく、SGML はテキスト構造を表現できる言語であるといってもよい。これにより、テキスト・オブジェクトの特定の型（戯曲・小説・報告書等）やその構成要素（会話・章・段落等）などの名前をつけることができる。また実際のテキスト中にこれらの型がどのような形で現れるのが正しいか（例えば、詩はスタンザを含むことができるが、段落では不可能であるなど）という決まりを述べることもできる。こうした決まりや他のタイプの決まりが組み合わさって、この世界でいわゆる文書型定義（DTD）なるものを作るわけだが、これのおかげで手頃なソフトウェアはテキストが本来の定義に適っているかをチェックしたり、テキストを解釈する際にその定義にくるまれたテキスト情報を利用したりできるようになる。

　TEI にとって、テキストは紙の上のきれいなパターン模様に並べ替えられないような無秩序な文字列の塊ではない。それはさまざまな種類のオブジェクトが織物のようにネストされたものであり、その配列と構造はテキストの理解の鍵を握る。いわば、ド・ローズ（De Rose）やその一派が最近著し、高い評価を受けた論文「テキストとは本当はどんなものか」（「高等教育におけるコンピュータ雑誌」1.2　1990、pp.3-26）で名付けたように「内容オブジェクトの秩序ある階層構造」なのである。こうして複雑な構造をもつものとしてのテキストに関心をもつことが、他のたぶんもっと知名度のあるマーク付けシステムよりも SGML を選ぶ一つの理由になっている。なぜなら、他のシステムの場合、構造的な複雑さは、それがテキストの印刷に影響を与えるかぎりにおいて、あるいはそれがテキスト検索システムから元に戻る際の正確さと回復度に影響を与えるかぎりにおいて認識されるにすぎないからだ。

　このこと（＊ SGML がテキストの複雑な構造を扱う方法）はどのようにしてなされるのか。すべてを知りたければ、他所に当たってみるしかあるまい。一通りの理解でよければ、続けて読んでもらえばよい。もし（私のように）この程度の上面の概観ならもう十二分に間に合っているという人は、どうかご海容いただき、このリストで本当に読みたいと思うものが何であるのか教えてもらいたいものだ。

４　どのようなものか

　SGML の術語では、テキスト（または文書）は内容とマーク付けから成り、特別なフラグとなる文字で区別される。テキストは、子要素またはただのテキストを含む要素から成っている。マーク付けは、内容を保持している異なった要素の境界を示す。いま読んでいるようなメールの内容を考えてみよう。これは「メッセージ」と呼ぶ一つのオブジェクトと考えられる。他のものと同じく、これには始めと終わりがあり、SGML ではこれらを区別して記号をつけなければならない。メッセージはまた、２つの部分に分けられるともいえる。すなわち、ヘッダ（頭の部分にあるネットワーク間のあらゆるおしゃべり）と本文（残りの部分）である。また、SGML ではこれら２つの構成要素の境界を区別する記号をつけなければならない。さらに、ヘッダと本文の両方（ヘッダには「発信人」「日付」「主題」等があり、本文は段落から成り、題名や署名等がある。）をさらに細かく分けることもできるだろう。

　SGML 標準は、参照の目的で、これらの境界に記号をつける一つの専用の方法を示唆している。つまり、それぞれの「例」オブジェクトのはじめに開始タグ（<例> のような感じ）を置き、終わりには終了タグ（</例> のような感じ）を置く方法である。けれども、この方法は（「規格参照具象構文（the reference concrete syntax）」なる名を冠しているが）必須のものではなく、角カッコや数字、バイナリのエスケープ文字の並び、キーボードが許せば、余白に描いた大きな赤い星印や音符でもかまわない。要素構造にはっきりとマッピングできるなら、昔ながらの句読点やレイアウト情報を使ってもかまわないのである。

　そういうわけで、SGML で（普通の場合よりもっと十分に）タグ付けすると、このメッセージの初めはこんな感じに見えるだろう。

  <message>
    <header><from>Lou</from>
            <to>Rest of World</to>
            <date>20 Aug <year>1990</year></date>
            <subject><abbrev>SGML</abbrev> - the basics</subject>
    </header>
    <body>
      <title>TEI Tutorial no 2:  SGML</title>
      <paragraph>
      <sentence>One of the <abbrev>TEI</abbrev>'s basic goals, as
      originally formulated in <date>1987</date>, was the definition
      of an encoding scheme expressive enough to allow texts in all
      widely-used encoding schemes to be translated into it without
      loss of information.</sentence> <sentence>This poses two
      technical challenges for any encoding scheme:  it must be
      extensible, to allow hitherto-unheard-of analyses of texts ...

    </body>
  </message>

　ヘッダにも（情報検索の分野では恐らく真っ先に候補に挙げられるはずのものだが）テキスト本文とちょうど同じような小分けを示すマーク付けを行っていることに注意したい。また、ある型のオブジェクト（例えば年や省略語等）がそれを囲む複数の型のオブジェクトの中で現れていることにも注意しよう。

　明示的にラベルを付け、範囲を区切っているオブジェクトは、階層的に組織された文法に従って記述されており、これが SGML について知るべきことのほとんどすべてである。あともう２つほどのヒントを書き残しているが、それは実体と属性についてである。

５　実体

　もう何年もの間、研究用テキストのコーディングと交換流通の中心的な課題は、マイケル（＊スパーバーグ・マックウィーン C.M. Sperberg-McQueen）がこのリストに以前投稿した中で定義したように、TEI 集団にとって重要なすべての言語と文字で使う文字素を表現するための標準について合意を探ることだった。標準制定団体やコンピュータ産業は、中世期の写本や古代高地グラゴル文字に対した場合にも似て、この点で奇妙に関心が欠けていたために、特別な字訳方式が増殖することになった。多くの人々にとっては、まさにそのような標準を定義するすることは TEI の主な仕事の一つなのである。後の投稿の中で、この点について TEI が実際に提案したものについてとり上げようと思う。ここでは、SGML 自体によって提示された著しく単純な解決法を指摘したいだけである。

　第一に、SGML によれば、 DTD はそれを使うテキストをコーディングしている文字コード・セットを明らかにしなければならない。これは、普通なら例えば ISO 646 （ASCII 文字と完全にではないがほとんど同じもの）などのように国際的に合意されたものになるだろうが、もしどうしても自分自身の選んだ文字セットを取り込もうというのであれば、SGML は少なくとも君がとった処置について世間に伝える手段となる。

　第二に、SGML は汎用的な文字列置換の機構を含んでいる。個々の文字からテキストの塊全体に及ぶ「要素」として知られる任意のテキスト区切りは、DTD の中で名付けられ、その後、それを直接に文書中に入れるのは不可能かまたは不都合な場合、どこからでも参照をつけることによって呼び出される。テキスト中の実体参照は、アンパサンドが前につき、セミコロンが後ろにつくものと相場が決まっており、こうして &実体名; の形をとる。SGML プロセッサには、文書中に使われているこのようなすべての実体の名前と、それらがプロセッサの動作する特定のハード環境に適合したものとなるように翻訳したものとの両方が DTD によって与えられる。例えば、アクセント文字・数学記号・印刷記号等に対して標準的な参照実体名のセットが ISO によって提案されているが、TEI は可能ならどんな場合でもそれに従うだろう。

６　属性

　テキスト要素に関連する情報をいくつか記録することができたら、たまには役に立つこともあるものだが、それ自身は一人前のテキスト要素であるとは見なされない。番号・規範的参照・状態マーカー等を特定することが具体的な例に含まれる。属性は、この目的で SGML に用意された機構なのだ。DTD は属性名とその（ある限界内で）とりうる値や、それが付属しうる要素を定義する。SGML でタグ付けしたテキストでは、属性値は要素の開始タグ内で補われなければならない。例えば、MESSAGE 要素が個々の MESSAGE 要素に固有の識別番号を補うのに用いる ID 属性を持つものとする。そこでメッセージ番号42の開始は、次のように示されることだろう。

  <message id=n42>

　属性を使うことは、それが形式面で余分なものを表している点で、いささか議論のあるところである。それでできる程度のことなら、それなしでもできる。しかしながら、属性は既存のほとんどの SGML システムに普及している。その上、属性なしでは、同時的な構造をマーク付けすることは耐え難いほど入り組んだものになる。しかし、そのことは他日の話柄である。