Reading joshua proposals for search in 2.4 (http://wiki.liblime.com/doku.php?id=koha24rmnotes) I see many improvements that are interesting for everybody & "easy" to add with our actual tools (& some that are already done in CVS ;-) ) my question is : should we add some technical requirements to Koha 2.4 ? things like Perl modules or non-perl modules (like yaz, that is a requirement for z3950 client & server) ? I think we should be very careful in "components" selecting. Koha is hard enough to set up, we should not make is harder. (for example : did Plucene need something else that Plucene.pm package ? cpan.org was not clear to me) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
my question is : should we add some technical requirements to Koha 2.4 ? things like Perl modules or non-perl modules (like yaz, that is a requirement for z3950 client & server) ?
I think we should be very careful in "components" selecting. Koha is hard enough to set up, we should not make is harder. I think this is an excellent question. If we do add more components we'll need to make sure they are a part of a long-term strategy to support something we really want. For example, I was recently contacted by a
On Mon, May 09, 2005 at 11:11:54AM +0200, Paul POULAIN wrote: potential client wondering whether Koha supported any archival standards such as EAD (http://www.loc.gov/ead/). Currently, adding support for EAD would require some way to insert EAD records into the Koha SQL database (currently split between MARC and old Koha tables). If we were using Lucene, it would be a simple matter of creating an index on those records since they're in XML. I really like the idea of seperating our database into two databases: one is a database of bibliographic (and other) records; the other is a database _about_ the books (things like holdings, item statuses, location, etc.). Koha's SQL is pretty good at handling the database _about_ the books, though I think we could optimize it to work even faster -- but as far as handling the database of bibliographic records, SQL is quite limited in terms of scalability and flexability. Lucene or other textual database engines have lots of nice feature built in, things like boolian searching, relevance ranking, full-text searching, etc. -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE CEO, LIBLIME migration, training, maintenance, support jmf@liblime.com Koha ILS, Mambo Intranet, DiscrimiNet Filter 1(740)707-7654 TRY OUR FULL DEMOS AT http://liblime.com
On Wed, May 11, 2005 at 05:09:18PM -0700, Joshua Ferraro wrote:
Koha's SQL is pretty good at handling the database _about_ the books, though I think we could optimize it to work even faster -- but as far as handling the database of bibliographic records, SQL is quite limited in terms of scalability and flexability. Lucene or other textual database engines have lots of nice feature built in, things like boolian searching, relevance ranking, full-text searching, etc. Sorry to reply to my own post but I thought I should clarify something.
I don't mean to say that we should scrap Koha's MARC tables, etc. What I am trying to say is that for search purposes, a textual database does a much better job than SQL does. Based on what I've learned so far, a textual database would allow us to create extremely useful indexes of marc records (indexes that we might even be able to create directly from the database -- I'm not sure if it would require an export to a markup language first). These indexes would allow us to perform very powerful query operations on our records that would have far too much overhead in SQL (the tables get too big too fast, and boolian operations, relevance ranking, spellchecking, etc. are pretty complex in SQL). Also, textual indexes are FAST! Additionally, adding new record formats to search in the catalog (like EAD) would be much simpler if our search API were independent of one kind of record format (MARC). -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE CEO, LIBLIME migration, training, maintenance, support jmf@liblime.com Koha ILS, Mambo Intranet, DiscrimiNet Filter 1(740)707-7654 TRY OUR FULL DEMOS AT http://liblime.com
participants (2)
-
Joshua Ferraro -
Paul POULAIN