dcatapit su Ckan (e datigov). fermi al palo

[Francesco Piero Paolicelli]

Ciao a tutti.

Credo che questa sia una cosa da comunità. 

Come sapete Agid ha dato le dritte per il Dcatapit.

In Trentino - Alto Adige hanno sviluppato un plugin che funziona bene per il singolo dataset ma ho scoperto essere buggato sul catalog.rdf del catalogo generale.

vale su tutti i siti web ckan su cui è stato installato. io ne segui 8. Ho visto che il problema ovviamente lo hanno anche gli altri .

ho aperto da 2 mesi una issue ma oggi gli sviluppatori mi dicono che non ci sono sviluppi. l'Italia è ferma al palo. 

Dico l'Italia perchè se ckan faticosamente adeguati NON danno un catalog.rdf corretto, l'harvesting su datigov è parziale e/o errato..

Ho spiegato tutto nella issue di 2 mesi fa:

https://github.com/geosolutions-it/ckanext-dcatapit/issues/50

non sono molto pratico di python e credo che se ci mettiamo a lavorare tutti assieme, troviamo la risoluzione.

1) il plugin europeo dcatap funziona su siti esteri. quindi dominiockan/catalog.rdf viene generato con i campo frequency, rightsholder, thema ect correttamente

2) installando oltre al plugin dcat anche il dcatapit il catalog.rdf NON legge più i campi di sopra e mette valori di default (frequency=unknow, thema provvisorio ect) mentre il singolo dataset/nomedataset.rdf viene generato correttamente. teoricamente datigov potrebbe lanciare la query per la lista dataset e poi per ciascun dataset leggere i metadati ma rallenta tutto il processo di harvesting. il catalog.rdf serve a questo....

Che dite, diamo una mano ?

credo che sia una cosa molto trasversale e "vitale" alla luce di tutti i discorsi di sostenibilità ect 

Piersoft

Inviato da iPhone

[Francesca Gleria]

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Spaghetti Open Data" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a spaghettiopendata+unsubscribe@googlegroups.com.
Visita questo gruppo all'indirizzo https://groups.google.com/group/spaghettiopendata.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/spaghettiopendata/58B55705-2A97-41C5-B7F0-E371598BAF3B%40gmail.com.
Per altre opzioni visita https://groups.google.com/d/optout.

--

Cellulare 380.4908599  Casa 0461.982380 Lavoro 0461 494436

[Francesca Gleria]

Apperò  si stava parlando da mò con Marco di come risolvere sta cosa, si stava aspettando un po' di calma. 

Operativamente dare una mano come ?

@Marco C. che dici ?

[Marco Combetto]

Lungi da me a dire che non la fix non serva, ma attualmente dati.gov.it utilizza le API CKAN e non l'estensione DCATAPIT per fare l'harvesting dei cataloghi locali. 

Almeno vale per noi e vale per BZ e la Toscana. Sviluppare la fix è solo un parte del problema, se approcciamo al problema in modo generale e per tutti i CKAN italiani.

Poi ci sono gli altro cataloghi non CKAN, e li ci sono altri problemi.

Il Team Digitale ed AGID stanno rivendendo la procedura di harvesting e ci sarà un upgrade e in tale senso, alcuni mesi abbiamo fatto delle prove di harvesting (ma solo come test) con l'estensione DCAT-AP. All'interno di queste attività, o lato nostro (insieme a BZ), o centralmente, errà abbastanza facile sistemare anche questa anomalia.

Stiamo definendo la lista di interventi e poi si farà il procurement necessario

Certo, purtroppo, che si tratterà di alcuni mesi, direi entro la fine dell'anno potrebbe essere (e io sarei contento) tutto basato su DCAT-AP-IT (fixed)

[Francesco Piero Paolicelli]

Marco, l'harvesting di un catalogo adeguato al dcatapit è semplice quanto quello dalle API.

Anzi è ancora meglio perchè mappa velocemente tutti i dataet e tutti i metadati partendo dal catalog.rdf

ho trovato il bug e la risoluzione tampone, ma non ho le competenze in python per patchare l'unico file da modificare.

E' probabile che con un if (campo addizionale = null) campoaddizionale="N/A" si risolve ma non è il costrutto il problema ma il campo nella tabella che non so come si chiama. gli sviluppatori lo farebbero in 5 minuti ora che ho dato la soluzione, io un 10 ore :)

l'importanza è abissale. datigov è già pronto per l'harvesting dal catalog.rdf (non sono quasi certo). in un paio d'ore almeno il trentino altoadige, la toscana, e i "miei" cataloghi comunali sarebbe importati decentemente e da li a europeandataportal

Piersoft

Inviato da iPhone

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "Spaghetti Open Data" di Google Gruppi.

Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a spaghettiopend...@googlegroups.com.

Visita questo gruppo all'indirizzo https://groups.google.com/group/spaghettiopendata.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/spaghettiopendata/3941a62c-b923-4fd9-8e2f-f15e398541cc%40googlegroups.com.

[Francesco Piero Paolicelli]

Piersoft

Inviato da iPhone

(Inizio messaggio inoltrato)

Da: Francesco Piero Paolicelli <pier...@gmail.com>
Data: 26 luglio 2017 09:27:26 CEST
A: "Open Data & Analytics" <da...@teamdigitale.governo.it>
Oggetto: Re: dcatapit su Ckan (e datigov). fermi al palo

forse ho trovato il bug. ho controllato tutti i campi. verso le 4 di notte ho iniziato la fase "nevrosi".

Ho compilato tutti i campi ed ha funzionato. Anche quelli opzionali. Ho iniziato a cancellarli uno ad uno e ho scoperto che:

1) il "Campo extra" non può rimanere vuoto. Allego screenshot

2) ckan.locales_offered = it o altra lingua è opportuno che sia compilato

​

l'ho testato in locale su un ckan di prova (che per la cronaca è interfacciato con data.world/piersoft ) e poi su uno in produzione di un ente che gestisco. 

Se mi date conferma avviso gli sviluppatori. Il punto è che vanno aggiornati tutti i dataset esistenti nel catalogo o creata una patch che se il campo è vuoto va riempito..

piersoft

Il giorno 25 luglio 2017 23:12, Francesco Piero Paolicelli <pier...@gmail.com> ha scritto:

scusate il crosso posting tra ML ma credo che questo argomento sia proprio appannaggio di tutti.

piersoft

---------- Messaggio inoltrato ----------
Da: Francesco Piero Paolicelli <pier...@gmail.com>
Date: 25 luglio 2017 17:45
Oggetto: dcatapit su Ckan (e datigov). fermi al palo
A: spaghettiopendata@googlegroups.com

Ciao a tutti.

Credo che questa sia una cosa da comunità. 

Come sapete Agid ha dato le dritte per il Dcatapit.

In Trentino - Alto Adige hanno sviluppato un plugin che funziona bene per il singolo dataset ma ho scoperto essere buggato sul catalog.rdf del catalogo generale.

vale su tutti i siti web ckan su cui è stato installato. io ne segui 8. Ho visto che il problema ovviamente lo hanno anche gli altri .

ho aperto da 2 mesi una issue ma oggi gli sviluppatori mi dicono che non ci sono sviluppi. l'Italia è ferma al palo. 

Dico l'Italia perchè se ckan faticosamente adeguati NON danno un catalog.rdf corretto, l'harvesting su datigov è parziale e/o errato..

Ho spiegato tutto nella issue di 2 mesi fa:

https://github.com/geosolutions-it/ckanext-dcatapit/issues/50

non sono molto pratico di python e credo che se ci mettiamo a lavorare tutti assieme, troviamo la risoluzione.

1) il plugin europeo del Ckan "dcatap" funziona su siti esteri. quindi dominiockan/catalog.rdf viene generato con i campi frequency, rightsholder, thema ect correttamente.

2) installando oltre al plugin dcat anche quello "dcatapit" il catalog.rdf NON legge più i campi di sopra e mette valori di default (frequency=unknow, tema provvisorio ect) mentre il singolo dataset/nomedataset.rdf viene generato correttamente. teoricamente datigov potrebbe lanciare la query per la lista dataset e poi per ciascun dataset leggere i metadati ma rallenta tutto il processo di harvesting. il catalog.rdf serve a questo....