PRINCIPI DI DATABASE MANAGEMENT IN ARCHEOLOGIA

razioni che aprono questo paragrafo, sarebbe auspicabile che
le pubblicazioni prevedessero descrizioni dettagliate dell’architettura secondo la quale il dato è stato organizzato.
PRINCIPI DI DATABASE MANAGEMENT
IN ARCHEOLOGIA: L’ESPERIENZA SENESE
di
VITTORIO FRONZA
INTRODUZIONE
Da qualche anno si nota la sporadica presenza di contributi riferibili al settore dell’informatica applicata anche al di
fuori delle sedi specialistiche nelle quali è solitamente relegata. Nonostante ciò, manca una chiara presa di coscienza da
parte della comunità archeologica circa il ruolo chiave svolto da questi strumenti. Le nostre pubblicazioni contengono
normalmente riferimenti (più o meno dettagliati) alle metodologie usate per l’indagine e la documentazione; fra questi
dovrebbe essere sempre compresa una descrizione delle eventuali applicazioni di tecnologia digitale.
In altre parole, l’informatica applicata è ormai matura
per diventare patrimonio metodologico comune in ambito archeologico, e meriterebbe quindi uno spazio più appropriato
nei contributi relativi a progetti che ad essa fanno ricorso.
Affinché ciò avvenga è indispensabile che l’archeologo prevalga sull’informatico (si tratta di uno dei principi sui quali
si è fondata la scuola senese di informatica applicata all’archeologia; a questo proposito FRONZA, NARDINI, VALENTI 2002
c.s. e bibliografia ivi citata). Una simile affermazione può
essere intesa in due diversi modi, entrambi riferibili alla nostra esperienza. In primo luogo, crediamo che l’archeologo
debba essere coinvolto direttamente nella gestione dell’intero processo di trattamento digitale del dato, attraverso le fasi
di acquisizione, analisi e divulgazione. Il secondo significato
va ricercato nell’approccio alla ricerca: vi è il rischio concreto di essere assorbiti da una scienza, quella informatica, con
problematiche e metodologie proprie; esiste già, di fatto, una
figura di ricercatore in ambito archeologico che privilegia
approcci e metodi prettamente informatici, matematici, statistici. L’archeologo, invece, mette in primo piano le sue particolari problematiche storiche, le sue metodologie e le risposte che vuole ottenere da un insieme di dati: l’ottimizzazione
delle risorse informatiche cede il passo a soluzioni che aderiscono più strettamente alle indagini in corso. Dobbiamo quindi
avere un approccio pragmatico nei confronti della tecnologia: si tratta di trovare una via archeologica all’informatica,
piuttosto che una via informatica all’archeologia.
Affrontare qualsiasi argomento di informatica applicata
comporta rischi direttamente legati all’alfabetizzazione dell’archeologo che scrive, al suo approccio nei confronti delle
tecnologie digitali, al tipo di applicazione descritta. Spesso
si assiste all’esposizione di concetti ovvi e banali, o di sterili
elenchi delle caratteristiche proprie di una specifica applicazione o categoria di software; in altri casi, ancora peggiori,
può accadere di imbattersi in inutili compendi di tecnologie
digitali, che non di rado sconfinano in eccessivi tecnicismi.
Ancora, è altrettanto diffuso l’uso errato o improprio di termini e concetti propriamente informatici da parte di archeologi che si improvvisano esperti del settore.
In ogni caso, non pensiamo che la redazione di trattati
di informatica rientri fra i compiti di un archeologo o fra gli
argomenti da trattare in una pubblicazione specialistica (sarebbe come scrivere trattati di zoologia ogni volta che si
nomina una specie in un articolo sui reperti faunistici). Nozioni informatiche di base dovrebbero far parte del nostro
bagaglio, oppure essere acquisite quando se ne ha la necessità. Nonostante ciò, la trattazione di aspetti tecnici di base
può rivelarsi pertinente purché direttamente legata alla pratica della ricerca archeologica.
Un ragionamento diverso vale, invece, per l’illustrazione dei modelli del dato: in questo caso si tratta di argomentazioni essenzialmente archeologiche; riprendendo le conside-
Questo contributo intende chiarire gli aspetti da tenere
in considerazione nell’applicazione delle tecniche di database management all’archeologia; deriva direttamente dall’esperienza maturata presso il LIAAM (Laboratorio di Informatica Applicata all’Archeologia Medievale – Università degli studi di Siena) da oltre un decennio. Si tenterà di
delineare alcuni principi che dovrebbero essere alla base
della riflessione sull’avvio di un progetto di archiviazione.
Alcuni, di carattere generale e quindi potenzialmente riferibili a tutte le implementazioni informatiche in archeologia, sono già stati affrontati in altre pubblicazioni del
LIAAM (si vedano soprattutto FRANCOVICH, VALENTI 2000;
VALENTI 2000). Altre considerazioni sono più specifiche e
riguardano le tecniche di database management e le loro
implicazioni nello sviluppo di DBMS in ambito archeologico. Lo scopo, in definitiva, è quello di tracciare alcuni
lineamenti metodologici, eterogenei e trasversali, utili per
l’archeologo che si appresta alla gestione in digitale del
proprio dato alfanumerico.
GLI INDIRIZZI DI FONDO
Il chiarimento degli indirizzi di fondo assunti nell’elaborazione di una soluzione informatica sono elemento indispensabile per una comprensione adeguata del lavoro svolto; di seguito riportiamo, fra i principi generali riferibili all’approccio della scuola senese, quelli più direttamente legati al database management.
Gli obiettivi del database management in archeologia
Occorre innanzitutto chiarire quali sono gli obiettivi (e,
al contempo, i vantaggi) del database management in archeologia. Si possono richiamare almeno due validi motivi
per l’utilizzo massiccio di basi di dati digitali:
– Facilità nella gestione. I vantaggi gestionali immediati
introdotti dall’uso di database automatizzati risultano piuttosto ovvi; in questo senso l’efficacia cresce esponenzialmente con l’aumento quantitativo delle informazioni. Oggi
è possibile gestire agevolmente e in tempo reale insiemi di
dati di ragguardevole dimensione. Le funzionalità maggiormente coinvolte nella facilità di gestione riguardano l’aggiornamento, la consultazione e l’analisi del dato. Un buon
database in ambito archeologico dovrebbe permettere all’utente elaborazioni complesse, non limitate alla semplice
interrogazione: occorre implementare funzioni che permettano di semplificare alcuni passaggi tradizionalmente considerati dispendiosi in termini di tempo e energie.
– Interscambio del dato. Anche se di intuizione meno immediata rispetto al precedente, la possibilità di interscambio del dato è da considerarsi uno dei vantaggi primari derivati dall’uso dei database in archeologia. A nostro avviso,
questa seconda caratteristica è forse anche più importante
della prima in quanto offre potenzialità maggiori sul terreno della costruzione di modelli storici. Alcune tecniche di
database management consentono infatti di uniformare il
dato, creando i presupposti per una reale condivisione delle
informazioni e quindi del sapere.
La necessità di un’architettura del dato aperta
L’esigenza di avere il massimo numero di informazioni
possibile in linea, per una consultazione e analisi che tengano conto di tutti i dati prodotti dalla ricerca, può essere
considerato uno dei requisiti dell’informatica applicata all’archeologia; in sostanza si tratta di pensare una soluzione
onnicomprensiva nella quale potersi muovere liberamente
629
e reperire con facilità qualsiasi combinazione di dati, a partire dal livello più basso e oggettivo per arrivare a registrazioni di tipo astratto o interpretativo.
Si rende in questo senso indispensabile la creazione di
un’architettura aperta e facilmente integrabile con nuove
tipologie di informazioni, derivanti dalle mutevoli dinamiche della ricerca sui singoli contesti. Ciò vale sia per le diverse classi di dati alfanumeriche, sia per la loro relazione
con altri tipi di dati (ad esempio, per l’integrazione fra GIS
e database si veda NARDINI 2001). In effetti i vasti e spesso
interdisciplinari ambiti coperti dalla ricerca archeologica,
il costante miglioramento delle metodologie e le particolarità di ogni singolo contesto, rendono impossibile la previsione di tutte le variabili e classi di dati potenzialmente coinvolte in un progetto. Un’architettura del dato che presenti
caratteristiche di flessibilità rappresenta quindi un requisito imprescindibile nello sviluppo di strumenti e soluzioni
digitali per l’archeologia.
Creare gli standard: un processo di approssimazione
A nostro avviso è fondamentale progettare soluzioni che
non esauriscano il loro potenziale all’interno della ristretta
cerchia degli “addetti ai lavori” ma possano essere di utilità
a tutta la comunità scientifica, indipendentemente dagli
obiettivi di uno specifico progetto o dal grado di alfabetizzazione digitale dei suoi attori. Il rischio concreto è, infatti,
quello di relegare la nascente disciplina dell’informatica
applicata all’archeologia ad un ruolo specialistico di nicchia, sottolineandone l’ausiliarietà senza sfruttarne il potenziale che la pone come una novità metodologica trasversale di larghissimo impatto.
Si rende quindi necessario uno sforzo, il più possibile
collettivo, per avviare un processo di creazione degli standard che garantiscano l’interscambiabilità del dato. Una collaborazione fattiva fra studiosi, che prescinda dai particolarismi metodologici soggettivi, costituisce la premessa indispensabile per conseguire l’obiettivo. Occorre ragionare il più
possibile in termini di gestione globale del dato, slegandosi
da metodi di archiviazione sviluppati per singoli siti o progetti. Si tratta di un processo da innescare almeno a livello
della singola unità di ricerca; ancora più auspicabile sarebbe
l’avvio di collaborazioni fra unità di ricerca che operano su
siti cronologicamente e spazialmente diversificati.
Per esperienza possiamo affermare che un simile percorso non si esaurisce in un unico momento progettuale. Si
rende anzi necessario (e fondamentale) “aggiustare” continuamente la struttura degli archivi con il procedere della
ricerca, l’immissione sul mercato di nuovi prodotti e tecnologie, la maggiore consapevolezza nell’uso del mezzo informatico. Ogni volta che all’interno di un progetto si esprime la necessità di gestire una nuova classe di dati, ampliare
lo spettro delle informazioni relative ad una classe di dati
esistente o effettuare nuovi tipi di elaborazione, queste funzioni devono essere integrate nell’architettura (aperta) e
quindi rese disponibili a tutti gli utenti della soluzione. Questo modo di procedere, per approssimazione successiva, rappresenta il nostro approccio alla creazione di standard nell’ambito del database management in archeologia.
ASPETTI DI DATABASE MANAGEMENT
Nella costruzione di basi di dati archeologiche complesse non è possibile prescindere da alcuni aspetti direttamente derivati dalla teoria del database management; tutti gli
argomenti trattati di seguito influiscono pesantemente sulla
reale fruibilità del dato.
Il modello relazionale
Grande attenzione va prestata alla scelta del modello
sui cui basare l’architettura del dato. I database relazionali
e il metodo di progettazione detto “entità-relazione” si sono
rivelati in questi anni una soluzione buona (se non ottimale) per la gestione del dato archeologico; permettono infatti
la strutturazione di schemi complessi che rispecchiano la
realtà della ricerca, mantenendosi ad un livello sufficientemente astratto (si veda FRONZA 2001 e le considerazioni relative al DBMS Carta Archeologica). Da evitare, invece,
un uso esclusivo del modello relazionale basato su albero
gerarchico, tranne i casi in cui la natura stessa dei dati lo
suggerisce (come avviene per la stratigrafia; FRONZA 2000).
Simili implementazioni si configurano infatti come soluzioni rigide e mostrano limiti nella gestione di contesti applicativi complessi; basti pensare alla relazione non gerarchica che intercorre fra le entità Sito e Bibliografia: un sito
può essere pubblicato in vari titoli di bibliografia e ciascun
titolo di bibliografia può trattare più siti. Nel caso di una
struttura gerarchica del dato una simile eventualità non è
prevista: un’us può avere molte schede di reperti ceramici,
ma ciascun reperto appartiene sempre ad una sola us.
La nostra scelta di continuare nello sviluppo di basi di
dati relazionali nasce dall’efficacia ormai assodata nella
soluzione dei problemi di gestione archeologica. Siamo
comunque perfettamente convinti dell’utilità legata a qualsiasi tipo di sperimentazione relativamente a tecniche innovative o non elevatesi a standard, soprattutto se finalizzate
a verificarne l’efficienza in campo archeologico.
Grado di dettaglio: la definizione di un compromesso
Stabilire un grado di dettaglio, non necessariamente
uniforme per tutte le categorie dei dati, significa ragionare
sull’efficienza di un archivio; l’argomento, direttamente
legato alla progettazione dell’architettura del dato, va affrontato almeno a due livelli: i campi e le entità.
Secondo le formulazioni informatiche, i dati rappresentati in un campo dovrebbero presentare il massimo grado di
frammentazione; da un punto di vista maggiormente aderente alla realtà archeologica, questa affermazione va tarata
in base alle esigenze di un database. Se prendiamo in considerazione la cronologia di un sito, a seconda del grado di
dettaglio, possiamo prevedere un campo unico Datazione
oppure più campi distinguendo, ad esempio, fra Periodo,
Fase, Cronologia iniziale, Cronologia finale, Affidabilità
datazione, ecc. Nel primo caso abbiamo possibilità molto
minori di controllo su linguaggio e consistenza (trattati più
avanti), interrogazione, analisi; nel secondo caso tutte queste operazioni risultano più agevoli e potenti, a scapito di
una maggiore complessità (che si traduce in maggiori difficoltà di gestione e carico di lavoro per gli utenti e il calcolatore). I ragionamenti esposti per i campi valgono anche,
ad un livello più alto, per le entità coinvolte in un progetto
di schedatura.
In definitiva, la soluzione ideale coniuga le esigenze
specifiche degli approfondimenti su particolari aspetti del
progetto di ricerca con i criteri di agilità indispensabili per
una proficua fruizione dei dati.
Allineamento del dato: un problema congenito al database
management archeologico
Le situazioni nelle quali molto spesso vengono condotte le ricerche archeologiche comportano, per loro natura,
forti problemi di disallineamento del dato. La questione
dell’aggiornamento dei dati si pone ogni qual volta più persone in luoghi diversi (cantieri di scavo, laboratori di schedatura, laboratori informatici, ecc.) lavorano localmente su
copie degli stessi archivi; avere molte trasposizioni dei medesimi dati, magari ad uno stadio di avanzamento della schedatura differente, può seriamente comprometterne la fruibilità. Nel caso migliore può risultare difficile stabilire quali
siano i file più aggiornati (ad esempio, le schede us di un
settore di scavo possono essere più recenti in una copia del
database e quelle di un altro settore in un’altra). La situazione si complica se più persone lavorano sugli stessi re-
630
cord (ad esempio due persone modificano le stesse schede
us su due copie diverse di un database). Problemi di questo
tipo non possono essere del tutto risolti; una corretta impostazione può però ridurli ad un ruolo marginale. Nell’esperienza senese siamo giunti, nel corso degli anni, ad una soluzione di compromesso che ha dato buoni risultati. L’accesso ai dati “ufficiali” (quasi sempre i più aggiornati) avviene in rete locale, attraverso un DBMS che consente di
gestire l’intero panorama informativo prodotto dalle indagini archeologiche (siti, indagini territoriali, stratigrafia,
reperti, dati archeometrici, edilizia, ecc.); tutti i ricercatori
possono accedere al database, ovunque si trovino, purché
vi sia un collegamento di rete (anche via modem); sono
perciò incoraggiati ad aggiornare i dati sul server centrale.
Quando ciò non è possibile sono previste versioni locali del
database, dotate di routine che prevedono un aggiornamento automatico dell’archivio centrale.
Questo tipo di organizzazione prevede anche una ripartizione dei ruoli delle persone coinvolte; occorre almeno
distinguere fra responsabili della progettazione/amministrazione della base di dati, responsabili raccolta dati,
rilevatori, utenti a più livelli.
Consistenza del dato
Nel caso di basi di dati complesse, quali effettivamente
sono quelle archeologiche, occorre prestare particolare attenzione alla definizione dei controlli sulla consistenza attraverso vincoli di integrità del dato; si tratta di un momento di
attenta riflessione e sintesi dei processi che producono le informazioni da far confluire negli archivi. Commettere errori
di valutazione nella progettazione di questi strumenti, soprattutto in relazione ad eccessi o difetti di severità, significa
andare incontro a tempi piuttosto onerosi nella ristrutturazione dell’archivio e nella correzione del dato o a seri ostacoli
nella fruizione (in casi estremi può essere pregiudicata la stessa utilizzabilità dei dati); occorre elaborare una soluzione che
permetta di effettuare un data entry corretto senza tuttavia
rendere i controlli soffocanti al punto da rallentare anziché
facilitare l’immissione e la revisione dei dati.
I controlli sulla consistenza sono parte integrante della
struttura di un database. Le verifiche più semplici riguardano l’obbligo di inserimento e il tipo di dato (numerico, testuale, data, ecc.) cui ci si deve attenere; il campo Numero
US di un database relativo alla stratigrafia avrà, ad esempio, entrambi i vincoli: un valore deve sempre essere inserito e deve essere esclusivamente numerico e intero. Controlli più complessi possono riguardare un intervallo di valori consentiti o vincoli basati su calcoli.
Normalizzazione del linguaggio: la questione dei thesauri
in archeologia
Normalizzare il linguaggio di un database, soprattutto
per quanto riguarda i campi di sintesi, costituisce un requisito fondamentale per la fruibilità dei dati. Come avviene
per i controlli sulla consistenza, un linguaggio non uniforme comporta inefficienze che possono anche determinare
la completa inutilizzabilità dei dati raccolti. Considerando
un esempio molto semplice, supponiamo di avere un archivio di siti per il quale non sia previsto un linguaggio coerente sul campo Definizione; nell’inserire il valore “Insediamento urbano”, rilevatori diversi possono utilizzare termini diversi (ad es. “Città”, ”Centro urbano”, “Insediamento cittadino”, ecc.). Volendo richiamare tutti gli insediamenti
urbani di un certo periodo il nostro compito risulterebbe
piuttosto complicato; immaginiamo di voler effettuare analisi statistiche che coinvolgono lo stesso dato: l’operazione
sarebbe impossibile. Se proiettiamo questo esempio banale
su casi più complessi, i risultati dell’uso di un linguaggio
non normalizzato possono rivelarsi catastrofici.
Le scienze informatiche non si occupano direttamente
di questo tipo di problematiche, le cui regole sono stabilite
dalla linguistica e dalle discipline classificatorie. Lo strumento principe per la normalizzazione del linguaggio è il
thesaurus, un vocabolario controllato che rende esplicite le
relazioni fra i termini in esso contenuti. Dalla chiarezza formale e dalla completezza di questi strumenti dipende in gran
parte la leggibilità e l’interpretabilità di una base di dati. In
sostanza si tratta, insieme alla progettazione dell’architettura relazionale, dello sforzo maggiore implicato nella costruzione di un database efficiente.
In archeologia può risultare utile dividere i vocabolari
in tre grosse categorie, a seconda del livello di standardizzazione del linguaggio raggiunto: chiusi (valori fissi, non
modificabili dall’utente; l’elaborazione del linguaggio è
completa), semichiusi (l’utente può suggerire valori mancanti), aperti (si aggiornano automaticamente in base ai
valori liberamente immessi dall’utente).
Identificatori relazionali
In ambito archeologico, la definizione degli identificatori relazionali (o chiavi primarie) assume importanza maggiore rispetto alle più diffuse applicazioni di database management. I frequenti interventi sui dati catastati e soprattutto la necessità di aggiornamenti continui (in particolare
durante la fase di data entry) suggeriscono di evitare l’uso
di numeri progressivi che si possono facilmente ripetere sia
fra classi di dati diverse, sia all’interno dello stesso contesto applicativo. Si rivela sicuramente più funzionale un sistema di chiavi complesse, basato su campi calcolati che
definiscono univocamente le classi di dati (attraverso sigle)
e i dati stessi (attraverso valori). Nel caso di un database dei
reperti ceramici, ad esempio, l’univocità è garantita dall’unione di scavo e numero di inventario del reperto. Un
esempio potrebbe essere “PROPI%CER6784”, dove “PRO”
e “CER” rappresentano le sigle delle classi di dati (Progetto e Reperti ceramici), “PI” e “6784” i valori del dato (inventario 6784 del progetto Poggio Imperiale); il carattere
“%” è usato come separatore fra classi di dati. Una simile
impostazione assicura inoltre una più facile memorizzazione degli identificatori da parte dell’archeologo.
Gli identificatori relazionali necessitano chiaramente di
un assoluto controllo sulla consistenza del dato, in particolare riguardo ai vincoli di obbligo d’inserimento e unicità
del dato; nel caso archeologico, vista la praticità delle chiavi calcolate sulla base di più dati, l’ideale sarebbe prevedere un inserimento guidato dei valori che formano l’identificatore.
Interfaccia utente: uno strumento per tutti
Si tratta di un aspetto direttamente legato al concetto di
utilizzo universale dei prodotti dell’informatica applicata
più volte citato in questo lavoro; la creazione di un’interfaccia di semplice utilizzo e che consenta di effettuare le
operazioni di base costituisce, a nostro avviso, un parametro importante per la valutazione della qualità di un database. Si tratta della fase più dispendiosa in termini di tempo
nella costruzione di un database; anche per questo motivo
viene spesso trascurata.
I criteri cui ci si dovrebbe attenere riguardano la personalizzazione delle funzioni principali, facilitando l’uso del software attraverso ambienti grafici e visuali intuitivi, controlli tarati
specificatamente sui singoli contenitori e percorsi guidati ed
obbligati nell’espletamento di alcune operazioni.
CONCLUSIONI
Gli argomenti trattati evidenziano come l’elaborazione
di un modello dei dati rappresenti, nell’analisi di una soluzione informatica, il momento di più stretto coinvolgimento del processo di cognizione proprio dell’archeologo. Dalle pagine che precedono risulta chiaro come la struttura del
dato è concettualmente (e in parte anche logicamente e fisi-
631
camente) indipendente dalle piattaforme hardware/software e dalle tecnologie impiegate per la costruzione di un
DBMS. Riteniamo migliore un database forse meno coerente da un punto di vista informatico, ma duttile ed aderente alle esigenze della nostra disciplina. Siamo inoltre
convinti che un database, per poter essere definito efficiente, deve essere testato su una mole rilevante di dati, sia in
senso qualitativo (casistica il più possibile varia), sia in senso
quantitativo (la gestione di grandi quantità di dati rappresenta un fattore importante per attestare la “bontà” di una
soluzione). Nell’esperienza senese, la progettazione si attua attraverso riunioni periodiche, a livelli diversificati, fra
le persone coinvolte nella gestione digitale (responsabili di
progetti, responsabili database management, rilevatori, ecc.);
la fase di codifica vera e propria è svolta da archeologi che
hanno acquisito conoscenze di alto livello nell’ambito del
database management.
Alcune considerazioni finali riguardano la standardizzazione e l’interscambio del dato, aspetti già citati in quanto principali obiettivi/vantaggi dell’archiviazione digitale.
Lo scopo è quello elevare la massa dei dati raccolti ad «un
accumulo di sapere collettivo destinato a far crescere il livello ed i contenuti della ricerca» (FRANCOVICH 2001); ciò
significherebbe creare strumenti efficaci per il confronto e
la vicendevole integrazione fra modelli diversi e spesso indissolubilmente legati a particolari tematiche della ricerca,
periodi storici o aree geografiche.
Non è questa la sede per analizzare i molti tentativi di
creare strumenti uniformi per la documentazione archeologica, susseguitisi ripetutamente negli ultimi decenni e strettamente legati a vari orientamenti teorici della ricerca; in
questo senso la proposta più attuale e onnicomprensiva è il
CRM (Conceptual Reference Model) del CIDOC. Simili
lavori costituiscono una base di partenza imprescindibile
per la definizione dei requisiti di minima nella catastazione
del dato archeologico; siamo comunque convinti che l’effettiva operatività di database standard possa concretizzarsi solamente attraverso la sperimentazione pratica su uno
stesso archivio da parte di un ampio numero di ricercatori.
La tecnologia attuale renderebbe facilmente attuabile un
progetto che si ponga questi obiettivi; già in altre occasioni
abbiamo proposto la sperimentazione di DBMS centrali,
residenti su server, da parte di gruppi di ricerca diversi (BOSCATO, FRONZA, SALVADORI 2000). Risulta chiaro che il problema non è assolutamente di tipo tecnologico; la motivazione della mancata standardizzazione va piuttosto ricercata nelle obiezioni di vario ordine spesso poste dagli stessi
ricercatori. Viene soprattutto contestata l’applicabilità di
metodi di documentazione comuni a contesti fra loro disomogenei nella cronologia, nello spazio, nel tipo di sito, nelle problematiche coinvolte. In realtà, l’uso del mezzo informatico garantisce qualità e trasparenza nelle ricerche, costringendo i ricercatori ad effettuare controlli ripetuti ed
approfonditi sulla correttezza, completezza e affidabilità
delle informazioni acquisite.
Da parte nostra, crediamo (forse utopicamente) nella
possibilità di elaborare standard di minima che possano garantire l’interscambiabilità delle informazioni indipendentemente dal contesto applicativo; l’obiettivo è raggiungibile attraverso una corretta progettazione del modello dati (in
questo senso vanno intesi i principi delineati sopra) unita-
mente alla disponibilità dei ricercatori che producono, gestiscono e mettono a disposizione i dati. In un modello standard si può comunque prevedere la possibilità di effettuare
schedature “personalizzate” su specifiche classi di dati o
tematiche di ricerca; analisi particolari possono prevedere
caratteristiche di dettaglio dell’architettura e flessibilità del
dato troppo onerose da prevedere in un sistema di gestione
globale.
Resta ancora molta strada da percorrere prima che la
comunità scientifica possa recepire appieno, ed in larga
maggioranza, la portata delle tecnologie digitali nell’ambito delle metodologie archeologiche; si spera che in futuro,
anche attraverso l’attivazione di specifici insegnamenti presso i corsi di laurea archeologici, questo problema possa essere progressivamente risolto. Ad oggi manca ancora un’alfabetizzazione tecnologica sufficientemente estesa e, soprattutto, un tentativo approfondito e collettivo da parte dei ricercatori di comprendere e accettare il mezzo informatico
come strumento per la produzione di conoscenza. Al contrario, si nota una diffusa mancanza di volontà nel confrontarsi (criticamente ma senza preconcetti) con la standardizzazione del dato, un processo cognitivo prettamente archeologico rispetto al quale le tecnologie digitali sono solamente un mezzo di attuazione o, in alcuni casi, uno stimolo per
il miglioramento qualitativo della ricerca.
BIBLIOGRAFIA
BOSCATO P., FRONZA V., SALVADORI F. 2000, Un archivio informatizzato per la gestione dei reperti archeozoologici, in BROGIOLO (a cura di), II Congresso Nazionale di Archeologia
Medievale, Società degli archeologi Medievisti Italiani –
Musei Civici di Santa Giulia, (Brescia, 28 settembre-1 ottobre 2000), Firenze, pp. 46-52.
FRANCOVICH R. 2001, Introduzione al workshop, in FRANCOVICH,
VALENTI 2001.
FRANCOVICH R., VALENTI M. 2000, La piattaforma GIS dello scavo ed il suo utilizzo: l’esperienza di Poggibonsi, in BROGIOLO
2000, pp. 14-20.
FRANCOVICH R., VALENTI, M.
FRONZA V. 2000, Il sistema di gestione degli archivi nello scavo di
Poggio Imperiale a Poggibonsi (Insegnamento di Archeologia Medievale dell’Università di Siena). Una soluzione all’interno della “soluzione GIS”, «Archeologia e Calcolatori», 11, pp. 125-137.
FRONZA V. 2001, Il sistema degli archivi nella gestione di un cantiere di scavo e la sua integrazione in un sistema globale
(l’esperienza senese), in FRANCOVICH, VALENTI (a cura di), Relazioni preliminari, Workshop “Soluzioni GIS nell’informatizzazione dello scavo archeologico” (Siena 9 giugno 2001),
pubbl. digitale online: http://archeologiamedievale.unisi.it/
NewPages/FORUM2/Welcome.html
FRONZA V., NARDINI A., VALENTI M. 2002 C.S., An integrated information system for archaeological data management: latest
developments, in The digital heritage of archaeology. Computer Applications and Quantitative Methods in Archaeology, Proceedings of the 29th Conference. Heraklion (Crete,
Greece, 2nd-6th April 2002), Oxford.
NARDINI A. 2001, Il modello dei dati nell’applicazione GIS dello
scavo (l’esperienza senese), in FRANCOVICH, VALENTI 2001.
VALENTI M., 2000 La piattaforma GIS dello scavo nella sperimentazione dell’Insegnamento di Archeologia Medievale dell’Università di Siena. Filosofia di lavoro e provocazioni,
modello dei dati e “soluzione GIS”, «Archeologia e Calcolatori», 11, pp. 93-109.
632