Archivos de Tags: openAIRE 4

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 (I): Identificadores de autor

Incorpore Identificadores de autor en sus metadatos

Entre los objetivos de OpenAIRE v4.0 figura la búsqueda de una mayor precisión, mas allá de los nombres normalizados que planteaba DRIVER, sobre los agentes del sistema investigador. Para ello OpenAIRE propone el uso de esquemas de identificación (identifier schemes) para autores, organizaciones, agencias financiadoras, etc.

Por tanto el primer problema que debemos abordar es cómo incorporar a nuestro repositorio procesos de normalización de nombres de autor y asignación de identificadores de autor, preferiblemente ORCID iDs.

Nuestra propuesta es el uso de métodos de desambiguación de nombres y asignación de identificadores, embebidos en los procesos de ingesta de contenidos y revisión de la metadatación, preferiblemente mediante el uso de funciones de control de autoridades. Hay algunas instituciones que han optado por soluciones diferentes, todas valen en tanto logren hacer correctamente la correspondencia Nombre de autor <–> Identificador de autor (para todos las posibles fuentes de autoridad, añadiríamos)

Recuerde que es posible, aunque en algunos escenarios puede desaconsejarse, efectuar consultas sobre la API de ORCID, incorporando datos de identificación de autores no institucionales a su repositorio.

Igualmente, si tiene la posibilidad de identificar la institución u organización de los autores, puede considerar exponer ese dato.

Exposición en el interface OAI_PMH de los identificadores de autor

El uso de esquemas de identificación (identifier schemes) para autores, organizaciones, agencias financiadoras, etc. se realiza en OpenAIRE 4 mediante la exposición de los identificadores únicos, PIDS, (principalmente ORCID iDs e ISNI) en los elementos de autoría, y más específicamente en los elementos datacite:creator y datacite:contributor junto con sus atributos, affiliation, nameIdentifier, contributorType, nameIdentifierScheme y schemeURI

Dependiendo de la solución adoptada (ver epígrafe anterior) para almacenar las asociaciones Autor-Identificador, trasladar éstas a la interface OAI-PMH puede resultar mas o menos compleja y/o efectiva.

En la figura siguiente, el modelo autoridades-SOLR authority cache-SOLR OAI-PMH que usamos en nuestras implementaciones, intentando mostraros rla posible complejidad de dicha exposición.

Si todo está ensamblado, estaremos en condiciones de exponer la información de autores de forma compatible openAIRE 4. Una muestra de lo dicho:

<datacite:creator>

<datacite:creatorName>Gavilán Ceballos, Beatriz</datacite:creatorName>
<datacite:nameIdentifier schemeURI=»https://orcid.org» nameIdentifierScheme=»ORCID»>0000-0001-7515-1186</datacite:nameIdentifier>
<datacite:affiliation>Universidad de Huelva</datacite:affiliation>
</datacite:creator>

Por ahora, suficiente. Mas entregas en unos días