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
THE IDENTIFIED NEED
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.
API STATUS UPDATE
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