The cost of knowledge graphs

There is interest and excitement building around the potential of knowledge graphs (“interlinked descriptions of entities [that] also encod[e] the semantics”) to drive content operations. I believe that knowledge graphs and content management systems (CMSs) that sit on top of knowledge graphs have a critical part to play, but I also have some concerns.

Since 2013, Scriptorium has had a very informal content maturity model:

1. Crap on a page
2. Design consistency
3. Template-based content
4. Structured content
5. Content in a database

Each level is explained in Why is content strategy hard?

You need at least level 4 for efficient content ops, and many organizations need level 5. The basic difference between levels 4 and 5 is how you store the content. In theory, you can create structured content in text files (XML or other markup). In practice, a database gives you better insight into content relationships, which in turn makes it easier to deliver improved customer experience. Knowledge graphs are level 5.

Structured content is information that captures the relationships and requirements among content components. For example, an article must have an author and an author must include a bio. An article that doesn’t include an author is invalid or incomplete.

In modern digital content production, we have linear documents (like Word files). The only relationship is sequential—paragraph 1 comes before paragraph 2.

Content relationships

The formatting of the document carries implied structure.

Formatting implies content structure

Structured content captures the implied structure explicitly. By adding containers like “section,” you can describe the relationships among the various document components with more precision. But structured content is still limited to sequence (up and down) and hierarchy (left and right). In effect, these documents are two-dimensional instead of linear.

Content relationships

Content management systems (CMSs) capture these hierarchical and sequential structural relationships. Knowledge graphs take the next step. Instead of a tree structure, a knowledge graph provides for multidimensional relationships, where content objects are interwoven. To create a document, web page, or other publication, you use the knowledge graph relationships to extract the relevant information.

For example, consider the simplified example of an author. For an author, your knowledge might include a name, a biography, and a photo. You could use the name and photo in an article as a byline. The author’s name (but not bio or photo) might appear in a citation or a bibliography. And finally, you can create a page that lists all of a particular author’s publications based on the relationship between author and articles. The key here is that all of the necessary information is in the knowledge graph and you query the knowledge graph to extract the relevant connections and information.

Content relationships are multidimensional

Using knowledge graphs as a foundation for content delivery will be challenging. It has more in common with building web page dashboards or web interfaces than with documents.

We have to think about the various content or data objects, understand how they relate to each other at the knowledge graph level, and then bring them together into a coherent experience, whether a webpage, a document, or something else entirely.

We have struggled mightily with XML. Even in technical content, which has been historically the friendliest to structure, it’s estimated that, at best, 30% is structured. And note that this 30% is measured in surveys of professional technical writers. It almost certainly omits the huge amounts of content being created by people who are not identified as professional communicators. The vast majority of technical and product content is level 1 or 2 and stashed in Word, even when it is high-stakes technical content.

Knowledge graphs and headless CMSs are suddenly all the rage for websites and specifically marketing content. But looking at the content maturity model above, I foresee trouble ahead.

In the last 20 years or so, some technical content has made a painful transition from template-based content (level 3) to structured content (level 4). From structured content, it’s a relatively smaller step into knowledge graphs.

The situation for marketing content is different. Design systems provide guidance for content formatting, so a website driven by a design system is at level 2. Template-based authoring, or at least rigorous template-based authoring, is rare in marketing content. In many CMSs, there are templates or forms that guide authors, but the systems offer escape hatches—a way to insert arbitrary HTML and get around the requested framework.

Marketing teams are now facing requirements to increase velocity, scale localization, and deliver content across many different channels. For this, they will need structured content and a content management system that can feed all the needed channels. Moving up in the content maturity model is always challenging, and a jump across multiple levels is daunting. Trying to move from design-forward content (level 2) all the way to knowledge graphs (level 5) is truly terrifying.

To succeed, we need a mindset shift from “make it pretty” (level 2) to a recognition that consistently organized and structured content provides value by improving the customer experience and enabling innovation. The service providers and software vendors need to step up to provide the necessary system and services to help make the transition.

What do you think? Does your organization need to move up in the content maturity model? Do you need knowledge graphs?