Bronwyn,
Can you point us to the METS file for the item?
Thanks,
Morgan Cundiff
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
> 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] ^^
> ^^ ^^
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
|