[Koha-devel] Solr and Z3950 server some news.

LAURENT Henri-Damien henridamien.laurent at biblibre.com
Fri Feb 11 09:14:29 CET 2011


Le 11/02/2011 01:08, Thomas Dukleth a écrit :
> Reply inline:
> 
> 
> On Tue, February 8, 2011 09:29, LAURENT Henri-Damien wrote:
>> Hi
>> We are getting a pretty nice working z3950 server for solr there.
>> We are parsing RPN queries quite generally using a perl module
>> Regexp::Grammars::Z3950::RPN
>> and  RPN2Solr
>> It is working quite well for simple usage (no exp1 or gils queries).
> 
> Hooray.  I greatly appreciate the work which BibLibre are doing for
> supporting a Z39.50/SRU server using Solr/Lucene.
> 
> I note that the tests for SimpleServer using Solr/Lucene,
> http://wiki.koha-community.org/wiki/SimpleServer_as_a_Z39.50/SRU_Server_Test_Queries_for_Koha_with_Solr/Lucene
> , are as underpopulated as I had left them when I had to return to working
> on a non-library project.  I took the time to write this message but I do
> not have the time to completely populate the tests presently.
> 
> An important point of the few tests which I had included is that useful
> functionality such as stemming should not be activated for a Z39.50/SRU
> query unless specifically specified in the query.  In the case of copy
> cataloguing, avoiding matches not specifically specified in the query is
> very important.  Copy cataloguing use might need the opposite defaults to
> what may most often benefit OPAC users.  If providing or avoiding various
> forms of query expansion cannot be specified at query time for
> Solr/Lucene, then we will need separate indexes with different defaults to
> which queries may be directed as appropriate to the query.
Yes, could be achieved with separate indexes and some tweaking to the query.
But at the moment, we have not embedded Stemming or approximative
search, so it would be the default behaviour.

> 
>>
>> But at the moment it is serving right only marcxml and not ISO2709. I
>> think we may have to try and determine exactly what type of data the
>> Z3950 server is supposed to send to yaz-client when serving "MARC" data.
> 
> YAZ can convert between MARCXML and ISO 2709.  YAZ can perform both server
> and  client functions.  I have not investigated precisely how to pass
> MARCXML to YAZ for returning ISO 2709 as a server side function, although,
> I have implemented such conversions as client functionality.  I do not
> have time to investigate presently.
Problem is that simply sending the marc generated by koha leads to this
BAD MARC error. So we are looking for information in order to know WHAT
SimpleServer should be sending.
We are still investigating.
Friendly
-- 
Henri-Damien LAURENT

> 
> A Z39.50/SRU server should return records in accordances whatever record
> syntaxes are specified as supported in the explain record.
> 
> Universal practise for Z39.50 server support of record syntax differs from
> the standard in that a single Z39.50 server database is only expected to
> support one record syntax.  Support for different record syntaxes over
> Z39.50 is obtained in practise by providing different database targets on
> the server which may be specified by the server as different database
> names or the same database name but running on a different port.  In the
> case of SRU, it is common for a single database target to support multiple
> record syntaxes and return the record syntax which is specified in the SRU
> query.
> 
> We are still a long ways from an ISO 2709 free world, therefore, a server
> which only returns MARCXML is insufficient.  I note that the default Zebra
> Z39.50 server configuration in Koha seems to only return MARCXML, but that
> is a configuration deficiency.  We should also not presume that a
> Z39.50/SRU client is using YAZ, although, a YAZ based client would be best
> as the primary client for testing.
> 
> [...]


More information about the Koha-devel mailing list