MARBI members:
Martha Yee, Chair ALCTS UCLA Film and Television Archive Marilyn Carbonell RUSA Nelson-Atkins Museum of Art Patricia French, Intern LITA University of California, Davis Helen Gbala LITA Innovative Interfaces Wei Jeng-Chu RUSA Worcester Public Library Bruce Rennie RUSA Kansas City Public Library Jacqueline Samples ALCTS North Carolina State University Adam Schiff ALCTS University of Washington Stephanie Schmitt, Intern LITA Yale Law Library Marc Truitt LITA University of Houston
Ex-Officio Members:
Alan Danskin British Library Sally H. McCallum Library of Congress Marg Stewart Library and Archives Canada
MARC Advisory Committee Representatives and Liaisons:
Joe Altimus RLG Research Libraries Group John Attig OLAC Pennsylvania State University Paul Cauthen MLA University of Cincinnati Sherman Clarke VRA New York University Bonnie Dede SAC University of Michigan Eugene Dickerson NLM National Library of Medicine John Espley AVIAC VTLS, Inc. Michael Fox SAA Minnesota Historical Society Rich Greene OCLC OCLC Rebecca Guenther LC Library of Congress Robert Hall PLA Concord Free Public Library Kris Kiesling SAA University of Texas, Austin Gail Lewis MicroLIF Coughlan Publishing Susan Moore MAGERT University of Northern Iowa Elizabeth O'Keefe ARLIS/NA Pierpont Morgan Library George Prager AALL New York University Law Libraries Tina Shrader NAL National Agricultural Library
Recorder:
Jacqueline Radebaugh LC Library of Congress
Other Attendees:
Penny Baker Clark Art Institute Jennifer Bowen University of Rochester Colleen Cahill Library of Congress Carroll Davis Library of Congress Linda Dujmic Carnegie Mellon University Betsy Eggleston Harvard University Lynn El-Hoshy Library of Congress Jonathan Furner OCLC Kathy Glennan University of Maryland Reinhold Heuvelmann Die Deutsche Bibliothek Diane Hillmann Cornell University Terry Hurlbert Carnegie Mellon University Charles Husbands Harvard University Kara Hyde Serials Solutions William Jones New York University Mary Larsgaard University of California, Santa Barba Bill Leonard Library and Archives Canada Elizabeth Lilker New York University Jimmie Lundgren University of Florida John Maier Pratt Institute Giles Martin OCLC Christine Meyer University of Minnesota Linda Miller Library of Congress William Moen University of North Texas Lauren Moffa Harvard University Mary Ann O'Daniel Florida Center for Library Automation Ed O'Neill OCLC Tod Olson University of Chicago Susan Pyzynski Harvard University Steven Riel Harvard University Diana Shonrock Iowa State University Beth Siers Massachusetts Institute of Technology Gary Smith OCLC Laura Snyder University of Houston Daniel Starr Metropolitan Museum of Art Gary Strawn Northwestern University Manon Théroux Yale University Bruce Trumble Harvard University Jay Weitz OCLC Robin Wendler Harvard University Matthew Wise New York University
Notes:
Saturday, January 21, 2006
Martha Yee (ALCTS), MARBI Chair, opened the meeting by asking committee members, representatives, and liaisons to identify themselves. The proposed agenda was adopted and the minutes of the previous meeting (www.loc.gov/marc/marbi/minutes/an-05.html) were accepted by a voice vote.
Dr. William E. Moen, Associate Professor at the University of North Texas, School of Library and Information Sciences, presented information about a current research project that is analyzing catalogers' use of MARC 21 content designation. The research project, funded by the Institute of Museum and Library Services (IMLS), is analyzing over 56 million MARC 21 bibliographic records from OCLC's WorldCat database to provide an empirical base on cataloger use of MARC content designation. Preliminary frequency count analysis on the records has been completed, and reports are available on the project website: www.mcdu.unt.edu. The next phase of work includes:
In addition, Dr. Moen expressed his interest in helping MARBI or another committee to sponsor a program that will present the study's research results and implications at the 2007 ALA Conference.
Data reports are available at: www.mcdu.unt.edu.
Paul Cauthen (MLA) introduced the paper. Proposal No. 2006-01 (www.loc.gov/marc/marbi/2006/2006-01.html) discusses the changes needed to incorporate IAML (International Association of Music Libraries, Archives, and Documentation Centres) form and genre codes in MARC 21 field 047 (Form of musical composition code) and how to code field 008/18-19 (Form of composition) if only IAML codes are used. The paper stems from Proposal 2005-08 (www.loc.gov/marc/marbi/2005/2005-08.html), "Changes to accommodate IAML coded data in bibliographic fields 008/18-19, 047 and 048," which was partially approved at the Annual 2005 MARBI Meeting. For Proposal 2005-08, the proposed changes to field 048 (Number of musical instruments or voices code) were approved except that the second indicator was defined as "Source of code" instead of the first as indicated in the proposal because the first was previously defined. It was also decided that field 047 (Form of musical composition code) changes would be reexamined in another proposal, particularly in terms of adopting the IAML codes and how it affects the coding of field 008.
Paul Cauthen (MLA) outlined the issues discussed on the MARC Forum Listserv (www.loc.gov/marc/marcginf.html#marcforum) in January 2006. There was a recommendation to define the second indicator in field 047 (Form of musical composition code) as "Code source" instead of the first since the second indicator was defined as "Code source" in field 048 (Number of musical instruments or voices code).
There was also a suggestion to define a code for field 008/18-19 (Form of composition) that indicates that IAML codes are located in field 047 (Form of musical composition code). The use of the fill characters to indicate that IAML codes are used in the field was not recommended because fill characters currently mean, "No attempt to code." If fill characters were defined to signify that one must look in field 047 (Form of musical composition code) for the composition code, their meaning would become ambiguous. It was also suggested to make field 047 (Form of musical composition code) repeatable for cases in which catalogers wish to input both MARC and IAML codes in multiple 047 fields. Paul Cauthen (MLA) clarified that with 2 minor exceptions, all of the MARC codes are included in the IAML list.
Elizabeth O'Keefe (ARLIS/NA) asked how one would code field 008/18-19 (Form of composition) when one wanted to code more than one composition code in field 047 (Form of musical composition code). Sally McCallum (LC) summarized for the group how one currently codes composition codes in MARC 21 records. If one wants to code one MARC composition code, it would go in field 008/18-19 (Form of composition). If one wants to code more than one composition code, code "mu" (Multiple forms) would go in field 008/18-19 (Form of composition) and the multiple composition codes would be coded in field 047 (Form of musical composition code). Ms. McCallum (LC) questioned, however, how one would code field 008/18-19 (Form of composition) when one wants to use a non-MARC composition code exclusively. Paul Cauthen (MLA) suggested that one use the code "yy" in field 008/18-19 (Form of composition) to indicate that a non-MARC code is located in field 047 (Form of musical composition code).
Adam Schiff (ALCTS) asked how one would code field 008/18-19 (Form of composition) when one wanted to use both a MARC code and a IAML code in a record. Rebecca Guenther (LC) suggested that one codes the MARC code in field 008/18-19 (Form of composition) and the IAML code in field 047 (Form of musical composition code). Unfortunately, however, doing this would not indicate to systems that there is a field 047 (Form of musical composition code) in the record. Sally McCallum (LC) suggested that software would simply need to check for field 047 (Form of musical composition code).
Marc Truitt (LITA) stated that it was "overkill" to define three codes in field 008/18-19 (Form of composition) to indicate that there are composition codes in field 047 (Form of musical composition code). For example, "mu" currently means that there are multiple MARC codes in field 047 (Form of musical composition code). The proposed code "yy" would mean that there are non-MARC codes in field 047 (Form of musical composition code) and code "zz" would indicate that there are both MARC and non-MARC composition codes in the 047.
Gary Strawn (Northwestern University) suggested that MARBI redefine the code "mu" to indicate that field 047 (Form of musical composition code) contains multiple codes and/or non-MARC codes. Sally McCallum (LC) agreed with him. Gary Smith (OCLC) also stated that redefining code "mu" would be easier for systems to implement than defining new codes.
Martha Yee (ALCTS, Chair) motioned to redefine code "mu" in field 008/18-19 (Form of composition) to mean that there are multiple composition codes (both MARC or alternate codes) in field 047 (Form of musical composition code). Field 047 (Form of musical composition code) will be made repeatable and the source of code will be indicated using the second indicator (not the first indicator, as was proposed) with a subfield $2 (Source of code) when necessary. Marc Truitt (LITA) seconded the motion. The vote of the committee was 8-0 in favor of the motion.
Robin Wendler (Harvard University) introduced the paper. Proposal No. 2006-03 (www.loc.gov/marc/marbi/2006/2006-03.html) proposes a method for providing standard terminology for access restrictions in field 506 (Restrictions on access note) of the MARC 21 Format for Bibliographic Data that may be machine identifiable. It also proposes defining field 506 (Restrictions on access note) in the MARC 21 Format for Holdings Data.
Robin Wendler (Harvard University) began the discussion by introducing the history of the request. She explained that a Registry of Digital Masters was defined by the Digital Library Federation (www.diglib.org) in a set of functional requirement documents in 2001, and since then, DLF members have worked with OCLC to implement such a registry by defining required information to be added to MARC 21 records. The Registry became available in OCLC in 2004 and is gradually being populated. Among the original tenets of the Registry is that a registering institution must be committed to preserving the digital object for the long term and that a digital copy must be publicly available, although the public copy need not necessarily be free. The Registry is also required to make its records available for harvesting to facilitate the records' inclusion in both local catalogs and free or fee-based discovery services.
It has become clear that some constituencies are only interested in records for materials that have free public copies, while other constituencies want to track all digital materials, even if there are fees involved or if a single resource can only be accessed as part of a large licensed set. Because of this, Digital Registry participants recently agreed to broaden the scope of the registry by allowing records for digital materials without access copies, provided that registry records carry clear, machine-identifiable indications of when access is open to the public or restricted and whether it is restricted to a limited user group, for a period of time, or indefinitely.
The proposal suggests adding a subfield for standardized terminology to field 506 (Restrictions on access note), plus adding a corresponding subfield $2 (Source) to identify the vocabulary from which the data was drawn. This addition would fulfill the needed function, require little effort to implement, and provide flexibility for different communities of interest to define their own lists of standardized terms or codes. The requested subfield would be optional in MARC 21, although the DLF Registry may decide to require it in its record guidelines.
In the proposal, the DLF suggested some possible values for a controlled list of access terms. However, Adam Schiff (ALCTS) questioned the value phrase, "Soon to be accessible." Robin Wendler (Harvard University) explained that this phrase would be used in records for digitized items that are currently not accessible, however, will be in the future. The possible values mentioned in the paper are only examples, and the list has not yet been finalized.
John Attig (OLAC) asked whether the same content designation defined in field 506 (Restrictions on access note) of the bibliographic format would be defined in the proposed field 506 (Restrictions on access note) of the holdings format. Rebecca Guenther (LC) stated yes. Fields are usually defined identically across MARC formats.
Sherman Clarke (VRA) asked whether codes could be used to indicate access restrictions. Robin Wendler (Harvard University) stated yes, codes could be used. Rebecca Guenther (LC) stated that whether codes or terms are used is determined by the controlled list, which would be identified in subfield $2 (Source).
Martha Yee (ALCTS, Chair) motioned to approve the proposal as written with the small change that the new subfield $f (Standardized terminology for access restriction) contain "data" instead of a "term or phrase" to allow codes to be recorded. Jacqueline Samples (ALCTS) seconded the motion. The vote of the committee was 8-0 in favor of the motion.
Sally McCallum (LC) introduced the paper. Proposal No. 2006-02 (www.loc.gov/marc/marbi/2006/2006-02.html) suggests adding subfields for relator terms to X11 (Meeting names) fields in the MARC 21 authority and bibliographic formats. The paper stems from Proposal No. 2005-06 (www.loc.gov/marc/marbi/2005/2005-06.html), "Addition of subfields for relator terms/codes for subject access to images." Proposal No. 2005-06 proposed defining subfield $e (Relator term) in fields 630 (Subject added entry - Uniform title) and 651 (Subject added entry - Geographic name) and subfield $4 (Relator code) in fields 630 (Subject added entry - Uniform title), 650 (Subject added entry - Topical term), and 651 (Subject added entry - Geographic name) in the bibliographic format so that relator codes and terms could be used to enhance the retrieval of visual materials. During the discussion of Proposal No. 2005-06, however, it was noted that although field 611 (Subject added entry-Meeting name) had subfield $4 for relator codes already defined ,subfield $e was defined as "Subordinate unit," not "Relator term." Because of this discrepancy, the committee decided to consider defining a relator term subfield in field 611 (Subject added entry-Meeting name) in a future paper.
Proposal 2006-02 proposes two options for defining a subfield for "Relator term" in field 611 (Subject added entry-Meeting name): The first is to define a new subfield $j (Relator term) in MARC 21 bibliographic format fields 111, 611, 711 and 811 and the authority format fields 111, 411, 511 and 711.
The second is to redefine subfield $e (Subordinate unit) as subfield $e (Relator term); redefine obsolete subfield $b (Number) as Subordinate unit. This would entail moving any leftover numbering data in subfield $b to its current valid position in subfield $n (Number of part/section of work), and moving any subordinate unit data currently in subfield $e to subfield $b in the above mentioned fields.
Although Option 2 would make all of the subfield definitions in the subject fields consistent, it would violate the longstanding MARC principle that obsolete content designators are not to be redefined. However, because there are relatively few occurrences of either subfield $b or subfield $e in the X11 (Meeting names) fields, this proposed change would not affect many existing MARC records.
Sherman Clarke (VRA) stated that although subfield $j has traditionally been defined as "Attribution qualifier," the use of attribution information in conference records would not occur often. He also felt that the MARC principle not to redefine obsolete content designators should be honored. Mr. Clarke (VRA) thus recommended adopting Option 1.
Gene Dickerson (NLM) stated that because NLM has relatively few records containing either subfield $b (Number) or subfield $e (Subordinate unit) in the X11 fields, it recommends adopting Option 2 and redefining subfields $b and $e.
Sally McCallum (LC) reiterated Pat Riva's (McGill University) suggestion that she e-mailed to the MARC Forum Listserv on January 13, 2006 at 11:59:44 that describes a phased approach to redefining subfield $b (Number) and subfield $e (Subordinate unit) in the X11 fields. She suggested that time be allowed to change existing records and then redefine subfield $e (Option 2). (http://listserv.loc.gov/listarch/marc.html).
Joe Altimus (RLG) reported that if Option 2 was adopted, record processing agencies that rely solely on machine processing of MARC records would have no way to ascertain when subfield $e should be changed to subfield $b in an X11 field. He recommended that MARBI define subfield $j for relator term.
Bruce Rennie (RUSA) suggested coding only subfield $4 (Relator code) in the X11 (Meeting names) fields since it is already defined. Elizabeth O'Keefe (ARLIS/NA) stated, however, that some systems process only relator terms and not relator codes.
Sally McCallum (LC) suggested that the MARC community may want to wait until the library community shifts to the RDA (Resource Description and Access) cataloging code before making any changes to the X11 MARC fields. Martha Yee (ALCTS, Chair) agreed. Marg Stewart (LAC) however, stated that although the JSC (Joint Steering Committee for the Revision of the Anglo-American Cataloging Rules) (www.collectionscanada.ca/jsc/rda.html) promotes the use of relators in MARC records, the actual RDA rules will have no impact on the use of relator codes and terms.
Marc Truitt (LITA) stated that although Option 2 is the "emotional favorite for catalogers," Option 1 is a better solution since it follows MARC principles. He motioned to adopt Option 1 (Define subfield $j for Relator term) in the MARC 21 formats X11 (Meeting names) fields. Bruce Rennie (RUSA) seconded the motion. The vote of the committee was 8-0 in favor of the motion.
Sally McCallum (LC) introduced the paper. Proposal No. 2006-04 (www.loc.gov/marc/marbi/2006/2006-04.html) summarizes the discussion on the Unicode-MARC Discussion Forum Listserv (http://listserv.loc.gov/listarch/unicode-marc.html) for converting Unicode to MARC-8 for systems that cannot currently handle Unicode-based records. The List consensus was for defining a placeholder character that could be substituted for each Unicode character that is not mappable.
There was general agreement that the technique for the conversion of Unicode to MARC-8 needed to be cheap and easy to implement. Two classes of techniques were considered by the group. The lossy technique would allow data to be lost and not be recovered. The lossless technique would allow data to be carried over into the MARC-8 environment in a coded form and could therefore be recovered on reconversion to Unicode.
Four techniques were discussed by the Forum. These are:
Gail Lewis (MicroLIF) reported that the MicroLIF community's preference is to either drop the unmappable character or use a replacement character, such as the fill character (|), that is already defined. Gary Smith (OCLC), however, stated that the proposed lossy approaches do not meet OCLC's record needs. He suggested that MARBI approve both a lossy and lossless solution.
Gail Lewis (MicroLIF) maintained that if the placeholder option is selected, the code must already be defined and validated within an ASCII table. Sally McCallum (LC) stated that the Unicode-MARC Discussion Forum Listserv preferred using a non-defined character. However, if MARBI adopts the dual technique proposed by Gary Smith (OCLC), the fill character (|) would be easier to implement.
According to Sally McCallum (LC), the Unicode-MARC Discussion List also contemplated preprocessing the Unicode record before the conversion to MARC-8 takes place. One solution to preprocessing is to decompose the precomposed base character/character modifier combinations using the Unicode Normalization Form D (NFD), which produces exact equivalents. It also primarily applies decomposition to precomposed characters with diacritics. Another normalization process would be to apply the Unicode Normalization Form KD which in addition to the NFD also normalizes to compatible equivalents for some characters, but is not reversible for some of those characters. Gary Smith (OCLC) suggested that the MARC community create its own list made up of characters that need to be decomposed. Sally McCallum (LC) reported that RLG may already have developed such a list.
Marc Truitt (LITA) motioned to accept the Placeholder approach where the fill character is used as a placeholder for the lossy technique. MARBI will consider a second proposal in the summer for a lossless numeric character reference conversion technique. A decomposition list will be prepared for preprocessing normalization by OCLC and RLG. The vote of the committee was 8-0 in favor of the motion.
Sally McCallum (LC) described another area of discussion about the use of Unicode in MARC records. She stated that the MARC 21 Specifications for Record Structure, Character Sets, and Exchange Media (www.loc.gov/marc/specifications/spechome.html) states that the MARC community is currently bound to the MARC-8 environment. However, Unicode introduces additional character sets, such as Tai and Tamil, that the MARC community may find advantageous to implement. She suggested that this specification be taken out so that people may use all of Unicode in MARC records. Gary Smith (OCLC) agreed.
Sunday, January 22, 2006
Martha Yee (ALCTS), MARBI Chair, opened the meeting by asking committee members, representatives, and liaisons to identify themselves.
Jennifer Bowen (University of Rochester) described the JSC (Joint Steering Committee for the Revision of the Anglo-American Cataloging Rules) efforts in drafting the RDA: Resource Description and Access (www.collectionscanada.ca/jsc/rda.html), which will replace the Anglo-American Cataloging Rules II (AACR2). The JSC plans to publish the RDA by 2008.
The draft for Part 1 of the RDA was out for public review when this meeting was being held. Part 1 represents a change in direction of the cataloging code that should make it easier and simpler to implement than the AACR2. The deadline to comment on Part 1 is February 7, 2006. A Web form for sending comments to the JSC is located online at: www.collectionscanada.ca/jsc/revision.html.
According to Jennifer Bowen (University of Rochester), Marjorie Bloss is the RDA Project Manager and Tom Delsey is the RDA Editor. An outreach group for the project is chaired by Matthew Beacom (Yale University). The RDA-L is a discussion list open to all interested parties. Information about RDA-L is online at: www.collectionscanada.ca/jsc/rdadiscuss.html.
Jennifer Bowen (University of Rochester) outlined how MARBI may participate in the creation of the RDA. Some ways are:
John Attig (OLAC) suggested showing MARC examples in future RDA drafts. Adam Schiff (ALCTS) agreed. Jennifer Bowen (University of Rochester) stated that it is currently too early to decide whether RDA examples will be displayed using MARC tagging.
Rebecca Guenther (LC) asked about the stability of the current draft of RDA. Jennifer Bowen (University of Rochester) stated that some RDA data elements may change as more people review the drafts. The JSC will know more about the stability of the RDA by its April 2006 meeting. Marg Stewart (LAC) suggested that after the JSC meets in April, MARBI may consider drafting a RDA to MARC mapping.
Rich Greene (OCLC) reminded the group that training must be considered when the MARC community moves to RDA. Jennifer Bowen (University of Rochester) stated that the JSC plans to put an implementation plan together which will include a training outline.
Linda Miller (LC) introduced the paper which proposes three possible changes to be made to MARC to allow for compatibility with the ONIX for Serials standard (www.editeur.org/onixserials.html). These changes include: 1) the addition of subfield $o (Type of material) in fields 853 (Captions and pattern - Basic bibliographic unit) and 863 (Enumeration and chronology - Basic bibliographic unit); 2) the addition of subfield $2 (Source of caption abbreviation) in 853-855 (Captions and pattern fields) to designate an authoritative source for caption abbreviations used in subfields $a through $h; 3) the addition of subfield $r for language of caption information in fields 853-855 (Caption and pattern). The paper was stimulated by efforts of the NISO/EDItEUR Joint Working Party for the Exchange of Serials Subscription Information (JWP) which has developed a specification and is experimenting using pilot projects to demonstrate the feasibility of using ONIX for Serials as an exchange format for serials subscription information.
ONIX for Serials was strongly influenced by the MARC 21 Format for Holdings Data (MFHD). The committee attempted to specify structures that can be mapped to MFHD so that holdings and coverage information supplied in ONIX messages can be loaded into MARC-based library systems. It is expected that ONIX SRN (Serial Release Notice) and SOH (Serials Online Holdings) messages will be used to update serial holdings in ILS and ERMS systems. This could save libraries considerable resources in that setting up patterns for predictive check-in is highly labor intensive.
To begin the discussion, Helen Gbala (LITA) expressed support for the proposal. John Attig (OLAC) summarized a message sent to the MARC Forum Listerv on January 4, 2006 at 11:17:57 by John Hostage (Harvard Law Library) (http://listserv.loc.gov/listarch/marc.html). In the message, Mr. Hostage (Harvard Law Library) suggested that subfield $o be defined as "Name of unit" instead of "Type of unit." He also suggested that if subfield $o is defined in both fields, there should be clearer guidelines on when to code it in field 853 (Caption and pattern - Basic bibliographic unit) and when to code it in field 863 (Enumeration and chronology - Basic bibliographic unit). Linda Miller (LC) answered that the Library of Congress is open to suggestions for name changes of the proposed data elements. She also agreed that the documentation should have clear guidelines about when to code subfield $o in fields 853 (Captions and pattern - Basic bibliographic unit) and 863 (Enumeration and chronology - Basic bibliographic unit).
Elizabeth O'Keefe (ARLIS/NA) suggested that the proposed subfield $2 (Source of caption abbreviation) in fields 853-855 (Captions and pattern fields) be made repeatable because abbreviations could be taken from different lists, especially if a caption is found in one list, but not another. The committee agreed.
John Espley (AVIAC) questioned how one would code the proposed subfield $r (Language of caption) in fields 853-855 (Captions and pattern fields) when the language of coded data is indicated in field 008/22-24 (Language). Rebecca Guenther (LC) stated that the code in field 008/22-24 (Language) will allow one to generate text for the chronology codes in the 853-855 (Captions and pattern) fields. She stated that the code in field 008/22-24 (Language) will not cover language changes made to captions.
Joe Altimus (RLG) was concerned that there are not many remaining subfields to be defined in fields 853-855 (Captions and pattern fields). Likewise, Discussion Paper 2006-DP05 (Indicating coverage dates for indexes in the MARC 21 Holdings Format) suggests defining subfield $r in fields 855 (Caption and patterns - Indexes) and 865 (Enumeration and chronology - Indexes) for both issue or coverage date of an index.
The committee questioned whether libraries would use language of caption information enough to justify defining subfield $r for it. Linda Miller (LC) stated that many libraries have already expressed interest in knowing this information. Jacqueline Samples (ALCTS) stated that because language of caption probably would not be recorded often, subfield $r could be defined in fields 853-855 (Caption and pattern fields) for language of caption, since issuing coverage dates is only needed in field 865 (Enumeration and chronology - Indexes). Rebecca Guenther (LC) also suggested that field 008/22-24 (Language) could be broadened to record language of caption in it.
Jacqueline Samples (ALCTS) motioned to approve Part 1 (Define subfield $o in fields 853 and 863 and make it repeatable) and Part 2 (Define subfield $2 in fields 853-855 and make it repeatable) in Proposal 2006-05. The Library of Congress will reconsider whether to propose defining subfield $r for Language of caption in fields 853-855 (Caption and pattern fields) or whether the code in field 008/22-24 (Language) suffices.
Helen Gbala (LITA) seconded the motion. The vote of the committee was 8-0 in favor of the motion.
Linda Miller (LC) introduced the paper which discusses how the development of the ONIX for Serials standard (www.editeur.org/onixserials.html), Serial Release Notice (SRN) will necessitate mapping from SRN to MARC 21 because publishers will be communicating this information. SRN is more granular in its distinctions of date types for indexes than MARC, as SRN includes both coverage and issuing dates. Discussion Paper 2006-DP05 discusses the need for making this distinction in MARC 21 holdings field 865 (Enumeration and chronology - Indexes).
Linda Miller (LC) explained that in the MARC 21 Format for Holdings Data (MFHD), there is not a discrete data element for coverage dates, although this information may be useful bibliographically. Often the publication date may be later than the coverage date of the index, however, it is currently not possible to record both dates in field 865 (Enumeration and chronology - Indexes).
It was suggested that most librarians would prefer knowing the coverage dates of indexes rather than the issuing dates. Likewise, Jacqueline Samples (ALCTS) stated that library users also prefer knowing the coverage dates of indexes. It was concluded that for indexes most institutions are recording dates of coverage, not issue dates in the chronology subfields. However, John Espley (AVIAC) stated that issue dates of indexes would be useful for check-in date prediction in some library systems. Sally McCallum (LC) agreed. Adam Schiff (ALCTS) commented that both the issue and coverage dates would be useful to librarians if a particular index became lost. The group agreed.
If issue and coverage dates are to be coded separately, Adam Schiff (ALCTS) asked the group how this might be accommodated in the format since there are few undefined subfields available in field 865 (Enumeration and chronology - Indexes). Rebecca Guenther (LC) reported that subfield $r is the only subfield available in both 85X (Captions and patterns) and 86X (Enumeration and chronology) field blocks. Jacqueline Samples (ALCTS) suggested that a numeric subfield be used for the dates. However, Rebecca Guenther (LC) reported that numeric subfields in the holdings format are defined as "Control subfields," such as codes for sources, etc..
Joe Altimus (RLG) reported that Proposal No. 2006-05 (Changes to holdings data fields to accommodate ONIX for Serials in the MARC 21 Holdings Format) proposed defining subfield $r in fields 853-855 (Caption and patterns fields) for Language of caption. The committee, however, decided earlier in the meeting that LC will reconsider whether to again propose subfield $r for Language of caption in fields 853-855 (Caption and patterns fields) or whether the code in field 008/22-24 (Language) will suffice. Even if it seems desirable to define a subfield in fields 853-855 (Enumeration and chronology fields) for language of caption (subfield $r?), this subfield is not needed in field 865 (Enumeration and chronology - Indexes) for that purpose, so it is still available for issue date (although there would not be correspondence between the field blocks). Thus, because the participants felt that there is need to code issue and coverage dates separately in holdings records for indexes, MARBI decided that a proposal will be presented at the next meeting for defining a subfield for issue dates of indexes in field 865 (Enumeration and chronology - Indexes). Subfield $r in field 865 could be used.
Alan Danskin (BL) introduced the paper which discusses adding a coded value to the 008 field in the MARC 21 Format for Bibliographic Data (MFBD) to carry coded warnings to certain types of content in items for visually impaired users. The need to include this information in MFBD records was initially met by including appropriate statements in field 520 (Summary Note). However, if this information is to be used as a search filter, use of field 008 or other coded data area may also be required.
The source of the paper was by the Revealweb Union Catalogue (www.ukoln.ac.uk/bib-man/projects/revealweb/), a recent initiative launched in 2003 in the UK. The Revealweb Union Catalogue uses MARC 21 bibliographic and holdings formats to provide a web-based union catalogue of materials available in accessible formats in the UK.
Alan Danskin (BL) explained that the values that currently represent content alerts in the bibliographic records of the Revealweb Union Catalogue are the following:
John Attig (OLAC) stated that there was support from OLAC to provide this type of information in the record.
Representatives for the Revealweb Union Catalogue feel that field 008 is appropriate for this information because it applies to the content of the work, not to its physical medium (as with field 007). Although field 008 has been fully defined in the past, field 008/32 has been obsolete for all forms of material since 1990. The alphabetic content alert codes for the new definition of this byte do not overlap with the alphabetic and numeric ones previously defined.
Helen Gbala (LITA) began the discussion by expressing concern about reusing an obsolete 008 position for content alerts. It has been MARC practice not to reuse obsolete data elements. Rich Greene (OCLC) agreed. He stated that OCLC may have problems processing the data because it would not know whether the data contained in field 008/32 represents information about content alerts or the information it held prior to 1990.
Eugene Dickerson (NLM) wondered whether one byte would be sufficient to hold content alert information. Some material may require a combination of content alert codes. Likewise, Rich Greene (OCLC) stated that if a MPAA (Motion Picture Association of America) rating was used, a subfield $2 (Source) may be needed to differentiate the rating from other organizations' ratings.
Gary Smith (OCLC) stated that using the 008 field may promote more coding errors to occur than using a variable field for this information. Likewise, he stated that current systems have the ability to process data using variable MARC fields and that a variable field would be preferable.
John Espley (AVIAC) questioned whether field 521 (Target Audience Note) could be used to hold content alert information. Sally McCallum (LC) reported that the National Library Service for the Blind and Physically Handicapped (NLS/BPH) (www.loc.gov/nls/) at the Library of Congress includes content alert information in its records for its talking book and Braille programs. Stock content alert phrases are placed in repeating 521 (Target Audience Note) fields. The values used by NLS/BPH are quite similar to those needed by the Revealweb Union Catalogue.
The participants agreed to define data elements in the MARC 21 bibliographic format to carry content alerts, Rebecca Guenther (LC) suggested that a proposal be presented at the Annual MARBI meeting in June that proposes using a variable field to hold content alerts. The committee agreed.
Martha Yee (ALCTS, Chair) reported that Dr. William Moen (University of North Texas) requested that MARBI host a program for the "MARC Content Designation Utilization Project" at the 2007 ALA conference. Martha Yee (ALCTS, Chair) wondered whether there is a volunteer from the group to help organize this program. Sally McCallum (LC) reported that MARBI traditionally has not been a committee that presented programs. She, however, suggested that the MARC Format Interest Group might sponsor it. Helen Gbala, chair of the MARC Format Interest Group, agreed to bring this suggestion up to the group for discussion and consideration.
Library of Congress
Sally McCallum (LC) presented the Library of Congress report. She reported that the Network Development and MARC Standards Office (NDMSO) has been converting MARC documentation into XML. NDMSO plans to use the XML to eventually be able to mount its full MARC 21 documentation formats on its website (www.loc.gov/marc/) in both HTML and PDF formats. NDMSO will also make its documentation available in XML. Ms. McCallum (LC) stated that NDMSO plans to make Update No. 6 (October 2005) of its MARC 21 formats available in PDF from an LC website. NDMSO also plans to issue a 2006 edition of its MARC Code List for Geographic Areas (www.loc.gov/marc/geoareas/gacshome.html). This edition will include new codes for Australian territories.
Rebecca Guenther (LC) stated that the ISO 639-2 language code list (Codes for the Representation of Names of Languages-- Part 2: Alpha-3 Code) (www.loc.gov/standards/iso639-2/) includes the same codes as the MARC Code List for Languages (www.loc.gov/marc/languages/langhome.html). Ms. Guenther (LC) also reported that a code for "No linguistic content" has been defined as code "zxx." This code will be used in the future instead of blanks in bibliographic field 008/35-37 (Language). An announcement will be issued soon.
Sally McCallum (LC) reported that a new version of MODS (www.loc.gov/standards/mods/) will be issued soon. MODS was recently adopted by the DLF (Digital Library Federation) Aquifer Project (www.diglib.org/aquifer/), which is built upon the DLF mission to enable new research and scholarship through the development and adoption of technical standards and best practices. Ms. McCallum (LC) also reported that the preliminary draft of the "MARC 21 Authority Format Mapping to MADS Schema Version 1.0" was recently released. It is available online at: www.loc.gov/standards/mads/mads-mapping.html.
German National Library
Reinhold Heuvelmann (German National Library) presented the German National Library report. He discussed how German and Austrian libraries are currently adopting the MARC 21 formats (www.ddb.de/eng/standardisierung/formate/marc21.htm). Mr. Heuvelmann (German National Library) sent this report to the MARC Forum Listserv (http://listserv.loc.gov/listarch/marc.html) on February 2, 2006 at 16:16:57.
Germany and Austria have traditionally used the MAB (Maschinelles Austauschformat für Bibliotheken = Machine-readable exchange format for libraries) (www.ddb.de/eng/standardisierung/formate/mab.htm) format since the early 1970s. MAB is loosely based on ISO 2709 (Format for Information Exchange) and RAK (German cataloging rules). During the last few years, MAB has been updated to include segments of other standards, such as Unicode, FRBR and MABxml. In 2001, the German and Austrian library communities began discussing the possibility of moving to the MARC 21 formats and in 2004, it was decided to adopt MARC 21. It is planned that the harmonization project between MAB and MARC 21 will be finished by the beginning of 2007.
The reasons for moving to MARC 21 are:
Financial support for the move has been provided by the German Research Foundation (DFG) and the Andrew W. Mellon Foundation.
A mapping from MAB to MARC 21 will be completed in the near future with the goal of minimizing any data loss. Based on the mapping, the German and Austrian communities will decide which data elements from MAB fit into the MARC 21 structure. Mappings for the coded character sets have already been completed.
Reinhold Heuvelmann (German National Library) explained how they will treat multivolume work descriptions in MARC 21. It is likely that there will be some proposals to MARBI to accommodate this harmonization process.
Sally McCallum (LC) introduced the paper which discusses the incorporation of former heading information into MARC 21 authority records to facilitate the location of instances of the former headings in bibliographic records that may need to be corrected. Ms. McCallum (LC) explained that in 2003, the Final Report of the Task Group on the Function of the Authority File (www.loc.gov/catdir/pcc/scs/tgauthrpt_fin.pdf) was presented to the Standing Committee on Standards of the Program for Cooperative Cataloging (www.loc.gov/catdir/pcc/standards.html). In this report, the Task Group cited several instances where it is not valid to make a reference from an invalid former heading because of possible conflicts with other references and duplication of references upon normalization. The report's recommendation was that former headings should be recorded in a note field to enhance the ability of correcting these former headings in bibliographic records. The report described several specific circumstances where a note would be useful:
The Task Group stated that defining a new note field for former headings would provide a unique place in which to record former headings. It would also enable more automated library catalog amendment processes.
To begin the discussion, John Espley (AVIAC) reported that VTLS currently uses a local second indicator value 9 (which is reserved for local use) in the authority 4XX fields (See from tracing) to indicate former headings of this type. Sally McCallum (LC) suggested that the use of subfield $w (Control subfield) in the 4XX fields (See from tracing), which is already defined in the format, may be a non-local solution. Bruce Rennie (RUSA) stated that coding subfield $w (Control subfield) in fields 4XX (See from tracing fields) would enable library systems to suppress the display of the former headings, however, he wondered if it would also facilitate the flipping of headings. Bill Jones (New York University) suggested that a subfield $w (Control subfield) value could be defined to indicate when not to flip headings, otherwise, flipping headings would be assumed. However, some participants questioned how many systems implement the display codes in subfield $w (Control subfield).
Rich Greene (OCLC) explained that using a note field is an inadequate solution for machine correction of headings in bibliographic records and that using values in subfield $w (Control subfield) of the 4XX fields (See from tracing fields) would provide the specificity needed for such manipulations. He also stated that the proposed note field would primarily be adequate for readability, not machine manipulation. Elizabeth O'Keefe (ARLIS/NA) also stated that if the newly defined field 683 (Former heading) is used for machine manipulation, it probably should include every subfield which is defined in the 1XX fields (Heading fields) in the authority format. Gary Strawn (Northwestern University) suggested that instead of defining field 683 (Former heading), field 688 (Application history note) may be coded for the same purposes.
Sally McCallum (LC) then asked about other data elements that users may want to include in former heading data. She queried whether a subfield for the time span of the former heading would be feasible, helpful, or worth the effort to record. Ms. McCallum (LC) asked if the date span could be given as part of subfield $i (Explanatory text) in field 683 (Former heading) if a specific institution was interested in retaining such information. Adam Schiff (ALCTS) also suggested that users may want to know the association between the canceled LCCN and its corresponding heading. Sally McCallum (LC) then asked whether users would want to record "reason phrases" in former heading information. If this information is desired, Ms. McCallum (LC) questioned how the use of fields 4XX (See from tracing fields) subfield $w (Control subfield) could provide for it. Adam Schiff (ALCTS) answered that the fields 4XX (See from tracing fields) could be linked to the 68X fields (Note fields) using subfield $8 (Field link and sequence number). Rebecca Guenther (LC) stated that subfield $8 linking technique has not been implemented widely in library systems.
Sherman Clarke (VRA) reported that in RLIN, it is possible to review previous versions of authority records. Mary Ann O'Daniel (Florida Center for Library Automation) also stated that it would be very useful to store deleted authority records in a "resource authority file." Catalogers would find consulting deleted scope notes useful. Field 688 (Application history note), however, already provides a place for such information.
Sherman Clarke (VRA) summarized that although the participants favored incorporating former heading information into authority records, they were undecided on whether to use a 4XX field (See from tracing fields) with subfield $w (Control subfield) or to define field 683 (Former heading). The 4XX field option was discussed because it would support accurate machine processing. However, a 683 note field would provide a unique location in which to record former headings. This solution was the only option on which the former committee could agree. Sherman Clarke (VRA) suggested that a new discussion paper be written that further explores these various options, including what values are needed in subfield $w (Control subfield). The group agreed.
Jimmie Lundgren (University of Florida) introduced the paper which suggests adding field 034 (Coded cartographic mathematical data) to authority records for geographic coordinates associated with places. This field would eventually form the basis for rich geospatial searching of library material using geographic coordinates.
In authority records for places, geographic coordinates have been included in note fields (specifically, field 670) cited from authoritative sources to document the place name. However, because the data is recorded in a textual form and is not isolated, it is difficult to utilize the information for a coordinates-based search in the context of the note. Encoding the coordinates in a specific data field amenable to machine retrieval and compatible with other geographic database searching systems would offer the potential for patrons to better retrieve items about a geographic location.
It would be appropriate to include coordinates in authority records because it is important information about the entity described in the authority record. Since this is information about the place for which the authority record is made, one could argue that it belongs in the authority record, rather than in every bibliographic record that relates to that place. In the authority format, the coordinates would apply to the entity described and would be taken from a reliable source such as the USGS (U.S. Geological Survey) Geographic Names Information System (GNIS) record for the place or from a gazetteer.
Ms. Lundgren (University of Florida) introduced six issues that should be discussed. These are:
John Attig (OLAC) began the discussion by stating that OLAC supports adding field 034 (Coded cartographic mathematical data) to the MARC 21 authority format. He recommended that both the bibliographic and authority coordinate data should be handled similarly. Mr. Attig (OLAC) also recommended that geographic experts advise MARC 21 users on how to utilize field 034 (Coded cartographic mathematical data) in authority data.
John Attig (OLAC) then asked about what kind of geographic data is currently recorded in field 670 (Source data found). Colleen Cahill (LC) stated that in authority records for places, geographic coordinates have frequently been included in field 670 (Source data found). They have been cited from authoritative sources to document the place name. Ms. Cahill (LC) also informed the group that coordinates in field 670 (Source data found) are used for human-readability and coordinates in field 034 (Coded cartographic mathematical data) would be used for system manipulation.
A member of the audience asked about how bounding boxes would be handled in authority data. Colleen Cahill (LC) stated that relevant data elements from field 034 (Coded cartographic mathematical data) in the MARC 21 bibliographic format include four subfields that define a bounding box (subfields $d, $e, $f, and $g). These are generally adequate for expressing the westernmost, easternmost, northernmost and southernmost extent of coverage of a map. Coordinates may also be expressed as center point where only two points are given (the same data expressed as east/west and another as north/south). Two more subfields ($s and $t) for G-ring latitude and longitude may also be used. Mary Larsgaard (University of California, Santa Barbara) stated that GIS search systems would utilize bounding boxes most efficiently and want data to the second.
While bounding box is more powerful than center point and used by GIS systems, center point may be all that is available. Ed O'Neill (OCLC) questioned whether there needed to be explicit coding identifying whether the data is bounding box or center point. Participants agreed that this was not necessary because points are treated like bounding box and GIS systems can use them.
Adam Schiff (ALCTS) asked if scale needs to be recorded in field 034 (Coded cartographic mathematical data) in the authority format. Mary Larsgaard (University of California, Santa Barbara) answered that scale is not important in authority data. Adam Schiff (ALCTS) then asked if subfields $a (Category of scale), $b (Constant ratio linear horizontal scale), and $c (Constant ratio linear vertical scale) are needed in field 034 (Coded cartographic mathematical data) in the authority format. The group decided that they should not be included in the authority format.
Adam Schiff (ALCTS) stated that the indicators in bibliographic field 034 (Coded cartographic mathematical data) are not applicable to authority data. These are:
Colleen Cahill (LC) however, recommended that the authority field 034 (Coded cartographic mathematical data) should contain the second indicator value (Type of ring), but not the first (Type of scale). The group agreed.
Rebecca Guenther (LC) then discussed Issue 5 (How would the effective time period that a set of coordinates is correct for a heading be indicated?). She recommended that two subfields be defined for beginning date and ending date. However, Alan Danskin (BL) stated that the authority record defines a geographic place, not the time period of the place. Colleen Cahill (LC) agreed with Ms. Guenther (LC), however, stating that beginning and ending dates applicable to coordinates are needed in authority data. She stated that catalogers would find the historical data of the geographic heading useful.
Rebecca Guenther (LC) then suggested that the source of the coordinates (Issue 6) should be included in field 034 (Coded cartographic mathematical data) in subfield $2. There are several sources that might be used for geographic coordinates since not all are established by the BGN (Board on Geographic Names). In addition, if applying coordinates to subject headings, other sources will be needed. A list of source codes for use with this field will need to be compiled by the Library of Congress. A cooperative effort has recently been initiated to compile a list or database of place area coordinates that when completed will be very valuable source for coordinates of place headings. Colleen Cahill (LC) suggested that the source of coordinates is also recorded in field 670 (Source data found). The group felt that this issue should be further explored as to whether both are needed.
Colleen Cahill (LC) recommended that a subfield be defined in field 034 (Coded cartographic mathematical data) that indicates coordinates of planets. This would assist in recording information for star charts. Adam Schiff (ALCTS), however, stated that field 043 (Geographic area code) could be used to record planet coordinates. The group agreed to further explore recording the coordinates of planets in the authority format.
A member of the audience asked whether a subfield in field 034 (Coded cartographic mathematical data) be included for type of feature. Rebecca Guenther (LC) asked if the type of feature could be associated with the coordinates recorded in the field. Colleen Cahill (LC) suggested that type of features could be recorded in another field in the authority record. Likewise, Lynn El-Hoshy (LC) informed the group that headings of features are usually recorded in the 5XX fields (See also from tracing fields).
Martha Yee (ALCTS, Chair ) suggested that a proposal to define field 034 (Coded cartographic mathematical data) in the authority format be presented at the next meeting with the following points:
The group agreed with Ms. Yee's (ALCTS, Chair) recommendations.
Sally McCallum (LC) explained to the committee why Discussion Paper 2006-DP04 (Indicating work/expression records in the MARC 21 authority format) was taken off of the meeting agenda. According to Ms. McCallum (LC), the paper explored data elements needed in the MARC 21 authority format to indicate that a record is for either a work or expression. It was a follow up to the MARC Report using MARC 21 with FRBR: Record configurations (www.loc.gov/marc/marbi/2005/2005-report02.pdf) that was discussed in June, 2005. At the time, the Library of Congress Cataloging Policy and Support Office (CPSO) asked that the configuration that treats the Work/Expression record as an authority record be explored in greater depth during the Midwinter 2006 MARBI meeting.
However, it was noted that during the discussion of the MARC Report using MARC 21 with FRBR: Record configurations paper in June, 2005, MARBI had decided that the MARC community should continue to experiment with FRBR before exploring what data elements are needed in the MARC 21 authority format to indicate that a record is for either a work or expression. Experimentation would help the bibliographic community know what it needs to do to make bibliographic data more adaptable to FRBR. At the current time, there have been few experimentation efforts reported.
John Attig (OLAC) stated that the University of Rochester created a grant proposal to experiment with FRBR in libraries. Martha Yee (ALCTS, Chair) also described how the UCLA Film and Television Archive uses the authority format to record work records. It also creates separate bibliographic records for expressions which are linked to authority records.
Sally McCallum (LC) requested that institutions experimenting with FRBR describe their results on the MARC 21 Forum Listserv (www.loc.gov/marc/marcforum.html). The group agreed.
The Library of Congress >> Librarians, Archivists >> Standards ( 11/15/2019 ) |
Legal | External Link Disclaimer |
Contact Us |