<chapter id="administration">
- <!-- $Id: administration.xml,v 1.8 2002-10-11 09:05:09 adam Exp $ -->
+ <!-- $Id: administration.xml,v 1.9 2002-10-17 08:10:08 mike Exp $ -->
<title>Administrating Zebra</title>
-
+ <!-- ### It's a bit daft that this chapter (which describes half of
+ the configuration-file formats) is separated from
+ "recordmodel.xml" (which describes the other half) by the
+ instructions on running zebraidx and zebrasrv. Some careful
+ re-ordering is required here.
+ -->
+
<para>
Unlike many simpler retrieval systems, Zebra supports safe, incremental
updates to an existing index.
group of records. If you plan to update/delete this type of
records later this should be specified as 1; otherwise it
should be 0 (default), to save register space.
+ <!-- ### this is the first mention of "register" -->
See <xref linkend="file-ids"/>.
</para>
</listitem>
</listitem>
</varlistentry>
<varlistentry>
+ <!-- ### probably a better place to define "register" -->
<term>register: <replaceable>register-location</replaceable></term>
<listitem>
<para>
<term>keyTmpDir: <replaceable>directory</replaceable></term>
<listitem>
<para>
- Directory in which temporary files used during zebraidx' update
+ Directory in which temporary files used during zebraidx's update
phase are stored.
</para>
</listitem>
That is, when a client wishes to retrieve a record
following a search operation, the files are accessed from the place
where you originally put them - if you remove the files (without
- running <literal>zebraidx</literal> again, the client
- will receive a diagnostic message.
+ running <literal>zebraidx</literal> again, the server will return
+ diagnostic number 14 (``System error in presenting records'') to
+ the client.
</para>
<para>
<chapter id="examples">
- <!-- $Id: examples.xml,v 1.9 2002-10-16 20:33:31 mike Exp $ -->
+ <!-- $Id: examples.xml,v 1.10 2002-10-17 08:10:08 mike Exp $ -->
<title>Example Configurations</title>
<sect1>
and well defined.
</para>
<para>
- For convenience, access points are gathered into <define>attribute
- sets</define>. For example, the BIB-1 attribute set is supposed to
+ For convenience, access points are gathered into <firstterm>attribute
+ sets</firstterm>. For example, the BIB-1 attribute set is supposed to
contain bibliographic access points such as author, title, subject
and ISBN; the GEO attribute set contains access points pertaining
to geospatial information (bounding box, ###, etc.); the CIMI
want to support the BIB-1 attribute set. Then we need to tell it
which elements of its record pertain to access point 1003.
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ </para>
+ </listitem>
+ </itemizedlist>
</sect1>
</chapter>
The master configuration file, <literal>zebra.cfg</literal>,
which is as short and simple as it can be:
<screen>
- # $Header: /home/cvsroot/idis/doc/examples.xml,v 1.9 2002-10-16 20:33:31 mike Exp $
+ # $Header: /home/cvsroot/idis/doc/examples.xml,v 1.10 2002-10-17 08:10:08 mike Exp $
# Bare-bones master configuration file for Zebra
profilePath: .:../../tab:../../../yaz/tab
</screen>
### What is an attribute set?
</para>
</listitem>
-
- <listitem>
- <para>
- The BIB-1 attribute set configuration file,
- <literal>bib1.att</literal>, which is also as short as possible:
- <screen>
- # $Header: /home/cvsroot/idis/doc/examples.xml,v 1.9 2002-10-16 20:33:31 mike Exp $
- # Bare-bones BIB-1 attribute set file for Zebra
- reference Bib-1
- </screen>
- Apart from the comments, all this specifies is that reference of
- the attribute set described by this file is
- <literal>Bib-1</literal>, a name recognised by the system as
- referring to a well-known opaque identifier that is transmitted
- by clients as part of their searches.
- ### Yeuch! Surely we can say that better!
- </para>
- <para>
- ### Can't we somehow say this trivial thing in the main
- configuration file?
- </para>
- </listitem>
-->
<!--
<chapter id="introduction">
- <!-- $Id: introduction.xml,v 1.17 2002-10-16 20:33:31 mike Exp $ -->
+ <!-- $Id: introduction.xml,v 1.18 2002-10-17 08:10:08 mike Exp $ -->
<title>Introduction</title>
<sect1>
Zebra is written in portable C, so it runs on most Unix-like systems
as well as Windows NT. A binary distribution for Windows NT is
available at
- <ulink url="http://ftp.indexdata.dk/pub/zebra/win32/"/>
+ <ulink url="http://ftp.indexdata.dk/pub/zebra/win32/"/>,
+ and pre-built packages are available for some Linux
+ distributions:
+ Red Hat 7.x RPMs at
+ <ulink url="http://ftp.indexdata.dk/pub/zebra/RedHat7.X/"/>
+ and Debian packages at
+ <ulink url="http://ftp.indexdata.dk/pub/zebra/debian/"/>
</para>
</listitem>
<para>
Protocol facilities: Init, Search, Present (retrieval),
Segmentation (support for very large records), Delete, Scan
- (index browsing), Sort, Close and some Extended Services.
+ (index browsing), Sort, Close and support for the ``update''
+ Extended Service to add or replace an existing XML record.
+ <!-- Adam says:
+ * Supported
+ You can insert/delete/replace an XML record given an
+ "external" ID. Actually this way of doing ES Update was
+ meant for an OAI application that Ian Ibbotson had in
+ mind to implement. The "update" command in YAZ client
+ implements this on the client side. My plan is to make
+ this available in ZOOM "extended" soon..
+ -->
</para>
</listitem>
announcements from the authors (new
releases, bug fixes, etc.) and general discussion. You are welcome
to seek support there. Join by sending email to
- <email>zebra-request@indexdata.dk</email>. Put the word 'subscribe'
- in the body of the message.
+ <email>zebra-request@indexdata.dk</email>. Put the word
+ <literal>subscribe</literal> in the body of the message.
</para>
<para>
Third, it's possible to buy a commercial support contract, with
well defined service levels and response times, from Index Data.
See
<ulink url="http://www.indexdata.dk/support/?lang=en"/>
+ <!-- ### compare this page with http://indexdata.dk/support2/ -->
for details.
</para>
</sect1>
<chapter id="record-model">
- <!-- $Id: recordmodel.xml,v 1.7 2002-10-11 09:05:09 adam Exp $ -->
+ <!-- $Id: recordmodel.xml,v 1.8 2002-10-17 08:10:08 mike Exp $ -->
<title>The Record Model</title>
<para>
kind of structured data. Each record in the system is associated with
a <emphasis>record schema</emphasis> which lends context to the data
elements of the record.
- Any number of record schema can coexist in the system.
+ Any number of record schemas can coexist in the system.
Although it may be wise to use only a single schema within
one database, the system poses no such restrictions.
</para>
<para>
The record model described in this chapter applies to the fundamental,
structured
- record type <literal>grs</literal> as introduced in
+ record type <literal>grs</literal>, introduced in
<xref linkend="record-types"/>.
<!--
FIXME - Need to describe the simple string-tag model, or at least
<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>
Each element is terminated by a closing tag - beginning
with <literal><</literal>/, and containing the same symbolic
tag-name as the corresponding opening tag.
- The general closing tag - <literal><</literal>>/ -
+ The general closing tag - <literal><</literal>/> -
terminates the element started by the last opening tag. The
structuring of elements is significant.
The element <emphasis>Telephone</emphasis>,
tag with the same <emphasis>class</emphasis> and
<emphasis>value</emphasis> settings, or by the
appearance of another, normal tag. In other words, the end-tags for
- the variants used in the example above could have been saved.
+ the variants used in the example above could have been omitted.
</para>
<para>
<chapter id="server">
- <!-- $Id: server.xml,v 1.4 2002-10-11 09:05:09 adam Exp $ -->
+ <!-- $Id: server.xml,v 1.5 2002-10-17 08:10:08 mike Exp $ -->
<title>The Z39.50 Server</title>
<sect1 id="zebrasrv">
</para>
<para>
- The server has full support for piggy-backed present requests (see
+ The server has full support for piggy-backed retrieval (see
also the following section).
</para>
A phrase register is created for those fields in the
<literal>.abs</literal> file that contains a
<literal>p</literal>-specifier.
+ <!-- ### whatever the hell _that_ is -->
</para>
<para>
<chapter id="zebraidx">
- <!-- $Id: zebraidx.xml,v 1.3 2002-09-19 21:06:51 adam Exp $ -->
+ <!-- $Id: zebraidx.xml,v 1.4 2002-10-17 08:10:08 mike Exp $ -->
<title>Running the Maintenance Interface (zebraidx)</title>
<para>
Options:
&zebraidx-options;
</para>
+ <!-- ### swap order of commands and options -->
<para>
Commands
projects / idzebra-moved-to-github.git / commitdiff