+ <ulink url="">
+
+ http://localhost:9999/?version=1.1&operation=searchRetrieve
+ &x-pquery=title%3Cthe
+ -->
+ </sect1>
+
+ <sect1 id="tutorial-oai-sru-present">
+ <title>Presenting search results in different formats</title>
+
+ <para>
+ &zebra; uses &acro.xslt; stylesheets for both &acro.xml;record
+ indexing and
+ display retrieval. In this example installation, they are two
+ retrieval schema's defined in
+ <literal>conf/dom-conf.xml</literal>:
+ the <literal>dc</literal> schema implemented in
+ <literal>conf/oai2dc.xsl</literal>, and
+ the <literal>zebra</literal> schema implemented in
+ <literal>conf/oai2zebra.xsl</literal>.
+ The URLs for accessing both are the same, except for the different
+ value of the <literal>recordSchema</literal> parameter:
+ <ulink url="http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=dc">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=dc
+ </ulink>
+ and
+ <ulink url="http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra
+ </ulink>
+ For the curious, one can see that the &acro.xslt; transformations
+ really do the magic.
+ <screen>
+ xsltproc conf/oai2dc.xsl data/debug-record.xml
+ xsltproc conf/oai2zebra.xsl data/debug-record.xml
+ </screen>
+ Notice also that the &zebra; specific parameters are injected by
+ the engine when retrieving data, therefore some of the attributes
+ in the <literal>zebra</literal> retrieval schema are not filled
+ when running the transformation from the command line.
+ </para>
+
+
+ <para>
+ In addition to the user defined retrieval schema's one can always
+ choose from many build-in schema's. In case one is only
+ interested in the &zebra; internal metadata about a certain
+ record, one uses the <literal>zebra::meta</literal> schema.
+ <ulink url="http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::meta">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::meta
+ </ulink>
+ </para>
+
+ <para>
+ The <literal>zebra::data</literal> schema is used to retrieve the
+ original stored &acro.oai; &acro.xml; record.
+ <ulink url="http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::data">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::data
+ </ulink>
+ </para>
+
+ </sect1>
+
+ <sect1 id="tutorial-oai-sru-searches">
+ <title>More interesting searches</title>
+
+ <para>
+ The &acro.oai; indexing example defines many different index
+ names, a study of the <literal>conf/oai2index.xsl</literal>
+ stylesheet reveals the following word type indexes (i.e. those
+ with suffix <literal>:w</literal>):
+ <screen>
+ any:w
+ title:w
+ author:w
+ subject:w
+ description:w
+ contributor:w
+ publisher:w
+ language:w
+ rights:w
+ </screen>
+ By default, searches do access the <literal>any:w</literal> index,
+ but we can direct searches to any access point by constructing the
+ correct &acro.pqf; query. For example, to search in titles only,
+ we use
+ <ulink
+ url="http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=@attr
+ 1=title the&startRecord=1&maximumRecords=1&recordSchema=dc">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=@attr
+ 1=title the&startRecord=1&maximumRecords=1&recordSchema=dc
+ </ulink>
+ </para>
+
+ <para>
+ Similar we can direct searches to the other indexes defined. Or we
+ can create boolean combinations of searches on different
+ indexes. In this case we search for <literal>the</literal> in
+ <literal>title</literal> and for <literal>fish</literal> in
+ <literal>description</literal> using the query
+ <literal>@and @attr 1=title the @attr 1=description fish</literal>.
+ <ulink
+ url="http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=@and
+ @attr 1=title the
+ @attr 1=description
+ fish&startRecord=1&maximumRecords=1&recordSchema=dc">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=@and
+ @attr 1=title the
+ @attr 1=description fish&startRecord=1&maximumRecords=1&recordSchema=dc
+ </ulink>
+ </para>
+
+
+ </sect1>
+
+ <sect1 id="tutorial-oai-sru-zebra-indexes">
+ <title>Investigating the content of the indexes</title>
+
+ <para>
+ How does the magic work? What is inside the indexes? Why is a certain
+ record found by a search, and another not?. The answer is in the
+ inverted indexes. You can easily investigate them using the
+ special &zebra; schema
+ <literal>zebra::index::fieldname</literal>. In this example you
+ can see that the <literal>title</literal> index has both word
+ (type <literal>:w</literal>) and phrase (type
+ <literal>:p</literal>)
+ indexed fields,
+ <ulink url="http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::index::title">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::index::title
+ </ulink>
+ </para>
+
+ <para>
+ But where in the indexes did the term match for the query occur?
+ Easily answered with the special &zebra; schema
+ <literal>zebra::snippet</literal>. The matching terms are
+ encapsulated by <literal><s></literal> tags.
+ <ulink url="http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::snippet">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::snippet
+ </ulink>
+ </para>
+
+ <para>
+ How can I refine my search? Which interesting search terms are
+ found inside my hit set? Try the special &zebra; schema
+ <literal>zebra::facet::fieldname:type</literal>. In this case, we
+ investigate additional search terms for the
+ <literal>title:w</literal> index.
+ <ulink url="http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::facet::title:w">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::facet::title:w
+ </ulink>
+ </para>
+
+ <para>
+ One can ask for multiple facets. Here, we want them from phrase
+ indexes of type
+ <literal>:p</literal>.
+ <ulink url="http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::facet::publisher:p,title:p">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&x-pquery=the&startRecord=1&maximumRecords=1&recordSchema=zebra::facet::publisher:p,title:p
+ </ulink>
+ </para>
+
+ </sect1>
+
+
+ <sect1 id="tutorial-oai-sru-yazfrontend">
+ <title>Setting up a correct &acro.sru; web service</title>
+
+ <para>
+ The &acro.sru; specification mandates that the &acro.cql; query
+ language is supported and properly configure. Also, the server
+ needs to be able to emit a proper &acro.explain; &acro.xml;
+ record, which is used to determine the capabilities of the
+ specific server instance.
+ </para>
+
+ <para>
+ In this example configuration we exploit the similarities between
+ the &acro.explain; record and the &acro.cql; query language
+ configuration, we generate the later from the former using an
+ &acro.xslt; transformation.
+ <screen>
+ xsltproc conf/explain2cqlpqftxt.xsl conf/explain.xml > conf/cql2pqf.txt
+ </screen>
+ </para>
+
+ <para>
+ We are all set to start the &acro.sru;/acro.z3950; server including
+ &acro.pqf; and &acro.cql; query configuration. It uses the &yaz; frontend
+ server configuration - just type
+ <screen>
+ zebrasrv -f conf/yazserver.xml
+ </screen>
+ </para>
+
+ <para>
+ First, we'd like to be sure that we can see the &acro.explain;
+ &acro.xml; response correctly. You might use either of these equivalent
+ requests:
+ <ulink
+ url="http://localhost:9999">http://localhost:9999
+ </ulink>
+ <ulink
+ url="http://localhost:9999/?version=1.1&operation=explain">
+ http://localhost:9999/?version=1.1&operation=explain
+ </ulink>
+
+ </para>
+
+ <para>
+ Now we can issue true &acro.sru; requests. For example,
+ <literal>dc.title=the
+ and dc.description=fish</literal> results in the following page
+ <ulink
+ url="http://localhost:9999/?version=1.1&operation=searchRetrieve&query=dc.title=the
+ and dc.description=fish
+ &startRecord=1&maximumRecords=1&recordSchema=dc">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&query=dc.title=the
+ and dc.description=fish &startRecord=1&maximumRecords=1&recordSchema=dc
+ </ulink>
+ </para>
+
+ <para>
+ Scan of indexes is a part of the &acro.sru; server business. For example,
+ scanning the <literal>dc.title</literal> index gives us an idea
+ what search terms are found there
+ <ulink
+ url="http://localhost:9999/?version=1.1&operation=scan&scanClause=dc.title=fish">
+ http://localhost:9999/?version=1.1&operation=scan&scanClause=dc.title=fish
+ </ulink>,
+ whereas
+ <ulink
+ url="http://localhost:9999/?version=1.1&operation=scan&scanClause=dc.identifier=fish">
+ http://localhost:9999/?version=1.1&operation=scan&scanClause=dc.identifier=fish
+ </ulink>
+ accesses the indexed identifiers.
+ </para>
+
+ <para>
+ In addition, all &zebra; internal special element sets or record
+ schema's of the form
+ <literal>zebra::</literal> just work right out of the box
+ <ulink
+ url="http://localhost:9999/?version=1.1&operation=searchRetrieve&query=dc.title=the
+ and dc.description=fish
+ &startRecord=1&maximumRecords=1&recordSchema=zebra::snippet">
+ http://localhost:9999/?version=1.1&operation=searchRetrieve&query=dc.title=the
+ and dc.description=fish &startRecord=1&maximumRecords=1&recordSchema=zebra::snippet
+ </ulink>
+ </para>
+
+
+
+ </sect1>
+
+
+ <sect1 id="tutorial-oai-z3950">
+ <title>Searching the &acro.oai; database by &acro.z3950; protocol</title>