Print

Print


Is this problem a result of our not FRBRizing our records? FRBR was supposed to create Work records that would be linked to separate Expression records, which would in turn be linked to Manifestation records. You weren't supposed to have to put manifestation and expression information on work records. It seems that Ian is trying to encode Work and Expression information on Manifestation records. In Kevin's proposal, it is only the Expression information which is encoded there.

Kevin seems to be saying that in a fully robust bib and authority infrastructure, all the authors of a work or expression would be included on its authority. It seems that would create some headaches because contributing authors can vary a great deal between manifestations (editions). How would we decide which authors should be included on the expression record? Would we be adding and removing them as new editions came out?

Maybe the 700 really is better since the 240 can't be controlled. However, I wonder if maintaining the old concept of "main entry" is helpful just because it puts something recognizable at the top of the display. Title transcription can contain some rather odd elements at times. For example, some title pages of a work by Luigi Bonacciuoli call it "De foetus formatione," but the more common title is "Enneas muliebris." The meaning of the titles is different, with the first being more understandable. If you see the author's name and "Enneas muliebris" the top, you'll be more likely to recognize the work if you were looking for it.

So it seems the 240 vs. 700 issue is a display issue to some extent.

Ted Gemberling


From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Kevin M Randall
Sent: Friday, October 10, 2014 10:07 AM
To: [log in to unmask]
Subject: Re: [PCCLIST] use of field 240

Interesting suggestion, Ian.  I think I would rather go much further and just have the MARC record be a description of the manifestation, without any "main entry" at the top, something like this:

245 0? Title transcribed from resource
700 1# AAP for 1st author, $e author
700 1# AAP for 2nd author, $e author
700 1# AAP for editor, $e editor
700 12 AAP for author. $t Preferred title for work, qualified by data specific to the expression

(I'm still not convinced that a separate AAP for the work alone is necessary.)

But if our bib and authority infrastructure (and the systems using it) were more robust, I would say that the first three 700 fields above would be unnecessary, because they would be in an authority record for the work/expression.  All that's needed to tie the manifestation to the work/expression is the AAP for the expression.  (And an even *more* robust system would require just the expression identifier in the 700 field.)

These discussions are really highlighting the fact that, while it is possible to shoehorn RDA data into MARC records, RDA is really intended for a very different environment.

Kevin M. Randall
Principal Serials Cataloger
Northwestern University Library
[log in to unmask]<mailto:[log in to unmask]>
(847) 491-2939

Proudly wearing the sensible shoes since 1978!

From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Ian Fairclough
Sent: Friday, October 10, 2014 8:19 AM
To: [log in to unmask]<mailto:[log in to unmask]>
Subject: Re: [PCCLIST] use of field 240

PCCLIST readers,

Thanks again to those who've contributed to this discussion.  The most recent post is Robert Maxwell's.  His book, Maxwell's Handbook for RDA, contains the phrase "format agnostic" (page viii), about which I asked a while ago (post to RDA-L, June 2, 2014).  The phrase is germane to the discussion, which I'd like to refocus back onto the use of MARC encoding, and in more general terms rather than specifically as to whether "Works. Selections" represents a work or expression, with or without various qualifiers.  My concern applies also to cases like "Poems. Selections" and "Preferred title. Language into which it is translated".  Setting such concerns aside for the moment (if possible!) and generalizing, I wonder whether:

100  AAP for author, |e author.
240  Preferred title for work, qualified by data specific to the expression
245  Title proper (as transcribed from preferred source).

is a practice that should be replaced by:

100  AAP for author, |e author.
245  Title transcribed from preferred source.
700 1_ AAP for author. |t Preferred title for work.
700 12  AAP for author. |t Preferred title for work, qualified by data specific to the expression.

Responding to Ted Gemberling's earlier question "Why would that be better than using the 240?":

If you concatenate the data in 100/240 as presented above, you get
AAP, author.  Preferred title for work
The relationship designator is obviously out of place in a field that represents the work or expression.  And the data is performing double duty, in these respects:
1. Field 100 is an access point qualified by the relationship term in subfield e, as well as a linking term for the preferred title;
2. Field 240 is a preferred title for work, however, it is also serving as preferred title for an expression of that work.  Particularly if a language into which the work has been translated is given.

Although use of MARC 700 duplicates the AAP for author data, it avoids having the 100 and 240 fields do double duty.  Despite the duplication, perhaps our records would be better if each field has just one function.

If I'm mistaken I'd appreciate correction.  In practical terms: is there any reason why not to prepare MARC records according to the second way?  (In OCLC Connexion, it has the added advantage that 700 fields with subfield t can be controlled, whereas field 240 cannot.)

Sincerely - Ian

P.S. Recording for reference purposes: Applicable guidelines are
100: RDA 9.19 & I.1, plus LC-PCC PS link to the document PCC Guidelines for the Application of Relationship Designators in Bibliographic Records
240: RDA 5.5
245: RDA 2.3.2

Ian Fairclough
Cataloging and Metadata Services Librarian
George Mason University
703-993-2938
[log in to unmask]<mailto:[log in to unmask]>