6
CAPITOLO 2
2
I
L SISTEMA DI DOCUMENTAZIONE
progetto di questo lavoro trae presupposto, in primis, dall’esigenza pratica di cre‐ are un sistema di schede per la raccolta, il censimento e la processazione dei dati ricavabili da uno scavo stratigrafico. Per rispondere a questa richiesta, nata sul campo ed in laboratorio, è stato necessario predisporre un substrato epistemologico coerente, in grado di sviluppare una base comune ed uniforme, ovvero, in altre parole, un linguaggio trasversale a più campi semantici e di studio.
In effetti il problema è stato più volte dibattuto e ormai da molti anni si sta tentando, in Italia come nel resto del mondo, di “normalizzare” la grande teoria di schede archeologi‐ che, tanatologiche e architettoniche per giungere ad un punto d’incontro definitivo tra i modelli5; si avverte tuttavia la mancanza di un modus operandi comune, in grado di uni‐ formare la raccolta di dati e di condurre infine alla creazione di un database che sia con‐ temporaneamente universale e multidisciplinare. Su questo fronte l’informatica applicata all’archeologia ha, di fatto, condotto ad una sorta di paradosso, poiché, se da una parte ha aperto la strada ad un nuovo modo di concepire il dato, come elemento dinamico, duttile, infinitamente riproducibile, dall’altra ha anche incrementato la creazione di soluzioni im‐ prontate ciascuna sulle necessità del singolo gruppo di studio, alimentando così il melting pot di modelli sovrapponibili ma raramente compatibili. 5 Già Andrea Carandini (CARANDINI, A., 2000) denunciava la troppa dispersione di dati legata all’assenza di un modello comune e generalmente applicabile.
Il
7
Va detto che nel nostro paese molto ha fatto l’Istituto Centrale per il Catalogo e la Docu‐
mentazione (ICCD), elaborando una serie di schede ministeriali per la catalogazione dei
reperti e fornendo in tal modo uno strumento coerente, improntato sullo sforzo di predi‐ sporre una serie di liste di valori con un vocabolario chiuso e codificato. Il Ministero dei Beni Culturali mette a disposizione dell’utenza una serie di standard di classificazione e di modelli per la realizzazione delle schede di Unità Stratigrafica (US), Unità Stratigrafica Mu‐ raria (USM) e Unità Stratigrafica di Rivestimento (USR)6. Partendo dalle tracce dell’edito si è così tentato di creare qualcosa di nuovo e, in un certo senso, innovativo. Il lavoro di sintesi e di progettazione ha condotto all’elaborazione di due modelli di schede; il primo, più tradizionale, è di tipo cartaceo, il secondo, omologo nei contenuti, di tipo informatico. Per ciascuna scheda si sono utilizzate caratteristiche parti‐ colari, strettamente collegate all’impiego che di essa si voleva fare, ma tra loro collegate dall’uniformità del layout (per il modello cartaceo) e dalla base di dati (per quello digitale).
2.1 L
E SCHEDE CARTACEEIl lavoro di progettazione e realizzazione del sistema di documentazione ha come princi‐ pio un pacchetto di schede su base cartacea sviluppato negli anni grazie all’aiuto ed alla i‐ spirazione di collaboratori e modelli ed attraverso l’impiego diretto sul banco di prova di numerose esperienze di scavo stratigrafico ed antropologico7. Si presentano nei prossimi paragrafi le seguenti schede: ‐ Scheda di Unità Stratigrafica (US) ‐ Scheda di Unità Stratigrafica Muraria (USM) ‐ Scheda di Unità Scheletrica (Usc) Per ciascuna scheda si riportano: ‐ Riferimento visuale ‐ Anni di sperimentazione sul campo ‐ Lingua di base ed eventuale traduzione ‐ Versione di release 6 Tutte scaricabili dal portale dell’Istituto, alla pagina: http://www.iccd.beniculturali.it/Catalogazione/standard‐catalografici/normative/nomative 7 Le schede qui presentate hanno trovato sperimentazione e collaudo in numerosi siti, italiani e stranieri; tra questi si : Benabbio (Lu), Badia Pozzeveri (Lu), Vecchiano (Pi), Piazza Mercurio (Ms), Piazza Aranci (Ms), Civitella (Vt), Miranduolo (Si), San Genesio (Si), Pieve di Pava (Si), Ex‐Gentili (Pi), Scavi della Ohio State University, dr. Larsen (USA).
8 ‐ Presenza di una relativa versione elettronica8 ‐ Cantieri di scavo in cui la scheda sia stata testata
2.1.1 S
CHEDA DIU
NITÀS
TRATIGRAFICARif.: Tav. 1, pag. 124; Tav. 2, pag. 125 Test.: 2007, presente Lingua: Italiano, Inglese Release: 2.0 (Ita), 1.2 (En) Corrispondente elettronico: sì Siti di impiego: Benabbio (Lu), Badia Pozzeveri (Lu), Vecchiano (Pi), Piazza Aran‐ ci (Ms), Civitella (Vt) La Scheda di Unità Stratigrafica elaborata (SUS) nasce a partire dalla scheda ministeriale dell’ICCD9. Il prototipo, sperimentato sin dal 2007, mira a rispondere alle principali esi‐ genze di uno scavo stratigrafico, conformandosi alle domande fondamentali che ci si pone in fase di ricerca sul campo, senza appesantire il lavoro di schedatura con campi pleonasti‐ ci o delegabili ad altro tipo di documentazione (fotografica e geografica in primis). La scheda, nella sua sostanza, si divide in due sezioni. La prima parte (quadri 1‐2) è dedicata ad una lettura di tipo denotativo dell’unità di sca‐ vo in esame. 1. Quadro 1: Osservazioni Generali: 1.1. Coordinate: caselle riservate al georiferimento delle coordinate cartesiane (x, y, z) rilevate a stazione totale sull’unità di scavo10.
1.2. Posizione nell’area: schizzo geometrico per la visualizzazione rapida dell’elemento all’interno dell’area di scavo.
1.3. Breve definizione: descrizione sintetica correlabile all’omologa definizione po‐ sta nell’elenco US e nell’intestazione del database (cfr. infra).
1.4. Definizione US: form a campi obbligati per la tipologizzazione delle US. I valori sono ripresi dalla codificazione ministeriale (1. Chiazza, 2. Lamina, 3. Strato, 4. 8 Si intenda al momento della stesura del presente elaborato. 9 Il modello di riferimento resta quello statutario, già sperimentato da anni dalle Soprintendenze Archeologiche; per le norme redazionali, di conseguenza, si rimanda alle pagine pubblicate sul sito: http://www.iccd.beniculturali.it/index.php?it/251/beni‐archeologici 10 Il campo proposto si intende sostituibile con una griglia per la triangolazione da picchetti, ove la stazione totale non sia disponibile.
9 Lente, 5. Paleosuperficie, 6. Paleosuolo, 7. Concentrazione, 8. Conoide, 9. Cumulo, 10. Muro, 11. Pavimento, 12. Struttura, 13. Riempimento, 14. Taglio, 15. Cresta, 16. Usura). 1.5. Formazione: determinazione del modo di formazione dell’unità (artificiale sin‐ cronico, artificiale progressivo, naturale sincronico, naturale progressivo). 1.6. Colore: determinazione del colore dell’unità di scavo11. 1.7. Consistenza: grado di friabilità dell’unità di scavo (sciolta=sabbia, friabile=limo a grani fini, compatta=argilla, cementata=malta) 1.8. Conservazione: processi di sconvolgimento dell’unità di scavo postdeposiziona‐ li.
1.9. Descrizione: spazio dedicato alle osservazioni denotative e non interpretative dell’US.
1.10. Disegno: quadro dedicato alla rappresentazione grafica in scala visuale ed o‐ rientata dell’unità di scavo.
1.11. Componenti: elementi determinanti la composizione fisico‐chimica dell’unità; i campi, a scelta obbligata, sono tripartiti in: componenti geologici, componenti
organici e componenti artificiali.
La seconda sezione (quadri 2‐3) raccoglie i campi destinati all’interpretazione dei rap‐ porti stratigrafici, della natura e della cronologia del record; infine, un ultimo spazio (qua‐ dro 4) raccoglie i dati riferiti alla setacciatura, alla raccolta di reperti ed alla campionatura.
2. Quadro 2: Relazioni stratigrafiche
2.1. Affidabilità stratigrafica: carnet di caselle a scelta obbligata relativo all’affidabilità della lettura del contesto al momento dello scavo12.
2.2. Relazioni: campi compilabili con la sigla della/e US correlate13 secondo i se‐ guenti rapporti: 1. Uguale a, 2. Si lega a , 3. Coperto da, 4. Copre, 5. Gli si appog‐ gia, 6. Si appoggia a, 7. Tagliato da, 8. Taglia, 9. Riempito da, 10. Riempie, 11. Trasformato da, 12. Trasforma14. 2.3. Matrix di Harris: diagramma stratigrafico dei rapporti diretti tra le interfacce delle US univocamente correlate al contesto15. 3. Quadro 3: Interpretazioni e Datazioni 11 Lo schema proposto si intende sostituibile con una tavola cromatica Munsell. 12 P.e. “affidabilità pessima” nel caso di terreno allagato dopo perturbazione; “affidabilità eccellen‐ te” con terreno asciutto ma non secco e irradiazione luminosa tangente. 13 Si intendano tutte le US interessate da un rapporto, anche indiretto, col contesto, (cfr. punto 2.3) 14 I rapporti sono mutuati da quanto già codificato in Harris (HARRIS, E.C., 1983). 15 Ibid.
10
3.1. Interpretazione: campo a inserimento libero dedicato alla descrizione inter‐ pretativa del contesto, in base alle sue relazioni, alle sue caratteristiche tipolo‐ giche, ai suoi componenti ed al materiale rinvenuto al suo interno, nonché al suo posizionamento stratigrafico (orizzontale e verticale) nell’area. 3.2. Datazioni: campi destinati alla sintesi cronologica relativa del contesto in fun‐ zione dei suoi rapporti e del materiale cronotipologizzante. 4. Quadro 4: Setacciature, campionamenti e reperti 4.1. Campionatura: campi a scelta obbligata relativi alle modalità di campionatura del sedimento e degli inclusi. 4.2. Reperti notevoli: campo a inserimento libero per una descrizione sommaria e interpretativa dei reperti di notevole interesse rinvenuti nel contesto. 4.3. Sacchetti dei reperti: caselle a valore numerico indicanti la quantità di sacchet‐ ti correlati alle unità immagazzinate.
2.1.2 S
CHEDA DIU
NITÀS
TRATIGRAFICAM
URARIARif.: Tav. 3, pag. 126; Tav. 4, pag. 127 Test.: 2011, presente Lingua: Italiano, Inglese Release: 1.1 (Ita), 1.1 (En) Corrispondente elettronico: sì (in fieri) Siti di impiego: Benabbio (Lu), Badia Pozzeveri (Lu), Vecchiano (Pi) La Scheda di Unità Stratigrafica Muraria (SUSM) risponde alle richieste di identificazione, censimento ed interpretazione degli elementi architettonici emergenti nell’area di indagi‐ ne o nei suoi contesti, ove queste possano in qualche modo aggiungere informazioni ar‐ cheologiche, storiche o tipologiche allo scavo o alla ricerca. Il modello sviluppato prende forma dagli standard già mutuati dai prototipi ICCD secondo le moderne discipline della stratigrafia architettonica16.
Anche in questo caso la pluralità di precedenti, ancorché assai preziosa, ha giocato un ruolo piuttosto scomodo, poiché è stato difficile trovare un modello di riferimento unita‐ rio. Difatti, come Brogiolo ha sintetizzato qualche anno fa, accanto al perfezionamento de‐ gli strumenti per l'analisi stratigrafica degli elevati, vari gruppi di ricerca hanno messo a
11
punto metodi di indagine finalizzati alla registrazione di altre sequenze: da quelle legate alle dinamiche formative del singolo edificio (sequenza degli intonaci, delle parti lignee, degli equilibri statici, del degrado) ad altre relative a contesti più ampi (come nel caso del‐ la sequenza dei cicli produttivi o delle forme "intese come distribuzione gerarchica degli spazi e dei percorsi")17. Nel nostro caso si è tentato di sintetizzare in un solo prototipo tut‐ te quelle schede tipizzanti gli aspetti più propriamente architettonici utilizzate in archeo‐ logia (schede USM; scheda edificio; scheda tecniche murarie; scheda aperture). La prima parte della scheda è dedicata all’inquadramento generale del contesto mura‐ rio; per tale scopo si è utilizzata la terminologia già ampiamente documentata dalle fonti18, rispettando la terminologia tipica di Complesso Architettonico (C.A.), Corpo di Fabbrica (C.F.), Prospetto (P), Ambiente (A) e Settore (S). Tra le voci successive troviamo il campo 'classe edilizia', creato per operare una iniziale divisione tra edilizia pubblica, privata, ecclesiastica e strutture difensive. Il campo 'tipologia edilizia’ è opportuno per precisare l’utilizzo specifico del contesto19. Naturalmente, soprattutto nel caso delle emergenze in elevato, la definizione della funzio‐ ne di ogni struttura corrisponde a quello che era in origine il suo uso primario, tant'é che il successivo campo 'uso secondario’ è pensato proprio in relazione alla necessità di eviden‐ ziare l'eventuale cambiamento di funzioni delle strutture classificate. La voce 'leggibilità struttura' con le tre opzioni non 'leggibile/parziale/totale', serve per indicare quando una struttura muraria è completamente coperta dall'intonaco, da altri e‐ difici poggiati o visibile in parte, dando così la possibilità di calcolare in percentuale quan‐ to può essere registrabile in un centro storico. Il campo ‘visibilità’ è direttamente legato al‐ la leggibilità e serve ad indicare, nel caso in cui una struttura sia analizzabile totalmente o in alcune parti, quante di queste si siano preservate ad esempio da interventi successivi, da pesanti restauri o da coperture vegetali o antropiche ineludibili. La voce ‘descrizione’ consente un’analisi denotativa del contesto, limitando il più possibi‐ le un approccio di tipo interpretativo. 17 (BROGIOLO, G.P., 1997, p.182) 18 Si rammenta per esempio il bel lavoro di sintesi fatto da Parenti all’interno del I ciclo di lezioni sulla ricerca applicata in Archeologia (PARENTI, R., 1988). 19 Così, per esempio, nel caso di una struttura ecclesiastica, si specificherà se si tratta di una chiesa, una pieve, un oratorio, un'area cimiteriale, un chiostro, etc. oppure se ad una struttura privata cor‐ risponde una casa a pilastri, una torre, una casa‐torre, un palazzo, una casa, così come nel caso di una struttura pubblica si specificherà se si parla di un palazzo comunale, di una fonte, di un ospeda‐ le, di un ponte, etc.. Nel caso invece di strutture difensive verrà distinto se l'oggetto di studio è ad esempio una cinta muraria, una delle sue porte od una torre.
12
La seconda parte della scheda è dedicata alla lettura degli elementi architettonici dell’elevato. Le voci riportate sono le seguenti: 1. Materiale utilizzato per la costruzione 2. Forma 3. Dimensioni 4. Processi di lavorazione 5. Finitura 6. Caratteristiche del nastrino 7. Tracce di strumenti 8. Posa in opera In particolare, per la gestione dei dati relativi alla tecnica muraria, dei numerosi campi presenti nella scheda, si è scelto di evidenziare la definizione muratura (in cui specificare il tipo di posa in opera, le differenze tra paramento esterno od interno, il tipo di nucleo etc.), il materiale da costruzione (con relative caratteristiche, relative anche ai mattoni, come il colore o gli inclusi ad esempio), la lavorazione del pezzo, la finitura, la malta (tipo di legan‐ te, coesione etc.), la cronologia . Questi parametri sono infatti necessari a specificare alcuni dati non direttamente desumibili dal rilievo. I due successivi paragrafi vanno ad analizzare le caratteristiche specifiche dei ’letti di po‐ sa’ e dei ‘giunti’, determinandone posizione, numero minimo, numero massimo e la media‐ na. Infine una serie di voci sono dedicate ai componenti ed alle infrastrutture del tessuto ar‐ chitettonico (inzeppature, legante, aggregati, aderenza, pareggiamenti), alle caratteristiche intrinseche del contesto analizzato (colore, consistenza) ed alle eventuali campionature ef‐ fettuate.
La terza sezione è riservata alle relazioni stratigrafiche, per la cui tipologizzazione si rimanda al paragrafo precedente, mentre la quarta si imposta sull’interpretazione e la da‐ tazione del contesto. Qualche nota meritano le voci legate a quest’ultimo aspetto, che è sta‐ to sottoposto a revisione e discussione. La voce ‘attività' (dando a questo termine il signifi‐ cato che ha con le stratigrafie orizzontali) è ovviamente riferibile alla numerazione pro‐ gressiva della attività o delle attività pertinenti la struttura muraria esaminata. Gli ultimi due campi sono invece dedicati alla cronologia dell'elevato: 'periodo' è una voce per illu‐ strare la sequenza cronologica che interessa la nostra emergenza. Si tratta, naturalmente, di un campo che può inizialmente anche non essere compilato nel caso in cui l’emergenza manchi di qualunque tipo di riferimento cronologico, ed essere completato in seguito quando, rielaborando i dati, è possibile magari giungere ad un confronto illuminante per inserire la struttura in un determinato periodo. Stessa considerazione vale pertanto anche con il campo 'elementi datanti' dove, nell'eventualità di una loro presenza, si segnalano le
13 fonti dirette o indirette che hanno indirizzato quella collocazione cronologica, inserendo nel caso in cui ci fossero, i pertinenti riferimenti bibliografici20. Il modello messo a punto nel corso dell’ultima campagna di scavo Benabbio e testato an‐ che a Badia Pozzeveri (cfr. infra), vuole integrarsi con il database relazionale che si pone alle spalle di tutti i protocolli sviluppati (cfr. par. 2.2).
2.1.3 S
CHEDA DIU
NITÀS
CHELETRICARif.: Tav. 5, pag. 128; Tav. 6, pag. 129; Tav. 7, pag. 130; Tav. 8, pag. 131; Tav. 9, pag. 132; Tav. 10, pag. 133 Test.: 2007, presente Lingua: Italiano, Inglese Release: 4.1 (Ita), 4.0 (En) Corrispondente elettronico: sì
Siti di impiego: Benabbio (Lu), Badia Pozzeveri (Lu), Vecchiano (Pi), Piazza
Mercurio (Ms), Miranduolo (Si), San Genesio (Si), Pieve di Pava (Si), Ex‐Gentili (Pi), Scavi della Ohio State University, dr. Larsen (USA) La scheda che ha comportato maggiore studio è stata quella dedicata ai reperti ossei. I precedenti cui ispirarsi in questo caso non sono stati molti: infatti, nonostante siano stati fatti numerosi tentativi al fine di elaborare una serie di parametri atti alla creazione di un modello compilativo trasversale, non esiste al momento in Italia uno standard unico da se‐ guire: ogni istituto gestisce il computo dei materiali scheletrici a seconda delle proprie esi‐ genze peculiari e, di fatto, c’è discrepanza persino sulla terminologia da utilizzare nella classificazione della scheda: in alcuni cantieri la si chiama “Scheda di Unità Tafonomica”, in altri “Scheda di Unità Antropologica”, ecc.21. Dal 2007 dunque è iniziata l’elaborazione e la sperimentazione sul campo di una Scheda di Unità Scheletrica, definita dall’acronimo SUsc, del tutto inedita: si tratta di un protocollo compilativo per la gestione delle evidenze an‐ tropologiche rinvenute durante uno scavo. Sviluppata sulla base delle schede da campo di 20 In base ai parametri individuati prima da Mannoni (MANNONI, T., 1984) e poi ripresi da Parenti (PARENTI, R., 1988). 21 Le definizioni tendono spesso a sottolineare le prerogative scientifiche dell’équipe di scavo: ad esempio la Scheda di Unità Tafonomica utilizzata in molti cantieri senesi è sostanzialmente impron‐ tata sugli aspetti più precipuamente archeologici di una deposizione funeraria, ovvero la tipologia sepolcrale, i rapporti stratigrafici, il corredo funebre; quella elaborata per questa tesi e battezzata “Scheda di Unità Scheletrica” mira invece di più ad un’analisi antropologica dei resti umani, deman‐ dando alla scheda di US gli aspetti stratigrafici.
14
Canci e Minozzi22 e di Duday23, è stata arricchita grazie al prezioso apporto della dott.ssa
Angelica Vitiello. Nella sua struttura la scheda consta di due parti speculari, una cartacea, da compilare durante la campagna di scavo e frutto di osservazione diretta delle evidenze dissepolte, l’altra informatica, nella quale trovano spazio i medesimi dati elaborati sulla gemella cartacea. Questi dati entrano a far parte di un grande sistema di banche‐dati rela‐ zionali compatibili e integranti il software Bones (cfr. infra). La SUsc consta di due parti: ‐ la prima (pagine 1 e 2) è dedicata alle osservazioni tafonomiche, tanatologiche ed archeologiche e raggruppa al suo interno quattro paragrafi (1 ‐ 4): I. Osservazioni generali, ovvero: a) breve descrizione denotativa dell’US, b) dispo‐ sizione generale del corpo, c) stato di conservazione dello scheletro, d) decubi‐ to, e) tipologia sepolcrale, f) tipo di deposizione, g) orientamento, h) inventario sinottico delle ossa, i) schizzo grafico, l) documentazione correlata; II. Osservazioni archeologiche, ovvero: a) relazioni stratigrafiche, b) corredo, c) matrix stratigrafico24; III. Osservazioni tafonomiche, ovvero: a) caratteristiche della fossa, b) caratteri‐ stiche dell’inumato; IV. Osservazioni antropologiche ed antropometriche, ovvero: a) sesso, b) età alla morte, c) alterazioni morfologiche, d) patologie, e) misurazioni sul campo; ‐ la seconda (pagine 3 e 4) è invece riservata alle osservazioni antropologiche e mor‐ fologiche dei singoli distretti scheletrici ed è suddivisa nei seguenti paragrafi (5‐10):
V. Cranio e denti, ovvero: a) apparizione cranio, b) posizione cranio, c) connes‐
sioni, d) dentatura, e) inventario degli elementi dentari;
VI. Colonna vertebrale, ovvero: a) connessioni, b) punti di disconnessione;
VII. Cinture, ovvero: a) connessioni del cinto scapolare, b) connessioni del cinto
pelvico; VIII. Arti superiori, ovvero: a) posizione, b) connessioni; IX. Arti inferiori, ovvero: a) posizione, b) connessioni; X. Compressioni, ovvero: a) tipo compressione, b) natura compressione. 22 (CANCI, A. and Minozzi, S., 2005) 23 (DUDAY, H., 1990) 24 Secondo il noto modello esposto da Harris (HARRIS, E.C., 1983)
15
La compilazione della scheda è guidata e facilitata da un sistema di campi omogenei e preordinati che possono essere di testo, di selezione, di spunta e di scelta multipla. L’abbondante presenza di campi‐note consente di impostare un’indagine quanto più det‐ tagliata delle evidenze; d’altro canto, la prerogativa logico‐informatica che sta alla base del progetto riduce al minimo l’imprecisione e la ridondanza di informazioni, normalizzando la qualità dei dati. Ciò ha consentito di creare un database commutativo e compatibile con quello di Bones e di migrare le informazioni ricavate sulla piattaforma GIS, sì da ottenere delle tabelle rela‐ zionate25 che vadano ad integrare le informazioni geo‐spaziali. La SUsc ha trovato applicazione in tutti i cantieri di scavo della Divisione di Paleopatolo‐ gia dell’Università di Pisa e di altri Dipartimenti universitari26, nonché in alcuni siti super‐ visionati dal prof. C.S. Larsen della Ohio State University27. 25 Come si dirà più avanti l’operazione di join consente di collegare due o più tabelle informatiche attraverso una chiave relazionale che ne mantiene l’integrità referenziale. 26 Si citano come esempio le applicazioni sui canteri senesi della Pieve di Pava (sotto la supervisione della dott.ssa Valeria Mongelli) e dello scavo di Miranduolo (sotto la supervisione della dott.ssa Sil‐ via Testi). 27 Tra questi lo scavo di Badia Pozzeveri (Lu), cfr. infra.
16
2.2 L
E SCHEDE INFORMATICHEAi modelli cartacei descritti nei precedenti paragrafi fanno da contrappunto altrettanti protocolli informatici, che ne riprendono struttura e campi. Alla base di queste schede elettroniche sta una banca elettronica comune, che mira a rac‐ cogliere tutta la teoria di informazioni reperite sul campo ed a normalizzarla trasforman‐ dola in un flusso dinamico di dati elaborabili. In informatica, il termine database, banca dati, o appunto base di dati (soprattutto in testi accademici), indica un archivio strutturato in modo tale da consentire la gestione dei dati stessi (l'inserimento, la ricerca, la cancellazione ed il loro aggiornamento) da parte di ap‐ plicazioni software28. Il database è un insieme di informazioni, di dati che vengono suddi‐ visi per argomenti in ordine logico (tabelle) e poi tali argomenti vengono suddivisi per ca‐ tegorie (campi). Informalmente e impropriamente, la parola “database” viene spesso usata come abbreviazione dell'espressione Database Management System (DBMS), che si riferi‐ sce a una vasta categoria di sistemi software che consentono la creazione e la manipola‐ zione efficiente di database29. La base di dati, oltre ai dati veri e propri, deve contenere anche le informazioni sulle loro rappresentazioni e sulle relazioni che li legano. In Bones alloggiano tutta una serie di strut‐ ture informatiche complementari e funzionali alla corretta applicazione dei protocolli; tra esse si possono citare: Strutture dati che velocizzano le operazioni frequenti, tipicamente a spese di ope‐ razioni meno frequenti. Collegamenti con dati esterni, cioè riferimenti a file locali o remoti non facenti par‐ te del database. Informazioni di sicurezza, che autorizzano solo alcuni profili utente ad eseguire al‐ cune operazioni su alcuni tipi di dati. Programmi che vengono eseguiti, automaticamente o su richiesta di utenti autoriz‐ zati, per eseguire elaborazioni sui dati. Un tipico automatismo consiste nell'esegui‐ re un programma ogni volta che viene modificato un dato di un certo tipo. Le basi di dati possono avere varie strutture, tipicamente: 1. gerarchica (rappresentabile tramite un albero), 2. reticolare (rappresentabile tramite un grafo), 28 (ELMASRI, R. and Navathe, S.B., 2003) 29 (ATZENI, P. et al., 2007)
17
3. relazionale (attualmente il più diffuso e utilizzato anche per il nostro software, rappresentabile mediante tabelle e relazioni tra esse), 4. ad oggetti (estensione alle basi di dati del paradigma "Object Oriented", tipico della programmazione a oggetti), 5. semantica (rappresentabile con un grafo relazionale). Un requisito importante di una buona base dati consiste nel non duplicare inutilmente le informazioni in essa contenute: questo è reso possibile dai gestori di database relazionali (teorizzati da Edgar F. Codd30), che consentono di salvare i dati in tabelle che possono es‐ sere collegate mantenendo l’integrità referenziale del medesimo record inserito in elenchi diversi e comunicanti. La funzionalità di un database dipende in modo essenziale dalla sua progettazione: la corretta individuazione degli scopi del database e quindi delle tabelle, da definire attraverso i loro campi e le relazioni che le legano, permette poi una estrazione dei dati più veloce e, in generale, una gestione più efficiente.
In campo archeologico l’utilizzo del database relazionale trova campo di attuazione in contesti a molteplici dimensioni. Come si dirà più avanti (cfr. par. 2.2.4), negli ultimi anni chi scrive ha potuto creare e sperimentare diverse applicazioni informatiche legate alla gestione di studi archeologici su ampia scala. In questi paragrafi, tuttavia, ci soffermeremo su protocolli pensati per un uso contestuale limitato ai record di scavo e laboratorio; am‐ bienti, questi, che sono anche il nucleo primigenio e centripeto su cui impostare una scala‐ tura graduale man mano crescente e generalizzante, in linea cioè col principio di induzione sviluppato a partire dall’approccio postprocessuale della moderna archeologia31.
2.2.1 D
ATABASE PER LEU
NITÀ DIS
CAVOLa gestione dei dati di scavo in fase di processazione, soprattutto per quanto riguarda missioni archeologiche di durata pluriennale, risulta molto spesso ostica e complicata se non si fa uso di strumentazioni informatiche. Le possibilità offerte dai moderni software GIS e database consentono una schedatura ordinata ed un recupero immediato di tutte le informazioni. Come detto, i precedenti e i modelli di ispirazione sono numerosi (special‐ mente negli ambienti accademici d’Oltremanica), tuttavia era necessario applicare un filtro ed una normalizzazione dei campi, in rispetto agli standard ministeriali e, di conseguenza, all’omologo prototipo cartaceo già descritto al par. 2.1.1. In particolare, per la realizzazione 30 (CODD, E.F., 1970) 31 (RENFREW, C. and Bahn, P., 2006)
18 della scheda elettronica di unità stratigrafica (SEUS), ci siamo basati su di una libera riela‐ borazione del modello ideato nel 1990 dal DUA32 e sul prototipo concessoci gentilmente in visione dal prof. Federico Cantini dell’Università di Pisa33. La scheda è stata creata graficamente attraverso le funzioni di Microsoft Access 2007, tut‐ tavia si appoggia ad un DBMS sviluppato a monte per mezzo di un editor VB SQL. Questa base di dati raccoglie non soltanto le Unità Stratigrafiche, ma tutte le unità di scavo (Unità Scheletriche, unità Stratigrafiche Murarie) e di laboratorio; questo, grazie all’uniformità delle sigle identificative, che svolgono la funzione di chiave normativa primaria e, associa‐ te alla sigla del cantiere di scavo, assumono carattere di univocità, permette di creare un “ponte” tra le varie applicazioni e renderle conseguentemente compatibili.
La scheda, nella sua schermata iniziale, riproduce un tipico elenco US, che si auto‐ aggiorna automaticamente, all’inserimento di ogni nuovo contesto; da questo prospetto è possibile fare ricerche, stampare report ed esportare i dati, nonché accedere direttamente alla scheda di ogni singola unità di scavo e stampare i modelli delle schede cartacee de‐ scritti nei precedenti paragrafi (Figura 1). Figura 1 ‐ Schermata iniziale della Scheda Elettronica di Unità Stratigrafica 32 Si tratta di un progetto ancora all’avanguardia elaborato dal Department of Urban Archaeology of London Museum Instituted ed edito da Spence (SPENCE, C., 1993). 33 Il modello elettronico, elaborato dalla dott.ssa Beatrice Fatighenti, è in uso presso numerosi can‐ teri di scavo gestiti dall’insegnamento di Archeologia Medievale.
19
Il comando ‘Nuova unità’ consente di aprire un’ulteriore finestra di scelta, denominata “Avvio” (Figura 2), nella quale inserire la denominazione, la sigla e l’anno del cantiere di scavo, l’area e il settore di pertinenza dell’unità, la data di compilazione e le generalità del‐ lo scavatore e del compilatore34. Il campo a tendina ‘Tipo US’ vincola la scelta della tipolo‐ gia di contesto a tre possibilità, le quali rimandano ad altrettante interfacce: US ‐ Scheda Elettronica di Unità Stratigrafica (par. 2.2.2), Usc ‐ Scheda Informatica di Unità Scheletrica (par. 2.2.3), USM ‐ Scheda elettronica di Unità Stratigrafica Muraria (In fieri). C’è da notare che, nonostante la molteplicità di interfacce dedicate a ciascuna tipologia di contesto, il database residente che sta a monte riconosce ogni record come un’unità inte‐ grata in un’unica lista; in tal modo l’elenco derivante andrà a raccogliere tutte le voci, indi‐ pendentemente dalla loro natura (US, USM, Usc) per creare una sovrastruttura di dati uni‐ versale. Questo è quanto mai importante quando si voglia estrapolare tutta la serie dei dati appartenenti, ad esempio, ad un’intera campagna di scavo per incrociarli tra loro al fine di ottenere statistiche e grafici. Figura 2 ‐ Maschera di avvio per la scelta delle tipologie di contesto
2.2.2 S
CHEDA INFORMATICA DIU
NITÀS
TRATIGRAFICALa prima opzione selezionabile dalla Maschera di avvio (vd. par. precedente) rimanda all’apertura della vera e propria Scheda Elettronica di Unità Stratigrafica. 34 I campi sono frutto di una scelta maturata dall’esperienza sul campo; ciò non toglie che non tutti i cantieri possano scegliere univocamente suddivisioni in aree e settori (si pensi a scavi urbani o di edifici, in cui, di norma, si preferisce partizionare lo scavo in ambienti o stanze). In tal caso sarà pos‐ sibile ripensare la struttura della tabella di raccolta dei dati in funzione di ciascuna esigenza parti‐ colare.
20 La maschera (Figura 3) ricalca il corrispondente prototipo cartaceo (vd. par. 2.1.1), ma vi sono sezioni che presentano un notevole potenziamento rispetto ad esso: la prima è costi‐ tuita dal campo ’Allegati’, dal quale è possibile includere immagini o documenti collegati al contesto e residenti in qualsiasi cartella del computer, senza che vengano caricati sul DMBS come oggetti OLE (ciò evita l’appesantimento del database); la seconda è la tabella
‘Coordinate’ che, raccogliendo dati numerici, consente una rapida esportazione in un foglio
dati esterno per la processazione in AutoCAD o in una piattaforma GIS35. Il terzo campo dinamico è rappresentato dal matrix stratigrafico, compilabile attingendo direttamente dall’elenco di UUSS già inserite nel sistema (e accessibili dalla lista posta a destra). Figura 3 ‐ Schermata principale di inserimento della SEUS 35 L’esportazione avviene in automatico selezionando il pulsante “Esporta Coordinate”, attraverso una routine VB creata ad hoc; l’importazione in AutoCAD del file creato è mutuata attraverso un plug‐in scaricabile dal sito: http://www.abcautocad.it/software_autocad.html
21 Dalla barra dei comandi è possibile accedere alla scheda di refertazione del materiale ce‐ ramico rinvenuto all’interno dell’unità stratigrafica36 (Figura 4), alla quale, invero, non ri‐ sponde un modello su foglio, poiché la sua compilazione è delegata ad un momento suc‐ cessivo allo scavo sensu stricto, e sarà dunque sufficiente stampare il report della tabella compilata per avere un riferimento cartaceo. La scheda, che si lega a quella di US con un rapporto di molti‐a‐uno (ovvero per ciascuna US è possibile avere più schede della ceramica, a seconda del numero delle classi cerami‐ che in essa rinvenuta) si compone di due maschere tabulari: la prima (Figura 4, sinistra) destinata alla descrizione del materiale, la seconda (Figura 4, destra) al conteggio dei frammenti di ciascuna classe, ai confronti ed ai disegni37.
Figura 4 ‐ Maschera della Ceramica
2.2.3 S
CHEDA INFORMATICA DIU
NITÀS
CHELETRICADirettamente connessa alla volontà di creare una sovrastruttura informatica in grado di gestire l’indagine archeo‐antropologica di resti osteologici, la Scheda Informatica di Unità scheletrica (SIUS) è stata sviluppata sperimentalmente per rispondere alle esigenze di uno scavo estensivo e pluriennale come quello di Benabbio. La cospicua quantità di sepolture che ci si aspettava uscissero dagli orizzonti cimiteriali del sito, ha indirizzato, sin dalla prima campagna, gli sforzi di chi scrive a realizzare un corrispondente elettronico alla 36 Sono in fase di realizzazione anche analoghi moduli relativi ai reperti in metallo e vetro. 37 I campi, per maggior parte a scelta obbligata in modo da vincolare l’utilizzo di voci normalizzate, rispondono al lessico ed al repertorio formale classificatorio codificato nei lavori della CUOMO DI CAPRIO (1985) e delle più recenti sintesi effettuate da Marco Milanese (2009) e, per il contesto pi‐ sano, da GRAZIELLA BERTI e MARCELLA GIORGIO (2011).
22 scheda già illustrata nel par. 2.1.3 che permettesse di inserire all’interno di una base di dati le informazioni ricavate in situ simultaneamente all’indagine sul campo. Diversamente dalla SEUS (cfr. par. 2.2.2), lo scheletro della scheda è stato realizzato con Visual Basic, che, come vedremo più avanti (cfr. par. 2.3.1), consente lo sviluppo di applica‐ zioni residenti molto più performanti rispetto agli strumenti offerti da Access. Il software, inserito nel medesimo pacchetto di installazione di Bones, si presenta come una serie di maschere interfacciate tra loro e omologhe alla struttura del prototipo cartaceo (Figura 5). Ogni scheda è compilabile, indipendentemente dalle altre, seguendo parametri il più del‐ le volte obbligati e dunque esenti da errori; la specularità dei campi con i corrispondenti cartacei facilita l’inputazione e non porta al rischio di possibili errori interpretativi, in mo‐ do che anche l’utente meno esperto in campo antropologico possa essere in grado di con‐ durre a conclusione l’inserimento di un record (elemento molto importante durante uno scavo didattico come Benabbio). I vantaggi legati all’utilizzo di un’applicazione informatica sono, ovviamente, molteplici: oltreché l’intrinseca normalizzazione dei dati inseriti, è infat‐ ti possibile esportare e riprodurre le informazioni all’infinito, nonché allegare ad ogni re‐ cord una ulteriore documentazione digitale (fotografie, documenti di testo, ecc.). Il pro‐ gramma, inoltre, è pensato per interagire col GIS di scavo, collegandosi ad esso attraverso legami logici primari; in tal modo è possibile legare alla documentazione alfanumerica di un individuo anche tutti quei dati spaziali altrimenti mal definibili, specialmente in campo antropologico (Figura 6). Figura 5 ‐ SIUS: Osservazioni generali
23 Figura 6 ‐ SIUS: collegamento al GIS di scavo La volontà programmatica di chi scrive è indubbiamente quella di implementare le po‐ tenzialità di supporti come le Scheda elettroniche di Unità Stratigrafica e Scheletrica, so‐ prattutto in funzione di una loro divulgazione in ambito accademico e di cantiere. La dire‐ zione da intraprendere è quella di una crescente integrazione tra le varie applicazioni do‐ cumentative al fine di creare una sovrastruttura unitaria ed “autosufficiente”.
2.2.4 A
LTRE APPLICAZIONI SVILUPPATELe potenzialità offerte dalle applicazioni costruite su basi di dati relazionali si sono con‐ cretizzate, durante gli anni di specializzazione dello scrivente, in alcuni progetti collaterali alla formazione. In particolare sono stati sviluppati due database, nati in seno agli inse‐ gnamenti di Archeologia della Produzione e Archeologia dell’Età dei Metalli.
***
Il primo prototipo, fortemente patrocinato dal prof. Fabio Fabiani, ha avuto come oggetto di studio un progetto di censimento degli impianti per la produzione dell’olio nell’Italia Romana. La vastità del lavoro, effettuato da una pluralità di voci narranti38, e la concreta volontà di ampliare e diffondere la ricerca, hanno indotto ad affiancare al consueto impe‐ gno di reperimento e risistemazione delle fonti documentarie uno strumento informatico 38 L’opera è stata condotta assieme ai colleghi specializzandi ed è in fase di pubblicazione sui gior‐ nali della Scuola di Specializzazione in Archeologia dell’Università di Pisa (FABIANI, F. et al., 2011).
24 di raccolta, gestione ed elaborazione dei dati prodotti; in tal senso si è resa necessaria la costituzione di un database in grado di rispondere alle richieste dei ricercatori. La creazione di una scheda informatica per la catalogazione degli impianti connessi alla produzione dell’olio nell’Italia romana è inevitabilmente partita dalla determinazione dei “campi sensibili”, ovvero di quelle domande la cui risposta risultasse indispensabile ad in‐ quadrare e analizzare i problemi e le tematiche archeologiche precipue dei cicli di lavora‐ zione dell’olio nell’antichità. Ovviamente, se è risultato alquanto banale individuare le voci di base (il “nome dell’insediamento”, la “localizzazione”, l’“inquadramento cronologico”, ecc.), assai complessa è stata la definizione dei campi più trasversali o liminari alla mate‐ ria, come le “fasi di vita” di un impianto, la presenza di altri cicli produttivi, connessi o non, o l’inquadramento topografico (la disponibilità di risorse idriche contestuali all’insediamento, la viabilità, ecc.); c’era infatti il rischio di tralasciare elementi di collega‐ mento importanti, l’assenza dei quali si sarebbe potuta riverberare sugli altri, inficiandone la coerenza (Figura 7). Figura 7 ‐ Struttura del database per gli impianti dell’olio romani
25
Il passo successivo è consistito nella normalizzazione delle voci da inserire, ovvero nell’attribuire loro una veste uniforme ed univoca, mediante la creazione di un glossario di lemmi omogenei ed universalmente applicabili. L’esigenza non era solo semantica, ma so‐ prattutto ‐ parlando in termini informatici ‐ formale; il rischio, infatti, era quello di una so‐ vrapposizione di sinonimi (ad esempio “struttura” e “costruzione”) o di una ridondanza terminologica (“Edificio” e “edificio” o “insediamento” e “insediamenti”). Si è dunque deci‐ so di creare delle liste da trasformare in campi a scelta obbligata, il che ha condotto alla progettazione dell’architettura della base di dati: si tratta di un database relazionale, ovve‐ ro a tabelle comunicanti, uno strumento di gestione dell’informazione molto potente ed in grado di registrare un gran numero di record occupando uno spazio minimo ed ottimiz‐ zando la quantità di dati immessi. L’assunto che sta alla base di tale architettura è l’integrità referenziale tra campi, cioè una grammatica di programmazione atta a garantire che le relazioni tra i record nelle tabelle correlate siano valide e mantengano tra loro vin‐ coli associativi; in tal modo si è potuta costruire una piattaforma dinamica e “parlante”, che si è deciso di impostare partendo da tre tabelle principali, destinate rispettivamente:
a raccogliere le informazioni relative al sito archeologico indagato, quali l’inquadramento cronologico e geografico, il contesto insediativo, la definizione degli impianti di produzione e dei cicli ad essi connessi; a definire le fasi di vita degli impianti; a catalogare gli indicatori archeologici di produzione, censendone le strutture fisse (mole, torchio, vasche, canalette, magazzini, dolia) e le altre evidenze(rifiuti e scar‐ ti di lavorazione). Accanto a queste si pongono una teoria di altre tabelle collegate tra loro attraverso speci‐ fiche chiavi comuni ed una serie di moduli per le ricerche tra i record (semplici e incrocia‐ te) e la reportazione. *** Un secondo ambito di sperimentazione per una base di dati evoluta ha preso spunto da un altro censimento condotto, stavolta, sotto la direzione della prof.ssa Renata Grifoni Cremonesi. Oggetto della ricerca, che verrà approfondita anche nel par. 2.4.4.2 per quanto riguarda il GIS, sono state le necropoli diffuse nella Penisola tra la Media Età del Bronzo e l’Età del Ferro.
Il lavoro di selezione dei contesti è stato accompagnato dalla creazione di un’applicazione ad hoc, in grado di raccogliere la grande mole di dati, normalizzandola se‐
26 condo criteri sostanzialmente inediti39. Il risultato è consistito in un software completo per la gestione, la ricerca e l’elaborazione dei dati, nel quale sono confluite informazioni circa la struttura funeraria e cultuale delle società preistoriche, la loro diffusione, le facies di ap‐ partenenza e le influenze reciproche . Figura 8 ‐ Il software Aspetti funerari in Italia tra Medio e Tardo Bronzo 39 Unico precedente in tal senso, il lavoro condotto dalla stessa prof.ssa Grifoni qualche anno fa e raccolto in una bella pubblicazione (MARTINI, F., 2006).
27
2.3 B
ONESTest.: 2008, presente Lingua: Italiano Release: 2.1 Siti di impiego: Benabbio (Lu), Badia Pozzeveri (Lu), Vecchiano (Pi), Scavi della Ohio State University, dr. Larsen (USA), Serie scheletriche dai la‐ voratori del dipartimento di Biologia, Università di Roma ‐ Tor‐ vergata, dott.ssa martinez. Bones è un software elaborato nel corso di alcuni anni e al momento in via di sperimen‐ tazione nei laboratori della Divisione di Paleopatologia a Pisa e a Calci (Pi) e presso il Di‐ partimento di Biologia dell’Università di Roma ‐ Torvergata, destinato alla raccolta e all’elaborazione dei dati antropologici e paleopatologici ricavabili dallo studio dei reperti umani in archeologia40. La nascita del software è stata voluta e incoraggiata dal prof. Fornaciari, che da sempre ha spinto nella direzione di un approccio multidisciplinare e tecnico alla complessa mate‐ ria della paleopatologia.
2.3.1 S
TRUTTURA LOGICA E SEZIONI DELL’
APPLICAZIONEL’intera struttura di Bones è stata sviluppata con Visual Basic 6 (formalmente abbreviato VB6), un linguaggio di programmazione creato dalla Microsoft, la cui sintassi deriva dal BASIC. Al giorno d'oggi sono disponibili numerosi linguaggi e tool per creare applicazioni, dal C a Java, a Delphi; di questo gruppo fa parte anche Visual Basic, che alcuni ritengono limitato e troppo semplicistico. Forse questa definizione si poteva applicare alle prime versioni del software: a partire dal release 4, ma soprattutto con le versioni 5 e 6, Visual Basic è diventato un linguaggio di programmazione di ottimo livello, che consente di rea‐ lizzare programmi praticamente di ogni tipo, dall'editor di testo al server web. Le caratte‐ ristiche che fanno di Visual Basic un linguaggio di programmazione estremamente versati‐ le e facile da usare sono due: le funzioni di progettazione dell'interfaccia completamente visuali; il linguaggio di tipo event‐driven; con questo termine si intende che l'elemento che sta alla base del linguaggio è l'evento, cioè, più in generale, l'azione: un evento è il clic
40 Per una visione completa del sistema si rimanda a: COSCHINO, F. et al. (2010) e COSCHINO, F. et al. (2009).
28 dell'utente su un pulsante, la digitazione in una casella di testo, la selezione di un comando di menu, ma anche il cambiamento della risoluzione, l'aggiunta di una periferica al sistema, ecc. . Il linguaggio di programmazione VB si basa su una serie di parametri codificati limi‐ tati nel numero ma capaci di gestire una quantità praticamente infinita di eventi, dalla cre‐ azione di un’interfaccia grafica navigabile, alla gestione di sistemi di controllo remoto e addirittura di applicazioni server industriali. L’intero programma consta sostanzialmente di sette parti: 1) la prima è costituita dalla schermata d’accesso, che contiene i collegamenti alle altre sei; 2) la seconda, racchiusa nella definizione “Distretti”, si incentra sulle analisi antropolo‐ giche effettuabili sullo scheletro (inventario delle ossa, caratteri metrici e disconti‐ nui); 3) la terza sezione è dedicata alle patologie riscontrabili sulle ossa; 4) la quarta sezione consente di calcolare e ricavare da metodi combinati il sesso e l’età alla morte di un individuo; 5) nella quinta sono raccolti i marcatori muscolo‐scheletrici e ligamentari, che coinvol‐ gendo di norma dei complessi funzionali non avrebbero trovato una giusta colloca‐ zione all’interno dei distretti; 6) la sesta consente di elaborare report e di sviluppare statistiche e grafici stampabili o esportabili; 7) la settima infine offre all’utenza la possibilità di effettuare ricerche mirate o compa‐ rate fra i record inseriti nel database. Bones è stato pensato come un software fruibile da un’utenza con conoscenze informati‐ che basilari, senza cioè capacità di programmazione o gestione avanzata del dato. La quasi totalità delle funzioni al suo interno è stata quindi impostata su un’impaginazione grafica
user‐friendly e “parlante”: ovvero fruibile senza manuale di istruzioni. Inoltre la maggior
parte delle applicazioni interne al programma sono raggiungibili dalla schermata principa‐ le, attraverso collegamenti dinamici e intuitivi. Da quella che potrebbe essere definita Homepage (Figura 9) o “Ponte di comando” si ac‐ cede al Treeview sinottico (Figura 10), che consente di aprire tutte le schede di compila‐ zione, di inserire ed eliminare Siti e Unità scheletriche, di allegare documenti e fotografie. Tutte le funzioni avanzate sono poste sulla barra degli strumenti, dalla quale si possono effettuare ricerche, stampare i report e le schermate ed esportare i dati.
29 Figura 9 ‐ Schermata di Apertura di Bones Figura 10 ‐ Collegamenti alle applicazioni raggiungibili dalla schermata principale di Bones La sezione principale di Bones è dedicata alla raccolta dei dati metrici e morfologici che è possibile ottenere dallo studio antropologico del sistema scheletrico di un individuo uma‐ no. La suddivisione logica che meglio ha risposto alle preposte esigenze di “normalizzazio‐ ne compilativa” cui ho accennato nella prefazione si è dimostrata avere come perno più ef‐ ficace la stessa, fisiologica, conformazione anatomica del corpo umano; seguendo i testi precipui della medicina anatomopatologica41 si è perciò creato un sistema di tabelle dina‐
41 Tra questi si può citare come esempio Anatomy of the Human Body di H. Gray, New York (1918), nella sua sezione riservata all’osteologia e liberamente consultabile a questo indirizzo:
30
miche relazionate tra loro secondo una chiave che ha alla base i nove distretti da cui è composto lo scheletro; essi sono così raggruppati: I DISTRETTO: Cranio Sottodistretti: Neurocranio, Splancnocranio, Mandibola, Denti II DISTRETTO: Colonna Vertebrale Sottodistretti: Rachide, Sacro III DISTRETTO: Gabbia Toracica Sottodistretti: Coste, Sterno IV DISTRETTO: Cinto Scapolare Sottodistretti: Scapola, Clavicola V DISTRETTO: Arti Superiori Sottodistretti: Braccio, Avambraccio VI DISTRETTO: Mani Sottodistretti: Carpo, Metacarpo, Falangi VII DISTRETTO: Cinto Pelvico Sottodistretti: Coxali VIII DISTRETTO: Arti Inferiori IX DISTRETTO: Piedi Sottodistretti: Tarso, Metatarso, Falangi
Questi distretti contengono al loro interno, suddivise logicamente in raggruppamenti conclusi in se stessi, le oltre duecento ossa che compongono l’organismo umano; queste vengono valorizzate dai dati inseriti dall’utente e si situano come baricentro informativo di tutto il database: ogni misurazione, patologia, carattere discontinuo, poggia informati‐ camente sull’identificativo numerico di un osso, che, a sua volta, afferisce ad una determi‐ nata Unità Scheletrica di un determinato Sito in un nesso circolare autoreferenziale del ti‐ po: http://books.google.it/books?id=CMoRAAAAYAAJ&pg=PA87&dq=Anatomy+of+the+Human+Body &ei=ZES6SdLmA5WyyQSf0JmwAw#PPR16‐IA8,M1.
31
Bones offre la possibilità di compilare le varie schede senza obbligatoriamente seguire un ordine lineare. Si è cioè ritenuto utile consentire all’utente di navigare liberamente tra le tabelle, seguendo la successione logica che meglio si adatti alla progressione delle sue analisi sulle ossa; ciascuna delle nove schermate presenta peraltro un aspetto grafico o‐ mogeneo ed è suddivisa in tabs registrabili indipendentemente. Queste ultime rispondono sostanzialmente a tre classi di definizione42:
I. Stato delle ossa (fig. 7/A), ovvero un inventario completo che include quattro possibilità di scel‐
ta: 1) osso presente e sano; 2) osso assente; 3) osso frammentario; 4) osso patologico.
II. Misurazioni e indici (fig. 7/B), in cui è possibile registrare le connotazioni antropometriche di ciascun osso.
III. Caratteri discontinui (fig. 7/C), ove inserire le variazioni morfologiche non quantificabili relative a ciascun individuo.
L’impresa più ardua nella stesura di un’applicazione vasta come Bones è consistita nel codificare la qualificazione e la quantificazione delle patologie riscontrabili sui resti umani in archeologia; a ciò si è poi accompagnata la necessità pratica di creare un supporto in‐ formatico che offrisse all’utente la possibilità di una compilazione diretta e intuitiva e fos‐ se parimenti in grado di mantenere intatta l’integrità delle informazioni inserite, evitando ripetizioni e ridondanze. A B C
Figura 11 (A, B, C) ‐ Screenshots delle principali schede riferite ai distretti in Bones
42 Alcuni distretti, come il cranio, hanno un maggior numero di campi compilabili e quindi una scheda con più tabs rispetto alle altre.
32 Si è così deciso di suddividere il sistema di affezioni ossee in nove raggruppamenti basati sulle classi patogenetiche tipiche della tassonomia anatomopatologica43, ognuno dei quali contenesse all’interno le malattie più statisticamente rinvenibili sui resti sepolti. Le classi sono le seguenti: I CLASSE. Anomalie Congenite ‐ sottoclassi: i) Nanismo, ii) Anencefalia, iii) Spina Bifida, iv) Spondilo‐ lisi, v) Lussazione Congenita dell’Anca, vi) Piede Torto, vii) Palatoschisi, viii) Idrocefalia, ix) Cranio‐ sinostosi, x) altro. II CLASSE. Patologie Degenerative Articolari ‐sottoclassi: i) Osteofitosi Vertebrale, ii) Osteoartrosi. III CLASSE. Patologie infiammatorie ‐ sottoclassi: i) Artrite reumatoide, ii) Spondilite Anchilosante, iii) DISH, iv) Gotta, vii) altro. IV CLASSE. Patologie infettive aspecifiche ‐ sottoclassi: i) Periostite, ii) Osteomielite. Patologie infet‐ tive specifiche ‐ sottoclassi: i) Sifilide, ii) Tubercolosi, iii) Lebbra.
V CLASSE. Patologie Neoplastiche ‐ sottoclassi i) Tumori Benigni (a. Osteocondroma, b. Osteoma, c.
Meningioma, d. altro), ii) Tumori Maligni (a. Osteosarcoma, b. Mieloma Multiplo, c. Carcinoma Me‐ tastatico, d. altro).
VI CLASSE. Patologie Metaboliche ‐ sottoclassi: i) Osteoporosi, ii) Avitaminosi D (a. Rachitismo, b. O‐ steomalacia), iii) Morbo di Paget, iv) Scorbuto, v) altro. VII CLASSE. Patologie Traumatiche ‐ i) Fratture, ii) Ferite. VIII CLASSE. Patologie Dentarie ‐ i) Carie, ii) Tartaro, iii) Uscura, iv) Patologie Periodontali e Ascessi, v) Malocclusioni, vi) Ipoplasia dello Smalto. IX CLASSE. Indicatori di Stress ‐ i) Anemie, ii) Disturbi della Crescita Infantile, iii) Patologie Vertebrali, iv) Altri Indicatori di Stress. Come si vede si è tentato di indirizzare la compilazione a scelte vincolate, evitando di la‐ sciare troppe tabelle aperte ad un’interpretazione libera. Parimenti per ciascuna scheda sono state predisposte caselle di compilazione che fossero il più possibile vincolate a ri‐ sposte fisse (caselle di spunta, menu a tendina, scelte multiple). Tutto ciò è stato possibile grazie all’utilizzo di un database relazionale centrale, capace di raccogliere in modo omo‐ geneo e diretto tutti i dati relativi ad un individuo in tabelle tra loro comunicanti e collega‐ te da chiavi specifiche (vd. par. 2.2.1). Ciascuna delle nove classi patologiche dà l’accesso ad un form elettronico (o scheda) per l’inserimento dei dati: ogni scheda ha caratteristiche diverse, ben specificate in appendice a questa tesi. Nella Figura 12 si riportano a titolo d’esempio le schede relative alle patolo‐ 43 Benché vi siano varianti anche notevoli (sia terminologiche che epistemologiche) tra i vari autori, si è qui fatto ricorso ad una bibliografia che unisse le esigenze catalogatrici mediche a quelle arche‐ o‐antropologiche; i testi‐base utilizzati sono stati i seguenti: BENEDETTI et al. (1991), WALDRON, T. (2009) BROTHWELLErrore. Il segnalibro non è definito., D.R. (1981); CANCI A., MINOZ‐ ZIErrore. Il segnalibro non è definito. S., (2005). Ricordo infine il preziosissimo lavoro di ricerca del prof. Fornaciari, come trova esposizione all’interno degli insegnamenti svolti per l’Università di Pisa.
33
gie traumatiche e dentarie; come si vede l’aspetto grafico è eterogeneo, tuttavia gli ele‐ menti caratterizzanti utilizzati dovrebbero risultare alquanto familiari ad un’utenza con medie conoscenze di informatica.
Figura 12 ‐ Due form per la compilazione delle patologie
2.3.2 D
ETERMINAZIONE DEL SESSO E DELL’
ETÀ INB
ONESUno dei momenti salienti nella redazione del software è stato l’elaborazione dei metodi di determinazione di due fattori estremamente variabili come il sesso e l’età alla morte.
Per quanto riguarda il sesso, la gran copia di studi effettuati in merito alle definizioni del riconoscimento e della quantificazione dei caratteri dimorfici scheletrici ha permesso l’elaborazione di un metodo compilativo sostanzialmente automatizzato, basato su quanto già era stato edito e sperimentato da tempo44. La sessualizzazione è basata sull’esame dei due distretti a più alto carattere dimorfico, cioè cranio e bacino, con la possibilità, per le successive versioni del software, di ampliare lo spettro anche a caratteri secondari. La se‐ lezione di ciascun tipo permette una computazione istantanea e statistica dei valori e‐
44 Si vedano le ricerche di BROTHWELL, D.R.Errore. Il segnalibro non è definito. (1981); ACSÀDI, NEMESKERI (1970); BUIKSTRAErrore. Il segnalibro non è definito. e UBELAKERErrore. Il se‐ gnalibro non è definito. (1994); FEREMBACH et al. (1977). Queste opere sono state utilizzate nel tempo per la normalizzazione di uno standard quantificativo unitario e riconosciuto dalla comunità scientifica.
34
spressi secondo gradazioni standard (Figura 13): ogni risultato numerico rimane in me‐ moria ed è esportabile in vari formati, così da prestarsi a future statistiche e comparazioni. Per quanto riguarda il calcolo dell’età di morte di un individuo l’orizzonte è sensibilmen‐ te più complesso: sono stati infatti effettuati numerosi studi, che hanno prodotto metodi alquanto diversi, spesso divergenti o addirittura tra loro contraddittori45. Oltretutto, se per gli individui immaturi è possibile effettuare diagnosi con minor grado di approssimazione, ben più difficile lo è per gli adulti. Si è preferito perciò lasciare maggior spazio all’esperienza del ricercatore e costruire una struttura “aperta”, ovvero un form contenen‐ te i diversi metodi, compilabili (tutti o una parte) manualmente, con o senza l’ausilio del computer (Figura 14): i risultati ottenuti possono essere approvati o corretti dall’utente, che ha facoltà di decidere quale metodo sia più efficace ed abbia maggior peso specifico in relazione al caso e di determinare il risultato finale. I procedimenti di diagnosi utilizzati sono i seguenti: Individui Immaturi: 1) lunghezza ossa lunghe, 2) saldatura delle epifisi, 3) eruzione dentaria. Individui adulti: 1) obliterazione delle suture craniche, 2) variazioni della superficie della sinfisi pu‐ bica, 3) margini delle estremità costali, 4) variazioni della superficie auricolare dell’ileo, 5) usura den‐ taria. Figura 13 ‐ Form di determinazione del sesso 45 Tra le numerose teorie statistiche e deduttive si citano a titolo di esempio gli studi portati avanti negli anni sulla dentizione e la dentatura da UBELAKER (1999) e da STERMER BEYER‐OLSEN E RI‐ SNES (1994), sulle suture craniche da BURNS (1999) e da LOVEJOY E MEINDL (1985) e, in una sin‐ tesi, da BROTHWELLErrore. Il segnalibro non è definito. (1981).
35 Figura 14 ‐ Form di determinazione dell'età di morte 1.
2.3.3 M
ARCATORI MUSCOLO‐
SCHELETRICILa macrocategoria dei marcatori muscolo‐scheletrici e ligamentari, che raggruppa al suo interno gli indicatori diagnostici specifici delle inserzioni muscolari e le entesopatie46, è stata inserita in Bones come scheda di compilazione a se stante. Questo per tre motivi:
1) perché si tratta dell’unico ambito trattato nel programma che investe tessuti non‐ ossei: muscoli, tendini, e legamenti sono infatti fibre organiche che, pur deperendo post
mortem sino a scomparire completamente, lasciano “impronte” visibili sullo scheletro lad‐
dove trovavano in vita un “ancoraggio” anatomico, o entesi;
2) perché le entesi investono spesso più di un osso, andando a formare dei complessi muscolari che designano, in vita, una serie coordinata di movimenti (p.es. il complesso muscolare della spalla, formato dalle entesi dei muscoli di omero, scapola e clavicola, con‐ sente all’organismo di effettuare tutti i movimenti di torsione, rotazione, sollevamento, ecc. della spalla); 3) infine perché i marcatori possono avere dei gradi di sviluppo sia morfologici che pato‐ logici: nel primo caso si parla di gradi di robustezza, nel secondo di entesopatie osteofitiche od osteolitiche47. 46 L’argomento è trattato approfonditamente da MARIOTTI, V. (2004).
36 Per queste tre ragioni si è preferito creare una scheda per così dire “trasversale” sia ai di‐ stretti, in modo da non dover per forza vincolare un carattere ad un singolo osso, sia alle patologie, data la duplice natura, morbosa e fisiologica, di tali marcatori. Come si vede in Figura 15 il form per la compilazione dei marcatori muscolo‐scheletrici consta di una scheda tabulare in cui sono riportati i vari marcatori indicizzati per tipologia, complesso muscolare e distretto interessato. Figura 15 ‐ Il form per la compilazione dei marcatori muscolo‐scheletrici 2.
2.3.4
I
MODULI DI RICERCA E LA REPORTISTICATra le principali potenzialità di un software che, come Bones, si integra in un sistema DBMS, vi è senz’altro la capacità di relazionare dinamicamente i dati e le informazioni in‐ serite nel database: infatti, se questi rispondono a parametri comuni e fra loro omogenei, è possibile effettuarvi sopra una quantità pressoché infinita di operazioni 48 , dall’ordinamento, alla ricerca, alla classificazione, alle computazioni aritmetiche ed alge‐ 47 Ibid.
48 Gli strumenti del linguaggio SQL hanno la caratteristica di offrire all’utente una gestibilità aperta, ponendosi quasi alla stregua di un linguaggio di programmazione.
37 briche. Il progetto che fa da base a Bones prevede la creazione (nell’immediato futuro) di alcune funzioni di gestione avanzata del dato fruibili dall’utenza: in particolare moduli di ricerca impostabili e dinamici su base API49, creazione automatica di Query relazionali, e‐ laborazione di grafici e statistiche. La volontà è quella di consentire un utilizzo inedito del‐ le informazioni, che consenta non soltanto di manipolare un unico individuo, ma anche di relazionarne diversi, ad esempio cercando una matrice comune che li leghi (la stessa loca‐ lizzazione geografica o storica, le stesse patologie, gli stessi caratteri antropometrici). Ciò porterebbe ad un traguardo ambizioso, ovvero il superamento dell’autoreferenzialità del dato ed il conseguente accesso all’area dell’ipermediale. Per la presentazione di questa tesi mi sono dovuto arrestare, per limiti di tempo, ad una versione del software liminare, caratterizzata da un numero di funzioni ancora ridotto. Le ricerche effettuabili sono, al momento, alquanto limitate anche a causa del ridottissimo numero di individui inseriti e quindi confrontabili. La maggior parte di esse ha carattere osservativo, basato sulla selezione dal treeview delle US da esaminare. Nel futuro prossi‐ mo l’intento è quello di elaborare delle schermate di indagine implementabili e dinamiche, che estendano la possibilità di ricerca al maggior numero possibile dei campi valorizzabili in sede di compilazione e siano soprattutto “trasversali”, includendo nella selezione indi‐ vidui appartenenti anche a siti diversi. *** Un report informativo è un documento generalmente costituito da visualizzazioni tabel‐ lari e grafiche esposte sinotticamente. Ha lo scopo di illustrare le informazioni inserite in una banca dati nella misura e nell’ordine decisi dall’utente. Come si può intuire l’aspetto vincente di una buona reportistica poggia sostanzialmente su tre caratteristiche:
1) la possibilità di sfruttare le capacità di ricerca, filtraggio e comparazione offerte dal DBMS; 2) la possibilità di personalizzare sia tali ricerche (a monte) che la loro visualizzazione fi‐ nale secondo canoni di volta in volta diversi; 3) la possibilità di esportare i dati ottenuti, sia su carta, che a video che, soprattutto, in al‐ tri software esterni. 49 Le Application Programming Interface API (Interfaccia di Programmazione di un'Applicazione), sono ogni insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per un determinato compito. È un metodo per ottenere un'astrazione, di solito tra l'hardware e il programmatore, o tra software a basso ed alto livello. Le API permettono di evitare ai programmatori di scrivere tutte le funzioni dal nulla. Le API stesse sono un'astrazione: il software che fornisce una certa API è detto implementazione dell'API.
38
Bones ha, gioco forza, una capacità di generare report complessi al momento alquanto limitata, dato che non ha potuto trovare ancora un banco di prova applicativo sul quale e‐ laborare le necessità operative dell’utenza. Col tempo, tuttavia, le incredibili potenzialità di elaborazione di un sistema dinamico come quello che sta dietro al software, troveranno attuazione e sviluppo in applicazioni viepiù complesse e performanti. Nella presente versione di release le schermate di reportazione si limitano a due: 1. la prima (Figura 16) sintetizza le informazioni generali di un individuo compilato; si tratta di un report a‐dinamico, generato cioè in automatico dal software attra‐ verso le informazioni già inserite dall’utente; l’importanza di questo form è legata al fatto che in esso sono conservati tutti gli agganci ipertestuali alla documentazio‐ ne allegata (elaborazioni GIS, documenti elettronici, fotografie, ecc.). 2. la seconda invece riporta in forma tabulare i record ottenuti da una ricerca, singola o comparata, tra gli elementi che popolano il database.
È proprio nella seconda direzione che Bones si svilupperà nel tempo, raccogliendo una serie di moduli di visualizzazione dinamici in grado di elaborare dati comparati, creare ta‐ belle esportabili ed ottenere statistiche e grafici. Per far ciò è tuttavia necessario applicare il programma a situazioni reali e raccogliere le necessità e le richieste dell’utenza. Figura 16 ‐ La scheda riepilogativa di Bones
39
2.4 GIS
DI SCAVONelle scienze territoriali e nelle applicazioni allo studio del territorio (pianificazione ur‐ banistica, valutazione delle risorse territoriali ed ambientali) va sempre più affermandosi l’uso del Geographical Information System (GIS), particolare categoria di software che con‐ sente l’acquisizione, l’analisi, la visualizzazione e la restituzione di dati georeferenziati in forma tabellare e/o di carte tematiche. In un lavoro di Giovanni Azzena viene affrontata la questione relativa alla terminologia dei GIS in archeologia50. Il GIS (o SIT51 in no) viene definito come un “produttore di informazioni, concernenti prevalentemente
l’assetto territoriale, basate sui dati qualitativi che siano contestualizzati rispetto allo stes‐ so”. La cartografia è quindi di per se stessa un sistema informativo. Tutte le informazioni che vengono memorizzate in un computer, nella cartografia tradizionale vengono invece disegnate su un supporto cartaceo secondo una serie di particolari simboli che nel loro in‐ sieme formano appunto un “sistema”. Nell’espressione SIT si possono, pertanto, far rien‐ trare altri “sistemi”: un lavoro di ricognizione archeologica, quando è fornito di schede de‐ scrittive dei siti, identificati con numeri o simboli, disegni, fotografie, mappe storiche della zona, ecc. è un esempio di un Sistema Informativo Territoriale. Rispetto ai supporti cartacei e tradizionali la rappresentazione informatica permette, in più, un approccio per così dire tridimensionale e trasversale: “dietro” la grafica si nascon‐ de un database e tutta una serie di informazioni indagabili su più piani. Secondo la defini‐ zione di Burrough “il GIS è composto da una serie di strumenti software per acquisire, me‐
morizzare, estrarre, trasformare e visualizzare dati spaziali dal mondo reale52”. Si tratta
dunque di un sistema informatico in grado di produrre, gestire e analizzare dati spaziali associando a ciascun elemento geografico una o più descrizioni alfanumeriche. Il GIS è differente dal DBMS (o Database Management System), in quanto si occupa es‐ senzialmente dell'elaborazione e manipolazione dei dati georeferenziati, che a loro volta possono essere memorizzati in un DBMS o in singoli file. L’anello di congiunzione e il gradino di superamento tra la rappresentazione convenzio‐ nale e il GIS è rappresentato pertanto dalla cartografia digitale. Un’espressione, questa, che indica il referente principale di un insieme di banche‐dati con un certo numero di compo‐ nenti (topografici, archivi amministrativi, dati geofisici, simulazione di impatto ambienta‐ le, ecc.) selezionabili in base alle esigenze dell’utenza finale. 50Cfr. AZZENA, G. (1997, pp.33‐35) 51 Il termine SIT (Sistema Informativo Territoriale) viene talvolta usato nelle pubblicazioni in lingua italiana come sinonimo di G.I.S. 52 BURROUGH, P.A. (1986, p.194)
