[Koha] Authority record updates fail- no matches found.

[Raymund Delahunty]

University of the Arts London moved to Koha in September last year, moving away from Voyager. We subscribe to the Marcive authority update service and we receive monthly updates to existing authority records and (in theory) also new authority records derived from newly added bibliographic records added to our database and sent to Marcive for inclusion in our data file. (Not that we have submitted records yet, due in part to ongoing frustrations with authority control in Koha.).

Much to my disappointment we have just suspended the monthly update service as we have been quite unable to update existing authority records as the matchpoint index simply doesn't work. If I try to update, I receive zero matches and every incoming record would be added. Has anyone, anywhere been able to update existing authority records based on the LC-Cardnumber index (010$a)? My (simplistic) take on the problem is that the normalisation rules (maybe Voyager-speak) are simply not correct and the index LC-cardnumber being built is useless.

PTFS Europe who provide support to us have been assisting and they went out to this list on 22 December last year. There were lots of responses but most were too technical for me. To me the problem seems to be with the way the index is built and the matching with the data incoming is performed. The 010$a RCN structure is complex but strictly defined- some records have a space in them (Structure B), some have two (Structure A). If the LC-cardnumber index is not being built correctly to match the data standard then isn't this a bug?

Included in the earlier email exchange on this list was this one (I believe it was from Joy Nelson at ByWater Solutions): "I suspect that you are correct that there is some stripping of spaces, but not to the extent you are looking for.  i.e. Koha is removing 1 space, but not multiple spaces    If this is the case, someone with some more expertise would need to weigh in on the behind the scenes code. [...]".

If this is a bug surely lots of other Koha users will be similarly afflicted? This problem is becoming mission critical for us now as we are struggling with (ridiculous amounts of) manual authority control, and we need to resolve this ASAP. Until we resolve this we cannot make informed choices as to what settings to use in ongoing authority work (particularly the choice of settings for BiblioAddsAuthorities).

There was the suggestion (again from Joy Nelson, I recall): "If you have some perl proficiency you can use perl scripts to pull out, modify the 010$a (stripping out spaces) from your authority records in Koha if that would help make them match the incoming records.  But from a true cataloger's perspective you want the 010$a in your system to be the 'right value' spaces or no spaces, so using a script to modify your 010$a's may or may not be desirable."

Now I won't confirm or deny that I am a true cataloger, but I am not prepared to permanently damage the sanctity of the MARC data. I do have a (ridiculously complicated MarcEdit-based) way of copying the existing 010$a (and other data) away, dealing with the spaces in the residual 010$a and doing the 7 months of overdue updates, before undoing my temporary damage to the MARC data, but the idea of doing this monthly (ripping apart the entire data in the authority file, importing the Marcive data and then undoing the damage) strikes even me as a bit extreme.

So, again. Has anyone, anywhere been able to update existing authority records based on the LC-Cardnumber index (010$a)?. We don't have server access, so if there is a workaround that would be for PTFS to implement. But if the LC-cardnumber index is broken surely there will be lots of Koha sites in a similar mess to the one we are in. Any suggestions or pointers would be most appreciated


Ray Delahunty
Systems Support Librarian
University of the Arts London
https://libsearch.arts.ac.uk





This email and any attachments are intended solely for the addressee and may contain confidential information. If you are not the intended recipient of this email and/or its attachments you must not take any action based upon them and you must not copy or show them to anyone. Please send the email back to us and immediately and permanently delete it and its attachments. Where this email is unrelated to the business of University of the Arts London or of any of its group companies the opinions expressed in it are the opinions of the sender and do not necessarily constitute those of University of the Arts London (or the relevant group company). Where the sender's signature indicates that the email is sent on behalf of London Artscom Limited the following also applies: London Artscom Limited is a company registered in England and Wales under company number 02361261. Registered Office: University of the Arts London, 272 High Holborn, London WC1V 7EY