I thought that RDA as a code used neither GMD _nor_ SMD, replacing those with the data elements that end up in the new mac 3xx fields? Can anyone confirm that, that there is no notion of 'smd' in RDA?
If so, there would be no answer to having every SMD registered in the RDA registry, nor to "way to indicate in RDA that the SMD should be ignored" -- RDA already ignores the SMD. No? Matching algorithms in union catalogs may have to be updated to take account of RDA. Of course, if people are just entering free text in the new 3xx MARC fields for RDA, instead of using a controlled vocabulary, that could still be a problem for matching algorithms. Exact same sort of problem as if people were/are entering free text instead of controlled vocabulary in the GMD/SMD of course. ________________________________ From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] on behalf of Deborah Fritz [debo...@marcofquality.com] Sent: Friday, April 22, 2011 2:52 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Cataloging playaways But what you do in the local catalog, does not actually stay in the local catalog, because records get batchloaded to WorldCat and other union catalogs (or catalogues) and, when that happens, what then will happen with the matching algorythms for deduping records if each record has a different SMD? 1 sound media player 1 pre-recorded MP3 player 1 pre-recorded digital audio player 1 Playaway 1 audio media player 1 digital media player 1) Is there an explicit code, currently in use in MARC--that we can use while we are creating RDA descriptions in a MARC environment, that will make it clear to a matching algorythm that this record is describing the same thing as that record, no matter what is in the 300$a? 2) And since this is the RDA-L not the MARC-L, is there a combination of RDA data elements that will reliably indicate that this description is describing the same thing as that description, no matter what is in the SMD, for whatever future matching we will need to do? 3) And/or is this another situation where The Registry could *really* help, so that every SMD is registered, before it is used in a description in a library environment, so that a matching algorythm can check the registry and match on 'variant' terms? And, if so, when will that become an integral part of our cataloging procedures? Deborah ------ Deborah Fritz MARC Database Consultant The MARC of Quality www.marcofquality.com<http://www.marcofquality.com/> Voice/Fax: (321) 676-1904 On Friday, April 22, 2011 10:58 AM , Ed Jones <ejo...@nu.edu<mailto:ejo...@nu.edu>> wrote: Julie, If you insist on a straight answer… If my library promoted them as Playaways and users knew them as Playaways, I would probably argue for calling them Playaways in the physical description. (As they say, What you do in the local catalog stays in the local catalog.) In an ideal world, where records carried more information in coded form, I would have a coded value in the record rather than a literal (something analogous to ONIX’s “AK”) and would leave it up to the local library what literal they wanted to have display in their catalog. In a shared catalog like OCLC, I would probably follow standard practice to the extent it exists. In 2008 the Playaway Cataloging Joint Task Force—yes, there was such a thing—recommended “1 sound media player” so I would probably go with that. http://www.olacinc.org/drupal/capc_files/playawaysPDF.pdf Ed On Thursday, April 21, 2011 5:07 PM , Julie Moore<julie.renee.mo...@gmail.com<mailto:julie.renee.mo...@gmail.com>> wrote: Ed, Are you saying that you would call it a: 300 1 pre-recorded MP3 player ? Just curious! Thanks, Julie On Wed, Apr 20, 2011 at 3:13 PM, Ed Jones <ejo...@nu.edu<mailto:ejo...@nu.edu>> wrote: FWIW, ONIX calls it a "pre-recorded MP3 player", which also seems to be the name used in the marketplace, if a Google search I just did is any indication (1.5 million results as a quoted string). The new "product form" was added to ONIX in early 2007. The RDA ONIX framework predates this (unless there is a newer version than version 1.0). http://www.onixtools.de/downloads/ONIX_Code_Lists_Issue_7_Changes.pdf Ed Jones --
