pedro valente

(Traduzido de http://resource.org/8_principles.html)

Um grupo de defensores da divulgação organizada de dados públicos se reuniu e criou a lista que segue, chamada em inglês de Open Government Data Principles.

Segundo eles, dados do governo só podem ser considerados abertos se forem liberados publicamente de acordo com os princípios abaixo. (Mantive os links para os verbetes originais em inglês).

1. Completos
   Todos os dados públicos estão disponíveis. Um dado público é o dado que não está sujeito a limitações válidas de privacidade, segurança ou privilégios de acesso.

2. Primários
   Os dados são como os coletados na fonte, com o maior nível possível de granularidade e sem agregação ou modificação.

3. Atuais
   Os dados são colocados à disposição tão rapidamente quanto necessário para preservar o seu valor.

4. Acessíveis
   Os dados estão disponíveis para a o maior escopo possível de usuários e para o maior escopo possível de finalidades.

5. Processáveis por máquinas
   Os dados são razoavelmente estruturados para permitir processamento automatizado.

6. Não-discriminatórios
   Os dados estão disponíveis para todos, sem necessidade de cadastro.

7. Não-proprietários
   O dados estão disponíveis em um formato sobre o qual nenhuma entidade tem controle exclusivo.

8. Livres de licenças
   Os dados não estão sujeitos a nenhuma regulação de direitos autorais, patentes, propriedade intelectual ou segredo industrial. Restrições sensatas relacionadas à privacidade, segurança e privilégios de acesso podem ser permitidas.
   

A observância aos princípios deve ser revisável (veja item 3 abaixo).

Definições

1. O significado de “público” :Estes princípios não tratam sobre que dados devem ser públicos e abertos. Privacidade, segurança e outras preocupações podem impedir legalmente (e com razão) que conjuntos de dados sejam compartilhados com o público. Por isso, os princípios especificam apenas as condições que os dados públicos devem atender para serem considerados “abertos”.
2. O significado de “dados”:Informações ou gravações armazenadas eletronicamente. Exemplos incluem documentos, bases de dados de contratos, transcrições de audiências e gravações audio/visuais de eventos.Embora fontes informativas não eletrônicas, como artefatos físicos, não sejam objeto destes princípios, encoraja-se que elas sejam convertidas para formatos eletrônicos na medida do possível.
3. O significado de “revisável”:Alguém deve ser designado como contato para responder a pessoas que tentarem utilizar os dados.A pessoa de contato deve estar claramente designada para que possa responder a reclamações sobre violações dos princípios.

   Uma corte administrativa ou judicial deve ter a jurisdição para revisar se a agência aplicou estes princípios apropriadamente.

* * *

E o que isso tem a ver com o Brasil?

Toda entidade pública que gera dados de interesse público deveria liberá-los seguindo os princípios acima. Simples assim. Não importa de onde elas são.

O exemplo mais gritante é o de dados que são acessíveis apenas pelo browser, como a lista de devedores do INSS, que viola claramente o princípio 5 (dados devem ser processáveis por máquinas).

O que os desafios dos posts anteriores incentivam é a aplicação na marra destes princípios aos dados públicos brasileiros.

Depois do sucesso do “Desafio #1 – A lista negra“, e de algumas repercussões publicadas por aí,  damos continuidade à série com mais um passatempo para o fim de semana.

Novamente a idéia veio do Fabiano Angélico, da Transparência Brasil. Vamos lá:

1. Nossos ilustres senadores

Temos aqui uma lista de todos os senadores atuais e seus respectivos números de CPF.

Bônus 1 – Falta encontrar o CPF do senador Marco Maciel. Alguém se habilita?

2. A lista de devedores para o INSS

O Ministério da Previdência, como bom credor, mantém uma lista de todos os caloteiros, com CPF, CNPJ, nomes e valores.

É possível fazer uma consulta à essa lista por este formulário:

http://www1.previdencia.gov.br/pg_secundarias/paginas_perfis/perfil_comPrevidencia_09_04-A.asp

Também conseguimos navegar pelos nomes de pessoas e empresas, por aqui:

http://www1.previdencia.gov.br/devedores/consdeved.asp

Brincando com a URL da consulta, consegui mostrar um ranking dos maiores devedores:

1. VARIG SA VIACAO AEREA RIO GRANDENSE EM RECUP
   2.512.002.963,38

2. VIACAO AEREA SAO PAULO SA
   1.445.447.625,87

3. TRANSBRASIL SA LINHAS AEREAS
   664.431.406,21

4. COMUNIDADE EVANGELICA LUTERANA SAO PAULO
   434.195.266,02

5. ESTADO DO RIO DE JANEIRO
   405.208.783,42

6. GAZETA MERCANTIL S/A (Já fui vítima dessa aqui)
   380.652.586,65

7. PIRES SERVICOS DE SEGURANCA E TRANSP.VALORES
   339.118.179,37

8. EMPRESA BRASILEIRA DE CORREIOS E TELEGRAFOS
   320.305.796,06

9. ENCOL S A ENGENHARIA COMERCIAL E INDUSTRIA
   319.362.278,18

10. FUND. EDUCAC. DO DISTRITO FEDERAL - EM EXTINC
    315.305.102,76

11. EST.SANTA CATARINA-SECRETARIA DA EDUCACAO E D
    313.380.862,29

12. EBID - EDITORA PAGINAS AMARELAS LTDA
    307.021.193,79

13. CAIXA ECONOMICA FEDERAL
    301.684.374,00

14. INSTITUTO DE PREVIDENCIA DO ESTADO DO RIO GRA
    300.026.754,78

15. TELESP - TELECOMUNICACOES DE SAO PAULO S/A
    299.645.695,76

Voltando ao assunto, queremos juntar A+B.

Objetivo – Cruzar a lista de senadores com a de devedores e descobrir:

a) Se existem senadores caloteiros,
b) Se existirem, quem são eles
c) Quanto devem nossos ilustres representantes

Quem conseguir nos responder a, b e c completa o desafio.  Não custa lembrar que a única condição é  que você  libere todo o código e explique como fez, para que outras pessoas também consigam reproduzir o seu resultado e aprender com ele. De preferência, use algum repositório público de código. Dúvidas: @pedrovalente e @fangelico.

Objetivos secundários

Bônus 2 – Será agraciado com nossa eterna gratidão o desenvolvedor que conseguir extrair a TODA a base de devedores do INSS, incluindo valores devidos (os detalhes que aparecem quando se clica no nome). Aceitamos CSV, dump de SQL, JSON ou qualquer formato razoavelmente reaproveitável. A base é atualizada a cada 3 meses, então devemos poder rodar a coleta novamente quando isso ocorrer. Se não tiver onde hospedar, mande para mim, no endereço pedro.valente no gmail.

Bônus 3 - A medalha de honra por serviços prestados à sociedade vai para quem, com a base acima em mãos, criar uma API pública para consulta desses dados. Algo como um serviço rodando no Google App Engine ou em algum servidor caridoso.

Bônus 4 - Encontrar os CPFs dos deputados federais e rodar o cruzamento do calote com eles.

Qualquer um pode participar. Até agora todo mundo usou Python, mas você pode usar a linguagem de programação de que mais gosta, sem problema.

Atualizarei o post com novidades. Usem os comentários para colaborar ou discutir e bom passatempo.

Atualização de 13 de abril

Como disse nos comentários, o Felipe Zorzo mandou uma solução para o desafio, na qual não encontrou-se nenhum senador devedor do INSS.

Aqui vai mais uma lista fornecida pelo Fabiano Angélico, com CPF de 2.224 parlamentares (deputados federais, vereadores das capitais e deputados estaduais).  Alguém se habilita a passá-la pela checagem e ver quem sai limpo do outro lado?

Sugiro também uma implementação bem simples e reutilizável, algo assim:

>>> import inss
# Caso não haja dívida:
>>> inss.divida('999.999.999-99')
None

# E se houver dívida:
>>> inss.divida('111.111.111-11')
[{'descricao':'Divida 1', 'valor': 5000000, 'data': 'xx-xx-xxxx'},
 {'descricao':'Divida 2', 'valor': 1000000, 'data': 'xx-xx-xxxx'}]

A maioria dos programadores que conheço curtem passar o tempo livre resolvendo desafios, então eu gostaria de propor um para quem se interessar.

É um desafio diferente, a complexidade não é a mesma dos problemas matemáticos e quebra-cabeças lógicos, mas não deixa de ser bem interessante.

O problema

1.  Existe uma “lista negra” de empresas queimadas na praça. São as chamadas “inidôneas” e “suspensas”.

O Cadastro Nacional de Empresas Inidôneas e Suspensas (CEIS) é um banco de informações mantido pela Controladoria-Geral da União que tem como objetivo consolidar a relação das empresas que sofreram sanções pelos órgãos e entidades da Administração Pública das diversas esferas federativas.

Ele pode ser acessado aqui: http://www.portaltransparencia.gov.br/ceis/

Pra facilitar, já exportamos os dois bancos no formato CSV. Baixe-os aqui.

2. Existe um formulário do TSE na web que permite consultar se uma determinada empresa foi doadora de campanha para algum candidato. Ele traz também os detalhes dessa doação, e principalmente para quem foi o dinheiro.

Ele fica aqui: http://www4.tse.gov.br/spce2008ConsultaFinanciamento/consultaReceitaDespesaCandidatoServlet.do

Queremos encontrar a intersecção entre esses dois mundos, que nos traria um resultado muito revelador: quem são os políticos que recebem dinheiro de empresas inidôneas. A idéia é usar o CNPJ das listas na busca do TSE para descobrir se há conexões e quais são os seus detalhes.

A solução

Está dada a largada. Quem quiser debater o problema ou mandar tudo resolvido pode usar os comentários deste post. Você também pode perguntar no Twitter pra mim (@pedrovalente) ou para o Fabiano Angélico (@fangelico), da Transparência Brasil. Foi ele quem me propôs o desafio, que resolvi compartilhar com quem quiser ajudar.

Só existe uma condição para participar, que você libere todo o código e explique como fez, para que outras pessoas também consigam reproduzir o seu resultado e aprender com ele.

O prêmio é apenas o reconhecimento público de um trabalho bem feito, e a satisfação de ter gasto seu tempo livre com um desafio que realmente pode ter algum impacto na vida real.

Se esta experiência der certo e alguém responder, quem sabe pode ser o início de uma série de cooperações independentes entre jornalistas e programadores na busca de menos sacanagem com o dinheiro público.

Atualização de domingo à noite (15/3):

Parece que já temos a resolução do problema. O Marcos Vinícius da Silva, de Ribeirão Preto, foi o primeiro a mandar uma solução que consegui rodar tranquilamente e pareceu funcionar direitinho. Com a palavra, o próprio Marcos:

Estou te mandando os fontes do que fiz até agora para o desafio.
Os fontes que estou te mandando assumem o Python instalado (o meu aqui é o 2.5.2), e que os arquivos Inidoneas.csv e Suspensas.csv estejam no mesmo diretorio dos fontes.
O programa irá gerar os arquivos saida_Suspensos.csv e saida_Inidoneos.csv, na mesma ordem que aparecem nos resultados das pesquisas realizadas no site.

Para executar o programa, basta chamar “python pesquisar.py”. Eu testei no Linux (Ubuntu), mas creio que funcione no windows também, pois não utilizei nenhum recurso fora do que o Python oferece.

Espero que seja útil!

Empacotei o código do Marcos com os arquivos CSV junto para quem quiser testar também.

Depois de rodar o código, estes foram os resultados encontrados no cruzamento.

Não posso deixar de agradecer também o Julio Biason, por ter liberado seu código inicial e aos outros que tentaram resolver. Acabo de dar uma olhada (23h) no repositório compartilhado pelo Julio e parece que ele está bem perto de um resultado. Aguardo seu relato para publicar aqui.

Fiquem à vontade pra comentar sobre as soluções e ajudar a melhorá-las, se necessário.

Agora é digerir esses dados e tentar interpretar o que eles significam.  Já vi alguns nomes bem interessantes ali dentro…

Atualização de segunda (16/3):

O Julio Biason também chegou à solução. Pontos pra ele por ter colocado o código num repositório compartilhado e feito uma visualização mais fácil do resultado. Parabéns!

Já faz mais de um ano que defendi, mas agora lembrei que ela não está online em lugar nenhum.

Pra quem tiver paciência, tá aqui o PDF da minha dissertação, sobre “Aplicações híbridas para a criação de conteúdo jornalístico na internet”. O curso foi o de Engenharia e Gestão do Conhecimento, na Universidade Federal de Santa Catarina.

Reli uns pedaços hoje e vi que muitas coisas que escrevo aqui no blog eu já tinha escrito nela.

O jornalista Marc Frons, “chief technology officer” de operações digitais do New York Times, responde a perguntas dos leitores. Entre outros assuntos, fala da integração entre os tecnólogos (technologists) e os jornalistas:

Shortly before I joined The Times, the print and digital sides of the newspaper decided to merge their operations — what we call “integration.” I’m sure there were many people who thought this was a terrible idea, that the ink-stained Luddites of the print newsroom (the Web stereotype) and the arrogant, illiterate Digerati (the print stereotype) would never find common ground.

We’ve certainly had our moments. But the truth is integration has been a huge success. I don’t think any of the things we have achieved over the past two years in terms of interactive journalism, technology or our business would have been possible without it.

There are many reasons for this, and a few key individuals who made it all work. But as someone who has long had a foot in both worlds, my perspective is we have succeeded largely because beneath the obvious cultural (and sartorial) differences, journalists and technologists are really kindred spirits. The best of them, anyway, are passionate about their calling (because it’s much more than just a job), are skeptical of conventional wisdom and focus groups, like to trust their instincts, yet pride themselves on their analytical abilities and their almost religious devotion to the facts. And for disciplines where teamwork is vitally important, they also tend to share an individualistic, sometimes anarchistic bent, which as a manager is either a constant source of aggravation or amusement, depending upon how much sleep I’ve had the night before. In the end, technologists and journalists like to get stuff done, which makes them ideally suited to one another.

The trouble is they view the world from opposite ends of the telescope. The instincts that serve you so well as a print journalist often don’t work online (and vice versa) because the rules of the mediums are so different. But once journalists and technologists start to breathe the same air, they begin to understand one another. While we still have some distance to travel, that has certainly been the case at The Times.

We’ve accelerated this process through some fairly unconventional means. Last year, we formed a new software group called Interactive News Technologies, a team of journalistically minded techies (led by a technically minded journalist named Aron Pilhofer) who sit side by side with our editors, reporters and graphics journalists in the newsroom and produce Web applications at daily deadline speed. They have already been responsible for some terrific applications that use interactive databases that we wouldn’t have able to build as fast otherwise, or perhaps at all because we would not have had anyone focused on developing that technical capability.

While there will always be differences between journalists and technologists, I think we are in the midst of a vast generational shift. In the not-too-distant future, the majority of working journalists will be “digital natives” who cannot remember a world without the Internet, and who read most of their news online. That is bound to lead to some profound changes as this Facebook generation begins to assume leadership positions in newsrooms around the country. This next generation is going to have a much greater understanding of the possibilities and limitations of technology, as well as an innate sense of what works (and what doesn’t) online.

Em outra resposta, disse o que vem por aí:

In the next few months, we hope to announce more innovations in multimedia and data visualization as we link these platforms to our strategy around user generated content and APIs.

E também mostrou como o NYT entende e trabalha pra usar ao seu favor as mudanças causadas pela web no jornalismo, principalmente na questão bloco de texto vs. informação estruturada:

In the past, we treated all this structured information as plain text. So there was no way to search, sort and filter all this information or link it to anything else. There was no useful metadata (a term that basically means data about data), no “tags” or other information to help our online readers find all this rich information we were producing every day.

But for the past several months, we’ve been building systems to ensure that everything we produce is tagged at the outset so that it can be placed in a database where it can then be accessed by software developers using the APIs I talked about earlier. We’re doing this not just for structured data but for articles as well so that there will be much richer and more descriptive information about everything we’re ever written going all the way back to 1851.

We have many ideas around creating much richer and more collaborative Times Topics pages and more enhanced articles and multimedia in general. Much of this is necessarily vague because we’re not yet ready to talk about all the things we’re doing in this area. But part of the idea behind creating this vast database of articles and data, making it available, and then giving people the tools to manage it and recombine it with other information, is to tap into the incredible creativity made possible by the Web. We’re really not sure what applications our own developers, external developers and our readers will create using all this information — and to me, that’s the beauty of it.

Essa pergunta tem passado pela minha cabeça com uma certa freqüência ultimamente. Resolvi enumerar abaixo algumas razões.

1. Porque, segundo a Wired, é cool:

Expired: ASP.NET, Tired: PHP, Wired: Django

2. Porque, segundo o Bruce Eckel, guru do Java, é legal.

“I think I’ve been using Python for close to 12 years now, and it’s been my favorite language for much of that time…” “I think the combination of choices offered by Django + TurboGears covers people’s needs better than a single monolithic approach, and Django appears to be the right solution for a large portion of the applications out there.”

3. Porque, segundo o xkcd, é sensacional:

4. Porque, segundo o Matt Waite, jornalista que aprendeu a programar, é fácil:

“But what makes Django an even greater work of art is that knuckle-dragging, mouth-breathing, not-very-good journalism graduates from small midwestern states (ahem) can learn just enough to build something they can be proud of.”

5. Porque Guido van Rossum, criador do Python, gosta do Django:

“My personal favorite — and I expect that that will remain a personal favorite for a long time — is something named Django. … I highly recommend it.”

6. Porque o Google (onde o Guido trabalha) resolveu apostar pesado em Python+Django com o AppEngine:

“With Google’s employment of Python and Django as a first class citizen in its AppEngine infrastructure [...] this development has the potential of trusting Python into the limelight.”[fonte]

7. Porque Python é uma das linguagens cuja adoção tem crescido constantemente pelo mundo:

Ocupa a 7ª colocação no ranking do índice Tiobe de julho de 2008, com quase 5% do total de linhas de código escritas.

8. Porque Django é um framework cada vez mais estável e confiável:

“Django 1.0 will be released in early September.” (dia 2 para ser mais exato)

9. Porque segundo o Adrian Holovaty, o Django tem tudo a ver com jornalismo:

“Because journalism and computer science don’t normally go together, I’ve had some success in this silly little niche of employing Web development in news organizations — ‘journalism via computer programming.’”

10. E finalmente, porque Django ajuda a resolver as coisas rápido:

“A apresentação é um passo a passo de como a pesquisa de um repórter em tabelas do Word pode se tornar uma aplicação web interativa com mapas e gráficos em apenas dois dias. O James Bennett usa Python e Django pra isso.”

O pessoal de uma pós-graduação da Cesusc me pediu e fiz uma apresentação rápida pra eles remotamente. Falei pelo Skype e pela webcam vi a sala onde foram exibidos os slides abaixo.

Eles discutiam o texto na internet e como a pirâmide invertida se encaixava nessa história toda. Eu aproveitei pra bater novamente na tecla do jornalista-programador

Mandei essa mensagem por email pra um monte de gente, não custa deixar por aqui pra quem se interessar…

Convido todos a participar:
http://groups.google.com/group/dados-publicos

A idéia principal é trocar experiências sobre técnicas de coleta, processamento e visualização de informações no Brasil.
O termo ‘dados públicos’ é usado aqui de uma maneira bem flexível, abrangendo dados disponíveis na rede em geral.

Veja o theinfo.org para uma iniciativa internacional desse tipo.
COLETA:
Scrapers, robôs de varredura, crawlers, dumps, shapefiles, arquivos xls, csv, txt, pdf(!) .
Ferramentas existentes, troca de scripts, liberação de iniciativas particulares em código aberto

PROCESSAMENTO:
Geoprocessamento, cruzamento, limpeza dos dados, scripts, etc.

VISUALIZAÇÃO:
Gráficos, mapas, tabelas, qual a melhor forma de mostrar tudo isso?

Questões relacionadas

• Repositório colaborativo de dados públicos brasileiros. É viável? E uma API de acesso a este repositório?
• A transparência/cobrança política pela web passa pelo acesso e cruzamento de dados públicos.
• Mobilização social para a abertura a desenvolvedores (APIs e web services) e simplificação da consulta a dados públicos que – por lei – devem estar disponíveis.

Pergunte, sugira e colabore. Qualquer um pode participar.

Muita gente já comentou o lançamento do EveryBlock, um site sensacional feito em Django por um dos criadores do próprio Django. Mas uma coisa que ainda não vi ninguém comentar e que achei interessante foi a ausência do Google Maps nele.

Tenho pensado em trocar o Google Maps por algo mais leve há algum tempo, e com o EveryBlock vi que existe um concorrente a altura, o OpenLayers. Não sei detalhes de como o Holovaty implementou, mas cada imagem que compõe o mapa é servida por um arquivo Python (tilecache.py).

Esse fato é significativo porque demonstra que o Google Maps não é mais unanimidade para a construção de mash-ups geográficos, moda iniciada pelo próprio Holovaty usando Gmaps em 2004 com o chicagocrime.org.

Outra surpresa interessante é que o EveryBlock usa jQuery. Como eu também tenho me dedicado a Django e a jQuery é bom saber que os dois frameworks andam conversando bem por aí.

O G1 publicou matéria sobre esse assunto e deixou uma bola quicando: no meio do texto o link para um arquivo do excel com todos os cruzamentos nos quais a polícia busca ter atenção especial, os tais “mais perigosos”.

Resolvi então fazer o óbvio, colocar os pontos no mapa para ver como ficaria.

1. Não tem como achar esquina?
O Google maps dá resultado para a procura por cruzamento de ruas nos Estados Unidos, mas não no Brasil. Espero que surja logo um suporte a esse recurso, ou então teremos que recorrer a gambiarras no futuro.

2. Nem foi tão trabalhoso assim
Como não dava pra automatizar, botei a mão na massa. Em pouco mais de uma hora inseri manualmente todos os pontos num mapa do Google Maps. Sei que é trabalho burro, mas para o meu objetivo serve. Taí o resultado:

O jQuery muita gente já conhece. É uma biblioteca javascript, similar ao Prototype e ao mooTools, que tenho usado bastante.

O Flot é um plugin pro jQuery que facilita a criação de gráficos (veja vários exemplos mais legais que o meu na página do projeto). O interessante é que ele usa o canvas, um “novo” elemento HTML que é vetorial – uma área onde o Flash reinava absoluto até pouco tempo. Pra variar, o Internet Explorer não entende direito canvas, por isso tem uma gambiarra no código que – dizem eles – faz funcionar também no IE (Eu não descobri como fazer isso ainda…).

Peguei uns dados de uma matéria do G1 e formatei num gráfico com Flot pra testar como funciona. Dá pra perceber que ainda é versão 0.1, mas promete. Mesmo assim, foi fácil e rápido fazer este exemplo aqui.

Atualização: Foi só eu terminar de escrever que descobri que o Google lançou uma API para a produção de gráficos.  Parece bem completa, tem recurso que não acaba mais.  Testarei em breve.

Todo blog que se preze tem listas de 10 mais, seja de que tópico for. Então resolvi postar algumas relacionadas com jornalismo de base de dados ou que nome tenha o “data journalism” que falam por aí. Reproduzo livremente e com licenças tradutórias do artigo original de Rich Gordon para o Readership Institute, que achei bem interessante.

A primeira lista é baseada em conclusões do grupo jornalístico Gannett Co. que implementou o information center, um tipo de central de coleta de dados:

Porque os dados devem ser a força motriz do jornalismo

• Dados não perdem a validade
  Depois de 24 horas o valor deles para o usuário não diminui.
• Dados podem ser pessoais
  A proximidade com o leitor se torna muito maior e mais fácil de ser atingida.
• Dados são melhor distribuídos em um meio sem limitações de espaço
  As melhores bases de dados são grandes demais para serem impressas na íntegra. A web além disso ainda tem a vantagem de possibilitar buscas, reordenação e todo tipo de filtragem.
• Dados se aproveitam das maneiras que as pessoas usam a web
  É um meio que se presta mais ao comportamento ativo, de pesquisar e interagir, do que passivo, de ler e assistir.
• Dados, depois de coletados, podem ser utilizados no meio impresso
  Depois de coletar, armazenar e permitir o acesso aos dados, é fácil utilizá-los em outros meios.

O jornal The Indianapolis Star, do grupo Gannet, é um dos que melhor aplica os itens acima, segundo o autor. E baseado na experiência deles surgiu a lista a seguir, que mostra…

As lições aprendidas pelo Star

• Tenha um plano
  Antes de montar a Central de Dados, pessoas-chave da redação criaram uma lista de assuntos que poderiam render bons dados e que seriam úteis para os leitores. Essa lista guiou todo o desenvolvimento das aplicações.
• Envolva especialistas em Reportagem Assistida por Computador (RAC)
  Repórteres e editores que já utilizam RAC têm o maior conhecimento de onde fuçar para encontrar dados importantes, que dados estão disponíveis e como lidar com buracos e inconsistências nas bases de dados.
• Monte uma equipe
  São necessárias as habilidades jornalísticas e analíticas de um especialista em RAC , o entendimento de pesquisa de bibliotecários de notícias, habilidades de desenvolvimento e HTML de programadores e o bom gosto visual e habilidade multimídia do departamento de arte. Embora seja difícil, é possível encontrar quem consiga acumular duas ou mais destas funções.
• Aumente a importância do “arquivo” de notícias
  Com a digitalização, jornais têm abandonado a clipagem manual e catalogação diária do jornal. Mas para que a central de dados funcione a contento, é importante que a área de armazenamento e pesquisa também esteja funcionando bem.
• Encontre ferramentas que tornem a publicação fácil
  Existem soluções de código aberto excelentes para esse tipo de central de dados. Django, um framework escrito na linguagem de programação Python, é o destaque. Nasceu das necessidades de um jornal e amadureceu dentro de uma redação, sendo moldado para permitir a produção de aplicações no ritmo da pauleira do fechamento.
• Publique apenas o que tiver valor de notícia
  As bases de dados com maior valor são aquelas apresentadas dentro de um contexto jornalístico claro. Tem que haver relação entre o que é notícia e os dados que são mostrados.

Para encerrar esse post que já está ficando comprido, uma última listinha, desta vez mostrando uma hierarquia dos tipos de projetos possíveis de se executar com uma central de dados na redação. A lista segue em ordem de complexidade:

1. Entrega de dados
   É o modelo mais simples. Você coleta os dados e mostra a tabela para os leitores.
2. Busca de dados
   É o modelo mais comum. Espera-se que o leitor encontre alguma coisa fazendo uma busca num campo de texto e alguns filtros, no caso de buscas avançadas.
3. Exploração de dados
   Aqui começa a ficar mais divertido. É o modelo usado pelo chicagocrime.com chicagocrime.org. Além da busca, tudo é link e pode ser clicado e a cada tela novas opções de navegação são sugeridas, melhorando a experiência do usuário. A apresentação do conteúdo e arquitetura da informação obedecem a critérios jornalísticos.
   
4. Experiências com dados e com narrativas
   É o casamento entre os dados e a notícia, integrando também elementos de redes sociais como comentários e elementos de narrativas multimídia como áudio e vídeo. O importante aqui é que deve existir uma integração de verdade. Não basta jogar um vídeo, uma tabela e umas notícias numa página para dizer que funcionou.
   Dois dos exemplos mais avançados deste modelo saíram do NY Times e do Star Tribune. Vale a pena dar uma olhada.