<chapter id="querymodel">
- <!-- $Id: querymodel.xml,v 1.34 2007-06-22 12:59:23 marc Exp $ -->
<title>Query Model</title>
<section id="querymodel-overview">
The <ulink url="&url.yaz.pqf;">&acro.pqf; grammar</ulink>
is documented in the &yaz; manual, and shall not be
repeated here. This textual &acro.pqf; representation
- is not transmistted to &zebra; during search, but it is in the
+ is not transmitted to &zebra; during search, but it is in the
client mapped to the equivalent &acro.z3950; binary
query parse tree.
</para>
<para>
It is possible to search
in any silly string index - if it's defined in your
- indexation rules and can be parsed by the &acro.pqf; parser.
+ indexing rules and can be parsed by the &acro.pqf; parser.
This is definitely not the recommended use of
this facility, as it might confuse your users with some very
unexpected results.
<emphasis>string</emphasis> attributes which in appearance
<emphasis>resemble XPath queries</emphasis>. There are two
problems with this approach: first, the XPath-look-alike has to
- be defined at indexation time, no new undefined
+ be defined at indexing time, no new undefined
XPath queries can entered at search time, and second, it might
confuse users very much that an XPath-alike index name in fact
gets populated from a possible entirely different &acro.xml; element
<literal>Word list (6)</literal>
is supported, and maps to the boolean <literal>AND</literal>
combination of words supplied. The word list is useful when
- google-like bag-of-word queries need to be translated from a GUI
+ Google-like bag-of-word queries need to be translated from a GUI
query language to &acro.pqf;. For example, the following queries
are equivalent:
<screen>
search and scan in index <literal>type="p"</literal>.
</para>
<para>
- The <literal>Complete subfield (2)</literal> is a reminiscens
+ The <literal>Complete subfield (2)</literal> is a reminiscent
from the happy <literal>&acro.marc;</literal>
binary format days. &zebra; does not support it, but maps silently
to <literal>Complete field (3)</literal>.
</para>
<para>
By setting an estimation limit size of the resultset of the &acro.apt;
- leaves, &zebra; stoppes processing the result set when the limit
+ leaves, &zebra; stops processing the result set when the limit
length is reached.
Hit counts under this limit are still precise, but hit counts over it
are estimated using the statistics gathered from the chopped
result set.
</para>
<para>
- Specifying a limit of <literal>0</literal> resuts in exact hit counts.
+ Specifying a limit of <literal>0</literal> results in exact hit counts.
</para>
<para>
For example, we might be interested in exact hit count for a, but
</row>
<row>
<entry>Approximative Limit</entry>
- <entry>9</entry>
+ <entry>12</entry>
<entry>scan</entry>
- <entry>1.4</entry>
+ <entry>2.0.20</entry>
</row>
</tbody>
</tgroup>
</section>
<section id="querymodel-zebra-attr-approx">
- <title>&zebra; Extension Approximative Limit (type 11)</title>
+ <title>&zebra; Extension Approximative Limit (type 12)</title>
<para>
- The &zebra; Extension Approximative Limit (type 11) is a way to
+ The &zebra; Extension Approximative Limit (type 12) is a way to
enable approximate hit counts for scan hit counts, in the same
way as for search hit counts.
</para>
<entry>key (@attr 4=3)</entry>
<entry>ignored</entry>
<entry>Null bitmap ('0')</entry>
- <entry>Used for non-tokenizated and non-normalized bit sequences</entry>
+ <entry>Used for non-tokenized and non-normalized bit sequences</entry>
</row>
<row>
<entry>year (@attr 4=4)</entry>
<entry>ignored</entry>
<entry>Year ('y')</entry>
- <entry>Non-tokenizated and non-normalized 4 digit numbers</entry>
+ <entry>Non-tokenized and non-normalized 4 digit numbers</entry>
</row>
<row>
<entry>date (@attr 4=5)</entry>
<entry>ignored</entry>
<entry>Date ('d')</entry>
- <entry>Non-tokenizated and non-normalized ISO date strings</entry>
+ <entry>Non-tokenized and non-normalized ISO date strings</entry>
</row>
<row>
<entry>ignored</entry>