doc/querymodel.xml

   1 <chapter id="querymodel">
   2  <!-- $Id: querymodel.xml,v 1.1 2006-06-13 09:27:01 marc Exp $ -->
   3  <title>Query Model</title>
   4
   5   <sect1 id="querymodel-overview">
   6    <title>Query Model Overview</title>
   7
   8    <para>
   9     Zebra is born as a networking Information Retrieval engine adhering
  10     to the international standards
  11     <ulink url="http://www.loc.gov/z3950/agency/">Z39.50</ulink> and
  12     <ulink url="http://www.loc.gov/standards/sru/">SRU</ulink>,
  13     and implement the query model defined there.
  14     Unfortunately, the Z39.50 query model has only defined a binary
  15     encoded representation, which is used as transport packaging in
  16     the Z39.50 protocol layer. This representation is not human
  17     readable, nor defines any convenient way to specify queries.
  18    </para>
  19    <para>
  20     Therefore, Index Data has defined a textual representaion in the
  21     <literal>Prefix Query Format</literal>, short
  22     <literal>PQF</literal>, which then has been adopted by other
  23     parties developing Z39.50 software. It is also often referred to as
  24     <literal>Prefix Query Notation</literal>, or in short
  25     <literal>PQN</literal>, and is thoroughly explained in
  26     <xref linkend="querymodel-pqf"/>.
  27    </para>
  28
  29    <para>
  30     In addition, Zebra can be configured to understand and map the
  31     <literal>Common Query Language</literal>
  32     (<ulink url="http://www.loc.gov/standards/sru/cql/">CQL</ulink>)
  33     to PQF. See an introduction on the mapping to the internal query
  34     representation in
  35     <xref linkend="querymodel-cql-to-pqf"/>.
  36    </para>
  37    </sect1>
  38
  39   <sect1 id="querymodel-pqf">
  40    <title>Prefix Query Format structure and syntax</title>
  41    <para>
  42     The
  43     <ulink url="http://indexdata.dk/yaz/doc/tools.tkl#PQF">PQF
  44     grammer</ulink> is documented in the YAZ manual.
  45     This textual PQF representation
  46     is always during search mapped to the equivalent Zebra internal
  47     query parse tree.
  48    </para>
  49
  50    <para>
  51    </para>
  52
  53   <sect2 id="querymodel-exp1">
  54    <title>Explain Attribute Set</title>
  55    <para>
  56      The attribute-set <literal>exp-1</literal> is defined for
  57      searching an Explain <literal>IR-Explain-1</literal> database.
  58      It consists of a single <literal>Use (type 1)</literal> attribute.
  59    </para>
  60    <para>
  61      In addition, the non-Use
  62      <literal>bib-1</literal> attributes, that is, the types
  63      <literal>Relation</literal>, <literal>Position</literal>,
  64      <literal>Structure</literal>, <literal>Truncation</literal>,
  65      and <literal>Completeness</literal> are imported from
  66      the <literal>bib-1</literal> attrubute set, and may be used
  67      within any explain query.
  68    </para>
  69
  70    <sect3 id="querymodel-exp1-use">
  71     <title>Use Attributes (type = 1)</title>
  72     <para>
  73      The following Explain search atributes are supported:
  74      <literal>ExplainCategory</literal> (@attr 1=1),
  75      <literal>DatabaseName</literal> (@attr 1=3),
  76      <literal>DateAdded</literal> (@attr 1=9),
  77      <literal>DateChanged</literal>(@attr 1=10).
  78     </para>
  79     <para>
  80      A search in the use attribute  <literal>ExplainCategory</literal>
  81      supports only these predefined values:
  82      <literal>CategoryList</literal>, <literal>TargetInfo</literal>,
  83      <literal>DatabaseInfo</literal>, <literal>AttributeDetails</literal>.
  84     </para>
  85      <para>
  86       See <filename>tab/explain.att</filename> and the
  87       for more information.
  88       </para>
  89    </sect3>
  90
  91     <sect3>
  92      <title>Explain searches with yaz-client</title>
  93      <para>
  94       List supported categories to find out which explain commands are
  95       supported:
  96       <screen>
  97        Z> base IR-Explain-1
  98        Z> @attr exp1 1=1 categorylist
  99        Z> form sutrs
 100        Z> show 1+2
 101       </screen>
 102      </para>
 103
 104      <para>
 105       Get target info, that is, investigate which databases exist at
 106       this server endpoint:
 107       <screen>
 108        Z> base IR-Explain-1
 109        Z> @attr exp1 1=1 targetinfo
 110        Z> form xml
 111        Z> show 1+1
 112        Z> form grs-1
 113        Z> show 1+1
 114        Z> form sutrs
 115        Z> show 1+1
 116       </screen>
 117      </para>
 118
 119      <para>
 120       List all supported databases, the number of hits
 121       is the number of databases found, which most commonly are the
 122       following two:
 123       the <literal>Default</literal> and the
 124       <literal>IR-Explain-1</literal> databases.
 125       <screen>
 126        Z> base IR-Explain-1
 127        Z> f @attr exp1 1=1 databaseinfo
 128        Z> form sutrs
 129        Z> show 1+2
 130       </screen>
 131      </para>
 132
 133      <para>
 134       Get database info record for database <literal>Default</literal>.
 135       <screen>
 136        Z> base IR-Explain-1
 137        Z> @and @attr exp1 1=1 databaseinfo @attr exp1 1=3 Default
 138       </screen>
 139       Identical query with explicitly specified attribute set:
 140       <screen>
 141        Z> base IR-Explain-1
 142        Z> @attrset exp1 @and @attr 1=1 databaseinfo @attr 1=3 Default
 143       </screen>
 144      </para>
 145
 146      <para>
 147       Get attribute details record for database
 148       <literal>Default</literal>.
 149       This query is very useful to study the internal Zebra indexes.
 150       If records have been indexed using the <literal>alvis</literal>
 151       XSLT filter, the string representation names of the known indexes can be
 152       found.
 153       <screen>
 154        Z> base IR-Explain-1
 155        Z> @and @attr exp1 1=1 attributedetails @attr exp1 1=3 Default
 156       </screen>
 157       Identical query with explicitly specified attribute set:
 158       <screen>
 159        Z> base IR-Explain-1
 160        Z> @attrset exp1 @and @attr 1=1 attributedetails @attr 1=3 Default
 161       </screen>
 162      </para>
 163     </sect3>
 164
 165   </sect2>
 166
 167   <sect2 id="querymodel-bib1">
 168    <title>Bib1 Attribute Set</title>
 169    <para>
 170     Something about querying to be written ..
 171    </para>
 172    <para>
 173     Most of the information contained in this section is an excerpt of
 174     the <literal>ATTRIBUTE SET BIB-1 (Z39.50-1995)
 175     SEMANTICS</literal>, found at  <ulink
 176     url="http://www.loc.gov/z3950/agency/bib1.html">The BIB-1
 177     Attribute Set Semantics</ulink> from 1995, also in an updated
 178    <ulink
 179     url="http://www.loc.gov/z3950/agency/defns/bib1.html">Bib-1
 180     Attribute Set</ulink>
 181     version from 2003. Index Data is not the copyright holder of this
 182     information.
 183    </para>
 184
 185
 186    <sect3 id="querymodel-bib1-use">
 187     <title>Use Attributes (type = 1)</title>
 188    </sect3>
 189
 190    <sect3 id="querymodel-bib1-relation">
 191     <title>Relation Attributes     (type = 2)</title>
 192    </sect3>
 193    <para>
 194    </para>
 195
 196    <sect3 id="querymodel-bib1-position">
 197     <title>Position Attributes     (type = 3)</title>
 198    </sect3>
 199
 200    <sect3 id="querymodel-bib1-structure">
 201     <title>Structure Attributes    (type = 4)</title>
 202    </sect3>
 203
 204    <sect3 id="querymodel-bib1-truncation">
 205     <title>Truncation Attributes   (type = 5)</title>
 206    </sect3>
 207
 208    <sect3 id="querymodel-bib1-completeness">
 209     <title>Completeness Attributes (type = 6)</title>
 210    </sect3>
 211
 212    <sect3 id="querymodel-bib1-sorting">
 213     <title>Zebra Extention Sorting Attributes (type = 7)</title>
 214    </sect3>
 215
 216    <sect3 id="querymodel-bib1-estimation">
 217     <title>Zebra Extention Search Estimation Attributes (type = 8)</title>
 218    </sect3>
 219
 220    <sect3 id="querymodel-bib1-weight">
 221     <title>Zebra Extention Weight Attributes (type = 9)</title>
 222    </sect3>
 223
 224   </sect2>
 225
 226    <sect2 id="querymodel-bib1-mapping">
 227     <title>Mapping from Bib1 Attributes to Zebra internal
 228      register indexes</title>
 229      <para>
 230      </para>
 231
 232    <para>
 233     <emphasis>Use</emphasis> attributes are interpreted according to the
 234     attribute sets which have been loaded in the
 235     <literal>zebra.cfg</literal> file, and are matched against specific
 236     fields as specified in the <literal>.abs</literal> file which
 237     describes the profile of the records which have been loaded.
 238     If no Use attribute is provided, a default of Bib-1 Any is assumed.
 239    </para>
 240
 241    <para>
 242     If a <emphasis>Structure</emphasis> attribute of
 243     <emphasis>Phrase</emphasis> is used in conjunction with a
 244     <emphasis>Completeness</emphasis> attribute of
 245     <emphasis>Complete (Sub)field</emphasis>, the term is matched
 246     against the contents of the phrase (long word) register, if one
 247     exists for the given <emphasis>Use</emphasis> attribute.
 248     A phrase register is created for those fields in the
 249     <literal>.abs</literal> file that contains a
 250     <literal>p</literal>-specifier.
 251     <!-- ### whatever the hell _that_ is -->
 252    </para>
 253
 254    <para>
 255     If <emphasis>Structure</emphasis>=<emphasis>Phrase</emphasis> is
 256     used in conjunction with <emphasis>Incomplete Field</emphasis> - the
 257     default value for <emphasis>Completeness</emphasis>, the
 258     search is directed against the normal word registers, but if the term
 259     contains multiple words, the term will only match if all of the words
 260     are found immediately adjacent, and in the given order.
 261     The word search is performed on those fields that are indexed as
 262     type <literal>w</literal> in the <literal>.abs</literal> file.
 263    </para>
 264
 265    <para>
 266     If the <emphasis>Structure</emphasis> attribute is
 267     <emphasis>Word List</emphasis>,
 268     <emphasis>Free-form Text</emphasis>, or
 269     <emphasis>Document Text</emphasis>, the term is treated as a
 270     natural-language, relevance-ranked query.
 271     This search type uses the word register, i.e. those fields
 272     that are indexed as type <literal>w</literal> in the
 273     <literal>.abs</literal> file.
 274    </para>
 275
 276    <para>
 277     If the <emphasis>Structure</emphasis> attribute is
 278     <emphasis>Numeric String</emphasis> the term is treated as an integer.
 279     The search is performed on those fields that are indexed
 280     as type <literal>n</literal> in the <literal>.abs</literal> file.
 281    </para>
 282
 283    <para>
 284     If the <emphasis>Structure</emphasis> attribute is
 285     <emphasis>URx</emphasis> the term is treated as a URX (URL) entity.
 286     The search is performed on those fields that are indexed as type
 287     <literal>u</literal> in the <literal>.abs</literal> file.
 288    </para>
 289
 290    <para>
 291     If the <emphasis>Structure</emphasis> attribute is
 292     <emphasis>Local Number</emphasis> the term is treated as
 293     native Zebra Record Identifier.
 294    </para>
 295
 296    <para>
 297     If the <emphasis>Relation</emphasis> attribute is
 298     <emphasis>Equals</emphasis> (default), the term is matched
 299     in a normal fashion (modulo truncation and processing of
 300     individual words, if required).
 301     If <emphasis>Relation</emphasis> is <emphasis>Less Than</emphasis>,
 302     <emphasis>Less Than or Equal</emphasis>,
 303     <emphasis>Greater than</emphasis>, or <emphasis>Greater than or
 304      Equal</emphasis>, the term is assumed to be numerical, and a
 305     standard regular expression is constructed to match the given
 306     expression.
 307     If <emphasis>Relation</emphasis> is <emphasis>Relevance</emphasis>,
 308     the standard natural-language query processor is invoked.
 309    </para>
 310
 311    <para>
 312     For the <emphasis>Truncation</emphasis> attribute,
 313     <emphasis>No Truncation</emphasis> is the default.
 314     <emphasis>Left Truncation</emphasis> is not supported.
 315     <emphasis>Process # in search term</emphasis> is supported, as is
 316     <emphasis>Regxp-1</emphasis>.
 317     <emphasis>Regxp-2</emphasis> enables the fault-tolerant (fuzzy)
 318     search. As a default, a single error (deletion, insertion,
 319     replacement) is accepted when terms are matched against the register
 320     contents.
 321    </para>
 322   </sect2>
 323
 324    <sect2  id="querymodel-regular">
 325     <title>Regular expressions</title>
 326
 327     <para>
 328      Each term in a query is interpreted as a regular expression if
 329      the truncation value is either <emphasis>Regxp-1</emphasis> (102)
 330      or <emphasis>Regxp-2</emphasis> (103).
 331      Both query types follow the same syntax with the operands:
 332      <variablelist>
 333
 334       <varlistentry>
 335        <term>x</term>
 336        <listitem>
 337         <para>
 338          Matches the character <emphasis>x</emphasis>.
 339         </para>
 340        </listitem>
 341       </varlistentry>
 342       <varlistentry>
 343        <term>.</term>
 344        <listitem>
 345         <para>
 346          Matches any character.
 347         </para>
 348        </listitem>
 349       </varlistentry>
 350       <varlistentry>
 351        <term><literal>[</literal>..<literal>]</literal></term>
 352        <listitem>
 353         <para>
 354          Matches the set of characters specified;
 355          such as <literal>[abc]</literal> or <literal>[a-c]</literal>.
 356         </para>
 357        </listitem>
 358       </varlistentry>
 359      </variablelist>
 360      and the operators:
 361      <variablelist>
 362
 363       <varlistentry>
 364        <term>x*</term>
 365        <listitem>
 366         <para>
 367          Matches <emphasis>x</emphasis> zero or more times. Priority: high.
 368         </para>
 369        </listitem>
 370       </varlistentry>
 371       <varlistentry>
 372        <term>x+</term>
 373        <listitem>
 374         <para>
 375          Matches <emphasis>x</emphasis> one or more times. Priority: high.
 376         </para>
 377        </listitem>
 378       </varlistentry>
 379       <varlistentry>
 380        <term>x?</term>
 381        <listitem>
 382         <para>
 383          Matches <emphasis>x</emphasis> zero or once. Priority: high.
 384         </para>
 385        </listitem>
 386       </varlistentry>
 387       <varlistentry>
 388        <term>xy</term>
 389        <listitem>
 390         <para>
 391          Matches <emphasis>x</emphasis>, then <emphasis>y</emphasis>.
 392          Priority: medium.
 393         </para>
 394        </listitem>
 395       </varlistentry>
 396       <varlistentry>
 397        <term>x|y</term>
 398        <listitem>
 399         <para>
 400          Matches either <emphasis>x</emphasis> or <emphasis>y</emphasis>.
 401          Priority: low.
 402         </para>
 403        </listitem>
 404       </varlistentry>
 405      </variablelist>
 406      The order of evaluation may be changed by using parentheses.
 407     </para>
 408
 409     <para>
 410      If the first character of the <emphasis>Regxp-2</emphasis> query
 411      is a plus character (<literal>+</literal>) it marks the
 412      beginning of a section with non-standard specifiers.
 413      The next plus character marks the end of the section.
 414      Currently Zebra only supports one specifier, the error tolerance,
 415      which consists one digit.
 416     </para>
 417
 418     <para>
 419      Since the plus operator is normally a suffix operator the addition to
 420      the query syntax doesn't violate the syntax for standard regular
 421      expressions.
 422     </para>
 423
 424    </sect2>
 425
 426    <sect2  id="querymodel-examples">
 427     <title>Query examples</title>
 428
 429     <para>
 430      Phrase search for <emphasis>information retrieval</emphasis> in
 431      the title-register:
 432      <screen>
 433       @attr 1=4 "information retrieval"
 434      </screen>
 435     </para>
 436
 437     <para>
 438      Ranked search for the same thing:
 439      <screen>
 440       @attr 1=4 @attr 2=102 "Information retrieval"
 441      </screen>
 442     </para>
 443
 444     <para>
 445      Phrase search with a regular expression:
 446      <screen>
 447       @attr 1=4 @attr 5=102 "informat.* retrieval"
 448      </screen>
 449     </para>
 450
 451     <para>
 452      Ranked search with a regular expression:
 453      <screen>
 454       @attr 1=4 @attr 5=102 @attr 2=102 "informat.* retrieval"
 455      </screen>
 456     </para>
 457
 458     <para>
 459      In the GILS schema (<literal>gils.abs</literal>), the
 460      west-bounding-coordinate is indexed as type <literal>n</literal>,
 461      and is therefore searched by specifying
 462      <emphasis>structure</emphasis>=<emphasis>Numeric String</emphasis>.
 463      To match all those records with west-bounding-coordinate greater
 464      than -114 we use the following query:
 465      <screen>
 466       @attr 4=109 @attr 2=5 @attr gils 1=2038 -114
 467      </screen>
 468     </para>
 469    </sect2>
 470
 471
 472      <!-- see in util/zebramap.c
 473       int zebra_maps_attr
 474
 475   if (completeness_value == 2 || completeness_value == 3)
 476         *complete_flag = 1;
 477     else
 478         *complete_flag = 0;
 479     *reg_id = 0;
 480
 481     *sort_flag =(sort_relation_value > 0) ? 1 : 0;
 482     *search_type = "phrase";
 483     strcpy(rank_type, "void");
 484     if (relation_value == 102)
 485     {
 486         if (weight_value == -1)
 487             weight_value = 34;
 488         sprintf(rank_type, "rank,w=%d,u=%d", weight_value, use_value);
 489     }
 490     if (relation_value == 103)
 491     {
 492         *search_type = "always";
 493         *reg_id = 'w';
 494         return 0;
 495     }
 496     if (*complete_flag)
 497         *reg_id = 'p';
 498     else
 499         *reg_id = 'w';
 500     switch (structure_value)
 501     {
 502     case 6:   /* word list */
 503         *search_type = "and-list";
 504         break;
 505     case 105: /* free-form-text */
 506         *search_type = "or-list";
 507         break;
 508     case 106: /* document-text */
 509         *search_type = "or-list";
 510         break;
 511     case -1:
 512     case 1:   /* phrase */
 513     case 2:   /* word */
 514     case 108: /* string */
 515         *search_type = "phrase";
 516         break;
 517    case 107: /* local-number */
 518         *search_type = "local";
 519         *reg_id = 0;
 520         break;
 521     case 109: /* numeric string */
 522         *reg_id = 'n';
 523         *search_type = "numeric";
 524         break;
 525     case 104: /* urx */
 526         *reg_id = 'u';
 527         *search_type = "phrase";
 528         break;
 529     case 3:   /* key */
 530         *reg_id = '0';
 531         *search_type = "phrase";
 532         break;
 533     case 4:  /* year */
 534         *reg_id = 'y';
 535         *search_type = "phrase";
 536         break;
 537     case 5:  /* date */
 538         *reg_id = 'd';
 539         *search_type = "phrase";
 540         break;
 541     default:
 542         return -1;
 543     }
 544     return 0;
 545
 546      -->
 547
 548    <!--
 549    <para>
 550     The RecordType parameter in the <literal>zebra.cfg</literal> file, or
 551     the <literal>-t</literal> option to the indexer tells Zebra how to
 552     process input records.
 553     Two basic types of processing are available - raw text and structured
 554     data. Raw text is just that, and it is selected by providing the
 555     argument <emphasis>text</emphasis> to Zebra. Structured records are
 556     all handled internally using the basic mechanisms described in the
 557     subsequent sections.
 558     Zebra can read structured records in many different formats.
 559    </para>
 560    -->
 561   </sect1>
 562
 563
 564   <sect1 id="querymodel-cql-to-pqf">
 565    <title>Server Side CQL to PQF Query Translation</title>
 566    <para>
 567     Using the
 568     <literal>&lt;cql2rpn&gt;l2rpn.txt&lt;/cql2rpn&gt;</literal>
 569       YAZ Frontend Virtual
 570     Hosts option, one can configure
 571     the YAZ Frontend CQL-to-PQF
 572     converter, specifying the interpretation of various
 573     <ulink url="http://www.loc.gov/standards/sru/cql/">CQL</ulink>
 574     indexes, relations, etc. in terms of Type-1 query attributes.
 575     <!-- The  yaz-client config file -->
 576    </para>
 577    <para>
 578     For example, using server-side CQL-to-PQF conversion, one might
 579     query a zebra server like this:
 580     <screen>
 581     <![CDATA[
 582      yaz-client localhost:9999
 583      Z> querytype cql
 584      Z> find text=(plant and soil)
 585      ]]>
 586     </screen>
 587      and - if properly configured - even static relevance ranking can
 588      be performed using CQL query syntax:
 589     <screen>
 590     <![CDATA[
 591      Z> find text = /relevant (plant and soil)
 592      ]]>
 593      </screen>
 594    </para>
 595
 596    <para>
 597     By the way, the same configuration can be used to
 598     search using client-side CQL-to-PQF conversion:
 599     (the only difference is <literal>querytype cql2rpn</literal>
 600     instead of
 601     <literal>querytype cql</literal>, and the call specifying a local
 602     conversion file)
 603     <screen>
 604     <![CDATA[
 605      yaz-client -q local/cql2pqf.txt localhost:9999
 606      Z> querytype cql2rpn
 607      Z> find text=(plant and soil)
 608      ]]>
 609      </screen>
 610    </para>
 611
 612    <para>
 613     Exhaustive information can be found in the
 614     Section "Specification of CQL to RPN mappings" in the YAZ manual.
 615     <ulink url="http://www.indexdata.dk/yaz/doc/tools.tkl#tools.cql.map">
 616      http://www.indexdata.dk/yaz/doc/tools.tkl#tools.cql.map</ulink>,
 617    and shall therefore not be repeated here.
 618    </para>
 619   <!--
 620   <para>
 621     See
 622       <ulink url="http://www.loc.gov/z3950/agency/zing/cql/dc-indexes.html">
 623       http://www.loc.gov/z3950/agency/zing/cql/dc-indexes.html</ulink>
 624     for the Maintenance Agency's work-in-progress mapping of Dublin Core
 625     indexes to Attribute Architecture (util, XD and BIB-2)
 626     attributes.
 627    </para>
 628    -->
 629  </sect1>
 630
 631
 632
 633 <!--
 634   <sect1 id="architecture-querylanguage">
 635    <title>Query Languages</title>
 636
 637    <para>
 638
 639 http://www.loc.gov/z3950/agency/document.html
 640
 641     PQF and BIB-1 stuff to be explained
 642     <ulink url="http://www.loc.gov/z3950/agency/defns/bib1.html">
 643      http://www.loc.gov/z3950/agency/defns/bib1.html</ulink>
 644
 645      <ulink url="http://www.loc.gov/z3950/agency/bib1.html">
 646      http://www.loc.gov/z3950/agency/bib1.html</ulink>
 647
 648      http://www.loc.gov/z3950/agency/markup/13.html
 649
 650   </para>
 651   </sect1>
 652
 653
 654 These attribute types are recognized regardless of attribute set. Some are recognized for search, others for scan.
 655
 656 Search
 657
 658 Type    Name    Version
 659 7       Embedded Sort   1.1
 660 8       Term Set        1.1
 661 9       Rank weight     1.1
 662 9       Approx Limit    1.4
 663 10      Term Ref        1.4
 664
 665 Embedded Sort
 666
 667 The embedded sort is a way to specify sort within a query - thus removing the need to send a Sort Request separately. It is both faster and does not require clients that deal with the Sort Facility.
 668
 669 The value after attribute type 7 is 1=ascending, 2=descending.. The attributes+term (APT) node is separate from the rest and must be @or'ed. The term associated with APT is the level .. 0=primary sort, 1=secondary sort etc.. Example:
 670
 671 Search for water, sort by title (ascending):
 672
 673   @or @attr 1=1016 water @attr 7=1 @attr 1=4 0
 674
 675 Search for water, sort by title ascending, then date descending:
 676
 677   @or @or @attr 1=1016 water @attr 7=1 @attr 1=4 0 @attr 7=2 @attr 1=30 1
 678
 679 Term Set
 680
 681 The Term Set feature is a facility that allows a search to store hitting terms in a "pseudo" resultset; thus a search (as usual) + a scan-like facility. Requires a client that can do named result sets since the search generates two result sets. The value for attribute 8 is the name of a result set (string). The terms in term set are returned as SUTRS records.
 682
 683 Seach for u in title, right truncated.. Store result in result set named uset.
 684
 685   @attr 5=1 @attr 1=4 @attr 8=uset u
 686
 687 The model as one serious flaw.. We don't know the size of term set.
 688
 689 Rank weight
 690
 691 Rank weight is a way to pass a value to a ranking algorithm - so that one APT has one value - while another as a different one.
 692
 693 Search for utah in title with weight 30 as well as any with weight 20.
 694
 695   @attr 2=102 @or @attr 9=30 @attr 1=4 utah @attr 9=20 utah
 696
 697 Approx Limit
 698
 699 Newer Zebra versions normally estemiates hit count for every APT (leaf) in the query tree. These hit counts are returned as part of the searchResult-1 facility.
 700
 701 By setting a limit for the APT we can make Zebra turn into approximate hit count when a certain hit count limit is reached. A value of zero means exact hit count.
 702
 703 We are intersted in exact hit count for a, but for b we allow estimates for 1000 and higher..
 704
 705   @and a @attr 9=1000 b
 706
 707 This facility clashes with rank weight! Fortunately this is a Zebra 1.4 thing so we can change this without upsetting anybody!
 708
 709 Term Ref
 710
 711 Zebra supports the searchResult-1 facility.
 712
 713 If attribute 10 is given, that specifies a subqueryId value returned as part of the search result. It is a way for a client to name an APT part of a query.
 714
 715 Scan
 716
 717 Type    Name    Version
 718 8       Result set narrow       1.3
 719 9       Approx Limit    1.4
 720
 721 Result set narrow
 722
 723 If attribute 8 is given for scan, the value is the name of a result set. Each hit count in scan is @and'ed with the result set given.
 724
 725 Approx limit
 726
 727 The approx (as for search) is a way to enable approx hit counts for scan hit counts. However, it does NOT appear to work at the moment.
 728
 729
 730  AdamDickmeiss - 19 Dec 2005
 731
 732
 733 -->
 734
 735 </chapter>
 736
 737  <!-- Keep this comment at the end of the file
 738  Local variables:
 739  mode: sgml
 740  sgml-omittag:t
 741  sgml-shorttag:t
 742  sgml-minimize-attributes:nil
 743  sgml-always-quote-attributes:t
 744  sgml-indent-step:1
 745  sgml-indent-data:t
 746  sgml-parent-document: "zebra.xml"
 747  sgml-local-catalogs: nil
 748  sgml-namecase-general:t
 749  End:
 750  -->