 |
 |
If you want to use checksums to show fixity of files, then changing the files is incompatible with that. You may want to show that a file did not change during transfer or ingest by calculating a checksum before it is moved to the repository and again after it was ingested. Then you could say that so long as the checksum doesn't change while the file is in the repository, or maybe when it is transferred out of the repository as part of a SIP, the file hasn't changed. If you want this kind of fixity information, you can't change the file itself. Instead you could either store the cover sheet separately from the file, but within the same AIP, or create a derived file with the cover sheet (and keep the original) and log the process steps (i.e. how the files relate). These ways could help demonstrate that you took care of the archival material and keep a provenance trail. Regards, Ben Ben Companjen Information scientist [log in to unmask] +31 6 1334 9717 Skype: bencompanjen Data Archiving and Networked Services (DANS) DANS promotes sustained access to digital research data. See www.dans.knaw.nl <http://www.dans.knaw.nl/> for more information and contact details. DANS is an institute of KNAW and NWO. DANS | Anna van Saksenlaan 51 | 2593 HW The Hague | P.O. Box 93067 | 2509 AB The Hague | +31 70 349 44 50 | [log in to unmask] | www.dans.knaw.nl <http://www.dans.knaw.nl/> On 14-04-14 04:57, "Kyle Banerjee" <[log in to unmask]> wrote: >This is where the difference between access objects and archival objects >is >relevant. Practices involving modification of archival objects in ways >like >this strike me as unfortunate. It is a nonissue with access objects. > >Having said that, checksums introduce some challenges. For example, >embedded metadata cannot be modified. > >Kyle >On Apr 13, 2014 4:23 PM, "Bernadette Houghton" < >[log in to unmask]> wrote: > >> We are currently considering the issue of cover sheets for our >>repository, >> but these don't seem to be compatible with the use of checksums/fixity. >> >> Cover sheets may not necessarily be added at very first ingest into the >> repository, meaning that once they are, the checksum of the object will >> change. Maybe at some stage the cover sheet will be removed, for >>whatever >> reason; maybe down the track we'll want to change the coversheet. Lots >>of >> maybes here, all amounting to the fact that if we do use cover sheets, >> we'll no longer be able to rely on checksums to verify the integrity of >>an >> object. >> >> Has anybody else considered this issue? >> >> Bernadette Houghton >> Library Business Applications Developer >> Library >> [Title: Deakin University logo] >> Deakin University >> Locked Bag 20000, Geelong, VIC 3220 >> +61 3 52278230 >> >>[log in to unmask]<mailto:[log in to unmask] >>u >> > >> www.deakin.edu.au<http://www.deakin.edu.au/> >> Deakin University CRICOS Provider Code 00113B >> >> >> Important Notice: The contents of this email are intended solely for the >> named addressee and are confidential; any unauthorised use, >>reproduction or >> storage of the contents is expressly prohibited. If you have received >>this >> email in error, please delete it and any attachments immediately and >>advise >> the sender by return email or telephone. >> >> Deakin University does not warrant that this email and any attachments >>are >> error or virus free. >>