PROPOSAL NO.: 2000-01R

DATE: Dec. 3, 1999
REVISED: May 10, 2000

NAME:Definition of Subfield $z (Numbering scheme) in Fields 853-855 (Captions and Patterns) of the Holdings Format

SOURCE:Library of Congress; CONSER Publication Pattern Task Force

SUMMARY:This paper proposes the adoption of a new subfield in fields 853-855 of the holdings format that will assist in characterizing the attributes of enumeration levels. It contains coded values to indicate how the numbering scheme is expressed (as alphabetic or numerics, upper, lower, or no case, script used or type of numeral).

KEYWORDS:Field 853-855 (HD); Captions and Patterns (HD); Numbering scheme (HD); Subfield $z, in field 853-855 (HD)

STATUS/COMMENTS:

12/3/99 - Forwarded to the MARC Advisory Committee for discussion at the January 2000 MARBI meetings.

1/15/00 - Results of MARC Advisory Committee discussion - Rejected. Option 2 was preferred because it allowed for more flexibility. A new proposal will be prepared for the annual meeting. Changes to Option 2 should include:

2/11/00 - Results of LC/NLC review - Agreed with the MARBI decisions.

5/10/00 - Paper revised and forwarded to the MARC Advisory Committee for discussion at the July 2000 MARBI meetings.

7/8/00 - Results of MARC Advisory Committee discussion - Approved as amended.

7/27/00 - Results of LC/NLC review - Agreed with the MARBI decisions.


PROPOSAL NO. 2000-01R:Definition of subfield $z (Enumeration scheme)

1. BACKGROUND

The MARC 21 Format for Holdings Data includes a block of fields and subfields that are intended to contain publication pattern information. These content designators are intended to allow for automated check-in and prediction of issues to be received. Systems use the parsed data in fields 853-855 (Captions and Patterns) to predict the next issue to be received so that the operator can determine that a claim needs to be submitted for a missing issue or whether there is a publishing gap.

In fields 853-855, various levels of caption information are captured in subfields $a through $h. Publication pattern information is contained in subfield $u through $y. Subfield $u (Bibliographic units per next higher level) contains a number that specifies the total number of parts that comprise the next higher level of enumeration. Subfield $v (Numbering continuity) tells whether or not a level's enumeration increments continuously or re-starts. Subfield $w contains a code or number that indicates the publication frequency of the item. Subfield $x contains numeric codes indicating the chronological point at which the next higher level increments or changes. Subfield $y contains codes that describe the regularity of the publishing pattern coded in subfield $w and may be repeated to indicate regular exceptions.

Since enumeration may be expressed in different ways using different schemes, an element is needed to characterize the kind of values to be found at a given level of enumeration. Specifically, it is necessary to indicate how the numbering scheme is expressed: as alphabetics or numerics; upper, lower, or no case; script used or type of numeral. Since serial issues for research collections have enumeration values described by these attributes, it is critical that they are understood and represented correctly without Arabic translations. This element is related to a given level of enumeration and may be different at different levels.

Proposal No. 2000-01 was discussed at the January 2000 MARC Advisory Committee meetings and presented two options to accommodate numbering scheme in the MARC 21 Holdings Format. Option 1 was the definition of subfield $z to contain one of five possible coded values: a (Arabic numeral), b (Lower case alphabetic), c (Upper case alphabetic), d (Lower case Roman numeral, e (Upper case Roman numeral. Option 2 was a more complex solution to include three character positions. The first would identify lower case alpha, upper case alpha, lower or no case numeral, or upper case numeral; the second would include a two-character script code if an alpha or a type code for Arabic or Roman if a numeric.

Discussion of the paper revealed a preference for Option 2 because it allowed for more flexibility. It was requested that LC submit a new proposal to allow for the ability to indicate script, to deal with an alphanumeric numbering scheme and to consider having the data in a fixed length.

2. DISCUSSION

2.1. Numbering scheme and issue prediction

System vendors currently support these numeric scheme characterizations in their issue prediction engines, since they are critical to an understanding of the description of the issue in hand. The data recorded as holdings in fields 863-865 (Enumeration and Chronology) indicate the enumeration scheme implicitly and numbers are converted to Arabic numerals for items held. However this is not sufficient for automated prediction, because the system needs to know what the numbering scheme is of the next item expected, rather than the item held. An example is the Chronicle of Higher Education, which uses a Roman numeral at the first level of enumeration and an Arabic numeral at the second level. When transmitting claims or recording holdings for this journal, it is important to understand the issue description as "Volume XL, Number 13" rather than some translated analog like "Volume 40, Number 13". The issue should be described in the exact fashion in which it appears so that the numbering of the next issue may be accurately predicted. Currently there is no way in the format to indicate the numbering scheme.

Numbering may also be expressed in alternate scripts, whether an alphabetic or numeric character. For example, the serial title Majallat Jâmi'at Dimashq fî al-'ulûm al-insânîyah (LCCN: 98-548088) has its numbering in Arabic script.

CONSER is initiating an experiment to support the exchange of 85X/86X pattern information for serials nationally via OCLC records. It is important that pattern descriptions be as complete as possible if they are to be truly helpful. Vendors who support issue prediction in their check-in systems are already supporting the recording of these numeric schemes in some fashion. Subfield $z is proposed so that there is a standard method for communicating this information. This subfield has been chosen because of its proximity alphabetically to the other publication pattern subfields $u through $y in fields 853-855.

It is proposed that a subfield $z be defined in fields 853-855 for Numbering scheme. It would be a repeatable subfield to allow for recording different numbering schemes at different levels of enumeration.

2.2. Definition of six character positions

A six character code string could be used to designate the numbering scheme used on a publication.

1st position ($z, position /00) Type of designation
a number
b letter
c combined, number first
d combined, letter first

The first position would indicate the whether the numbering is a number, letter or combined (number first or letter first). Combined should only be used when one of the elements is a constant designation (e.g. 1a, 2a, 3a), rather than actually two different levels of enumeration (e.g. 1a, 1b, 1c).

2nd position ($z, position /01) Case
a no case
b lower case
c upper case

This position is applicable if a numbering scheme is conveyed as alphas and applies both to those coded in the previous position as "b" or to Roman numerals. Although it was suggested that it be considered whether or not it is necessary to identify case, it is included because some vendors have distinguished and including it would facilitate mapping previous data. However, it is not clear whether this distinction is necessary, since systems probably process and sort cases the same.

3rd-6th positions ($z, positions /02-/05) Script or type code
Script code (4-character code from ISO/DIS 15924)
(e.g. latn=Latin; arab=Arabic; grek=Greek)
Type code (for numerals that are not in alternate scripts and coded with script codes, e.g. Roman numerals)
an## Arabic numeral
rn## Roman numeral

A draft international standard, Code for the representation of names of scripts (ISO/DIS 15924) has been developed to code for names of scripts. Two options are provided: a four-character code and a numeric code. Note that the previous version of this draft standard (ISO/CD 15924) that was considered as part of Proposal No. 2000-01 included a two-character script code. A later version (ISO/DIS 15924) calls instead for a four-character code. Although this standard is currently only a draft, the codes could be used in the proposed subfield $z to indicate the script. Most likely only a small number of these would be needed for coding publication patterns.

There could be defaults if the numbering scheme is Latin script or Arabic numeral (i.e. the last two positions could be omitted in these cases). For those that use a type code instead of a script code, the last two character positions will use blanks.

2.3. Examples (blanks indicated by "#")

DescriptionOn pieceSubfield $z
Arabic numeralv. 5aa or aaan##
Lower case alphano. a bb or bblatn
Upper case alphav. Bbc or bclatn
Lower case Roman numeralv. ixabrn##
Upper case Roman numeralVII acrn##
Alternate script numeral (Arabic)Image of serial title pageaaarab
Combined numberingv. 1acb or cblatn


3. PROPOSED CHANGES

In the MARC 21 Holdings Format:


Go to:


Library of Congress
Library of Congress Help Desk (01/26/01)