今時の簡単なXML論文ファイル作成提出方法/デジタル・ヒューマニティーズ国際会議での事例

論文の本文をXMLで記述しよう、という取り組みは、世界的にはかなり進んでいるようであり、日本でもJ-STAGEが「全文XML」ということで推進中です。 この7月に東京大学が開催予定の、国際デジタル・ヒューマニティーズ学会連合(ADHO)による国際学術大会 DH2022でも、全文XMLでの提出が求められています…が、この学会連合の場合、論文のXMLどころか、写本や碑文、楽譜などの内容のXML化にずっと取り組んできたコミュニティであるため、その種の技術に長けている人が、特に欧米には結構な数いらっしゃいます。そのようなコミュニティですので、以下のようなルーティンで、論文執筆者はXMLタグをまったく見ずに、しかしXMLで構造化された論文ファイルを提出できる仕組みが用意されています。その結果、毎回の発表論文のデータはすべて(2017年大会を除き)全文XMLで利用できるようになっています。(ここでのXMLはTEIガイドライン準拠のものですが、JATS/XML等にもおそらく自動変換できると思われます)。

論文執筆者の手順

さて、これを論文執筆者の手順の方からみてみますと、

  1. 論文執筆者は自分の投稿システムIDでXMLファイル作成システムにログイン

  2. 自分の名前・所属・発表タイトル等が入力された、MSワードかLibreOfficeのテンプレートファイルをダウンロード

  3. MSワードかLibreOfficeでテンプレートファイルに本文・図・脚注・参考文献一覧などを記入

  4. XMLファイル作成システムに再度ログインしてXMLファイルを生成してダウンロード

  5. XMLファイルは画像ファイルや変換済みHTMLファイルなども含めてzipアーカイブ(拡張子は.dhc)としてまとめられてダウンロードされるのでそれを投稿システムにFInal Upload

という風になります。ですので、論文執筆者は、XMLタグをまったく見ずにXMLファイルを作成できているのです。

システムの裏側

このシステムの裏側ですが、JAVAで書かれたDHConvalidatorという、この会議のために作成されたソフトウェアがあります。 この学会連合ADHOのGitHubアカウントで公開されているのですが、デジタル・ヒューマニティーズは学会連合でもGitHubアカウントを 持っていてソフトやデータを公開しており、その一環という位置づけになっています。誰がコントリビュートするのか、と言えば、 欧米のDH分野には、プログラミングにはまってシステム開発もできるようになってしまう、いわゆる「作る人」が結構いて、 そういう人たちに大学院~ポスドクの間に学会連合が謝金を出しながら作業していただく、というのが割と一般的です。そうすると、 「自分たちが使いたい物を自分たちで作る」形になりますので、仕様書作成とか作りたいものの説明などの手間が 激減しますので、頼む側は安くで作れて、作成者はお金をもらいながらスキルも身について人脈もできて、 できあがるものもそんなに悪くない…という風になっています。さらに、学会を開催するたびにDHConvalidatorをセットアップして使う、となると、そのたびに作った人や メンテをしている人たちに色々おうかがいすることもでてきますので、人脈作りという意味では若手にはうってつけでしょう。 このソフトウェアは汎用性が高く、次に述べるConftoolを使っている学会ならそのまま使えますので、実際に他の学会でも これを利用して論文をXMLで提出させるところがあるようです。

次に、データ構築の効率化について少しみておきましょう。 ADHO関連学会では、学会開催時の投稿管理システムとしてConftoolというサービスを使っていますが、この システムではAPIで外部から認証できるようになっており、DHconvalidatorは、この認証APIを用いて認証したり、発表者の名前・所属・発表タイトルといった 基本的な情報を取得して自動的にXMLで記述してくれます。つまり、一度投稿システムに自分の情報を登録すれば、そこから一気にXMLのデータまで できてしまいますので、ユーザ側の操作が少なくてなかなか親切です。

実際の変換に際しては、DOCX等の色々なファイル形式をXML等のファイル形式に変換してくれるOxGarageというサービスがありまして、 デフォルトだとこのAPIを用いて対象ファイルをXMLに変換しています。

そういうものだと設定は結構面倒なのではないか…と思われるかもしれませんが、今時の仕組みですので、dockerで全部入りのものが動かせるようになっています。 実は、dockerに頼らずにやってみようかとしばらくあれこれ試してみたのですが、結局挫折しました…。で、dockerで動かした上で、Apacheのリバースプロキシで 外部から使えるようにしています。

まとめ

というようなことで、世の中ではXMLを使うべしとかXMLはもう古いとか色々おっしゃる向きもありますが、基本的に、楽な方に、使いやすい方に流れていきますし、 「作る人」が一定数確保できている分野では、色々便利なものが提供されるようになる、ということでもあります。「作る人」のみなさんを大切にしましょう、ということで 今夜はここまでとしたいと思います。

日本発のプレプリントサーバJxivに論文を載せてみました

いわゆる10兆円ファンドの運用主体としてますます注目を浴びる科学技術振興機構(JST)が、最近、プレプリントサーバの運用を開始したそうです。その名もJxiv。すでに海外にいくつか著名なプレプリントサーバがあり、国内でも筑波大学が筑波大学ゲートウェイというプレプリントサービスを含む包括的なサービスを開始していることもあり、どういったところで個性や存在意義を打ち出していくのか、気になるところです。とりあえず「誰でも投稿できる」「日本語論文でも大丈夫」「人文系でも大丈夫」というのが特徴になるような印象を持ちました。(間違っていたら申し訳ありません)

プレプリントサーバは、サイエンスの崇高な理念を体現する存在であり、オープン性を踏まえた知識循環の基盤となるものと認識していたところであり、また、それゆえに、そのラディカルなオープン性に親和性が高くない分野やワークフローなどにはちょっと縁遠いものかもしれないと思ったりもしていたところでした。

とはいえ、この種の動向は、1990年代から遠巻きに見ていただけで、なかなか自分で投稿するには至らず、しかしながら、いつまでもそうしていてもわかることは少ないので、よい機会だと思って、いずれ某雑誌に投稿しようと思って温めていた原稿を投稿してから考えてみることにしました。

もちろん、忘れてはいけないのは、「未発表論文であること」を投稿規定に掲げている論文雑誌は結構多く、プレプリントサーバで公開した時点で、投稿できる雑誌が結構減ってしまう、という点ですが、まあ、どこかに投稿できるはずだと思ってとりあえず投稿してみたのでした。

ここでまず、正直に申し上げると、Jxivが公開された時点では、この「投稿ガイドライン」というタブやそこに掲載されたPDFファイルは、いずれも「ガイドライン」となっているだけで、ここに投稿に関する必須事項が記載されているとは気がつかず、まあガイドラインだから守っても守らなくても掲載はできるだろう…と甘くみて投稿してみたところ、色々足りないということで丁寧に確認していただき、いったん差し戻されました。

これは、「ガイドライン(当時の名称)」をちゃんと読めば書いてあったことですので、みなさまにおかれましてはきちんと読むことをおすすめしますが、「ジャーナルに投稿する論文を投稿せよ」という話であるにも関わらず、自分が投稿するジャーナルのフォーマットで投稿したら、ダメ、ということでしたので、このあたりの「ジャーナル」の定義や位置づけなどは、どこかの分野に沿ったものなのかもしれないとも思ったところでした。とくにびっくりしたのは、「利益相反に関する開示」の記載が論文中に必須だったことで、これは人文系の日本語論文ではそんなにみないかなあ…と思ったのでした。日本語論文の論文中に書く場合の書き方もよくわからなかったので、ググって調べてみました。ただ、利益相反の定義は学会によって異なる場合もあるようで、学会、あるいはジャーナルとして、利益相反に関する開示を記載する基準を提示しなければ、あまり有用な開示はできないのではないか、とも思ったところでした。あるいは、人文系にも対応するということであれば、過渡的には、この記述は任意にしてもいいのかもしれないとも思ったところでした。

最初の方だったせいか、結構丁寧に対応していただいて、こちらとしても大変恐縮してしまったところではありますが、一方で、こういうチェックをすることで、1日あたり何本くらい処理可能な体制になっているのだろうか、というのもちょっと気になりました。

なお、差し戻された際に「これは「ガイドライン」という名称ではなく「投稿ガイドライン」にした方がよいのではないでしょうか?」と担当者にお伝えしたところ、今は「投稿ガイドライン」としていただいたようで、同じことを言ったのは私だけではなかったのかもしれませんが、いずれにしても、このあたり、手作り感があっていいですね。

というようなことで、最初の方で書いたことに少し戻るのですが、「未発表論文であること」と投稿規定に掲げている雑誌については、「ただしプレプリントサーバについてはその限りでない」というような文言を投稿規定に追記してもらわないと、今のところはプレプリントサーバを使うことはできなさそうですね。ちょっと投稿規定をググってみましたが、ちょっとググった限りでは、どこの学会も「未発表論文」を条件に挙げていました。既発表論文を査読・掲載してくれる雑誌、という言い方をすると、それはそれで色々問題がありそうですので、やはりプレプリントサーバを例外的な場として位置づけてもらうのが穏当なのだろうと思いました。

とはいえ、プレプリントサーバと言っても、結局、査読前論文が公開されてしまうのだとしたら、いくつか難しい問題が登場してきそうです。すでにプレプリントサーバをワークフローに組み込めている雑誌ではそのあたりを十分に議論した上でクリアできているということなのだと思いますが、やはり、一度公開されている論文に対して査読をするのは、査読者側の負担が少し大きくなってしまうのではないかというのは気になるところです。未発表論文への査読に比べて、査読の内容についての説明責任がよりオープンなものとなることが想定されるからです。もちろん、サイエンスの発展を願うならその方が理想的なのですが、そもそも査読という行為は負担が大きい割に具体的なリターンが少なく(本来は、学術の水準を維持するという大きな意味での極めて重要なリターンはあるのですが)、それがプレプリントへの査読ということになると、説明責任が重くなる分、査読の引き受け手がますます減るのではないか、というのはちょっと気になるところです。メジャーな分野ならそれでも大丈夫かもしれませんが、マイナー分野で潜在的査読者が少ないところだと、説明責任のプレッシャーを増やすことはちょっと難しい状況を生み出すかもしれない、と、少し心配になるところではあります。

それから、人文系のなかには、出版社に雑誌刊行を頼んで市井で販売しているところもまだあるように仄聞しておりますが、そうすると、プレプリントサーバに載せて原稿を公開すると売れなくなってしまうという心配が出てきてしまわないか、ということで、そういう雑誌はプレプリントサーバの話には乗ってこないかもしれないとも思いました。

これに加えてやはり気になるのは、J-STAGEであれほどJATS/XMLを推しているのに、Jxivは今のところJATS/XML等による全文XML投稿は受け付けていないようだ、ということです。技術的には、JxivはカナダのPKPが開発しているOpen Jounarl Systemという気の利いたオープンソースのシステムで構築されているようであり、確か、JATS/XMLを使えるようにするためのプラグインがあったような気がするので、それを導入すれば割と簡単に全文XML投稿できるようになるのではないかと思ったりもしました。が、まあ、ワークフローを絞り込むのは運用コスト低減には重要なので、そのあたりを考えてのことかもしれませんね。

というようなことで、みなさまにおかれましても、ご自身が投稿予定の雑誌の投稿規定を確認した上で、問題なさそうならぜひプレプリントサーバを試してみましょう!それから、投稿前には「投稿ガイドライン」を熟読しましょう!

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

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

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

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

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

marketplace.sshopencloud.eu

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

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

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

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

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

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

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

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

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

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

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

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

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

f:id:digitalnagasaki:20220227020535p:plain

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

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

f:id:digitalnagasaki:20220227020642p:plain

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

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

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

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

f:id:digitalnagasaki:20220226212009p:plainf:id:digitalnagasaki:20220227015627p:plain

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

f:id:digitalnagasaki:20220227015811p:plain

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

f:id:digitalnagasaki:20220227020104p:plain

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

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

f:id:digitalnagasaki:20220227020822p:plain

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

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

f:id:digitalnagasaki:20220227021254p:plain

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

f:id:digitalnagasaki:20220227021759p:plain

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

f:id:digitalnagasaki:20220227021832p:plain

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

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

前回記事の続き。

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

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

f:id:digitalnagasaki:20220225013136p:plain

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

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

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

f:id:digitalnagasaki:20220225015600p:plain

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

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

f:id:digitalnagasaki:20220225020927p:plain

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

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

f:id:digitalnagasaki:20220225021536p:plain

ここでは、人称代名詞を<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つを考えておけばよいだろう。 一つは、なるべく正確なものを作成する方向であり、もう一つは、正確でなくてもいいから分析できるように分析の仕方を考えるという 方向である。そして、どちらの方にどれくらい重きを置くか、ということを決めるのが、この局面で必要になることである。

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

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

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