MARBI Members:
Priscilla Caplan LITA Univ of Chicago James E. Crooks RASD UC Irvine Shelby Harkin ALCTS Univ of North Dakota William Jones LITA New York Univ Gary Strawn ALCTS Northwestern Univ Flo Wilson ALCTS Vanderbilt Univ Larry Woods LITA Univ of Iowa Jacqueline Riley RASD Univ of Cincinnati MARBI Interns: Josephine Crawford ALCTS Univ of Wisconsin Paul Weiss ALCTS Nat. Lib of Medicine Representatives and Liaisons: John Attig OLAC Penn State Univ Jui-Wen Chang RLG RLG Betsy Cowart WLN WLN Bonnie 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 Maureen Killeen ISM ISM Karen Little MLA Univ of Louisville Sally McCallum LC LC, Net Dev/MSO Susan Moore MAGERT Univ of Arizona Young-Hee Queinnec NLC NLC Marti Scheel NLM NLM Sushila Shah AV Committee Macalester College Lib Patricia D. Siskin ARLIS Frick Art Ref Lib Stuart Spore AALL NYU Law Rutherford Witthus SAA Univ of Colorado Other attendees: Hiroko Aikawa Cleveland Public Library Joan Aliprand Research Libraries Group Melissa Becker FLICC/FEDLINK, LOC Elizabeth Black University of Toronto Candy Bogar DRA Lori Bronars Yale University Kline Science Library Suzanne Bureau CISTI, Ottawa, Canada Kevin Butterfield Univ of Michigan Sylvia Carson Penn State University Ann Case H.W. Wilson Co. Ho-chun Chin Research Libraries Group Sherman Clarke Amon Carter Museum Karen Coyle Univ of Calif Division of Lib Auto Alan Danshin British Library Carroll Davis Columbia University Stuart Ede The British Library Marcia Evans University of Alabama Laine Farley Univ of Calif Division of Lib Auto Patti Page Fields FLICC/FEDLINK, LOC Lori Franz Univ of Michigan Linda Gabel OCLC Nancy Greene Univ of Wisconsin, Madison Julie Grygotis Univ of Michigan, Ann Arbor Robert C. Hall, Jr. MIT/Concord Free Public Library Stephen Hearn Univ of Minnesota Norma Hendrickson Library of Congress Elaine Henjam Florida Center for Library Automation Diane Hillmann Cornell Law Library Lynne El-Hoshy Library of Congress CPSO Bruce Johnson Library of Congress Mary Larsgaard Univ of California, Santa Barbara Fay Leibowitz Univ of Pittsburgh Debra J Leslie Library Company of Philadelphia Sandra Lindberg Broomfield, Co. Kathryn Loadman Univ of North Texas Elizabeth Mangan LC G&M Ralph W. Manning National Library of Canada Catha D. Massey Univ of Georgia Susan Oros Research Libraries Group Cecilia Preston ---- Holly Schmidt Blackwell North America Kathy Schmidt Univ of Wisconsin, La Crosse Jacque-Lynne Schulman NLM Carolyn Sherayko Indiana University Ann Sitkin Harvard Law School Library Gary Smith OCLC Elisabeth Spanholt State Library of Louisiana Steven Squires Univ of North Carolina at Chapel Hill Barbara Story LC Jennifer Swede Univ of Pennsylvania Pat Thomas Stockton-San Joaquim Co Pub Library Sarah Thomas LC Cecilia Tittemore Dartmouth College Diane Vizine-Goetz OCLC Research Office Bob Warwick Rutgers University Robin Wendler Harvard University Lisa Wise NASA Center for Aerospace Info Dolores Yang Univ of Michigan MARBI Recorder: Josephine Crawford University of Wisconsin ***************************************************************** Saturday, June 24, 1995 ***************************************************************** Priscilla Caplan opened the meeting with introductions, a review of agenda changes, and an announcement about the planned Unicode meeting. John Attig asked why the Philadelphia minutes had not yet been distributed, and emphasized that he finds the minutes to be very important. Jo Crawford explained that a draft had been completed but had not yet been reviewed by LC staff and Priscilla due to an email snafu. Catherine Gerhart reminded the group that it had been previously agreed to post draft minutes to the USMARC list. PROPOSAL 94-10 : "Encoding of Patent Information in the USMARC Bibliographic Format" Sally introduced this proposal and remarked that the proposal had been improved due to the Midwinter meeting discussion. There are fewer new data elements, and Linking Entry Fields are used. One noteworthy change is the 013 $d which is a repeatable subfield because of the different types of patent dates. A parenthetical status has been added to give more meaning to the dates (e.g. granted versus effective). It was suggested that the parenthetical information should be published so there would be consistency. Sally agrees. Is there a reason to have a two-digit year? Sally reported this is done to follow the ANSI standard; when it is revised, will change to a four-digit year. David Goldberg reports receiving patents with barcodes at the top of the document. The barcode represents the U.S. Plan Patent barcode. Would it be appropriate to include? Paul Weiss stated that he is uncomfortable with the 013 since it will run out of subfields and there is a break with the USMARC principle of "one record, one document." John Attig is more comfortable with the proposal because he sees patents as a different animal; the proposal introduction explains that patent documents range from the application document to the approved patent document. If this barcode is like a UPC, Young-Hee Queinnec reminded the group there is a place for it in the format. Priscilla believes more needs to be known about the barcode before deciding what to do about it. She isn't so concerned about the scarcity of subfields as Paul. It was agreed to treat the barcode in a separate proposal if it can't be treated like a UPC. Priscilla asked about the 013 $c (Kind of Document), questioning that either a term or a code could be input. However, there are other precedents for this (such as NUC codes in the 040). The codes are published though in the WIPO standard. Paul Weiss asked about the relationship between the 013 $b, the 260$a, and 008/15-17; in the example on page 10, there is an inconsistency. Sally explained that 013 $b is the country corresponding to the number in 013 $a. Acknowledging the larger issue of consistency between dates in variable fields and those in fixed fields, John Attig pointed out that the utilities do not require the two to be the same. Priscilla clarified that the 008 has the date of the document, whereas the 013 has different processing dates (e.g. date of receipt of patent application, date patent granted, etc.). Paul questioned whether or not the 013 $a (Number) doesn't more appropriately belong in a linking entry field of a related record. It was pointed out that there may be multiple times that a patent document is filed by an inventor. Both domestic and foreign applications are made; therefore, the numbering and country must be separate. Is the publisher the patent office of each country? Should there therefore be different records for different countries? Or, should 013 $b be repeatable when the patent goes to different countries; under this approach, the defining characteristic of the 013 is the number. Sally plans to review this issue with Randall Barry. It was suggested that the documentation be more specific in regards to the relator terms in 700/710 $e, whether or not a term or a code, and how to standardize. John questioned placing the qualifying information in parentheses. An alternative would be to make the $e repeatable. Priscilla is not sure that the $e necessarily applies to the date. Paul agrees with John and likes repeating so that the history is kept together. One solution is to couple $d and $e together when appropriate with both repeatable. It was agreed that there is ambiguity regarding the date, the date qualification, and the status. If there are no fatal flaws to the proposal, it was suggested that the proposal be approved, so that patent libraries can use and see how it stands up. Paul suggested provisional approval, due to unresolved issues. Young-Hee pointed out that once records are created in databases, provisional approval is somewhat meaningless. COMMITTEE ACTION : Flo Wilson made a motion to accept the proposal as presented. The motion was seconded by Larry Woods. The motion passed, seven to zero. Sally will pursue the unresolved issues. --------------------------------------------------------------- PROPOSAL 95-13: "Improved Coding for Citation Data in Field 524" Stuart Spore (AALL) discussed the proposed changes to field 524: make it repeatable, add $2 for Source, and add $3 for Materials Specified. Priscilla asked if there has been much use of 524 to date; Stuart believes that the archival community has used. Young-Hee Queinnec informed the group that Canada supports the proposal; one suggested change though is to precede the year with a slash in the $2. There is no authoritative scheme (as of yet) for codes representing the citation source, but LC would publish one if this proposal is passed. In the case where there is no $2, Priscilla wondered if one would assume that the source is the publisher-- yes, or else, have a publisher code. Rutherford Witthus (SAA) pointed out that AMC format users leave out the 260 field, so a "local" code would be used (present in several code lists already). Agreement: Do not put in a $2 unless there is a code from the authoritative list, or there is a "publisher" code, or there is a "local" code. It was suggested that "preferred" should be dropped from the name of the field, once it becomes repeatable. Several agreed since there are a number of competing source schemes for legal materials. However, will this confuse the archival community since they may be using the field from the point of view of "preferred form of citation." A compromise is to leave the name the same but explain in the documentation, especially since name changes do cause much effort as they must ripple through all the network's documentation, even in its briefest forms. Paul Weiss sees some errors in the examples, which he will turn in. Flo Wilson made a motion to accept the proposal based upon the discussion. Seconded by Shelby Harkin. Seven members voted in favor; there were no votes against. ----------------------------------------------------------------- PROPOSAL 95-6 : "Linking Code for Reproduction Information in the USMARC Bibliographic Format" Sally introduced 95-6 by stating that handling reproductions or multiple versions is a continuing discussion, with progress towards a usable solution. The $8 is a method of checkmarking reproduction information buried in a record with both original and reproduction descriptive data. Sally also noted that RLG posted some good questions on the USMARC list, especially whether or not the $8 should be defined across all variable fields, including the 533. John Attig recollects past discussions where a number of people felt that it was preferable to use regular fields for reproduction descriptions rather than using the 533. Involves redefining the concept of repeatability (i.e. 245 field). John would very much like a good analysis with pros/cons before MARBI. Priscilla felt that the discussions leaned towards using the 533 as defined now. Bruce Johnson remembers a preference for the "full-record technique", but certainly not a consensus. He agrees with John that the proposal should flesh this out in more detail before moving forward. If this technique is approved, will it be mandatory or not; John Attig feels a decision is important. Sally McCallum reported though, that LC has a large number of 533 fields and would not split them out into 245, 260, etc. retrospectively. Nothing is clear cut: Robin Wendler reminded the group that the series statement is an access point and therefore needs to go into the 440 or 7xx. Bruce agreed that it is not possible to record all reproduction descriptive elements in a 533 field; those data elements requiring indexing should not be placed in a 533 given most systems. Is the 533 field adequate in many or most cases? Unknown. There seems to be two possible approaches: 1) Break out into all regular fields, with $8 linkage. 2) Use the 533, plus a few other fields when the 533 does not have a defined subfield for the data element. Paul Weiss believes that there may be display problems, because the 533 is not comprehensive enough, with the second approach. Young-Hee Queinnec is also concerned that the result will be a mixed-up record. Canada describes the reproduction in a 534 field where there is a $t. Perhaps add this to the 533? Sally stated that the $8 technique is so powerful, it is important to understand the implications of each approach. Others agreed. Bruce urged a resolution to the multiple versions problem, given the years of discussion. He reminded the group that there is a great number of complaints about current approach. John Attig brought the discussion back to the purpose of the proposal. He speculated that local systems want to be able to create a subrecord for reproductions, to hang off the original. Priscilla said she is hearing less and less discussion about separate records for original and reproduction, and more discussion about a master record with both. If a local system wants to extract the reproduction information to place into a subordinate record, she thinks the $8 technique will work. The Airlie House proposal suggested subordinate holdings records, but it was too hard for the utilities to implemement. This proposal gives local systems a tool to handle reproductions as preferred in the local system. Josephine Crawford explained the use of the master record technique at the University of Wisconsin-Madison. Reproduction information is added by hand to the bibliographic record of the original (a 533 field and other bibliographic fields like a series added entry); then, the holdings record has the 007 field for the reproduction as well as the enumeration/chronology fields if appropriate. The $8 technique would allow more precise coding in the bib record, making it possible for a local system like UW to make improvements to display, indexing, and output programs. Cornell University does something similar. Diane Hillmann had posted an example on the USMARC list where she repeated the basic fields and marked them with the $8; she did not use the 533 field. However, she sees the need to grandfather in existing 533 fields. She also noted that she did not deal with the 007 field. Don't the records get real long and hard to read when different reproductions are posted to the bib record for the same original? Yes, indeed, although Jo Crawford noted that the $8 linking technique could be used by a system to put up an understandable display for the cataloger. Examples posted by Sherman Clarke kept together the fields relating to a particular reproduction. [Clarke's Federal Register example describes 11 different reproductions, for partial serial runs.] Paul Weiss reported that NLM just wrote a specification for distributing one record with both original and reproduction data. The 533 field is assumed. The 007 for a reproduction can be in a holdings record. What about repeating 245 fields, with a $8? Rich Green discussed everything OCLC would have to do if the 245 became repeatable. It was agreed to not get into this, given that current systems cannot handle repeating 245 fields at this time. It was also pointed out that usually the title of a reproduction is not different from the original. The question was then asked which fields can have a $8? It was agreed that all except the fixed fields and the 245. But, what about fields with matching 533 subfields? Should it be mandatory to use or not, or be flexible either way? Flexibility means we could perhaps grandfather in existing 533 fields, but with movement away from the "limited" 533 field. Diane Hillmann asked the group to support catalogers in pushing the state of the art, so that cataloging can remain relevant to users' needs. She applauded the frequent use of repeating fields in the AMC format. No consensus developed at the meeting; technical analysis is needed because MARBI does have to worry about impact on databases. Bruce Johnson pointed out that the issue is smaller if system designers have two specific approaches to handle, rather than complete inconsistency in databases. Rich Greene stated that OCLC is taking the narrow point of view, because the 533 is already used by some programs. Several straw votes were taken at this time. Everyone in the room was invited to participate. -- Can you live with a requirement to use the 533 field, except in those cases where a subfield does not exist for the data element (in which case, use the regular field with a $8)? 31 people voted yes, no people voted no. -- Or, would you prefer for the option to do either? Only nine people voted yes. -- How many people prefer NOT to have the option? 14 people voted yes. Based upon the straw vote, it was agreed to bring a new proposal to the San Antonio meeting where the 533 field will be required. The proposal will list the fields where $8 with an "r" reproduction code is NOT allowed. The proposal will also analyze pros/cons of the following: 1) code $8 if 533 only field with reproduction data? 2) if both $6 and $8 present, what should the order be? 3) deal with the GMD in the 245 field. 4) deal with multiple 007 fields. 5) deal with use of $3. It was also suggested to add a local system example where the "master bib record" approach is used rather than cloning. Should show what is brought in from a utility as well as what is exported to another utility or a union list. ----------------------------------------------------------------- PROPOSAL 95-8 : "Define Field 856 (Electronic Location and Access) in the USMARC Classification Format" Sally introduced by saying this proposal is a straightforward request to add the 856 field to the classification format. The purpose is to provide a link from a USMARC class record to a related electronic resource. For instance, where a visual aid of some sort acts as a guide to the classification number. LC is exploring placing such files on a WWW server, adding a URL to the classification record, and then providing direct access from the classification record to help catalogers work effectively. John Espley pointed out that it is also necessary to add the 856 field to the community information format, in a separate proposal. Young-Hee asked if a link to the image file of a document should be placed in the bib record or a classification record? Conceptionally, the classification record is preferred. However, some systems like VTLS are putting these kinds of URLs in the bib record. It was agreed that this proposal is dealing with a different situation, linking to an "appendix" of the classification schedule. A pointer, not really a location. COMMITTEE ACTION: Flo Wilson moved to accept the proposal as is. Gary Strawn seconded her motion. There were six votes in favor, and no votes against. ***************************************************************** Sunday, June 25, 1995 ***************************************************************** PROPOSAL 95-12 : "Change Subfield $v (Record Control Number) to $u in USMARC Authority Format" Rebecca Guenther introduced this authority format proposal, which has been prompted by the decision last winter to establish a $v for form/genre in subject heading fields. There are two components to the proposal: 1) Change the Record Control Number from $v to $u. 2) Define $v for form/genre subdivision in 7xx linking entry fields. The issue addressed is whether any systems have been using the $v for the record control number. Gary Strawn reported that Northwestern has used the field alot, but never this subfield. LC, OCLC, and Blackwell representatives also reported no use of this subfield. Gary Strawn moved to approve the proposal. There were several seconds. Six members voted in favor, and no one voted against 95-12. ----------------------------------------------------------------- PROPOSAL 95-10 : "Making Field 755 obsolete in the USMARC Bibliographic Format" Rebecca introduced this proposal, referring to the earlier discussion paper (DP 82). It has proved difficult to distinguish between the 655 and 755 fields in practice. Given the discussion at Midwinter, it was originally thought to have an electronic vote. However, there was one person who wrote against the proposal on the list, so it will be voted on in person where there is more opportunity for discussion. Marti Scheel asked if $a is repeatable or not. It is not repeatable (the error in the March '94 USMARC documentation will be corrected). Gary Strawn made a motion to pass the proposal as is. Bill Jones seconded the motion. Six members voted in favor, and no members voted against it. ---------------------------------------------------------------- PROPOSAL 95-11 : "Definition of X55 Fields for Genre/Form Terms in the USMARC Authority Format" Rebecca briefly reviewed the long history of this proposal. At the last meeting, people were leaning toward new fields, rather than use of the 008. LCSH work is underway on the issue of dual use headings (e.g. Artists books can be used both as form and as topic). The proposal presents two options: Option #1: Separate authority records for dual use, defining 155, 455, 555, and 755 for genre/form headings Option #2: Single authority record; use X55 for genre/form only terms and X50 with 008/18 for dual use headings. John Attig asked if he is correct in assuming that Option 2 is preferred by LC due to existing authority database. LC is examining whether there should be disambiguity upfront. Apparently Barbara Tillett prefers two records, but there has been no official decision pending final analysis. Gary Strawn asked, if Option #1 approved, should 008/15 be coded appropriate for use as subject (???). Redefine subject or genre? Sally doesn't think so. Bill Jones says that the code really means that the heading can be used in 6xx fields. Marti Scheel reported that NLM favors Option #1, believing that there would be maintenance problems with Option #2. Young-Hee Queinnec sees some possible disadvantages with Option #1: duplication in indexing (unless indexed together); users having to search in both places (if indexed separately). Bill Jones implemented this in his system and has no problem with duplicate strings because the indexing is based upon the field tag. John asked if duplicate records cause confusion on displays? No, because indexed separately. Pat Thomas preferred two records so that scope notes will be on the appropriate record to explain the different uses. Priscilla sees a preference developing for Option #1. Is anyone else supporting Option #2? No. The group asked that the sentence be deleted about having to create two records and leave that up to the thesaurus. Stuart Spore would like to see a provision for faceting, modifying descriptors. Perhaps in 7xx to correlate AAT and LCSH. John finds this interesting because faceting puts together the string in the record, even if each heading authorized separately. Paul suggests a separate proposal to handle faceting, it is found to be desirable. Sally and Priscilla agree. Larry Woods moved to accept Option #1 of Proposal 95-11. There were several seconds. Six members voted yes, and no members voted no. ------------------------------------------------------------- PROPOSAL 95-9 : "Encoding of Digital Maps in the USMARC Bibliographic Format" The purpose of this proposal is to create a better method for handling digital maps in USMARC. It was introduced by Betsy Mangan of LC Geographic and Maps Division. The current wording for Leader Byte 6 is too restrictive; want to change wording from "printed map" to "cartographic material." In addition, the proposal calls for adding a digital code to 008/25. After Format Integration, prefer for digital maps and paper maps to be handled together, because the content is of primary importance while the physical format is secondary. LC's database only contains 25 digital maps and these will be changed by hand, if the proposal is approved. Paul Weiss believes the proposal raises many, many issues. Not sure if ready for approval. He would like to see MARBI look at the whole picture of multiple formats post format integration. Priscilla was not sure if it would have been better to do a discussion paper first, because there is much support. Betsy added that Project Alexandria is underway now, and Mary Larsgaard from UCSB is here for the discussion. Special material catalogers support this strongly, and request approval. Sally said that the issue came up quickly, and she thought it would be possible to act before looking at the larger issues. John Attig thinks that data archivists will not agree with map librarians. He thinks either choice is incorrect at this point. There was some agreement to change the wording of value "e" in Leader Byte 6. Then the proposal becomes an option, not a requirement for catalogers. Paul pointed out that there are two codes to consider: "e" for printed map and "f" for manuscript map; he thought "g" for digital could be coded in the 006 after Format Integration, but wanted to know what should be done about the "f" code. Betsy thought that it would be ok to not retain "f", because there are other ways to show the manuscript aspect. If the "f" code is retained, it was suggested to change wording to "manuscript cartographic map." The example to consider is a digitized manuscript map. Paul wondered about music codes "c" and "d" since the same split of printed and manuscript occurs; he reminded the group that changing the leader is tricky. Catherine Gerhart is concerned as a practicioner; the computer file cataloger needs the whole picture analyzed before changing practice. Mary Larsgaard from UCSB believes that this is equally true for the map cataloger. Users overall are interested in content, not the container. Priscilla pointed out that Format Integration gives us a mixed world. John thinks that we must work to see how to make acees possible under both aspects, content and container. Need to examine the uses made of the Leader. Catherine brought the discussion back to the practical implications for catalogers; what about the GMD in relation to the proposed new code "g" in 008/25 (Tpe of Cartographic Material). Apparently, the Joint Steering Committee for AACR2 will be looking at the basic concept of the base description of form. A major change could be coming. Sally doesn't think we should wait for these new cataloging directions. It is OK to have an 008 that does not match the 245 GMD. Larry Woods moved to approve the proposal with an amendment: approve the wording changes in Leader Byte 6 (codes "e" and "f"), but delete the change to the 008/25. Fields 006 and 007 can be used to show computer file aspects. Gary Strawn seconded. Five members voted yes, and no members voted no. John Attig is very uncomfortable with solving the narrow issue in this motion. LC staff agreed to write a discussion paper addressing the broader issues. In addition, the question was asked if LC will redistribute those 25 records after recoding them. --------------------------------------------------------------- DISCUSSION PAPER #87 : "Addition of Subfield $l (Uniform Resource Locator) in Linking Entry Fields 76X-78X" Rebecca Guenther introduced this discussion paper which is related to DP#88 and DP#89. It is desirable to add a URL subfield in the linking entry fields for cases when the electronic resource does not have a separate bibliographic record. The paper discusses a couple of options. Since the URN Internet standard is moving along too slowly, it would be good to do something in USMARC. Examples of both electronic books and serials are given in the paper. John Attig said that the USMARC principle is usually use one spot only. Why not just continue with the 856? What is the status of the URL? Priscilla said one should normally use the linking fields to connect to other bib records. This is a link to the object itself. Paul agrees completely; this is a major change in the use of the linking fields. Representing two bibliographic items in one record. But, Sally sees the linking entry field as a citation referral, not two bibliographic descriptions. Larry asked if the URL is for the item being described, or is the URL for the item to which there is a link. The latter. Others asked if the URL standard is stable. Some programs are under development for automatic updating; maintenance issue here. Rebecca is monitoring the URI lists and reported there are too many competing URN proposals still. The URL is like a shelf location, and the URN is like a control number. John summed up his view by saying we are left with a piece of dynamic data which could go in more than one place. Sally reminded the group that often the linking entry field is the only place to put the URL because the related record does not exist. Have to work in this environment now. Weigh the different results for users of moving ahead versus holding back. When people use linking fields, don't they jump to the other record? Sally says not available in many cases. Some felt that if an object is worth pointing to, it is worth creating a bib record for it. Jui-Wen Chang suggested using the $l only when no related record exists; but then harder to maintain when related record does get created. Young-Hee Queinnec suggested a skeletal record with a URL as a practical alternative. Bill Jones said the proposal is encouraging people to create a complex record structure, on a changing situation. Better to encourage a new bib record, and put the URL in the 856 of the second bib record. Stuart Spore suggested renaming the $l to electronic citation where any URL could be input, until the Internet standards settle down. Rebecca pointed out that the URL seems similar to the accepted practice of placing Record Control Numbers in the 76X-78X fields, at least for the object linked to. But others felt that the issue is whether there is any point in duplicating the URL in the linking entry fields if already present in the 856 of its main bib record, particularly because of the URL's transient nature. Bill asked if systems will make automatic connections? Yes, people believe this is happening and will happen more. John Espley pointed out that many classic works are now out on the Internet; would people add the URL to the linking entry fields in all those bib records? Better to use the 856 in electronic object's bib record. Paul agrees; the purpose of linking entry fields is to link to other bib records. Candy Bogar said that DRA systems staff is uneasy about programs looking into various fields to make the Internet link for users. Priscilla asked if users will be impatient if they have to look up another bib record. Paul thinks that there is a system architecture issue here; there could be a hot link to the other bib record, with another hot link to the full-text. Michael Johnson said that DataTrek is another vendor preferring the 856 approach. Stuart pointed out that as more and more versions are available online, it is helpful to display a description before making a link. Separate record better until URN standard available. Sally asked how the user gets to the related record. The DRA system uses the number in the linking entry field (ISSN, ISBN, or Record Control Number). The VTLS system links through the title in the linking entry field $t or uses a number if there. In other words, whatever is indexable can be used. Priscilla summed up the discussion by saying that creating a $l subfield in the linking entry fields is not a good idea because the URL is too unstable. The preferred method is to place the URL in the bib record for the electronic item. The linking field should point to this bib record. MARBI did not support bringing this discussion paper back as a proposal. ----------------------------------------------------------------- DISCUSSION PAPER #89 : "Defining Field 774 as a Component Item Entry Field in the USMARC Bibliographic Format" This is a revision from an earlier discussion paper. Some RLG libraries use a local 789 field, with links down, not up. Lennie Stovel has mapped the 789 field to the 774 so that all libraries could use this technique. Only one data element did not map (789 Subfield $i). The primary question is how to link the component part. The discussion paper lists three options. Given the earlier discussion, will throw out Option #1 (URL in linking entry field). Option #2 involves using the $8 in the 856 and 774 fields; a link code would need to be defined. Option #3 suggests using the Subfield $3 (Materials Specified) in the 856 field; some kind of unique identifier would be recorded in both the 774 and 856 fields. A basic assumption is that, for some collections, libraries do not want the overhead of creating separate bib records, and yet want to make hot links. Paul Weiss sees similarity with one proposed solution to the multiple versions issue. Priscilla asked about AMC records. Paul said describing as a set. John did not think the concept was dissimilar-- a different type of contents note. Sally said that we have a new generation of demands on bibliographic control. We are dealing with new material types. Always had problems with the linking entry fields. Used in systems for additional access, rather than for real purpose. Paul asked about the $i on page 6. The definition is a little vague. There is flexibility so that it can be defined by each specific project. Supposed to be an accession number, item number, or file name; will probably be used for an actual link. Priscilla asked if we really want to dismiss Option #1. The maintenance issue still exists with the other options. She prefers Option #1. Paul said that the sum of 856s is equal to the 245; he sees a tighter bib record with Option #2. John Espley asked if the 774 has some subfields not in the 856. This was clarified: the 774 is a mini description field whereas the 856 is for location and access. Karen Little expects that there will be 856 fields where a link with 774 would be appropriate. Larry Woods suggested thinking about a union catalog, each location with a slide. Sally reminded the group that in 1980 a USMARC principle was established that principle component parts should be described in a new bib record. However, given evolving bibliographic needs and the attempt to improve access through electronic means, the 774 field seems like a good idea to her. Paul agreed that it is useful for serials where only some issues have titles and can be analyzed. After this discussion, there was agreement that Option #1 is not acceptable. Each of the questions on page 8 were discussed in turn. 1) How should the definition of component part be revised in USMARC to include the applications detailed in this paper? Remove "physical part" in the definition. Component part was carefully defined in 1980, when separate record model preferred. The USMARC terminology is different from AACR2 terminology. The AMC people haven't followed the strict definition in USMARC. Bill Jones reminded the group that the definitions are found in the leader, so address this in Leader documentation. 2) Should any new data elements needed for field 774 (Subfield $i and second indicator) be defined across the linking entry fields or be restricted to this field? John Esley wondered about the 787 field. Does the definition fit? Some say no, some say yes. RLG comments on the USMARC list discussed the 2nd indicator: define if additional display constants are needed. "Component Part" suggested at the meeting, but it was also felt this may not be understood by users. Won't work if there are different uses of 774. Agreed to define the second indicator. There was not a consensus about extending the 2nd indicator across the other linking fields (some felt good idea to be parallel, others felt to wait until there was a need). 3) Should field 774 be defined to include all of the subfields of the Linking Entry fields 76X-78X? Yes. There will be more uses than those described in the paper. 4) Which option is preferred for linking the 774 field to the eleectronic item? Is it necessary to have more than one technique depending upon the situation? Option 2 preferred by many in the room. However, Young-Hee Queinnec stated that Canada prefers Option 3 as being the least disruptive. Paul said that the problem is when there is no $i. He suggests that both techniques be acceptable in the proposal. Priscilla thinks people can use Option 3 now. MARBI should approve Option 2 in specific situations. 5) If Option 2 ($8 technique) is selected, should the subfield $8 link code be defined across linking entry fields, across bibliographic fields, or restricted to field 774? Can't fully answer without more examples. Subfield $8 has been restricted by type, not by field so far. Paul Weiss suggested looking at music examples. 6) Is it necessary to sequence the 774 fields? No, not beyond what is already available in $8. 7) Should the second indicator for Display Constant Controller be used? Yes. In all 76X-78X fields or only field 774? Both opinions expressed. Should other display constants be defined? Perhaps. ----------------------------------------------------------------- BUSINESS MEETING: Bibligraphic Update #1 has gone to the GPO printer. Today's changes will be folded into the Authority Format update. Final edition of Format Integration document is out, and members will receive copies. 29 classification schedules are done, with nine to go plus proofreading and editing. There have been internal meetings at LC on SGML within USMARC. Want to draft a formal DTD. Need external funding to do this. Year 2 of Format Integration is pretty much on schedule. If there is slippage, will extend out to Jan or Feb. of 1996 only. John Attig if there is any chance of an up-to-date concise? Electronic Concise up to date except authority. All MARBI proposals kept online with cover sheet showing disposition. Marti Scheel asked if there is any more information on dates in the 006 and 008 fields? Use of "u" in Date1 or Date2 (e.g. 19uu). Sally said they are working on it as quickly as possible. What about Discussion paper #84 on 100 years of LCCNs? LC staff prefer a short-term solution now, because there are lots of records to load now. Larry Woods reported on the Character Set Subcommittee. Will put together another interim report and send out on the USMARC list. Basic and extended latin script table is done. Also, three Greek characters and subscript and superscript. Cyrillic, Hebrew, and Arabic characters look easy to map because there are ASCII clones. But have identified 10 characters in USMARC that are not present in Unicode; will request that they be added to Unicode. And, there is one Hebrew character that maps to two Unicode characters, so have to resolve this conflict. ***************************************************************** Monday, June 26, 1995 ***************************************************************** DISCUSSION PAPER #86 : "Mapping the Dublin Core Metadata Elements to USMARC" Rebecca Guenther introduced this paper, explaining that it was written as a result of the Dublin "metadata" workshop held at OCLC in March. The workshop brought together parties active in the Internet, electronic publishing, and librarianship. The result is a beginning: 13 optional core data elements to be supplied by the creator of an electronic resource (called "Dublin Core"). These data elements all are repeatable (although more specific rules can be defined for subsets) and can be expanded for specific uses. In addition, the data elements can be mapped to several transport syntaxes, not just USMARC. Rebecca sees a need in USMARC to have a code in the leader to show that a USMARC record has been created by extracting these Dublin data elements from an electronic resource; one can than envision a cataloger enhancing such a record once the data elements are captured into a cataloging database. This in part answered John Attig's question as to the purpose. Sally explained that another purpose is to provide some standard description as part of the electronic resource itself. Even though transitory perhaps, it will provide some measure of bibliographic control which is better than what we now get from authors. Paul Weiss asked who will give the final stamp of approval on the Dublin data elements. Not determined. The IETF may establish a working group on metadata. Is it then worth making the effort to map? Priscilla felt that a discussion of the data elements is useful at this time, since the Dublin work will be discussed at various international meetings in the future, and will affect the development of the Uniform Resource Characteristic (URC). See the Web document mentioned in DP #86 for more details. Karen Coyle asked for clarification about the date mapping to 260 $c. She wondered if we might get other data, like a version number. Rebecca responded that there had been another data element for edition/version but it was dropped due to poor definition. Attig reminded everyone that we currently use dates to monitor editions. Karen asked about a date attached to the description. Priscilla said that there is a version number assigned to the metadata, like the 005. Sally said it depends upon the context-- the metadata may be packaged with the file or may be extracted and available elsewhere. Karen's last question involved a user being able to find the most recent version of a file, since various copies/versions may be stored around the Internet. Attig sees this as a major record management issue, with too many unknowns at this point. Priscilla said it was up for the various groups and task forces to work out this problem. A member of the IETF in the audience (Cecilia Preston) asked why this is important. Answer: so that a user has some assurance of consulting the up-to-date version, when this is important. The meeting moved on to discuss author and agent (author is considered to be one type of agent). Priscilla reported she doesn't like the "Other Agent" terminology; others agreed. In the author field, the name "should be given in the natural sort order of the language being used" but Priscilla thinks that perhaps the final report changes this to inverted order. Apparently, the current intent is to invert both Author and Agent names, if this is the natural language convention, but currently there is a discrepancy between the author and agent descriptions. Gary Strawn asked for this to be verified. Gary also asked if the two Von Neuman names on page 6 represent the same person. Unknown. Diane Hillmann has advocated for the author field, and she is comfortable mapping this into a 7xx field. She is concerned though about losing the "other agent" distinction if both are mapped to the 7xx. This will be solved because the Other Agent should have a ROLE subelement which can be mapped to the $e (Relator Term). Paul Weiss also thinks putting both fields into the 7xx field is best at this point. The consensus was that the two data elements (Author and Other Agent) should be merged. Gary Strawn questioned why personal names will not have a ROLE subelement, whereas corporate names probably will. Priscilla thinks this is an oversight. Attig believes more attention needs to be given to definitions and version control. In regards to subject access, it was agreed that an indicator code for controlled subject headings (with specific codes for specific thesauri) and another code for uncontrolled headings would be helpful. Rebecca said there is now a SCHEME subelement for the thesaurus. Several "title" issues were discussed. First, there are big system implications for handling repeatable 245 fields. Second, titles are NOT required (although Attig felt the creator of the file will put some importance into supplying a title). Third, a supplied title field may actually be equivalent to supplied keywords. Some were surprised at the Coverage field describing spatial and temporal characteristics of the object. Apparently, there was a strong lobby for it, causing the Dublin dozen to expand to the baker's dozen! John Attig suggested a different mapping: the 522 for spatial) and 523 for temporal (instead of 034 or 255). Paul thought the coverage label should be changed if limited to spatial or temporal data; Priscilla agreed. Paul thinks that the Object-Type will be hard to map. Other possibilities are 300, 655, 653, or 516. Priscilla brought up the question as to how to best integrate these outside records into OPACs, suggesting a code in Leader 18 to identify them. This might work, thought Rich Greene, but a 040 $e would also be helpful. He thinks these records might go into an auxiliary file or might be integrated into the main OPAC file. Betsy Cowart would like the encoding level to be partial or preliminary, rather than Leader 18. Paul likes 040 $e DUBL as a way to sort out the source of the cataloging data. There was some agreement that there should be a single code for descriptions following the Dublin core. Stuart wondered if two institutions couldn't map differently? Yes, this might happen, but a standard will be helpful given record sharing. To wrap up, Priscilla suggested more discussion on the USMARC list. She will send out a message indicating the Web address of the Dublin report, and asking for discussion. ----------------------------------------------------------------- DISCUSSION PAPER #88 : "Defining a Generic Author Field in USMARC" Sally McCallum introduced this paper by pointing out that the use of the USMARC standard is expanding in many new directions. The fine distinction between types of authors, main and added entries, etc. is hard to sustain in some of these new situations. The paper suggests three solutions to this problem: 1) Use 7xx fields in a non-standard way (done now at times) 2) Relax 7xx definition, and add an "unspecified" indicator 3) Establish the 720 field for author names not formulated according to cataloging or thesauri rules. Paul Weiss thinks that the third option is a good idea, when incoming records have names which cannot be mapped accurately to 1xx or 7xx with current indicators. He saw the need for a broader field name for 720 than Author (but not Agent!). Young- Hee Quiennec suggested using fill characters for the tag when unknown (that is, 7||$a). John Attig didn't think this was possible as a tag must consist of ASCII characters to validate the tag against a table. Paul pointed out that sometimes a blank can substitute as a fill character but other times a blank has a specific meaning in USMARC. Priscilla thought this suggestion, although intriguing, would create havoc in existing systems. Diane Hillmann supports the 720 idea, because the more we ask the Internet community to do, the more unrealistic our expectations are. For workflow purposes, reported Marti Scheel, NLM would like an indicator to show if a name is under authority control or not. These records could be handled separately or not at all, because integration into current workflow doesn't seem realistic. John is not sure if this indicator would have any value. DP85 is related to this issue; if a generic author field were available, this may satisfy NLM's needs. Rich Greene said the heading comes in and you have to deal with it. If there is no distinction between personal and corporate names, you can try to match them against database. You have to do something in order to index them (at least in OCLC's system). Another possibility might be to create a general author index, but this has implications for OCLC's charging scheme. Priscilla said that local systems can usually distinguish between names under control and uncontrolled names in a keyword index. Larry Woods made a general observation regarding what is currently happening at Stanford University. He sees a trend toward loading of records with no intervention by library staff. Priscilla agreed. Question 1 on page 6 was discussed a little above, but no clearcut direction emerged. In regards to Question 2, the consensus of the meeting was to go with a 720 Name field. Marti suggested the field name "Personal Name or Other." Others suggested just "Name". In regards to Question 3, some subfielding in the 720 field was preferred (especially, $a and $e). However, a first indicator code for type of name (personal, corporate, conference) was not supported; better to map to the proper 7xx field if type of name is known. However, Karen Coyle would like to avoid incoming fields with no subfield designation ending up in a proper 7xx field. Robin Wendler suggested each system would make its own mapping decisions, based upon how much detail is available in the incoming record. Give the option for distinguishing between personal/corporate/conference, with option to set indicator to unknown if not supplied. John Attig suggested further exploration of the indicator issue. Question 4 asks if an indicator for form of personal name would be helpful to improve indexing (i.e. inverted form, direct order, or unknown). This will support machine processing and improve search results. Sally agreed to flesh out these issues in a proposal for a later meeting. ----------------------------------------------------------------- DISCUSSION PAPER # 85 : "Changes to Personal Name First Indicator Values" NLM has requested the addition of a new first indicator value for the 600 and 700 fields: value # (blank) meaning "no information provided." The new indicator would be used for when non-AACR2 records like Medline records are mapped to USMARC. Betsy Cowart wondered if a fill character wouldn't suffice as well, without defining the blank. Bill Jones pointed out that some authority programs use indicator values in authority processing, and others do not. Karen Coyle reported that, when the Melvyl loading program deals with the Medline tapes, the indicators are left blank and this does not affect Melvyl indexing. On the other hand, David Goldberg said NAL has discovered the same problem with Agricola records, as attempts are being made to create a single database composed of both the NAL OPAC and Agricola records. Marti urged one of two solutions: define the blank indicator value or establish the 720 field with a personal/corporate/conference indicator. John Attig asked, of these two solutions, which is the least disruptive to existing systems? The second change is suggested as a way to cut down on differences between USMARC and UKMARC, thereby improving the ability to share authority records under the NACO program. Both formats have the same indicator with the same values, but the applied definitions for single and multiple surname are different. Before dropping the distinction between single and multiple surname, it is important to know if systems make use of this indicator for some purpose (i.e. for filing or indexing). Bill Jones believes that the indicator value for multiple surnames is helpful in authority processing, perhaps for creating an automatic cross reference or for database maintenance reviews. He doesn't think systems are using this indicator for filing purposes though. Someone asked if any British systems use the indicator codes for filing? Unknown, although Sally reported that the British Library staff are comfortable with dropping the indicator value. Betsy Cowart asked if authority records would be redistributed if the indicator values are changed. Sally replied that this probably would not occur. Priscilla asked for a straw vote on the second change. Five people voted in favor of the change, and one person voted against. ----------------------------------------------------------------- DISCUSSION PAPER # 90 : "MARC Format Alignment" Sally McCallum introduced Stuart Ede (British Library) and Ralph Manning (National Library of Canada) who are attending the meeting to discuss DP # 90. CanMARC has had good alignment with USMARC for the last ten years, and the National Library of Canada regularly sends a representative to MARBI meetings. However, UKMARC is quite different from USMARC. UKMARC has mostly been developed for book material, with a little coding for non-book materials. UKMARC does not include the ISBD punctuation in the data itself; instead, more subfielding has been defined in its place. USMARC has much more detail for coding non-book materials, and this is seen as an advantage by the British Library. There is interest in our use of the 007 and 008. The British Library initiated the discussions to investigate closer alignment, which might then result in decreased costs and increased record sharing. Impact on databases and systems will be investigated though. Marti Scheel pointed out that the paper discussed the bibliographic format. What is intended in regards to the authority format? Sally said both formats will be analyzed for alignment. Apparently, the UK does not have an official UK authority format. BL does have an internal authority format which will probably correlate well to USMARC. Young-Hee Queinnec discussed a few differences between CanMARC and USMARC. Apparently, differences with name fields were discontinued a few years ago. There are more note fields in CanMARC compared to USMARC. More importantly, CanMARC has a block of 9xx fields for "equivalent headings" (i.e. translation of a heading into another language). John Attig asked about the goal of the alignment. Sally said the goal was for libraries in all three countries to use the same format. Whether or not this can be achieved depends upon system and database impact. The impact may be quite large; the US bibliographic community is probably not ready for a change as large as format integration. Rich Greene said that much alignment will prove to be easy, whereas some will be very hard. Paul Weiss agreed; one community or both will have to convert data in order to achieve true alignment. Stuart Ede explained that British libraries are interested in receiving US copy cataloging over the Internet, without the expense of switching records from USMARC to UKMARC. He expects much enthusiasm for the basic goal, but some trepidation on how to achieve it. The big issue with alignment is how much effort it will take. A process has been worked out, where system impact will be carefully evaluated before proceeding. Sally said that MARBI can expect various papers as a result of the ongoing work. John Espley said that he expected the vendor community to be very supportive of this goal. Although most countries base their MARC format on USMARC, the differences are significant. Right now vendors must write conversion programs when moving data between US utilities and local systems in other countries. Australia, New Zealand, Poland, Spain, Switzerland, and Turkey have adopted USMARC. Members wondered about Japan and Germany. Stuart Ebe reported he has discussed this project with the Head of the Deutches Bibliothek, and an observer may be sent to join meetings in future. Sally reported that the Germans are also looking at AACR2 (the German MARC format supports their own cataloging code).