</section>
-
<section id="querymodel-rpn">
<title>&acro.rpn; queries and semantics</title>
<para>
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>
<entry>Extension to the &acro.bib1; attribute set.</entry>
<entry>predefined</entry>
</row>
- <!--
- <row>
- <entry>&acro.idxpath;</entry>
- <entry><literal>idxpath</literal></entry>
- <entry>Hardwired &acro.xpath; like attribute set, only available for
- indexing with the &acro.grs1; record model</entry>
- <entry>deprecated</entry>
- </row>
- -->
</tbody>
</tgroup>
</table>
<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
via ASN.1. Practically no &acro.z3950; clients supports this. Fortunately
they don't have to - &zebra; allows retrieval of this information
in other formats:
- <literal>&acro.sutrs;</literal>, <literal>&acro.xml;</literal>,
- <literal>&acro.grs1;</literal> and <literal>ASN.1</literal> Explain.
+ &acro.sutrs;, &acro.xml;,
+ &acro.grs1; and <literal>ASN.1</literal> Explain.
</para>
<para>
<section id="querymodel-bib1-nonuse">
<title>&zebra; general Bib1 Non-Use Attributes (type 2-6)</title>
-
+
<section id="querymodel-bib1-relation">
<title>Relation Attributes (type 2)</title>
</para>
</note>
</section>
-
+
<section id="querymodel-bib1-structure">
<title>Structure Attributes (type 4)</title>
<para>
The possible values of the
<literal>structure attribute (type 4)</literal> can be defined
- using the configuration file <filename>
- tab/default.idx</filename>.
+ using the configuration file <filename>tab/default.idx</filename>.
The default configuration is summarized in this table.
</para>
</tbody>
</tgroup>
</table>
-
<para>
The structure attribute values
<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>
Z> find @attr 1=Body-of-text @attr 2=102 @attr 4=105 "bach salieri teleman"
</screen>
</para>
-
+
<para>
The structure attribute value
<literal>Local number (107)</literal>
</note>
</section>
+
<section id="querymodel-bib1-truncation">
<title>Truncation Attributes (type = 5)</title>
search and scan in index <literal>type="p"</literal>.
</para>
<para>
- The <literal>Complete subfield (2)</literal> is a reminiscens
- from the happy <literal>&acro.marc;</literal>
+ The <literal>Complete subfield (2)</literal> is a reminiscent
+ from the happy &acro.marc;
binary format days. &zebra; does not support it, but maps silently
to <literal>Complete field (3)</literal>.
</para>
</para>
</note>
</section>
- </section>
-
+
</section>
+ </section>
<section id="querymodel-zebra">
<title>Extended &zebra; &acro.rpn; Features</title>
search result. It is a way for a client to name an &acro.apt; part of a
query.
</para>
- <!--
- <para>
- <screen>
- </screen>
- </para>
- -->
+
<warning>
<para>
Experimental. Do not use in production code.
</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
<emphasis>Numeric use attributes</emphasis> are mapped
to the &zebra; internal
string index according to the attribute set definition in use.
- The default attribute set is <literal>&acro.bib1;</literal>, and may be
+ The default attribute set is &acro.bib1;, and may be
omitted in the &acro.pqf; query.
</para>
Z> find @attr 1=BodyOfText serenade
Z> find @attr 1=bO-d-Y-of-tE-x-t serenade
Z> find @attr 1=1010 serenade
- Z> find @attrset &acro.bib1; @attr 1=1010 serenade
+ Z> find @attrset bib1 @attr 1=1010 serenade
Z> find @attrset bib1 @attr 1=1010 serenade
Z> find @attrset Bib1 @attr 1=1010 serenade
Z> find @attrset b-I-b-1 @attr 1=1010 serenade
ignored. The above mentioned name normalization applies.
String index names are defined in the
used indexing filter configuration files, for example in the
- <literal>&acro.grs1;</literal>
+ &acro.grs1;
<filename>*.abs</filename> configuration files, or in the
<literal>alvis</literal> filter &acro.xslt; indexing stylesheets.
</para>
</para>
<para>
- Finally, <literal>&acro.xpath;</literal> access points are only
- available using the <literal>&acro.grs1;</literal> filter for indexing.
+ Finally, &acro.xpath; access points are only
+ available using the &acro.grs1; filter for indexing.
These access point names must start with the character
<literal>'/'</literal>, they are <emphasis>not
normalized</emphasis>, but passed unaltered to the &zebra; internal
<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>
<para>
Exhaustive information can be found in the
- Section <ulink url="&url.yaz.cql2pqf;">&acro.cql; to &acro.rpn; conversion"</ulink>
+ Section <ulink url="&url.yaz.cql2pqf;">&acro.cql; to &acro.rpn; conversion</ulink>
in the &yaz; manual.
</para>
<!--
projects / idzebra-moved-to-github.git / blobdiff