When a publisher decides to produce the same content for print, the web, an e-reader and an interactive whiteboard, the problem is not where to keep the files. It is to establish what, inside those files, counts as a reusable unit of content and with which metadata it is described. A document repository solves the first problem and leaves the second one open, and the second is what decides whether multi-channel publishing actually works or stays a format conversion done by hand.

What an ECM does and does not do

An Enterprise Content Management system — Alfresco being the open source reference of the period — handles a precise set of problems well: document versioning, access control, approval workflows, full-text search, retention. Its native data model is the document and the folder, extended with properties and aspects. For many corporate scenarios this is enough.

Interoperability at this level has had a standard since 2010: CMIS (Content Management Interoperability Services), approved as an OASIS Standard on 1 May 2010. CMIS defines a domain model and two bindings — Web Services and RESTful AtomPub — to read and write documents, folders, relationships and policies in a repository, regardless of vendor. It solves the problem of talking to a repository from an external application without coupling to its proprietary API.

What neither the ECM nor CMIS models natively is the semantic layer of publishing: the difference between a chapter, an entry, an exercise and a caption; the relations between a passage and the anthology into which it is recombined; the controlled vocabulary by which a school content item is classified by subject, grade and school level. The document knows it is version 4 signed by someone; it does not know it is a learning unit reusable in three different contexts.

The missing layer: vocabularies and typing

To make content genuinely reusable, two things are needed that live above the repository.

The first is a controlled vocabulary with which to describe content consistently. Editorial taxonomies and ontologies — by subject, audience, level, rights — are not lists of free strings: they have hierarchies, equivalence relations, preferred and alternate terms. Since 2009 there has been a W3C standard for expressing them in interoperable form: SKOS (Simple Knowledge Organization System), a Recommendation as of 18 August 2009. SKOS models concept schemes — skos:broader, skos:narrower, skos:prefLabel — as RDF data that can be published and linked. An editorial classification expressed in SKOS stops being a column in a table and becomes a graph that can be linked to others.

The second is the typing of the content itself. If the text is a blob of presentation markup, the only thing one can do is render it as is. If instead it is marked up by structure and function — this is a concept, this a procedure, this a reference — then it can be filtered, recomposed and laid out for different channels. DITA (Darwin Information Typing Architecture), in version 1.2 approved as an OASIS Standard on 1 December 2010, is the XML architecture that formalises this idea: typed topics, reuse by reference (conref), aggregation through maps. Born for technical documentation, the single-source principle holds for any catalogue that has to ship on more than one channel.

Where it gets hard

The critical point is that these standards sit at different levels and do not compose on their own.

CMIS speaks of documents and properties, not of SKOS concepts nor of DITA topics. A DITA file deposited in a CMIS repository remains, to the repository, an XML document with a few properties: the repository does not understand its conref relations and cannot resolve a map. The SKOS classification, to be useful for search and navigation, has to be projected onto the repository’s property model, and that projection loses part of the graph’s structure. Real integration — making an editorial workflow on the repository aware of the content’s typing and of the vocabulary it is classified by — is development work on the boundary between these worlds, not a configuration.

Then there is the output problem. Producing an EPUB — version 2.0.1 being the IDPF specification consolidated in 2010, built on OPS, OPF and OCF — means having a chain that generates the final package, with its packaging XML and its manifest, from the structured content. Print requires another chain, the web yet another. The value of single-sourcing is measured here: if every channel requires manual rework of the content, the repository has stored files but has not enabled multi-channel publishing.

A concrete instance of this design — an editorial production environment built by extending an Alfresco core with metadata, taxonomies and workflows for a publishing group — is described in the D@nte project carried out by noze: https://www.noze.it/en/projects/dante/.

Design implications

The consequence for anyone building an editorial DAM is that the decisive share of the work is not in storage. It is in defining the content model (which types, which relations), in formalising the vocabularies (preferably in SKOS, so they are not rebuilt for every project), in marking up content by structure rather than rendering, and in exposing all of it through a standard such as CMIS so that downstream applications do not couple to the repository. These are choices paid up front and amortised at every new publishing channel.

Committing to an open source stack here has a practical reason: a publisher’s content model is a long-term asset, and tying it to a proprietary format or repository means accepting a lock-in risk on a body of work meant to outlive several technology cycles.

Limits

Standards at different levels do not guarantee a chain that works without hand-written glue: CMIS, SKOS, DITA and EPUB each solve a piece, but the glue between the content model, the repository and the publishing engines remains bespoke work for every catalogue. DITA typing pays off when reuse is real and frequent; on content that ships only once, the author pays the cost of markup without reaping the benefit. And none of these standards touches the real editorial problem upstream — deciding what the right unit of content is for a given catalogue — which stays an editorial choice, not an architectural one.

Cover image: D@nte project image (noze).