43 Matching Annotations
  1. Jul 2022
    1. 9.2.1.1. CSV (Comma Separated Values)

      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.

    2. 9.2.1.1. CSV (Comma Separated Values)

      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.

    1. Requisito 15

      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.

    2. d’uso chiara e

      Chiara o aperta? o chiara aperta?

    1. Fig. 4.2 Formati più comuni per i dati aperti e relativi livelli di apertura

      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

    1. 2.1. Legislazione nazionale ed europea

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

    1. Il miglioramento della qualità dei dati e la maggiore diffusione delle tecniche di misurazione dipendono da vari fattori tra cui l’adesione a modelli di qualità condivisi.

      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.

    2. si dovrebbe

      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!

    1. coerenti con il REQUISITO 27.

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

    1. Linee Guida Open Data

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

    2. 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.
    1. Tali requisiti e raccomandazioni dovranno essere applicati dopo l’entrata in vigore degli atti di esecuzione della Commissione Europea insieme alle specifiche indicazioni che in quegli atti sono riportate.

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

    2. Serie di dati di elevato valore

      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.

    3. Visto che non si può fare riferimento ancora ad atti adottati ufficialmente ed entrati in vigore

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

    1. by-passando

      Ignorando?

    2. se del caso

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

    3. La Direttiva evidenzia che, in questi casi, i tempi di risposta alle richieste di riutilizzo dei documenti dovrebbero essere ragionevoli ed essere in linea con il tempo necessario per rispondere alle richieste di accesso a un dato documento conformemente ai pertinenti regimi di accesso.

      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.

    1. Documentazione

      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.

    2. Nel caso a), il soggetto ha tutti gli elementi per rappresentare il proprio modello dati; viceversa, nei casi b) e c), la stessa amministrazione, in accordo con AgID, valuta l’opportunità di estendere il modello dati a livello nazionale.

      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.

    3. Utilizzando il framework RDF, si può costruire un grafo semantico, noto anche come grafo della conoscenza, che può essere percorso dalle macchine risolvendo, cioè dereferenziando, gli URI HTTP. Ciò significa che è possibile estrarre automaticamente informazione e derivare, quindi, contenuto informativo aggiuntivo (inferenza).

      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!

    4. un livello più alto di standardizzazione può essere raggiunto facendo riferimento a vocabolari controllati, quali elenchi di codici, tassonomie, classificazioni o terminologie,

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

  2. Jun 2022
    1. È importante notare che nella pratica si ritiene a volte necessario passare da modelli di rappresentazione tradizionali come quello relazionale per la modellazione dei dati operando opportune trasformazioni per poi renderli disponibili secondo i principi dei Linked Open Data. Tuttavia, tale pratica non è necessariamente quella più appropriata: esistono situazioni per cui può essere più conveniente partire da un’ontologia del dominio e che si intende modellare e dall’uso di standard del web semantico per poter governare i processi di gestione dei dati.

      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.

    2. utilizzano diversi standard e tecniche, tra cui il framework RDF

      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"

    3. a formati di dati a quattro stelle come le serializzazioni RDF o il JSON-LD

      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.

    4. linked data

      Sono open o no?

    5. il linking è una funzionalità molto importante e di fatto può essere considerata una forma particolare di arricchimento. La particolarità consiste nel fatto che l’arricchimento avviene grazie all’interlinking fra dataset di origine diversa, tipicamente fra amministrazioni o istituzioni diverse, ma anche, al limite, all’interno di una stessa amministrazione”

      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.

    6. Come detto, il collegamento (linking) dei dati può aumentarne il valore creando nuove relazioni e consentendo così nuovi tipi di analisi.

      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.

    7. i set

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

    8. deferenziati

      dereferenziati

    9. riducendo l’onere di manutenzione per i titolari di dati

      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.

    10. l riferimento non deve essere adeguato

      Semplicemente direi: il riferimento non cambia

    1. documento”

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

    2. di licenze standard,

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

    3. I dati pubblici che rientrano nell’ambito di applicazione delle presenti linee guida DEVONO essere messi a disposizione per il riutilizzo a fini commerciali e non commerciali: in formato leggibile meccanicamente, cioè, come da definizione presente nel Decreto, in “un formato di file strutturato in modo tale da consentire alle applicazioni software di individuare, riconoscere ed estrarre facilmente dati specifici, comprese dichiarazioni individuali di fatto e la loro struttura interna”; in formato aperto, cioè, come da definizione dell’art. 1 comma 1 lettera l-bis) del CAD, in “un formato di dati reso pubblico, documentato esaustivamente e neutro rispetto agli strumenti tecnologici necessari per la fruizione dei dati stessi”; accessibili attraverso le tecnologie dell’informazione e della comunicazione; gratuitamente o con i costi marginali sostenuti per la riproduzione, messa a disposizione e divulgazione dei documenti, nonché per l’anonimizzazione di dati personali o per le misure adottate per proteggere le informazioni commerciali a carattere riservato (v. par. Tariffazione); secondo i termini di licenze standard, disponibili in formato digitale (v. par. Licenze e condizioni di riutilizzo); provvisti dei relativi metadati (v. par. Metadati).

      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?

    1. Utilizza ‘namespace’ (spazi dei nomi) quando possibile

      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.

    2. 9.2.4.2. Formati per dati statistici

      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.

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

    4. Utilizza URI http per identificare le risorse

      Meglio ormai https per l'uso in diversi software

    5. URI HTTP,

      e in realtà se vogliamo essere pignoli, IRI

    6. Le intestazioni di colonna devono essere auto-esplicative ed essere incluse nella prima riga del file CSV. Senza le intestazioni, è difficile per gli utenti interpretare il significato dei dati.

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

    7. cronimo/ abbreviazio ne Titolo Organismo di standardizz azione URL

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

    1. 3.2. Termini e definizioni

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