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

Author Archives: cfernandez

Nos adaptamos al RGPD

No queremos ser menos que todas las webs que se están actualizando con nuevas políticas de privacidad. Por eso te explicamos de la manera más simple cómo y para qué usamos tus datos.

Hemos creado una página en que te contamos qué datos obtenemos cuando navegas por nuestro blog y para qué usamos esos datos. Usamos las cookies míinimas para saber cuantas visitas hemos tenido, cómo evolluciona la web, o desde qué sitio nos leeis, ni más ni menos.  Tambien te explicamos cómo controlar la información que esas cookies recogen. Tu decisión cuenta en cómo se usa la web y que datos se recogen.

Igualmente, como indica el RGPD, te informamos en esta página de cuáles son tus derechos en lo relativo a tus datos personales, y cómo ejercitarlos

Te recomendamos que te tomes uno minutos y leas en esas dos páginas la información sobre las políticas de privacidad y las políticas de cookies.

¿y si empezamos a adaptar los repositorios a OpenAIRE 4 ?

OpenAIRE publicó en noviembre de 2017 para su consulta pública antes de su aplicación efectiva, las especificaciones OpenAIRE 4 para repositorios de publicaciones, OpenAIRE 4 Guidelines for Literature Repository Managers.

Esta nueva recomendación OpenAIRE, a fecha de escribir esto, aún con estatus de borrador, tiene dos objetivos principales, orientados a mejorar la calidad de la medida, control y seguimiento de los resultados de investigación: conectar correctamente los autores con su producción científica, y enlazar la información de financiación con esa producción.

Para lograr esta interoperabilidad, que de eso trata OpenAIRE, se propone un nuevo perfil de aplicación para la exposición OAI-PMH basado en Dublin Core y DataCite.

De interés en este perfil tenemos elementos ampliados de metadatación de autoría, recomendándose la inclusión de identificadores ISNI u ORCID.

<datacite:creator> 
<datacite:creatorName>Wallentin, Carl‐Johan 
</datacite:creatorName>
 <datacite:nameIdentifier 
 nameIdentifierScheme="ORCID" 
 schemeURI=“http://orcid.org"> 
 http://orcid.org/0000-0003-1983-9378 
</datacite:nameIdentifier> 
</datacite:creator>

Igualmente para la identificación de proyectos y agencias financiadoras se incorporan nuevos elementos de metadatación, fundingReference.

 <datacite:fundingReference>
 <datacite:funderName>European Commission</datacite:funderName> 
<fundingStream>H2020 Marie Skłodowska-Curie Actions</fundingStream> <datacite:funderIdentifier 
funderIdentifierType="Crossref Funder ID"> 
</datacite:funderIdentifier> 
<datacite:awardNumber>
awardURI="http://cordis.europa.eu/project/rcn/195983_en.html">660668 
</datacite:awardNumber> 
 <datacite:awardTitle>ACT against AMR</datacite:awardTitle>
</datacite:fundingReference>

No menos importante son los cambios de sintaxis de los metadatos de tipología, con inclusión de vocabularios COAR, versionados, etc..

¿Y en qué afecta a los repositorios? 

Básicamente la inclusión de ORCID, realizada ya por un número considerable de repositorios institucionales, deberá ir pareja a la adaptación del interfaz OAI-PMH al nuevo esquema de recolección oaire.  En un reciente proyecto piloto para la FECYT, hemos realizado una primera adaptación de un repositorio institucional  para esa exposición OAI-PMH. Os informaremos próximamente de este proyecto, señalando además que el código es de uso público.

Igualmente los repositorios deberán capturar información (mas) precisa sobre los proyectos y la financiación de la que se derivan los resultados de investigación. Deseamos la aparición de servicios de consulta (APIs públicas) para facilitar esta tarea a los repositorios.

¡ Una nueva etapa para el ecosistema de repositorios y recolectadores con OpenAIRE4 !

 

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.

Nueva versión del módulo de publicación en twitter.

A diferencia de las integraciones con capacidades 2.0 del tipo “add-this” disponibles hace tiempo en muchos repositorios, este módulo incluye la integracíón fuerte con la API de Twitter. Recientemente hemos actualizado la versión de este módulo, ahora en su versión 2.3 para permitir la publicación en diferentes perfiles twitter dependiendo de la colección de archivo, asi como para aprovechar la máximo la extensión a 280 caracteres introducida por Twitter.

El conector Twitter permite publicar en el perfil de twitter de un repositorio o una biblioteca los envíos publicados en el repositorio. La publicación se realiza en la última fase del proceso de ingesta o en fases posteriores, pues es posible re-postear un ítem cualquiera a selección del administrador, útil para destacar en cualquier momento ítems ya archivados y que pueda interesar su redifusión.

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

Jornadas Ecosistemas del Conocimiento Abierto, ECA2017

Se celebraron del 25 al 27 de octubre de 2017 en Salamanca, las jornadas Ecosistemas del Conocimiento Abierto ECA2017,  que  incluyeron el 16º Workshop de REBIUN de Proyectos Digitales, las 7as Jornadas OS-Repositorios, y el 11º Coloquio Internacional de Ciencias de la Documentación.

Nuestra valoración es positiva, ya que no abundan los puntos de encuentro para especialistas en acceso abierto, experiencias desarrolladas en repositorios y resto de tendencias innovadoras en el conocimiento abierto. ECA2017 ha demostrado la pujanza de nuestro sector y actividad.

La organización tuvo la gentileza de invitarnos a presentar nuestra ideas en la mesa de debate ‘Los Repositorios del futuro’ junto con  Francisco García Peñalvo (USAL), Ignasi Labastida (CRAI, UB),Catalina Guzmán (UCO) y Belén Fernández del Pino (UC3M, Madroño, COAR) en una mesa moderada por Leticia Barrionuevo (ULE). Como el lema del congreso era «Ecosistemas…» pues nos lanzamos a hablar del papel futuro de los repositorios en el ecosistema, y he de reconocer, que salió algo extraña la charla.

Acá va el texto leído en la mesa:

«En primer lugar, gracias por invitarme a esta mesa de debate y gracias a los asistentes …..

Hablemos de ecosistemas. Estamos mas o menos de acuerdo que el lugar de la especie RI en el ecosistema es capturar preservar y difundir el conocimiento, …..empecemos pues la predicción…

Por una parte, se requerirá cambiar los modos que usan los repositorios para capturar y tener contenidos completos, reflejando la totalidad de la producción científica-investigadora de las instituciones. Hablando en términos de ecosistemas, pienso que las relaciones de simbiosis serán  evidentes, asumiendo los repositorios papeles de simbiosis parasitaria- entendamos el término parásito en su acepción biológica y no en su acepción peyorativa- Y siguiendo con la analogía, veremos a los repositorios actuando como huéspedes y/o hospedadores en una suerte de mutualismo parasitario con otros sistemas…..

Observaremos incluso relaciones de hiperparasitismo (parásitos que parasitan a otros parásitos) entre los integrantes del ecosistema. Ayer, la Politécnica de Barcelona nos presentaba un modelo de hiperparasitismo mutuo, la simbiosis máxima, en que OpenAire les parasitaba, recolectando su contenido y ellos parasitaban a OpenAire, enriqueciendo el contenido de UPCommons con la información de este otro sistema.

Siguiendo con las tendencias que pensamos que se afianzarán en el futuro cercano, veremos repositorios siendo alimentados automágicamente (o casi) por otras especies ya existentes en el ecosistema  (crossref, pubmed, orcid, elsevier,  openAire….)

Y por otra parte asistiremos a la aparición de repositorios con variaciones genéticas en el sistema de auto-depósito, que tornará a ser un sistema ligero y posiblemente dotado de «inteligencia», con el fin de que el depósito no se convierta en una traba adicional para los investigadores, básicamente intentando que el investigador no se percate que le parasitamos….

Claramente visionamos a los repositorios del futuro ocupando nichos ecológicos de otras especies … y viceversa…en una suerte de ocupación de hábitats ajenos.. Pensamos que vamos a asistir en un cambio de la especie «repositorio» que evolucionará desde su foco adaptado a la producción científica, centrados en el objeto o en la colección, y que se reorientarán, este cambio se denomina plasticidad fenotípica, hacia una centralidad en el autor. Los autores tienen que adquirir una importancia que hasta ahora no parecen tener en los repositorios,… y esto pasa por: «Cuidar al autor» por ejemplo con los sistemas de depósito simplificados que comentábamos antes y «Mimar al autor» ofreciéndoles servicios de información (estadísticas de autor, altmetrías, servicios de suscripción inteligentes o avanzados, etc..)

Incorporarán igualmente capacidades de descripción y gestión de entidades adicionales (autor, departamento, institución, etc), unas veces en competencia, es decir siendo depredadores, por el espacio natural de los sistemas CRIS de carácter más básico y otras veces en simbiosis con los CRIS más avanzados. Esperemos no ver a los repositorios como presas en el ecosistema, pero esta conjetura no la puedo avalar.

Y por último, finalizar con una consideración sobre los objetos digitales almacenados…algunos repositorios mutarán para poder gestionar o manejar objetos de investigación complejos, multipartes, con contexto, etc….. a la par que cambiará el fenotipo de los repositorios para incluir extensiones de los contenidos como anotaciones, comentarios, peer review, etc

Bien,… la bola de cristal ya no da mas de sí,… muchas gracias por su atención.

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

DSpace versión 6

Bien, la versión 6 ya está aquí, se anunció su disponibilidad el 24 de octubre y ya está lista para ser instalada…

¿y qué nos trae de nuevo la versión 6? Pues unas cuantas funcionalidades y cambios:

  • Incorporación de Hibernate, herramienta de mapeo objeto-relacional, paso necesario para poder abordad la refactorización de la API de Dspace (estamos pensando en la versión 7). Si teníais código propio que accedía a la base de datos de Dspace, posiblemente tengas que reescribirlo…
  • Se mejora el sistema de configuración de Dspace, que ahora usa la sintaxis de Apache Commons Configurations. Las configuraciones de dspace.cfg pueden recargarse sin rearrancar el Tomcat, el fichero de configuración build.properties se ha cambiado por un local.cfg  y algunas mejoras más. Algunas mejoras, pero al ser un nuevo sistema pues hay que volver a aprender la forma de hacer despliegues…
  • Se ha retirado el soporte al sistema de acceso al almacenamiento (assetstore) basado en SRB (no habia constancia de que lo usasen muchas instalaciones). Para compensar, se ha añadido soporte al sistema Amazon S3.
  • Ya no se distribuye la interfaz LNI (poco o nulo uso).  Quedará no obstante como «add-on»
  • El motor de búsqueda basado en Lucene y los métodos de browse basados en base de datos desaparecen por completo del código (deprecated, en terminología de desarrollo de software). Ya se desaconsejaba su uso en la v4, si querías usarlo daba muchísimos problemas en la V5 y se ha finalizado eliminando estos elementos de código.
  • Tenemos unos nuevos informes, denominados Healthcheck (chequeo de salud) que revisan una serie de parámetros del repositorio y pueden enviar esos informes al administrador, por correo electrónico. Nos parece un avance sobre las posibilidades de comprobación existentes en versiones anteriores.
  • Es posible exportar los resultados de una búsqueda a CSV  (en XMLUI)
  • Hay un panel de control administrativo ampliado y configurable, las opciones del control panel, crecen y crecen….
  • Se anuncia el framework de importación de metadatos (aclaremos que realmente estaba  ya funcionando e incluso documentado extensamente en la versión 5) pero parece que hacen ahora el anuncio oficial. Será porque se aprovecha este framework para posibilitar la importación de metadataciones desde Pubmed, CrossRef, ScienceDirect, que insistimos, ya se podía hacer en la versión anterior….
  • La interface REST admite los mismos métodos de autenticación que las UI (hasta ahora solo se soportaba el login-password). Parece lógico, ¿verdad? sobre todo desde que se plantea para la próxima versión desagregar DSpace de las interfaces de usuario…
  • Aparece un sistema de chequeo de metadatos (REST metadata quality control) que permite interrogar via la interface REST sobre los valores de metadatos que tenemos en nuestros ítems..¡¡¡ muy curioso el funcionamiento !!! recomendable….
  • El operador de búsqueda de Discovery pasa a ser AND (el OR causaba más preguntas de la cuenta, pero realmente el cambio es mínimo, unas lineas en un fichero de configuración)
  • Se posibilita el indexado de documentos que se escriben de derecha a izquierda (RTL), como el árabe o el hebreo.
  • Se actualiza a PDfbox 2.0 y se incluye un nuevo generador de miniaturas de PDF (por lo que ya no es necesario el xpdf)

y seguro que me dejo algo….