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

 

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

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を利用(こちらは色々お金がかかるが、すでにライセンスを購入していればそのまま使ってください)するのがいいような気がします。ただし、これもネットワークやハードウェアの環境によって違ってくることがあると思いますので、ご自身の環境でも試してみてください。
  • 画像のサイズや想定アクセス数にあわせて画像配信サーバソフトを選択する。
  • 画像配信サーバソフトを、画像が置いてあるディレクトリにアクセス権を持っているサーバにインストールする。

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

  • 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 ViewerMiradorで、それぞれに様々特徴があります。それに加えて、EuropeanaIIIF Curation Viewerで採用されているLeafletというビューワもあります。それぞれよく比較してみて、目的にあったものを設置するという手もありますし、好きなビューワを閲覧者が選べるようにするという方法もあります。

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

 

終わりに:検索と認証

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

 

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

 

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

 

 

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

いよいよ、出ました。

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

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

 

一言で言うなら、

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

 

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

 

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

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

 

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

 

f:id:digitalnagasaki:20171013050710p:plain

 

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

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

 

f:id:digitalnagasaki:20171013050659p:plain

 

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

 

f:id:digitalnagasaki:20171013050633p:plain

 

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

 

f:id:digitalnagasaki:20171013050613p:plain

 

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

 

f:id:digitalnagasaki:20171013050547p:plain

 

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

f:id:digitalnagasaki:20171013050524p:plain

 

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

f:id:digitalnagasaki:20171013050443p:plain

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

f:id:digitalnagasaki:20171013050410p:plain

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

 

f:id:digitalnagasaki:20171013050350p:plain

 

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

 

f:id:digitalnagasaki:20171013050342p:plain

 

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

 

f:id:digitalnagasaki:20171013050333p:plain

 

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

 

f:id:digitalnagasaki:20171013050321p:plain

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

 

f:id:digitalnagasaki:20171013050300p:plain

 

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

 

f:id:digitalnagasaki:20171013050253p:plain

 

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

 

f:id:digitalnagasaki:20171013050312p:plain

 

という感じで、とても簡単に、「各地の画像を集めた仮想コレクション(と私は仮に勝手にそう読んでいます)ができるようになってしまいました。もう一つ、各地の画像を集めた仮想コレクションを作れるシステムとして、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の重要なアップデートをお祝いしつつ、作成者の方々に感謝しつつ、今後のさらなるデジタルアーカイブの発展の礎ができあがりつつあることを目の当たりしている実感とともに、とりあえず筆を置きたいと思います。