 |
 |
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 <[log in to unmask]> 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" <[log in to unmask]> 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:[log in to unmask]] On Behalf Of Ross Singer >> Sent: Friday, September 20, 2013 2:10 PM >> To: [log in to unmask] >> 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.