[Koha] data import question

[baljkas at mb.sympatico.ca]

Tuesday, July 22, 2003	  18:20 CDT

Hi, Derek,

You were dead-on right in your interpreting 
>I believe (correct me if I'm wrong) that I want the 016.9733 to end up
>in biblioitems.classification and the C475m to end up in
>biblioitems.subclass.

Whether the gods of LC should ever have caused so much trouble in splitting
up the constituent parts of a call number, the numbers map as you suggested
from 852h (the classification number, i.e. the sequence of alphanumerics
for all items on a given subject/topic) and 852i, the completion of the
call number (the item number, i.e. the sequence of alphanumerics yielding a
unique address/identifier for that particular object).

Some libraries seem to ignore the formal definition of the 852h and enter
the WHOLE call number in that field (classification part and item specific
designator); this certainly makes things easier, although it is not
strictly speaking correct. You could make a similar pitch to use the 852c
that way, although again, not strictly speaking correct. 

Just a quick addendum re: Larry Stamm's response -- at least, I think it
was Larry's part infra, but I wasn't quite clear who was writing, so my
apologies to Larry if this is a misattribution -- viz. what is arbitrary in
the '852'.

Of course, all of the structure of tags and subfields is arbitrary (in the
sense of having no real reason for having been designated as they are), but
the mapping of the 852 is a little more defined now. Remember to check LC's
MARC documentation to see what fields and subfields within fields are
defined and how they are used. The concise MARC info online is kept
up-to-date and it does contain examples to help clarify proper usage. For
852 surf to

   URL <http://www.loc.gov/marc/bibliographic/ecbdhold.html#mrcb852>

>> > The mapping that I am trying at the moment is:
>> > 
>> > items.itemnumber -> 852 f (arbitrary mapping - no data in this
>> > subfield in the original MARC record of our old system )
>> > 
>> > items.multivolumepart -> 852 m
>> > items.barcode	   -> 852 p
>> > items.dateaccessioned -> 852 8
>> > items.homebranch	   -> 852 a (arbitrary mapping)
>> > items.price	   -> 852 9
>> > items.itemnotes	   -> 852 z
>> > items.holdingbranch   -> 852 b (arbitrary mapping)
>> > 
>> > Your mappings might have to be slightly different depending on
>> > where your current MARC records are storing data.	Since many of
>> > our library's records were entered by hand, I am having to "fix and >>
> reconstitute" the MARC database to standardize the entries.  This
>> > is not proving to be an easy job to catch every error.
>> > 
>> > The rest of the columns in the items tables are left unmapped for
>> > now.