Berkeley Technical Services Discussion Group Meeting
Wednesday, February 7, 2007
9:00am to 11:00am
303 Doe
Agenda
1. Announcements
-Steve La Follette is the Bioscience Library’s new serials assistant. He can be reached at 2-2532, slafolle@library.berkeley.edu. Welcome Steve!
-As you may have heard, Margy Wilkinson retired. Please send requests for adding vendors, or updating vendor addresses in INNOPAC or BFS to Chris Haight (chaight@library.berkeley.edu). Send monograph payment questions to Thom Long (tlong@library.berkeley.edu.
2. Use of piggyback barcodes on post-it notes in books / T. Perry-Houts, J. Boydstun
For several years now, Conservation has been placing piggyback barcodes on post-it notes and placing these post-its in books being sent off for recasing instead of placing the piggyback barcode directly on the paper. Technical Services also uses this same technique for new unbound monographs. From a conservation standpoint, the long term effect of the piggyback carrier is unknown and thought to be potentially damaging to the paper. The problem with the post-it note is that in the binding process, the books become compressed, causing the post-it glue to really stick to the paper. The result can often be that the post-it will tear or “skin” the paper or leave glue residue when removed. It is thought that this “skinning” is in the long term is less damaging overall than the potential damage caused by the piggyback barcode carrier left in the volume.
After much discussion around the room some short term and long term solutions came up.
Short Term:
-Use only as much post-it as needed. (Make sure the barcode does not hang over the post-it and that as much of the extra post-it is cut off.)
-Place the post-it vertically. (This seems to help in removal.)
-Use Rubber Cement Pik-Up erasers to aid in the removal of glue residue left by the post-it.
-Do not place post-it over any text. (Text is sometimes removed when the post-it “skins” the paper.)
Long Term:
-Inquire about a removable "post-it" type piggyback barcode. (Cost, feasibility, etc.)
-Inquire about a custom, less tacky, perfect size post-it note to be used only for binding.
-Look into placing post-its on a page other than the verso of the title page.
If anyone has any more suggestions please let Jim Boydstun know. Jim will research this problem and get back to everyone.
3. RLIN/OCLC merger / C. Takaro
RLG merger into OCLC - preliminary notes
I attended some sessions at ALA in January about the merger of RLG and OCLC, which is in progress. Currently bib loading from RLG to OCLC is in progress and at the time of ALA 1.3 million new records had been created on OCLC from RLG loading (out of about 8 million records sent). No holdings are being set in this phase - that will happen in a later phase. What follows are my observations/predictions. I am sure that this will need further discussion and possibly workflow modifications when it gets closer - I'm bringing this to Btech now as a heads up.
What this means for our catalogers:
OCLC users are already seeing many more records in Worldcat, and future phases of the record loading will result in many original script (vernacular) records added to OCLC, as well as RLIN "order records".
RLG libraries can chose if they want their RLIN records sent to OCLC by RLG, or if they want to send a snapshot from their local catalog. It is the records for institutions that asked RLG to send their records that are being loaded to OCLC now. Records from institutions who are generating their own snapshots, including UCB, will happen later, on a timetable dependant on other timing concerns of the institution. In other words, there isn't a specific date by which everyone's records have to have been loaded (however, I would guess most institutions will be eager to have their records in OCLC before or around the time RLIN is turned off, probably this fall). For us there is less urgency, because we already crossload our RLIN records to OCLC. Probably our snapshot will be sent from Gladis to OCLC for the purpose of the RLG merger after our reclamation project is complete (the project to synchronize OCLC and Gladis).
One big change will be the implementation, with Connexion 2.0 (targeted for June/July '07) of "institutional records" in OCLC, somewhat similar to the old RLIN model. Current RLG members can chose to implement "institutional records" for their institution or not, and Berkeley and most other big libraries have chosen to go this route. Eventually non RLG libraries may be offered this choice.
The way institutional records will work is one institution's record will be chosen as the "master record", and all holdings will be attached to that record. The master record may have institutional records attached to it - any record sent to OCLC from a library that has chosen to implement institutional records will have an institutional record created for them associated with the master record their item matched on. When new institutional records are added from other libraries, the master record may be enhanced in certain ways (505s, 856s, etc. will be added by OCLC's load routines). So the master record to some degree will represent a "best of". Note: no holdings are attached to the institutional records, only to the master record. Also note that UCB's institutional records will not be created until we send RLG our snapshot from Gladis.
The institutional records may vary from the master record in various ways including treatment of standard cataloging elements, but also certain local fields, including local holdings if Marc21 holdings are used, will be retained in the institutional record that are not retained in the master record. IMPORTANT: the OCLC numbers in the institutional records will be completely unrelated to the OCLC# in the master record. However, at ALA OCLC was encouraged to define a field to contain the master record's OCLC # in each institutional record for match purposes. This will be very important to a number of projects at UCB.
All fields in institutional records will be indexed just as if they were in master records. Someone asked me specifically about the 797 on RLIN and if it will be supported in OCLC and the answer was yes, and it will be indexed in the institutional record.
This means that starting with Connexion 2.0 any OCLC member library (no matter if they were RLG members or not, and no matter if they chose to implement institutional records for their institution or not) will have access to not only the master records (as it is now) but also the variant institutional records for copy cataloging purposes for any institution whose records have been loaded. Keep in mind UCB's institutional records won't show up until we send them a snapshot from Gladis. RLG catalogers are already familiar with this type of situation, but it is totally new for OCLC.
OCLC verified that the ability to copy catalog off the institutional record can be restricted by logon, so it would be possible to limit entry level catalogers to just using the master records, to simplify training. However, experienced catalogers may find the variation in the institutional records (depending on the cataloging standards of the institution) valuable especially in certain specialty subject areas. OCLC confirmed we can have as many logons as we need to give the types of access different catalogers require.
Another important change for us will be that we will start resending records to OCLC when the bib information on Gladis changes. We are currently operating under the previous OCLC rules that only allow a given bib record to be sent to OCLC once (because the master record doesn't get replaced/updated, and the records we send that match something in OCLC only set our holdings). This will change, and the result will be that our institutional records on OCLC reflect the current state of the record in Gladis/Melvyl. This may become more important if Worldcat increases as a discovery tool for our materials. Our Gladis # will be retained in the institutional record and it will be the matchpoint for overlay of updates sent from Gladis.
Please send me questions and I'll do the best I can to find out the answers from OCLC and RLG.
4. Systems Gladis Update / C. Takaro
Gladis notes for BTECH 2/7/2007 for the period 11/1/06-1/31/07
1- Google mass digitization:
[repeat of last time's blurb, since questions have been coming up:]
a. Record upgrade for n level records (UCB affiliate records and non-UCB records): We sent CDL 533,000 n level records, and they returned 426,888 records that meet enough match criteria to load as is; 48,194 that could be loaded with human intervention using a reviewq process (though no workflow has been identified to actually process these at this time), and 58,666 that did not match anything in Melvyl. Matching Melvyl records was challenging because of the brevity of the bibliographic information in the n-level records. These records are now being interfaced to prepare them for loading and loading may be in progress by meeting time and will continue for much of November.
What does this mean to the public? N-level records get exported to Pathfinder (only), so this means that anyone searching Gladis or Pathfinder will now be much more likely to run across one of these n-level records in their search results. Since the short n-level records had so little bibliographic information, probably the public ran into them quite rarely before. There may be confusion as to why they are retrieving a record for something UCB doesn't own.
What does this mean to technical services staff? These records will have full (or fuller than before) cataloging, but will still be n-level. They will still be protected from merging with UCB Gladis records and from being edited by anyone except NRLF just as n level records are now. The record level will still be "n". Some n-level records won't get upgraded right away (or at all) because a match wasn't found or the match was not sufficient to load safely. New deposits are still receiving the traditional "cute" little n-level records, not full cataloging.
UPDATE: total loaded to date is: 374,993. Many of the remaining records to be loaded had "near title matches" instead of "good title matches" and some decisions need to be made about how these records should load depending on what matchpoints matched.
b. Change to not generate the “INVENTORY CONTROL RECORD” note for n level records going to Pathfinder that have been upgraded for the Google project. Eventually a similar change is planned for Gladis.
c. Minor change in how the mass charge program handles charges for items with missing barcode index records.
d. Much work being done to develop a mass discharge program that will discharge shipments from Google based on the barcodes in their return shipment manifest file.
2- OCLC number changes:
OCLC number changes went into place Nov. 8th 2006 to allow for the new, longer OCLC numbers that begin OCN, and to move the duplicate OCLC# that OCLC is now sending us in the 035 to the 039. Details follow:
OCLC used to send us their number as an 001, and we'd move it to an 035 when we loaded it. [The 001 in Gladis is the Gladis number]. Other numbers also appear in Gladis in the 035: RLIN numbers, SFX numbers, special numbers for specific projects like the Early American Imprints set (AAS numbers).
OCLC, for reasons of their own, decided to start sending us the OCLC number twice, once in an 001 like always, and once in a slightly different form in the 035. For various reasons, the thing that made the most sense was to move the 001 to an 035 and index it like we always have, and move their new 035 to an 039, which is not indexed, just to get it "out of the way". It is moved back to an 035 at export (except to Pathfinder, which is kept closer to Gladis to reduce staff confusion) - this is fine, since this field is repeatable (even though it's rather strange to have the same identical OCLC # twice, they can complain to OCLC about that if they want to...).
The new $z in the 035 on OCLC is not indexed on Gladis - for one thing, it's in the 039, which isn't indexed. This is a new place for the information that has been in the 019 on OCLC.
3- Spacing underscore character in URLS coming to Gladis soon!
In May 2006 OCLC implemented a number of new characters which have not been implemented in GLADIS. Records containing these characters are rejected and logged for having invalid characters:
http://www.oclc.org/support/documentation/worldcat/tb/252/
See the section titled “5 Character Set Changes”
One of these is a "spacing underscore" used in URLS. Until May, catalogers had to key this character as %5F for it to be correctly interpreted in OCLC and other systems. Starting in late May, on OCLC catalogers could continue to key it as %5F or could chose to use the character itself (by selecting it from some set of special keys inside Connexion?). However, for the record to be able to load to GLADIS, catalogers need to key it as %5F.
This is about to change - we're just about to implement the new character for GLADIS, because of it's importance for the SCP serials load (see below). I'll send email to btech when this change is in place. For now the rest of the characters referred to in the technical bulletin above still must not be used.
4- SCP serials may begin loading this month
If all goes well the SCP serials retrospective load may start soon. More information will be sent out after the retrospective load is complete. The retrospective load will ensure that Gladis is completely up to date with SCP serials (this is largely the case already due to extensive manual work on Technical Services part since the project began) so that fairly soon the weekly update files for SCP serials can be loaded automatically with a minimum of manual review.
5- 653s allowed from OCLC for specific Music cataloging projects
Change for Music project to catalog two large collections: Taddei libretto collection. and Sicilian libretto collection. Prior to this all 653s have been stripped from incoming records from OCLC (not from RLIN). Now Gladis allows 653s to enter on records that contain a 730 with one of these texts followed by $5CU. Changes made and in place for loads beginning on 01/12/07.
6- OCA scanning project pick lists:
Lists of items to pull for the OCA scanning project from NRLF were generated and from the Bancroft stacks are in progress.
7- EAL deaccession project pick lists:
Two new lists of items to deaccession from NRLF were generated for the EAL deaccession project.
8 - ARL statistics from GLADIS-
Statistics from GLADIS for open serials subscriptions, both print and electronic, were generated with new programming.
9- Marcnow loads started from Harrassowitz for German materials
German materials from Harrassowitz being cataloged by Marcnow are now having records loaded to Gladis as shipments arrive.
4. Technical Processing questions / Open Discussion
It seems like some branches have been having problems with the placement of barcodes in books. When books have text, tables or images on the inside back cover, care is not being taken to not cover text etc. The end result, branches have to remove the barcodes with Undu and place a new barcode in an appropriate place. Copies of some examples will be sent to Kay Keeton. It looks like it may be a PromptCat problem.
Also, there are some problems with the placement of call number labels on books. These will be forwarded to Tonnette.
Go to BTECH homepage