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: silva@ort.edu.uy Tel: (+598-2) 902-1505 ext. 206 Fax: (+598-2) 900-2952