The committee reviewed the draft list of elements in techMD, noting those that have been added since our last meeting in April. We discussed several elements in more detail.
PresentationSystem: One function of this element is to determine if the hardware/software can adequately present the digital object. The committee was reminded that techMD pertains to the archival master, not the presentation format of the digital object. Also, other techMD elements including FileSize will give information about whether a computer can "handle" the object. It was determined that this element is not appropriate for techMD. It will be in the METS datastream. PresentationSystem will not be in techMD.
OS (Operating System) and OSVersion: This pertains to the operating system on which the archival master file (object) was created. It will not contain information on the migratory path that a file might have gone through to get to this particular repository. Definition of OS: operating system in use at the time of archival master file creation. Definition of OSVersion: version of the operating system in use at the time of archival master file creation. OS and OSVersion will remain in techMD.
FileProducer: Properly speaking, this belongs in the METS Header (METSHdr). However, Fedora takes over the METS Hdr. The Committee agreed to move FileProducer to rightsMD (not METSHdr) so that Fedora does not eat it. FileProducer will not be part of techMD.
ObjectIdentifier: In METS, each section of metadata (techMD, rightsMD, descriptiveMD, etc.) has its own ID (system-supplied). In our Fedora implementation, there is also an internal ID for the whole information package (system-supplied). Finally, there is a persistent ID for the object, which consists of a CNRI handle with a unique ID for the object. The purpose of the ID in techMD is to help this section of metadata hang together with all the other parts that describe the file. METS implementation takes care of this already, whether in Fedora itself or in a migratory workflow management system to ingest into Fedora. For purposes of the Digital Library Repository, we will use the architecture of the Fedora implementation and its system-supplied internal ID numbers. ObjectIdentifier will not be part of techMD.
DateTimeCreated: The METS implementation takes care of this already, whether in Fedora itself or in a migratory workflow management systems to ingest into Fedora. For purposes of the Digital Library Repository, we will use the architecture of the Fedora implementation and its automatic DateTime stamps. DateTimeCreated will not be part of techMD.
CheckSumMethod and CheckSumValue: The committee agreed to retain these elements in techMD as they pertain to the archival master. We will also use CheckSumMethod and CheckSumValue in the DigiProvMD as they pertain to the complete information package.
FrameRate and BitRate: The committee evaluated these new elements which were added specifically to pertain to audiovisual files. Upon examination, they appear to have the same function, in a more specific way, as the element pair, Sampling and SamplingUnit. The committee agreed to collapse these elements and make them applicable to multiple formats. We will develop controlled vocabularies for image (i.e., still image), audio, and video. Thus, for example, the Sampling Unit for video might well be expressed in terms of Hz or KHz, as frame rates. Our registry will map the Sampling and Sampling Unit elements to the equivalent elements for FrameRate and BitRate in other schemas such as MPEG-7. FrameRate and BitRate will not be part of techMD.
There are 14 elements in techMD, five of which are mandatory (required):
The committee commenced work on the digiProvMD. We began discussing each element in detail.
ArchiveDateTime: The committee agreed on a definition for this element: date and time of the creation of the information package. We noted that Fedora writes this DateTime to the METS Header; it is system-supplied. We will note in our metadata registry that this digiProvMD element is written in the METSHdr.
ArchiveHistory: The committee agreed that this is a useful element, and that it is by nature a narrative element. That is, it allows an operator to supply a brief explanation of events. However, the committee could not come to consensus on the parameters or nature of the information that should go into this element due to meeting time constraints. We will continue to discuss DigiProvMD at our next meeting.
Next Data Architecure Committee meeting:
Monday, June 21, 2004, 9:30 a.m., TSB Conference Room.