Tito Orlandi
L'AMBIENTE UNIX E LE APPLICAZIONI UMANISTICHE
1. Quadro generale.
Questo articolo nasce dalla convinzione, che ho acquisito in
alcuni anni di esperienze informatiche in differenti settori
umanistici, che attualmente l'ambiente operativo Unix <1>
rappresenta la vera soluzione della maggior parte dei problemi
che incontrano le applicazioni informatiche di carattere
umanistico. Poiché tale convinzione non è giustificata tanto
dalle possibilità "tecniche" dell'ambiente Unix (che pure sono
formidabili, e pure assai poco conosciute), quanto da
considerazioni di carattere organizzativo e generale, è
necessario chiarire bene questo punto, prima di passare
all'argomento specifico dell'articolo, che è quello di
illustrare alcune delle possibilità di Unix. Quanto verrà detto
non è strettamente connesso alle applicazioni archeologiche;
d'altra parte in via metodologica non vi sono differenze
specifiche, per quanto riguarda l'informatica, fra
l'archeologia e le altre discipline. Perciò questo articolo
viene dedicato al primo numero di una rivista come questa, con
l'augurio che essa possa essere, come merita, il punto di
riferimento di coloro che dibattono seriamente i problemi posti
dall'uso delle tecnologie informatiche nell'ambito
dell'archeologia.
Comincerò col notare che, a proposito della grandezza o, se si
preferisce, della potenza dei computer, da alcuni anni si è
stabilizzata una classificazione che, pur essendo per molti
versi arbitraria (come sono tutte le classificazioni) tuttavia
sembra reggere nel complesso ai cambiamenti repentini che
avvengono nel settore <2>. Si distinguono dunque: (a) i "main
frame", complessi di potenza enorme, misurata in MIPS (million
of inputs per second), attorno ai quali è organizzata
un'adeguata istituzione (di solito chiamata Centro di Calcolo)
che serve intere Università, grandi aziende, o grossi gruppi di
ricerca. (b) I "mini (-computer)", macchine di potenza media,
per i quali la misura si riferisce alla capacità di memoria RAM
(random access memory) o primaria, in megabyte. In ambito
universitario sono le tipiche macchine dipartimentali: potenti,
flessibili e affidabili, non richiedono continua sorveglianza
nè un grosso apparato di gestione. (c) I "micro (-computer)",
macchine di potenza medio-piccola, basate su una sola scheda
(microprocessore), destinate per lo più all'uso di un solo
utente, e variamente conformate in modo da essere da scrivania,
oppure portatili, oppure adatte all'editoria, etc. Esse sono
strettamente legate all'attività di una persona.
Se invece si prendono in considerazione le concezioni
riguardanti gli ambienti di utilizzazione delle tre classi di
computer, si ha l'impressione di assistere a continui
ripensamenti, dettati non tanto dalle caratteristiche
intrinseche delle macchine, e nemmeno tanto da quelle dei
software sempre rinnovati, quanto dalle possibilità di
organizzazione dei vari tipi di lavoro applicativo svolto per
mezzo dei computer.
Quando è iniziata l'espansione dei micro (diciamo dal 1980)
essi sono stati considerati utili solo per attività molto
collaterali (lavoro spicciolo d'ufficio; al massimo data entry
locale in vista di gestione da parte di una macchina grossa),
mentre tutti i "veri" lavori di gestione sarebbero stati
appannaggio esclusivo dei main frame. I progressi nella
costruzione dei micro, e il conseguente incremento della loro
potenza, ha poi generato grande confidenza nelle loro
capacità <3>. La naturale propensione degli umanisti a lavorare
singolarmente ha trovato in questo un notevole incoraggiamento.
Col tempo tuttavia ci si è accorti che l'organizzazione dei
Centri di Calcolo, che pure ha alcuni svantaggi di tipo
burocratico (in senso lato), ha vantaggi che vanno oltre
la pura potenza delle macchine. Infatti i Centri di Calcolo
possono offrire apparecchiature speciali e servizi che
si giustificano solo se usati in comune da più ricercatori,
ed inoltre hanno forme di salvataggio dei dati che scaricano
i singoli utenti da alcune preoccupazioni in questo senso.
In questa prospettiva, i mini sono stati considerati dagli
umanisti come macchine adatte soprattutto ai dipartimenti
scientifici, in quanto richiedono pur sempre competenze che il
singolo utente umanista ha raramente, e a prima vista sembrano
offrire strumenti che possono trovarsi anche sui main frame. In
realtà si comincia a scoprire che all'interno
dell'organizzazione dei Centri di Calcolo alcune specifiche
esigenze umanistiche trovano raramente soddisfazione, in
confronto alle pressioni dell'utenza tecnico-scientifica, e che
spesso si sprecano risorse per adattare del software immaginato
per impieghi non umanistici ad usi che non gli sono congeniali.
Basterà in questo contesto alludere p.es. al problema dei
simboli alfabetici "complessi".
Ma la "crisi" in ambiente umanistico è venuta soprattutto da
motivi interni, cioè dai rapporti fra gli stessi grossi centri
a carattere umanistico, che pure esistono (CETEDOC, Banche dati
bibliografiche, Oxford Computing Centre, Istituto di
Linguistica Computazionale di Pisa, Thesaurus Linguae Graecae,
etc.) e le singole ricerche. Infatti questi grossi centri sono
sorti intorno a imprese particolari, per quanto vaste (p. es.
le concordanze latino-medievali del CETEDOC) che spesso
prevedevano pubblicazioni in forma non elettronica, e dunque
non prevedevano collaborazioni dirette con altre ricerche
informatizzate; oppure hanno costituito grossi corpora
testuali, che tuttavia difficilmente comprendono i tanti testi
minori che spesso interessano i ricercatori <5>. Alcuni centri
hanno costituito banche dati biliografiche interrogabili in
linea o diffuse su CD-ROM, ma anche qui gli argomenti presi in
considerazione sono di solito i più convenzionali.
Si aggiunge che i grossi centri risultano abbastanza restii a
diffondere i propri dati su vasta scala e soprattutto in linea
(in parte per motivi di "gelosia" o di sfruttamento
commerciale, ma spesso per questioni legali assolutamente
obiettive); e soprattutto i loro dati sono spesso codificati in
modo che poco potrebbero servire per essere sottoposti a
procedimenti non previsti al momento della loro codifica.
Per queste, e per altre ragioni che qui non approfondiamo, oggi
si fa strada fortemente l'esigenza di ottenere l'accesso
pubblico a vaste masse di dati non mediante grosse organizzazioni
accentrate, ma mediante la collaborazione della miriade di
piccoli centri di ricerca specializzati, esattamente come è
accaduto fino ad oggi per mezzo della produzione libraria. Come
per mezzo della stampa ogni studioso o piccolo gruppo di
studiosi mette a disposizione dei colleghi le proprie
edizioni o repertori o monografie o articoli che, raccolti
nelle varie sedi di ricerca, forniscono i dati per ricerche
ulteriori; così nell'era della comunicazione elettronica si
dovrebbero mettere a disposizione i risultati del lavoro di
memorizzazione dei dati.
E' evidente che questo comporta molti problemi, e solleva
parecchie obiezioni. La più seria, per quanto posso vedere, è
che in quel modo i dati tendono ad essere intimamente connessi
ai giudizi su di essi da parte dello studioso che li ha
raccolti e vagliati; e inoltre la loro codifica risentirà delle
esigenze dettate dal software a sua disposizione. E' opportuno
notare che:
(a) la "soggettività" dei dati, quando non sia spinta a livelli
estremi, del resto comunque non compatibili con un lavoro serio
di ricerca, non è affatto incompatibile con i sistemi
automatici, anzi ne è un aspetto essenziale. Questo ha
insegnato per esempio Gardin <6> proprio in ambito archeologico.
Potrei dire (riferendomi alla sintesi da me proposta
dell'informatica umanistica <7>) che il momento della codifica
dei dati è un momento molto importante, proprio perché non può
mai prescindere da un apprezzamento soggettivo di essi, guidato
dai risultati della ricerca precedente.
(b) Ad ogni modo in ambito informatico occorrerà compiere uno
sforzo per rendere i dati utilizzabili in ricerche diverse da
quelle che li hanno prodotti, e questo può essere ottenuto in
due modi interdipendenti: la massima semplicità nella loro
codifica; il riconoscimento di un ambiente operativo comune ai
ricercatori, estremamente aperto anche a programmi individuali,
che fornisca uno standard utile allo scambio dei dati.
Vorrei proporre un solo esempio: l'organizzazione di una banca
dati non è necessariamente legata a questo o quel pacchetto
gestionale, ma piuttosto ad un lavoro teorico e metodologico
che individui un rapporto fra la formalizzazione della sua
struttura e la realtà che essa sarà chiamata a riprodurre e su
cui si faranno le analisi in modo automatico.
L'umanista che progetta una banca dati prende di solito come
punti di partenza (perché l'ambiente e le precedenti esperienze
cartacee lo invitano a fare questo) due fattori: 1. il
programma di gestione che userà; 2. la "scheda" dei dati che
dovrà immettere. Questo atteggiamento (non possiamo chiamarlo
metodo, perché è piuttosto un modo di operare basato su
elementi psicologici e vecchie abitudini piuttosto che sulla
riflessione metodologica) è oggi da considerare errato alla
radice, dopo la produzione degli studi (ancor prima che dei
programmi) riguardanti il sistema RELAZIONALE di gestione delle
banche dati.
Ricordiamo intanto brevemente che questo sistema si basa
piuttosto su una visione teorica <8>, e dunque non è legato in
linea di principio alle realizzazioni tecniche, che vengono "a
valle". Esso prevede la costituzione di una pluralità di
archivi (contrariamente al singolo archivio in cui vengono
inseriti i dati nel modello gerarchico), che vengono espressi
sotto forma di "tabelle", nelle quali ciascun campo di notizie
(all'interno di un record) può essere riempito con una sola
notizia riferita al soggetto del record. I problemi derivati
dalla necessità di riferire più notizie dello stesso tipo
riguardanti un certo soggetto vengono risolti con la
moltiplicazione dei record o con l'aggiunta di archivi. Il
soggetto dei record, che resta la base della concezione degli
archivi, viene identificato nei passaggi da un archivio
all'altro in quanto mantiene inalterato almeno uno degli
attributi ad esso assegnati. Si aggiunge che un soggetto di
record in uno degli archivi può essere un attributo di un altro
soggetto in un altro archivio.
Si noti che questo sistema consente di utilizzare le singole
tabelle o archivi come parte di un sistema complesso diverso da
quello per il quale sono stati concepiti, purché siano stati
concepiti correttamente in ambito relazionale. Siamo cioè in
linea perfettamente coerente con la necessità di scambio di
dati fra studiosi che li utilizzano per scopi diversi, ed in
contesti diversi.
Ma soprattutto il sistema relazionale può essere svincolato dai
programmi che vengono usati in concreto per gestirlo in modo
automatico. Per questo motivo si rivela errato l'atteggiamento
di chi pensa di dover basare l'architettura del suo sistema su
un programma concreto (punto 1 sopra). Dato poi che gli archivi
sono più di uno, si rivela altrettanto errato l'atteggiamento
di chi vuole immaginare prima di tutto la "scheda", cioè
l'ipotetica area in cui sono riunite tutte le notizie
riguardanti i soggetti (considerati tutti di un solo tipo,
dunque riuniti in un solo archivio) che interessano la sua
ricerca <9>.
Questo della scheda è un problema delicato che va approfondito
nei suoi aspetti nascosti, di solito non considerati dagli
operatori. Infatti la "scheda" in senso tradizionale non ha
senso nel sistema relazionale, se la si vuole prendere come
base per costruire un archivio. D'altra parte ha senso, una
volta progettato correttamente l'archivio, e deciso il programma
che lo gestirà, costruire la "maschera" di una scheda che
consenta di introdurre i dati in maniera rapida e facile, non
in relazione all'architettura dell'archivio, ma in relazione a
come i dati si presentano materialmente allo studioso. Dunque è
giusto porsi il problema della scheda, ma bisogna ben
comprenderne la portata, e soprattutto comprendere che essa
comporta un programma aggiuntivo (che del resto è previsto dai
linguaggi di programmazione dei DBMS relazionali) che faccia da
tramite fra la scheda stessa e la collocazione reale dei dati
nei diversi archivi del sistema.
2. L'ambiente Unix.
E' utile a questo punto ricapitolare i dati della questione,
come abbiamo voluto porla per introdurre poi il discorso Unix.
Nella gestione di data base si rivela essenziale l'architettura
"teorica" di un sistema, non i programmi di gestione
automatica; e possiamo aggiungere che, per quanto riguarda il
campo della gestione di testi (che qui non affrontiamo <10>)
si rivela essenziale la codifica dei testi, cioè un passaggio
preliminare a forte carattere teorico, e non i programmi di
gestione di tali testi, vuoi per l'analisi, vuoi per la stampa.
Il fatto è però che l'attenzione ai programmi fin qui data
dagli studiosi ha una sua causa molto reale. Se infatti i
programmi effettivi di gestione non hanno alcun potere di
migliorare la costruzione teorica dei sistemi (che è ciò che
davvero importa), essi hanno però il potere di impedire - in
determinati casi - molte delle libertà di azione necessarie
alla corretta costruzione teorica. Inoltre essi possono
impedire lo scambio di dati con studiosi che usano programmi
diversi. Da questo punto di vista si comprendono le prese di
posizione e le polemiche degli studiosi nei riguardi della
bontà o meno dei programmi e dei pacchetti applicativi; ma
ritengo che esse si basino su una situazione in via di
superamento e pertanto debbano almeno cambiare obiettivo.
D'altra parte si nota che gli strumenti che davvero consentono
libertà e coerenza nello standard dei dati sono quelli che
fanno parte di un ambiente operativo, e quindi bisognerebbe
concentrarsi assai più sulle caratteristiche dei sistemi
operativi (o meglio ancora ambienti di sviluppo) che non su
quelle dei pacchetti applicativi. Questa attenzione
all'ambiente operativo, prima e più che ai singoli programmi,
può fornire la soluzione soddisfacente ai problemi illustrati
sopra.
E' vero peraltro che oggi gli strumenti presenti nei sistemi
operativi sono per lo più assai rudimentali, rispetto alle
esigenze degli utenti. Occorre però chiedersi se e quali
sistemi operativi presentino invece strumenti che si possono
considerare ottimi, e soprattutto adatti alle ricerche
umanistiche. Mi sembra in effetti che Unix sia uno di questi, e
poiché non sembra molto conosciuto e sfruttato in questo campo,
penso sia utile proporne le caratteristiche generali e dare
alcuni esempi specifici relativi alla sua utilizzazione <11>.
Unix è un sistema operativo "portabile": esso può essere
installato su qualsiasi computer, indipendentemente dal
modello, e indipendentemente dalla potenza della macchina. Le
varie sue versioni sono installabili oggi sui personal come sui
supercalcolatori. Unix consente inoltre la piena portabilità
dei programmi che siano stati implementati al suo interno, cosa
che non si verifica facilmente per altri ambienti operativi.
Unix consente il lavoro a molti utenti per volta, ma
soprattutto consente a ciascun utente di effettuare
contemporaneamente più operazioni. Esso è inoltre
particolarmente versato nel campo delle comunicazioni
(messaggi, posta elettronica, scambio di file) sia a livello
locale, sia attraverso le reti di trasmissione dati, sia
semplicemente attraverso la rete telefonica.
Vi sono caratteristiche più specifiche che possiamo solo
accennare per motivi di economia in un articolo, ma che
meriterebbero un buon approfondimento perché si rivelano con
l'uso essenziali alle applicazioni umanistiche. Esse
riguardano: (1) il file-system. Esso permette di suddividere
dati e testi in un grande numero di file, che tuttavia al
momento della gestione possono riprendere senza altri passatti
l'unità iniziale. Questo è importante per questioni di
indicizzazione, come per la gestione di basi di dati
relazionali, come per molti altri lavori. (2) Gli strumenti di
sviluppo. Essi sono molte decine, ciascuno con compiti ben
specificati, e nello stesso tempo con la possibilità di variare
i parametri applicativi secondo esigenze diverse. Alcuni li
vedremo all'opera negli esempi più oltre, ma sono una minima
parte rispetto a quelli esistenti. (3) Redirezione e pipe.
Ognuno degli strumenti prevede che come input e output siano
indicati dei file a piacere, ovvero che si formi una catena in
cui l'output di uno strumento diventi l'input di quello
impiegato successivamente. I risultati che si possono ottenere
con queste procedure sono davvero incredibili.
Queste caratteristiche di Unix fanno sì che esso sia
particolarmente adatto a lavori nei quali le esigenze vengono
molto "parcellizzate", cioè vengono scisse in un certo numero
di componenti fondamentali; ma nello stesso tempo l'ambiente
vada mantenuto quanto più possibile unitario. Concretamente
possiamo dire che se, p.es., col sistema operativo MS-DOS è
possibile utilizzare package per la gestione di banche dati,
package per indicizzazioni e concordanze, package per la
gestione di testi, package per le comunicazioni; tuttavia
ciascuno di essi avrà caratteristiche particolari che impongono
input particolari e forniscono output particolari, e il
passaggio di file dall'uno all'altro sarà per lo meno
complicato, quando non impossibile. Con Unix invece tutto si
svolge in un medesimo ambiente, sotto il controllo costante
dell'utente, e con la possibilità di intervenire in moltissimi
modi sofisticati in ognuno dei passaggi del procedimento a cui
sono sottoposti i dati.
Aggiungiamo che su Unix esiste una vastissima bibliografia
che ne esamina approfonditamente tutti gli aspetti, in vista
di svariate applicazioni, cosa che non avviene per i sistemi
operativi per macchine della classe mini o main-frame, per
i quali si può solo ricorrere ai manuali delle case, che
risultano di solito troppo ampi per certi versi, troppo
sintetici per altri.
3. Esempi applicativi.
Vogliamo ora tentare di mostrare alcuni esempi concreti di
quelle funzioni che fanno di Unix un magnifico strumento
umanistico. Dato che ci rivolgiamo soprattutto ad un ambiente
archeologico, tratteremo specificamente di procedimenti
relativi alle banche dati. In questo caso quello che ci
proponiamo di mostrare è la duttilità e la potenza del
linguaggio disponibile, e nello stesso tempo la perfetta
trasparenza dei dati e dunque la loro portabilità in qualsiasi
condizione ipotizzabile.
Per essere concreti, abbiamo scelto un esempio che consiste in
una banca dati realmente esistente, progettata attraverso un
package specifico installato su un sistema operativo non Unix,
e cioè l'Rdb, per il sistema operativo VMS della Digital, in
particolare per la macchina VAX. Il motivo della scelta è
dovuto al fatto che sulla banca dati di cui parleremo è stato
pubblicato un interessantissimo resoconto, che non solo ne
mostra il fondamento metodologico e la struttura completa anche
nei particolari, ma anche spiega in maniera eccellente e adatta
ad un pubblico di studiosi umanistici i principi del sistema
detto "relazionale", che attualmente appare di gran lunga il
più adatto per le esigenze umanistiche <12>. Ci è sembrato
opportuno che l'esemplificazione venisse fatta proprio su un
problema pensato indipendentemente da Unix.
Non intendiamo affatto mettere in concorrenza i due sistemi,
ciascuno dei quali ha i suoi pregi, e può essere consigliabile
in diverse circostanze. Quello che interessa è solo di mostrare
con un esempio concreto gli strumenti di Unix all'opera.
La banca dati è costruita sul contenuto di un gruppo di
documenti riunito nei volumi manoscritti delle cosiddette Notti
Coritane, che riportano l'attività di un gruppo di eruditi di
Cortona, riuniti nell'Accademia Etrusca, che era volta
a descrivere e studiare vari tipi di oggetti (reperti
archeologici e naturalistici, dipinti, disegni, incisioni,
monete e medaglie, antichi manoscritti, etc.) ed inoltre ad
illustrare fatti di storia locale e riunire notizie artistiche
e scientifiche. Si tratta dunque di avere indici, elenchi e
raffronti di tutto il materiale di cui si parla nei manoscritti
delle Notti Coritane.
Secondo i principi del sistema relazionale, i file (o tabelle)
vengono costruiti a partire dai soggetti fondamentali, o
"entità" su cui si intende indagare. In questo caso si sono
scelti: PERSONAGGI - OGGETTI - LUOGHI - EVENTI, e per maggiore
flessibilità si sono anche distinti: ATTRIBUTI (dei personaggi)
- TIPOLOGIA (degli oggetti) - EVENTI (di cui si è trattato
nel corso delle riunioni) - AZIONI (nel senso di rapporti
generali fra persone e cose etc.: autore di, scopritore di,
etc.) - COLLOCAZIONE (delle notizie all'interno dei manoscritti).
Sempre secondo i principi del sistema relazionale, sono stati
costruiti altri file (o tabelle) che riguardano le relazioni
poste (oggettivamente o soggettivamente) fra le "entità" sopra
citate, in particolare fra Personaggi, Oggetti, Luoghi, Eventi,
dando origine a file il cui nome indica chiaramente lo scopo:
P-O (relazioni personaggi-oggetti); P-L (relazioni
personaggi-luoghi); e così via per tutte le possibilità.
Così nel file PERSONAGGI i record sono divisi nei campi: nome -
identificatore del personaggio. Nel file ATTRIBUTI: titolo1 -
titolo2 - titolo 3 (si possono avere dunque fino a tre titoli.
Qui i principi del sistema relazionale sono stati un po'
coartati, ma ciò è giustificato dalla poca importanza) -
qualifiche accademiche - professione - identificatore del
personaggio - identificatore della collocazione. Nel file
TIPOLOGIA: tipologia - codice del tipo. Nel file OGGETTI:
oggetto (sua descrizione) - quantità - materiale - tecnica -
data - codice del tipo - identificatore dell'oggetto. Nel file
LUOGHI: luogo - edificio - appartamento - identificatore del
luogo. Nel file EVENTI: evento (sua descrizione) - data -
identificatore dell'evento. Nel file AZIONI: azione (sua
descrizione) - codice dell'azione. Nel file SEGNATURA:
identificatore della collocazione - volume - pagina.
Come si vede, vi sono dei campi in ciascun file (quelli
chiamati in genere: identificatore di...) che si ripetono e
consentono di rimandare (in gergo, che riprendiamo volentieri
dalla pubblicazione, "navigare") da un soggetto all'altro su
cui si fanno le ricerche. Questo, e la stessa struttura dei
file, permette di immaginare gli algoritmi abbastanza semplici
che guidano la "navigazione", e di fare sia singole ricerche in
linea, sia di produrre indici anche complessi.
Cominciamo dalle interrogazioni in linea <14>. Immaginiamo che il
punto di partenza sia un oggetto che ha attirato la nostra
attenzione (p.es. una "Caricatura del musico Carnacci celebre
buffo di Roma"; v. p. 59-60) e vogliamo avere tutte le notizie
che lo riguardano. In questo caso lo strumento essenziale sarà
il "grep" (eventualmente con le varianti "egrep" e "fgrep", su
cui non ci soffermiamo). Questo comando permette di effettuare
su un file o su un gruppo di file in qualche modo omogeneo
(possono appartenere ad una directory; oppure possono avere
qualche cosa in comune nel nome) la ricerca di una sequenza
qualsivoglia di simboli alfanumerici e speciali, e mostra le
linee che li contengono, eventualmente precedute dal nome del
file in cui si trovano.
Dunque scrivendo il comando:
< grep "Caricatura del musico Carnacci" oggetto >
dove oggetto è il nome del file, si ottiene di visualizzare la
linea che immaginiamo sia la seguente:
: Caricatura del musico Carnacci celebre buffo di Roma@
1@carta@disegno@0009@0209 :
dove:
@ è il simbolo di separazione dei campi della scheda (una
scheda si identifica con una linea del file)
0009 è l'identificatore della tipologia
0209 è l'identificatore dell'oggetto.
Scrivendo il comando:
< grep "0009" tipologia >
verrà visualizzata la seguente linea:
: stampe@0009 :
e sapremo che si tratta di una stampa.
Scrivendo il comando:
< grep "0209" P-O >
dove P-O è il file che contiene le relazioni fra gli oggetti, i
personaggi, e le "azioni" (da intendere in modo molto lato) che
riguardano gli oggetti, verranno visualizzate le seguenti
linee:
: 0122@0209@0015@0073 :
: 0131@0209@0106@0073 :
: 0075@0209@0084@0073 :
: 0254@0209@0067@0073 :
Nel terzo campo si trova il numero che identifica l'azione,
mentre nel primo campo si trova il numero che identifica il
personaggio implicato dall'azione. Si tratta di usare sempre il
"grep" sui file opportuni, e cioè "personaggi" e "azioni" per
mettere in chiaro di che si tratta. Faremo un solo esempio di
richiesta:
< grep "0015" azione >
: incisa/e da@0015 :
< grep "0122" personaggi >
: Tuscher Marco@0122 :
Volendo conoscere anche gli eventuali attributi del personaggio
si potrà procedere di nuovo con grep sul file "attributi", che
ci dà l'occasione di proporre un passo in avanti nel
procedimento. Infatti il record (o linea) di questo file è
abbastanza lungo, e possiede 7 campi (cf. sopra). Il risultato
"bruto" di "grep" sarebbe dunque (qui invento totalmente il
contenuto dei campi):
: Marchese di Villaverde@Cavaliere@Gran Ciambellano@Incisore@
Accademico Etrusco@0122@3241 :
e a noi interessava solo il campo 5.
E' opportuno a questo punto introdurre lo strumento chiamato
"awk", che ha moltissimi usi, di tipo sia editoriale sia di
gestione di dati. In sostanza esso considera singolarmente le
linee di un file, e all'intern di tipo sia editoriale sia di
gestione di dati. In sostanza esso considera singolarmente le
linee di un file, e all'interno di esse distingue dei settori
(i nostri campi) considerando come separatore un simbolo che
viene specificato di volta in volta. Ogni settore viene
rappresentato dal simbolo $, seguito dal numero progressivo del
settore: $1, $2, $3, etc. Dando p.es. questo comando:
< awk -F@ {print $5} >
verrà visualizzato solo il quinto campo della linea in
questione. Nel nostro caso, si dovrà mettere in "pipe" tale
comando, dopo quello di "grep":
< grep "0122" attributi | awk -F@ {print $5} >
: Accademico Etrusco :
In realtà "awk" è un vero e proprio linguaggio di
programmazione, che si piega ad usi infiniti. Noi qui e in
seguito indicheremo soltanto alcuni dei più semplici. E'
possibile per esempio ottenere degli output più eleganti:
< grep "0122" attributi | awk -F@ {print "Il personaggio e' un " $5} >
: Il personaggio è un Accademico Etrusco :
Ci sembra insomma di aver chiarito fin qui come è possibile
navigare attraverso le varie tabelle relazionali rimanendo
sempre esclusivamente nell'ambito del sistema operativo.
Compiamo ora un passo ulteriore, utilizzando la possibilità che
Unix offre, di raccogliere un certo numero di comandi in un
testo, e poi farli eseguire dal sistema senza bisogno di
intervenire direttamente. Nel nostro caso sarà essenziale
introdurre uno strumento che gestisca le "variabili", perché
altrimenti non sarebbe possibile passare da un file all'altro,
mediante gli identificatori, senza intervento del ricercatore
interessato.
Lo strumento che usiamo è "read". Scrivendo questo comando:
< read VARIABILE1 VARIABILE2 VARIABILE3 >
si darà il nome a tre elementi di una riga (ciascuno deve
essere separato da uno spazio) che viene scritta lì per lì
ovvero viene fatta provenire dal risultato di un comando
precedente attraverso un "pipe". Per preparare opportunamente
tale riga, si farà uso di "awk" in modo analogo a quanto
abbiamo mostrato sopra.
Ecco dunque come appare un testo che riassume (se così possiamo
esprimerci) la navigazione mostrata in precedenza (gli a-capo
sono importanti; abbiamo numerato le righe solo per le
successive annotazioni - Unix non lo prevede):
1 grep "Caricatura del musico Carnacci" oggetto |
2 awk -F@ {print $5 " " $6} | read TIPOLOGIA OGGETTO
3 grep $TIPOLOGIA tipologia | awk -F@ {print "L'oggetto e' del tipo " $1}
4 grep $OGGETTO P-O | awk -F@ {print $3 " " $1} |
5 while read AZIONE PERSONAGGIO
6 do grep $AZIONE azione | awk -F@ {printf " %s:",$1}
7 grep $PERSONAGGIO personaggi | awk -F@ {print $1}
8 done
Commenti: alle righe 2, 3, 4, 6 si vede come viene usata la
possibilità di indicare ad "awk" dei testi da stampare, messi
fra virgolette, inclusi eventualmente degli spazi, per rendere
più elegante l'output. - Alla riga 6 viene usato il comando
"printf" invece di "print", per evitare che l'output seguente
vada a capo. - Alle righe 5-7 abbiamo introdotto un
ciclo di "while", che fa parte degli strumenti di Unix, per
rendere possibile l'elenco di tutte le alzioni connesse con
l'oggetto in questione. Questo fa parte di ciò che viene
chiamato il linguaggio "shell" di Unix, ma non intendiamo qui
approfondire questo settore, che pure è di grande interesse
anche per l'utente umanista.
Per rendere di uso generale questo che, come si vede, diventa
un vero e proprio programma, sostituiamo alla riga 1 questi
altri comandi abbastanza evidenti, dopo quanto abbiamo detto:
1 echo "Inserire l'oggetto da cercare: "
2 read RICERCA
3 grep $RICERCA oggetto ... (etc. ...)
Diamo poi il comando che trasforma qualsiasi file (che
naturalmente contenga quanto si deve) in uno strumento alla
pari di quelli usati finora. Se il nostro file si chiama,
p.es., "ricerca", si scriverà:
< chmod +x ricerca >
e in tal modo, da questo momento in poi, scrivendo:
< ricerca >
si avrà il seguente risultato:
: Inserire l'oggetto da cercare: :
< Caricatura del musico Carnacci >
: L'oggetto è del tipo: stampe :
: incisa/e da Tuscher Marco :
: disegnato/a da Ghezzi Pier Leone :
: raffigura Carnacci :
Aggiungiamo poi, per inoltrarci un po' di più nelle
caratteristiche di "awk", che per la verità alcune delle
operazioni doppie sopra utilizzate (grep... awk) possono essere
semplificate e anche rese più mirate dalla capacità di "awk" di
agire solo su quelle linee che in uno dei campi contenga una
sequenza voluta. Pertanto la riga 3 può essere sostituita da:
< awk -F@ /$TIPOLOGIA/ - $2 {print "L'oggetto e' del tipo " $1} tipologia >
Abbiamo dunque visto come sia agevole navigare in una banca
dati di tipo relazionale con gli strumenti di Unix. Spostiamo
ora l'attenzione dalle ricerche del tipo in linea, alle
possibilità di ottenere indici di vario di tutto il materiale
della banca dati. In parte, come si comprenderà bene, i
procedimenti potranno essere gli stessi. Quello che funziona
per un caso, può essere ripetuto (si ricordi il ciclo "while")
per tutti i casi del medesimo tipo.
Ma per ottenere indici generali vi sono strumenti più adatti,
che è opportuno presentare anche perché possono essere
utilizzati per molte altre esigenze, che il lettore individuerà
da solo partendo dalle proprie esigenze. Gli strumenti a cui
alludiamo sono soprattutto: "join" e "sort". Quest'ultimo
riordina secondo l'ordine alfanumerico le linee di un file, in
maniera molto flessibile. Infatti esso può distinguere un certo
numero di campi nella linea, mediante un simbolo di divisione
che viene indicato dall'utente, e ordinare le linee tenendo
conto solo dei campi voluti, e inoltre dando una certa priorità
all'interno di quei campi.
Se "sort" è uno strumento che (sia pure in modo meno
sofisticato) si trova generalmente nei sistemi operativi,
"join" è invece uno strumento che, per quanto ci consta, è
peculiare di Unix. Esso agisce su due file, e mette a confronto
in sequenza le loro linee. Le linee sono distinte in campi
(questa volta separati necessariamente dallo spazio). Nel tipo
di impiego più semplice, quando il primo campo delle due linee
corrisponde, esso presenta in output tale campo (una volta
sola), e di seguito gli altri campi sia del primo che del
secondo file.
Ritorniamo all'esempio fatto prima, e supponiamo di voler
elencare le Notti Coritane di cui è data notizia negli omonimi
volumi, in ordine di data, aggiungendo il luogo in cui furono
tenute, e l'indicazione di volume e pagina della notizia. I
file che entrano in gioco saranno: eventi, luoghi, L-E
(relazione fra luoghi ed eventi). Ricordiamo come sono
organizzate le loro linee (cioè le schede e i relativi campi:
eventi: evento @ data @ Ide (identificatore dell'evento)
luoghi: luogo @ edificio @ appartamento @ Idl (identificatore
del luogo)
L-E: Ide @ Idl @ Code-r (tipologia degli eventi) @ Scheda (vol.
e pag.)
Si tratterà prima di tutto di porre all'inizio delle linee i
campi "di riferimento". Mediante "awk" è agevole ricomporre le
linee dei file, in modo che il primo campo in eventi sia Ide,
il primo campo in luoghi sia Idl. Quindi sceglieremo in eventi
le linee che contengono le Notti Coritane, e le metteremo in
ordine secondo Ide, ottenendo un file che chiameremo
eventi.new:
< grep "Notte Coritana" eventi | sort -t@ -1 = eventi.new >
Quindi ordiniamo L-E secondo il campo Ide, ottenendo un file
che chiamiamo L-E.new:
< sort -t@ -1 L-E > L-E.new >
Se ora diamo il comando:
< join eventi.new L-E.new > temp01 >
otteniamo un file temp01 in cui le linee sono così composte
temp01: Ide @ Evento @ Data @ Idl @ Code-r @ Scheda
Mediante un ulteriore passaggio in "awk" elimineremo i campi
Ide e Code-r che non servono, e porremo Idl al primo posto. A
questo punto agiremo sul file luoghi:
< sort -t@ -1 luoghi > luoghi.new >
e di nuovo agiremo attraverso "join":
< join temp01 luoghi.new > temp02 >
Le linee del file temp02 saranno così composte:
temp02: Idl @ Evento @ Data @ Scheda @ Luogo @ Edificio @
Appartamento
Come si vede, abbiamo ottenuto riunite in ciascuna linea tutte
e solo le notizie di volevamo dare nell'elenco. Agendo con
"sort" e "awk" metteremo le linee in ordine di data, ed
elimineremo il campo Idl che non serve. Di nuovo "awk" potrà
servire, come abbiamo visto sopra, a stampare l'indice in una
forma elegante.
4. Conclusione.
Io spero che risulti da quanto abbiamo esposto, che un
umanista che prenda un minimo di tempo e compia un minimo
sforzo mentale per informarsi sugli strumenti che Unix
mette a disposizione, può gestire i propri dati in
maniera semplice e diretta con due vantaggi fondamentali:
(1) affrancarsi in modo sostanziale dai rapporti di dipendenza
dagli specialisti di informatica e dagli analisti, che per
quanto amichevoli spesso tarpano la "fantasia" (scientifica,
beninteso) dello studioso nello sperimentare sempre nuovi
modi di analizzare i dati di cui dispone. (2) Mantenere
i propri dati codificati e memorizzati in maniera tale
da essere facilmente scambiati con quelli di colleghi
con cui intrattenga rapporti, soprattutto (ma non esclusivamente)
se anch'essi possono disporre dell'ambiente Unix sulle
macchine a cui hanno accesso.
A mio modo di vedere, solo questa è la via mediante la quale
si può realizzare l'accumulo spontaneo di conoscenze e
dati su supporto magnetico (o comunque gestibile con
sistemi elettronici), attraverso la collaborazione di
singoli studiosi, perfettamente indipedenti, piuttosto che
demandare questo compito a grossi centri nazionali o
internazionali, che per quanto bene orientati e organizzati
avranno per loro natura una tendenza in qualche modo
egemonizzante.
NOTE:
<1> Unix è un marchio registrato dei Bell Laboratories della
AT&T. Indichiamo i manuali fondamentali, da cui si potrà
trarre ulteriore bibliografia: B. W. KERNIGHAN, R. PIKE,
Unix, Bologna 1985; S. R. BOURNE, The Unix System, Reading
etc., 1983; H. McGILTON, R. MORGAN, Introducing the Unix
System, New York etc., 1983.
<2> Cf. p.es. G. CIOFFI, V. FALZONE (edd.), Manuale di
Informatica, Bologna 1987, p. 713-714.
<3> Cf. p.es. i due fascicoli della rivista-bollettino
del CNRS francese: Le Médiéviste et l'ordinateur,
n. 9, printemps 1983; n. 14, automne 1985. Per l'aspetto
storico cf. S. AUGARTEN, Bit by Bit. An Illustrated
History of Computers, 2.ed., London 1985, cap. 9, p.
253-281.
<4> *** I. LANCASCHIRE, W. McCARTHY, The Humanities Computing
Yearbook, Oxford 1988 ***
<5> Va detto che fra le realizzazioni migliori in questo campo
si possono menzionare il Text Archive dell'Oxford Computing
Centre, per le caratteristiche della codifica e la trasparenza
nella distribuzione; e in parte minore il Thesaurus Linguae
Graecae di Irvin (Illinois), per la completezza dei testi.
<6> J.-C. GARDIN, Archaeological Constructs, Oxford 1983
(cf. soprattutto cap. 3, p. 31-61).
<7> Cf. T. ORLANDI, Informatica umanistica, Roma 1990, cap. 2,
p. 29-41.
<8> P. ATZENI, C. BATINI, V. DE ANTONELLIS, La teoria relazionale
dei dati, Torino 1983 (con bibliografia).
<9> Una raccolta di esempi di "schede" in P. MOSCATI, Archeologia
e calcolatori, Firenze 1987, p. 15-53.
<10> Per una trattazione sintetica, con bibliografia, rimando
a T. ORLANDI (cit. alla nota 7), p. 117-131.
<11> Una buona sintesi a livello non specialistico in
L. CEROFOLINI, Ambienti di sviluppo e sistemi di documentazione,
in: G. ADAMO (ed.), Trattamento, edizione e stampa di testi
con il calcolatore, Roma 1989, p. 3-28.
<12> F. FIDECARO, A. TOSI, Le Notti Coritane. Applicazione
del modello relazionale, Bollettino d'Informazioni (Centro
di Elaborazione Automatica di Dati e Documenti Storico
Artistici, Pisa) 10 (1989) fasc. 2, 195 pp.
<13> Ibid., p. 11.
<14> Gli esempi di comandi in linea e di risultati sono molto
realistici, ma abbiamo dovuto omettere qualche particolare
che avrebbe nuociuto alla chiarezza. Si tratta soprattutto di
qualche apice che talvolta occorre aggiungere. Ma chi
abbia una conoscenza elementare di Unix può facilmente
utilizzare gli esempi seguenti in modo concreto.