Envíos basados en tipologías en DSpace 3.x

Una de las novedades que incorpora la versión 3 de DSpace, es la personalización de los envíos de ítems en función del tipo de contenido que se está enviando. Existía un parche en Jira_Dspace, el DS-464, Item type based submission, pero ha habido que esperar hasta la versión 3.0 para verlo incluido en el código estándar.

Esta función soluciona la necesidad de muchos Repositorios de adaptar sus formularios de envío a los diversos tipos de objetos que contienen, y cuya única solución, hasta el momento, consistía en definir Colecciones diferenciadas, cada una con un <form> específico.

En la nueva versión de DSpace, se pueden incorporar restricciones a la visualización en los campos del formulario de envío de ítems al Repositorio, dependiendo por ejemplo, de determinadas características de los objetos que se están describiendo. Ahora, un determinado campo se puede hacer visible dependiendo del valor que tome el metadato dc.type señalado previamente. Esto se consigue con la introducción de un nuevo elemento, <type-bind>, en la definición de los <field> del fichero input-forms.xml cuya visualización desea restringirse en ciertos casos.

A continuación se muestra, a modo de ejemplo, un extracto de la configuración del fichero input-forms.xml, en la que el <field> “Editor” sólo será visible si previamente en el <field> “Tipo” (dc.type), se ha introducido el valor «article».

<field>
   <dc-schema>dc</dc-schema>
   <dc-element>publisher</dc-element>
   <dc-qualifier></dc-qualifier>
   <label>Editor</label>
   <type-bind>article</type-bind>
</field>

En este otro ejemplo, el <field> “ISSN” sólo será visible si previamente en el <field> “Tipo” (dc.type), se han introducido los valores «bookPart» o «doctoralThesis».

<field>
   <dc-schema>dc</dc-schema>
   <dc-element>identifier</dc-element>
   <dc-qualifier>issn</dc-qualifier>
   <label>ISSN</label>
   <type-bind>bookPart,doctoralThesis</type-bind>
</field>

NOTA: Para que esta funcionalidad esté operativa, el elemento <type-bind> debe estar definido en el input-forms.dtd de la instalación DSpace.

¿el XMLUI?.. pero si es muy fácil

Hace muchos años (muchos) tuve que estudiar un libro introductorio a la electrónica cuántica cuyo título terminaba con esa apostilla.  Me parece que ese tipo de literatura se ha reconvertido en la seríe de títulos xxxxx, for dummies,  con lo que no descartamos pasar a la fama con un libro titulado  XMLUI for dummies….

Bromas aparte, comenzemos con un pequeño glosario sobre términos usados en XMLUI:

  • Cocoon:  framework de desarrollo web (del  proyecto Apache) que utiliza los conceptos de pipeline y tiene una arquitectura basada en componentes.
  • Sitemap:   fichero  XML usado para configurar los diversos componentes Cocoon,  que son del tipo: generadores, trasnformadores, serializadores,  …
  • Aspecto/ Aspect: proporciona el conjunto de funcionalidades presentes en la interface de usuario, generando mediante transformaciones encadenadas un documento DRI.
  • DRI (Digital Repository Interface): esquema, codificado en xml,  que estructura y gobierna las páginas XMLUI
  • Tema / Theme : proporciona el estilo al contenido generado, produciendo el XHTML para su visualización. Básicamente es la herramienta que convierte un documento DRI en un formato legible por el usuario.

 

Un proceso de construcción de una página DSpace  en XMLUI realiza las siguientes tareas:

  1. Generar la página DRI, representación xml de la página solicitada, concatenando los diversos aspectos involucrados: eperson, artifact browser, etc…
  2. Añadir referencias a los ficheros CSS que usará el tema. estas referencias se incluyen en la sección pageMeta del documento DRI. De esta manera las XSL que convierten el documento DRI en XHTML pueden encontrar esas referencias y ponerlas en la salida XHTML
  3. Transformar DRI a XHTML.  Generalmente (depende algo del tema y de las personalizaciones efectuadas) se hace a través de la librería dri2xhtml.xsl  o el código modificado que se haya escrito.
  4. Se internacionaliza la página, invocando el transformador Cocoon i18n  para resolver las etiquetas <i18n:text>
  5. Se envía al navegador, aplicando la CSS correspondiente.

 

Y visto de otra manera, más directa ¿o más práctica?….  ¿cuáles son los elementos involucrados en una customización de DSpace-XMLUI?

  1. Modificación simples al diseño, creación de temas simples: XHTML + CSS
  2. Modificaciones complejas al diseño, creación de temas complejos: XSL + XHTML + CSS
  3. Añadir nuevas funcionalidades, modificación de los «aspects»: Cocoon + Java

 

El registro de formatos

DSpace admite bitstreams en una diversidad de formatos (formato: forma particular en que una información se codifica en un fichero o medio digital). La concepción inicial de Dspace se realizó con una política amplia respecto de los formatos: reconocer y soportar la mayor cantidad de formatos posibles, aunque la naturaleza propietaria de muchos formatos hace dificil garantizar lo anterior.

Administrar correctamente los formatos admitidos (en parte, mediante el registro de formatos), tal y como hablábamos en un post anterior, es una de las tareas claves de la preservación digital.
Cuando se sube un fichero a DSpace, dependiendo del formato inferido de la extensión del mismo, se le asignará uno de los tres niveles de soporte siguientes:

  • Soportado (Supported). Se reconoce y soporta completamente el formato. El administrador de Dspace lo mantendrá legible en el futuro, usando las técnicas que en cada momento considere más convenientes (conversión, migración, emulación…)
  • Conocido (Known): el formato está declarado como reconocible en el registro, pero el administrador del repositorio no puede garantizar o no ha tomado aún una decisión sobre un soporte pleno a efectos de preservación. Este podía ser el caso de formatos propietarios, pero de muy amplia difusión, (como los de Microsoft, p.ej)
  • No soportado (Unknown): el formato no está en la lista de reconocimiento de DSpace; esos ficheros aparecerán con listados como «application/octet-stream», or «Unknown»

Con el nivel de soporte, estamos haciendo una declaración sobre su uso futuro, y es responsabilidad del administrador seleccionar qué  formatos aceptará y qué servicios de evolución de los mismos se requieren para satisfacer las necesidades de los usuarios con el mejor contexto de preservación posible.

El directorio ../[dspace_inst]/config/registries contiene tres ficheros XML. El de nuestro interés es el bitstream-formats.xml. En el arranque inicial del sistema, el ant fresh_install realiza una carga inicial de dicho fichero en la BBDD.

Nota: Cualquier cambio posterior que se realice con la UI, no actualiza el fichero xml. Si efectuamos posteriormente una carga del fichero, mediante el comando registry-loader, es decir :

..\dspace_inst*\bin\dspace registry-loader bitstream-formats.xml

pues se perderán aquellos cambios que hubíesemos realizado mediante la interfaz de usuario. Lo cual es importante porque en algunos procesos de actualización de versiones (p.ej 1.7 a 1.8) hay que ejecutar este comando desde la CLI.

Los contenidos del registro de formatos de bitstreams son responsabilidad del administrador del repositorio, aunque Dspace obliga a que al menos los formatos «unknown» y «license» estén definidos. Una entrada típica de un formato definido en este registro es de la forma:

entrada <bitstream-type> del bitstream-formats.xml

<bitstream-type>
<mimetype>application/vnd.sun.xml.draw</mimetype>
<short_description>Draw 6.0 documents</short_description>
<description>Draw 6.0 documents</description>
<support_level>1</support_level>
<internal>false</internal>
<extension>sxd</extension>
</bitstream-type>

 

Ejemplo Descripción
<mimetype> application/vnd.sun.xml.draw Identificador de tipo MIME (Multipurpose Internet Mail Extensions)
<short_description> Draw 6.0 documents El nombre de formato más usual de este formato
<description> Draw 6.0 documents id
<support_level> 1 Nivel de soporte Dspace de este formato, codificado como:0= Desconocido, unknown

1 = Conocido, known

2 = Soportado, supported

<internal> false Los formatos marcados como «internal», es decir, este campo a true, se usan por el sistema, y no se representan a los usuarios
<extension> sxd Extensión habitual de filename, la parte tras el «.» del nombre completo del fichero

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.

Traducción al español de Dspace 3.0 disponible

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.

 

 

 

BIREDIAL 2012, Universidad del Norte, Barranquilla

Estuvimos presentes en la  II Conferencia Internacional sobre Bibliotecas y Repositorios Digitales -BIREDIAL , que fué organizada por la Universidad del Norte en Barranquilla, Colombia, y en la cual impartí un taller acerca de las tareas de curación en DSpace.

Antes de nada agradecer a la Universidad del Norte su excelente  hospitalidad  y ayuda permanante en toda la estancia.  (nota al margen: además es muy recomendable ir a Barranquilla porque,  aparte de ser la ciudad natal de Shakira, su gente es excepcional y siempre te atenderán magníficamente :-)

BIREDIAL  pudo reunir a profesionales de DSpace y otras herramientas de gestión de repositorios digitales,  Directore/as y resto de personal de Bibliotecas y otras instituciones, siendo un marco adecuado para intercambiar experiencias de los diferentes países a los que pertenecían todos los asistentes.

En las ponencias se comentaron experiencias acerca del uso y características de diferentes herramientas, así como determinadas  carencias que tenían,  lo que sirvió para una interesantísima  puesta en común para dar soluciones a los diferentes tipos de problemas que surgían. Desde Arvo Consultores aportamos nuestra experiencia y conocimiento de DSpace para intentar dar soluciones y orientar a las diferentes instituciones presentes.

Especificamante en el taller que impartí, y que tuvo como tema central  las tareas de curación, expuse  ejemplos prácticos asi como teóricos sobre la inclusión-activación de las tareas de curación en DSpace (para los que no estuvieron presentes, en el blog tenemos unos post acerca de las tareas de curación). Adicionalmente,  en el taller se pudo hacer una pequeña demostración de la aplicación Easydeposit (desarrollada por Stuart Lewis,  mas información aquí  y en unos cuantos post de este blog)

Para acabar el post quiero acabar con un rotundo Gracias a la Universidad del Norte por su acogida, y por supuesto  están invitados a conocer nuestra tierra.

Administradores de Colección y Comunidad

En los repositorios digitales mayores o con estructuras de colecciones y comunidades amplias, la administración puede delegarse en los Administradores de Comunidad y Administradores de Colección. Estos usuarios (en realidad son e-grupos) pueden selecionar los revisores o editores en los flujos de aprobación-revisión,  las políticas de acceso, etc.. en sus respectivos ámbitos.

Los Administradores de Colección tienen privilegios sobre una determinada Colección, y pueden decidir a quién se le permite enviar ítems a la misma, así como añadirlos, editarlos o eliminarlos.

Un Administrador de Colección, además de disponer de los menús “Listar” y “Mi Cuenta”, dispone del menú “Contexto” para la Colección sobre la que tiene permisos de administración, desde el cual podrá editar dicha Colección, exportarla completamente o exportar sus metadatos, así como relacionar ítems pertenecientes a otras Colecciones en ésa. De la misma forma, tendrá permisos para editar, exportar completamente o solamente los metadatos, de los ítems pertenecientes a esa Colección. Sin embargo, el Administrador de Colección carece del privilegio de restringir el acceso a la lectura de los ítems y archivos entrantes en la Colección, que por defecto está asignado al Grupo Anónimo, ya que este privilegio sólo está disponible para el Administrador General del Sistema.

El Administrador de Colección dispone también del menú “Estadísticas”, desde el cual puede visualizar las estadísticas de uso de su Colección y de sus ítems, pero carece de la opción de visualización de las Estadísticas generales del sistema, así como del acceso a los Informes estadísticos mensuales. Ésta también es una opción disponible sólo para Administradores Generales del Sistema.

Hay que señalar que los Administradores de Colección carecen del menú “Administrativo”, por lo que no poseen funciones generales de control de acceso y gestión de usuarios y grupos, funcionalidades sobre registro de metadatos y formatos, de importación de metadatos, tareas de curación y tampoco acceso al “Panel de control” de la herramienta. Además, un Administrador de Colección no puede crear nuevas Colecciones.

Los Administradores de Comunidad gozan de un mayor número de permisos que los Administradores de Colección, ya que son aquellos usuarios de DSpace que tienen todos los privilegios sobre una determinada Comunidad, y pueden decidir a quién se le permite enviar ítems a sus Colecciones, editar los metadatos, y relacionar ítems existentes en otras Colecciones. Además, pueden crear Subcomunidades y Colecciones, así como gestionar o asignar permisos para las mismas. Sin embargo, no pueden crear nuevas Comunidades, funcionalidad que sólo está permitida para el Administrador General del Sistema.

De manera análoga a los adminitradores de colecciónm , además de los menús “Listar”, “Mi Cuenta” y “Contexto”, el Administrador de Comunidad dispone del menú “Estadísticas”, desde el cual puede visualizar las estadísticas de uso de su Comunidad y de sus Colecciones e ítems, pero carece de la opción de visualización de las Estadísticas generales del sistema, así como del acceso a los Informes estadísticos periódicos, ya que como se ha indicado anteriormente, ésa es una opción disponible sólo para los Administradores Generales del Sistema.

Los Administradores de Comunidad, al igual que los de Colección, carecen del menú “Administrativo”, por lo que tampoco pueden realizar las tareas Administrativas descritas anteriormente.

Traduccion al gallego de Dspace 1.8- XMLUI

La traducción al gallego de la interfaz XMLUI de Dspace para versiones 1.8 y anteriores está ya disponible. El fichero messages_gl.xml se encuentra disponible en el ticket jira 1394.

La traducción se ha realizado en el marco de un proyecto para la Universidade de Vigo, revisándose por el Área de Normalización Lingüistica de dicha universidad.

Auto-Registro y Registro de Usuario

La mayoria de las funciones de Dspace, como buscar documentos o descargarlos si están en acceso abierto, pueden usarse de forma anónima, es decir, sin realizar ningún tipo de autenticación de los usuarios. Sin embargo, ciertas características de DSpace solo son accesibles a usuarios privilegiados, y eso significa ser capaz de identificarlos y una vez hecho esto, asignarles permisos y acceso a esas funciones restringidas.

Las e-personas (e-people) y los grupos son los entes usados por Dspace para identificar usuarios y asignar privilegios. Las e-personas pueden existir mediante proceso de auto-registro o bien registradas (creadas)  por un administrador.  Existen diferencias sustanciales en el uso de cada opción.

En el procedimiento de Auto-Registro de un usuario, éste accede a la sección “Registro de nuevo usuario” e introduce su dirección de correo electrónico. Dspace, de manera automática, envía un correo (con un token de seguridad) a esa dirección para que se pueda continuar el registro. Siguiendo las instrucciones del correo recibido, el usuario crea su cuenta, introducir sus datos y una contraseña. A partir de ese momento, puede acceder a Dspace mediante el formulario de login, con la dirección de correo y contraseña indicadas. Finalizado el proceso de registro, el nuevo usuario es incluido en la Base de Datos de DSpace, con un identificador único asociado.

En el procedimiento de Registro de usuario por el Administrador, es éste quien crea al nuevo usuario, accediendo a la sección de “Gestión de usuarios”, sólo disponible para usuarios con este rol, y pulsando el enlace correspondiente para añadir un nuevo usuario. El Administrador debe introducir la información del nuevo usuario, incluyendo una dirección de correo electrónico, y pulsar el botón “Crear usuario” para crear un nuevo usuario en DSpace. Mediante este procedimiento, el nuevo usuario también es incluido en la Base de Datos de la herramienta con un identificador único asociado. Sin embargo, en un principio no puede acceder a la herramienta mediante contraseña, puesto que no tiene ninguna. Este sistema se emplea principalmente cuando los credenciales de acceso a Dspace se reciben de otros sistemas de identificación como un LDAP. Claro que habrá que configurar Dspace para ello.

Como segundo escenario para que el usuario creado mediante el sistema de Registro por un Administrador pueda acceder a DSpace mediante contraseña, debería ser el Administrador quien, desde la sección de “Gestión de usuarios”, pulse el botón “Restablecer contraseña” correspondiente a dicho usuario. De esta forma, la herramienta envía, de manera automática, un correo a la dirección de ese usuario para que pueda modificar su contraseña, o, en este caso, introducir una contraseña por primera vez.

Probamos DSPACE 3.0. Y nos gusta…

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..