はじめに

デジタルデータの長期保存は、図書館、アーカイブ、研究機関にとって重要な課題です。データ形式の変化、ソフトウェアの陳腐化、ストレージ技術の進化など、様々な要因がデジタル情報の持続可能性を脅かしています。

本記事では、この課題に対する解決策の一つである**OCFL（Oxford Common File Layout）**について、その概念、意義、そして実装例を紹介します。

OCFLとは

OCFL（Oxford Common File Layout） は、デジタル情報を構造化され、透明で、予測可能な方法で保存するための仕様です。オックスフォード大学のボドリアン図書館とスタンフォード大学図書館を中心に開発され、現在はコミュニティ主導のオープンスタンダードとして発展しています。

OCFLの公式定義

“OCFLは、アプリケーション非依存のアプローチでデジタル情報を保存するための仕様であり、長期保存とデータの完全性を保証します。”

OCFLの5つの主要原則

  1. 完全性（Completeness） - リポジトリをストレージファイルから完全に再構築可能
  2. 解析可能性（Parsability） - 人間と機械の両方が理解できる構造
  3. 堅牢性（Robustness） - エラーや破損に対する耐性
  4. バージョン管理（Versioning） - オブジェクトの変更履歴を保持
  5. ストレージの多様性（Storage Diversity） - 様々なストレージインフラに対応

なぜOCFLが必要なのか

デジタル保存の課題

従来のデジタル保存には、以下のような課題があります：

  • ベンダーロックイン - 特定のシステムやソフトウェアに依存してしまう
  • 移行の困難さ - システム更新時のデータ移行が複雑
  • 透明性の欠如 - データがどのように保存されているか不明瞭
  • 長期的な可読性 - 数十年後もデータを読み取れる保証がない

OCFLによる解決

OCFLは、以下のアプローチでこれらの課題を解決します：

  • シンプルなファイル構造 - 標準的なファイルシステムを使用
  • JSONによるメタデータ - 人間が読める形式で管理情報を保存
  • ハッシュによる完全性検証 - データの破損を検出可能
  • 透明なバージョニング - すべての変更履歴が追跡可能

OCFLの基本構造

OCFLリポジトリは、以下のような階層構造を持ちます：

ocfl_root/
├── 0=ocfl_1.1                    # OCFL仕様バージョンを示すマーカー
├── ocfl_layout.json              # レイアウト情報
└── object-001/                   # OCFLオブジェクト
    ├── 0=ocfl_object_1.1         # オブジェクトバージョンマーカー
    ├── inventory.json            # オブジェクトの完全な履歴
    ├── inventory.json.sha512     # インベントリのチェックサム
    └── v1/                       # バージョン1
        ├── inventory.json        # このバージョンまでの履歴
        ├── inventory.json.sha512
        └── content/              # 実際のコンテンツ
            └── sample.txt

inventory.json - OCFLの心臓部

inventory.jsonはOCFLオブジェクトの最も重要な要素で、以下の情報を含みます：

{
  "id": "object-003",
  "type": "https://ocfl.io/1.1/spec/#inventory",
  "digestAlgorithm": "sha512",
  "head": "v2",
  "contentDirectory": "content",
  "manifest": {
    "4171fdae3bde...": ["v1/content/data.txt"],
    "2d3d718515b3...": ["v2/content/data.txt"],
    "de313e63171...": ["v2/content/additional.txt"]
  },
  "versions": {
    "v1": {
      "created": "2025-11-05T11:32:17.462453+00:00",
      "message": "Version 1: Initial data",
      "user": {
        "name": "Data Manager",
        "address": "manager@example.com"
      },
      "state": {
        "4171fdae3bde...": ["data.txt"]
      }
    },
    "v2": {
      "created": "2025-11-05T11:32:17.462568+00:00",
      "message": "Version 2: Updated data",
      "user": {
        "name": "Data Manager",
        "address": "manager@example.com"
      },
      "state": {
        "2d3d718515b3...": ["data.txt"],
        "de313e63171...": ["additional.txt"]
      }
    }
  }
}

inventory.jsonの主要な要素

  • manifest - ファイルのハッシュ値と物理パスの対応表
  • versions - 各バージョンの作成日時、メッセージ、ユーザー情報
  • state - 各バージョンにおける論理ファイルの状態

OCFLとGitの違い

OCFLはバージョン管理を行う点でGitと似ていますが、目的と設計思想が大きく異なります。

項目OCFLGit
主な目的長期デジタル保存ソフトウェア開発の協調作業
設計思想シンプルさと透明性効率性と機能性
ファイル形式標準的なファイル・JSON独自のバイナリ形式
可読性人間が直接読めるツールが必要
ブランチサポートしない中核的機能
マージサポートしない中核的機能
重複排除コンテンツアドレッシングPackfileによる圧縮
保証100年後も読める設計現在のツールで最適
対象ユーザーアーカイブ・図書館ソフトウェア開発者

なぜGitではダメなのか

Gitは優れたバージョン管理システムですが、長期保存には以下の課題があります：

  1. 複雑性 - .gitディレクトリの内部構造は複雑で、Gitツールなしでは理解困難
  2. ツール依存 - データを読み取るにはGitクライアントが必須
  3. バイナリ形式 - Packfileは効率的だが、将来のツール互換性に不安
  4. 機能過多 - 保存には不要な多くの機能を持つ

OCFLは、シンプルさ と透明性 を優先し、特殊なツールなしでもデータにアクセスできることを保証します。

本リポジトリでの実装例

本リポジトリでは、PythonのOCFL Coreライブラリを使用して、OCFLの主要な機能を実装しています。

実装例1: シンプルなOCFLオブジェクトの作成

from ocflcore import OCFLRepository, OCFLObject, OCFLVersion

# リポジトリの初期化
repository = OCFLRepository(root, storage)
repository.initialize()

# オブジェクトとバージョンの作成
obj = OCFLObject("object-001")
v1 = OCFLVersion(datetime.now(timezone.utc))
v1._message = "Initial commit"
v1.files.add("sample.txt", file_stream, digest)
obj.versions.append(v1)

# リポジトリに追加
repository.add(obj)

実装例2: バージョン管理

本リポジトリのobject-003では、ファイルの更新履歴を管理しています：

  • v1 : data.txtの初期バージョン
  • v2 : data.txtの更新 + additional.txtの追加

この構造により、以下が可能になります：

  • 任意のバージョンへの復元
  • 変更履歴の追跡
  • ファイルの完全性検証

実装例3: 重複排除（Deduplication）

object-004では、同じ内容のファイルを異なる名前で追加しています：

# 同じ内容のファイルを3つ作成
v1.files.add("copy1/file_a.txt", file_stream_a, digest)
v1.files.add("copy2/file_b.txt", file_stream_b, digest)
v1.files.add("copy3/file_c.txt", file_stream_c, digest)

結果 :

  • 論理ファイル数: 3
  • 物理ファイル数: 1

OCFLは、ハッシュ値が同じファイルを1つの物理ファイルとして保存し、ストレージを効率化します。

OCFLの利点

1. 長期的な持続可能性

  • シンプルな構造 - 複雑なツールに依存しない
  • 標準的な技術 - ファイルシステムとJSONのみ
  • 明確な仕様 - 公開されたオープンスタンダード

2. データの完全性

  • ハッシュベースの検証 - すべてのファイルの完全性を確認可能
  • 変更の追跡 - すべての変更が記録される
  • 破損の検出 - チェックサムによる自動検証

3. 柔軟性

  • ストレージ非依存 - ローカルファイルシステム、S3、Glacierなど
  • アプリケーション非依存 - 特定のソフトウェアに縛られない
  • 移行の容易さ - 単純なファイルコピーで移行可能

4. 透明性

  • 人間が読める - JSONファイルを直接確認可能
  • 監査可能 - すべての履歴が明示的
  • デバッグしやすい - 問題の特定と修正が容易

OCFLの使用シーン

適している用途

  • デジタルアーカイブ - 文化遺産のデジタル化
  • 研究データ管理 - 学術研究データの長期保存
  • コンプライアンス - 法的要件に基づくデータ保存
  • 機関リポジトリ - 大学や研究機関の出版物管理

適していない用途

  • 頻繁な更新 - リアルタイムなデータ変更
  • 協調編集 - 複数人による同時編集
  • ブランチ管理 - 並行開発ワークフロー
  • 一時的なデータ - 短期間だけ必要なデータ

実践のポイント

1. オブジェクトの設計

OCFLオブジェクトは、論理的にまとまったデータの集合 として設計します：

  • 良い例 : 1つの書籍とそのメタデータ、画像
  • 悪い例 : 関連のない複数のファイルを1つのオブジェクトに

2. バージョニングの戦略

バージョンを作成するタイミング：

  • 意味のある変更があった時
  • 公開やリリースのタイミング
  • 定期的なスナップショット

3. ダイジェストアルゴリズムの選択

  • SHA-512 - 推奨（デフォルト）
  • SHA-256 - 代替オプション
  • MD5 - 非推奨（セキュリティ上の問題）

4. ストレージの検討

  • クラウドストレージ - S3、Azure Blob、Google Cloud Storage
  • テープストレージ - 大容量の長期保存
  • 分散ストレージ - 地理的冗長性の確保

まとめ

OCFLは、デジタル情報の長期保存のための実用的で強力なソリューションです。以下の特徴により、図書館、アーカイブ、研究機関にとって理想的な選択肢となっています：

  • シンプルさ - 複雑なツールに依存しない
  • 透明性 - すべてが人間に読める形式
  • 持続可能性 - 数十年後も読める設計
  • 柔軟性 - 様々なストレージに対応

本リポジトリの実装例を通じて、OCFLの基本的な概念と実践方法を理解していただけたと思います。デジタル保存の課題に直面している方は、ぜひOCFLの導入を検討してみてください。

参考リンク

付録: 用語集

  • OCFL Object（OCFLオブジェクト） - 一意のIDを持つデジタルコンテンツの集合
  • Inventory（インベントリ） - オブジェクトの履歴と状態を記録したJSONファイル
  • Manifest（マニフェスト） - ファイルのダイジェスト値と物理パスの対応表
  • Version（バージョン） - オブジェクトの特定時点での状態
  • State（状態） - あるバージョンにおける論理ファイルパスの集合
  • Digest（ダイジェスト） - ファイルのハッシュ値（整合性検証用）
  • Content Directory（コンテンツディレクトリ） - 実際のファイルが保存されるディレクトリ
  • Deduplication（重複排除） - 同一内容のファイルを1つの物理ファイルとして保存する仕組み