The Library of Congress >> Especially for Librarians and Archivists >> Standards

MARC Standards

HOME >> MARC Development >> Proposals List


MARC PROPOSAL NO. 2006-05

DATE: Dec. 16, 2005

REVISED:

NAME: Changes to Holdings data fields to accommodate ONIX for Serials in the MARC 21 Holdings Format

SOURCE: Library of Congress

SUMMARY: This paper proposes three changes to allow for compatibility with ONIX for Serials. They include 1) the addition of subfield $o (Type of material) in fields 853 and 863, equivalent to subfield $o in 854-855 and 864-865; 2) the addition of subfield $2 in 853-855 to designate an authoritative source for caption abbreviations used in subfields $a through $h; and, 3) the addition of subfield $r for language of caption information.

KEYWORDS: Field 853-855 (HD); Subfield $o, in field 853 (HD); Subfield $o, in field 863 (HD); Caption and Pattern Fields (HD); Enumeration and Chronology Fields; Name of Unit (HD); ONIX Serial Release Notice; Subfield $2, in fields 853-855 (HD); Subfield $r, in fields 853-855 (HD)

RELATED: 2001-DP07

STATUS/COMMENTS:

12/16/2005 - Made available to the MARC 21 community for discussion.

01/22/06 - Results of the MARC Advisory Committee discussion - Approved in part. The first two parts were approved (subfield $o and subfield $2). Subfield $2 (Source of caption abbreviation) in fields 853-855 is repeatable to allow for other abbreviation schemes to be used and identified. For Part 3, LC will reconsider whether to repropose subfield $r for Language of caption in fields 853-855 or whether the code in field 008/22-24 (Language) suffices.

03/07/06 - Results of LC/LAC/BL review - Approved

----------------------------------------------------------------------------------------------------------------

Proposal No. 2006-05: Changes to Holdings data fields to accommodate ONIX for Serials

1 INTRODUCTION

The ONIX (Online Information Exchange) family of standards were intended for communicating rich product information about books and other related material. Initially it was developed through the efforts of book publishers and other stakeholders in the book industry, especially for communicating information between publishers and online booksellers. Recently ONIX for Serials was developed as a similar standard for serials by a joint committee under the sponsorship of EDItEUR (the developer of ONIX) and NISO (National Information Standards Organization). The NISO/EDItEUR Joint Working Party for the Exchange of Serials Subscription Information (JWP) has developed a specification and is experimenting in pilot projects to demonstrate the feasibility of using ONIX for Serials as an exchange format for serials subscription information.

ONIX for Serials is a series of draft standards in XML format for communicating metadata about serial publications and subscription information. There are three different formats for use in various situations. Serials Products and Subscriptions (SPS) format conveys product information on serial resources along with (optionally) details of the specific subscriptions held by one or more subscribing parties. The Serials Online Holdings (SOH) format conveys summary holdings information about online serial resources from suppliers (such as online hosting services, agents or publishers) to subscribing libraries, showing the online holdings of a particular subscribing organization. The Serials Release Notice (SRN) supports information exchanges about the publication or electronic availability of one or more serial releases (i.e. issue level), primarily used by publishers, content hosting services, A&I services, subscription agents, etc. It is certain data used in the Serial Release Notice and Serials Online Holdings which is the focus of this paper.

ONIX for Serials was strongly influenced by the MARC 21 Format for Holdings Data. The committee attempted to specify structures that can be mapped to MFHD so that holdings and coverage information supplied in ONIX messages can be loaded into MARC-based library systems. It is expected that ONIX SRN and SOH messages will be used to update serial holdings in ILS and ERMS systems. This could save libraries considerable resources in that setting up patterns for predictive check-in is highly labor intensive. Getting the information from publishers would be more efficient. However, there are a few data elements included in the Serial Release Notice that do not have MARC equivalents. In addition to this proposal, there will be additional papers discussing other data elements that are needed in MARC 21 Holdings.

2 DISCUSSION

2.1 Type of unit in 853/863

2.1.1 Background. How to record a title associated with a specific issue or component part of a serial publication has been unclear in the MARC 21 holdings format, and has been discussed by the MARC Advisory Committee. In these cases, the title is only the title of a part, not the title of the bibliographic unit represented by a cataloging record.

Initiated by the CONSER Publication Pattern Task Force, Discussion Paper 2001-DP07 addressed the issue as to whether subfield $o (Type of unit) should be defined in fields 853 and 863 for the basic bibliographic unit, complimentary to subfield $o in fields 854/864 and 855/865 (Type/title of supplementary material and Type/title of index).

A separate field 844 was originally defined to accommodate the "Name of Unit" element in the then ANSI/NISO non-serial holdings standard, although it is also applicable to titles of component parts of serials. Using this field at the record level rather than related to a specific caption and pattern field forces the creation of separate holdings records, since field 844 applies to the entire record and the specific title may only be applicable to the basic unit. Subfield $o is currently only defined in fields 854/864 and 855/865 for supplementary material and indexes, not for the basic bibliographic unit (i.e. 853/863). Participants in the CONSER Publication Pattern Task Force wanted to make subfield $o available for the basic bibliographic unit (in fields 853 and/or 863) for component part titles. This would allow for specifying the distinctive names of units that go with particular 863s but that do not apply to the whole title, as does the record level 844.

In the discussion of the paper, there was no clear consensus on whether to use either subfield $o or field 844; many participants preferred using both data elements for different situations. The participants also felt that field 844 should be used for both serial and non-serial publications (it was originally defined for an element in the non-serial holdings standard). It was noted that the use of subfield $o in 853/863 could be confusing because usually repetition of the field implies a change in pattern rather than indication of a unit name. For the CONSER Publication Pattern initiative a local convention (in field 891, which OCLC used for encoding the publication pattern information) was chosen to accommodate the information. In holdings records, some users are putting the distinctive titles in subfield $z for lack of a subfield $o.

2.1.2. Type of unit and Serial Release Notice. It is more frequent that an index or supplement has a distinctive unit name, but not uncommon that a basic bibliographic unit might. When a name of unit remains constant for some portion of a serial run and does not increment with each issue, it should not be considered part of the enumeration, although it has been coded that way as a work around, since there is no $o in 853/863. In such cases, it would not be appropriate to use field 844 for the Name of unit, since it does not apply to the entire serial, but only to some portion of it brought out in the holdings data fields (853-868).

The ONIX Serial Release Notice (SRN) contains a data element "Named Unit" defined as follows:

"Text naming a unit in the enumeration hierarchy that has no associated sequence numbering. Used, for example for New Series or its equivalent; or in some legal publications where one level of the enumeration hierarchy identifies a particular piece of legislation, eg Title 42, where the number does not relate to a sequence of serial parts."

Consider the following example. Code of federal regulations (LCCN sn 91035510) contains a section entitled 12, Banks and Banking which itself has enumeration parts 1-199. The number 12 is part of the unit name, which remains constant for many issues. See: [scan the title page and make available]. In this case, there is one bibliographic record for the title Code of federal regulations and Banks and banking would not be used in field 844, since it is related to the caption, and is not a title at the holdings record level. It would be appropriate to consider it part of field 853/863, since it is a named unit at the basic bibliographic unit level. Thus, if subfield $o were available, the holdings data would be expressed as:

853 $aParts $i(year) $j(month) $k(day) $o12, Banks and banking

863 $a1-100 $i2004 $jJan. $k01

Note that in MARC 21 subfield $o in fields 854-855 is not repeatable. It is desirable to allow repetition, since there could be more than one name of unit applying to a level of enumeration (as in the example above). This applies both to a new subfield $o in 853/863 and the existing in 854-855 (and 864-865).

The ONIX Serial Release Notice would handle this as a named unit in the enumeration, since the number does not relate to a sequence of serial parts. There is a tag <NamedUnit> under <Enumeration><Leveln>.

As noted, a distinctive title for a supplement or index is quite common, and may be encoded in subfield $o (unless there is a separate cataloging record for the supplement or index itself, in which case it could be in 844). In SRN <NamedUnit> is used for this element. It is desirable to use a discrete element both in SRN and in MARC 21, whether it is part of the basic bibliographic unit, a supplement or index.

Another example is Journal de mathématiques pures et appliquées (LCCN 44015744), which has an issue as follows:

166e année, 9e série, Tome 80, Fascicule 2, mars 2001

The designation "9e série" does not increment, but stays the same for about 70 years, and thus would be considered a named unit. In the absence of 853$o, it would have to be concatenated to the first level of enumeration (année) , although that is a workaround. Currently it would be coded as:

853 20 $81 $a9e série & année $bt. $u1 $vc $cfasc. $u12 $vr $i(year) $j(month) $wm

863 41 $81.1 $a166 $b80 $c2 $i2001 $j01

If subfield $o were available it would be coded as:

853 20 $81 $a année $bt. $u1 $vc $cfasc. $u12 $vr $o9e série $i(year) $j(month)$wm

863 41 $81.1 $a166 $b80 $c2 $i2001 $j01

2.2 Captions in SRN and MARC 21

2.2.1 Caption abbreviations. Fields 853-855 contain captions that identify the enumeration and chronology levels. These are input according to the captions indicated on the piece. Abbreviations may be used, e.g. "v." for "volume". The MARC 21 Holdings Format states that the abbreviations used in subfields $a-$h are recorded according to the Anglo-American Cataloging Rules.

As the MARC 21 formats are adopted widely internationally and using various rules, it is desirable to allow for other abbreviation schemes. Many fields in MARC 21 use subfield $2 to indicate source of some data within the field. It would be appropriate to define subfield $2 in holdings fields 853-855 for this purpose to allow for other abbreviation schemes to be used and identified.

SRN treats abbreviated captions differently than in MARC, giving more flexibility for using captions from other languages. It includes the following elements under each level of enumeration:

<Unit language="">

<UnitAbbr>

Example:

<Unit language="ger">Jahrgang</Unit>

<UnitAbbr>Jahrg.</UnitAbbr>

It does not cite the source of abbreviation, although such information might be useful both in SRN and MARC 21. The use of this subfield would be optional, especiallly since publishers are not likely to include this information in SRN. However, it might be useful for non AACR2 users of the MARC 21 formats.

2.2.2 Language of captions. In addition to the need to provide information about the source of the abbreviation in the caption and pattern fields, the format could be enhanced to allow for specifying the language of the captions at the field level. Some institutions may want captions in a specific language, and this would facilitate automatic translation. The entire holdings record may be coded in field 008/22-24 to indicate the language of coded data. The format states that this allows for a language table to generate chronological terms or ordinal numbers for the codes in a display of the holdings statement. However, this applies mainly to coded data in the chronology subfields, for example to display "janv." for a month coded as "01" when 008/22-24 is coded "fre" for French. Since SRN includes information about the language of the caption at each enumeration level, in the absence of such a data element in MARC 21, this information would be lost when converting a serial release notice to a MARC 21 holdings record.

Subfield $q, $r, and $s are currently available in fields 853-855 and $r is available in 863-865. Subfield $r could be defined to include the language code. Since ISO 639-2 is used in 008/22-24 (and in SRN), it is appropriate to specify the use of ISO 639-2 in this subfield. The subfield could be repeatable in case of the unusual situation of mixing different languages for different enumeration levels (and it is repeated in SRN for different levels).

3 CURRENT DEFINITION OF FIELDS 853-855

Fields 853-855 are defined as follows:

Fields 863-865 are defined as follows:

4 PROPOSED CHANGES

In the MARC 21 Holdings Format

In the MARC 21 Holdings Format

In the MARC 21 Holdings Format

5 Additional information

For further information on ONIX for Serials see:

Serials Products and Subscriptions (SPS): http://www.editeur.org/18/Current-Releases/

Serials Online Holdings (SOH): http://www.editeur.org/18/Current-Releases/

Serials Release Notification (SRN): http://www.editeur.org/18/Current-Releases/


HOME >> MARC Development >> Proposals List

The Library of Congress >> Especially for Librarians and Archivists >> Standards
( 12/21/2010 )
Legal | External Link Disclaimer Contact Us