Archivos de Categoría: Documentación no técnica

Traducción al español de Dspace 5 (y 4) disponible

Ya está puesta a disposición de la comunidad DSpace la traducción al español de la versión 5.0 e interfaz XMLUI. El fichero messages_es.xml y el resto de ficheros de idiomas de la release está incorporado en la distribución de la versión 5.0, además de encontrarse ya disponible en el ticket jira 2233 o en el github

Así, está disponible el fichero de traducción de los mensajes correspondientes al Discovery, SwordClient y XMLWorkflow.  Recordar que desde la versión 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…

Además, como los ficheros de mensajes son compatibles con versiones atrasadas, pues se puede incorporar a las versiones 4 (de las que no se disponía de versión traducida)

Share

Open repositories 2014

Ya han pasado unas semanas desde la conferencia Open Repositories 2014. Decir que la OR2014, este año en Helsinki con cerca de 500 delegados en esta edición, es posiblemente el evento más importante del calendario del Acceso Abierto, con énfasis en las realizaciones prácticas y planteamientos tecnológicos.

Este año fuimos uno de los  patrocinadores de la conferencia, y ante todo, queríamos dar las gracias a los organizadores (la National Library de Finlandia) por la excelente hospitalidad recibida. 

IMG_20140610_154710

Comentaríamos que se presentaron muchos proyectos e iniciativas relacionados con la preservación (Hydra, Dryad..) los repositorios (DSpace, ePrints, Fedora, Islandora e Invenio) y las plataformas de servicios (Figshare, OpenRepository, DuraCloud, DspaceDirect, eudat…), pero ¿qué hay de nuevo en el ámbito de Dspace?  (recordemos que se aprovecha la celebración de OR2014 para realizar el DSpace Interest/User Group Meeting). 

De nuestro particular interés,  reseñaríamos:

  • el interés en los estándares de indentificación común, como ORCID, y se plantea su integración en el core de DSpace 5.
  • El desarrollo de funcionalidades de interoperabilidad entre plataformas, como determinadas integraciones con PubMed o WoS
  • Las nuevas interfaces adaptativas disponibles tanto en XMLUI (Mirage 2) como en JSPUI
  • las adaptaciones de compatibilidad OpenAire
  • el nuevo modelo de gobernanza de Dspace
  • y…

Las presentaciones del OR2014 podeis verlas aquí (todavía están subiendo algunas…..)  y  grabaciones del martes, miércoles y jueves,  de las sesiones de la conferencia aqui

 

 

Share

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

Curso finalizado. Ver edición más reciente

Share

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.

Share

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

Curso finalizado. Ver edición más reciente

Share

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.

Share

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

Share

Embargo en DSpace 3.x

Hasta la versión 3 de DSpace, el embargo era una restricción temporal de acceso a los bitstreams de los ítems. Durante el período de embargo, los metadatos de los ítems seguían estando disponibles para cualquier usuario, pero los bitstreams sólo estaban disponibles para usuarios administradores. El ámbito o duración del embargo podía variar, pero el hecho de que con el tiempo expirase era lo que lo distinguía de otras restricciones a los contenidos.

En la versión 3 de la herramienta, esta funcionalidad se ha extendido con una opción avanzada, que se establece en la siguiente línea del fichero dspace.cfg:

 xmlui.submission.restrictstep.enableAdvancedForm = true

El embargo avanzado permite establecer embargos para bitstreams de manera individualizada, añadiendo nuevas políticas de acceso a los mismos. Ofrece al usuario la oportunidad de gestionar manualmente las políticas de acceso a los bitstreams, con lo que además de poder establecer el embargo para los usuarios anónimos, se hacen posibles situaciones como establecer el embargo para cualquier usuario excepto para los pertenecientes a un grupo determinado, o establecer el embargo para ciertos grupos y no para otros, etc.

Adicionalmente, se ha incluido la posibilidad de hacer privados los ítems, permitiendo controlar la visibilidad de sus metadatos en los diferentes índices de la herramienta (búsqueda, navegación, discovery, etc), así como en las interfaces externas (REST-API, OAI-PMH, etc). En este caso, sólo los usuarios administradores podrán acceder a los ítems privados, con la nueva opción “Items Privados” del menú “Administrativo”, que les permite visualizar la lista de ítems privados existentes.

También es posible ajustar el estado “Público/Privado” de un ítem después de que haya sido archivado en el repositorio, con un nuevo botón disponible en la pantalla de edición de ítems. Pero hay que tener en cuenta que una vez el estado de un ítem sea privado, sólo los administradores podrán acceder a ellos para cambiarlo al estado público.

Hay que señalar que los usuarios de la Interfaz JSPUI todavía no podrán beneficiarse de algunas de estas mejoras, ya que por en la version 3 sólo están disponibles para la Interfaz XMLUI.

Share

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.

Share

Versionado a nivel de ítem en DSpace 3.x

En la versión 3 de DSpace se ha incluido un sistema de versionado a nivel de ítem, que permite acceder a la historia de un ítem y posibilita el citar una versión particular del mismo.

El versionado a nivel de ítem es una nueva funcionalidad que permite construir la historia de un ítem. Los usuarios Administradores generales y los Administradores de Comunidad y Colección, tienen ahora la oportunidad de crear una nueva versión de un ítem existente cada vez que se hace un cambio en el mismo.

Cada versión de un ítem está representada por un identificador de versión independiente, que la deja accesible y permite que pueda ser citada. En las versiones anteriores de un ítem, se muestra un mensaje señalando el identificador de la versión más reciente del mismo.

Es necesario indicar que sólo la versión más reciente de un ítem se muestra en los resultados de las búsquedas.

Por defecto, la funcionalidad de versionado a nivel de ítem, sólo soportada en XMLUI, está desactivada. Para proceder a su activación, hay que descomentar la siguiente línea del fichero xmlui.xconf:

<aspect name="Versioning Aspect" path="resource://aspects/Versioning/" />

Actualmente, no existe una opción de configuración para permitir a los usuarios publicadores crear nuevas versiones de un ítem. Esta funcionalidad se limita a los Administradores generales y a los Administradores de Comunidad y Colección. Sin embargo, en un contexto donde los envíos originales de ítems a DSpace se realizan por usuarios no Administradores, tendría sentido que también pudiesen crear nuevas versiones, especialmente teniendo en cuenta el hecho de que las nuevas versiones tienen que pasar a través del flujo de trabajo definido.

Es importante tener en cuenta que al establecer el versionado a nivel de ítem, por defecto, el nombre y el email de los publicadores son visibles para todos los usuarios en el historial de versiones del ítem.

historial de versiones

De momento, la única solución para esto consiste en ocultar el historial de versiones a los usuarios generales, y dejarlo disponible sólo para usuarios Administradores. Para ello, hay que cambiar a true el valor del parámetro item.history.view.admin del fichero versioning.cfg ubicado en el directorio [dspace]/config/modules/.

Share