Exprimiendo el interface XMLUI

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

Share

Configurando SOLR

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.

Share

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.

Share

¿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

 

Share

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

Share

Curso de Administración Dspace, 1ª edición

Curso finalizado. Ver edición más reciente

Share

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.

Share

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.

 

 

 

Share

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.

Share

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.

Share