Discrete vs. Relational Content Modeling

By Deane Barker • • 3 min read •
Author Description

Content modeling “inside” a single content object is generally quite simple. What’s trickier is content modeling between multiple content objects.

AI Summary

This post explores the differences between discrete and relational content modeling, highlighting how each approach affects content organization and management. The author provides insights into when to use each model and their implications for content strategy and architectural decisions in digital environments.

I was in Boston on business a couple of weeks ago, and one of the things I did for fun was take the train to Cambridge and walk around the campus of Harvard University. Call me a total dork, but it was amazing to actually be there.

(Did you know Harvard has a $26 billion endowment? At, say, eight percent interest, they could give all their students free tuition, and they’d still have to spend over $2 billion a year just to break even.)

The trip must have got me in a scholarly mood, because on the way back to Boston, I got to thinking about content modeling. And since I was in such an academic frame of mind, I made up two new terms:

  1. Discrete content modeling

  2. Relational content modeling

(Just checked Google. There are no hits for the first phrase, and a single hit for the second. I rule. Anyway…)

Discrete content modeling means simply, the ability for you to model a self-contained piece of content. So, if you decide that your news article needs properties for title, subtitle, author, summary, body, etc., then you’ve discretely modeled this piece of content. You’ve defined the information that the content item carries within itself.

Some content management systems are better at this than others. At the risk of beating a dead horse, I refer back to my comments on open and closed content management. If your system only cares about a “page,” then it gets tough to model anything beyond, well, a page.

Relational content modeling is a little more complex and it’s what sets systems apart in my mind. It refers to the modeling of a piece of content in relation to other content in the system. So it’s how a content item refers to content “outside” of itself.

Referring back to our news article example from above, let’s say that our “author” property wasn’t just a string of text, but was instead a reference to another object. In relational database terms, this is a foreign key relationship between tables. By setting up this reference, you’ve modeled this content item relationally.

This is where a lot of content management systems run into trouble, because relational modeling can be tricky to do. It’s tough from an interface perspective, as we talked about in-depth a few weeks ago.

Additionally, it gets complicated since you need to maintain referential integrity between content items – when the author to which you refer gets deleted, you need to make sure your news article gets updated. (Yes, this is easy in a standard relational database, but how many content management repositories are flat tables like that?)

eZ publish does relational modeling really, really well. I touch on this briefly in the screencast on eZ that I did for Packt last year. Essentially, you can state that a property of an object is (1) a reference to another object, or (2) a reference to multiple other objects. Additionally, you can specify what type of objects can be linked, and from what branch of the content tree they can come from. Short of a custom relational database, this is the best I’ve ever seen relational modeling executed.

Also, the template code to get at the relations is fantastic. The properties on the original object are seamless references to the other objects. Like this:

{$article.author.first_name} {$article.author.last_name}

Now, if your CMS has a content tree, you can fake up a limited amount of relational modeling. For instance, you could add an “author” object as a child of a news article. Then you just treat any author object found under an article object as the author of that article. This gives you a separate author object, but that’s about it – you have to have multiple authors under multiple articles, so it’s really limited. But it’s something, if you have no other options.

I realized recently that the ability to model content well is really the first thing I look for in a CMS. But it’s important to realize that discrete and relational model are two different things, and most systems are much better at the former than a latter (especially XML-ish systems – XML representations of content tend to be very discrete).

Next time you evaluate a system, look for both aspects of content modeling. A well-done relational modeling system can be a huge benefit.

Links to this – Varying Levels of Content Structure August 22, 2011
Content structure is achieved at a variety of levels -- structure within a property, structure withing a content object, structure between different content objects, etc.
Links to this – Open and Closed Content Management Re-visited November 27, 2005
A CMS should be able to solve content-related problems without me having to write code to support it.
Links to this – Three Types of Metadata August 6, 2012
A month or so ago, I posted about the NISO document for building digital collections . Buried in that document was a great quote about the different kinds of metadata. Essentially, NISO claims, it breaks down to three types: Descriptive Metadata is what we normally think of as content modeling....
Links to this – Chasing the Ideal: Relational Content Modeling in Content Management April 11, 2011
Every CMS tries, in some extent, to duplicate the classic model of the relational database. Some come closer than others to this "ideal."
Links to this – The Five Rings of Usability June 20, 2008
When you look at the usability of an entire Web site, I want to propose that there are five levels of it. From widest to narrowest, here is what I dub “The Five Rings of Usability” (man, I love making up important sounding names for stuff…) Site Existence: At the risk of being absurdly basic, this...
Links to this – Points of Differentiation in Headless CMS October 16, 2018
Why do customers pick one headless CMS over another? How do they differentiate themselves?
Links to this – What Makes a Content Management System? June 30, 2007
Comprehensive post discussing the most common features found in content management systems today.
Links to this – The Four Disciplines of Content Management November 24, 2007
All of the disciplines put under the "content management" moniker can actually be split into four distinct groups.
Links to this – On Posting Practices December 27, 2006
Aaron Mentele is asking about posting practices for people who blog a lot. But while the first part of my prediction seems to be true, I can’t say the same about posting getting any easier. Deane Barker tells me he spends 15 minutes on each post with the exception of an occasional chapter on cms...
Links to this – Architecture and Functionality in Content Management November 28, 2006
Some content management features are "out of the box," while some are developed during integration. Which pattern is better than the other, and why?
Links from this – Books by Deane Barker
Details of books I have authored, both published and in-progress.
Links from this – Open and Closed Content Management June 20, 2003
Different CMS allow you to define your content in different ways.
Links from this – Asynchronous Record Finding in Web Forms May 14, 2006
In any content management (or information management) system of sufficient complexity, you will have to interlink records. You will always get to the point where, in the process of editing a record, you will have to specify another record. (Let me note here that the title to this entry is insanely...
Links from this – The Content Tree August 18, 2005
A while back , I mentioned the concept of a “content tree” in regards to content management. I cited this as a “functional pattern” and promised to talk about it more, but I never did. So, here goes – With every content management system (CMS) I’ve written, I always get back to the concept of a...