Projeto de banco de dados para pesquisas musicológicas emperiódicos: um estudo de caso para os jornais da cidade de Rio
Grande
Pablo PaláciosUniversidade Federal de Pelotas
Resumo: A pesquisa “A música nos jornais de Rio Grande” utiliza periódicos como principal fonte depesquisa. O acervo possui notícias relacionadas a música encontradas em três jornais da década de1920, e, ao todo, somam-se mais de 1800 notícias. Neste trabalho, tratamos de apresentar o métodoempregado para a organização do banco de dados do nosso acervo, descrevendo os problemas quetivemos no início e a solução desenvolvida através do uso do framework Django. Essa soluçãoconstitui-se em um banco de dados centralizado, onde todos os pesquisadores envolvidos no projetopossuem acesso através da internet, e, além disso, nossa solução é dotada de mecanismos debusca, classificação e ordenação de dados, facilitando futuras pesquisas em nosso acervo.
Palavras-Chave: história da música no Rio Grande do Sul, pesquisa em periódicos, projeto de bancode dados, python, django.
Database design for musicological research with journals: a study case for the Rio Grande citynewspapers.
Abstract: The research “A música nos jornais de Rio Grande” uses journals as the main source ofresearch. The collection has music related news found in three newspapers of the 1920s, and counting all thematerial, we have more than 1800 news. In this work, we present the method used to organize ournews database, describing the problems we had at the beginning and the solution developed by usingthe Django framework. This solution is made up in a centralized database, which all the researcheshave access through the internet, and, more than this, our solution has interesting features such asdata research engine and assortment and classification of data, which will help the researches that willcome in the future.
Keywords: music history of Rio Grande do Sul, journals research, database design, python, django.
A pesquisa “A música na visão dos jornais de Rio Grande”, iniciada em 2010,
tem como um de seus objetivos levantar as dinâmicas musicais presentes na cidade
de Rio Grande – em Rio Grande do Sul, Brasil – na década de 1920 por meio da
análise de periódicos publicados nesse mesmo período: A Lucta, O Tempo e Rio
Grande. Além disso, a pesquisa também tem como objetivo formar e disponibilizar
um banco de dados para futuras pesquisas.
O método utilizado pode ser divido em três etapas principais: rastreio de
notícias sobre música, organização e sistematização das notícias encontradas e, por
fim, a análise delas. Dessas etapas, devido à grande quantidade de notícias
encontradas na primeira parte do trabalho e à dificuldade no processo de
classificação das notícias levantada por Ruthe Pocebon (2011), encontramo-nos
agora em um processo de reorganização e reclassificação dos dados. No entanto,
durante esse processo, alguns problemas de ordem prática e técnica apareceram, o
que acabou por dificultar o processo de revisão. Por exemplo, questões mais
simples, como erros em nomes de arquivos (que acabaram gerando problemas
complexos) até a dificuldade no compartilhamento de dados atualizados entre
pesquisadores.
Sendo assim, apresentamos com este trabalho um projeto de modelo de
banco de dados, bem como um sistema para análise dos dados e sua divulgação,
para um acervo de notícias de jornais. Para tanto, utilizamos o processo de
mapeamento de planilhas de dados em objetos por meio de scripts em Python para
o framework Django, com o objetivo de resolver os problemas encontrados e facilitar
o processo de revisão. A partir desse mapeamento, o framework Django nos
possibilita fazer listas de notícias utilizando consultas por termos de interesse em
cima de qualquer atributo dos nossos modelos de dados, facilitando a extração de
informações para atender aos objetivos de nossas pesquisas.
Por fim, este trabalho tem como por objetivo apresentar as tecnologias
empregadas nesse processo de reorganização, discutir o projeto de banco de dados
para pesquisas em periódicos e apresentar os resultados obtidos até o momento
com os jornais da cidade Rio Grande.
1. O ANTES
1.1. ESTRUTURA DOS DIRETÓRIOS
O banco de dados de notícias utilizado anteriormente consistia em um
simples diretório de arquivos que se organizava da seguinte maneira: o diretório raiz
armazenava 3 subdiretórios, um para cada jornal; cada diretório de jornal possuía
um subdiretório para cada ano, e esse, por sua vez, possuía um subdiretório para
cada mês. Para cada diretório de mês, maioritariamente, encontrava-se uma lista de
documentos de texto do Microsoft Office (arquivos com extensão .doc) com as
transcrições das notícias extraídas dos jornais. Esses arquivos estavam nomeados,
de uma forma geral, com a data da notícia, precedida pelo seu título.
Vale notar que, embora cada diretório ou subdiretório possuísse um certo
nível de organização, se os analisássemos como um todo, as estruturas não
seguiam uma forma padrão. Por exemplo, ora os arquivos eram nomeados com a
data completa, ora com apenas o dia e o mês, ora só o dia.
Figura 1 – Estrutura dos diretórios.
No fim disso, um arquivo poderia possuir um endereço tão longo e confuso quanto
essa descrição (e esse endereço poderia ser ainda maior dependendo de onde o
diretório raiz se encontrasse no computador do pesquisador).
Figura 2 – Listagem de arquivos: longo e confuso.
Além disso, o diretório do periódico O Tempo diferenciava-se dos outros dois
por possuir um subdiretório extra, com fotografias das notícias. Quanto às notícias
desse periódico, devemos relatar que algumas delas ainda não haviam sido
transcritas, encontrando-se apenas no formato de imagem nesse diretório extra ou
com a imagem inserida em um documento .doc. Por fim, vale dizer que algumas
notícias possuíam apenas uma foto (geralmente referentes a pequenos anúncios de
lojas ou instrumentos), e outras possuíam até 9 fotos (como é o caso da notícia da
inauguração do Conservatório de Música de Rio Grande, que ocupou o espaço de
uma página inteira no jornal), mas todas com resoluções altíssimas, fazendo com
que essas imagens ocupassem bastante espaço no disco rígido.
1.2. Interface
Para possibilitar a análise das notícias, foram criados arquivos de planilhas
(arquivo do tipo .xsl) para servirem de interface com a estrutura de diretórios. Para
cada jornal havia um arquivo de planilha e para cada arquivo de planilha, havia uma
planilha para cada ano de notícias.
Figura 3 – Modelo de notícia antigo.
Como descreve Ruthe Pocebon (2011), o modelo de dados para descrever
uma notícia consistia nos seguintes atributos: ano, mês, dia, nome do periódico,
título da notícia em formato de hipertexto (apontando para o endereço do arquivo
que continha a notícia, seja sua transcrição em formato .doc, seja a fotografia da
notícia), página do periódico onde se encontrava a notícia, resumo, autor e tipologias
para classificações das notícias (figura 3). Cada um desses atributos correspondia a
uma coluna na planilha e cada linha na planilha correspondia a uma notícia.
Diferentemente do caso dos diretórios, as planilhas se apresentavam
consistentes entre elas, pois todas apresentavam o mesmo modelo de dados
apresentado acima. No entanto, entre os valores dos atributos das notícias, o nível
de não formalização era grande. Notícias que se repetiam em um mesmo mês
possuíam uma lista dos dias nas quais elas se repetiam. Em alguns casos, os
delimitadores de dias variavam entre vírgulas, pontos, ponto e vírgula ou mesmo
textos, como “até”. O problema é que, se quiséssemos fazer uma consulta atrás de
todas as notícias de um específico dia, provavelmente omissões ocorreriam, tendo
em vista que quando há um intervalo de dias números podem ser omitidos.
Figura 4 – Problema com delimitadores: o número 17 não aparece no texto “16 até 23”.
Para o campo das tipologias, o problema era semelhante ao do campo dos
dias, pois, como descreve Pocebon, algumas notícias possuem mais de uma
possibilidade de classificação tipológica:
[a tipologia de um] anúncio de um concerto, no qual se lê o histórico doconcertista e o programa a ser executado (…) é composta por umainformação principal e outras secundárias, registrando-seConcertos/Concertistas/Repertórios. (POCEBON, 2011)
Sendo assim, esse atributo também recebia múltiplos valores e a sua
formatação na planilha também recebia delimitadores variados, como barras,
vírgulas e a palavra “e”, o que acaba por dificultar uma ordenação ou filtragem das
notícias por tipologias. Outro problema encontrado para esse atributo é que ainda
havia muitas notícias necessitando de revisão quanto à classificação tipológica, visto
que muitas ainda apresentavam tipologias já em desuso na pesquisa.
Outro atributo que apresentava problemas de consistência em seus valores
era o de título e endereço, pois muitas notícias não possuíam o hipertexto com o
endereço da transcrição ou da imagem no diretório de arquivos. Isso acontecia
principalmente nos casos em que a notícia ainda não havia sido transcrita para .doc
ou por existir mais de uma fotografia por notícia, impossibilitando a criação do
hipertexto, pois esse só permite o endereço de um arquivo por texto.
De acordo com o conceito de normalização de banco de dados relacionais,
todos os atributos de um modelo de dados devem possuir dados atômicos
(BEIGHLEY, 2010), ou seja, cada atributo da nossa planilha não deve receber mais
que um valor, pois, assim, além de criarmos uma tabela consistente, também nos
facilitará fazermos consultas aos nossos dados posteriormente. Os atributos dias,
tipologias, título e endereço não possuíam dados atômicos, pois todos recebiam
mais de um valor. Uma consideração deve ser feita quanto ao atributo página, pois
embora esse campo também recebesse múltiplos valores (mais de um número de
página quando a notícia era longa) muito dificilmente serão feitas consultas
envolvendo número de páginas, caracterizando esse campo não como um dado a
ser pesquisado, mas sim como uma referência para o endereço da notícia no jornal.
1.3. PESQUISADORES
Certamente, o maior problema encontrado no antigo banco de notícias era a
sua descentralização. Desde o início da pesquisa, em 2009, um número razoável de
colaboradores chegou a trabalhar na organização e sistematização das notícias.
Obviamente, a organização de um banco com milhares de notícias não poderia ser
trabalho para apenas um único pesquisador. Para viabilizar esse processo, a
estrutura de diretórios e as interfaces eram copiadas (duplicadas) no computador de
cada pesquisador, possibilitando que todos tivessem acesso ao banco de notícias.
No entanto, foi devido a isso que os maiores problemas surgiram. Provavelmente, a
origem de uma não padronização completa entre os diretórios e as planilhas de
interface tenham sua origem aqui, pois, em determinados momentos, cada
pesquisador era responsável por um jornal e cada um possuía um método de
análise e maneira diferente de lidar com essas duas estruturas.
Como Pocebon (2011) diz, na interpretação de uma notícia de difícil
compreensão, pode ser necessário recorrer a outro periódico para obter uma
classificação tipológica mais apurada. O problema gerado é: como manter todos os
integrantes da pesquisa com informações atualizadas sobre as notícias? Também é
importante dizer que, para complicar a nossa situação, houve momentos em que
havia mais de uma planilha por jornal – com informações divergentes, ou com
classificações tipológicas já em desuso – proveniente de pesquisadores que já não
trabalhavam mais no projeto. Nasceu outro problema: como saber qual planilha
continha a classificação mais adequada? Sendo assim, inseriu-se mais uma etapa
no processo de revisão das planilhas, a comparação e revisão do trabalho feito por
antigos pesquisadores.
Mas o fato de termos um número grande de pesquisadores e a consequente
replicação dos dados não gerou apenas um problema de ordem prática, mas
também problemas de ordem técnica. Muitos pesquisadores significam muitos
computadores e muitos computadores significam softwares e versões de softwares
diferentes, bem como sistemas operacionais diferentes com sistemas de formatação
de discos diferentes.
Cada software utilizado para a edição das planilhas possuía uma maneira
diferente de tratar os hipertextos com os endereços dos arquivos das notícias.
Alguns softwares utilizavam o endereço absoluto do arquivo com a transcrição (ou
da imagem), enquanto outros usavam endereços relativos estáticos em relação ao
endereço da planilha. Isso significa que alguns hipertextos levavam para arquivos
que estavam no computador de outro pesquisador ou para arquivos que se
encontravam em estrutura de diretórios utilizada por esse mesmo outro pesquisador.
Ou seja, havia hipertextos com endereços que não levavam aos arquivos das
notícias, embora esses tivessem sido copiados para o computador do pesquisador.
Somente os softwares mais recentes faziam uma análise da estrutura de diretórios e
corrigia os endereços dos hipertextos automaticamente. Mas, se por acaso
houvesse uma vírgula a mais ou a menos no nome de um arquivo ou no nome de
um diretório, o software não seria capaz de atualizar os endereços. E isso nos leva a
um segundo problema que tivemos: embora a estrutura de diretórios e os nomes dos
arquivos não fossem mais alterados, o endereço dos hipertextos podia ainda estar
errado, mesmo se apontando para o lugar certo, parecendo-nos como alguma falha
no arquivo de planilhas (um bug na planilha). A justificativa para esse evento é o fato
de cada sistema operacional e cada sistema de formatação de arquivos tratar de
forma diferente nomes de arquivos longos e caracteres não ASCII (por exemplo ç, é,
ã e letras que não estão presentes no alfabeto inglês). Como visto anteriormente,
alguns endereços de arquivos poderiam ser bem compridos em função da estrutura
de diretórios, fazendo com que alguns sistemas truncassem o nome do arquivo.
Também vimos que os arquivos eram nomeados com os títulos das notícias, e em
todas as vezes que havia um caractere não ASCII no título da notícia, esse era
convertido para números hexadecimais. Por exemplo, o par de chaves “[texto
qualquer]” presente no título de algumas notícias (e, portanto, no nome do arquivo)
era alterado para “5Btexto qualquer5D”. Na planilha, o endereço do hipertexto
estava certo, mas no sistema de arquivos o nome aparecia errado, quebrando o
hipertexto. Enfim, mais uma etapa era adicionada ao processo de revisão, verificar
os endereços dos hipertextos; e cada vez mais o pesquisador se distanciava de
“apenas” revisar as classificações tipológicas.
2. TRANSIÇÃO
Para poder resolver os problemas levantados anteriormente e possibilitar um
fluxo de pesquisa livre de detalhes que se afastam da prática musicológica, propus,
com este trabalho, um novo modelo de banco de dados e uma nova interface para
interação com ele. Esse novo sistema deveria facilitar a manipulação das notícias. O
modelo de banco de dados e o método para conversão do banco antigo para o novo
são os mesmos utilizados em trabalhos anteriores e consistem no uso do framework
Django para o mapeamento dos dados e a criação de scripts em Python para a
conversão, pois, como visto em outros trabalhos:
O uso do framework Django […] nos possibilita tratar os dados como sefossem objetos e não apenas como linhas em uma tabela, dando-nospraticidade na extração dos dados relevantes à pesquisa, evitando quebuscas manuais em tabelas gigantes sejam feitas. (PALÁCIOS, 2013)
A primeira etapa consiste em redefinir o nosso modelo de dados, ou seja,
redefinir quais são os atributos do nosso objeto de pesquisa, no nosso caso, uma
notícia. Começamos por desmembrar o modelo antigo em três novas classes –
Notícia, Jornal e Tipologia – pois julgamos ser a melhor representação do nosso
objeto de estudo na vida real.
Para a classe Notícia, unimos os atributos dia, mês e ano do modelo antigo
em um único atributo chamado data. Pelo fato do atributo data somente permitir um
dia por data, criamos mais dois atributos para Notícia: repete? e notícia base. Dessa
maneira, possibilitaremos a criação de notícias repetidas baseadas em uma única
notícia e, caso haja necessidade de alteração em uma delas, todas as notícias que
possuam a mesma notícia-base serão alteradas. O atributo Título e Endereço foi
desmembrado em três novos atributos, Título, Endereço de Imagem e Transcrição
da Notícia.
É importante salientar que cada instância de nossas novas classes deverão
ter um identificador único: um número inteiro que não se repetirá em instâncias da
mesma classe, o que nos permite uma melhor comunicação entre as instâncias.
Sendo assim, o atributo tipologias da classe Notícia se transformou em uma lista de
identificadores de instâncias da classe Tipologia. Isso nos possibilita que, caso
encontremos uma melhor nomenclatura para uma determinada tipologia e
resolvamos alterá-la, todas as notícias que possuam essa tipologia em sua lista de
tipologias serão atualizadas automaticamente, sem perder o vínculo com a tipologia,
pois apenas o nome foi alterado e não o seu identificador.
As classes Tipologia e Jornal possuem os mesmos atributos, que são nome
e descrição. No caso da tipologia, podemos colocar na descrição o que define
aquela tipologia, quais são seus limites de classificação e adicionar exemplos de
notícias que foram classificadas com ela.
Figura 5 – Transformação do modelo antigo no modelo novo.
Dessa maneira, caso o pesquisador encontre alguma dificuldade no
processo de revisão das classificações tipológicas, poderá recorrer ao banco de
tipologias para sanar suas dúvidas. Já para a classe jornal, o campo descrição pode
servir para delinear qual é o perfil daquele veículo, também para ajudar o
pesquisador no processo de revisão citado anteriormente. No fim, a transformação
do modelo de dados pode ser representado conforme a figura 5.
Definido o novo modelo, criamos as classes (Notícia, Jornal e Tipologia) em
linguagem Python na sintaxe do framework Django, e por meio do comando syncdb
nosso novo sistema para manipulação de dados está pronto, no entanto, sem
nenhuma notícia ainda. O Django possibilita que insiramos várias instâncias de
nossas classes de uma só vez com o comando loaddata. Para tanto, nossas
instâncias devem possuir uma representação em texto no formato JSON. Para
sabermos qual é a formatação em JSON, criamos uma notícia dentro do sistema
gerado pelo framework e exportamos o banco de dados para JSON com o comando
dumpdata, obtendo um resultado semelhante à figura 6.
Figura 6 – Formato JSON das nossas classes.
A tarefa agora é transformar cada notícia do nosso antigo banco de dados
em sua representação em formato JSON e colocarmos todas em um único arquivo,
possibilitando a inserção desses dados no sistema gerado anteriormente e
permitindo que o Django transforme as nossas planilhas antigas em tabelas
dinâmicas que atendam às necessidades de nossos pesquisadores e facilitem
futuras pesquisas. Poderíamos fazer isso manualmente, escrevendo notícia por
notícia no seu formato JSON, mas devido à grande quantidade de material, criamos
scripts em Python para automatizar esse processo.
Tendo em vista a quantidade de problemas na estrutura do nosso banco de
dados antigo, a criação do algoritmo de conversão tomou um certo trabalho.
Primeiramente, antes de escrever qualquer código, precisávamos chegar a um
mínimo de padronização entre os dados de nossas planilhas. Para isso, unimos
todas as planilhas em um único arquivo, criando uma lista gigante de notícias.
Reparamos aqui que não é prático analisar uma tabela muito comprida, pois o
arquivo demorava muito para carregar todas as notícias, tornando lenta a navegação
e classificação dos dados por meio de editor de planilhas. Após a união das
planilhas, padronizamos todos os delimitadores utilizados nos atributos dia e
tipologias, assim, nosso script seria capaz de entender em quais dias determinada
notícia se repete e quais tipologias foram utilizadas para classificar cada notícia.
Além disso, corrigimos todos os hipertextos que não possuíam o endereço da
notícia. Aqui, nos deparamos com o problema de haver mais de uma imagem por
uma notícia, impossibilitando que o hipertexto levasse a todos os arquivos que
compunham a notícia. Por se tratar de poucas notícias nesse caso, utilizamos o
editor de imagens GIMP para realizar uma montagem de fotos, unindo todas as
imagens em um único arquivo, permitindo assim, a criação do hipertexto. Por fim,
todos os campos que estavam vazios receberam um texto informando que aquela
informação não existia.
Nesse estágio, já possuíamos uma planilha com todos os campos
completos, no entanto, ainda com dois grandes problemas: ainda havia a presença
de tipologias já em desuso e endereços que não levavam a nenhum arquivo. Para
ambos os casos, a metodologia foi a mesma, criamos scripts em Python para
analisar o conteúdo desses campos e gerar listas com as notícias que possuíam
algum valor problemático. A começar pelas tipologias, nosso script nos informou que
havia mais de sessenta tipologias cadastradas, embora hoje somente trinta e uma
estejam em uso. Revisamos cada notícia que recebia uma tipologia em desuso e as
classificamos de acordo com as novas tipologias. A cada reclassificação, rodávamos
mais uma vez o nosso script para saber quantas notícias ainda precisavam ser
revistas. O interessante, aqui, é ter um controle sobre o processo de revisão,
permitindo-nos programar para realizar as revisões (por exemplo, a cada dia,
revíamos uma tipologia em desuso, assim poderíamos manter o foco sempre em um
determinado conceito de classificação, além de matar a ansiedade para saber
quando o processo de revisão terminaria).
Já para a correção dos endereços, criamos um script para corrigir os nomes
de arquivos que apresentavam algum caractere em formato hexadecimal. Depois,
criamos outro script que gerava uma lista de notícias as quais, mesmo com os
nomes corrigidos, não levavam a nenhum arquivo. Para essas notícias, tentamos
por meio dos programas find e locale, presentes em sistemas operacionais com
base UNIX, localizar os arquivos em nossos diretórios. A surpresa foi saber que
havia hipertextos que apontavam para um mesmo arquivo, não por erro de quem
catalogou a notícia, mas sim por, em todas as vezes, a notícia ser uma duplicação
de outra notícia já existente. Por fim, criamos um script que criava um identificador
para cada notícia (um número inteiro que não se repete) e movia todos os arquivos
para um único diretório, nomeando-os com o identificador da notícia e atualizando o
hipertexto para apontar para esse novo arquivo. Caso a notícia estivesse em um
documento .doc, o script convertia-a para o formato HTML. Esse último passo foi
necessário pois, como dito anteriormente, havia notícias que não haviam sido
transcritas, mas que suas fotografias se encontravam em um documento .doc.
Dessa maneira, poderíamos utilizar o analisador de HTML para Python
BeautifulSoup para extrairmos as imagens e, caso houvesse mais de uma imagem
dentro do documento, utilizaríamos o programa ImageMagick para realizar a união
das imagens em uma única, sem que precisássemos fazer isso manualmente. Além
disso, o ImageMagick nos permitiu diminuir o tamanho das imagens, reduzindo o
tamanho do espaço em disco utilizado para armazená-las.
Finalmente, com todos os campos revistos, com a remoção das tipologias
antigas, a revisão dos hipertextos e a revisão dos delimitadores, foi possível criar o
último script que convertia nossa interface em um documento no formato JSON. A
única característica especial aqui é que o script analisava se a notícia se repetia ou
não e, em caso afirmativo, criava novas instâncias de notícias com base nela
mesma, apenas alterando a data.
Outra característica interessante de nossos scripts é que tivemos o cuidado
de criar testes para eles utilizando o framework de testes unittest para Python, com
objetivo de garantir que todos os dados de entrada se convertiam em um valor
adequado e coerente. Isso significa que, antes de fazer a conversão completa dos
nossos dados, criamos notícias fictícias com dados problemáticos e testávamos os
nossos scripts nelas, permitindo-nos ver se as conversões estavam ocorrendo de
forma adequada ou não. Com os nossos scripts aprovados nos testes, convertemos
nossas notícias em um arquivo no formato JSON e o entregamos para o Django
fazer o resto do trabalho, isto é, transformar esse arquivo em um banco de dados
relacionais com nível máximo de padronização e nos entregar uma interface para
análise das notícias.
3. HOJE
Após todo o processo de transação do banco de notícias antigo para o
framework Django, possuímos agora uma interface para manipulação dos dados que
nos permite ser mais produtivos e dar passos mais largos na análise da dinâmica
musical da cidade de Rio Grande na década de 20 (figura 7).
Figura 7 – Nova interface do banco de dados: classificações por título, jornal, data e autor, bem como
filtros (à direita e no topo) por data, jornal e tipologias. Campo de pesquisa por termos no campo
superior esquerdo.
Devido ao fato de o Django ser um framework para desenvolvimento de
aplicativos web, podemos instalar o nosso banco de dados em algum servidor de
hospedagem de sites, possibilitando acesso ao banco de notícias de qualquer lugar
do mundo e de qualquer dispositivo que possua um navegador web (computadores,
tablets, celulares...). Com isso, resolvemos o problema de descentralização, pois os
nossos dados ficam em apenas um lugar e, ao mesmo tempo, acessíveis a todos os
pesquisadores. Além disso, podemos configurar o nosso servidor para realizar
diariamente cópias de segurança dos nossos dados, possibilitando que nossas
notícias sejam recuperadas caso algum problema técnico aconteça ou caso alguma
notícia seja excluída equivocadamente. É válido dizer que o framework também nos
dá um sistema de autenticação, ou seja, somente pesquisadores cadastrados no
nosso banco poderão modificá-lo. Ainda em relação à segurança, contamos com o
sistema automático de validação de entrada de dados do Django, isto é, nunca será
possível atribuir um valor não válido a um determinado atributo (por exemplo, o
Django não permitirá inserir uma letra no campo data), o que garante a consistência
dos nossos dados.
Mas, além de resolver problemas de ordem técnica e prática de nossa
pesquisa, o ponto mais interessante da nossa nova interface é podermos criar novas
listas de notícias, com ordenações ou filtros baseados nas tipologias, nos nomes dos
autores ou por datas de publicação. Não somente, o framework Django possibilita
também que busquemos por palavras dentro dos valores de cada notícia. Um
exemplo prático disso é que, por termos convertido os arquivos .doc para texto puro,
podemos criar uma lista de notícias que contenham em sua transcrição o nome de
uma determinada pessoa. Se somarmos isso com o uso de filtros, podemos ter uma
lista de todos os programas de concertos nos quais um determinado compositor
aparece, o que nos facilita se quisermos fazer um estudo de repertório
posteriormente.
CONSIDERAÇÕES
A criação de scripts em Python e o uso do framework Django nos auxiliou a
resolver vários problemas que tínhamos com o nosso antigo banco de notícias,
como, por exemplo, o de descentralização e a inconsistência dos dados. Além disso,
nos possibilitou novos recursos para utilizarmos em nossa pesquisa, por exemplo, a
capacidade de ordenação e filtragem das notícias, bem como a capacidade de
pesquisa nos valores dos atributos da notícia. No entanto, para que o nosso banco
funcione de forma eficiente, ainda precisamos terminar de transpor todas as notícias
que apenas se encontram no formato de imagem. Vale dizer também que, pelo fato
das notícias terem sido transpostas fielmente como foram publicadas (com
português de época e erros gráficos), poderá haver omissões em listas de notícias
provenientes de pesquisas por termos. Quanto a isso, pensamos que um modelo
ideal de notícia também deva incluir um atributo para a transcrição em português
atual e com os erros devidamente corrigidos.
Quanto às imagens, ainda pensamos que poderíamos diminuir o espaço de
disco utilizado, tendo em vista que uma única foto em alta resolução seria suficiente
para uma página inteira de jornal. Dessa maneira, além de também nos facilitar a
leitura das notícias, isso também nos possibilitaria utilizarmos futuramente um
software de busca de texto em imagens, semelhante ao sistema utilizado pelo
acervo do jornal “O Estado de São Paulo”.1
Também é importante ressaltar que a migração de um banco de dados
utilizando o método apresentado nesse trabalho exige um conhecimento específico
quanto à programação e administração de sistemas, o que em alguns casos exigirá
um profissional qualificado na área para o desenvolvimento de recursos específicos.
Pelo mesmo motivo, também é difícil encontrar serviços de hospedagem que
ofereçam suporte às tecnologias empregadas, exigindo um investimento um pouco
maior se comparado com servidores que suportam outras tecnologias.
Por fim, esperamos que com este trabalho tenhamos conseguido mostrar
novas possibilidades para pesquisas com periódicos. É possível que alguns ajustes
ainda sejam feitos em função da demanda dos pesquisadores, mas, devido ao grau
de organização que possuímos agora, isso não deverá ser um problema. A próxima
etapa consiste na finalização do processo de revisão das classificações tipológicas e
na criação de uma interface pública para que outros pesquisadores não cadastrados
no nosso banco também tenham a possibilidade de consultá-lo.
REFERÊNCIAS
BEIGHLEY, Lynn. Use a cabeça: SQL. Rio de Janeiro: AltaBooks, 2010.
GOLDBERG, Luiz Guilherme. A música pelos jornais de Rio Grande: daproclamação da república ao conservatório de música. Anais do XX congresso daANPPOM, 2010.
PALÁCIOS, Pablo. A música brasileira no repertório da OSESP entre 2000 e 2009 .Anais do XXIII congresso da ANPPOM, 2013.
POCEBON, Ruthe. A música na visão dos jornais de Rio Grande: o problema nadefinição das tipologias. Anais do XX congresso de iniciação científica UFPEL, 2010.
1 Disponível em: http://acervo.estadao.com.br/. Acessado em 18/11/2013.
Pablo Palácios é aluno do curso de Bacharelado em Música com Habilitação em Ciências Musicais pelaUniversidade Federal de Pelotas (Brasil). Também é aluno do curso de Programação em Python pela O'ReillySchool of Technology (EUA). Sua principal frente de trabalho envolve o uso de tecnologias como ferramentasassistivas em pesquisas musicológicas.
Top Related