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

Cursos de DSpace 7 para Administradores, segundo semestre 2024

Hemos programando una nueva edición de cursos sobre la  versión 7 de DSpace.

Administración de DSpace 7, del 30 de septiembre al 31 de octubre de 2024

Administración Técnica de DSpace 7, del 1 de octubre al 8 de noviembre de 2024

Administración avanzada de DSpace,  del 4 de noviembre al 5 de diciembre de 2024

Los formularios de inscripción están abiertos.

Más información

Repositorio de Datos ¿servirá mi repositorio Dspace?

Los autores almacenan sus datos de investigación para el cumplimiento de políticas o requisitos de diversos agentes, como las instituciones académicas y agencias de financiamiento y evaluación, que piden que se depositen sus datos en repositorios, como parte de los requisitos de sus políticas de ciencia e investigación

El personal de investigación del sector público o cuya actividad investigadora esté financiada mayoritariamente con fondos públicos […] deberá depositar una copia de la versión final aceptada para publicación y los datos asociados a las mismas en repositorios institucionales o temáticos de acceso abierto, de forma simultánea a la fecha de publicación. (1)

O simplemente, éstos se depositan para posibilitar la verificación de resultados y la transparencia en la investigación, aspectos prioritarios de la ciencia abierta. Además, al estar los repositorios integrados con el sistema de ciencia internacional como OpenAIRE, se facilita el descubrimiento y el reuso de datasets relevantes para otras investigaciones.

No obstante, intentar almacenar en un repositorio tradicional datasets que superan los 100-200 MB, algo normal en datasets raw o en ciertas disciplinas académicas,  plantea problemas de sesiones que expiran, almacenamiento creciente, colisión con otros tráficos del repositorio, etc.. Por tanto el uso de DSpace para estos mega-datasets requiere de planteamientos diferenciados a los de repositorios textuales, o bien el uso de sistemas específicos de subidas de ficheros en los procesos de archivo en el repositorio. Nuestra recomendación, si se está pensando en este tipo de datasets, sería bastante tibia sobre la conveniencia de usar DSpace.

En el caso que el condicionante de tamaño no sea limitante, el  uso de DSpace puede suponer ventajas considerables, tanto coexistiendo los datasets con el resto de materiales del repositorio «textual» como si se considera un repositorio específico de datos. El primer caso estaría recomendado si los datasets son una pequeña parte de los objetos a almacenar, pues se opera una única infraestructura y se comparte el conocimiento de los especialistas responsables del repositorio.

Para los repositorios anteriores se debería considerar la implantación de  las siguientes funcionalidades:
    • Adaptación de los metadatos a la casuística específica de los datasets
    • Asignación de DOIs a los datasets, proporcionando una identificación única y permanente que facilita la citación y la referencia en publicaciones académicas, dando crédito adecuado a los creadores originales de los datos (el  DOI es preferible al handle ara este tipo de objetos digitales)
    • Soporte a licencias de reuso ODCommons, mas apropiadas que las Creative Commons para este tipo de material.
    • Exposición OAI-PMH compatible con las OpenAIRE Guidelines for Data Archives

(1) artículo 37. Ley 14/2011, de 1 de junio de 2011, de la Ciencia, la Tecnología y la Innovación

Curso de DSpace 7 para Administradores, del 4 de marzo al 5 de abril de 2024

Con muchas instituciones planificando la migración de versión, hemos programando una nueva edición de cursos sobre la  versión 7 de DSpace. En marzo tenemos una edición del curso Administración de DSpace 7, continuando la programación del primer semestre con ediciones de nuevos cursos de Administración Técnica de DSpace 7 ( del 4 de marzo al 12 de abril de 2024)  y Administración avanzada de DSpace (del 8 de abril al 17 de mayo de 2024). Los formularios de inscripción están abiertos.

Más información

Indexación en Scholar. Dudas y certezas

Google Scholar  es en la actualidad una de las fuentes principales para la búsqueda de información publicada de índole científico-académica. Por ello, la visibilidad de los contenidos de un repositorio en Scholar es de primordial importancia para la valorización del mismo.

De forma simplificada, Scholar rastrea e indexa los documentos que tengan una estructura de aspecto académico. A continuación, el rastreador analiza los enlaces a los metadatos, que a continuación son evaluados por el algoritmo de Scholar para determinar si la información se agrega o no al índice de Scholar.

Un conteo reducido de resultados indexados, la disminución de los mismos en un período de tiempo o incluso la desaparición de todos los contenidos del índice Scholar, es causa habitual de desconcierto en los responsables de los repositorios.

Lo que sabemos

Google y Google Scholar son dos motores de indexación y búsqueda distintos, accediendo a ellos por dos URLs distintas. Las habituales recomendaciones SEO no parece que sean efectivas para la mejora de la indexación Scholar.

La comunidad de desarrolladores de DSpace y el equipo de Google Scholar han hecho un esfuerzo importante en adaptar DSpace 5, 6 y 7 a los requisitos de Scholar, trabajando conjuntamente. Es habitual el soporte y presencia de expertos de Scholar en conferencias de Dspace, webinars de divulgación, etc…, Una frase que podría describir esa colaboración sería «Scholar likes Dspace»

Scholar recomienda el uso de las metaetiquetas conformes al esquema Highwire Press para la correcta indexación. Una instalación base de DSpace incorpora mapeos estándar entre Dublin core y los metatags Highwire. Si usa los metadatos «habituales» para describir sus ítems en DSpace, los metatags Highwire serán razonablemente correctos. Como DSpace hace un mapeo de los metadatos internos a las metatags usados por Scholar, si ese mapeo está mal configurado, habrá errores (muchos) de indexación.

<meta content="A 13 kg meteoroid from comet 21P/Giacobini-Zinner recorded as a bolide during the 2011 draconid outburst" name="citation_title">
<meta content="eng" name="citation_language">
<meta content="apellido;  nombre" name="citation_author">
<meta content="http://rabida.uhu.es/dspace/bitstream/10272/9004/2/A%2013%20KG.pdf" name="citation_pdf_url">
<meta content="2012" name="citation_date">
<meta content="http://rabida.uhu.es/dspace/handle/10272/9004" name="citation_abstract_html_url">

Un repositorio no será indexado si presenta (bastantes) errores en la indexación. Los errores (relacionados con los metadatos) más habituales son

  • En general, metatags no alineados con la especificación Scholar
  • Ítems sin fecha de publicación o considerando dc.data.available (fecha de subida del repositorio) como el dc.date.issued.
  • Ítems con lista de autores que difieren del artículo «real». Orden de autorías cambiado o directores de tesis que aparecen como autores, etc
  • Uso de citation_date en lugar de citation_publication_date
  • Formato de fechas YYYY-MM-DD en vez del preferido por Scholar de YYYY/MM/DD
  • Disparidad entre los metadatos extraídos de nuestro repositorio y los extraídos de otras fuentes.
  • etc..

Además, Scholar necesita poder acceder a los ficheros de contenido, por lo que otro conjunto de errores deriva de las restricciones al acceso al bitstream o fichero (acceso cerrado, embargos, inexistencia del fichero de contenido). Si Scholar no puede acceder al fichero, no indexa el ítem. Si esta condición se da en muchos ítems, quizá no indexe nada del repositorio.

Relacionado con el párrafo anterior, Scholar penaliza los redireccionamientos de la descarga de bitstreams, En versiones «antiguas» de DSpace la forma de capturar las estadísticas de Analytics era mediante redireccionamientos, pero ya en versiones 5,x y posteriores esa «técnica» no es necesaria. No obstante, debería revisar que otros sistemas intermedios no están interfiriendo en este sentido (quizá estadísticas Matomo, etc…)

Además de los metadatos de los artículos, Scholar extrae metadatos de indexación analizando la primera página del PDF de contenido, por lo que la funcionalidad de DSpace denominada «PDF Citation Cover Page» , o equivalentes, puede afectar a las técnicas de extracción de metadatos de Scholar. Y recordamos de nuevo, el repositorio puede ser penalizado en todo o en parte por Scholar.

Un robots.txt, que referencie adecuadamente el sitemap es una excelente ayuda para que Scholar nos localice todo el contenido.

# The FULL URL to the DSpace sitemaps
# The http://rabida.uhu.es/dspace will be auto-filled with the value in dspace.cfg
# XML sitemap is listed first as it is preferred by most search engines
Sitemap: http://rabida.uhu.es/dspace/sitemap
Sitemap: http://rabida.uhu.es/dspace/htmlmap

##########################
# Default Access Group
# (NOTE: blank lines are not allowable in a group record)
######################

Lo que sospechamos…

Scholar es un «proyecto» diferenciado, con su equipo propio (reducido, parece) y continuidad «variable», como parte de los proyectos «experimentales» de Google. Esto hace que la interlocución con el equipo de soporte sea a veces errática o dificultosa.

La indexación Scholar tiene mecanismos distintos de la indexación habitual de Google, ésta que siempre nos parece mágica y automática. Mientras que Google indexa un sitio si lo descubre automáticamente o se le explicita con las herramientas de web manager, la indexación Scholar parece que necesita ser «solicitada» por los responsables de un repositorio.

No hay una indexación continua del espacio de repositorios, sino que el índice se actualiza con una periodicidad que no debe llegar a dos veces al año…

Scholar no tiene una declaración explícita de lo que considera trabajos «a indexar» (scholarly outputs …) La identificación de contenido «indexable» la realiza ponderando una serie de factores (presencia de metadatos, PDFs con texto extraíble, etc..). Si un repositorio tiene una mezcla significativa de trabajos de investigación con otro tipo de material (educativos, fondo antiguo, etc..) es posible que la indexación no sea efectiva o no se produzca.

No conocemos casos en que Scholar haya reportado errores debido a la presencia de código javascript empotrado en las páginas de item. Como recomendación general, evite javascript para la recuperación de texto indexable (funcionalidad muy habitual en la visualización de dc.description.abstracts, por poner un ejemplo). Que no conozcamos casos de no-indexación no significa que esta causa de mala-indexación no sea importante. Simplemente Scholar no lo notifica a los afectados.

Para saber mas

Conferencia Monica Westin a EIFL

Recursos en la wiki de Dspace 7

Hablemos de la versión 7 de DSpace y su sistema de versionado

En posts anteriores describíamos cómo era el modelo de versionado de Dspace (v6 y anteriores ) y cómo este modelo se trastocó recientemente al anuncia el fin del soporte de las vesiones 5 y 6

Un poco de contexto sobre los tiempos de la versión 7 de DSpace. Fue anunciada en el 2015, las primeras sesiones de divulgación ya se impartieron en el Open Repositories de Dublín 2016, fue reanunciado el 2017, el 2018, etc. Por fin, la esperada versión 7.0 aparece en julio del 2021, seguida de la 7.1 (Oct 2021), 7.2 (Feb 2022) y 7.3 (Jun 2022). ¿Cómo es posible que desde su anuncio hasta la versión 7.0 transcurran seis años? ¿Cómo aparecen releases nuevas cada cuatro meses?

Lo cierto es que la versión 7 supone un cambio gigantesco en el código de Dspace y es extremadamente ambiciosa, funcionalmente hablando. Las implicaciones en los plazos de desarrollo posiblemente se calibraron mal.

Claramente seis años de espera meten mucha presión y provocaron que, apremiados por los plazos, se tomase la decisión de lanzar la versión 7.0 con funcionalidad a la vez ampliada (la lista de novedades es larga) pero incompleta ( si la comparamos con la versión 6.3).

Y lo anterior significa que las versiones 7.1, 7.2, 7.3, 7.x intentan corregir esa incompletitud funcional, poco a poco, y según se invierten centenares de horas de desarrollo se incorporan funcionalidades que ya existían en la versión 6 o bien se requieren para aprovechar las nuevas características de la versión 7 (es el caso de la gestión del modelo de entidades)

El nuevo modelo de versionado, obligado por las anteriores circunstancias, tiene implicaciones fuertes para la instituciones que se planteen el paso a la versión 7.

En primer lugar, las instalaciones tendrán que hacer una evaluación cuidadosa de la versión destino al migrar desde versiones 5 y 6. En https://wiki.lyrasis.org/display/DSDOC7x/Release+Notes se describen las funcionalidades disponibles en las versiones 7.0 a 7.3 y a su vez en https://wiki.lyrasis.org/display/DSPACE/RoadMap se describe el alcance funcional que se pretende con las próximas versiones. La evaluación es compleja, sobre todo para las instalaciones que han extendido significativamente su DSpace y la decisión no será fácil.

La segunda implicación es que cambiar de release (7.3 a 7.4 p.ej) no será una tarea sencilla o al menos no será tan sencilla como en v6 y anteriores…. Además de parches funcionales y de seguridad, habituales antes, en una release cualquiera aparecerán funcionalidades de importancia, y que además requerirán posiblemente extensiones al modelo de datos. Y eso supone problemas (y costes) para actualizar, al menos con la frecuencia que se podía actualizar la versión 6 . Recordemos que los planes son liberar una nueva release cada 4 meses¡¡¡¡

Saludos y buenas migraciones¡¡¡

El soporte de DSpace 5 y 6 terminará en el 2023

La política de soporte del software #Dspace ha cambiado de forma imprevista el 31 de mayo de 2022 con consecuencias para los repositorios operando este software. La anterior política decía:

The DSpace Committers provide security updates/support for the most recent three (3) major releases of the platform.

Traduciendo e interpretando, significaba que la versión 5 tendría soporte hasta la aparición de la versión 8 y la versión 6 (mayoritaria en los repositorios DSpace) tendría soporte hasta que apareciese la versión 9 (nuestra bola de cristal dice que hacia 2026 o posterior)

Esta política cambió ayer para incluir un apéndice:

 However, earlier end-of-life dates may be announced if major concerns arise over the stability or longevity of a specific release”

Y esta declaración se ha aprovechado para hacer la siguiente declaración:

“ … the age of the 5.x and 6.x codebases  has resulted in major concerns over our ability to continue to address future security vulnerabilities in these releases”

y las consecuencias son:

  • DSpace 5.x: Support ends on January 1, 2023
  • DSpace 6.x: Support ends on July 1, 2023

Aun cuando un número considerable de instalaciones ya estaban planteándose las migraciones a versión 7 en el corto-medio plazo, el anuncio anterior plantea un escenario complejo, en términos de plazos, cargas de trabajo, inversiones, etc… que aún estamos analizando, ya que, como hemos planteado en algún foro, no vemos (a fecha de este post, junio de 2022) aún “madura” la Versión 7 para su instalación en repositorios “grandes” o funcionalmente “complejos”.

Estamos atentos para atender a cualesquiera preguntas que tengáis al respecto

Fuentes:

https://groups.google.com/g/dspace-tech/c/OOq80cq8CF

https://wiki.lyrasis.org/display/DSPACE/Support+for+DSpace+5+and+6+is+ending+in+2023#SupportforDSpace5and6isendingin2023-WhyissupportendingforDSpace5.xand6.xin2023?

DSpace 7.0 disponible

Atlanta, GA,  2 de agosto de 2021 –   Ya está disponible la largo tiempo esperada y tantas veces anunciada versión DSpace 7.0. Esta versión presenta una nueva interfaz de usuario (Angular) que reúne lo mejor de las interfaces JSPUI y XMLUI, rehaciéndose todas las características de DSpace. La nueva interfaz de usuario se apoya en una nueva REST API, que expone todos los contenidos y funcionalidades, permitiendo como nunca antes la  integración e interoperabilidad de DSpace con sistemas y servicios externos.

Esta versión reúne a toda la comunidad DSpace bajo una única interfaz de usuario, lo que nos permitirá progresar juntos más rápidamente. 

«DSpace 7.0 es la mayor versión de nuestra historia, con más de un millón de líneas de código de DSpace cambiadas, mayor que las últimas 4 versiones anteriores juntas. A pesar de la pandemia mundial, hemos acelerado nuestro desarrollo y lanzado un total de 5 versiones Beta, culminando con un Testathon global. Esta versión es el resultado de la dedicación, la determinación y el compromiso de nuestra comunidad, que alimenta continuamente el programa DSpace». Kristi Park, Presidenta de Gobernanza de DSpace y Directora Ejecutiva de la Biblioteca Digital de Texas

DSpace 7.0 ha sido desarrollado por la colaboración de más de 60 desarrolladores de la comunidad, liderados por LYRASIS, Atmire y 4Science. Más de 25 instituciones de todo el mundo han aportado generosamente su apoyo financiero. Consulte la lista completa de colaboradores en las   las notas de la versión.notas de la versión. Si desea contribuir a la próxima versión 7.x, considere la posibilidad de unirse a futuras reuniones del Grupo de Trabajo de DSpace 7.

Características de DSpace

La versión 7.0 de DSpace incluye las siguientes características:

  • Una nueva interfaz de usuario basada en Angular (reemplazando XMLUI y JSPUI). El objetivo de la nueva interfaz ha sido implementar todas las características principales de XMLUI y JSPUI en una única y moderna interfaz de usuario.
  • Una nueva y completa REST API , utilizando las mejores prácticas modernas. El objetivo de la nueva API REST es implementar una arquitectura moderna, segura, independiente y escalable.
  • Rediseño de los envíos y los flujos de trabajo con un proceso de envío en una página, con una interfaz de arrastrar y soltar y un rediseño de MyDSpace.
  • Un nuevo modelo de objetos de Entidades Configurables, que permite la creación de nuevas tipologías de entidades, así como contemplar las relaciones entre las mismas. Esta característica permite una mayor integración con los sistemas de identificadores externos (por ejemplo, ORCID), los sistemas CRIS, los sistemas de publicación de revistas electrónicas, etc.

La documentación técnica inicial de DSpace 7.0 está disponible.

Debido a la complejidad de fusionar características de las dos interfaces (XMLUI y JSPUI) en una sola, unido al objetivo de hacer que 7.0 estuviese disponible lo antes posible, la versión contiene las funcionalidades de mayor prioridad (las que se consideran más utilizadas). Determinadas funcionalidades se han retrasado para una versión posterior de 7.x. Consulte  los objetivos de la versión 7 de DSpace para obtener más información

Sea el primero de su país en actualizarse. Cuéntenos qué le hizo elegir DSpace 7.0 y qué características le condujeron a la actualización. Comparta su historia con DSpace 7.0.

Acerca de LYRASIS

LYRASIS, una organización de miembros sin ánimo de lucro con sede en Estados Unidos, coopera con más de 1000 bibliotecas, archivos y museos miembros para crear, acceder, preservar y gestionar la información digital, a la vez que construye y mantiene la colaboración, y mejora la tecnología. 

Para más información, visite www.lyrasis.org

Acerca de DSpace

DSpace es el software de repositorio de código abierto más utilizado del mundo, con más de 3.000 instalaciones. Está gobernado, desarrollado, apoyado y promovido por la comunidad. DSpace es el software preferido por las organizaciones ya sean académicas, sin ánimo de lucro o comerciales que crean repositorios digitales abiertos. Es un software gratuito, de instalación fácil e inmediata y completamente personalizable para adaptarse a las necesidades de cualquier organización.. Para más información, visite www.dspace.org.

(traducción de la nota de prensa de Lyrasis por Emilio Lorenzo, disculpad los inevitables gazapos, incorrecciones y expresiones forzadas)

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.