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…

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

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

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.