Quoting "Beacom, Matthew" <[email protected]>:
Work: Moby Dick with preface, appendices, Hart Crane poem (I'd call
this an aggregate work)
Includes: (Work) preface (by someone)
Includes: (Work) Poem (by Hart Crane)
Includes: (Work) Moby Dick (by Herman Melville)
Expression: Moby Dick with preface, appendices, Hart Crane poem
Includes: (Expression) preface (by someone)
Includes: (Expression) Poem (by Hart Crane)
Includes: (Expression) Moby Dick (by Herman Melville)
Manifestation: Moby Dick with preface, appendices, Hart Crane poem
Contains: (Work/Expression) preface (by someone)
Contains: (Work/Expression) Poem (by Hart Crane)
Contains: (Work/Expression) Moby Dick (by Herman Melville)
How are the WEM of each separate resource here connected? In other
words, do you have a Work entity defined for "preface" that links to
an expression entity for "preface", and do they all have identifiers?
(This really needs a diagram!) It seems like somewhere you need:
(Expression) preface --> expresses --> (Work) preface
That would have to exist outside of this particular description, right?
kc
Other expression groups of the above could be those same works
translated to French or Russian or Chinese. One could think of
others, but they might all get more complicated than straight
translation.
Other manifestation groups of the above could be a hard bound deluxe
edition, a hard bound trade edition, a trade paper edition and a
mass market edition with the only physical differences being covers
and paper quality/size. Add a few proprietary e-versions, if you want.
With regard to RDA, I think you are still working with a more or
less traditional catalog model that begins with inventory control of
physical items in a collection (whether tangible or virtual,
whether local or distributed.) The new aspects of RDA enhance our
ability to connect the items to one another at the manifestation,
expression and work levels.
I don't think RDA goes as far as you want it to go. But I'm not sure
there is any other model to follow. One has to connect
abstractions like work to actual items one can use. A reference to
a work without some linkage to an item that embodies it is a dead
end.
Matthew Beacom
-----Original Message-----
From: Code for Libraries [mailto:[email protected]] On Behalf
Of Karen Coyle
Sent: Monday, March 22, 2010 1:10 PM
To: [email protected]
Subject: Re: [CODE4LIB] Variations/FRBR project relases FRBR XML Schemas
Quoting Jonathan Rochkind <[email protected]>:
A big mistake, if it means what we think it means, that RDA has decided
that a given Manifestation can not contain several Expressions.
I'm not sure they've actually stated that, although that seems to be
the implication. I think they intend for you to use the "contains"
and "contained in" relationship that can apply to any WEMI entity. And
this is where RDA's implementation of FRBR becomes difficult when I
try to think of how to present this to the user --
Work: Moby Dick
Expression: Moby Dick with preface, appendices, Hart Crane poem
Contains: (Work/Expression) preface
Contains: (Work/Expression) Hart Crane Poem
Manifestation: Moby Dick with preface, appendices, Hart Crane poem
?Contains: preface
?Contains: Hart Crane Poem
While there may be some logic here, it seems like this just reproduces
the "unit card" view that we have today, with a manifestation and
added entries. I don't know what entity the "contains" hangs off of,
or if it can be related both to the expression and the manifestation.
I need to think about this more, but I don't see how this lets us
provide a non-unit card view for users, which is what I was hoping we
were working toward. Although perhaps the idea is to build that on top
of the unit card view, after taking apart the records... It might wok,
I really want to try to model this. Wish we could get some folks
together for a 1/2 day somewhere and JUST DO IT.
kc
Riley, Jenn wrote:
What the RDA folks (that is, the folks
who have created RDA, the JSC members) said (some of them off-list to
me), is that if your manifestation is an aggregate, then your
Expression must be an equal aggregate. So the Expression is pretty
much one-to-one with the Manifestation. (And I think we were all
seeing a many-to-many.)
I see this conclusion as RDA's, but not FRBR's. The FRBR report explicitly
says there can be a many-to-one relationship between Expressions and a
Manifestation (that is, a Manifestation can embody several
Expressions), and
the V/FRBR project takes that at face value and does not impose the
additional restriction that a Manifestation contains an equal
aggregate. RDA
may impose that restriction, but that's their implementation of FRBR, and
the V/FRBR project as *not* an RDA implementation doesn't feel
bound by that
decision.
Obviously I think that RDA has made a mistake in adding in a requirement
that "if your manifestation is an aggregate, then your Expression
must be an
equal aggregate." But that's their business, I guess.
Jenn
========================
Jenn Riley
Metadata Librarian
Digital Library Program
Indiana University - Bloomington
Wells Library W501
(812) 856-5759
www.dlib.indiana.edu
Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
--
Karen Coyle
[email protected] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
--
Karen Coyle
[email protected] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
