Probando OJS 3.1.2 : Categorías y colecciones

Tal y como advierten en su página oficial PKP ha liberado recientemente una nueva versión estable de OJS3 (https://pkp.sfu.ca/2019/03/01/ojs-3-1-2-released/). Entre las mejoras que aporta la nueva versión nos ha llamado poderosamente la atención una funcionalidad que permite crear categorías en las revistas y generar colecciones temáticas para vincular diferentes artículos publicados en distintos números.

Hemos testado la funcionalidad y los resultados son prometedores. Una vez instalado y activado el plugin Browse, OJS nos permitirá crear categorías en Preferencias → Revista → Categorías.

Su edición es muy similar a otras funcionalidades de OJS3 (e.g., Avisos, etc.). Así, podemos cargar el nombre de la categoría, anidarla en otras categorías previas, cargar el path, una descripción, imagen, etc.

Una vez editada será necesario activar un nuevo plugin para visibilizarlas en el lateral de nuestra revista, Browse Block.

Su gestión, como el resto de bloques, deberá realizarse desde el panel de gestión de bloques (Preferencias → Sitio web → Apariencia → Gestión de la barra lateral).

Otra posible solución para visibilizar las colecciones sería trabajar el menú superior de navegación (añadiendo un nuevo ítem de menú enlazado a una categoría padre). En su estado actual nos parece que no es una solución muy recomendable, dado que exige generar estructuras más complejas de categorías/subcategorías y configurar el item de menú como url externa (ruta absoluta).

La asociación de artículos a las categorías, finalmente, se realiza desde los Metadatos de cada envío.

Traduciendo la interfaz de trabajo de OJS3

Lamentablemente la nueva versión de OJS (v3) contiene partes del sistema aún no traducidas o mal traducidas al castellano.

Gracias a la instalación del plugin Translator, los administradores pueden traducir directamente desde la interfaz de trabajo sin necesidad de descargar y cargar los archivos de instalación que contienen las cadenas de caracteres no traducidas o mal traducidas. En esta entrada te explicaremos cómo trabajar con este plugin,

El proceso de instalación y carga de traducciones o refinamiento de traducciones es bien sencillo. El usuario debe ir a Preferencias → Sitio Web → Módulos y desde allí, acceder a la Galería de módulos para localizar el plugin Translator (https://github.com/pkp/translator).

Una vez instalado el usuario deberá acceder a la lista de módulos y plugins instalados, localizarlo, activarlo y hacer clic en el enlace Traducir. De ese modo podrá acceder a los archivos de traducción y editar directamente el contenido del componente que desea actualizar.

Para ello, en primer lugar, deberá seleccionar el idioma de trabajo. En las capturas que siguen se muestra el proceso completo para cargar traducciones en castellano/español.

1) Clic en el botón Editar.

2) Seleccionar el archivo xml donde figura el componente/cadena de caracteres que desea editarse. En el ejemplo, se va a proceder a cargar la traducción de los componentes que figuran al inicio del post (ventana emergente que le permite al editor tomar la decisión editorial de enviar a revisión un artículo):

##editor.review.newReviewRound##

La propia cadena de caracteres aporta pistas de gran valor para localizar el archivo xml que debe editarse (editor.xml). Para acceder a él el usuario deberá hacer clic en el enlace Editar.

3) Una vez accedido al archivo xml el usuario deberá localizar en el fichero el componente a editar (editor.review.newReviewRound), cargar la traducción y guardar cambios.

Implantación OJS3 de la Revista de Fomento Social (Universidad Loyola Andalucía)

Os animamos a visitar y consultar los contenidos de la Revista de Fomento Social de la Universidad Loyola Andalucía. En los últimos meses hemos trabajado con los responsables de la Biblioteca Universitaria en los procesos de implantación, configuración, ingesta de números y artículos, formación y diseño de la publicación en OJS3x (BootStrap Theme personalizado).

Durante los próximos meses seguiremos colaborando con los responsables de la publicación para profundizar en las tareas de internacionalización (i.e., indexación y traducción), ampliación funcional de la revista (i.e., instalación/configuración de plugins DOI/CrossRef, etc.) y nuevos procesos de ingesta de metadatos.

OpenAIRE. Estado del arte en OJS

En las versiones 2.4x y 3.0x  está disponible el plugin OpenAIRE,  no habiendo diferencias funcionales entre versiones 2.4x y 3.0x en lo que respecta a la adaptación del interface OAI-PMH a los requisitos de OpenAIRE3.  La versión 1.1 de este plugin para sendas versiones de OJS funciona correctamente generando los metadatos dc.relation y dc.rights requeridos.

El panorama es distinto en lo que se refiere a OpenAIRE 4, que fue publicado como borrador abierto a consulta pública en noviembre de 2017. Este nuevo «estándar» incorpora como principales novedades un nuevo perfil de aplicación y un nuevo esquema basado en el soporte de Dublin Core y DataCite.

Sus pautas están destinadas, como subraya el borrador, a lograr que los sistemas de almacenamiento, depósito o divulgación de publicaciones OA,  mejoren su mecanismos de identificación para autores, organizaciones, financiadores y recursos académicos y por tanto mejorar la interoperabilidad  del sistema de ciencia global.  Recalcar que la compatibilidad OpenAIRE 4, al igual que lo fue OpenAIRE3,  será objetivo, no sólo de los sistemas de ciencia europeos (investigación financiada por la CE) sino que ha sido adoptado por los sistemas nacionales, por el sistema de recolección latinoamericano (LA Referencia) y su aceptación o adherencia a sus especificaciones posiblemente se incremente en breve plazo….

Hasta la fecha, entre los principales cambios entre OpenAIRE3 y OpenAIRE4, nos encontramos varias cualificaciones y refinamientos de metadatos esenciales de identificación de autores, con el uso de ORCID iDs para la referenciación de los investigadores.

Igualmente importante es la introducción de nuevos elementos de metadatación (e.g., fundingReference) o los numerosos cambios de sintaxis introducidos en los propios metadatos (uso de vocabularios COAR, etc..).

Evidentemente, el nuevo OpenAIRE4 va a demandar de los sistemas OJS una adaptación sustancial de la información recogida y posteriormente expuesta a otros sistemas recolectores. Seguiremos con especial atención la información publicada en PKP y OpenAIRE sobre el futuro desarrollo del plugin e integración en los sistemas OJS 3.x.

Visibilidad de información de configuración en OJS3

Nos parece interesante postear aquí una inquietud trasladada por algunos de nuestros alumnos –cursos OJS3– a propósito de la visibilidad de contenidos de configuración en OJS3. Ciertamente, el comportamiento de las plantillas/temas de OJS3 y el tratamiento que realiza sobre la visibilización de información en la interfaz de acceso y consulta de las revistas -FrontOffice- no difiere en gran modo de algunos temas responsivos de OJS 2.4x con los que hemos trabajado estos últimos años.

Algunas plantillas responsivas 2.4x ofrecían un tratamiento diferente de la información cargada durante los 5 pasos de Configuración (e.g., elementos que presentaban disfuncionalidades, diferencias de visualización, etc.). OJS3, en lo que respecta a este asunto, al igual que estas plantillas, hace un tratamiento diferente en varios elementos en función del tema/plantilla cargado (e.g., declaración de privacidad, visibilidad de la descripción de la revista en la portada de la propia revista, etc.).

Como sabéis, los formularios de configuración en OJS3 han flexibilizado la carga de este tipo de contenidos con elementos agregadores de información como “Acerca de la revista” donde pueden introducirse contenidos en versiones 2.4x dispersos en varios elementos (e.g., aviso de derechos de autor, historia de la revista, declaración de privacidad…). Algunos de ellos, con el tema default, se duplican en diferentes lugares del OJS3 o bien, directamente, no aparecen.

Lo cierto es que, ante posibles migraciones y evoluciones del sistema a versiones 3.0x, recomendamos en primer lugar identificar qué información es sensible para la revista y puede quedar invisibilizada con el tema default, analizar el tratamiento de la información de partida con las plantillas Bootstrap3 u otras plantillas responsivas ya liberadas, etc.

Por debajo de una simple migración puede haber jornadas de desarrollo para aflorar contenidos de interés, ubicación de elementos (bloques), etc. que bien podrían estar resueltos total o parcialmente en otras plantillas/temas.