4.1 Introduction

The music industry in the United States today represents one of the most complex business ecosystems– one that is currently facing a number of challenges impacting all the entities in the music supply chain [1]. These challenges are due to a number of factors, including the emergence of new delivery mechanism (e.g. digital music streaming), the change in listening habits of the younger generation of audiences, the changing notions of music ownership by consumers, the complex legal arrangements around music copyright, and other factors.

Today artists and musicians are part of the gig economy and function much as gig-workers. They are finding it increasingly difficult to make a sustainable living as artistic creators [2] [3]. Many feel they lack visibility into state of license issuances of their works, and therefore to the projected incomes. For many songwriters and musicians, royalty payments for licenses may take several months to arrive. In many cases, the actual songwriters or artists for a given musical work are considered to be “un-attributable” – which leads to payments languishing in escrow accounts around the world unclaimed by the songwriters to whom the payments are due [4].

The industry itself as a whole has not invested sufficiently in technological advances (e.g. digital delivery, cloud services, digital identity, etc.), and has in fact turned down various new opportunities related to digital music over the past two decades (e.g. Naspter case in the late 1990s [1]). The net result is a music ecosystem today that still uses outdated accounting setups (e.g. exchanging Excel spreadsheets), leading to gross inefficiencies, confusing royalty statements and delayed payments, with music being tagged incorrectly leading to mistakes in attributions [2].

In this chapter, we look at the notion of data cooperatives in the context of artists and musicians as gig-workers, and how the management of music-related rights and licensing on a shared platform can reduce cost and operational complexity. We discuss the RAIDAR project [5] from MIT and the Berklee College of Music as an example of how future IT infrastructures need to be developed based on design principles that place emphasis on the owners of music-related rights.

4.2 Data Cooperatives: a Brief Introduction

Over the last decade there has been a continuing decline in trust on the part of individuals with regards to the handling and fair use of personal data [6] [7]. The public is increasingly aware of the power of big data combined with advanced analytics and artificial intelligence. They are also increasingly aware of the power wielded by social media platforms in influencing their daily lives, ranging from influencing the types of advertisements they see on websites and in the media, to the types of good and services they purchase online. Pew Research reported that 91 percent of Americans agree or strongly agree that consumers have lost control over how personal data is collected and used, while 80 percent who use social networking sites are concerned about third parties accessing their shared data [8].

The World Economic Forum (WEF) has already reported on the state of declining trust in its 2014 report on personal data [7], and recommended ways to remedy the situation. These recommendations include (i) increase in transparency by providing individuals with insight and meaningful control, (ii) improve accountability by orienting throughout the value chain (front-end to back-end) with risks being equitably distributed, and (iii) empowerment of individuals by way giving them a say in how data about them is used by organizations and by giving individuals the capacity to use data for their own purposes.

At the same time as this decreasing trust with regards to the handling and fair use of personal data, there has been a change in the employment patterns of many people through the emergence of the gig economy characterized by non-traditional, independent, short-term working relationships. In some cases, new technological platforms have paved the way and enabled the emergence of new kinds of gig employment previously unavailable (e.g. car ride-sharing services). However, the same technological advances that enabled the emergence of new forms of gig employment may also hold individual participants as captive and dependent for their livelihoods on these gig-enabling platforms.

Our notion of a digital data cooperative follows from the recommendation of the 2014 WEF report. We define the data cooperative in Chapter 2 as a member-owned organization that has a legal fiduciary responsibility to its members in the access, management and use of the members’ personal data for their benefit. In its simplest form the data cooperative could be one where a group of individuals with a common purpose voluntarily pool together access to their personal data, digital assets and other rights.

There is a range of things that members within a data cooperative can share with each other. We refer to these broadly as “personal data”, which may range from data generated by electronic devices (e.g. location data) as a by-product of using the device, data generated from using a 3rd party services (e.g. telephone call data records), to biomedical data unique to a person (e.g. DNA sequence, etc.). Data may also include those generated as a result of specific types of work (e.g. hospital schedule sheet for a nurse) or produced by the work itself (e.g. compositions by a songwriter, number of views on social media, etc.). The exact data being shared depends on the nature and purpose of the cooperative and must be defined by the members of the cooperative. The cooperative may also provide digital identity management to its membership [9].

Members of the cooperative may store their personal data and digital assets at the data cooperative (e.g. in its cloud infrastructure). Alternatively, they can store these elsewhere (e.g. in personal data stores) and make a copy remotely accessible to the cooperative [10]. Being a member-owned and voluntary organization, an individual person is free at any time to leave the cooperative and remove their personal data and other assets from the cooperative. A member retains legal ownership rights over their data and digital assets.

4.3 A Data Cooperative for Artists & Musicians

A comprehensive discussion of the music industry is beyond the scope of the current work and has been treated elsewhere (e.g. see [1] [11]). However, in order facilitate the discussion, we provide a high-level summary of the roles and tasks of the most common entities in the music license supply chain (see Figure 2). When a composer or songwriter creates a musical work, such as a music composition or score, they obtain copyright as soon as the musical work is realized (e.g. transcribed on a piece of paper). In order to facilitate the licensing of the composition, the songwriter typically engages a music publisher who may additionally manage the business relationship (e.g. manage contracts) on behalf of the songwriter. When a record label seeks to create a sound recording of the composition performed by a recording artist, the record label must obtain a mechanical license from the music publisher (or directly from the songwriter). The term “mechanical” derives from the days of the use of a physical devices (tape roll) or physical mediums (e.g. LPs or compact discs) as the primary means of making the sound recordings available to consumers.

Similarly, when a music streaming provider (e.g. Spotify, Pandora) – referred to more formally as digital service providers (DSP) – seek to offers streaming services to consumers, they must first obtain the appropriate performance license from the record labels who owns the legal rights to the sound recordings. In order to collect and disburse royalties generated from digital performances (e.g. streaming) the US Congress established a non-profit collective rights management organization called SoundExchange (SE) in 2003. One of the key roles of SoundExchange is to set the royalty rates for digital performances. On the music publishing side, an organization called the Harry Fox Agency (HFA) that was founded in 1927 has the task of managing, collecting and disbursing the mechanical license royalty-fees on behalf of the music publishers in the United States.

One of the noted side effects of the rise of mobile devices is the change in the listening habits of consumers. Increasingly consumers desire for ``music on demand’’ to be available through their mobile devices, even when these mobile devices are disconnected from the Internet. Furthermore, the mechanisms for the distribution of music has changed with the increase in service quality of Internet access providers. Thus, consumers are able to obtain digital (digitized) music over the IP Internet, instead of from traditional broadcasting mediums such as the radio or television. Consequently, a number of DSPs – such as Spotify – have moved away from the traditional performance license models used by the recoding labels for physical distribution (e.g. LP or CD). The net effect has been a reduction in the revenue made my recording artists and musicians, as reflected by the sheer number of artist-driven lawsuits against Spotify. Since most artists and musicians obtain more revenue from live performances or “gigs” than digital streaming, they have increasingly become gig-workers in the true sense of the word.

The Berklee College of Music and MIT have been spearheading an effort called Open Music to explore new technological means and new incentives mechanisms to enable a new open music ecosystem to evolve. One outcome of this joint effort has been the formation of the Open Music Initiative (OMI) [12] in 2017 as a forum for discussion regarding the various aspects – technological, business, employment models – of the future music industry globally.

We believe that artists and musicians as gig-workers would do well in forming communities based on the notion of the data cooperative. In the following we discuss some aspects of such a data cooperative.

4.4 Shared Repositories for Musical Works and Artists Personal Data

One of the significant issues in the music supply chain today is the lack of consistent, complete and authoritative information or metadata regarding the creation of a given musical work – namely the individual composition or a sound recording track. In many cases multiple entities in the music supply chain have each created their own version of the metadata for a musical work, often by manually re-entering the same information or through scraping data from other sites [13]. In such cases, the effort to synchronize or to correct the information becomes manually laborious and error-prone. Furthermore, confidential information regarding the legal ownership of the musical work is often commingled in the same metadata, making the entire database proprietary and thus closed. Currently the music industry have created standards for metadata file formats (e.g. DDEX based on XML), but the industry as a whole does not as yet have widely adopted standards which define the processes or workflows by which creation metadata is collected, displayed and validated. This lack of standards for metadata workflows is only one of the many problems plaguing the industry as a whole (e.g. see [2] [3] [4]).

We believe the music industry needs to move to an alternative model for creation metadata following the open access paradigm found in other industries, such as in book publishing, library systems and in the automotive parts supply chain. Creation-metadata needs to be separated from rights-ownership metadata as well as from licensing-metadata. The creation metadata must not include the actual musical work itself (e.g. sound recording MP3 file) and must not carry the legal ownership or copyright information of the musical work.

The notion of a data cooperative is appealing here as means to help communities of artists and musicians in managing their musical works, including the creation of authoritative metadata on a shared IT infrastructure. This allows its members to manage their metadata files and musical works (e.g. MP3 master file; song composition files) at a lower cost while retaining control over these valuable assets. This is illustrated in Figure 3 (a).

4.5 Shared Ledger for Music Metadata Registration

Distributed ledger technology and blockchain systems [14] has captured the attention of many artists and musicians in the past few years as a potential new paradigm that may help them obtain a more accurate indicator regarding the consumer adoption of their musical works and provide them a more sustainable way of making a living through a more direct transactions and payments cycle [3].

A data cooperative for artists and musicians can make available distributed ledgers to enhance and automate tasks or functions related the music rights and licensing. For example, the cooperative can establish a metadata registry ledger to which members can register their creation metadata. The entries of the ledger includes a globally unique resolvable identifier that allows anyone to follow the linked identifier to a copy of the complete creation metadata somewhere on the Internet. This is illustrated in Figure 3 (b).

There are several possible benefits to such an approach. The “publishing” of the signed registry-metadata file of a musical work onto the registry ledger provides legal support to the copyright claim on the part of the creator(s). The distributed ledger as a whole acts as “notarization” service where only the cooperative members have write-permission to add new entries to the ledger, while anyone in the public can read the metadata and validate the digital signature via the ledger transaction entry. This notarization using a distributed ledger provides a relatively immutable and non-repudiable timestamped public evidence of the existence of the musical work.

A second benefit of the metadata registry ledger is that together with the metadata repository it becomes the authoritative source of provenance information regarding a given musical work. By being the open-readable registry for musical works metadata, the registry ledger effectively becomes the trusted source (or an “oracle of truth”) for metadata that can then be referenced (linked to) by other types of ledger-based transactions, such as smart contracts that handle license issuance and rights-ownership exchanges. Even existing systems (e.g. legacy databases) can thus refer to the relevant entries (e.g. transaction-id) in the registry ledger.

4.6 Smart Contracts for Music License Management

Artists and musicians see distributed ledgers and smart contracts as a promising avenue for a more direct transaction engagement model. Smart contracts as stored procedures or functions (i.e. code) available on the nodes of the P2P network offers a number promising capabilities for increasing the efficiency of business workflows. In the context of the music contracts supply chain management, there are several possible applications of smart contracts implementing different business logic associated with different phases of the contracts supply chain. Thus, for example, smart contracts could be used to implement the logic of the following tasks: (i) the licensing of music copyrighted works (e.g. performance license and mechanical license); (ii) the tracking of payments for granted licenses; (iii) the disbursement of royalty payments to the correct rights-holders; and (iv) the revocation of granted licenses or automatic expiration.

A data cooperative for artists and musicians could help their membership generally with authoring smart contracts for specific ledger systems. This allows the community to standardize on the legal terms of the license, leaving the pricing decision to each artist/musician. The sharing of common “templates” of smart contracts provides a way for artists to save on legal costs. A second possible role for a data cooperative is to operate a distributed ledger for its membership, and possibly for other data cooperatives. This approach allows different data cooperatives around the world to share the costs of operating the shared ledger.

A sketch of this workflow and a copyright license management ledger is shown in Figure 4. Here, a composer or songwriter employs a smart contract for the purpose of allowing other entities (e.g. music publishers, other artists, etc.) to obtain a license for the composer’s musical work. The composer must first record the metadata to the metadata registry ledger in order to allow the smart contracts later to unambiguously refer to (point to) the musical work being licensed. This provides precision of licensing in the case that several version of the musical work exists (e.g. different length of sound recordings). This is summarized in Steps 1 to 3 in Figure 4. In the simplest implementation, the smart contract code could be one that incorporates the legal prose of the license agreement (referred to as Ricardian smart contracts [15]) and where the code simply applies the digital signature of the licensee.

When a licensee (e.g. music publisher) seeks to obtain a copyright license to a given composition, the licensee needs to employ the correct smart contract on the license management ledger. Depending on the specific implementation of the smart contract, the licensee may be required to make a payment in advance (e.g. using separate payment mechanism) and provide evidence to the smart contract regarding this payment. This is summarized in Steps 4 to 7 in Figure 4. If a payments ledger is used, then there is also the opportunity for a “splits” smart contract (Step 9) to be used to automatically disburse the payment portions to the correct rights holders in the case that the copyright is jointly owned by multiple people (e.g. composition created by multiple songwriters).

4.4 The MIT-Berklee RAIDAR Project

One of the significant issues in the music supply chain currently is the lack of consistent, complete and authoritative metadata regarding the creation of a given musical work. Similar to other supply chains (e.g. containerized goods in shipping), accurate information is needed about an item in order for entities across the supply chain to be able to synchronize their business processes. To this end, the Connection Science group at MIT and the Berklee College of Music are leading an effort to begin developing technical solutions for standardizing the various constructs around an open access music metadata layer [16] [5]. The goal of the project is to explore the various technical issues in creating an interconnected set of metadata repositories, and to understand how this new open access music metadata layer can become the basis for future music-related transactions on a distributed ledger or blockchain system. Here we use the term creation metadata or simply “metadata” to denote the factual information regarding a given musical work (e.g. composition, sound recording) without including the musical work itself (e.g. sound recording files).

Currently the music industry have created standards for metadata file formats (e.g. DDEX based on XML), but the industry as a whole does not as yet have widely adopted standards which define the processes or workflows by which creation metadata is collected, displayed and validated. Often different parts or “fractions” of metadata are kept at different locations by different entities along the music supply chain [13]. Given that data accuracy is largely a solved problem in other industries (e.g.financial industry) that employ technologies based on advanced distributed databases and tightly-synchronized transactional systems (e.g. NASDAQ, NYSE, etc.), we believe that this music metadata problem should be the first and foremost challenge the music industry needs to collectively address today. This lack of standards for metadata workflows is only one of the many problems plaguing the industry as a whole (e.g. see [2] [3] [4]).

In this section we use the general term of musical work to denote the individual song, composition or track, and we consider a song composition and recorded song as two separate musical works. This holds true even for a song where the songwriter/composer and recording artist/performer are the same person. We use the term creation metadata to refer to factual information regarding a given musical work. The creation metadata must not include the actual musical work itself (e.g. sound recording MP3 or WAV) and must not carry the legal ownership or copyright information of the musical work. This is akin to the bibliographic description of a book stored by the Library of Congress and other libraries, which does not include the book itself and does not include information on the current legal owner of the copyright of the book. We use term rights metadata for information pertaining to the legal ownership of rights to the musical work. In many circumstances, rights-metadata may be considered confidential, and thus in those cases it should not be made available to the public. We use the term distributed ledgers (or simply “ledger) to denote the broader notion of blockchain systems and networks. This allows the constructs described in this chapter to be implemented using a variety of ledger implementations (e.g. Ethereum [17], R3/Corda [18], Hyperledger [19]).

Thus, for each atomic unit of metadata information for a given musical work (e.g. one song or track), there should be exactly one authoritative creation-metadata file for that unit. This authoritative creation-metadata file must be digitally signed, and be publicly readable from multiple metadata repositories around the world. Its digital signature provides a means to detect unauthorized modifications to the file. If a given musical work has several versions (e.g. original release, remix, etc.), then a separate creation-metadata file must be generated and signed for each.

The availability of a single authoritative creation-metadata file for each musical work allows computing processes and systems to operate based on unambiguous metadata. When a computer program (e.g. traditional software; smart contract) implements the licensing function of a musical work to a licensee, the licensee (person or business entity) can “point” the smart contract to the exact creation-metadata file of interest. If a musical work has several versions (e.g. versions of sound recordings) and if the licensee seeks to obtain a license for all of these versions, then the licensee can point to each of the relevant creation-metadata file corresponding to each of the versions. As such, we believe this open access music metadata layer is crucial for reducing the complexity of business transactions, reducing the error rate due to mis-identification of musical works, and thus reducing the overall cost of operations for all entities in the music supply chain.

Design Principles

There are several design principles that should be the foundation for the technical architecture of the music metadata layer:

• Data collection upstream at point of works creation: Artists, musicians and relevant production-side entities (e.g. studio engineers, producers, managers, etc.) need to be empowered with the correct and intuitive tools (e.g. softwares) to capture the creation information into a metadata file and to digitally sign it (locally) as a means to assert a claim of “authority” over the provenance of that metadata. Existing systems, such as Digital Audio Workstations (DAW), may be a suitable point in the supply chain at which factual information regarding the creation event can be captured.

• Separation of creation metadata from rights-bearing musical works: Musical works (e.g. compositions, sound recordings) must be separated from creation-metadata files for privacy reasons and copyright enforcement reasons. Several access control models, mechanisms and solutions exist in the market today to provide protected access to these valuable resources (e.g. OAuth2.0 [20], OpenID-Connect [21], UMA [22] [23]).

• Separation of ownership information from factual creation metadata: Ownership information should be separated from creation metadata. This is because the ownership information may be confidential and because often the ownership to a given musical work may be sold/acquired over time. Any change of ownership must not alter the creation metadata.

• Open data access philosophy to creation metadata: The music metadata layer should adopt an open access philosophy which is already common today in other industries and sectors.

• Many publications today (e.g. books, magazines, journals, etc.) have adopted the open access philosophy for the purpose of advancing knowledge for the entire human race [24] [25].

  Private contracts and confidential information should not be placed in these public open access metadata repositories. Similarly, the actual musical works (e.g. sound recording master files) should not be placed in open access locations.

  This open access philosophy for music metadata paves the way towards a more accurate attribution of musical works to artists, musicians and other relevant creation-side persons and entities.

  Additionally, an open access music metadata layer allows fans to obtain more details about the creation of the musical work (e.g. what type of keyboard the musician was using). The availability of keywords and phrases linked to metadata files allows for intelligent search capabilities to be developed atop the music metadata layer.

• Inclusion of cryptographic hash of musical work: Every creation metadata file must include a cryptographic hash of the digital representation of the musical work of concern (e.g. hash of MP3 sound recording file) as a reference to the work. This allows for an exact 1-to-1 mapping between the metadata file and the corresponding musical work.

• Standard descriptor for metadata format & encoding: We anticipate that in the future there will be multiple metadata formats (e.g. DDEX-XML [26], JSON) with various encodings (e.g. Unicode, Chinese GB, etc.), according to the community of creators. The relevant headers of every metadata file must include such information in order to aid the reader (i.e. Client software) that fetches and parses these metadata files.

• Digitally signed and portable metadata units: The atomic unit of metadata (e.g. song, track, or composition as the atomic unit) must be digitally signed by an authoritative entity, such as the artist, songwriter, composer, musician, producer or other persons who have been authorized to do so. This allows the metadata unit to be self-contained and stand-alone, and therefore be portable and replicable as a unit. Each metadata file must carry a globally unique digital identifier that allows it to be uniquely distinguished from other metadata units.

• Figure 5 (a) illustrates this notion of a signed metadata file with a unique file identifier, where the last part in Figure 5 (a) shows the signature portion (e.g. X.509 [27] [28] or XML-DSig [29]) and the signer information.

• Replicated copies of metadata units: The signed metadata files must be made available to the public at multiple locations throughout the Internet. The digital identifier used for the metadata file must allow a user to locate one of the many copies of the metadata files on the Internet. Access should be made via standardized APIs.

• Globally unique and resolvable file identifiers: Each metadata file must be assigned a unique identifier under a registered namespace that allows a user to fetch a copy from one of the many repositories around the world based on that identifier.

• Digital identifier schemes such as the Digital Object Identifier (DOI) [30] and its accompanying Handle resolver system [31] [32] have been successfully deployed at a wide scale for over a decade now. Similar in protocol-behavior to the DNS infrastructure, the DOI and Handle allows for efficient look-ups of copies of data files (e.g. library catalog entries) stored at open repositories all over the Internet.

• Ledger-based notarization of signed metadata: A distributed ledger can be used as a means to notarize each signed metadata unit or a shorter summary of it. For convenience, we refer to the shorter metadata as the registry metadata, implying that the shorter registry metadata is intended to be stored on the distributed ledger. The same file identifier (e.g. DOI) used in the creation-metadata must be used in the registry-metadata, signifying that both point to the same musical work. The notarization of the registry metadata provides a tamper-detectable timestamp on the musical work.

• Figure 5 (b) illustrates the notion of notarization via a metadata registry ledger, and shows the shorter registry metadata to be recorded on the ledger. Entities who fetch a version of a metadata file must check the ledger to ensure that they have the latest version (e.g. based on the timestamp on the confirmed transaction).

• Support for multiple versions of a musical work: In many circumstances artists and musicians may create different versions of a given musical work. For example, for a given sound recording an artist may record a short version (e.g. 2 minutes long), long version (e.g. 3 minutes long) and an extended version (e.g. 6 minutes long). Since the cryptographic hash of the musical work(e.g. MP3 file) is included in the metadata file (see Figure 5 (a)), this implies that a separate metadata file must be created for each of these versions. Furthermore, this means that each of these metadata files must have a unique identifier. This is crucial in order to allow a licensee to unambiguously point to the exact version of the sound recording for which they are seeking a license.

• Support for revisions of metadata: It is inevitable that errors may exist in metadata information even when the information is collected upstream at the creation-end of the supply chain (e.g. in DAW software). As such, if a metadata file is to be corrected or revised, then the existing (old) metadata file should never be deleted or erased. When a new revision is written, the new version metadata file must be assigned a new file-identifier and must contain a link to (e.g. hash of) the revised version. This indicates to the reader (i.e. Client software) that a previous version exists. This principle is akin to source version-control in software engineering development, which is very common today (e.g. SVN or GitHub).

• Similarly, when a revised version is to be notarized via the registry ledger, the new registry-metadata must include a pointer to (e.g. hash of) to the previously confirmed registry metadata (e.g. transaction-id of previously confirmed registry-metadata transaction).

• Support for archival of revised metadata: Revised (old) metadata files must never be erased, and must be archived using the same replicated repositories architecture we have discussed. Archived metadata files must remain open access in order to support the tracing the provenance and history of the metadata information.

There are at least three benefits in this approach of combining open access metadata files and the notarization using the metadata registry ledger:

• Support of copyright claim: The “publishing” of the signed registry-metadata file of a musical work onto the registry ledger provides legal support to the copyright claim on the part of the creator(s). Furthermore, the notarization using a distributed ledger (with an additional act of signing the transaction) provides a relatively immutable and non-repudiable timestamped public evidence of the existence of the musical work.

• Basis for music metadata oracle for other ledgers & systems: By being the open registry for musical works metadata, the registry ledger effectively becomes the oracle for metadata that can be referred to (linked to) by other types of ledger-based transactions, such as license request smart contracts, and license granting smart contracts. Even existing systems (e.g. legacy databases, or future systems such as that of the Mechanical Licensing Collective or the Repertoire Data Exchange) can thus refer to the relevant entries (e.g. transaction-id) in the registry ledger.

• Opportunity for tight binding between a digital identity and public key: The need to digitally sign the creation-metadata and to sign the transaction submitted to the registry ledger necessitates dealing with key management of the private-public key pair of the signer. Standards for the creation of digital certificates based on the strong identification of persons have already existed in industry for over two decades now [33]. New efforts to retain this binding in a decentralized fashion via a blockchain system is also underway [34].

• This in turn paves the way towards solving the current problem in the music industry of identifying rights-holders (persons or legal entities) to whom royalty payments are owed (e.g. see [4]).

Distributed Repositories

We envisage that the creation-metadata of a given musical work should be replicated for higher-availability and reliability. There are several basic requirements for the implementations of the replicated metadata repositories:

• Independence of replication technologies: Since database and replication technologies will continue to evolve over time, the creation-metadata as the atomic unit must be “movable” (copyable) from one repository implementation to another.

• Standardized Service APIs for metadata repositories: The repository RESTful APIs used by a Client application that reads/writes to a metadata repository must be standardized. The API definitions must be independent of the technological implementation of the repository behind the APIs. A Client application calling to the APIs of a service should not need to be aware of the backend implementation of the service.

• Standardized Import & Export data format retaining signatures: When a metadata file is to be exported (read) from a metadata repository, then the file must use a standardized data-format. The digital signature portion of the original metadata file (as submitted initially by its creator) must remain valid when the metadata file is exported.

  

  For example, consider the case where an artist employs a Client application (e.g. DAW) to write a new a creation-metadata file in a given format (e.g. JSON) that is then signed by the artist using the corresponding public-key signature standard (e.g. JSON Web Signature). When the artist via the Client application submits this file to the local metadata repository, the repository may internally dissemble the metadata file in accordance to its internal data storage architecture. However, when later a home-user reads (exports) a copy of the metadata from this open access repository, the repository must be able to re-assemble the original creation-metadata such that its original signature can be validated by the home-user.

Figure 7(a) illustrates a summary of the parts of the creation metadata file:

• Part 1: Metadata Digital Identifier: The first part is the identifier of the creation-metadata file. We propose to use the Digital Object Identifier (DOI) scheme [30] [31] [32] due to its long history of successful deployments around the world.

• Part 2: Musical Works Metadata: The second part pertains to the actual musical works metadata. This component may use existing music metadata formats (e.g. XML-based DDEX RIN, JSON) or it may use other formats. The header part of this component must indicate the format and encoding of the metadata. Note that the metadata file must not contain the musical sound recording file or legal ownership information.

• Part 3: Cryptographic hash of musical works file: The third part in the creation-metadata file is a cryptographic hash of the musical work file. For example, this could be a hash of a sound recording master file (e.g. MP3, MPEG4) or the hash of the music notation file (e.g. PDF file, Sibelius file, Finale file).

• This allows for a correct 1-to-1 mapping between the metadata file and the musical works file. This exact matching becomes relevant in business processing when there are multiple versions of a given musical work (e.g. long version, short version, or remix of a sound recording).

• Part 4: Authoritative issuer digital signature: The issuer of the creation-metadata must digitally sign the combined parts of the metadata (i.e. Part 1 to Part 3 above).

• The digital signature is performed using the existing standard techniques for public-key digital signatures and timestamps. The signature portion is the fourth part of Figure 7(a). The signature part (Part 4) must include the standard pieces of information required for a reader to validate the file (e.g. signature algorithm-ID, etc. – see [33]). Henceforth, any attempt to modify any data in the assembled parts (Part 1 to Part 4 of Figure 7(a)) will cause the signature-verification to fail – indicating to the reader that the creation-metadata file is no longer authentic (i.e. that it has been tampered with).

Metadata Registry Ledger

The music metadata layer may benefit from the use of one or more distributed ledger networks as a means to effect a simple consensus-based notarized registry ledger. Since a creation-metadata file might be large and given that most ledger-based transactional systems are not intended to store large files, only a short summary of the metadata should be recorded on the registry-ledger system. We refer to this as the registry-metadata structure (see Figure 7(b)).

The shorter registry-metadata will be recorded on the registry ledger, and its resulting transaction-ID on that ledger can later be used as a reference in business logic implementations and multi-party transactions in other systems and ledgers. The registry-metadata must always carry the same identifier (i.e. DOI) as the creation-metadata, indicating that these two data structures refer to the same musical work.

There are two major goals of the registry ledger:

• Multicopy registry-metadata file and look-up: The registry ledger provides multiple copies of the registry-metadata, by virtue of the P2P network of nodes. Each node independently keeps a full set of confirmed blocks of transactions (see Figure 8), each of which carries the registry-metadata structure. The metadata identifier part (Part 5 in Figure 7(b)) includes the same file identifier (e.g. DOI) as in the creation-metadata (Part 1 in Figure 7(a)). This allows any entity to use the DOI identifier found in the short registry-metadata (on the public registry ledger) to fetch a copy of the full creation-metadata file from one or more repositories on the Internet.

• Persistent on-chain record for other infrastructures: The metadata registry ledger provides a persistent evidence upon which other infrastructures and systems can rely on (i.e. can point to). Thus, a music licensing scheme implemented on a different ledger or blockchain system can “point to” a registry-metadata found on the registry ledger as part of a license issuance smart contract. Similarly, legacy systems and databases can cite the transaction-ID (on the ledger) of the registry-metadata in its business logic processing software.

The parts of the registry-metadata is shown in Figure 7(b) (which does not show the enveloping ledger transaction structure):

• Part 5: Metadata Digital Identifier: The first part is the digital identifier of the registry-metadata file, which must be identical to the value found in the full creation-metadata (first part of Figure 7(a)).

• Part 6: Musical Works Identifier: The second part carries the musical works identifier that maybe in use within the metadata file. Typically, this would be an identifier common and understood in the music industry (e.g. ISRC number for recordings or ISWC number for compositions).

• Part 7: Cryptographic hash of full-metadata file: The third part carries the cryptographic hash of the full-metadata file as a means to ensure 1-to-1 correspondence between the registry-metadata and the full creation-metadata file.

• Part 8: Authoritative issuer digital signature: The fourth part carries the digital signature of the authoritative issuer, which should be the same issuer as that of the full creation-metadata file. Although not shown, typically a timestamp is included in the digital signature data structure.

After the authoritative issuer (e.g. artist) completes the capturing of the musical works metadata, he or she proceeds to create a short registry-metadata which is then enveloped within a transaction structure and transmitted to the distributed ledger. The transaction’s recipient (address) is either the issuer itself (i.e. to the public-key of the issuer) or is “null” (depending on the specific ledger implementation in question). This self-addressed transaction implicitly indicates that it is a notarization transaction.

Distributed Search and Lookups

Another issue closely tied to the music metadata layer relates to the ability for a user (e.g. home user, other creative artists) to search the various metadata repositories for music using keywords and phrases. We believe a separate “search infrastructure” is needed that is parallel and interconnected to the various metadata repositories.

There are a number of interesting considerations for this search infrastructure based on an interconnected set of the keywords-databases shown earlier in Figure 6 and Figure 7(b). Some of these considerations are as follows:

• Separation of creation metadata from search-material: The words, tags and phrases information – referred to here as search material – must be stored and managed separately from creation-metadata files. This is because while the creation metadata may remain static over time (unchanged) once it has been signed, the accumulated size of search-material – consisting of permutations and combinations of words and phrases – may grow and change over time.

• Creator-side association of keywords and phrases: Artists and musicians must be able to associate their own words, tags and phrases to a given music metadata and have this search-material be stored locally, but be read-accessible globally.

• User-side association of keywords and phrases: Similarly, any user or person (or AI and Machine Learning systems) must be able to create their own association of words, tags and phrases for a given music metadata and have this search-material stored locally to them. This is analogous to the current practice of music playlists that users create on their devices and streaming-accounts.

Figure 9 illustrates the search process. In Step 1 a user employs a search-application that performs searches on local keywords-databases as well as other available globally. The results of this search in Step 2 is a set of links or DOI values that the search-application can resolve to the full metadata. When the search-application presents these results, the user can choose certain DOIs (e.g. in the user’s search-application), which would result in the search-application fetching the full creation-metadata files in Step 3. In Step 4, the search-application has the option of verifying on the registry ledger whether there exists newer version of the creation-metadata file.

For each creation-metadata file, the user then can employ the hash of the musical work (e.g. hash of MP3 master file) found in the creation-metadata to fetch a copy of the musical work itself (e.g. MP3 master file) from its location of storage via a protected API. This last action will require the user to be authenticated and obtain authorization from the current owner of the musical work.

Currently, alternative decentralized content management systems (e.g. Open Index Protocol (OIP) [35]) are being developed to allow the decentralization of the storage of content-files (e.g. using IPFS [36]) with a separate locally-cached search terms. The local caching of search terms (e.g. on the user’s computer) avoids the centralized collection by (and hence user dependence upon) large search-engine service providers. This is important because the user’s choice of search terms and keywords may provide valuable insights through social analytics regarding the user’s preference for music genres as well as those of the user’s friends (e.g. people with frequent interactions in the social interaction-network [37]).

The 3 Layers of the Future Global Music Ecosystem

So far we have discussed the music metadata layer as the foundation layer for the future global music ecosystem. This layer is as core to the functioning of the digital music ecosystem as the DNS infrastructure is core to the functioning of the services on the Internet today. However, in order for new services to grow organically and evolve over time, we believe that two additional layers (or “infrastructures”) will be needed in order for the digital music industry to truly reach its global market potential.

The three layers or infrastructures of future digital music are summarized in Figure 10 and consists of the following:

• Music metadata layer: This is the music metadata layer that we have discussed in previous sections. This is the bottom-most layer in Figure 10.

• There will be several other components of this layer that we did not discuss, such as digital identity management, cryptographic key management, protected access to musical works (e.g. sound recording files), and others. There is a key role for Artificial Intelligence (AI) and Machine Learning (ML) technologies at this layer in solving the music search problem.

• Licensing and Royalties Management layer: The second layer needed is one that enables a decentralized management of music rights-ownership, music rights trading (i.e. buy/sell), license issuance/tracking, and the collection and distribution of royalties. This is the middle layer in Figure 10. Here, we believe that there is a major role for smart contracts technology to be used to represent business logic as part of the broader music licensing supply chain management.

• It is paramount to recognize that there is a strong dependency of this layer upon the bottom-most music metadata layer. Digital licenses cannot be issued by smart contracts (and royalties obtained) if creation-metadata information is incomplete or if there are multiple imprecise unauthoritative versions existing along the music supply chain. Hence our design principles discussed earlier.

  One important question for this layer is the confidentially of rights-related transactions on the distributed ledgers used in this layer. Research and development continues on cryptographic schemes (e.g. zero-knowledge schemes) that provide some degree of privacy to entities that transact on public blockchain networks. A second key question pertains to the interoperability of distributed ledgers and blockchain systems, something that is severely lacking today [38].

• Music virtual assets layer: The third layer needed is one that allows for the recognition of musical works and music-rights as virtual assets in the sense of digital tokens [39] [40].

• A new digital infrastructure is needed to allow for the exchange (e.g. buy, sell) of rights in the form of digital fungible tokens (e.g. ERC20 [41]), or non-fungible tokens (e.g. ERC721 [42]). Tokens can be used to represent full or partial rights ownerships of musical works, and therefore can be used as the basis for distributing royalties obtained from licensees.

  The eventual vision is for this layer to encompass multiple decentralized music-rights trading networks which operate on a global scale. Just like the Internet – which is composed of multiple ISPs and networks – the interoperability across trading networks (i.e. distributed ledgers and blockchains) remains a subject for future research and development in the technology industry.

Just as the Internet is not owned by any single entity, organization or country, we believe that there will be multiple implementations and instantiations of the functions and components of the above three layers in Figure 10. As the history of 1980s Local Area Network (LAN) industry has taught us [43], it is futile and even counter-productive for any single entity to seek to own or control entire layers. As such, technical and operational standards are needed to ensure a high degree of interoperability of services based on common standardized APIs – and thus ensure there is significant competition of services in the market.

Conclusions

Today we are in a situation where individual assets ...people’s personal data... is being exploited without sufficient value being returned to the individual. This is analogous to the situation in the late 1800’s and early 1900’s that led to the creation of collective institutions such as credit unions and labor unions, and so the time seems ripe for the creation of collective institutions to represent the data rights of individuals. We have argued that data cooperatives with fiduciary obligations to members provide a promising direction for the empowerment of individuals through collective use of their own personal data. Not only can a data cooperative give the individual expert, community-based advice on how to manage, curate and protect access to their personal data, it can run internal analytics that benefit the collective membership. Such collective insights provide a powerful tool for negotiating better services and discounts for its members. Federally chartered credit unions are a useful model because they have already been legally empowered to act as cooperatives. We believe there are many other similar institutions that could also provide data cooperative services, and we discuss the data cooperative model in the case for empowering artists and musicians in the music industry.

In the context of a data cooperative for artists and musicians, one of the key challenges of the music supply chain today is the lack of consistent, complete and authoritative information or metadata regarding the creation of a given musical work. We have described the notion of an open access music metadata layer that can become the basis for future music-related transactions on distributed ledgers or blockchain systems. The metadata layer consists of a replicated and decentralized open-access metadata repositories, which is a series of repositories that stores creation metadata, without rights-ownership information and without the copyrighted musical works (e.g. composition notes files, sound recording. files). This is coupled with a registry ledger which acts as a notarization service and which allows anyone in the world to resolve the identifiers in the registry-metadata to one or more copies of the complete creation metadata located on the Internet. We have described a number of design principles for this music metadata layer.

We believe there is a role for a data cooperative to operate and manage the relevant IT services that implement the music metadata layer and the registry ledger for the cooperative’s members. This provides artists and musicians better manageability of their assets (i.e. their creative works) and better visibility into the licensing of their works (e.g. who has licensed what works), Using smart contracts technology, licensees can obtain rights-licenses (e.g. performance license, mechanical license) directly on the blockchain from artists and musicians.

Our vision is a future music industry that operates globally based on the three logical layers or infrastructures. Thus, in addition to the music metadata layer we believe that a licensing and royalties management layer will be needed that can automate the business logic processing pertaining to license issuance, license tracking/accounting, rights-ownership trading (i.e. buy/sell), and royalties collection and distribution. We believe there is a promising role for smart contracts technologies to express the various business logic in this layer. The third and “uppermost” layer is one in which musical works and music-rights can be recognized as virtual assets in the sense of digital tokens. This tokenization paves the way for the evolution towards globally interconnected networks for the exchange of music virtual assets.