Date:         Wed, 11 Jul 2007 11:02:50 -0500
Reply-To:     Metadata Encoding and Transmission Standard
              <[log in to unmask]>
Sender:       Metadata Encoding and Transmission Standard
              <[log in to unmask]>
From:         Tyler Danstrom <[log in to unmask]>
Subject:      Fw: Re: PREMIS and METS amdSec
Comments: To: [log in to unmask]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline

I tried to send this the other day, but it got bounced. My
comments on Rebecca's suggested additions to METS for better PREMIS
integration are below.

On 09/07/Y 15:47:-0400, Rebecca S. Guenther wrote:

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

This method is working very well for what we are using PREMIS for at the U of
C. We are using METS to create SIPS for all digital objects that may contain
1 or more derivative files. Premis object goes into techMD; premis rights
into rightsMD; events and agents go into digiprovMD; and, each file gets an
amdSec element. Ultimately, it all gets broken up when it's stored in the I/S
but for SIP submission it's only necessary to keep everything in a series of
connected xml branches off the big mets tree. ID/REF keeps it all linked-up
and orderly.

>2. Use all in techMD.

This a workable solution. I wouldn't want to deal with such a massive xml
fragment, though. I like being able to move in and out of the different info
without creating overly long xpath statements.

>3. Use all in digiProv.

Some premis info (like object) isn't really provenance information at all. 

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

I do not favor this method. In my judgement 
it would require creating increasingly more complicated
ID/REFs within the METS record to tie everything together. How would one
create the structMap? One way might be multiple AMDIDs on a
given div around a filePtr, but this is not valid. Or several nested div
elements each with its own AMDID. Which would be the outermost div? 

>Option 2 would be to add additional subelements to amdSec, either a
>generic "otherMD" or "otheramd" or more specific types like
>"preservationMD"

My only reason to hesitate over doing this is that any kind of generic
complex element runs the risk of just serving as a cover for indecisive
people. 
After the xmlData element  is there, METS schema validation ceases to care
what's inside, so
otherMD could very well end up filled with everything not absolutely
descriptive. 

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

I agree with Rebecca about adding a preservationMD. 

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

It seems to me that METS is working fine the way it is. Sure, there are
decisions to be made on a case-by-case basis, but I've found that the
structure provides what we need. Where to put PREMIS metadata in METS is not
one of my major concerns in my job. Making too many options just hinders
interoperablity in the worst-case or pulls everyone to the lowest-common
denominator in the best-case.

----
Tyler Danstrom
Programmer analyst
University of Chicago Library, DLDC