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
> <>) 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
document".  FRBR is about bibliographic records, after all, and I
interpret that
as mainly being about descriptive cataloging.  So, if I had descriptive
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'
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
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]