Default Koha to MARC Mappings on nonexistent table fields?
Hey All, We have set up a plain Koha 3 install which we are using for import testing. I wrote a script to rebuild the biblio, biblioitems, and items tables from biblioitems.marcxml using the data stored in marc_subfield_structure. What I have found is that some of the framework code seems to reference table columns that do not exists. The columns referenced are: * bibliosubject.subject ( there is no bibliosubject table ) * biblioitems.cn_edition * biblioitems.cn_prefix Can anyone provide any insight to this situation? Are these dead columns, or columns that were never added, or just bugs? Thanks, Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
Kyle Hall a écrit :
Hey All, We have set up a plain Koha 3 install which we are using for import testing. I wrote a script to rebuild the biblio, biblioitems, and items tables from biblioitems.marcxml using the data stored in marc_subfield_structure. What I have found is that some of the framework code seems to reference table columns that do not exists. The columns referenced are:
* bibliosubject.subject ( there is no bibliosubject table )
this one is oldies but not goodies. Has been removed a long time ago (was in 1.x and maybe not even in 2.2) dunno for the 2 others -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Reply inline: On Mon, November 2, 2009 13:30, Kyle Hall wrote:
Hey All, We have set up a plain Koha 3 install which we are using for import testing. I wrote a script to rebuild the biblio, biblioitems, and items tables from biblioitems.marcxml using the data stored in marc_subfield_structure. What I have found is that some of the framework code seems to reference table columns that do not exists. The columns referenced are:
* bibliosubject.subject ( there is no bibliosubject table ) * biblioitems.cn_edition * biblioitems.cn_prefix
Can anyone provide any insight to this situation? Are these dead columns, or columns that were never added, or just bugs?
1. OBSOLETE COLMN REFERENCE. bibliosubject.subject is a legacy of subject searching of pre-Zebra Koha in Koha 2.2 and is not currently used in non-Zebra Koha. I had not followed changes in the implementation of non-Zebra Koha. References to bibliosubject.subject should be removed from the Koha MARC frameworks. 2. POTENTIALLY USEFUL BUT UNUSED COLUMN REFERENCES. biblioitems.cn_edition and biblioitems.cn_prefix represent columns which had been an important part of an attempt to enable the opportunity to create code for managing call numbers within Koha in a more standards compliant manner. The columns and associated value list CN_EDITION should have been part of Koha 3.0. I specified them in the Koha MARC bibliographic frameworks which I edited in consultation with Joshua Ferraro. He had intended to add the related columns and value lists to the database. Joshua had intended to have some better call number management for Koha 3.0 but no substantial change happened. Apparently those particular columns were not added, although, other related call number columns were added. Call number management should be at the item level. Most columns for the call number modelled on standards compliance for holdings were moved out of the items table to accommodate an early 3.0 development goal of storing all the items columns within the numbers and English letters for subfields within the single Koha MARC holdings field for indexing in Zebra. Either the missing columns should be added to the database or other related biblioitems columns should be removed along with references to them in the Koha MARC frameworks. We should not have a confusing half measure on the issue. The related set of columns should have uses for appropriately making the parts of the call number available to features corresponding to the relevant function of the particular part of the call number but that has not happened. Currently, it may be better to remove all the related call number parts columns from the biblioitems table for which there is no support in the code than to keep them in the wrong column for what should be item level use. Reference to such columns from the Koha MARC bibliographic frameworks should also be removed. 3. FUTURE DEVELOPMENT. We should fix the problem of items needing to rely upon a single Koha MARC holdings field to enable a better opportunity to manage call numbers well in Koha along with many other benefits. Strong limitations on holdings management especially in relation to serials is one of the worst problems of Koha. LEK has addressed the issue but that code is not being shared. Tümer Garip had fixed the issue for the Near East University library in Cyprus three years ago for which the code is available. We should be very careful to avoid merely creating another weak foundation in attempting to address the problem without considering the options well. Considering options and careful planning takes time. Development for the Koha 3.4 release should make some progress towards easing the reliance upon our present weak foundation. Until we resolve items management better for Koha, we should probably not be attempting to store very transient items column values in the Koha MARC holdings field. Reducing the burden of real time reliance upon the Koha MARC holdings field would allow an easier transition to developing a more flexible, robust, and standards compliant model for holdings in Koha. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
participants (3)
-
Kyle Hall -
Paul Poulain -
Thomas Dukleth