Senato su GitHub, Camera solo SPARQL: due modi opposti di aprire i dati
Risposta diretta: Camera e Senato pubblicano entrambi i propri dati come open data, ma con due strategie opposte. La Camera espone tutto solo attraverso un endpoint SPARQL (dati.camera.it/sparql, su Virtuoso). Il Senato affianca al suo SPARQL anche un repository GitHub — SenatoDellaRepubblica/AkomaNtosoBulkData — con disegni di legge ed emendamenti in formato Akoma Ntoso, licenza CC BY 4.0, aggiornati via CI. Integrando entrambi per Open·Parlamento abbiamo toccato con mano perché questa differenza conta.
TL;DR
- Camera: dati solo via SPARQL. Niente dump pubblici versionati. Se l'endpoint è lento o giù, non hai un piano B.
- Senato: SPARQL + bulk data su GitHub (AKN, CC BY 4.0, CI). Puoi clonare, versionare e processare offline i testi.
- SPARQL «ufficiali» fragili: più di un endpoint pubblico italiano risponde
200ma vuoto da script — bisogna ripiegare sui dump grezzi. - Lezione: un bulk dump versionato è più robusto di un endpoint live per chi costruisce pipeline di dati.
Perché due approcci diversi?
Camera e Senato sono istituzioni autonome che hanno aperto i propri dati in tempi e con scelte tecniche diverse. La Camera ha investito su un triple store SPARQL (Virtuoso 07.10.3207): elegante per interrogazioni puntuali, ma è un single point of failure — se l'endpoint rallenta o restituisce vuoto, non c'è alternativa ufficiale.
Il Senato ha fatto una scelta più «da sviluppatori»: oltre allo SPARQL, mette i testi legislativi in un repository GitHub aggiornato via integrazione continua. È un pattern che chi lavora con i dati conosce bene: un bulk dump versionato è facile da clonare, processare in batch e riprodurre, e non dipende dall'uptime di un server di query.
| Aspetto | Camera | Senato |
|---|---|---|
| Endpoint SPARQL | ✅ dati.camera.it/sparql |
✅ dati.senato.it/sparql |
| Bulk dump pubblico | ❌ | ✅ GitHub (AKN, CC BY 4.0) |
| Versionato / CI | ❌ | ✅ aggiornato via CI |
| Lavoro offline / batch | difficile | facile |
| Piano B se l'endpoint è giù | nessuno | il dump |
Il problema degli SPARQL «ufficiali» che rispondono vuoto
Costruendo i connettori abbiamo trovato un pattern ricorrente nei dati pubblici italiani: endpoint SPARQL ufficiali che da uno script rispondono HTTP 200 ma con zero risultati, pur funzionando da browser. Succede, per esempio, con il portale open-data della Corte Costituzionale: «SPARQL ufficiale risponde 200 vuoto da script → inutilizzabile», e la soluzione è stata usare i dataset JSON invece dell'endpoint live.
Questo è esattamente il motivo per cui la scelta del Senato — pubblicare anche un dump versionato — è preziosa: quando l'endpoint live ti tradisce, hai comunque una copia dei dati che puoi processare. Chi pubblica solo SPARQL, invece, ti lascia senza rete.
Cosa significa per chi costruisce sopra questi dati
- Un endpoint SPARQL non basta. È ottimo per query esplorative, ma fragile come unica via d'accesso. Per pipeline serie serve un dump.
- Il versioning è un feature, non un dettaglio. Sapere quale versione dei dati hai processato (un commit GitHub) rende le analisi riproducibili. Un endpoint live non te lo garantisce.
- Normalizza la diversità. Camera via SPARQL, Senato via SPARQL + dump: il nostro layer di connettori legge entrambi e li mappa su un modello unico prima del knowledge graph. (Ne abbiamo parlato anche a proposito delle due ontologie OCD e OSR.)
FAQ
La Camera ha un dump dei dati scaricabile?
Per quanto abbiamo trovato, no: la Camera espone i propri dati pubblicamente solo tramite l'endpoint SPARQL dati.camera.it/sparql. Non risulta un repository pubblico di dump versionati equivalente a quello del Senato.
Cos'è AkomaNtosoBulkData del Senato?
È un repository GitHub ufficiale del Senato della Repubblica con i testi legislativi (disegni di legge, emendamenti) in formato Akoma Ntoso, sotto licenza CC BY 4.0 e aggiornato via integrazione continua. È particolarmente utile per i testi degli emendamenti.
Perché un dump è più affidabile di un endpoint SPARQL?
Un dump versionato si clona una volta e si processa offline: non dipende dall'uptime del server, è riproducibile (sai quale versione hai usato) e non soffre di timeout o rate-limit. Un endpoint live è comodo per query puntuali ma diventa un collo di bottiglia per le pipeline.
Costruiamo agenti AI e knowledge graph su dati reali — gestendo la diversità delle fonti invece di nasconderla. Vedi come funziona Open·Parlamento, oppure parliamone.
Articoli correlati
- Come ho messo Costituzione e codici italiani in un knowledge graphCostituzione e sette codici (penale, civile, procedura, strada, consumo, assicurazioni): ~6.445 articoli ingeriti uno per uno, con identificatori ELI e 86.672 relazioni di modifica autoritative da Normattiva. Ecco metodo, numeri e limiti reali.
- Ho scaricato il diritto UE e l’ho messo nel grafo della legge italianaDal bulk dump dell’Ufficio Pubblicazioni UE (56.292 atti) ho estratto e collegato migliaia di norme europee — regolamenti, direttive, decisioni — al grafo della legge italiana, con CELEX ed ELI. Ecco metodo, numeri reali e cosa manca ancora.
- Grafo del Parlamento italiano: perché Camera e Senato non parlano la stessa linguaCamera e Senato pubblicano open data ottimi ma con due ontologie diverse (OCD e OSR): cognome, legislatura, date e relazioni sono modellati in modo incompatibile. Ecco i problemi e come li abbiamo risolti costruendo un grafo unico.