[Koha] data import question

[Larry Stamm]

baljkas  <baljkas at mb.sympatico.ca> writes:


    > 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>

Thanks for the clarification and link!  MARC structure is a bit hard to
get a grasp of for those of us not trained as librarians.


    > From the prescribed definition and usage examples given, you will
    > note that


    >    852 $8 is designated for Link and Sequence Number 852 $9 is not
    > defined [numbers tend to be avoided though] 852 $a is prescribed:
    > it must be a valid Organization Code 852 $b is prescribed: as
    > Sublocation or Collection 852 $f is prescribed: Coded Location
    > Qualifier, to distinguish subparts or specific issues of an items
    > that are located apart from the main holdings of the same item

    > Mapping for 852a, 852b, and 852f should not be treated
    > arbitrarily.

My understanding is that the 852 field is all for "local" data, and is
mainly for use within an organization. Is that true?  It seems that our
library staff has manually added all the 852 data since we automated,
and this is where the majority of irregularities occurs in our MARC
records.

The reason I chose the arbitrary mappings I did was because our current
MARC records have no data in those subfields, so there would be no
conflict in importation into Koha.  Your suggestions for location fields
make more sense and are helpful.

    > For the rest, I'd suggest an alternate mapping:

    >    items.price --> 852 $x Non-public note [LC ex. gives accession
    > no.]  items.itemnumber --> 852 $w [unused; unlikely to be used in
    > future] items.dateaccessioned --> 852 $d [unused; unlikely to be
    > used in future: if possible, you could use a second 852x, since LC
    > allows this as a repeatable subfield]

The manual for our current software (Sagebrush's Athena) suggests this
mapping:

    852 6 --> Format (eg, book, paperback)
    852 7 --> Aquisition fund
    852 8 --> Aquisition date
    852 9 --> Aquisition price

And consequently this is where this data lies in our MARC records.
Given the discrepancy between this usage and that laid out in the Lbrary
of Congress website, I'm wondering just how standardized actual MARC
implementaions are across all libraries?


    > You might be able to use a tool like MARCEdit (available off the
    > LC MARC tools page) to do simple global edits. You would need to
    > copy data from fields you know it is currently stored in, transfer
    > it to a temporary dummy field (a 9xx) where you can set up the
    > data as you need. Once you have all the data in standardised
    > places, you could use a global change delete to remove the 852's
    > that are there and then reconstruct them as you need them from the
    > correct locations in the dummy fields you set up.  Just a thought
    > anyway.

I went ahead and made some small changes, like changing "fic", "Fic",
"FiC", all to "FIC" and limiting further entries into the Athena
database to "FIC" for fictional books.  That amounted to a criminal
offence (almost), according to the staff. :) From a management point of
view, I think it will be easier to just get the data correctly imported
into Koha's database tables and do the correction and standardization in
that database.  Then limiting manual biblio entries to only authorized
standard values and/or formats can be hidden within the general chaos of
implementing new software.

-- 
Larry Stamm, Chair
McBride and District Public Library
McBride, BC  V0J 2E0
Canada
http://www.mcbridebc.org/library