RDA is meant to appeal to a variety of user communities, and some of them may opt not to apply some of its provisions. RDA 1.8 is one such provision: it states that certain elements "may" be used for both purposes; to me, this means that they also may not. It moves the decision to the level of the particular community implementing RDA. I don't see it as that big a deal, but maybe I'm missing something.
To give a scenario: My community decides on the rigid separation of description and access and receives a shipment of records from a community that applies RDA 1.8. On these records the descriptive elements are doing double duty, so for my own system I automatically massage the records to generate (1) a controlled access point field and (2) a provisional authority record from the data in each double-duty field (e.g., in MARC terms, generate a 240 from a 245 or an 830 from a 440). The records can now enter my system and conform to my implementation of RDA (with the description in unindexed 245 and 440 and access points in corresponding authority-controlled 240 and 830 fields). I would be more worried if RDA talked about generating description from access points--Kevin's example from WorldCat Local--but RDA 1.8 is a one-way system: only generating access points from description (specifically titles, which are fairly straightforward) and not vice versa. I'm not disagreeing with the end. I just think RDA as written is capable of accomplishing that end. Ed -----Original Message----- From: Resource Description and Access / Resource Description and Access [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Rochkind Sent: Tuesday, May 06, 2008 1:41 PM To: [email protected] Subject: Re: [RDA-L] RDA Vocabularies Project By ignoring RDA and coming up with their own guidelines for creating metadata? I mean, there's nothing to prevent a given implementation community from ignoring RDA entirely and doing whatever they want. But that sort of defeats the purpose of RDA if we're _counting_ on that, no? Am I missing something? Jonathan Ed Jones wrote: > 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 > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu
