Proposal No. 99-04: Definition of Field 007 for Tactile Materials in the MARC Bibliographic and Holdings Formats
SUMMARY: This paper explores the definition of a field 007 to indicate physical characteristics for tactile material, or material intended to be read by touch. Characteristics include specific material designation, grade level of braille, primary code of braille, braille music format, and production and physical characteristics. The field is requested to aid in retrieval and limiting of material.
NOTES: Preceded by DP 104 at ALA Midwindter 98. The proposal has been made more international in scope (some of the U.S. specific codes were eliminated). LC produces and distributes braille material, but it also buys and distributes braille material published from abroad, and they need to be able to accommodate international material. Contracted and uncontracted versions of Braille exist. Braille readers prefer one type of Braille over another depending on the type of material (text book, music, recreational reading). There's a type of Braille that is accessible to both the sighted and the blind (so parents can read to their children). Work is underway on a uniform Braille code; but in the meantime, there are still differences between different flavors of Braille which have to be accommodated.
RESULT: The proposal was accepted with a few small changes: e.g. defining a code "u" for "unknown" in 007/01, removing the category of "not applicable" in 007/03-04 and adding it in 007/06-08.
Proposal No. 98-15 R: Obsolete fields in the MARC Bibliographic Format
SUMMARY: The paper proposes making obsolete several fields and elements that have not been needed for current records for a number of years, to complete harmonization with CAN/MARC. Fields affected include Field 261; Field 262; Field 400; Field 410; Field 411; X11 subfield $q, Field 260 subfield $d.
This seemingly uncontroversial proposal sparked a long, at times impassioned debate about the implications of declaring USMARC fields obsolete. What does "obsolete" mean? Sally McCallum defined it as meaning not to be used when creating new records, but still valid in existing records. How then to define "new"? There is a difference between creating new records ab ovo and creating new records based on old cataloguing (recon). Data entry clerks doing recon will not have the judgment and experience to decide how to chop up information on the card to fit it into the correct new fields.
What impact will this have on software? OCLC distinguishes between valid and invalid; it would continued to regard these fields as valid. RLIN would probably change its validation procedures to disallow entry of these fields in online editing; for batch loading, it could go either way (allow the obsolete fields, or flag them as errors).
Many feel strongly that this will have an adverse impact on recon. Why are we doing this? The Canadians say because they don't want to see these obsolete fields (many of which were never defined for CANMARC) introduced into their databases. They have worked hard at getting rid of fields that don't mesh with USMARC; now they have to accept records that contain obsolete fields they never used. It's too confusing.
Anti-obsolete forces point out that the Canadian systems are going to have to deal with a bunch of new fields anyway; so why not keep the obsolete ones as part of the package.
Dollars and cents implications: some system vendors charge extra for pre-AACR2 fields. Some vendors may simply disallow "obsolete" fields; or write them out, forcing individual institutons to edit the validation tables every time they get an update from the vendor.
Some Orwellian soul suggests we define the fields as "non -current" instead of "obsolete" (an obsolete by any other name will smell as sweet).
Someone also points out that we need to separate AACR2 from USMARC; USMARC has to be able to handle numerous cataloguing codes. But we have to draw the line somewhere, say the LC people.
A straw vote indicated widespread objection to the proposal. So it was put aside for the moment (with hints in the air that LC might decide to ram it through anyway--at least that's what I think was going on).
Proposal No. 98-16 R: Nonfiling Characters in all MARC Formats (Revised)
This proposal elicited so much discussion at the last meeting that it was held over. Among the issues: shall the ability to indicate nonfiling characters be restricted to just the start of a subfield, or allowed with fields? UNIMARC does not restrict its use; and it would be helpful in cases when "sic" and "i.e." are used. There are also languages where articles appear at the end of words, rather than at the beginning. Problem: will users start to agonize about whether the nonfiling codes need to be used for every punctuation point?
The National Library of Medicine is in favor of using the technique at the start of subfields; uncertain about using it elsewhere.
OCLC: It's technically no more difficult to process non-filing markers within a subfield than at the strart of a subfield. OCLC's present practice is to discard these markers when they get a record containing them.
Do we need to expand the list of fields in which the technique may be used? (Some say yes, some say no, some say, Toss for it.)
Should we limit the technique to marking off alphanumeric characters? No--some systems index symbols like musical notation.
Wendler : Will the extra-functionality will confuse more than it helps? Concern about rules because cataloguing workflow will be affected (retraining; need to establish consistent practice over the whole database); there are also issues about sharing records (how can we if we are applying different rules?)
An appeal to what UNIMARC does brings the reply that UNIMARC lets you use the technique anywhere you please.
Attig: why don't we start with defining it just for the start of the subfield and then expanding its use later?
Altimus, RLG: They can't handle the non-filing codes UNIMARC is using now; they have to drop them when they import UNIMARC.
Greene, OCLC: What are we going to do about the non-filing indicators currently in use? Do we declare them "obsolete"? If it's a problem to declare an obscure subfield like the X11$q obsolete, what will happen when non-filing indicators, which appear on every record at least once, are made obsolete.
Goldberg (NAL): This is a big change. It will affect displays, input, etc.
McCallum: Format integration wasn't built in a day; it took five or six years. She's worried that baffled cataloguers will start besieging LC, asking for rulings on what is right and what is wrong.
Weiss: Recon doesn't involve inputting existing non-filing indicators, the person entering the data has to create them; so it's not the same as making a change which forces recon staff to alter existing data on the cards.
Goldberg: Would this affect sorting order? The Scandinavians file an o with a slash after z, we file after n. No--sorting order is a different parameter.
Attig: We all agree it should be usable in any field (not just confined to the short list given). But we don't agree about whether to limit it to the start of subfields, or to allow internal use.
General agreement, though, that the non-sorting zone should not be allowed to cross subfields. You will have to repeat the markers if there are contiguous non-sorting fields.
This is a huge task; we don't want to have to re-do it, so let's get it right the first time.
RESULT: Held over for more work.
Proposal No. 99-07:Field 263 and Year 2000 Compatibility in the MARC Bibliographic Format
Field 263 is used to record the projected publication date, usually in the form of a coded year and month, for works which have not yet been published. The encoding level (Leader/17) in records containing this field is generally set to value 8 (Prepublication level) to further identify the cataloging as "prepublication" and thus subject to change. The cataloging of bibliographic items by national bibliographic agencies such as the Library of Congress (LC) prior to their actual publication has proven to be a very useful in the U.S. and in other countries. The data in field 263 and Leader/17 value 8 can be used to perform periodic database maintenance of the cataloging for items which may not have been published yet, or which, for some reason, may never be published. During the initial analysis of the year 2000 problem and the MARC formats, field 263 was identified as one of the data elements where the year is represented by two digits. At that time this was felt to be acceptable for projected publication dates and no changes were suggested for field 263. More recently that decision has come into question. The proposal takes a closer look at field 263 and the "Y2K" problem. It suggests changes to the structure of the information recorded in the field to make it completely Y2K compatible. Other problems related to ambiguities in encoding the data itself are also dealt with.
This issue provoked relatively little comment. Marti (NLM) pointed out that once we changed this field, we would be under pressure to fix fields such as the Activity dates in the 008. Sally McCallum: this is a field which appears in public displays (unlike the 008), so that it draws more attention.
The proposal was passed.
Notes by Liz O'Keefe, Morgan Library
eokeefe@morganlibrary.org