カレントアウェアネス
No.346 2020年12月20日
CA1989
動向レビュー
IIIFの概要と主要APIバージョン3.0の公開
一般財団法人人文情報学研究所：永崎研宣（ながさききよのり）
1. IIIFとはどういうものか
文化資料をデジタル化してウェブに公開し、知の公共化をより広く進めることで社会に貢献したい。いわゆる「デジタルアーカイブ」の構築・公開に関わる人なら国内外を問わず多かれ少なかれ共有している気持ちだろう。しかし、それに触れようとすると、サイトごとに様々に異なる使い方を覚え、アクセスするたびにウェブサイトを切り替え、どこにあるかわからない資料を探すべく色々なウェブサイトを検索して回る、といった状況があった。このことは、ユーザにとって不便であるというだけでなく、文化資料を活用してもらいたい公開機関の側にとっても、本来の目標達成の障害になってしまっているという捉え方がなされるようになっていた。一方で、個々の機関が別々に専用のウェブシステムを発注して開発作業や高額な費用を個別に負担するという状況を続けることに困難を感じる場面が増えてきた。
このような状況を解決するために、無料で自由に共用できる規格の開発を目指して米英仏等の有力な機関のエンジニア達が手を取り合い、研究助成金を獲得したことで始まったのが IIIF（International Image Interoperability Framework）という枠組みであった。IIIFが国際的に大きな広がりをみせるのは、IIIFコミュニティが助成金依存を脱却すべくIIIFコンソーシアムを設立した2015年頃からであった。欧米各地の国立図書館や有力な大学図書館・研究図書館を中心に、急速に広まっていったのである。日本国内でも2016年にはSAT大正蔵図像DB(1)がIIIFを全面採用し、東京大学人文情報学拠点が日本から初めてIIIFコンソーシアムの会員となり、その後は京都大学貴重資料デジタルアーカイブ(2)や国立国会図書館デジタルコレクション(3)、国文学研究資料館の新日本古典籍総合データベース(4)等の大規模ウェブサイトで採用されるなど、陸続と広がっていった。最近では、ジャパンサーチ（E2317参照）(5)、カルチュラル・ジャパン(6)などの大規模ポータルサイトや、KuroNetくずし字認識サービス(7)、「みんなで翻刻」(8)等のデジタルアーカイブのコンテンツをさらに利活用するサービスにおいてもIIIFが大いに活用されている。
IIIFの基本を一言で表現するなら、各地のウェブサイトで公開されているコンテンツの任意の部分を共通の仕方で取り出せるようにするための技術的なルールを定めたものである。技術的には既存のものを組み合わせただけであり、当初から新規性は皆無だったが、国境を越えた複数の有力機関が共通ルールを採用したという点はまさに画期的であった。これによって、一つの手法で取り出せる画像が飛躍的に増加することになり、それに準拠して画像を公開・閲覧できるシステムが開発されやすくなるだけでなく、それを取り出して様々に活用するソフトウェアやシステムを開発することにもスケールメリットが生じることとなった。有用なソフトウェアやシステムが広まるにつれてIIIFがもたらし得る潜在的な可能性の高さについての認識が広まり、採用する機関が増加していき、さらにそれが新たな有用なサービスを生み出していくという好循環に入ったのが2010年代後半であった(9)。既存技術の組み合わせであるが故の導入のしやすさも、それを後押しした。そのような流れを踏まえつつIIIFコンソーシアムが満を持してリリースしたのが、主要なAPIであるIIIF Image APIとIIIF Presentation APIのバージョン3.0である。
2. バージョン3.0以前のIIIF API
バージョン3.0の説明に入る前に、その前のバージョン2がどのようなものであり、何をもたらしていたのか、について触れておきたい。バージョン2がリリースされたのは2014年9月のことである(10)。当時はまだIIIFの開発コミュニティもそれほど大きくなかったこともあり、リリース直後には対応しているアプリケーションが少なく、利便性の高い対応アプリケーションが増え始めるまではやや時間を要した。筆者が試用を始めた2015年2月頃には、まだ対応ソフトウェアが十分に整備されておらず、導入もそれほど容易ではなかった。その後1年ほどかけて環境が改善され、2016年に入った頃には対応ソフトウェアのみならず英語による導入手順書なども整備され、比較的容易に導入できると言ってよいものとなっていた。
IIIFのAPIは、この種のサービスを構築するのに必要な機能を効率的に提供すべく、役割に応じた複数のAPIに分割され提供されている。現在、正式版としてはImage API、Presentation API、Authentication API（CA1988参照）、Search APIが公開され、さらにベータ版としてChange Discovery APIとContent State APIが用意されている。これらはいずれも、筆者がIIIFコミュニティに参加し始めた2016年5月頃にはすでにGoogleドキュメントに議事録をとりながらZoomで実施される会議やGitHubのリポジトリを主な検討の場としており、世界中から参加したメンバーによって議論されてきた。これらのAPIのなかでは、特に、画像の操作に関するルールを定めるImage APIと、画像をはじめとするウェブコンテンツ同士の関係や注釈などを記述するルールを定めるPresentation APIという二つのAPIが広く利用されている。今回の主題であるバージョン3.0へのアップデートがこの二つのAPIに関して行なわれたということもあり、ここではこの二つについて概観してみよう。
3. IIIF Image APIについて
IIIF Image APIは、ウェブサイトに対して画像を取得するリクエストを送った際に、（1）画像に関するサイズやタイル化の有無などの情報を返戻することと、（2）画像のサイズや切り抜き領域、回転角度などをURIで指定して取得する手法を定めた取り決めである。大きな画像をウェブブラウザ上で表示する際、画像を小さなタイルに分割して表示領域のタイル画像だけをその都度サーバにリクエストするというルールもここに含まれている。これに準拠することにより、サーバ・クライアント（ウェブブラウザに表示されたIIIF対応ビューワ）間のやりとりの中で、大きな画像をタイルに分割する際にタイルのサイズを確認したり、ブラウザ上で必要なサイズの画像や、拡大表示したい箇所だけを指定して拡大した画像をリクエストしたりしている。ただし、このAPIでは準拠レベルを3段階に設定しており(11)、最高のレベル2では画像の切り抜きや回転にも対応することになっているが、レベル0では画像切り抜きもサイズ変更もなく、ただJPEG画像を提供できるだけでよいということになっている(12)。
実際の所、このIIIF Image APIを導入するにあたっては、これに対応している画像サーバソフトを導入した上で、その画像サーバソフトが要求するフォーマットの公開用画像を用意することになる。要求フォーマットは、JPEGやPNG、Pyramid TIFFやJPEG2000など、ソフトウェアによって様々だが、Pyramid TIFFの場合、画像をタイル上に分割したものをまとめたフォーマットになっているため、アクセスがあるたびにJEPG画像をタイルに分割するタイプの画像サーバソフトに比べるとサーバの負荷は小さくて済むことになる。
4. IIIF Presentation APIについて
IIIF Presentation APIは、画像などのコンテンツ同士の関係の記述と、それらに対するアノテーションなどを紐付けるためのルールを定めている。これまでにも同種のものはいくつか存在していたものの、おそらくこれが画期的であったのは、メタデータの記述についてルールをほとんど用意しなかったという点だろう。「デジタルアーカイブ」を構築する際にはメタデータをどのようにしてきちんと付与するか、ということが課題になりがちだが、資料を扱う分野が異なるとそれぞれに色々なルールがあって合意形成がなかなか難しく、結果として仕事が前に進まなくなってしまうということがままある。一方、IIIF Presentation APIは、たとえば、1冊の写本に含まれるページ画像がどういう順番でならべられるべきか、そこにどういう文字・テキスト・画像が記載されているか、といったことを記述することを定めたものであり、「どういうメタデータ項目を記述するか」というような、内容に関わることには基本的に踏み込まず、自由に記述できるようになっている。それゆえに、固有のメタデータを有する様々な種類の文化機関が採用しやすく、また、メタデータをきちんと作成できない場合でもとりあえずデジタル画像として公開できるため、常に人手不足のコンテンツの専門家に依拠せずとも、より間口の広いデジタル撮影やウェブ公開のための専門企業に外注するだけで対応できることになり、これもIIIFの広い普及を促すこととなった。
IIIF Presentation APIに対応するには、当該資料に含まれる画像や注釈、メタデータ等を所定の書き方に沿ってJSON-LD形式で記述して、そのファイルをウェブサーバに置いておくだけでよく、技術的にはかなり簡便な部類に入る。これによって、外部からも「この資料のこのページの画像」や「このページに付与された注釈データ」といったものを指定して取り出すことができる。そのようにして取り出したデータはウェブページ上に様々なレイアウトで貼り付けて表示したり、一括検索したり、指定された画像を切り出してOCRをかけたりと、様々な利活用が可能となる。
5. これらを活用したアプリケーション
これらのAPIを活用するアプリケーションには様々なものがある。代表的なのは、Mirador(13)、Universal Viewer(14)、TIFY(15)等といった、いわゆるIIIF対応ビューワである。それぞれ、簡単にIIIF対応画像をブラウジングできるようになっており、Universal Viewerでは動画・音声・3D画像の閲覧・視聴も可能となっている。また、ビューワも含めたIIIF対応コンテンツ活用プラットフォームの開発も盛んに行なわれており、代表的なものの一つに人文学オープンデータ共同利用センターのIIIF Curation Platform（E2301参照）(16)がある。これにより、世界各地のIIIF対応画像の任意の箇所を切り出して並べたりメタデータを付与したりと、横断的に様々な活用が可能となっている。同様に、Omeka(17)やBlacklight(18)などの統合的なコンテンツ管理システムでもIIIF対応コンテンツを取り込んで様々に操作して公開できるようにするプラグインが開発・提供されている。
そういった大がかりな活用システムが続々と開発される一方で、IIIF対応コンテンツをスマホケースに印刷してくれるウェブサイト(19)や、ジグソーパズル化してくれるウェブサイト、ゲームソフトウェア「あつまれ どうぶつの森」に取り込めるQRコードを作成してくれるウェブページ(20)など、目的特化型の様々なIIIF対応サービスも開発されるようになった。IIIF画像の世界は、専門家の外の世界にも様々な広がりをみせつつあったのである。
6. IIIF API 3.0
このようにIIIFが普及しコミュニティが発展していくなかで着々と策定が進められてきたのが、2020年6月3日にリリースされたIIIF Image APIとIIIF Presentation APIのバージョン3.0である。すでに広く普及していることから、非互換な変更はあまり行なわないという選択肢もあり得たが、IIIFコンソーシアムは、むしろこの機会に、次を着実に見据えた変更を行なった。個々の変更については、それぞれのAPI仕様を掲載しているウェブページにChange log(21)として掲載されているので、詳細はそちらを参照していただくとして、ここでは、とりあえず概観した上で、今後の方向性について検討してみよう。
両APIに共通する基本的な変更としては、データ形式がJSON-LD1.0からJSON-LD1.1へと移行した。そして、特によく用いられるプロパティである＠idや＠typeがそれぞれid、typeとなった。JSON-LDコミュニティの方向性に沿った変更だが、プログラミングの便という意味で有用性が高い。
IIIF Presentation APIの基本的なデータモデルに関しては、コミュニティベースで策定されたOpen Annotation model（E1613参照）に代えてW3C標準となったWeb Annotation Data Model（E1916参照）へと移行した。実際の所、両者の関係は、前者がW3Cで標準化された際に後者に名前が変わったというものであり、内容的には大きな違いはないと考えてよいだろう。全体として、ウェブの国際標準との結びつきをより深め、現代的なウェブ技術を適用しやすくしたということになる。
また、非互換の大きな変更もあった。ユーザ側からみて大きなものは、音声や動画を扱うためのルールが整備された点だろう。これにより、動画や字幕、静止画像など、様々なタイプのコンテンツを一つのタイムライン上で扱うことが共通のルールとして可能となっている。また、IIIF Presentation APIでは、コンテンツ中の一つのまとまり（たとえば写本の1ページ）をcanvasとみなし、そこに様々なコンテンツを載せていくというモデルを採るが、バージョン2ではcanvas同士がリンクされることまでは想定されていなかった。今回のバージョンアップにより、色々なコンテンツをcanvasに載せた上でそれを他のcanvasにリンクできるようになった。そして、canvasにコンテンツを載せる際、これまでは画像を直接載せるモデルになっていたが、バージョン3.0ではAnnotationPageという概念が新たに導入され、それにまとめられた上でcanvasに載せられることになった。これに伴い、外部アノテーションを付与する際に用いていたAnnotationListは廃止された(22)。メタデータ等の多言語対応に関しては、labelやsummary（これまではdescription）、metadata中のlabelやvalueといった、コンテンツに関わるテキストを記載する箇所に国際標準のBCP47(23)に準拠した言語指定が可能となった。これにより、複数言語のメタデータが用意されていてもIIIF Presentation APIのレベルで扱えるようになった。
一方、IIIF Image APIに関しては、非互換な変更として、返戻されるinfo.jsonファイルにおいてAPI準拠レベルを示すプロパティを明示することや、URIの記法が若干修正され、また、レベル1とレベル2における正方形での切り出し機能が新たに必須となった。
ただし、Image APIの場合、画像サーバソフトがバージョンアップに対応しないことにはユーザ側もデジタルアーカイブ提供者側も対応のしようがなく、今のところまだ多くの画像サーバソフトが対応したという状況ではない。とはいえ、サーバソフト側で対応が難しそうなものはそれほど多くないため、あまり時間をかけずに広まっていくだろう。
このような、特に目立つ変更以外にも、様々な変更が行なわれた。その多くは、提供者・開発者側からの扱いやすさを志向したことがうかがえるものであり、IIIFの開発者コミュニティ的性格が端的に表れていると言っていいだろう。
7. 今後の展望
すでにバージョン3.0のAPIに対応しているとするウェブサイト(24)やソフトウェア(25)も一部に存在するが、全体としては十分に対応しているソフトウェアやシステムは多くなく、各地の開発コミュニティが活発に作業を続けている模様である。また、これまでもIIIFの課題とされていた、できることが多すぎるためにすべての機能に完全に対応できるビューワの開発が困難であるという点は、動画・音声を統合的に扱えるようになったことにより、さらに難易度が高まっている。ビューワとしては、2020年11月9日に正式リリースされたMirador 3(26)が、Presentation / Image APIのバージョン3.0に対応しつつ音声・動画も扱えるようなっただけでなく、プラグイン志向を強めることで様々な機能を各自が開発・付与できるように工夫している。ビューワ提供側が何もかも用意するというよりも、それを利用するコンテンツ提供機関がそれぞれに公開手法に工夫を凝らすという選択肢の提供を志向しているのである。
デジタルアーカイブ等の公開側における今後の対応としては、ビューワの状況を見据えつつ、代表的なビューワが対応した段階で準拠していくのが穏当なところだろう。ビューワだけでなく、バージョン2を前提とした様々な応用システムが世界中で稼働している状況であることから、バージョン2での公開をやめてしまうとそれらのシステムが動かなくなってしまうため、バージョン2に関しては、バージョン3.0対応後も引き続き公開していくことがデジタルアーカイブの持続可能性にとっては大切である。特にIIIF Presentation APIの場合、複数のバージョンを共存させつつ公開することにあまりコストがかからないため、そのことも見越した上での非互換な変更だったとも言えるだろう。上述のMirador 3が、バージョン2と3.0の両対応としていることも、そうした事情を反映していると言えるだろう。
なお、今回のアップデートにあたり、IIIF コンソーシアムでは、Cookbook of IIIF Recipesというサービスを開始した。ここを見ると、自分のコンテンツを公開するのに必要なIIIF Presentation APIの「レシピ」、すなわち、何かを作るために必要な要素とその組み合わせ方の情報を簡単に入手できるようになっている。バージョン3.0への対応を検討している人は、こちらを参照されるとよいだろう(27)。
(1) SAT大正蔵図像DB.
https://dzkimgs.l.u-tokyo.ac.jp/SATi/images.php, （参照 2020-10-23）.
(2) 京都大学貴重資料デジタルアーカイブ.
https://rmda.kulib.kyoto-u.ac.jp/, （参照 2020-10-23）.
(3) 国立国会図書館デジタルコレクション.
https://dl.ndl.go.jp/, （参照 2020-10-23）.
(4) 新日本古典籍総合データベース.
https://kotenseki.nijl.ac.jp/, （参照 2020-10-23）.
(5) JAPAN SEARCH.
https://jpsearch.go.jp/, （参照 2020-10-23）.
(6) Cultural Japan.
https://cultural.jp/, （参照 2020-10-23）.
(7) “KuroNetくずし字認識サービス”. 人文学オープンデータ共同利用センター.
http://codh.rois.ac.jp/kuronet/, （参照 2020-10-23）.
(8) みんなで翻刻.
https://honkoku.org/, （参照 2020-10-23）.
(9) これについては、
永崎研宣. 特集, デジタルアーカイブを支える技術：デジタル文化資料の国際化に向けて：IIIFとTEI. 情報の科学と技術, 2017, 67(2), p. 61-66.
https://doi.org/10.18919/jkg.67.2_61, （参照 2020-10-23）.
がその時点までの状況を伝えている。さらにその後の状況については、
永崎研宣. “可用性を高めるための国際的な決まり事：IIIFとTEI”. 日本の文化をデジタル世界に伝える. 京都大学人文科学研究所・共同研究班「人文学研究資料にとってのWebの可能性を再探する」編, 樹村房, 2019, p. 97-163.
を参照されたい。
(10) “IIIF Image and Presentation API Version 2.0 Published”. IIIF. 2014-09-11．
https://iiif.io/news/2014/09/11/version-2-published/, （accessed 2020-10-23）.
(11) “Image API Compliance, Version 3.0.0 3.1 Region”. IIIF.
https://iiif.io/api/image/3.0/compliance/#31-region, （accessed 2020-10-23）.
(12) この場合には、本文中（1）の、画像についての情報の提供がImage APIに期待される役割ということになる。それでは切り抜き画像の表示もまったくできないのかと言えば、Presentation APIのアノテーション機能をCSSと組み合わせることによって一部を切り抜いたかのような表示をする機能をウェブブラウザ上で実装することは可能である。
(13) Mirador.
https://projectmirador.org/, （accessed 2020-10-23）.
(14) Universal Viewer.
https://universalviewer.io/, （accessed 2020-10-23）.
(15) TIFY.
https://github.com/tify-iiif-viewer/tify, （accessed 2020-10-23）.
(16) “IIIF Curation Platform”. 人文学オープンデータ共同利用センター.
http://codh.rois.ac.jp/icp/, （参照 2020-10-23）.
(17) OmekaのIIIF拡張については筆者による以下のブログ記事を参照。
“公開されているIIIFコンテンツを収集・共同編集するツールがリリースされました”. digitalnagasakiのブログ. 2017-07-04.
https://digitalnagasaki.hatenablog.com/entry/2017/07/04/041007, （参照 2020-10-23）.
(18) BlacklightのIIIF拡張については、たとえば以下を参照。
Snydman Stuart .“New Tools for Providing Access to Digital Image Collections: Mirador and Spotlight”. CNI Fall 2015 Membership Meeting. Washington, DC, 2015-12-14/15, CNI, 2015.
https://www.cni.org/wp-content/uploads/2015/11/CNISpotlightMiradorv2-Snydman.pdf, （accessed 2020-10-23）.
(19) cover.boutique.
https://cover.boutique/, （accessed 2020-10-23）.
(20) “Animal Crossing Art Generator”. Getty.
https://experiments.getty.edu/ac-art-generator, （accessed 2020-10-23）.
(21) それぞれ、以下のURLを参照。
“Changes for IIIF Image API Version 3.0”. IIIF.
https://iiif.io/api/image/3.0/change-log/, （accessed 2020-10-23）.
“Changes for IIIF Presentation API Version 3.0”. IIIF.
https://iiif.io/api/presentation/3.0/change-log/, （accessed 2020-10-23）.
(22) バージョン2と3の違いについては以下のページ掲載の図を参照のこと。
“IIIF Presentation API 3.0”. IIIF.
https://iiif.io/api/presentation/3.0/, （accessed 2020-10-23）.
“IIIF Presentation API 2.1.1”. IIIF.
https://iiif.io/api/presentation/2.1/, （accessed 2020-10-23）.
(23) “Tags for Identifying Languages”. 2009-09.
https://tools.ietf.org/html/bcp47, （accessed 2020-10-23）.
(24) Digital Bodleian.
https://digital2.bodleian.ox.ac.uk/, （accessed 2020-10-23）.
(25) ViewerにおけるPresentation API version 3.0については、2020年11月正式リリースされたMirador version 3がサポートしたとしており、Universal Viewerは現在開発中となっている。
(26) “Mirador v3.0.0 is released”. Stanford Libraries. 2020-11-09.
https://library.stanford.edu/blogs/digital-library-blog/2020/11/mirador-v300-released, （accessed 2020-11-12）.
(27) IIIFに関する日本語情報については、当面は下記リストを参照されたい。
“IIIFに関する日本語情報の私的なまとめ（2019/11/14版）”. digitalnagasakiのブログ.
https://digitalnagasaki.hatenablog.com/iiif, （参照 2020-10-23）.
［受理：2020-11-18］
永崎研宣. IIIFの概要と主要APIバージョン3.0の公開. カレントアウェアネス. 2020, (346), CA1989, p. 13-16.
https://current.ndl.go.jp/ca1989
DOI:
https://doi.org/10.11501/11596735
Kiyonori Nagasaki
An Overview of IIIF and Release of IIIF API Version 3.0
本著作（CA1989）はクリエイティブ・コモンズ 表示 4.0 国際 パブリック・ライセンスの下に提供されています。ライセンスの内容を知りたい方は https://creativecommons.org/licenses/by/4.0/legalcode.ja でご確認ください。
