DATE: Dec. 3, 1999
NAME:Definition of Subfield $z (Numbering scheme) in Fields 853-855 (Captions and Patterns) of the MARC 21 Holdings Format
SOURCE:Library of Congress; CONSER Publication Pattern Task Force
SUMMARY:This paper proposes the adoption of a new subfield in fields 853-853 of the holdings format that will assist in characterizing the attributes of enumeration levels. It contains coded values to indicate whether the numbering scheme is expressed as Arabic numerals, Roman numerals, or Alphabetics.
KEYWORDS:Field 853-855 (HD); Captions and Patterns (HD); Numbering scheme (HD); Subfield $z, in field 853-855 (HD)
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.
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 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 whether the numbering scheme is expressed as Arabic numerals, upper or lower case Roman, or upper or lower case alphabetic letters. 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.
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. 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.
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. Option 1
One option is to consider the definition of the following values to characterize the numbering scheme used:
a Arabic numeral b Lower case alphabetic c Upper case alphabetic d Lower case Roman numeral e Upper case Roman numeralSubfield $z would follow each enumeration level to which it applies. Arabic numeral could be assumed if no coding is supplied.
Thus, the 853 for The Chronicle of Higher Education might read:
$a v. $z e $b no.$z a $u 49 $vrThis coding indicates that the first level has upper case Roman numerals and the second level has Arabic numerals. Alternatively, we may only need to specify the departures from Arabic and consider the latter to be the default.
2.3. Option 2
Although the above option is simple and easy to use, it may be argued that it combines script issues with type of numbering and does not easily accommodate non-Roman scripts. Another alternative is to use a two or three character code. The first position would indicate the numbering scheme and the second and third would indicate the script (if an alpha numbering scheme) or type of number (if a numeric scheme).
A draft international standard, Code for the representation of names of scripts (Committee Draft ISO 15924:1999) has been developed to code for names of scripts. Three options are provided: a three-character code, a two-character code, and a numeric code. Although this standard is 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. For instance "la" is used for Latin.
In order to indicate both the numbering scheme and the script (if alpha) or type (if numeric, the following might be defined:
1st position a Lower case alpha b Upper case alpha c Lower or no case numeral d Upper case numeral 2nd and 3rd positions 2-character script code if 1st position is an alpha (code a or b) Use ISO 15924 two-character code Type code if 1st position is a numeric (code c or d) a Arabic r RomanExamples:
$z ala (for lower case alpha, Latin script) $z dr (for upper case Roman numeral) $z bar (for upper case alpha in the Arabic script)Alpha schemes would use three characters; numeric schemes would use two characters as data in the subfield.
3. PROPOSED CHANGES
In the MARC 21 Holdings Format:
a Arabic numeral b Lower case alphabetic c Upper case alphabetic d Lower case Roman numeral e Upper case Roman numeralOption 2.
1st position a Lower case alpha b Upper case alpha c Lower or no case numeral d Upper case numeral 2nd and 3rd positions 2-character script code if 1st position is an alpha (code a or b) Use ISO 15924 two-character code Type code if 1st position is a numeric (code c or d) a Arabic r Roman
4.1. The values in the publication pattern subfields may be used for collapse functions as well as prediction. Will the definition of this subfield have any impact on a systems' ability to manipulate data?
4.2. If Option 2 is selected, will it be necessary to indicate script used for numeric schemes (e.g. numbers written in another script)? The assumption here is that only a type code would be needed for numerals. Since Arabic numerals are not really written in the Arabic script, this could be a problem.