Activar tareas de Curation. Parte 1

Las tareas de Curación (Curation tasks) son básicamente programas desarrollados en Java para añadir una funcionalidad adicional, relacionada con la gestión de los objetos del repositorio, de ahí el término Curación o Preservación, a la que nos da la instalación base repositorio.

Manual Dspace 1.8: The goal of the curation system (‘CS’) is to provide a simple, extensible way to manage routine content operations on a repository. …The DSpace core distribution will provide a number of useful tasks, but the system is designed to encourage local extension – tasks can be written for any purpose, and placed in any java package. This gives DSpace sites the ability to customize the behavior of their repository without having to alter – and therefore manage synchronization with – the DSpace source code.

El soporte a las tareas de curación aparece en la versión 1.7 y se mejora sustancialmente en la versión 1.8, principalmente con la adición de un marco bastante completo de creación de nuevas tareas.

Las tareas de curación son programas java con detección del contexto de invocación, es decir se aplican al nivel de colección, subcolección o ítem,  en el contexto en el que se esté. Además pueden ser invocadas desde el Command line interface, CLI, con lo que pueden ser programadas mediante rutinas nocturnas,  y también desde la UI del administrador (sólo interface XMLUI).
Las tareas que pueden ser apropiadas serían, p.ej :

  • Escaneado antivirus de los ficheros, asegurar la legibilidad de los ficheros…
  • Mejora de los ficheros, p.ej aplicación de marcas de agua o páginas iniciales a los pdfs…
  • Comprobación de la completitud de metadatos, valores límite de los metadatos, adherencia a determinados perfiles de uso de los mismos..
  • Conexión con servicios externos a Dspace para mejorar los metadatos, como authority controlled…

Las tareas de curación nos permiten complementar Dspace e incorporar funciones adicionales, pero debemos considerar las implicaciones ante una migración de versiones. El poder implementar cualquier función tiene la desventaja de que esa libertad puede hacer que a la hora de desarrollar una tarea estemos usando versiones de la API de DSpace que en un momento dado se abandone o entren en desuso. Por ejemplo,  programamos una tarea de curation en la cual modificamos un metadato de DSpace usando la API del DSpace 1.7.2, luego al  migrar esta tarea de curación a una versión superior,  descubrimos que la API DSpace 1.8.2 no soporta lo que hemos programado.

No obstante esta precaución, he de decir que a partir de la versión 1.6.0 y futuras API’s no parece haber muchos cambios importantes a la hora de programar, por lo que una tarea de curación programada para la API 1.6.0 seguramente funcione para la 1.8.2.

Una vez hecha esta introducción ahora vuestra pregunta será, ¿cómo programo y cómo activo una tarea de curación?

La respuesta a la primera pregunta mejor lo dejamos para otro futuro post  (nos quedaría este muy pesado) y nos centramos es la segunda cuestión.

Como aspecto curioso de señalar,  DSpace tiene de por sí mas tareas de curación programadas de las que aparecen en el UI, lo que pasa es que no las tiene instaladas. Por ello nos centraremos en este caso  para aclarar cómo se instala una tarea de curación.

Para que el Curation System pueda ejecutar una tarea, se deben dar dos condiciones, que el código de la tarea se incluya con el resto del código,  p.ej. en [dspace]/lib, WAR, etc, y que además se le declare y asigne un nombre en el fichero de configuración [dspace]/config/modules/curate.cfg.  Notar que este fichero se localiza en el subdirectorio config/modules/. La intención es que las tareas sean add-ons de la configuración base del sistema, sin que añadir o retirar tareas impacte en dspace.cfg (esto cambión en la v1.8 respecto la v1.7)

En este fichero hemos de introducir las tareas de curación para que el interfaz gráfico de DSpace las detecte. Para cada tarea se debe añadir un par key-value. La Key es el nombre completo cualificado de la clase java y el Value es el nombre de la tarea usado en el resto del CS para referirse a la tarea,  de tal forma que luego el usuario las pueda seleccionar.

Por ejemplo, si queremos activar el antivirus ClamScan debemos de añadir en el parámetro plugin.named.org.dspace.curate.CurationTask, el nombre de la clase Java correspondiente a la tarea de curation y luego un nombre que le queramos dar a la tarea de curación. Nuestra clase java se llama ClamScan y queremos darle el nombre vscan, y entonces la línea quedaría así:

plugin.named.org.dspace.curate.CurationTask =
org.dspace.ctask.general.ClamScan = vscan

Como tendremos mas tareas activas, este parámetro tendrá más bien este aspecto:

plugin.named.org.dspace.curate.CurationTask = \
org.dspace.ctask.general.ProfileFormats = profileformats, \
org.dspace.ctask.general..RequiredMetadata = requiredmetadata, \
org.dspace.ctask.general.ClamScan = vscan

y obviamente si quisiésemos insertar otra tarea de curación, por ejemplo un fichero java llamado MiJava y de nombre mitarea sería así

plugin.named.org.dspace.curate.CurationTask = \
org.dspace.ctask.general.ProfileFormats = profileformats, \ 
org.dspace.ctask.general..RequiredMetadata = requiredmetadata, \ 
org.dspace.ctask.general.ClamScan = vscan \
org.dspace.ctask.general.MiJava = mitarea

Ahora solo queda reiniciar el tomcat y ya tenemos disponible nuestra tarea de curación en la UI. Con los privilegios de administrador (en la 1.8 también pueden ejecutar tareas de curación los administradores de comunidad, en su contexto de administración, claro) en los paneles de edición de comunidad o colección o item, deberemos seleccionar la pestaña de curar. En el desplegable que aparece seleccionamos la tarea que queremos ejecutar, y una vez seleccionada le damos al botón de realizar.

Bueno espero que os haya abierto el gusanillo de la curiosidad, y os de por experimentar un poco con tareas de curación. En siguientes entregas explicaremos como codificar nuevas tareas de curación.

Interfaces e integraciones con DSpace

La pregunta primera que nos debemos hacer es ¿cuando necesitamos tener un interface con DSpace? y no estamos hablando solamente de interfaz de usuario (léase XMLUI o JSPUI) sino de interfaces sistema-sistema o integraciones. Bien, en ciertas ocasiones necesitaremos integrarnos con sistemas o aplicaciones web, como CMS, DMS, LMS, diseñar interfaces de usuario sustancialmente diferentes, como las móviles, lograr una interacción entre repositorios, etc. Un conjunto más amplio de lo que inicialmente se piensa.
De hecho, una gran parte de repositorios se interconectan mediante OAI-PMH. Llevamos toda la vida usando servicios de integración y ni nos habíamos dado cuenta…
Bien, este post es un repaso (con la impresión de que no es exhaustivo) a las diversas alternativas y sabores existentes.

Integración directa contra la Base de Datos y el sistema de Ficheros
Esto podríamos consideralo básicamente una declaración del tipo: «no me sirve nada el código java de Dspace y me voy a programar otra cosa». El proyecto, excepto si pensamos para el acceso a funciones muy básicas, será largo, pero claro, prácticamente podréis usar cualquier framework de desarrollo para el proyecto.

JavaAPI
Cualquier aplicación que sea capaz de llamar al JavaAPI de Dspace, podrá usarse para este tipo de integración. Así es como surgió XMLUI y están surgiendo continuamente nuevos proyectos. El problema es que la JavaAPI no proporciona una separación completa o nítida y normalmente se requerirá re-escribir parte de la lógica de negocio de DSPACE en la nueva aplicación. Ejemplo de ello es la duplicidad existente en el código XMLUI y JSPUI, indicación clara de esta insuficiencia o «imperfección» del JavaAPI.
Pero aparte de eso, ese el camino para el uso de Frameworks de Aplicaciones Web o de desarrollo rápido, como el framework Play!, la nueva interface anunciada en agosto de este año para Dspace, Freemarker WebMVC o incluso el uso de frameworks no-Java como Ruby on Rails.

OAI-PMH
Simplificando, OAI-PMH permite la recolección de los metadatos DSpace en otro sistema. El OAI-PMH, OAI’s Protocol for Metadata Harvesting, es la base de los proyectos de cooperación entre repositorios de diferente nivel (regional, nacional , temáticos…). OAI-PMH define los estándares para describir los intercambios de metadatos entre sistemas y con la creciente disponibilidad de librerías OAI-PMH para una diversidad de plataformas, pues es una opción siempre valorable.
Curiosamente siempre tenemos presente la recolección de nuestro DSpace, ya que la aplicación OAI se despliega de forma estándar en el proceso normal de construcción de DSpace, pero (creo que desde la versión 1.6) podemos configurar nuestro DSpace para recolectar otros repositorios que expongan sus contenidos mediante este interface. Por ejemplo, arXIv posibilita su recolección para proveer acceso a los metadatos de todos sus artículos. Guarden la debida precaución con los derechos y licencias.

OAI-ORE
OAI-ORE, Open Archive Initiative’s Object Reuse and Exchange, es la especificación para describir agregaciones de recursos web y el intercambio de recursos digitales. El soporte de este protocolo en Dspace se propociona desde la versión 1.6.
Si se usa en combinación con OAI-PMH el contenido de un repositorio (metadatos + ficheros) puede ser recolectado desde/hacia otro sistema. Como uso, quizá un poco raro, lo hemos usado para migraciones, obtener nuevas unidades de agregación de contenidos, y sincronización de instancias, sin necesidad de recurrir a procesos de import-export o similares.

REST-API
Existe una REST API en fase de desarrollo avanzado que permite la integración basada en REST: Transferencia de Estado Representacional (Representational State Transfer).  El código se  puede descargar para la 1.8 y previsiblemente irá incluido en el DSpace 3.0, pero ya hay una serie de proyectos interesantes sobre esta interfza, incluido una integración Moodle.

SWORD
SWORD (Simple Web-service Offering Repository Deposit) es un protocolo, basado en atompub, Atom Publish Protocol, que define el depósito remoto de items en un repositorio por otras aplicaciones. Ya nos hemos explayado bastante en este blog sobre SWORD, está claro que nos gusta. La disponibilidad de librerias Sword en diversos lenguajes, (PHP, java…) promueve el uso de este tipo de integración, p.ej, en el depósito de publicaciones desde sistemas de investigación, y otros escenarios.
Dspace implementa el protocolo SWORD de diversas formas:

  • Servidor compatible con el protocolo SWORD v1, disponible desde la versión 1.6 de Dspace
  • Servidor compatible SWORD V2, disponible desde la versión 1.8 de Dspace.
  • Cliente SWORD, para hacer que DSPACE deposite items en otros sistemas que acepten este protocolo.

LNI (Lightweight Network Interface)
Este interface permite la integración de un sistema con DSpace via el protocolo WebDAV. Puedes encontrar más información aquí. La última actualización del código se realizó en la versión 1.5, su uso parece minoritario y hay reportados problemas de rendimiento (literalmente:    suffers horrible performance issues).  Desarrollado por el MIT, su proyecto más visible parece ser CWspace, una plataforma de este Instituto de contenidos OpenCourseware.

SOLR
En el Open Repositories 2012, Stuart Lewis presentó SkylightUI, que es un front-end sobre DSpace, desarrollado en CodeIgnitor(PHP), y que usa el índice SOLR de DSpace como una API. Como nunca nos podemos resistir a las propuestas de Stuart, pues lo probaremos lo antes que podamos, y os seguiremos contando.

Definir un nuevo índice de navegación

Además de la búsqueda (search), uno de los mecanismos que ofrecen los repositorios a sus usuarios es la navegación (browse) por sus contenidos, con los usuarios revisando un índice p.ej. de títulos para ver si encuentran contenidos de su interés.

En la mayoría de instalaciones surge la necesidad de redefinir los índices de navegación (Browse indexes), puesto que los cuatro índices (autor, título, fecha y materia) que vienen definidos por defecto en LUCENE, que es el buscador habitual de la mayoría de instalaciones Dspace, en contraposición a SOLR… posiblemente no se adapten suficientemente a las necesidades de nuestra organización. Dspace permite la definición de nuevos índices (incluyendo eliminar o modificar los ya definidos) como parte del proceso de configuración.

En primer lugar, índice se asocia por lo general a metadato, por lo que debemos tener definidos en Dspace los campos de metadatos relevantes, y sobre ellos configurar los índices de navegación.

  • Lo primero a tener en cuenta es incluir el metadato en el metadata-registry…claro. p.ej. dc.subject.unesco, porque queremos tener un índice de materias unesco.
  • Localizar la sección configurable browse indexes en dspace.cfg. Y en ella, editar el nuevo índice:
     webui.browse.index.(n) = Unesco:metadata:dc.subject.unesco:text

    para una explicación de la sintaxis de este campo, ver el cajetín al final de este post, y referirse al manual de Dspace. Sobre todo, cuidado con la numeración del índice, ya que deben quedar todos los índices en secuencia ordinal correcta…1,2,3..n , sin saltos, repeticiones…

  • realizar un index-init, rearrancar tomcat limpiando la memoria caché y el índice ya esta listo para ser usado..
  • Como el índice es nuevo, no existirán las etiquetas de lenguaje correspondientes. Avisados quedan, son un montón. Navegar sobre el índice recién construido y anotar las nuevas etiquetas, del tipo:
     xmlui.ArtifactBrowser.ConfigurableBrowse.title.metadata..........

    Para XMLUI, incluirlas en el messages.xml y en los messages_xx que use vuestra instalación

¿Sabías que…? si el campo sobre el que se construye el índice es un campo authority controlled, Lucene ofrece simultáneamente al índice «tradicional» un índice adicional sobre ese campo, que se construye únicamente con los valores validados… Para usar ese índice en el dspace.cfg tienes que configurar un nuevo índice con los valores:

webui.browse.index.5 = lcAuthor:metadataAuthority:dc.contributor.author:authority (ejemplo)

Sintaxis
webui.browse.index.<n>=<index name>:<metadata>:<schema prefix>.<element>.<qualifier>:<data-type field>:<sort option>.

  • Propiedad en dspace.cfg: webui.browse.index.<n>
  • <index name>: El nombre que queramos dar al índice, relevante para las messages keys
  • <metadata>: valores posibles “metadata”, “item” o «metadataAuthority»
  • <schema prefix>.<element>.<qualifier>: el campo dublin core cualificado sobre el que se construye el índice, p.ej.dc.contributor.author. Admite en <qualifier> caracteres de macheo múltiple (*)
  • <data-type field>: los tipos que permite son «date», «title», «text», «other», «authority» (y podriamos definir otros adicionales relevantes a configuraciones específicas de normalización del índice)
  • <sort option>: Opcional, puede ser ascendente o descendente.

Sobre los Formatos de ficheros

Como indica el documento ISO/TC 46/ SC 11 Digital records preservation: Where to start Guide, la naturaleza de los registros digitales origina una serie de desafíos que deben ser contemplados si se busca la preservación de los registros en el transcurso del tiempo. Los desafios principales son:

  • Obsolescencia y degradación de los formatos físicos (media)
  • Obsolescencia de los formatos de ficheros
  • Obsolescencia del software ( sistemas operativos, bases de datos, ofimática…)
  • Obsolescencia de Hardware

The current rate of technological change may mean that preservation actions, such as migrating to more accessible or durable formats may be required after as little as five years. Digital preservation should therefore be addressed from as early in the object life cycle as possible, particularly as the manner in which a resource is created has a significant impact on its durability. “Digital Preservation: Continued access to authentic digital assets»; Briefing paper; JISC; nov 2006.

Como consecuencia, se requiere la intervención casi continua y desde el primer momento, de los archivistas para preservar los contenidos digitales.

Obsolescencia de Formatos de ficheros

Principalmente se requiere un enfoque de anticipación, puesto que continuamente aparecen nuevos formatos, aunque estudios recientes sobre repositorios científicos de acceso abierto muestran un dominio del formato PDF y una larga cola (long tail) de otros formatos.  «Characterising and Preserving Digital Repositories: File Format Profiles»; Steve Hitchcock and David Tarrant; 30-January-2011; Ariadne Issue 66.

En un momento dado, una comunidad de usuarios como la que conforma nuestros repositorios Dspace podría estar usando decenas de aplicaciones y cientos de formatos, y lo que es más importante, deseando efectuar depósitos con las menores restricciones posibles. Al fin y al cabo, ¿a quién le gusta convertir formatos?

Los responsables de un repositorio, si son precavidos, deberían tener en cuenta este escenario de cambio, evolución y desorden, ya que una política de preservación que no considere el cambio, no es una buena política.

Formatos de Archivo (Archival Data Formats)

Uno de los elementos principales de un enfoque de preservación es el uso (sugerencia, recomendación u obligación) de formatos de archivo que no sean propietarios (se caen los formatos ms-office y decenas de otros) y que además estén específicamente definidos para el acceso en el largo plazo y desde diferentes plataformas tecnológicas.

Entre los candidatos a formato estable para documentos típicos, se considera normalmente el uso del Portable Document Format (PDF) de Adobe. Por ello nuestros repositorios están repletos de este formato, gusta a los usuarios y por tanto PDF es un buen candidato para formato de archivo.

Incidentalmente, PDF puede corresponder a Portable Document Format (Adobe), Printer Definition File (Netware) o a Package Definition File (Microsoft Systems Management Server) y aunque posiblemente no veremos nunca por nuestros Dspaces un PDF no-Adobe, el ejemplo ilustra los riesgos de asumir la extensión como indicación del formato. La extensión del nombre de fichero de tres caracteres no está ni estandarizada, ni es única, siendo además interpretada diferentemente por diferentes entornos.

Y a efectos de preservación, PDF significa al menos 17 formatos diferentes de Adobe: Acrobat pdf 1.0, 1.2, 1.3,..1.7, Acrobat PDF/A, Acrobat PDF/X Exchange 1a:2003, etc… con estrategias de preservación (migración y conversión) igualmente diferentes. Si a esto le añadimos las funcionalidades de protección de documentos de Adobe, la amenaza de los Digital Rights Management, u otras curiosas posibilidades de este magnífico software, pues entenderemos que la tarea de preservación puede ser muy complicada.

Recomendamos: Asomarse un poco a a la complejidad de los formatos, y de sus efectos en la preservación, en el registro PRONOM de los National Archives del Reino Unido.

 

Los formatos en Dspace

Por contra de otras muchas virtudes que tiene Dspace, en el asunto de formatos considero que nos ofrece poca ayuda a nuestra tarea. Expliquémosnos.

DSpace usa la extensión de fichero como indicación de la codificación (formato) del fichero. En ese sentido, Dspace considera la extensión como un «metadato» y a partir de ahí, mediante un macheo con el format-registry, asume el formato del fichero y el nivel de soporte que se determina sobre el formato. Sobre el soporte de formatos y el format-registry en DSpace ya escribiremos un post detallado.

Las consecuencias de esta sobre-simplificación de la identificación de formato son diversas, ya que podemos tener:

  • Un único saco para varios formatos similares y teóricamente compatibles, pero no lo olvidemos, a efectos de preservación, distintos: el caso explicado antes de los 17 formatos de Adobe PDF.
  • Asignaciones incorrectas tipo 1: considerar que tenemos un Adobe/pdf  y en realidad estamos «custodiando» un MS-Package Definition File, o cualquier otra cosa que el autor ha decidido renombrar con esa extensión.
  • Asignaciones incorrectas tipo 2: considerar que un fichero no está soportado, porque su extensión no corresponde a una soportada (el caso más obvio, los ficheros sin extensión)
  • etc..

Las soluciones que podemos vislumbrar, no son complejas, y están desde hace tiempo en la línea de evolución y desarrollo de Dspace, con una mezcla de tareas automáticas, como procesos batch o empotradas en los workflows de envio, de data profiling basadas en el software Droid (también de los National Archives del Reino Unido, qué bárbaros) o el framework Jhove2 (que usa Droid para la identificación de formatos) o alguna otra alternativa.

CommunityFiliator, reorganizando estructuras de comunidades

Aviso a navegantes, éste puede considerarse un post «raro». Si quedaste extrañado cuando explicamos el structure-builder, quizá sea mejor que no sigas leyendo.

Cuando hace tiempo nos topamos con el comando communityFiliator, la sensación de extrañeza fué mayúscula ¿y esto para qué sirve?. Ahora la pregunta sería diferente ¿y esto se usa en alguna parte?

Un poco de historia

Antes de la versión 1.2 no existía la posibilidad de definir sub-comunidades, es decir sólo habia Comunidades y Colecciones colgando de ellas.

En la actualidad se pueden definir n-elementos, sub-comunidades, entre la Comunidad de nivel superior y las Colecciones.

Pues bien, este comando sirvió a las instalaciones Dspace para «re-colocar» estructuras planas, dos niveles, en estructuras más piramidales.

Una comunidad en DSpace se puede considerar

  1. ‘padre’ (en realidad madre) en el sentido que hay al menos otra comunidad (sub-comunidad) dependiendo de ella. [Por ejemplo, en la figura anterior, las comunidades 2, i, i.j serían ‘madres’]
  2. ‘hij@’, significando que depende de una comunidad de un nivel superior. [Comunidades 2.1, 2.2, i.j, i.j.k]
  3. Ninguna de las dos cosas (no tiene sub-comunidades dependientes y su vez no depende de otra comunidad). [Comunidad 1]
  4. Ambas cosas (tiene sub-comunidades dependientes y a la vez depende de otra comunidad). [Comunidad i.j]

En estos términos, una comunidad ‘huérfana’ es quien no tiene ‘madre’, a éstas también las llamamos comunidades de nivel superior (top-level communities).

El comando tiene dos sabores: Set y Remove, para establecer y deshacer relaciones madre-hija.
Set sirve para coger una comunidad huérfana, es decir de nivel superior, y hacerla dependiente de otra comunidad, moviendo toda la estructura debajo de la especificada en el comando. Y Remove convierte a una comunidad ‘hija’ en ‘huérfana’.

Igual que el structure-builder, el CommunityFiliator se incluye en la clase Org.Dspace.administer y se invoca con un

[dspace]/bin/dspace community-filiator parámetros…

Los comandos tienen la sintaxis siguiente:

[dspace]/bin/dspace community-filiator -s -p ID1 -c ID2

en donde ‘-s’ o ‘–set’ significa que a la comunidad ‘huérfana’ con ID2 la hacemos depender de la ID1

y usando el comando Remove, con la sintaxis alternativa que la mayoría de comandos Dspace tienen:

[dspace]/bin/dspace community-filiator –remove –parent=ID1 –child=ID2

en donde hacemos huérfana a la comunidad ID2, ‘matando’ la relación de dependencia con la ID1

Lamentablemente, y por si no nos habíamos dado cuenta hasta ahora, el comando no sirve para mover colecciones (SOLO comunidades y sus colecciones dependientes) de una comunidad a otra, o dicho de otro modo los IDs corresponden a entradas en la tabla comunidades, no en la tabla colecciones. De hecho el comando re-escribe justamente la tabla comunidades…

Funcionando con varios DSpace

Hay muchas razones por las que nos puede interesar tener más de un DSpace, por mencionar unas cuantas: tener una instancia de producción y otra(s) de pruebas, servir a diferentes organizaciones, tener diferentes funcionalidades, preparar una migración, etc.

Y del mismo modo que hay múltiples razones, hay igualmente múltiples aproximaciones a esta situación. El post anterior planteaba un proceso simple, sin complicaciones, para tener múltiples instalaciones y funcionar alternativamente con ellas. En este post vamos a efectuar un recorrido rápido, no exhaustivo, por las alternativas existentes para tener instancias DSpace simultáneamente activas.

Un esquema simple, aunque efectivo para los objetivos que nos proponemos, de lo necesario para dspace sería: HW + sistema operativo + (servidor web y/o servidor de aplicaciones) + DSpace + bbdd, es decir:

Alternativa 1: Virtualización del HW por software
Es decir, emulación por software de un sistema físico con unas características de hardware determinadas: VMWare, VirtualBOX, Hyper_V, Xen-Server….. Si quieres realmente obtener copias idénticas de entornos, interesante en múltiples ocasiones, y aislamiento completo entre entornos, ésta es posiblemente vuestra opción.

 

Alternativa 2. Múltiples tomcat + bbdd + dspace
Instalar n Tomcat. No es trivial, pero se puede hacer con diferentes directorios de instalación, con scripts de aranque/parada diferenciados y diferentes puertos.
Instalar n bases de datos.
Instalar n Dspaces, con diferentes directorios dspace_src, los cual conducirá a ficheros de configuración separados, y por supuesto cada uno usando su base de datos correspondiente.
Además, cada Tomcat deberá apuntar al webapps de su dspace correspondiente …

 

 

Alternativa 3. Virtualizaciones Apache basada en Vhosts
En esta opción se debe usar Apache como front-end de los Tomcat.
Instalar y configurar n instancias Tomcat, n bases de datos y n Dspaces (como en la alternativa 2 anterior)
Con la directiva NameVirtualHost del servidor web Apache, crear n host virtuales, cada v-host dirigido a su Tomcat correspondiente. Más información sobre Vhosts, aquí

 

Alternativa 4 –> 1 tomcat + n BBDD + n dspace
Se puede usar un único Tomcat configurado para que use n directorios webapps correspondientes a n instancias Dspace. Pero claro, como siempre, (esto no hay manera de evitarlo) se necesitan n bases de datos diferentes y n instalaciones Dspace (con sus n directorios). Cada configuración Dspace apuntará a una base de datos diferente y hay que decirle a Tomcat donde está cada Dspace (bueno, cada aplicación jspui, xmlui, oai,….de Dspace) en el fichero server.xml de tomcat.

Algo así como

 
<Context path="/jspui_1" docBase="../dspace_1/webapps/jspui/" ..../>
<Context path="/jspui_2" docBase="../dspace_2/webapps/jspui/" ..../>
<Context path="/jspui_n" docBase="../dspace_n/webapps/jspui/" ..../>

<Context path="/xmlui_1" docBase="../dspace_1/webapps/xmlui/" ..../>
<Context path="/xmlui_2" docBase="../dspace_2/webapps/jspui/" ..../>
<Context path="/xmlui_n" docBase="../dspace_n/webapps/jspui/" ..../>

..

<Context path="/oai_1" docBase="../dspace_1/webapps/xmlui/" ..../>

 

 

 

Para profundizar más
Hay múltiples caminos y vías para tener más de una instalación de DSpace. Las líneas bocetadas en los párrafos anteriores pueden presentar características que para una organización en concreto no resulten aceptables. Quizá se quiera independizar o aislar fuertemente a los usuarios de desarrollo y producción, o las políticas TI no permitan virtualizaciones, etc..

En la página wiki.duraspace.org/display/DSPACE/MultipleDspaceOneServer encontraréis soluciones a algunos de los temas relacionados con la ejecución simultánea de varios DSpace.

Cómo instalar varios DSpace en paralelo

Durante los procesos de desarrollo e instalación de DSpace, surge la necesidad de tener varios DSpace (varias versiones diferentes, p.ej) ya que a veces nos interesa no ensuciar mucho nuestro instalación base y probar código nuevo, ….

Pues bien las siguientes instrucciones os van a dar una idea de como hay que hacer para tener varias versiones de DSpace funcionando a la vez para que luego cambiando una dirección del tomcat podamos acceder de uno a otro.

Vamos a suponer que queremos instalar un DSpace versión 1.x.x (se hace igual en todas las versiones) llamado dspace_1, con Postgresql en el cual crearemos una base de datos llamada dspace_1

En primer lugar descargamos el codigo fuente de un DSpace y hacemos el proceso de compilación mediante un maven.

Una vez hecho tenemos que tocar el fichero de configuración dspace.cfg y ahí tenemos que modificar un par de líneas con el siguiente contenido (modificar paths y puertos según instalación):

dspace.dir = /dspace_1

db.url = jdbc:postgresql://localhost:5432/dspace_1

Lo que hemos hecho es especificar una instalación de DSpace en el raiz, en una carpeta llamada dspace_1 y el segundo parámetro (db.url) que modificamos indica que estamos usando la base de datos dspace_1 mediante un conector postgresql.

Claramente en el proceso de instalación tenemos que crear una base de datos con el nombre acorde a lo especificado en db.url (en nuestro caso la base de datos se llama dspace_1).

Una vez creada la base de datos y guardado los cambios del dspace.cfg tenemos que hacer un ant fresh-install. Cuando acabe el proceso y obtengamos un success, antes de rearrancar el tomcat tenemos que modificar el fichero server.xml del tomcat para que apunte a nuestra instalación DSpace.

<Host name=»localhost»  appBase=»/dspace_1/webapps»
unpackWARs=»true» autoDeploy=»true»
xmlValidation=»false» xmlNamespaceAware=»false»>

 

Rearrancamos el tomcat y tenemos nuestro primer DSpace operativo con su propia base de datos asociada.

Ahora, si queremos otra versión de DSpace funcionando paralelamente a esta, tenemos que hacer el mismo proceso que antes, cambiando los nombres que de nuestra base de datos y la dirección de instalación del DSpace.  Suponiendo que quiero instalar un DSpace en el directorio raíz de nombre dspace_2, el proceso resumido sería el siguiente:

1- Hacer un maven

2- Modificar dspace.cfg de la carpeta target

dspace.dir = /dspace_2

db.url = jdbc:postgresql://localhost:5432/dspace_2

3- Crear una base de datos llamada dspace_2

4 – ant fresh-install

Con esto ya tenemos dos DSpace en nuestro ordenador, con dos bases de datos distintas

Ahora si queremos cambiar de una versión a otra tenemos que modificar el fichero server.xml haciendo que apunte el webapps de dspace_1 a dspace_2 o viceversa.

 

 

Búsquedas en Dspace

En DSpace, hasta la aparición de Discovery, existían dos tipos de búsqueda, la Simple y la Avanzada. La diferencia entre ambas radica en que en el caso de la Búsqueda Simple, el usuario introduce una palabra y el motor de búsqueda busca en todos los campos de los items (autor, título, fecha, etc), devolviendo cualquier coincidencia hallada, mientras que en la Búsqueda Avanzada el usuario puede, a través de una serie de filtros, indicar los campos donde buscar y combinarlos con el uso de los conectores lógicos AND, OR o NOT, depurando de esta manera los resultados de la búsqueda y adaptándolos a sus intereses. Todo ello aplicando los filtros que tenemos definidos en el search.analyzer, y que ya hemos explicado en otro post.

La Búsqueda Simple es rápida y directa, pero tiene el inconveniente de que si la consulta no es muy específica, los resultados pueden ser demasiado amplios, mientras que los obtenidos con la Búsqueda Avanzada pueden refinarse más.

En ambos casos, DSpace nos ofrece realizar una búsqueda en Todo DSpace, o bien restringirla a una Comunidad o Colección específica, cambiar el número de resultados que aparezcan en cada página y ordenar dichos resultados por relevancia, título, fecha de publicación o fecha de envío, tanto en orden descendente como en orden ascendente.

Para las búsquedas de múltiples términos, el motor de búsqueda de DSpace utiliza por defecto el operador booleano OR, que requiere que al menos uno de dichos términos esté presente. Este operador booleano de búsqueda utilizado por defecto, puede ser personalizado modificando la siguiente línea en el archivo dspace.cfg:

search.operator = OR

En caso de introducirse el operador AND, en las búsquedas de múltiples términos se requerirá que todos ellos estén presentes.


Modificando el Buscador Avanzado

El combo de selección de campos de búsqueda del Buscador Avanzado puede ser modificado para que incluya nuevos campos o se eliminen los existentes en la herramienta por defecto. Para ello, en el fichero dspace.cfg hay que buscar el bloque que comienza por ##### Fields to Index for Search ##### , donde pueden observarse varias líneas como las siguientes:

search.index.1 = author:dc.contributor.*
search.index.2 = author:dc.creator.*
search.index.3 = title:dc.title.*
search.index.4 = keyword:dc.subject.*
search.index.5 = abstract:dc.description.abstract

Si se desea añadir un nuevo campo de búsqueda al combo, hay que añadir una línea del tipo search.index.#. Mantener el ordinal de los índices de la forma 1,2,3,4… sin saltos y bien ordenado.. Para que la etiqueta mostrada sea comprensible por el usuario, sería necesario, además, modificar los ficheros Messages.properties y advanced.jsp o messages.xml correspondientes.

En el caso de modificar el combo de selección de campos de búsqueda, es importante reindexar DSpace para evitar que la búsqueda funcione de forma anómala, ejecutando el comando:

[dspace]/bin/dspace index-init

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)