You have audited your digital content, established appropriate metadata schema, and vetted your new taxonomy. The DAM system is installed, customized, and tested. All you have to do is catalog assets. Right? Well, if digital preservation is high on your list of priorities, and it should be, you will also want to ensure assets remain “what they purport to be”. Your efforts will ensure asset authenticity and help your users trust the data you manage on their behalf.
One recent study found that many user groups are not conducting data reviews on ingest or at points throughout the lifecycle of their digital assets.
To manage and protect valuable digital files, shouldn’t we expect there to be mechanisms baked in to DAM systems to verify file integrity? Regrettably, most DAM systems lack this important ability. In fact some vendors were surprised and incredulous of the need for it when I reached them for comment. Really? Strange since DAM systems purport to be digital repositories, the very same described in the OAIS conceptual model. According to OAIS documentation Information Packages must be validated against a digital signature created prior to ingest and at points along an asset’s lifecycle. Furthermore the ability to perform data integrity checks out of the box seems to be a low-effort proposition: many free tools, such as Carbon Copy Cloner, have offered it for years. So I call on DAM system vendors to add this functional requirement to the next minor or major release of their products.
Authenticity can be established by judging an object’s identity, made up of such attributes as provenance, creation date, relationships to other assets, etc. This is all well and good for physical items, but in the digital realm, data can easily be changed or corrupted without affecting descriptive metadata or vice-versa. For example, it is difficult to tell whether “photo.psd” is the same file as “photo-copy.psd”. To solve this riddle, we must pay attention to a bitstream’s integrity, or completeness, over time. Digital preservationists have a yardstick for this called fixity.
Fixity is the static, invariable, and changeless state of a digital asset. There are several roles fixity checks play: to validate digital content preserved is what was intended to be preserved, to ensure a data transfer is indeed an exact “bit-for-bit copy” of its source, to actively monitor integrity of digital objects, to identify early signs of data rot, and to determine when a data change or loss event has occurred. Assessing fixity is an important responsibility we must bear to encourage users to trust the assets we manage. Fixity is contingent on hard evidence that comes in the form of a checksum.
The three most popular types of algorithms that produce checksums are MD5, SHA–1, and SHA–2. “Applying these algorithms to a file produces an (almost certainly) unique hash or checksum value and will consistently produce this value if a file is unchanged” (Austin, 2011, p. 5). Comparing these checksums, sometimes called hashcodes, can help asset managers deduplicate assets (Riecks, 2010. Some forward thinking DAM systems offer this function. None yet offer the ability to verify file integrity, in spite of calls for action. In principle these values must be stored separately from an asset: embedding the hashcode — or any other metadata — will change the file and invalidate the checksum. More on this later.
Metadata should travel with assets and embedding this information has worked very well so far. However, adding, editing and replacing embedded metadata affects the fixity of a whole file, defeating the purpose of fixity checking. Some have suggested generating intra-file fixity values, which can then be embedded as metadata into a file. This is where checksums are run on parts of the file instead of the whole: checks would be performed on each audio track, every video frame, or layer of a TIFF file. These values would remain unaffected when metadata is written back into the whole file. Alternately, adopting a wrapper-based media file format would also be feasible, such the MXF file format. This type of file contains the file essence(s) — video, audio, image — and a metadata record. This last option is only possible if your system supports read/write into these types of information packages. Barring these choices, there is a case to be made to store metadata separately from your digital assets as sidecar files. The essence (original bitstream) remains unchanged and auditable while the separate metadata record may be continuously updated.
Do you perform fixity checks on your data? If so, how? What are some of the challenges you face?