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, col procedere del alvoro, le problematiche sono cresciute e la codifca è stata arricchita e implementata.

I documenti del manoscritto sono stati codificati all’interno di 528 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 civili è 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>

Altre realtà codificate in questo modo sono stati i popoli e le famiglie:

Esempio per popoli:

<org xml:id=”Dani”>
<orgName type=”gens”>Daci sive Dani</orgName>
<desc>Nome dato ai Normanni che attaccarono Luni.</desc>
</org>

Esempio per famiglie:
<orgName xml:id=”AldebertiFamilia_Tivegna”/>
<desc>Consorzio familiare dei domini di Tivegna.</desc>
<person sameAs=”#AldebrandetusAlberti”/>
<person sameAs=”#BonifaciusIordani”/>
<person sameAs=”#GerardusCalatronus”/>
<person sameAs=”#GualterinusNoçardi”/>
<person sameAs=”#HenricusAlbertini”/>
<person sameAs=”#MartinusStranbo”/>
<person sameAs=”#PalmerinusAlbertini”/>
</org>

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 528 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”/>.

La data

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.

I documenti possono presentare eventi interni, con date esplicite o ricavabili indirettamente da elementi del contenuto. Abbiamo identificato tre tipologie di eventi: eventi interni, stesura in mundum e autentica.

Stesura in mundum e autentica vengono racchiuse all’interno di un elemento <div> caratterizzato dai seguenti attributi:

  • un @xml:id che segue la sintassi “NumerazionOriginale_divn”, dove n rappresenta il numero del <div>, includendo nel conteggio anche l’elemento che racchiude il corpo vero e proprio del documento
  • un @type, che assume valore “autentica” e “mundum” rispettivamente.

All’interno di questo <div> la data viene marcata con <date>. Gli attributi possibili sono:

  • @when
  • @notBefore e @notAfter, quando si indica un periodo relativamente approssimativo per la datazione dell’evento. In questo caso si utilizza anche un attributo @cert, che può assumere tre valori (high, medium, low – alto, medio, basso, o unknown, se non si desidera specificare) per indicare il grado di certezza della ricostruzione critica.
  • @from e @to,per indicare un periodo ricostruibile con maggiore certezza.

Sia alle parti di autentica che a quelle di mundum viene associata una breve descrizione, racchiusa all’interno di un elemento <note> privo di attributi (particolare che consente di distinguerlo dalle note vere e proprie). Se la data dell’evento è esplicita nel testo, <note> sarà contenuto in <date>. Se invece la data è una ricostruzione critica, allora <note> conterrà <date>. Il collegamento tra questi due elementi, la data e il titolo dell’evento, è data da una relazione di contenimento: <note> deve essere o il nodo padre, o il nodo figlio di <date>. Per una corretta codifica, si devono evitare gli annidamenti di questi tag all’interno di altri elementi.

La struttura della codifica sarà quindi la seguente:
<div xml:id= “numerazione Originale_div>
contenuto del documento
</div>
<div xml:id= “numerazione Originale_div2” type= “autentica/mundum”>
testo dell’autentica/mundum
</div>

All’interno del testo dell’autentica o della stesura in mundum si possono avere due possibili combinazioni:

<note>Descrizione dell’evento <date @attributi></date></note>
<date @attributi>Data riportata nel documento<note>Descrizione dell’evento</note></date>

Gli eventi attestati nei documenti, ma che non sono oggetto dello stesso, vengono codificati usando <note> privo di attributi per inserire nel testo la descrizione dell’evento stesso, e <date> per marcarne la data, esplicitata nel testo o ricostruita dai curatori. Anche in questo caso si dà una relazione di contenimento: se la data è esplicita, <date> racchiude <note>, altrimenti si verifica l’annidamento contrario.

Gli attributi per la data sono gli stessi usati per la marcatura di autentiche e mundum.

I mestieri

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>.

Le monete

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 cinuqe possibili casistiche: denarius, solidus, mezanus, marca e libra.

I nomi di persona e di luogo

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 dei notai

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).

Integrazioni e citazioni

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 usati quattro elementi: <note>, <supplied>, <expan>, <gap>.

<note> è 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.

<supplied>, invece, è destinato alle correzioni agli errori del copista o alla scarsa comprensibilità del testo per ragioni diverse (macchie, erosione, sbiaditura, ecc.). 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; codifica <supplied reason=”omitted”> testo integrato perché omesso </supplied> reso graficamente come segue <testo integrato perché omesso>;
    • integrazione di una o più parole (qui invece anche frammenti di testo più lunghi) poco leggibili ma ricavabili dallo studio di altre fonti; <supplied reason=”illeggibile”> testo integrato perché illeggibile </supplied> reso graficamente come segue [testo integrato perché illeggibile];

<expan>, invece, è destinato alle espansione di abbreviazioni o di troncamenti, ma solo a quelle proposte come ipotetiche e che lasciano agli autori un certo margine di incertezza. Abbiamo ricontrato due casi:

  • espansione  incerta ma plausibile, codificata come segue <expan>dic<ex>ens</ex></expan>  e resa graficamente con il testo sciolto tra  parentesi tonde: dic(ens);
  • espansione non proponibile, codificata come segue <expan>i<ex>***</ex>a</expan> e resa graficamente con asterischi tra parentesi tonde: i(***)a;

<gap>, infine, è dedicato a segnalare le lacune non emendabili in alcun modo con la seguente codifica <gap quantity=”2″ unit=”chars” reason=”illegible”/>

Le citazioni sono di due tipi:

  • il discorso diretto è marcato con il tag <q> e  il testo visualizzato risulta tra virgolette a sergente « »;
  • la citazione di altri testi è marcata con il tag <quote> e il testo visualizzato è in corsivo, preceduto e seguito da virgolette a sergente « ».
Le tabelle

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

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, E. Salvatori, Codifica <http://pelavicino.labcd.unipi.it/il-progetto/la-codifica/>, in E. Salvatori [et al.] (a cura di), Codice Pelavicino. Edizione digitale, 2a ed., 2020  [consultato in AAAA/MM/GG]