What WCM can learn from DAM

Added By Kas Thomas at 26-Apr-2008 | Twitter: @KasThomas |

Having spent a great deal of time in recent weeks talking to vendors, consultants, and customers in the Digital Asset Management space (in preparing for the upcoming release of our Digital & Media Asset Management Report 2008), it occurs to me that the Web CMS world could perhaps learn a few things from the DAM world.

Established DAM vendors tend, surprisingly often, to be older than the most established Web CMS vendors (predating the Web itself, in some cases). This fact, coupled with the demanding scalability, storage, network-bandwidth, and other requirements of the DAM domain, have given DAM vendors a unique perspective on what it means to manage content.

In the Web CMS world, "content" tends (broadly speaking) to be something that has the potential to convey information. In the DAM world, content is a bit more abstract: it's something with value, hence an asset. The distinction is subtle but important. In DAM, a piece of content does not become an asset until it has been classified, indexed, versioned, secured, stored, possibly reformatted or canonicalized in some way, and (typically) assigned a lifecycle state, a unique ID, and an owner. These are the things that make a piece of content an asset.

What's the key to making it all work? Metadata. In the DAM world, it's what you know about an object that makes the object findable and reusable, thus valuable. These days, it's not unusual for unstructured content to come with its own embedded metadata (in the form of XMP, say), but the general assumption in DAM is that any object, of any kind, regardless of whether it has its own embedded metadata, regardless of whether it's structured or not, should be enlistable as an asset in the system. If an asset comes into the system totally bereft of metadata, information about the object will be extracted, either from the object directly (via rules created beforehand) or from the person who uploaded the object, manually. DAM offerings vary greatly in sophistication with regard to metadata handling, but the point is, nothing gets into a DAM system without some kind of metadata association.

Something else DAM vendors seem to have figured out is that there should be at most one authoritative copy of an asset ("the truth"), from which all other renditions and copies are derived; and the one true copy should live on a file system, whereas the metadata associated with that asset should live in a relational database. "File system" can mean one or more file servers, and/or Network Attached Storage. The noteworthy point is that assets are unpredictable as to size and structure, hence are a poor impedance match for RDBMS storage, whereas they are a good match for a file system.

Keeping metadata in a database, on the other hand, means you can manage information about files separately from the files themselves. You can manage metadata security separately from asset security. You can run sophisticated queries and stored procedures against metadata stored in tables; and you get to enjoy all the advantages of a modern RDBMS in terms of ACID transactions, connection pooling, familiar reporting and data-mining tools, the ability to integrate with other systems, and well-understood best practices around capacity planning, clustering, performance tuning, data backup, and so forth. Metadata tends to be compact and very highly structured, hence is a good match for a relational database (particularly an XML database).

If there's a larger point to be learned here, it's that Web CMS vendors (and their customers) are frequently not thinking abstractly enough about the 'C' in CMS. Content can have structure or not have it. It can be textual or binary. It can be anything. It's what you know about it (and how you manage what you know about it) that matters. Even if your website is mostly text, you can't really depend on your search engine to attach the appropriate meaning to it.

The upshot? Look for Web CMS vendors to add stronger metadata-handling capabilities to their products over the coming 12 to 18 months. The more aggressive vendors will build text-analytics tools into their WCMS products or partner with (perhaps even acquire) text-analytics companies. We can also expect to begin hearing more (much more) about the use of XMP not just in conjunction with media files and PDFs but a wide variety of file types that you wouldn't necessarily expect to be associated with XMP.

And if you're a prospective Web CMS buyer? Give careful consideration to how the products on your short-list deal with capturing, storing, and managing metadata — for all types of files. (Look to Part 3 of our Web CMS Report 2008 for further thoughts on this.) Metadata isn't just for media any more.

 

 

Categories: Kas Thomas, Digital Asset Management, Web Content Management, Industry Standards, Information Architecture, Selecting Technology, XML