> While I hope that this clarifies how my example uses the dmdSec
> and admSec
> elements, note that there are other valid ways of organizing
> administrativemetadata.  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).

Such a use would indeed be valid.  The notion is that it
might be simpler (and definitely more concise to come up
with groups of different types of administrative metadata
(IP rights, tech metadata for images, etc.) have them
addressable as a big chunk.  That way, a file could have
a single IDREF to administrative metadata that describes
it, rather than several.

This (and some other recent questions) are raising the issue
of whether people *want* so much flexibility in how
a METS document can be encoded, or would rather have
a more restrictive schema.  Alternatively, people might
want a fairly exhaustive guidelines document describing
how things probably *should* be encoded rather than enforcing
that through the schema.  This is probably something to talk
about at the September meeting, although if folks want to
get that balling rolling on the list now....