1 <?xml version="1.0" standalone="no"?>
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN"
3 "http://www.oasis-open.org/docbook/xml/4.1/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>
18 <refentrytitle>Pazpar2 conf</refentrytitle>
19 <manvolnum>5</manvolnum>
23 <refname>pazpar2_conf</refname>
24 <refpurpose>Pazpar2 Configuration</refpurpose>
29 <command>pazpar2.conf</command>
33 <refsect1><title>DESCRIPTION</title>
35 The Pazpar2 configuration file, together with any referenced XSLT files,
36 govern Pazpar2's behavior as a client, and control the normalization and
37 extraction of data elements from incoming result records, for the
38 purposes of merging, sorting, facet analysis, and display.
42 The file is specified using the option -f on the Pazpar2 command line.
43 There is not presently a way to reload the configuration file without
44 restarting Pazpar2, although this will most likely be added some time
49 <refsect1><title>FORMAT</title>
51 The configuration file is XML-structured. It must be well-formed XML. All
52 elements specific to Pazpar2 should belong to the namespace
53 <literal>http://www.indexdata.com/pazpar2/1.0</literal>
54 (this is assumed in the
55 following examples). The root element is named <literal>pazpar2</literal>.
56 Under the root element are a number of elements which group categories of
57 information. The categories are described below.
60 <refsect2 id="config-server"><title>server</title>
62 This section governs overall behavior of the server. It is identified
63 by the element "server" which takes an optional attribute, "id", which
64 identifies this particular Pazpar2 server. Any string value for "id"
68 elements are described below. From Pazpar2 version 1.2 this is
71 <variablelist> <!-- level 1 -->
76 Configures the webservice -- this controls how you can connect
77 to Pazpar2 from your browser or server-side code. The
78 attributes 'host' and 'port' control the binding of the
79 server. The 'host' attribute can be used to bind the server to
80 a secondary IP address of your system, enabling you to run
81 Pazpar2 on port 80 alongside a conventional web server. You
82 can override this setting on the command line using the option -h.
91 If this item is given, Pazpar2 will forward all incoming HTTP
92 requests that do not contain the filename 'search.pz2' to the
93 host and port specified using the 'host' and 'port'
94 attributes. The 'myurl' attribute is required, and should provide
95 the base URL of the server. Generally, the HTTP URL for the host
96 specified in the 'listen' parameter. This functionality is
97 crucial if you wish to use
98 Pazpar2 in conjunction with browser-based code (JS, Flash,
99 applets, etc.) which operates in a security sandbox. Such code
100 can only connect to the same server from which the enclosing
101 HTML page originated. Pazpar2s proxy functionality enables you
102 to host all of the main pages (plus images, CSS, etc) of your
103 application on a conventional webserver, while efficiently
104 processing webservice requests for metasearch status, results,
111 <term>relevance / sort / mergekey</term>
114 Specifies character set normalization for relevancy / sorting
115 and the mergekey - for the server. These definitions serves as
116 default for services that don't have these given. For the meaning
117 of these settings refer to the "relevance" element inside service.
123 <term>settings</term>
126 Specifies target settings for the server.. These settings serves
127 as default for all services which don't have these given.
128 The settings element requires one attribute 'src' which specifies
129 a settings file or a directory . If a directory is given all
130 files with suffix <filename>.xml</filename> is read from this
132 <xref linkend="target_settings"/> for more information.
141 This nested element controls the behavior of Pazpar2 with
142 respect to your data model. In Pazpar2, incoming records are
143 normalized, using XSLT, into an internal representation.
144 The 'service' section controls the further processing and
145 extraction of data from the internal representation, primarily
146 through the 'metadata' sub-element.
149 Pazpar2 version 1.2 and later allows multiple service elements.
150 Multiple services must be given a unique ID by specifying
151 attribute <literal>id</literal>.
152 A single service may be unnamed (service ID omitted). The
153 service ID is referred to in the
154 <link linkend="command-init"><literal>init</literal></link> webservice
155 command's <literal>service</literal> parameter.
158 <variablelist> <!-- Level 2 -->
159 <varlistentry><term>metadata</term>
162 One of these elements is required for every data element in
163 the internal representation of the record (see
164 <xref linkend="data_model"/>. It governs
165 subsequent processing as pertains to sorting, relevance
166 ranking, merging, and display of data elements. It supports
167 the following attributes:
170 <variablelist> <!-- level 3 -->
171 <varlistentry><term>name</term>
174 This is the name of the data element. It is matched
175 against the 'type' attribute of the
177 in the normalized record. A warning is produced if
178 metadata elements with an unknown name are
180 normalized record. This name is also used to
182 data elements in the records returned by the
183 webservice API, and to name sort lists and browse
189 <varlistentry><term>type</term>
192 The type of data element. This value governs any
193 normalization or special processing that might take
194 place on an element. Possible values are 'generic'
195 (basic string), 'year' (a range is computed if
196 multiple years are found in the record). Note: This
197 list is likely to increase in the future.
202 <varlistentry><term>brief</term>
205 If this is set to 'yes', then the data element is
206 includes in brief records in the webservice API. Note
207 that this only makes sense for metadata elements that
208 are merged (see below). The default value is 'no'.
213 <varlistentry><term>sortkey</term>
216 Specifies that this data element is to be used for
217 sorting. The possible values are 'numeric' (numeric
218 value), 'skiparticle' (string; skip common, leading
219 articles), and 'no' (no sorting). The default value is
225 <varlistentry><term>rank</term>
228 Specifies that this element is to be used to
230 records against the user's query (when ranking is
231 requested). The value is an integer, used as a
232 multiplier against the basic TF*IDF score. A value of
233 1 is the base, higher values give additional
235 elements of this type. The default is '0', which
236 excludes this element from the rank calculation.
241 <varlistentry><term>termlist</term>
244 Specifies that this element is to be used as a
245 termlist, or browse facet. Values are tabulated from
246 incoming records, and a highscore of values (with
247 their associated frequency) is made available to the
248 client through the webservice API.
250 are 'yes' and 'no' (default).
255 <varlistentry><term>merge</term>
258 This governs whether, and how elements are extracted
259 from individual records and merged into cluster
260 records. The possible values are: 'unique' (include
261 all unique elements), 'longest' (include only the
262 longest element (strlen), 'range' (calculate a range
263 of values across all matching records), 'all' (include
264 all elements), or 'no' (don't merge; this is the
270 <varlistentry><term>mergekey</term>
273 If set to '<literal>required</literal>', the value of this
274 metadata element is appended to the resulting mergekey if
275 the metadata is present in a record instance.
276 If the metadata element is not present, the a unique mergekey
277 will be generated instead.
280 If set to '<literal>optional</literal>', the value of this
281 metadata element is appended to the resulting mergekey if the
282 the metadata is present in a record instance. If the metadata
283 is not present, it will be empty.
286 If set to '<literal>no</literal>' or the mergekey attribute is
287 omitted, the metadata will not be used in the creation of a
293 <varlistentry><term>setting</term>
296 This attribute allows you to make use of static database
297 settings in the processing of records. Three possible values
298 are allowed. 'no' is the default and doesn't do anything.
299 'postproc' copies the value of a setting with the same name
300 into the output of the normalization stylesheet(s). 'parameter'
301 makes the value of a setting with the same name available
302 as a parameter to the normalization stylesheet, so you
303 can further process the value inside of the stylesheet, or use
304 the value to decide how to deal with other data values.
307 The purpose of using settings in this way can either be to
308 control the behavior of normalization stylesheet in a database-
309 dependent way, or to easily make database-dependent values
310 available to display-logic in your user interface, without having
311 to implement complicated interactions between the user interface
312 and your configuration system.
317 </variablelist> <!-- attributes to metadata -->
323 <term>relevance</term>
326 Specifies ICU tokenization and transformation rules
327 for tokens that are used in Pazpar2's relevance ranking.
328 The 'id' attribute is currently not used, and the 'locale'
329 attribute must be set to one of the locale strings
330 defined in ICU. The child elements listed below can be
331 in any order, except the 'index' element which logically
332 belongs to the end of the list. The stated tokenization,
333 transformation and charmapping instructions are performed
334 in order from top to bottom.
336 <variablelist> <!-- Level 2 -->
337 <varlistentry><term>casemap</term>
340 The attribute 'rule' defines the direction of the
341 per-character casemapping, allowed values are "l"
342 (lower), "u" (upper), "t" (title).
346 <varlistentry><term>transform</term>
349 Normalization and transformation of tokens follows
350 the rules defined in the 'rule' attribute. For
351 possible values we refer to the extensive ICU
352 documentation found at the
353 <ulink url="&url.icu.transform;">ICU
354 transformation</ulink> home page. Set filtering
355 principles are explained at the
356 <ulink url="&url.icu.unicode.set;">ICU set and
357 filtering</ulink> page.
361 <varlistentry><term>tokenize</term>
364 Tokenization is the only rule in the ICU chain
365 which splits one token into multiple tokens. The
366 'rule' attribute may have the following values:
367 "s" (sentence), "l" (line-break), "w" (word), and
368 "c" (character), the later probably not being
369 very useful in a pruning Pazpar2 installation.
375 From Pazpar2 version 1.1 the ICU wrapper from YAZ is used.
376 Refer to the <ulink url="&url.yaz.yaz-icu;">yaz-icu</ulink>
377 utility for more information.
386 Specifies ICU tokenization and transformation rules
387 for tokens that are used in Pazpar2's sorting. The contents
388 is similar to that of <literal>relevance</literal>.
394 <term>mergekey</term>
397 Specifies ICU tokenization and transformation rules
398 for tokens that are used in Pazpar2's mergekey. The contents
399 is similar to that of <literal>relevance</literal>.
405 <term>settings</term>
408 Specifies target settings for this service. Refer to
409 <xref linkend="target_settings"/>.
418 Specifies timeout parameters for this service.
419 The <literal>timeout</literal>
420 element supports the following attributes:
421 <literal>session</literal>, <literal>z3950_operation</literal>,
422 <literal>z3950_session</literal> which specifies
423 'session timeout', 'Z39.50 operation timeout',
424 'Z39.50 session timeout' respectively. The Z39.50 operation
425 timeout is the time Pazpar2 will wait for an active Z39.50/SRU
426 operation before it gives up (times out). The Z39.50 session
427 time out is the time Pazpar2 will keep the session alive for
428 an idle session (no operation).
431 The following is recommended but not required:
432 z3950_operation (30) < session (60) < z3950_session (180) .
433 The default values are given in parantheses.
438 </variablelist> <!-- Data elements in service directive -->
442 </variablelist> <!-- Data elements in server directive -->
447 <refsect1><title>EXAMPLE</title>
448 <para>Below is a working example configuration:
450 <?xml version="1.0" encoding="UTF-8"?>
451 <pazpar2 xmlns="http://www.indexdata.com/pazpar2/1.0">
454 <listen port="9004"/>
456 <metadata name="title" brief="yes" sortkey="skiparticle"
457 merge="longest" rank="6"/>
458 <metadata name="isbn" merge="unique"/>
459 <metadata name="date" brief="yes" sortkey="numeric"
460 type="year" merge="range" termlist="yes"/>
461 <metadata name="author" brief="yes" termlist="yes"
462 merge="longest" rank="2"/>
463 <metadata name="subject" merge="unique" termlist="yes" rank="3"/>
464 <metadata name="url" merge="unique"/>
466 <icu_chain id="relevance" locale="el">
467 <transform rule="[:Control:] Any-Remove"/>
469 <transform rule="[[:WhiteSpace:][:Punctuation:]] Remove"/>
473 <settings src="mysettings"/>
474 <timeout session="60"/>
482 <refsect1 id="config-include"><title>INCLUDE FACILITY</title>
484 The XML configuration may be partitioned into multiple files by using
485 the <literal>include</literal> element which takes a single attribute,
486 <literal>src</literal>. The of the <literal>src</literal> attribute is
487 regular Shell like glob-pattern. For example,
489 <include src="/etc/pazpar2/conf.d/*.xml"/>
493 The include facility requires Pazpar2 version 1.2.
497 <refsect1 id="target_settings"><title>TARGET SETTINGS</title>
499 Pazpar2 features a cunning scheme by which you can associate various
500 kinds of attributes, or settings with search targets. This can be done
501 through XML files which are read at startup; each file can associate
502 one or more settings with one or more targets. The file format is generic
503 in nature, designed to support a wide range of application requirements. The
504 settings can be purely technical things, like, how to perform a title
505 search against a given target, or it can associate arbitrary name=value
506 pairs with groups of targets -- for instance, if you would like to
507 place all commercial full-text bases in one group for selection
508 purposes, or you would like to control what targets are accessible
509 to users by default. Per-database settings values can even be used
510 to drive sorting, facet/termlist generation, or end-user interface display
515 During startup, Pazpar2 will recursively read a specified directory
516 (can be identified in the pazpar2.cfg file or on the command line), and
517 process any settings files found therein.
521 Clients of the Pazpar2 webservice interface can selectively override
522 settings for individual targets within the scope of one session. This
523 can be used in conjunction with an external authentication system to
524 determine which resources are to be accessible to which users. Pazpar2
525 itself has no notion of end-users, and so can be used in conjunction
526 with any type of authentication system. Similarly, the authentication
527 tokens submitted to access-controlled search targets can similarly be
528 overridden, to allow use of Pazpar2 in a consortial or multi-library
529 environment, where different end-users may need to be represented to
530 some search targets in different ways. This, again, can be managed
531 using an external database or other lookup mechanism. Setting overrides
532 can be performed either using the
533 <link linkend="command-init">init</link> or the
534 <link linkend="command-settings">settings</link> webservice
539 In fact, every setting that applies to a database (except pz:id, which
540 can only be used for filtering targets to use for a search) can be overridden
541 on a per-session basis. This allows the client to override specific CCL fields
542 for searching, etc., to meet the needs of a session or user.
546 Finally, as an extreme case of this, the webservice client can
547 introduce entirely new targets, on the fly, as part of the
548 <link linkend="command-init">init</link> or
549 <link linkend="command-settings">settings</link> command.
550 This is useful if you desire to manage information
551 about your search targets in a separate application such as a database.
552 You do not need any static settings file whatsoever to run Pazpar2 -- as
553 long as the webservice client is prepared to supply the necessary
554 information at the beginning of every session.
559 The following discussion of practical issues related to session and settings
560 management are cast in terms of a user interface based on Ajax/Javascript
561 technology. It would apply equally well to many other kinds of browser-based logic.
566 Typically, a Javascript client is not allowed to directly alter the parameters
567 of a session. There are two reasons for this. One has to do with access
568 to information; typically, information about a user will be stored in a
569 system on the server side, or it will be accessible in some way from the server.
570 However, since the Javascript client cannot be entirely trusted (some hostile
571 agent might in fact 'pretend' to be a regular ws client), it is more robust
572 to control session settings from scripting that you run as part of your
573 webserver. Typically, this can be handled during the session initialization,
578 Step 1: The Javascript client loads, and asks the webserver for a new Pazpar2
579 session ID. This can be done using a Javascript call, for instance. Note that
580 it is possible to submit Ajax HTTPXmlRequest calls either to Pazpar2 or to the
581 webserver that Pazpar2 is proxying for. See (XXX Insert link to Pazpar2 protocol).
585 Step 2: Code on the webserver authenticates the user, by database lookup,
586 LDAP access, NCIP, etc. Determines which resources the user has access to,
587 and any user-specific parameters that are to be applied during this session.
591 Step 3: The webserver initializes a new Pazpar2 settings, and sets user-specific
592 parameters as necessary, using the init webservice command. A new session ID is
597 Step 4: The webserver returns this session ID to the Javascript client, which then
598 uses the session ID to submit searches, show results, etc.
602 Step 5: When the Javascript client ceases to use the session, Pazpar2 destroys
603 any session-specific information.
606 <refsect2><title>SETTINGS FILE FORMAT</title>
608 Each file contains a root element named <settings>. It may
609 contain one or more <set> elements. The settings and set
610 elements may contain the following attributes. Attributes in the set node
611 overrides those in the setting root element. Each set node must
612 specify (directly, or inherited from the parent node) at least a
613 target, name, and value.
621 This specifies the search target to which this setting should be
622 applied. Targets are identified by their Z39.50 URL, generally
623 including the host, port, and database name, (e.g.
624 <literal>bagel.indexdata.com:210/marc</literal>).
625 Two wildcard forms are accepted:
626 * (asterisk) matches all known targets;
627 <literal>bagel.indexdata.com:210/*</literal> matches all
628 known databases on the given host.
631 A precedence system determines what happens if there are
632 overlapping values for the same setting name for the same
633 target. A setting for a specific target name overrides a
634 setting which specifies target using a wildcard. This makes it
635 easy to set defaults for all targets, and then override them
636 for specific targets or hosts. If there are
637 multiple overlapping settings with the same name and target
638 value, the 'precedence' attribute determines what happens.
646 The name of the setting. This can be anything you like.
647 However, Pazpar2 reserves a number of setting names for
648 specific purposes, all starting with 'pz:', and it is a good
649 idea to avoid that prefix if you make up your own setting
650 names. See below for a list of reserved variables.
658 The value of the setting. Generally, this can be anything you
659 want -- however, some of the reserved settings may expect
660 specific kinds of values.
665 <term>precedence</term>
668 This should be an integer. If not provided, the default value
669 is 0. If two (or more) settings have the same content for
670 target and name, the precedence value determines the outcome.
671 If both settings have the same precedence value, they are both
672 applied to the target(s). If one has a higher value, then the
673 value of that setting is applied, and the other one is ignored.
680 By setting defaults for target, name, or value in the root
681 settings node, you can use the settings files in many different
682 ways. For instance, you can use a single file to set defaults for
683 many different settings, like search fields, retrieval syntaxes,
684 etc. You can have one file per server, which groups settings for
685 that server or target. You could also have one file which associates
686 a number of targets with a given setting, for instance, to associate
687 many databases with a given category or class that makes sense
688 within your application.
692 The following examples illustrate uses of the settings system to
693 associate settings with targets to meet different requirements.
697 The example below associates a set of default values that can be
698 used across many targets. Note the wildcard for targets.
699 This associates the given settings with all targets for which no
700 other information is provided.
702 <settings target="*">
704 <!-- This file introduces default settings for pazpar2 -->
706 <!-- mapping for unqualified search -->
707 <set name="pz:cclmap:term" value="u=1016 t=l,r s=al"/>
709 <!-- field-specific mappings -->
710 <set name="pz:cclmap:ti" value="u=4 s=al"/>
711 <set name="pz:cclmap:su" value="u=21 s=al"/>
712 <set name="pz:cclmap:isbn" value="u=7"/>
713 <set name="pz:cclmap:issn" value="u=8"/>
714 <set name="pz:cclmap:date" value="u=30 r=r"/>
716 <!-- Retrieval settings -->
718 <set name="pz:requestsyntax" value="marc21"/>
719 <set name="pz:elements" value="F"/>
721 <!-- Query encoding -->
722 <set name="pz:queryencoding" value="iso-8859-1"/>
724 <!-- Result normalization settings -->
726 <set name="pz:nativesyntax" value="iso2709"/>
727 <set name="pz:xslt" value="../etc/marc21.xsl"/>
735 The next example shows certain settings overridden for one target,
736 one which returns XML records containing DublinCore elements, and
737 which furthermore requires a username/password.
739 <settings target="funkytarget.com:210/db1">
740 <set name="pz:requestsyntax" value="xml"/>
741 <set name="pz:nativesyntax" value="xml"/>
742 <set name="pz:xslt" value="../etc/dublincore.xsl"/>
744 <set name="pz:authentication" value="myuser/password"/>
750 The following example associates a specific name/value combination
751 with a number of targets. The targets below are access-restricted,
752 and can only be used by users with special credentials.
754 <settings name="pz:allow" value="0">
755 <set target="funkytarget.com:210/*"/>
756 <set target="commercial.com:2100/expensiveDb"/>
763 <refsect2><title>RESERVED SETTING NAMES</title>
765 The following setting names are reserved by Pazpar2 to control the
766 behavior of the client function.
771 <term>pz:cclmap:xxx</term>
774 This establishes a CCL field definition or other setting, for
775 the purpose of mapping end-user queries. XXX is the field or
776 setting name, and the value of the setting provides parameters
777 (e.g. parameters to send to the server, etc.). Please consult
778 the YAZ manual for a full overview of the many capabilities of
779 the powerful and flexible CCL parser.
782 Note that it is easy to establish a set of default parameters,
783 and then override them individually for a given target.
787 <varlistentry id="requestsyntax">
788 <term>pz:requestsyntax</term>
791 This specifies the record syntax to use when requesting
792 records from a given server. The value can be a symbolic name like
793 marc21 or xml, or it can be a Z39.50-style dot-separated OID.
798 <term>pz:elements</term>
801 The element set name to be used when retrieving records from a
807 <term>pz:piggyback</term>
810 Piggybacking enables the server to retrieve records from the
811 server as part of the search response in Z39.50. Almost all
812 servers support this (or fail it gracefully), but a few
813 servers will produce undesirable results.
814 Set to '1' to enable piggybacking, '0' to disable it. Default
815 is 1 (piggybacking enabled).
820 <term>pz:nativesyntax</term>
823 The representation (syntax) of the retrieval records. Currently
824 recognized values are iso2709 and xml.
827 For iso2709, can also specify a native character set, e.g. "iso2709;latin-1".
828 If no character set is provided, MARC-8 is assumed.
831 If pz:nativesyntax is not specified, pazpar2 will attempt to determine
832 the value based on the response from the server.
838 <term>pz:queryencoding</term>
841 The encoding of the search terms that a target accepts. Most
842 targets do not honor UTF-8 in which case this needs to be specified.
843 Each term in a query will be converted if this setting is given.
849 <term>pz:negotiation_charset</term>
852 Sets character set for Z39.50 negotiation. Most targets do not support
853 this, and some will even close connection if set (crash on server
854 side or similar). If set, you probably want to set it to
855 <literal>UTF-8</literal>.
864 Is a comma separated list of of files that specifies
865 how to convert incoming records to the internal representation.
868 The suffix of each file specifies the kind of tranformation.
869 Suffix "<literal>.xsl</literal>" makes an XSL transform. Suffix
870 "<literal>.mmap</literal>" will use the MMAP transform (described below).
873 The special value "<literal>auto</literal>" will use a file
874 which is the <link linkend="requestsyntax">pz:requestsyntax's</link>
876 <literal>'.xsl'</literal>.
879 When mapping MARC records, XSLT can be bypassed for increased
880 performance with the alternate "MARC map" format. Provide the
881 path of a file with extension ".mmap" containing on each line:
883 <field> <subfield> <metadata element></programlisting>
888 773 * citation</programlisting>
889 To map the field value specify a subfield of '$'. To store a
890 concatenation of all subfields, specify a subfield of '*'.
895 <term>pz:authentication</term>
898 Sets an authentication string for a given server. See the section on
899 authorization and authentication for discussion.
904 <term>pz:allow</term>
907 Allows or denies access to the resources it is applied to. Possible
908 values are '0' and '1'. The default is '1' (allow access to this resource).
909 See the manual section on authorization and authentication for discussion
910 about how to use this setting.
915 <term>pz:maxrecs</term>
918 Controls the maximum number of records to be retrieved from a
919 server. The default is 100.
927 This setting can't be 'set' -- it contains the ID (normally
928 ZURL) for a given target, and is useful for filtering --
929 specifically when you want to select one or more specific
930 targets in the search command.
935 <term>pz:zproxy</term>
938 The 'pz:zproxy' setting has the value syntax
939 'host.internet.adress:port', it is used to tunnel Z39.50
940 requests through the named Z39.50 proxy.
946 <term>pz:apdulog</term>
949 If the 'pz:apdulog' setting is defined and has other value than 0,
950 then Z39.50 APDUs are written to the log.
959 This setting enables SRU/SRW support. It has three possible settings.
960 'get', enables SRU access through GET requests. 'post' enables SRU/POST
961 support, less commonly supported, but useful if very large requests are
962 to be submitted. 'srw' enables the SRW variation of the protocol.
968 <term>pz:sru_version</term>
971 This allows SRU version to be specified. If unset Pazpar2
972 will the default of YAZ (currently 1.2). Should be set
979 <term>pz:pqf_prefix</term>
982 Allows you to specify an arbitrary PQF query language substring.
983 The provided string is prefixed the user's query after it has been
984 normalized to PQF internally in pazpar2.
985 This allows you to attach complex 'filters' to queries for a given
986 target, sometimes necessary to select sub-catalogs
987 in union catalog systems, etc.
993 <term>pz:pqf_strftime</term>
996 Allows you to extend a query with dates and operators.
997 The provided string allows certain substitutions and serves as a
999 The special two character sequence '%%' gets converted to the
1000 original query. Other characters leading with the percent sign are
1001 conversions supported by strftime.
1002 All other characters are copied verbatim. For example, the string
1003 <literal>@and @attr 1=30 @attr 2=3 %Y %%</literal>
1004 would search for current year combined with the original PQF (%%).
1010 <term>pz:sort</term>
1013 Specifies sort criteria to be applied to the result set.
1014 Only works for targets which support the sort service.
1020 <term>pz:recordfilter</term>
1023 Specifies a filter which allows Pazpar2 to only include
1024 records that meet a certain criteria in a result. Unmatched records
1025 will be ignored. The filter takes the form name[~value] , which
1026 will include only records with metadata element (name) that has the
1027 substring (value) given. If value is omitted all records with the
1028 metadata present will be included.
1037 <refsect1><title>SEE ALSO</title>
1040 <refentrytitle>pazpar2</refentrytitle>
1041 <manvolnum>8</manvolnum>
1044 <refentrytitle>yaz-icu</refentrytitle>
1045 <manvolnum>1</manvolnum>
1048 <refentrytitle>pazpar2_protocol</refentrytitle>
1049 <manvolnum>7</manvolnum>
1054 <!-- Keep this comment at the end of the file
1059 sgml-minimize-attributes:nil
1060 sgml-always-quote-attributes:t
1063 sgml-parent-document:nil
1064 sgml-local-catalogs: nil
1065 sgml-namecase-general:t