🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.protocols.iso.dev-environ
Article #34

(none)

#34
From: isode-RELAY
Date: Fri, 30 Jun 1989 07:59
77 lines
4363 bytes
Date:  Thu, 29 Jun 89 17:22:54 PDT
From:  "Wayne Davison" <BB.WED@RLG.BITNET>
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.
Technical Details
Message-ID: <8906300759.AA10208@ucbvax.Berkeley.EDU>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!SRI-NIC.ARPA!isode-RELAY

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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