構造をどこにどう格納し、何を API として配信するか。この選択は、プロジェクトの規模と用途、将来の拡張の余地を左右する。
格納先の選択肢と用途の対応
小規模なプロジェクトや、機械処理の前段として画像領域とメタデータを紐づける作業では、CSV や Excel などの表計算形式が出発点になりうる。画像の部分領域を切り出してメタデータを付与し、切り取り画像の URL を Excel でリスト化したうえで、後からプログラムで外部システム向けの形式に変換する運用が報告されている [UC-001 §ICPの高度な利用]。表計算形式は可搬性が高く初期コストも低いが、クエリの表現力や同時編集の堅牢性には限りがある。
より複雑なクエリや多ユーザーでの運用には関係データベースが向き、地理情報を含む場合は PostGIS などの空間データベースを組み合わせる。小規模なら表計算、複雑なクエリや多ユーザーなら関係データベース、地理情報を含むなら空間データベース、という対応が選び方の骨格になる。この整理は一般的なものであり、紐づく記事で関係データベースを運用した事例は、後述するテキストレポジトリの一例にとどまる。地理データに固有のファイル形式と配信は「地理データの形式と公開基盤」を、実体・属性・関係の切り分けは「データモデリングと構造化」を参照。
記事が具体的に示すのは、用途と規模に応じて格納先や構成を分ける例である。
- 共有の要否で分ける: 同一構図撮影を支援するカメラアプリでは、サーバ側に保存されるのは複数人で共有するプロジェクトのデータのみで、個人で完結するマイプロジェクトのデータはサーバに保存されない [UC-004 §アプリの基本要素とプラットフォーム]。共有が要るデータだけを集中管理し、個人用のデータは手元に置く切り分けである。
- 利用環境の段階で分ける: IIIF Curation Platform(ICP)の利用環境には、デモ環境を使う方法、クライアントだけを設置する方法、サーバも自前で立てる方法がある。プロジェクト専用環境を構築する Docker 版では、ポートやプロキシの設定が分かる程度のサーバー管理知識と Docker の基本知識が要るが、それほど高度な知識がなくても十分に対応できる範囲だと述べられている [BP-001 §工程ごとにツールを使い分ける]。構成の複雑さは、利用側が負える運用負担に合わせて選べる。
- 作業の規模で分ける: IIIF Curation Editor は個別のメタデータの追加や変更に使われるが、大規模な編集作業には向かないことが注意点として挙げられている [BP-001 §工程ごとにツールを使い分ける]。
いずれも当該のアプリやツール群についての記述であり、ここから格納先の一般的な選択基準を導くことはしない。実体間の関係をグラフとして表現し識別子で接続する考え方は「知識グラフとリンクトデータ」が扱う。グラフストアを実際に運用した実践知は、紐づく記事に見当たらない(本節末尾の「現時点で薄い領域」の項を参照)。
正本をデータベースに置き、API 越しに使う構成
関係データベースを正本とし、アプリケーションをすべて API 越しに使う構成の実例が、テキストレポジトリのシステムで報告されている。本文・注釈・同定をレポジトリ本体に保存し、アプリケーションは API を介してのみ使う [UC-049 §テキストレポジトリのシステム構成]。
- 正本: PostgreSQL 16 に、資料・版・本文(Canonical Text)、注釈、言及・実体・同定リンク、注釈どうしの関係、監査ログを保存する。
- 確定と推測の分離: AI の推測である候補は、確定データとは別の表に置く。
- API 層: REST と OpenAPI を用い、型付きクライアントを生成する。
- 連携するアプリケーション: 注釈・エンティティリンキング、分析・可視化、取り込み(翻刻・TEI・PDF・IIIF を変換し、確認してから版を確定する)、閲覧・検索が API で連携する。
確定データと AI の候補を別の表に分けておくことで、機械が出した推測が確認前のまま確定データに混ざることを避けられる。この分離は、正本として何を持つかという格納上の判断であり、配信の設計とも結びつく。
JSON を中間層として置く構成
格納形式と配信形式のあいだに JSON を中間層として挟む構成が、IIIF を使うプロジェクトで報告されている。JSONkeeper は JSON 形式のデータを保存・提供するサービス、Canvas Indexer は JSONkeeper のデータをクロールしてキャンバス単位に分解し検索可能にするサービスで、ビューアやファインダーの背後でデータベース的な層を担う [UC-001 §ICPの高度な利用]。この層に機械学習によるタグ付けサービスを連携させ、顔にタグを付けて検索する使い方もある。キュレーション単位で集めたデータをキャンバス単位に分解し、メタデータ単位で組み替える仕組みも、この層の上で動いている [UC-001 §ICPの高度な利用]。
中間層を置くと、前段のデータ作成と後段の検索・閲覧が切り離される。切り取り画像の URL をリスト化しておけば、後から JSONkeeper を読み出して別のデジタルアーカイブ向けの形式へ変換することもできる [UC-001 §ICPの高度な利用]。ここでの「組み替えがしやすい」という性質は、報告された運用から読み取れる範囲での整理であり、他の格納構成との比較に基づくものではない。
何を API として配信するか
格納したデータを外部に公開するとき、何を標準の API に載せ、何を独自の要件として残すかが、再利用可能性を左右する。標準の仕様に沿って配信すれば、利用者は既存のビューアでそのまま閲覧できる。一方、標準が想定しない要件を独自拡張で満たすと、その拡張に対応したビューアが要る。IIIF の API の構成と、独自拡張を伴う配信の事例は「画像の流通基盤」を参照。
もう一つの配信の考え方が、先のテキストレポジトリに見られる。OpenAPI を公開して、外部の研究システムも同じ API を使えるようにし、将来アプリケーションを追加しても本体の構造は変えない [UC-049 §テキストレポジトリのシステム構成]。何を正本として持ち、何を API を通して見せるかを分けることで、利用側のアプリケーションを増やしても、格納の構造を変えずに済む。
ここで述べたのは、紐づく記事が報告している構成の範囲である。エンドポイントの切り方、認証、バージョニングについての推奨は、記事から導けない。
後から変えることの難しさ
格納形式と API は、一度決めると後から変えるコストが高い。表計算形式から関係データベースへ移すにはスキーマ設計の見直しが要り、グラフ構造への再モデリングは構造の決め直しに及ぶ。独自 API 拡張に依存した下流のシステムは、拡張を変えるたびに修正を迫られる。この見立ては一般的な整理であり、移行の失敗や成功を扱った記事に基づくものではない。
このため、格納先の選択は、データモデリングの段階で見込まれるクエリの種類、データの規模、配信の要件と合わせて検討するのが望ましい。構造の決定が後から問えることを制約する側面は、「データモデリングと構造化」を参照。