OUR PROCESS
Read more here about our open protocols approach.
Special thanks to Berklee Trustee Dan Harple, Daan Archer, Gavin Nicol, Bas van Oostveen and the Context Labs team for tirelessly spearheading these efforts.
OMI members segmented in five working groups:
Core Functions / Payments / Metadata / Platform Architecture / Identity
5 Plenary Meetings to date
3,000+ 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
API released October 2017 and regularly updated/tweaked
API is designed to evolve naturally, and must evolve
Rough consensus and running code leads to standards that work
Multiple independent implementations exist and future work is already being identified
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.
Currently it is difficult at best, to pay royalties from playback to composers
This is largely because it’s hard to discover who to pay/credit
Most reconciliation processes are manual
THE IDENTIFIED SOLUTION
Query API enables automatic discovery of who royalties should be paid to
Optional registration capabilities
Support federation and auto-discovery of capabilities
EXAMPLE - FEDERATED SEARCH
OMI API adapters to MusicBrainz and Wikipedia
Federated API server connects to both
Federated/Direct connections are transparent to Apps
EXAMPLE - FEDERATED ATTESTATION
OMI API adapters to MusicBrainz and Wikipedia
Federated API server connects to both, and an attestation service
Change is transparent and engenders competition
All slides courtesy Gavin Nicol of Context Labs
API Reference Implementations
Use Cases by WG | Use Case Provider | # of Use Cases |
---|---|---|
Core Functions | YouTube | 1 |
Meta Interworking | Viacom, YouTube, Round Hill | 14 |
Identity, Security & Audit Services | Universal, DDEX | 30 |
Micropayment & Reporting Services | Goldsmiths, 7Digital, Day One Investments | 10 |
Ledger Services/Platform Architecture | Marty Simon, C3 | Note |
Total | 54 |
Use Cases by Market Vertical | Use Case Provider | # of Use Cases |
---|---|---|
Digital Service Providers (DSPs) | Spotify, Viacom, YouTube | 6 |
Electronic Dance Music (AFEM) | AFEM | 15 |
Music for Film and TV/Cue Sheets | LSPA-member | 1 |
Music for Creators: Providing Access to Data | LSPA-member | 1 |
Music Creators: Content Creators Coalition (C3) | LSPA-member | 9 |
Total | 32 |