バラバラになった各地の西洋中世写本断片をまとめて表示：IIIFの活用例

また少し時間がたってしまいましたが、今回は、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）、です。そちらでは、こういった話を、私だけでなく、色々な専門の方々がそれぞれの視点からお話してくださる機会になりますので、なかなか稀有な機会になると思います。お時間がございましたらぜひご参加ください。

写本や貴重書等の書誌情報の書き方について(TEI/XMLのご紹介)

　最近、メタデータの書き方について相談を受けることが多いので、今回は、写本や貴重書的な資料の書誌情報の書き方に関して、ちょっと事例を紹介させていただきます。

　テクスト資料のデジタル化に関しては、いわゆる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人以上集まるならおうかがいして講習などいたしますので、ぜひお声がけください。

IIIF画像配信の高速化のために（HTTP2の可能性と課題）

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の最新版に右⇒左ページめくり方向を実装してみました（5/8追記あり）

IIIF対応ビューワの代表格の一つ、Miradorですが、アノテーション機能と複数画像同時表示機能という大変便利な機能を提供してくれている一方で、右から左へのページめくりに対応していないため、東アジア系の資料に適用することがなかなか難しい状況でした。以前に、対応版を作ってみましたが、ちょっと機能的にいまいちでしたので、改めて、最新版をもとに追加しなおしました。それがこちらです。

Mirador Viewer

…と言っても、これだけですと、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」からできるようになっているようです。たとえば下記のブログなど、さっそく、専門の方々からも喜びの声があがっているようです。

d.hatena.ne.jp

これで、万単位の古典籍資料が「この資料を」と言って提示する時にURLで直接提示して公式サイトにリンクできるようになりますので、地味ですが、本当に大きな進歩です。

特に国文学研究資料館の古典籍のデータベースに関してのこれまでの問題点は、細かいところでもいくつかあるのですが、大きなものとして、（1）書誌情報に外からリンクを張れないために、URLで典拠情報を提示できなかったことと、（2）画像のページには外からリンクを張れるが、そこから書誌情報のページに戻れないために、画像を見ても何の画像だかすぐにはよくわからない（＝画像自体を自分で見て判断するか、書誌情報を別途検索して探さなければならない）、という2点がありました。このうち、（1）が解消されたということになります。

このことを知ったときにすぐに思い浮かんだのは、先月に急逝された古瀬蔵先生のことです。古瀬先生は国文学研究資料館の情報部門の責任者としてこの十数年ほどお仕事をしておられ、2011年のもののようですが、お人柄をよくあらわした（ように個人的には思っています）ざっくばらんなご対談が、国文学研究資料館のある立川市のタウン誌のサイトに掲載されています。研究領域が近かった古瀬先生とは色々な研究会を通じてお話しをすることがあり、この数年は国文学研究資料館の電子情報化委員というアドバイザー的な仕事をしていたこともあったので、上記の2点をやってください、と、ずっとお願いしていて、今年度に更新したシステムでは（1）はできるようにする、でも（2）は今回は無理だった、ということをうかがっていて、今か今かと待っていたのでした。結果として、1年近くかかってしまいましたが、ようやく（1）が達成されました。

　古瀬先生が時折私にお話ししてくださっていたことの一つに、自分がいなくなってもシステムが動くようにしないといけない、ということがありました。確かに私は先進的なシステムを提供しようとするあまりに自分がいなくなったら動かなくなるのではないかという懸念とは背中合わせの状況にあります。自分がいなくなっても稼働し続けられるように、続く人が継続できるようにと、いろいろな工夫をしてきていて、IIIFやTEI、Unicode等に入れ込んでいるのはそれを解消するための土台を皆で共有できるようにするということもあるのですが、まだ完全とは言えません。一方、古瀬先生が責任者として動かしておられた仕事は、事業として確実に動かせる形を目指して整備され、古瀬先生が亡くなった後にも着々と進められ、ついに公開にまで至り、とても地味ですが、しかし、国文学のみならず、日本文化研究全般を大きく前進させる1歩を刻むことになりました。それだけでなく、色々なデータベースがシステムの全面更改を経て今もなお普通に使えていることもまた、古瀬先生のご尽力に負うところが大きく、そこには学ぶべき事が多々あると思っています。国文学研究のデジタル化という極めて難しい仕事に取り組んでこられ、時折その大変さをおうかがいすることはありましたが、情報工学者と人文学者というギャップにはじまり、事業として研究を支援すること、日進月歩のデジタル技術を事業として扱わなければならないことなど、おそらくはおうかがいする以上に大変なことは様々にあったのだろうと思います。道半ばになってしまったことは古瀬先生としても残念なことだろうと思いますが、その着実なお仕事は、今後も、おそらくはほとんどそれと意識しない形で、我々に色々な恩恵を与え続けてくれることでしょう。

古瀬先生、ありがとうございました。

国立公文書館で紹介された「最新のIT技術を活用したデジタルアーカイブ・システムの調査検討報告書」について気がついたこと

ところで、先日、国立公文書館から、

• 最新のIT技術を活用したデジタルアーカイブ・システムの調査検討報告書（平成29年１月）(PDF)

というものが公開されたようで、「調査・報告書等」のページから閲覧できるようになっています。前の記事にてご紹介したブログを公開しているインフォコム株式会社さんの名前が最初のページに書いてあるので、インフォコムさんが作成されたのでしょうか？この調査報告の発注した文書などを確認すればわかるのだと思いますが、それは、どなたか、識者の方にご教示いただけますとたいへんありがたく存じます。

内容的には頑張って色々まとめておられて、「最新のIT技術（情報技術技術？）を活用した」というにはそんなに最新な感じはしませんが、現状を把握するにはよい文書なのではないかと思います。細部には色々気になる点もありますが、そういうところには突っ込みを入れつつ、これを使って読書会などをしてみるのもよいのではないかと思います。

ただ、拝読していて、ここは誤解を招きかねないのでちょっと書き換えていただいた方がよいのではないか、というところがあったので、念のため、ちょっと以下にメモしておきます。特に気になったのは、70ページの以下の記述です。

IIIF に対応したビューアである OpenSeadragonは、JavaScript で実装されたオープンソースの画像ビ ューアである。様々な解像度の画像を、解像度ごとにタイル画像に分割しておくことで、スムーズな拡大・ 縮小と移動を行える操作性が特徴である。ただし、この機能を構築するには、タイル画像を事前に用意 する必要があり、元の画像データの数倍から数十倍のディスク容量が必要となる。

先にまとめておくと以下の2点です。

（1）IIIF対応ビューアとしてOpenSeadragonを挙げるのは不適切

（2）「元の画像データの数倍から数十倍のディスク容量」を必要としないどころかJpeg画像そのままでもIIIF対応は十分可能。

まず、（1）ですが、

OpenSeadragonは、IIIF Image APIにしか対応していないので、「対応したビューアである」という例として挙げるのはよくないと思います。IIIFに対応したビューアを挙げるなら、Mirador, Universal Viewerなど、IIIF Presentation APIにも対応しているビューアを挙げないと、ミスリードになると思います。もし、OpenSeadragonを紹介したければ、別項を立てればよいと思います。

なお、OpenSeadragon自体はとても良い画像ビューワで、私もよく使っていますが、通常のIIIFビューアに比べると利用者に直接提供する機能はかなり少なめです。APIが充実しているので、開発者がユーザ向けにいろいろな機能を追加して提供することがかなり容易にできます。そこで、IIIF対応ビューアの中でもMiradorやUniversal ViewerはこのOpenSeadragonを内部で利用しています。

次に、（2）ですが、

OpenSeadragonが標準的に対応している画像配信（？）形式であるDeepZoom形式では、確かに、分割タイル画像を用意しておく必要があります。しかし、OpenSeadragonが対応している画像配信形式にはIIIF Image APIもあります。（ここではこの話のはずです）。IIIF Image APIの場合は、画像をどういう風に用意するか、というのは画像配信サーバに依存する形になります。そこで、画像配信サーバがどういう画像を配信できるか、タイル画像を事前に用意しなければならないのか、という話になるのですが、このブログでも以前にご紹介した digilibというIIIF対応画像配信サーバソフトでは、画像をJpeg画像のままで配信できます。そうすると、元画像の数倍のディスク容量、どころか、まったくディスク容量を増やす必要はありません。たとえばこちらのサイトではdigilibで400万枚ほどの画像を配信していますが、特に問題なく配信できていると思います。あるいは、Loris IIIF Image ServerというIIIF対応画像配信サーバソフト（これはUbuntuへの導入の仕方を2SC1815Jさんが紹介しておられます）では、ディスクにキャッシングをするようですので、キャッシュ用ディレクトリに多少ディスク容量を多めにとる必要があると思いますが、それでも元画像の数倍～数十倍、ということはないのではないかと思います。

まとめますと、この報告書を信頼して読んだ人は、OpenSeadragonを使ってみて「うーん、IIIF画像を読み込ませるのにこんなに手間がかかる上に、この程度のことしかIIIFではできないのか」と思ってしまうでしょうし、「数倍から数十倍のディスクを用意しないとIIIFには対応できないのか」と思ってしまうでしょう。もちろん、IIIFの本家のサイトを読んだりこのブログを見たりして自力で情報収集できる（時間のある）人には問題ないと思うのですが、この報告書は、そういう人向けではないと思いますので、なるべく、適切な情報を提示しておく必要があると思うのです。

そして、これを踏まえた上で気になるのは、85ページの、「コスト IIIF への対応にはコストがかかる。 」という記述です。確かに、0円ではできません。が、IIIF Image APIへの対応は、digilibでよければ、ソフトウェアを一つ入れるだけで済みますし、Lorisでいいなら、ソフトウェアを入れることと、キャッシュ用に多少のディスク容量を用意しておくだけでもなんとかなるはずです。（ただしLorisに関する私の知識は2年前なので現在は変わっているかもしれません）。「ディスク容量を数倍から数十倍に」というのと、「サーバソフトを入れるだけでも大丈夫」というのとでは、コストがかかると言ってもまったく印象が違ってくると思います。

それから、ついでに、数日前に、「資料が増えると対応の手間がその分増えて時間もかかるのではないか」という質問をいただいたので、そういうコストを想定することもあるのかと思って念のため書いておきますと、IIIF Presentation APIのファイルは、メタデータセットがあって、画像全体のディレクトリへのアクセス権限を持っているプログラムを作ることができれば、あとはそこから自動的にJSONファイルを出力するだけです。たとえば、こちらの約400万枚／1万9000点の古典籍資料と、こちらの12冊の本とでは、Presentation APIへの対応にかかる手間はほぼ同じです。プログラム作って、それを動かして自動的にファイルを生成するだけです。ファイル生成作業も、そもそも、動的にmanifestファイルを生成するようなシステムにすれば、不要になってしまいます。

IIIFへの対応には、確かにコストがかかります。ただ、そのコストを大きく見積もりすぎた結果、我が国がまたしても国際的な流れから大きく遅れをとるようなことになってしまいますと、さすがに今回はちょっと取り返しのつかないことになってしまうのではないかと心配しております。

今のところ、IIIFに対応してくれている「デジタルアーカイブシステム」提供企業としては、私が把握している限りでは、内閣府知的戦略本部のワーキンググループでも報告した話ですが、以下のようになっています。

• ㈱NTTデータ
　• ヴァティカン図書館
• インフォコム㈱
　• 東日本大震災アーカイブFukushima／国立歴史民俗博物館（総合資料学の創成プロジェクト）／岡山県立記録資料館
• ㈱メノックス　
　• 慶應大学メディアセンター（福沢諭吉コレクション・グーテンベルク聖書・奈良絵本・解体新書等）（公開予定）
• ㈱寿限無
　• 秋田県立図書館オープンライブラリ／高知県立図書館デジタルアーカイブ（試行版）（但し、IIIFでの運用方法が未定のため、来期以降運用等を検討予定）

基本的に、IIIFは、画像をうまく共有するための基盤の提供のための枠組みであり、そこはなるべく低コストに安価に提供していただいて、画像配信に関するビジネスとしては、配信した画像の上に何をどうのせていくか、というところで勝負をしていただけるとありがたいと思っております。IIIFが広まれば広まるほど、「その上に何かをのせる仕組み／サービス／ビジネス」の有用性は高まっていきます。また、みなさまがそれぞれに蓄積しておられる技術も、そこで改めて色々再展開できるものがあろうかと思います。Webが広まったことでいろいろなビジネスが開花していることと、規模の違いはあるにせよ、相似の関係にあると思います。そのような観点から、企業のみなさまには、ぜひとも、日本のデジタル文化資料を生かし、世界に貢献していけるような基盤を作り、ご提供していっていただけたらと思っております。

（なお、企業のみなさまにおかれましては、IIIF対応サービスや対応機関などの情報がありましたら、当方までお知らせいただけますとたいへんありがたく存じます。）