 |
 |
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 http://nla.gov.au/nla.mus-an5631356 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) http://www.apsr.edu.au 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: http://www.loc.gov/standards/premis/louis.xml 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: http://lcweb2.loc.gov/cocoon/test-ihas/loc.natlib.gottlieb.09601/default .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] ^^ ^^ ^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^