Dear all,
Attached is a presentation I gave on eLib's experiences with Z39.50 at the
Washington DC Z39.50 Implementers Group (ZIG) last week. I hope I didn't
grossly misrepresent anybody/project (I did do the usual disclaimer that the
comments where my own etc. etc.).
There is a meeting of the ZIG in September 2001 in the UK - this maybe an
opportunity for the various projects to make presentations which go into
more depth. The ZIG are interested both in real applications of Z39.50 but
also in learning where Z39.50 wasn't used where it could or should have been
and the reasons why it wasn't used. They are keen to improve the standard
both in its accessibility/usability as well as functionality.
Finally, Sebastian Hammer of IndexData gave an interesting report on his
findings in large cross-searching with Z39.50. They developed a simplified
Z39.50 client which just did cross-searching (i.e. a command line user
interface etc.). They found that the performance when searching 100 Z39.50
databases was no worse that searching a single database. In general the
response time for searching 100 Z39.50 servers was that of the slowest
server (e.g. if all servers responded within 1-2 seconds the cross-search
would respond within 1-2 seconds). The reason why problems may occur when
searching large numbers of databases tend to be either because the
particular gateway software itself is not well written to scale to that size
or for statistical reasons (it is more likely when searching 100 databases
that one will be slow!). As an aside, one European virtual union project
determined that the poor performance of their gateway was due to a slow
server. The site in question had not been aware of this since prior to the
clump project the server was only accessed from 6 dedicated internal OPACs.
This should be noted, since I suspect many institutions may have servers
sized on internal access only which may need to be upgraded if the intent is
to provide access over the internet (via a virtual catalogue or directly!)
This, of course, has obvious repercussions in how large a virtual catalogue
can be. There are of course other issues - when search 100 catalogues the
number of hits will be in general 100 times more than when searching 1, and
this number of hits will have implications on the usability of the interface
(if the searches aren't particularly precise) and on any post-search
manipulation of results (e.g. sorting).
Matthew
<<Digital Libraries.ppt>>
|