I took a look at your METS file that's now on the Wiki (finally) and have
a few comments.

The issue of using an admSec for each file was one we debated long and
hard about-- my initial inclination was to do it that way. It did get very
longwinded and when we compared the 2 approaches, it seemed that the
separate admSec tag was playing no role really-- the ID/IDref links were
identical regardless of whether you repeat admSec. But there may be other
good reasons to do it your way. I would be interested to see if others
have debated the pros and cons.

Yes, the reason for repeating digiProv is to only have to include the
agent once and be able to link from multiple events.

It would be great if we could all agree on best practices for this sort of
thing and document them. Maybe we'll all need to experiment first.


On Fri, 21 Jul 2006, Bronwyn Lee wrote:

> This is very timely, as we have also just developed a PREMIS METS
> example to go with a profile we are drafting for use within the
> Australian Partnership for Sustainable Repositories (APSR).
> Our example is a bit more complicated, being a piece of sheet music
> consisting of a front cover, two pages and a back cover. There are three
> representations covered in the METS document: an archival master copy
> consisting of four TIFF files, a display or access copy consisting of
> four JPEG files and a print copy consisting of a single PDF file which
> was created from the access copies. This is a real example from the
> National Library of Australia's Digital Collections Manager (DCM) system
> and the presentation of it can be seen at
> The scenario the profile addresses is use of the METS document to
> transfer custody of an item from one repository to another because this
> scenario requires the most metadata for the master copy.  As a general
> principle we have included all available metadata rather than linking to
> it hence for example the full catalogue record is included as well as a
> MODS record.
> In the example technical metadata is included for the access copies as
> well but we agree it is not essential.
> Our approach is similar to Rebecca's but the main difference is that we
> have one amdSec for each file (rather than all files' metadata under one
> amdSec) because we thought it was desirable to keep all the information
> about a file together. We also had only one digiprov for each file (we
> only included digiprov for the master files). An advantage of Rebecca's
> approach is that metadata for an agent only has to occur once, not once
> for each file involved. 
> I'd be interested to hear what people think. Our approach makes the
> document potentially longer but (in my opinion anyway) easier to follow
> as you don't have to jump round as much. But as systems will generate
> these documents, and process them, perhaps neither the jumping round nor
> the length matters, although I think it helps if the documents ARE human
> readable (by the way I'm not in favour of codes e.g. MIX's ColorSpace
> "2" instead of "RGB"). We would go along with the consensus in any case.
> This is still very much a draft and has not been published to a website
> yet, so I'm attaching both the draft profile notes (it won't be put into
> the METS profile xml schema until it's firmer) and the METS example. The
> METS example is a .txt file as the PIG list rejected the .xml file.
> Bronwyn Lee
> Australian Partnership for Sustainable Repositories (APSR) 
> National Library of Australia 
> [log in to unmask] 
> -----Original Message-----
> From: PREMIS Implementors Group Forum [mailto:[log in to unmask]] On Behalf Of
> Rebecca S. Guenther
> Sent: Friday, 21 July 2006 12:29 AM
> To: [log in to unmask]
> Subject: [PIG] PREMIS METS example
> This is being sent to both the PREMIS Implementors' Group list and the
> METS list. Sorry for the duplication.
> In preparation for a PREMIS tutorial that Priscilla Caplan and I just
> did in Glasgow (sponsored by Digital Curation Centre), I spent a lot of
> time trying to figure out the best approach for using PREMIS with METS.
> Thanks especially to Morgan Cundiff at LC and Tom Habing at UIUC for
> helping me with this. I have made available a sample document to
> illustrate the approach that we came up with and solicit comments about
> it. It is at:
> Some notes on the approach.
> 1. There is one administrative metadata with multiple techMD and
> digiProvMDs. The ADMID on <file> of course links to the appropriate
> techMD or digiProvMD.
> 2. PREMIS object metadata is in techMD and premis:event is in digiProv.
> If we had premis:rights it would be in rightsMD.
> 3. If there are elements in PREMIS that are also in METS, they are
> encoded redundantly. We thought that there was no harm in this and
> perhaps safer.
> 4. If there is MIX, generally the data that is in PREMIS is in the
> PREMIS section and only the additional elements that are file specific
> are included in the MIX section. Note that this is based on the older
> version of MIX; MIX is in the process of revision because of the Z39.87
> revision to harmonize the element names with PREMIS where they are the
> same.
> 5. If there is an agent, it is in a separate digiProvMD or rightsMD
> section depending upon which metadata it's related to. In this case we
> haven't included a rightsMD section. We do have 2 events in digiProv.
> Then we have repeated digiProv with an agent and both events link to the
> same agent and the one agent is associated with both events in the file
> section.
> 6. This example adds to a METS object we already had in our digital
> library. I am considering this METS object an intellectual entity (in
> PREMIS terms); thus the link to the presentation of it in the PREMIS
> linkingIntellectualEntity.
> see:
> .html
> 7. We have not included PREMIS metadata for the service copies, because
> we consider them throwaways.
> I would welcome any comments on this approach. Also any discussion so
> that we can all start thinking about best practices for PREMIS/METS/MIX
> together.
> 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]                                          ^^
> ^^                                                        ^^
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^