Warning: Constant WP_MEMORY_LIMIT already defined in /home/elorenzo/domains/arvo.es/public_html/dspace/wp-config.php on line 94
Documentación técnica | Hablando de DSpace - Part 2

Archivos de Categoría: Documentación técnica - Paginas 2

Authority Control en DSpace

Enviado por el 2014/02/24 Comentarios desactivados en Authority Control en DSpace

El Control de Autoridades o Authority Control es una de las piezas clave a disposición de los responsables de Repositorios Digitales para mejorar la calidad de contenidos y posibilitar la interoperabilidad entre repositorios.

Una autoridad es un conjunto de valores controlados para un dominio determinado, estando cada valor único identificado por una clave (clave de autoridad).

Un registro de autoridad es la información asociada con cada uno de los valores en una autoridad (incluyendo variaciones de deletreo, valores equivalentes y/o alternativos, etc).

Una clave de autoridad es un identificador opaco y persistente correspondiente a un registro de autoridad.

En la práctica habitual, un registro de autoridad (de nombres de autor, por ejemplo), contiene la forma autorizada del nombre del autor, establecida por la institución normalizadora como forma preferida para visualizar en sus sistemas, así como las formas variantes del nombre y nombres relacionados. Además, el registro de autoridad puede contener información relativa a la persona, representada por el punto de acceso), así como a las relaciones entre esa persona y otras entidades relacionadas, información para identificar las reglas de acuerdo con que se establecieron valores controlados, las fuentes consultadas, la agencia de catalogación encargada de establecer la normalización y la agencia responsable de establecer las formas preferidas del nombre.

Objetivos del Control de Autoridades

  • Dar consistencia e integridad a los metadatos
  • Conseguir mejorar la precisión en la recuperación de la información
  • Facilitar el intercambio de información bibliográfica

El modelo de authority control de DSPACE

El modelo de autoridades de Dspace aparece en la versión 1.6 de forma estándar, pues previamente era una pieza de código separada como add-on. La implementación en Dspace es de un framework que mediante configuración permite conectar (plug-in) clases programáticas para controlar dos aspectos básicos: Cómo se realiza la selección de valores en un metadato (choice management) y la inclusión de valores de autoridad asociados a los valores de metadatos (Authority Control).

Por tanto, no ofrece funcionalidad alguna para la gestión de las autoridades, de los registros de autoridad o de las claves de autoridad, que se consideran fuera del ámbito de DSpace y que por tanto se deberán gestionar mediante un aplicativo externo o bien desarrollos adicionales de DSpace.

Junto con el código que ofrece la funcionalidad de control de autoridades, se distribuyen con DSpace una serie de conectores con servicios de autoridades ya existentes, a modo demostrativo, como el Servicio de Nombres de la Biblioteca del Congreso (Library of Congress Names service) y el servicio de autoridades de nombres de revistas y editores Sherpa-Romeo, entre otros

Funcionalidades básicas del framework

  • Choice Management: En los elementos del Interfaz de usuario que se ocupan de la edición de metadatos (principalmente módulo de envíos para usuarios de autoarchivo u módulo de edición de metadatos para administradores) se pueden incluir funcionalidades que asisten en la selección de valores de los metadatos que se hayan configurado. Para dichos campos de metadatos se pueden generar listas de valores a partir de vocabularios extensos, navegación por tesauros jerárquicos, selección cerrada a los valores de una lista, lista abierta, …
  • Authority Control: El control de autoridades proporciona incluye la clave de autoridad junto con el valor del metadato seleccionado. Señalar que los metadatos controlados por autoridad deben llevar asociado el plugin Choice management. La información de autoridad consiste del valor del metadato, el valor de la clave de autoridad (authority key) y el denominado valor de confianza (confidence value), cuya utilidad explicaremos más adelante.
  • Visibilidad de las claves de autoridad y de los valores de confianza: En la interfaz OAI_PMH se expone únicamente el valor del metadato, (ya mencionamos antes la limitación del protocolo para exponer valores de autoridad) estando ocultos los valores de autoridad y de confianza (confidence value). Esto lo pongo alto y claro para evitar tentaciones: ES UNA MALA PRÁCTICA EXPONER LA CLAVE DE AUTORIDAD O EL VALOR DE CONFIANZA COMO METADATO, ESTOS VALORES SON EXCLUSIVOS DE DSPACE PARA SU CORRECTO FUNCIONAMIENTO.
  • Indices de autoridad:  Una característica normalmente poco conocida es la posibilidad de construir índices (browse o search indexes) que contengan sólo valores con clave de autoridad asociada. Así podemos tener un índice de autores y otro índice que incluya sólo autores validados. Además, la inclusión de un valor validado en este índice puede ser controlada mediante el valor de confianza (seguir leyendo..)
  • El valor de confianza (confidence value) se expresa como un valor simbólico dentro del rango siguiente: (aceptado, incierto, ambiguo, no encontrado, fallido) y puede asignarse adicionalmente al valor de clave de autoridad. A continuación, podemos especificar el nivel inferior de confianza que es necesario para incluir un valor de metadato en el índice construido, con lo que el índice así construido, incluirá los valores validados con ciertas condiciones, que sobrepasen ese nivel inferior (minimun confidence value).
  • Los registros de autoridad son externos a DSpace, es decir, DSpace no incluye ninguna funcionalidad para gestionarlos, depurarlos o ampliarlos, es decir, no incluye la posibilidad de añadir o asociar un valor adicional a un registro de autoridad ya existente. Típicamente es una base de datos de la institución, un proveedor externo, un servidor de vocabularios, etc… La arquitectura de plugins de DSpace permite integrar conectores a estos servicios de forma simple, sin tocar el código original de DSpace.

nota: este post es un extracto readaptado de la comunicación realizada por Sergio Nieto y Emilio Lorenzo en el congreso internacional Biredial 2013 celebrado en Costa Rica. Disponible aquí

La estructura del assetstore

Enviado por el 2013/12/04 2 comentarios

Mientras que el modelo de datos de Dspace (metadatos, workflows, estructura del repositorio, usuarios..) está soportado por la base de datos Oracle o Postgresql, los contenidos de los ítems se almacenan en el sistema de ficheros denominado assetstore.

La configuración tradicional del assetstore se realiza en el fichero dspace.cfg, mediante el parámetro:

assetstore.dir = [dspace]/assetstore para un solo sistema
assetstore.dir = [dspace]/assetstore_0
assetstore.dir.1 = /mnt/other_filesystem/assetstore_1       para más de un sistema.

La localización física de un objeto se guarda en la base de datos por lo que es de especial importancia NO mover los bitstreams entre assestores (además, el backup del assetstore tiene que formar parte de cualquier estrategia de backup). Aunque hay procedimientos para fusionar y mover assetstores, no son triviales, y los explicaremos en algún momento futuro.

Por defecto, los bitstreams nuevos se guardan en el assetstore 0 (es decir el especificado por la propiedad assetstore.dir) Para usar nuevos assetstores (cuando se nos está llenando el que usemos) hay que añadir un linea a dspace.cfg que referencie dónde deben ir los nuevos bitstreams:

assetstore.incoming = 1

Cuando se rearranque Tomcat, los nuevos envíos se archivarán en el assetstore especificado en assetstore.dir.1

Recordemos que además del fichero de contenido «tal cual» que se ingesta en el sistema, Dspace guarda una variedad de ficheros adicionales (los comentamos en este post).  Todos estos ficheros se almacenan en el assetstore en una estructura del tipo:

Clipboard05

 

Siguiendo con este mismo ejemplo,  la referencia de un ítem a «sus» ficheros se encuentra en la tabla bitstream, campo Internal_id. Así, por ejemplo, si me encuentro este identificador,  110832826281924074367996140570931140204, este fichero (bitstream, en nomenclatura dspace) se encuentra buscando los seis primeros dígitos del identificador, que indican en que Subdirectorio de tercer nivel está el item ( 11 >> 08 >> 32) y el nombre real del fichero será 826281924074367996140570931140204 (ha desaparecido toda referencia a xxx.pdf, y similar).

Clipboard07

p.d: Incidentalmente esto parece indicar que el límite máximo de un assetstore es referenciar/almacenar 100*100*100 bitstreams
p.d: Si tenemos mas de un assetstore, deberemos buscar el fichero en el assetstore indicado en el campo bitstream.store_number de la tabla bitstream.

Incorporar javascript en DSpace

Enviado por el 2013/10/17 Comentarios desactivados en Incorporar javascript en DSpace

Alguna vez se nos ha ocurrido introducir algo de comportamiento dinámico en nuestro repositorio DSpace, ya sea para cambiar el comportamiento de la página sin necesidad de cargar una nueva, o por el hecho de introducir efectos que solo javascript nos puede proporcionar.

Si cumples las anteriores condiciones, entonces continúa leyendo esta mini guía en la cual explico de una forma muy simple como introducir un fichero javascript para modificar el comportamiento en XMLUI.

Antes de nada, es recomendable tener un conocimiento básico en lo referente a la creación de temas en XMLUI, puesto que, para insertar un comportamiento javascript a DSpace vamos a tener que usar los temas ya definidos por DSpace (el método recomendado es crear un tema nuevo copiando el existente y a partir de ahí, aplicar los cambios)

Los ficheros que vamos a tener presentes son varios:

[dspace-instalación]/webapss/xmlui/themes/[nombre_del_tema]/[nombre_del_tema].xsl

[dspace-instalación]/webapss/xmlui/themes/[nombre_del_tema]/sitemap.xmap

[dspace-instalación]/webapss/xmlui/themes/[nombre_del_tema]/lib/fichero.js

Para que no suene tan abstractas las rutas, vamos a tomar de ejemplo el tema Classic y hacer las modificaciones sobre él, por lo que el primer fichero descrito antes sería… (suponiendo que el dspace-instalación esté ubicado en el directorio raíz con nombre dspace)

Classic.xsl

Ruta: /dspace/webapps/themes/Classic/Classic.xsl

En este fichero hemos de coger la información pertinente para luego poderle añadir el comportamiento javascript. Por ejemplo si queremos que en el menú aparezca un icono * que al hacer click sobre él nos despligue nueva información, hemos de coger el template correspondiente de la carpeta DRI que controla la zona del menú, pegarlo en nuestro fichero Classic.xsl y ahí lo editamos añadiendo el icono *.(Insisto, esta parte requiere un conocimiento base sobre cómo editar un tema en XMLUI)

Una vez introducido el componente por el cual nos comunicaremos con el javascript, solo nos falta añadir el fichero javascript que controlará la funcionalidad. Este fichero se ha de colocar dentro de la carpeta del tema en cualquier ubicación, aunque lo recomendable es usar la carpeta lib de cada tema.

Este fichero javascript una vez creado por el desarrollador, y ubicado en la posición del tema que queramos, lo único que necesitamos para que funcione es relacionarlo con la información añadida en el fichero XSL. Para hacer esto debemos de hacer la llamada a nuestro javascript desde el fichero XMAP, de tal forma que al pinchar sobre el icono *, este llame al javascript ubicado en la carpeta de nuestro tema a través del fichero XMAP.

Esta llamada va a tener un aspecto tal que así

<map:parameter name=»javascript#2″ value=»lib/fichero.js»/>

En el ejemplo se llama a un fichero llamado fichero.js que está ubicado dentro de  la carpeta lib de nuestro tema. He de decir que el name que se da en la llamada tiene que ser único, si no, DSpace nos generará un error.

NOTA: En el ejemplo hemos puesto javascript#2 puesto que ya hay una declaración posterior que es javascript (Esta hace referencia a jquery). El nombre que se le dé siempre es conveniente que siga el patrón siguiente: javascript#numero. El porqué hacerlo así es muy simple: DSpace a la hora de montar la página Web va a incluir esas llamadas a los javascript en el meta  y estás han de tener un orden lógico (este orden coincide con el orden alfabético de las peticiones) puesto que si no, DSpace va a tener problemas a la hora de hacer llamadas a Javascript.

Vamos a ver un ejemplo del fichero Classic.xmap

<map:parameter name=»javascript» value=»lib/jquery.js»/>

<map:parameter name=»javascript#2″ value=»lib/fichero.js»/>

Este fragmento de código se ha de introducir dentro de de una etiqueta del XMAP llamada

<map:transform type=»IncludePageMeta»>

Ojo, que esta etiqueta viene definida dos veces dentro del fichero, ya que este fichero antes de aplicar nada, tiene que verificar en qué navegador se está trabajando, (diferencia entre IE6 y el resto de navegadores, por lo que se ha de incluir el fragmento de código antedicho en ambas etiquetas)

Con todo esto ya podemos insertar de forma elegante código DSpace dentro de un tema dado en XMLUI.

Ya para acabar, simplemente decir que si queréis ver un ejemplo de código javascript incluido dentro de un tema, podéis consultar el código fuente incluido en el tema Mirage, en el cual hay algo del comportamiento javascript montado tal y como acabo de relatar.

Request-copy add-on para XMLUI

Enviado por el 2013/08/05 1 comentario

El módulo Request-copy para xmlui ha sido puesto a disposición de la comunidad Dspace. Es una  conversión al XMLUI de la funcionalidad que en su día (la primera versión era para Dspace 1.3 ¡¡) desarrolló la Universidad de Minho para JSPUI.

La funcionalidad de ‘Solicitar copia’, ‘Request Copy’ o ´Fair dealing button’, que con esa variedad de nombres se refiere esta funcionalidad en la documentación de repositorios, funciona de la siguiente forma:

  1. En todos los items restringidos, es decir no-OA (considerando éstos los que tienen permisos de acceso diferente de Anónimo) se muestra un link a «Solicitar una copia al autor»
  2. El usuario solicitante debe rellenar un formulario con sus datos de contacto y razones de su solicitud.
  3. Esos datos se envían al usuario que realiza el depósito (autores o persona delegada en su nombre).
  4. El autor (o depositante) puede responder al solicitante, usando dos posibles opciones «enviar copia» y «no enviar copia», con mensajes editables.
  5. El mensaje, tal y como lo redactó el autor, se envía al solicitante, con el fichero adjunto, si esa es la opción seleccionada.

El desarrollo se ha realizado en el marco de un proyecto para el Instituto Español de Oceanografía que ha considerado adecuado liberar el código, en palabras textuales, «para que todo el mundo pueda utilizarlo». El código correspondiente a esta función está disponible en un repositorio git , asociado al ticket Jira .

Exprimiendo el interface XMLUI

Enviado por el 2013/06/20 2 comentarios

Ya hemos explicado en otro post las diferencias entre  XMLUI  y JSPUI, dando unas pinceladas sobre el funcionamiento de XMLUI. Nuestra inclinación es más o menos clara, preferimos XMLUI:  permite aplicar  apariencias  diferentes a distintas colecciones, nos parece que separa mejor la lógica de negocio de la lógica de representación, etc …

Pues en este post daremos algunos comandos para acceder a alguno de los puntos intermedios de la cadena cocoon de transformación y que nos podrían ayudar en nuestros procesos de desarrollo y debugging.

Intentaremos (si no nos borran nuestro ejemplo) trabajar con este item http://demo.dspace.org/xmlui/handle/10673/590 (si no funciona, usar cualquier otra URL de un Dspace/XMLUI)

DRI
Para obtener el DRI subyacente debajo de esa URL, tenemos que escribir DRI/
después del path xmlui/
http://demo.dspace.org/xmlui/DRI/handle/10673/590

XML
Para obtener el XML de dicha URL, teclear:
http://demo.dspace.org/xmlui/handle/10673/590?XML
fijaros en todas las etiquetas i18n, es decir estamos antes de aplicar la transformación i18n

Idioma, i18n
Para forzar la aplicación de un idioma (sin tener que cambiar el idioma del navegador)

http://demo.dspace.org/xmlui/handle/10673/590?locale-attribute=es

http://demo.dspace.org/xmlui/handle/10673/590?locale-attribute=en

Tema
A la hora de elegir el tema o «theme» que queremos para nuestra instancia de DSpace es bastante engorroso indicar cuál queremos que sea visualizado editando el fichero [dir_instalación]/config/sitemap.xconf en sus últimas líneas…
Existe un parámetro, en el fichero de configuración dspace.cfg llamado:

xmlui.theme.allowoverrides

y si lo descomentamos y lo activamos a true podremos, podemos forzar (momentáneamente) el uso de los temas que tengamos definidos en nuestro directorio de Themes

http://demo.dspace.org/xmlui/handle/10673/590?themepath=Classic/

http://demo.dspace.org/xmlui/handle/10673/590?themepath=Reference/

Como es de suponer, si vais haciendo esto por los Dspace/xmlui de por ahí os encontrareis que niguno cambia, porque por defecto este parámetro va desactivado en el dspace.cfg. Solo lo recomendamos activar en procesos de depuración de Temas.

Mets
Y si eres de los que enredan con las XSL, esta es la URL necesaria para arrancar tus desarrollos:
http://demo.dspace.org/xmlui/metadata/handle/10673/590/mets.xml

Un saludo

Configurando SOLR

Enviado por el 2013/05/14 5 comentarios

Empecemos con una definición de la página del proyecto Apache SOLR (traducida rápidamente)

SOLR es una plataforma de búsqueda de código abierto, evolución del proyecto Apache Lucene. Sus principales características incluyen la búsqueda de texto completo,  búsqueda facetada,  indexación en casi- tiempo real, la agrupación dinámica, la integración de bases de datos, documentos ricos (por ejemplo, Word, PDF) y la búsqueda geoespacial. SOLR es fiable, escalable y tolerante a fallos, proporcionando indexación distribuida,  replicación y consultas en configuraciones con equilibrio de carga, failover automatizado y recuperación, configuración centralizada etc..

SOLR está presente en las características de búsqueda y navegación características de muchas de las mayores webs existentes (Resumiendo: es una evolución de Lucene y es extremadamente potente)

 SOLR y Dspace

SOLR se usa en Dspace para lograr dos funcionalidades: estadísticas y búsquedas. Como nada es perfecto, el uso de SOLR se mezcla con antiguas capas de código pre-existente Lucene. Así tenemos que en Dspace version 1.7, 1.8 y  3, conviven las estadísticas del «sistema» a partir del procesado de los logs del sistema  Y  las estadísticas de uso y descarga, obtenidas a partir /solr/statistics. En el -ambito de la búsqueda, la situación es que con Discovery activado, la búsqueda se hará sobre el motor SOLR y sus índices, pero la navegación por índices se hace sobre Lucene (desconcierto garantizado). Está planificado simplificar esta situación en la versión 4, eliminando Lucene… veremos..

Configurando las búsquedas SOLR

Hoy veremos el segundo bloque funcional, las búsquedas. La buena noticia es que SOLR se configura mediante ficheros XML, la mala es que esta configuración es sustancialmente más compleja que la configuración Lucene.   Rompamos una lanza: SOLR tiene una potencia espectacular aunque resulte difícil de comprender su funcionamiento. Pero… ¿quien entiende el comportamiento de Google? ¿y quién lo usa? ¿a que no podríamos vivir sin él?    Pues comprender el funcionamiento de SOLR es complejo y su potencial es enorme, aunque quizá podamos conformarnos con realizar una serie de adaptaciones.

Como ejemplo de lo anterior, y ya que teníamos pendiente hablar sobre las configuraciones de diacríticos, pues vamos a comentar como lograr lo mismo que hacíamos en Lucene en este post.

Básicamente el proceso de construcción del índice Solr es la aplicación de una serie de transformaciones a nuestros campos (fields). Las transformaciones son del mimo tipo que las que aplicábamos en Lucene. En general se mantienen los nombres de las clases transformadoras y se les añade el prefijo «solr», refiriéndose así a las clases java del paquete org.apache.solr.analysis.

Hay que especificarlas relacionándolas con el tipo de campo que queramos transformar, y esta relación se especifica dentro del fichero «principal» de configuración ../solr/search/conf/schema.xml.

En este fichero tenemos que localizar el <fieldType name=»text» ……> que es el que corresponde con los campos de tipo textual. Hay datos de múltiples tipos: numéricos, string, numéricos con ordenación textual, fechas, booleanos, hasta 39 diferentes contamos en schema.xml

pues bien dentro de esa etiqueta fielType, localizar

<filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt">

y cambiarla, añadiendo..

<filter class="solr.ASCIIFoldingFilterFactory"></filter>
<filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt">

Lo ponemos «antes» del Porter-Stemmer por las mismas razones que explicamos cuando configuramos el índice Lucene.  Ya de paso, y contestando una pregunta que nos hicísteis, aprovechamos para revisar en ese mismo fichero el operador lógico usado en las queries:

<!-- SolrQueryParser configuration: defaultOperator="AND|OR" -->

<solrQueryParser defaultOperator="AND"/>

Ahora nos queda reindexar SOLR. Nos parece que es más adecuado proceder a una reconstrucción completa del índice y por eso, la opción de borrado del índice.

..\bin\dspace update-discovery-index -b

Y ya debiera estar. Suerte.

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

Enviado por el 2013/04/15 Comentarios desactivados en 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 registro de formatos

Enviado por el 2013/02/18 Comentarios desactivados en 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

Enviado por el 2013/02/11 2 comentarios

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

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.