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

 

Curso de Gestión de Derechos en Repositorios Digitales, 2ª Edición

Curso finalizado. Ver edición más reciente

Licencias Creative Commons en las diferentes versiones de DSpace (Parte 2)

Tal y como habíamos prometido, en esta ocasión vamos a tratar el proceso de asignación de licencias Creative Commons dependiendo de la versión de DSpace utilizada.

En la versión 1.7 de DSpace, en la pantalla de licencia Creative Commons del proceso de envío de ítems, existía un botón “Acceder a Creative Commons para elegir una licencia”, que enviaba al usuario a una página externa de Creative Commons donde debía contestar a dos preguntas para seleccionar la licencia deseada.

imagen1

Después de pulsar el botón “Escoge una licencia”, se mostraba la selección realizada y un enlace “proceder” para regresar al repositorio y continuar con el proceso de envío.

Una vez el ítem era publicado, en el bundle CC-LICENSE eran almacenados los siguientes tres ficheros: license_url (en formato License, conteniendo la url de la licencia asignada), license_text (en formato CC License, con el texto de la licencia asignada) y license_rdf (en formato RDF XML con el texto de la licencia asignada). Y en la sección “Este ítem tiene asociados los siguientes ficheros de licencia” de los registros simple y completo, se mostraba un enlace denominado “Creative Commons”, que mostraba el texto de la licencia Creative Commons asociada a dicho ítem, contenido en el mencionado fichero license_text.

En la versión 1.8, sin embargo, en la pantalla de licencia Creative Commons del proceso de envío de ítems se disponía de un desplegable para seleccionar hasta 5 tipos diferentes de licencias (Creative Commons, Public Domain, Public Domain Mark, Sampling y CC0), según la declaración del parámetro

cc.license.classfilter

del fichero dspace.cfg, sin necesidad de abandonar el repositorio.

En el caso de seleccionar una licencia Creative Commons, se mostraban dos preguntas cuya respuesta permitía seleccionar un tipo u otro de licencia Creative Commons. Por ejemplo, una respuesta negativa a ambas preguntas, seleccionaba una licencia Creative Commons by-nc-nd.

Al seleccionar una licencia en esta pantalla, automáticamente DSpace asignaba dos metadatos, por defecto el dc.rights y el dc.rights.uri, al ítem que se está enviando. En el metadato dc.rights se almacenaba el nombre de la Licencia seleccionada. En el ejemplo anterior sería Attribution-NonCommercial-NoDerivs 3.0 Spain, siempre y cuando la jurisdicción elegida para la licencia fuese la española, aspecto configurable en el parámetro

cc.license.jurisdiction

del fichero dspace.cfg. En el metadato dc.rights.uri se almacenaba la uri de la Licencia seleccionada. Siguiendo con el mismo ejemplo sería http://creativecommons.org/licenses/by-nc-nd/3.0/es/, también si la jurisdicción elegida para la licencia fuese la española.

Al finalizar el proceso de envío, además de estos dos metadatos automáticos, en el bundle CC-LICENSE se almacenaba un único fichero license.rdf. Adicionalmente, se añadía un logo de Creative Commons al ítem, que si se pulsaba redirigía al usuario a la página de Creative Commons de la licencia que le hubiese sido otorgada.

imagen2

Este proceso de asignación de Licencias Creative Commons se ha mantenido en la versión 3.2 de DSpace.

Como puede observarse una vez leídos éste post y el previo sobre las licencias Creative Commons, los procesos de activación, configuración y asignación de las mismas son mucho mejores a partir de la versión 1.8 de DSpace, ya que, además de poder decidir fácilmente para qué Colecciones se desea activar el paso de asignación de estas licencias, para otorgarlas el usuario no abandona en ningún momento la herramienta, el proceso de asignación de metadatos es automático, y además se incorpora un logo linkable a la página de Creative Commons correspondiente en cada caso.

Licencias Creative Commons en las diferentes versiones de DSpace (Parte 1)

Los procesos de activación, configuración y asignación de las licencias Creative Commons han ido cambiando con las diferentes versiones de DSpace, mejorándose sustancialmente con el cambio de la versión 1.7 a la 1.8, y manteniéndose este comportamiento en la versión 3.2 de la herramienta.

En este primer post sobre las licencias Creative Commons, hablaremos sobre la activación y la configuración de las mismas.

En cuanto a la activación de estas licencias, en la versión 1.7 era necesario especificar en el fichero dspace.cfg el valor del parámetro

webui.submit.enable-cc = true

En la versión 1.8, sin embargo, las licencias Creative Commons se establecían como un paso configurable del proceso de envío de ítems, y su activación requería descomentar el paso señalado a continuación, en el fichero item-submission.xml, proceso que se ha mantenido en la versión 3.x:

<!-- Uncomment this step to allow the user to select a Creative Commons license -->

<!--

<step>

<heading>submit.progressbar.CClicense</heading>

<processing-class>org.dspace.submit.step.CCLicenseStep</processing-class>

<jspui-binding>org.dspace.app.webui.submit.step.JSPCCLicenseStep</jspui-binding>

<xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.CCLicenseStep</xmlui-binding>

<workflow-editable>false</workflow-editable>

</step>

-->

Esto facilitaba, por lo tanto, su habilitación de manera general para todas los procesos de envío de ítems definidos, o bien solamente para una Colección o Colecciones concretas.

Respecto a la configuración de las licencias Creative Commons, en la versión 1.7 tan sólo existía una pequeña parte configurable mediante el fichero dspace.cfg. Además de su activación mediante el parámetro

webui.submit.enable-cc

también se podía seleccionar la jurisdicción a utilizar para las mismas en el parámetro

webui.submit.cc-jurisdiction

En la versión 1.8, al igual que en la 3.x, además de seleccionar la jurisdicción a utilizar, también se pueden configurar las licencias a mostrar en el combo de selección de licencias del paso “Licencia CC” del proceso de envío de ítems, y los metadatos donde almacenar de manera automática el nombre y la url de la licencia seleccionada si así se desea.

Dejamos para un próximo post la descripción del proceso de asignación de las licencias Creative Commons en las diferentes versiones de DSpace.

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í

Curso de Gestión de Derechos en Repositorios Digitales, 1ª Edición

Curso finalizado. Consultar la programación de cursos aquí

Curso de Administración DSpace, 3ª edición

Curso finalizado. Consultar la programación de cursos aquí

Interfaz OAI en DSpace 3.x

En la versión 3 de DSpace se ha incluido una nueva Interfaz OAI-PMH que, además de facilitar la adecuación del Repositorio a los aspectos derivados de la recolección, puede simplificarnos la compatibilidad con las Directrices DRIVER y OpenAIRE.

Hasta ahora, se podía interrogar a un Repositorio mediante el uso de comandos OAI-PMH, emitidos desde cualquier navegador (al fin y al cabo el protocolo PMH se apoya en http) puesto que la mayoría de ellos están incluyen el soporte para que sus contenidos sean recolectados por los agregadores vía este Protocolo.

Considerando el caso habitual de que el OAI esté desplegado en el directorio [webapps]/OAI/ de DSpace, las consultas OAI-PMH son de la forma:

URL base de la instancia DSPACE/oai/request?verb=Xxxxx

Siendo Xxxxxx  los verbos utilizados para las consultas OAI-PMH, cada uno de ellos con una serie de atributos y modificadores, y cuya sintaxis se describe en el documento del estándar del Protocolo (http://www.openarchives.org/OAI/openarchivesprotocol.html#ProtocolMessages), los siguientes:

Identify, ListRecords, ListSets, ListMetadataFormats, ListIdentifiers y GetRecord.

A partir de la versión 3 de DSpace, se ha añadido una hoha de estilos que posibiliat realizar las anteriores consultas utilizando una Interfaz gráfica, que facilita sobremanera dicha tarea.

Clipboard02Además, la nueva versión, ha integrado una nuevas librerías OAI (xOAI, que sustituye al código OAI usado en anteriores versiones, originario de OCLC) que posibilitan la implementación de diferentes Interfaces OAI para cada uno de las necesidades de sets virtuales que requiera el Repositorio, de acuerdo con sus requerimientos en materia de metadatos, facilitando la creación de estos sets virtuales, mediante operaciones de filtrado y la transformación. Esto es de gran utilidad para el cumplimiento de Directrices como DRIVER y OpenAIRE.

Las Interfaces DRIVER y OpenAIRE, se muestran realizando las siguientes consultas, respectivamente:

URL base de la instancia DSPACE/oai/driver?verb=Identify
URL base de la instancia DSPACE/oai/openaire?verb=Identify

Básicamente, se ha realizado una reforma completa, realizada por la empresa portuguesa Lyncode,  que podría considerarse una evolución natural del Addon OAI-Extended (puesto que los compañeros de Lyncode provienen de una amplia experiencia desde la empresa KeepSolutions y desde Repositorium de la Universidade do Minho)  basándose en un framework OAI mejorado.

La estructura del assetstore

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.