+
+ <section 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 (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>
+
+ <section 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.
+ </para>
+
+ <table id="querymodel-attribute-sets-table" frame="top">
+ <title>Attribute sets predefined in Zebra</title>
+ <tgroup cols="4">
+ <thead>
+ <row>
+ <entry>Attribute set</entry>
+ <entry>Short hand</entry>
+ <entry>Status</entry>
+ <entry>Notes</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry><literal>Explain</literal></entry>
+ <entry><literal>exp-1</literal></entry>
+ <entry>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.</entry>
+ <entry>predefined</entry>
+ </row>
+ <row>
+ <entry><literal>Bib1</literal></entry>
+ <entry><literal>bib-1</literal></entry>
+ <entry>Standard PQF query language attribute set which defines the
+ semantics of Z39.50 searching. In addition, all of the
+ non-use attributes (types 2-11) define the hard-wired
+ Zebra internal query
+ processing.</entry>
+ <entry>default</entry>
+ </row>
+ <row>
+ <entry><literal>GILS</literal></entry>
+ <entry><literal>gils</literal></entry>
+ <entry>Extension to the <literal>Bib1</literal> attribute set.</entry>
+ <entry>predefined</entry>
+ </row>
+ <!--
+ <row>
+ <entry><literal>IDXPATH</literal></entry>
+ <entry><literal>idxpath</literal></entry>
+ <entry>Hardwired XPATH like attribute set, only available for
+ indexing with the GRS record model</entry>
+ <entry>deprecated</entry>
+ </row>
+ -->
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ The use attributes (type 1) mappings the
+ predefined attribute sets are found in the
+ attribute set configuration files <filename>tab/*.att</filename>.
+ </para>
+
+ <note>
+ <para>
+ 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"/>.
+ </para>
+ </note>
+
+ </section>
+
+ <section id="querymodel-boolean-operators">
+ <title>Boolean operators</title>
+ <para>
+ A pair of sub query 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="top">
+ <title>Boolean operators</title>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Keyword</entry>
+ <entry>Operator</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row><entry><literal>@and</literal></entry>
+ <entry>binary <literal>AND</literal> operator</entry>
+ <entry>Set intersection of two atomic queries hit sets</entry>
+ </row>
+ <row><entry><literal>@or</literal></entry>
+ <entry>binary <literal>OR</literal> operator</entry>
+ <entry>Set union of two atomic queries hit sets</entry>
+ </row>
+ <row><entry><literal>@not</literal></entry>
+ <entry>binary <literal>AND NOT</literal> operator</entry>
+ <entry>Set complement of two atomic queries hit sets</entry>
+ </row>
+ <row><entry><literal>@prox</literal></entry>
+ <entry>binary <literal>PROXIMITY</literal> operator</entry>
+ <entry>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.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </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
+ attribute set as follows.
+ Querying for the union of all documents containing the
+ terms <emphasis>information</emphasis> OR
+ <emphasis>retrieval</emphasis>:
+ <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 corresponding
+ OR query.
+ <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 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 corresponding
+ PROXIMITY query.
+ <screen>
+ Z> find "information retrieval"
+ </screen>
+ </para>
+ </section>
+
+
+ <section 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>, 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.
+ UN-supplied non-use attributes types 2-11 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>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Type</entry>
+ <entry>Notes</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><emphasis>attribute list</emphasis></entry>
+ <entry>List of <literal>orthogonal</literal> attributes</entry>
+ <entry>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.
+ </entry>
+ </row>
+ <row>
+ <entry><emphasis>term</emphasis></entry>
+ <entry>single <literal>term</literal>
+ or <literal>quoted term list</literal> </entry>
+ <entry>Here the search terms or list of search terms is added
+ to the query</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ <para>
+ Querying for the term <emphasis>information</emphasis> in the
+ default index using the default attribute set, the server choice
+ of access point/index, and the default non-use attributes.
+ <screen>
+ Z> find information
+ </screen>
+ </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 the term
+ <emphasis>debussy</emphasis> in the title field.
+ <screen>
+ Z> find @attr 1=4 debussy
+ </screen>
+ </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 might 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>
+ </section>
+
+
+ <section 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>. Notice that the client, not
+ the server, assigns the string <literal>'1'</literal> to the
+ named result set.
+ <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
+ </screen>
+ </para>
+
+ <note>
+ <para>
+ 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.
+ </para>
+ </note>
+ </section>
+
+ <section id="querymodel-use-string">
+ <title>Zebra's special access point of type 'string'</title>
+ <para>
+ The numeric <literal>use (type 1)</literal> attribute is usually
+ 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 attribute value. This is a great feature for
+ debugging, and when you do
+ 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. Scanning the same index.
+ <screen>
+ Z> find @attr 1=sometext "information retrieval"
+ Z> scan @attr 1=sometext aterm
+ </screen>
+ </para>
+ <para>
+ Searching or scanning
+ the bib-1 use attribute 54 using it's string name:
+ <screen>
+ Z> find @attr 1=Code-language eng
+ Z> scan @attr 1=Code-language ""
+ </screen>
+ </para>
+ <para>
+ It is possible to search
+ in any silly string index - if it's defined in your
+ indexation rules and can be parsed by the PQF parser.
+ This is definitely not the recommended use of
+ this facility, as it might confuse your users with some very
+ unexpected results.
+ <screen>
+ Z> find @attr 1=silly/xpath/alike[@index]/name "information retrieval"
+ </screen>
+ </para>
+ <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
+ debugging facility.
+ </para>
+ </section>
+
+ <section 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="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>
+ <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 GRS record model is simpler than
+ a full XML 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
+ <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>
+
+ <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 sub nodes 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 client-side PQF parsing
+ syntax errors:
+ <screen>
+ Z> find @attr {1=/root/first[@attr='danish']} content
+ Z> find @attr {1=/record/@set} oai
+ </screen>
+ </para>
+ <warning>
+ <para>
+ 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.
+ </para>
+ </warning>
+ </section>
+ </section>
+
+ <section 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
+ about a server's search semantics and functional capabilities
+ Zebra exposes a "classic"
+ Explain database by base name <literal>IR-Explain-1</literal>, which
+ is populated with system internal information.
+ </para>
+ <para>
+ The attribute-set <literal>exp-1</literal> consists of a single
+ <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>,
+ <literal>Structure</literal>, <literal>Truncation</literal>,
+ and <literal>Completeness</literal> are imported from
+ the <literal>bib-1</literal> attribute set, and may be used
+ within any explain query.
+ </para>
+
+ <section id="querymodel-exp1-use">
+ <title>Use Attributes (type = 1)</title>
+ <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>
+ </section>
+
+ <section id="querymodel-examples">
+ <title>Explain searches with yaz-client</title>
+ <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> 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> find @attr exp1 1=1 targetinfo
+ Z> form xml
+ Z> show 1+1
+ Z> form grs-1
+ Z> show 1+1
+ Z> form sutrs
+ 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
+ following two:
+ the <literal>Default</literal> and the
+ <literal>IR-Explain-1</literal> databases.
+ <screen>
+ Z> base IR-Explain-1
+ Z> find @attr exp1 1=1 databaseinfo
+ Z> form sutrs
+ Z> show 1+2
+ </screen>
+ </para>
+
+ <para>
+ Get database info record for database <literal>Default</literal>.
+ <screen>
+ Z> base IR-Explain-1
+ 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> find @attrset exp1 @and @attr 1=1 databaseinfo @attr 1=3 Default
+ </screen>
+ </para>
+
+ <para>
+ Get attribute details record for database
+ <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
+ found.
+ <screen>
+ Z> base IR-Explain-1
+ 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> find @attrset exp1 @and @attr 1=1 attributedetails @attr 1=3 Default
+ </screen>
+ </para>
+ </section>
+
+ </section>
+
+ <section 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>
+
+
+ <section id="querymodel-bib1-use">
+ <title>Use Attributes (type 1)</title>
+
+ <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>.
+ </para>
+ <para>
+ For example, some few <literal>Bib-1</literal> use
+ attributes from the <filename>tab/bib1.att</filename> are:
+ <screen>
+ att 1 Personal-name
+ att 2 Corporate-name
+ att 3 Conference-name
+ att 4 Title
+ ...
+ att 1009 Subject-name-personal
+ att 1010 Body-of-text
+ att 1011 Date/time-added-to-db
+ ...
+ att 1016 Any
+ att 1017 Server-choice
+ att 1018 Publisher
+ ...
+ att 1035 Anywhere
+ att 1036 Author-Title-Subject
+ </screen>
+ </para>
+ <para>
+ 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>
+ <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>
+
+ <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>
+ </section>
+
+ </section>
+
+
+ <section id="querymodel-bib1-nonuse">
+ <title>Zebra general Bib1 Non-Use Attributes (type 2-6)</title>
+
+ <section id="querymodel-bib1-relation">
+ <title>Relation Attributes (type 2)</title>
+
+ <para>
+ 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>
+
+ <table id="querymodel-bib1-relation-table" frame="top">
+ <title>Relation Attributes (type 2)</title>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Relation</entry>
+ <entry>Value</entry>
+ <entry>Notes</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>Less than</entry>
+ <entry>1</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Less than or equal</entry>
+ <entry>2</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Equal</entry>
+ <entry>3</entry>
+ <entry>default</entry>
+ </row>
+ <row>
+ <entry>Greater or equal</entry>
+ <entry>4</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Greater than</entry>
+ <entry>5</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Not equal</entry>
+ <entry>6</entry>
+ <entry>unsupported</entry>
+ </row>
+ <row>
+ <entry>Phonetic</entry>
+ <entry>100</entry>
+ <entry>unsupported</entry>
+ </row>
+ <row>
+ <entry>Stem</entry>
+ <entry>101</entry>
+ <entry>unsupported</entry>
+ </row>
+ <row>
+ <entry>Relevance</entry>
+ <entry>102</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>AlwaysMatches</entry>
+ <entry>103</entry>
+ <entry>supported</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ 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
+ <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>
+ 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>
+ 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>
+
+
+ </section>
+
+ <section 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>
+
+ <table id="querymodel-bib1-position-table" frame="top">
+ <title>Position Attributes (type 3)</title>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Position</entry>
+ <entry>Value</entry>
+ <entry>Notes</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>First in field </entry>
+ <entry>1</entry>
+ <entry>unsupported</entry>
+ </row>
+ <row>
+ <entry>First in subfield</entry>
+ <entry>2</entry>
+ <entry>unsupported</entry>
+ </row>
+ <row>
+ <entry>Any position in field</entry>
+ <entry>3</entry>
+ <entry>supported</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
+ The position attribute values <literal>first in field (1)</literal>,
+ and <literal>first in subfield(2)</literal> are unsupported.
+ Using them silently maps to
+ <literal>any position in field (3)</literal>. A proper diagnostic
+ should have been issued.
+ </para>
+ </section>
+
+ <section 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>
+ 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>
+
+ <table id="querymodel-bib1-structure-table" frame="top">
+ <title>Structure Attributes (type 4)</title>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Structure</entry>
+ <entry>Value</entry>
+ <entry>Notes</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>Phrase </entry>
+ <entry>1</entry>
+ <entry>default</entry>
+ </row>
+ <row>
+ <entry>Word</entry>
+ <entry>2</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Key</entry>
+ <entry>3</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Year</entry>
+ <entry>4</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Date (normalized)</entry>
+ <entry>5</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Word list</entry>
+ <entry>6</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Date (un-normalized)</entry>
+ <entry>100</entry>
+ <entry>unsupported</entry>
+ </row>
+ <row>
+ <entry>Name (normalized) </entry>
+ <entry>101</entry>
+ <entry>unsupported</entry>
+ </row>
+ <row>
+ <entry>Name (un-normalized) </entry>
+ <entry>102</entry>
+ <entry>unsupported</entry>
+ </row>
+ <row>
+ <entry>Structure</entry>
+ <entry>103</entry>
+ <entry>unsupported</entry>
+ </row>
+ <row>
+ <entry>Urx</entry>
+ <entry>104</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Free-form-text</entry>
+ <entry>105</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Document-text</entry>
+ <entry>106</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>Local-number</entry>
+ <entry>107</entry>
+ <entry>supported</entry>
+ </row>
+ <row>
+ <entry>String</entry>
+ <entry>108</entry>
+ <entry>unsupported</entry>
+ </row>
+ <row>
+ <entry>Numeric string</entry>
+ <entry>109</entry>
+ <entry>supported</entry>
+ </row>
+ </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
+ are equivalent:
+ <screen>
+ Z> find @attr 1=Title @attr 4=6 "mozart amadeus"
+ Z> find @attr 1=Title @and mozart amadeus
+ </screen>
+ </para>
+
+ <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>
+ 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>
+ 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>
+ <para>
+ The exact mapping between 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>