O Janium Collect produz registros: lê os documentos de um acervo e entrega registros estruturados no formato que a instituição usa —MARC21, ISAD-G, Dublin Core, CDWA. Mas um registro solto não é um catálogo. O catálogo é onde esses registros são consultados, relacionados entre si e, sobretudo, onde alguém que sabe catalogar os revisa e os corrige. Produzir o registro é uma parte; a outra é como ele chega ao catálogo —e, em um arquivo com hierarquia, o que é preciso fazer quando o catalogador corrige um registro que pende de um fundo.
Como os registros chegam ao catálogo
Há duas maneiras de levar os registros do Collect ao sistema de catálogo, e qual convém depende de como a instituição está montada e do que o seu catálogo expõe. Não é preciso escolher uma como “a correta”; são respostas a situações distintas.
A primeira é a sincronização direta via API, o que chamamos de modo conectado. O Collect envia os registros ao catálogo através da sua interface de serviços. É o caminho mais imediato: quando o catálogo está acessível na rede e oferece os pontos de entrada necessários, os registros se propagam com pouca demora. Encaixa-se bem quando os dois sistemas convivem na mesma infraestrutura ou há conectividade estável entre eles.
A segunda é a troca por arquivos sobre SFTP, por meio do plugin Janium. Em vez de chamadas ao vivo, o Collect deposita os registros como pacotes numa pasta que o catálogo recolhe, e o catálogo devolve uma confirmação do que processou. Esse caminho serve quando não há —ou não se quer— uma conexão direta entre os dois sistemas: o arquivo é a fronteira, e cada lado a cruza no seu ritmo. Em troca dessa independência, tem a sua própria latência: os pacotes viajam nos ciclos de envio, recolhimento e sondagem que tenham sido configurados.
A volta existe para manter a hierarquia
Para a maioria dos registros, carregá-los é o fim do trajeto. O catalogador os revisa e os corrige no catálogo, e ali fica: uma monografia em MARC, um registro em Dublin Core, uma obra em CDWA são registros independentes, e uma vez carregados o catálogo é a autoridade. O Collect não precisa saber dessas correções e, de fato, pode purgar esses registros quando o trabalho termina.
Há um caso em que sim importa que a correção volte: os arquivos hierárquicos descritos em ISAD-G. Ali os registros não são independentes: pendem de uma estrutura de fundo, seção e série, e parte da descrição dos nós superiores se monta subindo o que os documentos que pendem deles compartilham —o bubble-up—. Se o catalogador corrige um dado de um documento que participa dessa subida, o nó superior fica defasado em relação aos seus filhos.
Por isso, em um arquivo hierárquico, a correção feita no catálogo volta ao Collect, que a aplica sobre a sua cópia e recalcula a hierarquia: volta a subir aos nós pais o que corresponde, de modo que o fundo e a série continuem refletindo os documentos que contêm. Esse recálculo do bubble-up é a razão de o Collect conservar os registros do arquivo enquanto está ativo, e a razão de existir o trecho de volta. Em um catálogo plano, sem hierarquia para recalcular, não há nada a sustentar deste lado.
O que volta, e o que o Collect faz com isso
Uma correção é uma mudança pontual sobre um registro identificado: atualizar o valor de um campo, eliminar um dado que sobrava, acrescentar um que faltava. Cada registro viaja com um identificador que ambos os sistemas reconhecem, de modo que a correção se aplica sobre o registro correto e não sobre outro parecido.
Quando essa correção chega ao Collect, substitui a cópia local do registro —o catalogador é a autoridade, não se reprocessa com o modelo—, os dados derivados que dependem dele, como as pessoas e as datas, são reindexados, e o bubble-up é recalculado para os nós dos quais esse documento faz parte. O efeito é que a revisão humana feita no catálogo não fica só no topo: a descrição do fundo e da série continua coerente com a dos seus documentos, sem que ninguém tenha de refazê-la à mão.
Limites
Este mecanismo depende de o catálogo de destino expor a interface correspondente. Para a sincronização via API, o catálogo tem de oferecer os pontos de entrada para receber registros e emitir correções. Para a troca por arquivos, é preciso o espaço SFTP acordado e que o catálogo gere as confirmações e as correções no formato esperado. Com um catálogo que não expõe nenhuma das duas coisas, o Collect igual produz os registros, mas a carga volta a ser um trabalho manual.
O trecho de volta, além disso, só faz sentido onde há hierarquia a manter. Para um acervo plano —bibliográfico, uma fototeca em Dublin Core, uma obra em CDWA— não há bubble-up a recalcular: carregar o registro é tudo, e a correção vive no catálogo. Prometer um “ciclo fechado” ali seria inventar um problema que esse acervo não tem.
O outro limite é a latência do canal de arquivos. Se a instituição precisa que uma correção se reflita em questão de segundos, a troca por arquivos não é o caminho; ali convém a via API. Se os ciclos por lote são aceitáveis —e para muitos fluxos de catalogação o são—, o canal de arquivos oferece em troca não exigir uma conexão direta entre os dois sistemas.
Para continuar a conversa
Se a sua instituição descreve um arquivo em ISAD-G e quer que as correções dos seus catalogadores se reflitam na hierarquia sem refazê-la à mão, ou se simplesmente busca carregar no catálogo o que o Collect produz, a pergunta concreta é qual interface esse catálogo expõe hoje —uma API, um espaço de troca de arquivos, ou nenhuma ainda— e se o acervo tem hierarquia a manter. É disso que depende qual integração se aplica. Escreva para info@janium.com e revisamos para o seu caso.