UNIVERSITÀ DEGLI STUDI DI BARI
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea in Scienze dell’Informazione
___________________________________________________________________
Tesi di Laurea
Generazione automatica di metafore per le
interfacce utente di database multimediali
Relatori:
Chiar.mi Prof.ri
M.F. COSTABILE
D. MALERBA
Laureanda:
A. LOCONSOLE
_______________________________________________________________________
ANNO ACCADEMICO 1997/1998
INDICE
INTRODUZIONE
5
1. Sistemi di interrogazione visuale
8
1.1. Introduzione
8
1.2. Paradigmi per l’interrogazione visuale
9
1.3. VQS Multiparadigma
15
1.4. Realtà Virtuale
17
1.4.1. Realtà virtuale immersiva, non immersiva e aumentata
18
1.4.2. Realtà virtuale come nuovo paradigma di interazione
20
1.5. Un linguaggio per la simulazione di mondi virtuali
2. Problemi di soddisfacimento dei vincoli
22
25
2.1. Introduzione
25
2.2. Tecniche di soluzione per problemi combinatori e discreti
28
2.3. L’implementazione software
31
2.4. Applicazione del Prolog alla etichettatura di immagini
34
2.4.1. Determinazione dei vincoli
36
2
3. Un sistema di visualizzazione di dati in realtà virtuale
40
3.1. Introduzione
40
3.2. Il sistema Virgilio
41
3.3. Uso di metafore in Virgilio
45
3.4. Architettura di Virgilio
49
3.5. Architettura del Query Management Tool
53
4. Generazione dello structure tree
56
4.1. Introduzione
56
4.2. Definizione di structure tree
57
4.3. Query Repository
62
4.4. Strumenti utilizzati
64
4.4.1. Flex
65
4.4.2. Bison
67
4.5. Realizzazione dello Structure Tree Generator
70
4.6. Esecuzione del programma STG
71
4.7. Esempi di subquery create dal programma STG
75
5. Generazione automatica delle metafore in Virgilio
78
5.1. Introduzione
78
5.2. Requisiti per il mapping
79
5.3. Classificazione degli oggetti virtuali
80
3
5.3.1. Il mondo virtuale “palazzo”
83
5.4. Definizione della metafora come un problema di
soddisfacimento di vincoli
85
5.5. Il Metaphor Definition Tool
90
5.6. Esempio delle scene finali in VRML
91
5.7. Conclusioni
94
6. BIBLIOGRAFIA
96
Appendice
101
4
INTRODUZIONE
Uno dei più importanti problemi che bisogna risolvere per una
soddisfacente utilizzazione del calcolatore è l’identificazione di
appropriate modalità di comunicazione con esso. Quanto più il
calcolatore entra nella vita di tutti i giorni tanto più il problema diventa
reale. L’interfaccia utente di un sistema software è quella componente
che ha la funzione di rendere l’interazione utente-calcolatore la più
efficace possibile. Nel campo delle interfacce per basi di dati, si
propone in questa tesi di far uso di una modalità basata su una
rappresentazione a Realtà Virtuale. In generale la Realtà Virtuale ha lo
scopo di costruire un mondo virtuale, il più fedele possibile alla realtà,
in cui gli oggetti sono presi dal mondo reale e le possibili operazioni
sono simili a quelle effettuate nella realtà. L’utilizzo di Realtà Virtuale
per le interfacce di basi di dati permetterebbe quindi un approccio
alquanto immediato, visto che gli oggetti presenti nella base di dati
verrebbero rappresentati, nei limiti in cui è possibile, come sono nella
realtà o attraverso metafore molto significative per l’utente. Rispetto
ad altre forme di visualizzazione di informazioni, con la Realtà
Virtuale l’utente è agevolato perché i dati sono visualizzati mediante
oggetti familiari. Nella Realtà Virtuale infatti la percezione dell’utente
viene direttamente stimolata.
Questa tesi si inserisce nel progetto Virgilio, cui collaborano il GMD
IPSI (German National Research Center for Information Technology-
5
Integrated Publication and Information System Institute) di Darmstadt
e il Dipartimento di Informatica dell’Università di Bari.
Virgilio è un sistema basato su Realtà virtuale, sviluppato per essere
uno strumento di esplorazione general pourpose per dati altamente
strutturati. Virgilio visualizza i risultati di una query ad una base di
dati generando scene in Realtà Virtuale e sfruttando metafore
appropriate per trarre vantaggio dalla conoscenza sugli oggetti del
mondo reale, riducendo così il carico cognitivo nel processo di
assimilazione dell’informazione.
Il lavoro di questa tesi riguarda l’analisi e lo sviluppo di due
componenti dell’architettura di Virgilio, il Query Management Tool ed
il Metaphor Definition Tool. Esso è stato svolto in parte presso
l’Università di Bari e in parte presso il GMD-IPSI durante un
soggiorno di quattro mesi.
Nel primo capitolo della tesi vengono illustrati differenti paradigmi
visuali di interazione con basi di dati. In particolare viene presentato
l’approccio basato su RV ed un linguaggio (il VRML) che consente la
simulazione dei mondi virtuali.
Nel secondo capitolo si illustrano le tecniche per risolvere i problemi
di soddisfacimento dei vincoli poichè per la generazione delle
metafore si implementano delle procedure automatiche che sfruttano la
strategia di ricerca depth first degli interpreti Prolog per risolvere un
tipico problema di soddisfacimento dei vincoli.
6
Nel terzo capitolo si introduce il progetto Virgilio e si discutono le
metafore nell’interfaccia utente ed il loro utilizzo nel sistema Virgilio;
infine è presentata l’architettura di Virgilio.
Nel quarto capitolo si descrive una componente dell’architettura di
Virgilio, lo Structure Tree Generator ed il processo che produce uno
structure tree da una query SQL posta ad un database relazionale a
oggetti. Lo Structure Tree Generator calcola il risultato della query
interrogando il database, e quindi trasforma il risultato in una nested
relation attraverso l’analisi della struttura della query SQL, generando
quindi il corrispondente structure tree.
Nel quinto capitolo si descrive un’altra componente dell’architettura di
Virgilio, il Metaphor Definition Tool, che è stato sviluppato nella tesi e
si presenta una procedura completamente automatica per definire la
metafora che sarà sfruttata nella costruzione della scena in RV.
L’implementazione di questa procedura sfrutta la strategia di ricerca
depth first degli interpreti Prolog per risolvere un tipico problema di
soddisfacimento di vincoli, cioè problemi combinatori e discreti
applicati alla etichettatura di immagini.
Un sentito ringraziamento viene rivolto ai Prof.ri M. F. Costabile e D.
Malerba dell’Università di Bari, ai Prof.ri E.J. Neuhold, Dieter
Boecker e Matthias Hemmje del GMD-IPSI ed A. Paradiso, M.
L’Abbate per il loro costante aiuto e la preziosa collaborazione offerti
nella realizzazione di questo lavoro. Si ringraziano inoltre tutti coloro
che hanno fornito un supporto tecnico e morale.
7
Sistemi di interrogazione visuale
Capitolo primo
1.
Sistemi di interrogazione visuale
1.1.
Introduzione
Si avverte sempre di più la necessità di rendere le interfacce di accesso
alle basi di dati facili da usare, in modo che anche utenti poco esperti
possano accedere alle informazioni ivi contenute senza troppe
difficoltà e senza conoscerne la struttura [Catarci & Costabile, 1996].
Per accedere alle informazioni contenute nelle basi di dati, sono stati
definiti appositi linguaggi, chiamati Linguaggi di Interrogazione.
All’inizio
la
maggior
parte
di
questi
erano
linguaggi
di
programmazione. Col tempo si è cercato di definire dei linguaggi
comprensibili e usabili da gente che non è molto pratica dei calcolatori.
L’orientamento generale è stato quello di migliorare l’interfaccia che
c’è tra l’utente e la base di dati, in modo da svincolare il più possibile
l’utente dal conoscere la base di dati vera e propria ed operare solo
tramite l’interfaccia. È chiaro perciò che l’interfaccia deve poter
mostrare il contenuto della base di dati in modo chiaro e semplice da
interpretare da chiunque, e permettere di formulare interrogazioni
senza dover conoscere o imparare alcun linguaggio. Sono così nati i
Linguaggi di Interrogazione Visuale (VQL), linguaggi cioè che usano
8
Sistemi di interrogazione visuale
la rappresentazione visuale per mostrare il contenuto della base di dati
ed esprimere le relative interrogazioni. Essi sono inoltre dotati di
funzionalità per facilitare l’interazione utente-calcolatore e la
visualizzazione dei dati. Sistemi che implementano tali linguaggi
prendono il nome di Sistemi di Interrogazione Visuale (VQS) [Catarci
et al., 1997]. Attualmente, la maggior parte dei VQL si basa sui
seguenti formalismi visuali: moduli, diagrammi, icone e si sta cercando
di utilizzare una nuova tecnica di rappresentazione visuale: la Realtà
Virtuale.
1.2.
Paradigmi per l’interrogazione visuale
Si è già visto quali sono i formalismi visuali su cui si basano la
maggior parte dei VQL: moduli, diagrammi, icone [Catarci et al.,
1997]. Verranno ora descritti singolarmente.
Il paradigma basato su moduli (form based) è il primo tentativo
effettuato per lasciare lo spazio testuale monodimensionale e passare
ad una rappresentazione bidimensionale, sfruttando appunto la
bidimensionalità dello schermo [Catarci et al., 1997]. La sua principale
caratteristica è quella di essere una rappresentazione strutturata
corrispondente all’astrazione di un modulo di carta, già familiare alle
persone nelle loro attività quotidiane. Un modulo è anche visto come
una generalizzazione di una tabella, ed in questo l’utente è facilitato
nell’interazione con il calcolatore per la naturale tendenza che egli ha
9
Sistemi di interrogazione visuale
nell’uso e/o nell’organizzazione dei dati in strutture regolari come le
tabelle. Un modulo è una collezione di oggetti aventi la stessa
struttura. Può essere visto come una griglia rettangolare le cui
componenti sono una qualunque combinazione di celle o gruppi di
celle. Ogni riga rappresenta un oggetto, ogni colonna indica proprietà
comuni degli oggetti. Le relazioni possono esistere tra singoli elementi
(l’unità più piccola di informazione è una cella), tra sottoinsiemi di
elementi o tra gruppi di elementi. Tipicamente, le query in tale
paradigma si effettuano riempiendo i campi di un modulo. Si consideri
come esempio il QBE (Query By Example) [Zloof, 1976]. Sullo
schermo viene presentato all’utente lo schema della base di dati,
cosicché l’utente non deve più ricordare il nome degli attributi e/o
delle relazioni, ed interroga la base di dati riempiendo i campi di tale
schema. Una condizione di Select viene scritta nella casella
corrispondente all’attributo interessato dalla condizione (età>50 in
Figura 1.1 o sesso=F e città=Bari in Figura 1.2). Una P in una casella
indica invece una project su tale attributo.
PAZIENTE
NOME
COGNOME
DATA DI NASCITA
ETA’
P.
P.
P.
>50
SESSO
INDIRIZZO
CITTÀ’
P.
Figura 1.1 Esempio di query nel QBE: “Visualizza il nome, il
cognome, la data di nascita e la residenza di tutti i pazienti che abbiano
più’ di 50 anni”.
10
Sistemi di interrogazione visuale
PAZIENTE
NOME
COGNOME
P.
P.
DATA DI NASCITA
ETA’
SESSO
F
INDIRIZZO
CITTÀ’
BARI
Figura 1.2 Esempio di query nel QBE: “Visualizza il nome ed il
cognome di tutti i pazienti donna residenti a Bari”.
Un diagramma è una modalità di rappresentazione dell’informazione
che fa uso di elementi grafici, in genere semplici figure geometriche
(quadrati, rettangoli, cerchi, rombi, ecc....), codificando l’informazione
tramite la posizione relativa e la grandezza di tali figure geometriche
[Catarci et al., 1997]. La rappresentazione diagrammatica fa appunto
uso di diagrammi per rappresentare il contenuto della base di dati,
associando ad ogni figura geometrica uno specifico concetto. Un
diagramma è un insieme di nodi connessi da archi. In questa maniera è
possibile rappresentare un insieme di elementi e di relazioni binarie tra
essi. Tale paradigma quindi si presta bene per rappresentare le
relazioni tra oggetti, che vengono appunto esplicitate per mezzo di
connessioni tramite archi. Come conseguenza, la query può essere
naturalmente espressa manipolando direttamente gli elementi dei
diagrammi e navigando tra essi: tipicamente si selezionano gli elementi
seguendo i percorsi che li uniscono. Un diagramma, inoltre, non è
statico, ma può essere manipolato per includere altre relazioni. Il QBD
(Query By Diagram, [Angelaccio et al., 1990]) è un sistema che fa uso
del paradigma basato su diagrammi. Esso si basa su di un modello
concettuale quale il modello Entità-Relazione per rappresentare la
parte intensionale della base di dati e utilizza un ambiente
completamente grafico come interfaccia utente amichevole con il
11
Sistemi di interrogazione visuale
sistema. Sullo schermo viene presentato il diagramma rappresentante il
contenuto della base di dati e l’utente formula la query selezionando le
entità e le relazioni coinvolte in tale query. Si supponga di voler
conoscere tutte le persone che lavorano nella stessa città in cui vivono.
Per formulare tale query, si selezioneranno in sequenza l’entità città, la
relazione lavora, l’entità persona, la relazione risiede e di nuovo
l’entità città, dando luogo al diagramma di Figura 1.3. Fatto questo, si
passa ad esprimere le condizioni su ogni oggetto (nome della città in
cui lavora = nome della città in cui vive), indicando anche quali
attributi includere nel risultato.
è n a ta in
P ER SO N A
r is ie d e
C IT T A ’
la v o r a
p o s s ie d e
P R O P R IE T A ’
Figura 1.3 Diagramma dopo la selezione delle entità coinvolte nella
query.
Un’icona, nel campo dei calcolatori, è un’immagine segmentata e
stilizzata, in cui si distingue la parte pittorica da quella semantica. La
prima è ciò che viene visualizzato sullo schermo, la seconda il
significato che tale immagine rappresenta. Un’icona può rappresentare,
nel rispettivo paradigma, sia oggetti della base di dati sia operazioni
12
Sistemi di interrogazione visuale
che è possibile effettuare su di essi. Poiché si devono visualizzare
anche concetti astratti, oltre a quelli reali, per correlare le due parti,
quella pittorica e quella semantica, si ricorre a figure retoriche quali ad
esempio, l’analogia, la convenzione, la metonimia ecc.... La realtà di
interesse nel paradigma iconico viene presentata per mezzo di icone, e
la query viene effettuata selezionando e combinando tra loro le icone.
Mentre un diagramma riesce a rappresentare bene le relazioni esistenti
tra oggetti, lo scopo principale di un’icona è quello di rappresentare un
certo concetto, in modo che l’utente riesca a comprendere facilmente
ciò che tale icona sta a significare, per poterla manipolare . Un sistema
basato su icone è diretto soprattutto ai cosiddetti utenti casuali che non
hanno familiarità con un modello dei dati e potrebbero trovare difficile
interpretare un diagramma Entità Relazione. Il QBI (Query By Icons)
[Massari et al., 1995] è un sistema di interrogazione visuale per una
base di dati che fa uso di icone sia per la visualizzazione del contenuto
informativo della base di dati che per la formulazione della query. Esso
si differenzia dagli altri sistemi basati su icone sostanzialmente per il
modo in cui le icone sono definite ed usate per esprimere concetti.
Infatti per rappresentare un oggetto (entità o attributo) della base di
dati un icona nel QBI è composta dai seguenti elementi grafici :
l’immagine: è la parte grafica che rappresenta metaforicamente
l’oggetto;
la descrizione: è una frase in linguaggio naturale, generata
automaticamente dal sistema, che descrive l’oggetto ;
13
Sistemi di interrogazione visuale
l’etichetta: serve per distinguere due icone che hanno la stessa
immagine (visto che la descrizione non sempre è visualizzata);
la forma: è la figura geometrica avente dei contorni che permettono
di combinare solo icone simili (ad esempio, un’icona rappresentante
una stringa (nome di una persona) avrà una forma diversa da una
rappresentante un intero (età di una persona)).;
la struttura: indica la cardinalità dell’oggetto .
Una query nel QBI si effettua innanzitutto selezionando le entità e gli
attributi coinvolti nella query, poi si impongono le condizioni su questi
e infine si indicano quali degli attributi stampabili faranno parte del
risultato. Nell’imporre le condizioni ci viene in aiuto la forma delle
icone. Si possono infatti porre condizioni solo su icone che hanno la
stessa forma. Per far questo, si trascinano le icone interessate nell’area
delle condizioni, e si seleziona poi l’operazione da effettuare su di
esse.
La gran parte dei VQS adottano un’unica rappresentazione visuale. In
seguito si sono sviluppati dei sistemi ibridi, che possono essere divisi
in due categorie: quelli che hanno un’unica interfaccia che fa uso di
formalismi visuali di tipi diversi; e quelli cosiddetti multiparadigma,
che permettono diversi paradigmi di interazione consentendo
eventualmente il passaggio da un paradigma all’altro durante la
formulazione della query. In alcuni sistemi è anche possibile
14
Sistemi di interrogazione visuale
mantenere una storia delle varie query parziali che porteranno poi alla
query finale.
1.3.
VQS Multiparadigma
Un sistema che utilizza un unico formalismo visuale, è un sistema
piuttosto limitativo. Esso restringe le classi di utenti che possono trarre
vantaggio da un tale sistema. L’andamento attuale è quello di costruire
sistemi che offrano più paradigmi di interazione, ognuno con
caratteristiche differenti, cosicché ogni utente, sia esso principiante o
esperto, potrà scegliere il paradigma più adatto per interagire con il
sistema. Una tale interfaccia multiparadigma, è stata proposta in
[Catarci et al, 1996], in cui la selezione di un appropriato paradigma
viene effettuata in base ad un modello di utente che descrive l’interesse
ed il livello dell’utente. Questo perché per loro natura, le persone
hanno comportamenti non prevedibili, interessi vari e abilità diverse.
Dal momento che non si possono ricavare informazioni a priori sul tipo
di utente che di volta in volta interagirà col sistema, l’interfaccia sarà
resa personalizzabile, creando un modello per ogni utente che vi
interagisce. Il sistema stesso è in grado di collezionare dati che
vengono aggiornati dinamicamente, per poter suggerire all’utente il
paradigma di interazione più appropriato in base al suo livello di
abilità e alle sue necessità. Naturalmente, l’utente ha sempre la facoltà
di cambiare il paradigma in un altro tra quelli disponibili. In Catarci et
al., (1997) è possibile trovare una suddivisione degli utenti in classi in
15
Sistemi di interrogazione visuale
base a determinati criteri (frequenza di interazione, tipo di query,
ecc...).
Gli utenti casuali e quelli inesperti, difficilmente sono in grado di
formulare direttamente la query che li soddisfa in pieno al primo
tentativo, sia perché non hanno una conoscenza precisa del contenuto
della base di dati, sia perché non hanno familiarità con il linguaggio di
interrogazione. Essi inoltre, non accettano volentieri la fase di
apprendimento di un linguaggio di interrogazione, soprattutto quando
non hanno un background tecnico per poter capire i meccanismi di
interazione con il sistema. In questo caso, l’utente preferisce formulare
la query in maniera progressiva, per passi, effettuando prima domande
più generali, ottenendo risultati preliminari, e poi rivisitando questi
ultimi per raffinare ulteriormente la query fino ad ottenere i dati che gli
interessano [Chang et al., 1994]. Questo processo prende il nome di
query progressiva, un processo in cui si ha un obiettivo iniziale da
raggiungere (ottenere specifiche informazioni), che può cambiare nel
corso della formulazione della query, o anche spostando l’obiettivo su
informazioni diverse ma collegate con quello che era l’obiettivo
iniziale.
La query progressiva è la modalità più tipica per interrogare una base
di dati per un utente novizio, occasionale, cioè un utente che utilizza il
sistema raramente. Quando una persona cerca specifiche informazioni
in una nuova città, potrebbe consultare una cartina di quella città,
probabilmente prendendo come punti di riferimento un parco (una
grande area verde) o una stazione ferroviaria (lunghe linee parallele
che rappresentano i binari), e gradualmente raggiungere l’indirizzo
cercato. Questa persona può poi tornare indietro nella ricerca di una
16
Sistemi di interrogazione visuale
fermata di autobus o metropolitana per vedere se un mezzo pubblico
può aiutarla nel raggiungimento di quel posto. Oppure, può cercare
un’area per parcheggio e decidere quindi se andare in auto o con mezzi
pubblici. Infine, può cercare altri punti di riferimento, come ad
esempio se ci sono negozi per comprare un regalo, ecc. Il processo che
è stato chiamato query progressiva, è simile al processo appena
descritto cioè una sorta di navigazione nella base di dati. Questo è un
approccio diverso da quello della teoria delle basi di dati, in cui la
query è rifinita gradatamente e i dati candidati ad essere il risultato
della query sono sempre più ridotti e specializzati. La progressione
della query è quindi monotona. Nel processo di query progressiva
invece, si vuole che la formulazione della query avvenga in
progressione, ma non in maniera monotona. Si vuole cioè che sia
possibile formulare la query in una progressione non-monotona.
1.4.
Realtà Virtuale
Negli ultimi tempi si sente sempre più spesso parlare di RV. Ma che
cosa è la RV? Per alcuni l’elemento chiave della definizione della RV
è l’interattività. In base a questa definizione, se si può usare un mouse
per navigare all’interno di un modello di una casa su uno schermo di
un calcolatore, allora si sta utilizzando la RV. Altri dicono che
l’interattività non basta e sostengono che una RV deve essere un
ambiente accessibile in rete che permetta a più persone di entrarvi
nello stesso tempo. Altri ancora limitano la RV a quegli ambienti che
17
Sistemi di interrogazione visuale
fanno uso di caschi i quali permettono agli utenti di essere “immersi”
in questi mondi artificiali. Vi sono poi quelli che affermano che anche
quel livello di immersione non è abbastanza per essere qualificato
come RV: si deve arrivare all’immersione totale dell’intero corpo.
1.4.1. Realtà virtuale immersiva, non immersiva e
aumentata
Non esiste quindi una definizione precisa di cosa sia la Realtà Virtuale.
Le idee a tale riguardo sono infatti ancora molto confuse. Più chiara e
con un consenso più unanime è invece la suddivisione di RV in base
alle varie modalità di interazione dell’utente con l’ambiente virtuale. In
base a tale modalità si parlerà di realtà virtuale immersiva, realtà
virtuale non immersiva, realtà virtuale aumentata [Del Vecchio,
1995; Robertson, 1993].
La
realtà
virtuale
immersiva
prevede
che
l’utente
venga
completamente “proiettato” in un mondo virtuale attraverso un
particolare equipaggiamento, quali un casco denominato HMD (Head
Mounted Display, dotato all’interno di due display LCD a colori, uno
per occhio e di un tracker magnetico che serve a capire dove l’utente
sta guardando) e guanti speciali o addirittura particolari dispositivi di
immersione che consentono di percepire il movimento dell’intero
corpo, che gli permettono di interagire con tale mondo come egli
18
Sistemi di interrogazione visuale
farebbe in quello reale. Si ha cioè un’immersione totale dell’utente nel
mondo virtuale.
Nel caso invece della realtà virtuale non immersiva, l’interazione
uomo-mondo virtuale avviene tramite i normali dispositivi di
input/output con i quali l’utente interagisce normalmente con il
calcolatore:
il
mondo
virtuale
viene
presentato
all’utente
visualizzandolo su normali monitor ed egli interagisce tramite tastiera,
mouse o joystick.
C’è chi sostiene che l’immersione totale da parte dell’utente nel mondo
virtuale è essenziale per garantire un’interazione utente-calcolatore
efficiente. C’è chi invece sostiene che questa possa avere effetti
negativi, perché la realtà virtuale immersiva ha come conseguenza un
isolamento dell’utente dal mondo reale e da ciò che lo circonda.
Questo isolamento può comportare un certo stress fisico e psicologico
che non tutti gli utenti potrebbero sopportare. Bisogna inoltre
considerare che un casco ha un suo peso ed un’ergonomia piuttosto
limitata, per cui dopo un certo lasso di tempo l’indossare tale casco
diventa un vero e proprio fastidio. Per di più uno dei maggiori
problemi della tecnologia attuale è che la risposta agli input dell’utente
presenta un certo ritardo, creando così confusione tra le azioni del
partecipante e quello che appare come il risultato conseguente. Questo
fenomeno causa il cosiddetto “mal di simulazione”, i cui sintomi sono
nausea, affaticamento visivo e disorientamento spaziale [Brill, 1995].
D’altronde, in molte applicazioni si può ottenere un ottimo risultato
anche con la realtà virtuale non immersiva, anche perché le tecniche di
interazione basate sull’utilizzo di tastiera e mouse sono molto più facili
19
Sistemi di interrogazione visuale
da imparare rispetto a quelle basate sull’uso di guanti speciali (come il
dataglove). Tutto questo senza contare che il costo di apparecchiature
quali elmetto e guanti non sono nemmeno paragonabili a quelli di
monitor, tastiere, mouse e joystick.
Si parla invece di realtà virtuale aumentata in quei casi in cui si fa
uso della realtà virtuale per “aumentare” la vista del mondo reale con
immagini generate dal calcolatore. Per far questo si utilizzeranno
particolari
dispositivi
denominati
HUD
(Head
Up
Display),
parzialmente trasparente, in grado di aumentare il campo visivo
dell’utente; un esempio può essere quello di un chirurgo che può
accedere in tempo reale ad immagini ed informazioni mediche relative
ad un paziente mentre lo sta operando.
1.4.2. Realtà virtuale come nuovo paradigma di
interazione
L’applicazione di tecniche di RV nel campo delle interfacce per basi di
dati hanno portato all’introduzione di un nuovo paradigma di
interazione particolarmente adatto ad utenti inesperti e/o occasionali.
Tali
tecniche
combinano
i
vantaggi
della
visualizzazione
tridimensionale con il potere della rappresentazione metaforica.
L’utente è facilitato nella navigazione in una base di dati visto che il
sistema propone un ambiente che riproduce situazioni reali e dà la
possibilità di interagire manipolando oggetti che hanno una
corrispondenza bigettiva con oggetti conosciuti. La RV infatti ha lo
20
Sistemi di interrogazione visuale
scopo di costruire un mondo virtuale, il più possibile fedele alla realtà,
in cui gli oggetti siano presi dal mondo reale, e le possibili operazioni
dovrebbero essere quelle effettuate nella realtà. Ecco quindi che in un
paradigma basato sulla realtà RV gli oggetti presenti nella base di dati
verrebbero rappresentati, nei limiti in cui è possibile, come sono nella
realtà o attraverso metafore molto significative per l’utente. Rispetto
ad altre forme di visualizzazione di informazioni, con la realtà virtuale
l’utente è agevolato perché, potendo manipolare meglio i dati che
vengono visualizzati con oggetti familiari, riesce a capire subito qual è
il contesto in cui si trova, anche perché gli scenari virtuali sono
arricchiti con molti dettagli, presi da un contesto reale; in questo modo
si riduce la possibilità che l’utente si perda nel sistema, che dopo un pò
di navigazione nella base di dati egli non sappia più dove si trova.
Non si parla di realtà virtuale immersiva, di RV cioè in cui si ha la
pretesa di immergere fisicamente l’utente negli ambienti virtuali creati;
ma si parla di RV che non prevede l’immersione dell’utente, ma che ha
come scopo principale la visualizzazione della realtà [Preece et al.,
1994], ha cioè come scopo quello di proporre un ambiente virtuale che
risulti più vicino e simile alla realtà delle persone di quanto non lo
possa essere, ad esempio, una visualizzazione basata su icone.
Anche l’interazione dell’utente con il sistema utilizzando il paradigma
basato sulla RV è molto simile al comportamento che l’utente ha nella
realtà. Ad esempio, in un ospedale reale, se si cercano dati relativi ai
pazienti, si va verso lo schedario dove sono tenute le cartelle dei
pazienti e si cerca la cartella di uno specifico paziente. Una volta
trovata, la si apre e si leggono le informazioni alle quali si è interessati,
come ad esempio il suo indirizzo, il risultato degli esami effettuati,
21
Sistemi di interrogazione visuale
ecc.... Nella stessa maniera potrebbe essere implementato un sistema di
interrogazione per una base di dati basato sulla RV. Sullo schermo
verrebbe visualizzata una scena in cui vi è uno schedario. Lo si
seleziona e questo si apre. Successivamente si cerca la cartella relativa
al paziente di cui si vogliono le informazioni. Quando essa è stata
trovata, la si seleziona per aprirla e quindi poter leggere le
informazioni alle quali si è interessati.
Appare chiaro che l’utente è molto facilitato nell’interazione con una
base di dati utilizzando un’interfaccia che fa uso della RV. L’utente
infatti, impara molto più facilmente ad usare il sistema perché gli
oggetti e le metafore sono prese dalla vita reale e la maggior parte delle
volte lui già le conosce. Lo stesso vale per la modalità di interazione.
Lui sa già dove andare a trovare le informazioni a cui è interessato
perché si trovano, nei limiti in cui è possibile, nello stesso posto in cui
si trovano nella vita reale. L’unica cosa che resta da insegnargli è a
livello fisico, cioè l’uso dei mezzi fisici di interazione (mouse,
joystick, dataglove, elmetto, ecc.).
1.5.
Un linguaggio per la simulazione di mondi virtuali
Il VRML, Virtual Reality Modeling Language [Guglielmi et al., 1996],
è un linguaggio di programmazione che consente la realizzazione di
mondi virtuali interconnessi tramite Internet, visualizzabili tramite
pagine web e contenenti riferimenti (hyperlink) ad altre risorse
disponibili sulla rete.
22
Sistemi di interrogazione visuale
Si può a ragione sostenere che tramite il VRML si possano effettuare
simulazioni tridimensionali interattive, permettendo a tale linguaggio
la gestione completa della visualizzazione dei mondi virtuali creati, di
interazione delle singole parti con le azioni intraprese dall’utente, cioè
la gestione causa-effetto dei singoli eventi, e infine l’interconnessione
tramite Internet delle varie parti nel tutt’uno della ragnatela mondiale
conosciuta come World Wide Web (WWW).
L’idea del VRML nasce dalla necessità di avere un linguaggio comune
per la descrizione di scenari 3D e dei relativi “hyperlink” con il web,
linguaggio avente le stesse funzioni di quelle ricoperte dall’HTML
all’interno del WWW.
Inizialmente VRML significava Virtual Reality Markup Language (in
analogia con HTML, HyperText Markup Language); nel seguito la
parola Markup venne variata in Modeling per meglio rappresentare
l’aspetto grafico del linguaggio. VRML allo stato attuale è quindi
sinonimo di Virtual Reality Modeling Language [Guglielmi et al.,
1996].
La prima versione del VRML è basata su Open Inventor ASCII File
Format di Sylicon Graphics Inc, completata con alcune estensioni per
il supporto delle funzioni connesse all’utilizzo della rete Internet. Essa
doveva risultare indipendente da qualsiasi piattaforma hardware
software, essere sviluppabile e duttile, ma soprattutto consentire lo
sfruttamento ottimale delle risorse 3D su connessioni a bassa velocità.
Il VRML è indipendente dall’HTML ma come linguaggio “per
Internet” ne sfrutta e ne recepisce le potenzialità e le innovazioni.
23
Sistemi di interrogazione visuale
Il VRML è un linguaggio interpretato, non compilato quindi può
essere utilizzato da qualunque browser VRML compliant, cioè in
grado di tradurne i comandi in forma grafica. Il meccanismo di utlizzo
di un sorgente WRL (l’estensione tipica di un file ASCII contenente un
sorgente VRML) è relativamente semplice; l’utente si collega, tramite
un browser tipo Netscape o Internet Explorer al sito www contenente il
file; quest’ultimo viene caricato tramite la rete in sede locale (su PC o
workstation) e qui interpretato dal browser stesso.
Si può così astrarre il concetto base del VRML affermando che esso è
un sottoinsieme dell’Inventor File Format arricchito con alcune
funzioni che ne consentono l’esecuzione dal web includendovi inoltre
funzioni di richiamo di altri URL (Uniform Resource Locator),
nell’ottica tipica della navigazione per link del World Wide Web.
Inoltre permette di costruire scene tridimensionali facendo uso di
oggetti di forma arbitraria, immagini, suoni di formati MIDI o WAV,
link a URL remoti, sorgenti luminose, filmati in formato AVI o FLI
ecc. in cui è possibile definire luci e materiali da assegnare ai vari
oggetti, proprietà ed ambienti e creare effetti realistici.
Da ciò si comprende come le potenzialità del linguaggio in quasi ogni
campo dalle applicazioni scientifiche all’ambito pubblicitario, siano
limitate esclusivamente alla fantasia umana.
24
Problemi di soddisfacimento di vincoli
Capitolo secondo
2.
Problemi di soddisfacimento dei vincoli
2.1.
Introduzione
Molti problemi del mondo reale possono essere formulati come
Problemi di Soddisfacimento di Vincoli (PSV) cioè problemi per i
quali è richiesta la determinazione del valore di un certo numero di
variabili nel rispetto di un insieme di vincoli che le coinvolgono. Si
può immaginare una serie infinita di istanze di questi problemi con
caratteristiche e difficoltà di soluzione molto diverse tra loro. Le
tecniche di soluzione vengono studiate prevalentemente nell’Analisi
Matematica e nella Ricerca Operativa, e la realizzazione pratica di
queste tecniche in termini di software rappresenta una delle più ampie
problematiche dell’informatica coinvolgendo una parte considerevole
di risorse umane sia nell’ambito della ricerca che in quello industriale
[Guidotti et al., 1994].
Una categoria importante di PSV sono i Problemi Combinatori e
Discreti (PCD). La loro caratteristica principale consiste nel fatto che
le variabili in gioco hanno un dominio costituito da un numero finito
di valori (generalmente numeri interi). Ciò comporta che, essendo le
25
Problemi di soddisfacimento di vincoli
variabili a loro volta in numero finito, esiste un numero finito di
possibili combinazioni di valori. Ad esempio date n variabili, se i loro
domini hanno cardinalità d, il numero di possibili combinazioni tra le
quali cercare quelle che soddisfano i vincoli, cioè quelle ammissibili,
sarà pari a dn, e quindi esponenziale nella dimensione dell’istanza del
problema, che generalmente viene indicata proprio con il numero delle
variabili. Questo fatto, insieme con l’impossibilità di utilizzare per la
soluzione i metodi tipici dell’analisi matematica, ha come conseguenza
che la gran parte dei PCD sono NP-completi, cioè in sostanza
richiedono una enumerazione esplicita o implicita di tutte le
combinazioni di valori per selezionare quelle ammissibili [Guidotti et
al., 1994].
Nell’ambito del PCD la ricerca operativa pone particolare attenzione ai
Problemi di Ottimizzazione Combinatoria (POC) che consistono in
PCD per i quali l’obiettivo non è trovare una o più soluzioni
ammissibili, ma trovare la migliore secondo una certa funzione (detta
funzione obiettivo) costruita sulle variabili e che in sostanza associa ad
ogni possibile combinazione, un numero reale (ad esempio un costo
totale o un profitto totale). Risolvere un POC corrisponderà a trovare la
combinazione ammissibile cui corrisponde il valore massimo o quello
minimo a seconda del significato attribuito a tale valore. Esempi di
POC sono la programmazione lineare usata per trovare delle soluzioni
ottime per un gruppo di equazioni lineari simultanee ed il metodo del
simplesso.
I POC compaiono frequentemente in campo industriale, ad esempio
per stabilire come impiegare in maniera ottima risorse discrete quali
26
Problemi di soddisfacimento di vincoli
macchinari o persone, per determinare produzioni anch’esse discrete e
con quantità limitate non considerabili approssimativamente continue
oppure per determinare la sequenza di lavorazione ottima per parti che
richiedono le stesse risorse in quantità diverse tra loro. Altre tipiche
applicazioni scaturiscono dai problemi di scheduling come, ad
esempio, l’assegnamento di un certo numero di processi ai processori
disponibili in modo da ottenere il massimo throughput possibile.
Vista l’elevata complessità computazionale dei PCD è necessario
ottimizzare ogni singolo aspetto della tecnica di soluzione e occorre
unire competenze di tipo matematico e di tipo informatico per evitare
la realizzazione di un algoritmo poco efficiente. Come si può intuire,
tutto questo costa molto in termini di risorse umane impiegate,
cosicchè nella pratica, può essere preferibile rinunciare ad una
implementazione efficiente ma costosa in favore di una meno
efficiente ma più rapida da realizzare, visto che il tempo macchina oggi
costa molto meno del tempo uomo.
I Linguaggi di Programmazione a Vincoli (LPV) hanno come obiettivo
quello di consentire il rapido sviluppo di soluzioni compatte per i PSV.
Lo scopo primario è quello di consentire all’utente di descrivere gli
oggetti del proprio dominio applicativo insieme ad una collezione di
vincoli su di essi espressa normalmente in forma relazionale. In questo
modo la progettazione della soluzione ad un PSV si traduce nella
individuazione delle relazioni tra gli oggetti nel dominio affidando alla
macchina il calcolo dei valori che assicurano la consistenza.
27
Problemi di soddisfacimento di vincoli
La forma relazionale intrinseca alla Programmazione Logica (PL),
rende questo paradigma particolarmente adatto alla espressione dei
vincoli che sono relazioni fra oggetti. Inoltre il non-determinismo della
PL costituisce un potente strumento concettuale per il progetto di
programmi capaci di ricerche autonome in uno spazio di soluzione.
Molti sforzi sono stati fatti per estendere le basi teoriche della PL in
modo da includere concetti e meccanismi per il soddisfacimento di
vincoli specifici di domini quali booleani, reali, discreti, estendendo il
concetto di unificazione.
2.2.
Tecniche di soluzione per problemi combinatori e
discreti
Le tecniche di soluzione che comunemente si utilizzano sono tutte
basate
sull’uso
di
un
albero
decisionale
per
organizzare
l’enumerazione delle combinazioni. Date n variabili x1, x2,......,xn con
dominio rispettivamente D1, D2,......, Dn, sottoposte ad un insieme V di
vincoli, un possibile procedimento di ricerca della soluzione consiste
nell’assegnare un valore alle variabili una dopo l’altra, verificando ad
ogni assegnamento, che il valore attribuito sia compatibile, secondo i
vincoli, con quelli attribuiti alle variabili già assegnate. Se ciò non è
vero, si sceglie un altro valore, e se non se ne trova nessuno, si esegue
un
backtracking
sulla
variabile
precedente,
cioè
si
revoca
l’assegnamento eseguito in precedenza su di esso effettuandone un
altro con un valore diverso. Situazioni come queste vengono denotate
28
Problemi di soddisfacimento di vincoli
con il nome di fallimenti, in quanto un tentativo di assegnamento alle
variabili si rivela infruttuoso, cioè non porta ad alcuna soluzione
ammissibile. Questa tecnica viene detta Standard Backtracking. Si può
notare come l’assegnamento di una variabile venga visto come una
decisione che può anche rivelarsi errata, e pertanto venga prevista la
possibilità di doverla modificare in futuro. Il modo migliore per gestire
questa tecnica è utilizzare un albero decisionale esplorandolo con una
strategia di tipo depth first (in profondità).
Il problema fondamentale che si pone con questa tecnica è il seguente:
se i fallimenti vengono scoperti molto in profondità nell’albero
decisionale, viene esplorato un grande sottoalbero prima di effettuare
un altra scelta per la variabile. Essa rivela la sua incapacità ad
utilizzare intelligentemente i vincoli [Guidotti et al., 1994].
Una alternativa può essere quella di propagare gli assegnamenti
eseguiti alle variabili ancora da istanziare, utilizzando i vincoli in
maniera attiva. Questo corrisponde ad escludere dai domini delle
variabili non ancora istanziate quei valori che non sono compatibili
con le variabili già assegnate. Si parla in tal caso di Forward Checking
in quanto si opera un controllo preventivo sulle variabili. Questo modo
di operare viene anche denotato con il nome di Tecnica della
Consistenza [Van Hentenrick, 1989] in quanto corrisponde ad operare
scelte che siano consistenti con le decisioni già intraprese, consentendo
di scoprire il prima possibile le cause dei fallimenti per evitare di
incorrervi.
29
Problemi di soddisfacimento di vincoli
Un’altra tecnica di consistenza è nota col nome di Looking Ahead, che
utilizza una riduzione dei domini più sofisticata. Similmente alla
tecnica Forward Checking, oltre all’esclusione dei valori non
compatibili con gli assegnamenti già eseguiti, per il dominio di ogni
variabile non ancora istanziata e per ogni valore rimasto in esso, viene
controllata l’esistenza, nei domini delle altre variabili non ancora
istanziate, di almeno un valore compatibile. Se ciò non avviene, il
valore viene escluso dal dominio. La tecnica Looking Ahead è
caratterizzata da una maggiore probabilità di scoprire anticipatamente i
fallimenti, ma ha come conseguenza un notevole aumento del carico
computazionale rispetto al Forward Checking, per questo la tecnica
Looking Ahead non è molto usata [Guidotti et al., 1994].
Si è parlato in precedenza della necessità di scoprire i fallimenti in
anticipo. E’ però possibile agire in modo che questi fallimenti si
presentino il più presto possibile. Secondo il principio del First Fail è
conveniente eseguire per prime quelle scelte che hanno maggiore
probabilità di fallire. In altre parole conviene esplorare per prima la
parte più vincolata dello spazio di ricerca della soluzione. Un modo per
farlo può esserre assegnare per prime le variabili che hanno il dominio
più piccolo, utilizzando quindi un ordine di assegnamento delle
variabili stabilito dinamicamente durante la ricerca della soluzione, in
base alle scelte eseguite ed alle conseguenti riduzioni dei domini [Van
Hentenrick, 1989]. L’applicazione di questo metodo porta in generale
ad un miglioramento dell’efficienza della soluzione.
Le tecniche Forward Checking e First Fail hanno la capacità di guidare
l’esplorazione all’interno dello spazio di ricerca della soluzione in
30
Problemi di soddisfacimento di vincoli
modo da rimanere “vicini” alle soluzioni ammissibili, senza perdersi in
esplorazioni di sottospazi improduttivi.
Una volta determinate tutte le soluzioni ammissibili, se l’obiettivo è
quello di ricercare la soluzione ottima, una delle tecniche usate è quella
del Branch and Bound che è caratterizzata da due fasi: il branching
che equivale alla generazione dell’albero decisionale, ed il bounding
che consiste nella limitazione dell’albero stesso, cioè nella
eliminazione preventiva di sottoalberi improduttivi.
2.3.
L’implementazione software
Una volta definita la tecnica per una soluzione efficiente del problema
in esame, nasce la questione di come realizzare il software che lo
implementa. I principali problemi sono:
la gestione dell’albero decisionale;
la gestione delle elaborazioni locali al nodo che coinvolgono i
vincoli e le variabili non ancora istanziate.
L’approccio di implementazione attualmente più utilizzato consiste
nello scrivere il software usando un linguaggio imperativo (descrive
per passi come costruire una soluzione, strettamente legato
all’architettura di Von Neumann). In particolare, in Ricerca Operativa
si utilizzano soprattutto il Fortran ed il C, per motivazioni molteplici:
31
Problemi di soddisfacimento di vincoli
1. disponibilità di compilatori molto efficienti su qualsiasi tipo
di macchina, in grado di assicurare uno sfruttamento ottimale
dell’hardware e quindi elevate prestazioni;
2. portabilità del codice;
3. disponibilità di un notevole numero di librerie;
4. massima libertà nella scrittura del codice.
Ci si rende conto però di come i problemi realizzativi elencati in
precedenza pongano grandi difficoltà se affrontati con un linguaggio
imperativo. Supponendo di scrivere del codice per la gestione di un
albero utilizzando il Fortran, l’implementazione risulterà certamente
complessa poichè si hanno a disposizione solo array e contatori e non
si può usufruire della ricorsione.
Sebbene l’utilizzo di un linguaggio imperativo permetta elevate
prestazioni del software prodotto, si deve pagare un prezzo molto alto
in termini di sviluppo e di debugging. Inoltre l’aggiornamento del
codice, ad esempio in seguito ad una modifica intervenuta nel modello
del problema da risolvere, come l’aggiunta o la eliminazione di un
certo numero di vincoli, può risultare proibitiva in quanto spesso
sconvolge l’intera struttura del codice stesso.
Si può quindi affermare che un linguaggio imperativo non rappresenta
uno strumento ideale per l’implementazione di software per la
soluzione di PCD.
Una alternativa concreta ai linguaggi tradizionali è rappresentata dai
linguaggi di Programmazione Logica ed in particolare dal Prolog. Le
32
Problemi di soddisfacimento di vincoli
caratteristiche fondamentali che rendono la Programmazione Logica
un linguaggio naturale per l’implementazione dei PCD sono le
seguenti:
la forma relazionale che permette di dicharare i vincoli in
maniera molto chiara, essendo i vincoli delle relazioni tra
variabili;
il non determinismo che libera l’utente dal compito di
programmare la gestione dell’albero decisionale.
La semantica dichiarativa tipica della Programmazione Logica
permette di produrre codici compatti, leggibili e di facile
manutenzione, permettendo un notevole risparmio in termini di tempi
di sviluppo. Queste potenzialità giustificano il grande interesse che
gravita attualmente intorno all’applicazione della programmazione
logica nel settore dei PCD e in quello più generale dei PSV dando
luogo ad una specifica classe di linguaggi detti di Programmazione
Logica a Vincoli, (tra i quali il linguaggio Chip) che raggruppa quelle
estensioni
del
Prolog
che
forniscono
strumenti
linguistici
appositamente studiati per le esigenze dei problemi con vincoli.
Un aspetto particolarmente critico di questi linguaggi è costituito dal
compromesso tra la flessibilità degli strumenti che mettono a
disposizione per l’approccio a certe classi di problemi e l’efficienza
degli stessi. Generalmente questi due aspetti (flessibilità ed efficienza)
sono in contraddizione fra loro, nel senso che una maggiore flessibilità
viene pagata con una minore efficienza di soluzione.
33
Problemi di soddisfacimento di vincoli
La Programmazione Logica in genere e quella a vincoli in particolare,
si rivela comunque un valido strumento di studio di algoritmi per
problemi di ottimizzazione combinatoria, grazie ai rapidi tempi di
sviluppo che permette.
E’ interessante notare una caratteristica importante della soluzione
Prolog, che può dare la misura della potenza di questo approccio:
utilizzando lo stesso programma è possibile proporre al sistema una
soluzione per sapere se è ammissibile oppure no. E’ anche possibile
proporre un assegnamento parziale per sapere in che modo possa
essere completato. Per ottenere queste ultime due funzioni utilizzando
un linguaggio imperativo sarebbe necessario scrivere delle procedure
apposite. Ciò a ulteriore conferma del fatto che la Programmazione
Logica conferisce alle applicazioni una flessibilità impensabile per la
programmazione imperativa [Guidotti et al., 1994].
2.4.
Applicazione del Prolog alla etichettatura di immagini
Il problema di soddisfacimento di vincoli che riguarda la etichettatura
di immagini (labeling) può essere risolto in molti modi diversi. Esso
può essere formulato mediante un approccio di soddisfacimento dei
vincoli, che consiste in un insieme di variabili e di predicati; la
congiunzione dei quali deve essere soddisfatta dalle variabili
istanziate. Come mostrato in [Mackworth, 1977], utilizzando la
formulazione della logica dei predicati, il problema di soddisfacimento
di vincoli che riguarda l’etichettatura di immagini è simile al problema
34
Problemi di soddisfacimento di vincoli
di fornire una dimostrazione costruttiva della validità di una formula
ben fomata:
(X1) (X2)....(Xn) [P1(X1) P2(X2) ...... Pn(Xn) P12(X1,X2)
P13(X1, X3) ...... Pn-1,n(Xn-1,Xn)]
dove gli Xi sono variabili e Pi, Pij sono rispettivamente vincoli unari e
binari. Una delle cose più interessanti che emerge dalla formulazione
di un problema di AI come un problema di soddisfacimento di vincoli
nella forma suddetta è l’efficienza della procedura di soluzione
[Schalkoff, 1990].
La segmentazione e l’etichettatura di regioni di una immagine
utilizzando il soddisfacimento dei vincoli, è una prova importante della
potenza dichiarativa della programmazione in Prolog, poichè il
problema è posto in termini di necessità dell’utente; il sistema Prolog
determina i passi necessari per raggiungere una etichettatura vincolata.
La etichettatura dell’immagine serve come base per la descrizione di
una immagine, poichè dopo aver determinato l’identità di ogni parte di
essa si è nella posizione di descrivere l’intera immagine sulla base
della natura e delle relazioni interne delle regioni etichettate.
In contrasto ai problemi di soddisfacimento dei vincoli numerici,
l’obiettivo dei problemi di etichettatura in generale è ottenere uno o
più assegnamenti ammissibili di etichette ad insiemi di entità. Sono
definite le seguenti quantità:
35
Problemi di soddisfacimento di vincoli
{
U = {u1, u2, ......,un} è l’insieme degli oggetti che devono essere
etichettati
= {1, 2, ....,n} è l’insieme delle possibili etichette.
In questa formulazione si possono individuare due livelli di
compatibilità:
1. Le compatibilità delle etichette agli oggetti singoli
2. Le compatibilità delle etichette a due o più oggetti correlati.
Una definizione più succinta del problema di etichettatura diventa:
Determinare uno o più mappping tra gli elementi di e quelli
di U tali che i vincoli di compatibilità suddetti siano soddisfatti.
Bisogna notare che dati n oggetti ed m possibili etichette, senza vincoli
si possono avere mn combinazioni possibili [Schalkoff, 1990].
2.4.1. Determinazione dei vincoli
Si cerca di formulare il problema di etichettatura di parti di immagini
come un problema di soddisfacimento dei vincoli. Si considerano solo
due tipi di vincoli, cioè:
36
Problemi di soddisfacimento di vincoli
Vincoli unari o restrizioni su un solo argomento che possono essere
considerate delle proprietà degli oggetti. Ad esempio colore_di(a) è
un esempio di vincolo unario o proprietà dell’oggetto.
Vincoli binari o relazioni, che coinvolgono due entità o argomenti.
Ad esempio adiacente(a,b) è un esempio di questo tipo di vincolo.
Si inizia l’approccio alla etichettatura dell’immagine, con la
determinazione di un numero di vincoli che hanno senso. Questo è
l’aspetto empirico della formulazione del problema; ci sono forse
molte formulazioni (che impiegano differenti vincoli) che portano a
soluzioni soddisfacenti. La determinazione di un insieme di vincoli che
hanno senso implica l’esame della situazione e l’estrazione di vincoli
implementabili basati su caratteristiche estraibili che non violano
l’umana intuizione. Ad esempio in una immagine raffigurante un
paesaggio, raramente il cielo compare nella parte bassa dell’immagine.
Un possibile vincolo binario su una immagine è la regione di
adiacenza, ad esempio “una automobile è adiacente ad una strada”,
oppure un altro possibile vincolo binario è una relazione di
contenimento, ad esempio “una maniglia è contenuta in una porta”.
Determinati i vincoli è necessaria una appropriata formulazione in
Prolog di essi. In particolare è necessario rappresentare questi vincoli
mediante dei predicati e soddisfare la congiunzione dei vincoli che
coinvolgono le variabili.
37
Problemi di soddisfacimento di vincoli
Il database Prolog conterrà delle clausole ground (una clausola si dice
ground quando in essa non compaiono variabili libere). che
incorporano i vincoli, ad esempio:
adiacente(automobile, strada).
adiacente(strada, alberi).
adiacente(alberi, cielo).
Si può vedere il problema di soddisfacimento dei vincoli, come la
ricerca di legami adatti (assegnamenti di etichette) sulle variabili. Il
goal (obiettivo definito cioè una formula esistenziale con una
congiunzione di letterali) su questo database è formato da una
congiunzione di clausole che coinvolgono il predicato adiacente, ad
esempio:
adiacente(R1,R2),
adiacente(R2,R3).
Una etichettatura valida sarà l’istanziazione di queste variabili con
valori (etichette) tali che la congiunzione di queste clausole sia vera,
cioè soddisfacibile attraverso il meccanismo dell’unificazione.
L’insieme dei risultati a tutte le possibili unificazioni del goal suddetto
con il database è dato da:
La regione 1 è istanziata a
La regione 2 è istanziata a
La regione 3 è istanziata a
automobile
strada
alberi
La regione 1 è istanziata a
strada
38
Problemi di soddisfacimento di vincoli
La regione 2 è istanziata a
La regione 3 è istanziata a
alberi
cielo
Per ottenere questo risultato sono state aggiunte altre clausole al goal:
write(‘La regione 1 è istanziata a
write(‘La regione 2 è istanziata a
write(‘La regione 3 è istanziata a
’), write(R1), nl,
’), write(R2), nl,
’), write(R3), nl,fail.
L’operazione del predicato write ha l’effetto collaterale di indicare un
insieme di legami sulle variabili. Si deve notare che il sistema Prolog,
a causa dell’ordine in cui avviene l’unificazione, deve aver raggiunto il
successo prima di incontrare i predicati write, così non si verifica il
problema di stampare i valori delle variabili non istanziate.
Interessante è l’uso del predicato fail: esso è un predicato predefinito
in Prolog e valutato sempre falso. Incorporando il predicato fail come
ultimo predicato nel goal si forzano tutti i possibili backtracking e
conseguentemente la generazione di tutte le unificazioni possibili
[Schalkoff, 1990].
39
Un sistema di visualizzazione di dati in realtà virtuale.
Capitolo terzo
3.
Un sistema di visualizzazione di dati in realtà
virtuale
3.1.
Introduzione
Le interfacce visuali possono aiutare anche l’utente inesperto a
formulare query restituendo una grande quantità di informazione
strutturata. Quando il database sorgente contiene molte relazioni
semantiche e molti vincoli, l’insieme dei dati che rappresentano
l’intero risultato della query possono essere composti da molti oggetti
disposti in differenti livelli di nesting.
Per fornire agli utenti uno strumento efficace di esplorazione, i sistemi
di visualizzazioni di database devono avere le seguenti caratteristiche:
rappresentare un grande numero di oggetti complessi e le relazioni
semantiche tra di loro [Goldstain, 1994];
visualizzare sia attributi standard che attributi multimediali;
permettere agli utenti di esplorare un sottoinsieme dell’intero
insieme di dati risultante dalla query.
40
Un sistema di visualizzazione di dati in realtà virtuale.
I metodi di visualizzazione in 3D possono essere utilmente adottati per
organizzare grandi insiemi di oggetti. Sono efficaci le visualizzazioni
ad occhio di pesce (fish eye view) [Sarkar et al., 1994] poichè gli utenti
possono focalizzare l’attenzione su piccole parti dell’intero insieme di
dati senza perdere di vista il contesto. Inoltre gli ambienti in 3D
possono facilmente rappresentare sia dati alfanumerici che dati
multimediali, come immagini e video.
Le tecniche di visualizzazione in realtà virtuale permettono di
combinare i vantaggi delle visualizzazioni in 3D con la potenza delle
rappresentazioni metaforiche. Disponendo i dati del risultato della
query in scene virtuali, gli utenti sono facilitati nella esplorazione dei
dati poichè essi interagiscono con oggetti familiari. Sia il
comportamento del sistema che le proprietà strutturali degli oggetti in
un mondo virtuale, i.e. il modo in cui gli oggetti possono essere
composti,
sono
completamente
conosciuti
proprio
perchè
appartengono al background generale degli utenti. Di conseguenza è
più facile interagire ed esplorare l’insieme dei dati.
3.2.
Il sistema Virgilio
Virgilio è un sistema che genera visualizzazioni di oggetti complessi
che rappresentano il risultato di una query ad una generica base di dati
[Massari et al., 1997; Costabile et al., 1998]. Le rappresentazioni che
genera sono a realtà virtuale non immersiva cioè l’interazione tra
l’utente ed il mondo virtuale avviene tramite i normali dispositivi di
41
Un sistema di visualizzazione di dati in realtà virtuale.
input/output con i quali l’utente interagisce normalmente con il
calcolatore ad esempio tastiera, mouse o joystick (si veda il capitolo 1
per ulteriori dettagli).
In opposizione ad altri sistemi, esso è stato pensato per essere un
sistema general purpose per l’esplorazione di dati altamente strutturati
dove sia il dominio del database che la query dell’utente sono
considerati parametri esterni. Inoltre Virgilio è basato su concrete
metafore (i.e. metafore in cui il dominio visuale è composto da oggetti
presi dalla vita quotidiana dell’utente), in modo da aver vantaggio
dalla conoscenza degli oggetti del mondo reale riducendo così il carico
cognitivo nel processo di assimilazione dell’informazione.
Il sistema automaticamente definisce un mapping [Haber et al, 1994],
tra gli oggetti dell’insieme di dati e gli oggetti di qualche mondo
virtuale. Per permettere una appropriata visualizzazione dei dati tale
mapping deve seguire delle regole precise:
1. la struttura del risultato della query deve essere preservata, i.e. le
aggregazioni (tuple, set, sequenze) derivate dallo schema del
database devono essere mantenute nelle scene virtuali;
2. ogni dato del risultato della query deve avere un supporto fisico per
la sua visualizzazione;
3. gli oggetti virtuali scelti devono essere adatti a rappresentare il tipo
di dato che deve essere visualizzato (e.g. un oggetto “portaritratto” è
adatto per il tipo di dato immagine);
42
Un sistema di visualizzazione di dati in realtà virtuale.
4. devono essere considerate anche regole di visualizzazione che
garantiscono che attributi discriminanti sono visualizzati nel posto
giusto per permettere una esplorazione efficace dei dati. Per esempio
se un piano di un edificio rappresenta le informazioni relative ad un
tipo di musica, il piano deve contenere l’informazione sul tipo di
musica selezionato (un cartello o un poster).
Virgilio accetta come input l’insieme dei dati risultante da una query
su generiche basi di dati e crea una rappresentazione visuale composta
di una collezione di scene scritte in VRML (VR Modeling Language)
[Guglielmi et el., 1996]. Il sistema usa una libreria di oggetti del
mondo reale (ad esempio nel mondo virtuale “palazzo” gli oggetti
possono essere stanze, tavoli, ritratti ecc.) che include il loro aspetto
visuale, i tipi di dati che essi possono supportare (ad esempio, un
portafotografie è capace di visualizzare una foto o una immagine, un
foglio o un libro possono visualizzare testo scritto, stringhe ecc.) così
come relazioni di contenimento tra coppie di oggetti del tipo “A
contiene B” e/o “B è contenuto in A”. Virgilio lavora nel seguente
modo:
i valori degli attributi dei dati risultanti dalla query sono visualizzati
su oggetti del mondo virtuale secondo la capacità di questi oggetti di
rappresentare l’appropriato tipo di dato;
le relazioni semantiche tra gli oggetti nell’insieme dei dati che
costituiscono il risultato della query sono rappresentate usando
relazioni di contenimento.
43
Un sistema di visualizzazione di dati in realtà virtuale.
Le caratteristiche principali di Virgilio sono: 1) è parametrico rispetto
al database esplorato; 2) produce automaticamente una vista orientata
all’utente dei dati; 3) descrive i dati visualizzati attraverso il
linguaggio VRML [Guglielmi et al., 1996].
Un’altra rilevante caratteristica del sistema Virgilio è la possibilità di
usarlo come una applicazione client-server sulla rete. Le scene del
mondo virtuale sono memorizzate in formato VRML e l’utente finale
può accedere al sistema utilizzando un comune browser che supporta il
VRML [Guglielmi et al., 1996].
Sono stati condotti numerosi studi su sistemi di visualizzazioni di
database, ma essi generalmente non determinano un approccio
generale al problema. Alcuni sistemi forniscono all’utente interfacce
per esplorare insiemi di dati in uno specifico dominio applicativo (e.g.
dati statistici [Meo-Evoli et al., 1994] o database di documenti
[Hemmje et al., 1994]; altre strategie di visualizzazione (e.g. starfield
display descritto in [Alberg et al., 1994]) sembrano adattarsi meglio
per la visualizzazione di insiemi di oggetti piatti con poche relazioni
semantiche. Altri sistemi (e.g. LyberWorld [Hemmje et al., 1994])
usano
tecniche
di
visualizzazione
in
3D
per
rappresentare
l’informazione per mezzo di metafore astratte, dove gli oggetti da un
mondo astratto (e.g. coni e sfere) sono usati per comporre
rappresentazioni visuali dell’insieme di dati esplorato.
44
Un sistema di visualizzazione di dati in realtà virtuale.
3.3.
Uso di metafore in Virgilio
Il significato letterale di “metafora” (dal greco ‘metaphorein’) è
trasferire o trasportare. Uno dei più importanti aspetti della metafora è
che essa dà la possibilità di capire concetti nuovi e complessi
attraverso concetti più familiari. La definizione data da Lakoff e
Johnson dice che “una metafora è una figura retorica, la cui essenza è
capire e sperimentare un tipo di cose in termini di un altro” [Lakoff,
1980]. Per cui una metafora dà la possibilità di andare da concetti
familiari (i.e. ben-conosciuti) verso concetti sconosciuti, incorporando
così nuova conoscenza nei vecchi. Spesso, per introdurre un nuovo
concetto, lo si presenta in relazione ad un altro ben conosciuto,
semplificando così il processo di apprendimento. Ad esempio, il
modello dell’atomo è generalmente presentato con riferimento alla
struttura del sistema solare.
Alcune volte, la metafora è usata per fornire una rappresentazione
concreta di un concetto astratto (ad esempio, “quell’uomo è pauroso
come un coniglio!”; o ancora “questo luogo è freddo come una
Siberia!”). Nel campo dell’interazione utente-calcolatore, le metafore
sono state spesso usate per sfruttare la conoscenza che l’utente ha di
particolari domini della vita reale. Ad esempio, l’organizzazione del
sistema operativo per stazioni di lavoro personali usa la metafora della
scrivania, data la familiarità che l’utente ha con l’organizzazione di un
ufficio; le azioni sono basate su comportamenti tipici in un ufficio.
Sullo schermo viene presentata la visualizzazione della scrivania di un
ufficio, le varie informazioni (files, documenti) sono contenute in
45
Un sistema di visualizzazione di dati in realtà virtuale.
cartelle (che rappresentano le directory), la cancellazione di un file
avviene gettandolo, o meglio “trascinandolo” nel cestino, la stampa di
un documento con un doppio click sull’icona della stampante, ecc. Un
altro esempio è l’organizzazione di un programma di calcolo
elettronico che usa la metafora del foglio di calcolo strutturato in
forma matriciale di righe e colonne [Carrol et al., 1988].
E’ possibile individuare in ogni metafora due insiemi di concetti,
precisamente concetti sorgente e concetti destinazione [Martin, 1990].
I concetti destinazione sono i nuovi concetti da presentare, i concetti
sorgente sono quelli attraverso i quali i concetti destinazione sono
presentati. Formalmente le metafore sono rappresentate come insiemi
di associazioni, tra concetti sorgente e concetti destinazione. La
metafora specifica come i concetti sorgente corrispondono ai vari
concetti destinazione. Essa stabilisce un mapping tra il dominio
sorgente e il dominio destinazione.
La metafora è considerata uno strumento fondamentale nel progetto di
interfacce creative poichè fornisce all’utente un ambiente familiare con
cui lavorare [Mountford, 1990; Erickson, 1990]. E’ noto che una
metafora ideale non esiste, ma è estremamente importante scegliere la
metafora appropriata in accordo con la particolare situazione. Alcune
linee guida sul progetto delle metafore sono date in [Marcus, 1994;
Madsen, 1994]. Nelle interfacce per database, le metafore sono state
sfruttate per rappresentare la parte intensionale del database, cioè lo
schema dei dati; in questi casi la metafora è il mediatore tra il modello
dei dati e l’utente [Haber, 1994; Catarci et al., 1995]. La maggior parte
46
Un sistema di visualizzazione di dati in realtà virtuale.
degli utenti finali lavorano con la parte estensionale del database,
perciò è più appropriato offrire loro uno scenario dove l’informazione
contenuta nel database è metaforicamente rappresentata in un ambiente
RV, i.e. in un mondo virtuale, così che l’utente non è piu’consapevole
della presenza di un dabase strutturato, ma interagisce come nel mondo
reale.
La definizione di una “buona” metafora può essere un compito difficile
perchè è necessario prendere in considerazione un certo numero di
problemi, come:
Familiarità degli utenti con il mondo virtuale scelto. Ad esempio,
un utente che appartiene alla classe dei marinai, avrà familiarità con
il mondo delle navi mentre non avrà familiarità con il mondo degli
uffici.
Storia delle precedenti interazioni degli utenti con altre metafore.
Estremamente importante per la definizione di una metafora adatta
sarà la consistenza del mapping rispetto alla metafora utilizzata
precedentemente dall’utente. Per far fronte a questo problema gli
strumenti per la definizione di una metafora dovrebbero mantenere
una storia interna delle interazioni con gli utenti finali.
Vincoli
derivanti
da
un
particolare
background
culturale
dell’utente. In un mondo virtuale di un edificio scuola, ad esempio,
un utente appartenente alla classe degli insegnanti non accetterebbe
di vedere l’oggetto virtuale “video gioco” su un oggetto virtuale
47
Un sistema di visualizzazione di dati in realtà virtuale.
“banco di una classe”. Al contrario lo stesso mapping potrebbe
essere accettato da un utente di tipo studente.
La query attesa che l’utente vuole vedere sul sistema. Sarebbe
importante anche cercare di prevedere le richieste future dell’utente
in modo da permettere, in futuro, l’aggiunta di nuovi oggetti nelle
scene senza dover ricostruire completamente il nuovo mondo
virtuale.
Molti autori e progettisti dimostrano l’efficienza di una metafora per
mezzo di test di usabilità [Marcus, 1994; Carroll, 1988]. Essi
sottopongono una metafora ad un gruppo selezionato di differenti
utenti, studiando ed esaminando il risultato con tecniche di statistica.
Allo stato attuale non sono stati ancora fatti esperimenti formali per
valutare l’usabilità di Virgilio.
Per meglio individuare una metafora efficace potrebbe essere utile
prendere in considerazione il modello utente [Chang et al., 1993;
Catarci et al. 1996]. Una metafora è certamente più efficiente se essa è
adatta alle necessità ed alle attitudini dell’utente.
Virgilio è un sistema che supporta la definizione di una metafora come
un mapping tra i dati nel risultato di una query ad un database e gli
oggetti in un mondo virtuale. Molte metafore sono disponibili nel
sistema così che possono essere generati differenti mapping tra uno
stesso insieme di dati, che rappresentano il dominio destinazione, e
differenti mondi virtuali ognuno dei quali rappresenta il dominio
sorgente in modo da presentare all’utente l’ambiente più efficace per le
48
Un sistema di visualizzazione di dati in realtà virtuale.
sue aspettative. Uno dei mondi virtuali utilizzati in Virgilio è un
“palazzo” con una entrata principale che porta ad un ascensore che
contiene una pulsantiera. Ogni tasto ha una etichetta che può
identificare il piano da raggiungere. Il piano contiene un corridoio con
molte stanze; è possibile accedere ad una stanza aprendo una porta che
ha una etichetta su di essa. In una stanza ci sono dei mobili, come
accade nel mondo reale, ad esempio una cassettiera, una libreria
oppure un tavolo su cui può poggiare un album di foto.
3.4.
Architettura di Virgilio
L’intera architettura del sistema Virgilio come descritto in Massari et
al., (1997) è mostrata in Figura 3.1. Le componenti principali sono:
a) tre moduli chiamati Query Management Tool, un Metaphor
Definition Tool ed un Virtual World Object Editor;
b) un repository globale di informazioni che include tre meta database
contenenti le informazioni necessarie a generare le visualizzazioni
cioè il Query Repository, il Virtual World (VW) Object Repository
ed il Metaphor Repository;
c) lo Scene Constructor Server.
Le altre componenti visualizzate nella Figura 3.1 cioè un DBMS (Data
Base Management System) con il database che memorizza le
informazioni a cui gli utenti vogliono accedere, un Web browser ed
49
Un sistema di visualizzazione di dati in realtà virtuale.
una connessione in rete non specificata, sono considerate esterne a
Virgilio. Il database sorgente è un generico database con una struttura
composta da differenti tipi di classi di oggetti, molte relazioni
semantiche e contenente anche dati multimediali.
Q ue ry M anagm e nt
To o l
V irg ilio
M e ta
DB
M e ta p h o r
D e f in itio n T o o l
S y s te m
ad m in is trato r
Q ue ry
R e p o s ito ry
D a ta B a s e
DBMS
M e ta p h o r
R e p o s ito r y
V R O b je c ts
R e p o s ito ry
Scene
C o n s tr u c to r S e r v e r
V irtu al W o rld
O b je c ts e d ito r
w eb
VRML
brow se r
Figura 3.1 Architettura del sistema Virgilio.
Virgilio è stato progettato per essere un ambiente di esplorazione
general pourpose per dati altamente strutturati; esso è capace di
visualizzare grossi insiemi di oggetti con considerevole complessità
interna ed esterna e molte relazioni semantiche, attraverso efficaci
tecniche RV. I dati risultanti dall’esecuzione di una query sono
presentati in un ambiente virtuale in 3D sfruttando appropriate
metafore che si riferiscono ai vari mondi virtuali disponibili in
Virgilio.
50
E nd
U ser
Un sistema di visualizzazione di dati in realtà virtuale.
L’informazione sui mondi virtuali e tutti gli oggetti che essi includono
è memorizzata nel Virtual World Object Repository ed è fornita al
sistema attraverso il Virtual World Object Editor. Il Query Repository
memorizza sia la query eseguita che l’insieme dei dati che
costituiscono il risultato della query, informazioni necessarie per il
processo di definizione della metafora e la costruzione della scena
virtuale.
Per “definizione della metafora” si intende la definizione del mapping
tra gli oggetti nel database e gli oggetti nel mondo virtuale, che sono
scelti tra quelli disponibili nel sistema. Questo compito è svolto dal
Metaphor Definition Tool, e l’informazione su questo mapping è
memorizzata nel Metaphor Repository. La scena virtuale è generata
dallo Scene Constructor Server sulla base delle informazioni
memorizzate nei vari repository.
Come mostrato in Figura 3.1 due differenti classi di utenti possono
interagire con il sistema Virgilio:
gli utenti finali (utenti inesperti);
gli amministratori del sistema (utenti esperti).
Gli utenti finali interagiscono con Virgilio recuperando scene in 3D ed
effettuando l’esplorazione di informazione incapsulata attraverso un
browser VRML. Similmente ad una applicazione standard client-server
eseguita sul Web, una tipica interazione tra Virgilio e l’utente finale è
la seguente: l’utente inizia ad esplorare una scena RV contenente
51
Un sistema di visualizzazione di dati in realtà virtuale.
informazioni di interesse; quando decide di navigare in un altra scena
di un mondo virtuale, un messaggio è inviato a Virgilio, che in
risposta, effettua la query sul database sorgente ottenendo dei dati
“grezzi” i quali vengono incastrati in una scena virtuale che verrà
visualizzata sullo schermo, e così via.
Nell’architettura proposta in Massari et al. (1997), l’utente finale
accedeva al sistema effettuando una query in linguaggio naturale
mentre l’amministratore del sistema era un intermediario fondamentale
tra l’utente ed il sistema, poichè eseguiva tre importanti compiti:
1. definizione delle query in accordo alle necessità dell’utente;
2. specifica di un insieme appropriato di visualizzazioni RV di
tali query attraverso la definizione di un mapping (o metafora)
tra i dati nel risultato della query e gli oggetti di un mondo
virtuale;
3. definizione di nuovi oggetti virtuali specificando sia il loro
aspetto visuale che le relazioni di contenimento con gli altri
oggetti.
Il compito di definizione di una query su un database sarà eseguito
attraverso un qualsiasi sistema di interrogazione visuale general
pourpose.
Se si vuole che Virgilio diventi un sistema per effettuare le query su un
generico database e per effettuare l’esplorazione del risultato della
query, si dovrebbero automatizzare i primi due compiti, così che non
sia necessario nessun intermediario nel dialogo tra l’utente finale e il
sistema. Il terzo compito è l’unico che va oltre le capacità di un utente
52
Un sistema di visualizzazione di dati in realtà virtuale.
finale; la definizione di un nuovo mondo virtuale attraverso la
specifica di tutti i suoi oggetti con i loro attributi è un compito
complicato che deve essere fatto off line da una squadra di progettisti
specializzati. I nuovi oggetti virtuali sono dati in input al sistema
attraverso il Virtual World Object Editor, e memorizzati nel Virtual
World Object Repository, così che essi saranno accessibili dal
Metaphor Definition Tool e dallo Scene Constructor Server.
3.5.
Architettura del Query Management Tool
Il lavoro di questa tesi ha riguardato essenzialmente lo sviluppo di due
principali
componenti
dell’architettura
di
Virgilio:
il
Query
Management Tool la cui architettura è dettagliata in Figura 3.2, ed il
Metaphor Definition Tool.
Oltre ad una Visual Query Interface, i moduli più importanti sono lo
Structure Tree Generator e il Query Prolog Generator. Il primo prende
in input una espressione SQL (Structured Query Language, [Elmasri &
Navate, 1989]) calcola il risultato interrogando il database, trasforma il
risultato in una nested relation attraverso l’analisi della struttura della
query SQL e genera il corrispondente structure tree. Questo compito è
eseguito attraverso l’uso di due strumenti appropriati per la
trasformazione di input strutturato, cioè Flex e Bison (si vedano le
sezioni 4.5 e 4.6 per ulteriori dettagli) che sono le evoluzioni dei ben
noti Lex e Yacc [Levine et al., 1992]. Flex è usato per implementare
uno Scanner per le query SQL, mentre Bison è applicato per costruire
il corrispondente Parser.
53
Un sistema di visualizzazione di dati in realtà virtuale.
S tr u c tu r e
T re e
P a rse r
Q ue ry
R e p o s ito r y
T oken
V is u a l
Q ue ry
I n te r f a c e
SQ L
Q ue ry
Scanner
S tr u c tu r e
T re e
S tru c tu re T re e G e n e rato r
N e s te d
R e la tio n
P r o lo g
Q ue ry
Q ue ry
P r o lo g
G e n e r a to r
O p e r a tio n a l
D a ta B a s e
Figura 3.2 Architettura del Query Management Tool.
Ogni volta che una sequenza di token in input corrisponde ad una delle
regole nella grammatica della query SQL, è intrapresa una azione. Le
azioni riguardano la selezione delle relazioni e degli attributi coinvolti
nella query, l’identificazione degli attributi di Join, e la nidificazione
basata sulla clausola ORDER BY. Lo structure tree che rappresenta la
nested relation è dato in input al Prolog Query Generator che trasforma
lo structure tree in una Query Prolog che sarà utilizzata per il processo
di mapping (si veda il capitolo 5).
Il modulo Query Prolog Generator prende in input la nested relation,
poichè la query Prolog deve includere informazioni sulla cardinalità
delle relazioni che compongono la nested relation. Infine la query
Prolog è memorizzata nel Query Repository.
54
Un sistema di visualizzazione di dati in realtà virtuale.
La descrizione dello Structure Tree Generator è riportata nel capitolo
4.
55
Generazione dello structure tree.
Capitolo quarto
4.
Generazione dello structure tree
4.1.
Introduzione
In questo capitolo si descrive la realizzazione dello Structure Tree
Generator ed il processo che produce, da una query ad un database, lo
structure tree [Massari et al., 1997]. Lo Structure Tree Generator
prende in input una query SQL, calcola il risultato interrogando il
database, trasforma il risultato in una nested relation attraverso
l’analisi della struttura della query SQL e genera il corrispondente
structure tree. Questo compito è eseguito attraverso l’uso di due
strumenti appropriati per la trasformazione di input strutturato, cioè
Flex e Bison che sono le evoluzioni dei ben noti Lex e Yacc [Levine et
al., 1992]. Flex è usato per implementare uno Scanner (analizzatore
lessicale) per le query SQL, mentre Bison è applicato per costruire il
corrispondente Parser (analizzatore sintattico).
La query iniziale è data in input a Virgilio attraverso una Visual Query
Interface, la cui analisi va oltre lo scopo di questa tesi (si veda [Catarci
et al., 1997] per esempi di Visual Query Interface). Una tale interfaccia
56
Generazione dello structure tree.
traduce una query visuale in una query SQL che può essere manipolata
da un qualunque DBMS relazionale.
Il lavoro di questa tesi considera come input la query SQL che risulta
dalla traduzione della query dell’utente formulata mediante una
interfaccia visuale.
4.2.
Definizione di structure tree
Generalmente i dati che compongono il risultato della query hanno una
struttura complessa come le primitive permesse dal modello del
database. Ad esempio, nel modello relazionale, il risultato di una query
assumerà la forma di una relazione. Se il modello del database
permette l’espressione di vincoli (e.g. vincoli di cardinalità per la
partecipazione degli oggetti nelle relazioni) la struttura del risultato
della query può assumere una forma più complessa.
Nella struttura operativa di Virgilio (si veda la Figura 3.1) sarà
considerato un modello di DB più ricco del modello relazionale.
Virgilio opera con quei modelli che possono supportare, direttamente o
indirettamente, il concetto di nested relation (e.g. modelli semantici,
modelli object-oriented o modelli relazionali estesi [Atzeni & De
Antonellis, 1993]).
Informalmente una nested relation è un insieme di tuple tali che i
valori degli attributi possono essere essi stessi delle nested relation. Le
nested relation organizzano l’informazione in una struttura gerarchica,
57
Generazione dello structure tree.
che può essere rivelata anche nel risultato della query. In questo
contesto, si può dire che Virgilio è un sistema RV per la
visualizzazione e la esplorazione di nested relation in accordo col
paradigma di esplorazione.
Naturalmente, quando Virgilio opera su modelli relazionali estesi, il
risultato della query è una nested relation. Tuttavia, quando la query
visuale è trasformata in una standard query SQL, il risultato è una
relazione piatta, che non può essere esplorata. In questo caso, è
possibile applicare l’operatore “nest” che produce relazioni innestate a
partire da relazioni piatte [Atzeni & De Antonellis, 1993]. Ad esempio,
si consideri una query SQL che riguarda un database contenente
informazioni su CD musicali, cantanti, tipi di musica e canzoni ed
alcune relazioni tra queste entità. La Figura 4.1 mostra il
corrispondente diagramma E-R; si può notare che una parte
considerevole
dell’informazione
memorizzata
nel
database
è
multimediale.
Query 1:
SELECT musicType.name, musicType.notes, band.name, band.photo,
album.title, album.cover, song.title
FROM
musicType, band, album, song , tipicSings, contained, published
WHERE album.code=contained.albumCode AND
tipicSings.bandCode=band.code AND
album.code=published.albumCode AND
band.code=published.bandCode AND
song.code=contained.songCode AND
tipicSings.musicName= musicType.name
58
Generazione dello structure tree.
ORDER BY musicType.name, band.name, album.title;
Il risultato della query è una relazione piatta che può essere trasformata
in una corrispondente relazione innestata:
musicType(name: string, notes: text, band(name: string; photo:
picture, album(title:string; cover: picture, song(title:string))))
(0,N)
name
belongsTo
title
(0,N)
(0,N)
published
(1,N)
album
cover
(0,N)
(1,N)
lyricAuthor
(0,N)
(1,N)
contained
tipicSings
musicType
(1,1)
code
notes
members
person
(0,N)
title
(1,N)
musicAuthor
(0,N)
(1,N)
song
(0,N)
code
code
photo
lyric
(0,N)
name
(0,N)
band
performs
score
Figura 4.1 Diagramma E-R del database musicale di esempio.
La struttura di una nested relation è rappresentata da uno structure
tree [Massari et al., 1997]. Uno structure tree può essere descritto
componendo ricorsivamente i due costrutti “set_of” e “record”.
Informalmente un “set_of” è un insieme non ordinato di elementi dello
stesso tipo; un “record” è una lista di elementi che può essere di
differenti tipi. Uno o più elementi di un record può essere un “set_of”.
59
Generazione dello structure tree.
Così uno structure tree è composto di nodi e di archi, ogni nodo può
essere un costrutto “set_of” e “record”.
In un modo formale, uno structure tree può essere definito
ricorsivamente come segue:
I. D, dove D è un dominio atomico di valori,
II. set of(T), dove T è uno structure tree;
III. record A1:T1,.......An:Tn end, dove gli Ai sono simboli distinti
ed i Ti sono structure tree.
Un oggetto risultante è una istanza di uno structure tree che può essere
definito ricorsivamente seguendo la definizione. Sia T uno structure
tree;
se T è un dominio atomico D, allora ogni elemento di D è una
istanza di T;
se T ha la forma set of (T’), allora una istanza di T è un insieme
finito di istanze di T’;
se T ha la forma: record A1:T1,.......An:Tn end, allora una istanza di T
è una tupla t su A1,.......,An tale che t[Ai] è una istanza di Ti, per
1in.
Si consideri il seguente structure tree:
T: set of
record
60
Generazione dello structure tree.
A1:T1,....Ak:Tk,.....An:Tn
end
Se l’attributo Ak è un attributo chiave ciò implica che per ogni coppia
di tuple t’ e t’’ nell’insieme t’[Ak] t’’[Ak].
Un esempio di structure tree corrispondente alla nested relation su
riportata, è descritto in Figura 4.2.
Il nodo radice è un nodo record che indica il database coinvolto nella
query, e può occasionalmente avere alcuni valori atomici che
descrivono il database stesso. Esso ha solo un figlio, cioè un nodo
set_of, il cui valore è la nested relation MUSIC TYPES risultante dalla
query. La relazione MUSIC TYPES è un insieme di record con due
valori atomici, una stringa (NAME) e un testo (NOTES) in forma di
nodi attributo. Esso contiene anche una nested relation (BANDS) cioè
un nodo set_of, che rappresenta l’insieme di tutti i gruppi che
eseguono un certo tipo di musica.
Il resto dello structure tree può essere generato facilmente perchè esso
contiene ripetizioni delle nozioni esaminate. Inoltre, osservando la
Figura 4.2, è possibile notare che sono stati inseriti anche degli pseudo
nodi "typeofData", in modo da avere un accesso diretto al tipo di dato
che un nodo attributo può supportare (i.e. testo, immagine, suono e
così via).
61
Generazione dello structure tree.
MUSIC
contains
MUSIC TYPES
collects
MUSIC TYPE
owns
owns
contains
NAME
NOTES
BANDS
collects
isof
isof
TEXT
STRING
owns
owns
NAME
isof
BAND
contains
PHOTO
isof
STRING
ALBUMS
collects
owns
Set_of
ALBUM
IMAGE
owns contains
TITLE
COVER
isof
isof
STRING
PICTURE
SONGS
collects
SONG
Record
Key Attribute
owns
TITLE
Attribute
Type of data
isof
STRING
Figura 4.2 Structure tree per la query 1.
4.3.
Query Repository
Il modulo Structure Tree Generator inserisce lo structure tree nel
Query Repository. La Figura 4.3 mostra lo schema E-R del Query
Repository. E’ possibile notare che i nomi degli archi dello structure
62
Generazione dello structure tree.
tree (Figura 4.2) corrispondono ai nomi delle relazioni contenute nello
schema E-R del Query Repository (Figura 4.3).
Prolog
Qname
Query
SQL_expression
DbId
(0,N)
(1,1)
Query
DbName
refersTo
Dbase
Qid
STNid
StructureTree
Node
belongsTo
(1,N)
(1,1)
Key
SQLscript
SQLscript
(1,1)
SetofNode
(0,1)
(1,N)
RecordNode
(1,1)
AttributeNode
owns
collects
(1,1)
(1,1)
(1,1)
(0,N)
contains
(0,N)
(0,1)
has
isof
dataid
(0,N)
(0,1)
root
description
TypeofData
Figura 4.3 Diagramma E-R del Query Repository.
Ogni query è identificata univocamente dall’attributo “Qid”, mentre
“Qname” è il nome della query e “SQL_expression” è la sua
espressione SQL. L’attributo “Prolog Query” rappresenta la query in
forma di una clausola definita di un programma in Prolog [Bratko,
1990] e costituisce l’input del Metaphor Definition Tool. Ogni nodo
dello structure tree è identificato univocamente dall’attributo “STNid”
ed è istanziato ad una delle seguenti tre classi di nodi:
un nodo set_of;
un nodo record;
un nodo attribute.
63
Generazione dello structure tree.
Una query complessa può così essere descritta da una combinazione di
nodi che appartengono ad una delle classi su menzionata, legati
assieme da alcune relazioni in modo da generare differenti livelli di
nesting.
Ogni query ha come radice un nodo record (si veda la relazione "root"
in Figura 4.3), che può essere legato sia a nodi di tipo set_of
(attraverso la relazione "contains"), o a nodi di tipo “attribute”
(attraverso la relazione "owns"), o infine ad altri nodi di tipo record
(attraverso la relazione "has"). Gli oggetti recuperati dalla subquery di
un nodo set_of sono di tipo record (si veda la relazione "collects" in
Figura 4.3).
Poichè i nodi “attribute” possono essere di differenti tipi di dati in
dipendenza dal tipo di informazione che essi recuperano (i.e. testo,
immagini, suoni ecc.), essi sono legati dalla relazione "isof" ad un’altra
entità del Query Repository, chiamata typeofData. L’attributo “key”
del nodo “attribute” stabilisce se esso è chiave primaria nel database
sorgente.
4.4.
Strumenti utilizzati
Il problema di effettuare l’analisi sintattica è abbastanza difficile da
risolvere senza l’apporto di strumenti adeguati. Per questo motivo sono
64
Generazione dello structure tree.
state utilizzate delle utility che permettono la generazione automatica
di codice. Tra tutti gli strumenti disponibili (Lex e Yacc, Flex e Bison,
Sed e Awk, ecc.) sono stati scelti Flex e Bison. La scelta è stata fatta
perchè c’era una precedente conoscenza di Flex e Bison anche se in
versione Object-Oriented.
Solitamente usati in coppia, essi consentono la generazione di un
Parser data la grammatica del linguaggio e le espressioni regolari dei
token [Levine et al., 1992]. Non sono in grado di generare un
compilatore completo ma richiedono codice C di supporto per le parti
non strettamente sintattiche. Il loro campo di applicazione è abbastanza
ampio, sono utilizzabili per la costruzione di interpreti, convertitori di
formato, e in tutti i campi in cui si effettua analisi di formato.
4.4.1. Flex
Flex (Fast Lexical Analyzer Generator) è uno strumento per la
generazione di programmi che eseguono il riconoscimento di pattern
su un testo. A partire dalle regole scritte dal programmatore per
definire le caratteristiche lessicali di un linguaggio formale, Flex è in
grado di generare un analizzatore lessicale (Scanner) per quel tipo di
linguaggio formale. Flex riceve in input un file di testo (scan.l, si veda
la prima sezione dell’appendice) che contiene le regole per identificare
i simboli terminali del linguaggio che si sta considerando, in questo
caso l’SQL. Flex crea un file sorgente in C (lex.yy.c) contenente la
routine yylex che rappresenta lo Scanner che sarà utilizzato dal Parser
65
Generazione dello structure tree.
[Levine et al., 1992]. Lo schema generale del file in input a Flex è
nella Figura 4.4.
[ d e f in itio n s ]
%%
[ r u le s
%%
u s e r s u b r o u tin e s ]
Figura 4.4 Struttura del file in input a Flex.
La sezione definitions contiene codice C per la definizione di macro
pattern, dichiarazioni, direttive iniziali ed una elencazione di
espressioni regolari [Levine et al., 1992]. Nella sezione 1.1 in
appendice è possibile osservare un esempio di definitions per il file
scan.l.
La sezione rules contiene le regole per il riconoscimento dei pattern.
Le regole hanno il seguente formato:
pattern da riconoscere sottoforma di espressioni regolari;
azioni da compiere sottoforma di frammenti di programmi C
in corrispondenza del matching positivo tra file di input e
token.
In appendice la sezione rules del file scan.l contiene una elencazione
dei simboli terminali della grammatica da analizzare (l’SQL) e le
corrispondenti azioni che consistono nella restituzione del valore del
token.
66
Generazione dello structure tree.
La sezione user subroutines contiene routine in C usate come supporto
alle azioni attivate nella sezione precedente. Questa parte del file in
input a Flex è opzionale. Come è possibile notare in appendice, la
sezione user subroutines del file scan.l è vuota.
La routine yylex generata avrà il compito di fare lo scanning di un
testo cioè di leggere un file sorgente considerato come un semplice
flusso di caratteri e di suddividerlo in pezzi significativi detti “token”,
ottenuti raggruppando sequenze di caratteri.
4.4.2. Bison
A partire dalle regole grammaticali descritte dal programmatore
secondo il formalismo di Backus-Naur, Bison è in grado di generare un
analizzatore sintattico (Parser) che esamina e riconosce espressioni dei
linguaggi formali aderenti a quelle regole. Il Parser generato esamina
la sequenza dei token in input e automaticamente riconosce se tale
input coincide con una delle regole della grammatica definita. Inoltre
segnala errori sintattici in caso di match negativo tra le regole della
grammatica e l’input. Bison riceve in input un file di testo (parser.y)
contenente le regole della grammatica per identificare i simboli non
terminali del linguaggio che si sta considerando (in questo caso l’SQL)
e genera in output un file sorgente in C (parser.tab.c) che contiene una
particolare routine di parsing (yyparse) che riconosce istanze della
grammatica.
67
Generazione dello structure tree.
Lo schema generale di un file in input a Bison è riportato in Figura 4.5.
%{
C declarations
%}
Bison declarations
%%
grammar rules
%%
Additional C code
Figura 4.5 Struttura del file in input a Bison.
Le C declarations possono contenere definizioni di macro,
dichiarazioni di funzioni e di variabili che sono usate nelle azioni.
Nella sezione 1.2 in appendice è riportata la parte C declaration per il
file parser.y.
Nelle Bison declarations vengono dichiarati i nomi dei simboli
terminali e non terminali [Levine et al., 1992], è possibile specificare il
tipo di dato dei valori semantici dei simboli e la dichiarazione della
associatività di alcuni operatori. Il file parser.y contiene la
dichiarazione
dei
token
dell’SQL
(si
veda
la
sezione
1.2
dell’appendice).
68
Generazione dello structure tree.
Le grammar rules contengono una o più regole della grammatica da
analizzare e definiscono come costruire ogni simbolo non terminale a
partire dalle sue parti. Il formato di una grammar rule è il seguente:
simbolo non terminale: espressione regolare {azione}
Le azioni vengono eseguite in caso di match positivo con la
grammatica e sono istruzioni in C racchiuse tra parentesi graffe. In
appendice è mostrata la grammatica del linguaggio SQL.
La sezione additional C code può contenere qualsiasi routine di codice
C; generalmente in questa sezione è incluso l’analizzatore sintattico, la
routine per il report degli errori più altre procedure e funzioni che
vengono utilizzate nelle azioni. Il file parser.y contiene in questa
sezione le routines per per la generazione della nested relation.
I simboli %% , %{ e %} , appaiono in ogni file di input a Bison per
separare le varie sezioni.
Per effettuare il parsing di un linguaggio, esso deve essere descritto da
una grammatica context free; questo equivale a dire che è necessario
specificare uno o più gruppi sintattici e dare regole per costruirli. Il più
comune sistema formale per presentare tali regole è il Backus Naur
Form (BNF) ed ogni grammatica espressa in BNF è una grammatica
context free. Non tutte le grammatiche context free possono essere
manipolate da Bison ma solo quelle che sono LALR(1) (Look Ahead
token Left to Right) [Levine et al., 1992].
69
Generazione dello structure tree.
4.5.
Realizzazione dello Structure Tree Generator
Lo Structure Tree Generator (STG) è un programma il cui modulo
eseguibile è creato secondo i passi descritti nella Figura 4.6. Flex
riceve in input un file di testo che per convenzione ha estensione “.l”
(si veda la sezione 1.1 in appendice che illustra il file scan.l) che
contiene la lista dei simboli terminali del linguaggio SQL e genera il
codice sorgente dello Scanner in linguaggio C (lex.yy.c) contenente la
routine yylex che effettua l’analisi lessicale.
Specifica Flex
(*.l)
Flex
yylex()
Routine che effettua
l’analisi lessicale
Specifica Bison
(*.y)
Bison
yyparse()
Routine che effettua
l’analisi sintattica
Routines in C
Compilatore
C (GCC)
Librerie
Programma
Figura 4.6 Generazione del programma eseguibile.
Similmente Bison riceve in input un file di testo che per convenzione
ha estensione “.y” (si veda la sezione 1.2 in appendice che illustra il
file parser.y) contenente la grammatica del linguaggio SQL e genera il
70
Generazione dello structure tree.
codice sorgente di un analizzatore sintattico in linguaggio C
(parser.tab.c) contenente la routine yyparse che effettua l’analisi
sintattica.
Successivamente, i file di codice sorgente C generati verrano compilati
e linkati assieme agli header file dal compilatore Unix “GCC” per
generare il programma eseguibile.
4.6.
Esecuzione del programma STG
Il programma generato seguendo i passi descritti in precedenza,
durante l’esecuzione riceve in input un file contenente la query scritta
in SQL (in particolare la query è scritta nel linguaggio SQL dell’IUSInformix Universal Server) e crea i file “output” e “SET_OF”. Il file
“output” contiene la query ricevuta in input con gli eventuali messaggi
d’errore se la query non è corretta, mentre il file “SET_OF” contiene le
subquery per ogni entità presente nella query. La prima operazione
effettuata dal programma STG è l’analisi lessicale cioè lo Scanner
legge il file in input considerato come un semplice flusso di caratteri e
li raggruppa in token [Levine et al., 1992]; in questa fase sono
eliminati tutte le tabulazioni ed i caratteri carriage return.
La scansione viene effettuata dalla routine yylex contenuta nello
Scanner, invocata dalla routine yyparse contenuta nel Parser. La
sequenza dei token viene analizzata grammaticalmente per ricostruire
la derivazione della query dalla grammatica. Nel caso in cui l’input
non è sintatticamente corretto viene invocato il modulo yyerror che
71
Generazione dello structure tree.
visualizza un messaggio con il numero di linea in cui si è verificato
l’errore.
Ogni volta che una sequenza di token in input corrisponde ad una delle
regole nella grammatica della query SQL, è intrapresa una azione. Le
azioni riguardano la selezione delle relazioni e degli attributi coinvolti
nella query, l’identificazione degli attributi di Join, e la costruzione
della nested relation basata sulla clausola ORDER BY.
Considerando come input la query 1 del capitolo 4, ogni entità
corrisponde ad un nodo set_of, una istanza di una entità corrisponde ad
un nodo record e gli attributi delle entità corrispondono a nodi
attribute. Il primo passo effettuato dal programma STG per la
generazione della nested relation è l’individuazione dei set_of, degli
attribute e l’inserimento nella struttura sql_table dei nomi delle
relazioni presenti nella clausola Select (si veda la Figura 4.7).
sql_table
table
sql_script
song
SELECT title
musicType
SELECT name, notes
band
SELECT name, photo
album
SELECT title, cover
Figura 4.7 Sql_table dopo l’esecuzione delle azioni semantiche
associate alla clausola Select.
La sql_table è una lista formata da due campi, il primo contiene il
nome della entità del database sorgente ed il secondo contiene la
72
Generazione dello structure tree.
subquery ad essa associata (Figure 4.7 e 4.8). Nella sezione 1.4 in
appendice è riportato il file sorgente C che implementa questa tabella.
sql_table
table
sql_script
song
SELECT title FROM song
musicType
SELECT name, notes FROM musicType
band
SELECT name, photo FROM band
album
SELECT title, cover FROM album
Figura 4.8 Sql_table dopo l’esecuzione delle azioni semantiche
associate alla clausola From.
Quando il programma STG riconosce una clausola From verrà
effettuato
l’aggiornamento
delle
subquery
inserendo
“FROM
<name_table>” (si veda la Figura 4.8).
join_table
name_table1
name_attribute1
name_table2
name_attribute2
album
code
contained
albumCode
tipicSings
bandCode
band
code
album
code
published
albumCode
band
code
published
bandCode
song
code
contained
songCode
tipicSings
musicName
musicType
name
Figura 4.9 Join_table dopo l’esecuzione delle azioni semantiche
associate alla clausola Where.
73
Generazione dello structure tree.
La struttura join_table è creata quando è riconosciuta una condizione
di Join [Elmasri & Navate, 1989]. La join_table è una lista formata da
quattro campi in cui vengono inserite le relazioni ed attributi di Join
che compaiono nella clausola Where (si veda la Figura 4.9). Questa
tabella è necessaria per completare la generazione delle subquery.
Nella sezione 1.3 in appendice è riportato il file sorgente C che
implementa questa tabella.
sql_table
table
sql_script
song
SELECT title FROM song
musicType
SELECT name, notes FROM musicType ;
band
SELECT name, photo FROM band WHERE code IN (SELECT
bandCode FROM tipicSings WHERE musicName
=<musicName_selected> )
album
SELECT title, cover FROM album
Figura 4.10 Sql_table dopo l’esecuzione delle azioni semantiche
associate alla clausola Order by.
La costruzione della nested relation è effettuata quando il programma
STG riconosce la clausola Order by. Se due tabelle sono in sequenza
nella clausola Order by e se esse sono legate mediante una condizione
di Join, la prima nell’ordine sarà al top dello structure tree, mentre la
seconda sarà al bottom. Nella Figura 4.10 è possibile osservare la
subquery associata alla relazione band. Il risultato di questa subquery
contiene le informazioni (nome e foto) del cantante che esegue uno
stile di musica.
74
Generazione dello structure tree.
4.7.
Esempi di subquery create dal programma STG
Considerando la query 1 come input del programma STG, si ottengono
le seguenti subquery.
1. SELECT name, notes FROM musicType ;
2. SELECT name, photo FROM band WHERE code IN (SELECT
bandCode FROM tipicSings WHERE musicName
=<musicName_selected> )
3. SELECT title, cover FROM album WHERE code IN ( SELECT
albumCode FROM published WHERE bandCode
=<bandCode_selected>) ;
4. SELECT title FROM song WHERE code IN ( SELECT songCode
FROM contained WHERE albumCode =<albumCode_selected> ) ;
M U S IC T Y P E S
c o lle c ts
M U S IC T Y P E
o wns
NAM E
Figura 4.11.
o wns
N O TE S
Structure Tree
associato alla subquery 1.
Il risultato della prima subquery contiene le informazioni relative ai
tipi di musica. Lo structure tree associato a questa subquery è mostrato
in Figura 4.11.
75
Generazione dello structure tree.
Nel risultato della seconda subquery sono contenute le informazioni
relative ai cantanti che eseguono un tipo di musica. Il suo structure tree
è mostrato nella Figura 4.12.
M U S IC T Y P E
c o n tain s
BANDS
c o lle c ts
BAND
o wns
NAM E
o wns
P H O TO
Figura 4.12. Structure Tree associato alla subquery 2.
Il risultato della terza subquery contiene le informazioni relative agli
album incisi da un cantante. Il suo structure tree è mostrato nella
Figura 4.13.
BAND
c o n tain s
c o lle c ts
ALBUM S
ALBUM
o wns
T IT L E
o wns
COVER
Figura 4.13 Structure tree associato alla subquery 3.
Il risultato della quarta subquery contiene le informazioni relative alle
canzoni appartenenti ad un album. Il suo structure tree è mostrato nella
Figura 4.14.
76
Generazione dello structure tree.
ALBUM
c o n tain s
SO N G S
c o lle c ts
SO N G
o wns
T IT L E
Figura 4.14 Structure tree associato alla subquery 4.
Collegando gli structure tree ottenuti dalle subquery generate, si
ottiene facilmente lo structure tree mostrato in Figura 4.2.
77
Generazione automatica delle metafore in Virgilio.
capitolo 5
5.
Generazione automatica delle metafore in
Virgilio
5.1.
Introduzione
Una volta che lo structure tree della query è stato generato, come
descritto nel capitolo precedente, è necessario creare le corrispondenze
(mapping) tra lo structure tree e qualche mondo virtuale preso da un
insieme predefinito di mondi virtuali memorizzati nel VR Object
Repository in modo da presentare all’utente il risultato della query
mediante una scena virtuale che sfrutti una metafora appropriata. Tale
mapping è stato realizzato in modo automatico come un processo di
Soddisfacimento di Vincoli che sfrutta la strategia di ricerca depth first
degli interpreti Prolog che è descritto in questo capitolo.
A questo scopo, la rappresentazione dello structure tree è tradotta in
una clausola Prolog dal Prolog Query Generator mostrato in Figura
3.2.
78
Generazione automatica delle metafore in Virgilio.
5.2.
Requisiti per il mapping
Il processo di mapping deve incontrare un insieme di requisiti, ad
esempio:
Consistenza con lo structure tree: la metafora deve permettere di
effettuare l’esplorazione dei dati in accordo con le relazioni
gerarchiche espresse nello structure tree. In realtà, l’organizzazione
dei risultati è basata sulla struttura della query SQL, cioè sul modo
in cui l’utente ha formulato le sue richieste. Quando la
corrispondenza tra la struttura della query SQL e la “struttura” del
mondo virtuale è severa, l’utente potrà effettuare l’esplorazione più
facilmente poichè già conosce le direzioni da scegliere.
Completezza della metafora: Tutti i dati nella relazione risultante di
una query devono essere raggiungibili dal punto iniziale della
esplorazione.
Realismo del mondo virtuale: Le scene presentate all’utente devono
essere realistiche. Ad esempio, mostrare un muro con centinaia di
poster non è il modo migliore di aggregare dati riguardanti dei testi
musicali.
Efficacia della metafora: Le proprietà degli oggetti nel mondo
virtuale, devono corrispondere alle proprietà dei dati che essi
rappresentano. Ad esempio, se un CD in una scena virtuale
rappresenta un album musicale, clickando su di esso dovrebbe
79
Generazione automatica delle metafore in Virgilio.
essere possibile ascoltare una canzone, mentre le pagine di un libro
sono più appropriate per rappresentare il testo delle canzoni.
5.3.
Classificazione degli oggetti virtuali
Il mondo virtuale è visto come un insieme di oggetti del mondo
virtuale. Essi possono essere classificati in tre tipi differenti:
1. Aggregator, che non necessariamente rappresenta un dato per se
stesso, ma aggrega un insieme di oggetti virtuali di differenti tipi (ad
esempio un tavolo può aggregare l’oggetto “libro” e l’oggetto
“portaritratto”, il primo usato per rappresentare il testo delle canzoni
mentre il secondo mostra la foto del cantante;
2. Classifier, che assembla un insieme di oggetti Aggregator dello
stesso tipo (ad esempio un oggetto cassettiera è un classifier poichè
contiene molti cassetti). Naturalmente un classifier può essere più
appropriato di un altro per rappresentare un particolare insieme di
dati. Un importante fattore è il numero degli aggregatori che esso
contiene. Una reale cassettiera contiene da due a sei cassetti, mentre
un libro ha da ottanta a mille pagine. Perciò, per ogni classifier è
necessario definire un minimo ed un massimo numero di
aggregators da assemblare;
3. Accessory, che rappresenta uno specifico tipo di dato (ad esempio
un poster può visualizzare il tipo di dato “immagine” mentre una
80
Generazione automatica delle metafore in Virgilio.
etichetta è un esempio di accessory usato per rappresentare una
stringa).
E’ interessante notare che alcuni aggregators possono avere due
differenti rappresentazioni visuali: interno ed esterno. Il primo è
chiamato Aggrsymbol, ed è tipicamente mostrato quando l’utente
effettua il browse di un classifier, mentre il secondo è la naturale
rappresentazione dell’aggregator, ed è mostrato quando l’utente ha
scelto un aggregator da un classifier. Ad esempio, una stanza è un
aggregator a cui si accede da un corridoio (classifier). La sua
rappresentazione interna è ovvia e dipende dai dati aggregati, mentre la
sua rappresentazione esterna può essere una porta con una etichetta su
di esso. Così quando l’utente è nel corridoio vede solo molte porte, ma
quando entra in una stanza può vedere gli oggetti all’interno.
Tra gli oggetti virtuali menzionati in [Massari et al., 1997] vi è anche
un altro tipo di oggetti, cioè i "Jumpers", che possono essere usati per
linkare oggetti che non condividono relazioni di contenimento e.g, se
due oggetti che appartengono a due mondi virtuali devono essere
connessi, un jumper può fornire tale connessione. Tale tipo di oggetto
non è stato considerato durante l’implementazione di questa versione
di Virgilio, poichè ci sono ancora alcune problematiche aperte sul loro
effettivo significato ed utilizzo. Ad esempio non è chiaro se il mondo
virtuale a cui saltare dovrebbe contenere l’intera query iniziale oppure
solo una parte di essa. Inoltre non sarebbe facile prevedere la reazione
e il comportamento dell’utente se la metafora inizialmente scelta sia
sostituita da un’altra.
81
Generazione automatica delle metafore in Virgilio.
Gli oggetti descritti sono memorizzati nel Virtual World Object
Repository (VWOR), il cui schema è raffigurato in Figura 5.1.
h a s ic o n
c o lle c ts
(0, n)
(0, 1)
(1, 1)
T y p e o f D a ta
(1, 1)
has
(0, n)
M ax
(0, n)
(0, m )
is o f
M in
root
C la s s if ie r
c o n ta in s
(1, 1)
A g g r e g a to r
(0, n)
V W O b jI d
(1, 1)
ow ns
(0, n)
A c c e ssory
(0, m )
ow ns
(0, n)
A ggrsym bol
(0, m )
V W o b je c t
V R M L_FR M K
Figura 5.1 Diagramma E-R del Virtual World Object Repository.
L’entità VWobject possiede un attributo “VWObjId” che lo identifica
univocamente, ed un attributo “VRML_FRMK” cioè una descrizione
in VRML dell’oggetto. Un aggregator può contenere alcuni classifier
(legati dalla relazione "contains"), alcuni accessory (legati dalla
relazione "owns"), oppure altri aggregator (legati dalla relazione
"has"). Un aggregator è legato alla sua icona (i.e. ad un aggrsymbol)
attraverso la relazione "hasIcon". Un aggrsymbol può anche possedere
(“owns”) alcuni accessory, che possono corrispondere ad alcuni
accessory posseduti dall’aggregator associato. La relazione “collects”
lega ogni classifier con gli aggregator che esso colleziona.
Per evitare la generazione di scene non naturali con troppi oggetti
oppure con pochi oggetti (e.g. un edificio con 1000 piani o un libro
82
Generazione automatica delle metafore in Virgilio.
con una sola pagina), ogni classifier ha due attributi (Min e Max), che
rappresentano rispettivamente il minimo ed il massimo numero di
oggetti che esso può contenere.
Il tipo di dato che un oggetto Accessory può supportare è descritto
dalla entità "typeOfData", legato ad esso per mezzo della relazione
"isOf".
5.3.1. Il mondo virtuale “palazzo”
Il mondo virtuale utilizzato nel prototipo del sistema Virgilio descrive
un palazzo con una entrata principale che porta ad un ascensore che
contiene una tastiera. Premendo un tasto è possibile accedere ai piani
dell’edificio. Ogni tasto ha una etichetta che è un accessorio adatto a
rappresentare il tipo di dato stringa e può in tal modo identificare il
piano da raggiungere. Il piano contiene un cartellone con una scritta
che contiene la stessa informazione del tasto precedentemente
premuto.
83
Generazione automatica delle metafore in Virgilio.
OGGETTI VIRTUALI
ESEMPI VISUALI
Aggregator
Classifier
Accessory
Aggrsymbol
Tabella 5.1 Esempi visuali di oggetti virtuali.
Un piano aggrega anche un corridoio che può contenere delle stanze; è
possibile accedere ad una stanza aprendo una porta che ha una
etichetta su di esso. In una stanza si può trovare un poster con una
immagine, una cassettiera e un album di foto su un tavolo. Nella
tabella 5.1 si riportano degli esempi degli oggetti del mondo virtuale
“palazzo”.
84
Generazione automatica delle metafore in Virgilio.
5.4.
Definizione della metafora come un problema di
soddisfacimento di vincoli
L’approccio verso la definizione automatica di una metafora è basato
sul fatto che la conoscenza sui mondi virtuali può essere facilmente
rappresentata mediante un formalismo logico. In particolare l’universo
del discorso riguarda gli oggetti virtuali (aggregators, classifiers,
accessory), gli aggregator symbols, i types of data ed i numeri interi.
Ogni elemento dell’universo del discorso è identificato da una costante
distinta. Per esempio, se consideriamo il mondo virtuale “palazzo” si
possono definire le seguenti costanti:
AGGREGATORS: ascensore, stanza, piano dell’edificio, cassetto,
cartella, pagina;
CLASSIFIERS: tastiera, cassettiera, album, corridoio, collezione di
cartelle;
ACCESSORIES: nome del piano, cartello, poster, immagine, foto,
etichetta sulla porta, immagine sul cassetto, etichetta sul cassetto;
AGGREGATOR SYMBOLS: porta, frontale del cassetto, indice,
tasto;
TYPES OF DATA: stringa, testo, immagine piccola, immagine
grande.
Le relazioni interne tra gli oggetti dell’universo del discorso sono
espresse da clausole ground (si ricorda che una clausola si dice ground
quando in essa non compaiono variabili libere). Alcuni predicati
riguardano le relazioni riportate nello structure tree. Esse sono:
85
Generazione automatica delle metafore in Virgilio.
1. contains(Aggregator, Classifier), vale a dire che un Classifier può
essere contenuto in un Aggregator;
2. collects(Classifier, Aggregator), vale a dire che un Classifier può
collezionare un insieme di Aggregator;
3. owns(Aggregator, Accessory) oppure owns(AggregatorSymbol,
Accessory), vale a dire che un Aggregator (Symbol) può contenere
un Accessory;
4. is-of(Accessory, TypeOfData), che definisce il tipo del dato che può
essere associato ad un Accessory.
Inoltre, il predicato hasicon(Aggregator, AggregatorSymbol) definisce
l’Aggregator Symbol associato ad un Aggregator, mentre i predicati
hasmin(Classifier, Integer) ed hasmax(Classifier, Integer) sono usati
per esprimere vincoli realistici sul numero degli oggetti aggregati da
un classifier.
Un esempio di possibili relazioni interne tra gli oggetti del mondo
virtuale “palazzo” è riportato in Figura 5.2.
Data una base di conoscenza su qualche mondo virtuale, il problema di
trovare la corrispondenza tra lo structure tree e un mondo virtuale, può
essere visto come un problema di soddisfacimento di vincoli applicato
alla etichettatura di immagini (si veda il capitolo 2 per ulteriori
dettagli).
Come mostrato da Mackworth (1977), la soluzione ad un Problema di
Soddisfacimento di Vincoli è simile al problema di fornire una
dimostrazione costruttiva della validità di una formula (senza simboli
86
Generazione automatica delle metafore in Virgilio.
di funzione) del tipo FG, dove F è la descrizione del mondo espressa
come una congiunzione di letterali ground che realizzano una lista dei
fatti nel mondo, mentre G è l’obiettivo definito, che è una formula
esistenziale con una congiunzione di letterali (i vincoli).
contains(elevator, button-table)
contains(room, chest-of-drawers)
contains(room, album)
contains(floor, corridor)
contains(drawer, folder-collection)
collects(button-table,floor).
collects(corridor,room).
collects(chest-of-drawers,drawer).
collects(folder-collection,folder).
collects(album,page).
hasmin(button-table,2).
hasmin(corridor,1).
hasmin(chest-of-drawers,0).
hasmin(folders,1).
hasmin(album,1).
hasmax(button-table,20).
hasmax(corridor,30).
hasmax(chest-of-drawers,20).
hasmax(folder-collection,10).
hasmax(album,30).
owns(floor,floor-name).
owns(floor,sideboard).
owns(folder,photo).
owns(room,door-label).
owns(drawer,drawer-label).
owns(drawer,drawer-picture).
owns(door,door-label).
owns(drawer-front, drawer-picture).
owns(drawer-front, drawer-label).
isof(floor-name,string).
isof(drawer-label,string).
isof(door-label,string).
isof(button-label,string).
isof(sideboard,text).
isof(board,text).
isof(picture,picture).
isof(drawer-picture,picture).
isof(photo,picture).
isof(poster,image).
hasicon(room, door).
hasicon(drawer, drawer-front).
hasicon(page, index).
hasicon(floor, button).
hasicon(elevator,nil).
hasicon(folder,nil).
owns(room, poster).
Figura 5.2 Un esempio di base di conoscenza sul mondo virtuale
“palazzo”.
La
dimostrazione
costruttiva
della
validità
della
formula
automaticamente porta ad una sostituzione per le variabili quantificate
esistenzialmente. Nella specifica applicazione, F è la descrizione di un
mondo virtuale (e.g. “palazzo”), mentre G è la descrizione dello
structure tree, che è rappresentato come una congiunzione di letterali
87
Generazione automatica delle metafore in Virgilio.
non ground le cui variabili sono quantificate esistenzialmente. Tali
letterali descrivono la struttura della query, e definiscono il numero
reale di elementi aggregati da un classifier. Gli stessi simboli di
predicato sono usati per descrivere uno structure tree.
contains(RecordMusic, SetofMusicTypes)
hasicon(RecordMusic, RecordMusicIcon)
collects(SetOfMusicTypes, RecordMusicType)
hasicon(RecordMusicType, RecordMusicTypeIcon)
hasmin(SetOfMusicTypes, MinMusicTypes) 5 >= MinMusicTypes
hasmax(SetOfMusicTypes, MaxMusicTypes) MaxMusicTypes >= 15
owns(RecordMusicType, AttributeNameType)
isof(AttributeNameType, string)
owns(RecordMusicType, AttributeNotes) isof(AttributeNotes, text)
contains(RecordMusicType, SetOfBands)
collects(SetOfBands, RecordBand)
hasicon(RecordBand, RecordBandIcon)
hasmin(SetOfBands, MinBands)
2 >= MinBands hasmax(SetOfBands, MaxBands) MaxBands >= 30
owns(RecordBand, AttributeName) isof(AttributeName, string)
owns(RecordBand, AttributePhoto) isof(AttributePhoto, image)
contains(RecordBand, SetOfAlbums)
collects(SetOfAlbums, RecordAlbum)
hasicon(RecordAlbum, RecordAlbumIcon)
hasmin(SetOfAlbums, MinAlbums)
1 >= MinAlbums hasmax(SetOfAlbums, MaxAlbums)
MaxAlbums >= 8 owns(RecordAlbum, AttributeTitle)
isof(AttributeTitle, string)
owns(RecordAlbum, AttributeCover) isof(AttributeCover, picture)
contains(RecordAlbum, SetOfSongs)
collects(SetOfSongs, RecordSong)
hasicon(RecordSong, RecordSongIcon) hasmin(SetOfSongs, MinSong)
1>=MinSong hasax(SetOfSongs, MaxSong) MaxSong >=10
owns(RecordSong, AttributeNameSong) isof(AttributeNameSong, string)
Figura 5.3. Formulazione logica dello structure tree in Figura 4.2.
Ad esempio, la formulazione logica dello structure tree in Figura 4.2 è
riportato in Figura 5.3. I numeri interi nella query sono le cardinalità
88
Generazione automatica delle metafore in Virgilio.
delle relazioni che compongono la nested relation determinata dalla
query.
Da un punto di vista pratico, è possibile usare gli interpreti Prolog per
provare la validità della formula [Shalkoff, 1990]. Il Programma
Logico è l’insieme dei fatti ground della base di conoscenza, mentre la
query Prolog è la formulazione logica dello structure tree. La risposta
calcolata dall’interprete Prolog definisce le istanziazioni delle variabili
nella query con qualche oggetto virtuale.
RecordMusic elevator
RecordMusicIconnil
AttributePhotoposter
SetOfMusicTypesbutton-table
SetOfAlbumschest-of-drawers
MinMusicTypes2
MinAlbums0
MaxMusicTypes20
MaxAlbums20
RecordMusicTypefloor
RecordAlbumdrawer
RecordMusicTypeIconbutton
RecordAlbumIcondrawer-front
AttributeNameTypefloor-name
AttributeTitledrawer-label
AttributeNotessideboard
AttributeCoverdrawer-picture
SetOfBandscorridor
SetOfSongsfolder-collection
MinBands1
MinSongs1
MaxBands30
MaxSongs10
RecordBandroom
RecordSongfolder
RecordBandIcondoor
RecordSongIconnil
AttributeNamedoor-label
AttributeNameSongfolder-name
Figura 5.4. Istanziazione delle variabili della query in Figura 5.3 che
definisce il mapping tra lo structure tree e il mondo virtuale.
89
Generazione automatica delle metafore
In questo modo la corrispondenza tra lo structure tree in qualche
mondo virtuale è completamente definita, e sarà la metafora
eventualmente generata. Ad esempio, la risposta calcolata per la query
in Figura 5.3 definirà le istanziazioni riportate in Figura 5.4.
E’ interessante osservare che ci possono essere diverse risposte ad una
stessa query Prolog, cioè ci possono essere molte metafore che
possono rappresentare i risultati della stessa query SQL. Quando
questo accade, è importante avere un criterio per la scelta di una delle
possibili metafore. La scelta può essere basata sul più recente mondo
virtuale usato per rispondere ad una query dello stesso utente.
Questa assunzione è fatta perchè si presume che l’utente abbia più
familiarità con il mondo virtuale più recentemente visualizzato.
Tuttavia, non è stato definito alcun criterio per la scelta di metafore
che riguardano lo stesso mondo virtuale, poichè ogni scelta
ragionevole dovrebbe essere basata sul modello utente [Catarci et al.,
1996] non ancora disponibile in Virgilio.
5.5.
Il Metaphor Definition Tool
In Virgilio, il processo di mapping su descritto, è eseguito dal
Metaphor Definition Tool (MDT). L’MDT riceve in input sia la base di
conoscenza sui mondi virtuali che la query Prolog, e produce un
Metaphor Graph, che associa ad ogni nodo dello structure tree qualche
90
Generazione automatica delle metafore
oggetto virtuale. Il Metaphor Graph è memorizzato nel Metaphor
Repository, così che possa essere ritrovato dallo Scene Constructor
Server che costruisce la sequenza di scene del mondo virtuale scelto
che visualizza il risultato della query. Le scene sono costruite mediante
il VRML, ma il lavoro dello Scene Constructor Server va oltre lo
scopo di questa tesi (per dettagli si veda [Massari et al. 1997].
VW Object Name
Corridor
Room
Door
Label on the door
tipo
Classifier
Aggregator
Aggrsymbol
Accessory
Structure Tree Node
set_of bands
record band
record band
attribute name of the band
Tabella 5.2 Un esempio di metafora.
5.6.
Esempio delle scene finali in VRML
Si presentano adesso degli esempi di scene costruite mediante il
prototipo di Virgilio [Paradiso, 1997]. Esse riguardano la query 1,
descritta nel capitolo 4, il cui risultato è stato rappresentato dalla
metafora “Palazzo”. L’utente può effettuare l’esplorazione del risultato
della query navigando nell’edificio dalla sua entrata ai differenti piani
e dentro le stanze. La prima scena visualizzata è un palazzo, esso
rappresenta l’intero risultato della query ed il punto iniziale
dell’esplorazione. All’interno del palazzo, l’entrata aggrega differenti
oggetti decorativi ed un classifier, l’ascensore.
91
Generazione automatica delle metafore
Figura 5.5. Entrata del palazzo.
Questo contenitore classifica differenti stili musicali, fornendo un
accesso al successivo livello di aggregazione nello structure tree della
query di esempio. Si noti come i differenti tipi di musica siano stati
rappresentati dai pulsanti dell’ascensore.
Figura 5.6. Un oggetto contenitore che classifica i tipi di musica.
Dopo aver selezionato un bottone ed essere usciti dall’ascensore, un
poster sul muro ricorda il contenuto del piano scelto, ed una tavola
poggiata sul pavimento descrive le note relative al tipo di musica.
92
Generazione automatica delle metafore
Figura 5.7. Un oggetto contenitore corridoio che classifica i cantanti.
Il corridoio fornisce l’accesso alle stanze contenenti ulteriori
informazioni che riguardano i cantanti. I nomi dei cantanti sono scritti
su delle etichette sulle porte.
Figura 5.8. Una stanza e altri oggetti che visualizzano e classificano
altre informazioni sui cantanti.
Entrando in una stanza gli utenti possono vedere differenti oggetti che
rappresentano le informazioni relative al cantante scelto.
93
Generazione automatica delle metafore
Figura 5.9. Il libro posto sul tavolo è un oggetto classificatore
contente l’insieme delle canzoni che il cantante ha scritto.
Figura 5.10. Informazioni su ogni canzone sono memorizzate in
differenti cartelle all’interno di un cassetto.
5.7.
Conclusioni
In questa tesi si è presentato un nuovo approccio per generare
automaticamente le metafore che devono essere sfruttate nella
interazione tra gli utenti e i database. Il processo di definizione della
metafora è stato trattato come un processo di soddisfacimento di
vincoli che è visto come il problema di fornire una dimostrazione
costruttiva della validità di una formula.
94
Generazione automatica delle metafore
Il lavoro di questa tesi è un passo ulteriore nello sviluppo di Virgilio,
un sistema in realtà virtuale che visualizza gli oggetti in un database
attraverso efficaci tecniche in RV. Si è illustrato il processo che genera
da una query ad un database tutta l’informazione necessaria alla
costruzione della scena virtuale che visualizza i risultati della query,
permettendo all’utente di effettuare l’esplorazione di tale risultato.
Per effettuare un ulteriore passo avanti nello sviluppo di Virgilio, si
dovranno implementare le altre componenti dell’architettura di Virgilio
come lo Scene Constructor Server (si veda la Figura 3.1) ed il Query
Prolog Generator (si veda la Figura 3.2). Sarà necessario migliorare lo
Structure Tree Generator che nel prototipo attuale non accede al
database per il calcolo del risultato dell query.
Inoltre si prevede di incorporare un modello utente nel sistema che
possa fornire la conoscenza che deve essere sfruttata nella scelta della
metafora. Infine si dovrà effettuare il test dell’attuale prototipo con gli
utenti finali dai quali si dovrebbero ottenere importanti informazioni
utili allo sviluppo del progetto Virgilio.
95
Bibliografia.
6.
BIBLIOGRAFIA
Alberg C., Shneidermann B., (1994), Visual Information Seeking:
Tight Coupling of Dynamic Query Filters with Starfield
Displays, in Proc. CHI’94 Human Factors in Computing
Systems, ACM Press, pp 313-317.
Angelaccio, M., Catarci, T., Santucci, G., (1990), QBD: A Graphical
Query Language with Recursion, IEEE Transaption on Software
Engineering, 1150-1163.
Atzeni, P,. & de Antonellis, V., (1993), Relational Database Theory,
Benjamin/Cummings, Redwood City, CA.
Bratko, I., (1990), Prolog, Programming for artificial intelligence,
Addison Wesley Publishing.
Brill, L. M., Il Problema delle Interfacce, (1995), CG Computer
Gazzette, Nr 7, 27-31.
Carroll, J. M., Mack, R. L., Kellogg W.A., (1988), Interface Metaphors
and User Interface Design, Handbook of Human-Computer
Interaction, 67-85.
Catarci, T., Costabile, M.F, Matera, M., (1995), Visual Metaphors for
interacting with Databases. ACM SIGCHI Bulletin, 27(2), 1517.
Catarci, T., Costabile, M. F., Levialdi, S., Batini, C., (1997), Visual
Query Systems for Databases: A Survey, Journal of Visual
Languages and Computing, Academic Press, 8, 215-260.
Catarci, T., Chang, S. K., Costabile, M. F., Levialdi, S., Santucci, G.,
(1996) A Graph Based Framework for Multiparadigmatic Visual
96
Bibliografia.
Access to Databases, to appear in IEEE Transaction on
Knowledge and Data Engineering., June 1996, 8(3) 455-475.
Catarci, T., Costabile, M. F., (1996) Visual Query Systems Journal of
Visual Languages and Computing, Academic Press, 7, 243-245.
Chang, S., Costabile, M.F., Levialdi, S., (1994), Reality BitesProgressive Querying and Result Visualization in Logical and
VR Space, Proceedings. of IEEE Symposium on Visual
Languages, St. Louis, Ottobre 1994, 100-109.
Chang, S.K., Costabile, M.F., Levialdi, S., (1993) Modeling users in
an adaptive visual interface for database systems, Journal of
Visual Languages and computing, vol. 4.
Costabile, M.F., Malerba, D., Hemmje, M., Paradiso, A., (1998),
Building Metaphors for Supporting User Interaction with
Multimedia Databases, Proceedings of VDB4, l’Aquila, Italia,
47-65.
Elmasri, R., Navathe, S.B., (1989), Fundamentals of Database
Systems, The Benjamin/Cummings Publishing Company, Inc,
Redwood City, CA.
Erickson, T. D., (1990), Working with Interface Metaphors. In The Art
of Human-Computer Interface Design, (ed B. Laurel), Addison
Wesley, Reading, MA, 65-73.
Goldstain, J., Roth, S. F., (1994), Using aggregation and dynamic
queries for exploring large datasets, in Proceedings CHI ‘94,
Human factors in Computing Systems, ACM Press.
Guglielmi, L., Miglioli, P., (1996) VRML, Jackson Libri S.R.L., Prima
Edizione, Pavia.
97
Bibliografia.
Guidotti, P. A., Martello, S., Natali, A., (1994), La programmazione
logica nella risoluzione dei problemi combinatori e discreti, in
Rivista di Informatica, Milano, vol XXIV, Nr 2, 97-127.
Haber, E. M., Ioannidis, Y. E., & Livny, M., (1994), Foundation of
Visual Metaphors for Schema Display. Journal of Intelligent
Information Systems, 3, 1-38.
Hemmje,
M.,
Kunkel
C.,
Willet
A.,
(1994),
Lyberworld-A
Visualization User Interface Supporting Full Text Retrieval, in
Proceedings of ACM SIGIR’94, July 3-6, Dublin, 1994.
Lakoff, G., and Johnson, M., (1980), Metaphors We Live By. The
University of Chicago Press, Chicago.
Levine, J., Mason,T., Brown, D., (1992), Lex & Yacc. Second Edition.
O'Reilly and Associates, Sebastopol, CA..
Mackworth, A. K., (1977), Consistency in networks of relations.
Artificial Intelligence, 8 99-118.
Madsen, K. H., (1994), A Guide to Metaphorical Design.
Communications of the ACM, 37, 57-62.
Marcus, A., (1994), Managing Metaphors for Advanced User
Interface. Proceedings of International Workshop AVI'94, ACM
Press New York, 12-18.
Martin, J. H., (1990), A Computational Model of Metaphor
Interpretation. Academic Press, San Diego.
Massari, A., Pavani, S., Saladini, S., Chrysanthis, P. K., (1995), QBI:
Query By Icons, Proc. of The International Conference ACMSIGMOD, S Jose California USA.
Massari, A., Saladini, L., Hemmje, M. and Sisinni, F., (1997), Virgilio:
A Non-Immersive VR System To Browse Multimedia Databases,
98
Bibliografia.
In: Proceedings of the IEEE International Conference on
Multimedia Computing and Systems, IEEE Computer society
Press, Los Alamitos, CA, 573-580.
Meo-Evoli, L,. Rafanelli, M., Ricci, F. L., (1994) An interface for the
direct Manipulation of statistical Data, Journal of Visual
Languages and Computing, 5, pp. 175-202.
Mountford, S. J., (1990), Tools and Techniques for Creative Design. In
The Art of Human-Computer Interface Design, (ed B. Laurel),
Addison Wesley, Reading, MA, 17-30.
Paradiso, A., Hemmje, M., (1997), A Generic Refinement of the
Virgilio System's Design and a Prototypical Architecture. GMD
Technical Report, Nr. 1093, September 1997.
Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S., Carey, T.,
(1994), Human Computer Interaction, Addison Wesley,
Wakingham, England, 207-209.
Robertson G. G., Card S. K. and Mackinlay J. D., (1993),
Nonimmersive Virtual Reality, IEEE Computer, 26(2), 81-83.
Sarkar, M., Brown, M. H., (1994), Graphical Fisheye Views,
Communications of ACM, Dec 1994, vol. 37, No 12, pp. 73-83.
Schalkoff, R. J., (1990), Artificial Intelligence: An engineering
Approach, MC Graw Hill, New York.
Van Hentenrick, P., (1989), Costraint Satisfaction in Logic
Programming. MIT Press, Cambridge, Ma.
Zloof, M. M., (1976), Query By Example: Operation on the Transitive
Closure, Tecnical Report RC5526, IBM Research, Yorktown
Heights, 1976.
99
