Lesson 3 of 8 · Core Concepts

Content Modeling I — Types, Attributes & Objects

A content model is the blueprint underneath every CMS implementation. This lesson dissects its building blocks — attributes, types, and objects — and the intellectual act of turning fuzzy ideas into concrete structure.

⏱️ ~22 min read 📄 8 review questions 🎯 Core concept — take your time

Learning objectives

  • Define a content model and the idea of reification
  • Break down the full anatomy of an attribute
  • Distinguish an attribute type from an attribute assignment
  • Understand content types as wrappers around attributes
  • Nail the critical difference between a type and an object
"Content modeling is the foundation on which a CMS implementation is built. Mistakes made here breed multiple future problems that can be tough to recover from." — Deane Barker, Real World Content Modeling
Content model

The collection of content types, attributes, relationships, and datatypes that accurately describes a logical domain of content. "Content modeling" (the verb) is the process of designing that collection.

1Reification: making the abstract concrete

The central intellectual act of content modeling has a name — reification, from the Latin res, "thing." It means making something concrete: converting a vague human idea about content into actual types, attributes, and datatypes a machine can manage.

Example — the street address

You could store an address as one blob of text. That's flexible, but the computer can't sort by city or validate a postal code. Or you could break it into labeled fields — street number, street name, city, postal code. Now it's queryable and powerful, but you've traded away some flexibility (every address must now fit that structure). This tension shows up in every modeling decision.

2The anatomy of an attribute

Content, at bottom, is just labeled data: we take a datum and wrap it in a label and context so we can describe, manipulate, and refer to it. That wrapper is an attribute — a bundle of parts working together.

Attribute

A logical container holding a single piece of managed data along with everything needed to store, display, edit, and validate it.

A single attribute is doing more than it looks. Its parts include:

That's a lot, and as an editor you'll rarely see an attribute broken down this far — the parts are usually implied and spread across subsystems. This unique combination of all those pieces is called an attribute type.

3Types: wrappers around attributes

Attributes never float around alone. They're grouped into content types.

Content type

A set of attributes that combine to describe a logical unit of content. An Article type might be composed of Title, Body, Author, and Category attributes.

A crucial subtlety: a type contains no data. All data lives in attributes. A type is just a named, reusable wrapper — a boundary around a collection of attributes, plus maybe a few settings like permissions. A type must contain at least one attribute (otherwise it has no reason to exist).

🧩 Attribute type vs. attribute assignment

When you assign the "Text" attribute type to the Article type and name it "Title," you create an attribute assignment. The Title on Article is not the same as the Title on Employee Profile — they're separate assignments. Strictly, whenever we say "attribute" on a type, we mean an "attribute assignment": a specific attribute type, assigned to a specific content type, with a specific name and settings. We just say "attribute" because "attribute assignment" is a mouthful.

Finally, a content type is a unique combination of attributes. Could two types have identical attributes? Technically yes — but if they share the exact same attributes with the same settings, they're functionally the same type. In rare cases you might duplicate them for naming or rule differences (Article vs. Blog Post), but that usually just confuses editors.

4Types vs. objects — the cookie cutter

So far we've only described an empty model. The moment we add data, we move from a content type to a content object.

Content object

An actual piece of content created from a type — one instance, filled with real data. A type is the pattern; an object is a thing stamped out from that pattern.

🍪

The cookie-cutter analogy. Your content model — types and attributes — is a cookie cutter: the pattern for shaping cookies. When you start creating content, you stamp out cookie after cookie in that shape. You might have a million content objects of a single type. "Type" = the cutter (the plan). "Object" = the cookie (actual content).

🏛️ Plato was here

This idea traces back to Plato's Theory of Forms: everything in the real world is an instance of a more ideal "form." The table in your dining room is a representation of the universal idea of "table-ness." A content type is that ideal form; a content object is a real-world instance of it. (The material only half-jokingly offers bonus points to the first CMS brave enough to call its content types "Platonic Forms.")

⚠️

Why this all matters: everything else in your CMS — templates, workflow, delivery, search — is built on top of the model. Once a model is loaded with thousands of objects, changing it is genuinely hard, and internal names may be locked. This is why modeling deserves careful thought before you start pouring in content.

🔑 Key terms from this lesson

Content model
The collection of types, attributes, relationships, and datatypes describing a content domain.
Reification
Making the abstract concrete — turning ideas about content into managed structure.
Attribute
A labeled bundle wrapping one datum plus its name, label, datatype, editorial element, and validation.
Attribute type vs. assignment
The reusable definition vs. a specific instance of it placed on one content type with a name and settings.
Content type
A named, data-free wrapper grouping a unique set of attributes.
Content object
A concrete instance of a type, filled with data — the "cookie" from the "cutter."

Review Questions

Test your understanding. Click each question to reveal the answer.

1What is a content model, and what four things does it contain?
Show answer
Answer: A content model is the collection that accurately describes a logical domain of content. It contains content types, attributes, relationships, and datatypes.
2Define reification and give the street-address example of the trade-off it involves.
Show answer
Answer: Reification (from Latin res, "thing") is making the abstract concrete — turning an idea about content into managed structure. An address as free text is flexible but not queryable; broken into fields (street, city, postal code) it's powerful and queryable but less flexible. Structure trades flexibility for capability.
3Content is described as "labeled data." What construct does the labeling, and name four parts of it.
Show answer
Answer: The attribute. Its parts include: the value, an internal (machine) name, a human label, a primitive datatype, a typed value representation with (de)serialization, an editorial element, and validation rules. (Any four.)
4Why is it said that "a type contains no data"?
Show answer
Answer: All data lives in attributes. A content type is just a named, reusable wrapper (with maybe a few settings) that groups attributes together — it holds no data itself.
5Explain the difference between an attribute type and an attribute assignment.
Show answer
Answer: An attribute type is the reusable definition (e.g. "Text"). An attribute assignment is a specific instance of that type placed on a specific content type with a specific name and settings — e.g. "Title" on Article, which is distinct from "Title" on Employee Profile.
6Using the cookie-cutter analogy, distinguish a content type from a content object.
Show answer
Answer: The type is the cookie cutter — the pattern/plan. The object is a cookie stamped from it — an actual instance filled with data. You can have millions of objects of one type.
7How does Plato's Theory of Forms map onto content types and objects?
Show answer
Answer: A content type is like a Platonic "form" — the ideal, abstract pattern (e.g. "table-ness"). A content object is a real-world instance of that form (an actual table).
8Discussion: Why is it risky to change a content model after it's loaded with thousands of objects?
Consider locked internal names, existing data that must be migrated, and everything built on top of the model.
Show answer
Sample answer: Templates, workflow, delivery, and search all depend on the model, so changing it ripples outward. Internal attribute names may be unchangeable, and existing objects must be migrated to fit the new structure — risking data loss or inconsistency. That's why careful modeling up front is far cheaper than restructuring later.