Vespasiano da Bisticci, Lettere

L'embedded markup: l'annotazione XML/TEI

Il modello di markup proposto vuole tradurre i tre elementi cardine dell'edizione in un sistema formale. Il modello dichiara quindi in forma esplicita i punti di accesso al contenuto della lettera. Tali punti di accesso rappresentano anche gli indici che costituiscono i possibili percorsi di navigazione dell'utente finale:

a) persone citate nelle lettere;
b) testi citati e manoscritti realizzati dalla scuola di Vespasiano;
c) lessico tecnico della copia e del commercio librario.

A livello di markup è semplice rappresentare, attraverso adeguati elementi e attributi, questo tipo di dati. Gli esempi che seguono mostrano l'impiego della TEI P5 con riferimenti a file in formato RDF.

a) Persone - tag <persname>
Identificazione dei nomi così come compaiono nella lettera attraverso una sigla che permette di disambiguare tutte le forme varianti dello stesso nome attribuendo un codice identificativo univoco (#iniziale del nome e iniziale del cognome):

<persname ref="people.rdf#PS">Piero Strozi</persname>
<persname ref="people.rdf#FT">Pipo</persname>
<persname ref="people.rdf#VdB">Vespasiano di Filippo</persname>
<persname ref="people.rdf#PdM">Piero di Chosimo de' Medici</persname>

b) Codici manoscritti - tag <bibl> con elementi author e/o title
Identificazione di autori e testi così come compaiono nella lettera attraverso una sigla, cioè un codice identificativo univoco (#iniziale del nome dell'autore_iniziale del titolo dell'opera_eventuale numero del libro):

<bibl ref="manuscripts.rdf#P_SN>
<author>Prinio</author>
</bibl>

<bibl ref="manuscripts.rdf#L_D_III">
<title>Decha</title>
</bibl>

<bibl ref="manuscripts.rdf#L_D_IV_E">
<title>abreviationi</title>
</bibl>

c) Termini tecnici - tag <term>
Identificazione di parole tecniche così come compaiono nella lettera attraverso una sigla, cioè un codice identificativo univoco (#abbreviazione):

<term type="binding" ref="lexicon.rdf#leg">legaranno</term>
<term type="illumination" ref="lexicon.rdf#min">minî</term>

Il markup TEI ci consente quindi di identificare: nomi propri (<persname>), codici manoscritti citati (<bibl>) e relativi autori (<author>) e titoli (<title>), lessico tecnico (<term>) relativo a vari e diversi ambiti (@type="writing|support|binding|illumination|format|philology|cost").

Il valore dell'attributo @ref (reference) aiuta una prima identificazione delle stringhe presenti all'interno del documento, puntando ad una descrizione dell'elemento conservata in un luogo (in una porzione [identificata da #] di un file) esterno al documento stesso. Nello specifico sono stati creati 3 diversi file .rdf: uno per le persone (people.rdf), uno per i codici manoscritti (manuscripts.rdf) ed un altro per il lessico (lexicon.rdf). Diremo che il valore di @ref è un URI (Uniform Resource Identifier) relativo, un identificativo univoco che punta ad una entità conservata in uno dei tre repositories esterni (people.rdf, manuscripts.rdf, lexicon.rdf). Utilizzando il meccanismo degli URIs è possibile creare collegamenti fra il contenuto della lettera ed informazioni descrittive sulle stringhe annotate, conservate in documenti esterni. Il valore dell'attributo @ref, quindi l'URI, è un collegamento alla descrizione formale di quella stringa annotata: per esempio il valore, vale a dire l'URI, people.rdf#PdM punta alla specifica sezione (#) del file people.rdf dove Piero de' Medici, identificato con PdM, viene descritto (cfr. infra).

Se il meccanismo degli URIs ci dà modo di identificare univocamente ogni stringa, e di collegarla ad un documento esterno in cui quella stringa viene descritta, è necessario prevedere un sistema per adempiere al compito primario dell'edizione: costruire relazioni fra gli elementi annotati dotati di un URI. Questi collegamenti devono essere in grado di rispondere a domande del tipo: che relazione esiste fra 'Piero de' Medici' (people.rdf#PdM) e uno specifico esemplare delle Storie Naturali di Plinio (manuscript.rdf#P_SN)? E quale relazione esiste fra lo stesso manoscritto (manuscript.rdf#P_SN) e la parola 'legaranno' (lexicon.rdf#leg)?

Ma il modello dovrebbe essere in grado di rispondere anche a domande del tipo: quale esemplare delle Storie Naturali è stato realizzato (qual è la sua segnatura odierna) e in quale biblioteca è ad oggi conservato? Chi l'ha copiato? Chi l'ha miniato? Chi è Piero de' Medici?

Per rispondere al primo set di domande (cfr. infra) è necessario aggiungere semantica alla descrizione del documento. Non è sufficiente quindi classificare le stringhe come persone, codici manoscritti o lessico, ma esprimere formalmente, ed in modo processabile dalla macchina, informazioni aggiuntive sulle stringhe e descrivere le relazioni. Il linguaggio RDF dà la possibilità di esprimere asserti, sotto forma di triple (soggetto, predicato, oggetto) che permettono di esplicitare relazioni fra le stringhe identificate attraverso gli URIs.

Per il secondo set di domande (cfr. infra) è necessario creare collegamenti fra l'edizione e risorse su WWW capaci di estendere la descrizione degli elementi annotati. Questo significa agevolare il dialogo fra URIs interni all'edizione e URIs esterni correlati, come vedremo, avvalendosi dei predicati ontologici in uso nei principali modelli concettuali esistenti.

L'informazione esterna: i file RDF

Una volta che il testo è stato annotato prevedendo forme di dialogo con oggetti esterni è necessario comprendere come esprimere attraverso URIs e RDF le relazioni interne e quindi capire come realizzare i file RDF. Con gli URIs è possibile una prima identificazioni univoca di stringhe riconducendole ad una forma accettata. Con RDF è possibile esprimere le relazioni fra gli elementi dotati di un URI. Ma non solo. Ogni elemento dotato di identificazione può intrattenere una relazione di un qualche tipo con una stringa, sia essa un valore letterale o un altro URI.

a) Persone = people.rdf <rdf:description rdf:about="URI">
Le persone possono avere diverse proprietà dedotte dal testo ed essere messe quindi in relazione con i codici menzionati.

Identificazione univoca (frammento di URI): #PdM
Normalizzazione del nome (entry per un'authority record o definizione di un'access key): Medici, Piero de'
Forme varianti del nome (estratte in automatico per condivisione dell'URI): Piero, Piero di Cosimo de' Medici, Principe di Firenze
Relazioni con codici manoscritti: possessore-di: Plinio, Storie Naturali; Livio, Decadi (III e IV Deca comprese Epitomi)

In linguaggio formale possiamo esprimere questi concetti come relazioni attraverso i seguenti asserti (SOGGETTO PREDICATO OGGETTO):

people.rdf#PdM has_normalized_form Medici, Piero de'
has_variant_forms Piero, Piero di Cosimo de' Medici, Principe di Firenze
is_owner_of manuscripts.rdf#P_SN
is_owner_of manuscripts.rdf#L_D_III
is_owner_of manuscripts.rdf#L_D_IV_E

Possiamo quindi associare ad ogni stringa identificata nel documento con <persname> diversi tipi di proprietà: un identificatore univoco (definito attraverso un URI); alcune caratteristiche estratte dal documento stesso (forme varianti del nome); altri elementi dedotti da repertori condivisi (la forma accettata o normalizzata dei nomi); altre proprietà dedotte dalla lettura del documento (la relazione fra la persona e un codice).

Un primo passo verso l'interoperabilità è quello di collegare l'URI definito internamente con l'identificatore univoco stabilito in altri progetti e riferito allo stesso contenuto. Riferendo il nostro URI analogo (OWL:same-as) all'identificatore utilizzato in progetti come VIAF, che stabilisce le forme controllate dei nomi, è possibile far dialogare le risorse e creare collegamenti con altri sistemi standard come LCA e MARC (cfr. infra).

b) Codici manoscritti = manuscripts.rdf <rdf:description rdf:about="URI">
Allo stesso modo i codici possono essere identificati attraverso un URI e normalizzati utilizzando repertori specifici . Andranno poi ovviamente posti in relazione con le persone con le quali quei codici sono in qualche modo collegati.

Identificazione univoca (frammento di URI): #P_SN
Normalizzazione: Plinio, Storie naturali
Relazioni con persone (possessore, copista, miniatore, richiedente)
richiesto-da: Piero de' Medici
posseduto-da: Piero de' Medici
copiato-da: Piero Strozzi
miniato-da: Filippo Torelli

In linguaggio formale possiamo esprimere questi concetti come relazioni attraverso i seguenti asserti (SOGGETTO PREDICATO OGGETTO):

manuscripts.rdf#P_SN has_normalized_form Plinio, Storie naturali
is_requested_by people.rdf#PdM
is_owned_by people.rdf#PdM
is_copied_by people.rdf#PS
is_illuminated_by people.rdf#FT

c) Termini tecnici = lexicon.rdf <rdf:description rdf:about="URI">
Anche i termini tecnici, dotati di un URI, andranno normalizzati e posti in relazione con i codici a cui si riferiscono.

Identificazione univoca (frammento di URI): #min
Normalizzazione miniare:, miniatura, miniato
Relazioni fra il lessico e il codice a cui il lessico si riferisce: relativo-a Epitomi della IV Deca di Tito Livio

In linguaggio formale possiamo esprimere questi concetti come relazioni attraverso i seguenti asserti (SOGGETTO PREDICATO OGGETTO):

lexicon.rdf#min has_normalized_form miniare, miniatura, miniato
is_referred_to manuscripts.rdf#L_D_IV_E

I collegamenti con il WWW: la base di conoscenza

Diremo che il framework RDF, come mezzo per esprimere asserti, associato all'ontologia, come concettualizzazione di un dominio, sono strumenti finalizzati alla rappresentazione della conoscenza implicita dell'editore critico.

Costruire un'ontologia significa non solo usare linguaggi formali come XML e RDF, ma anche stabilire classi, definire proprietà, nella forma dei predicati, ed esprimere valori associati a quelle proprietà, rispetto al dominio di analisi. Nell'edizione le tre categorie sulle quali abbiamo ragionato (persone, termini tecnici e codici manoscritti) sono tre possibili classi di un'ontologia di dominio, dotate di proprietà (i predicati) e relativo valore (gli oggetti). Ogni istanza della nostra classe identificata in modo univoco (il soggetto identificato attraverso URI) intrattiene relazioni di varia natura (le proprietà che diventano predicati), con altre istanze (i valori delle proprietà che diventano oggetti) che possono essere dei valori letterali o a loro volta delle entità dotate di identificativi univoci (vedi asserti nella sezione precedente). Passiamo quindi dall'edizione come classificazione e categorizzazione degli elementi annotati (il markup) alla rappresentazione di concetti (l'ontologia) che trasformano il testo in una base di conoscenza.

Il passaggio dall'elemento marcato alla classe a cui può essere riferito consente una prima generalizzazione dell'appartenenza di una stringa ad un dominio semantico. La costruzione di relazioni fra le classi permette di realizzare un modello che può consentire il recupero di informazione strutturata. Non solo potrò ricercare singole stringhe, ma potrò interrogare la mia edizione alla ricerca di concetti: chi ha miniato un certo codice? chi è il possessore di un certo manoscritto? Ogni istanza di ciascuna classe avrà un contenuto determinato dal contesto in cui compare e sarà portatrice di informazione specifica per il dominio di riferimento.

Ma un'edizione non è conoscenza fino a quando rimane isolata ('siloed') e fino a quando non è in grado di dialogare con altre edizioni. Due sono quindi gli aspetti che ci interessano. Come trasformare l'edizione in un sistema interoperabile e come far dialogare l'edizione con il Web.

Scegliere predicati ontologici ad hoc per il tipo di progetto limita l'interoperabilità. Un generico predicato is_related_to, proprietà abitualmente utilizzata per collegare due elementi, è stato trasformato nel nostro esempio in una pluralità di relazioni che spaziano dalla forma normalizzata del nome (has_normalized_form) alle forme varianti (has_variant_forms), dal collegamento fra una persona e un codice (is_illuminator_of) a quello fra un codice e il lessico utilizzato per descriverla (is_described_by). Nulla ci impedirebbe di estendere le relazioni alle date e ai luoghi, tanto per fare un esempio. Per garantire massimo interscambio dell'edizione e quindi dell'ontologia andrà realizzato un mapping fra il modello usato e le principali ontologie esistenti nel dominio umanistico, sia a livello di classi che di proprietà. FRBR, DC terms, SKOS, EDM e CIDOC-CRM sono alcune fra le ontologie che si stanno studiando, per stabilire forme di dialogo e di condivisione.

Ma l'informazione interna, rappresentata attraverso il markup, e l'informazione esterna, rappresentata attraverso RDF, devono poter dialogare anche con il mondo del Web. Se infatti persone, codici e lessico intrattengono relazioni interne al documento sono inevitabilmente anche in relazione con quanto è necessario per approfondire le istanze di ciascuna di queste categorie.
Sono quindi in fase di analisi possibili estensioni degli elementi delle descrizione e delle loro relazioni. Andranno stabilite relazioni fra l'URI interno al progetto e altri URIs necessari ad approfondire gli elementi della descrizione. Ovviamente anche in questo contesto andranno valutati i predicati più adeguati ad esprimere queste relazioni. Vediamo partitamente come estendere la descrizione di ciascuna delle tre categorie o classi.

PERSONE. Un'istanza della classe persona, oltre ad essere dotata di un URI e di forme varianti del nome, ha diverse proprietà generali: un luogo e una data di nascita e di morte, una biografia, elementi iconografici che la qualificano.

Esempio:
<rdf:description rdf:about="#LM">
Access_key: Medici, Lorenzo de'
Same-as VIAF permalink: VIAF ID
Biography: Wikipedia
Father-of: Piero de' Medici (people.rdf#PM)
Born-in: Firenze (place.rdf#Fi)
Died-in: Firenze (place.rdf#Fi)
Born-when: 1449 (date.rdf#1449)
Died-when: 1492 (date.rdf#1492)
Iconography: google-images
Un'ontologia come il CIDOC-CRM può essere uno strumento utile per creare relazioni fra persone, eventi, oggetti, luoghi e date.

CODICI MANOSCRITTI. Molti manoscritti menzionati sono codici ad oggi posseduti da numerose biblioteche europee. Alla forma normalizzata del nome, come desunta dai repertori, andranno allora associate la segnatura, l'indicazione dell'istituto di conservazione ma anche un'eventuale descrizione codicologica o la disponibilità dell'immagine digitale del codice o del suo full-text.

Esempio:
<rdf:description rdf:about="#PV">
Access_key: Plutarco, Vite Parallele
Shelfmark: Laur. Plut. 65, 26
Available-in: Biblioteca Medicea Laurenziana, Firenze
Described-in: OPAC BML
Item-in(image): TECA
Item-in (full-text): --
Un ontologia come FRBR potrebbe essere usata per descrivere la relazione fra il codice inteso come oggetto fisico, quindi l'item, dotato di una segnatura - che può includere anche diverse sue rappresentazioni o espressioni (file di testo, file immagine, audio o video) - e l'opera di cui il codice è una specifica manifestazione.

TERMINI TECNICI. Anche il lessico deve essere qualificato. I termini vanno quindi descritti e vanno stabilite relazioni con altri repertori.

Esempio:
<rdf:description rdf:about="#aF">
Access_key: Ad fragmenta
Definition: "Sistema di resa scrittorea opposto alla scrittura 'ad volumina'. […] (S. Rizzo, Lessico filologico degli umanisti, Roma, Edizioni di Storia e Letteratura, 1973, p. 196)".
Type-of: writing
Iperonym: scrittura
Synomin: pecia
Antonym: ad volumina
L'ontologia SKOS fornisce uno strumento per creare thesauri terminologici e stabilire collegamenti fra i termini utilizzati nel documento e gli stessi definiti in altri repertori (come ad esempio la rete lessicale WordNet).

Nell'ambito del Web semantico, quindi di modelli e linguaggi di rappresentazione della conoscenza, un ruolo importante, ormai da alcuni anni, ha assunto Linked Open Data come progetto e strumento per la gestione di collegamenti fra risorse e quindi per il trattamento dei link. Molti linked datasets sono già disponibili sul WWW e possono di conseguenza essere utilizzati in ogni progetto, cioè richiamati al fine di associare istanze dello stesso concetto. Molti URIs di risorse e molte asserzioni RDF sono quindi a disposizione della comunità, con lo scopo di favorire il dialogo e lo scambio fra progetti. Rappresentare le informazioni relative alle edizioni utilizzando il meccanismo degli URIs e le modalità espressive di RDF significa contribuire a popolare l'universo dei linked data sets, in una prospettiva di interscambio e interoperabilità.

L'edizione digitale diventa quindi una base di conoscenza che permette all'utente finale di reperire informazioni strutturate. Le relazioni latenti sono definite in modo formale, diventando oggetto di query. I commenti, che l'editore mette tradizionalmente in nota, sono espressi tramite RDF e predicati ontologici. Ogni elemento annotato è identificato in modo univoco. L'edizione digitale così realizzata entra in un processo di dialogo con altre risorse digitali correlate.

L'obiettivo della creazione di una base di conoscenza è duplice: da un lato garantisce l'interoperabilità dell'edizione, aperta allo scambio con altri repositories; dall'altro dà agli studiosi uno strumento (liste di autorità espresse in modo formale e accessibili tramite URIs) e un metodo (dal contenuto delle lettere all'informazione esterna e dalle informazioni esterne al testo) che possono essere utilizzati in situazioni e contesti diversi. Un modello che sfrutta le tecnologie del Web semantico per la rappresentazione della conoscenza e linked data per l'nterscambio.

Contributi critici sul tema:

Barbera M., Meschini F., Morbidoni C., Tomasi F., Annotating digital libraries and electronic editions in a collaborative and semantic perspective, in Proceedings of the 8th Italian Research Conference on Digital Libraries (IRCDL 2012) - Revised Selected Papers. Communications in Computer and Information Science (CCIS) 354, Heidelberg, Germany, Springer, 2012, pp. 45-56.
F. Tomasi. Digital editions between embedded markup and external representation. A case study: Vespasiano da Bisticci's Letters, in Dall'Informatica umanistica alle culture digitali, a cura di G. Crupi, F. Ciotti. Atti del convegno in memoria di Giuseppe Gigliozzi (Roma, 27-28 ottobre 2011), Quaderni Digilab. II, Sapienza Università Editrice, Roma, 2012, pp. 201-218.
F. Tomasi. L'edizione digitale e la rappresentazione della conoscenza. Un esempio: Vespasiano da Bisticci e le sue lettere, «Ecdotica» 2012, 9 (2013), pp. 264-286.
F. Tomasi. Le edizioni digitali come nuovo modello per dati d'autorità concettuali, «JLIS.it» 4.2 (2013).