On Wed, 17 Mar 2010, Karen Coyle wrote:
> Quoting Jonathan Rochkind <[log in to unmask]>:
>> Well, I disagree with the "conclusion" on the RDA-L list, and said so
>> there too!
>>
>> If you have a collection that includes Beethoven's Symphony A, and
>> Beethoven's Symphony B, and Beethoven's Symphony A is also published
>> separately on its own --- how can it not be a work? And how can it not
>> be the same work in both places?
>
> I think this becomes a question of how we express WEMI -- you can always link
> from/to any WEMI using "contains" or "contained in" -- so you can always link
> to all of the Works in an aggregate. What I would like to achieve is for
> different decisions (like one community calling the aggregate a
> Work/Expression and another focusing on the individual works and linking
> those to a Manifestation) to not create incompatible data.
>
> I've had this ill-formed notion for a while that we shouldn't actually be
> creating WEMI as "things" -- that to do so locks us into a record model and
> we get right back into some of the problems that we have today in terms of
> exchanging records with anyone who doesn't do things exactly our way. WEMI to
> me should be relationships, not structures. If one community wants to gather
> them together for a particular display, that shouldn't require that their
> data only express that structure. I'm not sure FRBR supports this.
>
> sound vague? it is -- I wish I could provide something more concrete, but
> that's what I'm struggling with.
It's because FRBR is a reference model, not an implementation. Just as
there's no one 'correct' way to implement OAIS, there's no one
fixed way for FRBR.
FRBR gives us some ways to discuss the types of objects and attributes
that people commonly search for -- that doesn't mean that those are the
*only* objects or attributes that we can represent in our system. I'm of
the opinion that it'd be better to pull out the aggregation into seperate
objects within the model, rather than trying to force it into one of the
existing entities and have everyone try to do it differently.[1]
What's more important is that when we're getting to the point of trying to
compare our data between systems, we at least have common frame of
reference -- we have a language, so we can at least be more specific about
what it is that we're talking about, and then we can figure out how our
systems vary, and work around the differences.
[1] http://www.annoying.org/frbr/frbr_aggregate_works.txt
-Joe
(well, there goes my attempt at not getting sucked into this
conversation)
ps. I'm interestedabout the aggregate works issue because of dealing
with objects that exist as discrete objects, but can be collected up
in any number of ways; And in some cases, the membership into the
aggregation changes over time. (think of a 'top 100 list' where items
might get bumped out as new items are added)
pps. someone could model the Bethoveen's symphony as whole/part
relationships between expressions that all belong to the same work.
I'm not going to say it's the 'right' way to do it, but it could be
done. But there's the whole/part relationship allowed at *every*
level of the group 1 entities, so different people could handle it in
different ways:
http://vso1.nascom.nasa.gov/vso/misc/lib_metadata/figure2_nolabel.pdf
