English. This paper presents an ongoing work for allowing users to ask questions in natural language to a database management system on the domain of recipes. The system translates questions from Italian language to SQL exploiting an interlingua represented by a logical formalism such as relational calculus. There are two specific features of this project: first, the use of relational calculus as semantic representation for interlingua translation; second, the role played by pragmatic information, that is the Mediterranean diet domain implicitly encoded in the database schema.
Italiano. Questo articolo presenta un
progetto in corso sulla per permettere a
degli utenti di porre domande a un
database management system nell’ambito del
dominio delle ricette. Il sistema
traduce le domande da italiano a SQL
sfruttando una rappresentazione logica
interlingua che consiste nel calcolo
relazionale. Ci sono due specifiche
caratteristiche di questo progetto: l’uso del
calcolo relazionale come rappresentazione
semantica della traduzione interlingua e il
ruolo giocato dall’informazione
pragmatica, che consiste nell’uso del dominio della
dieta mediterranea che e` stato codificata
nello schema del database.
L’accesso a grandi moli di dati da parte di
persone comuni e` una delle molteplici sfide affrontata
da anni per permettere una piu` fluida interazione
uomo-macchina. La natura della comunicazione
umana presenta molti aspetti difficili da
formalizzare tramite regole precise: ambiguita` nell’uso di
parole ed espressioni, differenze culturali ed
idiomatiche, l’affidamento ad informazioni implicite
date dal contesto. Questo e` vero anche in
specifici domini, come quello che lega le persone al
cibo
In questo lavoro presentiamo una NLI per
interrogare una base di dati nel dominio della dieta
mediterranea. Una domanda su tale dominio espressa
in lingua italiana verra` analizzata mediante l’uso
di una grammatica feature-based context-free,
rappresentata mediante il calcolo relazionale su tuple,
e infine trasformata in SQL mediante un processo
ricorsivo basato sulla pragmatica del dominio
applicativo. Un elemento distintivo di questo
progetto, rispetto ai classici esempi di conversione basati
sulla logica del primo ordine
sulla sintassi
In questa sezione consideriamo alcuni lavori sul
tema della traduzione da linguaggio naturale a
SQL che fanno uso della sintassi, seguendo lo
schema proposto in
Negli approcci basati sul Parsing si derivano
gran parte delle informazioni ricavabili a partire
dalla struttura della frase in input. Tramite
questo approccio e` possibile riconoscere dipendenze
complesse tra i singoli elementi sintattici,
spesso introdotte da particolari espressioni o da
preposizioni: si attribuisce quindi un valore
semantico alla struttura logica della domanda
analizzata. Querix, ad esempio, fornisce un’interfaccia
per l’interrogazione di ontologie tramite la
generazione di una query SPARQL
Gli approcci basati su Grammatiche si
appoggiano largamente sulle regole di produzione: a
differenza dei sistemi descritti in precedenza, in
questi approcci e` possibile stabilire a priori quali tipi
di domande sia interpretabile e quali no. Da
questa capacita` segue quindi la possibilita` di
implementare un interfacciamento piu` interattivo, dove
la validita` di una domanda in input puo` essere
determinata durante la stessa fase di inserimento e
guidata da parte di feedback visivi. In TR
Discover, ad esempio, la prima fase di traduzione
della query consiste nel suo parsing su una
FeatureBased Context-Free Grammar (FCFG) dove
regole lessicali, generate dai nomi degli attributi della
base di dati, e regole grammaticali, le quali
definiscono la composizione delle informazioni estratte,
permettono di ottenere composizionalmente come
rappresentazione intermedia una formula nella
Logica del Primo Ordine (FOL)
Nel dominio della dieta alimentare il progetto
MADiMAN (Multimedia Application for Diet
MANagement) si pone come obiettivo quello di fornire
un intermediario semi-automatizzato (un “dietista
virtuale”) tra l’utente e la gestione della sua
alimentazione: a partire da informazioni quali dati
biologici individuali, una definizione della dieta
da seguire (basata su quantita` di macronutrienti)
e un aggiornamento costante sullo storico dei
pasti, il sistema cloud-based e` in grado di
proporre diversi servizi volti alla pianificazione dei pasti
futuri, alla persuasione dell’utente verso una sana
alimentazione e all’interazione efficace con queste
informazioni
Nel considerare il dominio di interesse e` necessario pensare ai dati stessi su cui andiamo a lavorare. Gedeone1 e` un portale di Coop Italia dedicato a promuovere un sano stile di vita e dieta proponendo consigli, articoli e soprattutto ricette. Al fine del progetto MADiMAN, le informazioni presenti su questo sito sono state manipolate e trasposte in una base di dati con DBMS PostgreSQL, rendendo disponibili un gran quantitativo di ricette (circa 500), passi preparativi, ingredienti, valori nutrizionali e vari metadati.
Un’ulteriore componente dello schema analizzato include dati e tabelle su utenti e la loro dieta, lo storico dei pasti e delle pesate.
Per gli obiettivi di questo lavoro e` stato deciso di considerare la parte del database relativa alle ricette trascurando la parte relativa alla pianificazione dei pasti considerando il punto di vista di un utente non esperto del funzionamento della memorizzazione dei dati, ancor meno di come questi siano strutturati internamente. 4
Primariamente e` stato costruito un corpus di 12
domande in Linguaggio Naturale2 (Tabella 1). Gli
scopi di questo piccolo corpus sono
principalmente due. Primo, nel progettare un sistema che si
interfacci con una persona tramite un unico
passo in un caso d’uso ipotetico (inserimento
testuale), e` stato necessario pensare a delle domande
plausibili che un utente medio potrebbe porre
tramite applicativo. E` stato ipotizzato a questo
fine che le informazioni piu` desiderabili derivino
dalla possibilita` di consultare il ricettario,
ponendo domande implicitamente relative alla propria
dieta personale (per esempio, sapere l’apporto
calorico di un certo piatto) cos`ı come richiedendo
1http://www.gedeone-e-coop.it
2Il corpus completo e` disponibile online: http://ww
w.di.unito.it/˜mazzei/papers/clic2021/Qn
Acorpus.pdf
Tabella 1: Le 12 domande nel dominio delle
ricette di Gedeone ideate per la sperimentazione. Il
simbolo @ indica delle variabili nella domanda.
istruzioni ed ingredienti. Secondo, per
permettere il testing di un prototipo, ognuna di queste
domande e` stata scritta affinch e´ verificasse
l’abilita` del sistema nel riconoscere e derivare
all’interno della struttura sintattica particolari costrutti,
strutture ed operazioni appartenenti alla query
finale. Prendendo spunto da
A ogni domanda definita nel corpus e` stata associata una corrispondente query SQL, la cui correttezza e` stata verificata sul database. Mentre si e` cercato il piu` possibile di semplificare il formato della traduzione finale di ogni domanda in input, la necessita` a fini sperimentali di definire domande sempre piu` complesse ha portato ad ottenere alcune query con strutture articolate, il che ha talvolta reso arduo il processo di traduzione.
Il processo di traduzione di ogni domanda del corpus e` sequenziale e si divide in una fase preliminare di preanalisi, e in due fasi principali concatenate fra di loro.
Nella preanalisi la domanda in italiano e` suddivisa in token. Oltre a cio` sono riconosciuti ed estratti possibili valori di attributi relativi alla base di dati considerata ed e` attuata dove necessario una sostituzione con sinonimi. ParPP[PT=?pt, RL=?rl, LF=?fl, ORD=?ord] -> P[PT=?pt] NP[RL=?rl, LF=?fl, ORD=?ord] NN[ORD=<\x.asc(x, id)>] -> ’ordine’ Figura 1: Un frammento della FCFG usata per rappresentare la semantica di una domanda in Calcolo Relazionale. tendo dalla terza frase della Tabella 1, ovvero Quali sono i piatti con piu` di 40g di proteine?, la preanalisi, dopo aver eseguito tokenizazione e sostituzione dei sinonimi, restituisce: [quali, sono, i, ricetta, con, piu`, di, 40, grammi, di, proteineg].
La prima fase prende in input i token ottenuti in preanalisi e restituisce un albero sintattico annotato, ottenuto tramite il parsing dei token su una FCFG. E` ottenuta, come rappresentazione intermedia, un’espressione nel Calcolo Relazionale su Tuple.
Infine, nella seconda fase, le informazioni presenti nell’albero sintattico sono estratte tramite diverse visite, durante ognuna delle quali e` costruita una clausola della corrispondente query in SQL. Nel seguito dettagliamo il funzionamento delle due fasi principali e poi analizziamo le prestazioni del sistema. 4.1
In questo lavoro abbiamo usato delle grammatiche
libere da contesto con feature3 (FCFG)
utilizzando la libreria Python NLTK
Dopo le prime sperimentazioni si e` riscontrato
che questa forma intermedia, per quanto intuitiva
e formale, non permetteva una facile traduzione
finale nella seconda fase. Inoltre, fare affidamento
esclusivamente su una singola formula composta
limitava i potenziali vantaggi dati dall’uso delle
3La grammatica realizzata e` disponibile online: http:
//www.di.unito.it/˜mazzei/papers/clic202
1/calcolo relazionale.fcfg
FCFG. In questo cambio di direzione e` stato
riscontrato che una rappresentazione intermedia piu`
vicina all’obbiettivo della traduzione in SQL
poteva essere data da una query in calcolo relazionale.
Il Calcolo Relazionale su Tuple con
dichiarazione di Range e` un linguaggio formale che permette
di esprimere in modo dichiarativo una
interrogazione su una base di dati relazionale. In questo
formalismo una query comprende tre componenti:
Target List (TL), Range List (RL) e Logic Formula
(LF)
Target List: specifica quali attributi compaiono nel risultato. Poiche´ il riconoscimento degli attributi necessari dipende sia da quali vengano esplicitati nella domanda, sia dalle tabelle coinvolte, questa componente e` quasi completamente determinata nella seconda fase (a posteriori della parsing sintattico). Tramite le regole lessicali della grammatica sono riconosciuti gli eventuali attributi di tabelle, i cui simboli terminali sono annotati dalla loro rappresentazione nella feature LF, specificandone il tipo tramite la feature booleana +ATTR. Gli elementi restanti della Target List saranno in seguito derivati tramite una mappatura tabella-attributi.
Range List: specifica le variabili libere nella Formula Logica, cioe` le tabelle su cui variano le variabili della LF per generare il risultato. Similarmente agli attributi, anche le tabelle possono essere riconosciute esplicitamente (ed annotate con una feature +TABLE), oppure derivate da attributi riscontrati, ma non appartenenti a nessuna tabella trovata fino a quel momento. In entrambi i casi la loro semantica e` raccolta nella feature RL di una produzione terminale e, come per gli attributi, i diversi elementi saranno raccolti nella fase successiva attraversando l’albero sintattico annotato.
Logic Formula: specifica una formula che il risultato deve soddisfare. A differenza delle precedenti, la LF (feature LF) e` composta ricorsivamente e i suoi predicati possono essere introdotti non solo nelle regole lessicali, ma anche nelle produzioni non terminali tramite il riconoscimento di particolari strutture sintattiche. La composizione della formula a partire da feature di nodi diversi e` effettuata tramite le astrazioni del lambda-calcolo: definendo predicati parziali in un nodo e` possibile applicarli a formule ed argomenti provenienti dagli altri nodi della stessa produzione in una semplificazione chiamata Beta-riduzione. Questa avviene automaticamente durante il parsing sintattico tramite NLTK, ed il risultato, se presente, e` visibile nella radice dell’albero sintattico.
A differenza di SQL, il Calcolo Relazionale, per propria natura, non esprime esplicitamente un ordinamento sull’insieme di tuple risultante (corrispondente al costrutto ORDER BY di SQL). Per compensare questo aspetto si e` deciso di utilizzare una feature aggiuntiva ORD, definita in modo simile alla feature LF ma utilizzata esclusivamente per mantenere tramite predicati le informazioni di un eventuale ordinamento esplicito (riconosciuto a livello lessicale da espressioni come “in ordine di”, “con meno/piu` X”, ecc.) In generale il processo di traduzione della prima fase e` completamente automatizzato: il parser utilizzato e` generato tramite una funzione della libreria NLTK e necessita solamente della definizione di una grammatica. Il parsing dei token in input restituisce dunque un albero sintattico annotato con feature.
Partendo dalla preanalisi della frase Quali sono i piatti con pi u` di 40g di proteine?, si ottiene l’analisi sintattica in Fig. 2(a), e la corrispondente rappresentazione in calcolo relazionale in Fig. 2(b). 4.2
La costruzione dell’interrogazione SQL utilizza l’albero sintattico e la corrispondente formula del calcolo relazionale ottenute entrambe nella fase precedente, insieme a ulteriori dati provenienti dal dominio di interesse, e che sono implicitamente codificate nel database di riferimento. Mentre con la prima fase si e` potuto modellare la conoscenza derivata dalla domanda iniziale, molto di cio` che ci serve sapere non e` direttamente derivabile da una domanda in italiano. Inoltre, poiche´ l’obbiettivo di questo progetto rimane la creazione di un sistema che operi su un dominio definito, e` necessario che le informazioni piu` importanti riguardanti questo siano definite ed accessibili nel sistema: queste informazioni sono fondamentali per stabilire i legami tra cio` che e` stato chiesto e i nomi effettivi di tabelle e attributi.
Il processo di traduzione finale segue un algoritmo generale comune: per ogni clausola principale di SQL viene visitato l’albero sintattico e, grazie anche alle informazioni dal dominio, viene generata la clausola componendo ivalori nelle feature.
In particolare:
SELECT: La lista di attributi da restituire corrisponde alla Target List del Calcolo Relazionale. E` possibile riconoscere due tipi di attributi appartenenti a questa. (i) Ogni tabella introdotta, esplicitamente o meno (riconosciuta a partire dalla feature +TABLE oppure derivata da un suo attributo), comprende uno o piu` attributi di default, oltre a quelli di chiave primaria. Questo tipo di mappatura e` un esempio di informazione pragmatica proveniente dal dominio e codificata nella tabella. (ii) Per quanto riguarda invece gli attributi non presenti in alcuna tabella, questi possono semplicemente essere riconosciuti da una regola lessicale (tramite la feature +ATTR) ed aggiunti in coda all’elenco.
FROM: Un’assunzione importante e` stata fatta nella gestione dei join, ovvero che le tabelle avessero sempre delle chiavi esterne definite esplicitamente. Cio` semplifica notevolmente la traduzione, in quanto e` sufficiente conoscere le tabelle coinvolte per poter generare l’intera clausola comprensiva delle condizioni di join. L’algoritmo di generazione riconosce i vincoli di chiave esterna tramite due cicli, che compongono la clausola risultante con gli attributi necessari. Da notare che sia i vincoli relazionali, sia gli alias delle tabelle sono definiti tramite dizionari.
WHERE: Questa clausola e` l’unica costruita a partire dalle informazioni provenienti dalla LF.
I predicati di questa sono indicati in un formalismo piu` simile a quello della FOL rispetto al Calcolo Relazionale, al fine di aderire alla sintassi delle formule di NLTK. Per ognuno dei predicati si effettua una traduzione corrispondente rappresentazione in SQL.
ORDER BY: Come la clausola WHERE, la costruzione di questa clausola e` determinata dal valore della feature ORD nella radice dell’albero sintattico. Per i fini della nostra implementazione e` stato deciso di adottare, nel caso in cui la feature ORD risulti vuota, un ordinamento di default sull’attributo di chiave primaria della tabella principale coinvolta.
Considerando ancora la terza frase della Tabella 1, il risultato della seconda fase di traduzione e` in Fig. 2-(c). (S[FL=<maggiore(ric(ricetta),proteineg,40)>, ORD=?ord] (VP[] (PI[NUM=’pl’, QRT=’qual’] Quali) (IV[NUM=’pl’] sono)) (NP[FL=?fl] (DET[NUM=’pl’] i) (NN[RL=<ric(ricetta)>, +TABLE] ricetta)) (PP[FL=<maggiore(ric(ricetta),proteineg,40)>, ORD=?ord, PT=’with’, RL=?rl] (P[PT=’with’] con) (NP[FL=<maggiore(ric(ricetta),proteineg,40)>] (ADV[FL=<\z y x.maggiore(x,y,z)>] piu`) (PP[FL=<40>, ORD=?ord, PT=’of’, RL=?rl] (P[PT=’of’] di) (NP[FL=<40>] (CARD[FL=<40>] 40) (NN[] grammi))) (PP[FL=<proteineg>, PT=’of’, RL=<ric(ricetta)>] (P[PT=’of’] di) (NN[+ATTR, FL=<proteineg>, RL=<ric(ricetta)>] proteineg))))) (a) (b) (c) {TL=ric.id, ric.descrizione, ric.nome , ric.proteineg | RL=ric(ricetta) | LF=maggiore(ric(ricetta),proteineg,40)} SELECT ric.id, ric.nome, ric.descrizione, ric.proteineg FROM Ricetta ric WHERE ric.proteineg>40 ORDER BY ric.id ASC; Figura 2: Il risultato della prima fase di analisi (a-b) e della seconda fase di analisi (c) sulla frase Quali sono i piatti con piu` di 40g di proteine?.
Nella sperimentazione preliminare e` stato possibile implementare la traduzione solamente di 7 domande rispetto alle 12 inizialmente definite nel corpus4. Seguono i limiti incontrati per alcune delle interrogazioni non realizzate.
La domanda 6, Quanta acqua ho consumato il giorno @data, e` stata tralasciata poiche´ richiederebbe una gestione delle informazioni riguardanti un utente che abbia effettuato l’accesso al sistema.
Non e` stato possibile realizzare la domanda 10, “Quali sono le ricette con cottura in forno o a vapore” per la natura dell’operazione richiesta (un OR esclusivo), la quale richiedeva una sotto-query. Al momento non e` implementato un meccanismo che rilevi la presenza di sotto-interrogazioni a partire dalla struttura della frase.
Nella domanda 11, “Quali sono gli ingredienti per @people persone della ricetta @recipe?”, la difficolt a` incontrata e` stata la gestione dei valori NULL ottenibili in certi attributi.
La domanda 12, “Quali sono i piatti con pochi carboidrati?”, e` stata realizzata nella versione semplificata “Quali sono i piatti con meno car4Un elenco completo dell’output e` disponibile a http: //www.di.unito.it/˜mazzei/papers/clic202 1/OutputPrototipo.pdf boidrati?”: la difficolt a` nell’includere una sottoquery (con annessa Window Function di SQL) ha portato a interpretare “pochi carboidrati” non come valori appartenenti al primo quartile sulla distribuzione totale, ma come quantita` al di sotto di una soglia di default.
In questo lavoro sono stati presentati i primi risultati di un progetto ancora in corso per interpretare una domanda in linguaggio naturale come un’interrogazione SQL nel dominio della dieta mediterranea. Le due caratteristiche principali di questo progetto sono state l’uso del calcolo relazionale su tuple per rappresentare il significato della frase (Sezione 4.1) e l’uso delle specificit a` del dominio per trasformare poi tale rappresentazione in SQL (Sezione 4.2).
In futuro intendiamo completare le
interrogazioni contenute nel corpus proposto per poi
integrare il prototipo in un agente conversazionale sul
dominio della gestione di una dieta salutare.
Considerando la presenza di indeterminatezza nel
linguaggio naturale, potrebbe essere interessante
dare supporto per estensioni del modello
relazionale che trattano indeterminatezza