[Koha-devel] The future of Koha (some ideas and thoughts)

[Stephen Hedges]

Thomas D said:
> What holdings data does NPL map to the biblioitems table?
>
>
> Thomas D

942 $c (item type) and 942 $k (dewey) -- here's the complete biblioitems
mapping:

biblioitemnumber --> 090 $d  (Koha biblioitemnumber)
biblionumber
volume --> 440 $v  (Volume number/sequential designation)
number --> 440 $n  (Number of part/section of a work)
classification --> 942 $k  (dewey)
itemtype --> 942 $c  (item type)
isbn --> 020 $a  (International Standard Book Number)
issn --> 022 $a  (International Standard Serial Number)
dewey
subclass
publicationyear
publishercode --> 260 $b  (Name of publisher, distributor, etc)
volumedate
volumeddesc
timestamp
illus --> 300 $b  (Other physical details)
pages --> 300 $a  (Extent)
notes
size --> 300 $c  (Dimensions)
place --> 260 $a  (Place of publication, distribution, etc)
url --> 856 $u  (Uniform Resource Identifier)
lccn --> 010 $a  (LC control number)
marc

>
> Quoting Stephen Hedges <shedges at skemotah.com> :
>> ---------------- Beginning of the original message ------------------
>>
>> Thomas D said:
>> > What alterations were done for the customised version of
>> bulkmarcimport.pl
>> > at NPL?
>>
>> Some code was added to the beginning to re-write the MARC
>> records (using
>> MARC::Record) to split holdings information into two MARC tags
>> instead of
>> the normal single tag, so that some of the holdings data could
>> be mapped
>> to biblioitems and the rest to items.
>>
>> Stephen
>>
>> >
>> >
>> > Thomas D
>> >
>> > Quoting Stephen Hedges <shedges at skemotah.com> :
>> >> ---------------- Beginning of the original message
>> ------------------
>> >>
>> >> I'd like to reinforce Thomas' point about "disintegrating
>> >> integrated
>> >> library systems" (and also correct a small error).
>> >>
>> >> NPL now uses BookWhere instead of ITS MARC for cataloging
>> >> materials --
>> >> which actually reinforces Thomas' point, because NPL was
>> able
>> >> to switch
>> >> from one cataloging application to another without making
>> >> changes to Koha.
>> >>  This was possible because both cataloging applications
>> >> generate MARC
>> >> records in a standard format (iso2709), and Koha can import
>> >> those
>> >> standardized records.  However, Koha is only able to do the
>> >> import after
>> >> the records have been altered by a customized version of
>> >> bulkmarcimport.pl.
>> >>
>> >> I believe I remember that Paul has already discussed the
>> >> notion of
>> >> rewriting the Koha cataloging code so that it generates
>> files
>> >> of records
>> >> for import in batches, instead of adding each record as it
>> is
>> >> created
>> >> (which is very slow).  I think it would be wise to aim for
>> >> doing this
>> >> rewrite in such a way that it also makes it easy for a
>> library
>> >> to use
>> >> their own cataloging utility.  In other words, I suggest
>> that
>> >> we start the
>> >> disintegration process with the cataloging module, making
>> it a
>> >> "stand-alone" application that _can_ be used with Koha, but
>> >> may also be
>> >> replaced with another cataloging application of the
>> library's
>> >> choosing.
>> >>
>> >> Stephen
>
> [snip]
>
>>
>>
>> --
>> Stephen Hedges
>> Skemotah Solutions, USA
>> www.skemotah.com  --  shedges at skemotah.com
>>
>>
>> ------------------- End of the original message ---------------------
>
>
>
>
> ---------------------------------------------
> Protect your mails from viruses thanks to Alinto Premium services
> http://www.alinto.com
>


-- 
Stephen Hedges
Skemotah Solutions, USA
www.skemotah.com  --  shedges at skemotah.com