 |
 |
Probably most people on this list are aware of the issues concerning using the PREMIS schemas (for encoding preservation metadata) with METS. Because these schemas were written to allow for flexibility in implementation and as faithful representations of the PREMIS data model, decisions need to be made as to which sections of METS to use for which entities described in the data dictionary (and encoded in the PREMIS schemas). The schemas consist of the following: premis:object (for technical metadata that applies to all or most file formats) premis:event (for actions taken on objects) premis: rights (for rights and terms and conditions relating to preservation of objects) premis:agent (for agents that act on objects through events or rights) There is also a container schema that references the 4 schemas if desired to have a wrapper for all PREMIS metadata. Because of the structure of METS, which requires the use of a subsection under the amdSec, PREMIS metadata cannot be put directly under amdSec, but a choice must be made. There are several alternatives for implementing the PREMIS schemas in METS: 1. Use premis:object in techMD, premis:event in digiProv, premis:rights in rightsMD, and premis:agent with either rights or digiProv depending on to which it applies (this seems to be the most common practice now). 2. Use all in techMD. 3. Use all in digiProv. At a DLF BOF session in Nov. 2006 during which PREMIS implementation was discussed, there seemed to be considerable interest in changing METS to allow for encoding PREMIS metadata directly under the amdSec so that a choice would not have to be made and so that all the PREMIS metadata stays together. This could be implemented in various ways. Option 1 is to remove the requirement to have mets:digiProvMD, mets:rightsMD, mets:sourceMD, and/or mets:techMD under amdSec. This would be like dmdSec in that the elements from the other schema would come directly under amdSec; an "MDTYPE" attribute could be added. Option 2 would be to add additional subelements to amdSec, either a generic "otherMD" or "otheramd" or more specific types like "preservationMD" I would be hesitant to define something like a preservation metadata section, because metadata that supports the digital preservation process may also support other functionality, such as access (consider that technical metadata supports both) and would prefer something like the "otherMD" approach if pursuing Option 2. Option 1 seems more elegant to me, because I'd rather not categorize what preservation metadata is or lump it into an "other". However, Option 2 would be less disruptive. I would be interested in reactions to this proposal and discussion about how best to implement it before sending it to the METS editorial board for consideration. Rebecca ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^ Rebecca S. Guenther ^^ ^^ Senior Networking and Standards Specialist ^^ ^^ Network Development and MARC Standards Office ^^ ^^ 1st and Independence Ave. SE ^^ ^^ Library of Congress ^^ ^^ Washington, DC 20540-4402 ^^ ^^ (202) 707-5092 (voice) (202) 707-0115 (FAX) ^^ ^^ [log in to unmask] ^^ ^^ ^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^