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 ensue.
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 exists.
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
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 modelling.
> 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