Z39.50 Discussion on Web4Lib

[Matthew Dovey]

Interesting on two counts of technical inaccuracy (and possible propogation
of myths we need to dispell)

> There are scalability issues with Z39.50.  Multithreaded searching of more
> than 5-7 institutions at a time can result in bottlenecks due to the
> client/server communications overhead.

Sebastian Hammer from IndexData has successfully searched about 200 Z39.50
targets simultaneously acheiving the same response time as searching 1
target. In fact the response time is determined by the slowest Z39.50
server, so when searching 200 you are statistically more likely to hit one
which is slow (due to insufficient hardware etc.) or down which can make the
search appear slower.

Of course it is possible to write bad multithreading code as well as good
efficient multithreading code, and I suspect that some programmers may have
made the claim you can't search more that 7 targets claim to cover poor
performance in their clients....

> Z39.50 uses, eseentially, the same registry concept that
> RDF, digital certificates and handles technology employ.  However, the
> client/server registry adds networking overhead.

This is not really true and essentially misleading. Z39.50 per se does not
really have a registry concept and certainly does not need one to work.
There are extensions (Explain and more recently Explain-lite) which allows
registry type applications but these are certainly not core to the protocol,
and many Z39.50 servers and clients do not even support these.

Matthew Dovey
Oxford University
----- Original Message -----
From: <peterson at amigos.org>
To: <www-zig at w3.org>
Sent: Friday, February 09, 2001 7:42 PM
Subject: Z39.50 Discussion on Web4Lib


> An interesting discussion on Z39.50 dying arose on Web4Lib today.  Because
> the ZIG will be looking at the future of the standard, I thought this
> email, which discusses one person's view of the technical side, might have
> a place in your discussion.
>
> Christine Peterson
> Library Liaison Officer, Amigos Library Services
> 14400 Midway Road, Dallas, TX  75244-3509
> 800/843-8482 x191 (message only)
> 512/671-1580 (phone and fax)
> EMAIL:  peterson at amigos.org
>
> ----- Forwarded by Chris Peterson/Amigos on 02/09/01 01:42 PM -----
>
> Everyone,
>
> There are scalability issues with Z39.50.  Multithreaded searching of more
> than 5-7 institutions at a time can result in bottlenecks due to the
> client/server communications overhead.  Standards for metadata harvesting
> such as OAI are emerging to address the complexity and network bottleneck
> issues of Z39.50.  Z39.50 uses, eseentially, the same registry concept
that
> RDF, digital certificates and handles technology employ.  However, the
> client/server registry adds networking overhead.  I think that future
> developments ought to divorce the registry aspect of Z39.50 from the
client
> and server and reference instead an independent "third-party" registry.
> Z39.50 should only use client/server functionality, if needed, for tuning
> the search engine to address the appropriate registry.   As search engines
> get smarter, even this requirement would drop off. This would integrate
> Z39.50 more tightly into XML-based distributed registry implementations,
> such as RDF, which has never gotten off the ground, I think because it is
> bound too tightly to the individual metadata record, which makes it very
> cumbersome and labor-intensive to employ.
>
> Z39.50 has a lot to offer that simpler harvesting protocols do
> not--granularity of searching to nontextual atrributes, to holdings, to
> segments of hierarchical records such as EAD Finding Aids.  I think the
> protocol needs some fine tuning to reflect the realities of the
distributed
> web networking environment but I don't think it is replaced by
technologies
> such as OAI, but rather complemented by them.
>
> Grace Agnew
> grace.agnew at libvid2.library.gatech.edu
>