<chapter id="querymodel">
- <!-- $Id: querymodel.xml,v 1.31 2007-03-21 19:36:47 adam Exp $ -->
<title>Query Model</title>
<section id="querymodel-overview">
<para>
&zebra; is born as a networking Information Retrieval engine adhering
to the international standards
- <ulink url="&url.z39.50;">&z3950;</ulink> and
- <ulink url="&url.sru;">&sru;</ulink>,
+ <ulink url="&url.z39.50;">&acro.z3950;</ulink> and
+ <ulink url="&url.sru;">&acro.sru;</ulink>,
and implement the
- type-1 Reverse Polish Notation (&rpn;) query
+ type-1 Reverse Polish Notation (&acro.rpn;) query
model defined there.
Unfortunately, this model has only defined a binary
encoded representation, which is used as transport packaging in
- the &z3950; protocol layer. This representation is not human
+ the &acro.z3950; protocol layer. This representation is not human
readable, nor defines any convenient way to specify queries.
</para>
<para>
- Since the type-1 (&rpn;)
+ Since the type-1 (&acro.rpn;)
query structure has no direct, useful string
representation, every client application needs to provide some
form of mapping from a local query notation or representation to it.
<section id="querymodel-query-languages-pqf">
- <title>Prefix Query Format (&pqf;)</title>
+ <title>Prefix Query Format (&acro.pqf;)</title>
<para>
Index Data has defined a textual representation in the
<ulink url="&url.yaz.pqf;">Prefix Query Format</ulink>, short
- <emphasis>&pqf;</emphasis>, which maps
+ <emphasis>&acro.pqf;</emphasis>, which maps
one-to-one to binary encoded
- <emphasis>type-1 &rpn;</emphasis> queries.
- &pqf; has been adopted by other
- parties developing &z3950; software, and is often referred to as
+ <emphasis>type-1 &acro.rpn;</emphasis> queries.
+ &acro.pqf; has been adopted by other
+ parties developing &acro.z3950; software, and is often referred to as
<emphasis>Prefix Query Notation</emphasis>, or in short
- &pqn;. See
+ &acro.pqn;. See
<xref linkend="querymodel-rpn"/> for further explanations and
descriptions of &zebra;'s capabilities.
</para>
</section>
<section id="querymodel-query-languages-cql">
- <title>Common Query Language (&cql;)</title>
+ <title>Common Query Language (&acro.cql;)</title>
<para>
- The query model of the type-1 &rpn;,
- expressed in &pqf;/&pqn; is natively supported.
- On the other hand, the default &sru;
+ The query model of the type-1 &acro.rpn;,
+ expressed in &acro.pqf;/&acro.pqn; is natively supported.
+ On the other hand, the default &acro.sru;
web services <emphasis>Common Query Language</emphasis>
- <ulink url="&url.cql;">&cql;</ulink> is not natively supported.
+ <ulink url="&url.cql;">&acro.cql;</ulink> is not natively supported.
</para>
<para>
- &zebra; can be configured to understand and map &cql; to &pqf;. See
+ &zebra; can be configured to understand and map &acro.cql; to &acro.pqf;. See
<xref linkend="querymodel-cql-to-pqf"/>.
</para>
</section>
<title>Operation types</title>
<para>
&zebra; supports all of the three different
- &z3950;/&sru; operations defined in the
+ &acro.z3950;/&acro.sru; operations defined in the
standards: explain, search,
and scan. A short description of the
functionality and purpose of each is quite in order here.
<section id="querymodel-operation-type-explain">
<title>Explain Operation</title>
<para>
- The <emphasis>syntax</emphasis> of &z3950;/&sru; queries is
+ The <emphasis>syntax</emphasis> of &acro.z3950;/&acro.sru; queries is
well known to any client, but the specific
<emphasis>semantics</emphasis> - taking into account a
particular servers functionalities and abilities - must be
of the general query model are supported.
</para>
<para>
- The &z3950; embeds the explain operation
+ The &acro.z3950; embeds the explain operation
by performing a
search in the magic
<literal>IR-Explain-1</literal> database;
see <xref linkend="querymodel-exp1"/>.
</para>
<para>
- In &sru;, explain is an entirely separate
- operation, which returns an ZeeRex &xml; record according to the
+ In &acro.sru;, explain is an entirely separate
+ operation, which returns an ZeeRex &acro.xml; record according to the
structure defined by the protocol.
</para>
<para>
simple free text searches to nested complex boolean queries,
targeting specific indexes, and possibly enhanced with many
query semantic specifications. Search interactions are the heart
- and soul of &z3950;/&sru; servers.
+ and soul of &acro.z3950;/&acro.sru; servers.
</para>
</section>
</section>
-
<section id="querymodel-rpn">
- <title>&rpn; queries and semantics</title>
+ <title>&acro.rpn; queries and semantics</title>
<para>
- The <ulink url="&url.yaz.pqf;">&pqf; grammar</ulink>
+ The <ulink url="&url.yaz.pqf;">&acro.pqf; grammar</ulink>
is documented in the &yaz; manual, and shall not be
- repeated here. This textual &pqf; representation
- is not transmistted to &zebra; during search, but it is in the
- client mapped to the equivalent &z3950; binary
+ repeated here. This textual &acro.pqf; representation
+ is not transmitted to &zebra; during search, but it is in the
+ client mapped to the equivalent &acro.z3950; binary
query parse tree.
</para>
<section id="querymodel-rpn-tree">
- <title>&rpn; tree structure</title>
+ <title>&acro.rpn; tree structure</title>
<para>
- The &rpn; parse tree - or the equivalent textual representation in &pqf; -
+ The &acro.rpn; parse tree - or the equivalent textual representation in &acro.pqf; -
may start with one specification of the
<emphasis>attribute set</emphasis> used. Following is a query
tree, which
- consists of <emphasis>atomic query parts (&apt;)</emphasis> or
+ consists of <emphasis>atomic query parts (&acro.apt;)</emphasis> or
<emphasis>named result sets</emphasis>, eventually
paired by <emphasis>boolean binary operators</emphasis>, and
finally <emphasis>recursively combined </emphasis> into
<thead>
<row>
<entry>Attribute set</entry>
- <entry>&pqf; notation (Short hand)</entry>
+ <entry>&acro.pqf; notation (Short hand)</entry>
<entry>Status</entry>
<entry>Notes</entry>
</row>
<entry>predefined</entry>
</row>
<row>
- <entry>&bib1;</entry>
+ <entry>&acro.bib1;</entry>
<entry><literal>bib-1</literal></entry>
- <entry>Standard &pqf; query language attribute set which defines the
- semantics of &z3950; searching. In addition, all of the
- non-use attributes (types 2-12) define the hard-wired
+ <entry>Standard &acro.pqf; query language attribute set which defines the
+ semantics of &acro.z3950; searching. In addition, all of the
+ non-use attributes (types 2-14) define the hard-wired
&zebra; internal query
processing.</entry>
<entry>default</entry>
<row>
<entry>GILS</entry>
<entry><literal>gils</literal></entry>
- <entry>Extension to the &bib1; attribute set.</entry>
+ <entry>Extension to the &acro.bib1; attribute set.</entry>
<entry>predefined</entry>
</row>
- <!--
- <row>
- <entry>&idxpath;</entry>
- <entry><literal>idxpath</literal></entry>
- <entry>Hardwired &xpath; like attribute set, only available for
- indexing with the &grs1; record model</entry>
- <entry>deprecated</entry>
- </row>
- -->
</tbody>
</tgroup>
</table>
<note>
<para>
The &zebra; internal query processing is modeled after
- the &bib1; attribute set, and the non-use
+ the &acro.bib1; attribute set, and the non-use
attributes type 2-6 are hard-wired in. It is therefore essential
to be familiar with <xref linkend="querymodel-bib1-nonuse"/>.
</para>
<emphasis>retrieval</emphasis>, taking proximity into account:
The hit set is a subset of the corresponding
AND query
- (see the <ulink url="&url.yaz.pqf;">&pqf; grammar</ulink> for
+ (see the <ulink url="&url.yaz.pqf;">&acro.pqf; grammar</ulink> for
details on the proximity operator):
<screen>
Z> find @prox 0 3 0 2 k 2 information retrieval
<section id="querymodel-atomic-queries">
- <title>Atomic queries (&apt;)</title>
+ <title>Atomic queries (&acro.apt;)</title>
<para>
Atomic queries are the query parts which work on one access point
only. These consist of <emphasis>an attribute list</emphasis>
followed by a <emphasis>single term</emphasis> or a
<emphasis>quoted term list</emphasis>, and are often called
- <emphasis>Attributes-Plus-Terms (&apt;)</emphasis> queries.
+ <emphasis>Attributes-Plus-Terms (&acro.apt;)</emphasis> queries.
</para>
<para>
- Atomic (&apt;) queries are always leaf nodes in the &pqf; query tree.
+ Atomic (&acro.apt;) queries are always leaf nodes in the &acro.pqf; query tree.
UN-supplied non-use attributes types 2-12 are either inherited from
higher nodes in the query tree, or are set to &zebra;'s default values.
See <xref linkend="querymodel-bib1"/> for details.
</para>
<table id="querymodel-atomic-queries-table" frame="top">
- <title>Atomic queries (&apt;)</title>
+ <title>Atomic queries (&acro.apt;)</title>
<tgroup cols="3">
<thead>
<row>
<para>
The <emphasis>scan</emphasis> operation is only supported with
- atomic &apt; queries, as it is bound to one access point at a
+ atomic &acro.apt; queries, as it is bound to one access point at a
time. Boolean query trees are not allowed during
<emphasis>scan</emphasis>.
</para>
<para>
Named result sets are supported in &zebra;, and result sets can be
used as operands without limitations. It follows that named
- result sets are leaf nodes in the &pqf; query tree, exactly as
- atomic &apt; queries are.
+ result sets are leaf nodes in the &acro.pqf; query tree, exactly as
+ atomic &acro.apt; queries are.
</para>
<para>
After the execution of a search, the result set is available at
<note>
<para>
- Named result sets are only supported by the &z3950; protocol.
- The &sru; web service is stateless, and therefore the notion of
+ Named result sets are only supported by the &acro.z3950; protocol.
+ The &acro.sru; web service is stateless, and therefore the notion of
named result sets does not exist when accessing a &zebra; server by
- the &sru; protocol.
+ the &acro.sru; protocol.
</para>
</note>
</section>
</para>
<para>
Finding all documents which have the term list "information
- retrieval" in an &zebra; index, using it's internal full string
+ retrieval" in an &zebra; index, using its internal full string
name. Scanning the same index.
<screen>
Z> find @attr 1=sometext "information retrieval"
</para>
<para>
Searching or scanning
- the bib-1 use attribute 54 using it's string name:
+ the bib-1 use attribute 54 using its string name:
<screen>
Z> find @attr 1=Code-language eng
Z> scan @attr 1=Code-language ""
<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 &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.
<para>
See also <xref linkend="querymodel-pqf-apt-mapping"/> for details, and
<xref linkend="zebrasrv-sru"/>
- for the &sru; &pqf; query extension using string names as a fast
+ for the &acro.sru; &acro.pqf; query extension using string names as a fast
debugging facility.
</para>
</section>
<section id="querymodel-use-xpath">
<title>&zebra;'s special access point of type 'XPath'
- for &grs1; filters</title>
+ for &acro.grs1; filters</title>
<para>
As we have seen above, it is possible (albeit seldom a great
idea) to emulate
<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 &xml; element
+ gets populated from a possible entirely different &acro.xml; element
than it pretends to access.
</para>
<para>
- When using the &grs1; Record Model
+ When using the &acro.grs1; Record Model
(see <xref linkend="grs"/>), we have the
possibility to embed <emphasis>life</emphasis>
XPath expressions
- in the &pqf; queries, which are here called
+ in the &acro.pqf; queries, which are here called
<emphasis>use (type 1)</emphasis> <emphasis>xpath</emphasis>
attributes. You must enable the
<literal>xpath enable</literal> directive in your
<para>
Only a <emphasis>very</emphasis> restricted subset of the
<ulink url="http://www.w3.org/TR/xpath">XPath 1.0</ulink>
- standard is supported as the &grs1; record model is simpler than
- a full &xml; &dom; structure. See the following examples for
+ standard is supported as the &acro.grs1; record model is simpler than
+ a full &acro.xml; &acro.dom; structure. See the following examples for
possibilities.
</para>
</note>
<para>
Finding all documents which have the term "content"
- inside a text node found in a specific &xml; &dom;
+ inside a text node found in a specific &acro.xml; &acro.dom;
<emphasis>subtree</emphasis>, whose starting element is
addressed by XPath.
<screen>
<para>
Filter the addressing XPath by a predicate working on exact
string values in
- attributes (in the &xml; sense) can be done: return all those docs which
+ attributes (in the &acro.xml; sense) can be done: return all those docs which
have the term "english" contained in one of all text sub nodes of
the subtree defined by the XPath
<literal>/record/title[@lang='en']</literal>. And similar
</screen>
</para>
<para>
- Escaping &pqf; keywords and other non-parseable XPath constructs
- with <literal>'{ }'</literal> to prevent client-side &pqf; parsing
+ Escaping &acro.pqf; keywords and other non-parseable XPath constructs
+ with <literal>'{ }'</literal> to prevent client-side &acro.pqf; parsing
syntax errors:
<screen>
Z> find @attr {1=/root/first[@attr='danish']} content
<section id="querymodel-exp1">
<title>Explain Attribute Set</title>
<para>
- The &z3950; standard defines the
+ The &acro.z3950; standard defines the
<ulink url="&url.z39.50.explain;">Explain</ulink> attribute set
Exp-1, which is used to discover information
about a server's search semantics and functional capabilities
</para>
<para>
In addition, the non-Use
- &bib1; attributes, that is, the types
+ &acro.bib1; attributes, that is, the types
<emphasis>Relation</emphasis>, <emphasis>Position</emphasis>,
<emphasis>Structure</emphasis>, <emphasis>Truncation</emphasis>,
and <emphasis>Completeness</emphasis> are imported from
- the &bib1; attribute set, and may be used
+ the &acro.bib1; attribute set, and may be used
within any explain query.
</para>
</para>
<para>
See <filename>tab/explain.att</filename> and the
- <ulink url="&url.z39.50;">&z3950;</ulink> standard
+ <ulink url="&url.z39.50;">&acro.z3950;</ulink> standard
for more information.
</para>
</section>
<title>Explain searches with yaz-client</title>
<para>
Classic Explain only defines retrieval of Explain information
- via ASN.1. Practically no &z3950; clients supports this. Fortunately
+ 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>&sutrs;</literal>, <literal>&xml;</literal>,
- <literal>&grs1;</literal> and <literal>ASN.1</literal> Explain.
+ &acro.sutrs;, &acro.xml;,
+ &acro.grs1; and <literal>ASN.1</literal> Explain.
</para>
<para>
<literal>Default</literal>.
This query is very useful to study the internal &zebra; indexes.
If records have been indexed using the <literal>alvis</literal>
- &xslt; filter, the string representation names of the known indexes can be
+ &acro.xslt; filter, the string representation names of the known indexes can be
found.
<screen>
Z> base IR-Explain-1
</section>
<section id="querymodel-bib1">
- <title>&bib1; Attribute Set</title>
+ <title>&acro.bib1; Attribute Set</title>
<para>
Most of the information contained in this section is an excerpt of
- the ATTRIBUTE SET &bib1; (&z3950;-1995) SEMANTICS
- found at <ulink url="&url.z39.50.attset.bib1.1995;">. The &bib1;
+ the ATTRIBUTE SET &acro.bib1; (&acro.z3950;-1995) SEMANTICS
+ found at <ulink url="&url.z39.50.attset.bib1.1995;">. The &acro.bib1;
Attribute Set Semantics</ulink> from 1995, also in an updated
- <ulink url="&url.z39.50.attset.bib1;">&bib1;
+ <ulink url="&url.z39.50.attset.bib1;">&acro.bib1;
Attribute Set</ulink>
version from 2003. Index Data is not the copyright holder of this
information, except for the configuration details, the listing of
<filename>tab/gils.att</filename>.
</para>
<para>
- For example, some few &bib1; use
+ For example, some few &acro.bib1; use
attributes from the <filename>tab/bib1.att</filename> are:
<screen>
att 1 Personal-name
<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>
The relation attributes 1-5 are supported and work exactly as
expected.
All ordering operations are based on a lexicographical ordering,
- <emphasis>expect</emphasis> when the
+ <emphasis>except</emphasis> when the
structure attribute numeric (109) is used. In
this case, ordering is numerical. See
<xref linkend="querymodel-bib1-structure"/>.
<emphasis>AlwaysMatches (103)</emphasis> is a
great way to discover how many documents have been indexed in a
given field. The search term is ignored, but needed for correct
- &pqf; syntax. An empty search term may be supplied.
+ &acro.pqf; syntax. An empty search term may be supplied.
<screen>
Z> find @attr 1=Title @attr 2=103 ""
Z> find @attr 1=Title @attr 2=103 @attr 4=1 ""
</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
- query language to &pqf;. For example, the following queries
+ 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=Title @attr 4=6 "mozart amadeus"
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>
</para>
<note>
<para>
- The exact mapping between &pqf; queries and &zebra; internal indexes
+ The exact mapping between &acro.pqf; queries and &zebra; internal indexes
and index types is explained in
<xref linkend="querymodel-pqf-apt-mapping"/>.
</para>
</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>&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>
<note>
<para>
- The exact mapping between &pqf; queries and &zebra; internal indexes
+ The exact mapping between &acro.pqf; queries and &zebra; internal indexes
and index types is explained in
<xref linkend="querymodel-pqf-apt-mapping"/>.
</para>
</note>
</section>
- </section>
-
+
</section>
+ </section>
<section id="querymodel-zebra">
- <title>Extended &zebra; &rpn; Features</title>
+ <title>Extended &zebra; &acro.rpn; Features</title>
<para>
The &zebra; internal query engine has been extended to specific needs
not covered by the <literal>bib-1</literal> attribute set query
<section id="querymodel-zebra-attr-search">
<title>&zebra; specific Search Extensions to all Attribute Sets</title>
<para>
- &zebra; extends the &bib1; attribute types, and these extensions are
+ &zebra; extends the &acro.bib1; attribute types, and these extensions are
recognized regardless of attribute
set used in a <literal>search</literal> operation query.
</para>
<entry>search</entry>
<entry>2.0.8</entry>
</row>
- </tbody>
<row>
<entry>Maximum number of truncated terms (truncmax)</entry>
<entry>13</entry>
<entry>search</entry>
<entry>2.0.10</entry>
</row>
+ <row>
+ <entry>
+ Specifies whether un-indexed fields should be ignored.
+ A zero value (default) throws a diagnostic when an un-indexed
+ field is specified. A non-zero value makes it return 0 hits.
+ </entry>
+ <entry>14</entry>
+ <entry>search</entry>
+ <entry>2.0.16</entry>
+ </row>
+ </tbody>
</tgroup>
</table>
<para>
All ordering operations are based on a lexicographical ordering,
- <emphasis>expect</emphasis> when the
+ <emphasis>except</emphasis> when the
<literal>structure attribute numeric (109)</literal> is used. In
this case, ordering is numerical. See
<xref linkend="querymodel-bib1-structure"/>.
The possible values after attribute <literal>type 7</literal> are
<literal>1</literal> ascending and
<literal>2</literal> descending.
- The attributes+term (&apt;) node is separate from the
+ The attributes+term (&acro.apt;) node is separate from the
rest and must be <literal>@or</literal>'ed.
- The term associated with &apt; is the sorting level in integers,
+ The term associated with &acro.apt; is the sorting level in integers,
where <literal>0</literal> means primary sort,
<literal>1</literal> means secondary sort, and so forth.
See also <xref linkend="administration-ranking"/>.
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
- the named term set are returned as &sutrs; records.
+ the named term set are returned as &acro.sutrs; records.
</para>
<para>
For example, searching for u in title, right truncated, and
<title>&zebra; Extension Rank Weight Attribute (type 9)</title>
<para>
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.
+ that one &acro.apt; has one value - while another as a different one.
See also <xref linkend="administration-ranking"/>.
</para>
<para>
&zebra; supports the searchResult-1 facility.
If the Term Reference Attribute (type 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
+ 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.
<title>Local Approximative Limit Attribute (type 11)</title>
<para>
&zebra; computes - unless otherwise configured -
- the exact hit count for every &apt;
+ the exact hit count for every &acro.apt;
(leaf) in the query tree. These hit counts are returned as part of
- the searchResult-1 facility in the binary encoded &z3950; search
+ the searchResult-1 facility in the binary encoded &acro.z3950; search
response packages.
</para>
<para>
- By setting an estimation limit size of the resultset of the &apt;
- leaves, &zebra; stoppes processing the result set when the limit
+ By setting an estimation limit size of the resultset of the &acro.apt;
+ 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
</para>
<para>
The attribute (12) can occur anywhere in the query tree.
- Unlike regular attributes it does not relate to the leaf (&apt;)
+ Unlike regular attributes it does not relate to the leaf (&acro.apt;)
- but to the whole query.
</para>
<warning>
</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>
</section>
<section id="querymodel-idxpath">
- <title>&zebra; special &idxpath; Attribute Set for &grs1; indexing</title>
+ <title>&zebra; special &acro.idxpath; Attribute Set for &acro.grs1; indexing</title>
<para>
The attribute-set <literal>idxpath</literal> consists of a single
Use (type 1) attribute. All non-use attributes behave as normal.
</para>
<para>
This feature is enabled when defining the
- <literal>xpath enable</literal> option in the &grs1; filter
+ <literal>xpath enable</literal> option in the &acro.grs1; filter
<filename>*.abs</filename> configuration files. If one wants to use
the special <literal>idxpath</literal> numeric attribute set, the
main &zebra; configuration file <filename>zebra.cfg</filename>
</warning>
<section id="querymodel-idxpath-use">
- <title>&idxpath; Use Attributes (type = 1)</title>
+ <title>&acro.idxpath; Use Attributes (type = 1)</title>
<para>
- This attribute set allows one to search &grs1; filter indexed
- records by &xpath; like structured index names.
+ This attribute set allows one to search &acro.grs1; filter indexed
+ records by &acro.xpath; like structured index names.
</para>
<warning>
</warning>
<table id="querymodel-idxpath-use-table" frame="top">
- <title>&zebra; specific &idxpath; Use Attributes (type 1)</title>
+ <title>&zebra; specific &acro.idxpath; Use Attributes (type 1)</title>
<tgroup cols="4">
<thead>
<row>
- <entry>&idxpath;</entry>
+ <entry>&acro.idxpath;</entry>
<entry>Value</entry>
<entry>String Index</entry>
<entry>Notes</entry>
</thead>
<tbody>
<row>
- <entry>&xpath; Begin</entry>
+ <entry>&acro.xpath; Begin</entry>
<entry>1</entry>
<entry>_XPATH_BEGIN</entry>
<entry>deprecated</entry>
</row>
<row>
- <entry>&xpath; End</entry>
+ <entry>&acro.xpath; End</entry>
<entry>2</entry>
<entry>_XPATH_END</entry>
<entry>deprecated</entry>
</row>
<row>
- <entry>&xpath; CData</entry>
+ <entry>&acro.xpath; CData</entry>
<entry>1016</entry>
<entry>_XPATH_CDATA</entry>
<entry>deprecated</entry>
</row>
<row>
- <entry>&xpath; Attribute Name</entry>
+ <entry>&acro.xpath; Attribute Name</entry>
<entry>3</entry>
<entry>_XPATH_ATTR_NAME</entry>
<entry>deprecated</entry>
</row>
<row>
- <entry>&xpath; Attribute CData</entry>
+ <entry>&acro.xpath; Attribute CData</entry>
<entry>1015</entry>
<entry>_XPATH_ATTR_CDATA</entry>
<entry>deprecated</entry>
</screen>
</para>
<para>
- Search for all documents where specific nested &xpath;
+ Search for all documents where specific nested &acro.xpath;
<literal>/c1/c2/../cn</literal> exists. Notice the very
counter-intuitive <emphasis>reverse</emphasis> notation!
<screen>
</screen>
</para>
<para>
- Search for all documents with have an &xml; element node
- including an &xml; attribute named <emphasis>creator</emphasis>
+ Search for all documents with have an &acro.xml; element node
+ including an &acro.xml; attribute named <emphasis>creator</emphasis>
<screen>
Z> find @attrset idxpath @attr 1=3 @attr 4=3 creator
Z> find @attr 1=_XPATH_ATTR_NAME @attr 4=3 creator
<section id="querymodel-pqf-apt-mapping">
- <title>Mapping from &pqf; atomic &apt; queries to &zebra; internal
+ <title>Mapping from &acro.pqf; atomic &acro.apt; queries to &zebra; internal
register indexes</title>
<para>
- The rules for &pqf; &apt; mapping are rather tricky to grasp in the
+ The rules for &acro.pqf; &acro.apt; mapping are rather tricky to grasp in the
first place. We deal first with the rules for deciding which
internal register or string index to use, according to the use
attribute or access point specified in the query. Thereafter we
</para>
<section id="querymodel-pqf-apt-mapping-accesspoint">
- <title>Mapping of &pqf; &apt; access points</title>
+ <title>Mapping of &acro.pqf; &acro.apt; access points</title>
<para>
&zebra; understands four fundamental different types of access
points, of which only the
<emphasis>numeric use attribute</emphasis> type access points
- are defined by the <ulink url="&url.z39.50;">&z3950;</ulink>
+ are defined by the <ulink url="&url.z39.50;">&acro.z3950;</ulink>
standard.
All other access point types are &zebra; specific, and non-portable.
</para>
<entry>hardwired internal string index name</entry>
</row>
<row>
- <entry>&xpath; special index</entry>
+ <entry>&acro.xpath; special index</entry>
<entry>XPath</entry>
<entry>/.*</entry>
- <entry>special xpath search for &grs1; indexed records</entry>
+ <entry>special xpath search for &acro.grs1; indexed records</entry>
</row>
</tbody>
</tgroup>
<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>&bib1;</literal>, and may be
- omitted in the &pqf; query.
+ The default attribute set is &acro.bib1;, and may be
+ omitted in the &acro.pqf; query.
</para>
<para>
According to normalization and numeric
use attribute mapping, it follows that the following
- &pqf; queries are considered equivalent (assuming the default
+ &acro.pqf; queries are considered equivalent (assuming the default
configuration has not been altered):
<screen>
Z> find @attr 1=Body-of-text serenade
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 &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
fields as specified in the <literal>.abs</literal> file which
describes the profile of the records which have been loaded.
If no use attribute is provided, a default of
- &bib1; Use Any (1016) is assumed.
+ &acro.bib1; Use Any (1016) is assumed.
The predefined use attribute sets
can be reconfigured by tweaking the configuration files
<filename>tab/*.att</filename>, and
ignored. The above mentioned name normalization applies.
String index names are defined in the
used indexing filter configuration files, for example in the
- <literal>&grs1;</literal>
+ &acro.grs1;
<filename>*.abs</filename> configuration files, or in the
- <literal>alvis</literal> filter &xslt; indexing stylesheets.
+ <literal>alvis</literal> filter &acro.xslt; indexing stylesheets.
</para>
<para>
</para>
<para>
- Finally, <literal>&xpath;</literal> access points are only
- available using the <literal>&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
- &xpath; engine. See <xref linkend="querymodel-use-xpath"/>.
+ &acro.xpath; engine. See <xref linkend="querymodel-use-xpath"/>.
</para>
<section id="querymodel-pqf-apt-mapping-structuretype">
- <title>Mapping of &pqf; &apt; structure and completeness to
+ <title>Mapping of &acro.pqf; &acro.apt; structure and completeness to
register type</title>
<para>
- Internally &zebra; has in it's default configuration several
+ Internally &zebra; has in its default configuration several
different types of registers or indexes, whose tokenization and
character normalization rules differ. This reflects the fact that
searching fundamental different tokens like dates, numbers,
<row>
<entry>numeric (@attr 4=109)</entry>
<entry>ignored</entry>
- <entry>Numeric ('u')</entry>
+ <entry>Numeric ('n')</entry>
<entry>Special index for digital numbers</entry>
</row>
<row>
<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>
against the contents of the phrase (long word) register, if one
exists for the given <emphasis>Use</emphasis> attribute.
A phrase register is created for those fields in the
- &grs1; <filename>*.abs</filename> file that contains a
+ &acro.grs1; <filename>*.abs</filename> file that contains a
<literal>p</literal>-specifier.
<screen>
Z> scan @attr 1=Title @attr 4=1 @attr 6=3 beethoven
contains multiple words, the term will only match if all of the words
are found immediately adjacent, and in the given order.
The word search is performed on those fields that are indexed as
- type <literal>w</literal> in the &grs1; <filename>*.abs</filename> file.
+ type <literal>w</literal> in the &acro.grs1; <filename>*.abs</filename> file.
<screen>
Z> scan @attr 1=Title @attr 4=1 @attr 6=1 beethoven
...
natural-language, relevance-ranked query.
This search type uses the word register, i.e. those fields
that are indexed as type <literal>w</literal> in the
- &grs1; <filename>*.abs</filename> file.
+ &acro.grs1; <filename>*.abs</filename> file.
</para>
<para>
If the <emphasis>Structure</emphasis> attribute is
<emphasis>Numeric String</emphasis> the term is treated as an integer.
The search is performed on those fields that are indexed
- as type <literal>n</literal> in the &grs1;
+ as type <literal>n</literal> in the &acro.grs1;
<filename>*.abs</filename> file.
</para>
<section id="querymodel-cql-to-pqf">
- <title>Server Side &cql; to &pqf; Query Translation</title>
+ <title>Server Side &acro.cql; to &acro.pqf; Query Translation</title>
<para>
Using the
<literal><cql2rpn>l2rpn.txt</cql2rpn></literal>
&yaz; Frontend Virtual
Hosts option, one can configure
- the &yaz; Frontend &cql;-to-&pqf;
+ the &yaz; Frontend &acro.cql;-to-&acro.pqf;
converter, specifying the interpretation of various
- <ulink url="&url.cql;">&cql;</ulink>
+ <ulink url="&url.cql;">&acro.cql;</ulink>
indexes, relations, etc. in terms of Type-1 query attributes.
<!-- The yaz-client config file -->
</para>
<para>
- For example, using server-side &cql;-to-&pqf; conversion, one might
+ For example, using server-side &acro.cql;-to-&acro.pqf; conversion, one might
query a zebra server like this:
<screen>
<![CDATA[
]]>
</screen>
and - if properly configured - even static relevance ranking can
- be performed using &cql; query syntax:
+ be performed using &acro.cql; query syntax:
<screen>
<
projects / idzebra-moved-to-github.git / blobdiff