IIIF対応URLで古典籍から画像や文字を切り出せるように!(日本の古典籍のオープンデータ!その4)

今回はまず、冗漫な話は後回しにして、先に要件から行きます。

 

ここしばらく時々記載している国文研オープンデータセットの活用例シリーズ、「日本の古典籍のオープンデータ!そのn」ですが、IIIF対応画像切り出し用URL、というのを簡単に作れる様にしてみました。例によって、国文研データセット簡易Web閲覧への機能追加という形で実現しました。(が、バグ等もあるかもしれませんのでご注意ください)

※IIIFは、現在、海外の主要な大規模デジタルアーカイブ公開機関が共同で取組んでおり、採用が広がりつつある、デジタルアーカイブにおける画像共有のためのルール(ここではAPIと呼ばれています)です。詳しくは過去記事をご参照ください。

 

さて、今回は、国文研データセット 絵本松の調 14でお試ししてみます。

 

1.新たにボタンが登場していますので、まずはそれをご確認ください。(※最初は、ページのロードが完全に終わるまで、一息、お待ちください。読み込み途中で作業を始めるとバグることがあるようです)

f:id:digitalnagasaki:20160423035336p:plain

 

2.このボタンをクリックすると、ボタンがオレンジ色になって、ズームが止まり、代わりに、画像上で長方形での選択をできるようになります。適当にズームインして切り出したい箇所を少し大きくしてからこのボタンをクリックしてみましょう。

f:id:digitalnagasaki:20160423035341p:plain

 

3.そこで、画像上でドラッグして長方形の選択をすると、ボタンが二つ現れますので、とりあえず試しに左側のボタンを押してみましょう。なお、長方形がずれてしまった時は、枠線についている黒い四角をドラッグすると修正できます。

f:id:digitalnagasaki:20160423035342p:plain

 

 

4.そうすると、切り出された画像が長辺500pxで表示されます。フルサイズのURLも用意してあるので「リンクアドレスをコピー」などでコピーしていただくとそのまま使えます。

f:id:digitalnagasaki:20160423035355p:plain

 

5.フルサイズの切り出しURLだとこんな感じです。

http://www2.dhii.jp/loris/NIJL0008/NA4-0644/NA4-0644-00013.jpg/pct:59.277,45.032,10.167,21.822/full/0/default.jpg

なお、詳しいURLのいじり方は本家IIIFのサイトのImage APIの解説をどうぞ。URLをさらにいじると、傾けたりひっくり返したり拡大縮小したり、色々なことができます。

 

f:id:digitalnagasaki:20160423035356p:plain

 

個々の確認はしてませんが、多分、国文研データセット簡易閲覧システム上のすべての画像がこれに対応できると思います。画像切り出しURLはツィッターに貼り付けたりしたら面白いかもしれませんので、ぜひ色々ご活用ください。

 

 

さて、ついでに少し背景の解説もさせていただきますと、まず、今回もすべてフリーソフトによって構築されています。一晩でできました。少し前に導入したPythonベースのIIIFサーバlorisを利用しつつ、OpenSeadragonのselectionプラグインというのがありまして、これを使って画像上で選択ができるようにしたものです。このプラグインでは、オリジナルの画像サイズを基準にしたピクセル値で切り出し位置と切り出しサイズを伝えてくれるのですが、IIIFは相対値で扱うので、相対値への変換が必要になります。簡単かと思ったら、OpenSeadragonでの「今見ている画像の」オリジナルの画像サイズの仕方がどうしてもわからず(絶対どこかに値を持っていると思うのですが)、結局、とても恥ずかしいやり方で、何はともあれ取得はできた、という状態です。XML様々です。(これを調べ始めて挫折するまでに4時間くらいかけてしまったので、その時間を省くと実際に開発に要した時間は3時間くらいでしょうか。)OpenSeadragonの標準APIで「今見ている画像の」オリジナルの画像サイズを取得できる手法をご存じのかたがおられましたらぜひご教示ください。(この件はプラグインはナシでお願いします)

 

実は、国文研データセットの画像の方でやろうと思っていたことは、これでようやく一通り終わりました。どれもこれも荒削りなままですが、「こういうデータが公開されるとこういうことができる」ということを知っていただくには、まあそれなりにお役に立つだろうかと思います。それから、もっと国文学に強い思い入れのある人や、そういう人が率いるチームが、これを横目に見つつ、さらに良いものを作ってくださることを期待しております。

 

それから、すでに、国文研特任助教の松田訓典氏が、この仕組みをもっときちんと活用した画像タグ付けシステムを開発しておられ、すでに実用レベルに達しているようですので、いずれ、それを用いた使いやすい仕組みが公開され、皆で使えるようになっていくことだろうと期待しております。

 

私が書いたソースコードは基本的に適当に書いているのでオープンにするには恥ずかしく、また、所詮文系のDIYプログラマが書くようなものですので特にお役に立てるようなことはあまりないと思いますが、もし本格的に取り組むにあたって参考にしたいという人がおられたらソースコードをお譲りしますのでお声がけください。

 

本当は、私の仕事はテキストの方なので、いずれは全文テキストの方もいじってみたいと思っています。ただ、このところ、ちょっと大がかりな画像データベースを作らなければならない状況になっていて、このところの一連のIIIF関連の作業はそこにつながっていきます。国文研オープンデータセット簡易閲覧システムは、その副産物的なものということもできるかと思います。後になってみたら、ああ、なるほど、と思ってくださる方もおられるだろうと思います。

 

今夜作った仕組みは発表原稿には間に合いませんでしたが、一連の国文研データセット簡易Web閲覧に関する開発の話は、5/14に筑波大学春日キャンパスで開催される、情報処理学会人文科学とコンピュータ研究会で発表する予定です。秋葉原駅から45分、つくば駅から歩いて10分くらいのところです。もし本件についてご興味がおありで、お時間がおありの方は、ぜひお越しください。なお、この研究会は、典型的な学際系研究会で、文系でもあって理系でもあるような、不思議な空間で、どちらの立場からの議論も大歓迎です。今回は、国文研の日本語典籍の大型プロジェクトやくずし字に関わる発表が3件、漢字研究関連の発表が3件、舞踊が2件、オペラ関連が1件、それに加えて、東西外交史、日本語マイクロクラウドソーシング、と、なかなか多彩な陣容になっています。さらに、情報知識学会と共催ということで、図書館・博物館方面からの発表なども加わるようです。

 

 

 

IIIFを使ってみたい人のためのIIPImage Serverインストール記(簡易版)

本日、「国際的なデジタル画像の相互運用の枠組み、IIIFのためのサーバを導入してみたので簡単にご紹介」という大変冗長な記事を書いたのですが、雑談や脱線が多すぎて、インストールが難しいのではという印象を一部に持たれてしまったかもしれないと思いまして、実際に必要(そう)な作業のみに絞り込んだものを以下に書いておきます。

 

IIIF(International Image Interoperability Framework)の目玉(の一つ)であるImage APIを使えるようにするために必要なのは、

1.サーバソフトのインストール

2.ピラミッド型タイル画像ファイルの用意

の2点です。それぞれ以下に方法を書いていきますと、

 

1.サーバソフトのインストール

 

今回は、CentOS7に、動作速度が速そうなIIPImage Serverをインストールしました。まず、準備として、fcgiを使えるようにするモジュールをインストールしておきます。

$ sudo yum install mod_fcgid

次に、ソースコードiipsrv-1.0.tar.bz2をダウンロードします。

次に、これを展開して、

$ tar xjvf iipsrv-1.0.tar.bz2

$ cd iipsrv-1.0/

$ ./configure

$ make

$ sudo make install

とするとiipsrv.fcgiができます。もし、./configureが通らない時は、適宜yumで*-develパッケージをインストールしてください。make installまで終わったら、これを設置するディレクトリを作ってそこに設置します。

$ sudo mkdir /var/www/iipsrv

$ sudo cp ./src/iipsrv.fcgi /var/www/iipsrv

次に、設定ファイルを作ります。

$ sudo vi /etc/httpd/conf.d/iipsrv.conf

 

iipsrv.confの内容はとりあえず下記のような感じで動きました。

--------------------------------------------------------

ScriptAlias /iipsrv /var/www/iipsrv/iipsrv.fcgi

# Set our environment variables for the IIP server
FcgidInitialEnv VERBOSITY "6"
FcgidInitialEnv LOGFILE "/tmp/iipsrv.log"
FcgidInitialEnv MAX_IMAGE_CACHE_SIZE "1500"
FcgidInitialEnv JPEG_QUALITY "100"
FcgidInitialEnv MAX_CVT "8000"

FcgidInitialEnv CORS "*"
FcgidInitialEnv FILESYSTEM_PREFIX "公開用画像ディレクトリのトップ"

-----------------------------------------------------------

 

「公開用画像ディレクトリのトップ」は、ピラミッドタイルTIFFファイルが置かれているディレクトリのトップを書いておきます。たとえば/opt/images/の下に01, 02, 03...というディレクトリがあって、そのさらに下にピラミッドタイルTIFFファイルが置かれている(=画像ファイルのパスが「/opt/images/01/0001.tif」等)という場合には、「/opt/images/」を書いておきます。その他の設定の意味と値については詳しくはこちらをご参照ください。たとえば、MAX_CVTピクセル単位で書いて送出する画像の最大サイズを制限します。

 

一通り終わったら、CentOS7ですので

# systemctl restart httpd.service

とすればサーバソフトは動作します。

http://Webサーバホスト名/iipsrv/iipsrv.fcgi

にアクセスして、IIPサーバが動作しているというページが表示されるかどうか確認してみてください。もし表示されないようなら、ディレクトリのアクセス権限等を確認してみてください。

 

2.ピラミッド型タイル画像ファイルの用意

ピラミッド型タイル画像ファイルを用意するにあたっては、ImageMagickさえあれば大丈夫のようです。たとえば 0001.jpgという画像があったとしたら、

$ convert 0001.jpg -define tiff:tile-geometry=256x256 -compress jpeg 'ptif:0001.tif'

とすれば作成できます。あとはこれをシェルスクリプトなどで適当に回せばOKですが、とりあえず動作確認のため、一つの画像だけで試してみましょう。このファイルは、上記の場合には/opt/imagesディレクトリ以下に置いてください。

$ cp 0001.tif /opt/images/

などとすればよいでしょうか。

 

その後、下記のURLにアクセスして

http://Webサーバホスト名/iipsrv/iipsrv.fcgi?IIIF=/0001.tif/full/full/0/default.jpg

画像の全体が表示されたらOKです。次に、たとえば以下のような感じで、URLに応じて色々表示の仕方が変化する様を試してみてください。詳しくは本家サイトのImage APIの解説をどうぞ。

http://Webサーバホスト名/iipsrv/iipsrv.fcgi?IIIF=/0001.tif/pct:60,65,18,23/800,/0/default.jpg

ここまでできたら、サーバの設定はもう終わりです。あとは、/opt/images/以下に、ピラミッド型タイル画像に変換したファイルを置いていけば、IIIF Image APIに対応した画像としてアクセスできるようになりますので、適宜画像作成して置いていってください。

 

ちょっと間違っているところがあるかもしれませんが、一応、これで動いたという最小限のことに関して、ご報告させていただきました。

 

 

 

 

 

 

国際的なデジタル画像の相互運用の枠組み、IIIFのためのサーバを導入してみたので簡単にご紹介

さて、最近は国際的なデジタル画像の相互運用の枠組み、IIIFというプロトコルのようなものが世界のデジタル画像データベース界(?)を席巻しております。以前にも少しご紹介しましたが、「スコットランド国立図書館、IIIFコンソーシアムに加盟 | カレントアウェアネス・ポータル」というカレントアウェアネス・ポータルの記事にもあるとおり、

オックスフォード大学ボドリアン図書館、英国図書館(BL)、スタンフォード大学図書館、バイエルン州図書館、コーネル大学、フランス国立図書館BnF)、ノルウェイ国立図書館プリンストン大学図書館、ウェルカム財団、イェール大学(英国美術センター 、バイネッキ貴重書・手稿図書館)の11機関により、2015年6月に創設された

IIIFコンソーシアムによるものです。まさに、錚々たる面々によって開始されたと言って良いのではないかと思いますが…あれ…?しかし、2015年2月にパリで開催されたEuropeana Tech2015の時点ですでにコミュニティ参加機関はもっと多かったし、何より、すでにデファクト標準化しそうな手触りを感じたのだったし…? 実際の所、開発はもっと前から始まっていて、採用機関ももっと前からあった、ということは確かです。「IIIFコンソーシアム」というものが正式に立ち上がるほどまでに充実してきた、ということのようですね。

 

さて、脱線しましたが、脱線ついでに、IIIFコンソーシアム設立の記事を少しみてみますと、

インターネット上の画像ベースの情報資源の多くは、これまでサイロの中に閉じ込められてきたが、IIIFはそういった画像の表示や操作、アノテーションなどの仕方を世界中で共通化できるように支援する

という趣旨のことが書かれています。筆者のように、各地の貴重書デジタル画像をあれこれ眺めてテクスト校訂をしようとしたり、他の人も使いやすくなるようにリンクシステムを作成したりしている身としては大変ありがたく、また、同様のニーズは色々な局面においてあり得るだろうと痛感するところでもあり、特に教育コンテンツ作成においては非常に有益だろうと思います。試しに、この冬に東大文学部/人文社会系研究科で担当させていただく「文化資源デジタルアーカイブ特論」ではこれを全面的に採用した授業を展開してみようかと思って細々と準備中です。

 

 また、すでにいくつかの関連業者さん達はIIIFへの取組みを始めておられるようでうれしい限りですが、まだ始めておられない業者さん達におかれましては、国際的なエコシステムの割と大きな変化になりそうなので、それにあわせてビジネスモデルも含めてうまくやっていただいて、日本のデジタルコンテンツがきちんと国際的な潮流についていけるようにしておいていただけたらと切に願っております。

 

 それはともかく、以前にもこのブログでIIIFについては少しご紹介しましたが、今回は、サーバソフトの導入について少しご紹介したいと思います。以前にご紹介した際は、PythonベースのLorisという割と簡単に導入できるソフトを使っておりました。これは比較的インストールが簡単で、jpeg画像も扱ってくれるので割と色々やりやすいのですが、その代わり、ちょっと動作が遅く、アクセスが集中するとなかなか厳しいものがあるだろうかと思っていたので(とはいえキャッシングもするので同じURLへのアクセス集中は問題なさそうですが)、このたび、いよいよ本格的にIIIFを利用する必要が生じてきたので、もう少し動作の速いものがよさそうだということで、fcgiを使う別のフリーソフトIIPImage Serverを導入してみることにしました。結果的には、ちょっと使ってみている限りではLorisよりも速そうな感じでもあるのですが、導入がなかなか大変で、アマチュアの片手間仕事とするにはまだちょっとはやいかな、という印象を持ちました。もちろん、Githubでガリガリ作業しているようなレベルの方々やプロのエンジニアとしてこういうことに取り組んでおられる方々なら楽勝だと思いますが、私レベルの文系DIYプログラマにはちょっと負担が大きいかなという感じでした。

 

 さて、そのIIPImage Serverですが、高速化のためにfcgiを使って動くのでそれにあわせた環境の用意も必要です。今回は、フリーのLinuxディストリビューションの一つであるCentOS7を使ってインストールを試みました。ご存じのように、CentOS7は著名な商用Linuxディストリビューションの一つRedhatのフリー版という位置づけです。私はRedhatがフリーだった頃からずっと使ってきているので、なんとなくそのまま使っています。ちなみに、Linuxはご存じですね?今やフリーのOSの代表的な存在で、名だたるグローバルIT企業が開発に取り組んでその成果をフリーで公開するというすごい流れになっていて、スパコンランキングでもトップ10はしばらく前からすべてLinuxを採用している、というようなものです。下の方でも、スマホOSの二強の一角、AndroidLinuxベースですし、パソコン用もあって…という感じですが、大きな流れとしてはインターネットサーバ用OSとして長らく愛され着々と改良されてきたOSの一つです。

 

 またまた脱線しましたが、そのCentOS7にIIPimage Serverをインストールして使えるようにすべく、取組みを開始しました。まず、そもそもタイル画像化したTIFFファイルを用意する必要があるようなので、このための準備を…と思って、昨晩やってみたときはImageMagickでうまく作れなかったような気がしたのでVIPSを頑張ってインストールしたのですが(これに4時間くらいかかったのですが)、このブログを書きながらもう一度試してみたらImageMagickでできてしまいました…。(激しくショック)

 

…ということで、気を取り直して、ImageMagickのバージョンが6.4.7-10 以降なら、ピラミッド型タイル画像の作成は可能のようです。確認は

 

$ convert --version
Version: ImageMagick 6.7.8-9 2016-03-31 Q16 http://www.imagemagick.org

などとすればOKです。

 

そして、ピラミッド型タイル画像の作成方法は、下記のコマンドでできました。

$ convert 元の画像ファイル名 -define tiff:tile-geometry=256x256 -compress jpeg 'ptif:ピラミッド型タイル画像ファイル名'

これについてはIIPImageのサイトに解説されているものと同じですのでそちらもご参照ください。本番(?)では、このスクリプトシェルスクリプトで回すなどして必要なファイル変換を自動的に済ませていただくとよいかと思います。

 それから、これは一応jpeg画像からでも作成可能ですが、ファイルサイズが結構大きくなります。たとえば 829K の画像ファイルが3.8Mになってしまったりしましたので、この点はちょっとご注意ください。

 

さて、気を取り直して、サーバソフトのインストールです。ここでまた余談ですが、実はCentOS6にはRPMパッケージが提供されていて、簡単インストールできる、という触れ込みだったので、最初はCentOS6にインストールして設定を試みていました。しかしながら、IIIFのImage API準拠でのアクセスがどうもエラーになってしまうので、ちょっとググってみたところ「あのパッケージはver1.0ってなってるけど実際に使ってるソースはもっと古いようでIIIF対応になってないんじゃないの?」という質問に対して、その通りなのでソースからコンパイルして。パッケージはもうちょっと待ってね、というような身もふたもない回答があって、まあそれならCentOS6にこだわる必要もなく、普通に最新版のOSを使うか、ということでCentOS7でソースからコンパイルすることになったのでした。

 

さて、インストールにあたっては、まず準備として

# yum install mod_fcgid

とやっておいてfcgiを使えるようにしておく必要があります。今回使うWebサーバソフトはApacheです。これが終わったらいよいよインストールです。

 

 ソースはGithubで取れるのですが、私はあまりGithubを使わないので、とりあえずソースファイルをダウンロードして展開してコンパイルしました。

 コンパイルは、公式サイトなどにはいかにも簡単なように書かれているのですが、実際にやってみると、足りないパッケージが結構あって色々インストールすることになりました。お約束ですが、

$ bunzip2 -c iipsrv-1.0.tar.bz2 | tar xvf -
$ cd iipsrv-1.0/
$ ./configure
$ make
$ make install

こんな感じです。configureをすると足りないライブラリについて色々アラートが出るので、いちいち調べて、とりあえずyumでインストールしていきます。*-develというパッケージが色々必要になるので、yumするときは$ yum install 必要なパッケージ名-* などとしてインストールしてしまうと割と樂です。とりあえずconfigureが最後まで通るようになったら、make してmake installです。

iipsrvのmake installまで通ったら、次はいよいよ設定です。今回は仮に

# mkdir /var/www/iipsrv

というディレクトリを掘っておいて

cp ./src/iipsrv.fcgi /var/www/iipsrv/

としておきます。それから、

/etc/httpd/conf.d/iipsrv.conf

などというファイルを作って設定を書いておく必要があります。私はこういうときはviを使うので

# vi /etc/httpd/conf.d/iipsrv.conf

で、内容は例えばこんな感じです。

 

ScriptAlias /iipsrv /var/www/iipsrv/iipsrv.fcgi

# Set our environment variables for the IIP server
FcgidInitialEnv VERBOSITY "6"
FcgidInitialEnv LOGFILE "/tmp/iipsrv.log"
FcgidInitialEnv MAX_IMAGE_CACHE_SIZE "1500"
FcgidInitialEnv JPEG_QUALITY "100"
FcgidInitialEnv MAX_CVT "8000"
FcgidInitialEnv FILESYSTEM_PREFIX "公開用画像ディレクトリのトップ"

 

「公開用画像ディレクトリのトップ」は、ピラミッドタイルTIFFファイルが置かれているディレクトリのトップを書いておきます。たとえば/opt/images/の下に01, 02, 03...というディレクトリがあって、そのさらに下にピラミッドタイルTIFFファイルが置かれている(=画像ファイルのパスが「/opt/images/01/0001.tif」等)という場合には、「/opt/images/」を書いておきます。その他の設定の意味と値については詳しくはこちらをご参照ください。たとえば、MAX_CVTピクセル単位で書いて送出する画像の最大サイズを制限します。

 

それから、画像の置いてあるディレクトリ「/opt/images/」がWebサーバから参照できるようにしておいてください。それと、iipsrv.fcgi を置いたディレクトリ「 /var/www/iipsrv」でfcgiが実行可能になるような設定も必要です。/etc/httpd/conf/httpd.confでのディレクトリのアクセス・権限制御の設定変更はもちろんですが、SELinuxを有効にしている場合は結構大変ですのでご注意ください。

 

一通り終わったら、CentOS7ですので

# systemctl restart httpd.service
とやってWebサーバソフトを再起動します。

 

これで、

http://Webサーバホスト名/iipsrv/iipsrv.fcgi?IIIF=/04/0170.tif/full/full/0/default.jpg

という風にアクセスしてみると、フルサイズ画像が表示されました。(私の場合)

あとは、たとえば下記のように、色々試してみていただくとよいかと思います。

http://candra.dhii.jp/iipsrv/iipsrv.fcgi?IIIF=/test/099-0127-00023.tif/pct:60,65,18,23/800,/0/default.jpg

IIIF Image APIの書き方に関しては過去記事をご覧ください。過去記事と同じ画像に対して同じURLを送ってみると、下記のように、異なるサーバソフト(過去記事ではLoris)でも同じように表示してくれます。

http://candra.dhii.jp/iipsrv/iipsrv.fcgi?IIIF=/test/099-0127-00023.tif/pct:60,65,18,23/800,/0/default.jpg

 

ちなみに、IIPImage Serverは、透かしをオンザフライで入れたりすることもできる結構多機能な画像配信サーバソフトのようですので、IIIFの枠組みのみにとらわれずに色々試してみるとまた面白いかもしれません。

 

次は、なんとかして機会を見つけて、Presentation APIについての記事を書けたらいいなと思っております。あちらはJSONメタデータを用意しておきましょう、という話で、これがどうなるかというと、たとえば最近あちこちでIIIF対応ビューワとして採用が広がっているMiradorでは、各地のサーバのJSONファイルを読み出して一つのビューワに表示できるようになっているようです。また、Presentation APIにはアノテーションやレイヤーなどの仕様も用意されているようですが、うまく実装できているクライアントがあるのかどうかはまだ十分に調査できていません。ちょうど、冒頭で言及したスコットランド国立図書館のサイトで採用されたようですが、Klokan Technologisが作っているビューワも結構多機能な感じなのでちょっと気になっています。

 

ということで、大変雑多なご紹介でしたが、お役に立ちましたら幸いです。

 

 

 

 

 

本日、 第4回 SPARC Japan セミナー2015 「研究振興の文脈における大学図書館の機能」に参加する予定なのですが…

本日、  第4回 SPARC Japan セミナー2015 「研究振興の文脈における大学図書館の機能」に参加する予定なのですが、もう本当に仕事が立て込んでいて、行けるかどうか定かでないので、とりあえず質疑応答の時間があったら聞いておきたいことを先に書いておくことにする。

 

もちろん、概要や講演要旨にすべてが書かれているわけではないと思うので、実際に参加してみなさまのご講演を拝聴することができたなら、特に質問などする必要もないという状況になるかもしれない。それも踏まえつつ、一応、考えを整理しておくために書いておくと、

 

聞いてみたいことというのは、かいつまんで言えば、「研究振興の文脈における大学図書館の機能」というタイトルで、「本(古典籍・貴重書等も含む)」が論点として全然出てきていないように見えるのだがそれで大丈夫だろうか、という点である。「本」と、そのデジタル化・デジタル化されたものも含めた活用を通じた研究振興というのは、そのほとんどは人文社会科学系が相手になるので、今のところすぐにはあまりお金にはならないし、図書館の皆様のこれまでのご経験からすると、もしかしたらややこしいことも多いのかもしれない。しかし、そこを外してしまったら、そもそも図書館である必要がなくなってしまうのではないか、というのが若干気になるのだ。

 

もちろん、図書館という枠に拘泥せずに、その期待される本来的な機能(であると思われる)研究振興という原点(だと思う)に戻って考えて見ると、多分このような絵になるのだろうと思う。学術情報流通にも少し関心を持っている身からしても、それ自体には特に異論がない。

 

とは言え、人文系研究者としては、依然として「本」は様々な局面で重要だし、そこをデジタルも含めてこれまで以上に効率的に扱えるようにすることに取り組んでいただければ、それもまた立派な研究振興だと思う。そして、そこに一番近いのは大学図書館だと思っているし、まだ、機関リポジトリよりは「本」の方が近いのではないかと思う。機関リポジトリを辞めて欲しいと言っているのではなく、それはそれでむしろどんどん頑張っていただきたいのだが、しかし、「本」からわざわざ距離を取ってしまうようなことになってしまうと、これまでそれなりに有してきた大学図書館のアドバンテージを手放してしまうことになりはしないか。大学図書館が困ってしまうというだけなら問題ないようにも思えるが、比較的公益性の高い枠組みの中で割と重要な役割を比較的容易に果たし得るプレイヤーが、その役割を離れて、むしろより困難なところにばかりリソースを注入していってしまうのだとすると、それはやはり社会的な損失だと言わざるを得ないようなことではないだろうか、とも思う。

こういうときに海外の話をすると出羽守などと言われてあまり喜ばれないことも多いのだが、それでも、まだ国内にはあまり強い事例がなさそうなので(この方面は勉強不足なので、あったらぜひ教えていただきたく…)、敢えてちょっと書いておくと、たとえば、HathiTrustみたいに、大学図書館連合でデジタルリポジトリを作ることができれば、人文社会科学系研究にとっては大いに振興になる上に、図書館の存在意義も改めて確認されることだろう。2ヶ月ほど前には東京大学でHathiTrust研究センターの所長さんを招いての国際シンポジウムが開催されていたが、その折には、HathiTrustのデジタル化資料を活用する研究のために研究センターに世界中から研究者が集っていてかなり大がかりなことになっている様子が紹介されていた。これを読まれるような方には釈迦に説法だと思うが、HathiTrustでは、著作権保護期間中の本でもデジタル化・テキストデータ化して、統計情報のみを扱えるようにするという形で研究環境を提供していて、これもまた大きな研究振興につながっているようである。(著作権が切れていない大量の本のテクストデータが、たとえそのまま扱えないにしても、統計処理できるのだとしたら、それだけでも相当に色々な可能性が拓けてくることだろうと思うとうらやましいことである)また、大学図書館連合と言えば、EEBOやECCO等の商用データベースコンテンツのテキストデータを作成共有して最終的にパブリックドメインで公開するプロジェクトTCP (Text Creation Partnership) は、欧米中国の150以上の主に大学図書館が参加している。TCPなどは、当事者達がどれくらい意識しているかはわからないが、まさにオープンデータ・オープンサイエンスの流れに沿ったものになっていると言えるだろう。

 一方、たとえばコロンビア大学の図書館では、人文学研究を支援するための活動が図書館司書達によって割と活発に展開されているようなのが、そのサイトにこんな一節がある。

データベースや高価なソフトウェアを提供するという図書館の役割が個々の研究者にとって大変重要であることは明らかなのだが、一方で、我々は現在、自分自身の手でデータベース(にデータ)を追加したりソフトウェアを開発したりすることや、一般の人々と共同での研究を試みること、そして、新たな方法でデータを収集し共有することに興味を持つようになる研究者の数が増えてきているということについて責任を負わなければならない。

これは人文学系の専門司書による仕事なので、日本だとそのまますぐに持ってくることは難しいとは思う。しかし、日本でも、こういう観点での研究振興のニーズは徐々に出てきているし、それをすくい上げるのに大学図書館はかなり近くて有利で、その固有性を活かせるかもしれないところにいるのではないかという気がする。

 

もちろん、大学図書館のことをよく知らないままに書いていることなので、まったく的外れだったら申し訳ないことだが、そのようなことで、今回、研究振興の文脈における大学図書館の役割、という風に風呂敷を広げるなら、そちらの方への配慮についてどうお考えなのか、時間があれば少しおうかがいできたらと思っている次第である。(しかし今日は打ち合わせが多いので結局おうかがいできない可能性もあるが…)

D3.jsとIIIF。まだ相互連携してませんが(日本の古典籍のオープンデータ!その3)

日本の古典籍のオープンデータのお話、ずいぶん間が空いてしまいましたが、その間、何もしてなかったわけではありません。ちまちまと開発を続けておりまして、しかしご報告を書く時間がなかなかとれないという状況でした。

 

今も、他にも色々しなければならないことがあるのですが、本件を少しまとめて発表しようと思うようになったので、その前段階としてちょっと近況をご報告します。主に、D3.jsを組み込んだという話と、国際的に流行しつつあるデジタル画像流通プロトコル、IIIFに対応させてみた、という話です。

 

D3.jsの組み込み

ということで、まず、D3.jsを組み込んだ、「タグ連想検索」を作りました、という話です。名前がちょっと仰々しいですが、要するに、関連しそうなものを連想的にたどっていけるようにする、というものをテキストデータとリンクで表示するようにしていたのですが、それをD3.jsに読み込ませるようにしただけのものです。ただ、組み込むにあたり、D3.jsのサンプルをちょっと修正して使っています。修正したのは、各ノードの大きさを個別に変更できるようにしたという点です。あとはほぼそのまま使っていると思います。

f:id:digitalnagasaki:20160229082935j:plain

 私のようなDIYレベルのプログラマの場合、D3.jsを組み込むポイントは、

  1. サンプルにあるjavascriptcssのファイルをとにかくそのまま組み込んでみる。
  2. とにかくうまく読み込ませることができるJSONデータを生成する

という2点かと思います。これだけで色々面白いものを作れてしまうというのがD3.jsの素晴らしいところだと思います。

 実は、このサンプルはしばらく前から別のシステム(ITLR等)で使っていて、これを使った最初の発表は、多分、2014年の夏、ウィーンで開催された国際仏教学会、ITLRのプロジェクトを紹介した時だったのではないかと思います。その後いくつかのシステムで利用してみながら、課題の一つとして、ノードのサイズと線の太さを変えられるようにしなければ…ということを感じておりました。今回の「タグ連想検索」では特にノードのサイズが重要だったので、これだけはなんとかしてから公開、と思っていたので、少し時間をかけてしまいましたが、まあなんとか実現できました。これに読み込ませるJSONデータもあわせて形式を修正しています。

 「連想」と言っていますが、今回は、元データの関係上、それほど複雑なことをしているわけではありません。タグは1つの頁に複数登場しているものもあれば1つしかないものもあり…というような状況で、何らかの関係を記述するのはなかなか難しい状況です。今回の場合、同じ頁に登場するタグ同士は関係が深く、隣の頁に登場するタグは深くないけど関係があり、さらにその隣の頁に登場するタグはもう少し浅い関係があり…ということで、5頁以内に登場するタグは関係があるかも、という前提で関係データを作りました。

 作成した関係データは、いったんデータベースに入れておいてインデックスをはって高速に検索できるように用意しておき、ユーザから検索クエリが来たらそれにあわせて、適宜、適切なデータを取り出してJSONデータ化する、という風にしています。(最初は、システムの移植可能性を考慮してテキストファイルを毎回開いて検索するようにしていましたが、どうにもデータ取り出しに時間がかかってしまうので、諦めてデータベースを使うことにしました。)関係データをJSONデータ化するにあたっては、まず、計測した結果を連想配列として整理し、その後、連想配列JSON形式に変換するPHPの関数を使ってJSONデータに変換するという手順になっています。なお、PHPではオブジェクトからJSON形式に変換することもできるようなので、若者はオブジェクトを使うとよいのではないかと思います。

 とういわけで、あとは、以前に作ったタグ検索システムをちょっと組み合わせて、ノードをクリックすればタグ検索結果が表示される、というものも組み込んで、まあ大体ここまで来ています。あと1つ2つ、機能を追加したいのですが、まだちょっと手が回りません。

あと、根本的な問題として、タグと画像頁との対応がちょっとずれてしまっているところがあるようで、今後はそこの精度を上げるというか、ずれが生じないようなタグ付与を期待したいところです。

 

IIIFへの対応

 IIIF(トリプルアイエフ, International Image Interoperability Framework, 国際画像交換フレームワーク)というのは、名前の通り、Web上でデジタル画像をやりとりする際の国際的な枠組みです。簡単に言うと、サーバ側の負担を大幅に増やして、クライアント(Webブラウザ)側から簡単に画像にアクセスできるようにしようという枠組みです。IIIFのルールに従ったURLをサーバに渡すと、サーバは画像を加工(切り出し・回転・サイズ変更など)してクライアント側に返してくれます。

 IIIFには、スタンフォード大学がかなり力を入れているようですが、コミュニティ参加機関を見る限りでは、重要機関の多くが参加するようになってきているようで、これに(も)のっておかないと後で大変になってしまうのではないかという感じがあります。個人的に、おおっ、となった参加機関としては、オックスフォード大学ボドリアン図書館、フランス/オーストリア/デンマークニュージーランドノルウェイイスラエルセルビアウェールズ国立図書館、英国図書館、Europeana、DPLA、ウェルカムトラスト、テクストグリッド、あたりですが、他にも色々な有名関係機関が名を連ねています。(まだメジャーなところのすべてではない、ということにも注目しておきたいところですが、もちろん、参加機関に名を連ねなくてもこれに対応することはできます)

 ちなみに、1年ほど前に参加したパリでのEuropeana Techでこれをよく知る機会を得たのですが、すでに当然のものとして語られていて、当時すでにプロトコルはバージョン2となっていました。最近は、デジタル・ヒューマニティーズ関連の会議でもちょこちょこ出てくるようになっています。基本的に、画像方面は疎いので、ふむふむ、と思って翌月には自分のところでちょっとサーバを動かしてみたりしました。下記、2015年12月にDigital Humanities in Japanという Facebookのグループに掲載したものに若干手を加えて再掲します。

 

 IIIFについてもう少し具体的に見ていきますと、基本的には、


(1)画像を表示する際にURLで画像の表示形態を指定するルール(image API
(2) (1)を前提として画像のメタデータを効率的に共有するルール(presentation API


から成っているようです。たとえば、

先日スタンフォード大学で公開された国絵図の高精細画像
http://gigazine.net/news/20151213-omi-kuni-ezu-stanford/
にもこのIIIFが採用されていました。

これがどういう風になるかといいますと、たとえば、

長辺を1000ピクセルで表示
.../full/!1000,1000/0/default.jpg長辺1000ピクセル画像

長辺を500ピクセルで90度回転させて表示

.../full/!2000,2000/90/default.jpg 90度回転画像

一部を指定して切り出して表示
.../7400,9500,1000,1000/!1000,1000/90/default.jpg 切り出し画像

というような感じのことができます。

これだけですと、URLまでいちいちいじらない一般利用者にはあまり縁のなさそうな話ですが、これは、色々な画像ビューワを作る際に大きく影響してきます。つまり、IIIF対応画像ビューワがあれば、どのサイトに置いてある画像でも同じように閲覧することができるようになります。さらに言えば、たとえばバーチャル博物館のような仕組みを作る際にも、IIIFの配信形式に対応した画像を対象とするなら、、IIIFに対応した表示機能を用意するだけで世界中で公開されているIIIF配信形式に対応した画像を取り込んで利用することができるようになります。IIIFの配信形式に対応した画像の公開がある程度広まっていけば、他にも様々な活用が可能となっていくことでしょう。(IIIF登場以前ですが、キュレーター養成カリキュラムでバーチャル博物館作成Webシステムを作って使った話を聞いたことがありまして、そういうものもIIIFの配信形式に対応した画像が増えてくれば一気にブレイクするかもしれませんね)

 すでに、フリーでの実装がいくつか公開されておりまして( http://iiif.io/apps-demos.html )、さらに、日本でもデジタルアーカイブシステムを作っている大手の某社がIIIFに近々対応すると聞いております。仕組み自体は複雑なものではありませんので、仕様書に「IIIFに対応すること」と書くだけで対応できる可能性もあります。

さて、筆者はDIYプログラマであり発注担当者でもあるので、当然、自分でも一応やってみなければ、という思いに駆られるわけです。1年程前に一度試してみたのですが、そのときに使った画像データだと、効果的な感じにするのにちょっと手間がかかりそうだったのでブログに書いたりしなかったのですが、このたび、国文研データセットImage APIの方を試してみたところ下記のような感じになりました。

横幅500pxで表示

http://www2.dhii.jp/loris/NIJL0010/099-0127/099-0127-00023.jpg/full/1000,/0/default.jpg

斜めに少し傾けて横幅は400pxで

http://www2.dhii.jp/loris/NIJL0010/099-0127/099-0127-00023.jpg/full/800,/22.5/default.jpg

右下のカエルだけを切り出して横幅800pxで表示

http://www2.dhii.jp/loris/NIJL0010/099-0127/099-0127-00023.jpg/pct:60,65,18,23/800,/0/default.jpg

 

サーバ側は、大きな画像を1枚用意しておけば、あとは、クライアント側からリクエストされたURLに応じてサーバが画像ファイルを加工して送出してくれるようになっています。これだけだと一般ユーザからはあまり面白くないかもしれず、どちらかと言うとソフトウェア開発者にとって面白い機能なのですが、一般ユーザでも、URL指定するだけでサーバ上の画像を切り出して提示できるということは、たとえば下記のようなことが可能になります。この場合、同じ座標で切り出してみましたが、画像撮影が上手にできているせいか、まあなんとかうまくできている感じです。

 

例:寛政3 (1791)年刊享和4 (1804)年刊の武鑑の口絵に出てくる亀を見比べてみる

 

http://www2.dhii.jp/loris/NIJL0307/MIT-Y01201-140/MIT-Y01201-140-00004.jpg/pct:35,70,13,15/800,/0/default.jpg

 

 

http://www2.dhii.jp/loris/NIJL0308/MIT-Y01201-149/MIT-Y01201-149-00004.jpg/pct:35,70,13,15/800,/0/default.jpg

 

で、違ってる箇所をさらに拡大してみると…

 

http://www2.dhii.jp/loris/NIJL0307/MIT-Y01201-140/MIT-Y01201-140-00004.jpg/pct:36,80,4,5/400,/0/default.jpg
http://www2.dhii.jp/loris/NIJL0308/MIT-Y01201-149/MIT-Y01201-149-00004.jpg/pct:36,80,4,5/400,/0/default.jpg
http://www2.dhii.jp/loris/NIJL0307/MIT-Y01201-140/MIT-Y01201-140-00004.jpg/pct:36,80,4,5/400,/0/default.jpghttp://www2.dhii.jp/loris/NIJL0308/MIT-Y01201-149/MIT-Y01201-149-00004.jpg/pct:36,80,4,5/400,/0/default.jpg

 

 

さらに、座標がちょっとずれますが、寛政11 (1799)年刊の亀は以下のような感じです。

http://www2.dhii.jp/loris/NIJL0306/MIT-Y01201-146/MIT-Y01201-146-00002.jpg/pct:35,72,13,15/800,/0/default.jpg

http://www2.dhii.jp/loris/NIJL0306/MIT-Y01201-146/MIT-Y01201-146-00002.jpg/pct:35,72,13,15/800,/0/default.jpg

 

 

このように、普通のユーザがブログを書いたりする時でも、画像URLの書き方のルールさえ知っていれば、割と自由に画像の部分引用ができるようになります。画像URLの書き方が面倒だ…と思われる方もおられると思いますが、もう少しお待ちいただければ、簡単に書けるような仕組みもご提供しますので…

 

ところで、ここまで来ると、開発系の人はむずむずしてくると思いますが、サーバ側にインストールしてみたのは、リストされているもののうち、lorisというソフトウェアです。これは、Jpeg画像でも使えて、Pythonで書かれていて、Apacheを介してデーモンとして動かせるので、お試しとしては導入が楽かと思い、使ってみています。あと、気になっているのはdigilibなのですが、まだ試せていないので、どなたか試用レポートをあげていただけるとありがたいなと思っております。

 lorisの導入は、上記のWebサイトに書いてある通りです。基本的に特に難しいことはないと思いますが、サーバ側に必要なライブラリ等をすべて用意するのに若干手間取りました。そこさえクリアできれば、あとは難しいことは特にないと思います。

 

IIIFは、簡便なユーザインターフェイスをクライアント側に用意するだけで画像の提示や切り出しを色々な形で(再掲: Image APIを参照)できるようになるということで、様々な応用が期待されるところです。私もそのうち、これを活用した面白いソリューションを提供したいと思っています。

 

ワークショップ (デジタル/アナログ・ヒューマニティーズ)によせて:パブリックドメイン資料の活用と大学図書館連合への参画について

【イベント】デジタル・ヒューマニティーズ関連ワークショップ(東京・2/10、2/12) | カレントアウェアネス・ポータル

の告知があった。残念ながら、すでに2/10は京都で講習会の講師を頼まれていて、ほぼ時間もかぶっているので、全然参加できないという状況である。しかしながら、デジタル・ヒューマニティーズ(DH)に関わるイベントが、西洋における歴史学の文脈で日本で開催されるというのは大変にうれしくありがたいことである。2/10のテーマに掲げられている「アナログ・ヒューマニティーズ」というのは、TEIガイドラインをめぐる議論等を通じて、まさにDHの努力の半分かそれ以上が捧げられているような歴史のある重要な事柄なので、ぜひそこを踏まえた上での建設的な議論を期待したい。

 

さて、さらにうれしいのは、テーマになっている話としてEEBO-TCPECCO-TCPが採り上げられていることである。TCP (Text Creation Partnership)というのは、有料(かつかなり高額な)英語文化資料データベースであるEEBO (Early English Books Online, 1475-1700年に英国で刊行された本のオンライン版)やECCO (Eighteenth Century Collections Online)等の、テキストの部分のみを、最初はメンバー大学図書館のみで作成・公開・共有して、最終的にはパブリックドメインとして共有しようという試みである。昨今のオープンデータ・オープンサイエンスの話ともつながってきそうな話である。

http://www.textcreationpartnership.org/

すでにEEBO-TCP Phase I として25000点のテクストがパブリックドメインになっていてオックスフォード大学のテクストアーカイブ等から公開されており、まだまだこれからたくさん作成公開されるという感じである。日本でも、去年の9月まで東京女子大にいらっしゃったアンジェラ・ダヴェンポート先生が注目しておられて、ワークショップを開催したりしておられた。

 このTCPのテクスト群をターゲットとして公開されている検索システムとしては ミシガン大学の Early English Books Online のものが結構高機能な検索システムを提供したりもしていてなかなか便利そうである。他にも様々なプロジェクトがこのテクスト群をターゲットとした研究開発を行っているようであり、一昨年、シカゴでTEIカンファレンスに参加した際には色々な研究発表が行われていた。なかでも面白かったのは、OCRのプロジェクトと、TEIガイドライン(人文学資料のためのテクストXMLマークアップのためのルール)のサブセットのプロジェクトの話だった。

 OCRの方は、テキサスA&M大学の英文学のLaura Mandell先生が率いるeMOPプロジェクトで、GoogleのフリーのOCRソフトであるTesseract OCR engine に歴史的な字形を学習させるためのツールとしてFranken+というのを開発中とのことで、これは日本語でやってみるとどうなるんだろうか、とちょっと思った次第。

 後者は、このTCPテクスト群をターゲットとしたTEI Simpleという規格が立ち上げられていた点である。TEIガイドライン自体は、とにかく多様な人文学資料やその用法にすべてきちんと対応しようとするあまり、タグや属性が多すぎてちょっと扱いが難しい面があるのだが、TEI SImpleでは、それをばっさりと削ってしまった上に、さらに英文資料に特化された属性値を決めたりして、簡単に機械処理できるようにしているようなのである。上述のオックスフォードのアーカイブでもこのTEI Simpleに従ってマークアップされたTEI/XMLファイルを公開しているとのことである。(ここら辺のことは西洋史とか英国史を研究しているわけではないので必ずしも正確・適切ではないかもしれずその点ご容赦いただきたい)。

 いずれにしても、自由に使える電子テクストがどんどん出てきているようなので、色々な研究が大きく進んでいくだろう。TCPのテクスト群は基本的には英語で、日本人でもそこそこ使えるのではないかと思うので、単に検索サービスやツールを使ってみるだけでなく(もちろんそれも重要なことだが)、こういったものを活用したプロダクトに挑戦してみていただくのもよいのではないかと思う。

 

さて、副題の方に入ろう。このTCPの参加館リストをみてみると、世界中から100以上の大学図書館が参加していて、東アジアからも香港大学が参加しているが、日本の大学は0である。まあ確かに英語資料のみに注力することは難しいので、わざわざ日本の大学からお金を払ってまで参加しようというのはちょっと無理があるかもしれない。ただ、他にも、HathiTrust(参照1 2 3)やCADAL(参照1 2)など、国際的な大学図書館連合の枠組みによって資料・情報を融通していこうという流れが結構大きくなってきており、にも関わらず日本の大学図書館からはまだほとんど参加がない(HathiTrustは慶応大学が資料提供をしているが参加はまだ)ような感じであり、このままで大丈夫なのか微妙に不安である。図書館の方々(もしくは図書館の方々に触発されたり頼まれたりした一部の研究者)が話を進めてくださるのを待っているのが研究者としてはこれまでの常道だったと思うのだが、もしかしたら、そろそろ、研究者の側から、きちんと話を持ちかけたりしていく必要があるのかもしれないと思ったり、そこまでする必要はなくて図書館の方々を信じて待っていればいいのかもしれないと思ったり、今回のワークショップのお知らせを拝見して、改めて色々考えた次第である。

北米大学図書館の日本研究司書の人たちの危機感を実感した話

今、いくつか原稿を抱えていて、本当ならこれを書いている場合ではないのだが、しかし、この感触を忘れないうちに記しておきたい。

 

北米大学図書館の日本研究司書の人たちの危機感を実感した

 

という話。

 

特に、ミシガン大学日本研究司書の横田カーター啓子さんやハーバード燕京図書館日本研究司書のマクヴェイ山田久仁子さんからよくおうかがいする話で、他の北米日本研究司書の方々からもちょこちょこおうかがいする話として

「中国韓国(多分台湾も)はネットで資料が手に入るけど日本は全然ネットで手に入らないからこのままだと利便性で圧倒的に負けていて若い人がそれを理由に離れていってしまいかねない」

 

という、割と、日本の将来にとって危機的な話がある。これは、江上敏哲さんが彼のご著書『本棚の中のニッポン 海外の日本図書館と日本研究』をはじめとしてあちこちでしておられる話でもある。そこら辺の事情を知る人なら誰でも感じる危機感である。私自身も、海外の仏教学研究者からそれに似たクレームを受けることは少なくないので多少は危機感を共有できていると思っていた。

 

しかし、先日、

 

デジタル・ヒューマニティーズに関して指導をしている大学院生が相談に来たので色々話をしているなかで、検討対象となっている資料が参照している資料集のようなものをちょっと見てみたいねえ、という話になった。1970年代に台湾の中央研究院から出版されたものなので、パブリックドメインではないだろうし、まあでも一応、ネットで探してみるか…と、探してみたら、なんとGoogle Booksにあった。有料で。お金を払うとGoogle Playで読める。Google Playはコンビニでギフトカードを買えばそのポイントで購入できるので(クレジットカードの所有が簡単ではない学生/院生にとっては重要)、さっそく彼とコンビニに行って(ついでにコーヒーなども買って)、戻ってきたらすぐにその資料を読めた。やや荒いスキャンだが、人が読むには十分であり、しかも部分的にだがOCRがかかっていて、数字のところなどは検索までできて、確認したかった箇所もすぐにみつかった。この資料を確認できたことで、次回の国際学会での発表申し込みのアブストラクトの内容をほとんど決めることができ、あとはそれに基づいて文章を書いてきてね、ということになった。

 

…こんな話は、電子書籍業界に少し詳しい人なら誰でも知っているような話だろう、と思うかもしれない。しかし、これが、海外にいる人にとっての日本の資料だとどうか、ちょっと考えて見よう。なぜこのように考えるかと言うと、上記の大筋は、海外(日本)の研究者が台湾の資料を参照するという話なので、海外の研究者が日本の資料を探してみるという話と対比するにはちょうどよいのではないかと思ったのであった。

 

 と言っても、私の場合、海外で日本の資料を参照することの大変さについては十分な知識はないかもしれない。今のところ知っているのは、「日本の図書館では、海外から複写依頼があった場合、著作権保護期間中の著作物はルール上電子送信できないので紙のコピーを郵送している(ので、送る側も大変だろうけどとにかく頼む側にとっては時間がかかり過ぎて話にならないという問題: 参照⇒海外から申し込む |国立国会図書館:)」だけである。もしかしたらもっと良い方法が今はあるかもしれないが、とりあえずこの話を前提とすると、

 

 (ここからは単なる想像です)もし海外で、教員と大学院生が、日本研究に関する研究について相談しながら鍵となる論文を読んでいて、参照されている資料の内容を確認してみたいと思ったら、まずはGoogleで検索してみるだろうか。しかし、Google検索ではすべての本の書誌情報が検索できるわけではないようなので、見つからなければNDLサーチなども使って検索してみるだろう(上記の事例ではGoogle検索で見つかった)。しかし、書誌情報が完備していなかったり、論文の参照の仕方が不十分だったりして候補となる本がたくさんあったり(上記の事例はそうだった)すると、実際にはどれを参照しているのかよくわからない(上記の事例では似た名前の本がいくつか見つかったが内容を一部表示してくれるので確認できた)ので、内容を確認するためにすべての本をとりあえず確認してみなければならない。「どれだろうねえ」となる。とりあえず、近くの図書館に少なくとも候補の一部は所蔵されているようなので、まず、その図書館に行くべきかどうか考える。行く時間はあるか。探す時間はあるか。探したとして、なかった場合どうするか。(もちろん、本が並んでいるところに行けば、探している資料だけでなく他にも色々な関連する資料が視野に入って発想が広がることがあるので、個人的にはなるべく図書館に行くのが好きだしそのようにしているのだが)なかった場合は、研究司書さんに探してみてもらおうか、資料が見つかったらまた続きをしようか、ということになって、この日の研究の相談は終わりである。「この資料を探してみよう」これがその日の相談の成果だ。(上記の事例では、次回の国際学会での発表申し込みのアブストラクトの内容が決まっている)

 

 さて、大学院生(というよりおそらく研究司書さん)が資料を探し始めるわけだが、資料が入手しやすいところになければ、国立国会図書館あたりに複写依頼をかけ、紙で送付してもらうのを待って、送ってきてもらう。しかし、中身が確認できない場合、確認したい本と微妙に違っていたり、複写依頼をした場所がずれていたりしたら、もう1回複写依頼をすることになるかもしれない。複写した資料があたりかハズレか、というのは、研究司書さんと大学院生の間のやりとりで解決できるかもしれないし、あるいは相談相手の教員に資料のコピーを持って行った相談の場でハズレだと発覚して再度相談、となるかもしれない。最長で2週間くらいでなんとかなるのだろうか?あるいは1ヶ月?

 

 ご存じのように、特に北米では、研究成果をどんどん出していかないと専門家として生きていくことは難しい。そして、日本研究をしている大学院生が資料を入手するために数週間をかけている間に、たとえば中国の研究をしている大学院生は、アブストラクトを作って、また次に進んでいるのであるのだとしたら、そのような環境下では、そもそも、日本研究をしていると研究業績が少なくなってしまうので、「東アジア研究」などの枠で勝負になった場合、日本研究の若手が勝てる可能性は少なくなってしまっているのではないかという気がする。こんなことをしていてもらちがあかない、となったら、その資料をみなくても研究できるようにテーマを少しずらそうか、という話になるかもしれない(時々耳にすることのある日本と海外での日本研究の違いはこういうところにも起因しているのかもしれない)。資料をみるだけでこんなに大変だったら、わざわざ日本研究なんてしなくても、中国や韓国も漢字文化圏で古い時代なら知識も生かせるし雰囲気も似てるし(日本人から見ると似てないが)、資料はすぐ入手できるし、中国韓国の研究に移行するか、という風になるかもしれない。いずれにしても、研究発表をしなければ生きていけない米国の研究者業界で、日本研究はおそらくそのような不利な状況におかれているのだと思う。(違っているところがあれば教えてください。)

 

ちなみに、今のような状況でも、多分、インターネットが普及する前は、問題なかった、というより、むしろ、郵便制度が完備していた日本には大きなアドバンテージがあったと思う。しかし、インターネットが普及した今、それを活用できていない現状は、単純に、海外から見ると「不便な状況を放置しているだけ」に見えてしまっているような気がしている。もちろん、どこかがお金を出してくれないとできないことではあるのだが、「どういう風にお金をだしてくれればどういうことをします」ということをきちんと提示しないことにはお金を出しようがないような気もする。一次資料に関しては、しかも著作権が切れているものに関しては、国立国会図書館国文学研究資料館早稲田大学をはじめとして、各地で大きな動きができてきているが、それもまだまだ網羅的と言える段階ではなく、多くはそれほど希少性の高くないものである。そして何より、学術書がまだあまりデジタルで海外から読めるようになっていないそうである。学術出版社だけでなく、学術系の刊行物を出しておられる皆様におかれましては、ぜひなんとかしていただきたいと、改めて思った次第である。

 

(そうそう、前提として、知日家(親日家でなくてもよい)は少しでも海外には多い方がいいと思っている、ということもあります。日本文化のことは、知られていないよりは知られている方が、色々な面で良いと思うのです。)

 

もちろん、できることがあればご協力もしたいと思っておりますので、私にお手伝いできそうなことがあれば、お声がけください。