Thursday, June 23, 2011


Over the last year, I've been developing strategies that allow publishers to define and identify IP Rights. The big difference between digital rights management (DRM), and IP rights management IPRM is that DRM is about locking down assets to mitigate against piracy. IPRM is about identifying and calculating clearance to use assets for any given context, and enabling publishers to make informed decisions about using specific assets.

ODRL, or Open Digital Rights Language, is a well-established, robust, extensible XML markup designed specifically for this purpose. At it's core is the ability to define relationships between parties, assets, and permissions (i.e., print, display, execute). But it's real power is the ability to express complex permissions that include conditions and constraints. For example, "a licensee can use an asset in a printed book, but the print run is limited to 2,000 copies, and the asset creator must be given proper attribution and will receive two copies of the book prior to its release", or "the asset can be used in print, except that it can't be distributed in North Korea".

This is powerful, and gives publishers the capability to monitor and evaluate rights clearance while the product is in development. Using an XML Database and XQuery, it's relatively trivial to calculate clearances for all assets for a product and to display the information in a dashboard. Editors can monitor the progress of rights clearances against all assets and determine whether to acquire additional rights to use assets that haven't been cleared, or to use other assets instead. Publishers can also track asset usage to ensure that the proper royalties are paid. It also helps publishers in "what if" scenarios: they can easily determine the cost and feasibility of adapting a product for a different market, which will tell them how many of the existing assets are cleared for use in that market and how many remain that either need additional clearance or should be replace with other assets.

Another scenario we're working on is using ODRL for wholly-owned assets. Publishers frequently commission third parties to produce photos, images, and other rich media for which the publisher retains the rights to. They want to reuse these assets for obvious cost savings, however, they don't want to over-expose assets. Frequently, editorial teams are primarily focused on one project or program, and have little insight as to what others are doing, so it's quite possible that an image could be used by more than one product at the same time. Not that this is always a bad thing, but it can lead to over-exposure. Using ODRL to manage access to assets, using embargo dates and other usage information, editorial groups can quickly make informed decisions whether to use an asset or look for another.

Pretty cool stuff


Secured Document Sharing said...


I genuinely loved this brilliant article. It is important to note that digital rights management relies on other technologies to enforce controls. These include encryption and licensing technology that prevents unprotected content from being accessed, and lock protected content to specific licensed machines. hanks for this wonderful post and hoping to post more of this.

Jim Earley said...

Thanks for the compliment! Indeed, a key facet to DRM is the underlying enforcement technologies. In fact, there are technologies that can leverage ODRL for that purpose as well (one of its principle use cases).

IPRM, and asset management as a whole, is just beginning to come into its own, thanks in part to ODRL and other RELs, but in larger part because the publishing paradigm is undergoing radical change. The industry is being pulled (some might suggest that it's being dragged, kicking and screaming) away from print-centric models, and now must transform themselves as "media companies". This shift means that more emphasis and focus has to be placed on better management of the digital assets they own or purchase rights to.

Renato Iannella said...

Great article Jim.

You maybe interested in a whitepaper we wrote back in the IPR Systems days: