Quando una casa editrice decide di produrre lo stesso contenuto per la carta, per il web, per un e-reader e per una lavagna interattiva, il problema non è dove conservare i file. È stabilire che cosa, dentro quei file, è un’unità di contenuto riusabile e con quali metadati la si descrive. Un repository documentale risolve il primo problema e lascia aperto il secondo, che è quello che decide se la pubblicazione multicanale funziona davvero o resta una conversione di formato fatta a mano.

Cosa fa e cosa non fa un ECM

Un sistema di Enterprise Content Management — Alfresco è l’esempio open source di riferimento dell’epoca — gestisce bene un insieme di problemi precisi: versioning dei documenti, controllo degli accessi, workflow di approvazione, ricerca full-text, conservazione. Il modello dati nativo è quello del documento e della cartella, con un’estensione a proprietà e aspetti. Per molti scenari aziendali questo basta.

L’interoperabilità di questo livello, dal 2010, ha uno standard: CMIS (Content Management Interoperability Services), approvato come standard OASIS il 1° maggio 2010. CMIS definisce un domain model e due binding — Web Services e AtomPub RESTful — per leggere e scrivere documenti, cartelle, relazioni e politiche in un repository, indipendentemente dal vendor. Risolve il problema di parlare a un repository da un’applicazione esterna senza accoppiarsi alla sua API proprietaria.

Quello che né l’ECM né CMIS modellano nativamente è il livello semantico dell’editoria: la differenza fra un capitolo, una scheda, un esercizio e una didascalia; le relazioni fra un brano e l’antologia in cui viene ricombinato; il vocabolario controllato con cui si classifica un contenuto scolastico per materia, grado e ordine di scuola. Il documento sa di essere la versione 4 firmata da Tizio; non sa di essere un’unità di apprendimento riusabile in tre contesti diversi.

Il livello che manca: vocabolari e tipizzazione

Per rendere un contenuto effettivamente riusabile servono due cose che vivono sopra il repository.

La prima è un vocabolario controllato con cui descrivere i contenuti in modo coerente. Tassonomie e ontologie editoriali — per materia, target, livello, diritti — non sono liste di stringhe libere: hanno gerarchie, relazioni di equivalenza, termini preferiti e alternativi. Dal 2009 esiste uno standard W3C per esprimerle in forma interoperabile: SKOS (Simple Knowledge Organization System), diventato Raccomandazione il 18 agosto 2009. SKOS modella schemi di concetti — skos:broader, skos:narrower, skos:prefLabel — come dati RDF pubblicabili e collegabili. Una classificazione editoriale espressa in SKOS smette di essere una colonna in una tabella e diventa un grafo che si può collegare ad altri.

La seconda è la tipizzazione del contenuto stesso. Se il testo è un blob di markup di presentazione, l’unica cosa che si può fare è renderlo com’è. Se invece è marcato per struttura e funzione — questo è un concetto, questo una procedura, questo un riferimento — allora lo si può filtrare, ricomporre e impaginare per canali diversi. DITA (Darwin Information Typing Architecture), nella versione 1.2 approvata come standard OASIS il 1° dicembre 2010, è l’architettura XML che formalizza questa idea: topic tipizzati, riuso per riferimento (conref), aggregazione tramite mappe. Nato per la documentazione tecnica, il principio del single-source vale per qualunque catalogo che debba uscire su più di un canale.

Dove diventa difficile

Il punto critico è che questi standard stanno a livelli diversi e non si compongono da soli.

CMIS parla di documenti e proprietà, non di concetti SKOS né di topic DITA. Un file DITA depositato in un repository CMIS resta, per il repository, un documento XML con qualche proprietà: il repository non capisce le sue relazioni conref e non sa risolvere una mappa. La classificazione SKOS, per essere utile in ricerca e navigazione, va proiettata sul modello a proprietà del repository, e quella proiezione perde parte della struttura del grafo. L’integrazione vera — far sì che un workflow editoriale sul repository conosca la tipizzazione del contenuto e il vocabolario con cui è classificato — è lavoro di sviluppo sul confine fra questi mondi, non una configurazione.

C’è poi il problema dell’output. Produrre un EPUB — la versione 2.0.1 è la specifica IDPF consolidata dal 2010, basata su OPS, OPF e OCF — significa avere una catena che dal contenuto strutturato genera il pacchetto finale con il suo XML di packaging e il suo manifest. La carta richiede un’altra catena, il web un’altra ancora. Il valore del single-source si misura qui: se ogni canale richiede una rilavorazione manuale del contenuto, il repository ha archiviato file ma non ha abilitato la multicanalità.

Una declinazione concreta di questo impianto — un ambiente di produzione editoriale costruito estendendo un core Alfresco con metadati, tassonomie e workflow per un gruppo editoriale — è descritta nel progetto D@nte seguito da noze: https://www.noze.it/progetti/dante/.

Implicazioni progettuali

La conseguenza per chi costruisce un DAM editoriale è che la quota di lavoro decisiva non sta nello storage. Sta nel definire il modello dei contenuti (quali tipi, quali relazioni), nel formalizzare i vocabolari (preferibilmente in SKOS, per non rifarli a ogni progetto), nel marcare il contenuto per struttura e non per resa, e nell’esporre il tutto via uno standard come CMIS perché le applicazioni a valle non si accoppino al repository. Sono scelte che si pagano in anticipo e si ammortizzano a ogni nuovo canale di pubblicazione.

Puntare su uno stack open source qui ha una ragione pratica: il modello dei contenuti di un editore è un asset di lungo periodo, e legarlo a un formato o a un repository proprietario significa accettare un rischio di lock-in su un patrimonio destinato a sopravvivere a più cicli tecnologici.

Limiti

Standard a livelli diversi non garantiscono una catena che funzioni senza colla scritta a mano: CMIS, SKOS, DITA ed EPUB risolvono ciascuno un pezzo, ma il collante fra il modello dei contenuti, il repository e i motori di pubblicazione resta lavoro su misura per ogni catalogo. La tipizzazione DITA conviene quando il riuso è reale e frequente; su contenuti che escono una volta sola, l’autore paga il costo della marcatura senza ricavarne il beneficio. E nessuno di questi standard tocca il problema editoriale vero a monte — decidere quale sia l’unità di contenuto giusta per un dato catalogo — che resta una scelta di redazione, non di architettura.

Immagine di copertina: immagine del progetto D@nte (noze).