 |
 |
On Mar 23, 2005, at 5:11 PM, Riley, Jenn wrote: > The FRBR report itself may not do a good job explaining the > relationship > between Manifestation and Expression - certainly it's a topic of much > discussion. But I do think the intention is to have a many to many > relationship between Expression and Manifestation. The diagram on p. 13 > (printed p. 13, p. 21 of the PDF file at > <http://www.ifla.org/VII/s13/frbr/frbr.pdf>) shows a double arrow at > both sides of the link between Expression and Manifestation, indicating > a many to many relationship. The text on this page similarly says "An > expression may be embodied in one or more than one manifestation; > likewise a manifestation may embody one or more than one expression." Hm. You're right, although it's odd they didn't clarify that in section 5.1 when they had the chance. > Yep, this makes sense, thanks! In the first model you presented in your > original response, with separate METS documents for each entity, I can > now see it would be easy to point multiple Expression documents to the > same Manifestation document. But could one do this within a single METS > document, and a single structMap? I guess I would need for you to define exactly what you mean by an "Expression document". FRBR is about bibliographic records, after all, and I interpret that as mainly being about descriptive cataloging. So, if I had descriptive metadata records for the expression of an Album and for each individual song on it, I wouldn't bother with multiple METS records or <mptr>s. I would have a <structMap> which had a root <div> for the album, a subsidiary <div> for each song, and each of those <div>s would have a DMDID reference to their appropriate 'expression' descriptive metadata record. In that case, haven't I satisfied the need to link the manifestions with the various bibliographic records for the expressions, and done so in a single <structMap>? <structMap> can describe a physical structure that is very specific to a particular manifestation of an expression, e.g., describing the folio and page structure of a particular 'item' for a work, which you might page scan and link to that <structMap>. However, it's also perfectly valid to define an abstract, logical <structMap> which can be equally applied to the text of a screenplay and a video file of the resulting movie. In those cases, I think you'd have to say the <structMap>'s <div> hierarchy is actually a structural description of the 'work/expression' in the FRBR sense, and that the <fptr> and <mptr> elements link from the structural description of the work/expressions to the manifestations/items. I think in crafting a <structMap> and the links from the <structMap> to descriptive metadata you need to keep in mind what exactly you're structurally describing and link appropriately. Jerome McDonough Digital Library Development Team Leader Elmer Bobst Library, New York University 70 Washington Square South New York, NY 10012 (212) 998-2425 [log in to unmask]