Archivos de Tags: Lucene

Configurando SOLR

Empecemos con una definición de la página del proyecto Apache SOLR (traducida rápidamente)

SOLR es una plataforma de búsqueda de código abierto, evolución del proyecto Apache Lucene. Sus principales características incluyen la búsqueda de texto completo,  búsqueda facetada,  indexación en casi- tiempo real, la agrupación dinámica, la integración de bases de datos, documentos ricos (por ejemplo, Word, PDF) y la búsqueda geoespacial. SOLR es fiable, escalable y tolerante a fallos, proporcionando indexación distribuida,  replicación y consultas en configuraciones con equilibrio de carga, failover automatizado y recuperación, configuración centralizada etc..

SOLR está presente en las características de búsqueda y navegación características de muchas de las mayores webs existentes (Resumiendo: es una evolución de Lucene y es extremadamente potente)

 SOLR y Dspace

SOLR se usa en Dspace para lograr dos funcionalidades: estadísticas y búsquedas. Como nada es perfecto, el uso de SOLR se mezcla con antiguas capas de código pre-existente Lucene. Así tenemos que en Dspace version 1.7, 1.8 y  3, conviven las estadísticas del “sistema” a partir del procesado de los logs del sistema  Y  las estadísticas de uso y descarga, obtenidas a partir /solr/statistics. En el -ambito de la búsqueda, la situación es que con Discovery activado, la búsqueda se hará sobre el motor SOLR y sus índices, pero la navegación por índices se hace sobre Lucene (desconcierto garantizado). Está planificado simplificar esta situación en la versión 4, eliminando Lucene… veremos..

Configurando las búsquedas SOLR

Hoy veremos el segundo bloque funcional, las búsquedas. La buena noticia es que SOLR se configura mediante ficheros XML, la mala es que esta configuración es sustancialmente más compleja que la configuración Lucene.   Rompamos una lanza: SOLR tiene una potencia espectacular aunque resulte difícil de comprender su funcionamiento. Pero… ¿quien entiende el comportamiento de Google? ¿y quién lo usa? ¿a que no podríamos vivir sin él?    Pues comprender el funcionamiento de SOLR es complejo y su potencial es enorme, aunque quizá podamos conformarnos con realizar una serie de adaptaciones.

Como ejemplo de lo anterior, y ya que teníamos pendiente hablar sobre las configuraciones de diacríticos, pues vamos a comentar como lograr lo mismo que hacíamos en Lucene en este post.

Básicamente el proceso de construcción del índice Solr es la aplicación de una serie de transformaciones a nuestros campos (fields). Las transformaciones son del mimo tipo que las que aplicábamos en Lucene. En general se mantienen los nombres de las clases transformadoras y se les añade el prefijo “solr”, refiriéndose así a las clases java del paquete org.apache.solr.analysis.

Hay que especificarlas relacionándolas con el tipo de campo que queramos transformar, y esta relación se especifica dentro del fichero “principal” de configuración ../solr/search/conf/schema.xml.

En este fichero tenemos que localizar el <fieldType name=”text” ……> que es el que corresponde con los campos de tipo textual. Hay datos de múltiples tipos: numéricos, string, numéricos con ordenación textual, fechas, booleanos, hasta 39 diferentes contamos en schema.xml

pues bien dentro de esa etiqueta fielType, localizar

<filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt">

y cambiarla, añadiendo..

<filter class="solr.ASCIIFoldingFilterFactory"></filter>
<filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt">

Lo ponemos “antes” del Porter-Stemmer por las mismas razones que explicamos cuando configuramos el índice Lucene.  Ya de paso, y contestando una pregunta que nos hicísteis, aprovechamos para revisar en ese mismo fichero el operador lógico usado en las queries:

<!-- SolrQueryParser configuration: defaultOperator="AND|OR" -->

<solrQueryParser defaultOperator="AND"/>

Ahora nos queda reindexar SOLR. Nos parece que es más adecuado proceder a una reconstrucción completa del índice y por eso, la opción de borrado del índice.

..\bin\dspace update-discovery-index -b

Y ya debiera estar. Suerte.

Configurando el buscador Lucene, sobre alfabetos, diacríticos, stemmers ….

A raiz de algunas preguntas que aparecieron últimamente en las listas de GUDE , sobre anomalías en los resultados de búquedas, me comprometí a escribir sobre el tema. No se si este post arrojará alguna luz o confundirá aún más…espero que lo primero.

Este post es aplicable a las configuraciones de buscador basadas en Lucene, no en SOLR, es decir, todas las 1.6 y anteriores y las 1.7 y 1.8 que no usen la facilidad Discovery…

Nuestro camino empieza a partir de la línea en dspace.cfg:

search.analyzer = org.dspace.search.DSAnalyzer

es decir, el analizador estándar de Dspace, que como bien nos recuerdan, está diseñado para textos en inglés. Y este analizador tiene los siguientes filtros, aplicados en cascada:

  • StandarFilter -> labores preparatorias de conversión del texto en cadena de palabras para el resto de filtros
  • LowerCaseFilter–> conversión a minúsculas
  • StopFilter –> Elimina las palabras gramaticales o “vacías” , que no aportan gran significado a la búsqueda, como artículos, conjunciones, preposiciones, etc, a partir de una lista de exclusión o “stopword”. La lista original del filtro incorpora términos ingleses
  • PorterStemFilter–> El algoritmo de Raíces de Porter (es lo que significa Porter Stem) retira sufijos y otras terminaciones morfológicas comunes de las palabras inglesas. Y desde luego con el español, catalán, portugués, etc… no es donde ofrece sus mejores resultados….

Sobre PorterStemFilter: Básicamente mejora las búsquedas en inglés, obteniendo la raíz de una mayoría de términos. Así loving, loves, loved, lovable, .., se ven reducidas a lov- y se mejora sustancialmente la búsqueda. De manera colateral, y por eso su uso pasa desapercibido a los hispanohablantes, es un stemmer válido para algunos plurales, pero no todos, del español, ya que recordemos que no está diseñado para nuestro idioma.

Para los curiosos, el filtro implementa un proceso definido en 1979 por Martin Porter, y que puede verse aquí .. Como dice Porter, y otros antes y después, el algoritmo simplemente devuelve mejores resultados en las búsquedas automatizadas, en inglés. Mejores que si no se usa el filtro. Pero tiene, evidentemente, sus carencias y equivocaciones, ya identificadas por Porter.

Y de forma “histórica”, como un conocimiento pasado de instalación en instalación, y que nosotros mismos hemos implentado, la mayoría de instalaciones con textos en español, portugués, francés… han añadido, a continuación en la cadena de transformaciones un nuevo filtro:

  • ISOLatin1AccentFilter, que reemplaza los caracteres acentuados del juego de caracteres ISO Latin 1 (ISO-8859-1) por sus equivalentes sin acentuar, es decir reemplaza á por a.

Con esta configuración, y con este orden de transformaciones, entre otros efectos, las palabras terminadas en es, son consideradas plurales (en inglés, pero plurales) y reducidas a su raíz, singular, por el PorterStemFilter. Por contra, las palabras terminadas en és, no son reducidas, pues para este Filtro, si terminas en és no eres un plural. Los resultados de la búsqueda son así dispares…y de ahí las preguntas en GUDE.

Un poco de wikipedia: Un signo diacrítico es un signo gráfico que confiere a los signos escritos, no necesariamente letra, un valor especial.
Son diacríticos, por ejemplo, los acentos ortográficos ( ´ ; ` ), la diéresis ( ¨ ), los signos empleados en el alfabeto fonético, como la oclusión (^) o la nasalización ( ~ ), la tilde de la ñ (virgulilla), la cedilla ( ¸ ) , la colita ( ˛ ), la coma ( , ), el doble acento agudo, ( ˝ ), el carón ( ˇ ), el breve ( ˘ ), el macrón ( ˉ ), el anillo ( ˚ ), el punto ( . ), el acento circunflejo ( ^ ) y el garfio ( ̉ ).

Otro poco de wikipedia: ISO 8859-1 es la norma de la ISO que define la codificación del alfabeto latino, incluyendo los diacríticos (como letras acentuadas, ñ, ç), y letras especiales (como ß, Ø), necesarios para la escritura de las siguientes lenguas originarias de Europa occidental: afrikáans, alemán, aragonés, asturiano, castellano, catalán, danés, escocés, español, feroés, finés, francés, gaélico, gallego, inglés, islandés, italiano, neerlandés, noruego, portugués, sueco y Euskera.
También conocida como Alfabeto Latino n.º 1 o ISO Latín 1.

Dicho esto, señalar que ISOLatin1AccentFilter ha sido retirado, “deprecated”, por Apache Lucene y ha sido sustituido por ASCIIFoldingFilter (hubo un ISOLatinACCENT por el intermedio..). Los detalles de la sustitución, aquí.

Esta clase mejora la ISOLatin1Accent, ya que ésta solo trataba el primer bloque de BASIC Latin, y lo amplía incluyendo (y filtrando a sus caracteres base) una larga lista de extensiones: C1 Controls y Latin-1 Supplement, Latin Extended-A, Latin Extended-B, Phonetic Extensions, General Punctuation, Superscripts and Subscripts, etc…

Y también señalar que Lucene tiene un org.apache.lucene.analysis.es.SpanishAnalyzer, que puede ser declarado en dspace.cfg como sustitución a org.dspace.search.DSAnalyzer. Las implicaciones de esta sustitución, es que en vez de usar la cadena StandarFilter -> LowerCaseFilter–> StopFilter –> PorterStemFilter–> ISOLatin1AccentFilter, usa el filtro definido por SpanishAnalyzer, un SpanishLightStemFilter. Las malas noticias son que las pruebas que hemos realizado con este Stemmer son ¿decepcionantes?, con un tratamiento desconcertante de las palabras agudas acentuadas terminadas en o, a y e …os suena, ¿verdad? No obstante, nos reservamos una segunda evaluación más pausada sobre este filtro.

ya casi… Conclusiones o recomendaciones

  • Seguir adoptando y adaptando org.dspace.search.DSAnalyzer, no cambiar a org.apache.lucene.analysis.es.SpanishAnalyzer, en tanto Lucene no mejore el Stemmer de español incluido por defecto.
  • Posiblemente cambiar ISOLatin1AccentFilter por ASCIIFoldingFilter. No mejorará radicalmente los resultados de ninguna búsqueda, pero si en el futuro se retira de las librerías Apache, el build no os dará problemas
  • Dependiendo del idioma predominante en nuestro Repositorio, valorar quitar PorterStemFilter de la cadena del analizador. Si requerís un Stemmer, otra opción, que hemos probado y aparentemente no tiene los problemas reportados en las listas GUDE, aunque a lo peor tiene otros efectos colaterales, es invertir el orden de los filtros PorterStem e ISOLatin1/ASCIIFolding.

con lo que org.dspace.search.DSAnalyzer nos podría quedar así:

import org.apache.lucene.analysis.ASCIIFoldingFilter;
..
..
result = new StandardFilter(result);
result = new LowerCaseFilter(result);
result = new StopFilter(result, stopSet);
result = new ASCIIFoldingFilter(result);
result = new PorterStemFilter(result);

Ya terminamos

Sobre todo, recordar los objetivos de un analizador: simplemente devolver mejores resultados en la mayoría de consultas. Es una transacción. Si dejamos pelada la cadena de análisis, los resultados serán extremadamente precisos, en el sentido de ofrecer solo resultados coincidentes con la cadena de búsqueda, pero no estaremos aprovechando las posibilidades de Lucene y nos habremos dejado en el camino un porcentaje amplio de resultados relevantes. Vuestra decisión.

(y perdón por que esta vez me ha salido un rollo)
(y sacaremos un post con la configuración propuesta para SOLR)