 |
 |
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