Evergreen

Bug #1150939
Comment #12

Comment 12 for bug 1150939

Revision history for this message

Jeremiah Miller (jeremym-t) wrote on 2013-03-08:

#12

>Why are we expecting the Dewey call number normalization algorithm to normalize call numbers that are not Dewey call numbers?

The preponderance of real world "Dewey call numbers" that are not strictly proper Dewey call numbers. Many coming from other ILS that do not have an equivalent to the prefix/suffix features. They will be encountered, handling them gracefully seems preferable to not doing so. Which it does already, with the exception of three digit numbers without decimals.

>Why don't we just make use of the Prefix functionality that has been there for a number of releases?

Agreed that would be the ideal. Agreed that would pretty much solve the issue. But moving toward making use of it is non-trivial for us, and likely others.

>You haven't provided any context for where this sorting is occurring (or not occurring, as the case may be).

My particular use case was straight database queries, selecting and sorting call number ranges using both callnum_label and callnum_label_sortkey. (Easily worked around at that level. And if we were using prefixes, would just add them to the SQL stew.) We've also experienced odd results when sorting report output by callnumber_label_sortkeys. (Another case where use of separate prefixes would solve the problem.)

But as far as I can tell, it is ubiquitous... anywhere and everywhere one can find (or create) a list of items and sort them by call numbers, dewey numbers with non-separate prefixes can sort incorrectly (depending on what mix of call numbers is in the list). Item status list view, pull holds list, copy buckets, OPAC call number search (shelf browse), report output, etc.

>If you want sorting by prefix + callnumber in some specific contexts, then we should fix that problem or problems

Agreed. While I can't think of a context where one wouldn't want that, I don't know of any where one can't.
I do know of a couple places the prefix isn't displayed... item status alternate view, copy editor.

>otherwise we have useless functionality in the form of the "Prefix" and "Suffix" and should remove it.

Disagree, I think the functionality appears quite useful and sensible, and even preferred. But taking advantage of it requires planning and work that can take time to execute properly. In the meantime, see no reason the Dewey normalizer should/could not be robust and capable of handling "bad Dewey" callnum input just as well as proper callnums. No reason it shouldn't return properly sortable results regardless of prefix use.

>Why are we expecting the Dewey call number normalization algorithm to normalize call numbers that are not Dewey call numbers?

The preponderance of real world "Dewey call numbers" that are not strictly proper Dewey call numbers.  Many coming from other ILS that do not have an equivalent to the prefix/suffix features.  They will be encountered, handling them gracefully seems preferable to not doing so.  Which it does already, with the exception of three digit numbers without decimals.

>Why don't we just make use of the Prefix functionality that has been there for a number of releases?

Agreed that would be the ideal.  Agreed that would pretty much solve the issue.  But moving toward making use of it is non-trivial for us, and likely others.

>You haven't provided any context for where this sorting is occurring (or not occurring, as the case may be).

My particular use case was straight database queries, selecting and sorting call number ranges using both callnum_label and callnum_label_sortkey.  (Easily worked around at that level.  And if we were using prefixes, would just add them to the SQL stew.)  We've also experienced odd results when sorting report output by callnumber_label_sortkeys.  (Another case where use of separate prefixes would solve the problem.)

But as far as I can tell, it is ubiquitous... anywhere and everywhere one can find (or create) a list of items and sort them by call numbers, dewey numbers with non-separate prefixes can sort incorrectly (depending on what mix of call numbers is in the list).  Item status list view, pull holds list, copy buckets, OPAC call number search (shelf browse), report output, etc.

>If you want sorting by prefix + callnumber in some specific contexts, then we should fix that problem or problems

>otherwise we have useless functionality in the form of the "Prefix" and "Suffix" and should remove it.

Disagree, I think the functionality appears quite useful and sensible, and even preferred.  But taking advantage of it requires planning and work that can take time to execute properly.  In the meantime, see no reason the Dewey normalizer should/could not be robust and capable of handling "bad Dewey" callnum input just as well as proper callnums.  No reason it shouldn't return properly sortable results regardless of prefix use.