TEIガイドラインP5

5.1 その道のりは本当に必要なのかTEI: その道のりは本当に必要なのか¶

符号化する人が電子化すべき文書の中でいくつかの図像に出会った時，解決されるべき最初の課題は「これは本当に異なる文字だろうか？」だろう．ある特定の図像が一つの文字であることを決定するためには，用語法とキー概念を参照されたい．

現在，ユニコードには10万近い文字が登録されているため，あなたが必要とするものがすでにそこにある可能性は十分にある．しかし，ユニコードでは別な名前で登録されている可能性があるため，見つけ出すのは簡単ではないかもしれない．このような場合，他のサイト，たとえば，文字と言語に基づく検索システムを提供している http://www.eki.ee/letterなどをも参照されたい．しかし，関連する文字であると思われるものの属性のすべてが，探している文字のものと一致するかどうかについても注意されたい．たとえば，あなたの文字が明らかに数字であり，しかし，一番よく似ているものの属性が文字となっていたならば，それはまだユニコードでは定義されていないということかもしれない．

一般に，表示形と位置づけられているユニコードの文字は避けておくのが賢明である．²⁰ しかし，もし，探している文字が（ある言語の正書法というよりはむしろ）記数法として用いられているならば，その場合には，それらが適切な属性となっている限りにおいて，数学記号範囲(すなわち，So:記号，その他， あるいは Sm:記号，数学)から文字を選ぶことはむしろ好ましい．

ある種の文字は事前に作られているかもしれないし，あるいは，基本となる文字とダイアクリティカルマークとの組み合わせで形成されるかもしれない．いずれにしても，一つの符号化された文字が「見つかった」というには十分だろう．

もし，いくつかのユニコード文字が選択し得るならば，なんらかの合意がすでに形成されているのかどうか，周囲の人や実際に取り組んでいる人に相談してみるのがよい．

しかし，もし，適切な形の文字がなさそうなら，次の質問が出てくるだろう．「問題になっている文字はすでに知られている文字の異体字なのか，それともまったく符号化されていない文字なのか？」もしその文字がユニコード標準には収録されていないことを確信したなら，その新しい文字を登録すべく提案するのは有益だろう． ( http://unicode.org/pending/proposals.htmlを参照).

このガイドラインは，ある図像のかたまりが異体字か，あるいは，外字であることが判明したときに，その先へ進むのに役立つだろう．これを決めることは，持っている文書の内容についての知識を必要とするだろう．最初の事例は，文字の「アノテーション」と呼ばれ，次の事例は新しい文字の「追加」と呼ばれる．異体字を表現している図像のかたまりをどのように取り扱うかということについては以下，5.3で議論されるだろう． (5.3 文字への注釈) 新しい文字を表現する際の問題は 5.4 新しい文字の追加で取り扱われるだろう．

これらの要件は多少重複しているが，明確に特化されたマークアップの構造は，以下の 5.2 文字と字形を表現するためのマークアップの構造に説明されるように，これらのそれぞれに関して用意されている． 以下のセクションでは，それらを目の前の問題にいかにして適用するか，という議論に入っていく．すでに存在する文字の「アノテーション」についての議論は5.3 文字への注釈 で，そして，最後に，新しい文字を作成するのは 5.4 新しい文字の追加で議論される．

5.2 文字と字形を表現するためのマークアップの構造TEI: 文字と字形を表現するためのマークアップの構造¶

原理的には，XML文書はあらゆる定義済みのユニコード文字を含むことができる． その標準規格では，適切なエンコーディング（デフォルトではUTF-8）を直接用いる方法と，数字を用いて参照する(NCR)間接的な方法とのどちらでも，これらの文字が表示されることが認められている．符号化する人は，適切なエンコーディング宣言を付け加えることで，文書で（あるいはその一部で）表現される文字の範囲を制限することもできる． たとえば，もし，文書が<?xml encoding="iso-8859-1"?>という宣言で始まっているなら，<?xml encoding="iso-8859-1"?> ISO-8859-1の文字セットに含まれないすべてのユニコード文字は数値文字参照(NCR)で表現されなければならない．

この章で定義される外字モジュールは，文書のなかで特殊な文字や字形を表示するためのさらなる方法を提供する．外字モジュールによって，符号化する人は，ユニコードでは包摂されている文字や字形を区別すること，ユニコードに入っていない新たな文字や字形を付け加えること，文書を符号化する際には利用できないユニコード文字を別の手段で表現することが可能となる．

外字モジュールがスキーマに含まれているときには，要素charDeclがクラスmodel.encodingPartに追加されている．そして，要素g がクラスphraseに追加されている．これらの要素とそれらのコンポーネントについてはこのセクションの別の場所で説明する．

ユニコード標準はユニコード文字データベースで定義するすべての文字に関する属性を定義している． その知識は，大抵の場合，テキスト処理システムに組み込まれている． もし要素g によって表示される文字がユニコードにまったく存在しない場合，その属性はまったく利用できない．もし表示される文字が既存のユニコード文字で，しかし，使っている処理システムで認識できる文字セットでは利用できない場合には，同じ方法でその属性にアクセスするのも便利かもしれない．要素char は，ある標準的な方法でそういったアプリケーションによって利用するために属性を蓄積することを可能にしている．

文字に関する属性のリストは，ユニコード文字データベースのものを手本としており，文字の属性を 規定(normative) と 参考(informative) に区別している． さらに，非ユニコードの属性も提供することができる．属性のリストはユニコード標準のバージョンによって異なるため，それらは，これらのガイドラインで定義する属性のリストとは正確には一致しないかもしれない．

要素charと要素glyphは似たような内容を持ち，似たような方法で用いられるが，それらの機能は異なっている．要素char は，どんな理由であれ，上述のように，現在の文書の文字セットでは利用できない文字を定義するために提供されている．要素glyph は，たいていの場合，下の文書に文字がどのように現れているかを示す特別な字形を提供することによって，すでに存在する文字を注記するために用いられるものである．ユニコードのコードポイントは非常に一般的な抽象化文字を参照するものであり，きわめて多くの表現手法によって描かれ得るものである．要素glyphは，符号化する人がすべてのあり得る字形に含まれない特殊な字形（あるいは字形のファミリー）を特定したいケースに向けて提供されている．

これらのうちの4つの要素 (gloss, desc,graphicと remarks) は他のTEIモジュールでも定義されており，それらのここでの用法は，別のところでの用法と違いはない．しかしながら，要素graphic は，ここでは，検討中の文字や字形の画像にリンクするか，あるいは，SVGでの表現を含むためだけに用いられる．いくつかの要素graphicが，たとえば，異なる解像度や異なるフォーマットによるいくつかの画像を提供するために，利用可能である．属性mimeTypeは，要素 graphicがクラスatt.internetMediaのメンバーから得るものだが、画像のフォーマットを特定するのに用いることができる．

あらゆる文字や字形の属性のより正確な説明は，次のセクションで解説される包括的な要素charPropを用いることで提供される．CharProp(Character Properties）という要素名にもかかわらず，この要素は文字にも字形にも用いることができる．

5.3 文字への注釈TEI: 文字への注釈¶

ある文字への注釈は，特定の側面（よくある例としては，見た目に関して）のみに基づいて区別されることが求められた時に必要となる．たとえば，rの文字の明確に異なる形が認められるマニュスクリプトにおいて，その頁の正確な表現を提供する必要性とはまったく異なった意味合いで，分析を目的としてそれらを区別することは有益かもしれない．デジタル画像，特に翻刻され符号化された版にリンクされたものは，常に上質な視覚的表現をもたらしてくれるだろう（どのようにしてデジタル画像から翻刻テキストにリンクするかということについての情報は 11.1 Digital Facsimilesを参照）．しかし，それは，そのような異なった形の分布に基づく議論を助けるのに用いることはできない．ここに記述された文字の注釈はこの問題への一つの解決策を提示する．²¹

このマークアップが適切なところにあれば，異なる文字「r」はオリジナルをより「忠実な」形で表示するのと同時に，その分布を分析するためのプログラムを書くこともできる．また，要素gで指示された注釈を簡単に無視して正規化されたバージョンを作り出すこともできる．

しかし，注意しておきたいのは，このテクニックは文書中の文字とその文字についての何らかの注釈との間のリンクを提供するためにマークアップオブジェクトを採用しているという点である．すなわち，このようなマークアップの構造が許可されないところ，特に属性の値では用いることができない．

5.4 新しい文字の追加TEI: 新しい文字の追加¶

テキストの符号化において利用するために追加する文字を作成することは，既存の文字の注釈にとてもよく似ている．同じ要素gが，テキスト中の文字のインスタンスから要素charDecl の中に書かれた文字定義へのリンクを提供するのに用いられる．この文字定義は要素char の形式を採る． 要素g 自身はたいていは空だが，ユニコード標準の個人利用区画(PUA)のコード番号を含むことができる．個人利用区画は文書に新しい文字を私的に追加するというまさにその目的のために用意されている領域である．その個人利用区画の文字の推奨される利用法は以下の節に提示されている．

この例では，「丸で囲まれた表意文字」は二つのマッピングと二つの属性で定義されている．二つの属性はユニコードで定義された文字部品であり，丸囲み文字であることを表している．それは適切な用語(上述の 5.2.1 文字の属性 を参照)と，「大漢和」と呼ばれるローカルで定義された属性を用いている．二つのマッピングのうち最初のものはこの文字の標準字形が人であることを示しており，二つ目のものはこの文字をローカルで表現するのに用いられている文字が個人利用区画文字のであることを示している．ローカルでの処理を便利にするために，このPUA文字は実際のところ要素g の内容として用いられてもよい．しかし，一般には，要素gは空となるだろう．

5.5 個人利用区画でのコード番号の使い方TEI: 個人利用区画でのコード番号の使い方¶

ユニコード標準の開発者はソフトウェア開発者やユーザグループ，あるいは個人のプライベートな利用のためにあるコード空間を確保してきた．この書き方（Unicode5.0）に関しては，13700コード番号がこのエリアで利用可能である．それはほとんどのニーズに十分だろう．標準自身がこのエリアへのコード番号の割り当てを行わないようにしており，いくつかの非常に基本的なデフォルト属性だけが割り当てられている．（それはこの章で概説した仕組みによって必要であれば上書きしてもよい．）したがって，ユニコード標準で定義されるすべての他のコード番号とは異なる，個人利用区画のコード番号は，容易な交換（blind interchange）を目指す文書では直接に文書の中で用いられるべきではない．

上述の二つの例で，我々は，関連する派生文字が個人利用区画の特定のコード番号にうまく割り当てられるだろうということを述べた．このことは，たとえば，ローカルな処理環境でのこのコード番号の箇所で希望の文字を表示する特定のフォントの利用を効率的にするかもしれない．しかし，この割り当てはローカルサイトで正しいというだけなので，そのようなコード番号を含んでいる文書は容易な交換（blind interchange）には不適である．交換のためにそのような文書を用意する処理では，あらゆる個人利用区画のコード番号は適切に用いられた要素g，たとえば g ref="#xxxx"によって置き換えられるべきである．そのようにして，参照された要素char によって提供される記述によって，必要な文字に関係づけるのである． 文書を用意する間に用いられる個人利用区画文字は， 5.4 新しい文字の追加での例に示されたように，要素char の中に記述されてもよく，あるいは，要素gの内容として保持されてもよい．しかし，受け取る側のサイトでそれを表現するのに用いる同じ個人利用区画文字が要求されないということと，このサイトがすでに独自の個人利用区画のコード番号に別の文字を割り当ててしまっていることもあるかもしれないということから，ローカルに定義された個人利用区画の文字を削除しておくのは最良である．そういった文字を扱うためには，受け取るサイトでのローカルな処理環境にさらに変換すること必要とされるだろう，ということは想定しておかねばならない．その場合，異体字は，要素charで提供された情報に基づき，それまで未使用だったコード番号に変換してもよい．

この仕組みはDOMツリーやパースされたXMLの断片が交換される場合にはやや弱い．そのケースはちょっと多いかもしれない．ここで可能な最も良い対応策はローカル文書の文脈のみでPUA文字の出現を扱うことであり，他の文脈での文字の扱い方として要素charを通じて提供される属性を利用することである．

機が熟したなら，一つの文字は標準となるかもしれず，個人利用区画以外のところに特定のコード番号を割り当てられるかもしれない．その仕組みを用いて符号化された文書は，少なくとも，この変更されたコード番号が関連する char要素に記録されたということを保証する．しかし通常は要素char を削除して，新たに符号化された文字を、それを参照する要素gのすべての登場箇所に置き換える方が簡単だろう．

5.6 外字モジュールTEI: 外字モジュール¶