OJS 3.6 JATS SciELO: o que revisar antes de produzir

OJS 3.6 JATS SciELO: o que revisar antes de produzir

O OJS 3.6 JATS SciELO não é uma decisão de ativar uma saída e deixar de olhar o arquivo. A versão proposta pelo PKP transforma o conteúdo da submissão em HTML editável e permite gerar JATS a partir desse HTML; para uma revista que trabalha com a SciELO, o passo útil é verificar o perfil de saída e o pacote antes de incorporá-lo ao ciclo editorial.[1]

A pergunta correta não é se uma saída JATS é suficiente por si só. Convém separar três níveis: XML JATS válido, conformidade com o SciELO Publishing Schema (SciELO PS) e controle editorial do artigo. Cada nível detecta riscos distintos e exige evidências distintas.[2][3]

Diagrama próprio. Cada controle deixa seu próprio relatório e seu responsável; nenhum substitui os demais.

OJS 3.6 JATS SciELO: controle o HTML de partida

A geração de JATS no OJS 3.6 se apoia em uma cadeia de transformação, não em uma correção automática das informações editoriais. O PKP descreve a passagem de DOCX para HTML editável do corpo do artigo, junto com metadados estruturados armazenados no OJS. Também indica que essa conversão gera HTML compatível com JATS, a partir do qual o mapeamento para JATS e sua atualização são diretos.[1]

Essa arquitetura tem uma consequência prática: a equipe não deveria revisar apenas o XML final. Deve abrir o HTML que serviu de fonte, compará-lo com o manuscrito aprovado e confirmar que os elementos importantes para a revista ficaram expressos de forma inequívoca. Um título com hierarquia confusa, uma tabela mal interpretada ou uma imagem sem descrição podem entrar na cadeia antes de o XML aparecer.

O PKP adverte que estilos complexos ou atípicos podem não ser transformados perfeitamente, embora a ferramenta continue melhorando. Por isso, a primeira amostra não deveria conter apenas artigos simples. É preferível incluir um texto com seções, citações, tabela, figura, equação se a revista as publica, autores com afiliações e referências de formas distintas. O objetivo é saber o que a saída faz com material que representa a prática editorial real.[1]

A mesma fonte estabelece um limite importante: o fluxo centrado em JATS, em que uma entidade externa cria o JATS a partir de DOCX e esse XML passa a ser a fonte para HTML e PDF, não está incluído no OJS 3.6. Isso não impede usar produção externa; evita confundir o fluxo HTML do OJS com aquele esquema de produção.[1]

Distinga XML JATS válido, SciELO PS e QA editorial

Um XML JATS válido responde a uma gramática JATS determinada. O repositório do plugin JATS Template do PKP indica que, desde o OJS 3.6.0.x, o plugin gera XML JATS 1.2 válido. Essa condição é valiosa como prova de estrutura, mas não transforma por si só o arquivo em um pacote ajustado a outro perfil de intercâmbio.[2]

A SciELO descreve outra exigência: o XML de que precisa deve estar em conformidade com o SciELO Publishing Schema. Sua documentação explica que esse esquema reúne a DTD JATS 1.0, as especificações do PMC e o estilo SciELO; ou seja, especializa aspectos da especificação para o envio de documentos.[3]

O terceiro nível é editorial. Um arquivo pode respeitar uma gramática e, ainda assim, trazer uma referência incompleta, uma afiliação atribuída à pessoa errada, uma figura com legenda insuficiente ou uma data que não corresponde à decisão editorial. Nenhuma dessas situações se resolve olhando apenas uma mensagem de validação estrutural. A revisão deve comparar a saída com a versão aprovada e com os dados que a revista decidiu publicar.

A diferença também aparece no próprio plugin do PKP. Seu README explica que ele entrega um modelo básico quando não há um JATS de maior qualidade disponível e que não se destina à publicação sem melhorias e sem um controle de qualidade considerável.[2] Leia isso como um sinal de alcance: «válido» descreve uma condição técnica; não substitui uma revisão de conteúdo, estilo ou empacotamento.

Defina o perfil de saída antes de gerar o primeiro arquivo

O perfil de saída é a especificação operacional que a revista fixará para avaliar cada resultado. Não basta dizer «JATS». Escreva qual versão, quais elementos editoriais devem estar presentes, como os identificadores serão representados, que informação será mantida para figuras e tabelas, que forma as referências devem ter e quais documentos acompanham o XML.

Esse perfil deve unir três referências: as decisões editoriais da revista, o comportamento observado da transformação HTML–JATS do OJS e as regras do SciELO PS que correspondam ao pacote que será preparado. Não presuma que um dado visível no OJS aparece igual no JATS. O PKP diz expressamente que os metadados do JATS e o banco de dados do OJS não estão vinculados; por isso, uma mudança no OJS não será refletida no JATS.[1]

Esse ponto merece um controle de versões. Antes de publicar, anote qual mudança foi feita no OJS, quando a saída foi gerada de novo e qual arquivo foi revisado. Se o título, a autoria, o DOI, uma referência ou um dado de licença for corrigido depois de gerar o JATS, gere de novo e compare de novo. Assim se evita aprovar uma cópia e carregar outra.

Uma orientação breve para o perfil de saída pode incluir:

• dados bibliográficos que devem coincidir entre OJS, HTML e XML;
• estrutura do corpo: título, resumo, seções, tabelas, figuras e referências;
• tratamento de afiliações, identificadores e notas de autoria;
• elementos que exigem revisão humana conforme a tipologia da revista;
• versão da saída, responsável pela revisão e evidência de validação.

Revise o pacote, não apenas o XML isolado

Para a SciELO, a unidade prática de revisão não é uma etiqueta solta. A documentação da SciELO indica que o Package Maker informa possíveis problemas, renomeia arquivos conforme o padrão SciELO PS e os separa em pacotes. O StyleChecker, por sua vez, entrega um relatório detalhado da conformidade de um XML com o SciELO PS.[3]

Por isso, a revista deve testar a construção do pacote completo: nome e localização dos arquivos, XML, ativos gráficos, tabelas ou material complementar se houver, e coerência das referências a esses ativos. A revisão do pacote responde a perguntas que uma verificação isolada não cobre: o XML aponta para o recurso correto? Cada nome se ajusta à convenção exigida? A evidência de validação corresponde a essa mesma versão do artigo?

Use as ferramentas da SciELO como controles de conformidade do perfil, não como uma declaração de aceitação. Sua documentação indica que ambas são usadas na produção e na publicação conforme o SciELO PS, e que a validação se mantém em cada envio mesmo após a certificação de um fornecedor.[3] Para a revista, a conclusão operacional é mais sóbria: guarde o relatório, corrija o que ele indicar e execute-o de novo sobre o pacote gerado novamente.

Execute uma amostra de teste com casos que tensionem o fluxo

A amostra de teste deve se parecer com o material que dará mais trabalho, não com um artigo ideal. Escolha artigos já aprovados para um teste interno, sem publicá-los pelo novo fluxo até concluir a revisão. Inclua variedade de estrutura, material gráfico, autores com várias afiliações e referências de tipos diversos. Se a revista usa resumos em mais de um idioma ou suplementos, acrescente-os à amostra.

A sequência recomendada é simples:

1. Defina o perfil de saída e uma planilha de comparação.
2. Gere HTML e JATS a partir de uma cópia controlada do artigo.
3. Revise visualmente HTML e PDF quando fizerem parte do fluxo, contra o documento editorial aprovado.
4. Valide o XML contra a condição JATS que a ferramenta declara.
5. Construa e revise o pacote com as ferramentas da SciELO correspondentes.[3]
6. Corrija na fonte adequada, gere de novo e repita os controles.
7. Guarde XML, pacote, relatórios e decisão editorial sob uma versão identificável.

Não pule do passo 2 para o 5. Se o problema nasce no conteúdo ou na transformação para HTML, corrigir apenas o XML pode criar divergências entre arquivos. A fonte do PKP apresenta o HTML como a fonte canônica de produção para gerar as saídas; essa é uma razão prática para localizar primeiro onde a diferença se originou.[1]

Organize os controles por responsável e por momento

A qualidade melhora quando cada controle tem um responsável e um momento definidos. O editor ou a editora valida conteúdo, metadados visíveis, autoria e referências contra a versão aprovada. A pessoa responsável pela produção revisa estrutura, arquivos associados, saída HTML/PDF e relatórios técnicos. Quem administra o OJS verifica se a versão carregada é a aprovada e se uma modificação posterior não deixou o XML desatualizado.

O relatório técnico não substitui uma decisão editorial. A revisão editorial tampouco deve ocultar um problema de empacotamento. Uma lista de liberação deve ter campos separados para: coincidência editorial, validade JATS, conformidade SciELO PS, integridade do pacote e versão final carregada. Quando um campo falha, o artigo volta à etapa que pode corrigi-lo.

Associe este controle ao seu guia de automação editorial e à revisão de erros de XML JATS. São apoios para documentar o fluxo interno; não substituem a evidência do arquivo e do pacote revisados.

Erros comuns que convém evitar

O primeiro erro é tratar “JATS válido” como sinônimo de “conforme ao SciELO PS”. São verificações relacionadas, mas não equivalentes: uma olha a gramática JATS; a outra confronta o arquivo com o esquema e o estilo da SciELO.[2][3]

O segundo é modificar metadados no OJS depois de gerar o XML e presumir sincronização. O PKP informa que os metadados do JATS e o banco de dados do OJS não estão vinculados.[1] A medida concreta é gerar de novo, comparar e arquivar o novo relatório.

O terceiro é testar com um único manuscrito simples. Esse resultado não mostra como a cadeia responde a figuras, tabelas, estilos complexos ou referências variadas. O PKP reconhece limites de transformação para estilos complexos ou pouco usuais.[1]

O quarto é separar validação técnica e revisão editorial como se uma bastasse. O plugin de modelo básico do PKP exige melhorias adicionais e controle de qualidade antes de se destinar à publicação.[2]

Conclusão: uma saída utilizável se demonstra com evidências

O OJS 3.6 abre um caminho para gerar JATS a partir de HTML editável e manter um fluxo de arquivos mais integrado.[1] Para uma revista que opera com a SciELO, a decisão responsável é transformar essa capacidade em um teste controlado: perfil de saída escrito, amostra representativa, validação JATS, revisão contra o SciELO PS, verificação do pacote e controle editorial da versão liberada.[2][3]

O resultado buscado não é uma afirmação geral sobre compatibilidade nem uma promessa de aceitação. É uma evidência repetível de que a revista pode revisar, corrigir e documentar cada saída antes de usá-la em produção.

Perguntas frequentes

O OJS 3.6 pode gerar XML JATS a partir de HTML?

O PKP descreve um fluxo em que o corpo do DOCX é convertido em HTML editável e compatível com JATS, com geração de JATS a partir dessa base.[1] Antes de depender dessa saída, teste-a com artigos representativos da sua revista e revise o resultado completo.

Um XML JATS válido já cumpre o SciELO PS?

Não são a mesma verificação. O PKP informa validade JATS 1.2 para seu plugin desde o OJS 3.6.0.x, enquanto a SciELO exige conformidade com o SciELO Publishing Schema.[2][3] Execute a validação do perfil SciELO e guarde o relatório junto com o pacote.

O que devo guardar depois de validar uma amostra?

Guarde a versão do artigo usada, o HTML e o XML gerados, o pacote, os relatórios das ferramentas, a lista de verificação editorial e o registro de correções. Essa evidência permite saber o que foi avaliado e repetir a verificação se o conteúdo ou os metadados forem modificados.

Produção especializada quando o fluxo exige mais controle

Se sua equipe precisa de uma camada de produção especializada, o Jatson se apresenta como um complemento entre o manuscrito e a publicação: recebe o conteúdo-fonte, o estrutura, o valida e o converte em XML JATS, PDF editorial e Scholarly HTML para o OJS.[4] Pode ser uma alternativa a avaliar quando a revista busca separar a produção especializada da administração cotidiana do OJS. Solicite uma avaliação do fluxo e do pacote de que sua revista precisa, sem presumir resultados antes de revisar uma amostra.

Fontes

1. PKP, Upload, Transform, Publish: Inside OJS 3.6’s File Production and Toolset — consultado em 2026-10-23.
2. PKP, JATS Template Plugin — consultado em 2026-10-23.
3. SciELO, Perguntas Frequentes Sobre a Adoção de XML — consultado em 2026-10-23.
4. OJS ONE, Marcação XML JATS para a SciELO Chile — consultado em 2026-10-23.