Re: RE: searching the nlm catalog

> (i) ZOOM, the Z39.50 library of choice, which you, John,  
> discovered, covers mostly the request side, but there remain  
> still some crucial additions to perform:
>  * configuring the connection
>  * interfacing the query dialogue
>  * reading the results
> 
> (ii) For a connection we have to know host, port, databse,  
> password etc. as well as the list of fields that are searchable.
> 
> (iiI) Supposedly, one would wish tu hide some of the low-level  
> details from the user, but I have no idea how to organise this  
> interface between the generic and the database specific code.

I've not yet completely experimented with these python eggs for that
problem, but an elegant solution would be to provide a nicely
pre-packaged egg for every database to support. With the model I
proposed in my previous mail, we could have a nice architecture that is
both easy to extend for developers (few code to write for integrating a
new system), and easy to manipulate for users (everything lives in a
single file)

> (iv) With regard to the parsing (reading) of the results, the  
> problem is one of embarrassment of the riches. MARC data are so  
> rich and of so good quality that one would like to exploit them  
> more thorougly than by  taking but author and title.

:-)

> One final point.  Contrary to what you seem to believe, MARC  
> data are standardised to a very high degree, much more so than  
> any other class of data. That is one of the reasons why it is  

Except in Switzerland, which has the highest number of variants per
inhabitant :-) It remains impressively coherent though, especially when
compared to random bibtex files you can fetch on the web.

Frédéric

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEIah7FjQHpltE9KURAiW0AKC6alcilFC+3L+JNGrgIztw16oCAACcCXtS
K4MsLJwNwJqvGUtyeukFFF4=
=7f4C
-----END PGP SIGNATURE-----