Print

Print


Jenn,maybe short excerpt from the various xxxSec elements
would help us understand this.
anyway, it would help me.
Thanks,
Rick

At 10:48 AM 2/23/2006, Riley, Jenn wrote:
Hi all-

My message yesterday got truncated - my apologies! Here's another try:

I've recently been looking at the possibility of using METS to list,
link to, and describe relationships between a set of diverse files being
transported from one institution to another. The purpose of this METS
file would be to provide enough information on the files being
transported to ensure they arrived safely, and to provide some very
basic information on the relationships between the files (2 different
bit rates of audio, scanned page images of concert programs representing
descriptive metadata of a sort, and two types of files containing
technical metadata about the audio files). We'd like the METS file to be
as simple as possible, with as little redundancy as we can manage. I've
come up with a proposal that in some places gets a little creative with
the use of METS for these purposes. Since I know there's a fine line
between creativity and a hack, I was interested in other opinions about
some of the practices I've proposed.

1) Every single file being transported (even the ones thought of as
descriptive or technical metadata) has an entry in the <fileSec>,
allowing us to indicate checksum, etc. These are grouped by type of
file.

2) A <dmdSec> appears representing the set of scanned pages of the
program for a concert (not each individual page, but the set of them).
It has an <mdRef> with an xlink:href attribute with the current METS
file as its value, and an XPTR attribute pointing to the <fileGrp> in
the <fileSec> where the page images are grouped. Saying this is
descriptive metadata is a *bit* of a stretch, as the bits making up the
page images aren't descriptive metadata, but their intellectual content
is.

3) Several <techMD>s appear, each representing a technical metadata file
(we have two kinds in this situation), using the same <mdRef> strategy
as in the <dmdSec> to point to the file in the <fileSec> of the METS
document.

4) The audio files in the <fileSec> have AMDID attributes referencing
which of the technical metadata files is applicable to this audio file.
They also have DMDID attributes referencing the set of program pages
referenced in the <dmdSec>. We reference the set rather than anything
more specific because we don't at this point in the project have
information about how the page images line up with points in the audio
file.

5) A <structMap TYPE="logical"> appears, listing "tracks" or breaks
between musical works in the concert.

So does any of this sound like I've gone a bit too far with the usage of
a METS element? Is there anything in this proposal that could be done
more simply or elegantly than the way I've described?

Thank you!

Jenn

> -----Original Message-----
> From: Riley, Jenn
> Sent: Wednesday, February 22, 2006 5:47 PM
> To: [log in to unmask]
> Subject: METS for transporting of various files
>
> Hello all-
>
> I've recently been looking at the possibility of using METS
> to list, link to, and describe relationships between a set of
> diverse files being transported from one institution to
> another. The purpose of this METS file would be to provide
> enough information on the files being transported to ensure
> they arrived safely, and to provide some very basic
> information on the relationships between the files (2
> different bit rates of audio, scanned page images of concert
> programs representing descriptive metadata of a sort, and two
> types of files containing technical metadata about the audio
> files). I've come up with a proposal that in some places gets
> a little creative with the use of METS for these purposes.
> Since I know there's a fine line between creativity and a
> hack, I was interested in other opinions about some of the
> practices I've proposed.
>
> 1) Every single file being transported (even the ones though
> of as descriptive or technical metadata) has an entry in the
> <fileSec>, allowing us to indicate checksum, etc. These are
> grouped by type of file.
>
> 2)
>
> ========================
> Jenn Riley
> Metadata Librarian
> Digital Library Program
> Indiana University - Bloomington
> Wells Library E170
> (812) 856-5759
> www.dlib.indiana.edu
>
> Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com

******************************
Enrico Silterra
Meta Data Engineer
107-E Olin Library
Cornell University
Ithaca NY 14853

Voice: 607-255-6851
Fax:     607-255-6110
E-mail: [log in to unmask]
http://www.library.cornell.edu/cts/
******************************