Lá em 2014, eu e o Giuliano Ferreira conversamos sobre como poderíamos indexar nossos catálogos no Google. Depois ele apresentou um trabalho bacana no SNBU: “AUMENTANDO O ALCANCE E A VISIBILIDADE DE CATÁLOGOS ONLINE E REPOSITÓRIOS INSTITUCIONAIS COM A AJUDA DO GOOGLE.”. Então essa é uma idéia que estava martelando na minha cabeça desde aquela época.
Neste post vou mostrar o caminho que fizemos para tornar essa idéia algo real.
Atualmente temos um catálogo que pode ser indexado pelo google, mas não está sendo por uma questão importante, que é a limitação dele para receber muitos usuários. Começamos então a estudar uma maneira de contornar isso. E uma das soluções encontradas foi criar um OPAC independente, mas sincronizado, que possa receber toda a carga de uso sem sobrecarregar o sistema principal.
Desenvolvemos um software livre utilizando o ElasticSearch e PHP, muito inspirado no Vufind. O ElasticSearch, na minha opinião, é a melhor ferramenta de criação de índices e recuperação da informação no momento e PHP foi escolhida por ser uma linguagem simples, mas que é poderosa o suficiente.
A idéia principal por tras é pegar os registros MARC e transformá-los em JSON (formato padrão utilizado no Elasticsearch). Para os nomes dos campos, utilizamos o padrão schema.org. A vantagem em utilizar o Schema.org é que é um formato de metadados estruturados que o google utiliza, melhorando a indexação. O sistema tem em seu cabeçalho, os metadados estruturados no padrão JSON-LD utilizando o Schema.org.
É possível adaptar a aplicação para qualquer formato de entrada de metadados e sistema fonte de informação. E adaptar a interface para essa situação.
Atualmente temos 2 sistemas em produção utilizando esta lógica, ambos com os metadados catalogados em MARC, mas sendo sincronizados e oferendo uma forma alternativa de consulta:
Partituras da Universidade de São Paulo
Biblioteca Digital de Produção Intelectual da Universidade de São Paulo
Ainda não fizemos com o nosso catálogo principal.
Mas posso falar que são muitas as vantagens em indexar o catálogo no Google, mas a principal é ampliar a visibilidade de um acervo que até então o usuário teria que fazer uma busca individual em cada catálogo para saber que alguma instituição tem a obra que ele precisa. Essa lógica altera um pouco o fluxo de sistemas de busca federada.
Uma limitação ainda é que não controlamos totalmente o que é indexado, então não é possível garantir que o google irá indexar todos os seus conteúdos. Há estudos que mostram que o google tende a indexar somente uma porcentagem do conteúdo dos sites e nunca tudo. Então esta pode ser uma limitação importante a ser considerada.
6 respostas para “Indexação do catálogo no Google”
Tiago, é um post digno de reflexão. Com um olhar ‘apocalíptico’ pode se dizer que isso se tornar uma tendência, veremos o fim dos mecanismos de busca dos catálogos locais (nas instituições) e a ‘entrega plena’ da responsabilidade de recuperar os registros para o Google.
Falando sem exageros, é algo para refletir. Há cerca de 25 anos atrás os catálogos utilizavam plataformas de software implementavam seus próprios sistemas de armazenamento e recuperação de dados, interagindo diretamente com o sistema de arquivos, criando os chamados ‘arquivos de índice invertidos’, uma tecnologia usada por muito tempo por quem implementava softwares em linguagens como Clipper ou COBOL.
Posteriormente os desenvolvedores de software deixaram de lado esse tipo de tecnologia, ainda nos anos 90, pois estava obsoleta e era causa de muitos problemas relacionados à perdas e manutenção dos dados do sistema das bibliotecas. Quem lidou com softwares de bibliotecas nessa época se lembra do que estou falando.
A utilização de Sistemas de Gerenciamento de Banco de Dados – SGBD (ex: PostgreSQL, Oracle Database, MySQL, etc) passou ser algo indispensável para complementar as plataformas, e passaram a contar com serviços de armazenamento e recuperação dos dados do sistema da biblioteca com segurança e confiabilidade, e melhor, sem ter que desenvolver e controlar esses serviços. Os SGBD são usados até hoje por conta disso.
Outra mudança na recuperação: a adoção de softwares de mecanismos de busca para acelerar a recuperação de registros e desonerar o SGBD das plataformas do papel de recuperar dados. Softwares como o HTDIG e Apache SOLR se tornaram populares a partir dos anos 2000 e são distribuídos em boa parte das plataformas como mecanismo de busca. Assim, temos as plataformas compostas pelo Software da Biblioteca + SGBD + Mecanismo de Busca integrados como um único conjunto de serviços.
Agora, se abre o catálogo indexado nos mecanismos de busca locais para o Google. Ele os reindexa e oferta uma interface de busca diferente, com outras opções, de maneira simples e rápida.
Até quando a arquitetura ‘Software da Biblioteca + SGBD + Mecanismo de Busca’ permanecerá assim? Será que no futuro as plataformas passarão a usar serviços de recuperação da informação (efetivamente, a interface de catálogo para o usuário final) externos como o Google? Daqui 05 ou 10 anos retornaremos a esse assunto, acrescentando mais essa mudança nessa lista?
Divino. Ótimas colocações. Tenho certeza que em menos de 5 anos estaremos aqui discutindo não só novas estratégias de indexação como novas portas de entrada pro usuário realizar a pesquisa dele. E É assim que eu vejo esse assunto. Como estratégias e plataformas complementares aos OPACs E Sistemas gerenciadores de bibliotecas. Não vejo esses sistema morrendo pq precisamos de um lugar confiavel com padrão, seja o MARC ou um novo padrão para armazenar os metadados de forma correta, para que esses enfim possam ser disponibilizados em um arquivo JSON como fez o Tiago, pras outras engines indexarem o conteúdo e entregar pro usuário nas mais diversas interfaces. Ou seja, eu vejo esse conteúdo continuando no sistema de bibliotecas porém o usuário tendo a sua disposição diversas portas de entrada pra chegar nesse mesmo conteúdo, através da ferramenta que ele já utiliza em outras pesquisas, sem que ele tenha que conhecer especificamente o sistema de busca da sua instituição ou que ele tenha que pesquisar em diversas bases de dados para obter o que precisa. O Google é uma excelente porta de entrada por causa disso, pois além de disponibilizar um algoritmo de indexação muito eficiente, também conta com diversos outros recursos como a auto correção de termos de busca equivocados, entre outras, mas ainda vejo os dados em sua origem armazenados nos sistemas de bibliotecas e os metadados armazenados utilizando algo como o MARC, porém com a carga de pesquisa que estaria toda em um servidor só, mas que agora está distribuída pelas diversas portas de entrada que o usuário vai ter a disposição dele. Agora imagina quando introduzirmos os elementos da web semântica nessas engines de busca e melhorar ainda mais a recuperação do usuário? Prevejo muitas novidades nessa área! Os usuários agradecem! 😉
Não teria como o google indexar o vufind, pois ai vc liga o vufind a sua base e coloca o vufind para receber as demandas do google?
Aisten. Daria sim e inclusive é uma alternativa interessante. Eu escolhi o Elasticsearch porque precisava, além de tudo, gerar dados estatísticos da produção e o ElasticSearch é muito mais flexivel que o Solr
Mas vc não consegue ligar o Elasticsearch no vufind para gerar as estatísticas? Temos que testar as opções e ver quais se enquadram melhor. Preciso instalá-los para conhecer melhor também.
Pelo que conheço não. Por que o SOLR é usado direto pelo vufind para indexação, não tem algum outro tipo de armazenamento no meio. Na verdade, ele coleta os dados, gera arquivos que poderiam ser indexados no ElasticSearch, mas como ele já faz no SOLR, é fazer a mesma coisa duas vezes. E fora que o ElasticSearch tem o Kibana, que é uma ferramenta de BI que permite fazer estatísticas, gráficos e outras consultas de uma maneira muito mais simples que no SOLR