Hi Jenn,

I second that you're scanned pages are rightly considered descriptive  
metadata, if they can be indexed.

At DSpace, we have also encountered the situation where system  
developers want our METS to point to all files (metadata and content)  
in one place using one mechanism.  I'd prefer to counter this bit of  
laziness, keeping them from ignoring the rich information our METS is  
passing them.  I kind of like what you did as a solution to that  
puzzle.  It allows a METS consumer to decide whether they can use any  
of its meaning.

However, if the problem you want to solve is integrity checking, you  
should look at PREMIS.

Robert Wolfe
Metadata Specialist
MIT Libraries/OpenCourseWare
[log in to unmask]

On Feb 23, 2006, at 11:24 AM, Jerome McDonough wrote:

> 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  
> descriptive
> metadata, but if it's really operating as such, I wonder whether  
> you might
> 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  
> approach
> 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]