- <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>
- <!-- tell about RPN - include link to YAZ
- url.yaz.pqf -->
- <para>
- Therefore, Index Data has defined a textual representation of the
- RPN query: <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>
+ <section 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;">&z3950;</ulink> and
+ <ulink url="&url.sru;">&sru;</ulink>,
+ and implement the
+ type-1 Reverse Polish Notation (&rpn;) query
+ model defined there.
+ Unfortunately, this model has only defined a binary
+ encoded representation, which is used as transport packaging in
+ the &z3950; protocol layer. This representation is not human
+ readable, nor defines any convenient way to specify queries.
+ </para>
+ <para>
+ Since the type-1 (&rpn;)
+ query structure has no direct, useful string
+ representation, every client application needs to provide some
+ form of mapping from a local query notation or representation to it.
+ </para>
+
+
+ <section id="querymodel-query-languages-pqf">
+ <title>Prefix Query Format (&pqf;)</title>
+ <para>
+ Index Data has defined a textual representation in the
+ <ulink url="&url.yaz.pqf;">Prefix Query Format</ulink>, short
+ <emphasis>&pqf;</emphasis>, which maps
+ one-to-one to binary encoded
+ <emphasis>type-1 &rpn;</emphasis> queries.
+ &pqf; has been adopted by other
+ parties developing &z3950; software, and is often referred to as
+ <emphasis>Prefix Query Notation</emphasis>, or in short
+ &pqn;. See
+ <xref linkend="querymodel-rpn"/> for further explanations and
+ descriptions of &zebra;'s capabilities.
+ </para>
+ </section>
+
+ <section id="querymodel-query-languages-cql">
+ <title>Common Query Language (&cql;)</title>
+ <para>
+ The query model of the type-1 &rpn;,
+ expressed in &pqf;/&pqn; is natively supported.
+ On the other hand, the default &sru;
+ web services <emphasis>Common Query Language</emphasis>
+ <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>
+ </section>
+
+ </section>
+
+ <section id="querymodel-operation-types">
+ <title>Operation types</title>
+ <para>
+ &zebra; supports all of the three different
+ &z3950;/&sru; operations defined in the
+ standards: explain, search,
+ and scan. A short description of the
+ functionality and purpose of each is quite in order here.
+ </para>
+
+ <section id="querymodel-operation-type-explain">
+ <title>Explain Operation</title>
+ <para>
+ The <emphasis>syntax</emphasis> of &z3950;/&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
+ explain 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 &z3950; embeds the explain operation
+ by performing a
+ search in the magic
+ <literal>IR-Explain-1</literal> database;
+ see <xref linkend="querymodel-exp1"/>.
+ </para>
+ <para>
+ In &sru;, explain is an entirely separate
+ operation, which returns an ZeeRex &xml; record according to the
+ structure defined by the protocol.
+ </para>
+ <para>
+ In both cases, the information gathered through
+ explain operations can be used to
+ auto-configure a client user interface to the servers
+ capabilities.
+ </para>
+ </section>
+
+ <section 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 &z3950;/&sru; servers.
+ </para>
+ </section>
+
+ <section id="querymodel-operation-type-scan">
+ <title>Scan Operation</title>
+ <para>
+ The scan 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 found in
+ the indexes, and in addition the scan
+ 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>
+ </section>
+
+ </section>
+
+ </section>