generazione di ontologie da rappresentazioni grafiche · più propriamente l'obiettivo nale...

Alma Mater Studiorum

Università di Bologna

SCUOLA DI SCIENZECorso di Laurea in Informatica

GENERAZIONE DI ONTOLOGIE

DA RAPPRESENTAZIONI GRAFICHE

Tesi di Laurea in Tecnologie Web

Relatore:Chiar.mo Prof.FABIO VITALI

Correlatore:Dott.SILVIO PERONI

Presentata da:RICCARDO FALCO

Sessione IIIAnno Accademico 2012/2013

Indice

Indice i

Elenco delle �gure iii

1 Introduzione 1

2 Progettazione gra�ca di ontologie 5

2.1 Notazioni gra�che per ontologie OWL . . . . . . . . . . . . . . . 52.2 Notazioni UML-based . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 ODM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Notazioni dedicate . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 VOWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 Gra�oo . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Riepilogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Il progetto GraMOS 15

3.1 Panoramica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Manchester OWL syntax . . . . . . . . . . . . . . . . . . . . . . 163.3 Comportamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1 Nessuna veri�ca di correttezza . . . . . . . . . . . . . . . 173.3.2 Pre�ssi OWL . . . . . . . . . . . . . . . . . . . . . . . . 173.3.3 Annotazioni rdfs:label e rdfs:comment . . . . . . . . 183.3.4 Riconoscimento degli assiomi OWL . . . . . . . . . . . . 183.3.5 Punning . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.6 Gestione di regole non SWRL . . . . . . . . . . . . . . . 203.3.7 Ordinamento degli statement Manchester . . . . . . . . . 203.3.8 Mantenimento delle informazioni presentazionali . . . . . 22

3.4 Assunzioni sul diagramma in input . . . . . . . . . . . . . . . . 233.5 Un esempio reale . . . . . . . . . . . . . . . . . . . . . . . . . . 24

i

4 GraMOS - Visione a basso livello 29

4.1 XSLT 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Strutturazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Trasformazioni parziali . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.1 Importazione del diagramma Gra�oo . . . . . . . . . . . 314.3.2 Gestione del punning . . . . . . . . . . . . . . . . . . . . 324.3.3 Attuazione degli assiomi Import . . . . . . . . . . . . . . 324.3.4 Analisi delle stringhe Manchester . . . . . . . . . . . . . 334.3.5 Traduzione in Manchester syntax . . . . . . . . . . . . . 33

4.4 Posizionamento delle edge label . . . . . . . . . . . . . . . . . . 334.5 Formato XML intermedio . . . . . . . . . . . . . . . . . . . . . 354.6 Parametri di trasformazione . . . . . . . . . . . . . . . . . . . . 374.7 Test e valutazioni . . . . . . . . . . . . . . . . . . . . . . . . . . 384.8 Tecnologie adottate . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Conclusioni 41

Bibliogra�a 43

ii

Elenco delle �gure

1.1 Semantic Web Layer Cake . . . . . . . . . . . . . . . . . . . . . 2

2.1 La notazione ODM: esempio . . . . . . . . . . . . . . . . . . . . 72.2 La notazione VOWL: esempio . . . . . . . . . . . . . . . . . . . 92.3 Legenda dei widget di Gra�oo . . . . . . . . . . . . . . . . . . . 112.4 La notazione Gra�oo: esempio . . . . . . . . . . . . . . . . . . . 12

3.1 Annotazioni rdfs:label e rdfs:comment . . . . . . . . . . . . 183.2 Riconoscimento degli assiomi OWL . . . . . . . . . . . . . . . . 193.3 Riconoscimento del punning . . . . . . . . . . . . . . . . . . . . 203.4 Ordinamento degli statement Manchester . . . . . . . . . . . . . 223.5 Mantenimento delle informazioni presentazionali . . . . . . . . . 233.6 Diagramma Gra�oo in input . . . . . . . . . . . . . . . . . . . . 243.7 Sorgente GraphML del diagramma Gra�oo . . . . . . . . . . . . 253.8 Ontologia Manchester in output . . . . . . . . . . . . . . . . . . 263.9 Validatore OWL della Manchester university . . . . . . . . . . . 273.10 Validazione dell'ontologia ottenuta . . . . . . . . . . . . . . . . 27

4.1 Posizionamento delle edge label in yEd . . . . . . . . . . . . . . 34

iii

Capitolo 1

Introduzione

L'obiettivo di questa tesi consiste nel fornire una panoramica di alcune no-tazioni gra�che adottabili per la creazione di modelli ontologici e nel proporreun motore di generazione di ontologie concrete a partire da rappresentazioniontologiche visuali. Questa dissertazione a�ronta quindi il problema della pro-duzione ontologica, intesa come processo di progettazione e generazione diontologie, particolari modelli di rappresentazione della realtà.

Le ontologie sono esplicite speci�cazioni di una concettualizzazione [GRU95],dove per concettualizzazione si intende un'astrazione di ciò che si vuole rap-presentare. In altre parole un'ontologia permette di descrivere in modo formalei 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 con-divisione della conoscenza in ambiti quali l'intelligenza arti�ciale, l'ingegneriadella conoscenza e, in particolare, il Web Semantico, la più recente svolta evo-lutiva intrapresa dal Web nonché contesto entro cui si sviluppa questa tesi. Iltermine �semantico� indica qui la possibilità di caratterizzare i dati pubblicatisul Web attribuendo loro un signi�cato che sia machine-readable, in modo cheesse siano in grado di e�ettuare non più solo elaborazioni sintattiche bensì verie propri ragionamenti. Più propriamente l'obiettivo �nale del Semantic Webè la generazione, accanto al classico �Web of documents�1, di un Web of da-

ta, ossia un Web costituito da dati tipati fortemente linkati tra loro (Linkeddata) e interpretabili da sistemi automatici per e�ettuare query �intelligen-ti� e dedurre nuove informazioni a partire da quelle già esistenti [W3C]. Perdato tipato si intende un dato la cui natura sia stata de�nita all'interno diuna sorta di vocabolario condiviso. Tali vocabolari sono appunto le ontologie2

e costituiscono i mattoni con cui costruire le basi di conoscenza sulle qualisi poggerà il Semantic Web. Il linguaggio formale con cui vengono de�nite le

1L'attuale Web, basato su documenti HTML navigabili tramite link ipertestuali.2In realtà i due termini non coincidono esattamente, tendendo ad attribuire alle ontolo-

gie una complessità maggiore rispetto ai vocabolari. Tuttavia nel testo i termini verrannoutilizzati in modo equivalente.

1

CAPITOLO 1. INTRODUZIONE

ontologie in ambito Web è OWL, Ontology Web Language, raccomandazioneW3C [HKP12] e parte sostanziale dello stack di tecnologie alla base del WebSemantico3 (�gura 1.1).

Figura 1.1: Semantic Web Layer Cake. Lo stack rappresenta l'architetturadel Web Semantico e le tecnologie su cui si basa, dal livello sintattico (XMLe 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 basanole proprie ricerche sulle tecnologie alla base del Semantic Web4, il Web ofdata fatica a crescere. Uno dei principali motivi che rende di�coltosa la suadi�usione ritengo sia lo scarso coinvolgimento del grande pubblico del WWW,estremamente eterogeneo e in gran parte composto da utenti tutt'altro cheesperti nelle tecnologie del Web Semantico. Per favorire la loro partecipazione ela successiva pubblicazione di dati semantici (Semantic Publishing) è necessariolo sviluppo di strumenti che sempli�chino:

1. La comprensione delle basi di conoscenza esistenti in modo da permet-terne il referenziamento da parte dei dati pubblicati.

2. Lo sviluppo e la pubblicazione di nuove ontologie.3Semantic Web Layer Cake: http://en.wikipedia.org/wiki/Semantic_Web_Stack.4Per esempio Nasa, Google, Facebook, BBC, . . .

2

http://en.wikipedia.org/wiki/Semantic_Web_Stack


Il primo passo per favorire la pubblicazione sul Web of data è quindi losviluppo di tecnologie che facilitino l'avvicinamento degli utenti alle basi diconoscenza esistenti. A tale �ne sono state proposti sistemi quali Parrot5 eLODE (the Live OWL Documentation Environment)6 [PSV13, PER12], in gra-do di analizzare un'ontologia target e generarne la documentazione necessariaalla sua rapida comprensione, o quantomeno più pratica rispetto all'analisidiretta degli statement OWL.

Il passo successivo nella rincorsa al Semantic Publishing è o�rire agli utentidel 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 processodi produzione ontologica per via gra�ca che si focalizza questa tesi. Il vantag-gio nell'utilizzo di notazioni visuali deriva dal fatto che la capacità intuitiva ecognitiva umana risulta più e�cace nel trattamento di informazioni gra�cherispetto alle equivalenti forme testuali [FCM10]. Inoltre i modelli ontologiciprodotti costituiscono un eccellente mezzo esplicativo dell'ontologia, attraver-so il quale un utente non esperto può captare in modo rapido e intuitivo le sueinformazioni strutturali [W3C13]. È quindi consigliabile a�rontare la fase diprogettazione ontologica adottando una tra le numerose notazioni ontologichegra�che proposte, quali ODM (Ontology De�nition Metamodel)8, VOWL (Vi-sual notation for OWL ontologies)9 e Gra�oo (Graphical Framework for OWLOntologies)10.

Per la successiva fase di generazione l'utente potrebbe adottare uno deinumerosi editor ontologici disponibili, tra i quali Protégé11 spicca per notorie-tà e validità. Tuttavia una simile soluzione richiede l'abbandono del modellogra�co e la riscrittura in forma testuale dell'ontologia corrispondente, intro-ducendo uno sforzo aggiuntivo notevole al processo di produzione ontologica12.Alternativamente l'utente potrebbe a�darsi a un eventuale tool che permet-ta l'immediata traduzione del modello ontologico visuale nella corrispondenteontologia concreta, espressa attraverso una particolare sintassi OWL. È questala soluzione o�erta dal progetto GraMOS, Gra�oo to Manchester OWL

Syntax, proposto da questa tesi appunto come punto di incontro tra le duefasi di progettazione e generazione.

GraMOS è un tool in grado di tradurre le ontologie OWL 2 espresse at-5Parrot homepage: http://ontorule-project.eu/parrot.6LODE homepage: http://www.essepuntato.it/lode.7Il W3C ha de�nito cinque possibili sintassi OWL: OWL/XML, RDF/XML (l'unica

che dev'essere obbligatoriamente supportata da ogni tool per OWL 2), Turtle, Manchestersyntax e una sintassi di tipo funzionale [?].

8ODM speci�cation: http://www.omg.org/spec/ODM/.9VOWL homepage: http://purl.org/vowl/.10Gra�oo homepage: http://www.essepuntato.it/graffoo/.11Protégé homepage: http://protege.stanford.edu/.12Il costo è evidente nel caso in cui l'ontologia debba subire modi�che e l'utente desideri

mantenere allineati modello e ontologia.

3

http://ontorule-project.eu/parrot

http://www.essepuntato.it/lode

http://www.omg.org/spec/ODM/

http://purl.org/vowl/

http://www.essepuntato.it/graffoo/

http://protege.stanford.edu/


traverso la notazione visuale Gra�oo in Manchester OWL syntax, una sintassicompatta e user-friendly per ontologie OWL 2. Per aumentare la leggibilità del-l'ontologia generata, GraMOS permette di stampare gli statement Manchestersecondo un ordinamento gerarchico basato sugli assiomi rdfs:subClassOf.Inoltre GraMOS implementa un meccanismo di auto-riconoscimento degli as-siomi OWL tramite un vocabolario dei sinonimi, in modo da incrementare illivello di usabilità della notazione Gra�oo.

Le ontologie generate da GraMOS sono risultate valide sia per il validatoredella Manchester University13 (vedi sezione 3.5) sia per l'editor di ontologieProtégé. L'applicazione è andata quindi a estendere la piattaforma DiTTO

(Diagrams Transformation inTo OWL)14, un servizio web in grado di generareontologie OWL a partire da diagrammi E/R [GP13].

In futuro GraMOS potrebbe essere migliorato per esempio introducendomeccanismi di traduzione verso di�erenti formati di output e ra�nando l'at-tuale sistema di conservazione delle informazioni presentazionali del diagram-ma iniziale in modo da sempli�care l'introduzione di un processo di round-triptra ontologia formale e ontologia gra�ca.

Nei prossimi capitoli le tematiche qui a�rontate verranno ulteriormenteanalizzate. Inizialmente una panoramica di alcune notazioni gra�che per on-tologie OWL permetterà di meglio comprendere i vantaggi indotti dall'adozionedi una notazione visuale sia durante la fase di progettazione ontologica, siaper un eventuale condivisione del modello ontologico (capitolo 2). Il progettoGraMOS verrà quindi proposto come punto di incontro tra le fasi di proget-tazione e generazione ontologica, analizzandone le funzionalità ad alto livelloe o�rendo un esempio di reale trasformazione, dal diagramma Gra�oo allavalidazione dell'ontologia Manchester ottenuta (capitolo 3). SuccessivamenteGraMOS verrà sezionato per comprenderne la struttura, i principi di funzio-namento a basso livello e i parametri che l'utente può sfruttare per adattare ilprocesso di traduzione alle sue esigenze (capitolo 4). In�ne verrà e�ettuata unapanoramica delle funzionalità di GraMOS migliorabili o mancanti, il cui svilup-po renderebbe la terna Gra�oo/DiTTO/GraMOS maggiormente appetibile perla comunità del Semantic Web.

13Manchester University OWL Validator:http://owl.cs.manchester.ac.uk/validator/.

14DiTTO homepage: http://www.essepuntato.it/ditto.

4

http://owl.cs.manchester.ac.uk/validator/

http://www.essepuntato.it/ditto

Capitolo 2

Progettazione gra�ca di ontologie

La produzione ontologica per il Web, intesa come quell'attività che por-ti alla generazione di vocabolari utilizzabili per strutturare il Web of data,è una fase fondamentale per favorire la crescita del Semantic Web. Data lacomplessità espressa dalle ontologie e la loro centralità nel processo di Seman-tic Publishing, la generazione ontologica necessita di una fase preliminare diprogettazione, durante la quale l'utente sia focalizzato sulla struttura dell'on-tologia in via di sviluppo. Le notazioni gra�che per ontologie OWL diven-tano quindi strumenti fondamentali per l'ideazione e progettazione di ontolo-gie sensate e ben strutturate. Di più, i modelli ontologici ottenuti mediantetali notazioni costituiscono un perfetto mezzo di comunicazione tra utenti, siaesperti sia, sopratutto, estranei al mondo dell'ingegneria ontologica, facilitan-do l'analisi strutturale dell'ontologia e rimanendo (parzialmente) indipendentidal particolare linguaggio OWL utilizzato.

Alcuni concetti espressi nei prossimi paragra� possono risultare nebulosisenza una conoscenza elementare di OWL. È quindi consigliabile un'intro-duzione ai concetti alla sua base tramite [HKP12].

2.1 Notazioni gra�che per ontologie OWL

OWL è diventato un punto di riferimento come linguaggio di rappresen-tazione della conoscenza non solo per il Web ma anche per ambiti quali intel-ligenza arti�ciale e ingegneria dell'intelligenza. Pertanto numerose sono statele proposte di notazioni gra�che per ontologie OWL [W3C13], alcune basatesu linguaggi di modellazione già esistenti quale UML, altre create ex-novo peresprimere ontologie OWL. Tuttavia nessuna di queste notazioni ha prevalsosulle altre, e tuttora non esiste un formato visuale universalmente accettato oconsiderato migliore degli altri nella comunità.

Tipicamente è convinzione di�usa che la caratteristica fondamentale di unabuona notazione gra�ca per OWL sia la compattezza [NHL13, BBC10a], inquanto un modello compatto permette di individuare rapidamente la strut-

5

CAPITOLO 2. PROGETTAZIONE GRAFICA DI ONTOLOGIE

tura ontologica. L'utilizzo di widget colorati e la possibilità di caratterizzarecromaticamente gli elementi del diagramma incrementano ulteriormente l'auto-esplicazione della struttura ontologica. Non è tuttavia da trascurare la com-prensibilità della notazione, sopratutto qualora il modello ontologico debbaessere condiviso tra utenti con di�erenti background. In�ne, la capacità digestione delle numerose funzionalità introdotte da OWL 2 rispetto alla prece-dente versione [GW12], potrebbe fare la di�erenza nella scelta della notazionegra�ca da adottare.

2.2 Notazioni UML-based

UML, Uni�ed Modeling Language, è un linguaggio di modellazione gestitodall'OMG, Object Management Group1, divenuto standard sia ISO sia de-factoper la modellazione di sistemi informatici ma anche di domini concettuali.Risulta quindi ovvio che parte della comunità di esperti in ontologie abbiaproposto di�erenti notazioni visuali ontologiche derivanti da questo linguaggiodi modellazione standard e general-purpose. Grazie infatti alla notorietà diUML, i diagrammi ontologici creati risultano facilmente comprensibili anchedai non esperti senza un'approfondita introduzione della notazione utilizzata.Non essendo state generate ex-novo, le notazioni UML potrebbero tuttaviarisultare talvolta eccessivamente verbose, in quanto basate sugli elementi gra�cidi UML.

2.2.1 ODM

L'ODM, Ontology De�nition Metamodel2, è una delle più di�use notazionigra�che UML-based per ontologie OWL. ODM è infatti un pro�lo UML stan-dard sviluppato dall'Object Management Group (creatore di UML) e pertantolargamente considerato come termine di paragone per altre notazioni gra�cheper ontologie OWL.

Dall'immagine 2.1 si osserva che ODM mette a disposizione due soli tipi dielementi gra�ci:

I Box rettangolari (elementi UML::Class), per esprimere classi, datarange,proprietà e istanze. La sezione di box dedicata in UML per le pro-prietà del nodo permette di attribuire in modo chiaro informazioni ag-giuntive, quali le caratteristiche di una object property (nell'esempio+owl:FunctionalProperty).

I Archi, per esprimere asserzioni, caratterizzati dagli stessi tipi di lineae di testa presenti in UML. Per esempio gli assiomi rdfs:domain e

1OMG homepage: http://www.omg.org/.2Speci�che ODM: http://www.omg.org/spec/ODM/1.0/.

6

http://www.omg.org/

http://www.omg.org/spec/ODM/1.0/


rdfs:range vengono rappresentati da associazioni, rdfs:subClassOf erdfs:subPropertyOf sotto forma di generalizzazioni, rdf:types comerealizzazioni, owl:inverseOf tramite dipendenze.

Figura 2.1: Sezione dell'ontologia MUTO (Modular Uni�ed TaggingOntology)3 rappresentata tramite ODM4.

ODM ricicla quindi fedelmente gli elementi UML, caratterizzandoli tramitela de�nizione di appositi stereotipi (per esempio �owl:Class�) senza intro-durre nuove caratteristiche ad-hoc. L'utilizzo intensivo di etichette stereotipatefavorisce notevolmente l'interpretazione del modello ontologico anche da partedi utenti non esperti. Inoltre, il fatto di non avere introdotto nuovi elemen-ti gra�ci consente all'utente l'utilizzo di un qualunque editor per diagrammiUML. Tuttavia la struttura del modello non risulta immediatamente cattura-

4MUTO homepage: http://muto.socialtagging.org/core/v1.html.4Diagramma tratto da [NHL13].

7

http://muto.socialtagging.org/core/v1.html


bile a causa sia dell'utilizzo della stessa notazione gra�ca per di�erenti tipi dientità, sia dell'assenza di colorazioni esplicative.

In de�nitiva, ODM risulta un linguaggio di modellazione ontologica pococompatto, nel quale entità di tipo di�erente vengono rappresentate con stes-si elementi gra�ci, ma estremamente esplicativo. ODM non risulta quindiparticolarmente adatto come mezzo di progettazione ontologica, prestandosibene tuttavia per la condivisione di modelli ontologici all'interno di comunitàeterogenee.

2.3 Notazioni dedicate

OWL de�nisce alcune funzionalità che un linguaggio di modellazione UML-based non può rappresentare in modo chiaro e semplice. Tipico esempio sonole classi anonime, ossia classi ottenute per composizione insiemistica di altreclassi, restrizione di proprietà o enumerazione di individui ([HKP12] sezione�Advanced Class Relationships�). Pertanto sono state proposte di�erenti no-tazioni gra�che ad-hoc, dotate di costrutti appositi che rendano puliti e com-patti i diagrammi ontologici. In questo modo i modelli ottenuti risultano menoverbosi, ma richiedono che gli utenti vengano introdotti alla notazione visualeutilizzata.

2.3.1 VOWL

VOWL, Visual Notation for OWL Ontologies5, è una notazione gra�ca perontologie OWL molto compatta e sintetica [NL13, NHL13]. Essa prevede laprogettazione e l'analisi dell'ontologia su tre di�erenti layer:

1. Conceptual layer: riguarda classi, proprietà e relazioni tra di essi;

2. Instance layer: la visualizzazione avviene a livello delle istanze e dellerelazioni tra di esse;

3. Integrated layer: integra il layer concettuale con quello delle istanze.

La notazione VOWL è basata su quattro tipi di elementi gra�ci:

I Cerchi, rappresentanti le classi dell'ontologia;

I Settori circolari all'interno delle classi, indicanti gli individui apparte-nenti a quella classe. Gli individui vengono quindi automaticamente rag-gruppati assieme alla classe di appartenenza, rendendone immediata l'in-dividuazione da parte dell'osservatore.

5VOWL homepage: http://purl.org/vowl/.

8



I Rettangoli, rappresentanti datatype, letterali e valori;

I Archi tra gli elementi precedenti e diversi�cati per tipo di linea e di te-sta, indicanti proprietà e asserzioni. Per esempio le relazioni gerarchiche(rdfs:subClassOf e rdfs:subPropertyOf) vengono chiaramente distin-te 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 ofa Friend)6 rappresentata tramite la notazione VOWL7.

Questa di�erenziazione velocizza l'individuazione della struttura ontologicada parte dell'osservatore. A tale scopo aiutano ulteriormente caratteristichequali le di�erenti colorazioni degli elementi del diagramma, la dimensione delleclassi proporzionale al grado di connettività con altre entità, l'utilizzo di unelemento gra�co apposito per rappresentare in modo compatto l'equivalenzatra classi.

Tuttavia, proprio la ricerca di compattezza e sinteticità rende i diagrammiVOWL talvolta di�cili da comprendere, richiedendo un'apposita introduzionedella notazione utilizzata. Per esempio la notazione adottata per denotare le

7FOAF homepage: http://www.foaf-project.org/.7Diagramma tratto da http://purl.org/vowl/.

9

http://www.foaf-project.org/



caratteristiche di una object property (per esempio F per Functional) oppuregli operatori insiemistici t (unione), u (intersezione) e ¬ (complementare) perla composizione di classi, non risultano immediatamente comprensibili senzauna precedente spiegazione. Ancora, l'utilizzo di un solo arco sia per la pro-prietà diretta sia per quella inversa richiede l'utilizzo di due etichette di�erenti,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 VOWLnon permetta la gestione di tutte le funzionalità di OWL 2, per esempio lacreazione di classi anonime ottenute per restrizione di proprietà8.

VOWL è una sintassi gra�ca molto compatta e quindi particolarmente adat-ta per la fase di progettazione ontologica, nella quale si presume che il proget-tista conosca al dettaglio la notazione utilizzata. Tuttavia l'adozione di questanotazione potrebbe limitare l'utente nell'utilizzo delle funzionalità di OWL 2.VOWL risulta invece una scelta rischiosa qualora i modelli ontologici debbanoessere condivisi all'interno di comunità eterogenee, in quanto l'estrema sin-teticità comporterebbe una certa di�coltà di interpretazione del diagrammada parte di quegli utenti estrenei alla notazione utilizzata.

2.3.2 Gra�oo

Gra�oo, Graphical Framework for OWL Ontologies9, è un framework perla rappresentazione visuale di ontologie OWL 2 [PER13a]. Gra�oo è infatti siauna notazione gra�ca ontologica, sia una palette di widget gra�ci integrabileall'interno dell'editor di diagrammi yEd10 per la creazione di modelli ontologicibasati su tale notazione.

Gra�oo non è una notazione immediatamente adottabile e interpretabileda utenti privi di un minimo background di OWL in quanto gli elementi gra�-ci sono basati sull'utilizzo della sintassi Manchester, una delle cinque possibilisintassi per OWL 2 (vedi sezione 3.2). Tuttavia tale sintassi risulta decisamenteuser-friendly, rendendo il modello ontologico particolarmente esplicativo e suf-�cientemente interpretabile da utenti con un minimo background di OWL.Inoltre questa scelta, insieme alla de�nizione di widget sia specializzati siageneral-purpose, permette di sempli�care la gestione delle funzionalità avan-zate di OWL 2, non richiedendo l'introduzione di una sintassi apposita e dimeccanismi di interazione complessi tra gli elementi gra�ci.

Dall'immagine 2.3 si osserva che i widget gra�ci messi a disposizione daGra�oo sono i seguenti:

8Non è stata trovata alcuna prova che confermi o smentisca questa osservazione.9Gra�oo homepage: http://www.essepuntato.it/graffoo/.10yEd homepage: http://www.yworks.com/.

10


http://www.yworks.com/


Figura 2.3: Legenda di tutti i widget gra�ci messi a disposizione dallanotazione Gra�oo.

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 diclassi sia di datatype, utilizzando come etichetta la stringa Manchesterdella de�nizione.

I Proprietà: archi tra i nodi, de�niscono object property, data property eannotation property. Inoltre Gra�oo mette a disposizione delle propertyfacility, elementi gra�ci utili per noti�care la possibilità di utilizzo diuna particolare property entro un certo dominio e codominio senza peròforzarne la concreta de�nizione nell'ontologia corrente.

I Assiomi: archi tra i nodi per la speci�ca di asserzioni.

I Additional axiom: box per la de�nizione di asserzioni aggiuntive, espressein sintassi Manchester. Questo tipo di widget risulta estremamente ver-satile in quanto può essere associato sia a nodi entità tramite appositilink, sia a property per vicinanza, in modo da attribuire loro informazioni

11


aggiuntive (per esempio caratteristiche di object property, annotazioni,relazioni tra property, ecc.).

I External rule: box per la speci�ca di regole o vincoli di integrità dell'on-tologia non rappresentabili come semplici interazioni tra widget. In par-ticolare questo elemento gra�co consente la de�nizione di regole SWRL,Semantic Web Rule Language, member submission del W3C11.

I Pre�x box: box per la de�nizione dei pre�ssi utilizzati dalle proprietà eassiomi presenti nel modello ontologico.

Figura 2.4: Sezione dell'ontologia CO (Collection Ontology)12 rappresen-tata tramite la notazione Gra�oo.

Da quanto detto, si deduce che Gra�oo permetta la rappresentazione anchedi funzionalità complesse di OWL 2. L'utilizzo di widget quali le restrizioni diclassi e di datarange rende la notazione compatta e al tempo stesso poco caoti-ca e decisamente esplicativa. In particolare la �essibilità degli additional axiom,pur abbassando in parte l'intuitività visiva del modello ontologico, permette

11SWRL: http://www.w3.org/Submission/SWRL/.12The Collection Ontology: http://purl.org/co.

12

http://www.w3.org/Submission/SWRL/

http://purl.org/co


l'immediata gestione di quelle informazioni aggiuntive che altrimenti avrebberorichiesto la de�nizione di appositi widget mirati. La possibilità di etichettareun'unico arco con più valori, aggregati e non, aumenta ulteriormente la compat-tezza della notazione. In�ne, oltre alle colorazioni prede�nite, yEd permette dipersonalizzare cromaticamente gli elementi del modello ontologico, per esempioper evidenziare un'entità particolarmente rilevante all'interno dell'ontologia.

Gra�oo risulta quindi un linguaggio di modellazione ontologica estrema-mente e�cace, sopratutto se messo a disposizione di esperti in ontologie OWL.Durante la fase di progettazione ontologica, il progettista può infatti esprimereogni funzionalità di OWL 2 in modo tutto sommato compatto e intuitivo. In�nesi osservi come gli eventuali limiti di comprensibilità dei modelli Gra�oo daparte di utenti estranei all'Ontology Web Language siano legati in parte all'u-tilizzo della Manchester syntax ma sopratutto alla complessità intrinseca dellefunzionalità avanzate di OWL.

2.4 Riepilogo

Le notazioni gra�che per ontologie OWL costituiscono un mezzo ideale siaper la condivisione di modelli ontologici, sia per la progettazione di nuove on-tologie. In entrambi i casi il linguaggio di modellazione ideale deve risultarecompatto, esplicativo e interpretabile anche da utenti senza una conoscenzaapprofondita di ontologie. Tra le notazioni analizzate, ODM risulta assoluta-mente esplicativo e interpretabile ma a�atto compatto. Inoltre si presta malealla rappresentazione di funzionalità proprie di OWL, essendo basato esclusi-vamente sugli elementi gra�ci di UML. VOWL al contrario appare estrema-mente compatto ma non del tutto chiaro senza un'introduzione alla notazionee apparentemente non in grado di gestire tutte le funzionalità di OWL 2.Gra�oo in�ne risulta particolarmente adatto alla creazione di modelli onto-logici con un certo grado di complessità, rimanendo su�cientemente compattoe interpretabile.

Una volta ottenuto il modello di progettazione dell'ontologia, l'utente tipi-camente deve a�darsi a un editor ontologico quale Protégé, a meno di metteremano direttamente agli statement OWL del sorgente ontologico. Alternativa-mente, un tool in grado di tradurre in modo automatico il modello ontologiconell'equivalente ontologia OWL sempli�cherebbe notevolmente il processo digenerazione ontologica. GraMOS, progetto sviluppato per questa tesi e descrit-to nei prossimi capitoli, si propone di assolvere questo compito consentendo diottenere ontologie concrete a partire da modelli Gra�oo.

13


14

Capitolo 3

Il progetto GraMOS

La crescita del Web Semantico è frenata dalla carenza di strumenti che ac-compagnino gli utenti non esperti delle tecnologie alla sua base nelle operazionidi Semantic Publishing, ossia nella pubblicazione di informazioni sul Web of da-ta. Tra i dati pubblicabili le ontologie sono sicuramente le entità che richiedonoil maggiore sforzo, in quanto esse de�niscono formalmente i vocabolari cui glialtri dati faranno riferimento e devono perciò essere progettate con criterio.Le notazioni visuali per ontologie OWL, oltre a favorire la comprensione delleontologie esistenti, ne facilitano la progettazione di nuove anche da parte diutenti non esperti in una particolare sintassi OWL. Tuttavia, per la successivafase di generazione dell'ontologia concreta, gli utenti sono obbligati a metteremano a un qualunque editor testuale oppure ad a�darsi a un apposito editordi ontologie quale Protégé, separando quindi la fase di progettazione da quelladi creazione. Il progetto GraMOS permette di evitare questa separazione.

Questo capitolo a�ronta l'analisi ad alto livello di GraMOS, fornendo nu-merosi esempi gra�ci abbinati alle corrispondenti traduzioni Manchester ot-tenibili dal motore di trasformazione in modo da facilitare la comprensione deiconcetti espressi. A�nché tali esempi risultino interpretabili è tuttavia neces-sario avere prima compreso le funzionalità dei singoli widget Gra�oo [PER13b].Al contrario la Manchester syntax risulta su�cientemente chiara anche senzaun'apposita introduzione, a patto di possedere delle basi di OWL.

3.1 Panoramica

GraMOS è un motore in grado di trasformare ontologie OWL 2 visuali inequivalenti ontologie formali, realmente iniettabili nel Web of data o importa-bili in un qualunque editor di ontologie OWL. In particolare GraMOS elaboramodelli ontologici creati tramite Gra�oo ed emessi dall'editor yEd in formatoGraphML, una notazione XML per esprimere gra� [BEL]. L'ontologia generataè espressa in Manchester syntax, una sintassi OWL particolarmente compattae 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 inun'altra sintassi OWL quale RDF/XML da un OWL Syntax Converter per lapubblicazione 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 gen-erazione di ontologie OWL concrete a partire da diagrammi di varia natura[GP13]. In questo modo è possibile usufruire dei vantaggi di una soluzioneWeb-based quali la possibilità di utilizzo da parte di chiunque sia provvistodi un browser con accesso al Web, la libertà per l'utilizzatore dal con�gu-rare l'ambiente locale per l'esecuzione, la gestione sempli�cata del processo diaggiornamento del software.

3.2 Manchester OWL syntax

Il W3C ha defnito cinque possibili sintassi concrete per l'Ontology WebLanguage: OWL/XML, RDF/XML, Turtle, Manchester syntax e una sintassidi tipo funzionale ([HKP12], sezione �OWL Syntaxes�). Le sintassi XML-basedrisultano sicuramente le più adatte in un contesto orientato alle macchine, inquanto facilmente elaborabili per manipolazione del DOM (Document ObjectModel) e maggiormente supportate dai tool per ontologie2. Tuttavia nel con-testo della generazione ontologica dovrebbe essere la human-readability il fat-tore determinante nella scelta della sintassi da adottare, dato che esistonostrumenti appositi per e�ettuare la successiva conversione in una qualunquedelle altre sintassi. Pertanto, per esprimere l'ontologia elaborata da GraMOS èstata adottata la Manchester OWL syntax, particolarmente compatta e vicinaal linguaggio naturale [HP12].

Prefix: : <http://MyOntology/>

Prefix: another: <http://AnotherOntology/>

Prefix: rdfs: <http://www.w3.org/2000/01/rdf-schema#>

Prefix: 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

1DiTTO homepage: http://www.essepuntato.it/ditto.2La sintassi basata su RDF/XML è l'unica che dev'essere obbligatoriamente supportata

da ogni tool per OWL 2.

16

http://www.essepuntato.it/ditto


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 in�uente nella scelta della sintassi è stato il fattoche alcuni widget Gra�oo 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 conversionesintattica del contenuto di tali widget.

3.3 Comportamento

3.3.1 Nessuna veri�ca di correttezza

GraMOS non e�ettua nessun controllo di correttezza sintattica (per esem-pio la plausibilità dell'IRI di un pre�sso o la correttezza di una restrizione) nétantomeno semantica (per esempio l'utilizzo corretto del punning, vedi sezione3.3.5). Questo è legato sia a fattori di sforzo complessivo di sviluppo, sia allascelta di lasciare agli utenti piena libertà di sperimentazione.

3.3.2 Pre�ssi OWL

OWL de�nisce quattro pre�ssi standard, non ride�nibili dall'utente: rdf,rdfs3, owl, xsd4. Gli IRI basati su di essi de�niscono infatti il vocabolarioprivato di OWL ([MPP12], sezione �IRIs�). Dato l'utilizzo frequente di questi

3RDFS: RDF-Schema.4XSD: XML-Schema Datatype.

17


pre�ssi all'interno di una qualunque ontologia, GraMOS permette all'utentedi non dichiararli in modo esplicito, ma, nel caso in cui siano e�ettivamenteutilizzati, 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 riferi-mento a speci�che entità non tramite l'IRI o il CURIE bensì attraverso semplicietichette facilmente interpretabili. Analogamente può ulteriormente migliorarela human-readability di un'entità l'applicazione di un commento che la descri-va. Questi due tipi di informazioni sono esprimibili in OWL tramite annotazionirdfs:label e rdfs:comment.

Dato che l'editor yEd o�re all'utente la possibilità di caratterizzare ogniwidget con una descrizione testuale, visibile come popup facendo hovering delwidget col mouse, si è scelto di sfruttare tale informazione come sorgente per lagenerazione automatica di etichette e commenti. In particolare per GraMOS:

I Il valore della proprietà rdfs:label è dato dalla prima riga non vuotadella 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 og-ni elemento gra�co. Facendo hovering di un widget appare un popupindicante l'eventuale descrizione a esso attribuita dall'utente. Tale de-scrizione viene tradotta da GraMOS come annotazioni rdfs:label erdfs:comment.

3.3.4 Riconoscimento degli assiomi OWL

Spesso, durante la fase di sviluppo di un'ontologia, è facile confondere ipre�ssi da utilizzare per referenziare un particolare assioma OWL, oppure non

18


ci si ricorda la forma esatta dell'assioma5. Per tale motivo si è ritenuto cheun meccanismo di autoriconoscimento degli assiomi OWL incrementasse par-ticolarmente il livello di usabilità dell'applicazione. GraMOS fornisce quindisupporto allo sviluppatore di ontologie OWL riconoscendo le più comuni vari-anti degli assiomi OWL, de�nite all'interno di un vocabolario dei sinonimiliberamente 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 gra�ca, GraMOS è in gra-do di riconoscere le principali varianti degli assiomi OWL. In questo ca-so gli archi sub_class_of e different vengono riconosciti rispettiva-mente come assiomi rdfs:subClassOf e owl:differentFrom e tradottidi conseguenza nella corrispondente forma Manchester.

3.3.5 Punning

Nella sua seconda versione, OWL introduce meccanismi sia per abbassarela verbosità di alcune operazioni6, sia per aumentare l'espressività del lin-guaggio [GW12]. Una caratteristica interessante è sicuramente il punning7, unmeccanismo che permette di fare metamodeling sulle entità dell'ontologia, in-crementando la potenza espressiva del linguaggio. In OWL 2 è infatti possibileutilizzare lo stesso IRI per referenziare oggetti di tipo di�erente, per esempio ilnome �Eagle� per indicare sia una classe, la classe di tutte le aquile, sia un in-dividuo, rappresentante la specie Eagle appartenente alla (meta)classe di tuttele specie animali.

Tuttavia il linguaggio pone anche di limiti ai gradi di �polimor�smo� uti-lizzabili, in particolare uno stesso IRI non può indicare contemporaneamente

I una classe e un datatype,

I property di tipo di�erente.5rdf:subClassOf oppure rdfs:subClassOf? rdfs:subClass oppure rdfs:subClassOf?6Zuccheri sintattici, per esempio l'unione di classi disgiunte.7Punning, letteralmente �gioco di parole�.

19


GraMOS supporta l'utilizzo del punning all'interno dei diagrammi Gra�oo,non e�ettuando tuttavia alcuna veri�ca 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 tipodinamico di un nodo del diagramma coinvolto in un'asserzione dipendeinfatti dal valore dell'assioma. In questo caso types identi�ca l'assiomardf:type, il quale richiede un soggetto di tipo individuo e un oggetto ditipo classe. L'entità Eagle corrisponde quindi sia a una classe, sia a unindividuo.

3.3.6 Gestione di regole non SWRL

Tramite l'introduzione di un widget apposito, Gra�oo consente la speci-�ca di regole SWRL, Semantic Web Rule Language8. Tali regole possonoessere tradotte in modo immediato in Manchester syntax grazie all'apposi-ta clausola Rule. Tuttavia l'utente può non avere familiarità con SWRL epreferire adottare una qualunque altra notazione con stesse capacità espres-sive, per esempio una query CONSTRUCT in SPARQL9. Dato che tali vincolipotrebbero non risultare direttamente rappresentabili in sintassi Manchester,GraMOS assume un'atteggiamento cauto, introducendo un'apposita annota-tion property graffoo:has<Lang>Rule10 (dove <Lang> rappresenta il nomedel linguaggio per regole utilizzato) priva di dominio e codominio attraversola quale le regole possono essere espresse come semplici annotazioni associateall'ontologia.

3.3.7 Ordinamento degli statement Manchester

GraMOS si conforma all'usuale ordinamento delle ontologie OWL 2 espressein sintassi Manchester, producendo un output strutturato secondo lo schemaseguente:

1. Dichiarazione dei pre�ssi;8SWRL speci�cation: http://www.w3.org/Submission/SWRL/.9SPARQL speci�cation: http://www.w3.org/TR/rdf-sparql-query/.10Il CURIE è in realtà un IRI in quanto il pre�sso graffoo è espanso con l'URI priva-

to http://www.essepuntato.it/graffoo/autoGeneratedEntities/ in modo da evitarecon�itti con un eventuale pre�sso omonimo.

20

http://www.w3.org/Submission/SWRL/

http://www.w3.org/TR/rdf-sparql-query/


2. Dichiarazione dell'ontologia corrente, eventuali statement Import e an-notazioni riferite all'ontologia corrente;

3. Dichiarazione nell'ordine di classi, datarange, object/data/annotationproperty e individui (le entità sullo stesso livello vengono ordinate al-fabeticamente);

4. Eventuali statement Rule per la speci�ca di regole SWRL.

Nonostante la human-readability dell'ontologia risultante dalla trasforma-zione non sia funzionale al suo successivo utilizzo, si è scelto di sempli�careulteriormente l'interazione dell'utente con gli statement Manchester fornendoanche un'ordinamento alternativo di tipo gerarchico. In particolare le classidell'ontologia vengono dichiarate seguendo una visita top-down delle gerar-chie de�nite dagli assiomi rdfs:subClassOf, a partire dalla classe universaleowl:Thing11. La dichiarazione di ogni classe viene seguita dalle dichiarazionidelle property che hanno per dominio tale classe e dai suoi individui, facilitan-do 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 diagrammaGra�oo rappresentato secondo le due di�erenti politiche di ordinamento delleentità.

11La classe owl:Thing è la superclasse universale dalla quale tutte le classi derivano.Per completezza dell'ontologia �nale, essa viene dichiarata automaticamente dal tool ditrasformazione.

21


# Basic Sorting

Class: Animal

SubClassOf: LivingBeing

Class: Cat

SubClassOf: Animal

Class: Human

SubClassOf: Animal

Class: LivingBeing

Class: Mineral

Class: owl:Thing

Class: Vegetable



Domain: LivingBeing

Range: LivingBeing

Individual: John

Types: Human

Individual: Poochie

Types: Cat

# Hierarchic Sorting

Class: owl:Thing

Class: LivingBeing


Domain: LivingBeing

Range: LivingBeing

Class: Animal


Class: Cat

SubClassOf: Animal

Individual: Poochie

Types: Cat

Class: Human

SubClassOf: Animal

Individual: John

Types: Human

Class: Vegetable


Class: Mineral

Figura 3.4: Oltre all'ordinamento tipico delle ontologie espresse inManchester syntax (colonna sinistra), GraMOS supporta anche un ordina-mento di tipo gerarchico basato sugli assiomi rdfs:subClassOf (colonnadestra).

3.3.8 Mantenimento delle informazioni presentazionali

Una funzionalità interessante nell'ambito Gra�oo/GraMOS è la possibili-tà di e�ettuare il round-trip delle ontologie concrete, ottenute da diagrammiGra�oo tramite GraMOS, nuovamente verso la notazione Gra�oo. Per faci-litare un futuro sviluppo di questa estensione, è stato introdotto un sistemasempli�cato e opzionale di mantenimento delle informazioni presentazionali dialcuni widget. Date alcune complicazioni, in primis il complesso sistema uti-lizzato da yEd per il posizionamento degli archi (vedi sezione 4.4), il problemaè stato appena scal�to, memorizzando informazioni basilari quali il posizio-namento assoluto, la dimensione del box e la colorazione adottata per i soliwidget di tipo class, datarange e individual. In particolare, tali informazionivengono memorizzate sottoforma di annotazioni graffoo:hasAppearance12,introdotte appositamente nell'ontologia.

12Il CURIE è espanso, analogamente alle annotation property graffoo:has<Lang>Rule.

22


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 diround-trip tra Gra�oo e OWL, GraMOS memorizza alcune informazionipresentazionali dei nodi di tipo classe, datatype e individuo sotto formadi apposite annotazioni.

3.4 Assunzioni sul diagramma in input

GraMOS non e�ettua nessun controllo di correttezza sul diagramma Graf-foo ricevuto in input, assumendone la validità e cercando di restituire sempreun risultato, eventualmente insensato. Di conseguenza l'utente non è in gradodi stabilire la validità dell'ontologia generata se non interrogando successiva-mente un validatore Manchester. Di seguito sono pertanto elencate le assun-zioni e�ettuate dal motore di trasformazione sul diagramma in input, in mododa fornire all'utente delle linee guida per la creazione di ontologie Gra�oo chepermettano di ottenere tramite GraMOS ontologie �nali valide.

I Il diagramma deve de�nire una sola main ontology, intesa come quell'on-tologia che non viene importata da nessun'altra ontologia.

I L'ontologia deve de�nire tutti i pre�ssi utilizzati, anche i pre�ssi delleentità appartenenti a ontologie importate. È possibile invece non de�nirei pre�ssi standard di OWL (sezione 3.3.2).

I Le restrizioni (sia di classi sia di datarange) non possono essere soggettidi asserzioni.

I I widget non possono essere ruotati in quanto questo minerebbe il mec-canismo di attribuzione degli additional axiom alle property (sezione4.4).

I L'utente può liberamente adattare la colorazione dei widget utilizzati allesue preferenze o esigenze, in quanto il loro riconoscimento è basato sullecaratteristiche strutturali quali la forma del nodo, il tipo di bordo, lalinea e gli end-point dell'arco, ecc.

23


3.5 Un esempio reale

Prima di analizzare GraMOS da un punto di vista a basso livello, vienedi seguito proposto un esempio di reale trasformazione, in modo da fornireall'utente una prova tangente dell'e�cacia di GraMOS. L'input della trasfor-mazione è costituito da una sezione di CO, the Collection Ontology13, nellaquale si è fatto uso di un discreto numero di widget gra�oo. Dal diagrammaGra�oo rappresentante tale sezione di ontologia (immagine 3.6), in particolaredal �le GraphML che codi�ca il diagramma (immagine 3.7), GraMOS general'ontologia OWL 2 equivalente espressa in Manchester syntax (immagine 3.8).Tuttavia l'ontologia ottenuta deve risultare valida a�nché sia e�ettivamenteutile e quindi iniettabile nel Web of data o importabile in un editor ontologicoquale Protégé. L'utilizzo del validatore OWL 2 della Manchester University14

(immagine 3.9) assolve questo scopo, dimostrando la validità dell'ontologiagenerata (immagine 3.10).

Figura 3.6: Sezione dell'ontologia CO (the Collection Ontology) espressatramite la notazione Gra�oo.

13The Collection Ontology: http://purl.org/co.14Validatore Manchester: http://owl.cs.manchester.ac.uk/validator/.

24

http://purl.org/co



Figura 3.7: Sorgente del diagramma Gra�oo. I diagrammi generati dal-l'editor yEd sono codi�cati in formato GraphML, una notazione XML perdescrivere gra�. In particolare i nodi appartenenti al formato GraphMLsono quelli con il namespace di default, gli altri sono elementi strutturaliintrodotti da yEd.

25


Figura 3.8: Ontologia Manchester emessa in output da GraMOS in seguitoall'elaborazione del diagramma Gra�oo.

26


Figura 3.9: Il validatore OWL della Manchester University permette lavalidazione di ontologie OWL 2 espresse in una qualunque delle cinquesintassi concrete OWL.

Figura 3.10: L'ontologia ottenuta risulta valida per il validatore dellaManchester University.

27


28

Capitolo 4

GraMOS - Visione a basso livello

Nel processo di generazione ontologica, GraMOS permette la traduzioneautomatica di modelli gra�ci creati tramite Gra�oo in corrispondenti ontologieconcrete espresse in sintassi Manchester, sposando progettazione e creazioneontologica in un'unica fase. Il capitolo precedente ha permesso di analizzare ilcomportamento ad alto livello di GraMOS e di comprendere i requisiti che devesoddisfare un diagramma Gra�oo per portare alla generazione un'ontologiavalida (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 tooldi traduzione.

4.1 XSLT 2.0

GraMOS è un motore di trasformazione basato esclusivamente sulla tec-nologia XSLT, Extensible Stylesheet Language Transformation. L'adozione si-stematica di XSLT è dovuta al fatto che le precedenti funzionalità di DiTTOfossero già implementate da motori XSLT [GP13], rendendo quindi possibilel'immediata integrazione di GraMOS senza modi�che sostanziali del servizioWeb. Inoltre XSL risulta particolarmente pratico per e�ettuare operazioni diaccesso e generazione di alberi XML, grazie all'utilizzo naturale delle espres-sioni XPath. In particolare la sua seconda versione, XSLT 2.0, basata su XPath2.0, introduce numerose funzionalità che sempli�cano notevolmente la vita del-lo sviluppatore [BBC10b, KAY07]. Tuttavia lo stile funzionale che lo caratteriz-za, in particolare l'immutabilità delle variabili XSLT e l'utilizzo della ricorsionecome unica forma di iterazione indeterminata, ha reso di�coltosa la proget-tazione e lo sviluppo delle fasi di trasformazione che richiedessero la frequentemodi�ca 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 dicon�gurazione e un DTD per la de�nizione delle entità XML:

main.xsl : foglio di stile principale, de�nisce l'entry point della trasformazionerichiamando i template de�niti in translation.xsl e si occupa dell'out-put del risultato �nale ed eventualmente, per favorire il debugging, deirisultati parziali1.

translation.xsl : implementa l'e�ettiva trasformazione, de�nendo le variabiliglobali risultanti dall'importazione iniziale del diagramma GraphML e itemplate nominali richiamati da main.xsl per e�ettuare le successivetrasformazioni intermedie.

utils.xsl : de�nisce metodi di utilità generale utilizzati durante l'intera ela-borazione.

config.xsl : si interfaccia con il �le di con�gurazione config.xml de�nendovariabili globali per l'accesso ai valori di con�gurazione da parte deglialtri moduli XSLT. Inoltre de�nisce i parametri accettati dal motore ditrasformazione.

config.xml : �le XML di con�gurazione, de�nisce alcuni valori che in�uisconosulla trasformazione, quali i valori di default dei parametri XSLT. Inoltrede�nisce un vocabolario di sinonimi per il riconoscimento automaticodegli assiomi OWL, la loro traduzione in Manchester syntax e i tipi diwidget accettabili per il soggetto e l'oggetto dell'assioma (per e�ettuareoperazioni di punning).

entities.dtd : de�nisce le entità XML rappresentanti i valori costanti utiliz-zati durante la trasformazione.

4.3 Trasformazioni parziali

Per abbassare la complessità delle operazioni di traduzione dell'ontologiadal formato Gra�oo alla Manchester syntax, GraMOS sfrutta una serie ditrasformazioni parziali successive, ognuna delle quali riceve in input il risultatodella precedente elaborazione. In questo modo ogni fase risolve un ben precisoset di problemi, facilitando sia lo sviluppo sia il debugging. In particolare,ogni trasformazione parziale genera un RTF, Result Tree Fragment, un alberoXML che descrive le elaborazioni e�ettuate sull'intera ontologia iniziale �no a

1La versione 2.0 di XSLT permette output multipli.

30


quel momento2. Seppure questi RTF derivino da elaborazioni di�erenti, i datirappresentati al loro interno condividono il medesimo formato (sezione 4.5).

Si possono identi�care cinque trasformazioni parziali, ognuna della qualigenera un corrispondente RTF.

4.3.1 Importazione del diagramma Gra�oo

L'ontologia graphml viene tradotta in un formato XML intermedio piùcompatto e maneggevole. In particolare l'albero XML che de�nisce l'ontologiaGraphML viene visitato, per ogni tipo di widget Gra�oo previsto viene gene-rato un RTF globale apposito e i risultati ottenuti vengono fusi in un unicoalbero. La generazione di RTF globali indipendenti permette di sfruttare gliRTF già de�niti nella creazione dei successivi3, riducendo la complessità dellatrasformazione. Di seguito sono elencate alcune delle operazioni fondamentalie�ettuate in questa fase:

I Attribuzione di ogni elemento alla sua ontologia di appartenenza e, nelcaso di entità, generazione delle annotazioni rdfs:isDefinedBy sottoforma di additional axiom a esse associati.

I Splitting degli archi dotati di etichette multiple e attribuzione di un idunivoco a ognuno di essi.

I Generazione di annotazioni rdfs:label e rdfs:comment sotto formadi additional axiom, per quelle entità provviste di descrizione fornitadall'utente.

I Scansione degli assiomi ed eventuale loro riconoscimento all'interno delvocabolario degli assiomi OWL de�nito in config.xml. Gli assiomi ri-conosciuti vengono tradotti nella corrispondente notazione Manchestere con essi vengono memorizzati i tipi accettati per il soggetto e l'ogget-to dell'asserzione (informazioni necessarie per attuare il punning di talientità).

I Attribuzione degli additional axiom alle entità cui si riferiscono.2Un RTF è una variabile XSLT di tipo nodo che de�nisce un albero XML. Gli RTF

erano già presenti in XSLT 1.0, ma dalla versione 2.0 è possibile navigarli tramite espres-sioni XPath. Questo permette di utilizzarli, oltre che per conservare risultati di elaborazioniparziali, anche come risultati strutturati restituibili da funzioni XSLT user-de�ned (altrafunzionalità introdotta in XSLT 2.0).

3XSLT non impone che una variabile globale referenziata venga dichiarata prima del suoreferente, purché ovviamente non ci siano dipendenze cicliche.

31


4.3.2 Gestione del punning

In questa fase viene e�ettuato il punning delle entità che intervengono comesoggetto/oggetto di asserzioni. In particolare per ogni assioma viene estrapola-to il tipo atteso per il soggetto/oggetto dell'assioma e, se questo non coincidecon il tipo corrente dell'entità, l'entità viene duplicata e l'assioma viene ag-giornato per referenziare il nuovo nodo XML. Il punto delicato di questa faseè la determinazione del tipo cui convertire l'entità soggetto/oggetto. L'alberodelle scelte implementato dal motore XSLT è schematizzato come segue:

1. L'assioma non è uno degli assiomi OWL (caso banale): l'entità sor-gente è necessariamente un individuo, mentre quella target è un indi-viduo 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à è determi-nato 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 dellesue eventuali repliche nel diagramma.

(c) L'assioma prevede entità soggetto e oggetto non necessariamentedello stesso tipo: nel caso di assiomi rdfs:domain e rdfs:range iltipo �nale può essere estrapolato in funzione sia dell'assioma chedel tipo dell'altro end-point o da eventuali sue repliche, altrimen-ti viene determinato da eventuali repliche dell'entità corrente neldiagramma.

(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 �at-tuati� gli assiomi owl:imports. In particolare, le entità de�nite in ontologie im-portate e referenziate da qualche arco appartenente all'ontologia che importa,entrano anch'esse a fare parte di tale ontologia.

4Per esempio, l'entità è un individuo e l'assioma è di tipo rdf:type.5Per esempio, l'assioma owl:disjointWith prevede che le entità coinvolte siano entrambe

classi.6Per 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 annotationproperty.

32


4.3.4 Analisi delle stringhe Manchester

Gra�oo permette che i widget testuali quali class rectriction, datarangerestriction e additional axiom facciano riferimento a entità non già de�niteesplicitamente dall'utente. In questa fase GraMOS analizza quindi le stringheManchester ed e�ettua una dichiarazione automaticha di quelle entità in esserilevate e non già dichiarate7. La ricerca avviene sfruttando la versatilità delleespressioni regolari.

4.3.5 Traduzione in Manchester syntax

Ultima fase della trasformazione, l'ontologia subisce l'e�ettiva traduzionedal formato XML intermedio alla sintassi Manchester, ordinando gli stamentOWL secondo una delle due possibili modalità viste in precedenza. Il risultatoemesso è in realtà ancora un RTF: ogni ontologia e�ettivamente presente neldiagramma Gra�oo iniziale viene infatti incapsulata all'interno di un nodoontology in modo da permetterne la stampa di�erenziata su �le distinti oppurel'output della sola main ontology.

4.4 Posizionamento delle edge label

Gra�oo 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 direttamentelinkati ai propri target, l'associazione con le proprietà si basa sulla vicinanzatra il box rappresentante l'assioma e la label dell'arco. In particolare, dato unadditional axiom non direttamente linkato ad alcun nodo, si assume che esso siaassociato 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 perle etichette degli archi comporta che l'esplicitazione di questa associazione siaun'operazione tutt'altro che banale. Infatti, mentre i nodi del diagramma sonolocalizzati con coodinate assolute rispetto al vertice top-left del diagramma, lecoordinate del box che de�nisce l'etichetta di un arco sono relative al punto diintersezione 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 Gra�oosi 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 de�niti tipi di dato ad-hoc quali punti, rette, segmenti e box8 eimplementati di�erenti meccanismi basati su di essi.

7In un'ontologia OWL tutte le entità referenziate devono essere dichiarate.8I costruttori di tali tipi di dato sono funzioni che restituiscono alberi XML con una

determinata struttura interna.

33


Figura 4.1: Al contrario dei nodi, le etichette degli archi in yEd non sonoposizionate in modo assoluto bensì secondo un complesso sistema di po-sizionamento relativo. Si noti che i nodi sorgenti non sono necessaria-mente 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 de�niscono il primo segmento dell'arco (ilsegmento che interseca il nodo sorgente) ed eventuale calcolo delle lorocoordinate assolute9.

I Calcolo dei segmenti che de�niscono i lati del box sorgente. Tipicamentei lati dei nodi sono orizzontali e verticali. Tuttavia i datatype sono dotatidi lati ogliqui, la cui pendenza è calcolata in funzione delle dimensioni delbox10. Si assume invece che i nodi non abbiano subito rotazioni durantel'editing del diagramma.

I Calcolo del punto di intersezione tra l'arco e uno dei quattro lati del boxdel nodo sorgente, operazione basata sull'intersezione tra rette e veri�cache il punto ottenuto appartenga e�ettivamente ai segmenti interessati.Tuttavia, dato che le coordinate assolute calcolate del punto sorgentedell'arco potrebbero cadere leggermente fuori dal box del nodo sorgente(eventualità che impedirebbe di trovare il punto di intersezione tra isegmenti), è stato necessario implementare un meccanismo che, durantela veri�ca di appartenenza del punto ai segmenti interessati, consideri

9Il primo e l'ultimo punto all'interno del path di un arco sono localizzati relativamenteal centro del box del nodo rispettivamente sorgente e target.

10In yEd il vertice top-left di un nodo con forma a parallelogramma è shiftato versodestra del 10% della sua larghezza rispetto alla posizione del box. Analogamente il verticebottom-right è shiftato verso sinistra.

34

tolleranze sempre maggiori �no a esito positivo. Questo garantisce chel'intersezione restituisca sempre almeno un punto.

I Implementazione della radice quadrata per approssimazioni successivetramite il metodo di Newton11, necessario per determinare la distanzatra due punti del piano cartesiano non allineati. In base a esso, l'ap-prossimazione (n + 1) esima della radice quadrata di un numero N èdata da

a(n+ 1) =1

2

{a(n) +

N

a(n)

}

4.5 Formato XML intermedio

GraMOS e�ettua la traduzione dell'ontologia Gra�oo per trasformazionisuccessive ed elaborazione di RTF parziali. Questi costituiscono di fatto lestrutture dati utilizzate dal motore XSLT per rappresentare e manipolare l'on-tologia. Il seguente DTD12 descrive il formato XML interno adottato dagli RTFintermedi:

<!ELEMENT ontology EMPTY>

<!ATTLIST ontology

id ID #REQUIRED

name CDATA #REQUIRED

main-ontology CDATA #FIXED "" >

<!ELEMENT prefix EMPTY>

<!ATTLIST prefix

prefix CDATA #REQUIRED

uri CDATA #REQUIRED

ontology-id IDREFS #IMPLIED >



<!ELEMENT class EMPTY>

<!ATTLIST class

id ID #REQUIRED


ontology-id IDREFS #REQUIRED

appearance CDATA #IMPLIED >

<!-- Same structure for object-property, data-property

11Il metodo di Newton, o metodo di Newton-Raphson, o metodo delle tangenti, permettedi calcolare in modo approssimato una soluzione di un'equazione della forma f(x) = 0approssimando iterativamente la funzione con la sua tangente.Metodo di Newton su Wikipedia: http://en.wikipedia.org/wiki/Newton's_method.

12DTD, Document Type De�nition: http://www.w3.org/TR/REC-xml/#elemdecls.

35

http://en.wikipedia.org/wiki/Newton's_method

http://www.w3.org/TR/REC-xml/#elemdecls

and annotation-property -->

<!ELEMENT object-property EMPTY>

<!ATTLIST object-property

id ID #REQUIRED


source-id IDREF #REQUIRED

target-id IDREF #REQUIRED

ontology-id IDREFS #REQUIRED >



<!ELEMENT object-property-facility EMPTY>

<!ATTLIST object-property-facility

id ID #REQUIRED



<!ELEMENT axiom EMPTY>

<!ATTLIST axiom

id ID #REQUIRED


source-id IDREF #REQUIRED


ontology-id IDREFS #REQUIRED

owl-axiom CDATA #FIXED ""

domain-type NMTOKENS #IMPLIED

range-type NMTOKENS #IMPLIED >

<!ELEMENT additional-axiom EMPTY>

<!ATTLIST additional-axiom




<!ELEMENT rule EMPTY>

<!ATTLIST rule



<!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


In particolare:

I Gli attributi id identi�cano univocamente i nodi XML nella strutturadati, referenziati dagli attributi ontology-id, source-id e target-id.Nel caso in cui sia attivata la modalità debug, tali referenze sono inoltreaccompagnate da corrispondenti attributi ontology-name, source-name,target-name speci�canti il valore dell'attributo name del nodo referen-ziato, in modo da favorire l'analisi dei risultati intermedi.

I L'attributo vuoto main-ontology identi�ca la main ontology del dia-gramma, unica per le assunzioni sul diagramma in input.

I L'attributo vuoto owl-axiom viene assegnato a quegli assiomi riconosciu-ti da GraMOS all'interno del vocabolario degli assiomi OWL 2, e deter-mina la presenza degli attributi domain-type e range-type, utilizzatiper l'eventuale punning del soggetto/oggetto dell'assioma.

4.6 Parametri di trasformazione

GraMOS consente all'utente di personalizzare il risultato emesso in outputdal motore di trasformazione tramite un set di parametri XSLT, i cui valori didefault sono de�niti nel �le di con�gurazione config.xml.

generate-all-ontologies-param : booleano indicante se è necessario gene-rare un �le owl per ogni ontologia dichiarata nel diagramma Gra�oo(true) oppure per la sola main ontology (false).

use-hierarchical-visit-param : booleano, speci�ca se l'output Manchesterdebba adottare l'ordinamento gerarchico (true) oppure l'ordinamentousuale per le ontologie OWL 2 espresse in Manchester syntax (false).

use-depth-first-visit-param : booleano, nel caso in cui venga adottato l'or-dinamento gerarchico degli statement Manchester, speci�ca se l'alberodelle classi vada visitato secondo la modalità depth-�rst (true) oppurebreadth-�rst (false).

maintain-appearance-param : booleano indicante se l'ontologia �nale deb-ba tenere traccia di informazioni presentazioni del diagramma Graf-foo iniziale (true), oppure se tali informazioni possano essere ignorate(false).

use-imported-ontology-version-iri-param : booleano, nel caso di ontolo-gie importate, speci�ca se lo statement Manchester Import debba uti-lizzare l'IRI generale dell'ontologia importata (false) oppure l'IRI diversione se dichiarato (true).

37


default-ontology-iri-param : stringa, nel caso in cui nel diagramma Gra�ool'utente abbia de�nito entità al di fuori di un ontology widget, questo va-lore viene utilizzato come IRI di un'ontologia auto-generata cui attribuiretali entità.

default-empty-prefix-param : stringa utilizzata come IRI di un pre�sso vuo-to auto-generato nel caso in cui l'utente non lo abbia dichiarato esplici-tamente tramite l'apposito pre�x widget.

4.7 Test e valutazioni

Proponendosi come intermediario tra la fase di progettazione e quella direale generazione ontologica, GraMOS si assume la responsabilità di emetterein output ontologie che rispecchino fedelmente il modello gra�co in input. Perveri�care la correttezza del processo di traduzione, il progetto GraMOS è statotestato empiricamente fornendo sia input generati ad-hoc, per valutare sepa-ratamente 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 estremamenteutile in quanto permette di studiare l'evoluzione progressiva dell'ontologia.

Le ontologie Manchester ottenute dai diagrammi più signi�cativi sono statevalidate sia attraverso il validatore della Manchester University13, sia impor-tandole all'interno dell'editor ontologico Protégé. I test personali di correttezzarisultano quindi positivi e il tool GraMOS pare non a�etto da bug evidenti.Tuttavia sarà necessario sottoporlo a valutazioni esterne per valutare la suae�ettiva usabilità, intesa come capacità del motore di trasformazione di com-portarsi e�ettivamente come gli utenti si aspettano. Una bassa usabilità intal senso vani�cherebbe infatti l'utilizzo di GraMOS in quanto l'utente, noncompreso nelle sue esigenze e quindi non soddisfatto del risultato �nale, neces-siterebbe di mettere mano personalmente agli statement OWL dell'ontologiagenerata, cadendo in quel fastidioso processo di generazione ontologica di cuiavrebbe dovuto occuparsi il tool.

4.8 Tecnologie adottate

Per ottimizzare lo sviluppo è stato adottatoOxygen XML Editor 14, softwareproprietario della Syncro Soft rilasciato con licenza a pagamento15. Oxygen èinfatti uno dei più apprezzati IDE per lo sviluppo di tecnologie XML, fornen-do in particolare supporto per l'editing, il debugging e il testing di moduli

13Manchester University OWL Validator: http://owl.cs.manchester.ac.uk/

validator/.14Oxygen XML Editor homepage: http://www.oxygenxml.com/.15È disponibile anche una licenza di prova gratuita della durata di trenta giorni.

38



http://www.oxygenxml.com/


XSLT 2.0. Oxygen è disponibile sia in versione standalone per sistemi oper-ativi Windows, Mac e Linux, sia sotto forma di plugin per Eclipse, sia comeapplicazione Java Web Start. In particolare lo sviluppo è avvenuto su EclipseIndigo JEE16 esteso con il plugin Oxygen XML Editor and XSLT Debuggerv15.2. Per il testing ci si è a�dati al processore Saxon Home Edition v9.5,integrato nell'IDE Oxygen17.

16Eclipse 3.7 for Java EE Developers.17Saxonica home page: http://www.saxonica.com/.

39

http://www.saxonica.com/


40

Capitolo 5

Conclusioni

La produzione ontologica è una pratica fondamentale per la crescita delWeb Semantico, in quanto le ontologie permettono la strutturazione delWeb of

data e l'attribuzione di valori semantici ai dati in esso pubblicati. Le notazionigra�che per ontologie quale Gra�oo sempli�cano il processo di progettazionedi ontologie e permettono la creazione di modelli ontologici facilmente inter-pretabili anche da comunità estranee al mondo del Semantic Web. GraMOSpermette di fondere la fase di progettazione ontologica visuale basata su Graf-foo con quella di generazione dell'ontologia formale corrispondente al modellogra�co, evitando all'utente un fastidioso e costoso cambio sia di prospettiva siadi strumentazione. Gra�oo evolve quindi da semplice strumento per descrivere,progettare, condividere ontologie OWL 2, a vero e proprio tool di generazioneontologica per via gra�ca.

L'integrazione di GraMOS con la piattaforma Web DiTTO sempli�ca lafase di trasformazione rispetto all'esecuzione locale1 e alleggerisce l'utente dalleoperazioni di con�gurazione dell'ambiente di esecuzione ed eventuale aggiorna-mento dei sorgenti. Per rendere cross-platform l'intero processo di generazioneontologica, la piattaforma DiTTO potrebbe essere estesa con una canvas yEdper consentire la creazione di diagrammi Gra�oo da browser, liberando l'utentedalla necessità di installare in locale l'editor yEd e la palette Gra�oo. Taleoperazione è infatti praticabile semplicemente grazie alle API messe a dispo-sizione dallo stesso yEd per l'editing online2. Parallelamente, per chi preferiscel'esecuzione in locale, si potrebbe prendere in considerazione il rilascio di unaversione stand-alone di GraMOS dotata di un'apposita interfaccia gra�ca.

L'implementazione di un meccanismo di round-trip da ontologie OWL con-crete a diagrammi Gra�oo introdurrebbe la funzionalità mancante per rendereil binomio Gra�oo/GraMOS una sorta di editor ontologico basato su editingvisuale. Tale meccanismo richiede però la risoluzione di problemi non banali,

1DiTTO dispone di form appositi per l'upload dell'ontologia Gra�oo e la gestione deiparametri di trasformazione.

2I cosidetti yFiles for HTML: http://www.yworks.com/en/products_yfileshtml_

about.html.

41

http://www.yworks.com/en/products_yfileshtml_about.html

http://www.yworks.com/en/products_yfileshtml_about.html

prima tra tutte la gestione del posizionamento dei widget Gra�oo in modo cheil diagramma ottenuto sia visibilmente chiaro e pulito. Una soluzione approssi-mata potrebbe prevedere il ra�namento dell'attuale sistema di mantenimentodelle informazioni presentazionali nella traduzione da gra�co a testuale e quindila capacità di elaborare quelle ontologie OWL testuali che siano state ottenuteda GraMOS.

In�ne, l'introduzione del supporto per sintassi alternative sempli�cherebbel'interscambio delle ontologie create, evitando il passaggio tipicamente obbli-gato attraverso un convertitore sintattico OWL. Tuttavia una simile esten-sione richiede l'implementazione di un sistema di parsing e traduzione dallaManchester syntax verso la sintassi target.

Nella comunità del Semantic Web lo sviluppo di tecnologie che abbatti-no il livello di complessità delle operazioni di analisi ontologica e SemanticPublishing è in rapida ascesa. Ci auguriamo che GraMOS possa costituire uncontributo positivo all'interno di questo movimento e fungere da terreno fertileper l'ideazione di nuove tecnologie per la crescita del Semantic Web.

42

Bibliogra�a

[BBC10a] Barzdi�n², J., Barzdi�n², G., �erans, K., Liepi�n², R., Spro�gis, A.(2010), �OWLGrEd: a UML Style Graphical Notation and Editor for OWL2�, In Proceedings of the 7th International Workshop on OWL: Experience

and Directions (OWLED-2010), San Francisco, California, USA, 21-22Giugno 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 (SecondEdition), W3C Recommendation, 14 Dicembre 2010, World Wide WebConsortium: 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 Ser-vice 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 TransformationinTo OWL�, In Blomqvist, E., Groza, T. (Eds.), Proceedings of the ISWC

2013 Posters e Demos Track (ISWC-PD 2013), Sydney, Australia, 23Ottobre 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 ontolo-gies used for knowledge sharing�, In International Journal of Human-

Computer Studies, 43: 907�928. Academic Press. Novembre 1995, http://www.sciencedirect.com/science/article/pii/S1071581985710816.

43

http://www.w3.org/TR/xpath20/

http://graphml.graphdrawing.org/primer/graphml-primer.html


http://www.w3.org/TR/2012/REC-owl2-quick-reference-20121211/

http://www.w3.org/TR/2012/REC-owl2-quick-reference-20121211/

http://ceur-ws.org/Vol-1035/iswc2013_demo_2.pdf

http://ceur-ws.org/Vol-1035/iswc2013_demo_2.pdf

http://www.sciencedirect.com/science/article/pii/S1071581985710816

http://www.sciencedirect.com/science/article/pii/S1071581985710816

[GW12] Golbreich, C., Wallace, E. (2012), OWL 2 Web Ontology LanguageNew 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 Speci�ca-tion, 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), W3CRecommendation, 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 Lan-guage 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 Rec-ommendation, 23 Gennaio 2007, World Wide Web Consortium: http://www.w3.org/TR/xslt20/.

[MPP12] Motik, B., Patel-Schneider, P., Parsia, B. (2012), OWL 2Web Ontology Language Structural Speci�cation and Functional-Style Syntax (Second Edition), W3C Recommendation, 11 Dicembre2012, 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 IntegratedRepresentation of OWL Ontologies�, In Proceedings of the 9th Interna-

tional Conference on Web Information Systems and Technologies (WE-BIST 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 Uni�ed Vi-sual Notation for OWL Ontologies: Insights from a Comparative UserStudy�, In Proceedings of the 9th International Conference on Seman-

tic 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 Documen-tation Environment: a tool for the automatic generation of ontology doc-umentation�, In ten Teije, A., Völker, J., Handschuh, S., Stuckenschmidt,H., d'Aquin, M., Nikolov, A., Aussenac-Gilles, N., Hernandez, N. (Eds.),

44

http://www.w3.org/TR/owl2-new-features/

http://www.w3.org/TR/owl2-new-features/



http://www.w3.org/TR/2012/REC-owl2-primer-20121211/

http://www.w3.org/TR/2012/REC-owl2-primer-20121211/

http://www.w3.org/TR/owl2-manchester-syntax/

http://www.w3.org/TR/owl2-manchester-syntax/

http://www.w3.org/TR/xslt20/

http://www.w3.org/TR/xslt20/

http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/

http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/

http://vowl.visualdataweb.org/v1/VOWL2013.pdf

http://www.vis.uni-stuttgart.de/uploads/tx_vispublications/VisualNotationOWL.pdf

http://www.vis.uni-stuttgart.de/uploads/tx_vispublications/VisualNotationOWL.pdf

Proceedings of the 18th International Conference on Knowledge Engineer-

ing 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), Gra�oo, Graphical Framework for OWL On-tologies, Silvio Peroni, 2013: http://www.essepuntato.it/graffoo/

(ultima visita: marzo 2014).

[PER13b] Peroni, S. (2013), Gra�oo Speci�cation, Silvio Peroni, 28ottobre 2013: http://www.essepuntato.it/graffoo/specification/

current.html.

[PSV13] Peroni, S., Shotton, D., Vitali, F. (2013), �Tools for the auto-matic 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 (2013), Semantic WebGraphical Notation, 15 luglio 2013: http://www.w3.org/wiki/

SemWebGraphicalNotation.

45


http://www.essepuntato.it/graffoo/specification/current.html

http://www.essepuntato.it/graffoo/specification/current.html

http://www.w3.org/standards/semanticweb/

http://www.w3.org/standards/semanticweb/

http://www.w3.org/wiki/SemWebGraphicalNotation

http://www.w3.org/wiki/SemWebGraphicalNotation

generazione di ontologie da rappresentazioni grafiche · più propriamente l'obiettivo nale...

Documents