SSH Open Marketplace：欧州の人文・社会科学分野の研究資源カタログはクラウドソーシングのようでした

欧州では European Union’s Horizon 2020 project の下、研究インフラの構築が盛んに行われています。 European Research Infrastructure Consortium (ERIC) を中心として進められているようで、 基本的には理工系の話なのですが、欧州では人文・社会科学にもそれなりに力が入っているようです。 たとえば、社会科学ではCESSDAやESS (European Social Survey)、 人文学ではCLARINやDARIAHが割と有名です。

しかしながら、研究に関わる資料やデータ・ツールなどをあちらこちらのサイトに見に行くのは なかなか大変です。当然、横断検索サイトを作りたいという話がでてきそうです。日本では 全分野の横断サイトとしてCiNii Research、人文・社会科学に特化したより詳細な横断検索サイト としてJDCatがあります。では、研究インフラ構築が盛んな欧州では…と思っていたら 出てきていたのが SSH Open Marketplace でした。 上記の組織をはじめ、人文・社会科学に関連する欧州の様々な組織が参加して いて、研究リソースの横断検索サイトを作る…という話で、2018年のこちらのシンポジウムで Laurent Romary先生がこういう話をしてらっしゃったので、それがいよいよ結実しつつあるのか…と思いながら 時々サイトを眺めていたところ、数ヶ月前に Final Versionというのが出ていました。 そこで以下のようなツィートをしたりしていたのですが、

欧州の人文社会科学研究リソースクラウド、SSHOpenCloud https://t.co/6Qo2WsfBLH がついに正式リリースされたそうです。CESSDA, CLARIN, DARIAH等のリソースを一括検索できるみたいです

— Kiyonori Nagasaki (@knagasaki) 2022年1月19日

これが、どうもよくみると、誰でもデータの登録申請ができるようなことを書いてありましたので、 もしかして…と思って、データ登録の操作をしてみました。

そして、本日、「そういえばどうなったかな…」と思ってサイトを改めてみてみたところ… ちゃんと登録されていました！

marketplace.sshopencloud.eu

メタデータをよくみると、INFORMATION CONTRIBUTORSとして、データ登録をした 私の名前以外に、Edward Grayという名前があります。この人がどこの人かを確認してみると、 このプロジェクトのメンバーのリストの中にお名前があり、 フランス国立科学研究センター(CNRS)の人文社会科学系のプロジェクト、Huma-Numの人のようです。 ここまでわかると、個人のプロフィールにもたどりつけます。 今回登録したデータは、コンテンツは仏教学ですがWebサイトやデータの一次言語はフランス語でしたので、 フランスの人が見た、ということかもしれませんが、博論で宗教も扱ったようですので、それも 関係あったかもしれないですね。メンバーのリストを見ると、各機関からいろいろな分野の人が 参加していて、この人たちがデータをキュレーションしてくれるなら、結構よい感じの サイトになっていくかもしれないと思ったところでした。

というようなことで、このSSH Open Marcketplaceは、「人文社会科学系キュレーション付きクラウドソーシング研究資源カタログサイト」 と考えておくとよさそうですね。すでに結構な量のデータが入っているようでもありますが、今後、みんなで育てていくと いいかもしれないですね。

【頭の整理】日本での「テキストデータベース」作りのステップ6くらい

前回記事では、用途に応じたタグの付け方についてみてきた。

このようにして様々なタグの付け方があり、分野毎に異なるタグが用意されることになるのであれば、 タグの構造を設定したり使い方をレクチャーしたりする、かなり詳しい人が分野毎に必要となりそうである。 しかし、人文学分野は多岐にわたるものであり、それぞれの分野で技術レベルの高い人を用意することは なかなか難しい。そこで、分野横断で、共通化できるタグはなるべく共通化して、しかし共通化 できないものは分野にあわせてタグを設定する、というやり方が一つの選択肢として出てくる。 まさにそこを目指して作成されてきたタグ付けのルールがTEIガイドラインであり、それゆえに、 特定の分野に偏ることなく、コミュニティに参加する人文学研究者達が取り組む分野全体に対応しつつ、 個別分野にも丁寧に配慮しようとしてきたのである。

TEIガイドラインはともかくとして、ここでは、「タグ」をつけることの可能性についてもう少し検討してみよう。

前回記事でみたように、タグの名前はタグが囲まれる文字列に対してなんらかの意味を付与することになる。 人名であったり、手紙の宛先であったり、校異情報であったり、様々である。 源氏物語の校異情報マークアップの例では<app>の中に <lem> と<rdg>が入っていたが、そのようにして 入れ子構造を作っていくことで上位タグの意味を下位のタグに継承していくことも検討する必要がある。

これは、たとえば人名の例で考えてみると、

<人名>森鴎外</人名>

というタグの付け方があったとして、これを姓名にわけると

<人名>``<姓>森</姓>``<名>鴎外</名>``</人名>

という風になる。ここで、「森」という<姓>の人の名は、一つ上の階層の<人名>にあがると、その下位に<名>である「鴎外」が確認できる。 階層構造の活かし方はたとえばこのような感じになる。

ちなみに、森鴎外は、本名は森林太郎‏であり、他にも、観潮楼主人、千朶山房など、様々なペンネームを使用していたとのこと。 この場合、前回記事に示すような、複数の名称が同じ人であると示すことの有用性がより高くなる。この場合、 ペンネームと本名を示すこと、そして、それが一人の人物であること、を示したいということになる。タグを付けると 以下のようになるだろう。

観潮楼主人と千朶山房については、姓名を区別できるかどうか筆者にはわからなかったので、姓名を区別するタグはつけていない。 タグの階層をそろえるために姓か名かのどちらかのタグをつけるということも処理を効率化する上では考えられるのだが、 姓か名かのタグをつけてしまうと、姓か名ではないものにいずれかであるという誤った情報を与えてしまうことになるため、 むしろ階層をそろえることを犠牲にしてこのような記述にしている。この場合、処理する際には「ペンネームの タグの下位には姓・名のタグがあって そのなかに名前の文字列が入っている場合と、姓・名のタグがなくて名前の文字列がペンネームタグのなかに直接書かれている 場合がある」という前提で処理をすることになる。

あるいは、処理上の例外を減らすために、「名前全体」というタグを作って、姓名を区別できないものも同じ階層にしておくという 方法もある。この場合、以下のようになる。

この場合、階層は同じなので、「ペンネームタグの下位には姓・名・名前全体のいずれかのタグがあり、そのなかに 名前の文字列が入っている。」というルールで処理をすることになり、処理側の例外は少し減らすことができる。 しかし一方で、「姓が来たときは名があるのでもう1つ処理をすることを前提にしなければならないが、名前全体がきたときは1つだけ」 という処理が必要になる。どちらの処理の方が効率的・効果的か、というのは状況に応じて異なる。 ただ、いずれにしても、<名前全体>があるタグ付け方法とないタグ付け方法は、この段階では機械的に置き換え可能 であり、自動置き換え処理を差し挟むことができる状況であれば、いずれの方法を採っても問題ないだろう。

さて、前回記事の人名の書き方では、文章のなかに登場する人名や呼称を「属性で参照」することによって 一意に同定できるようにしていた。では、この書き方の場合、それをどのように実現するのか、少し検討してみよう。 たとえば、以下のような文章があったとしよう。

東京都文京区千駄木町には、 登録有形文化財の和風住宅がある。ここは、明治の文豪である森鷗外と夏目漱石が、相次いで住んだ ことがあり、鷗外がここで執筆した小説に『文づかひ』がある。その後に住んだ漱石は『吾輩は猫である』をここで発表した。

この文章に含まれる人名にタグ付けすべく、対象文字列の始まりを<人名>、その終了箇所を</人名>として囲んでみると以下のようになる。

このようにしてタグをつけた場合、「人名」タグを対象とした取り出しの処理をすることで以下のようなデータを列挙できる。

この場合、まったく同じ文字列ではないので、機械で処理した場合、「多分同じ人物」という情報しか得られない。 この短い文章であればそれでも大丈夫だが、大量のテキストデータのなかでこのようなことが起きると、同定はやや難しい。 そこで、タグに対して本名が何かという情報を与えてみたのが以下のものである。

上記では、<人名>というタグに対して、本名という属性を与え、その値として本名の文字列を指定している。 このようにした場合、「人名タグの本名属性」を見ることで、同一人物かどうかを確実に判定できることになる。

ただし、これでは、まだ不足な面がある。この本名というのがどういう情報なのか、本名がすごく長い場合はどうするのか、 この人物の本名以外の情報はどうなっているのか、等々、もっと様々な情報を付与できた方がいい場合もある。そこで出てくるのが 人物情報を別に作り、そこにリンクするという方法である。

このように、人物タグを別に作成してそこに人物に関する情報を様々に記載しつつ、人物に 対してid="PS1"のように、PS1 という値を持つidという属性を与え、それに対して本文中の文字列に付与したタグから は属性「人物」を用いて参照する、という風にすれば、属性情報のリンクをたどることで 本文と登場人物の様々な情報を確実に結びつけられる。

タグとして付与できる情報にはこれ以外にも様々なものがある。今回の文章では 年代や住所、書名などがあり、それもタグ付けしてみると以下のようになる。

さらに、外部の情報とリンクすることもできる。たとえば、著書を残したことがある人の多くはVIAF (http://viaf.org/) という 国際的な人物の典拠情報においてIDが割り当てられている。今回の2名の場合、それぞれにVIAFでの登録があり、これを参照することによって 外部の豊かなデータと接続できることになる。今回は著作者の人物情報としてのVIAFとリンクすることが目的であるため、 このVIAFのIDは、<人物>タグの属性か、もしくはその下位に何らかの形でタグを付与しつつ記述することになる。たとえば 以下のようになる。

また、タグをまとめるということも考えてみたい。たとえば、<本名>や<ペンネーム>などは 人名の一種であるにも関わらず区別する必要がある。この場合、この二つは<人名> の変種として捉えることにして、<人名>タグに対して以下のように属性「タイプ」を用いて 区別している。

…今日は眠くなってしまったのでまた明日。

【頭の整理】日本での「テキストデータベース」作りのステップ5くらい

前回記事の続き。

テキストデータベースが「どういう深さのものか」を決めて、それを記述するというのが前回の到達点である。 しかしながら、前回は、研究志向の強いものについては、 「Level 5: 学術編集のためのタグ付け」で一括されてしまっていた。「学術編集のための」 と言っても、分野や手法によって関心は様々であり、それに応じた深さの方向性がある。 これをどうするか、というのが次の問題である。

たとえば、言語学のなかには、単語の品詞情報や発音・アクセントなどの情報が欲しい人がいるだろう。 その場合、各単語にタグがつけられて、そのタグによって本文中の単語に対する付帯情報を取り出せるように なっているとよいだろう。有名なものの一つに国立国語研究所が作成した現代日本語書き言葉均衡コーパス（BCCWJ）がある。 ここで「原動力」という単語をみてみると以下のようにタグ付けされている。

<LUW>というタグで始まり、そのタグに対して l_lForm="ゲンドウリョク" l_pos="名詞-普通名詞-一般" といった形で属性を与えることで、 </LUW>というタグで終わるところまでの文字列に対して、現代日本語の分析に必要な情報を与えている。さらに、<LUW>の次に<SUW>という タグもあり、これが「原動」と「力」にそれぞれついている。これは短い単位の単語区切りということで、この短いものに対しても、 やはり属性を通じて日本語分析に必要な情報が与えられている。このようにして、本文中の「原動力」という単語に対してタグを用いて 研究に有用な情報を付与しているのである。

あるいは、古典文学作品の代表格である『源氏物語』について少しみてみよう。『源氏物語』には実に多様な 研究のアプローチの仕方ががあるが、ここでは校異情報に関するタグ付けをみてみよう。

『源氏物語』と言えば、あまりにも有名なので、紫式部が著わした文章そのものが残っているのではないかとつい期待して しまうところだが、実際には、紫式部自身が書いたものはもう存在せず、それを写した写本の形式で日本各地に 伝承されている。そして、写本はいつも完璧に複製できるわけではなく、むしろ誤記や表現の仕方の変化などに よって内容が少しずつ変わってしまうこともある。我々が読んでいる『源氏物語』とは、そのようにして伝わってきた 写本を並べて差異を確認し、どれが紫式部が書いたものにより近いかを是々非々で検討した上で作成されたものである。 聖書にしても仏典にしても、原著者が書いたものが残っていない場合には、どうしてもそのような差異を気にする 必要が出てくる。そこで登場するのが、「各写本でこの箇所はどう書かれているか」を記述できるようなタグ付け方法である。 この種のものは、前出のTEIガイドラインが得意であり、たとえば『校異源氏物語』のある箇所をタグ付けすると以下のようになる。

ここでは、校異情報が存在する本文をまず<lem>～</lem>というタグで囲み、これに対して、校異情報を<rdg>～</rdg>という タグで囲んだ上で<rdg>タグには wit="#別陽" あるいは wit="#別國" と記載している。これは、一つ目の<rdg>は「別本の陽明本」 における記述であることを示し、二つ目の<rdg>は「別本の國冬本」であることを示している。その上で、<app>～</app>という タグで囲むことで、ここにはこの<lem>（Lemma, ここでは本文を意味する）と<rdg>（Reading，ここでは異文を意味する）を含む 校異情報（Critical Apparatus）が存在していることを示している。

言語学・文献学と、ややマニアックな方向に行ってしまったが、少し戻って考えてみると、そもそも例えば、テキスト中に登場する人名や地名などを タグ付けしておけば、むしろ、人文学に限らず、様々な研究分野、さらには研究外での用途も期待できるかもしれない。たとえば 以下のものはそのようなタグ付けの典型的な例である。

ここでは、人名や呼称を<persName>～</persName>で囲み、それが実際にはどういう人物であるかについて corresp= という属性を用いて 同定している。つまり、邪智暴虐の王がディオニスであることを記述しているのである。

さらに、人称代名詞が誰を指しているか、ということもタグ付けすれば分析の幅は広がるだろう。この場合には例えば以下のように なる。

ここでは、人称代名詞を<rs>～というタグで囲み、属性として corresp="#メロス"` などと書いておくことで、 誰が話題になっているか、ということを自動的に検出できることになる。

この「属性として corresp="#メロス" などと書いておく」というのも実は重要である。この例（太宰治の『走れメロス』） ではフィクションの登場人物なのであまり問題にならないが、これが歴史文書等の実在の人物と結びつくものであったり、 聖書や仏典など、多数の書物で参照される人を含んでいるものであったりする場合には、「あちらのテキストに登場する Aさんとこちらのテキストに登場するAAさんは同じ人だけどそちらのテキストに登場するAさんは名前が同じであるだけで 別の人」という情報があると、色々な処理がしやすくなる上に人が読んだり参照したりする際にも便利である。 そのような場合に、一人目のAさん、二人目のAさんのIDを何らかの形で決めておいて（たとえばpersonA-1, personA-2など）、 corresp="#personA-1" という風に属性をタグに記述しておくと、これは二人目のAさんではなく一人目のAさんであることが 明示され、機械的な処理ができるようになる。ただし、これだけだと人がみてもわかりにくい場合もある。 人が読んでもわかりやすいようにするためには、たとえば、「 corresp="#personA-1" という属性のついたタグが付与 された文字列（人物名や代名詞など）にマウスのカーソルをあわせれば「一人目のAさん」と記述されたポップアップが 表示される」という風にしておくことや、あるいは、行間にそのような注釈を表示させる、といった対応もあり得る。 ここで重要なのは、「Aさん」という名前を発見することはコンピュータの文字列検索で簡単にできるが、 一人目のAさんと二人目のAさんの区別をつけるのはコンピュータでは非常に難しく、最近のAI技術ではそういう ことがかなりの確立で可能になってきている場合もあるものの、決して正確なものではない。人の判断も 絶対に正しいとは限らないにせよ、多様な文脈から明白な根拠を以て判断するということについては まだ専門家による人力に一日の長があり、専門家の判断力を少しでも多く活かし後世に残していくためにも このような形で同名人物の区別を記述しておくことは有用である。

なお、人名や地名などの固有名詞は、表記が異なっているが 同じものを指していることがあるため、上の図のように、同じものかどうかを属性として記述しておくと分析等をする際の 精度はより高まるだろう。

今回は事例がやや少ないものの、このようにして用途によって深さの方向性が異なっていて、それに用いるタグの種類も 異なってくる、という点は示せたのではないかと思う。

【頭の整理】日本での「テキストデータベース」作りのステップ4くらい

テキストデータベース作りに関するメモの続き。

前の記事からくる帰結は、テキストデータの元資料への忠実さや付与される解釈の深さは、以下の2点に依拠するということになる。

・どういう人のどういうニーズを対象とするか

・どれくらいの手間暇時間をかけられるか

この2点を明確に定めたうえでテキストデータを作成すれば、目指すことは概ね実現できるだろう。 ただし、大規模なテキストになると、テキストデータを作成し始める段階では、手間暇時間の見通しを立てるのは難しいことも多い。 そのような場合には、本格的な作業に入る前に、対象となる元資料の典型的な箇所をいくつかサンプル的に取りだして テキストデータ化し、それを通じて全体にかかる手間暇時間を算定するのが穏当なやり方である。

どういう人のどういうニーズを対象とするか、というのは、テキストデータ作成者の立場によって大きく異なる。 対象テキストを自分（達）で研究したい人（達）が作成するのであれば、それらの点は明確にしやすい。 自分達の研究のニーズに沿ったデータを作成すべく、自らの方法論を深めていけばよいということになるから である。それもまた、突き詰めるとなかなか難しいことにはなるものの、目的地点を定めやすく、さらに、 それを追究すること自体が研究発表にもつながり得るため、いわば研究活動の一環として位置づけることも 可能である。

一方、図書館等のサービス提供者としてテキストデータを作成・提供しようという場合、その決定の仕方は やや難しいことになる。むしろ、手間暇時間（もしくは費用）をどれくらいかけられるか、ということが前面に 出てきて、それに応じて対象者やニーズを考える、という順番になることもあるだろう。大規模なところで見てみるなら、 HathiTrustにしても、国立国会図書館の次世代デジタルライブラリーにしても、基本的には、かけられるコストを踏まえて 現在可能なものを作成し提供している。むしろ、利用者側がその有効活用の方法を考える方が 発展的であると言えるだろう。

このような観点から有用なアプローチがあるので紹介しておきたい。人文学テキスト資料のためのXMLに準拠した 記述手法を提示するTEI (Text Encoding Intiative) ガイドラインを定めている TEI協会の図書館分科会が 提供している Best Practices for TEI in Libraries というルールがある。 ここでは、テキストデータへのタグ付け（符号化、encoding）のレベルを以下のように5段階に分けて整理している。

• Level 1: OCRによって自動生成されたテキストにそのまま自動化可能な範囲でタグ付け
• Level 2: 最小限のテキストの構造をタグ付け
• Level 3: 内容に関するごく簡単な整理も含むタグ付け
• Level 4: 内容に関する基本的な整理・分析を含むタグ付け
• Level 5: 学術編集のためのタグ付け

このように整理した上で、それぞれのレベルで推奨されるタグ・オプション的なタグも提示している。 このようなルールが公開されている場合、これらのいずれのレベルに準拠したか、ということさえ 明示しておけば、利用者側がどう使えばいいかということを判断しやすくなるだろう。 Level 1 のテキストであれば、利用者は、テキストの文字読み取りからして間違っている かもしれないという前提でテキストデータを扱うことができる。あるいは、Level 3のテキストであれば、 段落や章タイトルなどの基本的な構造がテキストデータに埋め込まれており、それを前提とした 処理ができることになる。そして、前回記事とも関わってくる話だが、 テキストデータ作成の際に準拠したレベルについての情報が、この「Best Practices for TEI in Libraries」とともに示されていれば、 利用者がデータを活用する際に大いに参考になるだろう。 そういったことをテキストデータ内に書き込もうとするなら、TEIガイドラインに準拠した テキストデータの場合には、<teiHeader>の中に書き込み可能な<editorialDecl>というエレメント に書き込むことができる。TEIガイドラインに準拠してテキストデータを作成しておけば、TEIに準拠した様々なツールで活用でき、 有用性を高めることができる点も考慮するとよいだろう。

この件の解は、TEIに準拠するだけでなく、他にも、別のデータモデルを作ってみたり、それをRDFで書いてみたりすることも 可能ではあるので、余裕があれば色々な選択肢について検討してみるという手もあるかもしれない。

【頭の整理】日本での「テキストデータベース」作りのステップ3くらい

前回記事では、非ボーンデジタルなテキストデータを元資料を一致させることの難しさについてちょこちょこメモしてみた。とはいえ、そんなことばかり言っていては先に進まないので 解決策、というか、それをどう捉えるべきかということについて少しメモしてみたい。

まず、あらゆる面においてまったく同じものをテキストデータで得ようとするのは無理、ということは確認しておきたい。 たとえば、テキストが書かれた紙や石といった元資料の任意の箇所の化学的組成を確認したいと思ったら、それを 行うことが技術的に一定程度可能だったとしても、現在の ストレージではデータ量が膨大になってしまうので基本的には無理である。また、 字形の微細な違いもやはり再現不可能な場合が多く、さらに、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つを考えておけばよいだろう。 一つは、なるべく正確なものを作成する方向であり、もう一つは、正確でなくてもいいから分析できるように分析の仕方を考えるという 方向である。そして、どちらの方にどれくらい重きを置くか、ということを決めるのが、この局面で必要になることである。

正確なものを作成する方向は、単に、全体として完全に正しいものを目指すというだけでなく、たとえば、 特定の情報がほしいだけであれば、その部分だけは正確性が高まるように、人力と機械をうまく組み合わせてチェックをしたり、 あるいは人力だけで根性で頑張るという手もあるだろう。

一方、正確でなくてもいいから分析できるように分析の仕方を考えるという 方向については、特にデータ量が大きい場合には比較的有効だろう。単なるテキスト検索にしても、 少々誤転記が多くても、大量にテキストデータがあれば、それなりに欲しい情報もヒットしてくれる ことがあるだろう。また、統計的に分析するにしても、統計的に有意であることを示すことが目的 であれば、大量テキストデータでは多少データに誤転記が含まれていてもなんとかなることもあるだろう。 この場合、対象となる大量テキストデータの信頼度がどれくらいかということもサンプル調査などをして 明らかにしておけば説得力は増すかもしれない。

というようなことで、眠くなってしまったので今夜はこれくらいにしておきたい。

【頭の整理】日本での「テキストデータベース」作りの2つ目のステップあたり

前回記事では、「テキストデータベース」作りに関して、その意義とか、テキストデータそのものをどうやって得るか、というようなことをメモしてみた。

今回は、とりあえずテキストデータが入手できたあと、どうすべきか、ということをメモしておきたい。ややもったいをつけて書いているところもあるかもしれないが メモなので気にしないでいいただきたい。

テキストデータ。これが実は非常に難しい。まず、ボーンデジタルなものには生じないが、デジタル以外の媒体に基づくテキストデータにはしばしば大きな問題がある。 それは、「元の媒体上でのテキストと完全に同じではない」ということだ。

すごく細かい話をすれば、字形や文字の大きさは必ず少し異なるはずだ。 このあたりは、まだ内容の相違ということにはならないが、しかし、読み手側が受ける印象には 少し違いが出てくるだろう。たとえば、目が悪い人向けに少し大きな文字にしているかどうか、 あるいは、ディスレクシア向けにユニバーサルデザイン（UD）フォントを使っているかどうか、 ということも、やはり読み手を意識した時にはやや大きな違いとなるだろう。テキストの内容を 分析する場合でも、テキストに対して読み手がどう考えたかということを研究対象とするなら そのあたりも関わってくることがあるかもしれない。もう少し大雑把な話をすれば、石に彫られたものと 紙に印刷されたものとでは受ける印象は大きく異なるだろうが、プレーンなテキストデータには そういった点も特に反映されることはない。

ここから少しスコープを広げると、字体の違いが出てくる。旧字体と新字体を丸めてしまうことは 現在も割とよく行われるようだが、その中には、著者は異なる文字として使い分けた2つの 字体を丸めてしまうとういこともあるかもしれない。できることなら、その使い分けに どういう意味があるかを判断するのは、それを読み分析する側でありたい。しかしながら、 たとえば外注で企業に文字起しを依頼する場合などは、あらかじめJISの第○水準の文字で、 という風に仕様書で限定をかけることになるので、どうしても丸めざるを得ないことになる。

ここまでは漢字の話だが、仮名も丸めたり色々なことをする場合がある。仮名については、 たとえば源氏物語の研究でよく用いられてきたものの一つである『校異源氏物語』では 字母の違う仮名を現代のひらがなに丸めてしまっている。一方で、近年は字母の違いを対象にした 源氏物語研究も行われており、この点は今後大きな課題の一つになっていくかもしれないと 個人的には思っている。

このあたりの、ルールベースでの問題とは別に、単なる誤転記という問題もある。 これは、最終的には人力でチェックするしかないので、正確性を期すなら非常に難しい。 むしろ、「少し間違っていても利用可能なもの」として流通させ利用する方が よいのかもしれない。そもそも、紙媒体でも誤植が混入することはしばしば生じるので あり、デジタルだけの問題でもないということでもあるだろう。

というようなことを踏まえていくと、元資料がデジタル媒体でないテキストデータの 扱いはなかなか一筋縄ではいかないようである。とはいえ、こういった状況に向けた 解決策もちょこちょこあるのでそれは次回にまた書いてみたい。

【頭の整理】日本での「テキストデータベース」作りの最初のあたり

標題の件につき、少し頭を整理するためにメモを残しておく。多分これが本来的なブログの使い方なのではないかと思うので、情報収集したい人にはあまり有益ではないかもしれず申し訳ないがご容赦いただきたい。

テキストデータベースを作る、という取組みは、テキスト研究をしているとどうしても関心を持たざるを得ない。もちろん、 テキストとして書かれたものだけを対象としたところで人間文化の何が明らかにできるのだろうか、という立場もあるとは 思うのだが、テキストほどに高度に集約的で持続性も高い情報伝達手段はなかなかないので、一定の有用性は認めてよいのでは ないかと思っている。

一方で、テキストは、Unicodeなどの文字コードに準拠して並べていけば割と高度な処理が比較的容易に可能となるので、 テキストデータベースをどういう風に作っていくかということは結構重要なのである。 もちろん、Unicodeなどが出てくる以前から、色々なローカルな文字コードを駆使してテキストデータベースは 作られてきていて、日本でも1980年代にはすでにテキスト・データベース研究会というのが活発に活動していたそうだ。

最近は、テキストデータと言えば、みんなで書いているMSワードや一太郎、LibreOffice、Google Docs等の文書、エクセルやパワポ、 Google やLibreOfficeの同種のソフトで作られたデータの テキスト部分、SNSへの毎日の大量の書き込みやブログ等へのほどほどの書き込みなど、いわゆるボーンデジタルのテキスト データが毎日せっせと大量に作成されていて、それらをざっくり分析できれば大変有用な分析が様々に行えそうである。 ePub等で販売されている電子書籍のデータもこれに入るだろうし、テレビの字幕データとか、他にも色々有用そうなものがある。 これについては、技術的には比較的容易だがデータ・文書の権利関係をクリアにするところが基本的には難しい。

一方、ボーンデジタルでないテキスト、には、著作権が切れているものと切れていないもの、著作権がどうなっているか わからないもの、の3種類がある。

著作権が切れているものは、基本的に自由に使える。が、著作権が切れているかどうかの確認は、権利者の没年情報が 必要になるため、著名人はともかくそうでない人は結構確認が難しい。著名人でも、没年の確認は難しい、という 場合もある。

ではこれを踏まえてどうするか、ということだが、基本的に、著作権が切れているものは自由に使えるので それをテキストデータ活用のベンチマークとして扱うのが一つのわかりやすい道だろう。これを通じて明らかに できた様々な活用方法を、権利関係的に自由に活用できることが稀なボーンデジタルテキストの分析に活用することで、 より深い社会文化研究にもつなげられるのではないか、というのが期待されることの一つである。

とはいえ、著作権が切れているものには、現代的な日本語で書かれているものはあまり多くない。しかも、 少し時代を遡ると古文＆くずし字になってしまうため、テキストデータベース作りにおける難易度は高くならざるを 得ない上に、そのテキストの分析手法をそのまま現代に適用するのはちょっと難しい。もう1つ2つ ステップが必要になる。

したがって、比較的新しいところにターゲットをあてるのがよいのかもしれない。明治中期～昭和初期あたり だろうか。このあたりは、最近、国立国会図書館で次世代デジタルライブラリーを公開するなかで OCRによるテキストデータ化もかなり進んでいることが明らかになり、これを用いることで、もう一歩進んだ 取組みが可能となるだろう。

古い日本語の分析手法は、すでに国立国語研究所により古い日本語のUnidicが時代ごとに公開されていて 形態素解析がある程度は可能となっており、また、 情報処理学会人文科学とコンピュータ研究会等では江戸時代以前のテキストデータを 対象とした固有表現抽出やトピックモデリングなどに関する発表が着々と行われており、テキストデータの 分析手法も、まったくできないわけではない。ただ、これはまだ研究段階であり、しかし研究段階だから 面白いということでもある。

また、古い日本語テキストの場合、OCRもかかりにくいということがあり、テキストデータベース 作りの難関の一つだったが、最近は、くずし字OCRやクラウドソーシング翻刻など、自動文字読み取り という方向や人力作業の輪を広げていく方向など、現在の技術水準で可能なことが徐々にこの 領域にもおりてきている（というより、おろしてくださっている若手研究者の方々に感謝である）。

というようなことで、古い方に関しては、精度の問題はあるにせよ、少しずつ進んできている。 その種の仕事とボーンデジタル日本語テキストの分析の間には無数の網の目のような連携の 可能性があるが、そのあたりはまた次に。