I admit I'm not seeing the problem with your scenario, I like the 
"contains" solution.

The "contains" relationship hangs off of whatever entities you choose to 
hang it off of, no?

If neither you nor anyone else has chosen to do the authority work to 
collocate, say, different "versions" of "Moby Dick with preface, 
appendixes, Hart Crane poem" as expressions or works (quite likely that 
nobody will), then the containing entity is simply a manifestation.  

I am not entirely sure what you mean by "a unit card view", or what kind 
of "non unit card view" you'd want to provide, but it seems to me this 
data structure encodes the data that matters in a machine readable way, 
and should be able to support many diverse kinds of interface.

A point we often come to in these conversations, my own denseness is 
leaving me confused about the nature of hte problem you are identifying 
-- I'm not seeing a problem.

Jonathan

Karen Coyle wrote:
> 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
>>>
>>>
>>>       
>
>