In this article I am going to assess various approaches to interoperability and examine some building blocks which if combined could offer a universal, scalable and relatively easy to implement framework.
Why Current Interoperability Methods Are Unsatisfactory
Most DAM vendors now offer an API that enables third party access to their data.Using them for actual integration tasks, however, is a harder task than it appears -- especially if there are multiple DAM systems involved.
Proprietary DAM APIs
Many DAM APIs use web protocols like REST or SOAP but each still has its own conventions, methods and terminology.Although developers can re-use their knowledge to work with them, the specifics generally require amendments for each different product and they often find they have to code separate libraries.The work involved to maintain interoperability with these multiple asset sources using their APIs is becoming an excessively time consuming (and sometimes confusing) undertaking.
CMIS And DAM Systems
There are some standards emerging for exchanging data across ECM systems.One example is CMIS (Content Management Interoperability Services).CMIS is comprehensive and provides a generic layer of abstraction to allow third party applications to access data within other CMIS-compliant systems in a consistent fashion.
There is a school of thought that claims that CMIS-compliant DAM systems might one day be the only interoperability game in town and all DAM vendors will eventually need to support it.I do not know if that prediction is accurate, but I suspect that even if it is, it might take some time to occur.I would agree that CMIS offers many (if not all) the interoperability features that DAM systems could make use of, but the adoption of CMIS in DAM faces some significant challenges.
The DAM market is highly fragmented and is composed of hundreds of vendors.There is a good reason for this.Digital Asset Management describes an ever widening scope of user requirements.Lots of people from all kinds of backgrounds think they are uniquely placed to understand and implement DAM.Each of these groups develop their own unique DAM applications based on their widely differing understanding of what DAM means.The development teams responsible are similarly varied and range from lone bedroom coders right up to those with multiple global offices and hundreds of staff.
Some DAM vendors have already committed the investment required to providing this in their solutions, but most have not and probably have no immediate plans to either.It could be argued that you should only deal with DAM vendors who offer CMIS compliant applications, but there are further standards out there.oData (Open Data Protocol) is supported by Microsoft (they also back CMIS too).The Open Archives Initiative Protocol for Metadata Harvesting (OA-IPMH) is another standard.There are several others I have not mentioned.
It is a somewhat easier proposition for larger vendors to hedge their bets across multiple standards and then just drop the one(s) that don't gain traction.However, those DAM vendors with more limited budgets and resources have to adopt a "wait and see" approach before they press ahead with complex and expensive implementation work only to find it was a waste of time and effort.They will still be acquiring new clients and extending their products in the meantime (and building out their own custom APIs too).
The practical reality is that when integration tasks come up, you usually don't get any opportunity to decide what you need to interoperate with, only that someone, somehow has to make it all happen -- and this is where we came in with proprietary APIs.
Simpler DAM Interoperability Solutions
I should stress I am not criticizing any of the standards like CMIS, but they are still a functional tier above what many DAM vendors are currently willing or able to offer. There is a pressing need to find more immediate interoperability solutions that are more likely to be implemented by many vendors. That requires simpler techniques that can be assembled in a more bottom-up fashion.
There are potential answers to this problem emerging.They originate from different sources, but some synthesis between them might provide the basis for an interoperability framework.There are four elements:
- Linked Data
- Unique Global Asset Identifiers
- Asset Registries
- Embedded Metadata
Some of the inspiration for the approach I am discussing has been derived from some articles by Tim Strehl, a German DAM developer whose blog we feature on DAM News, including:
- Image metadata on the Web: URL as identifier
- Linked Data for better image search on the Web
- Semantic markup for “You can license this image”
The essence of the idea is that using a protocol like RDFa, it would be possible to provide a metadata schema that describes an asset.Independent systems can extract this data and use it for interoperability purposes (e.g., to search it).Those familiar with the Semantic Web will probably grasp what is being proposed here.Some common metadata standards such as Dublin Core Metadata (DCMI) have already been in circulation for nearly two decades and while they still don't cover every possible scenario, they are well placed to form the basis of a descriptive metadata template.
Unique Global Asset Identifiers
If you purchase a book, it will almost certainly have an ISBN number that uniquely identifies it and can be used to find out the title, author, publisher, etc.DAM interoperability would benefit from a similar universal classification system.If it is was possible to assign assets an identifier that remained consistent irrespective of where it was stored, then tracking and exchanging metadata would become a much simpler proposition in the same way that managing catalogues of printed books has been made simpler because of ISBN.
There are some initiatives that have been set up to provide a scheme like this, including the International DOI Foundation (IDF).This conveniently introduces the next topic: asset registries.
Orphan works are on the legislative agenda in many countries.In simple terms, this means that assets like images can be used without originator permission if no obvious copyright information is available.The burden of proof is on the asset owner to ensure that prospective asset users are made aware of any licensing restrictions.
Photo registries such as the PLUS coalition have been established to help provide a centralized license repository (and to allow retention of other asset license information).PLUS stands for Picture Licensing Universal System.Image copyright owners can register their images with PLUS to reduce the likelihood of an image being deemed an orphan work.In addition to registering images, PLUS has a License Definition Format (LDF) which defines fields that are embedded into the asset itself also as XMP data.
David Riecks and other members of the Photo Metadata community have successfully managed to get embedded metadata on to the agenda for DAM software developers (in addition to a number of other websites and public image repositories).Most DAM systems will now at least read common formats like IPTC or XMP (and often write them too).
The advantage of embedded metadata is that it ensures that asset metadata always accompanies the asset.A common reason for doing this is to protect licensing information and to reduce the possibility of images especially becoming orphaned works.In this DAM Coalition article, David Riecks discusses methods for locking metadata (or at least proving that it has been modified) which have relevance to this discussion.One of the techniques described is using embedded metadata to store an ID that links it to a registry such as PLUS.The motivation for this is to preserve metadata and prevent copyright information being removed.
Bringing the Components Together
The building blocks for interoperability appear to already be in place and it is conceivable to see how they could be made to work together.
None of the methods I have described are complex to implement into DAM products as vendors either use them already or (in the case of the Linked Data techniques) they are fairly simple modifications to existing outputs used to populate existing APIs -- which can still be retained for more specialized operations.
A lot of the work carried out by those with an interest in preserving copyright and licensing could be re-used to validate interoperability and asset registries like PLUS might provide the same role for digital assets that domain name registries do for the DNS system that is a core service across the internet.
As well as the ability to enforce or verify copyright, asset registries, unique identifiers and embedded metadata have an equal role to play in providing interoperability between DAM systems.
There are a number of limitations which I have not considered in this article.One of the major stumbling blocks is getting agreement on which of the standards discussed should form part of a unified DAM interoperability protocol.I do have to note that this agreement has already been achieved with CMIS - although the number of ECM vendors is a smaller field of much larger operators.
I do not claim to have all the answers to all such problems, however, there is enough common ground to at least get a basic description of an asset and then further enhancements can be built upon that.As the saying goes, "the perfect is the enemy of the good" and it seems this is especially true where DAM interoperability is concerned.
Because of legislation like orphan works, additional commercial pressure might come from IP owners who may soon insist any system where their assets are stored must both interoperate with asset registries and preserve their embedded metadata.There is an opportunity to align the interests of intellectual property owners with those of software developers and other DAM users to provide an interoperability framework which has multiple benefits for different parties and is not technically demanding (and therefore expensive) to implement.
Title image courtesy of Laborant (Shutterstock)
Editor's Note: To read more by Ralph, see his Real World Digital Asset Management ROI