<chapter id="grs">
- <!-- $Id: recordmodel-grs.xml,v 1.4 2006-09-03 21:37:27 adam Exp $ -->
- <title>GRS Record Model and Filter Modules</title>
+ <title>&acro.grs1; Record Model and Filter Modules</title>
+
+ <note>
+ <para>
+ The functionality of this record model has been improved and
+ replaced by the DOM &acro.xml; record model. See
+ <xref linkend="record-model-domxml"/>.
+ </para>
+ </note>
<para>
The record model described in this chapter applies to the fundamental,
<section id="grs-filters">
- <title>GRS Record Filters</title>
+ <title>&acro.grs1; Record Filters</title>
<para>
Many basic subtypes of the <emphasis>grs</emphasis> type are
currently available:
<para>
This is the canonical input format
described <xref linkend="grs-canonical-format"/>. It is using
- simple SGML-like syntax.
+ simple &acro.sgml;-like syntax.
</para>
</listitem>
</varlistentry>
<term><literal>grs.marc.</literal><replaceable>type</replaceable></term>
<listitem>
<para>
- This allows Zebra to read
- records in the ISO2709 (MARC) encoding standard.
+ This allows &zebra; to read
+ records in the ISO2709 (&acro.marc;) encoding standard.
Last parameter <replaceable>type</replaceable> names the
<literal>.abs</literal> file (see below)
- which describes the specific MARC structure of the input record as
+ which describes the specific &acro.marc; structure of the input record as
well as the indexing rules.
</para>
- <para>The <literal>grs.marc</literal> uses an internal represtantion
- which is not XML conformant. In particular MARC tags are
- presented as elements with the same name. And XML elements
+ <para>The <literal>grs.marc</literal> uses an internal representation
+ which is not &acro.xml; conformant. In particular &acro.marc; tags are
+ presented as elements with the same name. And &acro.xml; elements
may not start with digits. Therefore this filter is only
- suitable for systems returning GRS-1 and MARC records. For XML
+ suitable for systems returning &acro.grs1; and &acro.marc; records. For &acro.xml;
use <literal>grs.marcxml</literal> filter instead (see below).
</para>
<para>
- The loadable <literal>grs.marc</literal> filter module
- is packaged in the GNU/Debian package
+ The loadable <literal>grs.marc</literal> filter module
+ is packaged in the GNU/Debian package
<literal>libidzebra2.0-mod-grs-marc</literal>
</para>
</listitem>
<term><literal>grs.marcxml.</literal><replaceable>type</replaceable></term>
<listitem>
<para>
- This allows Zebra to read ISO2709 encoded records.
+ This allows &zebra; to read ISO2709 encoded records.
Last parameter <replaceable>type</replaceable> names the
<literal>.abs</literal> file (see below)
- which describes the specific MARC structure of the input record as
+ which describes the specific &acro.marc; structure of the input record as
well as the indexing rules.
</para>
<para>
The internal representation for <literal>grs.marcxml</literal>
- is the same as for <ulink url="&url.marcxml;">MARCXML</ulink>.
- It slightly more complicated to work with than
- <literal>grs.marc</literal> but XML conformant.
+ is the same as for <ulink url="&url.marcxml;">&acro.marcxml;</ulink>.
+ It slightly more complicated to work with than
+ <literal>grs.marc</literal> but &acro.xml; conformant.
</para>
<para>
The loadable <literal>grs.marcxml</literal> filter module
<term><literal>grs.xml</literal></term>
<listitem>
<para>
- This filter reads XML records and uses
+ This filter reads &acro.xml; records and uses
<ulink url="http://expat.sourceforge.net/">Expat</ulink> to
- parse them and convert them into IDZebra's internal
+ parse them and convert them into ID&zebra;'s internal
<literal>grs</literal> record model.
- Only one record per file is supported, due to the fact XML does
+ Only one record per file is supported, due to the fact &acro.xml; does
not allow two documents to "follow" each other (there is no way
to know when a document is finished).
- This filter is only available if Zebra is compiled with EXPAT support.
+ This filter is only available if &zebra; is compiled with EXPAT support.
</para>
<para>
The loadable <literal>grs.xml</literal> filter module
- is packagged in the GNU/Debian package
+ is packaged in the GNU/Debian package
<literal>libidzebra2.0-mod-grs-xml</literal>
- </para>
+ </para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>grs.tcl.</literal><replaceable>filter</replaceable></term>
<listitem>
<para>
- Similar to grs.regx but using Tcl for rules, described in
+ Similar to grs.regx but using Tcl for rules, described in
<xref linkend="grs-regx-tcl"/>.
</para>
<para>
</para>
<section id="grs-canonical-format">
- <title>GRS Canonical Input Format</title>
+ <title>&acro.grs1; Canonical Input Format</title>
<para>
Although input data can take any form, it is sometimes useful to
describe the record processing capabilities of the system in terms of
a single, canonical input format that gives access to the full
- spectrum of structure and flexibility in the system. In Zebra, this
- canonical format is an "SGML-like" syntax.
+ spectrum of structure and flexibility in the system. In &zebra;, this
+ canonical format is an "&acro.sgml;-like" syntax.
</para>
<para>
<screen>
<Distributor>
- <Name> USGS/WRD </Name>
- <Organization> USGS/WRD </Organization>
- <Street-Address>
- U.S. GEOLOGICAL SURVEY, 505 MARQUETTE, NW
- </Street-Address>
- <City> ALBUQUERQUE </City>
- <State> NM </State>
- <Zip-Code> 87102 </Zip-Code>
- <Country> USA </Country>
- <Telephone> (505) 766-5560 </Telephone>
+ <Name> USGS/WRD </Name>
+ <Organization> USGS/WRD </Organization>
+ <Street-Address>
+ U.S. GEOLOGICAL SURVEY, 505 MARQUETTE, NW
+ </Street-Address>
+ <City> ALBUQUERQUE </City>
+ <State> NM </State>
+ <Zip-Code> 87102 </Zip-Code>
+ <Country> USA </Country>
+ <Telephone> (505) 766-5560 </Telephone>
</Distributor>
</screen>
<!-- There is no indentation in the example above! -H
-note-
- -para-
- The indentation used above is used to illustrate how Zebra
- interprets the mark-up. The indentation, in itself, has no
- significance to the parser for the canonical input format, which
- discards superfluous whitespace.
- -/para-
+ -para-
+ The indentation used above is used to illustrate how &zebra;
+ interprets the mark-up. The indentation, in itself, has no
+ significance to the parser for the canonical input format, which
+ discards superfluous whitespace.
+ -/para-
-/note-
-->
The following is a GILS record that
contains only a single element (strictly speaking, that makes it an
illegal GILS record, since the GILS profile includes several mandatory
- elements - Zebra does not validate the contents of a record against
- the Z39.50 profile, however - it merely attempts to match up elements
+ elements - &zebra; does not validate the contents of a record against
+ the &acro.z3950; profile, however - it merely attempts to match up elements
of a local representation with the given schema):
</para>
<screen>
<gils>
- <title>Zen and the Art of Motorcycle Maintenance</title>
+ <title>Zen and the Art of Motorcycle Maintenance</title>
</gils>
</screen>
<title>Variants</title>
<para>
- Zebra allows you to provide individual data elements in a number of
+ &zebra; allows you to provide individual data elements in a number of
<emphasis>variant forms</emphasis>. Examples of variant forms are
textual data elements which might appear in different languages, and
images which may appear in different formats or layouts.
- The variant system in Zebra is essentially a representation of
- the variant mechanism of Z39.50-1995.
+ The variant system in &zebra; is essentially a representation of
+ the variant mechanism of &acro.z3950;-1995.
</para>
<para>
<para>
The title element above comes in two variants. Both have the IANA body
type "text/plain", but one is in English, and the other in
- Danish. The client, using the element selection mechanism of Z39.50,
+ Danish. The client, using the element selection mechanism of &acro.z3950;,
can retrieve information about the available variant forms of data
elements, or it can select specific variants based on the requirements
of the end-user.
</section>
<section id="grs-regx-tcl">
- <title>GRS REGX And TCL Input Filters</title>
+ <title>&acro.grs1; REGX And TCL Input Filters</title>
<para>
- In order to handle general input formats, Zebra allows the
+ In order to handle general input formats, &zebra; allows the
operator to define filters which read individual records in their
native format and produce an internal representation that the system
can work with.
type <literal>regx</literal>, argument
<emphasis>filter-filename</emphasis>).
</para>
-
+
<para>
Generally, an input filter consists of a sequence of rules, where each
rule consists of a sequence of expressions, followed by an action. The
and the actions normally contribute to the generation of an internal
representation of the record.
</para>
-
+
<para>
An expression can be either of the following:
</para>
<variablelist>
<varlistentry>
- <term>INIT</term>
+ <term><literal>INIT</literal></term>
<listitem>
<para>
The action associated with this expression is evaluated
</listitem>
</varlistentry>
<varlistentry>
- <term>BEGIN</term>
+ <term><literal>BEGIN</literal></term>
<listitem>
<para>
Matches the beginning of the record. It can be used to
</listitem>
</varlistentry>
<varlistentry>
- <term>END</term>
+ <term><literal>END</literal></term>
<listitem>
<para>
Matches the end of the record - when all of the contents
</listitem>
</varlistentry>
<varlistentry>
- <term>/pattern/</term>
+ <term>
+ <literal>/</literal><replaceable>reg</replaceable><literal>/</literal>
+ </term>
<listitem>
<para>
- Matches a string of characters from the input record.
+ Matches regular expression pattern <replaceable>reg</replaceable>
+ from the input record. The operators supported are the same
+ as for regular expression queries. Refer to
+ <xref linkend="querymodel-regular"/>.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>BODY</term>
+ <term><literal>BODY</literal></term>
<listitem>
<para>
This keyword may only be used between two patterns.
</listitem>
</varlistentry>
<varlistentry>
- <term>FINISH</term>
+ <term><literal>FINISH</literal></term>
<listitem>
<para>
The expression associated with this pattern is evaluated
data element. The <replaceable>type</replaceable> is one of
the following:
<variablelist>
-
+
<varlistentry>
<term>record</term>
<listitem>
<para>
Begin a new record. The following parameter should be the
- name of the schema that describes the structure of the record, eg.
+ name of the schema that describes the structure of the record, e.g.,
<literal>gils</literal> or <literal>wais</literal> (see below).
The <literal>begin record</literal> call should precede
any other use of the <replaceable>begin</replaceable> statement.
/^Subject:/ BODY /$/ { data -element title $1 }
/^Date:/ BODY /$/ { data -element lastModified $1 }
/\n\n/ BODY END {
- begin element bodyOfDisplay
- begin variant body iana "text/plain"
- data -text $1
- end record
+ begin element bodyOfDisplay
+ begin variant body iana "text/plain"
+ data -text $1
+ end record
}
</screen>
</para>
<para>
- If Zebra is compiled with support for Tcl enabled, the statements
+ If &zebra; is compiled with support for Tcl enabled, the statements
described above are supplemented with a complete
scripting environment, including control structures (conditional
expressions and loop constructs), and powerful string manipulation
</section>
<section id="grs-internal-representation">
- <title>GRS Internal Record Representation</title>
+ <title>&acro.grs1; Internal Record Representation</title>
<para>
When records are manipulated by the system, they're represented in a
<para>
<screen>
- ROOT
- TITLE "Zen and the Art of Motorcycle Maintenance"
- AUTHOR "Robert Pirsig"
+ ROOT
+ TITLE "Zen and the Art of Motorcycle Maintenance"
+ AUTHOR "Robert Pirsig"
</screen>
</para>
<para>
<screen>
- ROOT
- TITLE "Zen and the Art of Motorcycle Maintenance"
- AUTHOR
- FIRST-NAME "Robert"
- SURNAME "Pirsig"
+ ROOT
+ TITLE "Zen and the Art of Motorcycle Maintenance"
+ AUTHOR
+ FIRST-NAME "Robert"
+ SURNAME "Pirsig"
</screen>
</para>
Which of the two elements are transmitted to the client by the server
depends on the specifications provided by the client, if any.
</para>
-
+
<para>
In practice, each variant node is associated with a triple of class,
- type, value, corresponding to the variant mechanism of Z39.50.
+ type, value, corresponding to the variant mechanism of &acro.z3950;.
</para>
-
+
</section>
-
+
<section id="grs-data-elements">
<title>Data Elements</title>
-
+
<para>
Data nodes have no children (they are always leaf nodes in the record
tree).
</para>
-
+
<!--
FIXME! Documentation needs extension here about types of nodes - numerical,
textual, etc., plus the various types of inclusion notes.
</para>
-->
-
+
</section>
-
+
</section>
-
+
<section id="grs-conf">
- <title>GRS Record Model Configuration</title>
-
+ <title>&acro.grs1; Record Model Configuration</title>
+
<para>
The following sections describe the configuration files that govern
- the internal management of <literal>grs</literal> records.
+ the internal management of <literal>grs</literal> records.
The system searches for the files
in the directories specified by the <emphasis>profilePath</emphasis>
setting in the <literal>zebra.cfg</literal> file.
</para>
<!--
- FIXME - Need a diagram here, or a simple explanation how it all hangs together -H
+ FIXME - Need a diagram here, or a simple explanation how it all hangs together -H
-->
<para>
<listitem>
<para>
- The object identifier of the Z39.50 schema associated
+ The object identifier of the &acro.z3950; schema associated
with the ARS, so that it can be referred to by the client.
</para>
</listitem>
known.
</para>
</listitem>
-
+
<listitem>
<para>
The variant set which is used in the profile. This provides a
ask for a subset of the data elements contained in a record. Element
set names, in the retrieval module, are mapped to <emphasis>element
specifications</emphasis>, which contain information equivalent to the
- <emphasis>Espec-1</emphasis> syntax of Z39.50.
+ <emphasis>Espec-1</emphasis> syntax of &acro.z3950;.
</para>
</listitem>
<listitem>
<para>
Possibly, a set of rules describing the mapping of elements to a
- MARC representation.
+ &acro.marc; representation.
</para>
</listitem>
- <listitem>
+ <listitem>
<para>
A list of element descriptions (this is the actual ARS of the
- schema, in Z39.50 terms), which lists the ways in which the various
+ schema, in &acro.z3950; terms), which lists the ways in which the various
tags can be used and organized hierarchically.
</para>
</listitem>
<para>
The number of different file types may appear daunting at first, but
- each type corresponds fairly clearly to a single aspect of the Z39.50
+ each type corresponds fairly clearly to a single aspect of the &acro.z3950;
retrieval facilities. Further, the average database administrator,
who is simply reusing an existing profile for which tables already
exist, shouldn't have to worry too much about the contents of these tables.
file. Some settings are optional (o), while others again are
mandatory (m).
</para>
-
+
</section>
-
+
<section id="abs-file">
<title>The Abstract Syntax (.abs) Files</title>
-
+
<para>
- The name of this file type is slightly misleading in Z39.50 terms,
+ The name of this file type is slightly misleading in &acro.z3950; terms,
since, apart from the actual abstract syntax of the profile, it also
includes most of the other definitions that go into a database
profile.
</para>
-
+
<para>
- When a record in the canonical, SGML-like format is read from a file
+ When a record in the canonical, &acro.sgml;-like format is read from a file
or from the database, the first tag of the file should reference the
profile that governs the layout of the record. If the first tag of the
record is, say, <literal><gils></literal>, the system will look
for the profile definition in the file <literal>gils.abs</literal>.
Profile definitions are cached, so they only have to be read once
- during the lifespan of the current process.
+ during the lifespan of the current process.
</para>
<para>
introduces the profile, and should always be called first thing when
introducing a new record.
</para>
-
+
<para>
The file may contain the following directives:
</para>
-
+
<para>
<variablelist>
-
+
<varlistentry>
<term>name <replaceable>symbolic-name</replaceable></term>
<listitem>
<para>
(m) The reference name of the OID for the profile.
The reference names can be found in the <emphasis>util</emphasis>
- module of YAZ.
+ module of &yaz;.
</para>
</listitem>
</varlistentry>
<para>
(o) Points to a file containing parameters
for representing the record contents in the ISO2709 syntax.
- Read the description of the MARC representation facility below.
+ Read the description of the &acro.marc; representation facility below.
</para>
</listitem>
</varlistentry>
<para>
(o,r) Adds an element to the abstract record syntax of the schema.
The <replaceable>path</replaceable> follows the
- syntax which is suggested by the Z39.50 document - that is, a sequence
+ syntax which is suggested by the &acro.z3950; document - that is, a sequence
of tags separated by slashes (/). Each tag is given as a
comma-separated pair of tag type and -value surrounded by parenthesis.
The <replaceable>name</replaceable> is the name of the element, and
</para>
</listitem>
</varlistentry>
-
+
<varlistentry>
<term>xelm <replaceable>xpath attributes</replaceable></term>
<listitem>
<term>melm <replaceable>field$subfield attributes</replaceable></term>
<listitem>
<para>
- This directive is specifically for MARC-formatted records,
- ingested either in the form of MARCXML documents, or in the
+ This directive is specifically for &acro.marc;-formatted records,
+ ingested either in the form of &acro.marcxml; documents, or in the
ISO2709/Z39.2 format using the grs.marcxml input filter. You can
specify indexing rules for any subfield, or you can leave off the
<replaceable>$subfield</replaceable> part and specify default rules
<listitem>
<para>
This directive specifies character encoding for external records.
- For records such as XML that specifies encoding within the
+ For records such as &acro.xml; that specifies encoding within the
file via a header this directive is ignored.
If neither this directive is given, nor an encoding is set
within external records, ISO-8859-1 encoding is assumed.
- </para>
+ </para>
</listitem>
</varlistentry>
<varlistentry>
<para>
If this directive is followed by <literal>enable</literal>,
then extra indexing is performed to allow for XPath-like queries.
- If this directive is not specified - equivalent to
+ If this directive is not specified - equivalent to
<literal>disable</literal> - no extra XPath-indexing is performed.
</para>
</listitem>
</varlistentry>
- <!-- Adam's version
+ <!-- Adam's version
<varlistentry>
- <term>systag <replaceable>systemtag</replaceable> <replaceable>element</replaceable></term>
- <listitem>
- <para>
- This directive maps system information to an element during
- retrieval. This information is dynamically created. The
- following system tags are defined
- <variablelist>
- <varlistentry>
- <term>size</term>
- <listitem>
- <para>
- Size of record in bytes. By default this
- is mapped to element <literal>size</literal>.
- </para>
- </listitem>
- </varlistentry>
+ <term>systag <replaceable>systemtag</replaceable> <replaceable>element</replaceable></term>
+ <listitem>
+ <para>
+ This directive maps system information to an element during
+ retrieval. This information is dynamically created. The
+ following system tags are defined
+ <variablelist>
+ <varlistentry>
+ <term>size</term>
+ <listitem>
+ <para>
+ Size of record in bytes. By default this
+ is mapped to element <literal>size</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
- <varlistentry>
- <term>rank</term>
- <listitem>
- <para>
- Score/rank of record. By default this
- is mapped to element <literal>rank</literal>.
- If no score was calculated for the record (non-ranked
- searched) search this directive is ignored.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>sysno</term>
- <listitem>
- <para>
- Zebra's system number (record ID) for the
- record. By default this is mapped to element
- <literal>localControlNumber</literal>.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- If you do not want a particular system tag to be applied,
- then set the resulting element to something undefined in the
- abs file (such as <literal>none</literal>).
- </para>
- </listitem>
- </varlistentry>
+ <varlistentry>
+ <term>rank</term>
+ <listitem>
+ <para>
+ Score/rank of record. By default this
+ is mapped to element <literal>rank</literal>.
+ If no score was calculated for the record (non-ranked
+ searched) search this directive is ignored.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>sysno</term>
+ <listitem>
+ <para>
+ &zebra;'s system number (record ID) for the
+ record. By default this is mapped to element
+ <literal>localControlNumber</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ If you do not want a particular system tag to be applied,
+ then set the resulting element to something undefined in the
+ abs file (such as <literal>none</literal>).
+ </para>
+ </listitem>
+ </varlistentry>
-->
<!-- Mike's version -->
</term>
<listitem>
<para>
- Specifies what information, if any, Zebra should
- automatically include in retrieval records for the
+ Specifies what information, if any, &zebra; should
+ automatically include in retrieval records for the
``system fields'' that it supports.
<replaceable>systemTag</replaceable> may
be any of the following:
<varlistentry>
<term><literal>rank</literal></term>
<listitem><para>
- An integer indicating the relevance-ranking score
- assigned to the record.
- </para></listitem>
+ An integer indicating the relevance-ranking score
+ assigned to the record.
+ </para></listitem>
</varlistentry>
<varlistentry>
<term><literal>sysno</literal></term>
<listitem><para>
- An automatically generated identifier for the record,
- unique within this database. It is represented by the
- <literal><localControlNumber></literal> element in
- XML and the <literal>(1,14)</literal> tag in GRS-1.
- </para></listitem>
+ An automatically generated identifier for the record,
+ unique within this database. It is represented by the
+ <literal><localControlNumber></literal> element in
+ &acro.xml; and the <literal>(1,14)</literal> tag in &acro.grs1;.
+ </para></listitem>
</varlistentry>
<varlistentry>
<term><literal>size</literal></term>
<listitem><para>
- The size, in bytes, of the retrieved record.
- </para></listitem>
+ The size, in bytes, of the retrieved record.
+ </para></listitem>
</varlistentry>
</variablelist>
</para>
</varlistentry>
</variablelist>
</para>
-
+
<note>
<para>
The mechanism for controlling indexing is not adequate for
configuration table eventually.
</para>
</note>
-
+
<para>
The following is an excerpt from the abstract syntax file for the GILS
profile.
elm (4,1) controlIdentifier Identifier-standard
elm (2,6) abstract Abstract
elm (4,51) purpose !
- elm (4,52) originator -
+ elm (4,52) originator -
elm (4,53) accessConstraints !
elm (4,54) useConstraints !
elm (4,70) availability -
<para>
This file type describes the <replaceable>Use</replaceable> elements of
- an attribute set.
- It contains the following directives.
+ an attribute set.
+ It contains the following directives.
</para>
-
+
<para>
<variablelist>
<varlistentry>
(m) The reference name of the OID for
the attribute set.
The reference names can be found in the <replaceable>util</replaceable>
- module of <replaceable>YAZ</replaceable>.
+ module of <replaceable>&yaz;</replaceable>.
</para>
</listitem></varlistentry>
<varlistentry>
set. For instance, many new attribute sets are defined as extensions
to the <replaceable>bib-1</replaceable> set.
This is an important feature of the retrieval
- system of Z39.50, as it ensures the highest possible level of
+ system of &acro.z3950;, as it ensures the highest possible level of
interoperability, as those access points of your database which are
derived from the external set (say, bib-1) can be used even by clients
who are unaware of the new set.
attribute value is stored in the index (unless a
<replaceable>local-value</replaceable> is
given, in which case this is stored). The name is used to refer to the
- attribute from the <replaceable>abstract syntax</replaceable>.
+ attribute from the <replaceable>abstract syntax</replaceable>.
</para>
</listitem></varlistentry>
</variablelist>
<para>
This file type defines the tagset of the profile, possibly by
referencing other tag sets (most tag sets, for instance, will include
- tagsetG and tagsetM from the Z39.50 specification. The file may
+ tagsetG and tagsetM from the &acro.z3950; specification. The file may
contain the following directives.
</para>
<para>
(o) The reference name of the OID for the tag set.
The reference names can be found in the <emphasis>util</emphasis>
- module of <emphasis>YAZ</emphasis>.
+ module of <emphasis>&yaz;</emphasis>.
The directive is optional, since not all tag sets
are registered outside of their schema.
</para>
<para>
(o) The reference name of the OID for
the variant set, if one is required. The reference names can be found
- in the <emphasis>util</emphasis> module of <emphasis>YAZ</emphasis>.
+ in the <emphasis>util</emphasis> module of <emphasis>&yaz;</emphasis>.
</para>
</listitem></varlistentry>
<varlistentry>
The element set specification files describe a selection of a subset
of the elements of a database record. The element selection mechanism
is equivalent to the one supplied by the <emphasis>Espec-1</emphasis>
- syntax of the Z39.50 specification.
+ syntax of the &acro.z3950; specification.
In fact, the internal representation of an element set
specification is identical to the <emphasis>Espec-1</emphasis> structure,
and we'll refer you to the description of that structure for most of
otherwise is noted.
</para>
</note>
-
+
<para>
The directives available in the element set file are as follows:
</para>
provides a default variant request for
use when the individual element requests (see below) do not contain a
variant request. Variant requests consist of a blank-separated list of
- variant components. A variant compont is a comma-separated,
+ variant components. A variant component is a comma-separated,
parenthesized triple of variant class, type, and value (the two former
values being represented as integers). The value can currently only be
entered as a string (this will change to depend on the definition of
a schema that differs from the native schema of the record. For
instance, a client might only know how to process WAIS records, while
the database record is represented in a more specific schema, such as
- GILS. In this module, a mapping of data to one of the MARC formats is
+ GILS. In this module, a mapping of data to one of the &acro.marc; formats is
also thought of as a schema mapping (mapping the elements of the
- record into fields consistent with the given MARC specification, prior
+ record into fields consistent with the given &acro.marc; specification, prior
to actually converting the data to the ISO2709). This use of the
- object identifier for USMARC as a schema identifier represents an
+ object identifier for &acro.usmarc; as a schema identifier represents an
overloading of the OID which might not be entirely proper. However,
it represents the dual role of schema and record syntax which
- is assumed by the MARC family in Z39.50.
+ is assumed by the &acro.marc; family in &acro.z3950;.
</para>
<!--
- <emphasis>NOTE: FIXME! The schema-mapping functions are so far limited to a
- straightforward mapping of elements. This should be extended with
- mechanisms for conversions of the element contents, and conditional
- mappings of elements based on the record contents.</emphasis>
+ <emphasis>NOTE: FIXME! The schema-mapping functions are so far limited to a
+ straightforward mapping of elements. This should be extended with
+ mechanisms for conversions of the element contents, and conditional
+ mappings of elements based on the record contents.</emphasis>
-->
<para>
This is used, for instance, by a server receiving a request to present
a record in a different schema from the native one.
The name, again, is found in the <emphasis>oid</emphasis>
- module of <emphasis>YAZ</emphasis>.
+ module of <emphasis>&yaz;</emphasis>.
</para>
</listitem></varlistentry>
<varlistentry>
</section>
<section id="grs-mar-files">
- <title>The MARC (ISO2709) Representation (.mar) Files</title>
+ <title>The &acro.marc; (ISO2709) Representation (.mar) Files</title>
<para>
This file provides rules for representing a record in the ISO2709
</para>
<!--
- NOTE: FIXME! This will be described better. We're in the process of
- re-evaluating and most likely changing the way that MARC records are
- handled by the system.</emphasis>
+ NOTE: FIXME! This will be described better. We're in the process of
+ re-evaluating and most likely changing the way that &acro.marc; records are
+ handled by the system.</emphasis>
-->
</section>
</section>
<section id="grs-exchange-formats">
- <title>GRS Exchange Formats</title>
+ <title>&acro.grs1; Exchange Formats</title>
<para>
Converting records from the internal structure to an exchange format
<itemizedlist>
<listitem>
<para>
- GRS-1. The internal representation is based on GRS-1/XML, so the
+ &acro.grs1;. The internal representation is based on &acro.grs1;/&acro.xml;, so the
conversion here is straightforward. The system will create
applied variant and supported variant lists as required, if a record
contains variant information.
<listitem>
<para>
- XML. The internal representation is based on GRS-1/XML so
- the mapping is trivial. Note that XML schemas, preprocessing
+ &acro.xml;. The internal representation is based on &acro.grs1;/&acro.xml; so
+ the mapping is trivial. Note that &acro.xml; schemas, preprocessing
instructions and comments are not part of the internal representation
- and therefore will never be part of a generated XML record.
- Future versions of the Zebra will support that.
+ and therefore will never be part of a generated &acro.xml; record.
+ Future versions of the &zebra; will support that.
</para>
</listitem>
<listitem>
<para>
- SUTRS. Again, the mapping is fairly straightforward. Indentation
+ &acro.sutrs;. Again, the mapping is fairly straightforward. Indentation
is used to show the hierarchical structure of the record. All
- "GRS" type records support both the GRS-1 and SUTRS
+ "&acro.grs1;" type records support both the &acro.grs1; and &acro.sutrs;
representations.
- <!-- FIXME - What is SUTRS - should be expanded here -->
+ <!-- FIXME - What is &acro.sutrs; - should be expanded here -->
</para>
</listitem>
<listitem>
<para>
- ISO2709-based formats (USMARC, etc.). Only records with a
+ ISO2709-based formats (&acro.usmarc;, etc.). Only records with a
two-level structure (corresponding to fields and subfields) can be
directly mapped to ISO2709. For records with a different structuring
- (eg., GILS), the representation in a structure like USMARC involves a
+ (e.g., GILS), the representation in a structure like &acro.usmarc; involves a
schema-mapping (see <xref linkend="schema-mapping"/>), to an
- "implied" USMARC schema (implied,
+ "implied" &acro.usmarc; schema (implied,
because there is no formal schema which specifies the use of the
- USMARC fields outside of ISO2709). The resultant, two-level record is
+ &acro.usmarc; fields outside of ISO2709). The resultant, two-level record is
then mapped directly from the internal representation to ISO2709. See
the GILS schema definition files for a detailed example of this
approach.
</para>
</listitem>
- <!-- FIXME - Is this used anywhere ? -H -->
+ <!-- FIXME - Is this used anywhere ? -H -->
<listitem>
<para>
SOIF. Support for this syntax is experimental, and is currently
level.
</para>
</listitem>
-
+
</itemizedlist>
</para>
</section>
-
+
<section id="grs-extended-marc-indexing">
- <title>Extended indexing of MARC records</title>
-
- <para>Extended indexing of MARC records will help you if you need index a
+ <title>Extended indexing of &acro.marc; records</title>
+
+ <para>Extended indexing of &acro.marc; records will help you if you need index a
combination of subfields, or index only a part of the whole field,
- or use during indexing process embedded fields of MARC record.
+ or use during indexing process embedded fields of &acro.marc; record.
</para>
-
- <para>Extended indexing of MARC records additionally allows:
+
+ <para>Extended indexing of &acro.marc; records additionally allows:
<itemizedlist>
-
+
<listitem>
- <para>to index data in LEADER of MARC record</para>
+ <para>to index data in LEADER of &acro.marc; record</para>
</listitem>
-
+
<listitem>
<para>to index data in control fields (with fixed length)</para>
</listitem>
-
+
<listitem>
<para>to use during indexing the values of indicators</para>
</listitem>
-
+
<listitem>
- <para>to index linked fields for UNIMARC based formats</para>
+ <para>to index linked fields for UNI&acro.marc; based formats</para>
</listitem>
-
+
</itemizedlist>
</para>
-
+
<note><para>In compare with simple indexing process the extended indexing
- may increase (about 2-3 times) the time of indexing process for MARC
+ may increase (about 2-3 times) the time of indexing process for &acro.marc;
records.</para></note>
-
+
<section id="formula">
<title>The index-formula</title>
-
+
<para>At the beginning, we have to define the term
- <emphasis>index-formula</emphasis> for MARC records. This term helps
- to understand the notation of extended indexing of MARC records by Zebra.
+ <emphasis>index-formula</emphasis> for &acro.marc; records. This term helps
+ to understand the notation of extended indexing of &acro.marc; records by &zebra;.
Our definition is based on the document
<ulink url="http://www.rba.ru/rusmarc/soft/Z39-50.htm">"The table
- of conformity for Z39.50 use attributes and RUSMARC fields"</ulink>.
- The document is available only in russian language.</para>
-
+ of conformity for &acro.z3950; use attributes and R&acro.usmarc; fields"</ulink>.
+ The document is available only in Russian language.</para>
+
<para>
The <emphasis>index-formula</emphasis> is the combination of
subfields presented in such way:
</para>
-
+
<screen>
71-00$a, $g, $h ($c){.$b ($c)} , (1)
</screen>
-
+
<para>
- We know that Zebra supports a Bib-1 attribute - right truncation.
- In this case, the <emphasis>index-formula</emphasis> (1) consists from
+ We know that &zebra; supports a &acro.bib1; attribute - right truncation.
+ In this case, the <emphasis>index-formula</emphasis> (1) consists from
forms, defined in the same way as (1)</para>
-
+
<screen>
71-00$a, $g, $h
71-00$a, $g
71-00$a
</screen>
-
+
<note>
- <para>The original MARC record may be without some elements, which included in <emphasis>index-formula</emphasis>.
+ <para>The original &acro.marc; record may be without some elements, which included in <emphasis>index-formula</emphasis>.
</para>
</note>
-
+
<para>This notation includes such operands as:
<variablelist>
-
+
<varlistentry>
<term>#</term>
<listitem><para>It means whitespace character.</para></listitem>
</varlistentry>
-
+
<varlistentry>
<term>-</term>
<listitem><para>The position may contain any value, defined by
- MARC format.
+ &acro.marc; format.
For example, <emphasis>index-formula</emphasis></para>
-
+
<screen>
70-#1$a, $g , (2)
</screen>
-
- <para>includes</para>
-
+
+ <para>includes</para>
+
<screen>
700#1$a, $g
701#1$a, $g
702#1$a, $g
</screen>
-
+
</listitem>
</varlistentry>
-
+
<varlistentry>
<term>{...}</term>
<listitem>
<para>The repeatable elements are defined in figure-brackets {}.
For example,
<emphasis>index-formula</emphasis></para>
-
+
<screen>
71-00$a, $g, $h ($c){.$b ($c)} , (3)
</screen>
-
+
<para>includes</para>
-
+
<screen>
71-00$a, $g, $h ($c). $b ($c)
71-00$a, $g, $h ($c). $b ($c). $b ($c)
71-00$a, $g, $h ($c). $b ($c). $b ($c). $b ($c)
</screen>
-
+
</listitem>
</varlistentry>
</variablelist>
-
+
<note>
<para>
- All another operands are the same as accepted in MARC world.
+ All another operands are the same as accepted in &acro.marc; world.
</para>
</note>
</para>
</section>
-
+
<section id="notation">
- <title>Notation of <emphasis>index-formula</emphasis> for Zebra</title>
-
-
+ <title>Notation of <emphasis>index-formula</emphasis> for &zebra;</title>
+
+
<para>Extended indexing overloads <literal>path</literal> of
- <literal>elm</literal> definition in abstract syntax file of Zebra
+ <literal>elm</literal> definition in abstract syntax file of &zebra;
(<literal>.abs</literal> file). It means that names beginning with
- <literal>"mc-"</literal> are interpreted by Zebra as
+ <literal>"mc-"</literal> are interpreted by &zebra; as
<emphasis>index-formula</emphasis>. The database index is created and
- linked with <emphasis>access point</emphasis> (Bib-1 use attribute)
+ linked with <emphasis>access point</emphasis> (&acro.bib1; use attribute)
according to this formula.</para>
-
+
<para>For example, <emphasis>index-formula</emphasis></para>
-
+
<screen>
71-00$a, $g, $h ($c){.$b ($c)} , (4)
</screen>
-
+
<para>in <literal>.abs</literal> file looks like:</para>
-
+
<screen>
mc-71.00_$a,_$g,_$h_(_$c_){.$b_(_$c_)}
</screen>
-
-
+
+
<para>The notation of <emphasis>index-formula</emphasis> uses the operands:
<variablelist>
-
+
<varlistentry>
<term>_</term>
<listitem><para>It means whitespace character.</para></listitem>
</varlistentry>
-
+
<varlistentry>
<term>.</term>
<listitem><para>The position may contain any value, defined by
- MARC format. For example,
+ &acro.marc; format. For example,
<emphasis>index-formula</emphasis></para>
-
+
<screen>
70-#1$a, $g , (5)
</screen>
-
+
<para>matches <literal>mc-70._1_$a,_$g_</literal> and includes</para>
-
+
<screen>
700_1_$a,_$g_
701_1_$a,_$g_
</screen>
</listitem>
</varlistentry>
-
+
<varlistentry>
<term>{...}</term>
<listitem><para>The repeatable elements are defined in
figure-brackets {}. For example,
<emphasis>index-formula</emphasis></para>
-
+
<screen>
71#00$a, $g, $h ($c) {.$b ($c)} , (6)
</screen>
-
- <para>matches
+
+ <para>matches
<literal>mc-71.00_$a,_$g,_$h_(_$c_){.$b_(_$c_)}</literal> and
includes</para>
-
+
<screen>
71.00_$a,_$g,_$h_(_$c_).$b_(_$c_)
71.00_$a,_$g,_$h_(_$c_).$b_(_$c_).$b_(_$c_)
</screen>
</listitem>
</varlistentry>
-
+
<varlistentry>
<term><...></term>
<listitem><para>Embedded <emphasis>index-formula</emphasis> (for
linked fields) is between <>. For example,
<emphasis>index-formula</emphasis>
</para>
-
+
<screen>
4--#-$170-#1$a, $g ($c) , (7)
</screen>
-
+
<para>matches
<literal>mc-4.._._$1<70._1_$a,_$g_(_$c_)>_</literal> and
includes</para>
-
+
<screen>
463_._$1<70._1_$a,_$g_(_$c_)>_
</screen>
-
+
</listitem>
</varlistentry>
</variablelist>
</para>
-
+
<note>
- <para>All another operands are the same as accepted in MARC world.</para>
+ <para>All another operands are the same as accepted in &acro.marc; world.</para>
</note>
-
+
<section id="grs-examples">
<title>Examples</title>
-
+
<para>
<orderedlist>
-
+
<listitem>
-
+
<para>indexing LEADER</para>
-
+
<para>You need to use keyword "ldr" to index leader. For example,
indexing data from 6th and 7th position of LEADER</para>
-
+
<screen>
elm mc-ldr[6] Record-type !
elm mc-ldr[7] Bib-level !
</screen>
-
+
</listitem>
-
+
<listitem>
-
+
<para>indexing data from control fields</para>
-
+
<para>indexing date (the time added to database)</para>
-
+
<screen>
- elm mc-008[0-5] Date/time-added-to-db !
+ elm mc-008[0-5] Date/time-added-to-db !
</screen>
-
- <para>or for RUSMARC (this data included in 100th field)</para>
-
+
+ <para>or for R&acro.usmarc; (this data included in 100th field)</para>
+
<screen>
elm mc-100___$a[0-7]_ Date/time-added-to-db !
</screen>
-
+
</listitem>
-
+
<listitem>
-
+
<para>using indicators while indexing</para>
- <para>For RUSMARC <emphasis>index-formula</emphasis>
+ <para>For R&acro.usmarc; <emphasis>index-formula</emphasis>
<literal>70-#1$a, $g</literal> matches</para>
-
+
<screen>
elm 70._1_$a,_$g_ Author !:w,!:p
</screen>
-
- <para>When Zebra finds a field according to
+
+ <para>When &zebra; finds a field according to
<literal>"70."</literal> pattern it checks the indicators. In this
case the value of first indicator doesn't mater, but the value of
- second one must be whitespace, in another case a field is not
+ second one must be whitespace, in another case a field is not
indexed.</para>
</listitem>
-
+
<listitem>
-
- <para>indexing embedded (linked) fields for UNIMARC based
+
+ <para>indexing embedded (linked) fields for UNI&acro.marc; based
formats</para>
-
- <para>For RUSMARC <emphasis>index-formula</emphasis>
+
+ <para>For R&acro.usmarc; <emphasis>index-formula</emphasis>
<literal>4--#-$170-#1$a, $g ($c)</literal> matches</para>
-
+
<screen><![CDATA[
elm mc-4.._._$1<70._1_$a,_$g_(_$c_)>_ Author !:w,!:p
]]></screen>
-
+
<para>Data are extracted from record if the field matches to
<literal>"4.._."</literal> pattern and data in linked field
match to embedded
<emphasis>index-formula</emphasis>
<literal>70._1_$a,_$g_(_$c_)</literal>.</para>
-
+
</listitem>
-
+
</orderedlist>
</para>
-
-
+
+
</section>
</section>
</section>
-
+
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
- sgml-parent-document: "zebra.xml"
+ sgml-parent-document: "idzebra.xml"
sgml-local-catalogs: nil
sgml-namecase-general:t
End:
projects / idzebra-moved-to-github.git / blobdiff