A few thoughts from my cold-sodden brain on Carl's
message. The criterion for whether something should
be on an individual file vs. being in a techMD section
is, I believe we said, whether the data varies significantly
from file to file. However, Carl's message raises some
interesting questions on this criterion.
> -- byte_order: The order of bit significance in a byte from left to
> right. (Big and little endian, Motorola vs. Intel, etc.)
byte_order isn't going to vary much from file to file; I'd
say it's techMD.
> -- the checksum trio:
> -- -- checksum_value Checksum value of the file, e.g.,
Definitely varies for each file; checksum_value is
definitely file element data, not techMD.
> -- -- checksum_type Type of checksum algorithm employed, e.g., MD-5,
> RSA-MD4, HC Checksum algorithm, etc.
My assumption is that you're unlikely to vary your checksum
algorithm much from file to file, so this is techMD. However,
there's a case to be made that you'd want to store the info
near where you're storing the checksum itself. I lean towards
making this techMD, though.
> -- -- checksum_datetime Creation date and time of the checksum, e.g.,
> 1997-04-22 (date only), 1997-04-22T19:20+01:00 (full expression), etc.
Varies by file, so, file metadata, not techMD.
> -- security: Type of encryption or other security used in the
> file, e.g.,
> symmetric, assymetric, RSA encryption, Rabin encryption etc.
> -- watermark: Type of watermark used in the file, e.g., Digimarc,
> Giovanni, Alpha-Tec, StirMark, etc. SBCS(255) NONE
> -- use: Use of the file, e.g., [Library of Congress terms,
> displayed for
> end-users] Master, Service High, Service Low, Preview.
> QUESTION 1: Are any of these nominees for filegrp or shall we
> agree to
> leave them in TECHMD?
As noted above, I think some of them are candidates for the
file element, although mostly I think they should be in techMD.
> QUESTION 2: If this whole bunch should stay in TECHMD, should we
> add them
> as a block to all four extension schemas or continue to have a
> separate"allfiles" schema? This is asked to the METS group
> because we share an
> interest in building an application profile that we all like.
In looking over the LC schema, I'm tempted to say that
you should organize things so that you have your media
oriented schema (text/image/audio/video), and that each
of those should include the allFiles schema. That way,
you could have a techMD section for video, say, which would
include both the video specific and allFiles metadata.
> PS: There is also an orphaned field we have called either
> compression_codec or compression_method. For this, we were not
> thinkingof the value "MP3" but rather "Frauenhofer" or "Sorenson"
> for the specific
> coding algorithm used. I suppose something like this would also
> be useful
> if you were anal enough to want to track the quantization tables
> you used
> to make a JPEG file. My mood today is to leave this one in audio and
> video TECHMD, and I plan to make it part of my coming dialog with our
> colleagues at Michigan State. Interim comments are welcome, however.
I think having slots for both the specific codec and quantization
methods is a good idea. If the theory is we want to support
scholars' ability to try to figure out what the original was
like, such information is vital.