[OPEN-ILS-GENERAL] dewey call number normalization

[Ben Shum]

This will be a slightly more technical answer that may require some direct
database access to ascertain more details.

You mention that the call numbers are identified as DDC.  So that's
label_class of 2, I believe.  We are using Dewey (DDC) for all of our
materials by default as well in our consortium.

I'd be curious to know what the label_sortkey values were for those call
numbers you mention.  That field is what actually drives the sorting values
for a given set.

For example, just pulling a few samples from our asset.call_number table:

label -> label_sortkey

720 Mag -> 720_000000000000000_MAG
720.9 How -> 720_900000000000000_HOW
720.92 Ros -> 720_920000000000000_ROS
720.973 THO -> 720_973000000000000_THO

So, the normalizer for Dewey class ought to pad in the extra zeroes with
the first . decimal point to set the initial sorting.  In that case, I
would expect 720 by itself to be 720_000... and 720.1 to be 720_100.... in
the sorting, which would result in the expected order.

But perhaps something is not quite right with your call number's
label_sortkey values, or it's behaving in yet another unexpected way.  I do
not know how your system is setup, but it's possible for the label_sortkey
values to be incorrect due to bugs or earlier implementations of Dewey
normalizers in previous run versions of Evergreen.  This has happened to us
before, where the class was set appropriately, but we had to run all the
call numbers back through to update the label_sortkey appropriately.

Hope this gets you somewhere to start looking, please feel free to follow
up with further questions.

-- Ben



On Thu, Apr 24, 2014 at 3:32 PM, Adam Shire <adam at flo.org> wrote:

> Hi Everyone,
>
> We are testing in evergreen 2.5.2
>
> I'm noticing what I think looks like incorrect behavior when using the
> call number browse feature.
>
> Doing a call number browse search for 720 results in the following call
> number sort order:
>
> 720 H47 1979
> 720 .H47
> 720.1 H74 1979
> 720.1 .H47 1980
> 720.1 .H74 1979
> 720 H74 1979
> 720 .H74 1979
>
>
> It looks like the decimal point might be throwing things off. I think that
> should be taken care of in a normalizer, but maybe there is a reason not
> to. I think the 720.1's should come at the end of this list, regardless of
> the decimal point before the cutter.
>
> All of the call numbers are identified as DDC.
>
> you can probably replicate this here
> http://emerson.eg.flo.org/eg/opac/cnbrowse?cn=715&locg=2
>
>
> I didn't see any bug reports that seemed to address this specific issue,
> so I'm wondering if there could be something else causing this behavior.
>
> thanks,
> Adam
>
> --
>
> Adam Shire
> Member Services Librarian
> Fenway Libraries Online <http://flo.org>
> 617-442-2384
>



-- 
Benjamin Shum
Evergreen Systems Manager
Bibliomation, Inc.
24 Wooster Ave.
Waterbury, CT 06708
203-577-4070, ext. 113
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20140424/c9b33681/attachment.htm>