Digital Asset Management (DAM) systems are the hubs for organizations\u2019 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<\/a>, or IPTC NewsML G2<\/a>) 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:<\/em> OASIS CMIS4DAM<\/a> is \u201cin development\u201d for quite a while now, but I\u2019m not too excited about it as participation costs money and I don\u2019t find CMIS particularly easy to implement.<\/p>\n\n\n\n Inventing a new standard is rarely a good idea. (You\u2019ve probably seen the XKCD comic on standards<\/a>.) 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.<\/p>\n\n\n\n I suggest that we encourage the DAM community to move towards the schema.org<\/a> vocabulary in an RDF<\/a> syntax. This is the stuff that already powers large parts of the emerging Semantic Web<\/a>. It introduces the DAM to the world of Linked Data<\/a>.<\/p>\n\n\n\n The schema.org vocabulary<\/a> 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<\/a>, 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\u2019t it?<\/p>\n\n\n\n And it\u2019s good that this vocabulary isn\u2019t DAM specific. Most of the time, DAM interoperability is about dealing with non-DAM systems. They\u2019re not too likely to support DAM standards. I bet the Web CMS market will move towards schema.org soon (because SEO).<\/p>\n\n\n\n Update:<\/em> The DAM specific stuff that\u2019s missing from schema.org, like more detailed file rendition information, could be added in the form of a schema.org extension<\/a>.<\/p>\n\n\n\n There\u2019s various well-supported syntaxes for representing RDF data: RDF\/XML, RDFa<\/a> (embedding RDF within HTML), JSON-LD<\/a>, textual formats like Turtle<\/a>\u2026<\/p>\n\n\n\n That\u2019s a plus \u2013 you\u2019ll likely find a syntax that suits you well \u2013 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\u2019ll likely have to use RDF-aware software (like EasyRDF<\/a> for PHP) to produce and process RDF. Directly dealing with, say, RDF\/XML via XSLT is too hard.<\/p>\n\n\n\n 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<\/a>, RightsML<\/a> or your own custom schema.<\/p>\n\n\n\n Me, of course. Mark Davey of the DAM Foundation is also in favor of schema.org, apparently, see this tweet by Jeff Lawrence<\/a> or this video<\/a>. Update:<\/em> Margaret Warren<\/a>, too (ImageSnippets). And Lisa Grimm<\/a>.<\/p>\n\n\n\n How about you?<\/p>\n\n\n\n Related blog posts: Web of information vs DAM, DM, CM, KM silos<\/a>. XHTML+RDFa for structured data exchange<\/a>. Dreaming of a shared content store<\/a>. Update:<\/em> DAM and the Semantic Web \u2013 our webinar on Dec 9th<\/a>.<\/p>\n\n\n\n Update:<\/em> For example schema.org RDF\/XML markup, see schema.org markup for a DAM system photo record<\/a>.<\/p>\n\n\n\nDo we need a new standard?<\/h3>\n\n\n\n
Why schema.org?<\/h3>\n\n\n\n
Why RDF?<\/h3>\n\n\n\n
Who\u2019s in?<\/h3>\n\n\n\n