Print

Print


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