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