[Yazlist] baffled by cql, or maybe rec.id

Larry E. Dixson ldix at loc.gov
Sun Mar 27 17:20:15 CEST 2011


Mike,
The searches in your session generated hit counts that seemed appropriate
because we configured our YAZ Proxy to map CQL "rec.id" searches to our
LC Control Number index (MARC21 010 field) not our Voyager ID
(MARC21 001 field).  The reasoning was that most external users are more
likely to come across our LCCNs (e.g., on versos of title pages, etc.).

However, we have since learned that there are some users that want
CQL access to our voyager IDs, so we changed that when we configured
the MetaProxy.

Note in the following session logs that "rec.id" searches against
"z3950.loc.gov:7090" match control numbers present in the 010 field
and "rec.id" searches against "lx2.loc.gov:210" match Voyager IDs
in the 001 field.
Larry


---------------------------------------
YAZ Proxy
---------------------------------------
$ yaz-client z3950.loc.gov:7090/voyager
Connecting...OK.
Sent initrequest.
Connection accepted by v3 target.
ID     : 34
Name   : Voyager LMS - Z39.50 Server (YAZ Proxy)
Version: 2007.2.0/1.2.1.1
Options: search present

Z> f rec.id=1001 or rec.id=1002 or rec.id=1003 or rec.id=1004 or
rec.id=1005
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 2

Z> s 1
Sent presentRequest (1+1).
Records: 1
[VOYAGER]Record type: USmarc
00519nas  22001453  4500
001 10748783
008 881206u        xx  u         0  0 0und
035    $9 (DLC)sv 88085531
906    $a 0 $b bbc $c serlocs $d u $e ncip $f 19 $g ilsserca
010    $a sv 88085531  $z ca05-1005
245 00 $a hOsterreichische chemiker-zeitung (Wien)(Vereines
hosterreichischer chemiker und der Chemisch-physikalische gesellschaft in
Wien)
310    $a Monthly
590    $a Holdings in 3x5 and visible files.
920    $a Keep 1
991    $b c-GenColl $c SER $h QD1.O3 $w SERLOC

Z> s 2
Sent presentRequest (2+1).
Records: 1
[VOYAGER]Record type: USmarc
00430nas  22001453  4500
001 10843618
008 891223u        xx  u         0  0 0und
035    $9 (DLC)sv 89099398
906    $a 0 $b bbc $c serlocs $d u $e ncip $f 19 $g ilsserca
010    $a sv 89099398  $z ca05-1002
245 00 $a Revue beconomique de Bordeaux .... $h [microfilm]
310    $a Unknown
590    $a See MICROFORM SERIAL RECORD.
920    $a Keep 1
991    $b c-MicRR $c MicRR $h 32114 $w SERLOC


---------------------------------------------
MetaProxy
---------------------------------------------
Z> $ yaz-client lx2.loc.gov:210/LCDB
Connecting...OK.
Sent initrequest.
Connection accepted by v3 target.
ID     : 81
Name   : Metaproxy/YAZ
Version: 1.2.0/4.0.11 e8ca42e680c5e5a644481e5d0b75a0e57c6d3e92
Options: search present scan namedResultSets

Z> querytype cql
Z> f rec.id=1001
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 1, setno 1

Z> s 1
Sent presentRequest (1+1).
Records: 1
[LCDB]Record type: USmarc
00920cam a22002297a 4500
001 1001
005 20020820153919.0
008 920720s1976    pk       d    000 0 per
035    $9 (DLC)   76930272
906    $a 7 $b cbc $c orignew $d 4 $e ncip $f 19 $g y-gencatlg
955    $a yh00 to arr. 07-20-92 $h yh20 2002-08-20 to AMED
010    $a    76930272
040    $a DLC $c DLC
050 00 $a MLCMN 2002/02899 (P)
100 0  $a   [ . . . ]


Z> f rec.id=1001 or rec.id=1002 or rec.id=1003 or rec.id=1004 or
rec.id=1005
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 0, setno 2
Diagnostic message(s) from database:
    [3] Unsupported search -- v2 addinfo 'Missconfigured search, malformed
at opac'

Elapsed: 1.142375
Z> f rec.id=1001 or rec.id=1002
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 10000, setno 3


On Sun, 27 Mar 2011, Mike Taylor wrote:

> On 26 March 2011 13:22, Larry E. Dixson <ldix at loc.gov> wrote:
> > Enrico and Mike,
> > Sorry that I didn't catch this sooner.  I didn't realize that you were
> > attempting to use Boolean operators with the @attr 1=12 search against
> > a Voyager database.  What you are seeing is a Voyager server
> > implementation "issue".  You cannot use Booleans with an @attr 1=12
> > search.  That index search has special "behavior' in Voyager.  Try
> > your search without the OR and see if that corrects the problem.
> >
> > Below is a session against our Voyager database -- to demonstrate
> > that the problem is present at LC as well.
> 
> But if that's the case, why did MY session against the LC server work correctly?
> 
> cartney:photos mike$ yaz-client z3950.loc.gov:7090/voyager
> Connecting...OK.
> Sent initrequest.
> Connection accepted by v3 target.
> ID     : 34
> Name   : Voyager LMS - Z39.50 Server (YAZ Proxy)
> Version: 2007.2.0/1.2.1.1
> Options: search present
> Elapsed: 0.423290
> Z> querytype cql
> Z> f rec.id=1001
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 0
> records returned: 0
> Elapsed: 0.165135
> Z> f rec.id=1001 or rec.id=1002
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 1
> records returned: 0
> Elapsed: 0.179830
> Z> f rec.id=1001 or rec.id=1002 or rec.id=1003
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 1
> records returned: 0
> Elapsed: 0.145695
> Z> f rec.id=1001 or rec.id=1002 or rec.id=1003 or rec.id=1004
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 1
> records returned: 0
> Elapsed: 0.156986
> Z> f rec.id=1001 or rec.id=1002 or rec.id=1003 or rec.id=1004 or rec.id=1005
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 2
> records returned: 0
> Elapsed: 0.197544
> Z>
> >
> > Sorry that it took so long for the "fog" to lift for me.
> > Larry
> >
> >
> > Z> f @or @attr 1=9 2008272044 @attr 1=9 99040535    [LCCN OK]
> > Sent searchRequest.
> > Received SearchResponse.
> > Search was a success.
> > Number of hits: 2
> >
> > Z> f @or @attr 1=12 1214711 @attr 1=12 249547    [001 ID search]
> > Sent searchRequest.
> > Received SearchResponse.
> > Search was a success.
> > Number of hits: 10000
> >
> > Z> f @and @attr 1=12 1214711 @attr 1=12 249547
> > Sent searchRequest.
> > Received SearchResponse.
> > Search was a success.
> > Number of hits: 10000
> >
> > Z> f @not @attr 1=12 1214711 @attr 1=12 249547
> > Sent searchRequest.
> > Received SearchResponse.
> > Search was a success.
> > Number of hits: 6488
> >
> >
> > Z> f @attr 1=12 1214711            [one at a time is OK]
> > Sent searchRequest.
> > Received SearchResponse.
> > Search was a success.
> > Number of hits: 1
> >
> > Z> f @attr 1=12 249547
> > Sent searchRequest.
> > Received SearchResponse.
> > Search was a success.
> > Number of hits: 1
> >
> >
> > On Sat, 26 Mar 2011, Mike Taylor wrote:
> >
> >> On 26 March 2011 05:15, Enrico Silterra <es287 at cornell.edu> wrote:
> >> > Mike, i'm the one who set up the yaz proxy that we are talking to --
> >> > here is the log from the yaz proxy, and this what it says.
> >> >
> >> > 01:10:25-26/03 [log] 1301116203:9952 2 CQL: rec.id=1001 or rec.id=1002
> >> > 01:10:25-26/03 [log] 1301116203:9952 2 Search RPN @attrset Bib-1 @or
> >> > @attr 1=12 @attr 5=100 @attr 6=1 @attr 3=3 @attr 4=1 @attr 2=3 1001
> >> > @attr 1=12 @attr 5=100 @attr 6=1 @attr 3=3 @attr 4=1 @attr 2=3 1002
> >> > 01:10:25-26/03 [log] 1301116203:9952 2 Sending searchRequest to
> >> > database.library.cornell.edu:7090 223 bytes
> >> > 01:10:32-26/03 [log] 1301116203:9952 2 Receiving searchResponse from
> >> > database.library.cornell.edu:7090 18 bytes
> >> > 01:10:32-26/03 [log] 1301116203:9952 2 10000 hits
> >> > 01:10:32-26/03 [log] 1301116203:9952 2 Sending searchResponse to client
> >> > 01:10:32-26/03 [log] 1301116203:9952 2 Elapsed 7.535
> >> >
> >> > i'm not very good at reading the RPN -- how does that look?
> >>
> >> Well, it's a correct translation of an "or" between the two values
> >> 1001 and 1002.  Without looking them up, I don't know what the other
> >> attributes mean, but since they're the same in the case when you
> >> search for only a single ID, I assume they're not the problem.
> >>
> >> What do you get when you use YAZ Client to submit that search, in it's
> >> PQF form, directly to the Voyager system, bypassing the YAZ Proxy?
> >>
> >> -- Mike.
> >>
> >>
> >>
> >> >
> >> > rick
> >> >
> >> > On Fri, Mar 25, 2011 at 8:40 PM, Mike Taylor <mike at indexdata.com> wrote:
> >> >> On 26 March 2011 00:34, Enrico Silterra <es287 at cornell.edu> wrote:
> >> >>> here is the interaction, connecting to yaz proxy,
> >> >>> which connects to a voyager z39.50 server.
> >> >>>
> >> >>> yaz-client -a apdu.log lxxxxxx:9090/voyager
> >> >>> Connecting...OK.
> >> >>> Sent initrequest.
> >> >>> Connection accepted by v3 target.
> >> >>> ID     : 34
> >> >>> Name   : Voyager LMS - Z39.50 Server (YAZ Proxy)
> >> >>> Version: 2007.1.1/1.3.6
> >> >>> Options: search present
> >> >>> Elapsed: 1.674038
> >> >>> Z> querytype cql
> >> >>> Z>  f rec.id=1001 or rec.id=1002
> >> >>> Sent searchRequest.
> >> >>> Received SearchResponse.
> >> >>> Search was a success.
> >> >>> Number of hits: 10000
> >> >>> records returned: 0
> >> >>> Elapsed: 7.503895
> >> >>> Z> quit
> >> >>>
> >> >>>
> >> >>> initRequest {
> >> >>>   protocolVersion BITSTRING(len=1) 111
> >> >>>   options BITSTRING(len=2) 11101001-1010001
> >> >>>   preferredMessageSize 1048576
> >> >>>   maximumRecordSize 1048576
> >> >>>   implementationId '81'
> >> >>>   implementationName 'YAZ'
> >> >>>   implementationVersion '3.0.52 e687cb7eb87c841f0d1a374174d51d30371f2d97'
> >> >>> }
> >> >>> initResponse {
> >> >>>   protocolVersion BITSTRING(len=1) 111
> >> >>>   options BITSTRING(len=1) 11
> >> >>>   preferredMessageSize 32768
> >> >>>   maximumRecordSize 1048576
> >> >>>   result TRUE
> >> >>>   implementationId '34'
> >> >>>   implementationName 'Voyager LMS - Z39.50 Server (YAZ Proxy)'
> >> >>>   implementationVersion '2007.1.1/1.3.6'
> >> >>> }
> >> >>> searchRequest {
> >> >>>   smallSetUpperBound 0
> >> >>>   largeSetLowerBound 1
> >> >>>   mediumSetPresentNumber 0
> >> >>>   replaceIndicator TRUE
> >> >>>   resultSetName 'default'
> >> >>>   databaseNames {
> >> >>>       'voyager'
> >> >>>   }
> >> >>>   {
> >> >>>       query choice
> >> >>>       type_104 {
> >> >>>           OID: 1 2 840 10003 16 2
> >> >>>           type_104 choice
> >> >>>           {
> >> >>>               'rec.id=1001 or rec.id=1002'
> >> >>>           }
> >> >>>       }
> >> >>>   }
> >> >>> }
> >> >>> searchResponse {
> >> >>>   resultCount 10000
> >> >>>   numberOfRecordsReturned 0
> >> >>>   nextResultSetPosition 1
> >> >>>   searchStatus TRUE
> >> >>>   presentStatus 0
> >> >>> }
> >> >>
> >> >> That is extremely strange.  As you may know, the Library of Congress's
> >> >> Z39.50 server is implemented by the same combination -- YAZ Proxy in
> >> >> front of a Voyager catalogue -- and that works just fine, as you can
> >> >> see in the transcript below.
> >> >>
> >> >> I can only think there must be some misconfiguration in the specific
> >> >> YAZ Proxy or Voyager installation of the particular server you're
> >> >> trying to work with.  Sorry if that's not very helpful.
> >> >>
> >> >> -- Mike.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> cartney:photos mike$ yaz-client z3950.loc.gov:7090/voyager
> >> >> Connecting...OK.
> >> >> Sent initrequest.
> >> >> Connection accepted by v3 target.
> >> >> ID     : 34
> >> >> Name   : Voyager LMS - Z39.50 Server (YAZ Proxy)
> >> >> Version: 2007.2.0/1.2.1.1
> >> >> Options: search present
> >> >> Elapsed: 0.423290
> >> >> Z> querytype cql
> >> >> Z> f rec.id=1001
> >> >> Sent searchRequest.
> >> >> Received SearchResponse.
> >> >> Search was a success.
> >> >> Number of hits: 0
> >> >> records returned: 0
> >> >> Elapsed: 0.165135
> >> >> Z> f rec.id=1001 or rec.id=1002
> >> >> Sent searchRequest.
> >> >> Received SearchResponse.
> >> >> Search was a success.
> >> >> Number of hits: 1
> >> >> records returned: 0
> >> >> Elapsed: 0.179830
> >> >> Z> f rec.id=1001 or rec.id=1002 or rec.id=1003
> >> >> Sent searchRequest.
> >> >> Received SearchResponse.
> >> >> Search was a success.
> >> >> Number of hits: 1
> >> >> records returned: 0
> >> >> Elapsed: 0.145695
> >> >> Z> f rec.id=1001 or rec.id=1002 or rec.id=1003 or rec.id=1004
> >> >> Sent searchRequest.
> >> >> Received SearchResponse.
> >> >> Search was a success.
> >> >> Number of hits: 1
> >> >> records returned: 0
> >> >> Elapsed: 0.156986
> >> >> Z> f rec.id=1001 or rec.id=1002 or rec.id=1003 or rec.id=1004 or rec.id=1005
> >> >> Sent searchRequest.
> >> >> Received SearchResponse.
> >> >> Search was a success.
> >> >> Number of hits: 2
> >> >> records returned: 0
> >> >> Elapsed: 0.197544
> >> >> Z>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Enrico Silterra Software Engineer
> >> > 501 Olin Library Cornell University Ithaca NY 14853
> >> > Voice: 607-255-6851 Fax:     607-255-6110 E-mail: es287 at cornell.edu
> >> > http://www.library.cornell.edu/dlit
> >> > "Out of the crooked timber of humanity no straight thing was ever made"
> >> > CONFIDENTIALITY NOTE
> >> > The information transmitted, including attachments, is intended only
> >> > for the person or entity to which it is addressed and may contain
> >> > confidential and/or privileged material. Any review, retransmission,
> >> > dissemination or other use of, or taking of any action in reliance
> >> > upon, this information by persons or entities other than the intended
> >> > recipient is prohibited. If you received this in error, please contact
> >> > the sender and destroy any copies of this document.
> >> >
> >> >
> >>
> >> _______________________________________________
> >> Yazlist mailing list
> >> Yazlist at lists.indexdata.dk
> >> http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist
> >>
> >
> >
> >
> > _______________________________________________
> > Yazlist mailing list
> > Yazlist at lists.indexdata.dk
> > http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist
> >
> >
> 




More information about the Yazlist mailing list