LA DIGITALIzzAzIONE DI TESTI LETTERARI DI AREA GERMANICA ... · 1 7 LA DIGITALIzzAzIONE DI TESTI...

1�7

LA DIGITALIzzAzIONE DI TESTI LETTERARI DI AREA GERMANICA: PRObLEMI E PROPOSTE

Roberto Rosselli Del Turco *

Premessa

La produzione di un’edizione digitale di qualsiasi testo, me-dievale o moderno, richiede un notevole sforzo da parte del cura-tore: un’edizione digitale presuppone che un oggetto fisico venga digitalizzato ed elaborato, per essere infine visualizzato (su scher-mo o a stampa) e manipolato (grazie a strumenti di navigazione, ricerca, confronto). La digitalizzazione spesso riguarda sia il testo, sia le immagini del manoscritto1, e il risultato finale dipende da una bilanciata ed efficace interazione fra queste due componenti essenziali. Tuttavia testo e immagini comportano difficoltà e livelli di responsabilità completamente differenti: per quanto riguarda la digitalizzazione delle immagini, il filologo può delegare l’acquisi-zione e il trattamento2 a un tecnico specializzato; inoltre le tecniche di acquisizione, come pure gli strumenti hardware e software, sono largamente sperimentate e affidabili3. La marcatura di un testo con SGML/XML, invece, implica un intervento e una responsabilità di-retta da parte del curatore, infatti non si tratta mai, se non nel caso

* [email protected] Università degli Studi di Torino.

1 Naturalmente è anche possibile lavorare esclusivamente sul testo e curare un’edizione senza immagini, realizzata comunque come edizione ipertestuale, ma la tendenza generale, e quella in grado di produrre i risultati più interes-santi, vede la riproduzione del manoscritto come facsimile digitale parallela-mente all’edizione dei testi.

2 Anche un eventuale collegamento con il testo per mezzo di image maps, a meno di non usare direttamente uno strumento come EPPT <http://beowulf.engl.uky.edu/eppt-trial/EPPT-TrialProjects.htm>.

3 Un capitolo a parte è costituito dalle tecniche di image processing utilizza-te per il cosiddetto ‘restauro virtuale’, basate sull’applicazione di filtri grafici all’immagine o parti di essa, che sono ancora in buona misura sperimentali. È interessante notare, inoltre, come proprio la necessità di definire una strategia di presentazione delle immagini ‘restaurate’ in rapporto a quelle originali per-metta di parlare di una ‘filologia delle immagini’.

1��

RObERtO ROSSEllI DEl tuRCO

di una marcatura estremamente ‘leggera’, di un’operazione neutra: marcando il testo il filologo lo interpreta e lo descrive, ne mette in risalto quelle che ritiene essere le sue caratteristiche essenziali e la sua struttura fondamentale. La marcatura, inoltre, è un processo lun-go e faticoso, non soltanto nel caso di testi particolarmente lunghi o complessi, ma soprattutto in rapporto alle basi teoriche dell’inter-pretazione cui si accennava sopra: prima di lanciarsi a testa bassa nell’impresa il filologo coscienzioso analizza il testo e definisce la griglia di elementi e attributi che userà; quest’analisi, tuttavia, risulta spesso parziale, infatti non di rado durante il lavoro di marcatura vengono alla luce elementi e particolarità prima non evidenti che implicano una revisione e un ampliamento della griglia preceden-temente stabilita. Per finire, non è impossibile che la stessa DTD o schema di riferimento si riveli inadeguata in relazione al testo da marcare, nel qual caso non resta che ripetersi ancora una volta che la X di XML sta per eXtensible, quindi rimboccarsi le maniche per costruire, eventualmente con l’aiuto della comunità scientifica, uno strumento su misura per le proprie necessità.

Tenendo presenti queste sommarie considerazioni, dobbiamo anche ricordare che non tutti i testi sono uguali ai fini di una marca-tura complessa, e che documenti appartenenti a tradizioni letterarie medievali, o più antiche, presentano caratteristiche e problemi non sempre affrontabili con la panoplia messa a disposizione da pur on-nicomprensive norme di riferimento quali quelle formulate dal con-sorzio TEI (Text Encoding Initiative4). I testi letterari che apparten-gono alla tradizione germanica, in particolare, presentano problemi non riscontrabili in documenti dell’era moderna o contemporanea, problemi che vanno dal livello più ‘basso’, la trascrizione e conver-sione in formato TEI XML, a quello più ‘alto’, la codifica di specifiche caratteristiche testuali in modo da poter effettuare successivamente un’analisi di tipo linguistico o stilistico. In questo articolo prenderò in esame due problemi che appartengono rispettivamente ai due livelli enunciati sopra, la codifica dei caratteri (trascrizione di fonti primarie) e la marcatura di metro e stile (edizione critica e analisi linguistica) in relazione a testi di area germanica5.

4 Il sito della TEI si trova all’indirizzo <http://www.tei-c.org/>, ospita non solo le Guidelines for Electronic Text Encoding and Interchange, ma anche le DTD e gli schemi di riferimento, tutorial, strumenti software e molto altro.

5 Per la codifica dei caratteri mi sono basato soprattutto sull’esperienza ma-turata grazie al progetto Vercelli Book Digitale <http://islp.di.unipi.it/bifrost/vbd/>; per quanto riguarda la marcatura di metro e stile, invece, la progetta-zione di un sistema di markup compatibile con le norme TEI è condotta da tre editor del progetto Digital Medievalist <http://www.digitalmedievalist.org/>:

1�9

lA DIgItAlIZZAZIONE DI tEStI lEttERARI DI AREA gERMANICA

CodiFiCA dEi CARAttERi PER tEsti in inGlEsE AntiCo

L’elemento base della codifica del testo

La digitalizzazione, o codifica, di un testo (ingl. text encoding), può avvenire su più livelli, quello di partenza è costituito dalla tra-scrizione del testo stesso come appare sul supporto che lo conserva, carta o pergamena, creando un documento digitale sulla base dei segni grafici che compongono il testo. L’elemento minimo è dunque il carattere, ma ‘carattere’ è un termine alquanto generico: è possibi-le distinguere fra carattere, inteso come entità astratta che, pur sulla base di un certo numero di caratteristiche fisse (numero e tipologia dei tratti fondamentali), può essere realizzato in modi diversi, e gli-fo, la realizzazione grafica di un determinato carattere, in maniera simile alla distinzione tra grafema-grafo-allografo e fonema-fono-allofono esistente in linguistica.

La codifica di un testo, dunque, avviene attraverso la codifica dei caratteri (ingl. character encoding) che lo compongono, ma que-sto processo è semplice soltanto in apparenza: perché non sempre troviamo il carattere giusto sulla nostra tastiera? Se il font6 in uso lo contiene, come faccio a inserirlo nel mio testo? come posso scoprire se è incluso in uno dei font presenti sul mio computer? Che tipo di font devo usare? Non è possibile rispondere in maniera esauriente a queste domande, e altre simili, se prima non si è accertato che cosa significhi esattamente ‘codifica dei caratteri’.

Computer e caratteri

In primo luogo è importante capire che un computer, a di-spetto delle apparenze, non elabora caratteri, ma soltanto numeri: i primi calcolatori, definizione particolarmente significativa da questo punto di vista, operavano sulla base di schede perforate, senza nes-sun ricorso a interfacce testuali; in un secondo momento si è intro-dotto l’uso dei caratteri per varie ragioni: per migliorare l’interfaccia utente, per impartire direttamente comandi (riga di comando) e per

Dorothy Carr Porter, Daniel Paul O’Donnell e il sottoscritto. Esiste anche una mailing list dedicata: [email protected].

6 Userò questo termine, ormai molto diffuso anche al di fuori dell’area infor-matica, come sinonimo di ‘set di caratteri’.

190


l’archiviazione dei primi testi (programmi e relativa documentazio-ne). Questo, tuttavia, non ha cambiato la situazione iniziale: ancora oggi il computer ‘vede’ soltanto dei numeri, peraltro secondo il si-stema numerico binario (0 e 1), ed elabora qualsiasi tipo di dato per mezzo di operazioni logico-matematiche. Se il codice alla base del funzionamento di un computer è un codice numerico, dunque, ‘co-difica di un carattere’ significa assegnare un numero a un carattere in modo da poterlo identificare.

Se prendiamo un qualsiasi carattere, infatti, e controlliamo la sua codifica sulla tabella di equivalenza, noteremo che esso è iden-tificato per mezzo di un numero, ad esempio per quanto riguarda il carattere A il corrispondente valore numerico secondo la codifi-ca ASCII è 657. Un font quindi potrebbe essere definito come una collezione di glifi che sono associati ai rispettivi caratteri in virtù di codici numerici stabiliti in una normativa standard8.

Sistemi di codifica

I primi sistemi di codifica implementati (ASCII, EBCDIC) non sono molto sofisticati e permettono un numero molto limitato di ca-ratteri. Lo standard ASCII, ancora oggi assai diffuso e di importanza fondamentale per molti sistemi operativi, alla sua prima apparizione comprendeva solo 128 caratteri9, poi aumentati a 25610; una tastiera standard, sfruttando un certo numero di combinazioni di tasti, per-mette di inserire direttamente quasi tutti i caratteri ASCII. Lo svan-taggio sta nel fatto che un numero così basso di codifiche permette di coprire soltanto l’alfabeto latino e poco più: restano fuori tutti gli altri sistemi di scrittura esistenti e passati, rendendo di fatto impra-ticabile la gestione di documenti basati su questi ultimi.

7 Lo stesso valore numerico è espresso come 41 in esadecimale o 0100001 in binario.

8 In caso contrario il rapporto fra glifo e carattere sarebbe del tutto arbitra-rio.

9 Il massimo numero di caratteri possibile impiegando 7 bit per carattere: i numeri disponibili vanno pertanto da 0 a 127.

10 ASCII esteso, sfrutta 8 bit per carattere.

191


Figura 1 (segue)

Caratt.Dec Hex Oct Bin

^@=0-0x00-00-%00000000Â=1-0x01-01-%00000001^B=2-0x02-02-%00000010^C=3-0x03-03-%00000011^D=4-0x04-04-%00000100Ê=5-0x05-05-%00000101^F=6-0x06-06-%00000110^G=7-0x07-07-%00000111^H=8-0x08-010-%00001000Î=9-0x09-011-%00001001^J=10-0x0A-012-%00001010^K=11-0x0B-013-%00001011^L=12-0x0C-014-%00001100^M=13-0x0D-015-%00001101^N=14-0x0E-016-%00001110Ô=15-0x0F-017-%00001111^P=16-0x10-020-%00010000^Q=17-0x11-021-%00010001^R=18-0x12-022-%00010010^S=19-0x13-023-%00010011^T=20-0x14-024-%00010100Û=21-0x15-025-%00010101^V=22-0x16-026-%00010110^W=23-0x17-027-%00010111^X=24-0x18-030-%00011000^Y=25-0x19-031-%00011001^Z=26-0x1A-032-%00011010^[=27-0x1B-033-%00011011^\=28-0x1C-034-%00011100^]=29-0x1D-035-%00011101^^=30-0x1E-036-%00011110^_=31-0x1F-037-%00011111=32-0x20-040-%00100000!=33-0x21-041-%00100001“=34-0x22-042-%00100010#=35-0x23-043-%00100011$=36-0x24-044-%00100100%=37-0x25-045-%00100101&=38-0x26-046-%00100110‘=39-0x27-047-%00100111(=40-0x28-050-%00101000)=41-0x29-051-%00101001*=42-0x2A-052-%00101010+=43-0x2B-053-%00101011-=45-0x2D-055-%00101101.=46-0x2E-056-%00101110/=47-0x2F-057-%001011110=48-0x30-060-%001100001=49-0x31-061-%001100012=50-0x32-062-%001100103=51-0x33-063-%001100114=52-0x34-064-%001101005=53-0x35-065-%001101016=54-0x36-066-%001101107=55-0x37-067-%00110111


8=56-0x38-070-%001110009=57-0x39-071-%00111001:=58-0x3A-072-%00111010;=59-0x3B-073-%00111011<=60-0x3C-074-%00111100==61-0x3D-075-%00111101>=62-0x3E-076-%00111110?=63-0x3F-077-%00111111@=64-0x40-0100-%01000000A=65-0x41-0101-%01000001B=66-0x42-0102-%01000010C=67-0x43-0103-%01000011D=68-0x44-0104-%01000100E=69-0x45-0105-%01000101F=70-0x46-0106-%01000110G=71-0x47-0107-%01000111H=72-0x48-0110-%01001000I=73-0x49-0111-%01001001J=74-0x4A-0112-%01001010K=75-0x4B-0113-%01001011L=76-0x4C-0114-%01001100M=77-0x4D-0115-%01001101N=78-0x4E-0116-%01001110O=79-0x4F-0117-%01001111P=80-0x50-0120-%01010000Q=81-0x51-0121-%01010001R=82-0x52-0122-%01010010S=83-0x53-0123-%01010011T=84-0x54-0124-%01010100U=85-0x55-0125-%01010101V=86-0x56-0126-%01010110W=87-0x57-0127-%01010111X=88-0x58-0130-%01011000Y=89-0x59-0131-%01011001Z=90-0x5A-0132-%01011010[=91-0x5B-0133-%01011011\=92-0x5C-0134-%01011100]=93-0x5D-0135-%01011101^=94-0x5E-0136-%01011110_=95-0x5F-0137-%01011111`=96-0x60-0140-%01100000a=97-0x61-0141-%01100001b=98-0x62-0142-%01100010c=99-0x63-0143-%01100011d=100-0x64-0144-%01100100e=101-0x65-0145-%01100101f=102-0x66-0146-%01100110g=103-0x67-0147-%01100111h=104-0x68-0150-%01101000i=105-0x69-0151-%01101001j=106-0x6A-0152-%01101010k=107-0x6B-0153-%01101011l=108-0x6C-0154-%01101100m=109-0x6D-0155-%01101101n=110-0x6E-0156-%01101110

192


I limiti dello standard ASCII sono stati in parte superati con una serie di estensioni raccolte nelle codifiche ISO-8859: queste permettono di codificare e quindi utilizzare molti più caratteri, ma al prezzo di difficoltà di scambio dei testi fra computer e sistemi di scrittura diversi. Le codifiche ISO-8859, infatti, possono entrare in conflitto perché lo stesso numero potrebbe essere usato per indi-care due caratteri diversi; viceversa, in codifiche diverse lo stesso carattere potrebbe essere indicato con due numeri diversi. Il rischio di corruzione dei documenti nel passaggio da un sistema all’altro è dunque elevatissimo, pertanto questo metodo sicuramente è inuti-lizzabile al di fuori di un singolo sistema di scrittura.

Il sistema di scrittura dell’inglese antico

È sufficiente un rapido sguardo alla tradizione manoscritta medievale di una lingua germanica, quale ad esempio l’inglese antico, per capire quanto i sistemi di codifica basati sul vecchio standard ASCII siano insufficienti allo scopo. Gli scribi anglosas-soni, infatti, hanno ampiamente modificato l’alfabeto latino in modo da adattarlo alla fonologia dell’inglese antico: alcune lette-re sono state modificate (æ, œ, ð), altre sono state sostituite con segni tratti dall’antico alfabeto runico (þ, ƿ), altre ancora sono state abbandonate (q, g sostituita da ʒ, v da f) o utilizzate mol-to raramente (k, j come variante di i per i numerali). Variazioni significative11 nella forma dei caratteri, inoltre, sono dovute alle diverse grafie impiegate nell’arco della produzione manoscritta in inglese antico, alle tradizioni locali dei singoli scriptoria e persino alle abitudini scribali.

Non solo lo standard ASCII tradizionale, ma anche le più recen-ti codifiche ISO-8859 sono del tutto insufficienti per quanto riguar-

11 Cfr. il par. «La codifica dei caratteri non standard dell’inglese antico».


o=111-0x6F-0157-%01101111p=112-0x70-0160-%01110000q=113-0x71-0161-%01110001r=114-0x72-0162-%01110010s=115-0x73-0163-%01110011t=116-0x74-0164-%01110100u=117-0x75-0165-%01110101v=118-0x76-0166-%01110110w=119-0x77-0167-%01110111


x=120-0x78-0170-%01111000y=121-0x79-0171-%01111001z=122-0x7A-0172-%01111010{=123-0x7B-0173-%01111011|=124-0x7C-0174-%01111100}=125-0x7D-0175-%01111101~=126-0x7E-0176-%01111110^?=127-0x7F-0177-%01111111

19�


da una visualizzazione di testi in inglese antico inclusiva di almeno parte dei caratteri originari. Il problema è stato in parte risolto con la creazione di font TTF in cui alle codifiche tradizionali corrispon-dono i glifi dei caratteri desiderati12: anche non volendo considera-re i problemi di inserimento e interscambio che questa soluzione comporta13, tuttavia, essa risulta inapplicabile nel caso s’intenda distribuire la propria edizione digitale per mezzo del World Wide Web. Purtroppo i set di caratteri basati sugli standard ISO-8859 non includono un gran numero di caratteri, soprattutto quelli modificati o varianti di quelli principali, che sarebbero necessari per visualiz-zare i testi anglosassoni. Se consultiamo il corpus del Dictionary of Old English redatto a Toronto14, ad esempio, noteremo che alcune lettere sono visibilmente difformi da quelle ‘normali’:

[005900 (162)] Ȩfne swa he cwæde: Micel is gefea,he ne bið Iudeum anum seald, ac he bið eallum þeowillaðFigura 2

Analizzando il codice HTML della pagina in questione il motivo appare subito evidente:

<img src="T04290_files/etail-uppercase.gif" align="top"

border="0">fne swa he cwæde: Micel is gefea (…)

Non è stato realmente impiegato un carattere E con la ‘coda’15, bensì un’immagine dello stesso, il che spiega le differenze in dimen-sioni e allineamento rispetto alla parte restante del testo. È impor-

12 Si vedano, ad esempio, i vari font basati sul tradizionale set di caratte-ri Times creati da P. Baker (http://www.engl.virginia.edu/OE/#fonts) e altri (http://www.georgetown.edu/faculty/ballc/oe/oe-fonts.html).

13 La sovrapposizione fra caratteri ‘normali’ e quelli del font personalizzato spesso richiede l’uso di software addizionale, ad esempio uno dei vari pro-grammi utilizzati per cambiare le mappe della tastiera. Per quanto riguarda l’interscambio di file, questi dovranno essere necessariamente accompagnati dai font personalizzati e, se il tipo di archivio non permette l’inserimento del font all’interno dell’archivio stesso, come è il caso dei documenti in PDF, que-sti dovranno necessariamente essere trasmessi su archivi separati e installati dal destinatario: se il font non è disponibile, infatti, il documento verrà visua-lizzato come un insieme di caratteri apparentemente privi di senso.

14 The Dictionary of Old English Corpus in Electronic Form, su CD-ROM; e Dictionary of Old English Corpus in Electronic Form on the World Wide Web: <http://www.doe.utoronto.ca/pub/webcorpus.html>.

15 Più precisamente ogonek, o cediglia inversa.

19�


tante comprendere che non si tratta soltanto di un problema, per così dire, estetico: il fatto che non sia presente quel carattere signi-fica che non sarà possibile effettuare ricerche che restituiscano la parola che lo contiene, e il carattere stesso non potrà essere oggetto di ricerca o di analisi. Per visualizzare correttamente il testo, avere una capacità di ricerca full text, e per poter rintracciare eventuali particolarità della grafia, è indispensabile non solo una codifica dei caratteri più avanzata, ma anche una marcatura efficace, in parti-colare per quanto riguarda la gestione di caratteri rari, variazioni uniche del manoscritto, o comunque di tutti i quei casi in cui il carattere desiderato non è visualizzabile.

Lo standard Unicode

Le carenze dei sistemi di codifica fin qui descritti spinsero al-cuni sviluppatori software16 a progettare e implementare un sistema universale, in grado di includere caratteri tipici di sistemi di scrittura quali il cinese o l’arabo, già dal 1987. Nel 1991, dopo anni di lavoro e l’adesione di molte altre parti interessate al processo di sviluppo, viene fondato il consorzio Unicode17, e viene pubblicato il primo volume di uno standard che ha raggiunto recentemente (18 luglio 2006) la versione 5.0, comprendente più di 99.000 caratteri.

L’obiettivo degli sviluppatori di Unicode è quello di fornire agli utenti un sistema di codifica dei caratteri veramente universale:

The Unicode Standard is a character coding system designed to support the worldwide interchange, processing, and display of the written texts of the diverse languages and technical disciplines of the modern world. In addition, it supports classical and historical texts of many written languages18.

16 In particolare alcuni sviluppatori della Xerox, interessati a tracciare le relazioni fra i caratteri giapponesi e quelli cinesi equivalenti, in modo da costruire un font per i caratteri cinesi estesi; e altri presso la Apple, dove si inizia a discutere di un set di caratteri universale in relazione allo sviluppo di Apple File Exchange.

17 Il sito del progetto, <http://www.unicode.org/>, è ricco di informazioni utili, tutorial e documentazione tecnica. Per rispondere a una delle domande poste nel par. 2.1, ad esempio, è stata creata la pagina Where is my Character? <http://www.unicode.org/standard/where/>; molto dettagliata e utile anche l’introduzione tecnica <http://www.unicode.org/standard/principles.html>

18 About the Unicode Standard, <http://www.unicode.org/standard/stan-dard.html>.

195


Non solo supporto per le lingue esistenti, dunque, ma anche attenzione verso versioni più antiche delle stesse, e a scritture ormai scomparse da tempo, sicuramente un pensiero confortante per ogni studioso dell’antichità e del Medioevo. L’obiettivo è uno standard che sia davvero «universal, efficient, unambiguous», basato sulla distinzio-ne fra carattere19 e glifo, e compatibile con la corrispondente versione ISO/IEC 10646, con la quale viene periodicamente sincronizzato. In breve la soluzione definitiva ai problemi di codifica dei caratteri.

Unicode è compatibile anche con il vecchio standard ASCII, che viene ‘incorporato’ nella nuova codifica: i valori numerici dei ca-ratteri ASCII rimangono invariati, anche se possono eventualmente essere preceduti da degli zeri, com’è possibile vedere nella tabella che segue.

Figura 3

19 Il codice numerico viene assegnato al carattere, ma è del tutto indipen-dente dal glifo, che può essere o no presente in un determinato font Unicode. In realtà sono ben pochi i font che si avvicinano a implementare il gran nu-mero di caratteri Unicode.

196


In questo modo la compatibilità con testi codificati in ASCII/ISO-8859-* è completa. Grazie alla sua architettura, inoltre, Unico-de è estensibile: malgrado ancora non siano stati definiti 100.000 caratteri lo spazio a disposizione ne prevede più di un milione. Per finire, se il carattere desiderato non è ancora stato inserito nello standard, è comunque possibile utilizzare quello che viene definito uno ‘spazio privato’ (PUA, o Private User Area) per asse-gnargli un codice numerico (code point) e poterlo implementare in un font adatto per usi specifici.

Questa possibilità ha una rilevanza diretta per gli studiosi di testi non contemporanei, infatti molti caratteri e altri segni grafici che appartengono a tradizioni letterarie antiche e medievali non sono ancora stati accettati all’interno di Unicode. Non solo, il processo di valutazione delle richieste e, nel caso vadano a buon fine, di assegnazione di codici numerici e nomi standard per i nuovi caratteri è piuttosto lungo. Grazie all’uso della PUA, quin-di, è possibile inserire direttamente i nuovi caratteri all’interno di un font Unicode, e sperimentarne l’uso nei propri documenti; una volta assegnati i code point definitivi sarà sufficiente modifi-care il font di conseguenza20.

Questo metodo viene seguito dai promotori di un progetto molto importante per i medievalisti: il progetto Medieval Unicode Font Initiative (MUFI)21, che ha come obiettivo la definizione e l’inserimento nello standard Unicode dei caratteri necessari per la digitalizzazione di testi medievali. Tra i font che implementa-no, o hanno l’obiettivo di implementare, i caratteri proposti da MUFI citiamo Junicode22, ad opera di Peter Baker, di particolare interesse per gli studiosi dell’inglese antico; e Andron Scriptor23, sviluppato da Andreas Stötzner, che si avvicina alla piena confor-mità con lo standard MUFI 2.0.

20 Ci si potrebbe chiedere se non sia una inutile perdita di tempo usare i caratteri dell’area PUA nei propri documenti se la loro codifica è solo tempo-ranea e dovranno essere sostituiti in blocco con la codifica definitiva: grazie all’uso delle entity, invece, non si corre alcun rischio del genere, si veda il paragrafo successivo.

21 Si veda il sito <http://www.mufi.info/>.22 Liberamente scaricabile dal sito <http://junicode.sourceforge.net/>.23 Una versione di prova è disponibile direttamente sul sito MUFI: <http://

www.mufi.info/fonts/#Andron>.

197


La codifica di caratteri ‘speciali’ dell’inglese antico

Tornando alla grafia dell’inglese antico, abbiamo già accennato alle differenze sostanziali rispetto all’alfabeto latino da cui è tratto, e soprattutto alle numerose variazioni nella forma delle lettere: varia-zioni di forma per lo stesso carattere24, di dimensioni25, apposizione di segni diacritici26, e un buon numero di segni con funzioni parti-colari (punteggiatura, brevigrafi, ecc.)27.

Ci sono molti buoni motivi per codificare almeno parte di que-sti caratteri durante la digitalizzazione di un testo: in primo luogo questo tipo di informazioni consentono un’analisi paleografica suf-ficientemente dettagliata, in particolare per quanto riguarda le abi-tudini scribali, in modo da poter formulare ipotesi riguardo il luogo o il periodo di redazione del manoscritto28. La ricerca testuale sarà inoltre molto più precisa, come pure la possibilità di individuare e visualizzare specifici punti del manoscritto in seguito a una ricerca. Inserendo nella codifica il carattere Unicode corretto, e disponendo di un font adeguato (Junicode o Andron Scriptor ad esempio), infi-ne, sarà possibile proporre un facsimile testuale di alta qualità.

Sarebbe un errore, tuttavia, decidere di marcare ogni sin-golo fenomeno grafico del manoscritto: non tutti i segni grafici sono ugualmente significativi, in particolare non tutte le varia-zioni nella forma delle lettere possono contenere informazio-ni utili. Si rende dunque necessaria un’accurata analisi delle principali caratteristiche del manoscritto prima di cominciare la marcatura del testo, per quanto sia sempre possibile29 modifica-

24 La lettera s, ad esempio, ha altre due forme: una con asta discendente al di sotto della linea di scrittura (), probabilmente la più diffusa, e un’altra simile ad una f (ſ).

25 La i e la e, in particolare la seconda, sono talvolta più alte rispetto alla norma.

26 Frequente l’apposizione di un punto sopra la y (ẏ), come pure il segno orizzontale che indica la presenza di un’abbreviazione (ū).

27 Ad esempio il thorn barrato () per þæ, e la classica nota tironiana per and/ond (⁊).

28 Nel caso del Vercelli Book, ad esempio, è stato notato da vari studiosi come la frequenza di alcuni segni e varianti sia piuttosto incostante nello spazio dell’intero manoscritto: stabilire con precisione la distribuzione di tali segni permetterebbe di capire quali sono dovuti all’azione meccanica di co-piatura dell’originale, e quali sono invece attribuibili alle abitudini dello scriba che ha redatto il manoscritto.

29 Dato che il processo di marcatura porta sempre a una migliore conoscen-za del testo e del manoscritto verrebbe voglia di dire che tale fenomeno è in realtà inevitabile.

19�


re e ampliare in corso d’opera il proprio sistema di markup.Possiamo quindi concludere che per una corretta trasposizione

in formato digitale di testi medievali sarà indispensabile ricorrere a un font Unicode, preferibilmente uno dei font che seguono lo stan-dard MUFI. Per quanto riguarda il tipo di markup XML da utilizzare, invece, notiamo che la TEI P5 introduce alcuni significativi miglio-ramenti rispetto alla versione precedente. Qualunque sia la scelta in materia di DTD/Schema, comunque, è senz’altro opportuno fare un uso esteso delle entity: un’entity è una ‘scatoletta vuota’30, inserita nell’intestazione di un file XML31, che viene ‘riempita’ con un valore scelto in precedenza. Ad esempio

<!ENTITY slow ""> 

<!ENTITY slong "ſ"> 

I dati importanti sono due:– slow e slong sono i nomi dell’entity;– i valori fra doppi apici,  e ſ, sono quelli assegnati

alle rispettive entity.

Una volta dichiarata l’entity, sarà necessario usare il suo nome, preceduto da ‘&’ e seguito da ‘;’, tutte le volte che si presenta il ca-rattere corrispondente. Ad esempio:

<lb n="1"/><hi rend="cap1.1">B</hi><hi

rend="cap1.0">R</hi>oðor þa leofestan ic c&windy;ðe þæt

þreo þing &slong;ynt ærest

<lb n="2"/>on fore&ss;weard&utilde; æg&ss;hw&curl

y;lc&utilde; m&eenl;n n&windy;d&ss;be&ss;h&eenl;fe

to&ms;habbanne

<lb n="3"/><num type="ordinal" value="1st">.i.</num>

i&slow;&ms;&yoghtilde;leafa32

30 Può essere paragonata al concetto di costante nei linguaggi di program-mazione; le entità sono molto usate anche nel linguaggio HTML.

31 Il processo di assegnazione di un valore alfanumerico a un’entity viene detto dichiarazione. Se il numero di entity supera la mezza dozzina è preferi-bile dichiararle in un file separato, che può essere richiamato nell’intestazione di uno o più documenti XML.

32 Inizio della Omelia III del Vercelli Book, markup sperimentale del proget-to Vercelli Book Digitale. Le entity citate in precedenza sono state evidenziate nel testo.

199


Quando il documento XML sarà elaborato, ad esempio da un processore XSLT, ogni entity verrà sostituita dal valore corrispon-dente. I vantaggi, rispetto all’uso diretto dei caratteri Unicode, sono molteplici: innanzitutto non è detto che il font utilizzato disponga di quel carattere, utilizzando il valore del code point Unicode ci si mette al riparo da ogni eventualità in attesa di individuare il font più adatto; in secondo luogo, un’entity può contenere del markup XML, pertanto la gestione del singolo carattere può essere molto so-fisticata e contenere numerose informazioni; per finire, modificando il valore dell’entity posso rapidamente cambiare il contenuto del documento XML33 senza dover apportare modifiche per mezzo di un’operazione ‘cerca e sostituisci’ manuale: l’uso delle entity garan-tisce la massima flessibilità, e permette di sperimentare tipi diversi di markup e di codifiche fino al momento in cui sarà stata fatta la scelta definitiva34. Un beneficio collaterale è dato dalla possibilità di trasmettere i propri documenti a sistemi operativi non compatibili con Unicode, non vi è motivo, infatti, per cui i nomi delle entity non debbano essere composti secondo lo standard ASCII, il che facilita lo scambio di file anche con sistemi più antiquati.

Veniamo adesso alla scelta dei valori per le entity. Supponiamo di voler marcare una variante della s nella minuscola anglosassone, se dichiariamo la nostra entity così

<!ENTITY slow "s">

i benefici derivanti dall’uso di un’entity, escludendo il caso che si tratti di un markup temporaneo, sono in sostanza assenti: quando un processore XML analizza e traduce le entity, inserisce nel testo il valore corrispondente, ma il nome stesso dell’entity non viene conservato, quindi il markup non sarà più utilizzabile per la ricerca; anche per quanto riguarda la visualizzazione avremo delle ‘s’ inse-rite nel testo proprio come se avessimo inserito direttamente tale carattere, pertanto questo tipo di markup non presenta alcun van-taggio rispetto al testo semplice. La seguente dichiarazione, invece, ci aiuta proprio per quanto riguarda la visualizzazione:

33 Anche di molti documenti XML contemporaneamente se le entity sono contenute in un file condiviso.

34 Nel caso si sia utilizzato un code point della PUA e al carattere ne venga assegnato uno definitivo dal consorzio Unicode sarà sufficiente cambiare il valore numerico (o inserire direttamente il carattere) nella dichiarazione del-l’entity per aggiornare tutti i documenti in cui la stessa è presente.

200


<!ENTITY slow "">

Ogni occorrenza di &slow; nel testo, infatti, verrà convertita nel carattere che abbiamo inserito come valore di tale entity. Tut-tavia non è ancora possibile effettuare ricerche o analisi statistiche riguardo tale carattere, per questo scopo dobbiamo formulare la dichiarazione dell’entity così:

<!ENTITY slow "<c type='longs'>s</c>">

Il markup utilizzato ci permette di effettuare ricerche35, di usare il carattere ‘’ per una visualizzazione più vicina all’origi-nale, oppure di effettuare una traslitterazione automatica con la ‘s’ rotonda36.

Markup avanzato

L’elemento <c>, che marca un singolo carattere, fa parte della versione P4 delle norme TEI. Nella versione in preparazione, la P5, è stato aggiunto un ulteriore elemento, <g>, che ha lo scopo preciso di permettere il markup di caratteri o glifi non standard. Il nuovo elemento può essere usato in maniera diretta o per mezzo di entity, ad esempio la nostra entity per la ‘s bassa’ potrebbe essere sostituita da questo markup37:

<g ref="#slow"/>

L’elemento <g> deve essere usato insieme al nuovo elemento <charDesc>, che consente di registrare informazioni dettagliate ri-guardo un carattere o un glifo.

<charDesc>

<char xml:id="slow">

<charName>LATIN SMALL LETTER LOW S</charName>

<charProp>

<localName>entity</localName>

35 È necessario un motore di ricerca XML.36 Ad esempio usando dei fogli di stile e un processore XSLT.37 Riteniamo tuttavia più semplice ed efficace modificare il valore dell’entity

in modo da rappresentare questa specifica notazione.

201


<value>slow</value>

</charProp>

<mapping type="standardized">s</mapping>

<mapping type="PUA">U+F127</mapping>

</char>

</charDesc>

La codifica appare piuttosto semplice, abbiamo tuttavia inserito un certo numero di informazioni interessanti:– <charName>: il nome in stile Unicode del carattere o glifo (LA-

TIN SMALL LETTER LOW S)– <localName> e <value>: il nome dell’entity di riferimento

(slow)– <mapping>: il modo in cui deve essere reso il carattere o glifo

(s/38)

Supponiamo adesso che questa particolare versione della s in-sulare, oltre a non essere un carattere Unicode standard, non sia nemmeno presente nell’area privata di nessun font esistente. In questo caso, possiamo comunque inserire un’immagine per visua-lizzare l’aspetto reale del glifo39:

<charDesc>

<char xml:id="slow">

<charName>LATIN SMALL LETTER LOW S</charName>

<charProp>


<value>slow</value>

</charProp>


<graphic url="slow.png"/>

</char>

</charDesc>

Possiamo anche utilizzare l’elemento <glyph>, anche questo nuovo nella P5, invece di <char>, in tal modo possiamo anche di-

38 Si noti come, nel secondo caso, venga inserito direttamente il numero di codifica Unicode dell’area priva (PUA) del font Junicode.

39 In una nota separata, ad esempio, eventualmente con una descrizione inserita per mezzo dell’elemento <desc>; oppure in una finestra pop-up che si apra sul carattere in questione nel caso si decida di visualizzare il testo per mezzo di una pagina X/HTML.

202


stinguere fra due o più varianti del segno in questione all’interno di un unico elemento <charDesc>:

<charDesc>

<glyph xml:id="slow">

<glyphName>LATIN SMALL LETTER LOW S</glyphName>

<charProp>


<value>slow</value>

</charProp>


<graphic url="slow.png"/>

</glyph>

<glyph xml:id="slowstroke">

<glyphName>LATIN SMALL LETTER LOW S WITH STROKE</

glyphName>

<charProp>


<value>slowstroke</value>

</charProp>


<graphic url="slow-stroke.png"/>

</glyph>

</charDesc>

Per ulteriori informazioni sull’uso di questi elementi si rimanda ai capitoli 4 (Languages and Character Sets) e 25 (Representation of non-standard characters and glyphs) delle norme TEI P540. L’uso di entity e il ricorso a un tipo di marcatura sofisticata possono in un primo momento sembrare un metodo complesso e complicato, speriamo tuttavia che anche da questa breve introduzione il lettore abbia potuto realizzare la grande flessibilità garantita dall’uso paral-lelo di Unicode per la codifica dei caratteri e delle norme TEI P5 per la marcatura del testo.

40 Sperberg-McQueen - Burnard 2005. Consultabili sul Web all’indirizzo <http://www.tei-c.org/P5/Guidelines/index.html>.

20�


CodiFiCA di CARAttERistiCHE MEtRiCHE E stilistiCHE

Il Base Tag Set for Verse della TEI

La TEI (versione P4) offre un certo numero di elementi de-dicati alla marcatura di testi poetici che descrive nel capitolo 9 (Base Tag Set for Verse) delle Guidelines, insieme a generiche in-dicazioni per un’analisi delle caratteristiche metriche del testo41. È sufficiente una lettura sommaria di questo capitolo, tuttavia, per notare che il numero di elementi dedicati è piuttosto ridotto (<l>, <lg>, <caesura/>: tutti e tre concepiti per un markup di tipo strutturale) e che per analisi più sofisticate è indispensabile ricorrere a un uso esteso dell’attributo met, eventualmente av-valendosi anche di elementi di tipo generico, non esclusivi del-l’analisi metrica (<seg>, <span>42). Risulta inoltre evidente che i redattori di questo capitolo delle Guidelines hanno tenuto conto soprattutto delle caratteristiche della metrica classica o moderna, non certo della metrica germanica medievale. Per la versione P5 è previsto un solo nuovo elemento, <rhyme>, che in ogni caso non può certo avere un impatto significativo per gli studi germa-nici medievali.

Questo non significa che non sia possibile effettuare una marcatura di testi poetici in lingue germaniche antiche usando le norme TEI, ma che, a differenza di altre aree (trascrizione di fonti primarie, apparato critico, prosopografia, etc.) non esiste una soluzione TEI ‘pronta per l’uso’: in questo caso dobbiamo guardare alle Guidelines come alle istruzioni di un generico ‘kit di montaggio’, e prepararci a utilizzare i vari ‘pezzi’ per costruire una serie di strumenti adatti ai nostri scopi43.

41 Si vedano, in particolare, le sezioni 9.4 Rhyme and Metrical Analysis e 9.6 Encoding Procedures For Other Verse Features.

42 Quest’ultimo viene proposto come soluzione onnicomprensiva nel caso si intenda marcare figure retoriche e stilemi presenti nel testo.

43 Possiamo citare almeno due progetti che hanno proposto delle norme di codifica di testi poetici basate sulla TEI: The Menota handbook, <http://gandalf.aksis.uib.no/menota/guidelines/ch9/metrics_1-1.html> e lo Skaldic Project <http://skaldic.arts.usyd.edu.au/>; si tratta, tuttavia, di soluzioni spe-cifiche per la tradizione norrena.

20�


Caratteristiche della metrica germanica medievale

Qualsiasi sistema di marcatura di un testo poetico di area ger-manica medievale deve prendere in considerazione i principi di base del metro germanico, qui brevemente elencati:

– verso lungo suddivisibile in due emistichi (o semiversi);– allitterazione che unisce i due emistichi;– anisosillabismo;– assenza della rima;– variabilità dello schema accentuativo;– irrilevanza (relativa) della quantità sillabica.

Un altro fatto importante, da non sottovalutare ai fini della progettazione di un sistema di markup, è la mancanza di una teo-ria universalmente accettata riguardo il metro germanico. Questo significa che il nostro sistema deve essere sufficientemente flessi-bile da prevedere il markup in base a teorie diverse, anche con-temporaneamente. Possiamo definire il nostro obiettivo così:

un sistema di marcatura che permetta di annotare in maniera le caratteristiche metriche e stilistiche di un testo, in modo da con-sentire una successiva analisi di tali tratti sia per fini di ricerca, sia per fini didattici.

Tale sistema deve essere:

– efficace, in particolare nell’evitare ambiguità nel markup;– bidirezionale, deve essere possibile accedere all’analisi dal

punto in esame e viceversa tornare al testo in un secondo momento;

– estensibile, deve essere in grado di accogliere interpretazioni diverse e persino contraddittorie

– facilmente integrabile con altri tipi di markup e con le Gui-delines TEI, di cui deve costituire un’estensione pienamente conforme;

– semplice, il markup deve essere quanto più chiaro e compren-sibile possibile.Considerando caratteristiche del metro germanico e i requi-

siti ideali che abbiamo delineato, occorre prestare particolare attenzione al rischio di concepire un sistema di markup eccessi-vamente complesso e aperto a possibili sovrapposizioni di gerar-chie44, soprattutto se si desidera estendere il sistema in modo da

205


comprendere gli stilemi più importanti della poesia germanica medievale.

Il metodo ‘semplice’

La prima espansione degli elementi TEI è di tipo strutturale, ed è finalizzata a distinguere i due emistichi all’interno del verso lungo allitterante: malgrado sia possibile ottenere questo risultato con altri mezzi, un elemento specifico per questo scopo permette una maggiore chiarezza nel markup e semplifica l’analisi metrica e l’elaborazione del testo poetico45. Definiamo pertanto un elemento <hl>, che può essere utilizzato esclusivamente all’interno di <l>, per marcare gli emistichi all’interno del verso, ad esempio:

<l>

<hl>Hwæt! Ic swefna cyst</hl>

<hl>secgan wylle</hl>

</l>

Non è necessario distinguere tra semiverso A e semiverso B tramite due elementi distinti (ad esempio <hlA> e <hlB>) perché questa distinzione può essere effettuata per mezzo degli attributi di <hl>, o per mezzo di fogli di stile XSLT. <hl> è un’aggiunta assai prudente poiché può essere considerato come una forma abbrevia-ta e compatta46 per <seg type=‘halfline’>.

Invece di usare l’attributo met all’interno di <hl>, come pre-vedono le norme TEI per <l>, creiamo un nuovo elemento <met/> per registrare la scansione metrica all’interno di <hl>. L’elemento <met/> può essere ripetuto in modo da includere le scansioni del verso in base alle varie teorie, ad esempio:

<hl>

<met name="Sievers" code="D1" scan="//\x"/>

<met name="Russom" code="x/Sx" scan="x|/\x"/>

44 Per maggiori informazioni riguardo questo problema si veda il capitolo Multiple Hierarchies delle Guidelines.

45 In teoria è possibile ricorrere a <caesura/> per spezzare il verso lungo a metà, ma andrebbe persa l’esplicitazione di quella che è una caratteristica fon-damentale del verso germanico. L’analisi prosodica, inoltre, dovrebbe essere forzatamente racchiusa dall’elemento <l>, con inevitabili complicazioni nel distinguere fra primo e secondo emistichio.

46 Ingl. syntactic sugar, lett. uno ‘zuccherino sintattico’.

206


<met name="Hoover" code="nAn" scan="xx /\x"/>

(...)

HWÆT! WE GARDENA

</hl>

Possiamo già notare, tuttavia, due difetti di questo metodo: non è possibile inserire due o più scansioni alternative47 in base allo stesso sistema e, problema altrettanto rilevante, non vi è modo di associare la scansione alle sillabe che compongono il verso. Risultano del tutto assenti, inoltre, importanti informazioni relative al verso, quali la presenza di anacrusi, il tipo di allitterazione e lo schema allitterativo.

Una soluzione parziale è data dall’incremento degli attributi disponibili, in modo da poter inserire informazioni più dettagliate:

<hl n="3a">

<met system="Sievers"

resp="Schwab"

totalSyllables="5"

scansion="D-1"

Anacrusis="0"

Extrametrical="0"

Lift="1,2,4"

halfLift="3"

dip="5"

allitGlyph="w"

allitSound="/w/"

allitPosition="1,2" />

<met system="Sievers"

resp="Fulk"

totalSyllables="4"

scansion="D-1"

Anacrusis="0"

Extrametrical="0"

Lift="1,2"

halfLift="3"

dip="4"

allitGlyph="w"

allitSound="/w/"

47 Ad esempio le diverse interpretazioni di studiosi riguardo lo stesso ver-so.

207


allitPosition="1,2" />

weorc wuldorfaeder

</hl>

L’attributo resp permette di distinguere diverse letture in base allo stesso sistema, e gli altri attributi proposti permettono di re-gistrare le informazioni relative alla prosodia e all’allitterazione. Se la complessità del markup è aumentata rispetto alla proposta iniziale, tuttavia, resta il problema di una mancata associazione fra il testo e le scansioni proposte48, problema che può essere risolto soltanto introducendo una suddivisione sillabica del testo. Possia-mo aggiungerla alla nostra proposta iniziale, ad esempio:

<hl>

<met name="Russom" scan="/x|/xx"

sylls="1a.1.1 1a.1.2 1a.1.3 1a.1.4 1a.1.5" />

<met name="Bliss" scan="/|\xx"

sylls="1a.1.1 1a.1.3 1a.1.4 1a.1.5"/>

<syl id=1a.1.1>þe</syl>

<syl id="1a.1.2">od</syl>

<syl id="1a.1.3">cyn</syl>

<syl id="1a.1.4">in</syl>

<syl id="1a.1.5">ga</syl>

</hl>

Tuttavia il livello di complessità del markup, in special modo se si desidera includere la messe di informazioni riportate sopra, aumenta in maniera considerevole.

Il metodo ‘complesso’

Il metodo definito all’inizio del paragrafo precedente, basato sugli elementi <hl> e <met/>, è sufficiente per un’analisi generale della scansione metrica, ma non soddisfa pienamente gli obiettivi indicati in precedenza, in particolare i criteri di bidirezionalità ed

48 Tanto che potrebbe essere desiderabile, per semplificare il markup, dis-sociare l’analisi metrica dal testo: usando i meccanismi di collegamento forniti dalla TEI si potrebbe inserire un puntatore come attributo di <hl> (ad esempio <hl n="3a" id="CH.3a">weorc wuldorfaeder</hl>) che rimandi alle scansioni proposte in un’altra parte del documento, o addirittura in un file separato (<met target="CH.3a"system="Sievers" etc.>).

20�


estensibilità. Aggiungendo gli attributi necessari per inserire ulte-riori informazioni, viceversa, si raggiunge un livello di complessità probabilmente eccessivo. È possibile trovare un compromesso ac-cettabile fra queste diverse esigenze ricorrendo a una struttura dati molto potente e flessibile disponibile nella DTD TEI e descritta nel capitolo 16 delle Guidelines49: la feature structure. In questo tipo di struttura ad ogni nome (feature) è associato un valore alfanumerico che può essere richiamato nel testo da marcare per mezzo di una breve stringa di identificazione (attributo id), in maniera tale da avere un markup snello (anche se forse non immediatamente rico-noscibile) e molto dettagliato allo stesso tempo. Una feature struc-ture è senza dubbio complessa da comporre, soprattutto nel caso si desideri costruire una feature structure library, cioè una collezione di blocchi riutilizzabili di coppie feature-value; tuttavia il processo deve essere effettuato soltanto una volta, e da quel momento è pos-sibile ricorrere alla collezione tutte le volte che si desidera. Un ab-bozzo di feature structure library per codificare il metro germanico potrebbe avere questo aspetto:



<fvLib id="PS" type="Prosodic Stress">

<ignored id="x"/> //ignored in scansion

<dip id="SO"/>

<dipResolution id="SOR"/> //second half of resolved

lift

<halfLiftLongPosition id="S1LP"/> // = V+CC

<halfLiftLongNature id="S1LN"/> // = Long Vowel

<halfLiftShort id="S1S"/>

<liftLongPosition id="S2LP"/> // lift long by position

<liftLongNature id="S2LN"/> // lift long by quantity

<liftLongResolution id="S2LR"/> // first part of resol-

ved lift

<liftShort id="S2S"/> // short lift

</fvLib>

<fvLib id="AT" type="Alliteration Types">

<allitNone id="A0"/> // does not alliterate

<allitPrimary id="A1"/> // alliterating lift

<allitSecondary id="A2"/> // alliterating dip

</fvLib>

49 Sperberg-McQueen - Burnard 2002, cap. 16 Feature Structures.

209


<fvLib id="AP" type="Alliteration Phonology">

(…)

<allitPW id="APW"/> // /w/ alliteration

</fvLib>

<fvLib id="AG" type="Alliteration Grapheme">

(…)

<allitGW id="AGW"/> // <w> alliteration

</fvLib>

Il verso weorc wuldorfaeder che avevamo preso ad esempio in precedenza verrebbe dunque marcato così:

<hl n="3a" id="CH.3a">

<syll id="ch3a.1">weord</syll>

<syll id="ch3a.2">wul</syll>

<syll id="ch3a.3">dor</syll>

<syll id="ch3a.4">fae</syll>

<syll id="ch3a.5">der</syll>

</hl>

Mentre la marcatura delle caratteristiche metriche avviene in un altro punto del file o, se così si desidera, in un file separato:

<linkGrp type="metrical prosody" domains="PS AT AP AG T1">



<link id="L1" targets="ch3a.1 S2LP A1 APW AGW"/>

<link id="L2" targets="ch3a.2 S2LP A1 APW AGW"/>

<link id="L3" targets="ch3a.3 S1LP A0"/>

<link id="L4" targets="ch3a.4 S1S A0"/>

<link id="L5" targets="ch3a.5 S0 A0"/>



Seguendo questa procedura possiamo avere tutti i vantaggi del metodo ‘semplice’, in particolare una codifica del testo chiara e con-cisa, e la ricchezza di informazioni desiderata, estensibile quanto si vuole grazie al fatto che la libreria feature structure è una struttura aperta. In più, grazie al sistema di linking ideato dai redattori TEI, il nostro markup è pienamente bidirezionale, infatti è possibile spo-starsi da un id al target corrispondente e viceversa. Il nostro sistema è ancora da perfezionare e definire nei dettagli, tuttavia riteniamo che in questo caso specifico i migliori risultati siano garantiti dall’uso delle feature structure o di qualche altra forma di standoff markup.

210


Markup di figure retoriche: la kenning

La kenning è uno stilema assai raffinato, definibile come un composto poetico usato in luogo del nome comune di una persona o di una cosa, comune alla tradizione poetica anglosassone e norrena. Le kenningar presentano non solo una notevole variabilità formale, come risulta evidente dalla nomenclatura descritta da Snorri50, ma sono anche oggetto di discussione presso gli studiosi, al punto che non esiste un consenso su una definizione universale di kenning. Qualsiasi forma di markup della kenning, dunque, dovrebbe essere sufficientemente flessibile da accogliere interpretazioni diverse51.

La forma più semplice di markup è quella che vede l’uso di un elemento <kenning>:

<kenning>swanrad</kenning>

<kenning>beadoleoma</kenning>

Questo tipo di marcatura è sufficiente per la generazione di liste di kenningar, o per rintracciarle rapidamente nel testo, ma non consente nessun tipo di analisi dei termini marcati. Aggiungendo a <kenning> questi sotto-elementi:

<bw> parola base

<det> determinante

<reg> forma regolarizzata della kenning

<refer> referente

è possibile scomporre la kenning nei suoi elementi fondamentali e registrare informazioni più precise, utili in una fase successiva: l’elemento <refer>, ad esempio, permette di esplicitare e marcare l’oggetto o la persona alla quale si riferisce la kenning, utile nel caso non siano immediatamente evidenti52; grazie a <bw> e <det> è possibile generare liste relative a queste due componenti e com-pararle in modo da analizzare più precisamente l’aspetto lessicale della kenning; <reg> si presta ottimamente alla generazione di un glossario; tutte queste informazioni, infine, possono essere analizza-te per produrre statistiche relative all’uso di ciascuna componente.

50 Nel secondo libro dell’Edda (Skáldskaparmál) Snorri Sturluson descrive e classifica, per bocca del dio Bragi, i vari tipi di kenning e heiti.

51 Esattamente come per le teorie relative al metro germanico.52 È il caso di alcune kenningar della tradizione norrena.

211


Il nostro esempio sarebbe quindi marcato così:

<kenning>

<det>beado</det><bw>lēoma</bw> <refer>sweord</refer>

</kenning>

Parte delle informazioni possono essere registrate come meta-dati, facendo uso di attributi: type per specificare il tipo di kenning, level per indicare il livello (utile nel caso di kenningar doppie e triple tipiche della poesia nordica), class per l’ambito semantico in cui può essere classificata la kenning, func per specificare la funzione stilistica della stessa (ad esempio nel caso sia usata come variazione).

<kenning type="metaphor" class="nature"

func="variation">

<det>swann</det>

<bw>rad</bw>

<reg>swanrad</reg>

<refer>sae</refer>

</kenning>

<kenning type="metaphor" class="war,weapon"

func="dobject">

<det>beadu</det>

<bw>leoma</bw>

<reg>beadoleoma</reg>

<refer>sweord</refer>

</kenning>

<kenning level="1">

<det>

<kenning level="2">

<det>heofon</det>

<bw>engla</bw>

</kenning>

</det>

<bw>cyning</bw>

</kenning>

Anche in questo caso siamo in una fase preliminare di pro-gettazione e definizione del markup, una versione alternativa ad esempio potrebbe far uso del nuovo elemento <choice> offerto

212


dalla TEI P5:

<kenning type="metaphor" class="war,weapon"

func="dobject">

<choice>

<orig>

<det>beadu</det><bw>leoma</bw>

</orig>

<reg>beadoleoma</reg>

</choice>

<refer>sweord</refer>

</kenning>

<kenning type="metaphor" class="nature"

func="variation">

<choice>

<orig>

<det>hran</det><bw>rad</bw>

</orig>

<reg>hronrad</reg>

</choice>

<refer>sae</refer>

</kenning>

Per fare spazio a una classificazione precisa, inoltre, potrebbe essere necessario ricorrere ad una forma di standoff markup simile a quella prospettata per l’analisi del metro germanico. Ci paiono comunque evidenti i vantaggi che questo tipo di marcatura del te-sto poetico, completato dalla definizione di altre figure retoriche centrali nella poesia germanica medievali ed eventualmente usato congiuntamente all’analisi metrica, offre al curatore di un’edizione digitale di un testo medievale di area germanica.

21�


Riferimenti

P.S. Baker, Junicode font: <http://junicode.sourceforge.net/>.Chisholm - Robey 1995 = D. Chisholm - D. Robey, Encoding verse texts,

«Computers and the Humanities», 29 (1995), pp. 99-111.Consorzio Unicode: <http://www.unicode.org/>.Dictionary of Old English Corpus in Electronic Form on the World Wide

Web, <http://www.doe.utoronto.ca/pub/webcorpus.html>.D.G. Durand - S.J. DeRose - E. Mylonas, What should markup really be?

Applying theories of text to the design of markup systems, disponibile alla pagina <http://xml.coverpages.org/Durand-markup-abridged.html>.

Edition Production & Presentation Technology (EPPT): <http://beowulf.engl.uky.edu/eppt-trial/EPPT-TrialProjects.htm>.

Falkenberg - Ore - Taugbøl 2001 = I. Falkenberg - E.S. Ore - S.B. Taugbøl, TEI for Good or Verse. Articolo presentato in occasione del convegno ACH/ALLC 2001 (New York University, 13-16 giugno 2001). Disponibi-le sul sito <http://www.nyu.edu/its/humanities/ach_allc2001/papers/falkenberg/index.html>.

Mahoney 2003 = A. Mahoney, Talking About Meter in SGML, «Computers and the Humanities», 37 (2003), pp. 469-73.

Medieval Unicode Font Initiative (MUFI): <http://www.mufi.info/>.Progetto Vercelli Book Digitale: <http://islp.di.unipi.it/bifrost/vbd/>.Progetto Digital Medievalist: <http://www.digitalmedievalist.org/>.Skaldic Project: <http://skaldic.arts.usyd.edu.au/>.Sperberg-McQueen - Burnard 2002 = C.M. Sperberg-McQueen - L. Burnard

(eds.), TEI P4: Guidelines for Electronic Text Encoding and Interchan-ge, Oxford, Providence, Charlottesville, Bergen: Text Encoding Initiative Consortium, 2002. XML Version. Disponibile sul sito <http://www.tei-c.org/P4X/>.

Sperberg-McQueen - Burnard 2005 = C.M. Sperberg-McQueen - L. Burnard, eds., TEI P5: Guidelines for Electronic Text Encoding and Interchange [v. 0.4.1], Oxford, Providence, Charlottesville, Nancy: Text Encoding Ini-tiative Consortium, 2005. La versione preliminare è disponibile sul sito <http://www.tei-c.org/P5/>.

The Dictionary of Old English Corpus in Electronic Form, a cura di P. Hea-ley - D. Haines - J. Holland - D. McDougall - I. McDougall - X. Xiang, TEI-P3 conformant and TEI-P4 conformant version, 2004 Release, Toronto, Dictionary of Old Eenglish Project, 2004.

The Menota Handbook: <http://gandalf.aksis.uib.no/menota/guidelines/in-dex.page>.

The Text Encoding Initiative: <http://www.tei-c.org/>.

LA DIGITALIzzAzIONE DI TESTI LETTERARI DI AREA GERMANICA ... · 1 7 LA DIGITALIzzAzIONE DI TESTI...

Documents

Transcript of LA DIGITALIzzAzIONE DI TESTI LETTERARI DI AREA GERMANICA ... · 1 7 LA DIGITALIzzAzIONE DI TESTI...