As per Relevance of the word document, we have this rfc below:











Network Working Group M. St.
Request for Comments: 1625 WAIS, Inc
Category: Informational J.

K.

J.
Thinking Machines Corp
B.
WAIS, Inc
J.
UC
H.
WAIS, Inc
F.
FS
June 1994


WAIS over Z39.50-1988

Status of this

This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited

1.

The network publishing system, Wide Area Information Servers (WAIS),
is designed to help users find information over a computer network
The principles guiding WAIS development are

1. A wide-area networked-based information system for searching
browsing, and publishing
2. Based on standards
3. Easy to use
4. Flexible and growth oriented

From this basis, a large group of developers, publishers,
bodies, libraries, government agencies, schools, and users have
helping further the WAIS system

The WAIS software architecture has four main components: the client
the server, the database, and the protocol. The WAIS client is
user-interface program that sends requests for information to
or remote servers. Clients are available for most popular
environments. The WAIS server is a program that services



IIIR Working Group [Page 1]

RFC 1625 WAIS over Z39.50-1988 June 1994


requests, and is available on a variety of UNIX platforms.
server generally runs on a machine containing one or more
sources, or WAIS databases. The protocol, Z39.50-1988, is used
connect WAIS clients and servers and is based on the 1988 Version
the NISO Z39.50 Information Retrieval Service and Protocol Standard
The goal of the WAIS network publishing system is to create an
architecture of information clients and servers by using a
computer-to-computer protocol that enables clients to
with servers

WAIS development began in October 1989 with the first
release occurring in April 1991. From the beginning, WAIS
to use the Z39.50-1988 standard as the information retrieval
between WAIS clients and servers. The implementation is still in
today by existing WAIS clients and servers resulting in over 50,000
users of Z39.50-1988 on the Internet

2.

The purpose of this memo is to initiate a discussion for a
path of the WAIS technology from Z39.50-1988 Information
Service Definitions and Protocol Specification for
Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3].
purpose of this memo is not to provide a detailed
specification, but rather to describe the high-level design goals
functional assumptions made in the WAIS implementation of Z39.50-
1988. WAIS use of Z39.50-1992 and Z39.50-1994 standards will be
subject of future RFCs

3. Historical Design Goals of

As an aid to understanding the original WAIS implementation and
use of Z39.50-1988, the historical design goals of WAIS are
in this section. Included with each goal is a brief description
the assumptions used to meet these design goals

1. Provide users access to bibliographic and non-
information, including full-text and images

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
documents existing in multiple formats (e.g., rtf, postscript, gif
etc.).

2. Keep the client/server interface simple and independent
changes in the functionality of the server




IIIR Working Group [Page 2]

RFC 1625 WAIS over Z39.50-1988 June 1994


To achieve this, the text string entered by the user was
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
server was no longer required by the client or the user, as is
of many existing Z39.50 implementations. In addition, the
software did not require modification to support the
functionality of the server

3. Provide relevance feedback capability

Relevance feedback is the ability to select a document, or portion
a document, and find a set of documents similar to the selection
WAIS included documents used in relevance feedback as part of
Type-3 query

4. Permit the server to operate in a stateless manner

A WAIS server was designed to be "stateless", meaning that
result sets were not stored by the server. In Z39.50 terms,
server exercised its right to unilaterally delete a result set
soon as it sent the search response. For this reason, the
Facility of Z39.50 was not used, and retrievals were performed
the Search Facility. Relaxing this constraint in
implementations may prove the most prudent path

5. Provide the ability for a client to retrieve documents
pieces

Because retrieval of a portion of a document could be done
ways with Z39.50-1988, specific assumptions were made to
this functionality. Accessing a portion of a document was
for both retrieval and for relevance feedback

6. Run over TCP

The Z39.50-1988 standard was designed to run in the application
using the presentation services provided by the Open
Interconnection (OSI) Reference Model. Due to the popularity
TCP/IP and the Internet, WAIS was designed to run over TCP. Use
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
developers used a recommended subset of Z39.50-1988 and
assumptions to fulfill its requirements. Over time, many of



IIIR Working Group [Page 3]

RFC 1625 WAIS over Z39.50-1988 June 1994


requirements have then gone into the definition of
versions of Z39.50. As new requirements become apparent, WAIS
document any additional assumptions and work with the ZIG
developing extensions

WAIS supported the Init and Search Facilities of Z39.50-1988.
search and retrieval were implemented using the Search Facility,
described in this section

Search was initiated by the client with a Search Request
(Application Protocol Data Unit) using a Type-3 query. The
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
full document, or portion thereof, to be used in
feedback. Each document object contains a
identifier (Doc-ID) [5], type, chunk-code, and start
end locations. The Doc-ID and type specify the location
format, respectively, of the document. The chuck-
determines the unit of measure for the start and
locations. Examples of chunk-codes used
byte, line, paragraph, and full document. If the chunk
is a full document, the start and end locations are ignored

A Search Response APDU returned by the server contained a
ranked list of records, or WAIS Citations. A WAIS Citation refers
a document on the server. Each WAIS Citation contains the
fields

1. Headline - a set of words that convey the main idea of
document
2. Rank - the numerical score of the document based on
relevance to the query, normalized to a top score of 1000.
3. List of available formats - e.g. text, postscript, tiff, etc
4. Doc-ID - the location of the document
5. Length - the length of the document in bytes

The number of WAIS Citations returned was limited by the
message size negotiated during the Init

Retrieval of a document was initiated by the client with a
Request APDU using a Type-1 query. The query contained up to
terms

1. Term: Doc-
Use Attribute: system-control-number code = "un
Relation Attribute: equal code = "re



IIIR Working Group [Page 4]

RFC 1625 WAIS over Z39.50-1988 June 1994


2. Term: the requested document
Use Attribute: data-type code = "wt
Relation Attribute: equal code = "re
3. Term: the start
Use Attribute: paragraph, line, byte code = "wp", "wl",
"wb
Relation Attribute: greater-than-or-equal code = "ro
4. Term: the end
Use Attribute: paragraph, line, byte code = "wp", "wl",
"wb
Relation Attribute: less-than code = "rl

Because full-text and images were often larger in size than
receive buffer of the client, clients were designed to
retrieve documents in chunks, specifying the start and end
of the chunk in the query. An example of a fully-specified
query is

query = ( ( use = "un", relation = "re", term = )

( use = "wt", relation = "re", term = postscript )

( use = "wb", relation = "ro", term = 0 )

( use = "wb", relation = "ro", term = 2000 )
)

A retrieval response was issued by the server with a Search
APDU. In this case a single record corresponding to the
document, or portion thereof, was returned in the specified format

5. Security

Security issues are not discussed in this memo

6.

[1] National Information Standards Organization (NISO).
National Standard Z39.50, Information Retrieval
Definition and Protocol Specifications for Library Applications
New Brunswick, NJ, Transaction Publishers; 1988.

[2] ANSI/NISO Z30.50-1992 (version 2) Information Retrieval
and Protocol: American National Standard, Information
Application Service Definition and Protocol Specification
Open Systems Interconnection, 1992.





IIIR Working Group [Page 5]

RFC 1625 WAIS over Z39.50-1988 June 1994


[3] Z39.50 Version 3: Draft 8", October 1993. Maintenance
Reference: Z39.50MA-034.

[4] Lynch, C., "Using the Z39.50 Information Retrieval
in the Internet Environment", Work in Progress, November 1993.

[5] "Document Identifiers, or International Standard Book
for the Electronic Age", Brewster Kahle, Thinking
Corporation, see URL=protocol/doc-ids.txt>,
September 1991.

7. Authors'

Margaret St.
WAIS
1040 Noel
Menlo Park, California 94025

Phone: (415) 327-
Fax: (415) 327-6513
EMail: saint@wais.


Jim
Clearinghouse for Networked
Discovery &
3021 Cornwallis
Research Triangle Park, North Carolina 27709-2889

Phone: (919)-248-9247
Fax: (919)-248-1101
EMail: jim.fullton@cnidr.


Kevin
Clearinghouse for Networked
Discovery &
3021 Cornwallis
Research Triangle Park, North Carolina 27709-2889

Phone: (919)-248-9247
Fax: (919)-248-1101
EMail: kevin.gamiel@cnidr.








IIIR Working Group [Page 6]

RFC 1625 WAIS over Z39.50-1988 June 1994


Jonathan
Thinking Machines
1010 El Camino Real, Suite 310
Menlo Park, California 94025

Phone: (415) 329-9300 x229
Fax: (415) 329-9329
EMail: jonathan@think.


Brewster
WAIS
1040 Noel
Menlo Park, California 94025

Phone: (415) 327-
Fax: (415) 327-6513
EMail: brewster@wais.


John A.
UC
289 Evans
Berkeley, California 94720

Phone: (510) 642-1530
Fax: (510) 643-5385
EMail: jak@violet.berkeley.


Harry
WAIS
1040 Noel
Menlo Park, California 94025

Phone: (415) 327-
Fax: (415) 327-6513
EMail: morris@wais.


Francois
FS
435 Highland
Rochester, New York 14620

Phone: (716) 256-2850
EMail: francois@wais.




IIIR Working Group [Page 7]








if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum