Archivos de Tags: discovery

Liberada la versión 5 de DSpace

Enviado por cfernandez el 2015/01/26 8 comentarios

El 21 de enero de 2015 se produjo la liberación de Dspace v5.0, tras un proceso de desarrollo que arrancó hace un año, y que tuvo su pre-versión el pasado 3 de noviembre cuando comenzó el Testhaton.

Señalaríamos que incorpora una larga lista de pequeñas correcciones, pero que su característica principal son las funcionalidades añadidas (por eso es una versión, claro..) y que pasamos a revisar rápidamente:

El tema Mirage2 para XMLUI. Bien, qué quéreis que os digamos, no es exactamente una novedad, pero es una excleente noticia su incorporación a la versión 5. El tema Mirage2 de @tmire nos gustó según lo vimos en su presentación «oficial» en el Open Repositories de Helsinki en junio de 2014. Tanto nos sedujo que lo empezamos a implantar en versiones 4 de inmediato y ya llevamos varias.

Actualización automática de datos en las migraciones a la versión 5. Simplifica la ejecución de los scripts de actualización de los esquemas de BBDD y migra los índices SOLR. Es un avance sobre el ¿proceso? artesanal actual de migración. No se si lo pondríamos en una lista de nuestras prioridades, pero bienvenida la simplificación.

Importación de SIPs desde el interface de usuario. Pschee, la parte más compleja de una importación no es la ejecución del comando desde la UI o desde el CLI, sino la propia creación del paquete.

REST API con CRUD (Create/Read/Update/Delete). Esto ya está mejor, sobre todo porque estabilizará el paisaje de proliferación de interfaces REST que había por el universo DSPaciero. Recordemos que aunque otras interfaces REST (la de Hedtek, p.ej.) ya posibilitaban el Create/read/update, lo que se necesitaba , y así se discutió en DCAT y otros foros de desarrollo, era la continuidad de las soluciones adoptadas. La api usada es la JAX-RS: Java API for RESTful Web Services.

Todos los DSpaceObjects con soporte de metadatos. Esto es interesante. Esta extensión es la que posibilitará (posibilitará, porque la interface de usuario aún no se ha extendido para poder gestionar el nuevo modelo) flexibilizar la infraestructura de metadatos, que hasta ahora era aplicable sólo a los ítems, a las Comunidades, colecciones, e-persons, grupos, …

Soporte Linked (Open) Data mediante una interface RDF. A partir de esta versión se podrán publicar contenidos del repositorio en forma de Linked Open Data. No obstante, no todo es tan sencillo, pues la instalación de Dspace hay que complementarla con otra webapp, un Triple Store, es decir una base de datos que almacene de forma nativa el modelo RDF. El sistema, puede servir Apache Fuseki, debe soportar SPARQL 1.1 Query Language y SPARQL 1.1 Graph Store HTTP Protocol.

Las estadisticas de Google Analytics ahora recogen las descargas de bitstreams (p.ej, las que vienen directamente de Google Scholar y que antes no se recogían como eventos) y se pueden visualizar (al menos si se usa Mirage2)

Se ha realizado una primera integración con los identificadores ORCID mediante la generación de un nuevo índice SOLR de autoridades. La clave de autoridad enlaza ahora con metadatos adicionales, entre los que se incluyen el identificador ORCID y nombres alternativos de autor. Esto sólo funciona en XMLUI, y bien, resuelve problemas de identificación de autores a las organizaciones que usan este identificador, pero no es la integración con las ORCID_API que estábamos esperando.

Y más mejoras, como la Creación de Thumbnails con ImageMagick / Ghostscript; la Autogeneración de páginas de cubierta PDF en la descarga de los objetos, la función lookup sobre SHERPA/RoMEO y alguna funcionalidad adicional, las puedes ver aquí.

Ordenación del índice de navegación por títulos

Enviado por Eva Braña el 2014/10/27 Comentarios desactivados

La ordenación de los resultados de los índices de navegación de DSpace, es un tema bastante controvertido y a veces resulta desconcertante para los usuarios de la herramienta.

En primer lugar, hay que tener en cuenta que el índice de navegación por Títulos que ofrece DSpace, no considera una serie de «palabras vacías» para la ordenación de los resultados mostrados en el mismo. Estas palabras vacías son consideradas como «no indexables», y por lo tanto, no son tenidas en cuenta para dicha ordenación.

En esta lista de palabras vacías aparecen por defecto los artículos en diferentes idiomas, como el artículo «el» en español, o su equivalente en inglés «the». Sin embargo, es importante tener en cuenta que para que estas palabras sean correctamente ignoradas en el idioma correspondiente, el idioma del metadato del título (dc.title) debe haber sido introducido de manera apropiada. Es decir, si el metadato del título está en «en_US», se ignora la lista de palabras inglesas, mientras que si está en «es_ES», se ignoran las españolas.

Esto no se tiene en consideración en muchos Repositorios, pudiendo encontrarse criterios mezclados, con coexistencia de ítems en los que el artículo «el» se ignora (apareciendo ordenados por la segunda palabra del título), e ítems en los que el artículo “el” se tiene en cuenta para la ordenación (apareciendo ordenados en la letra “E”).

Pongamos por caso un título que comience por «El derecho constitucional…»: Si su título está en español (el idioma del metadato debe ser el español), la partícula “el” se ignora y el ítem aparece indexado en la letra «D», mientras que si su título no lleva idioma o está señalado erróneamente como inglés, el ítem aparece indexado en la letra «E».

Pensemos ahora en un título que comience por «The love is…»: Si el idioma del título es el inglés, este ítem aparece indexado en la letra «L», puesto que la partícula «the» es ignorada en la ordenación del mismo. Si por el contrario el metadato del título no lleva idioma o está marcado como español, el ítem aparece en la letra «T».

Finalmente, y para aportar mayor claridad, acompañamos esta explicación con una imagen extraída del índice de títulos de un DSpace, y a continuación explicamos por qué la lista de títulos aparece ordenada de esa forma:

El título «The apple» se ha introducido en inglés, por lo que la herramienta ignora la partícula «the» y se ordena por la letra «A» de la palabra “apple”. Por eso aparece en el primer lugar.

El título «El destino final» está en español, por lo que en este caso se ignora la partícula «el» y se ordena por la «D» de la palabra «destino».

El título «El actor principal» está sin idioma, por lo que la partícula «el» es considerada para la ordenación. Si el título estuviese en español, la partícula “el” se ignoraría, y el título pasaría a la primera posición, ya que se ordenaría por la letra “A” de la palabra “actor”.

Finalmente, el título «The last function» también está sin idioma, y por ello la partícula «the» es considerada para la ordenación, apareciendo el ítem, por lo tanto, ordenado por la letra “T”.

Para entender la ordenación que siguen los resultados del índice de títulos de DSpace y que ésta sea óptima, no sólo se debe tener en cuenta la lista de palabras ignoradas en la ordenación, sino también la apropiada introducción del idioma del metadato que almacena cada título.

Configurando SOLR

Enviado por cfernandez el 2013/05/14 5 comentarios

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.

Traducción al español de Dspace 3.0 disponible

Enviado por cfernandez el 2013/01/11 2 comentarios

Ya está puesta a disposición de la comunidad la traducción al español de la versión 3.0 e interfaz XMLUI. El fichero messages_es.xml está incorporado en la distribución de la versión 3.0, aunque también se encuentra disponible en el ticket jira 1398.

En ese mismo tícket está disponible el fichero de traducción de los mensajes correspondientes al Discovery, y señalar que por premuras de ensamblaje de la versión 3.0, no pudimos incluir la traducción de los módulos SwordClient y XMLWorkflow. Recordar que desde la version 1.8, cada módulo distribuye su propio messages.xml, separado del messages.xml principal, de manera similar a la fragmentación de los ficheros de configuración…

Como en ocasiones anteriores, hemos revisado algunas de las traducciones de mensajes que veníamos arrastrando de versiones anteriores, intentando luchar algo contra el desorden natural de los mensajes…. Pues eso, sean benevolentes.

Probamos DSPACE 3.0. Y nos gusta…

Enviado por cfernandez el 2012/10/30 Comentarios desactivados

Pues no pudimos esperar más y nos bajamos e instalamos la Dspace 3.0-rc1 release. Realizamos la décimosegunda descarga, y nosotros pensando que llegábamos tarde….

El proceso de instalación, sobre un Ubuntu 9, Postgresql y Tomcat 6 que estaba en una máquina virtualizada fué nítido y rápido, y voilà, ya teníamos un Dspace3.0 con xmlui para probar. Mientras redactamos una evaluación detenida, os podemos contar algunos de los temas que destacan (y que estábamos esperando) de esta versión. No es una lista exhaustiva de todo lo bueno que contiene esta versión, que es mucho, y que lo podéis encontrar aquí.

Versionado a nivel de item. La historia de un item está disponible y es posible citar una versión particular de un item.

Modificaciones al sistema de embargo. Ya no se require el uso de los crontab (embargo-setter y embargo-lifter) para aplicar las restricciones, sino que se usa el AuthorizationManager, definiéndose una Embargo Resource Policy que hace uso de las fechas de comienzo y fin de las ResourcePolicies. Tendremos que echar una pensada sobre esta implementación. Ya os contaremos.

Mejoras al Discovery. La gente de @atmire sigue marcando diferencias y en esta versión la lista de propuestas para Discovery/Solr es abrumadora: resaltado de keywords, recomendaciones, nuevo tratamiento de las facetas, etc… Y SOBRE TODO:

Han portado el Discovery a JSPUI (gracias al apoyo de la Universidad de Hong Kong). Enhorabuena a los usuarios de JSPUI, ahora tendrán la popsibilidad de usar Discovery
Y Solr tiene en cuenta los derechos de acceso a un item, de modo que detecta que si el usuario no tiene accesos de lectura, ese ítem no se muestra en los resultados en las búsquedas. Para todos aquellos que en un momento dado buscamos ocultar items y colecciones y no lo logramos porque al final aparecían en los resultados de los buscadores, este es un avance sustancial. Habrá que probar esta función en detalle.

Mejoras al sistema de estadísticas. Aparte de que se han incluído estadísticas de search en colecciones/comunidades específicas y estadísticas de los workflow, aparecen una serie de utilidades para el tratamiento de grandes ficheros de log, con el fin de intentar minimizar el problema que generan los logs en instalaciones con mucho tráfico.

Envíos basados en tipo de documentos. Esta era una solicitud que venía de lejos (Google Summer of Code, un ticket jira DS-464, muy antiguo y una adaptación-patch a la versión 1.8 con el código del ticket jira DS-1127). Se dirige a la necesidad de muchos repositorios de adaptar los formularios de envío (input-forms) a los diversos tipos de objetos del repositorio. Hasta ahora la única solución era definir colecciones diferenciadas, cada una con un <form> adaptado. El enfoque ha cambiado, y se han incorporado en los <field> restricciones a su visualización dependiendo de determinadas características de los objetos que se describen. Posiblemente un enfoque más cómodo que el anterior.

OAI 2.0 basado en xOAI, aportado por la empresa Lyncode, antiguos Universidad do Minho y Keep solutions, creo. Permite la creación de sets virtuales, filtrado y transformación. Entendemos que es una reforma completa, o quizá evolución natural del OAIextended, pero basado en un framework OAI mejorado. Lo evaluaremos.

Tratamiento de formatos bibliográficos. Los scripts de importación disponen ahora de una opción que a partir del Biblio-Transformation-Engine es capaz de importar metadatos ¿y bitstreams? de los formatos Endnote, BibTex, RIS, TSV, CSV. Pues esto hay que probarlo en detalle..

Activar Mirage y Discovery

Enviado por Adán Román el 2012/05/03 9 comentarios

Una de las principales propuestas de DSpace 1.7 fue la funcionalidad de búsquedas Discovery. Desarrollado, y cedido a la comunidad DSpace, por la empresa AtMire, el sistema de búsquedas por facetas (faceted search) es de indudable atractivo para las nuevas instalaciones y posiblemente imprescindible en instalaciones con un número de items elevado, pues las facilidades de búsqueda en esos entornos necesitan ser «reforzadas».

Faceted search, also called faceted navigation or faceted browsing, is a technique for accessing information organized according to a faceted classification system, allowing users to explore a collection of information by applying multiple filters (wikipedia)

Para poder manejar correctamente el nuevo sistema de búsquedas, se distribuye conjuntamente con la release, el tema Mirage (y ahora debe quedar claro que hablamos de XMLUI, no de JSPUI) como complemento visual de la funcionalidad Discovery.

En este post va a proceder a explicar como se hace para activar Mirage y Discovery en nuestro Dspace 1.7 o 1.8.

ACTIVACION DE MIRAGE

Tendremos que ir al fichero xmlui.xconf ubicado en [dspace-instalación]/conf/xmlui.xconf

Ahí vamos a quitar los comentarios referentes a la linea

<!–<theme name=»Atmire Mirage Theme» regex=».*» path=»Mirage/» />–>

Por lo que nos quedaría de la siguiente forma

Una vez hecho esto, debemos comentar el tema que se estuviese usando, normalmente el tema Reference, es decir:

y añadirle los comentarios, dejándola así.

<!– <theme name=»Default Reference Theme» regex=».*» path=»Reference/» /> –>

Por ahora no hemos hecho mas que cambiar un tema por otro. Llega ahora la hora de la verdad, activar el faceted search.

ACTIVACIÓN DE DISCOVERY

Activar Discovery supone en primer lugar sustituir las transformaciones (aspects) relacionadas con la búsqueda de XMLUI por las nuevas transformaciones que supone Discovery. Para ello, en el fichero xmlui.xconf ubicado en la ruta [dspace-instalación]/conf/xmlui.xconf tenemos que desactivar la linea referente al uso del SearchArtifact, y activar la correspondiente al Discovery. Así, hay que comentar la linea siguiente:

quedando la línea de la siguiente forma

<!–<aspect name=»Searching Artifacts» path=»resource://aspects/SearchArtifacts/» />–>

y siendo consecuentes, descomentar la línea de Discovery:

<!–<aspect name=»Discovery» path=»resource://aspects/Discovery/» />–>

quedando la línea de la siguiente forma

El siguiente paso que tenemos que modificar el fichero dspace.cfg, cambiando un par de parámetros:

event.dispatcher.default.consumers

y añadirle a la derecha el parámetro discovery quedando de la siguiente forma.

event.dispatcher.default.consumers = search, browse, discovery, eperson, harvester

La siguiente línea a tocar es la siguiente:

recent.submissions.count

En este caso pondremos el parámetro a cero quedando así la línea:

recent.submissions.count=0

Ya estamos finalizando. El último fichero que debemos comprobar es el dspace-sorl-search.cfg, ubicado en la misma carpeta que los anteriores ficheros. Simplemente chequear que la dirección de nuestro dspace/solr coincide con la especificada en el fichero ¿aún no habíamos dicho que Discovery se apoya en SOLR?… Aseguraros que SOLR está desplegado y funcionando en vuestro Tomcat.

Bien, buscamos la línea:

solr.search.server = http://localhost:8080/solr/search

y ahí debemos comprobar que el puerto de acceso es correcto, lo cambiamos al nuestro, 8180, 8888, el que usemos:

solr.search.server = http://localhost:8180/solr/search

Cuidado, que hay una serie de problemas reportados en JIRA respecto el uso de 127.0.0.1 y el uso de localhost, por lo que quizá se tenga que tantear. (CORREGIDO gracias a la aportación de Javier, de la Universidad de Piura, Perú)

Una vez editados estos ficheros, hay que reiniciar el tomcat para que se apliquen los cambios y ejecutar en línea de comandos el programa update-discovery-index para que se actualicen los índices del Discovery.

[dspace-instalación]/bin/dspace update-discovery-index

Una vez ejecutada, podemos ver los cambios en nuestro Dspace, un magnífico DSPace con búsqueda por facetas:

Ah, un último punto… las etiquetas/textos que usa Discovery no están traducidas, pues no se incluyen en el messages-es.xml del núcleo de Dspace. La opción más razonable es localizar su messages.xml en las fuentes de dspace-discovery y copiarlas, es decir añadirlas, al messages_es.xml que usemos de forma habitual (una vez traducidas, claro..)

Suerte (y gracias a Atmire…)

Hablando de DSpace