3.3 la realizzazione

3.3.1 costruzione della bibliografia topografica

Come da progetto, la costruzione della bibliografia topografica avrebbe dovuto consistere nella realizzazione di due principali tipi di pagine:

· la realizzazione dell’indice della bibliografia: organizzando le voci consultabili, specificando per ciascuna delle piste il sito di partenza, generalmente corrispondente ad un’oasi del deserto occidentale egiziano, o comunque ad un sito all’interno della depressione di una delle oasi, e quindi la destinazione, per poi raggrupparle secondo l’oasi di partenza in una sorta di albero i cui nodi sarebbero stati costituiti dalle oasi o dai toponimi di partenza, ed i rami le piste carovaniere che ivi partivano,

· la realizzazione, per ciascuna delle voci della bibliografia topografica, di una pagina contenente la bibliografia specifica relativa ed una descrizione della pista stessa e dei siti incontrati durante il proprio percorso. Dopo le opportune citazioni, la scheda avrebbe contenuto la descrizione dedotta dallo studio della bibliografia citata.

Entrambe le strutture avrebbero dovuto avere la versione corrispondente in Inglese, la cui realizzazione avrebbe usufruito del traduttore automatico BabelFish,[1] e sarebbero state tutte realizzate in HTML con un semplice sistema di links ipertestuali.

3.3.2 la costruzione dell’OPAC: il database Bibliografiapiste

Dopo aver istallato e configurato correttamente PhpMyAdmin sul Server[2] è stato possibile creare il database che avrebbe accolto le tabelle precedentemente progettate, chiamato quindi bibliografiapiste che avrebbe contenuto la tabella libri, preparata per archiviare i testi della bibliografia digitale

Il database sarebbe dunque stato pronto ad archiviare i diversi documenti costituenti la bibliografia, e tramite le strutture successivamente implementate avrebbe reso possibile la fruizione della bibliografia digitale sul web.

Ovviamente vi sarebbero stati due livelli d’accesso ai dati ed alle strutture del database bibliografiapiste corrispondenti a due diverse gerarchie: un superutente, capace di lettura e scrittura su tutti i dati e le architetture del database, ed un accesso utente, destinato al dialogo standard con la bibliografia, capace dunque di visualizzare i valori (solo alcuni) contenuti nelle diverse tabelle, ma privo dei permessi di modifica.

3.3.3 costruzione della tabella libri

La costruzione della tabella per la bibliografia consiste nella dichiarazione del numero di campi necessari[3] e delle variabili contenute nei campi[4]

Essa consisteva di 11 campi, uno in più di quelli progettati, e cioè il campo id, un identificatore numerico per fornire all’amministrazione un ulteriore strumento per identificare i record:[5]

Id :	Iint(11)
Type :	Tinytext
Author :	Text
Title :	Text
isbn/issn :	Bigint(20)
Publisher :	Text
Published :	year(4)
Subject :	Text
Topography :	Text
Abstract :	Longtext

Come già espresso nella fase di progettazione, questa struttura avrebbe descritto dettagliatamente ed esaurientemente qualsiasi testo della bibliografia digitale.

Avendo poi specificato praticamente tutte le “caratteristiche” di qualsiasi documento cartaceo, sarebbe stato possibile manipolarne i record contenuti toccando qualsiasi suo aspetto, potendo così fornire all’utente la possibilità di ordinare e cercare con precisione ogni testo per ogni suo aspetto: ad esempio sarebbe stato possibile ordinare tutti i documenti archiviati secondo il loro codice identificativo (isbn o issn), per autore, per titolo, ecc…, oppure eseguire una ricerca più mirata che, tramite appositi form, avrebbe permesso di cercare, ad esempio, un autore o un titolo in particolare oppure avendo più dati o desiderando testi più specifici, interrogando l’archivio bibliografico tramite una ricerca incrociata.[6]

Strumenti essenziali per una connotazione dettagliata di ciascun testo sono i campi topography, subject ed abstract:

• Il campo topography avrebbe costituito la risorsa tramite cui realizzare una bibliografia topografica, attraverso la quale sarebbe stato possibile visualizzare tutti i record della tabella libri, in ordine alfabetico, per toponimi o, come accennato precedentemente, eseguendo una ricerca più mirata, chiedendo al motore di ricerca di estrarre solo i documenti il cui campo topography contenesse il toponimo indicato nell’apposito form.

• Il campo subject avrebbe invece riassunto i topics salienti di ciascun testo, anch’esso reso come criterio d’ordinamento di tutti i documenti o come target di una ricerca per campo.

• Il campo abstract avrebbe fornito una sommarizzazione dettagliata dei contenuti del teso archiviato, costituendo quindi uno strumento di utilità enorme per quanti desiderassero consultare i testi estratti dalle proprie interrogazioni. [7]

---

[1] Vedi la parte dedicata agli applicativi di Machine Translation.

[2] Per la corretta configurazione di PhpMyAdmin, così come per comprendere l’istallazione del programma sul Server consultare i links forniti in nota 12. Esistono anche altre guide più o meno precise dedicate alla configurazione ed all’upload di PhpMyAdmin sul server, reperibili su portali che offrono servizi di web Hosting, come Lycos ( http://www.lycos.it oppure http://www.tripod.lycos.it/ ) che amministra i database degli spazi web dei propri utenti proprio tramite PhpMyAdmin configurato ovviamente con livelli di accesso limitati.

[3] righe della tabella

[4] colonne della tabella

[5] Da sottolineare l’ampia flessibilità dei tipi di variabili che offre MySql, ad esempio nel caso dei campi che conterranno testo: già dalla dichiarazione dei tipi abbiamo una connotazione del contenuto dei campi stessi.

Il campo id conterrà un numero intero, ed è sostanzialmente un indice per una rapida selezione dei record. La specifica (11) definisce la lunghezza massima delle cifre del numero, così da allocare lo spazio di memoria disponibile per ciascun record in modo preciso ed efficiente.

Il campo Type, come precedentemente illustrato, conterrà il tipo di documento archiviato. Esso conterrà quindi un testo, definito come tinytext poiché la sua descrizione è esigua. Inizialmente avevo progettato che questo campo fosse con 4 valori fissi, contenenti i principali tipi di documento che prevedevo di prendere in esame per la realizzazione della mia tesi di laurea. Nel menù di amministrazione della bibliografia avrei fornito quindi le 4 opzioni da poter scegliere:

· Libro (o Book),

· Rivista ( Periodic ),

· Contributo – Atti Congresso ( Tributes - Congress ),

· Altro ( Other )

Il campo type allora sarebbe stato dichiarato come varchar(1), e le 4 opzioni sarebbero state specificate a PhpMyAdmin in fase di dichiarazione della variabile del campo type: type avrebbe assunto come valore il primo carattere di ogni voce ( se type = libro => type = ‘L’, else se type = Rivista => type = ‘R’, ecc…).

Questa soluzione era però poco efficiente perché impediva una maggior precisione nello specificare alcuni tipi di documenti di varia tipologia, il cui “nome” non era semplificabile a Libro, o rivista, ma dove occorrevano ulteriori notazioni, e quindi sarebbe stato necessario creare altre voci per archiviare testi geroglifici, iscrizioni, tutto il materiale fotografico ( tra l’altro non generalizzabile sotto un’unica dicitura perché di varia natura, ad es. rilievi topografici fotografie aeree, fotografie satellitari, ecc…), andando quindi a compromettere:

· l’economia del campo, poiché si dovevano costruire tutte questi ulteriori “tipi” di testo,

· la precisione con cui archiviare, e quindi poi pubblicare la bibliografia stessa, caratteristica forse più importante.

Optare dunque per realizzare il campo type come tinytext, ha concretizzato la possibilità di descrivere esaurientemente la tipologia del documento da archiviare, rispettando però i criteri di efficienza necessari al corretto funzionamento del database.

[6] E cioè cercando tutti i documenti, ad esempio, scritti da un certo autore, pubblicati in un certo anno e magari con soggetto un particolare argomento.

[7] Vi è inoltre un campo chiamato Free.

Esso si è reso necessario durante lo sviluppo dei sistemi di I.R. interni al portale, più precisamente utilizzato per l’implementazione delle procedure di ricerca libera, ossia un’interrogazione non vincolata a determinati campi del testo, ma mirata al reperimento dei documenti tramite il loro contenuto.

La realizzazione della ricerca libera per parole chiave è descritta successivamente.