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
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
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
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

^^  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]                                          ^^
^^                                                        ^^