download vs scrape

[Eduardo Leoni]

Uma coisa que eu acho importante é separar o download do scrape. Facilita os testes e utilizamos menos o coitado do servidor da câmara. 

mas aí ter um "default" do lugar onde encontrar os arquivos seria mais fácil. O sistema "caixa preta" é importante, mas deve ser balanceado pelo fato de que os dados que estamos adquirindo estão todos relacionados de uma forma ou de outra.  

E acho importante que o sistema inteiro de download e scrape seja "caixa preta" tbém. Isso é, bastando fazer o download do repositório git. (Em vez de ter que decidir onde colocar os dados e tal.)

-e

[Helder Ribeiro]

2009/10/23 Eduardo Leoni <e.l...@gmail.com>:

> Uma coisa que eu acho importante é separar o download do scrape. Facilita os
> testes e utilizamos menos o coitado do servidor da câmara.

Boa!

> mas aí ter um "default" do lugar onde encontrar os arquivos seria mais
> fácil. O sistema "caixa preta" é importante, mas deve ser balanceado pelo
> fato de que os dados que estamos adquirindo estão todos relacionados de uma
> forma ou de outra.

É, dá pra gente convencionar uma árvore pros scripts colocarem as
coisas, a partir do diretório atual. Um pouco da "caixa-pretisse" fica
preservada por conta de você poder especificar onde é a raiz da
árvore.

> E acho importante que o sistema inteiro de download e scrape seja "caixa
> preta" tbém. Isso é, bastando fazer o download do repositório git. (Em vez
> de ter que decidir onde colocar os dados e tal.)

Quando os scripts estavam na árvore do Parlamento Aberto, eu criei
rake tasks pra fazer tudo de uma vez, poupando o trabalho de ter que
rodar cada script. Fica como uma espécie de "etapa de compilação".
Baixa o repositório e roda um equivalente de "make" que baixa tudo o
que precisa (mais tarde podendo especificar se é pra fazer isso
baixando do site da câmara mesmo e usando os scrapers ou se baixando
do nosso próprio repositório).

> -e
>
> >
>

[Helder Ribeiro]

2009/10/24 Helder Ribeiro <hel...@gmail.com>:

> 2009/10/23 Eduardo Leoni <e.l...@gmail.com>:
>> Uma coisa que eu acho importante é separar o download do scrape. Facilita os
>> testes e utilizamos menos o coitado do servidor da câmara.
>
> Boa!

Implementei isso no scraping_legislators.rb:

$ ./scraping_legislators.rb
Usage: scraping_legislators.rb
-d, --directory=DIR Output directory for data
(optional, defaults to current dir)
--no-parse Only download pages to be
scraped, but don't parse them
--no-get Parse pages without downloading them.


Vou adaptar os outros scripts pra usar isso agora.

[Helder Ribeiro]

2009/10/25 Helder Ribeiro <hel...@gmail.com>:

> 2009/10/24 Helder Ribeiro <hel...@gmail.com>:
>> 2009/10/23 Eduardo Leoni <e.l...@gmail.com>:
>>> Uma coisa que eu acho importante é separar o download do scrape. Facilita os
>>> testes e utilizamos menos o coitado do servidor da câmara.
>>
>> Boa!
>
> Implementei isso no scraping_legislators.rb:
>
> $ ./scraping_legislators.rb

Er.. Isso é quando vc roda com "--help" ou "-h".

[Vitor Calejuri]

Legal e tal termos outro repositório de onde podemos baixar
os dados (caso eles fiquem indisponiveis), porém tem um desvantagem que é a integridade dos dados (mais especificamente, a assinatura de origem).

Como garantir a integridade dos dados oficias? Alguem já pensou num esquema
de assinaturas, ou mais basicamente HASH's ? Acho que devemos pensar num
esquema (mesmo que básico) de assinar ou hashear esses dados de forma que
possamos garantir que os dados são válidos e oficiais (evitando gente maliciosa).
E isso tem uma vantagem de podermos falar em "REVISOES" dos dados em si.
Fica relativamente fácil sabermos quando a câmara atualizou os dados, e sobre
que dados estamos trabalhando.

Isso ai :B

2009/10/25 Helder Ribeiro <hel...@gmail.com>

[Helder Ribeiro]

2009/10/26 Vitor Calejuri <ondeosfrang...@gmail.com>:

> Legal e tal termos outro repositório de onde podemos baixar
> os dados (caso eles fiquem indisponiveis), porém tem um desvantagem que é a
> integridade dos dados (mais especificamente, a assinatura de origem).
>
> Como garantir a integridade dos dados oficias? Alguem já pensou num esquema
> de assinaturas, ou mais basicamente HASH's ? Acho que devemos pensar num
> esquema (mesmo que básico) de assinar ou hashear esses dados de forma que
> possamos garantir que os dados são válidos e oficiais (evitando gente
> maliciosa).

Todo hash feito por nós mesmos seria inválido, porque serviria apenas
pra certificar de que os dados são os mesmos que *nós* provimos. Sem
que a Câmara tenha o seu próprio hash, não há como darmos esse tipo
de garantia.

Acho que o que projetos semelhantes pelo mundo fazem
(http://govtrack.us -- EUA --, http://ukparse.kforge.net/parlparse/ --
Reino Unido) é se posicionarem como um lugar conveniente pra outras
pessoas terem acesso aos dados de uma maneira melhor, mas sem darem
nenhuma garantia.

Quem sabe mais pra frente, se conseguíssemos cooperação da Câmara,
eles poderiam assinar eletronicamente um hash diário do repositório em
rsync. Mas isso é beeem pra frente.

> E isso tem uma vantagem de podermos falar em "REVISOES" dos dados em si.
> Fica relativamente fácil sabermos quando a câmara atualizou os dados, e
> sobre
> que dados estamos trabalhando.

Isso ia ser interessante mesmo. Pros dados de texto (e até as fotinhas
3x4) que a gente raspa talvez um simples repositório git só de dados
(hospedado em outro lugar que não o github, que só dá 300mb) seja uma
boa. Talvez até como uma alternativa ao rsync. Eu achei que talvez svn
fosse ocupar menos espaço, mas aparentemente não:
http://blog.affien.com/archives/2008/07/08/gits-versus-svns-storage-efficiency/

Caso a gente resolva disponibilizar pdfs e outros dados mais tipo
"blob" mesmo, talvez algo como CouchDB ou CloudKit seja melhor.