Licterarum Partium 19

Il manoscritto Licterarum Partium n. 19 è un codice cartaceo consistente di 16 fogli non numerati, dotati di scalettatura al margine destro per rubricazione alfabetica, e di 228 fogli numerati in cifre arabe sul recto. Dal registro sono stati asportati i fogli 99-112, l'angolo inferiore sinistro dei quali resta ancorato alla cucitura del registro. La coperta è in pergamena, con il dorso decorato da borchie di cuoio scuro sulle quali risalta l'intreccio della cucitura in pelle allumata. Capitelli in pelle allumata consolidano la struttura alle estremità del dorso, ma il registro si presenta comunque piuttosto deformato e sembra essere stato consolidato con una nuova cucitura posteriore. Le sue dimensioni sono 29x21,5x5 cm (altezza x larghezza x spessore).

Per la trascrizione ci si è avvalsi di criteri interpretativi largamente diffusi fra gli editori di fonti coeve. La grafia originale delle parole è stata rispettata, introducendo lievi modernizzazioni quali: la distinzione di u e v, la resa di j come i, l'introduzione di accenti e punteggiatura, la resa unitaria di parole potenzialmente separate, come nel caso dei connettori causali (es: «peroché») e finali (es: «acioché»), o di certi pronomi e aggettivi utilizzati con funzione anaforica (es: «supradicto»).

Le abbreviazioni sono state sciolte fra parentesi tonde, sebbene questa soluzione sia temporanea. Era stata concepita nell'ottica di permettere una doppia visualizzazione, con il testo interamente sciolto o con evidenziazione degli scioglimenti. Non è stato ancora possibile, però, implementare tecnicamente quest'idea.

Altri segni diacritici adoperati sono:

[ ] per integrazioni di omissioni o lettere illeggibili a causa di lacune e macchie

*** per spazi lasciati in bianco dallo scrivente

÷ per 1/2

Quanto alla resa dei fenomeni paleografici e della disposizione degli elementi nello specchio di scrittura, si è spostata in capo al testo di ogni lettera l'indicazione del beneficiario di essa, che nel manoscritto è collocata solitamente sul lato sinistro della pagina. Altri tipi di annotazione marginale, insieme a eventuali correzioni e particolarità della grafia, sono state descritte nelle note alfabetiche.

Manca per ora un apparato di note storiche. Questo esito dipende dall'intenzione originaria di realizzare una sorta di apparato esterno, collegato all'edizione grazie ai linked open data, ma i problemi incontrati su quel versante della sperimentazione hanno significato per ora la mancata realizzazione di questo collegamento. Personaggi eminenti come i feudatari del regno sono comunque identificati negli indici dell'edizione, così come luoghi che hanno mutato nome nei secoli.

Sin dall'inizio il progetto ha beneficiato del lavoro informatico di Alfredo Cosco, che ha sviluppato un'applicazione, Aracne, basata sulla piattaforma eXist-db1. Grazie ad essa, non è stato necessario creare riga dopo riga un file strutturato secondo l'arborescenza XML, poiché Aracne genera automaticamente, attraverso la compilazione di alcuni campi di testo predefiniti, la struttura di base del markup, conformemente allo schema di codifica TEI2. L'operazione avviene separatamente per ogni singolo documento (in questo caso le lettere copiate nel registro) e dà luogo a un albero come il seguente:

tei
  teiheader
    filedesc
      titlestmt
        title
        /title
        respstmt
        /respstmt
       /titlestmt
      sourcedesc
        listbibl/listbibl
        msdesc
          msidentifier
          /msidentifier
          mscontents
            summary
              p/p
            /summary
          /mscontents
          physdesc
          /physdesc
        /msdesc
      /sourcedesc
      notestmt/notestmt
        /filedesc
  /teiheader
  text
    docdate
    /docdate
    div type="protocollo"/div
    div type="testo"/div
    div type="escatocollo"/div
  /text
/tei

La codifica di fenomeni testuali di vario genere, invece, dall'identificazione di agenti a quella di situazioni paleografiche particolari, avviene attraverso la digitazione manuale dei marcatori, assistita da alcuni automatismi e da un correttore che pone in evidenza eventuali errori. Di seguito, elenchiamo schematicamente gli elementi ed attributi TEI che si è scelto di adottare, a partire da quelli necessari alla basilare formattazione del testo:

p

Per delimitare i singoli "paragrafi" eventualmente riconosciuti all'interno di una lettera. Il marcatore è comunque sempre obbligatorio all'interno dei campi "Regesto" e "Protocollo", "Testo", "Escatocollo", a meno di volerli lasciare vuoti.

span rend="hi"

Per collocare in apice alcune lettere o parole, replicando ciò che si osserva nel registro trascritto. Ricorrente, per esempio, con le date (es: «die X^o februarii 1482»).

span rend="italic"

Per la formattazione dei caratteri in corsivo.

ref e note

Quando si lavora su un file XML, l'inserimento di note rappresenta uno dei compiti più gravosi per l'editore, poiché i meccanismi di marcatura sono laboriosi e la minima disattenzione può dare luogo a errori. Proprio in questo, però, Aracne mostra uno dei suoi pregi maggiori. Alfredo Cosco è riuscito a sviluppare un "note taking environment" che rende automatico tutto il processo di codifica della marcatura necessaria all'implementazione della nota in XML. Non solo, ma è anche possibile inserire due ordini separati di note, alfabetiche e numeriche, e realizzare dunque un tradizionale apparato di note storiche e paleografiche senza sforzi particolari. La tecnica implementata è quella di referenziare un punto del testo attraverso un elemento ref dotato di un attributo @target, che ha come valore un codice identificativo, e di un attributo @type, il cui valore specifica se la nota da generare è alfabetica (valore "alpha") o numerica (valore "integer"). Il valore dell'attributo @target permette il collegamento a un elemento note situato in una porzione separata del testo, accompagnato da un attributo @xml:id che ha per valore appunto il codice cui punta l'attributo @target. Spiegata in questi termini la cosa può sembrare ostica, ma l'effettivo inserimento di una nota è estremamente semplificato da Aracne, che attraverso alcuni pulsanti permette all'editore di preoccuparsi solo di posizionare la nota al punto giusto, scegliere se essa dev'essere alfabetica o numerica e compilarla.

persName

L'elemento serve a marcare i nomi di persona. Lo schema TEI offre anche la possibilità di impiegare degli elementi incastonati all'interno di persName per articolare maggiormente la "descrizione" della persona stessa, per esempio evidenziando quale è il nome e quale il cognome. Si è ritenuto, tuttavia, che non valesse la pena spingersi sino a questo livello, poiché le strutture onomastiche presenti nella fonte pongono numerosi problemi a chi voglia servirsi troppo fedelmente di una distinzione netta e moderna fra nome e cognome.

Le abitudini registrate a tal proposito nei nostri documenti comportano, per esempio, la frequente difficoltà di distinguere chiaramente cognomi e nomi di famiglia da patronimici e soprannomi. Oltretutto le lettere Partium, al di là dell'apparizione più o meno costante di un pugno di personaggi e famiglie celebri (es: d'Afflitto) abbondano di personaggi poco o punto noti, afferenti a un sottobosco sociale e amministrativo di grande interesse ma mai indagato in modo puntuale dalla storiografia.

placeName

Utilizzato per la marcatura di toponimi. Ci si è chiesti, in questo caso, se valesse la pena fornire una specificazione relativa alla posizione gerarchica di un luogo attraverso attributi dell'elemento placeName. Si può ipotizzare, per esempio, una distinzione fra @region (Terra di Lavoro, contea di Aliano, diocesi di Capaccio), @settlement (Napoli) e @district (Mezzocannone). Tuttavia, questi attributi non paiono riflettere adeguatamente i bisogni che emergono dall'esame della fonte, le loro specificazioni sono imprecise rispetto al contesto storico e pertanto poco utili. Subito evidente, per esempio, la vaghezza del termine "regione" rispetto alla differente natura che caratterizza una provincia amministrativa, da un aggregato feudale, da una diocesi.

orgName

Con l'idea di marcare le entità collettive come università e chiese o monasteri, si è adottato questo elemento, che nelle Guidelines TEI è pensato per gli organizational names. Tuttavia, l'uso di questo tag si è limitato per ora ai casi in cui una di queste entità risultasse implicata in un ruolo documentario (d'abitudine come esponente della lettera, ma talvolta anche come destinataria). Ciò vuol dire che l'indicizzazione di queste entità non è al momento completa.

roleName

La logica per l'impiego di quest'ulteriore elemento è simile a quella descritta per orgName: qualora un ufficiale non altrimenti riconoscibile (cioè appunto un'entità identificata da un ruolo e non, per esempio, da un nome di persona) sia il destinatario o l'esponente di una lettera, si è fatto ricorso a roleName per poterlo indicizzare secondo la funziona documentaria che svolge.

Per tutti questi elementi si sono usati due attributi in modo ricorrente, con intenzioni precise:

@key

Lo si è usato per definire una forma normalizzata con la quale identificare le entità. È in sostanza la stringa di testo con la quale viene memorizzato un nome per l'indicizzazione, aggirando così le varianti grafiche che possono occorrere in una fonte del XV secolo. Qui si pone, beninteso, un classico problema di metodo che chiunque abbia realizzato un indice dei nomi conosce. Fino a che punto bisogna normalizzare, e secondo quale delle forme occorrenti?

Per quanto riguarda i nomi di persona, si è scelto di dare una forma canonica, quella maggiormente invalsa nella bibliografia, ai nomi dei personaggi più eminenti e noti. Anzi, nei casi di persone identificate attraverso il loro titolo (es: principe di Bisignano), frequente in quest'epoca soprattutto per i maggiori feudatari, si è optato comunque per la marcatura tramite persName , usando l'attributo per specificare il nome della persona, seguito dal titolo, e compiendo così un'operazione critica che normalmente si attua attraverso le note storiche al testo.

Per i numerosi personaggi meno noti o sconosciuti, invece, ci si è spinti a delle normalizzazioni solo nel caso di nomi molto comuni (per esempio "Iohanne" è stato reso come "Giovanni"), ma conservando una grafia arcaizzante laddove la modernizzazione implica maggiori forzature (classico il caso di "Iacobo"; ma ci si è attenuti a questo principio anche per le numerose varianti di "Iohanne"). In generale, dove si è potuta accertare l'identità di un personaggio al di là delle varianti grafiche relative al suo nome, si è provveduto a indicizzarla in una forma normalizzata, fermo restando che le varianti restano visibili sia negli indici che nel testo della fonte.

Il problema si pone anche per i luoghi, ovviamente, dove entra in gioco pure la questione del mutamento della toponomastica di uno stesso luogo nel tempo. In genere si è scelto di normalizzare in @key il nome antico, ma se esso differisce molto da quello attuale, si è riportato anche questo nella normalizzazione, fra parentesi tonde. Anche in questo caso, dunque, si è trasposto a livello di indice un'operazione d'identificazione che talvolta si trova compiuta nelle note a piè di pagina delle edizioni cartacee.

Per uffici e collettività è ovvio che la normalizzazione si è rivelata molto più semplice.

@role

Questo secondo attributo è servito ad aggiungere una dimensione in più alle operazioni di indicizzazione, allo scopo di consegnare all'utente un'ulteriore chiave di accesso alla fonte. Ogni volta che una persona, una collettività o un ufficiale è coinvolto come querelante, destinatario o sottoscrittore di una lettera, ci si è serviti di @role per evidenziarlo. I ruoli documentari individuati sono dunque: esponente, destinatario, sottoscrittore primario e sottoscrittore secondario.

Al momento, il modo più funzionale di effettuare una ricerca concentrata sui ruoli documentari testimoniati dalla fonte è selezionare uno degli indici, in particolare quello dei nomi, è utilizzare il campo di ricerca per introdurre una stringa come "esponente"; in questo modo, si potrà visualizzare una lista di tutti i personaggi indicizzati con questo ruolo.

Allo stato attuale del progetto, non è stato ancora tecnicamente possibile elaborare triple RDF in maniera semi-automatica a partire dall'edizione di Partium 19, sebbene alcune vie praticabili siano state individuate e discusse in sede di tesi di dottorato. È stato invece possibile cominciare una collaborazione con FactGrid ( https://database.factgrid.de/wiki/Main_Page ) ed entrare in contatto con il consorzio Data for History ( http://dataforhistory.org/ ), per collocare il progetto entro una comunità scientifica più ampia di storici interessati alle potenzialità di ontologie e triple per lo sviluppo di nuovi strumenti di ricerca. È una precondizione fondamentale non solo per promuovere iniziative come questa edizione, ma anche per condividere prassi operative e riflessioni, con uno spirito senza il quale ricorrere alle tecnologie LOD ha ben poco senso.

Al momento, è soprattutto la partecipazione a FactGrid che ha permesso di effettuare qualche sperimentazione concreta. Questa piattaforma, che utilizza Wikibase per costruire una base di dati semantica e collaborativa, offre un possibile incubatore entro il quale far crescere una prima generazione di dati estratti da Partium 19, ma utili per scopi più ambiziosi. Per fornire un'idea di ciò che si potrebbe fare in futuro, si è partiti dall'immissione manuale in FactGrid dei dati relativi alle prime tre lettere dell'edizione. Le triple utilizzate per descrivere l'entità che rappresentano le lettere sono visualizzabili a questi URL:

- https://database.factgrid.de/wiki/Item:Q251753

- https://database.factgrid.de/wiki/Item:Q254563

- https://database.factgrid.de/wiki/Item:Q254595

Si noti che Q251753, Q254563 e Q254595 sono gli identificativi delle entità. Nel formulare queste asserzioni, è stato necessario attenersi al modello di dati già utilizzato in FactGrid e riutilizzare il più possibile predicati già esistenti, trovando dei compromessi. Ciò non ha rappresentato un handicap di particolare rilievo, sebbene ponga problemi interessanti qualora si volesse provare a fare un uso più spinto di meccanismi inferenziali. La logica formale adoperata, infatti, è per il momento molto elastica quanto a regole e tassonomie; non c'è dubbio che volendo definirne una più stringente e precisa bisognerebbe disporre di un database a parte.

A ogni modo, ecco uno schema semplificato delle triple adoperate per descrivere una lettera, con riferimento agli item e alle proprietà di FactGrid:

Come si può notare esplorando la pagina relativa all'oggetto Q251753, elaborare delle triple implica riferirsi a numerose altre entità: persone, istituzioni, comunità, luoghi, che a loro volta sono dotate di identificativi e possono essere descritte in maniera più o meno approfondita, anche a seconda delle fonti a disposizione. Si costituisce in questo modo una sorta di intreccio discorsivo elementare, che si può arricchire sia creando nuovi oggetti e collegamenti interni al database, sia allacciando le entità ad altre risorse digitali esterne, come le trascrizioni di documenti proposte nella presente edizione, o gazetteer utili a georeferenziare luoghi, o ancora le authority list prodotte da biblioteche, archivi e istituti culturali.

Si stabilisce, inoltre, un doppio possibile vincolo fra database ed edizione (o altre iniziative). Come i dati della seconda possono riversarsi nel primo, così progetti esterni possono agganciarsi agli identificativi univoci delle entità raccolte nel database. In tal modo, un'edizione come quella qui presentata potrebbe avere una sorta di apparato esterno in dinamica crescita e riutilizzabile anche da altri prodotti online che hanno per protagoniste le medesime entità. Nello stesso tempo, il database semantico può avere una sua dignità autonoma e, grazie alle diverse fonti da cui potrebbe alimentarsi, divenire una sorta di repertorio a cui rivolgersi per compiere sondaggi e reperire informazioni.

È possibile esemplificare alcuni casi d'uso, per quanto in maniera ancora molto elementare. S'immagini di voler raccogliere informazioni prosopografiche su una persona, come il Renzo d'Afflitto che compare anche in Partium 19. Si utilizzi la seguente query SPARQL nel query service di FactGrid https://database.factgrid.de/query/

SELECT ?uffici ?ufficiLabel ?data ?dataInizio ?ultimaDataNota ?fonteLabel ?pagine ?link WHERE { SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }

wd:Q251728 p:P164 ?statement.

?statement ps:P164 ?uffici.

OPTIONAL {

?statement pq:P106 ?data.

}

OPTIONAL {

?statement pq:P49 ?dataInizio.

?statement pq:P303 ?ultimaDataNota.

}

?statement prov:wasDerivedFrom/pr:P51 ?fonte

OPTIONAL {

?statement prov:wasDerivedFrom/pr:P54 ?pagine.

}

OPTIONAL {

?fonte wdt:P69 ?link

}

}

Si noterà che per chiarire il potenziale di questi strumenti è stata inserita in FactGrid un'informazione desunta da uno dei volumi delle Fonti aragonesi edite a cura degli archivisti napoletani. Una ricerca sul database può quindi integrare informazioni di disparata provenienza, purché naturalmente l'assemblaggio dei dati sia stato compiuto con criterio e l'utente possa facilmente intendere il grado di rappresentatività dei dati ottenuti.

Ancora a titolo di esempio, si guardi come la query qui di seguito permetta di ottenere informazioni su tutti coloro che sono stati funzionari della Sommaria con il rimando alla fonte, che in questo caso è l'edizione di Partium 19:

SELECT ?soggettoLabel ?ufficioLabel ?data ?fonteLabel ?link WHERE { SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }

?soggetto p:P164 ?statement.

?statement ps:P164 ?ufficio.

?statement pq:P315 wd:Q251751.

?statement pq:P106 ?data.

?statement prov:wasDerivedFrom/pr:P51 ?fonte.

?fonte wdt:P69 ?link

}

Ovviamente, i risultati di queste query sono per ora assai limitati, perché i dati caricati su FactGrid sono pochi e vengono quasi esclusivamente dal registro Partium 19, ma è facile immaginare quanto le cose possano farsi interessanti (e metodologicamente problematiche) al cospetto di dataset più ricchi. Di conseguenza, l'auspicio per il futuro è di poter completare l'esportazione dei dati di Partium 19, ma nel contempo di poter trovare il giusto taglio per un progetto più ampio, che permetta al mondo della ricerca storica di trarre un beneficio reale dalle promesse d'interoperabilità dei LOD.