Introducing Four Rights Expression Languages: ccREL, PLUS, MPEG 21/5 and ODRL

shutterstock_261713198

This is the second in a series of posts about managing digital asset rights and permissions. The first post in the series examines underlying rights concepts. The next post outlines the steps enterprises should take to implement a rights expression language. These posts are based on Demian Hess’ article “Managing digital rights with rights expression languages”, which appears in the Autumn/Fall 2015 issue of the Journal of Digital Media Management.

Whenever a digital asset is used in a product or relicensed as part of a deal, businesses must go through a rights clearance process to ensure that they have permission to use the asset. Rights clearance is labor intensive because it requires a manual review of rights information recorded in written contracts. This becomes a bottleneck when a company has hundreds or thousands of assets. Indeed, I have worked with some companies who have not been able to monetize their assets at all because of the cost involved in clearing rights.

One solution is to capture rights information using a Rights Expression Language (REL). Using a REL, it is possible to translate a contract into a standard format that can be exchanged between information systems and queried. Rather than manually reviewing each contract, businesses can clear rights automatically.

Despite the availability of many different RELs, none has yet gained widespread adoption and implementation. Few digital asset management systems support standard RELs and most stock photo agencies exchange rights information as unstructured text files using proprietary vocabularies. One researcher speculated that “one of the main impediments to the use of RELs is the complexity associated with understanding and using them.”

This post examines four well-known RELs in order to clarify their purpose and explain when they can be most appropriately employed. Some RELs primarily model and express legal rights, such as copyright, while others focus on rights that have been transferred as part of a commercial transaction. The RELs to be examined are: Creative Commons Rights Expression Language (ccREL), Picture Licensing Universal System (PLUS), Motion Picture Experts Group, Standard 21, Part 5 (MPEG-21/5), and Open Digital Rights Language (ODRL).

Creative Commons Rights Expression Language (ccREL)

Creative Commons is a non-profit organization that seeks to advance the use of open source works. The organization created ccREL to make it easier to determine how open source assets can be reused. According to the ccREL data model, a license contains work properties and license properties. Work properties focus on the resource itself–such as its title and its creator–while license properties specify allowed uses, restrictions, and obligations.

Under ccREL, license properties can allow three types of use: copying, distributing, and altering to make derivative works. Rights holders can also assert a single restriction that specifies whether a work can be reused for commercial purposes. Finally, ccREL can express four end user obligations: 1) a requirement to list the licensing terms of the original work; 2) a requirement to share any derivatives under the same terms as the original asset; 3) the obligation to give proper attribution to the creator; 4) the requirement, for an executable asset, to supply source code on distribution.

ccREL is not capable of expressing the fine-grained constraints and actions usually required by commercial licenses. For example, a stock photo house could not use ccREL to license an image for use in the interior of 10,000 copies of a textbook distributed within North America. This is not a ccREL oversight, but rather reflects the fact that commercial licensing concerns are outside the scope for which ccREL was designed.

ccREL example

Example of the license properties portion of a Creative Commons, Attribution, Non-Commercial, No-Derivative license expressed in RDF XML. The license requires the user to post a notice of the type of license and to give attribution to the creator. It also permits redistribution and reproduction of the asset, but prohibits commercial use.

Picture Licensing Universal System (PLUS)

PLUS is a rights language developed by the PLUS Coalition in order to simplify licensing images. Building a license corresponds to navigating through a taxonomy of terms called the PLUS Matrix. Each choice has a corresponding 4-character code, and all the codes chosen are concatenated together and embedded into the license as a “code summary”. For example, when creating a license, the user first chooses from seven different use categories that include “Advertising” and “Editorial”. If “Advertising” is chosen, then the user must choose from 16 different media types; if “Editorial” were chosen, then there would only be seven media types. Users continue making choices until all the terms of the license have been assembled.

The benefit of PLUS is that it makes it possible to generate complex licenses that capture obligations, actions and constraints in a granular and machine-readable format. However, the specificity of PLUS comes at a price. The taxonomy that forms the core of the language is only intended for images and imposes a rigid hierarchy on how assets can be used. If an organization needs to license other types of digital assets or employs a business model that does not match the PLUS Matrix, then the PLUS licensing model will not capture the required terms.

 

Graphic representation of the PLUS Matrix

Graphic representation of the PLUS Matrix. Users make choices from a hierarchy, with each choice (represented by a node in the graphic) being assigned a 4-character code.

Motion Picture Experts Group, Standard 21, Part 5 (MPEG-21/5)

The Motion Picture Experts Group has issued a suite of standards for creating, distributing and consuming digital assets. Part 5 of the suite includes a rights expression language that is typically identified as “MPEG-21/5”. The standard also includes a data dictionary (Part 6), which contains approximately 2,000 standard terms that can be used within the REL.

An MPEG-21/5 license is created by an Issuer and contains one or more Grants that target Resources. Each Grant gives a Principal (i.e., an end user) the right to access the given Resource, although that right can be limited by Conditions. In the MPEG-21/5 model, a Condition can either be a requirement that the user must meet, such as making a payment, or it can be a constraint, such as an expiration date.

MPEG-21/5 is intended for use within commercial licensing workflows, where a user has purchased an asset and a control system must decide whether the user is allowed to access it. In other words, the language focuses on enforcing access rules and, as a result, the standard specifies a complex set of algorithms and requirements for identifying parties, establishing trust, and calculating permissions.

One potential problem that arises when using MPEG-21/5 is the way that the specification is distributed. The International Organization of Standardization (ISO) ratified MPEG-21 in 2004 and the specification is only available for purchase through the ISO web site. At the time of this writing, a single-user copy of Part 5 of the standard costs 198 Swiss Francs, with a separate charge for every other part, such as the data dictionary. While not exorbitant, the cost can be an impediment for organizations seeking to evaluate the standard, particularly if it needs to be reviewed by multiple users.

Open Digital Rights Language (ODRL)

ODRL is intended to facilitate the licensing, distribution, and consumption of digital media. ODRL is frequently compared to MPEG-21/5 because both are general-purpose RELs suitable for recording the terms of commercial licenses. ODRL is currently maintained by the ODRL Community Group of the World Wide Web Consortium (W3C), a web standards body. The ODRL specification includes a rights expression language as well as a small data dictionary that lists standard terms for permitted actions, obligations, and constraints.

An ODRL license, also called a Policy, can contain both Permissions and Prohibitions. These entities either permit or prohibit Parties from performing specific Actions on targeted Assets. Actions can be limited by Constraints, and Permissions can impose Duties on specific Parties before their corresponding Actions can be executed. A unique aspect of ODRL licenses is that one Policy can inherit terms from another Policy. For example, if a child policy does not specify a time constraint, but its parent has such a constraint, then the child inherits the constraint. The purpose of inheritance is to make it easier to establish master policies that are then reused.

While ODRL provides a sophisticated expression language, it has been criticized for not capturing all necessary terms. For example, the ODRL core model does not provide a way to capture copyright information. Similarly, although ODRL makes it possible to assert that an end user must give attribution before an asset is used, the standard does not provide a single, clear mechanism for recording the exact text of the attribution.  Another limitation of ODRL is that it does not resolve the ambiguity of licensing terms, particularly in regard to constraints. For example, an ODRL license may specify that an asset can only be used within a specific industry, but the ODRL data dictionary does not list any terms to identify those industries.

Unlike languages like PLUS, which defines all possible terms and their usage, ODRL provides a grammatical structure for expressing licensing information, but users must develop their own verbs, nouns and semantics. The ODRL documentation recommends combining ODRL expressions with controlled vocabularies developed by industry-specific organizations, such as PLUS, Dublin Core, and the International Press and Telecommunications Council (IPTC). The ODRL Community Group also encourages users to extend ODRL, a process known as creating a “Profile”, for specific use cases. IPTC has developed an ODRL profile called RightsML, and other organizations such as Creative Commons and IDEAlliance are developing their own profiles.

ODRL example

ODRL license expressed in Javascript Object Notation. This license states that the license holder is permitted to play the specified online game until 12/31/2010.

Implementing a REL

RELs are developed for specific purposes, but all build on common concepts of legal rights, permissions and restrictions. For any given permission or restriction, there is normally a corresponding action, user obligation and constraint. By using a REL, a business can encode its licensing information in a format that can be read by information systems and automatically processed. Selecting a REL is not trivial, however, and neither is creating a system to read and store the information expressed in the language. My next blog post provides a high-level overview of selecting and implementing a suitable rights language so that your business can make an informed choice.

If this topic interests you, then you can follow me on LinkedIn to receive a notice when I publish the next posts in this series.  Alternatively, follow Avalon Consulting on twitter and you’ll receive the link when it is tweeted out.

Demian Hess About Demian Hess

Demian Hess is Avalon Consulting, LLC's Director of Digital Asset Management and Publishing Systems. Demian has worked in online publishing since 2000, specializing in XML transformations and content management solutions. He has worked at Elsevier, SAGE Publications, Inc., and PubMed Central. After studying American Civilization and Computer Science at Brown University, he went on to complete a Master's in English at Oregon State University, as well as a Master's in Information Systems at Drexel University.

Leave a Comment

*