 |
 |
Quoting "Beacom, Matthew" <[log in to unmask]>: > > 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:[log in to unmask]] On Behalf > Of Karen Coyle > Sent: Monday, March 22, 2010 1:10 PM > To: [log in to unmask] > Subject: Re: [CODE4LIB] Variations/FRBR project relases FRBR XML Schemas > > Quoting Jonathan Rochkind <[log in to unmask]>: > >> 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 > [log in to unmask] http://kcoyle.net > ph: 1-510-540-7596 > m: 1-510-435-8234 > skype: kcoylenet > -- Karen Coyle [log in to unmask] http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet