Dealing with uncommon use cases
The music industry is complex. There are many ways in which music is exploited and traded, especially since the methods of distributing music are constantly evolving. This means that the mechanisms for the reporting of such exploitations, DDEX calls them “usages”, are also complex.
Most music distribution companies use a common set of distribution methods (e.g. pay as you go downloads, subscription-based streaming, etc.) whose key data points can comfortably be reported to the licensors of the rights in musical works and sound recordings using one of the profiles in the DSR standard. Some of these music distribution companies, however, have entered into licence agreements with licensors that require usage data to be exchanged that goes beyond the commonly used data points contained in the profiles of the DSR standard.
Whilst DDEX makes every attempt to ensure that its standards accommodate as wide a set of requirements as possible, ultimately it is not possible for DDEX’s standards to enable the communication of every possible single item of data that may exist across the music industry value chain. This obviously applies as well to the various profiles within the DSR standard.
A licensee that is required to communicate data points about usage which are not accommodated in one of the profiles of the DSR standard, has three options:
Wait until DDEX augments the relevant DSR standard profile in a new version with cells for these data points;
Add cells for the additional data points into an otherwise conformant DSR standard message; or
Communicate the additional data in a separate proprietary message sent in conjunction with a conformant DSR standard message.
Approach (1) above has two drawbacks:
It introduces a delay in a licensee’s ability to report data it is contractually obligated to report; and
The relevant updated profile in the DSR standard would become more and more complex with the addition of more and more cells that may well only ever be used by very few licensees.
DDEX tries to mitigate the delay issue by being as responsive to new requirements as possible. However, DDEX cannot resolve the second issue by meeting all licensees’ requirements because, some data points are “too esoteric” to be suitable for standardisation.
Approach (2) above would mean that the message sent is not conformant with the relevant DSR profile – and thus it is not conformant with the DSR standard. This implies that the licensee with the extra reporting needs, as well as all the licensors receiving such “extended” messages would need to have at least two implementations of the standard, a compliant DSR one, and one that supports the additional cells. Such extensions would need to be agreed bilaterally between licensors and licensees and thus negates the benefit of having a standard in the first place.
Approach (3) would keep the implementations of the standard common and shift all extra data points into a separate message. While somewhat similar to (2) it does mean that all companies can keep their DSR implementations conformant and thus maintain just one implementation. However, they would need to maintain multiple proprietary formats for the extra data at least until DDEX determines that some of the data points are sufficiently common, and adds them into a new version of the relevant DSR profile.
It is for the reasons in the last paragraph that DDEX recommends that if any licensee is required to communicate data that goes beyond the commonly used data points contained in the profiles in the DSR standard they should use approach (3) above and avoid approaches (1) and (2).