The Horizon Z39.50 server does support boolean operations on fields like author and title, but not on the numeric identifiers like IS*N or bib number. I think it's because they are indexed differently in the underlying search engine.
So in the below, the top three are fine, but as you've discovered the last one barfs. I don't think there's a way around it, unless you want to loop over the IS*Ns instead of ORing them. Ick. Best, -Tod open libcat.uchicago.edu format OPAC find @and @attr 1=4 "uses of infidelity" @attr 1=1003 "Martin Marty" show find @or @attr 1=4 "broke" @attr 1=1003 "Martin Marty" show find @attr 1=7 081080803X show find @or @attr 1=7 081080803X @attr 1=7 9780061733215 show close exit On Sep 20, 2013, at 1:31 PM, Ross Singer <rossfsin...@gmail.com> wrote: > Ah, interesting trick! Unfortunately, it doesn't work either (although it > doesn't explode, it just returns zero hits). > > I suspect you're right about the server not being configured to support > booleans, which would be a shame. > > -Ross. > > On Sep 20, 2013, at 2:22 PM, "LeVan,Ralph" <le...@oclc.org> wrote: > >> I can't say anything about the horizon server. But I have a suggestion. >> >> It's possible that server is configured to not support Booleans (either on >> that index or at all) and is blowing the trivial error response. If this is >> the case, there may be a workaround. Instead of explicitly ORing them >> together, maybe you can implicitly OR them together. >> >> The new query would look like this: f @attr 1=7 @attr 4=6 "9780413690609 >> 0413690601" >> >> What you are telling the server is that you want to search index 7 (use=7) >> and the structure of the term is a list of words (structure=6). First you >> have to hope this works and second you have to hope that OR is the implicit >> operator used in the list. But, it's worth a try. (In SRU we can >> explicitly say that this is a list of words to be ORed together.) >> >> Ralph (who doesn't quite regret all the z39.50 baloney stuck in his head) >> >> >> -----Original Message----- >> From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Ross >> Singer >> Sent: Friday, September 20, 2013 2:10 PM >> To: CODE4LIB@LISTSERV.ND.EDU >> Subject: "or" queries against Horizon Z39.50 servers? >> >> Hi everyone, >> >> I was wondering if anybody knew if there was some secret attribute >> combination to successfully do a "or"-ed ISBN or ISSN query against a >> SirsiDynix Z39.50 server. I've tried it against quite a few different >> implementations, but they all fail. >> >> From yaz-client, it goes something like this: >> >> Z> f @or @attr 1=7 9780413690609 @attr 1=7 0413690601 >> Sent searchRequest. >> Received SearchResponse. >> Search was a bloomin' failure. >> Number of hits: 0, setno 1 >> Result Set Status: none >> records returned: 1 >> Diagnostic message(s) from database: >> [100] Unspecified error -- v3 addinfo 'Unable to navigate!' >> Elapsed: 0.421485 >> >> All of the ones I've tried fail with that same error. >> >> If I search on the ISBNs individually, e.g.: >> >> Z> f @attr 1=7 9780413690609 >> Sent searchRequest. >> Received SearchResponse. >> Search was a success. >> Number of hits: 1, setno 2 >> records returned: 0 >> Elapsed: 0.606146 >> >> it works fine. >> >> If you are able to successfully do or'ed ISBN or ISSN queries can you pass >> along all of the use attributes that are being sent? >> >> Thanks, >> -Ross.
