Content Types and Attributes
A content model is a formal representation of structured content. The model is expressed as a series of content types linked by relationships to other content types. Each content type is made up of a bunch attributes that capture its essential characteristics. These design guidelines help you create consistent and readable content models, specifically when working content types and their attributes.
Content types names should be domain-based
Content type names should be evocative and plucked directly from the domain under study. All content type names should resonate with the business.
Do not underestimate how difficult it is to name a content type. It can be one of the most infuriating tasks that we can offer little assistance with as people outside your business domain. However, if you can’t name a content type, or if it feels ‘not quite right’, then go with your gut and try again, because it is most likely wrong. Getting the name right for a content type is like slotting in the final piece of a thousand word puzzle: it should click!
Do not use plurals for names.
Do not use plurals for content type or attributes. Prefer Article over Articles. Why? A content type is singular because you will use it to create many content items. The content type defines the Article; its content items are the articles.
Do not add attributes because it’s easy.
It’s so easy just to add attributes to content types today, but really hard to remove them later. Start out with a less is more attitude.
Consider the content type Profile, what attributes should we add: name, age, dateOfBirth, location, birthPlace, email, and userName. We could go on but we mustn’t. We should only add attributes if we know they deliver value to someone or something now. The temptation to design for tomorrow is both innate and overwhelming. What if we added twitterHandle, then we should have facebookHandle, and linkedIn whilst we’re here. This will safe us having to come back and do this later. Don’t do that. Resist this compulsion to “add because you can” and keep things simple. Model for what you know is valuable today and have the courage to change (add) tomorrow. Design never ends.
Be smart and store only what you need.
Going back to our Profile content type. Do you need to store both the age and dateOfBirth. If you know someone’s date of birth, you can figure out their age. Look at your attributes in totality and only define what you need.
Attribute names should be domain-based nouns.
Like content types, attribute names should be derived from the domain under study. If it doesn’t make sense to the business, then question why it’s being added at all.
Content types tend to nouns.
Content types are things – Article, Hotel, Promotion, Vaccine – to name a few. Content types tend to nouns. Be wary of content types that have verb-like properties. For example, consider the content type ArticleManager, what is that telling us? That ArticleManager is responsible for managing a collection of articles? That’s not a thing. It’s not a noun. Instead it’s does something rather than describes it. It’s a doer and most likely not a content type. Go back to the business and find out how they refer to a bunch of articles; Magazine, Book, Newspaper.
Be consistent with the attribute name and its type.
Every attribute has a type associated with it. A type constrains what kinds of values can be assigned to attribute (see here for details). Time for an example, consider the following
- Date publishDate
This is an attribute with the name publishDate and type Date. This tells anyone reading the content model that the attribute can only be assigned values that are of type Date, that is, they have a day, month and year. All other values are illegal.
- publishDate = -20413 (illegal)
- publishDate = “bob” (illegal)
- publishDate = 01/12/2015 (legal)
Now, if the publishDate is indeed of type Date, then that’s a good candidate name for the attribute. However, what if publishDate was of type Text? Is publishDate still a good name for the attribute? Maybe.
- Text publishDate
But it does raise a few clarifying questions like: Why isn’t the publishDate a Date? Why not call it publishText? Is there a better name for publishDate? Which leads us back to what really is a publishDate?
If the attribute name tells a different story to the type of value the attribute can store, double check all is well within business domain and the content model that is supposed to represent it.
Don’t bother with types on conceptual models.
In the early phases of content modelling, focus on what the attribute is. So in the above example, the business knows that an article has a publishDate. They don’t really need to go into the weeds are around how we enforce dates. When we move into the design model, we do care and we’ll need to make a decisions whether it will be capture using as Text or a Date.
In the conceptual content model, worry less about the types for attributes. Focus on capturing the right attributes.
