[Koha-devel] Search Engine Changes : let's get some solr

[Thomas Dukleth]

Reply inline:


On Tue, October 12, 2010 12:41, Thomas Krichel wrote:
>
>   Frederic Demians writes
>>
>> >Just as a side note, zebra3 should be based on solr. So yet
>> >another point for solr.
>>
>> So, isn't it the best interest of the Koha community to wait that
>> Indexdata integrate Solr into Zebra? and in the meantime, switch
>> Koha-Zebra interface from GRS1 to Dom in order to gain in
>> granularity and customazibility.
>
>   Yes. In any case, the zebra documentation notes that GRS1
>   has been improved and replaced by DOM.
>

1.  WORK WHICH INDEX DATA IS DOING ALREADY.

>> And as suggested by Thomas Dukleth, Koha supporters could sponsor
>> directly Indexdata to speed up their work and give them a Koha
>> 'direction'. Who's better than Indexdata has deep knowledge of
>> search engine technlogy in Libraries arena?
>
>   And to appear credible to them, it wouldn't be best to adopt
>   their recent technologies, before asking them to develop
>   new ones?

If the Koha community would work with Index Data to support Solr/Lucene,
we would not necessarily be asking Index Data to develop any new
technologies which they had not already been intending to develop
themselves.

Index Data has added Solr/Lucene support to a several products for
querying Solr/Lucene servers and integrating the result sets with
Z39.50/SRU and other searches.  See
http://www.indexdata.com/blog/2010/09/solr-support-zoom-pazpar2-and-masterkey
and
http://www.indexdata.com/news/2010/10/yaz-411-available-now-solr-support .
 There may be some which have not yet had a public release.  I did not
check all the release notes.


2.  WORK WHICH INDEX DATA MIGHT DO.

I enquired with Index Data about the prospect of Solr/Lucene support in
Zebra.  Index Data has experimented with Solr/Lucene based indexing as
well as other options which might be used in a next generation server for
Zebra 3.  A next generation version of Zebra would need some commitment of
funding for development from interested parties which has apparently not
been a priority from their customers most recently.  However, given the
work done for experimentation, the funding needed might be more modest
than I would have expected otherwise.

There may be other more modest options for developing support for Zebra as
a Z39.50/SRU server which might be independent from Zebra as a complete
indexing server if possible.

What may be done with Zebra would depend upon the level of importance
which the Koha community attaches to having a good Z39.50/SRU server.  As
I previously stated, I speculate that most libraries using Koha care very
little about their own Z39.50/SRU server.

Again, I will explain later the importance of Z39.50/SRU and how needing
to support Z39.50/SRU for libraries is a necessity.


3.  WORK FROM KNOWLEDGE INTEGRATION.

I have not yet contacted Knowledge Integration to learn what is required
to obtain any useful documentation for JZKit and learn whether its
Z39.50/SRU feature set is as limited as it appears it may be from my
examination of the source code and configuration files.


4.  CLIENT VS SERVER SUPPORT FOR Z39.50/SRU.

I do not think that client side support for Z39.50/SRU is enough. 
However, there is a potential for regression of both client and server
support for Z39.50 when rewriting Search.pm without working with Index
Data if they are the only company supporting the requisite software.

Knowledge Integration seems to depend upon Index Data software on the
client side but perhaps Knowledge Integration has some additional options
to provide.  I will enquire.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783