Seems like the author has stumbled upon SOA - this "content object" idea is basically just a restating of the "business object" from that philosophy. For more thinking along lines like this, I suggest reading up on SOA concepts. They perhaps aren't as widely applicable as the hardcore adherents believe (isn't this always true?), but they can be really useful in your bag of tricks.
note - rereading this comment the first bit comes across as snarky, but I don't mean it as such. It's a good article and good concept to know, just trying to pass on other search terms for similar modes of thought.
Isn't this how pretty much everyone builds pretty much everything? I didn't know there was a way to build web applications without knowing what data they're based on...
I think what he's getting at is that he's modeling the content expectations first, with no regard to the actual data they are based on. My team builds a lot of things this way - we start with mockups & presenters that have no actual data. Once we have that all locked in and approved, we start thinking about the data structures. Several of our projects deal with some really complex weather, insurance, and other info that can be hard to model & assemble upfront... so once we have our presenters worked out, it's rather easy to then decide how to model it, build our services and delivery mechanisms, and move forward.
We've found that going this direction leads to cleaner models, faster execution, and more decoupling of the entire front end from the entire back-end. We can query & build our data delivery however we need and feed it to the presenter as fast dumb objects (typically as Hamsterdam structs).
note - rereading this comment the first bit comes across as snarky, but I don't mean it as such. It's a good article and good concept to know, just trying to pass on other search terms for similar modes of thought.