Sviluppo di un algoritmo di similarità a supporto dell'annotazione semantica di Web Services

1

Copyright © 2010 Michele Filannino <[email protected]>.

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

You should have received a copy of the GNU General Public License alongwith 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 8giorni prima della seduta di laurea. Un lavoro lasciato alla fine non perché difficilema perché volevo contenesse i miei sentimenti più veri. Non sarebbe stato giustoscriverli 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 unanuova inutile televisione LCD sia sua, mentre mia madre parla di conti, bollette edaltre amenità, mentre Donato si affanna a far finta di assecondare mio padre, mentreClaudio divora manga al PC aspettando che il suo primo anno da matricola di Fisicacominci 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 nessunopotrà guardarti, quando non desterai sospetti aprirai questa tesi e cercherai questapagina. Non lo farai per avere uno spunto, non per interesse, lo farai perché tichiederai se sono diverso da come mi hai sempre visto, se è normale vivere assortinel proprio mondo e scoprirai di essere mio emulo. Ma lo scoprirai soltanto traqualche 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 rimanedentro per sempre. Che tu possa sempre viaggiare senza mai preoccuparti delle stradeimboccate e abbandonate. Nessuna pressione, nessuna costrizione: fai sempre quelloche senti di dover fare per raggiungere i tuoi sogni.

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

La mia famiglia, Marilena la mia incredibile ragazza, Asia (con Fatima, Benito ed ilsimpaticissimo Ettore) ed ovviamente tutti i miei amici della ridente Andria. Perquesti 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 vostroamico. Con la mia ragazza non basterebbe una vita, ma vale la pena provare aspenderla 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 teper aver stampato questo documento in tempi record.

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

Indice

1 Introduzione 91.1 Scopo della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Service Oriented Architecture 132.1 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.1 Tecnologie standard . . . . . . . . . . . . . . . . . . . . 182.1.1.1 eXtensible Markup Language (XML) . . . . . 182.1.1.2 Service Oriented Application Protocol (SOAP) 192.1.1.3 Web Service Description Language (WSDL) . 192.1.1.4 Universal Description Discovery and Integra-

tion (UDDI) . . . . . . . . . . . . . . . . . . 202.1.1.5 Vantaggi nell’uso dei Web Service . . . . . . . 212.1.1.6 REST . . . . . . . . . . . . . . . . . . . . . . 22

2.1.2 Limiti dei Web Service . . . . . . . . . . . . . . . . . . 232.2 Dai Web Service ai Semantic Web Service . . . . . . . . . . . 24

2.2.1 Semantica nel web . . . . . . . . . . . . . . . . . . . . 242.2.2 Web Ontology Language (OWL) . . . . . . . . . . . . 26

3 Semantic Web Service 303.1 Tipi di semantica . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.1 Semantica funzionale . . . . . . . . . . . . . . . . . . . 313.1.2 Semantica dei dati . . . . . . . . . . . . . . . . . . . . 323.1.3 Semantica della qualità . . . . . . . . . . . . . . . . . . 323.1.4 Semantica di esecuzione . . . . . . . . . . . . . . . . . 33

4

INDICE 5

3.2 Infrastruttura dei Semantic Web Service . . . . . . . . . . . . 333.3 Annotazione semantica . . . . . . . . . . . . . . . . . . . . . . 37

3.3.1 Tool per l’annotazione semantica . . . . . . . . . . . . 393.3.1.1 Tool semi-automatici . . . . . . . . . . . . . . 393.3.1.2 Tool manuali . . . . . . . . . . . . . . . . . . 41

3.3.2 Elaborazione del linguaggio naturale . . . . . . . . . . 453.4 Annotazione di SWS . . . . . . . . . . . . . . . . . . . . . . . 47

3.4.1 Web Ontology Language for Services (OWL-S) . . . . . 483.4.2 Web Service Modeling Ontology (WSMO) . . . . . . . 513.4.3 Web Service Semantic (WSDL-S) . . . . . . . . . . . . 543.4.4 Semantic Annotation for WSDL and XML Schema (SA-

WSDL) . . . . . . . . . . . . . . . . . . . . . . . . . . 553.5 Annotazione di REST service . . . . . . . . . . . . . . . . . . 61

3.5.1 SA-REST . . . . . . . . . . . . . . . . . . . . . . . . . 613.5.2 Tecniche di annotazione e linguaggi . . . . . . . . . . . 62

3.5.2.1 RDFa . . . . . . . . . . . . . . . . . . . . . . 623.5.2.2 GRDDL . . . . . . . . . . . . . . . . . . . . . 63

3.5.3 Stato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4 SWOP Project 664.1 Architettura generale . . . . . . . . . . . . . . . . . . . . . . . 704.2 Annotazione semantica di Web Service . . . . . . . . . . . . . 72

4.2.1 Interfaccia utente . . . . . . . . . . . . . . . . . . . . . 734.2.2 Ontologia di dominio . . . . . . . . . . . . . . . . . . . 77

5 L’algoritmo SAWA 795.1 Similarità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.1.1 Similarity vs. Relatedness . . . . . . . . . . . . . . . . 805.1.2 Similarità semantica . . . . . . . . . . . . . . . . . . . 80

5.1.2.1 Similarità tra parole . . . . . . . . . . . . . . 825.1.2.2 Dalla similarità tra parole alla similarità tra

testi . . . . . . . . . . . . . . . . . . . . . . . 845.2 SAWA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

INDICE 6

5.2.1 DISCO . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.2.2 Corpus . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.2.3 Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . 885.2.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . 88

5.2.4.1 Ottimizzazione . . . . . . . . . . . . . . . . . 915.2.5 Performance . . . . . . . . . . . . . . . . . . . . . . . . 94

5.2.5.1 Valutazione della misura di similarità . . . . . 945.2.5.2 Sperimentazione nella piattaforma . . . . . . 95

5.2.6 Architettura di rete . . . . . . . . . . . . . . . . . . . . 1015.2.6.1 Interfaccia di rete . . . . . . . . . . . . . . . . 1025.2.6.2 Interfaccia sul web . . . . . . . . . . . . . . . 1035.2.6.3 Interfaccia come servizio web . . . . . . . . . 106

6 Conclusioni 1076.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Elenco delle figure

2.0.1 Architettura SOA . . . . . . . . . . . . . . . . . . . . . . . . . 152.0.2 Architettura SOA nel Web . . . . . . . . . . . . . . . . . . . . 162.1.1 Web Service e loro standard . . . . . . . . . . . . . . . . . . . 182.1.2 Relazione tra XML, SOAP, WSDL ed UDDI . . . . . . . . . 192.1.3 SOAP skeleton listing . . . . . . . . . . . . . . . . . . . . . . . 202.2.1 Esempio di dichiarazione in OWL . . . . . . . . . . . . . . . . 272.2.2 Dichiarazione degli elementi di base in OWL . . . . . . . . . . 29

3.0.1 Semantic Web Services nel Semantic Web . . . . . . . . . . . . 303.2.1 Le dimensioni delle infrastrutture per Semantic Web Services . 343.3.1 Screenshot del tool MWSAF . . . . . . . . . . . . . . . . . . . 403.3.2 Screenshot di IBM Annotation Editor da pagina HTML . . . . 413.3.3 Screenshot di IBM Annotation Editor . . . . . . . . . . . . . . 423.3.4 Screenshot di Radiant . . . . . . . . . . . . . . . . . . . . . . 423.3.5 Screenshot di WSMO Studio . . . . . . . . . . . . . . . . . . 443.3.6 Screenshot di Jena con “SCA Tool Feature - SAWSDL Sup-

port” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3.7 Schematizzazione del processo di indicizzazione semantica dei

documenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4.1 Livello più generale dell’ontologia OWL-S . . . . . . . . . . . . 493.4.2 Struttura di WSMO . . . . . . . . . . . . . . . . . . . . . . . 523.4.3 Metafora dei puntatori di SAWSDL ai concetti ontologici . . . 583.4.4 Schema di SAWSDL . . . . . . . . . . . . . . . . . . . . . . . 603.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 . . . . . . . . . . . . . . . . 704.2.1 Flusso di lavoro del modulo di annotazione . . . . . . . . . . . 724.2.2 Lista ordinata di classi ontologiche semanticamente simili . . . 744.2.3 Mockup GUI di CODEArchitects Annotation Tool . . . . . . . 754.2.4 Mockup GUI di elaborazione CODEArchitects Annotation Tool 764.2.5 Mockup GUI risultati di CODEArchitects Annotation Tool . 76

5.0.1 Logo di SAWA . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2.1 Tempo di esecuzione si SAWA in versione ottimizzata e non

ottimizzata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.2.2 Risultati di SAWA 1 . . . . . . . . . . . . . . . . . . . . . . . 985.2.3 Risultati di SAWA 2 . . . . . . . . . . . . . . . . . . . . . . . 995.2.4 Risultati di SAWA 3 . . . . . . . . . . . . . . . . . . . . . . . 1005.2.5 Risultati della Figura 5.2.3 riportati su grafico . . . . . . . . . 1005.2.6 Risultati della Figura 5.2.4 riportati su grafico . . . . . . . . . 1015.2.7 Architettura di rete di SAWA . . . . . . . . . . . . . . . . . . 1025.2.8 Shell del server di SAWA . . . . . . . . . . . . . . . . . . . . . 1035.2.9 Client SAWA per Mac OS X - Interfaccia di richiesta . . . . . 1035.2.10Client SAWA per Mac OS X - Interfaccia di risposta . . . . . 1045.2.11Client SAWA per Mac OS X - Impostazione dei parametri di

rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.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 annonell’ambito del progetto regionale (Asse I, linea di intervento 1.1, 2007-2013)che ha coinvolto il SWAP Research Group1 del Dipartimento di Informaticadi Bari2 e la società CODEArchitects srl3 in qualità di partner aziendale.

La ricerca di web service basata sul contenuto informativo prodotto daesperti umani costituisce oggigiorno un fattore chiave per ogni piattaformaper la gestione di servizi web. La semplicità con la quale è possibile realizzaree pubblicare servizi web ha fatto si che questo strumento si diffondesse fino adivenire un caposaldo dell’intera artchitettura di sviluppo SOA. Un passo inavanti nel suo sviluppo è costituito dalla progettazione ed implementazionedi nuovi metodi che consentano di annotare testo semplice in maniera semi-automatica utilizzando concetti ontologici.

Motivati da questa esigenza, il progetto SWOP (Semantic Web OrientedPlatform) introduce il concetto di annotazione semantica semi-automaticavolta a migliorare l’accuratezza dei servizi di ricerca nei sistemi informativiaziendali.

In questo lavoro, presenterò in dettaglio una parte del modulo di coredell’intera architettura di progetto [50], la quale è responsabile dell’annota-zione semi-automatica di web services. In particolare, presenterò l’algoritmo

1http://www.di.uniba.it/~swap/2http://www.di.uniba.it/3http://www.codearchitects.com/

9

CAPITOLO 1. INTRODUZIONE 10

di similarità tra testi espressi in lingua inglese, realizzato per supportare lafase di annotazione semantica. Tale algoritmo infatti è impiegato per estrarredall’ontologia di dominio un sotto-insieme di classi la cui definizione in linguainglese è simile a quella fornita dagli utenti per definire le singole operazionidi un servizio web.

Il seguente documento, pertanto, rappresenta una sintesi di quanto è statoda 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 relativaall’annotazione semantica dei web service. L’azienda partner produce unframework autonomo di sviluppo impiegato dai propri clienti per costruirein 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. Conil crescere sempre più repentino del numero di servizi messi a disposizione èdiventato necessario migliorare gli strumenti di ricerca dei servizi. L’aziendapartner, CODEArchitects, ha deciso di avviare lo sviluppo di un sistema diricerca semantica che consentisse di reperire servizi web in maniera più velocee 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 allaricerca ed attendere che il sistema lo trovi. Il sistema realizzato da SWAPResearch Group provvederà a restituire un insieme di servizi che rispondonoalla descrizione fornita dagli sviluppatori.

Tale progetto è ambizioso per diversi ed importanti motivi:4http://www.scribd.com/doc/37331024/Sviluppo-di-un-algoritmo-di-similarita-a-

supporto-dell-annotazione-semantica-di-Web-Services


• l’azienda partner lavora con un ambiente di sviluppo proprietario, al-l’interno del quale non vi sono tool o librerie per l’accesso intelligenteall’informazione;

• l’architettura progettuale dell’intero sistema fa si che la soluzione creatapossa essere integrata ed utilizzata efficacemente con qualsiasi altroambiente 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: migliorale proprie performance con il passare del tempo;

• il sistema è completamente indipendente dal tipo di lingua utilizzatacome 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 svilupposoftware orientata ai servizi. Il progetto al quale ho partecipato mira allarealizzazione di una estensione in chiave semantica dell’architettura primacitata (SOA).

Il Capitolo 3 approfondisce il tema dei servizi web semantici iniziandoil lettore a tutte le tecnologie oggigiorno disponibili. Il mio lavoro è sta-to concentrato prevalentemente nel segmento dedicato all’annotazione di unservizio web per far si che questo potesse arricchirsi di significato processa-bile dalla macchina. Per questa ragione, nel terzo capitolo verrà dato ampiospazio al segmento di annotazione. Nella seconda parte del capitolo verràillustrato lo stato dell’arte relativamente all’annotazione semantica di servizi


REST. Verranno illustrati gli standard e le tecnologie relative alla gestionedi piattaforme di Web Service con particolare riferimento ai limiti di taliapprocci in modo da introdurre il valore aggiunto derivante dall’annotazio-ne semantica. Si procederà, quindi, con l’analizzare il significato di SemanticWeb Service, con particolare riferimento al termine “semantic”: cosa significain 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 ecome essa è suddivisa.

Il Capitolo 5 presenta SAWA, l’algoritmo da me realizzato, capace dimisurare la similarità semantica tra due frasi espresse in linguaggio natu-rale e suggerire le annotazioni semantiche più appropriate in funzione delledescrizioni 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 ridurredrasticamente il peso computazionale dell’intero algoritmo.

Il Capitolo 6 chiude questo documento con un’analisi critica del lavorosvolto alla quale segue un’insieme di possibili interventi volti a migliorarel’algoritmo per il calcolo della similarità semantica.

Capitolo 2

Service Oriented Architecture

Dagli anni ’90, Internet ha beneficiato di una forte crescita accompagnata daun sempre più vivo interesse da parte delle aziende.

La possibilità di utilizzare la rete globale come veicolo di comunicazione edanche di vendita ha spinto le imprese ad integrare i propri sistemi informativirichiedendo notevoli sforzi organizzativi e tecnologici.

Prima dell’avvento di Internet, la maggior parte delle aziende adottavasistemi informativi quasi totalmente proprietari, e completamente incapacidi 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 è facilitarel’interoperabilità tra i diversi sistemi, consentendo l’utilizzo delle singole ap-plicazioni come componenti del processo di business e soddisfando le richiestedegli 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’informazionestrutturata):

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 voluticonsistentemente con presupposti ed aspettative misurabili.

È importante rilevare che tale architettura, oltre che essere utilizzata peragevolare la comunicazione tra aziende differenti, venga abbondantementeimpiegata anche per la comunicazione interna. In altri termini, è possibile cheper motivi storici ed organizzativi, differenti divisioni della medesima aziendaabbiano 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 treattori principali che prendono parte all’intero processo di richiesta e fornituradel 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 migliorcompromesso tra visibilità e privacy;

• un service requestor : attore che richiede un servizio e lo utilizza (use)conformemente al protocollo di comunicazione stabilito. Il richiedentequasi mai conosce l’indirizzo esatto del servizio di cui necessita, perquesta ragione cerca (find) e contatta un intermediario noto (dettobroker);

• service directory (o broker): questo attore offre supporto a tutti i ri-chiedenti di servizi e restituisce un elenco di provider coerenti con lerichieste degli attori richiedenti. Il broker può adottare politiche di con-trollo degli accessi modificando la visibilità di taluni servizi a scapitodi 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-


Figura 2.0.1: Architettura SOA

tettura, essendo estremamente generale, si adatta bene a differenti canalitrasmissivi: 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 piattaformahardware e software sottostante (vedi Figura 2.0.2).

E’ opportuno chiarire che un’architettura SOA che sfrutti il Web comemezzo trasmissivo, può anche essere sviluppata utilizzando tecnologie dif-ferenti: RPC, REST, DCOM, CORBA, WCF (Windows CommunicationFoundation).

Il principale pregio di questa architettura è la possibilità di offrire servizia prescindere dal tipo di linguaggio utilizzato dall’attore richiedente ed ero-gante. Per inciso, un sistema informativo scritto in Java può offrire serviziad uno scritto in C# e viceversa.


Figura 2.0.2: Architettura SOA nel Web

In questo tipo di architettura ogni attore mette a disposizione un numeroarbitrario di servizi e può utilizzare quelli offerti dagli altri attori. In questocontesto è possibile, in maniera più facile, realizzare applicazioni anche moltocomplesse frutto di un’opportuna orchestrazione di servizi.

Sotto queste ipotesi i servizi prendono il nome di Servizi Web (WebService).

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 serviziall’esterno ed utilizza servizi di altri attori. Questo meccanismo ha fattosi che si venissero a creare applicazioni complesse operanti sul web realiz-zate esclusivamente tramite un’opportuna orchestrazione manuale di questiservizi.

I Web service sono componenti applicativi modulari, auto-descrittivi edindipendenti (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 attraversoun messaggio XML che osserva gli standard SOAP. La componente mette adisposizione una o più operazioni da eseguire per conto del richiedente. Le


operazioni e i formati di input ed output dei messaggi scambiati sono descrittiutilizzando WSDL [15].

Essendo legato a standard aperti del Web, un Web service è indipendentesia dal suo linguaggio di implementazione che dal tipo di piattaforma. Ladescrizione del servizio, espressa in un linguaggio neutrale, è essenziale perla diffusione di tale tecnologia. Per poter essere utilizzato, in generale, unservizio deve essere descritto e pubblicizzato. WSDL si preoccupa della fa-se di descrizione mettendo a disposizione un apposito linguaggio capace diesprimere 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 tuttii 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 linguaggioWSDL) ed eventualmente informazioni addizionali come quelle circa il for-nitore. I richiedenti di un particolare servizio (i client) possono interrogarediversi registri per scoprire ed usare servizi rilevanti.

Per descrivere ulteriormente un Web service, proviamo ad esaminare unoscenario 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 propriclienti, accesso illimitato al sistema, ma vuole solo dare loro lapossibilità di effettuare ordini in modo più facile. Utilizzandoi Web service, Moon Company può creare un’interfaccia con ilproprio sistema che possano utilizzare i clienti, previa autentica-zione, per effettuare gli ordini. Sotto queste ipotesi, l’azienda habisogno di fornire una definizione WSDL del servizio e i clientisaranno in grado di realizzare sistemi interni che utilizzano il ser-vizio di ordini offerto dal fornitore. Poiché Moon Company nonconosce i sistemi informativi utilizzati dai suoi clienti, tecnologiealternative sarebbero difficili da implementare”.


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 lacapacità 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 buonlivello di maturità ed è utilizzata per offrire facilmente funzionalità di busi-ness all’interno di Intranet ed Internet. Le funzionalità di business possonoconsistere in applicazioni comuni come sistemi di ERP, CRM e SCM.

Alcuni degli standard associati ai Web Service sono indispensabili persviluppare 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 ditrasporto (mandare messaggi tra fornitore e richiedente); WSDL descrive cia-scun Web service; UDDI è utilizzato per registrare il servizio e consentirne ilritrovamento.

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 alproblema di integrazione, poiché consente una codifica e visualizzazione fles-


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 (DTDoppure XSD). Un documento XML ben formato crea un albero bilanciato diinsiemi annidati di tag aperti e chiusi, ognuno dei quali può includere diversecoppie attributo-valore.

2.1.1.2 Service Oriented Application Protocol (SOAP)

Questo standard definisce i tipi ed i formati dei messaggi XML che possonoessere scambiati tra attori in un ambiente decentralizzato e distribuito. Unodei principali obiettivi di SOAP è di essere un protocollo di comunicazioneche può essere usato da diverse applicazioni sviluppate utilizzando diversilinguaggi di programmazione, sistemi operativi e piattaforme. La specificacorrentemente pubblicata dal W3C definisce una struttura del tipo in Figura2.1.3. L’involucro (Envelope) più esterno definisce lo spazio dei nomi dellaspecifica SOAP e il tipo di codifica dei caratteri utilizzato per la stesura deldocumento. La sezione di intestazione (Header) è opzionale e contiene infor-mazioni aggiuntive circa il messaggio. La sezione centrale (Body) contiene idati che devono essere trasferiti.

2.1.1.3 Web Service Description Language (WSDL)

WSDL (Web Service Description Language) è il linguaggio che fornisce unmodello, espresso in formato XML, che descrive le informazioni sintattichecirca 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


Figura 2.1.3: SOAP skeleton listing

tra la descrizione delle funzionalità astratte offerte dal servizio e la concretaloro implementazione, definendo in tal modo l’interfaccia che il Web Servicemetterà 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 icostrutti per la creazione di tipi di dato complessi.

In Appendice 3.1 Documento WSDL di esempio è riportato il codice diesempio di un file WSDL.

2.1.1.4 Universal Description Discovery and Integration (UDDI)

UDDI (Universal Description, Discovery, and Integration) è attualmente lostandard di fatto per la registrazione ed il ritrovamento di Web Service.

Quando un servizio viene sviluppato, è necessario pubblicizzarlo al finedi agevolarne il ritrovamento. Il meccanismo di ritrovamento può essereottimizzato in modo tale da essere adeguato alla vastità del Web garantendoricerche efficienti e risultati rilevanti tra i centinaia o migliaia di Web Servicedisponibili.


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 fornitodal possessore del servizio. Queste directory forniscono visibilità ai serviziche possono così essere invocati (utilizzati) dai richiedenti. UDDI può memo-rizzare le descrizioni dei servizi interni ad un’organizzazione così come quellipubblici presenti in Internet.

2.1.1.5 Vantaggi nell’uso dei Web Service

Riepilogando, è possibile tracciare un elenco dei principali punti di forzaderivanti 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 itrasferimenti 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 aiservizi rimangono trasparenti;

• sono in grado di pubblicare le loro funzioni e di scambiare dati con ilresto del mondo;

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


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 ultimitempi.

REST si riferisce ad un insieme di principi di architetture di rete, i qualidelineano come le risorse sono definite ed indirizzate. Il termine è spessousato nel senso di descrivere ogni semplice interfaccia che trasmette dati suHTTP senza un livello opzionale come SOAP o la gestione della sessionetramite i cookie. Questi due concetti possono andare in conflitto così comein sovrapposizione. È possibile progettare ogni sistema software complessoin accordo con l’architettura REST senza usare HTTP e senza interagire conil World Wide Web.

È altresì possibile progettare una semplice interfaccia XML+HTTP chenon sia conforme ai principi REST, e invece segua un modello di RemoteProcedure Call. I sistemi che seguono i principi REST sono spesso definiti"RESTful".

REST prevede che la scalabilità del Web e la crescita siano diretti risultatidi 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 universaletramite 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 dacodice on-demand;

– un protocollo che è: client-server, stateless, cacheable ed organiz-zato a livelli.


Utilizzando messaggi basati su XML, i servizi RESTful possono unire datidiscreti provenienti da differenti servizi per creare insiemi di dati con unparticolare significato. Questa operazione prende il nome di mashup.

Se da un punto di vista concettuale il mashup è molto utile ed abbraccianettamente l’idea di personalizzazione del Web, la sua implementazione realenon è altrettanto semplice ed immediata.

Per superare i problemi di implementazione, grossomodo legati alla com-plessità intrinseca di tale attività, diverse aziende hanno prodotto tool ingrado di assistere e supportare tale attività. I più noti sono: Yahoo’s pipes1,IBM QEDwiki2 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 trovanella 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 ilproblema della compatibilità, dall’altro ne appesantisce i dati poiché oltreal contenuto informativo vero e proprio sono necessari tag e strutture ag-giuntive. Oltre a ciò è anche necessario che i due attori della comunicazionieffettuino 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: uniciattori capaci di comprendere la semantica sottesa a ciascun servizio per poirealizzarne un’opportuna combinazione al fine di produrre applicazioni piùarticolate e complesse.

1http://pipes.yahoo.com/pipes/2http://services.alphaworks.ibm.com/graduated/qedwiki.html3http://editor.googlemashups.com (Il tool è stato dismesso pochi giorni fa)


E’ proprio in quest’ultima pratica che risiede il principale limite dei serviziweb comunemente utilizzati. Alla luce del successo di tale tecnologia e dellafacilità con la quale ogni applicazione se ne serve, delegare attività quali laricerca, la selezione e la composizione ad attori umani è oggigiorno diventatoun 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 correttoritrovamento del servizio ma soltanto la sua pubblicazione.

Attualmente i servizi web vengono ritrovati dagli sviluppatori softwarecon diversi criteri. La ricerca di tali servizi è difficoltosa e non sempre fruttuo-sa. La chiave necessaria per migliorare la fase di ritrovamento è l’associazionedi 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 lasemantica.

Si studiano tecniche orientate ad arricchire ciascun servizio web già esi-stente con un livello semantico che esprima le funzionalità del servizio inmaniera machine-readable.

La scelta di arricchire le risorse correntemente esistenti è chiaramenteessenziale in un’ottica aperta come quella del web: i tentativi di riscritturadell’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 unvocabolario 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,


machine-understandable per consentire l’implementazione di soluzioni idoneea 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, leontologie giocano un ruolo decisivo e vengono considerate il blocco fondantedel Semantic Web poiché consentono l’interpretazione dei dati da parte deicalcolatori riducendo, conseguentemente, il coinvolgimento dell’uomo.

In letteratura esistono diverse definizioni di ontologia tutte afferenti aparticolari 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 relazionirilevanti per un certo dominio applicativo.

In tal senso le ontologie si possono classificare a seconda di quanto sonogenerali: si va dalle ontologie top-level (che formalizzano concetti generalio di senso comune) fino alle ontologie di applicazione (che trattano concettimolto 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 eventualmentetassonomie.

Nella maggior parte dei casi, la rappresentazione di una ontologia è sempreformale poiché il fine ultimo è quello di rendere una parte di conoscenzacomprensibile al calcolatore. Sotto opportune condizioni, infatti, è possibileusare un’ontologia per ragionare induttivamente, classificare ed in generalefare inferenze logiche.

Questi grandi repository di conoscenza vengono costruiti appositamenteda utenti che prendono il nome di Ingegneri della conoscenza: attori in gradodi definire i concetti rilevanti per il dominio di interesse, ordinare i concettiin gerarchie, definire le proprietà ed i vincoli su di essi, nonché stabilire leopportune relazioni.


Realizzare da zero un’ontologia di un dominio, anche non particolarmentevasto, non è un lavoro banale. Il numero di considerazioni, decisioni proget-tuali che devono essere intraprese, unitamente alla profonda conoscenza didominio richiesta per la realizzazione di un’ontologia, fanno si che si prediligal’uso di ontologie vicine al proprio dominio (o a volte la personalizzazione diqueste) piuttosto che la sua costruzione “from scratch”.

Il linguaggio standard per la definizione di ontologie è OWL. Il 27 ottobre2007, il W3C ha annunciato OWL 2 suggerendolo come raccomandazione perla 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 esprimererelazioni 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 espressiveche 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 sulleproprietà;

• OWL DL è utile quando è necessaria la massima espressività mantenen-do la completezza computazionale e la decidibilità. OWL DL includetutti i costrutti del linguaggio OWL, ma questi possono essere utilizzatisolo 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 basedi OWL;

• OWL Full è utile quando si ha bisogno del massimo potere espressivoe della libertà sintattica di RDF senza che vi siano garanzie computa-zionali (in pratica è utile solo per la rappresentazione dei contenuti, ma


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 informazionirappresentate.

Una tipica ontologia OWL comincia con una dichiarazione dello spazio deinomi (URI) che fornisce un modo per l’interpretazione non ambigua degliidentificatori e rende la presentazione dell’ontologia più leggibile indicandoprecisamente quali sono i vocabolari utilizzati.

Una volta dichiarati i namespace, si dichiarano un insieme di asserzioniinerenti 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.


OWL fornisce i costrutti necessari per definire questi elementi. Generalmen-te, il concetto fondamentale in un dominio deve corrispondere alle classi chesono 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à implicitamenteuna sottoclasse di owl:Thing. Le classi radice di uno specifico dominio, pos-sono essere definite semplicemente dichiarandone il nome. OWL permetteanche la definizione della classe vuota, owl:Nothing.

La definizione di una classe è suddivisa in due parti: un nome introduttivoo un riferimento ed una serie di restrizioni. Ognuna delle espressioni che sonocontenute all’interno della definizione della classe, restringono le proprietàche possono essere applicate alle istanze della classe definita. Le istanzedella 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 universodelle cose. Un individuo è introdotto principalmente dichiarando la sua ap-partenenza ad una classe. È importante sottolineare le differenze tra classee 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 imembri di questi insiemi. Per questo motivo le classi devono corrispondereagli insiemi delle cose che compaiono in modo naturale nel dominio di undiscorso 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 fattigenerali riguardo i membri delle classi e di asserire fatti specifici riguardo gliindividui. Si distinguono due tipi di proprietà:

• datatype properties : relazioni tra le istanze delle classi ed elementi RDFliterals 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:


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 iprocessi d’integrazione dei Web service [43] allo scopo di automatizzare lefasi 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à epermette di integrarle con una conoscenza di dominio che può anche essereutilizzata in maniera indipendente.

Arricchiti con una descrizione formale delle proprie capacità [23], questiservizi possono essere utilizzati da altre applicazioni o da altri servizi senzaspecifici interventi da parte dell’uomo o accordi molto vincolanti su interfaccee protocolli. I Semantic Web Service appaiono dunque come un’estensionedelle attuali tecnologie e standard per i Web service realizzata utilizzando letecnologie 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 quattrodiversi tipi, ciascuno dei quali opportunamente scelto per rappresentare lecapacità, 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 nonmeramente sintattico. Posto in essere ciò, è sempre possibile individuare aseconda dei contesti d’uso, accezioni di semantica diverse.

Di seguito si riportano quelle individuabili all’interno dello scenario deiservizi web.

3.1.1 Semantica funzionale

Il potere dei Web Service si manifesta solo quando vengono ritrovati serviziappropriati, rispondenti ai requisiti funzionali.

Un assunzione universale per i differenti algoritmi di discovery di serviziweb semantici è che la funzionalità del servizio è caratterizzata dal suo inpute dal suo output.

In tal senso questi algoritmi cercano le corrispondenze tra input ed outputdei servizi, ed input ed output dei requisiti. Questo tipo di corrispondenzasemantica, da sola, può non restituire risultati appropriati che soddisfino irequisiti funzionali.

Per esempio: due servizi possono avere le stesse specifiche di input/outputanche se assolvono a compiti completamente diversi. Un servizio semplicis-simo di somma di due numeri avrà lo stesso significato sintattico di un altroservizio 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-


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

Anziché utilizzare ontologie, in alcuni rari casi la semantica funzionale puòessere espressa per categorizzazione. Tale tecnica è utilizzabile solo quandole funzionalità del servizio ricadono in categorie prestabilite da organi com-petenti, come United Standard Products and Services Code (UNSPSC1) o ilRosettaNet 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 intermini 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 diservizi, è necessario esprimere la semantica dei dati di input/output [21].

Quindi, se i dati coinvolti nell’operazione del Web service fossero annotatiutilizzando un’apposita ontologia, allora questi potrebbero essere utilizzatiper effettuare un confronto semantico tra i dati di input/output dei servizi equelli di input/output delle richieste.

3.1.3 Semantica della qualità

Dopo aver ritrovato i Web Service la cui semantica corrisponde con quelladelle richieste, il passo successivo è selezionare il servizio più adatto. Ogniservizio può avere diverse qualità perciò la scelta implica la corrispondenzacon il criterio che esprime la miglior qualità.

Il criterio di selezione del servizio riveste un ruolo essenziale specialmentenella 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 contodelle qualità di interesse.

1http://www.unspsc.org2http://www.rosettanet.org/Standards/RosettaNetStandards/Dictionaries/tabid/477/Default.aspx


Tuttavia, lo studio di questo tipo di semantica esula dagli obiettivi diquesto documento, dal momento che trova la sua utilità nelle fasi di selezionee composizione, anziché in quella di annotazione.

Tale tipo di semantica è spesso esplicitata anche per elicitare dei vincoli odettagli 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 dimessaggi, 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 solocondividano 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 ilservizio web da due punti di vista: esterno ed interno.

Il comportamento esterno descrive il protocollo che il client deve osservareper consumare le funzionalità del servizio. Il comportamento interno, alcontrario, descrive un flusso di lavoro: come le funzionalità del servizio siaggregano con eventuali servizi esterni. La formalizzazione di quest’ultimocomportamento (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)


Figura 3.2.1: Le dimensioni delle infrastrutture per Semantic Web Services

e Service Ontology (ontologia di descrizione dei servizi). Queste dimensionisono 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 inaltri termini un framework per i Semantic Web Service deve essere in gradodi supportare. L’architettura dei SWS descrive le componenti necessarieper portare a termine queste attività. L’ontologia di servizio si occupa diaggregare tutti i modelli concettuali collegati alla descrizione di un SemanticWeb Service e forma il modello della conoscenza riguardante le informazioniper 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 SWSsono 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 daiservizi stessi (annotation) [43]. Sarà utilizzato un registro semanticoper registrare istanze dell’ontologia per i singoli servizi. L’ontologia diservizio sarà in grado di distinguere tra informazioni utilizzate per ilmatching durante la fase di ritrovamento ed altre utilizzate durante lafase d’invocazione del servizio. In aggiunta, la conoscenza di dominiopuò anche essere pubblicata o collegata all’ontologia dei servizi.


• Il ritrovamento (discovery) di servizi consiste nel matching semanticotra la descrizione della richiesta di un servizio e la descrizione di unservizio pubblicato. Le query coinvolgono il nome del servizio, l’input,l’output, le pre-condizioni e altri attributi che possono essere costruitie utilizzati per la ricerca all’interno del registro semantico. Il matchingpuò essere fatto anche a livello di task da compiere o di obiettivi daraggiungere, seguito da una operazione di selezione tra i servizi chesi occupano di risolvere uno specifico task. Nel caso in cui ci sia piùdi un servizio corrispondente alla richiesta, sarà necessaria una fasedi selezione (selection). Attributi non funzionali come ad esempio ilcosto 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 requestere un provider in modo automatico, ma questo richiede che anche iservizi stessi siano basati su conoscenza [4, 24, 9].

• I meccanismi di composizione (composition) [5] permettono di definireSWS in termini di altri servizi più semplici. Un workflow che esprimela composizione di servizi atomici può essere definito nell’ontologia deiservizi utilizzando appropriati costrutti di controllo. La composizionedinamica può anche essere vista come un approccio per la richiesta delservizio nel quale i servizi atomici richiesti per risolvere una richiestasono individuati e composti “al volo”. Questo però richiede un invokerche si occupi del matching [25]tra l’output del servizio atomico e l’inputdel 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 validatoin base all’ontologia di dominio, ed infine il servizio può essere invocatoo può essere eseguito un workflow sulla base di tutto ciò che è statofornito fino a questo punto. E’ anche importante il monitoraggio dello


stato del processo di decomposizione e di notifica al richiedente nel casoin cui avvengano delle eccezioni;

• il deployment di un Web service da parte di un provider è indipendentedalla pubblicazione della sua descrizione semantica poiché lo stesso Webservice può essere utilizzato per scopi differenti. L’infrastruttura deiSWS, però, può fornire delle agevolazioni per il deployment istantaneodel codice a partire da una descrizione semantica;

• la gestione delle ontologie (ontology management) di descrizione deiservizi è un’attività chiave per i SWS poiché garantisce che le descrizionisemantiche dei servizi siano create, riutilizzate e manipolate all’internodel Semantic Web.

Da un punto di vista architetturale, i SWS sono definiti come un insieme dicomponenti che si occupano di realizzare le attività descritte sopra, con allabase dei meccanismi per la gestione della sicurezza.

Le componenti precedentemente descritte includono: un reasoner, unregister, un matchmaker, un decomposer ed un invoker:

• il reasoner è utilizzato durante tutte le attività e fornisce il supportoai meccanismi di ragionamento necessari per interpretare le descrizionisemantiche 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 durantela fase di discovery e di selezione dei servizi;

• il decomposer è la componente richiesta per l’esecuzione del modello dicomposizione dei servizi composti;

• l’invoker si occupa di mediare tra il requester (o il decomposer) e ilprovider al momento dell’invocazione del servizio.


L’ontologia di descrizione del servizio è un’altra dimensione con cui è possibiledefinire i SWS. Essa descrive le caratteristiche del servizio e le restrizioniapplicate al suo utilizzo.

L’ontologia dei servizi integra tutte le informazioni definite attraverso glistandard dei Web service con la conoscenza di dominio. Questa generalmenteinclude:

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

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

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

• informazioni correlate al task o al goal;

• conoscenza di dominio che definisce, ad esempio, la tipologia dell’inputdi 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’ontologiautilizzata per descrivere i SWS potrà contare sull’espressività e sul potereinferenziale del linguaggio ontologico supportato dal Semantic Web.

3.3 Annotazione semantica

Le specifiche dei Web service sono oggi basate su standard che ne definisconosolo le caratteristiche sintattiche. Sfortunatamente, ciò non è sufficiente, dalmomento 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, aggiungendoad 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 ogniprogramma (in qualsiasi linguaggio) può esporre Web Service.

Tuttavia è indispensabile, fin dai primi passi della creazione di un WebService, 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 specificastrutturale 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 calcolodella corrispondenza tra: semantica dei dati di ciascun servizio e semanticadei dati del servizio richiesto.

In questo momento non esiste una tecnologia universale riconosciuta cometale per l’annotazione semantica di un Web Service o più in generale didocumenti Web. I due principali attori coinvolti nella sfida della semanticasul Web, aziende ed università, hanno dato vita, talvolta assieme, ad una seriedi linguaggi che nel corso della storia hanno registrato consensi e dissensi.

A prescindere dal tipo di linguaggio utilizzato, in questo momento lostato dell’arte è diviso principalmente in due categorie di strumenti perl’annotazione:

• manuali;

• semi-automatici.

L’attività di annotazione, per sua natura, non può (e forse potrà) mai esserecompletamente demandata ad un calcolatore: l’intervento umano rimaneindispensabile.


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 annotazionesemantica: 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 allevolte strumenti corollari) per modificare opportunamente il codice del docu-mento WSDL. Con l’approccio semi-automatico il tool implementa algoritmidi NLP che suggeriscono all’utente delle possibili associazioni. L’operatore,in tal caso, ha il compito di visionare le associazioni proposte ed accettarleo rigettarle.

La fase di annotazione semantica è particolarmente importante poiché daessa dipende la comprensibilità del documento annotato da parte delle mac-chine. L’intervento umano è attualmente indispensabile poiché è in grado digarantire la coerenza dell’annotazione. Per questa ragione non esistono toolcompletamente autonomi che non richiedono l’intervento dell’utente (toolautomatici).

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, BPELEditor 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 mostraun layout organizzato in 3 colonne. Nella prima sono visualizzati in manieragerarchica tutti i nodi di interesse semantico del file WSDL caricato.

3http://lsdis.cs.uga.edu/projects/meteor-s/index.php?page=04http://lsdis.cs.uga.edu/projects/meteor-s/demo/METEOR-S-9.htm


Figura 3.3.1: Screenshot del tool MWSAF

Nella terza colonna vengono visualizzati tutti i concetti contenuti in unadeterminata ontologia. La colonna centrale viene utilizzata per suggerireil matching tra documento WSDL ed ontologia in base ad un algoritmodi matching che fornisce anche un coefficiente (da 0 ad 1) della pertinenzadell’associazione.

Ogni associazione proposta è corredata da una relativa check-box, agendosulla quale, l’utente può accettare l’associazione proposta o respingerla. Nontutte le informazioni del documento WSDL possono trovare un’associazionecon i concetti espressi dall’ontologia scelta.

Al termine della fase di approvazione dei differenti match proposti dalsistema, è possibile applicare l’annotazione semantica al documento WSDLoriginale 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-inper Eclipse particolarmente utili quando è necessario effettuare il mashupdi diversi Web Service. Uno di questi è quello di Web Service InterfaceMatching5.

5http://www.alphaworks.ibm.com/tech/wssem


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 creandouna mappa di connessione tra essi (vedi Figura 3.3.3). Fu inizialmente creatoper supportare WSDL-S (poi evolutosi in SAWSDL). Utilizza tecniche di In-formation Retrieval [40]: part-of-speech tagging e consultazione automaticadi tesauri in inglese.

3.3.1.2 Tool manuali

Radiant Radiant6 è un tool per l’annotazione semantica di documentiWSDL utilizzando lo standard SAWSDL. Non si tratta di un’applicazionestand-alone ma di un plug-in per Eclipse.

Anch’esso sviluppato dal LSDIS della University of Georgia, visualizzagraficamente i nodi del documento WSDL ed i concetti dell’ontologia diriferimento (vedi Figura 3.3.4).

L’ontologia di riferimento può essere sia locale (in formato OWL) oppure6http://lsdis.cs.uga.edu/Radiant/RadiantDemo/


Figura 3.3.3: Screenshot di IBM Annotation Editor

Figura 3.3.4: Screenshot di Radiant


remota. In questo caso il matching tra i concetti non viene proposto dalsoftware ma gestito manualmente e completamente dall’utilizzatore del tool.

E’ possibile interagire tra gli elementi utilizzando scorciatoie più naturalied 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 colonnacentrale).

Si tratta di un semplice annotatore manuale per documenti WSDL.

WODEN4SAWSDL WODEN4SAWSDL7 è una libreria Java, realizzataed utilizzata da METEOR-S per facilitare la gestione di documenti WSDL2.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 eSAWSDL. Le API sono disponibili gratuitamente attraverso il sito web delprogetto.

SAWSDL4J SAWSDL4J8 è una libreria Java che facilita enormementel’interazione con un documento WSDL ed il suo arricchimento semantico.Queste API si basano sulle precedenti (in termini di tempo) WSDL4J: librerieJava 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 edarricchire documenti WSDL utilizzando SAWSDL (Figura 14).

Il difetto di questo tool è la sua forte connessione con WSMO ed i suoielementi fondanti. Se il file WSDL può essere corredato da annotazioniin SAWSDL, questo deve comunque allacciarsi ad ontologie descritte conWSML.

7http://lsdis.cs.uga.edu/projects/meteor-s/opensource/woden4sawsdl/index.html8http://knoesis.wright.edu/opensource/sawsdl4j/index.html9http://www.wsmostudio.org/


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 leassociazioni da implementare.

SCA Tools per Eclipse Si tratta di un’insieme di plug-in appositamenterealizzati per gestire le informazioni semantiche in Eclipse.

SCA Tool Feature - SAWSDL Support10 è, in particolare, il tool checonsente 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 è possibiletrascinarlo direttamente nel codice del documento WSDL. Il plug-in si pre-occuperà di incollare il codice in formato SAWSDL (utilizzando gli appositeproprietà di estensione).

E’ un tool di annotazione completamente manuale dal momento chespetta all’utente la fase di ricerca dei concetti più adatti.

10http://wiki.eclipse.org/STP/SCA_Project


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 catalogarele parole presenti all’interno di un documento in base al loro significato.

Semplificando, è possibile associare ad ogni parola il significato correttoin base al contesto in cui la parola è utilizzata. L’utilizzo di tale strategia diindicizzazione da parte di un motore di ricerca implica la sua realizzazionein maniera del tutto automatica.

Associare un significato ad una parola è il risultato di un processo chesfrutta una grande quantità di conoscenza nel campo della Natural LanguageProcessing (NLP).

La Figura 3.3.7 mostra schematicamente il processo di elaborazione dellinguaggio naturale all’interno del quale vi sono diverse attività.

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

• Riconoscimento della lingua: viene riconosciuta la lingua del testo, inmodo da poter caricare tutte le risorse linguistiche necessarie ai processisuccessivi.


Figura 3.3.7: Schematizzazione del processo di indicizzazione semantica deidocumenti

• Part-of-speech tagging : viene attribuita ad ogni parola il suo ruologrammaticale (nome, verbo, aggettivo, avverbio,. . . ).

• Stemming : tutte le parole vengono ricondotte alla loro radice (adesempio “toys” diventa “toy”).

• Riconoscimento delle entità: vengono ricercati all’interno del testo inomi propri di città, personaggi celebri, fiumi, mari, date, simboli divaluta, sigle, ecc. . .

• Eliminazione stop word : vengono eliminate le parole che apportanoscarsa informazione, come articoli e preposizioni.

• Word Sense Disambiguation: si cerca di attribuire ad ogni parola ilgiusto 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à utilizzatonel processo di ricerca per poter rintracciare i documenti che contengono unoo più significati. La BOC può essere strutturata in modo differente, ma il suoscopo è sempre quello di contenere informazioni semantiche. Ogni elementodella BOC potrebbe avere una struttura siffatta:


< position, stem, POS − tag, concept, TF/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 significatodella 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( ndoc

cfdoc)), 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 definisconosolo le caratteristiche sintattiche. Sfortunatamente, ciò non è sufficiente, dalmomento 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, aggiungendoad 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 ogniprogramma (in qualsiasi linguaggio) può esporre Web Service.


Tuttavia è indispensabile, fin dai primi passi della creazione di un WebService, 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 specificastrutturale dei dati.

Per effettuare il ritrovamento automatico dei servizi, è necessario asso-ciare la semantica dei dati. Quindi, se i dati coinvolti nel servizio fosseroannotati utilizzando un’ontologia, allora tale semantica dei dati potrebbe es-sere utilizzata per il calcolo della corrispondenza tra: semantica dei dati diciascun servizio e semantica dei dati del servizio richiesto.

In questo momento non esiste una tecnologia universale riconosciuta cometale per l’annotazione semantica di un Web Service o più in generale didocumenti 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 linguaggiche 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 aicontenuti ma anche ai servizi presenti nel Web. Utenti ed agenti softwaredovrebbero essere in grado di ritrovare, invocare, comporre e monitorare lerisorse 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


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

di processo, che fornisce una descrizione dettagliata delle operazioni; ed ilgrounding, che fornisce dettagli su come interagire con il servizio, attraversomessaggi.

Il ServiceProfile specifica le funzionalità di un servizio. Questo concettoè il punto di partenza di alto livello per l’adattamento di un servizio adun modello OWL-S che supporta il retrieval di servizi [40] a partire dallapropria descrizione semantica. Esso descrive il servizio fornendo diversi tipidi informazioni:

• informazioni comprensibili per l’uomo (nome del servizio, descrizionedel 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 daticome 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). Questapeculiarità permette di vedere il servizio come un processo.


Il ServiceModel comunica ad un client come utilizzare il servizio, detta-gliando il contenuto semantico della richiesta, le condizioni che potrebberoportare a particolari conseguenze, e, dove necessario, i passi che compongonoil processo che porta a quei risultati. Esso dunque descrive come richiedere ilservizio 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 modidiversi:

• per effettuare un’analisi più approfondita al fine di verificare se unservizio soddisfa le sue necessità;

• per comporre descrizioni di servizi a partire da servizi multipli al finedi effettuare specifici task;

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

• 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 deipropri processi costituenti. Un processo può essere atomico o composto.Nel primo caso si tratta di una descrizione di un servizio che si aspetta unmessaggio e restituisce un messaggio in risposta; nel secondo abbiamo uninsieme 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 unprocesso fornisce l’informazione al richiedente rispettando un certo numerodi pre-condizioni, che devono tutte essere vere affinché il processo possa es-sere correttamente invocato. Gli effetti di un processo caratterizzano tuttociò 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


utilizzare il servizio). Un “grounding” è un mapping da una specifica astrat-ta ad una concreta di quegli elementi della descrizione del servizio che sononecessari 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 utilizzatoper contattare il servizio);

• per ciascuna tipologia semantica di input o di output specificata nelServiceModel, 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 dirappresentazione (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 aspettirivelanti di unWeb 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 Webservice, che descrive gli aspetti funzionali e comportamentali del Web servi-ce; obiettivi, che formalizzano i desideri dell’utente; mediatori, che hanno loscopo di gestire automaticamente i problemi d’interoperabilità tra differentielementi WSMO.

WSMO agisce come un meta-modello per i Semantic Web Service basatosulla Meta Object Facility (MOF). Descrizioni semantiche che seguono ilmeta-modello di WSMO possono essere definite attraverso il linguaggio WebService Modelling Language (WSML). WSMO enfatizza il ruolo dei mediatoriper superare i problemi d’interoperabilità. I seguenti elementi rappresentanole componenti chiave su cui si basa WSMO:


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 ontologieche forniscono la terminologia per gli altri elementi di WSMO. Un’ontologiaè composta da proprietà non funzionali (l’insieme esistente di proprietà corepredefinite), le ontologie importate, e la definizione dei concetti, relazioni,assiomi, funzioni e istanze dell’ontologia. In aggiunta, questo meta-livellodefinisce gli ooMediator che sono utilizzati per importare tutte le ontologieper le quali i problemi di allineamento, fusione e trasformazione devono essererisolti durante l’importazione.

I Goal sono definiti in WSMO come gli obiettivi che un client può averequando consulta un Web service. Questi sono composti da un insieme diproprietà non-funzionali (da un insieme di proprietà core predefinite), onto-logie importate, mediatori usati, post- condizioni ed effetti. Post-condizionied effetti descrivono rispettivamente lo stato dello spazio delle informazionie del mondo, che potrebbero essere desiderati dal richiedente. Le ontologiepossono essere direttamente importate come la terminologia per definire ilgoal quando non deve essere risolto alcun conflitto. Tuttavia, se è richiestoun allineamento, un merge o la risoluzione di conflitti, essi devono essereimportati attraverso ooMediator.

I Web Services forniscono la descrizione semantica dei Web service, com-prese le proprietà funzionali e non funzionali, così come altri aspetti rilevantiper interoperare con loro. La terminologia richiesta, così come per i goal,può essere importata direttamente oppure attraverso ooMediator quando cisono conflitti da risolvere. In aggiunta, le caratteristiche (capability) e le


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 edeffetti;

• le interfaces che rappresentano le interfacce di un servizio e fornisconodettagli su come opera in termini di coreografia ed orchestrazione.

I Mediators che hanno l’obiettivo di risolvere i problemi di eterogeneità. Imediatori in WSMO sono elementi speciali utilizzati per collegare componentieterogenee coinvolte nella modellazione di un Web service.

Essi definiscono tutti i mapping, le trasformazioni o le riduzioni necessarietra 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 gliooMediator per superare le differenze nella terminologia utilizzate perriferirsi a questi goal. In aggiunta, WSMO permette il linking non solodei goal, ma anche dei goal dei ggMediator, permettendo di conseguenzail 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 dirappresentazione differenti o concettualizzazioni differenti dello stessodominio;

• wgMediators, essi collegano un Web service ad un goal. Questi collega-menti rappresentano il raggiungimento (totale o parziale) del goal daparte del Web service. I wgMediator possono utilizzare gli ooMediatorper 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 possonosorgere nelle situazioni in cui i servizi utilizzano vocabolari differenti.

[Ultima sottomissione al W3C: 3 giugno 2005][Stato: W3C Member Submission]


3.4.3 Web Service Semantic (WSDL-S)

Si tratta di uno standard proposto dal laboratorio LSDIS dell’Università dellaGeorgia in collaborazione con IBM. Tale standard rappresenta un’estensionedel 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 WebService. 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ù grandeprocesso di business.

WSDL-S offre un meccanismo per associare annotazioni semantiche adun Web service descritto mediante l’uso di un documento WSDL. Nella defi-nizione del linguaggio è stato assunto che il modello formale di semantica peril servizio esistesse già. Tali modelli non coinvolgono il documento WSDLpur essendo referenziati all’interno di questo, utilizzando la possibilità diestendere gli elementi canonici del documento.

Il tipo di informazione semantica che è utile per la descrizione di un WebService comprende i concetti definiti dalla comunità del Semantic Web inOWL-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 primacosa, 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 dominioci 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 modellidi dominio già esistenti come UML può alleviare il bisogno di modellareseparatamente la semantica.


In ultima istanza, diventa relativamente facile aggiornare i vecchi tooloperanti sulle specifiche di WSDL: è sufficiente estenderli con un approccioincrementale.

[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 semanticodi 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 modellosemantico, tipicamente definiti all’esterno del documento WSDL, possanoessere 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 daqualsiasi tipo di linguaggio di mapping tra documento e modello semantico.

L’intero standard è stato costruito su solo tre attributi opzionali per itag previsti dallo standard WSDL 2.0 (compatibile 1.1) e da quello XMLSchema. Gli attributi sono (vedi Figura 3.4.4):

• sawsdl:modelreference, specifica l’associazione tra una componente deldocumento WSDL (o XML Schema) e il concetto espresso nel modellosemantico di riferimento;

• sawsdl:liftingschemamapping, specifica il mapping tramite il quale i da-ti definiti in maniera conforme ad uno schema XML possano esseretrasformarti conformemente al modello semantico di riferimento;


• sawsdl:loweringschemamapping, specifica il mapping tramite il quale idati definiti nel modello semantico possano essere trasformati in datiXML.

Di seguito si riporta un esempio di documento WSDL annotato semantica-mente tramite SAWSDL [2]:


<wsdl:descriptiontargetNamespace="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:operationname="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 WSDLoriginale (non annotato).


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 concettopresente nel modello semantico (vedi Figura 3.4.3) scelto come riferimento11.

Ciascuno degli attributi sopra descritti accetta da 0 a più URI per poteressere avvalorato. Nel caso di URI multipli, questi devono essere divisi daspazi.

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 questiviene applicato alla componente in oggetto senza che vi sia la possibilità dispecificare relazioni logiche tra essi.

11L’indirizzo esteso è il seguente http://www.w3.org/2002/ws/sawsdl/spec/ontology/purchaseorder


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 opportunetrasformazioni da XML a modello semantico (lifting) e viceversa (lowering).

Le attività di schemaMapping (lifting e lowering) possono essere descrittemediante diversi linguaggi (XSLT, SPARQL, XQuery); SAWSDL non ponelimitazioni 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 sopratuttonell’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 anchel’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 sulfronte sintattico: è necessario che i Web Service da annotare siano descrittimediante WSDL.

In particolare, SAWSDL è stato costruito come estensione di WSDL 2.0.


Figura 3.4.4: Schema di SAWSDL

E’ altresì possibile, mediante opportuni accorgimenti, utilizzare SAWSDLanche con la precedente versione di WSDL: WSDL 1.1.

Come si evince facilmente dalla Figura 4, SAWSDL offre una base comuneper 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


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 stessomodo 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 adun 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 ampioraggio sul tramite il quale è possibile aggiungere semantica solo a queglielementi 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 documentoWSDL 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 leannotazioni 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 definizionedell’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 sviluppatoripotrebbero propendere per l’utilizzo di RDF a scapito di OWL.


3.5.2 Tecniche di annotazione e linguaggi

In SAWSDL le annotazioni vengono inserite all’interno del documento WSDLe ciò è ragionevole dal momento che esiste una relazione 1 ad 1 tra il servizioweb ed il suo documento WSDL.

La maggior parte dei servizi RESTful sono privi di documenti WSDLcorrelati. La maggior parte di essi è presentata attraverso un documentoXHTML che descrive agli utenti le modalità d’invocazione. In qualche ma-niera il corrispettivo di WSDL per i Web Service è rappresentato da XHTMLper servizi REST (l’analogia è molto lasca).

Il problema dell’XHTML è che questi messaggi vengono scritti perlopiù inlinguaggio naturale: comprensibili agli utenti ma incomprensibili alle mac-chine. Per aggiungere semantica anche alle pagine web classiche (formatoXHTML) è 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 codiceXHTML 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 permettonoai 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 unapagina web, l’indirizzo e-mail o il numero di telefono dei contatti presentinella pagina, in modo da poterle trasferire velocemente nella rubrica.

Ritornando ai servizi REST, le due tecnologie di riferimento per SA-RESTsono 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 attraversouna serie di attributi aggiuntivi (rev, about, typeof, content, property) [8] cheassociati ai tag già noti, simulano le triple soggetto–predicato–oggetto tipi-


che di RDF. In questo modo, lo sviluppatore invece di produrre file RDF peresprimere 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 gratuitamenteRDFa 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#”>...The logical input of this service is anhttp://lsdis.cs.uga.edu/ont.owl#Location_Query object.The logical output of this service is a list ofhttp://lsdis.cs.uga.edu/ont.owl#Location objects.This service should be invoked using an HTTP GET<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”/>

...

3.5.2.2 GRDDL

GRDDL [44], da poco W3C Recommendation, offre una modalità univocaper l’estrazione di classi semantiche da documenti (X)HTML per qualsiasitipo 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 è inserireall’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 generaree manutenere due pagine: quella XHTML e quella di trasformazione.

3.5.3 Stato

SA-REST è un linguaggio nato dalla tesi di dottorato di Jonhatan Lathempresso la University of Georgia.


Figura 3.5.1: Comparazione del numero di pubblicazioni scientifiche perSAWSDL e SA-REST

La definizione e la successiva sottomissione di tale linguaggio al W3C erail 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 dimaturità tale da poter essere sottomesso all’ente di ratifica (vedi Figura ).

Non è difficile prevedere in futuro la realizzazione di una piattaformaunica per l’annotazione di servizi sia REST che SAWSDL [33].


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 introducendomeccanismi 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 delleoperazioni chiave di discovery, selection, composition e invocation. Questosecondo obiettivo, punto focale dell’innovatività del progetto, permetterà diintegrare all’interno di una piattaforma di sviluppo classica, com’è quella inesame, 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 tiposoftware, i quali, unitamente a guide operative e metodologie di approc-cio organizzativo, costituiranno il presupposto per avviare un processo diindustrializzazione e sfruttamento dei risultati di ricerca.

Il primo output consiste in una componente software per l’annotazionesemantica 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 subase 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 diavanzamento e può essere riassunto nella seguente caratteristica di fondo: unapproccio iterativo e incrementale guidato dai casi d’uso.

Sulla base di tale approccio, il processo di sviluppo si articolerà in unaserie di iterazioni, che hanno lo scopo di ridurre progressivamente i rischi difallimento del progetto, a partire da quelli principali (ad es. incomprensionisui 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 dianalisi, la quasi totalità dei requisiti, per poi completarli progressivamentedurante le successive iterazioni. I diversi requisiti verranno pertanto soddi-sfatti in modo incrementale: saranno soddisfatti tutti e sin dal principio intermini di analisi e soltanto successivamente anche in termini di disegno eimplementazione.

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 sistemaguiderà tutte le attività del processo di sviluppo. In particolare i casi d’usocostituiranno la base per la definizione dei requisiti e la loro validazione, ladefinizione dei test di accettazione e la pianificazione dei rilasci in un’otticaincrementale.

Sulla base dell’approccio appena descritto, si stabilisce che per entrambigli output di tipo software previsti dal progetto, l’obiettivo quantitativo daconseguire è rappresentato dalla copertura di almeno l’80% dei casi d’usoindividuati in fase di analisi e del 100% dei corrispondenti requisiti, laddoveprevisti.

In relazione ai due obiettivi che si intendono perseguire, riconducibili


entrambi all’integrazione di funzionalità di annotazione semantica dei webservice nella piattaforma che è alla base del progetto, la difficoltà maggiorenon dipende tanto dall’integrazione di tali funzionalità quanto dal renderleeffettivamente utilizzabili agli sviluppatori.

Le annotazioni semantiche sono rappresentate utilizzando formalismi diprogrammazione logica basate su un paradigma completamente differente daquello dei classici linguaggi di programmazione. Un esempio è la definizionedi una semplice classe utilizzando i due paradigmi. Una classe in un linguag-gio Object Oriented rappresenta l’astrazione di un oggetto e viene definitascrivendo 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 unassioma 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 alquantocomplicata, se non impossibile. Per questa ragione il trend verso cui si stamuovendo la comunità di ricerca è lo studio di metodologie che consenta-no la creazione semi-automatica di annotazioni semantiche partendo dallaprocessazione del linguaggio naturale (NLP).

Nel progetto in questione, lo scenario in cui queste attività di ricercaprendono forma può essere riassunto come segue:

Lo sviluppatore crea un web service con la piattaforma CA Enter-prise Solution Platform SDK descrivendone in linguaggio naturaleparametri e funzione. Egli attiva la funzionalità “annota”, che in-tegra tecniche di NLP, che genera annotazioni semantiche scrittein un linguaggio compliant al Semantic Web sfruttando ontologiegià esistenti. Tali annotazioni potranno essere riutilizzate per larealizzazione di funzionalità complesse (quali l’automazione del


discovery, selection, composition ed invocation di web service) disupporto alla creazione di nuovi servizi all’interno o all’esternodella piattaforma stessa.

La risoluzione del problema dell’automazione di queste funzionalità è vitaleaffinché si possano sfruttare pienamente i vantaggi offerti dall’architetturaSOA (Service Oriented Architecture).

Ad oggi, infatti, un utente che volesse utilizzare i web service è tenutoa conoscere esattamente dove si trovano, selezionare manualmente quelli chesoddisfano 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 diprogrammazione differenti.

In questi casi lo sviluppatore esperto espone le interfacce necessarie ecollega le due applicazioni conoscendo a priori tutte le caratteristiche del-le applicazioni in questione e dei servizi da esse generati. Anche se questafacilitazione per l’integrazione di applicazioni esistenti è un vantaggio nonindifferente, questo rappresenta una minima parte delle potenzialità dell’ar-chitettura SOA. Il principio generale è quello di costruire applicazioni chepossano essere utilizzate via Web sfruttando un’interfaccia standard apertaa qualsiasi soluzione applicativa.

Per realizzare pienamente questa vision è necessario introdurre un li-vello astratto che specifichi il significato, ovvero la semantica, delle featuredei servizi in modo tale da attenuare in modo progressivo le problematicheesposte.

I Semantic Web Service (SWS) si propongono come strumenti atti allarappresentazione di questo livello astratto specificando le modalità con cui èpossibile realizzare infrastrutture in grado di abilitare a pieno l’architetturaservice- 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.


Figura 4.1.1: Architettura del progetto SWOP

Avere a disposizione strumenti automatici in grado di indicare dove sonoi servizi, quale di questi è più consono ai nostri fabbisogni, le composizio-ni possibili per raggiungere i nostri obiettivi e la rilevazione di eventualiproblematiche inerenti la loro concreta invocazione consente allo sviluppato-re indubbi vantaggi in termini di tempo e conseguenti vantaggi in termini dispesa per le aziende. In quest’ottica il progetto si propone di creare strumentiper 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 (vediFigura 4.1.1).

Il servizio UDDI dialoga con l’infrastruttura completa al fine di poteresporre e pubblicizzare opportunamente i diversi servizi annotati.


L’infrastruttura deve contenere una serie di API per l’interazione con idiversi standard coinvolti. In questo caso di tratta di un esempio che prendein considerazione il linguaggio Java e lo standard SAWSDL per annotaresemanticamente i servizi web. Sotto tali ipotesi, le API necessarie sono stateidentificate 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 direttamentetramite 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 sforzisui contenuti piuttosto che sulla struttura del documento WSDL. Talemodulo è 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 lequery 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 tooldi elaborazione del linguaggio naturale. In tal caso è stato appositamenterealizzato SAWA: un tool da me sviluppato all’interno dello SWAP ResearchGroup 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 WSDLe concetti semantici contenuti all’interno di ontologie di dominio;

1http://clarkparsia.com/pellet


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 unalista 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 rispettividocumenti 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 ledescrizioni testuali).

4.2 Annotazione semantica di Web Service

La fase di annotazione semantica prevede un file WSDL in ingresso e lacorrispondente produzione di un file SAWSDL. Tale fase è stata organizzatatenendo ben presente l’intervento umano dello sviluppatore, il quale, oltre adutilizzare l’interfaccia, si riserva la possibilità di indicare quali componentidel servizio web annotare e soprattutto quali suggerimenti circa l’annotazioneaccettare e quali no.

Il modulo di annotazione viene utilizzato dagli sviluppatori presenti al-


l’interno delle aziende clienti di CODEArchitects ed il loro scopo è quello diesporre dei servizi attraverso gli appositi e consolidati ambienti di sviluppo.Al termine della fase di deploy di un classico servizio web, gli sviluppatorihanno ora la possibilità di utilizzare il modulo di annotazione al fine di arric-chire il servizio web appena condiviso di annotazioni semantiche attraversol’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 presentiall’interno di una ontologia di dominio disponibile attraverso un indirizzoURL. Detto ciò, la fase di annotazione, e di produzione del file SAWSDL, siriduce alla ricerca delle classi ontologiche pertinenti.

L’ontologia di dominio (vedi 4.2.2 nella pagina 77) contiene un insieme diclassi che esprimono i concetti pertinenti al dominio applicativo proprio delcontesto nel quale vengono utilizzati i servizi web. Ogni classe è provvistadi una opportuna descrizione, scritta in linguaggio naturale (inglese), che neillustra il suo significato.

L’algoritmo di suggerimento delle annotazioni semantiche, SAWA, non faaltro che calcolare la similiratà tra le due descrizioni:

1. descrizione in lingua inglese inserita dallo sviluppatore all’avvio del tooldi 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 ontologichepresenti nell’ontologia[22]. Tale computazione produce una lista di classi(vedi Figura 4.2.2 nella pagina seguente) ordinabile in funzione del punteggiodi similarità semantica calcolato. Così facendo, in accordo ad una politica difiltraggio, 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


Figura 4.2.2: Lista ordinata di classi ontologiche semanticamente simili


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 diannotazione, CODEArchitects Annotation Tool, e chiariscono la sequenzaoperativa del software.

Sulla scorta dei mockup iniziali, l’azienda partner ha provveduto a realiz-zare un’interfaccia software in ambiente Microsoft Presentation Foundationche dialogasse con il modulo di annotazione via web. L’interfaccia graficarealizzata ha quindi le seguenti funzionalità:

• caricare un file WSDL 1.1 o 2.0 ed inviare una richiesta al modulo diannotazione remoto;

2http://www.foreui.com/


Figura 4.2.4: Mockup GUI di elaborazione CODEArchitects Annotation Tool

Figura 4.2.5: Mockup GUI risultati di CODEArchitects Annotation Tool


• selezionare ogni elemento del file WSDL ed annotarlo con delle frasiespresse 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’interosistema, su consiglio dell’azienda partner, si è deciso di lavorare su un casodi 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 è quellocommerciale: 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 è propriol’ontologia.

Una ontologia formalizza la conoscenza di un intero dominio in manierache sia comprensibile alla macchina. L’ontologia utilizzata all’interno di que-sto progetto, relativamente al caso di studio concordato, è stata realizzataappositamente from-scratch.

La base di conoscenza generale è suddivisa in ben 6 ontologie specifichead un ambito di competenza ben definito. Pertanto, la base di conoscenza sicompone di:

1. Categories : contiene un’ampia tassonomia di categorie commercialirelative a prodotti e servizi;

2. Business Processes : contiene la classificazione delle funzionalità per leattività specifiche del dominio applicativo;


3. Business Object : contiene i concetti del dominio inerenti l’input el’output dei servizi web;

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

5. SWOP Integration: importa tutte le ontologie precedenti stabilendo lediverse relazioni tra classi;

6. SWOP : estende l’ontologia precedente con la definizione dei web servicepropri del caso d’uso concordato.

L’ontologia in esame non contiene individui ma solo classi, utilizzando gliassiomi 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 primaentità sia uguale alla seconda.

Più formalmente [18], sia E un insieme di possibili entità che abbianocaratteristiche 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 necessariamenteverificare le seguenti tre proprietà:

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

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 coppiaformata 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à algebrichedella funzione di similarità, si tratta di una misura semanticamente moltodiversa.

Facciamo un esempio. L’entità cane e l’entità gatto sono sicuramente dueentità molto in relazione tra loro poiché, ad esempio, si tratta di due animali,due mammiferi, entrambi domestici sebbene non si possa certo affermare chesi tratti di entità simili: un gatto non è un cane.

SAWA, è un algoritmo che misura la similarità sul piano semantico tradue testi espressi in lingua inglese. Sicché esso non misura il loro grado direlazione.

5.1.2 Similarità semantica

Introdotta la definizione formale di similarità e chiarita la differenza con larelazione è opportuno definire cosa si intenda per similarità semantica.


La similarità è una funzione che genera un dato numerico a partire dadue entità complesse a piacere. Per calcolare il coefficiente di similarità èquindi necessario disporre di una metrica di similarità, laddove per metricasi intende

“la legge che dà la distanza tra due punti qualsiasi di unospazio 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 taleragione esistono diverse metriche di similarità ognuna delle quali privilegiaalcuni aspetti piuttosto che altri.

Posto, ad esempio, che si voglia calcolare la similarità tra due vettorigeometrici, esistono inevitabilmente differenti metriche ognuna delle qualipredilige 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 dellinguaggio naturale.

La similarità tra due parole può essere calcolata confrontando i singolicaratteri che compongono la parola oppure confrontando il senso concettualeche esprime la parola.

Nel primo caso, ad esempio, le parole “nano” e “nona” sarebbero moltosimili, sebbene nel secondo caso non lo sarebbero affatto dal momento chesemanticamente si riferiscono a due concetti molto diversi: “persona di bassastatura” e “numero cardinale”.

SAWA utilizza una metrica di similarità basata sul piano semantico.


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 vecchioe 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 (insiemidi documenti molto grandi), di solito opportunamente annotati, al fine diricavare dei modelli che misurino il peso di ciascuna parola all’interno delcorpus.

In letteratura sono note due tecniche di misurazione facenti parte diquesta 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ù ingenerale tassonomie che aiutano ad individuare la corretta rete di relazionisemantiche che collega tutte le parole di una lingua.

Tali tassonomie vengono realizzate da linguisti professionisti e, oltre acontenere le definizioni dei vocaboli, contengono anche informazioni che aiu-tano a risolvere i problemi di polisemia e sinonimia tipici dell’elaborazionedel linguaggio naturale.

Per ogni vocabolo, ad esempio, è disponibile la lista di tutti i tipi gram-maticali (nome, verbo, aggettivo, avverbio) ad esso associabili, unitamenteall’elenco di tutti i sensi ad esso associabili. Questa conoscenza linguistica èresa in una forma machine-processable ed è di grande utilità nello sviluppodi algoritmi di elaborazione del linguaggio naturale.

Una delle tassonomie linguistiche più importanti e vaste per la linguainglese, e non solo, è Wordnet1.

1http://wordnetweb.princeton.edu/


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:

Simlch = −log(lenght

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’interatassonomia.

Lesk Inventata nel 1986, misura la sovrapposizione (overlap) tra le de-finizioni dei due concetti espresse attraverso un dizionario. E’ basata suun algoritmo inventato da Lesk e proposto per risolvere il problema delladisambiguazione dei sensi associati ad una parola.

Wu & Palmer La misura di similarità di Wu & Palmer, introdotta nel1994, misura la profondità dei due concetti all’intero della tassonomia diWordNet e la profondità del concetto genitore comune più vicino (LeastCommon Subsumer) combinandoli nel seguente modo:

Simwup =2 ∗ depth(LCS)

depth(concept1) + depth(concept2)

Resnik La misura di similarità di Resnik, introdotta nel 1995, calcolal’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 incontrareil concetto all’interno del corpus di riferimento:

IC(concept) = −log P (concept)


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

Simlin =2 ∗ IC(LCS)

IC(concept1) + IC(concept2)

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

Simjnc =1

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à traparole. In altri termini restituiscono un valore compreso tra 0 e 1 prendendoin 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 automaticamenteuno score che indichi la loro similarità a livello semantico, andando oltre imetodi 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 esprimerela similarità tra testi come estensione di quella tra parole.

L’algoritmo utilizzato da SAWA è stato proposto da [16] e consente diottenere ottimi risultati in termini di peso computazionale ma anche diperformance operative.

Si introduce una funzione di similarità direzionale (asimmetrica) che mi-sura la similarità del testo Ti rispetto al testo Tj. Tale definizione è utile neicasi in cui siano richieste misure di similarità asimmetriche, laddove cioè:

sim(Ti, Tj) 6= sim(Tj, Ti).


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 riduzionevengono rimosse le cosiddette stop-word (punteggiatura, articoli, verbi comu-ni, numeri) lasciando solo nomi, verbi, avverbi e aggettivi. L’informazionesul tipo grammaticale di ogni parola viene conservata.

Fatto ciò, si procede a seconda del tipo grammaticale alla ricerca dellaparola più simile all’interno del testo da confrontare. Dopo aver trovato,per ogni tipo grammaticale, la contro-parola più simile si moltiplica la suasimilarità (word-to-word similarity) con la frequenza della parola all’internodel corpus di riferimento. Tale procedimento viene eseguito per ogni tipogrammaticale e per ogni parola presente. Il tutto viene ponderato in basealla frequenza totale delle parole presenti nel documento di riferimento ai finidel calcolo della similarità.

La rappresentazione formale è la seguente:

sim(Ti, Tj)Ti=

∑pos

(∑

wk∈{Tipos}(maxSim(wk) ∗ idfwk

))∑wk∈{Tipos}

idfwk

Questa formulazione, che garantisce un risultato compreso tra 0 ed 1,è una misura di similarità asimmetrica, in questo caso calcolata rispetto altesto Ti. Per rendere simmetrica tale formulazione è sufficiente calcolare lamedia aritmetica delle similarità rispetto ad entrambi i testi Ti e Tj, nelseguente modo:

sim(Ti, Tj) =sim(Ti, Tj)Ti

+ sim(Ti, Tj)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-


za, analizzando due testi restituisce un coefficiente di similarità compreso tra0 ed 1.

L’algoritmo è definito utilizzando una metrica di similarità tra paroleintrodotta da Lin e viene impiegato per suggerire le classi ontologiche che piùsono simili alla descrizione in linguaggio naturale fornita dagli sviluppatoriper ciascun elemento da annotare.

SAWA elabora in input la descrizione di ciascuna classe con la descrizionedi ciascun elemento del file WSDL che si desidera annotare. L’algoritmo pro-duce, in corrispondenza di ogni coppia classe-elementoWSDL, un coefficientedi 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 lecoppie 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 nettadicotomia 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 unalibreria open-source realizzata da LinguaTools: DISCO.

Essa implementa l’algoritmo di Lin su corpus appositamente indicizzatiper 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 peril progetto SWOP, sono disponibili tre corpus differenti:


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 al7 luglio 2008, contenente 100 milioni di parole estratte da documentiscritti o trascrizioni di lingua parlata. La dimensione totale dell’indiceè di 1,82Gb.

3. Wikipedia: si tratta della celebre enciclopedia libera in lingua inglesein una versione risalente al 1 gennaio 2008 e contenente tutti i concettipresenti online all’epoca. La dimensione totale dell’indice è di ben6,25Gb.

Al fine di scegliere il corpus più adatto, è stato effettuato un test statisti-co utilizzando ogni corpus e misurando le performance registrate rispettoai punteggi calcolati da uno studio che ha coinvolto soggetti umani nellamisurazione 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 scorepari a 0, 5602. Per tale ragione, all’interno del progetto SWOP, è stato sceltoil corpus Wikipedia.

Il risultato del test è giustificato dalla natura estremamente specifica delcorpus Pub Med e da quella troppo poco folksonomica del corpus BNC, oltreche dalla scarsa dimensione di entrambi rispetto a quella di Wikipedia.

E’ opportuno precisare che vengono messi a disposizione degli utenti sologli indici Lucene dei vari corpus. In altri termini non si ha accesso ai dati deicorpus ma soltanto agli score di similarità e alle frequenze dei termini. Taliinformazioni sono state precedentemente calcolate e raccolte sotto forma diindice.

Qualora si desiderasse modificare anche solo la versione di Wikipedia, adesempio con una più aggiornata, è necessario richiederla ai responsabili delprogetto DISCO.

2http://www.cs.technion.ac.il/˜gabr/resources/data/wordsim353/


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, siprocede alla presentazione dell’algoritmo in forma di pseudo-codice.

La funzione getSimilarity è quella più ad alto livello e consente, in funzionedi un parametro, di calcolare la similarità. Come detto precedentemente(vedi 5.1.2.2 nella pagina 84), l’algoritmo utilizzato fornisce una misura disimilarità direzionale o simmetrica. Il parametro type viene utilizzato perindicare 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 nellafunzione definita sim.

Dopo aver richiesto a DISCO (vedi 5.2.1 nella pagina 86) il numero totaledi parole che compongono l’intero corpus, scompone il primo testo (già prece-dentemente ripulito delle stopword) in un insieme di parole e per ciascuna diqueste cerca quella più simile nel secondo testo. Tale ricerca viene effettuatadalla procedura getWordwithMaxSimilarity.

Le frequenze di tutte le parole più simili a quelle del primo testo vengonosommate e memorizzate all’interno della variabile sumWordsFrequencies. Lostesso computo si esegue per i coefficienti di similarità massimi di ciascunaparola memorizzandolo nella variabile score.

Il risultato finale viene calcolato come il rapporto tra la variabile score ela 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 paginaseguente) prevede un numero di accessi all’indice, così calcolato:


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)] /2else if type = 1 then

result = sim(T1, T2)end if

sim(T1, T2):numWords = DISCONumberOfWordssumWordsFrequencies = 0score = 0for all words w ∈ getWords(T1) do

frequencyTerm = DISCOFrequency(wordA)wordFrequency = numWords/frequencyTermif frequencyTerm 6= 0 then

maxSimilarity = getWordwithMaxSimilarity(w, T2)if maxSimilarity > 0 then

score = score + (maxSimilarity ∗ wordFrequency)sumWordsFrequencies = sumWordsFrequency + wordFrequency

elsereturn : 0

end ifend if

end forreturn : (score/sumWordsFrequencies)

getWordwithMaxSimilarity(word, Text):max = 0for all words w ∈ getWords(Text) do

sim = DISCOSimilarity(word, w)if sim > 0 thenif max < sim then

max = simend if

end ifend forreturn : max


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

che nel caso della similarità simmetrica o adirezionale diventa doppiorispetto alla formula.

Supponendo di voler suggerire annotazioni per un servizio web in uncontesto siffatto (caso verosimile):

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

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

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

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

chiamateSAWA = #elementiWSDLdescritti ∗#classiOntologiche.

Da tale formulazione risulta che per il suggerimento delle annotazio-ni semantiche occorrerebbero ben 11000 chiamate a SAWA. Il tempo dicomputazione è espresso nel seguente modo:

tempoComputazione = tempoAccessoIndice∗(accessiIndice∗chiamateSAWA).

Ne consegue che:

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

chiamateSAWA = 10 ∗ 1100 = 11000

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


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. Loscenario 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 possonoessere previsti nella formula.

5.2.4.1 Ottimizzazione

Analizzando le variabili che giocano un ruolo all’intero del computo del tempodi 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 causadella presenza di relazioni tra le classi: si rischierebbe di compromettere lacoerenza 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 scendereal massimo della metà: 4,4 ore al posto di 8,8, sebbene sia un importantepasso avanti, non aiuta.

L’idea quindi è stata quella di ridurre al massimo il numero di accessiall’indice. In particolare, nella formulazione originale SAWA consultava l’in-dice anche per ottenere risultati già calcolati in precedenza. Ecco i casi incui 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 richiestoil 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 parolepresenti all’intero del corpus è un dato che andrebbe chiesto una solavolta, è uno spreco chiederlo ad ogni chiamata dell’algoritmo;


• richiesta della frequenza di termini già noti : esattamente come peril caso delle coppie di termini già note, anche in questo caso è statoallocato in memoria RAM uno spazio che contiene tutte le frequenzedi tutti i termini già richiesti;

Dopo aver implementato queste modifiche, SAWA consulterà l’indice soloquando gli verrà chiesto di computare la similarità o la frequenza di terminimai analizzati. Questo tipo di ottimizzazione rende SAWA un algoritmo conprestazioni via via sempre migliori.

Si consideri che l’ontologia di dominio non cambia per tutta l’esecuzionebatch dell’algoritmo e conseguentemente non cambia neanche il set di pa-role utilizzato per le definizioni dei concetti ontologici. L’introduzione dinuove parole potrebbe avvenire solo per le descrizioni inserite all’interno deldocumento 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 necessariedue consultazioni dell’indice, adesso ne è necessaria solo una a patto che sitratti di una coppia inedita. In altri termini il tempo di computazione dellasimilarità 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 dellasimilarità (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 epregiudicherebbe il risultato finale.

Vieppiù, nel caso del calcolo di similarità di una frase già nota, il tempodi computazione sarebbe tendente allo zero.

Nella figura 5.2.1 vengono evidenziati i tempi di esecuzione per un soloelemento WSDL alla prima esecuzione di SAWA. Il momento della primaesecuzione è quello più lento poiché ogni coppia di termini è inedita e tuttii dati devono essere recuperati dall’indice. Come si evince dalla figura, purtrattandosi della prima esecuzione, il vantaggio è già del 77,45%.


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

Dopo un numero adeguato di richieste l’algoritmo registrerà tempi via viasempre inferiori fino ad assestarsi ad un valore fisso che dipende unicamentedalla velocità della macchina server. Il guadagno stimato è prossimo al 99%dal momento che non sarà più necessario accedere agli indici. A quel punto iltempo di accesso all’indice diventa trascurabile e le 8,8 ore iniziali diven-tano 1 minuto al massimo. Tempo necessario ad effettuare le operazionidi 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 13parole 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 di11 minuti.

Con l’algoritmo ottimizzato, alla prima esecuzione si scende già a 4,39secondi per un singolo elemento. Un miglioramento del 93,35% soltanto


alla prima esecuzione. Il margine di miglioramento non può che aumentaregrandemente 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. Ilprimo 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’interapiattaforma 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 (ognicoppia consiste in due frasi che sono le definizioni, prese dal corpus R&G, di65 coppie di parole). Il dizionario utilizzato era il Collins Cobuild (Sinclair,2001). Per ogni coppia di frasi, è stata fornito il coefficiente di similarità dei32 soggetti partecipanti, il quale varia da 0.0 (le frasi sono completamentescorrelate 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 finedi mantenere le frasi per le quali i coefficienti dei soggetti umani creasseromeglio una distribuzione sui valori attribuiti. Per questa ragione, SAWA èstato testato sullo stesso sottoinsieme, descritto da Li et al. [31]. In questoesperimento, 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.

3Il data set è disponibile pubblicamente su http://www2.docm.mmu.ac.uk/STAFF/J.Oshea/


Dopo un’attenta fase di ricerca, soltanto questi 4 sistemi pare siano statitestati su questo data set. In Tabella 5.1 si presenta il sotto-insieme dicoppie di frasi selezionate da Li et al [31] e i rispettivi coefficienti restituitidai 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 ilreport 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. Neirisultati è stata inclusa anche la versione asimettrica di SAWA, per la qualesi tiene conto dell’ordine degli argomenti nella funzione di similarità. Questaversione di SAWA è indicata in tabella con la voce “SAWA directed”. L’obiet-tivo di tale esperimento è quello di individuare eventuali carenze nel metodoutilizzato per calcolare SAWA simmetrico: la media aritmetica.

Come i risultati indicano, SAWA ha registrato la migliore correlazionetra tutti gli algoritmi presentati in Tabella 5.2. Stando ai risultati, l’utilizzodella misura di similarità semantica simmetrica è migliore rispetto a quellaasimettrica ed avvalora la tesi secondo la quale la media aritmetica sia unbuon metodo di calcolo. Per concludere, i risultati indicano chiaramente cheSAWA 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 diclassi ontologiche ed un insieme di descrizioni estrapolate da un file WSDLdi esempio.

Più precisamente l’algoritmo è stato testato su 31 definizioni di classiontologiche aventi in media 9 parole ciascuna e 10 descrizioni di elementiWSDL aventi in media 13 parole ciascuna.

I risultati che seguono ritraggono alcuni screenshot catturati da una classedi test. Ogni screenshot mostra la descrizione dell’elemento WSDL per ilquale suggerire le classi ontologiche, seguito da una tabella che contiene tutte


Coppie di frasi Umani STATIS LSA STS Omiotis SAWA

1.cord:smile 0.01 0.329 0.51 0.06 0.1062 0,10505.autograph:shore 0.005 0.287 0.53 0.11 0.1048 0,04269.asylum:fruit 0.005 0.209 0.505 0.07 0.1046 0,061113.boy:rooster 0.108 0.53 0.535 0.16 0.3028 0,229417.coast:forest 0.063 0.356 0.575 0.26 0.2988 0,386321.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,278729.bird:woodland 0.013 0.335 0.505 0.12 0.1074 0,243333.hill:woodland 0.145 0.59 0.81 0.29 0.4946 0,412337.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,138147.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,404649.hill:mound 0.293 0.739 0.54 0.15 0.5701 0,276550.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,357052.grin:smile 0.485 0.493 0.695 0.32 0.5987 0,585953.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,630655.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,842357.forest:woodland 0.628 0.7 0.75 0.26 0.612 0,657158.implement:tool 0.59 0.753 0.83 0.51 0.7392 0,639959.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,594561.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,559663.automobile:car 0.558 0.639 0.87 0.52 0.7889 0,714564.midday:noon 0.955 0.998 1 0.93 0.9291 1,000065.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 calcolodalla similarità.


Spearman’s ρ Pearson’s r

STATIS 0.8126 0.8162LSA 0.8714 0.8384STS 0.838 0.853

Omiotis 0.8905 0.856SAWA 0.8915 0.8740

SAWA directed 0.8460 0.8437

Tabella 5.2: Coefficienti di correlazione di Spearman e Pearson rispetto aquelli umani.

le classi analizzate con i rispettivi score di similarità calcolati da SAWA. Irisultati 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 restanticoncetti 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. Adesempio, nella Figura 5.2.2 vi sono i primi 5 risultati che ottengono scorenumericamente 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 casoillustrato in Figura 5.2.4 è simile al primo, sebbene il gruppo sia compostoda 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 performancein termini di efficacia.

Con riferimento ai possibili metodi di filtraggio dei risultati illustrati apagina 86 ritengo che sia più opportuno procedere ad un cut-off variabilecalibrato sul gruppo, calcolato attraverso la seguente formula:


Figura 5.2.2: Risultati di SAWA 1





Figura 5.2.5: Risultati della Figura 5.2.3 riportati su grafico


Figura 5.2.6: Risultati della Figura 5.2.4 riportati su grafico

maxk∈[1,n]

(score(k)− score(k + 1)

score(k))

dove k è la posizione dell’ultimo elemento da includere tra i risultati darestituire ed n è il numero classi ontologiche calcolate.

5.2.6 Architettura di rete

SAWA è stato pensato per essere utilizzato in maniera remota. La sceltadel paradigma SOA è stata necessaria al fine di separare efficientemente lecompetenze di ricerca & sviluppo dell’azienda partner da quelle in capo alSWAP Research Group.

Tale assunzione ha consentito di sviluppare SAWA pensandolo come unsoftware di rete, che una volta installato fosse perennemente operativo. Vistala 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 efuture (web service, web page, REST service).

La scelta di anteporre un nodo di rete alle interfacce terminali è statapensata al fine di preservare la sicurezza del software, nonché la possibilità dimanutenere una particolare interfaccia senza dover interrompere l’esecuzionedi SAWA. Uno dei pregi più importanti è che le differenti interfacce possonorisiedere su macchine diverse per meglio bilanciare i carichi di lavoro.

Di seguito si illustrano le caratteristiche di ogni interfaccia implementata.


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 coefficientedi similarità come servizio di rete via indirizzi IP e porta dedicata.

E’ stato implementato tramite la libreria Java Socket e consente di avviarel’algoritmo su una specifica porta (socket) sull’indirizzo IP pubblico del serverche lo ospita.

Il compito del server è quello di rimanere attivo per sempre ed evaderele richieste che giungono di volta in volta. Esso è stato sviluppato utilizzan-do i thread: ogni richiesta è gestita come un thread autonomo, sebbene leinformazioni presenti in memoria RAM siano condivise a tutti i thread. Lascelta del thread consente di migliorare notevolmente le performance di retedell’algoritmo oltre che garantire una maggiore stabilità dello stesso nei casiin cui vi fossero un numero di richieste elevate.

Da un punto di vista grafico, il server si presenta come una sempliceconsole che mostra: il proprio stato, il proprio indirizzo IP e la propria portadi comunicazione.

Al fine di testare le funzionalità di questa interfaccia è stata sviluppata


*-- SAWA Server --------*IP Address: 192.168.20.1Port : 1355Status : 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, MacOS X e Linux, necessaria ad inviare i due testi (vedi Figura 5.2.9), visualizzarelo 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 formadi pagina web.

L’interfaccia online consente di inserire i due testi in lingua inglese e dopo4http://193.204.187.223:8080/sawa/


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 direte


Figura 5.2.12: Pagina web di SAWA su dispositivo mobile

aver confermato visualizza lo score di similarità unitamente al tempo richiestoper l’elaborazione.

Le pagine web sono state realizzate utilizzando codice XHTML 1.1 e CSS2.0 e sono completamente conformi a tali standard.

L’esistenza del sito web consente di utilizzare l’algoritmo da ogni parte delmondo e con qualsiasi dispositivo abilitato alla navigazione web. Di seguitosi 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 GoogleAnalytics5 che consente di monitorare gli accessi e ricavare una serie di utilistatistiche.

5http://www.google.com/analytics/


Attualmente il numero di visite ricevute è superiore a 300, prevalen-temente dall’Italia ma anche da Finlandia, Regno Unito, Francia e StatiUniti.

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 diintegrarsi 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 dauna componente di più alto livello che espone i risultati all’esterno (Annota-tion Service). E’ questa componente a possedere una propria interfaccia comeservizio web. La trattazione dell’Annotation Service esula dal contenuto diquesto 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 direte 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 taleformalizzazione. Si sono altresì evidenziati i pregi e i difetti del principaleprodotto dell’architettura sopra-citata e presentata di conseguenza la teoriache sottende ai Semantic Web Service.

Introdotta la teoria si è passati ad illustrare i diversi strumenti oggigiornoesistenti per la gestione di servizi web semantici, oltre che quelli particolar-mente utili all’annotazione semantica. Il mio lavoro in qualità di membro delprogetto SWOP mi ha visto coinvolto sulla parte più specificatamente di an-notazione dei servizi. E’ per tale ragione che i capitoli 3 e 4 approfondisconosolo la fase di annotazione semantica.

Dopo aver introdotto il progetto e fornito al lettore tutte le informazioniper chiarire il contesto pratico del progetto, si è passati all’introduzione diSAWA. Un algoritmo per il calcolo della similarità semantica tra testi concaratteristiche 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 dasubito 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 libreriaJava 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 diutilizzare i corpus forniti dall’azienda che sviluppa la libreria. Attual-mente, infatti, non c’è possibilità di utilizzare DISCO su un corpusdiverso da quelli forniti e non è nemmeno possibile utilizzare versionipiù aggiornate dei corpus forniti. L’implementazione di un algoritmoad-hoc, anche per il calcolo della similarità tra parole basato anch’essosu Wikipedia aggiornata, potrebbe consentire di abbandonare DISCOper rimpiazzarlo con una componente creata ad-hoc, magari in licenzaopen-source e con una politica di rilascio dei corpus un po’ più aper-ta (anche soltanto pubblicando le specifiche di produzione degli indiciLucene).

• Le interfacce implementate ed attualmente disponibili soffrono di al-cune limitazioni. La prima di queste è che non si prestano ad un usointensivo 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 SAWApuò funzionare su corpus diversi, in diverse lingue. Parametrizzare lascelta dei corpus e/o la scelta delle lingue, nelle differenti interfacce,potrebbe essere d’aiuto in contesti DEMO ma anche operativi. A talproposito sarebbe opportuno non limitarsi a servizi web ma aggiungereun 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 sottolicenza open-source.

• Implementazione del postagger: attualmente SAWA non integra alcu-na tecnologia di part-of-speech tagging. Ciò rende l’implementazioneeffettiva dell’algoritmo, una versione ridotta di [16]. Le ragioni allabase di tale esclusione sono da ricercare nei vincoli di progetto lega-ti alle performance dell’algoritmo. E’ possibile integrare tecnologie dipart-of-speech tagging al fine di implementare una versione totalmenterispondente dell’algoritmo di [16].

• Condurre uno studio statistico approfondito che misuri le perfoman-ce dell’algoritmo valutandole sperimentalmente in termini di efficacianel contesto di riferimento. La natura dell’algoritmo fa si che servaun corpus ad-hoc di coppie di testi per le quali è già fornito un va-lore di similarità soggettivo. A tal proposito, potrebbe essere estesal’interfaccia web chiedendo agli utenti, oltre alla coppia di testi per iquali misurare il coefficiente di similarità, anche una stima (da 0 a 5ad esempio) di quanto percepiscono simili i due testi forniti in input.Il sistema consentirebbe di ottenere una base di dati sufficientementeampia (dopo un adeguato periodo) dalla quale estrarre con tecnichenumeriche avanzate degli indici di correzione degli score in funzione delcontenuto.

Bibliografia

[1] An information-theoretic definition of similarity. Morgan Kaufmann,San Francisco, CA, 1998.

[2] Creating Bioinformatics Semantic Web Services from Existing WebServices: 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 onrecommender systems. Jun 2010.

[5] D. Ardagna and B. Pernici. Adaptive service composition in flexibleprocesses. Software Engineering, IEEE Transactions on, 33(6):369–384,2007.

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

[7] S. McCarron S. Pemberton B. Adida, M. Birbeck. Rdfa in xhtml: Syntaxand 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 forextending 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 onworkflow 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, andWojciech H. Zurek. Information distance. Jun 2010.

[12] Allen Brown and Hugo Haas. Web services glossary. World Wide WebConsortium, 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 Servicesand Web Process Composition. Springer, 2005.

[15] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Webservices description language (WSDL) 1.1. W3c note, World Wide WebConsortium, 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 Transactionson, 21(11):1532–1543, November 2008.

[18] C. d’Amato, N. Fanizzi, and F. Esposito. A semantic similarity measurefor expressive description logics. In A. Pettorossi, editor, Proceedingsof Convegno Italiano di Logica Computazionale (CILC05) 21-22 June2005, 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. InMuhammad Ali Babar and Ian Gorton, editors, ECSA, volume 6285 ofLecture Notes in Computer Science, pages 360–367. Springer, 2010.

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

[21] Jochen Gruber. Semantic description of parameters in web serviceannotations. CoRR, abs/cs/0609132, 2006.

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

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

[24] R. Studer J. Davies. Semantic Web Technologies: Trends and Researchin Ontology-Based Systems. Chichester, 2006.

[25] M. Klusch, P. Kapahnke, and I. Zinnikus. Sawsdl-mx2: A machine-learning approach for integrating semantic web service matchmakingvariants. In Web Services, 2009. ICWS 2009. IEEE InternationalConference 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, pages31–57. 2008.

[27] Peter Kolb. Disco: A multilingual database of distributionally similarwords. 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 webservices. 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 corpusstatistics. IEEE Trans. Knowl. Data Eng., 18(8):1138–1150, 2006.

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

[33] Maria Maleshkova, Jacek Kopecký, and Carlos Pedrinaci. Adaptingsawsdl for semantic annotations of restful services. In Robert Meersman,Pilar Herrero, and Tharam S. Dillon, editors, OTM Workshops, volume5872 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 andnumerical methods. CoRR, abs/0909.4888, 2009.

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

BIBLIOGRAFIA 114

KES-AMSTA’08: Proceedings of the 2nd KES International conferenceon 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 basedon similarity evaluation. IEEE Transactions on knowledge and dataengineering, 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, pages1634–1638, 2005.

[43] S. Handshuh et al. S. Agarwal. Annotation, composition and invocationof 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. IEEEInternet Computing, 11:91–94, 2007.

[46] Amit P. Sheth, Karthik Gomadam, and Ajith Ranabahu. Semanticsenhanced 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, andAdina Sirbu. Simplifying the web service discovery process. In SeMMA,pages 31–45, 2008.

BIBLIOGRAFIA 115

[48] Rudi Studer, V. Richard Benjamins, and Dieter Fensel. Knowledgeengineering: 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. RetrievedFebruary 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. Textrelatedness 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, November2004.

[53] W3C. SOAP Version 1.2 Part 1: Messaging Framework (SecondEdition), 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. W3CRecommendation, W3C - World Wide Web Consortium, August 2002.

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

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

Documents

Sviluppo di un algoritmo di similarità a supporto dell'annotazione semantica di Web Services