Print

Print


Hello...

> 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
> valid.

You are right (of course!). 
I understand it now - also because I start to think about building a simple .xslt (for easy entry checking stuff). At this point it becomes clearly visible that it's not going to work the way I wanted it :) - you named all the reasons.

> rather than trying to implement a localized solution that would be
> incompatible with others' encodings.

No, that is absolutely not the way to go here. 
I am glad that you took your time to answer - thanks for the advice!

Best regards,
Wolfram Zieger, Florence


Wolfram Zieger
-----------------------------------------------------------
IT Struktur Support

Kunsthistorisches Institut in Florenz - Max-Planck-Institut 
Via Giuseppe Giusti 44
50121 Firenze
Italia

Tel:    +39 055-2491 159
e-mail: [log in to unmask]
web:    www.khi.fi.it

KHI-intern: 
- Telefon:  259
- Standort: B├╝ro im Anschluss an Bereich S (Photothek)


> -----Urspr├╝ngliche Nachricht-----
> Von: Metadata Encoding and Transmission Standard [mailto:[log in to unmask]]
> Im Auftrag von Jerome McDonough
> Gesendet: Mittwoch, 11. November 2009 17:44
> An: [log in to unmask]
> Betreff: Re: [METS] Refering to <mets:file GROUPID> from the structmap?
> 
> 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
> valid.
> 
> 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">
> > 			<METS:FLocat LOCTYPE="URL"
> >
> xlink:href="file:///digital_obj/b859t(SO)/anno01_001/page_master_0001.t
> if
> > "/>
> > 		</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">
> > 			<METS:FLocat LOCTYPE="URL"
> >
> xlink:href="file:///digital_obj/b859t(SO)/anno01_001/page_screen_0001.j
> pg
> > "/>
> > 		</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]