![]() |
Northwestern University Library |
Authority toolkit: create and modify authority records |
Program and documentation by Gary L. Strawn, Northwestern University Library.
mrsmith - at - northwestern.edu
This document describes a tool that can do three things:
This tool was originally designed to work with all types of authority records contributed to the LC/NACO Authority File as part of the NACO program: personal names, corporate and conference names, uniform titles, geographic names, series, and name/title headings. Although this tool's features continue to be developed with the NACO program in mind, this tool can be used by anyone interested in creating and maintaining authority records of the highest quality, whether a NACO participant, or not.
This tool only knows how to process information encoded according to the MARC21 format for authority data specification.1 This tool works with MARC21 data encoded using the UTF-8 encoding scheme.
This tool cannot at present be used for authority records that represent topical subject headings (including name headings plus subfields $v, $x, $y and/or $z).
|
The authority toolkit has three distinct modes of operation. (These modes are provided by three different installation packages.)
In OCLC Connexion mode, the tool reads bibliographic and authority records directly from the OCLC Connexion client, and writes new and modified authority records directly to the OCLC Connexion client. While this mode is designed with NACO participants in mind, this mode can also be used by non-NACO participants that like to do their work within the OCLC Connexion client. (Non-NACO participants working within the Connexion client will be able to use this mode to do everything described in this document except save a finished record to the LC/NACO Authority File; they will need to use an existing Connexion feature to export finished records to files.)
When running in OCLC Connexion mode, this tool is actually a system that consists of two elements working together:
The macro extracts information from an OCLC record, passes the information to the DLL, and asks the DLL to provide a service (create a new authority record from a bibliographic access point; present a new or existing authority record for enhancement). The DLL provides the service requested by the macro and eventually returns the result of its work to the macro. The macro completes the task by writing information to the OCLC Connexion client. The macro knows how to work with OCLC, but knows next to nothing about authority records. The DLL does not know the source of the information it receives, or what will happen to the information it produces, but knows a lot (though not everything) about authority records. These complementary strengths and weaknesses fit together to produce the complete system.
Whenever possible, this document will refer to the whole package as the toolkit without bothering to identify the component that carries out a task; most people won't care, anyway.
When running in OCLC Connexion mode, the toolkit does not contribute a new authority record to the LC/NACO Authority File as made available on OCLC, and it does not replace an existing record in the LC/NACO authority file. Instead, the toolkit helps you prepare an authority record, and presents the results in the OCLC Connexion client for your final approval. What happens next is up to you; if you wish to contribute the new record to the LC/NACO authority file, you must perform that action yourself.
In independent mode, the tool reads files of bibliographic and authority records (exported, perhaps, from a local library system), and writes new and modified authority records to other files. This mode can be used by any who prefer not to do their authority-related work within the OCLC Connexion client. This mode is limited to the same kinds of records that could be contributed to the LC/NACO Authority File; for example, the independent mode of this tool cannot be used to create authority records for topical headings. Gary does not build a new installer for the independent toolkit whenever he updates the underlying modules, but only on request. (Gary doesn't think that this version is used very often.)
When running in independent mode, the tool consists of a single module (an EXE). This document will also refer to this single module as the toolkit.
When running in independent mode, the toolkit creates output files of records. What happens after the toolkit finishes its work on an authority record is entirely up to you. If you wish to send a file of records to a local system, or contribute them to a cooperative project, you must take that action yourself.
The LC-only mode is only available to users at the Library of Congress. This mode provides all of the features present in independent mode, and is also able to read from and write to LC's local Voyager database. This mode also consists of a single module (an EXE file). Gary produced this version once, years ago, and has never been asked for an updated version.
Users should follow the simple naming convention used in this document, and regardless of operating mode should refer to this tool as the toolkit or as the authority toolkit,3 but never as the marcro.4 When on rare occasion this document refers specifically to the DLL, the EXE or the macro, this means that it is important for the moment that you recognize the contribution made to the toolkit's operation by a particular component.
The differences in the operating modes chiefly relate to the manner in which you begin or complete a task. (The word "task" being used here in the most general sense.) For example, the modes differ in the manner in which you begin the work of creating a new authority record from an access field in a bibliographic record, and differ in their handling of the completed new authority record. This means that this documentation has to contain mode-specific descriptions for the initial and final parts of each basic operation. (These descriptions refer to the three modes by name: OCLC Connexion mode, independent mode, and LC-only mode.) Happily, the three operating modes are identical in the fun part, the enhancement of a new or existing authority record, so the descriptions in this documentation of the toolkit's many record-enhancement features generally don't need to refer to the operating modes.
The three operating modes differ in the file you select to install the toolkit.
Many fields in an authority record are, or can be, under some degree of vocabulary control. The toolkit contains features that help you construct such fields, and ensure their accuracy5. You should take advantage of every feature of this toolkit that helps ensure the consistency and accuracy of data in authority records.
The toolkit will help you add pieces of secondary information (for example: language, country of residence) to an authority record, but the toolkit will not always be able to formulate the information in a 670 field required to support those additions. Making sure that all of the assertions in the authority record are supported by appropriate source citations is part of your job.
It is your responsibility to review the results of the toolkit's work, and to make any appropriate and necessary changes to the authority record before saving the results to the LC/NACO Authority File as either a new contribution or an updated record, or using the finished record in any other manner. You always have the final say. Under no circumstances would it be appropriate for you to justify the presence of an incorrect, inappropriate or malformed element in an authority record by claiming "It's what the program gave me." Say it again: The entire content of each authority record that you create or modify with the toolkit is your personal responsibility.
The toolkit will help you build and enhance authority records, but it does not offer any assistance with any follow-up actions that may be required and/or appropriate. It is part of your job to understand the implications of your actions for other bibliographic and authority records, and programs in which you may participate. Here are two examples, out of many:
Although it may seem to go without saying, it still needs to be said that you can't use the OCLC Connexion version of this toolkit to create and modify records in the LC/NACO Authority File on OCLC if you aren't authorized to create and modify records in the LC/NACO Authority File on OCLC. Non-NACO participants who employ the OCLC Connexion mode can use the toolkit to create and modify records, and then either save the records to the online save file and then export the records from there to a file, or directly export the records from OCLC to a file. Non-NACO participants can also use the independent mode to create and modify authority records, and save the finished products to files for use elsewhere.
Use of any part of this system (macro, DLL, EXE, and the accompanying documentation) is subject to limitations on liability.7 Use of any part of the toolkit constitutes acceptance of those conditions.
The Connexion client runs under the Microsoft Windows™ operating system, as does the independent EXE module; the toolkit described in this document is restricted to Windows workstations.
The descriptions in this document are in general written as if this toolkit were used in OCLC Connexion mode, and used just once per authority record. This may be the most common case, but there is nothing inherent in the authority toolkit that prevents multiple uses for one record.
The toolkit is able to perform such back-and-forth operations without any loss or corruption of data.
Some of the examples in this document are fabricated to illustrate particular features of this toolkit. The examples do not necessarily represent real entities or their attributes. No attempt will be made to adjust examples that show actual bibliographic and authority records, when those records are changed. The situations shown in the examples are situations that occur during the normal course of authority work, even if the particulars are no longer applicable, or never were applicable, to the entities named. Feel free to suggest additional examples, or replacement examples, especially if they will help make clear the toolkit's capabilities.
The illustrations of the toolkit's main panel generally show the panel's appearance in OCLC Connexion mode. (The toolkit shows different menu items when running in independent or LC-only mode, but is otherwise identical in all modes.) The illustrations do not necessarily show the latest version of all parts of the toolkit. For example, the usage and hdg. radio buttons were added to the Texts tab in mid-September, 2015. Illustrations in parts of this document that describe these radio buttons will of course show them, but illustrations of the Texts tab that illustrate other features of the toolkit will only be replaced (and so show all of the latest features) as they need to be changed for some other reason. Let Gary know if you find an illustration particularly jarring, and he'll arrange for a replacement.
The authority toolkit's features are open to additions and revisions. Whenever you discover the need for a change or enhancement let Gary know,8 and he'll see what can be done. A quick glance at the toolkit's revision history will demonstrate how much the toolkit can change in a short time. Most of these changes are the result of suggestions from users. With your help, the authority toolkit will become even more useful and powerful.
It's also likely that the code underlying the authority toolkit is not perfect in every detail. If something unexpected happens when you're using the toolkit, let Gary know about it. It will speed things along if you describe in excruciating detail all of the steps you took to arrive at the unexpected event, including (where relevant) OCLC bibligraphic record IDs and authority LCCNs. A full description will help Gary re-create the problem; and when he can re-create a problem, it's usually easy to come up with a fix.9
Also let Gary know if there's anything missing from the documentation, or if the documentation is unclear, or needs additional or different examples.
Users of the LC-only version will be instructed by LC staff in the installation, configuration and start-up of the toolkit on their workstations. The instructions in this documentation do not apply to the installation, configuration or start-up of the LC-only version.
|
Follow these instructions to install the toolkit for the first time, and to install later updates. If you're installing the OCLC Connexion version, the first time you run the setup program it probably won't matter whether the Connexion client is running; but later, when you install updates, you'll run into trouble if the Connexion client is running. This means that when installing the OCLC Connexion version, you might as well get into the habit of always closing the Connexion client before you run the setup program. If you're installing an update to the independent version of the toolkit, always close the toolkit, then run the installation program.
There are separate installation packages for each of the toolkit's operating modes. These packages are available at the Northwestern University Library's download site. You can if you wish install more than one package on the same workstation, and use them in alternation. Don't try to run multiple instances of the toolkit (either the same mode, or different modes) at the very same time.
After downloading one of these ZIP files, open the ZIP file and run the program setup.exe. (If you can't run setup.exe from within the ZIP file, formally extract the files from the ZIP file, and then run setup.exe.) You may need to acquire appropriate Windows privileges to run the setup program. If at any time during the installation you are informed that you already have a copy of this or that file with the same or a more recent date, click the button on the message box that means "I want to keep the file that I already have." The setup program will place files onto your computer's hard drive,10 but this is not the end of the things that need to happen before you can use the toolkit.
The folder into which the setup program deposits its files depends on your version of Microsoft Windows. For the OCLC Connexion version of the program, the folder's name should be one of these two:
For the independent version of the program, the folder's name should be one of these two:
In this folder you will find the following:
The toolkit draws on information stored in a series of configuration files to inform, control and complement its work. These configuration files have the extensions of .cfg, .xlsx or .txt.11 Most of the configuration files used by the toolkit were originally designed for use by other tools developed at Northwestern University Library; some parts of the information in these files is not used by the authority toolkit.
The setup program deposits the configuration files needed by the toolkit into the same folder as AuthDllUtf8.dll or AuthorityToolkit.exe. These configuration files must all be in the same folder, and the default folder is usually good enough. However, the configuration files don't have to be in the default folder; you can copy them to some other folder if you wish. If you choose to put these files elsewhere, define the new folder, and copy all of the .cfg, .xlsx and .txt files to that folder. If you copy the configuration files to a different folder, you must also change the Folder for configuration files setting on the toolkit's Options panel to show the new location. And finally: If you copy the configuration files to a different folder, you must deal on your own with updates to the configuration files that may arrive when you install an updated version.
The OCLC Connexion client allows you to define a one-step method to start macros, such as the macro that forms part of the Connexion version of the authority toolkit. You can define either a toolbar icon or a keyboard shortcut to start the toolkit's macro. Just how you go about this is described in the Connexion documentation itself, not in this document. The object that you want to attach to either a toolbar icon or a keyboard shortcut is the macro called AuthorityCreate,12 which is contained within the macro book NulToolkit.
In the following illustration, you have assigned the macro part of the toolkit to the keyboard shortcut "alt-minus". | |
![]() |
In the following illustration, you have assigned the macro part of the toolkit to the "2" icon on the Connexion toobar. | |
![]() |
You can start the independent version of the toolkit from the Windows Start button (it's in the Northwestern University Library folder).
The following illustration shows the toolkit's location in the Windows Start menu. (This menu has a different appearance in different versions of Windows. The programs included in the menu vary from one workstation to the next.) | |
![]() |
You can copy this shortcut to your desktop (or some other place of your choosing), making it even easier to start the toolkit.
When you first use the toolkit, most of the toolkit's options are set to default values, and you can leave all but one of these at their default values until you gain experience with the toolkit.
The one exception is the option that contains your institution's NACO symbol. (This is the code that appears in 040 subfields $a and $c.)13 The very first time you use the toolkit, it will ask you to supply this symbol, and you should take the opportunity to do so. (The toolkit will continue to ask you for this symbol each time you use the toolkit, until you change the option.) You can also go to the General tab on the toolkit's Options panel and directly change the value of the NACO symbol option. No matter how this option gets set, you should make sure that this option is correctly set to your institution's NACO symbol before you use this system to handle records that will update the LC/NACO Authority File.
Gary updates the installation package for the toolkit whenever he makes any kind of change.14 The change may be a minor bug fix or tweak, or it may involve the addition of a major new feature. (If Gary is working hard on the toolkit there can even be several updates in one day; but if Gary is working on some other project there might be a large gap between updates.) Whenever you have any problem with the toolkit, you should first install the latest version, to make sure the problem hasn't already been fixed. Whenever you think of something that the toolkit should do differently, or something new that the toolkit could do, first install the latest version, to make sure that the enhancement isn't already in place. Whether you're having problems or not, you should get into the habit of routinely checking the revision history section at the end of this document for notices of fixes and enhancements. (You can get to that section of the documentation easily at any time, via the toolkit's Help/Latest changes menu item.) Whenever you see something mentioned in the revision history that sounds like something you might be able to use, install the latest version and explore the new feature. Even if you're perfectly happy with the features in your current version of the toolkit, you should periodically update the installation, so you have all the latest bug fixes.
To install the latest version, simply fetch the updated installation package from the download site, and follow the general installation instructions. You don't need to un-install the previous version, and you don't need to worry about preserving your local settings.
If you use both the OCLC Connexion and independent versions of the toolkit on the same workstation, tell Gary when you install a new version for Connexion, so he can build you the corresponding independent version. This will ensure that both versions behave themselves, and work in exactly the same manner.
If you want to create a new authority record for one of the identities represented by an undifferentiated personal name authority record, see the special instructions.
You can also create a new authortity record by deriving a record from an existing record.
To create a new authority record, start with any OCLC bibliographic record that contains the access point you wish to establish as the 1XX field in an authority record. The bibliographic record can be a record in the online file, or a record from any of the various OCLC save files.15 The bibliographic record can contain changes that you have not yet saved. (The toolkit works with what it reads from the screen of the Connexion client; it does not pull the record from the Connexion database.) Click anywhere within the bibliographic access field that you wish to establish. (When you click on an access field in the Connexion client, Connexion puts a solid, dark frame around the field.) The bibliographic access field can contain subfields beyond those you wish to establish. The bibliographic access field can consist of a portion that is represented by an authority record plus a portion that is not represented by an authority record.16
The toolkit knows how to create an authority record from the following bibliographic fields: 100, 110, 111, 130, 24017, 24518, 49019, 600, 610, 611, 630, 651, 700, 710, 711, 730, 800, 810, 811, 830. If you ask the toolkit to use some other field as the basis for a new authority record, the toolkit will complain, and will not attempt to generate an authority record.
In the following illustration, you have selected the bibliographic 100 field. When asked, the toolkit will create an authority record with a 100 field for $a Karsten, Minna, $d 1968- | |
![]() |
In the following illustration, you have selected the bibliographic 240 field. When asked, the toolkit will create an authority record with a 100 field for $a Aubrey, John, $d 1626-1697. $t Brief lives. | |
![]() |
After selecting the access field that will serve as the basis for the new authority 1XX field, activate the toolkit by using a toolbar button or keyboard shortcut, depending on how you have configured Connexion. The toolkit gathers information from the bibliographic record.20 The toolkit will in some cases immediately show you its proposed new authority record, but in other circumstances the toolkit may first ask for your help in one or more matters it can't decide on its own. The following bullet points describe each of these issues.
For the following illustration, assume that you have selected a 110 field in a bibliographic record containing the text $a Dayton (Ohio). $b Board of Education. $b Attendance Department. This field represents three possible new headings: subfield $a by itself, subfield $a plus the first subfield $b, or all three subfields. (The toolkit makes no attempt to determine which of these may already be represented by an authority record.) The illustration shows the toolkit's presentation of this case; you have opened the drop-down list to reveal the three choices. The toolkit will create an authority record for whichever heading you select.
In the following illustration, assume that you have selected the bibliographic series field $a Tidvise skrifter. $p Organisasjon og ledelse. This illustration shows the toolkit offering two possibilities for the 1XX field in the new authority record: subfield $a by itself, or subfield $a plus subfield $p. (The toolkit makes no attempt to determine which of these may already be represented by an authority record.)
In the following illustration, you have selected the bibliographic 240 field $a Quintets, $m clarinet, violins (2), viola, cello. This illustration shows the toolkit offering two possibilities for the title segment of the 1XX field in the new authority record: the title by itself, or the title plus subfield $m. (The toolkit makes no attempt to determine which of these may already be represented by an authority record.) Because the original field in this example is the 240 field, the toolkit has changed 240 subfield code $a to $t. The mark of omission in each line indicates that the toolkit will eventually add the selected information from the 240 field to the end of the bibliographic 1XX field to create the authority 1XX field.
In the following illustration, you have selected a bibliographic 700 name/title field. This illustration shows the toolkit offering three possibilities for the 1XX field in the new authority record: the name by itself, the name plus subfield $t, and the name plus subfields $t and $p. (The toolkit makes no attempt to determine which of these may already be represented by an authority record. The toolkit knows that subfield $d is an integral part of a personal name, so in this case it does not offer subfield $a by itself as a fourth candidate.)
For example, assume that you wish to create an authority record based on a name/title 700 field in a bibliographic record for a sound recording, and further assume that the bibliographic record contains the 382 fields shown in the following illustration.
The toolkit will show all of these 382 fields (plus 380 fields, and other fields) in a multiple choice panel, and invite you to select one or more of them. You can select as many fields as you need.
In the following illustration, you have selected one of the 382 fields (shown in bold) for inclusion in the authority record. If you click the OK button, the toolkit will add the selected 382 field to the proposed new record.
After any such preliminaries, the toolkit shows the proposed new authority record on its main panel. The contents of the proposed new authority record will vary, depending on the type of entity the authority record represents, the information present in the bibliographic record, and the options you have selected. Although you cannot edit this record directly (meaning: you can't just click somewhere in a variable field and start typing), you can use the tools on the main panel to modify and enhance this record in many important ways.
Following your review and possible enhancement of the new record (and if you select the OK menu item), the toolkit calls up a blank authority workform in OCLC and writes the contents of the proposed authority record into the workform. The state of the record at this point is exactly the same as it would be had you called up a workform and filled it out yourself: you can modify the record some more, you can move the record to the online save file, you can contribute the record to the LC/NACO Authority File, or you can abandon the record without saving anything. The authority record created by the toolkit does not automatically become part of the LC/NACO Authority File; you must deliberately add it to that file yourself. The state of the finished record is entirely your responsibility.
If you want to create a new authority record for one of the identities represented by an undifferentiated personal name authority record, see the special instructions.
You can also create a record by deriving a new record from an existing record.
To create a new authority record, you need a file that contains a MARC bibliographic record, and that bibliographic record must contain an access point for the 1XX field of the new authority record.24 This bibliographic record can come from in OCLC, your local system, or any other source to which you may have access; the only requirement is that the record must be in the MARC21 bibliographic format, and must be in some folder that can be "seen" by Windows from your workstation.
Select File and then Open from the toolkit's menu. (If you want to pull in a bibliographic record from a file you opened earlier, use File and then Resume instead and then pick the record from the list.) The toolkit will show you a standard Windows find-the-file dialog box. The toolkit starts in the folder you identified as the default folder, but you can of course navigate to another folder if you need to. When you've identified the file, click the OK button on the find-the-file dialog box. If the file contains multiple records, you will need to identify the record of interest.
The toolkit may next show you a dialog panel that looks something like the following illustration. Depending on conditions, the toolkit may or may not show you this panel; if the toolkit shows you this panel, the choices available and the wording of those choices may vary.
![]() |
|
In our current example, you're creating an authority record from a bibliographic record, so select the corresponding radio button (the first one), if it's not already selected, and click the OK button. |
The toolkit displays the bibliographic record, and invites you to identify the field that should serve as the basis for the 1XX field in the new authority record.
![]() |
If the entire bibliographic field (minus obviously irrelevant subfields, such as 700 subfield $e, or 610 subfield $v) is to become the 1XX field in the new authority record, you can simply double-click on the bibliographic field. If only of some of the subfields in a bibliographic field are wanted in the 1XX field of the new authority record, carefully highlight all of the subfields to be included in the new 1XX field, and then click the OK button. If you want to create a name/title record that involves the bibliographic 240 field, use the 240 field to identify your wishes; the toolkit knows that it needs to include the bibliographic 1XX field in the finished authority 1XX field.
As is the case for the toolkit when running in OCLC Connexion mode, the independent toolkit knows how to create an authority record from the following bibliographic fields: 100, 110, 111, 130, 240, 245, 490, 600, 610, 611, 630, 651, 700, 710, 711, 730, 800, 810, 811, 830 (all subject to the restrictions mentioned above). If you ask the toolkit to use some other field as the basis for a new authority record, the toolkit will simply ignore your request.
From here on, the toolkit's behavior in independent mode parallels its behavior when used within OCLC Connexion (described above): the toolkit concerns itself with terminal punctuation of the new 1XX field, the toolkit considers 382 fields for name/title headings, and so on. (This is because the various operating modes start out differently, but funnel into a common body of instructions.) The toolkit eventually displays the proposed new authority record on the left side of its main panel, and displays the source bibliographic record on the right side. All of the system's tools for enhancing the authority record are available to you. When you finish your work on the authority record, select File and then Save from the toolkit's menu to write the record in MARC format to an output file, and use this output file for whatever purpose or purposes seem appropriate to you.
|
If you want to create a new authority record for one of the identities represented by an undifferentiated personal name authority record, see the special instructions.
You can also create a record by deriving a new record from an existing record.
In LC-only mode, you can use the file-based method available in independent mode to create a new authority record. This section tells you how to create a new authority record from a bibliographic record displayed in the Voyager cataloging client.
To create a new authority record, in the Voyager cataloging client call up any MARC bibliographic record that contains the access point that you want to use as the 1XX field of the new authority record. (The bibliographic access point can contain more subfields; for example, you can create a name-only authority record from a bibliographic name/title access point.)
Select Voyager and then Open from the toolkit's menu. The toolkit retrieves the bibliographic record from your Voyager system. If the left side of the toolkit's main panel contains an authority record, the toolkit will show the following dialog panel, so you can tell the toolkit whether you want to create a new record, or use the Voyager bib record to supplement the current authority record in some fashion:
![]() |
|
In this example, you're creating an authority record from a bibliographic record, so select the corresponding radio button (the first one), if it's not already selected, and click the OK button. |
The toolkit displays the bibliographic record, and invites you to identify the field that should serve as the basis for the 1XX field in the new authority record.
![]() |
If the entire bibliographic field (minus obviously irrelevant subfields, such as 700 subfield $e, or 610 subfield $v) is to become the 1XX field in the new authority record, you can simply double-click on the bibliographic field. If only of some of the subfields in a bibliographic field are wanted in the 1XX field of the new authority record, carefully highlight all of the subfields to be included in the new 1XX field, and then click the OK button. If you want to create a name/title record that involves the bibliographic 240 field, use the 240 field to identify your wishes; the toolkit knows that it needs to include the bibliographic 1XX field in the finished authority 1XX field.
As is the case for the toolkit when running in OCLC Connexion mode, the LC-only toolkit knows how to create an authority record from the following bibliographic fields: 100, 110, 111, 130, 240, 245, 490, 600, 610, 611, 630, 651, 700, 710, 711, 730, 800, 810, 811, 830 (all subject to the restrictions mentioned above). If you ask the toolkit to use some other field as the basis for a new authority record, the toolkit will simply ignore your request.
From here on, the toolkit's behavior in LC-only mode parallels its behavior when used within OCLC Connexion (described above): the toolkit concerns itself with terminal punctuation of the new 1XX field, the toolkit considers 382 fields for name/title headings, and so on. (This is because the various operating modes start out differently, but funnel into a common body of instructions.) The toolkit eventually displays the proposed new authority record on the left side of its main panel, and displays the source bibliographic record on the right side. All of the system's tools for enhancing the authority record are available to you. When you finish your work on the authority record, select Voyager/Save from the toolkit's menu to write the new record to your Voyager database, or select File/Save from the toolkit's menu to write the record in MARC format to an output file.
To modify an existing authority record, display the authority record in the OCLC Connexion client. The authority record can be a record in the online file, or a record from any of the various save files.25 The authority record as displayed may contain changes that you have not yet saved. (The toolkit works with what it can read from the screen of the Connexion client.) If the authority record contains code "b" in 008/32 (undifferentiated personal name) the toolkit will only allow you to work on the record under certain circumstances.
Once you've displayed an authority record you wish to modify, activate the toolkit by using a toolbar button or keyboard shortcut, depending on how you have configured Connexion. The toolkit presents the authority record on its main panel. Use the tools on the main panel to modify and enhance the record.
In the following illustration, the toolkit is presenting an existing authority record for enhancement. |
![]() |
Following your work with the record (and if you select the OK menu item), the toolkit replaces the original record in the OCLC Connexion client with your modified record.26 The state of the record at this point is exactly the same as it would be had you done all of this work yourself: you can modify the record some more, you can move the record to the online save file, you can replace the record in the LC/NACO Authority File, or you can close the record without saving anything. The authority record modified by the toolkit does not automatically replace the record in the LC/NACO Authority File; you must deliberately take that action yourself. The state of the finished record is entirely your responsibility.
To modify an authority record, you need a file that contains the MARC authority record. This record can come from OCLC, your local system, or any other source to which you may have access; the only requirements being that the record must be in the MARC21 authority format, and must be in some folder that can be "seen" by Windows from your workstation.
Select File and then Open from the toolkit's menu. The toolkit will show you a standard find-the-file dialog box. The toolkit starts in the folder you identified as the default folder, but you can of course navigate to another folder if you need to. When you've identified the file, click the OK button on the find-the-file dialog box. If the file contains multiple records, you'll need to identify the record of interest.
If the authority record contains code "b" in 008/32 (undifferentiated personal name) the toolkit will only allow you to work on the record under certain conditions. (This involves the extraction of one identity from the record to create a new authority record, and the modification of the undifferentiated name record.)
The toolkit may next show you a dialog panel that looks something like the following illustration. Depending on conditions, the toolkit may or may not show you this panel, and the choices available on this panel and their wording will vary.
![]() |
|
Select the radio button that tells the program your file contains an authority record to modify (as shown in the illustration), then click the OK button. |
The toolkit will display the authority record on the left side of its main panel. You can use any of the system's tools to make any change to the record that seems appropriate to you. When you have finished working with the record, select File and then Save from the program's menu to write the record to a file.
In LC-only mode, you can use the file-based method available in independent mode to modify an authority record. This section tells you how to modify the authority record displayed in the Voyager cataloging client.
To modify an authority record, call up the authority record in the Voyager cataloging client.
Select Voyager and then Open from the toolkit's menu. If the left side of the toolkit's main panel contains an authority record, the toolkit will show you the following dialog panel, so you can tell the toolkit whether you want to use the Voyager record to enhance the current authority record, or modify the Voyager authority record:
![]() |
|
You're modifying an existing authority record, so you should select the bottom radio button (as shown in the illustration), and click the OK button. |
If the authority record contains code "b" in 008/32 (undifferentiated personal name) the toolkit will only allow you to work on the record under certain circumstances. (This involves the extraction of one identity from the record to create a new authority record, and the modification of the undifferentiated name record.)
The toolkit will display the authority record on the left side of its main panel. You can use any of the system's tools to make any change to the record that seems appropriate to you. When you have finished working with the record, select Voyager/Save from the toolkit's menu to send the modified record back to Voyager, or select File/Save from the toolkit's menu to write the record to a file.
|
The toolkit can help you with some of the work involved in the extraction of information pertaining to one identity from an undifferentiated name authority record. This operation combines the modification of an existing record with the creation of a new record. Under your guidance, the toolkit will adjust the contents of an undifferentiated name record and put that record into the OCLC online save file; the toolkit will use information extracted from the undifferentiated name record to create a new record for one identity, and present that record to you on its main panel.
The toolkit will help you modify an existing authority record for an undifferentiated personal name, and create a new authority record for one identity formerly listed on that record, but that's probably not all that needs to happen. The toolkit will not perform any maintenance on bibliographic access points, and (if you're a NACO participant) the toolkit will not perform any of the additional steps described in LC's documentation.27
The authority record used to start this task must possess the following characteristics:
If an authority record has code "b" in 008/32 but does not have these additional characteristics, the toolkit will refuse to work with the record. The only task that the toolkit will allow you to perform on a record with code "b" in 008/32 is the task described in this section of this document.
The toolkit's presentation on its main panel of the new authority record for the extracted identity is identical to its presentation of any other new record. You can use any of the tools on the main panel to modify the record in whatever manner seems appropriate to you.
At all times, remember that you bear the ultimate responsibility for the content of both the original record and the new record.
When working with an identity extracted from an undifferentiated personal name authority record, you must modify the 100 field in the new record.28 You may want to change the text in subfield $a, or you may want to add one or more subfields (perhaps you will do both).
If you have selected the appropriate option the toolkit will prompt you to adjust the 100 field even before the toolkit shows you the proposed authority record: the toolkit puts the 100 field from the undifferentiated name record into its field-change panel, and invites you to adjust the 100 field. You should take advantage of this opportunity to put the new 100 field into proper shape as early in the process as possible. In most cases you need to add a subfield or two to the 100 field, or make some change to the text of 100 subfield $a.
The following illustration shows the toolkit's presentation of the 100 field from an undifferentiated name record. You are invited to make some change to the field. (In this particular case, adding $c (Turkey biologist), based on information in one of the 670 fields, is one possibility.) The toolkit will use the text from this box as the 100 field in the proposed new authority record for the extracted identity. | |
![]() |
|
When you click the OK button, the toolkit uses your modified 100 field in the new authority record. If you select any 400 fields from the original record for inclusion in the new record, the toolkit may propagate information from the revised 100 field into those 400 fields. |
You can also change the 100 field at any other time. To change the 100 field, click anywhere on the 100 field, then select Edit and then Change 100 from the toolkit's menu, or double-click on the 100 field. The toolkit presents the 100 field on its field change panel.
![]() |
|
When you click the OK button, the toolkit replaces the 100 field in the proposed authority record with your modified 100 field. In certain situations the toolkit also propagates information from the revised 100 field to the 400 fields. |
Some authority records for undifferentiated personal names contain one or more fields tagged 400 or 500.29 In some cases, one or more of these fields is relevant to the identity being extracted, and in some cases none is relevant; but it is not possible for the toolkit to figure this out on its own. When an authority record for an undifferentiated personal name contains 400 or 500 fields, the toolkit presents you with a box containing all of them, even before it shows you the preliminary new authority record. You can select one or more of these fields, and the toolkit will add the selected fields to the proposed authority record. (The toolkit does not remove the selected fields from the original authority record; an alternate access point may be applicable to more than one identity.)
In the following illustration, you have indicated the need to create a separate authority record for the editor of Kuo lu she pei ti tzu, by clicking on one of the 670 fields belonging to that identity. This authority record also contains 4XX fields. The 670 fields for this entity identify two variant names for this person. | |
![]() |
|
As part of its preparation for the new record, the toolkit presents all of the variant access points from the original record in its multiple choice panel, and invites you to select one or more of them; any lines you select will become 400 fields in the new authority record. In the following illustration, you have selected the first and third 400 fields (shown in bold); one of these is in a non-Latin script. If you click the OK button, the toolkit will add these two texts as 400 fields in the preliminary authority record. | |
![]() |
|
The toolkit will use its standard scheme to propagate information from the record's 100 field into the selected 400 fields. |
|
When you discover information about one of the identities represented by an undifferentiated personal name authority record that will allow you to separate that identity from the others, retrieve the authority record in OCLC.
Click on any of the 670 fields in the record for the identity you wish to establish in a new authority record.
In the following illustration, you have selected the bracketed Added entry of Real turkeys, the best known calls 670 field, and are about to activate the toolkit to ask for assistance with this identity. You could instead have selected the next 670 field, beginning Real turkeys …; the toolkit will recognize either of these fields as belonging to this identity. |
![]() |
After you select one of the 670 fields that belong to the identity to be removed from an undifferentiated personal name authority record, activate the toolkit by using a toolbar button or keyboard shortcut, depending on how you have configured Connexion. The toolkit inspects the conditions represented by the authority record. If this authority record satisfies all of the toolkit's tests, the toolkit will next do one of the following:
After making these changes to the existing LC/NACO authority record for an undifferentiated personal name, the toolkit saves the changed authority record to the online save file. The toolkit remembers the save file number, and will show it to you at the appropriate time.
The toolkit eventually displays the new authority record in its main panel.
The following illustration shows a preliminary authority record for an identity extracted from an undifferentiated name record. This authority record contains the two 400 fields selected in an earlier step, the standard 667 field for any identity extracted from an undifferentiated name record, and in this case also a 667 field identifying the non-Latin 400 field as not evaluated. When the toolkit prompted you to modify the 100 field, you added $c (Writer on steam boilers); the toolkit has propagated the new 100 subfield $c to the 400 fields. The toolkit has set 008/29 (reference status) to the appropriate value. |
![]() |
The following illustration shows the initial authority record for an identity extracted from a different undifferentiated name authority record. In this example, when the toolkit prompted you to modify the 100 field, you added $c (Turkey biologist). The toolkit supplied the required 667 field indicating that this identity was formerly represented on an undifferentiated name authority record. There were no alternate access points in the original undifferentiated name record, so there are not yet any 400 fields in this proposed authority record. |
![]() |
The new authority record is open to modification using all of the tools provided on the toolkit's main panel. Everything on the main panel works exactly as it does for a proposed new authority record. As is the case for any new authority record, once you have determined that the record is as complete as it can be, you select the OK menu item; this causes the toolkit to write the new record into an authority workform in the Connexion client. At the end of this work, the toolkit tells you the save file number for the modified authority record. (The toolkit also gives you the save file number if you select the Cancel menu item; you probably want to delete the record from the save file. In any case, the toolkit did not lock the original authority record.)
|
As is the case when it is used in OCLC Connexion mode, the toolkit can help with some of the steps involved in the extraction of one identity from an authority record for an undifferentiated personal name, but it cannot help with all of them. Although the toolkit's behavior for this work in independent mode is slightly different from its behavior in OCLC Connexion mode, the same kinds of things happen, and all the restrictions and cautions mentioned above apply.
Create a file containing an authority record for an undifferentiated personal name from which you wish to extract one identity. Select File and then Open from the toolkit's menu. The toolkit will show you a standard find-the-file dialog box. The toolkit starts in the folder you identified as the default folder, but you can of course navigate to another folder if you need to. When you've identified the file, click the OK button on the find-the-file dialog box. If the file contains multiple records, you will need to identify the record of interest.
The toolkit may next show you a dialog panel that looks something like the following illustration. Depending on conditions, the toolkit may or may not show you this panel, and the wording of the options may vary.
![]() |
|
Select the radio button that tells the program your file contains an authority record from which an identity is to be extracted (as shown in the illustration), then click the OK button. |
The toolkit notices that the record contains code "b" in 008/32 (undifferentiated personal name). The toolkit displays the authority record, and invites you to identify any of the 670 fields that represent the identity to be removed from this record.
![]() |
You can either double-click anywhere within any relevant 670 field; or you can click anywhere within a relevant 670 field and then click the OK button. If everything about this record and the 670 field checks out, the toolkit will extract from this record the 670 fields that belong to this identity and will save the modified record to a file. (The modified authority record in the file is the same as the record that the toolkit running under Connexion places into the OCLC online save file.) The toolkit then creates a new authority record for this one identity, and eventually presents it to you on its main panel for additional modifications.
|
In LC-only mode, you can use the file-based method available in independent mode to extract one identity from an undifferentiated name record. This section tells you how to do this work, starting from an authority record displayed in the Voyager cataloging client.
As is the case when it is used in OCLC Connexion mode, in LC-only mode the toolkit can help with some of the steps involved in the extraction of one identity from an authority record for an undifferentiated personal name, but it cannot help with all of them. Although the toolkit's behavior for this work in LC-only mode is slightly different from its behavior in OCLC Connexion mode, the same kinds of things happen, and all the restrictions and cautions mentioned above apply.
In the Voyager cataloging client, call up an authority record for an undifferentiated personal name. Select Voyager/Open from the toolkit's menu. If the left side of the toolkit's main panel contains an authority record, the toolkit will show you the following dialog panel, so you can tell the toolkit whether you want to use the Voyager record to enhance the current authority record, or modify (in this case, extract one identity from) the Voyager authority record:
![]() |
|
In this case you should select the bottom radio button (as shown in the illustration), and click the OK button. |
The toolkit notices that the record contains code "b" in 008/32 (undifferentiated personal name). The toolkit displays the authority record, and invites you to identify any of the 670 fields that represent the identity to be removed from this record.
![]() |
You can either double-click anywhere within any relevant 670 field; or you can click anywhere within a relevant 670 field and then click the OK button. If everything about this record and the 670 field checks out, the toolkit will extract from this record the 670 fields that belong to this identity and will write the modified record back to your Voyager database. (The modified authority record is the same as the record that the toolkit running under Connexion places into the OCLC online save file.) The toolkit then creates a new authority record for this one identity, and presents it to you on its main panel for additional modifications.
The toolkit's main panel can help you add certain kinds of information to a proposed new or existing authority record, and can help you make other kinds of changes as well. All of these changes are performed by the toolkit under your control. You cannot use the main panel to edit the authority record directly; you can only modify the record indirectly, using the tools provided.
In OCLC Connexion mode, once you activate the toolkit, you will not be able to use Connexion until you close the toolkit's main panel (by selecting Cancel, Suspend or OK from the toolkit's menu). You can however, switch to other programs, such as your favorite web browser. As soon as you select Cancel, Suspend or OK from the main panel's menu, the toolkit returns you to Connexion.
The following illustration shows a typical new authority record as presented on the main panel, ready for enhancement. This illustration shows the toolkit running in OCLC Connexion mode. (The program running in independent mode or LC-only mode is exactly the same except for some parts of the toolkit's menu bar.) |
![]() |
Across the top of the main panel is a menu. The selections in this menu are accessible via the mouse, or via keyboard shortcuts consisting of the Alt key plus some other key. The sub-choices on some of the menu items also have direct shortcuts consisting of the Ctrl key plus some other key. Selections available in the menu vary, depending on the version of the toolkit you are using, and also on the conditions presented by the authority record, and any field in that record on which you may have just clicked.
The following table summarizes the Control-key shortcuts available for items on the toolkit's menu.
|
Toolkit display areas: record and tabs
The body of the toolkit's panel is divided vertically into two parts. The left side shows your authority record. Many of the methods that the toolkit makes available for changing the record involve clicking on a variable field, then making a selection from the Edit menu. (To change a variable field, you can also simply double-click on the field.) If the toolkit finds any problems with the authority record, it will list error messages in a small window at the foot of the authority record. If you have asked the toolkit to verify controllable parts of the record, the toolkit will put its verification report into this same little window at the foot of the authority record.
The right side of the toolkit's main panel offers tools arranged on several tabs. You manipulate the tools on the tabs at the right to indicate your wishes, and the toolkit makes the corresponding changes to the authority record on the left. The tabs are essentially the same whether you are creating a new authority record or modifying an existing authority record. The following bullet points briefly summarize the work performed on each tab; click on the link for a fuller description.
There are several ways to get information about the use of the toolkit.
The following illustration shows the ? button on the main panel.
The following illustration shows the ? button on the field-edit panel.
Please let Gary know if you find something in the documentation that's unclear or incomplete. Additional (or replacement) examples that clarify the toolkit's behavior are particularly welcome.
As you use the menu items and tools on the tabs to change an authority record, the toolkit will occasionally make secondary changes for you. Most of these changes have something to do with the 4XX/5XX fields, and 008/29 (reference status):35
Let Gary know if there are additional changes of this kind that the toolkit could make automatically, as a natural consequence of some modification that you make to the authority record.
Every time you use any of the toolkit's tools or menu selections to change an authority record in any way, the toolkit passes the resulting record through a validation module that inspects the record's MARC coding and considers relationships between the elements in the record. If the record fails any of these tests, the toolkit shows you error messages in a small scrollable window at the foot of the authority record. (Some problems generate more than one error message.) Use these messages as pointers to parts of the record that need attention. The presence of messages in this box will not prevent the toolkit from sending the authority record to the Connexion client; you can ignore the toolkit's validation messages if you wish. The Connexion client has its own validation protocols; Connexion not allow you to contribute any record that breaks any of its own rules.36
Some of the toolkit's messages might be considered warnings, or queries, rather than outright descriptions of problems. In some cases, the toolkit can tell that a certain condition is often a problem, but it can't make an absolute determination in any particular case.37 You must always excercise judgement when deciding to take an action based on any of the toolkit's validation messages.
The following illustration shows an authority record with several deliberately-introduced errors. The small window below the authority record contains error messages generated by the validation module. You need to consider each message, and make appropriate changes. |
![]() |
If a validation message begins Expected 400 for and ends not found, you can double-click on the message, and the toolkit will add the 400 field to the authority record for you.
For example, the validation message in the following illustration shows that the toolkit has identified a 400 field that it thinks should be present (based on a standard manipulation of the 100 field), but is not. | |
![]() |
|
If you double-click on this message, the toolkit will add the 400 field to the authority record: | |
![]() |
Similarly, if you double-click on a validation message that reads Is the 678 tag correct, or should this be a 670 field? the toolkit will re-cast the 678 field as a 670 field.
For example, the validation message in the following illustration shows that the toolkit has identified a 678 field that it thinks might be reformulated into a 670 field. | |
![]() |
|
If you double-click on this message, the toolkit will change the 678 field into a 670 field: | |
![]() |
Some of the error messages may not be expressed as clearly as might be desired. It is also quite possible that this validation module does not detect every problem that the Connexion client can detect. Please let Gary know if you encounter any problems with or deficiencies in the toolkit's error-reporting feature.
If you have previously selected the Verify menu item for this authority record, this report will also contain information about any fields that the toolkit compared against external databases.
|
You will often need to change the content of a variable field in ways that are not otherwise provided for by the toolkit; and you will often need to add a field to an authority record in addition to the fields generated by the toolkit. The toolkit's field-change panel allows you to make any kind of change to a variable field, and to add any kind of new variable field.
The field-change panel has an optional feature that includes the display of the MARC definitions for indicators and subfield codes. To save space, most of the illustrations in this section show the appearance of the panel with this option turned off, but in most circumstances you'll probably want to turn on this very useful feature.
When you use any of these methods to tell the toolkit that you want to make some change to a variable field, the toolkit presents the variable field in its special editing panel.
The following illustration shows the toolkit's presentation in this panel of a 670 field from an authority record.
The following illustration shows the toolkit's presentation in this panel of a 100 field from an authority record. When changing an authority 1XX field, the panel has special features that are not present when creating or changing other variable fields.
You can use this panel to change the field's tag (by typing the new tag), indicators (by selecting the appropriate values from the drop-down lists) and/or text (by typing).
The following illustration shows the toolkit's presentation of this panel, ready for tag, indicators, and field text.
The Tag box contains the variable field's MARC tag. When you change the value in the Tag box, one or two things might happen:
The Ind 1 and Ind 2 boxes contain the values for the first and second indicators. In these drop-down lists, "#" represents a blank space.
The large box in the center of the panel is for the text of the variable field. Use the dollar sign to represent the subfield delimiter. (If the field text contains a dollar sign in its own right, the toolkit translates it into the symbol "{dollar}", as if it were a diacritic or special character.)
Click the Cancel button to abandon your work on this field.
Click the OK button when the tag, indicators and text of the field have the desired values:
If you select the appropriate option, the toolkit includes the current definitions for the indicators and subfield codes on its field-editing panel. (If you do not select this option, the toolkit lists all possible values (blank, and 0-9) for both indicator positions, and provides no information about valid subfield codes.) If you select this very useful option, the toolkit fetches from the LC web site the HTML page that gives the MARC information for a tag, scrapes from that page the definitions of indicators and subfield codes, and includes those definitions on this panel.39
To increase its responsiveness, the toolkit caches the MARC definitions for tags on your workstation, and checks periodically to see if the definitions have been updated. You can force the toolkit to clear its cache of MARC definitions and fetch new ones, by clicking a button on the Options panel.
The following illustration shows the appearance of the panel with this option turned on, during the editing of a 100 field. The lists for the two indicator positions contain only the defined values, and show the meaning of each value. The display includes a list of the subfield codes defined for the authority 100 field. |
![]() |
The following illustration shows the appearance of the panel with this option turned on, when creating a new variable field. As soon as you supply the 3-digit tag, the toolkit fetches the MARC definition for that field, and sets the lists of indicators and subfield codes to the current values. If there is nothing in the box for the text of the field other than the initial subfield code, the toolkit sets the values of the indicators to the default values specified by an option. |
![]() |
Whenever you change the text in the Tag box on this panel, the toolkit fetches the current MARC definition for that tag, and resets the lists on this panel to match. (The toolkit will complain if it can't find a definition for the tag.) To avoid driving yourself crazy, you should set the tag to the appropriate value first, and then deal with the other elements of the field.
Should it ever happen that you need to use the toolkit when the LC web site is unavailable, you should temporarily turn off the option that adds MARC information to this display. The toolkit's only clue that something is wrong with the LC web site will come when the attempt to fetch information times out; you'll quickly get tired of the long delays that this imposes on your work.
The large box in the center of the field-change panel (for the text of the variable field) uses labels within curly braces to display diacritics and special characters.40 *For example, the toolkit uses the text label {grave} in this window instead of the actual diacritic character of that name.) When you tell the toolkit that you want to edit a field, the toolkit translates diacritics and many special chacters into their text equivalents within curly braces. The toolkit converts these special texts within curly braces back into their proper form when you click the OK button.
The following illustration shows a 670 field as presented on the toolkit's field-editing panel. The toolkit has translated the umlaut character in the MARC record into the text label {umlaut}. If you click the OK button, the toolkit will translate this expression back into the umlaut character. | |
![]() |
The toolkit provies a simple and error-free way for you to add diacritics and special characters to a field, using the same convention of texts within curly braces. The drop-down list in the bottom left corner of the field-editing panel contains each of the toolkit's text equivalents for diacritics and special characters. To insert one of these characters into a variable field, select a label from this drop-down list, click within the variable field at the point at which you wish to insert the diacritic or special character (you can do those two steps in either order), and click the Insert button. The toolkit inserts the text equivalent for a diacritic or special character (within curly braces) into the text of the variable field at your insertion point. The toolkit shifts the insertion point for the next character to the right of the character's closing curly brace.
You can instead use textual character entity references to input diacritics and special characters. The toolkit does not support the full range of character entity references, but it does support all that represent a character plus a diacritic, and some of the others.41 If you type a textual character entity reference containing one of the recognized texts into the field-editing panel, the toolkit will translate it into its UTF-8 equivalent when you click the OK button; if you bring the same field back into the field-editing panel, the toolkit will replace the character with its curly-brace equivalent (if available), or will use its convention for non-Latin characters.
Finally, the toolkit also recognizes numeric character entity references for input (either "&#x" plus the hexadecimal value for UTF-16 character and a semicolon, or "&#" plus the decimal equivalent for a UTF-16 character and a semicolon). If the toolkit can translate the corresponding character into a recognized equivalent, it will use its text equivalent within brackets the next time you edit the same field. (For example, if you supply "&00C9;" in a variable field, the toolkit will echo this back to you as "E{acute}".) If the toolkit cannot translate the corresponding character into a recognized equivalent, the next time you edit the field the toolkit will use its convention for non-Latin characters.
To remove any notation for a diacritic or special character, carefully delete the entire expression, including the opening and closing curly braces (or including the opening ampersand and ending semicolon).
Because the toolkit uses the dollar sign in this panel to represent the subfield delimiter, the toolkit treats any dollar signs that appear natively in a field's text as just another diacritic or special character. A dollar sign in the text appears as "{dollar}" in the field-editing panel; the toolkit translates this back into a dollar sign when it puts the field into the MARC authority record.
The representation on the field-editing panel of any non-Latin characters will be a bit scary: the toolkit one of two substitutions. (The display mode is controlled by an option.)
Because either of these designations can be mapped directly to the information in the Unicode documentation, you can, if you are really careful and you know what you are doing, use the toolkit's field-editing panel to work with non-Latin characters. However, for most people, and in most cases, it's probably best to add the non-Latin characters once the record is in a more hospitable system (OCLC, your local system, or whatever).
The following illustration shows the presentation in the field-editing panel of a 670 field that contains diacritics, and also three non-Latin characters (U+C724, U+C815 and U+C11D), with the option chosen to display the characters within square brackets. If you look carefully, you can see that there is a space between the first and second of these character representations, just as there is in the authority record itself. When you click the OK button, the toolkit translates the Unicode character labels back into the equivalent UTF-8 characters. |
![]() |
When you bring the authority record's 1XX field into the field-editing panel, the panel displays several check-boxes in a column at the center bottom of the frame; these boxes are not present for other variable fields:
The following illustration shows the modification of a 100 field in progress. The editing panel shows special 1XX-only check boxes at the bottom, between the ? and Cancel buttons.
These special 1XX-only check boxes are described in the following paragraphs.
A check-mark in the Propagate check-box tells the toolkit that you wish it to change 4XX fields in the authority record to correspond to the 1XX field. (If you check the Propagate box, the toolkit does this task whether or not there is any actual change to the 1XX field; so you can do a "dummy" edit of the 1XX field for the sole purpose of propagating information from the 1XX field to the 4XX fields.) The scheme that the toolkit uses to do this work is subject to change as experience is gained with it. At present the scheme consists of the following elements:
The toolkit does not use the Propagate feature to modify a 4XX field coded in subfield $w as a former heading.
Here are some examples of the use of this feature.
For example, if you start with an authority record containing these fields: |
![]() |
... and if you use this panel to add $d 1952- to the 100 field, and if you check the Propagate box, like this: |
![]() |
... the toolkit will automatically add subfield $d to the 400 fields that contain only subfield $a, producing this result: |
![]() |
For another example, if you start with an authority record containing these fields: |
![]() |
... and if you use this panel to add 1947 to the 100 subfield $d, and if you check the Propagate box, like this: |
![]() |
... the toolkit will automatically add the death date to the 400 fields that only have the birth date, producing this result: |
![]() |
A feature that forms part of the 046 feature on the toolkit's Assist tab provides a different way to achieve a similar result. |
The 'Former 1XX to 4XX' and 'Suppress' check-boxes
Under most circumstances, when you make some change to the 1XX field, you will want to preserve the former 1XX field as a 4XX field, to serve as a record of the former heading (to enable automatic bibliographic corrections, or for some other purpose). If you wish the toolkit to transmogrify the former 1XX field into a 4XX field when you make some change to the 1XX field, check the Former 1XX to 4XX check-box; this tells the toolkit to create a new 4XX field, with subfield $w. If you check this box, the toolkit also offers the Suppress check-box. If you check this Suppress box, new 4XX field will contain $w nnea; if you do not check this box, the new 4XX field will contain $w nne.
In the following illustration, you are about to make a significant change to the authority 100 field. You have checked the Former 1XX to 4XX box, but for whatever reason you have in this case decided to leave the Suppress box unchecked. |
![]() |
When you click the OK button, the toolkit re-tags the 100 field as a 400 with $w nne, adjusts the value of 008/29, and inserts the new 100 field; all as shown in the following illustration. |
![]() |
When the Tag box on the field-editing panel contains a 3-digit tag that begins with a "5", the toolkit displays a drop-down list of recognized subfield $i texts in the center of the lower border of the panel, with an accompanying button captioned Fix $i. You can do three different things with this pair of controls.
In each case, the toolkit attempts to to provide subfield $w that corresponds to your action.
In this example, you are adding a 500 field for a member of a rock band to the authority record for the band. You have selected Member from the drop-down list of recognized subfield $i texts | |
![]() |
When you click the Fix $i button, the toolkid adds subfield $i, and the appropriate subfield $w, to the text of the field. | |
![]() |
When you click the OK button, the toolkit adds the 500 field to the authority record (and changes the value of the reference status fixed-field element). |
![]() |
|
In this example, you are modifying an existing 500 field. You have selected Founded corporate body of person from the drop-down list of recognized subfield $i texts | |
![]() |
When you click the Fix $i button, the toolkit replaces the existing text of subfield $i with the new text. (Subfield $w is already the way it should be.) | |
![]() |
|
Click the OK button to replace the existing 500 field with the modified one. |
When you modify a 670 field, if the field appears to contain a URL in subfield $a,42 and if the field does not alrleady contain subfield $u, the field change panel has a button with the caption Move URL to $u.
If you click the Move URL to $u button, the toolkit will attempt to isolate the URL, fetch the corresponding page, extract the title from the page, reformulate 670 $a, and add subfield $u for the URL removed from subfield $a. If all of these tasks meet with success, the toolkit will show you the reformulated 670 field.
In the following illustration, you have brought into the field-editing panel a 670 field that contains a URL in subfield $a. The toolkit displays the Move URL to $u button. | |
![]() |
|
When you click the Move URL to $u button, the toolkit isolates the URL, retrieves the indicated page, uses the <title> tag from that page to modify the text of 670 subfield $a, and adds 670 subfield $u. | |
![]() |
If the toolkit's changes appear correct (or correct enough), you can make other modifications to the field, and eventually click the OK button; click the Cancel button to abandon all changes to the field.
Many conditions can prevent the toolkit from successfully moving the URL from 670 subfield $a to subfield $u. For example, the web page might be behind a firewall requiring a signon; or the web site may be down temporarily; or the entire web site may have disappeared. If the toolkit can't handle the task on its own, and if you believe that the task is still worth doing, you'll have to adjust the text of the 670 field yourself.
When you modify a 678 field, the field change panel has a button with the caption Reformulate 678. You should only use this button for old-style 678 fields, which contain a miscellaneous hodge-podge of information. Do not use this button for newer-style 678 fields, which contain narrative descriptions of the entity represented by the authority record.
When you click the Reformulate 678 button, the toolkit re-casts the text of the 678 field as 670 subfield $b, and supplies text in a standard form for 670 subfield $a.
In the following illustration, you have brought a 678 field into the field-editing panel. The toolkit displays the Reformulate 678 button. | |
![]() |
|
When you click the Reformulate 678 button, the toolkit changes the tag to "670", supplies appropriate indocator values, modifies the text of 678 subfield $a for use in 670 subfield $b, and supplies a standard text for 670 subfield $a. | |
![]() |
If the toolkit's changes appear correct (or correct enough), you can make other modifications to the field, and eventually click the OK button; click the Cancel button to abandon all changes to the field.
The toolkit may discover that there is more than one way to handle your request to change a record. Here are some examples of situations that can involve a selection from a range of possibilities (details for each such choice are given at the proper location in this document):
When any such a condition arises, the toolkit will show you a list of possibilities on its multiple-choice panel, and invite you to make a selection. Depending on the context, you may properly select only one, or more than one, or none, of the items from the list.
The following illustration shows the toolkit's use of the multiple-choice form to present the possible formulations for 400 fields generated from text extracted from a bibliographic record: |
![]() |
Click once on any line in the big text box to select the line; the toolkit changes the font property on that line to bold. Click on any bold line to de-select it; the toolkit changes the font property on that line back to normal. You can select as many lines as seems appropriate to you in a particular situation. If you select any lines, the toolkit makes the OK button available; the caption on that button shows the number of selected lines.
In the following illustration, you have clicked on three of the proposed texts to select them. The toolkit shows each of the selected lines in bold, and the caption of the OK button shows the number of selected lines. If you click this OK button, the toolkit will add three 400 fields to the authority record. |
![]() |
The ? button on this multiple-choice panel should take you to the point in this documentation that describes the situation that calls for your assistance. There should be a link in the documentation from that point to this section, describing the operation of this panel in general terms.
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.
The toolkit makes the Add death date sub-element available on its Edit menu if your authority record presents all of the following characteristics:
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:
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.
|
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:
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.
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.
In the following illustration, you have brought into the toolkit an authority record for a personal name. In this case, you have changed the 100 field, and as part of that work the toolkit has created a 400 field for the former heading. (You have also made other changes to the record; many other changes are also needed, but they are not the focus of this example.) When you select Edit, and then Batch and then Pick up from the toolkit's menu, the toolkit saves the 1XX field, and both 4XX fields, for future use. (If the option to create 'shadow' references is turned on, in this case the toolkit will create additional virtual 4XX fields.) | |
![]() |
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 following illustration shows the correction definition derived by the toolkit from the authority record shown in a previous illustration. (In this case, you have selected the option to generate shadow references.) You can change or delete any of these 4XX fields, and you can add any other 4XX fields that may seem appropriate. | |
![]() |
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.
The following illustration shows an authority record with access fields involving one of the 4XX fields in the current definition. (This is the definition shown in an earlier illustration.) | |
![]() |
|
Select Perform from the toolkit's Edit/Batch menu. The toolkit compares the access fields in this record to the 4XX fields in the current definition. (This involves a normalized text match.) If the toolkit finds a match, it replaces the matching portion of the access field with the 1XX field from the current definition, and makes other adjustments as appropriate. The following illustration shows the toolkit's changes to this record, based on the definition decribed in an earlier illustration. In this case, because the toolkit changed the 1XX field (and because you selected this option), the toolkit created a new 4XX field to preserve the original field. | |
![]() |
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.
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.
|
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.
|
To change a variable field43, 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.
To arrive at the following illustration, you clicked on the 670 field in an authority record, and then asked the toolkit to present the field for editing. You can change any part of this field. After changing the field, if you click the OK button, the toolkit will replace the existing 670 field with the new field, and then validate the changed record. | |
![]() |
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.
If you click on the first 046 field in this record and then select Combine 046 from the toolkit's Edit menu, the toolkit will produce a single 046 field, containing subfields $f and $g. The toolkit can combine these two 046 fields because both have the same identifying subfield ($2 edtf, in this case). | |
![]() |
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.
If you click on the first 046 field in the following record and then select Combine 046 from the toolkit's Edit menu, the toolkit will produce a single 046 field, containing only the two fuller versions of subfields $f and $g. The toolkit eventually discards subfields $f and $g found in the first 046 field because they are fully redundant with other subfields in the combined field. | |
![]() |
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.
|
Use the Create 4XX menu item to combine information from two authority records to make a new 4XX field.44 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.
Both the record on the left and the record on the right must have these characteristics:
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:
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.
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.
Given this 130 field in the record on the left: | |
$a Project report (Land Resources Development Centre (Great Britain) | |
... and this 110 field in the record on the right: | |
$a Land Resources Development Centre (Great Britain) | |
... the toolkit will add this 410 field to the record on the left: | |
$a Land Resources Development Centre (Great Britain). $t Project report |
Given this 110 field in the record on the left: | |
$a J.L. Kellogg Graduate School of Management | |
... and this 110 field in the record on the right: | |
$a Northwestern University (Evanston, Ill.) | |
... the toolkit will add this 410 field to the record on the left: | |
$a Northwestern University (Evanston, Ill.). $b J.L. Kellogg Graduate School of Management |
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.
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.
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.
In the following illustration, you have brought an additional bibliographic record into the toolkit, and you have selected the Create 670 menu item. The toolkit is presenting its default new 670 field (based on this bibliograpic record) in its field-editing panel. You may change this field in any manner that seems appropriate, and click the OK button to add the 670 field to the authority record. (In this case, you should at least add the word "Marks" to the end of 670 subfield $b.) | |
![]() |
|
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.
|
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.45 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.
Tag | Personal | Corporate | Conference |
046 | Yes; $f, $g, $s, $t | Yes; $q, $r, $s, $t | Yes; $q, $r, $s, $t46 |
368 | Yes; $a, $c | Yes; $a, $c | Yes; $a, $c |
370 | Yes; $a, $b, $c, $e, $f | Yes; $c, $e, $f | Yes; $c, $e, $f |
372 | Yes; $a, $s, $t | Yes; $a, $s, $t | Yes; $a, $s, $t |
373 | Yes; $a, $s, $t | Yes; $a, $s, $t | Yes; $a, $s, $t |
374 | Yes; $a, $s, $t | No | No |
375 | Yes; $a47 | No | No |
377 | Yes | Yes | Yes |
378 | Yes; $q | No | No |
4XX | Yes | Yes | Yes |
5XX | Depends on $i text | Depends on $i text | Depends on $i text |
663 | Yes; $a, $b | Yes; $a, $b | Yes; $a, $b |
665 | Yes; $a, $b | Yes; $a, $b | Yes; $a, $b |
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.48
The toolkit may ask one or more questions as it pulls information from the authority record for re-use in the 678 field.
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.
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.
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.
The following illustration shows the toolkit's preliminary 678 field for a person, based on the manipulation of data elements extracted from the underlying authority record. (A different selection of options would produce a slightly different proposed field.) The toolkit uses subfield $a for the entire text; you may choose to insert a subfield $b code at an appropriate point. Thorough though it may seem, this proposed 678 field requires your attention. |
![]() |
The following illustration shows the toolkit's preliminary 678 field for a different person. (This 678 field shows the program's use of selected text from 510 subfield $i, when the record contains 510 fields that parallel 373 fields.) This proposed 678 field requires your attention. |
![]() |
The following illustration shows the toolkit's preliminary 678 field for a corporate body, based on the manipulation of data elements extracted from the underlying authority record. This proposed 678 field requires your attention. |
![]() |
The following illustration shows the toolkit's preliminary 678 field for a conference, based on the manipulation of data elements extracted from the underlying authority record. This proposed 678 field requires your attention. |
![]() |
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.
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.
|
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.
For example, if you start with this authority record: | |
![]() |
|
And if after you issue the Derive command you delete "& English" from subfield $l, the toolkit will show this as the preliminary version of the new record: | |
![]() |
|
You will need to make many other changes before this record could be considered ready for contributing, or saving for use in some other environment. |
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.
For example, if you start with this authority record and click the 510 field: | |
![]() |
|
When you select Derive new record from the Edit menu the toolkit presents you with its preliminary version of the new record. Note that the toolkit has flipped the text of 500 subfield $i to reflect the change in meaning.50 | |
![]() |
|
You will need to make many changes before this record could be considered ready for contributing, or saving for use in some other environment. |
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).
For example, to create a 430 field for Exposition of the prophecies supposed by William Miller to predict the second coming of Christ in 1843, which is subfield $t of the 100 field, click anywhere in the 100 field. | |
![]() |
|
When you select Duplicate $t as 430 from the Edit menu, the toolkit adds a 430 field to the record. | |
![]() |
|
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.51 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.52
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.
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.53 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,54 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.
Example: To convert the second $a subfield of this 675 field into a 670 field, click anywhere within the second a subfield. | |
![]() |
|
When you select Extract 675 as 670 from the toolkit's Edit menu, the toolkit modifies the record as shown below. The toolkit has inserted the subfield $b code into the text of the new 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.
Example: To convert the first $a subfield in this 675 field into a 670 field, click anywhere within the first $a subfield. | |
![]() |
|
When you select Extract 675 as 670 from the toolkit's Edit menu, the toolkit modifies the record as shown below. The toolkit has inserted the subfield $b code into the text of the new 670 field. Because the original 675 field contained two instances of subfield $a, the record still contains a 675 field. In this particular case, you may well wish to repeat the operation, to convert the remaining 675 subfield $a into a 670 field. (This 675 subfield contains multiple sets of parentheses, but the toolkit will still be able to find the correct location for the subfield $b code.) | |
![]() |
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.)
Example:, To convert this 675 field to a 670 field, click anywhere within the 675 $a subfield of interest (in this record there's only the one). | |
![]() |
|
When you select Extract 675 as 670 from the toolkit's Edit menu, the toolkit inspects the 675 field, and quickly realizes that it cannot figure out on its own where to insert the subfield $b code. The toolkit presents the putative new 670 field in its record-editing panel. You can make any change to this text that you want; you'll certainly want to insert the $b code just after "3rd ed.". | |
![]() |
|
If you click the OK button on the field-editing panel, the toolkit deletes the 675 subfield $a (in this particular case, that means that the toolkit deletes the whole 675 field), and creates a 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.55 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.
Example: To convert the second citation in this 675 field into a 670 field, click anywhere within the text of the second citation ("Proceedings of the ... Joint Conference on Digital Libraries, 2008: t.p. (Joint Conference on Digital Libraries)"). | |
![]() |
|
When you select Extract 675 as 670 from the toolkit's Edit menu, the toolkit modifies the record as shown below. The toolkit has inserted the subfield $b code into the text of the new 670 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.
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:
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.
|
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.
In the following illustration, you are creating a new authority record for a personal name. The record contains default fixed field values, and a default 040 field. Because the new 100 field contains subfield $d, the toolkit has also created an 046 field. This record yet requires at least a 670 field, and may need additional fields. | |
![]() |
|
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,56 but in one case (Korean to latin)57 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.58
![]() |
The general procedure for converting an access field from one representation to another is as follows:
In the following illustration, you have clicked on the first 400 field (text is romanized from Russian) |
![]() |
When you select Edit/Romanize/Russian from the toolkit's menu, the toolkit adds a 400 field for the vernacular equivalent. The toolkit made other standard changes to the record at the same time. |
![]() |
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.
The File menu is available on the independent and LC-only versions of the toolkit, not the OCLC Connexion version. As the name might imply, operations available from the File menu involve work with files; in this case, files containing MARC records.
Because it's expected in standard Windows programs, the toolkit's File menu also contains an Exit item.
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.
Use the toolkit's File/Open menu item to do the following:
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.
![]() |
|
The columns in this table tell you whether you've selected the record previously, whether it's an authority or bibliographic record, and give the contents of the 001, 010 and 1XX (authority) or 245 (bibliographic) fields. |
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.)
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.
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.
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.
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.
|
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.59 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:
The following sequence of illustrations and commentary provides a simple example of the use of this feature, drawing information from an additional bibliographic record.
In the following illustration, you are using the toolkit to modify an existing authority record. You could just as easily be working on a new authority record created from a heading in a bibliographic record. When you select Suspend from the toolkit's menu, the toolkit saves information about its status, and the toolkit's main panel disappears. |
![]() |
You find a bibliographic record in OCLC that represents information not yet present in the authority record, such as the record shown in the following illustration (with its variant statement of responsibility). With this record displayed, you use a toobar button or keyboard shortcut to activate the toolkit again. |
![]() |
The following illustration shows the toolkit's panel immediately after resuming work under these conditions. The toolkit presents on the left side of the panel the same authority record that you were working on the last time around. (Had you earlier made any changes to this record, the record on the left would reflect those changes.) The display on the Texts tab includes an active radio button for the additional bibliographic record. (The toolkit has automatically selected this Additional record radio button, because in this context it's likely you will first want to work with the additional record.) You can use the tools on the Texts tab to work with this bibliographic record, as long as the Additional record radio button is selected; you can select the Authority record radio button to make secondary uses of information in the authority record. You can use tools on the toolkit's other tabs to make additional changes to the authority record. |
![]() |
Also under these conditions, the toolkit makes the Create 670 menu choice available on its Edit menu. |
![]() |
If you select the Create 670 item from the Edit menu, the toolkit places the proposed 670 field (based on the additional bibliographic record) into its field change panel for consideration. |
![]() |
If you click the OK button on this panel, the toolkit adds the 670 field to the authority record. |
![]() |
The authority record is available for any other change that may be needed. (In the above example, the new 670 field certainly calls for a new 400 field.) Among many other possibilities, you can again suspend work on this authority record, find another bibliographic record in OCLC, or an authority record in the LC/NACO Authority File, and then resume work on this same authority record to draw information from the next additional 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.
In the following illustration, you are using the toolkit to create a new series authority record. You could just as easily be working on an existing authority record. If you select Suspend from the toolkit's menu, the toolkit saves information about its status, and the toolkit's main panel disappears. |
![]() |
You find an authority record in the LC/NACO Authority File that contains information of use in the series authority record. (In this case, this authority record represents a corporate body responsible in an important way for the content of the series.) With this record displayed, you use a toobar button or keyboard shortcut to activate the toolkit again. |
![]() |
The following illustration shows the toolkit's panel immediately after resuming work under these conditions. The toolkit presents on the left side of the panel the same authority record that you were working on the last time around. (Had you made any changes to this record, the record on the left would reflect those changes.) The display on the Texts tab includes an active radio button for the additional authority record. (The toolkit has automatically selected the Additional record radio button, because in this context it's likely you will first want to work with the additional record.) You can use the tools on the Texts tab to work with this authority record, as long as the Additional record radio button is selected; you can select the Authority record radio button to make secondary uses of information in the authority record, and you can select the Bibliographic record radio button to make secondary uses of information in the source bibliographic record. You can use tools on the toolkit's other tabs to make additional changes to the record. |
![]() |
Also under these conditions, the toolkit makes the Create 4XX menu choice available on its Edit menu. The toolkit changes the caption on this menu item to match the tag of the field that it would add to this particular record. Given the two authority records used in this sequence of illustrations, the toolkit is able to add a name/title 410 field to the record on the left (using the name from the record on the right plus the title from the record on the left); so the caption for this menu item in this case is Create 410. |
![]() |
If you select the Create 410 item from the Edit menu, the toolkit examines the two records, to see what opportunities they present. If the two records represent a condition that has been defined to the toolkit, the toolkit constructs a 4XX field that combines information from the 1XX fields of the two records, and adds the new 4XX field to the authority record. |
![]() |
The authority record is available for any other change that may be needed. Among many other possibilities, you can again suspend work on this authority record, find another authority record in the LC/NACO Authority File, or a bibliographic record in the OCLC database, and then resume work on this same authority record to draw information from the next additional 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:
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.
In the following illustration, assume that you have previously started work on an authority record, and selected Suspend from the menu. Then you did a search that resulted in a title listing, and you have selected five titles in the list. | |
![]() |
|
When you re-activate the toolkit, the toolkit converts each highlighted record to MARC. The toolkit shows the first bibliographic on the Texts tab. (The rest are on the Web tab; see just below.) You can click the small left/right arrow just below the record display to move through the set of records, one at a time. | |
![]() |
|
All of the records are listed on the Web tab, under the Z39.50 choice, on the Results sub-tab. To see any of these records, click anywhere on the record's line, then click the Show button. The toolkit displays the record on the Texts tab. | |
![]() |
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.
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.
|
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.61
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.62 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.63 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.64 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.65 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.66 There are of course exceptions to this general rule, to accommodate changes in practice over time.
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. |
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.68 (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.
Tag | Subfields tested | URI possible? | Identifying subfields |
111 | c | No | N/A |
336 | a | Yes | 01268 |
368 | abcd | Yes | stuv01268 |
370 | abcefg | Yes | istuv012468 |
372 | a | Yes | stuv01268 |
373 | a | Yes | stuv01268 |
374 | a | Yes | stuv01268 |
375 | a | No69 | stuv268 |
376 | a | Yes | stuv0268 |
376 | b | Yes | stuv01268 |
377 | a | Yes | 01268 |
380 | a | Yes | 01268 |
381 | a | Yes | uv01268 |
382 | a | Yes70 | uv01268 |
385 | a m | Yes | 012368 |
386 | a m | Yes | 012368 |
388 | a | Yes | 012368 |
4XX | No | naf | 014568 |
5XX | Yes | naf | 014568 |
The toolkit considers all of these fields except 4XX and 5XX fields as decomposable and combinable.
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 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:
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 following illustration shows the toolkit's verification report for a record that contains two verifiable single-element fields: a 372 field and a 374 field. The toolkit was able to determine that one these fields is acceptable (the 372 field contains the valid LCSH term "Computer music") and that the other is not acceptable (the 374 field contains "Computer musicians," a term not defined in LCSH). | |
![]() |
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.73
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.
If you ask the toolkit to verify an authority record containing a 370 field like this (both subfields being valid NAF terms): | |
![]() |
|
The toolkit will add subfield $0 to each term, which will result in a separate field for each term, even though they are both NAF terms: | |
![]() |
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.
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.74 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.
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.
The following illustration shows the verification detail for a place name in Vietnam, reconstructed from two elements in a 372 field. The characters in the authority record include the "u with hook" and "o with hook" characters, which the toolkit has translated into near equivalents for display in this little window. (The toolkit has also omitted the dot under the "o with hook", because this little window can't display that character, either.) You can know that the authority 372 field contains the correct characters, because searches at id.loc.gov only find a match if the diacritics and special characters in the search term agree precisely with the characters in the corresponding authority 1XX field. | |
![]() |
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.
The following illustration shows this special display immediately after the toolkit has completed its examination of the fields in an authority record, when it has found at least one term in the "wrong" vocabulary. The list identifies each distinct heading whose $2 code can be reassigned. | |
![]() |
|
Highlight the lines that represent subfield $2 codes you would like the toolkit to change (by default, all of the lines are highlighted), and click the OK button. Given the above display, the toolkit will change the record as shown in the following illustration. Re-verify the record to get a new verification report. | |
![]() |
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.
The following illustration shows the toolkit's verification report after it has completed its examination of the fields in an authority record, when it has found at least one term in the "wrong" vocabulary. One or more lines in the verification report at the bottom of the record display begin with an asterisk. | |
![]() |
|
The detailed report for a heading found in the "wrong" file (produced by double-clicking on a line in the report) contains a bold statement to this effect, and identifies the vocabulary in which the toolkit found the term. | |
![]() |
|
In this particular case, both of the "park" headings are authorized in LCSH, not NAF. The $2 code is wrong for both of these. |
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,75 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.
For example, given this subfield in a 372 field (for which no authority record exists as a pre-composed string): | |
Soil conservation--France--Alsace--Congresses | |
The toolkit will attempt to verify some or all of the following possible constructions (and perhaps others): | |
Soil conservation | |
Soil conservation--France | |
Soil conservation--Alsace | |
France | |
Alsace (France) | |
Soil conservation--Congresses | |
In its work, the toolkit should find authority records for each of these units, except for Soil conservation--France and Soil conservation--Alsace. (See below for more information about the toolkit's reconstruction of indirect geographic subdivisions.) |
The following illustration shows the toolkit's verification report for this heading. The toolkit was able to verify all of the pieces of the subfield, but not the whole thing as a single string. The report doesn't show everything that the toolkit tried, just the parts that the toolkit believes might be of interest. (For example, the report doesn't show the results of the toolkit's unsuccessful test for the strings Soil conservation--France and Soil conservation--Alsace because the toolkit was able to account for the relevant bits in another way.) | |
![]() |
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.
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.
There are no LCSH records for the following subfields from 372 fields, as complete strings. When the toolkit encounters strings such as these, it must consider the possibility that indirect subdivision is present. | |
Theater--Study and teaching--Africa | |
Because there is no authority record for Theater--Study and teaching, but there is an authority record for the subdivision Study and teaching, the toolkit must consider the possibility that Africa is a geographic name. | |
Mongols--China--Xinjiang Uygur Zizhiqu | |
Because there is no authority record for Mongols--China, the toolkit must consider the possibility that China, Xinjiang Uygur Zizhiqu, or Xinjiang Uygur Zizhiqu (China) (and perhaps more than one of these) is a geographic name. | |
Journalism--Study and teaching (Higher)--Mississippi | |
Because there is no authority record for Journalism--Study and teaching (Higher), but there is an authority record for the subdivision Study and teaching (Higher), the toolkit must consider the possibility that Mississippi is a geographic name. | |
Occasional verse--Baltic Sea Region--History | |
Because there is no authority record for Occasional verse--Baltic Sea Region, but there is an authority record for the subdivision History, the toolkit must consider the possibility that Baltic Sea Region and Baltic Sea are geographic names. The possibility that the final subdivision in this string should be History and criticism is not a matter that the toolkit can, at present, do anything about. | |
Veterans--Medical care--West Virginia--Beckley | |
Because there is no authority record for Veterans--Medical care--West Virginia, the toolkit must consider the possibility that West Virginia, Beckley and Beckley (W.Va.) (and perhaps more than one of these) is a geographic name. | |
Natural resources--Africa, West--Management | |
Because there is no authority record for the whole subfield, but there is an authority record for Natural resources--Management, the toolkit must consider the possibility that Africa, West is a geographic name. |
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.
Name of country, state, etc. (perhaps requiring abbreviation or other modification), plus name of city: | |
Given: --France--Paris | |
Tested as: Paris (France) | |
Given: --Illinois--Chicago | |
Tested as: Chicago (Ill.) |
One element contains a parenthetical qualifier (there are many possibilities!): | |
Given: --Russia (Federation)--Moscow | |
Tested as: Moscow (Russia) | |
Given: --Ohio--Lebanon (Township) | |
Tested as: Lebanon (Township : Ohio), Lebanon (Ohio : Township) and Lebanon (Township, Ohio) | |
Given: --California--Santa Clara Valley (Santa Clara County) | |
Tested as: Santa Clara Valley (Santa Clara County : Calif.), Santa Clara Valley (Calif. : Santa Clara County) and Santa Clara Valley (Santa Clara County, Calif.) | |
Given: --Tunisia--Carthage (Extinct city) | |
Tested as: Carthage (Extinct city) and not as: Carthage (Tunisia : Extinct city) or Carthage (Extinct city : Tunisia) | |
Given: --Germany--Wolfenbüttel (Principality) | |
Tested as: Wolfenbüttel (Principality) and only if not found also tested as: Wolfenbüttel (Principality : Germany) and Wolfenbüttel (Germany : Principality) |
Headings for regions, watersheds, metropolitan areas, etc. | |
Given: --Ohio--Dayton Metropolitan Area | |
Tested as: Dayton Metropolitan Area (Ohio) and Dayton (Ohio) |
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.)
The following similar subject strings from 372 fields result in different verification paths (and so different verification reports), because of the authority records that the toolkit encounters in the course of its examination of each heading. | |
Natural resources--Washington (State)--Management | |
There is no authority record for the whole string. The toolkit will search for and find the LCSH authority record for Natural resources, and will search for but not find an authority record for Natural resources--Washington (State). The toolkit will try to find an authority record for Washington (State). Finding such a record, the toolkit will then attempt to find an authority record for Natural resources--Management. Finding such a record, the toolkit declares the full string to be valid. In this case, the toolkit does not perform a separate search for Management as a subdivision. | |
Natural resources--Soviet Union--Management | |
There is no authority record for the whole string. The toolkit will find the LCSH authority record for Natural resources, and then it will find an authority record for Natural resources--Soviet Union. The toolkit will also look for, and find, an authority record for the subdivision Management. The toolkit declares the full string to be valid. In this case, the toolkit does not perform a search for Natural resources--Management . |
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.76) This clever yet arbitrary behavior often produces useful results, but does not always find the correct place to divide a string.
United States. Army. Cavalry Reconnaissance Squadron, Mechanized, 2nd | |
There is no authority record for the whole string. The toolkit will also search for United States and United States. Army. | |
Note that this string contains a combination of full-stop-space and comma-space, any of which might serve as dividing points for subordinate units. When a string contains this mixture of punctuation, the toolkit only divides the string at the full stops. | |
Universidad Nacional Abierta (Venezuela), Vicerrectorado Editorial | |
There is no authority record for the whole string. The toolkit will also search for Universidad Nacional Abierta (Venezuela). If the toolkit finds a match for this portion of the heading, it will change the text of the subfield to: Universidad Nacional Abierta (Venezuela). Vicerrectorado Editorial | |
University of Michigan. Business School. Frammis Club--Bibliography | |
There is no authority record for the whole string, though there is a subdivision record for Bibliography. The toolkit will also search for University of Michigan and University of Michigan. Business School | |
University of Michigan. W.K. Kellogg Foundation. Graduate and Postgraduate Dentistry | |
There is no authority record for the whole string. The toolkit will also search for University of Michigan; University of Michigan. W.K. and University of Michigan. W.K. Kellogg Foundation |
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.
Given the following fields in an authority record: |
![]() |
... during verification the toolkit will change the record in this manner, because it found matches for all of the verifiable fields: |
![]() |
Given the following fields in an authority record: |
![]() |
... during verification the toolkit will change the record in the following manner (splitting the 372 field into two pieces), because it found matches for some but not all of the subfields. ("Children's fiction" is a non-preferred term in LCSH.) |
![]() |
Given the following fields in an authority record: |
![]() |
... during verification the toolkit will do nothing. Each of the verifiable fields in this group differs from the ostensible preferred term in some matter of punctuation, capitalization, and/or abbreviation for which the toolkit has at present no accommodation. |
Given the following fields in an authority record: |
![]() |
... during verification the toolkit will change the record in the following manner. The toolkit split the original 370 field into 2 pieces, because it found authorization for the place names in different sources. |
![]() |
Given the following fields in an authority record: |
![]() |
... during verification the toolkit will change the record in the following manner, because it found matches for some but not all of the fields. |
![]() |
You might notice that toolkit did not find a match for the "New York (New York State)" heading, and you might change the subfield to reflect the form used in the LC/NACO Authority File. If you again select the Verify menu item, the toolkit will notice that the changed subfield now matches an authorized string, and will change the record in the following manner. The toolkit has brought together all of the 370 subfields that it could verify in NAF. There are still two 372 fields, because one of the subfields doesn't contain an LCSH term. |
![]() |
Given the following fields in an authority record: |
![]() |
... during verification the toolkit will change the record in the following manner. Not finding a matching authority record for the entire second subfield $a in the 373 field, the toolkit attempted to find an authority record for the "Delphi Automotive Systems" portion, but failed to do so because the name used in the 373 field lacks the parenthetical qualifier present in the NAF record. |
![]() |
The Voyager menu is only available on the LC-only version of the toolkit. These menu choices read information from, and write information to, a Voyager database.
Use the toolkit's Voyager/Open menu item to do the following:
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.
|
The tools on the Texts tab transform a piece of text present in the record on the right side of the toolkit's main panel into something in the authority record on the left side. The main point of this tab is to save you from typing out text that someone has already typed out. (Typing something that's already been typed is a waste of your time, and introduces the possibility of new error.) Many of the authority fields you create via the Texts tab will require further attention, but judicious use of the tools on this tab will in many cases save you unnecessary retyping.
This tab's Add capability is its original and most fully-developed function. This feature uses small bits of text from the record on the right to create new fields in the record on the left. For example, you can use this tab to turn a person's name found in a bibliographic 508 field into a 400 field in the authority record, or to transform part of a bibliographic 264 field into a 370 subfield in the authority record. When you use the controls on this tab in this manner, there need be no correspondence between the tag assigned to the bibliographic field that contains the source text and the tag of the field to be created in the authority record; any piece of text in the window on the Texts tab can be re-purposed for the authority record in any manner that seems appropriate to you.
If you are creating a new authority record from a bibliographic access field, you can initially draw on information from either the original bibliographic record or the proposed new authority record. When you are modifying an existing authority record or working on a new authority record for an identity extracted from an undifferentiated name record, you can initially draw on information only from the authority record itself. Once you've started work on an authority record, you can pull an additional authority or bibliographic record into this tab, and draw information from that record as well. (You can bring as many additional records into the toolkit as you want; but just one at a time.)
Over time, this tab has acquired capabilities beyond the original Add feature. Two of these features involve the transfer of an entire field from one record to another.
The following illustration shows a source bibliographic record displayed on this tab as it would appear when you are creating a new authority record from a bibliographic access field. (This tab has a slightly different appearance when you are modifying an existing authority record, and also when you have brought an additional bibliographic or authority record into the toolkit.) The record display on this tab omits some of the 0XX fields; this is simply to reduce the amount of scrolling you may need to do to get to the useful parts of the record.
![]() |
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.
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)78. 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.)
For example (continuing the preceding illustration), in this case the toolkit will add information for the location of the headquarters to the 670 field, as shown in the following illustration. Because this information may not actually be on the title page, this 670 field may require further work on your part. |
![]() |
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 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 the following illustration, you have highlighted the text District Council of Streaky Bay in the bibliographic record, and have selected the 4XX radio button.79 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.
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.
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.
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.
In the following example, you have selected the text Wilmot Spencer in the 245 field, and you have selected the 5XX radio button. | |
![]() |
|
When you click the Add 5?? button, the toolkit presents you with the following panel to gather more information. Here, you have selected the tag 500, the subfield $i text Real identity, and Spencer, Wilmot for the text of the field. | |
![]() |
|
When you click the OK button on this panel, the toolkit presents your field on its field-editing panel. You can make whatever additional changes you wish to make to the text of the field, the tag, and/or the indicators. | |
![]() |
|
When you click the OK button on the field-editing panel, the toolkit adds your field to the authority record. | |
![]() |
Three of the radio buttons on the Texts tab help you add information to 670 fields in the authority record.
(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.
Assume that you wish to create a 670 field that summarizes information gleaned from records in the OCLC database. You have decided to start by recording the person's usage in this bibliographic record, by selecting text in the statement of responsibility, and selecting the usage radio button. |
![]() |
When you click the Add 'usage' button, the toolkit inspects the authority record. In this case, because the authority record does not already contain a 670 field citing the OCLC database, the toolkit adds a new 670 field. (Had the authority record already contained such a 670 field, the toolkit would have added to any existing 'usage' clause, or would have created one.) So far, subfield $b in the new 670 field contains only the usage information you provided in this transaction. |
![]() |
Continuing with the same bibliographic record, you have in the next illustration highlighted the relevant part of an access point, and have selected the hdg. radio button. |
![]() |
When you click the Add 'hdg.' button, the toolkit inspects the authority record. In this case, the toolkit finds that the record already contains a 670 field citing the OCLC database, and that this 670 field does not already contain information about access points. The toolkit adds a new clause to the authority record, identifying the access point. (Had the 670 field already contained a recognizable clause citing access points, the toolkit would instead have added this access point to the existing clause.) |
![]() |
You can use the toolkit's suspend/resume capability to bring another bibliographic record into the toolkit, and enhance the OCLC database citation with additional usages and access points. |
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 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.
In the following illustration, you have clicked on the 670 field in the record on the left, highlighted some text, and selected the 670 $b radio button. The toolkit makes the New 670 $b() button available. |
![]() |
When you click the New 670 $b() button, the toolkit adds the selected text, within parentheses, to the end of the 670 field, and makes the field available for additional changes. |
![]() |
You should add some explanatory text in front of the new parentheses, to indicate where in the item this information appears. Other changes may also be appropriate. |
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.
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.
In the following illustration, you have selected an important piece of information from the text of one of the authority record's 670 fields, and have clicked the 678 radio button. Because this authority record already contains a 678 field, when you click the Add to 678 button the toolkit will append the selected text to the 678 field. After possibly adding other pieces of text to the 678 field, you will then need to edit the 678 field (using the field change panel) to produce a biographical note that's clear and succinct. |
![]() |
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:
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.
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.
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.
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 record80, 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.
For example, the UTF-16 designation for the acute accent is U+0301. The base-10 equivalent of the hexadecimal value 0301 is 769; the representation of the acute accent that the toolkit sends to the display device is "\u769?", and the display device knows what to do with that representation. If you select this character, the display device tells the toolkit that the selected character is "\u769?", and the toolkit translates this back into the representation of the character used in a MARC record.81 |
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.
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.
The non-Latin characters in the 400 and 670 fields of the following authority record will be represented correctly in the finished authority record. |
![]() |
|
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.
|
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.
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.
In the following illustration, you have clicked on the 383 field in the bibliographic record on the right. (The 383 field is defined in both the authority and bibliographic formats.) The toolkit responded to this click by making the Move button available, and by changing the button's caption to match the selected field's tag: Move 383. (The tag on the Add button still reflects the selected radio button, as it should, because you have also selected the 034 radio button.) When you click the Move 383 button, the toolkit will transfer the entire bibliographic 383 field into the authority record. |
![]() |
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.
The following illustration shows the small dialog window that the toolkit presents when you transfer the 1XX field, or a 5XX field that does not already contain $i, from an "additional" authority record into the authority record on the left. Select the appropriate $i text and click the OK button, or click the No $i button to transfer the field with no subfield $i. | |
![]() |
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.
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.
|
When the Texts tab displays an 'alternate' record, and when that alternate record is an authority record,83 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.
In the following illustration, you are modifying an existing authority record. You suspended work on this record, called up the LC/NACO authority record for People's Computer Company, and then resumed work on the authority record. You have clicked on the 110 field in the record on the right, and have selected the 373 radio button. The toolkit responded by changing the caption on the central button of the Texts tab to Move as 373. If you click this button, the toolkit will add a 373 field with the text People's Computer Company in subfield $a to the record on the left. Because the record on the right is an LC/NACO record and because the 373 field includes a definition for subfield $2, the finished 373 field will contain $2 naf. |
![]() |
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.
In the following illustration, you are creating a new series authority record. You suspended work on this record, called up the LC/NACO authority record for Suomen Maantieteellinen Seura, and then resumed work on the authority record. You have clicked on the 110 field in the record on the right, and have selected the 4XX radio button. The toolkit responded by changing the caption on the central button of the Texts tab to Move as 410. If you click this button, the toolkit will add a 410 field with the text $a Suomen Maantieteellinen Seura. $t Fennia to the record on the left. |
![]() |
|
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:
In the following example, you have clicked somewhere within the 1XX field (it's not necessarily to highlight a block of text), and have selected the 4XX radio button. When you click the Move as ... button, the toolkit will create an authority 400 field with the same text as the bibliographic 1XX field, in this case minus subfield $e. | |
![]() |
|
In the following illustration, you are creating an authority record for a musical composition. The bibliographic record contains a 700 field citing the work on which this work was based; you wish to preserve this information as a 5XX field in the authority record. | |
![]() |
|
When the cataloger clicks on the 700 field, the toolkit makes the 5XX radio button available, and the cataloger selects this radio button. | |
![]() |
|
When the cataloger clicks the Move as ... button, the toolkit uses the bibliographic 700 field to create an authority 500 field. The toolkit supplied subfield $w, because the bibliographic 700 field contains subfield $i. The toolkit removed the full stop from the end of the 700 field.84 | |
![]() |
|
You can add a new field to the authority record by selecting Edit and then Add new from the toolkit's menu. You can also create a new field from the Texts tab, if the tag of the new field corresponds to one of the radio buttons on this tab. Select the radio button that corresponds to the tag (and subfield code, where applicable) for the field you want to create, then click the New button. (The toolkit changes the caption on this button to correspond to the radio button you select.) The toolkit populates its field-adding panel with tag, indicators and first subfield code, and presents that form to you.
Change the indicators as necessary, and supply the complete text for the new variable field. When the field is just the way you want it, click the OK button; the toolkit adds the new field to the main authority record. (Click the Cancel button to discard the field.)
In the following illustration, you have clicked the 373 radio button. The toolkit responded to this click by changing the caption on the New button to New 373. |
![]() |
When you click the New 373 button, the toolkit presents its field-editing panel, primed for the text of the new 373 field. |
![]() |
You should either complete the field as appropriate, and then click the OK button to add the field to the authority record; or click the Cancel button to abandon the field. |
This method for creating new fields may have a small advantage (over the Edit/Add new menu item) for those who are new to authority records in the MARC format, or who use certain fields only rarely: the text that accompanies each radio button on the Texts tab helps remind the user which tag contains which bit of information.
When you use the Texts tab to add a field, the toolkit will occasionally give you more than you asked for. As always, the toolkit's behavior depends on the context.
In the following illustration, you are modifying the authority record for Schubert's Die Winterreise. You have highlighted the thematic index number "D. 911" in a 670 field, and have selected the 383 radio button.86 When you click the Add 383 button, the toolkit will compare the selected text against the recognized thematic index designations for Schubert. In this case, the toolkit will discover that D. is a recognized designation for a Schubert-related thematic index, and that the full designation for this index is Deutsch. The toolkit will add a 383 field with $c D. 911 $d Deutsch $2 mlati to the authority record.
In the following illustration, you have selected the text Electronic music in a 650 field with second indicator 0, and you have selected the 372 radio button. When you click the Add 372 button, the toolkit will add a 372 field with $a Electronic music $2 lcsh to the authority record.
In the following illustration, you have selected the text California in subfield $z of a 650 field with second indicator 0, and you have selected the 370 $e radio button. When you click the Add 370 $e button, the toolkit will add a 370 field with $e California to the authority record, but the 370 field will not contain subfield $2. If you Verify this record, the toolkit will automatically add the appropriate subfield $2 code.
Let Gary know if you think of additional similar automatic changes that the toolkit can make when you use the Texts tab to add information to the authority record.
|
Use the tools on the Choices tab to add information that comes from closed lists. (For example, there's a tool on this tab to add RDA content types to an authority record. The list of RDA content types is closed; you aren't supposed to define your own.) You choose an item from a list, and the toolkit adds it to the authority record for you. Some of the values in the lists on this tab are drawn from the toolkit's configuration files, and some are hard-coded within the toolkit.88
Where appropriate, the toolkit will automatically add subfield $2 to variable fields you create from this tab.
If you have selected the option to add URIs, some of the fields you create from this tab will also include subfield $0.
The following illustration shows the work areas on the Choices tab. There is a drop-down list on this tab for each controlled vocabulary from which you can draw terms to add to an authority record.
![]() |
Each of the drop-down lists is associated with one or more Add buttons. If there is more than one Add button for a list, you can use the items in the associated list in more than one way.
To add information from one of these lists to the authority record, select the value from a list, then click the corresponding Add button. The toolkit will automatically add any corresponding subfield $2 code.
In the following illustration, you have selected the term Females from the 375 Gender list. When you click the Add 375 button, the toolkit will add a 375 field containing $a Females $2 lcdgt to the authority record. |
![]() |
There are a few important things to note about this tab:
In the following illustration, you have typed the text kalimba ensemble into the box for the 382 field. When you click the Add 382 $a or Add 382 $b button, the toolkit will add to the authority record a 382 field with the text kalimba ensemble, but the toolkit will not add $2 lcmpt.
In the following illustration, you have clicked on the word "Rovaniemi" in 370 $e on the left, and have selected "Finland" on the right. The toolkit changed the caption of the Add to ... button to match the clicked-on subfield.
When you click the Add to 370 $e button, the toolkit adds the country name in parentheses to the selected subfield:
The Assist tab helps you build fields that present particular problems. At present, the tab offers assistance with the following fields:
At the top of the Assist tab is a frame whose contents control the behavior of this tab. The toolkit initially sets the values in this frame to match the selections on the Options panel, but you can adjust them at run-time as necessary. Manipulating the values on this tab does not change the default values themselves.
![]() |
The caption for this tab reflects the choices you make:
The following sections describe the behavior of this tab when you select the 046 or 371 radio buttons.
|
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.)
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.
In most uses of this work area, you'll start at the top and work your way to the bottom.
When everything on this tab is set to your liking, click the Add date button. The toolkit formulates the date and adds it to the authority record. (The toolkit will either add the new date to an existing 046 field or create a new 046 field, depending on its view of the conditions presented by the record.) If the date satisfies the EDTF scheme, the toolkit adds $2 edtf to the 046 field.
In the following illustration, you have selected the $f Birth radio button, supplied the year 1952, selected the month October and the day 8. You have not checked any of the Uncertain or Approximate boxes. When you click the Add date button, the toolkit will add an 046 field to the authority record with the text $f 1952-10-08 $2 edtf. |
![]() |
In the following illustration, you have selected the $g Death radio button, supplied the year 1811 and checked the Uncertain box for the year. You have selected the month March; you have not checked either the Uncertain or Approximate box in the Month/Season frame. Day of the month is set to NONE. When you click the Add date button, the toolkit will add an 046 field to the authority record with the text $g 1811?-03 $2 edtf. |
![]() |
If you want to clear the tab and start over, click the Reset button. (When you click the Add date button, the toolkit automatically resets the tab for you.)
|
Level 2 of ISO8601-2019 (same in the EDTF standard) defines a type of date called one of a set. This kind of date consists of two (or more) dates separated by commas, the whole enclosed within square brackets. This type of date is used when there is more than one possibility for a date, and the selection of one date as the correct date cannot be made based on the available evidence. This condition commonly arises for persons whose birth or death date is given only as a year in a calendar other than the Julian calendar (such as the Islamic or Jewish calendar). (Because the years in non-Julian calendars are not co-extensive with years in the Julian calendar, it is usually not possible to determine which of the possibilities is the correct year.) This condition may also arise in other contexts.
One-of-a-set dates may include a two-dot notation to indicate that all of the dates between two indicated dates are included in the choice list. The tools on the toolkit's 046 tab support all aspects of one-of-a-set dates, except for the two-dot notation. If your 046 field requires one of these features, you will need to modify the 046 field created by the toolkit.
Follow these steps to create an 046 subfield containing a set of dates:
As an example, take the following steps to create the 046 field for a person known to have been born in either 1945 or 1946.
Each of the dates in the set can contain any allowed combination of year, month, day or season; and any portion of any of the dates can have associated Uncertain or Approximate attributes.
![]() |
If you create a one of a set death date, and if you also check the Add death date to 100 $d check-box, the toolkit will use as the death date the two years in the finished 046 subfield $g, separated by "or".
|
Level 0 of ISO8601-2019 (same in the EDTF standard) defines a type of date called an interval. This kind of date defines a period of time during which an event occurred; a more precise date is not possible. (This is different from one-of-a-set dates, which represent a choice of discrete possibilities.) An interval is expressed as two dates, separated by a forward slash. The first date specifies the start of the interval, the second the end of the interval.
Level 1 of ISO8601-2019 (same in the EDTF standard) defines an extended interval, in which the beginning or ending date may be replaced by two dots, or omitted entirely. Level 1 also defines the use of markers to identify uncertain and approximate dates, as long as the markers apply to the entire date. Level 2 of ISO8601-2019 (same in the EDTF standard) defines a further refinement for intervals, allowing markers for undertain and/or approximate on individual parts of a date.
The tools on the toolkit's 046 tab support all aspects of Level 1 and Level 2 interval dates, except for the two-dot notation, and empty beginning or ending dates. If your 046 field requires one of these features, you will need to modify the 046 field created by the toolkit.
Follow these steps to create an 046 subfield containing an interval:
As an example, take the following steps to create the 046 field for a person known to have died at some time between February 1, 2004 and the end of 2005.
Either of the dates in the interval can contain any allowed combination of year, month, day or season; and any portion of either of the dates can have associated Uncertain or Approximate attributes.
![]() |
![]() |
|
When you are working with an authority record for a personal name and you select the $g Death radio button on the 046 tab, the toolkit makes the Add death date to 100 $d check box available, as well as two subsidiary check boxes: Create 4XX and Suppress94. If you check the Add death date to 100 $d box and then click the Add date button, and if the available data passes all of these tests:
... the toolkit makes these additional changes:
For example, given this authority record:
... and this configuration on the 046 tab (note the checkmarks in the Add death date to 100 $d, Create 4XX and Suppress boxes):
... when you click the Add date button the toolkit will change the record so that it looks like this:
The Add death date item on the toolkit's Edit menu is another way to make similar changes to the 100 field.
|
In some cases you will not be able to find a clear statement giving the date of a person's birth, but you will have other information that can produce at least an approximate date of birth for use in 046 subfield $f. Two pieces of information are needed to calculate the approximate birth year: a statement of the person's age at a particular moment, and the date of that moment. Most frequently, this information is found in an obituary or other post-death writing (for example: a person was so many years old on a specified date of death), but the same calculation can also be based on a statement giving the person's age at retirement, or at the time of an interview, or at the time of any other event. The critical pieces of information are a date, and the age as of that date.95
![]() |
|
Date of death: 2015-11-29; age at death: 70. Information derived from this 670 field can be used with this feature. | |
![]() |
|
Date of report: 2015-04; age at time of report: 66. Information derived from this 670 field can be used with this feature. | |
![]() |
|
Age at time of joining the regular army: 18; date of joining the army not given. This 670 field does not provide information that can be used with this feature. |
The toolkit's calculated birth date is almost always expressed as an one of a set expression96, but if information in sufficient detail is available, it will be a single date. Although the actual calculation of an approximate birthdate from a date and an age is simple enough, this feature must be used with a great deal of caution. The accuracy of this work is utterly dependent on the quality of the data taken from the source.97 This calculated date, which is no more than a best guess, should not be used in access fields.98
This tool is not able to calculate early dates; you cannot use this tool if the date of the report is earlier than 200 A.D.
To calculate an approximate date of birth from a known age and date, select the $f Birth, calculated radio button. The toolkit changes the bottom part of the work area to match this selection. (Clicking any other radio button restores the tab to its normal appearance.)
This is what the bottom part of the tab looks like when you select the $f Birth, calculated radio button: | |
![]() |
Supply the date of death or other report, and the age at the time of the report, in the corresponding boxes. Give the date and age in one of the specified formats, using only numerals and hyphens. (Leading zeroes are required for early years, but are not required for the month and day portions of dates.)
For example, supply this information for a person who died on February 25, 2016 at the age of 84 (the leading zero in "02" is not required): | |
![]() |
After you supply both pieces of information, the toolkit makes the Calculate button available. Click this button to tell the toolkit to generate 046 subfield $f from the data provided. If the toolkit accepts your data as valid, it will display the suggested 046 subfield $f text in the frame at the bottom of the tab, and will make the Use this date button available.
This illustration shows the 046 subfield $f generated from the supplied data: | |
![]() |
Click the Use this date button to add this 046 subfield $f to the authority record. Because this date is a valid EDTF date, the toolkit will supply subfield $2. The toolkit will add this subfield to an existing 046 field with $2 edtf if that field does not already have subfield $f; if no existing 046 field contains $2 edtf, the toolkit will create a new 046 field.
Here is an authority record modified using data found in its second 670 field. In this case, the toolkit added its calculated subfield $f to the existing 046 field. | |
![]() |
|
The work described in this section applies only to:
For a carefully-defined set of authority records, the toolkit is able to scan the 670 fields for detailed date information. For personal names, this means birth and death dates. For conference names, this means the opening and closing dates. The toolkit performs this work for appropriate authority records when you first bring a record into the toolkit. If, in your work with the 670 fields in a record, you make changes to the 670 fields that should be reflected in the 046 field, you can use the Scan the 670s button to pull the date information out of the 670 fields into the 046 field.
All you have to do, once the 670 fields are in order, is click the Scan the 670s button on the 046 tab. If the toolkit is able to find useful information in the record, it will either replace an existing 046 field, or add a second 046 field. (The behavior depends on the content of any existing 046 field.) If the toolkit is not able to find useful information in the record, it will show you a brief explanatory message.99
Here is a typical preliminary new authority record for a conference, created from an access field in a bibliographic record. At this point, the 046 field supplied by the toolkit is simply a copy of the year in 111 subfield $d. | |
![]() |
|
In the next illustration, you have modified the 670 field to show the full dates for the conference. | |
![]() |
|
When you click the Scan the 670s button, the toolkit looks for fuller dates in the 670 fields. In this case, the toolkit is able to find satisfactory information, and changes the 046 field to match the information in the 670 field. | |
![]() |
Use the 371 feature on the Assist tab to build a 371 field (address). Unlike the 046 feature on this same tab, which builds a field one subfield at a time, the 371 feature constructs an entire field at one stroke.
The toolkit provides work areas for each subfield in the 371 field. You must provide a value for at least one of the data subfields ($a, $b, $c, $d, $e, $m); you may optionally include values for the remaining subfields ($s, $t, $v, $z, $4).
The toolkit presents a work area for each principal subfield in the 371 field. In general, the subfields are in alphabetical order by subfield code; however, the toolkit presents the work area for subfield $d (country) as the first work area, because the selection of the country affects some of the other work areas. You should always choose the country first, and then provide values for the remaining work areas.
The following illustration shows a typical presentation by the toolkit of the work areas for the 371 field. | |
![]() |
Most of the work areas are simple text boxes: to create a subfield in your 371 field, you simply type your text into the appropriate box. If a work area is not applicable to your address, leave it blank.
Two of the work areas contain drop-down boxes.
Following the work area for subfield $z is a drop-down list containing standard diacritics and special characters. To add a diacritic or special character to the text in a text box, place the cursor in the text box at the proper place, select the name of the characater from the drop-down list, and click the Insert button. This is identical with a similar feature on the toolkit's field-editing panel.
|
Use the tools on the Web tab when you have found a web resource containing information that you wish to include in the authority record. The toolkit offers substantial assistance for resources known to be of particular use when constructing authority records, and which make information available in a structured manner that the toolkit has been taught to understand. (The toolkit offers a small amount of help for web resources other than those listed below.)
Here are the web resources that the toolkit knows about in detail:
The methods that web resources use to deliver information are constantly changing. It's entirely possible that a conversion for one of these resources that worked perfectly well one day won't work at all the next day. When this happens, be sure to let Gary know.
Note: If you commonly use some other web resource in your authority work, let Gary know; he may be able to add more web resources to this tab.100
The following illustration shows the Web tab. The features presented on this tab vary with the web resources selected in the drop-down list at the top of the tab. The default values for each resource are controlled by options.
![]() |
Using information from an external resource involves these steps, once you have identified information in an external resource that you want to apply to the authority record on which you're working:
With the exception of the Wikidata via Wikipedia data source, the toolkit's schemes for using information retrieved from Web resources is not at present open to local change, because they have to be written directly into the toolkit's program code. (However, suggestions for changes to these schemes are welcome.)
If the toolkit extracts any data from the record for some secondary use (046 field, 370 field, etc.), and if you have asked the toolkit to do so, the toolkit shows you this information in a special display. You manipulate this display to tell the toolkit which fields to add to your authority record. It is normally the case that secondary fields (046, 370, etc.) added to an authority record based on information extracted from a web site will require some degree of adjustment before the record can be considered acceptable; but at least you've been saved a lot of tedious copy-and-paste operations, or (even worse) typing.
If you have asked the toolkit to do so, it adds a 670 field to your authority record describing the web resource.
The following illustration shows a 670 field constructed from information provided by GeoNames. Because the data includes the coordinates for the place, the toolkit could also suggest an 034 field to add to the main record. If the name or alternate name elements in this field do not replicate information already present in the 151 and 451 fields of the authority record, the toolkit could also suggest one or more 451 fields. The toolkit's handling of the information pulled from a web service is under your complete control. The toolkit's 670 field always represents all of the information that the toolkit pulled from the web source, whether or not any secondary use was made of the information, and whether or not that information duplicates information found in other 670 fields. | |
![]() |
When it has completed its work with the data extracted from a web source, and if you have asked the toolkit to do so, the toolkit will take you immediately to the Texts tab. You will often wish to make some secondary use of data extracted from a web source beyond the uses that the toolkit makes on its own; turning on this option puts you in a position to continue your work with a bit less fuss.
The following sections of this document describe this work in substantial detail.
Select the web resource of interest from the drop-down list at the top of the tab. (You can use an option to set the default selection in this list to the resource you use most often.) As you change the selection in this list, the toolkit displays corresponding instructions for the use of that resource. (The various sub-sections of this document give detailed instructions for working with each of the web resources listed on this tab.) If you are going to supply a complete URL to tell the toolkit where to find information, you don't actually need to select the resource from this list, because the URL tells the toolkit everything it needs to know. (When you paste a URL into the toolkit's box, it changes the selection in the list to correspond.)
If you click the Click here to launch … button just below the drop-down list of web resources, the toolkit will open the indicated resource in your default web browser.102 In the preceding illustration, you have selected Canadian geographic as the web resource; you can click the Click here to launch … button to launch the interface for Canadian geographic information in a web browser.
In the empty box near the bottom of the Web tab, you supply the information the toolkit needs to request information.
The toolkit can do a number of things with information it pulls from a web resource, depending on the resource. All of the things that the toolkit does with the data it pulls from an external resource are under your control. The kinds of things that are possible vary somewhat with the web site; of the available possibilities, you can choose whichever action or actions seem to you to be the most suitable.
As you change the selection in the drop-down list on the Web tab, the toolkit changes the display in the central part of the tab to show the possibilities available for that service.
The following illustration shows the work areas available for id.loc.gov, which has the maximum number of possibilities. For other web sources, the toolkit may present fewer possibilities. | |
![]() |