[Gfoss] strumenti per l'opendata

[Maurizio Napolitano]

> Il 22 giugno 2012 08:22, Andrea Peri <aperi2007 a gmail.com> ha scritto:
> sai indicarmi quali sono i punti deboli e problematici dell'harvesting che
> te lo rendono poco utile ?

puoi ragionare a due livelli:
- import dei metadati nel catalogo
questa e' sicuramente la soluzione piu' robusta ma funziona ottimalmente
se implementata dentro ckan e non fuori.
In pratica, grazie alle api in rest, puoi costruirti il tuo script che
va a popolare ckan come vuoi.
La "noia" e' che devi spostarti fuori tutta la logica di gestione.
Le librerie che implementano le API di CKAN sono disponibili in vari
linguaggi: python, php e javascript (ma dovrei verificare se c'e' altro).
Se invece la funzione di harvesting e' gestita da ckan, il tutto va
a meraviglia se comunica con altri server che implementano ckan.
Se non implementano quelle api, allora devi estenderti un oggetto
python in modo da creare lo script.
I vari metodi dell'oggetto servono a gestire gran parte della logica.
Le code e i processi invece partono grazie a rabbitmq.

- creazione di un tool di interrogazione delle API distribuito
l'altra alternativa e' quella di crearsi una applicazione che non
fa altro che da front-end ai vari nodi.
Si tratta quindi di uno script in python o php o javascript che,
sfruttando le api di ckan, aggrega runtime su un sito tutte
le interrogazioni federate che un utente fa.
Spero di essermi spiegato
Un esempio e' qui
http://okfnlabs.org/datacatalog.js/
(se funziona)


> La lentezza di scambio dei dati ?

per i test che ho fatto non mi sembra sia lento, ma penso
che molto dipenda anche dall'infrastruttura.
CKAN puo' essere installato distribuito (es. il file system
di archiviazione su un cloud come s3, l'indicizzatore solr
su una o n macchine ecc...) e, pertanto, il discorso si
sposta altrove.
Certo, non e' parco di risorse.