NAME: Coding of Exceptions to Regularity Patterns in Field 853-855 in the USMARC Holdings Format
SOURCE: The Library Corporation
SUMMARY: This paper explores the coding of regularity patterns in the USMARC Holdings Format and the current difficulties in coding exceptions. It proposes two options: 1) the definition of a new subfield $r in the field to code for exceptions or 2) making subfield $y repeatable.
KEYWORDS: Subfield $y, in field 853-855 (HD); Subfield $r, in field 853-855 (HD); Regularity pattern (HD); Regularity exception (HD)
RELATED: 92-22 (June 1992)
STATUS/COMMENTS:
5/1/98 - Forwarded to the USMARC Advisory Group for discussion at the June 1998 MARBI meetings.
6/27/98 - Results of USMARC Advisory Group discussion - Approved Option 2.
Many participants did not feel strongly about one over the other option. Option 2 seemed cleaner
because one would not have to determine which pattern is the exception and which is the rule, but
could simply indicate that more than one pattern exists within the publication. Since the publication
code can use "o" for omitted, subfield $y can accommodate an exception to a regular pattern either in
terms of omitted issues or in terms of a different publication pattern with different chronology codes.
7/29/98 - Results of LC/NLC review - Agreed with the MARBI decisions.
PROPOSAL NO. 98-08: Exceptions to Regularity Patterns in Fields 853-855
1 BACKGROUND
The USMARC Holdings Format is used not only to detail a library's holdings, but also for systems to automate check-in and prediction of items. The latter functions are primarily accomplished through the information contained in field 853-855 (Captions and Patterns), subfields $u (Bibliographic units per next higher level), $v (Numbering continuity), $w (Frequency), $x (Calendar change), and $y (Regularity pattern). Together these subfields allow for a system to be able to predict when the next issue is due and what the volume/numbering of that next issue will be.
Proposal No. 92-22 (Additional Changes to Subfield $y (Regularity) in Fields 853-855 of the USMARC Holdings Format) proposed changes to subfield $y to code for additional patterns and exceptions which were not accommodated by the specifications. It defined new pattern codes, proposed making subfield $y repeatable, proposed a new publication code for combined issues, and made the regularity codes an agency defined element maintained at LC. The proposal was approved in part, but the proposal to make subfield $y repeatable and to define "c" (Combined) as a new publication code was not approved. It was felt that making subfield $y repeatable brought up questions about when the subfield should be used for that purpose and when the field should be repeated. Participants questioned whether it would assist in reducing ambiguity or add to it.
Over the last few years there have been numerous occasions when software developers have questioned the ability to code for all types of regularity patterns in their development of library acquisition and control systems. They need to be prepared for any circumstance and the format needs to communicate regular exceptions to regularity patterns. Since subfield $y is not repeatable, it is only possible to give one regularity pattern or one exception.
2 DISCUSSION
2.1 Regularity pattern codes Subfield $y of field 853-855 contains codes that describe the regularity of the publishing pattern coded in subfield $w (Frequency). The subfield is structured as follows:
<Publication Code><Chronology Code Definition><Chronology Code>,<Chronology Code>,...
The subfield may contain one or more chronology codes that are associated with the publication code and chronology code definition that are in the first and second character position of the subfield.
2.2 Publication code
Currently the holdings format defines two possible codes in the Publication code portion of subfield y (the first element of the subfield). These are: "p" for published and "o" for omitted. Code "p" means that the subfield contains a list of the issues published during the period, and code "o" means that the subfield contains a list of issues that are omitted during the period. Subfield y could become quite lengthy if the published issues are explicitly indicated; code "o" may serve to shorten the subfield when it is appropriate to use it. However, since the subfield is not repeatable and only one publication code/chronology code pair can be given, both a regular pattern and an exception to that pattern cannot be coded.
2.3 Chronology code definition
The second one-character code (chronology code definition) in the field determines how to process the subsequent chronology code(s), i.e. whether it represents the name of a day, numeric month or month and day, season, week of month, etc. Only one publication code/chronology code definition may be given.
Consider a serial publication which is published once a month in some months and twice a month in others. The issues are designated as follows:
Jan. Feb. 1 Feb. 15 Mar. Apr. May June 1 June 15 July Aug. Sept. Oct. 1 Oct. 15 Nov. Dec.There is currently no way to code this accurately in subfield $y, since the chronology code definition cannot be repeated, and some chronology codes will be month of year codes and others month and day codes. It could be coded with all month and day codes as follows:
Example 1
853 02$81$av.$bno.$u15$vr$i(year)$j(month)$k(day)$wm$x01
$ypd0101,0201,0215,0301,0401,0501,0601,0615,0701,0801,0901,1001,1015,1101,1201
This would not be entirely accurate in recording chronology, since only some issues actually use a day in the numbering designation. If subfield $y were repeatable, two publication code/chronology code definition/chronology code strings could be given.
2.4 Exceptions to regularity patterns
Consider a serial publication that is monthly, published every second Wednesday of the month except in April when it is published on the second Thursday and May, when it is published on the first Wednesday. The only way to code it currently is the following:
Example 2
853 03 $av.$bno.$u12 $vr $i(year) $j(month) $wm $x01 $ypw02we,0402th,0501we
The above coding is not accurate, because it indicates that the item is published every Wednesday in addition to the second Thursday in April and the first Wednesday in May instead of showing the latter two as exceptions.
Alternatively, it could be coded to show all issues that are published:
$ypw0102we,0202we,0302we,0402th,0501we,0602we,0702we,0802we,0902we,1002we,1102we,1202 we
However, consider what the content of the subfield would look like for a daily or weekly publication if the only way to code exceptions is to include all issues published in a non-repeatable $y.
2.5 Defining a new subfield for exceptions
It would be useful to either make subfield y repeatable or define a new subfield for exceptions, so that regular exceptions to regular patterns could be indicated. For instance, consider the serial Booklist (ISSN 0006-7385), which is published bimonthly on the first and fifteenth of the month except it is monthly in July and August. To show the published issues one would use subfield y as follows:
Example 3
853 $ypd0001,0015
(published on days 1 and 15)
Since the subfield is not repeatable there is no way to indicate the changed frequency in July and August. In the discussion of the previous proposal that suggested making subfield $y repeatable, there was concern that there would be confusion between what was the rule and what was the exception and thus possible increased ambiguity. A new subfield could provide an unambiguous place to record exceptions; it would always need to be considered in the context of the data in subfield $y. The same codes used in subfield $y could be used in subfield $r. If a new subfield $r were defined, example 2 above could be coded as follows:
Example 2
$ypw02we $rpw0402th,0501we
[Note that if the publication were issued on the second Thursday of April and first
Wednesday in May IN ADDITION to every second Wednesday, it would be coded as follows:
$ypw02we,0402th,0501we]
The publication Booklist could be coded as follows:
Example 3
853 $ypd01,15 $rpm07,08
Another example is PC Magazine (ISSN 0888-8507), which is published bimonthly on the last and third to last Tuesday of each month, except in July and August, when it is published monthly. If this option is approved, it could be coded as follows:
Example 4
853 $ypw99tu,97tu $rpm07,08
[99tu indicates last Tuesday; 97tu indicates third to last Tuesday.]
2.6 Making subfield $y repeatable
Example 1 above shows a case where there are two regular patterns, and two sets of publication code/chronology code definition/chronology code strings are needed. It may be difficult in some cases for the person encoding the data to determine which belongs in the exception subfield and which in the regularity subfield if a new subfield for regularity exceptions were available. If subfield $y were repeatable, in cases where more than one chronology code definition is necessary to interpret the codes, this situation could be coded as follows:
Example 1
853 $ypm01,03,04,05,07,08,09,11,12 $ypd0201,0215,0601,0615,1001,1015
Optionally, examples 2 through 4 could contain a second subfield $y instead of $r if subfield $y were made repeatable.
2.7 Coding date specific holidays It is currently not possible to code for the publication or omission of a date-specific holiday (e.g. July 4th) or a moveable feast (e.g. Thanksgiving Day in the U.S.) because of the inability to record more than one publication code/chronology code definition/chronology code string in subfield $y. It is not unusual for a publication to have a specific regularity pattern but if the publication date falls on a given holiday, that issue is omitted. Consider the following example: a publication is published every Monday and Thursday except for when New Years Day, the fourth of July, Labor Day, Thanksgiving and Christmas fall on a Monday or Thursday. This situation cannot currently be coded because it is necessary to combine more than one publication code/chronology code definition/chronology code string, since New Years' Day, fourth of July, and Christmas would use the day chronology code definition, and Labor Day and Thanksgiving Day would use the week chronology code definition. If subfield $r were defined for exceptions it could be coded as follows:
Example 5
$yp00mo,00th $rod0101,0704,1225 $row0901mo,1199th
[First $y indicates every Monday and Thursday; first $r indicates Jan. 1st,
July 4th, Dec. 25th; second $r indicates the first Monday in September (using
day of week code) and the last Thursday in November.]
Optionally, with a repeated subfield $y it could be coded as follows:
Example 5
$ypw00mo,00th $yod0101,0704,1225 $yow0901mo,1199th
3 PROPOSED CHANGES
In the USMARC Holdings Format:
Library of Congress