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

Archivos de Tags: CLI

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

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.

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…