Thanks, Tod. Looks like i'm going to have to loop over the ISxNs. Ick, indeed.
-Ross. On Sep 20, 2013, at 2:53 PM, Tod Olson <[email protected]> wrote: > 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 <[email protected]> > 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" <[email protected]> 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:[email protected]] On Behalf Of >>> Ross Singer >>> Sent: Friday, September 20, 2013 2:10 PM >>> To: [email protected] >>> 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.
