I documenti e gli event - IL FUNZIONAMENTO DEL PROGRAMMA

9. IL FUNZIONAMENTO DEL PROGRAMMA

9.2. I documenti e gli event

La codifica dei documenti

Poiché i documenti sono le uniche fonti del codice, essi rappresentano la variabile cardine su cui ruotano tutte le altre. Per questo motivo è essenziale gestire le loro informazioni nella maniera più efficiente possibile.

Finora, il metodo utilizzato dall’equipe che lavora sul progetto digitale prevede un file codificato per ogni singolo documento, mentre i rimandi a questi sono inseriti nel file di codifica principale Codice Pelavicino.xml. Questo sistema se da un lato garantisce un legame tra codice principale e i documenti, dall’altro mi ha presentato numerosi ostacoli nell’attribuire ad un singolo vescovo i relativi documenti con i luoghi e le date in cui sono stati rogati.

Per superare queste difficoltà è stata creata una struttura di codifica che ribalta quella attuale. Questa soluzione è tuttavia sperimentale e momentanea poiché sposta il punto focale dal documento al vescovo, rivoluzionando quindi l’intero lavoro svolto finora dai miei colleghi.

Ciò che ho fatto è stato inserire una lista di eventi all’interno di ogni singolo vescovo codificato in Vescovi_lista.xml, attribuendo ad ogni evento alcuni dei dati ricavati dai singoli documenti nel cui testo è possibile intuire che ne fu l’autore ed un riferimento all’url del documento codificato.

Ad esempio il documento CCXXVII 18822_{redatto a Collecchia in data 1 maggio 1189}

ci dice:

22_{Codice Pelavicino. Edizione digitale, a cura di E. Salvatori, E. Riccardini, L. Balletto, R. Rosselli del Turco,} C. Alzetta, C. Di Pietro, C. Mannari, R. Masotti, A. Miaschi, 2014, n° CCXXVII_188, <http:// pelavicino.labcd.unipi.it/evt/#doc=CCXXVII_188&page=fol_253r> [consultato in 2019/04/11]; ISBN 978- 88- 902289-0-2; DOI 10.13131/978-88-902289-0-2

<head>CCXXVII 188</head>

I consorti Blasio del fu Viviano di Soliera, Gerardo Verono del fu Gerardino Verono di Soliera e Albertino, figlio dello stesso Gerardino, vendono a Pietro, vescovo di Luni, e ad Arduino di Erberia, figlio del fu Giberto, e a suo figlio Gibertino tutte le terre da loro possedute in Castrum Novum de Barzi, nel luogo detto Colicclum. Il prezzo della vendita è di 8 lire di imperiali.

</event>

“I consorti Blasio del fu Viviano di Soliera, Gerardo Verono del fu Gerardino Verono di Soliera e Albertino, figlio dello stesso Gerardino, vendono a Pietro, vescovo di Luni, e ad Arduino di Erberia, figlio del fu Giberto, e a suo figlio Gibertino tutte le terre da loro possedute in Castrum Novum de Barzi, nel luogo detto Colicclum. Il prezzo della vendita è di 8 lire di imperiali.”

Da questo testo ho dedotto che il vescovo Pietro si trovasse in quella sede durante la stesura, così ho inserito nella lista di eventi relativi al vescovo Pietro l’evento:

In questo modo è possibile per il programma indicare che Pietro si trovasse a Collecchia l’1 di maggio del 1189 a stilare il documento CCXXVII 188.

Voglio tuttavia ribadire che questa soluzione non può considerarsi come quella definitiva, poiché non solo aggiungerebbe una mole di lavoro eccessiva nella codifica digitale, generando dati ridondanti già presenti nei file dei documenti (data, luogo, note etc.), ma sarebbe anche inesatta dal punto di vista storiografico; infatti nulla in questi dati ci conferma che Pietro fosse l’artefice del documento, né tanto meno che egli fosse effettivamente presente a Collecchia in quel preciso giorno.

codifica dei documenti un riferimento al vescovo o al vicario che li ha redatti, assegnando poi i metadati del file alla persona.

La soluzione adottata ha però delle motivazioni plausibili, in quanto nella richiesta iniziale della mappatura veniva evidenziata la necessità di visualizzare il percorso di un vescovo in base ai documenti, ma non quella di segnalare i luoghi in cui questi documenti sono stati redatti.

Avere inoltre una lista unica nella quale inserire o eliminare gli eventi offre al sistema ed ai miei colleghi una maggiore semplicità di gestione dei dati rispetto a quella che comporta l’obbligo di operare per la consultazione o la modifica su 200 file. Pertanto, fino a quando i responsabili che lavorano a questo progetto non avranno deciso che indirizzo seguire, il programma opererà su questo sistema di codifica.

L’inserimento degli eventi

Per recuperare i dati da inserire nella lista degli eventi mi sono basato sull’indice cronologico consultabile nel sito web del “Codice Pelavicino digitale” e presente in appendice sotto ogni documento. Grazie a questo indice sono riuscito a ricavare i dati necessari per la creazione degli eventi, ossia la data, il luogo, il vescovo di riferimento, il nome e la descrizione del documento e l’url dello stesso. Questi dati sono poi stati, per comodità, inseriti in una tabella ideata con la struttura sotto riportata:

documento data luogo vescovo url note

CXLVIIII 167 1224-07-14 Sarzanello Buttafava http... [...]

CCCCXXX 391 1224-09-21 Sarzanello Buttafava http... [...]

CCCLXXXXIII

354 1226-01-31 Sarzana Buttafava http... [...]

e successivamente codificati nel file Vescovi_lista come spiegato precedentemente:

<person xml:id=”ButtafavaEpLuni”> <persName>Buttavafa</persName>

<note>Buttafava, vescovo di Luni. Forse già canonico lunense - dato che troviamo un Buttafava in quel ruolo il <ref

target=”#LXXXVIII_105” type=”doc”>31 marzo del 1206</ ref> - è attestato la prima volta il <ref target=”#CXLVIIII_167” type=”doc”>14 luglio 1224</ref> e l’ultima il <ref

target=”#CCCLXXXXIII_354” type=”doc”>31 gennaio 1226</ref>. </note>

<event when=”1224-07-14” where=”Sarzanello” ref=”http://pelavicino.labcd.unipi.it/

evt/#doc=CXLVIIII_167&page=fol_242v “> <head>CXLVIIII 167</head>

Buttafava, vescovo di Luni, loca per homagium et resedium a Gerardino e a Bellandino, figli del fu Cicere di Magnano, che ricevono ...

</event>

Va tuttavia considerato che in questo modo si crea una corrispondenza biunivoca tra evento e documento, non considerando così la possibilità che un evento possa essere descritto in più documenti o, viceversa, che in uno stesso evento siano stati rogati più documenti. L’ibrido così creato lascia tuttavia aperte le diverse possibilità di ricodifica per il percorso del vescovo.

Le funzioni relative ai documenti

Grazie a questo tipo di interpretazione è stato possibile creare una funzione

ref=”http://pelavicino.labcd.unipi.it/

evt/#doc=CCCCXXX_391&page=fol_338r”> <head>CCCCXXX 391</head>

Buttafava, vescovo di Luni, approva quanto il vescovo Gualtiero, suo predecessore, stipulò il 29 marzo 1208 con gli uomini di Pontilliolo...

</event>

<event when=”1226-01-31” where=”Sarzana” ref=”http://pelavicino.labcd.unipi.it/

evt/#doc=CCCLXXXXIII_354&page=fol_320v “> <head>CCCLXXXXIII 354</head>

Buttafava, vescovo di Luni, investe a titolo di feudo Faime del fu Sinibaldo di Prato e sua moglie Matilde, figlia del fu Pagano di

Balognano... </event>

</listEvent> </person>

creaDocumenti() che permettesse per ogni evento di associare un singolo documento, creando così una classe contenente i diversi dati. Gli elementi di questa classe sono poi stati inseriti in una lista ordinata cronologicamente al fine di ottenere una più semplice visualizzazione dei dati.

$.ajax({ type: “GET”,

url: “Vescovi_lista.xml”, dataType: “xml”,

success: function (data) {

$(data).find(“listPerson person”).each(function () { vescovo_nome = $(this).find(“persName”).text(); var event = $(this).find(“ListEvent event”);

$(event).each(function () {

documento_name = $(this).find(“head”).text();

documento_when = $(this).attr(‘when’); documento_where = $(this).attr(‘where’); documento_note = $(this).find(“p”).text(); documento_ref = $(this).attr(‘ref’);

documento = {

Documento_nome: documento_name, Documento_luogo: documento_where,

Documento_data: documento_when, Documento_link: documento_ref, Documento_vescovo: vescovo_nome, Documento_note: documento_note

Questa lista è stata per esempio utilizzata per la ricerca di documenti prodotti in una determinata sede. Nella funzione cercaLuogo() si cerca una corrispondenza tra l’input

ricevuto e l’attributo del documento relativo al luogo, per ogni corrispondenza viene generato un indicatore e inseriti i relativi dati nella lista documenti. Analogamente si potrebbe creare una funzione cercaDocumento() dove si indica in quale luogo e da quale vescovo è stato prodotto.

documento_lista.push(documento);

documento_lista.sort((a, b) => (a.Documento_data > b.Documento_ data) ? 1 : ((b.Documento_data > a.Documento_data) ? -1 : 0));

}); });

9.3. I luoghi

La scelta dello stile della mappa

Lo stile scelto per la visualizzazione della mappa si basa su colori e contrasti tipici della cartografia ottocentesca, con sfumature di marrone e giallo che tendono a rievocare l’effetto di una cartina antica. Oltre a questa impostazione visiva, per illustrare nel modo più fedele possibile solamente quei paesi della Lunigiana menzionati nel Codice, sono state eliminate le indicazioni moderne come le città, le strade e i molteplici punti d’interesse. I limiti dello zoom e il tipo di mappa che mostra i rilievi montuosi servono a inquadrare meglio la regione e le sue caratteristiche geomorfologiche.

La nomenclatura del luogo

La differenza della toponomastica tra le città medievali e quelle moderne crea generalmente delle discrepanze nell’attribuzione del nome da utilizzare nella visualizzazione nella mappa. All’interno della codifica si possono riscontrare entrambe le varianti, identificate in diversi marcatori. Il nome (o i nomi) della città nella formula originale del codice sono stati inseriti come testo all’interno del marcatore

<settlement> nomeMedievale </settlement>, mentre gli equivalenti moderni si ritrovano in <placeName type=”new”> nomeModerno </placeName>. Per semplicità è stato deciso di scegliere l’unico nome moderno della città da assegnare al titolo del marker.

La geolocalizzazione del luogo

Per posizionare un indicatore sono richieste le coordinate specifiche dove lo stesso deve apparire nella mappa. È stato perciò necessario inserire le latitudini e le longitudini

di tutti i siti che si volevano evidenziare nella cartina. In questi luoghi è stata quindi inserita la marcatura <location><geo>lat lng</geo></location> con all’interno le coordinate ricavate manualmente da Google Maps23_{In questo modo il programma}

estrapola solo quei siti che contengono la marcatura, operando una prima cernita tra località, e crea una nuova variabile latlng da inserire come valore della position.

var latLng = new google.maps.LatLng(lat, lng);

Esisterebbe anche un altro metodo di geolocalizzazione che, per i motivi sotto specificati, si è però rivelato non essere adeguato ai risultati che il progetto si prefigge di ottenere. L’ipotesi era quella, per evitare l’inserimento manuale della latitudine e della longitudine, di sfruttare il servizio GeocodingService di Google, che converte automaticamente un indirizzo (address) nelle coordinate geografiche necessarie a posizionare gli indicatori sulla mappa.

I motivi principali per cui questo metodo è stato scartato sono stati:

 la difficoltà di Google di posizionare precisamente sulla mappa alcuni dei luoghi citati nel Codice: ad esempio la città di Luni, IT viene identificata come Ortonovo, mentre il luogo medievale dovrebbe essere ubicato nell’attuale zona di Luni Mare;

 la sovrabbondanza di dati che inserivano città di scarso interesse per il progetto, come Münster o Strasburgo in Germania, in cui difficilmente il Vescovo avrebbe rogato un documento;

 i costi del servizio per ogni richiesta. La tipologia di luogo

Un ulteriore passo è rappresentato dalla necessità di dover differenziare la tipologia della

23_{Nel caso di città con un’estensione relativamente grande come Carrara o Massa, ho preso come punto di} riferimento le chiese principali che in qualche modo forniscono un filo conduttore tra presente e passato.

località. Nella codifica del codice infatti ogni luogo ha un attributo che ne indica le caratteristiche, sia esso un borgo, un castello, una corte o altro. La difficoltà in questo frangente era dover attribuire uno specifico type a dei luoghi che inevitabilmente nel corso dei secoli ebbero evoluzioni nello status giuridico. La città di Sarzana, ad esempio, intorno al XI-XII secolo veniva descritta come borgo ma, ai primissimi anni del XIII secolo, il pontefice Innocenzo III ratificò la traslazione della sede vescovile da Luni a Sarzana con le bolle del 7 marzo 1203 e del 25 marzo 120424_{, rendendo così la città una curtis.}

In questi casi ambigui si è privilegiato attribuire al luogo lo status giuridico più importante; in questo modo quei paesi che hanno ospitato una sede vescovile o che possedevano un castello sono stati marcati come tali.

Sono poi state create e associate alla tipologia delle icone con colori diversi per rendere più intuitiva la lettura della mappa.

L’unica immagine che ha creato alcuni problemi è stata quella della curtis, che all’inizio voleva essere rappresentata dalla stilizzazione della pianta della biblioteca descritta ne “Il nome della Rosa” di Umberto Eco.

Tuttavia, poiché l’effetto grafico non ha dato i risultati sperati, si è optato per un semplice, ma più efficace rombo.

burgus castrum ecclesia locus

curtis

24_{Cfr. PR. Jaffe- A. Potthast, Regesta, cit., n. 1853 e 2161}

Le pievi

L’ultima fase di rappresentazione geografica è scollegata dalla codifica dei place del Codice, ma riprende una cartina raffigurante le pievi della diocesi di Luni nel medioevo25_.

Partendo da questa immagine iniziale, ho provveduto ad inserire dal punto di vista cartografico le diverse regioni su Google Earth, riportando sulla mappa i confini delle singole pievi; in questo modo si è potuto ottenere le coordinate delle regioni e i metadati ad esse collegati.

I poligoni ottenuti sono stati prima salvati in KML e successivamente convertiti nel formato GeoJSON. Grazie a questo formato si possono inserire direttamente sulla

25_{Baluze, Etienne, dir. Epistolarum Innocentii III romani pontificis libri undecim: *Accedunt gesta ejusdem Innocentii} & prima collectio decretalium composita a Rainerio diacono & monacho pomposiano. Paris, Franciscum Muguet, 1682.

mappa i dati descritti nel file, con il comando:

map.data.loadGeoJson(‘Pievi.geojson’);

e utilizzare le proprietà degli oggetti per la visualizzazione dei dati. Nel mio caso ho associato il nome della pieve ad un elenco di immagini ricavate dalle tabelle presenti in un file PDF, in questo modo se si clicca sulla regione apparirà la rispettiva immagine. Le funzioni per i luoghi

Le prime prove sperimentate consistevano nell’inserimento del luogo volta per volta, in quanto nella definizione della variabile dell’indicatore avevo imposto la proprietà map (ossia quella proprietà che indica su quale mappa visualizzare il marker) all’interno della variabile stessa.

Tuttavia, utilizzando questa metodologia, risultava molto più difficile e macchinosa la gestione delle classi: ad esempio, se si avesse voluto nascondere un luogo particolare o una tipologia di posti, si avrebbe avuto bisogno di fornire indicazioni precise che rallentavano l’elaborazione e creavano confusione nel testo di programmazione. Per evitare ciò ho quindi creato un’altra funzione chiamata setMapOnAll() che sfruttasse un parametro array e il metodo .setMap per inserire automaticamente nella mappa tutti gli elementi all’interno del vettore. In maniera analoga è stata creata anche la funzione opposta deleteMarkers() che permette di eliminare gli indicatori presenti nell’array impostato come parametro. Grazie a queste due funzioni è più semplice coordinare la gestione di indicatori multipli.

Il passaggio successivo così come è avvenuto nell’inserimento dei vescovi è stato suddividere in più funzioni le diverse azioni richieste.

 La funzione creaLuoghi() ricava direttamente dalla codifica del Codice Pelavicino le informazioni necessarie alla variabile, ossia il nome, la posizione e la tipologia del luogo, inoltre imposta la infowindow per mostrare il nome del luogo al verificarsi

del’evento click. I diversi elementi così creati sono poi inseriti in un array

luogo_lista che viene utilizzato come parametro per la funzione setMapOnAll().

 La funzione creaPievi() carica i dati presenti nel file “Pievi.geojson” e li trasforma in poligoni nella mappa. La infowindow invece è collegata ad una cartella immagini che a seconda del nome della pieve mostra la figura corrispondente.

//per ogni luogo trovato nella codifica var luogo = new google.maps.Marker({

position: latLng, title: luogo_nome,

icon: icons[luogo_tipo].icon, });

luogo_lista.push(luogo);

 Le funzioni showHidePievi() e showHideLuoghi() servono invece per scegliere se nascondere o mostrare i vari elementi della mappa. Esse sono collegate ai pulsanti presenti nella lista a cascata “mostra/nascondi luoghi” e alle rispettive immagini, cosicché gli indicatori che hanno un certo tipo di icona vengono gestiti a seconda dell’evento.

 La funzione cercaLuogo() è un’implementazione alla ricerca dei documenti in funzione, non al vescovo che li ha prodotti, ma al luogo in cui sono stati rogati. Serve per trovare tutti i documenti prodotti in una determinata sede. In base alla stringa ricevuta crea una corrispondenza tra l’input ricevuto e la proprietà del documento Documento_luogo. Per ogni documento che ha come valore quel luogo aggiunge un pulsante nella lista nodi contenente il nome del documento collegato alla rispettiva pagina web, la data e il vescovo che lo ha prodotto. Inoltre segna sulla mappa l’indicatore sul luogo trovato, con il numero totale di documenti prodotti in sede.

Nel documento I movimenti del Vescovo di Luni e la georeferenziazione dei luoghi del Codice Pelavicino (pagine 50-64)