[Koha-devel] Our own developments (searchs && displaying)

[Ernesto Silva]

Hi,
   as I've wrote a month or so ago we've developed a new search module 
for koha 2.2 based on Full Text Indexing off MySQL 5. I've also sent it 
to this list, I didn't have the time to translate the documentation to 
English, so it went in Spanish. Nobody made any comments on this, so I 
guess nobody care, which is perfectly reasonable is 3.0 is in 
development with Zebra.

Anyway, I want to mention our new development, which I suspect Paul and 
company have already considered and integrated into 3.0. And... I 
confess... I didn't take a look to the last koha version, not even the 
2.2 serie.

We are developing a new display module where you can define new formats 
to display biblios (Marc, ISBD, bibliographic, tabular, 
supercalifiagilisticoespialidoso, etc.).
Similar to issuing rules there will be a matrix indexed by "itemtype" 
and "display format". Each format could be present in OPAC or Intranet. 
Every matrix cell  indexed by the itemtype and  the format specified by 
the user (or a default format if none is defined) will contain an XSL 
specifying the output.
As our librarians very often differ on itemtypes specification, we 
decided that this specification must be filled by them. So, we will took 
part of our new search grammar and use it to specify the itemtype, and 
example could be:

     245^h CONTAINS 'impr' OR 245^h EQUALS 'serial' AND ....

We've developed a much more rich field^subfield specification, it's 
actually a list of marc fields where even each one can be specified with 
wildcards and exceptions, something like:

   245^*,100^a,6*^j EXCEPT (245^i, 65*^*) CONTAINS 'impr'.....

This is not a real search equation to find an itemtype, but there you 
can see what I'm talking about.

When the system runs it will loop over a list of biblios and evaluate 
the equations trying to match one of them, there it will find the 
itemtype (or use the default one).
The other parameter, the format, could be specified in 2 ways, actually 
hard coded in some template like in the search results or by the user 
selecting it from a list of available formats.
With this system you can even show to the user only the existing formats 
for an specific biblio, the ones defined depending on it's calculated 
itemtype.

If the system runs slow we can try to generate perl expressions from our 
own grammar and store them in the database, so we can evaluate them 
during itemtype discovery, we can even try to cache some of them, I 
didn't thought of this too much yet, nor till we've got the first 
version an make some speed tests.

Here is an example of the matrix:

        | default | MARC    | ISBD    | supercalifriag....
itemtype | format  | format  | format  | format
---------+---------+---------+---------+-------------------
eqn. for | Create  | Create  | Create  | Create
books    | or Edit | or Edit | or Edit | or Edit
---------+---------+---------+---------+-------------------
eqn. for | Create  | Create  | Create  | Create
videos   | or Edit | or Edit | or Edit | or Edit
---------+---------+---------+---------+-------------------
eqn. for | Create  | Create  | Create  | Creat
Tesis    | or Edit | or Edit | or Edit | or Edit
---------+---------+---------+---------+-------------------


As I said in my previous message, we can provide our full koha code, well, in 
this case I think we can also provide the specific code for this improvements 
as we're trying to make it as clean and pluggable as we can.

Please contact me if any of this can be of any help.

Best regards,

--
Ernesto Silva.
Coordinador de Desarrollo Web y Sistemas Abiertos
Centro de Procesamiento de Datos
Universidad ORT Uruguay.
E-mail: address@hidden
Tel: (+598-2) 902-1505 ext. 206
Fax: (+598-2) 900-2952