Author Archives: Adán Román

Altmétricas en DSpace. Trasteando con la API de Altmetric.

Las altmétricas o altmetrías miden el impacto de la investigación mediante el uso de métricas alternativas a las métricas de citas, cuantificando su presencia en la redes  sociales, en forma de menciones en la web social, descargas, enlaces, cobertura mediática, inclusión en gestores de referencias, etc . Como exponente principal de estas nuevas métricas, figura Altmetric, que pone a disposición de nuestros repositorios (y de quien quiera) de un mecanismo base de integración en forma de API.

Explicaremos una de las varias formas de usar esta API.  La incorporación del API de Altmetric en DSpace no es complicada de realizar, pues Clipboard02simplemente necesitamos acceder a la carpeta de nuestro tema y realizar una serie de modificaciones al código de vista-de-item.

Debemos saber que la API de Altmetric requiere que se le pase un parámetro de identificador de objeto. Puede ser un identificador doi, un PMid, una uri, etc…. El ejemplo lo vamos a aterrizar con doi, por lo que en el ítem DSpace tendremos algo así como un dc.identifier.doi para almacenar el valor correspondiente al identificador digital.

El primer fichero que debemos de editar es el fichero item-view.xsl (o equivalente en temas no mirage). Ahí debemos de realizar una llamada a una plantilla (template)  que llamaremos p.ej. itemSummaryView-altmetrics . Dicha llamada se deberá de realizar a su vez (ya sabéis que el xsl es un poco recursivo….)  sobre una plantilla que tenga acceso a la información dublin-core del item (por ejemplo itemSummaryView-DIM-fields), puesto que necesitamos pasar a la plantilla la información del metadato dc.identifier.doi

Llamada a la plantilla (en dónde pongamos la llamada ya es otro asunto, los iconos Altmetric se dibujarán en donde defináis):

<xsl:call-template name=»itemSummaryView-altmetrics»/>

Además debemos de crear la plantilla con el script de altmetrics,  algo así como:

<!– con codigo –>

 <xsl:template name=»itemSummaryView-altmetrics»>      
          <xsl:param name=»link» select=»//@OBJID» />
          <xsl:param name=»doi» select=»//dim:field[@element=’identifier’][@qualifier=’doi’]»/>
          <div class=»simple-view-icons»>
          <xsl:choose>
              <xsl:when test=»$doi»>
                <script type=’text/javascript’ src=’https://d1bxh8uas1mnw7.cloudfront.net/assets/embed.js’>&#160;</script>
                
                <span title=»Almetrics» data-badge-popover=»bottom» data-badge-type=»2″  data-hide-no-mentions=»true» class=»altmetric-embed»>
                    <xsl:attribute name=»data-doi»>
                         <xsl:value-of select=»$doi»/>
                    </xsl:attribute>
                </span>
                
            </xsl:when>
            <xsl:otherwise>
                <span title=»Almetrics» data-badge-popover=»bottom» data-badge-type=»2″  data-hide-no-mentions=»true» class=»altmetric-embed»>
                    <xsl:attribute name=»data-handle»>
                         <xsl:value-of select=»substring-after($link,’handle/’)»/>
                    </xsl:attribute>
                </span>
            </xsl:otherwise>
            </xsl:choose>
        </div>
      </xsl:template>

Una vez guardado no necesitamos rearrancar tomcat ni nada. Si véis que no aparece nada cercioraros de que estáis pasando un identifier.doi de un objeto que existe y mejor aún con citas… (es decir, las pruebas hacerlas con un código doi «con substancia»)

NOTA DISEÑO: para personalizar el icono, solo hay que cambiar el parámetro data-badge-type y ponerle un número, por ejemplo si ponemos data-badge-type=»4″ obtendremos el clásico donut o rosco de Altmetric. La información sobre los diferentes badges que podéis usar está en https://api.altmetric.com/embeds.html, variando desde el donut de Altmetric hasta «cosas» mas abstractas que seguro desconciertan a más de un autor…

Clipboard04  Clipboard07Clipboard08

                                                                                                                                                                 Pues que disfrutéis y uséis el código y que vuestros usuarios os lo agradezcan.

BIREDIAL 2014

Siempre que podemos asistimos a la conferencia BIREDIAL, Conferencia Internacional sobre Bibliotecas y Repositorios Digitales,  y así, este año nos desplazamos a Porto Alegre, Brasil, en donde se organizaba Biredial 2014.

Queremos agradecer antes de nada, la gran hospitalidad que nos ofrecieron durante las conferencias y todo el apoyo que nos brindaron durante los días de la conferencia.

Este año presentamos una comunicación sobre  DSpace y los interfaces móviles,  que podéis leer aquí, y además presentamos una ponencia conjuntamente con el Instituto Español de Oceonografía, en donde se expuso una visión global de las actuaciones en  el repositorio del Instituto, haciendo hincapié en las mejoras introducidas en el último año (autoridades, integración con sistema de gestión de investigación, vocabularios temáticos, integración básica con ORCID…)

IMG_0545

 

 

 

La interfaz JSPUI en DSpace 4

¡Si!, lo reconocemos, creemos que una vez que se aprende a usar XMLUI tiene mas ventajas que el interfaz JSPUI,  pero no obstante, dado que damos soporte a alguna instalación JSPUI, es necesario conocer sus líneas de evolución.  Por ello aquí os dejo mi pequeña aportación al JSPUI,  que en este caso es la customización del nuevo interfaz.

Una vez instalamos la versión 4 de DSpace nos encontramos que el interfaz de JSPUI  ha sido cambiado drásticamente. El interfaz «clásico» existente en cientos de instalaciones de DSpace por todo el mundo, y que era la «marca de la casa JSPUI»,  ha dejado paso en esta versión a un interfaz adaptativo, permitiendo la visualización de Dspace en cualquier tipo de pantalla, sea PC, tablet o dispositivos móviles.

Como explicábamos en nuestro post sobre mirage2 (liberado por nuestros compañeros de @tmire), este interfaz sigue la misma política para construir el interface adaptatativo, aunque claramente la forma de instalarlo o configurarlo es diferente (y los resultados son igualmente diferentes)

El tutorial que más nos ha gustado, proviene directamente de la comunidad Duraspace, puedes descargarlo aquí , páginas 29 a 38, y viene detalladamente explicado como modificar el interfaz JSPUI para poder añadir nuestros colores y logos de nuestra institución sin mayores quebraderos de cabeza. Básicamente nos cuenta cómo en 4 pasos podemos adaptar el interfaz de forma básica:

1- Cambiar los logos institucionales: Para ello modificamos los logos:

  • logo.gif 
  • dspace-logo-only.png

La ruta donde nos encontramos estos logos es la siguiente:

[dspace_i]/jspui/images/

2- Crear un nuevo tema de cero. Tenemos tres  urls en las que podemos descargarnos una serie de plantillas de tema prefijadas, o bien hacerlas nosotros de cero. Estos enlaces son los siguientes:

Usé personalmente el último de ellos, que considero es mas detallista y completo, pero a la vez más complejo si no se entienden las propiedades css. Además, mediante un formulario pude realizar mi propia adaptación simplemente rellenándolo. Si no se tiene mucho conocimiento de CSS se puede optar por bootswatch ya que nos da unas plantillas prefijadas y simplemente las podemos incluir en nuestro repositorio.

3- Aplicar los cambios: Una vez creas el estilo, lo descargas  y aplicas los cambios en el directorio

[dspace_i]/jspui/static/css/bootstrap/

4- Insertar iconos e imágenes: Aparte de insertar las css generadas de vuestro tema, si se han integrado nuevas imágenes, se han de meter en la siguiente dirección:

[dspace_i]/jspui/images/

Obviamente esta documentación es nada más que un inicio para plantar las bases de unos desarrollos posterioees, y sobre todo evitaros la primera aprensión que supone afrontar este nuevo interfaz, que no tiene nada que ver con el que nos encontramos en las versiones anteriores de DSpace.

Por ello os animo a probar dicho interfaz y si tienen dudas  no tienen mas que ponerse en contacto con nosotros.  Muchas gracias a todos los DSpacers que nos leen, y por cierto os dejo con mi obra:

 

Dspace 4.X JSPUI

Dspace 4.X JSPUI

Probando Mirage2

Buenas a todos, lectores.

Tras los anuncios de las últimas semanas de la nueva interfaz adaptativa de Dspace para XMLUI,  queríamos probar el nuevo tema Mirage2 que acaban de liberar nuestros amigos de @tmire. Señalar que Mirage2 está disponible para las versiones 3 y 4 de Dspace y que está llamado a convertirse en la interfaz «estándar» de DSpace v5-XMLUI.

Sobre todo, hay que descubrirse ante el buen trabajo que ha realizado @tmire, ya que podemos ver como han suavizado el tema Mirage sin dejar de lado la gran funcionalidad que ya existía y por supuesto  añadiendo las funcionalidades de liquidness y responsiveness (lo siento pero no vamos a traducir estos términos)

Adaptive is characterized by having defined layouts for different resolutions. Within each layout, resizing the window does not change the layout.

Liquid (also called «Fluid») is characterized by scaling the width of parts of the design relative to the window. It tends to fail when the window is much smaller or much larger than it was originally designed for.

Responsive is characterized by having defined layouts for different resolutions. Within each layout, the design is liquid and resizes the width of elements relative to the changing window size.

 

 

Mirage 2

Así se ve Mirage2

A primera vista me he fijado que se adapta perfectamente a la pantalla incluso con cambios de tamaño debido a su diseño responsivo.

Aprovechando el cambio, se han introducido modificaciones en la página principal (recolocación de menús), en la vista de colecciones y en la vista del item. En ésta, vemos como se da más representatividad a los thumbnails ocupando un espacio más visible en la página respecto a Mirage.

view item

Vista de Item en Mirage2

¿ESO ES TODO?

No. La principal novedad que tiene Mirage2 no es su rediseño sino su gran compatibilidad con otro tipo de tamaño de pantallas, haciendo que este interfaz se adapte al tamaño de cualquier monitor de PC y lo más novedoso de todo es que hay necesidad de habilitar el aspecto mobile que se podía crear para las versiones 1.8, 3 o 4 de DSpace.

VISTA MÓVIL

Haciendo pruebas desde el smartphone podemos apreciar como el meńu derecho desaparece según cambiamos de tamaño de pantalla, sustituyendo ese menú por un icono situado arriba a la derecha, en el cual, si lo pulsamos tenemos acceso a las mismas funcionalidades de la página completa.

Lo mismo ha ocurrido con el menú «mi cuenta» que se ha cambiado por un icono que aparece al lado del icono del menú.

vista en móvil

Vista en un móvil

VISTA EN TABLET

En la tablet también se experimentan los cambios,  ya que si permaneces con la tablet en forma horizontal tienes una visión mas próxima a la vista en un PC. En cambio, si se gira la tablet se comporta más bien como un móvil.

tablet vista normal

Tablet en horizontal

tablet en vertical

Vista con la tablet en vertical

 

Pues bueno,  DSpacers,  eso es todo por el momento. Seguiremos trabajando por seguir aprendiendo y modelando este gran interfaz que tiene muchas posibilidades.

A continuación os dejo los enlaces a @tmire para que probéis vosotros mismos el interfaz o si queréis trastear con él (si no podéis esperar a que salga la versión 5 de Dspace)

Vista: https://atmire.com/preview/

Descarga: http://atmire.com/website/?q=download-mirage-2

ejemplo: OpenKnowledge Wordlbank

otro: Trinity´s Access to Research Archive

 

Métodos usados en el Authority Control

Una vez explicado en el post anterior el modelo de control de autoridades en DSpace, vamos a profundizar algo más en el authority control. En concreto os voy a comentar los aspectos más destacables que tiene la clase encargada de hacer funcionar el authority control.

SampleAuthority es el modelo de ejemplo que se usa para poder a empezar a desarrollar nuestra funcionalidad del modelo de autoridades. (Aunque lo más correcto es crear nuestra propia clase Autoridad copiando el SampleAuthority)

Esta clase la podemos localizar dentro del DSpace API en la siguiente ruta:[dspace-src]/dspace-api/src/main/java/org/dspace/content/authority/SampleAuthority.java

Esta clase tiene un aspecto como el siguiente (no se incluye todo el código)

public class SampleAuthority implements ChoiceAuthority{    

    public Choices getMatches(String field, String query, int collection, int start, int limit, String locale){
       
    }

    public Choices getBestMatch(String field, String text, int collection, String locale) {
    }

    public String getLabel(String field, String key, String locale) {
    }
}

Básicamente lo primero que vemos es que la clase ha de implementar al interfaz ChoiceAuthority, y en el nos toca programar sus tres métodos principales

getMatches: este método ha de retornar un listado con todas las coincidencias buscadas a partir de la búsqueda introducida por el usuario, por lo general serán apellidos. Es decir si el usuario busca autores por el apellido Nieto, este método debería de retornar todos los autores de la BBDD con el apellido Nieto;

  • Nieto Español, Juan
  • Nieto Caramés, Sergio
  • Española Nieto, Juana

getBestMatch: Este método está pensando en devolver el mejor resultado posible, es decir si antes buscábamos solo por el apellido para mostrar un listado de autores con apellido parecido, con este método hemos de aproximar el resultado a uno posible.
En cuyo caso de que el resultado sea único debemos de dar un grado de confianza del mas alto posible. (Por lo general con un valor de confianza UNDEFINED ha de ser suficiente)

Este método hay que implementarlo bien, puesto que cada vez que se introduzca un metadato controlado (que use Authority Control), DSpace va a ser el encargado de validarlo automáticamente. Es decir que nos sirve para automatizar las tareas de los usuarios administradores, pero mejor que lo hagamos de forma precisa.

getLabel: Este método ha de resolver el problema de nombramiento que tiene DSpace con los autores validados, ya que por definición, DSpace coge el valor clave de autoridad y lo muestra como nombre de autor, por lo que debemos con este método cambiar por un valor de autor que se asocie a ese identificador.

Una vez programada esta clase (compilada y desplegada) solo falta rellenar la configuración detallada en el fichero de configuración dspace.cfg para que se asocie el proceso a un metadato que queramos como por ejemplo el dc.contributor.author. (toda esta información viene detallada en la documentación de DSpace accesible desde el código fuente o desde su web ;D)

Bueno ahora solo toca entender bien las especificaciones que deseamos aplicar a nuestro modelo de autoridades y programarlo según esas espacificaciones.

Mucha suerte

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í

Arvo Consultores en Biredial 2013

Este año Arvo Consultores también asistió a Biredial 2013 en la cita de Costa Rica. Hasta ahí viajó Sergio Nieto, para impartir un taller sobre el Control de autoridades en DSpace, en el cual explicamos el porqué de esta funcionalidad authority control, las particularidades de su implantación en DSpace y los consejos y recomendaciones para su implantación exitosa.

IMG-20131017-WA0001

En el evento, agradecer a Meilyn Garro y al resto del comité organizador de la Universidad de Costa Rica la bienvenida que nos brindaron. Esperamos la programación de Biredial 2014 y que según parece puede que se realice en Brasil… eso el tiempo nos lo dirá.

Para mas información sobre lo que ocurrió en el evento, programa y demás no dejen de consultar la siguiente página de Biredial   http://biredial2013.ucr.ac.cr/index.php/Biredial2013/ai

Si desean ver las fotos de los participantes al evento en facebook:

https://www.facebook.com/media/set/?set=a.682451368454664.1073741828.136503766382763&type=3

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.

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

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.