 |
 |
WRT the first case, my take on this has been that TRAC was designed to examine functioning preservation systems, so it's not necessary to reconstruct them from the preservation metadata. Evaluation by TRAC should rely on an examination of processes/workflows to determine the contemporaneousness (contemporanaity?) of generated events, not a system generated time stamp which could presumably be subject to the same sorts of delays/subterfuge as writing the event in the first place. I can't really speak to your second example because I don't know your details, but I definitely see your point. How do you store the results of the fixity checks that are "in holding", so to speak? If it's a sufficiently long time in between when the check was done and when the event is written, I feel like you'd almost have to check them again. Maybe an eventDetail would work for system-specific details like this? I guess it is obvious from my response that we don't track this, so hopefully I don't come off as a total idiot here. It's really just that I am already seeing the eye-rolls at the thought of explaining to our programmers that we need both the timestamp of the event and the timestamp of the Event of the event. ;) Best, Steve On 11-07-05 2:12 PM, Priscilla Caplan wrote: > My understanding is that there is considerable use of the PREMIS Event > description. The semantic unit eventDateTime is defined as "The single > date and time, or date and time range, at or during which the event > occurred." I'm wondering if any of you have felt a need to also have a > timestamp indicating when the Event description was written. I can see > two use cases for this. > > The first case is widely applicable. Re-reading TRAC (Trustworthy > Repositories Audit and Certification), I noticed it gives a lot of > emphasis to records being contemporaneous. That would indicate that the > smaller the time between the event happening and the event record being > recorded the better. You could only tell, however, if there was an > indication of when the event record was written. > > The second case may only apply to us, I don't know. We store multiple > copies of our AIP, each considered a master, in different storage > pools. (We also take back-ups of our masters, but that's irrelevant to > this.) Programs continuously check the fixity of each storage pool, > so we know that every AIP in the pool is fixed. However, we only record > a fixity Event for the AIP when another program verifies that all master > copies of an AIP have been fixity checked successfully. The date of the > most recent check will vary from copy to copy, so we record in > eventDateTime the earliest of the dates, which is the most recent date > we can be sure all copies were good. That date can be days or even > weeks before the event record is written. > > Do any of you timestamp the time the event record is written, even > though there is no PREMIS element for it? > > Do any of you think an element for the timestamp of the recording of an > event would be useful? > > p -- Stephen Marks Digital Preservation Librarian Scholars Portal Ontario Council of University Libraries [log in to unmask] 416.946.0300