In a message to this list on Jan. 3 I posed the question about which METS
sections to use with PREMIS metadata and when to use the PREMIS container.

After having a conversation with Jerry McDonough about this I felt a
little more enlighted and wanted to share the information with this list.
Here are Jerry's thoughts about the 2 questions (he wrote the initial
PREMIS schemas and was on the working group).

Use of the container:
The main reason he included the PREMIS container and made that separate
schema for it was primarily for the purpose of using the XML schemas as is
and NOT in the context of METS. So he didn't really see any good reason to
use it in METS. Even if you used more than one of the schemas in the same
METS section you may not need to use the container.

His general feeling was the same as what I had been thinking for some
time: object goes in techMD and event in digiProv. One could argue that
all preservation metadata has to do with provenance of the files and argue
for putting everything in digiProv. But then we talked a bit about that
and determined that object still needs to go in techMD because of the
overlap of those elements with those defined in MIX. And it would only
make sense to put all that overlapping data in techMD because that's where
MIX would be.

We had some questions at LC about the use of sourceMD vs. digiProvMD. He
thought that sourceMD might be a convenient bucket to use for descriptive
or technical information about the analog original. I am of the opinion
that descriptive metadata should stay in descMD-- but he made the point
that in the case where you might be linking to a MARC record and not
including descriptive metadata in the METS document, you might want to
keep some descriptive info in the METS document about the source of the
analog.  In any case it is ONLY about the analog, not about the source of
the digital. The event of making a digital from an analog goes in
digiProv.  Of course, this is probably irrelevant in terms of PREMIS,
since PREMIS deals only with digital events.

We agreed that premis:agent would go with event or rights in the
appropriate section. Here he thought it was optional whether or not to
bind them together with a premis container. I think maybe it is a good
idea to use the container if there's the potential to repeat the event or
rights, since it will bind the agent with the appropriate event or rights
statement (although you could relate them with an ID attribute). Like if
you were recording the digitization event and include who digitized it and
then later wanted to record something like a migration event and who did
it-- the agent and event need to be related either by the use of the
container or with the ID. It'd be less complex just to bind them with the

We'll still need to see some best practices emerge after experimentation,
but discussing it is one way to start.