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.su...@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@lists.koha.org > http://lists.koha.org/mailman/listinfo/koha-devel > _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
