Query by ISBN to Library of Congress' Z39.50
Hi, looks like copy cataloguing using ISBN fails when searching lx2.loc.gov:210/LCDB using Z39.50. Debugging Koha, I saw that it builds and sends a query like @attr 1=7 @attr 5=1 "9782406112143" that returns Number of hits: 0 while @attr 1=7 "9782406112143" returns Number of hits: 1 Try it in your terminal: $ yaz-client lx2.loc.gov:210/LCDB Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Metaproxy/YAZ Version: 1.19.1/5.30.3 2af59bc45cf4508d5c84f350ee99804c4354b3b3 Options: search present scan namedResultSets Elapsed: 0.188871 Z> f @attr 1=7 @attr 5=1 "9782406112143" Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 0, setno 1 records returned: 0 Elapsed: 0.152497 Z> f @attr 1=7 "9782406112143" Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 1, setno 2 records returned: 0 Elapsed: 0.157806 Z> q I verified this error up to Koha 25.5. Server hvd.alma.exlibrisgroup.com:1921/01HVD_INST (auth required) and few others work correctly with or without @attr 5=1. This Z39.50 attribute is added by C4::Breeding::_bib_build_query. I'm not sure if we can avoid to add @attr 5=1 for any Z39.50 server. Your opinion? Thx. Bye. Stefano PS: A workaround is to use lx2.loc.gov:210/LCDB as SRU.
5=1 means right truncation. It seems they removed support for it? El jue, 4 dic 2025 a las 8:44, Stefano Bargioni via Koha-devel (< koha-devel@lists.koha-community.org>) escribió:
Hi, looks like copy cataloguing using ISBN fails when searching lx2.loc.gov:210/LCDB using Z39.50. Debugging Koha, I saw that it builds and sends a query like @attr 1=7 @attr 5=1 "9782406112143" that returns Number of hits: 0 while @attr 1=7 "9782406112143" returns Number of hits: 1
Try it in your terminal:
$ yaz-client lx2.loc.gov:210/LCDB Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Metaproxy/YAZ Version: 1.19.1/5.30.3 2af59bc45cf4508d5c84f350ee99804c4354b3b3 Options: search present scan namedResultSets Elapsed: 0.188871 Z> f @attr 1=7 @attr 5=1 "9782406112143" Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 0, setno 1 records returned: 0 Elapsed: 0.152497 Z> f @attr 1=7 "9782406112143" Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 1, setno 2 records returned: 0 Elapsed: 0.157806 Z> q
I verified this error up to Koha 25.5. Server hvd.alma.exlibrisgroup.com:1921/01HVD_INST (auth required) and few others work correctly with or without @attr 5=1. This Z39.50 attribute is added by C4::Breeding::_bib_build_query. I'm not sure if we can avoid to add @attr 5=1 for any Z39.50 server. Your opinion?
Thx. Bye. Stefano
PS: A workaround is to use lx2.loc.gov:210/LCDB as SRU. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
-- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F
I think so. sb
On 9 Dec 2025, at 20:13, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
5=1 means right truncation. It seems they removed support for it?
El jue, 4 dic 2025 a las 8:44, Stefano Bargioni via Koha-devel (<koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org>>) escribió: Hi, looks like copy cataloguing using ISBN fails when searching lx2.loc.gov:210/LCDB <http://lx2.loc.gov:210/LCDB> using Z39.50. Debugging Koha, I saw that it builds and sends a query like @attr 1=7 @attr 5=1 "9782406112143" that returns Number of hits: 0 while @attr 1=7 "9782406112143" returns Number of hits: 1
Try it in your terminal:
$ yaz-client lx2.loc.gov:210/LCDB <http://lx2.loc.gov:210/LCDB> Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Metaproxy/YAZ Version: 1.19.1/5.30.3 2af59bc45cf4508d5c84f350ee99804c4354b3b3 Options: search present scan namedResultSets Elapsed: 0.188871 Z> f @attr 1=7 @attr 5=1 "9782406112143" Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 0, setno 1 records returned: 0 Elapsed: 0.152497 Z> f @attr 1=7 "9782406112143" Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 1, setno 2 records returned: 0 Elapsed: 0.157806 Z> q
I verified this error up to Koha 25.5. Server hvd.alma.exlibrisgroup.com:1921/01HVD_INST <http://hvd.alma.exlibrisgroup.com:1921/01HVD_INST> (auth required) and few others work correctly with or without @attr 5=1. This Z39.50 attribute is added by C4::Breeding::_bib_build_query. I'm not sure if we can avoid to add @attr 5=1 for any Z39.50 server. Your opinion?
Thx. Bye. Stefano
PS: A workaround is to use lx2.loc.gov:210/LCDB <http://lx2.loc.gov:210/LCDB> as SRU. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel <https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel> website : https://www.koha-community.org/ <https://www.koha-community.org/> git : https://git.koha-community.org/ <https://git.koha-community.org/> bugs : https://bugs.koha-community.org/ <https://bugs.koha-community.org/>
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <https://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F
participants (3)
-
bargioni＠pusc.it -
Stefano Bargioni
-
Tomas Cohen Arazi