W3C home > Mailing lists > Public > www-zig@w3.org > February 2002

RE: Z39.50 on the web (and in print)

From: Liv Aasa Holm <Liv.A.Holm@jbi.hio.no>
Date: Mon, 25 Feb 2002 08:29:00 +0100
To: Rob Bull <bull@crxnet.com>, Robert Sanderson <azaroth@liverpool.ac.uk>
Cc: <www-zig@w3.org>, Mike Taylor <mike@tecc.co.uk>
Message-ID: <3C79E051@p48-r508-1>
I have been following this discussion for a time.  One question to Rob S.: 
How does a client find your server? That is how does it find the address, 
the port number, if authentication is needed etc.?  The client will need 
this BEFORE it can make an INIT to your system.  This is where Explain Lite 
has been successful.  You can set up your client BEFORE sending an INIT.

Another point. Explain Lite does not have to be static, by that I mean "no 
more tags/fields added".  Just add the fields you think are missing, but do 
not use the existing tags for different content than today.

And all of you: please remember: we would like many systems (clients and/or 
servers) to be able to communicate via z39.50.  Then it has to be a simple 
way of getting to know how to start; how to actually contact another system.
Explain Lite does not prohibit the implementation of the full-scale Explain 
(or a subset of Explain according to a profile).  Just go ahead.  The 
statistics for the use of these implementations would be interesting.  The 
time MAY be right for another try.

But again: how should the average client find that Explain database?

Liv A. Holm

===== Original Message from Robert Sanderson <azaroth@liverpool.ac.uk> at 
23.02.02 20:45
>> >I think most people would be happy to get something together, even if it's
>> >not Explain mapped directly into XML.
>> agreed upon.  Thats why ONE-2 folks did explain lite - they have
>> already done the full explain service and needed something that would
>I'm sorry, but Explain Lite is simply not sufficient :(  Perhaps it might
>please some people, but I'm 100% certain that a better XML definition
>could be relatively easily agreed upon that could support better
>definitions of what Z can really do, with less confusion and better ease
>of autocreation.
>> If someone [tm] were to map out an attribute architectured way of
>> searching explain like records, then you could return them in GRS1, XML,
>> SUTRS or whatever else you wanted.  Just put them into a database
>> called... iR-exPlAin-2 [1] or whatever was agreed upon.
>> Not really - I am telling people about our servers in a consistent way
>> that does not need a Z39.50 connection. The XML data on the web
>I hear this a lot and it confuses me to no end.  Here we have a protocol
>that excels at search and retrieval, but people keep telling me that we
>shouldn't use even the basics of it for searching and retrieving records
>that describe our own databases.
>Am I the only person that doesn't understand this?  Why should a Z39.50
>client have all the vast amounts of code required to parse SOAP, when
>we've got everything already done for us using Z?!
>> delivered by the Z server. Editing XML is straightforward - there are
>> loads of tools out there - system administrators can understand it.
>> You simply cant edit GRS, or Explain-RS records that way - the records
>Err... you don't have X format databases in Z39.50, as Mike (IIRC)
>cheerily pointed out to me once.  You have a database, and the client
>requests records in whatever format it wants them in.  The server then can
>refuse to deliver them if it can't do whatever transformation it needs to.
>So you like XML, that's no problem, use XML for your underlying data store
>and map it into GRS1, MARC, SUTRS, or whatever else when you get requests
>for those record syntaxes.
>> You then don't have to worry about either taking an unnecessary hit on
>> init, or somehow connecting to a web server to get information about the
>> Z server.  Finding out where to go for the webserver is of course yet
>> another question that's unanswered -- may as well just use what we've
>> already got, eg Z39.50 databases with records in them.
>> - no - I can post a registry of servers and find that on Google etc.
>You the human agent can certainly do that, yes.  On the other hand a
>client should definitely not have to be use a completely different
>protocol, go to a search engine, parse the resulting web pages, and so
>As I asked before, unless I, the human agent, knows in advance where to go
>to find the XML record, how can I possibly know where to find it?  The
>machine with the Z database may not have a web server.  Or it may have
>more than one Z server running on it, administered by different people.
>Irwell.mimas.ac.uk for instance has at least 4 zservers running and
>probably more.  If a human agent can't find it, how can a client be
>expected to?
>Otherwise why use XML? Why not have instructions in plain old English (or
>other language or both) on how to configure your client?
>> Probably, but you have a big project behind you who all have to use it ;)
>> If you count all the Cheshire servers, then we may have you beat for
>> Explain capable machines.
>> - but where are the explain capable clients to use them ?
>We have one. I'm sure Sebastian has one. I expect that bell-labs has one,
>as their server has Explain and I would expect that they must have tested
>it.  I know Ashley has one, as he must have tested COPAC's explain data...
>Why don't you have one as well?
>http://gondolin.hist.liv.ac.uk/~cheshire/client/ has a whole slew of
>screenshots proving ours, if you want :)
>      ,'/:.          Rob Sanderson (azaroth@liverpool.ac.uk)
>    ,'-/::::.        http://www.o-r-g.org/~azaroth/
>  ,'--/::(@)::.      Special Collections and Archives, extension 3142
>,'---/::::::::::.    Twin Cathedrals:  telnet: liverpool.o-r-g.org 7777
>____/:::::::::::::.              WWW:  http://liverpool.o-r-g.org:8000/
>I L L U M I N A T I
===== Comments by Liv.A.Holm@jbi.hio.no (Liv Aasa Holm) at 25.02.02 08:20

Liv A. Holm
associate professor
Oslo University college
faculty of journalism, library and information science
tel. +47-22-45-27-77
Received on Monday, 25 February 2002 02:33:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:03 UTC