RE: ZNG dicussion

I like much in the idea of ZNG. It uses mainstream technology, and it has
a human readable transfer protocol.

However, I think Sebastian is right. Without the library community, the
supporters of Z39.50 would be very few and far between, so a new protocol
that does not improve the life for librarians is rather likely to be very
marginal. 

The state of the art today is that I can take just about any Z39.50 Origin
and direct at just about any library Z39.50 target, enter a search and get
results back in the form of a MARC record or plain text (SUTRS). Most
servers will even provide me with a record that is rather close to teh
MARC21 standard. This was not the case when I entered this business in
1997. At that time we were struggling to get origins and targets to talk
to each other at all. The tiny set of attributes supprted by one piece of
software was normally not compatible with what another supported.

Since then, the world has improved substantially, and with the Bath
profile, we got something that can be seen as a standard for what a
library Z39.50 implementation should provide. It will take several years
before a majority of servers and clients will provide the full
functionality, but having the profile gives people a common target to
strive for.

The big remaining issues for searches are in two areas. The first one is
to find common grounds on the level above the Z39.50 protocol and the Bath
profile. It includes things like what, in the context of Z39.50,
constitutes a normalised name. It is a difficult task indeed, because
practice differs between nations, and even within nations.

The second one is the extension of functionality. Cataloguers want a
standard way of handling Authority records. Patrons want access to
holdings and circulation information. Some people want to mix languages
and character sets. Some people want more precision in their searches. ILL
librarians want support for ordering and tracking items. Library financers
want the researchers and the public to service themselves with checkouts
and reservations and searches so they can fire all the librarians.

I think that the only path to success is to continue building on the
current platform and gradually change into something that is more in beat
with the times. We also need to give some of the people some more of what
they want out of Z39.50, but I don't think we can give everything to
everyone. Let's focus on what the protocol is made for - Search and
retrieval.

Some of the most important babies of the Z39.50 protocols are, in my
opinion, thrown out with the bathwater in ZNG. The first one is the
combination of the type-1/type-101 queries in combination with the BIB-1
attribute set. This is a powerful, non database-specific, easy to parse
way of expressing queries. It can stand improvements in clarity and
extensibility, but in general, I haven't seen anything better in
implementation. I think this intermediate form between the search that the
user expresses, and the search that is passed to the search engine is
important, and one of the great features of Z39.50. Both ends of the
search are direct and concrete, one in the universe of the user, the other
in the universe of indices and records. Computer Science research has
shown time and time again that the translation to an abstract intermediate
form greatly simplifies the adaption to different environments.

The second baby that I see floating down the drain is the ability to split
search and present. We do today have a protocol that is capable of
handling both session oriented and sessionless searches. It isn't all that
elegant, and it may need refinement, but I think it is a big strength that
would go away.

As for the ugly trolls:

ASN.1/BER is there, and the only people it makes happy are the
consultants. However, before it can go away from the library world, we
have to go through a step similar to Mike Taylors ZOOM ideas. Only after
you have isolated the lower layers can you replace them with any
confidence. I actually see the use of ASN.1 even in an XML environment.
What is needed is an ASN.1->XML compiler.

Explain, extended services, different segmentations, GRS-1, E-spec,
E-spec-q, bobsearches etc. - haul them all off to appendices with clear
warning signs. "Hazardous material. Enter at own risk." Some of them may
be taken up in the library community at large, but which ones remains to
be seen.

Jacob Hallén

 On Thu, 27 Sep 2001, Sebastian Hammer
wrote:

> Guys,
> 
> For what it's worth, my main problem with ZNG is that I believe it 
> threatens the success of Z39.50 *in any form*. Why? Because it doesn't 
> solve any current business need of the libraries that are currently using 
> Z39.50. That means uptake will be slow and sporadic. In the meantime, it 
> sucks the attention of the ZIG away from the concrete busines needs of 
> libraries, and it confuses potential implementor's about our intentions -- 
> like that big fat link to ZNG that Ray used to keep on the maintenance 
> agency front page but which he has now thankfully removed.
> 
> Here's a perspective from the Danish deployment of Z39.50. Your mileage may 
> vary.
> 
> Virtually any major library system vendor on the market has already 
> implemented Z39.50. Interoperability at the encoding and protocol level is 
> pretty much problem free (because of ASN.1 or in spite of it -- it makes no 
> difference). What libraries desperately *do* need is a standardised way to 
> exchange holdings info. They need someone to take the lead in proposing a 
> standard mechanism for handling loan requests that can be used together 
> with Z39.50. They need clean-cut profiles to take the ambiguity out of 
> Bib-1. They need to resolve a whole host of semantic and functional 
> interoperability issues having to do with the different ways that different 
> search engines work, and what they are and aren't capable of. ZNG does 
> *not* address these issues. Even if the ZIG miraculously manages to get all 
> the vendors to implement ZNG, or to acquire and integrate suitable 
> gateways, when the dust clears, libraries will still be struggling with the 
> exact same problems that they are struggling with today.
> 
> In my opinion, it's not the time or place for the ZIG to define a new 
> information retrieval protocol. If the XML community comes up with one and 
> it is picked up by industry, then by all means let's look at it. But I 
> don't think the ZIG has the clout, or the breath of requirements required 
> to propose a new protocol that will become widespread outside of libraries.
> 
> What we need to do, again in my opinion, is to attack with great vigor 
> those real-life business requirements of libraries that are trying *today* 
> to do real work with Z39.50, and to come up with new interesting things 
> they can do with the protocol. By all means let's improve the 
> specifications and the APIs to make our work easier... but to sit here and 
> geek out over encodings when we don't yet have the semantic stuff under 
> control is just plain dumb.
> 
> Just my 2 Euro cents.
> 
> --Sebastian
> 

        NetGuide                        http://www.netg.se/
        TerraTel AB                     jacob@netg.se
        Tankegĺngen 4                   031 - 50 79 40
        417 56 Göteborg

Received on Thursday, 27 September 2001 12:27:28 UTC