[Koha-devel] Need to Modify Marc Import Tool

[Ryan Higgins]

I also am against the idea of overloading the frameworks
mechanism for record import.  IMO the frameworks already
try to do too much.

My preferred solution would be to alter the import code so that
it can accept MARCXML records.  An XSLT stylesheet can then
be specified either in the staging tool or as a command-line
argument to bulkmarcimport.  The obvious drawback is that
XSL is very difficult for the uninitiated, but once a given XSLT
sheet has been created, it can be used by anyone.  XSL has
the added benefit of being able to handle some mapping, e.g.
merging or altering collection codes, or stripping that pesky T-prefix
from Follett barcodes.

[my 1.9999999¢]

Regards,

-- 
Ryan Higgins

LibLime  *  Open-Source Solutions for Libraries
Featuring KohaZOOM ILS
888-564-2457  x704


On Sun, Mar 15, 2009 at 7:30 PM, Mason James
<mason.loves.sushi at gmail.com> wrote:
>>>
>>> Folks,
>>>
>>> One of our customers wants the ability to import Follett marc records
>>> without having to use Marc Edit (to change fields 852 to 952).
>>>
>>> We want to make this change generic such that it will work for any
>>> import file that has holdings in fields other than 952.
>>>
>>> This is what we were thinking, will appreciate feedback on this
>>> design:
>>>
>>> 1. Use marc_subfield_structure table to store field structure of the
>>> import file. So Follett would have records under its framework code.
>>> We could create frameworks for other vendors too.
>>> 2. Accept framework code as user input from stage-marc-import.pl.
>>> User
>>> could choose nothing which means input file already has holdings in
>>> 952. Or could choose Follett or some other vendor.
>>> 3. Pass framework code as parameter to BatchStageMarcRecords
>>> (C4/ImportBatch.pm) and from there to AddItemsToImportBiblio
>>> (C4/ImportBatch.pm).
>>> 4. In AddItemsToImportBiblio
>>> - Use the input framework code in GetMarcFromKohaField (C4/Biblio.pm)
>>> to fetch Follett holdings fields and subfields
>>> - Fetch default fields and subfields (952) using null framework
>>> code, as
>>> is currently done.
>>> - For each subfield set values appropriately (in the case of Follett
>>> 952s = 852s) before saving item record.
>>> 5. Initially the code will help with holdings tags, and later we
>>> could
>>> extend this to biblio tags as well.
>>>
>>> Thanks,
>>> Savitra Sirohi
>>> Nucsoft OSS Labs
>>> http://www.osslabs.biz
>
>
> heya Savitra
>
> I think this is a *very* useful idea
>
> some suggestions:
>
> write a feature to do a remap of the vendor's itemlevel info to
> koha's 952, during the MARC import
> rather than rewriting koha3 to internally accept non 952 item-info
> from MARC records
>
> i suspect that an attempt to have koha3 use non-952 item-info may be
> tricky, as this change would affect many areas of koha3 code
> and would need much testing to ensure it is safe.
>
> a safer/easier way to your goal would be to have a feature where the
> source item-info gets remapped to koha's 952
>
>
> i think we could use another table to store this remapping info.
> perhaps a 'import_vendor_items_map' table...?
>
> a example record would look something like this..
>
> vendor_code             = 'FOLL'
> vendor_field            = '852'
> vendor_subfield         = 'a'
> vendor_subfield_desc    = 'HOME BRANCH'
> koha_field              = '952'
> koha_subfield           = 'a'
> ... etc
>
>
> what do others think about this idea?
>
> this looks to be a nice simple way to build a collection of other ILS
> vendor's item-level structures.
> and allow those vendor's MARC-records to be correctly remapped into
> koha's 952 structure during a bulkimport - from the GUI, without a
> custom script.
>
> Mason.
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-devel
>