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.
Responses follow your questions below:
Brett Zamir wrote:
> 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
www.dcc.ac.uk/events/premis-2006/premis_DCC2006_pt2.1.ppt). 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
(http://www.w3.org/TR/xlink/). 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,
Software Engineer, Research and Development
U.C. Berkeley Library
88 Herrada Rd
Santa Fe, NM 87508