As a core group within our department, we meet regularly to discuss our RDA Enrichment service. During these meetings, we talk about three topics: 1. What isn't working 2. What needs to be added 3. What needs further review We are continuing to make improvements to the service, though at this point, most of them are minor adjustments to programming we already have in place. Sometimes, it does mean we are adding in functionality where it didn't exist previously. Our hope is that as you become ready to address RDA within your system, you gain the confidence you may need by knowing that we are continually focusing our efforts on this. Here are some of the RDA updates we've discussed and have either implemented or are implementing shortly (*please note that these changes will only happen for clients that have filled out the RDA online profile): * Change <space>p. to <space>pages in 5xx notes * Change pagespages to pages in 300 $a, 5xx notes * Only spell out bracketed 260 $a info if RDA; even with this one, there are specific instances where certain state abbreviations are acceptable in RDA * Do not change 260 $a n.d. (or N.D.) to date of publication not identified; this should only be spelled out when appearing in 260 $c, otherwise it should be expanded to North Dakota * Tighten up programming for adding 9XX Enriched to RDA enriched bibs; this was acting like our normal change stamps so we are looking into making sure this tag (if desired) is added specifically to records that have been enriched / validated by our RDA processing, rather than just to any record that has been changed due to processing * We have a client that wants their non-RDA bibs to have access points updated only, but also wants their RDA bibs to have enrichment + validation; we decided in cases like this it makes sense to use 2 profiles: o 1) non-RDA bibs: run Step 5 only (which addresses access points in RDA) o 2) RDA bibs: run all of RDA profile * For our GMD to (33X) CMC processing, we are addressing what happens when the resulting set of 33X fields contains 2 or more 'unspecified': o If all three 33X (336, 337, 338) contain 'unspecified' then we are choosing to not add any of those fields to the record and report on it (R132 - CMC Not Added); o If 2 of the fields are 'unspecified', then we will report those out; in conjunction with this we are replacing our R130 - CMC Added report with R130 - CMC Unspecified instead as we feel this report would be more informative than CMC fields that have been added * We are also looking at changing the priority of checking certain fields when it comes to trying to establish the most correct set of 33X fields. Currently, we search for existing values in the following fields in this order: 245 $h GMD, LDR-06, LDR-07, 007-00, 007-01, 007-xx, 008-xx, 300 $a. But we have discovered that, in some cases, the 2nd 007 may contain the better field from which to derive the 33X fields; however, our system only considers the first 007 at this time. So we are looking into a couple different options: o If two 007 fields exist and are unique, then we look for 007-00 'c' (electronic resource) first; o Or consider checking 300 $a first when 2+ 007 fields exist; o We are testing both scenarios to see which may be the better fit for processing * Add a rule to change 'cm.' to 'cm' for all records (not just RDA only bibs); the 300 field no longer needs to end in a period and we have had a few requests to have this changed * Move existing $e rda to follow last $b in 040 field; note: we are not adding $e rda at any point during machine processing My team may have more to say on these (especially if I have misinterpreted any part of the above!). Also, please feel free to ask any questions you may have about the information presented today. Nate Cothran Vice President, Automation Services 25 East 1700 South Provo, Utah 84606 Phone: +1.800.288.1265, ext. 697 Direct: +1.801.342.5697 nate@bslw.com <mailto:nate@bslw.com?subject=Automation%20Services%20-%20Inquiry> * www.bslw.com <http://www.bslw.com>
