Background from Cornell:

 

QUESTION FROM YALE: Am I correct in assuming that in Voyager I can/will use the 852 |k in the much (or exactly) the same way that I am currently using |k in the NOTIS copy holdings record?

ANSWER FROM CORNELL: Pretty much, though you may want to use $m as well -- which is also standard MARC but NOTIS never implemented.

QUESTION FROM YALE: Is there a character limit to the 852 |k?

ANSWER FROM CORNELL: Yes, though I'm not sure we ever figured out exactly what it was. As I recall what happens when you exceed it is that it cuts off the display on the OPAC.

QUESTION FROM YALE: Can 852 |k be indexed in the Voyager system?

ANSWER FROM CORNELL: Nope.

QUESTION FROM YALE: It seems that you use the 852 |k primarily to indicate that an item is oversized -- with "+" or with "oversize." Is that correct? Do you use it for anything else?

ANSWER FROM CORNELL: All kinds of shelving anomalies -- take a look at our migration tables for Engineering and Rare & Manuscripts for instance. Also make sure you look at the special programming requests as well.

QUESTION FROM YALE: Is it safe to say that you use the 852 |k *only* for information that can not be recorded as location information or as call number information?

ANSWER FROM CORNELL: Nope. We used it for stuff we *didn't want* to record as location information, but that *wasn't* call number information. When you see how the acquisitions system behaves when you want to order something for one location and shelve it in another (remember: no such thing as "sublocation" really) you'll see how important this concept is.

MORE FROM CORNELL: The locations stuff is really important in Voyager, much more so than in NOTIS. We took the time early in the game to re-think the whole business, not wanting to migrate all the locations we then had. Susan Currie (who headed up the circulation portion of our migration effort) and I [Diane Hillmann] went to every location and literally browbeat them all into doing things our way (Susan's very nice so we did a kind of good cop/bad cop routine ...). Our goal was to pare down the locations to only those needed for circulation and acquisitions, and to use the $k and $m (you have both available) to deal with shelving anomalies within units. You can see the results of our work on the web:

http://www.library.cornell.edu/voyager/MigrLocs/index.html

Basically we set up certain locations for everyone, then figured out which extra ones were needed to deal with REAL problems, and set up the absolute minimum. When you see how the circ module and acquisitions works, you'll see that this is really important to do. You can see from our website that there are a number of migration documents still up:

http://www.library.cornell.edu/voyager/#migration

We did a LOT of cleanup of bibs and holdings prior to the migration--Jim [LeBlanc] is really the expert on that, and probably still has a lot of the documentation on what we did. We cleaned up a lot of problems, even up til the very last minute. I think it was worth it, but it sure did stress us out!

MORE FROM CORNELL: In short, managing locations in Voyager is a nuisance. When it comes time to configure the Systems Administration module for cataloging, circulation, acquisitions, etc., you'll curse every location that you feel you could have done without. A good rule of thumb would be: if a "location" is actually a separate physical entity (e.g. a separate building) or will have

its own circulation policy (e.g. a reference collection, reserve), it makes sense to treat it as a location. If, on the other hand, a "location" represents a shelving area which is neither a separate physical location or an area with its own CIRC policy (e.g. Oversize, Rockefeller Memorial Room), then it would be better to treat it as $k info.

Return to Orbis2 Implementation Site