Of course, RDA 1.8 doesn't _require_ an element to do double duty as both transcription and access point, it merely permits it. There is nothing to prevent a given implementation community from not applying 1.8 and creating separate elements in all cases.
-----Original Message----- From: Resource Description and Access / Resource Description and Access [mailto:[EMAIL PROTECTED] On Behalf Of Ed Jones Sent: Tuesday, May 06, 2008 12:46 PM To: [email protected] Subject: Re: [RDA-L] RDA Vocabularies Project True: I had forgotten RDA 1.8. -----Original Message----- From: Resource Description and Access / Resource Description and Access [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Rochkind Sent: Tuesday, May 06, 2008 11:56 AM To: [email protected] Subject: Re: [RDA-L] RDA Vocabularies Project If RDA instructs the cataloger to create only one data element to serve two purposes, then it's an RDA problem. If RDA instructs the cataloger to create two data elements (or gives an option of two, with a legacy option of one for legacy data), but MARC doesn't allow separate data fields for those two elements--then it becomes a MARC problem. Jonathan Ed Jones wrote: > This is an artifact of the card catalog, where such double-duty elements > made perfect sense. The elements involved are typically the title of > the resource being described and/or the title of the resource of which > it forms a component part (series, multivolume monograph, etc.). Having > said that, I think this is more a problem of MARC 21's double-duty > datafields (specifically 245 and 440) than of RDA. > > Ed Jones > National University (San Diego, Calif.) > > -----Original Message----- > From: Resource Description and Access / Resource Description and Access > [mailto:[EMAIL PROTECTED] On Behalf Of Kevin M. Randall > Sent: Tuesday, May 06, 2008 10:26 AM > To: [email protected] > Subject: Re: [RDA-L] RDA Vocabularies Project > > At 10:52 AM 5/6/2008, Karen Coyle wrote: > >> Would it be possible to separate the descriptive transcription of >> > fields > >from the linking and relationships between "resources" (considering a > >> book a resource AND the series itself as a resource). In the talk I did >> at Code4Lib I used the publisher name as an example. There would be >> > good > >> reasons to link bibliographic records to records for publishers (at >> least for modern works). The latter could have contact information or >> > at > >> least link to the publisher information in ones acquisitions system. >> This is NOT the same information as the transcribed publisher name that >> is in the publication statement. >> > > That last sentence is spot on. It seems that we've gotten so afraid of > redundancy that we think things that often *look* the same actually > *are* > the same. But to record the same name in a publisher statement as well > as > a publisher access point is not redundancy at all. They are two > different > things. Likewise with series, statement of responsibility, etc. (For > example, WorldCat Local shows how horrible it is to confuse the > different > properties and functions by getting rid of the statement of > responsibility > and then trying to replace it with a "made up" statement taking some of > the > data appearing in 1XX/7XX fields.) > > So yes, it is possible--and necessary--to separate description and > linking/access. (That is, when we're talking about access in terms of > authority-controlled elements.) We used to do it all the time; AACR2 > codified it. We're in danger of losing what we gained in the move from > AACR to AACR2, if don't keep in mind the essential differences between > elements. It's happened in WorldCat Local, in some CONSER standard > records, and elsewhere. Turning everything into data elements is a good > thing, as long as we remember what those data elements are for and don't > assign functions to them that they can't fulfill. > > Kevin > > Kevin M. Randall > Principal Serials Cataloger > Bibliographic Services Dept. > Northwestern University Library > 1970 Campus Drive > Evanston, IL 60208-2300 > email: [EMAIL PROTECTED] > phone: (847) 491-2939 > fax: (847) 491-4345 > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu
