Piattaforma di scraping degli Albi Pretori dei comuni colpiti dal sisma


#1

Il comune colpito dal sisma è il livello amministrativo pubblico più vicino al territorio interessato dai processi di ricostruzione e gestisce in prima persona parte degli investimenti sulla messa in sicurezza e ricostruzione e parte delle azioni concrete che coinvolgono cittadini e aziende locali.

Ogni azione di un comune è formalizzata in un atto pubblico protocollato e pubblicato all’interno del proprio Albo Pretorio, sia sotto forma di contenuto web (pagina o elemento di una pagina) che di pdf scaricabile.

Le sezioni dei siti dei comuni che pubblicano gli Albi Pretori non sono generalmente processabili automaticamente in base a standard condivisi, per cui è necessaria una piattaforma di scraping che li raccolga opportunamente dalle pagine web e dai pdf e ne strutturi l’informazione contenuta.

L’obiettivo di questa Azione è monitorare automaticamente il flusso di atti ufficiali dei comuni del cratere: aggregare, raccogliere e salvare questi documenti per strutturarli, analizzarli, renderne l’archivio ricercabile ed eventualmente ripubblicarli sotto altre forme.

Persone

Responsabile: Alessio Cimarelli (@jenkin) .

Partecipanti: Enrico Bergamini (@ebergam) .

Task

  1. Definizione della lista di fonti e di una modalità di aggiunta / modifica / rimozione di una fonte.
  • Implementazione di un primo scraper di esempio che monitori una fonte e ne esponga il flusso di contenuti sotto forma di feed RSS con caratteristiche condivise e omogenee.
  • Scrittura di una documentazione su come scrivere un nuovo scraper e di guida per gli sviluppatori che vogliono partecipare.
  • Installazione e setup di un database centrale con cui gestire i contenuti raccolti.
  • Implementazione di un aggregatore di feed RSS che ne indicizzi il contenuto nel database centrale.
  • Creazione di un motore di ricerca generale sull’archivio dei documenti raccolti.
  • Esposizione di feed RSS di contenuti riaggregati (es. per argomento).
  • Implementazione di un processo di verifica del buon funzionamento del sistema e di alerting se vengono rilevati malfunzionamenti.
  • Sperimentazione di processi di arricchimento automatico dei dati (es. testi da OCR sul pdf dell’atto, estrazione di entità semantiche dai testi, incrocio con altre basi dati, ecc.).

Milestones e tempistiche

  1. Pubblicazione di un feed RSS che sia l’aggregato di tutte le fonti monitorate (metà aprile).
  • Pubblicazione di un’interfaccia di ricerca d’archivio sotto forma di pagina web con esposizione di feed personalizzati (fine aprile).
  • Report con indicazioni di prospettive e limiti dei processi di arricchimento dei dati grezzi sperimentati (fine maggio).
  • Monitoraggio di tutte le fonti da monitorare (fine giugno).

Output atteso

Un archivio aggiornato automaticamente di tutti gli atti pubblicati negli Albi Pretori dei comuni del cratere. Un motore di ricerca pubblico sull’archivio con possibilità di sottoscrizione a feed personalizzati. Un cruscotto di controllo del funzionamento della piattaforma. Report di analisi dei dati.


Motore di ricerca degli albi pretori raccolti e aggregati
Definizione di una mappa degli elementi della ricostruzione
Interfaccia grafica di navigazione delle fonti monitorate
#2

Aggiornamento 1

Tre i repository di riferimento:

Task completati / in lavorazione:

  1. L’indice delle fonti è qui: RicostruzioneTrasparente/rt-scrapers;

#3

Aggiornamento 2

Terminato il task 5, il lavoro sull’indexer e il downloader dei documenti allegati agli atti: RicostruzioneTrasparente/albopop-feed-indexer. È stato necessario aggiornare opportunamente il mapping su Elasticsearch.

Lo scraper di Halleyweb è in funzione su un centinaio di fonti, ma è necessario ancora aggiornare la lista fonti su cui si basa l’indexer.


#4

Aggiornamento 3

Nuovo repository per l’esposizione del feed RSS aggregato a partire dai documenti indicizzati su Elasticsearch: https://github.com/RicostruzioneTrasparente/albopop-es2rss.

Completati i task 6 e 7, l’indexer ora indicizza tutte le fonti al momento sottoposte a scraping.


#5

Aggiornamento 4

Il task 9 riguardo l’uso delle API di Ambar per l’aggiunta delle funzionalità di OCR dei documenti scaricati è in fase di test.


#6

Aggiornamento 5

Il task di OCR con Ambar è fermo in attesa di notizie in merito a questa issue, intanto il primo scraper per Halley è stato deprecato ed è in uso il nuovo, che gestisce anche il provider Task, per un totale di 114 albi monitorati.