画像の流通基盤 — ガイドライン

作業版この節は現時点の記事に基づきAIが生成した暫定的な構造化(作業版)です。編集部が公開した内容は候補版、コンソーシアムが承認した規範版は第N版を参照してください。 (版の状態について)

IIIF（International Image Interoperability Framework）は、質の高い画像などのデジタル資料を、出典を明示したままオンラインで大規模に届けるための公開標準群であり、その開発・実装を担う国際コミュニティの名でもある。主要な文化機関のコンソーシアムがこれを支えている 1。この節では、その構成と、機関をまたいで資料を並べて見ることが何を変えるか、そしてその前提として何を揃える必要があるかを述べる。

提供する側の標準としての IIIF

様々なサイトの HTML ページを同じブラウザで見られるのと同じように、世界各地の IIIF サービスの画像を同じビューアで閲覧できる。この相互運用性が、画像の世界で IIIF の注目される理由とされている [UC-001 §IIIF Curation Platformとは何か]。ビューアには Mirador や Universal Viewer などがあり、CODH が開発する IIIF Curation Viewer もその一つである [UC-040 §IIIFとは]。

IIIF が世界中で急速に普及したのは、ミュージアムやライブラリといった画像提供者の共通のニーズに応えたからだ、という見方がある。共通形式でデータを公開して相互運用性を担保することで、同じツールで世界中の画像にアクセスできるようになった。各種ツールが IIIF を前提とするにつれ、IIIF に対応していないアーカイブのほうが「不便」とみなされる状況が近づいているとも語られている [UC-001 §IIIFの相互運用性とICPの独自性]。

Image API と Presentation API

中心となるのは二つの API である。Image API は、画像の領域・サイズ・回転・品質・形式を URI で指定し、標準的な HTTP(S) リクエストに対して画像を返す配信 API として定義されている。画像の技術的な情報を返す要求も URI で組み立てられる。この API は、文化遺産機関が管理する画像リポジトリで画像資源を体系的に再利用できるようにするために構想された 1。

Presentation API は、複数の画像や時間的範囲からなる資料を、人が閲覧できる環境で提示するために必要な情報を与える。画像のほか動画・音声などを含む対象について、複数の表示面や時間範囲を順序や階層をたどって見られるようにすること、資料の記述情報を示すこと、出版者と利用者が付加情報を注釈できる共通の場を持つことが目的である。この API が与える記述情報は人が読むためのもので、検索エンジンによる索引付けを意図したメタデータの提供は対象に含まれない 2。

資料の構造を記述するのがマニフェストである。各機関の Web サイトに置かれたマニフェストをビューアへドラッグ＆ドロップすれば、その作品が読み込まれる [UC-002 §顔コレ構築のワークフロー]。そのため、IIIF で公開されている画像であれば、どの機関のものでも同じ手順で読み込める [UC-041 §顔コレの構築過程]。

公開側の記述が閲覧の挙動を決める

公開側の指定は、そのまま閲覧の挙動に表れる。和書と洋書ではページをめくる方向が逆になるが、IIIF には「どちら側にめくるか」（viewingDirection）を指定する機能があり、同じビューアで両方を閲覧できる [UC-001 §IIIF画像の閲覧]。

標準の枠組みで扱いにくい資料もある。高解像度の気象衛星画像のような時系列資料では、「前」「次」がページ送りではなく時間の移動になる。この資料は Timeline API と Cursor API を独自に拡張して公開されており、その拡張に対応したビューアでしか表示できない [UC-001 §IIIF画像の閲覧]。標準の枠組みに収まる資料と独自拡張に依存する資料とでは、使えるビューアが分かれる。相互運用性は、公開側が標準の範囲で記述しているかどうかに左右される。

機関をまたいで資料を並べて見る

IIIF の相互運用性は、機関の枠を越えて資料を並べて見ることを可能にする。

一つは、画像を複製せずに参照する構成である。江戸マップでは、もとの江戸切絵図は国立国会図書館デジタルコレクションの IIIF 画像で、CODH はその画像をコピーせず国立国会図書館から取得し、町名や施設名を重ねるオーバーレイ情報だけを作成している [UC-001 §地図へのアノテーション]。利用者が付加情報を作って公開し、もとのデータは提供元から取得する使い方である。

もう一つは、異なる機関の資料を同じビューアで読み込める点である。どの機関のマニフェストでも、ドラッグ＆ドロップという同じ手順で読み込めるので、機関ごとに別の閲覧環境を用意する必要がない [UC-041 §顔コレの構築過程]。

こうした大規模なデータ収集が可能になった背景には、多くのミュージアムやライブラリによる高解像度画像の公開がある。IIIF の相互運用性は、日本でも他の国でも同じ技術でデータを集められる形で、組織横断的かつ全球的な大規模データ収集を可能にした [UC-040 §知見と今後の展望]。切り出した部分を集め直す使い方については、「部分を切り出す」を参照。

相互運用の前提として揃えるもの

資料を機関横断で並べるには、公開側が IIIF で資料を公開していること自体が前提になる。そのうえで、揃えるべき事柄は記事から次のように読み取れる。

データの持ち方：画像を手元に置かず、提供機関が公開する画像を参照し、自分のデータとしては付加情報だけを持つ構成である [BP-001 §画像は複製せず領域とメタデータを持つ]。
公開側の記述の範囲：標準の範囲で記述された資料は同じビューアで扱えるが、独自拡張に依存する資料は対応するビューアでしか表示できない [UC-001 §IIIF画像の閲覧]。

メタデータの記述水準にも手がかりがある。メタデータは、誰が使うかによって求められる水準が変わる。自分や自組織のためだけの利用なら相互運用性はあまり重要ではないが、一般的・専門的な利用者による「流通」を想定するなら、相互運用性を考慮した形式や、分野ごとの詳細なメタデータが必要になる [UC-021 §メタデータをめぐる論点：利用者・項目・専門性]。機関をまたいで資料を並べて見る使い方は、まさにこの流通にあたる。なお、Presentation API が与える記述情報は人が読むためのもので、検索エンジンによる索引付けを意図した記述は対象に含まれない 2。マニフェストの記述だけで機械的な発見や検索が成り立つわけではない。

IIIF の公式仕様は画像の提供者側の視点で書かれており、集める・並べる・付加情報を重ねるといった利用者側の視点は、独自に拡張した仕組みで補われている [UC-001 §キュレーションプラットフォームとキュレーションAPIの区別]。

参考資料