IIIFの活用をもう少し踏み込んで:SAT2018の事例より

ここのところ、合間を見つけて、ちょこちょこと作っていたものが、ようやく日の目をみてもよさそうなところまできたのでご紹介です。再びIIIFの話です。

 

SAT大蔵経テキストデータベース2018(SAT2018) と IIIF Manifests for Buddhist Studies (IIIF-BS)をうまく組み合わせてより利便性を高めたいと思っておりまして、結果として、以下のようなものができました。たとえば、『妙法蓮華経』の例を見て頂くと、右下にダイアログが開いて、以下のように、各地から公開されている経典画像の断片が、全体のどの部分にあたるか、というのが比較的正確に表示されるようになりました。

f:id:digitalnagasaki:20180426033124p:plain

これは大正新集大藏經の行番号をIIIF-BSで各IIIFマニフェストに割り当てておいて、その行番号をみて該当する箇所に該当するIIIFマニフェストを表示しています。横方向が経典の全体で、そのうちでそれぞれのIIIFマニフェストが対応する部分に関して、バーとして表示されるようにしています。このバーをクリックすると、IIIF対応画像に関しては、上のようにMiradorに表示されます。なお、この図の縦方向は、今のところ、公開期間ごとに分けているというだけでそれ以上の意味はありませんのでご注意ください。これを年代別にできるといいなあと思っているのですが、そのためには各画像の年代を調べて書いていかないといけないので、それはちょっと骨が折れそうです。(でもいつかできるようにしたいです)

 この表は、ホイール操作でズームすることもできるので、たとえば以下のようにして拡大してみて、各資料がどこまで残っているかを詳しく比較しながら確認することもできます。

f:id:digitalnagasaki:20180426033953p:plain

 

それから、「高麗蔵」「宮内庁宋版一切經」などは、まだIIIF対応ではないので、単に新しいウインドウ/タブがポップアップするだけ、という風になっています。

お試ししてみたい方は、以下にいくつかリンクを用意しておきますので、それぞれクリックしてみて「巻タイトル」の隣にある「画像一覧」というボタンをクリックしてみて下さい。そうすると、上記のような画像一覧の表が表示されるようになっています。

 

妙法蓮華経

http://21dzk.l.u-tokyo.ac.jp/SAT2018/T0262.html

『金光明最勝王経』

http://21dzk.l.u-tokyo.ac.jp/SAT2018/T0665.html

f:id:digitalnagasaki:20180426034706p:plain

 

今夜はもう寝なければならないので、とりいそぎ、速報ということでここまでとさせてください。

 

 

 

 

 

 

 

IIIF対応で画像を公開することの意義を改めて:各図書館等の事例より

前回の記事に引き続き、もう少し具体的に、各地の図書館等のIIIF画像とSAT2018との連携の状況についてのご紹介を通じて、IIIF対応で画像を公開することの意義を改めてみていきたいと思います。

 

1.京都大学東京大学の例

たとえば、以下の画像群は、左からみていくと、東京大学総合図書館、SAT研究会、京都大学図書館から公開されている画像です。東京大学総合図書館とSAT研究会の画像は仏教学のプロジェクトとしてデジタル化・公開されているので、このように使われているのはある意味これまでの流れの続きと言えると思います。

 一方、ここでまず注目しておきたいのは、京都大学図書館の画像です。京都大学図書館に関しては、おそらく、仏教学のプロジェクトの一環として公開したわけではなくて、自らのコレクションを学術利用全般のために公開するという文脈で公開したのだと想像しております。しかし、IIIF対応で公開したことによって、公開した側としてはそれ以上の手間暇はとくにかけなくとも、このようにして専門家コミュニティが利用するサイトにかなり便利な形で組み込まれて、教育・研究に活用される環境が作られていくことになります。

 

f:id:digitalnagasaki:20180409032637j:plain

ちなみに、このビューを得るには、以下のURLにアクセスして、巻17のところにあるIIIFアイコンを二つクリックして、ついでに大正新脩大藏経の巻17の始めの行のIIIFアイコンもクリックすると、大体完了です。

http://21dzk.l.u-tokyo.ac.jp/SAT2018/T1563_.29.0854b08.html

全画面表示する前は以下のような感じになりますが、全画面表示すると、上のように、大きく表示されて、読みやすくなります。

f:id:digitalnagasaki:20180408162835j:plain

 

 

2.ハーバード大学京都大学東京大学の例

あるいは、同様に、以下の例では、大慧普覺禪師語録巻二十五のうち、ハーバード大学京都大学東京大学、SAT研究会から公開されているものを並べてみています。

f:id:digitalnagasaki:20180408175338j:plain

これは、以下のURLから、一つ前の例と同様に、巻二十五のところにあるIIIFアイコンをクリックしていただくと表示できるようになっています。

http://21dzk.l.u-tokyo.ac.jp/SAT2018/T1998A.47.0916b11.html

 

3.九州大学・フランス国立図書館の例

以下の例は、金光明最勝王経という経典の第三巻の画像です。九州大学図書館では、この経典のかなりきれいな全巻揃いの写本を公開している一方で、フランス国立図書館で公開している敦煌写本画像のなかに同じ箇所のものがあったので、これも並べられるようにIIIFアイコンを用意しております。以下のURLから、上述のような仕方で閲覧できます。

http://21dzk.l.u-tokyo.ac.jp/SAT2018/T0665_.16.0413c10.html

f:id:digitalnagasaki:20180409034745p:plain

 

4.島根大学東京大学の例

島根大学図書館でも最近IIIF対応での画像公開が始まりましたが、そこに少し仏典画像が含まれていました。そこの『大智度論』の写本も、このようにして既存の他の画像と並べることができるのですが、この場合、右の二つの例とは区切り方が異なっており、大正新脩大藏経の脚注によれば、石山寺に写本で伝えられるものと一致していることから、そちらの系統の写本であることが想像されます。こちらは、頁を開いたあと、このビューにたどり着くのに少々手間がかかるので、URLは省略します。そういうパターンでもうまくアクセスできるようにすることを、次の開発目標にしています。

f:id:digitalnagasaki:20180409041408p:plain

 

5.バイエルン州立図書館・東京大学の例

バイエルン州立図書館は、IIIFに初期段階から熱心に関わっている機関の一つですが、そこでも、最近、東アジア資料のIIIF画像公開を始めたようです。日本の資料も色々ありますので、それはそれでどなたか何とかしてくださるとありがたいと思っておりますが、仏典関連資料も色々ありましたので、それもリンクしてみております。

http://21dzk.l.u-tokyo.ac.jp/SAT2018/T0262_.09.0027b13.html

f:id:digitalnagasaki:20180409042246p:plain

 

6. バチカン図書館の例

バチカン図書館では、NTTデータが技術面を担当しつつ、膨大なコレクションをIIIF対応で公開しつつありますが、そのなかに一つ、金泥写経があります。さすがにNTTデータが担当しているだけあってか、頁めくり方向を右⇒左にきちんと対応させていました。IIIFのルールとしてはきちんと用意されているのですが、ハーバードやフランス国立図書館等、欧米の機関だとなかなか対応できていないなかで、ありがたいことです。

f:id:digitalnagasaki:20180409043938p:plain

 

7.国文学研究資料館九州大学の例

国文学研究資料館は、現在、日本で最も多くのIIIF対応画像を公開している機関です。ここは、日本の古典籍を多く収集しているため、仏典関連でも、日本で広く読まれたものが多く公開されているのかもしれません。ここでは「仏説善悪因果経」が複数公開されていましたので、並べて見ています。読み下しにしてくずし字にしたものが一つ公開されていましたが、それと同じ版とおぼしきものは九州大学からも公開されていますので、それもならべてみています。それ以外にも、いくつか、国文学研究資料館から公開されていましたので、とりあえず見つけたものをリストしてみています。

http://21dzk.l.u-tokyo.ac.jp/SAT2018/T2881.html

f:id:digitalnagasaki:20180409045446p:plain

 

8.終わりに

 IIIFを通じて世界の文化機関が目指したのは、このようにして自らのコレクションを公開した際に、利用者が各自の文脈に応じてそれらを再編成し、効率的効果的に活用できるようにする環境を提供する、ということでした。ここまでみてきたように、ほとんどの機関は、仏教学のプロジェクトとして仏典画像を公開したのではなく、自らのコレクションを公開した中に、たまたま仏教学に役立つ資料画像が含まれていた、ということであるように思えます。それが、IIIF対応で公開されていることによって、このように、第三者が資料を集めて、特定の利用者コミュニティの利用方法に特化する形でサービス提供できるようになりました。この事例では、SAT2018から連携したことによって、各公開機関の方で電子テクストを用意していなくとも、SAT2018で全文検索した結果から画像にたどりつくルートが用意されたという形になっています。

 さらに、ここでは、単にSAT2018という単独のデジタルアーカイブで活用できるようにするだけでなく、以下のサイトにおいて、共同でIIIF対応画像を収集し、共同で目録情報を付与し、Web APIで利用できるようにもしています。

http://bauddha.dhii.jp/SAT/iiifmani/show.php

このIIIF Manifests for Buddhist Stufiesというサイトを介することで、同様のサービスを他のデジタルアーカイブにも追加することができるのです。たとえば、文学研究や歴史研究、あるいは漢字研究のためのサイトに特定のいくつかの仏典の画像が有用であるならば、その仏典に関するIIIF画像だけを、以下のようなURLで動的に入手することができます。(以下の例では、妙法蓮華経の巻第六の画像のIIIF Manifest URIのリストをApache Solrの検索結果の形で入手できます。)

http://bauddha.dhii.jp/SAT/iiifmani/show.php?m=getByCatNum&cnum=T0262&scrnm=s6

動的に、というのは、たとえば、上記のサイトに同じ経典の同じ巻の情報を誰かが追加したら、それを利用者はリアルタイムに入手・利用できるようになる、ということです。

 このように、単に、世界中のデジタルコンテンツに横串を指して利用者に便利なサービスを様々に提供できるようになるだけでなく、様々な便利なサービスを生み出すためのサービスを作りだしてそのような動きを促進することもできる、というのがIIIFが持つ大きな可能性であり、面白さでもあると思います。

 デジタル画像を公開するにあたり、少しでもうまく・幅広く活用されることを目指すなら、このようにして活用可能性を大幅に広げる機能を持ち、すでに世界的にも広く活用されるようになっているIIIFに対応しておくことは、目的達成のためのとても有力な選択肢であるように思われます。ここまで読まれた方で、まだ対応しておられない機関の方は、ぜひ、これを機に採用をご検討いただければと思っております。なお、すでに国内でもIIIFに対応できる企業は知る限りでも4社以上ありますので、外部発注をするにしてもそれほど問題なく導入できることと思いますし、内製が可能な組織であれば、容易に導入できるフリーソフトが様々に用意されていますので、ぜひ挑戦してみてください。

 さらに、画像だけでなく、音声・動画や3D等についても、徐々にIIIF対応が広がりつつあります。まだ事例はそれほど多くないですが、少なくとも画像と同様のことができるようになっていく見通しですので、そのようなコンテンツに関しても、採用に向けて検討してみていただくとよいかもしれません。

IIIF, Mirador, TEI, Word2vecを活用した仏教学研究教育サイト「SAT2018」

1.はじめに

2ヶ月ぶりのブログ更新です。この間、何をしていたのかというと、ひたすら時間をみつけて表題のサイト、SAT2018(SAT大蔵経テキストデータベース2018年版)を作っておりました。デジタルアーカイブの研究・教育利用のソリューションの一例とお考えいただけるとありがたく思います。今回の技術面でのキーワードはIIIF, Mirador, TEI, Word2vecで、隠れたキーワードはWebコラボレーションです。

f:id:digitalnagasaki:20180407234932p:plain

 

1994年に始まったSATプロジェクトでは、比較的初期の段階から、入力が済んだ順にテキストデータを公開していましたが、2008年に最初の全文検索Webサイトを公開した時は、大正新脩大藏経約1億字の全文検索や辞書検索、論文検索機能などが中心であり、2012年/2015年の改定では仏典画像の自前公開やリンク、パラレルコーパスなどが新規追加されました。

 今回、2018年版は、ネタが多すぎるので、ここでは一つずつ分けてご紹介していく予定です。まずここでは、比較的、適用性が幅広そうなIIIF/Miradorの話からいきたいと思います。

 

2.IIIF/Miradorの全面導入

今回のサイトでは、IIIF/Miradorを全面的に取り込んでいます。取り込みにあたっては、2ヶ月前のブログでご紹介した、IIIF Manifest for Buddhist studies と連携するとともに、基本的には、ここでのMiradorの使い方を踏襲しています。そこで、SAT2018では、IIIF画像の基本的な使い方として、

  • IIIFアイコンをクリックすると画面右側のMiradorのウインドウが新たに分割されてその画像のその頁が表示される。
  • IIIFアイコンをドラッグすると他のIIIF対応ビューワに表示される。

という風にしています。具体的にできるようにしたのは、「各文献を巻の単位で閲覧・対照できるように」ということです。これを全文検索と組み合わせることで、「全文検索をしてから巻単位であたりをつけて、気になる箇所は複数の版本を対照する」ことができるようになっています。たとえば、以下の例は、『妙法蓮華経』の「如來神力品第二十一」という章の版面を対照しているところです。ここでは、SAT研究会が提供する大正新脩大藏経の版面画像、フランス国立図書館が提供する敦煌写本・ペリオコレクションから2つ、東京大学総合図書館の万暦版大藏經、を並べて見ています。

 

f:id:digitalnagasaki:20180408002605p:plain

 

ここで、脚注の6番に着目してみると、一番左の『大正新脩大藏経』では「踊」としているものの、「三」(つまり、増上寺所蔵の宋版・元版・明版の三者)及び、「宮」(つまり、宮内庁書陵部の宋版一切經)では「涌」となっている、ということが書いてあります。そこで、とりあえずIIIFで参照できる資料を見てみますと、真ん中の2つ、遅くとも11世紀以前であることが想定される敦煌写本では「踊」となっており、一方、右側の、明代末~清代に刊行された万暦版大藏經(≒明版、ただし、大正新脩大藏経の校訂時に参照した刷りとは異なるので要注意)では「涌」となっています。

 

f:id:digitalnagasaki:20180408003223p:plain

 

IIIFではここまでですが、さらに、SAT218では、IIIF非対応画像でもいくつか巻単位でのリンクを張って見やすいようにしておりますので、ついでに、この箇所に関していくつか見てみましょう。

まず、13世紀に刊行された高麗版大藏經は、『大正新脩大藏経』の底本となっているものですが、その同じ版の異なる刷りのものをソウルの高麗大藏經研究所が大部分の画像とフルテクストをWebで公開してくれていますので、それを見てみますと、大正新脩大藏経が示すとおり「踊」となっています。(ちなみに、SAT研究会は、この高麗大蔵経研究所と包括連携協定を結び、対照目録データの共有等を行っています。)

f:id:digitalnagasaki:20180408003645p:plain

 

また、「宮」として脚注で参照されている宋版一切經は、慶応大学斯道文庫のWebサイトから公開されていて、SAT2018から巻単位でリンクされていますので、ちょっと見てみますと、これは「涌」になっていますね。

f:id:digitalnagasaki:20180408004038p:plain

 

さらに、奈良時代の写本というのがやはり宮内庁書陵部に伝えられていて、これも慶応大学斯道文庫のWebサイトから公開されていて、そちらにも巻単位でSAT2018からリンクされていますので、それを見てみますと「踊」になっているようです。

f:id:digitalnagasaki:20180408004924p:plain

 

こうしてみてくると、比較的古い写本と高麗版大藏經では「踊」となっているものが、木版の系統では、確認できる限りでは大正新脩大藏経が示すとおり「涌」になっているようです。

色々気になってきたので、ちょっと脱線して大正新脩大藏経を全文検索をしてみますと、

従地涌出:単語出現数 170

従地踊出:単語出現数 141

となっており、なかなか甲乙つけがたいものがあります。

ということで、こういったところから、仏典の伝承の系統を詳しく検討していくことができます。内容を検討する上でも重要になってくる場合がありますので、常用はしないとしても、必要な時にこのような機能が使えるようになっていることは大変重要です。以前は、一つ一つ閲覧許可を得たり、重くて高価なシリーズ本や影印本を購入したりしなければならず、一通り全部横に並べて検討してみるなどという贅沢なことは到底できなかったのですが、このようにしてWebで画像が閲覧できるようになったことで、この種の研究は大きく進展するのではないかと思います。また、ここでは、このようにして資料をIIIFで確認できると、ウインドウを切り替えたりせずにじーっと比較しながら読んでいくことができますので、やはり大変便利です。また、以下のように、

f:id:digitalnagasaki:20180408010621p:plain

 

「典籍」の「巻」の単位でリンクできるようにしておりますので、見たい箇所に比較的たどり着きやすくなっていると思います。(が、これはまだ改善の余地があり、抜本的な新ソリューションを検討中です)

 

さらに、IIIFの良いところは、リンクの仕組みが共通化されていますので、上述の IIIF Manifest for Buddhist studiesのサイトで集約した情報を、SAT2018に取り込むことも、容易に、世界中の対応画像に対して、一つのプログラムでできるようになっています。 IIIF Manifest for Buddhist studiesでは、世界中のIIIF対応仏典画像(の一部?)を集約しており、IIIF Manifest URIをリストアップするとともに、IIIF Manifestに記載されたテクストを全文検索できるようにしております。さらに、仏典の場合、特に中国語訳・中国語仏典の場合、大正新脩大藏経番号が世界中で広く使われており、論文等で参照する際にもそのテキスト番号や巻、頁番号などが記載されるようになっています。SAT大蔵経テキストデータベースも、その番号をずっと使ってきておりますので、世界中からリリースされつつあるIIIF Manifest URIに対しても、この大正新脩大藏経番号を付与できるようにしています。たとえば以下の図のように、これをWebコラボレーションでできるようにしており、少しずつ作業を進めております。

 

f:id:digitalnagasaki:20180408011507p:plain

ここに大正新脩大藏経のテキスト番号と巻番号を登録すれば、その番号で該当するIIIF Manifest URIを取り出せるようにしています。取り出しのためのURLはたとえば以下のような感じです。これは『妙法蓮華経』の巻第六のIIIF Manifest URIを取り出すためのURIです。

http://bauddha.dhii.jp/SAT/iiifmani/show.php?m=getByCatNum&cnum=T0262&scrnm=s6

 SAT2018からは、毎回このサイトに問い合わせを行ってデータをとってきますので、このサイトでのリンク情報の追加更新はダイレクトにSAT2018の利用画面に反映されることになります。特にアクセス制限は設けておりませんので、そのうち、他の仏典データベースでも、このサイトのデータを使ってIIIF仏典画像コンテンツを利用するようになるかもしれません。(海外の一部のプロジェクトとはそういう話をしております。)

3.国立国会図書館東京大学総合図書館所蔵『慧琳撰 一切經音義』のIIIF化・オープンデータ化・SAT2018連携

それから、もう一つのIIIFの活用例として挙げておきたいのは、『慧琳撰 一切經音義』です。この本は、唐の時代に書かれた、仏典に含まれる単語や文字の辞書なのですが、伝承の過程がやや特殊で、通常の中国木版大藏經の系譜から外れてしまっており、結果として、唐の時代の特徴を比較的損わずに現在に伝わっている可能性があるとみる向きがあります。この辞書は、13世紀に高麗で高麗版大藏經の一部として刊行され、木版大藏經の系譜の中ではそこにしか見つかっていないのですが、その後、江戸時代に忍澂上人が研究して校訂のようなことを行った本を木版で刊行し、さらに、明治時代には、その成果を含めた初の金属活字大藏經、大日本校訂大藏經(縮刷蔵)の爲部の後ろの方に含まれる形で刊行されます。それらを受けて、大正新脩大藏経にも含まれることになるのですが、とにかく、古い時代の辞書・字書を様々に引用しており、資料価値が高い一方で、いわゆる外字が極めて多く、SAT研究会が取り組む「仏典をすべてUnicode化することで普通に扱えるようにする」という目標にとって大きなハードルになっています。すでにSAT研究会では、これらのうち、デジタル画像化の許可が得られたものをデジタル画像化し、各文字を必要に応じて参照できる仕組みを構築し、この4年ほどはそれを用いて活動してきました。

SAT2018では、IIIFの仕組みを用いることで、それらの画像のうち、公開可能なものについて、容易に対比できるようにしました。ここでは、文字の形を対比できることが重要になりますので、拡大縮小を容易にできるIIIF/Miradorのメリットはとても大きいということになります。たとえば以下の例では、大正新脩大藏経(左から2番目)の脚注4に関して、一番左が大日本校訂大藏經、一番右が江戸時代の忍澂上人による刊本(白蓮社本)、右から2番目が、高麗版大藏經、ということになります。この場合、13世紀に刊行された高麗版大藏經に対して、忍澂上人が17世紀にこの文字に対して修正を行ったということがうかがえる一方、明治時代の大日本校訂大藏經では(活字が小さすぎて)つぶれてしまって読めない、という状況になっています。大正新脩大藏経では、この箇所に関しては比較的正確にそのような状況を記載していることがわかります。

 

f:id:digitalnagasaki:20180408015831p:plain

この一切經音義に関しては、以下のURLから閲覧できるようになっております。

http://21dzk.l.u-tokyo.ac.jp/SAT2018/T2128.html

 

3.1. Unicodeで使えるようにするためのIRG提案文書の動的閲覧

また、特にこの一切經音義を対象として、Unicodeで使えるようにするために、文字提案文書を作成しております。それも、SAT研究会の活動報告の一環として、そして、なるべく多くの人の目に触れて検証を行うべく、2015年2017年に符号化提案したリストを、証拠画像とともに掲載しました。SAT2018の画面右上の「参考資料」というリンクから表示することもできます。ここでも、iiifアイコンをクリックすると、該当する文字が含まれる頁がMirador上に表示されるようになっています。(ただし、残念ながら、すべての証拠画像で実現できたわけではありません。)たとえば、以下のような感じになります。すでに、この文書を議論するための組織、IRGのWebサイトではPDFで公開されているものですが、ここではそれを、動的に、全体の文脈のなかで閲覧・確認できるようにしております。

f:id:digitalnagasaki:20180408023523p:plain

 

 

3.2. 一切經音義 版本画像の出自とライセンス

なお、ここで利用している一切經音義の画像は、いずれもSAT研究会の画像データベースから配信しておりますが、白蓮社本と大日本校訂大藏經に関しては、SAT研究会と東京大学附属図書館との合意により、東京大学総合図書館所蔵の鷗外文庫に含まれるものをデジタル撮影・公開しており、再配布についても許諾されています。(余談ですが、以下のように、鷗外の蔵書だったことを示す印(鷗外自身の蔵書印ではないようです:青田寿美先生にご教示いただきました)も見えます)

f:id:digitalnagasaki:20180408033752p:plain

そこで、先行して2015年4月にオープンデータの貴重資料画像として試験公開され、その後正式に公開された東京大学大学所蔵万暦版大藏經と同様に、周辺情報も含める形でCC BYライセンスの下で公開するに至っております。

 一方、高麗版大藏經の一切經音義画像については、国立国会図書館デジタルコレクション(以下、国会デジコレ)にて画像公開されている京城帝国大学版という、刷りの新しいものを利用しています。国立国会図書館デジタルコレクションは、著作権保護期間が終了しているデジタル画像に関しては、再利用に何らの制限を設けていません。これまで筆者は、国会デジコレの画像をIIIFで公開する際には、国デコImage Wallに見られるように、NDL labの仮想サーバを用いていたのですが、今回は特に高速・大量アクセスが要求される場合があるため、SAT研究会の画像サーバにて公開させていただくことにしました。こちらは、ライセンスとしてはCC0をつけております。

 なお、ご存じの方も多いと思いますが、IIIFでは、ライセンス情報の書かれたURLをIIIF Manifestに記載することを求めており、ほとんどのIIIF対応ビューワでは、それを「情報ボタン」から表示できるようにしています。たとえば、Miradorの場合には以下のようになっています。

f:id:digitalnagasaki:20180408022431p:plain

4.SAT大正蔵図像DBとのシームレスな連携

SAT2018では、SAT大正蔵図像DBのIIIF画像検索・表示機能もマージしております。「図像検索」というボタンをクリックするとSAT大正蔵図像DBの図像を検索して表示します。以下は、よく用いる例ですが「炎髪」で検索してみています。これも2年前にIIIF対応でアノテーションとともに公開したものですが、2年前に公開したものでも、現在のシステムに、何の作り込みもせずに、何の追加料金も発生させずに、以下のように、ただ該当URLをビューワに渡すだけで、アノテーションも込みで普通に表示できてしまいます。IIIF以前は、他のシステムに組み込むどころか、単に、新規システムに移行するだけでも大変な手間と労力(あるいはそれにかかる費用や手続き)が必要でしたが、IIIFの登場により、事情は大きく変わりました。

 

f:id:digitalnagasaki:20180408012907p:plain

 

5.IIIF非対応の仏典画像群

ここまで、主にIIIF対応の仏典画像との連携についてみてきました。SAT研究会では、Web上の仏典画像についてはIIIF登場以前からリサーチを続けてきており、SAT2015ではそれらを連携して閲覧できるようにしていました。以前からある仏典画像の多くは、未だIIIF対応しておらず、当面は、そういったものについても引き続きリサーチとリンクを続けていく予定です。たとえば、転読で有名な(参考:興福寺での転読会の動画)大般若波羅蜜多經は、600巻ありますので、古い資料で全巻そろうのはなかなか難しいですが、各地に残された巻が少しずつデジタル化・公開されるようになってきており、これはこれでとてもありがたいことです。

f:id:digitalnagasaki:20180408024929p:plain

 

しかし一方で、IIIFに対応することで、利便性がとても高まりますので、すでに世界中でIIIF対応を呼びかけてきているところですが、今後も引き続き、それを続けていくつもりでおります。みなさまにおかれましても、未対応の方はぜひご対応を、対応済みの方は、IIIFのよりよい活用を目指していただけますと幸いです。

 

6. 終わりに

とりあえず今回は、IIIFの活用に関するさわりの説明で終わってしまいました。実際のところ、より緊密にテキストとリンクすることで、IIIFの活用可能性はさらに高まりますので、そのような実験も種々にしているところで、中にはもうじき公開できる話もあると思います。が、それはともかくとして、今後しばらく、SAT2018が提供する色々な機能について解説していきたいと思います。デジタルアーカイブの研究教育利用という観点でみなさまのお役に立てばと思っております。

 

7.おまけ(技術的なことに興味がある人向け)

今回、Miradorの画面をどんどん分割してManifest URIを読みこんで画像を表示していくという機能を提供しております。これは、私が書いたJavascriptのコードを見ていただけばわかることではあるのですが、いちいちあの長いものをみていくのは大変かもしれませんので、ポイントだけ少しご紹介しておきます。

まず、Miradorのインスタンスを作ります。

var miradorInstance = Mirador({..ここにMiradorの設定を書く...});

この時点で、一つManifestを読み込んでおくようにした方が後がやりやすいです。そうすると、

miradorInstance.viewer.workspace.slots[0].window.id

として、一つ目のウインドウを参照できるようになります。このウインドウに対して、何か操作をしたり、あるいは、新たにウインドウを追加したら、そのウインドウに対しても同様のIDで操作できるようになります。

ウインドウに対する操作は、

miradorInstance.eventEmitter.publish('操作内容', 'Window ID');

という風にします。ですので、たとえば、以下のようにすると、ID指定したMiradorのウインドウ(ワークスペースと呼んでいることもあります)が閉じます。

miradorInstance.eventEmitter.publish('REMOVE_WINDOW', '上記のID');

この操作内容には、他に、

SPLIT_RIGHT
ADD_WINDOW
ADD_MANIFEST_FROM_URL

等、いくつか用意されています。特に、新たにManifestを読み込ませるときは、

miradorInstance.eventEmitter.publish('ADD_MANIFEST_FROM_URL', 'Manifest URI');

をした後に、windowConfig設定とともにADD_WINDOWすることで、目当ての頁を表示させたり、目当ての箇所を拡大表示させたりしますが(そこら辺の設定はwindowConfigで設定してしまう)、普通に処理を並べると、Manifest ファイルを読み込み終わる前に次の操作に入ってしまって、読み込みが一度ではうまくいかないので、たとえばjQueryであれば $.when~.then のような、Manifestファイルを読み込み終わってからADD_WINDOWするような手法をとるとよいと思います。

$.when(
miradorInstance.eventEmitter.publish('ADD_MANIFEST_FROM_URL', 'Manifest URI'),
$.ajax({url:'Manifest URI'})
).then(function(){
var windowConfig = {
loadedManifest: kMani,
canvasID: kCvsId,
sidePanelVisible: false,
"windowOptions": {
"osdBounds": {"x": linep,"y": parv,"width": 0.08,"height": 0.5}
},
slotAddress: miradorInstance.viewer.workspace.slots[num].layoutAddress
};
miradorInstance.eventEmitter.publish('ADD_WINDOW', windowConfig);
});

ここら辺のところは、すでにご存じの方々も多いと思いますが、もし未チェックでしたら、これを機に、ぜひ、IIIF関連開発の選択肢に入れて置いていただけますと幸いです。

 あるいは、(むしろここが重要なのですが)、もっと良い書き方があったらぜひ教えてください。

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

 

 

 

 

仏典研究のためのIIIFコンテンツ収集+閲覧サイトを作ってみました

今回は、仏典研究のためのIIIFコンテンツを収集して閲覧できるサイト、というのを作ってみました。とりあえず1分くらいお時間がおありの方は以下の動画GIFをご覧になってみてください。

 

動画

 

要するに、世界各地のデジタルリポジトリ・デジタルコレクションに少しずつ含まれている仏典関連のIIIF manifestを集めて、IIIF manifest中の文字列で検索できるようにして、さらに、Miradorでクリックするだけで簡単に画像を並べられるようにしたものです。

 

技術的には特に難しいことはしておらず、最近世間で広まっていてフリーソフトで実現できる一般的な技術を組み合わせただけでこれくらいのことはできます。もう少し具体的には、IIIF manifestをサイトに登録すると、IIIF manifestのJSON形式をたどって文字列が入っているはずの箇所を取り出してから、それらの文字列を一つにまとめて、フリーの全文検索ソフトApache Solrに登録するようになっています。今までのこの種のサイトとひと味違うのは、すでに世界中の色々な機関から大量に公開されているIIIF manifestのURIを登録すれば、あとは全部自動的にやってくれてしまうという点です。

 Apache Solrという全文検索ソフトはよくできたフリーソフトで、歴史もあり、かゆいところにもかなり手が届く設計になっていながら、最近流行のJSONにもきちんと対応しているということで、とても便利なものです。以前からちょこちょこ試していたソフトの一つだったのですが、最近改めてこの本を買って、チュートリアル的に一通り操作方法をきちんと確認してから、こちらを見つつ色々作ってみているところです。

 今回は、アイコンをクリックするだけでMiradorで画像を開いて、さらに、もう一度アイコンをクリックするとMiradorのワークスペースを一つ増やしてそこに画像を並べるようにしてみています。これは、Miradorに元々用意されている機能を使ったもので、以下のようなコードを基本にしています。

<span class="hoge" data-n="manifest URI">Miradorのアイコン</span>

というエレメントがあったとしまして、これをクリックした時に、すでにMiradorインスタンスが一つ開いている場合に、以下のようなスクリプトが動くようになっています。(Miradorインスタンスがない状態から開くのは簡単すぎるので特に書きません)

 

var mUri = $(this).attr('data-n');

//クリックしたエレメントの属性値に書いてあるManifest URIを拾って

var slot = mirador.viewer.workspace.slots[0];

//一番左のワークスペースの番号を取得して
var num = mirador.viewer.workspace.slots.length;

//現在のワークスペースの数を数えて
mirador.eventEmitter.publish('SPLIT_RIGHT', slot);

//とりあえず一番左のワークスペースの隣に一つワークスペースを追加します

$.when(
   mirador.eventEmitter.publish('ADD_MANIFEST_FROM_URL', mUri),

// Manifest のURLを渡してManifestの内容をMiradorに読み込ませて
   $.ajax({url:mUri})

//Manifestの読み込みが終了してから(これをもっとうまく書きたいのですが…)・・・
).then(function(){

//次の手順に入りまして…
   var windowConfig = {

// ワークスペースに表示させる情報を設定します。ここはMiradorの設定と同じことです
     loadedManifest: mUri,
     slotAddress: mirador.viewer.workspace.slots[num].layoutAddress

//新しく追加されたスロットのアドレスを取得して設定しておきます。
};
mirador.eventEmitter.publish('ADD_WINDOW', windowConfig);

//あとは、新しく追加されたスロットに、設定したマニフェストの資料を表示します

})

 

これまで、アイコンをドラッグ&ドロップをしないと複数並べることが難しいということが、ユーザ側には結構ネックになることがあって、なんとかしたいと思ってきていたのですが、今回のシステムではちょうど良い案配になるのではないかと思って試しに付けてみたのでした。

 

このような感じで、割と簡単に、自分の好きなテーマのWebコンテンツを対象とした検索サイトのようなものを作ることができるようになります、というのがIIIFの面白さの一つと言いましょうか、とても重要な根幹部分です。他の分野でもこういう感じのものを作ってみていただくと面白いのではないかと思います。ぜひみなさまも挑戦してみてください。 また、それにあたって、このシステムを使ってみたいという人がおられましたらお声がけください。即応は難しいかもしれませんが、ぼちぼち対応させていただきます。

 

ということで、このシステムが、みなさまのデジタルアーカイブ/デジタル・ヒューマニティーズを考えていただく上でのヒントの一つにでもなりましたら幸いです。

 

※このサイトを作るにあたっては、神崎正英さんに一つご教示をいただきましたので感謝とともに記しておきます。

Omeka IIIF ToolKitを少し便利に

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

 

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

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

 

f:id:digitalnagasaki:20180201152142g:plain

 

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

 

地味な変更ですが、ピンポイントで結構便利な感じになるのではないかと思います。もし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、ApachePHPIIP Image server等をソースコードからコンパイルして設定しました。ですので、特に新たな費用は発生しませんでしたが、このやり方で導入してしまうとセキュリティアップデートなどがちょっと大変になってしまうので、企業発注の場合にも、導入コストだけでなくメンテナンスコストもやや高く見積もられてしまう可能性があります。ですので、HTTP/2に関しては、広くサーバ用途で使われるLinuxディストリビューションが対応するまで待った方がいいかもしれません。

 

1.3.画像配信サーバソフトのインストール

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

 

1.4.タイル画像化する場合のストレージの容量

 ある程度大きな画像を配信しようとする場合や、負荷がかなり大きくなることが想定される場合には、画像を事前にタイル化しておく方が利便性を下げずに済みます。タイル画像化については、現状ではPyramid Tiled Tiff(あるいはPyramid Tiff)が一般的であるように思われます。Pyramid Tiled Tiff形式を作成する場合、お手元の状況にもよると思いますが、TiffJpeg等の画像ファイルを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仕様についていく必要はないのですが、さりとて、ずっと古いままで、いずれビューワやその他の関連ツールや関連環境などが対応できなくなってしまうと本末転倒な感じになってしまいますので、やはり、どこかの時点でアップデートに対応できる体制とシステムはあった方がいいように思われます。

 

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