I think that “Product Information” with Id, Prices etc. is ideal to be stored in a content repository along-side with all the other “html”, “jpegs”, etc…

What information is important to the business is a “business call”.
In many projects I witness that developers (instead of “business people”) make sort of an arbitrary judgment call of what’s important to the business and what not.

Let me give you a recent real-life
example that I dealt with at a banking customer of ours. The bank has a CMS and an e-banking application. As usual, they get treated differently from an uptime requirements perspective. This of course is wrong since the “login screen” of the banking app is on a “content page”.
Now if your CMS is down, there are no transactions going through, just because people cannot login, since in real-life they will have a bookmark to the login page or even go through the main homepage and click their way to “ebanking” login.

The same of course holds true (even more so) for the “Product Catalog” application that you bring up.
If the customers can’t browse the HTML and JPEGs for your products, it doesn’t matter that the shopping cart application is still up and running, since nobody will be able
to add something to the cart.

I certainly think that a lot of the hard-structured (traditionally db oriented data) would very much benefit from features like versioning or access control. Product Information is just a very good example where “content services” definitely make a lot of sense.

regards,
david

It is very exciting to read the differences between “Content” and “Data” explained (which I of course see as “feature additions” or “improvements”).

I think this is a landmark post and I will certainly refer to it in my future presentations. Very good stuff.

This includes attributes such as id, title, and price. These attributes are data in my opinion. They are likely used by multiple systems at the database level.

Then we have attributes such as an html description, jpef image, and pdf documentation. These things, in my mind, are content. They should not be considered critical to the business. If they were removed and the website brought down. The notion of a product should still exist.

Also, reporting on content just doesn’t feel right the way reporting on data does.

(Btw, that’s not to put down the standards — they’re very welcome and the effort is appreciated).

The real question is — one of the holy grails of content management — when do content or data become information? And how would a CMS help you achieve that? It takes more than just efficient or interoperable storage.

(I could go on, but this is just a comment

However, I’ll take it one step further and say that code is also not content.

I touched on this same topic briefly in last blog post.

http://blogs.citytechinc.com/sjohnson/?p=16

Shane

The purpose of the post was about building systems to help users manage the output of a creative process.

So are you saying ‘content’ is a verb? That doesn’t make sense.

What’s wring with saying “content is data *used* for the expression and communication of information?”

Because – from what I’m reading here – content *is* data, just data used in a specific way.

Seriously, the point of this post is to get beyond the logical/physical storage aspects of content (which is what we tend to dwell on as technologists) and focus on what content means to users. Content is the expression and communication of information. This is significant because the tools that manage content need to be designed with an awareness that they will be used to intermediate in a conversation between human speakers and audiences about things that they care about.

The data (as in 010101011010) might be inert but the spirit that is captured and perceived hopefully isn’t.