UNIVERSITÀ DEGLI STUDI DI TORINO. Strumenti e schemi per la codifica di conoscenza prototipica in formati semanticamente ricchi

Transcript

1 UNIVERSITÀ DEGLI STUDI DI TORINO DIPARTIMENTO DI INFORMATICA Corso di Laurea in Informatica Relazione di Stage Strumenti e schemi per la codifica di conoscenza prototipica in formati semanticamente ricchi Relatori: Daniele P. Radicioni Antonio Lieto Candidato: Davide Colla Anno Accademico 2013/2014

2 Indice 1 Introduzione Informazione prototipica e ontologie Ontologie OWL RDF Linked Data SPARQL Spazi concettuali Il sistema Il formato interno Traduzione da XML a RDF Tool di annotazione ed editor Creazione di triple store La sperimentazione Estrazione query dalle descrizioni testuali Confronto fra DBPedia e PrototyPedia Conclusioni Ricapitolazione del lavoro Futuri sviluppi Bibliografia 37 i

3 Capitolo 1 Introduzione Il lavoro descritto in questa tesi si inserisce nel quadro di una ricerca volta a investigare un sistema ibrido per la rappresentazione della conoscenza concettuale, basato sull integrazione di ontologie e spazi concettuali. In particolare, questo lavoro muove dal tentativo di superare i limiti rappresentazionali e inferenziali dei sistemi ontologici standard: la restrizione principale dal punto di vista rappresentazionale è data dal fatto che le ontologie non consentono di rappresentare l informazione prototipica. Questo tipo di informazione può essere invece rappresentato tramite il paradigma degli spazi concettuali, che consentono di rappresentare la conoscenza tramite un insieme di spazi vettoriali; la riformulazione di tale conoscenza ha richiesto la definizione di un formato interno, punto di partenza per l attività di questa tesi. Scopo del lavoro descritto è trasformare la base di conoscenza disponibile al sistema in un triple store (ossia una base di conoscenza disponibile attraverso la rete e interrogabile tramite il linguaggio SPARQL, illustrato nel seguito) in formato RDF. Tale rappresentazione viene pubblicata secondo i principi dei Linked Data, uno degli strumenti più ampiamente utilizzati nell implementazione del Semantic Web. Presenteremo anche un tool sviluppato nel coro dell attività di tesi avente la doppia funzione di annotare nuovi elementi nel formato XML del sistema, e di permettere l aggiunta di parametri di descrizione per gli elementi del formato XML. L idea alla base della conversione è portare la codifica della conoscenza da un formato personalizzato nato durante il corso di un progetto di ricerca ad un formato

4 1.1. Informazione prototipica e ontologie 2 standard integrabile ed accessibile via Web e, soprattutto, collegato ad altri triple store nella logica dei Linked Data [9]. Per quanto riguarda il tool di annotazione, invece, questo ha lo scopo di facilitare l inserimento di nuovi elementi in previsione di attività future e consentire la modifica dello schema di descrizione degli elementi permettendo l aggiunta, a run time, di nuove caratteristiche. 1.1 Informazione prototipica e ontologie Uno dei più grossi limiti rappresentazionali delle ontologie, e così anche delle description logics, è la rappresentazione dell informazione prototipica, in particolare il problema principale è rappresentato dalle eccezioni. Un esempio evidente di tale punto è il seguente: supponendo di prendere in esame la categoria degli uccelli, ogni persona ha una propria rappresentazione mentale dell uccello, tipicamente vola, ha un becco, le ali, due zampe, vive in un nido; il problema si pone quando, secondo questa conoscenza tipica dell uccello, si cerca di rappresentare il pinguino, questo viene classificato come uccello. Tuttavia si tratta di un uccello particolare, in quanto non è in grado di volare. Il problema dal punto di vista ontologico è lo stesso, se si suppone di fornire ad un sistema, che utilizza un ontologia, in cui l uccello viene codificato con le informazioni prototipiche di cui sopra, risulta effettivamente difficile rappresentare il pinguino, e di fatto l unico metodo di soluzione è la costruzione di una soluzione ad hoc. L informazione prototipica può essere utile per rappresentare le eccezioni [6]: se si suppone di prendere in esame il concetto di acqua, la conoscenza classica rappresenta l acqua secondo la formula chimica H 2 O, ossia due molecole di idrogeno ed una di ossigeno disposte secondo un preciso legame chimico. Queste sono informazioni necessarie e sufficienti perché un concetto sia classificato come acqua; tuttavia l informazione prototipica da una definizione più evidente del concetto di acqua, ossia tipicamente è liquida, inodore, incolore e priva di gusto. Il problema non è solamente quello di rendere evidente il concetto, bensì come e quando effettivamente si può asserire di aver rappresentato il concetto di acqua: per un Eschimese l acqua tipicamente è solida, ed è necessario picconarla; mentre per quanto riguarda una persona che vive all equatore il concetto di acqua è sicuramente definito da altri tratti tipici. Risulta quindi difficile rappresentare

5 1.2. Ontologie 3 l informazione prototipica, secondo quanto detto ogni persona ha una definizione che potenzialmente differisce da ogni altra, il problema di capire quando il concetto viene effettivamente raggiunto, e quindi rappresentato correttamente, è un problema ancora aperto: conosce l acqua chi ne conosce la formula chimica o chi è in grado di riconoscerla in un ruscello che scorre o in un igloo, o chi dispone di entrambi i tipi di informazione? 1.2 Ontologie Sebbene il termine ontologia derivi dalla filosofia, trova ampiamente spazio anche nell informatica. Il senso filosofico del termine è molto distante dall accezione oggi utilizzata in informatica, in quanto l ontologia viene definita come lo studio dell essere in quanto tale, e delle sue categorie fondamentali. In ambito informatico le ontologie (dette ontologie formali) sono associate a un significato più ristretto: un ontologia può contenere solamente un frammento di conoscenza, il problema sta nel comprendere quale frammento rappresentare. Le ontologie si possono suddividere in due grandi categorie: Ontologie specializzate o di dominio. Si tratta dello strumento più impiegato per fini pratici, sono ontologie basate su uno specifico dominio, all interno di esse vengono rappresentati in maniera esaustiva i concetti appartenenti a tale dominio, chiaramente visto il dominio limitato non sono ottime in senso ampio ma sono perfette per sistemi specifici; Ontologie fondazionali. Si tratta di ontologie molto più vicine al significato filosofico, che rappresentano tutti i concetti di base dell intera conoscenza offrendo quindi la possibilità di catalogare ogni tipo di concetto; queste ontologie forniscono un ottima base per costruire ontologie specializzate OWL OWL, Web Ontology Language, è una famiglia di linguaggi dichiarativi per la rappresentazione della conoscenza, utilizzati per sviluppare basi di conoscenza, o ontologie formali, effettuare inferenze sulle stesse ed integrarle con il Web. OWL è

6 1.2. Ontologie 4 uno standard promosso dal W3C ed insieme a RDF fa parte del progetto Semantic Web. Sostanzialmente OWL è formato da tre componenti di base: Assioma : è lo statement di base, l unità, che le ontologie sono in grado di esprimere; Entità : è l insieme degli elementi utilizzati per identificare oggetti appartenenti al mondo reale; Espressione : è una combinazione di entità atte a formare descrizioni complesse a partire da quelle di base. Gli statement di un ontologia sono quindi detti assiomi; in generale possono essere sia veri che falsi, ossia è possibile asserire anche elementi falsi. Per quanto riguarda invece le entità generalmente gli statement OWL hanno una forma strutturata, si riferiscono tipicamente ad oggetti ed a loro classificazioni e/o relazioni, tutti gli elementi di uno statement che siano essi oggetti, categorie o relazioni vengono detti entità, in particolare OWL ha una distinzione ben precisa fra oggetti che prendono il nome di individui, categorie che sono dette classi, e relazioni che prendono il nome di proprietà. Queste ultime hanno un ulteriore suddivisione in proprietà sui dati, ossia proprietà che assegnano un valore ad un oggetto (ad esempio l età di una persona), e proprietà sugli oggetti che descrivono relazioni fra gli oggetti stessi. OWL è composto sostanzialmente da tre sottoinsiemi di linguaggi, progettati per differenti categorie di utenti, ognuno dei quali ha un espressività crescente, in particolare tutti i casi presentano un trade off tra potenza espressiva da un lato e vantaggi computazionali dall altro, nello specifico si intendono completezza, ossia la garanzia che le conclusioni siano computabili e decidibilità, cioè il fatto che tutte le computazioni abbiano un tempo di esecuzione finito: OWL Lite : permette la definizione di gerarchie semplici e vincoli poco complessi, chiaramente ha il vantaggio di essere sempre computabile e completamente decidibile; OWL DL : progettato per utenti che necessitano della massima espressività a patto di mantenere la completezza e la decidibilità, nello specifico OWL DL, DL sta per Description Logics, include tutti i costrutti del linguaggio ma utilizzabili solo sotto specifiche restrizioni;

7 1.2. Ontologie 5 OWL Full : progettato per fornire la massima potenza espressiva e libertà sintattica al prezzo di non fornire alcuna garanzia computazionale, ad esempio le classi possono essere trattate simultaneamente come collezioni di individui ed individui stessi. L idea di OWL è quindi quella di fornire una famiglia di linguaggi, strettamente basati sulla logica, per la rappresentazione di conoscenza, in particolare tali linguaggi sono formati da assiomi che danno la possibilità ai cosiddetti reasoners, ossia strumenti software in grado di esplicitare conoscenza implicita, di effettuare inferenze su tali basi di conoscenza. Nel 2008 il W3C ha pubblicato OWL2 1 ossia una versione aggiornata di OWL con un ulteriore suddivisione in tre nuove categorie di sottoinsiemi, nel caso specifico vengono detti profili ed hanno sostanziali differenze che li rendono adatti a situazioni diverse: OWL EL(Existential Language) : utile per ontologie che contengono un elevato numero di proprietà e/o classi, alcuni tipi base di inferenze risultano particolarmente efficienti, nel caso specifico hanno un tempo polinomiale rispetto all ampiezza dell ontologia, sono già presenti algoritmi di inferenza dedicati per questo profilo; OWL QL(Query Language) : progettato per ontologie composte da molti individui, cioè manipolano un elevato quantitativo di istanze con l obiettivo principale di rispondere a interrogazioni. Come per il profilo precedente sono già definiti algoritmi, polinomiali, per la risoluzione di problemi. L espressività di questo profilo è limitata, ciononostante include gran parte delle caratteristiche principali dei modelli concettuali; OWL RL(Rule Language) : questo profilo ha lo scopo di rendere possibile lo scalable reasoning, ossia la possibilità di fare inferenza in maniera scalare e distribuita, senza sacrificare troppo la potenza espressiva, ossia è progettato per sistemi che preferiscono maggior espressività al prezzo di un efficienza minore. 1

8 1.2. Ontologie 6 La famiglia di linguaggi OWL supporta, quindi, un ampia serie di sintassi, ognuna delle quali si pone un obiettivo differente. Vi è una sintassi funzionale che ha lo scopo di facilitare la specifica e le basi di tools come APIs e reasoners. Esiste una notazione RDF/XML che consiste semplicemente di un estensione della stessa con un opportuna traduzione per i costrutti OWL. La sintassi di Manchester, il cui scopo è quello di facilitare la lettura a utenti con minore confidenza con la logica. Esiste una sintassi XML di OWL definita dall XML Schema stesso RDF RDF, Resource Description Framework 2, è un modello base per la codifica, lo scambio ed il riutilizzo di dati strutturati sul Web, nel caso specifico si parla di metadati, ossia dati, strutturati, relativi ad una risorsa Web comprensibili dalle macchine, si tratta quindi di una base, standard, per poter esprimere la semantica [7]. L RDF ha un ampia gamma di sintassi possibili, fra cui: Turtle : un formato compatto e facilmente leggibile da umani; N-Triples : un formato semplice e facile da parsificare, non compatto quanto Turtle; N3 o Notation 3 : un formato non standard ma largamente impiegato, simile a Turtle; RDF/XML : un formato basato sulla sintassi XML, è stato il primo standard per la codifica di informazioni RDF. quelle più utilizzate sono RDF/XML o N3; il framework è formato da due componenti: RDF Model and Syntax : ossia la definizione del modello dei dati e la sintassi XML; RDF Schema : permette la definizione di vocabolari per i metadati. 2

9 1.2. Ontologie 7 L RDF data model fornisce, quindi, un modello per la descrizione e la specifica di risorse, uno dei fondamenti di tale concetto è l URI, Uniform Resource Identifier, ossia RDF definisce risorse come oggetti identificabili univocamente da URI. Il modello dei dati RDF è formato sostanzialmente da tre componenti: Risorse: sono identificate univocamente da un URI, possono essere qualsiasi tipo di oggetto, sia raggiungibile via Web che appartenente al mondo reale, ogni cosa definita da uno statement RDF è una risorsa; Predicati: anche detti proprietà, si tratta di qualsiasi relazione, caratteristica o attributo che riguardano una specifica risorsa, ogni proprietà può essere vista come una funzione matematica, ha una definizione ben precisa di dominio e codominio; Statements: gli statements RDF vengono detti triple in quanto sono formati da tre elementi, un soggetto, ossia una risorsa, un predicato, cioè una proprietà definita su quella specifica risorsa, ed un oggetto, ossia un valore specifico per la proprietà, generalmente si parla di triple s-p-o, Subject-Predicate- Object, in particolare l oggetto può essere un altro statement, una risorsa o un tipo primitivo di dato. Come mostrato graficamente in Figura 1.1 gli statement vengono rappresentati come dei grafi etichettati ed orientati in cui le risorse vengono rappresentate come i nodi del grafo, i predicati sono gli archi orientati ed etichettati con il nome della proprietà ed i valori sono rappresentati come elementi rettangolari nel grafo. L esempio più classico è quello che permette di mostrare l autore di un documento, Resource1 Property3 Property1 Property2 Resource2 Literal Literal Property4 Resource3 Figura 1.1: Rappresentazione generica di un grafo RDF. supponendo che il documento A sia stato scritto da John Doe, mediante RDF è possibile rappresentare facilmente queste informazioni in formato machine-readable,

10 1.2. Ontologie 8 con la rappresentazione a triple si otterrebbe quindi: Resource : DocumentA P ropoerty : author V alue : JohnDoe Dato che ogni entità è identificata da una URI, se si suppone che il documento sia e che John Doe abbia la propria pagina Doe si ha la seguente rappresentazione grafica come mostrato in Figura 1.2: L RDF Schema, invece, permette la definizione di vocawww.examples.com/documenta author Doe Figura 1.2: Rappresentazione grafica dell esempio. bolari, ossia permette la specifica di nuove proprietà dando, così, la possibilità di descrivere le relazioni fra risorse definendo le caratteristiche dei predicati Linked Data Uno degli obiettivi principali del Semantic Web è quello di connettere insiemi di dati strutturati (per esempio quelli menzionati, in formato RDF) in modo da facilitare la ricerca sia a macchine che ad umani, a tal proposito Tim Berners Lee ha introdotto il concetto di Linked Data. Il termine Linked Data indica una serie di best practices per la pubblicazione di dati strutturati e connessi fra loro nel Web, l idea che quindi sta alla base è quella di impiegare l architettura del Web per la pubblicazione e la diffusione di dati correttamente strutturati, uno dei concetti fondamentali di tale architettura è l URI come meccanismo globale di identificazione, per quanto riguarda l HTTP si tratta di un meccanismo di accesso alle risorse mentre nel contesto dell RDF assume il ruolo di identificatore di elementi, concetti o risorse. Tim BernersLee presentò i linked data alla conferenza TED, Technolo-

11 1.2. Ontologie 9 gy Entertainment Design, del 2009, definendo quelli che, come specificato in [1], vengono detti I Principi dei Linked Data : 1. Usare URI per identificare oggetti. 2. Usare HTTP URI in modo che questi oggetti possano essere referenziati e cercati da persone e user agent. 3. Fornire informazioni utili sull oggetto quando la sua URI è dereferenziata, usando formati standard come RDF. 4. Includere link ad altre URI relative ai dati esposti per migliorare la ricerca di altre informazioni relative nel Web. Il primo principio ha sostanzialmente l obiettivo di far sì che gli URI non vengano utilizzati soltanto come identificatori di risorse, come nel caso dell HTTP, ma anche per elementi reali, ossia vengano definiti URI per riferirsi a concetti del mondo non soltanto fisico, come oggetti reali, ma anche astratto, come sentimenti. Il secondo principio, invece, si pone l obiettivo di rendere possibile a macchine o persone di dereferenziare gli URI, mediante l impiego di HTTP, accedendo quindi alle risorse identificate o, quantomeno, ad informazioni utili sull oggetto richiesto. Il terzo principio consiglia l utilizzo di uno standard come RDF per la pubblicazione di dati sul Web: così come l impiego dell HTML ha permesso una facile e rapida diffusione ed evoluzione del Web, analogamente si cerca di ottenere lo stesso risultato per i Linked Data. L obiettivo è far sì che i dati siano pubblicati tutti con lo stesso modello standard. Il quarto principio ha l obiettivo di far sì che i collegamenti non siano soltanto fra documenti ma tra qualsiasi tipo di concetto, a differenza del Web classico dove i link fra risorse non hanno tipo nel contesto dei Linked Data i collegamenti hanno un tipo che descrive la relazione fra gli oggetti correlati, per evitare di confondere questo tipo di collegamenti con i link del Web classico essi vengono detti RDF link. I Linked Data sono quindi molto vicini al concetto di Web classico, senza il quale non potrebbero esistere. Anche l obiettivo è analogo: per quanto riguarda il Web si tratta di creare un insieme di informazioni universalmente accessibili, mentre con i Linked Data si cerca di creare un unico e globale insieme di dati interconnessi tra loro, tali connessioni devono rendere possibile la navigazione nel Web of Data.

12 1.2. Ontologie SPARQL Una delle più importanti caratteristiche dell RDF è che, oltre ad essere comprensibile dalle macchine, è interrogabile, lo strumento standard per le interrogazioni è SPARQL, acronimo ricorsivo che sta per SPARQL Protocol and RDF Query Language, ossia un linguaggio definito per interrogare dati rappresentati via RDF, infatti SPARQL permette la definizione di query basate su triple patterns. SPAR- QL fornisce differenti notazioni, ognuna di esse ha lo stesso potere espressivo, differiscono solamente per sintassi, in particolare la più diffusa è relativa alla notazione più utilizzata dall RDF, N3, Notation 3, oppure il suo sottoinsieme Turtle, quest ultima ha una forma particolarmente contratta facile da comprendere per esseri umani, per quanto riguarda N3, invece, la forma risulta meno compatta della precedente ma più facile da parsificare. SPARQL fornisce, quindi, una notazione basata su triple patterns, così come RDF hanno la forma subject-predicate-object, in particolare la notazione N3 rende molto bene l idea delle triple. I dati RDF possono anche essere visti come un normale database SQL formato da relazioni con tre colonne: soggetto, predicato ed oggetto, nello specifico SPARQL fornisce varie operazioni come join, ordinamento e aggregazione che sono tipiche di relazioni di questo tipo, inoltre permette la definizione di graph patterns, ossia la descrizione di grafi specificando le triple associate, con la restrizione che ogni variabile, che compare in più le triple, deve fare riferimento alla stessa risorsa, tipicamente, un grafo, viene denotato da un set di triple racchiuse tra parentesi graffe. Un esempio di query SPARQL, con notazione N3, che risponde alla domanda Qual è la capitale dell Italia? è la seguente: PREFIX s t a t e s : <http : / / example. com/ s t a t e s#> SELECT? c a p i t a l WHERE {? c a p i t a l s t a t e s : i s C a p i t a l O f s t a t e s : I t a l y } in cui è possibile definire variabili, nel caso specifico capital, semplicemente anteponendo il simbolo? al nome della variabile, in particolare una variabile può essere specificata in qualsiasi posizione ed il significato appunto è quello di non vincolare il campo specifico, ossia permettere che vengano selezionate le triple sen-

13 1.3. Spazi concettuali 11 za vincoli sul campo specifico, in questo caso vengono restituite tutte le triple che corrispondono al pattern variabile-predicato iscapitalof - oggetto Italy, dato che ogni oggetto è identificato da un URI è necessario specificare l identificatore di ogni elemento, a questo proposito è possibile definire dei prefissi, rdf-graph in questo caso, per facilitare la scrittura delle query. 1.3 Spazi concettuali Come sostenuto da Gärdenfors in [3], il web semantico basato sulle ontologie non è sufficientemente semantico: le ontologie sono strettamente basate sulla logica e quindi sull inferenza deduttiva; questa, tuttavia, comprende solo una minima parte del ragionamento umano che, per la maggior parte, funziona per tratti prototipici e si affida ad una classificazione per somiglianza. Questo tipo di ragionamento è sotto vari aspetti congeniale al tipo di rappresentazione degli spazi concettuali. La teoria degli spazi concettuali, introdotta da Peter Gärdenfors in [2] riguarda la rappresentazione dei concetti; ha alla base base la teoria dei prototipi, e sfrutta la nozione di similarità propria degli spazi vettoriali. Uno spazio concettuale è definito come uno spazio multidimensionale in cui i punti denotano gli oggetti mentre le regioni convesse, denotano i concetti; nel seguito, i punti identificano istanze di concetti, mentre diverse regioni rappresentano differenti tipologie di concetti. Ogni oggetto (ossia ogni punto dello spazio), è quindi descritto da una serie di valori in altrettante dimensioni, ognuna delle quali identifica una caratteristica dello stesso; la distanza fra questi punti fornisce un indice della similarità dei due oggetti. Dalle proprietà degli spazi concettuali viene naturale la rappresentazione di conoscenza prototipica, in particolare nel caso dei concetti questo è possibile mediante regioni convesse, il centro stesso di tali regioni identifica il prototipo, ossia l oggetto che rappresenta, per eccellenza, la categoria, quindi data una regione convessa è possibile calcolare la distanza di un punto, appartenente alla regione, ed il centro, questo fornisce un indice di prototipicità del concetto. La distanza fra due punti p 1,p 2 è calcolata come una combinazione tra distanza Euclidea e distanza angolare fra i punti; in particolare per punti che appartengono alla stessa regione viene utilizzato il normale criterio di distanza Euclidea, mentre

14 1.3. Spazi concettuali 12 per calcolare il divario fra punti appartenenti a regioni differenti viene utilizzata la distanza di Manhattan come suggerito da Gärdenfors. I pesi assegnati alle dimensioni tengono contro del contesto, perciò la distanza Euclidea pesata dist E è calcolata come segue [4]: dist E (p 1, p 2, k) = N w i (p 1,i p 2,i ) 2 dove i spazia su tutte le n dimensioni del dominio, k è il contesto e w i è il peso associato alla i-esima dimensione. I punti vengono rappresentati come vettori nello spazio, con tutte le dimensioni necessarie per rappresentare la caratteristica, così un naturale metodo di calcolarne la similarità è il coseno di similarità, ossia il coseno dell angolo compreso fra i due vettori che identificano i punti: due vettori con stessa direzione e stesso verso hanno coseno di similarità 1 e due vettori ortogonali hanno coseno di similarità 0. In questo contesto quindi la distanza d fra due individui i a e i b è calcolata con la formula di Manhattan arricchita da informazioni sul contesto che identifica i pesi associati ai domini e da un fattore di correzione per bilanciare il calcolo sulla base del numero di dimensioni dei domini: d(i a, i b, K) = m w j j=1 i=1 D j dist E (p j (i a ), p j (i b ), k j ) (1.1) dove K è il contesto generale che contiene i pesi w j e il contesto specifico k j,e D j è il numero di dimensioni del j-esimo domino. Gli spazi concettuali quindi forniscono un utile strumento di rappresentazione della conoscenza prototipica, e nella maggior parte dei casi col minimo sforzo di rappresentazione in quanto, come visto, la similarità viene naturalmente dal metodo geometrico di rappresentazione. La teoria degli spazi concettuali si sposa molto bene con la teoria dei prototipi di Rosch [8] secondo la quale la mente umana classifica i concetti in base alla somiglianza con dei prototipi delle varie classi. Un prototipo è quindi un elemento che maggiormente rappresenta la classe. Quanto il prototipo sia rappresentativo dipende però anche da quanto lo stesso sia familiare all uomo e dai tratti in comunque che questo ha con gli altri elementi, ad esempio la categoria degli uccelli

15 1.3. Spazi concettuali 13 sarà rappresentata molto meglio da un pettirosso che non da un pinguino.

16 Capitolo 2 Il sistema Il sistema preso come modello di riferimento nel corso di questa lavoro è un sistema ibrido di rappresentazione della conoscenza il cui obiettivo è quello di estendere la rappresentazione ed il reasoning classico delle ontologie con l informazione prototipica. L idea che sta alla base dello sviluppo del sistema, come descritto in [5], è una combinazione della teoria dei prototipi e di quella che in psicologia prende il nome di dual process theory, una teoria secondo la quale esistono due tipi di sistemi cognitivi: il primo tipo effettua un ragionamento veloce ed approssimato sulla base dell informazione prototipica, il secondo tipo effettua un ragionamento complesso, lento e non utilizza informazione prototipica, i due processi interagiscono fra loro tanto che il processo del primo tipo viene eseguito prima ed il risultato è raffinato da processi del secondo tipo. L idea di questa teoria ha permesso lo sviluppo del sistema, che, come mostrato in Figura 2.1, è formato da due componenti: Sistema1 (S1): si tratta di un sistema basato sull informazione prototipica, secondo la teoria di cui sopra si tratta di un sistema del primo tipo, sfrutta gli spazi concettuali per la rappresentazione di conoscenza, in particolare viene effettuato un reasoning non classico e gli elementi vengono classificati grazie al concetto di distanza come espresso nella formula 1.1; Sistema2 (S2): si tratta di un sistema basato su ontologie, sulla rappresentazione di conoscenza classica basata su description logics, in cui vengono specificate tutte le condizioni necessarie e/o sufficienti per la definizione

17 a more vivid way than its elements taken in isolation (that is, black and stripes ), and its visual load is expected to still grow if we add a coordinated term, like in with yellow and black stripes. We then introduced a parameter x to emphasize the contribution of the aforementioned features in case the corresponding terms are linked in the parse tree by a modifier/argument relation (denoted as mod and arg in Equation 3). ( x VL(c i ) if 9 c j s.t. mod(c i,c j ) _ arg(c i,c j ) VL(c i )= VL(c i ) otherwise. (3) In the experimentation x was set to 1.2. dei concetti, secondo la teoria S2 è un sistema del secondo tipo, basato su ragionamento ed inferenze complesse ma formali. The stimuli in the dataset are pairs consisting of a description d and a target T (st = hd,t i), such as 15 Input: description from stimulus inputto description d target T z } { z } { The big carnivore with yellow and black stripes is the... tiger. {z } stimulus st sentence parsing word sense disambiguation Information Extraction producesasoutput internal representation inputtokbsystem System The visual load associated to st components given the weighting scheme ~w is then computed as follows: Hybrid Knowledge Base: concept Tiger VL(d,~w)= Â c2d VL(c) (4) VL(T,~w)= VL(T ). (5) color: yellow Kingdom: habitat: forest Class: whiskers: yes Order: stripes: yes Genus:... Species: Animalia Mammalia Carnivora Panthera P. tigris System 1 System 2 accessto output conceptual space representation ontological KB accessto concept target Figura 2.1: Pipeline del sistema. La normale esecuzione del sistema è quindi formata da una serie di passi: viene, prima di tutto, mandata in input una descrizione testuale di un concetto, nella figura Il grande carnivoro con strisce gialle e nere da questa descrizione vengono estratte le informazioni necessarie ad individuare i concetti e vengono, appunto, tradotti in una rappresentazione interna che viene inviata ad S1, il primo sistema effettua l inferenza su spazi concettuali e fornisce un output che viene passato ad S2, il secondo sistema effettua la sua inferenza su basi di conoscenza classiche per verificare che il risultato sia consistente e manda in output il risultato, se S2 non trova nulla viene rilevata un inconsistenza. Il lavoro svolto per questa tesi si colloca nella sezione riguardante il formato interno, come mostrato in Figura 2.2:

18 2.1. Il formato interno 16 Figura 2.2: Lavoro svolto nella tesi. in particolare il lavoro svolto riguarda appunto la conversione dal formato interno ad una codifica standard RDF ed in seguito lo sviluppo di un tool per l annotazione di prototipi e la modifica dello schema dei dati. 2.1 Il formato interno Il formato che viene utilizzato internamente dal sistema è una codifica XML, in particolare ogni concetto viene rappresentato da un complextype chiamato object. Ognuno di questi prototipi viene descritto da quattro caratteristiche: vengono prima di tutto specificate una classe ed una famiglia dell oggetto, nella fattispecie classe identifica il tipo più generico del prototipo mentre la famiglia è un secondo

19 2.1. Il formato interno 17 livello di classificazione. Un altra importante caratteristica che viene utilizzata per la descrizione di oggetti è la relazione con l uomo del prototipo stesso, in particolare vengono utilizzati tre parametri di classificazione: funzione, ossia la funzione che l oggetto tipicamente ha per l uomo, prodotto, indica sia la caratteristica di produrre elementi per l uomo che il fatto di essere un prodotto per lo stesso, ed infine, il terzo parametro è la simbologia, ossia ciò che il prototipo tipicamente simboleggia. L ultimo, e più importante, parametro di definizione degli oggetti è la descrizione generica del prototipo sia fisica che non, in particolare la descrizione è composta da sette domini: dimensioni: le dimensioni fisiche del prototipo vengono codificate secondo la classica rappresentazione euclidea a tre coordinate, x,y e z; colore: il colore del prototipo viene descritto secondo il modello L*a*b*, dove L* indica la luminosità del colore, a* rappresenta la tonalità di colore da verde a rosso mentre b* identifica la tonalità da blu a giallo. alimentazione: l alimentazione tipica viene descritta da ulteriori due parametri, ossia il tipo di alimentazione, ad esempio carnivoro o erbivoro, e voracità del prototipo, viene inoltre fornita la possibilità di specificare alimenti preferiti; posizione: indica la location in cui tipicamente si può trovare il prototipo, nel caso di animali assume il ruolo di habitat, essa viene descritta in termini di altezza sul livello del mare, umidità, temperatura, vegetazione e fascia oraria in cui tipicamente è attivo il prototipo; movimento: Il movimento tipico del prototipo è codificato mediante ulteriori due parametri, ossia il tipo di movimento e la velocità dello stesso; sottoparte: indica le ulteriori parti che compongono l oggetto, esse vengono caratterizzate da ulteriori quattro parametri ossia il numero di sottoparti dello stesso tipo, la forma della parte, il colore e le dimensioni della parte, queste ultime due descritte come nei casi precedenti;

20 2.2. Traduzione da XML a RDF 18 superclasse: indica il concetto di cui il prototipo in esame è parte, la superclasse può essere specificata in tutti i dettagli come nel caso della sottoparte. In sostanza la rappresentazione di una caratteristica descrittiva ha due insiemi, ossia tale parametro ha un attributo, type, che ne identifica il dominio che a sua volta è formato da elementi semplici che lo compongono, ognuno di essi ha una dimensione, ossia delle restrizioni che vincolano il valore di tale elemento. Un esempio semplificato di un prototipo, nella fattispecie il leone, è il seguente: <o b j e c t name= l i o n > <g e n e r i c P h y s i c a l D e s c r i p t i o n> <f e e d i n g> <foodtype>5</ foodtype> <foodquantity>100</ foodquantity> </ f e e d i n g> </ g e n e r i c P h y s i c a l D e s c r i p t i o n> <manrelationship> <symbol id= >s t r e n g t h</symbol> </ manrelationship> </ o b j e c t> 2.2 Traduzione da XML a RDF L idea che sta alla base di questa traduzione è, appunto, quella di ottenere una base di conoscenza in un formato standard, in modo da rendere possibile il collegamento e l integrazione con il Web. La traduzione che ho fatto viene codificata rispettando i canoni definiti dal formato interno, perciò, così come in XML, anche per l RDF ogni oggetto viene descritto dalle stesse proprietà definite dalla notazione interna, nello specifico, ognuno di essi è descritto da quattro predicati: 1. hasclass: indica la classificazione più generica e di più alto livello, è definito su risorse di tipo objecttype e avente range un enumerazione di stringhe, ossia le possibili classi per un oggetto; 2. hasfamily: indica la classificazione di secondo livello, più specifica rispetto alla classe, definito anch esso su objecttype e avente come range un enumerazione di stringhe che da un elenco di famiglie attualmente disponibili;

21 2.2. Traduzione da XML a RDF hasgenericphysicaldescription: indica la descrizione fisica, ed informazioni strettamente correlate, dell oggetto, viene definita come proprietà su object- Type e avente come range una risorse che descrive tale descrizione con gli stessi canoni del formato interno; 4. hasmanrelationship: indica la relazione che l oggetto ha con l uomo, anch essa definita come proprietà su objecttype e avente range una risorsa che descrive tale relazione con i canoni della rappresentazione interna. Ognuna delle proprietà precedenti è quindi definita per objecttype e ha come range una risorsa specifica che ne definisce dettagliatamente il dominio della caratteristica, in sostanza si segue quasi sempre uno schema preciso in cui si passa da una caratteristica di descrizione a definirne il dominio con gli elementi che lo compongono, per poi passare alla definizione dettagliata dei vincoli dei singoli elementi, le dimensioni del dominio, in particolare, la risorsa puntata dal secondo predicato è chiamata genericphysicaldescription, ed è un elemento su cui vengono definite sette proprietà: hassize, hascolor, haslocation, hasfeeding, haslocomotion, ispartof e haspartconcept, ognuna di esse ha come dominio genericphysicaldescription e come range una risorsa che definisce gli elementi del dominio, infatti: hassize: punta a sizedomain su cui sono definite le proprietà hasx, hasy, hasz, hassizeshape, ognuna di esse ha appunto come dominio sizedomain e come valore una risorsa che definisce gli effettivi vincoli degli elementi del dominio, in particolare hasx, hasy e hasz hanno la risorsa decimalsizedimension come valore, tale oggetto è un tipo di dato che definisce il fatto che x,y e z non possano essere valori negativi; hascolor: punta a colordomain su cui sono definite le proprietà hasl, hasa e hasb, ognuna di esse ha come dominio colordomain e come valore una risorsa che definisce gli effettivi vincoli degli elementi del dominio, in particolare hasa e hasb hanno come valore, rispettivamente, acolordimension e bcolordimension, entrambi tipi di dato che vincolano il valore di a e b tra -127 e 128, mentre hasl ha lightnesscolordimension come range e vincola il valore di L ad un intero compreso fra 0 e 100;

22 2.2. Traduzione da XML a RDF 20 haslocation: punta a locationdomain su cui sono definite le proprietà hasaltitude, hastemperature, hasvegetation, hashumdity, hastime ognuna di esse ha come dominio locationdomain e come valore una risorsa che definisce gli effettivi vincoli degli elementi del dominio, in particolare hasaltitude ha come range altitudelocationdimension che vincola il valore dell altezza fra e 8848, hastemperature ha come range temperaturelocationdimension che vincola il valore della temperatura tra -10 e 60, hasvegetation ha come range vegetationlocationdimension che vincola il valore tra 0 e 100, hashumidity ha come range humiditylocationdimension che vincola il valore tra 0 e 100 ed infine hastime ha come range timelocationdimension che vincola il valore tra 1 e 5; hasfeeding: punta a feedingdomain su cui sono definite le proprietà hasfood- Type e hasfoodquantity, ognuna di esse ha come dominio feedingdomain e come valore una risorsa che definisce gli effettivi vincoli degli elementi del dominio, in particolare hasfoodtype ha come range foodtypefeedingdimension che vincola il valore tra 1 e 5, mentre hasfoodquantity ha come range foodquantityfeedingdimension che vincola il valore tra 0 e 100; haslocomotion: punta a locomotiomdomain su cui sono definite le proprietà hasspeed e hasmovement, ognuna di esse ha come dominio locomotiomdomain e come valore una risorsa che definisce gli effettivi vincoli degli elementi del dominio, in particolare hasspeed ha come range speedlocomotiondimension che vincola il valore in modo che sia maggiore di 0, mentre hasmovement ha come range movementlocomotiondimension che vincola il valore tra 1 e 7; haspartconcept: punta a partconcept su cui sono definite le proprietà hasnumber, haspartname, haspartshape, haspartsize e haspartcolor, ognuna di esse ha come dominio partconcept e come valore una risorsa che definisce gli effettivi vincoli degli elementi del dominio, in particolare hasnumber ha come valore un tipo di dato primitivo che vincola i valori in modo da renderli maggiori di 0, ha come range nonnegativeinteger, cioè impone il vincolo che il valore sia maggiore di 0, haspartname, haspartshape hanno come valore

23 2.2. Traduzione da XML a RDF 21 un tipo di dato primitivo che rappresenta le stringhe mentre haspartsize e haspartcolor hanno rispettivamente come range sizedomain e colordomain; ispartof: come nel caso precedente punta a partconcept su cui sono definite le proprietà hasnumber, haspartname, haspartshape, haspartsize e haspartcolor; ispartof ha come dominio genericphysicaldescription e sostanzialmente viene impiegata per specificare la superclasse del prototipo considerato, nello specifico viene definito un altro oggetto di cui il prototipo in esame è parte, come ad esempio nel caso della ruota è possibile specificare che è parte di una macchina. Ogni prototipo è, in realtà, un istanza della classe object cioè una classe avente tipo objecttype, l idea è quindi di definire un tipo di dato generico come dominio delle proprietà di alto livello per poi definire una classe generica, avente tale tipo, in modo da rendere ogni prototipo un istanza della stessa. Ogni oggetto è quindi descritto fino ai minimi dettagli concessi dalla rappresentazione, ognuno di essi è identificato univocamente da una URI ed è quindi una risorsa. La conversione è stata fatta senza discostarsi da quanto specifica il formato interno in modo da poter passare da un formato all altro in maniera veloce e senza problemi, il mappaggio delle proprietà è stato fatto sostanzialmente uno a uno, ossia i predicati in RDF hanno una corrispondente controparte nel formato XML. Un importante nota va fatta su come vengono tradotte le dimensioni della codifica interna, in particolar modo le restrizioni, una rappresentazione del tipo di dato primitivo per la temperatura è il seguente: temperaturelocation a rdfs : Datatype ; rdfs : l a b e l temperaturelocation ; rdfs : subclassof xsd : i n t e g e r ; owl : ondatatype xsd : i n t e g e r ; owl : w i t h R e s t r i c t i o n s ( [ xsd : maxinclusive 60 ] [ xsd : m i n I n c l u s i v e 10 ] ). in particolare viene specificato che è un tipo di dato, sottoclasse del tipo integer e le restrizioni sono specificate come range del predicato withrestriction proveniente da OWL.

24 2.3. Tool di annotazione ed editor 22 Per quanto riguarda i prototipi, quindi, una rappresentazione semplificata dell oggetto ruota, in notazione N3, è la prototypes : <http : / /www. example. org domains : <http : / /www. example. org datatypes : <http : / /www. example. org objects : <http : / /www. example. org / pdesc :. prototypes : wheel a objects : object ; rdfs : l a b e l wheel ; objects : hasclass invention ; objects : h a s G e n e r i c P h y s i c a l D e s c r i p t i o n [ a pdesc ; domains : hascolor [ a domains : colordomain ; domains : hasa 0 ; domains : hasb 0 ; domains : hascolorname black ; domains : hasl 0 ] ; domains : h a s S i z e [ a domains : sizedomain ; domains : h a s S i z e I d ; domains : hassizename wheel ; domains : hassizeshape c i r c u l a r ; domains : hasx 9 0 ; domains : hasy 9 0 ; domains : hasz 5 0 ] ] ; objects : hasmanrelationship [ a domains : manrelationshipdomain ; domains : hasfunction t r a n s p o r t a t i o n ; domains : hassymbol invention ]. 2.3 Tool di annotazione ed editor L idea alla base del tool di annotazione è facilitare l inserimento di nuovi prototipi nella base di conoscenza, quindi il tool permette l annotazione di nuovi elementi nel formato interno, XML, fornendo un interfaccia minimale in cui sono richieste le informazioni da inserire come parte dell oggetto. In sostanza il tool che ho

25 2.3. Tool di annotazione ed editor 23 sviluppato ha sostanzialmente un esecuzione tipica, ovvero, si occupa, in primo luogo, di leggere lo schema del formato interno, in particolare l XML Schema, per popolare una struttura dati ad albero con gli elementi dello schema a partire dal tipo più generico di objecttype, una rappresentazione grafica semplificata del formato interno è la seguente: ObjectType Class Family GenericPhysicalDescription ManRelationship Size Color Location Locomotion Feeding PartConcept... X Y Z Shape X-Restriction Figura 2.3: Rappresentazione ridotta della struttura dati popolata. di fatto, quindi, il tool parsifica lo schema degli oggetti, la radice rappresenta il tipo più generico, a livello uno ci sono gli elementi che compongono tale tipo, ossia i parametri di classificazione con cui sono descritti gli oggetti, al secondo livello sono presenti i domini, ossia ogni elemento a profondità uno hanno come tipo un dominio, ogni nodo al livello due ha quindi una serie di elementi che lo compongono, sono appunto i nodi a livello tre. Esiste poi ancora un quarto livello in cui vengono memorizzate le restrizioni dei nodi a profondità tre, ossia, in figura, nel nodo denominato X Restriction è memorizzato il tipo di dato primitivo di X, e le restrizioni sul valore, ossia deve essere un numero maggiore di zero. Ogni nodo dell albero in Figura 2.3 ha in realtà la stessa struttura:

26 2.3. Tool di annotazione ed editor 24 public class Node { private S t r i n g name ; //Name o f element private S t r i n g type ; //Type o f element private S t r i n g xmltype ; //XML tag o f element private ArrayList<Node> c h i l d r e n ; // Successors private ArrayList<Node> a t t r i b u t e s ; // A t t r i b u t e s o f element private S t r i n g min, max ; } oggetto in cui i campi name e type identificano nome e tipo dell elemento, xmltype identifica il tag XML relativo all elemento, children rappresenta la lista di oggetti che compongono l elemento mentre attributes è la lista di attributi dell elemento, min e max assumono un duplice significato: nel caso in cui l elemento in questione sia un complextype assume il significato di min/maxoccurs, ossia rappresenta una restrizione sul numero di occorrenze, mentre nel caso di un simpletype prende il significato di min/maxincusive quindi rappresenta una restrizione sul valore. La parsificazione dello schema si basa, tuttavia, su un assunzione molto forte, lo schema deve seguire il seguente modello: Element SimpleType ComplexType Restriction Sequence simplecontent Enumeration Min/Max inclusive Elements Extension Figura 2.4: Rappresentazione dello schema compreso dal tool.

27 2.4. Creazione di triple store 25 ossia gli elementi XML devono essere organizzati così come descritto in Figura 2.4, il tool non è in grado di comprendere un albero differente. Di fatto, quindi, il tool genera a run time un interfaccia basata sull albero parsificato disponendo dei bottoni per impostare le caratteristiche desiderate al prototipo. Oltre all annotazione di nuovi elementi il tool permette di modificare lo schema dei prototipi, in particolare nell interfaccia è previsto un bottone per l aggiunta di un nuovo parametro di classificazione per objecttype, il tool rende quindi possibile la definizione di nuovi domini e nuove dimensioni da associare ai nuovi parametri inseriti, l aggiunta di tali caratteristiche rispetta comunque lo schema in Figura 2.4, in particolare l interfaccia fornisce il supporto necessario per rispettare lo stesso. Il tool è quindi uno strumento utile sia all annotazione di nuovi prototipi che alla modifica dello schema con aggiunta di nuovi parametri di descrizione, questo permette l estensione dell insieme degli elementi rappresentabili dando la possibilità di aggiungere caratteristiche descrittive ad hoc. 2.4 Creazione di triple store Uno dei principali motivi per cui è stato scelto RDF come linguaggio di traduzione è che viene adottato come standard per la rappresentazione di Linked Data dal W3C, in particolare è una delle colonne portanti del progetto Semantic Web, l idea di base è quella di creare una rete di metadati facilmente navigabile da umani e macchine. Il modo più semplice di pubblicare Linked Data è quello di definire il proprio bubble di triple RDF, l idea è quella di creare una sorta di database in cui tali triple sono memorizzate, questo viene detto triple store, e di connetterlo ad altri bubble già presenti, primo fra tutti DBPedia 1 ; proprio a questo scopo nel formato RDF vengono aggiunti due predicati che collegano i nostri dati a DBPedia, ad esempio per il concetto di ruota le proprietà sono le seguenti: r d f s : seealso http : / / dbpedia. org / r e s o u r c e /Wheel ; owl : e q u i v a l e n t C l a s s http : / / dbpedia. org / r e s o u r c e /Wheel ; l obiettivo, oltre a voler ottenere informazioni strutturate e collegate, è quello di rendere i propri dati pubblicamente accessibili ed interrogabili via opportu- 1

28 2.4. Creazione di triple store 26 no SPARQL endpoint. La differenza fondamentale tra il nostro triple store e gli altri sta nell informazione memorizzata, nella fattispecie il nostro triple store memorizza, appunto, conoscenza prototipica codificata sotto forma di RDF, cosa che negli altri triple store non viene fatta. Per la costruzione dell endpoint sono disponibili varie alternative software, abbiamo deciso di appoggiarci a Open- Link Virtuoso 2, fornisce apposita interfaccia per l interrogazione e permette la definizione di prefissi senza doverli definire ogni volta nelle query. L endpoint è stato installato su una macchina del dipartimento raggiungibile all indirizzo tramite questa interfaccia è, quindi, possibile interrogare il set di prototipi presenti. Un esempio di query strutturata per il nostro triple store è il seguente: PREFIX o b j e c t s : <http : / /www. example. org / o b j e c t s#> PREFIX domains : <http : / /www. example. org /domains#> PREFIX xsd : <http : / /www. w3. org /2001/XMLSchema#> SELECT? animal WHERE {? animal o b j e c t s : h a s G e n e r i c P h y s i c a l D e s c r i p t i o n [ domains : h a s S i z e [ domains : hasx [ domains : hasdecimalsizevalue?x ] ] ; domains : haspartconcept [ domains : haspartname hump ; domains : hasnumber? n ] ; domains : haslocation [ domains : haslocationname d e s e r t ] ; ] ; o b j e c t s : hasclass [ domains : hasclassname animal ]. FILTER ( xsd : decimal (? n ) = 1 xsd : decimal (? n ) = 2) FILTER ( xsd : decimal (? x ) >= 80) } l interrogazione traduce la domanda Il grande animale che vive nel deserto ed ha una o due gobbe. 2

29 Capitolo 3 La sperimentazione Una volta completata la traduzione mi sono occupato di testare lo schema così ottenuto verificando che la potenza espressiva della nuova rappresentazione sia quantomeno equivalente a quella del formato interno, nella fattispecie il metodo sperimentale più diretto è quello di provare a tradurre le descrizioni testuali, utilizzate per testare il sistema, nella nuova codifica standard. Un altro importante punto su cui si è focalizzato il mio lavoro è stato quello di effettuare un confronto fra il nostro triple store e quello di DBPedia, ciò che si vuole dimostrare è che un bubble di dominio proprio grazie alla sua specializzazione ha la possibilità di dare una descrizione più precisa e strutturata di alcuni concetti, nel caso specifico animali, piante ed artefatti. Chiaramente per quanto si tratti di domini ristretti confrontati a quelli di DBPedia ha senso soffermarsi sul paragone in quanto mette in evidenza alcuni problemi di DBPedia che il nostro triple store non sembra avere. 3.1 Estrazione query dalle descrizioni testuali Una parte piuttosto importante in queste fasi del progetto è stata la verifica che il triple store, ottenuto dalla conversione da XML a RDF, avesse mantenuto la capacità espressiva del formato interno, ovvero è stato necessario verificare che le descrizioni testuali utilizzate per testare il sistema fossero ancora utilizzabili per il triple store, e che le risposte fornite fossero esattamente quelle attese. Inoltre è