Program for the manipulation of MARC bibliographic and authority records for use under RDA (2)

This program is devised to make changes to heading strings or controlled access fields in both authority and bibliographic records.. One of this program's output files contains changed r

Program for the manipulation of MARC bibliographic and authority records for use under RDA

Gary L Strawn

November 30, 2012

Introduction

Adoption of Resource description & access (RDA) involves the acceptance of a number of differences with previous

practice in the recording of information and the construction of heading strings.1 Fortunately, many of these

differences involve the kinds of mechanical manipulations that can safely be assigned to a computer program The use of such a program can allow data (specifically, heading strings) created under RDA to co-exist with data prepared under other standards, with the least amount of unhappiness This document describes one such program that can be used to manipulate elements in non-RDA heading strings into an RDA-like form This program runs under the Microsoft™ Windows™ operating system; it should work properly under any Windows version from XP™ forward This program is devised to make changes to heading strings (or controlled access fields) in both authority and bibliographic records

The changes made by this program are precisely those that are described in documentation prepared by the PCC Acceptable Headings Implementation Task Group.2 Although this program makes all of these changes to heading strings, the changes made by this program are not the only RDA-related changes that might be envisioned and perhaps encoded as a program For example, it might be possible for a program to use various MARC elements in bibliographic records to generate 336, 337 and 338fields, eliminating bibliographic 245 subfield $h in the process (Automated generation of these bibliographic 33X fields would involve updating nearly every bibliographic record

in a typical database.) It is not impossible that some other program will perform such changes; but the program

described in this document works only with heading strings and information spun off of them.

This program is designed to be used at any institution that handles bibliographic and/or authority information in the MARC21 format An institution can prepare files of records in the MARC21 format, and set this program to work onthose files, one at a time One of this program's output files contains changed records in the MARC21 format; this output file can be handled in whatever manner seems appropriate under local conditions This means that an institution could export bibliographic records from the local library management system to series of files, use this program to process those files of records, and then load the changed records back into the local system

With one important exception, the program described in this document deals only with files of records in the

MARC21 format The program does not itself extract records from a local system, nor does it write changed

records back to a local system Interaction with the local library system is left to other programs and utilities; the coordination of the various steps involved in updating a database of bibliographic and authority records for use

under RDA, is left to well-informed and -trained operators The exception to this general rule applies only to

institutions that use the Voyager library management system: the program is able to read a Voyager database directly

to find records of interest, and the program is able to write changed records directly back to a Voyager database

These Voyager-only features are described in Appendix B.

When evaluating the work performed by this program, it is important to understand how the program works: This program considers each MARC authority or bibliographic record in splendid isolation, on its own merits, using only the information contained in the one record This program does not test for conflicts involving other records in the

1 It is well known that there is a strong tide against the formulation of static heading strings, which will eventually carry us to the maintenance of identities instead However, the systems and records with which we must work in the time-frame for the transition to RDA are not yet constructed to take this important shift into account

2 In fact, this very program is the one used at the Library of Congress to make "phase 2" changes to authority records (An earlier version of this program was used to make the "phase 1" changes.) The documentation prepared

by the PCC Task Group describing these RDA-related mechanical changes is available here:

http://files.library.northwestern.edu/public/pccahitg/

local database, other records in the LC/NACO Authority File, or anywhere else It is entirely possible that the program will make RDA-related mechanical changes to a record without resolving a conflict between the changed field and a field in some other record Although this important restriction may be seen as less than optimal, it is fair

to say that if this program is applied to all of the authority and bibliographic records in a closed environment (such

as a local library system), the program will not make conditions any worse than they already are If this program is applied to all of the authority and bibliographic records in such a closed environment, there will (with one rare but important exception described below) be no new problems created; those bibliographic headings that previously matched authority fields will continue to match the same authority fields, and those bibliographic headings that previously matched no authority field will continue not to match any authority field

Here are some examples that may help make this important point clear

The following example shows a case where an existing (and correct) situation is still correct after the program has done its work.

When presented with the following fields in an authority record (not all fields in the LC/NACO record are shown):

100 0# $a Bernard, $c of Clairvaux, Saint, $d 1090 or 91-1153

400 0# $a Bernard, $c Saint, $d 1090 or 91-1153

400 0# $a Bernhard, $c av Clairvaux, Saint, $d 1090 or 91-1153

The program will change subfield $d in each field to its RDA equivalent:

100 0# $a Bernard, $c of Clairvaux, Saint, $d 1090 or 1091-1153

400 0# $a Bernard, $c Saint, $d 1090 or 1091-1153

400 0# $a Bernhard, $c av Clairvaux, Saint, $d 1090 or 1091-1153

Similarly, when presented with the following field in a bibliographic record:

100 0# $a Bernard, $c of Clairvaux, Saint, $d 1090 or 91-1153

The program will change subfield $d to its RDA equivalent:

100 0# $a Bernard, $c of Clairvaux, Saint, $d 1090 or 1091-1153

The bibliographic 100 field matched the 100 field of the LC/NACO authority record before the program did any work; the bibliographic 100 field still matches the authority 100 after the program has done its work on both the authority and bibliographic records.

The following examples show cases where an existing problem is not made any worse by the program's actions When presented with this field in a bibliographic record:

in other records Detection and resolution of this problem lies outside the competency of this program.

When presented with the following field in a bibliographic record:

600 10 $a Caxton, William $d ca 1422-1492

The program will change subfield $d to its RDA equivalent:

600 10 $a Caxton, William $d approximately 1422-1492

The original field does not reflect the form of name specified by the pre-conversion LC/NACO Authority File, and the changed field does not reflect the form of name specified by the post-conversion LC/NACO Authority File The bibliographic field has been modified into an RDA-like form on its own merits, without any effect on the state of things in a broader sense: the bibliographic field was not in an authorized form before the

conversion, and it remains in an unauthorized (though different) form after the conversion Note also the comma missing from the end of subfield $a, which the program does not supply, because it did not change subfield $a.

When presented with the following field in a bibliographic record:

110 10 $a Manitoba $b Dept of mines and natural resources

The program will expand the abbreviation in subfield $b:

110 10 $a Manitoba $b Department of mines and natural resources

The program successfully expands the abbreviation in subfield $b, but does not consider the use of uppercase letters in other parts of the subfield The normalized form of the bibliographic 110 field matched the 110 field in the LC/NACO authority file before the conversion, and it continues to match the authority 110 field after the conversion of the authority and bibliographic records, even though the two differ in detail.

When presented with the following field in a bibliographic record:

700 12 $a Equiano, Olaudah, $d b 1745 $t Interesting narrative of the life of Olaudah Equiano, or Gustavus Vassa, the African Selections 1971

The program will change subfield $d to its RDA equivalent:

700 12 $a Equiano, Olaudah, $d 1745- $t Interesting narrative of the life of Olaudah Equiano, or Gustavus Vassa, the African Selections 1971

The program successfully manipulates the data in subfield $d, but does remove the unnecessary alternate title

in subfield $t, and does not add the missing subfield codes $k and $f.

When presented with the following field in a bibliographic record:

240 10 $a Concertos, $m violoncello & string orchestra $k Selections $h Sound recording

The program will change "violoncello" in subfield $m to its RDA equivalent:

240 10 $a Concertos, $m cello & string orchestra $k Selections $h Sound recording

The program successfully substitutes the approved name for the solo instrument under RDA, but does not consider whether "cello & string orchestra" is a correct formulation for subfield $m; and the program does nothing with subfield $h.

There is one operation performed by this program—in full accordance with the scheme adopted by the Program for

Cooperative Cataloging—that can result in the creation of a new conflict or problem Under standards in effect before the adoption of RDA, the label "b." was used before a date in subfield $d if a person's birth date was known and the person was known or believed to be dead but the death date was not known Similarly, the label "d." was used before a date in subfield $d if a person's death date was known, but not the birth date Under RDA as adopted

by the PCC, hyphens are used instead of these abbreviations or the equivalent words

In an extremely small number of cases (a few dozen, out of about 8.5 million LC/NACO authority records), it happens that different people with the same name share a single year: for example, one dies in a given year, and another is born in the same year This means that after the application of RDA two headings that were distinct under

earlier cataloging rules suddenly have the same PCC comparison form; the duplicate headings will be created by the

RDA conversion process itself The detection and resolution of this problem are matters outside the scope of this program.3

$a Leggat, Claribel A $q (Claribel Ament), $d d 1881

$a Leggat, Claribel A $q (Claribel Ament), $d b 1881 $a Leggat, Claribel A $q (Claribel Ament), $d -1881$a Leggat, Claribal A $q (Claribel Ament), $d

1881-$a Netting, Conrad John, $d d 1944

$a Netting, Conrad John, $d

1944-$a Netting, Conrad John, $d -1944

$a Netting, Conrad John, $d

1944-3 This problem is created by the mismatch between the definition of the NACO comparison form and choices made for the content of RDA personal name headings; strictly speaking, this problem does not stem from a bug in the software It has been proposed that the rules for construction of the NACO comparison form be adjusted, to allow for the retention of the hyphen, thereby preventing this condition from occurring At the time of writing, this notion

is no more than a proposal Even if this proposal were presented formally and approved, it would be some time before the software in library systems is adjusted to match the changed definition

Restrictions on use

The program described in this document is available for non-commercial use only Any institution may use the program to manipulate records, and may freely distribute the program to others, as long as all of the following conditions are satisfied:

1 No charge is made for the program

2 No charge is made for the program's documentation

3 No charge is made for the work done by the program

Use of the program and its components under other conditions (such as, but not limited to, use of this program as part of a fee-based service) is subject to prior agreement with Northwestern University's Technology Transfer Program (1801 Maple Avenue, Evanston, IL 60208; 847/491-3005)

In all cases, use of the program is entirely at the risk of the user Use of the program constitutes agreement with this condition Those not willing to take this risk upon themselves must not use this program

Installation

Installation packages for this program are contained in a series of ZIP files available at the Northwestern University Library download site (http://files.library.northwestern.edu/public/RdaConversion/) The name of the ZIP file will consist of "RdaConversion" followed by additional numbers, and ending with the extension "ZIP" (For example, available file names might be "RdaConversion.2007.22.416.ZIP" and "RdaConversion.2008.11.523.ZIP".) Only users of the Voyager library system who are interested in using the program's Voyager-specific features need to worry about the numbers in the middle of the ZIP file names;4 others should simply take the installation package

with the most recent date (The numbers in the middle are not the date the installation was produced; see the separate

column in the display on the download page for the date of the package.)

While you are at this download site, also download the ZIP file whose name begins "RdaConfiguration"; you will need this when you set the program's configuration (see below)

The ZIP file for each installation package contains the following three files:

• setup.exe

• setup.lst

• RdaConversion.CAB

To install the program, unzip the file to some folder and then run setup.exe.5 During the installation, if you are told

that a given module (DLL, OCX, or other) in the installation package has an earlier date than a module currently

installed on the workstation, always select the choice in the dialog box that means "retain the module with the later date already installed on this workstation"

After you install the RDA conversion program, it will be available from the Windows Start menu in the listing of all programs; look in the "Northwestern University Library" folder You can copy the shortcut for this program to your desktop, or to any other location that seems convenient to you

4 The numbers in the middle of the ZIP file names identify various versions of the Voyager library system, and are NOT an indication of the version of the conversion program itself If you are a user of the Voyager library system and wish to use the program to update your Voyager database directly, you must choose the version of the program that corresponds to your version of Voyager, as described in Appendix B

5 Some versions of Windows allow setup.exe to be run successfully from the ZIP file, without explicitly unzipping the file; some versions of Windows allow setup.exe to start from the ZIP file, but then deliver an inscrutable error message

Before you begin to consider the program's configuration—before you even start the program the first download the ZIP file whose name begins "RdaConfiguration" from the same folder at the download site that contained the installation package Create a folder to contain your RDA configuration (the name of this

time configuration folder can be anything you can remember), and un- ZIP this file into that folder You'll need to supply the name of this folder as part of your conversion choices

You must configure the program before you can use it for either testing or production (As described in Appendix B, Voyager users who wish to use the program's Voyager-specific features must supply information beyond that

described here.) Configuring the program consists in the definition of one or more profiles Each profile represents a

different conversion scenario You might, for example, wish to create different scenarios for the handling of files of bibliographic and authority records The amount of complexity reflected in the scenarios is entirely of your devising:you must define at least one profile, but you can define as many additional profiles as you feel you need

When you start the program the first time, it looks like this:

The big empty window is where you will see a list of your profiles, once you've defined them

To create a profile, click the "New" button The program asks you for a name for the profile The name you give the profile can be anything that means something to you; the program just uses this name for display, and imposes no restrictions on the content of the name After you supply a name, the program adds it to the list In the following illustration, the name of the new profile is "Standard RDA conversion profile":

You can change the name of the profile at any time (by clicking the "Rename" button), and you can delete the profile

at any time (by clicking the "Delete" button)

If you define several profiles, select the profile of interest for a given operation from this opening screen; the choices

on the following screens of the profile definition reflect the values you have set for the selected profile The

program's caption (the bar at the top of the program's window) shows the name of the currently-selected profile.Once you have created a profile, you need to page through several screens, to set all of the options that together constitute the full profile Navigate from one page of options to the next by clicking "Next", "Previous", "First" and

"Last" buttons The following sections describe each of the screens that together constitute an RDA conversion profile

Every time you create a new profile when an existing profile's name is highlighted, the program sets all of the values

in the new profile to match the highlighted profile; the new profile is a "clone" of the existing profile, differing only

in the name Having created the clone, you need only change those values that differentiate this profile from the original one

Identify the source of records to convert

Use this frame to tell the program where to find the records with which it is to work Unless you are using the Voyager library system and have previously made appropriate configuration choices, the only choice available to you will be the choice "File of MARC records." Use the "Browse" button to find the file of records with which you wish the program to work

General conversion options

These very important options define some of the RDA-related changes made to records

You should set the values of the check-boxes to match the decisions made during the work of the PCC Acceptable Headings Implementation Task Group, and then left leave these options alone (The default values are those used to manipulate the LC/NACO Authority File Because most of these items are no longer 'options' in any meaningful sense, a future version of the program may remove them from the configuration altogether.)

• Conference names: possibility of 'ongoing' nature must be considered: This box should always be checked.

• Personal names: 'b.' at start of $d becomes 'born': This box should always be not checked.

• Personal names: 'd.' at start of $d becomes 'died': This box should always be not checked.

• Subfield $m: use 'cello' not 'violoncello': This box should always be checked.

• Bible: omit 'Apocrypha': This box should always be not checked.

• Bible: 'Selections' is authorized: As originally written, RDA does not provide for the use of the form

subdivision 'Selections' for parts of the Bible and other sacred scriptures At the time this document is beingwritten, there was a proposal before JSC to again allow 'Selections' in headings for sacred scriptures While

'Selections' is not authorized, this box should be not checked; if 'Selections' is at some future time

authorized, this box should be checked.

• OK to change dates in X50 subfield $a: This box should always be checked.

• OK to change dates in X5X subfield $y: This box should always be checked.

• OK to change' violoncello' in X50 subfield $a: This box should always be checked.

The options for folder names can be whatever values work in your environment

• Folder for reports: The name of a folder into which the program can write its reports and output files You will want to define a special folder to contain just this program's report files There are going to be a lot of

report files, and you're going to want to keep them separate from other files The folder name you give hereshould end with a reverse slash The folder you name must exist before you start the program; the program will not create this folder for you The default value of "c:\" for this folder will not be acceptable under

current versions of Windows, because programs are no longer allowed to write to the root directory of the main hard drive.

• Change no more than … records: This sets the maximum number of records of any type that the program

will modify during any one run This number is the combined number of authority and bibliographic records that the program will change The program's current limit is 10,000,000 changed records

• Folder for configuration files: the name of the folder that contains the program's configuration files These

are the files contained in the configuration ZIP file you downloaded when you downloaded the program's installation package (See elsewhere for a description of the ZIP file that contains the default configuration information, and what you should do with it.) This folder name should end with a reverse slash The defaultvalue of "c:\" won't cause the program to blow up, but it is an unacceptable value for ongoing work.The program creates files that show the 'before' and 'after' versions of each record it changes These files are extremely important during your testing of the program, as they allow you to identify every change made by the

program Because there are probably going to be a lot of records changed, a single file containing all of the records

is probably not a good idea With the number you supply in the Records per 'before and after' file area, you can tell

the program how many records (by hundreds) to include in each file You will find that a value of 1,000 or 2,000 probably strikes the best balance between the number of files generated, and the number of records in each file

Options for authority records

These options further control the program's behavior when it's considering an authority record

The "Inclusion" frame tells the program whether to consider locally-created authority records, or LC-type records, orboth You can check either box, or you can check both boxes, but you must check at least one of the boxes To this program, an "LC-type" record is an authority record containing 010 subfield $a; "local" record is an authority record

that not only does not contain 010 subfield $a, but also does not contain any markings that indicate that it plays a part in a non-LCSH subject heading scheme (For example, a MeSH authority record is neither an "LC-type" record nor a "local" record; the program will refuse to do anything with a MeSH authority record.) If you check the "LC-type" box, you can supply in the following text box a list of the 010 $a prefixes you wish to consider If you supply multiple codes, separate them with spaces If this box is empty, the program will include all LC-type authority records in its work.

For example, if you check the "LC-type" box and then supply "n sh" in the text box, the program will consider all records in the LC/NACO Authority File (records with 010 prefixes beginning with the letter "n", such as "n",

"no", "nr", "nb" and "ns"); the program will accept LCSH records (with prefix "sh") but will not consider LC form/genre records (with prefix "sg")

The "Conversion mode" drop-down box tells the program what kind of changes to make to authority records The choices available here correspond exactly to the two-phased implementation scheme devised by the PCC task group.(Note that this choice appears on a frame that relates specifically to authority records; the notion of "phases" does not apply to bibliographic records.)

• Phase 1: The program finds authority records that a) contain characteristics that prevent the use of the 1XX field under RDA without review and b) do not call for any mechanical changes; the program adds a 667 field to such records

• Phase 2: The program makes mechanical changes to records; the program adds a 667 field if the 1XX field bears characteristics that prevent its use under RDA without review

• Work ONLY with RDA 7XX fields: The program deals with RDA 7XX fields in authority records; the

program performs neither Phase 1 nor Phase 2 operations It is likely that you will not need to process

authority records with this option, as RDA 7XX fields probably only occur in records originating the LC/NACO Authority File If you do find that you need to perform this step, perform it between Phase 1 andPhase 2

The "Handling of 4XX created from 1XX" drop-down box allows you to control the suppression/display of 4XX fields that the program creates when it makes a mechanical change to the authority record's 1XX field

• Display all such 4XX: The program-supplied subfield $w does not contain byte 3; the 4XX field is not marked for suppression

• Suppress all such 4XX: The program uses code "a" for 4XX subfield $w/3 This is the value used during work performed under direction of the PCC task group.

• Display only if change is in last subfield: The program-supplied subfield $w does not contain byte 03 if the only change to the former 1XX field is in the last subfield; $w/3 contains code "a in all other cases

The "Attempt to convert 678 fields into 046 and 670 fields" check-box directs the program to inspect 678 fields and

in certain cases re-code the 678 as 670 and also create an 046 field This area of the program is currently still under design; you will probably be better off if you leave this box unchecked until directed otherwise

The choices in the "Authority MARC output file" control the records that the program writes to its output file

• Output file contains only changed records: The output file only contains records that the program changed

• Output file contains all records from input file: The output file contains all records present in the input file, whether changed or not

Options for bibliographic records

These options further control the program's behavior when it's considering a bibliographic record

The choices in the "Bibliographic MARC output file" control the records that the program writes to its output file.

• Output file contains only changed records: The output file only contains records that the program changed

• Output file contains all records from input file: The output file contains all records present in the input file, whether changed or not

The program prepares a "before and after" report, showing each changed record in its original state, and as modified

by the program As described elsewhere, this file can be an important adjunct to the testing of the RDA conversion program A bibliographic record can contain many fields that are not subject to the RDA-focused operations of this program; these fields can make it more cumbersome during testing to find and evaluate the changes made by the program Choices available in the "Fields not wanted in bibliographic 'before and after' report" frame allow you to

tell the program to exclude certain groups of variable fields from the report Note that choices made here only affect the contents of this report; the program does not omit these fields from the changed bibliographic records

themselves

Choices in the "Reports of non-RDA elements in bibliographic records" area allow you to receive reports concerningelements in headings (whether changed by the program, or not) that are not suitable for use under RDA without review You may not care about any of these, you may only care about some of these, or you may care passionately

about all of these There are no changes to bibliographic records directly associated with any of these reports.

• Musical ensembles in subfield $m: The program reports subfield $m if it contains "brasses," "plucked

instruments," "keyboard instruments" or "instrumental ensemble;" and it reports subfield $m if it contains

"strings," "winds" or "woodwinds" unless subfield $t also contains "trio," "quartet" or "quintet"

• 'Polyglot' and '&' in subfield $l: The program reports subfield $l if it contains "Polyglot", an ampersand, or

the word 'and'

• Treaties: The program reports bibliographic X10 fields with $t that contains "treaties", 240 fields with $a

that contains "treaties", and X30 fields that contain subfield $d

• Librettos and texts: The program reports subfield $s that contains "libretto" or "text"