We hop into our cars and play music from our mobile phones through the car speakers. It doesn't matter who the device or car manufacturer is, as long as they both add support for the A2DP Bluetooth profile.
We connect our set top boxes to our televisions with a single HDMI cable, again regardless of manufacturers.
We send emails to people in various organizations that use different email server vendors, but we don't need to worry about how our server communicates with theirs, they just both support SMTP.
Specific to Digital Asset Management (DAM), we add captions and keywords to images in common desktop applications and most of us don't have to think about the fact that they're being embedded using IPTC.
The examples are numerous, and we usually take the end result for granted, but those standards take significant time and effort to properly define the problems and come up with solutions that satisfy everyone participating, who sometimes have competing interests.
Disconnected silos of media are widespread in the DAM space. A large organization can have multiple, even tens of DAM systems, usually for different departments. A common thread in the industry is that we need to make it easier to integrate these systems with each other and with the rest of the enterprise so that the entire lifecycle of content can be managed in an efficient manner.
What might those integrations look like?
Metadata. Say a web content management system needs to display an image and a crucial piece of metadata, its credit line for example. There might be several web pages or even separate CMSes using the same image. If that credit line needs to change the CMS users shouldn't have to have to update it in every spot it's used. An integration could be developed to pull the image and data from a central DAM by building a connector between the two systems, but what if the DAM is switched out for another vendor, or there are multiple DAMs from different vendors?
Renditions. Lower quality renditions of rich media files (called proxies in the video world) are often used instead of the much larger original source files for various scenarios. Let's say we have a collaborative review mobile app which can be configured to point to a DAM system in order to use or request these renditions for playback or display. For the app to support DAMs from multiple vendors a connector must be developed for each, assuming the vendor even has a relevant API for the task in the first place.
Rights. Omni-channel customer experience management solutions (Mmmm, words, so buzzy) might need to assemble content and obtain rights information from a DAM before making a campaign live. There again: a different integration needed for each DAM vendor.
Interoperability standards are an obvious answer to these problems.
If we, the DAM ecosystem, build these critical system to system connectors using open standards that many vendors have agreed upon and have ultimately implemented we can be assured we'll only have to do it once and will avoid vendor lock-in.
If you haven't heard, work was started on just such a standard for the DAM industry, CMIS4DAM, designed to work alongside the existing Content Management Interoperability Services standard. It held great promise as an answer to the call that seemed to be coming from many DAM analysts, consultants, vendors, and customers with initial participation from a range of companies and individuals full of vigor to help shape what was to come.
The OASIS technical committee (TC) charter was put forth, uses cases and deliverables were defined, and work started on the specification itself.
Unfortunately the participation waned throughout that process and the monthly meetings now consistently involve only a few attendees.
Without commitment from more individuals, and perhaps more importantly vendors, OASIS will have to shut down the CMIS4DAM TC.
Consider this a call for help.
If you were on the TC and have stopped attending, was there a specific reason?
If you're a DAM vendor interested in improving the DAM technology ecosystem would you consider joining the committee to help develop the specification?
Is there a standard other than CMIS4DAM you feel would be a better match for the DAM community?
Perhaps most importantly, if you're a purchaser of a DAM system and have interest in leveraging these concepts in your implementation, contact your DAM vendor and encourage them participate. Your demands (hopefully) drive their roadmap, let's make sure an open interoperability standard is on it!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.