FAQ

Data di aggiornamento
Giovedì 12 Gennaio 2023

La sezione FAQ, costantemente aggiornata sulla base delle segnalazioni emerse durante la gestione del catalogo dati.gov.it, contiene una serie di suggerimenti per risolvere alcune situazioni che possono manifestarsi più di frequente.


1. Abbiamo notato che sul portale Dati.Gov.it i dataset della nostra amministrazione hanno come Licenza il valore “Sconosciuto”. A cosa è dovuto?

Il processo di Harvesting, cioè di raccolta di metadati da parte di Dati.Gov.it del catalogo CKAN che si intende federare col catalogo nazionale, può avvenire in vari modi: tramite API dirette di CKAN oppure tramite endpoint JSON o RDF.

Se il catalogo CKAN ha il plugin che lo adegua al profilo di metadatazione ufficiale DCAT AP IT, l’harvesting può avvenire in tutti i modi.

Ma è necessario controllare come i metatadati vengono esposti dal lato del server del catalogo federato.

Semplicemente si può scaricare il file RDF (o visualizzare il formato TTL) accedendo dal browser su dati.comune.xxxx.it/catalog.rdf ( o .ttl) controllando visivamente se ci sono tutti i metadati corretti.

PS: Per i cataloghi CKAN, se i dataset del proprio metacatalogo superano il numero di 100, è probabile che saranno disponibili N files catalog.rdf scaricabili aggiungendo ?page=x con x che va da 1 a NumeroDataset/100. Esempio dati.comune.xxxx.it/catalog.rdf?page=2

In particolare è necessario fare attenzione al campo license della risorsa:

dct:license <https://creativecommons.org/licenses/by/4.0/> ;

In questo caso la licenza applicata è la CC BY 4.0, che è la licenza Creative Commons suggerita da AgID.

Può capitare invece che il metacatalogo esponga come campo licenza:

dct:license <https://w3id.org/italia/controlled-vocabulary/licences/C1_Unknown>;

Questa è la “Licenza Sconosciuta”.

Tale valore viene applicato di default dal CKAN nel caso non avvenga una mappatura corretta tra la licenza del Dataset e quella della Risorsa.

Può capitare sia perché è stato fatto un upgrade del CKAN inserendo il plugin DCAT-AP_IT e non sono state modificate le singole licenze a ciascuna risorsa, oppure perché è stata utilizzata una licenza del Dataset non riconosciuta dal plugin in uso.

Esiste un metodo “ragionato” e “massivo” per applicare al catalogo CKAN una patch per cui in caso di licenza sconosciuta, si applichi la licenza che giuridicamente l’Ente (RightsHolder) ha deciso di usare.

Tipicamente nelle delibere regionali o comunali è riportata la licenza da applicare. In Italia le licenze più usate sono la IODL2.0, CCBY 4.0, CC0.

Auspicando che l’Ente abbia scelto di usare, o di migrare, alla CCBY 4.0 come per altro previsto come azione del Piano Triennale, come è possibile comunicare al CKAN in uso di utilizzarla come licenza di Default?

E’ necessario seguire le istruzioni qui di seguito illustrate che sono state condivise anche durante il Webinar “Il nuovo catalogo Dati.gov.it: metodi e standard per l'esposizione dei dataset in formato aperto da parte delle” http://eventipa.formez.it/node/326281

Modificando il file licence.py del CKAN in uso, è possibile sfruttare la caratteristica prevista dal plugin di usare una licenza ben precisa in caso di non corretta mappatura (o inesistente) tra licenza del dataset e della risorsa.

Ricordiamo che nel profilo DCAT-AP_IT, la licenza si applica alla risorsa e tale valore è esposto sul portale Dati.Gov.it (e non la Licenza sul dataset).


2. Abbiamo utilizzato il validatore semantico al nostro CKAN oppure ci avete comunicato che ci sono degli errori di harvesting sul campo startDate e endDate del Dataset o ancora sulla URL del Contact Point. Come possiamo risolvere?

Il profilo DCAT AP IT prevede i seguenti campi:

dcatapit:endDate

dcatapit:startDate

e vcard:hasURL <URI>

Se il catalogo CKAN è stato aggiornato con il plugin DCAT-AP_IT, è necessario controllare dal lato server come sono esposti i metadati.

Semplicemente si può scaricare il file RDF (o visualizzare il formato TTL) accedendo dal browser su dati.comune.xxxx.it/catalog.rdf ( o .ttl) controllando visivamente se ci sono tutti i metadati corretti.

PS: Per i cataloghi CKAN, se i dataset del proprio metacatalogo superano il numero di 100, è probabile che saranno disponibili N files catalog.rdf scaricabili aggiungendo ?page=x con x che va da 1 a NumeroDataset/100. Esempio dati.comune.xxxx.it/catalog.rdf?page=2

Se si rileva che tali campi sono mappati dal catalogo CKAN come:

schema:endDate

schema:startDate

e vcard:hasURL “URI” (cioè non un uri ma un campo letterale)

allora il plugin ha necessità di alcune patch (correzioni) sui campi citati.

E’ necessario seguire le istruzioni qui di seguito illustrate che sono state condivise anche durante il Webinar “Il nuovo catalogo Dati.gov.it: metodi e standard per l'esposizione dei dataset in formato aperto da parte delle” http://eventipa.formez.it/node/326281





3. Abbiamo notato che il formato delle risorse del nostro CKAN, quando vengono esposte su Dati.Gov.it diventano “OP_DATPRO” e non correttamente JSON, XML, ect tranne che i formati CSV. A cosa è dovuto?

Se il catalogo CKAN è stato aggiornato con il plugin DCAT-AP_IT, è necessario controllare dal lato del server come sono esposti i metadati.

Semplicemente si può scaricare il file RDF (o visualizzare il formato TTL) accedendo dal browser su dati.comune.xxxx.it/catalog.rdf ( o .ttl) controllando visivamente se ci sono tutti i metadati corretti.

PS: Per i cataloghi CKAN, se i dataset del proprio metacatalogo superano il numero di 100, è probabile che saranno disponibili N files catalog.rdf scaricabili aggiungendo ?page=x con x che va da 1 a NumeroDataset/100. Esempio dati.comune.xxxx.it/catalog.rdf?page=2

Nel caso di una risorsa in formato XML è possibile notare che il campo:

dct:format <http://publications.europa.eu/resource/authority/file-type/XML> ;

è invece esposto come:

dct:format <http://publications.europa.eu/resource/authority/file-type/OP_DATPRO> ;

Questo avviene per un errore del catalogo CKAN che riguarda la mappatura dei formati.

In particolare quando nelle Risorse viene inserito il campo “Formato di distribuzione” scegliendolo dal menu a tendina, deve corrispondere al “Formato” che è stato scelto per la risorsa.

E’ necessario seguire le istruzioni qui di seguito illustrate che sono state condivise anche durante il Webinar “Il nuovo catalogo Dati.gov.it: metodi e standard per l'esposizione dei dataset in formato aperto da parte delle” http://eventipa.formez.it/node/326281



Si può effettuare un upgrade dei formati di default che il catalogo CKAN mappa automaticamente.

Attualmente il plugin ha solo alcuni formati mentre andrebbero estese tutte le casistiche dei formati che il metacatalogo in esame espone. A tal fine è possibile modificare il file profile.py:

  • Entrare nel Docker (se presente) del CKAN
  • cd /usr/lib/ckan/default/src/ckanext-dcatapit/ckanext/dcatapit/dcat/
  • nano profiles.py e dopo la modifica qui sotto riportata, salvare e riavviare l’istanza (Apache2 o Docker).

ps: nella nuova versione dell'estensione DCATAP_IT per il CKAN 2.9x, il file da modificare non è profiles.py ma const.py

E’ necessario modificare, adeguandola, la sezione format_mapping con gli altri formati che, nel caso non presenti come formato distribuzione, possono essere automaticamente mappati per evitare OP_DATPRO.

E’ necessario tenere presente che il sistema riconosce la differenza tra maiuscole e minuscole per cui occorre controllare come è stato inserito il formato della risorsa (Json o JSON? xml o XML? GeoJSON o GEOJSON?):

format_mapping = {

'WMS': 'MAP_SRVC',

'HTML': 'HTML_SIMPL',

'CSV': 'CSV',

'XLS': 'XLS',

'ODS': 'ODS',

'XLSX':'XLS',

'JSON':'JSON',

'GEOJSON':'GEOJSON',

'GeoJSON':'GEOJSON',

'ZIP':'ZIP',

'pdf':'PDF',

'PDF':'PDF',

'XML':'XML',

'ARC': 'OP_DATPRO', # inserite tutti formati da mappare

}

In questo esempio il formato GeoJSON della risorsa, viene automaticamente associato al formato di distribuzione della risorsa: GEOJSON.


4. Come possiamo verificare i metadati del nostro catalogo dati, rispetto a possibili anomalie prima che vengano harvestati sul catalogo dati.gov.it?

Le anomalie più frequenti sono :

  1. Formato di distribuzione delle risorse, non settato correttamente. Questo genera “OP_DATPRO
  2. Licenza della Risorsa (non del Dataset) non settata o settata in maniera impropria. Questo genera la licenza “C1_Unknow” cioè “Licenza Sconosciuta
  3. Tema del Dataset non settato o impostato genericamente su “OP_DATPRO
  4. Formato di distribuzione delle risorse impostato sulla voce “ARC” oppure “ODATA” e non, invece, sul corretto formato della risorsa (CSV, XML, JSON ect)
  5. Frequenza di aggiornamento “Unknow” cioè “Sconosciuta”. Può essere una scelta consapevole oppure no.
  6. Scelta di una Licenza non applicabile ai dati di tipo aperto, secondo il paradigma degli OpenData. Per esempio per errore ci potrebbe essere una licenza CC-BY-NC.

Per poter controllare a livello visivo e macroscopico la qualità generale del proprio metacatalogo, si deve osservare il file presente nell’Endpoint.

Può essere un file TTL (esempio Comune di Palermo → https://opendata.comune.palermo.it/dcat/dcat.php ) oppure un file TTL derivato dal file RDF del proprio CKAN (esempio Comune di Crispiano → http://dati.comune.crispiano.ta.it/catalog.ttl che non è altro che catalog.rdf ma con .ttl finale in modo da non scaricarlo ma da visualizzarlo nel browser), o ancora l’API generica del proprio metacatalogo (Esempio Ministero del Lavoro → http://dati.lavoro.gov.it/SpodCkanApi/api/3/action/package_show?id=11414432-a7cd-4a73-9568-7b03fcd3ef46 )

PS: Per i cataloghi CKAN, se i dataset del proprio metacatalogo superano il numero di 100, è probabile che saranno disponibili N files catalog.rdf scaricabili aggiungendo ?page=x con x che va da 1 a NumeroDataset/100. Esempio dati.comune.xxxx.it/catalog.rdf?page=2

Facendo una semplice ricerca testuale, se si individuano “ARC”, “Unknow”, “C1_Unknow”, “OData”, OP_DATPRO” ci troviamo nei casi evidenziati. Vanno impostate “patch” come nelle FAQ precedenti nel caso di Cataloghi CKAN, oppure chiedere al fornitore di controllare se la mappatura dei formati è corretta.

Esempio:

Se si apre l’url di distribuzione della risorsa, si nota che il file è in formato “XML” mentre viene fornito come “OData” erroneamente.


Esempio:

update_frequency:

Può NON essere un errore ma una scelta consapevole.


Esempio:

od palermo

In questo caso dc:format viene esposto come tipo OP_DATPRO al posto di XML.


Esempio:

https://dati.emilia-romagna.it/dataset/comune-di-modena_air_quality_prediction_coverage_20211225/resource/bbb09d44-f8a5-4929-9631-3638489f3b91

Nei metadati si osserva la licenza chiusa, non compatibile con le licenze OpenData:

license

https://w3id.org/italia/controlled-vocabulary/licences/B11_CCBYNC40



5. La nostra amministrazione rilascia dataset da sensori con aggiornamenti continui. Come possiamo etichettarli per renderli fruibili, come “dati dinamici” tramite il catalogo nazionale Dati.Gov.it, anche in funzione di quanto previsto dal Piano Triennale?

Premesso che per la Direttiva Europea 1024/2019 “... i dati generati da sensori sono solitamente considerati dati dinamici”, il decreto legislativo 36/2006, come modificato dalla norma di recepimento della succitata direttiva, prevede:

“ «dati dinamici», documenti informatici, soggetti ad aggiornamenti frequenti o in tempo reale, in particolare a causa della loro volatilità o rapida obsolescenza”

Per questa specifica tipologia di dati, lo stesso decreto legislativo 36/2006 all’art. 6, comma 5, prevede:

“... le pubbliche amministrazioni e gli organismi di diritto pubblico rendono disponibili i dati dinamici per il riutilizzo immediatamente dopo la raccolta tramite API adeguate e, ove possibile, come download in blocco.”

e al successivo comma 6:

“Nei casi in cui l'espletamento dell'attivita' di cui al comma precedente ecceda le capacita' finanziarie e tecniche delle pubbliche amministrazioni e degli organismi di diritto pubblico, imponendo uno sforzo sproporzionato, i dati dinamici sono resi disponibili per il riutilizzo entro un termine e con temporanee restrizioni tecniche, da definirsi con apposito provvedimento dei titolari dei suddetti dati, tali da non pregiudicare indebitamente lo sfruttamento del loro potenziale economico e sociale.”

Sulla base di quanto previsto, ai fini del monitoraggio del Piano Triennale (obiettivo RA 2.1b) possiamo utilizzare, in fase di prima applicazione della norma, i seguenti criteri condivisi:

  • Utilizzare la proprietà “Frequenza di aggiornamento” del profilo di metadatazione indicando il valore “Continua” o, al massimo, “Quotidiana”, per i dataset coerenti con i presupposti normativi sopra citati.
  • Inoltre, per consentire una veloce e adeguata modalità di ricerca da parte degli utenti, possiamo utilizzare la proprietà “Parole chiave dataset” inserendo il termine: “dati-dinamici”.

Ciò permette una ricerca immediata sia sul metacatalogo locale sia su Dati.Gov.it e aiuta il monitoraggio dinamico perché è facilmente ricercabile tramite le API del catalogo nazionale.

Per esempio per i primi dataset già taggati come “dati-dinamici” si può usare la query:

https://dati.gov.it/opendata/api/3/action/package_search?fq=tags:dati-dinamici