[Koha] Zebra not updating biblios automatically in koha 3.8

Doug Kingston dpk at randomnotes.org
Tue Sep 4 04:41:56 NZST 2012


I would concur that 001 and 003 need to be taken together to have any
chance of a unique identifier.  Our library has our own unique 003
(UkLoVW).  For indexing, I suspect a better key to hand to zebra would be
the system control number (035 $a).  Are these kept unique by koha?

While I do believe this is a problem, I am not sure how this would the
cause of our ModAuthority failures however, unless I am missing something.
See the other mail thread for details (3.8.4 Error message when editing
authorities).  Its possible these issues are related but I am not sure.

-Doug-

On 3 September 2012 09:10, Paul <paul.a at aandc.org> wrote:

> At 11:32 PM 9/1/2012 +0100, Ian Bays wrote:
>
>> Hi.
>> The 3.8 upgrade offers the dom indexing by default and if you have taken
>> that option (as seen in $KOHA_CONF) the xsl used instead of record.abs
>> (~/koha-dev/etc/zebradb/marc_**defs/marc21/biblios/biblio-**zebra-indexdefs.xsl)
>> uses a construct (z:id) for the 001 which uses that (if it exists) as the
>> zebra unique id.  This means if you have more than one bib record with the
>> same 001 (as you get if you duplicate a bib for instance) it will only
>> index the last one and it won't complain at all about it.
>>
>
> If this is the case, then there is a problem (bug?) as the 001 is not a
> unique field by definition (this from our cataloguers who tell me it's only
> unique when taken in conjunction with the 003; they referred me to <
> http://www.loc.gov/marc/**authority/ad001.html<http://www.loc.gov/marc/authority/ad001.html>>
> which seems to confirm, but I would appreciate other views on this.)
>
> We certainly have many duplicates -- part of this is intentional (e.g.
> facsimile reprints and different titles for intrinsically identical books
> in UK and US editions[1]); part is "accidental" occurring after importing
> Z39.50 records from different libraries.
>
>  [snip] The better solution is to fix the xsl to probably not use the z:id
>> for biblios or maybe get it to use the 999$c, but the zebra config scares
>> me.
>>
>
> If my understanding is correct, the 999$c (biblio.biblionumber) is
> designed to be unique and I had _assumed_ that this was expressly for db
> indexing regardless of whether it's MySQL or Zebra.
>
> Our sandbox is tied up at the moment, but tomorrow I should be able to get
> some time to do a detailed comparison of 3.6 with 3.8.  However if I'm not
> correct in my assumption, maybe someone would be kind enough to avoid my
> going on a wild goose chase.
>
> Thanks - Paul
> [1] -- I understand that this may not be everyone's choice and that other
> options may be available, but also that it is perfectly acceptable as long
> as we "sign" the 003 as CaOPIACS; other major libraries, so I'm told, do
> the same.
>
>
> ______________________________**_________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/**mailman/listinfo/koha<http://lists.katipo.co.nz/mailman/listinfo/koha>
>


More information about the Koha mailing list