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

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

 

El soporte del estándar METS en DSpace

El estándar METS, Metadata Encoding and Transmission Standard, es una especificación XML que especifica los metadatos necesarios para la gestión de objetos digitales en un contexto digital así como para el intercambio entre sistemas de dichos objetos. METS se crea y diseña para proporcionar un formato relativamente simple de descripción de las actividades realizadas durante el ciclo de vida de un objeto digital.

Adicionalmente a la metadatación descriptiva interna, realizada habitualmente en Dublin Core Cualificado, el software Dspace incluye entre sus funcionalidades lo que se denomina un package disseminator and matching ingester adecuado para el tratamiento de determinados documentos METS.  La finalidad de este elemento es ayudar a los usuarios en la ingesta y exposición de los objetos DSpace usando el estándar METS.

DSpace tiene definidas pasarelas en formatos METS que usan el perfil de aplicación denominado, DspaceMETSSIPProfile,  en el que se han tomado las siguientes decisiones de diseño relevantes:

  • Los elementos de metadatación descriptiva se contemplan bajo un esquema MODS (Metadata Object Description Schema) aunque el formato METS acepta el encapsulado (wrapping) de otros esquemas, incluso coexistiendo en una única declaración.
  • Los elementos de metadatos técnicos que DSpace tiene definidos, sirven para sus propias necesidades de gestión del ciclo de vida y preservación de los objetos almacenados, lo que significa que no se contemplen objetos, eventos u agentes fuera de esas necesidades de gestión propias.  Mediante mapeo del  DSpace Content Object Model al modelo de objeto METS estos elementos se expresan usando el esquema de metadatos de preservación PREMIS. Es importante notar que el uso del PREMIS Data Dictionary no significa que DSpace soporte una implementación completa del modelo de datos PREMIS (p.ej. no usa las entidades de tipo evento)
  • Entre los elementos de metadatación administrativa, los correspondientes  derechos y autorías, si éstos son explícitos, se referencian, p.ej.  las licencias CC como rdf/xml, e incluyen en el manifiesto xml

Los creadores de este perfil METS, siguiendo criterios de simplicidad en la transferencia de información en los formatos SIP/DIP,  eran plenamente conscientes de la sobre-simplificación del mismo para una descripción completa de los AIPs:

Future use of this profile, or related profiles, to govern the creation of Archive Information Packages (AIPs) will require the inclusion of additional information to account for the larger information needs of AIPs.

Estas pasarelas o transformaciones se emplean en los siguientes ámbitos
Ingesta

  • El soporte de formatos empaquetados METS (conformes al perfil apuntado) está incluido en la herramienta de importación denominado packager
  • La interface SWORD también está adaptada para la ingesta de paquetes METS, haciendo uso del perfil especificado, mediante el plugin SWORDMETSIngester

Difusión:

  • El soporte de formatos empaquetados METS está incluido en la herramienta de exportación del packager
  • OAI-PMH, con metadataFormat METS
  • además, se expone en el interface XMLUI   (p.ej. añadiendo a la url de un item el /mets.xml)

Estas transformaciones exponen nada más que una historia parcial del ítem, no recogiendo todo el ciclo de vida de nuestro objeto digital, por otra parte desconocido para DSpace, ya que DspaceMETSSIPProfile es un perfil con objetivos diferentes de los requeridos habitualmente en los proyectos de digitalización como p.e.j:

  • Library of Congress METS Profile for Bibliographic Records
  • METS profile Biblioteca Virtual Patrimonio Bibliográfico del Ministerio de Educación y Cultura
  • METS Profile for Historical Newspapers (no registrado aú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.

DSpace en las Universidades españolas

Aprovechando el estudio que hicimos para el XIV Workshop Rebiun de Proyectos Digitales / VI Jornadas OS-Repositorios: Los horizontes de los Repositorios que se acaba de celebrar en Córdoba este mes de marzo, Estudio de la integración de repositorios en el sistema científico-investigador: alternativas y estado actual, pudimos extraer datos referentes al software de implementación y otros datos de caracterización de los repositorios institucionales.

Metodología Usada

Revisamos en la última semana de febrero de 2015 la lista de repositorios institucionales de REBIUN.   Indiquemos que REBIUN, Red de Bibliotecas Universitarias, incluye las bibliotecas de las universidades españolas (mas el Consejo Superior de Investigaciones Cientíificas), es decir un total de 74 instituciones.  Se inspeccionó la solución de software de los repositorios institucionales declarados en dicha lista, sobre la url reportada,  y en el caso de repositorios con software Dspace, además se anotó la interface (JSPUI ó XMLUI ) y cuando fue posible, la información de la versión.

Resultados

De las 74 instituciones, 58 tienen repositorio institucional, y como se ve en la figura siguiente, el software DSpace, con 49 instalaciones, es indudablemente el más usado en la construcción de repositorios, con una presencia baja  de otros sistemas: Invenio, Fedora, e-Prints, Greenstone…..

Software usado en repositorios institucionales REBIUN

Software usado en repositorios institucionales REBIUN

 

De estos 49 repositorios Dspace, el 51% tienen versiones “antiguas”, incluyendo 1.8, 1.7, 1.6 o etiquetadas desconocida”  (indicativo de versión 1.6 o anterior, en que no se declaraba la versión Dspace en los metatags de la homepage).  En cualquier caso,  una cifra del 49% de instalaciones con versiones actualizadas (versiones 3 y 4),  es una cifra en línea con la reportada del 40% que tenía el escenario más amplio, 1100 instalaciones Dspace,  analizado por @atmire en diciembre de 2013.

Versiones e interfaces Dspace/ REBIUN

Versiones e Interfaces Dspace en repositorios REBIUN

 

El 59% de las instalaciones tienen el interfaz XMLUI. aunque si consideramos solamente las instalaciones con versiones más actualizadas (v3, v4 o la ausente 5) contabilizan el 75% de las mismas. Una indicación posiblemente de cómo este interfaz está gradualmente ganado popularidad entre los gestores de repositorios universitarios.

Igualmente recordar que desde comienzos de este año 2015 se ha “discontinuado” el soporte para las versiones 1.8 y anteriores por lo que sería de importancia el que estas instalaciones considerasen la migración de sus repositorios.

 

Liberada la versión 5 de DSpace

El 21 de enero de 2015 se produjo la liberación de Dspace v5.0, tras un proceso de desarrollo que arrancó hace un año, y que tuvo su pre-versión el pasado 3 de noviembre cuando comenzó el Testhaton.

Señalaríamos que incorpora una larga lista de pequeñas correcciones, pero que su característica principal son las funcionalidades añadidas (por eso es una versión, claro..) y que pasamos a revisar rápidamente:

El tema Mirage2 para XMLUI.  Bien, qué quéreis que os digamos, no es exactamente una novedad, pero es una excleente noticia su incorporación a la versión 5. El tema Mirage2 de @tmire nos gustó según lo vimos en su presentación “oficial” en el Open Repositories de Helsinki en junio de 2014. Tanto nos sedujo que lo empezamos a implantar en versiones 4 de inmediato y ya llevamos varias.

Actualización automática de datos en las migraciones a la versión 5. Simplifica la ejecución de los scripts de actualización de los esquemas de BBDD y migra los índices SOLR.  Es un avance sobre el ¿proceso? artesanal actual de migración. No se si lo pondríamos en una lista de nuestras prioridades, pero bienvenida la simplificación.

Importación de SIPs desde el interface de usuario. Pschee, la parte más compleja de una importación no es la ejecución del comando desde la UI o desde el CLI, sino la propia creación del paquete.

REST API con CRUD (Create/Read/Update/Delete). Esto ya está mejor, sobre todo porque estabilizará  el paisaje de proliferación de interfaces REST que había por el universo DSPaciero. Recordemos que aunque otras interfaces REST (la de Hedtek, p.ej.)  ya posibilitaban el Create/read/update,  lo que se necesitaba , y así se discutió en DCAT y otros foros de desarrollo, era la continuidad de las soluciones adoptadas. La api usada es la JAX-RS: Java API for RESTful Web Services.

Todos los DSpaceObjects con soporte de metadatos. Esto es interesante. Esta extensión es la que posibilitará (posibilitará, porque la interface de usuario aún no se ha extendido para poder gestionar el nuevo modelo)  flexibilizar la infraestructura de metadatos, que hasta ahora era aplicable sólo a los ítems, a las Comunidades, colecciones, e-persons, grupos, …

Soporte Linked (Open) Data mediante una interface RDF. A partir de esta versión se podrán publicar contenidos del repositorio en forma de Linked Open Data. No obstante, no todo es tan sencillo, pues la instalación de Dspace hay que complementarla con otra webapp, un Triple Store, es decir una base de datos que almacene de forma nativa el modelo RDF. El sistema, puede servir Apache Fuseki, debe soportar SPARQL 1.1 Query Language y  SPARQL 1.1 Graph Store HTTP Protocol.

Las estadisticas de Google Analytics ahora recogen las descargas de bitstreams (p.ej, las que vienen directamente de Google Scholar y que antes no se recogían como eventos) y se pueden visualizar (al menos si se usa Mirage2)

Se ha realizado una primera integración con los identificadores ORCID mediante la generación de un nuevo índice SOLR de autoridades. La clave de autoridad enlaza ahora con metadatos adicionales, entre los que se incluyen el identificador ORCID y nombres alternativos de autor. Esto sólo funciona en XMLUI, y bien, resuelve problemas de identificación de autores a las organizaciones que usan este identificador, pero no es la integración con las ORCID_API que estábamos esperando.

Y más mejoras, como la Creación de Thumbnails con ImageMagick / Ghostscript; la Autogeneración de páginas de cubierta PDF en la descarga de los objetos, la función lookup sobre SHERPA/RoMEO y alguna funcionalidad adicional, las puedes ver aquí.