データモデリングで決めた構造をどこに格納し、どう配信するかという選択は、プロジェクトの規模・用途・将来の拡張性に直結する。格納先は表計算形式から関係データベース、空間データベース、グラフストアまで幅広く、何を 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 拡張に依存した下流システムの修正は、いずれもプロジェクトの途中で着手すると影響範囲が広い。したがって、格納先の選択は、データモデリングの段階で想定されるクエリ・規模・配信要件と合わせて検討することが望ましい。構造の決定が後で何を問えるかを制約する側面については「データモデリングと構造化」を参照。