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 200 ma 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

1. Un endpoint SPARQL non basta. È ottimo per query esplorative, ma fragile come unica via d'accesso. Per pipeline serie serve un dump.
2. 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.
3. 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. Il grafo è la porta, ma il motore è l'asset di dati normalizzato che ci sta dietro: ne abbiamo parlato anche a proposito delle due ontologie OCD e OSR e di perché il vero asset non è la visualizzazione del grafo.

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, scopri come agenti e open data aiutano a capire il Paese, oppure parliamone.