4.3 manipolazione della query per I.R.S. più efficiente
La struttura implementata per la realizzazione della ricerca libera per keywords si sarebbe basata dunque sull’elaborazione della stringa originale di query.
Essa sarebbe stata scomposta in tokens, i quali sarebbero stati cercati all’interno dell’ontologia infor, rappresentazione dei contenuti semantici dei documenti contenuti nella bibliografia, e dunque gli idi estratti dai documenti che avessero rispettato le condizioni della prima interrogazione, avrebbero costituito l’espressione della seconda query di select destinata all’interrogazione verso la tabella libri.
Tutti i processi di questa successione di operazioni sarebbero stati cruciali ed essenziali, e l’ottimizzazione anche di uno solo di essi avrebbe costituito un miglioramento di tutta l’operazione di I.R..
La seconda parte del processo di interrogazione per query libera non sarebbe stato direttamente suscettibile di ulteriori miglioramenti, poiché l’estrazione dei documenti dalla bibliografia in modo efficiente sarebbe dipesa dal corretto funzionamento della prima funzione di select, ossia dalla capacità delle procedure implementate nel riuscire a risalire ai giusti campi idi della tabella infor dalle parole della query tokenizzata.
Dunque i miglioramenti al sistema avrebbero dovuto riguardare proprio quest’ultima parte citata, ed essere inserite nella successione delle procedure di interrogazione dopo il processo di tokenizzazione e prima della funzione di select delle parole tokenizzate della query verso l’ontologia infor.
Infatti la parte precedente risultava già ben architettata, e fino al momento in cui la query non venisse tokenizzata e quindi trasferita all’array,[1] non sarebbe stato possibile aggiungervi processi o modificarne le prestazioni.
Sarebbe invece stato possibile applicare tutta una serie di strutture, nell’ordine di quanto esaminato nella sezione dedicata all’I.R., che avessero potuto eseguire delle operazioni di normalizzazione e di stemming sulla query inserita dall’utente.
In realtà un primo e flebile processo di normalizzazione della stringa di query sarebbe già avvenuta durante la sua tokenizzazione, ma vi erano altre operazioni inseribili fra la tokenizzazione e la costruzione della prima funzione di select.
Un esame distaccato dal contesto in questione della stringa ridotta a tokens avrebbe potuto portare ad una visione astratta della stringa rappresentata all’interno dell’array ad un insieme di elementi,[2] ed ogni elemento avrebbe costituito un ciclo nel primo processo di select, visto che ognuna di queste parole avrebbe potuto essere una chiave potenziale riconducibile ad un argomento dell’ontologia infor.
Preso atto di quanto affermato, era evidente che la durata della prima interrogazione verso il database sarebbe stata in relazione diretta col numero di parole in essa cercate, [3] e dunque una prima ottimizzazione avrebbe potuto consistere nell’eliminazione di elementi superflui, nello specifico rappresentati da parole inutili e ridondanti quali gli articoli, le preposizioni semplici e composte, ecc…,il cui insieme è detto stopwords.
L’eliminazione delle stopwords, oltre a diminuire i tempi di esecuzione di tutta la prima funzione di select, avrebbe migliorato l’efficienza del funzionamento di tutta la struttura, poiché per le strutture di controllo usate all’interno delle procedure le parole di stop avrebbero costituito elementi che avrebbero portato a fraintendimenti: prendiamo ad esempio le due stringhe x = ’ il deserto occidentale ’ ed y = ‘ deserto occidentale ’.
Ipotizziamo di eseguire due interrogazioni distinte, la prima con la stringa x e la seconda con la stringa y: secondo le strutture implementate fino a questo momento entrambe sarebbero state tokenizzate, e quindi avremmo ottenuto i seguenti array:
|
ArrayX |
ArrayY |
||||||||||
|
|
Ogni elemento di ciascun array avrebbe poi costituito un’espressione di select verso la tabella infor, e quindi è subito evidente che mentre la funzione di select relativa alla query X avrebbe compiuto un ciclo in più della funzione di select relativa alla query Y peggiorando nella velocità di esecuzione.
Inoltre ipotizzando che l’utente avesse
selezionato l’opzione di ricerca almeno una parola, allora i documenti estratti
tramite
Se invece vi fossero state una serie di strutture capaci di riconoscere che l’articolo “il” avrebbe potuto essere eliminato, le query avrebbero potuto estrarre, come dovuto, gli stessi documenti.
La struttura da realizzare avrebbe dovuto quindi esaminare che ogni elemento dell’array non fosse stato una stopwords, e nel caso contrario provvedere alla generazione di un nuovo array privo dell’elemento da eliminare.
Ma vi sarebbero stati altri casi di ambiguità costituita semplicemente dal modo nel quale venivano scritti gli stessi concetti, e quindi essendo i concetti espressi gli stessi, se essi fossero stati stringa di una query, anche i documenti che alla fine l’interrogazione avrebbe dovuto estrarre dovevano essere gli stessi.
Riassumendo, prima di analizzare nel dettaglio l’implementazione delle procedure di Tokenizzazione, di Stopwords e di Normalizzazione e Stemming, il sistema di ricerca libera per keywords si sarebbe arricchito di queste due ulteriori strutture, che avrebbero permesso di ridurre i tempi di interrogazione verso il database, ed avrebbero eliminato degli elementi ridondanti, possibili fonti di ambiguità e di fraintendimento di query riconducibili allo stesso significato.
4.4 tokenizzazione
Per tokenizzazione si intende quel processo di manipolazione di una stringa attraverso il quale essa viene suddivisa in unità basilari (parole) dette tokens: ogni token è rintracciabile tramite un indice, e può essere connotato con delle informazioni aggiuntive, come la propria analisi sintattica e semantica.
Nel caso specifico la tokenizzazione avrebbe dovuto limitarsi ad una manipolazione fisica della stringa, e non sarebbe stato necessario connotare il token di alcuna informazione aggiuntiva, se non di un semplice indice numerico per la sua reperibilità.
La tokenizzazione sarebbe stata eseguita con poche righe di codice grazie alla vasta gamma di funzioni per la manipolazione delle variabili ed, in questo caso, più precisamente, delle stringhe di testo offerte da Php.[4]
Tramite la funzione predefinita explode sarebbe stato possibile, utilizzando un array come variabile d’appoggio, suddividere la stringa, parola per parola, in base ad un carattere separatore: il risultato sarebbe stato un array composto da N elementi dove N corrisponde al numero delle parole contenute nella stringa sottoposta alla funzione di esplode, ed avrebbe sopperito anche all’indicizzazione dei tokens; ciascun elemento dell’array avrebbe contenuto dunque una parola della query.
La tokenizzazione inizialmente presa in considerazione per implementare le opzioni di ricerca libera-tutte le parole e/o ricerca libera-almeno una parola della funzione di ricerca libera, divenne poi necessaria anche per la corretta esecuzione dell’estrazione dei campi idi dalla tabella infor per l’esecuzione di un processo di I.R. che corrispondesse ai criteri proposti dal C.L.I.R., e sempre riguardo alla realizzazione di un sistema di I.R., la tokenizzazione avrebbe costituito la base senza la quale non sarebbe stato possibile sottoporre la query ad alcun processo di normalizzazione e di stemming.[5]
4.5 eliminazione delle stopwords
In base a quanto affermato precedentemente sarebbe stato necessario implementare una procedura che intervenisse, dopo la tokenizzazione della query, e testasse per ogni token, se il suo valore corrispondesse a quello di una stopword.
La procedura avrebbe dovuto scorrere quindi tutto l’array contenente la stringa di query precedentemente tokenizzata ed eseguire il controllo relativo alla presenza o meno di stopwords; nel caso in cui esse fossero state trovate, allora avrebbe dovuto sopperire alla loro eliminazione dall’array.
La prima risorsa di cui la procedura di eliminazione delle stopwords avrebbe avuto bisogno sarebbe dunque una lista delle parole di stop in base alla quale eseguire tutte le operazioni successive.
La lista avrebbe dovuto essere composta per ciascuna lingua rappresentata nel sito, dato che la sua redazione monolingue avrebbe compromesso il funzionamento del C.L.I.R. precedentemente implementato.
La struttura del database bibliografiapiste sarebbe stata nuovamente ritoccata, con l’aggiunta di una nuova tabella, stopwords che avrebbe accolto le parole di stop.
La tabella avrebbe contenuto un solo campo, detto parole, all’interno del quale sarebbero state inserite tutte le parole di stop utili e necessarie al funzionamento della struttura.
Così come realizzato per la tabella infor, anche per la tabella stopwords, una volta raggiunto lo spazio massimo supportato per ogni record, sarebbe stato possibile aggiungerne uno nuovo, inserendovi degli aggiornamenti alle lingue già rappresentate, o magari inserendo la rappresentazione di un nuovo linguaggio:[6]
|
Parole |
|
Italiano: di,a,di,da,in,con,su,per,tra,fra,il,lo,la,gli,le,questo,codesto,,
ecc… |
|
Inglese: a,of,an,from,on,with,over,up,for,throught,across,,long,
between,ecc… |
|
Portoghese:
a.bem,e,longe,para,se,você,abaixo,com,ela,mais,por,sem, ecc… |
|
Spagnolo: a,aquí,cuantos,esta,misma,nosotras,querer,tales,usted,acá,
ecc… |
La procedura, dunque avrebbe dovuto estrarre dalla tabella stopwords tutti i records, i cui valori sarebbero stati temporaneamente caricati all’interno di una variabile di appoggio.
La stringa di appoggio sarebbe anch’essa stata sottoposta alla funzione di explode,[7] e quindi tokenizzata, questo semplicemente per avere a disposizione un elenco indicizzato, parola di stop per parola di stop, al quale riferirsi con un semplice ciclo ricorsivo.
Infatti la struttura che avrebbe realizzato il confronto fra i tokens della query e quelli delle parole di stop sarebbe stato implementato con due cicli annidati[8] (dove cioè ogni giro del primo ciclo il secondo avrebbe compiuto tutte le proprie iterazioni) i cui indici sarebbero stati usati per lo scorrimento degli elementi dei due array.
I tokens dell’array contenente la tokenizzazione della stringa di query, se fossero stati identificati con un token di stop, avrebbero assunto come valore la stringa “ --- “ ad indicare la cancellazione dell’elemento.
La procedura poi avrebbe ricostruito la query, sempre mantenendola fisicamente tokenizzata, escludendo quegli elementi il cui valore fosse stato cancellato.
4.6 stemming per normalizzazione della query
La procedura di normalizzazione avrebbe dovuto realizzare due processi principali:
· avrebbe dovuto attingere ad un archivio contenente suffissi e prefissi da ricercare all’interno dei tokens della query,
· se questi fossero stati presenti avrebbe dovuto procedere alla loro elisione dal valore del token del quale avrebbero costituito o la testa (se prefissi), o la coda (se suffissi o flessioni), o entrambe (una struttura della del tipo: prefisso - tema o radice della parola - suffisso o flessione)
Come la struttura implementata per l’eliminazione delle stopwords dalla tokenizzazione della query avrebbe dovuto riferirsi ad una tabella nel database bibliografiapiste contenente l’archivio delle diverse parole di stop, così questa procedura avrebbe dovuto riferirsi ad una ulteriore tabella contenente i prefissi ed i suffissi eventualmente da eliminare dalle parole della query.
La tabella sarebbe stata chiamata normalizzatore, e sarebbe stata organizzata in campi:
· Suffissi: contenente le flessioni grammaticali, le desinenze da apporre alla radice di una parola
· Prefissi: contenente le strutture da premettere al tema od alla radice della parola.
Entrambi i campi avrebbero dovuto comprendere prefissi e suffissi di tutte le lingue rappresentate all’interno del sito, e quindi la tabella normalizzatore avrebbe assunto la seguente architettura:
|
Suffissi : |
are,ere,ire,ato,ata,ano,ana,imo,imi,nte,ecc... |
|
Suffissi : |
ing, es,s,er,ed,an,/’s,ecc… |
|
Prefissi : |
stra, super, iper,ecc… |
|
Prefissi : |
over,never,ever,ecc… |
La struttura, come le tabelle realizzate precedentemente, avrebbe avuto un’elasticità tale da poter essere prima di tutto aggiornata per l’inserimento di nuove stringhe nei campi già realizzati, e poi per l’aggiunta di nuovi suffissi e prefissi di ulteriori lingue.
La struttura della tabella, inoltre,
avrebbe consentito uno stemming con risultati corretti sia di stringhe monolingue
( a prescindere da quale fosse stata la lingua di redazione) sia multilingue,
mantenendo questa caratteristica già realizzata per la formulazione di query nel rispetto dei principi del C.L.I.R.
La prima parte della procedura di normalizzazione avrebbe dovuto provvedere all’estrazione dei prefissi e dei suffissi contenuti nei campi della tabella normalizzatore.
Questi sarebbero stati salvati temporaneamente in una stringa, poi sottoposta, come visionato per la procedura di stopwords, alla funzione di explode per ottenere una lista indicizzata delle strutture da utilizzare per la normalizzazione dei tokens di query.
La struttura di normalizzazione, allora, avrebbe dovuto procedere al processo di stemming: analizzare ogni token (precedentemente già passato dalla procedura di stopwords), ed identificarvi, se presenti, quei suffissi e quei prefissi aggiunti durante la corretta flessione grammaticale delle parole e presenti nell’array precedentemente generato dalla tokenizzazione dei contenuti della tabella normalizzatore tramite la funzione di explode.
Anche in questo caso sarebbero occorsi due cicli annidati per riuscire a controllare per ciascun token di query tutti i tokens di normalizzazione.
Una volta identificato il caso in cui la parola avesse contenuto in testa uno di questi prefissi, o in coda uno dei suffissi, il sistema avrebbe dovuto provvedere all’eliminazione delle parti superflue sostituendo all’interno dell’elemento in questione dell’array la parola priva della sua testa e/o coda.[9]
Sarebbe stato inoltre necessario, sempre nell’ordine di voler ricondurre ciascuna parola alla propria radice, controllare se la coda della parola già troncata, finisse per una vocale o per consonante.
Nel primo caso una ulteriore procedura avrebbe provveduto all’eliminazione della vocale, nel secondo caso la stessa avrebbe controllato se la consonante fosse stata una ‘s’, associabile alla flessione inglese e spagnola del plurale, e quindi anch’essa da eliminare.
A questo punto la query iniziale era stata manipolata profondamente ed al massimo livello possibile (senza chiaramente intaccarne le informazioni trasportate e necessarie all’interrogazione verso il database).
IL sistema di recupero delle informazioni sarebbe inoltre stato capace di eseguire interrogazioni multilinguistiche al database proprio grazie all’architettura delle procedure di normalizzazione ed alla costruzione dell’ontologia Infor, capaci di essere estese in qualsisasi momento al supporto di un nuovo linguaggio.
Sarebbe stato addirittura possibile formulare verso questo C.L.I.R.S. query contemporaneamente composte da parole in più lingue, come ad esempio: “caravan’s tracks del deserto occidentale”.
L’esempio di interrogazione è assolutamente
improbabile, ma illustra a dovere le potenzialità del sistema di C.L.I.R., che se implementato al
supporto delle lingue in gioco, avrebbe realmente trattato e manipolato l’interrogazione
ed il Retrival dei testi pertinenti
in modo del tutto indipendente dalla query stessa di partenza.