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

Agenda formativa DSpace, primer semestre de 2020

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

Cursos DSpace V6

  • Dspace v6 para Administradores, 20 de abril al 7 de junio de 2020, (+ información)
  • Dspace v6 para Administradores Técnicos, 20 de abril al 7 de junio de 2020 , (+ información)

Módulo de Visualización Avanzada de documentos

El módulo de visualización que implantamos integra un visualizador rico de documentos para formatos pdf, específicamente adaptado a revistas u otras publicaciones impresas de gran calidad.

El visualizador proporciona un experiencia vívida y realística de la lectura de los documentos almacenados. El módulo visor incorpora la licencia de uso del producto comercial Flexpaper/Flowpaper.

El motor de conversión convierte los pdfs en formatos susceptibles de visualización HTML5, lo que ayuda a alcanzar el máximo de dispositivos de lectura y por consiguiente de audiencia.

Los sistemas de archivo y visualización de DSpace son adaptados para minimizar el impacto en la operativa del repositorio y en los tiempos de respuesta durante la visualización. Igualmente se pueden modificar dichos sistemas para para visualizar ficheros de imagen (jpg, tiff), o de documentos ofimaticos (docx, rtf).

El sistema es configurable para poder restringir la descarga e impresión de los contenidos, en repositorios con características especiales de restricción de los contenidos.

Además presenta las siguientes características opcionales:

  • Zoom&Pan
  • Cambio de visualización una-multipágina
  • Búsqueda a texto completo en el documento visionado
  • Modo pasa-página
  • Modo impresión habilitado/deshabilitado
  • Modo descarga de documentos habilitado/deshabilitado

Adaptando a OpenAIRE 4 (IX). Creando un nuevo esquema de aplicación

Nota: hacemos un salto en nuestra explicación de «diez pasos» para responder específicamente una consulta que nos han hecho. Seguiremos con el resto de pasos en breve.

El perfil de aplicación oai_oaire usado en openAIRE 4 contiene una mezcla de elementos provenientes de dublin core, dcterms, datacite y oaire.

  • dc: http://purl.org/dc/elements/1.1/
  • dcterms: http://purl.org/dc/terms/
  • datacite: http://datacite.org/schema/kernel-4
  • oaire: http://namespace.openaire.eu/schema/oaire/

Recordemos que desde la inclusión de las librerías XOAI en la versión 3 de DSpace, ha aumentado la flexibilidad y facilidad de creación de nuevos perfiles de aplicación, pudiéndose crear nuevos perfiles (también referidos como metadata formats, aunque no son lo mismo) especificando una transformación XSLT creada ex profeso.

Cualquier elemento de metadatos de DSpace, por lo general, se puede potencialmente transformar en otro, modificando una hoja de estilo específica. Son buenas noticias, porque eso significa que ante nuevos requisitos de recolección, por lo general NO hay necesidad de alterar la metadatación en origen, tremendo dolor de cabeza para cualquier responsable de repositorio.

Un ejemplo sencillo, por ejemplo, corresponde a la exposición dc.title, que seguro tenemos en nuestro en el elemento correspondiente del esquema oai_oaire :


La transformación anterior se logra con una XSLT que contenga una sección similar a la siguiente

Las XSLT se loacalizan en el directorio [dspace]/config/crosswalks/oai/metadataFormats. Después de crear la nueva XSLT deberás añadir la información del nuevo entorno de aplicación dentro del elemento <Formats> de [dspace]/config/crosswalks/oai/xoai.xml

Todo esto sirve para ensamblar en el nuevo perfil de aplicación, oai_openaire, que será invocado mediante el parámetro OAI metadataPrefix

http://rabida.uhu.es/oai/openaire4?verb=ListRecords&metadataPrefix=oai_openaire

El por qué usamos en la url de recolección el apéndice /openaire4? en vez del /request?, lo explicaremos el día que hablemos de los contextos OAI…

Nota para nuestros lectores hispanoamericanos: LA Referencia forma parte de la Confederación de Repositorios de Acceso Abierto (COAR) y a través de RedCLARA colaboran con OpenAIRE, lo que es una noticia excelente, pues los lienamientos de ambas redes de repositorios son así equivalentes.

Y así, cuando decimos OpenAIRE Guidelines for Literature Repository Managers v4 , nos referimos también p.ej, en el caso colombiano, a las Directrices para repositorios institucionales de investigación de la Red Colombiana de Información Científica (RedCol) 2020 o para México, las directrices de REMERI, etc…

Adaptando a OpenAIRE 4 (III). Vocabularios COAR de versionado

En el perfil de aplicación de OpenAIRE 4, el elemento oaire:version es un elemento recomendado, y dependiendo de la tipología del recurso, esta propiedad se usa para indicar, bien el número de versión de un software o dataset, bien el estado de publicación de un artículo. Hablemos de este segundo caso…

El elemento oaire:version debe seguir los formatos definidos por el vocabulario controlado COAR Version Types

AOAuthor´s OriginalVersión original del autor, borrador, manuscrito
SMUR Submitted Manuscript Under ReviewVersión sometida a revisión, versión enviada a revisión, versión enviada a revisión por pares, versión enviada al editor
AMAccepted ManuscriptVersión aceptada para publicar, Postprint, Manuscrito aceptado
P ProofPrueba de galera, manuscrito editado, manuscrito aceptado
VoRVersion of RecordVersión publicada, Versión final del editor
CVoRCorrected Version of RecordVersión corregida, Versión publicada corregida
EVoREnhanced Version of RecordVersión mejorada
NA Not Applicable (or unknown)Versión desconocida

Pregúntese si su repositorio dispone de esta información de versionado. La realidad es que muy pocos repositorios contienen información de versionado y menos aún, codificados según el vocabulario info:eu-repo version terms. Si tuviese los valores adecuados, la solución mas simple sería efectuar un mapeo, en la interfaz OAI-PMH, entre los vocabularios eu-repo y los COAR, teniendo en cuenta que no es exactamente una relación biunívoca…

Si no los tuviese, plantéese una incorporación gradual de esta información en los registros de su repositorio. Y aprovechando la oportunidad, piense en utilizar ya los vocabularios COAR.

En el interim, puede optar por exponer el elemento oaire:version con el valor menos preciso, o comprometido, NA

Adaptando a OpenAIRE 4 (II). Vocabularios COAR de tipología

En el nuevo perfil de aplicación usado por OpenAIRE 4, los elementos descriptores de tipologías deben exponerse en el elemento oaire:resourceType y seguir los formatos definidos por el vocabulario controlado COAR Resource Type Genres. Mientras que el primer requisito no debiera plantearnos complicaciones, el uso de un nuevo vocabulario (descriptor de tipologías) tiene un impacto sustancial en cualquier repositorio.

Expliquemos. La mayor parte de los repositorios, compatibles OpenAIRE 1, 2 o 3, están usando para la descripción de los tipos de recurso el vocabulario originado por el proyecto DRIVER, info:eu-repo-publication-type-terms, y ahora habrá que cambiar al nuevo vocabulario.

Si comparamos los dos vocabularios observamos que solo un pequeño número de términos son equivalentes, sintáctica y semánticamente, La equivalencia no es generalizada, principalmente porque estamos comparando un vocabulario de 16 términos con otro mas extenso de 58.

Posibles soluciones

La primera, realizar una doble metadatación, duplicando los elementos descritores de tipología, conteniendo el repositorio elementos descriptivos info:eurepo/semantics y elementos oaire. Deberá ampliar los formularios de captura de datos y otras adaptaciones no excesivamente complejas. En los interfaces OAI-PMH (recordemos que posiblemente tengamos que mantener la compatibilidad OpenAIRE 3 y 4 un tiempo) expondremos (filtraremos) solo los elementos correspondientes de cada variante.

La segunda opción que tenemos consiste en mantener las metadataciones actuales. No perderá la compatibilidad OpenAIRE 3, pero para lograr la adaptación a OpenAIRE 4 deberá evaluar las tipologías actualmente en uso en el repositorio y definir en el crosswalk OAI los mapeos necesarios entre los vocabularios DRIVER y los vocabularios COAR. No habrá ganado la mejor precisión descriptiva del vocabulario COAR, pero se habrá dado un tiempo para el engorroso cambio de tipologías…..

Una tercera solución consiste en «atreverse» a sustituir en las metadataciones de los ítems, todos los dc.type con el vocabulario infoeurepo/semantics por las más precisas COAR Genre Types. Aparte del esfuerzo requerido, tenga cuidado porque podría perder la compatibilidad OpenAIRE3 actual (que suponemos que todavía es «recomendable» mantener), por lo que deberá efectuar el mapeo inverso en el interface OAI.

Hay otras opciones intermedias, pero básicamente hemos contado lo fundamental. Envíenos dudas y precisiones a lo contado en los comentarios a este post.

Hasta la próxima.

Adaptando a OpenAIRE 4

La aparición de OpenAIRE 4 (OpenAIRE Guidelines for Literature Repository Managers v4) a finales de 2018 plantea una serie de retos a los repositorios institucionales, como continuación de las sucesivas adaptaciones que OpenAIRE ha ido planteándo(nos) desde el año 2010.

En las VIII Jornadas OS Repositorios – XVIII Workshop de Proyectos Digitales de REBIUN, celebradas en León a finales de septiembre, tuvimos la oportunidad de hablar (en un triple ataque, una presentación en el evento paralelo organizado por la FECYT titulado «Nuevos servicios de OpenAIRE para gestores de repositorios», una comunicación al congreso conjuntamente con la Universidad de Huelva y un póster adicional) acerca de los condicionantes, problemas, alternativas y soluciones existentes ante el reto de la adaptación a OpenAIRE 4.

¿Cómo impacta en un repositorio el cumplimiento de las nuevas directrices ?

Aunque hay un número considerable de cambios y modificaciones que tendremos que hacer en nuestros repositorios, consideramos que los impactos principales serán:

  • La inclusión en los registros y posterior exposición OAI-PMH de los ORCID iDs, cuyo objetivo es tener una mayor precisión en la identificación de autorías y mayor visibilidad para los/as autores/as y para la institución¡¡¡
  • Incluir nuevos vocabularios COAR, que como todo cambio en los elementos descriptivos, revuelven el status quo de los metadatos.
  • Junto a lo anterior, se requiere la adaptación del interfaz OAI-PMH al nuevo esquema de recolección (perfil de aplicación) oai_openaire

¿De qué hablaremos?

En los posts que iremos dosificando (la adaptación es suficientemente compleja como para despacharla en un único post) seguiremos la propuesta que presentamos en el póster Adaptarse a OpenAIRE 4, explicado en diez pasos (disponible en https://buleria.unileon.es/handle/10612/11193

Adelantaremos su estructura :

  1. Incorpore identificadores de autor a sus registros
  2. Convierta vocabularios COAR: Tipología
  3. Convierta vocabularios COAR: Versionado
  4. Convierta vocabularios COAR: Derechos de acceso
  5. Incluya la información de financiación
  6. Considere los períodos de embargo
  7. Referencie los ficheros de contenido
  8. Complete la información del recurso
  9. Cree un nuevo esquema/perfil de aplicación
  10. Cree un nuevo contexto

Presten atención a sus pantallas…

Extracción automática de términos MeSH-DeCS en repositorios de ciencias de la salud: el caso de RUNA

En las jornadas Bibliosalud 2019, (Hospital Universitario Central de Asturias, 4 y 5 de Abril de 2019) presentamos un póster, realizado conjuntamente con Carmen Rodríguez Otero de Bibliosaúde-Biblioteca Virtual do Sistema Sanitario Público de Galicia, sobre los sistemas de extracción automatizada de palabras clave aplicados a repositorios temáticos.

Sigue el texto explicativo y extendido del póster. (También disponible en http://eprints.rclis.org/34448/)

Introducción

Para administrar y mejorar las búsquedas en la literatura biomédica, la Biblioteca Nacional de Medicina de EE.UU. (NLM®) desarrolló el vocabulario controlado Medical Subject Heading (MeSH). La clasificación temática basada en vocabularios se ha identificado como uno de los factores principales en las estrategias de búsqueda y recuperación de documentos.

Desafortunadamente, dada su naturaleza especializada, la asignación manual de términos MeSH a artículos biomédicos es una tarea compleja, subjetiva y que requiere mucho tiempo, por lo que los sistemas de extracción automatizada de palabras clave (AKE) se convierten en soluciones evidentes para su incorporación a sistemas que necesitan describir y manejar miles de documentos, como son los repositorios.

En el póster se muestra la solución incorporada en el repositorio RUNA, repositorio institucional del Sistema Público de Salud de Galicia para facilitar la clasificación temática sobre vocabularios temáticos (MeSH-DeCS).

Se describe de forma específica el sistema de extracción automatica de términos de documentos y cómo se ha integrado dicha solución en el flujo de archivo de documentos en el repositorio para posibilitar el complemento por catalogadores expertos y así mejorar la calidad de la descripción temática efectuada.

Metodología
El sistema construido se integra en el flujo de autoarchivo de los documentos del repositorio, con el fin de unir las ventajas del procesamiento automático con la existencia de un experto que realice la selección de los términos efectivamente usados. En este sentido el subsistema extractor automatizado se visiona como un pre-tratamiento del documento que propone términos de clasificación, que deberán luego ser validados y rechazados por el usuario experto del repositorio.

En primer lugar el documento, normalmente en formato PDF o en formatos tipo WORD, etc.. , es convertido a formato simple textual (txt). Este paso del proceso no sirve únicamente para normalizar la entrada documental al sistema extractor sino que el fichero transformado es usado también por el indexador a texto completo del repositorio RUNA.

A partir de ese fichero «simple» se realiza una primera selección de términos candidatos, con extracción de todas de las frases, palabras, términos y conceptos susceptibles de ser descriptores.

Sigue un proceso de puntuación y selección de términos. Todos los términos candidatos son puntuados combinando las propiedades de los términos (p.ej, su pertenencia al título del documento) con tecnicas de aprendizaje-máquina (machine learning techniques) para determinar la probabilidad de que un elemento sea un término clave. El sistema está configurado para proponer, a la finalización de este proceso un número determinado de términos. En la implementación específica que se ha realizado del motor de extracción, los elementos extraídos deben pertenecer al vocabulario MeSH-DeCS.

Los elementos extraídos se presentan al personal catalogador que en base a su experiencia puede aceptarlos, rechazarlos o añadir nuevos términos, como en un proceso normal de flujo de ingesta al repositorio, finalizando así el proceso de aceptación del documento en RUNA.

Como aspecto complementario, el sistema se inicializa mediante el suministro de un número suficiente de documentos, a modo de corpus, y sus correspondientes metadataciones temáticas realizadas por un experto. El motor de extracción realiza un primer ajuste de las probabilidades de los términos, efectuando así su aprendizaje inicial.

Igualmente, aunque no se ha implementado aún en RUNA, el flujo continuo de las selecciones, revisiones y aprobaciones efectuadas por el personal catalogador pueden ser usados para realimentar el motor de extracción, evolucionando las probabilidades asignadas a cada término y mejorando así la calidad de las propuestas automáticas.

La solución descrita, además del software Dspace del repositorio RUNA, se basa en Maui, un extractor de software libre (licencia GPL). Maui es el acrónimo de Multi-purpose automatic topic indexing, Indexador de tópicos automático y multi-propósito, un software diseñado por la doctora Alyona Medelyan

El núcleo de Maui es el sistema de aprendizaje-máquina denominado WEKA, que a su vez incorpora el algoritmo KEA de extracción de palabras clave.

Resultados y Conclusiones
El sistema construido automatiza la extracción, descripción e indexado de términos tópicos sobre los documentos incorporados al repositorio RUNA. Además de efectuar una extracción automática, permite que el personal experto en catalogación seleccione (y añada/corrija si así lo considera) los términos MeSH-DeCS mas adecuados, mejorando así la calidad y precisión de la catalogación del documento.

Los sistemas de extracción automática de palabras clave pueden considerarse un complemento que facilite de manera eficiente la precisión de la catalogación temática de los documentos incorporados a los repositorios temáticos.

Proceso de extracción

¿y cómo es realmente el proceso de implantar DSpace?

Una pregunta recurrente en organizaciones que se están planteando la instalación de un repositorio institucional es qué pasos dar.  Ya hace muchos años que el   Manual LEADIRS II. Cómo crear un Repositorio Institucional, nos orientaba sobre todas las consideraciones a tener en cuenta a la hora de acometer un proyecto de este estilo, pero queríamos dar una visión más concisa basada en nuestra experiencia con muchos de ustedes.

Un aspecto principal a tener en cuenta en una implantación de Dspace es que los requisitos afloran muy progresivamente en la vida del proyecto, según los usuarios van ajustando y trasladando los  modelos mentales conceptuales y las necesidades de la organización en requisitos y funcionalidades Dspace.  Por esto desaconsejamos un modelo tradicional de toma de requisitos–> documento de requisitos–> desarrollo–> implantación… Mas bien el modelo sería iterativo, con una primera fase para cubrir los requisitos que ya se hayan explicitado y uno o varios ciclos posteriores para llevar el repositorio a puntos posteriores de adaptación a las necesidades de la institución…

Así, un plan constará de una fase inicial de toma de requisitos, incepción, en donde se identifican los parámetros principales de la instalación: equipamiento disponible hw/sw,  tipo de objetos, estructura general de grupos-autorizaciones, origen de contenidos, necesidades de migración de contenidos,  estructura de colecciones, interfaces con otros aplicativos, necesidades de recolección (harvesting) de/desde, integración con sistemas de autenticación, licenciamiento, gestión de derechos, y alguna cosa más… Parece mucho, pero en realidad es una fase bastante ligera…

En este punto se está en condiciones de construir y configurar una instalación base, comprobando que los aspectos técnicos se cumplen. Si no se requieren desarrollos, en un plazo breve se debería tener una instancia DSpace razonablemente operativa. Además, se aprovecha para identificar y dimensionar, si acaso, los posibles desarrollos a efectuar.

En paralelo se trabaja en configurar/parametrizar la estructura lógica de Dspace, mediante una serie de ciclos de evolución de colecciones, usuarios, metadatos, etc….  Nuestra experiencia nos dice que los usuarios agotan todo el tiempo disponible, y más, pero si la estructura de las colecciones es simple (colección:  entendida como el conjunto de especificaciones de objetos-metadatos-permisos-pantallas de envío y de revisión)  o la tenéis ya pensada, pues se puede hacer razonablemente rápido.  No es intensivo en trabajo, pero podría dar lugar a períodos de implantación largos. Esa es la mala noticia. La buena es que por lo general no forma parte del camino crítico de una puesta en producción, ya que las actividades de ajuste «fino» se pueden hacer tras la puesta en producción, si así se determina…

Cuando el paso anterior está al 80%… ya se podría proceder a la carga inicial de contenidos, si existen, puesto que aportarán un valor inmediato a los usuarios. La carga de datos en general da problemas, porque se aprovecha para hacer revisión del material existente, complementar metadatos, etc… Señalaremos que al ser un proceso ad-hoc (aunque Dspace tenga herramientas específicas) pues siempre hay que inventar o reinventar algo.

En cuanto a cambiar la apariencia o look&feel, aspecto siempre recomendable, siempre se va mas rápido si nos adherimos  al libro de estilo intitucional…si no, pues habrá que acometer un diseño especifico…

Y ya se está listo para salir en producción (y listos para acometer otras fases de evolución y crecimiento del repositorio), aunque antes hay que proceder a aprender y formar y divulgar internamente… como casi cualquier proyecto complejo.

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 !