Agenda Digitale Lombarda
Linked Open Data
Versione 1.0
Luglio 2014
A cura di:
Regione Lombardia
Direzione Centrale PIeF
Struttura Attuazione delle agende regionali di semplificazione e di digitalizzazione.
Responsabile: Oscar Sovani
Lombardia Informatica S.p.A.
Presidenza – Progetto di Ricerca e Innovazione
Responsabile: Vicepresidente Alberto Daprà
Coordinamento lavori: Paolo Tacchino
Direzione Sistemi Regione
Coordinamento lavori: Daniele Crespi
Redazione:
[email protected] | www.crisp-org.it
Roberto Boselli
Ettore Colombo
Matteo Fontana
Nicolò Vegetti
Laboratorio di Ricerca IT Lab 2.0
Sommario
1
Introduzione ......................................................................................................................................... 3
2
Linked Open Data ................................................................................................................................. 4
2.1
2.2
2.3
2.4
Introduzione ai Linked Open Data .............................................................................................. 4
2.1.1
Cenni storici ................................................................................................................... 4
2.1.2
Motivazioni .................................................................................................................... 5
2.1.3
Le tecnologie.................................................................................................................. 6
2.1.4
LOD cloud....................................................................................................................... 8
2.1.5
LOD in Italia.................................................................................................................. 10
2.1.6
LOD casi di successo .................................................................................................... 12
Strumenti adottati .................................................................................................................... 14
2.2.1
Introduzione ................................................................................................................ 14
2.2.2
Protégé ........................................................................................................................ 14
2.2.3
LOD Refine ................................................................................................................... 14
2.2.4
Openlink Virtuoso Universal Server ............................................................................. 15
Il progetto ITLab e la costruzione dei LOD sui servizi in regione Lombardia ............................ 16
2.3.1
Introduzione ................................................................................................................ 16
2.3.2
Costruzione ontologia dei servizi ................................................................................. 17
2.3.2.1
Prima versione dell’ontologia ...................................................................... 18
2.3.2.2
Creazione dell'ontologia dei servizi pubblici con Protégé............................ 23
2.3.2.3
Versione implementata ................................................................................ 28
Procedura di conversione dal CSV a RDF e LOD ....................................................................... 30
2.4.1
Gli open data di regione Lombardia ............................................................................ 30
2.4.2
LODRefine: manipolazione del dataset, da CSV a RDF ................................................ 32
2.4.2.1
Importazione del dataset ............................................................................. 32
2.4.2.2
Pulizia dei campi ........................................................................................... 32
2.4.2.3
Riconciliazione .............................................................................................. 34
2.4.2.4
Definizione RDF schema ............................................................................... 36
2.4.2.5
Integrazione ontologia con ogni RDF ........................................................... 38
2.4.3
Pubblicazione sull'endpoint ......................................................................................... 40
2.4.4
Esempi di interrogazioni dell’endpoint SPARQL .......................................................... 42
2.4.4.1
2.5
3
Alcune considerazioni .................................................................................. 46
Conclusioni ............................................................................................................................... 48
Bibliografia e sitografia ....................................................................................................................... 50
Agenda Digitale – Linked Open Data
1
Indice delle figure
Figura 1 Esempio di grafo RDF ........................................................................................................................... 6
Figura 2 LOD cloud diagram............................................................................................................................... 9
Figura 3 Distribuzione di triple per dominio .................................................................................................... 10
Figura 4 Livello di qualità Open Data in Italia .................................................................................................. 11
Figura 5 Enti che pubblicano LOD in Italia ....................................................................................................... 11
Figura 6 Dataset LOD collegati a BBC Music .................................................................................................... 12
Figura 7 Screenshot da BBC Music .................................................................................................................. 12
Figura 8 Screenshot dal Portale Storico Camera dei Deputati ........................................................................ 13
Figura 9 Modello UML del CPSV ...................................................................................................................... 19
Figura 10 Modello di servizio ITLab 2.0 ........................................................................................................... 20
Figura 11 Diagramma del LGBM ...................................................................................................................... 21
Figura 12 Grafo della prima versione dell'ontologia dei servizi ...................................................................... 23
Figura 13 Screenshot da Protege con l'IRI dell'ontologia ................................................................................ 23
Figura 14 Screenshot da Protégé con schermata principale ........................................................................... 24
Figura 15 Screenshot da Protege con ontologia importata............................................................................. 24
Figura 16 Tab Classes ....................................................................................................................................... 25
Figura 17 Annotation della classe PublicService ............................................................................................. 26
Figura 18 Informazioni ontologiche della classe PublicService ....................................................................... 26
Figura 19 Tab Object Properties ...................................................................................................................... 27
Figura 20 Tab Individuals ................................................................................................................................. 27
Figura 21 Grafo della versione implementata dell'ontologia dei servizi ......................................................... 29
Figura 22 Screenshot del portale www.dati.lombardia.it ............................................................................... 31
Figura 23 Screenshot della tabella del dataset delle RSA accreditate............................................................. 31
Figura 24 il dataset delle RSA accreditate caricato in LODRefine.................................................................... 32
Figura 25 Particolare del menu dei comandi in LODRefine per la gestione delle colonne dei dataset .......... 33
Figura 26 Particolare del menu dei comandi in LODRefine per la gestione delle celle ................................... 33
Figura 27 Analisi della NATURA_GIURIDICA delle RSA accreditate in LODRefine ........................................... 34
Figura 28 Riconciliazione tramite LODRefine-GUI ........................................................................................... 35
Figura 29 Colonna COMUNE_UBICAZIONE dopo la riconciliazione. Selezione del comune di Albino ............ 36
Figura 30 Dettaglio della finestra di costruzione dello schema RDF ............................................................... 37
Figura 31 Grafo dell’ontologia ottenuta integrando schema RDF e ontologia dei servizi per le RSA ............. 38
Figura 32 Dataset RSA nel portale regionale, è evidenziato un record di esempio ........................................ 39
Figura 33 Dataset RSA, elenco delle classi in Protégé ..................................................................................... 39
Figura 34 Gerarchie delle classi nelle ontologie dei dataset considerati ........................................................ 40
Figura 35 Schermata web per l'interrogazione dell'endpoint con query SPARQL .......................................... 41
Figura 36 Schermata web della pagina di DBPedia Italia per il comune di Gromo ......................................... 46
2
Agenda Digitale – Linked Open Data
1 Introduzione
Tra le attività che vanno ad attuare l’Agenda Digitale Lombarda, Regione Lombardia ha posto in essere fin
dal 2012 vari interventi per favorire la valorizzazione del patrimonio informativo pubblico; tra questi, ha
chiesto anche uno studio per verificare quali possano essere le modalità ideali di pubblicazione di dati
rispettando le indicazioni della comunità internazione sui Linked Open Data (LOD). Lombardia Informatica
si è avvalsa del CRISP 1 (con cui collabora da alcuni anni all’interno del progetto ITLab 2) per effettuare uno
studio che, partendo dagli Open Data pubblicati sul portale regionale www.dati.lombardia.it, andasse a
proporre un modello per fare diventare alcuni di quei dataset dei LOD.
Questo documento contiene la relazione delle attività svolte da CRISP e Lombardia Informatica nell'ambito
del progetto ITLab da ottobre 2013 ad aprile 2014 e presenta i risultati finali ottenuti e i prototipi
sviluppati.
Per fare diventare alcuni dataset selezionati "Linked Open Data" sono state svolte queste attività:
• sviluppo dell’ontologia dei servizi;
• conversione in formato RDF di cinque dataset individuati in uno stesso ambito, con la creazione dei
corrispettivi schemi RDF;
• integrazione dell'ontologia in ciascuno dei cinque schemi e pubblicazione dei dati sull'endpoint SPARQL;
• test dell'endpoint SPARQL con alcune query di prova con i relativi risultati.
In conclusione del documento si presentano alcune osservazioni sui benefici, sui punti critici evidenziati
durante il progetto, e sui possibili sviluppi futuri.
1 centro di ricerca interuniversitario per i servizi di pubblica utilità http://www.crisp-org.it/
2 Il laboratorio IT Lab 2.0 nasce da una convenzione tra Lombardia Informatica e CRISP e ha l'obiettivo di sviluppare ricerche per lo
sviluppo di prototipi tecnologici da applicare al settore dei servizi, focalizzando l'attenzione sulle seguenti tematiche:
•
Il ruolo dell'IT come fattore abilitante di innovazione nei servizi;
•
L'IT come strumento a supporto della collaborazione nei servizi (Web 2.0 e cooperazione);
•
L'impatto dell'IT sulle politiche e sulla governance dei servizi;
•
I sistemi di Business Intelligence (BI) e Decision Support Systems (DSS) applicati ai servizi;
•
I modelli, le strategie e le architetture per l’interoperabilità.
•
Open Data, Linked Open Data; ontologie per la definizione dei servizi
•
Strumenti e algoritmi per la Data governance e data quality.
Agenda Digitale – Linked Open Data
3
2 Linked Open Data
2.1 Introduzione ai Linked Open Data
L'obiettivo del progetto ITLab sul tema Linked Open Data è stato lo studio e la definizione delle modalità di
creazione e pubblicazione di dataset in formato Open Data a 5 stelle, da applicare ai dataset presenti sul
portale Open Data della Regione Lombardia 3. Le 5 stelle rappresentano il livello più alto di qualità (secondo
la scala di Berners-Lee 4) previsto per gli Open Data (diventando così Linked Open Data - LOD), perché
permettono il maggior numero di attività possibili sui dati e il massimo grado di interoperabilità tra dataset
diversi. Per maggior completezza si ripresenta la descrizione dei cinque livelli di qualità e di riusabilità dei
dati:
1. Una Stella: il livello base, costituito da file non strutturati: ad esempio un’immagine in formato grezzo
(.gif, .jpg, .png), un documento in formato Word, un file in formato pdf;
2. Due Stelle: indica dati strutturati ma codificati con un formato proprietario, ad esempio un
documento in formato Excel;
3. Tre Stelle: indica dati strutturati e codificati in un formato non proprietario, ad esempio il formato
.csv (Comma Separated Values);
4. Quattro Stelle: indica dati strutturati e codificati in un formato non proprietario che sono dotati di un
URI, quindi indirizzabili e utilizzabili direttamente online, attraverso l’inclusione del modello RDF
(Resource Description Framework);
5. Cinque Stelle: indica quelli che vengono definiti Linked Open Data (LOD), cioè dataset di dati in RDF
collegati tra loro.
Il formato Linked Open Data è uno standard, definito dal W3C 5, basato su modelli, tecnologie e linguaggi
del Semantic Web, che consente la pubblicazione, l'interrogazione e il consumo su Web di dati strutturati in
formato RDF, distribuiti tra diversi server. Tale standard richiede il rispetto di 4 regole fondamentali:
•
•
•
•
usare indirizzi Web (Uniform Resource Identificator - URI) come nomi per le “cose”;
usare URI utili al protocollo HTTP in modo che sia possibile cercare e risolvere quei nomi;
quando qualcuno cerca una URI, fornire un’informazione utile;
includere link ad altre URI, così da permettere a chi cerca di scoprire nuovi collegamenti.
Grazie al rispetto di tali regole i dati hanno un reale indirizzo nel Web, sono quindi rintracciabili e possono
essere riutilizzati online.
2.1.1 Cenni storici
Nel 2001 Tim Berners-Lee, James Hendler e Ora Lassila pubblicavano un articolo che sarebbe diventato una
pietra miliare per la comunità scientifica, con il quale essi lanciavano il Web semantico definendolo come
una "[...] estensione del Web attuale, in cui all'informazione è dato un ben determinato significato,
facilitando la cooperazione tra i computer e le persone" 6. L'enfasi è quindi posta ai dati e all'interpretazione
3
www.dati.lombardia.it
Berners-Lee, T., “Linked Data”, http://www.w3.org/DesignIssues/LinkedData.html, 2012
5
http://www.w3.org/wiki/SweoIG/TaskForces/CommunityProjects/LinkingOpenData
6
Berners-Lee, T., Hendler, J. and Lassila, O., "The semantic web." Scientific american 284.5 (2001), pp. 28-37.
4
4
Agenda Digitale – Linked Open Data
del loro significato da parte degli elaboratori. Nel 2006 lo stesso Berners-Lee pubblicava "The Semantic
Web Revisited" 7 con il quale affermava che il raggiungimento del Web semantico era ancora lontano, si
richiedeva ancora un ampio sforzo nello sviluppare standard, ontologie e applicazioni, ma che l'apporto di
dati proveniente dal Social Web avrebbe portato nuova linfa al progetto, e grazie alla progressiva e
crescente pubblicazione di dati in RDF esso sarebbe divenuto realtà. Nello stesso anno Berners-Lee definiva
le regole dei Linked Data sopra descritte 8. Oggi si parla di Web of Data come strato fondamentale per
realizzare il Web semantico su scala globale, e diventa possibile solo se i dati vengono “linkati” tra loro
seguendo le direttive di Berners-Lee e del W3C.
2.1.2 Motivazioni
Date queste premesse fondamentali è necessario chiarire perché una Pubblica Amministrazione dovrebbe
pubblicare dataset in formato LOD. Innanzi tutto, i LOD possono definire in modo condiviso e
semanticamente espressivo il patrimonio informativo gestito dalle PA. Inoltre con i LOD si possono
enfatizzare collegamenti con altri dataset di dati pubblici e rendere universale l'accesso a tali dati, e ciò li
abilita a diventare la base di un nuovo paradigma applicativo.
Le PA italiane sono sollecitate a pubblicare sul Web i propri dati in formato aperto (Open Data) 9, cioè
accessibili online, privi di forme di controllo e restrizioni come copyright e brevetti, che ne limitano
l’integrazione, la riproduzione e il riutilizzo. Una volta pubblicati, tali dati aumentano sensibilmente il loro
valore conoscitivo quando dataset differenti, prodotti e pubblicati in modo indipendente da diversi
soggetti, possono essere incrociati liberamente da terze parti. Ciò permette in prima battuta
l'interoperabilità dei dati, e poi possono diventare la base per la creazione di nuove applicazioni e servizi, e
quindi diventare anche propulsori economici per la nascita di nuove start up, e posti di lavoro. Per far ciò è
necessario però che si attivi una collaborazione tra diverse PA, aziende e cittadini, e soprattutto che sia
esplicitato un linguaggio comune, una semantica per dati strutturati con chiavi di lettura univoche. Questo
è possibile grazie all'utilizzo dei linguaggi, strumenti e standard del Web semantico.
La visione della comunità dei Linked Data è molto semplice: trasformare il Web in un ambiente aperto e
interoperabile dove i dati non siano chiusi in silos indipendenti, ma collegati tra loro. Inoltre per i dati delle
PA si vuole che essi diventino dati di interesse pubblico, in modo che persone e applicazioni possano
accedere e interpretare i dati utilizzando le comuni tecnologie Web. Il termine Linked Data non descrive
infatti ulteriori nuove tecnologie e linguaggi, rispetto a quelle del Web semantico, ma le regole da seguire
per rendere più facilmente disponibili e raggiungibili i dati sul Web sia da esseri umani sia da applicazioni
software.
Di seguito si spiegheranno brevemente le principali tecnologie Web utilizzate per i Linked Data, per chiarire
come è possibile sfruttare il collegamento semantico tra dataset eterogenei, che aumenti le possibilità di
interrogazione e analisi dei dati da parte sia dei cittadini sia dei decisori, e permetta alle macchine di
dedurre nuova conoscenza.
7
Shadbolt, N., Hall, W. and Berners-Lee, T., "The semantic web revisited." Intelligent Systems, IEEE 21.3 (2006), pp. 96-101.
Berners-Lee, T., "Linked Data", op. cit.
9
Legge 17 dicembre 2012 n.221
8
Agenda Digitale – Linked Open Data
5
2.1.3 Le tecnologie
Come stabilito dalle quattro regole dei LOD il primo passo è identificare univocamente con un indirizzo Web
le risorse pubblicate. Tale indirizzo è un URI (Uniform Resource Identifier), di cui un URL (Uniform Resource
Locator) è una specializzazione, ed è una stringa di testo la cui generica struttura standardizzata è le
seguente:
<scheme name>:<hierarchical part>[ ? <query> ][ # <fragment> ]
ed un esempio di URI è il seguente:
http://it.dbpedia.org/resource/Gromo
Gli URI quindi devono rispettare uno schema condiviso ed essere rintracciabili sul Web attraverso il
protocollo standard HTTP. Le risorse pubblicate (come dati sul Web), devono essere codificate con il
modello RDF (Resource Description Framework), linguaggio standard per il trattamento della semantica nel
Web. Quindi i dataset open devono essere trasformati in dataset di triple RDF, e connessi mediante link
RDF ad altri dati presenti in altri dataset RDF, realizzando quindi una rete di Linked Data.
Il modello RDF descrive le relazioni che intercorrono tra gli oggetti (le risorse) e prende in considerazione
solo relazioni binarie, le più semplici, nelle quali un soggetto e un oggetto sono messi in una certa relazione
tra loro. La relazione è anche detta predicato, poiché da un punto di vista linguistico essa coinvolge un
verbo. La sequenza quindi di soggetto, predicato e oggetto viene denominata tripla. La relazione tra due
oggetti può essere rappresentata in un grafo in cui una linea (il predicato) collega due elementi (soggetto e
oggetto) (vedi figura 1). La tripla è l'elemento base dei grafi RDF.
Figura 1 Esempio di grafo RDF
Tale rappresentazione grafica non è però adatta all'elaborazione automatica, è necessario che sia
formalizzata in modo testuale secondo determinate sintassi o formati. Tale formalizzazione è chiamata
serializzazione RDF, e può essere scritta secondo i formati RDF/XML, N3, Turtle, ecc. In tali serializzazioni
ogni tripla è una "frase", o statement, e più frasi enunciate di seguito rappresentano la serializzazione di un
grafo.
6
Agenda Digitale – Linked Open Data
In RDF un soggetto è identificato da un URI, il predicato è un elemento della classe Property, e l'oggetto
può essere un URI o una stringa di testo. Nel grafo di figura 1 si rappresenta una risorsa, identificata con
l'URI http://dbpedia.org/page/The_Metamorphosis, che è una pagina Web che fornisce informazioni sul
racconto "La Metamorfosi", collegata attraverso tre predicati a tre altre risorse, due oggetti testuali
(l'abstract del racconto e l'etichetta del titolo) e un URI che identifica la pagina con informazioni sull'autore
del racconto, Franz Kafka.
Le triple RDF dell'esempio dicono però soltanto che "La Metamorfosi" ha un abstract, un'etichetta e un
autore che si chiama Franz Kafka, non dicono né che è un racconto, né il significato del concetto racconto o
autore. Per far ciò, per far comprendere ad applicazioni software il significato di tali, e altri, concetti, è
necessario utilizzare linguaggi quali RDF-S (RDF Schema) e OWL (Web Ontology Language) per definire dei
vocabolari (noti come ontologie) comprensibili alle applicazioni, con i quali si esprimono relazioni tra
termini di un dominio e il significato sia delle relazioni sia dei termini.
Con RDF-S è perciò possibile definire una relazione di sotto-classe, quando una classe è figlia di una classe
padre, oppure definire il dominio e il co-dominio di una relazione, cioè su quali classi di concetti opera una
certa relazione. OWL, come il suo successore OWL2, è stato sviluppato dal W3C per fornire ancora più
espressività a RDF e RDF-S, grazie al fatto che sfrutta la potenza espressiva delle logiche descrittive.
Con questi linguaggi, sviluppati dalla comunità del Web semantico, è possibile quindi descrivere le risorse
pubblicate sul Web in termini di concetti e relazioni e far comprendere il loro significato alle macchine,
quindi le risorse diventano sia machine-readable sia machine-processable. In questo modo i dati pubblicati
in formato RDF e descritti da un vocabolario in OWL, l'ontologia del dominio dei dati, raggiungono le 4
stelle della scala Berners-Lee.
Per arrivare a completare la scale delle 5 stelle è necessario che i dati siano accessibili e interrogabili
attraverso un altro linguaggio standard del Web semantico, SPARQL (acronimo di SPARQL Protocol and RDF
Query Language) e che siano linkati ad altri dataset. A questo scopo è necessario creare un endpoint
SPARQL, cioè un servizio Web da cui poter accedere ai dati attraverso delle interrogazioni (query) scritte in
SPARQL, che è un linguaggio e protocollo di interrogazione di dati in RDF. In termini più astratti, si può dire
che SPARQL consente di fare graph pattern matching all'interno di dati RDF.
La sintassi di SPARQL è simile a quella del linguaggio SQL e analogamente è un linguaggio difficile da
utilizzare per utenti non esperti, perché basa la rappresentazione della query sul concetto di tripla RDF, e
per interrogare correttamente un dataset RDF bisogna conoscerne la struttura, le proprietà utilizzate ed i
valori dei concetti. Così come SQL riflette, nella rappresentazione della query, il modello relazionale
sottostante, allo stesso modo SPARQL rappresenta la query sul concetto di tripla e di grafo (modello di
RDF). SPARQL è un linguaggio abbastanza ampio ed articolato, è possibile impostare delle ricerche
utilizzando il pattern a triple: <classe> <relazione> <classe> (dominio, relazione, co-dominio), e la risposta
alla query sono tutte le triple che istanziano il pattern. Ai fini della rappresentazione di una query SPARQL,
un pattern è composto dalla sequenza di tre elementi, ogni elemento può essere un termine RDF o una
variabile. Le variabili sono precedute dal carattere "?" o dal carattere"$" e possono trovarsi in qualunque
posizione all'interno del pattern.
Agenda Digitale – Linked Open Data
7
La struttura di una query in SPARQL è la seguente:
•
SELECT elenco di ciò che si vuole ottenere
•
FROM quale file OWL/RDF si utilizza per la ricerca
•
WHERE condizioni che permettono di rintracciare ciò che si sta cercando.
Un qualsiasi SPARQL client può quindi interrogare un endpoint SPARQL con query riguardanti un grafo RDF.
Le query esprimono le caratteristiche che un sottografo (un insieme di connessioni tra risorse di un certo
tipo e con certe caratteristiche) del dataset RDF deve avere. Le risposte alle query sono tutti quei sottografi
del grafo RDF che soddisfano le caratteristiche volute.
Un secondo punto critico del processo di creazione di LOD è rappresentato dai link RDF che servono a
collegare un dataset ad altri dataset pubblicati da altri soggetti. Per identificare correttamente quali link
utilizzare è necessario un ampio sforzo di analisi dei dati e ricerca sul Web, e soprattutto di supervisione
umana nell'inserimento manuale di tali link. Esistono degli strumenti che supportano l'identificazione di tali
link, ma non consentono ancora l'inserimento automatico e corretto degli stessi. Per far fronte a ciò la
comunità dei LOD ha individuato alcune proprietà (predicati di triple) che possono essere utilizzate come
link per collegare diversi dataset. Il loro utilizzo condiviso e la loro generalità ne hanno fatto uno standard
de facto, alcune di esse sono: owl:sameAs che stabilisce che due individui (URI) si riferiscono allo stesso
concetto; rdfs:seeAlso, foaf:knows, foaf:based_near, foaf:topic_interest ecc. Nel seguito del documento si
spiegherà meglio questo punto critico.
Per riassumere, per creare LOD a 5 stelle devono essere seguite queste linee guida:
• Non semplici dati ma concetti;
• I concetti sono rappresentati in triple RDF e definiti da ontologie;
• I dati strutturati sono memorizzati in appositi triplestore RDF interrogabili via SPARQL endpoint;
• I diversi dataset devono essere collegati con link RDF;
• Riusare il più possibile termini di vocabolari noti;
• Creare nuovi termini solo se strettamente necessario.
2.1.4 LOD cloud
La creazione e la pubblicazione di dataset in formato LOD sul Web ha generato una grande mole di dati e
sempre più enti, pubblici e privati, continuano a pubblicarne secondo le direttive del W3C. Nell’ottobre
2007, i dataset sul Web consistevano di oltre due miliardi di triple RDF, unite da oltre due milioni di
collegamenti RDF. Nel settembre 2010, questi dati erano cresciuti a 25 miliardi di triple RDF, linkate da circa
395 milioni di link RDF. Nel settembre 2011 sono arrivati a più di 31 miliardi di triple RDF e più di 500 milioni
di link RDF 10. I collegamenti tra diversi dataset vengono graficamente rappresentati da una grande ‘nuvola’
chiamata “LOD cloud diagram”, in cui vi è la visualizzazione interattiva dei gruppi di dataset interoperabili
(figura 2).
10
8
http://lod-cloud.net/state/
Agenda Digitale – Linked Open Data
Figura 2 LOD cloud diagram
Il diagramma LOD cloud mostra le categorie di dataset, che convergono nello CKAN11, un catalogo di
dataset Open Data e Linked Open Data gestito dalla Open Knowledge Foundation. L’immagine della LOD
cloud è solo uno dei possibili scenari in cui i LOD possono favorire l’interoperabilità tra dataset. Le
possibilità sono infinite, se si pensa alla immensa quantità di LOD già presenti nel Web come, ad esempio,
DBpedia.org, Wikipedia, Geonames 12, MusicBrainz 13, WordNet 14, la bibliografia DBLP 15 ecc.
11
http://ckan.net
http://www.geonames.org/
13
http://musicbrainz.org/
14
http://wordnet.princeton.edu/
15
http://dblp.uni-trier.de/db/
12
Agenda Digitale – Linked Open Data
9
Da un punto di vista dei domini coperti dalle triple presenti nella LOD cloud, si può notare dal grafico di
figura 3 che la maggior parte delle triple sono relative a dati di pubbliche amministrazioni (Government),
seguite da quelli geografici e cross-domain.
Figura 3 Distribuzione di triple per dominio
La LOD cloud ha come suo centro il progetto DBpedia, nato nel 2007 presso l'Università di Berlino, con
l'obiettivo di estrarre dati strutturati da Wikipedia e pubblicarli sul Web in formato LOD. A questo progetto
si sono collegati tutti gli altri progetti che hanno l'obiettivo di pubblicare LOD o di sfruttare i LOD per la
creazione di applicazioni e servizi. Esiste dal 2010 anche la versione italiana di DBpedia 16, che prende i dati
dalla versione italiana di Wikipedia, ed ha lo stesso obiettivo della versione ufficiale, di essere il fulcro e il
cuore del Web of data dei LOD italiani. Alcuni degli enti che pubblicano LOD rendono disponibili anche le
ontologie che descrivono la loro semantica, tra questi DBpedia, Geonames, UMBEL 17 e YAGO 18, che
possono essere riutilizzate per altri dataset (come si spiegherà più avanti). Da alcune osservazioni empiriche
e da molti articoli presenti in letteratura 19 si evince che la maggior parte dei dati presenti in LOD cloud fa
riferimento a poche ontologie, o parti di ontologie, e quindi sono pochi gli enti che oltre a pubblicare dati
sviluppa anche ontologie contestuali. Questo è uno dei temi aperti della ricerca sui LOD e sulle ontologie, in
particolare sul problema dell'integrazione a livello di schema ontologico e del loro riutilizzo nei LOD 20.
2.1.5 LOD in Italia
Dall'analisi dello stato dell'arte dei dataset in formato open, prodotti e pubblicati dagli enti locali italiani, si
rileva che attualmente sono stati pubblicati più di 10.500 dataset 21. Regione Lombardia pubblica più di 720
dataset. Dal punto di vista della qualità secondo lo schema di Berners-Lee, la maggior parte dei dataset
pubblicati in Italia (7286 pari a quasi 70%) raggiunge le 3 stelle (figura 4), e molti sono pubblicati con licenza
libera (come per esempio la CC0, CC-BY, IODL 2.0), quindi possiedono già un alto livello di riusabilità. A
livello nazionale però soltanto il 5% dei dataset raggiunge attualmente le 5 stelle.
16
http://it.dbpedia.org/
http://umbel.org/
18
http://www.mpi-inf.mpg.de/yago-naga/yago/
19
cfr.: Jain, P., Hitzler, P., Yeh, P. Z., Verma, K., & Sheth, A. P. (2010) Linked Data Is Merely More Data. In AAAI
Symposium: linked data meets artificial intelligence.
20
cfr.: Jain, P., Hitzler, P., Sheth, A. P., Verma, K., & Yeh, P. Z. (2010) Ontology alignment for linked open data.
Semantic Web–ISWC 2010 (pp. 402-417). Springer Berlin Heidelberg.
21
Dati aggiornati aprile 2014, cfr. http://www.dati.gov.it/content/infografica
17
10
Spring
In The
Agenda Digitale – Linked Open Data
Figura 4 Livello di qualità Open Data in Italia
Gli enti che pubblicano LOD a 5 stelle in Italia sono principalmente enti Statali: CNR, Camera, Senato,
Archivio generale dello Stato, qualche Comune e tra le università la sola è l'Università di Messina. Quindi
attualmente nessuna regione italiana pubblica LOD (figura 5).
Figura 5 Enti che pubblicano LOD in Italia
L'aumento della quantità e della qualità dei dataset in LOD porterebbe un valore aggiunto a tutto lo stato
degli open data italiani. Inoltre il raggiungimento di tale obiettivo porterebbe le Pubbliche amministrazioni
italiane ad allinearsi al modello europeo di interoperabilità semantica dei servizi erogati (EIF), secondo le
direttive dell'Agenda Digitale Europea 22.
22
Agenda Digitale Europea, http://ec.europa.eu/information_society/digital-agenda/index_en.htm, 2012
Agenda Digitale – Linked Open Data
11
2.1.6 LOD casi di successo
Come detto sopra la LOD cloud rappresenta uno scenario di dati disponibili e linkati, riutilizzabili per la
creazione di nuove applicazioni, servizi, siti. Tra le iniziative create con l'utilizzo dei LOD una delle migliori e
più citate è il sito BBC Music 23 che sfrutta i dati musicali della radio inglese BBC linkati ad altre risorse
disponibili nella LOD cloud, quali per esempio DBpedia, Musicbrainz, DiscoGS (figura 6). Facendo una
ricerca nel motore del sito, per esempio scrivendo il nome di un artista, si ottengono informazioni derivanti
da quelle fonti, il tutto sfruttando l'HTML e un'interfaccia semplice ed intuitiva (figura 7).
Figura 6 Dataset LOD collegati a BBC Music
Figura 7 Screenshot da BBC Music
23
http://www.bbc.co.uk/music
12
Agenda Digitale – Linked Open Data
Un'iniziativa italiana da citare è il Portale storico della Camera dei Deputati 24 (figura 8), che sfrutta i dati
LOD del sito dati.camera.it e fornisce un agile e utile strumento di navigazione della storia del Parlamento
italiano attraverso i nomi dei deputati, le legislature, gli atti e i documenti prodotti. Esso offre quindi
molteplici chiavi di lettura dei dataset, che possono essere selezionati e consultati attraverso un'intuitiva
navigazione basata su filtri a "faccette".
Figura 8 Screenshot dal Portale Storico Camera dei Deputati
Entrambi questi esempi sono siti che gestiscono e visualizzano informazioni derivanti da risorse Web in
formato LOD senza costringere l'utente a scrivere query in SPARQL, che restano nascoste all'utente, e che
vengono eseguite sulla base dei filtri e dei menu scelti dall'utente.
24
http://storia.camera.it/
Agenda Digitale – Linked Open Data
13
2.2 Strumenti adottati
2.2.1 Introduzione
In questa sezione si elencano gli strumenti software utilizzati durante il progetto ITLab per la parte Linked
Open Data. Si tratta di software open source sviluppati e manutenuti da comunità attive e collaborative sul
Web. Alcuni di questi sono diventati col tempo quasi strumenti di riferimento per la comunità, si pensi
all'enorme utilizzo di Protégé come ontology editor o Open Link Virtuoso come server di endpoint SPARQL.
Si fornirà di ciascun strumento le indicazioni della versione utilizzata nel progetto e i benefici e i punti critici
incontrati.
2.2.2 Protégé
Protégé 25 è una soluzione open source scritta in Java sviluppata dall’Università di Stanford (e in seguito con
l'aiuto dell'Università di Manchester) per la definizione e manutenzione di ontologie (schemi, vocabolari) in
RDF/OWL e OWL2. È un editor di ontologie la cui architettura è basata su plug-in estendibili. Esso ha
un'interfaccia grafica intuitiva ed è supportato da una nutrita comunità. L’attenzione è posta su OWL,
quindi i Linked Data in RDF puro hanno spesso qualche problema a essere gestiti in maniera adeguata. Il
limite principale di Protégé è la mancanza di un plug-in per utilizzare SPARQL, dovuta appunto all'approccio
“OWLcentric”. Protégé implementa un buon debugger logico per le ontologie e un motore di reasoning per
eseguire inferenze. Inoltre permette di importare ontologie esterne per la creazione di nuove ontologie.
La versione adottata nel progetto ITLab è la 4.3. Per la spiegazione dell'utilizzo di Protégé si rimanda alla
sezione dedicata alla costruzione dell'ontologia.
2.2.3 LOD Refine
OpenRefine 26 è un potente strumento software open source nato con lo scopo di facilitare le procedure di
pulizia dei dati. In precedenza il progetto che ha portato allo sviluppo di questa applicazione era
denominato Google Refine. OpenRefine mette a disposizione dell’utente un insieme molto vasto di
funzionalità che consentono il caricamento dei dati (da csv, xml, ecc.), la manipolazione della tabella
generata dopo l’import (aggiunta/rimozione di colonne/righe, manipolazione dei nomi di righe e colonne,
modifica dei valori dei campi, ecc.), l’analisi dei dati componenti il dataset importato (profiling, clustering).
Caratteristica fondamentale di OpenRefine è che, grazie alla natura open source del progetto (che ne
consente il riuso del codice in altri contesti) e grazie alla sua estendibilità a nuove funzionalità (attraverso lo
sviluppo di “Extensions”) lo strumento diviene, oltre che agile e immediato da utilizzare, anche versatile e
adattabile.
Nelle attività del laboratorio è stato utilizzato LODRefine 27, una distribuzione di OpenRefine che include già
installate una lunga serie di Extensions. Nel nostro caso specifico, le estensioni di interesse sono quelle
relative alla DERI RDF Extension 28. Questa estensione consente di effettuare due operazioni fondamentali
per la manipolazione dei dataset e la loro trasformazione in LOD: la costruzione di RDF Schema partendo
25
http://protege.stanford.edu/
http://openrefine.org/
27
http://code.zemanta.com/sparkica/
28
http://refine.deri.ie/
26
14
Agenda Digitale – Linked Open Data
dalla struttura della tabella e il Reconciliation semiautomatico dei valori. Se da un lato la prima funzionalità
è completamente manuale (l’utente deve costruire lo schema RDF che fornisce le informazioni su come le
colonne della tabella devono essere “interpretate” e come esse siano in relazione tra loro, e con ontologie
esterne o concetti definiti nello schema RDF stesso), la procedura di Reconciliation è semiautomatica.
Questa procedura consente di collegare una risorse descritta all’interno del dataset considerato con una
risorsa esterna (definita in un altro dataset o ontologia) attraverso l’uso dell’URI.
Funzionalità non banale presente in LODRefine è la possibilità di esportare lo schema creato manualmente
dall’utente e i dati presenti nel dataset in un unico file (RDF o Turtle) per poter essere poi utilizzato in altri
strumenti (Protégé, Open Link Virtuoso, ecc.).
2.2.4 Openlink Virtuoso Universal Server
La pubblicazione dei dataset LOD richiede l’utilizzo di un server in cui memorizzare e gestire i dataset e che,
al contempo sia anche un endpoint SPARQL. Virtuoso 29, nella sua versione enterprise, fornisce le seguenti
funzionalità di gestione e pubblicazione dei dati:
• Relational Data Management
• RDF Data Management
• XML Data Management
• Free Text Content Management & Full Text Indexing
• Document Web Server
• Linked Data Server
• Web Application Server
• Web Services Deployment (SOAP or REST)
All’interno del laboratorio ITLab è stata utilizzata la versione Open Source 30.
29
30
http://virtuoso.openlinksw.com/
http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/
Agenda Digitale – Linked Open Data
15
2.3 Il progetto ITLab e la costruzione dei LOD sui servizi in Regione Lombardia
2.3.1 Introduzione
L'obiettivo del progetto ITLab si è concentrato sulla creazione di una metodologia, supportata da strumenti
software open source, per la creazione, la pubblicazione sul Web e l’interrogazione di dataset LOD. Scopo di
tale metodologia è di permettere alle PA di arrivare ad avere i propri dataset in open data (attualmente al
più a 3 stelle) al livello LOD (in 5 stelle nella scala Barners-Lee) così da porre le basi fondamentali per la
creazione di applicazioni e servizi basati sull'inferenza di nuova conoscenza, generata dai collegamenti tra i
diversi dataset.
Sin dall'inizio del progetto si è scelto di trattare il dominio dei servizi di pubblica utilità della Regione
Lombardia, e tale scelta ha guidato la selezione dei dataset, estratti dal portale degli open data della
Regione Lombardia (www.dati.lombardia.it) , da utilizzare nella sperimentazione. La sperimentazione è
partita con un solo dataset (Anagrafe delle suole lombarde), poi si è passati ad utilizzare cinque dataset. I
dataset considerati sono stati: Anagrafe delle scuole, Comunità minori, RSA, Albo cooperative sociali e
Strutture di ricovero e cura.
Nel seguito si forniscono gli attributi dei dataset utilizzati:
• Scuole = {Provincia, Codice, Tipologia, Denominazione, Indirizzo, Localita, Cod. comune, Comune, CAP,
Distr., Telefono, Caratteristica scuola, Sede direttivo, Codice sede riferimento, Codice sede di direttivo,
Denominazione sede direttivo, Indirizzo sede di direttivo, Cod. comune sede dir., Comune sede di
direttivo, CAP sede dir., Distr. sede dir.}
• Comunita minori = {denominazione, struttura, indirizzo, nr, comune2, prov2, tipologia, telefono, eta,
capienza, fax, cap, asl}
• RSA = {asl, denominazione_struttura, comune, indirizzo, cap, tel, fax, e-­‐mail,
posti_letto_totali_accreditati, posti_letto_alzheimer_accreditati}
• Albo cooperative sociali = {denominazione, comune, provincia, telefono, email, area, servizi,attivita,
tipologie persone svantaggiate}
• Strutture di ricovero e cura = {asl, cod_ente, denom_ente,cod_struttura, cod_sub,denom_struttura,
cod_tipo_str,descr_tipo_str, data_apertura, data_chiusura,indirizzo, cap, localita, telefono, fax,
sito_web, liv_emerg, ps_pediatrico}
Per descrivere il dominio e fornire la semantica ai dataset si è quindi avviata la creazione di un'ontologia dei
servizi parallelamente allo sviluppo della metodologia. Gli obiettivi primari del progetto sui LOD sono
quindi: 1) rendere la metodologia il più possibile automatizzabile, replicabile, e utilizzabile anche da utenti
non esperti; 2) creare un'ontologia che sia un modello asciutto del dominio, sufficientemente astratto per
essere riutilizzato come riferimento, ma abbastanza specifico per collegare i diversi dataset relativi ai servizi
erogati in Lombardia. Il fine della creazione dell'ontologia è soprattutto quello di essere uno strumento
efficiente ed agile da utilizzare per la descrizione semantica e la pubblicazione di dataset lombardi in
16
Agenda Digitale – Linked Open Data
formato LOD, e non quello di proporsi come ennesimo nuovo sistema di classificazione e descrizione dei
servizi (scopo al di fuori del progetto).
2.3.2 Costruzione ontologia dei servizi
Al fine di rendere interoperabili i dati pubblicati sul Web è necessario fare riferimento a dei vocabolari
condivisi la cui semantica sia ben specificata. Questi vocabolari sono anche chiamati ontologie,
rappresentazioni formali e condivise di una concettualizzazione di un dominio di interesse 31. Un'ontologia
ricopre un ruolo fondamentale nel Web semantico per agevolare la fruizione e la comprensione del
significato dei dati da parte di agenti software, e ciò vale anche all'interno dei LOD. Come accennato
nell'introduzione ai LOD è quindi opportuno creare (se non esiste) o usare un'ontologia disponibile per
fornire un riferimento semantico esplicito per i dati LOD. Esistono ontologie standard che fanno riferimento
a diversi domini di conoscenza. Tra questi le più utilizzate e diffuse sono: Dublic Core, standard per la
descrizione di metadati bibliografici; Friend-of-a-friend (FOAF) per descrivere concetti relativi a persone e
alle relazioni tra di esse; Geonames per descrivere entità geografiche. Poi con lo sviluppo dei Linked Data
altre ontologie sono diventate un riferimento per la comunità, tra queste ha un ruolo fondamentale
l'ontologia sviluppata all'interno del progetto Dbpedia, utile per descrivere la conoscenza presente nelle
pagine di Wikipedia, i cui concetti e relazioni sono usati come veri e propri standard da molti dataset,
strumenti e applicazioni che condividono LOD 32.
La maggior parte delle ontologie riutilizzabili sono scritte nei linguaggi del Web semantico, RDF e OWL, e
possono essere importate facilmente al momento di crearne una nuova, così come è stato fatto anche in
questo progetto ed è descritto di seguito.
31
Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge acquisition, 5(2), pp. 199-220.
Lehmann, J., Isele, R., Jakob, M., Jentzsch, A., Kontokostas, D., Mendes, P. N., ... & Bizer, C. (2013). Dbpedia-a large-scale,
multilingual knowledge base extracted from wikipedia. Semantic Web Journal.
32
Agenda Digitale – Linked Open Data
17
2.3.2.1 Prima versione dell’ontologia
L'ontologia dei servizi è stata creata utilizzando lo strumento Protégé ed il linguaggio OWL. Sono stati presi
come riferimento del dominio alcuni vocabolari e modelli concettuali utili a descrivere il servizio pubblico
attraverso uno schema di concetti e relazioni.
Il primo modello studiato è stato il Core Public Service Vocabulary 33 (CPSV), un vocabolario riconosciuto a
livello europeo. Questo vocabolario è nato all'interno delle attività della piattaforma Joinup, creata
dall'Unione Europea nell'ambito del programma ISA (Interability Solutions for european public
Administrations) 34, che ha l'obiettivo di migliorare e rendere più affidabili, all'interno dell'Unione Europea,
gli scambi di informazioni, l'interazione e l'interoperabilità tra i sistemi. La piattaforma Joinup 35 ha lo scopo
di creare linee guida verso la standardizzazione, condivisione e riutilizzo del patrimonio informativo open
source. I temi di ricerca della piattaforma spaziano dall'incrocio tra diversi settori o stati, alla diffusione
della legislazione che regolamenta l'ambiente Open Data, alla diffusione di semantica, ontologie e
metodologie e pratiche per l'apertura e il collegamento tra loro dei vari dati, anche in formato LOD.
All'interno di Joinup la comunità SEMIC (SEMantic Interoperability Community) svolge un importante ruolo
di sviluppo di modelli semantici, che hanno come idea di base il "Core Concept": è un semplice modello di
dati che cattura le caratteristiche e gli attributi più semplici e generali di un'entità posta in un dominio
generico e neutrale. Esso ha due vantaggi sostanziali:
1) E' riutilizzabile, poichè cattura gli elementi generali, basilari ed indipendenti dal contesto in cui
l'entità è utilizzata, per cui è possibile riutilizzarla in modi diversi.
2) E' estendibile, poiché a questi attributi basilari è possibile in ogni utilizzo aggiungerne altri, più o
meno specifici, che ne danno una maggiore caratterizzazione.
Si tratta di modelli concettuali tecnologicamente indipendenti e successivamente codificati in diversi
formati tra cui XML o RDF. SEMIC ha già sviluppato alcuni di questi modelli, arrivando a definire dei
Concepts che costituiscono il modello formale per lo sviluppo di Core Vocabularies più tecnici e relativi a
diversi ambiti. Tra questi ambiti è stato definito il Core Public Service Vocabulary (CPSV) che definisce un
metodo univoco per descrivere un servizio pubblico, con lo scopo di pubblicarlo su portali governativi,
basandosi su un diagramma UML come modello base (figura 9) adattabile a diversi servizi; esso non
pretende di essere esaustivo ed adattabile ad ogni servizio in ogni contesto, ma vuole essere una base
generale e il più flessibile possibile che permetta di avere una struttura comune per l'interoperabilità.
Per la sua struttura, importanza e semplicità è stato utilizzato in questo progetto come primo passo per la
creazione dell'ontologia dei servizi.
33
https://joinup.ec.europa.eu/asset/core_public_service/asset_release/core-public-service-vocabulary-0
http://ec.europa.eu/isa/
35
https://joinup.ec.europa.eu/
34
18
Agenda Digitale – Linked Open Data
Figura 9 Modello UML del CPSV
Al centro del modello c'è il servizio pubblico, con i suoi attributi principali: il titolo o nome del servizio
(dcterms:title), la descrizione del servizio in formato testuale (dcterms:description), il linguaggio
(dcterms:language) e la tipologia di servizi, tratta da alcune liste standard esistenti appositamente
(dcterm:type). Legato (con la relazione hashchannel) troviamo i canali del servizio, per esempio la
homepage o la sede fisica dove è possibile ottenerlo. Leggendo il modello in senso orario: ogni servizio
produce un output, ovvero un documento che attesta l'erogazione del servizio e il riconoscimento
all'utente di diritti e doveri (Output); anch'esso è descritto con un titolo, una descrizione e una tipologia (se
è un documento cartaceo, una registrazione elettronica, una tessera ecc.).
Seguono due elementi che forniscono indicazioni di tipo spaziale (dcterms:spatial, indica il luogo) e
temporale (dcterms:temporal, indica il periodo temporale) relativamente al servizio. Così come forniscono
un output, alcuni servizi richiedono anche un input (relazione hasInput), ovvero i documenti o tutto ciò che
è necessario avere per poter accedere al servizio, dai moduli da compilare ai documenti che attestano le
caratteristiche socio-demografiche dell'utente che ne fa richiesta, alla richiesta stessa e così via. Restano tre
entità: ogni servizio segue delle regole, delle norme o una legislatura interna al servizio (relazione follows e
concetto Rules), o emessa dall'esterno (con la relazione implements che collega il concetto
FormalFramework) che può essere definita in modo più o meno specifico e formale, o derivare da altre
leggi ancora più generali. Vi sono infine diversi agenti che operano nel servizio (dcterms:agent): quale
pubblica amministrazione eroga il servizio, chi ha definito le regole, chi consegna il servizio, chi ha fatto le
leggi, ma anche chi alla fine utilizza il servizio. Vi sono inoltre due legami dei servizi con se stessi: è possibile
indicare se un servizio necessita di un altro servizio creato precedentemente (dcterms:required), o se è
legato non temporalmente a un altro servizio (dcterms:related).
Agenda Digitale – Linked Open Data
19
Tuttavia in letteratura esistono altri modelli di concettualizzazione del servizio, studiati durante la prima
edizione del progetto ITLab 2.0 per il quale si era già creato un modello di servizio, integrato nell'ontologia
del wiki semantico WiWork. Quel modello si basava su alcune regole:
• Gli attori di un servizio hanno un obiettivo
• Il servizio è composto da una serie di operazioni
• Le operazioni per essere attivate necessitano di input/output
• Le informazioni sono input/output delle operazioni
• Gli attori forniscono/richiedono diversi tipi di informazioni, quindi hanno diversi ruoli
• Il servizio per essere erogato può richiedere alcuni strumenti
Figura 10 Modello di servizio ITLab 2.0
Da questo elenco di regole si è definito uno schema gerarchico degli elementi principali con alcuni sottoelementi (figura 10):
• Obiettivo
• Ambiente
• Operazioni
o Avvio
o Gestione processo
o Gestione problemi
o Tracciabilità
• Attori
o Decisori
o Utenti
• Ruoli
o Produttore informazioni
o Consumatore informazioni
• Informazioni
o Tipo di informazioni
 Specifiche per i decisori
 Parte integrante del prodotto/processo
• Strumenti
20
Agenda Digitale – Linked Open Data
Confrontando questo schema con quello del CPSV si notano alcune differenze e alcune parti comuni. Nel
CPSV i concetti di input e output sono generici e ben differenziati, mentre nel secondo modello l'input è
un'operazione, mentre l'output non è esplicitato. La Location del CPSV è equivalente alla classe Ambiente
del secondo modello. Un'altra equivalenza, anche se non terminologica, esiste tra i Channel del CPSV e gli
Strumenti del secondo modello. Nel CPSV sono ben definiti il periodo temporale di durata del servizio e le
regole a differenza dell'altro modello. In questo però sono stati definiti le operazioni e l'obiettivo. Un
discorso a parte richiede il concetto di Attore o Agente. In entrambi i modelli si è definita una classe per
l'entità che è attiva nel servizio, però nel secondo modello attori e ruoli sono ben differenziati, mentre in
CPSV non si fa riferimento al ruolo se non come azione (relazione semantica) della classe Agente.
Un terzo modello di servizio esistente è stato studiato per arricchire e completare quello in costruzione nel
progetto. Si tratta del modello alla base della piattaforma online inglese "Effective Service Delivery Toolkit"
(ESD-Toolkit), che fornisce strumenti e modelli utili alla classificazione dei servizi pubblici locali sul territorio
inglese. Il modello si chiama Local Government Business Model 36, rappresentato nel diagramma di figura
11.
Figura 11 Diagramma del LGBM
36
http://standards.esd.org.uk/LGBMDiagram.aspx
Agenda Digitale – Linked Open Data
21
Il modello è diviso in tre parti: People and Places, Organisation scope e Organisation. Il concetto centrale
Service è al centro delle tre parti ed è collegato a diversi altri concetti. Un collegamento da sottolineare è
quello che definisce il servizio come parte di una Function. Questo è un concetto che raggruppa servizi o
attività che un'organizzazione (pubblica o privata) eroga o esegue per raggiungere un certo obiettivo.
Nell'ambito degli standard ESD le diverse funzioni possono essere equiparate alle categorie con le quali
classificare le aree tematiche, o domini, dei servizi pubblici.
Inoltre il modello introduce il concetto di Legislation che conferisce ad un'organizzazione il compito di
eseguire una Function. Tornando al concetto di Service si notano alcuni collegamenti interessanti: esso è
erogato attraverso un Process che è modellato come equivalente ad un tipo di Interazione condotta
attraverso un Canale come nel modello CPSV. Inoltre nel modello ESD il servizio è definito e memorizzato
da documenti, permessi dalla legislazione.
Si è descritto soltanto queste parti del modello ESD perchè sono quelle che maggiormente interessano nella
definizione dell'ontologia dei servizi. Infatti si è deciso di inserire alcuni di questi concetti per completare il
modello di servizio definito nel precedente progetto ITLab 2.0.
Prima di tutto il concetto Function appare molto simile al concetto Obiettivo di ITLab 2.0 e può essere
utilizzato anche per definire le categorie dei servizi. L'attore che esegue la Function può essere
genericamente modellato con la classe Agent (CPSV) o Attore (ITlab 2.0). Il concetto Legislation condensa i
concetti di FormalFramework e Rule di CPSV, anch'essi collegati all'Agent. Tale concetto invece non era
presente in ITLab 2.0. Il concetto Process equivale alla classe Operazioni di ITLab 2.0, mentre Channel
corrisponde al Channel di CPSV e agli Strumenti di ITLab 2.0. Il concetto Document era presente anche in
CPSV, mentre in ITLab 2.0 era definito come Informazioni. Invece si inserisce il nuovo collegamento tra il
documento e la legislazione.
Integrando e modificando alcune classi si è definito quindi il modello di servizio alla base della prima
versione dell'ontologia, rappresentato in figura 12.
22
Agenda Digitale – Linked Open Data
Figura 12 Grafo della prima versione dell'ontologia dei servizi
Nel primo schema sviluppato i concetti di Attore e Luogo sono subito stati considerati come fondamentali
per descrivere il Servizio, e per la loro definizione si è pensato di importare Geonames e FOAF. Inizialmente
quindi si pensava di usare Geonames per sfruttare la definizione delle entità geografiche presenti in essa, e
FOAF per quella delle persone. Si vedrà poi come Geonames è stata sostituita da alcune componenti
dell'ontologia di DBpedia, e gli elementi presi da FOAF siano stati modificati nello schema finale
dell'ontologia.
2.3.2.2 Creazione dell'ontologia dei servizi pubblici con Protégé
Il primo passaggio nella creazione di un'ontologia in Protégé è la definizione del suo indirizzo IRI (figura 13),
che rappresenta il suo namespace che verrà utilizzato all'interno dell'ontologia, ma non necessariamente
rappresenta la sua locazione fisica.
Figura 13 Screenshot da Protege con l'IRI dell'ontologia
Successivamente si deve specificare in quale formato si intende rappresentare l'informazione da modellare,
e si è scelto OWL/XML che permette una maggiore espressività nella modellazione. La prima schermata che
viene presentata all'utente (figura 14) fornisce la barra di navigazione (in alto) e i diversi tab che
Agenda Digitale – Linked Open Data
23
permettono di accedere e lavorare su diversi aspetti dell'ontologia. Oltre ai tab di default sono anche
presenti i tab dei plug-in installati nella versione corrente, che estendono alcune funzionalità.
Figura 14 Screenshot da Protégé con schermata principale
Il primo tab aperto è quello relativo alla Active Ontology, esso presenta le meta-informazioni associate
all'ontologia (come le Annotations), l'importazione (Ontology import) di file .owl esterni, e i prefissi
(Ontology prefixes) associati al file su cui si sta lavorando. Gli altri tab sono quelli fondamentali per la
creazione dell'ontologia: Classes, Object Properties, Data Properties e Individuals.
Per importare un'ontologia esterna si clicca sul pulsante + nella sezione Imported ontologies, si apre un
wizard che aiuta l'utente nell'identificazione dell'ontologia che si vuole importare, si può scegliere se
importare un file .owl locale o uno esterno tramite il suo URL, alla fine di questo processo appare il nome
dell'ontologia importata (figura 15).
Figura 15 Screenshot da Protege con ontologia importata
Nella prima versione dell'ontologia dei servizi sono state importate alcune parti di ontologie disponibili:
• da CPSV le classi: PublicService, Channel, Agent;
• da FOAF la classe Person e la proprietà based_near;
• da Vcard 37 la classe Address;
• da Dbpedia la classe Location;
• da ESD-toolkit la classe Function.
37
http://www.w3.org/TR/vcard-rdf/
24
Agenda Digitale – Linked Open Data
Altre classi sono state create direttamente in Protégé lavorando nel tab Classes. Il tab Classes è diviso in
due sezioni principali (figura 16), quella di sinistra serve a modellare la gerarchia delle classi (tassonomia)
mentre quella di destra è usata per specializzare e dettagliare la descrizione delle classi presenti
nell'ontologia.
Figura 16 Tab Classes
All'inizio di ogni nuova creazione nella sezione di sinistra, Class Hierarchy, l'unica classe che compare è la
Thing che rappresenta la root dell'ontologia. Con l'importazione di un'ontologia esterna invece
compariranno anche le classi di quest'ultima, nel presente caso le classi delle ontologie importate sopra
elencate. Per creare una gerarchia di classi è possibile usare i pulsanti messi a disposizione da Protégé in
alto a sinistra della Class Hierarchy. Il primo a sinistra permette di creare una classe di livello
gerarchicamente inferiore rispetto a quella selezionata (il primo passo è quindi selezionare Thing per creare
una sua sotto-classe). Con il secondo pulsante invece si crea una classe gerarchicamente allo stesso livello
di quella selezionata (non è possibile però creare classi allo stesso livello di Thing). Il terzo pulsante serve
per cancellare una o più classi selezionate (non è possibile cancellare la Thing).
La sezione di destra del tab Classes è divisa in due sezioni orizzontali, in quella superiore è possibile
aggiungere delle informazioni "non ontologiche" come ad esempio rdfs:label o rdfs:comment con il tab
Annotations, e si può visualizzare come la classe viene utilizzata all'interno del documento OWL che si sta
redigendo con il tab Usage. In figura 17 si può vedere come sia stato aggiunto un commento per la classe
PublicService.
Agenda Digitale – Linked Open Data
25
Figura 17 Annotation della classe PublicService
Tramite la parte inferiore si può aggiungere e modificare informazioni ontologiche associate alla classe
selezionata. In figura 18 un esempio di alcune informazioni associate alla classe PublicService.
Figura 18 Informazioni ontologiche della classe PublicService
Nell'esempio di figura 18 sono visualizzate alcune asserzioni logiche che definiscono le caratteristiche della
classe selezionata, esse utilizzano le proprietà e le classi cui la classe selezionata è collegata. Le proprietà
vengono create e definite nei tab Object Properties e Data Properties. Questi due tab sono analoghi a
quello delle classi (figura 19).
26
Agenda Digitale – Linked Open Data
Figura 19 Tab Object Properties
In questo tab è possibile creare le proprietà nella parte sinistra (utilizzando i tre pulsanti in alto che hanno
le stesse funzionalità descritte per quelli delle classi), e nella parte destra definire le caratteristiche
associate ad ogni proprietà. Tra queste caratteristiche è possibile definire il dominio (Domain) e il codominio (Range) di una proprietà selezionata, nell'esempio di figura 19 la proprietà hasUser ha come
dominio la classe PublicService e co-dominio la classe User. Il tab relativo alle Datatype Properties permette
una gestione delle proprietà del tutto analoga a quelle Object.
Il tab Individuals infine permette di creare nuovi individui (istanze) e modellare in maniera molto semplice
tutte le informazioni ad essi relative (figura 20).
Figura 20 Tab Individuals
Agenda Digitale – Linked Open Data
27
Il tab è diviso in tre parti: quella di sinistra visualizza la tassonomia, la parte centrale permette la creazione
delle istanze con due pulsanti (Add e Delete), la parte destra fornisce tutte le informazioni, in alto le
Annotations, in basso le informazioni ontologiche. Nell'esempio di figura 20 è possibile vedere come sono
state create le istanze della classe RSA, le istanze hanno un nome (in questo caso un codice numerico) e
nella parte di destra sono visualizzate le istanze delle classi cui è collegata tramite le sue proprietà.
È necessario spiegare come è avvenuto il caricamento delle istanze nell'ontologia. L'ontologia dei servizi,
come detto, è stata creata per descrivere il dominio di riferimento dei servizi lombardi, di cui i cinque
dataset sono delle istanze reali. Ciascun dataset contiene dati relativi a enti che erogano dei servizi nella
Regione Lombardia, per esempio le scuole o le strutture di ricovero e cura, che sono definite come sottoclassi della classe PublicServiceProvider. Ciascuna tupla del dataset Anagrafe scuole ha una serie di attributi,
il nome, l'indirizzo, il codice identificativo ecc. e viene definita come singola istanza della classe Scuola,
sottoclasse di PublicServiceProvider.
Tutte le istanze delle scuole sono state trattate e convertite in RDF con lo strumento LOD Refine (cfr. più
avanti) e il file RDF prodotto da questo strumento è stato importato in Protégé insieme all'ontologia dei
servizi. Questa importazione ha permesso quindi di classificare le istanze dei diversi servizi secondo lo
schema delle classi definito nell'ontologia. La fase di conversione dei dataset da tabelle relazionali in RDF ha
messo in evidenza alcune criticità della prima versione dell'ontologia, ciò ha costretto ad una sua radicale
revisione e raffinamento fino alla versione implementata nell'endpoint SPARQL. Una delle criticità
incontrate in questa fase è dovuta al fatto che non tutte le classi definite nell'ontologia dei servizi
sarebbero poi state utilizzate e collegate ad istanze dei dataset, tra queste Function, Legislation, Channel. Si
è quindi preferito, anche per motivi di performance dell'ontologia, ridurla alle sole classi utilizzate dai
dataset.
2.3.2.3 Versione implementata
Si è giunti per raffinamenti successivi, partendo dagli attributi dei dataset, ad una versione “asciutta”
dell'ontologia, con le sole classi necessarie per classificare i dataset scelti. Delle parti importate da
ontologie esterne si è mantenuto le classi PublicService e Agent da CPSV; Address, Telephone da Vcard,
Location da Dbpedia. Si è mantenuto il dettaglio delle sotto-classi di Agent: PublicServiceProvider,
Stakeholder e User, che a loro volta sono dettagliati in Group, Person e Organization.
Esiste poi una relazione di equivalenza tra le classi Location e Place, e tra le loro sotto-classi Comune e
Settlement. In figura 21 il grafo dell'ontologia dei servizi implementata, dove sono evidenziate alcune delle
relazioni più significative: per esempio il PublicServiceProvider fornisce un PublicService, è localizzato in un
luogo e ha degli utenti.
28
Agenda Digitale – Linked Open Data
Figura 21 Grafo della versione implementata dell'ontologia dei servizi
Prima di concludere questa parte sulla costruzione dell'ontologia dei servizi è necessario spiegare a cosa
serve il motore inferenziale presente in Protégé, detto anche reasoner (ragionatore). Il reasoner è uno
strumento software che, sfruttando la semantica formale delle espressioni in OWL, è in grado di esplicitare
delle relazioni tra classi che sono implicite nella modellazione. Nella versione di Protégé utilizzata nel
progetto è installato il reasoner Hermit (versione 1.3.8), che viene attivato dal menu Reasoner cliccando su
Start reasoner. Alla fine del suo processo si ottiene una nuova tassonomia inferita nella parte Class
hierarchy inferred del tab Classes. Più avanti si spiegherà, con alcuni esempi concreti eseguiti durante il
progetto, il risultato ottenuto dalle inferenze.
Agenda Digitale – Linked Open Data
29
2.4 Procedura di conversione dal CSV a RDF e LOD
Questa sezione del documento mostra i passi che portano dal dataset presente nell’archivio online degli
open data di Regione Lombardia allo stesso dataset in versione LOD. Nella presentazione della procedura
definita e seguita nel laboratorio ITLab abbiamo utilizzato come caso di studio il dataset “Elenco RSA
accreditate”.
2.4.1 Gli open data di Regione Lombardia
Il portale degli open data considerato nel progetto (www.dati.lombardia.it) è sviluppato in Socrata 38, che è
uno dei servizi più diffusi per la costruzione di questo tipo di portale. Il dato qui archiviato e reso disponibile
in download è formattato in modo tradizionale: la rappresentazione dei vari domini è in forma tabellare e
spesso corredata da documentazione in pdf che consente all’utente di comprendere il significato delle varie
colonne.
Socrata consente sia di consultare i dati online, attraverso funzionalità di navigazione di base ma
soprattutto ne consente il download per utilizzi esterni al portale. Per il portale di Regione Lombardia, i
dataset sono distribuiti con licenza IODL 2.0 (Italian Open Data License 2.0 39).
Il portale presenta una grande quantità di dataset disponibili, tra questi sono presenti quelli scelti per lo
studio all’interno del laboratorio ITLab. Come già accennato in precedenza, i dataset considerati sono i
seguenti:
• Anagrafica scuole;
• Albo cooperative sociali;
• Comunità per minori;
• Elenco RSA accreditate;
• Strutture di ricovero e cura.
38 http://www.socrata.com/
39 http://www.dati.gov.it/iodl/2.0/
30
Agenda Digitale – Linked Open Data
Figura 22 Screenshot del portale www.dati.lombardia.it
In figura 23 è riportato uno screenshot del dataset relativo alle RSA lombarde (Elenco RSA accreditate).
Questo dataset, come gli altri presenti nel portale, sono scaricabili in diversi formati (CSV, JSON, PDF, RSS,
XSL. XLMS, XML). Nel nostro caso, il formato da utilizzare è il CSV in quanto si tratta del formato più
compatto e gestibile per memorizzare dati in formato tabellare.
Figura 23 Screenshot della tabella del dataset delle RSA accreditate
Agenda Digitale – Linked Open Data
31
Grazie a questa funzionalità è possibile ottenere il dataset (in formato 3 stelle) e procedere con il lavoro
all’esterno del portale.
2.4.2 LODRefine: manipolazione del dataset, da CSV a RDF
Come accennato in precedenza, lo strumento software scelto per portare i dataset dal formato CSV al
formato RDF è LODRefine. Questo permette di importare in progetti distinti, diversi dataset.
2.4.2.1 Importazione del dataset
Nel nostro caso, il file CSV relativo alle RSA accreditate in Regione Lombardia è importato e visualizzato in
forma tabellare con una procedura semiautomatica.
Figura 24 il dataset delle RSA accreditate caricato in LODRefine
2.4.2.2 Pulizia dei campi
LODRefine consente di effettuare una serie di operazione per la messa in qualità dei dati presentati. Le
funzionalità da utilizzare sono quelle presenti già nel progetto OpenRefine, di cui LODRefine è diretto
discendente.
Le funzionalità a cui si fa riferimento qui sono quelle di manipolazione delle colonne. Questa prima
elaborazione del dataset porta a selezionare le colonne di interesse, alla creazione di nuove colonne
contenenti informazioni derivate da altri dati, ed una generica riorganizzazione della tabella.
32
Agenda Digitale – Linked Open Data
Figura 25 Particolare del menu dei comandi in LODRefine per la gestione delle colonne dei dataset
Analogamente a quanto è possibile eseguire sulle colonne, è possibile applicare trasformazioni al valore
contenuto nelle celle o al tipo di dato loro associato. Nel caso di particolari manipolazioni (ad es. “Split
multi-valued cells”), l’operazione genera nuove colonne all’interno della tabella.
Figura 26 Particolare del menu dei comandi in LODRefine per la gestione delle celle
Molto importanti per la messa in qualità del dataset, sono le funzioni che consentono di effettuare analisi
dei cluster dei dati “Cluster and edit…” e operazioni legate all’analisi dei valori presenti in una colonna.
Importante è evidenziare che il clustering viene effettuato secondo criteri puramente sintattici, anche se
LODRefine mette a disposizione diversi algoritmi di clusterizzazione tra cui scegliere.
Agenda Digitale – Linked Open Data
33
Figura 27 Analisi della NATURA_GIURIDICA delle RSA accreditate in LODRefine
Ad esempio, nel caso delle RSA accreditate, una porzione dell’analisi della colonna NATURA_GIURIDICA
mostra i valori presenti nella colonna e la relativa frequenza. Intervenendo sui valori mostrati nel form in
figura 27, è possibile modificare tutte le occorrenze del valore all’interno della tabella. Questa funzionalità
è molto importante per unificare, normalizzare e completare i dataset.
2.4.2.3 Riconciliazione
Grazie alla presenza in LODRefine della RDF Extension, è possibile effettuare sulle colonne del dataset delle
operazioni di riconciliazione. L’idea alla base della procedura di riconciliazione è quella di recuperare da una
fonte dati esterna i riferimenti a delle risorse da associare ai dati presenti nel dataset. Questa operazione, a
tutti gli effetti, consente di collegare il dato grezzo presente nella tabella ad un dato esterno, proprio
seguendo la filosofia dei LOD. Se infatti la risorsa esterna rappresenta le risorse come URI, la riconciliazione
consente di arricchire il dataset sotto elaborazione con riferimenti verso il resto della LOD cloud.
34
Agenda Digitale – Linked Open Data
Figura 28 Riconciliazione tramite LODRefine-GUI
Come mostrato nella figura 28, LODRefine propone diversi strumenti (ad es. SPARQL endpoint) e diverse
risorse esterne (ad es. Freebase) attraverso cui riconciliare una colonna. LODRefine consente inoltre di
configurare il server attraverso cui compiere la riconciliazione. Nel caso delle attività di ITLab si è scelto di
utilizzare, come server per la riconciliazione, l’endpoint SPARQL di DBPedia disponibile all’indirizzo
it.dbpedia.org/sparql. I campi su cui applicare la procedura sono tutti quelli che riguardano il nome del
comune con le risorse di classe dbpedia:Place presenti in DBPedia Italia. Quest’ultima informazione è
sempre presente all’interno dei dataset, spesso corredata dall’indirizzo dove si trova l’erogatore del
servizio, a volte si trovano due indicazioni di comuni (sede operativa e sede direttivo). Non importa come si
presenti la tabella: la procedura viene applicata allo stesso modo sul campo contenente il nome del
comune, indipendentemente dalle altre colonne presenti nel dataset. L’algoritmo di riconciliazione effettua
infatti una comparazione puramente sintattica del dato considerato e del dato presente sul server.
Agenda Digitale – Linked Open Data
35
Figura 29 Colonna COMUNE_UBICAZIONE dopo la riconciliazione. Selezione del comune di Albino
La figura 29 mostra la colonna COMUNE_UBICAZIONE dopo l’applicazione della procedura di riconciliazione.
La procedura è semi-automatica: quando il livello di confidenza del risultato è elevato, LODRefine associa
automaticamente a ciascuna cella il valore con il maggior livello di confidenza individuato, a meno che non
ci siano diversi valori con valori di confidenza simili. In questi casi, come nel caso del comune di Albino
mostrato in figura, la selezione del nome del comune da considerare è lasciata all’utente. È sempre
possibile per l’utente modificare il valore riconciliato associato alla cella, cliccando su “Choose new match”.
2.4.2.4 Definizione RDF schema
Un'altra funzionalità importante messa a disposizione in RDF Extension permette di comporre lo schema
RDF da associare al dataset. Scopo di questo schema RDF è di definire un modello che indichi, descriva,
rappresenti come deve essere interpretato il dataset. A tutti gli effetti, questo passo della procedura
definita nel laboratorio ITLab costituisce un ponte tra il dataset e l’ontologia dei servizi descritta nelle
pagine precedenti. Il modello RDF introdotto a questo livello, a metà strada tra l’ontologia dei servizi e il
dataset, è un’estensione dell’ontologia. Considerando tutti gli RDF schema generati per ciascun dataset, si
ottiene quindi una versione più ampia dell’ontologia che, risulterà ancor più estesa ogni qual volta verrà
aggiunto un nuovo dataset.
Durante questa operazione di modellazione del dataset, è cruciale indicare quali classi delle ontologie
considerate (ontologia dei servizi pubblici, CPSV, VCARD, …) associare ai vari campi della tabella oppure ai
concetti nuovi introdotti nello schema. Altrettanto importante è considerare e opportunamente riutilizzare
le stesse classi eventualmente definite negli schemi RDF di altri dataset.
36
Agenda Digitale – Linked Open Data
Figura 30 Dettaglio della finestra di costruzione dello schema RDF
La figura 30 mostra un esempio della GUI per la costruzione dello schema RDF delle RSA accreditate. Si può
notare, nella linea “Available prefixes”, l’elenco dei prefix considerati, tra queste:
• rdfs: ontologia dei concetti generici di RDF come le classi rdfs:Class, rdfs:Type o le relazioni
rdfs:subClassOf
• dbpedia-owl: ontologia di DBPedia
• foaf: l’ontologia Friend Of A Friend
• cpsv: Core Public Service Vocabulary
• vcard: l’ontologia dei biglietti da visita vCard
• serviziPubblici: l’ontologia dei servizi pubblici definita per ITLab
Nello spazio sottostante si mostra una porzione dello schema RDF definito per il dataset delle RSA
accreditate. Questa porzione è relativa all’ubicazione della sede legale dell’RSA, rappresentata dalla classe
serviziPubblici:SedeLegaleRSA. Con la relazione vcard:hasAddress esistente tra questa classe e la cella
INDIRIZZO_SEDE_LEGALE, si dichiara che una sede legale può avere un indirizzo e che questo valore si trova
nella cella indicata. Nel caso non ci fosse alcun valore in INDIRIZZO_SEDE_LEGALE per una specifica RSA,
questa relazione non verrà presentata per questa RSA ma solo per quelle in cui, nel dataset il campo è
valorizzato.
Più complessa inceve è la descrizione del comune. Infatti lo schema include la relazione vcard:locality verso
COMUNE_SEDE_LEGALE (che è di classe dbpedia-owl:Settlement e di classe serviziPubblici:Comune) che a
sua volta si dettaglia coi valori delle celle COMUNE_SEDE_LEGALE e COD_ISTAT_COMUNE_SEDE_LEGALE.
La differenza esistente tra il primo e il secondo COMUNE_SEDE_LEGALE è che il primo, quello di classe
dbpedia-owl:Settlement, è il valore riconciliato (quindi l’URI all’interno di DBPedia Italia) mentre il secondo
è il valore originariamente contenuto nel dataset.
La definizione dello schema RDF è propedeutica all’esportazione del dataset in formato RDF. Questo file è
esportabile da LODRefine attraverso il pulsante Export presente nella schermata principale. Tra le varie
opzioni, dopo l’installazione della RDF Extension, è possibile scaricare sul proprio pc in locale il file RDF
contenente l’intero dataset e lo schema.
Agenda Digitale – Linked Open Data
37
A questo punto della procedura, il dataset su cui si è lavorato è in formato RDF, linkato a delle risorse
esterne (DBPedia Italia) e utilizza concetti di ontologie esterne. Per arrivare ad essere un RDF 5 stelle
secondo la scala di Berners-Lee, sarà necessario pubblicare il dataset su un endpoint per renderlo
disponibile in rete.
2.4.2.5 Integrazione ontologia con ogni RDF
Prima di procedere alla pubblicazione del file RDF su di un endpoint SPARQL, è necessario uniformare e
unire i dataset attraverso l’importazione dell’ontologia e l’applicazione degli algoritmi di reasoning per far
dedurre automaticamente alla macchina alcune informazione che vadano ad arricchire il dataset.
La procedura richiede che il file RDF venga caricato in Protégé e che nel modello venga caricato il file
dell’ontologia dei servizi definita nel progetto. L’applicazione del reasoner porta dopo pochi secondi alla
deduzione di informazioni, come ad esempio l’appartenenza di alcuni elementi a delle classi. Ad esempio,
nello schema RDF delle RSA accreditate, ogni struttura erogante il servizio è definita come una RSA (cioè di
classe serviziPubblici:RSA).
All’interno di Protégé è possibile visualizzare lo schema derivato dall’unione del file RDF e dell’ontologia
come grafo delle classi. La figura 29 mostra lo schema così ottenuto. In figura si può notare che la classe
serviziPubblici:RSA è definita come sottoclasse di cpsv:PublicServiceProvider. Una tipica inferenza del
reasoner è infatti dichiarare, all’interno del nuovo modello generato, ciascuna struttura come appartenente
alla classe cpsv:PublicServiceProvider.
Figura 31 Grafo dell’ontologia ottenuta integrando schema RDF e ontologia dei servizi per le RSA
L’operazione di inferenza effettuata è necessaria, ad esempio, per rendere possibile la ricerca delle
strutture erogatrici di servizi; senza la diretta appartenenza degli erogatori alla classe
cpsv:PublicServiceProvider non sarebbe possibile recuperare con una sola richiesta generica “tutte le
strutture erogatrici di servizi pubblici”.
38
Agenda Digitale – Linked Open Data
Figura 32 Dataset RSA nel portale regionale, è evidenziato un record di esempio
La struttura RSA “Fondazione Casa di Riposo RSA – Ospadale G.G.Milesi – Onlus” di Gromo (BG), presente
nel dataset (come mostrato nella figura 32, all’interno del portale degli open data della Regione
Lombardia), è mostrato nella figura 33 come una istanza della classe RSA e mostrato all’interno
dell’applicativo Protégé in tutti i suoi dati di dettaglio. Si può anche in questo screenshot notare che la
classe RSA è stato dedotto essere sottoclasse di serviziPubblci:PublicServiceProvider e che ogni istanza della
sottoclasse è anche istanza di serviziPubblci:PublicServiceProvider (l’etichetta di questa classe è infatti in
grassetto perché esistono istanze della classe stessa).
Figura 33 Dataset RSA, elenco delle classi in Protégé
Agenda Digitale – Linked Open Data
39
Figura 34 Gerarchie delle classi nelle ontologie dei dataset considerati
Nella figura 34 sono mostrate le classificazioni dei concetti definiti nei diversi dataset uniti alle ontologie.
L’obiettivo finale è di unire questi modelli in un modello unico grazie alla presenza di concetti condivisi.
Oltre alla ontologia dei servizi, infatti, negli schemi RDF definiti per i vari dataset i concetti sono stati spesso
riutilizzati e sono quindi unificanti. Alcuni esempi di questi concetti sono:
• ASL, si tratta di un Place di riferimento sia per le strutture di ricovero e cura sia per le comunità di
minori
• ServiziSanitari, si tratta di una sottoclasse di PublicService utile per accomunare i servizi forniti dalle
strutture di ricovero e cura e dalle RSA.
2.4.3 Pubblicazione sull'endpoint
Una volta che i dataset sono convertiti in RDF, bisogna pubblicarli sul web utilizzando un endpoint.
L'endpoint permette anche di testare, e migliorare, il collegamento dei dataset tra loro e con i dataset
presenti tra i Linked Open Data sul web. A seconda dei dataset interrogabili tramite un endpoint essi si
possono suddividere in due macro-categorie:
• Endpoint specifici, è possibile interrogare solo un insieme predefinito di dataset che sono precaricati
sull'endpoint, per esempio i dataset ai quali si può accedere tramite l'endpoint di DBpedia.
• Endpoint generici, è possibile interrogare qualsiasi fonte dati RDF accessibile via Web. Un endpoint
general purpose che è possibile utilizzare liberamente è l'endpoint di Virtuoso.
La pubblicazione di un dataset all’interno dell’endpoint SPARQL viene effettuata dopo che il modello RDF è
stato processato dal reasoner. La collezione di tutti i dataset dei servizi costituisce in questo modo il
modello RDF dei servizi pubblici in Regione Lombardia.
40
Agenda Digitale – Linked Open Data
Come detto in precedenza, i dataset considerati nelle attività del laboratorio sono stati l’Anagrafica scuole,
l’Albo delle cooperative sociali, le Comunità per minori, l’Elenco delle RSA accreditate e le Strutture di
ricovero e cura. L’applicativo software usato per la pubblicazione dei dati è, come detto nelle pagine
precedenti, OpenLink Virtuoso, nella sua versione Open Source.
L’endpoint è raggiungibile all’indirizzo http://itlab.crisp.unimib.it:8891/serviziPubblici. Il dato così
pubblicato è potenzialmente utilizzabile da chiunque nel mondo sia in grado di effettuare una query
SPARQL sull’endpoint e inserire nel proprio dataset riferimenti a risorse del dataset dei servizi pubblici.
Figura 35 Schermata web per l'interrogazione dell'endpoint con query SPARQL
Agenda Digitale – Linked Open Data
41
2.4.4 Esempi di interrogazioni dell’endpoint SPARQL
Obiettivo: Elenco servizi sanitari
Query:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?servizio ?type WHERE {
?servizio a serviziPubblici:ServiziSanitari.
?servizio a ?type.
FILTER(regex(?type, "serviziPubblici") )
}
Risultato:
42
Agenda Digitale – Linked Open Data
Obiettivo: Elenco servizi rivolti a minori
Query:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT distinct ?servizioLabel ?providerName ?userLabel WHERE {
?provider serviziPubblici:hasUser ?user;
serviziPubblici:hasDenominazione ?providerName.
?provider cpsv:provides ?servizio.
?servizio rdfs:label ?servizioLabel.
?user rdfs:label ?userLabel.
FILTER(regex(?user, "Minori"))
} group by ?servizioLabel ?providerName ?userLabel
Risultato:
Agenda Digitale – Linked Open Data
43
Obiettivo: Servizi a Milano
Query:
SELECT ?servizio count(?sub) as ?numerosita WHERE {
?sub a serviziPubblici:PublicServiceProvider.
?sub cpsv:provides ?o.
?o rdfs:label ?servizio.
?sub dbpedia-owl:location ?location.
?location dbpedia-owl:location ?municipality.
?municipality a dbpedia-owl:Settlement.
?municipality serviziPubblici:hasDenominazione ?den.
FILTER (?den = "Milano").
}group by ?servizio
order by ?servizio
Risultato:
44
Agenda Digitale – Linked Open Data
Query: Servizi a Bergamo e comuni confinanti
SELECT ?comuneLabel ?servizio count(?servizio) as ?numerosita WHERE {
?municipality a dbpedia-owl:Settlement.
?municipality serviziPubblici:hasDenominazione ?den.
FILTER (?den="Bergamo").
SERVICE <http://it.dbpedia.org/sparql>
{
?municipality dbpprop-it:divisioniConfinanti ?confinante.
?confinante rdfs:label ?comuneLabel.
FILTER ( lang(?comuneLabel) = "it" )
}
?location dbpedia-owl:location ?confinante.
?sub dbpedia-owl:location ?location.
Risultato:
?sub a serviziPubblici:PublicServiceProvider.
?sub cpsv:provides ?o.
?o rdfs:label ?servizio.
} group by ?comuneLabel ?servizio
order by ?comuneLabel ?servizio
Agenda Digitale – Linked Open Data
45
2.4.4.1 Alcune considerazioni
Importante è sottolineare alcuni aspetti:
• partendo dalle risorse esterne al dataset è possibile arrivare ad altri dataset e recuperare le
informazioni in essi contenute. Ad esempio, seguendo il link http://it.dbpedia.org/resource/Gromo che
rappresenta il paese di Gromo in DBPedia Italia, è possibile arrivare alle informazioni mostrate nella
figura che segue;
Figura 36 Schermata web della pagina di DBPedia Italia per il comune di Gromo
È quindi possibile recuperare informazioni aggiuntive per arricchire il proprio dataset prima della
pubblicazione (ad esempio aggiungendo il numero di abitanti o la provincia direttamente nel dataset)
oppure recuperare le informazioni effettuando delle query federate all’interno dell’endpoint SPARQL.
46
Agenda Digitale – Linked Open Data
• la procedura presentata precedentemente è applicabile a qualsiasi dataset open source di Regione
Lombardia, sia esso relativo ai servizi pubblici o altro dominio. Nel caso non si trattasse di servizi
pubblici cambierebbero le ontologie di riferimento, ma gli strumenti che supportano il flusso logico del
lavoro potrebbero rimanere inalterati;
• lavorare sui dataset dei servizi porta alla loro unificazione in un unico endpoint, quindi ad un unico
dataset dei servizi pubblici. Questo, per poter giungere ad una reale pubblicazione e fruizione da parte
degli utenti, necessita di un approfondimento dell’ontologia dei servizi che riguardi principalmente due
aspetti e la disponibilità dei dati. Da un lato infatti si dovrebbe capire come classificare i servizi
(tipologia di servizi, tipologia utenti, tipologia degli erogatori), dall’altro sarebbe necessario verificare
ed eventualmente recuperare i dati per avere un dataset finale il più completo possibile;
• pubblicare dei dati su un endpoint può essere la conclusione di un lavoro, ma non garantisce comunque
che il dato venga utilizzato da altri; la pubblicazione su endpoint ne limita l’uso ad addetti ai lavori con
conoscenze specifiche in campo informatico. L’uso dei LOD da parte di un pubblico di “massa” può
essere garantito solo dall’introduzione di uno strumento di consultazione che renda trasparente
l’accesso ai dati tramite query SPARQL.
Agenda Digitale – Linked Open Data
47
2.5 Conclusioni
In conclusione, il progetto ITLab nella sua seconda edizione ha prodotto dei risultati concreti per quanto
riguarda il tema dei Linked Open Data. Si sono raggiunti gli obiettivi di portare a 5 stelle alcuni dataset a 3
stelle scelti dal patrimonio informativo della Regione Lombardia, si è sviluppata un'ontologia dei servizi in
OWL funzionante e riutilizzabile per altri dataset, si è sviluppata e consolidata una procedura di conversione
di dataset in RDF e LOD facilmente ingegnerizzabile, e per ultimo è stato implementato un endpoint
SPARQL con il quale accedere e interrogare i dati LOD della Regione Lombardia.
Con questi risultati si può affermare di aver creato dei LOD secondo le direttive del W3C, pronti per essere
resi visibili al resto della comunità dei LOD. Questo è stato possibile grazie al collegamento di cinque
dataset in RDF con la LOD cloud attraverso l'utilizzo di parti di ontologie standard (DBpedia, FOAF, VCard) e
si è potuto eseguire delle query federate, accedendo a DBpedia, per estrarre nuove informazioni (per
esempio i comuni limitrofi o il numero di abitanti di un luogo). Questo appare il punto di maggior rilievo del
progetto, l'esser riusciti a importare, nei dati pubblicati da Regione Lombardia, informazioni non presenti in
precedenza, e che queste informazioni provengono da altre fonti di LOD cui i dataset lombardi sono ora
collegati. Inoltre si è dimostrato come con le query in SPARQL su diversi dataset si possono ottenere
risultati che difficilmente si potrebbero ottenere interrogando in SQL dataset relazionali. Tutto ciò
rappresenta una potenziale base di conoscenza per la creazione di nuovi servizi e applicazioni che sfruttino i
dati di una PA.
Il progetto ha quindi permesso di mettere in evidenza alcuni benefici dei LOD per le Pubbliche
amministrazioni, che di seguito possono essere così sintetizzati:
• esporre i dati strutturati delle PA sul web per creare nuovi servizi e applicazioni,
• interconnettere i dati di una PA con quelli di altre fonti,
• gli esseri umani e le applicazioni possono accedere facilmente a questi dati utilizzando le tecnologie
web,
• le applicazioni possone "seguire" i link tra diversi dataset in modo da ottenere ulteriori informazioni
di contesto,
• i link ai dati di una PA possono aumentarne la visibilità e il valore conoscitivo.
Tuttavia non si possono non evidenziare alcuni punti di attenzione emersi durante il progetto e per i quali
sono state fatte anche alcune ipotesi di approfondimento, rilevazione che comunque rappresenta un
fattore importante per un progetto di ricerca. I maggiori punti da sottolineare sono:
• usabilità di alcune tecnologie LOD: la difficoltà per un utente comune di usare la sintassi SPARQL
nell'eseguire query sull'endpoint. Da ciò deriva la necessità di creare interfacce facilitanti con le
quali interagire per navigare i dati LOD (attraverso menù a tendina, faccette, filtri ecc.).
• integrabilità semantica: la difficoltà di identificare e integrare ontologie e link esterni da importare
e riutilizzare nei propri dataset, e legato a questo l'ampio sforzo di supervisione manuale necessaria
per utilizzare nel modo corretto relazioni e concetti definiti da altri soggetti.
• integrabilità dei dataset: è richiesto un grosso sforzo di modellazione dei dataset in RDF prima di
pubblicarli sull'endpoint, e gli strumenti che eseguono il linking automatico non sono ancora
sufficientemente efficienti, inoltre tale operazione è altamente dipendente dal dominio, ciò
48
Agenda Digitale – Linked Open Data
•
necessita di esperti di dominio che supportino il lavoro di modellazione. Per questo in futuro si
dovrà studiare e testare in modo approfondito alcuni tool (per esempio, SILK) e algoritmi per
facilitare questa task.
persistenza e qualità dei LOD: un tema aperto, che dovrà essere affrontato in modo adeguato nei
prossimi progetti, è quello relativo alla persistenza dei dati LOD in rete e alla loro qualità, prima e
dopo la pubblicazione. Finora non ci sono garanzie che i dati pubblicati e linkati nella LOD cloud
siano persistenti, non esistono a riguardo enti che garantiscano e monitorino questo fattore, così
come la qualità dei dati che deve essere affrontata con tecniche specifiche di messa in qualità e con
strumenti adeguati.
Agenda Digitale – Linked Open Data
49
3
Bibliografia e sitografia
Berners-Lee, T., Hendler, J. and Lassila, O., "The semantic web." Scientific american 284.5 (2001), pp. 28-37.
Berners-Lee, T. (2006), Linked Data. http://www.w3.org/DesignIssues/LinkedData.html
Bizer, C., Cyganiak, R., Heath, T. (2007), How to Publish Linked Data on the Web.
http://www4.wiwiss.fuberlin.de/bizer/pub/LinkedDataTutorial/
Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge acquisition,
5(2), pp. 199-220.
Jain, P., Hitzler, P., Yeh, P. Z., Verma, K., & Sheth, A. P. (2010) Linked Data Is Merely More Data. In AAAI
Spring Symposium: linked data meets artificial intelligence.
Jain, P., Hitzler, P., Sheth, A. P., Verma, K., & Yeh, P. Z. (2010) Ontology alignment for linked open data.
In The Semantic Web–ISWC 2010 (pp. 402-417). Springer Berlin Heidelberg.
Lehmann, J., Isele, R., Jakob, M., Jentzsch, A., Kontokostas, D., Mendes, P. N., ... & Bizer, C. (2013). Dbpediaa large-scale, multilingual knowledge base extracted from wikipedia. Semantic Web Journal.
Shadbolt, N., Hall, W. and Berners-Lee, T., "The semantic web revisited." Intelligent Systems, IEEE 21.3
(2006), pp. 96-101.
Agenda Digitale Europea: http://ec.europa.eu/information_society/digital-agenda/index_en.htm, 2012
BBC Music: http://www.bbc.co.uk/music
CKAN: http://ckan.org/
CPSV: https://joinup.ec.europa.eu/asset/core_public_service/asset_release/core-public-service-vocabulary
DBLP: http://dblp.uni-trier.de/db/
DBPedia Italia: http://it.dbpedia.org/
ESD-Toolkit: http://www.esd.org.uk/esdtoolkit/default.aspx
Geonames: http://www.geonames.org/
ISA: http://ec.europa.eu/isa/
Joinup: https://joinup.ec.europa.eu/
LGBM: http://standards.esd.org.uk/LGBMDiagram.aspx
LOD Cloud: http://lod-cloud.net/state/
LOD Refine: http://code.zemanta.com/sparkica/
Musicbrainz: http://musicbrainz.org/
Open Refine: http://openrefine.org/
Portale Storico Camera dei Deputati: http://storia.camera.it/
Protégé: http://protege.stanford.edu/
Socrata: http://www.socrata.com/
UMBEL: http://umbel.org/
VCard: http://www.w3.org/TR/vcard-rdf/
Virtuoso: http://virtuoso.openlinksw.com/
W3C: http://www.w3.org/
Wordnet: http://wordnet.princeton.edu/
YAGO: http://www.mpi-inf.mpg.de/yago-naga/yago/
50
Agenda Digitale – Linked Open Data

XI ITALIAN STATA USERS MEETING - ABSTRACT

La Rassegna Stampa del 26 ottobre 2014

Elaborato Palumbo Francesco n46000140

Elaborato minocchi mario n46000420

Documento PDF - Università degli Studi di Padova

ELEMENTI PER LA REGOLAZIONE ELETTRICA

In Vivo #9