On Thu, 18 Mar 2010, Jonathan Rochkind wrote:

> Joe Hourcle wrote:
>> 
>> The group's two proposals were to model aggregates as works, or as 
>> manifestatons, so RDA seems to be on their own modeling them as 
>> expressions:
>
> See, this is what I don't understa.d "As works, or as manifestations"??  In 
> the FRBR model, every single manifestation belongs to _some_ Work, does it 
> not?  So I don't understand how those can be alternatives. Or was the 
> proposal to change this? So some manifestations exist "free floating" 
> belonging to no work at all? (By "belonging to" in FRBR terms of art, I mean 
> in the FRBR model, every manifestation is "the embodiment of" SOME 
> expression, which is "the realization of" SOME Work. Whether that expression 
> or work are yet described or not, they're there in the model.  Was the 
> proposal really to change this, so some manifestations are  by definition 
> "the embodiment of" no expression at all, not even an expression that has yet 
> to have an identifier assigned to it? That seems horribly mistaken to me).

There's a many-to-many relationship between Expressions and 
Manifestations in FRBR, so a single Manifestation can encompass multiple 
Expressions (and therefore, multiple Works).

In the Aggregates-as-Manifestations model, something like the 'Complete 
Works of ...' would exist as a new manifestation, but *not* as a new work. 
(and those individual works might never exist as individual 
manifestations)

It's of course much more simple to express some items (such as the 
Canterbury Tales) as a single work (Aggregations-as-Works), and then just 
make an expressions of them, and the corresponding dozens of possible 
manifestations.  I guess it'd be the FRBR equivalent of data 
normalization.  And aggregating at the work levels makes it easier to 
reconcile the cases where different catalogers can't agree if it's a 
single object or multiple objects.

I'm torn -- I think both are valid ways of describing the relationships, 
and different domains are going to try to go the route that makes the most 
sense for them.  (which is likely, which one's the least cost to implement 
while giving them the functionality they want)

-Joe