Voyager 5.0: Cataloging Checklist

1/06. Roll-out problems. Hierarchy colors -- Diacritic in initial article/Undercounting Effect on Title Search -- Fixed Fields -- Redirect problems.

CONTENTS: 1. Local Import Character Set. Troubleshooting. LCDB. When Utilities Enable Export of UTF-8. Copy/Paste -- 2. Fonts -- 3. Conversion View -- 4. Diacritics/Special Characters 4a. Diacritics. 4b. Non-diacritic (special character) 4c. Complex diacritics. 4d. Special Character Entry Window. 4e. Diacritic/ Special Character Macros: on Keypad & Popup Pad. 4f. Overtyping: Unintentional and Intentional. 4g. Nonfiling indicators. 4h. Diacritics/Special Characters in the OPAC -- 5. Records with non-roman fields (880) 5a. Editing Guidelines. 5b. Exporting Guidelines. -- 6. Fixed Fields -- 7. Validation Preferences and Settings -- 8. Macro Express -- 9. Miscellaneous and Bugs. 9a. Alternate Key Sequences. 9b. Redirect. 9c. MFHD Keyword Searching. 9d. Keyword/Index Selection. 9e. Simultaneous Searching. 9f. Authorities, Diacritics, & LCDB. -- REPORTING PROBLEMS

Cataloging staff are scheduled to begin working in the Voyager 5.0 upgrade Jan. 3 2005. The upgrade will incorporate the conversion of the Orbis database to Unicode. Most of the items in this checklist affecting cataloging will involve adjustments to working in the Unicode environment.

1. Local Import character set

Local Import character set for bibliographic records exported from OCLC or RLIN must be MARC21 MARC8 (non-unicode).

MARC21 MARC-8 will be the default setting when Voyager 5.0 is pushed out. Although the RLIN21 and OCLC databases are Unicode compliant, the export function converts the records to MARC21 MARC-8 (non-unicode) because most ILS's have not yet converted to Unicode. The Local Import MARC21 MACR-8 (non-unicode) character set applies to records exported from either OCLC or RLIN21.

DO NOT USE: MARC21 UTF-8, OCLC (non-unicode), RLIN legacy (non-unicode), Voyager legacy (non-unicode), or Latin-1 (non-unicode).

DO NOT USE the Open RLIN Import File or Open OCLC Import File macros in the old Macro Express master1.2N.mex or master1.2D.mex files in Voyager 5.0. These macros were set up to work in Voyager 2.1 and will fail or re-set to the wrong character set in Voyager 5.0. Once Voyager 5.0 is installed, you should be using the master2D.mex or master2N.mex files, which include updated Open RLIN Import File and Open OCLC Import File macros.

--What happens if I use the wrong setting?

When you open the import file and view the record, some of the special characters may be replaced by substitute characters. If that happens, close the record and re-set the Local Import character setting to MARC21 MARC8 (unicode). When you open the import file again and view the record, the special characters should display and you can then save the record to Orbis. However, if you failed to re-set the Local Import and saved the unrefreshed import record with the substitute characters into Orbis, you should re-set Local Import to MARC21 MARC8 (unicode), re-export the record from the utility, and overlay the Orbis record with the re-exported record from the utility.

If the wrong character setting was selected and the special characters aren't affected, or the record simply had no special characters, assume the Voyager conversion program was able to cope. (But re-set Local Import nevertheless)

Although the MARC21 MARC8 (non-unicode) character setting should handle records exported from the utilities, those staff who save records from LCDB or Orbis to a workfile will not be able to open the record for editing when the Local Import is set at MARC21 MARC8 (non-unicode). (The practice of saving records to a workfile on the harddrive is limited primarily to Beinecke manuscript cataloging staff; the practice is not generally recommended.) When this setting is in place, Voyager will display this message when staff try to open the record; the record itself will not open.

The solution is to change the Local Import setting to MARC21 UTF-8 and then re-open the record.

The "record skipped" message above should only occur when staff attempt to open a UTF-8 record when the Local Import is set for a non-UTF-8 character set, i.e. MARC21 MARC8 (unicode). However, in some cases, staff may need to import bibliographic files that did not originate in Orbis, LCDB, or the bibliographic utilities. These records may be non-UTF-8 but also not MARC21 MARC8 (e.g. vendor records?). When this situation occurs, and if the Local Import is set at MARC21 MARC8 (non-unicode), Voyager will display the following message (# may vary):

The solution is to change the Local Import setting to match the character set of the file to be imported, e.g. to Latin1 (non-unicode), and then re-open the workfile to refresh it.

--Does the character setting affect records exported from LCDB?

No. Records in LCDB are UTF-8, the same character set as records in Orbis; a record saved into Orbis from LCDB is not processed as an import by Voyager. (Unless, exceptionally, the LCDB record was first saved as a workfile to the cataloger's harddrive; see above)

--What happens when the utilities enable exporting in UTF-8?

Continue to use the MARC21 MARC8 (non-unicode) character set until export/import settings have been coordinated department-wide.

--Can I use the copy/paste function to copy text from the bibliographic utilities to Orbis and vice versa?

a. There appears to be no problem copying text from RLIN and pasting into Orbis; neither diacritics/special characters nor delimiters appear to be affected.

b. Voyager does not recognize delimiters in text copied from OCLC; no other special characters appear to be affected.

c. There appears to be no problem copying text from Orbis and pasting into RLIN editing fields. Text with diacritics/special characters may be copied into the search slots for RLIN or OCLC as is; the diacritics/special characters may be converted to other characters, but the search itself is not affected by the conversion.

d. With the exception of delimiters, text with special characters can be copied from an Orbis record and pasted into an Orbis search window without further editing. Vietnamese corporate name example:

 

2. Fonts

Under the Colors/Fonts tab, Font must be set to Arial Unicode MS. Please do not customize on your workstation! Currently, Endeavor is only supporting Arial Unicode MS, which means that other fonts may not display characters as intended in the OPAC or in the staff module.

 

NEW (1/09/06) Display colors of the Hierarchy view in the Cataloging client.   Even if staff have their preferences for this view set to black background, it has been appearing with a white background for several staff.  What's odd is that when you look at your preferences, it appears that Black is correctly set.

The problem has been reported to Endeavor as a bug. Immediate resolution not expected. In the meantime if staff find the white background difficult to read or confusing, you can select any other color, or define a custom color of black, add it to your custom colors.  

3. Conversion View

In the same Colors/Fonts window above, the new Conversion view Text/Background color scheme should never match the Bibliographic view color scheme. The default setting for the Conversion view is red text on white background. The Conversion view displays when the Unicode conversion encountered a problem character. There are about 600+ records that have had conversion problems. In the example (Orbis bib id 486324), note that the problem characters are identified by a question-mark symbol in fields 310 and 321. If you encounter a conversion problem record, fix the problem if you can identify it and save the record to Orbis. Until the record is saved, only the Orbis ID number is indexed in the record. However, note that the limited indexing of the Conversion record applies only to the bibliographic record; the call number and barcode are indexed and searchable in the Staff Cataloging Module (the record cannot be retrieved by call number in the OPAC). After the record is saved, the color scheme will change to match the Bibliographic color scheme.

NOTE: Catalog Management will update these records systematically as a project in 2006.

NOTE: most of the Conversion problem records involve non-roman fields. See 5. Non-roman fields below for editing guidelines.

4. Diacritics and Special Characters

We recommend that catalogers who enter diacritics and special characters in Orbis check each other's work initially and/or view the finished cataloging record in the OPAC, preferably using a larger font size. For OPAC adjustments, see 4h. below.

4a. DIACRITIC ENTRY. A diacritic character must be entered after the letter that the diacritic modifies. When a diacritic is entered, it will display above or below the letter, whichever is appropriate.

Type: Grass, Gu<umlaut>nter

Orbis will display as: Grass, Günter

Type: come<acute>dien

Orbis will display as: comédien

4b. A NON-DIACRITIC CHARACTER is entered before the letter it modifies and should display before the letter as input.

Type: H<dot below>ada<macron><alif>iq

Note that the dot below and the macron are supposed to display below and above their modified letters respectively, so they are entered after the letters they modify. But the alif is supposed to display separately from, and before, the letter that follows it, so it must be entered before that letter.

Orbis will display as: Ḥadāʾiq

4c. COMPLEX DIACRITICS.

Ligatures are diacritics, but don't display above/below the record they modify (at least in Voyager). The left ligature is entered after the first letter modified, the right ligature is entered after the second letter modified.

Type: Sot<ligature left>s<ligature right>ializm Belinskogo : ‡b stat<miagkii znak>i i pis<miagkii znak>ma

Orbis will display as: Sot︠s︡ializm Belinskogo : ‡b statʹi i pisʹma

Multiple diacritics modifying the same letter. In the following Vietnamese example, two diacritics in different positions modify the same letter. Although the diacritics must be entered after the letter modified, the order in which the two diacritics are entered when they follow the letter does not appear to have any effect on the letter display.

Type: nie<circumflex><dot below>m

Or type : nie<dot below><circumflex>m

Orbis will display as: niệm

For overtyping situations, refer to 4f. below.

--How do I know whether the character is entered as a diacritic or as a non-diacritic character?

If the character is in a heading, copy the heading from the authority record. If the character is elsewhere, find other cataloged records that use the same word, or check with someone who knows the language.

4d.The Voyager SPECIAL CHARACTER ENTRY WINDOW has been greatly improved.

 

Diacritics and non-diacritic characters are now assigned the standard ALA character set labels and are arranged alphabetically by label. The character itself displays to the left of the label in the Text Insert column. To insert a character:

• in the bibliographic record, position the cursor where the character should be entered
• open the Special Character Entry window (ctrl + e) or (using the menu) Edit-->Special Character Entry
• scroll through the list of special characters until you find the required character
• select (click on) the character line needed
• click on the Insert/Close button.

--What is the Key Press column used for?

The characters listed in the Key Press column represent the key you can press when the keyboard is shifted into Special Character Mode.

To enter a character without using the Special Character Entry window:

• press ctrl+d (or, click to open the Edit menu and then click Special Character Mode)
• press the Key Press key that corresponds to your special character
• press ctrl+d again (or, click to open the Edit menu and then click Special Character Mode)

4e. MACRO EXPRESS. Special character macros are still mapped to the keypad (number pad) and the keyboard, and are also available through the Diacritic Pop-up Pad. The Macro Express file MASTER2D.mex must be open in order to run any of these functions. See also 7. Macro Express below.

The keypad (number pad) map is at:

http://www.library.yale.edu/cataloging/macroexpress/keypadmapOrbis.doc

The diacritic/special character Macro Express map is at:

http://www.library.yale.edu/cataloging/macroexpress/diacriticsvoy.htm

The pop-up diacritic/special character menu is assigned as a default to F12 but is not enabled. To enable the pop-up menu, locate the Pop-up keypad Diacritics (Popup Menu: F12) line in the Diacritics folder. Select the line and right-click to open the menu of options. Click the Enable macro option. To enter a diacritic or special character, position the cursor after (or, for some special characters, before) the letter to be modified, and press F12. This window will appear:

Be sure the window is activated (title bar is blue, not gray; click on the title bar if gray). Either double-click on the appropriate character or press the number/letter to the left of the character label. The window will close automatically and the character will be inserted.

4f. OVERTYPING. CAUTION. Pre-Unicode data entry for special characters moved the cursor to the next space after the character was entered. In Unicode data entry, the cursor remains in the same position after the character has been entered until a letter (as opposed to a special character) is typed. As a result, it is very easy to overtype a special character, sometimes multiple times, if you are not paying attention.* To undo an overtyped character, use the backspace key until the original character is restored.

Overtyped character: Genê̌t <hacek typed over circumflex>

To correct, place the cursor after the modified letter and backspace (in this case) once: Genêt

In some languages, overtyping of diacritics is normal; Voyager is set up to display overtypes of this kind correctly. In Vietnamese, a common name would be typed in as:

Nguye<circumflex><tilde>n

or

Nguye<tilde><circumflex>n

Orbis will display as: Nguyẽ̂n

4g. NONFILING INDICATORS. National practice for counting nonfiling indicators that is consistent with Unicode practice has actually been in place since 2003. However, in Voyager 2.1 use of the obsolete nonfiling indicator practice (where a diacritic modifying the first letter of the first word in a title was counted) did not affect retrieval. In Voyager 5.0, unless the current nonfiling indicator practice is followed, the title will not be retrieved.

Local policies and procedures (effective May 2003):

http://www.library.yale.edu/cataloging/Orbis2Manual/nonfilingindic.htm

PCC examples :

http://www.loc.gov/catdir/pcc/bibco/nonfile.html

The Unicode conversion changed the position of all diacritics but did not change the nonfiling indicator for records cataloged using the pre2003 rules. Also, it may be the case that some records cataloged after 2003 did not follow the rule change. If a title has an initial article with a diacritic on the first letter following the article, and the record is not retrieved on a title search, try re-searching the title with the first letter dropped, i.e. "criture" instead of "ecriture;" "ltimos" instead of "ultimos." As encountered, correct any nonfiling indicators that follow the pre2003 rules.

NEW (1/09/06): A diacritic in an initial article must be counted for the nonfiling indicator. (This rule in fact did not change in 2003) Example:

245

0

4

‡a Hē Kainē Diathēkē ...

However, it appears that, at least for the Greek Hē , undercounting the nonfiling indicator (e.g. 3 instead of 4) prevents the entire title from indexing for left-anchor searches . (The title can still be retrieved with OPAC keyword searching; keyword searching in the Cataloging Module has been less successful.)

It is possible that the Voyager indexing alogorithms may be using the nonfiling indicator numerical value as a byte count rather than a character count for non-roman articles. The Hebrew article "ha" is one character but is constructed with 2 bytes. The nonfiling indicator 1 should cause the search to skip past the article if the article is read properly as a character, but the title search will only work with a filing indicator of 2. Princeton reports similar problems with Arabic. (Since this is a bug--the nonfiling indicator works properly in RLIN--staff should not adjust the indicator to accommodate the Voyager 5.0 limitation.)

 

4h. Viewing special characters in the OPAC. So far, it appears that Firefox is able to handle all Unicode characters. Internet Explorer (IE) may require some tweaking. If diacritics, special characters, or non-roman characters are not displaying correctly on IE, be sure that

• the Web font (accessed via the menu Tools-->Internet Options-->Fonts) is set to Arial Unicode MS
• Auto-select (accessed via the menu View-->Encoding) is unchecked
• Encoding is set to UTF-8

Clicking the refresh button on IE should restore the special characters if all of the above are not effective.

Detailed instructions for adjusting your browser will be found under the OPAC Help tab.

To increase font size, on IE or Firefox, go to the menu View-->Text size--><select larger size>, or, if your mouse has a scroll button, hold down the ctrl key and play with the scroll button to get the best size.

5. Records with non-roman fields (880)

5a. 880 fields will now display the vernacular scripts (some fields omitted for reasons of space)

Staff in roman script units should edit only roman character text in UNLINKED fields, i.e., variable fields without an initial ‡6 subfield. An example of an unlinked field that should be edited by roman script units is the 650 Shinto field highlighted in the example above, which has a typo in the subdivision. On the other hand, the preceding 630 field has a ‡6 subfield and would not be edited by roman script units if it had a typo. CAUTION: although it is OK to update an unlinked roman character field, never rearrange the order of the variable fields since this may have a negative effect on the OPAC display.

For any linked field requiring editing, staff in roman script units should send a report on the ORBIS Heading Change Form at:

http://www.library.yale.edu/cataloging/change_request.htm

NOTE: it is OK to use the heading report form even if the typo or other editing problem is not in a heading. For example, the form can be used to report a typo in a roman script parallel title.

Staff in non-roman and roman script units should follow standard workflow procedures when editing non-roman records following the above guidelines. Standard workflow procedure for non-roman units is to update in RLIN and re-export to Orbis (generally); standard workflow procedure for roman script units is to update in Orbis without re-exporting back to the utilities. Non-roman workflow procedures in the Voyager 5.0 environment may need to be re-examined at a later date.

Incidentally, non-roman scripts can be copied and pasted into the Orbis search window and should generally retrieve successfully. However, keep in mind that since authority records lack non-roman fields, references and authority records will not be retrieved when a Staff search is used. (TIP: remember to delete ‡b and other subfield indicators.) PS: Staff who load and know how to use the Microsoft non-roman alternate keyboards will be able to type non-roman scripts into the search window.

 

5b. Records with non-roman fields may be exported from OCLC or RLIN by roman script staff for acquisitions in-process records or for copy cataloging. Generally these will be records for items obtained by roman script acquisitions units. If the cataloging is standard level,

• Copy cataloging may be done by a roman script cataloging unit (Fastcat if LC copy is available; by a roman script cataloging unit if only member copy is found)
• The 880 fields should not be deleted from the records; editing of the roman script should follow the guidelines in 5a. However, if a linked heading requires editing, route the item to the appropriate non-roman unit for cataloging.
• If an authority record needs to be created for a heading in a linked field, route the item to the appropriate non-roman unit for cataloging
• The records should be exported to RLIN and OCLC as well as MARS. (We expect to change the profiles to allow export of records with non-roman fields to RLIN; records exported from OCLC into Orbis and then exported via ExportQ to RLIN would be assigned the LI CTYA)

If the record is not standard level, it should be routed to the appropriate non-roman unit for cataloging.

For items where the content is primarily non-roman and the roman script unit has a cooperative agreement with the non-roman cataloging unit, the roman script unit should continue to send the item to the appropriate non-roman unit for cataloging.

6. Fixed Fields [NEW 1/06]

When editing the 008 in new or existing records staff can no longer "type ahead" through drop-down lists such as those found in the Language list or Place of Publication list.

Previously, for example, in LANGUAGE staff could type in fr and French would be selected/populate the field, since French is the first language beginning with fr in the 008language list. In 5.0 only the first letter is considered, so typing fr will move the cursor to roh [Raeto-Romance], the first language under r.

The immediate work around is to type the first letter and then scroll down through that portion of the list to select the language or place of publication you need. Endeavor considers this to be a feature, not a bug, so it is unlikely to be changed.

7. Validation Preferences and Settings

Two new options have been added to the Validation window, Bypass MARC21 Character Set Validation and Bypass Decomposition of accented characters for MARC21. Do not check either option.

8. Macro Express

Macros have been updated to account for the Voyager 5.0 changes. New files (MASTER2D.MEX and MASTER2N.MEX) will be pushed out by January. At that time, you must be sure Macro Express is set to one of the new files; a number of macros in the old master1.2D.mex and master1.2N.mex files will not work in the Voyager 5.0 environment. If your work requires data entry of foreign languages, MASTER2D.MEX is strongly recommended.

Do not re-set to the 2D/2N macro files until Voyager 5.0 is loaded on your workstation; a number of the macros in the new files will not work in the Voyager 2.1 environment.

Although the new macros have been tested against Voyager 5.0, it is possible that some may not work in the new environment. If a macro does not function as expected, have your expert user take a look. If the expert user cannot resolve the problem, s/he should contact jane.gillis@yale.edu or a member of the Macro Express group listed at:

http://www.library.yale.edu/cataloging/macroexpress/macxyalehome.html

NEW. There is a new "tip of the month" for January 2006, explaining how to load the new master files and listing glitches identified in Jan. 2006 and how to fix them.

http://www.library.yale.edu/cataloging/macroexpress/macxyaletip5.html

9. Miscellaneous & Bugs

9a. ALTERNATE KEY SEQUENCES. A number of alternate key sequences have changed. For example, Save to Database and Close has changed from ctrl+z to ctrl+q. The changed key sequences may affect customized macros, so take this into consideration when diagnosing Macro Express problems. At this time, there is no master list of changed key sequences.

9b. REDIRECT. The OPAC display of a bibliographic record can be retrieved from the top window record in the Cataloging module.

Display the bibliographic record window. From the menu,

Record-->Send Record to-->Orbis OPAC

Voyager will open the OPAC in Staff Orbis and display the record in brief form.

Enabling Internet Explorer to accept Redirect:

1. In IE, open the Tools Menu and select Internet Options

2. Click on the Advanced tab.

3. Scroll down to the Security section and enable Allow Active Content to Run on Files in My Computer and Allow Software to Install Even if the Signature is Valid. Click OK.

4. When Send Record to (Orbis OPAC) is selected from the Cataloging Module Record menu, IE will open. For a brief period you may see an intervening window in IE with the legend: HTTP Status Code 303. The OPAC record should display after a few seconds.

CAUTION: Each "redirect" will open a new window in IE, so you will need to keep track of how many windows get opened.

 

9c. MFHD KEYWORD SEARCHING.

All fields in the MFHD are indexed for keyword searching. The Voyager search can be refined to search by subfield, but this will not be in place on Jan. 3. Staff should use care in entering searches that will have manageable results, e.g. a keyword search on "sml" will probably lock up your computer, but combining "sml" and "smly" and "section 13" should retrieve all MFHDs for serials in PRR Section 13 (as long as the 852 has ‡z (Section 13)). CAUTION: if you just use a boolean "sml" and "smly" and "13" you will retrieve all MFHDs with call numbers in sml and smly with 13, and lock up your computer.

9d. KEYWORD/INDEX SELECTION RADIO BUTTON. There is a new Keyword radio button in the Search by section under the Find and Browse radio buttons. It is intended to be used in conjunction with Staff searches to perform keyword searching on headings including authority records. It should be used with caution; large result sets may take several minutes to process. Selecting a Filter category to limit the search is recommended. Use quotation marks to demarcate phrases.

9e. SIMULTANEOUS SEARCHING. This has been a known problem in Voyager since 2002 and has still not been addressed with Voyager 5.0. When Orbis has more than one record for the same title, the Simultaneous Search drops one of the titles from the retrieval display when a match is found in LCDB.

For example, a search on the title Surprised by sin retrieves records for 3 different editions in Orbis when only Orbis is searched; a search on the same title in LCDB retrieves records for 3 different editions when only LCDB is searched.

However, when Simultaneous Searching is performed, the Search Status widow shows (correctly) 3 records found in Orbis and 3 records found in LCDB.

But when the Show Results button is clicked, the Titles Index displays 3 records in Orbis (Local database) but only 2 in LCDB.

9f. AUTHORITIES, DIACRITICS & LCDB . Headings with diacritics are truncated or otherwise malformed when these windows are evoked in LCDB: Dedupe and Select one or more authority records. The records themselves are not affected; headings with diacritics are not affected when these windows are evoked in the Orbis database.

REPORTING PROBLEMS

email: prodsys@mailman.yale.edu

phone: 432-5839

Orbis Problem Report Form: http://www.library.yale.edu/lso/workstation/voyagerproblemreport.htm

 

[TOC] | Cataloging at Yale | [Optional Link]

NOTE: Examples require Arial MS Unicode font to be viewed correctly on web browser.
Copyright © 2005 Yale University Library
Contact: steven.arakawa@yale.edu
Last updated: < 13-Jan-2006 10:19 AM -->
URL:http://www.library.yale.edu/cataloging/Orbis2Manual/unicodechecklist.htm