Actually sharing these kinds of documents is exactly what we had in mind
for our PREMIS Implementors' Group wiki, the "pigpen".
It is very easy to use, and I would encourage people to put examples up
there-- better than sending in an email.
Right now it's password protected, although we had thought we would change
that to make it easier for people to use. Only subscribers to this list
can read the archives and would know about the wiki, so I am including the
There is a section for encoded examples as well as a section for METS
profiles that use PREMIS.
This is considered a place to put documents that people want discussed,
not necessarily anything in final form, so we encourage people to use it
as it was intended. It could really help us in our work.
So if anyone else has some sample files that use PREMIS, either examples
for objects or profiles or whatever, PLEASE post them on the pigpen and
let everyone know through this list.
To get to the pigpen:
There's also a link to it from the main PREMIS Implementor's group page
(but not the password):
To use it, simply click on edit and follow the pattern to create
links. Click on attach to upload a document from your computer to the
wiki. It's fairly self explanatory and there's some documentation under
On Mon, 24 Jul 2006, Bronwyn Lee wrote:
> There is no actual METS file for the item as yet, but it is proposed
> that the METS file would look like the text file I attached to my
> previous message. I fixed a few minor errors so I'm attaching it again.
> As I said it is very much a draft and will continue to be developed, and
> influenced by what other people are doing. We haven't tested it
> ourselves yet but when we do we can let people know where to find the
> test files.
> We weren't really ready to publicise it but since it was raised on the
> PIG list and Rebecca called for discussion we thought it was timely to
> show people what we are thinking.
> -----Original Message-----
> From: PREMIS Implementors Group Forum [mailto:[log in to unmask]] On Behalf Of
> Morgan V. Cundiff
> Sent: Friday, 21 July 2006 10:53 PM
> To: [log in to unmask]
> Subject: Re: [PIG] PREMIS METS example - An example from National
> Library of Australia
> Can you point us to the METS file for the item?
> 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
> > 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
> > 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/defau
> > lt
> > .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] ^^
> > ^^ ^^
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^