-<chapter id="querymodel">
- <!-- $Id: querymodel.xml,v 1.2 2006-06-13 13:45:08 marc Exp $ -->
- <title>Query Model</title>
-
+ <chapter id="querymodel">
+ <!-- $Id: querymodel.xml,v 1.16 2006-06-25 21:54:03 marc Exp $ -->
+ <title>Query Model</title>
+
<sect1 id="querymodel-overview">
- <title>Query Model Overview</title>
+ <title>Query Model Overview</title>
+
+ <sect2 id="querymodel-query-languages">
+ <title>Query Languages</title>
+
+ <para>
+ Zebra is born as a networking Information Retrieval engine adhering
+ to the international standards
+ <ulink url="&url.z39.50;">Z39.50</ulink> and
+ <ulink url="&url.sru;">SRU</ulink>,
+ and implement the
+ <literal>type-1 Reverse Polish Notation (RPN)</literal> query
+ model defined there.
+ Unfortunately, this model has only defined a binary
+ encoded representation, which is used as transport packaging in
+ the Z39.50 protocol layer. This representation is not human
+ readable, nor defines any convenient way to specify queries.
+ </para>
+ <para>
+ Since the <literal>type-1 (RPN)</literal>
+ query structure has no direct, useful string
+ representation, every origin application needs to provide some
+ form of mapping from a local query notation or representation to it.
+ </para>
- <para>
- Zebra is born as a networking Information Retrieval engine adhering
- to the international standards
- <ulink url="&url.z39.50;">Z39.50</ulink> and
- <ulink url="&url.sru;">SRU</ulink>,
- and implement the query model defined there.
- Unfortunately, the Z39.50 query model has only defined a binary
- encoded representation, which is used as transport packaging in
- the Z39.50 protocol layer. This representation is not human
- readable, nor defines any convenient way to specify queries.
- </para>
- <para>
- Therefore, Index Data has defined a textual representaion in the
- <literal>Prefix Query Format</literal>, short
- <literal>PQF</literal>, which then has been adopted by other
- parties developing Z39.50 software. It is also often referred to as
- <literal>Prefix Query Notation</literal>, or in short
- <literal>PQN</literal>, and is thoroughly explained in
- <xref linkend="querymodel-pqf"/>.
- </para>
+
+ <sect3 id="querymodel-query-languages-pqf">
+ <title>Prefix Query Format (PQF)</title>
<para>
- In addition, Zebra can be configured to understand and map the
- <literal>Common Query Language</literal>
- (<ulink url="&url.cql;">CQL</ulink>)
- to PQF. See an introduction on the mapping to the internal query
- representation in
- <xref linkend="querymodel-cql-to-pqf"/>.
- </para>
- </sect1>
+ Index Data has defined a textual representation in the
+ <literal>Prefix Query Format</literal>, short
+ <literal>PQF</literal>, which maps
+ <literal>one-to-one</literal> to binary encoded
+ <literal>type-1 RPN</literal> query packages.
+ It has been adopted by other
+ parties developing Z39.50 software, and is often referred to as
+ <literal>Prefix Query Notation</literal>, or in short
+ <literal>PQN</literal>. See
+ <xref linkend="querymodel-pqf"/> for further explanations and
+ descriptions of Zebra's capabilities.
+ </para>
+ </sect3>
+
+ <sect3 id="querymodel-query-languages-cql">
+ <title>Common Query Language (CQL)</title>
+ <para>
+ The query model of the <literal>type-1 RPN</literal>,
+ expressed in <literal>PQF/PQN</literal> is natively supported.
+ On the other hand, the default <literal>SRU</literal>
+ webservices <literal>Common Query Language</literal>
+ <ulink url="&url.cql;">CQL</ulink> is not natively supported.
+ </para>
+ <para>
+ Zebra can be configured to understand and map CQL to PQF. See
+ <xref linkend="querymodel-cql-to-pqf"/>.
+ </para>
+ </sect3>
+
+ </sect2>
+
+ <sect2 id="querymodel-operation-types">
+ <title>Operation types</title>
+ <para>
+ Zebra supports all of the three different
+ <literal>Z39.50/SRU</literal> operations defined in the
+ standards: <literal>explain</literal>, <literal>search</literal>,
+ and <literal>scan</literal>. A short description of the
+ functionality and purpose of each is quite in order here.
+ </para>
+
+ <sect3 id="querymodel-operation-type-explain">
+ <title>Explain Operation</title>
+ <para>
+ The <emphasis>syntax</emphasis> of Z39.50/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
+ discovered from case to case. Enters the
+ <literal>explain</literal> operation, which provides the means
+ for learning which
+ <emphasis>fields</emphasis> (also called
+ <emphasis>indexes</emphasis> or <emphasis>access points</emphasis>
+ are provided, which default parameter the server uses, which
+ retrieve document formats are defined, and which specific parts
+ of the general query model are supported.
+ </para>
+ <para>
+ The Z39.50 embeds the <literal>explain</literal> operation
+ by performing a
+ <literal>search</literal> in the magic
+ <literal>IR-Explain-1</literal> database;
+ see <xref linkend="querymodel-exp1"/>.
+ </para>
+ <para>
+ In SRU, <literal>explain</literal> is an entirely separate
+ operation, which returns an <literal>ZeeRex
+ XML</literal> record according to the
+ structure defined by the protocol.
+ </para>
+ <para>
+ In both cases, the information gathered through
+ <literal>explain</literal> operations can be used to
+ auto-configure a client user interface to the servers
+ capabilities.
+ </para>
+ </sect3>
+
+ <sect3 id="querymodel-operation-type-search">
+ <title>Search Operation</title>
+ <para>
+ Search and retrieve interactions are the raison d'être.
+ They are used to query the remote database and
+ return search result documents. Search queries span from
+ 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 Z39.50/SRU servers.
+ </para>
+ </sect3>
+
+ <sect3 id="querymodel-operation-type-scan">
+ <title>Scan Operation</title>
+ <para>
+ The <literal>scan</literal> operation is a helper functionality,
+ which operates on one index or access point a time.
+ </para>
+ <para>
+ It provides
+ the means to investigate the content of specific indexes.
+ Scanning an index returns a handful of terms actually fond in
+ the indexes, and in addition the <literal>scan</literal>
+ operation returns the number of documents indexed by each term.
+ A search client can use this information to propose proper
+ spelling of search terms, to auto-fill search boxes, or to
+ display controlled vocabularies.
+ </para>
+ </sect3>
+
+ </sect2>
+ </sect1>
+
+
<sect1 id="querymodel-pqf">
- <title>Prefix Query Format structure and syntax</title>
+ <title>Prefix Query Format syntax and semantics</title>
<para>
- The
- <ulink url="&url.yaz.pqf;">PQF
- grammer</ulink> is documented in the YAZ manual, and shall not be
- repeated here.
- This textual PQF representation
+ The <ulink url="&url.yaz.pqf;">PQF grammer</ulink>
+ is documented in the YAZ manual, and shall not be
+ repeated here. This textual PQF representation
is always during search mapped to the equivalent Zebra internal
query parse tree.
</para>
-
+
<sect2 id="querymodel-pqf-tree">
<title>PQF tree structure</title>
- <para>
- The PQF parse tree - or the equivalent textual representation -
- may start with one specification of the
- <emphasis>attribute set</emphasis> used. Following is a query
- tree, which
- consists of <emphasis>atomic query parts</emphasis>, eventually
- paired by <emphasis>boolean binary operators</emphasis>, and
- finally <emphasis>recursively combined </emphasis> into
- complex query trees.
- </para>
-
- <sect3 id="querymodel-attribute-sets">
- <title>Attribute sets</title>
<para>
+ The PQF parse tree - or the equivalent textual representation -
+ 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
+ <emphasis>named result sets</emphasis>, eventually
+ paired by <emphasis>boolean binary operators</emphasis>, and
+ finally <emphasis>recursively combined </emphasis> into
+ complex query trees.
+ </para>
+
+ <sect3 id="querymodel-attribute-sets">
+ <title>Attribute sets</title>
+ <para>
Attribute sets define the exact meaning and semantics of queries
issued. Zebra comes with some predefined attribute set
definitions, others can easily be defined and added to the
configuration.
- <note>
- The Zebra internal query procesing is modeled after
- the <literal>Bib1</literal> attribute set, and the non-use
- attributes type 2-9 are hard-wired in. It is therefore essential
- to be familiar with <xref linkend="querymodel-bib1"/>.
- </note>
- </para>
+ </para>
- <table id="querymodel-attribute-sets-table">
- <caption>Attribute sets predefined in Zebra</caption>
- <!--
- <thead>
- <tr><td>one</td><td>two</td></tr>
- </thead>
- -->
- <tbody>
- <tr>
- <td><emphasis>exp-1</emphasis></td>
- <td><literal>Explain</literal> attribute set</td>
- <td>Special attribute set used on the special automagic
- <literal>IR-Explain-1</literal> database to gain information on
- server capabilities, database names, and database
- and semantics.</td>
- </tr>
- <tr>
- <td><emphasis>bib-1</emphasis></td>
- <td><literal>Bib1</literal> attribute set</td>
- <td>Standard PQF query language attribute set which defines the
- semantics of Z39.50 searching. In addition, all of the
- non-use attributes (type 2-9) define the Zebra internal query
- processing</td>
- </tr>
- <tr>
- <td><emphasis>gils</emphasis></td>
- <td><literal>GILS</literal> attribute set</td>
- <td>Extention to the <literal>Bib1</literal> attribute set.</td>
- </tr>
- </tbody>
- </table>
- </sect3>
+
+ <table id="querymodel-attribute-sets-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Attribute sets predefined in Zebra</caption>
+
+ <thead>
+ <tr>
+ <td>Attribute set</td>
+ <td>Short hand</td>
+ <td>Status</td>
+ <td>Notes</td>
+ </tr>
+ </thead>
+
+ <tbody>
+ <tr>
+ <td><literal>Explain</literal></td>
+ <td><literal>exp-1</literal></td>
+ <td>Special attribute set used on the special automagic
+ <literal>IR-Explain-1</literal> database to gain information on
+ server capabilities, database names, and database
+ and semantics.</td>
+ <td>predefined</td>
+ </tr>
+ <tr>
+ <td><literal>Bib1</literal></td>
+ <td><literal>bib-1</literal></td>
+ <td>Standard PQF query language attribute set which defines the
+ semantics of Z39.50 searching. In addition, all of the
+ non-use attributes (type 2-9) define the hard-wired
+ Zebra internal query
+ processing.</td>
+ <td>default</td>
+ </tr>
+ <tr>
+ <td><literal>GILS</literal></td>
+ <td><literal>gils</literal></td>
+ <td>Extension to the <literal>Bib1</literal> attribute set.</td>
+ <td>predefined</td>
+ </tr>
+ <!--
+ <tr>
+ <td><literal>IDXPATH</literal></td>
+ <td><literal>idxpath</literal></td>
+ <td>Hardwired XPATH like attribute set, only available for
+ indexing with the GRS record model</td>
+ <td>depreciated</td>
+ </tr>
+ -->
+ </tbody>
+ </table>
+ </sect3>
- <sect3 id="querymodel-boolean-operators">
- <title>Boolean operators</title>
<para>
- A pair of subquery trees, or of atomic queries, is combined
- using the standard boolean operators into new query trees.
+ The <literal>use attributes (type 1)</literal> mappings the
+ predefined attribute sets are found in the
+ attribute set configuration files <filename>tab/*.att</filename>.
</para>
- <table id="querymodel-boolean-operators-table">
- <caption>Boolean operators</caption>
- <!--
- <thead>
- <tr><td>one</td><td>two</td></tr>
- </thead>
- -->
- <tbody>
- <tr><td><emphasis>@and</emphasis></td>
- <td>binary <literal>AND</literal> operator</td>
- <td>Set intersection of two atomic queries hit sets</td>
- </tr>
- <tr><td><emphasis>@or</emphasis></td>
- <td>binary <literal>OR</literal> operator</td>
- <td>Set union of two atomic queries hit sets</td>
- </tr>
- <tr><td><emphasis>@not</emphasis></td>
- <td>binary <literal>AND NOT</literal> operator</td>
- <td>Set complement of two atomic queries hit sets</td>
- </tr>
- <tr><td><emphasis>@prox</emphasis></td>
- <td>binary <literal>PROXIMY</literal> operator</td>
- <td>Set intersection of two atomic queries hit sets. In
- addition, the intersection set is purged for all
- documents which do not satisfy the requested query
- term proximity. Usually a proper subset of the AND
- operation.</td>
- </tr>
- </tbody>
- </table>
+ <note>
+ The Zebra internal query processing is modeled after
+ the <literal>Bib1</literal> 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"/>.
+ </note>
- <para>
+
+ <sect3 id="querymodel-boolean-operators">
+ <title>Boolean operators</title>
+ <para>
+ A pair of subquery trees, or of atomic queries, is combined
+ using the standard boolean operators into new query trees.
+ Thus, boolean operators are always internal nodes in the query tree.
+ </para>
+
+ <table id="querymodel-boolean-operators-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Boolean operators</caption>
+ <thead>
+ <tr>
+ <td>Keyword</td>
+ <td>Operator</td>
+ <td>Description</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr><td><literal>@and</literal></td>
+ <td>binary <literal>AND</literal> operator</td>
+ <td>Set intersection of two atomic queries hit sets</td>
+ </tr>
+ <tr><td><literal>@or</literal></td>
+ <td>binary <literal>OR</literal> operator</td>
+ <td>Set union of two atomic queries hit sets</td>
+ </tr>
+ <tr><td><literal>@not</literal></td>
+ <td>binary <literal>AND NOT</literal> operator</td>
+ <td>Set complement of two atomic queries hit sets</td>
+ </tr>
+ <tr><td><literal>@prox</literal></td>
+ <td>binary <literal>PROXIMY</literal> operator</td>
+ <td>Set intersection of two atomic queries hit sets. In
+ addition, the intersection set is purged for all
+ documents which do not satisfy the requested query
+ term proximity. Usually a proper subset of the AND
+ operation.</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <para>
For example, we can combine the terms
<emphasis>information</emphasis> and <emphasis>retrieval</emphasis>
into different searches in the default index of the default
Querying for the union of all documents containing the
terms <emphasis>information</emphasis> OR
<emphasis>retrieval</emphasis>:
- <screen>
- @or information retrieval
- </screen>
- </para>
- <para>
+ <screen>
+ Z> find @or information retrieval
+ </screen>
+ </para>
+ <para>
Querying for the intersection of all documents containing the
terms <emphasis>information</emphasis> AND
<emphasis>retrieval</emphasis>:
- The hit set is a subset of the coresponding
+ The hit set is a subset of the corresponding
OR query.
- <screen>
- @and information retrieval
- </screen>
- </para>
- <para>
+ <screen>
+ Z> find @and information retrieval
+ </screen>
+ </para>
+ <para>
Querying for the intersection of all documents containing the
terms <emphasis>information</emphasis> AND
<emphasis>retrieval</emphasis>, taking proximity into account:
- The hit set is a subset of the coresponding
- AND query.
- <screen>
- @prox information retrieval
- </screen>
- </para>
- <para>
+ The hit set is a subset of the corresponding
+ AND query
+ (see the <ulink url="&url.yaz.pqf;">PQF grammar</ulink> for
+ details on the proximity operator):
+ <screen>
+ Z> find @prox 0 3 0 2 k 2 information retrieval
+ </screen>
+ </para>
+ <para>
Querying for the intersection of all documents containing the
terms <emphasis>information</emphasis> AND
<emphasis>retrieval</emphasis>, in the same order and near each
- other as described in the term list
- The hit set is a subset of the coresponding
+ other as described in the term list.
+ The hit set is a subset of the corresponding
PROXIMY query.
- <screen>
- "information retrieval"
- </screen>
- </para>
- </sect3>
-
-
- <sect3 id="querymodel-atomic-queries">
- <title>Atomic queries</title>
- <para>
- Atomic queries are the query parts which work on one acess point
+ <screen>
+ Z> find "information retrieval"
+ </screen>
+ </para>
+ </sect3>
+
+
+ <sect3 id="querymodel-atomic-queries">
+ <title>Atomic queries (APT)</title>
+ <para>
+ Atomic queries are the query parts which work on one access point
only. These consist of <literal>an attribute list</literal>
followed by a <literal>single term</literal> or a
- <literal>quoted term list</literal>.
- </para>
- <para>
+ <literal>quoted term list</literal>, and are often called
+ <emphasis>Attributes-Plus-Terms (APT)</emphasis> queries.
+ </para>
+ <para>
+ Atomic (APT) queries are always leaf nodes in the PQF query tree.
Unsupplied non-use attributes type 2-9 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">
- <caption>Atomic queries</caption>
- <!--
- <thead>
- <tr><td>one</td><td>two</td></tr>
- </thead>
- -->
- <tbody>
- <tr><td><emphasis>attribute list</emphasis></td>
- <td>List of <literal>orthogonal</literal> attributes</td>
- <td>Any of the orthogonal attribute types may be omitted,
+ </para>
+
+ <table id="querymodel-atomic-queries-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Atomic queries (APT)</caption>
+ <thead>
+ <tr>
+ <td>Name</td>
+ <td>Type</td>
+ <td>Notes</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><emphasis>attribute list</emphasis></td>
+ <td>List of <literal>orthogonal</literal> attributes</td>
+ <td>Any of the orthogonal attribute types may be omitted,
these are inherited from higher query tree nodes, or if not
inherited, are set to the default Zebra configuration values.
- </td>
- </tr>
- <tr><td><emphasis>term</emphasis></td>
- <td>single <literal>term</literal>
- or <literal>quoted term list</literal> </td>
- <td>Here the search terms or list of search terms is added
+ </td>
+ </tr>
+ <tr>
+ <td><emphasis>term</emphasis></td>
+ <td>single <literal>term</literal>
+ or <literal>quoted term list</literal> </td>
+ <td>Here the search terms or list of search terms is added
to the query</td>
- </tr>
- </tbody>
- </table>
- <para>
+ </tr>
+ </tbody>
+ </table>
+ <para>
Querying for the term <emphasis>information</emphasis> in the
- default index using the default attribite set, the server choice
+ default index using the default attribute set, the server choice
of access point/index, and the default non-use attributes.
- <screen>
- "information"
- </screen>
- </para>
- <para>
- Equivalent query fully specified:
<screen>
- @attrset bib-1 @attr 1=1017 @attr 2=3 @attr 3=3 @attr 4=1 @attr 5=100 @attr 6=1 "information"
+ Z> find information
</screen>
- </para>
+ </para>
+ <para>
+ Equivalent query fully specified including all default values:
+ <screen>
+ Z> find @attrset bib-1 @attr 1=1017 @attr 2=3 @attr 3=3 @attr 4=1 @attr 5=100 @attr 6=1 information
+ </screen>
+ </para>
- <para>
- Finding all documents which have empty titles. Notice that the
- empty term must be quoted, but is otherwise legal.
+ <para>
+ Finding all documents which have the term
+ <emphasis>debussy</emphasis> in the title field.
<screen>
- @attr 1=4 ""
+ Z> find @attr 1=4 debussy
</screen>
- </para>
+ </para>
+
+ <para>
+ The <literal>scan</literal> operation is only supported with
+ atomic APT queries, as it is bound to one access point at a
+ time. Boolean query trees are not allowed during
+ <literal>scan</literal>.
+ </para>
+
+ <para>
+ For example, we migh want to scan the title index, starting with
+ the term
+ <emphasis>debussy</emphasis>, and displaying this and the
+ following terms in lexicographic order:
+ <screen>
+ Z> scan @attr 1=4 debussy
+ </screen>
+ </para>
+ </sect3>
+
+
+ <sect3 id="querymodel-resultset">
+ <title>Named Result Sets</title>
+ <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.
+ </para>
+ <para>
+ After the execution of a search, the result set is available at
+ the server, such that the client can use it for subsequent
+ searches or retrieval requests. The Z30.50 standard actually
+ stresses the fact that result sets are volatile. It may cease
+ to exist at any time point after search, and the server will
+ send a diagnostic to the effect that the requested
+ result set does not exist any more.
+ </para>
+
+ <para>
+ Defining a named result set and re-using it in the next query,
+ using <literal>yaz-client</literal>.
+ <screen>
+ Z> f @attr 1=4 mozart
+ ...
+ Number of hits: 43, setno 1
+ ...
+ Z> f @and @set 1 @attr 1=4 amadeus
+ ...
+ Number of hits: 14, setno 2
+ ...
+ Z> f @attr 1=1016 beethoven
+ ...
+ Number of hits: 26, setno 3
+ ...
+ </screen>
+ </para>
+
+ <note>
+ Named result sets are only supported by the Z39.50 protocol.
+ The 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.
+ </note>
+ </sect3>
- </sect3>
<sect3 id="querymodel-use-string">
- <title>Zebra's special use attribute of type 'string'</title>
+ <title>Zebra's special access point of type 'string'</title>
<para>
The numeric <literal>use (type 1)</literal> attribute is usually
- refered to from a given
+ referred to from a given
attribute set. In addition, Zebra let you use
<emphasis>any internal index
- name defined in your configuration</emphasis>
- as use atribute value. This is a great feature for
+ name defined in your configuration</emphasis>
+ as use attribute value. This is a great feature for
debugging, and when you do
- not need the complecity of defined use attribute values. It is
+ not need the complexity of defined use attribute values. It is
the preferred way of accessing Zebra indexes directly.
</para>
<para>
Finding all documents which have the term list "information
- retrieval" in an Zebra index, using it's internal full string name.
+ retrieval" in an Zebra index, using it's internal full string
+ name. Scanning the same index.
<screen>
- @attr 1=sometext "information retrieval"
+ Z> find @attr 1=sometext "information retrieval"
+ Z> scan @attr 1=sometext aterm
</screen>
- </para>
+ </para>
<para>
- Searching the bib-1 use attribute 54 using it's string name:
+ Searching or scanning
+ the bib-1 use attribute 54 using it's string name:
<screen>
- @attr 1=Code-language eng
+ Z> find @attr 1=Code-language eng
+ Z> scan @attr 1=Code-language ""
</screen>
- </para>
+ </para>
<para>
- Searching in any silly string index - if it's defined in your
+ 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.
This is definitely not the recommended use of
this facility, as it might confuse your users with some very
unexpected results.
<screen>
- @attr 1=silly/xpath/alike[@index]/name "information retrieval"
+ Z> find @attr 1=silly/xpath/alike[@index]/name "information retrieval"
</screen>
- </para>
- <para>
- See <xref linkend="querymodel-bib1-mapping"/> for details, and
- <xref linkend="server-sru"/>
- for the SRU PQF query extention using string names as a fast
- debugging facility.
- </para>
- </sect3>
+ </para>
+ <para>
+ See also <xref linkend="querymodel-pqf-apt-mapping"/> for details, and
+ <xref linkend="server-sru"/>
+ for the SRU PQF query extension using string names as a fast
+ debugging facility.
+ </para>
+ </sect3>
+
+ <sect3 id="querymodel-use-xpath">
+ <title>Zebra's special access point of type 'XPath'
+ for GRS filters</title>
+ <para>
+ As we have seen above, it is possible (albeit seldom a great
+ idea) to emulate
+ <ulink url="http://www.w3.org/TR/xpath">XPath 1.0</ulink> based
+ search by defining <literal>use (type 1)</literal>
+ <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
+ 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
+ than it pretends to access.
+ </para>
+ <para>
+ When using the <literal>GRS Record Model</literal>
+ (see <xref linkend="record-model-grs"/>), we have the
+ possibility to embed <emphasis>life</emphasis>
+ XPath expressions
+ in the PQF queries, which are here called
+ <literal>use (type 1)</literal> <emphasis>xpath</emphasis>
+ attributes. You must enable the
+ <literal>xpath enable</literal> directive in your
+ <literal>.abs</literal> configuration files.
+ </para>
+ <note>
+ 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 GRS record model is simpler than
+ a full XML DOM structure. See the following examples for
+ possibilities.
+ </note>
+ <para>
+ Finding all documents which have the term "content"
+ inside a text node found in a specific XML DOM
+ <emphasis>subtree</emphasis>, whose starting element is
+ addressed by XPath.
+ <screen>
+ Z> find @attr 1=/root content
+ Z> find @attr 1=/root/first content
+ </screen>
+ <emphasis>Notice that the
+ XPath must be absolute, i.e., must start with '/', and that the
+ XPath <literal>descendant-or-self</literal> axis followed by a
+ text node selection <literal>text()</literal> is implicitly
+ appended to the stated XPath.
+ </emphasis>
+ It follows that the above searches are interpreted as:
+ <screen>
+ Z> find @attr 1=/root//text() content
+ Z> find @attr 1=/root/first//text() content
+ </screen>
+ </para>
+
+ <para>
+ Searching inside attribute strings is possible:
+ <screen>
+ Z> find @attr 1=/link/@creator morten
+ </screen>
+ </para>
- </sect2>
+ <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
+ have the term "english" contained in one of all text subnodes of
+ the subtree defined by the XPath
+ <literal>/record/title[@lang='en']</literal>. And similar
+ predicate filtering.
+ <screen>
+ Z> find @attr 1=/record/title[@lang='en'] english
+ Z> find @attr 1=/link[@creator='sisse'] sibelius
+ Z> find @attr 1=/link[@creator='sisse']/description[@xml:lang='da'] sibelius
+ </screen>
+ </para>
+
+ <para>
+ Combining numeric indexes, boolean expressions,
+ and xpath based searches is possible:
+ <screen>
+ Z> find @attr 1=/record/title @and foo bar
+ Z> find @and @attr 1=/record/title foo @attr 1=4 bar
+ </screen>
+ </para>
+ <para>
+ Escaping PQF keywords and other non-parseable XPath constructs
+ with <literal>'{ }'</literal> to prevent syntax errors:
+ <screen>
+ Z> find @attr {1=/root/first[@attr='danish']} content
+ Z> find @attr {1=/record/@set} oai
+ </screen>
+ </para>
+ <warning>
+ It is worth mentioning that these dynamic performed XPath
+ queries are a performance bottleneck, as no optimized
+ specialized indexes can be used. Therefore, avoid the use of
+ this facility when speed is essential, and the database content
+ size is medium to large.
+ </warning>
- <sect2 id="querymodel-exp1">
- <title>Explain Attribute Set</title>
+ </sect3>
+
+ </sect2>
+
+ <sect2 id="querymodel-exp1">
+ <title>Explain Attribute Set</title>
<para>
The Z39.50 standard defines the
- <ulink url="&url.z39.50.explain;">Explain</ulink>attribute set
- <literal>exp-1</literal>, which is used to discover information
+ <ulink url="&url.z39.50.explain;">Explain</ulink> attribute set
+ <literal>Exp-1</literal>, which is used to discover information
about a server's search semantics and functional capabilities
Zebra exposes a "classic"
Explain database by base name <literal>IR-Explain-1</literal>, which
</para>
<para>
The attribute-set <literal>exp-1</literal> consists of a single
- <literal>Use (type 1)</literal> attribute.
- </para>
- <para>
+ <literal>use attribute (type 1)</literal>.
+ </para>
+ <para>
In addition, the non-Use
<literal>bib-1</literal> attributes, that is, the types
<literal>Relation</literal>, <literal>Position</literal>,
and <literal>Completeness</literal> are imported from
the <literal>bib-1</literal> attribute set, and may be used
within any explain query.
- </para>
+ </para>
- <sect3 id="querymodel-exp1-use">
+ <sect3 id="querymodel-exp1-use">
<title>Use Attributes (type = 1)</title>
- <para>
- The following Explain search atributes are supported:
- <literal>ExplainCategory</literal> (@attr 1=1),
- <literal>DatabaseName</literal> (@attr 1=3),
- <literal>DateAdded</literal> (@attr 1=9),
- <literal>DateChanged</literal>(@attr 1=10).
- </para>
- <para>
- A search in the use attribute <literal>ExplainCategory</literal>
- supports only these predefined values:
- <literal>CategoryList</literal>, <literal>TargetInfo</literal>,
- <literal>DatabaseInfo</literal>, <literal>AttributeDetails</literal>.
- </para>
+ <para>
+ The following Explain search attributes are supported:
+ <literal>ExplainCategory</literal> (@attr 1=1),
+ <literal>DatabaseName</literal> (@attr 1=3),
+ <literal>DateAdded</literal> (@attr 1=9),
+ <literal>DateChanged</literal>(@attr 1=10).
+ </para>
+ <para>
+ A search in the use attribute <literal>ExplainCategory</literal>
+ supports only these predefined values:
+ <literal>CategoryList</literal>, <literal>TargetInfo</literal>,
+ <literal>DatabaseInfo</literal>, <literal>AttributeDetails</literal>.
+ </para>
<para>
See <filename>tab/explain.att</filename> and the
+ <ulink url="&url.z39.50;">Z39.50</ulink> standard
for more information.
- </para>
- </sect3>
+ </para>
+ </sect3>
<sect3>
<title>Explain searches with yaz-client</title>
- <para>
- Classic Explain only defines retrieval of Explain information
- via ASN.1. Pratically no Z39.50 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>GRS-1</literal> and <literal>ASN.1</literal> Explain.
- </para>
-
+ <para>
+ Classic Explain only defines retrieval of Explain information
+ via ASN.1. Practically no Z39.50 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>GRS-1</literal> and <literal>ASN.1</literal> Explain.
+ </para>
+
<para>
List supported categories to find out which explain commands are
supported:
<screen>
Z> base IR-Explain-1
- Z> @attr exp1 1=1 categorylist
+ Z> find @attr exp1 1=1 categorylist
Z> form sutrs
Z> show 1+2
</screen>
</para>
-
+
<para>
Get target info, that is, investigate which databases exist at
this server endpoint:
<screen>
Z> base IR-Explain-1
- Z> @attr exp1 1=1 targetinfo
+ Z> find @attr exp1 1=1 targetinfo
Z> form xml
Z> show 1+1
Z> form grs-1
Z> show 1+1
</screen>
</para>
-
+
<para>
List all supported databases, the number of hits
is the number of databases found, which most commonly are the
<literal>IR-Explain-1</literal> databases.
<screen>
Z> base IR-Explain-1
- Z> f @attr exp1 1=1 databaseinfo
+ Z> find @attr exp1 1=1 databaseinfo
Z> form sutrs
Z> show 1+2
</screen>
Get database info record for database <literal>Default</literal>.
<screen>
Z> base IR-Explain-1
- Z> @and @attr exp1 1=1 databaseinfo @attr exp1 1=3 Default
+ Z> find @and @attr exp1 1=1 databaseinfo @attr exp1 1=3 Default
</screen>
Identical query with explicitly specified attribute set:
<screen>
Z> base IR-Explain-1
- Z> @attrset exp1 @and @attr 1=1 databaseinfo @attr 1=3 Default
+ Z> find @attrset exp1 @and @attr 1=1 databaseinfo @attr 1=3 Default
</screen>
</para>
-
+
<para>
Get attribute details record for database
<literal>Default</literal>.
found.
<screen>
Z> base IR-Explain-1
- Z> @and @attr exp1 1=1 attributedetails @attr exp1 1=3 Default
+ Z> find @and @attr exp1 1=1 attributedetails @attr exp1 1=3 Default
</screen>
Identical query with explicitly specified attribute set:
<screen>
Z> base IR-Explain-1
- Z> @attrset exp1 @and @attr 1=1 attributedetails @attr 1=3 Default
+ Z> find @attrset exp1 @and @attr 1=1 attributedetails @attr 1=3 Default
</screen>
</para>
</sect3>
-
- </sect2>
-
- <sect2 id="querymodel-bib1">
- <title>Bib1 Attribute Set</title>
- <para>
- Something about querying to be written ..
- </para>
- <para>
- Most of the information contained in this section is an excerpt of
- the <literal>ATTRIBUTE SET BIB-1 (Z39.50-1995)
- SEMANTICS</literal>, found at <ulink
- url="&url.z39.50.attset.bib1.1995;">The BIB-1
- Attribute Set Semantics</ulink> from 1995, also in an updated
- <ulink url="&url.z39.50.attset.bib1;">Bib-1
- Attribute Set</ulink>
- version from 2003. Index Data is not the copyright holder of this
- information.
- </para>
+
+ </sect2>
+
+ <sect2 id="querymodel-bib1">
+ <title>Bib1 Attribute Set</title>
+ <para>
+ Most of the information contained in this section is an excerpt of
+ the <literal>ATTRIBUTE SET BIB-1 (Z39.50-1995)
+ SEMANTICS</literal>,
+ found at <ulink url="&url.z39.50.attset.bib1.1995;">. The BIB-1
+ Attribute Set Semantics</ulink> from 1995, also in an updated
+ <ulink url="&url.z39.50.attset.bib1;">Bib-1
+ Attribute Set</ulink>
+ version from 2003. Index Data is not the copyright holder of this
+ information, except for the configuration details, the listing of
+ Zebra's capabilities, and the example queries.
+ </para>
<sect3 id="querymodel-bib1-use">
- <title>Use Attributes (type = 1)</title>
- </sect3>
-
- <sect3 id="querymodel-bib1-relation">
- <title>Relation Attributes (type = 2)</title>
- </sect3>
- <para>
- </para>
+ <title>Use Attributes (type 1)</title>
- <sect3 id="querymodel-bib1-position">
- <title>Position Attributes (type = 3)</title>
- </sect3>
+ <para>
+ A use attribute specifies an access point for any atomic query.
+ These access points are highly dependent on the attribute set used
+ in the query, and are user configurable using the following
+ default configuration files:
+ <filename>tab/bib1.att</filename>,
+ <filename>tab/dan1.att</filename>,
+ <filename>tab/explain.att</filename>, and
+ <filename>tab/gils.att</filename>.
+ New attribute sets can be added by adding new
+ <filename>tab/*.att</filename> configuration files, which need to
+ be sourced in the main configuration <filename>zebra.cfg</filename>.
+ </para>
- <sect3 id="querymodel-bib1-structure">
- <title>Structure Attributes (type = 4)</title>
- </sect3>
+ <para>
+ In addition, Zebra allows the access of
+ <emphasis>internal index names</emphasis> and <emphasis>dynamic
+ XPath</emphasis> as use attributes; see
+ <xref linkend="querymodel-use-string"/> and
+ <xref linkend="querymodel-use-xpath"/>.
+ </para>
- <sect3 id="querymodel-bib1-truncation">
- <title>Truncation Attributes (type = 5)</title>
- </sect3>
+ <para>
+ Phrase search for <emphasis>information retrieval</emphasis> in
+ the title-register, scanning the same register afterwards:
+ <screen>
+ Z> find @attr 1=4 "information retrieval"
+ Z> scan @attr 1=4 information
+ </screen>
+ </para>
+ </sect3>
- <sect3 id="querymodel-bib1-completeness">
- <title>Completeness Attributes (type = 6)</title>
- </sect3>
+ </sect2>
- <sect3 id="querymodel-bib1-sorting">
- <title>Zebra Extention Sorting Attributes (type = 7)</title>
- </sect3>
- <sect3 id="querymodel-bib1-estimation">
- <title>Zebra Extention Search Estimation Attributes (type = 8)</title>
- </sect3>
+ <sect2 id="querymodel-bib1-nonuse">
+ <title>Zebra general Bib1 Non-Use Attributes (type 2-6)</title>
+
+ <sect3 id="querymodel-bib1-relation">
+ <title>Relation Attributes (type 2)</title>
+
+ <para>
+ Relation attributes describe the relationship of the access
+ point (left side
+ of the relation) to the search term as qualified by the attributes (right
+ side of the relation), e.g., Date-publication <= 1975.
+ </para>
- <sect3 id="querymodel-bib1-weight">
- <title>Zebra Extention Weight Attributes (type = 9)</title>
- </sect3>
-
- </sect2>
+ <table id="querymodel-bib1-relation-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Relation Attributes (type 2)</caption>
+ <thead>
+ <tr>
+ <td>Relation</td>
+ <td>Value</td>
+ <td>Notes</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td> Less than</td>
+ <td>1</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Less than or equal</td>
+ <td>2</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Equal</td>
+ <td>3</td>
+ <td>default</td>
+ </tr>
+ <tr>
+ <td>Greater or equal</td>
+ <td>4</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Greater than</td>
+ <td>5</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Not equal</td>
+ <td>6</td>
+ <td>unsupported</td>
+ </tr>
+ <tr>
+ <td>Phonetic</td>
+ <td>100</td>
+ <td>unsupported</td>
+ </tr>
+ <tr>
+ <td>Stem</td>
+ <td>101</td>
+ <td>unsupported</td>
+ </tr>
+ <tr>
+ <td>Relevance</td>
+ <td>102</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>AlwaysMatches</td>
+ <td>103</td>
+ <td>supported</td>
+ </tr>
+ </tbody>
+ </table>
- <sect2 id="querymodel-bib1-mapping">
- <title>Mapping from Bib1 Attributes to Zebra internal
- register indexes</title>
<para>
+ The relation attributes
+ <literal>1-5</literal> are supported and work exactly as
+ expected.
+ All ordering operations are based on a lexicographical ordering,
+ <emphasis>expect</emphasis> when the
+ <literal>structure attribute numeric (109)</literal> is used. In
+ this case, ordering is numerical. See
+ <xref linkend="querymodel-bib1-structure"/>.
+ <screen>
+ Z> find @attr 1=Title @attr 2=1 music
+ ...
+ Number of hits: 11745, setno 1
+ ...
+ Z> find @attr 1=Title @attr 2=2 music
+ ...
+ Number of hits: 11771, setno 2
+ ...
+ Z> find @attr 1=Title @attr 2=3 music
+ ...
+ Number of hits: 532, setno 3
+ ...
+ Z> find @attr 1=Title @attr 2=4 music
+ ...
+ Number of hits: 11463, setno 4
+ ...
+ Z> find @attr 1=Title @attr 2=5 music
+ ...
+ Number of hits: 11419, setno 5
+ </screen>
</para>
- <para>
- <emphasis>Use</emphasis> attributes are interpreted according to the
- attribute sets which have been loaded in the
- <literal>zebra.cfg</literal> file, and are matched against specific
- 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 Bib-1 Any is assumed.
- </para>
+ <para>
+ The relation attribute
+ <literal>Relevance (102)</literal> is supported, see
+ <xref linkend="administration-ranking"/> for full information.
+ </para>
+
+ <para>
+ Ranked search for <emphasis>information retrieval</emphasis> in
+ the title-register:
+ <screen>
+ Z> find @attr 1=4 @attr 2=102 "information retrieval"
+ </screen>
+ </para>
- <para>
- If a <emphasis>Structure</emphasis> attribute of
- <emphasis>Phrase</emphasis> is used in conjunction with a
- <emphasis>Completeness</emphasis> attribute of
- <emphasis>Complete (Sub)field</emphasis>, the term is matched
- 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
- <literal>.abs</literal> file that contains a
- <literal>p</literal>-specifier.
- <!-- ### whatever the hell _that_ is -->
- </para>
+ <para>
+ The relation attribute
+ <literal>AlwaysMatches (103)</literal> is in the default
+ configuration
+ supported in conjecture with structure attribute
+ <literal>Phrase (1)</literal> (which may be omitted by
+ default).
+ It can be configured to work with other structure attributes,
+ see the configuration file
+ <filename>tab/default.idx</filename> and
+ <xref linkend="querymodel-pqf-apt-mapping"/>.
+ </para>
+ <para>
+ <literal>AlwaysMatches (103)</literal> 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.
+ <screen>
+ Z> find @attr 1=Title @attr 2=103 ""
+ Z> find @attr 1=Title @attr 2=103 @attr 4=1 ""
+ </screen>
+ </para>
- <para>
- If <emphasis>Structure</emphasis>=<emphasis>Phrase</emphasis> is
- used in conjunction with <emphasis>Incomplete Field</emphasis> - the
- default value for <emphasis>Completeness</emphasis>, the
- search is directed against the normal word registers, but if the term
- 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 <literal>.abs</literal> file.
- </para>
- <para>
- If the <emphasis>Structure</emphasis> attribute is
- <emphasis>Word List</emphasis>,
- <emphasis>Free-form Text</emphasis>, or
- <emphasis>Document Text</emphasis>, the term is treated as a
- 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
- <literal>.abs</literal> file.
- </para>
+ </sect3>
- <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 <literal>.abs</literal> file.
- </para>
+ <sect3 id="querymodel-bib1-position">
+ <title>Position Attributes (type 3)</title>
+
+ <para>
+ The position attribute specifies the location of the search term
+ within the field or subfield in which it appears.
+ </para>
- <para>
- If the <emphasis>Structure</emphasis> attribute is
- <emphasis>URx</emphasis> the term is treated as a URX (URL) entity.
- The search is performed on those fields that are indexed as type
- <literal>u</literal> in the <literal>.abs</literal> file.
- </para>
+ <table id="querymodel-bib1-position-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Position Attributes (type 3)</caption>
+ <thead>
+ <tr>
+ <td>Position</td>
+ <td>Value</td>
+ <td>Notes</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>First in field </td>
+ <td>1</td>
+ <td>unsupported</td>
+ </tr>
+ <tr>
+ <td>First in subfield</td>
+ <td>2</td>
+ <td>unsupported</td>
+ </tr>
+ <tr>
+ <td>Any position in field</td>
+ <td>3</td>
+ <td>default</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <para>
+ The position attribute values <literal>first in field (1)</literal>,
+ and <literal>first in subfield(2)</literal> are unsupported.
+ Using them does not trigger an error, but silent defaults to
+ <literal>any position in field (3)</literal>.
+ <!-- It should -->
+ </para>
+ </sect3>
+
+ <sect3 id="querymodel-bib1-structure">
+ <title>Structure Attributes (type 4)</title>
+
+ <para>
+ The structure attribute specifies the type of search
+ term. This causes the search to be mapped on
+ different Zebra internal indexes, which must have been defined
+ at index time.
+ </para>
- <para>
- If the <emphasis>Structure</emphasis> attribute is
- <emphasis>Local Number</emphasis> the term is treated as
- native Zebra Record Identifier.
- </para>
+ <para>
+ The possible values of the
+ <literal>structure attribute (type 4)</literal> can be defined
+ using the configuration file <filename>
+ tab/default.idx</filename>.
+ The default configuration is summarized in this table.
+ </para>
- <para>
- If the <emphasis>Relation</emphasis> attribute is
- <emphasis>Equals</emphasis> (default), the term is matched
- in a normal fashion (modulo truncation and processing of
- individual words, if required).
- If <emphasis>Relation</emphasis> is <emphasis>Less Than</emphasis>,
- <emphasis>Less Than or Equal</emphasis>,
- <emphasis>Greater than</emphasis>, or <emphasis>Greater than or
- Equal</emphasis>, the term is assumed to be numerical, and a
- standard regular expression is constructed to match the given
- expression.
- If <emphasis>Relation</emphasis> is <emphasis>Relevance</emphasis>,
- the standard natural-language query processor is invoked.
- </para>
+ <table id="querymodel-bib1-structure-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Structure Attributes (type 4)</caption>
+ <thead>
+ <tr>
+ <td>Structure</td>
+ <td>Value</td>
+ <td>Notes</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>Phrase </td>
+ <td>1</td>
+ <td>default</td>
+ </tr>
+ <tr>
+ <td>Word</td>
+ <td>2</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Key</td>
+ <td>3</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Year</td>
+ <td>4</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Date (normalized)</td>
+ <td>5</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Word list</td>
+ <td>6</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Date (un-normalized)</td>
+ <td>100</td>
+ <td>unsupported</td>
+ </tr>
+ <tr>
+ <td>Name (normalized) </td>
+ <td>101</td>
+ <td>unsupported</td>
+ </tr>
+ <tr>
+ <td>Name (un-normalized) </td>
+ <td>102</td>
+ <td>unsupported</td>
+ </tr>
+ <tr>
+ <td>Structure</td>
+ <td>103</td>
+ <td>unsupported</td>
+ </tr>
+ <tr>
+ <td>Urx</td>
+ <td>104</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Free-form-text</td>
+ <td>105</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Document-text</td>
+ <td>106</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Local-number</td>
+ <td>107</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>String</td>
+ <td>108</td>
+ <td>unsupported</td>
+ </tr>
+ <tr>
+ <td>Numeric string</td>
+ <td>109</td>
+ <td>supported</td>
+ </tr>
+ </tbody>
+ </table>
+
- <para>
- For the <emphasis>Truncation</emphasis> attribute,
- <emphasis>No Truncation</emphasis> is the default.
- <emphasis>Left Truncation</emphasis> is not supported.
- <emphasis>Process # in search term</emphasis> is supported, as is
- <emphasis>Regxp-1</emphasis>.
- <emphasis>Regxp-2</emphasis> enables the fault-tolerant (fuzzy)
- search. As a default, a single error (deletion, insertion,
- replacement) is accepted when terms are matched against the register
- contents.
- </para>
- </sect2>
+ <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
+ are equivalent:
+ <screen>
+ Z> find @attr 1=Title @attr 4=6 "mozart amadeus"
+ Z> find @attr 1=Title @and mozart amadeus
+ </screen>
+ </para>
- <sect2 id="querymodel-regular">
- <title>Regular expressions</title>
+ <para>
+ The structure attribute value
+ <literal>Free-form-text (105)</literal> and
+ <literal>Document-text (106)</literal>
+ are supported, and map both to the boolean <literal>OR</literal>
+ combination of words supplied. The following queries
+ are equivalent:
+ <screen>
+ Z> find @attr 1=Body-of-text @attr 4=105 "bach salieri teleman"
+ Z> find @attr 1=Body-of-text @attr 4=106 "bach salieri teleman"
+ Z> find @attr 1=Body-of-text @or bach @or salieri teleman
+ </screen>
+ This <literal>OR</literal> list of terms is very useful in
+ combination with relevance ranking:
+ <screen>
+ Z> find @attr 1=Body-of-text @attr 2=102 @attr 4=105 "bach salieri teleman"
+ </screen>
+ </para>
<para>
- Each term in a query is interpreted as a regular expression if
- the truncation value is either <emphasis>Regxp-1</emphasis> (102)
- or <emphasis>Regxp-2</emphasis> (103).
- Both query types follow the same syntax with the operands:
- <variablelist>
-
- <varlistentry>
- <term>x</term>
- <listitem>
- <para>
- Matches the character <emphasis>x</emphasis>.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>.</term>
- <listitem>
- <para>
- Matches any character.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><literal>[</literal>..<literal>]</literal></term>
- <listitem>
- <para>
- Matches the set of characters specified;
- such as <literal>[abc]</literal> or <literal>[a-c]</literal>.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- and the operators:
- <variablelist>
-
- <varlistentry>
- <term>x*</term>
- <listitem>
- <para>
- Matches <emphasis>x</emphasis> zero or more times. Priority: high.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>x+</term>
- <listitem>
- <para>
- Matches <emphasis>x</emphasis> one or more times. Priority: high.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>x?</term>
- <listitem>
- <para>
- Matches <emphasis>x</emphasis> zero or once. Priority: high.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>xy</term>
- <listitem>
- <para>
- Matches <emphasis>x</emphasis>, then <emphasis>y</emphasis>.
- Priority: medium.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>x|y</term>
- <listitem>
- <para>
- Matches either <emphasis>x</emphasis> or <emphasis>y</emphasis>.
- Priority: low.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- The order of evaluation may be changed by using parentheses.
- </para>
-
- <para>
- If the first character of the <emphasis>Regxp-2</emphasis> query
- is a plus character (<literal>+</literal>) it marks the
- beginning of a section with non-standard specifiers.
- The next plus character marks the end of the section.
- Currently Zebra only supports one specifier, the error tolerance,
- which consists one digit.
+ The structure attribute value
+ <literal>Local number (107)</literal>
+ is supported, and maps always to the Zebra internal document ID,
+ irrespectively which use attribute is specified. The following queries
+ have exactly the same unique record in the hit set:
+ <screen>
+ Z> find @attr 4=107 10
+ Z> find @attr 1=4 @attr 4=107 10
+ Z> find @attr 1=1010 @attr 4=107 10
+ </screen>
</para>
<para>
- Since the plus operator is normally a suffix operator the addition to
- the query syntax doesn't violate the syntax for standard regular
- expressions.
+ In
+ the GILS schema (<literal>gils.abs</literal>), the
+ west-bounding-coordinate is indexed as type <literal>n</literal>,
+ and is therefore searched by specifying
+ <emphasis>structure</emphasis>=<emphasis>Numeric String</emphasis>.
+ To match all those records with west-bounding-coordinate greater
+ than -114 we use the following query:
+ <screen>
+ Z> find @attr 4=109 @attr 2=5 @attr gils 1=2038 -114
+ </screen>
</para>
+ <note>
+ The exact mapping between PQF queries and Zebra internal indexes
+ and index types is explained in
+ <xref linkend="querymodel-pqf-apt-mapping"/>.
+ </note>
+
+ </sect3>
+ <sect3 id="querymodel-bib1-truncation">
+ <title>Truncation Attributes (type = 5)</title>
+
+ <para>
+ The truncation attribute specifies whether variations of one or
+ more characters are allowed between search term and hit terms, or
+ not. Using non-default truncation attributes will broaden the
+ document hit set of a search query.
+ </para>
+
+ <table id="querymodel-bib1-truncation-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Truncation Attributes (type 5)</caption>
+ <thead>
+ <tr>
+ <td>Truncation</td>
+ <td>Value</td>
+ <td>Notes</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>Right truncation </td>
+ <td>1</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Left truncation</td>
+ <td>2</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Left and right truncation</td>
+ <td>3</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>Do not truncate</td>
+ <td>100</td>
+ <td>default</td>
+ </tr>
+ <tr>
+ <td>Process # in search term</td>
+ <td>101</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>RegExpr-1 </td>
+ <td>102</td>
+ <td>supported</td>
+ </tr>
+ <tr>
+ <td>RegExpr-2</td>
+ <td>103</td>
+ <td>supported</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <para>
+ The truncation attribute values 1-3 perform the obvious way:
+ <screen>
+ Z> scan @attr 1=Body-of-text schnittke
+ ...
+ * schnittke (81)
+ schnittkes (31)
+ schnittstelle (1)
+ ...
+ Z> find @attr 1=Body-of-text @attr 5=1 schnittke
+ ...
+ Number of hits: 95, setno 7
+ ...
+ Z> find @attr 1=Body-of-text @attr 5=2 schnittke
+ ...
+ Number of hits: 81, setno 6
+ ...
+ Z> find @attr 1=Body-of-text @attr 5=3 schnittke
+ ...
+ Number of hits: 95, setno 8
+ </screen>
+ </para>
+
+ <para>
+ The truncation attribute value
+ <literal>Process # in search term (101)</literal> is a
+ poor-man's regular expression search. It maps
+ each <literal>#</literal> to <literal>.*</literal>, and
+ performs then a <literal>Regexp-1 (102)</literal> regular
+ expression search. The following two queries are equivalent:
+ <screen>
+ Z> find @attr 1=Body-of-text @attr 5=101 schnit#ke
+ Z> find @attr 1=Body-of-text @attr 5=102 schnit.*ke
+ ...
+ Number of hits: 89, setno 10
+ </screen>
+ </para>
+
+ <para>
+ The truncation attribute value
+ <literal>Regexp-1 (102)</literal> is a normal regular search,
+ see <xref linkend="querymodel-regular"/> for details.
+ <screen>
+ Z> find @attr 1=Body-of-text @attr 5=102 schnit+ke
+ Z> find @attr 1=Body-of-text @attr 5=102 schni[a-t]+ke
+ </screen>
+ </para>
+
+ <para>
+ The truncation attribute value
+ <literal>Regexp-2 (103) </literal> is a Zebra specific extension
+ which allows <emphasis>fuzzy</emphasis> matches. One single
+ error in spelling of search terms is allowed, i.e., a document
+ is hit if it includes a term which can be mapped to the used
+ search term by one character substitution, addition, deletion or
+ change of position.
+ <screen>
+ Z> find @attr 1=Body-of-text @attr 5=100 schnittke
+ ...
+ Number of hits: 81, setno 14
+ ...
+ Z> find @attr 1=Body-of-text @attr 5=103 schnittke
+ ...
+ Number of hits: 103, setno 15
+ ...
+ </screen>
+ </para>
+ </sect3>
+
+ <sect3 id="querymodel-bib1-completeness">
+ <title>Completeness Attributes (type = 6)</title>
+
+
+ <para>
+ The <literal>Completeness Attributes (type = 6)</literal>
+ is used to specify that a given search term or term list is either
+ part of the terms of a given index/field
+ (<literal>Incomplete subfield (1)</literal>), or is
+ what literally is found in the entire field's index
+ (<literal>Complete field (3)</literal>).
+ </para>
+
+ <table id="querymodel-bib1-completeness-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+ <caption>Completeness Attributes (type = 6)</caption>
+ <thead>
+ <tr>
+ <td>Completeness</td>
+ <td>Value</td>
+ <td>Notes</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>Incomplete subfield</td>
+ <td>1</td>
+ <td>default</td>
+ </tr>
+ <tr>
+ <td>Complete subfield</td>
+ <td>2</td>
+ <td>depreciated</td>
+ </tr>
+ <tr>
+ <td>Complete field</td>
+ <td>3</td>
+ <td>supported</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <para>
+ The <literal>Completeness Attributes (type = 6)</literal>
+ is only partially and conditionally
+ supported in the sense that it is ignored if the hit index is
+ not of structure <literal>type="w"</literal> or
+ <literal>type="p"</literal>.
+ </para>
+ <para>
+ <literal>Incomplete subfield (1)</literal> is the default, and
+ makes Zebra use
+ register <literal>type="w"</literal>, whereas
+ <literal>Complete field (3)</literal> triggers
+ 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>
+ binary format days. Zebra does not support it, but maps silently
+ to <literal>Complete field (3)</literal>.
+ </para>
+
+ <note>
+ The exact mapping between PQF queries and Zebra internal indexes
+ and index types is explained in
+ <xref linkend="querymodel-pqf-apt-mapping"/>.
+ </note>
+ </sect3>
</sect2>
+
+ </sect1>
- <sect2 id="querymodel-examples">
- <title>Query examples</title>
+ <sect1 id="querymodel-zebra">
+ <title>Advanced Zebra PQF 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
+ model. These extensions are <emphasis>non-standard</emphasis>
+ and <emphasis>non-portable</emphasis>: most functional extensions
+ are modeled over the <literal>bib-1</literal> attribute set,
+ defining type 7-9 attributes.
+ There are also the special
+ <literal>string</literal> type index names for the
+ <literal>idxpath</literal> attribute set.
+ </para>
+
+ <sect2 id="querymodel-zebra-attr-allrecords">
+ <title>Zebra specific retrieval of all records</title>
<para>
- Phrase search for <emphasis>information retrieval</emphasis> in
- the title-register:
+ Zebra defines a hardwired <literal>string</literal> index name
+ called <literal>_ALLRECORDS</literal>. It matches any record
+ contained in the database, if used in conjunction with
+ the relation attribute
+ <literal>AlwaysMatches (103)</literal>.
+ </para>
+ <para>
+ The <literal>_ALLRECORDS</literal> index name is used for total database
+ export. The search term is ignored, it may be empty.
+ <screen>
+ Z> find @attr 1=_ALLRECORDS @attr 2=103 ""
+ </screen>
+ </para>
+ <para>
+ Combination with other index types can be made. For example, to
+ find all records which are <emphasis>not</emphasis> indexed in
+ the <literal>Title</literal> register, issue one of the two
+ equivalent queries:
<screen>
- @attr 1=4 "information retrieval"
+ Z> find @not @attr 1=_ALLRECORDS @attr 2=103 "" @attr 1=Title @attr 2=103 ""
+ Z> find @not @attr 1=_ALLRECORDS @attr 2=103 "" @attr 1=4 @attr 2=103 ""
</screen>
</para>
+ <warning>
+ The special string index <literal>_ALLRECORDS</literal> is
+ experimental, and the provided functionality and syntax may very
+ well change in future releases of Zebra.
+ </warning>
+
+ </sect2>
+
+ <sect2 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
+ recognized regardless of attribute
+ set used in a <literal>search</literal> operation query.
+ </para>
+ <table id="querymodel-zebra-attr-search-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Zebra Search Attribute Extensions</caption>
+ <thead>
+ <tr>
+ <td>Name</td>
+ <td>Value</td>
+ <td>Operation</td>
+ <td>Zebra version</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>Embedded Sort</td>
+ <td>7</td>
+ <td>search</td>
+ <td>1.1</td>
+ </tr>
+ <tr>
+ <td>Term Set</td>
+ <td>8</td>
+ <td>search</td>
+ <td>1.1</td>
+ </tr>
+ <tr>
+ <td>Rank Weight</td>
+ <td>9</td>
+ <td>search</td>
+ <td>1.1</td>
+ </tr>
+ <tr>
+ <td>Approx Limit</td>
+ <td>9</td>
+ <td>search</td>
+ <td>1.4</td>
+ </tr>
+ <tr>
+ <td>Term Reference</td>
+ <td>10</td>
+ <td>search</td>
+ <td>1.4</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <sect3 id="querymodel-zebra-attr-sorting">
+ <title>Zebra Extension Embedded Sort Attribute (type 7)</title>
+ </sect3>
<para>
- Ranked search for the same thing:
+ 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 to deal with the Sort
+ Facility.
+ </para>
+
+ <para>
+ All ordering operations are based on a lexicographical ordering,
+ <emphasis>expect</emphasis> when the
+ <literal>structure attribute numeric (109)</literal> is used. In
+ this case, ordering is numerical. See
+ <xref linkend="querymodel-bib1-structure"/>.
+ </para>
+
+ <para>
+ 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
+ rest and must be <literal>@or</literal>'ed.
+ The term associated with 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"/>.
+ </para>
+ <para>
+ For example, searching for water, sort by title (ascending)
+ <screen>
+ Z> find @or @attr 1=1016 water @attr 7=1 @attr 1=4 0
+ </screen>
+ </para>
+ <para>
+ Or, searching for water, sort by title ascending, then date descending
<screen>
- @attr 1=4 @attr 2=102 "Information retrieval"
+ Z> find @or @or @attr 1=1016 water @attr 7=1 @attr 1=4 0 @attr 7=2 @attr 1=30 1
+ </screen>
+ </para>
+
+ <sect3 id="querymodel-zebra-attr-estimation">
+ <title>Zebra Extension Term Set Attribute (type 8)</title>
+ </sect3>
+ <para>
+ 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
+ the named term set are returned as SUTRS records.
+ </para>
+ <para>
+ For example, searching for u in title, right truncated, and
+ storing the result in term set named 'aset'
+ <screen>
+ Z> find @attr 5=1 @attr 1=4 @attr 8=aset u
</screen>
</para>
+ <warning>
+ The model has one serious flaw: we don't know the size of term
+ set. Experimental. Do not use in production code.
+ </warning>
+ <sect3 id="querymodel-zebra-attr-weight">
+ <title>Zebra Extension Rank Weight Attribute (type 9)</title>
+ </sect3>
+ <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.
+ See also <xref linkend="administration-ranking"/>.
+ </para>
+ <para>
+ For example, searching for utah in title with weight 30 as well
+ as any with weight 20:
+ <screen>
+ Z> find @attr 2=102 @or @attr 9=30 @attr 1=4 utah @attr 9=20 utah
+ </screen>
+ </para>
+
+ <sect3 id="querymodel-zebra-attr-limit">
+ <title>Zebra Extension Approximative Limit Attribute (type 9)</title>
+ </sect3>
+ <para>
+ Newer Zebra versions normally estimate hit count for every APT
+ (leaf) in the query tree. These hit counts are returned as part of
+ the searchResult-1 facility in the binary encoded Z39.50 search
+ response packages.
+ </para>
+ <para>
+ 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.
+ </para>
+ <para>
+ For example, we might be interested in exact hit count for a, but
+ for b we allow hit count estimates for 1000 and higher.
+ <screen>
+ Z> find @and a @attr 9=1000 b
+ </screen>
+ </para>
+ <note>
+ The estimated hit count facility makes searches faster, as one
+ only needs to process large hit lists partially.
+ </note>
+ <warning>
+ This facility clashes with rank weight, because there all
+ documents in the hit lists need to be examined for scoring and
+ re-sorting.
+ It is an experimental
+ extension. Do not use in production code.
+ </warning>
+
+ <sect3 id="querymodel-zebra-attr-termref">
+ <title>Zebra Extension Term Reference Attribute (type 10)</title>
+ </sect3>
+ <para>
+ Zebra supports the <literal>searchResult-1</literal> facility.
+ If the <literal>Term Reference Attribute (type 10)</literal> 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.
+ </para>
+ <!--
<para>
- Phrase search with a regular expression:
<screen>
- @attr 1=4 @attr 5=102 "informat.* retrieval"
</screen>
</para>
+ -->
+ <warning>
+ Experimental. Do not use in production code.
+ </warning>
+
+ </sect2>
+
+
+ <sect2 id="querymodel-zebra-attr-scan">
+ <title>Zebra specific Scan Extensions to all Attribute Sets</title>
+ <para>
+ Zebra extends the Bib1 attribute types, and these extensions are
+ recognized regardless of attribute
+ set used in a <literal>scan</literal> operation query.
+ </para>
+ <table id="querymodel-zebra-attr-scan-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Zebra Scan Attribute Extensions</caption>
+ <thead>
+ <tr>
+ <td>Name</td>
+ <td>Type</td>
+ <td>Operation</td>
+ <td>Zebra version</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>Result Set Narrow</td>
+ <td>8</td>
+ <td>scan</td>
+ <td>1.3</td>
+ </tr>
+ <tr>
+ <td>Approximative Limit</td>
+ <td>9</td>
+ <td>scan</td>
+ <td>1.4</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <sect3 id="querymodel-zebra-attr-narrow">
+ <title>Zebra Extension Result Set Narrow (type 8)</title>
+ </sect3>
+ <para>
+ If attribute <literal>Result Set Narrow (type 8)</literal>
+ is given for <literal>scan</literal>, the value is the name of a
+ result set. Each hit count in <literal>scan</literal> is
+ <literal>@and</literal>'ed with the result set given.
+ </para>
<para>
- Ranked search with a regular expression:
+ Consider for example
+ the case of scanning all title fields around the
+ scanterm <emphasis>mozart</emphasis>, then refining the scan by
+ issuing a filtering query for <emphasis>amadeus</emphasis> to
+ restrict the scan to the result set of the query:
<screen>
- @attr 1=4 @attr 5=102 @attr 2=102 "informat.* retrieval"
+ Z> scan @attr 1=4 mozart
+ ...
+ * mozart (43)
+ mozartforskningen (1)
+ mozartiana (1)
+ mozarts (16)
+ ...
+ Z> f @attr 1=4 amadeus
+ ...
+ Number of hits: 15, setno 2
+ ...
+ Z> scan @attr 1=4 @attr 8=2 mozart
+ ...
+ * mozart (14)
+ mozartforskningen (0)
+ mozartiana (0)
+ mozarts (1)
+ ...
</screen>
</para>
+
+ <warning>
+ Experimental. Do not use in production code.
+ </warning>
+ <sect3 id="querymodel-zebra-attr-approx">
+ <title>Zebra Extension Approximative Limit (type 9)</title>
+ </sect3>
+ <para>
+ The <literal>Zebra Extension Approximative Limit (type
+ 9)</literal> is a way to enable approximate
+ hit counts for <literal>scan</literal> hit counts, in the same
+ way as for <literal>search</literal> hit counts.
+ </para>
+ <!--
<para>
- In the GILS schema (<literal>gils.abs</literal>), the
- west-bounding-coordinate is indexed as type <literal>n</literal>,
- and is therefore searched by specifying
- <emphasis>structure</emphasis>=<emphasis>Numeric String</emphasis>.
- To match all those records with west-bounding-coordinate greater
- than -114 we use the following query:
<screen>
- @attr 4=109 @attr 2=5 @attr gils 1=2038 -114
- </screen>
+ </screen>
+ </para>
+ -->
+ <warning>
+ Experimental and buggy. Definitely not to be used in production code.
+ </warning>
+
+
+ </sect2>
+
+
+ <sect2 id="querymodel-idxpath">
+ <title>Zebra special IDXPATH Attribute Set for GRS indexing</title>
+ <para>
+ The attribute-set <literal>idxpath</literal> consists of a single
+ <literal>Use (type 1)</literal> attribute. All non-use attributes
+ behave as normal.
+ </para>
+ <para>
+ This feature is enabled when defining the
+ <literal>xpath enable</literal> option in the GRS 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>
+ directive <literal>attset: idxpath.att</literal> must be enabled.
</para>
+ <warning>The <literal>idxpath</literal> is depreciated, may not be
+ supported in future Zebra versions, and should definitely
+ not be used in production code.
+ </warning>
+
+ <sect3 id="querymodel-idxpath-use">
+ <title>IDXPATH Use Attributes (type = 1)</title>
+ <para>
+ This attribute set allows one to search GRS filter indexed
+ records by XPATH like structured index names.
+ </para>
+
+ <warning>The <literal>idxpath</literal> option defines hard-coded
+ index names, which might clash with your own index names.
+ </warning>
+
+ <table id="querymodel-idxpath-use-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Zebra specific IDXPATH Use Attributes (type 1)</caption>
+ <thead>
+ <tr>
+ <td>IDXPATH</td>
+ <td>Value</td>
+ <td>String Index</td>
+ <td>Notes</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>XPATH Begin</td>
+ <td>1</td>
+ <td>_XPATH_BEGIN</td>
+ <td>depreciated</td>
+ </tr>
+ <tr>
+ <td>XPATH End</td>
+ <td>2</td>
+ <td>_XPATH_END</td>
+ <td>depreciated</td>
+ </tr>
+ <tr>
+ <td>XPATH CData</td>
+ <td>1016</td>
+ <td>_XPATH_CDATA</td>
+ <td>depreciated</td>
+ </tr>
+ <tr>
+ <td>XPATH Attribute Name</td>
+ <td>3</td>
+ <td>_XPATH_ATTR_NAME</td>
+ <td>depreciated</td>
+ </tr>
+ <tr>
+ <td>XPATH Attribute CData</td>
+ <td>1015</td>
+ <td>_XPATH_ATTR_CDATA</td>
+ <td>depreciated</td>
+ </tr>
+ </tbody>
+ </table>
+
+
+ <para>
+ See <filename>tab/idxpath.att</filename> for more information.
+ </para>
+ <para>
+ Search for all documents starting with root element
+ <literal>/root</literal> (either using the numeric or the string
+ use attributes):
+ <screen>
+ Z> find @attrset idxpath @attr 1=1 @attr 4=3 root/
+ Z> find @attr idxpath 1=1 @attr 4=3 root/
+ Z> find @attr 1=_XPATH_BEGIN @attr 4=3 root/
+ </screen>
+ </para>
+ <para>
+ Search for all documents where specific nested XPATH
+ <literal>/c1/c2/../cn</literal> exists. Notice the very
+ counter-intuitive <emphasis>reverse</emphasis> notation!
+ <screen>
+ Z> find @attrset idxpath @attr 1=1 @attr 4=3 cn/cn-1/../c1/
+ Z> find @attr 1=_XPATH_BEGIN @attr 4=3 cn/cn-1/../c1/
+ </screen>
+ </para>
+ <para>
+ Search for CDATA string <emphasis>text</emphasis> in any element
+ <screen>
+ Z> find @attrset idxpath @attr 1=1016 text
+ Z> find @attr 1=_XPATH_CDATA text
+ </screen>
+ </para>
+ <para>
+ Search for CDATA string <emphasis>anothertext</emphasis> in any
+ attribute:
+ <screen>
+ Z> find @attrset idxpath @attr 1=1015 anothertext
+ Z> find @attr 1=_XPATH_ATTR_CDATA anothertext
+ </screen>
+ </para>
+ <para>
+ Search for all documents with have an XML element node
+ including an 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
+ </screen>
+ </para>
+ <para>
+ Combining usual <literal>bib-1</literal> attribute set searches
+ with <literal>idxpath</literal> attribute set searches:
+ <screen>
+ Z> find @and @attr idxpath 1=1 @attr 4=3 link/ @attr 1=4 mozart
+ Z> find @and @attr 1=_XPATH_BEGIN @attr 4=3 link/ @attr 1=_XPATH_CDATA mozart
+ </screen>
+ </para>
+ <para>
+ Scanning is supported on all <literal>idxpath</literal>
+ indexes, both specified as numeric use attributes, or as string
+ index names.
+ <screen>
+ Z> scan @attrset idxpath @attr 1=1016 text
+ Z> scan @attr 1=_XPATH_ATTR_CDATA anothertext
+ Z> scan @attrset idxpath @attr 1=3 @attr 4=3 ''
+ </screen>
+ </para>
+
+ </sect3>
</sect2>
- <!-- see in util/zebramap.c
- int zebra_maps_attr
-
- if (completeness_value == 2 || completeness_value == 3)
- *complete_flag = 1;
- else
- *complete_flag = 0;
- *reg_id = 0;
-
- *sort_flag =(sort_relation_value > 0) ? 1 : 0;
- *search_type = "phrase";
- strcpy(rank_type, "void");
- if (relation_value == 102)
- {
- if (weight_value == -1)
- weight_value = 34;
- sprintf(rank_type, "rank,w=%d,u=%d", weight_value, use_value);
- }
- if (relation_value == 103)
- {
- *search_type = "always";
- *reg_id = 'w';
- return 0;
- }
- if (*complete_flag)
- *reg_id = 'p';
- else
- *reg_id = 'w';
- switch (structure_value)
- {
- case 6: /* word list */
- *search_type = "and-list";
- break;
- case 105: /* free-form-text */
- *search_type = "or-list";
- break;
- case 106: /* document-text */
- *search_type = "or-list";
- break;
- case -1:
- case 1: /* phrase */
- case 2: /* word */
- case 108: /* string */
- *search_type = "phrase";
- break;
- case 107: /* local-number */
- *search_type = "local";
- *reg_id = 0;
- break;
- case 109: /* numeric string */
- *reg_id = 'n';
- *search_type = "numeric";
- break;
- case 104: /* urx */
- *reg_id = 'u';
- *search_type = "phrase";
- break;
- case 3: /* key */
- *reg_id = '0';
- *search_type = "phrase";
- break;
- case 4: /* year */
- *reg_id = 'y';
- *search_type = "phrase";
- break;
- case 5: /* date */
- *reg_id = 'd';
- *search_type = "phrase";
- break;
- default:
- return -1;
- }
- return 0;
-
- -->
+ <sect2 id="querymodel-pqf-apt-mapping">
+ <title>Mapping from PQF atomic APT queries to Zebra internal
+ register indexes</title>
+ <para>
+ The rules for PQF 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
+ deal with the rules for determining the correct structure type of
+ the named register.
+ </para>
+
+ <sect3 id="querymodel-pqf-apt-mapping-accesspoint">
+ <title>Mapping of PQF 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;">Z39.50</ulink>
+ standard.
+ All other access point types are Zebra specific, and non-portable.
+ </para>
+
+ <table id="querymodel-zebra-mapping-accesspoint-types"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Access point name mapping</caption>
+ <thead>
+ <tr>
+ <td>Access Point</td>
+ <td>Type</td>
+ <td>Grammar</td>
+ <td>Notes</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>Use attribute</td>
+ <td>numeric</td>
+ <td>[1-9][1-9]*</td>
+ <td>directly mapped to string index name</td>
+ </tr>
+ <tr>
+ <td>String index name</td>
+ <td>string</td>
+ <td>[a-zA-Z](\-?[a-zA-Z0-9])*</td>
+ <td>normalized name is used as internal string index name</td>
+ </tr>
+ <tr>
+ <td>Zebra internal index name</td>
+ <td>zebra</td>
+ <td>_[a-zA-Z](_?[a-zA-Z0-9])*</td>
+ <td>hardwired internal string index name</td>
+ </tr>
+ <tr>
+ <td>XPATH special index</td>
+ <td>XPath</td>
+ <td>/.*</td>
+ <td>special xpath search for GRS indexed records</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <para>
+ <literal>Attribute set names</literal> and
+ <literal>string index names</literal> are normalizes
+ according to the following rules: all <emphasis>single</emphasis>
+ hyphens <literal>'-'</literal> are stripped, and all upper case
+ letters are folded to lower case.
+ </para>
+
+ <para>
+ <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>Bib-1</literal>, and may be
+ omitted in the 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
+ configuration has not been altered):
+ <screen>
+ Z> find @attr 1=Body-of-text serenade
+ Z> find @attr 1=bodyoftext 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 Bib-1 @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
+ </screen>
+ </para>
+
+ <para>
+ The <emphasis>numerical</emphasis>
+ <literal>use attributes (type 1)</literal>
+ are interpreted according to the
+ attribute sets which have been loaded in the
+ <literal>zebra.cfg</literal> file, and are matched against specific
+ 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
+ <literal>Bib-1 Use Any (1016)</literal> is
+ assumed.
+ The predefined <literal>use attribute sets</literal>
+ can be reconfigured by tweaking the configuration files
+ <filename>tab/*.att</filename>, and
+ new attribute sets can be defined by adding similar files in the
+ configuration path <literal>profilePath</literal> of the server.
+ </para>
+
+ <para>
+ <literal>String indexes</literal> can be accessed directly,
+ independently which attribute set is in use. These are just
+ ignored. The above mentioned name normalization applies.
+ <literal>String index names</literal> are defined in the
+ used indexing filter configuration files, for example in the
+ <literal>GRS</literal>
+ <filename>*.abs</filename> configuration files, or in the
+ <literal>alvis</literal> filter XSLT indexing stylesheets.
+ </para>
+
+ <para>
+ <literal>Zebra internal indexes</literal> can be accessed directly,
+ according to the same rules as the user defined
+ <literal>string indexes</literal>. The only difference is that
+ <literal>Zebra internal index names</literal> are hardwired,
+ all uppercase and
+ must start with the character <literal>'_'</literal>.
+ </para>
+
+ <para>
+ Finally, <literal>XPATH</literal> access points are only
+ available using the <literal>GRS</literal> 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"/>.
+
+ </para>
+
+
+ </sect3>
+
+
+ <sect3 id="querymodel-pqf-apt-mapping-structuretype">
+ <title>Mapping of PQF APT structure and completeness to
+ register type</title>
+ <para>
+ Internally Zebra has in it's 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,
+ bitfields and string based text needs different rulesets.
+ </para>
+
+ <table id="querymodel-zebra-mapping-structure-types"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Structure and completeness mapping to register types</caption>
+ <thead>
+ <tr>
+ <td>Structure</td>
+ <td>Completeness</td>
+ <td>Register type</td>
+ <td>Notes</td>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>
+ phrase (@attr 4=1), word (@attr 4=2),
+ word-list (@attr 4=6),
+ free-form-text (@attr 4=105), or document-text (@attr 4=106)
+ </td>
+ <td>Incomplete field (@attr 6=1)</td>
+ <td>Word ('w')</td>
+ <td>Traditional tokenized and character normalized word index</td>
+ </tr>
+ <tr>
+ <td>
+ phrase (@attr 4=1), word (@attr 4=2),
+ word-list (@attr 4=6),
+ free-form-text (@attr 4=105), or document-text (@attr 4=106)
+ </td>
+ <td>complete field' (@attr 6=3)</td>
+ <td>Phrase ('p')</td>
+ <td>Character normalized, but not tokenized index for phrase
+ matches
+ </td>
+ </tr>
+ <tr>
+ <td>urx (@attr 4=104)</td>
+ <td>ignored</td>
+ <td>URX/URL ('u')</td>
+ <td>Special index for URL web adresses</td>
+ </tr>
+ <tr>
+ <td>numeric (@attr 4=109)</td>
+ <td>ignored</td>
+ <td>Numeric ('u')</td>
+ <td>Special index for digital numbers</td>
+ </tr>
+ <tr>
+ <td>key (@attr 4=3)</td>
+ <td>ignored</td>
+ <td>Null bitmap ('0')</td>
+ <td>Used for non-tokenizated and non-normalized bit sequences</td>
+ </tr>
+ <tr>
+ <td>year (@attr 4=4)</td>
+ <td>ignored</td>
+ <td>Year ('y')</td>
+ <td>Non-tokenizated and non-normalized 4 digit numbers</td>
+ </tr>
+ <tr>
+ <td>date (@attr 4=5)</td>
+ <td>ignored</td>
+ <td>Date ('d')</td>
+ <td>Non-tokenizated and non-normalized ISO date strings</td>
+ </tr>
+ <tr>
+ <td>ignored</td>
+ <td>ignored</td>
+ <td>Sort ('s')</td>
+ <td>Used with special sort attribute set (@attr 7=1, @attr 7=2)</td>
+ </tr>
+ <tr>
+ <td>overruled</td>
+ <td>overruled</td>
+ <td>special</td>
+ <td>Internal record ID register, used whenever
+ Relation Always Matches (@attr 2=103) is specified</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <!-- see in util/zebramap.c -->
+
+ <para>
+ If a <emphasis>Structure</emphasis> attribute of
+ <emphasis>Phrase</emphasis> is used in conjunction with a
+ <emphasis>Completeness</emphasis> attribute of
+ <emphasis>Complete (Sub)field</emphasis>, the term is matched
+ 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
+ GRS <filename>*.abs</filename> file that contains a
+ <literal>p</literal>-specifier.
+ <screen>
+ Z> scan @attr 1=Title @attr 4=1 @attr 6=3 beethoven
+ ...
+ bayreuther festspiele (1)
+ * beethoven bibliography database (1)
+ benny carter (1)
+ ...
+ Z> find @attr 1=Title @attr 4=1 @attr 6=3 "beethoven bibliography"
+ ...
+ Number of hits: 0, setno 5
+ ...
+ Z> find @attr 1=Title @attr 4=1 @attr 6=3 "beethoven bibliography database"
+ ...
+ Number of hits: 1, setno 6
+ </screen>
+ </para>
+
+ <para>
+ If <emphasis>Structure</emphasis>=<emphasis>Phrase</emphasis> is
+ used in conjunction with <emphasis>Incomplete Field</emphasis> - the
+ default value for <emphasis>Completeness</emphasis>, the
+ search is directed against the normal word registers, but if the term
+ 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 GRS <filename>*.abs</filename> file.
+ <screen>
+ Z> scan @attr 1=Title @attr 4=1 @attr 6=1 beethoven
+ ...
+ beefheart (1)
+ * beethoven (18)
+ beethovens (7)
+ ...
+ Z> find @attr 1=Title @attr 4=1 @attr 6=1 beethoven
+ ...
+ Number of hits: 18, setno 1
+ ...
+ Z> find @attr 1=Title @attr 4=1 @attr 6=1 "beethoven bibliography"
+ ...
+ Number of hits: 2, setno 2
+ ...
+ </screen>
+ </para>
+
+ <para>
+ If the <emphasis>Structure</emphasis> attribute is
+ <emphasis>Word List</emphasis>,
+ <emphasis>Free-form Text</emphasis>, or
+ <emphasis>Document Text</emphasis>, the term is treated as a
+ 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
+ GRS <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 GRS
+ <filename>*.abs</filename> file.
+ </para>
+
+ <para>
+ If the <emphasis>Structure</emphasis> attribute is
+ <emphasis>URX</emphasis> the term is treated as a URX (URL) entity.
+ The search is performed on those fields that are indexed as type
+ <literal>u</literal> in the <filename>*.abs</filename> file.
+ </para>
+
+ <para>
+ If the <emphasis>Structure</emphasis> attribute is
+ <emphasis>Local Number</emphasis> the term is treated as
+ native Zebra Record Identifier.
+ </para>
+
+ <para>
+ If the <emphasis>Relation</emphasis> attribute is
+ <emphasis>Equals</emphasis> (default), the term is matched
+ in a normal fashion (modulo truncation and processing of
+ individual words, if required).
+ If <emphasis>Relation</emphasis> is <emphasis>Less Than</emphasis>,
+ <emphasis>Less Than or Equal</emphasis>,
+ <emphasis>Greater than</emphasis>, or <emphasis>Greater than or
+ Equal</emphasis>, the term is assumed to be numerical, and a
+ standard regular expression is constructed to match the given
+ expression.
+ If <emphasis>Relation</emphasis> is <emphasis>Relevance</emphasis>,
+ the standard natural-language query processor is invoked.
+ </para>
+
+ <para>
+ For the <emphasis>Truncation</emphasis> attribute,
+ <emphasis>No Truncation</emphasis> is the default.
+ <emphasis>Left Truncation</emphasis> is not supported.
+ <emphasis>Process # in search term</emphasis> is supported, as is
+ <emphasis>Regxp-1</emphasis>.
+ <emphasis>Regxp-2</emphasis> enables the fault-tolerant (fuzzy)
+ search. As a default, a single error (deletion, insertion,
+ replacement) is accepted when terms are matched against the register
+ contents.
+ </para>
+
+ </sect3>
+ </sect2>
+
+ <sect2 id="querymodel-regular">
+ <title>Zebra Regular Expressions in Truncation Attribute (type = 5)</title>
+
+ <para>
+ Each term in a query is interpreted as a regular expression if
+ the truncation value is either <emphasis>Regxp-1 (@attr 5=102)</emphasis>
+ or <emphasis>Regxp-2 (@attr 5=103)</emphasis>.
+ Both query types follow the same syntax with the operands:
+ </para>
+
+ <table id="querymodel-regular-operands-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+
+ <caption>Regular Expression Operands</caption>
+ <!--
+ <thead>
+ <tr><td>one</td><td>two</td></tr>
+ </thead>
+ -->
+ <tbody>
+ <tr>
+ <td><literal>x</literal></td>
+ <td>Matches the character <literal>x</literal>.</td>
+ </tr>
+ <tr>
+ <td><literal>.</literal></td>
+ <td>Matches any character.</td>
+ </tr>
+ <tr>
+ <td><literal>[ .. ]</literal></td>
+ <td>Matches the set of characters specified;
+ such as <literal>[abc]</literal> or <literal>[a-c]</literal>.</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <para>
+ The above operands can be combined with the following operators:
+ </para>
+
+ <table id="querymodel-regular-operators-table"
+ frame="all" rowsep="1" colsep="1" align="center">
+ <caption>Regular Expression Operators</caption>
+ <!--
+ <thead>
+ <tr><td>one</td><td>two</td></tr>
+ </thead>
+ -->
+ <tbody>
+ <tr>
+ <td><literal>x*</literal></td>
+ <td>Matches <literal>x</literal> zero or more times.
+ Priority: high.</td>
+ </tr>
+ <tr>
+ <td><literal>x+</literal></td>
+ <td>Matches <literal>x</literal> one or more times.
+ Priority: high.</td>
+ </tr>
+ <tr>
+ <td><literal>x?</literal></td>
+ <td> Matches <literal>x</literal> zero or once.
+ Priority: high.</td>
+ </tr>
+ <tr>
+ <td><literal>xy</literal></td>
+ <td> Matches <literal>x</literal>, then <literal>y</literal>.
+ Priority: medium.</td>
+ </tr>
+ <tr>
+ <td><literal>x|y</literal></td>
+ <td> Matches either <literal>x</literal> or <literal>y</literal>.
+ Priority: low.</td>
+ </tr>
+ <tr>
+ <td><literal>( )</literal></td>
+ <td>The order of evaluation may be changed by using parentheses.</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <para>
+ If the first character of the <literal>Regxp-2</literal> query
+ is a plus character (<literal>+</literal>) it marks the
+ beginning of a section with non-standard specifiers.
+ The next plus character marks the end of the section.
+ Currently Zebra only supports one specifier, the error tolerance,
+ which consists one digit.
+ </para>
+
+ <para>
+ Since the plus operator is normally a suffix operator the addition to
+ the query syntax doesn't violate the syntax for standard regular
+ expressions.
+ </para>
+
+ <para>
+ For example, a phrase search with regular expressions in
+ the title-register is performed like this:
+ <screen>
+ Z> find @attr 1=4 @attr 5=102 "informat.* retrieval"
+ </screen>
+ </para>
+
+ <para>
+ Combinations with other attributes are possible. For example, a
+ ranked search with a regular expression:
+ <screen>
+ Z> find @attr 1=4 @attr 5=102 @attr 2=102 "informat.* retrieval"
+ </screen>
+ </para>
+ </sect2>
+
<!--
<para>
process input records.
Two basic types of processing are available - raw text and structured
data. Raw text is just that, and it is selected by providing the
- argument <emphasis>text</emphasis> to Zebra. Structured records are
+ argument <literal>text</literal> to Zebra. Structured records are
all handled internally using the basic mechanisms described in the
subsequent sections.
Zebra can read structured records in many different formats.
-<!--
- <sect1 id="architecture-querylanguage">
- <title>Query Languages</title>
-
- <para>
-
-http://www.loc.gov/z3950/agency/document.html
-
- PQF and BIB-1 stuff to be explained
- <ulink url="&url.z39.50.attset.bib1;">
- http://www.loc.gov/z3950/agency/defns/bib1.html</ulink>
-
- <ulink url="&url.z39.50.attset.bib1.1995;">
- http://www.loc.gov/z3950/agency/bib1.html</ulink>
-
- http://www.loc.gov/z3950/agency/markup/13.html
-
- </para>
- </sect1>
-
-
-These attribute types are recognized regardless of attribute set. Some are recognized for search, others for scan.
-
-Search
-
-Type Name Version
-7 Embedded Sort 1.1
-8 Term Set 1.1
-9 Rank weight 1.1
-9 Approx Limit 1.4
-10 Term Ref 1.4
-
-Embedded Sort
-
-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.
-
-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:
-
-Search for water, sort by title (ascending):
-
- @or @attr 1=1016 water @attr 7=1 @attr 1=4 0
-
-Search for water, sort by title ascending, then date descending:
-
- @or @or @attr 1=1016 water @attr 7=1 @attr 1=4 0 @attr 7=2 @attr 1=30 1
-
-Term Set
-
-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.
-
-Seach for u in title, right truncated.. Store result in result set named uset.
-
- @attr 5=1 @attr 1=4 @attr 8=uset u
-
-The model as one serious flaw.. We don't know the size of term set.
-
-Rank weight
-
-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.
-
-Search for utah in title with weight 30 as well as any with weight 20.
-
- @attr 2=102 @or @attr 9=30 @attr 1=4 utah @attr 9=20 utah
-
-Approx Limit
-
-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.
-
-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.
-
-We are intersted in exact hit count for a, but for b we allow estimates for 1000 and higher..
-
- @and a @attr 9=1000 b
-
-This facility clashes with rank weight! Fortunately this is a Zebra 1.4 thing so we can change this without upsetting anybody!
-
-Term Ref
-
-Zebra supports the searchResult-1 facility.
-
-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.
-
-Scan
-
-Type Name Version
-8 Result set narrow 1.3
-9 Approx Limit 1.4
-
-Result set narrow
-
-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.
-
-Approx limit
-
-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.
-
-
- AdamDickmeiss - 19 Dec 2005
-
-
--->
-
</chapter>
<!-- Keep this comment at the end of the file
projects / idzebra-moved-to-github.git / blobdiff