Agenda formativa DSpace, segundo semestre de 2018

Programamos para su impartición en el segundo semestre de este año una nueva edición de los cursos siguientes:

Cursos DSpace V6

  • Dspace v6 para Administradores, 24 de Septiembre al 4 de Noviembre de 2018, (+ información)
  • Dspace v6 para Administradores Técnicos, 24 de Septiembre al 4 de Noviembre de 2018, (+ información)

 

 

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.

Preservación e integridad de ficheros en DSpace

La preservación y la integridad de los ficheros almacenados en un sistema Dspace preocupan con frecuencia, y con razón, a los gestores de los repositorios. Intentaremos despejar las dudas más frecuentes sobre el comportamiento del software DSpace al respecto.

Una función hash es, básicamente, un algoritmo criptográfico que aplicado a un fichero produce como resultado una cadena alfanumérica única, permitiendo determinar, por comparación con valores anteriores de la cadena,  los cambios en el mismo, la integridad del fichero. DSpace realiza el  cálculo del valor hash de cada fichero almacenado en el sistema, incluidos los ficheros de licencia, etc.. Cuando se sube un fichero (en los cambios de estado submitted, approved y made available), se calcula automáticamente su valor hash, almacenándose en la tabla de bitstreams:

arvo.pdf   checksum: d4c4979a5f4f34f6158a2620f0d5710c (MD5)

license_rdf   checksum: 603b6a1a20b0b67b338ea745cbacb74f (MD5)

¿Y qué sucede entonces ante la modificación de un fichero? Para responder a esta pregunta, en primer lugar debemos aclarar que en DSpace un fichero en realidad no se modifica, sino que se sustituye por otro diferente (borrándose el antiguo o versionándolo) calculándose automáticamente el hash del nuevo fichero y generándose una nueva entrada en la tabla de bitstreams. Con este proceso se asegura que la integridad de cada fichero queda reflejada en la tabla bitstreams.

Parte de esta información se graba adicionalmente en el metadato dc.description.provenance. Importante tener en cuenta que este metadato sólo se graba en la subida inicial del fichero, no en las acciones de borrado o sustitución de fichero que pudieran ser realizadas posteriormente por un administrador.

dc.description.provenance Submitted by xxxxxx  (name@mail.com) on 2008-02-11T11:46:16Z No. of bitstreams: 1 RSCAS_DL_2005.pdf: 185727 bytes, checksum: 4d46d9280e930bf6a024f6d39f3a74bb (MD5)

Existe además el comando checker  (cuya ejecución se programa normalmente a intervalos regulares mediante crons) que permite comprobar que los hash de los ficheros no han cambiado y cuyo resultado y fecha de ejecución se almacenan en la tabla ckecksum_history:

[dspace]/bin/dspace checker

Adicionalmente, podríamos reseñar que en los logs de DSpace se registran las acciones realizadas sobre los bitstreams (añadir nuevos y borrar los existentes) y los usuarios que las han realizado. Pero hay que señalar que interpretar los logs directamente es una tarea bastante ardua que requiere del análisis de ingentes cantidades de datos sobre la historia/logs del repositorio. Una vía que no nos atreveríamos a recomendar.

En caso de detectarse la alteración o algún problema con un fichero, se deberá recurrir a un backup del assetstore  (o mas infrecuentemente, backups AIP).  Este no es un proceso de DSpace propiamente dicho, sino de las políticas de recuperación de cada repositorio. Cada repositorio deberá plantearse los modos y medios de recuperación de la información ante eventuales pérdidas.

Finalmente, señalar que DSpace no comprueba la existencia de virus en los ficheros de forma estándar, pero mediante la implantación de módulos específicos es posible analizar los ficheros del repositorio en busca de virus, avisando a publicadores y administradores de potenciales riesgos en sus ficheros y eventualmente restringiendo el archivo de los mismos.

¿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….)