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.

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.

Questo link dà errore 403.

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.

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!

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.

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..."

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.

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....

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

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?

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.)

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?
• ...