データモデリングで決めた構造をどこに格納し、どう配信するかという選択は、プロジェクトの規模・用途・将来の拡張性に直結する。格納先は表計算形式から関係データベース、空間データベース、グラフストアまで幅広く、何を API として外部に公開するかという問いとも切り離せない。
格納先の選択肢と用途の対応
小規模なプロジェクトや、機械処理の前段として画像領域とメタデータを紐づける作業では、CSV や Excel などの表計算形式が事実上の出発点になることがある。画像の部分領域を切り出してメタデータを付与した結果を Excel でリスト化し、後からプログラムで外部システム向けの形式に変換するという運用が報告されている [UC-001 §ICPの高度な利用]。この形式は可搬性が高く初期コストが低い反面、クエリの表現力と同時編集の堅牢性に限界がある。
より複雑なクエリや多ユーザー環境では関係データベースが選ばれる。地理情報を含む場合は PostGIS などの空間データベースが加わる——地理データに固有のファイル形式と配信については「地理データの形式と公開基盤」を参照。実体と実体の関係が複雑になるケースでのグラフデータベースやリンクトデータへの格納については「知識グラフとリンクトデータ」を参照。実体・属性・関係の切り分けがどこで行われるかについては「データモデリングと構造化」を参照。
JSON を中間層として置く構成
格納形式と配信形式の間に JSON を中間層として置く構成は、IIIF を使うプロジェクトで具体例が報告されている。JSONkeeper が JSON 形式のデータを保存・提供するサービスとして機能し、Canvas Indexer がそのデータをクロールしてキャンバス単位に分解・索引化することで、ビューアや検索サービスの背後にあるデータベース層を担う [UC-001 §ICPの高度な利用]。この層に機械学習によるタグ付けサービスを連携させ、顔画像を検索するといった拡張も実施されており [UC-001 §ICPの高度な利用]、JSON を中間フォーマットとして挟む設計がシステムの組み換えを容易にしている点が観察できる。
何を API として配信するか
格納したデータを外部に公開する際、API の設計は再利用可能性を決める。IIIF マニフェストを画像配信の API として用いると、ビューアや外部システムがそのまま接続できる。一方、標準 API が対応しきれない場面では独自拡張で対応した事例がある。時系列画像のアーカイブでは、「前」「次」が「ページ」ではなく「時間」の移動になる要件に対して、Timeline API と Cursor API を独自に拡張して実現した [UC-001 §IIIF画像の閲覧]。ただし、独自拡張は対応したビューアでしか表示できないというトレードオフを生む [UC-001 §IIIF画像の閲覧]。標準への準拠と独自要件への対応の間の緊張は、格納層だけでなく API 層の設計でも生じる。
後から変えることの難しさ
格納形式と API の選択は、後から変えるコストが高い。表計算形式を関係データベースへ移行するときのスキーマ設計の見直し、グラフ構造への再モデリング、あるいは独自 API 拡張に依存した下流システムの修正は、いずれもプロジェクトの途中で着手すると影響範囲が広い。格納先の選択は、データモデリングの段階で想定されるクエリ・規模・配信要件と合わせて検討することが望ましい。構造の決定が後で何を問えるかを制約する側面については「データモデリングと構造化」を参照。