On Thu, 18 Mar 2010, Jonathan Rochkind wrote:
> Karen Coyle wrote:
>> naturally favors the package over the contents. So we'll have some works
>> that are what users think of as works, and other works that represent the
>> publisher's package -- which sometimes will be something that makes sense
>> to the user, but at other times, as in many music CDs, is bordering on the
>> arbitrary. If we present these all as works to the user, confusion will
> So it's up to our systems to NOT present things that way, right? If a
> particular Work is just an aggregate which is not that meaningful to the
> user, it shouldn't be presented (at least in initial result sets), the
> meaningful expressions/manifestations should be presented, right? I'm not
> entirely clear on your example demonstrating that, but I believe you that it
I would personally assume so -- you don't want someone searching to see if
you have a copy of 'Hamlet', and all you have is 'The Collected Works of
William Shakespeare' and so your system reports that you don't.
Of course, depending on what the user asks for affects what we respond
back with -- even if we have 27 copies of 'Hamlet', we wouldn't respond
with 27 records back in response to their request. It's entirely possible
(and probable) that systems track objects at a granularity other than
what's presented back to the user.
If someone's searching for a specific song, so we expect them to know the
names of every album it's been on? Yes, our local catalog might only
track the albums, but if there's some sort of indication that they're
aggregations, we know that we might need to expand them to be able to
answer the question.
> The way I see it, our architectural job is _first_ to create a data model
> that allows all the neccesary things to be expressed, THEN create systems
> that use those necessary expressed things to create reasonable displays.
> I'm still thinking my interpretation (which is not JUST mine, I don't think I
> even invented it) of aggregate modelling is the only sane one I've seen that
> allows us to model what in many use cases we'd be allowed to model, without
> forcing us to model what in many use cases cost-benefit would not justify
It's a *reference* *model* ... it is *not* an implementation. Everyone's
allowed to model anything you want.
>> In the RDA relationships (which I've summarized here
>> http://kcoyle.net/rda/group1relsby.html) there seem to be two kinds:
>> intellectual relationships, and bibliographic relationships. "Is adapted
>> from" is an intellectual relationship; "Contains" is a bibliographic
>> relationship. They're all mixed together as if they are the same thing.
> I think you may very well be right that there some be more clarification in
> the model here. I haven't thought about it enough.
> There definitely needs to be more clarification in the model as to how to
> handle aggregates. At one point there was a working group on that, I'm not
> sure what happened to it. Of course, if the working group came up with
> something OTHER than my preferred interpretation, I'd be very unhappy. :)
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
I don't know what happened at the August 2009 meeting, though. William
Denton had a breakdown of the August 2008 meeting, which explained
some of the issues that they were considering: