MARCMaker and MARCBreaker User's Guide

MARCMaker and MARCBreaker User's Manual

[May 1, 2001; revised November 2007]

Table of Contents

General Introduction

This manual was written for anyone who would like to create basic MARC bibliographic records for library materials without having to use a MARC-based system. It describes the basic MARC data elements that should be in a record and provides information about some of the available tools used to create MARC records. Many of these tools are available online free of charge.

MARC is a widely used but not always well understood standard developed by libraries for the exchange of library information, especially cataloging data. The term MARC is an abbreviation for MAchine Readable Cataloging. Officially, it is an international standard that is sometimes identified by its ISO (International Standards Organization) number: 2709. ISO 2709 is a somewhat complex standard for bibliographic description that this manual does not attempt to describe. However, even though the ISO 2709 standard should be used when exchanging files of MARC data, it is not necessary to have a deep understanding of it to successfully create good MARC records.

MARC 21 is the oldest and most widely used implementation of ISO 2709. MARC 21 was originally called simply MARC. Its development in 1968 led to the development of ISO 2709, which is how the two came to be synonymous. Until 1998, MARC 21 was known as USMARC or CANMARC--names used to distinguish between slight regional variants. Following work that eliminated the differences between USMARC and CANMARC, the harmonized MARC format was renamed MARC 21. MARC 21 is used by implementers in a growing number of countries.

Many people are familiar with MARC from format documentation that presents MARC in the form of simple text. Some software programs can generate files of MARC records from text files. This manual describes how to create MARC records from a simple (proto-MARC) text format, using a free program called MARCMaker. Instructions for downloading MARCMaker and related software are also provided.

Limitations

This document was written to be used in producing basic bibliographic records that conform to the MARC 21 implementation of the ISO 2709 record structure. MARC 21 records can be much richer in data content than this guide describes. Other documentation is available that lists elements not described here. There are also other implementations of the ISO 2709 MARC record structure besides MARC 21.

Going Beyond this Guide

This guide provides information about usage of the more common data elements from the MARC 21 bibliographic format, as well as those elements that are required. The familiarity you gain in reading this guide should allow you to select and use additional MARC 21 data elements not mentioned here if you wish.

Additional documentation is available for the MARC 21 formats. Most of it is online, as is a complete list of MARC 21 data elements. You may also contact the Library of Congress for assistance in using the MARC 21 formats if the available documentation does not provide enough information.

System Requirements

The creation of MARC records using the software and processes described in this guide requires:

No other tools are needed. Some MARC users may use software such as Microsoft Access to format bibliographic information for use in MARCMaker and MARCBreaker. However, neither MARCMaker nor MARCBreaker require that the data processed comes from any particular program. What matters is that the data is formatted correctly.

What is a MARC Record?

A MARC record is a collection of textual data formatted in a way that follows the requirements of the ISO 2709 standard developed by libraries for sharing bibliographic data. Usually a separate MARC record is created for each bibliographic entity. Multiple MARC records are stored and transmitted in files. There is no limit to the number of MARC records that can be in a file. Most MARC records contain between 800 and 1,500 characters.

MARC Fields, Subfields and Indicators

Information in a MARC record is divided into fields referred to by three-digit numbers called tags. For example, the field tag for the title of a book is “245”. Most MARC fields begin with two character positions called indicators and are then usually divided into subfields that are identified either by lower-case letters of the alphabet or single digits (0 to 9). For example, the main title of a book is in subfield “a” in field 245, while the subtitle goes in subfield “b”. Because these lower-case letters of the alphabet can be confused with letters from words in the bibliographic data, a special control character called a delimiter always precedes a MARC subfield code. In this document we will use the character “$” (the dollar sign) to represent the subfield delimiter. Please note that the delimiter is not really a graphic character. Other characters may be used to represent it.

The only exception to the pattern of tag, two indicator positions, and at least one subfield code occurs in MARC fields with tags that begin with “00” (fields 000 through 009). These special fields do not have indicators or subfield codes and are usually defined as having a fixed number of character positions in them. For example, field 008 must always have 40 characters in it. Here are some examples of MARC fields.

MARC Format Data Dictionary

It is possible to have hundreds of MARC fields and thousands of MARC subfields in a record. However, not all possible combinations of three digits are used in MARC. For example, fields 440 and 490 are the only fields that begin with “4”. The MARC 21 Format for Bibliographic Data contains a list of the MARC tags and subfields (data elements) that can be used in a bibliographic record.

These data elements have been defined to describe a variety of materials, including books, periodicals, maps, sound and video recordings, software and sheet music. Some data elements are used for information that is not strictly bibliographic, for example, identifying who holds a copy of a bibliographic item. The list of possible data elements is sometimes referred to as a data dictionary because it includes a variety of elements from which to choose when constructing a MARC bibliographic record.

The MARC 21 bibliographic format is very rich, with more than 2,000 data elements defined. However, like a dictionary for a spoken language, it is not necessary to use every element. In fact, most MARC records contain only a small number of elements from the format; the average MARC record contains 30 data elements.

Cataloging Rules

An often overlooked aspect of using the MARC format is that the creation of cataloging records is usually governed by the application of cataloging rules, that can often be more complex and more difficult to master than the MARC format itself. Fortunately, much progress has been made in the development of cataloging rules since the introduction of MARC and today, MARC and cataloging rules fit together nicely. This guide incorporates some of the most basic cataloging rules that should be followed for the creation of basic MARC records.

The Anglo-American Cataloguing Rules (AACR2) have been followed in the recommendations presented in this guide as much as is possible. The current text is the Second Edition, 2002 Revision (with 2003, 2004, and 2005 updates). AACR2, like most other important cataloging rules and MARC, fully incorporates the International Standard Bibliographic Description (ISBD) conventions, developed by the International Federation of Library Associations (IFLA). Since AACR2 rules incorporate ISBD principles they are compatible with many other cataloging rules.

Inclusion of ISBD punctuation in the cataloging data placed in a bibliographic record is an important part of MARC 21 compliance. This and other aspects of good and bad MARC practices will be emphasized in this guide. It is strongly urged that you follow recommended cataloging practices when creating bibliographic data that will be shared in the MARC format.

Required Cataloging Information

In order to meet the minimum requirements of the cataloging rules that libraries follow, eighteen (18) data elements must be provided in every MARC record. These elements are listed below. The first column contains the common name of each data element. The second column contains the standard MARC content designator (tag, subfield code, etc.) used in a MARC record to identify the data element. The third column contains a code that identifies the data type. The datatypes are “A” (for alphabetic), “N” (for numeric), and “A/N” (for alphanumeric). This information might be important to those creating MARC records using certain types of software.

Many MARC data elements are variable length. The format allows up to a maximum of 9,999 characters in these fields. Since virtually no MARC user ever places this much data in a variable field, this guide suggests reasonable maximum field lengths for elements whose length can vary. The last column contains the suggested lengths. The suggested maximum lengths of these elements is based on experience with MARC records, but are not necessarily absolute. These suggested maximum lengths may be useful if you will be setting up a database from which MARC data will be taken.

Required data elements in a MARC record
Data Element Name MARC Tag Type Max Length
Record type 000/06 A 1
Bibliographic level 000/07 A/N 1
Control number 001 A/N var (12)
System identifier 003 A var (8)
Date/Time Last Transaction 005 N 16
Date of creation 008/00-05 N 6
Type of publication date 008/06 A 1
Date 1 008/07-10 N 4
Date 2 008/11-14 A/N 4
Country of publication code 008/15-17 A 3
Language of publication code 008/35-37 A 3
Cataloging Source 040$a$c A var (30)
Main title 245$a A/N var (1,000)
Place of publication 260$a A/N var (50)
Publisher 260$b A/N var (100)
Date(s) of publication 260$c A/N var (20)
Extent 300$a A/N var (50)
Size 300$c A/N var (20)

Optional Cataloging Information

The data elements above are the required minimum elements and every MARC record must include them. However, most MARC records contain more than these eighteen elements. The most common optional MARC elements are in the table that follows.

Some of these optional data elements are repeatable. Many libraries follow The Rule of Three when creating cataloging records using these. If applicable, a repeatable MARC field is repeated up to a maximum of three times. This is most commonly done for authors and subjects associated with a title. If more than three names or subjects are applicable, only the first three (or the three most important) are added.

Some of the optional fields in MARC are used for special forms of material. The type of material for which a specific field is appropriate is mentioned in the detailed description of the field.

Common optional data elements
Data Element Name MARC Tag Type Max Length
ISBN 020$az A/N 20
ISSN 022$ay A/N 20
Publisher number 028$ab A/N 50
Language codes 041$ah A/N 50
Main entry-Personal name 100$abcqd A/N 100
Main entry-Meeting name 111$andc A/N 200
Subtitle (if needed) 245$b A/N 1,000
Responsibility statement 245$c A/N 1,000
Nonprint material type 245$h A 20
Variant title 246$ia A/N 1,000
Edition number (if needed) 250$a A/N 100
Musical presentation statement 254$a A/N 100
Cartographic mathematical data 255$a A/N 100
Current publication frequency 310$a A/N 100
Dates of publication and/or sequential designation 362$a A/N 200
Series statement/ISSN/vol. number 440$axv A/N 200
General note 500$a A/N 500
Summary, etc. 520$a A/N 500
Subject-Personal name 600$abcqdx A/N 100
Subject-Corporate name 610$abx A/N 200
Subject-Meeting name 611$andcx A/N 200
Subject-Uniform title 630$ax A/N 150
Subject-Topical term 650$ax A/N 100
Subject-Geographic name 651$ax A/N 100
Added entry-Personal name 700$abcqd A/N 100
Added entry-Corporate name 710$ab A/N 200
Added entry-Meeting name 711$andc A/N 200
Local acquisitions information 923$adns A/N 200

Descriptions of Basic MARC Data Elements

The following section provides additional information about each MARC element listed in the two tables in the preceding sections. It is not enough to know what MARC field tag or subfield code to use. You must also apply cataloging rules when transcribing bibliographic information into a MARC record.

The descriptions of each MARC element below include the most important cataloging rules followed by libraries when they create MARC records. The rules explain: 1) where information is to be taken from; 2) how it should be transcribed in the MARC field; and: 3) what special punctuation is required. More detailed information about MARC data elements is available from the MARC Standards web site.

Leader and Control Fields

Leader - REQUIRED

The first two required MARC elements are both one-character codes located at positions 06 and 07 in the field called the record Leader or Field 000. This field is fixed in length: it must always contain 24 characters. (Note: Please note that these positions are counted from 00 to 23.)

Since you must only select the correct value for positions 06 and 07, the remaining 22 character positions contain specific default values which can be supplied automatically as part of the template used when a MARC record is created. Although only positions 06 and 07 in field 000 are described here, but all 24 positions are shown in the example since they must all be present in a record. If the value for any position is omitted, it changes the placement of positions which follow it.

000/06 (Record type)

The type of material represented by the MARC record is identified in field 000, position 06 (Record type). Since this value is very important, most MARC users create different templates for different types of material to control the coding of field 000. Field 000/06 may contain any of the following codes:

Values for 000/06
Code Meaning
a Language material (text)
e Cartographic material (maps, atlases)
g Projected graphic material (slides, films)
i Nonmusical sound recordings
j Musical sound recordings
k Nonprojected graphic material (photos, posters)
m Computer file (software, games, etc.)
o Kits (educational material in box)
p Mixed material (no type predominates)
r 3-dimensional material (statues, models)
t Manuscript material (letters, diaries, etc.)
000/07 (Bibliographic level)

Character position 07 in field 000 is used to indicate whether the item described in the MARC record is a monograph, serial, collection, or part of a larger item. One of the following codes must be used. The most common values used are code “m” (monograph), or code “a” (monographic component part). Code “s” is used for serials (periodicals) of any material type. Note: Titles in monographic series are coded as monographs, not serials.

Values for 000/007
Code Meaning
a Monographic component part
c Collection (created by the cataloger)
m Monograph
s Serial (periodical)

Field 001 (Control Number) - REQUIRED

Every MARC record must have a unique control number. This number is recorded in field 001. We recommend that the unique number in this field not exceed a maximum of 12 characters. Any style of number may be used. Most MARC users generate numeric control numbers, often with an alphabetic prefix that is unique to the creator of the record.

Field 003 (Control Number Identifier) - REQUIRED

Field 003 contains a MARC organization code that identifies the source of the MARC record. The Library of Congress assigns the MARC organization code (up to eight (8) alphabetic characters) for all U.S. organizations and for many in other countries. Some countries (for example, Canada, Germany, South Africa and the United Kingdom) have MARC organization code assignment agencies of their own. Since different creators of MARC records might use the same numbers in field 001, field 003 is used in conjunction with field 001 to determine uniqueness. If you do not already have an official MARC organization code, you may request one online at http://www.loc.gov/marc/organizations/. MARC codes are assigned free of change.

Field 005 (Date and Time of Latest Transaction) - REQUIRED

Field 005 contains a formatted date and time of the latest transaction (change) made in the MARC record. In new records, this is usually the date when the record was created. The data/time is always 16 characters long in the format: yyyymmddhhuuss.t where “yyyy” is the 4-digit year, “mm” is the two digit month, “dd” is the two digit day, “hh” is the two digit hour (using the 24-hour clock), “uu”is the two-digit minute, “ss” is the two-digit second, and “t” represents tenths of seconds. Many MARC users are unable to give such an exact time for the creation of the record. If you are unable to precisely identify the time, zeros can be used for unknown portions. But it is important to supply at least the year/month/day portion with something other than zeros.

Field 008 (Fixed-Length Data Elements) - REQUIRED

Field 008 contains various codes, including codes for the country and language of the publication, the date the MARC record was created, and the year(s) associated with the publication of the item. These codes are used by libraries primarily for limiting the results of a search.

Like field 000, field 008 is positionally defined, which means that the codes must be placed at particular positions in the field. Field 008 is always 40 characters in length. These positions are numbered 00 to 39. The creator of a MARC record must put some kind of code in every position.

The person creating a MARC record only needs to determine the coding for only six data elements in field 008. These elements are lsited below. Other elements may contain default values supplied in a template. Description and rules relating to the six data elements follow.

Remember, if the value for any position is omitted, it changes the placement of positions which follow it, so care must be taken to always generate field 008 with all 40 positions. In the example below, the character “\” represents a blank and the fill character “|” is used where no attempt was made to code the position.

008/00-05 (Date of creation)

The first six character positions in field 008 (positions 008/00 to 008/05) contain a formatted date that records when the record was created. The format of the date is: yymmdd where “yy” is the last two digits of the year, “mm” is the two-digit month, and “dd” is the two-digit day. Many MARC users allow the computer itself to supply this date when a record is created. Supplying the date of creation automatically depends on the sophistication of the system and/or template you are using for input. If possible, make a template that will allow the date to be supplied automatically.

008/06 (Type of publication date)

Character position 008/06 contains a one-letter code that identifies the kind of publication date(s) associated with the bibliographic item. The coding of this position is dependent on the kinds of dates recorded in positions 008/07-10 (Date 1) and 008/11-14 (Date 2). The table that follows shows the relationship between the code in position 008/06 and the dates in positions 008/07-14.

Coding values for 008/06
008/06 Name/meaning 008/07-10 (Date 1) 008/11-14 (Date 2)
s Single year 4-digit year 4 blanks
m Multiple years Beginning year of publication Ending year of publication
r Reprint & original year of publication Reprint year of publication Original year of publication
c Current periodical Beginning year of publication 9999 (latest possible year of publication)
d Dead periodical Beginning year of publication Ending year of publication

Most items are published in a single year, in which case 008/06 contains code “s”, 008/07-10 contains the year of publication, and 008/11-14 contains blanks. Even if an item does not have a publication date, a probable date of publication should be recorded in positions 008/07-10.

Use of the other codes in 008/06 makes the coding of 008/07-14 more complicated. The most common situation is the need to record multiple years, such as when a publication is in more than one volume and the volumes are published in more than one year.

The thing to remember is that Date 1 is usually the earliest year, and Date 2 is the later year. The only exception to this is for reprints, where Date 1 is the year of publication of the reprint, and Date 2 is the year of publication of the original edition. In this case, Date 2 is earlier than Date 1. Please note that new editions of a book are not treated as reprints by libraries. A true reprint is somewhat rare, and usually occurs when a new publisher reprints a book that has been unavailable for many years.

008/07-10 (Date 1)

There should always be a 4-digit year in positions 008/07-10. It is generally the first or earliest date associated with the item. If no date appears on an item, records a probable year of publication in 008/07-10. For multipart items and serials, 008/07-10 contains the year that the first volume was published. The Library of Congress uses one record for all volumes. However, if you are cataloging something other than the first volume, the date can be that of the volume in hand.

The date recorded in positions 008/07-10 has a relationship to the publication date recorded in field 260 (Imprint). This connection will be explained again in the description of field 260. The reason MARC requires a coded date in field 008 and a publication date in field 260 is that the coded representation of the date of publication in field 008 is standardized. This is important for the purposes of searching.

Field 260 is used to transcribe a date the way in appears on an item. This is not always a 4-digit year. It is also not always a Western-style year. A Hebrew book, for example, might have the publication date 5730, which would correspond to 1969 or 1970.

008/11-14 (Date 2)

When only one year is associated with a work, positions 008/11-14 contain blanks. If the item is published in more than one volume and more than one year is involved, 008/11-14 contains the last/ending year of publication. For serials that are still active, the ending year is not known. In this case, 008/11-14 contains “9999.” This represents the latest possible year.

008/15-17 (Country of publication code)

Positions 008/15-17 contain a 3-character MARC country code in lowercase Latin letters. In most cases, the country code is two alphabetic characters followed by a blank. Although many MARC users usually catalog publications from a single country, it is important to be able to modify the country code for publications from other countries. The MARC country code list is online at http://www.loc.gov/marc/countries/.

008/35-37 (Language of publication code)

Positions 008/35-37 contain a 3-character MARC language code in lowercase Latin letters. If a publication is in more than one language, 008/35-37 contains the code for the primary language of the item, usually that of the title. If the title itself is in more than one language, use the code for the official language of the country of publication. The MARC language code list is online at http://www.loc.gov/marc/languages/.

If more than one language is associated with an item, field 041 may be added to the MARC record as well. Field 041 (Language Codes) is used to record multiple language codes, especially when an item has been translated from another language. This field is optional but it can be very useful for purposes of searching.

Number and Code Fields

Field 020 (ISBN) - OPTIONAL

Field 020 contains the International Standard Book Number, a 10- or 13-character identifier assigned by the publisher to the title and edition. This MARC field is optional but is an important access point used by libraries. It is usually input in subfield $a, unless it is known to be an incorrect ISBN (for example, when it is not 10 or 13 characters long). These ISBNs are recorded in subfield $z. The field must include two indicator positions before subfield $a, but both positions contain blanks or “\”. The 10 or 13 characters of the ISBN are often printed on an item with hyphens separating them into groups (e.g. 1-4000-4025-6). However, because the placement of the hyphens varies, hyphens are not included in the MARC record.

Field 022 (ISSN) - OPTIONAL

Field 022 contains the International Standard Serial Number, a 9-character identifier (two groups of 4 characters, separated by a hyphen) assigned by the publisher to a serial. This MARC field is optional but is an important access point used by libraries. The ISSN is usually input in subfield $a, unless it is known to be an incorrect ISSN (for example, when it is not 9 characters long). It is then recorded in subfield $y. The field must include two indicator positions before subfield $a, but both indicator positions contain blanks or “\”. Because the hyphen always separates the first group of 4 characters from the second group of 4 characters in an ISSN, it is always included in field 022.

Note: When an ISSN is associated with a monographic series title, it is not recorded in field 022 but rather in field 440, subfield $x. See description of field 440 for details.

Field 028 (Publisher Number) - OPTIONAL

Field 028 contains publishers' numbers found on videorecordings, sound recordings, printed music, and other music-related material. These numbers are usually found on the edge of the container for the item nd may also be represented in part in a barcode (although barcodes are usually recorded in field 024). Publisher's numbers vary in length and style since they are not standardized identifiers. Many are alphanumeric. Usage of this number in a MARC record is optional, but it is an important access point.

The number is input in subfield $a. Transcribe the number as it appears on the item; this means including any internal spaces or punctuation that appear with the number. There are no input standards controlling the number recorded in field 028.

The publisher or issuing body is named in subfield $b. A brief form of the publisher's name is usually given. The field must include two indicator positions before subfield $a. The first indicator may contain the following values:

The second indicator contains a value that indicates whether a note and/or added entry generated from the content of the field is required:

Field 040 (Cataloging Agency) - REQUIRED

Field 040 contains MARC organization codes that identify who cataloged the item and who input the cataloging data. Usually, the same code is used. Subfield $a contains the MARC code for the cataloging agency and subfield $c contains the MARC code for the inputting agency. Field 040 has two indicator positions; both indicator positions contain blanks or “\”.

If you do not already have an official MARC organization code, request one online at http://www.loc.gov/marc/organizations/. MARC organization codes are assigned free of change.

Field 041 (Language Codes) - OPTIONAL

Field 041 contains two or more of the three-character lowercase Latin MARC language codes that identify the languages of the content of the item when there is more than one language (the main language of an item is also recorded in field 008/35-37).

The primary language(s) are recorded in subfield $a. This subfield is repeated for each language code.

If the item is a translation, the language code of the translation is recorded in subfield $a and the code for the original language is recorded in subfield $h.

The first indicator is value “0” when the item is not a translation, and value “1” when the item is a translation. The MARC language code list is online at http://www.loc.gov/marc/languages/.

Main Entry Fields

100 (Main Entry-Personal Name)

Field 100 contains the name of the person primarily responsible for the content of the item. In cataloging, this is usually referred to as a main entry heading.

Field 100 can be used only once in a record, and only if no other field beginning with “1” is present. That means a record cannot have field field 100 and field 110, 111 or 130. Only one 1XX field may be present in a records.

This field is optional because there may not be always be a primary personal name associated with the work.

100 $a (Personal name)

The personal name is recorded in subfield $a, usually in inverted “catalog entry” form. A comma separates the surname from the family name. Field 100 has two indicator positions. The first indicator is most often “1” and the second indicator is blank or “\”. In cases where the name consists of a forename only, the first indicator is “0”.

100 $b (Numeration)

Sometimes a number is associated with a personal name. It is recorded in subfield $b. This situation occurs most often when names lack a surname (and therefore have a first indicator value of “0”).

100 $c (Words associated with a name)

Sometimes one or more words are associated with a name but are not part of the forename or surname. These are recorded in subfield $c. A comma separates subfield $c from the preceding subfield.

100 $d (Dates associated with a name)

Some catalogers include birth and death dates (if known). These dates are recorded in subfield $d. A comma separates subfield $d from the preceding subfield. If no death date is appropriate or available, the birth date ends with a hyphen.

Field 100 always ends in a mark of final punctuation. This is usually a period, but a hyphen or question mark are also considered final marks of punctuation.

111 (Main Entry-Meeting Name)

Field 111 contains the name of the meeting, congress, conference, etc., that is primarily responsible for the content of an item. Meeting names are recorded in field 111 only when they appear prominently on the item and the item consists of the proceedings or record of the meeting. The first indicator position should contain value “2”. The second indicator is always blank (or “\”).

111 $a (Meeting name entry element)

The name of the meeting is recorded in subfield $a. When transcribing the name, follow the capitalization and punctuation rules of the language of the name.

111 $n (Number of meeting)

When a meeting is numbered, the number is recorded in subfield $n. An opening parenthesis [e.g. “(”] is placed before the number.

111 $d (Year of meeting)

The year that a meeting was held is recorded in subfield $d. Subfield $d is separated from the number of the meeting by a space colon [e.g. “ :”]. If no number is associated with the meeting, the date is preceded by an opening parenthesis [e.g. “(”].

111 $c (Place of meeting)

The place where a meeting was held is recorded in subfield $c after subfield $d. Subfield $c is preceded by a space colon. [e.g. “ :”]. A closing parenthesis [e.g. “)”] is added at the end of subfield $c.

Title and Title-Related Fields

245 (Title Statement)

Every MARC bibliographic record must have 245 field with at least subfield $a. It is assumed that all bibliographic items have some sort of title. Cataloging rules generally require transcription of the title exactly as it appears from a chief source of information. For books, this is the title page, for other types of material, this may be some other source. If an item lacks a title page or source of title information, a title is supplied by the cataloger in square brackets (“[....]”). Catalogers change the capitalization of the words in the title to follow the normal rules for the language of the work; that is, not all title words should be capitalized even though they may appear that way on a title page. Diacritical marks (accents, umlauts, tilde, etc.) are added to words that would normally have them even if they are missing on a title page. This often occurs when a title appears on a work in all uppercase letters without diacritical marks.

The punctuation of the title statement should follow that found on the source of the title, except that the colon (“:”) is replaced by the comma (“,”). Dots of ellipsis (“...” are replaced with two hyphens followed by a space (“-- ”). Dots of ellipsis are added only to show that the title has been shortened by the cataloger. If a title begins with dots of ellipsis (for example: “...and then there were three”), these are replaced by two hyphens (for example: “--and then there were three”).

Like most other fields, field 245 has two indicator positions. If there is a 1xx field in the record, the first indicator value is “1”. If there is no 1xx field the value is “0”.

The second indicator position can contain any value from “0” to “9” and is used to indicate how many letters at the beginning of the title should be skipped in filing or indexing. If a title begins with an initial article (for example “The”), the initial article is skipped. The space that follows the article is included in the count.

245 $a (Title proper)

The main title of a work, as it appears on the chief source of information, is recorded in field 245 subfield $a. This subfield is not repeatable. Here is a typical example of field 245, subfield $a.

245 $h (General medium designator)

If the item being cataloged is not printed text, record a general medium designator (GMD) that indicates the kind of special material. A typical example is a map. The GMD is given in the language of the catalog for which the MARC record is being made, not the language of the item itself. For example, an item in German would have a GMD in English if the MARC record was intended for an English language catalog.

The need to include subfield $h in field 245 is related to the code recorded in field 000 position 06 (Record type). If the record is for something other than text (code “a” in 000/06), then subfield $h should be added to field 245.

Subfield $h should always follow subfield $a. The GMD is recorded in square brackets (“[...]”). Simple terms are used in subfield $h, such as “atlas”, “map”, “sound recording”, “videorecording”, “CD-ROM”, and “music”.

245 $b (Other title information)

Many works have title information after the main title. This other title information is recorded in subfield $b.

Subfield $b is not required by the format, but it is usually added when a subtitle is present because important descriptive information is often found in this other title information. Subfield $b is preceded by a space and colon (“: ”). This subfield is not repeatable, but additional title information may be transcribed, separated by space colon space (“ : ”).

245 $c (Statement of responsibility)

Many works include some kind of statement of responsibility. Cataloging rules require that a transcription of a statement of responsibility appear in field 245, subfield $c, even though the name(s) may also appear in other MARC fields , such as fields 100 or 700.

Often statements of responsibility are simple statements such as: “written by John Williams”. But they can also be complex and include many names and information explaining who did what.

Libraries try to transcribe what appears on an item with as little change as possible, although some parts of a statement of responsibility are omitted, such as terms of address (“Dr.”). Libraries usually follow the Rule of Three when recording statements of responsibility. If more than three persons or corporate bodies are named, only the first is recorded in field 245 subfield $c. Others are omitted and dots of ellipsis and “et al.” in square brackets are added to show that the statement has been shortened (“ ... [et al.]”).

Only proper names are capitalized. The subfield is usually separated from the rest of the title statement by a space slash (“ /”). If several statements of responsibility need to be transcribed, they are separated from one another by a space, semicolon, space (“ ; ”). Subfield $c is not repeatable.

Why does a MARC record need 245 $c?

The information in field 245 subfield $c often repeats much of the information also recorded in field 100 or 700. However, it is important to remember that the content of field 245 subfield $c is the transcription of the statement of responsibility from the title page. This means that the information is not formatted like it is in one of the 1XX or 7XX fields. Libraries use the transcription of the title and author statements in field 245 to match an item with a specific bibliographic record. For works that have been published in many editions, this can be an important factor in identifying the appropriate MARC record.

The statement of responsibility is also used by librarians to determine the best form of name to use in access fields (MARC 1XX, 6XX, and 7XX fields). Prolific authors often vary the way they present their names on title pages. A single form will be used in a MARC access field, but different forms may appear in field 245. This is why catalogers transcribe the title page so carefully. The MARC record should reflect closely what was on the title page.

However, it is permissible to add information to what is transcribed if this makes the content of the work or responsibility for it clearer. But any additions made by the cataloger should always be recorded in square brackets. This indicates that the information did not appear on the chief source of information.

Field 246 (Variant Title) - OPTIONAL

Field 246 is used to provide access to a variant title that appears on an item. These titles appear on the cover, spine, or in other locations. If the variant title appears on the title page, the same title may be found in the transcription of the title page in field 245. This is often the case with parallel titles in different languages. The first indicator in field 246 is usually value 3 (a title added entry is generated, but no note). The second indicator value depends on the kind of variant title in field 246. The possibilities for the second indicator are shown in the following table.

Second indicator values for Field 246
Value Meaning
blank or “\” No type specified
0 Portion of title
1 Parallel title
2 Distinctive title
3 Other title
4 Cover title
5 Added title page title
6 Caption title (on periodicals)
7 Running title (throughout text)
8 Spine title

The variant title is recorded in subfield $a. If none of the second indicator choices shown above is appropriate, you can record a word or phrase in subfield $i that indicates the type of variant title. If subfield $i is used it precedes subfield $a. Subfield $i is often used in records for Russian publications that have a Russian title in the colophon. Field does not end in a mark of punctuation unless the last word in the field is an abbreviation, initial/letter, or data that ends woth a mark of punctuation.

Edition, Imprint. Etc. Fields - OPTIONAL

Field 250 (Edition Statement)

Field 250 is optional but should be included if an edition statement appears on the item. The statement is recorded in subfield $a in abbreviated form in the language in which it appears and should not be translated into another language. Both indicator positions in field 250 contain blanks or “\”. If the edition statement does not appear on an item but is known from some other source (external to the item), it may be recorded in square brackets (“[...]”). Field 250 always ends in a period.

Field 254 (Musical Presentation Statement) - OPTIONAL

This field is optional but should be included if the item is printed music. The musical presentation statement usually consists of words or phrases such as “Partitura” or “Full orchestral score” that appear on the piece of music itself. Do not translate this statement into another language; record it in the language in which it appears. If it appears in more than one language, transcribe it in the language of the title in field 245.

The statement is recorded in subfield $a. Both indicator positions in field 254 contain blanks or “\”. If the musical presentation statement does not appear on an item but is known from some other source (external to the item), it may be recorded in square brackets (“[...]”). Field 254 always ends in a period.

Field 255 (Cartographic Mathematical Data) - OPTIONAL

Field 255 is optional but should be included if the item is an atlas, map, or globe. Information about the scale of the cartographic item is recorded in this field. If the scale is not indicated on the item but is known from some other source (external to the item), it may be recorded in square brackets (“[...]”). If the scale is not known, use the statement “Scale not given.” or its equivalent in another language.

The statement is recorded in subfield $a. Both indicator positions in field 255 contain blanks or “\”. Field 255 always ends in a period.

Field 260 (Imprint) - REQUIRED

Field 260 is required in all MARC records. The field provides information that is useful to those users who might want to obtain a copy of the item. Information for field 260 is not always readily available but most catalogers try to provide information in the three main subfields defined for field 260: subfield $a (Place of publication), subfield $b (Publisher/distributor), and subfield $c (Date of publication/distribution), even if the information is probable.

Square brackets are used to indicate information that does not appear on the item being cataloged. A good thing to remember is that the person cataloging an item is most likely to know where it was published, by whom, and when. Years later, after the MARC record has sat in a library catalog, it will be much harder for a library user to guess what that information might be. Field 260 is not repeatable. Both indicator positions in field 260 contain blanks or “\”.

260 $a (Place of publication)

The first subfield in field 260 is always subfield $a. The place of publication is given in the briefest form possible that is clearly recognizable. The place is usually transcribed from the title page or preliminary pages of a work in the language of the text (thus “München” not “Munich” for a work in German). The name of the country or other jurisdiction is not added, unless it appears on the item or is needed to identify the city (for example “Athens [Ga.]”, or, “La Paz [Argentina]”).

If multiple places appear on a work, only the first place is given, unless it is not in the country where the item is being cataloged. In that case, a second place can be given. If there is no indication of the place of publication, the cataloger should provide the most probable place of publication followed by a question mark (“?”). Place this information in square brackets. If no place of publication is named and no good guess can be made, the abbreviation “[S.l.]” (Latin for “sine loco” (without place)) is recorded in subfield $b in square brackets.

Subfield $a is repeatable when more than one place must be recorded. When subfield $a is repeated, a space semicolon (“ ;”) is used to separate the repeated subfield from any subfield that precedes it.

260 $b (Publisher/distributor)

Field 260 should also always include at least one occurrence of subfield $b with the name of the publisher or distributor of the item. The name should be transcribed from the work itself, but may be abbreviated, as long as it is intelligible. If the name of a publisher appears in more than one language, the name in the language that corresponds to the title is preferred.

Subfield $b can be repeated for multiple publishers, but generally no more than three are given. If each publisher in located in a different city, subfield $b should follow the subfield $a with which it is associated. Most libraries precede subfield $b with a space semicolon (“ :”). If no publisher/distributor is named and no good guess can be made, the abbreviation “[s.n.]” (Latin for “sine nomine” (without name)) is recorded in subfield $b in square brackets.

260 $c (Date(s) of publication)

Field 260 normally includes subfield $c with the date of publication or distribution. Subfield $c is recorded as the last subfield in field 260, separated from the rest of the field by a comma (“,”). Usually the date is given in terms of a single year, or multiple years separated by a hyphen for multipart items. If the ending year is not known, the beginning year is followed by a hyphen and nothing else. The field itself should end in a period unless a hyphen, question mark, or square bracket is already present. If the year is not a Western style year, the Western equivalent is provided in square brackets immediately after the year(s) that was (were) transcribed from the item. If no date of publication/distribution is known, a probable date of publication should be supplied followed by a question mark (“?”). Probable dates are enclosed in square brackets.

Field 300 (Physical Description)

Field 300 is required in all MARC records and is used to record the physical description of the item--in particular its extent and dimensions. This physical description is used to more easily locate an item or to determine the size of an item in general.

The extent of a item (that is, number of pages, number of volumes, disks, etc.) is recorded in subfield $a. The dimensions of the item are recorded in subfield $c. An optional subfield $b is used to record other physical details, and accompanying material (for example, a DVD) is recorded in subfield $e. The subfields are recorded in alphabetical order. Both indicator positions in field 300 contain blanks or “\”.

The field may be repeated to record the physical description of components of different material types that are covered by the same MARC record, but this does not occur very often.

300 $a (Extent)

The extent of a bibliographic item is usually a numeric value followed by additional information that varies depending on what type of material the item is.

The extent of textual material is expressed by the number of pages, when the item is complete in one volume, or the number of volumes, when the item is in more than one volume. The words “pages” and “volumes” are abbreviated to “p.” and “v.” respectively in field 300.

The extent should represent the extent of the perfect copy, that is, the total number of pieces that would constitute a complete copy of the item. If the MARC record is for some of the parts of a multipart item, the number of the part being described is recorded in angle brackets (“<...>”) after the extent term. For example, if cataloging only volume 7 of a 10-volume set, the extent would be expressed as “v. <7>” not “7 v.”. Catalog users would interpret “7 v.” to mean that the item included and was complete in seven volumes.

Non-print materials use a variety of standard terms in field 300 subfield $a:

300 $b (Other physical details)

Many MARC users want to record other important physical details related to an item. These details include the presence of illustrations (“ill.”), sound (“sd.”), characteristics of sound (for example, “stereo”), recording technique (for example, “digital”), speed (for example, “33 1/3 rpm”), image characteristics (for example, “col.” or, “b&w”), and base material (for example, “wood”). The tendency is for this information to be kept brief. Libraries usually separate subfield $b from any preceding subfield with a space colon (“ :”). Subfield $b is not repeatable.

300 $c (Dimensions)

Field 300 should include the dimensions of the item in subfield $c. Dimensions of printed items are usually represented by the height in full centimeters (not fractions), unless the item is wider than it is high, in which case both the height and width are given in subfield $c. Film is measured in full millimeters. For discs, the diameter is given, usually in American inches (2.54 cm. = 1 inch).

Subfield $c is required, but often omitted by MARC users. In cases where the creator of the MARC record is unable to provide dimensions, the abbreviation “cm.” can be recorded in subfield $c as a placeholder. A space semicolon (“ ;”) is used to separate the subfield $c from preceding subfields. Subfield $c is not repeatable.

Field 310 (Current Publication Frequency)

Field 310 is optional but should be included if the item is a serial (periodical). The current publication frequency is recorded in subfield $a in the language of the catalog in which the record will reside, not the language of the title. It is usually brief, such as “Quarterly”, “Weekly”, or “Seven times a year”. Both indicator positions in field 310 contain blanks or “\”.

The frequency statement does not have to be found in the issue in hand in order for the MARC record to contain field 310. The first issue of a new periodical often has an indication of the planned publication frequency. If the frequency is not known or varies, field 310 can state this. Field 310 does not end in a period.

Field 362 (Dates of Publication and/or Sequential Designation)

Field 362 is optional but should be included if the item is a serial (periodical). All periodicals must have some sort of sequential designation. This is usually a number and associated month/year, but for annual publications, this can be a year alone. When issues of a periodical have both numbers and associated chronological designations (month, year, etc.), the chronological designation is recorded in parentheses after the number.

Field 362 contains the dates/sequential designations of the first and last issues only. However, since many periodicals are not dead, this field may contain only the date/sequential designation from the first issue.

If you do not know the date/sequential designation of the first issue, use the date/sequential designation from the issue you have. The designation is recorded in subfield $a. The first indicator position in field 362 should contain value “0”, the second indicator contains a blank or “\”. Field 362 ends with a hyphen if the designation of the last issue is not yet known.

Series Fields

Field 440 (Series Statement)

Field 440 contains the title, ISSN, and volume number(s) associated with monographic series and other collective titles associated with an item. Field 440 is repeatable if an item is in more than one series, however, in most cases where more than one series title appears, one is a main series and the other is a subseries. Cataloging agencies must be careful to identify cases where more than one series title is truly involved.

The first indicator position in field 440 always contains blank or “\” The second indicator position can contain any value from “0” to “9” and indicates how many letters at the beginning of the title should be skipped in filing if a series title begins with an initial article (for example “The”). The space that follows the letters to be skipped is included in the count. Although series titles are often displayed or printed with parentheses, parentheses are not recorded in the MARC record. Here is a typical example of field 440, subfield $a.

440 $a (Main series title)

The first subfield in field 440 is always subfield $a. It contains the main series title and is transcribed from the item as it appears. The same rules of capitalization and punctuation applicable to field 245 are applied in field 440. Subfield $a is not repeatable.

440 $x (ISSN)

If an ISSN has been assigned to a monographic series it is recorded in field 440, subfield $x, not in field 022. Only ISSNs associated with serials (periodicals) should be recorded in field 022.

The ISSN is recorded in subfield $x without the legend “ISSN”, but the hyphen that separates the first group of four characters from the second group of four should be included. Subfield $x is separated from subfield $a by a comma.

440 $v (Volume/sequential designation)

Volumes in a monographic series are sometimes numbered. If some sort of sequential designation (numbering) appears on the item, it is recorded in subfield $v and is separated from the preceding subfield by a space semicolon. Words associated with a number are included but in abbreviated form.

440 $n and $p (Subseries number and title)

Some monographic series include numbered (and unnumbered) subseries. These can be complex to catalog, and the MARC encoding can be equally complex. If the item you are cataloging includes a true subseries, it should be transcribed in the same occurrence of field 440 as the main series. The subseries title is recorded in subfield $p. If the subseries title has a sequential designation, the designation (numeric or alphabetic) is recorded in subfield $n, not $v. See the examples below.

Note Fields

Field 500 (General Note)

Field 500 is one of nearly 50 optional 5XX (Note) fields in the MARC 21 format. This field is described here because it can be used instead of one of the other more specific note fields. You may want to look at other 5XX fields if you have a particular need to record note information more specifically.

The text of the note is recorded in subfield $a. Both indicator positions in field 500 contain blanks or “\”. The most common use of field 500 is to record additional information about the content or publication of the item. Field 500 ends with a a period.

Field 520 (Summary, etc.)

Field 520 is optional but popular with MARC users who want to provide a summary or review of the content of the item. A brief summary, review, etc. is recorded in subfield $a. An expansion or continuation of the summary, etc. is recorded in subfield $b. The brief summary is recorded in a separate subfield to allow MARC users to display or print only the brief summary when space for the full summary is not available. The first indicator is used to indicate the exact type of note informacion found in field 520. The possible first indicator values are:

Value Meaning
blank or “\” Summary
0 Subject
1 Review
2 Scope and content
3 Abstract
8 (No display/print constant generated)

For all but value “8”, the indicator is used to generate text corresponding to the definition of the value. Value 8 is used when no display or print constant is to be generated and would be used if you wanted the first word in field 520 to describe the type of information in the field, for example, if you wanted to record a critique and wanted the word “Critique:” to introduce the text rather than any of the other possible terms. The second indicator position in field 520 contains a blank or “\”. Field 520 ends in a period.

Subject Fields

Field 600 (Subject-Personal Name)

Field 600 contains the name of a person used as a subject added entry. Field 600 has two indicators. The first indicator is most often value “1”. In cases where the name consists of a forename only, the first indicator is value “0”.

The second indicator is used to identify the source of the heading in a 6XX field. For example, second indicator value “0” means that the source is LC Subject Headings. Value “4” means that the source is not identified. Value “7” means that the source of the 6XX subject heading is identified by a MARC code in subfield $2. Use of second indicator value “7” requires the presence of subfield $2 with a valid MARC source code.

Field 600 always ends in a mark of final punctuation. This is usually a period, but a hyphen or question mark are also considered final marks of punctuation.

600 $a (Personal name)

The personal name is recorded in subfield $a, usually in inverted “catalog entry” form. A comma separates the surname from the family name.

600 $b (Numeration)

Sometimes a number is associated with a personal name. It is recorded in subfield $b. Since this situation is most common with names lacking a surname, the first indicator is often “0”.

600 $c (Words associated with a name)

Sometimes one or more words are associated with a name but are not part of the forename or surname. These are recorded in subfield $c. A comma separates subfield $c from the preceding subfield.

600 $d (Dates associated with a name)

Some catalogers include birth and death dates with names associated with an item. These dates are recorded in subfield $d. A comma separates subfield $d from the preceding subfield. If the no death date is appropriate, the birth date ends with a hyphen.

600 $x (General subdivision)

Personal names used as subjects often include a subject subdivision that indicates the aspect covered by the item. These subdivision terms are recorded in subfield $x. A typical example is the subdivision “History”.

600 $2 (Source of name)

Subfield $2 is required in a 6XX subject field only when the second indicator position contains value “7”. A MARC source code for the thesaurus from which the name or term was taken is recorded in subfield $2.

Field 610 (Subject-Corporate Name)

Field 610 contains the name of a corporate body used as a subject. The first indicator position should contain value 2, unless the corporate name is entered under the name of a jurisdiction (for example, the name of a country). If the first element is a jurisdiction, the first indicator is value “1”.

The second indicator is used to identify the source of the heading in a 6XX field. For example, second indicator value “0” means that the source is LC Subject Headings. Value “4” means that the source is not identified. Value “7” means that the source of the 6XX subject heading is identified by a MARC code in subfield $2. Use of second indicator value “7” requires the presence of subfield $2 with a valid MARC source code.

610 $a (Corporate name entry element)

The corporate name entry element is recorded in subfield $a. This is the highest level part of a corporate name. Follow the capitalization and punctuation for the language of the name in transcription. Subfield $a ends in a period.

610 $b (Subordinate unit)

Subfield $b contains the name(s) of the subordinate, lower level unit of a corporate body. Subfield $b is repeated for each subordinate unit and each occurrence of subfield $b ends in a period.

610 $x (General subdivision)

Corporate names used as subjects often include a subject subdivision that indicates the aspect covered by the item. These subdivision terms are recorded in subfield $x. A typical example is the subdivision “History”.

610 $2 (Source of name)

Subfield $2 is required in a 6XX subject field only when the second indicator position contains value 7. A MARC source code for the thesaurus from which the name or term was taken is recorded in subfield $2.

Field 611 (Subject-Meeting Name)

Field 611 contains the name of a meeting used as the subject. The first indicator position should contain value 2. The second indicator is used to identify the source of the heading in a 6XX field. For example, second indicator value “0” means that the source is LC Subject Headings. Value “4” means that the source is not identified. Value “7” means that the source of the 6XX subject heading is identified by a MARC code in subfield $2. Use of second indicator value “7” requires the presence of subfield $2 with a valid MARC source code.

611 $a (Meeting name entry element)

The name of the meeting is recorded in subfield $a. Follow the capitalization and punctuation for the language of the name in transcription. The number of the meeting is not recorded in subfield $a.

611 $n (Number of meeting)

When a meeting is numbered, the number is recorded in subfield $n. An opening parenthesis is recorded before the number after the subfield code.

611 $d (Year of meeting)

The year that a meeting was held is recorded in subfield $d. Subfield $d is separated from the number by a space colon (“ :”). If no number is associated with the meeting, the date is preceded by an opening parenthesis after the subfield code.

611 $c (Place of meeting)

The place where a meeting was held is recorded in subfield $c after subfield $d. Subfield $c is separated from subfield $d by a space colon (“ :”). A closing parenthesis is recorded at the end of subfield $c.

611 $x (General subdivision)

Meeting names used as subjects often include a subject subdivision that indicates the aspect covered by the item. These subdivision terms are recorded in subfield $x. A typical example is the subdivision “History”.

611 $2 (Source of name)

Subfield $2 is required in a 6XX subject field only when the second indicator position contains value “7.” A MARC source code for the thesaurus from which the name or term was taken is recorded in subfield $2.

Field 630 (Subject-Uniform Title)

Field 630 contains a uniform title used as a subject. This field is only used for works that are not known by an author's name. The first indicator position contains value “0”. The second indicator is used to identify the source of the heading in a 6XX field. For example, value “0” means that the source is LC Subject Headings. Value “4” means that the source is not identified. Value “7” means that the source of the 6XX subject heading is identified by a MARC code in subfield $2. Use of second indicator value “7” requires the presence of subfield $2 with a valid MARC source code.

630 $a (Uniform title)

The uniform title is recorded in subfield $a. Subfield $a ends in a period if is not followed by another subfield.

630 $x (General subdivision)

Uniform titles used as subjects sometimes include a subject subdivision that indicates the aspect covered by the item. These subdivision terms are recorded in subfield $x. A typical example is the subdivision “Commentaries”.

630 $2 (Source of name)

Subfield $2 is required in a 6XX subject field only when the second indicator position contains value “7”. A MARC source code for the thesaurus from which the name or term was taken is recorded in subfield $2.

Field 650 (Subject-Topical Term)

Field 650 contains a topical term (that is, not the name of a person, corporate body, meeting, or uniform title) used as a subject. The first indicator position usually contains a blank or “\”. The second indicator is used to identify the source of the heading in a 6XX field. For example, second indicator value “0” means that the source is LC Subject Headings. Value “4” means that the source is not identified. Value “7” means that the source of the 6XX subject heading is identified by a MARC code in subfield $2. Use of second indicator value “7” requires the presence of subfield $2 with a valid MARC source code.

650 $a (Topical term)

The topical term is recorded in subfield $a. Subfield $a ends in a period if not followed by another subfield. Subfield $a is not repeatable.

650 $x (General subdivision)

Topical terms used as subjects often include one or more subject subdivisions that indicates the aspect covered by the item. These subdivision terms are recorded in subfield $x. A typical example is the subdivision “History”. Subfield $x is repeatable.

650 $2 (Source of name)

Subfield $2 is required in a 6XX subject field only when the second indicator position contains value “7”. A MARC source code for the thesaurus from which the name or term was taken is recorded in subfield $2.

Field 651 (Subject-Geographic Name)

Field 651 contains a geographic name used as a subject. The first indicator position always contains a blank or “\”. The second indicator is used to identify the source of the heading in a 6XX field. For example, second indicator value “0” means that the source is LC Subject Headings. Value “4” means that the source is not identified. Value “7” means that the source of the 6XX subject heading is identified by a MARC code in subfield $2. Use of second indicator value “7” requires the presence of subfield $2 with a valid MARC source code.

651 $a (Geographic name)

The geographic name is recorded in subfield $a. Subfield $a ends in a period if not followed by another subfield.

651 $x (General subdivision)

Geographic names used as subjects often include one or more subject subdivisions that indicates the aspect covered by the item. These subdivision terms are recorded in subfield $x. A typical example is the subdivision “History”.

651 $2 (Source of name)

Subfield $2 is required in a 6XX subject field only when the second indicator position contains value 7. A MARC source code for the thesaurus from which the name or term was taken is recorded in subfield $2.

Field 700 (Personal Name)

Field 700 contains the name of a person who has some responsibility for the content of the item but who cannot be identified as the primary author. Field 700 is repeatable, but most libraries follow the “rule of three” and do not include more than three occurrences of this field.

Field 700 has two indicator positions. The first indicator is most often “1” and the second indicator contains blank or “\”. In cases where the name consists of a forename only, the first indicator is “0”.

700 $a (Personal name)

The personal name is recorded in subfield $a, usually in inverted “catalog entry” form. A comma separates the surname from the family name.

700 $b (Numeration)

Sometimes a number is associated with a personal name. It is recorded in subfield $b. Since this situation is most common with names lacking a surname, the first indicator is often “0.”

700 $c (Words associated with a name)

Sometimes one or more words are associated with a name but are not part of the forename or surname. These are recorded in subfield $c. A comma separates subfield $c from the preceding subfield.

700 $d (Dates associated with a name)

Some catalogers include birth and death dates with names associated with an item. These dates are recorded in subfield $d. A comma separates subfield $d from the preceding subfield. If no death date is appropriate, the birth date ends with a hyphen.

Field 700 always ends in a mark of final punctuation. This is usually a period, but a hyphen or question mark are also considered final marks of punctuation.

Field 710 (Corporate Name)

Field 710 contains the name of a corporate body for which access is needed in the MARC record. Although it is possible to record a corporate name in field 110, in most MARC records, corporate names are given in 710. The first indicator position should contain value “2”, unless the corporate name is entered under the name of a jurisdiction (for example, the name of a country). If the first element of the name is a jurisdiction, the first indicator is value “1”. The second indicator is always blank (or “\”).

710 $a (Corporate name entry element)

The corporate name entry element is recorded in subfield $a. This is the highest level part of a corporate name. Follow the capitalization and punctuation for the language of the name in transcription. Subfield $a ends in a period.1

710 $b (Subordinate unit)

Subfield $b contains the name(s) of subordinate, lower level units of a corporate body. Subfield $b is repeated for each subordinate unit. Each occurrence of subfield $b ends in a period.

Field 711 (Meeting Name)

Field 711 contains the name of a meeting for which access is needed in the MARC record. The first indicator position should contain value “2”. The second indicator is always blank or “\”.

711 $a (Meeting name entry element)

The name of the meeting is recorded in subfield $a. Follow the capitalization and punctuation for the language of the name in transcription. The number of the meeting is not be recorded in subfield $a.

711 $n (Number of meeting)

When a meeting is numbered, the number is recorded in subfield $n. An opening parenthesis is recorded before the number after the subfield code.

711 $d (Year of meeting)

The year that a meeting was held is always recorded in subfield $d. Subfield $d is separated from the number by a space colon (“ :”). If no number is associated with the meeting, the date is preceded by an opening parenthesis after the subfield code.

711 $c (Place of meeting)

The place where a meeting was held is always recorded in subfield $c after subfield $d. Subfield $c is separated from subfield $d by a space colon (“ :”). A closing parenthesis is recorded at the end of subfield $c.

Local Fields

Field 923 (Local Acquisitions Information)

Field 923 is a locally-defined MARC field used by the Library of Congress and vendors of library materials (mostly booksellers) who provide MARC records to LC for items they supply. The field contains a formatted date and the number of the invoice on which the bibliographic item was supplied.

This field is not required by the MARC 21 format but it is an important field for the Library of Congress. Suppliers of library materials to the Library should always include field 923 in records for items being shipped. Both indicators contain value blank or “\”.

923 $d (Invoice date)

Subfield $d contains an 8-digit formatted date of the invoice on which an item was supplied. The format of the date is: yyyymmdd where “yyyy” is the year, “mm” is the two-digit month, “dd” is the two-digit day. If the day is unknown, two hyphens can be used instead of digits.

923 $n (Invoice number)

Subfield $n contains the number assigned by the source of the material (often a bookseller) to the invoice on which the item was supplied. There are no special formatting requirements for the invoice number since the style and length of invoice numbers varies from source to source. This subfield is not intended for order numbers that can be assigned by LC or the supplier. No subfield is currently defined in MARC 21 for order numbers.

923 $s (Source code)

Subfield $s contains the MARC organization code for the source of the bibliographic item--this means, the supplier to the Library of Congress, not the publisher. This is usually the same MARC organization code as is found in field 003 and field 040.

Using MARCMaker and MARCBreaker

Up to this point, this guide has only presented information about possible MARC data elements and cataloging rules to follow in recording the data. The rest of this guide is for people who want to work with MARC records using MARCMaker and MARCBreaker and describes how to use this software.

Introduction

MARCMaker and MARCBreaker are software programs developed by the Library of Congress (LC) and are available free-of-charge to MARC format users.

Both MARCMaker and MARCBreaker run on any IBM-compatible PC running under DOS with a 386 Intel (or compatible) processor or better. If you have a computer with Windows 95, 98, or 98 ME, 2000, or XP, MARCMaker/Breaker should work in DOS emulation mode.

MARCMaker accepts files from most text editors and word processors (e.g., WordPerfect) and converts information to the MARC record structure. The program requires only that bibliographic data be presented a certain way so that the correct MARC structure and data separators (e.g., delimiters) can be generated. The interpretation by MARCMaker of explicit flags in the source data is how the proper MARC record structure is generated.

MARCMaker is very flexible. Anyone with access to even the simplest of computers can create source cataloging records that can be transformed into structurally sound MARC records. The companion program MARCBreaker can be used to take a file of MARC records and convert them into a text file configured the way MARCMaker requires.

Creating an Input File

MARCMaker is designed to accept information that has been saved as a DOS text file. Most word processors provide an option to save a file as DOS or ASCII text. A text file saves most graphic characters and omits special word processing codes. Saving a word processing file as a text file means stripping out any word processing codes like tabs, margin releases, indents, bold facing, etc. Since none of these word processing features are important to MARC records, it is not surprising that MARCMaker does not want to encounter any of them.

Preparing a file for MARCMaker is relatively easy. There are only a few rules for creating the text file for the records that will be converted. Most of the rules provide MARCMaker with a way to determine where records, fields, and subfields begin and end. The only other special instructions are related to encoding beyond the basic Latin alphabet (e.g., letters with accents or scripts other than Latin). Here is the short list of requirements for a MARCMaker input file.

MARCMaker Input File Rules:

  1. Start of file. The input file must begin with the first line of the first record. No other data may precede the first record in a file to be converted to MARC.
  2. Start of record. Each record after the first one must be preceded by an empty line. MARCMaker will interpret the data that follows the hexadecimal character string “0D 0A 0D 0A” as the beginning of a new record wherever this string occurs.

    If an empty line occurs between fields inside a record, MARCMaker will start a new record after the empty line, corrupting the file. If more than one empty line separates a record from the previous one, the extra line will be interpreted as a bad record, which will also corrupt the MARC file. Be careful with empty lines.

    Tag “000” is recommended for the record Leader.
  3. Start of field. All fields must begin with an equal sign “=” (hexadecimal character value 3D, or decimal character value 061) followed by a 3-character tag. The equal sign is not a reserved character since it is only interpreted as the beginning of new field when it follows a carriage return/line feed pair (hexadecimal characters string “0D 0A”) and is followed by a 3-digit tag. MARCMaker analyzes the environment of the equal sign before deciding whether to begin a new field.

    Note: Not all computers represent the equal sign with the same character value. It does not matter what you see on your computer screen, but be sure that the start of field character is the hexadecimal value 3D (decimal value 061). You can usually test this by holding down the “[ALT]” key on your keyboard and typing in the digits “0 6 1” on the number keypad. This character value may have been assigned to an accented letter in some countries.
  4. End of field. All fields must end with a carriage return (hexadecimal character 0D) and line feed (hexadecimal character value 0A) pair.
  5. Line breaks. MARCMaker does not care how long each field is, provided no field is longer than 9999 characters. If line length is limited by the software you use to create the input file and a field includes more than one line of text, every line of text must end with a carriage return and line feed pair (hexadecimal character values 0D and 0A), whether or not it is the end of a field.

    In most PC programs, the “ENTER” key is used to insert a carriage return/line feed pair of control characters into a text file. If a space occurs between the last word in one line and the first word of the next line, it is recommended that the space occur at the beginning of the next line. Some word processors automatically drop spaces that occur at the end of lines when saving to a text file. Breaking lines after 75 characters is generally recommended as long as it does not split a string enclosed in curly braces “{...}”.
  6. Spacing after tag. Two character positions (usually spaces) must separate the 3-digit field tag from the rest of the data in the field. MARCMaker will omit these two character positions when the MARC record structure is generated.

    In fields 010-999, these two character positions precede two additional positions occupied by indicator values. Since indicator positions sometimes contain blanks (spaces), this may result in more than two spaces between the 3-digit tag and the first subfield delimiter. The two character positions that precede actual MARC data are required by MARCMaker but serve to improve readability of the text file only. You may use any character in these two positions you want, but spaces are recommended.
  7. Backslashes. The backslash “ \” (hexadecimal character value 5C/decimal character value 092) can be used instead of a space or blank (hexadecimal character value 20/decimal character value 032) in an input file. This means that you cannot use the backslash character to represent a real backslash with MARCMaker. To enter a real backslash into a MARC record, use the character string “{bsol}”, an abbreviation for “back solidus”, the official name of the backslash.

    Note: Not all computers represent the backslash with the same character value. It does not matter what you see on your computer screen, but be sure that the backslash character is the hexadecimal value 5C/decimal value 092. You can usually test this by holding down the “[ALT]” key on your keyboard and typing in the digits “0 9 2” on the numeric keypad to the right of your keyboard. This character value may have been assigned to a special accented letter in your country. Use it as if it were a backslash.
    Character strings in curly braces “{...}” receive special processing during conversion by MARCMaker
  8. Dollar sign. The dollar sign “$” (hexadecimal character value 24/decimal character value 036) must be used as the subfield delimiter at the beginning of each subfield in fields 010 to 999. Remember, fields 000 to 009 have no subfield codes.

    The dollar sign is a special reserved character when used with MARCMaker. It must be followed by a small Latin letter “a” to “z” or a digit “0” to “9”. No other characters can be used to identify subfields in MARC 21.

    If you need to represent a real dollar sign in cataloging data (for example, in a title), use the character string “{dollar}”, enclosed in curly braces.

    Note: Not all computers represent the dollar sign with the same character value. It does not matter what you see on your computer screen, but be sure that the dollar sign character is the hexadecimal value 24/decimal value 036. You can usually test this by holding down the “[ALT]” key on your keyboard and typing in the digits “0 3 6” on the numeric keypad to the right of your keyboard. This character value may have been assigned to a special accented letter in your country. Use it as if it were a dollar sign.
  9. Curly braces. The left curly brace “{” (hexadecimal character value 7B/decimal character value 123) and right curly brace “}” (hexadecimal character value 7D/decimal character value 125) are reserved characters used to signal the beginning and end of character strings that are converted to special characters in the output MARC record file.

    MARCMaker converts any string of characters enclosed in curly braces to some other character string it finds in a character conversion file whose name you give as a third parameter when you run the program. If it doesn't find the string in the character conversion file, it passes the string to the MARC record. If you need to record a real left or right curly brace character in the output MARC record (because it appears in the cataloging data), you must use the character string for the left “{lcub}” or right “{rcub}” curly brace.
  10. Modified Latin letters and non-Latin scripts. MARCMaker can accommodate both accented letters and non-Latin character sets, but special character conversion files must be used. Letters of the Latin alphabet with diacritical marks (for example, accents) and letters from non-Latin alphabets must be encoded with great care. The character conversion file supplied with MARCMaker is designed for the MARC-8 Latin character set only. See the section on Character Sets for a more detailed description about how character sets are handled.

MARCMaker provides a couple of helpful ways to make your text input file more readable prior to conversion. As already mentioned, blank spaces can be input using either a space (hexadecimal character value 20) or the backslash character “\”.

Particularly in MARC elements like field 008 (Fixed-Length Data Elements) and in indicator positions, the use of the backslash can prevent input errors since real spaces are difficult to count. You are advised to use the backslash instead of a blank whenever legibility is required (for example, when you need to be able to count the number of blanks easily). It is recommended that you used the backslash instead of space whenever more than one space occurs together.

MARCMaker will convert backslashes to blanks automatically MARCBreaker follows the same principle and converts any occurrences of more than one blank space in a row to a backslashes. This makes it easy to see records that have too many spaces together.

Character Sets

Except for the special reserved characters already described in the MARCMaker Input File Rules, it is possible to use characters from virtually any 8-bit character set with the MARCMaker program. Most 8-bit graphic characters can be passed to the output MARC record without change. The MARC 21 formats themselves, however, use special library character sets for representing information in the Arabic, Cyrillic, Greek, Hebrew, and Latin scripts. MARC 21 also supports Chinese, Japanese, and Korean scripts, but these are not 8-bit characters sets and are not discussed here. In order to make good use of MARCMaker and MARCBreaker, you need to consider the special character set requirements described in the following sections.

Latin Script

Most users of MARCMaker and MARCBreaker will be able to create files that include the basic Latin alphabet. This even includes users in countries such as Russia where other scripts are used.

MARCMaker and MARCBreaker were designed to process any data including the basic Latin alphabet, the digits 0 to 9, punctuation marks, and a small number of additional characters since these characters are the only ones used in the MARC content designation (that is the tags, indicators, and subfield codes that separate MARC data into its distinctive parts).

The basic Latin character set as used in MARC is shown below. Note: Some of these characters may appear differently on your screen due to national differences in the Latin alphabet.

Symbol Name
@ at sign
# number sign
% percent sign
& ampersand
$ dollar sign
* asterisk
+ plus sign
= equal sign
| pipe sign (fill)
^ spacing circumflex
_ spacing underline
` spacing grave
~ spacing tilde
< less than sign (left angle bracket)
> greater than sign (right angle bracket)

Letters beyond the basic Latin alphabet, and even those in the table above vary from country to country. Different countries need different modified Latin letters (for example, letters with different accents), so some characters are dropped and others are added.

Computer keyboards and the character codes they generate are not the same everywhere. Computers in some countries even provide letters from different alphabets (for example, Greek) in addition to the basic Latin alphabet.

For the basic Latin script, nothing special needs to be done for MARCMaker. If you want to create MARC records with special Latin script characters or characters from other scripts, you should consider using the special character encoding technique described below.

Mnemonic strings (“Mnemonics”)

It is dangerous to pass Latin characters beyond the basic letters a-z and A-Z, or characters from non-Latin alphabets into MARC records. Although MARCMaker makes this technically possible, libraries receiving such MARC records may not be able to load the records into their MARC-based library systems. To get around this problem, MARCMaker allows you to encode those special characters using mnemonic character strings enclosed in curly braces. (The term “mnemonic” is from the Greek word “mnemos” meaning “memory”.)

A mnemonic character string holds the place of a special character which cannot be included in the MARCMaker input file; for example, the mnemonic string “{dollar}” must be used for the U.S. and Canadian dollar sign since the character “$” has a special use in MARCMaker. The curly braces cause MARCMaker to convert the mnemonic strings inside them in a special way because MARCMaker references an external file of mnemonic character strings (“marc21.txt”) during conversion.

If a match is found, the mnemonic character string is replaced with the specified MARC character(s). For example, if you want to encode the letter “a” with an acute accent (“á”), MARCMaker allows you to enter “{aacute}” in place of the character “á”. MARCMaker will automatically convert this character string to the correct MARC 8-bit encoding.

The actual MARC technique for handling accented letters is to encode a character value for the accent (in this case the acute accent), followed by a character code for the base letter (in this case the letter a). Thus the original character “á” will become two separate characters in the MARC record. The MARC technique for encoding modified letters of the Latin alphabet is quite different from the way non-MARC data treats the same letters. Since many MARC users have trouble converting their “precomposed” letter-with-diacritic characters to the MARC encoding, MARCMaker does it for you. If you don't use mnemonic strings in your data, the original character codes pass into the MARC record. Remember, most MARC systems cannot handle these character codes correctly. A table of mnemonics for many of the most commonly used letter-with-diacritic and special characters is provided at the end of this manual.

Note: The conversion of mnemonic character strings is controlled by a special character set conversion file (“marc21.txt”) referenced by the third parameter when you run MARCMaker. The file “marc21.txt” is made available with MARCMaker, but it can be renamed and modified if desired. Unrecognized mnemonic strings are not converted but their style is slightly altered; the left curly brace “{” is converted to an ampersand “&” and the right curly brace is converted to a semicolon “;”. The style after conversion is that of an SGML (Standard Generalized Markup Language) character entity reference. Unrecognized mnemonics are passed into the resulting MARC 21 record to prevent loss of data. Any mnemonic strings found in a MARC 21 record after conversion should be investigated. The mnemonic string may need to be added to the character conversion file.

You can add new strings to this file if you like, but care must be taken when doing so. Attempting to modify the character conversion table file may corrupt it. If you do add character mnemonics to the table, keep in mind it must be saved as a DOS file and follow the predetermined syntax of other entries in the table. Modifying this table is only recommended for programmers.

Handling Non-Latin Scripts

As already mentioned, MARCMaker can process 8-bit character sets other than Latin, but use of anything but the Latin set is not documented here. There are special 8-bit MARC character sets for Arabic, Cyrillic, Greek, and Hebrew script. In addition to special considerations for MARCMaker's handling of these character, their use in MARC 21 records requires the inclusion of field 066 (Character Sets Present) as well.

Running MARCMaker to Convert Text to MARC Records

MARCMaker was designed to generate the ISO 2709 (MARC) record structure by converting simple ASCII (DOS) text files that already include MARC content designators (tags, indicators, and subfield codes), and the special textual “flags” that identify the beginning and end of each record, field, and subfield. Once the source records have been created and saved as a DOS file, converting the records to MARC is a quick step.

Starting MARCMaker

You can copy the program to any drive you want prior to using it. We recommend that you create a special subdirectory on your PC for all your MARCMaker/MARCBreaker work.

Invoke MARCMaker using the command “marcmakr” from the drive where the program is located. The command that starts MARCMaker requires three “parameters” to run. It needs to know 1) the name of the file to convert; 2) the name of the resulting file of MARC records; and 3) the name of the character set conversion mnemonic file (either “marc21.txt” or the name of a replacement file you created yourself).

Parameters are keyed immediately following the command “marcmakr” with a space separating each one. Multiple format implementations are supported by MARCMaker, but only the character set file for MARC 21 is shipped with the basic program files, thus the third parameter “marc21.txt” should be used. Press “[ENTER]” after keying in the “marcmakr” command and the three parameters.

(NOTE: The example above assumes all the files are in the same directory. If the files are in different directories, you would have to enter the full path for each file.

The file extensions “.txt” and “.mrc” are recommended for the source file and converted file, respectively. This makes it easier to differentiate between the source file and MARC record file.

What Happens While MARCMaker Runs?

Once you press “[ENTER]” the program runs and you should quickly find a converted file of MARC records on the drive you specified with the file name you specified. MARCMaker converts files of source records to MARC very quickly--a file of 1000 records will probably convert in about ten seconds.

The source file and the character conversion file are not altered by MARCMaker. The program does not care what type of material the records are for, nor whether the records are bibliographic records, authority records, or any other record type. Record type in MARC is identified by one of the Record Leader values. Since MARCMaker accepts any Leader value for record type, you can create any record type you want. This is just another flexible aspect of MARCMaker.

MARCMaker does have one important limitation to keep in mind. MARCMaker cannot convert source records that lack field 000. If field 000 is lacking, the output MARC records generated by MARCMaker will be corrupted.

Running MARCBreaker to Convert MARC to Text

A file of MARC records can converted to an ASCII (DOS) text file format using the MARCBreaker program. MARCBreaker generates a text file that is formatted the way MARCMaker requires (see the section on the MARCMaker input file above). This can be very useful for importing MARC data to non-MARC systems.

Converting MARC records back to text after conversion to MARC is also a good way to test the integrity of source text files converted by MARCMaker. If you convert text to MARC and then reverse the process with MARCBreaker, you should get a file that looks very much like the text file you used with MARCMaker. If you don't, you should investigate what might be wrong with the text file converted by MARCMaker.

Starting MARCBreaker

Invoke MARCBreaker using the command “marcbrkr” from the drive where the program is located. The command that starts MARCBreaker requires three “parameters” to run: 1) the name of the source file of MARC records to convert; 2) what to name the resulting text file; 3) the name of a character conversion file used to convert special characters to mnemonic strings. Parameters are keyed immediately following the command “marcbrkr” with a space separating each.

Multiple format implementations are supported by MARCBreaker, but only the character set conversion file for converting MARC 21 Latin characters to text is shipped with the basic program files. The third parameter “text21.txt” is normally used, unless you have created a special character conversion file yourself. Press “[ENTER]” after keying in the “marcbrkr” command and three required parameters.

The file extensions “.mrc” and “.txt” are recommended for the source file and converted file, respectively. This makes it easier to differentiate between the source MARC file and resulting text file.

What Happens While MARCBreaker Runs?

During conversion to text, MARCBreaker uses the presence of spaces, hyphens, opening parentheses, and opening curly braces to determine where to break lines when the length of a field exceeds 55 characters. This results in a text file with lines short enough to be displayed and printed on most devices with average size fonts.

The processing of data strings including space-hyphen-hyphen-space ( “ -- ”), common in contents notes, has also been modified to produce a hard return after the final space. MARCBreaker also converts certain spaces to backslashes (e.g., when two spaces occur together, except between the tag and indicators). These new features in MARCBreaker were added to improve the legibility of long fields, especially contents notes.

Certain special characters are converted to mnemonic strings during conversion to text using MARCBreaker. The conversion is based on mappings in the character conversion file referenced by MARCBreaker (normally “text21.txt”). Please note that attempting to modify the character conversion table file may corrupt it. If you do add character mnemonics to the table, keep in mind it must be saved as a DOS file and follow the predetermined syntax of other entries in the table. Modifying this table is only recommended for programmers or people familiar with adjusting text files used by programs as they run.

Once you press “[ENTER]” the program runs and you should quickly find a file of text records on the drive you specified witht the file name you specified. MARCBreaker converts files of MARC records to text more slowly than MARCMaker converts files of text records to MARC records. A file of 1000 records can sometimes take a minute or longer to convert. Much depends on the speed of your computer and the length of the records themselves. The source file is not altered by MARCBreaker. The program does not care what type of material the records are for, nor whether the records are bibliographic records, authority records, or any other record type. The program will also convert virtually any implementation of MARC, as long as the records follow the ISO 2709 record structure. This is just another flexible aspect of MARCBreaker.

Using Word Processing Software to Prepare Input Files

Since MARCMaker was designed to accept files of text in the basic Latin alphabet, input files can be created by vitually all word processors. Most PCs, even in countries that use an alphabet other than Latin, can be used to input basic Latin script.

You can use templates with programs such as WordPerfect and Microsoft Word to greatly facilitate the creation of cataloging records. This is particularly true for the parts of the record that are difficult to key, like the 24-character field 000 (Record Leader) and the 40- character field 008 (Fixed-Length Data Elements). Great use can be made of templates, depending upon the features of the word processor, for other fields as well, for example: field 005 (Date and Time of Latest Transaction) and field 040 (Cataloging Source).

For cataloging agencies with existing files of bibliographic information, merging of existing data with templates using a “mail merge” function can provide a means for not having to rekey bibliographic data to get into the MARC format. New users of these utilities are encouraged to combine their imagination with the power of word processors, database programs, and MARCMaker/MARCBreaker to migrate existing data to the MARC format or to create data from scratch.

Sample MARCMaker Input Records

The following are sample input records formulated to convert to MARC 21 using MARCMaker. Notice the combination of spaces and backslashes used to represent the blanks. The 3-digit tags are separated from the variable field data by two extra spaces that have nothing to do with the indicator positions that begin each variable field. A blank line separates each record. Also notice the particular formatting of the contents note in the second record to help guarantee the use of hard returns at the end of lines. The first record is for printed text (a book), the second record is for a sound recording (CD).

Example of two bibliographic records before conversion by MARCMaker

=000  00000nam\\2200000\a\4500
=001  0123456789
=003  NjP
=005  19930422091534.7
=008  920806s1991\\\\nju\\\\\\\\\\\000\0\\eng\d
=020  \\$a0777000008
=040  \\$aNjP$cNjP
=100  1\$aSmith, John W.,$d1955-
=245  10$aPolitical tides in America /$cby John W. Smith III
 ; with an introduction and commentary by Spencer Yarborough.
=260  \\$aCamden, NJ :$bTrendsetter Press$c1991.
=300  \\$a344 p. :$bill., maps ;$c26 cm.
=650  \7$aPolitical science$zUnited States.$2lcsh
=650  \7$aPopulism$zUnited States.$2lcsh
=700  1\$aYarborough, Spencer,$d1931-


=000  00000njm\\2200000\a\4500
=001  rb1993000850
=003  VaArRKB
=005  19930903074500.0
=008  930903s1987nyu|||\\\|\\\\\\\\\\eng\d
=028  02$a9 61114-2$bElektra
=040  \\$aVaArRKB$bVaArRKB
=100  1\$aCole, Natalie.
=245  10$aEverlasting$h[sound recording].
=260  \\$aNew York, NY :$bElektra Entertainment,$cp1987, c1991.
=300  \\$a1 disc (55 min.) :$bdigital, stereo ;$c4 3/4 in.
=500  \\$aCompact disc.
=505  0\$a 1. Everlasting -- 2. Jump start -- 3. The urge to merge
 -- 4. Split decision -- 5. When I fall in love -- 6. Pink Cadillac
 -- 7. I live for your love -- 8. In my reality.
=650  \4$aSoul music.

Character Mnemonics Supported by MARCMaker in “marc21.txt”

MARCMaker converts any mnemonic string found in a special character conversion file (see the list of characters in the default character mnemonics file) to its hexadecimal equivalent. The mnemonic strings presented in the list at the link above are the most commonly needed for Latin script information. The character values in the left-hand column in the file are converted to the hexadecimal values in the second column. Equivalent decimal values are shown in the third column. The name of the character is given in the column on the far right.

The structure of the mnemonic string file is very important, which is why changes to it must be made with great care. It is possible to prevent MARCMaker from converting a character value by removing the hexadecimal and decimal values from the second and third columns. If no hexadecimal and thus no decimal equivalent are given in the file, the mnemonic is not converted.

If during conversion MARCMaker does not find a matching mnemonic string, the style of the string is changed to replace the curly braces with SGML-style entity reference delimiters “&” and “;”. For example, the mnemonic string “{cross}”, which is not in the mnemonic string file, would be converted to “&cross;” in the output MARC file.

MARCBreaker uses a different table to convert characters in MARC 21 records to mnemonics, but follows much the same logic. At present, MARCBreaker only converts non-ASCII characters to mnemonic strings. Depending upon the local (national) character set used), modifications to both “marc21.txt” and “text21.txt” may be needed.

If You Have Problems...

Whenever you use software, there is the possibility of problems and/or unexpected results. If MARCMaker or MARCBreaker do not work as you expect, we recommend you check the section of this manual that deals with the program you are using.

In most cases, these programs do not work because the formatting of the input files is incorrect. Be sure that the input formatting of the data you are giving to the program is correct. MARCMaker requires a very specific input file format in order to work properly. Any failure to provide the required formatting in the input text file can cause problems. MARCBreaker, likewise, requires a very specific input file format, namely MARC (ISO 2709). If MARCBreaker does not work properly, the input file may not be a MARC file.

If you are unable to identify the problem you are having with either program, you may contact the Library of Congress, Network Development and MARC Standards Office (NDMSO). NDMSO provides some support for users of these utilities, although resources are limited. It is recommended that you contact:

Network Development and MARC Standards Office
Library of Congress
101 Independence Avenue, S.E.
Washington, DC 20540-4402 U.S.A.
TEL: +1-202-707-5118
FAX: +1-202-707-0115
EMAIL: ndmso@loc.gov

Downloading MARCMaker and MARCBreaker

MARCMaker and MARCBreaker are available free of charge from the Library of Congress. In addition to the conversion programs and character set mapping files, test files are also available. You may download the files using the links provided below.

At the present time, only the DOS/Windows 95/98/ME/2000/XP version is available.

MARCMaker and MARCBreaker Program Files

Character Conversion Files

In order to run MARCMaker and MARCBreaker, special character set conversion files must be available to the programs as they run. You must have copies of these files to run the programs.

Test files

The four files listed below may be used for testing and experimentation with MARCMaker and MARCBreaker. There are two test files for each of the software programs.

Go to:

Library of Congress

Library of Congress Help Desk (February 12, 2008)