API para o Dicionário Livre da Hedra

49 views
Skip to first unread message

Pedro Markun

unread,
Mar 12, 2013, 3:55:25 PM3/12/13
to thackday, Lista REA, Brazil interest group for Open Knowledge and especially Open Data, Jorge Sallum
Caros,

a Editora Hedra - uma editora muito bacana que trabalha com CC =D - publica um Dicionário Livre de Português em CC :)

Eu pedi pra eles os arquivos originais pra montar uma API de consulta em formatos abertos e o Jorge subiu esses dias os arquivos .sql pro meu repositório:


Estou aqui dando uma olhada na estrutura e começando a rascunhar o aplicativo. Devo subir uma versão simples - passa o Verbe e ele retorna o significado - até o fim do dia, pra dar um gostinho... mas convido quem quiser ajudar a desenhar e participar da construção pra se manifestar.

Algumas questões pontuais:
* São cerca de 40mil registros. Estou pensando em fazer isso com MongoDB e Flask em Python. Não é uma aplicação muito complexa e daria pra fazer em php e mysql também... mas representar cada palavra diretamente como um documento me parece mais sensato? A estrutura relacional do banco deles é bem complicadinha (pq ali na verdade é o processo de produção do dicionário... alias Jorge, eu super toparia uma oficina sobre como é que vocês constroem o dicionário!). Alguém tem alguma opinião formada sobre isso?

* Pra hospedar isso em produção, vamos precisar de um servidorzinho legal... Vitor e Tom, vocês topam abrir uma conversa com a OKFN Central pra ver se eles podem hospedar? Eu acho que tem tudo a ver com o trampo da OKFN e isso pode ser um projeto OKFN Brasil também :)

abs,
Pedro Markun

Everton Zanella Alvarenga

unread,
Mar 12, 2013, 4:14:48 PM3/12/13
to Grupo de interesse em conhecimento livre no Brasil, especialmente dados abertos, thackday, Jorge Sallum, Lista REA, Mailing list do Capítulo brasileiro da Wikimedia., Edgar (gmail), Thiago Rondon
Pedro,

esses dias (no tempo vago que anda difícil achar) comecei tentar
brincar com o EC2 da Amazon, por recomendação do Edgar (copiado).
Conversei com o Thiago Rondon também para ver se ele tinha umas dicas,
já que eu não sabia que instância subir no primeiro mês gratuito.

Vou levantar os custos de um EC2 e fazer um brainstorm para melhor um
documento que o Thiago colocou no github para esse tipo de coisa
(Thiago, tem como passar o link fácil, perdi aqui) e podemos ver os
custos de uma hospedagem. Falo com o povo da OKFN central também, mas
é legal termos esse levantamento.

P. S. copie a Wikimedia Brasil caso possa interessar os wikidicionaristas.

Até,

Tom
> _______________________________________________
> okfn-br mailing list
> okf...@lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
>



--
Everton Zanella Alvarenga (also Tom)
OKFN Brasil - Rede pelo Conhecimento Livre
http://br.okfn.org

Pedro Markun

unread,
Mar 12, 2013, 4:57:42 PM3/12/13
to Grupo de interesse em conhecimento livre no Brasil, especialmente dados abertos, thackday
Nhé,

ok. A gente hospeda na THacker mesmo então :)

abs,
Pedro Markun

2013/3/12 Alexandre Hannud Abdo <ab...@member.fsf.org>
On 12-03-2013 16:55, Pedro Markun wrote:
> * Pra hospedar isso em produção, vamos precisar de um servidorzinho
> legal... Vitor e Tom, vocês topam abrir uma conversa com a OKFN Central
> pra ver se eles podem hospedar? Eu acho que tem tudo a ver com o trampo
> da OKFN e isso pode ser um projeto OKFN Brasil também :)

Ni!

Sem querer absolutamente menosprezar em nada o trabalho super legal da
editora...

Contudo sendo a obra incompatível com a Open Definition e, eu acharia
estranho tal projeto hospedar-se pela Open Knowledge Foundation.

Especialmente quando, novamente sem querer menosprezar o trabalho deles,
há uma alternativa compatível com a Open Definition, o Wikcionário, que
tem 187 mil verbetes em português, integrado com dicionários em 823
outros idiomas.

Mas, dependendo do tipo e finalidade de aplicação, não descarto ser
justificado.

Abs,
l
e

Marcio Ferreira

unread,
Mar 12, 2013, 6:23:11 PM3/12/13
to thac...@googlegroups.com, Grupo de interesse em conhecimento livre no Brasil, especialmente dados abertos, Jorge Sallum, Lista REA, Mailing list do Capítulo brasileiro da Wikimedia., Edgar (gmail), Thiago Rondon
AWS "assusta" no começo porque é botão pra todo lado, mas nenhum bixo de 7 cabeças =)

Conhece a calc http://calculator.s3.amazonaws.com/calc5.html ?

[]s,

Marcio Ferreira
skype: marcio.ferreir4
(21) 8365-7768


2013/3/12 Everton Zanella Alvarenga <everton....@okfn.org>

--
--
Você recebeu esta mensagem porque está cadastrado no grupo "Transparência Hacker"
Para enviar uma mensagem a todo o grupo, escreva para thac...@googlegroups.com
Para não receber mais mensagens, envie um email para thackday+u...@googlegroups.com
Para mais informações, ou para ler mensagens arquivadas deste grupo, visite http://groups.google.com/group/thackday?hl=pt-BR

---
Você está recebendo esta mensagem porque se inscreveu no grupo "Transparência Hacker" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para thackday+u...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.



Pedro Markun

unread,
Mar 12, 2013, 7:51:29 PM3/12/13
to Grupo de interesse em conhecimento livre no Brasil, especialmente dados abertos, thackday, Lista REA, Jorge Sallum
Duke,

acabei de subir aqui um v0 feito nas coxas só pra inspirar:


É basicamente um wrapper em Flask que acessa o MongoDB e cospe o json resultante...

O import.py faz a transação entre o banco MySQL e os documentos do Mongo... assim que tiver tempo vou trabalhar em colocar o resto das informações disponíveis no MySQL no Banco.

Aqui o exemplo de retorno:


Btw, o Jorge - da Hedra - me mandou uma msg agora pouco feliz com a história e dizendo que deviamos pensar em algum tipo de padrão pra retorno de dicionários... pq a Hedra tem outros além desse. Alguém sabe de algum padrão nesse sentido?

abs,
Pedro Markun

2013/3/12 Duke Khaos <duke...@gmail.com>

Fico no aguardo do link para a documentação para colaborar e qualquer coisa ajudo subir a app no S3 ou no server THacker

Abraços,
Duke

On 12 Mar 2013 18:58, "Everton Zanella Alvarenga" <everton....@okfn.org> wrote:
Pedro,

você resolveu ignorar minha proposta porque alguém não concordou com
você? Como falei, quero fazer uma análise de custo de um Amazon EC2,
até mesmo para aprender a mexer no negócio. :) E isso será muito útil
para várias pessoas que resolverem subir uma máquina por si mesmos.
Até hoje me arrependo de não ter documentado como configuramos o
servidor do stoa.usp.br numa super máquina usando ambientes virtuais.
Precisei depois de anos, mas esqueci como o time tinha feito (mas na
época era só subversion e não tinha coisa legal como o github). E
nessa sua proposta em particular poderá servir para melhorar a
documentação que o Rondon começou - tenho que pegar o link depois.

Acho importante levantar a questão da licença, mas se surgiu um
projeto bacana com a editora, por que não? ;)

Tom
--
Everton Zanella Alvarenga (also Tom)
OKFN Brasil - Rede pelo Conhecimento Livre
http://br.okfn.org

_______________________________________________
okfn-br mailing list
okf...@lists.okfn.org
http://lists.okfn.org/mailman/listinfo/okfn-br
Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br

Pedro Markun

unread,
Mar 13, 2013, 12:44:50 AM3/13/13
to Grupo de interesse em conhecimento livre no Brasil, especialmente dados abertos, thackday, Jorge Sallum, Lista REA
Opa,

eu não estava pensando muito em relacionar palavras não. Em um primeiro momento eu só queria mesmo disponibilizar as entradas do dicionário em formato aberto.

Eu justamente estou querendo evitar esquemas multidimensionais :)

abs,
Pedro Markun

2013/3/13 Thiago Rondon <thiago...@gmail.com>

Pedro,

Eu não entendi exatamente o que você quer fazer, mas se é para tornar isto uma API e manter estes dados persistentes, acredito que há algumas maneiras mais eficientes de se fazer isto, para facilitar o desenvolvimento tem um ORM excelente para Python, o SQLAlchemy. E o interessante do Python é que ele tem suporte a dicionários nativos, então o trabalho de um ORM para este caso é  "syntax sugar".

Desta maneira, você pode jogar um dicionário e criar um esquema que você pode relacionar todas as "propriedades" de cada "palavra" entre eles, economizando recursos e oferecendo mais opções de consumo na API. Eu recomendaria um esquema multidimensional para o banco de dados, como snowflake (star, ..).

Na minha opinião, se for para jogar isto em "cache" em alguma camada, o memcached/redis me parece uma saída melhor do que o mongodb.

Meus centavos,

Abs!
-Thiago Rondon



On Tuesday, March 12, 2013 at 8:51 PM, Pedro Markun wrote:
> Duke,
>
> acabei de subir aqui um v0 feito nas coxas só pra inspirar:
>
> https://github.com/pmarkun/minidicionario-hedra-api/blob/master/server.py
>
> É basicamente um wrapper em Flask que acessa o MongoDB e cospe o json resultante...
>
> O import.py faz a transação entre o banco MySQL e os documentos do Mongo... assim que tiver tempo vou trabalhar em colocar o resto das informações disponíveis no MySQL no Banco.
>
> Aqui o exemplo de retorno:
>
> http://apps.thacker.com.br/dicionario/palavra/hacker
>
> Btw, o Jorge - da Hedra - me mandou uma msg agora pouco feliz com a história e dizendo que deviamos pensar em algum tipo de padrão pra retorno de dicionários... pq a Hedra tem outros além desse. Alguém sabe de algum padrão nesse sentido?
>
> abs,
> Pedro Markun
>
> 2013/3/12 Duke Khaos <duke...@gmail.com (mailto:duke...@gmail.com)>

> > Fico no aguardo do link para a documentação para colaborar e qualquer coisa ajudo subir a app no S3 ou no server THacker
> > Abraços,
> > Duke
> > On 12 Mar 2013 18:58, "Everton Zanella Alvarenga" <everton....@okfn.org (mailto:everton....@okfn.org)> wrote:
> > > Pedro,
> > >
> > > você resolveu ignorar minha proposta porque alguém não concordou com
> > > você? Como falei, quero fazer uma análise de custo de um Amazon EC2,
> > > até mesmo para aprender a mexer no negócio. :) E isso será muito útil
> > > para várias pessoas que resolverem subir uma máquina por si mesmos.
> > > Até hoje me arrependo de não ter documentado como configuramos o
> > > servidor do stoa.usp.br (http://stoa.usp.br) numa super máquina usando ambientes virtuais.

> > > Precisei depois de anos, mas esqueci como o time tinha feito (mas na
> > > época era só subversion e não tinha coisa legal como o github). E
> > > nessa sua proposta em particular poderá servir para melhorar a
> > > documentação que o Rondon começou - tenho que pegar o link depois.
> > >
> > > Acho importante levantar a questão da licença, mas se surgiu um
> > > projeto bacana com a editora, por que não? ;)
> > >
> > > Tom
> > >
> > > Em 12 de março de 2013 17:57, Pedro Markun <pe...@esfera.mobi (mailto:pe...@esfera.mobi)> escreveu:
> > > > Nhé,
> > > >
> > > > ok. A gente hospeda na THacker mesmo então :)
> > > >
> > > > abs,
> > > > Pedro Markun
> > > >
> > > >
> > > > 2013/3/12 Alexandre Hannud Abdo <ab...@member.fsf.org (mailto:ab...@member.fsf.org)>

> > > > >
> > > > > On 12-03-2013 16:55, Pedro Markun wrote:
> > > > > > * Pra hospedar isso em produção, vamos precisar de um servidorzinho
> > > > > > legal... Vitor e Tom, vocês topam abrir uma conversa com a OKFN Central
> > > > > > pra ver se eles podem hospedar? Eu acho que tem tudo a ver com o trampo
> > > > > > da OKFN e isso pode ser um projeto OKFN Brasil também :)
> > > > >
> > > > >
> > > > > Ni!
> > > > >
> > > > > Sem querer absolutamente menosprezar em nada o trabalho super legal da
> > > > > editora...
> > > > >
> > > > > Contudo sendo a obra incompatível com a Open Definition e, eu acharia
> > > > > estranho tal projeto hospedar-se pela Open Knowledge Foundation.
> > > > >
> > > > > Especialmente quando, novamente sem querer menosprezar o trabalho deles,
> > > > > há uma alternativa compatível com a Open Definition, o Wikcionário, que
> > > > > tem 187 mil verbetes em português, integrado com dicionários em 823
> > > > > outros idiomas.
> > > > >
> > > > > Mas, dependendo do tipo e finalidade de aplicação, não descarto ser
> > > > > justificado.
> > > > >
> > > > > Abs,
> > > > > l
> > > > > e
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > okfn-br mailing list

> > > > > http://lists.okfn.org/mailman/listinfo/okfn-br
> > > > > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > okfn-br mailing list

> > > > http://lists.okfn.org/mailman/listinfo/okfn-br
> > > > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
> > >
> > >
> > >
> > >
> > > --
> > > Everton Zanella Alvarenga (also Tom)
> > > OKFN Brasil - Rede pelo Conhecimento Livre
> > > http://br.okfn.org
> > >
> > > _______________________________________________
> > > okfn-br mailing list

> > > http://lists.okfn.org/mailman/listinfo/okfn-br
> > > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
> >
> >
> > _______________________________________________
> > okfn-br mailing list

> > http://lists.okfn.org/mailman/listinfo/okfn-br
> > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
>
>
> _______________________________________________
> okfn-br mailing list

Thiago Rondon

unread,
Mar 12, 2013, 11:44:45 PM3/12/13
to Grupo de interesse em conhecimento livre no Brasil, especialmente dados abertos, thackday, Lista REA, Jorge Sallum

Pedro,

Eu não entendi exatamente o que você quer fazer, mas se é para tornar isto uma API e manter estes dados persistentes, acredito que há algumas maneiras mais eficientes de se fazer isto, para facilitar o desenvolvimento tem um ORM excelente para Python, o SQLAlchemy. E o interessante do Python é que ele tem suporte a dicionários nativos, então o trabalho de um ORM para este caso é "syntax sugar".

Desta maneira, você pode jogar um dicionário e criar um esquema que você pode relacionar todas as "propriedades" de cada "palavra" entre eles, economizando recursos e oferecendo mais opções de consumo na API. Eu recomendaria um esquema multidimensional para o banco de dados, como snowflake (star, ..).

Na minha opinião, se for para jogar isto em "cache" em alguma camada, o memcached/redis me parece uma saída melhor do que o mongodb.

Meus centavos,

Abs!
-Thiago Rondon


On Tuesday, March 12, 2013 at 8:51 PM, Pedro Markun wrote:
> Duke,
>
> acabei de subir aqui um v0 feito nas coxas só pra inspirar:
>
> https://github.com/pmarkun/minidicionario-hedra-api/blob/master/server.py
>
> É basicamente um wrapper em Flask que acessa o MongoDB e cospe o json resultante...
>
> O import.py faz a transação entre o banco MySQL e os documentos do Mongo... assim que tiver tempo vou trabalhar em colocar o resto das informações disponíveis no MySQL no Banco.
>
> Aqui o exemplo de retorno:
>
> http://apps.thacker.com.br/dicionario/palavra/hacker
>
> Btw, o Jorge - da Hedra - me mandou uma msg agora pouco feliz com a história e dizendo que deviamos pensar em algum tipo de padrão pra retorno de dicionários... pq a Hedra tem outros além desse. Alguém sabe de algum padrão nesse sentido?
>
> abs,
> Pedro Markun
>
> 2013/3/12 Duke Khaos <duke...@gmail.com (mailto:duke...@gmail.com)>
> > Fico no aguardo do link para a documentação para colaborar e qualquer coisa ajudo subir a app no S3 ou no server THacker
> > Abraços,
> > Duke
> > On 12 Mar 2013 18:58, "Everton Zanella Alvarenga" <everton....@okfn.org (mailto:everton....@okfn.org)> wrote:
> > > Pedro,
> > >
> > > você resolveu ignorar minha proposta porque alguém não concordou com
> > > você? Como falei, quero fazer uma análise de custo de um Amazon EC2,
> > > até mesmo para aprender a mexer no negócio. :) E isso será muito útil
> > > para várias pessoas que resolverem subir uma máquina por si mesmos.
> > > Até hoje me arrependo de não ter documentado como configuramos o
> > > servidor do stoa.usp.br (http://stoa.usp.br) numa super máquina usando ambientes virtuais.
> > > Precisei depois de anos, mas esqueci como o time tinha feito (mas na
> > > época era só subversion e não tinha coisa legal como o github). E
> > > nessa sua proposta em particular poderá servir para melhorar a
> > > documentação que o Rondon começou - tenho que pegar o link depois.
> > >
> > > Acho importante levantar a questão da licença, mas se surgiu um
> > > projeto bacana com a editora, por que não? ;)
> > >
> > > Tom
> > >
> > > Em 12 de março de 2013 17:57, Pedro Markun <pe...@esfera.mobi (mailto:pe...@esfera.mobi)> escreveu:
> > > > Nhé,
> > > >
> > > > ok. A gente hospeda na THacker mesmo então :)
> > > >
> > > > abs,
> > > > Pedro Markun
> > > >
> > > >
> > > > 2013/3/12 Alexandre Hannud Abdo <ab...@member.fsf.org (mailto:ab...@member.fsf.org)>
> > > > >
> > > > > On 12-03-2013 16:55, Pedro Markun wrote:
> > > > > > * Pra hospedar isso em produção, vamos precisar de um servidorzinho
> > > > > > legal... Vitor e Tom, vocês topam abrir uma conversa com a OKFN Central
> > > > > > pra ver se eles podem hospedar? Eu acho que tem tudo a ver com o trampo
> > > > > > da OKFN e isso pode ser um projeto OKFN Brasil também :)
> > > > >
> > > > >
> > > > > Ni!
> > > > >
> > > > > Sem querer absolutamente menosprezar em nada o trabalho super legal da
> > > > > editora...
> > > > >
> > > > > Contudo sendo a obra incompatível com a Open Definition e, eu acharia
> > > > > estranho tal projeto hospedar-se pela Open Knowledge Foundation.
> > > > >
> > > > > Especialmente quando, novamente sem querer menosprezar o trabalho deles,
> > > > > há uma alternativa compatível com a Open Definition, o Wikcionário, que
> > > > > tem 187 mil verbetes em português, integrado com dicionários em 823
> > > > > outros idiomas.
> > > > >
> > > > > Mas, dependendo do tipo e finalidade de aplicação, não descarto ser
> > > > > justificado.
> > > > >
> > > > > Abs,
> > > > > l
> > > > > e
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > okfn-br mailing list
> > > > > okf...@lists.okfn.org (mailto:okf...@lists.okfn.org)
> > > > > http://lists.okfn.org/mailman/listinfo/okfn-br
> > > > > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > okfn-br mailing list
> > > > okf...@lists.okfn.org (mailto:okf...@lists.okfn.org)
> > > > http://lists.okfn.org/mailman/listinfo/okfn-br
> > > > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
> > >
> > >
> > >
> > >
> > > --
> > > Everton Zanella Alvarenga (also Tom)
> > > OKFN Brasil - Rede pelo Conhecimento Livre
> > > http://br.okfn.org
> > >
> > > _______________________________________________
> > > okfn-br mailing list
> > > okf...@lists.okfn.org (mailto:okf...@lists.okfn.org)
> > > http://lists.okfn.org/mailman/listinfo/okfn-br
> > > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
> >
> >
> > _______________________________________________
> > okfn-br mailing list
> > okf...@lists.okfn.org (mailto:okf...@lists.okfn.org)
> > http://lists.okfn.org/mailman/listinfo/okfn-br
> > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
>
>
> _______________________________________________
> okfn-br mailing list
> okf...@lists.okfn.org (mailto:okf...@lists.okfn.org)

Thiago Rondon

unread,
Mar 12, 2013, 6:31:06 PM3/12/13
to Everton Zanella Alvarenga, Grupo de interesse em conhecimento livre no Brasil, especialmente dados abertos, thackday, Jorge Sallum, Lista REA, Mailing list do Capítulo brasileiro da Wikimedia., Edgar (gmail)

Everton,

Eu sugeri utilizar algum software que podemos orquestrar a instalação e o setup do servidor, para podermos mantermos a receita dele em algum local que todos possam manter, sempre que for o caso.

O artigo que o Tom comentou é um esboço ainda, e devo melhorar ainda, é sobre o Rex, mas existem outras soluções como o puppet por exemplo.

https://github.com/thiagorondon/equinocio/blob/master/equinocio/2013/quarentena/rex-orquestracao-de-servidores.pod

O AWS é ótimo, ele só é caro quando você mantém uma estrutura ociosa. Então, seria interessante levantar a receita necessária para executarmos os serviços necessários, assim como as aplicações e então dimensionar qual o servidor ideal.

Se vocês listarem, quais serviços querem oferecer no servidor, eu me disponho a criar esta receita para avaliação.

Abs!
-Thiago Rondon


On Tuesday, March 12, 2013 at 5:14 PM, Everton Zanella Alvarenga wrote:

> Pedro,
>
> esses dias (no tempo vago que anda difícil achar) comecei tentar
> brincar com o EC2 da Amazon, por recomendação do Edgar (copiado).
> Conversei com o Thiago Rondon também para ver se ele tinha umas dicas,
> já que eu não sabia que instância subir no primeiro mês gratuito.
>
> Vou levantar os custos de um EC2 e fazer um brainstorm para melhor um
> documento que o Thiago colocou no github para esse tipo de coisa
> (Thiago, tem como passar o link fácil, perdi aqui) e podemos ver os
> custos de uma hospedagem. Falo com o povo da OKFN central também, mas
> é legal termos esse levantamento.
>
> P. S. copie a Wikimedia Brasil caso possa interessar os wikidicionaristas.
>
> Até,
>
> Tom
>
> > okf...@lists.okfn.org (mailto:okf...@lists.okfn.org)

Duke

unread,
Mar 13, 2013, 8:55:31 AM3/13/13
to Pedro Markun, Brazil interest group for Open Knowledge and especially Open Data, thac...@googlegroups.com, Jorge Sallum, Lista REA
Markun esse dump da base deles vai ser atualizado? Eles vão ficar mandando um arquivo ou algo assim?

O SQLAlchemy é bom para evitar essas esses selects na mão do import.py como o server usa mongo não precisa dele lá, mas penso ser importante ter o cache, nem que for para fazer cache da request pra evitar chegar no banco.

Markun por que ta usando o mongodb? (Acho que pela complexidade de salvar os dados em um banco relacional)


Duke




Pedro Markun <pe...@esfera.mobi> wrote:

Opa,

eu não estava pensando muito em relacionar palavras não. Em um primeiro momento eu só queria mesmo disponibilizar as entradas do dicionário em formato aberto.

Eu justamente estou querendo evitar esquemas multidimensionais :)

abs,
Pedro Markun

2013/3/13 Thiago Rondon <thiago...@gmail.com>

Pedro,

Eu não entendi exatamente o que você quer fazer, mas se é para tornar isto uma API e manter estes dados persistentes, acredito que há algumas maneiras mais eficientes de se fazer isto, para facilitar o desenvolvimento tem um ORM excelente para Python, o SQLAlchemy. E o interessante do Python é que ele tem suporte a dicionários nativos, então o trabalho de um ORM para este caso é  "syntax sugar".

Desta maneira, você pode jogar um dicionário e criar um esquema que você pode relacionar todas as "propriedades" de cada "palavra" entre eles, economizando recursos e oferecendo mais opções de consumo na API. Eu recomendaria um esquema multidimensional para o banco de dados, como snowflake (star, ..).

Na minha opinião, se for para jogar isto em "cache" em alguma camada, o memcached/redis me parece uma saída melhor do que o mongodb.

Meus centavos,

Abs!
-Thiago Rondon


> > > Tom
> > >
> > > Em 12 de março de 2013 17:57, Pedro Markun <pe...@esfera.mobi (mailto:pe...@esfera.mobi)> escreveu:
> > > > Nhé,
> > > >
> > > > ok. A gente hospeda na THacker mesmo então :)
> > > >
> > > > abs,
> > > > Pedro Markun
> > > >
> > > >
> > > > 2013/3/12 Alexandre Hannud Abdo <ab...@member.fsf.org (mailto:ab...@member.fsf.org)>
> > > > >
> > > > > On 12-03-2013 16:55, Pedro Markun wrote:
> > > > > > * Pra hospedar isso em produção, vamos precisar de um servidorzinho
> > > > > > legal... Vitor e Tom, vocês topam abrir uma conversa com a OKFN Central
> > > > > > pra ver se eles podem hospedar? Eu acho que tem tudo a ver com o trampo
> > > > > > da OKFN e isso pode ser um projeto OKFN Brasil também :)
> > > > >
> > > > >
> > > > > Ni!
> > > > >
> > > > > Sem querer absolutamente menosprezar em nada o trabalho super legal da
> > > > > editora...
> > > > >
> > > > > Contudo sendo a obra incompatível com a Open Definition e, eu acharia
> > > > > estranho tal projeto hospedar-se pela Open Knowledge Foundation.
> > > > >
> > > > > Especialmente quando, novamente sem querer menosprezar o trabalho deles,
> > > > > há uma alternativa compatível com a Open Definition, o Wikcionário, que
> > > > > tem 187 mil verbetes em português, integrado com dicionários em 823
> > > > > outros idiomas.
> > > > >
> > > > > Mas, dependendo do tipo e finalidade de aplicação, não descarto ser
> > > > > justificado.
> > > > >
> > > > > Abs,
> > > > > l
> > > > > e
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > okfn-br mailing list

--

Nitai B. Silva

unread,
Mar 13, 2013, 9:37:29 AM3/13/13
to thac...@googlegroups.com, Pedro Markun, Brazil interest group for Open Knowledge and especially Open Data, Jorge Sallum, Lista REA, Augusto Herrmann
Entrando nesse papo massa!

Sobre um padrão de saída dos dados, Pedro, não encontrei algo para Json. Mas o Augusto falou dessa ontologia chamada GOLD [1].
Também usamos o flask num projeto e gostamos. Sobre o banco, vamos experimentar o CouchBase num projeto. Chamou a atenção a facilidade de uso.
Com ele dá pra usar o Couchbasekit [2].


[]s
Nitai

2013/3/13 Duke <du...@riseup.net>

Jorge Sallum

unread,
Mar 13, 2013, 9:46:32 AM3/13/13
to Duke, Pedro Markun, Brazil interest group for Open Knowledge and especially Open Data, thac...@googlegroups.com, Lista REA
Caros, temos interesse em continuar fornecendo os dumps, mas podemos reestruturá-los, uma vez que atualmente trabalhamos direto nos arquivos em LaTeX, e não há nada que um script bem bolado não resolva nesse caso. Mas me preocupo mais com a inserção de outras bases. Talvez uma API clara para inserção de arquivos em csv (com uma checagem humana dos campos antes do input na base) seja algo muito simples e convidativo para acadêmicos (também para output!). Para um dicionário realmente ser aberto ele tem que aceitar colaborações e até críticas, poder ter forks etc. Daí uma discussão por padrão que vai muito além da Hedra. 

Abraços, J. 


Editora Hedra
Rua Fradique Coutinho, 1139 subsolo
Vila Madalena, São Paulo-SP
01654-011 Brasil
+11-3097-8304



Marcio Ferreira

unread,
Mar 13, 2013, 3:19:10 PM3/13/13
to thac...@googlegroups.com, Lista REA, Brazil interest group for Open Knowledge and especially Open Data, Jorge Sallum
Opa, estou chegando atrasado na conversa :P
 
Algumas questões pontuais:
* São cerca de 40mil registros. Estou pensando em fazer isso com MongoDB e Flask em Python. Não é uma aplicação muito complexa e daria pra fazer em php e mysql também... mas representar cada palavra diretamente como um documento me parece mais sensato? A estrutura relacional do banco deles é bem complicadinha (pq ali na verdade é o processo de produção do dicionário... alias Jorge, eu super toparia uma oficina sobre como é que vocês constroem o dicionário!). Alguém tem alguma opinião formada sobre isso?

Isso não me parece ser trabalho para o MongoDB, um Full Text Search parece mais interessante nesse problema.

Marcio Ferreira

unread,
Mar 13, 2013, 3:22:58 PM3/13/13
to Grupo de interesse em conhecimento livre no Brasil, especialmente dados abertos, Duke, thac...@googlegroups.com, Lista REA
2013/3/13 Jorge Sallum <jo...@hedra.com.br>
Caros, temos interesse em continuar fornecendo os dumps, mas podemos reestruturá-los, uma vez que atualmente trabalhamos direto nos arquivos em LaTeX, e não há nada que um script bem bolado não resolva nesse caso. Mas me preocupo mais com a inserção de outras bases. Talvez uma API clara para inserção de arquivos em csv (com uma checagem humana dos campos antes do input na base) seja algo muito simples e convidativo para acadêmicos (também para output!). Para um dicionário realmente ser aberto ele tem que aceitar colaborações e até críticas, poder ter forks etc. Daí uma discussão por padrão que vai muito além da Hedra. 

Se trabalharmos com Full text Search, nem precisamos importar, apenas indexar!

Marcio Ferreira

unread,
Mar 13, 2013, 3:29:29 PM3/13/13
to thac...@googlegroups.com, Lista REA, Brazil interest group for Open Knowledge and especially Open Data, Jorge Sallum
https://github.com/pmarkun/minidicionario-hedra-api

Estou aqui dando uma olhada na estrutura e começando a rascunhar o aplicativo. Devo subir uma versão simples - passa o Verbe e ele retorna o significado - até o fim do dia, pra dar um gostinho... mas convido quem quiser ajudar a desenhar e participar da construção pra se manifestar.

Esse cheiro de lean em projetos opendata é muito agradável =) 

Markun, caso ele não encontre o verbete, poderia fazer uma sugestão, vamos seguir nessa linha?

Qual intenção do projeto, ser iterativo(participação do usuário em construir o dicionário) ou apenas dispor o significado?
O formato de wiki não atrai?

Pedro Markun

unread,
Mar 13, 2013, 3:47:36 PM3/13/13
to thac...@googlegroups.com, Lista REA, Brazil interest group for Open Knowledge and especially Open Data, Jorge Sallum
Opa,

na real eu nem sei. Eu acho que em primeiro lugar, ter uma API que retorne os significados do dicionário da hedra... simples, direto e confiável já é um grande passo - quero ver se faço um app para Android no fim de semana.

Ai em cima disso, acho que da pra fazer outras camadas e serviços. Gosto da ideia de wiki, de ampliar, de combinar com bases como o wikicionario... mas acho que ter uma consulta simples ao dicionário que é produzido pela Hedra é sempre algo legal.

Sobre full text search, sou totalmente a favor. É legal partir do princípio inverso do dicionário 'quais são as palavras que tem esse significado'. Acho que da só pra plugar um elasticsearch no mongodb (ou mesmo pular direto pro elasticsearch).

abs,
Pedro Markun

2013/3/13 Marcio Ferreira <marciodeso...@gmail.com>

--

Vitor Baptista

unread,
Mar 13, 2013, 9:34:27 PM3/13/13
to thac...@googlegroups.com, Lista REA, Brazil interest group for Open Knowledge and especially Open Data, Jorge Sallum
Pedro, qual o tamanho da base? O Heroku não resolveria?
Reply all
Reply to author
Forward
0 new messages