本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。

概要

born-digital 資料を長期保存するワークフローでは、ファイルを保存パッケージ （SIP / AIP）にする前に、移管されてきた状態をいったん記録する工程があります。 OAIS（Open Archival Information System）やアーカイブ実務で アクセッション（accessioning、受入）と呼ばれる段階です。

DataAccessioner は、この受入の 段階で、メディアやフォルダから安全にファイルを移送しつつ、各ファイルの チェックサムと技術メタデータを取得して記録するデスクトップツールです。本記事では、 このツールが何をするのか、なぜ「SIP を作る前」というタイミングが意味を持つのか、 そして自分が触っている SIP 作成ツールとどう役割が分かれるのかを整理します。

ワークフロー上の位置づけ

デジタル保存の典型的な流れは次のようになります。受入（accessioning）は配列より 前にあり、DataAccessioner はこの段階を、Archivematica は配列より後の ingest 以降を 担当します。

デジタル保存ワークフローにおける受入（accessioning）の位置

編成（配列）のステップでは、archivist が受け取ったファイル群を意味のある階層に 並べ替えます。このとき、元のフォルダ構造（before）と並べ替えた後の構造（after）の 対応関係を残しておかないと、「このファイルは元はどこにあったか」を後から辿れません。

配列後の構造は SIP / AIP の側に記録されますが、配列前の状態は、受入の段階で 固定しておかないと下流では復元しにくい、という性質があります。DataAccessioner は この受入時点のスナップショットを担当するツールと位置づけられます。

DataAccessioner とは

調査した限りでは、以下のようなツールです。

  • 最初のバージョンは 2008 年に Duke University Archives で Seth Shaw 氏が作成。 その後 Digital POWRR プロジェクトの支援でオープンソース化され、現在は digitalpowrr/DataAccessioner で維持されています（Seth Shaw 氏・Scott Prater 氏らが貢献）。
  • 公開されている範囲では、最新は v1.2（2024 年 2 月 17 日リリース）です。
  • Java / Swing 製の GUI アプリで、コマンドラインなしでフォルダやメディアから ファイルサーバへの移送を行えます。
  • 移送の際に FITS（File Information Tool Set）を ラップし、各ファイルのフォーマット同定と技術メタデータを取得します。

GUI で完結する点が特徴で、リソースの限られた小規模機関でも受入記録を作れる、 という Digital POWRR の趣旨に沿った設計になっています。FITS を直接扱うより敷居が 低く、「フォルダを選んで実行する」操作に落とし込まれています。

何を取得・出力するか

ドキュメントや解説を確認した範囲では、次のような動作です。

  • フィクシティ（同一性）: コピーの前後で各ファイルの MD5 チェックサムを計算し、 両者を比較して転送エラーを検出します。MD5 は元ファイルとコピー先の双方について 作られます。
  • メタデータ抽出: FITS で各ファイルからメタデータを抽出し、結果を XML として 保存します。メタデータ管理側で、既定では FITS の出力を PREMIS（Preservation Metadata: Implementation Strategies、v2.2）形式に変換します。この変換は XSLT を 差し替えて変更できます。
  • レポート: ディレクトリパス、ファイル名、最終更新日時、サイズ（バイト）、MD5、 ファイルフォーマットといった項目を含みます。別配布の Metadata Transformation ツール（XSLT プロセッサ）で、この一部をスプレッドシートや HTML に変換できます。

つまり、フォルダやメディアを取り込むと、ファイルごとに 「元パス＋ MD5 ＋技術メタデータ」を 1 つの XML に集約し、受入記録として固定する、 という道具です。

近接するツールとの関係

受入時点で同一性とメタデータを取得して記録する、という役割で見ると、近接する ツールがいくつかあります。

ツール役割補足
DataAccessioner受入時に FITS で技術メタ＋MD5 を取得し XML に固定Digital POWRR が維持。Java / Swing
Exactly（AVP ＋ケンタッキー大 Nunn Center）BagIt ＋MD5 マニフェストで取得時にプロヴェナンス／フィクシティを確立概念参照向き。現在の保守・入手性は未確認
Archivematicaingest 以降の SIP→AIP 変換、METS / PREMIS 生成受入「後」のワークフロー

DataAccessioner と Archivematica は時間軸で役割が分かれています。前者は配列前の 受入記録を固定し、後者は配列後を SIP / AIP として保存形式に固める、という分担です。

採用を検討する際に見ておく点

  • 公開されている範囲では v1.2（2024 年 2 月）が最新で、GitHub の star は十数程度です。 更新の頻度はそれほど高くないようなので、現行の維持状況は導入前に確認しておくと よさそうです。
  • 実行に Java ランタイムが必要です。
  • チェックサムは MD5 です。受入時のエラー検出という用途では実用上の問題は小さい ようですが、新規に同一性アンカーを設計するなら SHA-256 を選ぶ場面もあります。

概念とフォーマットの参照実装として参照する価値が高い一方、そのまま本番ワークフローに 長期的に組み込むかは、機関の事情に応じて判断することになりそうです。

自分の SIP 作成ツールとの棲み分け

別途、軽量な SIP 作成ツールを触っている文脈で、「DataAccessioner 相当の機能を 自前で持つべきか」を検討しました。現時点での整理を共有します。

まず、METS の structMap を自前生成する必要はなさそうだ、という点です。Archivematica が 配列前後の構造を保持するのに structMap を使っているのはその実装の都合であって、 before↔after の対応に必要な情報は、各ファイルの「元パス＋同一性（ハッシュ）」に 集約できます。structMap や PREMIS の生成は下流の ingest に任せ、受入側でフルの METS を 出力するのは過剰になりがちです。

一方で見落としやすいのは、多くの SIP 作成ツールが「渡された 1 時点のフォルダを パッケージするだけ」で、配列前と配列後という区別を持たない点です。Finder などで 先に配列を済ませてからツールに渡すと、ツールは配列後しか見ないため、配列前の構造が 記録されません。

DataAccessioner が示しているのは、ここを埋める順序です。

  1. 配列前に一度走らせ、各ファイルの元パス＋チェックサム（＋任意で技術メタデータ）を 受入記録として固定する。
  2. その後、配列して SIP 化する。
  3. 両者をハッシュで突合して before↔after を辿る。

ハッシュで配列前後（before↔after）を突合する

自分のツールに当てはめると、すでに出力している checksum.sha256（同一性）と DFXML（Digital Forensics XML、パス情報）に、元パスを束ねた受入スナップショットを 足すことで、DataAccessioner の核心部分は表現できそうです。フル FITS や METS を 再実装しなくても、「下流では取り戻しにくい配列前の状態を固定する」という役割は 担えます。自分のツールでは、この方針（受入時点のスナップショットを残し、structMap 生成は下流に委ねる）を採用しています。

まとめにかえて

DataAccessioner は、配列や SIP 化の前に、MD5 と FITS による技術メタデータを取得して 受入を記録するためのデスクトップツールです。Archivematica とは時間軸で役割が分かれ、 受入の段階を担います。公開されている範囲では更新頻度は高くなく、チェックサムは MD5 ベースなので、概念とフォーマットの参照実装として捉えるのが扱いやすそうです。 自前ツールに取り込む場合も、フルの METS / FITS ではなく「元パス＋ SHA-256 の受入 スナップショット」で核心は再現できる、というのが現時点での見立てです。

参考