Archivos de Tags: javaAPI

Tareas de curación. Parte 2

Bueno lo prometido es deuda, y os debía una segunda parte sobre las tareas de curación.

Como os acordaréis en la primera parte, se habló de como configurar DSpace para que aceptase las tareas de curación, es decir,  su configuración, su manejo, etc.. Ahora con este post vamos a proporcionar un esquema básico de una tarea de curación, junto con algún consejo a la hora de acometer la construcción de una tarea de curación.

El código, como expliqué en el post anterior, es un fichero java incluido dentro del código fuente de DSpace, este código debe tener una estructura básica tal que así:

public class ArvoCuration extends AbstractCurationTask{

private static Logger log = Logger.getLogger(ArvoCuration.class);

@Override
public void init(Curator curator, String taskId) throws IOException {

}

@Override
public int perform(DSpaceObject dso) throws IOException {
return 0;
}

Esta clase java debe heredar de la clase AbstractCurationTask,  y “usa” dos métodos init y perform. El método init no es estrictamente necesario incluirlo, pero es aconsejable puesto que esta función nos permite inicializar valores en nuestro código es decir, que cuando ejecutamos una tarea de curación primero se va a ejecutar el método init, el cual es útil para inicializar Bases de Datos u otras variables… En segundo lugar se ejecutará el método perform, y es aquí donde ha de ir el código que nuestra tarea de curación ejecutará.

El método perform recibe un parámetro que indica el objeto que se ha de evaluar, es decir un objeto de una colección…. Por lo que para trabajar con él hay que hacerle un cast y comprobar que lo que recibimos es un item, ya que a fin de cuentas el propósito de las tareas de curación es ejecutar tareas de curación-preservación (efectuar el mantenimiento) de items en el tiempo.

El retorno de la tarea de curación depende de que el proceso que se ejecute sea exitoso o fallido, y para ello hay unos códigos de error que vienen definidos en el manual de DSpace por lo que debemos de identificar si nuestra tarea se ejecutó correctamente o no. Os aconsejo usar la clase Curator invocándola así

import org.dspace.curate.Curator;

Esta clase al llamarla tiene definidas unas variables estáticas que nos definen de forma textual el código que ha de devolver el método perform.

Estas variables son:

Curator.CURATE_ERROR; (la tarea tiene un error)
Curator.CURATE_SUCCESS; (la tarea se ejecuta correctamente)
Curator.CURATE_FAIL; (la tarea falló)
Curator.CURATE_SKIP; (la tarea no se realizó)

De ti depende usar esos códigos (CURATE_ERROR….) correctamente, puesto que a fin de cuentas tu eres el encargado de programar la tarea de curación.

Otro apunte importante a la hora de programar nuestra tarea de curación es usar el log de DSpace para reflejar cualquier error, en caso de fallo. En el esqueleto del código os dejé como se llama al log de DSpace de tal forma que luego haciendo un log.error(“”); podéis escribir el fallo u otra información proporcionada por la tarea. Por ejemplo, si queréis notificar por log que la tarea se está ejecutando, podéis usar el método info del log así:

log.info("Se ha ejecutado mi tarea");

En serio, os recomiendo un uso amplio de esta característica..

Bueno y esto es (casi) todo. Si necesitáis mas información acerca de las tareas de curación, enviad vuestras comentarios a este post.

Un saludo, DSpace users.

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.