TransparencyCamp e os três desafios

[Pedro Markun]

Caros,

esse fds vai rolar o TransparencyCamp lá nas gringa. No blog da Sunlight os caras propuseram 3 desafios para serem resolvidos no evento... acho que quem puder acompanhar online, vale. E mais que isso, acho que temos que ficar atentos e ver como tropicalizamos essas discussões.

Segue em baixo a integra do post, mas resumo os 3 desafios:

• Construir um manual para abertura de dados. Algo em torno de 20 páginas para ser utilizado pelo governo e por ONGs para saber como fazer.

Acho que a gente tem que estar na cola disso e fazer logo um movimento para traduzir e adaptar. Tenho certeza que vai ter coisa voltada pra realidade local... mas boa parte pode ser usada por aqui tb.

• Montar um repositório livre com info sobre as jurisidições  e oficiais eleitos.

Seria mesmo um bom negócio para montar colaborativamente e rolar em um OpenTables do YQL ou qualquer outro jeito... mas acho que vale a gente salvar essa idéia prum hackday qualquer?

• Pensar um padrão para catalogos de dados.

Ai acho que era legal se alguem pudesse acompanhar meio de perto. Sempre foi algo que me incomodou nesse boom de catalogos de dados... de novo acho que tem alguma tropicalização necessária, mas é legal a gente participar desse momento de elaboração.

abs,

pedro markun

----

With TransparencyCamp kicking off this weekend, I want to issue a challenge to the entire open government and transparency community to help solve three big, easy problems. Starting this weekend, I'd like us to plan how we're going to solve these problems, and to have them solved them all by July 4th, 2010. We'll call it "Data Independence Day."

These ideas need full participation from as many people as possible and as many ideas as possible to get the best result. As such-- in conjunction with Phil Ashlock (who is awesome) over at TOPP Labs (who are awesome) we'll be working on these not only at TransparencyCamp here in Washington, DC but also atOpenGov West (which is awesome)

Here are the three big problems I want us to solve together:

1. Build an Open Data playbook. An instruction manual for people inside government to teach them how to open their data. This would range from dealing with the bureaucracy to convince the organization to go "open" to dealing with the technology one needs to go "open". The resulting document-- a 20-40 page HTML/Word/PDF could be given to people inside the government, inside NGOs and inside corporations to help them deal with the tactical issues of going "OpenData".

2. Build an open and shared resource: compile a list of all jurisdictions and elected officials in the country. Make it so that the entire community can share in this common resource, and make it so that we can count in it being updated when it needs to be updated. This constantly evolving dataset will support a tremendous number of municipal, state, and nation-wide projects.

3. Come up with a data exchange format for data catalogs. As we prepare the National Data Catalog for release, and begin to write importers, it's clear we need to have a model like Google did with GTFS. Let's create a basic file format for data catalogs, agree to use them so that our platforms will be interoperable, and get government to use it, too.

These three problems can be solved by our community. They can't be solved by any one organization, or any one person. They need leadership, community, and focus. They're not hard problems, they just need our focus and attention for a few weeks. Together, we can get organized and make it happen.

Who is in?

[Carlos Eduardo Moreira dos Santos]

Comecei a passar para um banco de dados relacional os dados sobre os
preços dos combustíveis. Sei que já estão disponíveis em algumas
tabelas (em algum lugar dos meusgastos.com.br), mas a minha ideia é
abrir tudo, desde o parser todo automático para manter os dados
atualizados até o banco de dados para download. Também quero facilitar
a camada entre o banco de dados e as tabelas YQL, e pensei em uma
espécie de wiki, onde o usuário escreve queries SQL e uma tabela YQL é
construída e disponibilizada automaticamente por um Web Service.

Numa segunda etapa partiria para outros dados, contando com a
colaboração de todos a partir do primeiro exemplo. Também gostaria de
tornar o parser distribuído, do tipo http://grub.org (um "google"
colaborativo que está sem patrocínio atualmente). Dependendo dos
acessos, o gargalo seria o banco de dados, e ainda não ouvi falar que
o YQL suporta balanceamento de carga entre diversos servidores.

Outra ideia é usar hadoop para armazenar e efetuar as queries, porém o
retorno de dados teria um delay mínimo um pouco alto. Mas isso deixo
para decidir depois, ainda estou no parser. Quem sabe alguém não
sugere outras maneiras...

2010/3/25 Pedro Markun <pe...@esfera.mobi>:

> --
> Você está recebendo esta mensagem porque se inscreveu no grupo
> "Transparência Hackday" dos Grupos do Google.
> Para postar neste grupo, envie um e-mail para thac...@googlegroups.com.
> Para cancelar a inscrição nesse grupo, envie um e-mail para
> thackday+u...@googlegroups.com.
> Para obter mais opções, visite esse grupo em
> http://groups.google.com/group/thackday?hl=pt-BR.
>