Sunday 1/22/06, 1:30-3:30 p.m. (Sheraton Gunter Hotel Yellow Rose)
The meeting started out with an update on RDA by Jennifer Bowen and the beginning of a slightly scary discussion about how MARC might need to respond to the [r]evolution in content description and access. I won’t include much detail on the general points—they’re covered elsewhere and I’m saving my energy for issues later on today. She described the focus groups that had been held so far where cataloging educators and catalogers had an opportunity to look at what ALA Publications was thinking about web-based products for RDA.
A couple of hot-button issues came up in the report, among them ISBD punctuation and GMD (general material designations). Comments on part I are due by Feb. 7, and comment periods for the subsequent parts come along briskly. Jennifer brought up the possibility of a small group getting together to map RDA data elements to MARC. If a group could be brought together within the next couple of months, Jennifer could report that to the JSC for their next meeting in April. Also on the table are general possibilities for MARBI participating in implementation planning.
John Attig reacted to the report as a MARBI member who has been involved as well in the RDA development. He felt that the invitation to collaborate on the mapping would be very positive, if for no other reason than that examples could be coded properly in MARC (though Jennifer pointed out that there’s not been a decision yet on whether that is desirable). Rebecca Guenther asked how much change in MARC might be anticipated or accepted—Jennifer thought that wouldn’t really be known until after the JSC April meeting.
John A. opined that the separation from description and presentation made implementation decisions very important, and that the impact of these should be explored at the earliest opportunity—he mentioned ISBD punctuation as one example. Rich Greene pointed out that, based on the experience with the transition to AACR2, there might be quite a bit of lead time needed by utilities and others, which doesn’t seem to be reflected in the current timeline. Jennifer agreed that training and planning for transition was important, but that the planning for doing so had just begun.
Proposal No. 2006-05 (http://www.loc.gov/marc/marbi/2006/2006-05.html): Changes to holdings data fields to accommodate ONIX for Serials in the MARC 21 Holdings Format. Linda Miller of LC introduced the proposal, describing the work of ONIX Joint Working Party (JWP) to create the Serials Release Notification (SRN), designed to allow information on serials releases to move from publishers to vendors of various kinds, and ultimately, to libraries.
The important parts of the proposal include the SRN notion of “named unit†which is not the same as the MARC 844, and the disconnect between what SRN and MARC holdings do with caption abbreviations. There had been discussions on the list about the ambiguity of the “named unit†designation, and Linda recounted the trouble the committee had in coming up with nomenclature, and agreed that there was something to be desired. There was some discussion about where communities of practice have done somewhat different things with named units in 844 and enumeration, but no one seemed particularly uncomfortable with that.
Another issue was the repeatability of $2, which was intended to be repeatable but was not so in the proposal (an oversight, apparently).
Rather than vote on this proposal, it was decided to go on to the discussion paper and see if it affected the perception of what should be done with the proposal.
Discussion Paper No. 2006-DP05 (http://www.loc.gov/marc/marbi/2006/2006-dp05.html): Indicating coverage dates for indexes in the MARC 21 Holdings Format. Linda Miller again presented the issues, which revolve around the perennial problem of divergent coverage and publication dates particularly for things like indexes. MARC Holdings doesn’t handle the distinction between the two dates well, but it’s critical in determining how to process SRN data in the real world. Martha Yee commented that there was a lot of support on the list for making this distinction, but because there are so few unreserved alphabetic subfields left, there are real concerns about the best way forward.
John Attig pointed out that the specific information necessary only for indexes is coverage, while publication date is important for all kinds of other things. Because coverage is what is needed by the public, in contrast to publication dates, which are used primarily by acquisitions staff and their systems of prediction, its coverage that is generally used.
Much discussion of the few possibilities continued for some time. Sally McCallum, in a rare demonstration of clutching at straws, asked plaintively whether anyone was distributing SRNs yet and whether we really had any evidence that they would want to distribute both dates, but the group didn’t seem to want to join her in wishful thinking, so problem solving continued.
Ultimately, Martha intervened and suggested that instead of attempting to solve all SRN issues at once, that we take the low road and solve those we could and leave the others for another day. The proposal (2006-05) passed with relief.
Discussion Paper No. 2006-DP02 (http://www.loc.gov/marc/marbi/2006/2006-dp02.html): Addition of coded value to 008 for content alerts in the MARC 21 Bibliographic format. Alan Danskin introduced the proposal, which arose out of some work in the UK on materials for users with disabilities. John Attig pointed out that the proposal was very narrowly scoped but addressed a general issue that the MARBIes needed to consider (though he hoped that some better handle than “content alert†could be used). Rich Greene from OCLC sent up a few red flags about the awful possibilities represented by this proposal, particularly as it used up valuable fixed field real estate (and, it should be noted, real estate that had been used for something else before, which is generally avoided for new MARBI development, sort of like brownfields)
Gary Smith from OCLC pointed out that though fixed fields are marginally better for processing they’re also harder to get right, and he advocated that we “stop using the technology of the sixties†to accomplish our aims (to which statement one of my Peanut Gallery companions said, “Amen, brother.â€)
Business Meeting: the first item was a proposed program for 2007 (or a sneak program for MidWinter) based on the work of Bill Moen’s MARC Content Designation Utilization work reported on yesterday. The usual hot potato conversation ensued, with no one jumping up to volunteer to do program planning (a black hole for the time and patience-challenged). (MFIG Chair beware—the hot potato is headed your way!)
Sally McCallum reported on updates and changes to documentation, the most interesting piece is the move toward PDF versions of things (to replace paper documentation at some point in the future, most likely). History information might move online only, though firm decisions on how various products might change are not yet made. All hands agreed that it would be good to have PDF in advance of print availability, though MARC changes have long been keyed to the emergence of documentation.
Rebecca Guenther reported that there was a new code coming into the MARC language codes from ISO, to designate “no linguistic content†(zxx). Sally also reported that there would be a new MODS release, with documentation enhanced by the DLF Aquifer group working with MODS.
A representative of the Deutsche Bibliothek reported on the implementation of MARC 21 in Germany and Austria. A translation of MARC 21 into German is coming, also mapping of legacy instance data, which is scheduled for completion in 2007. As in the earlier harmonization efforts with CANMARC and UKMARC, some proposals for additions to MARC 21 might be anticipated at the end of the process. Apparently the dogged German practice of cataloging each volume of multivolume works will continue, and they intend not to use 505 tables of contents, which will, of course, make the integration they seem to desire a bit problematic in some cases.
[To be continued …]