On Wed, 17 Mar 2010, Karen Coyle wrote:
Quoting Jonathan Rochkind <[email protected]>:
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
