<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<capitolo><paragrafo><titolo>La chiusura del cerchio: l&apos;archiviazione</titolo><testo>Mantenere rigore e progettualità fino alla fine del flusso non è facile. Ma una corretta archiviazione diventa vitale quando si pensi in qualche modo al termine “riuso”. Infatti, una grossa parte dell’interesse dovuto all’implementazione di un flusso cross-media sta proprio nei grandi vantaggi che si hanno quando si debbano riutilizzare informazioni già pubblicate. Rimettere nel flusso una parte di un albero sul quale si è già investito per ricavare struttura e Schema è facile se si è operato correttamente nella prima pubblicazione, e si è data importanza alla fase di archiviazione. La regola di base riguarda ancora il rapporto contenuto-forma: quanto più sapremo attuare una strategia di archiviazione che permetta di distinguere e connettere contenuto e forma, tanto meglio potremo ripescarli con facilità quando si tratterà di riutilizzarli in tutto o in parte. Anche questa mansione sarà di competenza dell’amministratore. </testo></paragrafo><paragrafo><titolo>L’ultima fase, l&apos;archiviazione, diventa spesso l&apos;inizio di una nuova fase di pubblicazione </titolo><testo>Fotografiamo una situazione tipo a questo punto del flusso. Dal materiale fornito dal cliente al prodotto di comunicazione realizzato, passando attraverso tutti i passi intermedi, abbiamo in mano una massa di file digitali importante. Cosa dobbiamo farne? Cosa tenere e cosa buttare? Ha tutto la stessa importanza? Le informazioni contenute sono sufficienti o è meglio operare una sorta di “etichettatura” ? Tante domande che spesso non vengono affrontate e risolte correttamente. Si preferisce evitare il problema prendendo ogni genere di asset relativo ad una certa commessa, ponendolo in una cartella e archiviando il tutto con un congruo numero di CD, DVD o quant’altro. Delegando, inoltre, alla sola memoria dei vari operatori l’incarico di tenere una sorta di traccia di ciò che si è messo via, nell’eventualità si debba riutilizzare qualcosa. Agendo così, spesso capita che si impieghi molto tempo per cercare di ripescare pezzi di materiale già pubblicato in precedenza, e, quando la ricerca sembra non dare risposte in tempi brevi, a volte si preferisce ripartire da zero dal materiale “crudo” e ristrutturarlo, perdendo così tutti gli affinamenti e le correzioni apportati in precedenza. Per evitare queste situazioni poco costruttive, conviene pensare da subito una strategia di archiviazione organica, che sia parte integrante del flusso CMP: da un lato ne sia conclusione, dall’altro occasione di nuovo inizio in caso di riuso. Dob­biamo pensarla un po’ come la gestione di una biblioteca: se si catalogano bene i libri, ponendo nel database molte informazioni su essi, e rispettando un rigoroso posizionamento negli scaffali, per quanto grande sia la massa di libri, sarà facile trovare quello che si cerca. Se, al contrario, la catalogazione o il posizionamento non vengono effettuati in modo appropriato, si comincia pian piano ad introdurre errori nel sistema e si arriverà presto a non riuscire a trovare le informazioni cercate, pur avendo la certezza della loro esistenza.</testo></paragrafo><paragrafo><titolo>Cosa archiviare</titolo><testo>A rigore sarebbe conveniente archiviare sempre ogni forma di dato digitale, in quanto, ogni file, anche se parziale o non definitivo, contiene tracce del lavoro umano, e, a volte, può capitare che serva proprio la versione di file appena buttata via perché non definitiva. Il rovescio della medaglia è che mantenere ogni versione degli elaborati porta facilmente tutto il sistema nel caos. Quindi, sta al criterio umano fare delle scelte e, per ogni passo importante del flusso, definire una versione “ufficiale” ed eliminare quelle “ufficiose”. Fatto questo, ci si chiede se si debba mettere via proprio tutto, o basti archiviare solo i PDF finali e solo le pagine HTML/asp/php e l’XML, solo gli impaginati, solo XML o asset puri. Tanto più sapremo archiviare bene le informazioni definitive per ogni fase, tanto più facilmente potremo ripescare il lavoro alla fase che ci è più comoda. Avere a disposizione le sorgenti di contenuto puro ci tiene aperte tutte le porte. Da XML e asset ricchi possiamo decidere di pubblicare su qualsiasi canale. Ar­chiviare correttamente (ad esempio mantenendo i link referenziali) XML e asset connessi sarà perciò un passaggio centrale. Da asset ricchi possiamo creare asset per il media, come già visto, ma non viceversa. Quindi, tra i due, senz’altro sono più importanti i primi. Però per la creazione di componenti per il media, ottenute dall’elaborazione degli asset ricchi, a volte si lavora molto ed è un peccato perdere questo lavoro. Quindi, nel caso di un riuso nello stesso media (ad esempio ripubblicazione in un sito differente, o in una nuova versione di catalogo cartaceo) si può risparmiare molto tempo avendo messo via ben ordinati e collegati i file pronti per il media. Per rendere più efficiente la fase di ripescaggio è conveniente ricavare e attribuire opportuni metadati (come vedremo più avanti), archiviarli assieme ai dati veri e propri e tenerne traccia in un contenitore esterno ricercabile.</testo></paragrafo><paragrafo><titolo>Come archiviare</titolo><testo>Prima di tutto è indispensabile definire un metodo rigoroso. L’amministratore dovrà spesso forzare le abitudini sia degli autori che dei designer. Un modo univoco di nominare i file, le cartelle e le versioni, per esempio, dovrà essere condiviso. Esistono diversi software di Digital Asset Management che consentono controlli a vari livelli. I criteri di scelta sono molti, e vanno dal costo alle esigenze operative, al carico di file da trattare. Il software di DAM non può compensare lacune organizzative, ma si limita a velocizzare qualcosa che si è già abituati a fare. Il supporto di un database esterno per tenere traccia dei dati è fondamentale se i dati sono già ben organizzati. Un’oculata gestione del versioning ha un ruolo chiave. Il riuso si basa spesso sulla correzione e l’integrazione. Quindi lo stesso file sorgente potrà essere riutilizzato con estensioni ed evoluzioni varie volte. È necessario non fare confusione tra le varie versioni, una conveniente regola che rifletta la versione nel nome eviterà spiacevoli inconvenienti. Il sistema DAM potrà essere coinvolto nel mantenere traccia delle versioni, tenendo il collegamento tra l’ultima e le precedenti. In un flusso CMP può capitare che alcuni dati (ad esempio le sorgenti XML per i siti) siano mantenuti sempre in linea all’interno dei Web server. Di caso in caso si dovrà capire come gestire quest’esigenza. Però, dato che abbinata alla pubblicazione on-line (per la quale il versioning ha un significato diverso) potrebbe essercene una cartacea, che, al momento della fusione contenuto-forma congela gli aggiornamenti, l’archiviazione degli asset utilizzati per la carta dovrà comprendere una “fotografia” della sorgente XML fatta al momento di quella pubblicazione. Questo non limita il fatto che, attraverso i media dinamici, la sorgente di contenuto possa continuare a cambiare e aggiornarsi.</testo></paragrafo><paragrafo><titolo>Dove archiviare</titolo><testo>Anche la scelta della tecnologia di memoria di massa per l’archiviazione, in qualche modo, influenza il flusso CMP. Supporti ottici (CD-DVD) e a nastro impongono una maggior “pacchettizzazione” degli archivi di quanto sia possibile con l’uso dagli hard disk. Se, ad esempio, c’è l’esigenza dell’aggiornamento continuo, comune nel caso di Internet e dei new media, spesso si manterrà in linea la versione attuale della sorgente di dati e anche le pubblicazioni statiche faranno unico riferimento a quella. In questo caso non avrà quasi senso parlare di archiviazione, ma sarà importante aver implementato un’adeguata strategia di back-up.</testo></paragrafo><paragrafo><titolo>I metadati</titolo><testo>Come le lattine, senza le appropriate etichette, sarebbero introvabili in un supermercato, così anche i file all’interno di un archivio sarebbero di difficile ripescaggio senza un’appropriata etichettatura. L’unica etichetta che da sempre siamo abituati a vedere e gestire è composta dal nome del file, dall’estensione, dalla data di creazione e di modifica, ed in alcuni casi dal programma creatore. Queste informazioni spesso non bastano quando la mole di asset in un archivio è molto grande. In alcuni file system è possibile vedere una piccola anteprima del contenuto, ma anche questa informazione spesso non è sufficientemente dettagliata per permetterci di decidere quale sia esattamente il file di cui abbiamo bisogno. Qui entrano in scena i metadati. Come i tag in XML servono per contenere i contenuti veri e propri e caratterizzarli, così i metadati permettono di aggiungere informazioni supplementari ai dati. I metadati sono informazioni sulle informazioni. Quindi, ad esempio, nel caso di foto, tra i metadati, oltre che trovar posto tutte le informazioni relative allo scatto, alle condizioni di ripresa (esposizione, diaframma, fotocamera utilizzata) e all’autore, dovranno esserci indicazioni relative alla tipologia di soggetto, al luogo del set, al codice relativo al prodotto contenuto, alle eventuali codifiche del produttore, ma anche una descrizione della situazione, del momento storico, delle eventuali persone presenti, degli oggetti a margine o complementari al soggetto centrale. Tutte queste informazioni aggiuntive spesso dovranno essere inserite manualmente o con piccoli automatismi in ogni asset. Una combinazione di più asset deve comprendere i metadati di tutte le componenti, con informazioni relative anche alla modalità di inclusione o di collegamento. Ci sono due tecnologie che affrontano questo problema: i sistemi di Digital Asset Management, che dall’esterno archiviano e indicizzano le proprietà degli asset in database autonomi, e la Extended Metadata Platform (XMP) di Adobe (figura alla pagina seguente), che prevede di “iniettare” tutti i metadati all’interno dei file stessi in modo da poterli trasportare in caso di spostamento.</testo></paragrafo><paragrafo><titolo>Come e cosa ripescare</titolo><testo>Facciamo l’esempio di un catalogo, stampato e pubblicato in un sito (come Info­Sedie). Se abbiamo archiviato il file PDF inviato alla stampa, e un bel giorno ci viene richiesta una ristampa esattamente identica alla prima edizione, sarà semplice ripescare il composito finale e rinviarlo nel flusso di prestampa. Spesso però servirà una ristampa con dei piccoli aggiornamenti, delle variazioni fatte qua e là, e, per quanto minimali, non sarà conveniente ripartire dal PDF definitivo. Anche perché, cosa importantissima, apportare modifiche al file finale di produzione, senza propagarle all’indietro, come avevamo visto, porta subito ad un’inconsistenza del flusso, e dell’archivio, fatto forse ancora più grave. Immaginiamo, ad esempio, che il PDF venga corretto direttamente e si vada in stampa senza aggiornare i contenitori delle informazioni pure. Se, in seconda istanza, si riprende la pubblicazione nel suo insieme e si vuole, ad esempio, creare una nuova versione stagionale del catalogo, tutte le piccole varianti apportate al PDF finale non ci saranno, e si incorrerà presto in errori e contestazioni. Quindi, formalizziamo una regola: è possibile ripescare e riutilizzare file di lavorazione a stadi avanzati del flusso solo se vengono ripubblicati così come sono, o, nel caso di modifiche, ci sia la garanzia che queste siano propagate all’indietro ai file sorgente. In caso contrario, per mantenere la consistenza dell’archivio, sarà necessario, ad ogni ripubblicazione con varianti, ristabilire il flusso CMP completo, relativamente alla pubblicazione interessata, con tanto di file XML e asset di forma neutra e di binding. Se l’archiviazione è stata fatta oculatamente, un buon software di ricerca potrà essere molto utile per ricercare asset in modo trasversale in tutto l’archivio, combinando vari metadati, ed evidenziando le varie versioni presenti in archivio.</testo><immagini><imm1><file href_fmt="images/Fig09-01_fmt.gif" href="file:///Users/marco/Desktop/CMPtaggaednDesign/Links/Fig09-01.tiff"></file><didascalia>Tutti i prodotti Adobe gestiscono XMP, e permettono di inserire nella struttura del file una serie standard di metadati ed, eventualmente, un insieme personalizzato a seconda delle esigenze dell’utente.  Un esempio è in Photoshop il comando Info su file.</didascalia></imm1><imm2><file href_fmt="images/Fig09-02_fmt.gif" href="file:///Users/marco/Desktop/CMPtaggaednDesign/Links/Fig09-02.tif"></file><didascalia>Se il file è un unico asset, le informazioni XMP sono incluse al suo interno. Se si tratta di un file composto da diverse parti incluse, le informazioni XMP vengono raccolte all’esterno e comprendono tutte quelle  dei file contenuti.</didascalia></imm2></immagini></paragrafo><paragrafo><titolo>Conclusione</titolo><testo>Giunti alla fine del nostro viaggio attraverso questo nuovo modo di vedere la tecnologia della comunicazione, non più basata sulla potenza di un singolo media, ma sulla sinergia di più canali, non resta che sottolineare gli obbiettivi di partenza. Il cross-media publishing vuole estendere il più possibile i canali che mettono in comunicazione il cliente che possiede l’informazione con l’utente che la cerca o a cui è destinata. Gli attori che compiono questo prodigio sono gli autori, i designer e gli amministratori. C’è più che mai quindi l’esigenza di lavorare in team, in sinergia, prima tra le persone che tra le tecnologie. È sicuramente un modo nuovo di vedere un problema molto antico. Gli strumen­ti e l’implementazione tecnologica si stanno formando in questi anni. Senza dubbio lo scoglio più difficile da superare sarà quello della mentalità di chi, abituato da anni ad operare e pensare in un certo modo, non troverà un vantaggio immediato nell’affrontare una strada nuova, sicuramente all’inizio più difficile e costosa, ma che in prospettiva promette grandi vantaggi. L’unico modo per eliminare la diffidenza è forse proprio cominciare a pensare e ad agire in logica CMP, affrontando e risolvendo uno ad uno i tanti problemi che si incontreranno in questo nuovo modo di comunicare. Questo libro vuole essere un inizio. Non resta che augurare buon lavoro ai pionieri che sposeranno questa tecnologia.</testo><immagini><imm1><file href_fmt="images/Fig09-03_fmt.gif" href="file:///Users/marco/Desktop/CMPtaggaednDesign/Links/Fig09-03.eps"></file><didascalia>Riprendiamo uno schema visto all’inizio per sottolineare come, dietro la tecnologia, ci siano persone  che pensano e utilizzano la tecnologia stessa. Per lavorare in logica CMP è indispensabile una buona sinergia di gruppo. </didascalia></imm1></immagini></paragrafo></capitolo>