Sei sulla pagina 1di 115

1

Copyright © 2010 Michele Filannino <filannino.m@gmail.com>.


Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation; with
no Invariant Sections, no Front-Cover Texts, and no Back-Cover Tex-
ts. A copy of the license is included in the section entitled "GNU Free
Documentation License".

You should have received a copy of the GNU General Public License along
with this document; if not, write to the Free Software Foundation, Inc.,
675 Mass Ave, Cambridge, MA 02139, USA.
2

“Raccontiamo a noi stessi delle storie per riuscire a vivere. Interpretiamo quello che

vediamo, scegliamo la più fattibile delle molte opzioni. Viviamo solamente grazie

all’imposizione di una linea narrativa su immagini altrimenti separate, grazie all’idea con

cui impariamo a congelare la fantasmagoria in movimento che è la nostra esperienza

effettiva”

Joan Didion in “The white album”


3

Sto scrivendo questa “pagina dei ringraziamenti” solo oggi, 30 settembre 2010. Appena 8
giorni prima della seduta di laurea. Un lavoro lasciato alla fine non perché difficile
ma perché volevo contenesse i miei sentimenti più veri. Non sarebbe stato giusto
scriverli in un box umido e polveroso dove invece ho scritto tutto il resto del docu-
mento. “Per essere autentici bisogna togliere” dice Mauro Corona. Scrivanie, penne,
computer, fogli, luce, cibo. Via tutto. Solo se stessi, le proprie idee e i propri sogni.

Mentre mio padre da tre giorni si ostina a pensare che la decisione di comprare una
nuova inutile televisione LCD sia sua, mentre mia madre parla di conti, bollette ed
altre amenità, mentre Donato si affanna a far finta di assecondare mio padre, mentre
Claudio divora manga al PC aspettando che il suo primo anno da matricola di Fisica
cominci e mentre il piccolo Cristian si pavoneggia con il netbook che gli ho regalato...
tra grida, urla, silenzi, luci, ombre e banalità io penso che sia giusto scriverTi.

So che leggerai questa pagina e so anche che sarà una pagina di carta e non di un PDF.
Sarà proprio l’unica copia di questo documento che prenderai. So che quando nessuno
potrà guardarti, quando non desterai sospetti aprirai questa tesi e cercherai questa
pagina. Non lo farai per avere uno spunto, non per interesse, lo farai perché ti
chiederai se sono diverso da come mi hai sempre visto, se è normale vivere assorti
nel proprio mondo e scoprirai di essere mio emulo. Ma lo scoprirai soltanto tra
qualche tempo. Avrei potuto dirtele di persona queste cose, ma non avresti capito.

Le strade si imboccano e si abbandonano ma l’emozione del viaggio è quella che ti rimane


dentro per sempre. Che tu possa sempre viaggiare senza mai preoccuparti delle strade
imboccate e abbandonate. Nessuna pressione, nessuna costrizione: fai sempre quello
che senti di dover fare per raggiungere i tuoi sogni.

Il mio viaggio è stato reso fantastico da gente meravigliosa che ho incontrato quasi per
caso ed è per questo che non possono esimermi dal ringraziarli. Senza il loro supporto
questo viaggio sarebbe stato uno schifo.

La mia famiglia, Marilena la mia incredibile ragazza, Asia (con Fatima, Benito ed il
simpaticissimo Ettore) ed ovviamente tutti i miei amici della ridente Andria. Per
questi ultimi, in particolare, non basterebbe un giorno intero per descriverne le virtù.
Siete delle persone speciali e sono onorato oltre che felice di potermi dire vostro
amico. Con la mia ragazza non basterebbe una vita, ma vale la pena provare a
spenderla tutta nell’impresa.

Vi adoro tutti.

PS. Se sei il/la ragazzo/a delle fotocopie e ti stai facendo i fatti miei, grazie anche a te
per aver stampato questo documento in tempi record.

PPS. Se mi stai leggendo perché mi sono appena laureato o solo perché la tesi è nuova e
non si abbina bene con i mobili del salotto... ora non sei tu il destinatario del mio
messaggio, ma occhio! che potresti esserlo più avanti.
Indice

1 Introduzione 9
1.1 Scopo della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Service Oriented Architecture 13


2.1 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1 Tecnologie standard . . . . . . . . . . . . . . . . . . . . 18
2.1.1.1 eXtensible Markup Language (XML) . . . . . 18
2.1.1.2 Service Oriented Application Protocol (SOAP) 19
2.1.1.3 Web Service Description Language (WSDL) . 19
2.1.1.4 Universal Description Discovery and Integra-
tion (UDDI) . . . . . . . . . . . . . . . . . . 20
2.1.1.5 Vantaggi nell’uso dei Web Service . . . . . . . 21
2.1.1.6 REST . . . . . . . . . . . . . . . . . . . . . . 22
2.1.2 Limiti dei Web Service . . . . . . . . . . . . . . . . . . 23
2.2 Dai Web Service ai Semantic Web Service . . . . . . . . . . . 24
2.2.1 Semantica nel web . . . . . . . . . . . . . . . . . . . . 24
2.2.2 Web Ontology Language (OWL) . . . . . . . . . . . . 26

3 Semantic Web Service 30


3.1 Tipi di semantica . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1 Semantica funzionale . . . . . . . . . . . . . . . . . . . 31
3.1.2 Semantica dei dati . . . . . . . . . . . . . . . . . . . . 32
3.1.3 Semantica della qualità . . . . . . . . . . . . . . . . . . 32
3.1.4 Semantica di esecuzione . . . . . . . . . . . . . . . . . 33

4
INDICE 5

3.2 Infrastruttura dei Semantic Web Service . . . . . . . . . . . . 33


3.3 Annotazione semantica . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1 Tool per l’annotazione semantica . . . . . . . . . . . . 39
3.3.1.1 Tool semi-automatici . . . . . . . . . . . . . . 39
3.3.1.2 Tool manuali . . . . . . . . . . . . . . . . . . 41
3.3.2 Elaborazione del linguaggio naturale . . . . . . . . . . 45
3.4 Annotazione di SWS . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.1 Web Ontology Language for Services (OWL-S) . . . . . 48
3.4.2 Web Service Modeling Ontology (WSMO) . . . . . . . 51
3.4.3 Web Service Semantic (WSDL-S) . . . . . . . . . . . . 54
3.4.4 Semantic Annotation for WSDL and XML Schema (SA-
WSDL) . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.5 Annotazione di REST service . . . . . . . . . . . . . . . . . . 61
3.5.1 SA-REST . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.5.2 Tecniche di annotazione e linguaggi . . . . . . . . . . . 62
3.5.2.1 RDFa . . . . . . . . . . . . . . . . . . . . . . 62
3.5.2.2 GRDDL . . . . . . . . . . . . . . . . . . . . . 63
3.5.3 Stato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4 SWOP Project 66
4.1 Architettura generale . . . . . . . . . . . . . . . . . . . . . . . 70
4.2 Annotazione semantica di Web Service . . . . . . . . . . . . . 72
4.2.1 Interfaccia utente . . . . . . . . . . . . . . . . . . . . . 73
4.2.2 Ontologia di dominio . . . . . . . . . . . . . . . . . . . 77

5 L’algoritmo SAWA 79
5.1 Similarità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.1.1 Similarity vs. Relatedness . . . . . . . . . . . . . . . . 80
5.1.2 Similarità semantica . . . . . . . . . . . . . . . . . . . 80
5.1.2.1 Similarità tra parole . . . . . . . . . . . . . . 82
5.1.2.2 Dalla similarità tra parole alla similarità tra
testi . . . . . . . . . . . . . . . . . . . . . . . 84
5.2 SAWA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
INDICE 6

5.2.1 DISCO . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2.2 Corpus . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2.3 Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.4.1 Ottimizzazione . . . . . . . . . . . . . . . . . 91
5.2.5 Performance . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.5.1 Valutazione della misura di similarità . . . . . 94
5.2.5.2 Sperimentazione nella piattaforma . . . . . . 95
5.2.6 Architettura di rete . . . . . . . . . . . . . . . . . . . . 101
5.2.6.1 Interfaccia di rete . . . . . . . . . . . . . . . . 102
5.2.6.2 Interfaccia sul web . . . . . . . . . . . . . . . 103
5.2.6.3 Interfaccia come servizio web . . . . . . . . . 106

6 Conclusioni 107
6.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Elenco delle figure

2.0.1 Architettura SOA . . . . . . . . . . . . . . . . . . . . . . . . . 15


2.0.2 Architettura SOA nel Web . . . . . . . . . . . . . . . . . . . . 16
2.1.1 Web Service e loro standard . . . . . . . . . . . . . . . . . . . 18
2.1.2 Relazione tra XML, SOAP, WSDL ed UDDI . . . . . . . . . 19
2.1.3 SOAP skeleton listing . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Esempio di dichiarazione in OWL . . . . . . . . . . . . . . . . 27
2.2.2 Dichiarazione degli elementi di base in OWL . . . . . . . . . . 29

3.0.1 Semantic Web Services nel Semantic Web . . . . . . . . . . . . 30


3.2.1 Le dimensioni delle infrastrutture per Semantic Web Services . 34
3.3.1 Screenshot del tool MWSAF . . . . . . . . . . . . . . . . . . . 40
3.3.2 Screenshot di IBM Annotation Editor da pagina HTML . . . . 41
3.3.3 Screenshot di IBM Annotation Editor . . . . . . . . . . . . . . 42
3.3.4 Screenshot di Radiant . . . . . . . . . . . . . . . . . . . . . . 42
3.3.5 Screenshot di WSMO Studio . . . . . . . . . . . . . . . . . . 44
3.3.6 Screenshot di Jena con “SCA Tool Feature - SAWSDL Sup-
port” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.7 Schematizzazione del processo di indicizzazione semantica dei
documenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.1 Livello più generale dell’ontologia OWL-S . . . . . . . . . . . . 49
3.4.2 Struttura di WSMO . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.3 Metafora dei puntatori di SAWSDL ai concetti ontologici . . . 58
3.4.4 Schema di SAWSDL . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.5 Pila estesa dei Web Service . . . . . . . . . . . . . . . . . . . . 60

7
ELENCO DELLE FIGURE 8

3.5.1 Comparazione del numero di pubblicazioni scientifiche per SA-


WSDL e SA-REST . . . . . . . . . . . . . . . . . . . . . . . . 64
3.5.2 Comparazione delle caratteristiche salienti di SAWSDL e SA-
REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.1.1 Architettura del progetto SWOP . . . . . . . . . . . . . . . . 70


4.2.1 Flusso di lavoro del modulo di annotazione . . . . . . . . . . . 72
4.2.2 Lista ordinata di classi ontologiche semanticamente simili . . . 74
4.2.3 Mockup GUI di CODEArchitects Annotation Tool . . . . . . . 75
4.2.4 Mockup GUI di elaborazione CODEArchitects Annotation Tool 76
4.2.5 Mockup GUI risultati di CODEArchitects Annotation Tool . 76

5.0.1 Logo di SAWA . . . . . . . . . . . . . . . . . . . . . . . . . . 79


5.2.1 Tempo di esecuzione si SAWA in versione ottimizzata e non
ottimizzata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.2.2 Risultati di SAWA 1 . . . . . . . . . . . . . . . . . . . . . . . 98
5.2.3 Risultati di SAWA 2 . . . . . . . . . . . . . . . . . . . . . . . 99
5.2.4 Risultati di SAWA 3 . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.5 Risultati della Figura 5.2.3 riportati su grafico . . . . . . . . . 100
5.2.6 Risultati della Figura 5.2.4 riportati su grafico . . . . . . . . . 101
5.2.7 Architettura di rete di SAWA . . . . . . . . . . . . . . . . . . 102
5.2.8 Shell del server di SAWA . . . . . . . . . . . . . . . . . . . . . 103
5.2.9 Client SAWA per Mac OS X - Interfaccia di richiesta . . . . . 103
5.2.10Client SAWA per Mac OS X - Interfaccia di risposta . . . . . 104
5.2.11Client SAWA per Mac OS X - Impostazione dei parametri di
rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.2.12Pagina web di SAWA su dispositivo mobile . . . . . . . . . . . 105
Capitolo 1

Introduzione

Questa tesi è il prodotto finale di un lavoro di ricerca durato più di un anno


nell’ambito del progetto regionale (Asse I, linea di intervento 1.1, 2007-2013)
che ha coinvolto il SWAP Research Group1 del Dipartimento di Informatica
di Bari2 e la società CODEArchitects srl3 in qualità di partner aziendale.
La ricerca di web service basata sul contenuto informativo prodotto da
esperti umani costituisce oggigiorno un fattore chiave per ogni piattaforma
per la gestione di servizi web. La semplicità con la quale è possibile realizzare
e pubblicare servizi web ha fatto si che questo strumento si diffondesse fino a
divenire un caposaldo dell’intera artchitettura di sviluppo SOA. Un passo in
avanti nel suo sviluppo è costituito dalla progettazione ed implementazione
di nuovi metodi che consentano di annotare testo semplice in maniera semi-
automatica utilizzando concetti ontologici.
Motivati da questa esigenza, il progetto SWOP (Semantic Web Oriented
Platform) introduce il concetto di annotazione semantica semi-automatica
volta a migliorare l’accuratezza dei servizi di ricerca nei sistemi informativi
aziendali.
In questo lavoro, presenterò in dettaglio una parte del modulo di core
dell’intera architettura di progetto [50], la quale è responsabile dell’annota-
zione semi-automatica di web services. In particolare, presenterò l’algoritmo
1
http://www.di.uniba.it/~swap/
2
http://www.di.uniba.it/
3
http://www.codearchitects.com/

9
CAPITOLO 1. INTRODUZIONE 10

di similarità tra testi espressi in lingua inglese, realizzato per supportare la


fase di annotazione semantica. Tale algoritmo infatti è impiegato per estrarre
dall’ontologia di dominio un sotto-insieme di classi la cui definizione in lingua
inglese è simile a quella fornita dagli utenti per definire le singole operazioni
di un servizio web.
Il seguente documento, pertanto, rappresenta una sintesi di quanto è stato
da me studiato, approfondito e realizzato ed è liberamente disponibile online4 .

1.1 Scopo della tesi


La finalità del progetto regionale SWOP (Semantic Web Oriented Platform)
è quella di realizzare una piattaforma per la ricerca semantica di servizi web.
Realizzare un sistema di ricerca semantica significa predisporre opportuna-
mente le fasi propedeutiche al ritrovamento semantico delle informazioni.
La fase della quale mi sono occupato in prima persona è quella relativa
all’annotazione semantica dei web service. L’azienda partner produce un
framework autonomo di sviluppo impiegato dai propri clienti per costruire
in maniera più veloce, software aziendale di varia natura.
Tale piattaforma mette a disposizione delle aziende clienti una moltitudi-
ne di servizi web che coprono le più disparate esigenze implementative. Con
il crescere sempre più repentino del numero di servizi messi a disposizione è
diventato necessario migliorare gli strumenti di ricerca dei servizi. L’azienda
partner, CODEArchitects, ha deciso di avviare lo sviluppo di un sistema di
ricerca semantica che consentisse di reperire servizi web in maniera più veloce
e precisa, utilizzando descrizioni in linguaggio naturale.
In altri termini, agli sviluppatori delle aziende partner è richiesto di de-
scrivere in linguaggio naturale (in inglese) il servizio web del quale sono alla
ricerca ed attendere che il sistema lo trovi. Il sistema realizzato da SWAP
Research Group provvederà a restituire un insieme di servizi che rispondono
alla descrizione fornita dagli sviluppatori.
Tale progetto è ambizioso per diversi ed importanti motivi:
4
http://www.scribd.com/doc/37331024/Sviluppo-di-un-algoritmo-di-similarita-a-
supporto-dell-annotazione-semantica-di-Web-Services
CAPITOLO 1. INTRODUZIONE 11

• l’azienda partner lavora con un ambiente di sviluppo proprietario, al-


l’interno del quale non vi sono tool o librerie per l’accesso intelligente
all’informazione;

• l’architettura progettuale dell’intero sistema fa si che la soluzione creata


possa essere integrata ed utilizzata efficacemente con qualsiasi altro
ambiente di sviluppo;

• l’architettura progettuale dell’intero sistema riduce al minimo la com-


plessità di installazione;

• il sistema offre risultati con tempi di risposta estremamente bassi;

• l’algoritmo per il calcolo della similarità è di tipo incrementale: migliora


le proprie performance con il passare del tempo;

• il sistema è completamente indipendente dal tipo di lingua utilizzata


come riferimento. Esso può essere abilitato all’utilizzo dell’italiano,
spagnolo, tedesco e francese;

• il sistema è realizzato con architettura SOA.

1.2 Struttura della tesi


Il Capitolo 2 presenta una breve introduzione all’architettura di sviluppo
software orientata ai servizi. Il progetto al quale ho partecipato mira alla
realizzazione di una estensione in chiave semantica dell’architettura prima
citata (SOA).
Il Capitolo 3 approfondisce il tema dei servizi web semantici iniziando
il lettore a tutte le tecnologie oggigiorno disponibili. Il mio lavoro è sta-
to concentrato prevalentemente nel segmento dedicato all’annotazione di un
servizio web per far si che questo potesse arricchirsi di significato processa-
bile dalla macchina. Per questa ragione, nel terzo capitolo verrà dato ampio
spazio al segmento di annotazione. Nella seconda parte del capitolo verrà
illustrato lo stato dell’arte relativamente all’annotazione semantica di servizi
CAPITOLO 1. INTRODUZIONE 12

REST. Verranno illustrati gli standard e le tecnologie relative alla gestione


di piattaforme di Web Service con particolare riferimento ai limiti di tali
approcci in modo da introdurre il valore aggiunto derivante dall’annotazio-
ne semantica. Si procederà, quindi, con l’analizzare il significato di Semantic
Web Service, con particolare riferimento al termine “semantic”: cosa significa
in generale, e più dettagliatamente nell’accezione dei servizi web.
Il Capitolo 4 illustra diffusamente le finalità del progetto SWOP, l’archi-
tettura di sviluppo scelta per il progetto e le componenti che assieme realiz-
zano l’intera infrastruttura. Verrà altresì descritta l’ontologia di dominio e
come essa è suddivisa.
Il Capitolo 5 presenta SAWA, l’algoritmo da me realizzato, capace di
misurare la similarità semantica tra due frasi espresse in linguaggio natu-
rale e suggerire le annotazioni semantiche più appropriate in funzione delle
descrizioni testuali associate agli elementi di un servizio web pre-esistente.
Verranno illustrate le scelte di natura scientifica e quelle di natura tecni-
ca, nonché le modalità pratiche attraverso le quali è stato possibile ridurre
drasticamente il peso computazionale dell’intero algoritmo.
Il Capitolo 6 chiude questo documento con un’analisi critica del lavoro
svolto alla quale segue un’insieme di possibili interventi volti a migliorare
l’algoritmo per il calcolo della similarità semantica.
Capitolo 2

Service Oriented Architecture

Dagli anni ’90, Internet ha beneficiato di una forte crescita accompagnata da


un sempre più vivo interesse da parte delle aziende.
La possibilità di utilizzare la rete globale come veicolo di comunicazione ed
anche di vendita ha spinto le imprese ad integrare i propri sistemi informativi
richiedendo notevoli sforzi organizzativi e tecnologici.
Prima dell’avvento di Internet, la maggior parte delle aziende adottava
sistemi informativi quasi totalmente proprietari, e completamente incapaci
di dialogare con il mondo esterno.
La necessità di scambiarsi informazioni pur mantenendo, allo stesso tem-
po, una certa autonomia, ha dato origine ad una nuova architettura software:
la Service-Oriented Architecture (SOA).
L’obiettivo fondamentale dell’architettura orientata ai servizi è facilitare
l’interoperabilità tra i diversi sistemi, consentendo l’utilizzo delle singole ap-
plicazioni come componenti del processo di business e soddisfando le richieste
degli utenti in modo integrato e trasparente.
L’architettura orientata ai servizi nasce dall’esigenza di rendere interope-
rabili diverse applicazioni costruite con sistemi diversi, in linguaggi diversi,
su macchine diverse.
La definizione di SOA più autorevole è senza ombra di dubbio quel-
la di OASIS (Organizzazione per lo sviluppo di standard sull’informazione
strutturata):

13
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 14

Un paradigma per l’organizzazione e l’utilizzo delle risorse di-


stribuite che possono essere sotto il controllo di domini di pro-
prietà differenti. Fornisce un mezzo uniforme per offrire, scopri-
re, interagire ed usare le capacità di produrre gli effetti voluti
consistentemente con presupposti ed aspettative misurabili.

È importante rilevare che tale architettura, oltre che essere utilizzata per
agevolare la comunicazione tra aziende differenti, venga abbondantemente
impiegata anche per la comunicazione interna. In altri termini, è possibile che
per motivi storici ed organizzativi, differenti divisioni della medesima azienda
abbiano adottato differenti sistemi informativi. Anche in quest’ultimo caso,
l’adozione dell’architettura SOA consente di superare il limite intrinseco.
Nella formalizzazione canonica dell’architettura [19] si individuano tre
attori principali che prendono parte all’intero processo di richiesta e fornitura
del servizio (vedi Figura 2.0.1). Essi sono:

• un service provider : attore che offre il servizio all’esterno, pubbliciz-


zando (publish) l’interfaccia dei propri servizi ad un broker ; ogni pro-
vider decide autonomamente quali servizi offrire, scegliendo il miglior
compromesso tra visibilità e privacy;

• un service requestor : attore che richiede un servizio e lo utilizza (use)


conformemente al protocollo di comunicazione stabilito. Il richiedente
quasi mai conosce l’indirizzo esatto del servizio di cui necessita, per
questa ragione cerca (find) e contatta un intermediario noto (detto
broker );

• service directory (o broker ): questo attore offre supporto a tutti i ri-


chiedenti di servizi e restituisce un elenco di provider coerenti con le
richieste degli attori richiedenti. Il broker può adottare politiche di con-
trollo degli accessi modificando la visibilità di taluni servizi a scapito
di altri.

I tre attori possono essere dislocati sul territorio ed usare tecnologie dif-
ferenti, a patto che tutti utilizzino il medesimo canale trasmissivo. L’archi-
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 15

Figura 2.0.1: Architettura SOA

tettura, essendo estremamente generale, si adatta bene a differenti canali


trasmissivi: quello più importante è sicuramente quello Web.
Nel Web, si utilizzano specifiche tecnologie per l’interazione, la descrizio-
ne, la ricerca ed il reperimento dei servizi. Esse sono rispettivamente:

• SOAP: per l’interazione tra fornitore e fruitore del servizio [53];

• WSDL: per la descrizione formale di ciascun servizio [15];

• UDDI: per la ricerca ed il reperimento dei servizi.

I fattori comuni a tutte queste tecnologie sono:

• l’impiego di XML come linguaggio di rappresentazione dei dati;

• l’uso del protocollo HTTP come veicolo di comunicazione.

Il risultato di quest’ultimo binomio è la totale indipendenza dalla piattaforma


hardware e software sottostante (vedi Figura 2.0.2).
E’ opportuno chiarire che un’architettura SOA che sfrutti il Web come
mezzo trasmissivo, può anche essere sviluppata utilizzando tecnologie dif-
ferenti: RPC, REST, DCOM, CORBA, WCF (Windows Communication
Foundation).
Il principale pregio di questa architettura è la possibilità di offrire servizi
a prescindere dal tipo di linguaggio utilizzato dall’attore richiedente ed ero-
gante. Per inciso, un sistema informativo scritto in Java può offrire servizi
ad uno scritto in C# e viceversa.
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 16

Figura 2.0.2: Architettura SOA nel Web

In questo tipo di architettura ogni attore mette a disposizione un numero


arbitrario di servizi e può utilizzare quelli offerti dagli altri attori. In questo
contesto è possibile, in maniera più facile, realizzare applicazioni anche molto
complesse frutto di un’opportuna orchestrazione di servizi.
Sotto queste ipotesi i servizi prendono il nome di Servizi Web (Web
Service).

2.1 Web Service


Lo strumento fondamentale oggigiorno impiegato per la realizzazione di un’ar-
chitettura SOA è il Web Service (WS). Ogni attore della rete offre servizi
all’esterno ed utilizza servizi di altri attori. Questo meccanismo ha fatto
si che si venissero a creare applicazioni complesse operanti sul web realiz-
zate esclusivamente tramite un’opportuna orchestrazione manuale di questi
servizi.
I Web service sono componenti applicativi modulari, auto-descrittivi ed
indipendenti (auto-contained), accessibili via Internet. Si tratta della più
popolare tecnologia per la realizzazione di un’architettura di tipo SOA.
Un Web service è una componente software invocabile dal Web attraverso
un messaggio XML che osserva gli standard SOAP. La componente mette a
disposizione una o più operazioni da eseguire per conto del richiedente. Le
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 17

operazioni e i formati di input ed output dei messaggi scambiati sono descritti


utilizzando WSDL [15].
Essendo legato a standard aperti del Web, un Web service è indipendente
sia dal suo linguaggio di implementazione che dal tipo di piattaforma. La
descrizione del servizio, espressa in un linguaggio neutrale, è essenziale per
la diffusione di tale tecnologia. Per poter essere utilizzato, in generale, un
servizio deve essere descritto e pubblicizzato. WSDL si preoccupa della fa-
se di descrizione mettendo a disposizione un apposito linguaggio capace di
esprimere dettagli sufficienti a far invocare le operazioni del servizio.
Il fornitore del servizio descrive il suo Servizio Web e lo pubblicizza tra-
mite un registro universale chiamato UDDI. Questa operazione fa si che tutti
i richiedenti possano cercare un servizio opportuno (che presenti le caratteri-
stiche desiderate). UDDI consente la creazione di registri accessibili via Web.
Un registro contiene semplicemente la descrizione del servizio (in linguaggio
WSDL) ed eventualmente informazioni addizionali come quelle circa il for-
nitore. I richiedenti di un particolare servizio (i client) possono interrogare
diversi registri per scoprire ed usare servizi rilevanti.
Per descrivere ulteriormente un Web service, proviamo ad esaminare uno
scenario reale:

“Un’azienda chiamata Moon Company distribuisce un prodotto.


Questa tiene traccia dei propri clienti, prodotti ed ordini attraver-
so un sistema proprietario. L’azienda non vuole fornire, ai propri
clienti, accesso illimitato al sistema, ma vuole solo dare loro la
possibilità di effettuare ordini in modo più facile. Utilizzando
i Web service, Moon Company può creare un’interfaccia con il
proprio sistema che possano utilizzare i clienti, previa autentica-
zione, per effettuare gli ordini. Sotto queste ipotesi, l’azienda ha
bisogno di fornire una definizione WSDL del servizio e i clienti
saranno in grado di realizzare sistemi interni che utilizzano il ser-
vizio di ordini offerto dal fornitore. Poiché Moon Company non
conosce i sistemi informativi utilizzati dai suoi clienti, tecnologie
alternative sarebbero difficili da implementare”.
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 18

Figura 2.1.1: Web Service e loro standard

2.1.1 Tecnologie standard


L’uso di protocolli di comunicazione standard è uno degli aspetti più impor-
tanti dell’architettura SOA; che le conferisce grande flessibilità oltre che la
capacità di sviluppare servizi tecnicamente inter-compatibili.
Attualmente, gli standard dei Web service sono quelli preferiti per svilup-
pare prodotti di tipo SOA. La tecnologia dei Web service ha ottenuto un buon
livello di maturità ed è utilizzata per offrire facilmente funzionalità di busi-
ness all’interno di Intranet ed Internet. Le funzionalità di business possono
consistere in applicazioni comuni come sistemi di ERP, CRM e SCM.
Alcuni degli standard associati ai Web Service sono indispensabili per
sviluppare soluzioni basate su SOA (vedi Figura 2.1.1).
XML, SOAP, WSDL ed UDDI [12] sono le tecnologie fondanti per svilup-
pare un’architettura SOA basata su Web service (vedi Figura 2.1.2). XML
è lo standard per la rappresentazione dei dati; SOAP specifica il livello di
trasporto (mandare messaggi tra fornitore e richiedente); WSDL descrive cia-
scun Web service; UDDI è utilizzato per registrare il servizio e consentirne il
ritrovamento.

2.1.1.1 eXtensible Markup Language (XML)

XML è accettato come standard per lo scambio di dati sul Web poiché con-
sente di strutturarli facilmente. Si tratta di un linguaggio adatto alla rap-
presentazione di dati semi-strutturati ed è stato proposto come soluzione al
problema di integrazione, poiché consente una codifica e visualizzazione fles-
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 19

Figura 2.1.2: Relazione tra XML, SOAP, WSDL ed UDDI

sibile dei dati, grazie all’uso di meta-dati che ne descrivono la forma (DTD
oppure XSD). Un documento XML ben formato crea un albero bilanciato di
insiemi annidati di tag aperti e chiusi, ognuno dei quali può includere diverse
coppie attributo-valore.

2.1.1.2 Service Oriented Application Protocol (SOAP)

Questo standard definisce i tipi ed i formati dei messaggi XML che possono
essere scambiati tra attori in un ambiente decentralizzato e distribuito. Uno
dei principali obiettivi di SOAP è di essere un protocollo di comunicazione
che può essere usato da diverse applicazioni sviluppate utilizzando diversi
linguaggi di programmazione, sistemi operativi e piattaforme. La specifica
correntemente pubblicata dal W3C definisce una struttura del tipo in Figura
2.1.3. L’involucro (Envelope) più esterno definisce lo spazio dei nomi della
specifica SOAP e il tipo di codifica dei caratteri utilizzato per la stesura del
documento. La sezione di intestazione (Header) è opzionale e contiene infor-
mazioni aggiuntive circa il messaggio. La sezione centrale (Body) contiene i
dati che devono essere trasferiti.

2.1.1.3 Web Service Description Language (WSDL)

WSDL (Web Service Description Language) è il linguaggio che fornisce un


modello, espresso in formato XML, che descrive le informazioni sintattiche
circa il Web Service.
Si tratta di uno standard W3C per la specifica dell’interfaccia di Web ser-
vice, anche detta contratto. L’uso di tale linguaggio consente la separazione
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 20

Figura 2.1.3: SOAP skeleton listing

tra la descrizione delle funzionalità astratte offerte dal servizio e la concreta


loro implementazione, definendo in tal modo l’interfaccia che il Web Service
metterà a disposizione del richiedente.
La definizione dell’interfaccia (detta port-type nella versione 1.1 e inter-
face nella versione 2.0) costituisce l’impronta per tutte le operazioni esposte,
includendo il nome dell’operazione, gli input, gli output e i possibili errori.
Oltre all’interfaccia, il documento WSDL consente di specificare, eventual-
mente, informazioni circa il servizio in sé e le sue relazioni con altri servizi.
L’ultima versione dello standard è WSDL 2.0, raccomandata dal W3C (Giu-
gno 2007). WSDL utilizza XML Schema Definition (XSD) che fornisce i
costrutti per la creazione di tipi di dato complessi.
In Appendice 3.1 Documento WSDL di esempio è riportato il codice di
esempio di un file WSDL.

2.1.1.4 Universal Description Discovery and Integration (UDDI)

UDDI (Universal Description, Discovery, and Integration) è attualmente lo


standard di fatto per la registrazione ed il ritrovamento di Web Service.
Quando un servizio viene sviluppato, è necessario pubblicizzarlo al fine
di agevolarne il ritrovamento. Il meccanismo di ritrovamento può essere
ottimizzato in modo tale da essere adeguato alla vastità del Web garantendo
ricerche efficienti e risultati rilevanti tra i centinaia o migliaia di Web Service
disponibili.
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 21

UDDI è stato progettato per essere interrogato da messaggi SOAP e for-


nire il collegamento ai rispettivi documenti WSDL che descrivono i servizi.
Lo standard definisce il contenuto informativo ed il tipo di accesso fornito
dal possessore del servizio. Queste directory forniscono visibilità ai servizi
che possono così essere invocati (utilizzati) dai richiedenti. UDDI può memo-
rizzare le descrizioni dei servizi interni ad un’organizzazione così come quelli
pubblici presenti in Internet.

2.1.1.5 Vantaggi nell’uso dei Web Service

Riepilogando, è possibile tracciare un elenco dei principali punti di forza


derivanti dall’uso dei servizi web. Di seguito:

• permettono l’interoperabilità tra diverse applicazioni software e su di-


verse piattaforme hardware/software;

• utilizzano un formato dei dati di tipo testuale, quindi più comprensi-


bile e più facile da utilizzare per gli sviluppatori (esclusi ovviamente i
trasferimenti di dati di tipo binario);

• essendo basati sul protocollo HTTP, non richiedono modifiche alle re-
gole di sicurezza utilizzate come filtro dai firewall;

• sono semplici da utilizzare e possono essere combinati l’uno con l’altro


(indipendentemente da chi li fornisce e da dove vengono resi disponibili)
per formare servizi "integrati" e complessi;

• permettono di riutilizzare applicazioni già sviluppate;

• fintanto che l’interfaccia rimane costante, le modifiche effettuate ai


servizi rimangono trasparenti;

• sono in grado di pubblicare le loro funzioni e di scambiare dati con il


resto del mondo;

• tutte le informazioni vengono scambiate attraverso protocolli "aperti".


CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 22

2.1.1.6 REST

I servizi basati su un paradigma a trasferimento di stati (REST), imple-


mentazione leggera di SOA, hanno riscosso notevole successo negli ultimi
tempi.
REST si riferisce ad un insieme di principi di architetture di rete, i quali
delineano come le risorse sono definite ed indirizzate. Il termine è spesso
usato nel senso di descrivere ogni semplice interfaccia che trasmette dati su
HTTP senza un livello opzionale come SOAP o la gestione della sessione
tramite i cookie. Questi due concetti possono andare in conflitto così come
in sovrapposizione. È possibile progettare ogni sistema software complesso
in accordo con l’architettura REST senza usare HTTP e senza interagire con
il World Wide Web.
È altresì possibile progettare una semplice interfaccia XML+HTTP che
non sia conforme ai principi REST, e invece segua un modello di Remote
Procedure Call. I sistemi che seguono i principi REST sono spesso definiti
"RESTful".
REST prevede che la scalabilità del Web e la crescita siano diretti risultati
di pochi principi chiave di progettazione:

• lo stato dell’applicazione e le funzionalità sono divisi in Risorse Web;

• ogni risorsa è unica ed indirizzabile usando una sintassi universale


tramite link ipertestuali;

• tutte le risorse sono condivise con interfaccia uniforme per il trasferi-


mento di stato tra client e risorse, che consiste in:

– un insieme vincolato di operazioni ben definite;


– un insieme vincolato di contenuti, opzionalmente supportato da
codice on-demand;
– un protocollo che è: client-server, stateless, cacheable ed organiz-
zato a livelli.
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 23

Utilizzando messaggi basati su XML, i servizi RESTful possono unire dati


discreti provenienti da differenti servizi per creare insiemi di dati con un
particolare significato. Questa operazione prende il nome di mashup.
Se da un punto di vista concettuale il mashup è molto utile ed abbraccia
nettamente l’idea di personalizzazione del Web, la sua implementazione reale
non è altrettanto semplice ed immediata.
Per superare i problemi di implementazione, grossomodo legati alla com-
plessità intrinseca di tale attività, diverse aziende hanno prodotto tool in
grado di assistere e supportare tale attività. I più noti sono: Yahoo’s pipes 1 ,
IBM QEDwiki 2 e Google Mashup Editor 3 .
Anche in questo caso, come nel caso dei Web Service, il problema dell’in-
tegrazione ed in generale quello della interoperabilità tra diversi servizi trova
nella descrizione sintattica una forte limitazione.
Sovente è difficile integrare dati attraverso la loro sola descrizione sintat-
tica e strutturale: sono necessarie tecniche semantiche.

2.1.2 Limiti dei Web Service


Per sua natura, la comunicazione tra l’offerente ed il richiedente avviene uti-
lizzando XML. Se tale caratteristica, da un lato risolve definitivamente il
problema della compatibilità, dall’altro ne appesantisce i dati poiché oltre
al contenuto informativo vero e proprio sono necessari tag e strutture ag-
giuntive. Oltre a ciò è anche necessario che i due attori della comunicazioni
effettuino ogni volta una codifica e decodifica delle informazioni. Questi fat-
tori rendono i Web Service poco adatti ad applicazioni per le quali la velocità
rappresenti un fattore critico.
Per diverso tempo, la capacità di cercare, selezionare, comporre ed ese-
guire questi servizi web è stata prerogativa unica degli sviluppatori: unici
attori capaci di comprendere la semantica sottesa a ciascun servizio per poi
realizzarne un’opportuna combinazione al fine di produrre applicazioni più
articolate e complesse.
1
http://pipes.yahoo.com/pipes/
2
http://services.alphaworks.ibm.com/graduated/qedwiki.html
3
http://editor.googlemashups.com (Il tool è stato dismesso pochi giorni fa)
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 24

E’ proprio in quest’ultima pratica che risiede il principale limite dei servizi


web comunemente utilizzati. Alla luce del successo di tale tecnologia e della
facilità con la quale ogni applicazione se ne serve, delegare attività quali la
ricerca, la selezione e la composizione ad attori umani è oggigiorno diventato
un vincolo troppo stringente.

2.2 Dai Web Service ai Semantic Web Service


Uno dei punti più delicati per tutti i web service è la fase di ritrovamen-
to. La pubblicazione del servizio tramite UDDI non garantisce il corretto
ritrovamento del servizio ma soltanto la sua pubblicazione.
Attualmente i servizi web vengono ritrovati dagli sviluppatori software
con diversi criteri. La ricerca di tali servizi è difficoltosa e non sempre fruttuo-
sa. La chiave necessaria per migliorare la fase di ritrovamento è l’associazione
di semantica a ciascun servizio.
Si cerca di trovare soluzioni che consentano di superare il limite sintattico.
La ricerca universitaria, insieme a quella aziendale, si sono mosse verso la
semantica.
Si studiano tecniche orientate ad arricchire ciascun servizio web già esi-
stente con un livello semantico che esprima le funzionalità del servizio in
maniera machine-readable.
La scelta di arricchire le risorse correntemente esistenti è chiaramente
essenziale in un’ottica aperta come quella del web: i tentativi di riscrittura
dell’architettura dell’informazione sono, de facto, improponibili.
Ogni servizio web viene arricchito di informazioni indispensabili per chia-
rire il servizio in esame, espresse con un formalismo standard utilizzando un
vocabolario condiviso ed algoritmi di ragionamento su meta-dati.
A tal proposito, giocano un ruolo decisivo, le ontologie.

2.2.1 Semantica nel web


I soli Web Service non sono sufficienti a costruire processi Web sofisticati.
Via via si è convenuto nel ritenere che è essenziale rendere i servizi web,
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 25

machine-understandable per consentire l’implementazione di soluzioni idonee


a supportare tutte le fasi del ciclo di vita di un processo Web.
Nasce proprio dall’idea del “Semantic Web”, l’esigenza di rendere com-
prensibili anche alla macchina i diversi servizi disponibili. In quest’ottica, le
ontologie giocano un ruolo decisivo e vengono considerate il blocco fondante
del Semantic Web poiché consentono l’interpretazione dei dati da parte dei
calcolatori riducendo, conseguentemente, il coinvolgimento dell’uomo.
In letteratura esistono diverse definizioni di ontologia tutte afferenti a
particolari ambiti disciplinari. Quella più generale è la seguente [48]:

«Un’ontologia è un specifica formale ed esplicita di una con-


cettualizzazione condivisa».

Una ontologia, semplificando, è un repertorio di concetti e relative relazioni


rilevanti per un certo dominio applicativo.
In tal senso le ontologie si possono classificare a seconda di quanto sono
generali: si va dalle ontologie top-level (che formalizzano concetti generali
o di senso comune) fino alle ontologie di applicazione (che trattano concetti
molto specifici relativamente a particolari attività in particolari domini).
Una ulteriore classificazione viene operata relativamente al contenuto del-
le ontologie. Le ontologie pesanti sono caratterizzate dalla presenza di vin-
coli ed assiomi generali; si contrappongono alle ontologie leggere che di so-
lito rappresentano solo concetti con le relative proprietà ed eventualmente
tassonomie.
Nella maggior parte dei casi, la rappresentazione di una ontologia è sempre
formale poiché il fine ultimo è quello di rendere una parte di conoscenza
comprensibile al calcolatore. Sotto opportune condizioni, infatti, è possibile
usare un’ontologia per ragionare induttivamente, classificare ed in generale
fare inferenze logiche.
Questi grandi repository di conoscenza vengono costruiti appositamente
da utenti che prendono il nome di Ingegneri della conoscenza: attori in grado
di definire i concetti rilevanti per il dominio di interesse, ordinare i concetti
in gerarchie, definire le proprietà ed i vincoli su di essi, nonché stabilire le
opportune relazioni.
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 26

Realizzare da zero un’ontologia di un dominio, anche non particolarmente


vasto, non è un lavoro banale. Il numero di considerazioni, decisioni proget-
tuali che devono essere intraprese, unitamente alla profonda conoscenza di
dominio richiesta per la realizzazione di un’ontologia, fanno si che si prediliga
l’uso di ontologie vicine al proprio dominio (o a volte la personalizzazione di
queste) piuttosto che la sua costruzione “from scratch”.
Il linguaggio standard per la definizione di ontologie è OWL. Il 27 ottobre
2007, il W3C ha annunciato OWL 2 suggerendolo come raccomandazione per
la creazione di ontologie.

2.2.2 Web Ontology Language (OWL)


OWL estende RDF Schema (linguaggio utilizzato nel Semantic Web per rap-
presentare meta-informazioni) sia includendo costrutti per poter esprimere
relazioni complesse tra classi differenti specificate in RDF Schema, sia ac-
crescendo la specifica delle restrizioni applicabili alle classi e alle proprietà.
OWL specifica tre sotto-linguaggi utilizzabili in base alle esigenze espressive
che emergono durante la fase di progettazione dell’ontologia:

• OWL Lite è utile quando nella costruzione dell’ontologia si ha biso-


gno soltanto di gerarchie di classificazione e restrizioni semplici sulle
proprietà;

• OWL DL è utile quando è necessaria la massima espressività mantenen-


do la completezza computazionale e la decidibilità. OWL DL include
tutti i costrutti del linguaggio OWL, ma questi possono essere utilizzati
solo sotto certe restrizioni (per esempio, una classe può essere sotto-
classe di più classi ma non può essere istanziata da un’altra classe).
L’acronimo DL sta per Description Logic, il linguaggio logico alla base
di OWL;

• OWL Full è utile quando si ha bisogno del massimo potere espressivo


e della libertà sintattica di RDF senza che vi siano garanzie computa-
zionali (in pratica è utile solo per la rappresentazione dei contenuti, ma
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 27

Figura 2.2.1: Esempio di dichiarazione in OWL

non per il loro utilizzo). Ognuno di questi sotto-linguaggi è un’estensio-


ne del suo predecessore, sia in termini di cosa può essere rappresentato,
sia in termini di cosa può essere validamente dedotto dalle informazioni
rappresentate.

Una tipica ontologia OWL comincia con una dichiarazione dello spazio dei
nomi (URI) che fornisce un modo per l’interpretazione non ambigua degli
identificatori e rende la presentazione dell’ontologia più leggibile indicando
precisamente quali sono i vocabolari utilizzati.
Una volta dichiarati i namespace, si dichiarano un insieme di asserzioni
inerenti l’ontologia. Queste asserzioni contengono il nome, alcuni commenti,
la versione dell’ontologia e possono specificare l’inclusione di altre ontologie
(vedi Figura 2.2.1).
Dopo queste dichiarazioni è possibile specificare gli elementi di base del-
l’ontologia (vedi Figura 2.2.2). Tali elementi sono le:

• classi;

• proprietà;

• istanze delle classi;

• relazioni tra le istanze.


CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 28

OWL fornisce i costrutti necessari per definire questi elementi. Generalmen-


te, il concetto fondamentale in un dominio deve corrispondere alle classi che
sono alla radice delle varie strutture ad albero che ne rappresentano la tasso-
nomia. Ogni individuo nel mondo OWL è un membro della classe owl:Thing.
Per questo motivo ogni nuova classe definita dall’utente sarà implicitamente
una sottoclasse di owl:Thing. Le classi radice di uno specifico dominio, pos-
sono essere definite semplicemente dichiarandone il nome. OWL permette
anche la definizione della classe vuota, owl:Nothing.
La definizione di una classe è suddivisa in due parti: un nome introduttivo
o un riferimento ed una serie di restrizioni. Ognuna delle espressioni che sono
contenute all’interno della definizione della classe, restringono le proprietà
che possono essere applicate alle istanze della classe definita. Le istanze
della classe appartengono all’intersezione delle restrizioni su di essa.
In aggiunta alle classi, OWL permette di descrivere anche i loro membri.
Normalmente pensiamo ai membri come degli individui nel nostro universo
delle cose. Un individuo è introdotto principalmente dichiarando la sua ap-
partenenza ad una classe. È importante sottolineare le differenze tra classe
e individuo in OWL.
Una classe è da considerarsi semplicemente come un nome e una colle-
zione di proprietà che descrive un insieme d’individui. Gli individui sono i
membri di questi insiemi. Per questo motivo le classi devono corrispondere
agli insiemi delle cose che compaiono in modo naturale nel dominio di un
discorso e gli individui devono invece corrispondere proprio a quelle entità
che possono essere raggruppate in queste classi.
Le proprietà OWL sono relazioni binarie che permettono di asserire fatti
generali riguardo i membri delle classi e di asserire fatti specifici riguardo gli
individui. Si distinguono due tipi di proprietà:

• datatype properties: relazioni tra le istanze delle classi ed elementi RDF


literals o tipi di dati XML Schema;

• object properties: relazioni tra le istanze di due classi.

Quando si definisce una proprietà si utilizzano alcuni meccanismi per restrin-


gere tale relazione (vedi Figura 2.2.2). I più semplici sono:
CAPITOLO 2. SERVICE ORIENTED ARCHITECTURE 29

Figura 2.2.2: Dichiarazione degli elementi di base in OWL

specificare il dominio e l’intervallo (range) della proprietà;


specializzare una proprietà esistente (sotto-proprietà), ma OWL ne inclu-
de molti altri che sono più specifici (property restrictions).
Capitolo 3

Semantic Web Service

I Semantic Web Service [13, 26] nascono con l’obiettivo di riprogettare i


processi d’integrazione dei Web service [43] allo scopo di automatizzare le
fasi di ritrovamento, selezione, composizione e invocazione.
Generalmente un Semantic Web Service è descritto attraverso un’onto-
logia dei servizi, che rende “comprensibili” alle macchine le sue capacità e
permette di integrarle con una conoscenza di dominio che può anche essere
utilizzata in maniera indipendente.
Arricchiti con una descrizione formale delle proprie capacità [23], questi
servizi possono essere utilizzati da altre applicazioni o da altri servizi senza
specifici interventi da parte dell’uomo o accordi molto vincolanti su interfacce
e protocolli. I Semantic Web Service appaiono dunque come un’estensione
delle attuali tecnologie e standard per i Web service realizzata utilizzando le
tecnologie e gli standard del Semantic Web (vedi Figura 3.0.1).

Figura 3.0.1: Semantic Web Services nel Semantic Web

30
CAPITOLO 3. SEMANTIC WEB SERVICE 31

Cardoso e Sheth in [14] dividono il significato di semantica in quattro


diversi tipi, ciascuno dei quali opportunamente scelto per rappresentare le
capacità, i requisiti, gli effetti e l’esecuzione del servizio web.

3.1 Tipi di semantica


Il termine semantica indica un riferimento ad uno stato concettuale e non
meramente sintattico. Posto in essere ciò, è sempre possibile individuare a
seconda dei contesti d’uso, accezioni di semantica diverse.
Di seguito si riportano quelle individuabili all’interno dello scenario dei
servizi web.

3.1.1 Semantica funzionale


Il potere dei Web Service si manifesta solo quando vengono ritrovati servizi
appropriati, rispondenti ai requisiti funzionali.
Un assunzione universale per i differenti algoritmi di discovery di servizi
web semantici è che la funzionalità del servizio è caratterizzata dal suo input
e dal suo output.
In tal senso questi algoritmi cercano le corrispondenze tra input ed output
dei servizi, ed input ed output dei requisiti. Questo tipo di corrispondenza
semantica, da sola, può non restituire risultati appropriati che soddisfino i
requisiti funzionali.
Per esempio: due servizi possono avere le stesse specifiche di input/output
anche se assolvono a compiti completamente diversi. Un servizio semplicis-
simo di somma di due numeri avrà lo stesso significato sintattico di un altro
servizio che effettua la differenza tra due numeri.
Effettuare il confronto basandosi esclusivamente sul contratto di inter-
faccia di un servizio web può non fornire i risultati attesi. Per rappresen-
tare la funzionalità del servizio migliorando il ritrovamento e la selezione, è
indispensabile annotare lo stesso con semantica funzionale.
Disponendo di un’ontologia di tipo funzionale, nella quale ogni concet-
to/classe rappresenta una funzionalità ben definita del dominio scelto, l’inten-
CAPITOLO 3. SEMANTIC WEB SERVICE 32

to è quello di agganciare ogni funzionalità ad uno o più concetti dell’ontologia


di riferimento.
Anziché utilizzare ontologie, in alcuni rari casi la semantica funzionale può
essere espressa per categorizzazione. Tale tecnica è utilizzabile solo quando
le funzionalità del servizio ricadono in categorie prestabilite da organi com-
petenti, come United Standard Products and Services Code (UNSPSC1 ) o il
RosettaNet Technical Dictionary (RNTD2 ).

3.1.2 Semantica dei dati


Tutti i Web Service prevedono un set di input e producono un set di out-
put. Entrambi gli insiemi di dati sono descritti all’interno del documen-
to WSDL. Tuttavia la specifica di tali operazioni viene fornita soltanto in
termini sintattici (anche nel caso di strutture dati complesse).
Questi dettagli (come i tipi dei dati, lo schema XML dei tipi complessi)
sono utilizzati per l’invocazione del servizio. Per effettuare il ritrovamento di
servizi, è necessario esprimere la semantica dei dati di input/output [21].
Quindi, se i dati coinvolti nell’operazione del Web service fossero annotati
utilizzando un’apposita ontologia, allora questi potrebbero essere utilizzati
per effettuare un confronto semantico tra i dati di input/output dei servizi e
quelli di input/output delle richieste.

3.1.3 Semantica della qualità


Dopo aver ritrovato i Web Service la cui semantica corrisponde con quella
delle richieste, il passo successivo è selezionare il servizio più adatto. Ogni
servizio può avere diverse qualità perciò la scelta implica la corrispondenza
con il criterio che esprime la miglior qualità.
Il criterio di selezione del servizio riveste un ruolo essenziale specialmente
nella fase di composizione. Esso richiede la gestione di metriche di qualità
(QoS) per i Web service al fine di ottenere un set di servizi che tengano conto
delle qualità di interesse.
1
http://www.unspsc.org
2
http://www.rosettanet.org/Standards/RosettaNetStandards/Dictionaries/tabid/477/Default.aspx
CAPITOLO 3. SEMANTIC WEB SERVICE 33

Tuttavia, lo studio di questo tipo di semantica esula dagli obiettivi di


questo documento, dal momento che trova la sua utilità nelle fasi di selezione
e composizione, anziché in quella di annotazione.
Tale tipo di semantica è spesso esplicitata anche per elicitare dei vincoli o
dettagli specifici che non trovano spazio all’intero delle altre semantiche. E’
altresì importante specificare tale semantica per migliorare la fase di discovery
(in particolare quella di filtering) di SWS.

3.1.4 Semantica di esecuzione


La semantica di esecuzione di un Web Service coinvolge l’idea di sequenza di
messaggi, modelli di conversazione tra servizi in esecuzione, flussi di azioni,
precondizioni ed effetti dell’invocazione di un servizio.
Alcuni problemi relativi alla semantica d’esecuzione sono ereditati diret-
tamente dalle tecnologie di workflow. Nell’e-commerce, l’uso della semanti-
ca d’esecuzione può aiutare nel cercare dinamicamente servizi che non solo
condividano i requisiti funzionali, ma anche quelli operazionali come lun-
ghe interazioni o conversazioni complesse. Un modello opportuno per la se-
mantica d’esecuzione potrebbe anche aiutare a coordinare le diverse attività
transazionali.
In generale, questo tipo di semantica serve a descrivere formalmente il
servizio web da due punti di vista: esterno ed interno.
Il comportamento esterno descrive il protocollo che il client deve osservare
per consumare le funzionalità del servizio. Il comportamento interno, al
contrario, descrive un flusso di lavoro: come le funzionalità del servizio si
aggregano con eventuali servizi esterni. La formalizzazione di quest’ultimo
comportamento (quello interno) esula dall’interesse di questo documento.

3.2 Infrastruttura dei Semantic Web Service


L’infrastruttura di servizi può essere descritta attraverso tre dimensioni orto-
gonali (vedi Figura 3.2.1): Activities (casi d’uso), Architecture (architettura)
CAPITOLO 3. SEMANTIC WEB SERVICE 34

Figura 3.2.1: Le dimensioni delle infrastrutture per Semantic Web Services

e Service Ontology (ontologia di descrizione dei servizi). Queste dimensioni


sono correlate ai requisiti per i SWS a livello business, fisico e concettuale.
I casi d’uso servono per definire i requisiti funzionali, tutto ciò che in
altri termini un framework per i Semantic Web Service deve essere in grado
di supportare. L’architettura dei SWS descrive le componenti necessarie
per portare a termine queste attività. L’ontologia di servizio si occupa di
aggregare tutti i modelli concettuali collegati alla descrizione di un Semantic
Web Service e forma il modello della conoscenza riguardante le informazioni
per descrivere e supportare l’utilizzo del servizio.
Dal punto di vista dei casi d’uso, i SWS sono visti come oggetti all’in-
terno di uno scenario di esecuzione di un’attività di business. Le attività
individuate come necessarie per eseguire un’applicazione utilizzando i SWS
sono le seguenti:

• La pubblicazione o pubblicizzazione (publishing) di un SWS permetterà


agli agenti o alle applicazioni di “ritrovare” i servizi a partire dagli obiet-
tivi che l’applicazione vuole conseguire o dalle caratteristiche offerte dai
servizi stessi (annotation) [43]. Sarà utilizzato un registro semantico
per registrare istanze dell’ontologia per i singoli servizi. L’ontologia di
servizio sarà in grado di distinguere tra informazioni utilizzate per il
matching durante la fase di ritrovamento ed altre utilizzate durante la
fase d’invocazione del servizio. In aggiunta, la conoscenza di dominio
può anche essere pubblicata o collegata all’ontologia dei servizi.
CAPITOLO 3. SEMANTIC WEB SERVICE 35

• Il ritrovamento (discovery) di servizi consiste nel matching semantico


tra la descrizione della richiesta di un servizio e la descrizione di un
servizio pubblicato. Le query coinvolgono il nome del servizio, l’input,
l’output, le pre-condizioni e altri attributi che possono essere costruiti
e utilizzati per la ricerca all’interno del registro semantico. Il matching
può essere fatto anche a livello di task da compiere o di obiettivi da
raggiungere, seguito da una operazione di selezione tra i servizi che
si occupano di risolvere uno specifico task. Nel caso in cui ci sia più
di un servizio corrispondente alla richiesta, sarà necessaria una fase
di selezione (selection). Attributi non funzionali come ad esempio il
costo o la qualità potranno essere utilizzati per la scelta del servizio.
Attraverso dei meccanismi d’interazione agent-based o comunque più
specializzati, il processo di negoziazione potrà avvenire tra un requester
e un provider in modo automatico, ma questo richiede che anche i
servizi stessi siano basati su conoscenza [4, 24, 9].

• I meccanismi di composizione (composition) [5] permettono di definire


SWS in termini di altri servizi più semplici. Un workflow che esprime
la composizione di servizi atomici può essere definito nell’ontologia dei
servizi utilizzando appropriati costrutti di controllo. La composizione
dinamica può anche essere vista come un approccio per la richiesta del
servizio nel quale i servizi atomici richiesti per risolvere una richiesta
sono individuati e composti “al volo”. Questo però richiede un invoker
che si occupi del matching [25]tra l’output del servizio atomico e l’input
del servizio richiesto;

• l’invocazione (invocation) dei SWS coinvolge un certo numero di passi,


non appena l’input richiesto è stato fornito dal richiedente del servizio.
Per prima cosa, è necessario istanziare il servizio e le ontologie di do-
minio ad esso associate. Secondariamente, l’input deve essere validato
in base all’ontologia di dominio, ed infine il servizio può essere invocato
o può essere eseguito un workflow sulla base di tutto ciò che è stato
fornito fino a questo punto. E’ anche importante il monitoraggio dello
CAPITOLO 3. SEMANTIC WEB SERVICE 36

stato del processo di decomposizione e di notifica al richiedente nel caso


in cui avvengano delle eccezioni;

• il deployment di un Web service da parte di un provider è indipendente


dalla pubblicazione della sua descrizione semantica poiché lo stesso Web
service può essere utilizzato per scopi differenti. L’infrastruttura dei
SWS, però, può fornire delle agevolazioni per il deployment istantaneo
del codice a partire da una descrizione semantica;

• la gestione delle ontologie (ontology management) di descrizione dei


servizi è un’attività chiave per i SWS poiché garantisce che le descrizioni
semantiche dei servizi siano create, riutilizzate e manipolate all’interno
del Semantic Web.

Da un punto di vista architetturale, i SWS sono definiti come un insieme di


componenti che si occupano di realizzare le attività descritte sopra, con alla
base dei meccanismi per la gestione della sicurezza.
Le componenti precedentemente descritte includono: un reasoner, un
register, un matchmaker, un decomposer ed un invoker:

• il reasoner è utilizzato durante tutte le attività e fornisce il supporto


ai meccanismi di ragionamento necessari per interpretare le descrizioni
semantiche e le query;

• il register fornisce i meccanismi per la pubblicazione e la localizzazio-


ne dei servizi all’interno del registro semantico e tutte le funzionalità
necessarie per la creazione e l’editing delle descrizioni dei servizi;

• il matchmaker si occupa di mediare tra il requester e il register durante


la fase di discovery e di selezione dei servizi;

• il decomposer è la componente richiesta per l’esecuzione del modello di


composizione dei servizi composti;

• l’invoker si occupa di mediare tra il requester (o il decomposer) e il


provider al momento dell’invocazione del servizio.
CAPITOLO 3. SEMANTIC WEB SERVICE 37

L’ontologia di descrizione del servizio è un’altra dimensione con cui è possibile


definire i SWS. Essa descrive le caratteristiche del servizio e le restrizioni
applicate al suo utilizzo.
L’ontologia dei servizi integra tutte le informazioni definite attraverso gli
standard dei Web service con la conoscenza di dominio. Questa generalmente
include:

• caratteristiche funzionali come l’input, l’output, pre e post condizioni;

• caratteristiche non funzionali come la categoria, i costi e la qualità del


servizio;

• informazioni correlate al provider come il nome dell’impresa e il suo


indirizzo;

• informazioni correlate al task o al goal;

• conoscenza di dominio che definisce, ad esempio, la tipologia dell’input


di un servizio.

La conoscenza di dominio, che definisce le proprietà funzionali e non funziona-


li del servizio, può essere suddivisa in diverse ontologie. Tuttavia, l’ontologia
utilizzata per descrivere i SWS potrà contare sull’espressività e sul potere
inferenziale del linguaggio ontologico supportato dal Semantic Web.

3.3 Annotazione semantica


Le specifiche dei Web service sono oggi basate su standard che ne definiscono
solo le caratteristiche sintattiche. Sfortunatamente, ciò non è sufficiente, dal
momento che l’interoperabilità automatica dei servizi/processi Web non può
evidentemente essere ottenuta.
Una delle soluzioni largamente riconosciute per risolvere tale problema è
abilitare le applicazioni alla comprensione dei metodi e dei dati, aggiungendo
ad essi un significato interpretabile dalla macchina.
CAPITOLO 3. SEMANTIC WEB SERVICE 38

Esistono diversi tool utili alla creazione dei Web Service: le stesse ap-
plicazioni scritte in Java (o in qualsiasi altro linguaggio orientato agli og-
getti) possono essere agevolmente tradotte in Web service. In fondo ogni
programma (in qualsiasi linguaggio) può esporre Web Service.
Tuttavia è indispensabile, fin dai primi passi della creazione di un Web
Service, cominciare ad usare semantica (nei diversi tipi sopra descritti). Du-
rante lo sviluppo, la semantica dei dati, quella funzionale e quella di qualità
hanno bisogno di essere specificate.
Tutti i Web service richiedono un set di input e producono un set di out-
put. Queste informazioni sono presenti all’interno del contratto delle opera-
zioni in una particolare sezione del file WSDL. Tuttavia la definizione del-
l’interfaccia fornisce soltanto una specifica sintattica oltre che una specifica
strutturale dei dati. Per effettuare il ritrovamento automatico dei servizi, è
necessario associare la semantica dei dati [32].
Quindi, se i dati coinvolti nel servizio fossero annotati utilizzando un’onto-
logia [9], allora tale semantica dei dati potrebbe essere utilizzata per il calcolo
della corrispondenza tra: semantica dei dati di ciascun servizio e semantica
dei dati del servizio richiesto.
In questo momento non esiste una tecnologia universale riconosciuta come
tale per l’annotazione semantica di un Web Service o più in generale di
documenti Web. I due principali attori coinvolti nella sfida della semantica
sul Web, aziende ed università, hanno dato vita, talvolta assieme, ad una serie
di linguaggi che nel corso della storia hanno registrato consensi e dissensi.
A prescindere dal tipo di linguaggio utilizzato, in questo momento lo
stato dell’arte è diviso principalmente in due categorie di strumenti per
l’annotazione:

• manuali;

• semi-automatici.

L’attività di annotazione, per sua natura, non può (e forse potrà) mai essere
completamente demandata ad un calcolatore: l’intervento umano rimane
indispensabile.
CAPITOLO 3. SEMANTIC WEB SERVICE 39

3.3.1 Tool per l’annotazione semantica


Di seguito si riportano i tool più diffusi per l’annotazione semantica di docu-
menti WSDL [42]. Esistono fondamentalmente due tipi di tool di annotazione
semantica: semi-automatici e manuali.
Nell’annotazione semantica manuale, l’intervento dell’utente è indispen-
sabile. Con questo tipo di approccio è l’utente ad operare le scelte di associa-
zione tra concetti, laddove il tool si limita a fornire l’interfaccia grafica (e alle
volte strumenti corollari) per modificare opportunamente il codice del docu-
mento WSDL. Con l’approccio semi-automatico il tool implementa algoritmi
di NLP che suggeriscono all’utente delle possibili associazioni. L’operatore,
in tal caso, ha il compito di visionare le associazioni proposte ed accettarle
o rigettarle.
La fase di annotazione semantica è particolarmente importante poiché da
essa dipende la comprensibilità del documento annotato da parte delle mac-
chine. L’intervento umano è attualmente indispensabile poiché è in grado di
garantire la coerenza dell’annotazione. Per questa ragione non esistono tool
completamente autonomi che non richiedono l’intervento dell’utente (tool
automatici).

3.3.1.1 Tool semi-automatici

Meteor-S Web Service Annotation Framework Meteor-S3 è un insie-


me di tool realizzati per agevolare l’arricchimento semantico di Web Service
[39].
Questo strumento, realizzato al LSDIS Lab della University of Georgia,
si compone di 5 tool software distinti: MWSAF, Publishing, MWSDI, BPEL
Editor e MWSCF.
MWSAF4 è il tool dedicato all’annotazione semantica di documenti WSDL
(vedi Figura 3.3.1). Si tratta di un software realizzato in Java che mostra
un layout organizzato in 3 colonne. Nella prima sono visualizzati in maniera
gerarchica tutti i nodi di interesse semantico del file WSDL caricato.
3
http://lsdis.cs.uga.edu/projects/meteor-s/index.php?page=0
4
http://lsdis.cs.uga.edu/projects/meteor-s/demo/METEOR-S-9.htm
CAPITOLO 3. SEMANTIC WEB SERVICE 40

Figura 3.3.1: Screenshot del tool MWSAF

Nella terza colonna vengono visualizzati tutti i concetti contenuti in una


determinata ontologia. La colonna centrale viene utilizzata per suggerire
il matching tra documento WSDL ed ontologia in base ad un algoritmo
di matching che fornisce anche un coefficiente (da 0 ad 1) della pertinenza
dell’associazione.
Ogni associazione proposta è corredata da una relativa check-box, agendo
sulla quale, l’utente può accettare l’associazione proposta o respingerla. Non
tutte le informazioni del documento WSDL possono trovare un’associazione
con i concetti espressi dall’ontologia scelta.
Al termine della fase di approvazione dei differenti match proposti dal
sistema, è possibile applicare l’annotazione semantica al documento WSDL
originale utilizzando l’apposita voce di menù.
Si tratta di un annotatore semi-automatico per documenti WSDL.

IBM Semantic Tools for Web Services Si tratta di una serie di plug-in
per Eclipse particolarmente utili quando è necessario effettuare il mashup
di diversi Web Service. Uno di questi è quello di Web Service Interface
Matching 5 .
5
http://www.alphaworks.ibm.com/tech/wssem
CAPITOLO 3. SEMANTIC WEB SERVICE 41

Figura 3.3.2: Screenshot di IBM Annotation Editor da pagina HTML

Attraverso questo strumento è possibile, in maniera semi-automatica,


procedere all’associazione delle interfacce di due servizi (vedi Figura 3.3.2).
Il software calcola la similarità semantica tra le descrizioni dei servizi risol-
vendo le differenze lessicali, strutturali e sintattiche dei documenti e creando
una mappa di connessione tra essi (vedi Figura 3.3.3). Fu inizialmente creato
per supportare WSDL-S (poi evolutosi in SAWSDL). Utilizza tecniche di In-
formation Retrieval [40]: part-of-speech tagging e consultazione automatica
di tesauri in inglese.

3.3.1.2 Tool manuali

Radiant Radiant6 è un tool per l’annotazione semantica di documenti


WSDL utilizzando lo standard SAWSDL. Non si tratta di un’applicazione
stand-alone ma di un plug-in per Eclipse.
Anch’esso sviluppato dal LSDIS della University of Georgia, visualizza
graficamente i nodi del documento WSDL ed i concetti dell’ontologia di
riferimento (vedi Figura 3.3.4).
L’ontologia di riferimento può essere sia locale (in formato OWL) oppure
6
http://lsdis.cs.uga.edu/Radiant/RadiantDemo/
CAPITOLO 3. SEMANTIC WEB SERVICE 42

Figura 3.3.3: Screenshot di IBM Annotation Editor

Figura 3.3.4: Screenshot di Radiant


CAPITOLO 3. SEMANTIC WEB SERVICE 43

remota. In questo caso il matching tra i concetti non viene proposto dal
software ma gestito manualmente e completamente dall’utilizzatore del tool.
E’ possibile interagire tra gli elementi utilizzando scorciatoie più naturali
ed immediate, come il drag&drop nodo-nodo (associando un concetto ontolo-
gico direttamente ai nodi del documento WSDL sulla sinistra) e nodo-codice
(associando il concetto ontologico in porzioni di codice WSDL nella colonna
centrale).
Si tratta di un semplice annotatore manuale per documenti WSDL.

WODEN4SAWSDL WODEN4SAWSDL7 è una libreria Java, realizzata


ed utilizzata da METEOR-S per facilitare la gestione di documenti WSDL
2.0 da annotare semanticamente con lo standard SAWSDL.
All’interno di tale libreria non vi sono algoritmi per l’annotazione se-
mantica ma solo le primitive per l’interazione con il modello WSDL 2.0 e
SAWSDL. Le API sono disponibili gratuitamente attraverso il sito web del
progetto.

SAWSDL4J SAWSDL4J8 è una libreria Java che facilita enormemente


l’interazione con un documento WSDL ed il suo arricchimento semantico.
Queste API si basano sulle precedenti (in termini di tempo) WSDL4J: librerie
Java utili per l’interazione con documenti WSDL.

WSMO Studio WSMO Studio9 è un framework open-source per la mo-


dellazione di Semantic Web Service e Semantic Business Process.
Si tratta di un tool capace di gestire ontologie, elementi WSMO ed
arricchire documenti WSDL utilizzando SAWSDL (Figura 14).
Il difetto di questo tool è la sua forte connessione con WSMO ed i suoi
elementi fondanti. Se il file WSDL può essere corredato da annotazioni
in SAWSDL, questo deve comunque allacciarsi ad ontologie descritte con
WSML.
7
http://lsdis.cs.uga.edu/projects/meteor-s/opensource/woden4sawsdl/index.html
8
http://knoesis.wright.edu/opensource/sawsdl4j/index.html
9
http://www.wsmostudio.org/
CAPITOLO 3. SEMANTIC WEB SERVICE 44

Figura 3.3.5: Screenshot di WSMO Studio

Anche in questo caso, l’attività di annotazione non è assistita ma com-


pletamente manuale. E’ l’utente che utilizza il tool a dover decidere le
associazioni da implementare.

SCA Tools per Eclipse Si tratta di un’insieme di plug-in appositamente


realizzati per gestire le informazioni semantiche in Eclipse.
SCA Tool Feature - SAWSDL Support10 è, in particolare, il tool che
consente l’annotazione in SAWSDL di documenti WSDL (Figura 15).
Per utilizzarlo è necessario installare Jena che fornisce una comoda inter-
faccia per la ricerca di concetti all’intero di ontologie locali e remote.
Dopo aver individuato con Jena il concetto che ci interessa è possibile
trascinarlo direttamente nel codice del documento WSDL. Il plug-in si pre-
occuperà di incollare il codice in formato SAWSDL (utilizzando gli apposite
proprietà di estensione).
E’ un tool di annotazione completamente manuale dal momento che
spetta all’utente la fase di ricerca dei concetti più adatti.
10
http://wiki.eclipse.org/STP/SCA_Project
CAPITOLO 3. SEMANTIC WEB SERVICE 45

Figura 3.3.6: Screenshot di Jena con “SCA Tool Feature - SAWSDL Support”

3.3.2 Elaborazione del linguaggio naturale


Per indicizzazione semantica di documenti si intende la capacità di catalogare
le parole presenti all’interno di un documento in base al loro significato.
Semplificando, è possibile associare ad ogni parola il significato corretto
in base al contesto in cui la parola è utilizzata. L’utilizzo di tale strategia di
indicizzazione da parte di un motore di ricerca implica la sua realizzazione
in maniera del tutto automatica.
Associare un significato ad una parola è il risultato di un processo che
sfrutta una grande quantità di conoscenza nel campo della Natural Language
Processing (NLP).
La Figura 3.3.7 mostra schematicamente il processo di elaborazione del
linguaggio naturale all’interno del quale vi sono diverse attività.

• Normalizzazione del testo: il testo viene “ripulito” dei caratteri che non
sono utili (per esempio una pagine HTML viene ripulita dei tag) e viene
preparato nel formato richiesto dalle fasi successive.

• Riconoscimento della lingua: viene riconosciuta la lingua del testo, in


modo da poter caricare tutte le risorse linguistiche necessarie ai processi
successivi.
CAPITOLO 3. SEMANTIC WEB SERVICE 46

Figura 3.3.7: Schematizzazione del processo di indicizzazione semantica dei


documenti

• Part-of-speech tagging: viene attribuita ad ogni parola il suo ruolo


grammaticale (nome, verbo, aggettivo, avverbio,. . . ).

• Stemming: tutte le parole vengono ricondotte alla loro radice (ad


esempio “toys” diventa “toy”).

• Riconoscimento delle entità: vengono ricercati all’interno del testo i


nomi propri di città, personaggi celebri, fiumi, mari, date, simboli di
valuta, sigle, ecc. . .

• Eliminazione stop word : vengono eliminate le parole che apportano


scarsa informazione, come articoli e preposizioni.

• Word Sense Disambiguation: si cerca di attribuire ad ogni parola il


giusto significato all’interno del documento.

Il risultato di tale processo è la BOC (bag-of-concepts), ovvero ad ogni docu-


mento viene associato un insieme di concetti (significati), che sarà utilizzato
nel processo di ricerca per poter rintracciare i documenti che contengono uno
o più significati. La BOC può essere strutturata in modo differente, ma il suo
scopo è sempre quello di contenere informazioni semantiche. Ogni elemento
della BOC potrebbe avere una struttura siffatta:
CAPITOLO 3. SEMANTIC WEB SERVICE 47

< position, stem, P OS − tag, concept, T F/IDF >

nella quale:

• position: individua la posizione della parola all’interno del documento;

• stem: radice della parola;

• POS-tag: ruolo grammaticale della parola;

• concept: codice identificativo che individua univocamente il significato


della parola all’interno di una ontologia lessicale;

• TF/IDF : misura del potere informativo del concetto all’interno del do-
cumento ed è calcolata come: cf ∗ (log( cf
ndoc
doc
)), dove: cf è la frequenza
del concetto all’interno del documento, ndoc è il numero totale di do-
cumenti indicizzati e cfdoc è la frequenza del concetto in tutti gli ndoc
documenti.

Tale struttura permette di effettuare ricerche combinate solo sui concetti,


solo sulla radice o contemporaneamente sia sul concetto sia sulla radice.

3.4 Annotazione di SWS


Le specifiche dei Web service sono oggi basate su standard che ne definiscono
solo le caratteristiche sintattiche. Sfortunatamente, ciò non è sufficiente, dal
momento che l’interoperabilità automatica dei servizi/processi Web non può
evidentemente essere ottenuta.
Una delle soluzioni largamente riconosciute per risolvere tale problema è
abilitare le applicazioni alla comprensione dei metodi e dei dati, aggiungendo
ad essi un significato interpretabile dalla macchina.
Esistono diversi tool utili alla creazione dei Web Service: le stesse ap-
plicazioni scritte in Java (o in qualsiasi altro linguaggio orientato agli og-
getti) possono essere agevolmente tradotte in Web service. In fondo ogni
programma (in qualsiasi linguaggio) può esporre Web Service.
CAPITOLO 3. SEMANTIC WEB SERVICE 48

Tuttavia è indispensabile, fin dai primi passi della creazione di un Web


Service, cominciare ad usare semantica (nei diversi tipi sopra descritti). Du-
rante lo sviluppo, la semantica dei dati, quella funzionale e quella di qualità
hanno bisogno di essere specificate.
Tutti i Web service richiedono un set di input e producono un set di out-
put. Queste informazioni sono presenti all’interno del contratto delle opera-
zioni in una particolare sezione del file WSDL. Tuttavia la definizione del-
l’interfaccia fornisce soltanto una specifica sintattica oltre che una specifica
strutturale dei dati.
Per effettuare il ritrovamento automatico dei servizi, è necessario asso-
ciare la semantica dei dati. Quindi, se i dati coinvolti nel servizio fossero
annotati utilizzando un’ontologia, allora tale semantica dei dati potrebbe es-
sere utilizzata per il calcolo della corrispondenza tra: semantica dei dati di
ciascun servizio e semantica dei dati del servizio richiesto.
In questo momento non esiste una tecnologia universale riconosciuta come
tale per l’annotazione semantica di un Web Service o più in generale di
documenti Web.
I due principali attori coinvolti nella sfida della semantica sul Web, azien-
de ed università, hanno dato vita, talvolta assieme, ad una serie di linguaggi
che nel corso della storia hanno registrato consensi e dissensi.

3.4.1 Web Ontology Language for Services (OWL-S)


Il Web semantico dovrebbe consentire un ottimo accesso non soltanto ai
contenuti ma anche ai servizi presenti nel Web. Utenti ed agenti software
dovrebbero essere in grado di ritrovare, invocare, comporre e monitorare le
risorse del Web oltre che farlo con un grado di automazione scelto a priori.
OWL-S [52] è una ontologia di servizi [34, 35] che rende queste funzionalità
possibili.
Si tratta di un’ontologia di alto livello che fornisce un modello di rap-
presentazione astratta del servizio (vedi Figura 3.4.1 nella pagina seguente).
E’ composta da una classe radice, Service, collegata a tre classi principa-
li: il profilo del servizio per la pubblicazione ed il ritrovamento; il modello
CAPITOLO 3. SEMANTIC WEB SERVICE 49

Figura 3.4.1: Livello più generale dell’ontologia OWL-S

di processo, che fornisce una descrizione dettagliata delle operazioni; ed il


grounding, che fornisce dettagli su come interagire con il servizio, attraverso
messaggi.
Il ServiceProfile specifica le funzionalità di un servizio. Questo concetto
è il punto di partenza di alto livello per l’adattamento di un servizio ad
un modello OWL-S che supporta il retrieval di servizi [40] a partire dalla
propria descrizione semantica. Esso descrive il servizio fornendo diversi tipi
di informazioni:

• informazioni comprensibili per l’uomo (nome del servizio, descrizione


del servizio, contatti);

• funzionalità (identificatori del tipo di parametri, identificatori dell’in-


put e dell’output, parametri dei metodi del servizio, pre-condizioni,
risultati);

• parametri di servizio (identificatore dei parametri (nome,valore) utiliz-


zati dal servizio);

• categoria del servizio (identificatore della categoria del servizio dati


come nome della categoria, tassonomia, valore, codice).

Le informazioni fornite dalla descrizione delle funzionalità del servizio in-


capsulano il modello IOPE (Input, Output, Pre-condizioni, Effetti). Questa
peculiarità permette di vedere il servizio come un processo.
CAPITOLO 3. SEMANTIC WEB SERVICE 50

Il ServiceModel comunica ad un client come utilizzare il servizio, detta-


gliando il contenuto semantico della richiesta, le condizioni che potrebbero
portare a particolari conseguenze, e, dove necessario, i passi che compongono
il processo che porta a quei risultati. Esso dunque descrive come richiedere il
servizio e ciò che accade quando il servizio è eseguito. Per i servizi non banali
(quelli composti da più attività eseguite nel tempo) questa descrizione può
essere utilizzata da un agente di ricerca dei servizi in almeno quattro modi
diversi:

• per effettuare un’analisi più approfondita al fine di verificare se un


servizio soddisfa le sue necessità;

• per comporre descrizioni di servizi a partire da servizi multipli al fine


di effettuare specifici task;

• durante l’esecuzione del servizio, per coordinare le attività dei diversi


partecipanti;

• per monitorare l’esecuzione del servizio.

Dal punto di vista dei processi, ServiceModel definisce il concetto processo


(Process) che descrive la composizione di uno o più servizi in termini dei
propri processi costituenti. Un processo può essere atomico o composto.
Nel primo caso si tratta di una descrizione di un servizio che si aspetta un
messaggio e restituisce un messaggio in risposta; nel secondo abbiamo un
insieme di processi o un singolo processo.
Ciascun processo può avere un qualsiasi numero di input per rappresen-
tare le informazioni, legati comunque ad alcune condizioni. L’output di un
processo fornisce l’informazione al richiedente rispettando un certo numero
di pre-condizioni, che devono tutte essere vere affinché il processo possa es-
sere correttamente invocato. Gli effetti di un processo caratterizzano tutto
ciò che avviene dopo una corretta esecuzione del servizio.
Il ServiceGrounding specifica come il servizio deve essere invocato (sintas-
si della chiamata al servizio, tutto quello che il client ha bisogno di sapere per
CAPITOLO 3. SEMANTIC WEB SERVICE 51

utilizzare il servizio). Un “grounding” è un mapping da una specifica astrat-


ta ad una concreta di quegli elementi della descrizione del servizio che sono
necessari per interagire con il servizio. In generale, un grounding specifica:

• un protocollo di comunicazione; o il formato dei messaggi; o altri det-


tagli specifici per il servizio (ad esempio, il numero di porta utilizzato
per contattare il servizio);

• per ciascuna tipologia semantica di input o di output specificata nel


ServiceModel, la tecnica di serializzazione adottata.

Dal punto di vista dei processi, il ServiceGrounding consente la trasforma-


zione dell’input e dell’output di un processo atomico in costrutti concreti di
rappresentazione (ad esempio in WSDL).
[Ultima sottomissione al W3C: 22 novembre 2004]
[Stato: W3C Member Submission]

3.4.2 Web Service Modeling Ontology (WSMO)


Il Web Service Modeling Ontology (WSMO) fornisce un framework concet-
tuale ed un linguaggio formale per la descrizione semantica di tutti gli aspetti
rivelanti di un Web Service al fine di facilitare l’automazione del ritrovamento,
combinando ed invocando servizi elettronici attraverso il Web.
WSMO è composto da quattro elementi (Figura 2): ontologia, che for-
nisce la terminologia usata dagli altri elementi WSMO; descrizione del Web
service, che descrive gli aspetti funzionali e comportamentali del Web servi-
ce; obiettivi, che formalizzano i desideri dell’utente; mediatori, che hanno lo
scopo di gestire automaticamente i problemi d’interoperabilità tra differenti
elementi WSMO.
WSMO agisce come un meta-modello per i Semantic Web Service basato
sulla Meta Object Facility (MOF). Descrizioni semantiche che seguono il
meta-modello di WSMO possono essere definite attraverso il linguaggio Web
Service Modelling Language (WSML). WSMO enfatizza il ruolo dei mediatori
per superare i problemi d’interoperabilità. I seguenti elementi rappresentano
le componenti chiave su cui si basa WSMO:
CAPITOLO 3. SEMANTIC WEB SERVICE 52

Figura 3.4.2: Struttura di WSMO

Le ontologie (Ontologies) sono descritte in WSMO come un meta-livello.


Una meta-ontologia permette la descrizione di tutti gli aspetti delle ontologie
che forniscono la terminologia per gli altri elementi di WSMO. Un’ontologia
è composta da proprietà non funzionali (l’insieme esistente di proprietà core
predefinite), le ontologie importate, e la definizione dei concetti, relazioni,
assiomi, funzioni e istanze dell’ontologia. In aggiunta, questo meta-livello
definisce gli ooMediator che sono utilizzati per importare tutte le ontologie
per le quali i problemi di allineamento, fusione e trasformazione devono essere
risolti durante l’importazione.
I Goal sono definiti in WSMO come gli obiettivi che un client può avere
quando consulta un Web service. Questi sono composti da un insieme di
proprietà non-funzionali (da un insieme di proprietà core predefinite), onto-
logie importate, mediatori usati, post- condizioni ed effetti. Post-condizioni
ed effetti descrivono rispettivamente lo stato dello spazio delle informazioni
e del mondo, che potrebbero essere desiderati dal richiedente. Le ontologie
possono essere direttamente importate come la terminologia per definire il
goal quando non deve essere risolto alcun conflitto. Tuttavia, se è richiesto
un allineamento, un merge o la risoluzione di conflitti, essi devono essere
importati attraverso ooMediator.
I Web Services forniscono la descrizione semantica dei Web service, com-
prese le proprietà funzionali e non funzionali, così come altri aspetti rilevanti
per interoperare con loro. La terminologia richiesta, così come per i goal,
può essere importata direttamente oppure attraverso ooMediator quando ci
sono conflitti da risolvere. In aggiunta, le caratteristiche (capability) e le
CAPITOLO 3. SEMANTIC WEB SERVICE 53

interfacce di un servizio sono descritte come segue:


• le capability che definiscono gli aspetti funzionali del servizio offerto,
modellato in termini di pre-condizioni, assunzioni, post-condizioni ed
effetti;

• le interfaces che rappresentano le interfacce di un servizio e forniscono


dettagli su come opera in termini di coreografia ed orchestrazione.
I Mediators che hanno l’obiettivo di risolvere i problemi di eterogeneità. I
mediatori in WSMO sono elementi speciali utilizzati per collegare componenti
eterogenee coinvolte nella modellazione di un Web service.
Essi definiscono tutti i mapping, le trasformazioni o le riduzioni necessarie
tra gli elementi collegati. Ci sono quattro differenti tipologie di mediatori:
• ggMediators, questi collegano tra loro due goal, ed esprimono la ridu-
zione da un goal sorgente ad un goal target. Possono utilizzare gli
ooMediator per superare le differenze nella terminologia utilizzate per
riferirsi a questi goal. In aggiunta, WSMO permette il linking non solo
dei goal, ma anche dei goal dei ggMediator, permettendo di conseguenza
il riuso di più goal per la definizione di nuovi goal;

• ooMediators, questi importano le ontologie e risolvono possibili incon-


gruenze di rappresentazione tra loro, come ad esempio per i linguaggi di
rappresentazione differenti o concettualizzazioni differenti dello stesso
dominio;

• wgMediators, essi collegano un Web service ad un goal. Questi collega-


menti rappresentano il raggiungimento (totale o parziale) del goal da
parte del Web service. I wgMediator possono utilizzare gli ooMediator
per risolvere problemi di eterogeneità tra i Web service e i goal;

• wwMediators, questi collegano due Web service, che contengono gli oo-
Mediator necessari per superare i problemi di eterogeneità che possono
sorgere nelle situazioni in cui i servizi utilizzano vocabolari differenti.
[Ultima sottomissione al W3C: 3 giugno 2005]
[Stato: W3C Member Submission]
CAPITOLO 3. SEMANTIC WEB SERVICE 54

3.4.3 Web Service Semantic (WSDL-S)


Si tratta di uno standard proposto dal laboratorio LSDIS dell’Università della
Georgia in collaborazione con IBM. Tale standard rappresenta un’estensione
del classico WSDL.
L’attuale standard WSDL opera ad un livello sintattico e manca di espres-
sività semantica, necessaria per rappresentare i requisiti e le capacità dei Web
Service. La semantica può migliorare il riuso ed il ritrovamento del software,
facilitando significativamente la composizione di Web services ed abilitan-
do l’integrazione di applicazioni proprietarie come parte di un più grande
processo di business.
WSDL-S offre un meccanismo per associare annotazioni semantiche ad
un Web service descritto mediante l’uso di un documento WSDL. Nella defi-
nizione del linguaggio è stato assunto che il modello formale di semantica per
il servizio esistesse già. Tali modelli non coinvolgono il documento WSDL
pur essendo referenziati all’interno di questo, utilizzando la possibilità di
estendere gli elementi canonici del documento.
Il tipo di informazione semantica che è utile per la descrizione di un Web
Service comprende i concetti definiti dalla comunità del Semantic Web in
OWL-S ed altri (METEOR-S, WSMO). Le informazioni semantiche specifi-
cate in questo documento includono le definizioni delle precondizioni, input,
output e gli effetti delle operazioni del Web Service.
Questo approccio offre diversi vantaggi rispetto ad OWL-S. Per prima
cosa, gli utenti possono descrivere sia il livello semantico che operazionale,
utilizzando sostanzialmente WSDL, un linguaggio molto noto alla comuni-
tà degli sviluppatori. Esternalizzando il modello della semantica di dominio
ci si approccia agnosticamente al linguaggio di rappresentazione dell’ontolo-
gia: ciò consente agli sviluppatori di annotare i propri Web service sceglien-
do il linguaggio ontologico che più gli soddisfa (come UML oppure OWL)
diversamente da OWL-S.
Questa caratteristica è significativa perché la possibilità di riusare modelli
di dominio già esistenti come UML può alleviare il bisogno di modellare
separatamente la semantica.
CAPITOLO 3. SEMANTIC WEB SERVICE 55

In ultima istanza, diventa relativamente facile aggiornare i vecchi tool


operanti sulle specifiche di WSDL: è sufficiente estenderli con un approccio
incrementale.
[Ultima sottomissione al W3C: 7 novembre 2005]
[Stato: W3C Member Submission]

3.4.4 Semantic Annotation for WSDL and XML Sche-


ma (SAWSDL)
Nasce come evoluzione del precedente WSDL-S ad opera del SAWSDL Wor-
king Group, definendo una estensione del set di attributi di WSDL che con-
sente l’associazione di elementi del documento WSDL al modello semantico
di riferimento.
Semantic Annotations for WSDL and XML Schema (SAWSDL) [20, 28,
41] non specifica un linguaggio per la rappresentazione del modello seman-
tico. Al contrario, fornisce meccanismi grazie ai quali i concetti del modello
semantico, tipicamente definiti all’esterno del documento WSDL, possano
essere referenziati utilizzando i classici documenti WSDL e/o XML Schema.
Si tratta di un linguaggio accettato dal W3C per la sua estrema flessi-
bilità nonché per la sua assenza di vincoli con altri linguaggi: tale standard
è indipendente oltre che da qualsiasi tipo di modello semantico, anche da
qualsiasi tipo di linguaggio di mapping tra documento e modello semantico.
L’intero standard è stato costruito su solo tre attributi opzionali per i
tag previsti dallo standard WSDL 2.0 (compatibile 1.1) e da quello XML
Schema. Gli attributi sono (vedi Figura 3.4.4):

• sawsdl:modelreference, specifica l’associazione tra una componente del


documento WSDL (o XML Schema) e il concetto espresso nel modello
semantico di riferimento;

• sawsdl:liftingschemamapping, specifica il mapping tramite il quale i da-


ti definiti in maniera conforme ad uno schema XML possano essere
trasformarti conformemente al modello semantico di riferimento;
CAPITOLO 3. SEMANTIC WEB SERVICE 56

• sawsdl:loweringschemamapping, specifica il mapping tramite il quale i


dati definiti nel modello semantico possano essere trasformati in dati
XML.

Di seguito si riporta un esempio di documento WSDL annotato semantica-


mente tramite SAWSDL [2]:
CAPITOLO 3. SEMANTIC WEB SERVICE 57

<wsdl:description
targetNamespace="http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order#"
xmlns="http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order#"
xmlns:wsdl="http://www.w3.org/ns/wsdl" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:sawsdl="http://www.w3.org/ns/sawsdl">
<wsdl:types>
<xs:schema targetNamespace="http://www.w3.org/wsdl/order#"
elementFormDefault="qualified">
<xs:element name="OrderRequest"
sawsdl:modelReference="http://www.w3.org/ontology/purchaseorder#OrderRequest"
sawsdl:loweringSchemaMapping="http://www.w3.org/mapping/RDFOnt2Request.xml">
<xs:complexType>
<xs:sequence>
<xs:element name="customerNo" type="xs:integer" />
<xs:element name="orderItem" type="item" minOccurs="1" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="item">
<xs:all>
<xs:element name="UPC" type="xs:string" />
</xs:all>
<xs:attribute name="quantity" type="xs:integer" />
</xs:complexType>
<xs:element name="OrderResponse" type="confirmation" />
<xs:simpleType name="confirmation"
sawsdl:modelReference="http://www.w3.org/ontology/purchaseorder#OrderConfirmation">
<xs:restriction base="xs:string">
<xs:enumeration value="Confirmed" />
<xs:enumeration value="Pending" />
<xs:enumeration value="Rejected" />
</xs:restriction>
</xs:simpleType>
</xs:schema>
</wsdl:types>
<wsdl:interface name="Order"
sawsdl:modelReference="http://example.org/categorization/products/electronics">
<wsdl:operation
name="order" pattern="http://www.w3.org/ns/wsdl/in-out"
sawsdl:modelReference="http://www.w3.org/ontology/purchaseorder#RequestPurchaseOrder">
<wsdl:input element="OrderRequest" />
<wsdl:output element="OrderResponse" />
</wsdl:operation>
</wsdl:interface>

</wsdl:description>

In grassetto sono stati riportati i frammenti di codice necessari all’annota-


zione semantica: il codice non evidenziato rappresenta il documento WSDL
originale (non annotato).
CAPITOLO 3. SEMANTIC WEB SERVICE 58

Figura 3.4.3: Metafora dei puntatori di SAWSDL ai concetti ontologici

Come si evince facilmente dall’esempio, alcuni elementi del documen-


to WSDL sono stati arricchiti dell’attributo sawsdl:modelreference che rap-
presenta semplicemente un collegamento (in formato URI) ad un concetto
presente nel modello semantico (vedi Figura 3.4.3) scelto come riferimento11 .
Ciascuno degli attributi sopra descritti accetta da 0 a più URI per poter
essere avvalorato. Nel caso di URI multipli, questi devono essere divisi da
spazi.
L’attributo modelReference può essere utilizzato con qualsiasi elemen-
to presente all’interno di un documento WSDL o XML Schema, sebbe-
ne lo standard attribuisca un significato solo agli elementi: wsdl:interface,
wsdl:operation, wsdl:fault, xs:element, xs:complexType, xs:simpleType e xs:attribute.
Quando a questo attributo viene associato più di un URI, ognuno di questi
viene applicato alla componente in oggetto senza che vi sia la possibilità di
specificare relazioni logiche tra essi.
11
L’indirizzo esteso è il seguente http://www.w3.org/2002/ws/sawsdl/spec/ontology/purchaseorder
CAPITOLO 3. SEMANTIC WEB SERVICE 59

Gli attributi liftingSchemaMapping e loweringSchemaMapping sono mol-


to utili nelle fasi post-discovery di un servizio web [10].
Ad esempio, quando nel documento sono presenti due dati, nome e co-
gnome, mentre nel modello semantico è disponibile solo il concetto nomina-
tivo è opportuno concatenare i due dati al fine di procedere all’annotazio-
ne semantica: con i due attributi di mapping possiamo definire opportune
trasformazioni da XML a modello semantico (lifting) e viceversa (lowering).
Le attività di schemaMapping (lifting e lowering) possono essere descritte
mediante diversi linguaggi (XSLT, SPARQL, XQuery); SAWSDL non pone
limitazioni nella scelta del linguaggio.
Esistono dei casi nei quali l’attributo modelReference può essere applica-
to a tag presenti a diversi livelli di innestamento. Questo accade sopratutto
nell’annotazione di dati definiti in XML Schema. Il tag xs:element, essen-
do il più esterno (rispetto a xs:complexType, xs:simpleType e xs:element)
, è quello che ha la precedenza su tutti i tag più interni. Parimenti anche
l’attributo modelReference seguirà la stessa regola.
Ad esempio:
...
<xs:element name="orderItem" type="itemType"
sawsdl:liftingSchemaMapping="http://example.org/mapping/OrderItem2Ont.xslt"/>
<xs:complexType name="itemType"
sawsdl:liftingSchemaMapping="http://example.org/mapping/ItemType2Ont.xslt">
<xs:sequence>
<xs:element ref="partDesc" />
</xs:sequence>
<xs:attribute name="ItemID" type="xs:string"/>
</xs:complexType>

...
Nel caso dell’estratto di codice precedente, lo schema utilizzato sarà Or-
derItem2Ont.xslt anziché ItemType2Ont.xslt, malgrado l’innestamen-
to (più profondo) possa trarre in inganno.
Diversamente dalle altre tecnologie disponibili, SAWSDL si limita a for-
nire una interfaccia di comunicazione tra la descrizione sintattica e la de-
scrizione semantica. Il vincolo di compatibilità è espresso unicamente sul
fronte sintattico: è necessario che i Web Service da annotare siano descritti
mediante WSDL.
In particolare, SAWSDL è stato costruito come estensione di WSDL 2.0.
CAPITOLO 3. SEMANTIC WEB SERVICE 60

Figura 3.4.4: Schema di SAWSDL

E’ altresì possibile, mediante opportuni accorgimenti, utilizzare SAWSDL


anche con la precedente versione di WSDL: WSDL 1.1.
Come si evince facilmente dalla Figura 4, SAWSDL offre una base comune
per le diverse sorgenti semantiche: RDF, OWL, RIF, WSML e così via.
[Ultima sottomissione al W3C: 28 agosto 2007]
[Stato: W3C Recommendation]

Figura 3.4.5: Pila estesa dei Web Service


CAPITOLO 3. SEMANTIC WEB SERVICE 61

3.5 Annotazione di REST service


L’operazione di mashup di diversi servizi RESTful ha palesato l’impraticabi-
lità di tale tecnica quando essa coinvolge un grand numero di servizi.
E’ emersa la possibilità di rendere più scalabile tale processo e, allo stesso
modo di quanto successo per i Web Service, anche con i servizi RESTful si è
convenuto di arricchire tali servizi con annotazioni semantiche.
Se per i Web Service esiste uno standard ratificato e supportato dal W3C,
per i servizi REST ancora non ne esiste uno ufficiale. Diverse sono le propo-
ste, anche se in questo caso è ben più arduo collegare semantica rispetto ad
un documento WSDL.

3.5.1 SA-REST
I servizi REST, spesso sono inclusi in pagine web scritte in formato XHTML
[54]. Sebbene WSDL sia stato specificatamente creato per catturare la de-
scrizione dei servizi, XHTML è un linguaggio di contrassegno più ad ampio
raggio sul tramite il quale è possibile aggiungere semantica solo a quegli
elementi di pagina che includono servizi o riferimenti ad essi.
Su questa considerazione sono state gettate le basi per SA-REST [29,
30, 45]. Sviluppato dallo stesso gruppo di lavoro di SAWSDL, SA-REST è
composto da un set di proprietà che si utilizzeranno, non su un documento
WSDL bensì su un documento in formato XHTML.
Di conseguenza SA-REST utilizza RDFa e Gleaning Resource Descrip-
tions from Dialects of Languages (GRDDL) per aggiungere e catturare le
annotazioni semantiche.
SA-REST condivide con SAWSDL l’attributo modelReference che consen-
te l’aggancio ai diversi concetti ontologici. Alla stessa stregua di SAWSDL,
anche SA-REST non vincola a nessun tipo di formalismo per la definizione
dell’ontologia. E’ possibile infatti utilizzare RDF [36] oppure OWL.
Data la natura del tipo di annotazione, più orientata alla struttura del do-
cumento che al collegamento tra i vari oggetti ed il reasoning, gli sviluppatori
potrebbero propendere per l’utilizzo di RDF a scapito di OWL.
CAPITOLO 3. SEMANTIC WEB SERVICE 62

3.5.2 Tecniche di annotazione e linguaggi


In SAWSDL le annotazioni vengono inserite all’interno del documento WSDL
e ciò è ragionevole dal momento che esiste una relazione 1 ad 1 tra il servizio
web ed il suo documento WSDL.
La maggior parte dei servizi RESTful sono privi di documenti WSDL
correlati. La maggior parte di essi è presentata attraverso un documento
XHTML che descrive agli utenti le modalità d’invocazione. In qualche ma-
niera il corrispettivo di WSDL per i Web Service è rappresentato da XHTML
per servizi REST (l’analogia è molto lasca).
Il problema dell’XHTML è che questi messaggi vengono scritti perlopiù in
linguaggio naturale: comprensibili agli utenti ma incomprensibili alle mac-
chine. Per aggiungere semantica anche alle pagine web classiche (formato
XHTML) è possibile utilizzare i micro formati.
Tramite i micro formati, i programmi possono integrare i dati semanti-
ci in una pagina web. I micro formati permettono infatti di creare codice
XHTML leggibile dai programmi (come per i dati in formato XML o RDF)
ma continuando a garantire un’elevata comprensibilità da parte delle persone.
In altre parole, le pagine web create sfruttando i micro formati permettono
ai programmi di esaminarne i dati e di utilizzare le informazioni ivi contenute.
Ad esempio, attraverso il micro formato hCard, specifico per la descri-
zione delle persone, il browser può facilmente riconoscere, all’interno di una
pagina web, l’indirizzo e-mail o il numero di telefono dei contatti presenti
nella pagina, in modo da poterle trasferire velocemente nella rubrica.
Ritornando ai servizi REST, le due tecnologie di riferimento per SA-REST
sono RDFa e GRDDL.

3.5.2.1 RDFa

RDFa [7] è un linguaggio estendibile che consente di includere triple RDF al-
l’interno di documenti XML, HTML o XHTML ed è un sotto-insieme di RDF.
RDFa è uno strumento che arricchisce [6] la sintassi di XHTML attraverso
una serie di attributi aggiuntivi (rev, about, typeof, content, property) [8] che
associati ai tag già noti, simulano le triple soggetto–predicato–oggetto tipi-
CAPITOLO 3. SEMANTIC WEB SERVICE 63

che di RDF. In questo modo, lo sviluppatore invece di produrre file RDF per
esprimere concetti semantici, potrà usare direttamente le pagine XHTML.
Il vantaggio di RDFa è che, a partire dalla pagina annotata, è facile pro-
durre triple in formato RDF. Allo scopo è possibile utilizzare gratuitamente
RDFa Distiller & Parser direttamente online sul sito del W3C.
Di seguito un esempio di documento annotato con SA-REST:

<html xmlns:sarest=”http://lsdis.cs.uga.edu/SAREST#”>
...
<p about=”http://craigslist.org/search/”>
The logical input of this service is an
<span property=”sarest:input”>http://lsdis.cs.uga.edu/ont.owl#Location_Query</span> object.
The logical output of this service is a list of
<span property=”sarest:output”>http://lsdis.cs.uga.edu/ont.owl#Location</span> objects.
This service should be invoked using an <span property=”sarest:action”>HTTP GET</span>
<meta property=”sarest:lifting” content=“http://craigslist.org/api/lifting.xsl”/>
<meta property=”sarest:lowering” content=“http://craigslist.org/api/lowering.xsl”/>
<meta property=”sarest:operation” content=“http://lsdis.cs.uga.edu/ont.owl#Location_Search”/>
</p>

...

3.5.2.2 GRDDL

GRDDL [44], da poco W3C Recommendation, offre una modalità univoca


per l’estrazione di classi semantiche da documenti (X)HTML per qualsiasi
tipo di micro-formato scelto.
Trasformare le annotazioni con il GRDDL associato in RDF è più com-
plicato rispetto ad RDFa. Per annotare un documento leggibile con GRDDL
è necessario inserire nel tag <head> un attributo profile necessario per indi-
care che la pagina web è annotata con GRDDL. Il passo successivo è inserire
all’interno del tag <head> il collegamento alla pagina di trasformazione.
GRDDL è più flessibile (si può allacciare a qualsiasi tipo di microformati)
e meno invasivo rispetto ad RDFa, pur obbligando lo sviluppatore a generare
e manutenere due pagine: quella XHTML e quella di trasformazione.

3.5.3 Stato
SA-REST è un linguaggio nato dalla tesi di dottorato di Jonhatan Lathem
presso la University of Georgia.
CAPITOLO 3. SEMANTIC WEB SERVICE 64

Figura 3.5.1: Comparazione del numero di pubblicazioni scientifiche per


SAWSDL e SA-REST

La definizione e la successiva sottomissione di tale linguaggio al W3C era


il secondo deliverable di un’attività W3C Incubator dell’anno 2008.
Ad oggi, oltre che un esiguo numero di pubblicazioni scientifiche attinen-
ti (vedi Figura 3.5.1), tale linguaggio non è ancora giunto ad un livello di
maturità tale da poter essere sottomesso all’ente di ratifica (vedi Figura ).
Non è difficile prevedere in futuro la realizzazione di una piattaforma
unica per l’annotazione di servizi sia REST che SAWSDL [33].
CAPITOLO 3. SEMANTIC WEB SERVICE 65

Figura 3.5.2: Comparazione delle caratteristiche salienti di SAWSDL e SA-


REST
Capitolo 4

SWOP Project

Il progetto regionale SWOP (Semantic Web Service Oriented Platform) per-


segue due obiettivi fondamentali.
In primo luogo intende estendere l’attuale piattaforma proprietaria di svi-
luppo di applicazioni di classe enterprise, denominata CA Enterprise Solu-
tion Platform, verso un modello di architettura service-oriented introducendo
meccanismi per la creazione e gestione di web service.
In secondo luogo intende abilitare la medesima piattaforma all’annotazio-
ne semantica di tali web service così da rendere possibile l’automazione delle
operazioni chiave di discovery, selection, composition e invocation. Questo
secondo obiettivo, punto focale dell’innovatività del progetto, permetterà di
integrare all’interno di una piattaforma di sviluppo classica, com’è quella in
esame, nuove funzionalità derivanti dall’integrazione di metodologie che com-
binano i campi di ricerca del Semantic Web e del Natural Language Processing
(NLP).
SWOP è un progetto di ricerca industriale con un programma di svilup-
po sperimentale che si concentra sulla realizzazione di due output di tipo
software, i quali, unitamente a guide operative e metodologie di approc-
cio organizzativo, costituiranno il presupposto per avviare un processo di
industrializzazione e sfruttamento dei risultati di ricerca.
Il primo output consiste in una componente software per l’annotazione
semantica semi-automatica dei web service da integrare nella piattaforma CA

66
CAPITOLO 4. SWOP PROJECT 67

Enterprise Solution Platform.


Il secondo consiste in un dimostratore per almeno una delle tecniche in-
dividuate di discovery, selection, composition e invocation di web service su
base semantica.
Il processo di sviluppo che sarà adottato nel progetto risponde ad obiet-
tivi primari di time-to-market, controllo del rischio e visibilità degli stati di
avanzamento e può essere riassunto nella seguente caratteristica di fondo: un
approccio iterativo e incrementale guidato dai casi d’uso.
Sulla base di tale approccio, il processo di sviluppo si articolerà in una
serie di iterazioni, che hanno lo scopo di ridurre progressivamente i rischi di
fallimento del progetto, a partire da quelli principali (ad es. incomprensioni
sui requisiti e/o incertezze sull’architettura). In ogni iterazione si ripetono,
in misura e percentuali diverse, le medesime tipologie di attività (analisi,
disegno, implementazione e test).
La scelta di progetto è coprire sin dalla prima iterazione, in termini di
analisi, la quasi totalità dei requisiti, per poi completarli progressivamente
durante le successive iterazioni. I diversi requisiti verranno pertanto soddi-
sfatti in modo incrementale: saranno soddisfatti tutti e sin dal principio in
termini di analisi e soltanto successivamente anche in termini di disegno e
implementazione.
La realizzazione e il rilascio degli output avverrà in modo progressivo.
La pianificazione sarà guidata dai casi d’uso e il risultato di ogni itera-
zione sarà una release eseguibile. La definizione dei casi d’uso del sistema
guiderà tutte le attività del processo di sviluppo. In particolare i casi d’uso
costituiranno la base per la definizione dei requisiti e la loro validazione, la
definizione dei test di accettazione e la pianificazione dei rilasci in un’ottica
incrementale.
Sulla base dell’approccio appena descritto, si stabilisce che per entrambi
gli output di tipo software previsti dal progetto, l’obiettivo quantitativo da
conseguire è rappresentato dalla copertura di almeno l’80% dei casi d’uso
individuati in fase di analisi e del 100% dei corrispondenti requisiti, laddove
previsti.
In relazione ai due obiettivi che si intendono perseguire, riconducibili
CAPITOLO 4. SWOP PROJECT 68

entrambi all’integrazione di funzionalità di annotazione semantica dei web


service nella piattaforma che è alla base del progetto, la difficoltà maggiore
non dipende tanto dall’integrazione di tali funzionalità quanto dal renderle
effettivamente utilizzabili agli sviluppatori.
Le annotazioni semantiche sono rappresentate utilizzando formalismi di
programmazione logica basate su un paradigma completamente differente da
quello dei classici linguaggi di programmazione. Un esempio è la definizione
di una semplice classe utilizzando i due paradigmi. Una classe in un linguag-
gio Object Oriented rappresenta l’astrazione di un oggetto e viene definita
scrivendo un’istruzione del tipo:

public class Man extends Person{...}

Una classe in un linguaggio logico atto alla rappresentazione delle annota-


zioni semantiche equivale alla definizione di un concetto creato scrivendo un
assioma del tipo:

Man ≡ Person u pWoman

Questo semplice esempio mostra che nella pratica l’utilizzo di un linguag-


gio logico da parte di uno sviluppatore, sia pure esperto, sarebbe alquanto
complicata, se non impossibile. Per questa ragione il trend verso cui si sta
muovendo la comunità di ricerca è lo studio di metodologie che consenta-
no la creazione semi-automatica di annotazioni semantiche partendo dalla
processazione del linguaggio naturale (NLP).
Nel progetto in questione, lo scenario in cui queste attività di ricerca
prendono forma può essere riassunto come segue:

Lo sviluppatore crea un web service con la piattaforma CA Enter-


prise Solution Platform SDK descrivendone in linguaggio naturale
parametri e funzione. Egli attiva la funzionalità “annota”, che in-
tegra tecniche di NLP, che genera annotazioni semantiche scritte
in un linguaggio compliant al Semantic Web sfruttando ontologie
già esistenti. Tali annotazioni potranno essere riutilizzate per la
realizzazione di funzionalità complesse (quali l’automazione del
CAPITOLO 4. SWOP PROJECT 69

discovery, selection, composition ed invocation di web service) di


supporto alla creazione di nuovi servizi all’interno o all’esterno
della piattaforma stessa.
La risoluzione del problema dell’automazione di queste funzionalità è vitale
affinché si possano sfruttare pienamente i vantaggi offerti dall’architettura
SOA (Service Oriented Architecture).
Ad oggi, infatti, un utente che volesse utilizzare i web service è tenuto
a conoscere esattamente dove si trovano, selezionare manualmente quelli che
soddisfano le sue esigenze, comporre manualmente e, infine, gestire i pro-
blemi legati all’invocazione (accordi sui protocolli di trasporto dei messaggi,
tipologia dei dati, ecc.). Tipicamente tutte queste problematiche circoscri-
vono l’utilizzo delle tecnologie correlate ai web service ai soli casi in cui
è necessario combinare applicazioni legacy scritte utilizzando linguaggi di
programmazione differenti.
In questi casi lo sviluppatore esperto espone le interfacce necessarie e
collega le due applicazioni conoscendo a priori tutte le caratteristiche del-
le applicazioni in questione e dei servizi da esse generati. Anche se questa
facilitazione per l’integrazione di applicazioni esistenti è un vantaggio non
indifferente, questo rappresenta una minima parte delle potenzialità dell’ar-
chitettura SOA. Il principio generale è quello di costruire applicazioni che
possano essere utilizzate via Web sfruttando un’interfaccia standard aperta
a qualsiasi soluzione applicativa.
Per realizzare pienamente questa vision è necessario introdurre un li-
vello astratto che specifichi il significato, ovvero la semantica, delle feature
dei servizi in modo tale da attenuare in modo progressivo le problematiche
esposte.
I Semantic Web Service (SWS) si propongono come strumenti atti alla
rappresentazione di questo livello astratto specificando le modalità con cui è
possibile realizzare infrastrutture in grado di abilitare a pieno l’architettura
service- oriented.
A tal proposito sono stati individuati un insieme di casi d’uso che prevedo-
no l’automazione graduale delle operazioni chiave, quali ad esempio discovery,
selection, composition e invocation.
CAPITOLO 4. SWOP PROJECT 70

Figura 4.1.1: Architettura del progetto SWOP

Avere a disposizione strumenti automatici in grado di indicare dove sono


i servizi, quale di questi è più consono ai nostri fabbisogni, le composizio-
ni possibili per raggiungere i nostri obiettivi e la rilevazione di eventuali
problematiche inerenti la loro concreta invocazione consente allo sviluppato-
re indubbi vantaggi in termini di tempo e conseguenti vantaggi in termini di
spesa per le aziende. In quest’ottica il progetto si propone di creare strumenti
per la creazione semi- automatica di SWS abilitanti i relativi casi d’uso.

4.1 Architettura generale


Nell’ottica della realizzazione di uno strumento funzionale alla fase di an-
notazione, è stata studiata una soluzione architetturale che possa esprime-
re i vari moduli software coinvolti nello sviluppo dell’infrastruttura (vedi
Figura 4.1.1).
Il servizio UDDI dialoga con l’infrastruttura completa al fine di poter
esporre e pubblicizzare opportunamente i diversi servizi annotati.
CAPITOLO 4. SWOP PROJECT 71

L’infrastruttura deve contenere una serie di API per l’interazione con i


diversi standard coinvolti. In questo caso di tratta di un esempio che prende
in considerazione il linguaggio Java e lo standard SAWSDL per annotare
semanticamente i servizi web. Sotto tali ipotesi, le API necessarie sono state
identificate in:

• UDDI4J : Si tratta di una libreria scritta in Java che espone le primiti-


ve per l’interazione con lo standard UDDI. Tramite questo strumento
è possibile in modo facile e veloce interagire con UDDI direttamente
tramite linguaggio di programmazione;

• WSDL4J : Come per UDDI4J, anche WSDL4J è una libreria di primi-


tive in ambiente Java che facilitano la gestione di documenti WSDL.
Lo strumento mette a disposizione funzionalità specifiche per tali do-
cumenti, consentendo allo sviluppatore di concentrare i propri sforzi
sui contenuti piuttosto che sulla struttura del documento WSDL. Tale
modulo è integrato automaticamente in SAWSDL4J;

• SAWSDL4J : vedi 3.3.1.2 nella pagina 43.

Oltre ai due moduli (poiché WSDL4J è integrato in SAWSDL4J) precedenti


è indispensabile la presenza di un ragionatore che consenta di interpretare le
query degli sviluppatori. Il ragionatore scelto per l’architettura proposta è
Pellet, disponibile gratuitamente sul proprio sito web ufficiale1 .
L’ultimo strumento trasversale indispensabile all’infrastruttura è un tool
di elaborazione del linguaggio naturale. In tal caso è stato appositamente
realizzato SAWA: un tool da me sviluppato all’interno dello SWAP Research
Group del Dipartimento di Informatica di Bari.
I quattro moduli sopra descritti vengono utilizzati dai due servizi princi-
pali dell’infrastruttura:

• Annotation Service: strumento con interfaccia grafica necessario all’e-


licitazione delle associazioni semantiche tra componenti del file WSDL
e concetti semantici contenuti all’interno di ontologie di dominio;
1
http://clarkparsia.com/pellet
CAPITOLO 4. SWOP PROJECT 72

Figura 4.2.1: Flusso di lavoro del modulo di annotazione

• Discovery Service: strumento con interfaccia grafica necessario alla for-


mulazione di query complesse da sottoporre al sistema per ottenere una
lista di servizi semanticamente rilevanti rispetto alla query.

L’intera infrastruttura dialogherà con un insieme di ontologie al fine di di-


sambiguare il testo descrittivo inserito dagli sviluppatori/annotatori ed ar-
ricchire semanticamente i servizi web sintatticamente descritti dai rispettivi
documenti WSDL. Si tratterà quindi di disporre di ontologie di dominio
(indispensabili per i concetti propri del business aziendale) e di ontologie les-
sicali (indispensabili per comprendere la lingua con la quale si inseriscono le
descrizioni testuali).

4.2 Annotazione semantica di Web Service


La fase di annotazione semantica prevede un file WSDL in ingresso e la
corrispondente produzione di un file SAWSDL. Tale fase è stata organizzata
tenendo ben presente l’intervento umano dello sviluppatore, il quale, oltre ad
utilizzare l’interfaccia, si riserva la possibilità di indicare quali componenti
del servizio web annotare e soprattutto quali suggerimenti circa l’annotazione
accettare e quali no.
Il modulo di annotazione viene utilizzato dagli sviluppatori presenti al-
CAPITOLO 4. SWOP PROJECT 73

l’interno delle aziende clienti di CODEArchitects ed il loro scopo è quello di


esporre dei servizi attraverso gli appositi e consolidati ambienti di sviluppo.
Al termine della fase di deploy di un classico servizio web, gli sviluppatori
hanno ora la possibilità di utilizzare il modulo di annotazione al fine di arric-
chire il servizio web appena condiviso di annotazioni semantiche attraverso
l’uso dello standard SAWSDL.
Lo standard prevede l’inserimento, per ciascun elemento presente all’in-
terno della definizione del servizio, di uno o più puntatori a classi presenti
all’interno di una ontologia di dominio disponibile attraverso un indirizzo
URL. Detto ciò, la fase di annotazione, e di produzione del file SAWSDL, si
riduce alla ricerca delle classi ontologiche pertinenti.
L’ontologia di dominio (vedi 4.2.2 nella pagina 77) contiene un insieme di
classi che esprimono i concetti pertinenti al dominio applicativo proprio del
contesto nel quale vengono utilizzati i servizi web. Ogni classe è provvista
di una opportuna descrizione, scritta in linguaggio naturale (inglese), che ne
illustra il suo significato.
L’algoritmo di suggerimento delle annotazioni semantiche, SAWA, non fa
altro che calcolare la similiratà tra le due descrizioni:

1. descrizione in lingua inglese inserita dallo sviluppatore all’avvio del tool


di annotazione;

2. descrizione in lingua inglese presente per ogni classe all’interno dell’on-


tologia di dominio.

La similarità di un elemento viene calcolata per tutte le classi ontologiche


presenti nell’ontologia[22]. Tale computazione produce una lista di classi
(vedi Figura 4.2.2 nella pagina seguente) ordinabile in funzione del punteggio
di similarità semantica calcolato. Così facendo, in accordo ad una politica di
filtraggio, vengono restituiti i risultati con più alto punteggio di similarità.

4.2.1 Interfaccia utente


Nella fase iniziale del progetto era necessario chiarire le modalità d’inte-
razione dell’utente al fine di operare una dicotomia architetturale tra le
CAPITOLO 4. SWOP PROJECT 74

Figura 4.2.2: Lista ordinata di classi ontologiche semanticamente simili


CAPITOLO 4. SWOP PROJECT 75

Figura 4.2.3: Mockup GUI di CODEArchitects Annotation Tool

competenze di sviluppo dell’azienda partner e quelle del gruppo di ricerca.


Utilizzando un apposito tool, ForeUI2 , sono stati realizzati dei mockup
[vedi Figure 4.2.3, 4.2.4, 4.2.5] che sintetizzano le funzionalità del tool di
annotazione, CODEArchitects Annotation Tool, e chiariscono la sequenza
operativa del software.
Sulla scorta dei mockup iniziali, l’azienda partner ha provveduto a realiz-
zare un’interfaccia software in ambiente Microsoft Presentation Foundation
che dialogasse con il modulo di annotazione via web. L’interfaccia grafica
realizzata ha quindi le seguenti funzionalità:

• caricare un file WSDL 1.1 o 2.0 ed inviare una richiesta al modulo di


annotazione remoto;
2
http://www.foreui.com/
CAPITOLO 4. SWOP PROJECT 76

Figura 4.2.4: Mockup GUI di elaborazione CODEArchitects Annotation Tool

Figura 4.2.5: Mockup GUI risultati di CODEArchitects Annotation Tool


CAPITOLO 4. SWOP PROJECT 77

• selezionare ogni elemento del file WSDL ed annotarlo con delle frasi
espresse in linguaggio naturale;

• visualizzare le annotazioni suggerite dal modulo di annotazione remoto;

• accettare, modificare o rifiutare le annotazioni suggerite automatica-


mente;

• esplorare l’ontologia di dominio in accordo con i vincoli di restrizione.

4.2.2 Ontologia di dominio


Il progetto SWOP mira alla creazione di una piattaforma aperta per la ge-
stione di servizi web semantici. Al fine di realizzare un prototipo dell’intero
sistema, su consiglio dell’azienda partner, si è deciso di lavorare su un caso
di studio reale.
Il caso di studio riguarda un’azienda che vende prodotti e servizi uti-
lizzando a questo scopo dei web service. Il dominio da modellare è quello
commerciale: prodotti, servizi, fatture, mercato, clienti, anagrafiche.
Tale scelta è giustificata dal fatto che vi sono alcune componenti impre-
scindibilmente dipendenti dal dominio applicativo. Una di queste è proprio
l’ontologia.
Una ontologia formalizza la conoscenza di un intero dominio in maniera
che sia comprensibile alla macchina. L’ontologia utilizzata all’interno di que-
sto progetto, relativamente al caso di studio concordato, è stata realizzata
appositamente from-scratch.
La base di conoscenza generale è suddivisa in ben 6 ontologie specifiche
ad un ambito di competenza ben definito. Pertanto, la base di conoscenza si
compone di:

1. Categories: contiene un’ampia tassonomia di categorie commerciali


relative a prodotti e servizi;

2. Business Processes: contiene la classificazione delle funzionalità per le


attività specifiche del dominio applicativo;
CAPITOLO 4. SWOP PROJECT 78

3. Business Object: contiene i concetti del dominio inerenti l’input e


l’output dei servizi web;

4. Services: fornisce i concetti utili a modellare i web service;

5. SWOP Integration: importa tutte le ontologie precedenti stabilendo le


diverse relazioni tra classi;

6. SWOP : estende l’ontologia precedente con la definizione dei web service


propri del caso d’uso concordato.

L’ontologia in esame non contiene individui ma solo classi, utilizzando gli


assiomi per compensare il potere descrittivo offerto tipicamente dalla dichia-
razione di individui.
Capitolo 5

L’algoritmo SAWA

Figura 5.0.1: Logo di SAWA

5.1 Similarità
Calcolare la similarità tra due entità generiche significa individuare una mi-
sura comune ad entrambe che sia di interesse per stabilire quanto la prima
entità sia uguale alla seconda.
Più formalmente [18], sia E un insieme di possibili entità che abbiano
caratteristiche comuni, allora è possibile definire la funzione

sim : E × E → [0, 1]

che ad ogni coppia di elementi e1 , e2 ∈ E associa un numero reale com-


preso tra 0 ed 1. Tale valore è noto con il nome di Coefficiente di similarità.

79
CAPITOLO 5. L’ALGORITMO SAWA 80

Una funzione di similarità, per poter essere tale, deve necessariamente


verificare le seguenti tre proprietà:

1. f (a, b) ≥ 0, ∀a, b ∈ E (positività)

2. f (a, b) = f (b, a), ∀a, b ∈ E (simmetria)

3. f (a, b) ≤ f (a, a), ∀a, b ∈ E

Per convezione si suole attribuire il valore massimo di similarità ad una coppia


formata da due entità uguali. In tal caso vale:

f (a, a) = 1, ∀a ∈ E.

5.1.1 Similarity vs. Relatedness


Nella letteratura scientifica molto spesso si confonde la misura di similarità
con quella di relazione.
Se la misura di similarità trova il suo massimo valore nella stato di ugua-
glianza, la misura di relatedness ha lo scopo di misurare quanto due entità
siano in relazione tra loro. Pur osservando le medesime proprietà algebriche
della funzione di similarità, si tratta di una misura semanticamente molto
diversa.
Facciamo un esempio. L’entità cane e l’entità gatto sono sicuramente due
entità molto in relazione tra loro poiché, ad esempio, si tratta di due animali,
due mammiferi, entrambi domestici sebbene non si possa certo affermare che
si tratti di entità simili: un gatto non è un cane.
SAWA, è un algoritmo che misura la similarità sul piano semantico tra
due testi espressi in lingua inglese. Sicché esso non misura il loro grado di
relazione.

5.1.2 Similarità semantica


Introdotta la definizione formale di similarità e chiarita la differenza con la
relazione è opportuno definire cosa si intenda per similarità semantica.
CAPITOLO 5. L’ALGORITMO SAWA 81

La similarità è una funzione che genera un dato numerico a partire da


due entità complesse a piacere. Per calcolare il coefficiente di similarità è
quindi necessario disporre di una metrica di similarità, laddove per metrica
si intende

“la legge che dà la distanza tra due punti qualsiasi di uno


spazio matematico”.

Una metrica riflette l’insieme delle caratteristiche di una entità che sono im-
portanti al fine del calcolo della sua distanza [11] da un altra entità. Per tale
ragione esistono diverse metriche di similarità ognuna delle quali privilegia
alcuni aspetti piuttosto che altri.
Posto, ad esempio, che si voglia calcolare la similarità tra due vettori
geometrici, esistono inevitabilmente differenti metriche ognuna delle quali
predilige il controllo di certi aspetti piuttosto che di altri:

1. lunghezza del vettore;

2. punto di applicazione del vettore;

3. angolo del vettore;

4. lunghezza delle proiezioni del vettore.

SAWA opera con testi scritti in lingua inglese, perciò il contesto è quello del
linguaggio naturale.
La similarità tra due parole può essere calcolata confrontando i singoli
caratteri che compongono la parola oppure confrontando il senso concettuale
che esprime la parola.
Nel primo caso, ad esempio, le parole “nano” e “nona” sarebbero molto
simili, sebbene nel secondo caso non lo sarebbero affatto dal momento che
semanticamente si riferiscono a due concetti molto diversi: “persona di bassa
statura” e “numero cardinale”.
SAWA utilizza una metrica di similarità basata sul piano semantico.
CAPITOLO 5. L’ALGORITMO SAWA 82

5.1.2.1 Similarità tra parole

In letteratura esistono differenti algoritmi per il calcolo della similarità se-


mantica tra due parole. Si tratta di un filone di ricerca relativamente vecchio
e per questa ragione i contributi sono molto numerosi.
Sostanzialmente le misure di similarità si dividono in due grandi categorie:

• misure basate su corpus (Corpus-based measures);

• misure basate su conoscenza (Knowledge-based measures).

Le misure appartenenti alla prima categoria analizzano dei corpus (insiemi


di documenti molto grandi), di solito opportunamente annotati, al fine di
ricavare dei modelli che misurino il peso di ciascuna parola all’interno del
corpus.
In letteratura sono note due tecniche di misurazione facenti parte di
questa categoria: Pointwise Mutual Information e Latent Semantic Analysis.
Si tratta di tecniche efficienti computazionalmente parlando ma che regi-
strano risultati mediamente meno accurati delle misure basate su conoscenza.
Queste ultime, invece, si basano sull’utilizzo di dizionari, tesauri o più in
generale tassonomie che aiutano ad individuare la corretta rete di relazioni
semantiche che collega tutte le parole di una lingua.
Tali tassonomie vengono realizzate da linguisti professionisti e, oltre a
contenere le definizioni dei vocaboli, contengono anche informazioni che aiu-
tano a risolvere i problemi di polisemia e sinonimia tipici dell’elaborazione
del linguaggio naturale.
Per ogni vocabolo, ad esempio, è disponibile la lista di tutti i tipi gram-
maticali (nome, verbo, aggettivo, avverbio) ad esso associabili, unitamente
all’elenco di tutti i sensi ad esso associabili. Questa conoscenza linguistica è
resa in una forma machine-processable ed è di grande utilità nello sviluppo
di algoritmi di elaborazione del linguaggio naturale.
Una delle tassonomie linguistiche più importanti e vaste per la lingua
inglese, e non solo, è Wordnet1 .
1
http://wordnetweb.princeton.edu/
CAPITOLO 5. L’ALGORITMO SAWA 83

Le più importanti misure di similarità basate su conoscenza [16, 17]


prendono i nomi degli scienziati che primi le hanno formalizzate e sono:
Leacock&Chodorow, Lesk, Wu&Palmer, Lin, Resnik e Jiang&Conrath.

Leacock & Chodorow Inventata nel 1998, questa misura di similarità


viene calcolata nel seguente modo:

lenght
Simlch = −log( )
2∗D
dove lenght è la lunghezza del cammino più breve tra i due concetti calco-
lata utilizzando il conteggio dei nodi e D è la massima profondità dell’intera
tassonomia.

Lesk Inventata nel 1986, misura la sovrapposizione (overlap) tra le de-


finizioni dei due concetti espresse attraverso un dizionario. E’ basata su
un algoritmo inventato da Lesk e proposto per risolvere il problema della
disambiguazione dei sensi associati ad una parola.

Wu & Palmer La misura di similarità di Wu & Palmer, introdotta nel


1994, misura la profondità dei due concetti all’intero della tassonomia di
WordNet e la profondità del concetto genitore comune più vicino (Least
Common Subsumer ) combinandoli nel seguente modo:

2 ∗ depth(LCS)
Simwup =
depth(concept1 ) + depth(concept2 )

Resnik La misura di similarità di Resnik, introdotta nel 1995, calcola


l’information content del genitore comune più vicino (LCS) tra i due concetti:

Simres = IC(LCS)

dove l’information content è definito in base alla probabilità di incontrare


il concetto all’interno del corpus di riferimento:

IC(concept) = −log P (concept)


CAPITOLO 5. L’ALGORITMO SAWA 84

Lin La misura di Lin [1], introdotta nel 1998, è costruita a partire da quella
di Resnik aggiungendo un fattore di normalizzazione che consiste nel calcolo
dell’information content dei due concetti presi singolarmente. La formula è
la seguente:

2 ∗ IC(LCS)
Simlin =
IC(concept1 ) + IC(concept2 )

Jiang & Conrath La misura di Jiang & Conrath, enunciata nel 1997, è
calcolata nel seguente modo:

1
Simjnc =
IC(concept1 ) + IC(concept2 ) − 2 ∗ IC(LCS)

5.1.2.2 Dalla similarità tra parole alla similarità tra testi

Gli algoritmi esaminati nella sezione precedente misurano la similarità tra


parole. In altri termini restituiscono un valore compreso tra 0 e 1 prendendo
in input due singole parole.
Per passare dalla word-to-word similarity alla text-to-text similarity esi-
stono diversi modi. Dati due testi, è necessario derivare automaticamente
uno score che indichi la loro similarità a livello semantico, andando oltre i
metodi tradizionali di string-matching.
Sebbene una metrica di misurazione ideale non possa prescindere dal rico-
noscere il ruolo che le relazioni tra le parole giocano nel calcolo della similarità
semantica, l’approccio è quello di ignorare tale considerazione ed esprimere
la similarità tra testi come estensione di quella tra parole.
L’algoritmo utilizzato da SAWA è stato proposto da [16] e consente di
ottenere ottimi risultati in termini di peso computazionale ma anche di
performance operative.
Si introduce una funzione di similarità direzionale (asimmetrica) che mi-
sura la similarità del testo Ti rispetto al testo Tj . Tale definizione è utile nei
casi in cui siano richieste misure di similarità asimmetriche, laddove cioè:

sim(Ti , Tj ) 6= sim(Tj , Ti ).
CAPITOLO 5. L’ALGORITMO SAWA 85

Per ciascuno dei due testi di cui si vuole calcolare il coefficiente di similari-
tà si procede alla loro riduzione a insiemi di parole. Nell’attività di riduzione
vengono rimosse le cosiddette stop-word (punteggiatura, articoli, verbi comu-
ni, numeri) lasciando solo nomi, verbi, avverbi e aggettivi. L’informazione
sul tipo grammaticale di ogni parola viene conservata.
Fatto ciò, si procede a seconda del tipo grammaticale alla ricerca della
parola più simile all’interno del testo da confrontare. Dopo aver trovato,
per ogni tipo grammaticale, la contro-parola più simile si moltiplica la sua
similarità (word-to-word similarity) con la frequenza della parola all’interno
del corpus di riferimento. Tale procedimento viene eseguito per ogni tipo
grammaticale e per ogni parola presente. Il tutto viene ponderato in base
alla frequenza totale delle parole presenti nel documento di riferimento ai fini
del calcolo della similarità.
La rappresentazione formale è la seguente:
P P
( (maxSim(wk ) ∗ idfwk ))
pos w ∈{T
k ipos }
sim(Ti , Tj )Ti = P
idfwk
wk ∈{Tipos }

Questa formulazione, che garantisce un risultato compreso tra 0 ed 1,


è una misura di similarità asimmetrica, in questo caso calcolata rispetto al
testo Ti . Per rendere simmetrica tale formulazione è sufficiente calcolare la
media aritmetica delle similarità rispetto ad entrambi i testi Ti e Tj , nel
seguente modo:

sim(Ti , Tj )Ti + sim(Ti , Tj )Tj


sim(Ti , Tj ) = .
2

5.2 SAWA
SAWA, Similarity Algorithm based on WikipediA, è un algoritmo per il cal-
colo della similarità semantica tra testi [50] e come tale osserva le proprietà
formali enunciate precedentemente (vedi 5.1 nella pagina 79). Di conseguen-
CAPITOLO 5. L’ALGORITMO SAWA 86

za, analizzando due testi restituisce un coefficiente di similarità compreso tra


0 ed 1.
L’algoritmo è definito utilizzando una metrica di similarità tra parole
introdotta da Lin e viene impiegato per suggerire le classi ontologiche che più
sono simili alla descrizione in linguaggio naturale fornita dagli sviluppatori
per ciascun elemento da annotare.
SAWA elabora in input la descrizione di ciascuna classe con la descrizione
di ciascun elemento del file WSDL che si desidera annotare. L’algoritmo pro-
duce, in corrispondenza di ogni coppia classe-elementoWSDL, un coefficiente
di similarità semantica che viene utilizzato per ordinare i risultati.
Agli utenti utilizzatori del Tool di annotazione verranno proposti gli ele-
menti che sono risultati più simili. La politica tramite la quale selezionare le
coppie più promettenti è tuttora al vaglio. Sono possibili diverse soluzioni:
1. restituire le prime N classi;

2. restituire le classi più simili fino a quando non si individua una netta
dicotomia negli score;

3. restituire le prime classi che superano una soglia pre-impostata.

5.2.1 DISCO
Per il calcolo del coefficiente di similarità tra parole è stata utilizzata una
libreria open-source realizzata da LinguaTools: DISCO.
Essa implementa l’algoritmo di Lin su corpus appositamente indicizzati
per mezzo di Lucene e mette a disposizione due sole funzionalità:
1. restituzione del coefficiente di similarità tra due parole;

2. restituzione della frequenza di un termine all’interno del corpus.

5.2.2 Corpus
Sono disponibili corpus ad-hoc in diverse lingue: inglese, tedesco, francese,
italiano e spagnolo. Relativamente alla lingua inglese, lingua di interesse per
il progetto SWOP, sono disponibili tre corpus differenti:
CAPITOLO 5. L’ALGORITMO SAWA 87

1. Pub Med: si tratta di un corpus, aggiornato al 1 maggio 2007, contenen-


te più di 100.000 pubblicazioni scientifiche nel campo della medicina.
La dimensione totale dell’indice è di 905Mb.

2. BNC (British National Corpus): si tratta di un corpus, aggiornato al


7 luglio 2008, contenente 100 milioni di parole estratte da documenti
scritti o trascrizioni di lingua parlata. La dimensione totale dell’indice
è di 1,82Gb.

3. Wikipedia: si tratta della celebre enciclopedia libera in lingua inglese


in una versione risalente al 1 gennaio 2008 e contenente tutti i concetti
presenti online all’epoca. La dimensione totale dell’indice è di ben
6,25Gb.

Al fine di scegliere il corpus più adatto, è stato effettuato un test statisti-


co utilizzando ogni corpus e misurando le performance registrate rispetto
ai punteggi calcolati da uno studio che ha coinvolto soggetti umani nella
misurazione della similarità tra parole (WordSim3532 ).
La misurazione del coefficiente di correlazione campionaria dei 3 corpus,
a parità di algoritmo, ha visto prevalere la bontà di Wikipedia con uno score
pari a 0, 5602. Per tale ragione, all’interno del progetto SWOP, è stato scelto
il corpus Wikipedia.
Il risultato del test è giustificato dalla natura estremamente specifica del
corpus Pub Med e da quella troppo poco folksonomica del corpus BNC, oltre
che dalla scarsa dimensione di entrambi rispetto a quella di Wikipedia.
E’ opportuno precisare che vengono messi a disposizione degli utenti solo
gli indici Lucene dei vari corpus. In altri termini non si ha accesso ai dati dei
corpus ma soltanto agli score di similarità e alle frequenze dei termini. Tali
informazioni sono state precedentemente calcolate e raccolte sotto forma di
indice.
Qualora si desiderasse modificare anche solo la versione di Wikipedia, ad
esempio con una più aggiornata, è necessario richiederla ai responsabili del
progetto DISCO.
2
http://www.cs.technion.ac.il/˜gabr/resources/data/wordsim353/
CAPITOLO 5. L’ALGORITMO SAWA 88

5.2.3 Algoritmo
Dopo aver chiarito i dettagli relativi alla componente di terza-parte utiliz-
zata per ottemperare efficientemente al calcolo della similarità tra parole, si
procede alla presentazione dell’algoritmo in forma di pseudo-codice.

La funzione getSimilarity è quella più ad alto livello e consente, in funzione


di un parametro, di calcolare la similarità. Come detto precedentemente
(vedi 5.1.2.2 nella pagina 84), l’algoritmo utilizzato fornisce una misura di
similarità direzionale o simmetrica. Il parametro type viene utilizzato per
indicare quale tipo di misura calcolare, nel seguente modo:

• type = 0 → simmetrica o adirezionale;

• type 6= 0 → asimmetrica o direzionale.

Più propriamente, l’algoritmo del calcolo della similarità è formalizzato nella


funzione definita sim.
Dopo aver richiesto a DISCO (vedi 5.2.1 nella pagina 86) il numero totale
di parole che compongono l’intero corpus, scompone il primo testo (già prece-
dentemente ripulito delle stopword ) in un insieme di parole e per ciascuna di
queste cerca quella più simile nel secondo testo. Tale ricerca viene effettuata
dalla procedura getWordwithMaxSimilarity.
Le frequenze di tutte le parole più simili a quelle del primo testo vengono
sommate e memorizzate all’interno della variabile sumWordsFrequencies. Lo
stesso computo si esegue per i coefficienti di similarità massimi di ciascuna
parola memorizzandolo nella variabile score.
Il risultato finale viene calcolato come il rapporto tra la variabile score e
la variabile sumWordsFrequencies.

5.2.4 Performance
Sebbene gli indici di Lucene del corpus Wikipedia siano estremamente ot-
timizzati, l’algoritmo nella sua formulazione formale (vedi 5.1 nella pagina
seguente) prevede un numero di accessi all’indice, così calcolato:
CAPITOLO 5. L’ALGORITMO SAWA 89

Algorithm 5.1 Similarity Algorithm based on WikipediA(T1 ,T2 ,type)

INPUT: Due stringhe T1 e T2 ed un coefficiente numerico type.


OUTPUT: Un numero reale result ∈ [0, 1].

getSimilarity(T1 , T2 , type):
Stopword(T1 )
Stopword(T2 )
if type = 0 then
result = [sim(T1 , T2 ) + sim(T2 , T1 )] /2
else if type = 1 then
result = sim(T1 , T2 )
end if

sim(T1 , T2 ):
numW ords = DISCON umberOf W ords
sumW ordsF requencies = 0
score = 0
for all words w ∈ getW ords(T1 ) do
f requencyT erm = DISCOF requency(wordA)
wordF requency = numW ords/f requencyT erm
if f requencyT erm 6= 0 then
maxSimilarity = getW ordwithM axSimilarity(w, T2 )
if maxSimilarity > 0 then
score = score + (maxSimilarity ∗ wordF requency)
sumW ordsF requencies = sumW ordsF requency + wordF requency
else
return : 0
end if
end if
end for
return : (score/sumW ordsF requencies)

getW ordwithM axSimilarity(word, T ext):


max = 0
for all words w ∈ getW ords(T ext) do
sim = DISCOSimilarity(word, w)
if sim > 0 then
if max < sim then
max = sim
end if
end if
end for
return : max
CAPITOLO 5. L’ALGORITMO SAWA 90

accessiIndice = 1 + #paroleT1 + (#paroleT1 ∗ #paroleT2 )

che nel caso della similarità simmetrica o adirezionale diventa doppio


rispetto alla formula.
Supponendo di voler suggerire annotazioni per un servizio web in un
contesto siffatto (caso verosimile):

• 10 elementi WSDL descritti in linguaggio naturale ed una media di 13


parole ciascuno;

• un’ontologia di dominio con 1100 classi ed una media di 10 parole


ciascuna;

• server con tempo di accesso all’indice di 0,02 secondi;

la formula per il calcolo del numero di chiamate all’algoritmo è la seguente:

chiamateSAW A = #elementiW SDLdescritti ∗ #classiOntologiche.

Da tale formulazione risulta che per il suggerimento delle annotazio-


ni semantiche occorrerebbero ben 11000 chiamate a SAWA. Il tempo di
computazione è espresso nel seguente modo:

tempoComputazione = tempoAccessoIndice∗(accessiIndice∗chiamateSAW A).

Ne consegue che:

accessiIndice = 1 + 13 + (13 ∗ 10) = 144

chiamateSAW A = 10 ∗ 1100 = 11000

tempoComputazione = 0, 02 ∗ (144 ∗ 11000) = 31680 secondi.


CAPITOLO 5. L’ALGORITMO SAWA 91

L’algoritmo SAWA nella sua formulazione originale impiegherebbe l’equiva-


lente di ben 8,8 ore per suggerire le annotazioni di un unico file WSDL. Lo
scenario ipotizzato non è un caso pessimistico, è un caso reale, tuttavia è
doveroso sottolineare che si tratta di tempi teorici. Tutti i linguaggi di pro-
grammazione utilizzano sistemi di ottimizzazione del codice che non possono
essere previsti nella formula.

5.2.4.1 Ottimizzazione

Analizzando le variabili che giocano un ruolo all’intero del computo del tempo
di computazione è evidente che quella sulla quale è possibile intervenire è
soltanto il numero di accessi all’indice.
Infatti, il numero di elementi da annotare non può al più che crescere,
laddove il numero di classi ontologiche non è facilmente riducibile a causa
della presenza di relazioni tra le classi: si rischierebbe di compromettere la
coerenza dell’ontologia.
In prima analisi, un altro modo per ridurre il tempo di accesso ai dischi è
quello di utilizzare macchine server più veloci, ma i tempi potrebbero scendere
al massimo della metà: 4,4 ore al posto di 8,8, sebbene sia un importante
passo avanti, non aiuta.
L’idea quindi è stata quella di ridurre al massimo il numero di accessi
all’indice. In particolare, nella formulazione originale SAWA consultava l’in-
dice anche per ottenere risultati già calcolati in precedenza. Ecco i casi in
cui l’algoritmo è stato ottimizzato:

• richiesta del calcolo di similarità di una coppia di termini già nota:


considerando che l’algoritmo computa in modalità batch è possibile al-
locare in memoria RAM tutte le coppie per le quali è già stato richiesto
il calcolo della similarità. L’accesso alla memoria RAM è molto più
veloce (nell’ordine delle centinaia di volte) di quello al disco;

• richiesta del numero di parole presenti nel corpus: il numero di parole


presenti all’intero del corpus è un dato che andrebbe chiesto una sola
volta, è uno spreco chiederlo ad ogni chiamata dell’algoritmo;
CAPITOLO 5. L’ALGORITMO SAWA 92

• richiesta della frequenza di termini già noti: esattamente come per


il caso delle coppie di termini già note, anche in questo caso è stato
allocato in memoria RAM uno spazio che contiene tutte le frequenze
di tutti i termini già richiesti;

Dopo aver implementato queste modifiche, SAWA consulterà l’indice solo


quando gli verrà chiesto di computare la similarità o la frequenza di termini
mai analizzati. Questo tipo di ottimizzazione rende SAWA un algoritmo con
prestazioni via via sempre migliori.
Si consideri che l’ontologia di dominio non cambia per tutta l’esecuzione
batch dell’algoritmo e conseguentemente non cambia neanche il set di pa-
role utilizzato per le definizioni dei concetti ontologici. L’introduzione di
nuove parole potrebbe avvenire solo per le descrizioni inserite all’interno del
documento WSDL dagli sviluppatori.
La funzione di similarità tra parole di DISCO è naturalmente simmetri-
ca. Significa che richiedere la similarità tra due parole, in qualsiasi ordine,
restituisce lo stesso risultato. Se prima dell’ottimizzazione erano necessarie
due consultazioni dell’indice, adesso ne è necessaria solo una a patto che si
tratti di una coppia inedita. In altri termini il tempo di computazione della
similarità adirezionale (o simmetrica) è ora uguale a quello della similarità
direzionale (o asimmetrica), laddove prima era doppio.
Si noti che questo tipo di ottimizzazione preserva completamente la qua-
lità dei risultati originali. E’ altresì possibile introdurre nel calcolo della
similarità (procedura sim in 5.1 nella pagina 89) un cut-off della computa-
zione nel caso in cui la massima similarità di un termine fosse molto bassa e
pregiudicherebbe il risultato finale.
Vieppiù, nel caso del calcolo di similarità di una frase già nota, il tempo
di computazione sarebbe tendente allo zero.
Nella figura 5.2.1 vengono evidenziati i tempi di esecuzione per un solo
elemento WSDL alla prima esecuzione di SAWA. Il momento della prima
esecuzione è quello più lento poiché ogni coppia di termini è inedita e tutti
i dati devono essere recuperati dall’indice. Come si evince dalla figura, pur
trattandosi della prima esecuzione, il vantaggio è già del 77,45%.
CAPITOLO 5. L’ALGORITMO SAWA 93

Figura 5.2.1: Tempo di esecuzione si SAWA in versione ottimizzata e non


ottimizzata

Dopo un numero adeguato di richieste l’algoritmo registrerà tempi via via


sempre inferiori fino ad assestarsi ad un valore fisso che dipende unicamente
dalla velocità della macchina server. Il guadagno stimato è prossimo al 99%
dal momento che non sarà più necessario accedere agli indici. A quel punto il
tempo di accesso all’indice diventa trascurabile e le 8,8 ore iniziali diven-
tano 1 minuto al massimo. Tempo necessario ad effettuare le operazioni
di sommatoria e divisione e consultare la memoria RAM.
Nel caso dei test condotti in piccolo, il contesto di annotazione era:

• 10 elementi WSDL descritti in linguaggio naturale ed una media di 13


parole ciascuno;

• un’ontologia di dominio con 31 classi ed una media di 7 parole ciascuna;

• server con tempo di accesso all’indice di 0,026 secondi;

Con l’algoritmo privo di ottimizzazioni, ogni elemento sarebbe stato elabo-


rato in 65,97 secondi e l’intero file WSDL con le 10 annotazioni, conse-
guentemente, sarebbe stato elaborato in 659,68 secondi, l’equivalente di
11 minuti.
Con l’algoritmo ottimizzato, alla prima esecuzione si scende già a 4,39
secondi per un singolo elemento. Un miglioramento del 93,35% soltanto
CAPITOLO 5. L’ALGORITMO SAWA 94

alla prima esecuzione. Il margine di miglioramento non può che aumentare


grandemente con il passare del tempo.

5.2.5 Performance
Al fine di valutare le performance dell’algoritmo, sono stati condotti due espe-
rimenti che mirano a misurare l’abilità di catturare la similarità tra frasi. Il
primo esperimento è basato su un data set prodotto da Li et al. [31]. Il secon-
do esperimento si basa sulla valutazione dell’algoritmo nell’ottica dell’intera
piattaforma su un set ristretto di classi ontologiche.

5.2.5.1 Valutazione della misura di similarità

Il data set è prodotto da Li et al. [31] e comprende 65 coppie di frasi (ogni


coppia consiste in due frasi che sono le definizioni, prese dal corpus R&G, di
65 coppie di parole). Il dizionario utilizzato era il Collins Cobuild (Sinclair,
2001). Per ogni coppia di frasi, è stata fornito il coefficiente di similarità dei
32 soggetti partecipanti, il quale varia da 0.0 (le frasi sono completamente
scorrelate nel significato), a 4.0 (le frasi hanno significato identico)3 .
Delle 65 coppie di frasi, Li et al. [31] decisero di estrarne un sotto-
insieme di 30, similmente a quanto fatto da Miller e Charles (1991), al fine
di mantenere le frasi per le quali i coefficienti dei soggetti umani creassero
meglio una distribuzione sui valori attribuiti. Per questa ragione, SAWA è
stato testato sullo stesso sottoinsieme, descritto da Li et al. [31]. In questo
esperimento, sono stati comparati i risultati di SAWA con quelli di:

1. STASIS: la misura di similarità semantica proposta da Li et al. [31];

2. LSA: un approccio basato su LSA descritto da O’Shea et al. (2008);

3. STS: una misura proposta da Islam e Inkpen (2008);

4. Omiotis: la misura di similarità proposta da Tsatsaronis et al. (2010)


e ritenuta la migliore in letteratura.
3
Il data set è disponibile pubblicamente su http://www2.docm.mmu.ac.uk/STAFF/J.Oshea/
CAPITOLO 5. L’ALGORITMO SAWA 95

Dopo un’attenta fase di ricerca, soltanto questi 4 sistemi pare siano stati
testati su questo data set. In Tabella 5.1 si presenta il sotto-insieme di
coppie di frasi selezionate da Li et al [31] e i rispettivi coefficienti restituiti
dai partecipanti umani (in media normalizzata in 0,1), STASIS, LSA, STS,
Omiotis e SAWA.
In Tabella 5.2 si presentano i risultati della comparazione, compreso il
report relativo al coefficiente r di correlazione dell’ordine dei ranghi di Spear-
man e quello di r di Pearson per STASIS, LSA, STS, Omiotis e SAWA. Nei
risultati è stata inclusa anche la versione asimettrica di SAWA, per la quale
si tiene conto dell’ordine degli argomenti nella funzione di similarità. Questa
versione di SAWA è indicata in tabella con la voce “SAWA directed”. L’obiet-
tivo di tale esperimento è quello di individuare eventuali carenze nel metodo
utilizzato per calcolare SAWA simmetrico: la media aritmetica.
Come i risultati indicano, SAWA ha registrato la migliore correlazione
tra tutti gli algoritmi presentati in Tabella 5.2. Stando ai risultati, l’utilizzo
della misura di similarità semantica simmetrica è migliore rispetto a quella
asimettrica ed avvalora la tesi secondo la quale la media aritmetica sia un
buon metodo di calcolo. Per concludere, i risultati indicano chiaramente che
SAWA può essere impiegato con successo alla computazione della similarità
semantica tra porzioni di testo o frasi.

5.2.5.2 Sperimentazione nella piattaforma

Vista la considerevole quantità di classi presenti all’interno dell’ontologia,


durante la fase di sviluppo l’algoritmo è stato testato su un sotto-insieme di
classi ontologiche ed un insieme di descrizioni estrapolate da un file WSDL
di esempio.
Più precisamente l’algoritmo è stato testato su 31 definizioni di classi
ontologiche aventi in media 9 parole ciascuna e 10 descrizioni di elementi
WSDL aventi in media 13 parole ciascuna.
I risultati che seguono ritraggono alcuni screenshot catturati da una classe
di test. Ogni screenshot mostra la descrizione dell’elemento WSDL per il
quale suggerire le classi ontologiche, seguito da una tabella che contiene tutte
CAPITOLO 5. L’ALGORITMO SAWA 96

Coppie di frasi Umani STATIS LSA STS Omiotis SAWA


1.cord:smile 0.01 0.329 0.51 0.06 0.1062 0,1050
5.autograph:shore 0.005 0.287 0.53 0.11 0.1048 0,0426
9.asylum:fruit 0.005 0.209 0.505 0.07 0.1046 0,0611
13.boy:rooster 0.108 0.53 0.535 0.16 0.3028 0,2294
17.coast:forest 0.063 0.356 0.575 0.26 0.2988 0,3863
21.boy:sage 0.043 0.512 0.53 0.16 0.243 0,3646
25.forest:graveyard 0.065 0.546 0.595 0.33 0.2995 0,2787
29.bird:woodland 0.013 0.335 0.505 0.12 0.1074 0,2433
33.hill:woodland 0.145 0.59 0.81 0.29 0.4946 0,4123
37.magician:oracle 0.13 0.438 0.58 0.20 0.1085 0,1117
41.oracle:sage 0.283 0.428 0.575 0.09 0.1082 0,1381
47.furnace:stove 0.348 0.721 0.715 0.30 0.2164 0,4547
48.magician:wizard 0.355 0.641 0.615 0.34 0.5295 0,4046
49.hill:mound 0.293 0.739 0.54 0.15 0.5701 0,2765
50.cord:string 0.47 0.685 0.675 0.49 0.5502 0,5349
51.glass:tumbler 0.138 0.649 0.725 0.28 0.5206 0,3570
52.grin:smile 0.485 0.493 0.695 0.32 0.5987 0,5859
53.serf:slave 0.483 0.394 0.83 0.44 0.4965 0,5474
54.journey:voyage 0.36 0.517 0.61 0.41 0.4255 0,6306
55.autograph:signature 0.405 0.55 0.7 0.19 0.4287 0,3212
56.coast:shore 0.588 0.759 0.78 0.47 0.9308 0,8423
57.forest:woodland 0.628 0.7 0.75 0.26 0.612 0,6571
58.implement:tool 0.59 0.753 0.83 0.51 0.7392 0,6399
59.cock:rooster 0.863 1 0.985 0.94 0.9982 0,8070
60.boy:lad 0.58 0.663 0.83 0.60 0.9309 0,5945
61.cushion:pillow 0.523 0.662 0.63 0.29 0.3466 0,5172
62.cemetery:graveyard 0.773 0.729 0.74 0.51 0.7343 0,5596
63.automobile:car 0.558 0.639 0.87 0.52 0.7889 0,7145
64.midday:noon 0.955 0.998 1 0.93 0.9291 1,0000
65.gem:jewel 0.653 0.831 0.86 0.65 0.8194 0,6664

Tabella 5.1: Coefficienti delle 30 coppie di frasi per ciascun sistema di calcolo
dalla similarità.
CAPITOLO 5. L’ALGORITMO SAWA 97

Spearman’s ρ Pearson’s r
STATIS 0.8126 0.8162
LSA 0.8714 0.8384
STS 0.838 0.853
Omiotis 0.8905 0.856
SAWA 0.8915 0.8740
SAWA directed 0.8460 0.8437

Tabella 5.2: Coefficienti di correlazione di Spearman e Pearson rispetto a


quelli umani.

le classi analizzate con i rispettivi score di similarità calcolati da SAWA. I


risultati in tabella sono ordinati in maniera decrescente rispetto allo score.
Al termine viene mostrato anche il tempo di esecuzione.
Come si evince da tutti gli screenshot, vi è un ristretto numero di ri-
sultati che presentano un buon coefficiente di similarità seguito dai restanti
concetti che vedono attribuirsi uno score uguale a meno di piccole oscillazioni
(nell’ordine del ±1%).
Il numero di risultati con uno score rilevante non è sempre uguale. Ad
esempio, nella Figura 5.2.2 vi sono i primi 5 risultati che ottengono score
numericamente compatti. Nella Figura 5.2.3 ve n’è solo uno, il primo, poiché
già il secondo risultato ha uno score che è mezzo rispetto al primo. Il caso
illustrato in Figura 5.2.4 è simile al primo, sebbene il gruppo sia composto
da 6 elementi piuttosto che 5.
La situazione è meglio illustrata in Figura 5.2.5 e 5.2.6.
La valutazione sperimentale dell’algoritmo è stata condotta su un cam-
pione di classi ontologiche estramemente ridotto rispetto a quello che sarà
impiegato realmente, in tal senso è necessario condurre dei test statistici do-
po che la piattaforma sarà pienamente operativa e misurare le performance
in termini di efficacia.
Con riferimento ai possibili metodi di filtraggio dei risultati illustrati a
pagina 86 ritengo che sia più opportuno procedere ad un cut-off variabile
calibrato sul gruppo, calcolato attraverso la seguente formula:
CAPITOLO 5. L’ALGORITMO SAWA 98

Figura 5.2.2: Risultati di SAWA 1


CAPITOLO 5. L’ALGORITMO SAWA 99

Figura 5.2.3: Risultati di SAWA 2


CAPITOLO 5. L’ALGORITMO SAWA 100

Figura 5.2.4: Risultati di SAWA 3

Figura 5.2.5: Risultati della Figura 5.2.3 riportati su grafico


CAPITOLO 5. L’ALGORITMO SAWA 101

Figura 5.2.6: Risultati della Figura 5.2.4 riportati su grafico

score(k) − score(k + 1)
max ( )
k∈[1,n] score(k)
dove k è la posizione dell’ultimo elemento da includere tra i risultati da
restituire ed n è il numero classi ontologiche calcolate.

5.2.6 Architettura di rete


SAWA è stato pensato per essere utilizzato in maniera remota. La scelta
del paradigma SOA è stata necessaria al fine di separare efficientemente le
competenze di ricerca & sviluppo dell’azienda partner da quelle in capo al
SWAP Research Group.
Tale assunzione ha consentito di sviluppare SAWA pensandolo come un
software di rete, che una volta installato fosse perennemente operativo. Vista
la natura dell’algoritmo, esso è stato fornito di una interfaccia di rete princi-
pale la quale riceve le richieste di diverse tutte le altre interfacce esistenti e
future (web service, web page, REST service).
La scelta di anteporre un nodo di rete alle interfacce terminali è stata
pensata al fine di preservare la sicurezza del software, nonché la possibilità di
manutenere una particolare interfaccia senza dover interrompere l’esecuzione
di SAWA. Uno dei pregi più importanti è che le differenti interfacce possono
risiedere su macchine diverse per meglio bilanciare i carichi di lavoro.
Di seguito si illustrano le caratteristiche di ogni interfaccia implementata.
CAPITOLO 5. L’ALGORITMO SAWA 102

Figura 5.2.7: Architettura di rete di SAWA

5.2.6.1 Interfaccia di rete

L’interfaccia di rete di SAWA espone la funzionalità di calcolo del coefficiente


di similarità come servizio di rete via indirizzi IP e porta dedicata.
E’ stato implementato tramite la libreria Java Socket e consente di avviare
l’algoritmo su una specifica porta (socket) sull’indirizzo IP pubblico del server
che lo ospita.
Il compito del server è quello di rimanere attivo per sempre ed evadere
le richieste che giungono di volta in volta. Esso è stato sviluppato utilizzan-
do i thread: ogni richiesta è gestita come un thread autonomo, sebbene le
informazioni presenti in memoria RAM siano condivise a tutti i thread. La
scelta del thread consente di migliorare notevolmente le performance di rete
dell’algoritmo oltre che garantire una maggiore stabilità dello stesso nei casi
in cui vi fossero un numero di richieste elevate.
Da un punto di vista grafico, il server si presenta come una semplice
console che mostra: il proprio stato, il proprio indirizzo IP e la propria porta
di comunicazione.
Al fine di testare le funzionalità di questa interfaccia è stata sviluppata
CAPITOLO 5. L’ALGORITMO SAWA 103

*-- SAWA Server --------*


IP Address: 192.168.20.1
Port : 1355
Status : listening

Figura 5.2.8: Shell del server di SAWA

Figura 5.2.9: Client SAWA per Mac OS X - Interfaccia di richiesta

una semplice versione Client, disponibile per le piattaforme Windows, Mac


OS X e Linux, necessaria ad inviare i due testi (vedi Figura 5.2.9), visualizzare
lo score di similarità unitamente al tempo di elaborazione (vedi Figura 5.2.10)
ed impostare i parametri di rete (vedi Figura 5.2.11).

5.2.6.2 Interfaccia sul web

SAWA possiede una interfaccia direttamente online4 disponibile sotto forma


di pagina web.
L’interfaccia online consente di inserire i due testi in lingua inglese e dopo
4
http://193.204.187.223:8080/sawa/
CAPITOLO 5. L’ALGORITMO SAWA 104

Figura 5.2.10: Client SAWA per Mac OS X - Interfaccia di risposta

Figura 5.2.11: Client SAWA per Mac OS X - Impostazione dei parametri di


rete
CAPITOLO 5. L’ALGORITMO SAWA 105

Figura 5.2.12: Pagina web di SAWA su dispositivo mobile

aver confermato visualizza lo score di similarità unitamente al tempo richiesto


per l’elaborazione.
Le pagine web sono state realizzate utilizzando codice XHTML 1.1 e CSS
2.0 e sono completamente conformi a tali standard.
L’esistenza del sito web consente di utilizzare l’algoritmo da ogni parte del
mondo e con qualsiasi dispositivo abilitato alla navigazione web. Di seguito
si riportano alcune immagini dell’uso di SAWA su un dispositivo iPhone 4G
(vedi Figura 5.2.12).
Il sito web di SAWA è stato arricchito di una sottoscrizione a Google
Analytics5 che consente di monitorare gli accessi e ricavare una serie di utili
statistiche.
5
http://www.google.com/analytics/
CAPITOLO 5. L’ALGORITMO SAWA 106

Attualmente il numero di visite ricevute è superiore a 300, prevalen-


temente dall’Italia ma anche da Finlandia, Regno Unito, Francia e Stati
Uniti.

5.2.6.3 Interfaccia come servizio web

L’interfaccia web consente di utilizzare agevolmente l’algoritmo, ma la mo-


dalità di interazione essendo manuale, non permette un uso intensivo e con-
tinuato del servizio.
A tal proposito è opportuno fornire un servizio web che sia in grado di
integrarsi più agevolmente con i sistemi informativi aziendali.
Nell’ottica del progetto SWOP, SAWA è solo una delle componenti dell’in-
tera architettura (vedi Figura 4.1.1 nella pagina 70). Esso viene utilizzato da
una componente di più alto livello che espone i risultati all’esterno (Annota-
tion Service). E’ questa componente a possedere una propria interfaccia come
servizio web. La trattazione dell’Annotation Service esula dal contenuto di
questo documento.
Indipendentemente dagli scopi del progetto è previsto (vedi 6.1 nella pa-
gina 108) che venga realizzato un web service indipendente per SAWA, al-
lorquando esso sarà installato su un server in grado di reggere un traffico di
rete continuato ed intenso.
Capitolo 6

Conclusioni

Questo documento ha illustrato approfonditamente il lavoro svolto in qualità


di membro del progetto SWOP all’interno del SWAP Research Group.
Nei primi capitoli il lettore è stato introdotto all’architettura di svilup-
po software orientata ai servizi, alla ragioni che hanno spinto ad una tale
formalizzazione. Si sono altresì evidenziati i pregi e i difetti del principale
prodotto dell’architettura sopra-citata e presentata di conseguenza la teoria
che sottende ai Semantic Web Service.
Introdotta la teoria si è passati ad illustrare i diversi strumenti oggigiorno
esistenti per la gestione di servizi web semantici, oltre che quelli particolar-
mente utili all’annotazione semantica. Il mio lavoro in qualità di membro del
progetto SWOP mi ha visto coinvolto sulla parte più specificatamente di an-
notazione dei servizi. E’ per tale ragione che i capitoli 3 e 4 approfondiscono
solo la fase di annotazione semantica.
Dopo aver introdotto il progetto e fornito al lettore tutte le informazioni
per chiarire il contesto pratico del progetto, si è passati all’introduzione di
SAWA. Un algoritmo per il calcolo della similarità semantica tra testi con
caratteristiche di pregio in termini di performance.
Si sono illustrate le modalità di fruizione del servizio attraverso la crea-
zione di diverse interfacce a seconda di diversi scopi.

107
CAPITOLO 6. CONCLUSIONI 108

6.1 Sviluppi futuri


Di seguito si riportano i margini operativi entro i quali è possibile sin da
subito intervenire apportando miglioramenti all’algoritmo.

• Introdurre un algoritmo per il calcolo della similarità semantica tra pa-


role: attualmente SAWA si basa sull’utilizzo di DISCO, una libreria
Java open-source, che fornisce la modalità di calcolo della similarità
semantica tra parole. Sebbene abbia consentito di accorciare i tem-
pi di sviluppo, tale soluzione, implica nel lungo periodo l’obbligo di
utilizzare i corpus forniti dall’azienda che sviluppa la libreria. Attual-
mente, infatti, non c’è possibilità di utilizzare DISCO su un corpus
diverso da quelli forniti e non è nemmeno possibile utilizzare versioni
più aggiornate dei corpus forniti. L’implementazione di un algoritmo
ad-hoc, anche per il calcolo della similarità tra parole basato anch’esso
su Wikipedia aggiornata, potrebbe consentire di abbandonare DISCO
per rimpiazzarlo con una componente creata ad-hoc, magari in licenza
open-source e con una politica di rilascio dei corpus un po’ più aper-
ta (anche soltanto pubblicando le specifiche di produzione degli indici
Lucene).

• Le interfacce implementate ed attualmente disponibili soffrono di al-


cune limitazioni. La prima di queste è che non si prestano ad un uso
intensivo e continuato, ad esempio nell’integrazione con sistemi infor-
mativi aziendali, come già premesso in 5.2.6.3. Un altro problema è
quello del vincolo di utilizzo ad un unico corpus. Tecnicamente SAWA
può funzionare su corpus diversi, in diverse lingue. Parametrizzare la
scelta dei corpus e/o la scelta delle lingue, nelle differenti interfacce,
potrebbe essere d’aiuto in contesti DEMO ma anche operativi. A tal
proposito sarebbe opportuno non limitarsi a servizi web ma aggiungere
un servizio web semantico ed un servizio RESTful.

• Rilascio del codice sorgente sotto licenza open-source: a breve l’algo-


ritmo verrà rilasciato in licenza open-source. Sarà garantita la possibi-
lità di utilizzarlo a scopo non-commerciale, diffonderlo citando l’autore
CAPITOLO 6. CONCLUSIONI 109

e migliorarlo a patto che le migliorie siano anch’esso rilasciate sotto


licenza open-source.

• Implementazione del postagger: attualmente SAWA non integra alcu-


na tecnologia di part-of-speech tagging. Ciò rende l’implementazione
effettiva dell’algoritmo, una versione ridotta di [16]. Le ragioni alla
base di tale esclusione sono da ricercare nei vincoli di progetto lega-
ti alle performance dell’algoritmo. E’ possibile integrare tecnologie di
part-of-speech tagging al fine di implementare una versione totalmente
rispondente dell’algoritmo di [16].

• Condurre uno studio statistico approfondito che misuri le perfoman-


ce dell’algoritmo valutandole sperimentalmente in termini di efficacia
nel contesto di riferimento. La natura dell’algoritmo fa si che serva
un corpus ad-hoc di coppie di testi per le quali è già fornito un va-
lore di similarità soggettivo. A tal proposito, potrebbe essere estesa
l’interfaccia web chiedendo agli utenti, oltre alla coppia di testi per i
quali misurare il coefficiente di similarità, anche una stima (da 0 a 5
ad esempio) di quanto percepiscono simili i due testi forniti in input.
Il sistema consentirebbe di ottenere una base di dati sufficientemente
ampia (dopo un adeguato periodo) dalla quale estrarre con tecniche
numeriche avanzate degli indici di correzione degli score in funzione del
contenuto.
Bibliografia

[1] An information-theoretic definition of similarity. Morgan Kaufmann,


San Francisco, CA, 1998.

[2] Creating Bioinformatics Semantic Web Services from Existing Web


Services: A Real-World Application of SAWSDL, 2008.

[3] Rohit Aggarwal. Semantic web services languages and technologies:


Comparison and discussion.

[4] Dhoha Almazro, Ghadeer Shahatah, Lamia Albdulkarim, Mona Khe-


rees, Romy Martinez, and William Nzoukou. A survey paper on
recommender systems. Jun 2010.

[5] D. Ardagna and B. Pernici. Adaptive service composition in flexible


processes. Software Engineering, IEEE Transactions on, 33(6):369–384,
2007.

[6] M. Hausenblas B. Adida. Rdfa use cases: Scenarios for embedding rdf
in html. W3C Working Drafts, 2007.

[7] S. McCarron S. Pemberton B. Adida, M. Birbeck. Rdfa in xhtml: Syntax


and processing. W3C Recommendation, 2008.

[8] S. McCarron S. Pemberton B. Adida, M. Birbeck. Rdfa in xhtml: Syn-


tax and processing. a collection of attributes and processing rules for
extending xhtml to support rdf. W3C Recommendation, 2008.

110
BIBLIOGRAFIA 111

[9] Khalid Belhajjame, Suzanne Embury, Norman Paton, Robert Stevens,


and Carole Goble. Automatic annotation of web services based on
workflow definitions. pages 116–129. 2006.

[10] Fatima-Zahra Belouadha, Hajar Omrana, and Ounsa Roudies. A model-


driven approach for composing sawsdl semantic web services. CoRR,
abs/1004.3256, 2010. informal publication.

[11] Charles H. Bennett, Peter Gacs, Ming Li, Paul M. B. Vitanyi, and
Wojciech H. Zurek. Information distance. Jun 2010.

[12] Allen Brown and Hugo Haas. Web services glossary. World Wide Web
Consortium, Note NOTE-ws-gloss-20040211, February 2004.

[13] J. Cardoso. Semantic Web Services: Theory, Tools and Applications.


Hershey, 2007.

[14] Jorge Cardoso and Amit Sheth. Introduction to Semantic Web Services
and Web Process Composition. Springer, 2005.

[15] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web


services description language (WSDL) 1.1. W3c note, World Wide Web
Consortium, March 2001.

[16] Courtney Corley and Rada Mihalcea. Measuring the semantic similari-
ty of texts. In Proceedings of the ACL Workshop on Empirical Mode-
ling of Semantic Equivalence and Entailment, pages 13–18, Ann Arbor,
Michigan, June 2005. Association for Computational Linguistics.

[17] Pádraig Cunningham. A taxonomy of similarity mechanisms for case-


based reasoning. Knowledge and Data Engineering, IEEE Transactions
on, 21(11):1532–1543, November 2008.

[18] C. d’Amato, N. Fanizzi, and F. Esposito. A semantic similarity measure


for expressive description logics. In A. Pettorossi, editor, Proceedings
of Convegno Italiano di Logica Computazionale (CILC05) 21-22 June
2005, Rome, Italy, 2005.
BIBLIOGRAFIA 112

[19] Lucas Bueno Ruas de Oliveira, Katia Romero Felizardo, Daniel Feitosa,
and Elisa Yumi Nakagawa. Reference models and reference architec-
tures based on service-oriented architecture: A systematic review. In
Muhammad Ali Babar and Ian Gorton, editors, ECSA, volume 6285 of
Lecture Notes in Computer Science, pages 360–367. Springer, 2010.

[20] Joel Farrell and Holger Lausen. Semantic annotations for WSDL and
XML schema. W3C working draft, World Wide Web Consortium, 2007.

[21] Jochen Gruber. Semantic description of parameters in web service


annotations. CoRR, abs/cs/0609132, 2006.

[22] Behnam Hajian and Kamran Zamanifar. Automatic semantic web an-
notation by applying associative concept classifier in text. Journal of
Theoretical and Applied Information Technology, pages 197–205, 2009.

[23] Rubn Lara Holger, Holger Lausen, Sinuhé Arroyo, Jos Bruijn, Dieter
Fensel, and Universität Innsbruck. Semantic web services: description
requirements and current technologies, 2003.

[24] R. Studer J. Davies. Semantic Web Technologies: Trends and Research


in Ontology-Based Systems. Chichester, 2006.

[25] M. Klusch, P. Kapahnke, and I. Zinnikus. Sawsdl-mx2: A machine-


learning approach for integrating semantic web service matchmaking
variants. In Web Services, 2009. ICWS 2009. IEEE International
Conference on, pages 335–342, July 2009.

[26] Matthias Klusch. Semantic web service description. In CASCOM: In-


telligent Service Coordination in the Semantic Web, chapter 3, pages
31–57. 2008.

[27] Peter Kolb. Disco: A multilingual database of distributionally similar


words. In In Proceedings of KONVENS-2008, 2008.

[28] J. Kopecky, T. Vitvar, C. Bournez, and J. Farrell. Sawsdl: Seman-


tic annotations for wsdl and xml schema. Internet Computing, IEEE,
11(6):60–67, November 2007.
BIBLIOGRAFIA 113

[29] Jonathan Douglas Lathem. Sa-rest: Adding semantics to rest-based web


services. Master’s thesis, University of Georgia, 2007.

[30] Jonathan Douglas Lathem, Karthik Gomadam, and Amit P. Sheth. Sa-
rest and (s)mashups : Adding semantics to restful services. In ICSC,
pages 469–476. IEEE Computer Society, 2007.

[31] Yuhua Li, David McLean, Zuhair Bandar, James O’Shea, and Kee-
ley A. Crockett. Sentence similarity based on semantic nets and corpus
statistics. IEEE Trans. Knowl. Data Eng., 18(8):1138–1150, 2006.

[32] Maria Maleshkova. Acquisition and management of semantic web service


description. 2008.

[33] Maria Maleshkova, Jacek Kopecký, and Carlos Pedrinaci. Adapting


sawsdl for semantic annotations of restful services. In Robert Meersman,
Pilar Herrero, and Tharam S. Dillon, editors, OTM Workshops, volume
5872 of Lecture Notes in Computer Science, pages 917–926. Springer,
2009.

[34] David Martin, Massimo Paolucci, and Matthias Wagner. Toward se-
mantic annotations of web services: Owl-s from the sawsdl perspective.
European Semantic Web Conference, 2007.

[35] David Martin, Massimo Paolucci, and Matthias Wagner. Bringing se-
mantic annotations to web services: Owl-s from the sawsdl perspective.
pages 340–352. 2008.

[36] Brian McBride. Rdf vocabulary description language 1.0: Rdf schema,
2004.

[37] Andrei-Horia Mogos and Mugurel Ionut Andreica. Approximating ma-


thematical semantic web services using approximation formulas and
numerical methods. CoRR, abs/0909.4888, 2009.

[38] James O’Shea, Zuhair Bandar, Keeley Crockett, and David McLean. A
comparative study of two short text semantic similarity measures. In
BIBLIOGRAFIA 114

KES-AMSTA’08: Proceedings of the 2nd KES International conference


on Agent and multi-agent systems, pages 172–181, Berlin, Heidelberg,
2008. Springer-Verlag.

[39] Abhijit Patil, Swapna Oundhakar, Amit Sheth, and Kunal Verma.
Meteor-s web service annotation framework. pages 553–562. ACM Press,
2004.

[40] Pierluigi Plebani and Barbara Pernici. Urbe: Web service retrieval based
on similarity evaluation. IEEE Transactions on knowledge and data
engineering, 21(11):1629–1642, November 2009.

[41] B. Sapkota R. Akkiraju. Semantic annotations for wsdl and xml schema
- usage guide. W3C Recommendation, 2007.

[42] Lawrence Reeve. Survey of semantic annotation platforms. In Pro-


ceedings of the 2005 ACM Symposium on Applied Computing, pages
1634–1638, 2005.

[43] S. Handshuh et al. S. Agarwal. Annotation, composition and invocation


of semantic web services. Journal of Web Semantics, 2(1):31–48, 2004.

[44] Several. Gleaning Resource Descriptions from Dialects of Languages


(GRDDL), September 2007.

[45] Amit P. Sheth, Karthik Gomadam, and Jon Lathem. Sa-rest: Se-
mantically interoperable and easier-to-use services and mashups. IEEE
Internet Computing, 11:91–94, 2007.

[46] Amit P. Sheth, Karthik Gomadam, and Ajith Ranabahu. Semantics


enhanced services: Meteor-s, sawsdl and sa-rest. IEEE Data Eng. Bull.,
31(3):8–12, 2008.

[47] Nathalie Steinmetz, Mick Kerrigan, Holger Lausen, Martin Tanler, and
Adina Sirbu. Simplifying the web service discovery process. In SeMMA,
pages 31–45, 2008.
BIBLIOGRAFIA 115

[48] Rudi Studer, V. Richard Benjamins, and Dieter Fensel. Knowledge


engineering: Principles and methods. Data & Knowledge Engineering,
25(1-2):161 – 197, 1998.

[49] The LyX Team. LyX 1.6.1 - The Document Processor [Computer soft-
ware and manual]. Internet: http://www.lyx.org, 2009. Retrieved
February 16, 2009, from http://www.lyx.org.

[50] Eufemia Tinelli, Michele Filannino, Daniele Casulli, and Leo Iacquinta.
Swop: Semantic web services opened platform. SWAP Conference, 2010.

[51] George Tsatsaronis, Iraklis Varlamis, and Michalis Vazirgiannis. Text


relatedness based on a word thesaurus. J. Artif. Int. Res., 37(1):1–40,
2010.

[52] W3C. Owl-s: Semantic markup for web services. Padrão, November
2004.

[53] W3C. SOAP Version 1.2 Part 1: Messaging Framework (Second


Edition), 2004. ittp://www.w3.org/TR/soap12-part1/ [25/02/2008].

[54] W3C HTML Working Group. XHTML 1.0: The Extensible Hyper-
Text Markup Language. a reformulation of HTML 4 in XML 1.0. W3C
Recommendation, W3C - World Wide Web Consortium, August 2002.

[55] Eric Yeh, Daniel Ramage, Christopher D. Manning, Eneko Agirre, and
Aitor Soroa. Wikiwalk: Random walks on wikipedia for semantic
relatedness. ACL-IJCNLP Workshop, 2009.

[56] Shoujian Yu, Qin Zhu, Xiaoling Xia, and Jiajin Le. A novel web
service catalog system supporting distributed service pubblication and
discovery. 2009.