解決策
初期のウェブアーカイブは取得したページを保存できたが、再生や長期的な管理にはペイロードのバイト列以上のものが必要だった。クロールにはリクエストヘッダー、レスポンスヘッダー、タイムスタンプ、IPアドレス、ダイジェスト、メタデータ、そしてレコード間のリンクも必要だった。
WARCの設計は、そうした文脈を第一級の要素とした。この形式はWARCレコードの単純な連結であり、各レコードはコンテンツブロックの前に自身の型とヘッダーを宣言する。通常のHTTP素材を運ぶことも、保存データにリンクした任意のメタデータを運ぶこともできる。
WARC 1.1仕様によれば、この形式はウェブアーカイブを構造化・管理・保存し、圧縮と完全性を支え、HTTPやDNSなどのプロトコルからの制御情報を保存し、収集プロトコルからのすべての制御情報を記録するために設計された。
その採用は、旧来のARCの世界との後方互換性によって後押しされた。アーカイブは既存のクロールを放棄することなく、より豊かなレコードへ移行できた。
達成したこと
ファイルだけでなく、トランザクションをアーカイブする
うまくいった理由
ペイロードと取得時の文脈を一緒に保つことで、後の再生と監査が可能になった。
レコード型によって、1つのファイルにレスポンス、リクエスト、メタデータ、重複排除の参照を混在させることができた。
ダイジェストフィールドは、保存システムに組み込みの完全性の手がかりを与えた。
追記可能なストリームモデルは、クローラーが実際にウェブを収集する方法と合致していた。
応用できること
対象が文脈に依存するものであるなら、その周囲のトランザクションを保存せよ。メタデータの経路は、取得されたバイト列と同じくらい重要になり得る。
その後
WARCはウェブアーカイブの実用的なファイル形式となり、国立図書館、研究用クローラー、保存ツールによって使用された。それはクロールをページの山から、再生可能な証拠の連鎖へと変えた。
出典をたどる
出典
- The WARC Format 1.1 International Internet Preservation Consortium · iipc.github.io