[Koha-devel] Default Koha to MARC Mappings on nonexistent table fields?

Thomas Dukleth kohadevel at agogme.com
Tue Nov 3 18:55:44 CET 2009


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






More information about the Koha-devel mailing list