MARBI Members:
Priscilla Caplan LITA Univ of Chicago James E. Crooks RASD UC Irvine Shelby E. Harkin ALCTS Univ of North Dakota Sandra Lindberg RASD LaFayette Public Library Flo Wilson ALCTS Vanderbilt Univ Larry Woods LITA Univ of Iowa Jacqueline Riley RASD Univ of Cincinnati Paul J. Weiss ALCTS Nat. Lib of Medicine Robin Wendler LITA Harvard University MARBI Interns: Josephine Crawford ALCTS University of Wisconsin Carol Penka RASD University of Illinois Elaine Henjum LITA Florida Ctr for Lib Auto Representatives and Liaisons: Jui-Wen Chang RLG Research Libraries Group Betsy Cowart WLN Western Library Network Bonnie A. Dede SAC Univ of Michigan John Espley AVIAC VTLS Catherine Gerhart CC:DA Univ of Washington David Goldberg NAL NAL Richard Greene OCLC OCLC Rebecca Guenther LC LC, Net Dev/MSO Michael Johnson MicroLIF Follett Software Co Maureen Killeen ISM ISM, Inc. Karen Little MLA Univ of Louisville Sally McCallum LC LC, Net Dev/MSO Susan Moore MAGERT Univ of Arizona Phyllis Post AALL Capital Univ Law Lib Young-Hee Queinnec NLC National Library of Canada Louise Sevold PLA/CIS Cuyahoga County Pub Lib Patricia Siska ARLIS Frick Art Ref Lib Rutherford Witthus SAA Univ of Colorado Other attendees: Steven R. Affleck Retro Link, Provo, Utah Kathy Allen TALX Corp Joe Altimus RLG Karen Anspach DataTrek, Inc. Kathleen Bales Research Libraries Group Richard Baumgarten Johnson County Library Mike Berger University of California Virginia Berringer University of Akron Diane Boehr Costabile Associates Candy Bogar DRA Ross Bourne British Library Jo Calk Blackwell North America Sylvia Carson Penn State University Ann Case H.W. Wilson Co. Marlene Chamberlain American Library Association Winnie Chan University of Illinois at Urbana Sherman Clarke Amon Carter Museum Karen Coyle University of California Robert Cunningham NELINET Darleen Gerace Daly AMIGOS Bibliographic Council Carroll Davis Columbia University Mollie Della Terza Harvard University Genevieve Engel Univ of California Ann Ercelawn Vanderbilt University Ann Fiegen University of Arizona Anne Flint OhioLink Michael Fox Minnesota Historical Society Ruth Haas Harvard University Margaret Hecker Kentucky State University Diane Hillmann Cornell Law Library Christa Hoffmann National Lib of Medicine Alice Jacobs National Lib of Medicine William W. Jones New York University Erik Jul OCLC Arno Kastner New York University Joseph Kiegel University of Washington, Seattle Kris Kiesling University of Texas Lynne Kraus SUNY/OCLC Louisa J. Kreider Cleveland Public Library Eric Lamontague DRA Mary Larsgaard UC Santa Barbara Lyllian Le Quellec DRA Elizabeth Mangan LC G&M Ralph Manning National Lib of Canada David Murrell-Wright National Lib of Canada Larry N Osborne Univ of Hawaii Glenn Patton OCLC Judith Ranta Queens Borough Public Library Becky Ringler UC San Diego Stefan Roger DataTrek (ILS) Holly Schmidt Blackwell North America Jackie Shieh University of Virginia Ann Sitkin Harvard Law Library Gary Smith OCLC Steven J. Squires University of North Carolina Stuart Spore NYU Medical Library Gary Strawn Northwestern University Louise Swold Cuyahoga County Public Library Mitch Turitz San Francisco State University Tamara Weintraub National Lib of Medicine Susanne Warren Art and Architecture Thesaurus Bob Warwick Rutgers University Libraries Luciana Wlassics University of Virginia MARBI Recorder: Josephine Crawford University of Wisconsin ***************************************************************** January 20, 1996 ***************************************************************** The meeting was opened by chair Priscilla Caplan. After introductions, the meeting moved on to the first item of business. PROPOSAL 95-6 : "Linking Code for Reproduction Information" Sally McCallum introduced the proposal as a substantive revision of earlier proposals. She discussed three general models (A, B, and C). By "marking" the cataloging data referring to the microform reproduction, a local system can opt to store separate (Model A) or merged (Model B) bibliographic records as best internally, yet communicate separate records for the original and reproduction as required by the utilities. Model C is a variant of Model B (merged bib records) with a dependent holdings record. The $8 link will serve as a marker needed to identify fields pertaining to the reproduction when both the original and reproduction are described in the same record. At the previous meeting there was a request for order of numeric subfields to be indicated, so the proposal proposed a specific order for numeric subfields. Rich Greene talked about the serious problems OCLC has with the proposed order due to existing records and existing software for CJK assume $6 is always first. Sally said that the suggested rule is derived from current practice as indicated in the Bibliographic format. Rich believes that the last subfield of the 533 would have to be moved under the proposed rule. Priscilla Caplan added that old software always thought $a should be first, and she asked if no preferred order is better now. Do we want to facilitate machine processing, human input, both, or neither? Jui-Wen Chang agreed that a rule-imposed subfield order could cause software problems. She emphasized that the most important thing is to have the tagging. Kathy Bales reported that the RLIN system places the $6 first when communicating CJK records to OCLC. Rich recommends a rule for placing $6 first followed by the $7, otherwise any order is OK. Mitch Turitz questioned marking or flagging a 776 (Additional Physical Form Entry) in a merged bib record, because by definition it links back to the original record. Diane Hillmann believes it should not be flagged if there is only one reproduction involved. Catherine Gerhart reminded everyone that it is very common to have both fiche and film and the original; must be able to link the 533 field to the appropriate set of reproduction fields. Priscilla pointed out that the 007 cannot be flagged. Sally agreed that there could be multiple 776 fields, so need to require the $8 in these cases. Robin Wendler and Paul Weiss discussed record exchange between systems in terms of Model A and Model B. Robin recommended Model A in all cases, Paul stated that NLM has a commitment to Model B at this time. Sally wants to make sure that local systems don't have display problems with Model B. Priscilla felt MARBI must decide on either Model A or Model B for record exchange. Diane Hillmann emphasized explicit coding of multiple versions so that a local system could manipulate records upon receipt. Rich Greene agreed with Diane. Robin asked if OCLC will explode out a merged record which has three reproductions and one original on it. The answer is no. Paul pointed out that OCLC now has records with multiple 533s. He sees a problem in that serial holdings are being treated like monographic holdings; a library probably doesn't own the whole run yet there is no way to tell this from OCLC's database. Priscilla asked for a straw vote from all present. Do not code the $8 in the 533 field if there is only one reproduction involved. If multiple reproductions are being described, then the $8 is required in each 533 field. Eighteen people voted for this approach and sixteen voted against. The meeting moved on to discuss the 007 issue. Sally asked if 007s are used now? Yes. Paul likes imbedding the 007 in a variable subfield (e.g. 841 $7 h). Others felt that not being able to include a $8 link in an 007 field is not a fatal flaw since the "h" code would indicate microform. Jui-Wen Chang asked what to do in preservation cases where the original is destroyed after the reproduction is made. Under Model A, Sally suggested deleting the original record as well as the 776 field on the reproduction record. If there is a functioning holdings system, Diane pointed out, the original bib record could be retained with withdrawn noted in the holdings. The discussion returned to whether or not a particular model should be required by USMARC for the exchange of records. Larry Woods argued in favor of a standard Model A approach. Diane Hillmann discussed the complicated variations that catalogers commonly see; she recommends negotiation between the exchange parties on this issue. Priscilla asked for a straw vote on the following: The USMARC format should NOT proscribe one model over another, parties should negotiate. The responsibility is placed on the receiving system to say if it is preferred to received separate or merged bib records. The majority of the people in the room voted in favor of this. Like the 007, it will not be possible to link an 008 field to a set of reproduction fields. There is the possibility to use additional 006's if multiple 533's are used. Priscilla suggested that a motion be made to accept Proposal 95-6 with the requirement that Model A be used for record exchange. Under Model A, separate records are communicated, one for the original and one for each reproduction. Each reproduction record has a GMD in the 245, an 007, a 533, and a 776 field. Robin Wendler made the motion (stating that some progress is better than none) and Larry Woods seconded it. Seven members voted in favor, and two voted against. Robin also made a motion dealing with the order of numeric subfields. The $6 subfield should come first, after that no order is proscribed. Paul seconded this motion. Eight members voted in favor and no members voted against. ----------------------------------------------------------------- PROPOSAL 96-4 : "Defining a Constituent Unit Entry Field" Rebecca Guenther introduced this proposal, which has been preceded by two earlier discussion papers. There were two proposals originally which have been merged into one because the issues were intertwined. Rebecca suggested that everyone turn to page 7 where the proposal gives two alternatives for defining a Constituent Unit Entry Field: change the name and broaden the use of field 770 or define field 774. The proposal also explores the relationships between fields 770, 772, and 773. (It is useful to keep in mind the difference between fields 772 and 773 as currently defined; the distinction between these fields is whether the item described is physically independent.) Priscilla opened the discussion by stating that improving bibliographic relationships is a recurring issue in MARBI discussions. Which field for which relationship? The discussion moved on to discuss past uses of the 770 field. Usage has changed over time, according to Diane Hillmann, especially with the implementation of the holdings format; primary use has been for supplements though. Young-Hee Q. reported that the 770 is used widely for supplements in Canada. A member of the audience suggested a completely different approach -- use the same fields with indicators to show the up/down relationships. Jui-Wen Chang from RLG explained why the 774 approach is preferred. Mary Laarsgard talked about using the 772, 773, 775, and 776 for map materials. She found that the 770 (with parent in 772) worked well because about 80% of cartographic material has a relationship with spatial data. The relationship is mostly parent/child. She also found that the 773 field is useful when several maps are on the same sheet. She recommends maintaining both the 772 and 773 relationship fields, since both situations occur and the user display must be different for access purposes. Young-Hee reported that the National Map Collection of Canada uses the 772 field. It was agreed that the 772 and 773 fields point back to the parent record in the same way, but that the user must be able to see the parent information for the 773 field. Priscilla summed up by defining 4 relationships (up, down, physically separate, and contained within). USMARC needs a generic up/down linking entry, not just for serial supplements and special issues. Karen Coyle asked for clarification about the bibliographic record; the 772 goes on a full bibliographic record, correct? Yes. John Espley stated that he is not in favor of making 772/773 obsolete because there are many records in databases now with them. Diane Hillmann asked if the parent/child relationship is a reciprocal one or one-way? Priscilla felt that it is impossible to predict what is needed, so it is best to leave room for both situations. Karen Coyle brought up the example of journal articles with images supplied over the network. Even if the user does not require the display of the host for retrieval purposes, the user may need to know the host for a bibliography. Priscilla recommended using the 774 field for the down relationship and the 773 for the up relationship, regardless of physicality and with no expectation of reciprocity. She also recommended leaving the 770 and 772 fields alone. Mary agreed with Priscilla. Betsy, however, pointed out that the 772 display constant must be changed. The second indicator will be used to generate different display constants. Given past practice, it might be good for "#" (which stands for No information provided) to display as: Supplement to: Other indicator codes could display as: Part of: Single issue of: Special issue of: There was some discussion about the need for $8 linking. This will happen in some cases, and in one case sequencing is required according to Rebecca. It was agreed that the $8 linking code should be "c" for constituent entries. Paul made a motion to accept the following USMARC changes. -- define the 774 Constituent Entry Field -- remove the physical item requirement from the 773 field -- clarify the 772/773 relationship -- Define a 2nd indicator for the 772 field: # Supplement to: 0 Parent relationship 8 No display constant generated -- define $o (Other item identifier) in 76X-78X fields -- define $i (Display text) in 76X-78X fields -- define "c" code for the $8 type of linkage (Constituent item) Larry Woods seconded the motion. Eight members voted in favor and no members voted against. ----------------------------------------------------------------- DISCUSSION PAPER #92 : "Change in Definition of Computer File in Leader/06 (Type of Record)" Rebecca introduced this discussion paper by stating that the information world has changed considerably since the plans were first made for format integration. Computer files are used much more frequently now, and it seems useful to separate content from carrier. The idea is to narrow the definition of the Leader 06 "m" code to represent executable software only, and not any computer file. Priscilla suggested that the questions on page 5 be discussed in turn. The discussion began by relating the current uses of Leader/06. The RLIN system uses the code for putting the record into different databases. The WLN system uses it for sorting and to display the appropriate cataloger workform (each workform has different defaults supplied). ISM uses the code to ensure the validity of fixed fields; also for sorting, display of the record level, and boolean searching by format. NLC uses it for duplicate detection. OCLC uses the code for matching bibliographic records and for selecting subsets of records since the database is not segmented. VTLS uses the code for display of labels and for different displays of individual tags. Priscilla suggested that the "m" code not be used for anything textual, such as electronic journals. Is this a good idea? Yes, in the case of cartographic items. Paul agreed that textual computer files are a case where it is not good to separate the rules from the format. Catherine Gerhart asked if the Type code should be different than the AACR2 chapter? Unknown. Karen Coyle expressed some concern about retaining the ability to show "computerness" (like seriality). Paul pointed out that there is inconsistency now. Sally asked if it is useful for the Leader/06 to just mean language material? But then, if you follow the microform model, where do you code the executable software? And data is another type of computer file. Someone from the audience asked about text with executable software -- like an electronic kit! With Java entering our information world, there is every expectation that it will be hard to distinguish executable software from the data and/or text itself. THere was concern that the definition in the paper for computer file as executable software was too narrow. With the new definition you couldn't use a computer file 006 for additional characteristics of, for example a digital text, since it isn't executable. Diane suggested that we broaden the concept so that no dead ends are created. Priscilla suggested narrowing the definition of a computer file so that it allows items not to be coded as computer files. Robin suggested we define a couple of codes for the primary aspect, and then use the 006 for secondary characteristics. Paul believes users care about image, sound, etc., but the 006 won't help managing these characteristics. Catherine presented a model where equal value is given to content, physical carrier, seriality, and archivability; she proposed a repeatable leader. It was agreed that it is useful to put the history of a serial in one record, yet this is contrary to current cataloging rules. Karen pointed out that users need and want cataloging descriptions to be kept together even though the carrier changes. She supplied an example of a serial which changes from CD-ROM to an electronic journal. It was suggested that each constituency will need to issue guidelines. The discussion closed with an agreement to revisit this summer by a 2nd discussion paper. ----------------------------------------------------------------- DISCUSSION PAPER #91 : "Machine Generation Flag in USMARC Authority Records" [not discussed on 1/20/96; see end of session on 1/21/96] ***************************************************************** January 21, 1996 ***************************************************************** PROPOSAL 96-1 : "Changes to Field 856 (Electronic Location and Access) in the USMARC Formats" Rebecca Guenther introduced the proposal which recommends two changes to the 856 field as follows: -- Define the value 8 (Other) in the First indicator, as a way to deal with the current redundancy in the use of subfield $2 when the access method is also recorded as part of the URL in subfield $u. -- Redefine subfield $q from "File transfer mode" to "File format type," in order to keep up with the changing FTP landscape since so many file types now exist. Priscilla suggested that the Committee begin by addressing the recommendation for the first indicator. It was generally acknowledged that redundant inputting is a problem, yet there are intense pressures from other directions, such as the "frequent sea changes" of the Internet. Diane Hillmann asked if catalogers could use macros on their workstations, in order to lessen the impact of redundant keying. She is concerned that the 856 field will change too frequently, unless changes are made for only the most critical issues. Bill asked if there is a one-to-one correspondence between the access method in $2 and the first part of the URL in the $u. Rebecca thought that there is a one-to-one correspondence. Robin asked what the future holds in store for us given the work on URN's. Would this change be "very interim" or last for some years? Does the URN include access method? Priscilla replied that she does not think that the URN will include access method. Because a URN might be resolved into several different URL addresses, there will be much to consider when this Internet standard is approved. Erik Jul spoke on behalf of OCLC's Intercat. He discussed several concerns in turn: 1) He is concerned about the limit on the number of values in the first indicator position. Can we use values 1 and 2 as a combination? This would allow for 100 combinations. 2) As described in the proposal, Intercat uses $2 and $u for display purposes. Erik likes the detailed coding in the current 856 field, where each data element has its own subfield code. Works more easily in a USMARC-based system. A change would mean some programming and also might take up more computer cycles in processing a display. 3) OCLC would have to deal with some kind of change to retrospective records, or else have more convoluted display programs. This is not desirable at all. 4) In regards to the one-to-one relationship between a $2 and the first part of the URL, this will not be true once OCLC's PURL protocol is in use. A PURL is like a cross reference to the real URL, which will be stored at OCLC. Example: http://purl.oclc.org. Using a PURL, the access method to the object might be FTP, but a PURL will always use http. Given this discussion, there was no support for this proposed change. The Committee moved on to discuss the $q proposal. Priscilla asked if there is a need for a more precise definition of file format; if so, should it be in $q? Rebecca replied that now that the MIME standard is in common use, she saw a need when mapping the Dublin Core elements to USMARC. She asked if the default for the subfield should be binary. Although the LC system is programmed to translate a file extension to mime type (and can therefore distinguish between text files and various types of binary files), would it benefit other systems to have binary be the default? Erik reported that the $q is not used much now in Intercat. It seemed reasonable to define it at the point in time it was defined, but hasn't proved to be of much use. Paul reminded the group that the 856 field is used for all computer resources, not just those on the Internet (i.e. dial-up, CD-ROMs, etc.) Priscilla discussed the real purpose of this subfield: to give a user the information needed to easily transfer and use various types of files. She worried about file types which won't be represented by a MIME type. Although it is possible to register MIME types, new ones will appear on the Internet before registration is completed, Rebecca added. Young-Hee Queinnec asked about the cost/benefit relationship of this proposed change. Is it really necessary? Might software take care of file format type for users automatically? Rebecca reported that an FTP using a WWW browser does not require a user to know if a file is ASCII or binary. Others in the room discussed whether or not this change would prove to be unnecessary in the long run, with the general feeling that this was a possibility. Paul Weiss moved that both parts of Proposal 96-1 be turned down. Larry Woods seconded. Eight members voted in favor of the motion. ----------------------------------------------------------------- PROPOSAL 96-2 : "Defining a Generic Author Field in the Bibliographic, Authority, Classification, and Community Information Formats" Sally McCallum introduced the proposal. It is a direct result of the OCLC MetaData Workshop where the generic author field could not be mapped into USMARC due to the USMARC emphasis on the cataloging concepts of distinctions among names: person, corporation, meeting. The proposal has also been spurred on by the interest of the National Library of Medicine. Paul Weiss suggested the discussion begin by asking for people's thoughts on the RLG comments sent out on the list on 1/18/96. Should the proposal remove the Authority format from the list of formats? Yes, citation of Authority format was an error. What is the preferred field number, 713 or 720? There was agreement that the field number should be 720. Can the definition of the field maintain the reference to cataloging rules and authority files? It was agreed that the description of the field should read "This field contains names associated with a work that are not necessarily formulated according to cataloging rules or that are not necessarily contained in an authority file or list." Priscilla wondered about name form of personal names. Should USMARC require last name first? Paul thought not, if the intent is to parallel the field with current practice of the 653 (Uncontrolled Subject Terms). There was some agreement that it would be helpful to show if an inverted name or not by the use of a 2nd indicator. Robin Wendler noted that distinguishing between personal and corporate names allows a library to send records off for authority control processing. However, NLM has Medline records that don't now show if a name is a personal name or other type of name. Perhaps best for the indicator value to not be required. It was agreed to use the "minimalist approach" where blank will be legal. Rich Greene reported OCLC staff looked in depth at this proposal. A great idea, but late by 25 years! Unfortunately, it will require major development so it is likely OCLC will not be ready when the change is released. He gave some examples of the OCLC programs which assume computer knowledge of type of name: authority programs, PRISM display programs, and indexing programs. In particular, OCLC staff feel it is important for users to get to all personal names in a single index, whether that name is present in a 100, 700, or 720 field. Priscilla asked if OCLC could remove the field until ready. Yes, Rich replied, although even removing is an expense given the large numbers of records involved. Rich went on to discuss another issue -- deciding whether MetaData records should be part of the OLUC or stored in a separate file. Young-Hee Queinnec expressed concern that these incoming names will not be formulated according to cataloger rules. Although others share the same concern, it is not realistic to expect authors to input authoritative forms. Paul reported that Medline indexing uses the form exactly as it appears on the article itself, so it may or may not be different from the authoritative form. RLG staff reported that they have a model in place already where a separate index is used for this type of field. John Espley spoke up about local systems; there is usually a keyword index and clients decide which fields to include in different index types. Someone reported that LC indexes the 653 field by keyword in a general note index. There seemed to be general agreement that the value of the proposal is that it keeps the USMARC format relevant to the user community and it allows for experimentation to deal with authority control and other types of problems. Paul moved that the Committee accept the proposal in the following way: 720 field, revised field definition as stated above, and Option 1 where the first indicator is not defined. There were several seconds but no vote, while Option 1 was compared to Option 2. Karen Coyle spoke up for Option 2; more information should always be encouraged even if it cannot be required. Paul questioned whether the definition of value # in the first indicator should read "Not specified" and that another value be established for "Unknown" in addition to the values for "Personal" and "Other." Robin made a motion to amend the previous motion to accept Option 2 with the value # defined as Not specified. The amendment was seconded and the vote was 8 in favor and 0 against. ----------------------------------------------------------------- PROPOSAL 96-3 : "Changes to Personal Name First Indicator Values in the Bibliographic, Authorities, Classification, and Community Information Formats" Sally McCallum introduced the proposal by discussing the MARC reconciliation work in progress with The British Library and The National Library of Canada. It was discovered that UKMARC and USMARC have the same indicator with the same values, but the definitions are slightly different. Single surname and multiple surname encompass slightly different groups of headings. Rather than undertake an expensive reconciliation between the two countries, it seems best to make the one of the two surname values obsolete. It does not appear that systems have programs relying on the distinction between multiple and single surname. Paul expressed a concern for the proposed LC policy regarding retrospective records; LC probably would not carry out retrospective conversion of its bibliographic or authority records, but would maintain consistency between the indicator for headings in authority records and bibliographic records. Paul saw this approach as a break with how "obsolete" has been handled in the past. What should "obsolete" mean and should there be consistency? Rich Greene agreed with Paul. He stated that OCLC has the practice of scanning the database to get rid of any obsolete coding or data elements. Yet, OCLC must be in synch with LC. Priscilla stated that it is explicitly against USMARC rules to input obsolete codes. David Goldberg suggested that there are some reasonable alternatives. Alice Jacobs reported that NLM prefers for past records to be changed, both authority and bibliographic so that the information is kept in sync. Since LC does not have a linked authority file, this seems less important. Yet, LC distributes its authority file to systems where synchronization is essential for smooth functioning. And the records pass through a utility like OCLC, so Rich Greene and Stefan Roger (DRA) urged retrospective conversion. Sally said the major cost for LC is converting the bibliographic records retrospectively, not the authority records since there are many fewer. Would just converting authority records be acceptable? Rich felt that OCLC could change bibliographic records upon receipt, as long as LC took responsibility for changing authority records all at once. Others agreed. Robin suggested that, if any large systems converted bibliographic records retrospectively, that perhaps these records could be shared with LC. Others pointed out that there would be record matching problems to solve and that the volume might be more than LC could handle. Priscilla asked for more discussion on the impact of this proposal on systems. John Espley reported no concerns from AVIAC members. Maureen Killeen from ISM reported that the impact is minimal, as long as LC redistributes changed authority records. Betsy Cowart from WLN reported that the WLN system does use the value for indexing multiple surnames, and might have to reprogram the display. Therefore, WLN is against the proposal. Priscilla suggested that this becomes a smaller issue for WLN as long as LC redistributes the authority file with the proposed changes. Betsy agreed. Since WLN will still have some impact on its operation, Paul asked how in general MARBI should handle such situations. Priscilla explained that MARBI should always try to look at the expense of system changes, but must weigh the severity against the advantages. She asked Betsy if WLN needed more time to prepare, if the proposal passes; Sally added that implementation should normally follow within six months after publication. LC will need to work out the timing with OCLC and RLG. Betsy said not in this case, since WLN staff expected the proposal would pass. Others pointed out that not passing the proposal would cause much more work overall than passing the proposal. Paul moved to pass the proposal. In the first indicator of the X00 fields, value 2 (multiple surname) will be made obsolete and value 1 (surname) will be redefined and renamed. Robin seconded the motion. Six voted in favor and no one voted against. ----------------------------------------------------------------- PROPOSAL 95-4 : "Merger of the 27X fields in the Community Information Format" Rebecca Guenther introduced Louise Sevold, who has come to the MARBI meeting to represent PLA Community Information Section. Rebecca went on to describe Proposal 95-4 and its history. The original objective was to align the Bibliographic Format with the Community Information (CI) format; as part of this process, discussion revealed a need to tighten up coding for various types of addresses in the CI format. There seems to be a consensus now to have a single address field; the field would be repeatable and would have values in the first indicator position to show type of address. Louise reported that she has spoken with various system vendors who support the CI format. The proposal is generally acceptable, although a value "3" for mailing address is requested in the first indicator in addition to the values in the proposal. It would be common for the same address to be used both as a primary address and also as a mailing address, in which case the field would be repeated with only the indicator difference. It was asked if there has been heavy use of the two fields which will become obsolete under this proposal, 271 and 275. Yes, indeed. But, Louise added that the vendors agree to change existing records, moving the information into the 270 field with appropriate coding. It was suggested it might be better to define a 2nd indicator for mailing address, so that it would not be necessary to input/store the same information twice. Louise likes this idea. John Espley added that some mechanism should be established for local definition of address types. He proposed a "7" value in the 2nd indicator which refers to the $i for the type of address. Stewart asked if "location" rather than "address type" might be a better way to describe the 2nd indicator. Some thought this was a little too subtle. Louise reported that users don't see the mailing address. It is used for mailing out requests for updates to the information in the record. Priscilla asked if there were any comments about $v (Hours) and $z (Public note). Although not mnemonic, both codes are aligned with the bibliographic format. Errors were noted in the $a example on page 7. Rebecca will explore what happened and correct as needed. Paul moved that the proposal be approved with the following amendment: -- 271 and 275 fields should be deleted from the format (rather than made obsolete). -- First indicator called "Level" # No level specified 0 Primary 1 Additional (Secondary) -- Second indicator called "Type of Address" # Not specified 0 Mailing Address 7 Other (refer to $i) A second was provided. Eight members voted in favor, and no members voted against the motion. ----------------------------------------------------------------- PROPOSAL 96-5 : "Enhancements to Field 007 in the Community Information Format" Rebecca introduced Proposal 96-5. The main issue is defining character position 10 in field 007 for various values relating to handicap parking. The proposal also discusses some other issues which came up in the various discussions, such as coding more interpretation-related services (such as oral/voice/tactile interpretation for the vision impaired). Louise Sevold representing PLA Community Information Section recommended that the 007/10 change be approved. It would be very helpful to service providers. Priscilla asked if the other 007 values should be improved at this time. Louise does not feel that it is necessary at this time. Paul recommended that sign language be looked at in the near future, in consultation with the ASCLA Deaf Section. Rebecca reported that she has been in contact with the deaf community to discuss the current list of sign languages in terms of MARC language codes. Bonnie Dede stated that she would be happy to share information about sophisticated telephone packages, for users who need artificial voices or emergency back-up. Sally thanked the Committee for these comments, and suggested that those creating CI records should be urged to bring forward their needs. Discussion returned to the proposed values for parking. The codes mainly specify if handicap parking is available or not, and, if handicap parking is available, whether there is high clearance for special vehicles. Paul wondered if the disabled legislation specifies the clearance in feet? If so, he suggests that this be stated in the definition of the values. This seemed reasonable. Paul moved that the proposal be approved with heights proscribed if appropriate. Jacqueline Riley seconded the motion. Seven members voted in favor and no members voted against. ----------------------------------------------------------------- PROPOSAL 96-6 : "Definition of Existing Bibliographic Data Elements in the Community Information Format" This proposal defines two fields in the CI format, exactly as they were recently defined in the Bib format. The fields are 658 (Index Term-Curriculum Objective) and 856 (Electronic Location and Access). Given the current emphasis on format alignment, it is expected that the adoption of new data elements from one format to another will become commonplace. This proposal also suggests a new procedure by which new data elements would be defined by adoption, thereby avoiding the delays of the MARBI discussion paper and proposal process. Priscilla suggested each part of the proposal be discussed in turn. Louise reported that PLA was in favor of adding both fields to the CI format. Paul moved immediately to accept the 658 addition to the CI format. Jacqueline Riley provided a second. Seven members voted in favor and no members voted against this part of the proposal. There was some discussion about the 856 field. Do the electronic links refer to an agency or program? How does this stack up against the description in the CI record? Will it make sense to the user? Louise felt that all will work well in actual practice. She felt users would be thrilled by the ability to jump from a CI record to more detailed information on the Internet. Paul moved that the 856 field be added to the CI format. There was a second. Eight members voted in favor and no members voted against the motion. There was much discussion regarding the proposed "adoption" procedure. It was pointed out that the procedure would only take affect where a data element could be adopted in another format without changes to the tag, indicators, subfield codes, or other encoding-related aspects. Implementation would occur after a 90-day period following a technical notice to USMARC subscribers. Larry Woods expressed surprise that a fast-track procedure was folded into the proposal, since it could involve other formats than the CI format-- or will the procedure just apply to CI? Sally said that it was folded in because these two changes are excellent examples of where the procedure would have been helpful. Jui-Wen Chang, the RLG representative, spoke about whether or not such a procedure would allow for adequate discussion and analysis on system impact. Rich Greene seconded this concern, although he said that OCLC staff agreed with the need for a fast track process in some cases. Rich suggested another level to the procedure: before the technical notice on paper, send out a note on USMARC asking for discussion on impact. This idea was refined even more so that more time is allowed for notice and preparation: a) Post a notice on the USMARC list of intent to propagate a change across formats, with a six week period to raise a red flag on any negative impact. b) Distribute an official, printed technical notice about the propagation to USMARC subscribers with a 90-day period to respond. c) Include the change in the next edition of the format. d) System implementation. The discussion revolved around the use of the USMARC list. Are Community Information catalogers and vendors signed up? Or, is there a separate CI-Marc list? Louise Sevold said that she will take on the responsibility for getting more CI users signed up to USMARC. Larry wondered about the noise level of USMARC. People reported the activity level is not constant, it is certainly not like Auto-Cat. Sally said that LC is always open to suggestions on how to better moderate the list. Sally also emphasized that the intent is to use the fast-track procedure in the case of straight adoptions only (little or no system impact expected). Paul Weiss made a motion to approve a fast-track procedure as developed during the discussion. Flo Wilson seconded his motion. Eight members voted in favor of the motion and no members voted against it. ----------------------------------------------------------------- DISCUSSION PAPER #91 : "Machine Generation Flag in USMARC Authority Records" Given that there was time to spare at the end of the day's agenda, Priscilla suggested that the Committee stay on to discuss DP #91, a hold over from the day before. This was agreeable. Sally McCallum introduced the paper. The Cooperative Cataloging Council Series Authority Record (SAR) Task Group requests a data element of some type to represent authority records initially generated by machine. The Task Group believes that this information is important in the context of authority files where there is a mix of human- and machine-generated records. This coding would help catalog managers understand the overall nature of a particular authority file (providing in essence some file management statistics) and help pinpoint where cross references could be added by catalogers. The SAR Task Group suggested that a new code be added to the 008/33 (Level of Establishment), although the discussion paper fleshes out several different options. Stefan Roger (DataTrek) spoke in support of the SAR request. He characterized the new data element as overdue and discussed the need for both programs and people to be able to distinguish easily the two types of authority records. He detailed one specific instance in a cataloger's workflow (overlaying) where the code would be used actively. Priscilla asked if the real issue was identifying machine-generated records or identifying where there has been no human review. Another in the audience felt that both would be true at times, depending upon the system and database under use. Stefan also discussed using this flag for screening out machine-generated authority records which are no longer needed. John Espley reported that VTLS already has a local flag to show when an authority record has been created from a bib record (it means machine generated, not yet reviewed by a human). The flag changes when a person adds a cross reference. He speculated that most systems have something similar. Young-Hee Queinnec believes that a USMARC data element is a nice idea because it would stimulate more machine generation of authority records. Might also promote uniformity between systems which would be helpful for authority record exchange. Priscilla asked what now exists in the authority record format. It appears that current flags are internal to different systems. Is more necessary? Young-Hee thinks so. Larry Woods sees the desirability of a USMARC code, in order to facilitate authority record sharing as well. He cited the possibility that the CIC libraries might want to share cataloging work. Paul Weiss supported adding new values to existing data elements and emphasized the need to know when human review has occurred. Diane Hillmann spoke up with a clarification: keep in mind two kinds of machine generation of authority records, heading only and heading plus cross references. Priscilla wondered if all incoming vendor authority records would have the same flag -- she can think of different types of vendor records and it might be helpful to track them with different codes. Young-Hee suggested thinking about more than one code too. Gary Strawn discussed how things are done at Northwestern University. Priscilla suggested the codes as helping to track a hierarchy of steps in content evaluation of authority records. Gary Strawn reported that the Program for Cooperative Cataloging (PCC) is looking at three levels of review, but does not plan to tie it to the encoding level. Alice Jacobs (NLM) mentioned that it is hard to track review of authority records, due to amount of editing. Someone else suggested that this be built into systems, based upon calling up a record under a specific function or editing the record in some way. Paul discussed his concern about using the 008/33 (Level of Establishment). He believes the flag must relate to the whole record, and yet the 008/33 is currently defined as relating to the heading only. This problem was discussed in the discussion paper. Paul suggested expanding the values in the 008/33. Sally said she saw a need for management statistics of authority files. Priscilla asked Gary to expand upon the PCC plan. He spoke about these three levels: Minimum Level = heading record plus a 670 field Middle Level = some attempt to generate references Top Level = most perfect form of an authority record The PCC plan emphasizes machine behavior at all levels. Stefan talked about generating an authority record from a bib record; there is no 035 in the authority record. A cataloger, with local control, should then be able to overlay the machine-generated local record with the LC Authority Record. The discussion moved on to the question of retrospective conversion of current authority files. This will be hard to do, except in those cases where a system has an internal flag. Priscilla showed concern for rational movement of records between systems, given how definitions of machine-generation may differ from system to system. Sally asked if the idea for this flag is mature within CCC. It was agreed that it would be useful to ask CCC for more clarification: -- to define machine generation to see if there are variations. -- to describe how codes would be used in more detail. Another discussion paper will probably be done once more information can be gathered. ***************************************************************** January 22, 1996 ***************************************************************** DISCUSSION PAPER #93 : "CAN/MARC Changes for Marc Format Alignment" Copies of this paper were posted and distributed in January, too late, because of the snow in Washington, to be received by all. Additional copies had been passed out at an earlier meeting, so that members had a chance only to read it in advance and not to dicuss the paper within their institutions. The discussion paper details changes that the CAN/MARC users have suggested be made to USMARC in order to facilitate alignment between USMARC, CAN/MARC, and UKMARC. Sally McCallum presented some background about alignment between versions of the format. She reported on the December meeting in which impact and timetables had been discussed (see January 18, 1996 USMARC-L message on MARC Harmonization Meeting). She emphasized that, although the format may change, in general the content of the machine-readable records will not. The Library of Congress will provide overall coordination, and no one is yet sure which MARC version will need to absorb the most conversion work. This is still under negotiation. Ross Bourne, representing the British Library (BL), spoke about the benefits of harmonization to the overall bibliographic community. He saw it as a natural extension of use of AACR2 in Britain, the re-adoption of LCSH by BL, the effort to merge the BL and NACO authority files, and the fact that UKMARC does not include provision for special formats. A three-year timetable has been established so need to move along the decision-making process relatively quickly in order to have enough implementation time. The British consensus is being developed via a position paper with discussion by UKMARC users. He expects that BL will be willing to adopt USMARC practices unless there is a conflict in current databases. UKMARC activity has had a low profile in the past, but the BL plans to change this by establishing an email helpline, a listserv for discussion, a Web site with information, and a UKMARC Advisory Group. Young-Hee Queinnec, representing the National Library of Canada (NLC), regularly attends MARBI meetings. This is an example of the history of cooperation with Canada on format development. The Canadian Committee on MARC has just completed a close analysis of the differences between CAN/MARC and USMARC in regards to the Bibliographic and Authority formats; results are outlined in this discussion paper. Young-Hee talked about the important work of the Canadian archival community, which has only recently been added to CAN/MARC. Canada would have preferred to having a little more time but is making every effort to cooperate. Young-Hee stated that Canada is open to negotiation with this caution: there is a commitment to supporting the Canadian Rules for Archival Description (RAD) in CAN/MARC. Rutherford Witthus, representing the Society of American Archivists (SAA), stated that the SAA has a committee on archival exchange which has been watching the development of RAD in Canada. Harmonization of rules between Canadian and American archivists is under discussion. More time is needed. The SAA committee has seen the RAD rules but has not yet seen this discussion paper. Paul Weiss wondered if there is formal communication between SAA and the Canadian archival community. Rudy replied in the affirmative; there is a formal SAA representative, Steve Hensen, who attends some Canadian meetings. Sally suggested that MARBI discussion on USMARC and CAN/MARC alignment first address all non-archival issues, then address archival issues later, thereby giving the archival community more time. She plans to work with Young-Hee on timing. Priscilla asked if supporting RAD could be put off until after format alignment is completed. Young-Hee explained that this is not possible due to the fact that RAD support is now part of CAN/MARC. It was agreed to work in stages as suggested by Sally, but some discussion of the archival issues now will be helpful. There was quite a bit of discussion of the Canadian practice of using fill characters in the field tag (e.g. 6__ or 65_). Shelby Harkin asked if this practice can occur with any field tag or just 1xx, 6xx, and 7xx. Not clear. Priscilla and Sally asked if this would remain a practice internal to Canadian libraries, or if such records would be exchanged with American libraries. David Murrell-Wright reported that these records are communicated by local Canadian libraries to NLC. Robin reported that Harvard now receives Canadian records from LC, processed by LC programs, where the fill character is present. A Harvard filtering program converts to some arbitrary tag. Young-Hee reported that these records are not supposed to be distributed by NLC without upgrading to full MARC; the fill character practice is only supposed to support the Canadian National Union Catalog. There was a review of some of the data elements described in the paper. In many cases, it was pointed out that much needs to be discovered about current usage. BIBLIOGRAPHIC FORMAT: LDR/7 (Bibliographic Level). "Fonds" is similar to the American concept of "collection." Can probably reconcile differences. LDR/17 (Encoding Level). Code 3 is needed for the National Bibliography of Canada according to Young-Hee. An important code. LDR/18 (Descriptive Cataloging Form). Rudy reported that both American and Canadian rules will follow the international ISAD standard. 007/2 (Original vs. Reproduction Aspect). Very controversial. Hard to code now. May be best to make this obsolete, but have to see if in use in databases now. OCLC would like something consistent in this position; a "u" perhaps but not a blank (#). 009 (Cartographic Material). Was valid in USMARC in the past, with a totally different definition and then made obsolete. Young-Hee didn't know why it has been defined as a local field in CAN/MARC, but she will find out. She will see if it would be possible to make it obsolete in CAN/MARC, rather than resurrecting it in USMARC. 028 (Publisher Number for Music). Young-Hee asked if it was common practice to index this field. Most people said no, some said yes. 048 (Number of Musical Instruments or Voices). Celesta is considered a percussion, not a keyboard. Sally suggested changing the name, not the code. 087 (Document Shelving Number (CODOC)). Young-Hee reported that this is a shelving number. There was some discussion about placing this number in the 086, rather than create a new field in USMARC. 260 (Imprint). The concept of "creation" is in 245 in USMARC. Steve Hensen was against use of 260. It is more than just an editorial change. 377+378 (Archival Description). There is a close affinity to the 561 (Provenance Note) field; must reconcile. Canadian archivists wanted a sequence of tags. Sally thinks that systems could display as needed by users, since it may not be possible to have tags in order. 542 (Location of Related Archival Materials Note). Must reconcile with 544 in USMARC. 9XX (Local Fields listed in Appendix D). Not supposed to communicate these fields unless a limited exchange where details are worked out between consenting exchange partners. AUTHORITY FORMAT: $w (Special Relationship). Young-Hee discussed how these $w codes are used to reduce redundant bibliographic searching by library staff. 008/8 (Bilingual Usage). Young-Hee suggested that other multi-lingual countries may find these codes to be of use as a model. She asked if the "g" code would be used by American libraries. Priscilla wrapped up the lengthy discussion by asking for a review of the next steps. Sally will redo the discussion paper, perhaps separating out the two groupings of changes. She will then ask the American bibliographic community to respond about impact issues, at least an initial review by April 15. Then there will be a MARBI proposal giving the American community a second chance to comment. ----------------------------------------------------------------- DISCUSSION PAPER #94 : "Proposed changes to FTP File Label Specifications for Electronic Files of USMARC Records" The European library community has decided to use the USMARC FTP file label specs, rather than inventing a separate specification. Some changes/improvements are under discussion. Larry Dixon from LC is working with the European group as well as OCLC and RLG. RLG responded in some depth to the discussion paper on the USMARC-L list on January 18, 1996. Ross Bourne encouraged discussion at this time, so that American concerns can be discussed by his colleagues who are working on these specifications. Proposal 2 suggests changing "end-of-field" to "new line" to work more easily between different operating systems. Karen Coyle prefers the "end-of-field" character. Perhaps carriage return is good for Unix systems, but perhaps not for MVS systems. Is there something else that is not in use in another context? In the past, people wanted something they could see, but different systems displayed differently (back slash, hash mark, etc.). People seem split on this proposal, according to Sally. She asked for the community to take a look at the issue in more depth. Proposal 3 proposes adding a country identifier at the start of the ORS (Originating System ID) field. Paul Weiss wondered how a receiving system would know if a country code is present or not, if it is optional. Proposal 5 suggests adding a FQF (Format Qualifier) field to supplement the FOR (Format) field since it is seen to be inadequate by the Europeans. Proposals 6-7 would enable the processing of variations in the character set. It was pointed out that ISO 646 is in use by the European library community, but that there are different national versions due to language differences. Therefore, need to be able to show character set variations and extensions in order to process the FTP file. Right now the character set is imbedded in the USMARC record, but the possible implementation of UNICODE makes it desirable to carry character set information in the FTP label. Robin Wendler asked about the label sequence in Section 3. Would it be helpful to move the order around? Sally reported that the Europeans prefer this specific order. Sally wrapped up by asking for final comments by the end of February. ----------------------------------------------------------------- BUSINESS MEETING: Larry Woods reported on behalf of the Character Set Subcommittee. Much mapping work has been completed and there is a glimmer of hope of being finished by this summer. Larry expanded on some of the mapping issues and promised to post a report on USMARC-L by March. Larry is planning on two MARBI proposals, one this summer to discuss mapping and another next winter to discuss the "presence" of Unicode in MARC records. Catherine Gerhart reported that the American bibliographic community must be prepared for a large international meeting on cataloging rules to be held the summer of 1997. CC:DA is collecting issues at this time and plans to hold a forum at the Annual Meeting. Some possibilities for the forum are: content versus carrier, and merging AACR2 and USMARC. Catherine urged MARBI members to participate. Sally McCallum gave an update on USMARC publications. Everything passed through July 1995 for Classification and Authority formats have been published. This spring there will be a Bibliographic Update and a Community Information Update. Sally and others will be working on the Concise publication, bringing it up to date, adding examples, and marking it up so is can be made available over the Web. Sally announced the Web site address (www@loc.gov/marc), stating that it is the easiest way to access information about USMARC including the list archives. Sally also announced that March 1 is the LC system date for Phase 2 of Format Integration. LC catalogers will begin using on March 15, so the community should expect FI records in the third week of March. 5-29-96 jc