Authority Control en DSpace

El Control de Autoridades o Authority Control es una de las piezas clave a disposición de los responsables de Repositorios Digitales para mejorar la calidad de contenidos y posibilitar la interoperabilidad entre repositorios.

Una autoridad es un conjunto de valores controlados para un dominio determinado, estando cada valor único identificado por una clave (clave de autoridad).

Un registro de autoridad es la información asociada con cada uno de los valores en una autoridad (incluyendo variaciones de deletreo, valores equivalentes y/o alternativos, etc).

Una clave de autoridad es un identificador opaco y persistente correspondiente a un registro de autoridad.

En la práctica habitual, un registro de autoridad (de nombres de autor, por ejemplo), contiene la forma autorizada del nombre del autor, establecida por la institución normalizadora como forma preferida para visualizar en sus sistemas, así como las formas variantes del nombre y nombres relacionados. Además, el registro de autoridad puede contener información relativa a la persona, representada por el punto de acceso), así como a las relaciones entre esa persona y otras entidades relacionadas, información para identificar las reglas de acuerdo con que se establecieron valores controlados, las fuentes consultadas, la agencia de catalogación encargada de establecer la normalización y la agencia responsable de establecer las formas preferidas del nombre.

Objetivos del Control de Autoridades

  • Dar consistencia e integridad a los metadatos
  • Conseguir mejorar la precisión en la recuperación de la información
  • Facilitar el intercambio de información bibliográfica

El modelo de authority control de DSPACE

El modelo de autoridades de Dspace aparece en la versión 1.6 de forma estándar, pues previamente era una pieza de código separada como add-on. La implementación en Dspace es de un framework que mediante configuración permite conectar (plug-in) clases programáticas para controlar dos aspectos básicos: Cómo se realiza la selección de valores en un metadato (choice management) y la inclusión de valores de autoridad asociados a los valores de metadatos (Authority Control).

Por tanto, no ofrece funcionalidad alguna para la gestión de las autoridades, de los registros de autoridad o de las claves de autoridad, que se consideran fuera del ámbito de DSpace y que por tanto se deberán gestionar mediante un aplicativo externo o bien desarrollos adicionales de DSpace.

Junto con el código que ofrece la funcionalidad de control de autoridades, se distribuyen con DSpace una serie de conectores con servicios de autoridades ya existentes, a modo demostrativo, como el Servicio de Nombres de la Biblioteca del Congreso (Library of Congress Names service) y el servicio de autoridades de nombres de revistas y editores Sherpa-Romeo, entre otros

Funcionalidades básicas del framework

  • Choice Management: En los elementos del Interfaz de usuario que se ocupan de la edición de metadatos (principalmente módulo de envíos para usuarios de autoarchivo u módulo de edición de metadatos para administradores) se pueden incluir funcionalidades que asisten en la selección de valores de los metadatos que se hayan configurado. Para dichos campos de metadatos se pueden generar listas de valores a partir de vocabularios extensos, navegación por tesauros jerárquicos, selección cerrada a los valores de una lista, lista abierta, …
  • Authority Control: El control de autoridades proporciona incluye la clave de autoridad junto con el valor del metadato seleccionado. Señalar que los metadatos controlados por autoridad deben llevar asociado el plugin Choice management. La información de autoridad consiste del valor del metadato, el valor de la clave de autoridad (authority key) y el denominado valor de confianza (confidence value), cuya utilidad explicaremos más adelante.
  • Visibilidad de las claves de autoridad y de los valores de confianza: En la interfaz OAI_PMH se expone únicamente el valor del metadato, (ya mencionamos antes la limitación del protocolo para exponer valores de autoridad) estando ocultos los valores de autoridad y de confianza (confidence value). Esto lo pongo alto y claro para evitar tentaciones: ES UNA MALA PRÁCTICA EXPONER LA CLAVE DE AUTORIDAD O EL VALOR DE CONFIANZA COMO METADATO, ESTOS VALORES SON EXCLUSIVOS DE DSPACE PARA SU CORRECTO FUNCIONAMIENTO.
  • Indices de autoridad:  Una característica normalmente poco conocida es la posibilidad de construir índices (browse o search indexes) que contengan sólo valores con clave de autoridad asociada. Así podemos tener un índice de autores y otro índice que incluya sólo autores validados. Además, la inclusión de un valor validado en este índice puede ser controlada mediante el valor de confianza (seguir leyendo..)
  • El valor de confianza (confidence value) se expresa como un valor simbólico dentro del rango siguiente: (aceptado, incierto, ambiguo, no encontrado, fallido) y puede asignarse adicionalmente al valor de clave de autoridad. A continuación, podemos especificar el nivel inferior de confianza que es necesario para incluir un valor de metadato en el índice construido, con lo que el índice así construido, incluirá los valores validados con ciertas condiciones, que sobrepasen ese nivel inferior (minimun confidence value).
  • Los registros de autoridad son externos a DSpace, es decir, DSpace no incluye ninguna funcionalidad para gestionarlos, depurarlos o ampliarlos, es decir, no incluye la posibilidad de añadir o asociar un valor adicional a un registro de autoridad ya existente. Típicamente es una base de datos de la institución, un proveedor externo, un servidor de vocabularios, etc… La arquitectura de plugins de DSpace permite integrar conectores a estos servicios de forma simple, sin tocar el código original de DSpace.

nota: este post es un extracto readaptado de la comunicación realizada por Sergio Nieto y Emilio Lorenzo en el congreso internacional Biredial 2013 celebrado en Costa Rica. Disponible aquí

Interfaz OAI en DSpace 3.x

En la versión 3 de DSpace se ha incluido una nueva Interfaz OAI-PMH que, además de facilitar la adecuación del Repositorio a los aspectos derivados de la recolección, puede simplificarnos la compatibilidad con las Directrices DRIVER y OpenAIRE.

Hasta ahora, se podía interrogar a un Repositorio mediante el uso de comandos OAI-PMH, emitidos desde cualquier navegador (al fin y al cabo el protocolo PMH se apoya en http) puesto que la mayoría de ellos están incluyen el soporte para que sus contenidos sean recolectados por los agregadores vía este Protocolo.

Considerando el caso habitual de que el OAI esté desplegado en el directorio [webapps]/OAI/ de DSpace, las consultas OAI-PMH son de la forma:

URL base de la instancia DSPACE/oai/request?verb=Xxxxx

Siendo Xxxxxx  los verbos utilizados para las consultas OAI-PMH, cada uno de ellos con una serie de atributos y modificadores, y cuya sintaxis se describe en el documento del estándar del Protocolo (http://www.openarchives.org/OAI/openarchivesprotocol.html#ProtocolMessages), los siguientes:

Identify, ListRecords, ListSets, ListMetadataFormats, ListIdentifiers y GetRecord.

A partir de la versión 3 de DSpace, se ha añadido una hoha de estilos que posibiliat realizar las anteriores consultas utilizando una Interfaz gráfica, que facilita sobremanera dicha tarea.

Clipboard02Además, la nueva versión, ha integrado una nuevas librerías OAI (xOAI, que sustituye al código OAI usado en anteriores versiones, originario de OCLC) que posibilitan la implementación de diferentes Interfaces OAI para cada uno de las necesidades de sets virtuales que requiera el Repositorio, de acuerdo con sus requerimientos en materia de metadatos, facilitando la creación de estos sets virtuales, mediante operaciones de filtrado y la transformación. Esto es de gran utilidad para el cumplimiento de Directrices como DRIVER y OpenAIRE.

Las Interfaces DRIVER y OpenAIRE, se muestran realizando las siguientes consultas, respectivamente:

URL base de la instancia DSPACE/oai/driver?verb=Identify
URL base de la instancia DSPACE/oai/openaire?verb=Identify

Básicamente, se ha realizado una reforma completa, realizada por la empresa portuguesa Lyncode,  que podría considerarse una evolución natural del Addon OAI-Extended (puesto que los compañeros de Lyncode provienen de una amplia experiencia desde la empresa KeepSolutions y desde Repositorium de la Universidade do Minho)  basándose en un framework OAI mejorado.

La estructura del assetstore

Mientras que el modelo de datos de Dspace (metadatos, workflows, estructura del repositorio, usuarios..) está soportado por la base de datos Oracle o Postgresql, los contenidos de los ítems se almacenan en el sistema de ficheros denominado assetstore.

La configuración tradicional del assetstore se realiza en el fichero dspace.cfg, mediante el parámetro:

assetstore.dir = [dspace]/assetstore para un solo sistema
assetstore.dir = [dspace]/assetstore_0
assetstore.dir.1 = /mnt/other_filesystem/assetstore_1       para más de un sistema.

La localización física de un objeto se guarda en la base de datos por lo que es de especial importancia NO mover los bitstreams entre assestores (además, el backup del assetstore tiene que formar parte de cualquier estrategia de backup). Aunque hay procedimientos para fusionar y mover assetstores, no son triviales, y los explicaremos en algún momento futuro.

Por defecto, los bitstreams nuevos se guardan en el assetstore 0 (es decir el especificado por la propiedad assetstore.dir) Para usar nuevos assetstores (cuando se nos está llenando el que usemos) hay que añadir un linea a dspace.cfg que referencie dónde deben ir los nuevos bitstreams:

assetstore.incoming = 1

Cuando se rearranque Tomcat, los nuevos envíos se archivarán en el assetstore especificado en assetstore.dir.1

Recordemos que además del fichero de contenido «tal cual» que se ingesta en el sistema, Dspace guarda una variedad de ficheros adicionales (los comentamos en este post).  Todos estos ficheros se almacenan en el assetstore en una estructura del tipo:

Clipboard05

 

Siguiendo con este mismo ejemplo,  la referencia de un ítem a «sus» ficheros se encuentra en la tabla bitstream, campo Internal_id. Así, por ejemplo, si me encuentro este identificador,  110832826281924074367996140570931140204, este fichero (bitstream, en nomenclatura dspace) se encuentra buscando los seis primeros dígitos del identificador, que indican en que Subdirectorio de tercer nivel está el item ( 11 >> 08 >> 32) y el nombre real del fichero será 826281924074367996140570931140204 (ha desaparecido toda referencia a xxx.pdf, y similar).

Clipboard07

p.d: Incidentalmente esto parece indicar que el límite máximo de un assetstore es referenciar/almacenar 100*100*100 bitstreams
p.d: Si tenemos mas de un assetstore, deberemos buscar el fichero en el assetstore indicado en el campo bitstream.store_number de la tabla bitstream.

Arvo Consultores en Biredial 2013

Este año Arvo Consultores también asistió a Biredial 2013 en la cita de Costa Rica. Hasta ahí viajó Sergio Nieto, para impartir un taller sobre el Control de autoridades en DSpace, en el cual explicamos el porqué de esta funcionalidad authority control, las particularidades de su implantación en DSpace y los consejos y recomendaciones para su implantación exitosa.

IMG-20131017-WA0001

En el evento, agradecer a Meilyn Garro y al resto del comité organizador de la Universidad de Costa Rica la bienvenida que nos brindaron. Esperamos la programación de Biredial 2014 y que según parece puede que se realice en Brasil… eso el tiempo nos lo dirá.

Para mas información sobre lo que ocurrió en el evento, programa y demás no dejen de consultar la siguiente página de Biredial   http://biredial2013.ucr.ac.cr/index.php/Biredial2013/ai

Si desean ver las fotos de los participantes al evento en facebook:

https://www.facebook.com/media/set/?set=a.682451368454664.1073741828.136503766382763&type=3

Embargo en DSpace 3.x

Hasta la versión 3 de DSpace, el embargo era una restricción temporal de acceso a los bitstreams de los ítems. Durante el período de embargo, los metadatos de los ítems seguían estando disponibles para cualquier usuario, pero los bitstreams sólo estaban disponibles para usuarios administradores. El ámbito o duración del embargo podía variar, pero el hecho de que con el tiempo expirase era lo que lo distinguía de otras restricciones a los contenidos.

En la versión 3 de la herramienta, esta funcionalidad se ha extendido con una opción avanzada, que se establece en la siguiente línea del fichero dspace.cfg:

 xmlui.submission.restrictstep.enableAdvancedForm = true

El embargo avanzado permite establecer embargos para bitstreams de manera individualizada, añadiendo nuevas políticas de acceso a los mismos. Ofrece al usuario la oportunidad de gestionar manualmente las políticas de acceso a los bitstreams, con lo que además de poder establecer el embargo para los usuarios anónimos, se hacen posibles situaciones como establecer el embargo para cualquier usuario excepto para los pertenecientes a un grupo determinado, o establecer el embargo para ciertos grupos y no para otros, etc.

Adicionalmente, se ha incluido la posibilidad de hacer privados los ítems, permitiendo controlar la visibilidad de sus metadatos en los diferentes índices de la herramienta (búsqueda, navegación, discovery, etc), así como en las interfaces externas (REST-API, OAI-PMH, etc). En este caso, sólo los usuarios administradores podrán acceder a los ítems privados, con la nueva opción “Items Privados” del menú “Administrativo”, que les permite visualizar la lista de ítems privados existentes.

También es posible ajustar el estado “Público/Privado” de un ítem después de que haya sido archivado en el repositorio, con un nuevo botón disponible en la pantalla de edición de ítems. Pero hay que tener en cuenta que una vez el estado de un ítem sea privado, sólo los administradores podrán acceder a ellos para cambiarlo al estado público.

Hay que señalar que los usuarios de la Interfaz JSPUI todavía no podrán beneficiarse de algunas de estas mejoras, ya que por en la version 3 sólo están disponibles para la Interfaz XMLUI.

Incorporar javascript en DSpace

Alguna vez se nos ha ocurrido introducir algo de comportamiento dinámico en nuestro repositorio DSpace, ya sea para cambiar el comportamiento de la página sin necesidad de cargar una nueva, o por el hecho de introducir efectos que solo javascript nos puede proporcionar.

Si cumples las anteriores condiciones, entonces continúa leyendo esta mini guía en la cual explico de una forma muy simple como introducir un fichero javascript para modificar el comportamiento en XMLUI.

Antes de nada, es recomendable tener un conocimiento básico en lo referente a la creación de temas en XMLUI, puesto que, para insertar un comportamiento javascript a DSpace vamos a tener que usar los temas ya definidos por DSpace (el método recomendado es crear un tema nuevo copiando el existente y a partir de ahí, aplicar los cambios)

Los ficheros que vamos a tener presentes son varios:

[dspace-instalación]/webapss/xmlui/themes/[nombre_del_tema]/[nombre_del_tema].xsl

[dspace-instalación]/webapss/xmlui/themes/[nombre_del_tema]/sitemap.xmap

[dspace-instalación]/webapss/xmlui/themes/[nombre_del_tema]/lib/fichero.js

Para que no suene tan abstractas las rutas, vamos a tomar de ejemplo el tema Classic y hacer las modificaciones sobre él, por lo que el primer fichero descrito antes sería… (suponiendo que el dspace-instalación esté ubicado en el directorio raíz con nombre dspace)

Classic.xsl

Ruta: /dspace/webapps/themes/Classic/Classic.xsl

En este fichero hemos de coger la información pertinente para luego poderle añadir el comportamiento javascript. Por ejemplo si queremos que en el menú aparezca un icono * que al hacer click sobre él nos despligue nueva información, hemos de coger el template correspondiente de la carpeta DRI que controla la zona del menú, pegarlo en nuestro fichero Classic.xsl y ahí lo editamos añadiendo el icono *.(Insisto, esta parte requiere un conocimiento base sobre cómo editar un tema en XMLUI)

Una vez introducido el componente por el cual nos comunicaremos con el javascript, solo nos falta añadir el fichero javascript que controlará la funcionalidad. Este fichero se ha de colocar dentro de la carpeta del tema en cualquier ubicación, aunque lo recomendable es usar la carpeta lib de cada tema.

Este fichero javascript una vez creado por el desarrollador, y ubicado en la posición del tema que queramos, lo único que necesitamos para que funcione es relacionarlo con la información añadida en el fichero XSL. Para hacer esto debemos de hacer la llamada a nuestro javascript desde el fichero XMAP, de tal forma que al pinchar sobre el icono *, este llame al javascript ubicado en la carpeta de nuestro tema a través del fichero XMAP.

Esta llamada va a tener un aspecto tal que así

<map:parameter name=»javascript#2″ value=»lib/fichero.js»/>

En el ejemplo se llama a un fichero llamado fichero.js que está ubicado dentro de  la carpeta lib de nuestro tema. He de decir que el name que se da en la llamada tiene que ser único, si no, DSpace nos generará un error.

NOTA: En el ejemplo hemos puesto javascript#2 puesto que ya hay una declaración posterior que es javascript (Esta hace referencia a jquery). El nombre que se le dé siempre es conveniente que siga el patrón siguiente: javascript#numero. El porqué hacerlo así es muy simple: DSpace a la hora de montar la página Web va a incluir esas llamadas a los javascript en el meta  y estás han de tener un orden lógico (este orden coincide con el orden alfabético de las peticiones) puesto que si no, DSpace va a tener problemas a la hora de hacer llamadas a Javascript.

Vamos a ver un ejemplo del fichero Classic.xmap

<map:parameter name=»javascript» value=»lib/jquery.js»/>

<map:parameter name=»javascript#2″ value=»lib/fichero.js»/>

Este fragmento de código se ha de introducir dentro de de una etiqueta del XMAP llamada

<map:transform type=»IncludePageMeta»>

Ojo, que esta etiqueta viene definida dos veces dentro del fichero, ya que este fichero antes de aplicar nada, tiene que verificar en qué navegador se está trabajando, (diferencia entre IE6 y el resto de navegadores, por lo que se ha de incluir el fragmento de código antedicho en ambas etiquetas)

Con todo esto ya podemos insertar de forma elegante código DSpace dentro de un tema dado en XMLUI.

Ya para acabar, simplemente decir que si queréis ver un ejemplo de código javascript incluido dentro de un tema, podéis consultar el código fuente incluido en el tema Mirage, en el cual hay algo del comportamiento javascript montado tal y como acabo de relatar.

Versionado a nivel de ítem en DSpace 3.x

En la versión 3 de DSpace se ha incluido un sistema de versionado a nivel de ítem, que permite acceder a la historia de un ítem y posibilita el citar una versión particular del mismo.

El versionado a nivel de ítem es una nueva funcionalidad que permite construir la historia de un ítem. Los usuarios Administradores generales y los Administradores de Comunidad y Colección, tienen ahora la oportunidad de crear una nueva versión de un ítem existente cada vez que se hace un cambio en el mismo.

Cada versión de un ítem está representada por un identificador de versión independiente, que la deja accesible y permite que pueda ser citada. En las versiones anteriores de un ítem, se muestra un mensaje señalando el identificador de la versión más reciente del mismo.

Es necesario indicar que sólo la versión más reciente de un ítem se muestra en los resultados de las búsquedas.

Por defecto, la funcionalidad de versionado a nivel de ítem, sólo soportada en XMLUI, está desactivada. Para proceder a su activación, hay que descomentar la siguiente línea del fichero xmlui.xconf:

<aspect name="Versioning Aspect" path="resource://aspects/Versioning/" />

Actualmente, no existe una opción de configuración para permitir a los usuarios publicadores crear nuevas versiones de un ítem. Esta funcionalidad se limita a los Administradores generales y a los Administradores de Comunidad y Colección. Sin embargo, en un contexto donde los envíos originales de ítems a DSpace se realizan por usuarios no Administradores, tendría sentido que también pudiesen crear nuevas versiones, especialmente teniendo en cuenta el hecho de que las nuevas versiones tienen que pasar a través del flujo de trabajo definido.

Es importante tener en cuenta que al establecer el versionado a nivel de ítem, por defecto, el nombre y el email de los publicadores son visibles para todos los usuarios en el historial de versiones del ítem.

historial de versiones

De momento, la única solución para esto consiste en ocultar el historial de versiones a los usuarios generales, y dejarlo disponible sólo para usuarios Administradores. Para ello, hay que cambiar a true el valor del parámetro item.history.view.admin del fichero versioning.cfg ubicado en el directorio [dspace]/config/modules/.

Request-copy add-on para XMLUI

El módulo Request-copy para xmlui ha sido puesto a disposición de la comunidad Dspace. Es una  conversión al XMLUI de la funcionalidad que en su día (la primera versión era para Dspace 1.3 ¡¡) desarrolló la Universidad de Minho para JSPUI.

La funcionalidad de ‘Solicitar copia’, ‘Request Copy’ o ´Fair dealing button’, que con esa variedad de nombres se refiere esta funcionalidad en la documentación de repositorios, funciona de la siguiente forma:

  1. En todos los items restringidos, es decir no-OA (considerando éstos los que tienen permisos de acceso diferente de Anónimo) se muestra un link a «Solicitar una copia al autor»
  2. El usuario solicitante debe rellenar un formulario con sus datos de contacto y razones de su solicitud.
  3. Esos datos se envían al usuario que realiza el depósito (autores o persona delegada en su nombre).
  4. El autor (o depositante) puede responder al solicitante, usando dos posibles opciones «enviar copia» y «no enviar copia», con mensajes editables.
  5. El mensaje, tal y como lo redactó el autor, se envía al solicitante, con el fichero adjunto, si esa es la opción seleccionada.

El desarrollo se ha realizado en el marco de un proyecto para el Instituto Español de Oceanografía que ha considerado adecuado liberar el código, en palabras textuales, «para que todo el mundo pueda utilizarlo». El código correspondiente a esta función está disponible en un repositorio git , asociado al ticket Jira .

Exprimiendo el interface XMLUI

Ya hemos explicado en otro post las diferencias entre  XMLUI  y JSPUI, dando unas pinceladas sobre el funcionamiento de XMLUI. Nuestra inclinación es más o menos clara, preferimos XMLUI:  permite aplicar  apariencias  diferentes a distintas colecciones, nos parece que separa mejor la lógica de negocio de la lógica de representación, etc …

Pues en este post daremos algunos comandos para acceder a alguno de los puntos intermedios de la cadena cocoon de transformación y que nos podrían ayudar en nuestros procesos de desarrollo y debugging.

Intentaremos (si no nos borran nuestro ejemplo) trabajar con este item http://demo.dspace.org/xmlui/handle/10673/590 (si no funciona, usar cualquier otra URL de un Dspace/XMLUI)

DRI
Para obtener el DRI subyacente debajo de esa URL, tenemos que escribir DRI/
después del path xmlui/
http://demo.dspace.org/xmlui/DRI/handle/10673/590

XML
Para obtener el XML de dicha URL, teclear:
http://demo.dspace.org/xmlui/handle/10673/590?XML
fijaros en todas las etiquetas i18n, es decir estamos antes de aplicar la transformación i18n

Idioma, i18n
Para forzar la aplicación de un idioma (sin tener que cambiar el idioma del navegador)

http://demo.dspace.org/xmlui/handle/10673/590?locale-attribute=es

http://demo.dspace.org/xmlui/handle/10673/590?locale-attribute=en

Tema
A la hora de elegir el tema o «theme» que queremos para nuestra instancia de DSpace es bastante engorroso indicar cuál queremos que sea visualizado editando el fichero [dir_instalación]/config/sitemap.xconf en sus últimas líneas…
Existe un parámetro, en el fichero de configuración dspace.cfg llamado:

xmlui.theme.allowoverrides

y si lo descomentamos y lo activamos a true podremos, podemos forzar (momentáneamente) el uso de los temas que tengamos definidos en nuestro directorio de Themes

http://demo.dspace.org/xmlui/handle/10673/590?themepath=Classic/

http://demo.dspace.org/xmlui/handle/10673/590?themepath=Reference/

Como es de suponer, si vais haciendo esto por los Dspace/xmlui de por ahí os encontrareis que niguno cambia, porque por defecto este parámetro va desactivado en el dspace.cfg. Solo lo recomendamos activar en procesos de depuración de Temas.

Mets
Y si eres de los que enredan con las XSL, esta es la URL necesaria para arrancar tus desarrollos:
http://demo.dspace.org/xmlui/metadata/handle/10673/590/mets.xml

Un saludo

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.