7. OSSA. Alessio Maculani

Transcript

1 7. OSSA ossa è il modulo software realizzato in questo stage di laurea. Esso aggiunge all applicazione composta da MadCow, VisualOntoGraph e FormalAnnotation, gli strumenti necessari all utente annotatore per realizzare annotazioni strutturate. Il caso più semplice consiste nell associare ad un documento un concetto appartenente ad un ontologia di riferimento. Questo caso corrisponde all annotazione semplice ed è realizzabile tramite il modulo FormalAnnotation. Il caso più complesso consiste invece nell associare ad un documento un espressione strutturata creata ad hoc su concetti appartenenti ad un ontologia di riferimento; essa rappresenta un concetto derivabile dall ontologia di riferimento ed è possibile realizzarla tramite il modulo ossa. Nello sviluppo di ossa la scelta sui modi di generare concetti strutturati è stata influenzata da quella effettuata per il sistema A* [Osi02]. Vediamo in dettaglio come in ossa si possono generare i concetti: generalizzazione di concetti dell ontologia di riferimento; la generalizzazione si può realizzare in diversi modi: - unione di concetti dell ontologia di riferimento; un concetto definito unione di due concetti eredità le proprietà di entrambi e i vincoli imposti sui due concetti sono rilassati; vedi esempio nelle figure 42 e 43 (rilassamento vincolo sul range), e nelle figure 44 e 45 (rilassamento vincolo di cardinalità); - rilascio di un vincolo di cardinalità (su una proprietà) imposto per un concetto nell ontologia di riferimento: è realizzabile quando nell ontologia di riferimento esistono concetti la cui definizione impone un vincolo di cardinalità su una proprietà p, il nuovo concetto che si definisce generalizza uno di questi concetti rilasciando il vincolo di cardinalità su p (vedi esempio nelle figure 44 e 45); 73

2 - rilascio di un vincolo sul range (di una proprietà) imposto per un concetto nell ontologia di riferimento: è realizzabile quando nell ontologia di riferimento esistono concetti la cui definizione impone un vincolo sul range di una proprietà p, il nuovo concetto che si definisce generalizza uno di questi concetti rilasciando il vincolo sul range di p (vedi esempio nelle figure 42 e 43); specializzazione di concetti dell ontologia di riferimento; la specializzazione si può realizzare in diversi modi: - intersezione di concetti dell ontologia di riferimento: un concetto definito intersezione di due concetti eredita le proprietà di entrambi e i vincoli imposti su entrambi i concetti devono essere verificati; vedi esempio nelle figure 46 e 47 (rafforzamento vincolo sul range), e nelle figure 48 e 49 (rafforzamento vincolo di cardinalità); - aggiunta di un vincolo di cardinalità (su una proprietà) nonimposto per un concetto nell ontologia di riferimento: è realizzabile quando nell ontologia di riferimento esistono concetti la cui definizione non impone vincoli di cardinalità su una proprietà p, il nuovo concetto che si definisce specializza uno di questi concetti impono un vincolo di cardinalità su p; (vedi esempio nelle figure 48 e 49); - aggiunta di un vincolo sul range (di una proprietà) non-imposto per un concetto nell ontologia di riferimento: è realizzabile quando nell ontologia di riferimento esistono concetti la cui definizione non impone vincoli sul range di una proprietà p, il nuovo concetto che si definisce specializza uno di questi concetti impono un vincolo sul range di p; (vedi esempio nelle figure 46 e 47); restrizione su una proprietà dell ontologia di riferimento: si definisce un concetto impono un vincolo su una proprietà dell ontologia di riferimento (corrisponde a definire un concetto come specializzazione del concetto più generale owl:thing); la restrizione sulle proprietà può essere realizzata in due modi: vincolando la cardinalità di una proprietà p (corrisponde a dichiarare la classe di individui su cui p assume un numero di 74

3 valori che verifica il vincolo di cardinalità esplicitato nella definizione), vedi esempio in figura 50; vincolando il range di una proprietà p (corrisponde a dichiarare la classe di individui su cui p ha valori nell insieme esplicitato come range nella definizione), vedi esempio in figura 51; combinazione dei modi precedenti (vedi esempio in figura 52). 75

4 Maestro Ontologia di Riferimento la proprietà insegnapresso su istanze di Maestro restituisce istanze di Scuola Professore Ontologia di Riferimento la proprietà insegnapresso su istanze di Professore restituisce istanze di Università Insegnante Ontologia di Riferimento viene allora definito come Maestro Professore la proprietà insegnapresso su istanze di Insegnante restituisce istanze di Scuola Università In DL equivale a: Insegnante = Maestro Professore In OWL equivale a: <owl:class rdf:id="maestro"> <owl:restriction> <owl:onproperty rdf:resource="#insegnapresso" /> <owl:allvaluesfrom> <owl:class rdf:resource="#scuola" /> </owl:allvaluesfrom> </owl:restriction> </owl:class> <owl:class rdf:id="professore"> <owl:restriction> <owl:onproperty rdf:resource="#insegnapresso" /> <owl:allvaluesfrom> <owl:class rdf:resource="#università" /> </owl:allvaluesfrom> </owl:restriction> </owl:class> <owl:class rdf:id="insegnante"> <owl:unionof rdf:parsetype="collection"> <owl:class rdf:resource="#professore" /> <owl:class rdf:resource="#maestro" /> </owl:unionof> </owl:class> Fig. 42 esempio di generalizzazione tramite unione (rilassamento vincolo sul range) Persona Università Ipotesi Un insegnante può insegnare solo: - in una o più scuole; - in una o più università; - in una o più scuole e in una o più università. Riferimento: = persona che insegna in una o più università = persona che insegna in una o più scuole Scuola = persona che insegna in una o più università e in una o più scuole = persona che non insegna = proprietà insegnapresso = classe degli Insegnanti Fig. 43 diagramma di Venn dell esempio di figura 42 76

5 MultiCorrentista Ontologia di Riferimento la proprietà titolaredi su istanze di MultiCorrentista restituisce > 1 istanze di ContoCorrente MonoCorrentista Ontologia di Riferimento la proprietà titolaredi su istanze di MonoCorrentista restituisce esattamente 1 istanza di ContoCorrente Correntista Ontologia di Riferimento viene allora definito come MultiCorrentista MonoCorrentista la proprietà titolaredi su istanze di Correntista restituisce > 0 istanze di ContoCorrente Ipotesi: la proprietà titolaredi Ontologia di Riferimento il dominio è definito sulla classe Persona il range è definito sulla classe ContoCorrente In DL equivale a: Correntista = MultiCorrentista MonoCorrentista In OWL equivale a: <owl:class rdf:id="multicorrentista"> <owl:restriction> <owl:onproperty rdf:resource="#titolaredi" /> <owl:mincardinality rdf:datatype="&xsd;nonnegativeinteger"> 2 </owl:mincardinality> </owl:restriction> </owl:class> <owl:class rdf:id="monocorrentista"> <owl:restriction> <owl:onproperty rdf:resource="#titolaredi" /> <owl:cardinality rdf:datatype="&xsd;nonnegativeinteger"> 1 </owl:cardinality> </owl:restriction> </owl:class> <owl:class rdf:id="correntista"> <owl:unionof rdf:parsetype="collection"> <owl:class rdf:resource="#multicorrentista" /> <owl:class rdf:resource="#monocorrentista" /> </owl:unionof> </owl:class> Fig. 44 esempio di generalizzazione tramite unione (rilassamento vincolo di cardinalità) Persona ContoCorrente Riferimento: = persona che è titolare di almeno 2 ContoCorrenti = persona che è titolare di esattamente 1 ContoCorrente = persona che non è titolare di alcun ContoCorrente = proprietà titolaredi = classe dei Correntisti Fig. 45 diagramma di Venn dell esempio di figura 44 77

6 ProprietarioBeniImmobili Ontologia di Riferimento la proprietà proprietariodi su istanze di ProprietarioBeniImmobili restituisce almeno un istanza di BeniImmobili ProprietarioBeniMobili Ontologia di Riferimento la proprietà proprietariodi su istanze di ProprietarioBeniMobili restituisce almeno un istanza di BeniMobili ProprietarioBeniImmobiliEMobili Ontologia di Riferimento viene allora definito come ProprietarioBeniImmobili ProprietarioBeniMobili la proprietà proprietariodi su istanze di ProprietarioBeniImmobiliEMobili restituisce almeno un istanza di BeniImmobili e almeno un istanza di BeniMobili In DL equivale a: ProprietarioBeniImmobiliEMobili = ProprietarioBeniImmobili ProprietarioBeniMobili In OWL equivale a: <owl:class rdf:id="proprietariobeniimmobili"> <owl:restriction> <owl:onproperty rdf:resource="#proprietariodi" /> <owl:somevaluesfrom> <owl:class rdf:resource="#beniimmobili" /> </owl:somevaluesfrom> </owl:restriction> </owl:class> <owl:class rdf:id="proprietariobenimobili"> <owl:restriction> <owl:onproperty rdf:resource="#proprietariodi" /> <owl:somevaluesfrom> <owl:class rdf:resource="#benimobili" /> </owl:somevaluesfrom> </owl:restriction> </owl:class> <owl:class rdf:id="proprietariobeniimmobiliemobili"> <owl:intersectionof rdf:parsetype="collection"> <owl:class rdf:resource="#proprietariobeniimmobili" /> <owl:class rdf:resource="#proprietariobenimobili" /> </owl:intersectionof> </owl:class> Fig. 46 esempio di specializzazione tramite intersezione (rafforzamento vincolo sul range) Persona BeniMobili Riferimento: = Persona che è proprietaria di uno o più BeniMobili BeniImmobili = Persona che è proprietaria di uno o più BeniImmobili = persona che è proprietaria di uno o più BeniImmobili e di uno o più BeniMobili = persona che non ha proprietà = proprietà proprietariodi = classe dei ProprietariBeniImmobiliEMobili Fig. 47 diagramma di Venn dell esempio di figura 46 78

7 PersonaConPiuDiUnaProprietà Ontologia di Riferimento la proprietà proprietariodi su istanze di PersonaConPiuDiUnaProprietà restituisce > 1 Oggetti PersonaConMenoDiTreProprietà Ontologia di Riferimento la proprietà proprietariodi su istanze di PersonaConMenoDiTreProprietà restituisce < 3 Oggetti PersonaConDueProprietà Ontologia di Riferimento viene allora definito come PersonaConPiuDiUnaProprietà PersonaConMenoDiTreProprietà la proprietà proprietariodi su istanze di PersonaConDueProprietà restituisce esattamente 2 Oggetti Ipotesi: la proprietà proprietariodi Ontologia di Riferimento il dominio è definito sulla classe Persona il range è definito sulla classe Oggetto In DL equivale a: PersonaConDueProprietà = PersonaConPiuDiUnaProprietà PersonaConMenoDiTreProprietà In OWL equivale a: <owl:class rdf:id="personaconpiudiunaproprietà"> <owl:restriction> <owl:onproperty rdf:resource="#proprietariodi" /> <owl:mincardinality rdf:datatype="&xsd;nonnegativeinteger"> 2 </owl:mincardinality> </owl:restriction> </owl:class> <owl:class rdf:id="personaconmenoditreproprietà"> <owl:restriction> <owl:onproperty rdf:resource="#proprietariodi" /> <owl:maxcardinality rdf:datatype="&xsd;nonnegativeinteger"> 2 </owl:maxcardinality> </owl:restriction> </owl:class> <owl:class rdf:id="personacondueproprietà"> <owl:intersectionof rdf:parsetype="collection"> <owl:class rdf:resource="#personaconpiudiunaproprietà" /> <owl:class rdf:resource="#personaconmenoditreproprietà" /> </owl:intersectionof> </owl:class> Fig. 48 esempio di specializzazione tramite intersezione (rafforzamento vincolo di cardinalità) Persona Oggetto Riferimento: = Persona che è proprietaria di più di 2 Oggetti = Persona che è proprietaria di 1 Oggetto = Persona che è proprietaria di 2 Oggetti + = classe delle PersoneConPiuDiUnaProprietà + = classe delle PersoneConMenoDiTreProprietà = Persona che non ha proprietaria = proprietà proprietariodi = classe delle PersoneConDueProprietatà Fig. 49 digramma di Venn dell esempio di figura 48 79

8 ProprietarioBeniImmobili Ontologia di Riferimento viene allora definito come la classe di individui su cui la proprietà proprietariodi restituisce almeno un istanza di BeniImmobili (suppono che proprietariodi,beniimmobili Ontologia di Riferimento) In DL equivale a: ProprietarioBeniImmobili = ( proprietariodi. BeniImmobili ) In OWL equivale a: <owl:class rdf:id="proprietariobeniimmobili"> <owl:restriction> <owl:onproperty rdf:resource="#proprietariodi" /> <owl:somevaluesfrom> <owl:class rdf:resource="#beniimmobili" /> </owl:somevaluesfrom> </owl:restriction> </owl:class> Fig. 50 definizione di un concetto vincolando il range di una proprietà MultiProprietario Ontologia di Riferimento viene allora definito come la classe di individui su cui la proprietà proprietariodi restituisce >1 Oggetti Ipotesi: la proprietà proprietariodi Ontologia di Riferimento il dominio è definito sulla classe Persona il range è definito sulla classe Oggetto In DL equivale a: MultiProprietario = ( 2 proprietariodi ) In OWL equivale a: <owl:class rdf:id="multiproprietario"> <owl:restriction> <owl:onproperty rdf:resource="#proprietariodi" /> <owl:mincardinality rdf:datatype="&xsd;nonnegativeinteger"> 2 </owl:mincardinality> </owl:restriction> </owl:class> Fig. 51 definizione di un concetto vincolando la cardinalità di una proprietà MultiProprietarioDiSoliBeniImmobili Ontologia di Riferimento viene allora definito come la classe di individui su cui la proprietà proprietariodi restituisce >1 istanze di BeniImmobili e 0 istanze di BeniMobili (suppono che BeniImmobili,BeniMobili Ontologia di Riferimento) Ipotesi: la proprietà proprietariodi Ontologia di Riferimento il dominio è definito sulla classe Persona il range è definito sulla classe Oggetto In DL equivale a: MultiProprietarioDiSoliBeniImmobili = ( ( 2 proprietariodi ) ( proprietariodi. BeniImmobili ) ) In OWL equivale a: <owl:class rdf:id="multiproprietariobeniimmobili "> <owl:intersectionof rdf:parsetype="collection"> <owl:restriction> <owl:onproperty rdf:resource="#proprietariodi" /> <owl:mincardinality rdf:datatype="&xsd;nonnegativeinteger"> 2 </owl:mincardinality> </owl:restriction> <owl:restriction> <owl:onproperty rdf:resource="#proprietariodi" /> <owl:allvaluesfrom> <owl:class rdf:resource="#beniimmobili" /> </owl:allvaluesfrom> </owl:restriction> </owl:intersectionof> </owl:class> Fig. 52 definizione di un concetto combinando i modi precedenti 80

9 7.1 Linguaggio L per costruire le Annotazioni In questo paragrafo è utilizzata la terminologia definita nel capitolo 4. Il linguaggio che è stato scelto per definire le espressioni di annotazione che si possono costruire con il modulo OSSA è OWL DL (-) (vedi figura 53), il quale utilizza un sottoinsieme dei costruttori OWL. Costruttore OWL Sintassi DL Esempio intersectionof A 1 A 2 Human Male unionof A 1 A 2 Abstract Physical allvaluesfrom R. A haschild.doctor somevaluesfrom R. A haschild.doctor maxcardinality n R 2 haschild mincardinality n R 2 haschild Cardinality = n R = 2 haschild Fig. 53 costruttori di OWL DL (-) La scelta di OWL DL (-) è stata influenzata dal fatto che le espressioni che costruisce un utente annotatore tramite il modulo OSSA dovrebbero essere verificate semanticamente sull ontologia di riferimento tramite l utilizzo di un reasoner. La verifica semantica impedisce di memorizzare sul server espressioni di annotazione incoerenti con l ontologia (ad esempio l espressione OggettiBianchi OggettiNeri è incoerente con un ontologia in cui la classe OggettiBianchi è definita disgiunta dalle classe OggettiNeri perché risulta una classe vuota). È vero, come detto in precedenza, che per OWL DL (corrispondente a DL SHOIN) il problema di reasoning è decidibile, ma in realtà molti dei reasoner esistenti possono gestire solo un sottoinsieme di OWL DL. Racer [HM01] ad esempio, non gestisce la possibilità di definire una classe attraverso l enumerazione delle sue istanze e consente la 81

10 restrizione di cardinalità solo su ruoli semplici 47. Visto che in ossa è previsto tra gli sviluppi futuri l utilizzo di un reasoner esterno scelto tra quelli già esistenti si è scelto di escludere costrutti come oneof e not 48 per evitare di scegliere un linguaggio non gestito da diversi reasoner. 47 Ruolo semplice: proprietà che non è transitiva e che non ha sottoproprietà transitive. 48 not: costruttore utile alla definizione del complemento di una classe. 82

11 7.2 CFG G che genera L In questo paragrafo viene descritta in dettaglio la Context Free Grammar (CFG) che è stata utilizzata nello sviluppo di OSSA. Una definizione di CFG è riportata di seguito (vedi [Sip97]): Definizione una Context-Free Grammar è una 4-tupla (V, S, R, S), dove: 1. V è un insieme finito di variabili (o non-terminali), 2. Σ è un insieme finito, disgiunto da V, di terminali, 3. R è un insieme finito di regole, ogni regola associa ad una variabile una stringa di variabili e terminali, e 4. S V è la variabile iniziale. Le regole sono della forma A x, dove A V e x ( Σ V) *. A x è applicabile ad una stringa ω (Σ V) * se esistono due stringhe y,z (Σ V) * tali che ω = yaz. Il risultato dell applicazione di A x a ω è la stringa w = yxz. In tal caso si dice che la stringa w è derivata direttamente da ω nella grammatica G, in simboli ω G w. G è una relazione binaria su (Σ V) * ; la chiusura riflessiva e transitiva di G è solitamente indicata con. Un modo compatto quindi per esprimere che possiamo ottenere w da ω in zero o più passi applicando zero o più regole di una CFG G, è scrivere: * G w * ω. G L insieme di stringhe di terminali che si può generare da una CFG G è il linguaggio L(G). Allora possiamo scrivere: L(G) = { ω S * S * G ω }. Da questo punto in poi il linguaggio OWL DL (-) descritto nel paragrafo 7.1 sarà chiamato semplicemente L. Nel realizzare la grammatica per il linguaggio L sono state fatte le seguenti semplificazioni: 1) i costruttori DL e sono due operatori binari e in una CFG che genera L vanno considerati simboli terminali; in seguito si scriverà opbin per 83

12 intere indistintamente o ; in pratica è come se opbin fosse un non-terminale da cui è possibile produrre o, e noi lo trattassimo come se fosse un terminale; in altre parole conosciamo l esistenza della regola: opbin ma la omettiamo dall insieme R della grammatica e trattiamo opbin come tratteremmo un simbolo terminale per semplificare la trattazione (si noti che questa semplificazione non influenza i ragionamenti); 2) i costruttori DL e sono due quantificatori e in una CGF che genera L vanno considerati simboli terminali; analogamente alla prima considerazione, in seguito si scriverà quant per intere indistintamente o ; conosciamo l esistenza della regola: quant ma la omettiamo dall insieme R della grammatica e trattiamo quant come tratteremmo un simbolo terminale per semplificare la trattazione (si noti che questa semplificazione non influenza i ragionamenti); 3) i costruttori DL, e = servono a vincolare la cardinalità di una proprietà e in una CGF che genera L vanno considerati simboli terminali; analogamente alla prima considerazione, in seguito si scriverà card per intere indistintamente, o = ; conosciamo l esistenza della regola: card = ma la omettiamo dall insieme R della grammatica e trattiamo card come tratteremmo un simbolo terminale per semplificare la trattazione (si noti che questa semplificazione non influenza i ragionamenti); 4) per costruire espressioni di annotazione possono essere utilizzate le proprietà definite in un ontologia di riferimento; queste sono un numero finito n; siano proprietà 1, proprietà 2,, proprietà n le proprietà definite nell ontologia di riferimento, in una CGF che genera L queste vanno considerate simboli terminali; analogamente alla prima considerazione, in seguito si scriverà property per intere indistintamente proprietà 1, o proprietà 2,, o proprietà n ; conosciamo l esistenza della regola: property proprietà 1 proprietà 2 proprietà n 84

13 ma la omettiamo dall insieme R della grammatica e trattiamo property come tratteremmo un simbolo terminale per semplificare la trattazione (si noti che questa semplificazione non influenza i ragionamenti); 5) per costruire espressioni di annotazione possono essere utilizzate le classi definite in un ontologia di riferimento; queste sono un numero finito m; siano classe 1, classe 2,, classe m le classi definite nell ontologia di riferimento, in una CGF che genera L queste vanno considerate simboli terminali; analogamente alla prima considerazione, in seguito si scriverà class per intere indistintamente classe 1, o classe 2,, o classe m ; conosciamo l esistenza della regola: class classe 1 classe 2 classe m ma la omettiamo dall insieme R della grammatica e trattiamo class come tratteremmo un simbolo terminale per semplificare la trattazione (si noti che questa semplificazione non influenza i ragionamenti); 6) per vincolare la cardinalità di una proprietà si deve inserire un numero intero nell espressione di annotazione (ad esempio 3 haschild ); in una CGF che genera L i numeri interi (utili esclusivamente a questo scopo) vanno considerati simboli terminali; analogamente alla prima considerazione, in seguito si scriverà n per intere indistintamente 0, 1, 2, ; a n è associato il linguaggio regolare delle stringhe che rappresentano numeri interi, definito dall espressione regolare: 0+[1-9][0-9] * ; conosciamo l esistenza di regole che a partire dal non-terminale n generano il linguaggio degli interi appena definito ma omettiamo tali regole dall insieme R della grammatica e trattiamo n come tratteremmo un simbolo terminale per semplificare la trattazione (si noti che questa semplificazione non influenza i ragionamenti). Le sei semplificazioni sopra elencate sono riassunte nella tabella in figura

14 terminali semplificazione regola implicita, opbin opbin, quant quant,, = card card = proprietà 1, proprietà 2,, proprietà n property property proprietà 1 proprietà 2 proprietà n classe 1, classe 2,, classe m class class classe 1 classe 2 classe m 0, 1, 2, 3, 4, n n Fig. 54 semplificazioni sulla CFG sviluppata Ora che sono state definite le semplificazioni operate (figura 54) al linguaggio L (figura 53) contenente le espressioni di annotazione generabili con OSSA, si può definire una prima CFG G tale che L(G) = L. Si noti che in questa fase del progetto è stata adottata la grammatica sviluppata per il sistema A* in [Osi02]. G = (V, S, R, S ), dove: - V = { E, Q, F }; - S = { opbin, quant, card, property, class, n, (, ),. }; - R = { E E opbin Q Q, Q quant property. F F, F ( E ) class card n property }; - S = E ; G è una grammatica non ambigua (vedi [Fac03]) con ricorsioni sinistre (vedi nota 50 e [ASU88]); precisamente G ha una sola regola ricorsiva a sinistra: E E opbin Q. In fase progettuale si è deciso di realizzare per ossa un interfaccia che permetta di costruire tutte e sole le espressioni del linguaggio L(G). Per garantire che sia verificato questo vincolo non è sufficiente realizzare un interfaccia grafica con pulsanti per l inserimento nell espressione di tutti e soli i terminali della grammatica, è necessario anche effettuare una verifica sintattica dell espressione costruita, verificare cioè che esista una sequenza di regole di G che dal simbolo iniziale E * genera l espressione w costruita dall annotatore ( E G w ). La verifica sintattica è solitamente eseguita da un analizzatore sintattico, anche detto parser. Questo strumento è il cuore delle prime fasi di un compilatore (l analisi 86

15 sintattica è eseguita dal compilatore nella seconda fase della compilazione, quella cioè immediatamente successiva all analisi lessicale). Nel nostro caso il compito del parser è quello di analizzare la struttura di un espressione di annotazione (del codice di un programma nel caso del compilatore) e di verificare l esistenza di errori. Applicando le regole di una CFG al simbolo non-terminale più a sinistra delle forme sentenziali 49 si ottiene una derivazione sinistra. Data un espressione di annotazione, vogliamo un parser che ottenga la sua derivazione sinistra. Per far ciò possiamo utilizzare un parser top-down, un parser cioè che parte dalla radice dell albero di derivazione e cerca di ricostruire la crescita dell albero che porta alla sequenza di terminali della data espressione ricostruo una derivazione sinistra. Precedentemente è stato detto che la grammatica G ha regole ricorsive a sinistra; questo è un problema perché nessun parser top-down può gestirle. Visto però che in G c è una sola regola con ricorsioni a sinistra e questa è di tipo immediata 50, non è difficile scrivere una nuova grammatica G, equivalente a G, in cui la regola ricorsiva a sinistra è sostituita da altre non ricorsive a sinistra. Il processo eseguito per eliminare tale regola è il seguente (vedi [ASU88]): 1) separare la regola ricorsiva dall altra: E E opbin Q; E Q; 2) introdurre un nuovo non-terminale Z; 3) cambiare la regola non ricorsiva in: E Q Z; 4) rimuovere la regola ricorsiva e sostituirla con: Z e opbin Q Z Si noti che Z e è la regola nulla (e è il simbolo nullo) e serve a terminare la derivazione di un espressione. La CFG G che risulta dal processo appena descritto è la seguente. 49 Una forma sentenziale di una grammatica G è una qualunque sequenza di terminali e non-terminali che può occorrere in una derivazione in G; formalmente è una qualunque sequenza α tale che * G α ( V S ) * e S α. 50 Siano A,B simboli non-terminali e a,b simboli terminali, le regole con ricorsioni sinistre immediate sono del tipo { A Aa }, le regole con ricorsioni sinistre non immediate sono del tipo { A Ba, B Ab }; le regole del tipo { B abb } o { B ab } non sono ricorsive a sinistra. 87

16 G = (V, S, R, S ), dove: - V = { E, Q, F, Z }; - S = { opbin, quant, card, property, class, n, (, ),. }; - R = { E Q Z, Z e opbin Q Z, Q quant property. F F, F ( E ) class card n property }; - S = E. 88

17 7.3 Alcune definizioni sui parser La grammatica G del paragrafo 8.2 è non-ambigua e senza ricorsioni sinistre, il che ci permette di sviluppare per essa un parser top-down. Più precisamente per G può essere sviluppato un parser top-down predittivo. Questo tipo di parser viene utilizzato per grammatiche che hanno alcune parti destre di regole che cominciano con nonterminali, ha la capacità di guardare avanti nella grammatica in modo da prevedere quali terminali sono derivabili (mediante derivazioni sinistre) da ciascuno dei vari non-terminali. I parser predittivi per prevedere i terminali derivabili dai non-terminali in una CFG G utilizzano gli insiemi dati in output dalla funzione First che è definita nel modo seguente. First(α): input: α è una forma sentenziale generata da G; output: un insieme di terminali di G; si considerino tutte le sequenze derivabili in G da α mediante derivazioni sinistre; se α * β e β inizia con un terminale, allora quel terminale appartiene a First(α). G Tutti i parser che utilizzano gli insiemi First sono detti predittivi. La tecnica appena descritta non può essere utilizzata per grammatiche con regole nulle o tali che gli insiemi First di due diverse parole non sono disgiunti. Per gestire questi casi si utilizza in aggiunta a First una seconda funzione: Follow. Nel definirla assumiamo che ogni forma sentenziale ha appeso il carattere speciale $ come segno di demarcazione ( $ è appeso alla fine di ogni parola). Follow(A): input: A è un non-terminale di G; output: un insieme di terminali; Follow(A) è l insieme di tutti i terminali che possono venire subito dopo A in una forma sentenziale derivabile da G; se (in G) A può capitare alla fine, allora Follow(A) include $. 89

18 Un parser pre in input una stringa ω e una grammatica G, quindi cerca su G una derivazione che a partire dal simbolo iniziale S produca ω. Se il parser trova una tale derivazione, allora ω L(G); se non la trova, allora ω L(G). Parser predittivi che utilizzano in questo processo le funzioni First e Follow sono detti parser LL(1), grammatiche per cui questa tecnica può essere utilizzata sono dette grammatiche LL(1). In questa notazione la prima L sta per left ed indica che la scansione è da sinistra a destra, la seconda L sta per left ed indica che la derivazione è sinistra, (1) sta ad indicare che si guarda avanti di un carattere. Le grammatiche LL(1) assicurano che guardando un carattere in avanti il carattere in arrivo determina univocamente quale parte destra della regola scegliere. Formalmente una grammatica LL(1) è definita nel modo seguente. Una grammatica è LL(1) se per ogni coppia di regole A α β si ha: 1) (First(α) {e}) (First(β) {e}) = ; 2) se α è annullabile 51, allora First(β) Follow(A) =. 51 Un simbolo è annullabile se da esso è derivabile la stringa vuota e, oppure se è esso stesso la stringa vuota e. 90

19 7.4 Parser LL(1) per la grammatica G La grammatica G è LL(1); di seguito è presentata la dimostrazione. Dimostrazione: Il simbolo iniziale E è parte sinistra di una sola regola (E Q Z), allora le condizioni 1 e 2 non devono essere verificate su E. Il simbolo non-terminale Z è parte sinistra della coppia di regole: Z ε opbin Q Z; First(ε) = ; First(opBin Q Z) = { opbin }; First(ε) First(opBin Q Z) = ; ε è annullabile; Follow(Z) = { $, ) }; First(opBin Q Z) = { opbin }; Follow(Z) First(opBin Q Z) =. Il simbolo non-terminale Q è parte sinistra della coppia di regole: Q quant property. F F ; First(quant property. F) = { quant } ; First(F) = { (, class, card } ; First(quant property. F) First(F) =. Il simbolo non-terminale F è parte sinistra delle coppie di regole: 1) F ( E ) class; First(( E )) = { ( }; First(class) = { class }; First(( E )) First(class) = ; 2) F ( E ) card n property; First(( E )) = { ( }; First(card n property) = { card }; First(( E )) First(card n property) = ; 91

20 3) F class card n property. First(class) = { class }; First(card n property) = { card }; First(class) First(card n property) =. la grammatica G è LL(1) c.v.d. Un modo di implementare un parser LL(1) è quello di racchiudere ogni insieme di regole a partire da uno stesso non-terminale in una funzione Booleana. In questo tipo di parser deve esservi una tale funzione per ogni non-terminale della grammatica. Ogni funzione dovrà tentare ciascuna parte destra finché non trova una corrispondenza. Se la corrispondenza viene trovata la funzione deve ritornare true, altrimenti deve ritornare false. Ciascuna di queste funzioni dovrà scegliere la parte destra in base agli insiemi First e Follow. Un parser LL(1) di questo tipo cerca sulla grammatica la derivazione di una stringa eseguo per prima la funzione del simbolo iniziale, la quale chiamerà ricorsivamente le altre funzioni e/o essa stessa secondo le regole della grammatica. Ogni funzione restituisce true o false e se tutte le istanze di tutte le funzioni restituiscono true allora la prima istanza della funzione del simbolo iniziale (cioè quella che è stata generata per prima ed ha generato tutte le altre) restituisce true, altrimenti restituisce false. Nella realizzazione di ossa è stato sviluppato un parser di questo tipo; nelle figure 55, 56, 57 e 58 è rappresentato lo pseudocodice delle quattro funzioni che costituiscono il parser LL(1) implementato in ossa per la grammatica G (in realtà il parser implementato in ossa è più sofisticato di quello presentato di seguito, infatti oltre a eseguire la verifica sintattica di un espressione DL di annotazione, durante il parsing costruisce e fornisce in output l espressione OWL corrispondente a quella DL data in input). 92

21 Regola: E Q Z; First(Q Z) = { quant, class, card, ( }; function E: Boolean var cc: char; E:= false; cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc { quant, class, card, ( } then sposta il cursore a sinistra di una posizione; if Q then if Z then E := true; Fig. 55 funzione E del parser LL(1) per G 93

22 Regole: Z ε opbin Q Z; First(opBin Q Z) = { opbin }; Follow(Z) = { $, ) }; function Z: Boolean var cc: char; Z:= false; cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc = opbin then if Q then if Z then Z := true; else if cc { $, ) } then sposta il cursore a sinistra di una posizione; Z := true; Fig. 56 funzione Z del parser LL(1) per G 94

23 Regole: Q quant property. F F ; First(quant property. F) = { quant }; First(F) = { (, class, card } ; function Q: Boolean var cc: char; Q:= false; cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc = quant then cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc = property then cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc =. then if F then Q := true; else if cc { (, class, card } then sposta il cursore a sinistra di una posizione; if F then Q := true; Fig. 57 funzione Q del parser LL(1) per G 95

24 Regole: F ( E ) class card n property; First( (E) ) = { ( }; First(class) = { class } ; First(card n property) = { card } ; Follow(F) = { $, opbin, ) }; function F: Boolean var cc: char; F:= false; cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc = card then cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc = n then cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc = property then cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc { $, opbin, ) } then sposta il cursore a sinistra di una posizione; F := true; else if cc = class then cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc { $, opbin, ) } then sposta il cursore a sinistra di una posizione; F := true; else if cc = ( then if E then cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc = ) then cc:= il primo carattere alla destra del cursore; sposta il cursore a destra di una posizione; if cc { $, opbin, ) } then sposta il cursore a sinistra di una posizione; F := true; Fig. 58 funzione F del parser LL(1) per G 96

25 7.5 Inizializzazione dell applicazione La fase di costruzione di annotazioni strutturate tramite ossa presuppone la precedente fase di selezione e recupero di classi e/o di proprietà da un ontologia tramite VisualOntoGraph. Senza avere un insieme di classi e/o di proprietà non è possibile infatti costruire espressioni del linguaggio L(G ) precedentemente descritto. Un utente che vuole costruire un annotazione strutturata tramite ossa è vincolato quindi a interagire prima con FormalAnnotation per lanciare VisualOntoGraph, quindi con VisualOntoGraph per selezionare classi e/o proprietà, quindi ancora con FormalAnnotation per lanciare OSSA. Si osservi che nello schema appena descritto il lato client di VisualOntoGraph e il lato client di FormalAnnotation si sincronizzano sull evento creazione nella macchina dell annotatore dei file classe.txt e properties.txt. Finché VisualOntoGraph non ha creato questi file non è possibile utilizzare l interfaccia di FormalAnnotation. Questo schema di comunicazione è ereditato da ossa, il quale quindi se è lanciato da FormalAnnotation successivamente alla selezione di concetti con VisualOntoGraph può aspettarsi di trovare localmente questi due file. Una volta che è stato lanciato ossa, esso per prima cosa va a leggere i file classes.txt e properties.txt (se non li trova avverte l utente con il corrispondente messaggio di errore). Questi sono file di testo e contengono le informazioni relative alle classi e alle proprietà selezionate precedentemente dall utente. Ossa riconosce queste informazioni grazie ad un analisi lessicale del testo contenuto nei file. I file sono creati da VisualOntoGraph secondo uno schema su cui ci si è accordati in fase di progetto (vedi figure 59 e 60). classe 1, classe 2,... classe n Fig. 59 schema file classes.txt proprietà 1 (dominio 1,codominio 1 ), proprietà 2 (dominio 2,codominio 2 ),... proprietà m (dominio m,codominio m ) Fig. 60 schema file properties.txt 97

26 I due file contengono una sequenza di caratteri che in fase di analisi lessicale ossa tokenizza, trasforma cioè in un insieme di parole (token). L analisi lessicale è eseguita durante la lettura dei file. Contemporaneamente alla tokenizzazione i token vengono ordinati alfabeticamente (tramite un algoritmo di ordinamento con ricerca binaria, simile al Merge-Sort, con complessità n log 2 n ) e ad ognuno è assegnato un codice identificativo (univoco) breve per migliorare l efficienza dell analisi sintattica che successivamente sarà eseguita dal parser. I token ordinati alfabeticamente sono memorizzati in una tabella, la quale contiene l etichetta e il codice identificativo di ogni token (vedi figura 61). Successivamente alla memorizzazione nella tabella, la lista ordinata di token è presentata all utente in un apposita finestra (vedi figura 62), la quale permette in fase di creazione dell espressione di annotazione di selezionare le classi o le proprietà e di importarle (tramite un apposito pulsante) in un altra finestra in cui è visualizzata l espressione DL e la corrispondente espressione OWL. 98

27 PermanentResidence, Woman, Human, Man, Organism, classes.txt tokenizzazione e ordinamento n log n home(human,permanentresidence), daughter(woman,human), wife(woman,man), husband(man,woman), mother(organism,organism), sister(woman,human), brother(man,human), child(human,human) properties.txt etichetta brother child daughter home Human husband Man mother Organism PermanentResidence sister wife Woman ID p0 p1 p2 p3 c0 p4 c1 p5 c2 c3 p6 p7 c4 tabella dei token in memoria Fig. 61 lettura file classes.txt e properties.txt con tokenizzazione e ordinamento (i concetti dell esempio sono presi da SUMO) 99

28 Fig. 62 interfaccia di ossa per la visualizzazione di concetti (la visualizzazione è riferita all esempio in figura 61) Si osservi che: - l esistenza dei file classes.txt e properties.txt sulla macchina utilizzata per annotare; - la lettura e la tokenizzazione del contenuto di questi file; - l ordinamento, l assegnazione di un ID e la memorizzazione dei token risultanti dalla tokenizzazione; - la creazione e l esistenza della tabella; sono completamente trasparenti all utente e realizzati automaticamente al momento del lancio dell applicazione. Quando appare sul monitor dell annotatore l interfaccia di ossa, i processi sopra elencati sono già stati eseguiti e la tabella che è stata creata risiede in memoria. Appena l interfaccia di ossa è visualizzata la fase di inizializzazione è conclusa. 100

29 7.6 Pre-Parsing e Feedback-Aiuto Durante l interazione che un utente ha con le finestre grafiche di ossa per realizzare l espressione DL di annotazione, l applicazione esegue una parziale verifica sintattica. Tale verifica precede il vero e proprio controllo sintattico che esegue il parser una volta che la costruzione dell espressione è terminata ed è stata implementata per impedire all utente di commettere errori grossolani. Questa operazione di verifica sintattica parziale è stata chiamata Pre-Parsing; essa individua gli errori al momento stesso che sono commessi e avverte l utente con una finestra di dialogo che, oltre al messaggio di errore, contiene un consiglio sulla giusta sintassi. Tali consigli sono stati chiamati Feedback-Aiuto (vedi figura 72). Fig. 72 esempio di Feedback-Aiuto Il processo di Pre-Parsing è basato su delle considerazioni fatte sulla grammatica G. Nelle regole di tale grammatica ogni categoria sintattica ha una forma ben definita che ha permesso la definizione di ulteriori regole. Queste nuove regole sono utilizzate nel Pre-Parsing ma non sono utilizzate nella verifica sintattica vera e propria. Le considerazioni che sono state fatte sono del tipo: se F card n property è una regola della grammatica, allora nella costruzione dell espressione è consentito: 1) inserire il simbolo n successivamente al simbolo card; 2) inserire il simbolo property successivamente al simbolo n. 101

30 Questo appena descritto è il caso più semplice perchè la parte destra della regola è composta solo di simboli terminali. Il caso più complesso è invece del tipo: se Q quant property. F è una regola della grammatica e First(F) = {(, class, card}, allora nella costruzione dell espressione è consentito: 1) inserire il simbolo property successivamente al simbolo quant ; 2) inserire il simbolo. successivamente al simbolo property ; 3) inserire il simbolo ( successivamente al simbolo. ; 3) inserire il simbolo class successivamente al simbolo. ; 3) inserire il simbolo card successivamente al simbolo.. Considerazioni di questo tipo sono state fatte su ogni regola della grammatica G. Si noti che da tali considerazioni è possibile stabilire per ogni simbolo terminale l insieme di simboli terminali che possono seguirlo e l insieme di simboli terminali che non possono seguirlo. Infatti se T è l insieme finito di simboli terminali in G e C T è l insieme dei simboli terminali consentiti in G successivamente al simbolo terminale t, allora l insieme dei simboli terminali non consentiti in G successivamente al simbolo terminale t è T C. L insieme di regole derivate in questo modo dalla grammatica G è rappresentato nella tabella di figura 73. T = {, =,, classe, (,,,,, ),., proprietà, numero } Token C: Token consentiti successivamente T-C:Token non consentiti successivamente classe,, ), =,, classe, (,,,., proprietà, numero proprietà,, ),., =,, classe, (,,, proprietà, numero numero proprietà, =,, classe, (,,,,, ),., numero (, =,, classe, (,,,, ),., proprietà, numero ),, ), =,, classe, (,,,., proprietà, numero,, =,, classe, (,,,, ),., proprietà, numero., =,, classe, (,,,, ),., proprietà, numero, =, numero, =,, classe, (,,,,, ),., proprietà, proprietà, =,, classe, (,,,,, ),., numero Token consentiti in prima posizione Token non consentiti in prima posizione, =,, classe, (,,,, ),., proprietà, numero Fig. 73 regole del Pre-Parsing 102

31 Il processo di Pre-Parsing è attivo durante tutta la fase di costruzione dell espressione DL di annotazione e controlla l inserimento dei token all interno dell espressione: se il token che l utente tenta di inserire è consentito (secondo la tabella di figura 73) allora l inserimento è accettato, se invece non è consentito (secondo la tabella di figura 73) allora l inserimento è rifiutato e viene mandato in esecuzione un Feedback-Aiuto in cui compare l elenco di token consentiti (secondo la tabella di figura 73) in quel momento dell interazione. Si noti che il processo di Pre-Parsing non garantisce che l espressione costruita sia sintatticamente corretta, infatti esso impedisce all utente di commettere soltanto alcuni degli errori sintattici possibili e quindi l espressione costruita deve essere comunque verificata dal parser. Al termine della costruzione dell espressione il processo di Pre-Parsing termina e va in esecuzione il parser che realizza la verifica sintattica completa dell espressione (vedi figura 74). inizio inserimento accettato si Pre-Parsing inserimento token Token consentito? costruzione espressione terminata Feedback-Aiuto inserimento rifiutato no Feedback-Aiuto no Parsing espressione derivabile da G? si codice OWL Fig. 74 Pre-Parsing e Parsing 103

32 7.7 Interfaccia GUI Successivamente alla fase di inizializzazione sul monitor dell utente vengono visualizzate le due finestre grafiche di ossa: 1) SelectedConcepts; 2) Ontological Structured Semantic Annotation. 104

33 7.7.1 SelectedConcepts SelectedConcepts è la finestra grafica secondaria dell applicazione; essa è composta da due schede: - Concepts Imports (vedi figura 62), è la scheda che propone all utente tutti i concetti (classi e proprietà) che ha precedentemente selezionato su VisualOntoGraph; i concetti sono visualizzati in colonna (colonna token) in ordine alfabetico; in corrispondenza di ognuno è riportato il tipo (colonna type): class o property. I concetti possono essere utilizzati nell espressione di annotazione. Per farlo è sufficiente un doppio click sul token desiderato (il quale lo seleziona) e quindi la pressione del pulsante Imports Selected (la quale provoca l importazione del token selezionato nell altra finestra); si noti che durante l importazione di un concetto in Ontological Structured Semantic Annotation, ossa controlla cosa si tenta di importare e permette l operazione solo se è stata selezionata una classe o una proprietà, in caso contrario viene visualizzato un messaggio di errore (vedi figura 63). - Concepts Memo (vedi figura 64), è la scheda che propone all utente le classi e le proprietà separatamente e nell ordine in cui l utente li ha precedentemente selezionati in VisualOntoGraph. Delle proprietà è riportato il dominio e il codominio, i quali dovrebbero essere già conosciuti dall utente per la precedente interazione con VisualOntoGraph, ma sono comunque riportati in questa scheda come promemoria al fine di aiutare l utente a non commettere errori semantici durante la costruzione delle espressioni di annotazione (ad esempio se il range della proprietà husband è Woman, e l utente costruisce l espressione husband. Man, egli commette un errore semantico). 105

34 Fig. 63 messaggio di errore per tentata importazione di qualcosa di diverso da una classe e da una proprietà Fig. 64 scheda Concepts Memo di SelectedConcepts 106

35 7.7.2 Ontological Structured Semantic Annotation Ontological Structured Semantic Annotation è la finestra principale di ossa, quella con cui l utente deve interagire per costruire l espressione DL di annotazione. In questa finestra viene visualizzato, tra le altre cose, il codice OWL prodotto dal parser. In figura 65 è riportata una rappresentazione di Ontological Structured Semantic Annotation in cui è aggiunto un numero di riferimento ad ogni porzione della finestra; i riferimenti richiamano i dettagli riportati di seguito. Fig. 65 interfaccia Ontological Structured Semantic Annotation (vedi note di seguito) 1) La zona dell interfaccia di colore bianco contenente il numero 1 permette la visualizzazione di testo su molteplici righe ed ha la proprietà di essere in sola lettura. In questa zona viene visualizzato il codice OWL prodotto dal parser come traduzione dell espressione DL prodotta dall utente. 2) La zona dell interfaccia di colore grigio contenente il numero 2 permette la visualizzazione di testo su un unica riga ed ha la proprietà di essere in sola lettura. In questa zona viene visualizzata la codifica dell espressione DL 107

36 costruita dall utente (i token sono rappresentati in modo abbreviato con i rispettivi ID). Questa codifica è utilizzata in fase di elaborazione da ossa ed è utile per migliorare l efficienza del parsing, infatti durante la scansione dell espressione al parser basterà leggere la prima lettera del token che incontra per capire di che tipo di token si tratti. Nel codice abbreviativo utilizzato a token di stesso tipo (vedi figura 54) corrisponde la stessa lettera, a token di diverso tipo (vedi figura 54) corrispondono diverse lettere. È possibile considerare indistintamente token diversi ma di stessa categoria sintattica perché durante il parsing sono trattati in modo analogo (vedi paragrafi 7.2 e 7.4): al parser interessa solo conoscere il tipo (cioè la categoria sintattica) del token che va ad analizzare e non l etichetta specifica. Anche se durante la verifica sintattica non è importante conoscere l etichetta specifica di un token, durante la fase di generazione del codice OWL è necessario tradurre nuovamente il codice abbreviativo di un token nell etichetta originale del token stesso. Per risolvere questo problema il codice abbreviativo non contiene solo la lettera del tipo del token codificato ma anche un numero al quale è associata univocamente l etichetta del token codificato. Per quanto riguarda i costruttori del linguaggio di annotazione la codifica è statica ed è stata definita in fase progettuale; la codifica delle classi e delle proprietà è invece dinamica ed avviene in fase di inizializzazione dell applicazione secondo lo schema descritto nel paragrafo 7.5; anche la codifica dei numeri è dinamica, ed avviene al momento dell inserimento degli stessi. In figura 66 è rappresentata una tabella che esplica il codice abbreviativo sviluppato per ossa. Si noti che la tabella della figura 66 risiede in memoria durante l utilizzo di ossa, inoltre in essa è possibile fare accessi diretti grazie al fatto che tutti i token (costruttori, numeri, classi e proprietà) sono raggruppati per categoria sintattica di appartenenza. Ne consegue che ogni accesso ha costo costante e quindi anche la codifica o la decodifica dei token ha costo costante (ad esempio per effettuare la decodifica la prima lettera di un codice identificativo individua una categoria sintattica e la porzione della tabella associata ad essa, il numero che segue nel codice identificativo individua la posizione specifica all interno della porzione della tabella precedentemente selezionata; nella locazione individuata in questo modo è possibile accedere direttamente e recuperare l etichetta del token che si va a decodificare). 108