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