|
|
| (9 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | == 2.1 Introduction ==
| |
| − | === Overview ===
| |
| | MARS 2.0 makes changes in over 100 different MARC fields within your bibliographic record. Our ''Bibliographic Record Validation'' service updates many elements in MARC bibliographic records to conform with current MARC21 standards, providing increased consistency within your bibliographic files. | | MARS 2.0 makes changes in over 100 different MARC fields within your bibliographic record. Our ''Bibliographic Record Validation'' service updates many elements in MARC bibliographic records to conform with current MARC21 standards, providing increased consistency within your bibliographic files. |
| | | | |
| Line 10: |
Line 8: |
| | | | |
| | == Topics == | | == Topics == |
| − | Chapter three is one of our most comprehensive documents, and as such is too large for a single page. | + | Chapter two is one of our most comprehensive documents, and as such is too large for a single page. |
| | * [[Profile Guide Step 2.1|Step 2-1]] - MARC Update Service Levels | | * [[Profile Guide Step 2.1|Step 2-1]] - MARC Update Service Levels |
| − | * [[Profile Guide Step 2.2|Step 2-2]] - Normalization of Generic Name Headings | + | * [[Profile Guide Step 2.2|Step 2-2]] - Numeric Field Validation |
| | + | * [[Profile Guide Step 2.3|Step 2-3]] - Leader and Fixed Field Updates |
| | + | * [[Profile Guide Step 2.4|Step 2-4]] - Tag Updates and Field Deletes |
| | + | * [[Profile Guide Step 2.5|Step 2-5]] - Subfield Code Updates and Deletes |
| | + | * [[Profile Guide Step 2.6|Step 2-6]] - Indicator Updates |
| | + | * [[Profile Guide Step 2.7|Step 2-7]] - Special MARC21 Field Conversions and Additions |
| | + | * [[Profile Guide Step 2.8|Step 2-8]] - Initial Article and Filing Indicator Validation |
| | + | * [[Profile Guide Step 2.9|Step 2-9]] - GMD Standardization |
| | | | |
| − | | + | [[category:Profile Guide]] |
| − |
| + | |
| − | | + | |
| − | == Step 2.2 Question ==
| + | |
| − | [[Image:2-2.png]]<br> | + | |
| − | | + | |
| − | === Numeric Field Validation ===
| + | |
| − | MARC fields that are incorrectly formatted often cause user searches to fail and prevent items in the collection from being included in the system indexes. MARS 2.0 software can validate the structure of numeric data in the following fields:<ul><li>010: Library of Congress Control Number (LCCN)<li>020: International Standard Book Number (ISBN)<li>022: International Standard Serial Number (ISSN)<li>034: Coded Cartographic Mathematic Data (CCMD)</ul>
| + | |
| − | | + | |
| − | === Historical Fact ===
| + | |
| − | LC changed the structure of the LCCN beginning on Jan. 1, 2001 in order to accommodate a four-digit year. The length of the control number remains 12 characters as it was prior to the change. However, in the old LCCN structure (A), suffixes were occasionally used. Under the new LCCN structure (B), the location of elements is slightly altered to accommodate a four-digit year. Under both structures, the prefix, year and serial number are the basic elements required to make a LCCN unique.
| + | |
| − | | + | |
| − | Please indicate on Step 2.2 what kind of validation you would like performed on your 010, 020, 022 or 034 fields. Choosing “Yes, With these modifications” means that you would like the MARS 2.0 software to perform a modified validation (e.g., validate fields 020 and 022, but not fields 010 or 034).
| + | |
| − | | + | |
| − | === Pre-2001 LCCN ===
| + | |
| − | LCCN Structure A (2000 and earlier) numbers are formatted according to the following 6 divisions (separated by hyphens):<br>
| + | |
| − | [[Image:Pre2001lccn.png]]
| + | |
| − | | + | |
| − | <ol><li>3-character prefix with lowercase letters and/or blanks<li>2 digits, usually the last 2 digits of the year<li>6-digit serial number, with zeroes padded to the left to make 6 digits<li>Blank space<li>Optional variable length suffix and/or alphabetic identifier<li>Optional revision date</ol><br>
| + | |
| − | | + | |
| − | Examples of LCCN Structure A (the character # represents a single space):<br>
| + | |
| − | [[Image:pre2001lccn2.png]]<br>
| + | |
| − |
| + | |
| − | == 2.2 Numeric Field Validation ==
| + | |
| − | === Post-2000 LCCN ===
| + | |
| − | LCCN Structure B (2001 and later) numbers are formatted according the following 3 divisions (separated by hyphens):<br>
| + | |
| − | [[Image:Pst2001lccn.png]]
| + | |
| − | | + | |
| − | <ol><li>2-character prefix with lowercase letters and/or blanks<li>4-digit year<li>6-digit serial number, with zeroes padded to the left to make 6 digits</ol><br>
| + | |
| − | | + | |
| − | Examples of LCCN Structure B (the character # represents a single space):<br>
| + | |
| − | [[Image:Pst2001lccn2.png]]<br>
| + | |
| − | | + | |
| − | According to the Library of Congress, Structure A LCCNs will not be changed to Structure B. This minimizes the impact of the LCCN change for local systems. Since LCCN structures A and B will continue to exist in authority and bibliographic records, MARS 2.0 programs provide for validation of both old and new LCCN formats. No provision is necessary, therefore, for the conversion of Structure A to the new Structure B formats, or vice versa.
| + | |
| − | | + | |
| − | === LCCN Structure A Corrections ===
| + | |
| − | If the LCCN in the 010 $a is identified as a Structure A LCCN and does not have a valid structure, MARS 2.0 programs make the following format corrections (all changes are subsequently checked for validity):<ul><li>If the first character of the LCCN is a number (no prefix is present), the programs insert 3 blanks (###) before the number:<br><font color="red">95-156543</font><br><font color="blue">###95156543#</font><br><li>If the first character of the LCCN is an alphabetic character and the second character is a number, MARS 2.0 programs insert 2 blanks (##) between the alphabetic character and the number to make a valid 3-character prefix:<br><font color="red">n95-156543</font><br><font color="blue">n##95156543#</font><br><li>If the first 2 characters of the LCCN are alphabetic and the third character is a number, MARS 2.0 programs insert 1 blank (#) between the alphabetic characters and the number to make a valid 3-character prefix:<br><font color="red">nb95-156543</font><br><font color="blue">nb#95156543#</font><br><li>If a hyphen appears in the 010 subfield $a, MARS 2.0 programs count the number of digits before the hyphen. If one digit is before the hyphen, a 0 (zero) is inserted before the first digit in the LCCN (following the prefix). If 2 digits are before the hyphen, no zeroes are inserted at the beginning of the LCCN:<br><font color="red">nb#9-156543</font><br><font color="blue">nb#09156543#</font><br><font color="red">nb#95-156543</font><br><font color="blue">nb#95156543#</font><br><li>MARS 2.0 programs also count the number of digits following the hyphen. If there are fewer than 6 digits, zeroes are added following the first 2 digits (##-) of the LCCN to make 6 digits (for a total of 8 digits). The hyphen is deleted from the LCCN:<br><font color="red">nb#95-6543</font><br><font color="blue">nb#95006543#</font><br><font color="red">nb#95-56543</font><br><font color="blue">nb#95056543#</font><br><li>If the LCCN contains a suffix, the suffix is removed in accordance with the revised LC standard for Structure A LCCNs:<br><font color="red">nb#95-516543//r86</font><br><font color="blue">nb#95156543#</font><br><li>If the LCCN does not end with a blank, MARS 2.0 programs insert a blank following the last digit:<br><font color="red">nb#95-516543</font><br><font color="blue">nb#95156543#</font><br><li>If the 010 field data has been modified, the 010 field length is recalculated and the 010 directory entry is updated. The record length is recalculated and updated in the record leader.<li>If MARS 2.0 programs cannot correct the format of the LCCN in the 010 subfield $a (e.g., there are 4 characters in the prefix or there are 9 digits), the 010 subfield $a code is changed to $z and a report can be generated. See report R50 on page 5:25 for more information about this report.<li>The following invalid LCCN prefixes are corrected to the valid format (# = blank):<ul><li>#a# -> a##<li>##a -> a##<li>#bc -> bc#<li>## -> ###<li># -> ###</ul></ul>
| + | |
| − | | + | |
| − | === LCCN Structure B Corrections ===
| + | |
| − | If the LCCN in the 010 subfield $a is identified as a Structure B LCCN and does not have a valid structure, MARS 2.0 programs attempt to correct it by making these conversions (all changes are subsequently checked for validity):<ul><li>If the first character of the LCCN is a number (no prefix is present), the programs insert 2 blanks before the number:<br><font color="red">2005-256543</font><br><font color="blue">##2005256543</font><li>If the first character of the LCCN is an alphabetic character and the second character is a number, MARS 2.0 programs insert 1 blank (#) between the alphabetic character and the number to make a valid 2-character prefix:<br><font color="red">n2005-256543</font><br><font color="blue">n#2005256543</font><br><font color="red">nb2005-256543</font><br><font color="blue">nb2005256543</font><li>If a hyphen or blank space appears in the 010 subfield #a, MARS 2.0 programs count the number of digits following the hyphen. If there are fewer than 6 digits, zeroes are added following the first 4 digits (####-) of the LCCN to make 6 digits (for a total of 10 digits). The hyphen is deleted from the LCCN:<br><font color="red">nb2005-6543</font><br><font color="blue">nb2005006543</font><li>If the 010 field data has been modified, the 010 field length is recalculated and the 010 directory entry is updated. The record length is recalculated and updated in the record leader.<li>If MARS 2.0 programs cannot correct the format of the LCCN in the 010 subfield $a (e.g., there are 4 characters in the prefix or there are 9 digits), the 010 subfield $a code is changed to $z and a report can be generated. See report R50 in Step 5 for more information about this report.<li>The following invalid LCCN prefixes are corrected to the valid format (# = blank):<ul><li>#bc -> bc<li>#a -> a#<li># -> ##</ul></ul>
| + | |
| − | | + | |
| − | === 020 Field ===
| + | |
| − | Some automated systems do not index an ISBN if the format is invalid. An ISBN in field 020 subfield $a should be 10 digits or 13 digits. If the ISBN in 020 subfield $a does not have the valid structure, MARS 2.0 programs attempt to correct the ISBN structure by performing the following conversions:<ul><li>If there are 9 digits in the ISBN, a 0 (zero) is inserted before the first digit in the ISBN:<br>
| + | |
| − | <font color="red">873671008</font><br><font color="blue">0873671008</font>
| + | |
| − | <li>All hyphens are deleted:<br>
| + | |
| − | <font color="red">1-873671-008</font><br><font color="blue">1873671008</font>
| + | |
| − | <li>A lowercase x is converted to uppercase:<br>
| + | |
| − | <font color="red">187367100x</font><br><font color="blue">187367100X</font>
| + | |
| − | <li>If ISBN is 13 digits, MARS 2.0 programs will verify that the first 3 digits are 978.<li>As an optional service, MARS 2.0 programs will correct the order of the ISBN (i.e. pairs of 13/10 and 13/10)
| + | |
| − | <li>As an optional service, MARS 2.0 programs will convert ISBN-10 to ISBN-13 (includes check-sum value for both 10 and 13 length ISBNs):<br>
| + | |
| − | <font color="red">1873671008</font><br><font color="blue">9781873671000</font>
| + | |
| − | <li>If MARS 2.0 programs cannot correct the format of the ISBN in the 020 subfield $a (e.g., there are 11 digits), the 020 subfield $a code is changed to $z and a report is generated. See report R50 in Step 5 for more information about this report.</ul>
| + | |
| − | | + | |
| − | === Historical Fact ===
| + | |
| − | The structure of the ISBN has changed over the past thirty years. Prior to 1977, the 020 field was not repeatable and multiple ISBNs and related information were placed in repeated subfields. Older bibliographic records may still have multiple ISBNs in a single 020 field rather than in multiple 020 fields. January 1, 2007 marked the final date for fully adopting ISBN-13. Between 2005 and 2008, publishers were encouraged to supply both an ISBN-10 and an ISBN-13 for the same manifestation, based on guidelines issued by the International ISBN Agency (IIA). The Library of Congress began accommodating ISBN-13 on October 1, 2004. At the beginning of 2007 is when publishers were expected to supply only ISBN-13.
| + | |
| − |
| + | |
| − | === Ordering 020 Fields ===
| + | |
| − | LC will accept both an ISBN-13 and an ISBN-10 for the same manifestation. These numbers are shown by publishers according to guidelines issued by the IIA, which call for grouping the pairs of ISBNs by manifestation. In printed products the ISBN-13 appears first, and each number is preceded by a print constant as in the following example:<br>
| + | |
| − | ISBN-13: 978-1-873671-00-0<br>
| + | |
| − | ISBN-10: 1-873671-008<br>
| + | |
| − | | + | |
| − | === Repeating 020 Subfields ===
| + | |
| − | MARS 2.0 Update processing validates an 020 field for correct subfield repeatability. If the 020 field contains multiple subfields $a, each subfield $a is placed in a separate 020 field:<br>
| + | |
| − | 020 $a11111111$a22222222<br>
| + | |
| − | Corrected to:<br>
| + | |
| − | 020 $a11111111<br>
| + | |
| − | 020 $a22222222<br>
| + | |
| − | | + | |
| − | === Binding Information in 020 Fields ===
| + | |
| − | Prior to 1978, binding information was placed in a subfield $b. Older bibliographic records may have binding information in a subfield $b rather than as a parenthetical qualifier in the subfield $a.
| + | |
| − | | + | |
| − | If the 020 field contains a subfield $b and an 020 subfield $a exists:<ul><li>Subfield $b delimiter and subfield code are deleted<li>020 subfield $b data is enclosed in parentheses<li>A blank is inserted at the end of the immediately preceding 020 subfield $a data<li>020 subfield $b data, enclosed in parentheses, is moved after the blank at the end of the 020 subfield $a data<br>Original: 020 $a1873671008$bpbk. Corrected to: 020 $a1873671008 (pbk.)</ul>
| + | |
| − | | + | |
| − | === No Subfield $a in 020 Field ===
| + | |
| − | If the 020 field contains a subfield $b and no 020 subfield $a exists, the subfield $b code will be changed to $c:<br>
| + | |
| − | 020 $bpbk.<br>
| + | |
| − | Corrected to:<br>
| + | |
| − | 020 $cpbk.<br>
| + | |
| − | | + | |
| − | === Multiple Subfields $c in 020 Field ===
| + | |
| − | If the 020 field contains multiple subfields $c, each subfield $c is placed in a separate 020 field:<br>
| + | |
| − | 020 $c4.95 (lib. bdg.)$c3.60 (pbk.)<br>
| + | |
| − | Corrected to:<br>
| + | |
| − | 020 $c4.95 (lib. bdg.)<br>
| + | |
| − | 020 $c3.60 (pbk.)<br>
| + | |
| − |
| + | |
| − | === Multiple Subfields $a and $c in 020 Field ===
| + | |
| − | MARS 2.0 programs correctly handle 020 fields with multiple subfields $a and $c:<br>
| + | |
| − | 020 $a11111111$c4.95$a22222222$c3.60$c8.97$bpbk.<br>
| + | |
| − | Corrected to:<br>
| + | |
| − | 020 $a11111111$c4.95<br>
| + | |
| − | 020 $a22222222$c3.60<br>
| + | |
| − | 020 $c8.97 (pbk.)<br>
| + | |
| − | | + | |
| − | === 022 Field ===
| + | |
| − | MARS 2.0 Update processing can validated the format of the ISSN in field 022 subfield $a. Some automated systems do not index an ISSN if the format is invalid. A valid ISSN in field 022 subfield $a has the following structure: 4 digits, hyphen, 4 digits (or digits and an X):<br>
| + | |
| − | 1234-1234<br>
| + | |
| − | 1234-123X<br>
| + | |
| − | | + | |
| − | If the ISSN in field 022 subfield $a does not have the valid structure, MARS 2.0 programs attempt to correct it by making these conversions:<ul><li>If the ISSN has no hyphen, adds a hyphen between the fourth and fifth digits:<br>
| + | |
| − | <font color="red">12345678</font><br><font color="blue">1234-5678</font>
| + | |
| − | <li>Converts a lowercase x to uppercase:<br>
| + | |
| − | <font color="red">1234-567x</font><br><font color="blue">1234-567X</font>
| + | |
| − | <li>If MARS 2.0 programs cannot correct the format of the ISSN in the 022 subfield $a (e.g., there are 9 digits), the 022 subfield $a code is changed to $y and a report is generated. See report R50 in Step 5 for more information about this report.</ul>
| + | |
| − | | + | |
| − | === 034 Field ===
| + | |
| − | MARS 2.0 Update processing can validate field 034 CMD (Coded Mathematical Data) for correct format. If the 034 field first indicator has value 2 and the 034 field contains multiple subfields $a, MARS 2.0 Update processing:<ul><li>Places each subfield $a in a separate 034 field<li>Changes each 034 field first indicator to value 1<br>
| + | |
| − | 034 2_$aa$b100000$aa$b120000<br>
| + | |
| − | Corrected to:<br>
| + | |
| − | 034 1_$aa$b100000<br>
| + | |
| − | 034 1_$aa$b120000</ul>
| + | |
| − | | + | |
| − | === Historical Fact ===
| + | |
| − | First indicator value 2 became obsolete when field 034 was made repeatable in 1982. Older bibliographic records may still have first indicator value 2.
| + | |
| − |
| + | |
| − | == Step 2.3 Question ==
| + | |
| − | [[Image:2-3.png]]<br>
| + | |
| − | | + | |
| − | === Leader & Fixed Field Updates ===
| + | |
| − | MARS 2.0 Update processing provides a variety of updates and corrections to values in the Leader and fixed fields (006, 007, 008). Indicate whether or not to perform Leader & Fixed Field updates.
| + | |
| − | | + | |
| − | You may also elect to modify the standard fixed field updates by making a copy of the fixed field update chart, describing desired changes and returning a copy of the edited chart with your profiles.
| + | |
| − | | + | |
| − | Fixed Field Updates
| + | |
| − | Changes to MARC21 replaced many fixed field values or made them obsolete. In the leader, for example, the value p designating a “Record in partial ISBD form” in byte 18, Descriptive Cataloging Form, was made obsolete in 1987 and is now coded using value I (ISBD). MARS 2.0 Update converts an h value in Leader byte 18 to i.
| + | |
| − | | + | |
| − | Bytes 18 (Frequency) and 19 (Regularity) in the 008 fixed field for Computer files/Electronic resources format materials were made obsolete in 1995. Additionally, 008 bytes 18-19 are undefined (should not be used) for Mixed materials format. The MARS 2.0 Update software, therefore, converts any values in 008 bytes 18-19 to blanks for Computer files/Electronic resources and Mixed materials records.
| + | |
| − | | + | |
| − | MARS 2.0 Leader & Fixed Field Updates Table
| + | |
| − | In the following table, byte position is counted with the first byte being “00” (zero) to be consistent with MARC21 Bibliographic Format documentation. The table uses the following symbols:<br>
| + | |
| − | # = blank space<br>
| + | |
| − | | = fill character<br>
| + | |
| − | | + | |
| − | Format codes are as follows:<br>
| + | |
| − | BK = Books<br>
| + | |
| − | CF = Computer files/Electronic resources<br>
| + | |
| − | MP = Maps<br>
| + | |
| − | MU = Music<br>
| + | |
| − | CR = Continuing resources (serials, etc.)<br>
| + | |
| − | VM = Visual materials<br>
| + | |
| − | MX = Mixed materials (includes obsolete Archival and Manuscripts control)<br>
| + | |
MARS 2.0 makes changes in over 100 different MARC fields within your bibliographic record. Our Bibliographic Record Validation service updates many elements in MARC bibliographic records to conform with current MARC21 standards, providing increased consistency within your bibliographic files.
The level of MARC update is entirely configurable by you and your staff. By default, we perform all of the updates to your MARC bib records. Or, if you prefer, we can only perform the updates you specify. In the end, the update process is tailored to your expectations of what you’d like to see happen within your bibliographic records.
As soon as we receive your files, they are prepared for processing. The MARS 2.0 programs check all files of MARC records submitted to ensure they conform to the basic structural requirements of the MARC21 communications format. Our validation programs ensure that all records meet the following criteria:
Chapter two is one of our most comprehensive documents, and as such is too large for a single page.
