[Koha] data import question
Derek Dresser
Derek.Dresser at gouldacademy.org
Wed Jul 23 07:06:06 NZST 2003
Quoting Derek Dresser <Derek.Dresser at gouldacademy.org>:
> Quoting Larry Stamm <larry at larrystamm.com>:
>
> > Derek Dresser <Derek.Dresser at gouldacademy.org> writes:
> >
> >
> > > Is there an already defined option to extract the "item" data from
> > > the MARC 852 field (I believe from some responses that I have
> > > received that this is a fairly standard location for the "item"
> > > data). Any help or additional information would be appreciated.
> > > Perhaps there is a way for me to rewrite my MARC data so that that
> > > information will be read properly?
> >
> > Hi Derek,
> >
> > No, you have to define the mappings from the marc fields to the items
> > table yourself. This is done in from the Koha intranet interface, going
> > to the Parameters link, and then to the "Links Koha-MARC DB" link, and
> > then to the items tab from the drop-down menu. Then you start mapping
> > the koha items table column names to MARC subfields.
> >
> > Note that _all_ of these mappings have to be in the subfields of the
> > same MARC field, so that if you are using the 852 field (as our library
> > is) then all the needed items table columns will need to be mapped to
> > 852 subfields.
> >
> > 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.
> > In addition, you have to go to the "MARC tag structure" link under
> > Parameters and change the tab value of all the subfields used in the
> > items table to "items(10)", except for the tab value of items.itemnumber
> > which should be set to "-1(ignore)" since this value will be
> > autoincremented by the bulkmarcimport script and should not read any
> > values that might inadvertently be in your MARC records that you are
> > trying to import.
> >
> > Then go back to the main Parameters page, and click the "MARC Check"
> > link. This will check all your MARC-Koha mappings to see if they are
> > valid. If there are errors, it will point them out and you need to fix
> > them before trying to use the bulkmarcimport script. Once you get an
> > error free message from "MARC-Check", then you should be good to use
> > bulkmarcimport. Remember to use the "-d" option to delete the previous
> > entries.
> >
> > Once you get the biblio data into the items tables, the circulation data
> > from your old system can be extracted and added to the table if you
> > want. You will probably have to write your own script to automate this,
> > since each library system seems to store its circulation data in a
> > lightly different fashion.
> >
> > I find the bulkmarcimport script to be interminably slow, entering only
> > about 6000 items per hour on our 950 MHz CPU server running Mandrake
> > 9.0. It is not much slower on my 266 MHZ home machine that I am using
> > as a test machine. Because I have to enter all 15,000 items from our
> > collection to really test for errors in my MARC "munging", it means
> > another 2 1/2 hr wait to load up all the items again after fixing a
> > mistake before testing. I might get frustrated enough to try my hand at
> > writing a faster upload script...
> >
>
> Larry,
> this is ENORMOUSLY helpful. Thank you. I am getting closer. I still
have
> one error when I run MARC Check.
>
>
> ALL items fields MUST :
>
> be mapped to the same tag,
> and they must all be in the 10 (items) tab
>
> here is my mapping.
>
> items.itemnumber -> 852f (arbitrary)
> items.barcode -> 852p
> items.homebranch -> 852a (arbitrary)
> items.itemnotes -> 852z (arbitrary)
> items.holdingbranch -> 852b (arbitrary)
>
> I did set all the items fields to "item(10)" except for items.itemnumber
> which is set to -1 "ignore"
>
> The only actual fields that seem to be used in my data are
> 852h - call number
> 852p - bar code
>
> anything obvious that I'm missing? Also, where is the call number
supposed
> to end up? by call number, I think I mean dewey number and local call
> number. It looks like this in my data
> _h016.9733 C475m
>
> Thanks again. With your help, I'm getting closer.
Hi again,
Is it true that the 016.9733 part of the 852h field (example above) supposed
to end up in biblioitems.classification and the C475m part supposed to end
up in biblioitems.subclass?
When mapping the MARC subfield structure, is the "tab" parameter used to
extract multiple values from the same subfield? For example from above
would the 016.9733 be subfield 852h tab0? and C475m be subfield 852h tab1?
or am I misinterpreting the "tab" parameter?
I imported a small subset of my data using the mapping above (even though
MARC Check still reports the one error shown above) I now get data in my
items table in the database. The problem I am having now is that the
biblioitems.classification field is NULL for all my records even though it
is mapped to 852h.
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.
Thanks in advance for any help. Getting closer all the time :-)
-Derek
>
> -Derek
>
> > --
> > Larry Stamm, Chair
> > McBride and District Public Library
> > McBride, BC V0J 2E0
> > Canada
> > http://www.mcbridebc.org/library
> >
> > .
> >
> > _______________________________________________
> > Koha mailing list
> > Koha at lists.katipo.co.nz
> > http://lists.katipo.co.nz/mailman/listinfo/koha
> >
> >
>
>
> --
> Derek Dresser
> http://network.gouldacademy.org/
> Gould Academy
> Bethel, ME 04217
> (207)824-7700
>
> "Nothing endures but change"
> --Heraclitus
>
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>
>
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
>
--
Derek Dresser
http://network.gouldacademy.org/
Gould Academy
Bethel, ME 04217
(207)824-7700
"Nothing endures but change"
--Heraclitus
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
More information about the Koha
mailing list