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: crisp@crisp-org.it | 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
© Copyright 2024 Paperzz