Aggiungere CI sul repo per i file .ttl

[ioggstream]

Mi aspetto

• un meccanismo di validazione dei commit sul repo almeno per i file .ttl
• la verifica controlla solo la directory latest

Invece

• non c'è

Note

• validare sintatticamente i file .ttl
• validare solo le directory latest
• Validare i metadati delle risorse semantiche con SHACL shapes #260
• limitare i path ad ascii ed il contenuto ad UTF8 #258
• Aggiungere linting dei file CSV, se presenti #259

Per gli altri tipi di file valuterei altre azioni.

[giorgialodi]

@bfabio @mfortini @Clou-dia anche questo mi sembra che un minimo di controlli ci siano.

[bfabio]

@giorgialodi vedrei per le ultime due voci nella checklist

@ioggstream sono già state implementate?

[ioggstream]

@bfabio non credo siano stati implementati.

I check sono parzialmente implementati in una libreria python esterna. - repo: https://github.com/teamdigitale/json-semantic-playground.git

. Puoi verificare dentro I pre-commit hooks.

Ove possibile, i check andrebbero integrati nei pre-commit hooks in modo da essere riusabili da tutti gli enti che partecipano, e configurati per-directory

[giorgialodi]

@bfabio cosa facciamo con questo issue?

Tra l'altro il terzo check non ha senso in generale rispetto al titolo dell'issue. Validare ogni file turtle ontologico con shacl shapes vuol dire creare le shacl shape per ogni ontologia e quindi ogni modello dei dati e al momento non è a roadmap di schema. È un lavoro molto vasto. Forse si intendeva per i metadati dei vocabolari controllati e c'è un altro issue relativo #225

[bfabio]

@giorgialodi IMO, dimmi se ti torna:

• validare usando shacl in base alle indicazioni presenti su https://docs.italia.it/italia/daf/lg-patrimonio-pubblico/it/stabile/index.html

La potremmo considerare #225, come dici tu, e in aggiunta crearne una nuova come tracciamento del lavoro più completo (che magari si farà in un lontano futuro o non si farà, ma almeno abbiamo un posto dove discuterne). Questo a meno che tu pensi sia una cosa troppo grossa rispetto al vantaggio che ci porterebbe.

Vedo comunque che la casella è segnata come fatta, il che è strano.

• limitare i path ad ascii ed il contenuto ad UTF8
• verificare il formato dei CSV

Queste due per me hanno abbastanza senso, creerei delle issue di per discuterne.

Saranno da implementare su https://github.com/teamdigitale/dati-semantic-cookiecutter

[giorgialodi]

@bfabio sì il primo punto mi torna. La questione shacl per ogni modello ontologico potrebbe anche avere senso ma proprio come lavoro molto futuro, ma molto molto. Al momento non è previsto. Penso fosse checkata per via di alcuni controlli minimi su alcuni vocabolari o su alcuni metadati, ma un conto sono i metadati descrittivi un conto è fare una valutazione via SHACL shapes di quanto modellato nell'ontologia.

Per gli ultimi due punti: se il CSV non lo imponiamo come si sta discutendo di recente su schema, non so. Magari se un'amministrazione lo mette avere un minimo di controllo ha senso. Invece UTF-8 ha senso eccome, per il resto vorrei capire meglio il tutto, soprattutto in questo contesto il riferimento al "path"

[ioggstream]

Vedo comunque che la casella è segnata come fatta, il che è strano.

• limitare i path ad ascii ed il contenuto ad UTF8
• verificare il formato dei CSV

C'è un minimo di validazione fatta tramite Frictionless se non ricordo male.

Saranno da implementare su https://github.com/teamdigitale/dati-semantic-cookiecutter

tutti i check vanno implementati nel repo centralizzato repo:

• https://github.com/teamdigitale/json-semantic-playground.git

ed importati via pre-commit da

• https://github.com/teamdigitale/dati-semantic-cookiecutter

Alcuni check sono implementati dentro questo repo perché non sono stati ancora generalizzati.
Una volta generalizzati possono essere implementati in

• https://github.com/teamdigitale/json-semantic-playground.git

[ioggstream]

@giorgialodi

un conto sono i metadati descrittivi un conto è fare una valutazione via SHACL shapes di quanto modellato nell'ontologia.

Corretto. L'obiettivo in prima battuta è evitare che vengano committati file che falliscono al momento dell'harvesting.

[giorgialodi]

sì ma l'harvesting @ioggstream fa harvesting di cose diverse: i vocabolari sono una cosa, le ontologie un'altra e hanno metadati loro. Inoltre il framework frictionless di solito viene usato per includere metadati di contenuto rispetto a intestazioni di colonne di dat espressi in CSV. A me sembra proprio fuori luogo qui perché 1) la semantica c'è già espressa negli standard relativi e nasce prima (spesso il CSV è derivato dall'RDF). Non siamo nel caso di dati CSV più disparati. Sono tutti uguali ed espressi con un'unica ontologia (che dà già la semantica) che è SKOS (ossia massimo 4 campi quando ci sono anche le alternative label e le descrizioni).

[ioggstream]

Frictionless per ora lo usiamo per verificare che i CSV abbiano i campi con valori uniformi (eg., che in una colonna con tutti interi non ci siano stringhe, ad esempio, o viceversa).
Poiché non governiamo ancora la creazione dei CSV (alcuni sono fatti a mano/con xls, altri con query, ...) può capitare che e.g. XLS interpreti male un campo e lo salvi in modo sbagliato (e.g., una data per un numero, un decimale con la virgola per una stringa).

Ovviamente è un tipo di controlli che va affinato, ma evita che dei dati sporchi (anche se generati da processi automatici) finiscano per rompere l'harvester o le API.

A regime l'ideale sarebbe definire un processo di proiezione RDF->CSV con json-ld framing, sparql o X. Ci ragioneremo spero presto.

[giorgialodi]

Ma non ci sono questi casi @ioggstream. I CSV sono codici (stringhe) e termini (stringhe). Non siamo parlando di un repo con dataset in CSV dove allora quello che scrivi DEVE essere fatto.
Sui CSV ci stavamo già ragionando in schema proprio per evitare di imporre questa cosa del CSV a PA che offrono già tutto con gli standard semantici del caso.

[ioggstream]

Che quei casi non ci siano deve essere stabilito da un software, non dalla buona fede del developer che crea il file ;)

That's it.

[giorgialodi]

@ioggstream chiaramente non sono d'accordo perché questo repository ha specifici contenuti e sappiamo bene la loro natura.