OASIS CMIS & DAM Interoperability Telephone Conference, October 2nd 2013, 11am ET
On 16th September, OASIS (Organization for the Advancement of Structured Information Standards) hosted a conference call to discuss potential need for a common DAM interoperability standard. As part of that conversation, CMIS (Content Management Interoperability Services) and ICOM (Integrated Collaboration Object Model) were also considered to see how they might provide a basis.
Following an article I wrote for CMSWire last month: The Building Blocks Of DAM Interoperability, I got asked to participate in this call and present some of the key points. There were other speakers also, including, Michael Pollit Making the case for a DAM interoperability standard; David Choy: “How does CMIS fit?” and Ken Baclawski with “How does ICOM fit?” Mike Pollit’s article is here: http://limeboy.com/2013/08/01/towards-a-dam-interoperability-standard/
Reflecting the fact that interoperability has become an important topic DAM, there were a lot of others in attendance on the call, notably from the DAM side, photo metadata guru, David Riecks but a number of representatives of both vendors and larger corporate end users of DAM too.
A lot of the subject areas covered how CMIS might apply to DAM and Mike Pollit especially did a good job of explaining how CMIS might map to a typical DAM scenario and what areas were going to need more attention to start practically using it.
Copies of the minutes of the meetings are available for anyone who wishes to have a look: https://lists.oasis-open.org/archives/cmis/201309/msg00010/DAM-conversation-minutes-2013-09-16.pdf
When I gave my talk, I was mainly following the existing CMSWire piece, however, the following are some of the key points to result during that discussion and my own thoughts after it.
CMIS seems like quite a comprehensive standard, but the implementation appears too onerous to encourage mass-acceptance in DAM at present. I had a conversation with another delegate on the call about the likely time required and figures of 1.5 weeks was discussed as an estimate. That doesn’t seem too bad, however, it appears a somewhat arbitrary assessment (as these things tend to need to be). A lot depends on not only the skill of your development team, but also whether they over-complicate the implementation (or underestimate it, by the same token). A point was made that there are libraries to help with this task – which I can accept make it easier. Still, it requires someone to sit down and spend a few days familiarising themselves and setting another task aside for a while and given that most DAM vendor development teams are already at full stretch, that is quite a big ask.
Based on my experience talking with a number of DAM vendors (mostly medium size ones -but a few larger operators too) this is a chicken and egg situation and they are unlikely to take a gamble that investing into CMIS compliance is worth doing unless they get a specific request for it and at least one customer pays the bill. When interoperability requests get measured up against other functional requirements and capital resources are scarce, the latter nearly always wins. The client’s gratification from enhanced functionality comes up-front whereas integration only becomes an issue when you need to actually do it. As we have covered on DAM News a lot, the DAM industry is currently in something of a features ‘arms race’ where vendors are falling over each other to ensure they can keep ticking all the boxes on RFPs etc so I can see CMIS compliance getting pushed to the back-burner and the DAM interoperability crisis continuing.
Many vendors who know nothing about CMIS take the view that they have an API already so why do they need to create another one? There are obvious flaws in that reasoning, but it points at an issue with standards which is the same as the software itself – it’s one thing developing standards, it’s quite another persuading people to go ahead and use them.
My opinion on this is two-fold: firstly a DAM interoperability standard needs to be as simple as possible – to the point where basic compliance can be achieved in a few hours (which is more feasible if Linked Data techniques are used as we have discussed before). Secondly, there is a lot of demand from IP owners now as a result of legislative trends like orphan works to better secure their copyright. This is generating momentum to support embedded metadata and asset registries. That should be utilised to encourage adoption of any DAM interoperability standard.
Practically all vendors now (large and small) have DAM systems which support the reading of IPTC embedded metadata when images are ingested. That has happened because it is fairly easy for vendors to implement and there is a lot of cross-industry support for these ideas, so anyone who lacks support for it is under some pressure to get that issue resolved.
I do believe that CMIS (with some further modifications) could be a useful standard for DAM – but it is an objective that needs to be broken down further. DAM is not a subset of ECM, no matter how much the ECM interests would like you to think it is. Given the fragmented nature of our market, I am unconvinced that just persuading a few better known DAM vendor brands to join in will solve the adoption problem and encourage everyone else to fall in line. This has to happen across the whole industry and if it comes at the expense of a more ambitious standard in the first instance, then so be it.
I suspect the level of interest perhaps took the OASIS organisers a little by surprise so the time available to conduct a more meaningful discussion wasn’t as long as it maybe should have been, however, a decent amount of ground was covered and OASIS are hosting a follow up call on 2nd October 2013 at 11am(ET). The details are
US & Canada: +1 559-546-1401
UK: +44 (0) 330 606 0192
Access Code: 151031#
The call is open to anyone to join – you don’t need an invite. Given the importance of interoperability currently in DAM, I think it’s important that there is activation participation from all sections of the DAM community so that any resulting standards are as a relevant as possible to actual use cases and will be easy to implement too.
Share this Article: