[OPEN-ILS-GENERAL] Improving LC Call Number Displays & Behaviors

Thu Dec 11 13:11:30 EST 2014

Hi Don,

Some answers inline below.

> Hi Kathy
>
>
>         Issue #2 Multiple Suffixes in Volume and Copy Creator
>
> Are you talking about the suffix field here or the parts field? I was 
> thinking the parts field would be the most appropriate place to store 
> the volume/part information. Is there a reason you can't have a part 
> listed as "volume 1, part 1" or as "volume 1, part 2"?
>
> My understanding of how suffixes and part designation works is that 
> you can create a suffix "v." and then enter a value in part 
> designation "1"
> Providing a call number like
> BR
> 60
> .C49
> v.1
>
> I don't see how you can create a call number
> BR
> 60
> .C49
> v.1
> pt.5
> with the current structure. Am I missing something?
Our sites put the entire string in the parts field, and I believe most 
other Evergreen sites do the same thing. However, I'm guessing that the 
parts information prints all on one line instead of printing in the way 
you identified above.

The feature request, then, may be to support a way to break up that 
information in spine label printing rather than adding an enhancement to 
the suffix field.

The original intent of the suffix field was not to work together with 
the parts field. It's not to say it can't be used to serve purposes 
outside of the original intent, but it's something that some of our 
libraries use to add some extra information to the call number field 
that may not be appropriate for the prefix field.

>
> Personally I only see the need for the Shelf browse. The other seems 
> superfluous, but perhaps I am missing something. I can't recall any 
> other ILS that has two different call number indexes. I would 
> recommend eliminating this option, especially since it returns null 
> results. 

I concur with eliminating this option and have added a working branch to 
do so on the bug at https://bugs.launchpad.net/evergreen/+bug/1074096. 
Most of the people I spoke to do not use this option, but this opinion 
has mainly been expressed through IRC discussions rather than list 
discussions. Is there anyone who objects to removing this option from 
the numeric search?

Kathy

>
>         Issue #5 No entries found when doing "Bib Call Number" searches
>
> We've had discussions about the bib call number search at various 
> times in IRC,  the most recent one being last week when you sent this 
> e-mail. The relevant bug report is at 
> https://bugs.launchpad.net/evergreen/+bug/1074096. The thought was 
> that this search probably works with call numbers stored in the 099 
> field, but I haven't had a chance to confirm this behavior. If you 
> wanted it to work with another call number field, then I think you 
> would need to adjust the bibcn entry in the config.metabib_field table 
> in the database to point to another field. You would then need to 
> reingest your records to get the call number search working with the 
> new tag(s)
>
> I'm not sure what all is going on with Bib Call Number Search. I was 
> simply reporting the behavior. However it makes no sense to me why a 
> default setting for this feature would only index locally assigned 
> call numbers instead all LC or Dewey number. My supposition was that 
> Bib Call Number Search should index call numbers from the bib record 
> while the Call Number (Shelf browse) indexes the copy/item record.
>
> Personally I only see the need for the Shelf browse. The other seems 
> superfluous, but perhaps I am missing something. I can't recall any 
> other ILS that has two different call number indexes. I would 
> recommend eliminating this option, especially since it returns null 
> results.
>
> As an aside, it would make sense to me to include the Call Number 
> (Shelf Browse) option in the Browse the Catalog "Browse for:" dropdown 
> list.
>
> Blessings,
>
> Don
>
>
> On Thu, Dec 11, 2014 at 9:09 AM, Kathy Lussier <klussier at masslnc.org 
> <mailto:klussier at masslnc.org>> wrote:
>
>     Thank you for pulling this list together Don! I have a couple of
>     questions/comments.
>
>>
>>             Issue #2 Multiple Suffixes in Volume and Copy Creator
>>
>>     The suffix structure is not sufficiently complex to handle LC
>>     call numbers that include multiple suffixes such as volume 1,
>>     part 1, volume 1, part 2, etc. Currently, the only way to account
>>     for these exceptions is to simply include it as part of the text
>>     in the Call Number text box.
>>
>     Are you talking about the suffix field here or the parts field? I
>     was thinking the parts field would be the most appropriate place
>     to store the volume/part information. Is there a reason you can't
>     have a part listed as "volume 1, part 1" or as "volume 1, part 2"?
>
>>
>>             Issue #5 No entries found when doing "Bib Call Number"
>>             searches
>>
>     We've had discussions about the bib call number search at various
>     times in IRC,  the most recent one being last week when you sent
>     this e-mail. The relevant bug report is at
>     https://bugs.launchpad.net/evergreen/+bug/1074096. The thought was
>     that this search probably works with call numbers stored in the
>     099 field, but I haven't had a chance to confirm this behavior. If
>     you wanted it to work with another call number field, then I think
>     you would need to adjust the bibcn entry in the
>     config.metabib_field table in the database to point to another
>     field. You would then need to reingest your records to get the
>     call number search working with the new tag(s)
>
>     However, what I have heard is that many sites (including ours) do
>     not use the bib call number search nor do they really see a need
>     for the bib call number search. For consortia, this makes sense
>     since the individual libraries within the consortium use different
>     call numbers and wouldn't all necessarily be using the same call
>     number that is on the bib record. However, we even had a single,
>     academic institution mention in IRC that they have disabled the
>     bib call number search. There has also been discussion of removing
>     that search from the default install of Evergreen. It would still
>     be there for people who had a need for it, but they would need to
>     customize the numeric search of their catalog to add it.
>
>     My question for you and anyone else who uses the bib call number
>     search is if there is a need for that search that can't be
>     fulfilled by an asset.call_number search, which is the call number
>     that you add when you are adding volumes/copies to the record. Is
>     it primarily because you dislike the display of the results when
>     doing a Call Number (Shelf Browse) search? If so, I would
>     wholeheartedly support an alternate project that brings about an
>     alternate, text-based display for that search. It's something
>     MassLNC once put out as a possible development project (see
>     http://masslnc.cwmars.org/search/node/call%20number), but
>     ultimately decided not to fund the project.
>
>     Kathy
>
>     Kathy Lussier
>     Project Coordinator
>     Massachusetts Library Network Cooperative
>     (508) 343-0128  <tel:%28508%29%20343-0128>
>     klussier at masslnc.org  <mailto:klussier at masslnc.org>
>     Twitter:http://www.twitter.com/kmlussier
>     #evergreen IRC: kmlussier
>
>     On 12/4/2014 9:01 AM, Donald Butterworth wrote:
>>     Colleagues,
>>
>>     Another priority that emerged from the Evergreen for Academics
>>     survey is Library of Congress Call Numbers displays and
>>     behaviors. My assignment is to identify issues. To that end an
>>     Evergreen DokuWiki was created entitled Improve LC Call Number
>>     Displays & Behaviors
>>     <http://wiki.evergreen-ils.org/doku.php?id=evergreen_for_academics:improved_lc_call_number> 
>>     I have identified 10 issues so far. Please note that the
>>     examples, problems and wishlist items listed originate from
>>     behaviors in my local 2.6.1 catalog
>>     <http://evergreen.asburyseminary.edu/eg/opac/browse>. Also please
>>     understand that we have used Evergreen for less than six months.
>>     So there may be some issues listed that are the result of
>>     incorrect settings, or some issues may already have been
>>     addressed in more recent releases.
>>
>>     The Evergreen for Academics group greatly appreciates your
>>     feedback. If you have an opinion or comment on any item please
>>     share it. If there are issues or outstanding bug reports that you
>>     would like to see listed, please email me directly and I will add
>>     them to the Wiki.
>>
>>     Don
>>
>>     -- 
>>     Don Butterworth
>>     Faculty Associate / Librarian III
>>     B.L. Fisher Library
>>     Asbury Theological Seminary
>>     don.butterworth at asburyseminary.edu
>>     <mailto:don.butterworth at asburyseminary.edu>
>>     (859) 858-2227 <tel:%28859%29%20858-2227>
>
>
>
>
> -- 
> Don Butterworth
> Faculty Associate / Librarian III
> B.L. Fisher Library
> Asbury Theological Seminary
> don.butterworth at asburyseminary.edu 
> <mailto:don.butterworth at asburyseminary.edu>
> (859) 858-2227

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20141211/7dd72803/attachment.htm>