There’s no widely-accepted standard for DAM data yet

Digital Asset Management (DAM) systems are the hubs for organizations’ creative content. DAMs need to exchange data with other systems all the time: import creative works and metadata from external content providers, export digital assets and metadata to Web Content Mananagement systems and so on. Sadly, none of the various DAM related standards (like the Dublin Core Metadata Element Set Lisa Grimm writes about, or IPTC NewsML G2) have been broadly adopted by DAM vendors. At least not broadly enough that you can expect to exchange data between DAM systems without programming effort. Update:OASIS CMIS4DAM is “in development” for quite a while now, but I’m not too excited about it as participation costs money and I don’t find CMIS particularly easy to implement.

Do we need a new standard?

Inventing a new standard is rarely a good idea. (You’ve probably seen the XKCD comic on standards.) If there is an existing open standard that more or less matches our use case, we better use that one to benefit from the existing documentation, tools, and adoption.

I suggest that we encourage the DAM community to move towards the schema.org vocabulary in an RDF syntax. This is the stuff that already powers large parts of the emerging Semantic Web. It introduces the DAM to the world of Linked Data.

Why schema.org?

The schema.org vocabulary seems quite sensible. But the great thing about schema.org is that it is supported by large search engines: Bing, Google, and more. Which means the SEO guys are picking it up, so businesses will (finally) want to invest money in structured data! The chance of a lifetime for librarians who were struggling to prove DAM ROI, isn’t it?

And it’s good that this vocabulary isn’t DAM specific. Most of the time, DAM interoperability is about dealing with non-DAM systems. They’re not too likely to support DAM standards. I bet the Web CMS market will move towards schema.org soon (because SEO).

Update: The DAM specific stuff that’s missing from schema.org, like more detailed file rendition information, could be added in the form of a schema.org extension.

Why RDF?

That’s a plus – you’ll likely find a syntax that suits you well – but makes it a bit harder to adopt. Even within the RDF/XML format, the same information can be encoded in many different ways. So you’ll likely have to use RDF-aware software (like EasyRDF for PHP) to produce and process RDF. Directly dealing with, say, RDF/XML via XSLT is too hard.

The great thing about RDF is its limitless extensibility. You can easily mix schema.org markup with any schema or vocabulary that specifies URIs, be it IPTC Photo Metadata, RightsML or your own custom schema.