You are here
OLAC Cataloger’s Judgment: Questions and Answers
Jay Weitz, Column Editor
Out of Practice
Question: The MLA Music Best Practices instructs us (in the BP to 3.19.3): "Use separate MARC 347 fields when recording both RDA and non-RDA vocabulary terms." I would have expected something similar relevant to the 344 to have been stated, but no such provision is in the Best Practices (that I can find), and the "Examples" in Supplements to Best Practices never show such a practice. In fact, one example has "344 analog $c 33 1/3 rpm $g stereo", which is a mix of RDA and non-RDA terms. I presume the instruction about separate 347 fields for different vocabularies reflects the provision in authority records to use one (of any of a number of fields) for a value from a single controlled vocabulary and another instance of the same field for terms from another vocabulary or from no controlled vocabulary at all. So, in theory, one could have quite a string of like-tagged fields, if several controlled vocabularies happened to apply and some non-controlled terms were also relevant. Does anyone know why this sort of separation has never been applied to the 344 field?
Answer: In working on the OCLC-MARC Update 2017, I brought up essentially the same issue to the MLA CMC and to the OLAC Cataloging Policy Committee (CAPC). It came to the fore in particular with the release of LC Technical Notice (March 10, 2017), which consisted of 23 additions to the Genre/Form Code and Term Source Codes list. In its earlier iterations, the MLA Best Practices glossed over the fact that not all of our elements have controlled vocabularies in RDA. Even now, as you’ve noticed, the BP remains inconsistent, although over time it has grown stricter in this regard, particularly with the removal of some controlled vocabularies from RDA (see, for instance, MLA BP 3.19.3). The 23 new codes suggest at least two alternative ways to code the 33X and 34X fields in which they would be used, or some inconsistent combination thereof. The first option is to continue coding them as we have since the 33X and 34X fields were defined in MARC, going as far back as 2009. In the case of the 33X fields, that would mean continuing to use the existing RDA terms in the respective subfields $a and the corresponding codes in the respective subfields $b along with subfield $2 Source codes rdacontent in 336, rdamedia in 337, and rdacarrier in 338, for example:
336performed music $b prm $2 rdacontent
337audio $b s $2 rdamedia
338audio disc $b sd $2 rdacarrier
In the case of the 34X fields, that would usually mean continuing to follow the established coding practice of using the respective controlled RDA vocabularies in a single field along with the Source code rda in subfield $2, for example:
344 analog $g stereo $h Dolby-B encoded $2 rda
The second option is to switch to using the newly-defined codes, which would often result in having to code multiples of many of the fields in question to accommodate the various controlled vocabularies. With the 3XX fields, the older (spelled-out) Source codes defined both the terms and the codes for the content, media, and carrier types, so that including subfields $a, $b, and $2 in a single 336, 337, or 338 field was perfectly legitimate. With the three new (abbreviated) codes, only the terms are part of the vocabulary, necessitating for example:
336 performed music $2 rdaco
336$b prm $2 rdacontent
337audio $2 rdamt
337$b s $2 rdamedia
338audio disc $2 rdact
338 $b sd $2 rdacarrier
We have consulted with LC about the 33X fields, and they apparently expect to continue the established coding practice of a single field in each 33X case. LC seemed to be noncommittal about the 34X fields, however. Employing the newly-defined codes would result in such examples as the following:
344 analog $2 rdatr
344 $g stereo $2 rdacpc
344 $h Dolby-B encoded $2 rdaspc
MLA/CMC and OLAC/CAPC have created a joint task group to discuss and decide upon coordinated best practices. The debate might be defined as pitting strict adherence to RDA and MARC against ease and practicality. With some luck, by the time you read this we’ll know their recommendations. Of course, the conflict between making things potentially more useful for a Linked Data future and keeping things simple for catalogers is at the core of this discussion. Some side issues come to mind. Do we convert any or all of the existing 33X and 34X fields to conform with these new practices? How amenable to the changes will local system vendors be, especially if they have not already dealt well with the 33X fields that have been around since 2009 and the 34X fields, a few of which have been around since 2011 or longer? The debate between codes and controlled vocabulary is also fraught. Codes have the advantage of being language-neutral and at least in theory allow for automated switches among languages (although depending upon the sophistication of the switches, the same could be said for controlled vocabularies). Codes, being usually shorter, may tend to be less error-prone than spelled-out controlled vocabularies. Perhaps the least obvious problem with the “new” controlled vocabularies for content, media, and carrier is that they don’t account for the “other” and “unspecified” designations that are accounted for in the original MARC/RDA vocabularies. That seems particularly shortsighted for what are supposed to be forward-looking sets of instructions and vocabularies that claim to be trying to anticipate the unanticipated. As it is, the existing “other” categories in the Term and Code List for RDA Carrier Types can be distinguished from each other ONLY through their distinct codes, if they are present.
Still Out of Practice
Question: When I look at the OLAC Best Practices for Cataloging DVD-Video and Blu-ray Discs Using RDA and MARC21, I see a lot of recommendations that simply carry on practices because that’s we way we’ve always done things, not because they are internationally friendly or based on principle. You’d think that guidelines based on RDA would try to be both.
Answer: The current 2015 DVD/Blu-ray RDA best practices document took a long time to develop and was based heavily on the two AACR2 documents that preceded it from 2008 and 2002. It proved difficult to get away from thinking through an AACR2 lens, even during the document’s 2012-2015 gestation period. At least part of that was because until RDA “Day One” on 2013 March 31, it was mostly a relatively few larger institutions that had made the RDA leap. The 2015 document also more-or-less kept the MARC-like arrangement of its 2008 predecessor, rather than following the logic of RDA (such as it is and using the term “logic” advisedly). Because we still catalog in an essentially MARC environment and will for the foreseeable future, it’s difficult for many of us to think beyond the frame of a MARC record or outside of strings of MARC fields and subfields. Such newer MARC elements as the 33X and 34X fields do encourage us to untie those strings and to think more about individual bits of data, but it doesn’t come naturally (speaking for myself, at least). Such MARC elements as the 33X and 34X fields allow systems that are so equipped to manipulate them at will. It’s my entirely unscientific supposition that not many local systems are so equipped and won’t be anytime soon, so it makes a certain sense to remain consistent with past practice for now. We also have millions of MARC records not yet retrofitted with 33X and 34X fields, both in WorldCat and in local databases. As you probably know, CAPC is starting to work on a set of guidelines that will attempt to rationalize, consolidate, and harmonize all of the current OLAC best practices documents. The eventual goal is a single, consistent OLAC best practices document that tries to account for all materials under OLAC’s purview that have not otherwise been dealt with. Not only would that make it more likely that the document could be linked instruction-byinstruction into RDA, it would make maintenance so much easier. Arranging the mega-document into RDA order and having links into RDA need not mean any loss of either detail or specificity if we do it carefully. What it should cut down on are repetition and, perhaps even more importantly, places where we are unnecessarily inconsistent. I have a dream that one day OLAC will rise up and live out the true meaning of its creed: an equal concern for “all types of nonprint materials, including a wide range of digital resources as well as more ‘traditional’ formats." And that will be reflected in a comprehensive OLAC mega-best practices document. And when this happens, the little OLAC symbol will link from every
RDA instruction so that catalogers will be able to join hands and sing in a paraphrase of the old AfricanAmerican spiritual, “Linked at last. Linked at last. Thank OLAC and CAPC, we are linked at last.” Sorry, I got carried away there.
Question: I was trying to improve a minimal level record. I thought my cataloging privileges allowed this, but the system will not allow me to add subfield $d with our OCLC symbol as modifying organization. Do I have to derive the existing record and create a new record? This would be a duplicate, though. It's been a while since I tried to modify an existing record.
Answer: When you replace the record, the system will automatically supply your institution's OCLC symbol as the final 040 subfield $d. You don't have to do that yourself; in fact as you've discovered, the system won't allow you to do that. It happens automatically. At this point because you've already tried to edit the 040 field, it's possible that you may have to start over with a fresh copy of the record, cut and paste your edits from the other version, and then replace the fresh version.
Question: I note in the new OCLC Technical Bulletin No. 267 that the Bibliographic 752 (Added Entry-Hierarchical Place Name) can now take a subfield $2 code, plus a host of other subfields. I’m confused, as I’m not aware that this field can truly be said to belong to the NAF or any other source code. What am I missing here? Are there plans to make this field linkable? I’ve always been a bit confused about the formulation of this field, and would welcome any wisdom relating to how it might be linked in future.
Answer: Bibliographic field 752 has had the subfield $2 defined since MARC 21 Update No. 6 in October
2005, which was implemented by OCLC as part of the OCLC-MARC Format Update 2007. The change to 752 subfield $2 that is part of the 2017 OCLC-MARC Update is merely a rewording of the subfield definition, which had previously referred to the source of the heading or term. MARC 21 has now been clarified to read: “MARC code that identifies the source list from which the geographic name was assigned. Code from: Name and Title Authority Source Codes.” There is no change to the use of the subfield itself. If by “linkable” you are referring to the controlling of WorldCat headings to the authority file, there are currently no such plans for field 752.