[WEB4LIB] z29.50 (was re: The Next Five Years)

[Jon Knight]

On Wed, 2 Jun 1999, Thomas Dowling wrote:
> That doesn't make z39.50 the correct solution for this problem.  Z39.50
> development is chugging slowly away in an insular little development
> community, while faster moving segments of the IT world are quickly
> putting together ways to manage and merge text databases in the terabyte
> range.  Their tools are more likely to be XML (perhaps RDF), something
> like a web spider, an off-the-shelf database program, and a few hundred
> lines of Perl.  Those are tools designed to do in six months what z39.50
> hasn't accomplished in six years.

Plus Z39.50 itself does not appear to be too hot at providing access to a
large number of dynamically changing information sources in response to a
single user query. The reason is that the basic protocol has no concept of
query routing so you have to either pre-configure clients to search
specific databases (OK if you only have a few and they rarely change) or
get users to enter the details of the Z39.50 servers themselves (which is
a bit less than userfriendly, especially as z3950s and z3950r URIs haven't
exactly taken the world by storm).  If you could just point a Z39.50
client at a local server, fire off your query to that and then get the
server to return not only matches from its own records but CIP index
records that the client could then use to route the query to other
potentially interesting servers it might be more of a goer. 

Despite some years of twiddling with Z39.50 servers, clients and gateways
I still think its a minority protocol that is finding it difficult to hit
the big time.  The web hasn't helped its cause as HTML and CGI scripts
running in one browser give users something very close to a universal
search interface (OK, the form widgets change from search engine to search
engine, but then so do the available attributes in Z39.50 servers).

Tatty bye,

Jim'll