[OPEN-ILS-GENERAL] ***SPAM*** Re: Call numbers in Evergreen

[Dan Scott]

On Wed, 2010-07-28 at 05:26 -0400, Don Butterworth wrote:
> 
> ----- Original Message -----
> From: "Dan Scott" <dan at coffeecode.net>
> To: "Evergreen Discussion Group"
> <open-ils-general at list.georgialibraries.org>
> Sent: Tuesday, July 27, 2010 9:36:40 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [OPEN-ILS-GENERAL] Call numbers in Evergreen
> 
> <snip>
> 
> Interesting. In the past we used prefixes on our call numbers to
> identify which library holds a given book, but we've done away with
> them
> to avoid messing up call number sorting in the loverly shelf browse.
> The
> idea of having non-sorting prefixes and suffixes is intriguing -
> although I wonder if it would make more sense to work out a
> programmatic
> way to tell the spine label editor to generate a given prefix or
> suffix
> when printing a spine label, rather than manually entering that
> information into new fields all the time.
> 
> ++++++++++++++++++++++++++++++++++++++++
> In our former system, call number prefixes were assigned based on a
> parameter set in a Collection Code definition area. In other words,
> the collection code ATSREF defined the call number prefix prefix Ref.,
> ACREF also defined the call number prefix Ref. This work great both
> for gathering statistics and applying the prefix. It was a set it then
> forget it operation. Our current system "tries" to do the same thing,
> but it does not work as seamlessly. 

This made me think that the right place to define call number prefixes
and suffixes might be at the copy location. 

1. We could add a "prefix" and "suffix" field to the asset.copy_location
table.

2. When printing spine labels, the spine label editor would check the
copy location for the item in hand. If there is a prefix or suffix value
for a given copy location, the prefix or suffix would be added
automatically to the spine label at printing time, just at printing time
(and just like the existing call number label, those pieces would then
be editable for that particular label if one really needed to override
them for a single item for some reason).
 
A quick consultation with our cataloguers suggests that this approach
would work for us. It would avoid having to key in explicit prefixes or
suffixes in most cases, and shelving location generally defines the kind
of prefix or suffix we want (e.g. some libraries want their short name
prefixed to the call number and a suffix of "Ref." if it's part of the
reference collection). It would also avoid polluting the shelf browse -
only the call number label proper would be used for that - so that one
would see all materials on a given subject collocated independent of
whether they were reference / reserves / circulating material.

> Please pardon my ignorance, but it sounds like Evergreen requires
> keying in every call number prefix. Is that true? Wouldn't that be an
> unnecessary extra burden for the data entry person? 

It is true. But in our case, the vast majority of our collection doesn't
use prefixes, so it's not much of a burden. The current defaults match
the majority of our use cases, and I hope we can make that the case for
the broader Evergreen community. Discussions like these are how we make
it happen.