[Koha] A quick question on biblioitems.dewey field's datatype

[Baljkas Family]

Monday, August 23, 2004   16:22 CDT

Hi, Bob, Indranil et alii,

Just adding another 2 cents here, just FYI on the cataloguing matter touched on ...
 
> From: Bob Seidl <singularity at wi.rr.com>
> Date: 2004/08/23 Mon AM 07:51:13 CDT
> To: Koha Users List <koha at lists.katipo.co.nz>
> Subject: Re: [Koha] A quick question on biblioitems.dewey field's datatype
> 
> Indranil Das Gupta wrote:
> 
> >On Sun, 2004-08-22 at 22:49, MJ Ray wrote:
> >  
> >
> >>On 2004-08-22 12:06:33 +0100 Indranil Das Gupta <indradg at icbic.com> 
> >>wrote:
> >>
> >>>Why is the biblioitems.dewey field set to double(8,6) and not to, say
> >>>varchar(15) or something like that?
> >>>
> >>I think quite a few developers have been wondering that recently, too. 
> >>Unless there's a killer reason to keep it numeric, I expect it to 
> >>change in 2.1.* before much longer.
> >>    
> >Thanks for the info. At my deployment site, use of double precision
> >datatype was leading to the decimal part of the stored dewey number
> >being padded with extra zeros. And this was reflecting a wrong value in
> >the OPAC interface.
> >
> >So, I simply changed the fieldtype to varchar(15) and rerun
> >misc/rebuildnonmarc.pl. Now, the dewey value is being correctly stored
> >in biblioitems.dewey and properly displayed in the OPAC.
> >
> >So far, I haven't noticed any inconsistency due to the change.
> >
> >cheers,
> >-indra.
> >
>     Not knowing the language very well, and not knowing the dewey 
> decimal system very well, I can nonetheless venture a guess based upon 
> my experience in other computer areas.
>     If the number of characters after the decimal point ever changes, 
> then it will not sort properly.

That is definitely the case, Bob.

The Dewey Decimal Classification system uses each position 100s, 10s, 1s, tenths, hundredths, thousandths and so on to be more specific about a book's content. There are other bits that are added on to even these, so that if a library wants to do so, the numbers can get VERY long and VERY specific.

You may notice on the back of the title page (t.p.) that when Dewey numbers are given there are little prime marks (') after one or more groups. This is to help cataloguers out by suggesting specific places to stop number building.

E.g. (an ex. appropriate to the Koha community):
Random acts of kindness / the editors of Conari Press ; foreword by Daphne Rose Kingma ; introduction by Dawna Markova. --
  CIP gives 177'.7

If the library's collection were small (overall or in that area) or for other reasons where a long number is not desirable, the number could be stopped at 177 (and augmented with cutter number, etc. as per local practice); or, if the collection were larger (overall or in that area) or for other reasons, the number could be the complete 177.7 (again augmented as noted).

The difference here would be between classing a book on the Ethics of social relations (177) vs. the more specific Ethics of social relations - Love (including benevolence, charity, kindness, liberality, philanthropy) (177.7), not something a patron might even notice.

With some topics, though, the 'base' number goes to 3 decimal places (a random example: School journalism = 371.897). And when you add in numbers for geography and classes of persons, and so on, you can get quite specific and consequently quite long numbers.

> If the field is changed to varchar, I would make sure to
> put in some sort of edit mask / edit check to verfy
> the number of characters after the decimal point. If there
> are less than some minimal number, space fill to the 
> right.
 
I am sorry for being dull here, Bob, but I don't understand what this would do.

Does what you're proposing mean that instead of the zeros that were a problem for Indranil, there would be blank space filed instead? Wouldn't that distort numbers, too?

Steven F. Baljkas
library tech at large
Koha neophyte
Winnipeg, MB, Canada