3. Criticità
● Diversi formati di input
○ sintatticamente diversi
○ record, item e value semanticamente diversi (e.g.
un record non è sempre la riga di una tabella)
● Caratteristiche inerenti vs dipendenti dal sistema
● Alcune metriche necessitano di metadati di contesto
(e.g. I-ACC-1 dipende dal datatype)
4. Soluzione proposta
Utilizzare RDF come stele di Rosetta tra formati, ontologie
standard (e all’occorrenza custom) per gestire il flusso dei
dati e SPARQL per effettuare le misurazioni
5. Resource
Description
Framework
Lo strumento proposto da W3C per: codifica, scambio e
riutilizzo di dati e metadati strutturati.
Consente l'interoperabilità semantica tra applicazioni che
condividono informazioni.
11. Vantaggi
● diversi formati riconciliati in un unico formalismo
● metadati associati a livello di dato
● misurazioni tramite query SPARQL
○ facilmente espandibili anche per misurazioni
non ISO/IEC 25024
12.
13. Vantaggi
● diversi formati riconciliati in un unico formalismo
● metadati associati a livello di dato
● misurazioni tramite query SPARQL
○ facilmente espandibili anche per misurazioni
non ISO/IEC 25024
● dati machine readable e actable tramite l’utilizzo
di ontologie standard (SHACL e DQV)
○ eventualmente espandibili
20. User journey
1. Alessio vuole analizzare la qualità di una anagrafica in formato CSV
2. Carica il file scelto e delinea i metadati (Shape) in SHACL, aiutato da
un’interfaccia con suggerimenti e autocompletamenti
3. L’attenzione di Alessio si sposta sull’interfaccia di scheduling, dove
trova la lista delle possibili misurazioni di qualità che può compiere. Si
accorge che non può lanciare alcune metriche relative all’accuratezza
perché i metadati che ha inserito non sono completi
4. Alessio torna nella schermata dei metadati e aggiunge le informazioni
mancanti
21. User journey
5. Ora Alessio lancia tutte e sole le misurazioni relative all’accuratezza: è
la metrica che gli interessa in questo studio
6. Nella schermata finale trova una visualizzazione di sintesi dei risultati: il
valore che vede non è ottimale
7. Alessio apre il dettaglio e scopre che la qualità degli indirizzi della sua
anagrafica è decisamente migliorabile
8. Si scarica allora i risultati in formato JSON e organizza una riunione...
29. Conclusioni
● Acquisizione di coscienza sulla qualità dei propri dati
○ Vedo quali sono gli aspetti più carenti quindi decido dove investire
per migliorare
○ Feedback costante: posso versionare la qualità dei dati e legarla
allo sviluppo del software
○ Creazione di una certificazione??
● Architettura modulare
○ A prova di futuro tramite ontologie e moduli facilmente espandibili
○ API REST: l’interfaccia può cambiare in base alle necessità