This Carl's metadata musings, number 2 of 2 for December 9, 2001. Thanks
again to Dave Ackerman for the very helpful note about the AES process.
I cannot say HOW RELIEVED I am to learn that AES is cooking up separate
"administrative" and "processing history" metadata blocks. I was worried
that the society would head for a DIG35-like "everything but the kitchen
sink" structure, including rights and descriptive metadata. They did a
GREAT job but it is more awkward for us plug- and-play types to use.
In general, we in the LC AV project will listen and obey the AES, just as
we plan to listen and obey the NISO image standard. I am working up a few
notes on audio which I'll pass along shortly, to continue the process we
have shared with the MSU group, who have also provided some very helpful
Meanwhile, a couple of early observations (more to come):
About byte_order, which was also touched on in my msg 1 of 2 today. Dave
Ackerman's preview of the AES standard (which we will use as techMD) does
include byte order, called "audio_data_orientation" [(big_endian |
little_endian) #REQUIRED], as an attribute of the element "data_format."
This is consistent with a recent email from Jerry that stated his sense
that byte order go to techMD rather than fileGrp. But the NISO data set
does not include byte_order, which strikes me as odd since we at LC have
had trouble from time to time reading an "Intel TIFF" or a "Motorola TIFF"
file in one software or another, which I attribute to byte order
differences. If it is omitted from NISO, and if we use NISO for techMD do
we then risk losing this information about images?
About targets (images) and calibration signals (audio and video):
The NISO document (but not the current versions of the LC or MSU schemas
derived from it) does include:
TargetType: "identifies targets [target images] as external or
internal" "0=external" and "1=internal"
TargetID: "target name, manufacturer, version" string with name, etc.
ImageData: "path where image of the target is located" "URN"
These are listed as required but I am uncertain what that means; many
projects will not produce a targets. Does this mean "required if you have
Dave's notes don't tell us about calibration tones for audio, more or less
the equivalent of a target in imaging. If calibration tone recordings
exist, will the AES track them in their "processing
history" schema? Meanwhile, at the moment the LC audio and video database
tables have, although they seem not to have made into our schemas:
calibration_type: equivalent to NISO TargetID
calibration_location: equivalent to NISO ImageData, on the
possibly/probably false assumption that all calibration tones will be
calibration_note: more information
On reflection, the trio for NISO seems a little better than our
trio: (1) external/internal, (2) ID/type, and (3) location-if-external.
But for us METS folks: where is the best home for this information about
targets and calibration tones? With other techMD, as suggested by the
NISO document? Or in digiprov? Since digiprov is not likely to be used
by many METS practitioners, my mood is to say techMD. This would mean
adding a target block to the imageMD schema and calibration blocks to
audioMD and videoMD. What are the implications for the use of the AES
administrative schema if it omits calibration? Shall we shift targets and
calibration to our allFiles block, which may turn out to be an insertion
into our various specific techMD schemas?
Thanks for the continuing discussion! Carl