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-bibliographic-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 (wiki)

·         Leader and Fixed Field Updates (wiki)

·         Tag Updates and Field Deletes (wiki)

·         Indicator Updates (wiki)

·         Initial Article Validation (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 (wiki)

·         Special MARC21 Field Conversions and Additions (wiki)

·         GMD Standardization (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 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 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 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 nate@bslw.com

Jeremy Myntti jmyntti@bslw.com

Judy Archer jarcher@bslw.com

Karen Anderson 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