PROGETTAZIONE E SVILUPPO DI UN FRAMEWORK DI SUPPORTO IN AMBIENTE AZIENDALE SU...
TESIPOLI
1. POLITECNICO DI MILANO
V Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Dipartimento di Elettronica e Informazione
SEMANTIFICAZIONE E CLASSIFICAZIONE
DI WEB SERVICE TRAMITE
ONTOLOGIE OWL
Relatore :
Prof. Marco Colombetti
Co-Relatore :
Ing. Mario Arrigoni Neri
Tesi di Laurea di :
Vicentini Luca Matricola 680302
Anno Accademico 2011/2012
1
2. A Mio Fratello
“Quisque Est Faber Suae Fortunae”
Luca
Desidero ringraziare il mio Professore e Relatore Prof. MarcoColombetti e il mio Co-Relatore l'Ing. Mario
Arrigoni Neri per il loro aiuto e la loro grandissima disponibilità dimostratami durante tutto il periodo di tesi, ho
imparato molto da questo lavoro.
2
3. Indice:
1.Introduzione e Motivazioni …......…………………………………………………………………. 5
1.1. Tecnologie Utilizzate
1.1.1. XML/RDF
1.1.2. WSDL
1.1.3. Ontologie
1.1.3.1. Owls Upper Ontology
2. Cap. 1 ……………………………………………………………………………………………. 14
2.1. Idea di progetto
2.2. Struttura tesi
2.3. Ontologia
2.3.1. Ontologia di Dominio
2.3.2. Ontologia di Servizio
2.4. Semantificazione
2.5. Classificazione
2.6. Stemmer
2.7. WordNet & Tabelle di Valutazione
2.8. Funzione di Fitting
2.9. Repository & Logging
2.9.1. Logging
2.9.2. Repository
3. Cap. 2 ……………………………………………………………………………………………. 39
3.1. Architettura
3.1.1. Database
3.1.2. Logica
3.2. Software & Deployment
4. Risultati Sperimentali ………………………………………………………………………….. 46
5. Conclusioni ….…………………………………………………………………………………. 54
6. Sviluppi Futuri ………………………………………………………………………………….. 55
7. Glossario ………………………………………………………………………………………... 57
8. Bibliografia ……………………………………………………………………………………… 58
3
4. Indice delle figure:
1.1 Top Ontology
1.2 Service Profile
1.3 Service Model
2.1 WorkFlow generale di interazione tra le classi principali
2.2 OntoGraf owl:Thing
2.3 OntoGraf della classe owl:location
2.4 OntoGraf della classe owl:identifiers
2.5 OntoGraf della classe owl:duration e owl:weather
2.6 OntoGraf owl:encoding
2.7 Schema importazioni Ontologia di Dominio e OWLS
2.8 Built-In DataType Hierarchy
3.1 Class Diagram del sistema
3.2 Sequence Diagram ciclo generale
3.3 Sequence Diagram semantificazione e classificazione
3.4 deployment diagram
4.1 Tabulato PortType
4.2 Tabelle di classificazione GmlTimeSeriesService
4.3 Tabelle di classificazione servizio LatLonListSubgridService
4.4 Classificazione di GmlTimeSeriesService
4.5 Classificazione di LatLonListSubgridService
4
5. 1. Introduzione e Motivazioni
Tra le tecnologie che hanno rivoluzionato il mondo, internet, ricopre di sicuro un primissimo
posto. Ogni giorno, centinaia di migliaia di persone interagiscono con questa realtà virtuale nella
quale sono condivise una quantità infinita di dati, per lavoro, divertimento o studio.
L'interpretazione di ogni dato usufruibile dal web, in questo momento, è quasi del tutto affidata
alla supervisione dell'occhio umano facendo si che si perda moltissimo tempo nella ricerca di
documenti ben precisi a causa, appunto, della loro vastità e, intrinseca, poca raggiungibilità. I
documenti infatti, nonostante siano presenti in internet, non sono interamente raggiungibili, in
quanto i motori di ricerca attuali si basano su algoritmi di page Ranking che ottimizzano la ricerca
solamente per link che vengono spesso utilizzati o sponsorizzati all'interno di altre pagine web,
creando quindi una rete di pagine privilegiate. Il web semantico si pone nell'ottica di rendere
machine-readable tutte le pagine web scritte con un particolare linguaggio composto da metadati
estremamente complessi e di difficile lettura, ma estremamente semplici, o comunque,
processabili da una agente automatico. Questa tesi si pone nell'ottica di trovare una particolare
serie o categoria di servizi su internet senza basarsi sugli standard UDDI1 oramai privatizzati e di
difficile utilizzo, tentando una classificazione degli stessi basandosi su di una serie di ontologie
create ad hoc per definire un ambito applicativo del software. Tutto ciò può essere di facile
adattamento a diversi ambiti applicativi, quale per esempio un ambito industriale che abbia una
realtà di servizi molto ampia o un particolare motore di ricerca che basi i propri risultati su di un
dominio di ricerca, non più basato su di una singola parola o frase, ma, bensì, su di una serie di
regole logiche e concetti ben precisi definiti appunto dalle nostre ontologie. Se si riuscisse a creare
una realtà simile, si potrebbero creare ricerche altamente selettive, si potrebbe usufruire di
qualsiasi tipo di servizio con molta più facilità e velocità rispetto agli standard attuali e sopratutto
ci si potrebbe permettere di comporre tali servizi al solo fine di rendere più flessibile la struttura
stessa delle nostre pagine web, il tutto in maniera automatica e sopratutto senza la necessaria
supervisione dell'occhio umano.
1 UDDI ( Universal Description Discovery and Integration registry)
5
6. Possiamo sottolineare il fatto che la ricerca in quest'ambito è completamente aperta. Infatti si è
svolto il lavoro con una documentazione minima in quanto la maggior parte dei lavori svolti in
questo settore sono sopratutto sperimentali e a volte mal documentati. Questo è un motivo in più
per svolgere ricerca in un ambito in completo e continuo sviluppo.
1.1 Tecnologie utilizzate
1.1.1. XML/RDF
Precedentemente abbiamo parlato del concetto di Web Semantico. Questo tipo di rete è stato
introdotto come prospettiva da uno degli inventori della attuale rete internet Tim Berners-Lee nel
2001 su di un articolo pubblicato nello "Scientific American". Questa nuova concezione si
propone di integrare le pagine web con annotazioni e metadati al fine di rendere le stesse
consultabili in maniera automatica da agenti razionali, le ontologie, in questo senso, sono la chiave
in grado di azionare la tecnologia del web semantico dando una parvenza di ragionamento umano
ad un'elaborazione completamente senza supervisione umana. Per far ciò, il linguaggio utilizzato
deve essere rigoroso e comprensivo di tag per delimitare i dati e indirizzi standard per rendere
unici gli elementi e gli attributi in un'istanza XML2. Il linguaggio XML, in questo senso, ha
apportato grandi rivoluzioni, sopratutto con l'avvento di standard come XSD3, ovvero XML
Schema Definition, che permette di definire documenti in termini di vincoli, definendo quali
elementi e attributi possono comparire, definisce i loro tipi di dato e le relative relazioni tra gli
stessi. Esso è molto più potente di documenti come i vecchi DTD (Document Type Definition) e
inoltre è completamente integrato in XML. Il passaggio, a questo punto, da un web machine-
2 XML (Extensible Markup Language) : http://www.w3.org/XML/
3 XSD (XML Schema Definition) : http://www.w3.org/XML/Schema
6
7. readable a machine-understandable è l'introduzione di ulteriori dati, sui metadati, che permettano
ad un agente generico di "capire" ciò che viene processato. RDF4 in questo senso, colma molti
dei limiti posti da XML.
1.1.2. WSDL
I WSDL5 sono documenti scritti in un linguaggio XML-based che fornisce un modello per la
descrizione di servizi web non semantificati. Questo sta a significare che un servizio descritto in
linguaggio WSDL avrà si una struttura standard e caratterizzata dal linguaggio XML, ma non sarà
ottimizzato per essere processato autonomamente da un agente automatico. Questo tipo di
documenti è anche utilizzato per descrivere le operazioni che possono essere effettuate da un
certo tipo di servizio ed anche la sua localizzazione. La maggior parte dei tool di sviluppo, allo
stato dell'arte, supporta la struttura WSDL alla versione 1.1, sarà quindi la struttura di questo tipo
di versione che si andrà a descrivere nel corso dell'elaborato. La struttura di un WSDL può essere
esemplificata utilizzando sei componenti principali:
1. <type> : questo elemento è utilizzato per definire il tipo di elemento XML semplice o
complesso utilizzato nello scambio dei messaggi definiti nel documento.
2. <messages> : definisce una rappresentazione astratta dell'informazione trasmessa.
Tipicamente un messaggio contiene uno o più parametri, ognuna di queste parti è associata
tramite la definizione dei tipi sopra citati.
3. <portType> : è un componente importante all'interno dei documenti WSDL in quanto
vengono definite al suo interno le operazioni svolte dal web service stesso. Ognuna delle
operazioni definite all'interno del portType è accompagnata da input e output associati al
relativo messaggio che veicola l'input o l'output. I port type inoltre definiscono il tipo di
pattern utilizzato per scambiare messaggi tra lo user e il server dove è locato il servizio. Essi
4 RDF (Resource Description Framework) : http://www.w3.org/TR/REC-rdf-syntax/
5 WSDL (Web Service Description Language) : http://www.w3.org/TR/wsdl
7
8. sono di quattro tipi:
3.1. One-Way : il servizio riceve un singolo messaggio di input.
3.2. Request-Responce : il servizio riceve un messaggio di input e risponde con un messaggio
di output.
3.3. Solicit-Responce : il messaggio invia. per primo, un messaggio di output e aspetta la
ricezione di un messaggio di input in risposta.
3.4. Notification : il messaggio invia un messaggio di risposta senza aspettare nulla in
risposta.
Data la struttura dei WSDL analizzati, ci si è resi conto che il pattern ricorrente
all'interno dei documenti in uso era un request-responce, cosi da porter costruire servizi
analoghi, tutti con la stessa struttura atomica, non complessa.
4. <operation> : racchiude le operazioni svolte dal servizio web, con i relativi input e output in
modo tale da poter autorizzare l'agente automatico che ne richiede l'utilizzo ad usufruirne nel
migliore dei modi. Questa è anche la sezione principale analizzata dall'applicativo sviluppato
in quanto ogni operazione, come verrà sottolineato in seguito, verrà trasformata in una classe
owl opportunamente classificata all'interno della nostra ontologia di servizio.
5. <binding> : specifica il protocollo di comunicazione e il formato dati per ogni operazione e
messaggio definito in un particolare elemento del portType.
6. <Service> : è un'operazione composita che aggrega multiple porte aggregate o funzioni. In
questa sezione è contenuto anche l'indirizzo al quale si può effettuare il retrieving del servizio
stesso.
Dato il formato standard di questo tipo di documenti, è facile creare del codice, implementato in
qualsiasi tipo di linguaggio, che legge questo particolare tipo di strutture dati.
8
9. 1.1.3. Ontologie
L'analisi e lo studio dell'upper ontology OWLS è stata affrontata in maniera approfondita per la
costruzione della parte di semantificazione e, sopratutto, per collocare in maniera opportuna il
servizio trovato su internet nella nostra ontologia di servizio. Essa è formata da tre macro aree
che rappresentano la struttura essenziale nella quale è suddiviso un web service. Ciascuna macro
area definisce e descrive un particolare aspetto ti tale servizio:
1) Service Profile : descrive cosa il servizio offre a chi ne vuole usufruire e informazioni su chi lo
ha creato.
2) Service Model : descrive la struttura vera e propria del servizio con informazioni essenziali per
capire come usarlo
3) Service Grounding : definisce i metodi in cui si può interagire con il servizio, semantificando
all'interno di questa area, i legami tra il web service originale e il documento WSDL che lo
rappresenta.
Figura 1.1 Top Ontology
9
10. Service Profile
La sua struttura è molto semplice ma di fondamentale importanza per qualunque agente
automatico che vuole utilizzare il servizio. essa descrive il servizio in termini di IOPE (Input,
Output, Precondizioni, Effetti) aggiungendo anche informazioni riguardanti chi provvede al
servizio stesso.
Figura 1.2 Service Profile
La figura rappresenta le relazioni tra le Object Property che definiscono le, appunto, proprietà del
servizio e i parametri. Come possiamo notare la descrizione è orientata a far capire ad un
ipotetico user cosa, un particolare servizio necessita, sia da un punto di vista di dati che da un
punto di vista di stati logici, ovvero precondizioni ed effetti. in questa sezione dii troveranno
inoltre:
1) serviceName : data property che rappresenta il nome del servizio
2) serviceDescription : data property che fornisce una descrizione testuale del servizio
3) contactInformation : object property che permette di referenziare, magari tramite VCard, colui
10
11. che referenzia il servizio
Service Model
In questa sezione si descrive esattamente, come, il servizio web viene realizzato. Vengono infatti
fornite tutte le direttive per interagire al meglio con esso dando una visione davvero dettagliata
dello stesso. Il concetto di variabile, in Owls è definito tramite il concetto di ProcessVar a sua
volta sottoclasse di Variable, una classe appartenente all'ontologia SWRL. Vengono quindi
presentate le seguenti sottoclassi :
1) Parameter : unione a sua volta di Input e Output.
2) Local : unione disgiunta delle classi Loc e Ling che rappresentano le variabili interne di un
processo composito.
3) Existenzial : variabile non di tipo input usata come precondizione.
4) ResultVar : come il precedente ma riferito ad un risultato.
5) Partecipant : variabile partecipante al processo. Sono presenti due individui come, per esempio,
theClient e theServer
11
12. Figura 1.3 Service Model
Service Grounding
Specifica i dettagli che consentono ad un agente esterno di interfacciarsi con il servizio stesso. Il
service grounding rappresenta l'unico ponte tra l'ontologia Owls e il servizio vero e proprio in
quanto si occupa di mappare entità astratte in entità concrete (come per esempio le WSDL
operation); senza questa operazione sarebbe impossibile da parte di un agente, che ha già trovato
il servizio che gli serve, come comunicare con lo stesso. Un grounding basato sulla mappatura tra
owls e WSDL poggia su tre corrispondenze principali, che sono :
1. Processo Atomico : corrisponde ad una operazione del WSDL. I diversi tipi di Operation
sono collegati ad un processo atomico come segue:
12
13. 1.1. un processo atomico che presenta sia input che output è mappato come responce-
request operation
1.2. un processo atomico che presenta solo input è mappato come one-way operation
1.3. un processo atomico che presenta solo output è mappato come notification operation
1.4. un processo atomico che manda un output prima di ricevere input è mappato come una
solicit-responce operation
2. Gli input e gli output di un processo corrispondono all'idea di messaggio WSDL.
3. I tipi si possono associare ad un abstract type sfruttando l'estensibilità di WSDL.
Successivamente a questa infarinatura generale del Grounding, esiste una descrizione molto
più dettagliata che si preoccupa di collegare gli elementi delle due realtà descritte tramite
costrutti fondamentali. Tale livello di dettaglio, dato che non è stato preso in considerazione
all'interno dell'applicativo, lo si lascia alla curiosità del lettore.
13
14. 2. Cap. 1
2.1 Idea di progetto
Tenendo in considerazione le definizioni teoriche sopra riportate, si può facilmente capire come il
processo di classificazione e semantificazione si pone perfettamente all'interno del contesto più
generale e ampio che si sta creando grazie al web semantico. Il Web semantico, infatti, richiede
che i documenti pubblicati online siano associati ad informazioni e metadati che specificano il
contesto semantico rendendo più semplice l'interpretazione e l'interrogazioni dei dati stessi da un
agente automatico, il tutto specificato in un linguaggio totalmente machine readable, come RDFS,
in modo tale da rendere il tutto il più automatizzabile possibile a spese della leggibilità. Detto ciò,
l'idea di fondo del progetto è quella di sviluppare un software in grado di ricercare una particolare
categoria di servizi online a seconda del tipo di descrizione messa a disposizione dall'utente,
raccogliendo e classificando tutto ciò che viene trovato appoggiandosi ad una ontologia di fondo
(Ontologia di Dominio) che aiuta il software a “capire” se il contesto semantico espresso del
servizio trovato sia catalogabile o meno con l'ontologia in uso. Una volta capito che il servizio
appartiene al contesto descritto dalla nostra ontologia esso viene classificato utilizzando una
seconda ontologia (Ontologia di Servizio) mantenendolo in memoria per degli utilizzi futuri.
Tutto questo è pienamente in linea con l'obiettivo messo in risalto dal web semantico, ovvero
mettere a disposizione un modo per rintracciare automaticamente online un documento,
classificarlo e renderlo disponibile a terze parti.Sulla base di conoscenze così costruita, sarà
inoltre possibile compiere dei ragionamenti in modo tale da poter ottenere un servizio, il più
fedele possibile alle nostre aspettative, in maniera automatica. In tutto ciò, le ontologie utilizzate,
ricoprono un ruolo essenziale nell'intero processo. Esse infatti, per definizione, mettono in
relazione le conoscenze nomologiche e concettuali di un ambito ben preciso cosi da costruire una
14
15. base di conoscenze consistente che ci permetta di portare a termine ragionamenti in un tempo
finito.
Utilizzando una upper ontology come OWLS si può facilmente procedere nella trasformazione di
un documento WSDL in un nuovo documento scritto in XML/RDF che sia compatibile con il
linguaggio di OWL della nostra ontologia. Successivamente si procederà alla semantificazione e
classificazione dello stesso servizio processando ogni suo componente al fine di comprendere
appieno la sua appartenenza al contesto in uso.
2.2 Struttura della tesi
La struttura della tesi in se è molto semplice. Vi sono due classi fondamentali che gestiscono i
processi di semantificazione/classificazione [G.1] e ricerca. Come supporto alle due macro
operazioni sottolineate precedentemente, si sono implementate delle operazioni di base, come per
esempio le operazioni di cameling [G.2] e di tokenizzazione [G.3] per il trattamento delle stringhe
o la gestione dei sinonimi tramite il richiamo di un database semantico-lessicale specifico per la
lingua inglese, in modo tale da facilitare la suddivisione dei compiti ed evitare di sovraccaricare o
rendere troppo pesante il codice di ogni singola del sistema. Il tool è stato ottimizzato per la
lingua inglese in quanto ho sostenuto l'ipotesi di base che i servizi disponibili via web,siano resi
pubblici in una lingua comune. Il concetto primario del web semantico infatti non è altro che
riuscire ad utilizzare un linguaggio comune che possa rendere disponibile una lettura automatica e
automatizzata dei file nel web, in modo tale da ottimizzare la loro ricerca e il loro utilizzo tramite
piattaforme indipendenti.
15
16. Data la vastità del lavoro, si è riuscito ad implementare solo una piccola parte degli intenti iniziali
posti come obiettivo. Si è infatti deciso di evitare di sviluppare un crawler [G.4] che ricercasse
automaticamente online i documenti appoggiandosi al dominio di ricerca definito dall'ontologia
di dominio. Per ovviare a questa mancanza, abbiamo utilizzato come dati in ingresso un vasto
range di servizi scelti direttamente da internet, in modo tale da poter testare in maniera
soddisfacente il software in casi totalmente differenti. Inoltre sarebbero possibili molte modifiche
al software, ma di questo si parlerà nella sezione degli sviluppi futuri.
Tornado alla struttura della tesi, si è cercato di far interagire il meno possibile le parti del sistema
tra loro, ottimizzando i servizi messi a disposizione, aggregando così ciascuna macro operazione
ad una specifica classe che conterrà quindi metodi specifici per la risoluzione di un particolare
problema senza dover ogni volta interagire con la classe chiamante dando origine ad una serie di
chiamate che potrebbe solamente rallentare il sistema in vista di un corposo numero di ingressi da
gestire. Le uniche chiamate fatte dalle classi principali verso le classi che sostengono i lavori di
base, sono quelle di inizializzazione e di interrogazione per ottenere i risultati.
16
18. Andiamo ora ad illustrare la struttura principale tramite un diagramma dei package ed un più
specifico diagramma delle classi; successivamente si passeranno in rassegna tutti i singoli
componenti in modo tale da rendere la spiegazione del sistema il più esauriente possibile.
Come possiamo notare dallo schema sovrastante, il carico principale del lavoro è suddiviso
equamente in due package che sono l'Engine e il Research Manager i quali, rispettivamente, si
occupano, il primo, della gestione delle ontologie date in ingresso dal main passando per
l'Application manager (che per inciso si occupa dell'inizializzazione delle stesse come da schema
concettuale) con tutte le relative operazioni svolte sui servizi presi in carico dalle classi di ricerca
e, la seconda, per inciso, della ricerca online dei servizi che andranno a popolare la Repository,
quindi, il nostro sistema. Prima di spiegare passo passo gli algoritmi implementati nelle rispettive
classi, vorrei dare un'idea delle interazioni delle classi e del loro effetto sul lavoro complessivo
svolto dal software. L'ontology Manager, per esempio, non si occupa solamente di caricare le due
ontologie di fondo che si occupano di modellizzare l'ambito di ricerca, ma si occupa anche della
valutazione dei servizi appoggiandosi ad un'altra classe che si fa carico di tutte le operazioni di
elaborazione del linguaggio naturale e relativa valutazione delle somiglianze valutando ogni
singolo servizio creato e decidendone il grado di somiglianza con i servizi già presenti nel sistema.
Un altro elemento che gioca un ruolo essenziale al fine di ottenere un risultato ottimale è lo
Stemming Engine. Esso basa la sua efficacia su un motore di stemming [G.5] oramai ben
consolidato come il Tartarus6 utilizzato allo stesso modo all'interno delle librerie NLP Core di
Stanford. Oltre alle classi che gestiscono tutte le operazioni di semantificazione, classificazione e
ricerca, vi è un altro centro focale di tutto il lavoro, svolto appunto dalle ontologie sulle quali si
fonda tutto il ragionamento e che definiscono l'ambito di ricerca. Senza un'ontologia che
definisce il dominio applicativo, infatti, tutto questo lavoro non avrebbe senso, primo perché non
si saprebbe di che tipo di servizio stiamo parlando, secondo, perché non si saprebbe come
classificare le sue variabili in input perdendo gran parte del significato intrinseco dei servizi stessi.
6 Tartarus : http://snowball.tartarus.org/
18
19. 2.3 Ontologie
Per una completa resa dell'ambito applicativo, dobbiamo dividere la nostra ontologia in due parti
fondamentali: la prima è l'ontologia di Dominio (Domain Ontology) e la seconda è l'ontologia di
Servizio (Service Ontology).
2.3.1 Ontologia di Dominio
L'ontologia di dominio è un'ontologia implementata ad hoc per circostanziare il problema che ci
stiamo proponendo di risolvere in maniera ottimale. Con la definizione di questa ontologia
l'obiettivo è quello di aggregare un insieme di termini con relazioni in modo tale da ottenere una
struttura gerarchica tra gli stessi rendendo possibile una serie di inferenze logicamente valide.
L'ontologia di dominio quindi serve a definire l'ambito di ricerca. Più essa è dettagliata più
corrispondenze ci saranno con i servizi ricercati sul web.
Durante la fase di ricerca si è notato che il problema principale nella stesura di questo modello è il
racchiudere termini specifici utilizzati normalmente per classificare un certo tipo di servizio, cosa
non semplice da identificare. Questi termini infatti non sono sempre utilizzati con nomi propri,
ma abbreviati o espressi con sinonimi o acronimi poco conosciuti. La difficoltà quindi è stata
quella di identificare un insieme consistente di termini che garantisse un buon successo degli
algoritmi applicati. Naturalmente gli algoritmi sono stati creati per gestire qualsiasi tipo di input,
sono quindi il più generale possibile, ma il riconoscimento o il matching tra i termini contenuti in
nome, inputs e outputs dei servizi trovati, non è sempre cosi scontato.
Vado ora ad esemplificare parte dell'ontologia e delle relazioni utilizzate. Il primo esempio è la
suddivisione dei concetti sottoclasse di Thing, ovvero i concetti principali quali : location, che
19
20. rappresenta il concetto di posizione o luogo, identifiers, che identifica tutti i metodi che possono
essere utilizzati per richiamare un particolare luogo (zipcode, ip etc.), i concetti di forecast e weather,
che stanno a puntualizzare il concetto di meteo e di previsione meteo con tutti i loro particolari
annessi esemplificati anch'essi nei concetti di characteristic (che associa i concetti di umidità,
temperatura etc a weather), il concetto di warning e alert e duration che esemplificano le fasi di
segnalazione di pericolo da parte di un comunicato generico e la durata del weather forecast
utilizzato. Insieme ai concetti generici c'è anche una particolare classe che identifica la particolare
codifica del servizio che stiamo semantificando. Tra quelle presenti nel web, ne sono state
identificate due primarie, ovvero le codifiche GML7 e DWML8.
Figura 2.2 OntoGraf owl:Thing
7 GML (Geography Markup Language): http://www.opengeospatial.org/standards/gml
8 DWML (Digital Weather Markup Language): http://graphical.weather.gov/xml/DWMLgen/schema/DWML.xsd
20
21. Andiamo a vedere nello specifico alcune delle classi create:
1)owl:location :
Figura 2.3 OntoGraf della classe owl:location
La classe owl:location definisce il concetto di località che può essere distinta in località geografica
(nazione, stato, città) o località intesa come postazione fisica (stazione meteorologica, cella etc.).
Non è richiesta una maggiore distinzione in sotto categorie ma semplicemente una
schematizzazione di sottoclasse in quanto il concetto è comunque ben definito e un maggiore
livello di dettaglio non aumenterebbe la percentuale di servizi aggiunti al sistema.
21
22. 2)owl:identifier :
Figura 2.4 OntoGraf della classe owl:identifiers
Un concetto che segue logicamente dalla location è quello che è stato definito come identificativo
di zona (owl:identifier), ovvero tutto ciò che comprende un codice per identificare un luogo
particolare sia esso uno ZipCode, un IP Address, o delle più specifiche diciture come WMOID9,
FIPS10, WBAN11. Questi ultimi acronimi sono stati creati dall'associazione NOAA12, una agenzia
federale americana che si occupa di ricerca in ambito meteorologico ed oceanografico. Come si
può notare è anche stato associato il più comune concetto di coordinate GPS.
9 WMOID (World Metereological Organization ID Number ) : http://www.ncdc.noaa.gov/oa/climate/linktowcs.html
10 FIPS (Federal Information Processing Standard Code) : http://www.itl.nist.gov/fipspubs/
11 WBAN (Weather Bureau Army Navy) : http://www.ncdc.noaa.gov/oa/climate/stationlocator.html
12 NOAA (National Oceanic and Atmospheric Administration) : http://www.noaa.gov/
22
23. 3)owl:duration e owl:weather
Figura 2.5 OntoGraf della classe owl:duration e owl:weather
L'ultimo concetto interessante, come già accennato in precedenza è il concetto di codifica. Le
grandi agenzie di meteorologia o geospaziali come il NOAA o l'OGC13 hanno preferito
dichiarare degli standard de facto per comunicare in maniera eguale i risultati dei loro rilevamenti
creando appunto schemi come le codifiche già citate, DWML e GML. Queste due codifiche sono
le più complesse utilizzate anche da altri enti per rendere omogenea la trasmissione dei dati
acquisiti alle stazioni di ricerca.
Figura 2.6 OntoGraf owl:encoding
13 OGC (Open Geospacial Consortium): http://www.opengeospatial.org/
23
24. 2.3.2 Ontologia di Servizio
Al fine di classificare i servizi non è sufficiente processare gli input, output o i nomi tramite
l'ontologia di dominio, ma è necessario anche creare un'ontologia di servizio che si poggi su una
ontologia più specifica e strutturata come OWLS e mappare le classi rilevate dal processo di
semantificazione del documento WSDL con gli input e gli output dei Servizi appartenenti
all'ontologia di servizio in modo tale da controllarne le corrispondenze e vedere se i servizi
trovati possono essere classificati come istanza di un servizio già presente nell'ontologia. Il
servizio inoltre, se non trova corrispondenze, ha due possibilità, o venir scartato o valutato in
modo tale da avere i requisiti necessari ad essere elevato a nuovo servizio e quindi classificato
come una nuova istanza dello stesso appena creato. Come già accennato, l'ontologia di servizio si
poggia su owls. Owls, come già spiegato, è un'ontologia creata ad hoc per la classificazione di
documenti wsdl e quindi contiene tutte le classi e sottoclassi necessarie a tale scopo. I servizi che
sono stati creati sono a tutti gli effetti dei profili, ovvero delle sottoclassi di owl:Profile. Ad essi
sono associati input e output tramite la Object Property specifica hasParameter che associa un
Profile al relativo Input/Output.
Nella struttura generale del progetto la Service Ontology importa sia owls che la Domain
ontology con tutte le loro Object Property e relativi assiomi di Abox.
24
25. Figura 2.7 Schema importazioni Ontologia di Dominio e OWLS
2.4 Semantificazione
Il secondo passo verso una classificazione ottimale dei dati in ingrasso è il processo di
semantificazione, ovvero il processo di conversione di un documento WSDL trovato online in un
documento .owl definito in linguaggio consono a quello con il quale è scritta l'ontologia stessa
(ovvero RDF/XML).
Inizialmente viene recuperato il documento dal server nel quale è memorizzato. Dopo vari
tentativi di scrittura di una procedura che permettesse la semantificazione corretta del
documento, si è deciso di appoggiarsi ad una libreria standard che si occupa di questo tipo di
operazioni, ovvero un Traslator messo a disposizione da Mindswap14 per la conversione di
documenti wsdl in documenti owl (utilizzando le librerie di conversione in owls). Owl e owls
condividono la stessa sintassi, l'unica differenza è che in owls vengono importate nel documento
14 Mindswap : http://www.mindswap.org/
25
26. anche le ontologie di servizio necessarie a standardizzare la lettura e schematizzazione di un web
service (riferimenti ad owls possono esser trovati nel capitolo introduttivo sulle tecnologie di base
utilizzate).
Oltre alla lettura del documento, si necessita anche dell'aggiunta di tutti i parametri sia in ingresso
che in uscita contenuti nello schema WSDL che stiamo trasformando, in modo tale da sviluppare
un file ontologico completo e valido a tutti gli effetti. Questa parte di codice è stata sviluppata ad
hoc integrando tutti i metadati xml necessari nel documento owl creato dal traduttore in modo
tale da ottenere un documento valido e sopratutto completo, file che potrà essere
successivamente utilizzato per classificare al meglio il servizio. Data la struttura descritta all'inizio
di un documento WSDL, ci sono un paio di punti da sottolineare di importanza cruciale: il primo
è che ogni documento WSDL contiene un numero che può essere molto elevato di operazioni e,
ogni operazione è, in se, un servizio che il software al quale fa riferimento il documento WSDL,
può fornire a coloro che si servono del documento stesso. Ogni operazione è gestita
singolarmente in modo tale da poter leggere ogni singola occorrenza di una di esse e creare un
documento valido completo per ogniuna. C'è da sottolineare che tutto questo materiale è molto
poco documentato e che le ricerche in questo campo sono ancora in via di sviluppo, quindi si è
dovuto effettuare un gran numero di test prima di approdare ad una struttura consona a quello
che si stava cercando di creare, ovvero un sistema che, in automatico, mettesse in sequenza una
serie di operazioni “intelligenti” per comprendere al meglio un input generico in ingresso. Una
volta creato, quindi, il nostro file owl dal servizio WSDL originario, siamo pronti a classificarlo in
automatico. Una volta finita la semantificazione del documento, si passa quindi alla classificazione
vera e propria, che ci porta alla descrizione dell'algoritmo principale proposto, che sarà appunto, il
corpo fondamentale della tesi.
26
27. 2.5 Classificazione
Il processo di classificazione di un servizio owl è un procedimento complesso composto da
diverse sequenze standard di operazioni orientate alla comprensione, il più ampia possibile, di
com'è composto il servizio e qual'è ambito al quale si riferisce. Dovendo automatizzare questo
processo, si sono localizzate le fonti principali dove sono contenute tutte le informazioni
necessarie al processo in corso. Sono essenzialmente tre:
1) nome di servizio
2) input e relativo tipo
3) output e relativo tipo
Una volta individuati i punti salienti per la classificazione si è passato in rassegna un numero
molto ampio di esempi per tentare di sviluppare un algoritmo abbastanza efficace per far
“comprendere” all'agente automatico il significato delle parole contenute nei nomi e negli input in
modo tale da facilitarne la classificazione. A questo punto però, si è riscontrato un problema. I
nomi non sono nomi semplici o riconoscibili facilmente, ma una serie di acronimi, nomi
abbreviati e altre sigle che devono essere in qualche modo interpretate prima di procedere alla
classificazione. Per ovviare a questo problema, si sono tenuti come riferimento molti lavori nel
campo del Natural Language Processing (NLP) senza, tuttavia, implementare la maggior parte
degli algoritmi che rendono famoso il campo del machine learning a causa della loro potenza ma
gran complessità in alcuni casi. Si è tuttavia proposto un algoritmo alternativo che, pur
sfruttando molte delle tecniche standard come la tokenizzazione di una frase e il cameling di una
stringa si propongono di trovare il significato intrinseco di ogni parte del nome analizzato
svolgendo azioni che noi utilizziamo normalmente e inconsciamente per ovviare a problemi di
questo tipo. Infatti, cosa succede quando ci troviamo di fronte ad un acronimo del quale non
sappiamo il significato? Di solito proviamo ad attaccare delle parole ad ogni iniziale per arrivare a
27
28. conoscere parte del suo significato, oppure, se abbiamo a nostra disposizione qualche
informazione aggiuntiva sull'ambito alla quale appartiene, andiamo mirati verso l'obiettivo senza
dubbi e sopratutto senza commettere errori. Nel nostro caso si è fatto un ragionamento simile.
All'interno di un nome casuale generato dal programmatore per dare un'idea della procedura
svolta dal nostro servizio web, vi sono nomi, abbreviazioni, acronimi, articoli e congiunzioni
varie. Oltre a questo però, un servizio gode anche di una dettagliata descrizione di cosa esso
effettivamente svolge. L'algoritmo da me proposto inizialmente tokenizza (t.1) questa descrizione
togliendo spazi, articoli congiunzioni e cose inutili al processo di confronto e mantiene in
memoria una lista delle parole contenute al suo interno, parole che andremo ad utilizzare per
espandere le eventuali abbreviazioni e gli eventuali acronimi non riconosciuti. Una volta fatto ciò,
viene fatto un parsing [G.6] della stringa in ingresso (es. il nome del servizio) e viene effettuata
una prima scrematura dei termini contenuti. Questa prima scrematura ci permette di capire in
quale tipo di caso rientra il nostro nome, ovvero ci permette di comprendere se esso è una
semplice sequenza di nomi con le maiuscole come iniziale, se è, per esempio, un nome con un
acronimo al suo interno (inizio, fine o all'interno della parola) o se è un nome generico
comprensivo di abbreviazioni e articoli e via dicendo. Questo primo passaggio, per riconoscere gli
eventuali acronimi, fa uso di una mappatura statica tra tutti gli acronimi universalmente
riconosciuti e il loro significato standard (si è trovato infatti un sito internet che contiene tutti gli
acronimi universalmente divulgati e se ne è mappato il contenuto a nostro favore). Una volta
riconosciuto il fatto che tale parola contiene un acronimo, l'algoritmo lo isola ed effettua il
cameling della restante parte della parola che stiamo analizzando. Se non è presente un acronimo
riconosciuto o semplicemente è un nome composto da abbreviazioni o parole complete esso
effettua il cameling diretto della parola. A questo punto ci troviamo con una parola che potrebbe,
potenzialmente, essere composta da lettere maiuscole, che non sappiamo a cosa corrispondono,
da abbreviazioni, intuibili ma da un occhio umano e non da un computer, da parole intere o da
tutte le precedenti insieme ad un acronimo esteso dalla prima mappatura. L'algoritmo a questo
punto fa uso della descrizione tokenizzata per completare, come accennato prima, per analogia,
una parola abbreviata o una lettera iniziale associando tale abbreviazione, o iniziale, alla parola
28
29. completa sulla base degli inizi comuni. Faccio un esempio. Capita di trovare nomi come :
LatLongList il processo prevede che:
1. tokenizzazione della descrizione
2. controllo acronimi: ci sono acronimi all'interno? NO
3. camelizzazione : Lat / Long / List
4. associazione parole dalla descrizione per completare la lista che ho:
4.1. Lat → Latitude
4.2. Long → Longitude
4.3. List → List
5. a questo punto, le parole che sono state mappate nel precedente modo vengono aggiunte ad
una mappatura dinamica che andrà ad essere interrogata nel caso non si trovino delle
corrispondenze tra i nomi che abbiamo e i nomi della descrizione
6. stemming dei termini
La mappatura dinamica è molto importante nel processo perchè, se un termine è già stato
espanso e la descrizione non contiene analogie, essa propone una soluzione veloce e ottima senza
dispendio computazionale. Si è infatti implementato un algoritmo con mappature e funzioni il più
ottimizzate possibile in quanto, pensando, potenzialmente, alla grande quantità di dati in ingresso,
non si voleva perdere troppo tempo nella ricerca dei termini, per esempio, con l'uso di un
dizionario o di una ricerca di espansioni direttamente su internet. Si era infatti trovato un altro
modo per espandere, per esempio, le abbreviazioni. Esistono siti come WordReference15, ovvero
dizionari online di traduzioni tra molte delle lingue conosciute, forniscono, oltre ai servizi
standard, anche una lista di abbreviazioni comuni associate al termine stesso. Una volta trovato
questo termine, fare il parsing della pagine per ritrovare la parole intera è una cosa banale, ma
comunque molto dispendiosa in termini di tempo se consideriamo che deve esser speso del
tempo nella ricerca, nel parsing e nell'interpretazione del risultato. Tornando alla nostra
15 WordReference: www.wordreference.com
29
30. mappatura dinamica, a questo punto, si potrebbe obiettare che sia inconsistente, in quanto, se un
termine non viene trovato nella descrizione e la mappatura è vuota, essa non fornisce alcun
risultato. Questo è in parte vero, ma si è visto come essa è talmente flessibile da poter gestire
anche questi casi limite appoggiandosi alla mappatura stati che contiene i termini base degli
acronimi. Questo è sufficiente per rendere l'algoritmo abbastanza robusto da portare a termine il
lavoro di riconoscimento dei termini che a noi serve. Un altro passo importante è lo stemming.
2.6 Stemmer
Lo stemming è molto importante nel processo di classificazione. Le parole, infatti, possono
essere differenti dalle parole utilizzate dalla descrizione ontologica del contesto applicativo che
stiamo utilizzando, quindi, devono essere ridotte alla radice in modo tale da aumentarne la
corrispondenza con il sistema in uso. A causa di questo, ogni termine fornito dal processo
precedentemente descritto, viene stemmato e ridotto. Si è utilizzato all'interno dell'algoritmo, lo
stemmer tartharus, già ampiamente utilizzato anche all'interno di NLP Core di Stanford già citato
precedentemente. Durante la fase di test però, si è notato che tale stemmer conteneva degli errori
di concetto, che diminuivano di gran lunga l'attendibilità dei risultati forniti dall'algoritmo. Le
parole terminanti in -y infatti venivano codificato con la desinenza -i rendendo la parola, non
sono lessicalmente sbagliata, ma portando anche il matching corrente a dare risultati falsati da
questo dato di fatto. Si è quindi modificato il codice dello stemmer correggendo questi particolari
e rendendo i risultati più consoni a quello che ci si aspetta in realtà.
30
31. 2.7 WordNet e Tabelle
A questo punto disponiamo di tutti gli elementi necessari a svolgere il corpo centrale
dell'algoritmo di classificazione. Prima di procedere però vorrei far saltare all'occhio un punto
importante che si andrà a sottolineare anche in seguito successivamente. Si è fatto uso di due tipi
diversi di tabelle preliminari alla funzione di valutazione per classificare al meglio il tutto. La
prima è una tabella che mette in corrispondenza una stringa ad una classe owl contenuta
nell'ontologia di dominio e la seconda mette in corrispondenza una classe owl dell'ontologia di
dominio con un'altra classe owl che rappresenta gli input e gli output dei servizi codificati
nell'ontologia di servizio. Vi sono, quindi, 6 tabelle:
–nome del servizio wsdl / classe owl corrispondente
–nome del servizio / classe owl rappresentato il servizio codificato
–stringa input / classe owl input
–stringa output / classe owl output
–classe owl input / matching con input ontologia di servizio
–classe owl output / matching con output ontologia di servizio
Per riempire questo tipo di tabelle ci serve un modo per confrontare tali termini e fornire in
uscita una percentuale di matching. Per fare questo si sono utilizzati tre diversi approcci a seconda
del caso in cui ci troviamo, ovvero:
1)la parola derivante dal processo precedente è identica alla classe contenuta nell'ontologia di
dominio
31
32. 2)la parola derivante dal processo precedente è in parte identica ad un termine contenuto
nell'ontologia di servizio
3)la parola non appartiene al contesto
Il primo caso e l'ultimo sono i più semplici da analizzare. Se una parola non appartiene all'insieme
dei termini contenuti nell'ontologia, essa viene semplicemente ignorata e non aggiunta da
nessuna parte. Se essa è, invece, uguale a uno di questi termini, viene aggiunta alla relativa tabella
preliminare con il massimo della corrispondenza. Se invece approdiamo al secondo caso, sono
stati implementati due modi che ci permettono di carpire la corrispondenza tra i termini. Il primo
è una valutazione per confronto e il secondo è una valutazione per sinonimo. Tali valutazioni
vengono espresse tramite una percentuale di affinità con il termine, calcolate poi, come
accennato, tramite confronto o, come nel secondo caso, tramite una valutazione dei sinonimi
della parola stessa. Per confronto si intende un confronto lettera a lettera delle parole, e, la
percentuale, è derivante dal conteggio delle lettere uguali nelle due parole. La seconda valutazione
interviene se per caso non si sono trovate corrispondenze dirette. Infatti, prima di scartare una
parola, che potrebbe essere una possibile corrispondenza, si controlla che essa non sia, in realtà,
un sinonimo della parola utilizzata. Per far ciò ci si è appoggiati ad un tesauro chiamato
WordNet16, che fornisce una specie di dizionario dove però le parole sono correlate grazie al loro
significato e quindi alla loro relazione con gli altri termini e non grazie ad un ordinamento
alfabetico. Se una parola è quindi un sinonimo della parola con la quale la stiamo confrontando,
ad essa viene associata una valutazione calcolata in base all'intersezione degli insiemi dei sinonimi
delle due parole. Ovvero: prendo l'insieme dei sinonimi della prima parola, prendo l'insieme dei
sinonimi della seconda parola e ne faccio l'intersezione. Se essa è vuota allora la parola è da
scartare, se non lo è, la percentuale deriva dalla divisione tra il numero di elementi derivanti
dall'intersezione tra i due insiemi e dal numero degli elementi totali (ovvero unione senza
ripetizione dei termini delle due tabelle). Questo metodo garantisce che ogni caso venga preso in
considerazione e che la parola venga processata nel migliore dei modi, assicurando un risultato, in
primis, accurato e, di conseguenza, consistente rispetto al processo che stiamo portando avanti.
16 WordNet : http://wordnet.princeton.edu/
32
33. Questo processo di trattamento dei nomi, è leggermente differente per quanto riguarda gli input
e gli output. I nomi di questi parametri, infatti, vengono trattati allo stesso modo, il problema è il
Type degli stessi. Essi infatti potrebbero causare molti problemi nel momento in cui un input o
un output sia di tipo complesso. Ricordiamo infatti che input e output possono essere
fondamentalmente di due tipi: semplici e complessi. I parametri semplici sono parametri standard
o DataType, ovvero tipi definiti in maniera univoca dalla W3C come appunto, standard di uso
comune.
33
34. Figura 2.8 Built-In DataType Hierarchy
La datatype17 hierarchy riportata in figura 2.8, mostra la complessità e la struttura dei data type
standard. Questi tuttavia non creano problema in fase di lettura o di semantificazione in quanto,
essendo standard, vengono universalmente riconosciuti e trattati di conseguenza. I problemi
sopraggiungono nel momento in cui i tipi con i quali abbiamo a che fare sono definiti dall'utente,
ovvero composti da parametri non standard che si dovrebbero, per scrupolosità progettuale e per
completezza, espandere e trattare singolarmente. Data la complessità di questo procedimento, che
comprende la valutazione dei singoli namespace e il trattamento di ogni singolo dato con la
creazione e con il confronto dello stesso con una classe relativa all'interno della mia ontologia, si
è pensato di trattarli in maniera standard e lasciare la loro gestione più approfondita tra gli
sviluppi futuri, in modo tale da terminare al meglio l'algoritmo base di classificazione.
Detto ciò, abbiamo completato il trattamento dei dati, creando quindi tabelle che ci portano a
confrontare, inizialmente, le stringhe dei nomi di servizio, input e output, con le classi
dell'ontologia di dominio, cosi da tentare di “capire” e mappare il dato che si sta trattando con
una classe della nostra ontologia di riferimento. Successivamente si sono create le tabelle che ci
permettono di valutare quanto il nostro set di dati, centri con i servizi locati nella nostra ontologia
di servizio, cosi da valutarne l'eventuale esatta collocazione e quindi, classificare il nostro nuovo
servizio all'interno del sistema che stiamo sviluppando. Per far ciò, oltre alle tabelle necessarie al
mapping degli input e gli output con gli input e output dei servizi della nostra ontologia, si
richiede la presenza di una funzione di valutazione, o funzione di fitting, che utilizzi i dati raccolti
fino a questo punto e ne tragga delle conclusioni sotto forma numerica. Prima di addentrarci
nella descrizione della funzione di fitting, vorrei spiegare un paio di particolari riguardanti le
tabella di confronto con i servizi. Queste tabelle sono leggermente diverse dalle prime, ovvero
mantengono una corrispondenza tra classe e classe con le relative percentuali. Le classi dalle quali
si procede sono contenute nello stesso dominio, ovvero quello definito,appunto, dalla nostra
17 DataType : http://www.w3.org/TR/xmlschema-2/#datatype-dichotomies
34
35. ontologia di dominio. La particolarità di questo procedimento è dovuta al semplice fatto che i
servizi contenuti nell'ontologia di servizio, hanno due tipi di input e output differenti, quindi le
tabelle richiederanno due tipi di trattamenti differenti. Quelli più semplici sono i servizi che
contengono degli input particolari, possono contenere infatti solo classi di livello zero, ovvero le
foglie dell'albero creato nell'ontologia di dominio come, per esempio, la classe Latitudeche è una
delle ultime foglie della sottoclasse GPS. Il secondo tipo di input o output di un servizio della
nostra ontologia di servizio è un tipo di parametro aggregato, ovvero un tipo di dato che può
essere una qualsiasi delle classi di una particolare classe padre, utilizzando il caso dato
precedentemente, possiamo dire che il nostro servizio potrebbe avere come input un aggregato di
classi tipo GPS. Questo significa che il servizio che verrà mappato sotto questo tipo di input
potrà avere più parametri che rientrano tutti nella categoria GPS, che possono essere, come in
questo caso, Latitude, Longitude, Elevation e Resolution. Ogni input o output cosi fatto, avrà quindi
una molteplicità multipla e, la percentuale per la funzione di fitting sugli ingressi, verrà calcolata
sul numero di categorie rispettate. Per ottenere questo tipo di informazioni non si sono creati
metodi per calcolare o scalare l'albero XML/RDF dell'ontologia alla ricerca delle corrispondenze,
ma si è utilizzato un reasoner Hermit che, tramite l'utilizzo di inferenze sull'ontologia stessa,
riesce ad ottenere automaticamente le informazioni che cerchiamo rendendo più efficiente tutto il
processo.
2.8 Funzione di Fitting
L'idea che sta alla base della costruzione di questa funzione è capire quanto il mio sistema ha
compreso del servizio trovato su internet passando per entrambe le ontologie costruite. Le due
ontologie infatti sono su due livelli differenti. Mentre l'ontologia di dominio ci serve a creare una
correlazione tra i parametri del servizio e l'ambito applicativo, l'ontologia di servizio serve a
creare una correlazione tra le classi trovate dal primo processo appena descritto e i servizi (con i
35
36. relativi parametri) locati al suo interno. Per far ciò, il modo più semplice, dato che le variabili sono
già state processate, è quello di conteggiare i parametri che corrispondono alle ontologie e quelli
realmente contenuti all'interno del documento originale. La funzione di fitting è quindi suddivisa
in due parti relative, la prima, all'ontologia di dominio e la seconda all'ontologia di servizio. La
struttura generale di tale formula è stata valutata sulla base di ricerche nel campo. Si sono trovati
infatti articoli molto interessanti che modellano il matching tra ontologie sfruttando funzioni con
pesi di normalizzazione dei risultati standard, dove per standard si intende assegnati
manualmente.
L'esempio finale di funzione di fitting proposta è quindi:
Θ(W ,S )=0,3
∑
0
N
iw
∑0
N
I W
+0,3
∑
0
N
ow
∑0
N
OW
+0,2
∑
0
N
is
∑0
N
I S
+0,2
∑
0
N
os
∑0
N
OS
Con :
– iw
= input riconosciuti dall'ontologia di dominio
– IW
= input totali del wsdl originale
–is
= input riconosciuti dall'ontologia di servizio
– IS
= input totali del servizio
– ow
= output riconosciuti dall'ontologia di dominio
– OW
= output totali del wsdl originale
– os
= output riconosciuti dall'ontologia di servizio
–OS
= output totali del servizio
36
37. Come possiamo notare dalla legenda dei simboli, essi si riferiscono ai parametri del wsdl e del
servizio facendo cosi in modo di dividere la funzione essenzialmente in due parti, facendoci
capire quanto del servizio è stato compreso dal nostro software.
Una seconda cosa che si può notare è l'utilizzo di pesi necessari per la normalizzazione del valore
della funzione di fitting. Questi pesi sono stati aggiunti manualmente valorizzando maggiormente
il processo di comprensione del wsdl rispetto a quello di riconoscimento dei parametri del
servizio. Un possibile sviluppo sarebbe quello di assegnare i pesi alla funzione di valutazione
tramite dei cicli di learning compiuti da, per esempio, una rete neurale che valuta l'importanza dei
diversi parametri e ne ri-aggiorna il peso iterativamente (vedi sviluppi futuri).
2.9 Repository & Logging
Per mantere traccia di tutte le modifiche e di tutti i documenti creati, il sistema prevede due file di
risultati, un file di Logging, che tiene conto di tutte le operazioni effettuate dal sistema e una
Repository che mantiene i collegamenti dei documenti con le ontologie utilizzate.
2.9.1 Logging
Il file di Logging non è altro che un semplice file di testo che contiene tutti le operazioni
effettuate dal sistema con i timestamp e il relativo metodo che ha effettuato tale operazione. Si è
deciso di limitare i dati scritti sul file di Logging al livello di INFO, nel caso di operazioni andate a
buon fine e, per mantenere traccia anche del contrario, ovvero di tutte le operazioni che non
hanno portato ad una classificazione del servizio, si tiene traccia ad un livello GRAVE, cosi da
essere il più scrupolosi possibile nel documentare gli avvenimenti del sistema.
37
38. 2.9.2 Repository
La Repository ha l'unico compito di contenere il mapping tra i documenti creati, ovvero i servizi
in formato owl, e i relativi indirizzi dei servizi padre ai quali sono stati assegnati. Utilizzando una
struttura cosiffatta, abbiamo la possibilità di leggere direttamente i risultati della classificazione
cosi da essere in grado, se vogliamo, di recuperare i servizi appena creati per offrire, per esempio,
un servizio di composizione o sostituzione di un altro servizio che si sta utilizzando e che, per
motivi generico, può essere offline e quindi irraggiungibile rendendo quindi il cliente passibile di
un denial of servise potenzialmente dannoso. La struttura finale sarà quindi la seguente:
38
39. 3. Cap.2
3.1 Architettura di sistema
Si è tentato di mantenere una netta separazione tra ogni livello dell'applicazione, facendo
interagire in maniera limitata ogni singolo modulo cosi da mantenere una struttura gerarchica ben
definita facendo in modo che ogni singola operazione svolta dal sistema si appoggi ad una singola
libreria per volta sfruttandone al meglio le potenzialità. Si può quindi dire che si è utilizzata
un'architettura multi layering ma senza l'utilizzo di particolari tecnologie come applicativi client-
server o componenti web come servlet e JSP per l'interazione con l'utente. Lo user target del
sistema è infatti un agente automatico che si preoccupa di fornire al sistema i parametri di
funzionamento e, se necessario, le ontologie per definire l'ambiente applicativo. La versione
generale del sistema infatti, è stata pensata per adattarsi a un qualsiasi utilizzo, quindi, dovrebbe
essere strutturata in modo tale da poter ricevere in ingresso ontologie e tipo di operazioni
richieste e fornire in output ciò che viene definito da contratto generale. Tutto questo però è
definito negli sviluppi futuri di questo software in quanto avrebbe richiesto una quantità di tempo
molto maggiore per lo sviluppo.
Le componenti principali del sistema sono, in questo modo, due, una parte di logica che
comprende tutti i metodi utilizzati per lo sviluppo delle operazioni e una parte di data base divisa
anch'essa in due parti, che utilizzano due database differenti.
39
40. 3.1.1 Data Base
I data base utilizzati sono essenzialmente di due tipi, il primo è un database in linguaggio
XML/RDF, proprio delle ontologie, utilizzato per la creazione delle ontologie di servizio e di
dominio e per la repository dei risultati; il secondo tipo è un database di termini gestito e creato
da terzi che è appunto il database WordNet, responsabile di parte della fase di classificazione. La
struttura dei database non è presente in quanto WordNet non è altro che un database di termini
posti in relazione semantico-lessicale tra loro, mentre il secondo, ovvero le ontologie, ha una
struttura ad albero molto complessa che cresce a seconda della quantità di dati gestiti dal sistema.
La struttura standard iniziale delle due ontologie, si è spiegata nei capitoli precedenti ed è stata
creata tramite l'utilizzo di tool grafici che rendono la sua gestione molto più semplice rispetto alla
loro scrittura manuale che, data il linguaggio utilizzato (RDF) è altamente non human-readable.
3.1.2 Logica
Si vuole dare un'idea della struttura della logica del sistema utilizzato tramite l'utilizzato di un class
diagram generale delle classi create e dei metodi utilizzati. Successivamente si spiegherà, tramite
l'utilizzo di sequence diagram, alcuni dei casi d'uso più frequenti gestiti dal sistema come per
esempio il ciclo generale e la parte di semantificazione.
40
41. Figura 3.1 Class Diagram del sistema
Come possiamo notare, come anche precendentemente descritto nel capitolo 1, l'OntManager
gestisce le interazioni generali del sistema, appoggiandosi a classi come NLPEngine e Research
Manager per gestire, rispettivamente, la parte di semantificazione dei servizi in ingresso e la parte
di ricerca dei servizi che saranno input di sistema. Una cosa da notare, che però si è sbagliata a
documentare nel class diagram proposto è che tutti i metodi all'interno delle classi sono metodi
privati. La classe che inizializza le classi che andrà ad utilizzare potrà quindi solamente richiamare
il servizio principale svolto dalla stessa cosi da non poter interagire in alcun modo con i processi
interni delle stesse
41
42. Andiamo ora ad illustrare alcuni dei processi principali del sistema:
1)processo di inizializzazione dei componenti e ciclo standard per la lettura e gestione delle
operazioni contenute nei wsdl service trovati su internet:
Figura 3.2 Sequence Diagram ciclo generale
Come si evince dalla figura in questione, la classe Main inizializza il nostro Application Manager,
il quale, a sua volta, inizializza le due classi principali del sistema, che sono appunto l'Ontology
Manager e il Research Manager. Il resto del processo è ampiamente descritto dal successivo
sequence diagram.
42
43. 2) processo di semantificazione e classificazione:
Figura 3.3 Sequence Diagram semantificazione e classificazione
Come possiamo notare, il corpo principale del lavoro, è eseguito dall'ontology Manager che,
leggendo gli elementi del wsdl appena trovato, si preoccupa di chiamare l'NLP Engine
responsabile della risoluzione dei nomi e degli acronimi, il quale, a sua volta, si appoggia a classi
dedicate solamente ad uno scopo, come per esempio stemmare i termini da utilizzare o fornire
sinonimi al sistema. Il tutto, come si può vedere, limita al minimo le interazioni tra le classi.
43
44. 3.2 Software e deployment
Per la realizzazione del sistema sono state utilizzate le seguenti tecnologie :
–WordNet Database: Princeton WordNet DB 3.0
–Ambiente di Sviluppo: Eclipse Java EE IDE for Web Developers
–Ontology Manager: Protegé 4.1
Inoltre sono state integrate nel sistema le seguenti librerie:
–NLP Core Stanford : http://nlp.stanford.edu/software/corenlp.shtml
–Gestione ontologie :
–Owls API 3.0 Mindswap Libraries
–Owl API SemanticWeb
–Hermit Reasoner : SemanticWeb API
–Html Parser
–XML Parser
–JRE Standard System Library
Vorrei inoltre fornire una visione d'insieme del sistema generale tramite il seguente deployment
diagram che evidenzia i collegamenti tra i package d'interesse. Si sottolinea che il diagramma offre
uno schema logico dell’applicazione e non una suddivisione “hardware”.
Figura 3.4 deployment diagram
44
46. 4. Risultati Sperimentali
Si è utilizzato, per modellare il sistema, un servizio molto generale e complesso, tra quelli generati
da un grande consorzio americano e che è responsabile di una codifica molto complessa della
quale si è precedentemente parlato, ovvero la DWML. Utilizzando tale servizio, i risultati sono i
seguenti:
Il WSDL originale mostra che, essendo rispettata la struttura classica del WSDL come descritto
nel capitolo introduttivo, la sezione Port Type, racchiude tutte le operazioni che definiscono il
servizio originario, operazioni che noi andremo a trattare come singoli servizi, di seguito è
riportato il tabulato XML relativo a tale sezione:
<portType name="ndfdXMLPortType">
<operation name="NDFDgen">
<documentation>
Returns National Weather Service digital weather forecast data
</documentation>
<input message="tns:NDFDgenRequest"/>
<output message="tns:NDFDgenResponse"/>
</operation>
<operation name="NDFDgenByDay">
<documentation>
Returns National Weather Service digital weather forecast data summarized over either 24- or 12-
hourly periods
</documentation>
<input message="tns:NDFDgenByDayRequest"/>
<output message="tns:NDFDgenByDayResponse"/>
</operation>
<operation name="NDFDgenLatLonList">
<documentation>
Returns National Weather Service digital weather forecast data
</documentation>
<input message="tns:NDFDgenLatLonListRequest"/>
<output message="tns:NDFDgenLatLonListResponse"/>
</operation>
<operation name="NDFDgenByDayLatLonList">
<documentation>
Returns National Weather Service digital weather forecast data summarized over either 24- or 12-
hourly periods
</documentation>
<input message="tns:NDFDgenByDayLatLonListRequest"/>
<output message="tns:NDFDgenByDayLatLonListResponse"/>
</operation>
<operation name="GmlLatLonList">
<documentation>
Returns National Weather Service digital weather forecast data encoded in GML for a single time
</documentation>
<input message="tns:GmlLatLonListRequest"/>
<output message="tns:GmlLatLonListResponse"/>
</operation>
<operation name="GmlTimeSeries">
<documentation>
Returns National Weather Service digital weather forecast data encoded in GML for a time period
</documentation>
<input message="tns:GmlTimeSeriesRequest"/>
46
47. <output message="tns:GmlTimeSeriesResponse"/>
</operation>
<operation name="LatLonListSubgrid">
<documentation>
Returns a list of latitude and longitude pairs in a rectangular subgrid defined by the lower left and
upper right points
</documentation>
<input message="tns:LatLonListSubgridRequest"/>
<output message="tns:LatLonListSubgridResponse"/>
</operation>
<operation name="LatLonListLine">
<documentation>
Returns a list of latitude and longitude pairs along a line defined by the latitude and longitude of
the 2 endpoints
</documentation>
<input message="tns:LatLonListLineRequest"/>
<output message="tns:LatLonListLineResponse"/>
</operation>
<operation name="LatLonListZipCode">
<documentation>
Returns a list of latitude and longitude pairs with each pair corresponding to an input zip code.
</documentation>
<input message="tns:LatLonListZipCodeRequest"/>
<output message="tns:LatLonListZipCodeResponse"/>
</operation>
<operation name="LatLonListSquare">
<documentation>
Returns a list of latitude and longitude pairs in a rectangle defined by a central point and distance
from that point in the latitudinal and longitudinal directions
</documentation>
<input message="tns:LatLonListSquareRequest"/>
<output message="tns:LatLonListSquareResponse"/>
</operation>
<operation name="CornerPoints">
<documentation>
Returns four latitude and longitude pairs for corners of an NDFD grid and the minimum resolution
that will return the entire grid
</documentation>
<input message="tns:CornerPointsRequest"/>
<output message="tns:CornerPointsResponse"/>
</operation>
<operation name="LatLonListCityNames">
<documentation>
Returns a list of latitude and longitude pairs paired with the city names they correspond to
</documentation>
<input message="tns:LatLonListCityNamesRequest"/>
<output message="tns:LatLonListCityNamesResponse"/>
</operation>
</portType>
Figura 4.1 Tabulato PortType
Come possiamo notare ogni operazione è accompagnata da una descrizione e dai relativi
messaggi Request e Responce che gestiscono input e output del WSDL trattato. Dopo il primo
ciclo di semantificazione ci troviamo ad avere lo stesso numero di servizi del numero di
operazioni contenute nel documento e nel file necessario alla classificazione ovvero .owl :
1)NDFDgen.owl
2)NDFDgenByDay.owl
47
49. Sono stati scelti due servizi con i relativi dati e descrizioni per esemplificare il processo di
creazione delle tabelle, sono:
1.
1.1. Descrizione: Returns National Weather Service digital weather forecast data encoded in
GML for a time period
1.2. Nome: GmlTimeSeriesService
Figura 4.2 Tabelle di classificazione GmlTimeSeriesService
49
50. 2.
2.1. Descrizione: Returns a list of latitude and longitude pairs in a rectangular subgrid
defined by the lower left and upper right points
2.2. Nome: LatLonListSubgridService
Figura 4.3 Tabelle di classificazione servizio LatLonListSubgridService
50
51. Queste sono solo due delle tabelle create nel processo di classificazione dei 12 servizi sopra
riportati. Sono state riportate solamente a titolo esemplificativo nel tentativo di far capire come
l'algoritmo funzioni del riempirle. Come possiamo notare, sulla sinistra, i nomi delle prime 4
tabelle, ovvero nome del WSDL, nome del servizio, input ed output, contengono nomi stemmati
in modo tale da aumentarne al massimo la corrispondenza nell'eventualità di un matching con
una classe all'interno dell'ontologia. Si sarà oramai capito che una classe ontologica non
corrisponde ad una classe java, ma è un oggetto vero e proprio con le proprie relazioni e
proprietà definite da regole di Abox e Rbox. Le ultime due tabelle invece contengono solamente
nomi di classi a significare che, una volta capito cosa del WSDL originale ci serve, tutto ciò che è
stato selezionato, viene confrontato con i parametri contenuti nei servizi della nostra ontologia di
servizio al fine di ottenere dati a sufficienza per ottenere come risultato una corrispondenza alta,
o comunque superiore al 30 %, soglia fissata come limite di classificazione. Una volta ottenuto
ciò, la corrispondenza alla classe del servizio della nostra ontologia di servizio, ci servirà a creare
una corrispondenza tra il servizio stesso e il servizio appena semantificato (ovvero il nostro
WSDL). Il passo successivo, sarà quindi creare e posizionare l'individuo corrispondente al
servizio appena ottenuto dalla semantificazione come sotto istanza del servizio della nostra
ontologia di servizio che otterrà una valutazione sufficiente dopo il processo di classificazione.
51
52. Quello che otterremo sarà questo:
1)il primo servizio, ovvero ServiceGmlTimeSeriesService, come è evidente dal nome, verrà
classificato all'interno della mappatura dei servizi con codifica GML, ed infatti il risultato della
classificazione mostra che tale attesa viene ampiamente rispettata essendo esso creato come
istanza del super service GMLService già allocato nella nostra ontologia dei servizi. Riporto ora
in seguito la schermata di Protegè che mostra tale risultato:
Figura 4.4 Classificazione di GmlTimeSeriesService
52
53. 2)il secondo servizio invece viene posto nella posizione relativa ai servizi puramente geografici,
ovvero quelli che richiedono coordinate GPS come latitudine e longitudine per essere richiamati.
Come ci si può aspettare dal nome, quello che avviene è:
Figura 4.5 Classificazione di LatLonListSubgridService
Il passo finale del nostro lavoro è stata la valutazione della precisione del nostro algoritmo. Si è
verificato che, a fronte dell'inserimento di 21 documenti WSDL trovati su internet, sono stati
creati 39 documenti owl semantificati e classificati correttamente su un totale di 51 servizi
(ovvero 51 operazioni contenute nei documenti originali). Questo significa che l'algoritmo da noi
proposto ha classificato ben il 76.5% dei servizi da lui processati.
53
54. 5. Conclusioni
In conclusione possiamo dire che è possibile, una volta preso in ingresso un qualsiasi servizio
web e schematizzato e definito precisamente il dominio applicativo di ricerca, classificare tale
servizio al fine di capirne la tipologia e il genere, in modo tale da facilitare eventuali funzioni di
ricerca dello stesso. Questo lavoro quindi è un ottimo esempio di come si potrebbe procedere alla
creazione di un motore di ricerca semantico allo scopo, per esempio, di ricercare servizi da
sfruttare per la sostituzione di servizi web non più raggiungibili in maniera automatica, oppure,
più semplicemente, dato un ambito applicativo, la ricerca di documenti molto più precisi e
attendibili, cosa che, nella rete internet attuale, rappresenta un enorme ostacolo in quanto i dati
devono essere interpretati direttamente da un occhio umano, cosa non ottimale nel caso di
ricerche di vasta entità o altamente selettive.
54
55. 6. Sviluppi Futuri
Vi sono innumerevoli sviluppi futuri per quanto riguarda questo tipo di applicazione.
La prima idea sarebbe quella di creare un crawler web che ricerchi automaticamente i servizi da
semantiticare e classificare sul web, in modo tale da rendere automatico questo processo una volta
fornito l'ambito applicativo di ricerca.
Un secondo passo sarebbe quello di rendere indipendenti i due processi, ovvero introdurre il
multi-threading per rendere parallelo il processo di semantificazione e classificazione e quello di
ricerca online dei contenuti.
Un terzo sviluppo futuro sarebbe l'aggiunta di una rete neurale che bilanci e ricerchi i pesi ottimi
da applicare alla funzione di fitting in modo tale da rendere i risultati ottenuti sempre più
affidabili e meno sottoposti ad una valutazione manuale e casuale, ovvero meno soggetta
all'individuo che la sta programmando ma più soggetta ai dati dei quali disponiamo.
Un quarto punto, molto importante, sarebbe quello di sviluppare una parte di classificazione
molto più selettiva, che valuti esattamente tutti i tipi di dato, compresi gli input complessi, cosa
molto difficile da gestire a causa della vastità e diversità dei dati utilizzati all'interno dei servizi a
disposizione sul web. Questo ambito infatti è in completo sviluppo ed è molto mal documentato.
Questo porta gli sviluppatori a creare applicativi poco standardizzati rendendo quindi la loro
classificazione molto esposta ad errori o mismatching.
Un quinto punto, successivo a tutto questo, sarebbe l'aggiunta della funzione di ricerca all'interno
della base di dati XML/RDF creata. Infatti, grazie a query SWRL ad hoc, si potrebbe creare un
motore di ricerca e sostituzione di servizi web in maniera automatica, permettendo di avere un
55
56. servizio online che, una volta richiamato, ricerca al suo interno un degno sostituto al servizio che
ha cessato di funzionare e, se non si trova, compone più servizi in modo tale da avere lo stesso
risultato di prima ma sempre in maniera del tutto automatica.
Si è pensato anche ad un sesto possibile sviluppo futuro, ovvero quello di aggiungere anche una
funzione di pianificazione. Questo significa che: se un utente avesse bisogno di un particolare
servizio, il sistema, grazie ai servizi di cui dispone, potrebbe “pensare” di comporre alcuni dei
servizi allocati al suo interno, sfruttando le regole logiche di cause ed effetto aggregate ai vari
servizi, cosi da raggiungere il target che la ricerca si è posta. Questo comporterebbe l'aggiunta di
un algoritmo che implementi una strategia di ricerca, quasi sicuramente informata, elevando il
sistema stesso a progetto di intelligenza artificiale e non solamente a progetto di ingegneria della
conoscenza; ambiti che, nella maggior parte dei casi, si accavallano e completano a vicenda.
56
57. 7. Glossario
[G.1] Semantificazione : Processo di trasformazione di un documento XML-based in un
documento di tipo RDF-based con l'aggiunta di metadati specifici per creare la base ontologica
da quale partire con un eventuale processo di lettura automatica o classificazione a seconda delle
esigenze.
[G.2] Cameling : Processo di separazione dei nomi, contenuti all'interno di una parola, separati,
una dall'altra, da una maiuscola come iniziale.
[G.3] Tokenizzazione : Processo di eliminazione degli spazi all'interno di una frase in modo tale
da evidenziare le singole parole che la compongono.
[G.4] Crawler : Applicativo web adibito al coping e allo storing di una pagina web per un
successivo processamento con il fine di ricercare un particolare elemento o, più semplicemente,
indicizzare una pagina web (cosa che succede, per esempio, con i motori di ricerca).
[G.5] Stemming : Processo di riduzione alla propria radice di una parola .
[G.6] Parsing : o analisi sintattica, è il processo atto ad analizzare uno stream continuo in
input (letto per esempio da un file o una tastiera) in modo da determinare la sua struttura
grammaticale grazie ad una data grammatica formale. Un parser è un programma che esegue
questo compito.
57
58. 8. Bibliografia
[1] Euzenat, Jérôme, Shvaiko, Pavel, Ontology Matching, 2007, X, 334 p. 67 illus.
[2] Stuart Russel and Peter Norvig, Artificial Intelligence: A Modern Approach
[3] Fensel, D., Lausen, H., Polleres, A., Bruijn, J. De, Stollberg, M.,Roman, D., Domingue, J., Enabling
Semantic Web Services, 2007, XIV, 188 p. 41 illus.
[4] Khalid Elgazzar, Ahmed E. Hassan, Patrick Martin School of Computing, Queen’s University, Canada,
Clustering WSDL Documents to Bootstrap the Discovery of Web Services
[5] Aditya Kalyanpur,Daniel Jiménez Pastor, Steve Battle, Julian Padget Automatic mapping of OWL
ontologies into Java
[6] Documentazione riportata a piè di pagina riguardante tutti i documenti e i particolari utilizzati nella
trattazione
58
