The dotBlockchain Music Project — update #7 Minimum Viable Data Doc

dotBC Minimum Viable Data (MVD V1.1) — Bill Wilson

Introduction

The foundation of the modern, digital music business is data. The ideal being a federated system of interoperable datasets, in which each node in the system communicates authoritative, normalized data to other nodes in the system with no human intervention required. The current state of music data is far from that ideal, as the systems between different verticals are not interoperable, and the data at individual companies within those verticals is (typically) rife with errors, and ambiguity. To make matters more complicated, companies also operate at very different levels of technology adoption, and heretofore the industry has been incredibly slow in dealing with these challenges for various reasons.

Dotblockchain music is creating a system that leverages the power of a blockchain ledger to create a standard set of “rails” for the industry to operate on at all levels of sophistication. It provides control to the owners, and transparency where required. More information can be found at http://dotblockchainmusic.com/about-dotbc/ as well as our technical and non-technical webinars.

The problems resolved by the blockchain ledger and associated technology are dependent on the underlying datasets, and what data points are required by each stakeholder. Establishing manageable field sets that are both backwards-compatible and forward looking are equally critical. This iterative document serves as the basis for what information is conveyed in the dotBC format, and will be updated going forward. This first document was completed with the kind assistance of several DSP’s.

What we mean by Minimum Viable Data

The amount of metadata that can be associated with works or master recordings is endless. However, we are concerned with the most essential functions of identifying the original and current owner(s) of a composition or master, and the match of the correct master to the correct composition. For example:

Registration MVD V1.1

Registration MVD V1.1

As you can see from the above, all that is required for a songwriter to get a song into the system is the name of the song and the name of one writer. As dotBC is iterative and this data is not sufficient for commercialization or delivery, it serves as a basic statement of truth about a work that can be amended and updated incrementally, and tracked via blockchain-powered changelog.

Commercial Core MVD V1.1

Commercial Core MVD V1.1

In must be noted that the above list of minimum fields is not a comprehensive set of data. The dotBC superset of information can be expanded to include fields from DDEX ERN, DDEX RIN, CWR, and external crowd-sourced databases. In many cases, the above would be sufficient information for any DSP to accept a recording for commercialization, but some may require additional information (such as GRid, ISWC or ISNI) within their own plug-ins.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.