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 <pau...@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@lists.katipo.co.nz > http://lists.katipo.co.nz/**mailman/listinfo/koha<http://lists.katipo.co.nz/mailman/listinfo/koha> > _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha