Discrete vs. Relational Content Modeling

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.