 |
 |
Hi Priscilla, FYI: in our case, the Archivematica system records the event data in real time upon the completion of all automated events. We actually log the time a task is assigned to a processor, the time that the task began and the time it was completed. The difference between the three is often just milliseconds. We use the task start time as the PREMIS event timestamp value. The one exception is when a user may opt to do a manual file format normalization outside of the Archivematica pipeline (now possible btw in 0.7.1-alpha). In that case there is a delay between the actual event and when the PREMIS event gets recorded. So I can see how it may be useful to have a second timestamp value to distinguish between the two to meet TRAC's requirement for contemporaneous logging. To be honest, however, we see this as a somewhat academic discussion right now. Do you think it would be sufficient (from a TRAC compliance standpoint) to have system documentation describing how and when event metadata are generated during SIP processing? Evelyn McLellan Archivematica Community Manager www.archivematica.org > 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