On Feb 23, 2006, at 9:48 AM, Riley, Jenn wrote:
> 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.

I don't have a problem with considering the program as a piece of  
metadata, but if it's really operating as such, I wonder whether you  
want to at least produce a text transcription so that the  
"descriptive metadata"
is indexable/searchable.  If you're going to use <fileSec> to insure
you can record fixity information for your metadata records, the  
you're taking for <dmdSec> and <techMD> records seems OK, but I would
suggest at least considering whether it might be better to use PREMIS
to record this type of information, and abandon the slightly kludgy use
of <fileSec> to record fixity info for your metadata.

> 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?

I think the use of PREMIS would be a bit more elegant and in keeping
with the general structure of METS, given that there is no existing
facility in METS for recording fixity information for a metadata record.
I do think the board might want to consider whether a change to the
METS schema to add some sort of fixity information to the mdSecType
definition is in order.  If we include an attribute for this purpose for
data files, including one for metadata seems like a reasonable step.

Jerome McDonough, Asst. Professor
Graduate School of Library & Information Science
University of Illinois, Urbana-Champaign
501 E. Daniel Street, Room 202
Champaign, IL 61820
(217) 244-5916
[log in to unmask]