Example Alvis XSLT filter configuration



Indexing:

   ../../index/zebraidx -c conf/zebra.cfg init
   ../../index/zebraidx -c conf/zebra.cfg update data/*.xml
   ../../index/zebraidx -c conf/zebra.cfg commit


Checking manually the indexing stylesheet:

   xsltproc conf/oai2index.xsl data/debug-record.xml


Starting the SRU/SRW/Z39.50 server:

   ../../index/zebrasrv -f yazserver.xml


Checking manually the retrieval stylesheets:

   xsltproc conf/identity.xsl data/debug-record.xml
   xsltproc conf/oai2dc.xsl data/debug-record.xml
   xsltproc conf/oai2zebra.xsl data/debug-record.xml


Z39.50 explain (needs tewaking of the conf/explain-xml file):

   yaz-client localhost:9999
   Z> explain

Z39.50 search:

   yaz-client localhost:9999
   Z> format xml
   Z> querytype prefix
   Z> elem oai
   Z> find @attr 1=oai_identifier  @attr 4=3 
                  "oai_caltechcstr.library.caltech.edu:4"
   Z> show 1+1
   Z> find @attr 1=oai_datestamp  @attr 4=3 "2001-04-20"
   Z> find @attr 1=oai_setspec @attr 4=3 7374617475733D756E707562
   Z>
   Z> elem dc
   Z> find @attr 1=dc_title communication
   Z> show 1+1
   Z> find @attr 1=dc_identifier @attr 4=3  
                 "http://resolver.caltech.edu/CaltechCSTR:1986.5228-tr-86"

   etc, etc. 

   Notice that all indexes defined by 'type="0"' in the 
   indexing style  sheet must be searched using the '@attr 4=3' 
   structure attribute instruction.   

   Notice also that searching and scan on indexes
   'dc_contributor',  'dc_language', 'dc_rights', and 'dc_source' 
   fails, simply because none of the records in this example set 
   have these fields set, and consequently, these indexes are 
   _not_ created. 


Z39.50 search using server-side CQL conversion:

   Z> format xml
   Z> querytype cql
   Z> elem dc
   Z>
   Z> find harry 
   Z>
   Z> find creator = the
   Z> find dc.creator = the
   Z> find title = the
   Z>
   Z> find description < the
   Z> find title le some
   Z> find title ge some
   Z> find title > some
   Z>
   Z> find identifier eq 
           "http://resolver.caltech.edu/CaltechCSTR:1978.2276-tr-78"
   Z> find relation eq something 
   

   etc, etc. Notice that  all indexes defined by 'type="0"' in the 
   indexing style  sheet must be searched using the 'eq' 
   relation.    

   Z> find title <> and

   fails as well.  ???


Z39.50 scan:

   yaz-client localhost:9999
   Z> format xml
   Z> querytype prefix
   Z> scan @attr 1=oai_identifier @attr 4=3 oai
   Z> scan @attr 1=oai_datestamp @attr 4=3 1
   Z> scan @attr 1=oai_setspec @attr 4=3 2000
   Z>
   Z> scan @attr 1=dc_title communication
   Z> scan @attr 1=dc_identifier @attr 4=3 a

   etc, etc,

Z39.50 scan using server side CQL conversion:

   Unfortunately, this will _never_ work as it is not supported by the 
   Z39.50 standard.
   If you want to use scan using server side CQL conversion, you need to  
   make an SRW connection using  yaz-client, or a
   SRU connection using REST Web Services - any browser will do.


SRU Explain ZeeRex response:

   http://localhost:9999/
   http://localhost:9999/?version=1.1&operation=explain


SRU Search Retrieve records:

   http://localhost:9999/?version=1.1&operation=searchRetrieve
                          &query=creator=adam

   http://localhost:9999/?version=1.1&operation=searchRetrieve
                         &query=date=1978-01-01
                         &startRecord=1&maximumRecords=1&recordSchema=dc

   http://localhost:9999/?version=1.1&operation=searchRetrieve
                         &query=dc.title=the

   http://localhost:9999/?version=1.1&operation=searchRetrieve
                         &query=description=the


   relation tests:

   http://localhost:9999/?version=1.1&operation=searchRetrieve
                      &query=title%3Cthe


SRU scan:

   http://localhost:9999/?version=1.1&operation=scan&scanClause=title=a
   http://localhost:9999/?version=1.1&operation=scan
                      &scanClause=identifier%20eq%20a

   Notice: you need to use the 'eq' relation for all @attr 4=3 indexes



SRW explain with CQL index points:

   Z> open http://localhost:9999
   Z> explain

   Notice: when opening a connection using the 'http.//' prefix, yaz-client
   uses SRW SOAP connections, and 'form xml' and 'querytype cql' are 
   implicitely set.


SRW search using implicit server side CQL:

   Z> open http://localhost:9999
   Z> find identifier eq 
        "http://resolver.caltech.edu/CaltechCSTR:1978.2276-tr-78"
   Z> find description < the


   In SRW connection mode, the follwing fails due to problem in yaz-client:
   Z> elem dc
   Z> s 1+1


SRW scan using implicit server side CQL:

   yaz-client http://localhost:9999
   Z> scan title = communication
   Z> scan identifier eq a  

   Notice: you need to use the 'eq' relation for all @attr 4=3 indexes



Some additional notes:

When using SRW connections, the logs look like this:
 ... [request] SRWSearch OK 100 - 1+0 
     CQL: description < the

When using Z39.50 connection with querytype CQL, it looks like that:
 ... [request] Search OK 100 1 1+0 
     RPN: @attrset Bib-1 @attr 5=100 @attr 6=1 @attr 3=3 @attr 4=1 
          @attr 2=1 @attr "1=dc_description" the

Why the difference in logging ??


  Kimmo asked:
  2) How do you add to the index attributes of any other type than "w"?
  I mean, in the context of making CQL queries. Let's say I want a date 
  attribute in there, so that one could do date > 20050101 in CQL.

  Currently for example 'date-modified' is of type 'w'.

  The 2-seconds-of-though solution:

     in alvis2index.sl:

    <z:index name="date-modified" type="d">
      <xsl:value-of 
           select="acquisition/acquisitionData/modifiedDate"/>
    </z:index>

  But here's the catch...doesn't the use of the 'd' type require 
  structure type 'date' (@attr 4=5) in PQF? But then...how does that
  reflect in the CQL->RPN/PQF mapping -- does it really work if I just
  change the type of an element in alvis2index.sl? I would think not...?

  No, it does not. CQL-2-PQF conversion is a little weak at this
  point. You have to define a new relation to do so:

  relation.eq                             = 2=3

  Then you can put a new structure attribute on this:

  structure.eq                            = 4=5

  Finally, a query like this works:

  f date-modified eq 20050713
  if the PQF index date-modified has been defined with type="d"

