Nice to hear from you. I hope you don't mind my posting this response to
the entire METS list, as others may have the same question as you posed to
me. And also, this way Jerry and/or others can correct my mistakes...
You correctly note that in my sample METS document there are multiple
<dmdSec> elements, but only one <amdSec> element. This is because the
<dmdSec> is itself an <mdSecType>; the <amdSec> is not itself an
<mdSecType>; but rather it comprises 4 repeatable elements that are
mdSecTypes: <techMD>, <rightsMD>, <sourceMD> and <digiprovMD>. A <dmdSec>
can contain just a single unit of descriptive metadata (although it may
contain both an mdRef and an mdWrap element); and therefore <dmdSec> must
be repeated for each unique unit of descriptive metadata pertaining to a
METS object. But an <amdSec> element can encapsulate any number of unique
Administrative metadata units. The ADMID attributes of the <file> element
(under <fileGrp>) and <div> (under <structMap>) can refer directly to the
IDs associated with the relevant <techMD>, <rightsMD>, <sourceMD> and
<digiprovMD> elements under the encapsulating <amdSec> element.
Thus in my sample document, the file identified by ID=FID8 refers to 3
units of administrative metadata: ADM3, which is a unit of <techMD>
pertaining to how the image was captured; ADM6, which is a unit of
<rightsMD>; and ADM15, which is a unit of digiprovMD pertaining to the
master image from which the derivative image FID8 was derived. The file
identified by ID=FID9 also refers to 3 units of administrative metadata:
the techMD and rightsMD units are the same as for FID8 (ADM3 and ADM6
respectively). But the digiprovMD is different, as would be expected since
FID9 derives from a different master image.
While I hope that this clarifies how my example uses the dmdSec and admSec
elements, note that there are other valid ways of organizing administrative
metadata. I think that it would be perfectly valid to wrap each unique
administrative metadata unit in its own <admSec> element and have the ADMID
attributes of <file> and <div> refer to IDs at the admSec level. Or each
unique combination of <techMD>, <rightsMD>, <sourceMD> and/or <digiprovMD>
could be wrapped in an admSec element. Again under this handling, the ADMID
attributes of <file> and/or <div> would refer to IDS at the admSec
level. (Hopefully Jerry will confirm--or deny--that such uses of the
admSec would be valid). Also note that if I had used either of these
possibilities in my sample document, the document would have been
considerably longer. Wrapping all of the techMD, rightsMD, sourceMD and
digiprovMD elements within a single admSec element is the most economical
approach here, I think, and allows the various administrative metadata
units to be mixed and matched as needed to describe a <file> or <div> fully.
I hope this helps. Further comments and corrections are most welcome.
At 02:42 PM 8/7/01 +0200, you wrote:
>I am working on mets example documents for the METAe project. I had a
>closer look to your example to find out how other people use METS and
>came across some problems.
>You use a DmdSec for each descriptive metadata set in the document.
>That's how I would like to use it too. But you use just one AmdSec and
>put all administrative metadata in there then referencing the data using
>the id in the subsections and not using the id of the AmdSec.
>This seams to be wrong because the documentation of the file element
>7. ADMID: IDREFS to administrative metadata sections in the METS
> that correspond with this file
>Your way of using the AmdSec is also different from how you use the
>DmdSec. As they are named similar I think they should be used the same
>Am I wrong? Why did you choose this way of using the AmdSec?
>University of Innsbruck
>Innrain 52 / A-6020 Innsbruck / Austria
>E-mail: [log in to unmask]
>Phone: +43 512 507 9055
>Fax: +43 512 507 2607
Lead Software Engineer, Research and Development
Library Systems Office
University of California, Berkeley 94720-6000