Omeka IIIF ToolKitを少し便利に

少し時間が空いてしまいましたが、その後、SAT大蔵経テキストデータベースの再構築作業をはじめ、手元の作業に時間を費やしておりまして、しかしシステムが大きくてなかなか公開するところまで至らず、ブログ更新するネタがない状態できておりました。一方で、リアル（？）講習会（IIIF講習会やTEI講習会など）は着々と実施しておりまして、12月には沖縄県立芸術大学と琉球大学附属図書館でもIIIF講習会を実施しました。その後引き続き、基本的にはSAT大蔵経テキストデータベースの再構築作業を続けているのですが、機能が多すぎてまだ公開できるところまでたどり着いておりません。もう少ししたら公開できると思いますので、もうしばしお時間をください。

　それはともかくとしまして、今回は、東京大学の「文化資源デジタルアーカイブ特論」という3日間の集中講義のなかでOmeka IIIF Toolkitを実習教材として使った際に、受講生から出た要望にもとづいて少し改良をしましたので、それをご報告したいと思います。

　Omeka IIIF Toolkitでは、これまで、地図上にプロットした点などをクリックした際に、そこに紐付けられているアノテーションがどんなに小さかったとしても画像全体が表示されてしまって、ただでさえ小さなMiradorの画面領域で、アノテーションがとても小さく表示されてしまい、いちいちユーザが拡大して確認しなければなりませんでした。技術的には紐付けられていて、辿ることもできるようになっているとしても、これではちょっと不便です。それを受講生に指摘されて、なんとかならないものかと思ったので、集中講義の期間中、夜にちまちまと宿題的にコーディングしてみました。相変わらず適当なコーディングですが、一応、動くようになったので、Githubに置いてみております。そもそもfile_get_contents()を使うよりも直接必要なパラメータを既存の値から取得した方がいいと思うのですが、それをどうやって取得すればいいのか調べる時間が惜しく、とりあえずすぐできる方法ということでこういう風に書いてしまいました。具体的には、以下の画像（動画GIF）のようになります。

たとえばこちらのサイトなどで実装してみています。

地味な変更ですが、ピンポイントで結構便利な感じになるのではないかと思います。もしIIIF Omeka Toolkitを利用しておられるかたがおられましたら、既存のファイルのバックアップをとった上で、上記のファイルを入れ替えてみていただくと、それだけで使えるはずですので、よかったらお試ししてみてください。あと、拡大のためにMiradorに渡すパラメータを、もっと良い案配に調整していただくことももちろんアリですので、よりよい計算式を作られたらぜひご教示ください。（ちなみに、Miradorが依拠しているOpenSeadragonでは、位置情報を採るときに、縦軸は横軸の長さに対する相対値で見ますので、Media Fragments URIとのやりとりをする際には、その点、注意が必要です。）

ということで、よろしくお願いいたします。

国会図書館で近デジIIIFコンテンツを使って一緒に地域資料マップを作ってみませんか？

　先日、NDLライブラリーカフェのアナウンスがありました。第2回を私が担当させていただくことになりましたが、これは、次世代開発室の皆さんと暖めてきたもので、地域資料＋IIIF＋地図年表マッピング、を参加者のみなさんで色々試してみよう、という企画です。

　国立国会図書館のデジタル化資料はあまりにも大量にありますが、ありすぎてほとんど埋もれているとしか言い様がない状況でもあります。山のなかから宝を引き出そうと、色々な方々が色々に工夫をしてきているところですが、今回の企画では、とりあえず、引き出したものを一つの地図に載せてしまえば、それはそれでコンテンツとなり得るのではないか、ということが基本的な目論見です。ただし、ここで完成品を作って世間に公開しよう、ということを目標とするのではありません。もちろん、世間に公表できるような、良さそうなものを作ることができればベストですが、主眼は、「こういう風に自分たちでもできる」ということを皆さんが体験してくださることです。ここで使うシステムは、すべてフリーソフトウェアであるというだけでなく、セットアップもかなり簡単で、少しサーバ構築の経験があるような人なら、とても簡単に、「IIIFコンテンツを取り込んでメタデータを適宜修正しつつアノテーションもつけて、それを地図・年表上にマッピングする」というシステムの提供ができるようになってしまいます。つまり、ここで経験したことを、持って帰っていただいて、身の回りの方々や自分の組織で、こういうことに取り組んでみていただけるように、ということを最終的には目指しております。もちろん、必ずそうしていただかなければならない、というわけではなくて、そういう機会があればそうなるとありがたい、というくらいのことですが。

今回使うシステムの解説は、こちらのブログ記事にて掲載しております。そして、具体的に作るもののひな形は、以下のような感じです。

仮想コレクション＠NDLライブラリーカフェ · IIIF-Omeka Sandbox

　いわゆる地域資料には、様々な地域の情報が含まれているにもかかわらず、NDLデジタルコレクションに入っているだけだと、文字検索ができないのでなかなか見つけてもらえず埋もれたままになってしまいがちです。しかし、今回のシステムで、(1)画像を取り込み、(2)アノテーションを付けると、そのアノテーションがGoogleなどの検索エンジンから検索してもらえるようになります。ですので、画像上に、皆にみつけてもらいたい箇所だけでもアノテーションを付与しておけば、一気に発見性が高まります。たとえばこういう感じです。（うまくいくといいですが・・・。）

　さらに、2つ上のURLの例のように、地図・年表上にマッピングすれば、地図を提示することで、地図を介して色々な形でみていただくことができるようになります。NDLデジタルコレクションのデジタル化資料は、著作権保護期間満了の資料がほとんどなので、どうしても古い情報ばかりになってしまいますが、しかし逆に、戦前はどうだったのか、ということを示したり確認したり共有したりするにはとても良い素材であるように思われます。意外と我々には伝わっていない事も結構あります。そのような情報を、地図・年表から見ていくことができれば、地域への親しみ方もまた少し変わってくるかもしれません。

　そこで、このライブラリーカフェでは、主に、旧近代デジタルライブラリー（古典籍ではない）の、地域に関する資料を使って、アノテーションや地図年表マッピングをしていただきたいと思っております。そして、それにあたっては、いったん、皆さんが扱いたいと思うデジタル化資料をIIIF対応に変換します。以下のURLなどから、使ってみたい資料のURLを確認して、申込時に書き込んでいただけますとありがたいです。あるいは、後からでしたら、筆者に何らかの形で連絡していただけますと幸いです。

国立国会図書館デジタルコレクション - 地域の歴史に関する資料（都道府県ごと）

の「1. インターネット公開のみを検索」から、資料を探していただけると大変ありがたいです。

このシステムは、ジョージ・メイソン大学がフリーソフトウェアとして作成公開しているOmekaに対して、地図年表マッピングのためのプラグインとしてヴァージニア大学図書館スカラーズラボが作成したNeatline、IIIF対応ビューワとしてアノテーションを作成できるようにとスタンフォード大学・ハーバード大学等が作成したフリーソフトMirador、それらをつないで利用者が簡単にその恩恵を受けられるようにとトロント大学図書館が作成したOmekaのプラグイン、IIIF Toolkit with Miradorという構成になっています。細かいところを見ていけば、さらに色々ありますが、いずれにしましても、北米で取り組まれてきているオープンソースの文化資料エンジニアリングの集大成とも言えるような感じになってきています。これらを作ってくださっている方々、資金提供してくださっている方々に感謝しつつ、やはりバリバリ使い込むのが最大の感謝の表現だということで、皆でどんどん使っていくのがよいだろうと思います。そこで、ぜひ、ライブラリーカフェにお越しいただいて、皆で使い込んでみつつ、持ち帰ってこれをさらに色々試していただき、デジタルアーカイブの可能性を追求する一助にしていただけたらと思っております。

IIIFの導入・運用にあたっての課題と解決方法

IIIFの導入・運用にあたっての課題と解決方法を知りたいというお話をいただきましたので、ここまでの筆者の体験について少しご紹介してみたいと思います。導入方法についてご紹介した前回の記事とあわせてご覧いただけますと幸いです。

まず、全般的な印象について、筆者の個人的な見解を書いておきます。筆者は、IIIFを導入するようになる前から、高精細画像をWeb上で公開するシステムを作ってきました。具体的には、色々検討した結果、自分でタイル画像ビューワをJavascriptで書いて提供していたことがあり、また、Open SeadragonでDeep Zoom形式のタイル画像を用いて公開したこともあります。そういう経験からしますと、IIIFの導入にあたっては留意しなければならないいくつかのポイントがありますが、それらは、高精細画像をWeb上で公開する際の課題とほぼ重なります。ですので、多くの課題は、IIIFの問題というよりは、高精細画像の公開一般についての問題と考えていたいただくのがよいのではないかと思っております。その上で、IIIFに準拠して公開した場合には様々なメリットが生じる一方、対応しない場合のデメリットの大きさも勘案するなら、対応しておかない手はないだろう、ということでみなさまにおすすめしているところです。

　そのようなことで、とりあえずここでは、筆者が自分で導入したり導入のお手伝い（いくつかの機関や企業のお手伝いもしてきております）をしたりしたなかで経験した色々な課題を、画像配信にまつわる問題、公開の在り方の問題、IIIF Manifestの問題、ビューワに関わる問題、その他諸々、といった感じにわけて、それぞれご紹介してみたいと思います。

1．画像配信にまつわる問題

やはりIIIFではこれに関わる問題が色々とあります。高精細画像の公開における課題そのものと考えていただいてよいのではないかと思いますが、とりあえず一つずつご紹介していきます。

1．1．タイル画像のサイズ

　Pyramid Tiled Tiff形式は、IIP Image Serverと併用して、比較的大きな画像を高速に配信するためによく使われています。8～10種類くらい（あるいはもっと）の縦横サイズの画像を作成し、さらに、指定した縦横サイズ以上の画像の場合には分割して（タイル化して）部分的に取り出せるようにして、それらを一つのTiffファイルにまとめたものがPyramid Tiled Tiff形式、もしくはPyramid Tiffなどと呼ばれる画像形式です。タイル化する際には、タイルの大きさをどのようにするかというのが一つのポイントになってきます。

　タイル画像のサイズの決定は、なかなか難しい問題です。「タイルに区切って配信することで、容量の大きな画像であっても見たい箇所だけを配信することができるので効率的である」と言っても、画像でもなんでも、Webで配信すると、1ファイルを配信するごとにサーバとクライアント（パソコン）の間で色々なやりとりが発生します。タイルが小さすぎると、やりとりされるタイルの数が増えて、このやりとりの回数も増えてしまうので、結果的に遅くなってしまいますし、大量の小さな画像を送信することはネットワークへの負荷もそれなりに大きくなってしまうことがあります。ですので、小さすぎないことも重要です。筆者はとりあえず256x256で作ってしまっていますが、もう一回り大きくてもいいかもしれないと思っております。たとえば、以下のサイトは512x512だったり、

https://open.library.ubc.ca/collections/tokugawa/items/1.0227946

https://iiif.library.ubc.ca/presentation/cdm.tokugawa.1-0227946/manife (IIIF manifest)

https://iiif.library.ubc.ca/image/cdm.tokugawa.1-0227946.0000/info.json (info.json)

さらに、大きな地図を公開している例では2147x1434とか2142x1756のようなサイズのタイルにしているところもあるようです。

2147x1434:

https://searchworks.stanford.edu/view/11298997

https://purl.stanford.edu/hs631zg4177/iiif/manifest (IIIF manifest)

https://stacks.stanford.edu/image/iiif/hs631zg4177%252Fhs631zg4177_00_0001/info.json (info.json)

2142x1756:

https://searchworks.stanford.edu/view/dp874jj6432

https://purl.stanford.edu/dp874jj6432/iiif/manifest (IIIF manifest)

https://stacks.stanford.edu/image/iiif/dp874jj6432%252F5763001/info.json (info.json)

　特に、現在ほとんどのWebサイトで使われているHTTP1.1では、一度に配信する数が多い場合、オーバーヘッドがとても大きくなってしまいます。大きな画像ではじからはじまでさっと移動させると、それだけで膨大な数のタイル画像の転送をサーバ側に要求することになってしまって、画像配信がものすごく遅くなってしまうことがあります。そこで、タイル画像のサイズを大きめにして、転送数を減らすという方向も十分にあり得ます。大きな画像を扱う場合には、実際にいくつかのタイルサイズを試してみるといいかもしれません。

1．2．HTTPにおけるタイル画像の大量同時配信における課題 

　詳しい技術的な解説は他のサイトに譲るとしまして、基本的に、Webで用いられているプロトコルHTTP/HTTPSは、大量のファイルを一度にサーバから送出するという使い方にはそれほど向いていません。現在広く使われているWebサーバソフト環境では、HTTP1.1が使われていることが多いですが、これは、KeepAliveの設定をOnにしておかないと、たくさんのファイルを配信するときに転送数制限に引っかかってしまって、タイル画像の読み込みが途中で止まってしまいます。たとえば、Redhat6やCentOS6のApacheでは、KeepAliveがデフォルトではOnになっていないようですので、Onにした方がよいと思います。Redhat7やCentOS7ではデフォルトでOnになっているようですので、この点は大丈夫かと思います。

　また、KeepAliveの設定をOnにしていたとしても、やはりどうしても、配信ファイル数が多くなる場合の負荷の大きさという問題は残ります。それをよりうまく解決する方法として、従来よく使われてきたHTTP1.1ではなくHTTP/2を採用するという手があります。たとえば、万暦版大蔵経デジタル版では、画像配信にHTTP/2を採用しており、それなりに速くなっているようです。ただし、現時点では、サーバ用途でよく使われるLinuxディストリビューションでは、HTTP/2は正式サポートされていないようですので、自分で対応するHTTPサーバを用意する必要があります。筆者は、HTTP/2を導入するために、OpenSSL、Apache、PHP、IIP Image server等をソースコードからコンパイルして設定しました。ですので、特に新たな費用は発生しませんでしたが、このやり方で導入してしまうとセキュリティアップデートなどがちょっと大変になってしまうので、企業発注の場合にも、導入コストだけでなくメンテナンスコストもやや高く見積もられてしまう可能性があります。ですので、HTTP/2に関しては、広くサーバ用途で使われるLinuxディストリビューションが対応するまで待った方がいいかもしれません。

1．3．画像配信サーバソフトのインストール

　画像配信サーバソフトのインストールは、作業自体はそれほど難しくはありません。いくつかの解説サイトを見て手順通りに作業すれば大丈夫です。ただし、(1) PythonかrubyのCGI的なものを動してよいか、(2) C++のソフトをCGIとして動かしてよいか、(3) Tomcatサーバを動かしてよいか、といった点について、サーバ運用に関する全体のポリシーとのすりあわせを行う必要があります。いずれもダメということになった場合には、IIIF Image API を導入することはやや難しくなります。この点は、たとえばOpen Seadragonの Deep Zoom形式であれば、画像配信用サーバソフトがなくてもタイル化されたJpeg画像を所定のWebディレクトリに置いておくだけで利用可能であることに比べると、状況によっては割と大きな障壁となる場合があります。また、運用ポリシーとの整合の問題は大変重要ですが、費用面に関しても、導入費用だけでなく保守費用も高くなる可能性が念頭に入れておく必要があります。また、言い方を変えると、画像配信サーバソフトのインストールがネットワーク・サーバの運用ポリシーに抵触しないのであれば、導入自体は容易であると言うこともできます。

1．4．タイル画像化する場合のストレージの容量

　ある程度大きな画像を配信しようとする場合や、負荷がかなり大きくなることが想定される場合には、画像を事前にタイル化しておく方が利便性を下げずに済みます。タイル画像化については、現状ではPyramid Tiled Tiff（あるいはPyramid Tiff）が一般的であるように思われます。Pyramid Tiled Tiff形式を作成する場合、お手元の状況にもよると思いますが、TiffやJpeg等の画像ファイルをPyramid Tiled Tiffに変換することになると思います。この変換の際には、ImagemagickやVIPSといったフリーソフトが利用できます。いずれかのフリーソフトを用いることで、「フルサイズ画像に加えて、8～10段階程度（あるいはもっと多い場合・少ない場合もあります）の画像を作成しつつ、一定サイズ以上のものはタイル状に分割して、それらをまとめて一つのTIFF画像を作成する」という一連の操作がコマンド一つでできます。このようにして作成したPyramid Tiled Tiff画像をIIP Image Server等から読み込み・配信できるようにしておけば、クライアント側からのアクセス要求にあわせて近いサイズの画像を取り出して配信するととともに、一定サイズ以上のものはタイル状に分割して、クライアントから要求された場所のタイルを取り出して配信するということになり、サーバソフトでの処理の負荷を大幅に軽減することができ、結果的に、大きい画像であればあるほど、アクセスを高速化することができます。

　この変換作業にあたっては、簡単なスクリプトで繰り返し処理をすれば、大量の画像でもあまり手間をかけずに処理することができます。ただ、人の手間はあまりかからないのですが、この画像処理自体に結構時間がかかりますので、計画的に進めることが重要になってきます。

　また、Pyramid Tiled Tiffに変換すると、複数サイズの画像を作成するということになりますので、どうしてもファイルサイズが大きくなってしまいます。大きなストレージを用意することができるのであれば、それが一番楽ですが、そういうわけにもいかない場合もあるでしょう。そのためには、画像容量がなるべく大きくならないように、Pyramid Tiled Tiffにする際に画像の圧縮率を上げてしまうという方法があります。圧縮率を多少上げても、人が見る際にはそれほど問題がない場合もあるので、色々試してみた上で変換時の圧縮率を決めるとよいかもしれません。

1．5．画像へのアクセス速度をあげるための工夫: IIP Image ServerのMemcached

　IIP Image Server限定ですが、アクセス速度をあげるためにMemcachedを利用することができます。クライアント側からリクエストされた画像をそのままキャッシュして、同じリクエストがきたらそれを返すということになり、アクセスごとに画像変換を行う処理を回避できることになります。よくアクセスされるサムネイル画像群や、皆がよく見る画像、授業や会合等で皆がほぼ同時にアクセスする画像等がキャッシングされることになれば、画像配信サーバの負荷が劇的に下がることが期待できます。筆者の関係しているサイトでも一部でこれを利用しております。

2．他の機関に画像を持って行かれるようにみえる／公開機関の存在感がなくなる

　この問題については、こちらの論考 http://researchmap.jp/?action=cv_download_main&upload_id=125135 のp. 65の「IIIFの導入に伴う公開の在り方の変化」という節をご覧ください。それに筆者の考えをもう少し付け加えると、基本的には、「デジタルアーカイブ」の利活用を広げ、デジタル時代の知識流通基盤を確かなものにしていくためにはIIIFのような利用のされ方が必要にならざるを得ず、しかもそのためには、各「デジタルアーカイブ」で共通のルールが用いられる必要があることから、現時点では、高精細画像を共有する機能に関してはIIIFの仕様を採用していくことが最良の選択肢であると思っております。

　また、IIIFの仕様としては、権利所有者についての情報とライセンス情報を書くというルールになっており、各対応ビューワはそれを表示するようになっています。

　なお、Image API単独での利用を考慮して、画像毎にライセンス情報を付与できる仕様もImage APIには用意されていますが、（http://iiif.io/api/image/2.1/#rights-and-licensing-properties）これを何らかの形で実装している例にはまだ気づいたことがありません。もしどなたかご存じでしたらぜひご教示ください。

 3．IIIF Manifestファイルに関して

　IIIF Manifestファイルを作成した時には、IIIF Validator http://iiif.io/api/presentation/validator/service/ にて整合性チェックをしてみましょう。最低限、これでエラーが出なくなるまではきちんと修正する必要がありますが、エラーが出た場合に、どこがエラーなのかわからないことがあります。その場合には、別のJSONバリデータを使うことで確認できることがあります。JSONバリデータは、ググるとたくさん出てきますので、ここだけでわからない時は、他のものを探していくつか試してみるとよいかもしれません。ちなみに筆者は、oXygen XML EditorがJSONにも対応してバリデータの機能も持っているので、基本的にはこれを使っています。テストパターン作成もこれで行っています。

　IIIF Manifestファイルに目次情報を入れたりするとだんだんファイルが巨大になっていってしまいます。ビューワ側としては基本的にはIIIF Manifestファイルを全部読み込んでから次のプロセスに移るものが多いようですので、IIIF Manifestファイルが巨大になると、配信に時間がかかって、その分、画像が開くのが遅くなります。そこで、Webサーバ側でJSONファイル配信時にgzip圧縮をかける設定をすると、そこのボトルネックがかなり解消されます。体感的には結構速くなりました。たとえばApacheの場合には、mod_deflateで.jsonに圧縮がかかるようにすればいいようです。

　IIIF Manifestでは、@idごとにURIを作成することになりますが、重複しないように注意してください。それから、作成したURIごとに対応するJSONファイルを作成した方がよいので、それも頑張ってください。筆者の場合、最初はやってませんでしたが、途中からなるべく作成するようにしております。（しかし、canvasなど、直接アクセスされやすそうなものだけで、まだ全部作成しているわけではありませんので、これは筆者自身の課題でもあります。）

4．IIIF対応ビューワに関して

　IIIF対応ビューワには、Universal Viewer、Miradorというメジャーなもの以外にも、Leaflet-IIIFやOpen Seadragonなど、カスタマイズすることで色々な形で使える、自由度は高いが開発力を要求するタイプのものがありますが、簡便に導入できる便利なものを採用したければやはりUniversal ViewerかMiradorということになります。Universal Viewerに比べて、Miradorの場合には、サムネイル画像を横に並べてページをめくっていける機能があり、サムネイル画像を多く表示できる分、使いやすい面があるのですが、当初は、IIIF ManifestではviewingDirectionとしてright-to-leftという値が用意されているにも関わらずMiradorではそれに対応していませんでした。日本語や中国語の縦書き資料でページめくりやサムネイル画像のリストが左から右になってしまっていることに関しては、結構な数の利用者から使いにくいというクレームがあっただけでなく、自分自身としても、あまりにも使いにくかったので、オープンソースとして開発されているMiradorのソースコードを見て、自分でコードを追加して、viewingDirectionがright-to-leftになっている時だけはそれに対応したページめくり方向・サムネイル画像の並び方向になるようにしました。自分のところではそれを使えばよかったのですが、日本の他機関にも使ってもらうといいのではないかと持ちかけたところ、本家で対応していないとだめだということを言われたので、本家のソースコードに反映してもらえるように交渉をしました。ソースコードを提供してからやや時間がかかり、本家が何度かバージョンアップしてそのたびにこちらの追加コードを書き直すことになったりしましたが、ようやくバージョン2.6.0で正式に取り込まれた、ということがありました。いずれにしても、オープンソースプロジェクトなので、こちらが必要な機能をこちらで開発してコードを提供すれば、グローバルな機能の一つとして取り込んでもらうことは可能なようです。

5．HTTPS問題

　近年、認証を必要とするシステムでは、HTTPSに対応することが求められるようになってきています。そして、IIIFが依拠する仕組みでは、HTTPSのサイトにIIIFコンテンツを読み込ませようとすると、IIIFコンテンツもHTTPS対応していなければなりません。これは、Webブラウザの仕様による制限であって、IIIFの問題ではありません。が、とにかく、HTTPで公開しているコンテンツは、一般的なWebコラボレーションシステム（＝HTTPSで運用されていることが多い）のようなものでは取り込めなくなってしまうことが多いです。ですので、IIIFコンテンツをHTTPS で公開することは必須になりつつあります。そして、そのためにはSSLの証明書が必要になります。これは、どこか信頼できるところから取得する必要があり、しばらく前までは、そのためにそれなりの費用を支出する必要がありました。しかし、最近は、Let’s encryptというフリーのSSL証明書取得サービスが始まったので、一応、これを利用してHTTPS対応するという選択肢が出てきました。このサービスでは、証明書の利用期間が短く、数ヶ月ごとに証明書を更新する必要がありますが、導入・更新のためのスクリプトが用意されていて、コマンド一発でできるようになっています。ですので、とりあえずはこれを利用しておくという手もあろうかと思います。

6．仕様のアップデートの問題

　筆者が開催しているIIIF講習会ではいつも強調していることの一つであり、かつ、IIIFに限ったことではなく、「デジタルアーカイブ」全般において避けて通れない重要な課題なのですが、IIIFのAPIの仕様はそれなりの頻度でアップデートされます。ですので、アップデートされた場合には、適切な速度でうまくついていけるような体制とシステムにしておく必要があります。HTMLの例で考えていただけばよいと思いますが、5年くらいはまあなんとか大丈夫ですが、10年経つと互換性がちょっとあやしくなることがある、というような感じでしょうか。もちろん、ビューワ側で旧バージョンにも対応し続けてくれれば問題ないのですが、ビューワ開発のマンパワーは無尽蔵ではないので、新バージョンでできる新しく意義深いことが優先されるようになってしまうと、旧バージョン対応がちょっと厳しくなることもあるでしょう。

　一方で、IIIFのAPIの仕様がアップデートされても、ビューワやサーバソフトなどの環境がすぐに対応できるわけではないので、アップデートに即応する必要はありません。たとえば、筆者が関わり始めたときはImage APIとPresentation APIがどちらもバージョン1からバージョン2に移行する時期で、使っているソフトがバージョン2にうまく対応できているかどうかの確認ができず、ものによって対応しているようであるものとそうではなさそうなものがあるようで、よくわからずに少々混乱しました。それでも、2016年の3月くらいには、バージョン2に対応するソフトがかなり安定してきたようだったので、本格的な導入に向けて作業を始めたのでした。また、バージョン2はそれなりの使い勝手を提供できており、それなりに安定しているようでもありましたので、海外有力機関が続々採用し始めていたこともあり、皆様にも広めようと思うに至ったのでした。

　そのような感じですので、あまり無理して最新のAPI仕様についていく必要はないのですが、さりとて、ずっと古いままで、いずれビューワやその他の関連ツールや関連環境などが対応できなくなってしまうと本末転倒な感じになってしまいますので、やはり、どこかの時点でアップデートに対応できる体制とシステムはあった方がいいように思われます。

まだまだ色々あるような気がしますが、とりあえずここまでとしたいと思います。上記の情報は、記憶に頼って書いている部分が多く、正確でないところがあるかもしれませんので、くれぐれもご注意ください。何か、気がついたことがございましたらぜひお知らせください。

IIIFの導入方法のまとめ（コンテンツホルダー・一次公開者向け）

IIIFの導入の仕方がよくわからない、という声を結構あちこちで聞きます。ブログ記事として断片的に書いてきているのですが、それをいちいち探して読んでいただくのも大変ですので、改めて簡潔に記しておきます。ただし、既存のサーバ環境やサーバ・ネットワーク運用ポリシーによってできることは結構違ってくることがありますので、その点はよくご注意ください。

　それから、IIIFの場合、「導入」と言っても、コンテンツホルダーや一次公開者向けの「導入」とは別に、既存の公開IIIFコンテンツを素材とする二次利用公開という観点での「導入」があります。これは今までは「利活用」と呼ばれてきたものだと思いますが、たとえば地図年表上に他所のIIIFコンテンツをマッピングできるシステムの例などをみますと、もはや「導入」と言ってしまってもいいような雰囲気があるように思っております。が、ここでは、あくまでも、一次公開者向けの導入方法の解説ということになっておりますので御承知置きください。

IIIF Image APIへの対応

画像配信サーバマシンの選定：メモリはある程度大きい方がいいです。国デコImage Wallは8GB、SAT大正蔵図像DBは32GB、万暦版大蔵経デジタル版は96GBです。それから、ディスクアクセスは速ければ速いほどよいですが、体感ですと、画像1枚あたり50MBくらいまではNASでも大差ありません。100MB超えると、NASではちょっときつくなります。

• 画像を用意する。
  • 画像は、筆者の体験では、2MB以内ならJpegそのままでも問題なし。2MBを超えるなら、Pyramid Tiled Tiffに変換する（フリーソフトで対応可能：Pyramid TIled Tiffへの変換の仕方）か、JPEG2000を利用（こちらは色々お金がかかるが、すでにライセンスを購入していればそのまま使ってください）するのがいいような気がします。ただし、これもネットワークやハードウェアの環境によって違ってくることがあると思いますので、ご自身の環境でも試してみてください。
• 画像のサイズや想定アクセス数にあわせて画像配信サーバソフトを選択する。
  • 画像が小さくてJpegのままでいくならLoris、digilibなどを選ぶこともできます。LorisはPythonで、digitlibはJAVA/Tomcatで動きます。筆者はフォローしておりませんが、Rubyで動くものもあります。Pyramid Tiled Tiffの場合は高速なIIP Image Serverも利用可能です。導入方法は、たとえば下記の記事をご覧ください。
  • Loris IIIF Image Server on Ubuntu 16.04 (2SC1815J氏による)
  • Digilib導入方法
  • IIIPImage Server導入方法（再掲）
  • それから、Dspaceなど、対応プラグインが用意されているものもありますので、既存環境のIIIF対応についても確認してみてください。

• 画像配信サーバソフトを、画像が置いてあるディレクトリにアクセス権を持っているサーバにインストールする。

インストールは、選んだソフトによってやり方が変わります。サーバの設定や運用ポリシーによってはインストールができない場合もありますのでご注意ください。それぞれの配信サーバソフトのインストール方法については、それぞれ紹介記事がありますのでご確認ください。

• CORSの設定をする。

HTTPヘッダのAccess-Control-Allow-Originの値が*になるようにサーバの設定をする必要があります。サーバの設定ファイルに書くことになる場合が多いと思いますが、.htaccessに書くだけで対応できることもあります。この件については、ググるとたくさん情報がでてきますのでそちらにお任せします。

• 動作確認をする。

IIIF Image APIに準拠してアクセスできているかどうか、確認をしましょう。これは上記のインストール方法紹介記事に確認方法も書いてあるはずです。

IIIF Image APIの導入、つまり、画像そのものの配信については以上です。

次に、Presentation APIへの対応についてみてみましょう。

IIIF Presentation APIへの対応

「デジタルアーカイブ」が自らのデジタル画像を公開するためにPresentation APIに対応するということは、IIIFマニフェストと呼ばれる、「資料」単位でのJSON-LDファイルを作成して公開するということです。これは、動的である必要はなく、JSON-LDファイルを作ったら、あとはWebディレクトリに置いておくだけで大丈夫です。「資料」単位ですので、その資料に含まれる画像のIIIF Image APIによるURL群を適切な順番で記述しておくということになります。では、もう少し詳しく、順を追ってみてみましょう。

1. 画像の縦横ピクセルサイズの情報、画像のURL、その他、画像や画像のまとまりとしての資料の各種メタデータを確認する。
   • 画像の縦横ピクセルサイズはプログラムで取得できますので、いちいち手作業をしようとは考えないでください。各種メタデータはなるべく詳しい方がいいです。
2. それらのデータを用いて、資料単位でPresentation APIが支持する形式に準拠したJSON-LDファイルを作成する。
   • 前項で用意したデータを一つのJSON-LDファイルにまとめるのですが、大抵のプログラムでは、データを読み込んで配列やオブジェクトなどに格納しておけば、あとはそれをJSON形式に変換してしまう関数があったりしますので、いちいち{}などを書こうとしないで、配列等から変換するようにした方が整合性チェックの手間が省けて楽だと思います。
   • 全体的な内容については、神崎正英氏による解説が参考になると思いますのでぜひご覧ください。
   • 画像上に付与したアノテーション（注釈）に関しては、別ファイルを作成してそれを参照するように書くのが現状ではいいように思われます。たとえばSAT大正蔵図像DBのIIIFマニフェストとアノテーションがご参考になるかもしれません。また、詳しい解説が神崎正英氏のサイトにもありますので、こちらもぜひご覧ください。
   • 目次も作成できますが、結構冗長になりますので、この場合、ファイル送信時にgzip圧縮をかけたりした方がいいかもしれません。（これについてはこのブログの次の記事をご参照ください）。たとえば、万暦版大蔵経デジタル版のIIIFマニフェストの下の方のsc:Rangeのところをご覧ください。
3. 作成したJSON-LDファイルを適切なディレクトリ（当該ファイル内で@idとして設定したパスになるように）に置く。それと、このファイル（が置いてあるディレクトリ）は、Image APIと同様に、Access-Control-Allow-Originの値が*になっている必要があります。
   • 繰り返しになりますが、単にファイルを置いておくだけでも大丈夫です。

このようにして作成・設置されたIIIFマニフェストのURLがあれば、好きなビューワ、あるいは各地のビューワに読み込んでもらって閲覧してもらうということが可能になります。

ビューワの設置

IIIFに対応して公開するという場合には、上記のような手順を経て、IIIFマニフェストのURLを公開すれば、それで十分です。しかし、組織・機関として公開する場合、ビューワ上で見えるようになっていないと十分に成果として認められない場合があります。そこで、IIIF対応ビューワを自分のサイトに設置することになります。ビューワとしては、よく用いられるのはフリーソフトのUniversal ViewerとMiradorで、それぞれに様々特徴があります。それに加えて、EuropeanaやIIIF Curation Viewerで採用されているLeafletというビューワもあります。それぞれよく比較してみて、目的にあったものを設置するという手もありますし、好きなビューワを閲覧者が選べるようにするという方法もあります。

IIIF対応ビューワに関しては、筆者が書いてきたブログ記事などに色々情報がありますので、そちらもご参考になりましたら幸いです。

終わりに：検索と認証

メタデータやタグ等を検索できるようにしたければ、また別途色々工夫する必要がありますが、その観点からすると、現状では既存のデジタルアーカイブシステムの検索システムを用いつつ、おまけとしてImage APIに対応しつつJSONファイルも用意しておくというGallica（フランス国立図書館）の手法が採用しやすいように思われます。ただ、検索システムを別途一から用意しようという場合は、IIIF Search APIというのがありますので、それに準拠する形で用意するといいかもしれません。

それから、認証をかけてアクセス制限をしたいという場合には、Authentication APIというのもありますので、オープンにすることが運用上不可能なコンテンツの場合にはご検討いただくとよいかもしれません。

以上、お役に立ちましたら幸いです。

世界各地の高精細画像で簡単に自分の仮想コレクションを！（IIIF Curation Viewer）

いよいよ、出ました。

IIIF Curation Viewer | 人文学オープンデータ共同利用センター

の重要なアップデートです。

一言で言うなら、

「世界各地の高精細画像で簡単に自分の仮想コレクションを作れるようになりました」

これは、IIIFが目指す世界における重要なマイルストーンの一つなのですが、それが、とてもスマートなインターフェイスで実現されたということに、感動しているところです。

すでに、公式サイトにもいくつかデモがありますが、私もさっそくやってみました。というより、やってみた結果、そのインターフェイスのスマートさに感動しているところです。

　作ってみたものは、特にスマートでもなんでもないのですが、魚の顔を少し集めてみました。国会図書館と国文学研究資料館から。つまり、複数の別々の機関のサイトから公開されている画像が、このようにして、一つのビューワ上で一元的に操作できて、その成果も比較的簡単に公開できる、ということになってしまいました。

さて、具体的にどういう風にやってみたのか、みてみましょう。（近いうちに公式サイトからもきちんとしたマニュアルが出ると思いますのでこちらは速報私家版として）、まずはデモ用ビューワにアクセスしてみます。

ここに、例の、IIIFアイコンのドラッグ＆ドロップをしろ、ということのようです。そこで、IIIFアイコンを探すのですが、こういう時に簡単なのは国デコImage Wallです。アクセスすると、いきなり画像がずらっと表示されます。これは、国立国会図書館デジタルコレクションから、デジタル化資料中の挿絵や図だけを取り出してサムネイル画像をリストしてくれるものです。そして、ここでリストされている画像を含むデジタル化資料は、その資料全体がIIIF対応になっています。ステマと思われると困るので書いておきますが、国デコImage Wallのシステムは私が作っていてIIIF対応作業も私が（書いたスクリプトで私が）行っています。

そこで、Webブラウザで新規にタブを開いてから、たとえば、「魚」で検索すると以下のような感じになります。スライダを動かすと刊行年での絞り込みもできます。

気に入ったサムネイル画像をみつけたらクリックしてみます。そうすると、以下のように、その画像をもう少し拡大した画像と、IIIFアイコンや、その他いくつかの関連情報がでてきます。しかし、新規にタブを開いた人は、ここでは迷わず、このIIIFアイコンをドラッグして、Curation Viewerのタブに持って行って、タブが切り替わったら、Dropすべき場所にアイコンをDropします。

そうすると、以下のように、その資料の最初のページが開きます。

ここで、左上にある「サムネイル一覧」ボタンをクリックすると、以下のように、サムネイル画像を一覧できますので、気に入った画像をクリックしてみましょう。

そうすると、以下のように、その画像のみが拡大表示されます。ここで、右側の黒い四角いアイコンをクリックすると、範囲選択ができるようになります。

範囲選択をした後、右上にある白抜きの☆印をクリックすると・・・

以下のように、☆が青くなります。（あるいは、白抜きだったものが塗りつぶされます★）。これで、一つの「キュレーション」ができました。

ここで、右上の「キュレーションリストを表示」というポップアップがついているアイコンをクリックすると、以下のように、キュレーションリストの最後に、今切り出した画像が入っていることが確認できます。なお、ここでは、すでにいくつか切り出しを行ってしまっていたので、その最後に追記された形になっています。

これだけでは物足りないので、次に、またWebブラウザで新しいタブを開いて、今度は国文学研究資料館の新日本古典籍総合データベースに行ってみましょう。このデータベースは、おそらく現在、日本古典籍のIIIF対応画像数では最大ではないかと思います。なかなか贅沢な環境ですが、ここで、「魚」で検索すると、以下のような資料がみつかりました。

当然、ここでも、IIIFアイコンがありますので、先ほどと同じようにこれをドラッグ＆ドロップすると以下のようになります。

そこで、以下のように、切り出しをして、また同様に、☆アイコンをクリックして「キュレーションリスト」に追加します。

ここで、キュレーションリストを表示させてみると以下のようになりますが、この画面では、これらのサムネイル画像をドラッグすることで順番の変更ができるようになっています。

たとえば、今、最後に追加したサムネイル画像をドラッグして、以下のように、一番最初に持って行ってみます。そして、以下の画面に見えている「エクスポート」ボタンをクリックしてみましょう。そうすると・・・

以下のようにして、今、追加した画像のうち、矩形領域で指定した箇所が拡大される形で、選んだ画像がキュレーションリストの順番で表示されていきます。

という感じで、とても簡単に、「各地の画像を集めた仮想コレクション（と私は仮に勝手にそう読んでいます）ができるようになってしまいました。もう一つ、各地の画像を集めた仮想コレクションを作れるシステムとして、IIIF Toolkit with MiradorというOmekaのプラグインがあるのですが、あちらが注釈（アノテーション）の付加や地図年表上のマッピング、作業担当者の認証制御までできてしまう代わりにサーバシステムが必要であるという重さを背負っているのに対して、Curation Viewerは、とにかく軽量で、用意すべきものもほとんどありませんし、操作性もよく考えられているように思われます。今後も、この調子で、シンプルなままで機能を拡張していっていただけたらと思っているところです。

もう一つ特筆すべき点として、このCuration Viewerは、広く用いられているIIIF対応ビューワであるMiradorやUniversal Viewerではなく、Leafletというビューワをベースとして使っています。LeafletのIIIF対応版というのが開発公開されているのですが（これの開発者のJack Reedさんは来週、来日して講演やワークショップ参加をしてくださいます）、さらにその先を行くものであるように見受けられます。Leafletベースという点は、他の有名ビューワがいずれもOpen Seadragonをベースにしていることに鑑みると、IIIFの世界に多様性を確保するという点でまず重要ですが、シンプルで使いやすいインターフェイスであるということもその存在意義を高めているように思われます。

ということで、簡単な紹介になってしまいましたが、IIIF Curation Viewerの重要なアップデートをお祝いしつつ、作成者の方々に感謝しつつ、今後のさらなるデジタルアーカイブの発展の礎ができあがりつつあることを目の当たりしている実感とともに、とりあえず筆を置きたいと思います。

Miradorの正式版 (2.6.0) に、右⇒左ページめくりが実装されます

IIIF対応ビューワの代表格の一つ、Miradorが、2.6.0にて、ようやく、右⇒左ページめくりを実装することになったようです。以下のページでアナウンスされています。

Releases · ProjectMirador/mirador · GitHub

このページから、ビューワもダウンロードできるようになっておりますので、もしよかったら、.zipか.tar.gzファイルをダウンロード＆展開して、お手元のパソコンで開いてみてください。

Miradorでは、通常のページめくりは左⇒右です。しかし、日本語資料を扱う方々からは、そのページめくりだと使いにくい、という話をたくさんいただいており、私としても使いにくいのでなんとかしなければと思っておりました。そこで、自分で機能追加のコードを書いて本家に取り込んでもらえるようにとずっとお願いしていたものが、ようやく正式に取り込んでもらえることになりました。対応してくださった、Mirador開発者のDrew Winget氏をはじめ、関係者のみなさまにはたいへん感謝いたしております。

　この機能は、資料の情報に、「右⇒左ページめくりである」という情報を組み込んでおけば、それにあわせてページめくり方向を変えてくれるものです。もう少し細かく説明しますと、IIIF manifestファイル中でviewingDirectionの値としてright-to-leftと書いておくと、それを読み込んで、ページめくりの方向を右⇒左にしてくれます。一応、例をこちらにも用意しておきましたが、同じことを皆様のパソコン上でもできますので、ぜひ、ダウンロードしてお試ししてみてください。

具体的な使い方

　このビューワのサンプルの使い方をもう少し具体的に御説明しておきますと、ダウンロードした圧縮ファイルを元に戻すと、中にexample.htmlというファイルがあります。これをWebブラウザで開くと、以下のようなページが開きます。

（図1）

ここで、「＋」をクリックすると、以下のような画面になります。サムネイル画像がどんどん読み込まれていきますが、ちょっと時間がかかりますのでしばし待ってみてください。

（図2）

サムネイル画像の読み込みが終わったら、このリストの中から「唐糸草紙」を探し出して、そのサムネイルをクリックしてみてください。

（図3）

そうすると、以下のように、唐糸草紙が開きます。画面下部のサムネイル画像が右から左の順番に並んでいること、ページめくりの矢印をクリックすると読んでいく方向にページがめくられていくことを確認してみてください。これが、その右⇒左ページめくりです。同様にして、唐糸草紙以外の本を開いてみると、ほとんどは、左⇒右ページめくりになっていると思います。それもよかったら試してみてください。

（図4）

なお、この右⇒左ページめくりは、IIIF Manifestにその旨を上述のように記載したものでなければ対応できません。今のところ、比較的大きめのコレクションとしては、新日本古典籍総合データベースの数万件の IIIF manifestがこれをきちんと記述しております。たとえば、以下のIIIF Manifestを読み込ませれば右⇒左ページめくりになってくれます。

http://kotenseki.nijl.ac.jp/biblio/200021974/manifest

あるいは、やや手前味噌で恐縮ですが、東京大学附属図書館万暦版大蔵経デジタル版もこれに対応しています。これも、規模としては上記のデータベースほどではありませんが、19万枚ほどの画像を公開しています。

https://dzkimgs.l.u-tokyo.ac.jp/kakouzou/042_1/manifest3.json

それから、規模はやや小さいですが、中野区立図書館デジタルアーカイブも右⇒左ページめくりがきちんと表示されるようです。

http://archive.nakano-library.jp/manifest/807509464_manifest.json

※これらのURLはIIIF maniefstファイルで、資料画像そのものを表示してくれるものではありません。これらが指し示す資料画像をビューワに表示させるには、画面左上の「スロット数の変更」というアイコンにカーソルをあわせるとサブメニューがでますので、そのなかで「新しいオブジェクト」をクリックします。そうすると、上の「図3」のような画面になります。そこで、表示したいURL（たとえば上記のIIIF manifestのURLのいずれか）を画面右上の「URLで新規オブジェクト追加」の欄にコピペして、「読み込み」ボタンをクリックしてください。そうすると、そのIIIF manifestの対象となる資料のサムネイル画像が表示されます。そうしましたら、そのサムネイル画像をクリックすると、表示されます。

次の課題としてのアノテーション縦書き表示

　そのようなことで、ようやく、日本語資料のデジタルアーカイブで普通にできていたことが、また一つ、IIIF対応でも普通にできるようになりました。そこで次の課題として気になってくるのは、アノテーションが縦書き表示できないのか、という件です。たとえば、上の唐糸草紙の例では、「図4」画面左上の赤く囲ってあるアイコンをクリックしていただくと、アノテーションとして付与された翻刻テクストが表示されるようになっています。しかし、この翻刻テクストは、下記のように、横書きになってしまっています。

これは、この場合、縦書きになってくれないと少々不便です。もちろん、HTML5では縦書き表示に割と簡単に対応できますし、Miradorをちょっとカスタマイズすれば縦書き表示は割と簡単に実現できます。しかしながら、汎用ビューワで縦書き表示ができれば、その方が明らかに有益です。これをどういう風に実装すべきか、というのは慎重な議論が必要であり、すくなくとも、右⇒左表示のように、縦書きであることの宣言をIIIF Manifestの中に入れてしまってよいのかどうか、ということも慎重に検討する必要がありますが（筆者としては、今のところ、個々のアノテーションにそれぞれ縦書き表示のタグを入れることでなんとか対応できないかと思っているところです）、次は、どなたか他の人がこれに取り組んでくださるとありがたい、と思っております。多少のお手伝いはいたしますので、どうかよろしくお願いいたします。

京大附属図書館IIIF対応と新日本古典籍総合データベースの右⇒左対応

ついに、待ちに待っていた京都大学附属図書館からのIIIF対応デジタルコレクションが公開されたようです。「京大貴重資料デジタルアーカイブ」だそうです。素晴らしいことです。

　京都大学附属図書館は、東京大学大学院人文社会系研究科人文情報学拠点に続いて、日本からIIIFコンソーシアムに加盟した、まだ日本には2つしかない組織の一つであり、筆者としては、ここからのIIIF対応コンテンツの公開を心待ちにしていたのでした。多様な資料がIIIF対応で公開されていて、見ているとなかなか楽しいものですね。私の好きな南瞻部洲万国掌菓之図も公開されていて、ちょっとテンションがあがります。コンテンツの豊富さもさることながら、公開に際しては、MiradorとUniversal Viewerという、IIIF対応の二大ビューワのどちらにも対応している上にIIIF Dropアイコンも用意してらっしゃるので、至れり尽くせりの対応ですね。

さて、さっそく、他機関の画像とも対比してみようかと、こちらの宇津保物語を国文学研究資料館の新日本古典籍総合データベースの宇津保物語をちょっと並べてみました。

なかなかいい感じですね。ただ、ちょっと右側が暗めなので、Miradorの画像表示調節機能を使ってちょこっと明るくしてみますと・・・

本来、こういう風にあまり輝度や彩度をいじるのはあまり好ましいことではないのですが、一応、こういう風にして見やすくすることもできます。

さて、ここで使っているビューワは、先月末に公開された東京大学総合図書館万暦版大蔵経（嘉興蔵）デジタル版のMiradorです。すでにIIIFについてよくご存じの方や、このブログをずっと読んできてくださった方、私のIIIF講習会に参加された方々はよくご存じかと思いますが、IIIF対応で公開された画像は、IIIF対応ビューワなら、どこでも表示できてしまいます。自分の好みの機能を持ったビューワに、外の見たい画像を読み込ませることができるのです。

　ここで表示しているMiradorは、私が改良したもので、ページめくり方向を、日本の縦書き資料にあわせて右から左にめくっていったり、サムネイル画像を右から左に並べたりすることができます。ただし、それにあたっては、IIIF Presentation APIに規定されている表示方向の設定を記述しておく必要があります。viewingDirecitionというパラメータがありますので、それをright-to-leftとしておくと、そのパラメータを読み込んで右⇒左のページめくり等に対応するようになっています。西洋の資料や横書き資料はleft-to-rightとしておけば左から右にページめくりできます。

　このビューワに読み込ませたのは、日本の縦書き資料なので右から左に読んでいきたい、ということなのですが、新日本古典籍総合データベースの方は、きちんと右から左に読んでいくことができました。このIIIF マニフェストファイルを見てみると、"viewingDirection":"right-to-left"となっているのが確認できました。この仕事は国文学研究資料館のプロジェクト「日本語の歴史的典籍の国際共同研究ネットワーク構築計画」によるもので、システム構築はインフォコム株式会社が行っているようです。新日本古典籍総合データベース自身が実装しているビューワでは右から左へのページめくりにはまだ対応していないようですが、IIIF マニフェストファイルを先行してきちんと対応させておくことにより、上記のような形で、対応可能なビューワを誰かが用意できればきちんと表示されるようになります。いわば、潜在的な可用性を高めることにつながることです。もちろん、日本語縦書き資料を右から左に読んでいけることは、IIIFの日本や東アジアでの普及にとってはとても大事なことですので、その点だけをもってしても価値があるのですが、このように、今はできなくてもいつか誰かが活用してくれるかもしれない情報を、コストに見合う範囲できちんと残していくという姿勢は、デジタルアーカイブを持続的に発展させていく上で大切なことですので、個別に見ると小さなことですが、こういう姿勢は忘れないようにしていきたいものです。

　さて、新日本古典籍総合データベースの話が出てきましたので、もう少し、今度は万暦版大蔵経デジタル版との対比もしてみましょう。基本的に、漢文の仏典ということになりますので、同じものの異なる版、というのが東アジア全域にわたって様々に残されてきています。たとえば、以下のような感じです。

さらに、万暦版大蔵経デジタル版は、ビューワをもう少しカスタマイズしていまして、目次欄の「SAT DB」という箇所をクリックすると、対応するテキストデータが画面右側に縦書きで表示されるようになっています。たとえば以下のような感じです。

テキストデータは、大正新脩大藏經の全文テキストデータベースであるSAT大蔵経テキストデータベースから引っ張ってきておりますので、異読を含む脚注もあります。異読のうち「明」と注記されているものは万暦版大蔵経ですので、ほぼそのままデジタル画像と対応します。たとえば以下のような感じです。

このようにして見比べていくと、やはり右から左にページをめくっていけるようになっていないと操作性の面ではなかなか厳しいものがあります。全体として、右から左へのページめくりはなんとか対応していきたいところですが・・・

　先日、ハーバードの燕京図書館の中国古典籍コレクションのIIIF対応画像のなかにも万暦版大蔵経が一部含まれていることに気がついたので、比較できるビューを作ってみました。たとえば以下のような感じです。

このビューは、たとえばこちらにアクセスしていただいて、目次欄の「SAT DB」をクリックしていただくと、テキストデータの下に「Harvard」と注記されたIIIF Dropアイコンが表示されます。そこで、ウインドウを一つ増やして、そこにこのHarvardのIIIF Dropアイコンをドラッグ＆ドロップしていただくと、対応するページ（キャンバス）が表示されるようにしてみています。

　万暦版大蔵経デジタル版の今後の課題の一つとしては、このアイコンを増やしていくことが重要であると考えておりますが、それはともかく、

　このHarvardのものを表示してみたところ、viewingDirectionがleft-to-rightになっていることに気がつきました。いくつか見てみたところ、大体そういう感じになっているようでしたので、さっそく、HarvardのIIIF担当者に連絡をとってみたのでした。ところが、中で議論したところ、右方向か左方向かというフラグがないのでうかつに変更ができない、という話になってしまったようで、残念ながらとりあえずお蔵入りとなってしまいました。中国古典籍だとほとんど右⇒左なのではないか、とは主張してみたのですが、残念ながら反応は今ひとつでした。

　実は、京大附属図書館のIIIF manifestも、上記のように表示してみたらページめくりが左⇒右となっていて、IIIF manifestを見てみたらviewingDirectionがないので、あれれ？と思ったのですが（viewingDirectionのパラメータはSHOULDと規定されているので、なくても一応大丈夫です）、京大附属図書館のIIIFコンテンツの場合、右方向と左方向の資料が混在しているようにも思えますので、この場合、仕分けが結構難しくてちょっとやむを得ない状況なのかもしれない、と思ったところでした。まだ試験公開版とのことですので、本公開までに、余力があったらご対応いただけるとありがたいところです。

　ちなみに、外から見ているだけなので実際の仕組みがどうなっているのかわからないのですが、国デコ（国立国会図書館デジタルコレクション）では、サムネイル画像の一覧表示に際して、古典籍系は右から左、近デジ由来のものは左から右、という風にしているようにも見えました。きちんとフラグをつけてくれているといいなと思いつつ、しかし、数十万点もあるので、もし、今、フラグをつけていないのなら、もうそのままにしておいてもらいたいような気もしました。今からつけるとしたら、それにかかる少なくない人件費は、やはり税金から支出されることになるのですから、それならばむしろ、もっと別なことに予算をかけていただいて、読んでいく方向については、手でいちいちフラグをつけていくのではなく、何か別の方法でなんとかするように考えた方がよいのではないかとも思っているところです。

　ということで、ちょっと長くなってしまいましたが、京都大学附属図書館のIIIFワールドへの仲間入りを、改めて心よりお祝いしたいと思います。そして、これからも引き続き、頑張っていただけたらと思っております。