1 <?xml version="1.0" standalone="no"?>
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.4//EN"
3 "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"
5 <!ENTITY % local SYSTEM "local.ent">
7 <!ENTITY % entities SYSTEM "entities.ent">
9 <!ENTITY % idcommon SYSTEM "common/common.ent">
12 <refentry id="pazpar2_conf">
14 <productname>Pazpar2</productname>
15 <productnumber>&version;</productnumber>
16 <info><orgname>Index Data</orgname></info>
20 <refentrytitle>Pazpar2 conf</refentrytitle>
21 <manvolnum>5</manvolnum>
22 <refmiscinfo class="manual">File formats and conventions</refmiscinfo>
26 <refname>pazpar2_conf</refname>
27 <refpurpose>Pazpar2 Configuration</refpurpose>
32 <command>pazpar2.conf</command>
36 <refsect1><title>DESCRIPTION</title>
38 The Pazpar2 configuration file, together with any referenced XSLT files,
39 govern Pazpar2's behavior as a client, and control the normalization and
40 extraction of data elements from incoming result records, for the
41 purposes of merging, sorting, facet analysis, and display.
45 The file is specified using the option -f on the Pazpar2 command line.
46 There is not presently a way to reload the configuration file without
47 restarting Pazpar2, although this will most likely be added some time
52 <refsect1><title>FORMAT</title>
54 The configuration file is XML-structured. It must be well-formed XML. All
55 elements specific to Pazpar2 should belong to the namespace
56 <literal>http://www.indexdata.com/pazpar2/1.0</literal>
57 (this is assumed in the
58 following examples). The root element is named "<literal>pazpar2</literal>".
59 Under the root element are a number of elements which group categories of
60 information. The categories are described below.
63 <refsect2 id="config-threads"><title>threads</title>
65 This section is optional and is supported for Pazpar2 version 1.3.1 and
66 later . It is identified by element "<literal>threads</literal>" which
67 may include one attribute "<literal>number</literal>" which specifies
68 the number of worker-threads that the Pazpar2 instance is to use.
69 A value of 0 (zero) disables worker-threads (all work is carried out
73 <refsect2 id="config-server"><title>server</title>
75 This section governs overall behavior of a server endpoint. It is identified
76 by the element "server" which takes an optional attribute, "id", which
77 identifies this particular Pazpar2 server. Any string value for "id"
81 elements are described below. From Pazpar2 version 1.2 this is
84 <variablelist> <!-- level 1 -->
89 Configures the webservice -- this controls how you can connect
90 to Pazpar2 from your browser or server-side code. The
91 attributes 'host' and 'port' control the binding of the
92 server. The 'host' attribute can be used to bind the server to
93 a secondary IP address of your system, enabling you to run
94 Pazpar2 on port 80 alongside a conventional web server. You
95 can override this setting on the command line using the option -h.
104 If this item is given, Pazpar2 will forward all incoming HTTP
105 requests that do not contain the filename 'search.pz2' to the
106 host and port specified using the 'host' and 'port'
107 attributes. The 'myurl' attribute is required, and should provide
108 the base URL of the server. Generally, the HTTP URL for the host
109 specified in the 'listen' parameter. This functionality is
110 crucial if you wish to use
111 Pazpar2 in conjunction with browser-based code (JS, Flash,
112 applets, etc.) which operates in a security sandbox. Such code
113 can only connect to the same server from which the enclosing
114 HTML page originated. Pazpar2s proxy functionality enables you
115 to host all of the main pages (plus images, CSS, etc) of your
116 application on a conventional webserver, while efficiently
117 processing webservice requests for metasearch status, results,
124 <term>relevance / sort / mergekey / facet</term>
127 Specifies character set normalization for relevancy / sorting /
128 mergekey and facets - for the server. These definitions serves as
129 default for services that don't have these given. For the meaning
130 of these settings refer to the "relevance" element inside service.
136 <term>settings</term>
139 Specifies target settings for the server.. These settings serves
140 as default for all services which don't have these given.
141 The settings element requires one attribute 'src' which specifies
142 a settings file or a directory . If a directory is given all
143 files with suffix <filename>.xml</filename> is read from this
145 <xref linkend="target_settings"/> for more information.
154 This nested element controls the behavior of Pazpar2 with
155 respect to your data model. In Pazpar2, incoming records are
156 normalized, using XSLT, into an internal representation.
157 The 'service' section controls the further processing and
158 extraction of data from the internal representation, primarily
159 through the 'metadata' sub-element.
162 Pazpar2 version 1.2 and later allows multiple service elements.
163 Multiple services must be given a unique ID by specifying
164 attribute <literal>id</literal>.
165 A single service may be unnamed (service ID omitted). The
166 service ID is referred to in the
167 <link linkend="command-init"><literal>init</literal></link> webservice
168 command's <literal>service</literal> parameter.
171 <variablelist> <!-- Level 2 -->
172 <varlistentry><term>metadata</term>
175 One of these elements is required for every data element in
176 the internal representation of the record (see
177 <xref linkend="data_model"/>. It governs
178 subsequent processing as pertains to sorting, relevance
179 ranking, merging, and display of data elements. It supports
180 the following attributes:
183 <variablelist> <!-- level 3 -->
184 <varlistentry><term>name</term>
187 This is the name of the data element. It is matched
188 against the 'type' attribute of the
190 in the normalized record. A warning is produced if
191 metadata elements with an unknown name are
193 normalized record. This name is also used to
195 data elements in the records returned by the
196 webservice API, and to name sort lists and browse
202 <varlistentry><term>type</term>
205 The type of data element. This value governs any
206 normalization or special processing that might take
207 place on an element. Possible values are 'generic'
208 (basic string), 'year' (a range is computed if
209 multiple years are found in the record). Note: This
210 list is likely to increase in the future.
215 <varlistentry><term>brief</term>
218 If this is set to 'yes', then the data element is
219 includes in brief records in the webservice API. Note
220 that this only makes sense for metadata elements that
221 are merged (see below). The default value is 'no'.
226 <varlistentry><term>sortkey</term>
229 Specifies that this data element is to be used for
230 sorting. The possible values are 'numeric' (numeric
231 value), 'skiparticle' (string; skip common, leading
232 articles), and 'no' (no sorting). The default value is
238 <varlistentry><term>rank</term>
241 Specifies that this element is to be used to
243 records against the user's query (when ranking is
244 requested). The value is an integer, used as a
245 multiplier against the basic TF*IDF score. A value of
246 1 is the base, higher values give additional
248 elements of this type. The default is '0', which
249 excludes this element from the rank calculation.
254 <varlistentry><term>termlist</term>
257 Specifies that this element is to be used as a
258 termlist, or browse facet. Values are tabulated from
259 incoming records, and a highscore of values (with
260 their associated frequency) is made available to the
261 client through the webservice API.
263 are 'yes' and 'no' (default).
268 <varlistentry><term>merge</term>
271 This governs whether, and how elements are extracted
272 from individual records and merged into cluster
273 records. The possible values are: 'unique' (include
274 all unique elements), 'longest' (include only the
275 longest element (strlen), 'range' (calculate a range
276 of values across all matching records), 'all' (include
277 all elements), or 'no' (don't merge; this is the
283 <varlistentry><term>mergekey</term>
286 If set to '<literal>required</literal>', the value of this
287 metadata element is appended to the resulting mergekey if
288 the metadata is present in a record instance.
289 If the metadata element is not present, the a unique mergekey
290 will be generated instead.
293 If set to '<literal>optional</literal>', the value of this
294 metadata element is appended to the resulting mergekey if the
295 the metadata is present in a record instance. If the metadata
296 is not present, it will be empty.
299 If set to '<literal>no</literal>' or the mergekey attribute is
300 omitted, the metadata will not be used in the creation of a
306 <varlistentry><term>setting</term>
309 This attribute allows you to make use of static database
310 settings in the processing of records. Three possible values
311 are allowed. 'no' is the default and doesn't do anything.
312 'postproc' copies the value of a setting with the same name
313 into the output of the normalization stylesheet(s). 'parameter'
314 makes the value of a setting with the same name available
315 as a parameter to the normalization stylesheet, so you
316 can further process the value inside of the stylesheet, or use
317 the value to decide how to deal with other data values.
320 The purpose of using settings in this way can either be to
321 control the behavior of normalization stylesheet in a database-
322 dependent way, or to easily make database-dependent values
323 available to display-logic in your user interface, without having
324 to implement complicated interactions between the user interface
325 and your configuration system.
330 </variablelist> <!-- attributes to metadata -->
336 <term>relevance</term>
339 Specifies ICU tokenization and transformation rules
340 for tokens that are used in Pazpar2's relevance ranking.
341 The 'id' attribute is currently not used, and the 'locale'
342 attribute must be set to one of the locale strings
343 defined in ICU. The child elements listed below can be
344 in any order, except the 'index' element which logically
345 belongs to the end of the list. The stated tokenization,
346 transformation and charmapping instructions are performed
347 in order from top to bottom.
349 <variablelist> <!-- Level 2 -->
350 <varlistentry><term>casemap</term>
353 The attribute 'rule' defines the direction of the
354 per-character casemapping, allowed values are "l"
355 (lower), "u" (upper), "t" (title).
359 <varlistentry><term>transform</term>
362 Normalization and transformation of tokens follows
363 the rules defined in the 'rule' attribute. For
364 possible values we refer to the extensive ICU
365 documentation found at the
366 <ulink url="&url.icu.transform;">ICU
367 transformation</ulink> home page. Set filtering
368 principles are explained at the
369 <ulink url="&url.icu.unicode.set;">ICU set and
370 filtering</ulink> page.
374 <varlistentry><term>tokenize</term>
377 Tokenization is the only rule in the ICU chain
378 which splits one token into multiple tokens. The
379 'rule' attribute may have the following values:
380 "s" (sentence), "l" (line-break), "w" (word), and
381 "c" (character), the later probably not being
382 very useful in a pruning Pazpar2 installation.
388 From Pazpar2 version 1.1 the ICU wrapper from YAZ is used.
389 Refer to the <ulink url="&url.yaz.yaz-icu;">yaz-icu</ulink>
390 utility for more information.
399 Specifies ICU tokenization and transformation rules
400 for tokens that are used in Pazpar2's sorting. The contents
401 is similar to that of <literal>relevance</literal>.
407 <term>mergekey</term>
410 Specifies ICU tokenization and transformation rules
411 for tokens that are used in Pazpar2's mergekey. The contents
412 is similar to that of <literal>relevance</literal>.
421 Specifies ICU tokenization and transformation rules
422 for tokens that are used in Pazpar2's facets. The contents
423 is similar to that of <literal>relevance</literal>.
429 <term>settings</term>
432 Specifies target settings for this service. Refer to
433 <xref linkend="target_settings"/>.
442 Specifies timeout parameters for this service.
443 The <literal>timeout</literal>
444 element supports the following attributes:
445 <literal>session</literal>, <literal>z3950_operation</literal>,
446 <literal>z3950_session</literal> which specifies
447 'session timeout', 'Z39.50 operation timeout',
448 'Z39.50 session timeout' respectively. The Z39.50 operation
449 timeout is the time Pazpar2 will wait for an active Z39.50/SRU
450 operation before it gives up (times out). The Z39.50 session
451 time out is the time Pazpar2 will keep the session alive for
452 an idle session (no operation).
455 The following is recommended but not required:
456 z3950_operation (30) < session (60) < z3950_session (180) .
457 The default values are given in parantheses.
462 </variablelist> <!-- Data elements in service directive -->
466 </variablelist> <!-- Data elements in server directive -->
471 <refsect1><title>EXAMPLE</title>
472 <para>Below is a working example configuration:
474 <?xml version="1.0" encoding="UTF-8"?>
475 <pazpar2 xmlns="http://www.indexdata.com/pazpar2/1.0">
477 <threads number="10"/>
479 <listen port="9004"/>
481 <metadata name="title" brief="yes" sortkey="skiparticle"
482 merge="longest" rank="6"/>
483 <metadata name="isbn" merge="unique"/>
484 <metadata name="date" brief="yes" sortkey="numeric"
485 type="year" merge="range" termlist="yes"/>
486 <metadata name="author" brief="yes" termlist="yes"
487 merge="longest" rank="2"/>
488 <metadata name="subject" merge="unique" termlist="yes" rank="3"/>
489 <metadata name="url" merge="unique"/>
491 <icu_chain id="relevance" locale="el">
492 <transform rule="[:Control:] Any-Remove"/>
494 <transform rule="[[:WhiteSpace:][:Punctuation:]] Remove"/>
498 <settings src="mysettings"/>
499 <timeout session="60"/>
507 <refsect1 id="config-include"><title>INCLUDE FACILITY</title>
509 The XML configuration may be partitioned into multiple files by using
510 the <literal>include</literal> element which takes a single attribute,
511 <literal>src</literal>. The of the <literal>src</literal> attribute is
512 regular Shell like glob-pattern. For example,
514 <include src="/etc/pazpar2/conf.d/*.xml"/>
518 The include facility requires Pazpar2 version 1.2.
522 <refsect1 id="target_settings"><title>TARGET SETTINGS</title>
524 Pazpar2 features a cunning scheme by which you can associate various
525 kinds of attributes, or settings with search targets. This can be done
526 through XML files which are read at startup; each file can associate
527 one or more settings with one or more targets. The file format is generic
528 in nature, designed to support a wide range of application requirements. The
529 settings can be purely technical things, like, how to perform a title
530 search against a given target, or it can associate arbitrary name=value
531 pairs with groups of targets -- for instance, if you would like to
532 place all commercial full-text bases in one group for selection
533 purposes, or you would like to control what targets are accessible
534 to users by default. Per-database settings values can even be used
535 to drive sorting, facet/termlist generation, or end-user interface display
540 During startup, Pazpar2 will recursively read a specified directory
541 (can be identified in the pazpar2.cfg file or on the command line), and
542 process any settings files found therein.
546 Clients of the Pazpar2 webservice interface can selectively override
547 settings for individual targets within the scope of one session. This
548 can be used in conjunction with an external authentication system to
549 determine which resources are to be accessible to which users. Pazpar2
550 itself has no notion of end-users, and so can be used in conjunction
551 with any type of authentication system. Similarly, the authentication
552 tokens submitted to access-controlled search targets can similarly be
553 overridden, to allow use of Pazpar2 in a consortial or multi-library
554 environment, where different end-users may need to be represented to
555 some search targets in different ways. This, again, can be managed
556 using an external database or other lookup mechanism. Setting overrides
557 can be performed either using the
558 <link linkend="command-init">init</link> or the
559 <link linkend="command-settings">settings</link> webservice
564 In fact, every setting that applies to a database (except pz:id, which
565 can only be used for filtering targets to use for a search) can be overridden
566 on a per-session basis. This allows the client to override specific CCL fields
567 for searching, etc., to meet the needs of a session or user.
571 Finally, as an extreme case of this, the webservice client can
572 introduce entirely new targets, on the fly, as part of the
573 <link linkend="command-init">init</link> or
574 <link linkend="command-settings">settings</link> command.
575 This is useful if you desire to manage information
576 about your search targets in a separate application such as a database.
577 You do not need any static settings file whatsoever to run Pazpar2 -- as
578 long as the webservice client is prepared to supply the necessary
579 information at the beginning of every session.
584 The following discussion of practical issues related to session and settings
585 management are cast in terms of a user interface based on Ajax/Javascript
586 technology. It would apply equally well to many other kinds of browser-based logic.
591 Typically, a Javascript client is not allowed to directly alter the parameters
592 of a session. There are two reasons for this. One has to do with access
593 to information; typically, information about a user will be stored in a
594 system on the server side, or it will be accessible in some way from the server.
595 However, since the Javascript client cannot be entirely trusted (some hostile
596 agent might in fact 'pretend' to be a regular ws client), it is more robust
597 to control session settings from scripting that you run as part of your
598 webserver. Typically, this can be handled during the session initialization,
603 Step 1: The Javascript client loads, and asks the webserver for a new Pazpar2
604 session ID. This can be done using a Javascript call, for instance. Note that
605 it is possible to submit Ajax HTTPXmlRequest calls either to Pazpar2 or to the
606 webserver that Pazpar2 is proxying for. See (XXX Insert link to Pazpar2 protocol).
610 Step 2: Code on the webserver authenticates the user, by database lookup,
611 LDAP access, NCIP, etc. Determines which resources the user has access to,
612 and any user-specific parameters that are to be applied during this session.
616 Step 3: The webserver initializes a new Pazpar2 settings, and sets user-specific
617 parameters as necessary, using the init webservice command. A new session ID is
622 Step 4: The webserver returns this session ID to the Javascript client, which then
623 uses the session ID to submit searches, show results, etc.
627 Step 5: When the Javascript client ceases to use the session, Pazpar2 destroys
628 any session-specific information.
631 <refsect2><title>SETTINGS FILE FORMAT</title>
633 Each file contains a root element named <settings>. It may
634 contain one or more <set> elements. The settings and set
635 elements may contain the following attributes. Attributes in the set node
636 overrides those in the setting root element. Each set node must
637 specify (directly, or inherited from the parent node) at least a
638 target, name, and value.
646 This specifies the search target to which this setting should be
647 applied. Targets are identified by their Z39.50 URL, generally
648 including the host, port, and database name, (e.g.
649 <literal>bagel.indexdata.com:210/marc</literal>).
650 Two wildcard forms are accepted:
651 * (asterisk) matches all known targets;
652 <literal>bagel.indexdata.com:210/*</literal> matches all
653 known databases on the given host.
656 A precedence system determines what happens if there are
657 overlapping values for the same setting name for the same
658 target. A setting for a specific target name overrides a
659 setting which specifies target using a wildcard. This makes it
660 easy to set defaults for all targets, and then override them
661 for specific targets or hosts. If there are
662 multiple overlapping settings with the same name and target
663 value, the 'precedence' attribute determines what happens.
671 The name of the setting. This can be anything you like.
672 However, Pazpar2 reserves a number of setting names for
673 specific purposes, all starting with 'pz:', and it is a good
674 idea to avoid that prefix if you make up your own setting
675 names. See below for a list of reserved variables.
683 The value of the setting. Generally, this can be anything you
684 want -- however, some of the reserved settings may expect
685 specific kinds of values.
690 <term>precedence</term>
693 This should be an integer. If not provided, the default value
694 is 0. If two (or more) settings have the same content for
695 target and name, the precedence value determines the outcome.
696 If both settings have the same precedence value, they are both
697 applied to the target(s). If one has a higher value, then the
698 value of that setting is applied, and the other one is ignored.
705 By setting defaults for target, name, or value in the root
706 settings node, you can use the settings files in many different
707 ways. For instance, you can use a single file to set defaults for
708 many different settings, like search fields, retrieval syntaxes,
709 etc. You can have one file per server, which groups settings for
710 that server or target. You could also have one file which associates
711 a number of targets with a given setting, for instance, to associate
712 many databases with a given category or class that makes sense
713 within your application.
717 The following examples illustrate uses of the settings system to
718 associate settings with targets to meet different requirements.
722 The example below associates a set of default values that can be
723 used across many targets. Note the wildcard for targets.
724 This associates the given settings with all targets for which no
725 other information is provided.
727 <settings target="*">
729 <!-- This file introduces default settings for pazpar2 -->
731 <!-- mapping for unqualified search -->
732 <set name="pz:cclmap:term" value="u=1016 t=l,r s=al"/>
734 <!-- field-specific mappings -->
735 <set name="pz:cclmap:ti" value="u=4 s=al"/>
736 <set name="pz:cclmap:su" value="u=21 s=al"/>
737 <set name="pz:cclmap:isbn" value="u=7"/>
738 <set name="pz:cclmap:issn" value="u=8"/>
739 <set name="pz:cclmap:date" value="u=30 r=r"/>
741 <!-- Retrieval settings -->
743 <set name="pz:requestsyntax" value="marc21"/>
744 <set name="pz:elements" value="F"/>
746 <!-- Query encoding -->
747 <set name="pz:queryencoding" value="iso-8859-1"/>
749 <!-- Result normalization settings -->
751 <set name="pz:nativesyntax" value="iso2709"/>
752 <set name="pz:xslt" value="../etc/marc21.xsl"/>
760 The next example shows certain settings overridden for one target,
761 one which returns XML records containing DublinCore elements, and
762 which furthermore requires a username/password.
764 <settings target="funkytarget.com:210/db1">
765 <set name="pz:requestsyntax" value="xml"/>
766 <set name="pz:nativesyntax" value="xml"/>
767 <set name="pz:xslt" value="../etc/dublincore.xsl"/>
769 <set name="pz:authentication" value="myuser/password"/>
775 The following example associates a specific name/value combination
776 with a number of targets. The targets below are access-restricted,
777 and can only be used by users with special credentials.
779 <settings name="pz:allow" value="0">
780 <set target="funkytarget.com:210/*"/>
781 <set target="commercial.com:2100/expensiveDb"/>
788 <refsect2><title>RESERVED SETTING NAMES</title>
790 The following setting names are reserved by Pazpar2 to control the
791 behavior of the client function.
796 <term>pz:cclmap:xxx</term>
799 This establishes a CCL field definition or other setting, for
800 the purpose of mapping end-user queries. XXX is the field or
801 setting name, and the value of the setting provides parameters
802 (e.g. parameters to send to the server, etc.). Please consult
803 the YAZ manual for a full overview of the many capabilities of
804 the powerful and flexible CCL parser.
807 Note that it is easy to establish a set of default parameters,
808 and then override them individually for a given target.
812 <varlistentry id="requestsyntax">
813 <term>pz:requestsyntax</term>
816 This specifies the record syntax to use when requesting
817 records from a given server. The value can be a symbolic name like
818 marc21 or xml, or it can be a Z39.50-style dot-separated OID.
823 <term>pz:elements</term>
826 The element set name to be used when retrieving records from a
832 <term>pz:piggyback</term>
835 Piggybacking enables the server to retrieve records from the
836 server as part of the search response in Z39.50. Almost all
837 servers support this (or fail it gracefully), but a few
838 servers will produce undesirable results.
839 Set to '1' to enable piggybacking, '0' to disable it. Default
840 is 1 (piggybacking enabled).
845 <term>pz:nativesyntax</term>
848 Specifies how Pazpar2 shoule map retrieved records to XML. Currently
849 supported values are <literal>xml</literal>,
850 <literal>iso2709</literal> and <literal>txml</literal>.
853 The value <literal>iso2709</literal> makes Pazpar2 convert retrieved
854 MARC records to MARCXML. In order to convert to XML, the exact
855 chacater set of the MARC must be known (if not, the resulting
856 XML is probably not well-formed). The character set may be
858 <literal>;charset=</literal><replaceable>charset</replaceable> to
859 <literal>iso2709</literal>. If omitted, a charset of
860 MARC-8 is assumed. This is correct for most MARC21/USMARC records.
863 The value <literal>txml</literal> is like <literal>iso2709</literal>
864 except that records are converted to TurboMARC instead of MARCXML.
867 The value <literal>xml</literal> is used if Pazpar2 retrieves
868 records that are already XML (no conversion takes place).
874 <term>pz:queryencoding</term>
877 The encoding of the search terms that a target accepts. Most
878 targets do not honor UTF-8 in which case this needs to be specified.
879 Each term in a query will be converted if this setting is given.
885 <term>pz:negotiation_charset</term>
888 Sets character set for Z39.50 negotiation. Most targets do not support
889 this, and some will even close connection if set (crash on server
890 side or similar). If set, you probably want to set it to
891 <literal>UTF-8</literal>.
900 Is a comma separated list of of files that specifies
901 how to convert incoming records to the internal representation.
904 The suffix of each file specifies the kind of tranformation.
905 Suffix "<literal>.xsl</literal>" makes an XSL transform. Suffix
906 "<literal>.mmap</literal>" will use the MMAP transform (described below).
909 The special value "<literal>auto</literal>" will use a file
910 which is the <link linkend="requestsyntax">pz:requestsyntax's</link>
912 <literal>'.xsl'</literal>.
915 When mapping MARC records, XSLT can be bypassed for increased
916 performance with the alternate "MARC map" format. Provide the
917 path of a file with extension ".mmap" containing on each line:
919 <field> <subfield> <metadata element></programlisting>
924 773 * citation</programlisting>
925 To map the field value specify a subfield of '$'. To store a
926 concatenation of all subfields, specify a subfield of '*'.
931 <term>pz:authentication</term>
934 Sets an authentication string for a given server. See the section on
935 authorization and authentication for discussion.
940 <term>pz:allow</term>
943 Allows or denies access to the resources it is applied to. Possible
944 values are '0' and '1'. The default is '1' (allow access to this resource).
945 See the manual section on authorization and authentication for discussion
946 about how to use this setting.
951 <term>pz:maxrecs</term>
954 Controls the maximum number of records to be retrieved from a
955 server. The default is 100.
963 This setting can't be 'set' -- it contains the ID (normally
964 ZURL) for a given target, and is useful for filtering --
965 specifically when you want to select one or more specific
966 targets in the search command.
971 <term>pz:zproxy</term>
974 The 'pz:zproxy' setting has the value syntax
975 'host.internet.adress:port', it is used to tunnel Z39.50
976 requests through the named Z39.50 proxy.
982 <term>pz:apdulog</term>
985 If the 'pz:apdulog' setting is defined and has other value than 0,
986 then Z39.50 APDUs are written to the log.
996 <ulink url="&url.sru;">SRU</ulink>/<ulink url="&url.solr;">SOLR</ulink>
998 It has four possible settings.
999 'get', enables SRU access through GET requests. 'post' enables SRU/POST
1000 support, less commonly supported, but useful if very large requests are
1001 to be submitted. 'srw' enables the SRW (SRU over SOAP) variation of
1005 A value of 'solr' anables SOLR client support. This is supported
1006 for Pazpar version 1.5.0 and later.
1012 <term>pz:sru_version</term>
1015 This allows SRU version to be specified. If unset Pazpar2
1016 will the default of YAZ (currently 1.2). Should be set
1017 to 1.1 or 1.2. For SOLR, the current supported/tested version is 1.4
1023 <term>pz:pqf_prefix</term>
1026 Allows you to specify an arbitrary PQF query language substring.
1027 The provided string is prefixed the user's query after it has been
1028 normalized to PQF internally in pazpar2.
1029 This allows you to attach complex 'filters' to queries for a given
1030 target, sometimes necessary to select sub-catalogs
1031 in union catalog systems, etc.
1037 <term>pz:pqf_strftime</term>
1040 Allows you to extend a query with dates and operators.
1041 The provided string allows certain substitutions and serves as a
1043 The special two character sequence '%%' gets converted to the
1044 original query. Other characters leading with the percent sign are
1045 conversions supported by strftime.
1046 All other characters are copied verbatim. For example, the string
1047 <literal>@and @attr 1=30 @attr 2=3 %Y %%</literal>
1048 would search for current year combined with the original PQF (%%).
1054 <term>pz:sort</term>
1057 Specifies sort criteria to be applied to the result set.
1058 Only works for targets which support the sort service.
1064 <term>pz:recordfilter</term>
1067 Specifies a filter which allows Pazpar2 to only include
1068 records that meet a certain criteria in a result. Unmatched records
1069 will be ignored. The filter takes the form name, name~value, or name=value, which
1070 will include only records with metadata element (name) that has the
1071 substring (~value) given, or matches exactly (=value). If value is omitted all records
1073 metadata element present will be included.
1079 <term>pz:preferred</term>
1082 Specifies that a target is preferred, e.g. possible local, faster target. Using block=pref on show command
1083 will wait for all these targets to return records before releasing the block. If no target is preferred,
1084 the block=pref will identical to block=1, which release when one target has returned records.
1090 <term>pz:block_timeout</term>
1093 (Not yet implemented). Specifies the time for which a block should be released anyway.
1099 <term>pz:facetmap:<replaceable>name</replaceable></term>
1102 Specifies that for field <replaceable>name</replaceable>, the target
1103 supports (native) facets. The value is the name of the
1104 field on the target.
1108 At this point only SOLR targets have been tested with this
1120 <refsect1><title>SEE ALSO</title>
1123 <refentrytitle>pazpar2</refentrytitle>
1124 <manvolnum>8</manvolnum>
1127 <refentrytitle>yaz-icu</refentrytitle>
1128 <manvolnum>1</manvolnum>
1131 <refentrytitle>pazpar2_protocol</refentrytitle>
1132 <manvolnum>7</manvolnum>
1137 <!-- Keep this comment at the end of the file
1142 sgml-minimize-attributes:nil
1143 sgml-always-quote-attributes:t
1146 sgml-parent-document:nil
1147 sgml-local-catalogs: nil
1148 sgml-namecase-general:t