Warning: Constant WP_MEMORY_LIMIT already defined in /home/elorenzo/domains/arvo.es/public_html/dspace/wp-config.php on line 94
version 5 | Hablando de DSpace

Archivos de Tags: version 5

API de ORCID V1 y V2, acceso público

Creemos que son interesantes para los repositorios DSpace los servicios de integración que ofrece ORCID a través de su API (Application Programming Interface). La API, en su versión actual v2.0, ofrece un serie de funcionalidades que permiten a los repositorios (y otros sistemas) interactuar con ORCID.

  1. Obtener el ORCID iD
  2. Leer/recuperar datos públicos (ORCID iDs y datos autorizados por los autores)
  3. Leer/recuperar datos privados (Si los autores han concedido autorización al que accede)
  4. Notificaciones de actualización del perfil (webhooks)
  5. Notificaciones cuando ocurren cambios en los ORCID iDs que se monitorean
  6. Añadir y actualizar datos de registros ORCID
  7. Creación de nuevos registros ORCID

Sólo algunas funciones API (1 y 2) son de libre uso, la denominada API-pública, mientras que el resto están restringidas al uso por aquellas organizaciones que contribuyen a la financiación de ORCID con una cuota anual (membresía básica y premium)

 

DSpace tiene incluidas desde el año 2014, con el lanzamiento de la versión 5, algunas capacidades de integración con ORCID usando la API-Pública, que se constuyeron por Atmire en el contexto de un proyecto con la Universidad de Missouri. La funcionalidad construida permite la  consulta de identificadores correspondientes a los nombres de autor, y tras la validación,  la incorporación del identificador y otros datos del registro ORCID a DSpace. Como aspecto importante de esta integración, se realizó con la API disponible en ese momento, V1. Lamentablemente esa versión de API ha sido retirada (deprecated) y mas lamentable aún, la V2 no ha mantenido la compatibilidad con los modos de recuperación de información de la versión anterior.

Just an FYI that ORCID.org has finally deprecated the v1 API that DSpace was using to look up authors. Their mailing list announcement[0] says that as of February 1, 2018 the default API version for calls to pub.orcid.org will become v2, and that v1 will move to a new URL until March 1, 2018, but this appears to be broken currently

Los usuarios del lookup de autoridades en este momento ya no pueden validar contra ORCID, en tanto no se desarrolla y prueba el acceso a la versión 2 de la API. El impacto es bastante limitado, pues la mayoría de repositorios con ORCID iDs no validaban directamente contra la bbdd de ORCID, sino únicamente contra la bbdd de autoridades del propio repositorio, no afectando en principio a las operativas de validación de autoridades.

Os mantendremos al corriente de los avances en los desarrollos de la nueva integración de DSpace con la API v2.

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?)

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

 

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)