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

Estrenamos blog, Hablando de OJS

Fruto de nuestra actividad profesional y experiencia, lanzamos un nuevo espacio de reflexión y divulgación de información sobre OJS homólogo a nuestro blog sobre temas de DSpace, denominado Hablando de OJS

Nuestro principal objetivo es aportar información de valor a todas aquellas personas interesadas en el mundo de las publicaciones electrónicas y, especialmente, a los usuarios del sistema OJS de PKP.

Confiamos en que los temas a tratar os resulten interesantes y pedimos, de manera anticipada, vuestra participación a través del blog para enriquecer nuestro espacio de divulgación de información y conocimientos OJS.

Podréis acceder al contenido del mismo en esta dirección   http://www.arvo.es/ojs

Nuevos ficheros de idiomas de catalán y valenciano

A partir del trabajo efectuado en un par de proyectos Dspace, se han generado y puesto a disposición del resto de proyectos DSpace los siguientes ficheros de mensajes

DSpace Version 6, XMLUI, Catalán:  Traducción a la versión 6 realizada por EINA, Centre Universitari de Disseny i Art de Barcelona, a partir del fichero messages_ca.xml de la version 5, cuya traducción proviene de la Universitat de Vic  y puesto a disposición de otros proyectos por cortesía de su Biblioteca Universitaria.  Se puede descargar en el siguiente enlace

https://github.com/arvoConsultores/DSpace/blob/dspace-6_x/dspace-xmlui/src/main/webapp/i18n/messages_ca.xml

DSpace Version 5, XMLUI, Valenciano: A partir de una traducción pre-existente  de la Universitat de Valencia para la versión 4, se ha  traducido para la versión 5 por el Instituto Valenciano de Investigaciones Agrarias.  Se puede descargar en el siguiente enlace

https://github.com/arvoConsultores/DSpace/blob/dspace-5_x/dspace-xmlui/src/main/webapp/i18n/messages_ca.xml

 

 

 

 

Versiones en DSpace

Nos preguntan en ocasiones qué significan los números de las versiones de Dspace. Vamos a intentar explicarlo:

Antes de 2012, las versiones se numeraban como 1.x, 1.6, 1.7 y 1.8.. Cada año aproximadamente se lograba terminar una versión nueva y se liberaba.  En ese momento, 2008 -2010,  se tenía en mente la version “definitiva”, DSpace 2. Todavía hay documentos indexados por google que hablan de esa versión.

Pero esa versión 2 nunca llegó, así que en 2013 se decidió comenzar un nuevo esquema de numeración de versiones en forma [major].[minor].  Dspace desde entonces se numera como 3.0 (la primera tras el cambio de criterio) 3.1, 3.2…. 4.0,  4.1. Nunca hubo una versión 2 de Dspace.

¿Y cómo se decide el [major].[minor]…?

Incrementar el primer número, [major], significa que estamos ante una versión principal de Dspace. Esta incluye: nuevas funcionalidades, cambio de arquitectura, mejoras del sistema y corrección de errores.  Así, las versiones 3.0, 4.0, 5.0, 6.0 y la próxima 7.0, suponen una evolución sustancial del software.  Evolucionar entre versiones, cambiando el primer número, supone por lo general un esfuerzo considerable para:

  • La comunidad de desarrolladores de Dspace, que intenta mantener un calendario de una [major] por año, aunque no siempre se consigue.
  • Los repositorios DSpace, las instalaciones propiamente dichas, que deben ejecutar procedimientos de migración de datos y código entre versiones, prueba de la nueva versión, formación en las nuevas funcionalidades, etc. Es decir, proyectos por lo general, complejos.

Dspace releases

Las versiones menores [minor] son las que incrementan el segundo número. Sólo incluyen parches y resolución de bugs (bugs fixes) de la versión principal. Así tenemos p.ej. 5.1, 5.2, 5.3, 5.4, 5.5 y 5.6 por ahora.  Moverse entre versiones menores es un proceso por lo general simple. Basta con (haciendo un backup) actualizar nuestra version en los directorios fuente, y desplegar. Por lo general es un proceso simple…(¡¡o al menos mucho mas simple que un cambio de versión mayor¡¡)

El compromiso de la comunidad Dpsace es proporcionar parches de seguridad a las tres últimas versiones mayores de Dspace.  Es decir si , ahora al escribir esto, mayo de 2017, hay una vulnerabilidad  detectada y se corrige con un parche, se emitiría una actualización, denominándose 4.8 , 5.7 y 6.1 que son los siguientes numeros [minor] que hay disponibles…… Sin embargo, la comunidad de desarrollo DSpace solo nos comprometemos a parches funcionales para la versión última (aunque a veces se aprovecha para meter algún parche a versiones mayores anteriores….)

El soporte de ORCID en Dspace 5 (y superiores)

En el anuncio a finales de 2014 de la  versión 5, figuraba entre las funcionalidades destacadas el denominado “soporte ORCID”  (para interfaces XMLUI con mirage ó mirage 2), contribución de @tmire y de la Universidad de Missouri. Esta funcionalidad se definía como:

The current product will provide a means for realtime ORCID lookup during submission of an item. A subset of ORCID metadata will be retained in a local store.

Ampliando la escueta definición anterior, diríamos que DSpace  incorpora  la capacidad de enlazar un campo de metadatación, como  dc.contributor.*,  con una consulta (lookup)  sobre la base de datos de autores orcid.org.

clipboard01La implementación estándar de ese lookup, es decir lo incluido en Dspace v5,  normaliza el nombre del autor al valor del nombre de autor orcid, le asigna una clave interna de autoridad (un id de authority control que no tiene nada que ver con el orcid-id) y crea una entrada adicional en el nuevo núcleo SOLR  de caché de autoridades, ésta si, conteniendo el orcid_id.  Por ejemplo, la entrada del autor que se seleccionó en la pantalla anterior quedaría (en formato JSON) así:

{
"id": "53577e21-cd61-4e84-ae73-400c73a60d31",
"field": "dc_contributor_author",
"value": "Lorenzo, Antonio",
"deleted": false,
"creation_date": "2016-08-17T15:02:25.323Z",
"last_modified_date": "2016-08-17T15:02:25.323Z",
"authority_type":"orcid",
"first_name": "Antonio", "last_name": "Lorenzo",
"orcid_id": "0000-0002-5831-0808",
 }

Es decir, conseguirá en un primer paso normalizar nombres (bueno, quizá es bastante), pero el orcid-id  lo tiene por ahí oculto, dentro del SOLR  y poco mas podrá aprovechar de forma fácil ese proceso de consulta-desambigüación-normalización, teniendo que recurrir a extensiones sustanciales a Dspace si se quieren incluir integraciones adicionales usando la API de orcid, como sincronización de publicaciones, uso de la autenticación, etc…

La funcionalidad base es migrable hacia atrás para versiones 4, quizá para versiones 3, y para versiones JSPUI con algún trabajo y existe una implantación adicional para aquellos valientes que se atrevieron con el módulo  Dspace-CRIS.

Señalar que además hay funciones adicionales relacionadas con la importación-exportación batch de metadatos (BME)  y  que esta funcionalidad no cambia en la versión 6 (liberada hace nada) y no está prevista su ampliación para la versión 7 (¿enero 2018?)

Módulo Open Peer Review

Con el apoyo financiero de OpenAIRE, la organización Open Scholar ha coordinado un consorcio de 5 socios para desarrollar un módulo de Peer Review Abierto para revisar y evaluar trabajos albergados en repositorios institucionales basados en software DSpace

Open Peer review module
En este proyecto han participado:

  • DIGITAL.CSIC, el repositorio institucional del Consejo Superior de Investigaciones Científicas
  • e-IEO, repositorio del Instituto Español de Oceanografía
  • IIIA-CSIC, Instituto de Inteligencia Artificial del CSIC en Cataluña
  • SECABA, Multidisciplinary Laboratory of Library and Computer Sciences en Granada
  • Arvo Consultores

El proyecto ha sido financiado por OpenAIRE 2020, EU-Horizon2020 Grant ID 643410, y se acaba de presentar en el Jardín Botánico de Madrid, ante un numeroso grupo de responsables de repositorios institucionales e investigadores interesados en los nuevos paradigmas de revisión científica.

Señalar que iguamente se presentará en la conferencia Open Repositories 2016 de este año en Dublín.

El módulo Open Peer Review, OPRM, se puede instalar en repositorios institucionales Dspace existentes como un add-on. Los objetos digitales alojados de estos repositorios podrían entonces ser evaluados por un número ilimitado de evaludores, permitiéndo no sólo una evaluación cualitativa en forma de texto, sino también las medidas cuantitativas que serán utilizados para construir la reputación del objeto. Es importante destacar que este sistema de evaluación es abierto y transparente. Por abierto -open- queremos decir que el texto completo de las revisione está a disposición de los usuarios junto con el trabajo de investigación original. Por transparente se entiende que la identidad de los revisores se divulgará a los autores y al público. En nuestro modelo, la apertura y la transparencia son dos aspectos elementales que consideramos necesariao para abordar el problema de opiniones sesgadas o no expertas, que es inherente al modelo de revisión por pares anónimos, que se caracteriza por la falta de responsabilidad de los colaboradores.

El código del proyecto, así como sus indicaciones para la instalación,  puede encontrarse en https://github.com/arvoConsultores/Open-Peer-Review-Module/wiki

 

¿Por qué debiera interesarte la versión 6 de Dspace?

Hemos de decir que DSpace 6 es, principalmente, una versión de transición hacia la versión 7, esa esperada versión en la que sólo habrá una única interfaz de usuario. Por eso, para poder abordar una transición manejable a la V7, se ha tenido que re-escribir la mayor parte de la Java API de DSpace. Igualmente se ha mejorado el sistema de configuración, para evolucionar hacia un sistema más flexible y con capacidad de carga dinámica de las configuraciones.

Para dar una idea del esfuerzo tras este cambio, unas cifras del mismo:

      La refactorizacion de la Java API ha requerido cambiar 1,440 de los ficheros java de la apliciación DSpace.
      El Sistema Mejorado de Configuración (Enhanced Configuration System) modifica menos ficheros ¡solo 324¡¡¡ pero afecta a unas 6,000 líneas de código con el fin de lograr un sistema más flexible de configuración de Dspace.

Si a lo anterior el añadimos unos procesos de prueba de Dspace (los testhaton son una parte de este proceso…) mas intensos, pues tenemos unas cuantas buenas razones para el retraso que esta versión está sufriendo (de finales de 2015 a enero de 2016, luego al 8 de febrero y luego a una fecha indeterminada entre marzo y abril o mayo, quién sabe…)

Bien, y funcionalmente ¿qué ofrece la nueva versión?

  • Mejoras a los plugins de almacenamiento físico, incluyendo soporte para el almacenamiento Amazon S3
  • Chequeo del estado del repositorio, con informes al administrador via correo electrónico.
  • Panel de control administrativo ampliado
  • mejoras a la REST API con soporte a todos los métodos de autenticación,  Shibboleth, LDAP, etc
  • mejoras a XMLUI : importación de metadatos de fuentes externas como Pubmed y  ScienceDirect).
  • mejoras a XMLUI:  exportación de resultados de búsqueda a CSV

Posiblemente no encuentres muchas razones (funcionales) para  plantear una migración, excepto que tu versión actual sea realmente antigua y quieras recoger los frutos funcionalmente jugosos de las versiones 3, 4 y 5.

 

 

XXIII Asamblea Anual de Rebiun

Arvo participa como patrocinador en la XXIII Asamblea Anual de la Red de Bibliotecas Universitarias Españolas en la Universidad de Cantabria los días 5 y 6 de noviembre del 2014. La Asamblea Anual es el  foro nacional para planificar la organización, el funcionamiento y los objetivos de REBIUN

La Red de Bibliotecas Universitarias, está formada por las bibliotecas de las 76 universidades miembros de la Conferencia de Rectores de las Universidades Españolas (50 de ámbito universitario público y 26 de ámbito universitario privado) y el CSIC.  Sus objetivos son liderar, coordinar y dar las directrices a las bibliotecas universitarias para poder realizar proyectos conjuntos que den como respuesta nuevos retos en ámbito del aprendizaje, la docencia, la investigación y la formación.

Información detallada del evento en el siguiente enlacehttp://eventos.crue.org/event_detail/2133/detail/rebiun-2015.-xxiii-asamblea-anual-de-la-red-de-bibliotecas-universitarias.html

y puedes seguir el evento por Twitter con el hashtag 

y además en Youtube,  la conferencia inaugural  por  Ignasi Labastida, con el título “Los retos de la investigación en abierto para las universidades” en  esta dirección:  https://www.youtube.com/watch?v=sP7lB9R37Co

 

Expectativas de los usuarios sobre las búsquedas en DSpace

A pesar de los grandes avances que se han sucedido en las herramientas de búsqueda y recuperación de la información en los Repositorios DSpace (búsqueda facetada, Discovery, evolución del motor de búsqueda SOLR, etc), el excesivo número de registros recuperados tras una búsqueda, comúnmente conocido como “ruido”, continúa siendo, sin lugar a dudas, el principal problema de los usuarios. La necesidad de un cribado posterior desconcierta en muchos casos al usuario, por lo que el dilema está servido: ¿compensa descubrir tanta información?

Lo que el usuario de DSpace demanda del buscador, es que sea capaz de satisfacer su necesidad de información no sólo con la verosimilitud en los resultados ofrecidos, sino también con su pertinencia, logrando un equilibrio entre el descubrimiento de lo desconocido y la recuperación de lo realmente apropiado.

Por ejemplo, en un supuesto de búsqueda, entra dentro de lo verosímil que un usuario introduzca en el cajetín de búsqueda “frío” y recupere todos aquellos registros que contienen “frío” en el texto completo o en alguno de los metadatos configurados en los índices de búsqueda. Si, en su defecto, el sistema lanza una consulta con “frÄo”, los resultados presentarán un problema de verosimilitud.

La pertinencia, por su parte, ocupa la centralidad de las preocupaciones de los usuarios, asumiendo que la verosimilitud está más o menos acotada y ha sido eficazmente tratada con la configuración inicial del buscador (selección del analizador de búsqueda, stemmers, lematización, diacríticos, orden de los filtros de cribado, palabras vacías y un largo etcétera). El tratamiento de la pertinencia es un asunto que se puede atajar con las Ayudas DSpace, si bien han sido pocas las instituciones que se han molestado en aquilatar las ayudas que DSpace ofrece con una instalación estándar. Y probablemente ése sea uno de los principales problemas: los usuarios se encuentran con una herramienta de búsqueda poderosísima apenas explicada, al menos, en los términos que necesitan.

Por ello, cabe plantearse las siguientes preguntas: ¿tiene sentido cambiar el operador de búsqueda por defecto de DSpace cuando el usuario desconoce su funcionamiento efectivo? ¿Compensa configurar un mayor número de filtros si los usuarios desconocen cómo se pueden combinar para obtener un refinamiento de los resultados más preciso?

Afortunadamente, el perfil técnico de DSpace conoce el lenguaje, la sintaxis, y el modo de operar el código para lograr la verosimilitud de los resultados de las búsquedas, mientras que el perfil administrador sabe gestionarla y tiene la capacidad de comprenderla y traducirla para alcanzar la pertinencia. Conjugando adecuadamente ambos aspectos, se puede mejorar notablemente la satisfacción de los usuarios con el buscador de DSpace.

Derechos de acceso y permisos en DSpace (Parte 2)

En este post continuamos hablando sobre derechos de acceso y permisos en DSpace, y según lo prometido, vamos a abordar las principales demandas de los usuarios a este respecto. ¿Y cuáles son esas demandas?

De la misma forma que se entiende que la introducción de una fecha de embargo hace que el fichero adjunto quede no disponible para usuarios anónimos hasta dicha fecha, es evidente que al usuario le gustaría que al seleccionar las opciones “restrictedAccess” y “closedAccess”, los ficheros quedasen de forma automática como no disponibles para los usuarios sin permisos. Asimismo, lo ideal sería que en el caso de que el fichero volviese a estar disponible para cualquier usuario, bien sea por expiración del periodo de embargo o por un reintegro manual de permisos, el metadato de derechos de acceso cambiase automáticamente a la opción “openAccess”.

Open Access11

Si bien DSpace no tiene esas funcionalidades incluídas en su comportamiento o configuración, se pueden programar unas tareas de curación (curation tasks) para:

  • Detectar, a la hora de realizar un nuevo envío, los permisos que debe tener el fichero adjunto en función de la información introducida en el metadato de derechos de acceso (dc.rights.accessRights o similar), y ajustarlos según corresponda. Por defecto, cualquier usuario tiene acceso a los ficheros almacenados, por lo que la opción “openAccess” no exige ningún cambio en sus permisos. Si el publicador selecciona las opciones “restrictedAccess” y “closedAccess”, la curation retira indefinidamente los permisos a los ficheros adjuntos, ya que en estos dos casos no se dispone de una fecha de reintegro de permisos como en el caso del embargo temporal. Recordemos que en el caso de “embargoedAccess”, es necesario introducir una fecha de fin de embargo para que éste se active y desactive por sí solo, sin necesidad de ninguna tarea adicional. Si se selecciona esta opción, pero no se introduce fecha de fin de embargo, la curation lo entiende como un embargo indefinido y también retira permanentemente los permisos a los ficheros adjuntos.
  • Cambiar la información de derechos de acceso en función de los permisos del fichero adjunto. El caso más común es el cambio a “openAccess” cuando los ficheros vuelven a estar disponibles para cualquier usuario. Por ejemplo, si se introducen unos derechos de acceso con valor “embargoedAccess”, al llegar la fecha de fin de embargo este valor cambia automáticamente a “openAccess”. Lo mismo en el caso de que un administrador reintegre manualmente los permisos del fichero y se olvide de modificar la información descriptiva de derechos de acceso. Esta tarea resuelve aquellos casos en los que por descuido se ha almacenado el valor “openAccess” y se ha introducido una fecha de fin de embargo. Puesto que la información “openAccess” es meramente descriptiva, el fichero adjunto queda no disponible hasta que el embargo expire, por lo que la tarea detecta esta falta temporal de permisos, y cambia el valor “openAccess” por el valor “embargoedAccess”. Una vez el embargo expira, el valor de los derechos de acceso son corregidos de nuevo por “openAccess”.

Este tipo de tareas no sólo simplifican las labores de gestión de los administradores del repositorio sino que permiten mantener de manera automática una coherencia entre la información descriptiva proporcionada por los metadatos y los permisos de los ficheros adjuntos.

Derechos de acceso y permisos en DSpace (Parte 1)

La inclusión de información sobre derechos de acceso y su coherencia con los permisos reales de acceso a los ficheros, es un tema sobre el que los usuarios de DSpace suelen plantear preguntas con frecuencia, y al que dedicaremos este primer post sobre derechos de acceso y permisos en DSpace.

Habitualmente, a la hora de realizar un envío a DSpace, los publicadores rellenan la información sobre los derechos de acceso, puesto que es un dato exigido para la compatibilidad con determinadas Directrices como las Directrices OpenAIRE. Cuando los derechos de acceso son “openAccess”, no hay problema alguno, puesto que el fichero adjunto permanece disponible para cualquier usuario una vez el ítem es publicado en el repositorio. Sin embargo, en ocasiones los publicadores seleccionan las opciones “embargoedAccess”, “restrictedAccess” o “closedAccess”. Esta selección (igual para “openAccess”) se almacena en un metadato, normalmente el dc.rights.accessRights, que por sí mismo no modifica los permisos de acceso al fichero asociado al ítem, ya que simplemente es un metadato descriptivo. Por eso, cuando un usuario selecciona una de esas opciones puede pensar que está modificando los derechos de acceso al fichero adjunto, cuando en realidad solamente está enriqueciendo la descripción de su publicación.

Cuando el sistema de embargos está activo y configurado en DSpace, es necesario introducir la fecha de fin de embargo en el lugar correspondiente (en la pantalla de descripción o en la pantalla de subir fichero, dependiendo de la versión de la herramienta), para que el fichero adjunto se quede embargado hasta dicha fecha. Esto es imprescindible, puesto que la introducción de “embargoedAccess” en el metadato dc.rights.accessRights no cambia por sí sola los permisos de acceso al fichero, tal y como se indica en el párrafo anterior. Ésta es, por defecto, la única manera que el usuario tiene, durante el proceso de envío, para influir en los permisos de los ficheros adjuntos, y puede utilizarla también para la retirada de permisos cuando selecciona otras opciones como “restrictedAccess” o “closedAccess” en el campo de derechos de acceso. Una vez el ítem es publicado, solamente los usuarios con permisos de administración pueden retirar manualmente los permisos de su fichero adjunto, no pudiendo hacerlo el propio publicador.

Otra cuestión que se plantean los usuarios es qué sucede con la información almacenada en el metadato de derechos de acceso cuando los permisos de los ficheros adjuntos cambian. Pues bien, por defecto, esta información no cambia automáticamente. Es decir, un dc.rights.accessRights con valor p.ej. “embargoedAccess”, no cambia automáticamente a “openAccess” cuando el embargo llega a su fin. Esta labor suele ser realizada de forma manual por un usuario con permisos de administración.

En el siguiente post hablaremos de cuáles son las principales demandas de los usuarios a este respecto y analizaremos las posibles soluciones.