Di Antonello Fabio Caterino – Marco Petolicchio

18 gennaio 2017 (Bimestre Gennaio-Febbraio 2017)

Polemiche letterarie del Cinquecento (PoLet500) nasce da una proposta presentata al XX Congresso dell’ADI (Associazione degli Italianisti), all’interno del panel Eterodossie e Rinascimento, e mira a schedare le tante, forse troppe querelle di argomento letterario che caratterizzarono il secolo sedicesimo.

Si è partiti dal presupposto che trattare in prospettiva unicamente diacronica un fenomeno sui generis quale la polemica letteraria – che in nessun caso può essere trattata come universo a sé stante – è praticamente impossibile, vista la frequente necessità di comparazioni e correlazioni tra le stesse. Anche una mera categorizzazione per tematiche (come quella tentata da Giovanni Laini, Polemiche letterarie del Cinquecento, Mendrisio, Stucchi, 1944) si è dimostrata davvero fallimentare, poiché spesso i temi si intrecciano, o – più banalmente – sono usati a mo’ di maschera per coprire le reali ragioni delle dispute. Si è quindi pensato – anche per facilitare il fruitore – a un supporto telematico, che permetterebbe indicizzazioni più complesse di semplici indici “cartacei”.

Ogni scheda contempla le seguenti voci: Cronologia, Argomenti, Protagonisti, Altri personaggi coinvolti, Sinossi della vicenda, Fonti storiche, Fonti epistolari, Fonti letterarie, Bibliografia e Autore della voce. Il rimando ai testi nella loro interezza avverrà – quando possibile – mediante collegamento a url esterna; altrimenti si provvederà a una trascrizione di servizio. Sempre se possibile, ogni riferimento a un autore rimanderà anche alla relativa entrata biografica.

Modello di archiviazione e schedatura dei dati

Il progetto PoLet500 prevede la redazione di un numero di schede stimato in via non definitiva nell’ordine di grandezza orientativamente compreso tra 100 e 500.
Una tale mole di dati, costituita da un numero variabile di entrate di natura bibliografica, storico-documentaria e critica, impone una considerazione a monte sul modello prescelto nella redazione degli oggetti testuali, sulla loro impalcatura nell’economia dello sviluppo del software e sulla necessità di scalarità, modularità e portabilità del progetto. Per garantire che tali necessità possano trovare una rispondenza nella struttura informatica si è optato per la scelta di fornire un livello di schedatura dei dati non elaborati, in cui i file sono costituiti da due sezioni: una intestazione dedicata all’elaborazione metatestuale – contenente campi quali autori, personaggi, cronologia, fonti bibliografiche e storico-letterarie – ed una testuale, destinata alla redazione di una sinossi dell’elemento in esame. L’adozione di una infrastruttura basata su file di testo non dipendenti da marcatura ha positive ripercussioni in termini di portabilità del progetto e nella formazione di archivi non strettamente dipendenti dall’engine di riferimento.

L’architettura informatica delle schede

La parte principale del lavoro è legato a quello della compilazione delle schede, ovvero i file contenenti i dati della polemica. Per ogni scheda è stato elaborato un modello informatico basato su file in formato Comma separated value (.csv) di due fogli, uno contenente i diversi campi utili alla schedatura:

• Cronologia della scheda

• Autore della scheda

• Personaggi coinvolti

• Argomenti

• Sinossi della vicenda

e l’altro dedicato ai riferimenti bibliografici e storico-letterari della vicenda, comprendente per ogni voce i seguenti campi:

• Tipologia di riferimento (Bibliografia/Fonte)

• Categoria (Articolo, Libro, Fonte epistolare ecc…)

• Autore, Titolo volume/saggio, Sede periodica, Città d’edizione, Editore, Anno

• Link URI alla risorsa, dove disponibile

Le schede, convertite in pagine web, presentano una tassonomia che connette tramite link di riferimento i vari campi, trasformando i dati in collegamenti ipertestuali interconnessi all’interno dell’archivio informatico.

Le schede in formato .csv vengono processate da un software scritto ad hoc e convertite in file testuali in formato Markdown (.md) composti da:

• Una intestazione in linguaggio YAML che comprende i campi principali, l’autore, i personaggi, gli argomenti ed i riferimenti bibliografici in formato tassonomico

• Un corpo di testo in cui è contenuta la sinossi della scheda

I file .md vengono processati lato-server attraverso template scritti in linguaggio TWIG: i dati vengono marcati in linguaggio HTML attraverso l’elaborazione di tali template da parte dell’engine in PHP. Si è optato per la scelta di una impalcatura basata su un Content Management System (CMS) di tipo flat-file: nessun tipo di database è necessario per il funzionamento del progetto, che risulta essere in buona sostanza un archivio composto da una collezione di pagine (le schede) riunite per tassonomie e dall’interazione dell’utente con i dati medesimi. Il software prescelto a fondamento del progetto è GravCMS, rilasciato con Licenza MIT (open source).

L’organizzazione del lavoro tra modularità e scalarità

L’intento principale di una simile architettura dell’informazione è quello di fornire un approccio altamente dinamico e scalare al progetto, fornendo delle pagine di output non dipendenti dall’engine di riferimento. L’adozione di formati di file non legati a software proprietari e l’adozione di licenze aperte appare come la proposta capace di rispondere alle esigenze di portabilità dell’archivio, non confinandolo all’utilizzo con le tecnologie più contingenti derivate dal’adozione di un dato software.

In tale ordine di idee si è cercato di configurare l’intero lavoro di schedatura attraverso un paradigma che seguisse la formattazione tipica dei file .csv: un numero fisso di campi per ogni oggetto testuale tali da fornire l’ossatura ipertestuale dell’archivio. La scelta di un sistema che non presenta di per sé database appare certamente innovativa e non priva di vantaggi, sia per i succitati motivi di portabilità e scalarità che per quanto riguarda la richiesta delle tecnologie necessarie al funzionamento su server e, dunque, i costi di gestione dello stesso. Così, il progetto si configura essere come una grande collezione di schede divise in collezioni basate su tassonomie di descrizione all’interno di ogni scheda, una sorta di archivio ipertestuale piuttosto che una base di dati completamente organizzata.

Tale approccio è altamente modulare ed aperto ad implementazioni nel corso del tempo tale che rende appetibile siffatta architettura per la costruzione del progetto informatico di PoLet500, dove un comitato preposto si occupa della redazione delle schede in maniera indipendente dalla elaborazione digitale delle stesse su server.

In tale maniera, parallelamente all’output in HTML5 [4], le schede vengono servite sotto forma di file in formato JSON ed XML nei dialetti RSS ed ATOM; il framework appare sufficientemente elastico da poter pensare a successive implementazioni in tale senso nei tempi futuri.

La necessità di modularità ed interoperabilità dei contenuti generati è assicurata dall’utilizzo di un Content Management System (CMS) ottimizzato sulle esigenze del progetto in esame. I successivi sviluppi della piattaforma in termini di incremento progressivo dell’infrastruttura designata – sia per quanto concerne l’adozione di nuovi standard in via di sviluppo successivi all’HTML5 [5], sia per quel che riguarda le tecnologie più recenti orientate ad un approccio definito progressive enhancement con il possibile sviluppo del progetto in formato webapp [6] – risultano compatibili con un’architettura del software basata sulla archiviazione di materiale di schedatura in formato testuale non marcato (markup): la separazione dei dati dalla presentazione degli stessi appare in linea con i più recenti paradigmi legati allo sviluppo di progetti destinati al web.

Tipi di informazione: dai testi ai dati

Come mostrato, un tale tipo di approccio alla gestione dell’archivio presenta una serie di vantaggi in termini di modularità e scalarità, dove i contenuti possono essere disponibili in diversi formati e sotto differenti modalità di indicizzazione, portando una risorsa di natura testuale ad essere interrogata e consultata in via telematica – estendendo quelli che sono i confini tipici di un oggetto testuale [2] -, e per possibili lavori di analisi e visualizzazione dei dati (data visualization) [3], in linea con le più recenti tendenze delle Digital Humanities, laddove con il termine dati ci si riferisce alla definizione di “[insieme di] informazione processabile” [1] .

Il presente progetto mira a fornire un output diversificato in conformità con il grado di utilizzo e la necessità di interrogazione da parte dell’utente, provvedendo alla compilazione lato server di parti di informazioni di natura metatestuale, atte a descrivere il contenuto dell’oggetto, in cui l’archiviazione di dati viene separata dal software di riferimento, consentendo una notevole flessibilità di utilizzo, di gestione e di implementazione future, non confinando i dati nello spazio di azione delle necessità più contingenti ed immediate rappresentate dall’opera di schedatura ma proiettando il progetto in una prospettiva di utilizzo il più possibile aperta a scenari e modificazioni future.

L’elaborazione di opportune descrizioni di dati (metadati) avviene tramite la generazione di template lato server a partire dai dati in forma testuale: in questo modo è possibile prevedere la possibilità di un numero considerevole di differenti formati di gestione dei dati, in dipendenza delle necessità che si verranno a creare e della risposta degli utenti e degli studiosi rispetto alle strategie d’implementazione dei piani redazionali ed informatici.

Il progetto, nato indipendente attualmente in costruzione, è raggiungibile al sito http://nuovorinascimento.org/polet500 (al suo interno è possibile consultare altresì la lista dei collaboratori ai lavori di schedatura), mentre il codice sorgente è attualmente disponibile su GitHub all’indirizzo https://github.com/p-marco/polet500/ [7].

Riferimenti e note

[1] Trevor Owens. 2011. Defining Data for Humanists: Text, Artifact, Information or Evidence?. Journal of Digital Humainities, vol 1, no. 1.

[2] Gino Roncaglia. 2010. La quarta rivoluzione. Sei lezioni sul futuro del libro, Roma-Bari, Laterza.

[3] Maureen Stone. 2009. Information Visualization: Challenge for the Humanities in Working Together or Apart: Promoting the Next Generation of Digital Scholarship (Washington, D.C. : Council on Library and Information Resources).

[4] W3C. 2014. HTML 5 – A vocabulary and associated APIs for HTML and XHTML, Recommendation, www.w3.org/TR/html5/ (ultimo accesso: 18/01/2017)

[5] W3C. 2016. HTML 5.1, Recommendation; www.w3.org/TR/html/ (ultimo accesso: 18/01/2017)

[6] W3C. 2016. WebApp Manifest, Living Document, www.w3.org/TR/appmanifest/, (ultimo accesso: 18/01/2017)

[7] Inoltre è stata attivata una pagina Facebook del progetto, raggiungibile all’indirizzo https://www.facebook.com/polet500/ , ed una app nativa per il sistema operativo Android è ora disponibile su Google Store.

---

---