Linked Data ICONVIS Progetto e sviluppo di un visualizzatore di dati

POLITECNICO DI TORINO
III Facoltà di Ingegneria
Corso di Laurea in Ingegneria del Cinema e dei Mezzi di
Comunicazione
Tesi di Laurea Magistrale
Linked Data ICONVIS
Progetto e sviluppo di un
visualizzatore di dati relazionali
basato su ontologie
Relatore:
prof. Juan Carlos De Martin
Candidato:
Giuseppe Futia
Anno accademico 2010-2011
II
Ringraziamenti
Si dice che gli occhi di una persona, nel corso di una vita, non cambino mai.
Ringrazio mio padre, mia madre e mio fratello perché il loro sguardo nei miei confronti, malgrado quello che combinassi, non è mai cambiato e mai cambierà. Ringrazio
Giuseppe per i preziosi consigli e perché durante il mio percorso di tesi mi è stato davvero vicino. Ringrazio Federico, che ha contribuito a una vastissima parte di
questo lavoro da un punto di vista tecnico, umanistico e umano. Lo ringrazio assieme
a Enrico ed Ernesto, perché tutti insieme mi hanno regalato le cose più preziose che
ho imparato all’Università e che porterò sempre con me. Ringrazio Gabbo, Robbè,
Mimmo, Carlo, Lucia, perché sono stati una bellissima scoperta. Ringrazio Puglia,
che malgrado gliene dicessi, oggi è alla conquista della gloriosa America, la terra
delle opportunità. Ringrazio Lele, perché in questi anni, nei momenti di più grande
difficoltà, mi è stato sempre vicino. Ringrazio Ale, Umbi, Cleme, Guido, Bubbo e
Fabio, perché il bar di Giò resta il luogo in cui, ancora oggi, riesco a ritrovare me
stesso e perché sono e resteranno per sempre gli amici della porta accanto. Ringrazio
Francesca, Lara, Glenn, Toppy e Nebbio, perché dopo averli conosciuti sono uscito
fuori dal torpore in cui mi trovavo. Ringrazio Antonella e Mirko, perché col ballo
mi hanno insegnato tanto. Ringrazio Anna, perché professionalmente è stata la prima persona a darmi fiducia. Ringrazio Simona e tutte le persone del mio passato.
Ringrazio Elena, che mi ha saputo aspettare, e tutte le persone del mio presente.
III
Indice
Ringraziamenti
I
III
Prima Parte
1
1 Introduzione
3
2 Semantic Web
2.1 I layers del Semantic Web . . . . . . . . .
2.2 RDF e rappresentazione dei dati . . . . . .
2.2.1 Mapping di RDB su RDF . . . . .
2.3 OWL e rappresentazione della conoscenza
2.3.1 RDF Schema . . . . . . . . . . . .
2.3.2 Web Ontology Language . . . . . .
2.3.3 Perché usare OWL . . . . . . . . .
2.3.4 I sottolinguaggi di OWL . . . . . .
2.3.5 Costrutti fondamentali . . . . . . .
2.4 Ontologie . . . . . . . . . . . . . . . . . .
2.5 Ricchezza semantica dei dati . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Linked Data
3.1 Che cosa sono i Linked Data? . . . . . . . . .
3.1.1 Linee guida . . . . . . . . . . . . . . .
3.2 Tecnologie del Linked Data . . . . . . . . . .
3.3 Pubblicare Linked Data sul Web . . . . . . . .
3.3.1 URI e vocabolari RDF . . . . . . . . .
3.3.2 Generazione dei link . . . . . . . . . .
3.4 Il Linking Open Data Project . . . . . . . . .
3.5 DBpedia . . . . . . . . . . . . . . . . . . . . .
3.5.1 Struttura della conoscenza in DBpedia
3.6 Linked Data e Semantic Web . . . . . . . . .
IV
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
9
10
13
13
15
16
16
17
19
21
.
.
.
.
.
.
.
.
.
.
23
23
24
25
27
27
27
29
31
33
36
II
Seconda Parte
37
4 Stato dell’arte
4.1 Visualizzazione delle ontologie . .
4.1.1 Tecniche di visualizzazione
4.1.2 Multidimensionalità . . . .
4.2 Linked Data browsers . . . . . . .
4.2.1 Disco . . . . . . . . . . . .
4.2.2 Tabulator . . . . . . . . .
4.2.3 Sig.ma . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Linked Data ICONVIS
5.1 Il back end dell’applicazione . . . . . .
5.2 Tecnologie del front end . . . . . . . .
5.2.1 ActionScript 3.0 . . . . . . . . .
5.2.2 DBpedia Lookup Service . . . .
5.3 Visualizzazione . . . . . . . . . . . . .
5.3.1 Elementi dell’ontologia . . . . .
5.3.2 Visualizzazione dei dati . . . . .
5.3.3 Visualizzazione dei Linked Data
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
51
53
53
55
58
.
.
.
.
.
.
.
.
61
61
62
62
63
65
65
75
77
6 Campi di applicazione e conclusioni
83
6.1 Visualizzazione dei dati nella Pubblica Amministrazione . . . . . . . 83
6.2 Il giornalismo nell’era dei dati . . . . . . . . . . . . . . . . . . . . . . 85
6.3 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Bibliografia
89
V
Elenco delle tabelle
3.1
3.2
5.1
6.1
DBpedia: classi dell’ontologia, numero delle istanze, esempi di properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparazione tra le differenti tipologie di estrazione dei dati da
DBpedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabella di confronto tra differenti visualizzatori di ontologie e Linked
Data ICONVIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entità estratte dall’archivio del New York Times . . . . . . . . . . .
VI
. 32
. 35
. 74
. 86
Elenco delle figure
2.1
2.2
3.1
3.2
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Lo stack del Semantic Web . . . . . . . . . . . . . . . . . . . . . . . .
RDF: grafo orientato, sintassi RDF/XML e N3 . . . . . . . . . . . . .
owl:sameAs - Il concetto di Berlino espresso tramite due risorse appartenenti a datasource differenti . . . . . . . . . . . . . . . . . . . .
Sezione del Linking Open Data Project Cloud Diagram. Per visualizzare l’intera cloud, visita: http://richard.cyganiak.de/2007/10/lod/
Visualizzazione dei concetti dell’ontologia della Pizza, comunemente
proposta per spiegare gli elementi principali di un’ontologia, in Protégé
Visualizzazione di un’ontologia in Isaviz . . . . . . . . . . . . . . . . .
Visualizzazione dei risultati di ricerca in Grokker . . . . . . . . . . .
Visualizzazione di tipo tree map . . . . . . . . . . . . . . . . . . . . .
Visualizzazione basata sulle information slices circolari . . . . . . . .
Visualizzazione di una porzione dell’ontologia adottata dal Brazilian
Agricultural Research Society . . . . . . . . . . . . . . . . . . . . . .
Visualizzazione di concetti in BiFocal Tree . . . . . . . . . . . . . . .
Visualizzazione dei concetti di un’ontologia in Ontosphere . . . . . .
Screenshot dell’interfaccia di Disco . . . . . . . . . . . . . . . . . . .
Screenshot di Tabulator in modalità ‘esplorazione’ . . . . . . . . . . .
Visualizzazione di una mappa in Tabulator in modalità ‘analisi’ . . .
Visualizzazione di un calendario in Tabulator in modalità ‘analisi’ . .
Visualizzazione dei risultati in Sig.ma . . . . . . . . . . . . . . . . . .
Visualizzazione dell’area contenente i riferimenti alle sorgenti dei dati
in Sig.ma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Classi dell’ontologia con indicatore delle sottoclassi . . . . . . . . . .
Classi dell’ontologia con indicatore delle istanze . . . . . . . . . . . .
Classi dell’ontologia con indicatore di classi e istanze . . . . . . . . .
Visualizzazione delle istanze dell’ontologia . . . . . . . . . . . . . . .
Visualizzazione delle istanze con anteprima del grafo delle classi . . .
Visualizzazione di una porzione della tassonomia . . . . . . . . . . . .
Movimento del grafo . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relazioni dell’ontologia . . . . . . . . . . . . . . . . . . . . . . . . . .
VII
7
11
28
30
41
43
45
47
48
49
50
52
54
55
56
57
59
60
66
67
68
68
69
70
71
72
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
Relazioni dell’ontologia con anteprime della tassonomia e delle istanze
appartenenti a una classe . . . . . . . . . . . . . . . . . . . . . . . . .
Visualizzazione dei dati delle istanze della classe ‘palazzo’ . . . . . . .
Visualizzazione dei dati dell’istanza ‘Palazzina di Caccia di Stupinigi’
Visualizzazione del grafo relativo all’istanza Cesare Pavese ed alle
tipologie di dati recuperati da DBpedia . . . . . . . . . . . . . . . . .
Visualizzazione dei dati relativi al comune di Chivasso prelevati da
DBpedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Informazioni su Cesare Pavese prelevate da DBpedia . . . . . . . . .
Informazioni su Antonio Ascari prelevate da DBpedia . . . . . . . . .
Finestra del browser durante la visualizzazione dei Linked Data . . .
VIII
73
76
76
78
79
80
81
81
Parte I
Prima Parte
Capitolo 1
Introduzione
Le conseguenze legate al processo di digitalizzazione hanno determinato il proliferare di una mole d’informazione sempre più complessa da gestire e valorizzare. Sorge
dunque una serie di difficoltà legata al reperimento di informazioni che effettivamente soddisfino gli obiettivi di ricerca dell’utente. Per trovare una soluzione a
queste problematiche occorre adoperare strumenti che sfruttino il contesto semantico in cui i documenti, o più in generale qualunque altro tipo di dato, sono collocati.
In quest’ambito, le ontologie rappresentano il mezzo più comune attraverso cui raggiungere questo tipo di obiettivo: esse infatti descrivono una collezione di concetti
legati tra loro all’interno di uno specifico dominio di conoscenza. Ecco perché, oltre
a fornire un supporto prezioso agli algoritmi di ricerca semantica, le ontologie in
molti casi vengono rappresentate visivamente. Tuttavia, ciò che più interessa l’utente non riguarda tanto la comprensione del dominio entro cui sono collocati i dati,
quanto piuttosto il recupero degli stessi. A tal proposito, l’ontologia diviene lo strumento visivo (estremamente più semplice da usare rispetto alla composizione di una
query sul database) con il quale l’utente è in grado di individuare con esattezza le
informazioni che gli interessano, attraverso una navigazione dei concetti legati tra
loro da relazioni di diversa natura. Inoltre, è possibile arricchire tali relazioni e di
conseguenza l’insieme dei dati che si possono esplorare, sfruttando dataset presenti
sul Web, pubblicati secondo regole ben precise (le best practices che riguardano i
cosiddetti Linked Data).
Linked Data ICONVIS (Interactive and Customizable Ontology-based Visualization System) è un’applicazione RIA (Rich Internet Application) caratterizzata da
una serie di strumenti che consentono di visualizzare i dati inseriti in un database
(DB) a partire dall’ontologia costruita su di essi. A differenza di un tradizionale
motore di ricerca, Linked Data ICONVIS (LDI) è in grado di fornire un insieme di
informazioni utili alla comprensione del dominio complessivo a cui appartengono i
dati. Oltre a ciò, l’applicazione è in grado di agganciarsi a sorgenti di dati aperti presenti sul Web per incrementare la conoscenza con la quale l’utente si confronta. Se
3
1 – Introduzione
consideriamo ad esempio un’ontologia costruita a partire dai dati riguardanti i beni
culturali situati in Piemonte, sarà presente l’entità ‘Palazzo Carignano’, ammettendo
che vi siano dati che la riguardano. A questo punto, attraverso una serie di meccanismi inseriti nell’applicazione, è possibile andare alla ricerca dell’entità ‘Palazzo
Carignano’ presente su DBpedia, ricevendo i dati che questa mette a disposizione,
arricchendo ulteriormente i dati presenti sul database di partenza. L’applicazione
è adatta in particolare ai content publisher che desiderano offrire ai propri utenti
un’esperienza di fruizione dei loro grandi archivi didattica, alternativa e coinvolgente. Grazie all’alto grado di configurabilità di cui è caratterizzato, il software
si può adattare a ogni diverso dominio (come e-commerce, beni culturali, editoria
online, pubblica amministrazione, ecc.) a partire dalle impostazioni specifiche per
la gestione del database e dell’ontologia.
Nella prima parte di questo lavoro (capitoli 2 e 3) vengono argomentati gli elementi teorici essenziali riguardanti il Semantic Web e i Linked Data, che forniscono
una premessa fondamentale per comprendere il contesto entro il quale si colloca
l’applicazione. Il capitolo 4 descrive lo stato dell’arte della visualizzazione, con
un’analisi approfondita dei principali visualizzatori di ontologie e una panoramica
dei più importanti Linked Data browsers che sono oggi a disposizione degli utenti. Il
capitolo 5 descrive tutti gli aspetti che riguardano l’applicazione LDI, dalle tecnologie che utilizza alle tecniche di visualizzazione che implementa. Infine, nel capitolo
6 vengono discussi alcuni dei possibili campi di applicazione del software, quali ad
esempio la Pubblica Amministrazione e il Data Journalism.
4
Capitolo 2
Semantic Web
Il Semantic Web (SW) rappresenta un’estensione del Web attuale nel quale l’informazione viene strutturata per veicolare maggiore significato e consentire molteplici
occasioni di cooperazione tra macchine ed esseri umani. Questa definizione, apparsa
su un articolo del 2001 scritto da Tim Berners Lee, James Hendler e Ora Lassila per
la rivista Scientific American 1 fornisce un primo quadro di quali siano gli intenti e
gli obiettivi del SW. All’interno del lavoro intitolato A framework for Web Science
[4], si specifica inoltre come tale estensione consista in un rafforzamento del paradigma secondo il quale il Web induce un vero e proprio cambiamento del modo di agire
delle persone. Ai suoi albori, la tecnologia ha permesso infatti di condividere con
facilità e a buon mercato i documenti sulla rete: il SW ha il compito di favorire la
propagazione di questa condotta anche all’universo dei dati, fornendo i presupposti
che ne permettano una realizzazione da un punto di vista tecnologico.
La necessità di collegare tra loro collezioni strutturate di informazioni appartenenti a soggetti diversi, in modo tale da rendere possibili operazioni di ragionamento
automatico attraverso un insieme di regole di inferenza, obbliga a tener conto di
compromessi (trade-off ) di diversa natura. In primo luogo, poiché occorre far coesistere diversi sistemi di rappresentazione della conoscenza, è necessario utilizzare
un linguaggio che abbia una potenza espressiva tale da poter descrivere proprietà
e relazioni complesse, ma che allo stesso tempo sia abbastanza “elastico” di modo
che gli agenti software non incorrano in paradossi o inconsistenze. Il trade-off che
dunque coinvolge più da vicino gli intenti del SW riguarda un’interoperabilità semantica: il prevalere dell’idea secondo cui è fondamentale creare le premesse perché
sorgenti di dati differenti possano essere collegate tra di loro, provocherebbe un appiattimento delle strutture di dati a discapito della loro stessa capacità espressiva.
D’altro canto, maggiore espressività comporta inevitabilmente tutta una serie di
difficoltà nel relazionare i dati tra loro.
1
http://www.scientificamerican.com/article.cfm?id=the-semantic-web
5
2 – Semantic Web
2.1
I layers del Semantic Web
Lo sviluppo di applicazioni che rispettino i principi del SW implica la necessità di
definire una pila di protocolli che stabilisca un insieme di linguaggi e tecnologie con
l’obiettivo di “modularizzare” il problema, in maniera tale che ad ogni livello venga
associato uno standard specifico. Nello stack proposto dal W3C (vedi Figura 2.1) il
livello più alto prettamente riconducibile alle tecnologie del SW è rappresentato dal
Trust. Poiché i dati sono collocati in una dimensione globale e provengono da sorgenti differenti, è necessario che l’utente sia in grado di distinguere le fonti affidabili
da quelle che invece non lo sono. A tal proposito, il livello di “fiducia” sui dati è accertabile da un lato in maniera esplicita, nel momento in cui si considera attendibile
l’origine dell’informazione, oppure può essere derivato in modo automatico a partire
da agenti intelligenti in grado di effettuare operazioni di deduzione o inferenza.
Nel caso di una deduzione automatica, è necessario quantificare in che modo sia
stato calcolato il livello di Trust. Occorre dunque una componente Proof che fornisca
indicazioni in merito alla logica sottesa al ragionamento. La “prova” consiste dunque
di un insieme di informazioni inferite, ognuna delle quali viene sfruttata dal motore
inferenziale per derivare un determinato risultato, in relazione ai valori di Trust che
hanno permesso di controllare la veridicità di ciascuna deduzione.
Naturalmente, la solidità del livello Proof si fonda sulla base della cosiddetta
Unifying Logic: la logica matematica rappresenta infatti il mezzo più adeguato per
consentire a una macchina di processare una determinata informazione e svolgere
un insieme di operazioni di reasoning per riuscire a derivarne di nuove. La logica
dev’essere perciò in grado di rispondere a due esigenze specifiche: da un lato rendere
efficace la prova e dall’altro descrivere l’informazione stessa. Come già anticipato nel
paragrafo introduttivo al SW, è necessario garantire un determinato grado di espressività per definire modelli concettuali e regole d’inferenza, senza tuttavia indurre in
paradossi o inconsistenze gli agenti che ragionano sull’informazione.
La parte superiore della pila costituisce dunque l’insieme di tutti gli elementi
necessari per poter abilitare sui dati operazioni di ragionamento. La parte inferiore,
invece, ingloba un insieme di tecnologie e linguaggi atti a formalizzare la conoscenza
in maniera da rendere attuabili tali operazioni. Innanzitutto, occorre un meccanismo per identificare ed accedere alle risorse. Per questi motivi, uno dei blocchi
fondamentali è quello dei cosiddetti URI2 (Uniform Resource Identifier ), ovvero
stringhe che identificano univocamente risorse generiche. Quest’ultimi assumono
inoltre un’estrema rilevanza nell’ambito della rappresentazione della conoscenza,
2
http://en.wikipedia.org/wiki/Uniform Resource Identifier
6
2.1 – I layers del Semantic Web
Figura 2.1.
Lo stack del Semantic Web
7
2 – Semantic Web
poiché divengono i mattoncini fondamentali per i linguaggi ontologici3 , che li adottano per l’identificazione dei concetti rilevanti per codificare l’informazione. Il termine conoscenza (o più propriamente l’espressione dominio di conoscenza) definisce
un’astrazione attraverso il quale ci si riferisce ad una specifica area dello sforzo
umano4 . La rappresentazione della conoscenza sfrutta in questo senso un insieme
di simboli per rappresentare tale dominio, creando le condizioni affinché sia applicabile una serie di metodi per inferire nuova conoscenza, grazie ad un ragionamento
formalizzato.
Il livello immediatamente sovrastante a URI è XML. In breve, l’eXtensible Markup
Language indica un linguaggio di marcatura che consente di costruire ed utilizzare
i propri tag, al fine di garantire l’interoperabilità sintattica, che permette a sistemi
differenti di interpretare la sintassi e la struttura dei documenti scambiati. Oltre a
ciò, XML consente un certo grado di interoperabilità strutturale che riguarda invece
l’interpretazione delle strutture dei documenti riconducibili a diversi schemi logici,
qualora si conoscano le regole di traduzione.
Tuttavia, per poter raggiungere anche la cosiddetta interoperabilità semantica,
ossia la capacità di interscambio di dati sulla base del significato che essa è in
grado di veicolare, piuttosto che sul suo formato, occorre risalire al livello successivo
della pila: RDF5 (Resource Description Framework ). Esso è lo strumento base
proposto dal W3C per la codifica, lo scambio e il riutilizzo di metadati strutturati per
l’interscambio di informazioni sul Web. Il data model RDF permette di esprimere
asserzioni elementari costituite da tre elementi: il soggetto che identifica l’entità,
il predicato che specifica determinate proprietà e l’oggetto che fornisce un valore
per tali proprietà6 . Occorre specificare che all’interno di un’asserzione l’oggetto può
essere a sua volta un’entità (identificata da un URI) od assumere un valore letterale.
Pur consentendo un primo grado di interpretabilità semantica, RDF non contiene un’espressività tale da poter gestire alcune situazioni in cui, ad esempio, due
sistemi differenti sfruttino URI diversi per poter identificare la medesima risorsa. In
tal caso infatti non sarebbe possibile confrontare ed integrare le asserzioni presenti
in un sistema con quelle collocate nell’altro. Pertanto, serve un linguaggio per poter affermare che in questo caso i due identificatori hanno lo stesso significato. Per
rispondere a tale esigenza, si utilizzano le cosiddette ontologie, ovvero rappresentazioni della conoscenza di un insieme di concetti appartenenti a un dominio, che
specificano inoltre la natura delle relazioni che intercorrono tra questi stessi concetti.
I linguaggi ontologici prevalentemente adottati da parte della comunità del SW sono
3
Per approfondire, vedi il paragrafo Ontologie
http://en.wikipedia.org/wiki/Domain knowledge
5
http://www.w3.org/RDF/
6
Per approfondire vedi il paragrafo RDF e rappresentazione dei dati
4
8
2.2 – RDF e rappresentazione dei dati
RDF Schema7 e OWL8 (Web Ontology Language).
Esistono inoltre dei meccanismi che permettono di potenziare le capacità delle
macchine di elaborare conoscenza, ossia i sistemi a regole (Rules). Poiché sono già
largamente diffusi ed utilizzati all’interno della comunità scientifica, la proposta da
parte del W3C è stata quella di standardizzare RIF9 , un metodo che consente ai
sistemi a regole esistenti di interagire tra di loro. Al fine di interrogare datasource
che esprimono i propri dati in RDF, è necessario trovare uno strumento che da un
lato permetta di realizzare delle query sui dati e dall’altro definisca un protocollo che
consenta di effettuare tali query sul Web. Entrambi i requisiti vengono soddisfatti
da SPARQL10 attraverso cui è possibile estrarre informazioni dalle basi di conoscenza distribuite sulla rete. Infine, una componente importante è rappresentata da
Crypto (che indica crittografia e firma digitale) che pur non essendo direttamente
legata alle tecnologie del SW, costituisce un elemento fondamentale per raggiungere
il cosiddetto Trust e determinare dunque l’affidabilità dei dati.
I paragrafi successivi tratteranno in particolar modo i linguaggi per la rappresentazione della conoscenza, che costituiscono il presupposto essenziale per quello
che il SW si propone di realizzare.
2.2
RDF e rappresentazione dei dati
Una delle questioni più importanti concernenti il SW riguarda la creazione di connessioni tra dati appartenenti a fonti diverse. Per questi motivi, è necessario un
framework comune che consenta una vera e propria “liberazione11 ” dei dati e che
allo stesso tempo garantisca condizioni di interoperabilità. RDF è in grado di rispondere ad entrambe le esigenze, specie nel momento in cui venga scelto XML come
sintassi d’interscambio dei dati12 . XML permette di abilitare un meccanismo di interoperabilità per coloro che vogliono esprimere i dati in RDF ed allo stesso tempo
consente di sfruttare un insieme di strumenti e parser ampiamente diffusi per l’elaborazione dei dati13 . In questo modo, i dati possono essere aggregati e relazionati tra
7
http://www.w3.org/TR/rdf-schema/
http://www.w3.org/TR/owl-features/
9
http://www.w3.org/2005/rules/wiki/RIF Working Group
10
http://www.w3.org/TR/rdf-sparql-query/
11
[4] p.19
12
Occorre ricordare che RDF non definisce un formato in cui pubblicare i dati, ma piuttosto un
modello di rappresentazione. Oltre ad XML, infatti, è possibile rappresentare formalismi RDF anche attraverso la sintassi NTriple (http://www.w3.org/2001/sw/RDFCore/ntriples/) o la relativa
sintassi semplificata N3 (http://www.w3.org/DesignIssues/Notation3)
13
La sintassi RDF/XML è l’unica ad avere una specifica Recommendation del W3C
8
9
2 – Semantic Web
di loro per poi, in una fase successiva, essere ricondotti ad entità del mondo reale14 ,
favorendo interpretazioni consistenti tra datasource eterogenei.
RDF ha dunque l’obiettivo di definire un sistema per rappresentare e modellare le
risorse, in cui ciascuna di esse viene identificata univocamente (attraverso gli URI) e,
cosı̀ come nel caso dei sistemi di classificazione, prevede la possibilità di associare ad
ogni risorsa dei metadati descrittivi. I metadati vengono genericamente definiti come
dati su dati. Utilizzati alle origini per classificare i volumi all’interno dei cataloghi
delle biblioteche, in ambito digitale sono sfruttati di descrivere il contenuto e il
contesto entro il quale sono collocati i file. Una pagina Web, ad esempio, potrebbe
includere metadati che indichino la lingua in cui è scritta, gli strumenti utilizzati
per crearla, gli argomenti che affronta15 . L’enunciato (statement) rappresenta la
struttura base di RDF ed è formato da tre componenti: il soggetto, che identifica
la risorsa, il predicato, che definisce un attributo o una proprietà del soggetto che
s’intende descrivere e l’oggetto, ossia il valore che il predicato assume in relazione al
soggetto considerato. Per questi motivi, l’enunciato viene anche chiamato “tripla”
ed è rappresentato secondo un modello a grafo etichettato, in cui soggetto e oggetto
sono i nodi e il predicato è l’arco orientato (Figura 2.2).
2.2.1
Mapping di RDB su RDF
L’obiettivo del SW è quello di creare un enorme database globale che trascenda
le singole componenti. Una visione di questo tipo è diretta conseguenza di uno
dei principali intenti del SW, ovvero la creazione di collegamenti tra datasource
diversi. In questo modo, infatti, la qualità dei dati non è legata soltanto a un valore
intrinseco, ma cresce in base alle modalità con cui i dati sono relazionati tra loro,
grazie alle quali è possibile sviluppare applicazioni in grado di compiere operazioni
differenti su sorgenti eterogenee. Il primo passo a livello realizzativo consiste nel
mapping di Relational Databases (RDB) su RDF. Uno degli elementi di maggiore
criticità nell’evoluzione del Web, e in particolare nel passaggio dal cosiddetto Web
of Documents al Web of Data, consiste proprio nell’inclusione e nella condivisione
dell’enorme quantità di dati presente all’interno dei database relazionali. Il mapping
di questi dati su RDF coinvolge attualmente diversi ambiti di ricerca e conduce
allo sviluppo e all’implementazione di tecniche sempre più efficienti all’interno di
diversi domini applicativi. Per questi motivi, RDF non rappresenta soltanto un
data model, ma svolge il ruolo di vera e propria piattaforma d’integrazione per dati
che provengono da fonti diverse.
Ciascun DB, in relazione al dominio cui fa riferimento, possiede specifiche caratteristiche in termini di scalabilità, efficienza di storage, esecuzione ottimizzata delle
14
Per approfondire vedi il paragrafo dedicato alle Ontologie
Tra le collezioni di metadati più usate vi è Dublin Core, che prevede la definizione di un insieme
di elementi che rappresentano i metadati necessari per descrivere opportunamente risorse in rete
15
10
2.2 – RDF e rappresentazione dei dati
Figura 2.2.
RDF: grafo orientato, sintassi RDF/XML e N3
11
2 – Semantic Web
query e affidabilità. A differenza del data model relazionale, i dati espressi in RDF
possono essere interpretati, processati e in generale sono in grado di veicolare maggiore espressività. In uno studio dal titolo Relational Databases on the Semantic
Web [2] Tim Berners Lee discute i tratti comuni e quelli distintivi che caratterizzano il modello RDF e quello Entità-Relazione (ER). In particolare, ci si sofferma
sul concetto di relazione o predicato che RDF è in grado di esprimere e sull’uso degli
URI attraverso i quali è possibile stabilire dei link tra le varie entità, sfruttando il
valore del predicato per integrare informazioni che hanno origini diverse.
Ciò che dunque occorre sottolineare riguarda l’effettivo information gain ottenuto mappando RDB su RDF, che permette di aggiungere alle relazioni esplicite
presenti nel primo le relazioni implicite, collocate all’interno di uno specifico dominio semantico, che caratterizzano il secondo. Alcune applicazioni sono in grado
di effettuare un mapping automatico, sfruttando tre assunti principali:
• un record RDB è un nodo-soggetto RDF;
• il nome della colonna di una tabella RDB definisce il predicato;
• la cella di una tabella RDB definisce il valore-oggetto all’interno della tripla
RDF.
Un esempio di questo approccio è quello reso possibile da Virtuoso RDF View 16
che utilizza l’identificatore di un record (la chiave primaria) come soggetto, la colonna della tabella come predicato ed il valore presente all’interno della cella come
elemento oggetto della tripla RDF. Tuttavia, come osservato all’interno del lavoro
dal titolo A Survey of Current Approaches for Mapping of Relational Databases to
RDF [17], il mapping generato in maniera automatica non è in grado di catturare
il dominio semantico complessivo necessario a gran parte delle SW applications. Un
secondo approccio riguarda perciò l’utilizzo di espliciti contesti semantici, modellati
attraverso un’ontologia, incorporando ciò che gli RDB schema non esprimono o non
sono in grado di catturare. Inoltre, questo genere di mapping è in grado di ridurre
la creazione delle triple irrilevanti o ridondanti all’interno del dominio di conoscenza
specifico. Il dominio ontologico può essere preesistente e prelevato, ad esempio, da
un repository pubblico: in ambito biomedico, una risorsa fondamentale è rappresentata dal National Center for Biomedical Ontologies17 (NCBO). Oppure, è possibile
sfruttare ontologie locali create attraverso tools di mapping automatico.
16
17
http://virtuoso.openlinksw.com/whitepapers/relational%20rdf%20views%20mapping.htm
http://bioportal.bioonyology.org
12
2.3 – OWL e rappresentazione della conoscenza
2.3
OWL e rappresentazione della conoscenza
Oltre alla necessità di un framework per poter descrivere e interconnettere tra loro
le risorse, è necessario definire dei meccanismi che consentano ai dati di veicolare
una certa semantica. RDF fornisce soltanto un modello per la rappresentazione delle
risorse: occorrono dunque degli strumenti (linguaggi) che provvedano in primo luogo
a definire schemi specifici per i metadati e vocabolari per identificare le tipologie delle
risorse, ed in secondo luogo introducano elementi di logica che favoriscano operazioni
di ragionamento automatico.
2.3.1
RDF Schema
Il primo passo per la definizione di un linguaggio ontologico in grado di veicolare
informazioni relative alle caratteristiche degli elementi (soggetto, predicato, oggetto)
di un enunciato è rappresentato da RDF Schema (RDFS). Esso fornisce i costrutti per descrivere vocabolari in grado di categorizzare i tipi di risorse, collocandoli
all’interno di specifici raggruppamenti. In accordo con quanto accade nell’universo Object Oriented Programming (OOP), la tipizzazione viene definita classe e in
RDFS è rappresentata dalla risorsa rdfs:Class. Le risorse che hanno per tipo una
specifica classe si dicono istanze di quella classe. Facendo riferimento ancora una
volta al modello OOP, le classi definiscono determinati attributi che nelle istanze
assumono specifici valori, i quali definiscono lo stato dell’istanza stessa. Nello specifico, l’istanza delinea l’entità che, all’interno del dominio di conoscenza, rappresenta
il riferimento concettuale direttamente collegato al dato esistente. Nel caso in cui,
ad esempio, all’interno di un’ontologia che rappresenta i beni culturali della Regione
Piemonte vi sia un’istanza di tipo ‘Palazzo Carignano’, essa costituisce il riferimento
diretto al dato presente sul DB. Tuttavia, lo sviluppo di una corretta concettualizzazione è affidata all’ontology designer, che con l’ausilio di strumenti automatici18
ha il compito di mettere a punto un’ontologia adeguata.
Utilizzando la sintassi N319 , che rappresenta un’alternativa compatta e leggibile
a RDF/XML per esprimere gli enunciati RDF, è possibile dichiarare che ad esempio
Madame Bovary è un’istanza della classe libro:
18
19
ex:Book
rdf:type
rdfs:Class
ex:MadameBovary
rdf:type
ex:Book
Vedi paragrafo Mapping di RDB su RDF
http://www.w3.org/DesignIssues/Notation3
13
2 – Semantic Web
La definizione di classi RDFS consente inoltre di esprime relazioni di ereditarietà
tra le classi. Il linguaggio offre infatti anche la proprietà rdfs:subClassOf, che lega
una classe ad un’altra che ne rappresenta un sottoinsieme. Tornando al caso dei
libri, posso definire che la classe romanzo è una sottoclasse della classe libro:
ex:Novel
rdfs:subClassOf
ex:Book
Strutture di questo genere suggeriscono dunque che RDFS non delinea soltanto
una convenzione sull’uso di un certo numero di costrutti, ma veicola anche una parte
della semantica riguardante tali espressioni, che può essere sfruttata per inferire nuova conoscenza. Nel caso degli esempi precedenti, è possibile dedurre che qualunque
istanza della classe romanzo, in virtù della transitività di rdfs:subClassOf, è anche
istanza della classe libro:
ex:Novel
rdfs:subClassOf
ex:Book
ex:HeartOfDarkness
rdfs:type
ex:Novel
A partire da questi due costrutti, un motore in grado di compiere delle deduzioni
a partire da RDFS, può inferire in automatico che:
ex:HeartOfDarkness
rdfs:type
ex:Book
RDFS fornisce inoltre anche dei meccanismi per poter specificare che una determinata proprietà può essere applicata soltanto a un certo tipo di risorsa, oppure può
assumere unicamente valori predeterminati: rdfs:domain specifica che una data proprietà contempla soltanto uno specifico soggetto, mentre invece rdfs:range definisce
l’insieme di valori che a quella stessa proprietà possono essere associati:
ex:hasWriter
rdfs:domain
ex:Book
ex:hasWriter
rdfs:range
ex:Writer
Oltre a questi aspetti, RDFS è in grado di arricchire anche le proprietà RDF,
14
2.3 – OWL e rappresentazione della conoscenza
offrendo il costrutto subPropertyOf :
ex:hasWriter
rdfs:subPropertyOf
dc:Creator
ex:hasComposer
rdfs:subPropertyOf
dc:Creator
In tal caso, per quanto scrittori e musicisti si occupino di realizzare opere completamente diverse, il loro ruolo può essere ricondotto alla proprietà dc:Creator del
Dublin Core.
2.3.2
Web Ontology Language
Sebbene RDF Schema possieda strumenti efficaci per poter definire schemi e vocabolari basati su RDF, è anche vero che estraendo elementi provenienti dalla logica
nel suo complesso, o anche soltanto dalla First Order Logic (FOL), esistono notevoli
opportunità per arricchire un linguaggio ontologico e supportarlo con regole che realizzino le condizioni perché siano applicabili operazioni di ragionamento automatico.
Nella logica matematica il linguaggio del primo ordine è un linguaggio formale che
serve per gestire meccanicamente enunciati e ragionamenti che coinvolgono i connettivi logici, le relazioni e i quantificatori. La locuzione “del primo ordine” indica
che esiste un insieme di riferimento ed i quantificatori possono riguardare soltanto
gli elementi di tale insieme e non i suoi sottoinsiemi. Per questi motivi, se attraverso
la logica del primo ordine si può affermare che per tutti gli x elementi dell’insieme
vale P(x), non si può affermare altrettanto che per tutti i sottoinsiemi A valga P(A).
In base a queste sue caratteristiche, per quanto FOL sia un ottimo strumento per
la rappresentazione della conoscenza, è caratterizzato da elementi di intrattabilità
e semi-decidibilità che non lo rendono adeguato come linguaggio ontologico puro.
Per questa ragione, la scelta è stata quella di introdurre in RDFS alcune parti di
FOL necessarie per poter ampliare le caratteristiche di espressività del linguaggio,
senza tuttavia venir meno agli elementi di decidibilità e trattabilità: il risultato di
questa combinazione è confluito in OWL, il Web Ontology Language. OWL è in
grado di fornire dei costrutti che possono essere utilizzati per descrivere le classi e le
istanze (o individui) inerenti ai documenti e alle applicazioni presenti sul Web. Nello
specifico, attraverso l’uso di OWL è possibile formalizzare uno specifico dominio di
conoscenza attraverso cui definire le classi e le proprietà appartenenti a tali classi,
descrivere gli individui ed asserire le relazioni che intercorrono tra di essi, e ragionare
infine su tali classi ed individui nella misura consentita dalla semantica formale del
linguaggio OWL.
15
2 – Semantic Web
2.3.3
Perché usare OWL
Visti i diversi formalismi esistenti per rappresentare la conoscenza, è necessario soffermarsi sui punti di forza di OWL per la realizzazione di applicazioni per il SW.
Innanzitutto, per poter dare un significato esplicito alle informazioni ed integrare
i dati presenti sul Web, risulterà necessario ricorrere ad XML per definire schemi
di tagging personalizzabili e all’approccio flessibile di RDF per la rappresentazione
dei dati. Al di sopra di XML ed RDF occorre un linguaggio ontologico che possa
descrivere formalmente il significato della terminologia utilizzata nei documenti collocati sul Web. Se le macchine sono chiamate a svolgere compiti di ragionamento
utili e complessi su tali documenti, il linguaggio utilizzato deve andare oltre la semantica di base di RDFS. OWL è stato dunque progettato per rispondere a questa
esigenza. Al fine di chiarire il grado di espressività che esso introduce, può essere
utile risalire lungo lo stack del Semantic Web (Figura 2.1), ed analizzare che cosa
stabilisce concretamente ciascun linguaggio o formalismo:
• XML fornisce una sintassi di superficie per documenti strutturati, ma non
impone vincoli semantici sul significato di questi documenti;
• XML Schema è un linguaggio utilizzato per limitare la struttura dei documenti
XML ed estendere il formalismo attraverso i datatype;
• RDF è un data model per descrivere gli oggetti (o risorse) e le relazioni che li
legano, introducendo un primo livello di semantica;
• RDF Schema è un vocabolario per descrivere le proprietà e le classi delle
risorse RDF, con una semantica in grado di compiere una generalizzazione
delle gerarchie di cui fanno parte tali proprietà e classi;
• OWL aggiunge un ulteriore vocabolario per descrivere con maggiore raffinatezza proprietà e classi. In particolare, consente di specificare le relazioni tra classi
(ad esempio la disgiunzione), la cardinalità (ad esempio uno ed esattamente
uno), l’uguaglianza, una tipizzazione più ricca delle proprietà, classi enumerate
ed aggiunge caratteristiche alle proprietà quali ad esempio la simmetria.
2.3.4
I sottolinguaggi di OWL
OWL fornisce tre sottolinguaggi che si differenziano per la propria capacità espressiva, progettati per essere utilizzati da comunità di utenti e sviluppatori con esigenze
differenti:
• OWL Lite supporta tutti coloro che necessitano di una gerarchia di classificazione e di vincoli “semplici”: nel caso del vincolo di cardinalità, ad esempio,
16
2.3 – OWL e rappresentazione della conoscenza
i valori ammessi sono soltanto 0 e 1. Il basso grado di espressività consente
inoltre una migrazione piuttosto semplice di tassonomie e tesauri verso OWL
Lite;
• OWL DL (Description Logic) supporta quegli utenti che vogliono ottenere
un alto livello di espressività, mantenendo completezza computazionale (le
conclusioni sono studiate in maniera tale da poter essere sempre computabili)
e decidibilità (tutte le computazioni terminano in un tempo finito). OWL DL
comprende tutti i costrutti previsti dal Web Ontology Language, che tuttavia
sono vincolati da alcune restrizioni (ad esempio, mentre una classe può essere
una sottoclasse di più classi, non può essere istanza di alcuna classe). La
Description Logic che inizia a subentrare a partire da questa versione di OWL
costituisce il campo di ricerca nel quale sono state affrontate le logiche che
caratterizzano il fondamento formale del linguaggio;
• OWL Full è destinato a tutti gli utenti che desiderano la massima libertà
espressiva, in aggiunta alla libertà sintattica di RDF, senza alcuna garanzia
computazionale. In OWL Full una classe può essere trattata allo stesso tempo come una collezione di individui, oppure come un individuo a se stante.
Attraverso queste elementi, l’ontologia costruita in OWL Full è in grado di
aumentare il significato predefinito da RDF ed OWL. Ad oggi, non esiste un
applicativo in grado di sostenere un ragionamento completo per ogni caratteristica di OWL Full.
Ognuno di questi dialetti accresce l’espressività del suo predecessore, sia per
ciò che può essere validamente espresso, sia per quello che può essere validamente
concluso. OWL Full può essere visto come un’estensione di RDF, mentre OWL Lite
e OWL DL possono essere considerati come un’estensione di una visione limitata di
RDF. Per questi motivi, nel compiere una migrazione da RDF ad OWL Lite o OWL
DL, occorre tener conto di alcune precauzioni che garantiscano che il documento
originale sia conforme ai vincoli che vengono imposti dalle versioni meno espressive di
OWL. Alcuni di questi vincoli riguardano, ad esempio, il fatto che gli URI utilizzati
come nome di una classe devono essere esplicitati come owl:Class (e in maniera
analoga anche le proprietà); ogni individuo (o istanza) deve appartenere ad almeno
una classe; gli URI utilizzati per le classi, le proprietà e gli individui devono essere
reciprocamente disgiunti.
2.3.5
Costrutti fondamentali
Osservando le caratteristiche peculiari di OWL, è possibile comprendere in che modo l’espressività sia cresciuta rispetto ad RDF Schema. Come già anticipato nei
paragrafi precedenti, in OWL è possibile caratterizzare in maniera molto più ricca
17
2 – Semantic Web
le proprietà. Infatti, è possibile definire una proprietà come transitiva o simmetrica,
oppure stabilire la proprietà inversa di una data proprietà:
• transitiva: nel momento in cui una prima risorsa è collegata ad una seconda
attraverso una specifica relazione e se la seconda risorsa è legata ad una terza
dalla medesima relazione, si può affermare che anche la prima risorsa è collegata con la terza da quella relazione. La proprietà “essere precedente a” è un
esempio di proprietà transitiva:
ex:comesBefore
rdf:type
owl:TransitiveProperty
• simmetrica: tale condizione si verifica quando la relazione sussiste in entrambi i versi. Il legame di parentela, ad esempio, è considerato una proprietà
simmetrica:
ex:isRelativeOf
rdf:type
owl:SymmetricProperty
• inversa: qualora una proprietà non fosse simmetrica, è possibile comunque
definirne la proprietà inversa. In questo modo, dato un enunciato che lega
due risorse attraverso una determinata proprietà, è possibile inferire un altro
enunciato ottenibile scambiando reciprocamente il soggetto con l’oggetto, utilizzando come predicato la proprietà inversa. Ad esempio, “è autore di” è la
proprietà inversa di “ha per autore”:
ex:isAuthorOf
owl:inverseOf
ex:hasAuthor
Come detto nel paragrafo precedente, RDFS attraverso meccanismi come domain e range introduce delle limitazioni sull’uso delle proprietà. L’impiego di tali
costrutti è molto semplice e tuttavia impone un utilizzo delle proprietà molto limitato. Consideriamo ad esempio la formulazione “è autore di” e poniamo il caso che
possa essere utilizzata sia nel caso di scrittori che di pittori. Stabiliamo inoltre che
se il soggetto della proprietà che abbiamo definito è uno scrittore, allora l’oggetto
dell’enunciato potrà essere soltanto un libro; nel caso in cui invece il soggetto sia un
pittore, l’oggetto dovrà essere un dipinto. Attraverso gli strumenti forniti da RDFS,
saremmo costretti a definire per ogni caso una diversa proprietà. Per ovviare a
questo problema, OWL introduce le cosiddette restrizioni. Una owl:Restriction è
la definizione di una particolare classe di cui si definisce il comportamento in relazione a una o più proprietà (owl:Property): con questo stratagemma è possibile
stabilire limitazioni sulla cardinalità (in tal caso i costrutti a cui si fa riferimento sono owl:minCardinality, owl:maxCardinality, owl:cardinality), oppure sui valori
18
2.4 – Ontologie
che può assumere (owl:allValuesFrom e owl:someValuesFrom). A partire da questi
presupposti, possiamo scrivere:
ex:Writer
rdfs:subClassOf
ex:WriterAuthorRestriction.
ex:WriterAuthorRestriction
rdf:type
owl:Restriction;
owl:onProperty
ex:isAuthorOf;
owl:allValuesFrom
ex:Book.
ex:painter
rdfs:subClassOf
ex:painterAuthorRestriction.
ex:painterAuthorRestriction
rdf:type
owl:Restriction;
owl:onProperty
ex:isAuthorOf;
owl:allValuesFrom
ex:picture.
In questo caso abbiamo dunque utilizzato la medesima proprietà ex:isAuthorOf
applicata in maniera corretta ad ambiti differenti.
2.4
Ontologie
Nella concezione tradizionale, le ontologie contengono le specifiche dei concetti che
sono necessari per comprendere un determinato dominio di conoscenza. Entrando
nel dettaglio, esse introducono il vocabolario indispensabile alla descrizione di tale
dominio: definiscono le relazioni che intercorrono tra i concetti espressi e tale vocabolario, stabilendo inoltre il modo in cui devono essere definite le proprietà che
contraddistinguono classi ed individui, in relazione al medesimo vocabolario. Un’ontologia può essere formale, oppure informale. Un uso formale del linguaggio consente
alla macchina di intraprendere un ragionamento più profondo sulle risorse Web, tuttavia lo svantaggio principale riguarda il fatto che tali formalismi sono percepiti in
molti casi come difficili da rispettare.
I dati possono essere mappati su un’ontologia. Il loro uso è dunque destinato
a mettere ordine tra le informazioni espresse secondo formati eterogenei (proprio
perché l’ontologia stessa non tiene conto del formato, ma definisce soltanto il dominio
entro il quale sono collocate tali informazioni) e, per questi motivi, contribuisce in
modo determinante all’ideale del Web come fonte di sapere unica. In un certo senso,
19
2 – Semantic Web
un’ontologia è riconducibile a un database schema 20 , con le differenze sostanziali
che un’ontologia è scritta con un linguaggio relativamente ricco ed espressivo, è
caratterizzata da un’informazione meno strutturata e fornisce una teoria di dominio.
Alcuni studi, tuttavia, paventano il rischio che un focus troppo ristretto sulle
ontologie potrebbe indurre a postulare, per il Web del futuro, dei formalismi che
rischiano di privilegiare soltanto un certo tipo di classificazione nell’ambito della
comprensione del linguaggio umano [12]. Esistono a tal proposito due problemi
distinti e opposti. In primo luogo, il tipo di ontologie che viene sfruttato a livello industriale consiste di semplici tassonomie il cui compito principale è quello di
fornire un sistema di classificazione per documenti e pagine web che non debbono
essere elaborati e non necessitano di formalismi altamente espressivi. Al contrario,
qualora sia necessario catturare tutta la conoscenza spesso arbitraria di uno specifico
dominio, risulta difficile definire un unico formalismo adeguato. Oltre alla Description Logic su cui si fonda OWL, infatti, si possono sfruttare altri tipi di logica come
ad esempio quella causale, temporale e probabilistica.
Malgrado le numerose possibilità che si manifestano in questo ambito, per poter
comprendere a fondo l’insostituibilità, almeno per ora, delle ontologie all’interno del
SW è necessario sottolineare un aspetto fondamentale. Il Web viene spesso concepito con un ambiente statico, mentre invece risulta essere in continuo cambiamento
ed è caratterizzato da una semantica dinamica che rispecchia le attività che si svolgono quotidianamente in rete. All’interno di alcuni studi [11] si argomenta tuttavia
che la visione del SW deve sottendere da un lato una semantica “dichiarativa”, sulla base della quale avremmo a che fare soprattutto con dati passivi recuperati dal
server, e dall’altro un insieme di cambiamenti molto lenti, in cui la pubblicazione
di contenuti risulta molto meno frequente rispetto ad azioni legate alla navigazione
sul Web. D’altro canto, anche il contesto nel quale vengono recuperate le informazioni, come ad esempio il profilo dell’utente, la collocazione all’interno di uno
specifico pattern di navigazione e i consueti processi di editing che avvengono sul
Web possono determinare la creazione di differenti edizioni di una pagina. Perciò,
occorre evitare di focalizzarsi sull’idea secondo la quale il SW deve essere inteso
come un singolo sistema globale, caratterizzato da uno specifico modo di interagire
e da un insieme definito di requisiti che forzino la conoscenza in un’unica forma.
Come già osservato nel paragrafo dedicato a RDF, i dati che devono essere valorizzati sono soprattutto quelli relazionali. L’obiettivo, all’interno di questo contesto,
riguarda perciò la generazione di valore a partire da questi dati in aggiunta a quello che già posseggono, permettendo operazioni di inferenza e consentendo, secondo
quanto descritto da un’ontologia, di collegare i dati tra loro. Per questi motivi,
il paradigma del SW non si fonda sul fatto che tutti i dati o l’intera conoscenza
debbano essere rappresentabili attraverso un ristretto insieme di formalismi, ma si
20
http://en.wikipedia.org/wiki/Database schema
20
2.5 – Ricchezza semantica dei dati
focalizza sulle potenzialità che possono essere espresse grazie all’interrelazione e alla
combinazione di questi dati. Poiché dunque questo è ciò che si propone di realizzare
il SW, l’ontologia risulta ad oggi essere lo strumento più adeguato per consentire
una comprensione dei dati che provengono da sorgenti differenti, a patto che siano
pertinenti ed appropriati per lo scopo che s’intende conseguire.
2.5
Ricchezza semantica dei dati
Uno dei problemi fondamentali che contraddistingue un ambiente complesso come
il Web consiste nella capacità di estrarre dati in maniera automatica da contenuti
ricchi di informazioni. Nel caso delle risorse multimediali, ad esempio, i motori di
ricerca attuali basano le proprie ricerche sui riferimenti testuali, spesso parziali e non
sempre affidabili, che nella maggior parte dei casi accompagnano video, musiche ed
immagini. Il cosiddetto gap semantico21 tra i metadati estratti e il contenuto non
testuale della risorsa resta dunque, nell’ambito dell’information retrieving, una delle
lacune più difficili da colmare.
Benché contenuti testuali e multimediali presentino problemi analoghi quando
si tratta di questioni riguardanti la navigazione attraverso repository diversi , una
ricerca keyword-based non è in grado di restituire in maniera accurata e precisa
elementi che fanno parte di un contesto multimediale. L’approccio utilizzato da
Google Images, che si fonda sulle informazioni testuali collegate direttamente alla
risorsa, permette una ricerca molto veloce, grazie a cui l’utente riesce a trovare con
buona approssimazione ciò che desidera. D’altra parte, è necessario ricordare che
i risultati restituiti sono quelli che il motore ritiene più plausibili e non quelli di
cui l’utente è effettivamente alla ricerca. Per questi motivi, l’intervento umano22
all’interno del processo di collegamento tra il linguaggio visivo e quello basato sul
testo per il reperimento delle informazioni rimane essenziale [14], benché siano in fase
di sviluppo tecniche automatiche per l’associazione di strutture di natura testuale a
collezioni di immagini all’interno di specifici domini di conoscenza [1].
Nel momento in cui il fattore discriminante è rappresentato dalla correttezza
delle informazioni trovate piuttosto che dall’abbondanza dei risultati ottenuti, un
approccio interessante consiste nell’utilizzo di un’ontologia costruita su uno specifico
campo del sapere che permetta di accedere con precisione alle informazioni di cui
21
Con l’espressione semantic gap s’intende la differenza che esiste tra due descrizioni di un medesimo oggetto, espresse in due linguaggi distinti. In informatica, il problema si manifesta quando
ordinarie attività del mondo reale devono essere tradotte in una rappresentazione computazionale.
Per approfondire: http://en.wikipedia.org/wiki/Semantic gap
22
In specifici contesti, alcuni prototipi come VLEMA (Vision-Language intEgration MechAnism)
sono in grado di supportare il “lavoro umano”, generando descrizioni in linguaggio umano a partire
da scene visive che raffigurano gli interni di un edificio. Per approfondire vedi nota [14] p.4 in
bibliografia.
21
2 – Semantic Web
l’utente è alla ricerca. L’approccio utilizzato da LDI consente all’utente di raggiungere i dati che maggiormente gli interessano sfruttando tale principio e fornendo una
struttura concettuale navigabile che conduce alla risorsa desiderata. Sull’ontologia
di partenza, che descrive il dominio di conoscenza a cui gli elementi del datasource
sono riconducibili, potrebbe essere mappata un’ontologia contenente concetti di basso livello (colore dominante, intensità della luce, ecc.) [15] come i descrittori visuali presenti nello standard di codifica MPEG-7 espressi in formato RDF. A questi
dovrebbero aggiungersi ontologie, anch’esse costruite a partire da MPEG-7, che forniscano una descrizione (scheme) del contenuto multimediale; infine occorrerebbe
una core ontology 23 che possa fungere da ponte tra le descrizioni di basso e quelle
di alto livello.
23
La cosiddetta core ontology modella delle primitive concettuali che possono essere sfruttate
dalle varie ontologie che fanno parte dell’architettura. Per approfondire, vedi [18] p.2
22
Capitolo 3
Linked Data
Il World Wide Web ha modificato radicalmente il nostro modo di condividere la
conoscenza, contribuendo alla creazione delle condizioni necessarie per la pubblicazione e l’accesso a documenti collocati in uno spazio d’informazione globale. Se
da un lato i collegamenti ipertestuali consentono di percorrere questo enorme spazio,
d’altro canto i motori di ricerca sono in grado di indicizzare i documenti e analizzare
i collegamenti esistenti tra di essi, provando a inferire i risultati di maggiore rilevanza per le query di ricerca degli utenti. Indubbiamente, la natura generica, aperta ed
estensibile del Web ha costituito la base per una crescita incondizionata del sistema
e per lo sviluppo di strumenti in continua evoluzione atti ad esplorarlo.
3.1
Che cosa sono i Linked Data?
Il principio di condivisione che ha contraddistinto la pubblicazione dei documenti
sul Web, malgrado i benefici citati poc’anzi, non ha ancora trovato una compiuta
applicazione nel contesto dei dati. Tradizionalmente, essi vengono diffusi in maniera
disordinata e caotica, con scarse possibilità d’integrazione. I formati di maggiore
utilizzo vanno dal CSV (Comma-Separated Value) all’XML (eXtensible Markup Language), passando per la marcatura attraverso tabelle HTML, che sacrificano gran
parte della struttura e della semantica dei dati. In un ambiente di questo tipo,
l’ipertesto convenzionale definisce soltanto un legame implicito, la cui natura non è
sufficientemente espressiva da consentire una relazione tra le varie entità presenti in
un documento con le altre entità, presenti in documenti diversi, che alle prime sono
correlate.
Tuttavia, negli ultimi anni il Web si è evoluto da spazio di informazione globale
costituito da documenti collegati, verso un sistema nel quale sia i dati che gli stessi
documenti risultano interconnessi tra di loro. Alla base di questa evoluzione vi è
un insieme di best practices per la pubblicazione e la connessione di dati strutturati
23
3 – Linked Data
sul Web noto come Linked Data1 . L’adozione di queste pratiche ha determinato
la creazione di uno spazio globale parallelo a quello che raccoglie i documenti, nel
quale dati provenienti da domini di conoscenza diversi sono collegati tra di loro, il
cosiddetto Web of Data. Quest’ultimo consente nuovi tipi di applicazione: esistono
i Linked Data browsers che permettono la navigazione all’interno di datasource differenti, oppure motori di ricerca che sono in grado di scansionare il Web of Data ed
offrire la possibilità di strutturare delle query del tutto simili a quelle per esplorare
database locali. Si aprono inoltre nuove possibilità all’interno di uno specifico dominio. A differenza delle cosiddette Mash-up che sfruttano un insieme fisso e statico
di sorgenti di dati, le applicazioni Linked Data operano sull’interno spazio di dati e
sono in grado di rispondere alle esigenze dell’utente in maniera sempre più completa
ed efficiente a mano mano che nuove fonti di dati compaiono sulla rete.
3.1.1
Linee guida
Affinché i dati possano essere pubblicati2 e riutilizzabili, occorre che venga definito
un insieme di regole che ne favorisca l’interoperabilità. Nel 2006 Tim Berners-Lee
[3] propose alcune linee guida per fare in modo che i dati entrassero a far parte di
uno spazio globale complesso:
• l’utilizzo di URI per l’identificazione delle risorse;
• l’utilizzo del protocollo HTTP per permettere di attraversare e consultare
queste risorse;
• la necessità di sfruttare standard come RDF e SPARQL per esplorare un URI
e reperire informazioni utili;
• la creazione di collegamenti tra i vari URI al fine di scoprire nuove risorse.
Tuttavia, in una presentazione tenuta nel 2009 all’interno del ciclo di conferenze
TED3 lo stesso Berners-Lee rivisita e sintetizza i principi del Linked Data all’interno
di tre regole di base4 :
• ogni risorsa riconducibile a un oggetto del mondo reale è contraddistinto da
un identificativo che comincia con HTTP;
1
Il paper intitolato Linked Data - The Story So Far [6] evidenzia lo stato dell’arte dei Linked
Data ed ha fornito gli spunti principali per lo sviluppo di questo capitolo
2
Vedi paragrafo ‘Pubblicare Linked Data sul Web’
3
http://www.ted.com/talks/tim berners lee on the next web.html
4
http://en.wikipedia.org/wiki/Linked Data
24
3.2 – Tecnologie del Linked Data
• lo scopo principale per il quale vengono utilizzati i Linked Data è quello di ottenere informazioni. Per questi motivi, i dati devono essere espressi in formato
standard, affinché possano essere utili e riutilizzabili dagli utenti;
• l’informazione da ottenere non è legata, ad esempio al peso, all’altezza o alla
data di nascita di una persona, ma riguarda l’insieme di relazioni che essa ha
instaurato con tutti gli altri elementi del mondo reale. Inoltre, nel momento in
cui tali relazioni vengono definite e dichiarate in maniera esplicita, alle risorse
(o oggetti) collocate tra queste relazioni va attribuito un identificativo che
comincia con HTTP.
Anche all’interno delle nuove linee guida è menzionata la necessità di formati
standard, pur senza esplicitare formati specifici quali RDF/XML, segno che gli elementi di apertura e condivisione dei Linked Data si ripercuotono anche in ambito
tecnologico.
3.2
Tecnologie del Linked Data
Il principio del Linked Data si basa su due tecnologie che sono fondamentali per il
Web: lo Uniform Resources Identifier (URI) e l’HyperText Trasfer Protocol (HTTP).
Mentre i cosiddetti Uniform Resource Locator (URL) sono molto familiari agli utenti, poiché rappresentano gli indirizzi ai quali è possibile reperire documenti ed entità
di altro genere situati sul Web, gli URI forniscono un mezzo più generico per poter
identificare qualsiasi entità riconducibile ad oggetti presenti nel mondo reale. Qualora inoltre le risorse identificate da URI utilizzino uno scheme http:// 5 , è possibile
accedervi dereferenziando l’URI tramite il protocollo HTTP. In questo modo, si
sfrutta un meccanismo semplice ma universale per il recupero delle risorse serializzato come un flusso di byte (l’immagine di un gatto), oppure della descrizione di
entità che di per sé non potrebbe essere veicolata attraverso la rete (il gatto stesso).
Ad URI e HTTP si aggiunge una tecnologia fondamentale per la realizzazione
del Web of Data, ovvero RDF. Mentre HTML fornisce un insieme di strumenti
per poter organizzare la struttura di un documento e consente la creazione di link,
RDF è costituito da un generico modello di dati basato su grafi, le cui strutture di
collegamento sono in grado di descrivere relazioni riconducibili a quelle esistenti nel
mondo reale.
L’RDF Vocabulary Definition Language e il Web Ontology Language definiscono
inoltre una base di partenza per la creazione di vocabolari che possono essere usati
per descrivere le entità del mondo reale cosı̀ come sono correlate. I vocabolari sono
collezioni di classi e proprietà, anch’essi pubblicati in RDF, che mutuano termini da
5
http://en.wikipedia.org/wiki/URI scheme
25
3 – Linked Data
RDFS e OWL, prevedendo diversi gradi di espressività nella modellazione di domini
di interesse. Secondo il principio del Linked Data, chiunque è libero di pubblicare
vocabolari all’interno del Web of Data: attraverso le triple RDF è possibile collegare
le classi e le proprietà presenti in uno specifico vocabolario a quelle di un altro,
definendo una sorta di mapping tra vocabolari che possiedono elementi in comune.
In sostanza, con l’ausilio di URI per l’identificazione delle risorse, del protocollo
HTTP come meccanismo di recupero e di RDF per rappresentare le descrizioni delle
risorse, il Linked Data si basa direttamente sull’architettura generale del Web. Il
Web of Data dunque può essere visto come un livello strettamente intrecciato al
Web classico, che possiede molte delle sue proprietà:
• il Web of Data è generico e può contenere qualunque tipo di dato;
• chiunque può pubblicare sul Web of Data;
• i data publishers non sono vincolati nella scelta dei vocabolari con cui intendono diffondere i dati;
• le varie entità sono collegate tra loro da link RDF e danno vita ad un grafo di
dati globale in continua espansione, che favorisce la scoperta di nuove sorgenti
di informazioni.
Nel caso in cui si vogliano sviluppare applicazioni che fanno uso di questi dati,
occorre tener conto di alcune specifiche:
• i dati sono rigidamente separati da aspetti di formattazione e presentazione;
• i dati sono autodescrittivi: se un’applicazione in grado di “consumare” Linked
Data incontra una serie di dati descritti secondo un vocabolario sconosciuto, l’applicazione può dereferenziare gli URI che identificano i termini del
vocabolario per andare alla ricerca della loro definizione;
• l’uso di HTTP come meccanismo di comunicazione e di RDF come standard di
modellazione semplifica notevolmente l’accesso ai dati rispetto all’uso di Web
API6 che tendono ad affidarsi a data model e interfacce eterogenei;
• il Web of Data è aperto, il che significa che le applicazioni non devono essere
implementate per sorgenti di dati fisse e specifiche, ma devono essere in grado
di scoprire nuove fonti di dati seguendo i link RDF;
6
http://en.wikipedia.org/wiki/Web API
26
3.3 – Pubblicare Linked Data sul Web
3.3
Pubblicare Linked Data sul Web
La pubblicazione di dati sul Web secondo il principio del Linked Data è costituita da
una serie di pratiche che favoriscono la scoperta e l’utilizzo di questi stessi dati da
parte delle applicazioni. Per raggiungere questo obiettivo, esistono alcuni passaggi
fondamentali di cui occorre tener conto: assegnare una serie di URI alle entità
descritte dal dataset, diffondere tali URI tramite il protocollo HTTP secondo un
modello di rappresentazione RDF e definire collegamenti RDF verso altre fonti di
dati presenti sul Web, facendo in modo che i clients possano navigare all’interno del
Web of Data nel suo complesso. Di seguito, una panoramica generale su ciascuna
di queste attività.
3.3.1
URI e vocabolari RDF
I data providers possono scegliere tra due modelli di tipo HTTP URI per poter identificare le entità: 303 URIs7 e hash URI8 . Entrambi i pattern assicurano agli utenti la possibilità di distinguere tra URI che identificano le entità presenti nel mondo reale e quelli che invece identificano i documenti che descrivono
queste entità. In un ambiente aperto come il Web, fornitori di contenuti differenti pubblicano dati circa una medesima entità del mondo reale, come ad esempio
una specifica posizione geografica, oppure una celebrità: poiché è plausibile che
un provider non conosca l’altro, ciascuno di essi potrebbe introdurre URI differenti per identificare la stessa risorsa. Nel caso della città di Berlino, ad esempio, DBpedia utilizza l’URI http://dbpedia.org/resource/Berlin, mentre Geonames
http://www.geonames.org/2950159 : entrambi delineano il medesimo concetto e per
tali motivi vengono definiti alias URI. A questo proposito, non è realistico prevedere
che tutti i provider siano d’accordo sul medesimo URI per l’individuazione di un
soggetto, tuttavia a questa condizione si accompagna un vera e propria funzione
sociale, in quanto vi è la possibilità di esprimere opinioni diverse sul medesimo argomento. E’ prassi comune che i fornitori di informazioni diverse, parlando della
medesima entità, definiscano il tag owl:sameAs per collegare tra loro alias URI di
cui sono a conoscenza.
3.3.2
Generazione dei link
I link RDF consentono alle applicazioni client di navigare tra le fonti di dati per
scoprirne di ulteriori. Per poter essere parte del Web of Data, le sorgenti di informazioni collocate sulla rete dovrebbero impostare collegamenti RDF verso altri
dataset. Poiché la quantità di dati da dover trattare è molto ampia, è una pratica
7
8
http://en.wikipedia.org/wiki/HTTP 303
http://en.wikipedia.org/wiki/Dereferenceable Uniform Resource Identifier
27
3 – Linked Data
Figura 3.1. owl:sameAs - Il concetto di Berlino espresso tramite due risorse appartenenti a datasource differenti
28
3.4 – Il Linking Open Data Project
oramai assodata utilizzare strategie automatiche o semi-automatiche per generare
link RDF.
In specifici settori vengono generalmente accettati gli schemi di denominazione.
Ad esempio, nel campo della pubblicazione editoriale, esistono i codici ISBN e ISSN9 ,
in ambito finanziario vi sono identificatori quali ISIN10 , mentre EAN11 è ampiamente
utilizzato per la catalogazione di prodotti. Se il dataset di origine e quello di destinazione supportano entrambi questo schema di identificazione, la relazione implicita
esistente può essere resa esplicita attraverso RDF: un approccio di questo tipo è stato utilizzato per poter generare legami tra le varie fonti di dati presenti nella Linking
Open Data (LOD) Cloud 3.2, che raccoglie i dataset pubblicati secondo i principi del
Linked Data da parte di coloro che partecipano al progetto LOD. Qualora non vi sia
alcuno schema di denominazione condiviso, è possibile creare collegamenti RDF sulla base della somiglianza tra due o più set di dati. I costi di natura computazionale
richiesti dalla valutazione della similarità possono essere molto onerosi, a causa della
vasta mole di contenuti da analizzare, in relazione ad aspetti come il record linkage 12
e il rilevamento dei duplicati nell’ambito di database community, cosı̀ come anche
nel caso dell’ontology matching [9] nel contesto delle knowledge representation community. Un esempio di algoritmo di interconnessione automatico è rappresentato
da quello descritto nello studio intitolato Automatic Interlinking of Music Datasets
on the Semantic Web: al fine di impostare collegamenti RDF tra gli artisti presenti in Jamendo13 e MusicBrainz14 , viene utilizzata una combinazione di somiglianze
metriche15 che tiene conto del nome degli artisti, nonché dei titoli dei loro album e
canzoni16 . Altri framework per la generazione di link RDF forniscono un insieme
di linguaggi dichiarativi per specificare quali tipi di collegamenti RDF devono essere creati e quale combinazione di somiglianze metriche devono essere sfruttate per
confrontare le varie entità, conferendo una serie di punteggi che una volta aggregati
forniscono un quadro complessivo dell’effettiva somiglianza tra dataset diversi.
3.4
Il Linking Open Data Project
L’esempio più importante di adozione ed applicazione dei principi del Linked Data
è costituito dal progetto Linking Open Data17 , comunità nata nel gennaio 2007 e
9
http://www.issn.org/
http://en.wikipedia.org/wiki/International Securities Identification Number
11
http://en.wikipedia.org/wiki/European Article Number
12
http://en.wikipedia.org/wiki/Record linkage
13
http://www.jamendo.com/it/
14
http://musicbrainz.org/
15
http://en.wikipedia.org/wiki/String metric
16
Per approfondire in dettaglio il funzionamento dell’algoritmo vedi bibliografia [16] p.4
17
http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData
10
29
3 – Linked Data
sostenuta dal W3C Semantic Web Education and Outreach Group 18 . Lo scopo del
progetto è quello di fungere da catalizzatore del Web of Data, identificando set
di dati disponibili sotto licenze aperte, pubblicati in formato RDF rispettando i
fondamenti del Linked Data e, ovviamente, diffusi attraverso il Web.
Alle prime fasi del progetto hanno partecipato soprattutto ricercatori e sviluppatori appartenenti a laboratori di ricerca universitari ed aziende di piccole dimensioni. Da quel momento in poi il progetto è cresciuto notevolmente, coinvolgendo
organizzazioni di grandi dimensioni come BBC, Thompson Reuters e non ultima la
Biblioteca del Congresso. Un tale sviluppo è stato permesso dalla natura aperta del
Linking Open Data, a cui qualsiasi soggetto può contribuire semplicemente pubblicando un insieme di dati secondo le specifiche citate in precedenza: un’indicazione
dello stato attuale del progetto è fornita in figura 3.2. Ogni nodo del diagramma
rappresenta un diverso set di dati pubblicato come Linked Data.
Figura 3.2. Sezione del Linking Open Data Project Cloud Diagram. Per visualizzare l’intera cloud, visita: http://richard.cyganiak.de/2007/10/lod/
Gli archi indicano invece i collegamenti esistenti tra gli elementi nei due set di dati
18
http://www.w3.org/2001/sw/sweo/
30
3.5 – DBpedia
collegati. Archi più pesanti corrispondono inoltre a un maggior numero di relazioni
tra due insiemi, mentre archi bidirezionali indicano una connessione reciproca tra
due dataset. Il contenuto della “nube” può essere di natura diversa e comprende dati
relativi a località geografiche, pubblicazioni scientifiche, film, musica, dati statistici
ed altro ancora.
Valutare l’esatta dimensione del Web of Data rappresenta un compito molto
arduo e impegnativo a causa del fatto che i dati vengono appositamente generati da
wrapper 19 per le basi dati relazionali o le API, che devono pertanto essere sottoposti
a scansione prima di poter essere analizzati. In alternativa, è possibile compiere una
stima a partire dalle statistiche raccolte dalla comunità LOD all’interno del wiki
ESW: il Web of Data sarebbe attualmente composto da 4,7 miliardi di triple RDF
interconnesse tra di loro da circa 142 milioni di collegamenti RDF20 .
Osservando la figura 3.2 si nota come alcuni set di dati fungano da collegamento
tra i diversi hub. Ad esempio, DBpedia consiste di triple RDF estratte dalle informazioni presenti sugli articoli di Wikipedia, mentre Geonames21 e Linked Geo
Data22 forniscono descrizioni RDF di milioni di aree geografiche in tutto il mondo.
Poiché questi dataset raccolgono URI e descrizioni RDF molto comuni ad entità e
concetti di diverso genere, vengono frequentemente referenziate da set di dati più
specialistici, ed hanno quindi sviluppato il ruolo di hub a cui è collegato un numero
sempre crescente di dati.
3.5
DBpedia
Fino a una decina di anni fa, la creazione di conoscenza di base è stata appannaggio
di gruppi di scienziati impegnati all’interno di settori specifici. A partire dal 2001,
con la nascita di Wikipedia, al lavoro degli esperti si è affiancata una conoscenza
creata e mantenuta da migliaia di collaboratori provenienti da tutto il mondo, che
ha contribuito, grazie alle informazioni veicolate sotto forma di dati strutturati, a
migliorare l’intelligenza del Web.
Su queste basi, il progetto DBpedia23 sfrutta una gigantesca mole di conoscenza
estraendo informazioni strutturate da Wikipedia: il risultato consta di 2,6 milioni di
soggetti, entro cui sono compresi 198 mila persone, 328 mila luoghi, 101 mila opere
19
http://en.wikipedia.org/wiki/Wrapper %28data mining%29
Per approfondire vedi http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData
/DataSets/Statistic
21
http://www.geonames.org/ontology/
22
http://linkedgeodata.org/About
23
http://dbpedia.org/About
20
31
3 – Linked Data
musicali, 34 mila film e 20 mila imprese24 . Rispetto ad altri repository DBpedia
copre dunque una vasta gamma di domini di conoscenza e si evolve in maniera
automatica in relazione ai cambiamenti che si verificano su Wikipedia. Nella Tabella
3.1 vengono riportate le classi più comuni di DBpedia, con il numero di istanze a
cui esse fanno riferimento e alcuni esempi delle properties maggiormente utilizzate
per quelle specifiche classi.
Classi
Instanze
Esempi di properties
Person
198.056
name, birthdate, birthplace, employer, spouse
Artist
54.262
activeyears, awards, occupation, genre
Actor
26.009
academyaward, goldenglobeaward, activeyears
MusicalArtist
19.535
genre, instrument, label, voiceType
Athlete
74.832
current Team, currentPosition, currentNumber
Politician
12.874
predecessor, successor, party
Place
247.507
lat, long
Building
23.304
architect, location, openingdate, style
Airport
7.971
location, owner, IATA, lat, long
Bridge
1.420
crosses, mainspan, openingdate, length
Skyscraper
2.028
developer, engineer, height, architect, cost
PopulatedPlace
181.847
foundingdate, language, area, population
River
10.797
sourceMountain, length, mouth, maxDepth
Organisation
91.275
location, foundationdate, keyperson
Band
14.952
currentMembers, foundation, homeTown, label
Company
20.173
industry, products, netincome, revenue
Educ.Institution
21.052
dean, director, graduates, staff, students
Work
189.620
author, genre, language
Book
15.677
isbn, publisher, pages, author, mediatype
Film
34.680
director, producer, starring, budget, released
MusicalWork
101.985
runtime, artist, label, producer
Album
74.055
artist, label, genre, runtime, producer, cover
Single
24.597
album, format, releaseDate, band, runtime
Software
5.652
developer, language, platform, license
TelevisionShow
10.169
network, producer, episodenumber, theme
Tabella 3.1.
DBpedia: classi dell’ontologia, numero delle istanze, esempi di properties
Per ciascuna entità, secondo i principi del Linked Data, DBpedia definisce un
identificatore univoco globale che può essere dereferenziato. Grazie alla pluralità
24
I dati provengono dal paper intitolato DBpedia - A crystallization point for the Web of Data [7].
Lo studio ha fornito inoltre le linee guida per lo sviluppo del paragrafo ‘Struttura della conoscenza
in DBpedia’
32
3.5 – DBpedia
di informazioni di cui è caratterizzata e alle licenze open con cui i contenuti vengono distribuiti, DBpedia rappresenta uno dei nodi centrali di interconnessione del
nascente Web of Data, a cui gran parte dei content publishers fanno riferimento.
In sintesi, i contributi che il progetto DBpedia fornisce al Web of Data sono i
seguenti:
• un framework di estrazione che converte i contenuti di Wikipedia in una ricca conoscenza di base multi-dominio, costantemente aggiornata grazie alla
presenza di live feed ;
• un’ontologia costruita a partire dalla mappatura delle InfoBoxes di Wikipedia,
in grado di incrementare il valore qualitativo dei dati;
• un identificativo univoco che contraddistingue ciascuna entità, elemento essenziale per la creazione di legami con altre sorgenti presenti sul Web;
• un insieme di link di puntamento che hanno permesso lo sviluppo di una parte
importante del Web of Data attorno a DBpedia stessa.
3.5.1
Struttura della conoscenza in DBpedia
La knowledge base di DBpedia è composta da circa 274 milioni di triple RDF. Ogni
soggetto è costituito da una serie di etichette e di brevi abstract descritti in 30 lingue
diverse, 609 mila collegamenti, più di 3 milioni di link a pagine web esterne, 415
mila categorie Wikipedia e 286 mila categorie Yago.
Per gli identificatori (URI) delle singole entità vengono prelevati i nomi degli
articoli di Wikipedia in lingua inglese. Le informazioni provenienti dalle altre lingue
vengono mappate su questi stessi identificatori in maniera bidirezionale, sfruttando
i link presenti all’interno delle pagine di Wikipedia relativi alle diverse lingue in cui
il contenuto è disponibile. Alle risorse vengono dunque assegnati URI il cui pattern è caratterizzato dalla forma http://dbpedia.org/resource/Name, in cui “Name”
corrisponde alla sezione della URL dell’articolo di Wikipedia, espressa nella forma
http://en.wikipedia.org/wiki/Name. Una scelta di questo genere determina diversi
risvolti positivi:
• gli URI di DBpedia coprono una vasta gamma di argomenti enciclopedici;
• gli URI vengono definiti sulla base del consenso della comunità che contribuisce
a Wikipedia;
• esistono politiche chiare, senza ambiguità, in merito alla loro gestione;
• una descrizione chiara e in forma testuale è reperibile con facilità alla pagina
relativa di Wikipedia.
33
3 – Linked Data
Le entità presenti in DBpedia vengono collocate all’interno di quattro specifici
schemi di classificazione al fine di soddisfare esigenze applicative differenti:
• le categorie di Wikipedia, espresse in DBpedia secondo lo standard SKOS25
(Simple Knowledge Organization System), strumento che fornisce un insieme
di primitive per descrivere semplici schemi concettuali. Entrando nel dettaglio,
il suo contesto di applicazione è costituito da schemi di classificazione, tesauri,
tassonomie ed in generale vocabolari di concetti utili per la gestione e la ricerca
di informazione. Il vantaggio principale consiste nel fatto che un sistema di
classificazione di questo genere viene esteso in modo collaborativo ed aggiornato da migliaia di editori. Il principale svantaggio riguarda invece l’obsolescenza
della categorizzazione che in certi casi non rispecchia l’evoluzione dei contenuti
su Wikipedia;
• lo schema di classificazione YAGO26 , costituito da 286 mila classi che formano
una gerarchia basata sul concetto di sussunzione. Lo schema si basa sul mapping delle cosiddette leaf categories di Wikipedia, che quindi non possiedono
sottocategorie. Le principali caratteristiche di YAGO riguardano, da un lato,
la profondità con la quale si estende la gerarchia di classi che lo caratterizza
e in secondo luogo la codifica di un gran numero di informazioni all’interno di
una singola classe. A partire da tale presupposto, benché YAGO possa raggiungere un’elevata precisione, si verificano in alcuni casi errori ed omissioni a
causa della generazione automatica delle classi;
• l’ontologia UMBEL27 (Upper Mapping and Binding Exchange Layer ) sviluppata per l’interconnessione di dati e contenuti Web. Essa deriva da OpenCyc28
e comprende 20 mila classi. UMBEL è progettata per agire da riferimento
per il collegamento e la mappatura di contenuti esterni, costituendo un ponte
tra dataset differenti. Poiché sia YAGO che UMBEL sfruttano le synset 29 di
WordNet30 , è possibile creare un mapping delle classi OpenCyc su DBpedia,
attraverso l’uso di UMBEL;
• l’ontologia costruita a partire dalle InfoBoxes presenti all’interno dell’edizione
25
http://www.w3.org/2004/02/skos/
http://en.wikipedia.org/wiki/YAGO %28Ontology%29
27
http://www.umbel.org/
28
http://www.cyc.com/cyc/opencyc
29
All’interno di Wordnet, database semantico-lessicale per la lingua inglese, l’organizzazione del
lessico si avvale delle cosiddette ‘synset’ e del collegamento dei loro significati attraverso diversi tipi
di relazioni chiaramente definite. All’interno dei synset le differenze di significato sono numerate e
definite.
30
http://wordnet.princeton.edu/
26
34
3.5 – DBpedia
inglese di Wikipedia consiste di 170 classi che formano una gerarchia basata
anch’essa sulla sussunzione e comprende 720 properties.
Ogni entità di DBpedia è descritta da un insieme di properties generali e di properties relative alle specifiche InfoBoxes. Le prime inglobano una breve etichetta, un
abstract in inglese, un link al corrispondente articolo di Wikipedia, le coordinate
geografiche, un link ad un’immagine che raffigura il soggetto e un insieme di link a
pagine web esterne. Qualora vi fossero più versioni linguistiche, vengono aggiunti
alla descrizione l’etichetta e l’abstract della lingua specifica assieme ai collegamenti
alle diverse versioni linguistiche di Wikipedia. Le informazioni ottenute attraverso una generica estrazione di dati a partire dalle InfoBoxes è definita alla pagina http://dbpedia.org/property/namespace. Le proprietà ricavate invece attraverso
un’estrazione mapping-based sulla base dell’ontologia costruita sulle InfoBoxes sono
disponibili alla pagina http://dbpedia.org/ontology/namespace.
All’interno della Tabella 3.2 vengono mostrate le cifre relative ai dataset costruiti
grazie all’estrazione di informazioni generiche provenienti dalle Infoboxes, a quelli
derivanti dall’estrazione di tipo mapping-based e ai dataset strutturati a partire dai
collegamenti tra le pagine di Wikipedia. Nel caso di estrazione generica, si ottengono
1 milione e 462 mila risorse, mentre attraverso le ontologie se ne ottengono 843 mila.
Vi sono poi 2 milioni 853 mila 315 link tra le varie pagine di Wikipedia. Per quel
che concerne il numero di properties, i dataset generici ne utilizzano 38 mila 659,
mentre il mapping-based dataset ne contiene 720. Il dataset sviluppato sulla base
dei link sfrutta una sola property per rappresentare link non tipizzati tra le varie
pagine Wikipedia.
Extraction methods
Generic extraction
Mapping-based extraction
Pagelinks
Tabella 3.2.
Described entities
Mio. triples
Unique properties
Triples/property
Triples/entity
1.462.108
843.169
2.853.315
26,0
7,0
70,2
38.659
720
1
673,7
9722,2
70,2mio
17,81
8,34
24,61
Comparazione tra le differenti tipologie di estrazione dei dati da DBpedia
I dati di DBpedia, tratti dai contenuti pubblicati sulle pagine di Wikipedia,
forniscono un insieme di informazioni che descrivono gli aspetti peculiari di una
specifica entità. Ipotizzando che DBpedia inglobi nel suo insieme tutta la conoscenza
prodotta dall’uomo (o che ne sia potenzialmente in grado in relazione al crescere
di Wikipedia), essa può diventare un punto di riferimento per poter accrescere il
valore di uno specifico dominio descrittivo. Consideriamo, ad esempio, un’ontologia
costruita sui beni culturali appartenenti alla Regione Piemonte: con ogni probabilità
essa conterrà un’entità definita ‘Palazzo Madama’ caratterizzata da una serie di
relazioni con altre entità presenti all’interno dell’ontologia. Identificare la medesima
35
3 – Linked Data
risorsa ‘Palazzo Madama’ presente su DBpedia31 , permetterebbe di incrementare il
numero di relazioni che caratterizzano l’istanza presente nell’ontologia di partenza,
accrescendo di fatto la conoscenza che quest’ultima è in grado di esprimere. A questo
proposito, nel caso in cui sia verosimile che l’entità ‘Palazzo Madama’, collocata
all’interno dell’ontologia sui beni culturali, possegga una relazione che identifica
il suo architetto Filippo Juvarra, non si può dire altrettanto delle sue coordinate
geografiche. In tal caso, sarà possibile recuperare tali coordinate da DBpedia, che
potranno essere sfruttate per mostrare la specifica collocazione geografica.
3.6
Linked Data e Semantic Web
Come già visto nel capitolo precedente, il desiderio di estendere le capacità del Web
per la pubblicazione di dati strutturati risale ad una delle prime proposal per il
World Wide Web32 . Le tendenze auspicate in queste prime fasi riguardavano soprattutto l’evoluzione dei documenti contraddistinti da una notevole facilità di comprensione da parte degli esseri umani (human-readable), affinché potessero contenere
un insieme di informazioni manipolabili e comprensibili dalle macchine (machinereadable). Tali tendenze potrebbero essere viste come i semi che avrebbero dato
vita, in una fase successiva, a quello che divenne noto come Semantic Web.
Il concetto di SW viene interpretato in modi molto diversi. Tuttavia, malgrado
la presenza di visioni differenti, l’obiettivo iniziale di costruire un Web of Data
globale interpretabile dalle macchine resta costante in tutta la letteratura originale
di questa materia. Secondo Tim Berners-Lee il primo passo consiste nell’inserire
dati sul Web secondo una forma che le macchine sono in grado di comprendere o
riconvertire il tutto in quella forma: “Questo è ciò che intendo con SW, un insieme
di dati che possano essere trattati direttamente o indirettamente dalle macchine”.
Pertanto, mentre il SW definisce il risultato finale di questo processo, i Linked Data
forniscono i mezzi necessari per poter raggiungere tale obiettivo.
Grazie alla pubblicazione di dati secondo i precetti del Linked Data, numerosi
individui e gruppi hanno contribuito alla costruzione di un Web of Data grazie al
quale sono stati in grado di supportare il riutilizzo, l’integrazione e l’applicazione
di dati originati da fonti distribuite ed eterogenee. Nel prossimo futuro, alcune
delle proposte più sofisticate associate alla visione del SW, sfruttando come base il
principio del Linked Data, potranno diventare senza alcun dubbio una realtà.
31
Una strategia potrebbe essere quella di definire nell’ontologia la relazione owl:sameAs, di cui si
è accennato nel paragrafo URI e vocabolari RDF dichiarando in maniera esplicita l’URI presente
su DBpedia, oppure quella di sviluppare ex novo o sfruttare servizi esistenti in grado di risolvere
l’eventuale label con la quale descriviamo l’entità all’interno dell’ontologia
32
http://www.w3.org/History/1989/proposal.html
36
Parte II
Seconda Parte
Capitolo 4
Stato dell’arte
All’interno di questo capitolo si è scelto di riportare lo stato dell’arte della visualizzazione, ponendo l’attenzione su due aspetti nettamente separati: da un lato
la visualizzazione delle ontologie, considerando quell’insieme di tecniche e strategie
che vengono adottate a livello visivo per mostrare le relazioni che collegano i dati
tra loro, e dall’altro la visualizzazione stessa dei dati, in particolar modo quelli che
provengono da sorgenti differenti (pubblicati secondo le best practices del Linked Data) e convergono all’interno di una medesima interfaccia. LDI racchiude entrambe
le caratteristiche: in primo luogo consente di esplorare uno specifico dominio di
conoscenza costruito a partire dai dati collocati in un database relazionale, e dall’altro permette la visualizzazione dei dati stessi. Oltre a ciò, a partire da una risorsa
specifica è possibile arricchire i dati preesistenti sfruttando quelli provenienti da
dataset esterni, costruendo una vista opportuna in grado di visualizzarli.
4.1
Visualizzazione delle ontologie
L’uso delle ontologie, in un contesto nel quale vi sono costanti progressi nell’ambito delle tecnologie di rete e dei supporti di memorizzazione, sta assumendo un
ruolo sempre più importante. La crescente disponibilità di contenuti a disposizione
dell’utente genera infatti numerose difficoltà nel reperimento dei dati di cui è alla
ricerca. Per questi motivi, la descrizione di un dominio di conoscenza entro il quale
tali dati sono contenuti, può fornire una serie di strumenti utilizzabili dagli algoritmi di ricerca per poter individuare efficacemente, attraverso processi di inferenza,
l’informazione che risponde alle sue esigenze. Tuttavia, per la ricchezza di dettagli
che l’ontologia è in grado di veicolare e per le ragioni di natura progettuale che il
suo sviluppo richiede, è sorta parallelamente alla descrizione della conoscenza anche la necessità di visualizzarla. La visualizzazione di un’ontologia è un compito
tutt’altro che semplice per diverse ragioni: in primo luogo, essa non rappresenta
39
4 – Stato dell’arte
soltanto una gerarchia di concetti, ma definisce la natura delle relazioni esistenti tra
di essi e gli attributi associati ad ogni singolo concetto. Inoltre, ad ogni elemento
di tipo classe potrebbero appartenere da una a migliaia di istanze. Pertanto, non è
semplice generare una visualizzazione che sia in grado di mostrare in maniera efficace un gran numero di informazioni e che allo stesso tempo consenta all’utente di
eseguire con facilità tutta una serie di operazioni (come ad esempio la navigazione
tra concetti) sull’ontologia. Oltre ai sistemi studiati specificatamente per la visualizzazione delle ontologie, però, esiste un insieme di tecniche adottate in altri ambiti
che possono essere riadattate e sfruttate per questo scopo specifico. Nel paragrafo
successivo verranno dunque affrontate alcune di queste tecniche, cercando di individuare i paradigmi di visualizzazione che fino ad oggi sono stati utilizzati per rendere
in forma grafica le ontologie.
4.1.1
Tecniche di visualizzazione
I metodi di visualizzazione possono essere raggruppati in base alle caratteristiche di
presentazione, alle tecniche di interazione e alle funzionalità supportate:
• liste indentate: la maggior parte dei sistemi che oggi permettono di creare e
sviluppare ontologie tra cui Protégé1 , OntoEdit2 , Kaon3 e Ontorama4 offrono
tra le proprie funzionalità una finestra che consente di esplorare la tassonomia
(gerarchia delle classi) dell’ontologia espressa in forma di alberatura. In Figura
4.1 è rappresentata la finestra di navigazione delle classi, cosı̀ come proposta
da Protégé. Il vantaggio principale delle liste indentate riguarda da un lato la
semplicità di implementazione e di rappresentazione degli elementi grafici e in
secondo luogo la familiarità dell’utente con questo genere di visualizzazione.
Inoltre, esso propone una visione chiara delle singole classi e della loro gerarchia
in quanto le etichette presenti sui nodi non si sovrappongono le une con le
altre, evitando cosı̀ spostamenti del mouse da un elemento all’altro per mettere
in chiaro l’etichetta. Sono previsti inoltre meccanismi per l’espansione e il
collasso dei nodi, con l’obiettivo di mettere a fuoco soltanto parti specifiche
della gerarchia, in particolare per quelle di grandi dimensioni. La semplicità
dell’interfaccia consente una navigazione veloce, ragion per cui tale paradigma
viene adottato nella maggior parte dei casi come principale strumento per
l’editing delle ontologie: altrettanto facile risulta infatti l’individuazione di
classi specifiche e delle istanze appartenenti a una data classe.
1
http://protege.stanford.edu/
http://www.semtalk.com/semnet files/POntoEdit.htm
3
http://kaon.semanticweb.org/
4
http://tinyurl.com/ontorama
2
40
4.1 – Visualizzazione delle ontologie
Figura 4.1. Visualizzazione dei concetti dell’ontologia della Pizza, comunemente
proposta per spiegare gli elementi principali di un’ontologia, in Protégé
41
4 – Stato dell’arte
La scelta di una visualizzazione ad albero, tuttavia, determina una serie di
limitazioni da un punto di vista della ricchezza di informazioni che si possono
rappresentare. Le liste indentate mostrano infatti soltanto relazioni di tipo
padre/figlio e non sono in grado di evidenziare in maniera efficace anche relazioni di tipo diverso. Inoltre, casi di ereditarietà multipla non sono molto
chiari e dunque un utente che ha poca familiarità con le ontologie potrebbe
rimanere disorientato dal fatto che una medesima classe possa apparire più
volte, all’interno di sub-gerarchie differenti. Nel caso di ontologie di grandi dimensioni, inoltre, porzioni specifiche possono essere visualizzate soltanto
una alla volta, determinando da un lato una gestione degli elementi grafici
incapace di sfruttare tutto lo spazio a disposizione e dall’altro la necessità di
scorrimento manuale durante la navigazione;
• alberatura tramite nodi e link: in questa categoria sono inserite tecniche che
rappresentano le ontologie come un insieme di nodi interconnessi, in cui la
tassonomia è mostrata con un layout che si estende dall’alto verso il basso,
oppure da sinistra a destra. L’utente è generalmente in grado di sviluppare e
ritirare i nodi e le loro sotto-strutture, al fine di regolare il dettaglio delle informazioni riportate, evitando situazioni di confusione e ingombro di elementi
sullo schermo.
OntoViz5 , ad esempio, è un plug-in di visualizzazione sfruttato da Protégé
che si basa su GraphViz6 , libreria che fornisce un insieme di primitive per la
realizzazione di grafici 2D. In OntoViz le classi dell’ontologia vengono rappresentate con un’etichetta di identificazione, con le loro proprietà e con le
proprie relazioni. Le istanze vengono identificate con un diverso colore, ed è
possibile compiere operazioni per ingrandire o ridurre le dimensioni del grafo.
IsaViz7 fornisce invece un ambiente visuale per la creazione e la navigazione
di ontologie, strutturate secondo un grafo orientato (Figura 4.2). Gli elementi
grafici principali sono ellissi e rettangoli, che rappresentano rispettivamente le
classi ed i valori delle proprietà associate a tali classi, ed archi che definiscono
invece la natura di tali proprietà.
Altri strumenti come SpaceTree8 adottano alcuni accorgimenti come la creazione
di un’icona di anteprima per i rami che non possono essere completamente
aperti o la possibilità di modificare l’orientamento del grafo. TreePlus9 propone invece una metafora grazie alla quale è possibile esplorare la gerarchia a
partire da un nodo specifico, sfruttando un layout ad albero che si estende da
5
http://protegewiki.stanford.edu/wiki/OntoViz
http://www.graphviz.org/
7
http://www.w3.org/2001/11/IsaViz/
8
http://www.cs.umd.edu/hcil/spacetree/
9
http://www.cs.umd.edu/hcil/treeplus/
6
42
4.1 – Visualizzazione delle ontologie
Figura 4.2.
Visualizzazione di un’ontologia in Isaviz
43
4 – Stato dell’arte
sinistra a destra, combinato con una serie di meccanismi per l’espansione e il
collasso dei nodi.
Una rappresentazione di tipo tree definisce una struttura molto comune ed
intuitiva per le classificazioni di tipo gerarchico. Questo sistema offre una
buona panoramica delle sotto-strutture, nelle quali è possibile distinguere con
chiarezza l’estensione e la profondità della gerarchia. Malgrado ciò, i metodi
con cui nodi appartenenti a livelli diversi vengono collegati tra loro causano,
a meno di particolari accorgimenti come il lo sviluppo e il ritiro dei nodi, un
sovraffollamento di una specifica zona dello schermo, mentre la parte opposta
rischia di rimanere non adeguatamente utilizzata. Inoltre, qualora si abbia a
che fare con un gran numero di nodi, potrebbero occorrere più schermi per la
visualizzazione e degli strumenti (manuali o preferibilmente automatici) per lo
scorrimento;
• tecniche con ingrandimento: raccolgono tutti i metodi che presentano i nodi
appartenenti ai livelli inferiori della gerarchia, annidati all’interno dei propri “genitori”, con dimensioni inferiori rispetto a quest’ultimi. Tali tecniche
consentono all’utente di effettuare operazioni di zoom-in sui nodi figli per
ingrandirli, modificando il livello principale di visualizzazione.
Grokker10 , ad esempio, è un sistema per la visualizzazione di mappe concettuali. E’ stato studiato come mezzo per fornire una rappresentazione grafica di informazioni relative ai risultati provenienti da una motore di ricerca di
documenti o più in generale di file: un meccanismo di clustering è in grado di
presentare gli oggetti come una serie di diagrammi di Venn11 annidati gli uni
negli altri (vedi Figura 4.3).
Gli utenti possono navigare attraverso la gerarchia, cliccando all’interno dei
cerchi che, una volta selezionati, vengono ingranditi con una serie di animazioni. L’intensità del colore permette inoltre di separare i livelli più bassi
contraddistinti da un alto grado di opacità, da quelli più alti caratterizzati da
elevati livelli di trasparenza. Un principio simile è quello adottato dai cosiddetti cropcircles 12 , nei quali la struttura gerarchica delle classi viene mostrata
secondo un insieme di cerchi concentrici. I nodi figli vengono collocati all’interno del nodo padre e la presenza di un pannello nel quale viene presentata
la lista delle classi consente operazioni di ‘esplosione’ dei nodi per poter esplorare livelli differenti della gerarchia, con un supporto per la cronologia di
navigazione dell’utente.
10
http://library.stanford.edu/about sulair/special projects/stanford grokker.html
http://en.wikipedia.org/wiki/Venn diagram
12
http://www.mindswap.org/2005/cropcircles/
11
44
4.1 – Visualizzazione delle ontologie
Figura 4.3.
Visualizzazione dei risultati di ricerca in Grokker
45
4 – Stato dell’arte
Le interfacce di tipo zoomable sono molto efficaci per individuare nodi specifici
in quanto forniscono dimensioni diverse a seconda del livello di gerarchia di
appartenenza. Tuttavia, potrebbero essere migliorate fornendo ulteriori spunti
di navigazione che consentano all’utente di ricondurre il concetto di gerarchia a
strutture con cui ha maggiore familiarità, come le liste indentate e gli alberi. A
queste sarebbe utile aggiungere ulteriori informazioni sul livello di profondità
della gerarchia che in quel momento si sta esplorando;
• tecniche di riempimento dello spazio (o tree map): a questa categoria appartengono tutte quelle tecniche che utilizzano l’intero spazio dello schermo,
associando ad ogni area disponibile uno specifico nodo e tutti i figli che ad
esso fanno riferimento. La dimensione di ogni suddivisione corrisponde a una
proprietà del nodo, e fornisce indicazioni sull’estensione del nodo stesso in
relazione al numero di figli che possiede.
Nell’ambito delle ontologie, questo genere di visualizzazione è stato impiegato
dal Gene Ontology Consortium 13 : tale sistema sfrutta una serie di funzionalità tra le quali etichette, dimensioni differenti per identificare geni di natura
diversa. Inoltre, l’utente può compiere operazioni di zoom sui dettagli con
un doppio clic sull’area di interesse. Attraverso questo accorgimento, è possibile effettuare un’interrogazione dei dati che appartengono nello specifico alla
zona che viene visualizzata in quel momento, piuttosto che un’interrogazione
complessiva(Figura 4.4).
Una variante della classica visualizzazione a riempimento di spazio è l’approccio proposto dalle cosiddette information slices: in questa tecnica vengono utilizzati uno o più dischi circolari per definire la gerarchia, proponendo
una struttura più compatta. Ciascun disco rappresenta un livello della gerarchia, e le varie sub-divisioni sono in grado di adattarsi in relazione allo spazio
disponibile e alla numerosità con cui sono presenti (vedi Figura 4.5);
• tecniche di alterazione del grafo: questo gruppo di tecniche si basa sul presupposto di un’alterazione della vista del grafo, in grado di combinare elementi
legati al contesto di visualizzazione e alla messa a fuoco. Di solito, un nodo
specifico rappresenta l’obiettivo prioritario dell’analisi dell’utente. Il resto dei
nodi gravita attorno ad esso in dimensioni progressivamente più ridotte e a
distanze sempre più consistenti dal nodo centrale, fino a raggiungere un punto
in cui i nodi non sono più visibili. Per poter ottenere questo obiettivo, di
solito si utilizza una funzione iperbolica. Un albero costruito sfruttando tale
funzione è quello utilizzato per presentare l’ontologia del Brazilian Agricultural Research Society. La radice dell’albero si colloca inizialmente al centro di
13
http://www.cs.umd.edu/hcil/bioinfovis/treemap.shtml
46
4.1 – Visualizzazione delle ontologie
Figura 4.4.
Visualizzazione di tipo tree map
dell’ontologia del Gene Ontology Consortium
47
4 – Stato dell’arte
Figura 4.5.
Visualizzazione basata sulle information slices circolari
48
4.1 – Visualizzazione delle ontologie
una zona circolare, con i nodi figli che si dispongono attorno ad esso, e i loro
rispettivi figli a loro volta posizionati attorno ai propri nodi padre. La distanza
esistente tra nodi appartenenti allo stesso livello diminuisce progressivamente
al crescere del loro numero. A seguito della trasformazione iperbolica, tuttavia,
l’albero continua a riadattarsi secondo una forma circolare: per questi motivi,
la tecnica si basa su una serie di distorsioni con l’obiettivo di mantenere una
visualizzazione collocata entro certi limiti (vedi Figura 4.6).
Figura 4.6. Visualizzazione di una porzione dell’ontologia adottata dal Brazilian
Agricultural Research Society
BiFocal Tree propone invece una visualizzazione basata sulla focalizzazione
di uno specifico contesto concettuale, ma a differenza di altri sistemi intende
sfruttare due fuochi, anziché uno soltanto. Esso mostra una gerarchia disposta
su due diagrammi interconnessi: una focus area che ingloba la porzione di grafo
contenente il nodo di interesse e una context area che contiene il nodo padre
e le restanti sotto-zone del grafo che in quel momento non vengono prese in
considerazione (vedi figura 4.7).
49
4 – Stato dell’arte
Figura 4.7.
Visualizzazione di concetti in BiFocal Tree
50
4.1 – Visualizzazione delle ontologie
Questo genere di tecniche, caratterizzato da un insieme di espedienti combinati fra loro, presenta diversi vantaggi. Innanzitutto, un nodo di interesse
può essere collocato al centro della struttura, per poter visualizzare maggiori
particolari, mantenendo integro l’insieme dei nodi ad esso collegato. D’altra
parte, il fatto di non mantenere costante il posizionamento dei nodi, potrebbe
disorientare l’utente. Per questi motivi, benché queste tecniche siano molto
efficaci nel visualizzare un gran numero di nodi, consentendo inoltre una focalizzazione della vista su nodi specifici, non offrono una rappresentazione
evidente della struttura gerarchica, poiché spesso si verifica un ingombro dei
nodi e delle etichette ad essi associati. Quest’ultimo aspetto, unito al completo
aggiornamento della vista ogniqualvolta si esplora il grafo, può provocare delle
difficoltà all’utente nella generazione di un’astrazione mentale dell’ontologia.
4.1.2
Multidimensionalità
Ad ognuno dei paradigmi di visualizzazione presentati nel paragrafo precedente è
applicabile anche la terza dimensione. Tuttavia, la scelta di rappresentare gli elementi di un’ontologia su due o tre dimensioni è legata al device specifico che dovrà
riprodurre in forma grafica la struttura. I metodi basati su una visualizzazione
2D sfruttano l’intero piano dello schermo, tralasciando il concetto di profondità.
Gli strumenti che offrono una visualizzazione 3D14 (vedi Figura 4.8) tengono conto
della terza dimensione per creare effetti grafici riconducibili a metafore del mondo reale o per migliorare la navigazione in termini di usabilità. Malgrado ciò, una
“materializzazione” su tre dimensioni presenta alcune problematiche:
3D visualization in general requires increased system resources in
order for navigation and viewing to be smooth and without delays and,
as a result, is probably not suitable for web use. Furthermore, the 3D
methods presented here employ more complex navigation methods and
may be a little frustrating and disorienting for a novice user. [13]
Un approccio efficace consiste perciò nel riuscire ad arricchire l’esperienza con cui
l’utente si confronta in presenza delle sole due dimensioni, in modo tale che l’esplorazione del grafo possa avvenire secondo prospettive differenti (si potrebbe sfruttare
un’ibridazione delle tecniche presentate in precedenza), evitando però manipolazioni
nella terza dimensione: all’interno del lavoro intitolato Multi-View Ontology Visualization [8], ad esempio, viene presentato un sistema che permette la visualizzazione
del grafo, sfruttando strutture geometriche differenti.
14
Uno
degli
esempi
più
importanti
http://ontosphere3d.sourceforge.net/index.html
51
di
visualizzatori
3D
è
Ontosphere:
4 – Stato dell’arte
Figura 4.8.
Visualizzazione dei concetti di un’ontologia in Ontosphere
52
4.2 – Linked Data browsers
4.2
Linked Data browsers
Cosı̀ come i browser web tradizionali consentono agli utenti di navigare tra le pagine
HTML seguendo i collegamenti ipertestuali, i Linked Data browser permettono loro
di navigare tra le fonti di dati attraverso link espressi sotto forma di triple RDF. Nel
caso in cui ad esempio volessi reperire alcune informazioni sull’architetto ‘Filippo
Juvarra’, potrei andare alla ricerca su DBpedia dei palazzi di cui è stato architetto.
Scorgendo tra questi ‘Palazzo Madama’, qualora desiderassi avere maggiori informazioni per conoscere, ad esempio, quali altri edifici storici si trovano nelle sue
vicinanze, potrei collegarmi a Geonames ed accedere a questo tipo di dato. Il risultato dunque è che l’utente può cominciare ad esplorare una fonte di dati specifica e
progressivamente attraversare il Web, basandosi sulle strutture RDF, piuttosto che
sui link HTML. Esiste però un elemento fondamentale di cui occorre tener conto: da
un lato occorre considerare quegli strumenti che consentono unicamente una navigazione tra le risorse provenienti da sorgenti diverse, come ad esempio Disco, d’altro
canto bisogna tener conto di altre applicazioni, come Tabulator e in parte Sig.ma,
che hanno sviluppato delle vere e proprie viste per questi stessi dati. LDI si colloca,
per ora, tra quest’ultimi. Pur collegandosi a una sorgente esterna, l’obiettivo resta
quello di estrarre il dato dalla risorsa, costruendo una vista adeguata in grado di
valorizzarlo. Di seguito vengono riportati alcuni esempi di Linked Data browsers,
descrivendo per ciascuno le caratteristiche di maggiore rilevanza.
4.2.1
Disco
Disco15 è un semplice browser per navigare il Semantic Web come un insieme di fonti
non legate tra loro. Inizialmente, viene eseguito un rendering di tutte le informazioni
che l’applicativo è in grado di scovare su una risorsa specifica come una pagina
HTML. Con ogni probabilità, essa conterrà un insieme di collegamenti ipertestuali
che consentono di navigare tra le risorse: passando da una all’altra, il browser
recupera dinamicamente le informazioni dereferenziando URI HTTP e seguendo
collegamenti di tipo rdfs:seeAlso.
L’applicazione risulta di semplice utilizzo per l’utente. L’esplorazione comincia
con l’inserimento di un URI nella casella di navigazione. Dopo aver premuto il tasto
‘Go!’, il browser comincia a recuperare le informazioni su questa specifica risorsa
dai dataset pubblicati secondo le best practices dei Linked Data. Tali informazioni
vengono visualizzate come una tabella costituita da una prima colonna che identifica
le proprietà, una seconda che raccoglie i valori ad esse relativi ed una terza che
elenca le fonti dalle quali tali informazioni provengono. Per quest’ultime vengono
utilizzate delle abbreviazioni (G1, G2, ecc.) che in una tabella successiva consentono
15
http://www4.wiwiss.fu-berlin.de/bizer/ng4j/disco/
53
4 – Stato dell’arte
Figura 4.9.
Screenshot dell’interfaccia di Disco
54
4.2 – Linked Data browsers
di consultare le fonti di origine. Cliccando sul collegamento ipertestuale che riguarda
la descrizione delle risorsa, inoltre, il browser archivia tutti i grafi RDF recuperati
in una cache di sessione. Attraverso il link ‘Display all RDF graphs’ è possibile
visualizzare una lista di tali grafi, nonché un elenco degli URI che non sono stati
dereferenziati con successo (vedi Figura 4.9).
4.2.2
Tabulator
Tabulator [5] è uno strumento che consente l’esplorazione e l’analisi dei dati presenti sul Semantic Web. L’utente è in grado di esplorare l’abstract di una risorsa
appartenente al Web of Data. In ogni momento, cliccando su una cella di dati, è
possibile evidenziare le fonti di origine e il relativo stato. Con un un doppio click
sulla sorgente è possibile visualizzare i metadati relativi a quella specifica fonte.
Inoltre, qualora all’informazione si possa associare un URI dereferenziabile, viene
visualizzato un piccolo bottone che assume il colore blu nel caso in cui i dati non
fossero ancora accessibili, il verde nel caso di quelli recuperati, il giallo se sono in
fase di recupero e infine il rosso nel caso in cui i dati non siano stati trovati (Figura
4.10).
Figura 4.10.
Screenshot di Tabulator in modalità ‘esplorazione’
In Tabulator, la progettazione dell’interfaccia utente tiene conto di due modalità
di funzionamento: l’esplorazione e l’analisi. Se da un lato, infatti, lo spostamento
da un nodo ad un altro ci obbliga a ridefinire la nostra prossima mossa ad ogni
passo16 , occorre tener conto del fatto che la maggior parte delle data applications
come quelle per la gestione di denaro o degli appuntamenti su un calendario, obbliga
a trattare i dati in maniera ben definita e specifica per l’applicazione. Nella fase di
16
Nel caso del World Wide Web l’esplorazione di un link specifico nasce come sensazione istintiva
che consentirà di rivalutare la sensazione dopo ogni link
55
4 – Stato dell’arte
esplorazione, l’utente somministra un URI a Tabulator. A partire da esso, l’utente
è in grado di esplorare un grafo RDF, mostrato secondo una lista indentata (Figura
4.10), espandendo i vari nodi per poter ottenere maggiori informazioni. Ogni volta
che l’utente compie questa azione, Tabulator segue implicitamente una serie di link
che potrebbero contenere nodi RDF, relazionati in qualche modo ai nodi che sono
stati presi in considerazione.
Per passare alla modalità di analisi, l’utente seleziona alcuni settori per definire
un modello e chiede a Tabulator di trovare tutti gli esempi relativi a questo modello. Nella fase successiva, viene eseguita una query che tenta di ricondurre il modello
stabilito in precedenza ai collegamenti che fanno parte del grafo RDF. I risultati
ottenuti vengono visualizzati secondo un certo numero di punti di vista modulari:
tabelle, proiezioni temporali su calendari (Figura 4.12), mappe geografiche (Figura 4.11). E’ possibile ritornare nuovamente alla modalità di esplorazione su una
qualsiasi istanza presentata all’interno di tali viste.
Figura 4.11.
Visualizzazione di una mappa in Tabulator in modalità ‘analisi’
56
4.2 – Linked Data browsers
Figura 4.12.
Visualizzazione di un calendario in Tabulator in modalità ‘analisi’
57
4 – Stato dell’arte
4.2.3
Sig.ma
Sig.ma17 è un’applicazione che consente di esplorare il Web of Data. Essa permette
di sfruttare le informazioni provenienti da molteplici siti web non correlati tra loro,
che incorporano informazioni in RDF, RDFa18 o secondo Microformats19 . Sig.ma
può essere utilizzato in tre modi differenti:
• browser web di dati: a partire da una qualsiasi entità è possibile esplorarne di
nuove a partire dalla pagina risultante. E’ possibile navigare attraverso una
vera e propria ‘rete di mash-up’ che tuttavia, a causa dell’eterogeneità delle
sorgenti da cui vengono tratti i risultati, può generare del rumore. Il browser
mostra da un lato le risorse che è possibile esplorare e dall’altro presenta una
serie di viste (come nel caso delle immagini o di SlideShare nel caso si tratti
di dati relativi a una presentazione);
• widget embeddable: i risultati offerti da Sig.ma, una volta raffinati secondo le
proprie esigenze, si possono incorporare all’interno di mail, twit o blog. Si
tratta di dati che si modificano in base alle relazioni ed ai cambiamenti che
si verificano nei dataset e che dunque risultano sempre aggiornati, ovunque
vengano pubblicati;
• API semantiche: con Sig.ma è possibile recuperare le descrizioni delle entità e
delle proprietà ad esse associate in formato JSON o RDF.
L’interfaccia dei risultati presenta due aree ben distinte. Una prima area, sulla sinistra, che offre tutti i risultati con i valori delle property associate all’entità
presa in considerazione (Figura 4.13). Una seconda, posta sulla destra, permette
di osservare invece quali sono le sorgenti da cui provengono i risultati, con la possibilità da parte dell’utente di classificare tali sorgenti come ‘Approved’ (e dunque
affidabili), oppure ‘Rejected’ (o in altre parole inaffidabili o irrilevanti ai fini delle
proprie ricerche) (Figura 4.14).
17
http://sig.ma/
http://en.wikipedia.org/wiki/RDFa
19
http://microformats.org/
18
58
4.2 – Linked Data browsers
Figura 4.13.
Visualizzazione dei risultati in Sig.ma
59
4 – Stato dell’arte
Figura 4.14. Visualizzazione dell’area contenente i riferimenti alle sorgenti dei dati in Sig.ma
60
Capitolo 5
Linked Data ICONVIS
All’interno di questo capitolo viene proposta una panoramica delle tecnologie che
sono state adottate per lo sviluppo dell’applicazione, ed un’analisi profondità sulle
differenti modalità di visualizzazione che delineano i casi d’uso in cui è possibile
sfruttare le caratteristiche di LDI. Dopo una breve panoramica del back end dell’applicazione e delle tecnologie principali adottate nel front end, l’analisi si concentra
sulle tecniche sfruttate in primo luogo per la visualizzazione degli elementi che è
possibile estrarre dall’ontologia, e in seconda istanza per la visualizzazione dei dati.
5.1
Il back end dell’applicazione
La componente di back end si occupa da un lato di estrarre le informazioni presenti nell’ontologia e dall’altro di interfacciarsi con il database per poter accedere
ai dati presenti al suo interno. Esso è stato sviluppato in Java EE, la versione enterprise della piattaforma Java, che fornisce una serie di strumenti per facilitare
l’implementazione di architetture SOA1 solide e scalabili. La componente prende
in input due file: l’ontologia descritta in formato OWL e un file di configurazione
XML all’interno del quale l’amministratore di sistema definisce le specifiche query
(per classi o istanze) che occorrono per poter interrogare il DB. Prima di effettuare
il build dell’applicazione con Apache Ant2 , è necessario specificare all’interno di un
file di properties il path in cui sono contenuti l’ontologia e il file XML. Per il deploy
dell’applicazione viene utilizzato JBoss3 , application server open source che implementa l’intera suite di servizi Java EE. Il vantaggio nell’uso di JBoss riguarda il
fatto di poter essere utilizzabile su qualsiasi sistema operativo che supporti Java.
1
http://en.wikipedia.org/wiki/Service-oriented architecture
http://ant.apache.org/
3
http://www.jboss.org/
2
61
5 – Linked Data ICONVIS
5.2
Tecnologie del front end
All’interno di questa sezione vengono affrontati da un lato gli aspetti relativi alle
tecnologie sfruttate per la visualizzazione dei dati e dall’altro quelle relative al recupero dei dati presenti su DBpedia che, per rendere l’applicazione più rapida nel
rispondere all’interazione con l’utente, sono state collocate nel front end.
5.2.1
ActionScript 3.0
Actionscript è un linguaggio di programmazione object-oriented di proprietà della
Adobe Systems. Si tratta di un dialetto ECMAScript e dunque è caratterizzato dalla
medesima sintassi e semantica di JavaScript. Esso viene utilizzato principalmente
per lo sviluppo di siti Web ed applicazioni basati sulla piattaforma Adobe Flash
Player. ActionScript è stato progettato inizialmente per il controllo di semplici
animazioni vettoriali 2D realizzate in Adobe Flash. Nelle sue versioni successive sono
state incrementate le capacità di scripting, con funzionalità che ne hanno permesso
l’uso per lo sviluppo di giochi e applicazioni Web dinamiche in grado di contemplare
l’uso di file multimediali.
ActionScript 3.0 ha determinato una ristrutturazione fondamentale del linguaggio, tanto che utilizza una macchina virtuale completamente diversa rispetto a quella
sfruttata per le versioni precedenti. Inoltre, esso ha aggiunto un supporto limitato
per l’accelerazione hardware (DirectX, OpenGL). Oltre a ciò, ActionScript 3.0 fornisce un supporto per la dinamica 3D: rotazione lungo gli assi X Y e Z e texture
mapping.
Flare Prefuse
Per poter visualizzare una gran mole di dati trattabili a livello grafico secondo esigenze specifiche, la scelta è stata quella di utilizzare un tool concepito per la visualizzazione di dati sul web, Flare Prefuse4 . Flare è una libreria sviluppata a partire
da ActionScript 3.0 studiata per la creazione di elementi visuali. Il toolkit supporta
la gestione dei dati, la codifica visiva, le animazioni e diverse tecniche di interazione.
Esso fornisce inoltre un design modulare che aiuta gli sviluppatori nella creazione
di tecniche di visualizzazione personalizzate. Rispetto ad altri strumenti quali ad
esempio GraphViz5 , JGraph6 , Jung7 , JQuery Visualize8 , Flare fornisce il miglior
4
http://flare.prefuse.org/
http://www.graphviz.org/
6
http://www.jgraph.com/
7
http://jung.sourceforge.net/
8
http://www.filamentgroup.com/lab/update to jquery visualize accessible charts with html5 from designing with/
5
62
5.2 – Tecnologie del front end
compromesso tra complessità di utilizzo, configurabilità e resa grafica. Gli strumenti offerti da Flare permettono di scegliere la forma del grafo con cui mostrare i dati
in relazione alle proprie esigenze, consentendo inoltre il passaggio da una visualizzazione all’altra in modo molto semplice. In aggiunta, viene proposta una serie
di interfacce che permettono di modificare gli elementi visivi di base (node, edge),
utilizzando proprietà e metodi della classe ‘Graphics’ di ActionScript 3.0, per una
notevole libertà di sviluppo. Esiste inoltre un insieme di strumenti molto potenti
per la visualizzazione dei dati. Le informazioni infatti vengono conglobate all’interno delle istanze delle classi degli oggetti grafici, senza dover creare un ponte con le
strutture dati fornite dal linguaggio di programmazione. Per poter visualizzare la
label associata a un nodo, ad esempio , basta semplicemente specificare una stringa
nella proprietà ‘data.label’ dell’istanza. L’oggetto di tipo ‘Labeler’, a cui si dovrà
indicare quale property dell’elemento grafico contiene la stringa che dovrà essere
visualizzata, provvederà ad associare a ciascuno di essi un oggetto grafico (istanza
della classe Sprite) specifico di ActionScript 3, ed aggiungerlo come figlio (child ) o
come livello (layer ) sovrapposto all’elemento.
5.2.2
DBpedia Lookup Service
Il servizio DBpedia Lookup9 consente di andare alla ricerca degli URI presenti su
DBpedia a partire da parole chiave correlate. Con il termine ‘correlate’ si può intendere da un lato l’etichetta (label ) associata ad un URI specifico, dall’altro invece un
testo di ancoraggio utilizzato frequentemente in Wikipedia come riferimento a quel
dato elemento. Ad esempio, la risorsa http://dbpedia.org/resource/United States
può essere associata molto spesso alla stringa ‘USA’. I risultati forniti dal servizio
vengono poi ordinati secondo il numero di link d’ingresso presenti sulle altre pagine
di Wikipedia, che conducono alla pagina considerata.
LookUp offre due diverse API: la ricerca di parole chiave e la ricerca a partire da
un prefisso; l’URL definito per la richiesta delle risorse è caratterizzata dalla forma
seguente: http://lookup.dbpedia.org/api/search.asmx/ -API-? -parametri-. Nel primo caso, la stringa utilizzata per scovare la risorsa su DBpedia può essere costituita
da uno o più termini. Esaminando, ad esempio, tutti i luoghi collegati alla parola
Berlino, è possibile comporre una richiesta di questo tipo:
http://lookup.dbpedia.org/api/search.asmx/KeywordSearch?QueryClass=place
&QueryString=berlin
Nel secondo caso, è possibile impostare un tipo di analisi basato sull’autocompletamento. A partire da una stringa che definisce soltanto una parola chiave espressa
9
http://dbpedia.org/lookup
63
5 – Linked Data ICONVIS
in modo parziale come ad esempio ‘Berl’, l’API è in grado di restituire una serie di
risorse DBpedia tra cui anche http://dbpedia.org/resource/Berlin. Qualora si volesse
effettuare una richiesta in cui vengono mostrate le cinque risorse più rilevanti a partire da un termine chiave che inizia con ‘Berl’ è possibile impostare la seguente URL:
http://lookup.dbpedia.org/api/search.asmx/PrefixSearch?QueryClass=MaxHits=5
QueryString=berl
All’interno della richiesta, vengono specificati tre parametri:
• QueryString: una stringa grazie a cui è possibile recuperare un URI su DBpedia;
• QueryClass: una classe DBpedia appartenente alla sua ontologia, a cui la
risorsa dovrebbe appartenere (nel caso in cui la classe di appartenenza sia
owl#Thing o per risorse non tipizzate, tale parametro deve restare vuoto).
• MaxHits: il numero massimo di risultati restituiti.
DBpedia LookUp ingloba attualmente i dati contenuti nella versione 3.6 di DBpedia. Da questo insieme sono esclusi tutti quei risultati che non rappresentano
un’entità specifica, ma sono risorse di reindirizzamento. Il servizio è basto su un
indice Lucene10 , costruito sulla base del dump della versione inglese di Wikipedia
datata ottobre 2010. I risultati vengono rappresentati in formato XML e sono contraddistinti dai seguenti elementi: l’URI della risorsa, la label, una breve descrizione,
le classi (URI ed etichetta), le categorie (URI ed etichetta), il numero di link in
ingresso alla pagina di Wikipedia.
All’interno della componente di front end le LookUp API sono state utilizzate
per il matching con la risorsa presente all’interno di DBpedia. Per poter compiere
tale operazione, è stata prelevata dall’ontologia l’etichetta del nodo considerato,
sfruttandola per comporre la richiesta verso il servizio. Nel caso in cui la keyword
search non vada a buon fine, l’applicazione prevede una prefix search, che come
specificato in precedenza consente l’autocompletamento a partire da una stringa
parziale. Un meccanismo di questo tipo implica la necessità che le etichette siano
scritte in modo preciso e formalmente corretto. Allo stesso modo, entrano in gioco
tutte le problematiche relative alla lingua di partenza che in molti casi può essere
diversa dall’inglese. Ecco perché nello sviluppo e nell’uso di questo genere di applicazioni occorre tenere bene a mente tali aspetti, che tuttavia coinvolgono elementi
che vanno al di là dello studio di metodi di visualizzazione adeguati. Infine, la scelta
di collocare LookUp nel front end consente dei tempi di risposta molto più rapidi
10
http://lucene.apache.org/java/docs/index.html
64
5.3 – Visualizzazione
rispetto a quelli necessari per un’ulteriore richiesta verso il back end Java da parte
del client Flash.
5.3
Visualizzazione
Gli aspetti relativi alla visualizzazione sono stati suddivisi a livello concettuale in
tre parti differenti. La prima riguarda tutti gli elementi relativi alla visualizzazione
dell’ontologia, in relazione alla grande quantità di informazioni che essa in grado di
veicolare. In secondo luogo vengono affrontate le modalità con cui vengono visualizzati i dati presenti sul database su cui tale ontologia è stata sviluppata, e infine
vengono spiegate le scelte effettuate per mostrare i dati provenienti da sorgenti
esterne.
5.3.1
Elementi dell’ontologia
Oltre alla struttura gerarchica con cui sono organizzate le rappresentazioni concettuali delle informazioni, un’ontologia racchiude al proprio interno le proprietà
che caratterizzano i singoli concetti e le specifiche relazioni che intercorrono tra di
essi. A tal proposito, occorre visualizzare opportunamente ciascun elemento dell’ontologia, affinché l’utente possa discernere senza troppi sforzi le informazioni che gli
interessano:
• Classi : è possibile visualizzare in una sola volta tutte le classi, oppure visualizzarne soltanto alcune in relazione alle esigenze dell’utente. Le classi
vengono distinte l’una dall’altra associando a ciascuna di esse un identificativo espresso in forma intelligibile. Nel caso di LDI, la scelta è stata quella di
visualizzare soltanto i concetti a cui l’utente è davvero interessato attraverso
la ”esplosione” dei nodi durante la navigazione, incorporando all’interno dell’elemento grafico che rappresenta la classe una label prelevata direttamente
dalla property rdfs:label dell’ontologia. Nel caso in cui tale property non sia
presente, viene utilizzato direttamente il finale dell’URI che identifica il concetto. Poiché in alcuni casi il numero di nodi del medesimo livello (siblings)
associato a una classe diviene tale da superare i limiti dello schermo, è stata introdotta una funzione che permette di visualizzare soltanto un certo numero di
sottoclassi per volta: quando l’utente preme il bottone (Figura 5.1 - Elemento
‘Thing’), le sottoclassi visualizzate in quel momento si ‘ritirano’, dando spazio
a quelle successive. In questa maniera si evita che l’utente rimanga confuso da
una visualizzazione troppo pesante. Qualora una determinata classe possieda
delle sottoclassi, sovrapponendo ad essa il cursore del mouse viene visualizzato un oggetto grafico di colore arancione, che una volta cliccato permette di
visualizzare le relative sottoclassi (Figura 5.1 - Elemento ‘oggetto giuridico’).
65
5 – Linked Data ICONVIS
Figura 5.1.
Classi dell’ontologia con indicatore delle sottoclassi
66
5.3 – Visualizzazione
• Istanze: non è opportuno visualizzarle come elementi inseriti direttamente
all’interno del grafo che definisce la struttura gerarchica delle classi, poiché
spesso sono molto numerose e potrebbero indurre l’utente a una confusione
concettuale. Per questi motivi, una scelta opportuna risulta quella di introdurre una vista separata rispetto al grafo dell’ontologia, nella quale collocare
gli individui della classe. LDI, a questo proposito, permette di visualizzare le
istanze con molta facilità. In primo luogo, a partire dal grafo dell’ontologia,
grazie a una piccola icona verde che compare nel caso in cui il cursore del
mouse venga sovrapposto a una classe, è possibile capire innanzitutto se essa
possiede delle istanze (Figura 5.2 - Elemento ‘vegetale’).
Figura 5.2.
Classi dell’ontologia con indicatore delle istanze
Ovviamente, nel caso in cui una classe possieda sia sottoclassi che istanze, vengono visualizzati entrambi gli elementi grafici (Figura 5.3 - Elemento ‘materia
prima’).
Con un click sull’icona verde, è possibile accedere alle istanze. La nuova struttura visiva si presenta come una raggiera, al cui centro viene posta la classe
presa in considerazione e agli estremi gli individui appartenenti a tale classe
(Figura 5.4). La scelta dei colori aiuta l’utente finale a riconoscere con molta facilità la differenza tra classi e istanze. Per tornare alla vista del grafo
principale, non si deve far altro che cliccare nella posizione in alto a sinistra
dello schermo, laddove è posizionata l’anteprima del grafo (Figura 5.5). Anche
in questo caso, qualora il numero degli individui fosse troppo elevato per una
visualizzazione efficace sullo schermo, la medesima funzione adottata per le
gestione delle classi consente ai nodi visualizzati in quel momento di essere
‘ritirati’, per far spazio alle nuove istanze da mostrare.
67
5 – Linked Data ICONVIS
Figura 5.3.
Classi dell’ontologia con indicatore di classi e istanze
Figura 5.4.
Visualizzazione delle istanze dell’ontologia
68
5.3 – Visualizzazione
Figura 5.5.
Visualizzazione delle istanze con anteprima del grafo delle classi
69
5 – Linked Data ICONVIS
• Tassonomia (relazioni di tipo ISA11 ): la presentazione di questo elemento è
essenziale per comprendere le relazioni di ereditarietà tra le classi. Il sistema
deve fornire una visione olistica12 della tassonomia, all’interno di una rappresentazione gerarchica. Una visualizzazione parziale del grafo, che permette
all’utente di concentrarsi su una porzione specifica della tassonomia, è inoltre
una caratteristica desiderabile durante la navigazione (Figura 5.6).
Figura 5.6.
Visualizzazione di una porzione della tassonomia
Per rispondere a questa esigenza, LDI implementa una serie algoritmi che
consentono al grafo di scorrere in maniera automatica, a seconda di quale
zona l’utente intenda esplorare. In particolare, nel momento in cui il nodo
viene “esploso” con un clic del mouse, l’algoritmo controlla che i nodi figli
siano in quell’istante visibili sullo schermo. Se cosı̀ non fosse, una funzione
consente al grafo di scorrere quanto basta perché tutti i nodi figli possano essere
visualizzati: il cerchio blu in Figura 5.7 mostra l’effettiva traslazione del grafo
verso destra, affinché le sottoclassi di ‘artefatto’ possano essere visualizzate. Lo
11
Le relazioni ISA (termine che deriva dall’espressione “is a”) specificano che una classe deve
considerarsi una sottocategoria o sottoclasse di un’altra detta superclasse
12
L’Olismo è una posizione filosofica basata sull’idea che le proprietà di un sistema non possano
essere spiegate esclusivamente tramite le sue componenti. In questo caso specifico, con “visione
olistica” intendo una visualizzazione complessiva del grafo in cui il dominio di conoscenza viene
esplicitato mostrando non soltanto i singoli concetti, ma anche come essi si relazionano tra loro
70
5.3 – Visualizzazione
scorrimento è implementato per tutte e quattro le direzioni e nel momento in
cui un nodo ‘implode’, qualora fosse necessario per esigenze di visualizzazione,
il grafo viene ‘riportato’ nella posizione di partenza.
Figura 5.7.
Movimento del grafo
• Relazioni : hanno un ruolo cruciale all’interno delle ontologie. Come nel caso
delle istanze, è consigliabile una visualizzazione separata dalla struttura gerarchica complessiva. L’alberatura infatti non permette di definire in maniera
adeguata le relazioni, poiché oltre a indicare quali entità sono coinvolte, occorre
specificare la natura di tali relazioni. Tramite un click su una delle istanze visualizzate (Figura 5.4), l’applicazione mostra le relazioni che intercorrono con
le altre istanze definite nell’ontologia, che vanno a disporsi agli estremi di una
raggiera (Figura 5.8). Cliccando sui nodi relativi alle altre istanze, è possibile
reiterare la visualizzazione delle relazioni.
Un’anteprima del grafo delle istanze appartenenti a una data classe viene
mostrata nella zona in basso a destra dello schermo, al di sotto dell’anteprima
71
5 – Linked Data ICONVIS
Figura 5.8.
Relazioni dell’ontologia
72
5.3 – Visualizzazione
riguardante la tassonomia delle classi. Tramite un click su una delle anteprime,
l’utente può tornare ad esplorare il livello concettuale che gli interessa (Figura
5.9). Nella tabella seguente (5.1) viene riportata una sintesi delle strategie con
le quali i principali visualizzatori di cui si è accennato nel capitolo precedente
mostrano gli elementi principali dell’ontologia.
Figura 5.9. Relazioni dell’ontologia con anteprime della tassonomia e delle
istanze appartenenti a una classe
Struttura ad albero
Una visualizzazione di tipo tree, che si struttura secondo un diagramma nodo-link, è
una delle vie più efficaci e intuitive per poter mostrare una rappresentazione gerarchica. È infatti possibile avere una panoramica della profondità e della larghezza che
caratterizza una specifica porzione del grafo. Quest’ultimo inoltre può essere orientato dall’alto verso il basso (top-down) oppure da sinistra verso destra (left-right),
a seconda delle esigenze del content provider e/o dell’utente. Alcuni dei principali
punti deboli che vengono attribuiti a questo tipo di visualizzazione riguardano la necessità di scorrimento del grafo, o della presenza di più schermi nel momento in cui
vi sia un numero molto elevato di classi o istanze da visualizzare [19]. D’altro canto,
spesso lo scorrimento viene implementato tramite delle barre di navigazione: un’operazione sconsigliata perché costringe l’utente a spostare continuamente la propria
attenzione dal grafo agli strumenti di spostamento e viceversa.
73
5 – Linked Data ICONVIS
Metodi
Classi e istanze
Gerarchia
classi
delle
Multiereditarietà
Relazioni
Protégé
Le classi vengono presentate come nodi di
una lista indentata che
si possono ritrarre ed
espandere. Le istanze
vengono mostrate in
una finestra separata
I nodi figli vengono posizionati sotto il relativo padre, indentati
verso destra
I nodi figli vengono collocati in relazione a
tutti i propri padri
NO
Isaviz
Classi
e
istanze
vengono rappresentate
come liste etichettate
I nodi sono linkati ai
propri padri. La parentela è visibile attraverso una vista generale e una di dettaglio
I nodi figli vengono collocati in relazione a
tutti i propri padri
Rappresentate tramite
link etichettati
Grokker
Classi
e
istanze
vengono rappresentate
tramite cerchi colorati
I nodi più profondi
sono più piccoli rispetto ai propri padri e
collocati all’interno di
essi
NO
NO
I nodi vengono rappresentati come dei riquadri colorati, con dimensioni differenti. Le
etichette sono visibili
soltanto fino a una
certa profondità
I nodi che si trovano
a un livello gerarchico
più basso vengono collocati all’interno dei
propri padri
NO
NO
BiFocal Tree
I nodi sono rappresentati come rettangoli etichettati quando
si trovano nella focus
area e come cerchi all’interno della context
area
I nodi figli si dispongono attorno al proprio padre, lungo una
circonferenza
NO
NO
Ontosphere
Classi e istanze sono
rappresentate attraverso delle sfere
Nella visualizzazione
TreeFocus, i nodi figli
vengono collocati più
in profondità rispetto
al proprio padre
Nella visualizzazione
TreeFocus, i nodi figli
sono collegati a tutti i
propri padri
Nella visualizzazione
ConceptFocus,
vengono
mostrati
dei
collegamenti
etichettati
Linked Data ICON-
Le classi e le istanze
vengono mostrate attraverso ellissi etichettate con colori diversi
e visualizzati su grafi
differenti
I nodi figli vengono collocati sotto il rispettivo
padre
I nodi figli vengono
mostrati sotto tutti i
propri padri
Le relazioni vengono
mostrate in un grafo
differente,
attraverso
collegamenti
etichettati
TreeMap
Gene
del
Ontology
Consortium
VIS
Tabella 5.1. Tabella di confronto tra differenti visualizzatori di ontologie
e Linked Data ICONVIS
Nel caso di LDI, qualora il numero di sottoclassi di un medesimo livello appartenenti a una specifica superclasse sia troppo elevato, si è scelto di visualizzare
soltanto un certo numero di sottoclassi alla volta. Malgrado una visualizzazione di
questo genere determini una perdita dell’informazione complessiva deducibile dall’ontologia, d’altra parte occorre ricordare che l’utente è interessato soprattutto alla
74
5.3 – Visualizzazione
visualizzazione dei dati, piuttosto che del dominio di cui essi fanno parte. In secondo luogo, per poter evitare l’uso delle barre di scorrimento, nel caso di LDI sono
stati sviluppati degli algoritmi di spostamento che permettono al grafo di scorrere
in maniera automatica a seconda della zona che l’utente sta esplorando in quel
momento.
Secondo alcuni studi [10], uno degli approcci più efficaci per mostrare molti elementi attraverso una visualizzazione ad albero è quello utilizzato da SpaceTree che
prevede tecniche di espansione e di ritorno dei singoli nodi (exapansion/retraction),
con l’aggiunta di un espansione controllata dei cosiddetti subtrees, che appartengono al grafo complessivo. LDI attualmente prevede un meccanismo di espansione
graduale dei nodi: la visualizzazione di partenza infatti mostra soltanto le sottoclassi di ‘Thing’, la classe a cui convenzionalmente si riferiscono tutti gli elementi di
una qualunque ontologia. A quel punto, l’utente può esplorare il ramo del grafo che
maggiormente gli interessa, guidato dagli algoritmi di scorrimento. Attualmente non
è previsto un meccanismo di retraction che, nel caso in cui si rivelasse necessario,
sarebbe molto semplice da implementare attraverso la libreria Flare Prefuse.
5.3.2
Visualizzazione dei dati
LDI consente all’utente di visualizzare con estrema semplicità tutti i dati delle istanze di una specifica classe o di una singola istanza a partire dal grafo ontologico.
Esplorando i concetti di un’ontologia sui beni culturali, ad esempio, è possibile
raggiungere la classe ‘palazzo’. Nel caso in cui l’utente sia interessato ai dati del
DB delle istanze della classe ‘palazzo’, può visualizzarle tramite un ‘interruttore’
contrassegnato da un’icona bianca, riconducibile alla forma di un DB. Il grafo tassonomico si riduce in alto a sinistra poco prima che i dati vengano visualizzati sullo
schermo, in modo tale che l’informazione relativa all’esplorazione dei concetti da
parte dell’utente non venga persa (Figura 5.10).
Anziché visualizzare i dati di tutte le istanze di una classe, è possibile tuttavia
ridurre il campo di ricerca a una singola istanza, in questo specifico caso ‘Palazzina di
Caccia di Stupinigi’, visualizzando tutti i contenuti presenti nel DB. (Figura 5.11).
Poiché ‘Palazzina di Caccia di Stupinigi’ è un’istanza della classe ‘palazzo’, vi si
potrà accedere soltanto dopo aver esplorato le istanze di quest’ultima. In tal caso,
anche il grafo che mostra le istanze si sposterà nella zona sinistra dello schermo per
far posto alla visualizzazione dei dati. Come nei casi precedenti, è possibile tornare
alla visualizzazione dei grafi relativi all’ontologia con molta semplicità, con un click
nella zona in cui esse sono posizionate.
75
5 – Linked Data ICONVIS
Figura 5.10.
Figura 5.11.
Visualizzazione dei dati delle istanze della classe ‘palazzo’
Visualizzazione dei dati dell’istanza ‘Palazzina di Caccia di Stupinigi’
76
5.3 – Visualizzazione
5.3.3
Visualizzazione dei Linked Data
Gli elementi che contribuiscono alla visualizzazione dei Linked Data costituiscono
il terzo step dello sviluppo dell’applicazione. In questo caso i dati provengono da
sorgenti esterne (DBpedia nello specifico), tuttavia si è deciso di mantenere una
struttura coerente ed omogenea con le scelte adottate nel caso dell’ontologia e dei
dati presenti sul DB. Se da un lato l’utente deve avere la possibilità di confrontarsi
con un tipo di interazione a lui familiare, allo stesso modo l’applicazione deve indurlo
a comprendere che sta visualizzando oggetti diversi dai precedenti.
In primo luogo, dopo aver cliccato sull’icona che rappresenta la tripla RDF (vedi
icona blu in Figura 5.8), viene mostrato un grafo orientato da sinistra a destra che
gli consente di capire il genere di dati recuperati dai datasource esterni (Figura 5.12):
l’elemento posizionato sulla sinistra rappresenta l’entità di cui vogliamo conoscere le
informazioni, mentre sulla destra sono posizionati i nodi che riguardano una sintesi
di tali informazioni. Per quest’ultimi, si è scelto di adottare il colore con cui vengono
rappresentate le sorgenti di dati che fanno parte della Linked Data Cloud (Figura
3.2). Mentre il grafo mostra un’anteprima dei dati che l’applicazione è riuscita
a recuperare, sulla zona destra dello schermo è stata creata una vista per poter
visualizzare i dati in maniera completa e di facile comprensione per l’utente (Figura
5.14). La scelta di rappresentare un’informazione di sintesi è legata al fatto che,
talvolta, per l’entità presa in considerazione DBpedia non contiene alcune voci. Nel
caso di Antonio Ascari (Figura 5.15), ad esempio, non vi è la proprietà dbpediaowl:thumbnail, che di solito lega l’entità soggetto alla risorsa di una delle immagini
contenute in Wikipedia.
Le informazioni prelevate da DBpedia, ovvero il thumbnail, l’abstract di Wikipedia,
i link esterni e gli URI per un’eventuale disambiguazione intendono mostrare una
serie di contenuti che forniscono una sintesi dell’entità presa in considerazione e
diverse indicazioni per consultare risorse ulteriori. Nel caso in cui inoltre si tratti
di un’entità che si situa in uno specifico luogo, oltre ai dati descritti in precedenza viene visualizzata una mappa che indica la collocazione geografica, grazie alle
coordinate prelevate da DBpedia (Figura: 5.13). Intuitivamente, la presenza di coordinate geografiche consente all’applicazione di capire se un’entità è effettivamente
un luogo e di conseguenza richiedere al servizio Google Maps le primitive grafiche
per la creazione della mappa.
Le sezione legata agli URI alternativi non rappresenta soltanto un insieme di informazioni che s’intende semplicemente visualizzare. Nel caso di entità molto simili
tra di loro, in cui la label adottata dall’ontologia non consenta al servizio LookUp13
di individuare l’entità corretta, gli URI forniti divengono preziosissimi. Essi costituiscono infatti una nuova finestra di navigazione attraverso cui l’utente, presa coscienza del fatto che le informazioni recuperate non si riferiscono all’entità rappresentata
13
Vedi Paragrafo DBpedia LookUp Service
77
5 – Linked Data ICONVIS
Figura 5.12. Visualizzazione del grafo relativo all’istanza Cesare Pavese ed alle
tipologie di dati recuperati da DBpedia
78
5.3 – Visualizzazione
Figura 5.13. Visualizzazione dei dati relativi al comune di Chivasso
prelevati da DBpedia
79
5 – Linked Data ICONVIS
nell’ontologia di partenza, può “insegnare” all’applicazione quale sia la rispettiva
risorsa presente su DBpedia. Questo elemento risulta di notevole importanza. L’applicazione, infatti, risolvendo le label presenti nell’ontologia, potrebbe andare alla
ricerca in maniera automatica della stessa entità che su altri datasource, a livello
concettuale, rappresenta la medesima di quella contenuta nell’ontologia di partenza. A quel punto, l’URI di tale risorsa potrebbe diventare il valore di una property
come owl:sameAs all’interno dell’ontologia, andando ad incrementare il valore d’informazione che essa è in grado di esprimere. Laddove l’applicazione non sia in grado
di riconoscere correttamente la risorsa, interviene ‘la mano dell’uomo’, dando vita,
in una forma specifica, a quella cooperazione tra esseri umani e macchine ipotizzata
da Tim Berners-Lee nel 2001 a proposito del Semantic Web. Infine, per passare
dalla visualizzazione dei Linked Data all’esplorazione degli elementi dell’ontologia si
sfruttano i meccanismi adottati in precedenza (Figura 5.16).
Figura 5.14.
Informazioni su Cesare Pavese prelevate da DBpedia
80
5.3 – Visualizzazione
Figura 5.15.
Figura 5.16.
Informazioni su Antonio Ascari prelevate da DBpedia
Finestra del browser durante la visualizzazione dei Linked Data
81
5 – Linked Data ICONVIS
82
Capitolo 6
Campi di applicazione e
conclusioni
Nei paragrafi successivi vengono analizzati due casi d’uso nei quali sarebbe possibile sfruttare le caratteristiche di LDI. Da un lato nell’ambito della Pubblica
Amministrazione sia per gli operatori che si trovano a dover lavorare con una
sterminata quantità di documenti, che per i cittadini che desiderano accedere ai
dati che l’amministrazione è in grado di produrre. Dall’altro nel campo del Data
Journalism, un fenomeno che, anche grazie all’apertura da parte delle stesse amministrazioni pubbliche, sta assumendo una rilevanza sempre maggiore per poter
arricchire l’esperienza interattiva con cui l’utente si confronta.
6.1
Visualizzazione dei dati nella Pubblica Amministrazione
Le informazioni e i contenuti prodotti dalla Pubblica Amministrazione (PA) rappresentano una risorsa strategica e un patrimonio di conoscenze che spesso risulta
difficilmente accessibile da parte degli utenti in una forma chiara e intuitiva. Eppure, una diffusione accurata di questo genere di dati può rappresentare un elemento
primario per favorire da un lato la partecipazione dei cittadini alla vita pubblica, e
dall’altro la crescita economica e produttiva, la ricerca e l’innovazione. Il 26 luglio
2010 il Ministero per la pubblica amministrazione e per l’innovazione ha emanato
un documento in cui vengono specificate le linee guida per la costruzione dei siti
web per la PA1 . All’interno del documento si specifica come, nella maggior parte
1
Linee guida per i siti web della PA, art. 4 della Direttiva 8/09 del Ministro per la pubblica
amministrazione e l’innovazione, 26 luglio 2010
83
6 – Campi di applicazione e conclusioni
dei casi, la difficoltà nel reperire le informazioni disponibili sia dovuta alle differenti logiche organizzative dei portali delle singole amministrazioni locali. Per questi
motivi, occorre definire con maggiore chiarezza le modalità di offerta dei contenuti,
che vanno classificati secondo standard che ne favoriscano il riuso:
I sistemi di classificazione utilizzati per le risorse dei siti web della
pubblica amministrazione devono consentire l’interoperabilità semantica,
ovvero la possibilità di individuare in modo omogeneo gli attributi che
caratterizzano una risorsa (metadati) e i valori che gli attributi possono
assumere (vocabolari) quando si descrivono i contenuti.
E’ dunque necessario garantire un’interoperabilità che permetta a sistemi diversi
di condividere dati, documentazione e servizi. Tra le diverse raccomandazioni che
vengono specificate all’interno del documento, una in particolare si riferisce alle
modalità di reperimento e visualizzazione delle informazioni:
organizzare i contenuti secondo un’architettura dell’informazione che
consenta la loro presentazione in ordine di rilevanza e pertinenza con i diversi argomenti trattati, la gestione di correlazioni tra i diversi contenuti
e la loro lettura secondo più percorsi di navigazione.
LDI, offrendo un percorso di navigazione che si snoda lungo la struttura dell’ontologia, è in grado di fornire un supporto efficace alla visualizzazione, valorizzando la
correlazione esistente tra i diversi i contenuti (basti pensare alla struttura gerarchica della tassonomia, oppure alla “materializzazione” grafica delle relazioni esistenti
tra le istanze appartenenti alle diverse classi) favorendo inoltre la scelta di percorsi
alternativi. Ad esempio, per poter visualizzare i dati l’utente può focalizzarsi su
una singola istanza: in tal caso verranno mostrati tutti i documenti, le immagini e
video che ad essa fanno riferimento. Oppure, può scegliere un livello di profondità
diverso, decidendo di visualizzare tutti dati della classe a cui quella data istanza
appartiene. In questo caso, ai contenuti precedenti si aggiungeranno quelli relativi
alle altre istanze che fanno riferimento a quella data classe.
L’importanza di visualizzare i dati in maniera adeguata si accompagna al fenomeno
del cosiddetto Open Data nell’ambito della pubblica amministrazione2 , che si manifesta attraverso un comportamento più aperto e trasparente degli enti pubblici che
mette i cittadini nella condizioni di valutarne l’operato. A questo proposito, tra le
iniziative più interessanti presenti in rete si distingue Data.gov3 , sito web creato nel
2009 dal CIO (Chief Information Officer ) dell’amministrazione Obama con lo scopo
di raccogliere in un unico portale tutte le informazioni rese disponibili dagli enti
2
3
http://it.wikipedia.org/wiki/Dati apertiL.27Open data nella pubblica amministrazione
http://www.data.gov/
84
6.2 – Il giornalismo nell’era dei dati
statunitensi in formato aperto. Il sito presenta anche una sezione legata al Semantic
Web4 , al cui interno si specifica l’obiettivo primario di coinvolgere cittadini e sviluppatori per costruire applicazioni ibride che sfruttino i Linked Data, integrando le
informazioni della PA con quelle presenti all’interno dei datasource aperti disponibili in rete ed espressi in RDF. LDI, fornendo gli strumenti per poter risolvere gli
URI e agganciarsi a dataset esterni potrebbe fornire un supporto ulteriore a questa
specifica esigenza. Un altro esempio concreto dell’uso degli strumenti del Semantic
Web nell’ambito della PA è dato da Data.gov.uk5 , che possiede inoltre un end point
per poter effettuare query SPARQL e interrogare il datasource.
6.2
Il giornalismo nell’era dei dati
Il giornalismo si è sempre fondato sulla testimonianza di fatti e asserzioni. Ma oggi, per poter alimentare una storia, la visualizzazione dei dati diviene un elemento
cruciale. A differenza dei fatti, il dato può essere calcolato, analizzato e gestito in
maniera automatica. Una visualizzazione efficace consente a tal proposito di effettuare confronti o di analizzare in modo accurato l’evoluzione di un carattere specifico
della società (aumento/diminuzione della disoccupazione, variazioni nel fenomeno
dell’immigrazione ecc.). Concentrare l’attenzione su questo bacino di informazioni,
focalizzandosi non soltanto sullo stato “istantaneo” dell’informazione quanto invece
sul suo progressivo cambiamento, rappresenta l’essenza di ciò da cui deriva la notizia
in quanto tale.
I giornali più importanti del mondo si sono attrezzati con specifiche sezioni all’interno dei propri siti web, in cui vengono pubblicati i dati riguardanti la pubblica
amministrazione, ma non solo. Uno degli esempi più famosi è il Data Store 6 del
Guardian, dove vengono messi in evidenza i servizi giornalistici basati sulla raccolta e sull’analisi dei dati. Lo ‘Store’ è poi innervato da un Data Blog 7 in cui sono
pubblicati non solo le notizie e i servizi del Guardian che si alimentano di dati, ma
anche tutte le news riguardanti il movimento internazionale Open Data8 .
Anche il New York Times ha sostenuto ingenti sforzi in questa direzione: se da
un lato infatti il suo dipartimento grafico ha aperto uno specifico canale su Twitter
nel quale vengono pubblicate notizie in cui i dati svolgono il supporto fondamentale,
dall’altro nel 2008 ha sviluppato il servizio Visualization Lab 9 che consente ai lettori
di creare tabelle, mappe e grafici interattivi sfruttando i dati messi a disposizione dal
4
http://www.data.gov/semantic/index
http://data.gov.uk/
6
http://www.guardian.co.uk/data-store
7
http://www.guardian.co.uk/news/datablog
8
http://www.opendatafoundation.org/
9
http://vizlab.nytimes.com/
5
85
6 – Campi di applicazione e conclusioni
Times e la tecnologia Many Eyes 10 proposta da IBM. Gli utenti possono commentare
le visualizzazioni, condividerle sotto forma di widget e immagini, creare dei topic
in cui raccogliere questi dati e discutere di argomenti specifici. Inoltre, a partire
dal 2009, il New York Times ha cominciato a pubblicare il proprio indice come
Linked Open Data11 . Al 13 febbraio 2010, le voci pubblicate sotto licenza Creative
Commons erano all’incirca 10 mila ed erano disponibili sia come documenti RDF
che come pagine HTML. La tabella 6.1 mostra la classificazione dei tag e le strategie
di mapping utilizzate per l’estrazione dei dati.
Type
Manually mapped tags Automatically mapped tags
People
4.978
0
Organizations
1.489
1.582
Locations
1910
0
Descriptors
498
0
Tabella 6.1.
6.3
Total
4.978
3.081
1.910
498
Entità estratte dall’archivio del New York Times
Conclusioni
In un contesto nel quale l’utente si confronta con una mole sterminata di dati, si fa
strada la necessità di collocare questi stessi dati all’interno di un preciso dominio
semantico affinché l’utente sia in grado, con strumenti opportuni, di raggiungere
l’informazione che risponde effettivamente alle sue esigenze. Sul modello dei motori
di ricerca semantici, il reperimento dei dati non avviene in base alle informazioni
specifiche che l’utente già possiede, ma per mezzo del percorso concettuale che l’ontologia gli propone. Tuttavia, a differenza dei motori di ricerca, nel caso di LDI gli
artefatti di rappresentazione della conoscenza non sono uno strumento nascosto che
fornisce intelligenza al meccanismo di information retrieving, bensı̀ sono espliciti ed
evidenti al visitatore in tutta la loro ricchezza.
Linkded Data ICONVIS è dunque in grado di visualizzare e consentire la navigazione interattiva di dati strutturati in forma di ontologia. Dal momento che
l’ontologia in ingresso al sistema è progettata sulla base dei valori dei campi più
significativi di un database, essa costituisce la rappresentazione della conoscenza
complessiva del dominio a cui i dati si riferiscono. L’utente può passare dall’esplorazione dei concetti presenti sul grafo ontologico all’effettiva fruizione dei contenuti
del DB. Oltre a ciò, l’applicazione è in grado di agganciarsi a database esterni e
costruire viste opportune, prelevando dati specifici in grado di arricchire i contenuti
al quale l’utente può accedere.
10
11
http://manyeyes.alphaworks.ibm.com/manyeyes/
http://data.nytimes.com/
86
6.3 – Conclusioni
In sintesi, l’applicazione si propone come mezzo per poter accedere ai dati relazionali sfruttando i paradigmi e gli strumenti del Web Semantico non soltanto
all’interno di un dominio chiuso e specifico, ma sfruttando le relazioni esistenti tra
i dati provenienti da diverse sorgenti. Un mezzo per poter esplorare il Web of Data
ipotizzato da Tim Berners-Lee.
87
6 – Campi di applicazione e conclusioni
88
Bibliografia
[1] K. Ahmad, M. Tariq, B. Vrusias, e C. Handy, Corpus-based thesaurus construction for image retrieval in specialist domains, in
“Advances in Information Retrieval:
Proceedings of the 25th
European
Conference
on
IR
Research
(ECIR
2004)”,
2003,
http://www.computing.surrey.ac.uk/ai/socis/papers/ECIR03 tech.pdf
[2] T. Berners-Lee, Relational Databases on the Semantic Web - Design Issues, 1998,
http://www.w3.org/DesignIssues/RDB-RDF.html
[3] T.
Berners-Lee,
Linked
Data
Design
Issues,
2006,
http://www.w3.org/DesignIssues/LinkedData.html
[4] T. Berners-Lee, W. Hall, J. A. Hendler, K. O’Hara, N. Shadbolt,
D. J. Weitzner, A framework for Web Science, in “Journal Foundations and Trends in Web Science”, Volume 1, Issue 1, 2006,
http://eprints.aktors.org/594/01/1800000001.pdf
[5] T. Berners-Lee, Y. Chen, L. Chilton, D. Connolly, R. Dhanaraj, J. Hollenbach, A. Lerer, D. Sheets, Tabulator: Exploring and Analyzing linked dataon
the Semantic Web, 2006, http://swui.semanticweb.org/swui06/papers/BernersLee/Berners-Lee.pdf
[6] C. Bizer, T. Heath, T. Berners-Lee, Linked Data - The Story So Far, in “International Journal on Semantic Web and Information Systems (IJSWIS)”, 2009,
http://tomheath.com/papers/bizer-heath-berners-lee-ijswis-linked-data.pdf
[7] C. Bizer, J. Lehmannb, G. Kobilarova, S. Auerb, C. Beckera, R. Cyganiakc,
S. Hellmannb,DBpedia - A crystallization point for the Web of Data , in “Journal
of Web Semantics”, 2009
[8] J. Dmitrieva, F. J. Verbeek, Multi-view Ontology Visualization, 2009,
http://protege.stanford.edu/conference/2009/abstracts/S9P3Dmitrieva.pdf
[9] J. Euzenat, F. Scharffe, A. Zimmermann, Expressive alignment language and implementation, in “IKnowledge Web project report”, KWEB/2004/D2.2.10/1.0,
2007, http://sw-app.org/pub/isemantics08-sotsw.pdf
[10] J. D. Fekete, C. Plaisant, Interactive Information Visualization of a Million
Items, in “Proceedings of IEEE Symposium on Information Visualization”, 2002,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.81.9248&rep=rep1&type=pdf
89
Bibliografia
[11] C. Fry, M. Plusch, H. Lieberman, Static and Dynamic Semantics of the
Web, in “Spinning the Semantic Web: Bringing the World Wide Web to its
Full Potential”, 2003, http://web.media.mit.edu/ lieber/Lieberary/DynamicSemantics/Dynamic-Semantics.pdf
[12] J. A. Goguen, Ontology, Society, and Ontotheology, “International Conference on Formal Ontology in Information Systems”, 2004
,http://cseweb.ucsd.edu/users/goguen/pps/fois04.pdf
[13] A. Katifori, C. Halatsis, G. Lepouras, C. Vassilakis, E. Giannopoulou, Ontology Visualization Methods – A Survey, in “ACM Computing Surveys”, 2007,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7581&rep=rep1&
type=pdf
[14] K. Pastra e Y. Wilks,
Vision-language integration in AI:
A
reality
check,
in
“Proceedings
of
ECAI
2004”,
2004,
http://www.ilsp.gr/homepages/pastra/documents/ecai04.pdf
[15] K. Petridis, F. Precioso, T. Athanasiadis, Y. Avrithis e Y. Kompatsiaris, Combined domain specific and multimedia ontologies for image understanding, in
“Proceedings of the Workshop on Mixed-Reality as a Challenge to Image Understanding and Artificial Intelligence, 28th German Conference on Artificial
Intelligence”, 2004, http://www.image.ece.ntua.gr/papers/384.pdf
[16] Y. Raimond, C. Sutton e M. Sandler Automatic Interlinking of Music Datasets
on the Semantic Web, 2008, http://events.linkeddata.org/ldow2008/papers/18raimond-sutton-automatic-interlinking.pdf
[17] S. S. Sahoo, W. Halb, S. Hellmann, K. Idehen, T. Thibodeau Jr,
S. Auer, J. Sequeda, A. Ezzat, A Survey of Current Approaches for Mapping of Relational Databases to RDF, “W3C RDB2RDF Incubator Group”,
http://www.w3.org/2005/Incubator/rdb2rdf/RDB2RDF SurveyReport.pdf
[18] N. Simou, C. Saathoff, S. Dasiopoulou, E. Spyrou, N. Voisine, V. Tzouvaras,
I. Kompatsiaris, Y. Avrithis e S. Staab, An ontology infrastructure for multimedia reasoning, in “International Workshop on Very Low Bit-Rate Video-Coding”,
2005, http://www.image.ntua.gr/papers/381.pdf
[19] F. Van Ham, J. J. Van Wijk, Beamtrees:
Compact Visualization of Large Hierarchies,
in “Proceedings of the IEEE
Conf.
Information
Visualization”,
IEEE
CS
Press,
2002,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.7659&rep=rep1&type=pdf
90