laurea magistrale in ingegneria del...
TRANSCRIPT
Laureando: Gabriele Manna
Relatore: Fulvio Corno
Tutor aziendale: Louis Bono
LAUREA MAGISTRALE IN INGEGNERIA DEL CINEMA E DEI MEZZI DI COMUNICAZIONE
INTEGRAZIONE DI CONTENUTI DI TIPO SEMANTICO
NEL SISTEMA DOCUMENTALE DOQUI
1
«Fear can hold you prisoner. Hope can set you free.» “The Shawshank Redemption” written and directed by Frank Darabont, 1994.
2
Ringrazio la mia fidanzata, nonché compagna di vita, per essermi stata sempre
vicino supportandomi e “sopportandomi” in questi ultimi anni di studio.
Ringrazio la mia famiglia per avermi dato questa possibilità e per avermi
assecondato in tutte le mie scelte.
3
INDICE
INTRODUZIONE .......................................................................................................................... 5
CAPITOLO 1 - IL WEB .................................................................................................................. 8
1.1 IL WORLD WIDE WEB ........................................................................................................ 9
1.2 IL SUCCESSO DEL WEB .................................................................................................... 10
1.3 FONDAMENTA DEL WEB ................................................................................................. 11
1.4 IL WEB DI IERI .................................................................................................................. 12
1.5 IL WEB DI OGGI ............................................................................................................... 12
1.5.1 Primo elemento: XML .............................................................................................. 13
1.5.2 Secondo elemento: Web Service ............................................................................. 14
1.5.3 Terzo elemento: Ajax ............................................................................................... 16
CAPITOLO 2 - LA LOGICA DEL SEMANTIC WEB ........................................................................ 17
2.1 INTRODUZIONE AL SEMANTIC WEB ............................................................................... 18
2.2 COS’È IL SEMANTIC WEB ................................................................................................. 18
2.2.1 Approfondimento sul Semantic Web secondo Tim Berners-Lee ............................. 20
2.3 LA PILA DEL SEMANTIC WEB ........................................................................................... 22
2.4 CHE COS’È UN’ONTOLOGIA ............................................................................................ 24
2.5 LE METROPOLITANE DEL SEMANTIC WEB ...................................................................... 25
CAPITOLO 3 - RDF E SPARQL .................................................................................................... 26
3.1 IL LINGUAGGIO RDF ........................................................................................................ 27
3.2 RDF DATA MODEL ........................................................................................................... 28
3.3 LA SINTASSI N3 ................................................................................................................ 30
3.4 LA SINTASSI RDF/XML ..................................................................................................... 31
3.5 RDF SCHEMA ................................................................................................................... 32
3.5.1 Esempio di un RDF Schema ...................................................................................... 34
3.6 RDF OLTRE XML ............................................................................................................... 36
3.7 SPARQL ............................................................................................................................ 37
3.7.1 Le path expression ................................................................................................... 38
3.7.2 Output di una query in formato XML ....................................................................... 41
3.7.3 Framework SPARQL .................................................................................................. 43
4
CAPITOLO 4 - DOQUI ................................................................................................................ 44
4.1 CHE COS'È DOQUI ........................................................................................................... 45
4.2 OBIETTIVI ......................................................................................................................... 45
4.3 INNOVAZIONE ................................................................................................................. 46
4.3.1 L’approccio alla gestione documentale ................................................................... 47
4.3.2 Il modello di sviluppo ............................................................................................... 48
4.3.3 Le scelte tecnologiche .............................................................................................. 48
4.4 COMPONENTI DEL SISTEMA ........................................................................................... 48
4.5 STRUTTURA DOQUI ......................................................................................................... 50
CAPITOLO 5 - DEFINIZIONE DEL PROBLEMA ........................................................................... 52
5.1 OBIETTIVI GENERALI ....................................................................................................... 53
5.2 CASO DI STUDIO .............................................................................................................. 54
5.3 REALIZZAZIONE INTERFACCIA ......................................................................................... 55
CAPITOLO 6 - VERSIONE BASATA SU RDF E SPARQL .............................................................. 58
6.1 TIPOLOGIA DI INFORMAZIONI ........................................................................................ 59
6.2 MODELLO ........................................................................................................................ 60
6.3 TOOLKIT SPARQL ............................................................................................................. 63
6.3.1 Impostazioni iniziali .................................................................................................. 63
6.3.2 Requisiti del database .............................................................................................. 63
6.3.3 Esempio di query utilizzate ...................................................................................... 64
CAPITOLO 7 - VERSIONE BASATA SU INDEX ............................................................................ 67
7.1 PRIMO APPROCCIO AD INDEX ........................................................................................ 68
7.2 DUE POSSIBILI SOLUZIONI ............................................................................................... 70
7.3 SOLUZIONE ADOTTATA ................................................................................................... 71
7.4 CUSTOM CONTENT MODEL ............................................................................................ 74
CAPITOLO 8 - VALUTAZIONI .................................................................................................... 78
8.1 CONFRONTI ..................................................................................................................... 79
CONCLUSIONI ........................................................................................................................... 84
GLOSSARIO ............................................................................................................................... 87
BIBLIOGRAFIA ........................................................................................................................... 93
SITOGRAFIA .............................................................................................................................. 94
5
INTRODUZIONE
INTRODUZIONE
6
L’esplosione del fenomeno del Web 2.0 ha da un lato portato alla luce una serie di nuove
modalità di interazione e di potenzialità abilitate dal Web, dall’altro ha mostrato come
l’evoluzione del Web sia un continuo work in progress. Per fare in modo che il Web
raggiunga le sue piene potenzialità è necessario puntare ad un ulteriore avanzamento
tecnologico che porti il Web ad essere, da uno spazio di semplice condivisione di documenti
pensati per la fruizione da parte delle persone, una piattaforma per la pubblicazione e il
recupero di dati strutturati attraverso processi logici ed elaborazioni automatiche da parte
delle macchine.
Questa parte dell’evoluzione del Web sta accadendo in questi anni e si concretizza nel
Semantic Web. Riportando le parole pronunciate da Tim Berners-Lee, co-inventore insieme a
Robert Cailliau del World Wide Web, in occasione del suo intervento intitolato “The next
Web of open, linked data” al TED 20091, “la nostra vita è costellata di dati e informazioni che
in gran parte già mettiamo sul Web: perché non fare in modo che questi dati pubblicati sul
Web siano ‘semanticamente’ connessi, così da abilitare nuove applicazioni e creare nuove
opportunità?”.
Questa tesi ha per oggetto proprio l’approfondimento e la ricerca riguardo le logiche della
semantica ed ha previsto lo sviluppo di una componente prototipale CMS (Content
Management System), vale a dire un’interfaccia Web studiata per facilitare la gestione di
determinati contenuti da parte di eventuali amministratori, svincolandoli da conoscenze
tecniche di programmazione. Tale componente va ad integrarsi nell'architettura DoQui, un
sistema di gestione di documenti pubblici in formato digitale, nato dalla collaborazione fra
Regione Piemonte, Comune e Provincia di Torino, a supporto dei procedimenti amministrativi
degli Enti. L’interesse pubblico dedicato alla piattaforma DoQui deriva dalla consapevolezza
circa le potenzialità di gestione documentale ai fini amministrativi tali da permettere
l’ottimizzazione di tempi ed il miglioramento delle modalità di organizzazione, archiviazione
e condivisione di documenti in formato digitale a livello regionale.
A tal fine l’obiettivo principale del progetto di tesi è stato comprendere innanzitutto se
DoQui permetta di gestire e utilizzare i dati in modo semantico e successivamente
individuare il modo tecnologicamente migliore per poterlo effettuare.
Il progetto è stato seguito e realizzato in collaborazione con TRIM s.r.l., una società torinese
solida e dinamica, formata da un team di 15 ingegneri che, lavorando con una propria
metodologia, progettano e realizzano applicazioni web e soluzioni di gestione documentale
in maniera rapida ed efficace utilizzando principalmente tecnologie Java.
TRIM s.r.l con questo progetto ha inteso approfondire un aspetto tecnologico
all’avanguardia su cui un sempre maggior numero di applicazioni basa le sue tecniche vale a
dire il Semantic Web. L’approccio semantico al World Wide Web intende trasformare
quest’ultimo in un ambiente in cui i documenti, come le pagine html, le immagini, i file, etc.,
1 TED 2009, è un insieme di eventi organizzati su scala mondiale dove si incontrano i più grandi leader del
mondo nel campo della technology, dell’entertainment e del design.
INTRODUZIONE
7
vengano associati a informazioni e metadati in modo da renderne possibile l’interrogazione
e interpretazione automatizzata attraverso logiche inferenziali di tipo semantico.
Con il Semantic Web saranno possibili ricerche più evolute e più ramificate grazie a relazioni
e connessioni tra documenti basate su logiche più elaborate del semplice link ipertestuale. In
tal contesto, per la descrizione delle informazioni, negli ultimi anni, ha ricevuto sempre più
attenzione e si è diffuso notevolmente il modello RDF (Resource Description Framework), e
proprio per tale ragione la ricerca da me effettuata si è soffermata sullo studio di questo
modello e sulla possibilità di impiego del Semantic Web nella progettazione del componente
CMS.
Il presente lavoro è strutturato in due parti. La prima parte inizia illustrando i principi
architetturali del Web che sono stati indispensabili per capire meglio sia l’evoluzione degli
ultimi anni del Web, sia il ruolo che rivestono le sue tecnologie. Segue approfondendo le
principali logiche del Semantic Web attraverso la presentazione dell’RDF, il modello
relazionale dei dati per il Web, con le sue sintassi e le sue modalità di interrogazione
specifiche, presentando quindi il linguaggio SPARQL. La prima parte, dunque, si propone di
gettare le fondamenta su cui proseguire il percorso di approfondimento.
La seconda parte presenta il progetto realizzato partendo dal problema iniziale, affrontando
le possibili soluzioni e giungendo alle considerazioni finali. Il progetto nello specifico ha
comportato la realizzazione di un’applicazione Web per gestire dati relativi ai menu per
ristoranti, dati che a livello back-end dovevano essere trattati con le logiche della semantica.
Il problema da affrontare nasce da una domanda cruciale per lo sviluppo stesso del progetto:
“È possibile utilizzare Index per rappresentare i dati in modo semantico?”
Da qui la decisione di realizzare a livello back-end due versioni del progetto, una prima
basata su un’applicazione Web che si interfacci a DoQui e nella fattispecie ad Index, il
motore di gestione dei contenuti digitali di DoQui, cercando di rappresentare i dati in modo
semantico; ed una seconda versione, utilizzata come modello per il confronto, basata sulla
stessa applicazione Web ma che in questo caso si interfacci su un EndPoit SPARQL per
effettuare interrogazioni su dati di tipo semantico.
Realizzare due versioni del progetto a livello beck-end ha permesso di giungere a delle
valutazioni conclusive che chiudono la seconda parte e riassumono i principali risultati di
questo interessate progetto di ricerca.
8
CAPITOLO 1
IL WEB
CAPITOLO 1 – IL WEB
9
1.1 IL WORLD WIDE WEB
Le tecnologie del World Wide Web2 sono continuamente in evoluzione, un’evoluzione
direttamente proporzionale alla nascita di nuovi business, difatti nuove esigenze portano
allo sviluppo di nuove soluzioni tecnologiche.
La nascita del Web risale al 6 agosto 1991, giorno in cui Tim Berners-Lee3 mise on-line il
primo sito web che inizialmente venne utilizzato esclusivamente dalla comunità scientifica
per usi personali. Il 30 aprile 1993 il CERN4 decise di rendere pubblica tale tecnologia,
decisione a cui seguì un immediato successo del Web che portò ad una crescita esponenziale
di Internet5 ancora oggi in atto e alla nascita della cosiddetta "era del Web".
La prima era del Web fu caratterizzata da un universo di informazioni accessibili via rete
fatto dalle persone per le persone, Internet era costituito dai cosiddetti “siti vetrina”, siti
statici, che rappresentavano la soluzione più semplice ed immediata per essere presenti su
internet. Questi potevano essere considerati una sorta di biglietto da visita on-line per
presentare le informazioni di carattere generale di aziende ed organizzazioni: il loro profilo,
la descrizione dei servizi offerti, l'ubicazione della sede dell'attività e tutti i recapiti per i
contatti.
Il Web di oggi, la seconda era, è un Web fondato su siti dinamici, così chiamati perché
presentano contenuti redatti dinamicamente. I siti Web dinamici sono caratterizzati infatti
da un'alta interazione fra sito e utente; alcuni elementi che caratterizzano la dinamicità di un
sito possono essere: l'interazione con uno o più database, la presenza di moduli per l'invio di
email o altre operazioni su cui operano sempre più le macchine, pensiamo ai crawler6 dei
motori di ricerca o agli RSS feed7 generati da macchine per altre macchine, per le quali sono
state standardizzate tecnologie come XML e i Web Service, che saranno approfonditi nei
paragrafi successivi.
2 World Wide Web, traduzione letterale: “grande ragnatela mondiale”. Il Web è uno spazio elettronico e
digitale di Internet destinato alla pubblicazione di contenuti multimediali (testi, immagini, audio, video,
ipertesti, ipermedia, ecc.) nonché uno strumento per implementare particolari servizi come ad esempio il
download di software (programmi, dati, applicazioni, videogiochi, ecc.). Tale spazio elettronico e tali servizi
sono resi disponibili attraverso particolari computer di Internet chiamati server web. 3 Timothy John Berners-Lee (Londra, 8 giugno 1955) è un informatico britannico, co-inventore insieme a
Robert Cailliau del World Wide Web. 4 L'European Organization for Nuclear Research, più conosciuto come CERN (acronimo) , è il più grande
laboratorio al mondo di fisica delle particelle. Si trova al confine tra Svizzera e Francia alla periferia ovest
della città di Ginevra. 5 Internet è una rete di computer mondiale ad accesso pubblico attualmente rappresentante anche uno dei
principali mezzi di comunicazione di massa. 6 Un crawler (detto anche spider o robot), è un software che analizza i contenuti di una rete (o di un database)
in un modo metodico e automatizzato, in genere per conto di un motore di ricerca. I crawler solitamente
acquisiscono una copia testuale di tutti i documenti visitati e le inseriscono in un indice. 7 Feed RSS (detti anche flussi RSS), sono informazioni di qualunque tipo, relative ad un sito Internet, che un
utente può vedere con l'aiuto di un lettore apposito, nella stessa pagina, nella stessa finestra, senza dover
andare ogni volta nel sito principale.
CAPITOLO 1 – IL WEB
10
1.2 IL SUCCESSO DEL WEB
Il Web è al centro di un mutamento sociale ed economico di proporzioni epocali che ha
cambiato profondamente il nostro modo di interagire con la realtà. Il pattern cercare-
confrontare-scoprire-scegliere vale per un numero crescente di prodotti e servizi che
includono libri, brani musicali, film, amicizie, rapporti di lavoro e persino prodotti che noi
stessi possiamo desiderare di mettere in vendita sui siti come eBay8.
La novità fondamentale è che ciascuno può avere un ruolo attivo nel Web: può non solo
consumare ogni genere di servizio, ma anche crearne scrivendo il proprio blog, contribuendo
a wikipedia9, condividendo le proprie foto e i video su Flickr10 e YouTube11, persino
combinando i vari servizi su Yahoo!12, Pipes13 e Openkapow14.
Per la prima volta dall’invenzione dei mass media, tutti noi, utenti comuni, possiamo far
sentire la nostra voce e raccontare a nostro modo il mondo, questo è il fenomeno dell’User
Generated Content (UGC). Si tratta di una nuova modalità di guardare al Web ed ai mass
media in generale, grazie a tutta una serie di innovazioni tecnologiche è stato reso possibile
un nuovo approccio esperienziale al Web: gli elementi chiave di questa nuova visione sono
infatti la dimensione sociale, la possibilità di condivisione, la possibilità per ciascuno di
essere autore di contenuti. Tali cambiamenti sono derivati non tanto da innovazioni
meramente tecnologiche, molte delle quali preesistevano infatti al Web 2.0 (il Web della
seconda era), quanto dalla modalità di utilizzo delle stesse e dall’uso che ne viene fatto da
parte di utenti non esperti. Mentre durante la prima era del Web i contenuti venivano diffusi
e pubblicati on-line solo da parte di utenti esperti nella realizzazione di siti Web, con il web
2.0 anche l’utente inesperto ha la possibilità di contribuire all’ampliamento dei contenuti sul
Web. Da dinamiche di dialogo unicamente top-down, si è passati infatti a dinamiche anche
bottom-up attraverso cui i ruoli, prima statici, di produttore e consumatore di contenuti,
vengono oggi continuamente scambiati e rinegoziati.
Il Web 2.0 rappresenta la concretizzazione di gran parte delle aspettative dei creatori del
Web, poiché questo costituisce una realtà realmente accessibile a tutti gli utenti: la
possibilità di disporre di servizi a basso costo in grado di consentire l'editing anche per
8 eBay è una piattaforma che offre ai propri utenti la possibilità di vendere e comprare oggetti sia nuovi che
usati, in qualsiasi momento, da qualunque postazione Internet e con diverse modalità, incluse le vendite a
prezzo fisso e a prezzo dinamico, comunemente definite come "aste online". 9 Wikipedia è una enciclopedia multilingue collaborativa, online e gratuita.
10 Flickr è un sito web multilingua che permette agli iscritti di condividere fotografie personali con chiunque
abbia accesso a Internet. 11
YouTube è un sito web che consente la condivisione di video tra i suoi utenti. 12
Yahoo! è una società fornitrice di servizi internet rivolta al mondo business e consumer (motore di ricerca,
mail, messenger e chat). 13
Pipes, un aggregatore e manipolatore interattivo di feed. 14
Openkapow, permette appunto di “fondere” più servizi insieme grazie alle API fornite dagli sviluppatori. Si
basa sul principio della fruizione di moduli già precompilati e la modifica collettiva di mash-up, ovvero
applicazioni che usano contenuti di più sorgenti per crearne uno completamente nuovo.
CAPITOLO 1 – IL WEB
11
l'utente poco evoluto, rappresenta un importante passo verso un'autentica interazione e
condivisione in cui il ruolo dell'utente è centrale.
1.3 FONDAMENTA DEL WEB
Il Web, secondo Tim Berners-Lee, per diventare un universo di informazioni accessibile
tramite la rete avrebbe dovuto rispondere ai due seguenti requisiti:
1. Adattarsi alla natura frattale della società;
2. Favorire e supportare l’invenzione indipendente.
Per natura frattale si intende la caratteristica di molti fenomeni di ripetersi nella loro
struttura allo stesso modo su scale diverse, mentre per natura frattale della società si
intendono le reti di relazioni; pertanto il Web per adattarsi a tale natura deve permettere
agli utenti di essere liberi di stabilire legami fra punti arbitrariamente distanti nello spazio
informativo.
Se si ammette la natura frattale della società, allora è naturale anche ammettere che le
stesse idee possano venire indipendentemente a diversi innovatori. Pertanto, nessuno può
essere il più bravo, per ogni versione di una idea ne esisterà certamente almeno un’altra e
prima o poi queste dovranno interoperare.
La natura del Web si compone di tre soli elementi:
1. Un meccanismo per identificare ogni risorsa, comprese le risorse fisiche al di fuori
dello spazio informativo, per esempio un codice ISBN15 può essere usato per
identificare un libro.
2. Un protocollo per:
a) deferenziare tali identificativi e ottenere una rappresentazione della risorsa; si
parla di rappresentazione perché l’operazione di deferenziazione non restituisce la
risorsa ma una sua rappresentazione digitale, ad esempio un’immagine digitale è
una rappresentazione di una persona fisica.
b) negoziare una specifica rappresentazione della risorsa tra le rappresentazioni
alternative disponibili. Ciò consiste nell’invio di un’insieme di prefernze da parte
del richiedente nel tentativo di fornire la rappresentazione che meglio soddisfa tali
richieste.
3. Un linguaggio ipermediale per rappresentare le risorse, che consenta di mixare testo
strutturato con rappresentazioni multimediali, ma soprattutto di collegare le diverse
risorse tramite iperlink.
15
L'ISBN (International Standard Book Number), è un numero che identifica a livello internazionale in modo
univoco e duraturo un titolo o una edizione di un titolo di un determinato editore. Oltre a identificare il
libro, si attribuisce a tutti quei prodotti creati per essere utilizzati come libro.
CAPITOLO 1 – IL WEB
12
Questi sono gli elementi fondamenta del Web, nei successivi paragrafi analizzo questi tre
elementi nel Web di ieri e introduco le nuove tecnologie che si sono aggiunte nel Web di
oggi.
1.4 IL WEB DI IERI
La prima e più importante soluzione introdotta nel Web è rappresentata dalle URI (Uniform
Resourse Identifier), che sono stringhe opache in grado di identificare qualsiasi risorsa sul
Web. Queste sono dette opache poiché non intendono assegnare nessun significato globale
alla stringa: questa deve essere trattata solo come sequenza di caratteri capaci di
identificare una risorsa.
La seconda soluzione tecnologica introdotta nel Web e che ha ancora un ruolo dominante, è
il protocollo di deferenziazione e negoziazione HTTP (HyperText Transfer Protocol), un
protocollo di tipo Request-Response per architetture Client-Server.
Per implementare la terza soluzione tecnologica dell’architettura del Web (ovvero un
linguaggio ipermediale per le risorse), Tim Berners-Lee propose nel 1989 il linguaggio HTML
(HyperText Markup Language) che inizialmente si evolse in molti dialetti proprietari di
differenti browser16 scatenando quella che negli anni novanta venne chiamata la guerra dei
browser e che cessò solo quando questi si resero conto che i primi a perderci erano proprio
loro in quanto imponevano ai programmatori di siti Web una scelta su quale dialetto
utilizzare e limitavano gli utenti, che con un solo browser, non avevano la possibilità di
visualizzare qualsiasi pagina.
Le URI, l’HTTP e l’HTML hanno consentito a milioni di imprese, organizzazioni di pubblicare
milioni di risorse tra loro connesse tramite link.
1.5 IL WEB DI OGGI
Lo scoppio della bolla17 dot-com18 nel 2001 ha segnato un vero e proprio punto di svolta
nella storia del Web, si è trattato di una bolla speculativa che dal ’95 al 2001 ha visto i
16
Un browser web (in italiano: navigatore) è un programma che consente agli utenti di visualizzare e interagire
con testi, immagini e altre informazioni, tipicamente contenute in una pagina web di un sito (o all'interno di
una rete locale). Il browser è in grado di interpretare il codice HTML (e più recentemente XHTML) e
visualizzarlo in forma di ipertesto. L'HTML è il codice col quale la maggioranza delle pagine web nel mondo
sono composte: il web browser consente perciò la navigazione nel web.
17 Si definisce bolla speculativa una particolare fase di un qualsiasi mercato caratterizzata da un aumento
considerevole e ingiustificato dei prezzi, dovuto ad una crescita della domanda repentina e limitata nel
tempo. Quando il valore dei titoli scende repentinamente e si assiste a un cambiamento radicale delle
prospettive economiche retrostanti, si parla di scoppio della bolla speculativa.
18 Con Dot-com si definiscono quelle società di servizi che sviluppano la maggior parte del proprio business
tramite un sito internet. Il nome deriva dal diffuso utilizzo, da parte di queste, di siti appartenenti al
CAPITOLO 1 – IL WEB
13
mercati azionari occidentali, aumentare rapidamente la crescita di Internet. Il periodo è
stato caratterizzato dalla fondazione, e spesso da un’altrettanto rapido fallimento, di
numerose società operanti nell’ambito del Web e per questo conosciute come ‘.com’ (che si
legge ’dot-com’). Fattori quali rapida crescita delle quotazioni in borsa, speculazioni,
immissioni di capitale a rischio e fragili strutture industriali e di marketing, portarono a una
serie di ripetuti fallimenti.
In molti hanno sperato che il Web fosse sopravalutato e che il vecchio modo di produrre
pacchetti software non avrebbe continuato ad avere successo. Invece, le crisi sono una
caratteristica comune delle innovazioni dirompenti poiché segnano il momento in cui le
tecnologie nuove sono pronte a soppiantare quelle esistenti. Così il Web, dopo la bolla del
2001, continua a evolversi, arricchendosi di nuove tecnologie.
Le nuove tecnologie del Web di oggi che si sommano a quelle che sono le sue fondamenta,
sono tre:
o Il linguaggio XML;
o I Web Service;
o Il linguaggio AJAX.
1.5.1 Primo elemento: XML
Il W3C (World Wide Web Consortium)19, propone nel 1998 l’XML (eXtensible Markup
Language)20, un mezzo per supportare lo scambio di dati strutturati attraverso il Web.
L’aspetto più interessante di questo standard è che non istituisce un nuovo linguaggio, ma si
limita a fornire un insieme di specifiche per definire nuovi linguaggi estensibili e per questo
motivo si parla spesso di linguaggi basati su XML piuttosto che di linguaggio XML.
dominio di primo livello (.com). Le Dot-com impostarono un business improntato principalmente
all'erogazione di servizi via web, queste aziende, eccessivamente fiduciose nelle potenzialità della rete,
durante la fine del ventesimo secolo, s'illusero di potersi facilmente espandere, ma si trovarono, in molti
casi, a dover fare i conti con la mancanza di idee innovative, di esperienza e di capacità gestionali. Proprio
per questo le Dot-com furono le protagoniste, in negativo, della bolla speculativa della new-economy
all'inizio degli anni 2000, quando, numerose di esse, fallirono generando una vera e propria recessione della
New Economy.
19 W3C è un consorzio che sviluppa tecnologie (specifiche, linee guida, software, e strumenti) per portare il
Web al massimo del suo potenziale, definendo protocolli comuni che ne favoriscano l’evoluzione e
assicurino l’interoperabilità. 20
XML è un metalinguaggio di markup, ovvero un linguaggio marcatore che definisce un meccanismo sintattico
che consente di estendere o controllare il significato di altri linguaggi marcatori. Rispetto all'HTML, l'XML ha
uno scopo ben diverso: mentre il primo definisce una grammatica per la descrizione e la formattazione di
pagine web e, più in generale, di ipertesti, il secondo è un metalinguaggio utilizzato per creare nuovi
linguaggi, atti a descrivere documenti strutturati. Mentre l'HTML ha un insieme ben definito e ristretto di
tag, con l'XML è invece possibile definirne di propri a seconda delle esigenze.
CAPITOLO 1 – IL WEB
14
Per definire un linguaggio basato su XML si utilizza uno dei due linguaggi di schema standard:
DTD(Document Type Definition) o XSD (XML Schema). Entrambi permettono di definire:
1. i nomi degli elementi;
2. i nomi degli attributi;
3. come questi possono essere combinati in strutture ad albero complesse;
4. quali parti della struttura sono opzionali;
5. quali tipi di valori possono assumere gli attributi e gli elementi foglia, vale a dire
quegli elementi che non contengono altri elementi.
XSD in aggiunta permette anche di distinguere tra il nome di un elemento e il suo tipo in
modo da realizzare gerarchie di tipi come nei linguaggi di programmazione Object-Oriented e
rendere ancora più estensibili i linguaggi basati su Xml.
Con XSD e XML è possibile definire un nuovo linguaggio integrando linguaggi già definiti.
Questa modularità solleva il rischio di conflitti tra linguaggi diversi che utilizzano lo stesso
nome per elementi o attributi differenti. Per ovviare a questo problema sono stati introdotti
i namespace che permettono di associare URI diverse a nomi identici definiti in XSD
differenti.
Un esempio di utilizzo di XML è dato dagli RSS che rappresentano una delle estensioni più
significative alle tecnologie base del Web e che consentono di collegarsi non solo ad una
pagina ma di “abbonarsi” ad essa ricevendo un avviso ogni volta che la pagina viene
aggiornata. Rich Skrenta21 lo definisce “Web incrementale”, altri lo chiamano “Live Web”.
1.5.2 Secondo elemento: Web Service
Il secondo elemento che abilita l’interazione machine-to-machine sul Web è costituito dai
Web Service; un Web Service è un insieme di protocolli e standard utilizzati per lo scambio
dei dati tra applicazioni e sistemi. Applicazioni scritte in vari linguaggi di programmazione e
che funzionano su differenti piattaforme possono utilizzare i Web Service per comunicare
attraverso le reti, come Internet, in un modo simile alla comunicazione tra diversi processi
che sono attivi su uno stesso computer.
Caratteristica fondamentale di un Web Service è quella di offrire un'interfaccia software
utilizzando la quale altri sistemi possono interagire con il Web Service stesso attivando le
operazioni descritte nell'interfaccia tramite appositi “messaggi” inclusi in una “busta” (la più
famosa è SOAP): tali messaggi sono, solitamente, trasportati tramite il protocollo HTTP e
formattati secondo lo standard XML.
21
Rich Skrenta, noto informatico statunitense, divenne famoso perché, a soli quindici anni, creò l'Elk Cloner,
un virus informatico (probabilmente il primo della storia del computer) che infettava il sistema Apple II
tramite floppy disk. Grazie a questo gesto, Richard Skrenta entrò di diritto nella storia dell'informatica, in
quanto fece capire innanzitutto la vulnerabilità del sistema Apple, ed anche che i "virus" di cui tanto
parlavano gli scrittori non erano solo fantascienza.
CAPITOLO 1 – IL WEB
15
Questa caratteristica dei Web Service è estremamente utile se si considera che possono
essere trovati utilizzando l'UDDI (Universal Description, Discoverey and Integration), un
servizio di directory disponibile sul Web dove gli interessati possono registrare e cercare
servizi web. L'interfaccia pubblica di un Web Service viene descritta tramite WSDL (Web
Services Description Language) un linguaggio basato su XML usato per la creazione di
“documenti” descrittivi delle modalità di interfacciamento ed utilizzo del Web Service.
Tutti i dati scambiati sono formattati mediante “tag” XML in modo che gli stessi possano
essere utilizzati ad entrambi i capi delle connessioni.
Figura 1 - Pila protocollare dei Web Service.
Un documento WSDL è caratterizzato da quattro elementi principali:
o <types>
o <message>
o <portType>
o <binding>
Ecco un esempio della sua architettura:
<definitions>
<types>
<!-- definizione dei tipi di dato utilizzati -->
</types>
<message>
<!-- definizione di uno dei messaggi impiegati dal
web service per comunicare con l'applicazione client -->
</message>
<!-- naturalmente può esistere più di un elemento message
all'interno del documento -->
<portType>
<!-- definisce una “porta” e le operazioni che possono essere eseguite
CAPITOLO 1 – IL WEB
16
dal web service. Definisce inoltre i messaggi coinvolti nelle
operazioni elencate -->
</portType>
<binding>
<!-- definisce il formato del messaggio ed i
dettagli di protocollo per ogni porta -->
</binding>
</definitions>
1.5.3 Terzo elemento: Ajax
La soluzione tecnologicamente più avanzata del Web di oggi, che integra HTML, DOM,
JavaScript, XML e Web Service, è AJAX (Asynchronous JavaScript and XML)22 tecnologia
ampiamente impiegata in tutte le applicazioni Web 2.0 di successo ed in particolare nella
realizzazione dei Mush-up23: servizi ottenuti combinando dati e script provenienti da più
server in un’unica applicazione. I Mush-up più diffusi combinano servizi di mappe con altri
dati geografici.
Nel Web di ieri ad ogni click dell’utente veniva ricaricata l’intera pagina, con AJAX i click
dell’utente vengono intercettati da script che invocano il Web Service ottenendo nuovi dati e
modificando la pagina via DOM per presentare i risultati all’utente.
Tabella 1 - Differenze del Web tra ieri e oggi.
22
AJAX, è una tecnica di sviluppo per la realizzazione di applicazioni web interattive (Rich Internet Application).
Lo sviluppo di applicazioni HTML con AJAX si basa su uno scambio di dati in background fra web browser e
server, che consente l'aggiornamento dinamico di una pagina web senza esplicito ricaricamento da parte
dell'utente. AJAX è asincrono nel senso che i dati extra sono richiesti al server e caricati in background senza
interferire con il comportamento della pagina esistente. Normalmente le funzioni richiamate sono scritte
con il linguaggio JavaScript. Tuttavia, e a dispetto del nome, l'uso di JavaScript e di XML non è obbligatorio,
come non è necessario che le richieste di caricamento debbano essere necessariamente asincrone. 23
Mash-up, applicazioni che usano contenuti di più sorgenti per crearne uno completamente nuovo.
ELEMENTO WEB DI IERI WEB DI OGGI
Identificare URI URI
Dereferenziare HTTP 1.1 HTTP 1.1
Rappresentare HTML + CSS + DOM + SCRIPT.
Png, jpg,..
XML, XHTML, RSS,…
Png, jpg, mp3, mpeg,…
WSDL, SOAP, REST
17
CAPITOLO 2
LA LOGICA DEL SEMANTIC WEB
CAPITOLO 2 – LA LOGICA DEL SEMANTIC WEB
18
2.1 INTRODUZIONE AL SEMANTIC WEB
Ad oggi il Web è il maggior contenitore di conoscenza ed è quello più frequentemente
utilizzato da una larga varietà di persone per utilizzi e finalità diverse. Ma nel Web spesso
l’informazione ricercata dall’utente è dispersa tra più fonti informative, e sarebbe di grande
ausilio la possibilità che le macchine potessero autonomamente estrarre e dedurre
conoscenza. Le tecnologie del Semantic Web mirano appunto a questo obiettivo, infatti il
Semantic Web rappresenta la volontà di estendere e dare valore aggiunto al Web di oggi
attraverso la creazione di dati elaborabili e comprensibili direttamente dalle macchine
attraverso l’uso della logica e dei linguaggi di rappresentazione della conoscenza.
Oggi la maggior parte dei contenuti del Web è pensata per essere letta e fruita dagli esseri
umani, mentre moltissime attività e compiti potrebbero essere automatizzati se anche i
computer potessero accedervi e manipolare tali contenuti in maniera significativa. Il
Semantic Web ha l’obiettivo di dare una struttura ai contenuti delle pagine web creando le
condizioni per cui agenti e programmi software portino a termine sofisticati compiti per gli
utenti.
Il Gartner Group24 ha previsto un orizzonte per il Semantic Web di 20-25 anni il che proietta
nel 2027 la sua maturità, tuttavia si tratta di una proiezione pessimistica poiché di sicuro la
curva di adozione del Semantic Web da parte dell’intero sistema sarà meno lunga e meno
lenta del previsto.
2.2 COS’È IL SEMANTIC WEB
Ai suoi esordi Internet era costituito unicamente di testi e di indici ipertestuali e
caratterizzato dal fatto che la creazione della conoscenza era una prerogativa unicamente
dei produttori. Col passare del tempo le strutture dei siti si sono evolute, anche se per
l’utente questo è rimasto un aspetto quasi del tutto nascosto, ed hanno raggiunto livelli di
complessità sempre maggiore, tale da permettere a tutti gli utenti di poter contribuire alla
creazione della conoscenza on-line. Allo scopo di rendere reperibili per l’utente le
informazioni desiderate sono stati sviluppati i motori di ricerca, ovvero sistemi automatici
che, data una determinata chiave di ricerca, analizzano insiemi di dati e restituiscono un
indice dei contenuti disponibili classificandoli in base al grado di rilevanza.
In un motore di ricerca l’utente inserisce una o più parole che intende cercare e avvia la
ricerca. Il risultato è un insieme di collegamenti a siti internet che presentano nei loro
contenuti la o le parole cercate. L'efficacia dell'operazione dipende da due fattori, primo
dagli algoritmi che il motore di ricerca utilizza per estrarre i contenuti e secondo da come
sono stati indicizzati i contenuti del sito.
24
Gartner Group è una società di ricerca e consulenza con sede principale a Stamford, nel Connecticut, con
oltre 10.000 clienti nel mondo. L'attività principale consiste nel supportare le decisioni di investimento dei
suoi clienti attraverso ricerca, consulenza, benchmarking, eventi e notizie.
CAPITOLO 2 – LA LOGICA DEL SEMANTIC WEB
19
Nel caso dei motore di ricerca del Web 2.0 qualsiasi query25 attivata è sempre soggetta al
rischio dell’ambiguità. Per esempio cercando la parola “albero” si possono ottenere risultati
appartenenti a più svariati ambiti di interesse, quali quelli dell'informatica, della botanica,
della nautica, etc. L’ambiguità a cui è soggetta una query è dovuta al fatto che Internet è un
insieme di testi collegati tra loro ma con collegamenti deboli, nel senso che sono troppo
generici e vaghi. I collegamenti deboli non sono quelli sintattici anzi questi sono piuttosto
solidi, un link infatti localizza una risorsa attraverso un URL univoco. I collegamenti deboli
sono invece quelli legati alla capacità di descrivere il significato di un collegamento. Oltre a
“portare” in un determinato “luogo” un collegamento dovrebbe descrivere il “luogo verso
cui porta”. Il termine appropriato per parlare di questa funzione è appunto capacità
semantica. Quando si parla di Semantic Web si intende proporre un Web che possieda delle
strutture di collegamenti più espressive di quelle attuali.
Il termine 'Semantic Web' è stato proposto per la prima volta nel 2001 da Tim Berners Lee.
Da allora il termine è stato associato all'idea di un Web nel quale agiscono agenti
intelligenti: applicazioni in grado di comprendere il significato dei testi presenti sulla rete e
perciò in grado di guidare l'utente direttamente verso l'informazione ricercata, oppure di
sostituirsi a lui nello svolgimento di alcune operazioni. Un agente intelligente dovrebbe
essere una applicazione in grado di svolgere operazioni come la prenotazione di un aereo
per Parigi con arrivo in centro città prima delle 13.00. Il tutto analizzando gli arrivi ai diversi
aeroporti di Parigi (Paris, Charles de Gaule, Orly) e deducendo, senza che sia specificato nella
query, che un arrivo per le 13.00 in centro implichi un arrivo in aeroporto diverso.
Questa proposta ha affascinato molto la comunità informatica. Il W3C ha attivato
immediatamente un gruppo di lavoro e le università hanno aperto numerosi programmi di
ricerca legati a questi temi. Si sono imposti subito degli standard, il più famoso dei quali è
certamente RDF(S), un linguaggio in sintassi XML per definire e esprimere ontologie26.
In definitiva, la visione del Semantic Web è un’estensione dei principi del Web dai documenti
ai dati: le persone rendono i loro dati disponibili agli altri e aggiungono collegamenti ad altri
dati per permetterne il ritrovamento. A questo proposito, è utile illustrare la differenza tra
information retrieval e data retrieval. Mentre il primo ha come scopo il recupero dei
documenti rilevanti rispetto ad una richiesta, il secondo si prefigge di trovare la corretta
risposta a una domanda. In questo senso, i dati hanno un valore e una rilevanza molto
maggiore rispetto ai documenti e la possibilità di fare data retrieval incrementerebbe
notevolmente il potenziale del Web. E proprio questo è l’obiettivo del Semantic Web:
passare da un Web di documenti, fatto dalle persone per le persone, ad un Web dei dati cui
possono accedere anche le macchine.
25
Il termine query in informatica viene utilizzato per indicare l’interrogazione ad un database in modo da
ottenere come risultato dei dati contenuti in uno o più database. 26
L’ontologia descrive il modo in cui diversi schemi vengono combinati in una struttura dati contenente tutte
le entità rilevanti e le loro relazioni in un dominio. I programmi informatici usano l’ontologia per una varietà
di scopi, tra cui il ragionamento induttivo, la classificazione e svariate tecniche per la risoluzione di
problemi.
CAPITOLO 2 – LA LOGICA DEL SEMANTIC WEB
20
Figura 2 - Il Semantic Web.
La figura mostra come nel Web 1.0 fossero solo i produttori artefici della creazione della
conoscenza on-line, nel Web 2.0 invece il consumatore assume lo stesso ruolo del
produttore, quindi nuovo generatore di conoscenza, infine nel Semantic Web gli agenti
intelligenti, attingendo alle diverse conoscenze create nel Web, ne generano di nuove.
2.2.1 Approfondimento sul Semantic Web secondo Tim Berners-Lee
In un famosissimo articolo apparso sulla rivista Scientific American nel maggio del 2001, Tim
Berners-Lee, insieme a James Hendler e Ora Lassila, danno una definizione del Semantic
Web:
“The Semantic Web is not a separate Web but an extension of the current one, in which
information is given well-defined meaning, better enabling computers and people to work in
cooperation.”
Tre sono i punti chiave di questa definizione: il Semantic Web è un’estensione del Web
attuale, quindi può essere concretizzato partendo da quello che già esiste e che tutti
conosciamo e utilizziamo quotidianamente; lo scopo del Semantic Web è la cooperazione tra
computer e persone, in modo che le macchine possano essere maggiormente di supporto
agli esseri umani nell’esecuzione e nell’automazione di compiti; la realizzazione del Semantic
Web è possibile solo dando un significato ben definito all’informazione, in modo che le
macchine possano raggiungere quel grado di “comprensione” che abilita funzionalità
avanzate di ragionamento e capacità di rispondere a domande complesse.
CAPITOLO 2 – LA LOGICA DEL SEMANTIC WEB
21
Figura 3 - L'uso delle ontologie nello scenario dell'articolo del 2001.
Per meglio illustrare cos’è il Semantic Web, l’articolo illustra uno scenario realistico, come
mostra bene la figura, in cui Pete e Lucy, due figli premurosi di una donna che ha bisogno di
fisioterapia, si affidano ai loro agenti software intelligenti per trovare un opportuno
terapista, adatto a effettuare il trattamento prescritto dal medico alla madre. Per soddisfare
i loro bisogni questo terapista deve essere conosciuto per professionalità e affidabilità; il suo
ambulatorio non deve essere troppo lontano dalla loro abitazione; le sue prestazioni devono
rientrare tra quelle coperte dall’assicurazione medica. Gli agenti software che usano le
tecnologie del Semantic Web sono in grado non solo di portare a termine il compito di
trovare un fisioterapista adatto, ma anche di offrire la possibilità di raffinare la ricerca per
avere più alternative, di confrontare l’appuntamento dello specialista con gli appuntamenti
nell’agenda di Pete (che deve accompagnare la madre alle sedute) e anche di spiegare
all’utente il perché della selezione di un certo risultato.
Per raggiungere lo stesso risultato oggi, Pete e Lucy dovrebbero compiere manualmente un
certo numero di ricerche, con il rischio di non riuscire a trovare tutte le possibili e migliori
alternative e con la certezza di dover impiegare molto più tempo a districarsi tra sistemi e
linguaggi diversi. Il Web odierno, infatti, è una fenomenale e smisurata fonte di informazioni
la cui cernita, manuale o mediata dai motori di ricerca, implica uno sforzo da parte
dell’utente tale da scoraggiare anche il solo tentativo. Lo scenario che può sembrare molto
CAPITOLO 2 – LA LOGICA DEL SEMANTIC WEB
22
futuristico è un’efficace rappresentazione delle potenzialità del Semantic Web, ovvero di
quello che si può ottenere aggiungendo logica al Web.
2.3 LA PILA DEL SEMANTIC WEB
Il Semantic Web è un’estensione del Web attuale, quindi può essere concretizzato partendo
da quello che già esiste e che tutti conosciamo ed utilizziamo quotidianamente; lo scopo del
Semantic Web è la cooperazione tra computer e persone in modo che le macchine possano
essere maggiormente di supporto agli esseri umani nell’esecuzione ed automazione di
compiti; la sua realizzazione è infatti possibile solo dando un significato ben definito
all’informazione in modo tale che le macchine possano raggiungere quel grado di
“comprensione” che abilita funzionalità avanzate di ragionamento e capacità di rispondere a
domande complesse.
Per meglio illustrare cosa serve per la realizzazione del Semantic Web e per renderlo
sistematico, Tim Berners-Lee ed i ricercatori del W3C hanno definito la cosiddetta pila del
Semantic Web. Come spesso accade in informatica è sempre bene definire una pila di
protocolli che stabilisca i diversi livelli necessari a completare un’implementazione o un
sistema di comunicazione in modo che il problema sia “modularizzato” a livelli, a ciascuno
dei quali venga associato uno standard opportuno.
Figura 4 - Pila del Semantic Web.
Tale standardizzazione col passare degli anni ha subito delle revisioni dovendo aggiornarsi
rispetto alla crescente standardizzazione dei linguaggi di programmazione e delle contestuali
innovazioni tecnologiche.
L’immagine riportata rappresenta la pila che ha riscosso i maggiori favori dalla comunità del
Semantic Web negli ultimi tempi.
CAPITOLO 2 – LA LOGICA DEL SEMANTIC WEB
23
Partendo dall’alto si ha un livello che non è parte integrante della pila, si tratta dello strato
delle applicazioni e delle interfacce utenti (1); queste possono essere costruite sulla base
dell’insieme delle tecnologie sottostanti. Il livello più alto di tali tecnologie è rappresentato
da Trust (2) che ha il compito di distinguere i dati affidabili da quelli non affidabili dato il
grande quantitativo di informazioni presenti in rete. L’affidabilità dei dati può essere
“esplicita” oppure “inferita”27 a partire da dati esistenti da parte di agenti intelligenti che si
basano sulla tecnologia del Semantic Web. Nel caso di “affidabilità derivata” è necessario
poter risalire ai meccanismi che hanno portato a stabilirne la bontà. A tale necessità
risponde il livello di Proof (3), vale a dire “la prova” che dimostra all’utente quale è stata la
logica sottostante il ragionamento e le relative conclusioni. Questo genere di prova è
raggiungibile solo sulla base solida della logica e quindi il livello sottostante al Proof è
rappresentato dalla cosiddetta logica unificante (4). Questa deve rispondere a due necessità:
abilitare la prova e permettere di definire e descrivere l’informazione stessa. Quali siano le
caratteristiche di questo linguaggio logico unificante non è stato ancora stabilito con
precisione perché i processi sono in continua e costante evoluzione: le logiche infatti
possono essere al contempo causali, temporali, descrittive e probabilistiche. Ciononostante
questa “logica” costituisce il cuore pulsante della pila.
La parte inferiore della pila è costituita da tutte le tecnologie atte ad esprimere
l’informazione ed a formalizzare la conoscenza su cui si intende abilitare il ragionamento
automatico. Partendo dal basso troviamo tecnologie e protocolli che sono il fondamento del
Web:
o Le URI (5) sono il meccanismo usato per identificare le risorse. I modelli per lo scambio
di dati e i linguaggi ontologici28 usano proprio le URI per identificare termini e concetti
rilevanti per codificare le informazioni. Queste infatti assicurano che ciascun concetto
non sia semplicemente una parola o una stringa in un documento ma sia collegato a
un’unica definizione che chiunque possa trovare sul Web.
o Unicode (6) è invece lo standard che permette alle macchine una rappresentazione
consistente ed una manipolazione omogenea dei caratteri testuali, si tratta di un
sistema di codifica che rende i caratteri indipendenti dalla piattaforma software, dalla
applicazione utilizzata e dalla lingua.
o XML (7) è un linguaggio di marcatura che permette di creare, definire e rendere
utilizzabili i propri Tag, rappresenta una sorta di meta-linguaggio. XML è il mezzo
migliore per l’interoperabilità sintattica ovvero la capacità dei sistemi di riuscire a
27
“Ciò che tuttavia pare caratterizzare questa prima categoria di segni è il rapporto dello “stare per” che si
regge su un meccanismo inferenziale: se rosso di sera, allora bel tempo si spera. È il meccanismo
dell’implicazione filoniana: pq.” tratto da Umberto Eco “Segno ed Inferenza” 1984, Einaudi editore, pg.4. 28
I linguaggi ontologici definiscono formalmente le relazioni tra termini, un’ontologia è il mezzo per descrivere
e definire la rappresentazione computazionale di quella parte del mondo che interessa modellare in un
programma o in una applicazione.
CAPITOLO 2 – LA LOGICA DEL SEMANTIC WEB
24
interpretare la sintassi e la struttura dei documenti scambiati ed in parte
l’interoperabilità strutturale, ovvero la possibilità di interpretare le strutture di
documenti di schemi logici differenti. XML non è sufficiente però a soddisfare
l’interoperabilità semantica ovvero quella capacità di interscambio di dati tra sistemi
basata sul significato stesso dell’informazione scambiata e non sul suo formato.
o RDF (8) rappresenta la possibilità di soddisfare anche l’interoperabilità semantica. In
questo modello relazionale di dati, il significato dell’informazione è codificato in insieme
di “triple” che corrispondono a frasi elementari costituite da tre elementi: soggetto,
predicato ed oggetto; identificabili attraverso URI.
o I linguaggi ontologici ad oggi più largamente adottati dalle comunità del Semantic Web
sono RDF Schema (9), che aggiunge un primo livello di logica al di sopra di RDF, ed OWL
(10) che tra le altre cose fornisce la possibilità di asserire relazioni di equivalenza tra le
risorse.
o Accanto ai linguaggi ontologici all’interno della pila, troviamo le regole che
rappresentano un meccanismo atto ad aumentare l’espressività e le funzionalità di
ragionamento automatico delle ontologie stesse, Rules: RIF (11).
o SPARQL (12) è un linguaggio di interrogazione su dati RDF ed allo stesso tempo un
protocollo che permette di effettuare tali richieste in ambiente Web.
o CRYPTO (13) indica la crittografia e firma digitale, rappresenta un tassello importante
per il raggiungimento di buoni livelli di affidabilità nel mondo del Web.
2.4 CHE COS’È UN’ONTOLOGIA
Secondo Rudi Studer29, Richard Benjamins e Dieter Fensel30 “un’ontologia è una
specificazione formale ed esplicita di una concettualizzazione condivisa”31.
Quindi ogni sistema di rappresentazione o gestione della conoscenza avrà sempre una
qualche concettualizzazione esplicita o implicita del suo dominio. Un’ontologia deve
riflettere la conoscenza di un gruppo, non può fare riferimento al pensiero di un singolo;
inoltre deve essere anche condivisibile cioè pubblica ed utilizzabile da parte della comunità.
Una concettualizzazione viene espressa attraverso un’indicazione dei concetti e delle
relazioni che tra essi sussistono, per esplicita si intende che tali concetti e tali condizioni
29
Rudi Studer, (nato nel 1951 in Stuttgart) è un informatico tedesco e professore all’Università di Karlsruhe,
Germania. 30
Dieter Fensel, (nato il 10 Ottobre 1960 in Nuremberg) è un ricercatore nel campo del linguaggio formale e
del semantic web. 31
Rudi Studer, Richard Benjamins e Dieter Fensel “Data & Knowledge Engineering” Volume 25, numero 1-2
(March 1998) - Pagine: 161 – 197.
CAPITOLO 2 – LA LOGICA DEL SEMANTIC WEB
25
debbano essere esplicitamente definiti, spiegati e chiariti in modo da non lasciare ambiguità.
La specificazione infine, deve essere anche formale ovvero espressa in un formato
elaborabile dai computer. Attraverso l’uso di ontologie le applicazioni riescono a mettere in
relazione l’informazione contenuta in una pagina con altre fonti di conoscenza, associandole
direttamente ed indirettamente attraverso l’utilizzo di dinamiche inferenziali.
2.5 LE METROPOLITANE DEL SEMANTIC WEB
La visione di Tim Berners-Lee sul Semantic Web è efficacemente rappresentata da una vivida
metafora presentata in figura.
Figura 5 - La metafora delle metropolitane.
Il Semantic Web è come una rete di metropolitane: le linee sono costituite da diverse
ontologie che descrivono e specificano diverse parti della realtà (nella figura: il tempo, i
luoghi, le persone e così via), mentre le diverse stazioni corrispondono alle applicazioni che si
possono creare sulla base di tali ontologie. Alcune di queste fermate della metropolitana
coinvolgono solo una linea, ovvero hanno bisogno di una sola ontologia; altre stazioni
rappresentano invece punti di interscambio delle varie linee, ovvero coinvolgono più
ontologie nel loro funzionamento. In questa visione i dati sul Web, o meglio i metadati
descritti rispetto a tali ontologie, sono i “convogli” della metropolitana che trasportano
l’informazione (i passeggeri) tra un’applicazione (una stazione) e l’altra. Da questa immagine
metaforica capiamo chiaramente la grande importanza che riveste la condivisione delle
ontologie nel Semantic Web, le ontologie infatti veicolano proprio il significato e la
conoscenza contenuti nei dati sul Web.
26
CAPITOLO 3
RDF E SPARQL
CAPITOLO 3 – RDF E SPARQL
27
3.1 IL LINGUAGGIO RDF
Secondo la proposta del W3C il set di linguaggi su cui costruire il web semantico è RDF
(Resource Description Framework), un set di linguaggi dichiarativi basati su sintassi XML.
Il Semantic Web nasce come tentativo di controllare le informazioni ancorandole ad uno
schema. Questa idea funziona se si dividono bene i compiti, da una parte si hanno i dati, da
un’altra uno schema che definisce come i dati si strutturano e relazionano fra loro.
I settori nei quali RDF può essere utilizzato e portare vantaggi sono i più disparati:
o descrizione del contenuto di un sito Web, di una pagina, di una biblioteca digitale;
o implementazione di intelligent software agent, per lo scambio di conoscenza e un
utilizzo migliore delle risorse Web;
o classificazione del contenuto, per applicare criteri di selezione;
o descrizione di un insieme di pagine, che rappresentano un singolo documento logico;
o stabilire i criteri di proprietà intellettuale delle singole pagine;
o esprimere criteri di privacy preference degli utenti e le privacy policies di un sito Web;
o con il meccanismo della digital signature32, contribuire alla creazione del Web of
Trust33, per le applicazioni nel commercio elettronico, la cooperazione;
o e molti altri ancora.
RDF è costituito da due componenti:
o RDF Model and Syntax: definisce il data model RDF e la sua codifica XML;
o RDF Schema: permette di definire specifici vocabolari per i metadati.
I metadati sono “dati che accompagnano i dati” ovvero “dati sui dati”. Il mondo a cui fare
riferimento per comprendere l’importanza dei metadati è quello dei sistemi per
l’organizzazione della conoscenza ( Knowledge Organization System o KOS ), che trovano
applicazioni in molti ambiti, primo fra tutti l’ambito delle catalogazioni bibliotecarie. Il
mondo dell’informazione on-line ha sviluppato sistemi di catalogazione e categorizzazione,
nonché sistemi di strutturazione e standardizzazione delle descrizione bibliografiche. Sono
così nate iniziative volte a proporre diversi sistemi (o KOS) per la catalogazione bibliografica;
il più rilevante è il sistema ideato dalla Dubline Core Initiative34. Tale sistema prevede la
definizione di un insieme di elementi che rappresentano i metadati necessari per descrivere
opportunamente risorse in rete. L’insieme base degli elementi essenziali ai fini della
descrizione di materiale digitale su cui è stato raggiunto il consenso era costituito
32
Digital signature, “firma digitale” in italiano, è basata sulla tecnologia della crittografia a chiave pubblica o
PKI. Dal punto di vista informatico rappresenta un sistema di autenticazione di documenti digitali tale da
garantire non ripudio. La nozione di firma digitale ha in Italia anche un'accezione giuridica, in quanto
individua quel tipo di firma che può essere apposta ai documenti informatici alla stessa stregua di come la
firma autografa viene apposta ai documenti tradizionali. 33
Web of Trust, “Web di fiducia” in italiano, è un concetto espresso da programmi che permettono di usare
autenticazione e privacy crittografica, per stabilire l’autenticità dell’associazione chiave-utente. 34
Il Dublin Core Initiative è un sistema di metadati costituito da un nucleo di elementi essenziali ai fini della
descrizione di qualsiasi materiale digitale accessibile via rete informatica.
CAPITOLO 3 – RDF E SPARQL
28
inizialmente da quindici elementi, successivamente si è esteso, esempio di qualche
elemento: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format.
Ad ogni elemento è stato attribuito un identificativo unico sotto forma di URI35, ad esempio
per denotare l’autore di una risorsa si utilizza l’elemento Creator, indicato dall’URI
http://purl.org/dc/elements/1.1/creator/.
3.2 RDF DATA MODEL
Per capire pienamente il modello RDF, prima di tutto pensiamo alla struttura delle risorse sul
Web: le pagine Web sono identificate dal loro indirizzo, l’URL36, e sono collegate tra loro
tramite i collegamenti ipertestuali (i link, in HTML indicati dall’attributo href con l’indicazione
dell’URL della risorsa collegata).
RDF ha l’obiettivo di definire un sistema per la descrizione delle risorse; come avviene per le
pagine Web: RDF prevede che ogni risorsa possa essere identificata univocamente e che a
ogni risorsa possano essere associati dei metadati descrittivi. RDF è quindi un linguaggio per
rappresentare e modellare le risorse in rete.
La struttura base di RDF è l’enunciato (in inglese statement), che esprime la struttura base
della descrizione di una risorsa. L’enunciato è formato da tre componenti:
o il soggetto, ovvero l’identificativo della risorsa;
o il predicato, che indica la proprietà o l’attributo del soggetto che si vuole descrivere;
o l’oggetto, ovvero il “valore” che il predicato assume in riferimento al soggetto.
Figura 6 - Rappresentazione grafica di un enunciato.
Per la sua struttura soggetto-predicato-oggetto l’enunciato viene anche semplicemente
chiamato tripla. Spesso RDF viene rappresentato mettendo in risalto il modello a grafo
orientato ed etichettato su cui si basa, in cui soggetto e oggetto sono i nodi e il predicato è
l’arco orientato.
35
URI (Uniform Resource Identifier), è il generico insieme di tutti i nomi/indirizzi che costituiscono le brevi
sequenze di caratteri che fanno riferimento ad una risorsa. 36
URL (Uniform Resource Locator), è una sequenza di caratteri che identifica univocamente l'indirizzo di una
risorsa in Internet, come un documento o un'immagine.
CAPITOLO 3 – RDF E SPARQL
29
Per poter rendere le descrizioni delle risorse elaborabili da parte delle macchine, le tre
componenti dell’enunciato non possono essere delle semplici stringhe, pertanto il modello
RDF prevede che queste vengano identificate univocamente attraverso le URI.
Ad esempio, l’enunciato “La pagina Web http://www.example.org/home ha per autore il
signor Rossi” nella rappresentazione RDF sarà così suddiviso:
o il soggetto: “La pagina Web”, identificabile univocamente dalla sua URL
http://www.example.org/home;
o il predicato: “ha per autore”, per la quale si può usare la definizione di Creator del
Dublin Core;
o l’oggetto: l’autore della pagina, “il signor Rossi”.
In questo caso soggetto e predicato hanno già un URI, mentre per identificare l’oggetto ci
sono due soluzioni:
o se l’oggetto dell’enunciato è a sua volta una risorsa, l’oggetto deve essere
rappresentato attraverso un’URI. Per esempio si può identificare “il signor Rossi”
attraverso l’URL http://staff.example.org/Rossi, così che possa poi essere utilizzata
come soggetto di altri enunciati che descrivono la sua persona;
o altrimenti se l’oggetto è solo un valore, ad esempio una stringa, un numero o una
data, si dice che l’oggetto della tripla è un letterale e dunque non sarà associato ad
alcuna URI.
Figura 7 - Fusione di enunciati RDF.
La descrizione RDF di una risorsa è quindi costituita dall’insieme degli enunciati che hanno
per soggetto tale risorsa. Queste triple sono logicamente legate dall’univocità degli
CAPITOLO 3 – RDF E SPARQL
30
identificativi; ma nulla vieta che i diversi enunciati siano fisicamente distribuiti su più
sorgenti dati (ad esempio memorizzati su file distinti). Quando le informazioni di una risorsa
provengono da diverse fonti, i rispettivi enunciati possono facilmente essere raccolti
insieme, indipendentemente dalla loro origine e locazione. Dalla figura è possibile capire
come due enunciati, riguardanti la stessa risorsa http://www.example.org/home, possano
essere uniti e come questa unione non crei ridondanze.
Il modello a grafo alla base di RDF risulta essere molto flessibile ed efficiente quando si tratta
di collezionare informazioni, di integrare dati che provengono da diverse fonti, di prevedere
diversi punti di vista sulla descrizione di una determinata risorsa. Gli enunciati (le triple
soggetto- predicato-oggetto) si dimostrano così un mezzo potente e allo stesso tempo
elementare.
3.3 LA SINTASSI N3
La rappresentazione più semplice degli enunciati è quella di scriverli per intero, ogni tripla
rappresentata come: URI del soggetto, spazio, URI del predicato, spazio, URI dell’oggetto o
rispettivo letterale, punto. Questa rappresentazione si chiama Notation3, detta anche N3.
La N3 introduce abbreviazioni e scorciatoie per rendere l’RDF più leggibile. In N3, come in
XML, è prima di tutto possibile definire i namespace utilizzati dalle URI dell’RDF che segue e
quindi definire dei prefissi che saranno utilizzati per abbreviare le URI. La sintassi di
dichiarazione dei namespace è la seguente:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix ex: <http://www.example.org/>.
Dopo aver definito i prefissi è possibile sostituire, nei successivi enunciati, le URI con il
rispettivo QName (rdf: o dc: o ex:). E’ anche possibile definire il namespace di base (senza
bisogno di prefisso), che quindi è sottinteso ogni volta che una risorsa è definita senza usare
alcun prefisso.
@prefix : <http://www.example.org/>.
Se volessimo rappresentare l’enunciato “La pagina Web http://www.example.org/home ha
per autore il signor Rossi” in N3, avremo:
ex:home dc:creator “Rossi”.
Quando si vuole tipizzare una risorsa, in RDF lo si può fare usando il predicato rdf:type. In N3
il predicato rdf:type può essere abbreviato con a. Le due triple che seguono sono
equivalenti:
ex:staff rdf:type ex:Webmaster.
ex:staff a ex:Webmaster.
CAPITOLO 3 – RDF E SPARQL
31
Quando si vuole “tipizzare” un letterale, attribuendogli un significato particolare, N3
prevede l’inserimento dell’indicazione del tipo XSD(XML Schema Definition), attraverso la
notazione grafica del doppio accento circonflesso (^^) seguito dal QName dell’XSD datatype
a cui fa riferimento; infine, se si vuole specificare la lingua in cui è espressa una stringa,
possiamo aggiungere al letterale l’indicazione della lingua attraverso il carattere ‘@’ seguito
dal codice a due lettere della lingua.
ex:home dc:date “2009-10-07”^^xsd:date.
ex:home dc:title “Benvenuti nella homepage”@it.
3.4 LA SINTASSI RDF/XML
La sintassi XML di RDF ha lo scopo di abilitare un meccanismo di interoperabilità per coloro
che vogliono esprimere i loro dati in RDF e, allo stesso tempo, usufruire degli strumenti e dei
parser creati e ampiamente diffusi per l’elaborazione dei dati in XML. Per questo motivo
l’RDF/XML è la sintassi ufficiale di RDF.
Un documento RDF/XML inizia con un elemento radice che contiene la dichiarazione dei
namespace; il nodo radice è sempre indicato come <rdf:RDF> e i namespace sono definiti
esattamente come in XML.
<?xml version = ”1.0”?>
<rdf:RDF
xmlns:rdf = ”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:dc = “http://purl.org/dc/elements/1.1/”
xmlns:ex = “http://www.example.org/”
xmlns:staff = “http://staff.example.org/” >
<rdf:Description rdf:about = “http://www.example.org/home”>
<dc:creator>
<rdf:Description rdf:about = “http://staff.example.org/Rossi”/>
</dc:creator>
<dc:title>
Benvenuti nella homepage
</dc:title>
</rdf:Description>
</rdf:RDF>
La descrizione è composta da due enunciati, uno che lega la pagina Web al suo autore e
l’altro che la lega al letterale che indica il suo titolo. Per indicare la risorsa
http://www.example.org/home, si usa l’elemento rdf:Description con l’attributo rdf:about;
se l’oggetto del predicato è una risorsa, allora il nodo conterrà a sua volta un elemento
rdf:Description con l’attributo rdf:about che contiene l’URI della risorsa; se invece l’oggetto è
un letterale, allora il nodo del predicato conterrà il valore semplicemente come testo. Se il
letterale dovesse essere tipizzato, allora il nodo predicato conterrà l’attributo rdf:datatype
con il riferimento all’XSD datatype.
CAPITOLO 3 – RDF E SPARQL
32
Il W3C ha anche definito una sintassi “abbreviata”. Ad esempio, quando l’enunciato ha una
risorsa per oggetto, anziché definire un nodo rdf:Description annidato è possibile inserire
l’URI dell’oggetto come valore di un attributo rdf:resource del nodo che indica il predicato; il
frammento:
<dc:creator>
<rdf:Description rdf:about = “http://staff.example.org/Rossi”/>
</dc:creator>
Diventa più semplicemente:
<dc:creator rdf:resource = “http://staff.example.org/Rossi” />
Un’altra possibile contrazione della sintassi RDF/XML è relativa agli enunciati che hanno per
predicato la particolare proprietà rdf:type. Quando si vuole descrivere una risorsa dicendo a
quale categoria o famiglia appartiene, si può indicare il tipo proprio con rdf:type.
<rdf:Description rdf:about = “http://staff.example.org/Rossi”>
<rdf:type rdf:about = “http://www.example.org/Staff”/>
</rdf:Description>
Questa espressione può essere abbreviata “tipizzando” il nodo della risorsa:
<ex:Staff rdf:about = “http://staff.example.org/Rossi” />
La sintassi RDF/XML, pur avendo regole precise per l’ordine dei tag all’interno dello stesso
enunciato, non pone alcuna restrizione rispetto all’ordine tra le diverse triple, anzi viola
esplicitamente i vincoli posizionali di XML.
3.5 RDF SCHEMA
Il data model RDF permette di definire un modello semplice per descrivere le relazioni tra le
risorse, in termini di proprietà identificate da un nome e relativi valori. Tuttavia, RDF data
model non fornisce nessun meccanismo per dichiarare queste proprietà, né per definire le
relazioni tra queste proprietà ed altre risorse. Per questo è necessario utilizzare un
linguaggio di schema o ontologico come RDF Schema. Quest’ultimo rappresenta
un’estensione di RDF che comprende i costrutti per descrivere i vocabolari: meccanismi per
descrivere gruppi di risorse collegate e le proprietà che li legano tra loro.
RDF Schema ci offre la possibilità di descrivere i tipi di risorse definendone dei
raggruppamenti; in accordo con quanto accade nel mondo dell’object-orientation, la
tipizzazione si chiama classe e in RDFS è rappresentata dalla risorsa rdfs:Class37. Le risorse
che hanno per tipo una specifica classe si dicono istanze di quella classe. La descrizione delle
classi ci permette inoltre di descrivere la relazione esistente tra diverse classi sotto forma di
37
Il namespase di RDFS è http://www.w3.org/2000/01/rdf-schema#, abbreviato con rdfs.
CAPITOLO 3 – RDF E SPARQL
33
ereditarietà: il linguaggio offre anche la proprietà rdfs:subClassOf, che lega una classe ad
un’altra che rappresenta rispetto a questa un sotto-insieme.
RDFS non è solo una convenzione sull’uso di un certo numero di costrutti, ma veicola anche
una parte della “semantica” di tali espressioni. Questa semantica a sua volta può essere
utilizzata per inferire nuova conoscenza a partire da quella data, ad esempio quando si ha
una gerarchia di sotto-classi e un’istanza della classe più specifica di tale gerarchia, si può
automaticamente inferire che tale istanza appartiene anche a tutte le super-classi. Un
esempio è dato dalla figura, che rappresenta i seguenti enunciati:
ex:HistoricalNovel rdfs:subClassOf ex:Book.
ex:Fiction rdfs:subClassOf ex:Book.
ex:Fantasy rdfs:subClassOf ex:Fiction.
ex:LordOfTheRings rdf:type ex:Fantasy .
Figura 8 - Ereditarietà con rdfs:subClassOf.
In virtù della transitività di rdfs:subClassOf, si possono inferire i seguenti enunciati:
ex:Fantasy rdfs:subClassOf ex:Book.
ex:LordOfTheRings rdf:type ex:Fiction.
Infatti dato che i fantasy sono dei romanzi e che i romanzi sono dei libri, ne segue che anche
i fantasy sono dei libri (primo enunciato) e dato che “Il signore degli Anelli” è un fantasy e
che i fantasy sono un tipo di romanzo, ne deriva che “Il signore degli Anelli” è un romanzo
(secondo enunciato).
RDFS ci permette inoltre di definire per tutte le proprietà RDF il dominio e il codominio
rispettivamente con rdfs:domain e rdfs:range. Quando definiamo una proprietà si può
scrivere a quale rdfs:domain si può applicare e dichiarare qual è il suo rdfs:range, ovvero di
quale tipo devono essere i valori assunti da quella proprietà, come ad esempio:
CAPITOLO 3 – RDF E SPARQL
34
ex:hasWriter rdfs:domain ex:Book.
ex:hasWriter rdfs:range ex:Writer.
Questo significa che ogni qualvolta si usa la proprietà ex:hasWriter in un enunciato, un
sistema “intelligente” che conosce la semantica veicolata da RDFS potrà automaticamente
controllare o inferire che il soggetto di quegli enunciati è un libro e che l’oggetto è uno
scrittore.
Figura 9 - Definizione di domain e range della proprietà hasWriter.
RDFS offre molti costrutti per descrivere con ricchezza le proprietà RDF, ovvero le risorse che
hanno per tipo rdf:Property. Oltre a specificare dominio e codominio, si possono descrivere
gerarchie di proprietà. Per descrivere l’ereditarietà tra le proprietà RDFS ci offre il costrutto
rdfs:subPropertyOf.
Concludendo, RDF Schema permette di definire dei vocabolari, quindi l’insieme delle
proprietà semantiche individuate da una particolare comunità. RDF Schema permette di
definire significato, caratteristiche e relazioni di un insieme di proprietà, compresi eventuali
vincoli sul dominio e sui valori delle singole proprietà. Inoltre, implementando il concetto
(transitivo) di classe e sottoclasse, consente di definire gerarchie di classi, con il conseguente
vantaggio che agenti software intelligenti possono utilizzare queste relazioni per svolgere i
loro compiti.
3.5.1 Esempio di un RDF Schema
Per capire meglio come si struttura un file RDF Schema presento un esempio in cui i
contenuti da rappresentare sono relativi a dei corsi ed a delle lezioni online. Come
dichiarazione iniziale in un file RDF Schema si definiscono dei namespace (delle URI) che
identificano i costrutti RDF, RDFS e l'ontologia. Per il resto lo schema descrive le classi e
proprietà. Esempio del costrutto RDF:
<?xml version='1.0' encoding='ISO-8859-1'?>
<rdf:RDF
xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs ="http://www.w3.org/2000/01/rdf-schema#"
xmlns:a="http://nomesito.it/data/nomeontologia#">
CAPITOLO 3 – RDF E SPARQL
35
<rdfs:Class rdf:ID="Corso">
<rdfs:subClassOf rdf:resource="#Resource"/>
</rdfs:Class>
<rdfs:Class rdf:ID="Argomento">
<rdfs:subClassOf rdf:resource="#Corso"/>
</rdfs:Class>
<rdfs:Class rdf:ID="Specializzazione">
<rdfs:subClassOf rdf:resource="#Resource"/>
</rdfs:Class>
<rdfs:Property rdf:ID="Titolo">
<rdfs:domain rdf:resource="#Corso"/>
<rdfs:range rdf:resource="#Literal"/>
</rdfs:Property>
<rdfs:Property rdf:ID="Livello_di_Specializzazione">
<rdfs:domain rdf:resource="#Corso"/>
<rdfs:range rdf:resource="#Specializzazione"/>
</rdfs:Property>
<rdfs:Property rdf:ID="Utenti">
<rdfs:domain rdf:resource="#Specializzazione"/>
<rdfs:range rdf:resource="#Utenti"/>
</rdfs:Property>
<rdfs:Property rdf:ID="Preparazione_Utenti">
<rdfs:domain rdf:resource="#Specializzazione"/>
<rdfs:range rdf:resource="#Literal"/>
</rdfs:Property>
</rdf:RDF>
Nell’esempio viene innanzi tutto definita una classe (rdfs:Class) che ha come nome
(rdf:about) la risorsa (rdf:resource=) http://www.nomesito.it/data/nomeontologia#Corso. I
nomi delle risorse si identificano utilizzando URI. La parte dell'URL che precede # indica una
precisa ontologia, indica il nome dello schema al quale è riferito un elemento, la parte
successiva al # indica il nome che si è voluto dare a quell'elemento. La classe Corso è
sottoclasse (rdfs.subClassof) di Resource. Resource rappresenta una risorsa, o una classe
generica. Riferire un elemento a Resource significa dire che quell'elemento è genericamente
una risorsa, significa collegarsi al livello radice del nostro dominio.
Considerando il livello radice come livello 0, la classe Corso appartiene al livello 1 del
dominio. La classe Argomento è a sua volta sottoclasse di Corso. La classe Corso ha una
proprietà, ossia un attributo, chiamato Titolo, di tipo stringa. Questo lo si capisce in quanto
l'elemento Titolo è stato definito come rdf:Property, con dominio (rdfs:domain) la classe
CAPITOLO 3 – RDF E SPARQL
36
Corso e con codominio (rdfs:range), Literal, ossia la risorsa standard che in RDF definisce i
dati di testo, siano essi stringhe o interi.
Una classe può essere definita specificando i suoi attributi. La classe Corso ha un titolo che
deve essere specificato tramite una stringa. La classe Argomento in quanto sottoclasse di
corso eredita la proprietà Titolo. Anche l'argomento pertanto può essere definito da un
titolo.
Sempre nell’esempio la classe Corso ha una proprietà che si chiama
Livello_di_Specializzazione. Questa proprietà ha il compito di tener traccia del livello di
specializzazione col quale è stato preparato un corso. Questa proprietà non è però semplice,
non è definibile semplicemente riempiendo una stringa, ma punta ad un'altra classe.
Nella classe Specializzazione ci sono a loro volta due attributi. Uno indica il tipo di utenti, e
punta ad un classe utenti non descritta nell'esempio, uno indica la preparazione di questi
utenti. In pratica la proprietà Livello_di_Specializzazione, per il fatto di puntare ad un'altra
classe, non è più una semplice proprietà ma diventa una relazione fra classi. SubClassof
possiede un significato molto chiaro e indica una parentela di ereditarietà: “gli attributi del
padre sono trasmessi ai figli”. Le relazioni definite tramite le property non hanno un
significato specifico, se non per il fatto di delimitare le proprietà di una classe attraverso
quelle di un'altra.
Con questo piccolo esempio si possono vedere le possibilità espressive di uno schema
ontologico. Il corso può avere un livello di specializzazione che dipende dal tipo di utenti a
cui si rivolge e dalla preparazione che si presume questi abbiano. Con una situazione di
questo tipo si sta descrivendo una proprietà, Livello_di_Specializzazione, che ha un grado,
con una sorta di restrizione a seconda dell'utente a cui di volta in volta la si attribuisce.
3.6 RDF OLTRE XML
La nascita delle tecnologie XML ha dato un’ulteriore spinta alla “globalizzazione” dello
scambio delle informazioni. Tuttavia, i successi ed i vantaggi portati da XML risultano limitati
quando si vuole andare oltre il semplice accordo strutturale e sintattico per prendere in
considerazione la “semantica”, ovvero il significato veicolato dell’informazione.
Il formato XML modella i dati secondo una struttura ad albero particolarmente adatta a
rappresentare un documento e a veicolare informazioni sotto forma di messaggio. Inoltre,
grazie ai namespace e all’espressività del linguaggio XSD (XML Schema Definition), tale
struttura ben si presta a essere estesa. E’ infatti possibile estendere uno schema
precedentemente definito aggiungendo un elemento, un attributo o una struttura più
complessa in un particolare punto di un documento XML senza impattare sul resto del
documento o su tutti gli altri documenti che utilizzano lo stesso schema. Purtroppo, tale
modello non è sufficientemente espressivo per rappresentare relazioni complesse tra i vari
elementi.
CAPITOLO 3 – RDF E SPARQL
37
Un altro modello per la rappresentazione dei dati è quello relazionale (utilizzato nella
maggioranza dei database); questo modello non soffre dei limiti del modello ad albero, ma
mal si adatta a definire schemi di messaggi flessibili ed estensibili. Infatti, se si volesse
aggiungere un attributo a una particolare tupla (oggetto base del modello relazionale),
sarebbe necessario aggiungere tale attributo in tutte le altre tuple della stessa relazione.
Un modello che racchiude i vantaggi del modello relazionale e del modello ad albero è il
modello a grafo orientato etichettato, il quale permette di definire un insieme di nodi e
collegarli tramite relazioni etichettate ed orientate. L’elemento minimo di tale modello è
rappresentato dalla tripla, che connette due nodi tramite un arco.
Nella figura si vede bene come il modello a grafo risulti essere più espressivo per
rappresentare i dati rispetto agli altri due, per questo risulta più adeguato a rappresentare i
dati sul Web. Lo standard RDF rappresenta i dati secondo il modello dei grafi orientati
etichettati.
Figura 10 - Struttura dei tre modelli di rappresentazione dei dati.
3.7 SPARQL
SPARQL (Simple Protocol And RDF Query Language), è il linguaggio di interrogazione
specifico per il recupero dei dati espressi in RDF dal Web. Accolto con entusiasmo come
l’ultimo tassello per l'edificazione del Semantic Web da W3C, è asceso dal 15 gennaio 2008
al rango di W3C Candidate Recommendation.
SPARQL è formato da:
o un linguaggio di interrogazione (SPARQL Query Language);
o il formato XML per i risultati delle query (SPARQL Query XML Results Format);
o il protocollo di accesso ai dati che definisce l’uso di semplici protocolli HTTP e SOAP
per l’interrogazione remota dei database RDF (SPARQL Protocol).
Lo SPARQL Protocol for RDF permette a un generico client di interrogare uno o più endpoint
SARQL inviando una richiesta espressa nel linguaggio di interrogazione e ricevendo come
CAPITOLO 3 – RDF E SPARQL
38
risposta il risultato in formato XML. Il protocollo SPARQL è basato su WSDL 2.0 (Web Services
Description Language ) e la sua specifica descrive sia l’interfaccia astratta, sia i legami di
questa verso gli standard attualmente utilizzati sul Web. Anche lo SPARQL Query Language è
un linguaggio di interrogazione pensato per il Web. Infatti oltre a prevedere la clausola
SELECT come in SQL38, SPARQL offre anche altri costrutti. E’ possibile infatti che non si
conosca a priori lo schema dei dati, per risolvere questo problema SPARQL ha la clausola
DESCRIBE, che permette di ottenere una descrizione della risorsa cercata; inoltre, qualora vi
siano più sorgenti potenzialmente in possesso di una certa informazione, è possibile che si
presenti la necessità di sapere se un certo enunciato o un certo pattern di dati sia presente
nella sorgente dati: per questo motivo SPARQL propone la clausola ASK.
Esistono notevoli somiglianze tra i Data Model su cui si basano i due linguaggi SPARQL e SQL.
L'RDF Data Model trova corrispondenza con il modello Entity-Relationship39, ad esempio una
rappresentazione dei dati con RDF, come quella che segue, è facilmente “traducibile” come
segmento di riga della tabella di un database relazionale nella forma “chiave - nome colonna
- valore colonna”:
SOGGETTO PREDICATO OGGETTO
id1234 anno 1994
Tabella 2 - Rappresentazione a tabella dei dati con RDF.
ID ANNO .....
1234 1994 .....
Tabella 3 - Rappresentazione a tabella dei dati con database relazionale.
Se è possibile trasporre un Data Model in un altro, è altresì possibile trasporre l'uno nell'altro
i rispettivi linguaggi di interrogazione, concludendo: gli scopi di SQL e di SPARQL sono
abbastanza diversi tra loro da giustificare la creazione di un linguaggio specifico per
l'interrogazione dell'RDF. Ciò nonostante è possibile tradurre espressioni SPARQL in
espressioni SQL, permettendo così a chi ne fa uso, di immagazzinare i propri dati RDF in
database relazionali e di scrivere le query, a seconda dei casi, in SQL oppure in SPARQL.
3.7.1 Le path expression
SPARQL adotta la sintassi Turtle, un'estensione di N-Triples, che si basa sul concetto di tripla
e sull’unione degli enunciati rappresentata dal grafo di triple. Per esprimere le
interrogazioni, SPARQL introduce il concetto di path expression: l’insieme delle triple
necessarie a rispondere all’interrogazione, in cui sostituiamo uno o più identificativi (sia
38
SQL (Structured Query Language), è un Linguaggio di programmazione per database progettato per leggere,
modificare e gestire dati memorizzati in un sistema basato sul modello relazionale, per creare e modificare
schemi di database, per creare e gestire strumenti di controllo ed accesso ai dati. 39
L’Entity Relationship Model è una rappresentazione astratta e concettuale dei dati, usato spesso per
produrre database relazionali.
CAPITOLO 3 – RDF E SPARQL
39
risorse che letterali) con una variabile, espressa da una parola arbitraria preceduta dal
simbolo “?”.
La path expression rappresenta quindi il pattern dei dati che vogliamo recuperare e i risultati
dell’interrogazione saranno tutte e sole le triple RDF che soddisfano la path expression
sostituendo alle variabili le risorse o i letterali corrispondenti.
Nell’esempio seguente ecco una tripla che costituisce una path expression:
?titolo cd:autore ?autore.
Al posto del soggetto e dell'oggetto questo “triple pattern” prevede due variabili,
contrassegnate con “?”. Le variabili fungono in un certo senso da incognite
dell'interrogazione, cd:autore funge invece da costante: le triple RDF che trovano riscontro
nel modello associeranno i propri termini alle variabili corrispondenti. Ecco una semplice
query di selezione SPARQL:
PREFIX cd: <http://example.org/cd/>
SELECT ?titolo ?autore ?anno
FROM <http://cd.com/listacd.ttl>
WHERE {
?titolo cd:autore ?autore.
?titolo cd:anno ?anno.
}
Nella prima riga viene dichiarato il namespace utilizzato e a differenza della sintassi N3, la
parola chiave PREFIX è senza il simbolo ‘@’ ed alla fine della dichiarazione non c’è il punto.
Se si volesse dichiarare un namespace di default, si potrebbe usare la parola chiave BASE al
posto di PREFIX.
Nelle righe successive ci sono altre parole chiave del linguaggio SPARQL e l'analogia con il
linguaggio SQL è lampante:
o SELECT definisce le variabili di ricerca da prendere in considerazione nel risultato
(nell'esempio: titolo, autore e anno);
o FROM specifica il set di dati su cui dovrà operare la query (si suppone che le triple
siano immagazzinate presso l'indirizzo fittizio “http://cd.com/listacd.ttl”). È inoltre
possibile ricorrere a clausole FROM NAMED e alla parola chiave GRAPH per
specificare più set di dati;
o la clausola WHERE , infine, definisce il criterio di selezione specificando tra parentesi
graffe uno o più “triple patterns” separati da punto fermo.
La query precedente ha catturato esclusivamente le triple dotate di tutti e tre i termini
richiesti (titolo, autore, anno), escludendo le triple che ne possedevano due soltanto (titolo,
autore). È possibile riformulare la query in modo più elastico, prevedendo la possibilità di
inserimento di triple in cui vi sia l’assenza di alcuni termini come mostra l’esempio seguente:
CAPITOLO 3 – RDF E SPARQL
40
PREFIX cd: <http://example.org/cd/>
SELECT ?titolo ?autore ?anno
FROM <http://cd.com/listacd.ttl>
WHERE {
?titolo cd:autore ?autore.
OPTIONAL { ?titolo cd:anno ?anno }
}
Nell'esempio, il secondo pattern è dichiarato opzionale: l'informazione è aggiunta al risultato
solo se disponibile, altrimenti le variabili compariranno prive di valore. Le risorse sprovviste
della proprietà ‘anno’ sono mostrate ugualmente e le celle dei valori mancanti sono lasciate
vuote. Un altro modo per assicurare una certa elasticità nel reperimento dei dati è il
seguente:
PREFIX cd: <http://example.org/cd/>
SELECT ?titolo ?autore ?anno
FROM <http://cd.com/listacd.ttl>
WHERE {
{ ?titolo cd:autore ?autore. }
UNION { ?titolo cd:anno ?anno }
}
La parola chiave UNION esprime un OR logico: la query non si limita pertanto alle triple che
soddisfano entrambi i triple patterns, ma cattura sia quelle che soddisfano unicamente il
primo, sia quelle che soddisfano unicamente il secondo.
È possibile porre restrizioni sui valori da associare alle variabili. Ad esempio:
PREFIX cd: <http://example.org/cd/>
SELECT ?titolo ?anno
FROM <http://cd.com/listacd.ttl>
WHERE {
?titolo cd:autore ?autore.
FILTER ( ?anno > 2000 )
}
In questo caso, la restrizione è effettuata mediante l'operatore di confronto ‘>’, il filtro
esclude i termini che non soddisfano la condizione definita tra le parentesi tonde. Gli
operatori utilizzabili all’interno di una clausola FILTER sono costituiti da connettivi logici
(AND e OR, rappresentati da ‘&&’ e ‘||’), operazioni di comparazione (come ‘>’, ‘<’, ‘=’, ‘!=’,
ecc.), espressioni regolari ed una serie di operatori unari specifici di SPARQL.
Un esempio di operatore specifico di SPARQL è ‘regex’, corrispettivo di LIKE dell'SQL che
permette di adoperare espressioni regolari per il matching dei letterali. Nel seguente
esempio il filtro seleziona, senza riguardo per maiuscole o minuscole, solo gli autori che
iniziano per “au”:
CAPITOLO 3 – RDF E SPARQL
41
PREFIX cd: <http://example.org/cd/>
SELECT ?titolo ?autore
FROM <http://cd.com/listacd.ttl>
WHERE {
?titolo cd:autore ?autore.
FILTER regex (?autore, “^au”, “i”)
}
Come in SQL, è possibile escludere dal risultato i valori duplicati mediante la parola chiave
DISTINCT, ad esempio:
SELECT DISTINCT ?titolo ?autore
Altri costrutti supportati da SPARQL per la manipolazione del risultato sono:
ORDER BY DESC ( ?autore )
LIMIT 10
OFFSET 10
o ORDER BY imposta l'ordine dei risultati della query: stando all'esempio, i risultati
verranno presentati in ordine decrescente (DESC) in base alla variabile ?autore.
o LIMIT pone restrizioni al numero dei risultati, limitandoli, secondo quanto indicato
nell'esempio, ai soli primi 10.
o OFFSET permette di “saltare” un certo numero di risultati, escludendo, stando
all'esempio, i primi 10.
Di particolare interesse sono le query CONSTRUCT, che permettono di restituire il risultato
dell’interrogazione sotto forma di grafo RDF, nell’esempio si vede come viene utilizzato:
PREFIX cd: <http://example.org/cd/>
CONSTRUCT { ?titolo ?autore }
FROM <http://cd.com/listacd.ttl>
WHERE {
?titolo cd:autore ?autore.
}
3.7.2 Output di una query in formato XML
Eseguendo la seguente query:
PREFIX cd: <http://example.org/cd/>
SELECT ?titolo ?autore
FROM <http://cd.com/listacd.ttl>
WHERE {
?titolo cd:autore ?autore
}
CAPITOLO 3 – RDF E SPARQL
42
Il risultato in formato tabulare è:
TITOLO AUTORE
“Permutation” “Amon Tobin”
“Bricolage” “Amon Tobin”
“Amber” “Autechre”
Il risultato in formato XML è:
<?xml version=“1.0”?>
<sparql xmlns=http://www.w3.org/2005/sparql-results#>
<head>
<variable name=“titolo” />
<variable name=“autore” />
</head>
<results ordered=“false” distinct=“false”>
<result>
<binding name=“titolo”>
<literal>Permutation</literal>
</binding>
<binding name=“autore”>
<literal>Amon Tobin</literal>
</binding>
</result>
<result>
<binding name=“titolo”>
<literal>Bricolage</literal>
</binding>
<binding name=“autore”>
<literal>Amon Tobin</literal>
</binding>
</result>
<result>
<binding name=“titolo”>
<literal>Amber</literal>
</binding>
<binding name=“autore”>
<literal>Autechre</literal>
</binding>
</result>
</results>
</sparql>
La sintassi è intuitiva, leggibile e facile da gestire mediante fogli di stile. L'elemento radice è
‘sparql’, l'attributo ‘xmlns’ definisce, come di consueto, il namespace di riferimento.
Nella sottosezione ‘head’ sono elencate, nello stesso ordine in cui compaiono nella SELECT
della query, le variabili da prendere in considerazione nel risultato, indicate come valori
dell'attributo ‘name’ degli elementi vuoti ‘variable’.
CAPITOLO 3 – RDF E SPARQL
43
La seconda sottosezione, ‘results’, contiene una sequenza di elementi ‘result’ che
esprimono, per ciascun risultato della query, le variabili cercate, indicate come valore
dell'attributo ‘name’ dell'elemento ‘binding’, e i rispettivi valori (nell'esempio, letterali di
tipo stringa).
I valori booleani degli attributi ‘ordered’ e ‘distinct’ dell'elemento ‘results’ indicano se
prendere in considerazione o meno gli eventuali costrutti ORDER BY o SELECT DISTINCT della
query.
3.7.3 Framework SPARQL
Sono stati realizzati diversi framework (piattaforme) open source, quindi scaricabili
gratuitamente da Internet, che permettono di effettuare il parsing (l'analisi) di strutture RDF,
l'esecuzione di query, la manipolazione, il caricamento di triple su database (appoggiandosi
su database relazionali) e altri tipi di funzioni.
Attualmente i più diffusi framework sono Jena, Redland, Twinkle, Rap, Sesame, ARC2 e si
differenziano principalmente per il linguaggio di programmazione utilizzato (PHP40 o JSP41).
Nel progetto di questa tesi è stato scelto un framework fra questi e sarà approfondito nel
capitolo 6.
40
PHP (acronimo ricorsivo di "PHP: Hypertext Preprocessor", preprocessore di ipertesti) è un linguaggio di
scripting interpretato, con licenza open source e parzialmente libera, utilizzato principalmente per
sviluppare applicazioni web lato server. 41
JSP (JavaServer Pages), è una tecnologia Java per lo sviluppo di applicazioni Web che forniscono contenuti
dinamici in formato HTML o XML. Si basa su un insieme di speciali tag con cui possono essere invocate
funzioni predefinite o codice Java (JSTL).
44
CAPITOLO 4
DOQUI
CAPITOLO 4 – DOQUI
45
4.1 CHE COS'È DOQUI
DoQui è una piattaforma informatica di gestione documentale che permette di organizzare,
archiviare e condividere documenti in formato digitale. Realizzata nel 2008 da Regione
Piemonte, Città e Provincia di Torino con il coordinamento di CSI-Piemonte e il contributo
del Politecnico di Torino e dell’Università degli studi di Torino. La piattaforma promuove una
collaborazione fra Enti pubblici e mondo accademico per raggiungere la completa de
materializzazione dei processi amministrativi, per sostenere la crescita delle imprese ICT
(Information and Communication Technology) in Piemonte e diffondere l’utilizzo di soluzioni
e tecnologie open source. Il carattere innovativo dell’iniziativa sta anche nella creazione di
una comunità di soggetti, pubblici e privati, che potranno collaborare e condividere
materiali, temi e documenti del progetto.
I vantaggi:
o ottimizza i processi;
o assicura la tracciabilità delle azioni;
o incrementa la (ri)trovabilità dei documenti;
o garantisce sicurezza e riservatezza delle informazioni;
o favorisce l'eco-sostenibilità grazie all'abbattimento dei consumi di carta;
o consente di ridurre drasticamente gli spazi e i costi dedicati agli archivi cartacei.
Per chi:
o Enti della Pubblica Amministrazione che hanno necessità di assolvere agli obblighi di
legge in materia di amministrazione digitale;
o Aziende che hanno necessità di gestire con efficacia la documentazione digitale;
o Aziende che, in qualità di “fornitori” di servizi e soluzioni informatiche, possono
contribuire a migliorare la soluzione sviluppata e ampliare le prospettive di mercato.
Le caratteristiche:
o basato su tecnologie open source;
o flessibile: può essere adattato a contesti d'uso ed esigenze diversi;
o orientato al riuso delle componenti;
o gratuito.
4.2 OBIETTIVI
Il progetto, coordinato da CSI-Piemonte, attua una strategia di politica industriale pubblica
piemontese basata su:
o collaborazione fra Enti pubblici e mondo accademico;
o dematerializzazione e semplificazione dei processi amministrativi;
o utilizzo di soluzioni e tecnologie open source;
o sostegno alla crescita delle imprese ICT piemontesi.
CAPITOLO 4 – DOQUI
46
Gli obiettivi:
o offrire alla Pubblica Amministrazione piemontese un sistema informatico per la
gestione documentale per:
assolvere agli obblighi di legge nella gestione quotidiana dei procedimenti
amministrativi;
razionalizzare i processi organizzativi interni;
ridefinire le modalità di interazione con i cittadini e le imprese, in vista di una
maggiore efficienza e trasparenza;
o determinare ricadute positive sul settore ICT piemontese grazie a:
nuove competenze;
nuovi modelli di business;
logiche di mercato che privilegiano l’offerta di consulenze specialistiche e la
realizzazione di progetti e/o prodotti ICT finiti;
o sviluppare una linea strategica industriale basata sul software libero attraverso:
una comunità che diffonda l’approccio industriale al modello open source e
costituisca un punto di eccellenza a livello nazionale;
la collaborazione fra mondo accademico e Enti Pubblici;
o offrire alle aziende l’opportunità di:
acquisire competenze tecnologiche elevate;
proporre servizi aggiuntivi costruiti sulla piattaforma (consulenza,
personalizzazioni e verticalizzazioni, evoluzioni funzionali).
4.3 INNOVAZIONE
DoQui propone una soluzione:
o open source, per fornire un vantaggio competitivo al territorio e valorizzare le
competenze presenti;
o flessibile e orientata al riutilizzo delle componenti per assicurare la fruibilità del
sistema anche in filiere documentali diverse da quella di origine;
o aperta alle PMI del comparto ICT piemontese per stimolare il tessuto produttivo
locale e creare nuove opportunità di mercato;
o conforme alla direttiva nazionale (Codice Amministrazione Digitale42);
o partecipata grazie alla creazione della comunità di soggetti pubblici e privati chiamati
a collaborare alla progettazione, gestione e manutenzione della piattaforma.
Il progetto è fortemente innovativo per:
42
Il Codice dell’Amministrazione Digitale è entrato in vigore l’ 1 Gennaio 2006 ed ha lo scopo di assicurare e
regolare la disponibilità, la gestione, l’accesso, la trasmissione, la conversazione e la fruibilità
dell’informazione in modalità digitale utilizzando in modo appropriato le tecnologie dell’informazione e
della comunicazione all’interno della pubblica amministrazione, nei rapporti tra amministrazione e privati e
in alcuni casi limitati anche solo tra privati.
CAPITOLO 4 – DOQUI
47
o l’approccio alla gestione documentale;
o il modello di sviluppo;
o le scelte tecnologiche.
4.3.1 L’approccio alla gestione documentale
La soluzione DoQui rovescia la prospettiva tradizionale che considera l’archivio dell’Ente
come un derivato del sistema di protocollo, spostando il focus sui concetti di “documento”,
“fascicolo”, “archivio”. Questo consente di avviare un piano di convergenza
dell’organizzazione dell’Ente verso una gestione strutturata della propria documentazione, e
affrontare processi di dematerializzazione end to end43 prescindendo dal sistema di
protocollo.
In base a questo approccio, il modello di riferimento a lungo termine è delineato nello
schema:
Figura 11 - Gestione documentale di DoQui.
Si inquadra nell’ambito dei sistemi di gestione, archiviazione e condivisione di documenti
informatici, prodotti cartacei digitalizzati o digitali già in origine.
Il perimetro funzionale è stato definito a partire dall’analisi del ciclo di vita del documento,
(digitale o cartaceo, protocollato o non) all’interno dell’Ente o meglio di una sua Area
Organizzativa Omogenea (AOO):
43
Il principio end to end è uno dei principi centrali del protocollo IP (Internet Protocol), che fornisce le basi per
Internet. Secondo il principio dell’ end to end, le operazioni relative ai protocolli di comunicazione devono
avvenire nei punti finali di un sistema di comunicazione.
CAPITOLO 4 – DOQUI
48
o produzione/ricezione: produzione del documento che porta alla sua versione
definitiva oppure ricezione di un documento che verrà archiviato o trasmesso ad altri
soggetti;
o gestione: azioni effettuate sul documento nella sua versione definitiva (prodotta o
ricevuta dall’Ente) cioè archiviazione, trasmissione, ricerca, esibizione, etc.;
o conservazione: trasversale al ciclo di vita del documento a partire dall’inserimento in
archivio corrente e fino al suo versamento nell’archivio di deposito.
4.3.2 Il modello di sviluppo
Le attività di raccolta delle esigenze e di codifica dei requisiti funzionali sono state svolte da
un gruppo di lavoro multi-Ente e multi-disciplinare, con notevoli benefici:
o il modello open source garantisce bassi costi di adozione e lock-in44 inferiori rispetto
alle equivalenti soluzioni commerciali;
o le funzionalità rispondono alle esigenze funzionali, organizzative e operative di realtà
amministrative eterogenee rappresentate dal Gruppo di Lavoro;
o le imprese ICT, coinvolte fin dalle prime fasi del progetto, hanno l’opportunità di
acquisire conoscenze e contribuire a migliorare le scelte e i prodotti.
4.3.3 Le scelte tecnologiche
Il sistema progettato è conforme al paradigma di architettura basata sui servizi (SOA),
scomposta in moduli autoconsistenti e basata su standard di ambito ECM (Enterprise
Content Management), tipici di tutti i principali vendors.
Questa impostazione garantisce:
o una migliore suddivisione tra le funzioni di sistemi complessi di gestione documentale
(storage45, business logic di accesso allo storage, business logic di organizzazione dei
contenuti, interfacccia utente);
o l’accrescimento funzionale del sistema attraverso l’innesto nell’architettura
complessiva di altri moduli autoconsistenti, anche se sviluppati con tecnologie
diverse e da soggetti diversi.
4.4 COMPONENTI DEL SISTEMA
Il Sistema di Gestione Documentale ha come cuore operativo la gestione dell’archivio
tramite l’applicativo DoQui Acta e come piattaforma di Content Management DoQui Index.
44
Il fenomeno del lock-in si ha quando, individualmente o collettivamente, si è "catturati" da una scelta
tecnologica potenzialmente inferiore rispetto ad altre disponibili, è assai rilevante nell'ambito delle
tecnologie di Internet. 45
Storage, deposito dati.
CAPITOLO 4 – DOQUI
49
Le filiere di produzione/ricezione dei documenti così come i sistemi di gestione delle
strutture organizzative, autenticazione, autorizzazione e firma digitale sono integrati con la
gestione dell’archivio, mentre il servizio di conservazione viene reso disponibile alla gestione
dell’archivio dalla piattaforma.
DoQui Index gestisce anche l’archiviazione separata di documenti in archivio corrente,
sempre disponibili on line, diversamente da quelli in archivio di deposito che potranno
risiedere su supporti di memorizzazione anche non in linea. La componente di Content
Management (DoQui Index) consente di effettuare l’archiviazione dei documenti mettendo a
disposizione il software di base a garanzia dell’integrità e dell’immodificabilità dei
documenti, fornendo le seguenti principali funzionalità:
o il check-in ed il check-out dei documenti;
o l’esibizione dei documenti;
o l’accesso ai documenti;
o la gestione del versioning;
o il supporto alla firma digitale e al time stamping;
o la ricerca dei documenti.
L’applicativo DoQui Acta è un insieme integrato di moduli funzionali che definiscono, nella
loro completezza, la gestione documentale dell’Ente, cioè la modalità con cui le funzionalità
base della piattaforma sono utilizzate dall’Ente:
o back-office (BKO): modulo per la definizione della struttura dell’Ente, degli utenti, dei
profili, e del diritto di accesso ai documenti;
o gestione strutture archivio (GSA): modulo per la definizione della struttura
dell’archivio, del titolario di classificazione e delle strutture aggregative;
o gestione contenuti (GCO): modulo per la gestione delle strutture aggregative dei
documenti e per effettuare tutte le operazioni su di esse (ad esempio inserire e
prelevare documenti);
o gestione smistamento (SMS): modulo per consentire lo smistamento dei documenti,
inviare e ricevere gli avvisi di comunicazione agli utenti sulla presenza di documenti
nel sistema;
o gestione archivio (GAR): modulo per tutte le operazioni proprie della gestione
archivio;
o audit trail (AUD): modulo per la registrazione delle operazioni effettuate nel sistema
con le relative responsabilità e tempi;
o servizi applicativi (SER): modulo per la definizione dei servizi applicativi richiamabili
da procedure software esterne al sistema di gestione documentale.
CAPITOLO 4 – DOQUI
50
Figura 12 - Componenti del sistema DoQui.
4.5 STRUTTURA DOQUI
I componenti che costituiscono la struttura di DoQui si suddividono in applicazioni e
infrastrutture.
Infrastrutture:
o Index è il motore di gestione dei contenuti digitali, basato su un modello
infrastrutturale SOA che rende disponibili servizi di document management riferiti
alle più estese soluzioni industriali di ECM. Index è di classe enterprise, presenta
un'alta modularità, notevole capacità di carico, elevata scalabilità.
o Flux è un sistema per la gestione del ciclo di vita dei processi di business a supporto
delle attività necessarie per definire, ottimizzare, monitorare e integrare le prassi
lavorative di un’azienda. Fornisce strumenti per la configurazione e la realizzazione di
soluzioni applicative personalizzate per l'automazione di processi e gestisce processi
che trattano documenti in integrazione con le altre componenti presenti nell'offerta
DoQui.
Applicazioni:
o Acta è un sistema integrato per la gestione della documentazione elettronica degli
Enti pubblici.
o Acta light è un’implementazione ridotta di Acta. Per Enti pubblici e non solo.
o Cedolino elettronico è il sistema per la gestione di tutte le attività necessarie alla
pubblicazione del cedolino elettronico.
o Preserve è un’applicazione per la connessione ai servizi esterni di conservazione
sostitutiva secondo le norme previste dalla legge.
CAPITOLO 4 – DOQUI
51
o Share è il sistema per la gestione strutturata e la condivisione di documenti digitali in
contesti di carattere collaborativo.
Figura 13 - Struttura DoQui.
52
CAPITOLO 5
DEFINIZIONE DEL PROBLEMA
CAPITOLO 5 – DEFINIZIONE DEL PROBLEMA
53
5.1 OBIETTIVI GENERALI
“È possibile utilizzare Index per rappresentare i dati in modo semantico?”
Questo interrogativo è il cuore di codesta tesi, ovvero capire come portare le tecnologie del
Semantic Web all’interno di un sistema documentale quale DoQui e nel particolare
all’interno dell’infrastruttura Index, il motore di gestione di documenti in formato digitale
della Regione Piemonte.
Questo interrogativo nasce dalla consapevolezza delle potenzialità del Semantic Web, ad
oggi l’obiettivo delle nuove tecnologie del Web è quello di sfruttare sempre più le macchine
e per far questo è necessario organizzare meglio e in modo più flessibile l’archiviazione dei
dati per rendere più facile la ricerca e favorire un uso migliore delle risorse esistenti
(documenti, dati, funzionalità), che crescono sempre più.
Per non passare sempre attraverso manutenzioni applicative occorre trasferire alle
applicazioni più conoscenza e meglio organizzata, in modo tale che le informazioni siano
interpretabili dalle macchine.
La conoscenza si può organizzare sia utilizzando concetti definiti univocamente attraverso
URI, classificazioni e comportamenti, e sia utilizzando contesti definiti univocamente con
domini e campi di applicabilità dei concetti. Dunque, attraverso concetti e contesti univoci
diviene possibile per le macchine “ragionare”, creando nuovi collegamenti con altre
conoscenze, cosicché i dati evolvano e si creino dei veri e propri aggregati di conoscenza il
cui valore finale è potenzialmente maggiore. E affinché la conoscenza possa essere utilizzata
da applicazioni differenti deve essere organizzata fuori dalle applicazioni e deve essere
rappresentata in modo standard.
Per organizzare meglio la conoscenza i dati devono essere trattati in maniera che non siano
dei semplici file testuali ma che siano strutturati attraverso la logica della semantica tale da
permettere elaborazioni informative successive effettuate da “agenti intelligenti”, in modo
tale che questi non si limitino ai soli dati quantitativi ma che amplino la sfera conoscitiva
rendendo disponibili informazioni aggiuntive, di carattere qualitativo.
Nella figura è mostrato un esempio di come gli agenti intelligenti possano elaborare i dati
relativi agli ingredienti di un piatto e ricondurci alle case di produzione di tali ingredienti.
Questo grazie all’incremento della conoscenza degli stessi agenti intelligenti che attingono,
nelle loro ricerche, a più sorgenti precedentemente strutturate con la logica della semantica.
E dato l’incremento di questa logica nel Web, si possono creare numerosi collegamenti resi
disponibili direttamente dalle macchine senza che sia l’uomo a doverli cercare. Chiaramente
affinché il tutto funzioni è necessario che gli identificativi delle stesse risorse, tra le diverse
sorgenti, siano uguali.
CAPITOLO 5 – DEFINIZIONE DEL PROBLEMA
54
Figura 14 - Esempio di collegamenti creati da Agenti intelligenti.
Quindi l’interrogativo iniziale vuole porre l’attenzione sulle potenzialità di Index e sulla
possibilità di rappresentare e utilizzare i dati al suo interno in modo semantico; questo per
permettere una ricerca migliore internamente ed esternamente, condividendo la
conoscenza di Index con altri applicativi di ricerca. Fondamentalmente uno studio, quello di
questa tesi, volto a capire se Index per come è stato strutturato possa evolversi verso il Web
3.0 senza apportare modifiche alla sua struttura interna.
5.2 CASO DI STUDIO
Il progetto ha comportato la realizzazione di un’interfaccia Web che permetta a livello
amministrativo la gestione dei dati relativi ai menu dei ristoranti e quindi consenta ai gestori
di ristorante (o a chi ne fa le veci per loro) di creare un menu composto da tutte le sue parti,
quindi portate, bevande, coperto, tipi di piatti, i relativi prezzi ed eventuali descrizioni dei
piatti.
Dovendo giungere a delle conclusioni finali che rispondono al quesito principale su cui si
basa questa tesi è stato utile percorrere due strade differenti ma parallele per arrivare allo
stesso risultato e valutarle mediante confronto.
Il fine è rappresentare e utilizzare i dati in modo semantico, il punto di partenza è
l’interfaccia Web di un CMS per menu di ristoranti, le due strade differenti ma parallele da
percorrere sono:
CAPITOLO 5 – DEFINIZIONE DEL PROBLEMA
55
o rappresentare i dati su RDF e interrogandoli utilizzando un EndPoint SPARQL46;
o rappresentare e utilizzare i dati semantici con Index.
Avere due versioni differenti dello stesso progetto permette di analizzare meglio i pro e i
contro di entrambi e ai fini della ricerca consente di trarre delle conclusioni migliori.
Queste due versioni sono presentate e analizzate rispettivamente nei capitoli 6 e 7, mentre il
capitolo 8 mostra tutte le valutazioni nate dal confronto.
5.3 REALIZZAZIONE INTERFACCIA
I due percorsi, seguiti per la realizzazione finale del progetto, partono dalla stessa interfaccia
Web, le funzionalità dell’interfaccia infatti non cambiano, ciò che cambia è il back-end,
ovvero il luogo dove i dati vengono allocati. Per cui il primo passo da compiere è stato la
realizzazione dell’interfaccia.
Per realizzare l’interfaccia Web di un CMS sui menu dei ristoranti e per capire meglio di quali
elementi quest’ultimi si possano comporre è stato opportuno iniziare con l’analisi di un vero
e proprio menu di un ristorante. La catalogazione, in un menu per ristoranti, avviene per
portate, quindi primi, secondi, frutta, etc. e queste a loro volta sono composte dai diversi
piatti con relativi prezzi ed eventuali descrizioni degli ingredienti del piatto, come mostrato
in figura.
Figura 15 – Suddivisione menu ristorante.
46
Endpoint SPARQL, è un servizio che consente agli utenti di interrogare una base di conoscenze RDF
attraverso il linguaggio SPARQL.
CAPITOLO 5 – DEFINIZIONE DEL PROBLEMA
56
È stato utile partire da questa suddivisione per decidere come organizzare nel miglior modo
l’interfaccia utente per l’inserimento dei dati di un menu. Infatti, osservando anche la figura,
è automatico pensare che sia necessario un primo box (riquadro) per l’inserimento delle
portate, un secondo box per l’inserimento dei piatti e relativi prezzi ed infine un terzo per
eventuali descrizioni del piatto, come gli ingredienti che compongono il piatto, l’origine di
tali ingredienti, etc.
La figura che segue mostra l’interfaccia nella sua realizzazione finale, tale interfaccia
consente ad un amministratore di creare le portate, gestirne la catalogazione, eliminarle e
modificarle utilizzando il riquadro a sinistra. Per ogni portata è poi possibile, utilizzando il
riquadro centrale, inserire i piatti che la compongono con i relativi prezzi, gestirne la
catalogazione, eliminarli e modificarli. Infine, nel riquadro a sinistra, per ciascun piatto è
possibile inserirne una descrizione.
Figura 16 – Interfaccia realizzata del CMS di un menu per ristorante.
Nella realizzazione di questa interfaccia è stato utilizzato jQuery47, un framework JavaScript
che modifica, il modo in cui si programma in JavaScript, infatti le principali funzioni di
quest’ultima (e i problemi ad esse associati) sono state sostituite da strutture più cross-
47
jQuery è un framework JavaScript, realizzato per supportare nel miglior modo possibile lo sviluppatore web
garantendogli, non solo un più rapido sviluppo delle applicazioni ma anche, e soprattutto, la sicurezza di
avere un'architettura compatibile con tutti i principali browser moderni.
CAPITOLO 5 – DEFINIZIONE DEL PROBLEMA
57
browser48 che facilitano non di poco il lavoro di un programmatore. Con jQuery sono state
realizzate le funzioni Drag&Drop sulle portate e sui piatti per gestire un loro ordinamento nei
rispettivi box, delle Dialog personalizzate con una grafica differente dalle classiche Alert dei
vari browser, una WordSuggestion nell’inserimento delle portate per consigliare le portate
più comuni.
Ultimata l’interfaccia si è passati ad un’analisi dei dati per decidere quale fosse la loro
migliore organizzazione semantica per poi operare sulla costruzione dei due differenti back-
end. Nei successivi capitoli vengono mostrate le due versioni realizzate successive proprio a
tale analisi.
48
Le pagine web si dicono talvolta multipiattaforma o cross-browser se possono essere utilizzate da qualunque
browser o da tutti i browser recenti.
58
CAPITOLO 6
VERSIONE BASATA SU RDF E SPARQL
CAPITOLO 6 – VERSIONE BASATA SU RDF E SPARQL
59
6.1 TIPOLOGIA DI INFORMAZIONI
Una volta completato l’aspetto front-end, ovvero sviluppata l’interfaccia Web, si è passati a
quello back-end. Prima di iniziare a creare la struttura back-end è buona norma soffermarsi
sui dati per capire come questi debbano essere suddivisi. Per questo per una prima loro
rappresentazione è stato utilizzato il formato XML, che permette di utilizzare tag
personalizzati e proprio per questo consente semplici rappresentazioni facilmente
interpretabili sia dall’uomo che dalla macchina.
Ecco come i dati sono stati suddivisi nel file XML:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE menu [
<!ELEMENT menu (portata*)>
<!ELEMENT portata ( (piatto*))>
<!ELEMENT piatto ( (nome, prezzo, descrizione))>
<!ELEMENT nome (#PCDATA)>
<!ELEMENT prezzo (#PCDATA)>
<!ELEMENT descrizione (#PCDATA)>
]>
<menu>
<portata id="Antipasti">
<piatto id="Bresaola">
<nome> Bresaola </nome>
<prezzo> 25.00 </prezzo>
<descrizione> <![CDATA[ <b>Bresaola</b> ]]> </descrizione>
</piatto>
<piatto id="Prosciutto_Crudo">
<nome> Prosciutto Crudo </nome>
<prezzo> 25.00 </prezzo>
<descrizione> <![CDATA[ Prosciutto Crudo ]]> </descrizione>
</piatto>
.
.
.
</portata>
<portata id="Primi">
<piatto id="Salsiccia_Toscana_al_forno">
<nome> Salsiccia Toscana al forno </nome>
<prezzo> 8.00 </prezzo>
<descrizione> <![CDATA[ Salsiccia Toscana ]]> </descrizione>
</piatto>
.
.
.
</portata>
.
.
.
</menu>
CAPITOLO 6 – VERSIONE BASATA SU RDF E SPARQL
60
Nella prima parte di questo file XML è stato definito il DOCTYPE, ovvero la grammatica
utilizzata nel restante codice. Con <!ELEMENT element-name CONTENT-DESCRIPTION> sono
definite le caratteristiche degli elementi e questi quali altri elementi possono contenere:
l’elemento menu è costituito da 0 o più elementi portata;
portata è costituita da 0 o più elementi piatto;
piatto è costituido dagli elementi nome, prezzo e descrizione;
nome, prezzo e descrizione sono di tipo ‘testuale’.
6.2 MODELLO
La realizzazione di un file XML, per gestire i dati, ha permesso di ragionare meglio sui dati
stessi e su come questi dovessero essere strutturati per una rappresentazione semantica. Il
Semantic Web prevede che ogni risorsa sia rappresentata da triple soggetto-predicato-
oggetto, per esempio l’espressione “il risotto ai funghi ha un prezzo di 6€” avrà una
rappresentazione semantica di questo tipo:
SOGGETTO PREDICATO OGGETTO
Risotto ai funghi Ha prezzo 6
e nella rappresentazione Notation3 (o N3) dell’RDF sarà:
SOGGETTO PREDICATO OGGETTO
@prefix
tr:Risotto_ai_funghi
tr:
tr:has_prezzo
<http://www.trim.it/>.
“6”.
RDF prevede che ogni risorsa possa essere identificata univocamente mediante namespace
utilizzati dalle URI, e per evitare di riscriverli per ciascuna singola risorsa, che renderebbe la
lettura degli enunciati poco comprensibile, è possibile abbreviarli definendo dei prefissi. Il
primo enunciato, infatti, specifica che tr: è il prefisso che abbrevia il namespace dell’URI
http://www.trim.it/. Dopo aver definito il prefisso è possibile sostituire, nei successivi
enunciati, le URI con il rispettivo QName (in questo caso tr:).
Strutturare tutti i dati in questo modo comporta che a monte ci sia una organizzazione della
gestione della conoscenza, ovvero una struttura che definisca i tipi di risorse che
effettivamente saranno utilizzati e il tipo di relazioni che sussistono tra loro. Si tratta di
definire l’ontologia che riflette la conoscenza dei dati del menu per ristorante, così che possa
poi essere condivisa con altre fonti di conoscenza, associandole direttamente ed
indirettamente attraverso l’utilizzo di dinamiche inferenziali.
L’ontologia viene definita nell’RDF Schema che offre la possibilità di descrivere i tipi di risorse
definendone dei raggruppamenti; in accordo con quanto accade nel mondo dell’object-
orientation, è infatti possibile specificare se una risorsa è di tipo classe o sotto-classe o di
tipo proprietà o sotto-proprietà, e così via.
CAPITOLO 6 – VERSIONE BASATA SU RDF E SPARQL
61
In questo progetto i dati da strutturare, ovvero quelli di un menu per ristorante, dovevano
innanzitutto riguardare un singolo menu, in quanto ovviamente ciascuno amministratore
gestisce i dati relativi al menu del proprio ristorante, ed essere perciò identificati come
appartenenti ad un determinato ristorante. Per questo sono stati strutturati nel seguente
modo: una classe Ristorante avente una sotto-proprietà chiamata has_Name_Ristorante che
specifica il name_Ristorante che è una sotto-classe di Literal, ovvero un letterale. La classe
Ristorante ha una proprietà che definisce quali portate offre il suo menu, per l’appunto
chiamata offre che ha come codominio la classe Portata, sotto-classe di Ristorante.
Portata a sua volta ha una sotto-proprietà che definisce il suo nome, chiamata
has_Name_Portata e codominio name_Portata, sotto-classe di Literal. Portata ha anche una
proprietà, per definire i piatti che la compongono, chiamata is_composed che ha come
codominio la classe Piatto.
Piatto è sotto-classe di Portata e ha tre sotto-proprietà che puntano a tre differenti sotto-
classi di Literal, per specificare il nome del piatto, il prezzo e una sua descrizione. Queste tre
sotto-proprietà sono chiamate has_Name_Piatto, has_Prezzo_Piatto e
has_Descrizione_Piatto ed hanno rispettivamente come codominio name_Piatto,
prezzo_Piatto e descrizione_Piatto.
I nomi delle classi, delle proprietà e dei letterali sono stati assegnati arbitrariamente con lo
scopo di rendere maggiormente comprensibile il tipo di informazione che rappresentano.
Questa è la rappresentazione dell’RDF Schema in N3 del menu ristorante:
SOGGETTO PREDICATO OGGETTO
@prefix
@prefix
@prefix
tr:Ristorantre
tr:has_Name_Ristorante
tr:has_Name_Ristorante
tr:has_Name_Ristorante
tr:name_Ristorante
tr:Portata
tr:Portata
tr:offre
tr:offre
tr:offre
tr:has_Name_Portata
tr:has_Name_Portata
tr:has_Name_Portata
tr:name_Portata
rdf:
rdfs:
tr:
rdf: type
rdfs:subPropertyOf
rdf:domain
rdf:range
rdfs:subClassOf
rdf:type
rdfs:subClassOf
rdf:type
rdf:domain
rdf:range
rdfs:subPropertyOf
rdf:domain
rdf:range
rdfs:subClassOf
<http://www.3w.org/1999/02/22-rdf-syntax-ns#>.
<http://www.w3.org/2000/01/rdf-schema#>.
<http://www.trim.it/>.
rdfs:Class.
rdfs:label.
tr:Ristorante.
tr:name_Ristorante.
rdfs:Literal.
rdfs:Class.
tr:Ristorante.
rdf:Property.
tr:Ristorante.
tr:Portata.
rdfs:label.
tr:Portata.
tr:name_Portata.
rdfs:Literal.
CAPITOLO 6 – VERSIONE BASATA SU RDF E SPARQL
62
tr:Piatto
tr:Piatto
tr:is_composed
tr:is_composed
tr:is_composed
tr:has_Name_Piatto
tr:has_Name_Piatto
tr:has_Name_Piatto
tr:name_Piatto
tr:has_Prezzo_Piatto
tr:has_Prezzo_Piatto
tr:has_Prezzo_Piatto
tr:prezzo_Piatto
tr:has_Descrizione_Piatto
tr:has_Descrizione_Piatto
tr:has_Descrizione_Piatto
tr:descrizione_Piatto
rdf:type
rdfs:subClassOf
rdf:type
rdf:domain
rdf:range
rdfs:subPropertyOf
rdf:domain
rdf:range
rdfs:subClassOf
rdfs:subPropertyOf
rdf:domain
rdf:range
rdfs:subClassOf
rdfs:subPropertyOf
rdf:domain
rdf:range
rdfs:subClassOf
rdfs:Class.
tr:Portata.
rdf:Property.
rdf:Portate.
rdf:Piatto.
rdfs:label.
tr:Piatto.
tr:name_Piatto.
rdfs:Literal.
rdfs:label.
tr:Piatto.
tr:prezzo_Piatto.
rdfs:Literal.
rdfs:label.
tr:Piatto.
tr:descrizione_Piatto.
rdfs:Literal.
Nella figura una rappresentazione dell’ontologia a grafo orientato ed etichettato:
Figura 17 - Ontologia del menu di un ristorante.
Definita l’ontologia è poi semplice descrivere tutte le risorse. Per esempio per rappresentare
un primo, come nel caso precedente ‘risotto ai funghi’, ed indicare a che tipo di portata
appartiene, quale è il suo nome, quale il suo prezzo e quale la sua descrizione vengono
utilizzate le seguenti triple:
CAPITOLO 6 – VERSIONE BASATA SU RDF E SPARQL
63
SOGGETTO PREDICATO OGGETTO
tr:Secondi
tr:Risotto_ai_funghi
tr:Risotto_ai_funghi
tr:Risotto_ai_funghi
tr:Risotto_ai_funghi
tr:is_composed
rdf:type
tr:has_Nome_Piatto
tr:has_Prezzo_Piatto
tr:has_Descrizione_Piatto
tr:Risotto_ai_funghi.
tr:Piatto.
"Risotto ai funghi".
"8.00".
"Con funghi porcini".
6.3 TOOLKIT SPARQL
Realizzati i file RDF e RDF Schema in formato N3, è necessario poter usare gli enunciati
presenti in questi files, quindi poter ottenere quelli desiderati e poterne salvare degli altri: il
linguaggio specifico per interrogare i file RDF è SPARQL.
Per la realizzazione del progetto, con la versione basata su RDF e SPARQL, è stata utilizzata la
libreria ARC2 per il motore di query SPARQL e per il caricamento e la gestione delle
ontologie. ARC2 è un framework realizzato in Php che traduce le espressioni SPARQL in
espressioni SQL, permettendo così di immagazzinare i propri dati RDF in database relazionali.
Essendo le parti del componente CMS realizzate con il linguaggio PHP, la scelta di utilizzare
questo framework anziché un altro è principalmente dovuta al fatto che anche ARC2 è
realizzato in PHP, quindi una scelta volta ad avere una coerenza di linguaggi di
programmazione.
6.3.1 Impostazioni iniziali
ARC2 introduce una classe statica che è tutto ciò che deve essere incluso. Qualsiasi altro
componente può essere caricato tramite ARC2, senza la necessità di conoscere l'esatto
percorso del file di classe.
include_once(“path/to/arc/ARC2.php”);
Una volta che la classe statica ARC2 è messa a disposizione, è possibile caricare i componenti
con le semplici chiamate di metodo e iniziare a utilizzarli:
$parser = ARC2::getRDFParser();
$parser->parse('http://example.com/foaf.ttl');
$triples = $parser->getTriples();
6.3.2 Requisiti del database
Alcuni componenti hanno bisogno di un database MySQL (per esempio l'archivio di RDF e il
motore SPARQL). Il database deve essere configurato in anticipo cosicché ARC2 possa creare
in automatico le tabelle necessarie. Un unico database è sufficiente per creare più negozi
ARC2 ed è possibile fornire un nome personalizzato per ogni negozio, che viene poi
utilizzato, come prefisso della tabella.
CAPITOLO 6 – VERSIONE BASATA SU RDF E SPARQL
64
Le opzioni di configurazione possono essere fornite con qualsiasi istanza della classe che
vengono caricate dinamicamente e specificate una volta per tutte:
$config = array(
/* db */
'db_host' => 'localhost', /* default: localhost */
'db_name' => 'my_db',
'db_user' => 'user',
'db_pwd' => 'secret',
/* store */
'store_name' => 'arc_tests',
);
$store = ARC2::getStore($config);
$store -> query ( 'LOAD <file:///mio_file_rdf.rdfxml>' );
Se un eventuale errore di trattamento si dovesse verificare, verrebbe registrato e trasmesso
al componente chiamante, in modo tale da esplicitare il tipo di errore verificatosi:
$rs = $store->query('...');
if ($errs = $store->getErrors()) {
/* $errs contiene errori di $store*/
...
}
Con la funzione $store->query('...') è possibile effettuare le diverse query, con linguaggio
SPARQL, al database. Con la chiamata $store -> query ( 'LOAD <file:///mio_file_rdf.rdfxml>' )
sono stati caricati tutti gli enunciati che descrivono le risorse di questo progetto, contenuti
nel file mio_file_rdf.rdfxml, all’interno del database, così da effettuare query direttamente al
database.
6.3.3 Esempio di query utilizzate
Ecco qualche esempio di query SPARQL realizzate utilizzando il framework ARC2:
public function get_piatti() {
$q = "PREFIX rdf: <http://www.3w.org/1999/02/22-rdf-syntax-ns#> ".
"PREFIX dc: <http://purl.org/dc/elements/1.1#> ".
"PREFIX tr: <http://www.trim.it/> ".
"SELECT ?id_piatto ?nome ?prezzo ?descrizione ?tipo_portata ".
"WHERE {
?id_piatto rdf:type tr:Piatto.
?id_piatto tr:has_Name_Piatto ?nome.
?id_piatto tr:has_Prezzo_Piatto ?prezzo.
?id_piatto tr:has_Descrizione_Piatto ?descrizione.
?tipo_portata tr:is_composed ?id_piatto.
}";
if ($rows = $this->store->query( $q, 'rows' ))
return $rows;
else
CAPITOLO 6 – VERSIONE BASATA SU RDF E SPARQL
65
return null;
}
Con questa funzione PHP vengono estrapolate dal database informazioni, già precaricate su
quest’ultimo, relative ai piatti. La query è molto semplice, con SELECT vengono passate le
incognite da trovare, che sono dei nomi arbitrari preceduti dal ‘?’, mentre con WHERE viene
specificato il path expression, ovvero l’insieme delle triple necessarie a rispondere
all’interrogazione. Da questa query viene restituito un’array associativo con key uguali ai
nomi delle incognite senza il ‘?’.
Il successivo è un esempio di INSERT INTO:
public function aggiungi_piatto($id_piatto, $id_portata, $nome_piatto, $prezzo){
$q = "PREFIX rdf: <http://www.3w.org/1999/02/22-rdf-syntax-ns#> ".
"PREFIX dc: <http://purl.org/dc/elements/1.1#> ".
"PREFIX tr: <http://www.trim.it/> ".
"INSERT INTO <http://www.trim.it/> { ".
"tr:".$id_portata." tr:is_composed tr:".$id_piatto.". ".
"tr:".$id_piatto." rdf:type tr:Piatto. ".
"tr:".$id_piatto." tr:has_Name_Piatto \"".$nome_piatto."\". ".
"tr:".$id_piatto." tr:has_Prezzo_Piatto \"".$prezzo."\". ".
"tr:".$id_piatto." tr:has_Descrizione_Piatto \"".$nome_piatto."\". ".
"}";
If ( $rs = $this->store->query( $q ) )
return $rs;
else
return null;
}
Con questa funzione PHP invece viene inserito un nuovo piatto nel database passando in
input quattro valori, che sono l’identificativo del piatto, l’identificativo della portata a cui
appartiene il piatto, il nome del piatto ed infine il prezzo. Questi valori integrano il path
expression della query per raffinare la ricerca.
Ultimo esempio a riguardo la funzione DELETE FROM:
public function elimina_piatto( $id_portata, $id_piatto ){
$q = "PREFIX rdf: <http://www.3w.org/1999/02/22-rdf-syntax-ns#> ".
"PREFIX dc: <http://purl.org/dc/elements/1.1#> ".
"PREFIX tr: <http://www.trim.it/> ".
"DELETE FROM <http://www.trim.it/> { ".
"tr:".$id_piatto." rdf:type tr:Piatto. ".
"tr:".$id_piatto." tr:has_Name_Piatto ?nome. ".
"tr:".$id_piatto." tr:has_Prezzo_Piatto ?prezzo. ".
"tr:".$id_piatto." tr:has_Descrizione_Piatto ?descrizione. ".
"tr:".$id_portata." tr:is_composed tr:".$id_piatto.
" }";
If ( $rs = $this->store->query($q) )
return $rs;
CAPITOLO 6 – VERSIONE BASATA SU RDF E SPARQL
66
else
return null;
}
In questo caso la funzione permette di eliminare un piatto specificandone in input il suo
identificativo e l’identificativo della portata a cui appartiene. Anche in questo caso il path
expression si compone con i valori passati in input.
Questi esempi completano la presentazione del progetto realizzato con la prima versione,
ovvero quella basata su RDF e SPARQL. Nel corso del capitolo è stato presentato come i dati
debbano essere strutturati con la logica della semantica partendo da una loro
rappresentazione ontologica. Ed infine come questi possano essere interrogati con SPARQL
mediante l’ausilio del framework ARC2. Nel prossimo capitolo sarà affrontata la seconda
versione partendo da considerazioni, fatte proprio in questo capitolo, sull’ontologia dei dati
di un menu per ristorante.
67
CAPITOLO 7
VERSIONE BASATA SU INDEX
CAPITOLO 7 – VERSIONE BASATA SU INDEX
68
Fin qui il progetto ha visto la realizzazione della prima versione, quella basata su RDF e
SPARQL: è stata pertanto realizzata un’interfaccia Web che permette la gestione di un menu
per ristorante e che, a livello back-end, strutturara i dati con la logica della semantica,
esprimendo tutte le risorse in triple soggetto-predicato-oggetto, e li interroga con query
SPARQL per caricare e salvare i dati in un database.
In questo capitolo viene invece proposta la versione basata su Index e, a fronte della sua
realizzazione, le analisi effettuate sulle possibili interpretazioni per la risoluzione del
problema principale:
“È possibile utilizzare Index per rappresentare i dati in modo semantico?”
7.1 PRIMO APPROCCIO AD INDEX
Per poter affrontare tematiche come “che tipo di interrogazioni è possibile effettuare ad
Index?” e “quali dati è possibile trattare?” è importante conoscere i Web Service di Index.
I servizi messi a disposizione da Index sono presenti su file WSDL (Web Services Description
Language) che contengono informazioni su cosa può essere utilizzato (le “operazioni” messe
a disposizione dal servizio), come utilizzarlo (il protocollo di comunicazione da utilizzare per
accedere al servizio, il formato dei messaggi accettati in input e restituiti in output dal
servizio ed i dati correlati, ovvero i “vincoli”, bindings in inglese, del servizio) e dove
utilizzarlo (il cosiddetto endpoint del servizio che solitamente corrisponde all'indirizzo, in
formato URI, che rende disponibile il Web Service). Pertanto lo studio si è focalizzato sui file
WSDL di Index, ed in particolare ecmengine-backoffice.wsdl e ecmengine-management.wsdl.
Il primo descrive il servizio di backoffice con operazioni appartenenti a 4 categorie principali:
o gestione utenti e gruppi (creazione, modifica, cancellazione, ricerca);
o access Control List (creazione, modifica, cancellazione);
o gestione repository logici;
o informazioni del sistema.
Il secondo file invece descrive il servizio di management e qui troviamo operazioni
appartenenti a 5 categorie principali:
o gestione contenuti (creazione, modifica, cancellazione);
o controllo del formato dei contenuti;
o versioning;
o check-in/check-out (con locking);
o gestione di cicli semplici di approvazione;
o auditing.
CAPITOLO 7 – VERSIONE BASATA SU INDEX
69
Quindi per capire meglio come utilizzarli sono state realizzate delle chiamate SOAP ad Index
in linguaggio Php per creare nuovi utenti, nuove cartelle, inserire file testuali, etc. Ecco un
esempio:
<?php
class MyFunction {
var $clientM;
public function __construct() {
$this->clientM = new SoapClient("ecmengine-management.wsdl",
array('location'=>"http://localhost:8080/ecmengine/services/EcmEngineManagement"));
}
public function crea_content() {
/* OperationContext - info per l'autenticazione */
$ctx = array('username'=>'admin', 'password'=>'admin', 'nomeFisico'=>'Ammin',
'fruitore'=>'Esempio');
/* Metadati del contenuto... */
$metadati = array('prefixedName'=>'cm:name', 'dataType'=>'d:text', 'values'=>array('mio.txt'),
'multivalue'=>false);
/* Contenuto */
$text="Nuovo file di testo";
$myFile = array('properties'=>array($metadati), 'prefixedName'=>'cm:mio.txt',
'typePrefixedName'=>'cm:content','parentAssocTypePrefixedName'=>'cm:contains',
'contentPropertyPrefixedName'=>'cm:content', 'mimeType'=>'txt',
'encoding'=>'UTF-8', 'content'=>$text);
/* Creazione del Node */
$xpath = array('XPathQuery'=>'/app:company_home', 'fullTextAllWords'=>false, 'limit'=>0,
'pageIndex'=>0, 'pageSize'=>0);
try {
$myNode = $this->clientM->getUid($xpath, $ctx);
}catch(Exception $e) {
echo $e;
}
/* Eseguo la creazione... */
$myNewNode = $this->clientM->createContent($myNode, $myFile, $ctx);
/* A questo punto la variabile myNewNode conterra' i riferimenti al contenuto appena creato sul
repository "primary". */
}
?>
In questo esempio ci sono due funzioni, la prima è il costruttore della classe MyFunction che
crea un’istanza ClientM della classe SoapClient passando in input ecmengine-
management.wsdl, mentre la seconda funzione consente di creare un file testuale e inserirlo
in Index. Tutte le funzioni di management utilizzabili in Index e descritte nel file WSDL
CAPITOLO 7 – VERSIONE BASATA SU INDEX
70
possono essere chiamate come metodi dell’oggetto SoapClient, come ad esempio clientM-
>getUid(..) e clientM->ceateContent(..).
Già da questo piccolo esempio è possibile notare quanti parametri bisogna passare alle
funzioni di Index; e se questi non sono coerenti con le specifiche stesse di Index, le chiamate
creano solo delle eccezioni. Inoltre si nota come la creazione di un contenuto comporti
anche la creazione dei suoi metadati, questo è un elemento importante in Index, infatti ogni
nodo, cartella o file può avere informazioni aggiuntive sui metadati ed anche sulle
associazioni con altri nodi, cartelle o file. Questo elemento tornerà altresì utile nella
realizzazione finale progetto con questa soluzione e sarà oggetto di approfondimento nel
paragrafi successivi.
7.2 DUE POSSIBILI SOLUZIONI
Dopo un primo approccio ai servizi di Index resta da capire se con il Content Management di
DoQui, ovvero Index, sia possibile strutturare i dati in triple e se sia possibile interrogarli in
quel formato. In Index il servizio di “management” permette di creare, modificare e
eliminare cartelle, nodi, categorie, file e relativi metadati e DoQui è un sistema di gestione
documentale che permette, grazie a Index, di salvare documenti in qualsiasi formato e che
consente una ricerca testuale dei suoi documenti, pertanto questi documenti sono trattati
come semplici file di testo e non è possibile effettuare analisi sulla loro struttura interna, per
esempio in caso di file XML non è possibile fare il parsing dei tag presenti.
Da questa analisi ne deriva che sia inutile caricare su DoQui file RDF, in quanto non è
possibile gestirli internamente a meno che non si valutino due soluzioni:
o caricare file RDF all’interno di DoQui e permettere ai client esterni di prelevarli e di
gestirli con un EndPoint SPARQL esterno;
o caricare file RDF all’interno di DoQui e creare un EndPoint interno a DoQui così che i
client esterni possano direttamente interrogare i file RDF con Index stesso.
Analizzando i pro e i contro si evince che di entrambe le soluzioni il pro è che i dati sono
rappresentati con la logica della semantica e salvati in RDF e con Index allocati in DoQui, ma i
contro di queste soluzioni non permettono di soddisfare completamente l’esigenza iniziale:
o la prima soluzione comporta che Index, e di conseguenza anche DoQui, non abbia la
possibilità di trattare i file RDF, interrogandoli. Si ritrova quindi ad essere un mero
deposito per gli RDF e non sapere effettivamente cosa siano e cosa farne; si
potrebbero effettuare solo ricerche testuali su questi file ma niente di più. Quindi la
soluzione numero uno è bocciata, anche perché DoQui non semplificherebbe il lavoro
ai client che dovrebbero, successivamente alla richiesta del file RDF, analizzarlo con
un EndPoit SPARQL esterno ed eventualmente effettuare nuove chiamate a Index
qualora nell’RDF ci fossero collegamenti a dati multimediali contenuti in Index stesso;
CAPITOLO 7 – VERSIONE BASATA SU INDEX
71
o la seconda soluzione invece non rientra nelle logiche applicative di DoQui, inserire un
EndPoint SPARQL al suo interno sarebbe una forzatura alla sua stessa architettura.
Seguendo questa strada si dovrebbe effettuare una riprogettazione strutturale del
suo interno che comporterebbe un lavoro non indifferente e non è esattamente ciò
che si vuol fare. L’EndPoint SPARQL dovrebbe eventualmente essere considerato
come un bridge tra il repository e il fruitore dei contenuti e non parte interna di
DoQui.
Figura 18 – Prime due soluzioni per gestire i dati in modo semantico con DoQui.
La figura rappresenta le prime due soluzioni analizzate su come Index possa rappresentare i
dati in modo semantico, soluzioni mostratesi non ideali per poterne permettere un loro
utilizzo interno senza stravolgere l’architettura propria di Index.
7.3 SOLUZIONE ADOTTATA
La soluzione finale del progetto, in questa sua versione, è scaturita osservando proprio la
rappresentazione grafica dell’ontologia dei dati di un menu per ristorante (vedi figura 17).
La rappresentazione grafica di un ontologia altro non è che un grafo orientato ed
etichettato, ovvero nodi connessi tra loro attraverso archi orientati ed etichettati (con un
peso o valore) ed una rappresentazione a grafo in Index è possibile realizzarla difatti con
Index è possibile realizzare nodi e definirne il tipo di associazioni.
La soluzione finale è volta quindi a rappresentare gli enunciati, che esprimono le risorse,
mediate la creazione di nodi collegati tra loro all’interno del repository di Index, dove già
tutti i suoi contenuti hanno una rappresentazione a grafo. Consentendo così ad un client
CAPITOLO 7 – VERSIONE BASATA SU INDEX
72
esterno di interrogare Index mediante linguaggio XPath49 e ricevere come risposta
l’informazione desiderata, lasciando interamente ad Index la gestione dei dati.
La figura che segue mostra la logica della terza soluzione, ovvero quella finale:
Figura 19 - Terza soluzione (finale) per gestire i dati in modo semantico con DoQui.
Questa soluzione ha portato a tre tipi di interpretazioni differenti:
Figura 20 - Terza soluzione per gestire i dati in modo semantico con DoQui.
49
XPath è un linguaggio parte della famiglia XML che permette di individuare nodi all'interno di un documento
XML. Le espressioni XPath, a differenza delle espressioni XML, non servono a identificare la struttura di un
documento, bensì a localizzarne con precisione i nodi.
CAPITOLO 7 – VERSIONE BASATA SU INDEX
73
La prima idea è stata quella di rappresentare gli enunciati (soggetto-predicato-oggetto), nel
repository di Index, utilizzando un nodo per il soggetto, un altro nodo per l’oggetto e la
rispettiva associazione per il predicato, e più precisamente utilizzando un nodo chiamato con
lo stesso valore del soggetto, un altro chiamato con lo stesso nome dell’oggetto e la
rispettiva associazione chiamata con il valore del predicato. Un’interpretazione che presenta
un problema: in Index è necessario definire tutti i tipi di associazione che vogliamo tra i nodi
attraverso i custom content model50, ma questi devono essere creati e caricati in Index in
anticipo rispetto all’inserimento dei nostri dati. Il che comporta una mancanza di dinamicità,
infatti nel momento in cui si decide di utilizzare una nuova proprietà, per definire l’oggetto di
un soggetto, si deve modificare il custom content model e ricaricarlo in Index.
La seconda intuizione è stata quella di creare un nodo per ciascun elemento dell’enunciato,
tenendo presente di non inserirne di nuovi, nel momento in cui qualche elemento si fosse
ripetuto, in modo tale da non creare duplicati del soggetto, dell’oggetto o del predicato. Ma
anche questa interpretazione presenta un problema, un problema in fase di ricerca (come
mostrato nella figura che segue), infatti supponendo che due soggetti (nodi), S1 e S2,
abbiano un predicato P1 in comune e che questo definisca un oggetto O1 per S1 e un
secondo oggetto O2 per S2, in fase di ricerca, con Index, chiedendo quale oggetto definisce il
predicato P1 per S1, ci darà come risposta sia O1 che O2, il che è sbagliato.
Figura 21 - Problema della seconda interpretazione.
La risoluzione di questo problema giunge con la terza interpretazione, ovvero far sì che i nodi
che costituiscono l’enunciato abbiano una rappresentazione gerarchica, il che comporta che
il predicato sia annidato nel soggetto e che l’oggetto a sua volta nel predicato.
Nel momento in cui troviamo un enunciato con un soggetto già inserito, questo non deve
essere duplicato e quindi il predicato dell’enunciato deve essere annidato all’interno del
soggetto già esistente e l’oggetto annidato nel predicato dell’oggetto.
Nel caso in cui oltre al soggetto anche il predicato si ripete, si deve solo annidare l’oggetto
del nuovo enunciato nel predicato esistente già annidato nel soggetto anch’esso già
esistente.
50
I content model descrivono le caratteristiche dei nodi e delle associazioni dei contenuti che si trovano
all’interno del repository. In quanto i contenuti sono rappresentati come grafo composto da due elementi
base: il nodo e l’associazione. Quest’ultima può essere di tipo padre-figlio o semplice.
CAPITOLO 7 – VERSIONE BASATA SU INDEX
74
Questa soluzione quindi prevede che ci siano duplicati
del predicato e dell’oggetto, ma non del soggetto,
ciononostante, essendo organizzati in modo
gerarchico, questo non crea conflitti durante la fase di
ricerca.
In questo modo è possibile rappresentare con Index i
dati in modo semantico, rispondendo pertanto alla
domanda iniziale del mio progetto di tesi, ovvero “E’
possibile utilizzare Index per rappresentare i dati in
modo semantico?”. Partendo da questo punto è stata
realizzata la seconda versione del progetto, facendo sì
che l’interfaccia Web per la gestione di un menu per
ristorante, già realizzata, dialogasse direttamente con
Index e che quest’ultimo gestisse i dati strutturandoli
con la soluzione appena argomentata.
7.4 CUSTOM CONTENT MODEL
La soluzione appena trovata comporta che i nodi da creare all’interno di Index abbiano
particolari specifiche. Il servizio di management di Index impone che ad ogni nodo, nel
momento della sua creazione, vengano definite determinate variabili, tra queste ce ne sono
due particolarmente utili: typePrefixedName e parentAssocTypePrefixedName, che servono
a specificare il tipo di nodo che si sta creando ed il tipo di associazione con il nodo padre.
Quindi dovendo creare nodi del tipo soggetto, predicato e oggetto, questi avranno
associazioni con il nodo padre rispettivamente del tipo repository-soggetto, soggetto-
predicato e predicato-oggetto.
Ma per poter utilizzare nuovi tipi di nodo personalizzati, come in questo caso, è necessario
definirli creando un nuovo custom content model e quest’ultimo inserito in Index. Nel
custom content model per ciascun nodo personalizzato si deve definire il nome del tipo e, a
differenza del serzvizio di management dove è necessario definire il tipo di associazione con
il nodo padre, il nome del tipo di associazione con un nodo figlio. Ecco il custom content
model realizzato per definire il tipo di nodi utilizzati:
<model name="rdf:rdfmodel" xmlns="http://www.alfresco.org/model/dictionary/1.0">
<description>TRIM RDF Model</description>
Figura 22 - Terza interpretazione.
CAPITOLO 7 – VERSIONE BASATA SU INDEX
75
<author>TRIM S.r.l.</author>
<published>2009-09-20</published>
<version>1.0</version>
<imports>
<import uri="http://www.alfresco.org/model/dictionary/1.0" prefix="d"/>
<import uri="http://www.alfresco.org/model/system/1.0" prefix="sys"/>
</imports>
<namespaces>
<namespace uri="http://www.trim.it/model/rdf/1.0" prefix="rdf"/>
</namespaces>
<types>
<type name="rdf:oggetto">
<title>Oggeto RDF</title>
<parent>sys:base</parent>
<properties>
<property name="rdf:nomeOggetto">
<title>Nome</title>
<type>d:text</type>
<mandatory enforced="true">true</mandatory>
</property>
</properties>
<associations>
<child-association name="rdf:oggettoPredicato">
<source>
<mandatory>false</mandatory>
<many>false</many>
</source>
<target>
<class>rdf:predicato</class>
<mandatory>false</mandatory>
<many>true</many>
</target>
</child-association>
</associations>
</type>
<type name="rdf:predicato">
<title>Predicato RDF</title>
<parent>sys:base</parent>
<properties>
<property name="rdf:nomePredicato">
<title>Name</title>
<type>d:text</type>
<mandatory enforced="true">true</mandatory>
</property>
</properties>
<associations>
CAPITOLO 7 – VERSIONE BASATA SU INDEX
76
<child-association name="rdf:predicatoOggetto">
<source>
<mandatory>false</mandatory>
<many>false</many>
</source>
<target>
<class>rdf:oggetto</class>
<mandatory>false</mandatory>
<many>true</many>
</target>
</child-association>
</associations>
</type>
</types>
</model>
Con tale custom content model vengono definiti due nodi, il primo chiamato
rdf:nomeOggetto, per rappresentare i nodi “soggetto” e i nodi “oggetto” ed il secondo
rdf:nomePredicato, per rappresentare i nodi “predicato”, aventi come nomi dell’associazioni
con i propri nodi figli rispettivamente rdf:oggettoPredicato e rdf:predicatoOggetto. Tali
associazioni implicano che rdf:nomeOggetto possa avere solo figli predicato e che
rdf:nomePredicato solo figli oggetto.
Inoltre nei tag mandatory vengono inseriti valori booleani per specificare se i nodi possono
avere uno o più figli e se loro stessi hanno uno o più padri, così ho imposto che
rdf:nomeOggetto possa avere un solo padre e più figli di tipo predicato mentre
rdf:nomePredicato un solo padre e più figli di tipo oggetto.
Figura 23 - ECM Web Console di Index.
CAPITOLO 7 – VERSIONE BASATA SU INDEX
77
La figura 23 mostra l’interfaccia della
ECM (Enterprise Content Management)
Web Console di Index, attraverso cui è
possibile constatare l’effettiva
realizzazione dei contenuti effettuata
mediante la componente CMS
appositamente progettata.
La figura 24 è un ingrandimento della
figura 23, in particolare della struttura
interna dei nodi.
Figura 24 - Struttura dei nodi all'interno della ECM Web Console.
78
CAPITOLO 8
VALUTAZIONI
CAPITOLO 8 - VALUTAZIONI
79
La soluzione finale sviluppata nella seconda versione del progetto, ovvero quella basata su
Index, ha permesso di giungere alla realizzazione dell’obiettivo principale: realizzare un
componente CMS per la gestione a livello amministrativo di un menu per ristoranti che
possa dialogare con DoQui per immagazzinare e prelevare i dati e che questi possano essere
gestiti da quest’ultimo attraverso la logica della semantica. Obiettivo raggiunto dopo aver
effettuato diverse analisi in modo da capire quale fosse la strada migliore da percorrere. In
conclusione è stato fattibile rispondere alla quesito:
“E’ possibile utilizzare Index per rappresentare i dati in modo semantico?”
Sì è possibile utilizzare Index per rappresentare e utilizzare i dati in modo semantico,
convertendo le triple degli enunciati, che rappresentano le risorse, in nodi strutturati in
modo gerarchico all’interno del repository di Index. Per ogni tripla esisteranno tre nodi nel
repository che rappresenteranno il soggetto, il predicato e l’oggetto, e saranno nominati
rispettivamente con il valore del soggetto, del predicato e dell’oggetto. La struttura
gerarchica dunque, consentirà l’esistenza di duplicati del predicato e dell’oggetto ma non del
soggetto.
8.1 CONFRONTI
Le due versioni del progetto realizzate (vedi figura 25), la prima basata su RDF e SPARQL e la
seconda su Index, hanno permesso un confronto finale consentendo di analizzarne i pro e
contro.
Figura 25 - Le due versioni finali del progetto realizzato.
Di seguito un’analisi delle due versioni che per comodità saranno indicate con ‘A’ per
identificare la prima versione (RDF e SPARQL) e con ‘B’ per identificare la seconda (Index):
o Effettiva integrazione con DoQui:
chiaramente la versione A non interagisce con DoQui perché è stata realizzata
utilizzando RDF e SPARQL proprio per avere un modello ad hoc nel trattamento dei
dati semantici nel Web e quindi per poter fare un confronto con la versione B, che si
basa fondamentalmente sull’interazione con Index, quindi con DoQui.
CAPITOLO 8 - VALUTAZIONI
80
o Facilità di sviluppo a livello back-end:
sicuramente la realizzazione della versione A è stata meno complessa, inoltre
l’utilizzo del framework ARC2 ha reso più facile la gestione degli enunciati sia nel
caricamento su database che nelle interrogazioni. L’unica laboriosità è stata la
realizzazione delle query ad hoc in linguaggio SPARQL.
Invece la realizzazione della versione B è stata più complessa e più dispendiosa come
righe di codice scritto, infatti per ogni nodo creato all’interno del repository di Index
è necessario inserire i valori per quasi tutte le sue proprietà e per le proprietà dei
suoi metadati, inoltre è indispensabile specificare quale è il nodo padre a cui sarà
“agganciato”.
Prendendo come esempio le funzioni per la creazione di portate e piatti all’interno
del menu per ristorante, nella versione A avremo:
public function aggiungi_portata($id_portata, $nome_portata){
$q = "PREFIX rdf: <http://www.3w.org/1999/02/22-rdf-syntax-ns#> ".
"PREFIX dc: <http://purl.org/dc/elements/1.1#> ".
"PREFIX tr: <http://www.trim.com/> ".
"INSERT INTO <http://www.trim.com/> { ".
"tr:".$id_portata." rdf:type tr:Portata . " .
"tr:".$id_portata." tr:has_Name_Portata \"".$nome_portata."\". ".
"}";
$rs = $this->store->query($q);
if ($err = $this->store->getErrors()) {
var_dump( $err );
}
}
public function aggiungi_piatto($id_piatto, $id_portata, $nome_piatto, $prezzo){
$q = "PREFIX rdf: <http://www.3w.org/1999/02/22-rdf-syntax-ns#> ".
"PREFIX dc: <http://purl.org/dc/elements/1.1#> ".
"PREFIX tr: <http://www.trim.com/> ".
"INSERT INTO <http://www.trim.com/> { ".
"tr:".$id_portata." tr:is_composed tr:".$id_piatto.". ".
"tr:".$id_piatto." rdf:type tr:Piatto. ".
"tr:".$id_piatto." tr:has_Name_Piatto \"".$nome_piatto."\". ".
"tr:".$id_piatto." tr:has_Prezzo_Piatto \"".$prezzo."\". ".
"tr:".$id_piatto." tr:has_Descrizione_Piatto \"".$nome_piatto."\". ".
"}";
$rs = $this->store->query($q);
if ($err = $this->store->getErrors()) {
var_dump( $err );
}
}
Mentre nella versione B avremo:
/* VERIFICA ESISTENZA NODO */
public function exist_node($xpath,$ctx){
CAPITOLO 8 - VALUTAZIONI
81
$b;
try {
$this->clientM->nodeExists($xpath, $ctx);
$b = TRUE;
}catch(Exception $e) {
$b = FALSE;
}
return $b;
}
/* CREARE SOGGETTO PREDICATO OGGETTO */
public function crea_soggetto_predicato_oggetto($s, $p, $o) {
/* OperationContext - info per l'autenticazione */
$ctx = array('username'=>'admin', 'password'=>'admin', 'nomeFisico'=>'Amministratore',
'fruitore'=>'Esempio WIKI');
/* Metadati del contenuto... */
$metadati_sogg = array('prefixedName'=>'rdf:nomeOggetto', 'dataType'=>'d:text',
'values'=>array($s), 'multivalue'=>false);
$metadati_pred = array('prefixedName'=>'rdf:nomePredicato', 'dataType'=>'d:text',
'values'=>array($p), 'multivalue'=>false);
$metadati_ogg = array('prefixedName'=>'rdf:nomeOggetto', 'dataType'=>'d:text',
'values'=>array($o), 'multivalue'=>false);
/* Contenuto Soggetto*/
$mySogg = array('properties'=>array($metadati_sogg), 'prefixedName'=>'rdf:'.$s,
'typePrefixedName'=>'rdf:oggetto', 'parentAssocTypePrefixedName'=>'cm:contains');
/* Contenuto Preicato */
$myPred = array('properties'=>array($metadati_pred), 'prefixedName'=>'rdf:'.$p,
'typePrefixedName'=>'rdf:predicato', 'parentAssocTypePrefixedName'=>'rdf:soggettoPredicato');
/* Contenuto Oggetto */
$myOgg = array('properties'=>array($metadati_ogg), 'prefixedName'=>'rdf:'.$o,
'typePrefixedName'=>'rdf:oggetto', 'parentAssocTypePrefixedName'=>'rdf:predicatoOggetto');
/* Creazione del Node Sogg */
$xpath_s = array('XPathQuery'=>'/app:company_home/cm:ristorante', 'fullTextAllWords'=>false,
'limit'=>0, 'pageIndex'=>0, 'pageSize'=>0);
/* Creazione del Node Pred */
$xpath_p = array('XPathQuery'=>'/app:company_home/cm:ristorante/rdf:'.$s,
'fullTextAllWords'=>false, 'limit'=>0, 'pageIndex'=>0, 'pageSize'=>0);
/* Creazione del Node Ogg */
$xpath_o = array('XPathQuery'=>'/app:company_home/cm:ristorante/rdf:'.$s.'/rdf:'.$p,
'fullTextAllWords'=>false, 'limit'=>0, 'pageIndex'=>0, 'pageSize'=>0);
$xpath_full = array('XPathQuery'=>'/app:company_home/cm:ristorante/rdf:'.$s.'/rdf:'.$p.'/rdf:'.$o,
'fullTextAllWords'=>false, 'limit'=>0, 'pageIndex'=>0, 'pageSize'=>0);
if( $this->exist_node($xpath_p,$ctx) ){
if( $this->exist_node($xpath_o, $ctx) ){
if( !$this->exist_node($xpath_full, $ctx) ){
$Node_o = $this->clientM->getUid($xpath_o, $ctx);
$newNodeOgg = $this->clientM->createContent($Node_o, $myOgg, $ctx);
}
}else{
$Node_p = $this->clientM->getUid($xpath_p, $ctx);
$newNodePred = $this->clientM->createContent($Node_p, $myPred, $ctx);
CAPITOLO 8 - VALUTAZIONI
82
$Node_o = $this->clientM->getUid($xpath_o, $ctx);
$newNodeOgg = $this->clientM->createContent($Node_o, $myOgg, $ctx);
}
}else{
$Node_s = $this->clientM->getUid($xpath_s, $ctx);
$newNodeSogg = $this->clientM->createContent($Node_s, $mySogg, $ctx);
$Node_p = $this->clientM->getUid($xpath_p, $ctx);
$newNodePred = $this->clientM->createContent($Node_p, $myPred, $ctx);
$Node_o = $this->clientM->getUid($xpath_o, $ctx);
$newNodeOgg = $this->clientM->createContent($Node_o, $myOgg, $ctx);
}
}
È lampante la differenza in righe di codice e la complessità di ciascuna riga nella
versione B.
o Complessità delle query:
Nella versione A le query sono in linguaggio SPARQL, un linguaggio molto semplice e
soprattutto flessibile in quanto permette di effettuare qualsiasi tipo di
interrogazione. Altrettanto flessibile la risposta che restituisce una query SPARQL, di
default è un’array associativo contenete i valori cercati, altrimenti se specificato nella
query stessa, può restituire i dati in formato RDF o XML.
La versione B per le query a Index utilizza il linguaggio XPath, un linguaggio ad hoc
per localizzare precisamente i nodi, in questo caso, all’interno del repository. Le
risposte di tali query però sono più complesse da gestire, infatti una quey XPath
effettuata per cercare determinati nodi restituisce come risposta una lista di UID dei
nodi trovati. Questo comporta che sulla risposta ottenuta debbano essere effettuati
successivi adeguamenti per convertirla in un’array associativo contenente i valori
cercati.
Il progetto nelle sue due versioni non presenta delle query esageratamente
complesse, per questo è stato possibile realizzarle senza grandi problemi sia in
linguaggio SPARQL che XPath, ma nel momento in cui si dovessero effettuare delle
query più elaborate la realizzazione in linguaggio XPath e la successiva gestione della
risposta diverrebbero molto più difficili nelle loro logiche applicative.
o Prestazioni-velocità:
Nella gestione dei calcoli la versione A risulta essere più veloce rispetto alla versione
B, infatti testando le interfacce Web delle rispettive versioni si è evinto che sia
nell’inserimento di dati, sia nella loro eliminazione, sia nella loro modifica, la versione
A risulta eseguire tali operazioni in un arco di tempo leggermente ma comunque
inferiore rispetto alla seconda versione, indubbiamente perché la versione B in tutte
queste operazioni effettua più passaggi.
o Sviluppo successivo e manutenzione:
CAPITOLO 8 - VALUTAZIONI
83
Questa valutazione deriva da alcuni punti precedenti, innanzitutto dal numero di
righe di codice scritto, che nella versione B è di gran lunga maggiore, che dalla
complessità delle query e della loro gestione, che come abbiamo visto nella versione
B risultano più laboriose e questo comporta di conseguenza maggiore difficoltà sia in
fase di uno sviluppo successivo che di manutenzione.
In definitiva, avendo analizzato i pro e i contro delle due versioni, possiamo dire che sebbene
sia stato raggiunto l’obiettivo, ovvero la realizzazione di un componente CMS per la gestione
di un menu per ristoranti che si interfacci a Index e che tratti i dati in modo semantico, la
seconda versione del progetto realizzato presenta dei punti che sarebbe necessario
migliorare ulteriormente in modo da renderlo ottimale rispetto al suo scopo finale.
Per questo, a fronte di questa ricerca, è auspicabile individuare delle migliorie a tale versione
o valutare ulteriori soluzioni per poter utilizzare Index affinché tratti i dati secondo la logica
della semantica.
84
CONCLUSIONI
CONCLUSIONI
85
Il progetto realizzato, in conclusione, ha portato a comprendere maggiormente le
potenzialità di Index e di come questo possa avvicinarsi alle logiche della semantica.
È stata dunque realizzata una componente prototipale CMS per gestire dati relativi ai menu
per ristoranti, dati che a livello back-end sono stati strutturati con le logiche della semantica.
Ed a livello amministrativo per il back-end sono state realizzate due versioni, una prima
basata su un’applicazione Web che si interfaccia a DoQui e nella fattispecie ad Index ovvero
il motore di gestione dei contenuti digitali di DoQui, ed un’altra che si interfaccia ad un
EndPoit SPARQL, atto ad interrogazioni specifiche per il recupero dei dati espressi in RDF.
La realizzazione di due versioni del progetto a livello beck-end ha permesso di giungere a
delle valutazioni finali circa le ulteriori possibilità di approfondimento e di ricerca in questo
ambito oltre che del progetto specifico. Si è trattato di uno studio che ha inteso indicare
delle prospettive di ricerca più generali che possano costituire oltre che un punto di arrivo,
anche una buona base di partenza per futuri studi nell’ambito della semantica applicata a
Index.
Il progetto di questa tesi è stato molto interessante perché mi ha portato alla conoscenza di
un argomento importante ed affascinante quale è il Semantic Web, un Web non più
costituito da documenti, fatto dalle persone per le persone, ma da dati cui possono accedere
anche le macchine creando automaticamente collegamenti semantici. Inoltre le competenze
acquisite in questo periodo sono state tante grazie alla supervisione ed alla guida del
relatore, il Prof. Corno, ai suggerimenti operativi dei colleghi di TRIM oltre che grazie ai
diversi approfondimenti personali attraverso approfondite letture sulla sintassi e sulla
filosofia delle logiche della semantica che mi hanno portato ad una maggiore comprensione
di quanto queste siano indispensabili per l’evoluzione stessa del Web.
Conducendo un percorso duale, perché costituito sia da approfondimenti di natura teorica
che da tentativi pratici di natura operativa, ho potuto comprendere a fondo quanto oggi più
che mai, grazie a questi nuovi spunti di ricerca semantica, il Web si presenti ad un “addetto
ai lavori” come un laboratorio aperto che offra la possibilità, e allo stesso tempo mostri la
necessità, di continuare a condurre esperimenti, approfondimenti, in una sola parola ricerca,
in vista di continue innovazioni tecnologiche, non fini a sé stesse ma rilevanti sia socialmente
che in termini di business.
Vorrei concludere indicando quali saranno, a mio parere, le principali sfide future del
Semantic Web e che concernono la risoluzione di due principali questioni, vale a dire quello
relativo alla identità e quello che concerne il ragionamento automatico in ambito Web:
o Il problema dell’identità:
Il Semantic Web, essendo un affinamento del Web stesso, utilizza le URI per
identificare le risorse. Le URI, in accordo con i principi su cui si fonda il Web, sono
assegnate con un metodo che bilancia il principio di decentralizzazione e quello di
semplicità ma che non garantisce l’univocità: “come riconoscere che due URI
identificano la stessa risorsa?”.
CONCLUSIONI
86
La decentralizzazione è un problema da un punto di vista logico, ma ha enormi
vantaggi dal punto di vista della creazione di contenuti. Le persone, infatti, non
hanno problemi a gestire più di un identificativo per la stessa risorsa e non c’è
bisogno di imporre un identificativo univoco. Per le macchine, però il discorso è
diverso, ed avere a che fare con più identificativi sarebbe un problema di difficile
gestione. Ovviamente, a rendere ancora più complessa la questione, ci sono per
esempio gli errori di battitura. L’aspirazione del Semantic Web è quella di costruire
un Web di dati rendendo collegabili semanticamente i silos di informazioni delle
varie organizzazioni, tuttavia non è pensabile che, per rendere disponibile
l’informazione contenuta in questi, sia richiesta un’operazione manuale di verifica
dell’univocità degli identificativi. E’ assolutamente indispensabile fare in modo che
questi dati siano trattati in modo automatico attraverso processi logico-intuitivi.
Il problema sarà difficile da affrontare nella sua interezza e l’elaborazione delle
possibili risoluzioni molto lunga, perché il Web copre una vasta gamma di
informazioni resa disponibile per ragioni differenti e il cui significato cambia nel
tempo. Quindi, un’importante sfida per il Semantic Web è quella di mettere a punto
metodi e tecniche per affrontare il problema dell’identità e realizzare sistemi in
grado di gestirlo, se non per l’intero Web, almeno per una parte di esso.
o Il problema del ragionamento automatico in presenza di inconsistenze:
I tipi di ragionamento derivati dall’ingegneria della conoscenza sono numerosi, ma
pochi sono stati automatizzati, come ad esempio il calcolo della deduzione naturale
ed i vari tipi di inferenza statistica. Il Semantic Web, però, può abilitare altri tipi di
ragionamento, come il ragionamento associativo (sono messi a confronto i punti di
vista di attori differenti) e quello per analogia (se A è analogo a B ed A ha la
proprietà P, allora anche B avrà la proprietà P), ed ha quindi bisogno di nuove
tecniche in grado di abilitare il ragionamento automatico in presenza di
inconsistenza e di funzionare sull’intera scala del Web. Uno dei principali problemi
aperti nel Semantic Web è il ragionamento in presenza di inconsistenze. Il Web è un
medium democratico in cui ciascuno può esprimere il proprio punto di vista e, dal
momento che molti di questi punti di vista sono il risultato di culture differenti,
dobbiamo aspettarci molte inconsistenze e possibili contrapposizioni oltre che
studiare delle modalità di gestione delle stesse.
Dal momento che non è possibile vietare l’introduzione di enunciati contraddittori,
l’ingegneria della conoscenza volge alcuni dei suoi studi nell’individuare metodi per
ragionare in presenza di inconsistenze in modo tale da permettere di limitare gli
effetti degli enunciati contraddittori.
87
GLOSSARIO
GLOSSARIO
88
AJAX (Asynchronous JavaScript and XML), è una tecnica di sviluppo per la
realizzazione di applicazioni web interattive (Rich Internet Application). Lo sviluppo di
applicazioni HTML con AJAX si basa su uno scambio di dati in background fra web
browser e server, che consente l'aggiornamento dinamico di una pagina web senza
esplicito ricaricamento da parte dell'utente. AJAX è asincrono nel senso che i dati
extra sono richiesti al server e caricati in background senza interferire con il
comportamento della pagina esistente. Normalmente le funzioni richiamate sono
scritte con il linguaggio JavaScript. Tuttavia, e a dispetto del nome, l'uso di JavaScript
e di XML non è obbligatorio, come non è necessario che le richieste di caricamento
debbano essere necessariamente asincrone.
AOO (Area Organizzativa Omogenea), è una struttura amministrativa individuata da
settori che, per tipologia di mandato istituzionale, di funzione amministrativa
perseguita, di obiettivi e di attività svolta, presentano esigenze di gestione della
documentazione in modo unitario e coordinato.
CERN (European Organization for Nuclear Research), è il più grande laboratorio al
mondo di fisica delle particelle. Si trova al confine tra Svizzera e Francia alla periferia
ovest della città di Ginevra
CSI-Piemonte, è un consorzio di Enti pubblici che promuove l'innovazione nella
Pubblica Amministrazione attraverso le tecnologie ICT. Con più di 1.200 dipendenti,
sei sedi sul territorio e 82 Enti consorziati, oggi il CSI è una delle principali aziende ICT
in Italia. Con la propria attività permette alle Amministrazioni di offrire servizi più
efficienti a cittadini e imprese, promuove occasioni di collaborazione a livello
regionale, interregionale e internazionale, favorisce il riuso e la condivisione di best
practices.
CMS (Content Management System ), letteralmente sistema di gestione dei
contenuti, è uno strumento software installato su un server web studiato per
facilitare la gestione dei contenuti di siti web, svincolando l'amministratore da
conoscenze tecniche di programmazione.
Digital signature, “firma digitale” in italiano, è basata sulla tecnologia della
crittografia a chiave pubblica o PKI. Dal punto di vista informatico rappresenta un
sistema di autenticazione di documenti digitali tale da garantire non ripudio. La
nozione di firma digitale ha in Italia anche un'accezione giuridica, in quanto individua
quel tipo di firma che può essere apposta ai documenti informatici alla stessa stregua
di come la firma autografa viene apposta ai documenti tradizionali.
DTD (Document Type Definition - definizione del tipo di documento), ha lo scopo di
definire le componenti ammesse nella costruzione di un documento XML. Il termine
non è utilizzato soltanto per i documenti XML ma anche per tutti i documenti derivati
GLOSSARIO
89
dall'SGML (di cui peraltro XML vuole essere una semplificazione che ne mantiene la
potenza riducendone la complessità) tra cui famosissimo è l'HTML.
Dublin Core Initiative, è un sistema di metadati costituito da un nucleo di elementi
essenziali ai fini della descrizione di qualsiasi materiale digitale accessibile via rete
informatica, inizialmente composto da solo quindici elementi, successivamente si è
esteso (esempio di qualche elemento: Title, Creator, Subject, Description, Publisher,
Contributor, Date, Type, Format).
ECM (Enterprise Content Management), è l'insieme di strumenti che consentono la
gestione della documentazione prodotta e ricevuta all’interno di un’organizzazione,
indipendentemente dal suo formato.
HTML (HyperText Markup Language), è un linguaggio usato per descrivere la
struttura dei documenti ipertestuali disponibili nel World Wide Web ossia su
Internet. Tutti i siti web sono scritti in HTML, codice che viene letto ed elaborato dal
browser, il quale genera la pagina che viene visualizzata sullo schermo del computer.
HTTP (Hypertext Transfer Protocol), è il protocollo di trasferimento di un ipertesto.
Usato come principale sistema per la trasmissione di informazioni sul web. L'HTTP
funziona su un meccanismo richiesta/risposta (client/server): il client esegue una
richiesta ed il server restituisce la risposta. Nell'uso comune il client corrisponde al
browser ed il server al sito web. Vi sono quindi due tipi di messaggi HTTP: messaggi
richiesta e messaggi risposta.
JavaScript, è un linguaggio di scripting orientato agli oggetti comunemente usato nei
siti web. Fu originariamente sviluppato da Brendan Eich della Netscape
Communications con il nome di Mocha e successivamente di LiveScript, ma in seguito
è stato rinominato "JavaScript" ed è stato formalizzato con una sintassi più vicina a
quella del linguaggio Java di Sun Microsystems. JavaScript è stato standardizzato per
la prima volta tra il 1997 e il 1999 dalla ECMA con il nome ECMAScript.
JSP (JavaServer Pages), è una tecnologia Java per lo sviluppo di applicazioni Web che
forniscono contenuti dinamici in formato HTML o XML. Si basa su un insieme di
speciali tag con cui possono essere invocate funzioni predefinite o codice Java (JSTL).
In aggiunta, permette di creare librerie di nuovi tag che estendono l'insieme dei tag
standard (JSP Custom Tag Library). Le librerie di tag JSP si possono considerare
estensioni indipendenti dalla piattaforma delle funzionalità di un Web server.
jQuery (JavaScript Query), è un framework JavaScript, realizzato per supportare nel
miglior modo possibile lo sviluppatore web garantendogli, non solo un più rapido
sviluppo delle applicazioni ma anche, e soprattutto, la sicurezza di avere
un'architettura compatibile con tutti i principali browser moderni.
GLOSSARIO
90
Mash-up, applicazioni che usano contenuti di più sorgenti per crearne uno
completamente nuovo.
PHP (acronimo ricorsivo di "PHP: Hypertext Preprocessor", preprocessore di
ipertesti), è un linguaggio di scripting interpretato, con licenza open source e
parzialmente libera, originariamente concepito per la realizzazione di pagine web
dinamiche. Attualmente è utilizzato principalmente per sviluppare applicazioni web
lato server ma può essere usato anche per scrivere script a linea di comando o
applicazioni stand-alone con interfaccia grafica.
RDF (Resource Description Framework), è lo strumento base proposto da W3C per la
codifica, lo scambio e il riutilizzo di metadati strutturati con la logica della semantica
e consente l'interoperabilità tra applicazioni che si scambiano informazioni sul Web.
SGML (Standard Generalized Markup Language), è uno standard per la descrizione
logica dei documenti.
SOA (Service-Oriented Architecture), indica generalmente un'architettura software
adatta a supportare l'uso di servizi Web per garantire l'interoperabilità tra diversi
sistemi così da consentire l'utilizzo delle singole applicazioni come componenti del
processo di business e soddisfare le richieste degli utenti in modo integrato e
trasparente.
SOAP (Simple Object Access Protocol), è un protocollo leggero per lo scambio di
messaggi tra componenti software, tipicamente nella forma di componentistica
software. La parola object manifesta che l'uso del protocollo dovrebbe effettuarsi
secondo il paradigma della programmazione orientata agli oggetti. Si basa sul
metalinguaggio XML e la sua struttura segue la configurazione Head-Body,
analogamente ad HTML.
SPARQL (Simple Protocol And RDF Query Language), è il linguaggio di interrogazione
specifico per il recupero dei dati espressi in RDF dal Web, ed è asceso dal 15 gennaio
2008 al rango di W3C Candidate Recommendation.
SQL (Structured Query Language), è un Linguaggio di programmazione per database
progettato per leggere, modificare e gestire dati memorizzati in un sistema basato sul
modello relazionale, per creare e modificare schemi di database, per creare e gestire
strumenti di controllo ed accesso ai dati.
TRIM s.r.l. nasce nel 1999 ed è una delle prime aziende dell'Incubatore di Imprese
Innovative del Politecnico di Torino. Solida e dinamica, è formata da un team di 15
ingegneri che, lavorando con una propria metodologia, progettano e realizzano
GLOSSARIO
91
applicazioni web e soluzioni di gestione documentale in maniera rapida ed efficace
utilizzando tecnologie Java.
UDDI (Universal Description Discovery and Integration), è un registry (ovvero una
base dati ordinata ed indicizzata), basato su XML ed indipendente dalla piattaforma
hardware, che permette alle aziende la pubblicazione dei propri dati e dei servizi
offerti su internet.
URI (Uniform Resource Identifier), è il generico insieme di tutti i nomi/indirizzi che
costituiscono le brevi sequenze di caratteri che fanno riferimento ad una risorsa,
acronimo più generico rispetto ad URL.
URL (Uniform Resource Locator), è una sequenza di caratteri che identifica
univocamente l'indirizzo di una risorsa in Internet, come un documento o
un'immagine. E’ un termine informale, non più utilizzato nelle specifiche tecniche,
associato con gli schemi URI più noti e diffusi (http, ftp, mailto, etc.).
Web of Trust, “Web di fiducia” in italiano, è un concetto espresso da programmi che
permettono di usare autenticazione e privacy crittografica, per stabilire l’autenticità
dell’associazione chiave-utente.
Web Service (servizio web), è un sistema software progettato per supportare
l'interoperabilità tra diversi elaboratori su di una medesima rete.
Wiki, è un sito Web (o comunque una collezione di documenti ipertestuali) che viene
aggiornato dai suoi utilizzatori e i cui contenuti sono sviluppati in collaborazione da
tutti coloro che vi hanno accesso. La modifica dei contenuti è aperta, nel senso che il
testo può essere modificato da tutti gli utenti (a volte soltanto se registrati, altre
volte anche anonimi) procedendo non solo per aggiunte, ma anche cambiando e
cancellando ciò che hanno scritto gli autori precedenti. Ogni modifica è registrata in
una cronologia che permette in caso di necessità di riportare il testo alla versione
precedente; lo scopo è quello di condividere, scambiare, immagazzinare e ottimizzare
la conoscenza in modo collaborativo. Il termine wiki indica anche il software
collaborativo utilizzato per creare il sito web e il server.
WSDL (Web Services Description Language), è un linguaggio formale in formato XML
utilizzato per la creazione di “documenti” per la descrizione di Web Service.
Mediante WSDL può essere, infatti, descritta l'interfaccia pubblica di un Web Service
ovvero creata una descrizione, basata su XML, di come interagire con un determinato
servizio: un “documento” WSDL contiene infatti, relativamente al Web Service
descritto, informazioni su cosa può essere utilizzato (le “operazioni” messe a
disposizione dal servizio), come utilizzarlo (il protocollo di comunicazione da utilizzare
per accedere al servizio, il formato dei messaggi accettati in input e restituiti in
GLOSSARIO
92
output dal servizio ed i dati correlati) ovvero i “vincoli” (bindings in inglese) del
servizio e dove utilizzare il servizio (cosiddetto endpoint del servizio che solitamente
corrisponde all'indirizzo - in formato URI - che rende disponibile il Web Service).
W3C (World Wide Web Consortium), è un consorzio che sviluppa tecnologie
(specifiche, linee guida, software, e strumenti) per portare il Web al massimo del suo
potenziale, definendo protocolli comuni che ne favoriscano l’evoluzione e assicurino
l’ interoperabilità.
XML (eXtensible Markup Language), è un meta-linguaggio di markup, cioè un
linguaggio che permette di definire altri linguaggi di markup. A differenza di HTML,
XML non ha tag predefiniti e non serve per definire pagine Web né per programmare.
Esso serve esclusivamente per definire altri linguaggi. Rispetto all'HTML, l'XML ha uno
scopo ben diverso: mentre il primo definisce una grammatica per la descrizione e la
formattazione di pagine web e, più in generale, di ipertesti, il secondo è un
metalinguaggio utilizzato per creare nuovi linguaggi, atti a descrivere documenti
strutturati. Mentre l'HTML ha un insieme ben definito e ristretto di tag, con l'XML è
invece possibile definirne di propri a seconda delle esigenze.
XPath, è un linguaggio parte della famiglia XML che permette di individuare i nodi
all'interno di un documento XML. Le espressioni XPath, a differenza delle espressioni
XML, non servono a identificare la struttura di un documento, bensì a localizzarne
con precisione i nodi.
XSD (XML Schema Definition), è un esempio concreto di schema XML scritto in
linguaggio XML Schema. Una XSD definisce il tipo di un documento XML in termini di
vincoli: quali elementi ed attributi possono apparire, in quale relazione reciproca,
quale tipo di dati può contenere, ed altro. Può essere usata anche con un programma
di validazione, al fine di accertare a quale tipo appartiene un determinato documento
XML.
93
BIBLIOGRAFIA
Rudi Studer, Richard Benjamins e Dieter Fensel (marzo 1998), Data & Knowledge
Engineering, Amsterdam, Elsevier Science Publishers B. V., Volume 25, pagine 161 – 197.
David Sklar (2005), PHP 5 Elementi di programmazione, Milano, McGraw-Hill.
Della Valle Emanuele, Celino Irene, Cerizza Dario (giugno 2009), Semantic Web - Dai
fondamenti alla realizzazione di un'applicazione, 1a edizione, Italia, Pearson Education
Italia.
Tim Berners-Lee, James Hendler, Ora Lassila (maggio 2001), The Semantic Web, Scientific
American Magazine, Scientific American Inc.
Jeffrey T. Pollock (2009), The Semantic Web for Dummies, Indianapolis (Indiana), Wiley.
Michael C. Daconta, Leo J. Obrst, Kevin T. Smith (2003), The Semantic Web: A Guide to the
Future of XML, Web Services and Knowledge Management, Indianapolis (Indiana), Wiley.
94
SITOGRAFIA
Sito di DoQui:
http://www.doqui.it/
Wiki di DoQui:
http://www.doqui.it/wiki/doku.php
Laboratorio di Accessibilità e Usabilità - Interrogare l'RDF con SPARQL:
http://lau.csi.it/realizzare/accessibilita/linguaggi_programmazione/SPARQL/rdf.shtml
Documentazione ARC2 - Framework PHP per RDF e SPARQL:
http://arc.semsol.org/
“Web2.0 Innovazione applicata ai servizi di Rete” di Federico Moro (Novembre 2006):
http://www.openarea.net/Web2.0.pdf
“Web 2.0 Compact Definition: Trying Again” di O’Really Radar:
http://radar.oreilly.com/archives/2006/12/web-20-compact-definition-tryi.html
“The Web Semantic” di Tim Berners-Lee:
http://www.scientificamerican.com/article.cfm?id=the-semantic-web/
Materiale del corso universitario “Semantic Web: Technologies, Tools, Applications” del
prfessore Fulvio Corno e della professoressa Laura Farinetti:
http://elite.polito.it/teaching-mainmenu-69/master-a-phd-mainmenu-94/56-01lhviu-
semweb
Raccomandazioni del W3C sul RDF Primer di Frank Manola ed Eric Miller:
http://www.w3.org/TR/rdf-primer/
Raccomandazioni del W3C sul RDF Schema di Dan Brickley e R.V. Guha:
http://www.w3.org/TR/rdf-schema/
Raccomandazioni del W3C sulle query SPARQL di Eric Prud'hommeaux, Andy Seaborne,
Hewlett-Packard Laboratories e Bristol:
http://www.w3.org/TR/rdf-sparql-query/
Tutorial sull’RDF realizzato dal W3schools:
http://www.w3schools.com/RDF/default.asp
Validatore RDF del W3:
http://www.w3.org/RDF/Validator/
Validatore RDF realizzato da Joshua Tauberer:
http://www.rdfabout.com/demo/validator/
95
Il Web Semantico in Italiano:
http://esw.w3.org/topic/SemWebItaly/
“Architecture of the World Wide Web” di Ian Jacobs e Norman Walsh:
http://www.w3.org/TR/webarch/
“Best Practice Recipes for Publishing RDF Vocabularies” di Diego Berrueta e Jon Phipps:
http://www.w3.org/TR/swbp-vocab-pub/
Progetto Semantic Web Services DIP – Data, Information and Process Integration:
http://www.service-finder.eu/