Also found at: http://ac.bslw.com/community/blog/2010/10/backstage-plans-for-rda-bibliograp hic-record-handling/ Introduction There has been a lot of talk recently regarding what options are available to our clients when it concerns their RDA bibliographic records. We realized this was a great opportunity to discuss with you our tentative plans during this testing phase. Our company has always been interested in providing our customers with different processing options, and with RDA there is no better time than to address this. The testing phase officially began October 1, 2010. During this phase, it is likely that some practices will be adjusted according to user feedback or official declarations. We anticipate that our own plans will change with respect to this kind of workflow, though we do have a clear idea of how to move forward from this point. During the testing phase, the Backstage Authority Control Service will treat any bibliographic record that contains "040 $e RDA" as an RDA bibliographic record. This means that all headings within such a record will be treated as if they were RDA headings, rather than a mixture of both AACR2 & RDA headings. This will make it easier for our system to differentiate what kinds of processing options are available to our clients. Our authority service includes cleaning up your bibliographic records (when necessary) through our Bibliographic Validation routines. It also involves cleaning up and matching your bibliographic headings against national databases of your choice, through our Authority Matching routines. As RDA is becoming more actively integrated into our clients' records, we need to have different processing options in place, which affects both Validation and Matching. Bibliographic Validation For Validation, if the bibliographic record is identified as RDA (040 $e RDA), our system can still apply most of the over 100 rules that are run routinely on your AACR2 bibliographic records: . 010, 020, 022, 034 Field Validation ( <http://ac.bslw.com/community/wiki/index.php5/Profile_Guide_Step_2.2> wiki) . Leader and Fixed Field Updates ( <http://ac.bslw.com/community/wiki/index.php5/Profile_Guide_Step_2.3> wiki) . Tag Updates and Field Deletes ( <http://ac.bslw.com/community/wiki/index.php5/Profile_Guide_Step_2.4> wiki) . Indicator Updates ( <http://ac.bslw.com/community/wiki/index.php5/Profile_Guide_Step_2.6> wiki) . Initial Article Validation ( <http://ac.bslw.com/community/wiki/index.php5/Profile_Guide_Step_2.8> wiki) We have chosen, for now, to exclude other rules until we have gathered more information about how including them will affect your RDA bibliographic record validation: . *Subfield Code Updates and Deletes ( <http://ac.bslw.com/community/wiki/index.php5/Profile_Guide_Step_2.5> wiki) . Special MARC21 Field Conversions and Additions ( <http://ac.bslw.com/community/wiki/index.php5/Profile_Guide_Step_2.7> wiki) . GMD Standardization ( <http://ac.bslw.com/community/wiki/index.php5/Profile_Guide_Step_2.9> wiki) While most of the Subfield Code Updates and Deletes will actually still be applied to RDA bibliographic validation, there are a few key rules pertaining to <http://ac.bslw.com/community/wiki/index.php5/Profile_Guide_Step_2.5#Relator _Subfield_.24e_Deletions> relator terms that we need to explore further and will be turned off. Our system will also not be spelling out abbreviations for RDA bibliographic validation, except in very specific scenarios: . Bible headings which contain "O.T." and "N.T" will be spelled out to "Old Testament" and "New Testament", respectively, if there is no individual book or part, and if there is, the system will delete "O.T." and "N.T." . Latin abbreviations will be replaced with the appropriate phrases in 260 fields. We have extensive lists for AACR2 bibliographic records where we abbreviate words within the headings. Our plan is to utilize these same lists to reverse the process and spell out abbreviations in RDA bibliographic records, though the rub right now is determining which ones to include and which to exclude. Back in <http://ac.bslw.com/community/blog/2010/04/announcing-new-300-field-validati on/> April 2010, we added the 300 field as part of our standard validation, which included many different kinds of changes. For RDA bibliographic validation, these changes will also be turned off at this time. Authority Matching Since late August 2010, Library of Congress (LOC) has been distributing new RDA authority records in conjunction with AACR2 authority records that contain RDA headings. LOC will not create an RDA authority record unless there is no equivalent AACR2 authority record that exists. If there is an existing AACR2 authority record, then LOC will add the RDA heading to the matching AACR2 authority record in a <http://ac.bslw.com/community/blog/2010/09/rda-testing-and-policies/> 7XX field. Please note that these types of authority records are now being distributed to our clients. Most likely, your ILS will load these authority records without any issues. If you do experience any difficulties, please contact us and we can remove the fields if necessary until a better solution is in place. For Matching, we have four possible options. We anticipate the number of options to increase once all of the parameters have been ironed out during the testing phase: 1. Run RDA bibliographic records as if they are AACR2. This option will not represent any change on our part. If our system runs across an RDA bibliographic record (040 $e RDA), it will treat all headings as if they are AACR2. Authorities returned will be AACR2 authority records. 2. Ignore RDA bibliographic records. Some libraries may desire that their RDA bibs are not processed yet since the testing phase is still ongoing. We can set these RDA records aside to not process. 3. Match AACR2 bib headings against AACR2 authorities. Match RDA bib headings against RDA authorities or against 7XX fields in existing AACR2 authority records. This option is more involved as the system will attempt a match against a 7XX RDA authority heading (within an AACR2 authority record) if there is no new RDA authority to check against. 4. Match the unmatched bib heading from #3 above to available authority record. For instance, if you have an RDA heading that you are trying to match against either a new RDA authority record or an RDA heading within an AACR2 authority record, and your heading doesn't match either of these databases, what would you like to see happen? Should our processing then attempt to find a match for that RDA heading against an AACR2 authority record? Please consider the above options and let us know how you would prefer your RDA bibliographic records to be processed in our system. Conversions Our ultimate plan with RDA is to provide our clients with a few different options when it comes to conversions. However, we also realize that some conversions can only be one-way and may encounter significant issues going back-and-forth (e.g., abbreviations). At this time, we are not providing conversions of AACR2 bibliographic records to RDA bibliographic records, or vice versa. It is something we are interested in, and would welcome any feedback to help refine our intent. Conclusion The aim with RDA processing by Backstage is to offer our customers the kinds of options that make sense during this testing phase. We want the processing to continue to remain as seamless as possible from your point of view, while at the same time addressing any concerns you may have. Please feel free to contact us with any questions: Nate Cothran <mailto:nate@bslw.com> nate@bslw.com Jeremy Myntti <mailto:jmyntti@bslw.com> jmyntti@bslw.com Judy Archer <mailto:jarcher@bslw.com> jarcher@bslw.com Karen Anderson <mailto:kanderson@bslw.com> kanderson@bslw.com -- Chad Cluff Systems Development Backstage Library Works 1-800-288-1265 ext. 696 Direct: 1-801-342-5696 ccluff@bslw.com http://ac.bslw.com/community/blog