The reason that we used an IDREF attribute in the <fptr> element was  
to insure that all <fptr> references are actually valid, i.e., they're  
pointing at a real <file> element  and XML processing software can  
double check that for you.  Essentially it serves as a safety check  
for referential integrity between the <structMap> and the <fileSec>.   
As the GROUPID attribute is not an ID attribute (and can't be, given  
its use), there's no easy way to do what you suggest and still insure  
that references from the <structMap> to content files are actually  

I recognize that it seems like using GROUPID would make for simpler  
coding, but providing yet another variation in how people can encode  
the structural metadata for objects would make it that much harder to  
exchange them between institutions.  I'd strongly recommend following  
recommended practice here (<fptr> IDREFs pointint to <file> IDs)  
rather than trying to implement a localized solution that would be  
incompatible with others' encodings.

On Nov 11, 2009, at 7:35 AM, Wolfram Zieger wrote:

> Hello dear METS experts community,
> I found a lot of METS examples which use the GROUPID parameter  
> within the
> "fileGrp"s in a way to represent i.e. the very same page of a  
> scanned book
> with different file formats (using the "USE" parameter for  
> separation).
> I'd thought it makes perfect sense to refer to this GROUPID from the
> structMap, to represent this very book page with it's different
> file-format-implementations all at once.
> However all the examples I found ignore this GROUPID parameter  
> completely
> within the structmap and bravely writing every single fileid instead  
> (which
> is exactly, what the GROUPID parameter is trying to assemble).
> Why is that?
> Did all the examples miss this great opportunity? Or is it me who is  
> missing
> something :) ? [edit: yes - it's me - see below]
> Here is an example ignoring GROUPID="b859t(SO)-anno01_003-page0001"  
> for page
> 1 (as I was taught by "METS Documentation final 070930 msw.pdf" and  
> other
> examples officially linked from the METS webpage)
> ----------------------------------------------
> <mets:fileSec>
> 	<mets:fileGrp USE="master">
> 		<mets:file
> 		ID="b859t(SO)-anno01_003-page0001-master"
> 		GROUPID="b859t(SO)-anno01_003-page0001"
> 		MIMETYPE="image/tiff"
> 		SEQ="1"
> 		USE="master">
> xlink:href="file:///digital_obj/b859t(SO)/anno01_001/page_master_0001.tif 
> "/>
> 		</mets:file>
> 	</mets:fileGrp>
> 	<mets:fileGrp USE="screen">
> 		<mets:file
> 		ID="b859t(SO)-anno01_003-page0001-screen"
> 		GROUPID="b859t(SO)-anno01_003-page0001"
> 		MIMETYPE="image/jpeg"
> 		SEQ="1"
> 		USE="screen">
> xlink:href="file:///digital_obj/b859t(SO)/anno01_001/page_screen_0001.jpg 
> "/>
> 		</mets:file>
> 	</mets:fileGrp>
> </mets:fileSec>
> <mets:structMap TYPE="physical">
> 	<mets:div ORDER="1" LABEL="Some ancient old magazine">
> 		<mets:div TYPE="page" ORDER="1" ORDERLABEL="Page 1">
> 			<mets:fptr FILEID="b859t(SO)-anno01_003-page0001-master"/>
> 			<mets:fptr FILEID="b859t(SO)-anno01_003-page0001-screen"/>
> 		</mets:div>
> 	</mets:div>
> </mets:structMap>
> ----------------------------------------------
> Ahhh, you can't imagine how much it helps to write such a posting :) .
> I already found the answer for now: With <fptr FILEID> I can of  
> course only
> refer to <mets:file ID>s, not to any other parameter of the  
> <mets:file>.
> But is there a way to do so? Referring to a <mets:file GROUPID> from  
> within
> the structmap (maybe involving ID or CONTENTIDS - but I am  
> completely unsure
> here)?
> If there is no way for such a thing - do I understand it correctly,  
> that the
> GROUPID remains only useful for the XML renderer in charge?
> Thanks for your help and for trying to understand my concerns,
> best regards,
> Wolfram Zieger, Florence, Italy

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