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対応サービスや対応機関などの情報がありましたら、当方までお知らせいただけますとたいへんありがたく存じます。）

IIIF manifestファイルの書き方を神崎正英さんが解説しておられます

また更新の時間が空いてしまいましたが、今回はIIIF maniefstファイルの書き方について、Web標準の世界で有名なあの神崎正英さんがインフォコムのブログにて解説記事を書いてくださっています。

特に、まだ私が取り組んでいないrange等の書き方についても解説してくださっていますので、より利便性の高いIIIF manifestファイルを作成しようと思ったら、ぜひ読んでみて挑戦してみてください。

画像共有の新しい標準IIIF｜LOD Diary｜RDF/Linked Open Data等の最新情報ブログ【Infocom デジタルアーカイブシステム】

一歩進んだIIIFマニフェストの利用｜LOD Diary｜RDF/Linked Open Data等の最新情報ブログ【Infocom デジタルアーカイブシステム】

ちなみに、このdigitalnagasakiのブログでは、IIIF manifestファイルの書き方についてはまだ全然解説していません。見ればわかるだろうと思って敢えて書こうとしなかったのですが、結構リクエストがありまして、そのうち書いてみようと思っています。

東京国立博物館の一部デジタルコンテンツがCC BY-NC的な感じに！

昨日知ったのですが、東京国立博物館のhttp://webarchives.tnm.jp/ 配下で公開しているデジタルコンテンツの利用許諾条件（ライセンス）が変更され、以下のようになったそうです。

当館で公開しているデジタルコンテンツ(画像、テキスト等)のうち、 著作権の生じるものについては、特別な記載のない限り当館がその著作権を保有しています。

http://webarchives.tnm.jp/ 配下で公開しているデジタルコンテンツ( 画像検索、データベース等)に限り、非商業目的で下記の「デジタルコンテンツ無償利用条件」（以下「本条件」という）を満たすご利用については、特別な手続きを経ることなく無償で複製、加工、出版物やウェブサイトへの掲載等を行うことができます。 利用者は条件に従ってご利用ください。

「東京国立博物館 - デジタルコンテンツの利用について」

これは、大変ありがたく、かつ、画期的なものだと思います。いわゆるクリエイティブコモンズライセンスで言えばCC BY-NC（表示・非営利）にあたるものだろうかと思います。

『仏鬼軍絵巻』をIIIF対応に

というわけで、さっそく、少しやってみました。こちらのサイトの「画像検索」にて公開されている『仏鬼軍絵巻』というデジタル化資料があります。これは如來や菩薩・明王らの大軍が地獄に攻め込んで亡者を救済するという絵巻で、壮大なスケールの戦いが描かれているのですが、公開中の絵巻のデジタル画像は分割されていますので、まず、それらを一通りくっつけて、IIIF対応にしてみました。マニフェストファイルは以下のURLとなっております。

http://dzkimgs.l.u-tokyo.ac.jp/iiif/bukkigun/manifest.json

このマニフェストURIさえあれば、どこのIIIF対応ビューワでも読み込めますし、色々活用できますので、ぜひ、利用許諾条件の範囲でご活用してみてください…と書きたいところですが、これだけだとなんだかイマイチですので、ちょっと実際にIIIF対応ビューワに読み込ませてみましょう。

変体仮名認識システムに

まずは、@2SC1815Jさんによる、変体仮名認識システム付きのIIIF Curation Viewerに読み込ませてみます。

IIIF Curation Viewer with Hentaigana Image Recognition

画像の解像度の関係でちょっと字が小さくて難しいかもしれませんが、文字によってはそれなりに認識できているような感じですね？

日本古典籍データセットの『仏鬼軍』と並べて見る

さて、次にいきましょう。実はこの『仏鬼軍絵巻』は、色々なバージョンがあって、特に江戸時代に何度か木版本で刊行されたものは結構流布したようです。ネットでもいくつか公開されています。

ドイツデジタル図書館の仏鬼軍

仏鬼軍 | 日本古典籍データセット

国文研データセット簡易Web閲覧： 仏鬼軍

早稲田大学古典籍総合データベースの仏鬼軍

このうち、国文研データセット簡易Web閲覧のものは、東京大学大学院生の北﨑有帆氏により本文の翻刻がIIIFアノテーションとして付与されていますので、これを例のMiradorで並べて表示させて対比してみると、木版本の挿絵がどういうもの表現をしようとしていたか、ということがちょっと想像できて面白いですね。

いきなりずらっと並べてしまいましたが、いくつか、以下に、Miradorでのビューへのリンクをご用意しましたので、自分でもビューワ上で眺めてみたいという方は、こちらから見ていってみてください。なお、ビューワでは、各ウインドウの左上のアノテーションボタンをクリックすると翻刻が表示されますので、よかったらそれも試してみてください。

不動明王と五大尊が鬼を攻めているところ

薬師如来と十二神将

船や動物に乗る菩薩達

とりあえず、比較的すぐにできそうなことを手元でやってみたのですが、東京国立博物館のコンテンツは面白いものがたくさんありますので、みなさまもぜひお試ししてみていただけたらと思っております。

それから、ちょっとテクニカルな話題として、Miradorに関してなのですが、元になっているOpenSeadragonではいわゆるViewport Navigatorが装備されているにもかかわらず、Miradorでそれを有効化する方法を見つけることができておりません。特に巻物的な横に長いものは、Viewport Nagivatorのようなものがないと「どこを見ているのか」わからなくなってしまうことがあり、なんとかしたいところです。この場合、「これだからMiradorよりも他のビューワを使った方がよい」と思う人もおられると思いますが、「とりあえずMiradorを改造してみよう（誰かにやってもらおう）」という方向もありではないかと思います。オープンソースですし、元々、OpenSeadragonでは実装されている機能なので、そんなに苦労せずになんとかなるのではないかと想像しております。あるいは、Miradorの開発チームにそういう要望を投げてみるのもよいかもしれませんが。

ということで、最後はやや脱線気味でしたが、今後ともよろしくお願いいたします。