Sorry for the delay.  I answer your questions as best I can below.  
Others on the METS Board or within the METS community may wish to extend 
or correct what I have to say.  My sense is that most of these are not 
just questions, but recommendations for additions to or elaborations of 
documentation in the METS Primer.  The "documentation errors" page on 
the METS wiki can be used for recommendations to improve the METS 
documentation; and I will add your suggestions to this page.

In addition to your fairly specific questions here, you have recently 
set forth many suggestions for extending the application of METS.  The 
METS Board plans to take up these suggestions at upcoming Board 
teleconferences.  In the meantime I plan to set up a page on the METS 
wiki so that ideas like yours which which have not yet been formalized 
as specific schema change requests can be recorded by anyone with an 
interest in METS and can be discussed by the METS community.


Rick Beaubien

Responses follow your questions below:

Brett Zamir wrote:
> Hello,
> I also have the following questions of clarification about the 
> documentation... (I put page numbers for my own reference, though they 
> may not be critical for the question.)
> 1) Is there any limitation on supported schemes for XPTR? (p. 20) If 
> so, or even if not, I think it might be mentioned.
METS is agnostic with regards to the XPTR scheme that is used. 
> 2) Pages 29-30 mention <file/> as recursive allowing for sub-files or 
> components files--is this along the lines of being part of a zip, or 
> just broken in pieces (like each page of a book having a separate file)?
Along the lines of the former, not the latter.  (See the example on page 
33 of the METS Primer).  Recursive <file> support came in with METS 1.5, 
and was implemented in particular with an eye to supporting the PREMIS 
"onion layer" model.  (see  It allows 
multiple layers of encoding to be analyzed, and for each to be 
associated with appropriate technical metadata.  The ways that content 
files fit together to express the  logical and/or physical structure of 
a digital entity should be expressed through structMap mechanisms.
> 3)  Might an example be given showing the difference of USE when used 
> on <file/> and when on <FLocat/>?
A <file> element may contain any number of FLocat elements and/or an 
FContent element.  In other words a single file element may aggregate 
one or more references to different copies of the file (FLocat) and/or 
an FContent element that wraps the actual file contents.  In cases where 
the <file> element aggregates multiple FLocat elements, or an FLocat 
element and an FContent element, different uses may pertain to the 
different copies of the file that are referenced.  For example, if a 
file element contains both an FLocat and an FContent element, the USE or 
purpose of the copy of the file referenced in the FLocat may be 
"service", and the copy of the file wrapped in the FContent element may 
be "preservation".  In this case, the file element would probably not 
include a USE attribute.  Rather the distinct uses intended for the 
different copies of the file would be expressed in conjunction with the 
FLocat and FContent elements.  If, however, a <file> element only 
contains a single FLocat or FContent element, or if all of a <file> 
element's child <FLocat> and <FContent> elements serve the same purpose, 
the USE can be expressed at the <file> level, rather than at the FLocat 
and/or FContent level.
> 4) While I know it is application-specific, what exactly would an 
> XLink show value of "embed" mean in the context of a METS file. 
> Embedding the file within the document would not seem to make sense, 
> as the document is not really meant to be formatted, I presume, so 
> might it be used to refer to how the document should be displayed 
> subsequently. For example, if I am using METS to browse reassembled 
> packages of files in my web browser, it might refer to embedding the 
> file in the current window, as opposed to opening a new window? (p. 44)
I frankly doubt that xlink:show is very often used in conjunction with 
the elements in METS that implement simpleLink.  However, if it were 
used it would be a directive to a presentation layer, as you correctly 
> 5) I think the use of both XLink's arcrole and role in an example 
> would be useful.
These are XLink, not METS, defined attributes--and their uses are 
described (with examples) in the XLink specification 
(  However, I will add this as a suggestion 
for improving the METS documentation.
> 6) file: is used as a prefix for relative files in the METS docs; is 
> this a standard?
The Board is currently reviewing both the accuracy and appropriateness 
of these apparent references to the file protocol in the Primer.  Stay 
> best wishes,
> Brett

Rick Beaubien
Software Engineer, Research and Development
U.C. Berkeley Library

Contact information:

88 Herrada Rd
Santa Fe, NM 87508