Outra situação recorrente era a grafia de sobrenomes de autores em caixa alta. Este procedimento não é uma norma do AACR2, mas é uma regra para elaboração de referencias bibliográficas, a ABNT NBR 6023/2002. Como muitos sistemas não alteravam os dados de minúsculo para maiúsculo no momento de fazer a referência, a solução encontrada por muitas bibliotecas foi adotar que as autoridades de pessoas seriam registradas com os sobrenomes em caixa alta. Desta forma, era garantido que a referência seria exibida da forma correta. Com a publicação dos catálogos na internet, a visualização de nomes em caixa alta (gritados, de acordo com o código de comunicação da internet), não é favorável ao OPAC (Online Public Access Catalogue), alterando o tamanho das letras apenas no momento de gerar a referência do registro consultado.
Quando a questão da migração é encarada nos dias de hoje, aqueles anos “selvagens”, onde os registros deveriam ser desbravados e muito trabalhados, ficaram para trás. Hoje boa parte das bibliotecas brasileiras já utiliza sistemas que são aderentes ao formato e uma migração ocorre, na maioria das vezes, de MARC para MARC. A substituição de um ILS (Integrated Library System – Sistemas Integrados de Bibliotecas) por outro é bem mais suave do que já foi no passado, mas isso não significa que, por não utilizar o MARC como formato de metadados, os registros de uma biblioteca não possam ser aproveitados e migrados. O formato MARC é utilizado como parâmetro para adoção de sistemas, pois ele permite que uma ferramenta seja substituída por outro de forma segura, garantindo que os dados armazenados não sejam perdidos em uma conversão retrospectiva (CAFÉ, SANTOS E MACEDO, 2001, p.74).
Muitas bibliotecas ainda utilizam o Winisis, sistema distribuído de forma gratuita pela Unesco. Ele não utiliza o formato MARC (se bem que alguns bibliotecários corajosos tentam fazer isso, criando tags e subcampos e controlando seu uso de forma manual, principalmente ao trabalhar os termos adotados). Isso não significa que uma biblioteca que usa o Winisis e decide migrar para outro sistema não possa aproveitar seus registros e migrá-los. Quando uma biblioteca opta por utilizar um sistema que se utiliza de padrão de metadados definido, o legado deve ser mapeado para que exista aderência ao formato escolhido, preservando os dados existentes.
O PHL é um sistema oferecido de forma gratuita ou pago, de acordo com a quantidade de unidades de uma rede. Este sistema, bastante utilizado por bibliotecas brasileiras, não utiliza o formato MARC, mas a Metodologia Lilacs, um componente da BVS (Biblioteca Virtual da Saúde) constituído de normas, manuais, guias e aplicativos, destinados à coleta, seleção, descrição, indexação de documentos e geração de bases de dados. O fato de uma biblioteca utilizar o PHL não significa que os dados não podem ser migrados, sendo realizado o mapeamento necessário para identificação dos registros em seus campos e níveis bibliográficos distintos.
Em outras palavras, por mais que uma biblioteca utilize um sistema que não seja aderente ao formato MARC não significa que a migração não é possível. A decisão de abdicar dos registros e iniciar uma catalogação do zero deve ser adotada apenas como última opção, quando todos os recursos já foram esgotados.
Segundo Vasconcellos (apud ZAFALON, 2012, p.60) o processamento técnico e o registro de informações bibliográficas são as atividades mais caras em um processo de automação, por isso é fundamental garantir que os dados em meio digital sejam (re)utilizados.
De acordo com Watson (2001), existem cinco razões porque uma biblioteca deve participar de programas de catalogação cooperativa:
1) Porque é caro;
2) Porque é trabalhoso;
3) Porque envolve custos excessivos;
4) Porque é uma atividade morosa;
5) Porque recatalogar uma obra é desanimador aos bibliotecários.
Não estamos abordando neste artigo a catalogação cooperativa, mas estes motivos são aplicáveis à migração e reaproveitamento de registros de sistemas legados. A este conjunto, acrescentaria mais duas razões:
1) Porque o histórico da biblioteca não pode ser descartado: ao abrir mão de seus registros o bibliotecário está excluindo informações de uso de seu acervo, frequência dos usuários, obras consultadas, pouco ou nunca consultadas, obras extraviadas e demais informações que registram a história de um acervo e sua utilização;
2) Porque o trabalho feito não pode ser descartado: por maior que seja a quantidade de equívocos realizados na descrição de metadados (forma e conteúdo), as informações devem ser preservadas porque foram investidos tempo e dinheiro na elaboração destes registros e devem-se maximizar as possibilidades de reaproveitamento do legado.
A decisão de descartar completamente um legado deve ser tomada quando:
1) Os dados não apresentam nenhum tipo de padrão que permita mapeamento para campos e subcampos de formato de metadado;
2) Apesar de existir certo padrão, a quantidade de registros errados será tão expressiva que é preferível criar registros novos;
3) A inconstância dos marcadores utilizados gerará novos erros durante o processo migratório.
Se a biblioteca definiu que fará a migração dos dados e empreenderá esforços para corrigir os registros com erros, deve estipular um período de trabalho e método para correções, priorizando o tratamento das autoridades, normalmente armazenadas em tabelas controladas, que permitem a correção em lote de diversos registros bibliográficos.
Caso a biblioteca opte por realizar a importação de registros deve certificar-se que está utilizando-se de fonte(s) idônea(s) para não gerar novos erros na base. Utilizar-se de fontes que não possuem controle bibliográfico, padrão mínimo para descrição de registros e nível bibliográfico incompatível com a política descritiva adotada pela descrição é tão improducente quanto descartar o legado. Utilize-se de fontes consagradas (no Brasil: autoridades da Fundação Biblioteca Nacional, Academia Brasileira de Letras, Fundação Getúlio Vargas, Rede Bibliodata; no mundo: Library of Congress, British Library etc.). Lembre-se que quantidade de registros não significa qualidade ou muitas opções de dados para serem importados. A qualidade dos metadados deve ser considerada antes de realizar uma importação. Se o dado é incompleto ou incorreto (já vi, inclusive, registros em pré-catalogação oferecidos em rede colaborativa!), sua importação resultará em tantas correções que poderia ser mais prático realizar a catalogação sem importação. Se uma fonte de dados oferece muitas opções de descrição para um mesmo registro, desconfie! Isto significa que os dados não são padronizados, cada unidade participante faz a catalogação por critérios próprios e que não existe apuro ou procedimentos de qualidade para aferir o processo.
É necessário ficar atento quanto a validação da migração realizada, verificando se correções foram feitas (muitas são possíveis) e se o processo não gerou novos erros. Nestes casos é preferível regredir alguns passos em melhorias automáticas e corrigir as imperfeições de forma manual.
Cabe uma ressalva que nenhum catálogo será 100% correto. Sempre existirão erros (pequenos ou grandes). Isto ocorre em todas instituições. Certa vez, ao realizar buscas sobre Harry Potter na British Library, deparei-me com duas entradas autorizadas para J.K. Rowling. Uma biblioteca inglesa, famosa por sua competência e qualidade cometeu um erro com uma autora inglesa! O problema foi corrigido e não figura mais no catálogo, mas isso comprova que não existe catálogo infalível. Cada biblioteca deve definir seu nível de qualidade e os “erros” aceitáveis em seu catálogo, caso contrário o processo de correção da base migrada será infinito, desanimador e improdutivo.
Evidentemente, quando falamos em formato é bom deixar claro que nem todas as informações são registradas no MARC. O formato é utilizado para estruturar os dados de autoridades e de registros bibliográficos, porém não as informações oriundas de circulações (empréstimos, devoluções, renovações, reservas etc.), dados de aquisição, patrimônio, inventário e demais dados que são controlados pelos ILSs, porém não são armazenados no MARC. Existem diversos campos e subcampos no MARC e, além dos oficiais, a Library of Congress permite que sejam acrescentados campos locais (os x9x) para descrever informações próprias para cada biblioteca. Com isso vemos muitas bibliotecas adotando a tag 949 para registrar dados de exemplares (tombo, código de barras, dados de aquisição etc.) ou incluindo notas locais (59x) para descrever particularidades de seus acervos. Isto não é o problema, afinal não foram criados campos não previstos no formato, mas adaptados de acordo com a (pequena) flexibilidade existente no MARC. Num momento de conversão, estes campos locais serão criados na nova base e convertidos sem problemas. A questão fica crítica quando campos (não locais) e subcampos são criados livremente, ferindo o formato definido. Por exemplo: um registro com tags 100 (entrada principal de pessoa) e 110 (entrada principal de entidade) simultaneamente. Ou então, duas tags 250 (edição) no mesmo registro, quando este campo é não repetitivo. Ou ainda, uma nota geral (500) com dois subcampos |a (a tag é repetitiva, mas o subcampo não). Um sistema de fato aderido ao formato MARC não deve permitir que tags sejam criadas livremente, com exceção dos campos locais. Um formato tem um padrão e padrões são seguidos fielmente. Seguir um padrão mais ou menos não é garantir aderência a um formato bibliográfico.
Que migrações de bases de dados são fascinantes, não resta a menor dúvida. Entendo que nem todos bibliotecários compartilham deste pensamento, mas enxergo-me como esta uma bibliotecária em 10 que gosta de migrar bases de dados e promover melhorias nos metadados. Alguém tem que gostar de fazer isso, afinal, o que seria do azul se todos gostassem do amarelo?
Referências
CAFÉ, L.; SANTOS, C.; MACEDO, F. Proposta de um método para escolha de software de automação de bibliotecas. Ciência da Informação, Brasília, v. 30, n. 2, p. 70-79, maio/ago. 2001. Disponível em: http://revista.ibict.br/index.php/ciinf/article/view/198/175. Acesso em: 16 out. 2013.
