Date: 2001-11-19Present: Steven Arakawa, Ellen Ellickson, Mickey Koth, Beatrice Luh, Cecile Mandour, Earl Roy, Rick Sarcia, Dajin Sun, Manon Theroux (chair).
Absent: Audrey Novak, David Faulds, Robert Kilheffer, Xinkai Kong.
Agenda: Discussion of Basefile2 QA Results
Eleven members of the group participated in the QA and sent their findings to Manon. Manon looked at the problems reported and tried to interpret them. Some "problems" she was able to explain and some not. She created a web page to summarize the group's findings. The problems are divided into three categories: 1) transactions that failed to load; 2) transactions that indicate problems with the MARS processing; and 3) transactions that demonstrate problems that MARS can't fix. The URL is: http://www.library.yale.edu/cataloging/authorities/basefile2QA.html.
The group started by discussing the examples of transactions that failed to load. A transaction will fail to load if: 1) there is no 928 in the record; 2) there is a 928actape in the record; 3) the tag in the heading has been changed; or 4) the heading itself has been changed since the record was sent out for processing (changes to indicators and tag order do not affect loads). Many transactions failed to load because their bib records did not have a 928 field. The group could think of no workflows that called for removing 928 tags from records. [N.B. Records without 928 fields got extracted but did not get 928 fields added. It was thought that the # of records without 928 fields would be small. Records with 928 fields did not have their 928 dates updated, but the date does not have to be accurate for loads to take place]. It was noted that some of the records with no 928 were in-process and suppressed records and the group was puzzled as to why these were part of Basefile2 instead of Basefile1. Other transactions apparently failed to load because the heading had been updated since the time of the extract or the record itself had been overlaid. Given that an entire year has passed since the basefile extract, it is not surprising that there were so many transaction load failures. The group also wondered whether the recent ORBDEV7 crashes might have affected the loads [N.B. Audrey Novak subsequently confirmed that these crashes did not affect the loads].
We then turned to those transactions that seemed to indicate problems with the MARS processing. The most serious of these problems involved the processing of series headings. Incorrect 830s (sometimes real howlers) are being added to records. Also, 490-0 strings are being changed to 440, sometimes resulting in a conflation of multiple series under a single heading. The group spent much time discussing the ramifications for patrons and staff if the transactions are loaded into ORBIS. They also discussed options for not loading the transactions. These options seem to be as follows:
--Load the transactions, accepting that automated processing will never be perfect. Many records would then have headings for *completely* different series. These would be confusing for both patrons and staff. They might go for long periods without being reported. Patrons may see them and be totally confused but not say anything. Or patrons may never find the records they need because the records have the wrong series heading attached. Even if the headings do get reported to Catalog Management, they will be quite time-consuming to sort out and fix. Support staff may use the uncorrected records as a model and add the same incorrect 830s to their own records.
--Don't load the files with series transactions. This would mean also not loading transactions for conference and uniform titles headings. Do we want the conference and uniform title transactions to load? Has MARS done a good enough job on these?
--If we do want the conference and uniform title transactions to load, we could ask OCLC if they could strip the series transactions from the files and return the files to us so we could load *only* the conference and uniform titles transactions. Not sure if they could do this, how quickly, whether we would be charged extra, how much it would be, etc.
Manon noted that we have already loaded (and are continuing to load) recon records that have gone through the processing. We did not find these series problems during the recon QA. Also we have already loaded the Basefile1 transactions--we did not find the series problems during that QA. As for ongoing processing of current cataloging, which is the next step of the implementation, Manon noted that we *might* be able to change our processing profile. There is an option to *not* process series. There is also an option to perform manual review. We did not select either option for our processing when we set up our profiles. It might not be too late to select one of these if we feel strongly about the inability of MARS to handle series. However, it may also be that the problems with series processing affect older cataloging more than current cataloging, so the profile might be okay for ongoing cataloging.
Manon also noted that there are tentative plans to index 490-0 in the new Voyager system, so that 490-0 would index together with 440 and 830. Patrons want the access and don't really care if a series is not supposed to be traced. No one in the group objected to this idea. However, although 440-0 and 490 would be indistinguishable from a patron's perspective, some in the group still saw a definite staff advantage to distinguishing between the two fields and for this reason are opposed to loading transactions that change 490-0 to 440 and often conflate multiple series under a single heading. It was noted that a 490-0 can function as a "lightbulb" for catalogers who know that they may need to evaluate the field and perhaps look for an appropriate 830 to add to the record. A 440 is more likely to suggest that the field has already been evaluated and placed under authority control. Others thought that a 440 should not be interpreted in this narrow way - that it simply means that the series has been traced in the form in which it appears and no further authority control has been performed. It was noted that this kind of conflation occurs all the time with other headings (personal names without dates that should have dates, etc.) and that catalogers are continually in the process of differentiating among distinct entities.
The group then moved on to some of the other problems illustrated in the report, some relatively minor and some less so. Regarding the problem of 490-0 not being changed to 490-1 when an 830 has been added, the group asked whether 490-1 series were going to be indexed in Voyager. It was noted that this would result in series being indexed twice, once as 490-1 and again as 830, which would be confusing and would also wreak havoc with cross reference structures. The group discussed the problem of 600$x getting changed to 600$t and noted that such changes affect both access and position in index displays. We wondered if any other subject subdivisions besides "Correspondence" would be at a risk for change. The group noted that MARS introduces weird punctuation in conference qualifiers ("smiley-faces"!) and has a hard time with conference subfields. Finally, it was obvious that many of our records have just plain weird headings to begin with and that we can't expect MARS to perform miracles! It was also recognized that MARS does make many good changes and that we should remember that despite our focus on the problem areas during our discussion.
Manon will discuss the QA results and the group's reactions with Joan. She suggested that Audrey should be given the go-ahead to start loading the "regular" transaction files and that everyone think a little more about what should be done with those files that have series, conference, and uniform title transactions. She wants to look a little more closely at Mickey's report on uniform titles and may add some more examples to the web report. Joan has indicated that she would be willing to discuss the series processing with the group. Manon will also talk to Audrey about the transactions that failed to load to see if she can learn anything more. She will inform OCLC of our findings and ask if they can provide any more insight into how the processing works.
Site URL: http://www.library.yale.edu/cataloging/authorities/acac.htm
Comments to: Manon Théroux <email@example.com>
© 2001 Yale University Library