<row><entry><literal>s=ag</literal></entry><entry>
Tokens that appears as phrases (with blank in them) gets
- structure phrase attached. Tokens that appers as words
- gets structure phrase attached. Phrases and words are
+ structure phrase attached (4=1). Tokens that appear to be words
+ gets structure word attached (4=2). Phrases and words are
ANDed. This is a variant of s=al and s=pw, with the main
difference that words are not split (with operator AND)
but instead kept in one RPN token. This facility appeared
<entry><literal>?</literal></entry>
</row>
<row>
+ <entry>mask</entry>
+ <entry>Masking character. Requires YAZ 4.2.58 or later</entry>
+ <entry><literal>#</literal></entry>
+ </row>
+ <row>
<entry>field</entry>
<entry>Specifies how multiple fields are to be
combined. There are two modes: <literal>or</literal>:
#define YAZ_MARC_XCHANGE 5
#define YAZ_MARC_CHECK 6
#define YAZ_MARC_TURBOMARC 7
+ #define YAZ_MARC_JSON 8
/* supply iconv handle for character set conversion .. */
void yaz_marc_iconv(yaz_marc_t mt, yaz_iconv_t cd);
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>YAZ_MARC_JSON</term>
+ <listitem>
+ <para>
+ <ulink url="&url.marc_in_json;">MARC-in_JSON</ulink> format.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</para>
<para>
<listitem>
<para>
Format of input. Supported values are
- <literal>marc</literal> (for ISO2709); and <literal>xml</literal>
- for MARCXML/MarcXchange.
+ <literal>marc</literal> (for ISO2709), <literal>xml</literal>
+ (MARCXML/MarcXchange) and <literal>json</literal>
+ (<ulink url="&url.marc_in_json;">MARC-in_JSON</ulink>).
</para>
</listitem>
</varlistentry>
<listitem>
<para>
Format of output. Supported values are
- <literal>line</literal> (MARC line format);
- <literal>marcxml</literal> (for MARCXML),
- <literal>marc</literal> (ISO2709),
- <literal>marcxhcange</literal> (for MarcXchange).
+ <literal>line</literal> (MARC line format);
+ <literal>marcxml</literal> (for MARCXML),
+ <literal>marc</literal> (ISO2709),
+ <literal>marcxhcange</literal> (for MarcXchange),
+ or <literal>json</literal>
+ (<ulink url="&url.marc_in_json;">MARC-in_JSON </ulink>).
</para>
</listitem>
</varlistentry>
</itemizedlist>
</para>
</example>
+
+ <example id="tools.retrieval.marcxml">
+ <title>MARCXML backend</title>
+ <para>
+ SRW/SRU and Solr backends returns records in XML.
+ If they return MARCXML or MarcXchange, the retrieval module
+ can convert those into ISO2709 formats, most commonly USMARC
+ (AKA MARC21).
+ In this example, the backend returns MARCXML for schema="marcxml".
+ </para>
+ <programlisting><![CDATA[
+ <retrievalinfo>
+ <retrieval syntax="usmarc">
+ <backend syntax="xml" name="marcxml">
+ <marc inputformat="xml" outputformat="marc"
+ outputcharset="marc-8"/>
+ </backend>
+ </retrieval>
+ <retrieval syntax="xml" name="marcxml"
+ identifier="info:srw/schema/1/marcxml-v1.1"/>
+ <retrieval syntax="xml" name="dc">
+ <backend syntax="xml" name="marcxml">
+ <xslt stylesheet="MARC21slim2DC.xsl"/>
+ </backend>
+ </retrieval>
+ </retrievalinfo>
+]]>
+ </programlisting>
+ <para>
+ This means that our frontend supports:
+ <itemizedlist>
+ <listitem>
+ <para>
+ MARC21 records (any element set name) in MARC-8 encoding.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ MARCXML records for element-set=marcxml
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Dublin core records for element-set=dc.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </example>
+
</sect2>
<sect2 id="tools.retrieval.api">
<title>API</title>
</para>
</sect2>
</sect1>
+ <sect1><title>Sorting</title>
+ <para>
+ This chapter describes sorting and how it is supported in YAZ.
+ Sorting applies to a result-set.
+ The <ulink url="http://www.loc.gov/z3950/agency/markup/05.html#3.2.7">
+ Z39.50 sorting facility
+ </ulink>
+ takes one or more input result-sets
+ and one result-set as output. The most simple case is that
+ the input-set is the same as the output-set.
+ </para>
+ <para>
+ Z39.50 sorting has a separate APDU (service) that is, thus, performed
+ following a search (two phases).
+ </para>
+ <para>
+ In SRU/Solr, however, the model is different. Here, sorting is specified
+ during the the search operation. Note, however, that SRU might
+ perform sort as separate search, by referring to an existing result-set
+ in the query (result-set reference).
+ </para>
+ <sect2><title>Using the Z39.50 sort service</title>
+ <para>
+ yaz-client and the ZOOM API supports the Z39.50 sort facility. In any
+ case the sort sequence or sort critiera is using a string notation.
+ This notation is a one-line notation suitable for being manually
+ entered or generated and allows for easy logging (one liner).
+ For the ZOOM API, the sort is specified in the call to ZOOM_query_sortby
+ function. For yaz-client the sort is performed and specified using
+ the sort and sort+ commands. For description of the sort criteria notation
+ refer to the <link linkend="sortspec">sort command</link> in the
+ yaz-client manual.
+ </para>
+ <para>
+ The ZOOM API might choose one of several sort strategies for
+ sorting. Refer to <xref linkend="zoom-sort-strategy"/>.
+ </para>
+ </sect2>
+ <sect2><title>Type-7 sort</title>
+ <para>
+ Type-7 sort is an extension to the Bib-1 based RPN query where the
+ sort specification is embedded as an Attribute-Plus-Term.
+ </para>
+ <para>
+ The objectives for introducing Type-7 sorting is that it allows
+ a client to perform sorting even if it does not implement/support
+ Z39.50 sort. Virtually all Z39.50 client software supports
+ RPN queries. It also may improve performance because the sort
+ critieria is specified along with the search query.
+ </para>
+ <para>
+ The sort is triggered by the presence of type 7 and the value of type 7
+ specifies the
+ <ulink url="http://www.loc.gov/z3950/agency/asn1.html#SortKeySpec">
+ sortRelation
+ </ulink>
+ The value for type 7 is 1 for ascending and 2 for descending.
+ For the
+ <ulink url="http://www.loc.gov/z3950/agency/asn1.html#SortElement">
+ sortElement
+ </ulink>
+ only the generic part is handled. If generic sortKey is of type
+ sortField, then attribute type 1 is present and the value is
+ sortField (InternationalString). If generic sortKey is of type
+ sortAttributes, then the attributes in list is used . generic sortKey
+ of type elementSpec is not supported.
+ </para>
+ <para>
+ The term in the sorting Attribute-Plus-Term combo should hold
+ an integer. The value is 0 for primary sorting criteria, 1 for second
+ criteria, etc.
+ </para>
+ </sect2>
+ </sect1>
</chapter>
<!-- Keep this comment at the end of the file
projects / yaz-moved-to-github.git / blobdiff