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

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

IIIF（International Image Interoperability Framework）は、世界中のミュージアムやライブラリが公開する画像を、機関をまたいで同じビューアで閲覧できるようにする国際的な画像配信方式である。この相互運用性が整うことで、所蔵機関の異なる資料を一つの画面に並べて見るという作業が、個々の機関との特別な交渉なしに実現する。

Image API と Presentation API の構成

IIIF は複数の API から構成される。その中心となる Image API は、画像の配信を HTTP リクエストで標準化する仕様である。URI に領域・サイズ・回転・品質・フォーマットのパラメータを組み込んで画像サービスへ送ると、指定した条件に従った画像が返ってくる 1。同じ仕様に対応したサービスであれば、どのビューアからでも同じ方法で画像を取得できる。

Presentation API は、閲覧環境がオブジェクトをどう表示するかを指定するための仕様である。デジタル化された画像・映像・音声などをユーザーに提示し、複数のビューや時間範囲をシーケンシャルまたは階層的にナビゲートさせ、コンテキストとなる説明情報を表示させるための情報を提供することを目的とし、検索エンジン向けのメタデータ収集は意図的に対象外とされている 2。現行の安定版は Presentation API 3.0 で、2020年6月3日に公開されている 2。

マニフェストとキャンバスの役割

Presentation API の中心的なデータ構造がマニフェストである。マニフェストは、ある資料をどのような順序・方向で閲覧するかの情報を保持する。たとえば和書と洋書ではページをめくる方向が逆になるが、IIIF にはどちら側にめくるか（viewingDirection）を指定する機能があるため、同じビューアでどちらも表示できる [UC-001 §IIIF画像の閲覧]。マニフェストを構成するキャンバスは画像を配置する単位であり、のちにキュレーションによって画像の一部分を切り出すときや、複数機関の資料を一覧にまとめるときの参照点になる（詳細は「部分を切り出す」を参照）。

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

IIIF の相互運用性がもたらす変化は、画像を複製せずに機関をまたいだ比較ができることである。『源氏物語』の写本・版本を例にとると、東京大学総合図書館所蔵の写本に限らず九州大学をはじめ複数の機関で公開されている諸本を集約し、一つの環境から比較できるようになる [UC-003 §「デジタル源氏物語」と諸本比較支援]。この集約を可能にするのは、各機関のマニフェストをそのまま参照できるという仕組みであり、複数マニフェストにまたがるアノテーションの管理にも同じ枠組みが適用できる。

機関横断的な閲覧環境は、資料を物理的に手元に引き寄せることなく成り立つ。CODH が公開した江戸マップを例にとると、国立国会図書館デジタルコレクションの江戸切絵図はコピーせず国立国会図書館にアクセスして画像を取得し、その上に重ねるオーバーレイ情報だけを別途作成している。利用者が独自に付加情報を作って公開し、元のデータは提供元から取得するという構成である [UC-001 §地図へのアノテーション]。

相互運用性の前提として何を揃えるか

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

Image API 3.0 は最新の安定版として現行の基準となっており 1、この仕様に対応したサービスを構築することが、他機関・他ツールとの接続性の出発点になる。接続性があるとはいえ、現在の IIIF の枠組みで適切に扱えない資料形式もある。時系列画像のように「前」「次」が時間の移動になる資料や高頻度観測の連番画像は、標準仕様の範囲では表現しきれないため、Timeline API や Cursor API として独自に拡張した API が用いられるが、これらは独自拡張に対応したビューアでしか表示できない [UC-001 §IIIF画像の閲覧]。

利用者側の視点を持ち込む

IIIF の仕様は画像の「提供者側」の視点で設計されている。これに対し、利用者が特定のテーマに沿って複数機関の画像を集め、並べ直し、付加情報を与えて公開するという「利用者側」の視点は、標準仕様のみでは直接サポートされていない。この差を埋める試みとして、Curation API という仕様が独自に整備されており、キュレーションリストを介して領域・メタデータ・アノテーションを一元管理する形が実践されている [UC-001 §キュレーションプラットフォームとキュレーションAPIの区別]。Curation API はデータのフォーマットや提供方法を定めた仕様であり、特定のソフトウェアへの依存を前提としない点がその設計上の位置づけである。

この枠組みが複数機関の画像に対してどう機能するか、また部分を切り出して集め直すという実践がどのように成り立つかは「部分を切り出す」を参照。

参考資料