Because Z39.50-1988 grew out of the bibliographic community,
additional assumptions with the protocol were required to serve non-
bibliographic information. They were also necessary to serve
documents existing in multiple formats (e.g., rtf, postscript, gif,
etc.).
2. Keep the client/server interface simple and independent of
changes in the functionality of the server.
RFC 1625 WAIS over Z39.50-1988 June 1994
To achieve this, the text string entered by the user was transmitted
to the server without parsing the string into a Type-1 RPN (reverse-
polish notation) query, as is common for bibliographic applications.
Instead WAIS defined a new Type-3 query containing the text string.
In this way, knowledge of the Z39.50 Attributes supported by the
server was no longer required by the client or the user, as is true
of many existing Z39.50 implementations. In addition, the client
software did not require modification to support the evolving
functionality of the server.
3. Provide relevance feedback capability.
Relevance feedback is the ability to select a document, or portion of
a document, and find a set of documents similar to the selection.
WAIS included documents used in relevance feedback as part of the
Type-3 query.
4. Permit the server to operate in a stateless manner.
A WAIS server was designed to be "stateless", meaning that search
result sets were not stored by the server. In Z39.50 terms, the
server exercised its right to unilaterally delete a result set as
soon as it sent the search response. For this reason, the Present
Facility of Z39.50 was not used, and retrievals were performed using
the Search Facility. Relaxing this constraint in future
implementations may prove the most prudent path.
5. Provide the ability for a client to retrieve documents in
pieces.
Because retrieval of a portion of a document could be done several
ways with Z39.50-1988, specific assumptions were made to implement
this functionality. Accessing a portion of a document was required
for both retrieval and for relevance feedback.
6. Run over TCP.
The Z39.50-1988 standard was designed to run in the application layer
using the presentation services provided by the Open Systems
Interconnection (OSI) Reference Model. Due to the popularity of
TCP/IP and the Internet, WAIS was designed to run over TCP. Use of
Z39.50 over TCP is described in [4].
4. WAIS Implementation of Z39.50-1988
By working with the Z39.50 Implementors Group (ZIG), the WAIS
developers used a recommended subset of Z39.50-1988 and specific
assumptions to fulfill its requirements. Over time, many of these
RFC 1625 WAIS over Z39.50-1988 June 1994
requirements have then gone into the definition of subsequent
versions of Z39.50. As new requirements become apparent, WAIS will
document any additional assumptions and work with the ZIG in
developing extensions.
WAIS supported the Init and Search Facilities of Z39.50-1988. Both
search and retrieval were implemented using the Search Facility, as
described in this section.
Search was initiated by the client with a Search Request APDU
(Application Protocol Data Unit) using a Type-3 query. The query
contained two main fields:
1. The "seed words", or text, typed by the user.
2. A list of document objects, where a document object is a
full document, or portion thereof, to be used in relevance
feedback. Each document object contains a document
identifier (Doc-ID) [5], type, chunk-code, and start and
end locations. The Doc-ID and type specify the location and
format, respectively, of the document. The chuck-code
determines the unit of measure for the start and end
locations. Examples of chunk-codes used include
byte, line, paragraph, and full document. If the chunk code
is a full document, the start and end locations are ignored.
A Search Response APDU returned by the server contained a relevance
=2= |