Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!SRI-NIC.ARPA!isode-RELAY From: isode-RELAY@SRI-NIC.ARPA Newsgroups: comp.protocols.iso.dev-environ Subject: (none) Message-ID: <8906300759.AA10208@ucbvax.Berkeley.EDU> Date: 30 Jun 89 07:59:17 GMT Sender: usenet@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 77 Date: Thu, 29 Jun 89 17:22:54 PDT From: "Wayne Davison" To: ISODE@NRTC.NORTHROP.COM TO: Joe Rafail FROM: Wayne Davison SUBJECT: Z39.50 I don't know of any discussion groups or bboards for Z39.50 "Information Retrieval Service Definition and Protocol Specifications for Library Applications" or Z39.58 "Common Command Language for Online Interactive Information Retrieval." Given the growing interest in this area, it seems like time to set some up. Here at The Research Libraries Group we have a Z39.50 implementation, but not under Unix. You might check with someone at OCLC. Howard Turtle is a possible contact there; he is on bitnet as HRT@OCLCRSUN. The general OCLC phone number is 800-848-5878. I was interested in Marty Schoffstall's response to your questions. NYSERNet and OCLC have made some agreements on their implementation that are outside of the American National Standard and the draft ISO standard. There is a possibility that after the ISO standard is finished, the American standard may be revised. Any comments anyone has about the work in progress on the international standard would be most welcome. The next meeting on this subject is tentatively scheduled for late January, 1989 in Copenhagen. I am puzzled at Mr. Schoffstall's criticism that Z39.50 is at variance with OSI/ISO in not using the Remote Operations (ROS, or ROSE) notation. While some OSI application protocols do use this notation, many do not. For example, the Association Control, File Transfer, Transaction Processing, and Commitment- Concurrency-Recovery protocols do not use it. When developing Z39.50 we considered the use of ROS and rejected it for two reasons. First, there are currently some problems with the ROS macro notation; in some cases these macros cannot be expanded unambiguously. While these problems are being worked out it seemed best to avoid using ROS. Second, ROS is inherently half-duplex; there are some cases where we might not want to impose a rigid request-response discipline on the database client-server dialog. For example, the client might wish to cancel a request in progress before a resonse is received; or the server might make several responses to a single request, including multiple interim responses before sendng the final, complete response to a search request. I am also puzzled by Mr. Schoffstall's criticism of the Z39.50 "user query language." Z39.50 does not define a user query language. One of the primary design goals of Z39.50 was to provide for standardized process to process communication and to encourage systems to tailor the user interface to the needs of particular groups of users. Z39.50 does not specify what command language is to be used between the human user and the client application process. OCLC and NYSERNet did decide to use the Common Command Language to pass search queries; this is outside the Z39.50 standard. I certainly understand Mr. Schoffstall's frustration in dealing with MARC records; bibliographic data is very different from many of the data structures found in commercial applications. I am afraid that the complexities are inherent in the data and are not caused by the MARC format. It has been very difficult to get major vendors to be at all responsive to the particular requirements of the information retrieval community. I might also mention that in developing Z39.50 we did look carefully at the relational data model, but were unable to find any reasonable way to apply it to bibliographic data. Dr. Clifford Lynch at the University of California has done considerable work in this area. His phone number is 415-642-9485. I have had an opportunity to discuss many of these matter with Dr. Arms of CMU and he may be able to fill in some of the background for you. I would certainly welcome further communication regarding these matters if you would find that useful.