Bit senza acidi / Acid-Free Bits

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  


Sottotitolo: Raccomandazioni per una letteratura elettronica durevole

Autori: Nick Montfort, Noah Wardrip-Fruin

Data di pubblicazione: giugno 2004

Articolo originale: ELO

 

Traduzione a cura del Gruppo Giada (2015)

 

 

Prefazione: Acid-Free Bits e il progetto PAD della ELO

Con la pubblicazione di Acid-Free Bits (versione 1.0) la Electronic Literature Organization (ELO) porta al pubblico problematiche che sono state dibattute sul sito ufficiale della ELO per almeno due anni. Il documento è un appello agli scrittori affinché agiscano in modo proattivo nell’archiviazione delle proprie creazioni e tengano presenti queste problematiche anche nell’atto della composizione.
Le destinazioni della letteratura a stampa – nei negozi, come nodo su Amazon, sullo scaffale di una libreria e infine in un canone condiviso – sono al momento così prevalenti che pochi scrittori cartacei riservano la dovuta attenzione al tema della consevazione. Non esistono simili destinazioni, comunque, per scrittori di letteratura nata digitale.

 

Il meglio che gli attuali archivi digitali sono riusciti a realizzare è una casa non per la letteratura, ma per le riviste accademiche. I file di testo collegati a elementi grafici sono conservati, non programmati; sono indicizzate solo le opere individuali e non quelle di network e il più avanzato uso della tecnologia consiste nel link ipertestuale. Abbiamo una grande mole di informazioni, ma pochissime strutture o contesti. Contrariamente alle aspettative, l’archivio elettronico non ha contribuito alla creazione e alla circolazione di scritti letterari. Gli scrittori di letteratura elettronica hanno dunque avuto bisogno, essenzialmente, di costruire il contesto per le proprie opere a un livello inimmaginabile nella stampa. Coloro che trascurano anche le più basilari problematiche relative alla conservazione scoprono molto presto il caos generato dall’obsolescenza tecnologica, non solo nelle singole opere, ma anche nelle connessioni tra testi, immagini e listati che sono cruciali per qualsiasi pratica letteraria duratura e condivisa da una comunità.

 

In risposta, il comitato ELO per la Conservazione, Archiviazione e Diffusione [in inglese PAD: Preservation, Archiving, and Dissemination. N.d.T.] della letteratura elettronica  ha commissionato a Nick Montfort e Noah Wardrip-Fruin la stesura di un appello rivolto direttamente agli autori, con l’auspicio che la componente creativa non si separi da quella curatoriale.

 

Acid-Free Bits dà inizio a una campagna, sia online che in forma di pamphlet, che si svilupperà in tre fasi. La seconda fase aggiungerà ulteriori spiegazioni riguardo ai metadati e agli standard comunitari, ai linguaggi da preferire nelle presentazioni e agli sforzi complementari relativi alla conservazione realizzati in tutto il mondo (come Archiving the Avant-Garde). Questa fase della campagna di conservazione intrapresa dalla ELO sarà indirizzata non solo agli autori, ma anche a editori, librai, sviluppatori di software e altri. La terza fase creerà, attraverso gli sforzi di archivisti e programmatori, una struttura base di standard e pratiche nonché di strumenti di implementazione per autori ed editori. Questo terzo stadio della missione dipenderà ampiamente dal sostegno di istituzioni e agenzie finanziatrici che andranno ad aggiungersi al continuo e coordinato contributo di autori singoli e membri della ELO.

 

I lettori noteranno che l’edizione per il web di Acid-Free Bits, realizzata attorno all’estate del 2004, è essa stessa un modello di standard e pratiche creato in un linguaggio non proprietario, aperto e basato sull’XML che facilita quel tipo di produzione eterogenea, istituzionale e composta di riferimenti incrociati che l’Organizzazione nel suo complesso, lavorando collettivamente, spera di realizzare nei prossimi mesi e anni.

 

Nel suo progredire, la campagna includerà un sito internet dove gli autori potranno accedere, comunicare e contribuire all’opera di conservazione con la consapevolezza di non star creando in un mondo isolato. In breve tempo, le problematiche identificate da Montfort e Wardrip-Fruin si espanderanno a un ambito chiave per la ricerca della ELO – ovvero X-Lit. X-Lit sarà una struttura XML per la rappresentazione e la migrazione di opere di letteratura elettronica (inclusi sia i contenuti sia i comportamenti dinamici). Potenziato da strumenti di implementazione, X-Lit sarà progettato in modo tale che autori, editori, archivisti, accademici e programmatori possano collaborare più facilmente nella conservazione e disseminazione della letteratura elettronica. Il concept per X-Lit e lo sviluppo di interpreti ed emulatori open-source realizzati specificamente per la letteratura elettronica sarà l’argomento della prossima pubblicazione della ELO, un Libro bianco scritto da Alan Liu.

 

Joseph Tabbi, a nome della commissione della ELO e del nucleo operativo della PAD.

1. Mantenere viva la letteratura elettronica

 

La letteratura elettronica non è composta da pagine stampate e rilegate. Lasciarla sullo scaffale non significa che sarà facile, o addirittura possibile, leggerla in futuro. Persino metterla in una camera blindata con temperatura, luce e umidità controllate non ne assicurerà la disponibilità.

 

Le nuove possibilità della letteratura elettronica vengono dal suo essere tanto software quanto documento, tanto macchina quanto testo. Perché la letteratura sia leggibile, i suoi meccanismi devono continuare a operare o devono essere sostituiti, poiché i cambiamenti nel contesto informatico complicheranno l’accesso a importanti opere di letteratura sul computer. Il contesto del computer include i sistemi operativi, le applicazioni, l’ambiente del network e l’interfaccia hardware – e questo contesto si evolve costantemente. Un’opera di letteratura elettronica scritta per un Macintosh negli anni Ottanta potrebbe essere illeggibile sui Mac nella sala computer di un liceo di oggi. Ma la letteratura elettronica può diventare illeggibile molto più velocemente, in quanto un aggiornamento alla versione successiva di un software di scrittura o di lettura può introdurre problemi inaspettati.

 

Certi approcci alla creazione di letteratura elettronica sono molto più indicati di altri per un’opera che possa dirsi duratura. Acid-Free Bits fornisce informazioni per aiutare gli autori a trovare modi per creare opere letterarie elettroniche durevoli, modi che si adeguino alle loro pratiche e ai loro scopi. Per spiegare perché tali informazioni vengono offerte, risponderemo prima a due domande cruciali:

 

Perché preservare la letteratura elettronica?

 

Se non vengono fatti sforzi consistenti ora, studenti, professori, autori e lettori non saranno più in grado di accedere a molte importanti opere di letteratura elettronica in futuro. Affinché la letteratura elettronica possa contribuire alla nostra cultura, è importante avere opere alle quali i lettori possano accedere in un secondo momento e che gli autori possano raccomandare agli altri, con una certa sicurezza, che l’opera sarà ancora disponibile in forma leggibile. Conservare e creare una letteratura elettronica che rimanga disponibile è essenziale per lo stesso concetto di letteratura elettronica, l’idea base che il computer possa essere un luogo per nuove opere letterarie che fanno uso delle sue funzionalità.

 

Chi dovrebbe preservare la letteratura elettronica?

 

La conservazione è sempre un lavoro collettivo. Essenzialmente, la conservazione della letteratura elettronica sarà il lavoro di un sistema di scrittori, editori, studiosi di letteratura elettronica, librai, archivisti, programmatori di software e informatici. Ma oggi, anche se un tale sistema è già operativo, le pratiche degli autori e degli editori determineranno se la conservazione di opere particolari sia relativamente facile o quasi impossibile. Lo scopo di questo saggio è aiutare scrittori di letteratura elettronica a compiere decisioni consapevoli riguardo alle loro pratiche. Ciò che gli autori fanno oggi non solo darà forma al futuro delle loro opere, ma aiuterà anche a dirigere il corso della letteratura elettronica nel suo complesso.

 

2. Acid-Free Bits – Bit senza acidi

 

Gli artisti che disegnano schizzi su carta da giornale acida generalmente sanno che, nel giro di alcuni anni, la carta che usano sarà fragile e scolorita, rendendo forse la loro opera illeggibile. Probabilmente solo pochi tra coloro che usarono le estensioni di HTML introdotte con Netscape 4 hanno realizzato che le loro opere potrebbero andare incontro a un destino simile.

 

Almeno l’HTML è conservato in testo non formattato ed è leggibile dall’uomo, così le persone possono vedere cosa contiene un file HTML anche se il browser speciale per il quale fu scritto non viene trovato facilmente. La situazione può essere peggiore per quegli scrittori che hanno usato sistemi pre-programmati (authoring systems) che producono file binari. Questi file potrebbero essere incomprensibili tranne che per programmi proprietari non più disponibili o per programmi che non funzionerebbero più sui sistemi operativi odierni, anche se se ne riuscisse a trovare una copia.

 

Certo, gli autori di letteratura elettronica potrebbero scegliere di lavorare con materiali che sono meno che durevoli, esattamente come gli scultori che scelgono di lavorare con il cartone o addirittura con il ghiaccio. Anche le performance sono per natura temporanee. Ma persino di tali opere temporanee spesso rimane molto di più rispetto a scritti elettronici che rimandano a un errore 404 (Not Found) o che non girano più su nessun sistema in circolazione. Gli scultori che usano il cartone potrebbero sempre fare i loro abbozzi preliminari su taccuini senza acidi. Le sculture di ghiaccio vengono fotografate. Anche una produzione di uno spettacolo da Off-Broadway lascia un copione, una locandina, delle fotografie, delle riviste e probabilmente una videocassetta nella libreria del Lincoln Center. È possibile apprezzare e imparare dalla documentazione di uno spettacolo conclusosi decenni fa. Al contrario, opere web della stessa epoca sono a volte conosciute solo grazie a brevi voci che restano in ristrette liste di siti preferiti.

 

Ci sono innumerevoli approcci diversi alla conservazione di un’arte nata digitale come la letteratura elettronica. Questa guida non è concepita affinché tutti gli autori adottino ogni approccio riportato. Né tanto meno si suppone che i consigli espressi servano a insegnare agli autori a essere i propri archivisti di media digitali. Si tratta piuttosto di delineare alcuni importanti principi che, se usati per guidare pratiche letterarie al computer, possono aiutare la letteratura elettronica a rimanere accessibile, funzionale e fruibile per i lettori futuri.

 

3. Come tutelare la letteratura elettronica

 

3.1 Conservare hardware vecchi per far funzionare sistemi vecchi

 

Questa è un’opzione costosa e difficile, ma che è stata già gestita in pochi luoghi con vecchie cabine di video giochi e altre opere storiche di arte elettronica. È uno dei modi in cui persone e istituzioni potrebbero conservare la letteratura elettronica nella sua forma materiale originale ma, anche se questo metodo avesse successo, solo coloro che visitassero l’hardware conservato sarebbero in grado di accedere all’opera.

 

3.2 Emulare o interpretare vecchi programmi su nuovi hardware

 

Emulatori e interpreti gratuiti hanno reso possibile il funzionamento di molti programmi più vecchi su computer moderni. L’emulazione e l’interpretazione permettono l’uso dei file originali di un’opera di letteratura elettronica, mettendo a disposizione meccanismi che fanno da ponte tra i formati del file originale e la piattaforma corrente. Finché rimane un qualche forte interesse per opere realizzate su certe piattaforme più vecchie, è molto probabile che la loro emulazione o interpretazione resterà un’opzione e nuovi emulatori e interpreti continueranno a essere sviluppati per nuove piattaforme. Al contrario, nel caso di piattaforme o programmi poco noti o di programmi particolarmente esigenti (ad esempio quelli che richiedono accesso al network o ad hardware speciali) questa opzione può non essere sempre realistica.

 

3.3 Migrare vecchi programmi e media in sistemi nuovi

 

È possibile rendere nuovamente funzionanti le opere di letteratura elettronica convertendo i programmi e i file di dati dal loro formato originale ai formati moderni. Questo tipo di migrazione è specifico per programmi e formati di dati particolari e, quando può essere effettuato, i risultati presentano vari gradi di fedeltà. In più, la conversione potrebbe rendersi necessaria diverse volte (dal formato originale a un formato del 1998, dal formato del 1998 a una piattaforma attuale e di nuovo in futuro) e ogni migrazione rischia di introdurre nuovi problemi. In questi casi il processo di migrazione diventa parte del modo in cui l’autore ha realizzato l’opera di letteratura elettronica ricevuta dagli attuali lettori, tenendo presente che la documentazione delle varie trasformazioni dovrebbe essere disponibile per i lettori.

 

3.4 Documentare i sistemi con le relative istruzioni per ricrearli

 

Anche se questa opzione non conserva la possibilità di interagire con un’opera di letteratura elettronica come poteva essere fatto originariamente, questa prassi spesso fornisce una maniera pratica alle persone di farsi un’idea di com’era un’opera di letteratura elettronica. Se la documentazione è meticolosa, potrebbe addirittura permetterne la ricreazione futura.

4 Principi per la creazione di opere durevoli

 

4.1 Preferire sistemi aperti a sistemi chiusi

 

Un sistema aperto è un sistema le cui dinamiche fondamentali sono pienamente e pubblicamente documentate; uno standard aperto è pubblicato e disponibile per chiunque. Coloro che usano sistemi aperti e aderiscono a standard aperti quando creano opere di letteratura elettronica hanno una possibilità molto più alta  che il formato delle loro opere letterarie sarà supportato o decifrabile in futuro. Il piccolo gruppo di persone responsabili di un sistema o di uno standard chiusi potrebbero perdere interesse e smettere di sviluppare il software oppure il piccolo gruppo potrebbe cambiare il sistema o lo standard senza avvisare, per cui opere di letteratura elettronica più vecchie non funzionerebbero più su nuove piattaforme (ciò è in particolar modo un rischio quando la letteratura elettronica non è lo scopo principale di un sistema che potrebbe essere cancellato incidentalmente.) Sistemi e formati aperti possono essere migrati ed emulati più facilmente dal momento che le loro specifiche sono pubblicamente conosciute. I sistemi chiusi sono decisamente più difficili da migrare ed emulare.

 

È vero che un sistema chiuso potrebbe fornire importanti possibilità che altrimenti non sarebbero disponibili e alcuni sistemi chiusi potrebbero essere molto adatti per il tipo di creazione letteraria a cui gli autori sono interessati; ci potrebbero cioè essere buone ragioni che inducono gli autori a usare un particolare sistema chiuso. Tuttavia essi dovrebbero essere consapevoli che tali scelte potrebbero avere effetti sulla longevità delle loro opere. Di conseguenza gli autori potrebbero desiderare di documentare simili progetti in modo più meticoloso.

 

 

4.2 Preferire sistemi comunitari a sistemi corporativi

 

Un sistema gestito da una corporazione, o proprietario, è un sistema nel quale le tecnologie sottostanti sono controllate da una corporazione, anche se potrebbero essere pienamente documentate e quindi aperte. PDF, Flash e Java sono alcuni esempi, anche se Sun (e in qualche misura anche Adobe e Macromedia) hanno preso provvedimenti per coinvolgere la comunità nello sviluppo di queste tecnologie. Per quanto ben documentata possa essere una tecnologia di un’opera di letteratura elettronica, ci sono specifici rischi che riguardano la longevità delle tecnologie di corporazioni che non esistono nei sistemi gratuiti e accademici. Il caso del software di scrittura multimediale mTropolis è esplicativo. La traballante compagnia mFactory Inc. che produsse questo software fu apparentemente salvata da un’acquisizione da parte della compagnia di desktop publishing Quark nel 1997, ma solo per essere chiusa l’anno successivo poco prima del rilascio dell’ultima versione di mTropolis.

 

Sistemi gestiti da corporazioni possono permettere migrazioni se la corporazione decide di fornire una funzione per la migrazione (nel regno dei sistemi corporativi proprietari, gli autori farebbero bene a preferire sistemi che consentono, opzionalmente, l’esportazione in un formato aperto.) In generale, comunque, i sistemi gestiti da comunità hanno una migliore e comprovata esperienza in termini di autorizzazioni di migrazioni ed emulazioni.

 

 

Approfondimento – Flash

Flash è un sistema usato per creare media e programmi interattivi solitamente destinati al web. Iniziò come strumento per sviluppare animazioni interattive scalabili. Si tratta di un sistema corporativo sviluppato da Macromedia Inc. che dirige il sistema e i suoi formati. I file di progetto (.fla) sono in un formato binario proprietario. I file per la distribuzione (.swf) sono in un formato binario documentato pubblicamente. Questi file .swf possono essere generati e analizzati da prodotti della Macromedia (inclusi plugin per browser) e da altri software, come i prodotti Quicktime della Apple. Flash è stato largamente adottato e offre funzionalità che sono essenziali per alcune pratiche di autori di letteratura elettronica. Tuttavia noi sconsigliamo l’uso di Flash per creare elementi che possono essere creati facilmente in sistemi aperti non proprietari come immagini fisse e finestre di testi con barre di scorrimento. Per i progetti in Flash (o in qualsiasi altro formato) che richiedono una finestra browser con certe caratteristiche, è consigliabile che la pagina di lancio in grado di creare una tale finestra venga archiviata direttamente insieme all’opera piuttosto che fuori in una tabella di contenuti posta in una directory diversa. Formati più conservabili rispetto a Flash potrebbero rivelarsi molto utili in futuro; un candidato è SVG,  formato vettoriale scalabile (Scaling Vector Format) applicazione di XML. L’articolo Macromedia Flash Considered Harmful (J. van Baal, 2007) riporta delle argomentazioni contro l’uso di Flash in siti web accessibili, mentre Is ‘Open’ and ‘Shut’ Really Open-and-Shut? è una risposta di Macromedia a tali argomentazioni.

 

 

4.3 Consolidare il codice, fornire commenti

 

Idealmente, lo stesso bit di codice dovrebbe esistere in un unico posto in un progetto di letteratura elettronica. Per esempio, sin dall’avvento di Actionscript 2, lo stesso codice Flash può essere conservato in diversi luoghi all’interno dell’ambiente di programmazione o in una singola dichiarazione di funzione di una classe editabile dall’esterno; quest’ultima opzione semplifica l’individuazione e la migrazione del codice. Centralizzare il codice ed eliminare le duplicazioni è anche una buona pratica di ingegneria del software e di programmazione e porta benefici durante lo sviluppo. Purtroppo, a partire da questo scritto, programmi come Dreamweave incoraggiano esattamente la pratica opposta, collocando di default lo stesso codice ridondante in ogni file HTML di un progetto web che utilizza le medesime funzione in più pagine.

 

Il codice dovrebbe anche includere commenti, non solo per il bene degli archivisti, ma anche perché, in tal modo, persino gli autori originali potranno attribuire un senso al codice in futuro. I commenti dovrebbero spiegare, ad esempio, come è usata ciascuna variabile dichiarata e dovrebbero chiarire non solo cosa si sta facendo (cosa che può essere dedotta ispezionando il codice) ma anche perché lo si sta facendo (che raramente è così ovvio).

 

 

4.4 Convalidare il codice

 

Il codice del computer, sia esso scritto con un linguaggio di programmazione, un linguaggio di marcatura  o un linguaggio per la presentazione di documenti come il CSS, può essere “valido” o “non valido”, indipendentemente dalla correttezza del suo funzionamento. Valido significa che il codice è stato realizzato in una forma corretta – esso è in effetti HTML o Java o qualsiasi altro linguaggio si suppone che sia. Nel linguaggio ordinario delle equazioni matematiche, per esempio, “2+2=5” è un’equazione valida (sbagliata, ma scritta in una forma corretta), mentre “=4” non è un’equazione valida, perché non contempla due espressioni.

 

La definizione formale di HTML (o XHTML) è nascosta per la maggior parte delle persone che scrive e legge pagine web e vede, molto più rapidamente, che una pagina viene ben visualizzata in un particolare browser. Questo non significa che la pagina funzionerà correttamente in ogni browser. I web browser cercano di essere gentili: essi mostrano correttamente alcune pagine anche se non sono scritte in un HTML valido. Di conseguenza un browser non serve da validatore in quanto non assicura che una pagina sia valida.

 

Convalidare una pagina o sito web, usando un servizio come il W3C Validator o il validatore costruito con l’editor di testi BBEdit, assicura che tutti i browser che si attengono agli standard del World Wide Web Consortium, ora e in futuro, interpreteranno correttamente la pagina. Non tutti i browser sono completamente conformi agli standard, ma offrono comunque garanzie migliori rispetto a quelle che derivano dal semplice controllo di una pagina in un browser o anche in una manciata di browser.

 

Questo principio si applica anche ad altri tipi di linguaggi, ma la validità è più ovvia con linguaggi di programmazione compilati: un programma Java non valido, ad esempio, non compilerà; in tal modo l’autore/il programmatore è avvertito fin da subito di questo problema.

 

 

 

Approfondimento – Inform

Il sistema Inform è composto da un compilatore e da librerie per la realizzazione di narrativa interattiva. Il sistema è stato finanziato e sostenuto dal suo creatore, Graham Nelson, con l’aiuto di numerosi contributi comunitari. I file Inform (.inf), scritti in ASCII, possono essere compilati in uno dei due formati binari: Z-Machine (.z5, .z8) o Glulx (.ulx). Il linguaggio Inform è uno standard aperto. Entrambi i formati binari sono aperti e multi-piattaforma. Il codice sorgente è disponibile per interpreti che leggono sia il formato Z-Machine che il Glulx. Per ulteriori informazioni sul sistema Inform rimandiamo al Manuale The Inform Designer’s Manual. Inform è una componente essenziale di un sistema di narrativa interattiva aperto e generalizzato. Se i file multimediali Inform/Glulx possono non funzionare perfettamente su diverse piattaforme, le narrazioni interattive realizzate con Inform/Z-Machine hanno funzionato bene su numerose piattaforme per decenni e ci sono ottime possibilità che restino accessibili.

 

 

4.5 Preferire formati di puro testo a formati binari

 

Un formato di puro testo (plain-text format), ovvero contenente del testo non formattato, come l’HTML (ma anche l’XML, l’XHTML o l’SVG) può essere modificato, letto e analizzato su diverse piattaforme. Questa accessibilità rimane persino quando il programma che lo ha creato, o il programma che era stato concepito per interpretarlo, non è più disponibile (o esiste in una versione radicalmente diversa e incompatibile). I contenuti di un file di puro testo rimangono accessibili anche se la documentazione del formato del file non è disponibile. Questa accessibilità è del tutto assente nei formati binari come i primi formati Microsoft Word, che non possono essere modificati o letti senza la conoscenza della struttura del file (che può non essere pubblica) e senza un programma dedicato. La versione compilata di un’opera potrebbe essere in un formato binario per via della natura dell’opera, ma è ragionevole aspettarsi che il codice sorgente sia scritto in puro testo.

 

 

4.6 Preferire opzioni di multi-piattaforma a opzioni di sistemi singoli

 

Per ragioni di conservazione e di adeguamento agli standard moderni di accessibilità, è bene che l’opera possa funzionare su diversi computer e numerosi sistemi operativi diversi.  Su cinque sistemi diversi si potrebbe, dopo anni, facile trovarne solo due e questi due potrebbero non essere quelli che potevano sembrare le piattaforme più ovvie e dominanti. Un’opzione per il solo Windows è raramente una buona scelta quando esistono sistemi con funzionalità simili che girano su Windows, Mac e Linux.

 

 

4.7 Tenere in mente l’intero sistema

 

Se un hardware non comune (ad esempio una tavoletta grafica) è parte di un’opera di letteratura elettronica, conservazione significa preservare la possibilità di usare questo hardware con il sistema. Se il progetto dovrà essere fruito direttamente in futuro, la piattaforma da usare dovrà avere un driver per questa tavoletta grafica e lo stesso hardware, o uno simile, dovrà essere disponibile nel futuro. Se invece viene usato un emulatore, esso dovrà fornire un modo per emulare le capacità della tavoletta grafica originale. Conservare l’opera significa preservare l’intero sistema che ne consente il funzionamento. Fornire al sistema strumenti alternativi per funzionare può aumentare le possibilità per i futuri lettori. Per un sistema che dipende da un particolare ambiente di network, strumenti alternativi potrebbero includere un archivio (cache) dei file del formato che il sistema si aspetta di trovare nel network in modo che questi possano essere usati se la risorsa del network non sarà più disponibile in futuro. Un’opera che impiega video dal vivo, ad esempio,  potrebbe includere una serie di file video del tipo che il sistema si aspetta di trovare e che può essere usata nel caso in cui una telecamera o un driver che producono file di questo tipo non siano  disponibili.

 

 

4.8 Documentare presto, documentare spesso

 

La documentazione di un sistema può consistere semplicemente in alcuni screenshot che illustrino a grandi linee l’esperienza; anche se ciò fornisce un’indicazione non proprio ottima di come abbia funzionato un sistema complesso, questa documentazione è meglio che niente. È molto più facile  catturare schermate simili mentre l’opera è ancora in corso ed è ancora più facile catturarle subito dopo che l’opera è stata completata. Se un’opera passa attraverso molte versioni, è bene conservare delle tracce di tali versioni, documentare l’aspetto originale dell’opera e chiarire di volta in volta quale versione è stata distribuita o pubblicata. Allo stesso modo, estrarre i testi inseriti nel sistema e conservarli come testi puri, senza formattazione, alla fine del processo di revisione, di solito è relativamente semplice e può apportare, in fasi successive, inestimabili vantaggi. Una documentazione più estesa – per esempio relativa al processo di interazione e alle possibilità per la generazione di contenuti – potrebbe non essere così semplice da assemblare. Tuttavia una simile documentazione è caldamente consigliata nel caso di un’opera che si avvale di sistemi a rischio conservativo (ad esempio i sistemi proprietari chiusi o quelli che dipendono da una risorsa di network particolare o da un hardware speciale). Come per molte opere d’arte interattive e  per le performance, la documentazione potrebbe essere tutto ciò che rimane di un’opera innovativa di letteratura elettronica.

 

 

4.9 Conservare i file sorgente

 

Molti ambienti di sviluppo e programmazione usati nella creazione di opere di letteratura elettronica generano file “sorgenti” (source) o file “di progetto” (project) oltre ai file destinati alla fruizione finale a parte dei lettori. Come è stato illustrato nel precedente approfondimento, Flash crea sia file progetto “.fla” sia file di consegna (delivery file) “.swf”. Photoshop genera sia file “.psd” (che conservano i livelli, la storia delle versioni e così via) sia file di consegna in formati come PNG, JPEG e TIFF. Molti ambienti di sviluppo di software in realtà generano tre tipi di file: i file progetto (che conservano la storia e altre informazioni specifiche di quell’ambiente), i file sorgente (che contengono solo il testo della versione corrente del programma) e i file eseguibili (il codice binario compilato della versione corrente per la fruizione da parte del lettore). In ogni caso, anche se le dimensioni dei file sorgente e dei file progetto sono di solito significativamente più grandi di quelli di consegna, gli autori sono incoraggiati a conservare anche i primi due per i componenti della loro opera di letteratura elettronica. Idealmente, tali file dovrebbero essere archiviati e copiati con l’opera stessa e dovrebbero essere ben organizzati ed etichettati in modo appropriato. Mettere a disposizione più copie agli editori può rivelarsi di grande aiuto nel caso di perdita accidentale di un file sorgente. La possibilità di effettuare piccole modifiche al codice sorgente o di esportare immagini in diversi formati potrebbe facilitare di molto il raggiungimento di una accessibilità continua nel tempo. Inoltre gli autori e gli editori potrebbero apprezzare la possibilità di effettuare piccole modifiche senza dover riprodurre da capo tutti gli elementi che compongono l’opera.

 

 

4.10 Utilizzare strumenti d’uso comune e funzionalità documentate

 

Alcuni degli strumenti usati dagli autori di letteratura elettronica sono di uso comune. Questi includono prodotti commerciali come Flash e Photoshop e strumenti open source o sviluppati da comunità come l’ambiente di sviluppo Eclipse e il linguaggio di programmazione Inform. Quando autori ed editori conservano i file sorgente creati da strumenti come questi, è molto più probabile reperire in futuro software compatibili che consentiranno l’apertura e la modifica di tali file. Alcuni autori potrebbero scegliere di lavorare con strumenti meno comuni che potrebbero necessitare di funzionalità non offerte dai software più diffusi. L’utilizzo di strumenti meno noti crea, peraltro, un ulteriore onere per gli autori: per sviluppare o modificare le loro opere, gli autori sono obbligati a  conservare una versione di questo software che funzioni di pari passo con i cambiamenti tecnologici. Ciò può richiedere che gli autori agiscano da esperti della conservazione per mantenere l’accesso ai loro stessi strumenti di sviluppo.

L’utilizzo di funzionalità non documentate nei programmi di lettura o di sviluppo rende ancora più alto il rischio di ridurre la disponibilità di lettura di un’opera. Creare effetti usando funzionalità non specificate in una documentazione di un sistema può contraddistinguere un’opera di letteratura elettronica, può essere un’interessante esplorazione delle modalità operative del sistema ed è persino una parte di certe tradizioni legate al computer (come nel caso di Demoscene). 

 

Tuttavia coloro che usano simili tecniche dovrebbero essere consapevoli che è poco probabile che gli sviluppatori di piattaforme mantengano funzionalità non documentate nelle versioni future e gli hardware emulati raramente supportano funzionalità non documentate di sistemi precedenti. Avvalersi di simili funzionalità non è una mossa che incrementi la compatibilità e l’accesso futuro a un’opera. Inoltre, tale pratica richiede un maggiore sforzo nella documentazione o la costosa conservazione della piattaforma originale.

 

 

Approfondimento – The Connection Muse

 

The Connection Muse (Robert Kendall e Jean-Hugues Réty, 2006) è una libreria di codice JavaScript concepita per facilitare lo sviluppo di opere letterarie ipertestuali complesse progettate per il web che si avvale dei principi degli ipermedia adattabili. Il sistema è aperto e gratuito e può essere usato dall’interno di Dreamweaver, utilizzando un set di strumenti per browser o inserendo manualmente il codice JavaScript reperito nella libreria. Per ulteriori informazioni sul sistema si rimanda all’articolo Toward an Organic Hypertext (Robert Kendall e Jean-Hugues Réty, 2000). Offrendo un’interfaccia all’interno di Dreamweaver senza tuttavia richiedere alcun software proprietario, The Connection Muse garantisce una elevata facilità di utilizzo aderendo al contempo agli standard (JavaScript, originalmente un linguaggio proprietario, è stato standardizzato come ECMAScript) e svincolandosi da qualsiasi tipo di sistema proprietario. Gli script di The Connection Muse hanno un’ottima prospettiva di rimanere operativi.

 

 

4.11  Conservare metadati e informazioni bibliografiche

 

Gli autori possono conservare informazioni essenziali sulle loro opere digitali senza grandi sforzi aggiuntivi. Conservando il file originale e le varie modifiche quando si effettuano i back up dei file può aiutare gli autori a capire a quando risalgono la prima realizzazione o la modifica più recente delle varie opere di letteratura elettronica e dei loro componenti. Può anche essere d’aiuto conservare informazioni chiave (autore o autori, date, sistemi sui quali si è appurato che l’opera funzioni) in un file di puro testo nella stessa cartella dell’opera. Coloro che usano formati (come HTML, XML o la maggior parte dei linguaggi di programmazione) che consentono l’inserimento di tali informazioni nei commenti, possono conservare simili metadati in un formato di puro testo all’interno degli stessi file dell’opera di letteratura elettronica, diminuendo la probabilità che essi vengano inavvertitamente separati dall’opera. Conservare i numeri delle varie versioni può anche aiutare a distinguere tra diverse incarnazioni di un’opera di letteratura elettronica, ad esempio tra i lavori  in corso sulla scrivania di un autore e quelli pubblicati in diversi luoghi.

 

Gli autori sono inoltre invitati a inviare le informazioni relative alle loro opere alla Electronic Literature Directory, che assicura che le informazioni bibliografiche essenziali saranno registrate e conservate nella Directory.

 

4.12 Consentire e incoraggiare la duplicazione e la ripubblicazione

 

Gli autori che tengono solo per sé l’unica copia di un’opera di letteratura elettronica stanno riducendo la probabilità che quest’opera sopravvivrà. Editori commerciali di letteratura elettronica, tra cui la Eastgate Systems e la successiva Voyager, duplicano le opere degli autori; un risultato è che molte copie fisiche sono disponibili ed è più probabile che alcune di queste perdureranno. Un’altra alternativa consiste nel fornire le opere in rete, gratis e nell’incoraggiarne lo scaricamento e la copia esatta (mirror) rendendo i file disponibili su diversi siti. Questa non è necessariamente un’alternativa in senso stretto, poiché è possibile vendere media fisici commerciali e anche rendere disponibile la componente digitale gratis, come fanno i distributori Linux e come hanno fatto alcuni artisti e scrittori. Quando riviste letterarie online pubblicano opere di letteratura elettronica e le ospitano sui propri siti internet non solo ne incrementano l’accesso oggi, ma aumentano anche la probabilità che la letteratura che ospitano sarà in circolazione in futuro.

 

4.13 Conservare copie in media diversi e durevoli

 

Soluzioni d’archiviazione che sembravano promettenti alcuni anni fa (come i back up su nastro) possono sembrare meno promettenti oggi (quando i lettori CD-ROM sono ovunque, ma  le unità nastro sono rare). Un modo per aiutare la letteratura elettronica a durare nel tempo è effettuare il back up dei file essenziali in molti modi diversi. Quando eseguono il back up su unità a nastro, gli autori possono anche copiare i file su una unità di disco rigido di un altro computer, masterizzarli su CD-R e trasferire almeno i file più importanti in un sistema di network per i quali qualcun altro conserverà  i back up (come ad esempio un network universitario).

 

5 Uno sguardo al futuro

 

Sopra sono stati delineati alcuni principi che gli autori possono seguire per migliorare le prospettive future delle loro opere di letteratura elettronica. Tuttavia, i sistemi e gli standard impiegati per opere letterarie elettroniche sono raramente “senza acido” come vorremmo. Il progetto a lungo termine PAD della ELO sta tentando di migliorare la longevità della letteratura elettronica lavorando su altri livelli. Il progetto guarda indietro verso alcune delle nostre prime e più importanti opere di letteratura elettronica e guarda avanti per provare a stabilire pratiche, strumenti e metodi di archiviazione migliori per mantenere leggibile la letteratura elettronica. Acid-Free Bits inizia pubblicamente questa missione.

 

A continuare questo tentativo vi è un’iniziativa del progetto PAD della ELO chiamata X-Lit. L’iniziativa X-Lit coinvolge lo sviluppo di una ricca rappresentazione della letteratura elettronica in linea con i principi descritti in questa sede, un tipo di letteratura che sia leggibile dall’uomo e fruibile su macchina a lungo in futuro. X-Lit permetterà la rappresentazione di elementi multimediali (inclusi testo, grafica, audio e video) come anche una descrizione dei meccanismi interattivi e computazionali delle opere di letteratura elettronica. Lo standard fornirà inoltre un modo per documentare la disposizione fisica e gli aspetti materiali di un’opera di letteratura elettronica. X-Lit sarà un’applicazione dello standard aperto XML (eXtensible Markup Language) ed essa stessa sarà aperta e comunitaria. La pianificazione di X-Lit (e quella per l’iniziativa interprete complementare del progetto PAD) cerca di incrementare e integrare, piuttosto che replicare, i prodotti di iniziative correlate come Archiving the Avant-Garde, Variable Media Network, Open Archival Information System e Metadata Encoding and Transmission Standard.

 

Inizialmente X-Lit offrirà agli autori un modo standard e efficiente per documentare le proprie opere di letteratura elettronica. Servirà da descrizione, leggibile dall’uomo, di elementi di opere di letteratura elettronica e del modo in cui questi elementi interagiscono e operano, consentendo agli autori di documentare opere di letteratura elettronica di tutti i tipi in modo uniforme così che queste potranno essere capite o persino ricreate in futuro (in ogni caso, gli autori non dovrebbero aspettare X-Lit per occuparsi della documentazione delle loro opere; documentare un’opera ora, mentre è ancora funzionante o per come è sviluppata, renderà molto più facile codificarla in futuro nel formato standard X-Lit.) X-Lit fornirà anche un esempio per gli sviluppatori di software che stanno tentando di creare sistemi per una letteratura elettronica conservabile. Il progetto PAD lavorerà insieme agli autori per assicurarsi che X-Lit sia uno strumento utile e facile da utilizzare e al contempo lavorerà con gli sviluppatori di software così che gli autori saranno capaci di salvare le loro opere in formato X-Lit. Nel corso del suo sviluppo, X-Lit diventerà un formato aperto che potrà essere utilizzato dalle più svariate forme di applicazioni di letteratura elettronica, un formato in cui gli autori possano esportare o salvare e che potrà, in molti casi, essere direttamente lanciato e fruito. Una volta completamente realizzati, i sistemi compatibili con X-Lit forniranno agli autori non solo una documentazione, ma anche un formato duraturo e aperto per le loro opere, una nuova, potente e semplice opzione per seguire i principi tracciati in questo documento.

 

Gli autori dovrebbero abbracciare l’iniziativa già adesso; altre istituzioni avranno sicuramente bisogno di essere coinvolte a lungo termine. Sostenere la ELO mentre prosegue il progetto PAD diventando un membro e offrendo feedback e partecipazione è un importante modo per aiutare. Anche gli editori possono contribuire rendendo disponibili le opere pubblicate sui propri siti web su pagine con URL fissi, incorporando le informazione bibliografiche, catalogando le opere della Electronic Literature Directory della ELO e avvalendosi delle tecnologie più durature possibili. Coloro che sono associati con una Università possono anche incontrarsi con librai e amministratori dei sistemi universitari e spiegare loro le motivazioni artistiche e letterarie in base alle quali mantenere la letteratura elettronica accessibile negli anni. Le persone che ora conservano la nostra cultura non-digitale potrebbero avere difficoltà a capire in che modo istituzioni già esistenti possano aiutare a rendere le opere nate digitali accessibili in futuro a meno che autori, editori, studiosi e insegnanti di letteratura elettronica non impieghino del tempo per parlare con loro circa le attuali problematiche di conservazione, archiviazione e disseminazione.

 



  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

One thought on “Bit senza acidi / Acid-Free Bits”

Lascia un commento