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