Authority toolkit: create and modify authority records

4.7.1.1. Introduction

You cannot simply click the cursor into the authority record that the toolkit displays on the left side of its main panel, and start typing. This display version of the record is locked against such direct manipulation. Instead, you need to use the toolkit's various tools to change the record. Although you can always double-click on a variable field to bring it into the toolkit's editing window and then make whatever change you want, that's not always the most efficient way to make a change, and it's not necessarily the most error-free method, either. The items on the toolkit's Edit menu provide one way to make certain pre-defined changes to a record reliably, and with very little effort.

4.7.1.2. Add death date to 100

The toolkit makes the Add death date sub-element available on its Edit menu if your authority record presents all of the following characteristics:

• The authority record has a 100 field
• The last subfield in the 100 field is subfield $d
• The last character in 100 $d is a hyphen
• The authority record contains 046 $g
• 046 $g contains at least a four-digit year (no century; no "u" or "X")

If the Add death date sub-element on the Edit menu is available and you select it, the toolkit makes the following changes to the authority record:

• The toolkit adds the year portion of 046 $g to the 100 field. (If subfield $g of the 046 field represents a choice of dates (as in "$g [2050,2051]"), the toolkit will use the two years, separated by "or" in 100 $d.)
• The toolkit creates a new 400 field with $w nnea for the original 100 field
• The toolkit adds the death date to 400 fields (other than a 400 field for a former heading) that have subfield $d ending with a hyphen.

  For example, given this authority record:

  

  ... when you select the Add death date menu item, the toolkit changes the record like this:

  

The Add death date to 100 $d check-box on the 046 tab provides another way to make similar changes to an authority record.

4.7.1.3. Change fields in several records ("batch" correction)

Introduction

It will happen from time to time that information in one authority record needs to be reflected in other authority records. Here are a few examples:

• An authority record shows a change to a personal name heading. The earlier form of this person's name also appears in one or more name/title authority records
• An authority record shows a change to a corporate name heading. The earlier form of the organization's name also appears in one or more additional authority records
• An authority record shows a change to geographic heading. The earlier name is also used as the entry element in one or more corporate name authority records

In such cases, information describing a change to the preferred name for an entity needs to be reflected in other authority records that involve that entity. The toolkit does not have any way to find the associated authority records and change them all for you, but it does provide substantial automated assistance in this work. You need to bring each affected record into the toolkit, and the toolkit does much of the rest.

All of the work described in this section takes place from the Batch item on the toolkit's Edit menu. This isn't really a "batch" correction, in the sense that a whole bunch of things get changed all at once, but the term "batch" seems like the best shorthand way to describe what's going on.

This work is controlled by several options.

The examples in this section were constructed to illustrate the toolkit's capabilities. These examples illustrate the toolkit's working method and results, but do not necessarily represent actual situations.

Define the change

To begin the process of making a change to a group of authority records, bring into the toolkit an authority record that represents the change to be made. This authority record must include at least one 4XX field. (The 4XX field in the record need not necessarily reflect exactly the change you wish to make; the reason for this will become clear in a moment.) You simply tell the toolkit that this authority record defines a batch change, by selecting Edit, and then Batch and then Pick up from the toolkit's menu. The toolkit picks up the 1XX field and all of the 4XX fields, and stores them for future use.

The toolkit stores the correction definition in the Windows registry, replacing any previous definition. This definition remains in place, and is avilable every time you start the toolkit, until you either replace it with a different definition, or clear it from memory.

If you have selected the appropriate option, after picking up a new correction definition the toolkit immediately displays that definition, so that you can make adjustments to it.

Display (and change) the definition

The current correction definition is available at any time for inspection and modification. To see the current definition (and possibly make changes to it), select Edit and then Batch and then Display/Adjust from the toolkit's menu. The toolkit displays the 4XX fields that form the critical part of the correction definition. To change or delete a field, highlight the field and then click the corresponding button. To add a field, click the Add button. The change and add functions use the toolkit's standard field-editing panel. You can delete multiple fields at one time; but you can only edit one field at a time.

The changed definition must have at least one 4XX field in it. If you click the OK button, the toolkit replaces the 4XX fields in the existing definition with those listed in the display. If you click the Cancel button, the tookit retains the existing definition without any change.

The toolkit stores the changed definition in the Windows registry, replacing any previous definition. This definition remains in place, and is avilable every time you start the toolkit, until you either replace it with a different definition, or clear it from memory.

None of the changes that you make to the definition are reflected in the authority record from which the definition was derived. (For example: If you remove a 4XX from the definition, the toolkit does not remove the original 4XX field from the authority record.)

Make a change to an authority record

To make a change to an authority record, bring into the toolkit an authority record that contains an access point that involves one of the 4XX fields that form part of the current definition. Select Edit and then Batch and then Perform from the toolkit's menu. The toolkit applies the current definition to the 1XX, 4XX and 5XX fields in the record, and immediately shows you the changed record.

Click OK in the toolkit's menu to send the record back to Connexion, and contribute the change to the LC/NACO Authority File. Proceed in a similar manner to change additional records involving the same name: bring each record into the toolkit, and apply the correction definition to it, and save the record to the LC/NACO file. You only need to define the correction once, and then you can apply it to as many records as need that change.

Clear the definition

If you want to obliterate the current correction definition, select Edit and then Batch and then Clear from the toolkit's menu. There's no particular need to do this—the toolkit only applies a correction definition when you tell it to do so—but there's also no harm in clearing the definition once you've finished with it.

4.7.1.4. Create a new field

Use the Edit/Add new menu choice to add a new variable field (tag 010-999) to the authority record. The toolkit presents you with a blank field editing panel. You supply tag, indicators, and text in the field editing panel, and the toolkit adds the new field to your record.

4.7.1.5. Change an existing field

To change a variable field⁴⁴, click on the field, then select the Edit/Change menu item. The toolkit places the field into its field editing panel. (You can achieve the same result by double-clicking on the field of interest.) In the field editing window, you can change the field's tag, indicators, and text.

4.7.1.6. Combine fields

Use this menu choice to combine two or more fields into a single field containing all of the subfields from all of the fields. Click anywhere on the first instance of the field you wish to combine with others, then select this menu item; the toolkit finds remaining fields of the same type "lower" in the authority record, and combines them into a single occurrence.

The toolkit only makes this menu item available when you click on a field that the toolkit allows you to combine with others: the 034, 368, 370, 372, 373, 374, 376, 380, 381, 383, 385 and 386 fields. The toolkit will only combine fields with the same tag, indicators and subfield $2 information (or if neither field has subfield $2). The toolkit will not allow you to combine some fields if you have chosen any option to add URIs to fields.

The toolkit contains a special trick for combining 046 fields. If any of the subfields in a combined 046 field is fully redundant with another subfield, the toolkit will silently remove the redundant subfield.

This menu choice is only available if you have indicated that separate fields may be combined. One option controls the combining of separate 046 fields, another controls the combining of all other fields. The toolkit will not combine fields in which subfield $0 is defined, if you have selected any of the options to generate URIs.

4.7.1.7. Create a 4XX field, using a second authority record

Use the Create 4XX menu item to combine information from two authority records to make a new 4XX field.⁴⁵ This menu choice produces a hierarchial corporate 4XX field, a hierarchical title 4XX field, or a name/title 4XX field.

The toolkit will only make this menu item available if there is an authority record on the Texts tab labeled Additional, and if this record, and the authority record displayed on the left side of the toolkit's main panel, share certain characteristics.

You must take some deliberate action to bring an additional authority record into the toolkit.

• Using any version of the toolkit, you can bring in an additional authority record by using the toolkit's ability to retrieve authority records from the id.loc.gov site.
• If you are using the OCLC Connexion version of the toolkit, you can employ the toolkit's suspend feature to stop work on an authority record for a moment, and bring a second authority record into the toolkit.
• If you are using the independent version of the toolkit, you can use the File/Open menu choice.
• If you are using the LC-only version of the toolkit, you can use either File/Open or Voyager/Open menu items.

Both the record on the left and the record on the right must have these characteristics:

• Both authority records must have a 1XX field
• Neither 1XX field may contain subfield $v, $x, $y or $z

The 1XX fields of the two records must match one of these pre-defined scenarios for combining two authority records to make a new 4XX field:

• The authority record on the left is a series authority record (008/12 contains "a", "b", "c" or "z") and the authority record on the right has a 110 field
• Both records have a 130 field
• One record contains a 130 field and the other contains a name/title 1XX field
• The record on the left has a 110 field, and the record on the right has a 151 field

If the two authority records pass all tests, the toolkit makes the Create 4XX menu choice available. When you select this menu item, the toolkit does some manipulation of the 1XX field from the authority record on the left before combining fields.

• If the 1XX field from the authority record on the left consists of a name plus a title, the toolkit retains only the title portion
• If the 1XX field from the authority record on the left is not a name/title field and if that fields' tag is 130: if the record on the right has a 130 field as well, the toolkit changes the $a code in the 130 from the record on the left to $p; if the record on the right does not have a 130, the toolkit changes the $a code in the 130 from the record on the left to $t
• If the record on the left has a 130 field, the toolkit removes any terminal parenthetical qualifier
• If the record on the left has a 110 or 111 field that is not a name/title heading, the toolkit retains only the rightmost subfield

The toolkit creates a new 4XX field that begins with the 1XX field from the authority record on the right, plus the (modified) 1XX field from the authority record on the left. The toolkit attempts to add appropriate punctuation between the two pieces that it assembles into the new 4XX field.

Let Gary know if you encounter additional cases in which the toolkit could combine 1XX fields from two authority records to produce a new 4XX field.

4.7.1.8. Create a 670 field

The Create 670 menu choice creates a new 670 field, based on information in a bibliographic record. This menu choice is only available if you have brought an additional bibliographic record into the toolkit.

You must take some deliberate action to bring an additional bibliographic record into the toolkit.

• Using any version of the toolkit, you can bring in an additional bibliographic record by using the toolkit's Z39.50 capability to search and retrieve bibliographic records from any suitable site.
• If you are using the OCLC Connexion version of the toolkit, you can employ the toolkit's suspend feature to stop work on an authority record for a moment, and bring a bibliographic record into the toolkit.
• If you are using the independent version of the toolkit, you can use the File/Open menu choice.
• If you are using the LC-only version of the toolkit, you can use either File/Open or Voyager/Open menu items.

When you have a bibliographic record displayed as an Additional record on the Texts tab, the toolkit makes the Create 670 item on the Edit menu available. If you select this menu item, the toolkit pulls information from the bibliographic record, and shows you its proposed 670 field in its field change panel. If you click the OK button on this panel, the toolkit adds the 670 field to the authority record. See an example.

4.7.1.9. Create a 670 field for OCLC usage

The toolkit can help you begin work on a 670 field that summarizes the usages and headings found in the OCLC database. To do this, select the Create 670 OCLC item on the Edit menu. This menu choice is available for all kinds of records, at all times.

When you select this menu item, the toolkit creates a preliminary 670 field, using the 1XX field from the authority record as the access point, and information the record's first 670 field as the usage. The toolkit presents you this preliminary field in its field field editing panel, as shown in the following illustration. You can make additional changes to this field now, or at any other convenient time.

The usage and hdg. radio buttons on the Texts tab offer another way to construct a 670 field showing patterns found in the OCLC database.

4.7.1.10. Create a 678 field

Use the Edit/Create 678 menu item to ask the toolkit to generate a preliminary 678 field (biographical or historical data). The toolkit only makes this menu item available if you're working on an authority record for a personal, corporate or conference name. To construct the proposed 678 field, the toolkit pulls information from the 1XX, 046, 370, 372 and many other fields, and mixes the various bits of information with suitable text and punctuation to produce a narrative statement. The toolkit only uses discrete bits of information that have been teased out into separate data elements; the toolkit does not attempt to parse the 670 fields to find useful bits of information. (The toolkit can also help you create a 678 field in a different way, using information drawn from a Wikipedia page.)

The following table outlines the elements that the toolkit may consider for use in the 678 field that it generates.⁴⁶ For ease of reference, this table is in order by MARC tag; the toolkit plucks information from the authority record in whatever order seems appropriate in a particular context.

The toolkit's assembly of a 678 field using data pulled from the authority record is controlled by a large number of options. The toolkit contains substantial internal tables (not at present available as configuration files) that tell it how to manipulate commonly-occurring terms found in the 368, 372 and 374 fields for use in the 678 field.⁴⁹

The toolkit may ask one or more questions as it pulls information from the authority record for re-use in the 678 field.

• If the authority record contains a 100 field with subfield $c, the toolkit needs to know how to treat the text from subfield $c in the display form of the person's name. (The display form of the name is the name that the toolkit will use to begin the new 678 field; this should be the name in its "natural" order, and containing the elements that (to your best guess) users will find most helpful.)

  In the following illustration, the toolkit shows (on its multiple choice panel) the 100 field with the text from subfield $c presented at the beginning and end of the subfield $a text, and also presents the text of 100 subfield $a without subfield $c. You have selected the form that includes the subfield $c text following the subfield $a text (shown in bold). When you click the OK button, the toolkit will use the selected text at the beginning of the 678 field.

  

• If the authority record contains any 4XX fields, (not counting 4XX fields marked as 'former heading'), the toolkit will ask if it should include any of them in the 678 field.⁵⁰ The toolkit uses its multiple choice panel to do this. You can select as many of the 400 fields as you wish.

  In the following illustration, the toolkit has presented a list of the 400 fields in the record (un-inverted, with forenames before surname, as specified by an option). You have selected one 400 field (shown in bold), representing a person's full name in the Cyrillic alphabet.

  

  In the following illustration, the toolkit has presented a list of the 410 fields in the authority record. You have selected three of these fields (shown in bold): one non-Latin field, and two Latin-alphabet fields.

  

• If the authority record contains a 663 or 665 field, and if you have not selected the corresponding 663: Always include or 665: Always include option, the toolkit will ask if it should include the 663 or 665 field in the 678 field.

The toolkit eventually presents the proposed 678 field on its field change panel. You can modify the field as you see fit. Click the OK button to add the field to the authority record; click the Cancel button to abandon the 678 field.

It cannot be emphasized too strongly that you should regard the program-generated 678 field as a preliminary gesture, and not as the final form of the 678 field. You should also understand that the toolkit doesn't know what the various bits of text mean in any significant sense. If there's something nonsensical in the proposed 678 field, such as She is an English literature, you should cancel the operation, adjust the MARC content designation of the various bits of information, and then try the Edit/Create 678 menu item again. Similarly, if the proposed 678 field contains an expression such as Smith is an actor or actress, and if the person's gender is known, you should cancel the operation, add a 375 field to the authority record, and then try the 678 field again.

If you have any suggestions for improving or expanding the preliminary 678 field generated by the toolkit, please let Gary know. (Proposals for including additional information must involve data elements that are separately identified in the authority record, and not buried somewhere in a 670 field.) There is above all great scope for the definition of additional options to tailor the content and appearance of the proposed field.

4.7.1.11. Delete a field

Use this menu choice to remove a variable field from the authority record. Click on the field, then select this menu item (or press CTRL-D). The toolkit removes the field for you. The toolkit will not allow you to delete the 00X, 040 or 1XX fields.

4.7.1.12. Derive a new record

Whenever you are editing any authority record, you can use the Derive new record item on the toolkit's Edit menu to create a new record. Towards the end of its work, the toolkit will throw away the current authority record, so you should make sure that you've saved any changes to it that you wish to make, before you derive a new record. When you select the Derive new record menu item, the toolkit removes any 001 and 010 field, and replaces the 005 and 040 fields. Because the 1XX field of the new record must differ in some way from the 1XX field of the base record, the toolkit presents the existing 1XX field in its field change panel, inviting you to make some modification to the field. The toolkit eventually shows you the derived new record, ready for the many additional changes that will no doubt be required before the record can be contributed or otherwise saved.

If you want to create a new, blank record, use the New record item on the Edit menu.

If the record contains a 5XX field, you might want to 'flip' the record around, so that the 5XX becomes the 1XX in the new record and the 1XX becomes a 5XX. (This work is controlled by some options.) To do this, simply click first on the 5XX field and then select Derive new record from the Edit menu. The toolkit will prepare a preliminary new record for you, reversing what it is able to reverse. The toolkit's preliminary new record will almost certainly require a lot of additional changes before it can be contributed or saved.

4.7.1.13. Duplicate $t as 430

This choice on the Edit menu is only available if you first click on a 1XX or 4XX field that contains subfield $t.

Use this menu choice to create a 430 field that contains subfield $t, and all following subfields, from a name/title heading. Click first on a name/title 1XX or 4XX field, then select Duplicate $t as 430 from the Edit menu. The toolkit adds a 430 field to the record consisting of subfield $t of the selected field, plus any following subfields (not including subfield $w, or $0-$9).

4.7.1.14. Edit the fixed fields

The cataloger's toolkit attempts to keep the authority record's fixed fields (elements from the record leader and 008 field) synchronized with other parts of the authority record. On rare occasions, you may wish to make changes to a fixed-field element that are beyond the toolkit's capabilities.⁵² Select Edit/Fixed fields from the toolkit's menu to make any change to any of the fixed-field elements.

You can also begin editing the fixed fields by double-clicking anywhere within the fixed fields.

The behavior of the toolkit's fixed-field editing panel is controlled by a few options, but mostly by the configuration file FfdEdit.cfg.⁵³

When you select Edit/Fixed fields from the toolkit's menu, the toolkit displays the fixed-field elements on a special editing panel. The toolkit's arrangement of fixed-field elements is based on the presentation in the OCLC Connexion client, and the editing panel works in a fashion similar to the Connexion client. The following illustration shows a typical example of the toolkit's fixed-field editing panel.

The toolkit displays the value of "blank" as "#", and it displays the "fill character" as a vertical bar ("|").

To change an element, either select the new value from the list of defined values, or type the value. If you type an unacceptable value, the toolkit will instantly change the background color of the element to highlight the problem. The toolkit will not allow you to save the fixed-field values if any of the values is undefined.

For help with the values used in any element, click on the button with the element's name. The toolkit will open your favorite web browser to either the OCLC or Library of Congress documentation for that element, depending on the option you have chosen.

When you've finished changing the fixed-field elements (assuming they're all correct), click the OK button. The toolkit will not allow you to save fixed-field elements if any of them contains an unrecognized value. To abandon your work, click the Cancel button.

4.7.1.15. Extract a 675 field into a 670 field

Use this menu choice to convert information in a 675 field into a 670 field, with the subfield $b code inserted at the correct spot in the new field.⁵⁴ This menu choice was originally designed to work with 675 fields constructed according to the current model, with each source in a separate $a subfield, but was later expanded to handle 675 fields with all of the sources in a single $a subfield.

If there are multiple $a subfields in the 675 field

To extract a single 675 subfield $a into a 670 field, click anywhere within the text of the subfield, and the select Extract 675 as 670 from the toolkit's Edit menu. (This menu choice is only available when you click on a 675 field.) The toolkit extracts this subfield and examines it.

If the toolkit can find a reliable point in the subfield's text at which to insert the subfield $b code,⁵⁵ the toolkit will simply delete the 675 $a subfield (if that's the only $a subfield in the 675 field, the toolkit deletes the whole field), and then add a 670 field.

The toolkit will modify only one 675 $a subfield at a time; if you need to extract more than one 675 $a subfield to a 670 field, you will have to handle each one separately.

If the toolkit cannot figure out on its own where to insert the subfield $b code, the toolkit will show you the proposed new 670 field in its field change panel. You can modify the text of the field in any way that seems appropriate to you. If you click the OK button, the toolkit creates a new 670 field, and removes your subfield from the 675 field. The toolkit does not inspect the text of the field that you have approved, to make sure that it contains a subfield $b code. (In some cases, it may be appropriate not to have subfield $b at all in the new 670 field.)

If there is a single $a subfield in the 675 field

The toolkit also offers a way to extract one source from a 675 field, when the 675 field contains only a single instance of subfield $a, and that subfield contains multiple source citations separated from their neighbors by semicolons.⁵⁶ You must be careful when using this method, because it is very sensitive to the formatting of the text in the 675 field. If this method produces incorrect results (either because it split the subfield at the wrong place, or converted the entire subfield into a new 670 field), you should undo the change, and edit the field yourself.

To extract one semicolon-delimited source citation from a 675 field, click anywhere within the source citation, and then select Extract 675 as 670 from the toolkit's Edit menu. (This menu choice is only available after you click somewhere in a 675 field.) The toolkit attempts to identify the segment of the 675 field that corresponds to the point at which you clicked.

If the toolkit is able successfully to isolate a source from the 675 field, it will use that text to create a new 670 field, and remove the citation from the 675 field.

As is the case with a 675 field containing multiple $a subfields, if you wish to extract more than one citation from the 675 field, you must extract each in a separate operation. And, as described above, if the toolkit cannot figure out where to insert the subfield $b code into the extracted text, the toolkit will ask for your assistance.

4.7.1.16. Move a field up or down in the record

Use this menu choice to change the relative position of a variable field in the authority record. This menu option has two sub-items: Down and Up. To move a field, click anywhere on the field, then select this menu item. To shift the field up one position in the record, select Move/Up; to shift the field down one position in the record, select Move/Down.

The toolkit can only change the position of a field within the context of the field-ordering rules defined in the ExtendedFieldOrder stanza of the configuration file authsup.cfg. The default version of this stanza produces the following sort order for the variable fields in an authority record:

• 001-399: in ascending order by tag. Exception: the toolkit further sorts 024 fields by their $2 codes
• 400-499: in alphabetical order (this has the side-effect of sorting 400 fields with non-Latin texts into order by script)
• 500-599: in order by information in $w/$i, and then alphabetical order
• 600-641: in ascending order by tag
• 642, 643, 644, 645, 646: in ascending order by tag, and then by subfield $5 (DLC at the top)
• 647-699: in ascending order by tag
• 700-799: in order by the second indicator
• 800-879, and 881-999: in ascending order by tag
• 880 fields (which shouldn't appear in NACO authority records): adjacent to the corresponding romanized field

Within this framework you could use Edit/Move to change the order of multiple instances of the 370 field, but you could not use Edit/Move to place a 370 field after a 374 field, and you could not use Edit/Move to put 4XX fields into some order other than alphabetical. If you ask the toolkit to move a field to a place that is contrary to the field's defined location, the toolkit will either appear to ignore your request altogether, or will move the field to the nearest place that satisfies its own field-order definition.

4.7.1.17. New (blank) record

The New record menu choice is offered as a convenience to some users. Creating a new record in this manner forces you to supply the entire record yourself, one field at a time. Whenever possible, you should create a new record by pulling information from a bibliographic record, or by deriving one authority record from another.

To create a new, blank record, select New record from the Edit menu. The toolkit will show you its field-editing panel. You must take this opportunity to supply the 1XX field for the new record. If you do not supply a new 1XX field, the toolkit will not create the new authority record.

In some circumstances, the toolkit will use information in your new 1XX field to generate additional fields. Use the toolkit's various features to complete the authority record.

4.7.1.18. Romanization

The toolkit contains a facility for converting authority access fields presented in certain vernacular scripts into the latin script, and converting some texts presented in the latin script into a vernacular script. (For example, the toolkit can convert a Russian-language 400 field given in the Cyrillic script into its latin-script equivalent, and can convert a 400 field containing a romanized Ukrainian name into the equivalent in Cyrillic script.) This procedure is commonly referred to as romanization.

The toolkit's romanization feature is controlled in large part by a series of configuration files,⁵⁷ but in one case (Korean to latin)⁵⁸ the conversion is coded into the program itself. The behavior of the toolkit's romanization feature is controlled by a number of options.

The toolkit's romanization feature is available from a sub-menu attached to the Romanize element in the Edit menu. This sub-menu contains a list of the available languages and scripts, showing you the languages and scripts that the toolkit knows about, and the directions of translation that the toolkit can perform. In this list, the designation "L-V" means that the toolkit can convert text in the latin alphabet into this vernacular script; the designation "V-L" means that the toolkit can convert text in this language/script into the latin-alphabet equivalent. For some scripts the toolkit can perform only a conversion from vernacular script to latin script, for some scripts the toolkit can perform only a conversion from latin script to the vernacular script, and for some scripts the toolkit can perform the conversion in both directions.⁵⁹

The general procedure for converting an access field from one representation to another is as follows:

• Click the cursor anywhere within a 1XX or 4XX field in the authority record displayed on the left side of the toolkit's display panel.
• Select Edit and then Romanize from the toolkit's menu, and then select the appropriate language or script.
• The toolkit will convert the text in the field according to your instructions.
• In most cases, the toolkit will simply create a new 4XX field. However, if the direction of the conversion is from a vernacular script to latin characters, the toolkit will display the new field in its field change panel. (It's often the case that the new field will require adjustments to spacing, hyphenation, and/or capitalization.)
• If it turns out that the new 4XX field has the same NACO comparison form as an existing 1XX, 4XX or 5XX field, the toolkit will appear to do nothing.

4.7.1.19. Undo edits

The toolkit keeps track of each change you make to a record; if you don't like the result of a particular change, you can use the Undo menu item to restore the record to its previous state. Because the toolkit tracks all of your changes, if you wish you can select Undo repeatedly, until you have restored the original authority record.

4.7.2.1. File/Exit

The toolkit's File/Exit menu item closes the program. If you have not saved the current version of the authority record displayed on the left side of the toolkit's main panel, the toolkit will ask you if you wish to abandon your work on that record.

4.7.2.2. File/Open

Use the toolkit's File/Open menu item to do the following:

• Create a new authority record from an access field in a bibliographic record.
• Add information from an additional authority or bibliographic record to an existing authority record.
• Modify an existing authority record (including the extraction of one identity from an undifferentiated name record)

When you select File/Open from the toolkit's menu, the toolkit presents you with a standard Windows file-open dialog panel. Use this panel to identify the file containing the record you wish to use.

The toolkit reads all of the records in the file. (The toolkit stops when it has read 200 records from the input file.) The toolkit shows you a panel like the one in the following illustration. (If the input file contains only one record, an authority record; and if you have not yet opened any records, the toolkit assumes that you want to open this authority record for modification. In this case, the toolkit doesn't bother to show you this panel.) This panel lists each authority or bibliographic record in the file. To identify the record with which you wish to work, highlight a row and click either the Open or Add button.

• Open: Begin a new item of work (create a new authority record from a bibliographic access point; modify an existing authority record; extract one entity from an undifferentiated name record). This record replaces the authority record on the left side of the toolkit's main panel.
• Add: Use information in this authority or bibliographic record to supplement the authority record on the left side of the toolkit's main panel. This record appears on the Texts tab, as the additional record.

After you have opened a file, the toolkit makes the File/Resume menu item available. Use this menu item to select another record from the same input file. (The toolkit will not prevent you from opening the same record more than once; so you can "open" the same bibliographic record multiple times to create several authority records from various access points.)

4.7.2.3. File/Resume

If you use the File/Open menu item to pull a record from a file that contains more than one record, the toolkit shows you a list of all the records in the file, and invites you to make a selection. When the toolkit reads such a file, it retains a list of all of the records in the file. If you need to do something with a different record from the save file, select the toolkit's File/Resume menu item. (You can of course select File/Open again; but that takes longer, and won't tell you which records you've examined at least once.) The toolkit shows you the same list of records; the toolkit marks records you've already seen, to help you find other records with which you may wish to work. (You may wish to visit a bibliographic multiple more than once during a session, to create authority records for several access points.)

The following illustration shows the toolkit's display of records from a file, after you have already worked with several of them.

You can use File/Resume repeatedly, until you've done everything you need to do with the records in the source file.

4.7.2.4. File/Save

The toolkit's File/Save menu item writes the current state of the authority record displayed on the left side of the toolkit's main panel to a file. A set of options control the name of the file, and whether the file contains just one record or a set of records.

4.7.3.1. Introduction

When you are working on an authority record, you will often want to exploit information in authority and bibliographic records beyond the record with which you began the operation.

• When creating a new authority record, you may need to bring in information from a second bibliographic record. For example, you might want to add a 670 field to represent a bibliographic record other than the record with which you started the task. (You might, for example, want to include a citation to a bibliographic record for an item whose statement of responsibility represents an important variant name; and then also generate a 4XX field.)
• When either creating a new authority record or modifying an existing authority record, you may need to bring in information from other authority or bibliographic records. (The id.loc.gov choice on the Web tab is another way to bring other authority records into the toolkit.)

The various toolkit modes (OCLC, independent and LC-only) offer strikingly different ways to make it possible for you to add information from additional bibliographic and authority records to an authority record. In addition to the two modes described below, you can also use the Web tab to bring a bibliographic record from a source (such as OCLC) that supports the Z39.50 protocol, or an authority record from the Library of Congress into the toolkit.

4.7.3.2. OCLC Connexion mode (Suspend and Resume)

General procedure

When you wish to add information from another record, the obvious thing to do might be to return to the OCLC Connexion client, call up a bibliographic or authority record, and tell the toolkit to absorb information from it. However, this isn't possible (at least not in a simple and direct way), because the Connexion client is unavailable whenever the authority toolkit is active: you have access to one or the other, but not both at the same time.

The toolkit's solution to this problem (in OCLC Connexion mode only) is its ability to suspend work on an authority record. When you suspend work on a record, the toolkit's main panel disappears; you can return to Connexion to call up any bibliographic or authority record. When you invoke the toolkit again, it resumes work on the previous authority record, and it also presents you with the additional record, so you can draw information from it.⁶⁰ When you resume work on an authority record in this manner, if the additional record is a bibliographic record the toolkit makes the Create 670 menu item available; if the additional record is an authority record, the toolkit makes the Create 4XX menu item available.

If the additional record is an authority record, the toolkit's Move button on the Texts tab has an enhanced capability. If the additional record is an authority record, the Texts tab also presents a Move as button under certain conditions.

Here is an outline of the steps involved in this work:

• You use the toolkit to create a new authority record, or to begin the modification of an existing authority record
• You select Suspend from the toolkit's menu. The toolkit saves its current state and disappears, leaving you again with access to the Connexion client
• You call up a single bibliographic or authority record in the Connexion client (or you call up a list of bibliographic records, and select several of the items in the list)
• You invoke the toolkit again. The display on the Texts tab includes the new bibliographic or authority record (to see it, select the Additional record radio button).
• You make additional changes to the authority record. In addition to everything else that you might do, you can (if the additional record is a bibliographic record) use the Create 670 item available on the Edit menu to generate a basic 670 field, and you can (if the additional record is an authority record) use the Create 4XX item on the Edit menu to create a 4XX field that combines 1XX fields
• You eventually select OK or Cancel from the toolkit's menu, or you select Suspend again to add information from yet another authority or bibliographic record to this authority record

The following sequence of illustrations and commentary provides a simple example of the use of this feature, drawing information from an additional bibliographic record.

The following sequence of illustrations and commentary provides a simple example of the use of this feature, drawing information from an additional authority record.

Multiple bibliographic records

It may happen that you wish to bring several additional bibliographic records into the toolkit, and use each of them in turn to enhance your authority record. You can do this as long as all of the records appear in the same search title list.

Here is an outline of the steps; these are identical with the general procedure except for one thing:

• You start work on an authority record
• You suspend work on that record
• You do a search in OCLC for additional records, and discover that several of the records in a title listing will be of use to you
• Select all of the records in the title list that you wish to bring into the toolkit
• With the title list still displayed in Connexion, activate the authority toolkit again⁶¹
• The toolkit brings all of the highlighted bibliographic records into the toolkit

The toolkit does something that may seem a bit unusual when you bring in several records from OCLC: it puts a list of the records on the Web tab, for the Z39.50 choice, as if you had retrieved a group of records via a remote search. You can use this list to move from one record to another, as is the case for Z39.50 search results. The toolkit also displays a small left/right arrow on the Texts tab; use this to move sequentially from one record to the next.

4.7.3.3. Independent mode (File of records)

When using the toolkit as an independent program, you don't need to leave the program in order to pick up an additional bibliographic or authority record. Instead, you simply open a MARC file.

• Create a MARC-format file containing a record with information you wish to add to the authority record.
• Select File and then Open from the toolkit's menu
• Use the standard Windows file-open dialog to identify the file
• The toolkit shows you a dialog panel similar to the panel shown in the following illustration. (The choices available on this panel, and the wording of those choices will vary, depending on circumstances.) Select the record of interest, and click the Add button.

  

• The toolkit presents the additional record on the right side of its panel. You make any use of the information in this record that seems appropriate to you.
• You can use this same method to bring additional bibliographic or authority records into the toolkit, one at a time.

4.7.3.4. LC-only mode

Users of the LC-only version of the toolkit can use the same technique available to users of the toolkit in independent mode to bring a supplementary authority or bibliographic record into the program, using a MARC file.

Users of the LC-only version can also bring a supplementary record from Voyager into the system more directly, by using the Open sub-item on the toolkit's Voyager menu.

• In the Voyager cataloging client, open an authority or bibliographic record containing information you wish to add to the authority record.
• Select Voyager and then Add from the toolkit's menu
• The toolkit presents the supplementary record on the right side of its panel. You make any use of the information in this record that seems appropriate to you.
• You can use this same method to bring additional bibliographic or authority records into the toolkit, one at a time.

4.7.4.1. General

Some of the fields in authority records can contain terms drawn from recognized standard vocabularies. For example, the authority 374 field (occupation) can contain terms drawn from a large number of controlled lists, such as LCSH or the Dictionary of occupational titles. The toolkit's Verify menu item gives you a way to test many of these fields against a few of these controlling vocabularies. When you select this menu item, the toolkit tests data in certain authority fields against lists of valid terms maintained elsewhere, and presents a report of its findings. At present, the toolkit's verification against external definitions is limited to vocabularies that are defined at the id.loc.gov and id.nlm.nih.gov sites, and are also capable of being searched via URL; these limitations may change in the future.⁶²

The toolkit's verification of the fields in an authority record is controlled by options.

The toolkit takes a greater or lesser amount of time to verify the fields in a record, depending on the response of the underlying web site. The response time achieved by the id.loc.gov site varies widely (two identical requests issued within minutes of each other can require markedly different amounts of time), so there is no rule of thumb that can be used to provide an estimate of the time the toolkit will require to check the fields in a record. (As the toolkit checks each heading, it displays the heading on the main panel's title bar; this gives you some clue that it's not simply stuck.) Because the verification of the fields in a record can often take rather a long time, by default the toolkit only verifies the fields in a record when you select the Verify item from the menu on the toolkit's main panel.⁶³ The toolkit's verification report does not change when you make a change to an authority record; if you wish the toolkit to re-verify an authority record, you must select the Verify menu item. (By way of contrast, the toolkit validates the contents of a record each time you make a change to the record, because the work of validation normally takes less than a second to perform.)

A search for an authorized term at the id.loc.gov and id.nlm.nih.gov sites is, unfortunately, sensitive to case, punctuation (sometimes!) and diacritics.⁶⁴ This means that a search for an authorized term will typically find a match only if the text in the authority record exactly matches the established form.⁶⁵ To confuse matters a great deal more, searches for headings that contain certain characters, such as the ampersand, refuse to find the matching heading at id.loc.gov, for reasons that are unknown.⁶⁶ All of this means that you should not simply assume that the toolkit's "not found" report is accurate; when in doubt, follow through with your own search of the appropriate database.

The toolkit generally makes no attempt to adjust for minor errors present in the fields it verifies; the match is either perfect, or it is non-existent.⁶⁷ There are of course exceptions to this general rule, to accommodate changes in practice over time.

• If the toolkit finds no match for a subfield of the 370 field, and if the subfield appears to have older-style punctuation, the toolkit will adjust the punctuation to reflect the ostensible current practice and perform a second search. If this second search produces a match, the toolkit changes the text of the subfield in the 370 field.

  	For example, given this text in 370 subfield $a:
  	Dayton, Ohio
  	The toolkit will search for "Dayton, Ohio" as the authorized term. Not finding any match, the toolkit will next search for this modified version of the text:
  	Dayton (Ohio)
  	Finding a match, the toolkit will change the text of the subfield in the 370 field to reflect current practice.

• If a subfield of the 370 field consists entirely of a recognized abbreviation, the toolkit will expand the abbreviation⁶⁸ and perform a second search. If this second search produces a match, the toolkit changes the text of the subfield in the 370 field.

  	For example, given this text in 370 subfield $c:
  	Vic.
  	The toolkit will search for "Vic." as the authorized term. Not finding any match, the toolkit will next search for this modified text:
  	Victoria
  	Finding a match, the toolkit will change the text of the subfield in the 370 field to use the full name for the place, reflecting current practice.

The following table shows the details that control the toolkit's verification of fields in an authority record.⁶⁹ (The toolkit's use of this table is subject to the field-level limitations you define as part of the toolkit's options. You have control over which of the available vocabularies the toolkit will test, and the order in which it will test them. But at present, you have no control over the fine details of the toolkit's verification of fields.) This table, and so the toolkit's handling of fields in the authority record, is liable to be modified as experience is gained in this work. The toolkit's use of this table is explained in the paragraphs that follow the table.

The toolkit considers all of these fields except 4XX and 5XX fields as decomposable and combinable.

• Decomposable means that if a single field consists of independent units (such as a 370 field containing subfields $a and $e), the toolkit verifies each subfield as a separate entity; if one of these subfields can be matched to an authorized list and the other cannot, the toolkit will split the 370 field into two fields (one with subfield $2, the other without subfield $2).
• Combinable means that if the authority record contains more than one field of a given tag, and if after verification the identifying subfields (including subfield $2) of those fields are identical, the toolkit will bring the fields together into a single field.

If you have selected any option to add URIs to variable fields, the toolkit will always decompose all fields that can be decomposed (whether or not it is able to verify anything in those fields), and the toolkit will never combine fields.

When you select the Verify menu item, the toolkit compares the tag of each field in the record against its list of verificable tags. If the tag is defined as verifiable:

• If the field contains subfield $2 and the subfield $2 code is defined in this table for that field, the toolkit tests the contents of designated subfields in the field only against the vocabulary identified in subfield $2. (As is the case with so many rules, there is an important exception.)
• If the field contains subfield $2 and the subfield $2 code is not defined in this table for that field, the toolkit makes no attempt to inspect the contents of the field.
• If the field does not contain subfield $2, the toolkit tests the contents of designated subfields in the field against the vocabulary or vocabularies defined in the table (in the order you have defined), until it either finds a match, or runs out of vocabularies to test.
• If a 375 field does not contain subfield $2, and if subfield $a contains only "female" or "male", the toolkit will not attempt to verify the 375 field. (The verification report will therefore not contain a line indicating that the 375 field is valid, even though it is.) The toolkit will complain if a 375 field does not have subfield $2 and contains anything other than "female" or "male." (This doesn't mean that the 375 field is necessarily wrong.)⁷²

If a subfield is subject to verification according to the toolkit's internal definition, the toolkit tests the subfield, as given, against the terms defined for the vocabulary. If the entire subfield is defined in the vocabulary, the toolkit considers the subfield to be valid. If the entire subfield is not defined in the vocabulary:

• If the vocabulary is LCSH and if the subfield contains any double hyphens (suggesting the presence of at least one topical, form/genre, geographic or chronological subdivision),⁷³ the toolkit breaks the subfield into pieces at each set of double hyphens and attempts to verify them against LCSH and/or NAF terms. (This process is described below in a bit more detail.) If the toolkit can find authorization for all of the pieces that it tests, the toolkit considers the string as a whole to be valid as well; if the toolkit cannot find authorization for all of the pieces that it tests, the toolkit considers the string as a whole to be invalid.
• If the vocabulary is not LCSH or if the subfield does not contain any double hyphens, and if the heading contains a full stop followed by a space, the toolkit attempts to find NAF records for shorter portions of the subfield text, dividing at each full stop-space. (This is based on the assumption that the name might consist of a main corporate body name plus the names of one or more subordinate bodies.)
• In other cases, the toolkit declares the subfield to be invalid.

The toolkit's verification report reflects each subfield that the toolkit checks. (The inclusion of terms in this report is controlled by an option.) For an LCSH subfield that contains double hyphens or full stop/space, the report may also show separate elements from the subfield. If the toolkit is able to determine (to the limits of its ability) that the an entire subfield (or an element from a subfield) is valid, the report shows the text of the subfield (or element) in lowercase; if the toolkit believes that an entire subfield (or element from a subfield) is not valid, the report shows the text of the subfield (or element) in uppercase. The toolkit presents its verification report in the same box as its validation report, at the foot of the authority record. (If you have selected the appropriate option, instead of showing all of the pieces tested, the toolkit's verification report only contains subfields or elements that the toolkit cannot identify as valid.)

The verification report continues to show the results of the most recent verification each time you make any change to a record; the toolkit only changes the verification report when you explicitly request a new verification of the record by again selecting the Verify menu item. This means that if you change the text of any of the fields that the toolkit is able to verify, you will probably want to request a new verification report, so that the report accurately reflects the current contents of the record.

If a field contains multiple subfields to test, and if the toolkit is only able to verify some of those subfields, the toolkit creates a new field: one containing the verified subfield(s) (with subfield $2), the other containing the non-verified subfield(s). Conversely, if two fields with the same tag contain verifiable terms from a single vocabulary, the toolkit will combine them into a single field (unless options prevent the toolkit from combining fields.) For example, if a record contains two 372 fields without $2 and if the contents of those fields can be verified against LCSH and if those fields do not contain any other of the identifying subfields, the toolkit will merge those two fields into a single field, and add to that field $2 lcsh. By way of contrast, the toolkit will not tease apart fields that already contain subfield $2 if they contain unverifiable elements, but the verification report will show you the unverified subfields.⁷⁴

If you have asked the toolkit to add URIs to verified subfields, it will do so. Because subfields $0 and $1 are among the subfields that the toolkit uses to determine whether or not two fields can be merged, selecting the option to add URIs means that each verified element marked containing $0 or $1 must appear in its own field.

The toolkit's determination that the contents of a verified subfield do or do not correspond to the requirements of a particular vocabulary has nothing to do with whether or not the record can be added to the LC/NACO Authority File. Because information stored in these verifiable authority fields is devoid of most content designation, because searches at id.loc.gov may return "not found" even when a matching authority records is present, and because the information provided by a search of id.loc.gov does not contain everything that the toolkit could use to evaluate a string, the toolkit's judgement on a string (both found, and not found) must always be considered imperfect and provisional. If you disagree with the toolkit's judgments you can change the verified fields to match your own view of things, or leave things as they stand. As is always the case with the toolkit, you have the final responsibility for the contents of the records you create and modify.

The following paragraphs give additional information on some of the techniques the toolkit uses to verify headings. Because of the conditions under which it works, the toolkit's verification feature will never be able to evaluate the correctness of string with 100% accuracy; but if you encounter situations in which you think the toolkit's actions, or its report on its actions, could be improved, please let Gary know. The one thing that's certain, is that improvements are possible. Be sure to include the heading or headings of interest in your message.

4.7.4.2. A bit more about URIs

When the toolkit is able to determine that the content of a subfield is a recognized term in some vocabulary, it is usually able also to determine the identifier that corresponds in that vocabulary to that term.⁷⁵ If you have selected the appropriate option, and if appropriate information about the construction of the URI is available, the toolkt will convert that identifier into a URI, and add it to the field in an appropriate subfield. (In some cases, the toolkit may add two subfields to the field.)

In addition to adding URIs for "headings", the toolkit may also add URIs to recognized 024 fields, and convert a term used in some instances of subfield $i into a URI in subfield $4.

This feature, added to the toolkit in the first half of 2020, will be the subject of extensive investigation and modification as the practice for using URIs in authority records evolves. Please let Gary know if you have any ideas about how this feature may be expanded, modified or improved.

4.7.4.3. Verification report details

If you double-click on any line in the toolkit's verification report, the toolkit will give you more information about that line. The detail in the little pop-up message box will include identifiers for the databases searched, the actual heading strings searched, the tags of the source fields, and (if found) any standard identifier extracted from the returned information. You can only see details for one report line at a time.

The following illustrations show typical detail reports produced for the tested strings in an authority record.

The little pop-up message window is not able to display all of the diacritics and special characters that may be present in MARC fields, so the toolkit may need to modify display text in this window. However, if the toolkit is able to find a match, it is because the diacritics and special characters in the authority record do indeed exactly match the characters in the corresponding authority record's 1XX field.

4.7.4.4. Searching in the "wrong" database

If a field being verified contains a recognized code in subfield $2, the toolkit will in general test the interesting subfields in that field only against the vocabulary identified in subfield $2. However, if the toolkit's search for the entire heading in the indicated vocabulary doesn't find a match, and if the subfield being tested doesn't contain any double hyphens, and if the indicated vocabulary is either LCSH or NAF, the toolkit silently performs a second search, using the "other" vocabulary. In addition, if you have turned on the appropriate option, the toolkit will extend the search to any other vocabularies you have defined for the field.

If the toolkit does not find a match in the vocabulary identified by the subfield $2 code but it is able to find a match in some other vocabulary, immediately after verification the toolkit will show you a list containing the affected heading or headings and the proposed new subfield $2 code for each. Use this display (as appropriate) to change the subfield $2 codes of the affected fields.

In addition, if any of the toolkit's searches of additional vocabularies finds a match, the line for the heading in the verification report begins with an asterisk. If you double-click on such a line, the toolkit will identify the vocabulary in which it found the term. You can use this information to change the code in subfield $2, or to take any other action that you deem appropriate.

4.7.4.5. Topical subfields that can be taken apart

General

The toolkit always checks first to see if it can find an authority record for the complete contents of a subfield in a particular vocabulary. If the toolkit cannot verify the entire contents of a subfield, and if the subfield contains at least one set of double hyphens (suggesting the presence of a main heading plus subject subdivisions) and if the field's vocabulary is defined as one that can contain subdivisions,⁷⁶ the toolkit also attempts to verify the various parts and sub-units of the heading, moving from left to right. The possibility that the string contains an indirect geographic subdivision (involving one or perhaps two consecutive elements preceded by double hyphens) complicates the toolkit's fragmentation of a double-hyphen-containing string into verifiable parts.

The toolkit's behavior in this complex operation is influenced by the results of the work as it progresses. (In the preceding example, if the toolkit hadn't found an authority record for Alsace (France), the toolkit would have attempted to verify the string Soil conservation--Alsace--Congresses. Had the toolkit found an authority record for Soil conservation--France, it wouldn't have bothered to search France as a separate entity.) In addition to showing the toolkit's overall evaluation of the complete subfield, the verification report may also include information about various sub-parts of the subfield.

The fact that the toolkit was able to determine that authority records exist for all of the pieces in a multi-element heading is no guarantee that the complete string is valid. For example, the toolkit does not at present have any way to determine that indirect subdivision is allowed under a main topical heading; and the toolkit has no way to know whether a given topical or form subdivision is allowed, or even makes sense, under a particular topical main heading.

Indirect subdivision

LCSH headings (in the 368, 372 and 374 fields, and perhaps others) may contain subdivisions, and some of those subdivisions may be geographic subdivisions. Geographic subdivisions may consist of a single unit (for example, the name of a country or region), or of two adjacent units (most commonly, the name of a country followed by the name of a city; but there are other possibilities). Because the definitions of the authority 368, 372 and similar fields do not support the subfield codes used in similar bibliographic fields (codes that would give the toolkit some notion of how to parse the string), whenever the toolkit cannot find an authority record for a subject string that contains two hyphens, the toolkit must consider the possibility that indirect geographic subdivision is involved. The path the toolkit must follow on its way to a resolution of the matter is occasionally a torturous one. This work is made more complicated by the fact that an LCSH indirect geographic subdivision might (when reconstituted) be validated against either LCSH or NAF.

Although the reconstruction of a geographic name from its indirect subdivision is in many instances a simple matter, there are many factors that complicate the issue. The following examples do not provide an exhaustive listing of all of the conditions that the toolkit attempts to resolve, but they should provide some indication of the kinds of problems present in the data, and the length to which the toolkit goes to find a matching authority record. If a string represents combinations of these and similar conditions, the toolkit applies various combinations of the reconstruction techniques.

The presence or absence of an authority record for the part of a subject string that includes the place name can influence the toolkit's subsequent testing. (This is because, in this case, there is no way for the toolkit to know without doing yet another search that the terminal subdivision in an intermediate established heading string is a place name.)

4.7.4.6. Corporate names that can be taken apart

If the toolkit cannot find matches for all parts of a heading, and if the first piece of the heading (which may be the entire subfield) contains at least one full stop plus a space, the toolkit tests for the possibility that the term represents the name of a corporate body plus one or more subordinate units. The toolkit behaves as if each full-stop-plus-space marks the end of one element and the start of the next. The toolkit also behaves in this manner if the candidate term does not contain any full-stop-plus-space, but does contain at least one comma-space.⁷⁷) This clever yet arbitrary behavior often produces useful results, but does not always find the correct place to divide a string.

4.7.4.7. Examples

These examples show the results of verification as it will behave when the option to combine fields is selected, and when none of the options to generate URIs is selected.

4.7.5.1. Voyager/Open

Use the toolkit's Voyager/Open menu item to do the following:

• Create a new authority record from an access field in a bibliographic record.
• Add information from an additional authority or bibliographic record to an existing authority record.
• Modify an existing authority record (including the extraction of one identity from an undifferentiated name record)

4.7.5.2. Voyager/Save

The toolkit's Voyager/Save menu item writes the current state of the authority record displayed on the left side of the toolkit's main panel to your Voyager database: either as a new record, or as an updated record. If this is a new record, the toolkit will re-display the record, showing now the new Voyager authority record control number in the 001 field.

4.8.2.1. General

The instructions immediately below describe this feature in general terms, and are applicable to most situations. Following sections of this document describe special uses of this feature to create 4XX fields, and to add information to 670 fields and 678 fields. A final section describes considerations that apply to text that contains non-roman characters.

To use a piece of text in the record on the right for some new purpose in the record on the left, proceed from the top of the tab to the bottom.

• At the top of the Texts tab is a set of radio buttons within a frame labeled Text source. The Authority record radio button is always available; this represents the authority record also displayed on the left side of the main panel. If you started from a heading in a bibliographic record, the Bibliographic record radio button is available, representing the source bibliographic record; otherwise, it's not available. If you have suspended work on a record and then resumed with an additional authority or bibliographic record, or have used the Web tab to bring in an additional authority record, the Additional record radio button is available, representing that record; otherwise, it's not available. When you select any of the available radio buttons in the Text source frame, the toolkit changes the record displayed in the large window just below the row of radio buttons.
• Carefully highlight in the record displayed on the right, the text you wish to re-use in the authority record on the left.⁷⁸ If your text is written in a right-to-left script, correctly highlighting the complete text may take several tries. The toolkit assumes that any initial or terminal punctuation that you include in your selection is an integral part of the text.
• Underneath the text display box are radio buttons that identify the use you wish to make of the selected text. Your choice here tells the toolkit the tag (and, sometimes, the subfield code) you wish to assign to the selected text when the text becomes part of the authority record on the left. As you click on radio buttons in this area, the toolkit changes the caption on the Add button to match. (For example, if you click the 373 radio button, the caption becomes Add 373.)
• If the text in the source record begins with a lowercase letter, and if you wish the text in the authority record to begin with an uppercase letter, check the Uppercase first letter box. (For example: If there is a checkmark in this box, the toolkit will change the text psychologist to Psychologist when it puts the text into the authority record.)
• After you selected the record to use, highlighted the text of interest and identified the destination of the text, click the Add [tag] button. The toolkit extracts the highlighted text and converts it into information in the authority record. The new authority field's tag and subfield code correspond to the radio button you selected. (The toolkit supplies default indicators, which you can later change as needed.)

  The following illustration shows the operation of this tab during work on an authority record for the name of a corporate body. You have discovered somewhere in the item represented by this bibliographic record that the corporate body is headquartered in Edmonton, Alberta; happily the word "Edmonton" appears in the bibliographic record. You have highlighted the relevant text in the bibliographic record, and have selected the radio button for location of headquarters (370 subfield $e)⁷⁹. When you click the Add 370 $e button, the toolkit will add a 370 field with $e Edmonton to the authority record.

  

When you use this tab to extract text from a bibliographic record (when you're creating a new authority record), the toolkit will often add corresponding information to the end of subfield $b in the first 670 field in the authority record. The toolkit cannot predict the source of this information within the item; it assumes everything is on the title page (or credits, etc., depending on the type of material). You may need to adjust the text of the 670 to reflect the true source of the information. (If you set an option to the correct value, the toolkit will not attempt to modify the 670 field.)

4.8.2.2. Creating 4XX fields

One of the radio buttons on this tab is labeled 4XX. As is the case with the other radio buttons, to use this feature you highlight some text, select a radio button (the 4XX button in this case), then click the Add button. What happens next depends on the context.

• In some cases the toolkit will immediately add a 4XX field to the authority record

  In the following illustration (showing a name/title authority record in progress), you have highlighted the text Shakespeare's tragedy of Antony and Cleopatra in a 670 field of the authority record, and have selected the 4XX radio button. When you click the Add 4XX button, the toolkit will immediately add a 400 field with $a Shakespeare, William, $d 1564-1616. $t Shakespeare's tragedy of Antony and Cleopatra to the authority record.

  

  In the following illustration (for a geographic name authority record), you have highlighted a Cyrillic script version of the name of the city. When you click the Add 4XX button, the toolkit will immediately add a 451 field with this text plus the qualifier (Ohio) to the authority record.

  

• In other cases the toolkit will list the possibilities in its multiple choice panel and invite you to make your selection. (The toolkit may ask you one or more questions before it shows you this panel.) Hint: The toolkit will recognize many common texts accompanying personal names that belong in subfield $c (the toolkit's behavior in this matter is controlled by an option); but if the selected name includes a title of nobility (such as 'Gary Strawn, Earl of Strawnton' or 'Earl Gary Strawn, of Strawnton') you should type the 400 field yourself, instead of using this feature.

  In the following illustration, you have highlighted the text District Council of Streaky Bay in the bibliographic record, and have selected the 4XX radio button.⁸⁰ When you click the Add 4XX button, the toolkit will not simply add a 410 field with this text to the authority record. There are in fact several possible constructions for 410 fields using this text—alone, and in various combinations with the authority record's 110 field. The toolkit will formulate a number of possibilities, and ask you to make a choice. (This example is continued here.)

  

When the toolkit offers you a choice of potential 4XX fields, you can select as many of the possibilities as you like, and then click the OK button; or you can click the Cancel button to reject all of them. The following bullet points describe the different things the toolkit might do when requested to generate a 4XX field.

• For simple personal names (the authority record has a 100 field with only subfield $a, $b, $c, $d and $q): if the selected text contains any internal spaces, the toolkit will generate a list of all possible "rotations" of the text.

  In the following illustration, assume that you selected the text "Jorge G. Castañeda y Alvarez de la Rosa" for use in a 400 field. The toolkit produced a list containing every possible rotation of this text, and also every possible location of an internal comma within the direct-order text. In this illustration, you have clicked on three lines, and the toolkit changed the font property on those three lines to bold to make the situation clear; if you click the OK button, the toolkit will add three 400 fields with the selected texts to the authority record.

  

• For corporate names, the toolkit will propose several possibilities of direct and subordinate placement. Many of these possibilities will make no sense in a particular context, but at least one of the proposals should be close to the one you're looking for.

  The following illustration continues an earlier example, showing the highlighted text District Council of Streaky Bay. The toolkit formulates various combinations of the text plus information from the 110 field from the authority record on the left, and presents you with the possibilities. Click once to select a line; click on a highlighted line to un-select it; you can select as many lines as you like. In this illustration, you have clicked on the second proposed 410 field, and the toolkit has changed the font property on that line to bold to make the choice clear. When you click the OK button, the toolkit will add one 410 field to the authority record.

  

In certain cases, the toolkit completes the 4XX fields with information from the 1XX field. The scheme that the toolkit uses to do this work is identical with the scheme the toolkit uses when you check the Propagate check box while editing the authority record's 1XX field.

You may assume that the toolkit will learn additional tricks as experience is gained with the 4XX radio button. When you use this feature to create a 4XX field and the toolkit doesn't behave exactly as you'd like, be sure to let Gary know.

4.8.2.3. Creating 5XX fields

One of the radio buttons on the Texts tab is labeled 5XX. As is the case with the other radio buttons, to use this feature you highlight some text and select the radio button, then click the Add button. (If you wish to re-purpose an entire access field on a bibliographic or authority record as a 5XX field, click anywhere in the field, select the 5XX radio button, and click the Move as button instead.)

Getting from the selected text to a finished 5XX field requires a couple of steps. This is primarily because there is no way for the toolkit to know what tag to use for the new 5XX field. And, if the tag is to be 500, the toolkit has no way to know what the entry element for the name should be. The toolkit first shows you a panel that allows you to select the tag, and the proper form of name to use in the new 5XX field. You can also select a text for subfield $i of the new 5XX field. After you supply this information, the toolkit presents the 5XX field in its field-editing panel, so you can make additional adjustments to it. If you select OK from the field-editing panel, the toolkit adds the finished 5XX field to your authority record.

4.8.2.4. Working with 670 fields

General

Three of the radio buttons on the Texts tab help you add information to 670 fields in the authority record.

• 670 $b: Modify an existing 670 field.
• usage: Add a statement of responsibility ("usage") to a 670 field that represents a citation of the OCLC database. If such a field already exists, the toolkit attempts to add to it; if no such field exists, the toolkit creates a new one.
• hdg: Add the text of an access point ("heading") to a 670 field that represents a citation of the OCLC database. If such a field already exists, the toolkit attempts to add to it; if no such field exists, the toolkit creates a new one.

(The Create 670 OCLC item on the Edit menu is another way to begin a 670 field describing information found in the OCLC database.)

The usage and hdg radio buttons

The following illustrations and accompanying text show the application of the usage and hdg radio buttons. These buttons only apply to a 670 field that summarizes information gleaned from the OCLC database.

Because there are (unfortunately) no firm rules governing the construction of 670 fields, the toolkit will not always be able to identify an existing 670 field that cites the OCLC database; in this case, the toolkit will create a new 670 field. If the toolkit can find an existing 670 for the OCLC database, it may not be able to recognize that it already contains access point or usage information; in this case, the toolkit will add a new clause to the existing 670 field. All this means that after the toolkit has done what it can with the information you provide, you may have to perform some tidying-up on the resulting 670 field.

The 670 $b radio button

The New and Add buttons have special behaviors when you select the 670 $b radio button.

New button: When you select the 670 $b radio button, and when you have also clicked on a 670 field in the authority record on the left, the toolkit makes the New 670 $b() button available. If you click this button, the toolkit will put the highlighted text into a new set of parentheses at the end of the selected 670 field, and offer the modified field to you in the field change panel. At the least, you will probably want to insert some relevant phrase (such as "added title page" or "brochure") before the new parenthetical expression to indicate where the information comes from.

Add button: When you select the 670 $b radio button, the toolkit makes the Add 670 $b button available. If you click this button, the toolkit adds the highlighted text to the end of the last parenthesized expression in subfield $b of the first 670 field in the authority record. If this 670 field does not contain subfield $b already, the toolkit will add the subfield. The toolkit does not present the modified 670 field for editing, but you can if you wish edit the field in the usual manner.

4.8.2.5. Adding to the 678 field

Use the radio button labeled 678 on the Texts tab to re-purpose text for use in in a 678 field. If the record already contains a 678 field, the toolkit appends the new text to the end of that field; if the record does not contain a 678 field, the toolkit creates a new one. In either case, you will need to edit the resulting 678 field to integrate the text properly.

4.8.2.6. Non-Latin characters

The toolkit uses a standard device to display MARC authority and bibliographic records; this device is able to display most of the Unicode character set. To achieve a correct display of many characters (including non-Latin characters) the toolkit has to translate some native MARC characters from one representation to another; this shift is a simple mechanical process that can be performed and reversed without loss. There is, however, one point at which the difference in representation techniques breaks down; this is only a problem with certain scripts, and then only on some workstations. (The cause of this problem is unknown. Perhaps the problem has its origin in certain versions of Windows, or certain versions of the font file.) It appears that this problem is only important if you select non-Latin characters for re-use in the authority record; and then, only certain scripts are affected.

This section concludes with a long and boring description that may contain more information than you want to bother with, so here's a somewhat shorter description of what you really need to know: When you ask the toolkit to make a secondary use of non-Latin data, one of four things will happen:

• The field that appears in the authority record is exactly what you expected. If this happens, you're in fine shape.

  In the following illustration, you have just asked the toolkit to build a 400 field from the selected text. In this case, the resulting 400 field is correct.

  

• If the toolkit recognizes that the selected text presents a translation problem, the toolkit asks for help. The toolkit is able to figure out which subfield of which variable field contains your selected text, but at present it cannot get any closer to your wishes than that. The toolkit extracts the subfield from the underlying MARC record, chops the subfield into "words" at each space, and shows you a multiple choice panel containing each of the space-delimited words from the subfield, one per line. You select each line in this display that should be included in your text (not just the first and last lines, but all of the lines), then click the OK button.

  In the following illustration, you highlighted some text in subfield $c of the 880 field linked to the 245 field (your selected text is unfortunately not visible in this illustration), and clicked the 4XX radio button to tell the toolkit how to use the selected text in the authority record. When you clicked the Add 4XX button, the toolkit recognized that the selected data presents a character-translation problem. The toolkit has isolated 880 subfield $c (paralleling 245 $c) from the MARC record that underlies the display on the Texts tab, and has presented a panel containing each space-delimited word from that subfield on a separate line. You have clicked on the two lines that represent the text of interest, and the toolkit has responded by showing those lines in bold. When you click the OK button, the toolkit will re-assemble the text (removing the terminal comma in the process), and will use that text in the next step. (In this case, because you clicked the 4XX radio button, the toolkit will use the text in its standard routine for generating candidate 4XX fields; because this authority record is for a personal name, the next thing you will see is a list of candidate 4XX fields from which you may choose one or more.)

  

  The addition of this technique to the toolkit in mid-September, 2015 may mean that you never encounter either of the two remaining possibilities, described just below.

  Please let Gary know if you have any thoughts about how this feature of the toolkit could be improved to make this task better or simpler.

• The field that appears in the authority record contains garbled data. You'll need to select the Edit/Undo menu item (or click on the field and then select the Edit/Delete menu item) to remove the offending field, and you'll need to do the work with this piece of text in OCLC instead of with this toolkit.

  In the following illustration, you have just asked the toolkit to make a 400 field from the selected text. In this case, the resulting 400 field contains nonsense characters instead of the expected non-Latin characters. You need to select the Edit/Undo menu item to remove the 400 field; this 400 field will have to be created in OCLC instead of within this toolkit.

  

• The toolkit tells you (before it adds the field) that it is unable to handle the characters in the selected text. You'll need to do the work with this piece of text in OCLC instead of with this toolkit.

A more detailed discussion of the situation follows. Skip this if you want to.

The toolkit sends to the display device a formatted version of the MARC record⁸¹, with diacritics, special characters, and non-Latin data translated into a notation that is parallel to the Unicode designations for those characters: namely, a base-10 equivalent for the hexadecimal UTF-16 character designations. The display device understands this representation of special characters, and knows how to present the characters correctly.

A difficulty arises because for some characters, at least on some workstations, the string containing the selected text that is returned by the display device employs a different scheme to report certain characters than was used in the string that the toolkit sent to the display device.

For example, the UTF-16 representation of a certain Hangul character is U+D5D5. The base-10 equivalent of hexadecimal D5D5 is 54741, so the representation of this character that the toolkit sends to the display device is "\u54741?". The display device understands this code, and shows the correct character. However, if you select a string containing this character, the display device tells the toolkit that the selected character as "\'c2".

When this unfortunate event occurs, there is an additional clue in the data returned by the display device: this is a "character set" number. (The expression "\'c2" can mean different things, relative to the character set number.) The toolkit has been taught about some of these alternate character sets, but not all of them.

• The toolkit recognizes this alternate representation for the Arabic and Hebrew scripts; each of these contains a comparatively small number of characters, and tedious experimentation has produced what seems to be a complete list of equivalents. This means that you should not encounter this problem with these two scripts.
• The toolkit does not recognize this alternate representation for CJK scripts; there are simply too many characters for the experimental method used for Arabic and Hebrew to be practical. At present, there is no solution. If characters in these scripts do not arrive correctly in the authority record on the left side of the main panel, then there is at present nothing to be done. If the toolkit adds a garbled field, you'll need to click the Edit/Undo menu item to remove the field from the authority record, and do the work yourself once the authority record arrives in OCLC.
• It is not known whether this problem also occurs for other scripts. If it does occur, the toolkit will recognize the presence of the problem through the use of the "\'" notation in the text returned by the display device, and refuse to proceed. You'll need to do the work yourself, later.

Note that this problem does not apply to non-Latin data present in a new authority record, or an authority record being updated, as long as the text arrives in the initial record. This problem should also not occur in non-Latin data placed by the toolkit into a field created from information that the toolkit pulled from the internet. If the data displayed in the record on the left side of the main panel is correct, it is safe, and it will stay safe. The problem only occurs (when it occurs at all) when the toolkit moves data from the display on the right to the authority record on the left.

4.8.3.1. General

The authority toolkit has two features that involve transferring an entire field from the record on the right to the record on the left. These features are activated via two buttons on the Texts tab whose captions begin Move plus something more. These features are produce markedly different results, and are only available in appropriate contexts.

4.8.3.2. Move a whole field, (generally) preserving the original tag

There are cases in which you will want to move an entire field from a record displayed on the right side of the toolkit's panel, to the record on the left side. The record on the right side can be the bibliographic record serving as the basis of a new authority record; or it can be an additional bibliographic or authority record brought in via the toolkit's suspend/resume feature or retrieved from the id.loc.gov site. One of the buttons on the Texts tab has as its caption the word Move plus a tag. This button does exactly this: it moves an entire field from the record on the right to the record on the left, preserving the field's tag in the process. The behavior of this button varies a bit, depending on whether the record displayed on the right side is an authority record or a bibliographic record.

• Bibliographic record: In some cases, the tag used for a given type of information is the same in the authority and bibliographic formats.⁸³ This means that there may be situations in which you will want to transfer an entire variable field from a bibliographic record on the right into the authority record on the left.
• Authority record: If the record on the right side of the toolkit's panel is an authority record, you can move any of the fields you could move were the record a bibliographic record, and you can also move any of the 1XX, 4XX, 5XX or 670 fields.

If you wish to move a field from the record on the right to the record on the left, click anywhere on the field. (You don't need to select a block of text; just click on the field.) If you click on a field that the toolkit will allow you to move, the toolkit will make the Move button available at the bottom of this tab, and will change the caption on that button to show the MARC tag. Click this Move button, and the toolkit will copy an entire field from the record on the right to the authority record on the left.

If you ask the toolkit to move the 1XX field from the authority record on the right to the authority record on the left, the toolkit will change the tag of the field from 1XX to 5XX. (The toolkit transfers 4XX and 5XX fields from one authority record to another without changing the tag.) If you use this toolkit feature to transfer a 1XX field into a new 5XX field, or to move an authority 5XX field (when the original 5XX field does not already contain subfield $i), it's likely that you will want to supply some text for subfield $i. In these cases, the toolkit will present a small window containing the same values for subfield $i as are contained in the list on the Choices tab. You can select the subfield $i text you want from this list, and it'll appear in the new 5XX field. The toolkit will automatically add the appropriate subfield $w for you.

If you don't use this small dialog box to add subfield $i to a new 5XX field, you will often want next to switch to the Choices tab, click on the new 5XX field, and add subfield $i to the new 5XX field.

When moving a field from a bibliographic record on the right to the authority record on the left, a few cautions apply.

• The toolkit does not attempt to determine whether a field is appropriate within the context of a particular authority record. For example, the toolkit will not prevent you from moving a 336 field into the authority record for a person.
• The toolkit tries to account for differences in the definition of indicator positions between the bibliographic and authority versions of a given tag, but the toolkit makes no attempt to adjust for differences in subfield coding between the two formats.

These errors, and others like them, will be reported by the toolkit's validation module, but careful use of this feature will prevent most of them.

4.8.3.3. Move the authority 1XX field to a different field

When the Texts tab displays an 'alternate' record, and when that alternate record is an authority record,⁸⁴ the toolkit makes available a button whose caption begins Move 1XX as plus a tag (and perhaps also a subfield code). This button moves the authority 1XX field from the record on the right into a different field in the record on the left. For example, you can use this feature to turn the 110 field in the authority record on the right into subfield $a in a 373 field in the authority record on the left. (This largely duplicates the effect produced by selecting the entire text of the 1XX field, and then using the Add button; but it's faster, because you don't need to select text.)

The toolkit makes this button available whenever the alternate authority record is an authority record. The toolkit changes the caption of the Move 1XX as button to correspond to the radio button selected. When you click the Move 1XX as button, the toolkit extracts the 1XX field from the authority record on the right. Except as noted below [move as 4XX], the toolkit removes any internal subfield codes from the field, and adds a new field to the record on the left, using the tag (and subfield code, as appropriate) corresponding to the radio button you selected.

There is one exception to this general procedure. If you have selected the 4XX radio button, the toolkit combines all or part of the 1XX field from the record on the right with all or part of the 1XX field from the record on the left to produce a new 4XX field. In this work, the toolkit uses exactly the same logic as it uses when you use a menu item to create a 4XX field. Because the toolkit uses the same code block for both operations, the results should be exactly the same either way. If the toolkit does not have a defined scenario for combining the two 1XX fields into a new 4XX field, the toolkit simply copies the 1XX field from the alternate record as a 4XX in the record on the left.

4.8.3.4. Create an authority 4XX or 5XX field from a bibliographic access field

In some circumstances, you may wish to create an authority 4XX or 5XX field from a bibliographic 1XX or 7XX field. For example, you may have brought into the toolkit a second bibliographic record containing an access field with an alternate name for the entity represented by the authority record on the left side of the toolkit's display. Or, you may be creating an authority record for a work from a bibliographic access field, and a different field in the same bibliographic record identifies a related entity; in this case, you may wish to add a 5XX field for the related entity to the authority record.

This is a case where the best method involves working downwards from the top of the tab. Click anywhere in the bibliographic 1XX or 7XX field you wish to re-use in the authority record. Select either the 4XX or the 5XX radio button, and then click the Move as ... button. The toolkit adds a 4XX or 5XX field to the authority record, adjusting the bibliographic indicators as necessary to fit the model used for authority records. The toolkit omits bibliogrpahic subfields (such as X00 subfield $e) that don't belong in the authority record.

Note the following about subfield $i in the new 5XX field:

• If the source bibliographic field contains subfield $i (relationship), the toolkit copies the bibliographic $i text to authority subfield $i, and adds subfield $w r.
• If the source bibliographic field does not contain subfield $i, the toolkit pops up a small panel and prompts you to select an appropriate text for subfield $i.

4.10.2.1. Introduction

The toolkit presents the 046 work area when you select the 046 radio button in the box at the top of this tab. Use this work area to build a date for the authority 046 field (special coded dates). This work area is designed to produce dates that embody most of the commonly-used features of the Extended date-time format (EDTF) scheme, without requiring that you actually know how to construct an EDTF date. (This toolkit does not at present know how to formulate some exotic and rarely-needed kinds of EDTF dates, such as multiple dates.) You can also use this work area to create an 046 field containing dates expressed as centuries, although century dates are, inexplicably, not part of the EDTF scheme. (Century dates are part of the ISO-8601 standard that underlies the EDFT scheme.)

To use the 046 feature:

• If the caption on the tab is 046, simply click on the tab
• If the caption on the tab is Assist, click on the tab and then select the 046 radio button
• If the caption on the tab is 371, select the tab, un-check the Locked box, then select the 046 radio button.

The following illustration shows the 046 work area.

If you're interested in the $f Birth, calculated radio button, see the special instructions.

Most of the time, you'll use the various controls on this form to construct a date, and proceed from the top of the tab to the bottom. The Scan the 670s button is an exception to the general method.