sarebbe bello leggere qui una posizione che dice che se dai dati geospaziali HVD la Commissione definisce una lista con i dettagli precisi dei dati d'aprire, allora IGM si adeguta

mi chiedo come questo può tracciare le evoluzioni dei dati che vengono riusati e redistribuiti Es. il dato viene importato in OpenStreetMap che è un ente no profit internazionale (suppongo quindi che non viene visto come società privata) e poi viene redistribuito come dato di OpenSteetMap .. e poi riusato da aziende

credo sia necessario un requisito legato alla completezza dei dati e della garanzia del livello minimo di aggregazione. Es. numeri civici accompagnati da codice di avviamento postale limiti amministrativi al livello più dettagliato dell'amministrazione di rifeirmetno edifici che comprendano anche l'altezza ecc... Si trata di dettagli che fanno la differenza nel riuso

Io per essere sicura ribadirei che per tante altre categorie di dati (e.g. dati sulla salute, dati sulla giustizia / leggi, dati sull'energia, dati sul patrimonio culturale, dati sul procurement.) si consiglia di aprirli rispettando le solite regole. Non vorrei che si prendessero alla lettera solo alcune categorie e si dimenticassero tutte le altre... Qui siamo in linee guida nazionali sul tema open data che deve spaziare su tutto, non nella direttiva europea (c'è già quella a ricordarmi alcune cose).

Secondo me manca un raccordo con tutta la parte anche PDND. Un pezzo del registro imprese è parte dei dataset di alto valore e quindi da mettere a disposizione a tutti per il riutilizzo con API. Il registro imprese è banca dati di interesse nazionale e dovrebbe confluire nella PDND, quest'ultima poi consente di avere API su quei dati. Detta in altri termini, ci sono degli overlap tra questi dati e quelli che confluiscono nella PDND ma nulla si dice. Siccome nel gruppo di lavoro non c'è il dipartimento trasformazione digitale, né ISTAT né altri attori con ruoli sui dati, mi chiedo, quanto siano coordinate queste linee guida in generale con il resto.

Non sarebbe meglio scrivere "Visto che non si può ancora far riferimento a tali atti come ufficiali e in vigore, di seguito..."

importanza codifica caratteri

"... meglio se fornendo il file .prj stesso"

fondamentale la questione encoding dei caratteri

fondamentale che l'encoding usato per i caratteri sia una proprietà presente in qualsiasi foramto utilizzato

Se proprio bisogna dare delle indicazioni così specifiche, si deve inserire la raccomandazione (banalissima) che nella scelta del separatore di campo (; , tab ecc) si deve scegliere un separatore che poi non compare all'interno del testo dei campi, come purtroppo avviene spesso (p.es. nel campo descrizione del file dei consulenti della PA, spesso vi era all'interno del testo il punto e virgola, utilizzato come separatore di campo)

Raccomandare di descrivere sempre:

• qual è il separatore del CSV
• qual è l'encoding dei caratteri

Senza queste informazioni ci può essere un impatto di lettura difficilmente superabile. Specie per un CSV che non contiene nessun elemento descrittivo al suo interno.

La commissione economica per l'Europa (UNECE) mantiene un dataset in cui pubblica codici standard per indicare le unità di misura (Standardised codes from Recommendation 20). Il link al dataset è https://datahub.io/core/unece-units-of-measure

Un file per tabella, una riga per osservazione, una colonna per variabile.

Aggiungere qui una nota sulla grande opportunità/necessità di associare alle risorse in CSV, qualcosa che descriva le risorse: come "Metadata Vocabulary for Tabular Data" e "Model for Tabular Data and Metadata on the Web" o frictionless schema.

Il formato CSV è di gran lunga il più diffuso, ma nella quasi totalità dei casi si descrive soltanto il contenitore (il dataset), senza alcuna informazione sullo schema delle risorse. Questo ha un enorme impatto di utilizzo.

Come suggerito da Giorgia Lodi, questi metadati di contenuto potrebbero seguire le ontologie nazionali di OntoPiA (o il recentissimo "catalogo nazionale della semantica dei dati"), soprattutto per tutti quei dati indipendenti dal dominio specifico.

farei comunque anche presente la questione della gestioen del DRM http://mirrors.creativecommons.org/drafts/by_4.0d3.html#s2a3

l'obbligo comunque può essere fatto in maniera che non sia restrittivo nel riuso

Questo link dà errore 403.

concordo sull'importanza di queste caratterisitche, propongo comunque di permette il rilascio di dati anche incompleti di queste caratteristiche, chiedendo però di specificare i problemi e di chiedere di favorire il dialogo Qui si potrebbe anche valutare l'uso di licenze di tipo condivisione allo stesso modo come la ODbL facendo presente che, una volta risolti i problemi poi il dato viene rilasciato con una licenza meno restrittiva. (forse complesso come scenario)

Un documento come questo, è un'occasione imperdibile per fare cultura.

C'è un'evidente esigenza di dare valore ai dati di genere, di farli "apparire", per prendere decisioni che tengano conto della realtà. Senza attenzione ad aspetti come questi, c'è meno qualità dei dati, le analisi saranno monche.

Sfrutterei questa occasione, per indicare anche con una frase, l'enorme importanza del tema, come esempio in cui raccomandare la necessità di non aggregare i dati.

Le precedenti linee guida erano piene di raccomandazioni perché l'impianto normativo era diverso. Con queste linee guida, l'impianto cambia tanto che avete distinto tra si deve dal si dovrebbe. Coglie un po' di sorpresa vedere che la qualità dei dati è "solo" una raccomandazione e non un requisito. Come si pensa di fare effettivamente riutilizzo dei dati se non si richiede per esempio che almeno alcune caratteristiche di qualità del dato siano rispettate? Si dovrebbe garantire timeliness oer voi? o si deve garantire che il dato è aggiornato rispetto alla sua frequenza di aggiornamento? Io forse direi la seconda anche perché sono tanti anni che parliamo di queste cose. Un po' più di coraggio non guasta!

propongo un paragrafo 5.2.1 Richiesta di riutilizzo di open data con licenze incompatibili Questa sezione dovrebbe dare una linea guida su come comportarsi nei tre casi: - rilascio in CC0 => nessun problema - rilascio con licenza di attribuzione => dichiarare che si può cambiare la modalità di attribuzione a patto che ci sia uno spazio che permette di risalire alla sua sorgente. Nel caso poi di ulteriori restrizioni (come DRM previsto da CC-BY 4.0) si accettano forme analoghe di restrizione anche se diverse [queste osservazioni sono per permettere il riuso in OpenStreetMap) - caso di licenze di condivisione allo stesso modo qui è necessario dialogo fra le parti

attenzione ai casi (es OpenStreetMap e non solo) dove viene fatta richiesta di riutilizzo dei dati con licenza open data diversa o di poter avere il permesso di gestire le restrizioni in maniera diversa. Dal mio punto di vista questo dovrebbe essere un caso gestito a se con un suo paragrafo che delinea delle linee guida sui permessi di riutilizzo di dati aperti con restrizioni sulle licenze. Al momento ci sono diversi casi simili in Italia

Ignorando?

Se del caso o no? Se si deve promuovere il riutilizzo è del caso, no?

Ok, nella direttiva, ma linee guida dovrebbero dare un'indicazione, non dico puntuale se è complicato, ma almeno di massima. Cosa vuol dire ragionevoli? e cosa sono i "pertinenti regimi di accesso"? Siccome si vedono robe abbastanza assurde, forse meglio intervenire.

estendere dicendo "e del rispetto dei vincoli richiesti anche dalle licenze open data risolvendo eventuali problemi di gestione delle attribuzioni e di modalità di rilascio?"

qui penso sia necessario verificare di avere tutti i permessi per farlo Si vedono sempre pìu dataset rilasciati con coordinate ricavate da geocoder senza andare a vedere i termini di riuso se permettono poi di ridistribuire i dati come open data.

Il problema di questa sezione è derubricare i modelli dati come documentazione. Le ontologie di ontopia (parlo di modelli non tanto di dati come i vocabolari controllati) sono machine-readable. Quindi non è solo una questione di documentare la sintassi o il contenuto del dato. È rendere il modello actionable, ossia leggibile e interpretabile dalle macchine stesse. Io potrei benissimo documentare dei dataset con una bella tabellina in Github o con tante tabelline in un bellissimo PDF (documentazione), ma non è la stessa cosa di rendere disponibile un'ontologia per dei dati. Rendere i modelli parte attiva della gestione del dato (come per le ontologie) significa abilitare l'inferenza che avete richiamato sopra in maniera impropria per me, ma anche utilizzarli per explainable AI e tanti altri usi. Questo è un concetto fondamentale che non può essere trattato così in linee guida nazionali. Dovrebbe anzi avere un capitolo suo dedicato, vista l'importanza anche in ottica data quality "compliance" caratteristica di qualità dello standard ISO/IEC 25012.

Tutta la parte di modellazione dati, anche attraverso il catalogo nazionale delle ontologie e vocabolari controllati, sembra ora in mano a ISTAT, titolare, insieme al Dipartimento di Trasformazione Digitale di schema.gov.it. Qui però sembra AGID abbia il ruolo di definire i vari modelli. Secondo me questo crea confusione. bisognerebbe coordinarsi anche con le altre amministrazioni per capire bene chi fa cosa. AGID al momento di OntoPiA gestisce solo un'infrastruttura fisica.

Non è che fate inferenza perché dereferenziate gli URI. Vi suggerisco di leggere bene le linee guida per l'interoperablità semantica attraverso i linked open data che spiega cosìè l'inferenza (e questa sì fa parte di un processo di arricchimento nel mondo linked open data). L'inferenza è una cosa più complessa che si può fare con ragionatori automatici e query sparql. Si possono dedurre nuove informazioni dati dati esistenti e soprattutto dalle ontologie che sono oggetti machine readable!

Ho visto il documento qui riferito ma intanto parlano di vocabolari controllati RDF e qui non c'è scritto. Inoltre, a essere pignoli, il più alto livello di standardizzazione forse lo si raggiunge non solo con i vocabolari controllati ma anche con modelli dati/ontologie condivise. Chiaramente sono il publications office e devono sponsorizzare gli EU vocabulary, ma qui siamo su un livello nazionale. Io semplicemente direi che un buon livello di standardizzazione può essere raggiunto facendo riferimento a vocabolari controllati in RDF....

piccola nota: questo è anche uno dei motivi per cui non c'è compatibilità fra CC-BY 4.0 e ODbL

anche se forse è superficiale, in ogni caso rimarcherei qui quanto scritto nel'articolo 5 della legge sul diritto d'autore dove - nei fatti - si dichiara che atti e documenti della pubblica amministrazione sono in pubblico dominio. Credo sia un passaggio importante e chiarifichiatorio in quanto spesso si mettono licenze (aperte o meno) su questa categoria di documenti dove non `è necessario

Nella Direttiva UE il termine "documento" è esplicitato, ed è definito come "qualsiasi contenuto, a prescindere dal suo supporto (su supporto cartaceo o elettronico, registrazione sonora, visiva o audiovisiva)" Nel diritto italiano il termine "documento" fa riferimento quasi sempre ad un supporto cartaceo, o, comunque, ad un contenuto già strutturato. Visto che la direttiva è ovviamente sui "dati aperti", o si aggiunge qui "a tutti i documenti e i dati", oppure nel paragrafo "Termini e definizioni" si inserisce la definizione di "documento" contenuta nella Direttiva UE

Questo punto potrebbe generare confusione, non distinguendo i casi in cui l’URI rappresenta una risorsa/entità e i casi in cui ho più link verso i diversi formati con cui i dati sono resi disponibili (se ho interpretato bene questo punto). In ogni caso andrebbe specificato meglio.

Il requisito 15, se non ho sbagliato, sono i metadati DCAT-AP_IT. Ma i metadati OpenAIRE per i dati della ricerca? Che relazione c'è in quel caso? Perché in alcuni progetti europei richiedono certi metadati - https://guidelines.openaire.eu/en/latest/#horizon-2020-open-access-requirements. Il requisito 16, sempre se non ho sbagliato, riguarda dati territoriali e la necessità di metadatarli con i metadati RNDT. Qui non mi è chiaro: stiamo però parlando dei dati della ricerca, che è sezione a parte rispetto ai dati territoriali. Forse è bene chiarire con qualche esempio così da eliminare ogni dubbio.

Chiara o aperta? o chiara aperta?

Forse si può riprodurre in italiano. Ho qualche dubbio sul formato non proprietario XLSX. È molto dibattuto. Molti dicono che non è un open format perché non è un open standard. Quindi nel suggerire la traduzione in italiano, presterei un po' attenzione a quel caso

Questo paragrafo fa riferimento a diverse norme: è opportuno inserire gli hyperlink a queste in Normattiva.

In questo requisito, se ne cita un altro. Nella versione finale della guida sarebbe opportuno attivare hyperlink tra requisiti.

A mio avviso è molto più significativo il "vecchio" titolo: "Linee guida nazionali per la valorizzazione del patrimonio informativo pubblico". Propongo di mantenerlo

Aggiungere un capitolo su una lista di strumenti consigliati per "lavorare" con i dati aperti:

• strumenti di pulizia;
• strumenti di validazione;
• strumenti di trasformazione;
• strumenti di pubblicazione.

Mi fa pensare a enti della P.A., forse si potrebbe parlare di organizzazione in senso più generale.

c'è una ripetizione

Cambierei la frase in: "La dereferenziazione degli URI consente di risolvere ..." oppure "Considerato, inoltre, che gli URI possono essere dereferenziati, l'etichetta può essere risolta in qualsiasi lingua ... "

mi sembra tautologico

non è chiaro se i dati da fonti esterne sono i dati esistenti, o se i dati esistenti sono quelli creati

è un concetto o un processo?

Inserire riferimento con nota a piè pagina

Non trovo utilità in quanto qui scritto onestamente. Molti più sistemi sono ormai linked open data nativi, quindi oltre al fatto che parlare di linked open data in arricchimento è sbagliato, direi di lasciar perdere questo periodo.

rifraserei in "si basano su diversi standard, tra cui RDF, e spesso usano vocabolari controllati RDF per rappresentare terminologia controllata del dominio applicativo di riferimento"

JSON-LD è una serializzazione RDF nel mondo JSON. Occhio che qui la traduzione in italiano del documento del publications office non è venuta fuori bene (loro dicono data format such as RDF or JSON-LD che sarebbe anche impreciso. RDF è un modello di rappresentazione del dato nel Web. Le serializzazioni RDF sono tipo Ntriple, RDF/Turtle, RDF/XML, JSON-LD). Tra l'altro nell'allegato tecnico sui formati per i dati aperti, testo preso dalla precedente linee guida, JSON-LD è indicato come serializzazione RDF.

Sono open o no?

Qui c'è un problema di fondo proprio concettuale. Il problema è che il paradigma dei Linked Open Data è stato derubricato come arricchimento, che nelle linee guida che si cita qui era solo una fase di un processo generale per la gestione dei dati linked open data. Fare linked open data non vuol solo dire arricchire i dati, ma è possibile gestire un dato fin dalla sua nascita in linked open data nativamente. Questo era lo spirito delle linee guida qui citate. Estrapolando solo una parte avete snaturato un po' tutto. Consiglio di trattare l'argomento com'era trattato nelle precedenti linee guida. Peccato anche che sia sparita la figura della metropolitana che aiutava molto.

Comunque, farei uno sforzo in più, con tutto quello che l'italia ha scritto sui linked open data, per scrivere frasi che non siano proprio paro paro la traduzione in italiano del documento in inglese.

si può usare anche l'italiano. Insieme di dati

dereferenziati

Ma anche per quelli che li usano, non si devono preoccupare di aggiornare le varie label, che è molto più complesso. Forse chiamare anche il concetto di once-only non sarebbe male.

Semplicemente direi: il riferimento non cambia

mi sembra superfluo e non proprio discriminante per i livelli 4 e 5

Forse evidenzierei di già la possibilità di usare standard come SPARQL per accedere ai dati. Mentre per accedere ai dati in CSV (o dati su database) ho necessità di creare delle interfacce ad-hoc

mi sembra superfluo

Specificando che si tratti della stessa risorsa (owl:sameAs), oppure si sta facendo riferimento al dereferencing in cui in base al tipo di richiesta viene fornito la pagina Web o la sua rappresentazione in RDF? Il dubbio mi è venuto leggendo l'ultimo paragrafo in cui parla di content negotiation.

molto vago, servizi per fare cosa?

per le risorse astratte no?

non vorrei che questa frase generasse confusione. Distinguerei tra formati (CSV, JSON, ...) e modelli (RDF). SPARQL definisce uno standard di risposta basato su XML, il quale può essere semplicemente trasformato in CSV o JSON, però la parte interessante di SPARQL è quella di lavorare su basi di conoscenza.

in genere una query SPARQL sta su un link, quindi non parlerei di pochi click ma di uno solo :-)

Posto in questi termini sembra molto astratto. Forse un esempio potrebbe aiutare a chiarire?

Mi aspettavo di trovare nella tabella standard di riferimento per la pubblicazione dei dati. Poi però trovo anche SPARQL. In aggiunta, troviamo nella stessa tabella, ontologie note, standard, schemi, modelli. Questa tabella aggrega troppe cose diverse tra loro.

Si potrebbe indicare come raccomandazione il riutilizzo di schemi esistenti (es. Ontopia).

Questa cosa non è chiara per nulla. Cosa si voleva dire? Si intende forse il fatto di usare namespace prefix visto quello che c'è scritto sotto (e.g, riducono al verbosità)? Ma poi intendete applicarlo solo a RDF/XML e RDF/Turtle? Comunque spazio dei nomi non si è proprio mai sentito :) In questo caso, se lasciate solo l'inglese essendo una cosa molto tecnica va bene uguale.

La stessa cosa della sezione 9.2.4.1 vale anche qui: chi mi impedisce di usare RDF? RDF DataCube infatti è la versione RDF di SDMX. Se il regolamento europeo magari fa esempi, perché è appunto un regolamente, in linee guida nazionali con allegati tecnici bisogna essere più puntuali dal punto di vista tecnico.

Nella sezione 9.2.4.1 - Chi mi impedisce di usare RDF per esempio? In questa sezione, sembra che, a parte delle rappresentazione ben precise, di solito si usi il JSON e finisce lì. Ma nessuno mi impedisce di usare anche standard del web semantico. Suggerimento quindi è di non scrivere necessariamente "oltre al JSON".

Meglio ormai https per l'uso in diversi software

e in realtà se vogliamo essere pignoli, IRI

Proprio a integrazione del commento di @aborusso direi che le intestazioni dovrebbero seguire le etichette dei concetti definiti nelle principali ontologie italiane di OntoPiA qualora il dato fosse già modellato. Esempio: "indirizzo completo" (proprietà full address dell'ontologia CLV-AP_IT) per indicare l'indirizzo completo presente in tantissimi dataset (aperti).

In questa tabella c'è un calderone di roba diversa messa sullo stesso piano e questo crea a mio avviso solo confusione. Mi spiego: OWL, SPARQL, RDF, RDFS insieme a RNDT, NUTS e via dicendo è singolare. Inoltre, chissà perché l'assenza di XML a questo punto. Ok che la lista non è esausitva ma non si capiscono i criteri della lista. Intanto OWL, SPARQL, RDF, RDFS sono standard building block per la realizzazione di un nuovo modello di rappresentazione del dato nel web. ONTOPIA, DCAT, DCAT-AP_IT, DataCube ecc. sono tutti standard per la rappresentazione di specifici domini che poggiano (usano) sugli standard dello stack del web semantico prima citati. Suggerimento, mettere in evidenza queste differenze magari anche creando diverse tabelle, indicando i domini applicativi che coprono gli standard (e.g., DataCube per la rappresentazione di SDMX in RDF, quindi contesto dei dati statistici, OntoPiA copre tutta una serie di domini, DCAT metadatazione di dati in cataloghi, EU vocabularies coprono diversi domini ecc.)

Secondo me si può generare confusione tra documento e dato, soprattutto in un mondo quello della PA che è ancora troppo basato solo su documenti. I documenti sono appunto una rappresentazione di dati, come qui indicato.Tipicamente si parla di dati non strutturati. Sono concetti diversi quindi. Al di là del termine usato nella normativa, in linee guida naizonali ci si asptta di chiarire bene questo aspetto. e sotto si parla "di documenti pubblici che hanno le caratteristiche dei dati aperti".

licenze aperte standard. Aggiungere la parola aperte che è fondamentale.

Immaginare - specie per blocchi così importanti - una FAQ, utile per le PA e per le persone. Alcune domande/spunti di esempio:

• se una PA pubblica un cruscotto statistico in PDF (sotto un esempio), la cittadinanza può pretendere che i dati siano pubblicati come previsto da queste linee guida?

• se le persone riscontrano il non rispetto di questi requisiti, cosa possono fare? Scrivono al Difensore Civico?

• se io PA non rispetto queste linee guida, cosa avviene?

• se una azienda partecipata comunale raccoglie dati ambientali in modo continuo, e li pubblica in PDF e/o con scarsa frequenza (ad esempio mensile), siamo anche in questo caso a un non rispetto di queste linee guida e quindi si possono pretendere dati aggiornati dopo la raccolta e pubblicati via API?

Manca un vero e proprio glossario Open Data, a cui si possa fare riferimento, da mettere a fattor comune con chi è nuovo a questo contesto. Ad esempio:

• cosa è un dataset?
• cosa è una risorsa?
• cosa vuol dire leggibile meccanicamente?
• ...