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
for some reason people did not receive this. ---------- Forwarded message ---------- From: savitra sirohi <savitra.sirohi@osslabs.biz> Date: Thu, Mar 12, 2009 at 9:36 AM Subject: Need to Modify Marc Import Tool To: koha-devel <koha-devel@lists.koha.org> 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
Might be radical, but I told my vendors how I wanted my MARC 952 to look and they are complying no cost to me since I'm paying for the records... ;) Follett is in compliance David savitra wrote:
for some reason people did not receive this.
---------- Forwarded message ---------- From: savitra sirohi <savitra.sirohi@osslabs.biz> Date: Thu, Mar 12, 2009 at 9:36 AM Subject: Need to Modify Marc Import Tool To: koha-devel <koha-devel@lists.koha.org>
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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
-- View this message in context: http://www.nabble.com/Need-to-Modify-Marc-Import-Tool-tp22469564p22489774.ht... Sent from the Koha - Dev mailing list archive at Nabble.com.
That's great for new records. Not so good if one is trying to migrate records. On Thu, 2009-03-12 at 20:54 -0700, David Schuster wrote:
Might be radical, but I told my vendors how I wanted my MARC 952 to look and they are complying no cost to me since I'm paying for the records... ;)
Follett is in compliance
David
savitra wrote:
for some reason people did not receive this.
---------- Forwarded message ---------- From: savitra sirohi <savitra.sirohi@osslabs.biz> Date: Thu, Mar 12, 2009 at 9:36 AM Subject: Need to Modify Marc Import Tool To: koha-devel <koha-devel@lists.koha.org>
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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
-- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA for Koha checkout http://koha-dev.washk12.org or git://koha-dev.washk12.org/koha
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.
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@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
Yes, I like this idea. I think we will start work on MarcXML and XSLT. The customer may not want to wait so we will give them something simpler for now. Thanks everybody for your input! Savitra Sirohi MD, Nucsoft OSS Labs http://www.osslabs.biz On Mon, Mar 16, 2009 at 10:14 AM, Ryan Higgins <ryan.higgins@liblime.com>wrote:
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@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
Hi to all, On Thu, 12 Mar 2009 09:36:27 +0530, savitra sirohi
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:
[...]
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.
my vote is for this solution. I think we need a standard for all about this topic and 952 is OK. And I don't like modification in the API for this type of work (conversion and migration). My experience is that every migration is unique and same specific software work is a must for a quite good migration. So best solution 2, with good documentation to implement a a new code o to modify a present one. In the future a specific API for convertion ? Bye Zeno Tajoli
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.
There are utilities in Kyle Hall's koha-tools collection that pretty much do this--they act as an intermediary between the bulkmarcimport script and the librarian, who can choose a vendor framework. It's for the dev_week version of Koha, but we're in the process of migrating to 3.0, so I imagine Kyle will be writing a 3.0 version at some point soon. I don't know if he plans to integrate it into Koha or keep it separate, but perhaps it would be useful as a basis for what you want it to do. Maybe Kyle can elaborate? Cheers, c. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cindy Murdock IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org
OK sorry bout that... I'm using MarcEdit to verify the vendor information they sent so good luck in making the changes. they could use MARCEDIT utility to Join records into one file and do the F11 renaming tags and subfields. Sorry. David Schuster savitra 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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
-- View this message in context: http://www.nabble.com/Need-to-Modify-Marc-Import-Tool-tp22469564p22530880.ht... Sent from the Koha - Dev mailing list archive at Nabble.com.
participants (7)
-
Cindy Murdock -
David Schuster -
Mason James -
Michael Hafen -
Ryan Higgins -
savitra sirohi -
tajoli