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