Richiesta upstream: abilitare le aggregazioni (facet) nell'API RNDT

[aborruso]

Contesto

L'API REST del RNDT (/rest/metadata/search) permette di filtrare i metadati con una query string Lucene (q=campo:valore), ma non permette di aggregarli: non c'è modo di ottenere in una sola chiamata, ad esempio, "quanti record per ciascuna licenza / ente / tema INSPIRE / tipo di risorsa".

Il backend è Elasticsearch (Esri Geoportal Server). Lo si vede dalla forma delle risposte, che espongono i campi tipici di un documento ES:

{ "_index": "...", "_id": "...", "_version": ..., "_seq_no": ..., "_primary_term": ..., "found": true, "_source": { ... } }

e dalla convenzione di mapping dinamico dei campi (_s keyword, _dt data, _txt testo, _i intero, _b booleano, _geo/_pt geometrie).

Elasticsearch supporta nativamente le aggregations (il body aggs), ma l'API pubblica del RNDT espone solo i parametri di filtro (q, bbox, time, modified, type, sort, start, num, …) e nessun parametro/endpoint di aggregazione. Il motore saprebbe aggregare, ma l'API non lo consente.

Cosa chiediamo

Esporre una capacità di aggregazione/faceting sull'endpoint di ricerca. Possibili strade, in ordine di preferenza:

1. Un parametro o body di aggregazione su /rest/metadata/search che inoltri un terms aggregation di Elasticsearch su un campo indicizzato (es. aggs=isOpendata,EnteResponsabile_s,INSPIRETheme_s).
2. In alternativa, esporre le facet tramite l'endpoint OGC API - Records già presente (/ogcrecords).
3. In subordine, anche solo un endpoint read-only di sola lettura per i terms aggregation su una whitelist di campi sicuri.

Perché serve (casi d'uso)

Oggi, per rispondere a domande di sintesi sul catalogo, l'unica via è scaricare tutti i ~23.500 record e aggregarli in locale. Con le aggregazioni basterebbe una chiamata. Esempi concreti:

• Distribuzione delle licenze (isOpendata): quante risorse per CC BY 4.0, IODL 2.0, ecc. Utile per monitorare l'apertura reale dei dati territoriali e — non secondario — per far emergere la disomogeneità del campo (oggi convivono CC BY 4.0, CCBY, Licenza CC-BY 4.0, paragrafi di disclaimer…), un problema di qualità che le aggregazioni renderebbero subito visibile.
• Record per ente (EnteResponsabile_s / apiso_OrganizationName_txt): chi pubblica di più, copertura per amministrazione.
• Record per tema INSPIRE (INSPIRETheme_s) e per categoria ISO 19115.
• Record per tipo (apiso_Type_s: dataset/service/series) e per ambito territoriale.

Tutte statistiche utili a cittadini, PA e riusatori per capire cosa contiene il RNDT, senza martellare l'API con migliaia di richieste.

Workaround attuale (e suoi limiti)

Si può emulare un facet emettendo una query per ciascun valore e leggendo total:

# es. via openrndt
for v in dataset service series; do
  openrndt --format json search --q "apiso_Type_s:$v" --num 1 | jq '.total'
done

Funziona solo per campi enumerati con valori già noti. È inutile per scoprire i valori distinti (devi già conoscerli) ed è impraticabile su campi a testo libero come le licenze. Da qui la richiesta di abilitare le aggregazioni native.

---

Issue di tracciamento lato openrndt. Il testo sopra è pensato per essere inoltrato a chi gestisce il RNDT (AgID / geodati.gov.it).

[aborruso]

Riconfermato live 2026-07-17. Nessun parametro di aggregazione ha effetto; /RNDT/ogcrecords → 404; /RNDT/rest/index/stats (endpoint di stat citato nel JS del portale, su host interno) → 404 pubblicamente.

Nuova motivazione a supporto — il campo licenza è incoerente e le facet lo renderebbero evidente: la licenza può stare in isOpendata, apiso_AccessConstraints_s o solo in apiso_OtherConstraints_s. Esempio: i 12 dataset AIB del MASE hanno isOpendata=null e la licenza (CC BY 4.0) solo in apiso_OtherConstraints_s, quindi q=isOpendata:* non li trova (su "incendi": 101 su 190). Serve sia l'aggregazione sia una normalizzazione del campo licenza.

[aborruso]

Verifica esaustiva 2026-07-18: nessun faceting, su nessun campo, su nessuno dei due canali.

REST — provati 15 nomi di parametro plausibili (aggs, aggregations, facet, facets, facet.field, facet=true, group, groupBy, stats, terms, summary, count, distinct, querydsl): la risposta mantiene sempre le stesse 7 chiavi, ["nextStart","num","results","sourceKey","sourceType","start","total"]. La documentazione ufficiale elenca del resto tutti i parametri accettati e nessuno riguarda l'aggregazione.

CSW — lo standard prevede GetDomain, che restituisce i valori distinti di una proprietà (l'equivalente OGC del faceting). Sul RNDT è esplicitamente disattivata: non compare fra le operazioni dichiarate, e le capabilities riportano GetDomain-KVP: false e GetDomain-XML: false. L'unica forma accettata (ParameterName=GetRecords.resultType) restituisce il dominio di un parametro della richiesta, non i valori del catalogo.

Caso d'uso concreto che ne soffre — le licenze. Senza aggregazioni non è possibile rispondere a "quanti sono i dati aperti nel RNDT": a seconda di come si formula la query si ottengono numeri molto diversi.

Query	Risultato
isOpendata:*	16.668
isOpendata:*CC*	10.451
apiso_OtherConstraints_s:*CC*	3.797
OR dei tre campi su *CC*	13.977

Scaricando un campione di 500 record, il solo campo isOpendata contiene 27 stringhe distinte: la stessa licenza scritta come CC BY 4.0, CCBY, Licenza CC-BY 4.0, licenza CCBY, CC BY 4.0 (Creative Commons - Attribuzione) https://…; valori che licenze non sono (progetto-opendata-highvalue, progetto-opendata-training-ai); etichette del campo incollate nel valore (Limiti di utilizzo\tRisorsa rilasciata con licenza IODL…); interi paragrafi di disclaimer.

Le due cose si tengono: le aggregazioni servono a misurare il problema, e una normalizzazione a valle della licenza (identificatore controllato SPDX o vocabolario DCAT-AP, accanto al testo originale) servirebbe a renderlo interrogabile.