scarica la tesi - Riccardo Falco

Download Report

Transcript scarica la tesi - Riccardo Falco

Alma Mater Studiorum
Università di Bologna
SCUOLA DI SCIENZE
Corso di Laurea in Informatica
GENERAZIONE DI ONTOLOGIE
DA RAPPRESENTAZIONI GRAFICHE
Tesi di Laurea in Tecnologie Web
Relatore:
Chiar.mo Prof.
FABIO VITALI
Presentata da:
RICCARDO FALCO
Correlatore:
Dott.
SILVIO PERONI
Sessione III
Anno Accademico 2012/2013
Indice
Indice
i
Elenco delle gure
iii
1 Introduzione
1
2 Progettazione graca di ontologie
5
2.1
2.2
2.3
2.4
Notazioni grache per ontologie OWL
Notazioni UML-based . . . . . . . . .
2.2.1 ODM . . . . . . . . . . . . . .
Notazioni dedicate . . . . . . . . . .
2.3.1 VOWL . . . . . . . . . . . . .
2.3.2 Graoo . . . . . . . . . . . .
Riepilogo . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 5
. 6
. 6
. 8
. 8
. 10
. 13
3 Il progetto GraMOS
3.1
3.2
3.3
3.4
3.5
15
Panoramica . . . . . . . . . . . . . . . . . . . . . . . .
Manchester OWL syntax . . . . . . . . . . . . . . . . .
Comportamento . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Nessuna verica di correttezza . . . . . . . . . .
3.3.2 Pressi OWL . . . . . . . . . . . . . . . . . . .
3.3.3 Annotazioni rdfs:label e rdfs:comment . . .
3.3.4 Riconoscimento degli assiomi OWL . . . . . . .
3.3.5 Punning . . . . . . . . . . . . . . . . . . . . . .
3.3.6 Gestione di regole non SWRL . . . . . . . . . .
3.3.7 Ordinamento degli statement Manchester . . . .
3.3.8 Mantenimento delle informazioni presentazionali
Assunzioni sul diagramma in input . . . . . . . . . . .
Un esempio reale . . . . . . . . . . . . . . . . . . . . .
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
16
17
17
17
18
18
19
20
20
22
23
24
4 GraMOS - Visione a basso livello
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
XSLT 2.0 . . . . . . . . . . . . . . . . . . .
Strutturazione . . . . . . . . . . . . . . . . .
Trasformazioni parziali . . . . . . . . . . . .
4.3.1 Importazione del diagramma Graoo
4.3.2 Gestione del punning . . . . . . . . .
4.3.3 Attuazione degli assiomi Import . . .
4.3.4 Analisi delle stringhe Manchester . .
4.3.5 Traduzione in Manchester syntax . .
Posizionamento delle edge label . . . . . . .
Formato XML intermedio . . . . . . . . . .
Parametri di trasformazione . . . . . . . . .
Test e valutazioni . . . . . . . . . . . . . . .
Tecnologie adottate . . . . . . . . . . . . . .
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
30
31
32
32
33
33
33
35
37
38
38
5 Conclusioni
41
Bibliograa
43
ii
Elenco delle gure
1.1
Semantic Web Layer Cake . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
La notazione ODM: esempio .
La notazione VOWL: esempio
Legenda dei widget di Graoo
La notazione Graoo: esempio
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
. 9
. 11
. 12
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
Annotazioni rdfs:label e rdfs:comment . . .
Riconoscimento degli assiomi OWL . . . . . . .
Riconoscimento del punning . . . . . . . . . . .
Ordinamento degli statement Manchester . . . .
Mantenimento delle informazioni presentazionali
Diagramma Graoo in input . . . . . . . . . . .
Sorgente GraphML del diagramma Graoo . . .
Ontologia Manchester in output . . . . . . . . .
Validatore OWL della Manchester university . .
Validazione dell'ontologia ottenuta . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.1
Posizionamento delle edge label in yEd . . . . . . . . . . . . . . 34
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
18
19
20
22
23
24
25
26
27
27
Capitolo 1
Introduzione
L'obiettivo di questa tesi consiste nel fornire una panoramica di alcune notazioni grache adottabili per la creazione di modelli ontologici e nel proporre
un motore di generazione di ontologie concrete a partire da rappresentazioni
ontologiche visuali. Questa dissertazione aronta quindi il problema della produzione ontologica, intesa come processo di progettazione e generazione di
ontologie, particolari modelli di rappresentazione della realtà.
Le ontologie sono esplicite specicazioni di una concettualizzazione [GRU95],
dove per concettualizzazione si intende un'astrazione di ciò che si vuole rappresentare. In altre parole un'ontologia permette di descrivere in modo formale
i concetti del dominio del discorso e le relazioni tra di essi in termini di classi,
proprietà, istanze e asserzioni.
Le ontologie risultano fondamentali come mezzo di rappresentazione e condivisione della conoscenza in ambiti quali l'intelligenza articiale, l'ingegneria
della conoscenza e, in particolare, il Web Semantico, la più recente svolta evolutiva intrapresa dal Web nonché contesto entro cui si sviluppa questa tesi. Il
termine semantico indica qui la possibilità di caratterizzare i dati pubblicati
sul Web attribuendo loro un signicato che sia machine-readable, in modo che
esse siano in grado di eettuare non più solo elaborazioni sintattiche bensì veri
e propri ragionamenti. Più propriamente l'obiettivo nale del Semantic Web
è la generazione, accanto al classico Web of documents 1 , di un Web of data, ossia un Web costituito da dati tipati fortemente linkati tra loro (Linked
data ) e interpretabili da sistemi automatici per eettuare query intelligenti e dedurre nuove informazioni a partire da quelle già esistenti [W3C]. Per
dato tipato si intende un dato la cui natura sia stata denita all'interno di
una sorta di vocabolario condiviso. Tali vocabolari sono appunto le ontologie2
e costituiscono i mattoni con cui costruire le basi di conoscenza sulle quali
si poggerà il Semantic Web. Il linguaggio formale con cui vengono denite le
1 L'attuale Web, basato su documenti HTML navigabili tramite link ipertestuali.
2 In realtà i due termini non coincidono esattamente, tendendo ad attribuire alle ontologie una complessità maggiore rispetto ai vocabolari. Tuttavia nel testo i termini verranno
utilizzati in modo equivalente.
1
CAPITOLO 1.
INTRODUZIONE
ontologie in ambito Web è OWL, Ontology Web Language, raccomandazione
W3C [HKP12] e parte sostanziale dello stack di tecnologie alla base del Web
Semantico3 (gura 1.1).
Figura 1.1: Semantic Web Layer Cake. Lo stack rappresenta l'architettura
del Web Semantico e le tecnologie su cui si basa, dal livello sintattico (XML
e gli IRI), agli standard W3C per la gestione della semantica quali RDF,
SPARQL e OWL, al livello applicativo cui si interfaccia l'utente nale.
Seppure siano numerosi i progetti e le aziende che già da anni basano
le proprie ricerche sulle tecnologie alla base del Semantic Web4 , il Web of
data fatica a crescere. Uno dei principali motivi che rende dicoltosa la sua
diusione ritengo sia lo scarso coinvolgimento del grande pubblico del WWW,
estremamente eterogeneo e in gran parte composto da utenti tutt'altro che
esperti nelle tecnologie del Web Semantico. Per favorire la loro partecipazione e
la successiva pubblicazione di dati semantici (Semantic Publishing ) è necessario
lo sviluppo di strumenti che semplichino:
1. La comprensione delle basi di conoscenza esistenti in modo da permetterne il referenziamento da parte dei dati pubblicati.
2. Lo sviluppo e la pubblicazione di nuove ontologie.
3 Semantic Web Layer Cake: http://en.wikipedia.org/wiki/Semantic_Web_Stack.
4 Per esempio Nasa, Google, Facebook, BBC, . . .
2
CAPITOLO 1.
INTRODUZIONE
Il primo passo per favorire la pubblicazione sul Web of data è quindi lo
sviluppo di tecnologie che facilitino l'avvicinamento degli utenti alle basi di
conoscenza esistenti. A tale ne sono state proposti sistemi quali Parrot5 e
LODE (the Live OWL Documentation Environment)6 [PSV13, PER12], in grado di analizzare un'ontologia target e generarne la documentazione necessaria
alla sua rapida comprensione, o quantomeno più pratica rispetto all'analisi
diretta degli statement OWL.
Il passo successivo nella rincorsa al Semantic Publishing è orire agli utenti
del web la possibilità di progettare e generare facilmente le proprie ontologie,
senza richiedere la conoscenza approfondita di una particolare sintassi OWL7 .
È qui che entrano in gioco le notazioni ontologiche visuali ed è sul processo
di produzione ontologica per via graca che si focalizza questa tesi. Il vantaggio nell'utilizzo di notazioni visuali deriva dal fatto che la capacità intuitiva e
cognitiva umana risulta più ecace nel trattamento di informazioni grache
rispetto alle equivalenti forme testuali [FCM10]. Inoltre i modelli ontologici
prodotti costituiscono un eccellente mezzo esplicativo dell'ontologia, attraverso il quale un utente non esperto può captare in modo rapido e intuitivo le sue
informazioni strutturali [W3C13]. È quindi consigliabile arontare la fase di
progettazione ontologica adottando una tra le numerose notazioni ontologiche
grache proposte, quali ODM (Ontology Denition Metamodel)8 , VOWL (Visual notation for OWL ontologies)9 e Graoo (Graphical Framework for OWL
Ontologies)10 .
Per la successiva fase di generazione l'utente potrebbe adottare uno dei
numerosi editor ontologici disponibili, tra i quali Protégé11 spicca per notorietà e validità. Tuttavia una simile soluzione richiede l'abbandono del modello
graco e la riscrittura in forma testuale dell'ontologia corrispondente, introducendo uno sforzo aggiuntivo notevole al processo di produzione ontologica12 .
Alternativamente l'utente potrebbe adarsi a un eventuale tool che permetta l'immediata traduzione del modello ontologico visuale nella corrispondente
ontologia concreta, espressa attraverso una particolare sintassi OWL. È questa
la soluzione oerta dal progetto GraMOS, Graoo to Manchester OWL
Syntax, proposto da questa tesi appunto come punto di incontro tra le due
fasi di progettazione e generazione.
GraMOS è un tool in grado di tradurre le ontologie OWL 2 espresse at5 Parrot homepage:
6 LODE homepage:
http://ontorule-project.eu/parrot.
http://www.essepuntato.it/lode.
7 Il W3C ha denito cinque possibili sintassi OWL: OWL/XML, RDF/XML (l'unica
che dev'essere obbligatoriamente supportata da ogni tool per OWL 2), Turtle, Manchester
?
syntax e una sintassi di tipo funzionale [ ].
8 ODM specication: http://www.omg.org/spec/ODM/.
9 VOWL homepage: http://purl.org/vowl/.
10 Graoo homepage:
http://www.essepuntato.it/graffoo/.
11 Protégé homepage: http://protege.stanford.edu/.
12 Il costo è evidente nel caso in cui l'ontologia debba subire modiche e l'utente desideri
mantenere allineati modello e ontologia.
3
CAPITOLO 1.
INTRODUZIONE
traverso la notazione visuale Graoo in Manchester OWL syntax, una sintassi
compatta e user-friendly per ontologie OWL 2. Per aumentare la leggibilità dell'ontologia generata, GraMOS permette di stampare gli statement Manchester
secondo un ordinamento gerarchico basato sugli assiomi rdfs:subClassOf.
Inoltre GraMOS implementa un meccanismo di auto-riconoscimento degli assiomi OWL tramite un vocabolario dei sinonimi, in modo da incrementare il
livello di usabilità della notazione Graoo.
Le ontologie generate da GraMOS sono risultate valide sia per il validatore
della Manchester University13 (vedi sezione 3.5) sia per l'editor di ontologie
Protégé. L'applicazione è andata quindi a estendere la piattaforma DiTTO
(Diagrams Transformation inTo OWL)14 , un servizio web in grado di generare
ontologie OWL a partire da diagrammi E/R [GP13].
In futuro GraMOS potrebbe essere migliorato per esempio introducendo
meccanismi di traduzione verso dierenti formati di output e ranando l'attuale sistema di conservazione delle informazioni presentazionali del diagramma iniziale in modo da semplicare l'introduzione di un processo di round-trip
tra ontologia formale e ontologia graca.
Nei prossimi capitoli le tematiche qui arontate verranno ulteriormente
analizzate. Inizialmente una panoramica di alcune notazioni grache per ontologie OWL permetterà di meglio comprendere i vantaggi indotti dall'adozione
di una notazione visuale sia durante la fase di progettazione ontologica, sia
per un eventuale condivisione del modello ontologico (capitolo 2). Il progetto
GraMOS verrà quindi proposto come punto di incontro tra le fasi di progettazione e generazione ontologica, analizzandone le funzionalità ad alto livello
e orendo un esempio di reale trasformazione, dal diagramma Graoo alla
validazione dell'ontologia Manchester ottenuta (capitolo 3). Successivamente
GraMOS verrà sezionato per comprenderne la struttura, i principi di funzionamento a basso livello e i parametri che l'utente può sfruttare per adattare il
processo di traduzione alle sue esigenze (capitolo 4). Inne verrà eettuata una
panoramica delle funzionalità di GraMOS migliorabili o mancanti, il cui sviluppo renderebbe la terna Graoo/DiTTO/GraMOS maggiormente appetibile per
la comunità del Semantic Web.
13 Manchester University OWL Validator:
http://owl.cs.manchester.ac.uk/validator/.
14 DiTTO homepage: http://www.essepuntato.it/ditto.
4
Capitolo 2
Progettazione graca di ontologie
La produzione ontologica per il Web, intesa come quell'attività che porti alla generazione di vocabolari utilizzabili per strutturare il Web of data,
è una fase fondamentale per favorire la crescita del Semantic Web. Data la
complessità espressa dalle ontologie e la loro centralità nel processo di Semantic Publishing, la generazione ontologica necessita di una fase preliminare di
progettazione, durante la quale l'utente sia focalizzato sulla struttura dell'ontologia in via di sviluppo. Le notazioni grache per ontologie OWL diventano quindi strumenti fondamentali per l'ideazione e progettazione di ontologie sensate e ben strutturate. Di più, i modelli ontologici ottenuti mediante
tali notazioni costituiscono un perfetto mezzo di comunicazione tra utenti, sia
esperti sia, sopratutto, estranei al mondo dell'ingegneria ontologica, facilitando l'analisi strutturale dell'ontologia e rimanendo (parzialmente) indipendenti
dal particolare linguaggio OWL utilizzato.
Alcuni concetti espressi nei prossimi paragra possono risultare nebulosi
senza una conoscenza elementare di OWL. È quindi consigliabile un'introduzione ai concetti alla sua base tramite [HKP12].
2.1 Notazioni grache per ontologie OWL
OWL è diventato un punto di riferimento come linguaggio di rappresentazione della conoscenza non solo per il Web ma anche per ambiti quali intelligenza articiale e ingegneria dell'intelligenza. Pertanto numerose sono state
le proposte di notazioni grache per ontologie OWL [W3C13], alcune basate
su linguaggi di modellazione già esistenti quale UML, altre create ex-novo per
esprimere ontologie OWL. Tuttavia nessuna di queste notazioni ha prevalso
sulle altre, e tuttora non esiste un formato visuale universalmente accettato o
considerato migliore degli altri nella comunità.
Tipicamente è convinzione diusa che la caratteristica fondamentale di una
buona notazione graca per OWL sia la compattezza [NHL13, BBC10a], in
quanto un modello compatto permette di individuare rapidamente la strut5
CAPITOLO 2.
PROGETTAZIONE GRAFICA DI ONTOLOGIE
tura ontologica. L'utilizzo di widget colorati e la possibilità di caratterizzare
cromaticamente gli elementi del diagramma incrementano ulteriormente l'autoesplicazione della struttura ontologica. Non è tuttavia da trascurare la comprensibilità della notazione, sopratutto qualora il modello ontologico debba
essere condiviso tra utenti con dierenti background. Inne, la capacità di
gestione delle numerose funzionalità introdotte da OWL 2 rispetto alla precedente versione [GW12], potrebbe fare la dierenza nella scelta della notazione
graca da adottare.
2.2 Notazioni UML-based
UML, Unied Modeling Language, è un linguaggio di modellazione gestito
dall'OMG, Object Management Group1 , divenuto standard sia ISO sia de-facto
per la modellazione di sistemi informatici ma anche di domini concettuali.
Risulta quindi ovvio che parte della comunità di esperti in ontologie abbia
proposto dierenti notazioni visuali ontologiche derivanti da questo linguaggio
di modellazione standard e general-purpose. Grazie infatti alla notorietà di
UML, i diagrammi ontologici creati risultano facilmente comprensibili anche
dai non esperti senza un'approfondita introduzione della notazione utilizzata.
Non essendo state generate ex-novo, le notazioni UML potrebbero tuttavia
risultare talvolta eccessivamente verbose, in quanto basate sugli elementi graci
di UML.
2.2.1 ODM
L'ODM, Ontology Denition Metamodel2 , è una delle più diuse notazioni
grache UML-based per ontologie OWL. ODM è infatti un prolo UML standard sviluppato dall'Object Management Group (creatore di UML) e pertanto
largamente considerato come termine di paragone per altre notazioni grache
per ontologie OWL.
Dall'immagine 2.1 si osserva che ODM mette a disposizione due soli tipi di
elementi graci:
I Box rettangolari (elementi UML::Class), per esprimere classi, datarange,
proprietà e istanze. La sezione di box dedicata in UML per le proprietà del nodo permette di attribuire in modo chiaro informazioni aggiuntive, quali le caratteristiche di una object property (nell'esempio
+owl:FunctionalProperty).
I Archi, per esprimere asserzioni, caratterizzati dagli stessi tipi di linea
e di testa presenti in UML. Per esempio gli assiomi rdfs:domain e
1 OMG homepage:
2 Speciche ODM:
http://www.omg.org/.
http://www.omg.org/spec/ODM/1.0/.
6
CAPITOLO 2.
PROGETTAZIONE GRAFICA DI ONTOLOGIE
rdfs:range vengono rappresentati da associazioni, rdfs:subClassOf e
rdfs:subPropertyOf sotto forma di generalizzazioni, rdf:types come
realizzazioni, owl:inverseOf tramite dipendenze.
Figura 2.1: Sezione dell'ontologia MUTO (Modular Unied Tagging
Ontology)
3 rappresentata tramite ODM4 .
ODM ricicla quindi fedelmente gli elementi UML, caratterizzandoli tramite
la denizione di appositi stereotipi (per esempio owl:Class) senza introdurre nuove caratteristiche ad-hoc. L'utilizzo intensivo di etichette stereotipate
favorisce notevolmente l'interpretazione del modello ontologico anche da parte
di utenti non esperti. Inoltre, il fatto di non avere introdotto nuovi elementi graci consente all'utente l'utilizzo di un qualunque editor per diagrammi
UML. Tuttavia la struttura del modello non risulta immediatamente cattura4 MUTO homepage: http://muto.socialtagging.org/core/v1.html.
4 Diagramma tratto da [NHL13].
7
CAPITOLO 2.
PROGETTAZIONE GRAFICA DI ONTOLOGIE
bile a causa sia dell'utilizzo della stessa notazione graca per dierenti tipi di
entità, sia dell'assenza di colorazioni esplicative.
In denitiva, ODM risulta un linguaggio di modellazione ontologica poco
compatto, nel quale entità di tipo dierente vengono rappresentate con stessi elementi graci, ma estremamente esplicativo. ODM non risulta quindi
particolarmente adatto come mezzo di progettazione ontologica, prestandosi
bene tuttavia per la condivisione di modelli ontologici all'interno di comunità
eterogenee.
2.3 Notazioni dedicate
OWL denisce alcune funzionalità che un linguaggio di modellazione UMLbased non può rappresentare in modo chiaro e semplice. Tipico esempio sono
le classi anonime, ossia classi ottenute per composizione insiemistica di altre
classi, restrizione di proprietà o enumerazione di individui ([HKP12] sezione
Advanced Class Relationships). Pertanto sono state proposte dierenti notazioni grache ad-hoc, dotate di costrutti appositi che rendano puliti e compatti i diagrammi ontologici. In questo modo i modelli ottenuti risultano meno
verbosi, ma richiedono che gli utenti vengano introdotti alla notazione visuale
utilizzata.
2.3.1 VOWL
VOWL, Visual Notation for OWL Ontologies5 , è una notazione graca per
ontologie OWL molto compatta e sintetica [NL13, NHL13]. Essa prevede la
progettazione e l'analisi dell'ontologia su tre dierenti layer:
1. Conceptual layer: riguarda classi, proprietà e relazioni tra di essi;
2. Instance layer: la visualizzazione avviene a livello delle istanze e delle
relazioni tra di esse;
3. Integrated layer: integra il layer concettuale con quello delle istanze.
La notazione VOWL è basata su quattro tipi di elementi graci:
I Cerchi, rappresentanti le classi dell'ontologia;
I Settori circolari all'interno delle classi, indicanti gli individui appartenenti a quella classe. Gli individui vengono quindi automaticamente raggruppati assieme alla classe di appartenenza, rendendone immediata l'individuazione da parte dell'osservatore.
5 VOWL homepage:
http://purl.org/vowl/.
8
CAPITOLO 2.
PROGETTAZIONE GRAFICA DI ONTOLOGIE
I Rettangoli, rappresentanti datatype, letterali e valori;
I Archi tra gli elementi precedenti e diversicati per tipo di linea e di testa, indicanti proprietà e asserzioni. Per esempio le relazioni gerarchiche
(rdfs:subClassOf e rdfs:subPropertyOf) vengono chiaramente distinte dagli altri assiomi in quanto rappresentate con una notazione apposita,
in particolare sotto forma di generalizzazioni UML.
Figura 2.2: Vista integrata di una sezione dell'ontologia FOAF (Friend of
6 rappresentata tramite la notazione VOWL7 .
a Friend)
Questa dierenziazione velocizza l'individuazione della struttura ontologica
da parte dell'osservatore. A tale scopo aiutano ulteriormente caratteristiche
quali le dierenti colorazioni degli elementi del diagramma, la dimensione delle
classi proporzionale al grado di connettività con altre entità, l'utilizzo di un
elemento graco apposito per rappresentare in modo compatto l'equivalenza
tra classi.
Tuttavia, proprio la ricerca di compattezza e sinteticità rende i diagrammi
VOWL talvolta dicili da comprendere, richiedendo un'apposita introduzione
della notazione utilizzata. Per esempio la notazione adottata per denotare le
7 FOAF homepage: http://www.foaf-project.org/.
7 Diagramma tratto da http://purl.org/vowl/.
9
CAPITOLO 2.
PROGETTAZIONE GRAFICA DI ONTOLOGIE
caratteristiche di una object property (per esempio F per Functional) oppure
gli operatori insiemistici t (unione), u (intersezione) e ¬ (complementare) per
la composizione di classi, non risultano immediatamente comprensibili senza
una precedente spiegazione. Ancora, l'utilizzo di un solo arco sia per la proprietà diretta sia per quella inversa richiede l'utilizzo di due etichette dierenti,
caratterizzate da un simbolo indicante la direzione dell'arco cui si riferiscono,
notazione non sempre chiara.
Per quanto riguarda la potenza espressiva, pare che la notazione VOWL
non permetta la gestione di tutte le funzionalità di OWL 2, per esempio la
creazione di classi anonime ottenute per restrizione di proprietà8 .
VOWL è una sintassi graca molto compatta e quindi particolarmente adatta per la fase di progettazione ontologica, nella quale si presume che il progettista conosca al dettaglio la notazione utilizzata. Tuttavia l'adozione di questa
notazione potrebbe limitare l'utente nell'utilizzo delle funzionalità di OWL 2.
VOWL risulta invece una scelta rischiosa qualora i modelli ontologici debbano
essere condivisi all'interno di comunità eterogenee, in quanto l'estrema sinteticità comporterebbe una certa dicoltà di interpretazione del diagramma
da parte di quegli utenti estrenei alla notazione utilizzata.
2.3.2 Graoo
Graoo, Graphical Framework for OWL Ontologies9 , è un framework per
la rappresentazione visuale di ontologie OWL 2 [PER13a]. Graoo è infatti sia
una notazione graca ontologica, sia una palette di widget graci integrabile
all'interno dell'editor di diagrammi yEd10 per la creazione di modelli ontologici
basati su tale notazione.
Graoo non è una notazione immediatamente adottabile e interpretabile
da utenti privi di un minimo background di OWL in quanto gli elementi graci sono basati sull'utilizzo della sintassi Manchester, una delle cinque possibili
sintassi per OWL 2 (vedi sezione 3.2). Tuttavia tale sintassi risulta decisamente
user-friendly, rendendo il modello ontologico particolarmente esplicativo e sufcientemente interpretabile da utenti con un minimo background di OWL.
Inoltre questa scelta, insieme alla denizione di widget sia specializzati sia
general-purpose, permette di semplicare la gestione delle funzionalità avanzate di OWL 2, non richiedendo l'introduzione di una sintassi apposita e di
meccanismi di interazione complessi tra gli elementi graci.
Dall'immagine 2.3 si osserva che i widget graci messi a disposizione da
Graoo sono i seguenti:
8 Non è stata trovata alcuna prova che confermi o smentisca questa osservazione.
9 Graoo homepage: http://www.essepuntato.it/graffoo/.
10 yEd homepage:
http://www.yworks.com/.
10
CAPITOLO 2.
PROGETTAZIONE GRAFICA DI ONTOLOGIE
Figura 2.3: Legenda di tutti i widget graci messi a disposizione dalla
notazione Graoo.
I Entità semplici: nodi del diagramma per la rappresentazione di classi,
datatype, individui, letterali, valori e ontologie.
I Entità complesse: nodi che consentono la creazione di restrizioni sia di
classi sia di datatype, utilizzando come etichetta la stringa Manchester
della denizione.
I Proprietà: archi tra i nodi, deniscono object property, data property e
annotation property. Inoltre Graoo mette a disposizione delle property
facility, elementi graci utili per noticare la possibilità di utilizzo di
una particolare property entro un certo dominio e codominio senza però
forzarne la concreta denizione nell'ontologia corrente.
I Assiomi: archi tra i nodi per la specica di asserzioni.
I Additional axiom: box per la denizione di asserzioni aggiuntive, espresse
in sintassi Manchester. Questo tipo di widget risulta estremamente versatile in quanto può essere associato sia a nodi entità tramite appositi
link, sia a property per vicinanza, in modo da attribuire loro informazioni
11
CAPITOLO 2.
PROGETTAZIONE GRAFICA DI ONTOLOGIE
aggiuntive (per esempio caratteristiche di object property, annotazioni,
relazioni tra property, ecc.).
I External rule: box per la specica di regole o vincoli di integrità dell'ontologia non rappresentabili come semplici interazioni tra widget. In particolare questo elemento graco consente la denizione di regole SWRL,
Semantic Web Rule Language, member submission del W3C11 .
I Prex box: box per la denizione dei pressi utilizzati dalle proprietà e
assiomi presenti nel modello ontologico.
Figura 2.4: Sezione dell'ontologia CO (Collection Ontology)
12 rappresen-
tata tramite la notazione Graoo.
Da quanto detto, si deduce che Graoo permetta la rappresentazione anche
di funzionalità complesse di OWL 2. L'utilizzo di widget quali le restrizioni di
classi e di datarange rende la notazione compatta e al tempo stesso poco caotica e decisamente esplicativa. In particolare la essibilità degli additional axiom,
pur abbassando in parte l'intuitività visiva del modello ontologico, permette
11 SWRL:
http://www.w3.org/Submission/SWRL/.
http://purl.org/co.
12 The Collection Ontology:
12
CAPITOLO 2.
PROGETTAZIONE GRAFICA DI ONTOLOGIE
l'immediata gestione di quelle informazioni aggiuntive che altrimenti avrebbero
richiesto la denizione di appositi widget mirati. La possibilità di etichettare
un'unico arco con più valori, aggregati e non, aumenta ulteriormente la compattezza della notazione. Inne, oltre alle colorazioni predenite, yEd permette di
personalizzare cromaticamente gli elementi del modello ontologico, per esempio
per evidenziare un'entità particolarmente rilevante all'interno dell'ontologia.
Graoo risulta quindi un linguaggio di modellazione ontologica estremamente ecace, sopratutto se messo a disposizione di esperti in ontologie OWL.
Durante la fase di progettazione ontologica, il progettista può infatti esprimere
ogni funzionalità di OWL 2 in modo tutto sommato compatto e intuitivo. Inne
si osservi come gli eventuali limiti di comprensibilità dei modelli Graoo da
parte di utenti estranei all'Ontology Web Language siano legati in parte all'utilizzo della Manchester syntax ma sopratutto alla complessità intrinseca delle
funzionalità avanzate di OWL.
2.4 Riepilogo
Le notazioni grache per ontologie OWL costituiscono un mezzo ideale sia
per la condivisione di modelli ontologici, sia per la progettazione di nuove ontologie. In entrambi i casi il linguaggio di modellazione ideale deve risultare
compatto, esplicativo e interpretabile anche da utenti senza una conoscenza
approfondita di ontologie. Tra le notazioni analizzate, ODM risulta assolutamente esplicativo e interpretabile ma aatto compatto. Inoltre si presta male
alla rappresentazione di funzionalità proprie di OWL, essendo basato esclusivamente sugli elementi graci di UML. VOWL al contrario appare estremamente compatto ma non del tutto chiaro senza un'introduzione alla notazione
e apparentemente non in grado di gestire tutte le funzionalità di OWL 2.
Graoo inne risulta particolarmente adatto alla creazione di modelli ontologici con un certo grado di complessità, rimanendo sucientemente compatto
e interpretabile.
Una volta ottenuto il modello di progettazione dell'ontologia, l'utente tipicamente deve adarsi a un editor ontologico quale Protégé, a meno di mettere
mano direttamente agli statement OWL del sorgente ontologico. Alternativamente, un tool in grado di tradurre in modo automatico il modello ontologico
nell'equivalente ontologia OWL semplicherebbe notevolmente il processo di
generazione ontologica. GraMOS, progetto sviluppato per questa tesi e descritto nei prossimi capitoli, si propone di assolvere questo compito consentendo di
ottenere ontologie concrete a partire da modelli Graoo.
13
CAPITOLO 2.
PROGETTAZIONE GRAFICA DI ONTOLOGIE
14
Capitolo 3
Il progetto GraMOS
La crescita del Web Semantico è frenata dalla carenza di strumenti che accompagnino gli utenti non esperti delle tecnologie alla sua base nelle operazioni
di Semantic Publishing, ossia nella pubblicazione di informazioni sul Web of data. Tra i dati pubblicabili le ontologie sono sicuramente le entità che richiedono
il maggiore sforzo, in quanto esse deniscono formalmente i vocabolari cui gli
altri dati faranno riferimento e devono perciò essere progettate con criterio.
Le notazioni visuali per ontologie OWL, oltre a favorire la comprensione delle
ontologie esistenti, ne facilitano la progettazione di nuove anche da parte di
utenti non esperti in una particolare sintassi OWL. Tuttavia, per la successiva
fase di generazione dell'ontologia concreta, gli utenti sono obbligati a mettere
mano a un qualunque editor testuale oppure ad adarsi a un apposito editor
di ontologie quale Protégé, separando quindi la fase di progettazione da quella
di creazione. Il progetto GraMOS permette di evitare questa separazione.
Questo capitolo aronta l'analisi ad alto livello di GraMOS, fornendo numerosi esempi graci abbinati alle corrispondenti traduzioni Manchester ottenibili dal motore di trasformazione in modo da facilitare la comprensione dei
concetti espressi. Anché tali esempi risultino interpretabili è tuttavia necessario avere prima compreso le funzionalità dei singoli widget Graoo [PER13b].
Al contrario la Manchester syntax risulta sucientemente chiara anche senza
un'apposita introduzione, a patto di possedere delle basi di OWL.
3.1 Panoramica
GraMOS è un motore in grado di trasformare ontologie OWL 2 visuali in
equivalenti ontologie formali, realmente iniettabili nel Web of data o importabili in un qualunque editor di ontologie OWL. In particolare GraMOS elabora
modelli ontologici creati tramite Graoo ed emessi dall'editor yEd in formato
GraphML, una notazione XML per esprimere gra [BEL]. L'ontologia generata
è espressa in Manchester syntax, una sintassi OWL particolarmente compatta
e user-friendly, e può essere liberamente importata in un qualunque editor di
15
CAPITOLO 3.
IL PROGETTO GRAMOS
ontologie OWL che supporti la sintassi Manchester oppure essere convertita in
un'altra sintassi OWL quale RDF/XML da un OWL Syntax Converter per la
pubblicazione sul Web of data.
GraMOS è stato pensato e sviluppato con l'obiettivo di estendere DiTTO,
Diagram Transformation into OWL1 , un servizio web che permette la generazione di ontologie OWL concrete a partire da diagrammi di varia natura
[GP13]. In questo modo è possibile usufruire dei vantaggi di una soluzione
Web-based quali la possibilità di utilizzo da parte di chiunque sia provvisto
di un browser con accesso al Web, la libertà per l'utilizzatore dal congurare l'ambiente locale per l'esecuzione, la gestione semplicata del processo di
aggiornamento del software.
3.2 Manchester OWL syntax
Il W3C ha defnito cinque possibili sintassi concrete per l'Ontology Web
Language: OWL/XML, RDF/XML, Turtle, Manchester syntax e una sintassi
di tipo funzionale ([HKP12], sezione OWL Syntaxes). Le sintassi XML-based
risultano sicuramente le più adatte in un contesto orientato alle macchine, in
quanto facilmente elaborabili per manipolazione del DOM (Document Object
Model) e maggiormente supportate dai tool per ontologie2 . Tuttavia nel contesto della generazione ontologica dovrebbe essere la human-readability il fattore determinante nella scelta della sintassi da adottare, dato che esistono
strumenti appositi per eettuare la successiva conversione in una qualunque
delle altre sintassi. Pertanto, per esprimere l'ontologia elaborata da GraMOS è
stata adottata la Manchester OWL syntax, particolarmente compatta e vicina
al linguaggio naturale [HP12].
Prefix:
Prefix:
Prefix:
Prefix:
: <http://MyOntology/>
another: <http://AnotherOntology/>
rdfs: <http://www.w3.org/2000/01/rdf-schema#>
xsd: <http://www.w3.org/2001/XMLSchema#>
Ontology: <http://MyOntology>
Import: <http://AnotherOntology>
Annotations:
rdfs:comment "This is my ontology sample."
Class: another:Human
Class: Person
EquivalentTo: another:Human
1 DiTTO homepage: http://www.essepuntato.it/ditto.
2 La sintassi basata su RDF/XML è l'unica che dev'essere obbligatoriamente supportata
da ogni tool per OWL 2.
16
CAPITOLO 3.
IL PROGETTO GRAMOS
ObjectProperty: hasSpouse
Domain: Person
Range: Person
Characteristics: Symmetric
ObjectProperty: parentOf
Domain: Person
Range: Person
Characteristics: Irreflexive
DataProperty: hasName
Domain: Person
Range: xsd:string
Individual: another:Mary
Individual: John
Types: Person
DifferentIndividuals: John, Mary
Altro fattore non poco inuente nella scelta della sintassi è stato il fatto
che alcuni widget Graoo prevedano l'inserimento di statement Manchester,
per esempio gli additional axiom e le restrizioni di classi e datatype [PER13a].
Adottando la sintassi Manchester è stato quindi possibile evitare la conversione
sintattica del contenuto di tali widget.
3.3 Comportamento
3.3.1 Nessuna verica di correttezza
GraMOS non eettua nessun controllo di correttezza sintattica (per esempio la plausibilità dell'IRI di un presso o la correttezza di una restrizione) né
tantomeno semantica (per esempio l'utilizzo corretto del punning, vedi sezione
3.3.5). Questo è legato sia a fattori di sforzo complessivo di sviluppo, sia alla
scelta di lasciare agli utenti piena libertà di sperimentazione.
3.3.2 Pressi OWL
OWL denisce quattro pressi standard, non ridenibili dall'utente: rdf,
rdfs3 , owl, xsd4 . Gli IRI basati su di essi deniscono infatti il vocabolario
privato di OWL ([MPP12], sezione IRIs). Dato l'utilizzo frequente di questi
3 RDFS: RDF-Schema.
4 XSD: XML-Schema Datatype.
17
CAPITOLO 3.
IL PROGETTO GRAMOS
pressi all'interno di una qualunque ontologia, GraMOS permette all'utente
di non dichiararli in modo esplicito, ma, nel caso in cui siano eettivamente
utilizzati, essi verranno inseriti automaticamente nell'ontologia nale.
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs
http://www.w3.org/2000/01/rdf-schema#
owl
http://www.w3.org/2002/07/owl#
xsd
http://www.w3.org/2001/XMLSchema#
3.3.3 Annotazioni rdfs:label e rdfs:comment
Spesso nella generazione di ontologie risulta pratico per l'utente fare riferimento a speciche entità non tramite l'IRI o il CURIE bensì attraverso semplici
etichette facilmente interpretabili. Analogamente può ulteriormente migliorare
la human-readability di un'entità l'applicazione di un commento che la descriva. Questi due tipi di informazioni sono esprimibili in OWL tramite annotazioni
rdfs:label e rdfs:comment.
Dato che l'editor yEd ore all'utente la possibilità di caratterizzare ogni
widget con una descrizione testuale, visibile come popup facendo hovering del
widget col mouse, si è scelto di sfruttare tale informazione come sorgente per la
generazione automatica di etichette e commenti. In particolare per GraMOS:
I Il valore della proprietà rdfs:label è dato dalla prima riga non vuota
della descrizione;
I Il valore della proprietà rdfs:comment è ottenuto da tutto ciò che segue.
Class: Eagle
Annotations:
rdfs:label "Eagle class",
rdfs:comment "The class
of all the eagles"
Figura 3.1: L'editor yEd permette l'attribuzione di una descrizione a ogni elemento graco. Facendo hovering di un widget appare un popup
indicante l'eventuale descrizione a esso attribuita dall'utente. Tale descrizione viene tradotta da GraMOS come annotazioni
rdfs:comment.
rdfs:label
e
3.3.4 Riconoscimento degli assiomi OWL
Spesso, durante la fase di sviluppo di un'ontologia, è facile confondere i
pressi da utilizzare per referenziare un particolare assioma OWL, oppure non
18
CAPITOLO 3.
IL PROGETTO GRAMOS
ci si ricorda la forma esatta dell'assioma5 . Per tale motivo si è ritenuto che
un meccanismo di autoriconoscimento degli assiomi OWL incrementasse particolarmente il livello di usabilità dell'applicazione. GraMOS fornisce quindi
supporto allo sviluppatore di ontologie OWL riconoscendo le più comuni varianti degli assiomi OWL, denite all'interno di un vocabolario dei sinonimi
liberamente estendibile, e consentendo di conseguenza l'utilizzo di formule più
vicine al linguaggio naturale (per esempio subproperty o sub_property_of)
in sostituzione all'esatto valore dell'assioma (rdfs:subPropertyOf).
Class: Animal
Class: Eagle
SubClassOf: Animal
Individual: Mary
Individual: John
DifferentFrom: Mary
Figura 3.2: Per favorire l'editing dell'ontologia graca, GraMOS è in grado di riconoscere le principali varianti degli assiomi OWL. In questo caso gli archi
sub_class_of e different vengono riconosciti rispettivardfs:subClassOf e owl:differentFrom e tradotti
mente come assiomi
di conseguenza nella corrispondente forma Manchester.
3.3.5 Punning
Nella sua seconda versione, OWL introduce meccanismi sia per abbassare
la verbosità di alcune operazioni6 , sia per aumentare l'espressività del linguaggio [GW12]. Una caratteristica interessante è sicuramente il punning 7 , un
meccanismo che permette di fare metamodeling sulle entità dell'ontologia, incrementando la potenza espressiva del linguaggio. In OWL 2 è infatti possibile
utilizzare lo stesso IRI per referenziare oggetti di tipo dierente, per esempio il
nome Eagle per indicare sia una classe, la classe di tutte le aquile, sia un individuo, rappresentante la specie Eagle appartenente alla (meta)classe di tutte
le specie animali.
Tuttavia il linguaggio pone anche di limiti ai gradi di polimorsmo utilizzabili, in particolare uno stesso IRI non può indicare contemporaneamente
I una classe e un datatype,
I property di tipo dierente.
5 rdf:subClassOf oppure rdfs:subClassOf? rdfs:subClass oppure rdfs:subClassOf?
6 Zuccheri sintattici, per esempio l'unione di classi disgiunte.
7 Punning, letteralmente gioco di parole.
19
CAPITOLO 3.
IL PROGETTO GRAMOS
GraMOS supporta l'utilizzo del punning all'interno dei diagrammi Graoo,
non eettuando tuttavia alcuna verica circa il suo uso corretto.
Class: AnimalSpecies
Class: Eagle
Individual: Eagle
Types: AnimalSpecies
Figura 3.3: GraMOS è in grado di rilevare l'utilizzo del punning. Il tipo
dinamico di un nodo del diagramma coinvolto in un'asserzione dipende
infatti dal valore dell'assioma. In questo caso
rdf:type,
types
identica l'assioma
il quale richiede un soggetto di tipo individuo e un oggetto di
tipo classe. L'entità
Eagle
corrisponde quindi sia a una classe, sia a un
individuo.
3.3.6 Gestione di regole non SWRL
Tramite l'introduzione di un widget apposito, Graoo consente la specica di regole SWRL, Semantic Web Rule Language8 . Tali regole possono
essere tradotte in modo immediato in Manchester syntax grazie all'apposita clausola Rule. Tuttavia l'utente può non avere familiarità con SWRL e
preferire adottare una qualunque altra notazione con stesse capacità espressive, per esempio una query CONSTRUCT in SPARQL9 . Dato che tali vincoli
potrebbero non risultare direttamente rappresentabili in sintassi Manchester,
GraMOS assume un'atteggiamento cauto, introducendo un'apposita annotation property graffoo:has<Lang>Rule10 (dove <Lang> rappresenta il nome
del linguaggio per regole utilizzato) priva di dominio e codominio attraverso
la quale le regole possono essere espresse come semplici annotazioni associate
all'ontologia.
3.3.7 Ordinamento degli statement Manchester
GraMOS si conforma all'usuale ordinamento delle ontologie OWL 2 espresse
in sintassi Manchester, producendo un output strutturato secondo lo schema
seguente:
1. Dichiarazione dei pressi;
8 SWRL specication: http://www.w3.org/Submission/SWRL/.
9 SPARQL specication: http://www.w3.org/TR/rdf-sparql-query/.
10 Il CURIE è in realtà un IRI in quanto il presso
to
graffoo è espanso con l'URI privahttp://www.essepuntato.it/graffoo/autoGeneratedEntities/ in modo da evitare
conitti con un eventuale presso omonimo.
20
CAPITOLO 3.
IL PROGETTO GRAMOS
2. Dichiarazione dell'ontologia corrente, eventuali statement Import e annotazioni riferite all'ontologia corrente;
3. Dichiarazione nell'ordine di classi, datarange, object/data/annotation
property e individui (le entità sullo stesso livello vengono ordinate alfabeticamente);
4. Eventuali statement Rule per la specica di regole SWRL.
Nonostante la human-readability dell'ontologia risultante dalla trasformazione non sia funzionale al suo successivo utilizzo, si è scelto di semplicare
ulteriormente l'interazione dell'utente con gli statement Manchester fornendo
anche un'ordinamento alternativo di tipo gerarchico. In particolare le classi
dell'ontologia vengono dichiarate seguendo una visita top-down delle gerarchie denite dagli assiomi rdfs:subClassOf, a partire dalla classe universale
owl:Thing11 . La dichiarazione di ogni classe viene seguita dalle dichiarazioni
delle property che hanno per dominio tale classe e dai suoi individui, facilitando la comprensione strutturale dell'ontologia. Anche in questo caso, le entità
appartenenti allo stesso livello vengono ordinati alfabeticamente.
Di seguito sono comparati gli output Manchester generati dal diagramma
Graoo rappresentato secondo le due dierenti politiche di ordinamento delle
entità.
11 La classe
owl:Thing
è la superclasse universale dalla quale tutte le classi derivano.
Per completezza dell'ontologia nale, essa viene dichiarata automaticamente dal tool di
trasformazione.
21
CAPITOLO 3.
IL PROGETTO GRAMOS
# Basic Sorting
Class: Animal
SubClassOf: LivingBeing
Class: Cat
SubClassOf: Animal
Class: Human
SubClassOf: Animal
Class: LivingBeing
Class: Mineral
Class: owl:Thing
Class: Vegetable
SubClassOf: LivingBeing
ObjectProperty: parentOf
Domain: LivingBeing
Range: LivingBeing
Individual: John
Types: Human
Individual: Poochie
Types: Cat
Figura
3.4:
Oltre
# Hierarchic Sorting
Class: owl:Thing
Class: LivingBeing
ObjectProperty: parentOf
Domain: LivingBeing
Range: LivingBeing
Class: Animal
SubClassOf: LivingBeing
Class: Cat
SubClassOf: Animal
Individual: Poochie
Types: Cat
Class: Human
SubClassOf: Animal
Individual: John
Types: Human
Class: Vegetable
SubClassOf: LivingBeing
Class: Mineral
all'ordinamento
tipico
delle
ontologie
espresse
in
Manchester syntax (colonna sinistra), GraMOS supporta anche un ordinamento di tipo gerarchico basato sugli assiomi
rdfs:subClassOf
(colonna
destra).
3.3.8 Mantenimento delle informazioni presentazionali
Una funzionalità interessante nell'ambito Graoo/GraMOS è la possibilità di eettuare il round-trip delle ontologie concrete, ottenute da diagrammi
Graoo tramite GraMOS, nuovamente verso la notazione Graoo. Per facilitare un futuro sviluppo di questa estensione, è stato introdotto un sistema
semplicato e opzionale di mantenimento delle informazioni presentazionali di
alcuni widget. Date alcune complicazioni, in primis il complesso sistema utilizzato da yEd per il posizionamento degli archi (vedi sezione 4.4), il problema
è stato appena scalto, memorizzando informazioni basilari quali il posizionamento assoluto, la dimensione del box e la colorazione adottata per i soli
widget di tipo class, datarange e individual. In particolare, tali informazioni
vengono memorizzate sottoforma di annotazioni graffoo:hasAppearance12 ,
introdotte appositamente nell'ontologia.
12 Il CURIE è espanso, analogamente alle annotation property
22
graffoo:has<Lang>Rule.
CAPITOLO 3.
IL PROGETTO GRAMOS
Class: Eagle
Annotations: <http://www.essepuntato.it/
graffoo/autoGeneratedEntities/hasAppearance>
"x=363.015889485677 y=264.0 width=81.968221
height=44.0 fill-color=#FFFF00"
AnnotationProperty: <http://www.essepuntato.it/
graffoo/autoGeneratedEntities/hasAppearance>
Figura 3.5: Per facilitare la futura implementazione di un processo di
round-trip tra Graoo e OWL, GraMOS memorizza alcune informazioni
presentazionali dei nodi di tipo classe, datatype e individuo sotto forma
di apposite annotazioni.
3.4 Assunzioni sul diagramma in input
GraMOS non eettua nessun controllo di correttezza sul diagramma Graffoo ricevuto in input, assumendone la validità e cercando di restituire sempre
un risultato, eventualmente insensato. Di conseguenza l'utente non è in grado
di stabilire la validità dell'ontologia generata se non interrogando successivamente un validatore Manchester. Di seguito sono pertanto elencate le assunzioni eettuate dal motore di trasformazione sul diagramma in input, in modo
da fornire all'utente delle linee guida per la creazione di ontologie Graoo che
permettano di ottenere tramite GraMOS ontologie nali valide.
I Il diagramma deve denire una sola main ontology, intesa come quell'ontologia che non viene importata da nessun'altra ontologia.
I L'ontologia deve denire tutti i pressi utilizzati, anche i pressi delle
entità appartenenti a ontologie importate. È possibile invece non denire
i pressi standard di OWL (sezione 3.3.2).
I Le restrizioni (sia di classi sia di datarange) non possono essere soggetti
di asserzioni.
I I widget non possono essere ruotati in quanto questo minerebbe il meccanismo di attribuzione degli additional axiom alle property (sezione
4.4).
I L'utente può liberamente adattare la colorazione dei widget utilizzati alle
sue preferenze o esigenze, in quanto il loro riconoscimento è basato sulle
caratteristiche strutturali quali la forma del nodo, il tipo di bordo, la
linea e gli end-point dell'arco, ecc.
23
CAPITOLO 3.
IL PROGETTO GRAMOS
3.5 Un esempio reale
Prima di analizzare GraMOS da un punto di vista a basso livello, viene
di seguito proposto un esempio di reale trasformazione, in modo da fornire
all'utente una prova tangente dell'ecacia di GraMOS. L'input della trasformazione è costituito da una sezione di CO, the Collection Ontology13 , nella
quale si è fatto uso di un discreto numero di widget graoo. Dal diagramma
Graoo rappresentante tale sezione di ontologia (immagine 3.6), in particolare
dal le GraphML che codica il diagramma (immagine 3.7), GraMOS genera
l'ontologia OWL 2 equivalente espressa in Manchester syntax (immagine 3.8).
Tuttavia l'ontologia ottenuta deve risultare valida anché sia eettivamente
utile e quindi iniettabile nel Web of data o importabile in un editor ontologico
quale Protégé. L'utilizzo del validatore OWL 2 della Manchester University14
(immagine 3.9) assolve questo scopo, dimostrando la validità dell'ontologia
generata (immagine 3.10).
Figura 3.6: Sezione dell'ontologia CO (the Collection Ontology) espressa
tramite la notazione Graoo.
13 The Collection Ontology: http://purl.org/co.
14 Validatore Manchester: http://owl.cs.manchester.ac.uk/validator/.
24
CAPITOLO 3.
IL PROGETTO GRAMOS
Figura 3.7: Sorgente del diagramma Graoo. I diagrammi generati dall'editor yEd sono codicati in formato GraphML, una notazione XML per
descrivere gra. In particolare i nodi appartenenti al formato GraphML
sono quelli con il namespace di default, gli altri sono elementi strutturali
introdotti da yEd.
25
CAPITOLO 3.
IL PROGETTO GRAMOS
Figura 3.8: Ontologia Manchester emessa in output da GraMOS in seguito
all'elaborazione del diagramma Graoo.
26
CAPITOLO 3.
IL PROGETTO GRAMOS
Figura 3.9: Il validatore OWL della Manchester University permette la
validazione di ontologie OWL 2 espresse in una qualunque delle cinque
sintassi concrete OWL.
Figura 3.10: L'ontologia ottenuta risulta valida per il validatore della
Manchester University.
27
CAPITOLO 3.
IL PROGETTO GRAMOS
28
Capitolo 4
GraMOS - Visione a basso livello
Nel processo di generazione ontologica, GraMOS permette la traduzione
automatica di modelli graci creati tramite Graoo in corrispondenti ontologie
concrete espresse in sintassi Manchester, sposando progettazione e creazione
ontologica in un'unica fase. Il capitolo precedente ha permesso di analizzare il
comportamento ad alto livello di GraMOS e di comprendere i requisiti che deve
soddisfare un diagramma Graoo per portare alla generazione un'ontologia
valida (a meno di errori interni al modello ontologico). Qua un'analisi a più
basso livello consente di indagare le tecnologie e i meccanismi alla base del tool
di traduzione.
4.1 XSLT 2.0
GraMOS è un motore di trasformazione basato esclusivamente sulla tecnologia XSLT, Extensible Stylesheet Language Transformation. L'adozione sistematica di XSLT è dovuta al fatto che le precedenti funzionalità di DiTTO
fossero già implementate da motori XSLT [GP13], rendendo quindi possibile
l'immediata integrazione di GraMOS senza modiche sostanziali del servizio
Web. Inoltre XSL risulta particolarmente pratico per eettuare operazioni di
accesso e generazione di alberi XML, grazie all'utilizzo naturale delle espressioni XPath. In particolare la sua seconda versione, XSLT 2.0, basata su XPath
2.0, introduce numerose funzionalità che semplicano notevolmente la vita dello sviluppatore [BBC10b, KAY07]. Tuttavia lo stile funzionale che lo caratterizza, in particolare l'immutabilità delle variabili XSLT e l'utilizzo della ricorsione
come unica forma di iterazione indeterminata, ha reso dicoltosa la progettazione e lo sviluppo delle fasi di trasformazione che richiedessero la frequente
modica di strutture dati intermedie.
29
CAPITOLO 4.
GRAMOS - VISIONE A BASSO LIVELLO
4.2 Strutturazione
Il progetto GraMOS si compone di quattro moduli XSLT, un le XML di
congurazione e un DTD per la denizione delle entità XML:
main.xsl : foglio di stile principale, denisce l'entry point della trasformazione
richiamando i template deniti in translation.xsl e si occupa dell'output del risultato nale ed eventualmente, per favorire il debugging, dei
risultati parziali1 .
translation.xsl : implementa l'eettiva trasformazione, denendo le variabili
globali risultanti dall'importazione iniziale del diagramma GraphML e i
template nominali richiamati da main.xsl per eettuare le successive
trasformazioni intermedie.
utils.xsl : denisce metodi di utilità generale utilizzati durante l'intera elaborazione.
config.xsl : si interfaccia con il le di congurazione config.xml denendo
variabili globali per l'accesso ai valori di congurazione da parte degli
altri moduli XSLT. Inoltre denisce i parametri accettati dal motore di
trasformazione.
config.xml : le XML di congurazione, denisce alcuni valori che inuiscono
sulla trasformazione, quali i valori di default dei parametri XSLT. Inoltre
denisce un vocabolario di sinonimi per il riconoscimento automatico
degli assiomi OWL, la loro traduzione in Manchester syntax e i tipi di
widget accettabili per il soggetto e l'oggetto dell'assioma (per eettuare
operazioni di punning).
entities.dtd : denisce le entità XML rappresentanti i valori costanti utilizzati durante la trasformazione.
4.3 Trasformazioni parziali
Per abbassare la complessità delle operazioni di traduzione dell'ontologia
dal formato Graoo alla Manchester syntax, GraMOS sfrutta una serie di
trasformazioni parziali successive, ognuna delle quali riceve in input il risultato
della precedente elaborazione. In questo modo ogni fase risolve un ben preciso
set di problemi, facilitando sia lo sviluppo sia il debugging. In particolare,
ogni trasformazione parziale genera un RTF, Result Tree Fragment, un albero
XML che descrive le elaborazioni eettuate sull'intera ontologia iniziale no a
1 La versione 2.0 di XSLT permette output multipli.
30
CAPITOLO 4.
GRAMOS - VISIONE A BASSO LIVELLO
quel momento2 . Seppure questi RTF derivino da elaborazioni dierenti, i dati
rappresentati al loro interno condividono il medesimo formato (sezione 4.5).
Si possono identicare cinque trasformazioni parziali, ognuna della quali
genera un corrispondente RTF.
4.3.1 Importazione del diagramma Graoo
L'ontologia graphml viene tradotta in un formato XML intermedio più
compatto e maneggevole. In particolare l'albero XML che denisce l'ontologia
GraphML viene visitato, per ogni tipo di widget Graoo previsto viene generato un RTF globale apposito e i risultati ottenuti vengono fusi in un unico
albero. La generazione di RTF globali indipendenti permette di sfruttare gli
RTF già deniti nella creazione dei successivi3 , riducendo la complessità della
trasformazione. Di seguito sono elencate alcune delle operazioni fondamentali
eettuate in questa fase:
I Attribuzione di ogni elemento alla sua ontologia di appartenenza e, nel
caso di entità, generazione delle annotazioni rdfs:isDefinedBy sotto
forma di additional axiom a esse associati.
I Splitting degli archi dotati di etichette multiple e attribuzione di un id
univoco a ognuno di essi.
I Generazione di annotazioni rdfs:label e rdfs:comment sotto forma
di additional axiom, per quelle entità provviste di descrizione fornita
dall'utente.
I Scansione degli assiomi ed eventuale loro riconoscimento all'interno del
vocabolario degli assiomi OWL denito in config.xml. Gli assiomi riconosciuti vengono tradotti nella corrispondente notazione Manchester
e con essi vengono memorizzati i tipi accettati per il soggetto e l'oggetto dell'asserzione (informazioni necessarie per attuare il punning di tali
entità).
I Attribuzione degli additional axiom alle entità cui si riferiscono.
2 Un RTF è una variabile XSLT di tipo nodo che denisce un albero XML. Gli RTF
erano già presenti in XSLT 1.0, ma dalla versione 2.0 è possibile navigarli tramite espressioni XPath. Questo permette di utilizzarli, oltre che per conservare risultati di elaborazioni
parziali, anche come risultati strutturati restituibili da funzioni XSLT user-dened (altra
funzionalità introdotta in XSLT 2.0).
3 XSLT non impone che una variabile globale referenziata venga dichiarata prima del suo
referente, purché ovviamente non ci siano dipendenze cicliche.
31
CAPITOLO 4.
GRAMOS - VISIONE A BASSO LIVELLO
4.3.2 Gestione del punning
In questa fase viene eettuato il punning delle entità che intervengono come
soggetto/oggetto di asserzioni. In particolare per ogni assioma viene estrapolato il tipo atteso per il soggetto/oggetto dell'assioma e, se questo non coincide
con il tipo corrente dell'entità, l'entità viene duplicata e l'assioma viene aggiornato per referenziare il nuovo nodo XML. Il punto delicato di questa fase
è la determinazione del tipo cui convertire l'entità soggetto/oggetto. L'albero
delle scelte implementato dal motore XSLT è schematizzato come segue:
1. L'assioma non è uno degli assiomi OWL (caso banale): l'entità sorgente è necessariamente un individuo, mentre quella target è un individuo se il predicato dell'assioma utilizza una object property, altrimenti
(data/annotation property) è un necessariamente un letterale.
2. L'assioma è uno degli assiomi OWL: il tipo nale dell'entità è determinato da una dei seguenti rami, con priorità decrescente:
(a) Il tipo corrente dell'entità è già uno dei tipi accettati dall'assioma4 :
l'entità rimane immutata.
(b) L'assioma prevede entità soggetto e oggetto dello stesso tipo5 : il tipo
nale è determinato dai tipi compatibili dell'altro end-point e delle
sue eventuali repliche nel diagramma.
(c) L'assioma prevede entità soggetto e oggetto non necessariamente
dello stesso tipo: nel caso di assiomi rdfs:domain e rdfs:range il
tipo nale può essere estrapolato in funzione sia dell'assioma che
del tipo dell'altro end-point o da eventuali sue repliche, altrimenti viene determinato da eventuali repliche dell'entità corrente nel
diagramma.
(d) Il tipo nale è il tipo di default accettato dall'assioma6 .
4.3.3 Attuazione degli assiomi Import
In seguito all'eventuale duplicazione delle entità per punning, vengono attuati gli assiomi owl:imports. In particolare, le entità denite in ontologie importate e referenziate da qualche arco appartenente all'ontologia che importa,
entrano anch'esse a fare parte di tale ontologia.
4 Per esempio, l'entità è un individuo e l'assioma è di tipo rdf:type.
5 Per esempio, l'assioma owl:disjointWith prevede che le entità coinvolte siano entrambe
classi.
6 Per esempio,
rdfs:subPropertyOf
è un assioma valido per ogni tipo di property, ma
un'operazione di punning basato su di esso utilizza come valore di default il tipo annotation
property.
32
CAPITOLO 4.
GRAMOS - VISIONE A BASSO LIVELLO
4.3.4 Analisi delle stringhe Manchester
Graoo permette che i widget testuali quali class rectriction, datarange
restriction e additional axiom facciano riferimento a entità non già denite
esplicitamente dall'utente. In questa fase GraMOS analizza quindi le stringhe
Manchester ed eettua una dichiarazione automaticha di quelle entità in esse
rilevate e non già dichiarate7 . La ricerca avviene sfruttando la versatilità delle
espressioni regolari.
4.3.5 Traduzione in Manchester syntax
Ultima fase della trasformazione, l'ontologia subisce l'eettiva traduzione
dal formato XML intermedio alla sintassi Manchester, ordinando gli stament
OWL secondo una delle due possibili modalità viste in precedenza. Il risultato
emesso è in realtà ancora un RTF: ogni ontologia eettivamente presente nel
diagramma Graoo iniziale viene infatti incapsulata all'interno di un nodo
ontology in modo da permetterne la stampa dierenziata su le distinti oppure
l'output della sola main ontology.
4.4 Posizionamento delle edge label
Graoo permette l'associazione di additional axiom a entità sia di tipo nodo
(ontologie, classi, datarange, individui) sia di tipo arco (proprietà). Tuttavia,
mentre gli additional axiom associati a entità di tipo nodo sono direttamente
linkati ai propri target, l'associazione con le proprietà si basa sulla vicinanza
tra il box rappresentante l'assioma e la label dell'arco. In particolare, dato un
additional axiom non direttamente linkato ad alcun nodo, si assume che esso sia
associato a quella property label il cui box sia il più vicino al box dell'assioma.
Tuttavia l'intricato sistema di posizionamento utilizzato dall'editor yEd per
le etichette degli archi comporta che l'esplicitazione di questa associazione sia
un'operazione tutt'altro che banale. Infatti, mentre i nodi del diagramma sono
localizzati con coodinate assolute rispetto al vertice top-left del diagramma, le
coordinate del box che denisce l'etichetta di un arco sono relative al punto di
intersezione tra il box del nodo sorgente dell'arco e l'arco stesso. La complessità
è alta a tal punto da comportare che questa minima caratteristica di Graoo
si traduca nella fase di elaborazione più intricata nell'intera trasformazione,
richiedendone una trattazione autonoma dal resto del processo di traduzione.
Per facilitare l'attribuzione degli additional axiom alle etichette degli archi,
sono stati deniti tipi di dato ad-hoc quali punti, rette, segmenti e box8 e
implementati dierenti meccanismi basati su di essi.
7 In un'ontologia OWL tutte le entità referenziate devono essere dichiarate.
8 I costruttori di tali tipi di dato sono funzioni che restituiscono alberi XML con una
determinata struttura interna.
33
CAPITOLO 4.
GRAMOS - VISIONE A BASSO LIVELLO
Figura 4.1: Al contrario dei nodi, le etichette degli archi in yEd non sono
posizionate in modo assoluto bensì secondo un complesso sistema di posizionamento relativo. Si noti che i nodi sorgenti non sono necessariamente i nodi da cui ha visibilmente inizio l'arco (questo ne è un esempio),
bensì quei nodi utilizzati come sorgenti dell'arco durante la stesura del
diagramma (successivamente possono essere invertiti).
I Determinazione dei punti che deniscono il primo segmento dell'arco (il
segmento che interseca il nodo sorgente) ed eventuale calcolo delle loro
coordinate assolute9 .
I Calcolo dei segmenti che deniscono i lati del box sorgente. Tipicamente
i lati dei nodi sono orizzontali e verticali. Tuttavia i datatype sono dotati
di lati ogliqui, la cui pendenza è calcolata in funzione delle dimensioni del
box10 . Si assume invece che i nodi non abbiano subito rotazioni durante
l'editing del diagramma.
I Calcolo del punto di intersezione tra l'arco e uno dei quattro lati del box
del nodo sorgente, operazione basata sull'intersezione tra rette e verica
che il punto ottenuto appartenga eettivamente ai segmenti interessati.
Tuttavia, dato che le coordinate assolute calcolate del punto sorgente
dell'arco potrebbero cadere leggermente fuori dal box del nodo sorgente
(eventualità che impedirebbe di trovare il punto di intersezione tra i
segmenti), è stato necessario implementare un meccanismo che, durante
la verica di appartenenza del punto ai segmenti interessati, consideri
9 Il primo e l'ultimo punto all'interno del path di un arco sono localizzati relativamente
al centro del box del nodo rispettivamente sorgente e target.
10 In yEd il vertice top-left di un nodo con forma a parallelogramma è shiftato verso
destra del 10% della sua larghezza rispetto alla posizione del box. Analogamente il vertice
bottom-right è shiftato verso sinistra.
34
CAPITOLO 4.
GRAMOS - VISIONE A BASSO LIVELLO
tolleranze sempre maggiori no a esito positivo. Questo garantisce che
l'intersezione restituisca sempre almeno un punto.
I Implementazione della radice quadrata per approssimazioni successive
tramite il metodo di Newton11 , necessario per determinare la distanza
tra due punti del piano cartesiano non allineati. In base a esso, l'approssimazione (n + 1) esima della radice quadrata di un numero N è
data da
N
1
a(n) +
a(n + 1) =
2
a(n)
4.5 Formato XML intermedio
GraMOS eettua la traduzione dell'ontologia Graoo per trasformazioni
successive ed elaborazione di RTF parziali. Questi costituiscono di fatto le
strutture dati utilizzate dal motore XSLT per rappresentare e manipolare l'ontologia. Il seguente DTD12 descrive il formato XML interno adottato dagli RTF
intermedi:
<!ELEMENT ontology EMPTY>
<!ATTLIST ontology
id
ID
name
CDATA
main-ontology
CDATA
<!ELEMENT prefix EMPTY>
<!ATTLIST prefix
prefix
CDATA
uri
CDATA
ontology-id
IDREFS
#REQUIRED
#REQUIRED
#FIXED ""
>
#REQUIRED
#REQUIRED
#IMPLIED
>
<!-- Same structure for class, class-restriction, datarange,
datarange-restriction, individual and literal elements -->
<!ELEMENT class EMPTY>
<!ATTLIST class
id
ID
#REQUIRED
name
CDATA
#REQUIRED
ontology-id
IDREFS
#REQUIRED
appearance
CDATA
#IMPLIED
>
<!-- Same structure for object-property, data-property
11 Il metodo di Newton, o metodo di Newton-Raphson, o metodo delle tangenti, permette
di calcolare in modo approssimato una soluzione di un'equazione della forma
approssimando iterativamente la funzione con la sua tangente.
Metodo di Newton su Wikipedia:
f (x) = 0
http://en.wikipedia.org/wiki/Newton's_method.
http://www.w3.org/TR/REC-xml/#elemdecls.
12 DTD, Document Type Denition:
35
CAPITOLO 4.
GRAMOS - VISIONE A BASSO LIVELLO
and annotation-property -->
<!ELEMENT object-property EMPTY>
<!ATTLIST object-property
id
ID
name
CDATA
source-id
IDREF
target-id
IDREF
ontology-id
IDREFS
#REQUIRED
#REQUIRED
#REQUIRED
#REQUIRED
#REQUIRED
>
<!-- Same structure for object-property-facility,
data-property-facility and annotation-property-facility -->
<!ELEMENT object-property-facility EMPTY>
<!ATTLIST object-property-facility
id
ID
#REQUIRED
name
CDATA
#REQUIRED
ontology-id
IDREFS
#REQUIRED >
<!ELEMENT axiom EMPTY>
<!ATTLIST axiom
id
ID
name
CDATA
source-id
IDREF
target-id
IDREF
ontology-id
IDREFS
owl-axiom
CDATA
domain-type
NMTOKENS
range-type
NMTOKENS
<!ELEMENT additional-axiom EMPTY>
<!ATTLIST additional-axiom
name
CDATA
target-id
IDREF
ontology-id
IDREFS
<!ELEMENT rule EMPTY>
<!ATTLIST rule
name
CDATA
ontology-id
IDREFS
#REQUIRED
#REQUIRED
#REQUIRED
#REQUIRED
#REQUIRED
#FIXED ""
#IMPLIED
#IMPLIED
>
#REQUIRED
#REQUIRED
#REQUIRED
>
#REQUIRED
#REQUIRED
>
<!ELEMENT root (ontology | prefix | class |
class-restriction | datarange | datarange-restriction |
individual | literal | object-property |
data-property | annotation-property |
object-property-facility | data-property-facility |
annotation-property-facility | axiom |
additional-axiom | rule)* >
36
CAPITOLO 4.
GRAMOS - VISIONE A BASSO LIVELLO
In particolare:
I Gli attributi id identicano univocamente i nodi XML nella struttura
dati, referenziati dagli attributi ontology-id, source-id e target-id.
Nel caso in cui sia attivata la modalità debug, tali referenze sono inoltre
accompagnate da corrispondenti attributi ontology-name, source-name,
target-name specicanti il valore dell'attributo name del nodo referenziato, in modo da favorire l'analisi dei risultati intermedi.
I L'attributo vuoto main-ontology identica la main ontology del diagramma, unica per le assunzioni sul diagramma in input.
I L'attributo vuoto owl-axiom viene assegnato a quegli assiomi riconosciuti da GraMOS all'interno del vocabolario degli assiomi OWL 2, e determina la presenza degli attributi domain-type e range-type, utilizzati
per l'eventuale punning del soggetto/oggetto dell'assioma.
4.6 Parametri di trasformazione
GraMOS consente all'utente di personalizzare il risultato emesso in output
dal motore di trasformazione tramite un set di parametri XSLT, i cui valori di
default sono deniti nel le di congurazione config.xml.
generate-all-ontologies-param : booleano indicante se è necessario generare un le owl per ogni ontologia dichiarata nel diagramma Graoo
(true) oppure per la sola main ontology (false).
use-hierarchical-visit-param : booleano, specica se l'output Manchester
debba adottare l'ordinamento gerarchico (true) oppure l'ordinamento
usuale per le ontologie OWL 2 espresse in Manchester syntax (false).
use-depth-first-visit-param : booleano, nel caso in cui venga adottato l'ordinamento gerarchico degli statement Manchester, specica se l'albero
delle classi vada visitato secondo la modalità depth-rst (true) oppure
breadth-rst (false).
maintain-appearance-param : booleano indicante se l'ontologia nale debba tenere traccia di informazioni presentazioni del diagramma Graffoo iniziale (true), oppure se tali informazioni possano essere ignorate
(false).
use-imported-ontology-version-iri-param : booleano, nel caso di ontologie importate, specica se lo statement Manchester Import debba utilizzare l'IRI generale dell'ontologia importata (false) oppure l'IRI di
versione se dichiarato (true).
37
CAPITOLO 4.
GRAMOS - VISIONE A BASSO LIVELLO
default-ontology-iri-param : stringa, nel caso in cui nel diagramma Graoo
l'utente abbia denito entità al di fuori di un ontology widget, questo valore viene utilizzato come IRI di un'ontologia auto-generata cui attribuire
tali entità.
default-empty-prefix-param : stringa utilizzata come IRI di un presso vuoto auto-generato nel caso in cui l'utente non lo abbia dichiarato esplicitamente tramite l'apposito prex widget.
4.7 Test e valutazioni
Proponendosi come intermediario tra la fase di progettazione e quella di
reale generazione ontologica, GraMOS si assume la responsabilità di emettere
in output ontologie che rispecchino fedelmente il modello graco in input. Per
vericare la correttezza del processo di traduzione, il progetto GraMOS è stato
testato empiricamente fornendo sia input generati ad-hoc, per valutare separatamente le funzionalità introdotte durante lo sviluppo, sia input complessi,
in modo da simulare possibili trasformazioni reali. A tale scopo la possibilità
di analizzare i risultati delle trasformazioni intermedie risulta estremamente
utile in quanto permette di studiare l'evoluzione progressiva dell'ontologia.
Le ontologie Manchester ottenute dai diagrammi più signicativi sono state
validate sia attraverso il validatore della Manchester University13 , sia importandole all'interno dell'editor ontologico Protégé. I test personali di correttezza
risultano quindi positivi e il tool GraMOS pare non aetto da bug evidenti.
Tuttavia sarà necessario sottoporlo a valutazioni esterne per valutare la sua
eettiva usabilità, intesa come capacità del motore di trasformazione di comportarsi eettivamente come gli utenti si aspettano. Una bassa usabilità in
tal senso vanicherebbe infatti l'utilizzo di GraMOS in quanto l'utente, non
compreso nelle sue esigenze e quindi non soddisfatto del risultato nale, necessiterebbe di mettere mano personalmente agli statement OWL dell'ontologia
generata, cadendo in quel fastidioso processo di generazione ontologica di cui
avrebbe dovuto occuparsi il tool.
4.8 Tecnologie adottate
Per ottimizzare lo sviluppo è stato adottato Oxygen XML Editor 14 , software
proprietario della Syncro Soft rilasciato con licenza a pagamento15 . Oxygen è
infatti uno dei più apprezzati IDE per lo sviluppo di tecnologie XML, fornendo in particolare supporto per l'editing, il debugging e il testing di moduli
13 Manchester
validator/.
University
OWL
Validator:
http://owl.cs.manchester.ac.uk/
14 Oxygen XML Editor homepage: http://www.oxygenxml.com/.
15 È disponibile anche una licenza di prova gratuita della durata di trenta giorni.
38
CAPITOLO 4.
GRAMOS - VISIONE A BASSO LIVELLO
XSLT 2.0. Oxygen è disponibile sia in versione standalone per sistemi operativi Windows, Mac e Linux, sia sotto forma di plugin per Eclipse, sia come
applicazione Java Web Start. In particolare lo sviluppo è avvenuto su Eclipse
Indigo JEE16 esteso con il plugin Oxygen XML Editor and XSLT Debugger
v15.2. Per il testing ci si è adati al processore Saxon Home Edition v9.5,
integrato nell'IDE Oxygen17 .
16 Eclipse 3.7 for Java EE Developers.
17 Saxonica home page: http://www.saxonica.com/.
39
CAPITOLO 4.
GRAMOS - VISIONE A BASSO LIVELLO
40
Capitolo 5
Conclusioni
La produzione ontologica è una pratica fondamentale per la crescita del
Web Semantico, in quanto le ontologie permettono la strutturazione del Web of
data e l'attribuzione di valori semantici ai dati in esso pubblicati. Le notazioni
grache per ontologie quale Graoo semplicano il processo di progettazione
di ontologie e permettono la creazione di modelli ontologici facilmente interpretabili anche da comunità estranee al mondo del Semantic Web. GraMOS
permette di fondere la fase di progettazione ontologica visuale basata su Graffoo con quella di generazione dell'ontologia formale corrispondente al modello
graco, evitando all'utente un fastidioso e costoso cambio sia di prospettiva sia
di strumentazione. Graoo evolve quindi da semplice strumento per descrivere,
progettare, condividere ontologie OWL 2, a vero e proprio tool di generazione
ontologica per via graca.
L'integrazione di GraMOS con la piattaforma Web DiTTO semplica la
fase di trasformazione rispetto all'esecuzione locale1 e alleggerisce l'utente dalle
operazioni di congurazione dell'ambiente di esecuzione ed eventuale aggiornamento dei sorgenti. Per rendere cross-platform l'intero processo di generazione
ontologica, la piattaforma DiTTO potrebbe essere estesa con una canvas yEd
per consentire la creazione di diagrammi Graoo da browser, liberando l'utente
dalla necessità di installare in locale l'editor yEd e la palette Graoo. Tale
operazione è infatti praticabile semplicemente grazie alle API messe a disposizione dallo stesso yEd per l'editing online2 . Parallelamente, per chi preferisce
l'esecuzione in locale, si potrebbe prendere in considerazione il rilascio di una
versione stand-alone di GraMOS dotata di un'apposita interfaccia graca.
L'implementazione di un meccanismo di round-trip da ontologie OWL concrete a diagrammi Graoo introdurrebbe la funzionalità mancante per rendere
il binomio Graoo/GraMOS una sorta di editor ontologico basato su editing
visuale. Tale meccanismo richiede però la risoluzione di problemi non banali,
1 DiTTO dispone di form appositi per l'upload dell'ontologia Graoo e la gestione dei
parametri di trasformazione.
2 I cosidetti
about.html.
yFiles
for
HTML:
http://www.yworks.com/en/products_yfileshtml_
41
prima tra tutte la gestione del posizionamento dei widget Graoo in modo che
il diagramma ottenuto sia visibilmente chiaro e pulito. Una soluzione approssimata potrebbe prevedere il ranamento dell'attuale sistema di mantenimento
delle informazioni presentazionali nella traduzione da graco a testuale e quindi
la capacità di elaborare quelle ontologie OWL testuali che siano state ottenute
da GraMOS.
Inne, l'introduzione del supporto per sintassi alternative semplicherebbe
l'interscambio delle ontologie create, evitando il passaggio tipicamente obbligato attraverso un convertitore sintattico OWL. Tuttavia una simile estensione richiede l'implementazione di un sistema di parsing e traduzione dalla
Manchester syntax verso la sintassi target.
Nella comunità del Semantic Web lo sviluppo di tecnologie che abbattino il livello di complessità delle operazioni di analisi ontologica e Semantic
Publishing è in rapida ascesa. Ci auguriamo che GraMOS possa costituire un
contributo positivo all'interno di questo movimento e fungere da terreno fertile
per l'ideazione di nuove tecnologie per la crescita del Semantic Web.
42
Bibliograa
[BBC10a] B
arzdi
n², J., Barzdin², G., ƒerans, K., Liepin², R., Spro
gis, A.
(2010), OWLGrEd: a UML Style Graphical Notation and Editor for OWL
2, In Proceedings of the 7th International Workshop on OWL: Experience
and Directions (OWLED-2010), San Francisco, California, USA, 21-22
Giugno 2010, CEUR, Vol. 614, 2010, DOI: 10.1007/978-3-642-16101-8_9.
[BBC10b] Berglund, A., Boag, S., Chamberlin, D., Fernández, M., Kay, M.,
Robie, J., Siméon, J. (2010), XML Path Language (XPath) 2.0 (Second
Edition), W3C Recommendation, 14 Dicembre 2010, World Wide Web
Consortium: http://www.w3.org/TR/xpath20/.
[BEL] Brandes, U., Eiglsperger, M., Lerner, J., GraphML Primer,
GraphML Working Group: http://graphml.graphdrawing.org/
primer/graphml-primer.html (ultima visita: marzo 2014).
[BKM12] Bao, J., Kendall, E., McGuinnes, D., Patel-Schneider, P.
(2012), OWL 2 Web Ontology Language Quick Reference Guide
(Second Edition), W3C Recommendation, 11 Dicembre 2012,
World Wide Web Consortium: http://www.w3.org/TR/2012/
REC-owl2-quick-reference-20121211/.
[FCM10] Falconer, S., Callendar, C., Storey, M. (2010), A Visualization Service for the Semantic Web, In Knowledge Engineering and Management
by the Masses, Vol. 6317 (554-564), Springer Berlin Heidelberg, 2010, DOI:
10.1007/978-3-642-16438-5_45.
[GP13] Gangemi, A., Peroni, S. (2013), DiTTO: Diagrams Transformation
inTo OWL, In Blomqvist, E., Groza, T. (Eds.), Proceedings of the ISWC
2013 Posters e Demos Track (ISWC-PD 2013), Sydney, Australia, 23
Ottobre 2013, CEUR Workshop Proceedings 1035, CEUR-WS.org. http:
//ceur-ws.org/Vol-1035/iswc2013_demo_2.pdf.
[GRU95] Gruber, T. (1995), Toward principles for the design of ontologies used for knowledge sharing, In International Journal of HumanComputer Studies, 43: 907928. Academic Press. Novembre 1995, http://
www.sciencedirect.com/science/article/pii/S1071581985710816.
43
[GW12] Golbreich, C., Wallace, E. (2012), OWL 2 Web Ontology Language
New Features and Rationale (Second Edition), W3C Recommendation,
11 Dicembre 2012, World Wide Web Consortium: http://www.w3.org/
TR/owl2-new-features/.
[GWG09] GraphML Working Group (2009), GraphML Specication, GraphML Working Group, 15 Dicembre 2009: http:
//graphml.graphdrawing.org/primer/graphml-primer.html.
[HKP12] Hitzler, P., Krötzsch, M., Parsia, B., Patel-Schneider, P., Rudolph, S.
(2012), OWL 2 Web Ontology Language Primer (Second Edition), W3C
Recommendation, 11 dicembre 2012, World Wide Web Consortium: http:
//www.w3.org/TR/2012/REC-owl2-primer-20121211/.
[HP12] Horridge, M., Patel-Schneider, P. (2012), OWL 2 Web Ontology Language Manchester Syntax (Second Edition), W3C Working Group Note,
11 Dicembre 2012, World Wide Web Consortium: http://www.w3.org/
TR/owl2-manchester-syntax/.
[KAY07] Kay, M. (2007), XSL Transformations (XSLT) Version 2.0, W3C Recommendation, 23 Gennaio 2007, World Wide Web Consortium: http:
//www.w3.org/TR/xslt20/.
[MPP12] Motik, B., Patel-Schneider, P., Parsia, B. (2012), OWL 2
Web Ontology Language Structural Specication and FunctionalStyle Syntax (Second Edition), W3C Recommendation, 11 Dicembre
2012, World Wide Web Consortium: http://www.w3.org/TR/2012/
REC-owl2-syntax-20121211/.
[NL13] Negru, S., Lohmann, S. (2013), A Visual Notation for the Integrated
Representation of OWL Ontologies, In Proceedings of the 9th International Conference on Web Information Systems and Technologies (WEBIST 2013), Aachen, Germania, 08-10 Maggio 2013, SciTePress 2013, pp.
308-315. http://vowl.visualdataweb.org/v1/VOWL2013.pdf.
[NHL13] Negru, S., Haag, F., Lohmann, S. (2013), Towards a Unied Visual Notation for OWL Ontologies: Insights from a Comparative User
Study, In Proceedings of the 9th International Conference on Semantic Systems (I-SEMANTICS 2013), Graz, Austria, 04-06 Settembre 2013,
ACM 2013, pp. 73-80, http://www.vis.uni-stuttgart.de/uploads/
tx_vispublications/VisualNotationOWL.pdf.
[PER12] Peroni, S., Shotton, D., Vitali, F. (2012), The Live OWL Documentation Environment: a tool for the automatic generation of ontology documentation, In ten Teije, A., Völker, J., Handschuh, S., Stuckenschmidt,
H., d'Aquin, M., Nikolov, A., Aussenac-Gilles, N., Hernandez, N. (Eds.),
44
Proceedings of the 18th International Conference on Knowledge Engineering and Knowledge Management (EKAW 2012), Galway City, Irlanda,
08-12 Ottobre 2012, Lecture Notes in Computer Science 7603: 398-412,
DOI: 10.1007/978-3-642-33876-2_35.
[PER13a] Peroni, S. (2013), Graoo, Graphical Framework for OWL Ontologies, Silvio Peroni, 2013: http://www.essepuntato.it/graffoo/
(ultima visita: marzo 2014).
[PER13b] Peroni, S. (2013), Graoo Specication, Silvio Peroni, 28
ottobre 2013: http://www.essepuntato.it/graffoo/specification/
current.html.
[PSV13] Peroni, S., Shotton, D., Vitali, F. (2013), Tools for the automatic generation of ontology documentation: a task-based evaluation,
In International Journal on Semantic Web and Information Systems
(IJSWIS), 9 (1): 21-44. Hershey, Philadelphia, USA: IGI Global. DOI:
10.4018/jswis.2013010102.
[W3C] World Wide Web Consortium, Semantic Web: http://www.w3.org/
standards/semanticweb/ (ultima visita: marzo 2014).
[W3C13] World Wide Web Consortium
Graphical Notation, 15 luglio 2013:
SemWebGraphicalNotation.
45
(2013), Semantic Web
http://www.w3.org/wiki/