METS is agnostic with respect to how the files in the mets file inventory (the <fileSec>) are grouped--and there may be any number of reasons for grouping them one way or another.  However, I personally would caution against confusing the discrete functions of the <fileSec> and <structMap> elements.  And you could offer different structMaps regardless of how the file elements are grouped in the fileSec.  But I may not be fully understanding your proposal.


Elizabeth McKelvey wrote:
[log in to unmask]" type="cite">



Is anyone using nested file groups in their METS?


I just read the METS primer (again) and my eye was caught by something I didn’t remember from earlier readings:




A sequence of file group elements <fileGrp> can be used group the digital files comprising the content of a METS object either into a flat arrangement or, because each file group element can itself contain one or more file group elements, into a nested (hierarchical) arrangement. . . .


For a text resource with a variety of content file types one might group the content files at the highest level by type, and then use the <fileGrp> element’s nesting capabilities to subdivide a <fileGrp> by format within the type, such as:

• one <fileGrp> for all of the page images with nested <fileGrp> elements for each image for-mat/resolution (tiff, jpeg, gif)

• one <fileGrp> for a PDF version of all the pages of the document

• one <fileGrp> for a TEI encoded XML version of the entire document or each of its pages.


The nested file group option sounds great for situations such as the one described in my earlier post where we have a pdf of the entire work as well as page images. . .  each top level fileGrp could correspond to a different physical struct map, allowing the user to pick among versions – epub, entire work pdf, page images version, etc.







Betsy McKelvey

Digital Collections Librarian



Rick Beaubien
Technical Chair
METS Editorial Board
Contact information:

88 Herrada Rd
Santa Fe, NM 87508