Codifica

Introduzione
<teiHeader>
Liste
<text>
Documenti
Bibliografia


Introduzione

Per l’edizione digitale del Codice Pelavicino si è scelto di far riferimento a una codifica XML secondo lo standard TEI, utilizzando i moduli e gli elementi predisposti dalle Guidelines.

La TEI (Text Encoding Initiative) è un consorzio che ha sviluppato, in ambito linguistico e letterario, uno standard per la rappresentazione dei testi in formato digitale. La missione della TEI è quella di sviluppare una serie di linee guida per la codifica dei testi e per sostenere e condividere il loro uso da parte di diverse categorie, più o meno ampie, di utenti. Attraverso un testo di riferimento, le Guidelines for Electronic Text Encoding and Intherchange, il consorzio definisce un linguaggio di markup (in XML) che comprende un numero elevato di elementi, di tipo strutturale e semantico, definiti per mezzo di un certo numero di schemi di codifica, organizzati in una struttura modulabile e personalizzabile. Grazie a queste caratteristiche, ogni studioso ha la possibilità di sviluppare il proprio progetto partendo da una serie di linee guida, scegliendo i moduli necessari e modificando, in qualsiasi momento, le definizioni degli elementi. L’attuale versione delle linee guida (TEI P5) è stata pubblicata alla fine del 2007 ed è basata su XML e su schemi di codifica Relax NG e DTD tradizionale. Tra le numerose e importanti novità è stato inserito un modulo per la descrizione dei manoscritti, che è stato ampiamente sfruttato per la codifica del Codice Pelavicino

Data la ricchezza e la varietà del manoscritto, per la prima fase della codifica si è stabilito di partire da una selezione di 145 documenti tratti dal Liber Iurium. In seguito alla messa online del progetto, si potrà passare ad una seconda fase di codifica.

I documenti del manoscritto sono stati codificati all’interno di 145 file XML differenti, collegati ad un unico file “master” suddiviso, come da standard, in due macro elementi: <teiHeader> e <text>. Solo in un secondo momento è stato aggiunto, allo stesso livello gerarchico, l’elemento <facsimile>, necessario per la realizzazione dei collegamenti fra contenuti specifici del testo e immagine.

Il <teiHeader> corrisponde all’intestazione dell’intero manoscritto, all’interno della quale sono stati inseriti tutti i metadati relativi alla provenienza, alla pubblicazione e alla descrizione sintetica del volume. Il <text> è il corpo del file XML e contiene i testi, così come sono stati predisposti nei documenti Word, e la bibliografia di riferimento. L’unico elemento a non contenere testo è il <facsimile>. Al suo interno, infatti, si trovano solo ed esclusivamente le pagine del Codice e i riferimenti ai numerosi signa tabellionis.

La struttura del file XML si presenta dunque così:
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE TEI SYSTEM “schema/tei_cp.dtd”>
<TEI xmlns=”http://www.tei-c.org/ns/1.0″>
<teiHeader>

</teiHeader>
<facsimile>

</facsimile>
<text>

</text>
</TEI>

<teiHeader>

Il <teiHeader> racchiude una serie di informazioni rappresentative del manoscritto che devono essere collocate allo stesso livello gerarchico di <text>, ossia del contenuto dei testi. Tutti i metadati necessari per fornire una descrizione accurata del volume sono raggruppati all’interno di un altro elemento, il <fileDesc> che contiene una descrizione bibliografica completa di un file elettronico.
I tre elementi principali contenuti nel <fileDesc> sono il <titleStmt>, il <publicationStmt> e il <sourceDesc>, e sono così rappresentati nel documento:

<teiHeader>
<fileDesc>
<titleStmt>

</titleStmt>
<publicationStmt>

</publicationStmt>
<sourceDesc>

</sourceDesc>
</fileDesc>
</teiHeader>

Il <titleStmt> racchiude, tramite gli elementi <title> e <respStmt>, tutte le informazioni relative al titolo dell’opera e ai responsabili dell’edizione critica, della codifica e della revisione, mentre il <publicationStmt> raggruppa i dati riguardo la pubblicazione e la distribuzione del documento elettronico.

Per le informazioni concernenti le caratteristiche specifiche del manoscritto, è stato utilizzato l’<msDesc>, uno degli elementi principali del modulo msdescription, inserito all’interno del <sourceDesc>. L’<msDesc> si compone, a sua volta, di quattro unità descrittive: <msIdentifier>, <msContents>, <physDesc> e <history>. Il primo, oltre a specificare il nome con il quale è identificato il Codice, raccoglie una serie di dati sulla sua collocazione fisica; il secondo specifica la lingua del testo, in questo caso il latino, e predispone un campo con un breve riassunto informativo sugli autori; <physDesc> e <history>, invece, attraverso una serie di elementi interni, forniscono tutte le informazioni sulla composizione fisica (dal materiale alla descrizione delle decorazioni) e sulla storia del volume. Infine, sempre all’interno del <sourceDesc>, sono state inserite anche delle liste, fondamentali per la realizzazione degli indici di ricerca e di consultazione dell’edizione digitale.

Liste

Di alcuni elementi marcati nel testo, in particolare i nomi di persona e di luogo, si è deciso di creare delle liste per poterli normalizzare e per creare degli indici, essenziali per la consultazione dinamica e per la ricerca dei contenuti all’interno del manoscritto. Attraverso la predisposizione degli elenchi, infatti, è stato possibile associare una serie di metadati relativi a ogni persona o luogo presente nel testo, creando così una corrispondenza in grado di arricchire l’edizione digitale e, al tempo stesso, di permettere una navigazione completa e approfondita.
La lista delle persone, racchiusa all’interno di un <listPerson>, è composta da tanti elementi <person> quante sono le persone menzionate nel Codice. A sua volta, ognuno di questi tag comprende una serie di campi descrittivi per la codifica dei metadati. Per distinguere i nomi e per creare la corrispondenza tra le liste e le numerose occorrenze nel testo, ogni <person> è dotato di un attributo identificativo, l’@xml:id.

Esempio:
<person xml:id=”Aiutuspres”>
<persName>
<forename>Adiutus / Aiutus</forename>
<surname>de valle Ylioli</surname>
</persName>
<sex>M</sex>
<occupation n=”1″>presbiter</occupation>
</person>

La lista dei luoghi è stata impostata in maniera analoga. All’interno di un unico <listPlace> sono stati inseriti numerosi <place>, distinguibili dai diversi @xml:id, che contengono tutti i metadati necessari per l’identificazione e la descrizione delle singole località.

Esempio:
<place xml:id=”Carrara”>
<settlement type=”corte”>Carraria</settlement>
<placeName type=”new”>Carrara</placeName>
<district type=”comune”>Aulla</district>
</place>

La lista degli enti religiosi e assistenziali è stata ugualmente costruita all’interno di un unico <listOrg> in cui sono stati elencati gli <org> distinguibili dai diversi @xml:id, che contengono  i metadati necessari per l’identificazione e la descrizione degli enti.

Esempio:
<org xml:id=”S_Venanzio_Ceparana”>
<orgName type=”monasterium”>S. Venanzio di Ceparana</orgName>
<desc>Il monastero di S. Venanzio di Ceparana, sito in […]</desc>
</org>

Data la ricchezza delle informazioni e degli elementi presenti nel testo, ogni lista, prima di essere inserita all’interno del documento XML, è stata compilata e aggiornata in un file Microsoft Excel, in modo da facilitare la codifica e l’organizzazione dei metadati. Attraverso il Mapping XML, una specifica funzione disponibile nella scheda sviluppo di Excel, è stato possibile esportare i contenuti della tabella direttamente in formato XML, rispettando così la struttura originaria delle liste. Per prima cosa, è necessario generare un file XML con un modello vuoto della lista di riferimento e associarlo, tramite la funzione mapping, alla tabella Excel. A questo punto basta trascinare la struttura XML sulle celle per completare l’operazione e, quindi, generare il documento. Naturalmente, perché la mappatura possa funzionare, è indispensabile che i due file abbiano la stessa struttura.

All’interno del <sourceDesc> è stata predisposta anche la lista dei signa tabellionis, grazie alla quale è stato possibile collegare i singoli elementi dei timbri nel testo ad una struttura più approfondita, con link alle immagini e riferimenti ai rispettivi notai.

<text>

I documenti del Codice sono stati codificati all’interno di 145 file XML distinti e sono stati collegati al file “master” tramite XInclude, un metodo per collegare fra di loro più file XML.

Nel file principale, dunque, è stato inserito un elemento comprensivo <group> e, al suo interno, sono stati predisposti i collegamenti ai vari documenti XML esterni.

Di seguito è riportata la struttura generica del collegamento tramite XInclude:<xi:include xmlns:xi=”http://www.w3.org/2001/XInclude” xpointer=”numerazioneOrig_numerazioneNuova” href=”doc/numerazioneOrig_numerazioneNuova.xml”>
<xi:fallback>
<p>
<emph>FIXME: MISSING XINCLUDE    CONTENT</emph>
</p>
</xi:fallback>
</xi:include>

Ognuno dei 145 file esterni è stato suddiviso, come per il “master”, nei due macro-elementi standard <teiHeader> e <text>. Il <teiHeader> è rimasto vuoto, non dovendo riportare alcuna informazione generale, mentre il <text> è stato predisposto per la codifica vera e propria dei documenti (comprensiva di metadati).

Per distinguere i numerosi <text> dei documenti è stato predisposto un @xml:id diverso per ogni documento. I valori dell’attributo sono stati ripresi dalle due numerazioni utilizzate per classificare e ordinare i diversi testi, secondo questo schema: “Numerazione originale_Numerazione moderna”. Ad esempio, il documento con numerazione originale CCXL e con numerazione moderna 210, presenta nel <text> il seguente attributo: xml:id=”CCXL_210″.

Documenti

Prima della trascrizione del testo vero e proprio, ogni <text> è arricchito da una serie di informazioni che forniscono dettagli di vario tipo sul documento. Queste indicazioni sono raggruppate nell’elemento <front>, identificato da un @xml:id. Al suo interno, oltre ai due <titlePart> e al <docDate>, utilizzati rispettivamente per trascrivere le due numerazioni (originale e moderna) e la data topica e cronica del testo di riferimento, vi sono numerosi <div>. La presenza di diversi attributi permette di determinare al meglio tutti gli elementi e, al tempo stesso, favorisce la navigazione all’interno dei contenuti per le fasi successive del progetto. Nello specifico, il @type, come si può intuire dal nome, precisa ulteriormente la tipologia del tag; l’@xml:id, invece, identifica in maniera univoca l’elemento, associandolo al documento tramite uno schema simile a quello utilizzato per i <text>.

Di seguito è riportata la struttura del <front>:
<front xml:id=”NumerazioneOriginale_front”>
<titlePart type=”NumerazioneNuova”> … </titlePart>
<titlePart type=”NumerazioneOrig”> … </titlePart>
<docDate xml:id=”NumerazioneOriginale_docDate”>
<date when=”anno-mese-giorno”> … </date>
<placeName> … </placeName>
</docDate>
<div type=”regesto” xml:id=”NumerazioneOriginale_regesto”>
<p> … </p>
</div>
<div type=”footer” xml:id=”NumerazioneOriginale_footer”>
<div type=”orig_doc”> … </div>
<div type=”biblio”> … </div>
<div type=”crit_notes”> … </div>
<div type=”appr”> … </div>
</div>
</front>

Il primo <div> contiene il regesto, in altre parole un breve riassunto del documento dotato di tutte le informazioni necessarie per una rapida comprensione dei contenuti. Nel testo possono essere presenti alcuni termini in latino: questi sono inseriti all’interno dell’elemento <term>, al quale è associato un attributo @xml:lang con valore “latin”. Il secondo, invece, presenta una struttura più complessa. Al suo interno, infatti, sono presenti quattro ulteriori <div>, ognuno dei quali è identificabile per mezzo dell’attributo @type. Il primo include le informazioni riguardanti la collocazione del documento all’interno del manoscritto; il secondo contiene la bibliografia di riferimento, con rimando alla lista bibliografica vera e propria (in coda al file XML); il terzo racchiude eventuali note critiche e il quarto, infine, predispone uno spazio per altri testi di approfondimento.

Allo stesso livello gerarchico del <front> c’è il <body>, l’elemento che contiene l’intero corpo del documento. Al suo interno, le diverse informazioni sono state codificate per mezzo di numerosi elementi. Prima di passare alla loro descrizione, però, bisogna fare una distinzione tra elementi strutturali e semantici. I primi, non trasmettendo alcun tipo di informazione, si occupano di riprodurre la struttura originaria del testo (in paragrafi, in versi, ecc.) nel documento elettronico; i secondi, invece, sono utilizzati per marcare semanticamente i contenuti ricercati. I tag strutturali adoperati per la codifica del Codice Pelavicino sono due: <p> e <pb/>. Il primo permette di distinguere i paragrafi, mentre il secondo segnala il cambio di pagina. Entrambi gli elementi presentano due attributi, @xml:id e @n, che sono usati per distinguerli dagli altri. Ad esempio, il documento che al suo interno presenta il cambio dalla pagina 214 verso alla 215 recto, contiene il seguente <pb/>: <pb n=”215r” xml:id=”fol_215r”/>.

Quasi tutti i documenti, nonostante la molteplicità di contenuti, presentano una o più date di redazione, espresse in numeri romani. Si tratta di un’informazione fondamentale, poiché permette di collocare temporalmente un determinato documento. Per questo elemento è utilizzato <date> che, oltre al resto, consente la memorizzazione della data in cifre arabe (nel formato anno-mese-giorno), grazie all’uso dell’attributo @when.

Anche per i mestieri e per le diverse strutture citate nel Codice è previsto l’utilizzo di due elementi. I primi sono codificati per mezzo di un <roleName> privo di attributi, non essendo prerogativa degli studiosi tener conto del collegamento fra l’impiego e l’eventuale persona associata; i secondi, invece, vengono racchiusi all’interno di un <orgName>. Data la varietà degli insediamenti, ogni <orgName> è contraddistinto da un @type che ne specifica la tipologia. Ad esempio, la chiesa di Ponzanello è resa così nel file XML: <orgName type=”chiesa”>ecclesia de Ponçanello</orgName>.

Per la codifica delle monete è stato necessario adattare uno degli elementi predisposti dalle TEI Guidelines: il tag <measure>. Questo elemento, infatti, è genericamente usato per qualsiasi unità di misura ma, data la sua generalità, può essere impiegato anche per fini più specifici. Per questo elemento sono previsti tre eventuali attributi: il @type, che viene utilizzato per descrivere la tipologia della moneta (imperiales, ianuenses, ecc.), @quantity, che contiene la quantità espressa in cifre arabe e @unit, che informa circa l’unità di riferimento nelle tre possibili casistiche: denari, soldi e lire.

Perché le liste del <teiHeader> possano trovare una corrispondenza con le numerose occorrenze nel testo, è necessario che ogni nome venga annotato con un preciso elemento. Nello specifico, è importante che ogni persona sia codificata all’interno di un <persName> e ogni luogo all’interno di un <placeName>. Il collegamento tra le singole voci della lista e i nomi presenti nel testo è reso possibile grazie all’utilizzo di un attributo @ref, al quale dovrà essere dato come valore l’@xml:id corrispondente preceduto dal simbolo cancelletto: #.

Qui di seguito un esempio di <persName> tratto dal file XML:
<persName ref=”#GerardusVeronus”>Gerardinus</persName>

I signa tabellions, invece, sono marcati nel testo tramite l’elemento vuoto <ptr/>: un puntatore utilizzato per fare riferimento a un altro tag del file XML. Il <ptr/> è dotato di due attributi: un @ref, utilizzato per creare la corrispondenza tra le voci nella lista dei signa (inclusa nel <teiHeader>), e un @facs, fondamentale per la realizzazione del collegamento testo immagine fra i timbri notarili (v. cap. 5).

Ciascun documento è caratterizzato, inoltre, da una serie di interventi editoriali, nello specifico note e correzioni. Anche queste tipologie di informazioni necessitano di una loro codifica e, per questo motivo, sono stati predisposti due elementi: <note> e <supplied>. Il primo è utilizzato per le note ed è provvisto di tre attributi: @place, per la collocazione dell’annotazione nel testo di riferimento (con valore standard “foot”), @n, per la numerazione, e @xml:id, per l’identificazione univoca del tag all’interno del file XML. L’elemento <supplied>, invece, è destinato alle correzioni agli errori del copista o alla scarsa comprensibilità del testo. Due le tipologie di testo mancante  vengono integrate dall’editore:

    • integrazione ex ingenio di una o più parole (ma tendenzialmente di un testo breve o brevissimo) tralasciato dal copista per distrazione;
    • integrazione di una o più parole (qui invece anche frammenti di testo più lunghi) omesse dal copista e ricavabili dallo studio di altre fonti.

La codifica <add place=”inline”> utilizzata fino ad oggi è stata modificata come segue:

  • per errori o omissioni del copista <supplied reason=”omitted”> testo integrato perché omesso </supplied>

reso graficamente come segue <testo integrato perché omesso>

    • per parole illeggibili <supplied reason=”illeggibile”> testo integrato perché illeggibile </supplied>

reso graficamente come segue [testo integrato perché illeggibile]

Una codifica è stata aggiunta per òa gestione dei documenti con struttura tabellare.

    • A livello di codifica, i documenti con struttura tabellare sono così codificati:

<table rows=”2” cols=”2”>
<head>Intestazione tabella:</head>
<row role=”data”>
<cell> Testo </cell>
<cell> Testo </cell>
</row>
<row role=”data”>
<cell> Testo </cell>
<cell> Testo </cell>
</row>

Come si può vedere, l’elemento <table> viene utilizzato per marcare l’inizio della tabella, mentre i suoi due attributi @rows e @cols specificano il numero totale delle righe e delle colonne. All’interno di ogni elemento <table> abbiamo: un <head> per l’intestazione della tabella e una serie di elementi <row>, tanti quante sono le righe indicate nell’attributo @rows. A sua volta, all’interno di ogni <row> sono predisposte una serie di <cell>, in numero uguale a quelle definite nell’attributo @cols.

Una codifica è stata aggiunta per la gestione dei documenti su colonne:

    • A livello di codifica, per suddividere il testo in colonne si utilizza:

<cb n=”1” rend=”2col_layout” xml:id=”CCCXLVI_cb_001”/>

Dove l’attributo @n specifica il numero della colonna alla quale apparterrà il testo seguente, @rend definisce il numero totale di colonne che avrà il dato documento (2col_layout vuol dire che ne avrà due) e @xml:id è l’identificatore specifico della colonna per il dato file XML.

Bibliografia

La bibliografia completa dell’edizione digitale è inserita all’interno di un <back>, allo stesso livello gerarchico del <text xml:id=”text”>. Le diverse voci sono racchiuse in diversi <bibl> e, per mezzo dell’attributo @xml:id, si ricollegano direttamente ai <ref> bibliografici contenuti nel <div type=”biblio”>. Ad esempio, il <ref> con @target=“#LUPO_GENTILE_1912” troverà nel <back> una corrispondenza di questo tipo: <bibl xml:id=”LUPO_GENTILE_1912″>M. Lupo Gentile, <emph>Il regesto del codice Pelavicino</emph>, in «Atti della Società Ligure di Storia Patria», XLIV (1912).</bibl>.
Tutti i <bibl> sono inseriti, a loro volta, all’interno di un’unica <listBibl>, l’elemento che può contenere una lista di citazioni bibliografiche di qualsiasi natura.

Di seguito è riportata la struttura completa del <back>:
<back>
<div type=”biblCompleta”>
<listBibl>
<bibl xml:id=”…”> … </bibl>
<bibl xml:id=”…”> … </bibl>
<bibl xml:id=”…”> … </bibl>

</listBibl>
</div>
</back>


Come si cita questa pagina:

R. Rosselli Del Turco, C. Alzetta, A. Miaschi, Codifica <http://pelavicino.labcd.unipi.it/il-progetto/la-codifica/>, in 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; ISBN 978-88-902289-0-2; DOI 10.13131/978-88-902289-0-2 [consultato in AAAA/MM/GG]