Two weeks ago, I posted a summary of a telephone conference held on 16th September hosted by web standards organisation, OASIS for those with an interest in DAM interoperability to discuss how the CMIS (Content Management Interoperability Services) standard might be utilised. The second call was held on 2nd October, the minutes of which have been released by OASIS and are available here: https://lists.oasis-open.org/archives/cmis/201310/msg00000/DAM-conversation-minutes-2013-10-02.docx
The call covered CMIS and ICOM in more detail with talks delivered by David Choy and Ken Baclawski respectively. For those unaware, ICOM is an acronym for Integrated Collaboration Object Model and essentially interfaces a formalised collaboration model into the CMIS framework. For DAM, it has particular relevance using the ‘Artifact’ branch – which could map to the asset-centric model which DAM users are familiar with. The remainder of the call was a discussion about DAM and how to get it to work with CMIS.
The first call in September was not a bad introduction, but there were limited opportunities for delegates to interact and discuss the points raised by the speakers. The second was far more expressive and useful to get to grips with the issues. I have mentioned on several occasions that I believe CMIS (while a good standard) is currently too sophisticated to enable more widespread adoption in DAM. In particular, I have perceived the attitude among DAM vendors that CMIS-compliance is one of many tasks that they won’t engage in until at least one client subsidises the cost of it, so there is a chicken and egg situation with DAM which is less prevalent in ECM (where CMIS has already gained widespread adoption). My contention is that there needs to be a simpler subset of CMIS which is vastly quicker (and therefore cheaper) to implement so that a wider cross section of DAM solutions could be integrated with CMIS compliant applications.
There were some great contributions made by all the delegates on the follow-up call. Metadata guru David Riecks described how many interoperability exercises involve delimited files like CSV etc which need to be matched up to target fields (especially mapping to standard IPTC definitions). This is the kind of real world DAM interoperability which currently characterises most users (and vendors) experiences of what you often need to do to get two apps to exchange data. I have been involved in IT professionally now for close to 20 years and delimited file data munging exercises never seem to go away, despite the numerous advances in other related fields (I suspect it was probably done the same way for over 20 years before I ever worked in this industry too). Ultimately, I guess the simplicity of the technique implies that they are unlikely to completely disappear for some time to come. However, within certain sectors where data exchange is becoming an absolutely critical task (like Digital Asset Management) it is well overdue for a more powerful, flexible and reliable standard to step up to fulfil that role. CMIS looks like one of the better options on offer – but only if it can be made more accessible than it is now, especially to the increasingly fragmented DAM market.
For me, the killer point of the call was this one by Ray Gauss of Alfresco:
“You could do a DAM model on top of CMIS. CMIS is well architected and could handle that. CMIS is just the highway for the information to get from one place to another. A DAM profile could work here. CMIS didn’t start out to be a complicated standard. There are many players involved and everything in CMIS was put there because it was needed. If we started with a new standard, it would soon be just as complicated and we’d be reinventing the wheel. I think we should split the certification or implementation of the standard for different levels of support—systems could communicate over CMIS Level One or something like that. This would help vendors who don’t want to consume the entire standard all at once.” [Read More]
Ray absolutely hit the nail on the head (from my perspective). The opportunity for DAM developers to leverage some of the interoperability innovations like ICOM is substantial. We have discussed the DAM Value Chain on DAM News and elsewhere extensively this year. Both myself and Naresh have pointed towards a best of breed approach where DAM solutions can be combined in a far more service-oriented and less adversarial or monolithic fashion where vendors try to take on all functionality themselves. But those are all pipe dreams unless there is a baseline standard that everything can interface with – in other words, there’s a lot of value but not much chain to connect it together in DAM right now. CMIS would offer that opportunity and a ‘level one’ route to obtaining compliance as Ray describes would allow a far wider cross-section of the market to participate in CMIS.
OASIS have set up an email discussion group, the details for which are below.
– Send an empty email message to firstname.lastname@example.org
– Watch for an email with the subject line “confirm subscribe to email@example.com.” Reply to this message.
– You will next receive an email with the subject line “WELCOME to firstname.lastname@example.org.”
– Join the discussion by sending messages to email@example.com
This list is publicly visible and anyone can view the archives of the list at https://lists.oasis-open.org/archives/dam-cmis-profile-discuss/
One of the early tasks is to create a Statement of Purpose to describe this process. I intend to participate as actively as I can with this task and any discussions resulting from it. My expectation is that in the earlier stages, this is going to be a somewhat lonely undertaking, however, the opportunity for the DAM industry to properly address interoperability by laying the theoretical foundations of the DAM Value Chain (and to be closely involved in decisions about it) seems too good for me to pass up and I would anticipate many others might have the same view.