senato-votes: verificare se oggettotrattazione/seduta può disambiguare i residui dei fallback fiducia→DDL

[aborruso]

Contesto

Dopo i due fallback già documentati in docs/lod-wiki/senato/votazione-ddl-link.md e docs/lod-wiki/senato/fiducia-fallback.md, il linking voto Senato → DDL è molto più robusto di prima:

1. path primario osr:oggetto -> osr:relativoA
2. fallback label -> osr:fase = "S.<num>"
3. fallback intra-seduta per le fiducie con refuso nel numero testuale

Questo chiude casi reali come il Piano Casa 2026. Restano però dei residui tecnici non ancora verificati fino in fondo.

Residui aperti

I casi ancora fragili sono soprattutto due:

• fiducia unica senza voti sorella da cui propagare il ddl_uri
• più DDL nella stessa seduta/data, dove la propagazione intra-seduta viene giustamente bloccata per evitare un aggancio sbagliato

Ipotesi da verificare

Verificare se lato Senato esiste un segnale aggiuntivo affidabile che permetta di disambiguare questi residui, ad esempio:

• oggettotrattazione
• qualche proprietà dell'oggetto trattato nella seduta
• un collegamento seduta -> oggetto -> DDL che oggi non stiamo usando

Non è detto che esista davvero un path utile: questa issue è prima di tutto indagine LOD mirata, non implementazione già decisa.

Obiettivo

Capire se esiste un terzo segnale strutturato da usare solo nei casi residui, dopo i fallback già esistenti, senza indebolire la guardia contro i falsi collegamenti.

Non è questa issue

• non riguarda il gap storico 2020 / Cura Italia (#36), che è assenza del dato nel LOD
• non riguarda il limite topic/keyword di senato-votes (#35), che è discovery semantica
• non riguarda il caso Piano Casa 2026, già sostanzialmente coperto

Origine

Riallineamento dopo la run docs/news-agent/2026-07-08_08-17.md e rilettura della wiki Senato (votazione-ddl-link.md, fiducia-fallback.md).

[aborruso]

Indagine LOD — nessun terzo segnale strutturato: OggettoTrattazione non è agganciato alla seduta

Verificato sull'endpoint (leg.19, caso reale: fiducia votazione/19-432-3, DL Lavoro, DDL ddl/60201).

Il modello reale

OggettoTrattazione è un nodo minimale: solo rdf:type, osr:relativoA → Ddl, osr:legislatura. Dump da un voto con oggetto (19-432-1):

?ot a osr:OggettoTrattazione
?ot osr:relativoA  ddl/60220
?ot osr:legislatura 19

Nessun arco OggettoTrattazione → Seduta. Controllo globale: COUNT(?ot a osr:OggettoTrattazione ; osr:seduta ?s) = 0 su tutto il dataset.

Conseguenza: il path seduta → oggetto → DDL ipotizzato nell'issue non esiste. La seduta sta sul voto (Votazione osr:seduta Seduta), non sull'oggetto. L'unico ponte tra una seduta e un DDL è un voto che possiede entrambi gli archi (osr:seduta + osr:oggetto → OggettoTrattazione → Ddl) — cioè un voto sorella. È esattamente il Fallback 2 già in produzione, non un segnale nuovo.

Test sui due residui

• Fiducia unica senza voti sorella: senza un voto sorella con osr:oggetto, sulla seduta non c'è nulla che punti a un DDL (l'OT non si aggancia alla seduta). Il seduta-join restituisce vuoto → irrisolvibile, come il Fallback 2.

• Più DDL nella stessa seduta: verificato sulla seduta della fiducia 19-432-3. I voti sorella raggiungono due DDL distinti — ddl/60201 (DL Lavoro, la fiducia) e ddl/60220 — più decine di documento/sindacatoispettivo. Il seduta-join dà quindi ≥2 DDL senza modo di attribuire quello della fiducia → ambiguo. È il numero nel label ("S.1933") a disambiguare, non la seduta. Nessun guadagno sul Fallback 2.

Query di prova (nodi che condividono la seduta della fiducia e hanno relativoA): 0 righe — nessun OggettoTrattazione sulla seduta.

SELECT DISTINCT ?x ?px ?ddl WHERE {
  <http://dati.senato.it/votazione/19-432-3> osr:seduta ?s .
  ?x ?px ?s . ?x osr:relativoA ?ddl
}

Esito

Non esiste un terzo segnale strutturato oltre ai due fallback. Il seduta-join è solo una riformulazione del Fallback 2 (propagazione per nodo-seduta invece che per data) e ne eredita gli stessi limiti: irrisolvibile sulla fiducia isolata, ambiguo sulla seduta multi-DDL. L'unica traccia del provvedimento per le fiducie resta il numero nel label (bill_number → osr:fase "S.<num>"), coerente con la conclusione di #21. La guardia anti-falsi-collegamenti va tenuta così com'è.

Chiudibile in negativo: indagine conclusa, nessuna implementazione da fare.

[aborruso]

Aggiungo un caso emerso nella run news-driven del 2026-07-09.

Non è solo un problema di fiducia senza voti sorella: c’è anche un caso di voto finale Senato non disambiguato a un solo DDL.

Caso concreto:

italianparliament senato-votes list --legislature 19 --date-from 2026-06-23 --date-to 2026-06-23 --format jsonl
italianparliament senato-votes list --legislature 19 --keyword caccia --format jsonl

Il voto finale del 2026-06-23 (notizia ANSA sul ddl caccia, 80 sì / 56 no / 2 astenuti) viene trovato, ma il record porta un ddl_uri multiplo:

http://dati.senato.it/ddl/59566 | http://dati.senato.it/ddl/56784 | http://dati.senato.it/ddl/58687 | http://dati.senato.it/ddl/59294 | http://dati.senato.it/ddl/59357

Quindi oggi la CLI consente di trovare il voto, ma non di identificare il DDL principale a cui attribuirlo in modo rapido e riproducibile.

Per me questa issue dovrebbe coprire esplicitamente anche il caso:

• voto finale / testo unificato / più DDL correlati nella stessa seduta
• possibile output futuro, se il LOD lo consente: distinguere primary_ddl_uri da related_ddl_uris invece di comprimere tutto in un solo campo multi-valore.

Questo sbloccherebbe bene il caso giornalistico “quale provvedimento preciso ha appena votato il Senato?” anche quando il voto esiste già nel dataset.