Thank you to Dean and Bartek at MSU for the VERY HELPFUL response re:
audio metadata. My colleagues and I are digesting this and will no doubt
need a bit more help to get it all figured out. Watch for emails to come.
And thanks to Jerry on the "allfiles" stuff -- we are still heading in the
direction of phasing out allfilesMD and your comments give us some more to
go on. To be continued.
Meanwhile, this email is a report on my look at the MSU image
element/attribute list. MSU took our LC schemas and added some NISO
"mandatories" that we had left off. This idea of honoring the NISO
mandatories seems useful, even if (as is the case) we actually put some of
the "missing" data in other parts of the overall METS structure.
What follows is the core of MSU's analysis, with comments from me. But I
have gone to the data dictionary for our capture-database (where things
are in "fields" instead of elements/attributes) and noticed that some
things may have been inadvertently omitted from the schemas. (Thanks for
the proofreading, guys!)
<excerpt from MSU starts>
These attributes were added to the existing LOC image extension:
1. FORMAT: Name of Image Format. Recommended syntax: record value as a
three-character name that corresponds to the standard file extension
associated with the image format. (Examples) GIF, JPG, JP2, PCD, TIF;
<irreverent comment>I am still having trouble getting the point of this,
forgive me, since the MIMEtype also mandatory in NISO has the same darn
"names" in more or less the same form. I'm sure I'm missing something
and, as stated, we will march in step with NISO.</irreverent comment>
2. FORMAT_VERSION: Version of image format;
3. COMPRESSION: Designates the compression scheme used to store the image
data. Example: Uncompressed, CCITT 1D, CCITT Group 3, CCITT Group 4, LZW,
JPEG, PackBits (simple byte-oriented run-length scheme). Values above
drawn from TIFF 6.0 specification; and
<comment>We had thought not to bother with compression which is usually
expressed in the format type/format name (file extension), EXCEPT for TIFF
files where you gotta look inside. So we have a field in our database
(which may have gotten lost en route to the XML) called tiff_compression.
We better rename it compression and make sure it does get into the
4. PHOTOMETRICINTERPRETATION: Designates the color space of the
decompressed image data.
<comment>This is in our database as a field; may have inadvertently gotten
lost en route to the XML.</comment>
5. WATERMARK: the type of watermark.
<comment>If we kill allfilesMD, this element will go to imageMD, sure
1. SOURCE_XDIMENSION: Specifies the width of the scanned object; and
2. SOURCE_YDIMENSION: Specifies the length of the scanned object.
<irreverent comment>Well, these probably should go in the schema if
mandatory in NISO. We actually collect more information on the source
side (type, condition, etc.), destined for METS sourceMD extensions. But
no doubt we can pass off the dimensions part of this data to the imageMD.
This is a case where I differ with (or at least am reluctant to adopt) the
NISO approach, which mixes source information with image
To be continued . . .