Role code synonyms and credits

DDEX standards make extensive use of “allowed value sets” (AVS), i.e. controlled lists of well-defined terms. Typical examples are currency and territory code lists (that DDEX imports from the relevant ISO standards) and classifications for how consumers may interact with a musical Release. The two main ones for this are the UseType and the CommercialModelType.

AVSs have one advantage: they allow the sender and recipient of a message to communicate precise semantics. If the sender includes the TerritoryCode of DE into a Deal, the recipient knows precisely where this Deal is valid: in the territory of the Federal Republic of Germany (and only there). And when the Deal contains a CommercialModelType of AdvertisementSupportedModel then the recipient knows that the “service or product offering is financed by revenue generated from the sale of advertising”. And if a contributor is listed as being having played the Role of a MasteringEngineer, the recipient of the message knows precisely, thanks to the DDEX Data Dictionary, what this means.

AVSs do also have a drawback: they limit flexibility. For example, DDEX currently has no means to communicate a commercial model where the consumer barters a different piece of content against the Release the consumer is given access to. DDEX has the means to support such cases but the principle remains: AVSs reduce the flexibility as the cycle required to add new AVS terms, takes time.

One area where flexibility is very important is in the communication of credits. Artists often wish that their contribution is noted in a specific way – and this way may change from Release to Release and from Recording to Recording or from Work to Work. At the same time, DSPs and consumers would want to have a proper taxonomy of what a specific musician has done – regardless of how that is officially credited. The same applies to instrument types.

Using DisplayCreditText to customise credits

One example of this is what DDEX calls a Violin. Some musicians, who are playing such an instrument, may call it a Fiddle. However, it is important to make sure that the actual instrument is always communicated using the official DDEX term:

<InstrumentType>Violin</InstrumentType>

In order to satisfy the musician’s desire to communicate his contribution as having played the “fiddle”, DDEX has introduced a tag for a display credit string. This is a free-form string that allows for such additional information to be communicated, for instance:

<DisplayCreditText>Johnny on the fiddle</DisplayCreditText>

A DSP that receives such an InstrumentTypeand DisplayCreditTextwould be expected to display “Johnny on the fiddle” in the credits for the recording or Release. If the DSP’s system supports this, a hyperlink to a separate page for John may be added. The DSP may also include John as on a separate page of violinists.

Expected Behaviour

Ideally, DSPs store instrument and contributor name as separate strings. The actual information that is to be displayed would be either held separately or generated only at the point of displaying the information to consumers. 

The “raw” information would be:

The string in the DisplayCreditmeans that the sender of the ERN message expects the DSP to replace the entire usual credit string made up from the raw instrument and contributor information.

So, instead of showing “John: Violin” the DSP would in the above example expected to show “Johnny on the fiddle”.

While linking to two separate pages – one for John and one for violinists – is easier when the “raw” data is presented to the user than if a single display credit string, the ability to communicate such a string helps to represent the Release or Resource as intended by the artist(s).