Authority record updates fail- no matches found.
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
Hi, Raymund-- I overlay (and thus update) authority records based on the 010 $a all the time without any problems--the match & authority record overlay works perfectly. When the appropriate script(s) run on Friday night, all my linked fields in bibs are updated, which also works perfectly. Some of our authority records are in our system from our initial data load (from an Athena catalog, loaded to our new Koha catalog by ByWater Solutions), and I currently export authority records from OCLC using Connexion Client into a file and then import them into Koha using the stage records for import tool, since there's not yet a gateway export for authorities. It works perfectly no matter the original source of the authority record. Here's what an 010 field of ours looks like when I save an authority record from Koha as MARCXML, so you can see an example: <datafield tag="010" ind1=" " ind2=" "><subfield code="a">n 98048791 </subfield></datafield> I'm very far from an expert--I am a cataloger!:)--but it doesn't sound like a bug to me. It sounds to me like something is going on with your 010 fields from Voyager and that they may need to be standardized. (We are using the fully open source version of Koha 3.22, hosted and supported by ByWater Solutions.) I hope this is helpful! Best, heather ~~~~~~~~~~~~~~ Heather Hernandez Technical Services Librarian San Francisco Maritime National Historical Park Research Center 2 Marina Blvd., Bldg. E, 3rd floor, San Francisco, CA 94123 415-561-7032, heather_hernandez@nps.gov http://www.nps.gov/safr/learn/historyculture/museum-collections.htm "The sailor does not pray for wind, he learns to sail."--Gustaf Lindborg
participants (2)
-
Hernandez, Heather -
Raymund Delahunty