Karen,

Is see your depiction of the Moby Dick example

Work: Moby Dick
Expression: Moby Dick with preface, appendices, Hart Crane poem
   Contains: (Work/Expression) preface
   Contains: (Work/Expression) Hart Crane Poem
Manifestation: Moby Dick with preface, appendices, Hart Crane poem
   ?Contains: preface
   ?Contains: Hart Crane Poem

This way:

Work: Moby Dick with preface, appendices, Hart Crane poem (I'd call this an aggregate work)
   Includes: (Work) preface (by someone)
   Includes: (Work) Poem (by Hart Crane)
   Includes: (Work) Moby Dick (by Herman Melville)
Expression: Moby Dick with preface, appendices, Hart Crane poem
   Includes: (Expression) preface (by someone)
   Includes: (Expression) Poem (by Hart Crane)
   Includes: (Expression) Moby Dick (by Herman Melville)
Manifestation: Moby Dick with preface, appendices, Hart Crane poem
   Contains: (Work/Expression) preface (by someone)
   Contains: (Work/Expression) Poem (by Hart Crane)
   Contains: (Work/Expression) Moby Dick (by Herman Melville)

Other expression groups of the above could be those same works translated to French or Russian or Chinese. One could think of others, but they might all get more complicated than straight translation.

Other manifestation groups of the above could be a hard bound deluxe edition, a hard bound trade edition, a trade paper edition and a mass market edition with the only physical differences being covers and paper quality/size. Add a few proprietary e-versions, if you want.  

With regard to RDA, I think you are still working with a more or less traditional catalog model that begins with inventory control of physical items in a collection (whether tangible or virtual, whether local or distributed.) The new aspects of RDA enhance our ability to connect the items to one another at the manifestation, expression and work levels.

I don't think RDA goes as far as you want it to go. But I'm not sure there is any other model to follow.  One has to connect abstractions like work to actual items one can use. A reference to a work without some linkage to an item that embodies it is a dead end.

Matthew Beacom

-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Monday, March 22, 2010 1:10 PM
To: [log in to unmask]
Subject: Re: [CODE4LIB] Variations/FRBR project relases FRBR XML Schemas

Quoting Jonathan Rochkind <[log in to unmask]>:

> A big mistake, if it means what we think it means, that RDA has decided
> that a given Manifestation can not contain several Expressions.

I'm not sure they've actually stated that, although that seems to be  
the implication. I think they intend for you to  use the "contains"  
and "contained in" relationship that can apply to any WEMI entity. And  
this is where RDA's implementation of FRBR becomes difficult when I  
try to think of how to present this to the user --

Work: Moby Dick
Expression: Moby Dick with preface, appendices, Hart Crane poem
   Contains: (Work/Expression) preface
   Contains: (Work/Expression) Hart Crane Poem
Manifestation: Moby Dick with preface, appendices, Hart Crane poem
   ?Contains: preface
   ?Contains: Hart Crane Poem

While there may be some logic here, it seems like this just reproduces  
the "unit card" view that we have today, with a manifestation and  
added entries. I don't know what entity the "contains" hangs off of,  
or if it can be related both to the expression and the manifestation.  
I need to think about this more, but I don't see how this lets us  
provide a non-unit card view for users, which is what I was hoping we  
were working toward. Although perhaps the idea is to build that on top  
of the unit card view, after taking apart the records... It might wok,  
I really want to try to model this. Wish we could get some folks  
together for a 1/2 day somewhere and JUST DO IT.

kc


>
> Riley, Jenn wrote:
>>> What the RDA folks (that is, the folks
>>> who have created RDA, the JSC members) said (some of them off-list to
>>> me), is that if your manifestation is an aggregate, then your
>>> Expression must be an equal aggregate. So the Expression is pretty
>>> much one-to-one with the Manifestation. (And I think we were all
>>> seeing a many-to-many.)
>>>
>>
>> I see this conclusion as RDA's, but not FRBR's. The FRBR report explicitly
>> says there can be a many-to-one relationship between Expressions and a
>> Manifestation (that is, a Manifestation can embody several Expressions), and
>> the V/FRBR project takes that at face value and does not impose the
>> additional restriction that a Manifestation contains an equal aggregate. RDA
>> may impose that restriction, but that's their implementation of FRBR, and
>> the V/FRBR project as *not* an RDA implementation doesn't feel bound by that
>> decision.
>>
>> Obviously I think that RDA has made a mistake in adding in a requirement
>> that "if your manifestation is an aggregate, then your Expression must be an
>> equal aggregate." But that's their business, I guess.
>>
>> Jenn
>>
>> ========================
>> Jenn Riley
>> Metadata Librarian
>> Digital Library Program
>> Indiana University - Bloomington
>> Wells Library W501
>> (812) 856-5759
>> www.dlib.indiana.edu
>>
>> Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
>>
>>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet