Warning: Constant WP_MEMORY_LIMIT already defined in /home/elorenzo/domains/arvo.es/public_html/dspace/wp-config.php on line 94
GUI | Hablando de DSpace

Archivos de Tags: GUI

Activar tareas de Curation. Parte 1

Enviado por el 2012/10/25 Comentarios desactivados en 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.

Definir un nuevo índice de navegación

Enviado por el 2012/08/22 Comentarios desactivados en 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.

XMLUI o JSPUI??

Enviado por el 2011/12/09 6 comentarios

Una cuestión que normalmente  surge en las nuevas instalaciones (o migraciones ) de DSpace es ¿qué interface usar?.

Anteriormente a Dspace 1.5, la interface única  de JSPUI simplificaba la elección :), y este es el motivo de la amplia difusión de los interfaces JSPUI, pero con la aparición de XMLUI es una pregunta recurrente. Intentaremos proporcionar alguna luz, o quizá simplemente alimentar el debate al respecto…  Empecemos:

XMLUI permite de forma extremadamente simple, mucho más que JSPUI, aplicar apariencias radicalmente diferentes a distintas colecciones, lo que resulta de especial relevancia en determinados ámbitos, pensemos en distintas tipologías de objetos por colección, o en diferenciación de la imagen institucional o… motivos diversos los hay, y en ocasiones son causas suficientes para decantarse por XMLUI…

Por otra parte, existe una sensación general de que los nuevos desarrollos de Dspace se alejan de JSPUI, pero nos gustaría confirmarlo con hechos. Algunas de las nuevas funcionalidades presentes en Dspace 1.8 están soportadas únicamente en XMLUI, como el Configurable Reviewer Workflow. De hecho, según se encarga de recordarnos la documentación del 1.8, la activación de esta función «deshabilita» el JSPUI. (realmente no lo deshabilita, simplemente deja de funcionar, pues se altera el esquema de la base de datos…). Y en versiones anteriores, recordamos el Authority Control en Dspace 1.6, la versión JSPUI nos produjo más quebraderos de cabeza que satisfacciones, hablando en plata. Y algunas de las características de un «tema» como Mirage, incluso considerando sus bugs pre-1.8, son inalcanzables, pensamos, para JSPUI.

Pero esto también pudiese ser cierto a la inversa. Al menos hasta la aparición de la versión 1.7, la interfaz de administración de XMLUI iba por detrás de la disponible en JSPUI. Y recordemos que la funcionalidad base para usuarios generales de JSPUI sigue siendo objetivo, a mi entender, aún no alcanzado, de los temas XMLUI como el «Classic», sin efectuar desarrollos específicos. Lo cual nos lleva al siguiente punto, modificar y desarrollar la interfaz de usuario en una u otra interfaz.

Desarrollar en XMLUI es sustancialmente más complejo que en JSPUI, para funcionalidades «estándar» si es que eso existe. La curva de aprendizaje de XMLUI es mucho más costosa y esforzada, sinceramente. La mezcla de funciones java, seguido de una cadena de transformaciones XSL, todo embutido en un framework Apache Cocoon, resulta compleja de entender. XMLUI no funciona bajo una lógica «una plantilla-una página», sino bajo una lógica «diversas plantillas- una página» y, simultáneamente «una plantilla- diversas páginas». Lo cual complica la concepción del sistema así creado…

Bien, existen más diferencias, y sobre todo más opiniones sobre las mismas, que las planteadas en la breves líneas anteriores

¿y Vds, que opinan?.

Mapear Items entre colecciones

Enviado por el 2011/07/22 Comentarios desactivados en Mapear Items entre colecciones

En la gestión de Dspace normalmente aparece la necesidad de mantener estructuras complejas de comunidades y colecciones, en las que normalmente aparece algún tipo de solapamiento… Derivado de este hecho, se requiere que determinados objetos (items) pertenezcan a más de una colección, lo que habitualmente se denomina mapear un item a múltiples colecciones.

Existen básicamente tres formas de realizar este mapeo: Mediante la Interfaz de usuario; con la función de Batch Metadata Editing y modificando directamente la Base de Datos de Dspace. La selección entre una opción u otra deberá realizarse teniendo en cuenta principalmente el número de items a mapear y la familiaridad o conocimiento que tengamos de cada una de las tres alternativas existentes.

Como características que debemos tener en cuenta, el item mapeado no cambia sus privilegios, pues mantiene las autorizaciones que «heredó» en el proceso de inclusión a su colección original. Y relacionado con este aspecto, un administrador de colección no podrá mapear items si no tiene privilegios en la colección origen, es decir necesita ser administrador de las colecciones origen y destino, evidentemente…

 

Interfaz de Usuario

El nombre de la función en los menús es mapeador (relacionador) de items.

Debemos estar autenticados como administradores (generales o de colección) y navegar a la colección a la que queremos mapear los items. En el menú (herramientas de administración en JSPUI y menú de contexto de colección en XMLUI) nos aparecerá la opción de relacionar items.

Podemos efectuar una búsqueda y sobre la pantalla de resultados efectuar el mapeado o directamente proporcionar el handle del item a mapear.. El «mapeador» de items permite además «des-mapear» los items que seleccionemos.

  • Pros: Simple de manejar, GUI directa y comprensible por el personal de administración de la colección
  • Cons: un poco engorroso cuando se trata de hacer trabajos de mapeo entre múltiples colecciones- items

 

Batch Metadata Editing.

A partir de la versión 1.6, tenemos la opción de hacer cambios amplios a los metadatos de nuestro Dspace a través de la exportación a CSV, edición del CSV e importación de la magnífica herramienta que es el Batch Metadata Editing. Junto con los metadatos, la herramienta muestra la o las colecciones en las que está incluido un objeto.

Ejemplo:

La exportación de un item, nos proporciona, además de los metadatos del mismo, la siguiente información (segunda columna de nuestro CSV, habitualmente):

collection: 123456789/15, es decir el item está archivado bajo la colección de id 123456789/15.

Para mapearlo, (o incluso moverlo) a otra colección simplemente concatenamos a la colección «primaria» el id de la otra colección a la que queremos asociar el objeto. Así, en la columna collection ponemos 123456789/15||123456789/33 y cuando hagamos la importación de metadatos habremos mapeado el item a la colección de id 123456789/33

  • Pros: Permite efectuar el mapeo de items-colecciones junto con el resto de tareas de limpieza, mantenimiento y curación de metadatos. Un modelo «cuasi-batch»
  • Cons: requiere de la versión 1.6 y superiores. Y haber manejado previamente la herramienta Batch Metadata Editing. Es simple, pero no es obvia.

 

Base de Datos
Anteriormente a la versión 1.6 esta era la vía «dura», usada en vez de el mapeo vía UI,  si se requería el mapeo de un número considerable de items.   Si se dispone el conocimiento necesario de base de datos,  se puede mapear una colección adicional en un item insertando una fila adicional en la tabla «collection2item».

Cada fila de dicha tabla contiene pares de collection_id y item_id, siendo el collection_id el identificador de la colección (de la tabla «collection» y el item_id es el identificador interno de Item (no es el handle, se puede obtener de la página Editar Item).

  • Pros: Directo, puesto que en modo batch modificamos la BD. Permite cambios masivos a nuestos items y colecciones.
  • Cons: Sólo para usuarios técnicos avanzados ya que requiere conocimientos de SQL, por lo que se recomienda encarecidamente hacer un backup previo de la BD.