<!doctype linuxdoc system>
<!--
- $Id: zebra.sgml,v 1.13 1996-01-03 16:21:58 quinn Exp $
+ $Id: zebra.sgml,v 1.18 1996-02-10 12:20:46 quinn Exp $
-->
<article>
<title>Zebra Server - Administrators's Guide and Reference
-<author>Index Data, <tt/info@index.ping.dk/
-<date>$Revision: 1.13 $
+<author><htmlurl url="http://www.index.dk/" name="Index Data">, <tt><htmlurl url="mailto:info@index.ping.dk" name="info@index.ping.dk"></>
+<date>$Revision: 1.18 $
<abstract>
The Zebra information server combines a versatile fielded/free-text
search engine with a Z39.50-1995 frontend to provide a powerful and flexible
neat, you're welcome to drop us a line saying that, too. You'll find
contact info at the end of this file.
-<sect>Getting Started
-
<sect>Compiling the software
<p>
If you've made it this far, there's a reasonably good chance that
you've got through the compilation OK.
-<sect><heading><label id="administrating">Administrating Zebra</>
+<sect>Administrating Zebra<label id="administrating">
<p>
Unlike many simpler retrieval systems, Zebra supports safe, incremental
not indicate the location of the configuration file by option
<tt>-c</tt>.
-<sect1><heading><label id="record-types">Record Types</>
+<sect1>Record Types<label id="record-types">
<p>
Indexing is a per-record process, in which
either insert/modify/delete will occur. Before a record is indexed
command line option <tt>-t</tt> or specify a
<tt>recordType</tt> setting in the configuration file.
-<sect1><heading><label id="configuration-file">The Zebra Configuration File</>
+<sect1>The Zebra Configuration File<label id="configuration-file">
<p>
The Zebra configuration file, read by <tt>zebraidx</tt> and
<tt>zebrasrv</tt> defaults to <tt>zebra.cfg</tt> unless specified
This will remove all records that match the files below that root
directory.
-<sect1><heading><label id="register-location">Register Location</>
+<sect1>Register Location<label id="register-location">
<p>
Normally, the index files that form dictionaries, inverted
it is recommended that you allocate one or more filesystem exclusively
to the Zebra register files.
-<sect1><heading><label id="shadow-registers">Safe Updating - Using Shadow Registers</>
+<sect1>Safe Updating - Using Shadow Registers<label id="shadow-registers">
<sect2>Description
zebrasrv [options] [listener-address ...]
</verb></tscreen>
+<bf/Options/
<descrip>
<tag>-a <it/APDU file/</tag> Specify a file for dumping PDUs (for diagnostic purposes).
The special name &dquot;-&dquot; sends output to <tt/stderr/.
-<tag>-c <it/config-file/</tag> Read configuration information from <it/config-file/. The default configuration is <tt/./zebra.cfg/.
+<tag>-c <it/config-file/</tag> Read configuration information from <it/config-file/. The default configuration is <tt>./zebra.cfg</tt>.
<tag/-S/Don't fork on connection requests. This can be useful for
symbolic-level debugging. The server can only accept a single
given <it/username/. It's useful if you aren't comfortable with having the
server run as root, but you need to start it as such to bind a
privileged port.
+
+<tag>-w <it/working-directory/</tag>Change working directory.
+
+<tag/-i/Run under the Internet superserver, <tt/inetd/.
</descrip>
A <it/listener-address/ consists of a transport mode followed by a
over the network - according to the Z39.50 standard.
</itemize>
-<sect1><heading><label id="local-representation">Local Representation</>
+<sect1>Local Representation<label id="local-representation">
<p>
As mentioned earlier, Zebra places few restrictions on the type of
</descrip>
-<tag/data/Create a data element under. The concatenated arguments make
+<tag/data/Create a data element. The concatenated arguments make
up the value of the data element. The option <tt/-text/ signals that
the layout (whitespace) of the data should be retained for
transmission. The option <tt/-element/ <it/tag/ wraps the data up in
preceding the command with a <bf/begin element/ command, and following
it with the <bf/end/ command.
-<tag>end <it/[type]/</tag>Close a data element. If no parameter is given,
+<tag>end <it/[type]/</tag>Close a tagged element. If no parameter is given,
the last element on the stack is terminated. The first parameter, if
any, is a type name, similar to the <bf/begin/ statement. For the
<bf/element/ type, a tag name can be provided to terminate a specific tag.
</descrip>
The following input filter reads a Usenet news file, producing a
-record in the WAIS schema.
+record in the WAIS schema. Note that the body of the news posting is
+separated from the list of headers by a blank line (or rather a
+sequence of two newline characters.
<tscreen><verb>
BEGIN { begin record wais }
<it>NOTE: Tcl support is not currently available, but will be
included with the next release.</it>
-<sect1><heading><label id="internal-representation">Internal Representation</>
+<it>NOTE: Variant support is not currently available in the input filter, but will be included with the next release.</it>
+
+<sect1>Internal Representation<label id="internal-representation">
<p>
When records are manipulated by the system, they're represented in a
different schema, by stating, for each element, a mapping to a
different tagging.
+<sect2>Tagged Elements
+
+<p>
+A data element is characterized by its tag, and its position in the
+structure of the record. For instance, while the tag &dquot;telephone
+number&dquot; may be used different places in a record, we may need to
+distinguish between these occurrences, both for searching and
+presentation purposes. For instance, while the phone numbers for the
+&dquot;customer&dquot; and the &dquot;service provider&dquot; are both
+representatives for the same type of resource (a telephone number), it
+is essential that they be kept separate. The record schema provides
+the structure of the record, and names each data element (defined by
+the sequence of tags - the tag path - by which the element can be
+reached from the root of the record).
+
+<sect2>Variants
+
+<p>
+The children of a tag node may be either more tag nodes, a data node,
+or a tree of variant nodes. The children of variant nodes are either
+more variant nodes or data nodes. Each leaf node, which is normally a
+data node, corresponds to a <it/variant form/ or the tagged element
+identified by the tag which parents the variant tree. The following
+title element occurs in two different languages:
+
+<tscreen><verb>
+ VARIANT LANG=ENG "War and Peace"
+TITLE
+ VARIANT LANG=DAN "Krig og Fred"
+</verb></tscreen>
+
+Which of the two elements are transmitted to the client by the server
+depends on the specifications provided by the client, if any.
+
+In practice, each variant node is associated with a triple of class,
+type, value, corresponding to the variant mechanism of Z39.50.
+
+<sect2>Data Elements
+
+<p>
+Data nodes have no children (they are always leaf nodes in the record
+tree).
+
+<it>NOTE: Add more stuff here about types of nodes - numerical,
+textual, etc., plus the various types of inclusion notes.</it>
+
+<sect1>Configuring Your Data Model
+
+<p>
The following sections describe the configuration files that govern
the internal management of records. The system searches for the files
in the directories specified by the <bf/profilePath/ setting in the
tag 10 organization string
</verb></tscreen>
-<sect2><heading><label id="variant-set">The Variant Set (.var) Files</>
+<sect2>The Variant Set (.var) Files<label id="variant-set">
<p>
The variant set file is a straightforward representation of the
simpleelement (4,52)
</verb></tscreen>
-<sect2><heading><label id="schema-mapping">The Schema Mapping (.map) Files</>
+<sect2>The Schema Mapping (.map) Files<label id="schema-mapping">
<p>
Sometimes, the client might want to receive a database record in
projects / idzebra-moved-to-github.git / blobdiff