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). 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. It comes with the wip/solr branch. I hope I will be able to add some information as of how to set a box on that branch soon. Hope that helps. -- Henri-Damien LAURENT
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... , 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.
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. 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. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
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... , 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.
[...]
Reply inline: On Fri, February 11, 2011 08:14, LAURENT Henri-Damien wrote: [...]
Problem is that simply sending the marc generated by koha leads to this BAD MARC error.
What part of the server or client is reporting the "BAD MARC" error when sending ISO 2709 records but not reporting an error when sending MARCXML records?
So we are looking for information in order to know WHAT SimpleServer should be sending. We are still investigating.
[...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
participants (2)
-
LAURENT Henri-Damien -
Thomas Dukleth