3.4.4 ricerca per parola chiave
Le strutture precedentemente implementate avrebbero permesso una consultazione della bibliografia già abbastanza personalizzabile da parte dell’utente, tuttavia essa era vincolata al fatto che la visualizzazione avrebbe riguardato tutta la bibliografia digitale, e non vi sarebbe stata la possibilità di poter interrogare l’archivio con una query,[1] ed estrarre quindi solo gli elementi che corrispondenti ad un’interrogazione più precisa.
La struttura che avrebbe permesso l’interrogazione all’archivio avrebbe costituito la risorsa di I.R. principale della biblioteca digitale, e come da progetto avrebbe dovuto articolarsi in due tipi di ricerca per parola chiave:[2]
1. ricerca per campi: dove la query sarebbe stata digitata dall’utente tramite un form che avrebbe presentato diversi campi sotto cui vincolare e ricercare la stringa inviata,
2. ricerca libera: la query sarebbe stata svincolata dai campi rappresentati dal form precedente, ed avrebbe invece interrogato la tabella libri nel campo free, costruito per rappresentare i contenuti ed i temi principali del record archiviato.[3]
Un menù avrebbe permesso all’utente di scegliere se effettuare una ricerca libera, svincolata dai campi bibliografici, oppure se vincolare la propria interrogazione ai campi della scheda bibliografica. Il menù avrebbe consentito di raggiungere gli appositi forms, costituenti anch’essi da realizzare in Php.
Ogni form, infatti, avrebbe dovuto contenere il codice di programmazione necessario a ricevere la query digitata, le opzioni di interrogazione, e quindi andare ad effettuare la ricerca interrogando la tabella libri del database bibliografiapiste.
Poi avrebbe dovuto contenere tutte le funzioni necessarie all’estrazione dei record attinenti alle keywords immesse dall’utente, e dunque avrebbe dovuto generare un indice puntato di documenti ordinandoli secondo i criteri prestabiliti.[4]
Ogni elemento dell’elenco puntato, rappresentazione di un documento, così come quanto realizzato per l’ordinamento per campi della bibliografia, avrebbe puntato a doc.php, la pagina che avrebbe descritto visualizzando anche il campo abstract, la scheda bibliografica completa dell’elemento selezionato.
La prima pagina, key.php, di facile realizzazione, avrebbe contenuto una succinta introduzione al funzionamento ed alle prestazioni del motore di ricerca che ci si accingeva ad usare.
3.4.6 ricerca
vincolata ai campi
La ricerca per campi avrebbe dovuto sopperire alla possibilità di effettuare un’interrogazione al database tramite query da compilare nell’apposito form, la cui stringa (una o più parole) avrebbe dovuto essere ricercata all’interno del campo corrispondente a quello del form in cui l’utente lo avesse digitato.
In un archivio, come nella bibliografia digitale in questione e come già molto abbondantemente descritto precedentemente, ogni documento sarebbe stato rappresentato da da più campi organizzati in una tabella, ma non tutti i campi sarebbero stati necessari per la ricerca ed il reperimento dei documenti in modo efficiente: solo i più rappresentativi sarebbero risultati importanti ai fini delle operazioni di I.R. da eseguire sul corpus di testi.
Questi sarebbero stati come in qualsiasi sistema di biblioteca digitale:
· titolo,
· autore,
· soggetto, nel caso in questione, un corpus di testi egittologici, il soggetto sarebbe comunque appartenuto a questi particolari campi semantici
· topografia, campo ponderante per l’estrazione di determinati documenti rispetto ad altri
Il form destinato a ricevere la query digitata dall’utente avrebbe dunque dovuto contenere 4 moduli entro cui poter scrivere una stringa di ricerca: le 4 stringhe sarebbero state caricate su una variabile locale e trasmesse alla procedura di ricerca.
La prima funzione da implementare per il funzionamento corretto della procedura di ricerca sarebbe consistita nel testare che almeno uno dei quattro moduli del form fosse stato riempito, condizione essenziale prima di effettuare un’interrogazione inutile verso il database che avrebbe avuto come risultato un errore da parte di MySql stesso.[5]
Il caso più semplice da rendere funzionante avrebbe coinciso con un solo campo riempito, e dunque la procedura di ricerca avrebbe dovuto gestire l’interrogazione esclusivamente verso il campo selezionato.
Era necessario inserire il codice opportuno
per far estrarre dal database con un ciclo contenente le stesse istruzioni
(passaggio di dati da campi di ciascuna riga della tabella libri ad array di
appoggio e dunque alla variabile di visualizzazione finale) usate per
l’estrazione dei dati nelle precedenti interrogazioni, ma avrebbe dovuto essere
posta una condizione vincolante l’estrazione: il campo della tabella e a quello
corrispondente selezionato nel form avrebbero
dovuto contenere lo stesso valore;[6] la
condizione doveva essere espressa durante
Tuttavia questa struttura era limitata all’estrazione di determinati elementi dalla tabella libri rispetto ad una query vincolata ad un solo campo, mentre l’obbiettivo sarebbe stato quello di poter rendere la ricerca il più precisa possibile, specificando gli altri campi.
Nel caso in cui, cioè, l’utente avesse riempito più di un modulo del form, il motore di ricerca avrebbe dovuto estrarre dalla tabella libri solo quei record che avessero soddisfatto contemporaneamente la struttura di confronto elaborata precedentemente riguardo ad un solo campo.[8]
Ad esempio: ipotizzando che l’utente avesse digitato nel 1° campo la stringa x, lasciato in bianco il campo 2° e 4°, mentre nel 3° egli avesse inserito la stringa y, la procedura avrebbe dovuto estrarre e visualizzare solo quei record della tabella libri che avessero contenuto nel valore dei propri campi corrispondenti al 1° e 3° del form, rispettivamente, sia la stringa x sia la stringa y.
Non avrebbe avuto molto senso abilitare il motore di ricerca ad estrarre quei documenti che avessero presentato l’una o l’altra stringa all’interno dei campi corrispondenti, poiché il risultato dell’interrogazione sarebbe stato equivalente a 2 interrogazioni distinte, ciascuna per campo, che avrebbe reso molto più leggero il processo di estrazione dei documenti.
Riprendendo
quindi il codice utilizzato per l’estrazione dei documenti relativi alla query vincolata ad un solo campo,
l’operatore where della funzione select avrebbe dovuto contenere la casistica
di contemporaneità di nomecampotabella LIKE '%$keyN%' per tutti
i campi adottati come dominio di ricerca.[9]
Dunque aver implementato il
controllo per l’esecuzione o meno della funzione di select verso la tabella illustrato
precedentemente[10] si sarebbe rivelato fondamentale anche in questo
caso, perché la condizione vera e contemporanea di tutti i controlli si sarebbe
verificata anche quando venisse digitato per sbaglio o per volontà (oppure al
primo collegamento con la procedura key.php dove alle variabili $keyN il valore assegnato per
default sarebbe stato nullo) il pulsante di submit[11] senza aver riempito alcun campo del form di ricerca.
La funzione dunque avrebbe estratto i record relativi alla query incrociata ed avrebbe generato una pagina dinamica contenente, come da progetto, l’indice puntato relativo ai documenti estratti, che avrebbe fatto riferimento alla pagina dinamica doc.php che, come già visto per l’ordinamento dei documenti per campo, avrebbe fornito la scheda bibliografica completa del documento selezionato.
3.4.7 ricerca libera
La procedura che avrebbe dovuto eseguire la ricerca libera per keywords, ultima opzione di ricerca che sarebbe stata fornita all’utente, avrebbe rappresentato l’applicazione più difficile perché ricca di punti da sviluppare per una sua corretta implementazione.
La sua realizzazione, infatti, non si sarebbe limitata ad una struttura di procedure e di pagine, ma avrebbe modificato profondamente anche l’architettura del database bibliografiapiste ed il sistema stesso con cui finora erano state progettate ed implementate le sessioni d’interrogazione e di estrazione dei dati dalle tabelle del database.
La procedura, infatti, avrebbe dovuto eseguire un’interrogazione verso la bibliografia digitale che non fosse però limitata ai campi specifici della rappresentazione della scheda bibliografica.
Prima di tutto, essendo la query svincolata da ogni sottodominio,[12] sarebbe stato necessario fornire la possibilità di distinguere un’opzione relativa alla struttura fisica della query stessa.[13]
Se essa fosse stata costituita da una sola parola, [14] il problema non sarebbe sussistito, poiché la parola sarebbe stata ricercata tramite le strutture che saranno illustrate successivamente, e l’interrogazione avrebbe provveduto all’estrazione dalla tabella libri dei testi corrispondenti.
Nell’altro caso[15] sarebbe stato necessario distinguere le seguenti opzioni:
· ricerca di tutte le parole: dove cioè si andasse a cercare quei documenti che avessero contenuto nelle strutture apposite tutte le parole presenti nella stringa di query, anche in ordine sparso e non necessariamente seguendo la sequenza digitata dall’utente. Le parole della query sarebbero state dunque inserite all’interno di un’espressione costituente la struttura della funzione di select, le cui singole strutture di controllo, ciascuna per parola, sarebbero state connesse da una relazione di tipo AND, (vedi a fine capitolo la figura relativa)
·
ricerca
di almeno una delle parole : la procedura avrebbe dovuto estrarre tutti
i record della tabella nel cui campo dedicato alla ricerca libera fossero state
contenute almeno una delle parole costituenti
· ricerca della frase esatta: la procedura avrebbe dovuto considerare la query come una stringa intera, senza suddividerla in parole, ed avrebbe dovuto estrarre i documenti della tabella libri che avessero contenuto esattamente la stringa di query al proprio interno.[17] (vedi a fine capitolo la figura relativa)
La scelta di una delle tre opzioni sarebbe dovuta avvenire all’interno dello stesso form che avrebbe accolto la query stessa, e sarebbe stato fornito tramite un menù a tendina.
Lo sviluppo delle prime due opzioni avrebbe implicato una manipolazione della query digitata dall’utente, infatti questa sarebbe stata trattata non nella sua integrità, ma elemento per elemento (e quindi parola per parola).
La riuscita delle prime due opzioni, quindi, sarebbe dipesa dall’implementazione di una procedura da applicare preventivamente alla query, detta di tokenizzazione, capace di scomporre la stringa in un array di parole il cui numero di elementi sarebbe coinciso con il numero delle parole costituenti la stringa iniziale, e dove ogni elemento ne avrebbe contenuta una (token), e solo a questo punto sarebbe stato possibile sviluppare le opzioni di ricerca.
L’obbiettivo principale della ricerca libera, tuttavia, non sarebbe stato solo il servizio delle tre opzioni di ricerca applicabili alla query, ma avrebbe dovuto consistere nello svincolare la ricerca per parola chiave dai campi della tabella libri, per poter eseguire un’interrogazione ad un livello concettuale più astratto, più elevato, andando cioè ad interrogare circa il contenuto e gli argomenti principali dei testi della bibliografia digitale.
Infatti tutti i tre criteri di ricerca erano riferiti ad una struttura contenuta nel database bibliografiapiste ancora indefinita, che avrebbe dovuto archiviare la rappresentazione dei contenuti dei testi.
Questa rappresentazione avrebbe dovuto avere la caratteristica di rimanere invisibile all’utente, ma di riuscire a rendere reperibili tutti i documenti della bibliografia tramite delle chiavi comuni ad essi, e connotate in modo che rispecchiassero i criteri logici di una possibile interrogazione.
Le chiavi di ricerca avrebbero rappresentato gli argomenti principali di ciascun documento, e quindi avrebbero dovuto puntare a tutti gli elementi della bibliografia i cui contenuti fossero riconducibili al determinato argomento, mentre ogni documento avrebbe potuto puntare anche a tutti gli argomenti identificati all’interno della bibliografia digitale.
Sarebbe stato necessario costruire due nuove strutture all’interno del database bibliografiapiste:
· una nuova tabella che avrebbe accolto ed archiviato gli argomenti detta infor, indicizzati in modo da poterli facilmente relazionare,
· un nuovo campo all’interno della tabella libri che avrebbe invece contenuto la relazione agli argomenti di cui il testo avesse trattato, detto free, costituito dallo stesso indice che avrebbe connotato la tabella infor.
Il funzionamento della ricerca libera sarebbe stato diverso dalle interrogazioni precedenti: infatti la query sarebbe stata manipolata nel caso in cui si desiderasse effettuare la ricerca di tutte o di almeno una delle parole dell’interrogazione, e quindi l’interrogazione non avrebbe più riguardato direttamente la tabella libri, ma sarebbe stata destinata alla tabella infor, contenente una struttura capace di rappresentare i concetti generali contenuti all’interno della bibliografia, e dove presente, avrebbe estratto il valore del campo di indice di questi elementi.
Questi valori sarebbero poi andati a costituire una nuova espressione di una funzione di select, stavolta destinata ad interrogare il campo free della tabella libri, e la funzione avrebbe estratto solo i documenti nel caso in cui i due indici avessero coinciso, e cioè se il valore dell’espressione di select fosse corrisposta al valore del campo free.[18]
Interrogazione
libera per parola chiave con opzione “tutte le parole”
Interrogazione
libera per parola chiave con opzione “almeno una parola”
Interrogazione
libera per parola chiave con opzione “frase esatta”