The MARC record management libraries need to allow management of the legacy records we actually have and the records that existing systems currently use.
Some problems that MARC record management libraries need to manage: 1. CHARACTER VARIANCE FOR FIELD CODES. Large union catalogue systems such as RLIN and OCLC have already specified almost every numeric MARC 21 local use field for their own purposes. Canadian local use fields for equivalence or cross-reference between languages are part of the MARC 21 standard even if they are only used in Canada. RLIN itself has specified so many local use fields that they have added field codes with letters instead of only numbers to provide more local use fields for special purposes of theirs. Local system use of field codes that are not strictly numeric would seem to be a reasonable solution to the problem of too many potential reserved uses of local use fields. Such usage would allow local use fields which do not interfere with the established local use.fields of popular union catalogue systems. 1.1. NO PROBLEMS WITH RECORD MANAGEMENT MODULES? I have not observed problems with field codes containing non-numeric characters using MARC::Record or MARC::File::XML. However, I have not tested extensively and want to be certain that no problems would not arise from such usage in future. 2. CHARACTER VARIENCE FOR SUBFIELD CODES. On Thu, July 13, 2006 4:41 pm, Paul POULAIN wrote: > Could it be possible to have an option that deals with invalid > subfieldcodes : Whether valid or not, real systems use punctuation symbols to designate subfields so as not to interfere with standard usage. No, $9 is not always enough. Use of $% and $@ is widespread. RLIN uses $% to store the control number of a linked authority record. UNIMARC has provided $3 for the same purpose. The problem of how to match bibliographic records to authority records has been left to system designers for MARC 21. Punctuation symbols may be sufficiently numerous for some purposes but I can certainly imagine a case in a system where actually using capital letters in addition to the standard lowercase letters would be very helpful. 2.1. PROBLEMS WITH RECORD MANAGEMENT MODULES. I have not tested this but expected that at least some punctuation might be liable to be a problem for some record management modules. Paul Poulain reports this as a problem for MARC::File::XML. I believe his case had problems with $> as a subfield in addition to possibly capital letters. On Thu, July 13, 2006 4:41 pm, Paul POULAIN wrote: > * die (actual behaviour) Maybe this would not be a problem for some punctuation, but I would like to be certain that it would not to be a problem for any punctuation nor for capital letters either. 3. SYSTEMS ANSWERING REAL NEEDS. Systems are designed to answer real needs in the real world. Of course, extensions to standard usage should sometimes be filtered out to facilitate maximally interoperable record exchange when exported for use outside the system for which the extensions were created. However, the recipient of an unfiltered record may not have the option of choosing a filtered record if only unfiltered records are available. The record recipient's system has to cope with available records or not use them. If system designers are adding elements to MARC, which extend the standard without conflicting with the standard; then the libraries used to manage the records must support such records. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783
