Recommended use of CommercialModelType and UseType in ERN-4
Introduction
In order to support the many ways in which companies can express how a Creation may be used or has been used, DDEX Standards such as ERN use two key allowed value sets – CommercialModelType and UseType – to provide users of the Standards with a means to express a whole range of business models.
These business models change over time and users of the Standards constantly need to find the “best match” between what a user of the Standards wishes to do (or in the case of sales/usage reporting: have done) and what the allowed values of the DDEX standard support. 100% matches are not always possible – there are simply too many variations possible.
This document provides guidance on how to use CommercialModelType and UseType within DDEX in an effort to minimise any confusion in the way users of the Standards use the two allowed value sets. This paper focuses on the ERN message but similar approaches can be taken for all DDEX standards.
Defining the Semantic of Message Elements
The music industry, as a “high volume low value” transaction environment requires an efficient supply chain. This means that the computers of senders and recipients of music related data will need to have a common understanding [1] of what is being communicated. There are two ways in which this common understanding can be reached: either the two parties involved agree upon specific codes and their meaning that they, but not necessarily other parties, understand or the two parties involved rely on a common standard that everyone understands (or can understand).
As the approach of bilaterally agreeing codes and their meaning is not scalable, the members of DDEX have decided that DDEX messages should provide, in addition to message structure, well-defined semantics for the various elements that need communicating. This is, of course, not to say that both parties are prevented from using such terms in accordance with their own understanding, based on bilateral agreements. However, if the definitions of the terms are sufficiently precisely defined, this interpretational margin should be limited.
“Simple” Exploitations
Labels can communicate how they wish a DSP to use (or “exploit”) their Releases using the ERN message by selecting suitable values from a few lists of terms with clear, DDEX-defined semantics. DDEX calls these lists “allowed-value sets” (AVSs) and amongst the most important ones are those that describe the conditions under which a record company wishes that a DSP makes available its Releases.
The two main AVSs for this are UseType (the way the consumer obtains the music) and CommercialModelType (the way the consumer pays for the music). The same AVSs are then also used, for example, to express how creations have been used in a sales/usage report.
Each of the allowed values (AVs) in these AVSs has a well-defined definition that all users of DDEX standards should adhere to. At the same time, the definitions are flexible enough to cater for the small variations between how different companies in the music industry value chain operate. Typical operations, however, can be expressed with the DDEX-defined values: A standard download deal where the consumer pays a fixed price for each download can be expressed with a UseType of PermanentDownload and a CommercialModelType of PayAsYouGoModel.
If the current set of AVs in any AVSs prove to be inadequate, then DDEX will add further values as required.
“Complex” Exploitations
Some exploitations may require multiple UseTypes and/or CommercialModelTypes, even if they are offered to consumers under one headline deal. A Subscription service where subscribers can stream the music but also listen to it offline would be expressed as a deal with DealTerms of two UseTypes (ConditionalDownload and Stream) and one CommercialModelType (Subscription).
There are also cases where two sets of DealTerms need to be constructed to adequately express the full semantics of the deal.
For example, this is the case, when a digital service offers a music à-la-carte download store but also a subscription service where the subscribers can both stream the content online but also offline.
There will therefore be two separate deals in the NewReleaseMessage:
Deal 1:
CommercialModelType:PayAsYouGoModelUseType:PermanentDownload
Deal 2:
CommercialModelType:SubscriptionModelUseType1:StreamUseType2:ConditionalDownload
Do’s and Don’ts
Implementers should use the combinations of UseTypes and/or CommercialModelTypes as set out in below where the exploitations they are seeking to communicate match the examples.
If the examples are not directly applicable, implementers should adapt the examples listed below to their specific circumstances.
In using or adapting the examples, implementers should consider using a combination of multiple UseTypes and/or CommercialModelTypes – in one or more sets of DealTerms – if the offering at hand cannot be expressed with a single UseType and/or CommercialModelType. It is not acceptable to collapse multiple aspects into one generic “headline use type” for convenience sake.
As a last resort only, implementers may use the AsPerContract values to express situations that cannot be expressed using the DDEX values. Some DSPs have enacted a policy to not accept AsPerContract.
In the cases where AsPerContract has to be used, implementers are encouraged to contact DDEX with a view to having the allowed-value set(s) extended as soon as possible (where such extension does not inadvertently or otherwise hint at possibly confidential terms of actual sender/receiver agreements). [2]
Generic and Specific UseTypeValues
To aid implementation and allow for backward compatibility, the Allowed Value Set for UseType includes a few generic values, described below. Each generic value can be used in place of a specific group of specific values. If a label sends a generic UseType, it should expect the recipient to interpret it to include all the respective specific values. For example, if sending Stream then the recipient is likely to interpret that to include: ContentInfluencedStream, NonInteractiveStream, OnDemandStream, and TimeInfluencedStream.
If a label does not want to grant all of the respective specific UseType values, it must send just the desired specific UseType values. For example, if you don't want to grant OnDemandStream then do not send Stream.
It is perfectly acceptable, within one Usage composite, to combine a generic UseType with other specific UseType values from outside of that group. For example, a label may send Streamand ConditionalDownload together. But one must not send Stream and NonInteractiveStream together.
This table explains the hierarchical relationships of three generic parent terms (note: deprecated values are not listed here):
Generic Parent Term | Specific Child Terms |
|
|
|
|
|
|
Specific Examples
This section contains a number of typical exploitations common in the market today. DDEX expects to update this document in the future if and when new business models become wide-spread.
“A la carte” Downloads
The consumer pays for a specific Release via a one-time purchase at the DSP.
The DSP allows the consumer to download a copy of the release to store on their own device(s). Subsequent downloads of the Release by the same consumer are usually permitted.
The consumer is permitted to access, copy and keep the release on their own device(s) for their private use indefinitely, even beyond the life of the DSP that provided it.
<DealTerms>
<ValidityPeriod>
<StartDateTime>2018-12-25T17:00:00</StartDateTime>
</ValidityPeriod>
<CommercialModelType>PayAsYouGoModel</CommercialModelType>
<UseType>PermanentDownload</UseType>
</DealTerms>
Stream Subscriptions
This includes the uses of both on-demand access (the user selects and plays a recording, album etc with full control) and non-interactive access (a radio-style experience with minimal user control). As it is a subscription, the user gains additional features such as no advertisements, higher quality audio, and/or other added functionality.
In effect this is a DSP offering any or all of the services described in Sections on On-Demand Streaming Subscriptions, Non-interactive Streaming Subscriptions plus any other subscription streaming offerings that are not covered in these three sections (and for which DDEX has, at this stage no specific UseType or CommercialModelType values).
<DealTerms>
<ValidityPeriod>
<StartDateTime>2018-12-25T17:00:00</StartDateTime>
</ValidityPeriod>
<CommercialModelType>SubscriptionModel</CommercialModelType>
<UseType>Stream</UseType>
</DealTerms>
On-Demand Streaming Subscriptions
The consumer pays a fee for time-limited access to the service. The fee is not tied to specific Releases and is automatically re-charged at the beginning of a new time period. There are no advertisements and there may be additional features such as higher quality audio.
The DSP allows the consumer to browse and select specific Releases they wish to use. The user can select and play a recording or album with full control. The number of times each Release can be used is unlimited within the specified time period.
This does not cover the case where Releases or Resources are downloaded to the consumer’s device(s). Where this is permitted, the model in the Section on Subscription-enabled Offline Consumption should be used.
<DealTerms>
<ValidityPeriod>
<StartDateTime>2018-12-25T17:00:00</StartDateTime>
</ValidityPeriod>
<CommercialModelType>SubscriptionModel</CommercialModelType>
<UseType>OnDemandStream</UseType>
</DealTerms>
Non-interactive Streaming Subscriptions
The consumer pays a fee for time-limited access to the service. The fee is not tied to specific Releases and is automatically re-charged at the beginning of a new time period. There are no advertisements and there may be additional features such as higher quality audio.
The consumer cannot access specific Releases on request, but instead indicates interest in other criteria as defined and offered by the DSP. The DSP then delivers Releases or Resources that it selects according to these criteria, such as pre-programmed lists or fuzzy search results. In effect this is a radio-style experience with minimal user control.
This does not cover the case where Releases or Resources are downloaded to the consumer’s device(s). Where this is permitted, the model in the Section on in the Section on Subscription-enabled Offline Consumptionshould be used.
<DealTerms>
<ValidityPeriod>
<StartDateTime>2018-12-25T17:00:00</StartDateTime>
</ValidityPeriod>
<CommercialModelType>SubscriptionModel</CommercialModelType>
<UseType>NonInteractiveStream</UseType>
</DealTerms>
Subscription-enabled Offline Consumption
The consumer pays a fee for time-limited access to the service. The fee is not tied to specific Releases and is automatically re-charged at the beginning of a new time period.
The DSP allows the consumer to browse and select specific Releases or Resources they wish to use. The number of times each Release or Resource can be used is unlimited within the specified time period.
Chosen Releases or Resources are downloaded to the consumer’s device(s) using mechanisms that:
Limit access to the paid-for time period;
Allow use of the Releases or Resources without an internet connection to the DSP;
Prevent unauthorised use of the Releases or Resources.
<DealTerms> <ValidityPeriod> <StartDateTime>2018-12-25T17:00:00</StartDateTime> </ValidityPeriod> <CommercialModelType>SubscriptionModel</CommercialModelType> <UseType>ConditionalDownload</UseType> </DealTerms>
Ad-supported Streaming Service
This includes the uses of both on-demand access (the user selects and plays a Recording, album etc with full control) and non-interactive access (a radio-style experience with minimal user control). As it is advertisement-supported, the user is not paying for the service, instead gaining access by the consumption of advertisements.
In effect this is a DSP offering any or all of Ad-supported On-Demand Streaming Services or Ad-supported non-interactive Streaming Services, plus any other advertisement-supported streaming offerings that are not covered in these three sections (and for which DDEX has, at this stage no specific CommercialModelType or UseType values).
<DealTerms> <ValidityPeriod> <StartDateTime>2018-12-25T17:00:00</StartDateTime> </ValidityPeriod> <CommercialModelType>AdvertisementSupportedModel</CommercialModelType> <UseType>Stream</UseType> </DealTerms>
Ad-supported On-Demand Streaming Service
The consumer does not pay a fee to access the service, but instead is obliged to enjoy advertisements.
The DSP allows the consumer to browse and select specific Releases or Resources they wish to use. Users have full control over the releases.
<DealTerms> <ValidityPeriod> <StartDateTime>2018-12-25T17:00:00</StartDateTime> </ValidityPeriod> <CommercialModelType>AdvertisementSupportedModel</CommercialModelType> <UseType>OnDemandStream</UseType> </DealTerms>
Ad-supported non-interactive Streaming Service
The consumer does not pay a fee to access the service, but instead is obliged to enjoy advertisements.
The consumer cannot access specific Releases or Resources on request, but instead indicates interest in other criteria as defined and offered by the DSP. The DSP then delivers releases that it selects according to these criteria, such as pre-programmed lists or algorithmic programming. In effect this is a radio-style experience with minimal user control.
<DealTerms> <ValidityPeriod> <StartDateTime>2018-12-25T17:00:00</StartDateTime> </ValidityPeriod> <CommercialModelType>AdvertisementSupportedModel</CommercialModelType> <UseType>NonInteractiveStream</UseType> </DealTerms>
RightsClaim Model
In order to communicate rights to a fingerprinting service provider, a Rights Controller needs to allow the service provider to use the Releases or Resources. The Releases or Resources will not be made available by the service provider to consumers.
<DealTerms> <ValidityPeriod> <StartDateTime>2018-12-25T17:00:00</StartDateTime> </ValidityPeriod> <CommercialModelType>RightsClaimModel</CommercialModelType> <UseType>UseForIdentification</UseType> </DealTerms>
User Generated Content (UGC) Model (Matched to Master Recordings)
A user uploads content (s)he has generated to a UGC site. The UGC provider then matches the uploaded content to the master recordings and/or musical works it has been provided with. The UGC provider will then make the uploaded content available to consumers based on the matched recordings’ and/or works’ rights holders’ policies.
<DealTerms> <ValidityPeriod> <StartDateTime>2018-12-25T17:00:00</StartDateTime> </ValidityPeriod> <CommercialModelType>RightsClaimModel</CommercialModelType> <UseType>UserMakeAvailableUserProvided</UseType> </DealTerms>
User Generated Content (UGC) Model (content-embedded)
A user uploads content (s)he has generated to a UGC site by using content that the UGC service provides to its content-creating users, who, in turn, has received the content from a record company. Once the UGC content has been uploaded to the UGC provider it will make it available to consumers based on the matched recordings’ and/or works’ rights holders’ policies.
<DealTerms> <ValidityPeriod> <StartDateTime>2018-12-25T17:00:00</StartDateTime> </ValidityPeriod> <CommercialModelType>RightsClaimModel</CommercialModelType> <UseType>UserMakeAvailableLabelProvided</UseType> </DealTerms>
Subscription Stream and Offline Consumption (multiple service types)
A subscription streaming service where the consumer can also keep the files on his/her local device – as long as the subscription membership is maintained.
This is a combination of the business models described in Clauses on Stream Subscriptions and Subscription-enabled Offline Consumption.
<DealTerms> <ValidityPeriod> <StartDateTime>2018-12-25T17:00:00</StartDateTime> </ValidityPeriod> <CommercialModelType>SubscriptionModel</CommercialModelType> <UseType>Stream</UseType> <UseType>ConditionalDownload</UseType> </DealTerms>
Virtual Gifts
Virtual gifts are described in the same manner as the “gifted business model”. The only difference to the non-gifted variety is that the payee is different from the consumer.
Multi-tier subscriptions
Some DSPs may wish to offer multiple tiers of subscription. These can be handled in multiple ways – if the difference in the tiers is simply a different pricing for different encoding quality the Dealsmight change by referencing different TechnicalResourceDetails.
However, a cleaner approach is to communicate the service type by using a user-defined UseType and/or user-defined CommercialModelType.
(Note: DDEX is working on adding support for a separate service type tag in future versions of the ERN Standard.)
[1] Actually, it is the developers that need to have this common understanding so that the computers can act in accordance with that common understanding.
[2] DDEX’s change request form is available from https://ddex.net/change_request.