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.
>>