今まさに広まりつつあるデジタルアーカイブの国際規格IIIFの導入の仕方

前回の記事では、IIIFについて、主にユーザ側の視点から、良くなりそうなことを簡単にご説明しました。今回は、IIIFの導入の仕方についてちょっとご紹介したいと思います。

一昨日開催された人文科学とコンピュータ研究会で、10分だけ、IIIFをご紹介する機会をいただいたので、研究者としてこれと付き合うとしたらどういうポイントがあり得るか、という視点からちょっとご紹介をしました。その中で使ったスライドの図を、まずは以下に掲載します。

要するに、

１．対応画像サーバソフトをインストール・設定する

２．メタデータ等をPresentation APIに従ってJSON-LDに変換する

という２点ができればOKです。では一つずつ下記で検討していきましょう。

１．対応画像サーバソフトをインストール・設定する

　まずは、画像にアクセスできるサーバマシン上に、対応画像サーバソフトをインストールして設定します。ただし、これに際しては、場合によっては、画像形式をTiled TIFF画像形式に変換しなければならないことがあります。特に、画像がかなり大きかったり、アクセス数がかなり多く見込まれる場合などです。そこで、ここでは２つのやり方を見ていきましょう。

1-1. Loris IIIF Imageサーバ：画像が大きくなくてアクセス数もそれほど多くない場合

　画像サイズが1MB～数MBで、アクセス数もそれほど多くなければ、サーバマシンのスペックにもよりますが、Loris IIIF Imageサーバという、Python製のサーバで大丈夫ではないかと思います。また、実験的に導入してみようという場合も、とりあえずはこれで十分かと思います。

　インストールはPythonにある程度通じていればなんということはないと思うのですが、ちょっとややこしいのが画像の置き場のディレクトリ構成です。設定ファイル loris2.conf の中で

src_img_root = '/opt/imagefiles/'

とした場合、

/opt/imagefiles/NIJL0008/NA4-0644/NA4-0644-00007.jpg

という画像が、下記のURLでアクセスできることになります。

http://www2.dhii.jp/loris/NIJL0008/NA4-0644/NA4-0644-00007.jpg/full/full/0/default.jpg

 （初めてインストールした時はこの関係がよくわからなくて、インストールに成功したかどうかすらよくわからず、ちょっと時間をつぶしてしまいました）

1-2. IIP Image サーバ：画像が大きかったりアクセスが多そうな場合

　一方、ファイルサイズが大きい場合（目安は10MB～？）、あるいは、アクセスがかなり多く見込まれる場合、IIP Image Serverを使っていただいた方が良いかもしれません。こちらはインストールがちょっとややこしいので、公式サイトのインストールガイドに加えて、私が書いたインストールガイドもご覧ください。特にCentOS環境なら、私のインストールガイドだけでもインストールできると思います。Debian系の場合も、注意点（バイナリをインストールしてもIIIF対応バージョンがインストールされない、等）は共通するところがあるようですので、一応目を通しておいていただくとよいと思います。

　こちらの場合は、上記のインストールガイドにも書いてあるように、タイル形式画像を用意する必要があり、お金がなければTiled Tiffしか選択肢がないので、結果的に、ちょっとストレージをたくさん必要とすることになります。この点、ちょっと注意が必要です。

さて、画像サーバのインストール・設定が終わったら、次はPresentation APIへの対応、つまり、JSON-LDファイルの作成です。

２．メタデータ等をPresentation APIに従ってJSON-LDに変換する

　これは特に難しいことはありません。既存のメタデータと、画像の入っているディレクトリがあれば、あとは、Presentation APIに従って、JSON-LDファイルを作っていくだけです。ただし、ここで、上記のIIIF対応画像サーバによって使えるようになる Image APIに準拠した画像のURLが必要になりますので、手順としては、画像サーバインストールが先に必須になります。

　ファイルの作り方については、たとえば私の場合、PHPで、同内容の連想配列を作ってから

json_encode(連想配列, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT)

などとしています。「とりあえずIIIF対応ビューワに読み込ませて動作する」というレベルのものについてはこちらを参考にしてみてください。このPresentation API準拠のJSON-LDファイルが IIIF Manifest等と呼ばれるものになります。ここでは「マニフェストファイル」と呼んでおきましょう。

　基本的な考え方としては「キャンバス」を集めたものが「マニフェスト」です。このマニフェストが一つの本とか作品等にあたります。

　マニフェストから上位の概念を見ていくと、マニフェストを集めたものが「コレクション」で、コレクションはさらに集めて上位の「コレクション」とすることもできます。コレクションの例はたとえばこんな感じです。

　一方、マニフェストから下位の概念を見ていくと、「キャンバス」が、画像やアノテーション等を載せるための仮想的な概念（コンテナ）として用意されています。この「キャンバス」の順番を決める「シーケンス」があり、さらに、キャンバスを「章」のような形で少しずつまとめていく「ストラクチャー」も用意されています。ただし「ストラクチャー」については、きちんと実装されているビューワはハーバード大学版Miradorくらいしかみたことがありません。先週この開発者にお会いしたので聞いてみたところ、近々Miradorの正式版にもこの機能が取り込まれるとのことでした。

　ちなみに、私は画像上にアノテーションを付ける目的があってIIIFとMiradorにちょっと入れ込んでおりまして、ごく近いうちに、その機能を活用した画像データベースを公開する予定です。アノテーションの付け方は、前回の記事にも書きましたが、たとえばこういうマニフェストファイルを作って（このファイル中の http://www2.dhii.jp/loris/NIJL0008/NA4-0644/p5 の「otherContent」に注目してください）、これに対してアノテーションのファイルはこんな感じになります。IIIF対応画像ビューワMiradorでの実際の利用例はこちらです。Media Fragments URIがここできちんと活用されるようになっていることに感涙することしきりです。

＜実際にマニフェストファイルをIIIF対応ビューワに読み込んで確認してみましょう＞

さて、JSON-LDによるマニフェストファイルができたら、あとはこれをビューワに組み込むだけなのですが、代表的なビューワは、いずれもマニフェストファイルのURLを入力すればそのマニフェストに含まれる画像やメタデータを表示してくれるようになっており、さらにMiradorに至っては、上記のようなアノテーションまでも表示してくれます。

 　マニュフェストファイルをビューワに読み込ませる方法ですが、Universal Viewerはリンク先をみていただけば一目瞭然で説明の必要はないと思います。あるいは、公式サイトでは、いきなりマニフェストファイルのURLの入力を要求されるようになっています。ただしこちらは、アノテーションの表示がまだできないようです。Universal Viewerはマルチメディアコンテンツを色々表示できるように拡張に取り組んでいるそうです。

　Miradorの方は微妙にわかりにくく説明を必要とすると思うので、一応、下記に説明をしておきます。たとえば、こちらの例の場合では、画面の左上の方に用意されいているアイコンをクリックすると…

下記のようなメニューが現れますので、「新しいオブジェクト」を選択します。

そうすると、右上に「URLで新規オブジェクト追加」という項目が表示されて入力欄が出ますので、ここにマニフェストファイルのURLを入力して「Load」をクリックします。そうすると、そのマニフェストファイルのコンテンツが表示されるようになっています。

 ここまでできたら、IIIF対応はできた、と言っても大丈夫ではないかと思います。

さて、せっかくIIIF対応マニフェストファイルを用意できたのですから、自前でビューワを用意してそこに読み込ませたい、という気持ちが出てくるのは当然かと思います…が、それはまた次回に、ということで。

今、まさに広まりつつある国際的なデジタルアーカイブの規格、IIIFのご紹介

※IIIFの情報を求めてこちらに来られた方は、「IIIF日本語情報私的まとめ」もご覧ください

現在、デジタルアーカイブにおいて画像を公開し共有するための国際的な枠組みが作られ、採用が広まりつつあります。International Image Interoperability Framework、略してIIIF（トリプルアイエフ）というもので、英国図書館、フランス国立図書館、オックスフォード大学ボドリアン図書館、スタンフォード大学、プリンストン大学、イェール大学など、錚々たる機関が始めた規格で、国立国会図書館のカレントアウェアネスポータルでも何度か簡単に紹介されているようです。

　これまで、デジタルアーカイブに関する大きな難点の一つであった、「各地のデジタルアーカイブで個別に公開されて、いちいちそれぞれのサイトの使い方を覚えなければならず、使い勝手も善し悪しが大きく異なる」という状況が、IIIFの登場と普及によって、ようやく、そして一気に解決しようとしています。

　つまり、画像データやそれに対する注釈情報等のコンピュータ間でのやりとりの仕方を各機関の間で一元化することによって、利用者が色々な使い方を自由に選べるようにする、という状況がもたらされようとしているのです。

　このブログでは、何度か、その仕組みの裏側についてご紹介してきましたが、今回は、普通の利用者にとってIIIFがどういう風に作用することになるのか、ということに焦点をあててご紹介していきたいと思います。（一応、技術的な事柄が中心になりますが、技術的な事柄がよくわからないという人も、いきなりこのページを閉じないで、とりあえず、下記の紹介画像だけでも見ていっていただいて、雰囲気だけでも感じていただけたらと思います。）

ここまで何度か、IIIF Image APIについて採り上げつつ、IIPImage Serverのインストールについてのご紹介などをしてきました。（詳しくは過去記事をご参照ください）IIIF対応画像サーバのインストールは必須なので押さえておかねばならないのですが、ここでは、これを踏まえた上でのIIIF Presentation APIのご紹介、ということになります。

基本的には、

・世界中のどこのデジタルアーカイブの画像ファイルでも、その情報を自分のビューワに読み込ませるとそれを表示してくれる。

ということに尽きます。しかし、これは決して当たり前のことではなくて、私も長年夢見てきたことに向けた大変大きな一歩が踏み出されたというところがすごいところなのです。もう少し言い方を変えてみると、

・IIIF Presentation APIに沿った形式のJSONファイルで画像ファイルの情報をサーバに置いておくとどこのどのビューワでも自由に表示できるし画像上に注釈を付けたりすることもできる。

という風になります。

さらにこれを利用者目線に寄って見みてみると、

IIIF 準拠で画像公開されていれば：

• いくつかの選択肢の中から好きなビューワを選んで使える
• どこのサーバで公開されていても一つのビューワの中で一元的に扱える

というような感じになります。

さて、ビューワですが、今回は MiradorとUniversal Viewerを試してみました。いずれもフリーソフトですが、かたやスタンフォード大学やハーバード大学、UCLA、など、かたや英国図書館やウェルカムライブラリなど、いずれも大手の関係機関が関わっているもののようです。他にもいくつかよさそうなフリーソフトがありますが、とりあえず今回はこの二つに圧倒されてみましょう。

IIIF Presentation APIでは、何度も書いていますが、一定の書式に従ってJSONファイルを作成することが前提です。これを読み込むことで、サーバがどこにあっても、手元のビューワに画像を読み出せるようになっています。JSONファイルは、たとえば、下記のような感じです。

http://oculus-dev.harvardx.harvard.edu/manifests/via:olvwork576793

http://dms-data.stanford.edu/data/manifests/BnF/jr903ng8662/manifest.json

http://www2.dhii.jp/nijl/NIJL0003/049-0197/manifest.json

これだけ見ると難しそうでわけがわからん、という人もおられると思いますが、基本的には機械的に生成できますので、いちいち手で書く必要はありません。今回、国文研データセットに関してはちょっとプログラムを作って350ファイルを自動生成しました（まだ記述が完全ではありませんが、書式は正しく、動作もきちんとします）。なお、エラーチェックに関しては、簡単なバリデータがありますので、これで確認しながら進めるとよいかと思われます。（バリデートされたからといって必ず動作するとは限らないので要注意ですが）

とりあえず、これをいつもの国文研オープンデータセット簡易Web閲覧のページから個々にダウンロードできるようにしておきました。「IIIF manifest」というリンクをクリックするとJSONファイルが開きますが、これを開いても仕方がないので、URLをコピーして、IIIF対応ビューワに読み込ませるなどとして、適宜ご利用ください。（IIIF manifestファイルをここで入手できる、ということを覚えておいてください。）

それから、このページにはというアイコンが登場していますが、これはIIIF対応ビューワにドラッグ＆ドロップするとその画像セットを閲覧できるようになる、というアイコンです。そして、このアイコンの隣に「UV」というリンクがありますので（上記画像には出ていませんので当該ウェブページにて直接ご確認ください）それをクリックするといきなりUniversal Viewerでファイルを開くことができます。たとえば以下のような感じです。

このビューワは、今の段階ではまだ普通のビューワです。とりあえずあちこちクリックしたりしてみて機能を確認してみていただけますとよいかと思います。

特にこのビューワで面白いのは、「今見ている領域をそのままURLにして共有できる機能」です。

画像閲覧中に左下のアイコンをクリックすると上記のような表示になりますので、サイズを選んだりしつつ、表示されているURLのみ、あるいはHTMLタグごとコピーして適宜利用して、表示中の領域を再現できるようになっています。この機能は、我らがe国宝でかなり以前から提供されてきているので既視感がありますが、このようにして簡単にどこでも実装できるようになると、これはこれで今後の展開が楽しみなところです。

それから、先ほどご紹介したIIIF ManifestファイルのURLを読み込ませて表示させる、という機能をUniversal viewerは持っています。画像表示画面の下の方にURLを書き込む場所がありますので、そこにIIIF ManifestファイルのURLをコピペするなどして「Set」をクリックすればOKです。ちょっと時間がかかることや、公開元によってはサムネイル画像がうまく表示されないことなどがあるようですが、国文研データセットのIIIF Manifestファイルでは、確認した限りでは、普通に表示されるようです。

ここまで見ていただけば、「各地で公開されている画像を一元的に扱える」というのは大体ご理解いただけたかと思いますが、これだけではちょっとインパクトに欠けると思います。そこで次にご紹介したいのがMiradorです。

まず、下記の２件の表示を見てください。これです。これが、IIIF対応している画像であればどれでもできるのです。しかも、フリーソフトで。

さて、では、Miradorについて見ていきましょう。まずはデフォルトのページをご覧ください。ここで大きな十字が表示されると思います。この十字をクリックしてください。そうしますと、下記のように、登録されている各資料がずらっと表示されるはずです。

ここでいずれかの資料や画像をクリックすると、ビューワに表示されます。

それから、ここには表示されていないけど使いたい画像があってIIIF ManifestファイルのURLを知っているという場合は右上の空欄にそのURLを書き込んで「Load」をクリックするとこの一覧にその資料が追加されます。

ビューワに表示されると下図のようになりますが、これは普通の拡大縮小可能なビューワですので（内部的にはOpenSeadragonのようです）、特に変わったところはありません。

このビューワ画面の右上に注目していただきますと「レイアウト変更」というリンクがあります。これをクリックしますと下記のような画面になって、１つのページ内に表示できる画像数を設定できるようになります。

とりあえず、１×２を選択すると下記のようになります。これで、先ほどと同様に「アイテム追加」をしていただくと、他の資料を選択できるようになりますので、適当に選択してみてください。そうすると、２つの図を並べて表示できるようになります。

最初から複数の画像を並べて表示させることもできます。寛政武鑑だけを最初から並べて表示できるようにしてみたのがこちらのURLです。下記のようになるはずです。

さらに追加していくと、下図のように６つの寛政武鑑を並べたりすることもできますのでお試ししてみてください。

ちなみに、ちょっと動作が遅い…と思われた方もいらっしゃるでしょう。それは、国文研データセットのIIIF画像配信サーバソフトがあまり速くないものであることと、そのハードウェアももう5歳になってしまっているためかと思います。機会があれば、もう少し速いものに置き換えたいと思っております。

それから、この仕組みでは、Open Annotationを採り入れており、Media Fragments URIに準拠した形でアノテーションもできます。たとえばこんな感じです。これは、manifestのjsonファイルとは別のファイルとして作成する必要があり、manifestファイルから参照する形になります。annotationファイルの例はこちらです。なお、annotationファイルは「list」というディレクトリに入っていなければならないようで、Presentation APIの仕様書にはきちんと書いてありますが、よく読んで取り組んでください。

というわけで、この数日の苦労を惜しげもなく開陳してしまったわけですが、あまりに圧倒されたので、とりあえず日本の皆様にもこれをよく知っていただきたい、というか、フリーソフトを組み合わせるだけでちょっと時間をかければどこでも使えるようになる、そして、ここまでのことができるようになっている、ということをお知らせしなければと思ったのです。

このような枠組みに、世界中の多くのデジタルアーカイブ公開機関が賛同し、協働で新しい世界を構築しようとしているようです。参加機関のリストを見るだけでもかなり圧倒されますが、ここにリストされていない大型機関でもIIIF対応を進めているところがあるようで、少なくとも２箇所、知っております。そのようなことで、日本の関係機関の皆様におかれましても、この枠組みにうまく乗っていただけたらなあと、そして、システムを開発・提供する企業の皆様におかれても、うまく対応していただけたらなあと思うところです。

それから、本件については、特に  @2SC1815J さんにいくつか重要なご教示をいただきまして、それがなければこんなに早くできることはなかっただろうと思います。感謝すること至極です。

最後に、この件について色々検討したりされる方々の資料作成が少しでも容易になるように、例示したURLやその他役立ちそうなURLを掲載しておきます。

規格関連

IIIF Presentation API

Media Fragments URI

IIIF Image API

周辺情報

IIIFコミュニティに参加しているデジタルアーカイブ公開機関のリスト

IIIF対応ビューワ Mirador

IIIF対応ビューワ　Universal Viewer

IIIF対応ソフト一覧

ハウツー

IIPImage Serverのインストールについてのご紹介

IIIFの事例

国文研オープンデータセット簡易Web閲覧

Universal Viewerによる事例

Miradorのデフォルトのページ

Miradorでアノテーションをつけた事例

Miradorで寛政武鑑を並べて表示する事例

Miradorで国文研データセット「日本文学」を表示する事例

Miradorで国文研データセット「芸術・諸芸等」を表示する事例

実際のJSONファイルと作成支援ツール

ハーバード大学で公開しているIIIF ManifestのJSONファイル

スタンフォード大学で公開しているIIIF ManifestのJSONファイル

国文研データセット用のIIIF ManifestのJSONファイル

IIIF Presentation API用に今回作ったアノテーションのJSONファイル

IIIF Presentation APIのための簡単なバリデータ

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

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

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

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

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

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

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

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

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

５．フルサイズの切り出し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をさらにいじると、傾けたりひっくり返したり拡大縮小したり、色々なことができます。

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

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

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

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

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

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

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

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

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

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

１．サーバソフトのインストール

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

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

１．サーバソフトのインストール

今回は、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サーバが動作しているというページが表示されるかどうか確認してみてください。もし表示されないようなら、ディレクトリのアクセス権限等を確認してみてください。

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

ピラミッド型タイル画像ファイルを用意するにあたっては、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の二強の一角、AndroidはLinuxベースですし、パソコン用もあって…という感じですが、大きな流れとしてはインターネットサーバ用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）でも同じように表示してくれます。

ちなみに、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。まだ相互連携してませんが（日本の古典籍のオープンデータ！その３）

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

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

D3.jsの組み込み

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

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

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

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

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

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

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

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

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

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

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

.../full/!2000,2000/90/default.jpg

一部を指定して切り出して表示
.../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

さらに、座標がちょっとずれますが、寛政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

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

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

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

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