PREMIS における UUID と SHA-256 の使い分け — objectIdentifier と fixity が別の欄に置かれている理由

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

「UUID と SHA-256 は何が違うのか」「UUID や SHA-256 を使えば、何でも一意に識別できるのか」という問いは、どちらも一般論として答えると曖昧になりがちです。ここでは PREMIS（Preservation Metadata: Implementation Strategies、デジタル保存のためのメタデータ標準）の Data Dictionary と、それを実装しているシステムが実際に書き出すファイルを見ながら整理します。抽象的な比較よりも、実運用の標準がどちらをどこに置いているかを見たほうが、役割の違いがはっきりするためです。

参照する一次資料は次の通りです。

PREMIS Data Dictionary for Preservation Metadata, version 3.0（June 2015 – Revised November 2015、PREMIS Editorial Committee）
Archivematica 1.18 のドキュメント、および artefactual/archivematica のソースコード（qa/1.x ブランチ）
E-ARK（European Archival Records and Knowledge Preservation）の CITS（Content Information Type Specification、コンテンツ種別ごとの仕様）Preservation Metadata v1.0.0（2021-08-31、DILCIS Board（Digital Information LifeCycle Interoperability Standards Board））
Library of Congress の統制語彙（id.loc.gov）

二つの問いは、PREMIS の別々の欄に置かれている

先に PREMIS の前提を二つだけ確認します。

一つは、PREMIS が Object を 4 つのレベルで捉えることです。知的実体（Intellectual Entity、一つの資料としてのまとまり）、表現（Representation、その資料を構成するファイル一式。オリジナル一式と保存用一式は別の表現になります）、ファイル、ビットストリーム（ファイル内の一部分）の 4 つで、下に行くほど具体的な単位になります。

もう一つは、Data Dictionary の書式です。この文書は semantic unit（意味の単位。XML では要素として現れます）ごとに、Definition・Rationale・Obligation（義務）・Repeatability（反復可能性）・Applicability（どのレベルに適用されるか）・Data constraint・Usage notes といった定型の欄を持つ表になっています。以下で「義務は Mandatory」のように書くのは、この欄の値のことです。

そのうえで本題です。PREMIS の Object エンティティには、識別子を書く欄とチェックサムを書く欄が別々に用意されています。これは「同じことを二通りで書ける」のではなく、答えている問いが違うためです。

Data Dictionary の 1.1 objectIdentifier は、次のように定義されています。

A designation used to identify the Object uniquely within the preservation repository system in which it is stored.

義務は Mandatory、反復は Repeatable で、4 つのレベルすべてに適用されます。反復可能である理由は Usage notes に明記されていて、リポジトリが付与した識別子と外部で付与された識別子の両方を記録できるようにするためです。

一方 1.5.2 fixity の定義はこうです。

Information used to verify whether an object has been altered in an undocumented or unauthorized way.

こちらは義務が Optional で、適用範囲がファイルとビットストリームに限られます。知的実体と表現には「Not applicable」と明示されています。ただし fixity を置く場合、その中の messageDigestAlgorithm と messageDigest は Mandatory です。これは Data Dictionary の凡例にある一般規則で、任意の入れ物の中にある必須の要素は、その入れ物が存在するときに限り必須になります。任意なのは「チェックサムを書くかどうか」であって、書くと決めたら中身は揃っていなければならない、という構造です。

表現レベルに適用されない理由も Usage notes に説明があります。表現が単一ファイルからなる場合や、複数ファイルを zip でまとめた場合は、表現に対して fixity チェックができるように見えます。しかし実際にチェックしているのはそのファイルであって、たまたまファイルと表現が一致しているだけだ、という整理です。

なお同じ箇所で、用語についての注意も添えられています。

(Note that the terms "message digest" and "checksum" are commonly used interchangeably. However, the term "checksum" is more correctly used for the product of a cyclical redundancy check (CRC), whereas the term "message digest" refers to the result of a cryptographic hash function, which is what is referred to here.)

日本語では「チェックサム」で通してしまうことが多いのですが、PREMIS の semantic unit 名が messageDigest である背景はここにあります。

Archivematica が書き出す METS を読む

抽象的な定義だけでは使い分けが見えにくいので、実装が書き出す実物を見ます。Archivematica はオープンソースのデジタル保存システムで、AIP（Archival Information Package、保存用情報パッケージ）のメタデータを METS（Metadata Encoding & Transmission Standard）に PREMIS を埋め込む形で出力します。METS には記述メタデータ用の dmdSec と、技術メタデータ用の techMD などの区画があり、PREMIS の Object はそこに入ります。

以下はいずれも Archivematica 1.18 のドキュメントに掲載されている例で、論旨に関係しない名前空間宣言や空要素は省いた抜粋です。まず知的実体レベルの dmdSec から見ます。

<premis:object xsi:type="premis:intellectualEntity" version="3.0">
  <premis:objectIdentifier>
    <premis:objectIdentifierType>UUID</premis:objectIdentifierType>
    <premis:objectIdentifierValue>6a82ffa2-91e2-48e1-b0d0-55b0de21568e</premis:objectIdentifierValue>
  </premis:objectIdentifier>
  <premis:objectIdentifier>
    <premis:objectIdentifierType>ULID</premis:objectIdentifierType>
    <premis:objectIdentifierValue>01D9T8MJM9NEQ390H239VT50CQ</premis:objectIdentifierValue>
  </premis:objectIdentifier>
  <premis:objectIdentifier>
    <premis:objectIdentifierType>EXID</premis:objectIdentifierType>
    <premis:objectIdentifierValue>https://example.com/AIP/id/1348554167</premis:objectIdentifierValue>
  </premis:objectIdentifier>
  <premis:originalName>demo-1-6a82ffa2-91e2-48e1-b0d0-55b0de21568e</premis:originalName>
</premis:object>

同じ一つの知的実体に、3 つの識別子が並んでいます。UUID と ULID（Universally Unique Lexicographically Sortable Identifier、生成時刻の順に並ぶ識別子）はどちらもリポジトリ側が付けたもので、EXID が外部の識別子にあたります。Usage notes が挙げる「内部と外部の併記」に加えて、内部でも複数の体系を持たせている形です。ここには fixity がありません。知的実体には適用されないという規定通りです。

次にファイルレベルの techMD です。

<premis:object xsi:type="premis:file" version="3.0">
  <premis:objectIdentifier>
    <premis:objectIdentifierType>UUID</premis:objectIdentifierType>
    <premis:objectIdentifierValue>d8717b3a-d12c-408a-9c37-732425331f44</premis:objectIdentifierValue>
  </premis:objectIdentifier>
  <premis:objectCharacteristics>
    <premis:compositionLevel>0</premis:compositionLevel>
    <premis:fixity>
      <premis:messageDigestAlgorithm>sha256</premis:messageDigestAlgorithm>
      <premis:messageDigest>1cad1038c85dde1d018116c15fd32d2dac34d645b548611eb042f37169fcdee0</premis:messageDigest>
    </premis:fixity>
    <premis:size>47941948</premis:size>
    <premis:format>
      <premis:formatDesignation>
        <premis:formatName>Tagged Image File Format</premis:formatName>
      </premis:formatDesignation>
    </premis:format>
  </premis:objectCharacteristics>
  <premis:originalName>%SIPDirectory%objects/View_from_lookout_over_Queenstown_towards_the_Remarkables_in_spring-d8717b3a-d12c-408a-9c37-732425331f44.tif</premis:originalName>
</premis:object>

ここで初めて UUID と SHA-256 が同じ Object の中に同居します。UUID はこのファイルがどれであるかを指し、SHA-256 はその中身が変わっていないことを後から検証するために置かれています。originalName にも UUID が埋め込まれていて、ファイル名を通じても識別子が持ち回されていることが分かります。

なお、このオブジェクトは受け入れたままのファイルではなく、保存用に正規化された側です。同じドキュメントの続きにこのファイルが別のオブジェクトを「source」として名指しする記述があり（後述）、fileSec の USE="original" に入っているのは別の UUID を持つ JPEG のほうだからです。ファイル名の末尾に UUID が付いているのも、正規化で作られたファイルの命名です。

Archivematica のドキュメントでは、チェックサムのアルゴリズムは MD5・SHA-1・SHA-256・SHA-512 から選べると説明されています。

You can select which checksum algorithm Archivematica will use during the Assign UUIDs and checksums microservice in Transfer. Choose between MD5, SHA-1, SHA-256 and SHA-512.

既定値はドキュメント上では明示されていないようですが、ソースコードでは次のように定義されています（src/archivematica/MCPClient/settings/common.py）。

DEFAULT_CHECKSUM_ALGORITHM = "sha256"

fixity チェックは Object ではなく Event として記録される

もう一つ、PREMIS の設計として押さえておきたいのは、チェックを「実行した事実」がどこに書かれるかです。Data Dictionary の Usage notes には次のようにあります。

The act of performing a fixity check and the date it occurred would be recorded as an Event. The result of the check would be recorded as the eventOutcome. Therefore, only the messageDigestAlgorithm and messageDigest need to be recorded as objectCharacteristics for future comparison.

つまり Object に置くのは「比較のための値」だけで、いつ照合して結果がどうだったかは Event 側に積み上がっていきます。Archivematica のドキュメントにある fixity チェックの Event 例が分かりやすいです。

<premis:event version="3.0">
  <premis:eventIdentifier>
    <premis:eventIdentifierType>UUID</premis:eventIdentifierType>
    <premis:eventIdentifierValue>8c6714b3-ab18-44e2-8507-80691ad1dafa</premis:eventIdentifierValue>
  </premis:eventIdentifier>
  <premis:eventType>fixity check</premis:eventType>
  <premis:eventDateTime>2019-11-14T11:00:50.632264+00:00</premis:eventDateTime>
  <premis:eventDetailInformation>
    <premis:eventDetail>program="sha512sum -c --strict .../metadata/checksum.sha512"; version="sha512sum (GNU coreutils) 8.28"</premis:eventDetail>
  </premis:eventDetailInformation>
  <premis:eventOutcomeInformation>
    <premis:eventOutcome>pass</premis:eventOutcome>
  </premis:eventOutcomeInformation>
</premis:event>

Event の識別子にも UUID が使われています。eventType の fixity check は Library of Congress の統制語彙にある用語で、同じ語彙には message digest calculation（digest の計算そのもの）も別項目として登録されています。調べた限り、この eventType 語彙は全 50 語です。

この例で興味深いのは、ファイルレベルの fixity が sha256 なのに対し、この Event は sha512sum を実行している点です。参照先の metadata/checksum.sha512 は、提出者が transfer に同梱したチェックサムファイルです。Archivematica のドキュメントは、外部で作成された MD5・SHA1・SHA256・SHA512 のチェックサムを Verify transfer checksums マイクロサービスで照合すると説明していて、ソース（clientScripts/verify_checksum.py）の説明文も「transfer の metadata フォルダに置かれた checksum.md5 のような、システムに提供されたチェックサムを検証する」となっています。つまり両者の違いは検証の粒度ではなく、digest を誰が計算したかという出所です。Data Dictionary の特別トピックにも、複数のアルゴリズムを併用することへの言及があります。

In fact, it is common to create and test two or more message digests using different algorithms to be certain that an object is fixed.

fixity が Repeatable であることとも対応しています。

正規化するとハッシュは変わる。つないでいるのは識別子のほう

デジタル保存では、受け入れたファイルを長期保存に適した形式へ変換する正規化（normalization）を行うことがあります。このとき、バイト列が変わるので messageDigest は必ず別の値になります。

先ほどのファイルレベルの例には、続きとして relationship が入っています。

<premis:relationship>
  <premis:relationshipType>derivation</premis:relationshipType>
  <premis:relationshipSubType>has source</premis:relationshipSubType>
  <premis:relatedObjectIdentifier>
    <premis:relatedObjectIdentifierType>UUID</premis:relatedObjectIdentifierType>
    <premis:relatedObjectIdentifierValue>d0c46bbb-63b1-4530-ad1f-f65d9a32e434</premis:relatedObjectIdentifierValue>
  </premis:relatedObjectIdentifier>
  <premis:relatedEventIdentifier>
    <premis:relatedEventIdentifierType>UUID</premis:relatedEventIdentifierType>
    <premis:relatedEventIdentifierValue>d7746761-d98c-4a78-80e0-2e91e4c187d4</premis:relatedEventIdentifierValue>
  </premis:relatedEventIdentifier>
</premis:relationship>

正規化で作られたファイル（d8717b3a…）が、元のファイル（d0c46bbb…）を has source として名指しています。二つを結びつけているのはハッシュではなく relatedObjectIdentifier の識別子です。さらに relatedEventIdentifier で、その派生を生んだ Event（変換処理）も指しています。

ここが「ハッシュだけでは同一性を扱えない」ことの具体的な現れだと思います。ハッシュが一致しないという事実は「別のバイト列である」以上のことを語りません。同じ資料の別の姿だと言えるのは、識別子で相手を名指しした関係が別途記録されているからです。逆に、ハッシュが一致することも（後述の意図的な衝突がないかぎり）「同じバイト列である」以上のことは語りません。たとえば同一の PDF を二つの資料群にそれぞれ受け入れれば、二つの Object の digest は同じ値になりますが、識別子は別々に振られます。極端な例では、空ファイル同士も同じアルゴリズムなら常に同じ digest になります。

E-ARK の仕様にも同じ構造がある

Archivematica 固有の設計ではないことを確かめるため、欧州の E-ARK 系の仕様も見ておきます。DILCIS Board の CITS Preservation Metadata v1.0.0 は、E-ARK パッケージにおける PREMIS の使い方を定めたものです。

識別子については、local 型を使う場合はその値が PREMIS 文書内およびリポジトリ内で一意であるべきとし（PREMIS-ID-LOCAL）、objectIdentifier 要素を繰り返して他の型を追加してよいとしています（PREMIS-ID-OTHER）。掲載されている例は次の 3 つです。

<objectIdentifier>
  <objectIdentifierType>local</objectIdentifierType>
  <objectIdentifierValue>fileId001</objectIdentifierValue>
</objectIdentifier>
<objectIdentifier>
  <objectIdentifierType>UUID</objectIdentifierType>
  <objectIdentifierValue>5707ecac-6713-41b5-826a-3388e21c4c2f</objectIdentifierValue>
</objectIdentifier>
<objectIdentifier>
  <objectIdentifierType>filepath</objectIdentifierType>
  <objectIdentifierValue>metadata/file.xml</objectIdentifierValue>
</objectIdentifier>

チェックサムについては SHA-256 を推奨としています。

PREMIS-CHECKSUMS: Checksums SHOULD be provided as a descendant of the "objectCharacteristics" element information in the form of the recommended SHA-256 hashsum, a fixed size 256-bit value.

例では messageDigestOriginator に /usr/bin/sha256sum が入っていて、どのエージェントが最初の digest を計算したかを記録する使い方が示されています。この semantic unit の Rationale は、提出者が計算した digest を検証すれば送信前後で同一であることを確認でき、digest が付いていない場合はリポジトリ側が計算することになるため、どちらが計算した値なのかを知ることに意味がある、というものです。先ほど Archivematica の Event で見た「提出者のチェックサムを照合する」という処理は、まさにこの Rationale が想定している場面にあたります。

Archivematica の実装と CITS の仕様は別々に作られたものですが、識別子を複数持たせる点と、fixity に SHA-256 を使う点は共通しています。

「何でも一意に識別できるか」を数値で見る

役割分担が分かったところで、冒頭のもう一つの問いに戻ります。UUID も digest も有限のビット列なので、個数が増えれば値の重複は避けられません。ただし理由の立て方は両者で違います。ハッシュ関数は入力の空間が出力より広い写像なので、鳩の巣原理（n 個の入れ物に n+1 個を入れれば必ずどこかが重複する）から衝突は必ず存在します。UUID は入力から導出するのではなく乱数を発行する方式なので、衝突は「必ず存在する」ではなく確率の問題として残ります。

実務上どれくらい遠いのかを、誕生日限界（衝突確率が 50% に達する個数、おおよそ 1.1774 × √(2^bits)）で見ます。

偶然の衝突が 50% に達する個数を対数軸の棒グラフで示した図。UUIDv4（乱数 122 ビット）は 2.7 × 10 の 18 乗個、MD5（128 ビット）は 2.2 × 10 の 19 乗個、SHA-1（160 ビット）は 1.4 × 10 の 24 乗個、SHA-256（256 ビット）は 4.0 × 10 の 38 乗個。横軸は対数のため棒の長さは桁数を表し比ではないことが注記されている。下部に「SHA-1 は偶然を待つまでもなく、2017 年に意図的な衝突が実際に作られている」と記載

対象	ビット数	衝突確率 50% に達する個数
UUIDv4	122（乱数部）	約 2.7 × 10¹⁸
MD5	128	約 2.2 × 10¹⁹
SHA-1	160	約 1.4 × 10²⁴
SHA-256	256	約 4.0 × 10³⁸

なお誕生日限界は「集合の中に重複があるか」を測る指標なので、識別子の一意性にはそのまま当てはまりますが、fixity のほうは「壊れた 1 個のファイルが元と同じ digest になるか」という 1 回の比較が問題です。ここでは桁の感覚をつかむための共通の物差しとして並べています。

UUIDv4 の乱数部が 122 ビットであることは RFC 9562（2024 年 5 月、RFC 4122 を廃止）に規定されています。1 兆個（10¹²）の UUIDv4 を生成した場合、少なくとも 1 回衝突する確率は概算で 9.4 × 10^-14 ほどで、リポジトリの規模で問題になる水準ではありません。RFC 9562 自体は絶対的な一意性を保証する書き方をしておらず、実装者は自分のアプリケーションにおける衝突の影響を検討すべきだ、という書き方をしています。

一方、偶然の衝突とは別に、意図的に衝突を作れるかという問題があります。SHA-1 は 2017 年 2 月 23 日に CWI Amsterdam と Google の研究者によって実際の衝突が公表されました（SHAttered）。同じ SHA-1 値 38762cf7f55934b34d179ae6a4c80cadccbb7f0a を持つ、内容の異なる 2 つの PDF が示されています。偶然の衝突が期待される個数は 10²⁴ のオーダーですが、意図的に作る場合はそれよりはるかに少ない計算量で到達できます。先ほど「ハッシュが一致すれば同じバイト列」と書きましたが、衝突を作れるアルゴリズムではこの前提自体が成り立ちません。SHA-256 について同種の攻撃は現時点では知られていないようです。

保存用途で重要なのは、fixity の目的が「意図せぬ改変の検出」であって、悪意ある改竄への耐性はまた別の要求だという点です。ビット腐敗（保存媒体の経年で一部のビットが化ける現象）やコピー時の破損を見つけるだけなら MD5 でも実用上は機能しますが、改竄検知まで含めるなら SHA-256 以上を選ぶ運用が多いようです。BagIt（ファイル群をマニフェスト付きでまとめるパッケージ形式）の RFC 8493（2018 年 10 月）も、ツールは SHA-256 と SHA-512 をサポートしなければならず、新規の bag では SHA-512 を既定で有効にすべきとしたうえで、MD5 と SHA-1 は後方互換性のためにサポートすべき、という書き方をしています。

実装ごとに値の書き方がずれる

実装を横に並べると、値の書き方が揃っていないことに気づきます。

messageDigestAlgorithm について、Data Dictionary は Library of Congress の統制語彙から値を取ることを求めています（Data constraint は "should"）。この語彙 cryptographicHashFunctions を実際に取得すると、収録されているのは取得時点で 13 語で、authoritative label と code は次のようになっています。

code	label
`adler`	Adler-32
`crc32`	CRC32
`haval`	HAVAL
`md2`	MD2
`md5`	MD5
`mnp`	MNP
`sha1`	SHA-1
`sha256`	SHA-256
`sha384`	SHA-384
`sha512`	SHA-512
`tiger`	TIGER
`unk`	unknown
`whirl`	Whirlpool

語彙名は cryptographicHashFunctions ですが、中身には CRC32 や Adler-32 のような暗号学的ハッシュではないものも含まれています。先ほどの「message digest と checksum は違う」という注意書きと、この語彙の中身は完全には対応していません。取得したデータに含まれる changeset を見る限り、2010 年に作成され、2012 年と 2018 年 9 月に更新されたようです。SHA-3 系や BLAKE2 / BLAKE3 を値として使う場合は、語彙の外の値になります。

そのうえで実装を見ると、Archivematica は sha256（code 側の表記）、CITS の例は SHA-256（label 側の表記）、Data Dictionary の Examples も SHA-256 です。どちらも語彙の範囲内ではあるものの、文字列として突き合わせると一致しません。複数のリポジトリから PREMIS を集約する場合、この程度のゆらぎは正規化してから比較する必要があります。

識別子の型についても同様です。objectIdentifierType の Data constraint は http://id.loc.gov/vocabulary/identifiers.html を参照するよう求めていますが、この語彙を取得すると 232 語あり、その中に uuid は見当たりませんでした（local「Locally defined identifier」や doi hdl ark urn などは収録されています）。Archivematica も CITS も UUID という値をそのまま使っていますが、これは語彙外の値ということになります。

もっとも Data Dictionary 側も、識別子の型はリポジトリ内で暗黙でもよく、外部に出すときに明示できればよい、という書き方をしています。

The type of the identifier may be implicit within the repository as long it is can be explicitly communicated when the digital object is disseminated outside of it.

CITS も、識別子の型の扱いは実装ごとの問題であり、型の語彙を推奨も要求もしないと明記しています。厳密な統制を要求しているわけではないので、実装が独自の型名を使うこと自体は想定の範囲内だと読めます。ただ、機械的に突き合わせるつもりなら、事前に確認しておく箇所です。

なお PREMIS 3.0 の本文中で「UUID」という語が現れるのは、調べた限り 1 箇所だけで、eventIdentifierType の Examples に FDA Stanford Repository Event ID UUID local と並んでいる箇所です。UUID を使うことは PREMIS の要求ではなく、実装側の選択だということが分かります。

fixity が保証しないもの

最後に、PREMIS の特別トピック「Fixity, integrity, authenticity」の整理を引いておきます。ここでは 3 つが明確に区別されています。

While this procedure can indicate with some confidence that an object has not changed over time, it does not address the object's integrity or authenticity.

fixity チェックが言えるのは「ある時点から変わっていない」ことだけです。整合性（integrity）については、フォーマットの識別と検証が鍵になるとして JHOVE（JSTOR/Harvard Object Validation Environment、フォーマット検証ツール）のようなツールが挙げられ、これも Event として記録されます。真正性（authenticity）については、最終的には人間の判断の問題であり、そのための証拠として来歴（provenance）の記録、提出時とビット単位で同一のコピーの保存、重要な特性の保持、電子署名などが必要になる、と述べられています。

digest を保存しておくことは、真正性を支える一連の記録のうちの一部を担うにすぎません。「SHA-256 を記録してあるから真正である」とは言えず、それを誰がいつ計算し、その後どの Event を経てきたかという記録と組み合わせて初めて意味を持つ、という構成になっています。

整理

	UUID（objectIdentifier）	SHA-256（fixity / messageDigest）
答える問い	これはどのモノか	この中身は変わっていないか
値の決まり方	発行する（UUIDv4 は乱数）	内容から導出する（決定論的）
内容との関係	無関係。中身が変わっても同じ	1 バイト変われば別の値
PREMIS での義務	Mandatory	Optional（置くなら中身は Mandatory）
PREMIS での適用範囲	知的実体・表現・ファイル・ビットストリーム	ファイル・ビットストリームのみ
反復	可（複数の識別子体系を併記）	可（複数アルゴリズムを併記）
実装例での値	`UUID` / `ULID` / `EXID` / `local` / `filepath`	`sha256` / `SHA-256`

冒頭の「何でも一意に識別できるか」については、数学的には有限なので衝突は避けられず、実用上は桁が離れているので問題にならず、運用上は別の理由で破綻しうる、という三層で考えるのが実際的だと思います。三つ目が一番厄介で、正規化のたびに digest が変わる、実装ごとにアルゴリズム名の表記が揃わない、識別子の型名が参照先の語彙から外れる、といった事象はいずれも確率の問題ではありません。PREMIS が識別子を反復可能にし、relationship と Event を別に用意していることは、結果としてこの層の問題に効いている、という見方もできます。

🧾PREMIS における UUID と SHA-256 の使い分け — objectIdentifier と fixity が別の欄に置かれている理由

二つの問いは、PREMIS の別々の欄に置かれている

Archivematica が書き出す METS を読む

fixity チェックは Object ではなく Event として記録される

正規化するとハッシュは変わる。つないでいるのは識別子のほう

E-ARK の仕様にも同じ構造がある

「何でも一意に識別できるか」を数値で見る

実装ごとに値の書き方がずれる

fixity が保証しないもの

整理

参照した資料

📚METSFlaskを試す

📥DataAccessioner：受入時点でチェックサムと技術メタデータを固定するツール

🏫学認のメタデータを開いて読む ── SAML フェデレーションの中身を実データで確かめる

コメント

二つの問いは、PREMIS の別々の欄に置かれている

Archivematica が書き出す METS を読む

fixity チェックは Object ではなく Event として記録される

正規化するとハッシュは変わる。つないでいるのは識別子のほう

E-ARK の仕様にも同じ構造がある

「何でも一意に識別できるか」を数値で見る

実装ごとに値の書き方がずれる

fixity が保証しないもの

整理

参照した資料

関連記事

📚METSFlaskを試す

📥DataAccessioner：受入時点でチェックサムと技術メタデータを固定するツール

🏫学認のメタデータを開いて読む ── SAML フェデレーションの中身を実データで確かめる

コメント