前回記事では、非ボーンデジタルなテキストデータを元資料を一致させることの難しさについてちょこちょこメモしてみた。とはいえ、そんなことばかり言っていては先に進まないので 解決策、というか、それをどう捉えるべきかということについて少しメモしてみたい。
まず、あらゆる面においてまったく同じものをテキストデータで得ようとするのは無理、ということは確認しておきたい。 たとえば、テキストが書かれた紙や石といった元資料の任意の箇所の化学的組成を確認したいと思ったら、それを 行うことが技術的に一定程度可能だったとしても、現在の ストレージではデータ量が膨大になってしまうので基本的には無理である。また、 字形の微細な違いもやはり再現不可能な場合が多く、さらに、Unicodeで符号化されていない文字であれば 自分のPCやWebページでは外字で対応するとしても、広く簡単に利用することは難しい。 そういったところをなんとかできたとして、 その次に来るのが、誤転記問題ということになる。
というわけで、まず、上記のような状況を斟酌しつつ、「テキストデータで何をどこまで再現したいか」という ことを検討する必要がある。これは「どこまで手間暇時間を費やせるか」ということでもある。 このようなことになると、技術水準による制約も大きく関わってくるので、長く通用する具体的な対応策を 立てるのは難しい。が、とりあえず、ここ数年の状況をみてみよう。
とりあえず、字形の微細な違いに関しては、UnicodeのIVSの仕組みを用いることでかなりの程度対応できる。 IVSに適切な字形を見つけられない場合は、IVDをUnicodeに提案して自分に必要な字形をUnicodeに登録して しまうという手もある。この場合、フォントも自分で作成しなければならないが、これはGlyphwikiを使えば 割と簡単である。…という風に、技術的にも手続き的にも色々なことが可能になっているが、そうすると やはり「どこまで手間暇時間を費やせるか」という問題になってしまう。字形の微細な違いをきちんと 反映しようと思った場合、「標準的な字形とは微細な違いのあるこの字形はこの資料の中に登場するすべての同字で共通なのか」 を確認しなければ、意味が薄くなってしまう。それは人力で確認するのか、あるいは、画像処理プログラミングの 得意な人であれば（あるいはそういう人に頼めるのであれば）、元資料を デジタル撮影／スキャンして文字を切り出して分類し、自動的／半自動的に確認するか。人力の場合には、 文字入力、もしくはOCRの誤字チェックをしながら同時にチェックしていくことになるだろうか。いずれにしても、 簡単にできることはなさそうである。そして、その微細な字形を表現するためのフォントをGlyphwikiで 作成し、フォントを作り、UnicodeへのIVDの登録手続きに入ることになる。Unicodeへの登録手続きは 慣れていればそんなに難しくないかもしれないが、これに慣れている人は地球上でも2桁いるかどうかという 感じなので、やや長丁場になると考えておく必要がある。
というようなことを踏まえて、字形の微細な違いに手間暇時間をかけられないと思ったなら、それは 諦めることになる。ただ、諦めるにしても、「この字形はこの文字と同じとみなす」というような ルールの設定は必要になる場合がある。このルール表が大きくなるとかえって入力作業が 大変になってしまうこともあるので、その案配にも注意が必要である。
次に、Unicodeで符号化されていない（＝Unicodeに入ってない）文字だったらどうするか、という問題に進んでみよう。 これは、上記のIVS/IVDに比べると、資料内の全文字チェックのようなことはおそらく 必要にならないので、その部分ではコストはそれほどかからないと思われる（つまり、 「この文字はUnicodeに入っていない」ことさえ確認できればいいから）。しかしながら、 Unicode未符号化文字をUnicodeに入れる場合の手間暇時間はなかなか大変である。 Unicodeの文字に関しては、国際標準化機構（ISO）で定めた文字コード表 ISO/IEC 10646に 準拠しているため、Unicode協会ではなく、国際標準化機構の方に行って符号化提案をしなければならない。 そのためのルートはいくつか存在するが、いずれにしても、数年を必要とし、ISOの委員会での 英語文書の交換に基づく議論に参加して符号化提案の必要性を提示しなければならない。 一度Unicodeに文字が登録されれば、同じ文字を扱わねばならないすべての 人を益することができるため、社会的貢献度は高い仕事ではあるが、手間暇時間はそれなりに 大きくなる。諦めて、似た文字を使うとか、あるいは「外字」を使うという方向性も考える必要はあるだろう。 ただ、そのようにした場合、その文字が「本来はどういう文字であるか」を示すことが テキストデータだけではなかなか難しい。その状況を改善する手段の一つとして、 Text Encoding Initiativeガイドラインの gaijiモジュールがある。ここでは、文字についての 様々な情報を記述した上で、本文中に記した文字に対してその文字情報を付与できる 枠組みとなっている。
というようなことで、なんとかしてテキストデータをUnicodeの文字に置き換えることを ルール化できたなら、それを可能な限り文書として残しておくことが重要である。 「なんでこの文字が出てくるの？」「この文字とこの文字はどういう関係なの？」 等々、ただテキストデータ化しただけだと、元資料からどのように文字起しされたかが 明示的に記述されていないと、他の人がそのテキストデータを使おうとした時に、 よくわからないまま使うことになってしまう。結果として、データの信頼性が 低いとみなされて使われなくなってしまうことも十分にあり得る。 データ作成者でない人が見たときに理解し利用できるようにデータを作って おくというのは、デジタルデータの長期保存に関する枠組みとして有名なOAIS参照モデル でも提示されているような教科書的なことである。これは、テキストファイルの冒頭にでも 書き込んでおけばよいかもしれないが、この場合でも、Text Encoding Initiativeガイドラインが それを書くためのエレメントを提供しており、活用するとそのあたりの処理の利便性を 高められる。興味がある人は、特に teiHeaderの章を読まれたい。
というわけで、文字をデジタルに転記する方法に関しては、まあ 大体なんとかなるとして、次に出てくるのは、誤転記である。せっかくルールを作っても、 人間だもの。間違うことは（大いに）ある。コンピュータにOCRやHTRで読み込ませても お茶目な間違いをしてくれることは大いに期待できる。それを人力で修正しても、やはり 間違いが残ってしまうこともあるだろう。では、たとえば分析のためのテキストデータとする 場合はどうなのか。誤転記を含むデータを分析したところで何か意味のある処理が可能なのか、 ということになるが、それは、テキストデータの量や処理の内容、つまり、統計的に分析するのか、 単にテキスト検索ができればいいのか、といったことによってかなり話が変わってくる。 そして、もちろん、手間暇時間をかけるほど、正確性の高いデータを得られることは 間違いなく、しかし、手間暇時間をかけられない場合には、では何をどこまで妥協するのか、 ということになる。
このあたりになってくるとやや難しい判断が必要になるが、基本的な方向性としては2つを考えておけばよいだろう。 一つは、なるべく正確なものを作成する方向であり、もう一つは、正確でなくてもいいから分析できるように分析の仕方を考えるという 方向である。そして、どちらの方にどれくらい重きを置くか、ということを決めるのが、この局面で必要になることである。
正確なものを作成する方向は、単に、全体として完全に正しいものを目指すというだけでなく、たとえば、 特定の情報がほしいだけであれば、その部分だけは正確性が高まるように、人力と機械をうまく組み合わせてチェックをしたり、 あるいは人力だけで根性で頑張るという手もあるだろう。
一方、正確でなくてもいいから分析できるように分析の仕方を考えるという 方向については、特にデータ量が大きい場合には比較的有効だろう。単なるテキスト検索にしても、 少々誤転記が多くても、大量にテキストデータがあれば、それなりに欲しい情報もヒットしてくれる ことがあるだろう。また、統計的に分析するにしても、統計的に有意であることを示すことが目的 であれば、大量テキストデータでは多少データに誤転記が含まれていてもなんとかなることもあるだろう。 この場合、対象となる大量テキストデータの信頼度がどれくらいかということもサンプル調査などをして 明らかにしておけば説得力は増すかもしれない。
というようなことで、眠くなってしまったので今夜はこれくらいにしておきたい。
