An excellent question as to what is considered the default for RDA bib processing. Here are the list of options (with #1 being the default unless our clients tell us otherwise): 1. Match RDA bibs as if they are AACR2 bibs, so RDA headings are matched against AACR2 authmaster (default) 2. Ignore RDA bibs when our system encounters them as part of mixed file of AACR2 bibs & RDA bibs 3. Match AACR2 headings against AACR2 authmaster, RDA headings against RDA authmaster 4. If no match in #3 above, match AACR2 headings against RDA authmaster, RDA headings against AACR2 authmaster We have already had a couple requests for option #2 (ignore RDA bibs), though there has been interest for all options. For #2, we will need to manually separate out the files prior to processing, otherwise option #1 (match RDA as AACR2) will take precedence; however, by late next week our system should be able to ignore these bibs as it runs across them (obviating the need to manually separate the records). Up to this point, we were undecided as to how to process the RDA bibs and AACR2 bibs. So some of our clients may have received RDA authorities since our system would attempt to find a suitable match either on an RDA authority or AACR2 authority. On November 2 (tomorrow), the two authority databases will be maintained separately within our system. This ensures that your headings are searched only against the authorities you specify, even during the testing phase. Of course if an RDA authority is available and your processing is setup to match against the RDA authmaster, and there is a match, that matching RDA authority will be returned to your institution. Starting tomorrow, the only time you should receive new RDA authority records is if you instruct us to match against the RDA authmaster. We hope to have more concrete numbers as to the number of RDA authorities later this week to give you an idea of how many have been distributed by Library of Congress to Backstage. Nate Cothran Backstage Library Works From: bslwac-bounces@mailman.xmission.com [mailto:bslwac-bounces@mailman.xmission.com] On Behalf Of Carras, Darla Black Sent: Monday, November 01, 2010 11:58 AM To: 'Backstage Library Works Authority Contol Listserv' Subject: Re: [BSLWAC] Backstage Plans for RDA Bibliographic Record Handling What is the default option? What will happen to RDA records in our current cataloging files if we have not given you instructions? Darla Carras Head, Catalog Management Unit University Library System University of Pittsburgh 412-244-7541 dcarras@pitt.edu From: bslwac-bounces@mailman.xmission.com [mailto:bslwac-bounces@mailman.xmission.com] On Behalf Of Chad Cluff Sent: Monday, November 01, 2010 1:46 PM To: bslwac@mailman.xmission.com Subject: [BSLWAC] Backstage Plans for RDA Bibliographic Record Handling 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

Up to this point we have been delivering RDA authority records combined with AACR2 authority records. So far the percentage of RDA authorities mixed in with AACR2 authorities has been typically less than 0.2%-there are very few RDA authorities being delivered to our clients. Once we have a current count of the separate RDA authority master file (authmaster), we plan to share those numbers on this listserv. As an example, one of our clients received 7,000+ Name Authority Records in October as part of their Notification service. Of those 7,000+ NARs, 5 were RDA (040 $e rda) authority records; the Subject Authority Records numbered 2 RDA out of 3,500+ total SARs. Another client (also in October) received 4 RDA out of nearly 2,700 NARs, and 1 RDA out of 2,300+ SARs. All of these RDA authority records were returned as part of the Name or Subject authority files. Going forward we can deliver RDA & AACR2 authorities separately. Or we can continue to deliver them as part of your standard AACR2 authority files. The default would be to continue to include them with your AACR2 authority files, unless you tell us otherwise. Of course, now that we have separated the RDA authorities from the AACR2 authorities and moved the RDA authorities to their own authority master file, our clients will not be matching against that RDA database unless you instruct us to do so. Our intent is to give you even more control over how & when to integrate RDA authorities into your workflow. Nate Cothran Backstage Library Works From: bslwac-bounces@mailman.xmission.com [mailto:bslwac-bounces@mailman.xmission.com] On Behalf Of Zhu, Lihong Sent: Monday, November 01, 2010 5:52 PM To: Backstage Library Works Authority Contol Listserv Subject: Re: [BSLWAC] Backstage Plans for RDA Bibliographic Record Handling For option 3, how would you distribute authority files to us? AACR2 and RDA authority records in the same file? In separate files? Currently, we are getting NAME-1st and SUBJECT-1st and NAME-2nd and SUBJECT-2nd to facilitate the name heading (with dates) flipping through III automatic authority updating. Will this work with RDA authority records? Thanks. Lihong Zhu Head, Technical Services Washington State University Libraries P.O. Box 645610, Pullman, WA 99164-5610 E-mail: lzhu2@wsu.edu Phone: (509) 335-7769 Fax: (509) 335-9589 From: bslwac-bounces@mailman.xmission.com [mailto:bslwac-bounces@mailman.xmission.com] On Behalf Of Nate Cothran Sent: Monday, November 01, 2010 2:06 PM To: 'Backstage Library Works Authority Contol Listserv' Subject: Re: [BSLWAC] Backstage Plans for RDA Bibliographic Record Handling An excellent question as to what is considered the default for RDA bib processing. Here are the list of options (with #1 being the default unless our clients tell us otherwise): 1. Match RDA bibs as if they are AACR2 bibs, so RDA headings are matched against AACR2 authmaster (default) 2. Ignore RDA bibs when our system encounters them as part of mixed file of AACR2 bibs & RDA bibs 3. Match AACR2 headings against AACR2 authmaster, RDA headings against RDA authmaster 4. If no match in #3 above, match AACR2 headings against RDA authmaster, RDA headings against AACR2 authmaster We have already had a couple requests for option #2 (ignore RDA bibs), though there has been interest for all options. For #2, we will need to manually separate out the files prior to processing, otherwise option #1 (match RDA as AACR2) will take precedence; however, by late next week our system should be able to ignore these bibs as it runs across them (obviating the need to manually separate the records). Up to this point, we were undecided as to how to process the RDA bibs and AACR2 bibs. So some of our clients may have received RDA authorities since our system would attempt to find a suitable match either on an RDA authority or AACR2 authority. On November 2 (tomorrow), the two authority databases will be maintained separately within our system. This ensures that your headings are searched only against the authorities you specify, even during the testing phase. Of course if an RDA authority is available and your processing is setup to match against the RDA authmaster, and there is a match, that matching RDA authority will be returned to your institution. Starting tomorrow, the only time you should receive new RDA authority records is if you instruct us to match against the RDA authmaster. We hope to have more concrete numbers as to the number of RDA authorities later this week to give you an idea of how many have been distributed by Library of Congress to Backstage. Nate Cothran Backstage Library Works From: bslwac-bounces@mailman.xmission.com [mailto:bslwac-bounces@mailman.xmission.com] On Behalf Of Carras, Darla Black Sent: Monday, November 01, 2010 11:58 AM To: 'Backstage Library Works Authority Contol Listserv' Subject: Re: [BSLWAC] Backstage Plans for RDA Bibliographic Record Handling What is the default option? What will happen to RDA records in our current cataloging files if we have not given you instructions? Darla Carras Head, Catalog Management Unit University Library System University of Pittsburgh 412-244-7541 dcarras@pitt.edu From: bslwac-bounces@mailman.xmission.com [mailto:bslwac-bounces@mailman.xmission.com] On Behalf Of Chad Cluff Sent: Monday, November 01, 2010 1:46 PM To: bslwac@mailman.xmission.com Subject: [BSLWAC] Backstage Plans for RDA Bibliographic Record Handling 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

We send our current cataloging files to Backstage on the first of every month. Our October file has already been processed and returned to us, and I know there were rda records in that file. This set of options was announced in the blog on October 29, and not distributed to this list until October 31. This did not give us time to consider them prior to this file being processed. I am still not certain which option I prefer, but knowing that our October records were processed according to option 1 makes it likely that I will stay with that one for consistency's sake for the duration of the test period. I would be very interested in hearing from other libraries as to which option they have chosen and their reasons for doing so. What are the implications for the test period and thereafter? What if rda is adopted? What if it isn't? What in-house review procedures are you performing, if any? Darla Carras Head, Catalog Management Unit University Library System University of Pittsburgh 412-244-7541 dcarras@pitt.edu From: bslwac-bounces@mailman.xmission.com [mailto:bslwac-bounces@mailman.xmission.com] On Behalf Of Nate Cothran Sent: Monday, November 01, 2010 5:06 PM To: 'Backstage Library Works Authority Contol Listserv' Subject: Re: [BSLWAC] Backstage Plans for RDA Bibliographic Record Handling An excellent question as to what is considered the default for RDA bib processing. Here are the list of options (with #1 being the default unless our clients tell us otherwise): 1. Match RDA bibs as if they are AACR2 bibs, so RDA headings are matched against AACR2 authmaster (default) 2. Ignore RDA bibs when our system encounters them as part of mixed file of AACR2 bibs & RDA bibs 3. Match AACR2 headings against AACR2 authmaster, RDA headings against RDA authmaster 4. If no match in #3 above, match AACR2 headings against RDA authmaster, RDA headings against AACR2 authmaster We have already had a couple requests for option #2 (ignore RDA bibs), though there has been interest for all options. For #2, we will need to manually separate out the files prior to processing, otherwise option #1 (match RDA as AACR2) will take precedence; however, by late next week our system should be able to ignore these bibs as it runs across them (obviating the need to manually separate the records). Up to this point, we were undecided as to how to process the RDA bibs and AACR2 bibs. So some of our clients may have received RDA authorities since our system would attempt to find a suitable match either on an RDA authority or AACR2 authority. On November 2 (tomorrow), the two authority databases will be maintained separately within our system. This ensures that your headings are searched only against the authorities you specify, even during the testing phase. Of course if an RDA authority is available and your processing is setup to match against the RDA authmaster, and there is a match, that matching RDA authority will be returned to your institution. Starting tomorrow, the only time you should receive new RDA authority records is if you instruct us to match against the RDA authmaster. We hope to have more concrete numbers as to the number of RDA authorities later this week to give you an idea of how many have been distributed by Library of Congress to Backstage. Nate Cothran Backstage Library Works