This makes sense to me, Robin. I have gone ahead and added an entry for
this on the METS 1.9 change requests page on the METS Wiki so that it
will get on the agenda for discussion at the next Board meeting.
There are a couple of related issues that we should possibly consider:
1. Should we add an ADMID attribute to mdWrap as well? It seems pretty
clear to me that we should. Any element of mdSecType can contain both
an mdRef and an mdWrap--and from what you are saying it appears that
distinct administrative metadata may apply to each, even within the same
2. Do we want to incorporate ADMID into the FILECORE attribute group? I
haven't looked at the full implications of this yet. However, doing so
would take care of the need on both mdWrap and mdRef elements. However,
many elements which reference the FILECORE attribute group also have an
associated ADMID attribute.
Robin Wendler wrote:
> Hi, all --
> We'd like to include in METS documents the administrative and
> metadata associated with an mdRef'd metadata file. Right now, it looks
> there is no ADMID attribute on mdRef. One would have to use the ADMID
> on the
> encapsulating element (e.g. techMD, digiprovMD), which may not be
> appropriate, since the linked ADMID would refer not to the encapsulating
> element as a whole, but rather to the specific file within the mdRef.
> The METS Board did add the FILECORE attribute group to mdRef, which was a
> recognition that one might need to record more information about the
> ref'd file.
> Adding ADMID would be a logical next step to enable folks to manage
> metadata files similarly to the way they manage content files.
> Any thoughts? Thanks,
> Robin Wendler
> Harvard University Library
> Office for Information Systems
> 90 Mt. Auburn St.
> Cambridge, MA 02138 USA
> 617-495-3724 (W)
> [log in to unmask]
Software Engineer, Research and Development
U.C. Berkeley Library
88 Herrada Rd
Santa Fe, NM 87508