Resultados-INEOS-manual-buenas-practicas.pdf

Type: Document | Status: ready

8

✔ Ampliar la información disponible y la visibilidad de los autores dentro de los repositorios institucionales con la inclusión del perfil público del investigador de CVN.
✔ Mejorar los procesos de publicación en acceso abierto de las revistas editadas en el seno de las instituciones públicas de investigación. ✔ Utilizar vocabularios controlados para mejorar la descripción, la interoperabilidad y la recuperación de la información.
IV. Buenas prácticas derivadas de INEOS
a) Inclusión de la información relativa a la fuente de financiación en los repositorios institucionales
La FECYT ha desarrollado un sistema de enriquecimiento de la información relativa a la fuente de financiación de los trabajos de investigación depositados en acceso abierto para los repositorios institucionales, con datos de las convocatorias nacionales. Este enriquecimiento se puede realizar de forma manual, a través de un buscador de proyectos1, o de forma automática, a través de una interfaz API REST2 de acceso público. Este servicio permite vincular los resultados de investigación disponibles en RECOLECTA con su fuente de financiación. Para lograr este objetivo, la FECYT desarrolló las siguientes actuaciones:
a) Construir una base de datos con información relativa a los proyectos de investigación financiados por convocatorias nacionales.
b) Alimentar y actualizar esta base de datos de forma periódica. c) Desarrollar mecanismos para transferir esa información a los repositorios de RECOLECTA y a cualquier sistema de gestión de información científica institucional y curricular CRIS, a través de un buscador y una interfaz API. d) Incluir nuevas opciones para la búsqueda de proyectos en el buscador de RECOLECTA. e) Validar el metadato referido a la fuente de financiación de todos los repositorios de RECOLECTA. f) Recolectar el metadato referido a la fuente de financiación. Para crear la base de datos de proyectos nacionales, la FECYT ha contado con la colaboración de la Agencia Estatal de Investigación (AEI). En el momento de publicar este Manual, la información disponible en los servicios web de RECOLECTA es la siguiente: ● Desde el año 2004 hasta el año 2015 (incluido): Todas las convocatorias que aparecen en los programas anuales de actividades de I+D.
● Desde el año 2006 hasta el año 2016 (incluido): Las siguientes convocatorias autonómicas:

Generalitat Valenciana (2007-2011)

Junta de Castilla y León (2008-2014)

Gobierno del Principado de Asturias (2006-2014)

1 Para más información: Guía de ayuda del buscador de publicaciones y proyectos RECOLECTA | Recolecta (fecyt.es) 2 Características técnicas de la API: https://recolecta.fecyt.es/node/1273?language=es

9

Xunta de Galicia (2009-2011)

Junta de Andalucía (2008-2009)

Gobierno de Canarias (2008-2012)

Gobierno de Aragón (2009-2015)

Gobierno de Cantabria (2007-2016)

Junta de Comunidades de Castilla-La Mancha (2006-2013)

Gobierno de la Comunidad de Madrid (2008-2011)

Junta de Extremadura (2008-2010)

Govern de les Illes Balears (2006-2014)

Gobierno de la Región de Murcia (2009-20112)

Gobierno Vasco (2009)

Gobierno de La Rioja (2006-2009)

Gobierno de Navarra (2009-2011) ● Año 2016: Convocatorias de la Fundación Española para la Ciencia y la Tecnología (FECYT), el Instituto de Salud Carlos III (ISCIII) y el Centro para el Desarrollo Tecnológico e Industrial (CDTI). ● Año 2017 y siguientes: Todas las convocatorias de la Agencia Estatal de Investigación (AEI). Estos datos se actualizarán anualmente. A fecha de publicación de este Manual, el último año disponible es 2019. RECOLECTA obtiene el campo de fuente de financiación de los repositorios institucionales y lo almacena entre los metadatos agregados y expuestos en su buscador. De ese modo, el navegador permite asociar las publicaciones con su fuente de financiación, y los proyectos financiados con la producción científica que han generado.
A continuación se muestra la visualización de los resultados en el buscador de RECOLECTA:

10

Figura 1: Visualización de los resultados en el buscador de RECOLECTA. Fuente: https://www.recolecta.fecyt.es/
En la siguiente infografía se informa de cómo los repositorios enriquecen el metadato de código de proyecto en RECOLECTA:

Figura 2: Cómo enriquecer el metadato de código de proyecto. Fuente: https://www.recolecta.fecyt.es/ El Instituto de Salud Carlos III contribuyó al correcto desarrollo de los trabajos mediante el enriquecimiento del metadato de identificación de los proyectos de investigación na cionales en su repositorio institucional de acceso abierto, REPISALUD. De su experiencia, INEOS ha obtenido una serie de pautas y orientaciones específicas encaminadas a reforzar la interoperabilidad de los repositorios institucionales, cuya adopción es recomendable por parte

11

de los repositorios que contienen literatura científica. Estas pautas se fundamentan en las Directrices de OpenAIRE para administradores de repositorios de literatura v43. ✔ A la hora de describir un trabajo de investigación depositado en un repositorio institucional, es fundamental detallar no solo la agencia o entidad financiadora del mismo, sino que se deben incluir los datos referidos al proyecto financiado. ✔ El contenido de este campo se refiere al número o código de proyecto del que ha resultado el artículo o producto de investigación que se está depositando. Es recomendable que este metadato tenga carácter obligatorio (cuando así corresponda) dentro de la plantilla de descripción de artículos en el repositorio y que su contenido esté normalizado.
✔ Dentro del esquema de metadatos de DublinCore el utilizado para describir esta información es el DC.Relation y el cualificador será el projectID. ✔ Para los trabajos financiados por la Comisión Europea se utilizará la sintaxis OpenAire3.0: info:eu-repo/grantAgreement/Funder/FundingProgram/ProjectID ✔ Los valores del metadato incluyen el código de identificación del proyecto, que equivale al identificador del acuerdo de subvención o al número de adjudicación. Para ello usaremos la sintaxis info:eu-repo/grantAgreement/EC/número de proyecto en el caso de que el financiador sea la Comisión Europea. Para los trabajos financiados con fondos nacionales a través del Plan Estatal de Investigación Científica, Técnica y de Innovación, usaremos info:eu-repo/grantAgreement/ES/número de proyecto ✔ Como consecuencia de la actualización de las directrices OpenAIRE a la versión 4, la sintaxis usada en este metadato habrá de ser modificada para adaptarse a las mismas.
✔ El campo oaire:fundingReference, correspondiente al modelo de metadatos OpenAIRE Specification Schema, es utilizado por los siguientes esquemas de metadatos y puede intercambiarse su uso de manera indistinta: Esquema de Metadatos Campo Relacionado Dc dc.relation.projectID Dcterms dcterms.description.sponsorship Marcxml field: 536 ✔ Es necesario preparar los repositorios para vincular los proyectos a las publicaciones. Con la utilización de este metadato la información contenida en el repositorio hace que este gane en calidad y visibilidad. Así mismo permitirá obtener estadísticas fiables de la producción científica financiada en España y será posible un mejor intercambio de información con otros repositorios y recolectores de información científica, haciendo accesible para la infraestructura de OpenAIRE la información de financiación cuando corresponda. Ejemplos:

dc:relation.projectIDinfo:eu-repo/grantAgreement/ES/PIE16/00021</dc:relation>

dc:relationinfo:eu-repo/grantAgreement/EC/FP7/340177</dc:relation>

3 https://guiasopenaire4.readthedocs.io/es/latest/#directrices-de-openaire-para-administradores-de-repositorios- de-literatura-v4

12

✔ No debe confundirse la referencia de proyecto financiado (dc.relation.projectID) con la institución responsable de la financiación del mismo (dc.contributor.funder). ✔ Es recomendable que los nombres de las instituciones o agencias financiadoras se escriban de forma completa y, en su caso, con sus siglas correspondientes. En caso de múltiples entidades responsables del apoyo financiero, se debe repetir el metadato tantas veces como sea necesario. Ejemplos:

  • <dc.contributor.funder>Instituto de Salud Carlos III - ISCIII</dc.contributor.funder>
  • <dc.contributor.funder>European Research Council</dc.contributor.funder> b) Inclusión del Perfil público CVN en aplicaciones institucionales El objetivo de desarrollar la funcionalidad de hacer público el CVN de un investigador es el de facilitar la consulta de los datos curriculares contenidos en los ficheros CVN -PDF. Esta opción posibilita que un currículo CVN albergado en la aplicación del Editor de FECYT (https://cvn.fecyt.es/editor/) pueda ser consultado -en su formato PDF (o de lec tura) y XML (o de explotación del metadato) - por otras personas a través de una URL, siempre que su titular así lo autorice, “perfil público del editor CVN-FECYT”. El enlace de descarga conecta directamente con la versión exportada del CVN -PDF que se encuentre disponible al público de manera online. De esta forma, el propietario del CVN puede difundir la URL para su visualización, divulgación, etc. y las entidades certificadas en este estándar curricular pueden optar por enriquecer sus sistemas informáticos con los datos que los investigadores hayan querido hacer públicos de su currículum.

13

Figura 3: Cómo publicar un CVN desde el Editor de FECYT. Fuente: https://cvn.fecyt.es
Por otro lado, la FECYT ha desarrollado además una interfaz API 4 para que las instituciones certificadas en esta funcionalidad puedan consultar los perfiles públicos existentes en el editor.
Las instituciones certificadas pueden conocer la URL del perfil público de los investigadores de los que dispone en sus diferentes aplicativos institucionales como pueden ser los repositorios, sistemas de gestión curricular o los sistemas CRIS institucionales. Una de las aplicaciones más directas de esta funcionalidad es la visualización de los currículos de los investigadores dentro de las publicaciones presentes en los repositorios, de forma que aumenta la visibilidad de los investigadores y les permite localizar a investigadores con un determinado perfil.
Con esta funcionalidad se maximiza la interoperabi lidad entre los diferentes sistemas, por lo que la FECYT recomienda a los repositorios, a las aplicaciones CRIS institucionales y a los sistemas de gestión curricular enlazar con esta API. Para ello, los interesados deben escribir a [email protected] solicitando su acceso. c) Herramientas de edición electrónica para las revistas académicas Las revistas académicas son la principal vía de comunicación para difundir resultados de investigación. Con la edición elec trónica las formas de comunicar y transmitir esos resultados no se limitan ya a volcar unos contenidos determinados en un documento pensado para ser leído por otras personas . Ahora, además de eso, hay que tener en cuenta que las máquinas

4 Más información en el apartado IV.c) Mejoras en CVN: API de consulta de los datos públicos de CVN

14

también acceden a esos documentos y, de manera muy concreta, a los metadatos que acompañan a esos textos. Lo hacen para recopilar información y ponerla después a disposición de los lectores y de los gestores y lo hacen también para auditar distintos elementos (no solo de co ntenido) con intereses diversos. Desde hace ya tiempo la comunicación científica se desarrolla en Internet, por eso la correcta implementación de ciertas herramientas de edición electrónica y la aplicación de ciertos estándares técnicos deben considerarse indicadores de buenas prácticas. Estos contribuyen a la difusión de la publicación y, al mismo tiempo, fomentan la transparencia permitiendo, además del cosechado de datos, la auditoría de diferentes agentes facilitando con ello el trabajo de indexadores, agregadores de contenido , evaluadores, etc. Hoy en día, el editor de una revista científica, además de cuidar la edición del texto, su maquetación y su difusión por los medios impresos tradicionales (si los mantiene), debe prestar especial atención a los m etadatos que genera de cada artículo y a cómo los ofrece no solo a la comunidad investigadora, sino a toda la sociedad. Por ello, debe saber manejarse en un mar de siglas y nombres más o menos complejos (OJS, APIs, plugins, OAI-PMH, Dublin Core, etc.) que son las herramientas que le van a permitir difundir sus contenidos de una forma organizada, compatible y (más o menos) controlada. Las revistas actuales ofrecen sus contenidos en dos niveles diferenciados: por un lado, se ofrece el texto completo de las co ntribuciones. Para ello, los formatos más habituales son el PDF y el HTML y, cada vez más, el etiquetado en ficheros de formato XML (el más extendido es el estándar NISO JATS - Journal Article Tag Suite). Por otro lado, se ofrecen los metadatos de la propia revista, de la editorial y de cada uno de los textos publicados. Para ello, es fundamental contar con una herramienta que permita la gestión del proceso de producción de las publicaciones y que, además, permita crear una página web desde la que servir to dos esos contenidos. Aunque no es la única, Open Journal Systems (OJS) es la herramienta más utilizada en España para este fin y la empleada en concreto para crear las páginas webs a las que se accede desde el portal Revistas Científicas del CSIC. Edición Electrónica. Serían muchos los temas que tratar en una guía de buenas prácticas para editores de revistas científicas. No es este el objetivo de este documento y, dado que ha surgido del trabajo realizado en el marco del proyecto INEOS, nos limitaremos a mencionar los elementos concretos que se han abordado en el marco del proyecto. INEOS ha sido un proyecto centrado en la Ciencia en Abierto y enfocado principalmente a los repositorios, aunque se ha dado cabida en él al editor. Si bien comparten elementos comunes y objetivos en algunos casos similares, repositorios y editoriales son entidades muy diferentes que utilizan herramientas también similares, pero adecuadas cada una a sus objetivos. El proyecto INEOS ha tenido una vertiente claramente técnica y, en ese aspecto, cabe señalar que el enfoque predominante ha sido el de los repositorios. Ha servido sin embargo para identificar objetivos comunes y tratar de buscar solucion es técnicas compatibles con ambos entornos. En el ámbito de la interoperabilidad, los metadatos y los identificadores persistentes se han obtenido buenos resultados relativos a los repositorios. Sin embargo, en el caso de las plataformas editoriales, (reco rdemos que hablamos exclusivamente de OJS) será necesario seguir profundizando en el futuro para poder implementar determinadas soluciones.

15

ORCID Aunque no es el único código existente, el ORCID, que permite identificar de manera unívoca a un autor con su producción científica, se utiliza cada día más en el ámbito de la literatura científica. Es deseable que las plataformas de las editoriales que lo utilizan muestren información relacionada con el ORCID de los autores. La versión 2.x de OJS ya permitía hace rlo y, por supuesto, esta posibilidad se mantiene con la 3.x. Sin embargo, al no existir una etiqueta específica para este código, no es posible ofrecerlo como metadato a través del OAI -PMH para que sea correctamente cosechado por RECOLECTA. CVN El lanzami ento de la nueva API de código de proyecto en el marco de INEOS permite la interoperabilidad de CVN con los metadatos de los proyectos depositados en los repositorios de RECOLECTA. Sin embargo, es necesario avanzar en la interrogación a la base de datos completa de RECOLECTA de forma que permita a los investigadores, cuando generen su currículum, incorporar las publicaciones existentes en RECOLECTA. Además, sería deseable integrar CVN con la plataforma OJS de edición de revistas. Esta integración permitiría a las revistas enlazar el perfil público de los investigadores existente en CVN con las publicaciones que estos investigadores hacen en las diferentes revistas a través de esta plataforma OJS de la misma forma que lo hacen los repositorios. Fuentes de financiación La interconexión de i nformación sobre fuentes de financiación ha sido uno de los ejes principales del proyecto. En lo que a publicaciones se refiere, la inmensa mayoría de las editoriales recoge en sus normas para autores, desde hace tiempo, la necesidad de mencionar esta información en el artículo. Por otro lado, las propias entidades financiadoras suelen indicar que esa mención es obligatoria en cualquier publicación derivada de una investigación financiada. No obstante, es habitual encontrar m enciones de este tipo con muy diversos formatos. Las revistas científicas deberían solicitar a sus autores que incluyan toda la información posible sobre financiación: la entidad financiadora con su nombre completo (y acrónimo, si se conoce), código del pr oyecto o contrato (si lo hay), el título del proyecto, tipo de contrato o beca , e incluir el de todas las entidades financiadoras con el mismo nivel de detalle cuando coinciden más de una en un mismo artículo. Para una revista , el primer paso
sería indicar a sus autores de forma detallada cómo y dónde deben incorporar esta información. El segundo paso sería el de procesar correctamente los metadatos extraídos de esa información para ofrecerlos a través de la web (como metadatos exportables vía OAI o archivos XML). Son muchas las instituciones financiadoras locales, nacionales e internacionales. No es sencillo estandarizar esta información y, para tratar de solucionarlo, la FECYT ha desarrollado, en coordinación con los repositorios que forman parte del proye cto INEOS, una API sobre códigos de proyectos basada en la codificación de OpenAIRE en la que se incluye el identificador persistente FundRef de Crossref. Mediante una consulta a esta API, el repositorio recibe el metadato estandarizado que, una vez colocado en una etiqueta concreta, garantiza su correcta recolección por parte de RECOLECTA. Nuevamente, será necesario seguir trabajando en el futuro para conseguir su compatibilidad con OJS , aunque cabe mencionar que existe ya un plugin para la versión 3 del p rograma de PKP que permite introducir los códigos FundRef en

16

una sección creada por el propio plugin, llamada “Datos de los fondos”, que aparecerá en los metadatos de los artículos. Activar este plugin sería algo adicional a la caja “Agencias de apoyo”, que sí es nativa de OJS.

Figura 4: Cómo enriquecer el metadato de la fuente de financiación en las publicaciones académicas. Fuente: CSIC. Datos de investigación Otro de los ejes principales del proyecto INEOS ha sido el tratamiento de los datos de investigación. Para Editorial CSIC ha sido, sin duda, el tema más novedoso y ha sido el que ocupado gran parte de nuestra actividad durante el proyecto. En primer lugar, intentamos definir qué son los datos de investigación, qué tipo de datos pueden obtener los autores con las investigaciones que se publican en nuestras revistas que abarcan múltiples áreas, materias y disciplinas: observacionales, experimentales, computacionales, compilados, derivados, de simulación, etc.