With the caveat that I am not on the NISO committee publishing the image
metadata standard, I'm happy to share the rationale that led to inclusion
of the data elements in the draft data dictionary. We'll have to wait
until early 2002 to see what elements have survived into the draft standard
that will be released--I don't know if all mandatory fields in the
dictionary, for example, will still be mandatory in the standard.
--------Excerpts from your message of 12/5/01--------
>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;
Why are these listed as separate fields? The NISO Standard includes only
"FORMAT," type=string, *not* FORMAT_VERSION. We added the FORMAT field to
make versions explicit when necessary. Granted, the value of "FORMAT" will
be redundant in most cases--repeating what has already been identified by
MIMEtype--but certain raster formats, such as GIF, PDF and TIFF/EP, will
potentially have meaningful distinctions according to the version number.
>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
Like TIFF, PDF and other raster formats support a range of compression
schemes, so compression should not be implicit.
>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
The purpose of these fields is to compute spatial resolution accurately,
NOT to describe the attributes of the source materials. These values are
needed when intermediates, such as microfilm, are scanned. The SOURCE_X
AND Y_DIMENSIONS would be used with ImageWidth and ImageLength (expressed
as numbers of pixels) to calculate the correct "dpi on the original" values.
These are optional fields.
>To be continued . . .
Preservation Librarian for Digital Initiatives
Weissman Preservation Center
Harvard University Library
Holyoke Center 821
Cambridge, MA 02138
E-mail.. [log in to unmask]