Special thanks to Berklee Trustee Dan Harple and his Context Labs for tirelessly spearheading these efforts

  • OMI members segmented in five Working Groups

  • Core Functions / Payments / Metadata / Platform Architecture /Identity

  • 5 Plenary Meetings to date (as of July 2017)

  • 2,900 hours of conference calls

  • 50+ use cases submitted by members

  • First draft of Requirements Documentation agreed & ratified by members

  • API specifications (Minimum Viable Interoperability 1.0) developed

  • Official release Fall 2017



To help achieve OMI’s stated mission of assuring “proper compensation for all creators, performers and rights holders of music,” OMI has identified the need to link recordings, musical works, and music rights holders and creators. The value of this is illustrated by this use case:

A complete list of ISWCs matched to recordings provided at an early point in the supply chain would provide a substantial boost when a label is first providing recording data to a digital partner (e.g., Amazon, Apple, Spotify, Tidal). It is sometimes a challenge to get a new DSP partner to pay in a timely and accurate manner - especially for the long tail. Providing a partner with compositional data matched to recording IDs can accelerate the process.

For example, a music distributor that licenses content from a record label usually needs to obtain additional rights from publishers or music rights societies on their behalf, but may not know from whom to obtain those rights. To solve this problem, the works associated with the recordings and ideally the entities that oversee their licensing must first be identified. Addressing this gap in the music industry is crucial for licensing and royalty payments, both in their current form and in advanced future interlinked forms, e.g. derivative licensing.

In short, the global music industry lacks a readily accessible and trustworthy Linkage of Sound Recording to Music Works and Creators/Contributors. As an open initiative, OMI is well placed to create consensus around specifications intended to solve this problem.


  • The API is designed to evolve naturally, and must evolve. Rough consensus and running code à standards that work.

  • Requirements document has been ratified.

  • Apiary documentation is being updated/tweaked.

  • Multiple independent implementations exist.

  • Based on implementation, future work is already being identified

  • Identity, security, field formats, de-duplication, etc.

All slides below by Gavin Nicol of Context Labs