Cornell University Library Voyager Implementation Site    

Note to CU-LIB readers - These minutes reference detailed documentation that has been created by committee members, and will be submitted to Endeavor as part of our specification, or used as the test plan once we begin doing data migrations. If anyone would like copies of these documents, please contact Diane Hillmann, chair of the group.

Data Migration Working Group
Meeting Notes
November 23, 1999

Present: Diane Hillmann, chair, Bill Kara, Jim LeBlanc, Scott Wicks, Linda Westlake, Peter Hoyt, Lynne Personius

The agenda:
1. Bibliographic record decisions (Jim)
2. Records with suppressed holdings (Scott)
3. Other acquisitions issues (Scott & Bill)
4. Locations (Diane)
5. Special programming requests (Diane)
6. Deadlines, etc.

First, Lynne reported that we did not have a response from Marlene Harris regarding the special programming requests. Marlene had questions about them, and Lynne referred her to Diane directly.

Jim reported on the bib and holding record specifications, and the plan for testing those.

Bib Specs
As an overview, Jim said that we are trying to get rid of obsolete data in cases where we think we can isolate it. The spreadsheets define these at either the indicator, subfield or entire field level. We discussed the spreadsheet he prepared for bibliographic records first. It covers things we would like to have done as part of the migration that are not covered in Endeavor's data migration questionnaire.

A question about 856 fields, which Lynne agreed to forward to Marlene, is can the 856 be moved to, and displayed from, the holdings record in Voyager?? We learned at training that Voyager uses the contents of the subfield z as display text, and we know that Cornell has put public notes there. We should either get rid of them now, or as part of the migration. In some cases, we do want to keep a subfield z, and we need to run some SAS reports to see what exactly is there.

We also said that we need some SAS reports to investigate the content of 9xx fields.

We talked about the data migration timing - First, apparently the data migration is not connected with the software upgrade to 99.1 - they can be done independently. We would like to have our data migration done during ALA if possible.

Holdings Specs
We have some records that we would like dumped - the details are covered on Jim's spread sheets.

We discussed some call number issues. CTS and Mann have put semicolons in call #s, and in Voyager these need to go either to blanks or to subfield I's. Sometimes, we would not want a blank. Diane is concerned about how this decision might affect call number sorting. Since old call numbers don't have semicolons, adding spaces to just new ones could be a problem. The semicolons were added because of spine labeling. Diane cautioned that we may not use Endeavor's spine label routine, so we should not make decisions because of that.

Also, Jim pointed out that we want to migrate 843 fields, and it isn't included anywhere in the questionnaire.

Authority specs.
See the spreadsheet for details. Lynne asked if we shouldn't try to do some changes before the migration. Diane said yes, and that Lydia has done some good work producing SAS reports to help with preparations. A lot of the work has to be done record by record.

Scott reported on records with suppressed holdings. In a nutshell, we don't want to migrate withdrawn locs unless it is the last one, but we do want selected withdrawn records retained for other reasons. Scott and Bill have developed a list of the situations, provided scenarios, and collected records that are examples. The other reason to migrate withdrawn records was to keep information needed by selectors, who often want to know what was once in the system, and what happened to it.

Voyager allows suppressions both from the OPAC and from staff view, and Scott clarified that we are only talking about the OPAC.

Scott and Bill have compiled detailed documentation, and will send it on to the committee.

Next we discussed some problems with the acquisitions migration. In order to be assigned an order type of "continuation" during the migration, Voyager is looking for an OPR value that is not present for the majority of multivol orders (the scope field in the NOTIS OPR.) If we want our NOTIS multivol orders to migrate as continuations, we need to identify these records and change the data field of the SCOPE. Order type has implications at time of fiscal year rollover.

Endeavor does not automatically migrate all of the data fields that we will need. To compensate for this, Scott and Bill picked a 9xx field, and plan to migrate some information into it to be used once we have converted to Voyager. As further compensation for non-migrated data, they are looking for an archive of acquisitions information from NOTIS, possibly on a CD, for reference after NOTIS goes away. As an example, they need past payment information.

Diane discussed the work that she and Susan have been doing with locations. They have a preliminary spreadsheet for all locations that represents a comprehensive review of CUL. She is going to add a column to document for special programming requests. Examples of things that need special programming are item types, and special formats by location. Also, the piece that will allow us to put text in the subfield k is important. We will be able to get rid of a lot of locations.

We need to learn how to display the information stored in the subfields k and m of the 852 field. Information vital to serials check-in is stored in both of these subfields. We also need to learn if the information stored in these subfields becomes part of the data exported for printing spine labels and if so, how we might be able to manipulate that data into recognizable spine abbreviations. (There is currently the capacity to take the value of the subfield h and replace it with the spine text of your choice. We need similar functionality for subfields k and m.)

A last outstanding item of work for Susan and Diane is to build a table of values for item types.

The result of all of the work on locations is that the number is down to between 180-200 from 400.

We discussed the Cons,Opt location, which was used for the very old digital imaging projects. It seems that these records may be updated prior to the final migration because of the schedule for the IMLS grant. Someone needs to let tech services know when they can be changed. For those, we can use a current location, and not display the old Cons,Opt if any are still there.

Deadlines
We had targeted Dec 1 to complete the specification, but would like to have until Dec 6. Lynne will call Marlene and let her know.

Lynne is also still talking with Endeavor about the schedule for the data migration tests.

Lynne Personius, recorder, 11/24/99


- Library Management System Implementation Site - Cornell University Library - Ithaca NY -
last modified on: Oct.6, 1999