前回記事の続きのようなものですが、しかし、これも大きなトピックかもしれないと思いましたので、記事を分割しました。
一つの画像に、赤外線写真とX線写真を重ね合わせてみる、というものも、汎用ビューワでできるようになったようです。まずはこちらをご覧ください。以下のような写真が表示されるはずです。
ここで、前回記事と同様に、左上の「Layers」というタブをクリックしてみてください。そうすると、X線と赤外線の画像がそれぞれ選択できる上に、透明度も調整できるようになっています。もちろん、同時に拡大縮小することも可能です。たとえば以下のような感じです。
このような用途の場合、各地の画像をどうこうするというのとはまた少し違った話になってきそうですが、標準的な規格とツールを使ってこのような表示ができるようになるということには、色々なメリットがありますので、これも今後に期待されるところです。
また少し時間がたってしまいましたが、今回は、6月にヴァチカンで開催されたIIIFカンファレンスで仕入れてきた話を一つご紹介します。IIIFが当初目標としていた、「バラバラになって各地の機関に保存されている西洋写本の断片をまとめて表示する」という機能が、ようやく、IIIFの規格に基づいて、IIIF対応の汎用フリーソフトMiradorビューワを用いて可能になったようです。
まずは、こちらのURLをご覧ください。ここでは、以下のように、挿絵の部分が切り取られた写本の画像が表示されます。
ここで、画面左上の「Layers」というタブをクリックしてみてください。そうすると、以下のようなパネルが表示されるはずです。
ここで「visible」というチェックボックスをクリックしてみてください。そうすると以下のようになって…
切り取られた挿絵のところに以下のようにしてこの絵が表示されました。
挿絵のところを拡大してみてみましょう。
この挿絵が本来ここに来るべきものなのかどうか、筆者にはよくわからないのですが、このような機能のデモンストレーションとしては十分ではないかと思います。今回はフランスの国立図書館が公開する画像とCNRSが公開する画像を組み合わせたということになっているようです。Manifestファイル（この資料の画像群の表示の仕方等を定義するファイル）のこのページの部分は以下のようになっていました。
ちょっと字が小さくて読めないかもしれませんが、ちゃんと見たい人は直接このmanifestファイルをご覧ください。IIIF Image APIで記述された二つの画像のURLを一つのキャンバスにリンクされています。書き方としては、もっとたくさんの画像を一つのキャンバスにリンクすることも可能であり、Miradorの今回のバージョンでは、実際に、もっとたくさんの画像を重ねあわせて、さらに透過度も変化させることができるようです。開発者の方々に大感謝です。
これまでも何度も同じことを書いてきているようで恐縮ですが、10年前にはすでに、このようにして絵を重ね合わせる機能だけであれば、Webで提供することはできたはずです。しかし、IIIFが画期的なのは、その機能をオープンな共通規格として実現可能としたことであり、その規格がすでに世界中の多くの有力機関で採用されつつあるという点なのです。結果として、誰もがこのような機能を使って、世界中に点在する多様なデジタル文化資料を様々な形で自在に活用できる道を開いた形になっています。この重ね合わせる機能に関して言えば、今はまだManifestファイルを頑張って書かなければなりませんが、しかし、書き方は標準化されているので、近いうちに、これを簡単に書けるような仕組みを誰かが作って公開してくれるかもしれない、ということが期待されます。デジタル文化資料の活用において、オープンな共通規格の重要性は、これからますます明らかになっていくだろうと思っております。
なお、今度、7/27の午後に、人文学オープンデータ共同利用センター（CODH）にて、IIIFを主に扱うセミナーが開催されます。会場は、国立情報学研究所（NII）、です。そちらでは、こういった話を、私だけでなく、色々な専門の方々がそれぞれの視点からお話してくださる機会になりますので、なかなか稀有な機会になると思います。お時間がございましたらぜひご参加ください。
最近、メタデータの書き方について相談を受けることが多いので、今回は、写本や貴重書的な資料の書誌情報の書き方に関して、ちょっと事例を紹介させていただきます。
テクスト資料のデジタル化に関しては、いわゆるISOのような規格ほどかっちりとしたものではないのですが、人文学資料向けに TEI (Text Encoding Initiative)というガイドラインが公開されています。これは、人文学資料向けというくらいですので、希望すれば非常に細やかな構造化が可能で（しかし浅い構造化もできて）、対応可能な分野も様々です。（たとえば、コーパス言語学では各単語の属性に着目しますが、古典文献学ではどちらかというと書誌情報や異文に着目する、という風な違いがあります。）
このTEIガイドラインでの構造化は、現在はXMLで行うのが主流になっています。TEIガイドラインは、本来は特定のマークアップ言語に束縛されるものではなく、当初はXMLの前に使われていたSGMLというマークアップ言語に準拠したものでしたが、XMLが策定されるにあたってコンセプトのレベルで貢献した上、XMLの策定後数年で、自らもXMLに移行した、という経緯を持っています。
といっても、この動向はほとんど欧米で展開されてきたため、欧米・中東近辺の文献には比較的強いですが、それ以外の地域となるとまだ十分に対応できていません。それをなんとかするための動きがようやくアジア地域の研究者によって始まってきているところですが、そのご紹介はまた別の機会にして、今回は、TEIガイドラインの事例として紹介されている書誌情報の書き方についてちょっと見てみたいと思います。
日本で書誌情報、と言えば、OPACに入るような情報や資料調査に入った方々の調査票など、様々なものがあります。もちろん欧米でも、すべての機関が同じやり方をとっているわけではないようなのですが、TEIガイドラインでは、なるべく担当者・利用者のニーズにあわせた詳細な書誌情報にも対応できるように、ということで、深い情報も書き込めるようなルールを提供しています。（なお、TEIガイドラインのエレメント名、属性名、それぞれの一言解説に関しては、鶴見大学の大矢一志先生が日本語訳を提供してくださったおかげで大部分は日本語でも参照できるようになっています。）
これを理解するのに役立ちそうなエレメントとして<history>がありますので、TEI P5ガイドラインからその利用例をちょっとみてみましょう。これは、以下のように、オックスフォード大学ボドリアン図書館に所蔵されている手書き資料の目録をTEIガイドラインに従って記述（構造化）したというもののようです。（私の理解は十分ではないかもしれないので、修正すべき点がありましたらご教示ください）
この書誌情報には<history>という要素が含まれており、以下のようになっています。
ここでは、いわゆる来歴情報が書かれていますが、来歴の中で、<orgPlace>や<orgDate>などといったタグを用いて、最初にいつどこで書かれたかという情報がマークアップされています。<quote>というタグもありますので、何らかの引用ではないかと思われます。ただ、これだけですと、ちょっと情報量が少ないような感じがしますね。
おそらく、上記の<history>をさらに詳細にマークアップしたと思われる例も掲載されていましたので、ちょっと見てみましょう。
これをみると、来歴情報の本文が、まず<origin>と<provenance>と<acuisition>という風に分かれています。これで、出所の情報か、それがどこを渡ってきたのか、どうやって入手したのか、ということがそれぞれ機械可読（≒コンピュータが読んで処理できる形式）になっています。機械可読になっているということは、人にとっても読みやすい、つまり、この情報を元に、自動的にきれいなレイアウトを作って人が読みやすい形に提示することもできますし、もちろん、コンピュータが、複数の資料から出所情報だけ、あるいは入手情報だけを取り出して統計情報をとったり、それもまた人が見やすいように地図・年表上にマッピングしたりすることもできるようになります。
そして、<origin>の中を見てみると、ここでは13th cent.となっているものに関して、「notAfter="1300"」、つまり1300年以前、ということが、機械可読の形でXMLの属性・属性値として追記されています。こうしておくと、13th cent.という表記はそのままにしておきながら、この表記が何を意味しているかをコンピュータに解釈させるためのプログラムを作成するという手間を省き、かつ、正確な情報をコンピュータに渡せるようになります。
それから、次はその後の来歴ということで、<provenance>タグで囲まれた文章があります。ここでは、引用がラテン語であることが<quote>の属性として xml:lang="la"と記載されています。（これはISO639に基づくことになっています）言語の自動判定というのは、文章が短いとなかなか難しいのですが、このように書いておくと、自動判定に失敗したというような問題に悩まされることはありません。（もちろん、これには一長一短があります）。
最後に、入手した際の情報が書かれています。これもまた興味深いものがあります。<name>タグで囲まれているのが、人名ですが、人名の表記には、略称も含め様々な表記があり、一括検索するのはなかなか難しいことがあります。この目録では、<name>タグに属性としてkeyを用意して、おそらく、この人物と同じ人物については、表記の如何に関わらずkey="MCRAYWD"としているのだろうと思われます。そうすると、あとからこのデータを見たり検索したりする人やコンピュータにとって、表記の仕方が違っていても同じ人物としての同定が簡単かつ確実になります。人物同定は、ある程度知識のある人でなければ難しいことですので、その知識を明示して継承できるようにするという意味合いもあるでしょう。（※XMLに詳しい人への補足としましては、このkey属性は、TEI/XMLではむしろ他のところで定義された人物情報のxml:idを参照する形でsameAsという属性を使用する例が多いように思います）。入手した日付に関しても、<date>エレメントのwhen属性としてW3C-DTFの形式で記述されており、これも記述の一意性を提供することで人にもコンピュータにも理解しやすいものとなっています。
このように、来歴情報などに関しても、必要に応じてきちんとマークアップしていくという方法をTEI/XMLでは提供しています。データ公開・検索等の実際の運用では、たとえばDublin CoreのDescriptionのあたりにこれらをまとめて入れてしまうという手もあるかもしれませんが、いずれにしても、特定のフォーマットにあわせて書誌情報を記述していくというよりはむしろ、コンピュータに処理させたい、さらに言えば、他の人や後の人にも、ある程度明確な定義を伴う形で自分の知っている知識を継承したいという目的でTEI/XMLは用いられることがあり、そのような方向で発展してきている面があるということが言えるだろうと思います。このようなやり方が日本の古典籍・古文書等でも役に立たないだろうか、ということを日々考えておりますので、もしご関心がおありの方がおられましたらぜひお声がけください。
ところで、この部分的なマークアップの説明からもわかるように、TEI/XMLでは、多様なマークアップの深さを許容しています。この点は他の諸々の規格と大きく異なるところではないかと思います。また、上記の2例のうち、最初の方は、<history>の内部を、どちらかといえばコンピュータに自動的に読み取ってもらうことを期待するやり方であり、二つ目の例は、人間が確実に記録してコンピュータに正確に読み取らせることを意図したやり方であるとも言えるでしょう。TEI/XMLが1987年から続いているものであることに鑑みるなら、当初は後者のやり方ですべて人が行うことが重要であったように思われますが、近年では、自動読み取りもそれなりの正確性を持つようになり、そのような状況では、2つめの例は、むしろ自動読み取りソフトウェアのための学習用データとして用いるという可能性も考えられるところです。また、写本・貴重書等の書誌情報では、大規模処理というほど多くのデータが集まらない可能性もあり、その場合にはむしろ、一度コンピュータで諸々の情報を判定させた後に、人が手で修正し、その結果を2つ目の例のフォーマットで書き残せるようにする、という方法もあるかもしれません。
それから、ちょっと話が飛びますが、このようなマークアップを実際に作業する場合、普通のエディタで作業するとタグの入れ子関係等がおかしくなった時の確認などになかなか大変です。これを支援するためにXMLエディタというのが色々出ています。筆者は、商用ソフトではありますが、oXygen XML Editorというソフトウェアを使っています。（一応、30日間の無料使用期間があります）このソフトはXMLだけでなくJSONやその他色々なフォーマットの処理ができる上に、TEI/XMLのスキーマも標準装備していますので、初期設定も簡単です。タグ補完機能やフォーマットのチェックなどで非常に充実した機能を持っていますので、とりあえず初心者にはこのソフトをおすすめしています。とはいえ、このソフトは、使い方がわかるととても便利なのですが、最初のハードルが結構高いです。ので、この数年、無料講習会を各地で行っています。ご興味がおありの人がおられましたら、3人以上集まるならおうかがいして講習などいたしますので、ぜひお声がけください。
HTTPSに関して説明する必要はもうあまりないと思います。Webで暗号化通信とサイトの身元保証をしてくれる仕組みですね。これまで、HTTPSは、主に送信されるデータに比較的高度なセキュリティが必要な状況、たとえばパスワードを送信する時などに主に使われてきたように思います。しかし、最近、IOSアプリでHTTPS通信が義務化されることが話題になり、通常のサイトでも必要になってきているような雰囲気が出てきています。
IOSアプリのそのような動向の一方で、通常のパソコン用のWebブラウザでも、HTTPSのサイトを閲覧しながらWeb API的な形で他のサイトのデータをとってくるような仕組みを用意しようとした時には、セキュリティを高めるために他のサイトもHTTPSでなければならない、という縛りがかかるようになりました。ここで具体的に影響を受けるのは、Mirador等のIIIFビューワです。HTTPSのサイトに設置されたIIIF Viewerからはhttpsで配信されている画像しか見えないのです。そして、最近いよいよHTTPSのサイトが増えてきましたので、なんとか対応する必要に迫られそうになってきております。今からIIIFを導入する予定の人／組織は、HTTPSも必須だと思っておいていただいた方がよいと思います。
今のところ、大手の中では、gallicaのIIIF画像はまだHTTPS化されていないのですが、これも、関係者はHTTPS化の必要性を認識しているようでしたので、そのうちHTTPS化されるのだろうと思います。
そこで、せっかくHTTPSに対応するのだから、ついでに、画像配信が速くなるというHTTP2も導入できないかと色々調べてみました。
その結果、わかったことは、筆者が使っているRedHat LinuxやCentOSでは少々難しいようである、ということでした。というのは、OpenSSL1.0.2以上でないとブラウザ側がうまく対応できないことがあるらしいのですが、RedHat LinuxaやCentOSでは、まだOpenSSL1.0.1対応のものばかりで、いくつかのメジャーなRPMリポジトリを見てみましたが、まだOpenSSL1.0.2以上に対応しているものがないようなのです。Ubuntuの新しい方なら大丈夫、とのことなのですが、サーバにUbuntuを入れ直すのも大変なので、さてどうしたものかとしばらく止まっていました。
とりあえずHTTPS化だけはしなければ、ということで、最近話題のLet's Encryptを使って試しに設定してみたところ、今までの苦労はなんだったのか、というくらい、拍子抜けするほど簡単でした。これは所定のガイドに沿って作業するだけでできてしまうので、画像配信にしか使っていないサーバであれば、試してみるとよいかと思います。
さて、しかし、HTTP2にすると速い、という話をさんざん聞くので、画像配信をもう少し速くしたいと思っていたこともあり、結局、ソースコードからコンパイルという禁断の方法に手を出してしまいました。何が禁断かということ、セキュリティアップデートなどの際に、再度自分でソースコードからコンパイル・インストールを毎回やらねばならなくなるからです。20年前は一生懸命やっていましたが、これだと継続性に問題が生じがちなので、10年ほど前にはほとんどやらなくなり、パッケージからインストールするようになっていました。（意味がわからない人のために簡単に説明しておくと、Windowsアップデートのたびに必要なソフトを一つずつそれぞれのサイトからダウンロードしてインストールして設定も個々に行って、さらに互換性も自分で確かめる、というようなことになります。） ですので、企業等に今の段階でこれをお願いする場合は、追加料金を結構払わねばならない場合があることに留意しておいてください。あるいは、仕様書にHTTP2と書いてしまうと、見積額が少々高くなる可能性があります。もちろん、発注の規模次第ではそんなに差はでないこともあると思いますが。
前置きが長いのは、HTTP2に関しては、今のところは安易に導入を決めないようにしていただきたいからなのですが（でも、これにごく安価に対応できる企業さんがおられたらお知らせいただけるとうれしいです）、それでも、画像配信は多少はやくなるようです。一つのサーバで、HTTP1.1、HTTPS+HTTP1.1、HTTPS+HTTP2で、IIIFビューワMiradorを設定して91個のファイルを一気に配信されるようにした時の計測結果は以下のような感じでした。サーバソフトはApache 2.4.25、サーバOSはCentOS7.2、opensslは1.0.2k、という感じでした。
| HTTP1.1 | 3.742857143秒 |
| HTTPS + HTTP1.1 |
4.511428571秒 |
| HTTPS + HTTP2 | 3.8秒 |
7回アクセスして平均値をとってみています。こうしてみてみると、HTTPS化して遅くなった分をHTTP2で取り返す、というような感じになっているようにみえます。さらにアクセスが増えてくるとまた違う結果になるかもしれません。また、Nginxを使えばもっと速いかもしれません（今回は既存サービスとの互換性を考えてApacheにしてしまいました）。もう少しよい調査方法を試してみることができたら、またちょっとご報告してみたいと思います。
さて、このインストール方法ですが、とにかく必要なソースコードをダウンロードしてコンパイルしてインストール、設定、を繰り返しました。具体的な内容については、また次回記事にてご報告させていただきます。
IIIF対応ビューワの代表格の一つ、Miradorですが、アノテーション機能と複数画像同時表示機能という大変便利な機能を提供してくれている一方で、右から左へのページめくりに対応していないため、東アジア系の資料に適用することがなかなか難しい状況でした。以前に、対応版を作ってみましたが、ちょっと機能的にいまいちでしたので、改めて、最新版をもとに追加しなおしました。それがこちらです。
…と言っても、これだけですと、Miradorの使い方を知っている人でないとあまりよくわからないと思います。そこでご用意したのが以下のものです。
http://candra.dhii.jp/nagasaki/mirador20170506/mirador/index2.html
右から左へのページめくりと、左から右へのページめくりが一つのビューワで混在できていると思います。ただし、「ギャラリー表示ビュー」のサムネイル一覧だけは、残念ながらまだ対応できていません。力不足で申し訳ありません。（どなたかやってみていただけると大変ありがたいです）
※もう少し調べてみたら、できました！というわけで、以下のものが完成版（？）です。
http://candra.dhii.jp/nagasaki/mirador20170507/mirador/index2.html
慶応大学メディアセンターデジタルコレクションのIIIF対応画像も、これで右から左のページめくりができるようです。Miradorの使い方をある程度ご存じの方向けになってしまいますが、たとえば以下のIIIF Manifestかdrop iconなどをお試ししてみてください。
http://dcollections.lib.keio.ac.jp/sites/default/files/iiif/NRE/110X-274-3-1/manifest.json
なお、ビューワ自体をダウンロードしたい場合はこちらからどうぞ。(.tgz形式です）
それから、この仕組みについて、少しだけ御説明しておきますので、まだご存じないという人で、かつ興味がある人はちょっと読んでみてください。
まず、IIIFでは、一つの資料ごとに「IIIF Manifest」というファイルを用意することになっています。IIIF Manifestは、JSON-LDというWebで今流行しているフォーマットに基づいて書かれているものです。JSON-LDは、World Wide Web Consortium (W3C) で定められている規格であり、このフォーマットに従うことでJavascriptのプログラムがデータ間のリンクを簡単かつ効率的に解釈できるようになります（この説明は簡潔すぎてちょっと語弊があるかもしれませんのでご注意ください）。そして、JSON-LDに従ってどういう内容を書くべきか、ということについてはIIIF Presentation APIにおいて規定されています。（もう一つ関連する重要な話としてWeb annotationというデータモデルがあるのですが今回はそれについては省略します。）
このIIIF Presentation APIでは、プロパティと値、という形で、一つの資料に関する様々な情報をIIIF manifest記述してブラウザに渡すことになります。資料に含まれる各ページ画像のURL、資料のメタデータ、資料に付与されたアノテーションのURL等がここには含まれることになります。資料の提供者やライセンスの情報もここに書き込むことになります。Webブラウザに読み込まれたIIIF対応ビューワは、このIIIF Manifestを受け取って、必要な画像やその他の情報を集めて、適宜整形してWebブラウザ上に表示することになります。
さて、このIIIF Manifestに書いてもよいプロパティの中でviewingDirectionというプロパティがあります。これによって、一つの資料に含まれる画像を見ていく方向を規定できるようになっています。日本語資料のように右から左にページをめくっていく資料の場合には、"viewingDirection:right-to-left"と書くことになっています。IIIFという規格では、このようにして、右から左にページをめくっていく日本語等の資料にも対応しています。
しかし、これは、あくまでも、規格上の記述の仕方の話です。このように記述しておけば、あとは、利用者側（で使っているビューワ等のソフトウェア）がそれを読み込んで右から左にページめくりできるようにすればよくなるのですが、そのビューワは誰が用意するのか、という話が次に出てきます。
実は、IIIF対応ビューワの代表格の一つであるUniversal Viewerであれば、すでにその機能が実装されています。（例）ただ、Universal Viewerも優れたビューワの一つではあるのですが、こちらだと、せっかくつけたアノテーションが表示されなかったり、複数画面表示ができない、といった感じで、やや不足感があります。そういう機能を使ってみたければ、やはりMiradorをなんとかしなければ、ということになります。そこで今回、改めて、新しいMiradorにこの機能を組み込むことに挑戦してみたのでした。
基本的には、ページめくりに関しては画像の順番の変更、サムネイル画像の並べ方に関してはCSSのdirection:rtlで対応しています。ページめくりに関しても、ページめくり矢印の機能を左右逆にするだけでもよかったかもしれないのですが、以前に実装した際にすでに画像の順番変更で対応してしまっていたので、その続きということでそのようにしてしまいました。ページめくり矢印の機能を逆にする実装の仕方もおいおい検討してみたいとも思っております。
なお、このIIIF Presentation API及びIIIF Manifestについてより理解を深めたい人は、LOD Diaryの神崎正英さんによる連載をぜひご覧ください。
さて、本日は夕方からデジタルアーカイブ学会設立総会に参加する予定です。すでにWebサイトには「デジタルアーカイブ学会設立趣意書」が公開されていますので、目指す方向はここで提示されているものと思われます。
これを拝見してまず思ったことは、学会に副題をつけるとわかりやすくなるかもしれない、ということです。たとえば、「デジタル知識基盤社会のための政策形成に向けて」などといったような感じです。「デジタルアーカイブ」という呼称だけだと、「何がデジタルアーカイブか」という終わりがなく生産性の低い議論を呼び起こしがちなので、それを避けるための一工夫があるとよいのではないかと思ったところです。
趣意書を私が理解したところでは、かつてキャリア官僚が、最近はシンクタンクが担ってきたようなことを、これからは学会が担うのだ、という話のように読めます。かつて県立大学の教員をしていた頃に地方自治体で某総研会社の人と仕事をした身としては、確かに、シンクタンクの力は大きくて、しかもそこにそれなりのお金も流れているようだった、ということを思い出しつつ、ああいう仕事を学会と名付けられた組織が担うことが可能なのだろうか、ということは若干気になるところではあります。知る限りでは（すごく狭い経験ですが）、シンクタンクは、調査力だけでなく見せ方が上手で、そこにも相当のリソースを投入しているであろうことが想像されますので、それにとって代わろうとするなら、同じ事を肩代わりする必要はないにせよ、相当な説得力のある何かは提示できる必要があろうかと思います。それが、「中央省庁から民間企業、地域の草の根の活動までが、高い次元で車座的に話し合い、共に考え」ることなのだろうと想像していますが、そのような場をどういう風に形成していくのか、今後に期待したいところです。
それから、「デ ジタルアーカイブに関わる諸学会、研究者を繋ぎ、共通の認識基盤を形成しながら、こうした具体的課 題に取り組んでいきます」とのこと、設立準備委員会が主導してこれを進めているのだと思いますが、これについては、とにかく、うまくやっていただけたらと思っております。
最後の段落では、すべてのステイクホルダーへの呼びかけ、価値のあることだと思います。難しいことではありますが、声が大きな人だけでなく、関係者皆が参加意識を持てるような形になってもらえたらと思っております。ちょうど10年前に、この種のステイクホルダーの問題について人文科学とコンピュータシンポジウムで発表したことがありますが（「人文科学のためのデジタル・アーカイブにおけるステイクホルダー」）、この趣意書での議論は政策としての基盤というところから立ち上げていこうということなので、話としてはもっと大きくなるのだろうと思います。この種の問題に技術・実務・研究の面からそれなりの期間関わってきた経験からしますと、とりわけ、人事ローテーションでたまたまデジタル知識基盤に数年間の仕事として関わる人たちと、仕事でデジタル知識基盤を利用するユーザや所蔵者、創作者、提供者、作成者（企業含む）等の立場でずっと仕事として関わり続ける人たち、それから、たまにちょっと関心を持ったときだけ利用するようなライトユーザ（これは、ヘビーユーザと区別すべきでない、という議論もありますが、区別した方が良い状況が確かに存在します）との感覚の違いをうまく乗り越えて議論できるような場を作ってくださるとありがたいと思っております。
いつアナウンスされたのかよくわからないのですが、国文学研究資料館の古典籍のデータベースに「書誌URL」というものがつきました。これはいわゆるパーマリンクに近いものなのではないかと想像しています。たとえば、下記の引用画像の赤線部をご覧ください。
これまで、公式には、こういったURLが書誌情報に関しては発行されておらず、普通のユーザからは、この書誌のページをリンクすることができませんでした。が、現在、それが、この「書誌URL」からできるようになっているようです。たとえば下記のブログなど、さっそく、専門の方々からも喜びの声があがっているようです。
これで、万単位の古典籍資料が「この資料を」と言って提示する時にURLで直接提示して公式サイトにリンクできるようになりますので、地味ですが、本当に大きな進歩です。
特に国文学研究資料館の古典籍のデータベースに関してのこれまでの問題点は、細かいところでもいくつかあるのですが、大きなものとして、（1）書誌情報に外からリンクを張れないために、URLで典拠情報を提示できなかったことと、（2）画像のページには外からリンクを張れるが、そこから書誌情報のページに戻れないために、画像を見ても何の画像だかすぐにはよくわからない（＝画像自体を自分で見て判断するか、書誌情報を別途検索して探さなければならない）、という2点がありました。このうち、（1）が解消されたということになります。
このことを知ったときにすぐに思い浮かんだのは、先月に急逝された古瀬蔵先生のことです。古瀬先生は国文学研究資料館の情報部門の責任者としてこの十数年ほどお仕事をしておられ、2011年のもののようですが、お人柄をよくあらわした（ように個人的には思っています）ざっくばらんなご対談が、国文学研究資料館のある立川市のタウン誌のサイトに掲載されています。研究領域が近かった古瀬先生とは色々な研究会を通じてお話しをすることがあり、この数年は国文学研究資料館の電子情報化委員というアドバイザー的な仕事をしていたこともあったので、上記の2点をやってください、と、ずっとお願いしていて、今年度に更新したシステムでは（1）はできるようにする、でも（2）は今回は無理だった、ということをうかがっていて、今か今かと待っていたのでした。結果として、1年近くかかってしまいましたが、ようやく（1）が達成されました。
古瀬先生が時折私にお話ししてくださっていたことの一つに、自分がいなくなってもシステムが動くようにしないといけない、ということがありました。確かに私は先進的なシステムを提供しようとするあまりに自分がいなくなったら動かなくなるのではないかという懸念とは背中合わせの状況にあります。自分がいなくなっても稼働し続けられるように、続く人が継続できるようにと、いろいろな工夫をしてきていて、IIIFやTEI、Unicode等に入れ込んでいるのはそれを解消するための土台を皆で共有できるようにするということもあるのですが、まだ完全とは言えません。一方、古瀬先生が責任者として動かしておられた仕事は、事業として確実に動かせる形を目指して整備され、古瀬先生が亡くなった後にも着々と進められ、ついに公開にまで至り、とても地味ですが、しかし、国文学のみならず、日本文化研究全般を大きく前進させる1歩を刻むことになりました。それだけでなく、色々なデータベースがシステムの全面更改を経て今もなお普通に使えていることもまた、古瀬先生のご尽力に負うところが大きく、そこには学ぶべき事が多々あると思っています。国文学研究のデジタル化という極めて難しい仕事に取り組んでこられ、時折その大変さをおうかがいすることはありましたが、情報工学者と人文学者というギャップにはじまり、事業として研究を支援すること、日進月歩のデジタル技術を事業として扱わなければならないことなど、おそらくはおうかがいする以上に大変なことは様々にあったのだろうと思います。道半ばになってしまったことは古瀬先生としても残念なことだろうと思いますが、その着実なお仕事は、今後も、おそらくはほとんどそれと意識しない形で、我々に色々な恩恵を与え続けてくれることでしょう。
古瀬先生、ありがとうございました。
