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

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 enlace:  http://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  #REBIUN2015

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

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.

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».

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.

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.