Codice diplomatico della Lombardia medievale
(secoli VIII - XII)

Procedure di lavoro: la codifica XML dei testi

di Michele Ansani

1. Certamente la prima questione da risolvere, la prima scelta da operare quando si decide di elaborare del materiale testuale in formato elettronico e destinato alla pubblicazione on line, il primo requisito di chiarezza necessario è quello relativo al formato dei dati, allo standard di codifica. Uso la nozione di codifica, in questo caso, in senso generale, senza riferimento a linguaggi specifici. Ci si deve porre – è banale osservarlo, ma ne vale sempre la pena – il problema della durata, della conservazione dei testi, consapevoli della rapida e potenziale obsolescenza del testo digitale.

Altro è il discorso relativo alla struttura dei dati. Sin dalle origini, il tema del trattamento elettronico dei testi è sviluppato, nelle applicazioni umanistiche, intorno a quello della codifica e dei modelli di codifica. Non ci si intrattiene a lungo su questioni che sono ad un tempo tecniche e teoriche, e si potrebbe rinviare in merito a una letteratura pressoché sterminata [1]. Certamente, per motivi diversi e non coincidenti, il ricorso agli applicativi e ai formati più diffusi, ma anche l’impiego dello strumento di marcatura più adoperato da chi pubblica materiale testuale in rete, il linguaggio noto con la sigla HTML (HyperText Markup Language), risultano del tutto incapaci sia di soddisfare le esigenze cui già si accennava (durata, conservazione, prospettive certe di riconversione del materiale senza perdita rilevante di informazioni), sia di abbinare all’opzione digitale un reale, concreto miglioramento dei risultati (e delle condizioni) della ricerca. Certamente, non si potrà ragionevolmente sostenere che un’edizione elettronica sia di per sé migliore di un’edizione a stampa: dovrà offrire qualcosa di più, qualcosa che l’edizione a stampa, un’edizione tradizionale non è in grado di offrire. E questo plus-valore non potrà certamente coincidere con una maggiore rapidità nelle procedure di pubblicazione, oppure di consultazione; semmai, e piuttosto, di una maggiore trasparenza nelle procedure critiche, di una maggiore consapevolezza e responsabilità dell’editore, della possibilità di contemperare molteplici livelli di accesso alla documentazione, calibrati tanto sulle esigenze della ricerca quanto sulle strutture testuali e documentarie – strutture che risultano storicamente definibili e definite [2].

*****

2. Il modello operativo messo a punto per l’allestimento del CDLM elabora precise risposte – che si spera risultino efficaci non solo nell’immediato – per questi problemi. Qui si proverà a illustrare, senza eccessivi tecnicismi, i parametri adottati e le scelte finalizzate al lavoro sui testi. Dev’essere chiaro: l’edizione digitale comporta un sovrappiù di fatica per l’editore; non semplifica il lavoro: lo complica. Anche perché resta inteso (deve restare inteso) che la ‘manipolazione’ digitale interviene solo nell’ultima fase, quella che precede la pubblicazione, l’immissione in rete dei documenti: ma invece di coincidere con un giro, un ultimo giro di bozze, costituirà un’operazione di livello scientifico aggiuntivo, destinata a rimettere parzialmente in discussione la lettura critica dei testi da parte del loro editore, e nel contempo a creare i presupposti per un corretto funzionamento degli strumenti di gestione e di ricerca automatica su di un corpus testuale in prospettiva omogeneo.

Si allude, naturalmente, al linguaggio e al modello di codifica che si è scelto di adottare. Facciamo due esempi, utilizzando lo stesso frammento testuale elaborato in base a due standard di codifica diversi. I più esperti riconosceranno immediatamente le formule d’avvio di un documento di refuta del XII secolo.

(SN) Anno dominice incar(nacionis) mill(esimo) cent(esimo) sexag(esimo) sexto, octavo die mensis madii, indictione .XIIII. Per lignum | quod sua manu tenebat Opizo Guercius, filius Guilengi Guercii, fecit fin[em et refutacion]em ad|versus donnum Pacignanum, rectorem et missum hospitalis de Betleem de Ultraticino, de illis decem modiis | de formento (a) et de sicala …

Quella che segue è una possibile e semplicissima marcatura di questo frammento testuale basata sul codice HTML.

<P style="color: black"> (SN) Anno dominice incar<SPAN style="color: red">nacionis</SPAN> mill<SPAN style="color: red" >esimo</SPAN> cent<SPAN style="color: red">esimo</SPAN> sexag<SPAN style="color: red">esimo</SPAN> sexto, octavo die mensis madii, indictione .XIIII. Per lignum | quod sua manu tenebat Opizo Guercius, filius Guilengi Guercii, fecit fin<SPAN style="color: blue">em et refutacion</SPAN>em ad|versus donnum Pacignanum, rectorem et missum hospitalis de Betleem de Ultraticino, de illis decem modiis | de formento et de sicala … </P>

Facilmente si potrà intuire come la marcatura (tutto ciò che è compreso fra parentesi angolari) definisca qui informazioni di carattere tipografico (sebbene, per esempio, si siano sostituite le parentesi quadre con l’inserimento di un colore diverso per il testo restituito); queste informazioni diventano in realtà istruzioni per il software, che produrrà un output del documento in cui quelle istruzioni risulteranno eseguite. Così:

(SN) Anno dominice incarnacionis millesimo centesimo sexagesimo sexto, octavo die mensis madii, indictione .XIIII. Per lignum | quod sua manu tenebat Opizo Guercius, filius Guilengi Guercii, fecit finem et refutacionem ad|versus donnum Pacignanum, rectorem et missum hospitalis de Betleem de Ultraticino, de illis decem modiis | de formento et de sicala …

HTML è un linguaggio di codifica cosiddetta ‘procedurale’. Ha un suo ‘vocabolario’ standardizzato e universale.

Ecco viceversa, qui di seguito, come si potrebbe risolvere la marcatura dello stesso testo adottando una sintassi ‘dichiarativa’, propria dei metalinguaggi di codifica noti con le sigle SGML (Standard Generalized Markup Language) e XML (Extensible Markup Language) [3]:

<PROTOCOLLO>(SN) <DATA-CRONICA>Anno dominice incarnacionis millesimo centesimo sexagesimo sexto, octavo die mensis madii, indictione .XIIII.</DATA-CRONICA></PROTOCOLLO> <TESTO> <DISPOSITIO> Per lignum <LB/> quod sua manu tenebat <AUCTOR> <PERSONA nm="Opizo Guercius">Opizo Guercius, filius <PERSONA nm="Guilengus Guercius">Guilengi Guercii<PERSONA></PERSONA> </AUCTOR>, fecit fin<RESTITUTIO>em et refutacion</RESTITUTIO>em adversus <RECIPIENS> <PERSONA>Iohannem de <TOP id="Besate, Mi">Besade</TOP></PERSONA> </RECIPIENS>, <RES>de illis decem modiis de formento (a) et de sicala … </RES> … </DISPOSITIO> … </TESTO>

Come si può vedere, sono qui esplicitate meta-informazioni (che ovviamente in fase di visualizzazione resteranno nascoste) sulla struttura del testo, sulle sue partizioni, sulle funzioni giuridiche documentarie, e si adotta un sistema di regolarizzazione dei nomi di persona e di luogo che risulterà vitale, importantissimo per la costruzione automatica di indici, liste di frequenza e così via. Con SGML/XML è standardizzata la sintassi; il ‘vocabolario’ dei marcatori sarà definito dalle esigenze scientifiche e dalla struttura dei testi.

Si dovrebbe agilmente cogliere la differenza. Nel primo caso la marcatura è del tutto indipendente dalla natura e dalla ‘forma’ dei testi; nell’altro caso è, in gran parte, esplicitamente dipesa dall’impiego di terminologia e categorie tipiche dell’analisi documentaria tradizionale.

Naturalmente si è scelto di adottare la seconda ‘filosofia’. Ma a questo punto occorreva decidere se adottare un ‘modello’ esistente [4], o se identificare un autonomo set di ‘elementi’ e di ‘attributi’ (così, tecnicamente, si definiscono i marcatori compresi fra parentesi angolari e fra virgolette) calibrato sulle caratteristiche specifiche della documentazione – caratteristiche morfologiche, strutturali, storiche, territoriali –, e tale comunque da non appesantire eccessivamente il lavoro di chi opera la codifica; tale cioè da renderlo sostenibile, e da essere poi comunque in grado di generare risultati significativi in fase di information retrieval.

Pur nel rispetto degli standard disponibili e riconosciuti (XML lo è), è parso utile rinunciare al modello TEI, e dar vita a un’autonoma e agile struttura di codifica dei dati testuali. Nella consapevolezza – ovvia – che il prodotto (il ‘modello’) andrà progressivamente perfezionato, sulla base di possibili ulteriori impieghi – non limitati dunque al Codice diplomatico lombardo –; mi è capitato in altre circostanze [5] di indicare nel Vocabulaire International de la Diplomatique lo strumento ideale per avviare una discussione e un confronto concreti all’interno della comunità dei diplomatisti, lo strumento da cui partire per fissare i requisiti di una Document Type Definition (DTD) [6] da impiegare nell’edizione elettronica di testi documentari; che, in sostanza, sia per la comunità degli studiosi ed editori di fonti d’archivio medievali ciò che TEI è per filologi e letterati [7].

*****

3. Vediamo dunque il modello di codifica adottato. Mi limito alle sezioni riguardanti la marcatura del testo, tralasciando quelle con funzioni di cornice tipografica o che semplicemente serviranno al motore di ricerca per operare selettivamente sul materiale della banca dati.

a. Strutture formali, partizioni e sotto-partizioni del documento

I marcatori definiscono lo svolgimento del discorso documentario, circoscrivendone anzitutto le articolazioni principali:

<PROTOCOLLO>
<TESTO>
<ESCATOCOLLO>

Ciascuna di queste sezioni può, anzi deve, includere delle ‘sotto-sezioni’

<PROTOCOLLO>
     <INVOCATIO>
     <INTITULATIO>
     <INSCRIPTIO>
     <DTCRON> (= data cronica)
     <DTTOP> (= data topica)

<TESTO>
     <EXORDIUM>
     <PROMULGATIO>
     <NARRATIO>
     <DISPOSITIO>
     <FORMULAE>
     <CLAUSULAE>
     <EXCEPTIONES>
     <SANCTIO>
     <CORROBORATIO>

<ESCATOCOLLO>
     <DTCRON> (= data cronica)
     <DTTOP> (= data topica)
     <RECOGNITIO>
     <SUBSCRIPTIO>
     <SMR> (= signa manuum rogantium)
     <SMC> (= signa manuum consentientum)
     <SME> (= signa manuum estimatorum)
     <SMT> (= signa manuum testium)
     <SMF> (= signa manuum fideiussorum)
     <ROGATIO>
     <IUSSIO>
     <IT> (= index testium)
     <COMPLETIO> o <DATATIO>

Questa griglia – che, come si vede, riflette una poco meno che manualistica e assolutamente tradizionale analisi formale del documento – supporta con sufficiente elasticità le strutture formali normalmente esibite da chartae, brevia, placiti, diplomi, privilegi, litterae. Le regole di inclusione (che prevedono gerarchie e sequenze, ma senza prescriverle all’interno di un modello rigidamente ordinato) formalizzate nella DTD consentono – rispecchiando così la prassi documentaria – numerose eccezioni; ai marcatori già individuati ne vanno aggiunti altri due, di pura utilità funzionale:

<TENOR-ADDITUM> (isola formule, clausole, pattuizioni aggiuntive che, soprattutto fra XI e XII secolo, tendono a rompere la falsariga immobile delle scritture notarili, inserendosi in varia posizione all’interno del documento).

<RES> (circoscrive elenchi e descrizioni di beni e diritti oggetto di scambi, transazioni, liti, a prescindere dalla loro ubicazione nel corpo del documento)

b. Funzioni personali giuridiche e documentarie

I marcatori identificano le funzioni ‘reali’ esercitate dalle persone nell’ambito dell’azione giuridica e della documentazione; non coincidono con le qualifiche denunciate. Per esempio, Ugo de Gambolato consul Papie non sarà ‘marcato’ come <consul> – attenzione all’iper-codifica! –, bensì – se nella circostanza agisce in qualità di giudice o di arbitro – come <iudex> o come <arbiter>. La codifica deve interferire il meno possibile con le informazioni già esplicitate nel testo documentario.

<SCRIPT> (scriptor, cioè redattore del documento)
<ROGSUBSCRIPT> (rogatario sottoscrittore)
<AUTHSCRIPT> (autenticatore scrittore)
<AUTHSUBSCRIPT> (autenticatore sottoscrittore)
<ROG> (semplice rogatario)
<AUCT> (auctor/auctores, autore/autori)
<RECIP> (recipiens/recipientes, destinatario/destinatari)
<ACT> (actor/actores, attore/attori)
<DEF> (defensor/defensores, convenuto/convenuti)
<ADV> (advocatus/advocati)
<ARB> (arbiter/arbitri)
<ESTIM> (estimator/estimatores)
<IUD> (iudex/iudices)
<TT> (testis/testes)
<CONS> (consentiens/consentientes ovvero confirmans/confirmantes)
<REN> (renuntians/renuntiantes)
<FID> (fideiussor/fideiussores)

c. Nomi di persona, di luogo e istituzioni ecclesiastiche

È l’ultimo ‘livello’ della codifica. Le informazioni così marcate verranno comunque ricomprese entro strutture di livello superiore, che definiscono le articolazioni formali ovvero le funzioni personali giuridiche e documentarie.

<PERSONA>
<TOP> (toponimo)
<ECCL> (chiesa o monastero)

Ciascuno di questi elementi è supportato da una serie di attributi, i cui valori solo in parte dipenderanno dalle informazioni di cui il documento dispone.

c1. Nomi di persona

<PERSONA>

Attributi di normalizzazione e identificazione del nome:

• nm (nome normalizzato)
• id (identificazione, quando possibile, e quando l’informazione risulta incompleta se confrontata con altre disponibili)

Attributi di parentela:

• fil (filius)
• pat (pater)
• mat (mater)
• sor (soror)
• fr (frater)
• germ (germanus),
• vir (marito)
• ux (uxor)
• par (parente: rimanda a tutte le altre relazioni di parentela);

e inoltre:

• lex (professione di legge, quando disponibile)

Un esempio renderà più efficace questo passaggio:

… constat nos Petrum qui dicor Lorencii, de loco Fara Basilliano, et Richam, iugalis, qui professi sumus lege vivere Longobardorum …

… constat nos <AUCT><PERSONA nm="Petrus qui dicitur Lorencii de loco Fara Basilliano" id="Petrus Laurentius" ux="Richa" lex="langobarda">Petrum qui dicor Lorencii, de loco Fara Basilliano</PERSONA>, et <PERSONA nm="Richa" vir="Petrus qui dicitur Lorencii, Laurentius" germ="Iohannes" par="Iohannes de Lucia" lex="langobarda">Richam, iugalis</PERSONA></AUCT>, qui professi sumus lege vivere Longobardorum …

c2. Nomi di luogo

<TOP>

Attributi di normalizzazione e identificazione del nome:

• nm (nome normalizzato)
• id (identificazione del toponimo)

Completiamo l’esempio precedente:

… constat nos <AUCT><PERSONA nm="Petrus qui dicitur Lorencii de loco Fara Basilliano" id="Petrus Laurentius" ux="Richa" lex="langobarda">Petrum qui dicor Lorencii, de loco <TOP nm="Fara Basilliano" id="Cascina Basiano, Morimondo, Mi">Fara Basilliano</TOP></PERSONA>, et <PERSONA nm="Richa" vir="Petrus qui dicitur Lorencii, Laurentius" germ="Iohannes" par="Iohannes de Lucia" lex="langobarda">Richam, iugalis</PERSONA></AUCT>, qui professi sumus lege vivere Longobardorum …

c3. Istituzioni ecclesiastiche

<ECCL>

Attributi di identificazione:

• id (denominazione e tipologia dell'istituzione)
• top (luogo sede dell'istituzione)

Esempio:

… <ECCL id="S. Pietro in Ciel d’Oro, monastero" top="Pavia">Monasterio Sancti Petri Celi Aurei</ECCL> ego Iohannes …

d. Interventi editoriali

Del tutto indipendenti dalla struttura documentaria sono i marcatori che definiscono gli interventi dell’editore (la segnalazione dei compendi, delle restituzioni, della presenza di litterae elongatae, di testo dipendente da testi precedenti – ‘vorurkunden’ –, l’inserimento di note critiche al testo, la segnalazione dei cambi di riga):

<ABBR> (isola le parti compendiate; sostituisce, in sostanza, le parentesi tonde)

<REST> (circoscrive le parti di testo lacunose per caduta o per compromissione del supporto, e restituite dall’editore; sostituisce, in sostanza, le parentesi quadre)

<LB/> (= line-break: è un marcatore TEI)

<ELONG> (circoscrive le parti in litterae elongatae)

<ORIGO> (circoscrive le parti dipendenti, nei diplomi regi e imperiali o nei documenti della cancelleria pontificia, da testi precedenti)

*****

4. Abbiamo dunque precisato tre livelli di marcatura che – comprese le possibili inclusioni di elementi entro altri elementi dello stesso livello (per esempio, come si è visto, l’elemento <TOP> si annida di frequente nell’elemento <PERSONA>) – sembrano poter descrivere ordinatamente la struttura testuale:

<EDITIO>
     <PROTOCOLLO> 
          <DTCRON> data cronica </DTCRON>
     </PROTOCOLLO>
     <TESTO> 
          <DISPOSITIO> <AUCT> <PERSONA informazioni indicizzate> nome
          </PERSONA> </AUCT> azione <RECIP> <PERSONA informazioni
          indicizzate> nome </PERSONA> </RECIP> <RES> beni siti
          in <TOP informazioni indicizzate> luogo </TOP> </RES>
          <FORMULAE> formulario </FORMULAE> <CLAUSULAE> formulario
          </CLAUSULAE> </DISPOSITIO> 
     </TESTO>
     <ESCATOCOLLO>
          <DTTOP> <TOP> data topica </TOP> </DTTOP> <SUBSCRIPTIO>
          <PERSONA informazioni indicizzate> sottoscrizioni autografe
          </PERSONA> </SUBSCRIPTIO> <IT> <PERSONA informazioni
          indicizzate> elenco dei testi </PERSONA> </IT>
          <COMPLETIO> <SCRIPT> <PERSONA informazioni indicizzate>
          nome del notaio </PERSONA> </SCRIPT> </COMPLETIO> 
     </ESCATOCOLLO>
</EDITIO>

Per un’applicazione concreta del ‘modello’ si veda un esempio di documento con marcatura XML ‘in chiaro’.

*****

5. La ‘manipolazione’ digitale qui parzialmente descritta, e che supporta in ultima istanza le procedure critiche finalizzate all’edizione dei testi – in questo senso, la codifica da un lato obbliga all’analisi del documento, e dall’altro costringe a operare scelte talvolta omesse in applicazioni ‘routinarie’ [8] – produce ritorni del tutto significativi in termini di ricerca automatica delle informazioni all’interno di un corpus testuale destinato a comporsi di svariate migliaia di documenti. L’interrogazione del quale non risulterà indistinta, ma filtrata dagli ambiti (testuali e non solo) d’interesse: la ricerca del lemma curtis, per esempio, potrà essere ristretta a un arco cronologico predeterminato, a un’area territoriale predefinita, ed essere ‘pescata’ dal motore all’interno dei testi soltanto quando risulti elemento toponimico preciso ovvero elemento generico nelle formule di pertinenza.

Un’ultima precisazione, in chiusura di questa sintetica e semplificata descrizione. I documenti pubblicati nel CDLM si presentano, in prima istanza, informa di file HTML. Ma quello che si vede è il prodotto di una trasformazione, di una conversione da un formato all’altro, operata da un programma installato sul server – la macchina su cui risiedono i documenti –. Tale programma, detto in termine tecnico processore, esegue una serie di istruzioni da noi dichiarate in un foglio di stile (istruzioni che potremmo modificare in qualsiasi momento) e opera la conversione, in modo da rendere il testo non solo leggibile in quanto tale in tutti i browser odierni, ma anche secondo determinate e specifiche caratteristiche di impaginazione e di organizzazione delle parti di cui è composto. Il documento – o per meglio dire il file – ‘originale’, quello su cui abbiamo attivato il processo, è un altro. È un documento di solo testo, leggibile da ogni computer, portabile da ogni sistema, e soprattutto redatto in conformità a una sintassi di codifica che rispetta uno standard internazionale: la versione 1.0 del metalinguaggio XML. Dunque, un documento a ‘lunga conservazione’.