Here’s the revised text of the 008/21 and 008/33 proposal, incorporating suggestions by Kathy and Matthew:
Draft Statement on the Transposition/Arrangement and
Presence/Absence of Parts Positions of the 006 and 008 Fields
Background
At the 2008 Newport meeting of the MARC Formats Subcommittee, it was the sense of both the Subcommittee and some of the visitors present that the Bibliographic Control Committee should issue an official statement regarding the transposition/arrangement and presence/absence of parts bytes of the 006 and 008 fields. These bytes were included in Proposal no. 2002-14/3:008/21 and Proposal no. 2002-14/4: 008/33 (Music), available at http://www.loc.gov/marc/marbi/2002/2002-14.html. These proposals were made as concessions to the British cataloging community, which uses these bytes. However, since there is no consensus among U.S. and Canadian catalogers on how these fields should be used, their inclusion posed the potential for some confusion and inconsistency among shared records.
Recommendations
In the sound recordings format, the OCLC defaults for positions 008/21 (parts) and 008/33 (transposition/arrangement) are both “n” (not applicable), since these bytes can only be applied to notated music. In the scores format, the defaults are blank for both positions. Since both positions are optional, these are the only logical defaults. Also, some confusion has been expressed regarding the meaning of the presence/absence of parts byte; and this recommendation is in part to allay such confusion by recommending that the position not be coded.
The MARC Formats Subcommittee recommends that the OCLC defaults be used for these bytes. Reasons for this include inconsistent coding in USMARC 008/21, based on differing interpretations of the coded values, which led to this byte becoming obsolete in USMARC in 1988. U.S. and Canadian cataloging records did not include this information from 1988 to 2002. The Music Library Association feels that there are currently better ways for online catalogs to retrieve records with or without parts, especially since dependence on coded data for retrieval has lessened considerably since 1988. Also, U.S. and Canadian catalogers did not have the ability to code arrangement/transposition at all until 2002; and there is no perception among that community that providing these values would help catalog users in record retrieval.
I confess to some surprise when fixed fields for parts and arrangements/transposition turned up in the scores workform. If there was any discussion in advance, I either missed it or it was so uninformative that I have forgotten it. In any case, I dutifully filled in those fields until I recognized that our Sirsi ILS has not upgraded its database to include them. They simply get stripped from the record when it’s imported. Until I read Kathy’s post, I had no idea where they came from, why the information in them mattered, or how they would be useful without retrospectively adding them to everything else that was in the library before they became available. Somehow I simply assumed that the BCC had commented on them and approved them.
In short, I am glad to concur with the statement to the effect that these bytes are essentially pointless and should be ignored. I assume that there is no problem with the fact that in some records other values have been added–no problem, that is, besides the waste of a little bit of time and keystrokes.
Comment by David Guion — June 11, 2008 @ 12:53 pm
The statement probably should make it clearer from the beginning that these two bytes apply only to notated (not recorded) music.
Comment by Kathy Glennan — June 11, 2008 @ 1:44 pm
Since I have some experience making use of coded fields that were sometimes perceived as not useful (the 048 project at Kent State, for instance: http://www.library.kent.edu/kentlink_instrument_search.php), I wonder if these two bytes of info *could* be made to be useful. I agree there is probably less interest in the transposition/arrangement byte, but I can envision usefulness of a limit to scores that include parts. Such a limit would of course be OPAC dependent, at this point, and so maybe not so useful. Since the application of the subject subdivisions “$v Parts” and “$v Scores and parts” is relatively consistent, these may provide a better way to find parts.
So, now that I’ve argued devil’s advocate, I’ll support a statement that says what we should all do with these bytes! They maybe be a good idea, but can we really use them?
Comment by Beth Flood — June 12, 2008 @ 5:17 pm
In regard to Kathy’s comment, the bytes show up in scores and recordings workforms, so I think we need to at least address how to code them (or not), if only to recommend following OCLC defaults in the sound recording format.
Comment by jalberts — June 12, 2008 @ 5:44 pm
I recommend reorganizing this statement so the background, recommendation, etc. stands out more clearly, with sections such as:
Comment by Kathy Glennan — June 17, 2008 @ 3:03 pm
Whoops! I entered comment #5 accidentally, without actually finishing the entry. So, here’s the rest of what I had in mind:
The sections could specifically include background & recommendations, possibly with subheaders for sound recordings and notated music. This would help frame the desired recommendations and make them stand out more on the page/screen.
Comment by Kathy Glennan — June 17, 2008 @ 3:07 pm