PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|RFC|rfc1625.txt =

page 2 of 4




   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=

1| < PREV = PAGE 2 = NEXT > |3|4

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.0225661 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)