RDR-N: SoundRecording DetailsByTerritory (version 1.5)

Each SoundRecording node must include one or more SoundRecordingDetailsByTerritory nodes. The first SoundRecordingDetailsByTerritory node includes data which would apply for this SoundRecording in all territories as a default, unless specifically overridden by further information provided in subsequent SoundRecordingDetailsByTerritory nodes . Most implementers of the RDR-N message currently specify that only one SoundRecordingDetailsByTerritory node should be supplied per SoundRecording. This does not preclude the delivery of multi-territory rights ownership information. For further guidelines on territorial variations consult the following article: Guide to Territorial Variations in the SoundRecordingDetailsByTerritory Composite in RDR-N (v 1.5).

The SoundRecordingDetailsByTerritory composite in v 1.5 has been simplified and as a result the following elements have been deleted from that composite and moved to the SoundRecording composite:

• PerformingContributor;

• RightsController; and

• OriginalResourceReleaseDate.

All other elements listed as part of the Recommended or Core Data Profile in the table below remain unchanged and in line with v 1.4.

"RDR" is the new name for the "MLC" Standards.

Which fields need to be provided?

Whilst the DeclarationOfSoundRecordingRightsClaimMessage of DDEX’s RDR-N Standard in Version 1.5 can accommodate several hundred tags, a few of these in SoundRecording and SoundRecordingDetailsByTerritory are quite critical to effective use of the message in practice. The table below itemises the most critical tags which should be provided by record companies to music licensing companies.

The "Recommended Profile" is what DDEX recommends is sent, at a minimum, from record companies to music licensing companies as well as from music licensing companies to other music licensing companies in order to register a claim. The data set has been defined because it will enable most music licensing companies to accept the claim as stated and thus collect revenue for the rights holder. In some cases it may not be possible for the sender of the message to collate all the data elements listed in the "Recommended Profile". In that case the message sender should consider using the "Core Data Profile". This data set typically allows a claim to be registered, but the data provided may not be sufficient, on their own, to enable the music licensing company to accept the claim and thus undertake the correct collection of revenues. Amalgamated with data from other sources it may, however, be possible for music licensing companies to collect revenues and to pay out.

In the table below, tags are shown as "mandatory" or “include” as within the core or the recommended datasets for a recording, and thus core or recommended for inclusion in Declaration messages. The tags marked as "mandatory" are to ensure that implementers deliver messages that are technically valid agains the XSD. The tags shown as "include" have been added to provide practical guidance to record companies (and other senders of the claim message) on which data is generally needed by music licensing companies on operational grounds.

It is noted for good order that DDEX is not able to give definitive advice on the data policy of any specific music licensing company as there may be bilateral and contractual requirements for additional data sets – the table below is for general guidance.

Implementation Notes

The following notes are more detailed guidelines including sample data for some of the tags listed in the above table.

TerritoryCode

This defines the territory or territories covered by this node.  Worldwide is defined as an allowed value.  When listing an exception (i.e. to Worldwide) an ExcludedTerritoryCode should be used.

Title

In SoundRecordingDetailsByTerritory this tag can be used to express the title in another language, or an alternative title applicable in a given territory. 

Example of Title

<Title LanguageAndScriptCode="en" TitleType="DisplayTitle">
      <TitleText>My Song</TitleText>
      <SubTitle>Album Version</SubTitle>
</Title>

DisplayArtistName

This is the artist name as associated with the recording. (See also the HostSoundCarrier node for artist name as associated with a given release on which the sound recording appears). The “artist name” element is solely descriptive information (i.e. does not convey or necessarily imply information about rights, performances or contributions.)  Music licensing companies use this for matching to usage.

In the case that there are several artist names associated with the recording, the DisplayArtistName acts as a “compound string”, as it would be displayed to the public.

• Example of a band name DisplayArtistName: “The Weeknd”

• Example of several artists as DisplayArtistName in a “compound string”: “The Beatles & Tony Sheridan”

• Example of a “virtual” band DisplayArtistName: “Gorillaz”.

When the DisplayArtist is provided, the following are necessary:

• FullName

• DisplayArtistRole

MainArtist is a Role and only applies to DisplayArtist.  MainArtist is the principal credited artist associated with a resource.
Note that the DisplayArtist node may occur several times with the tag SequenceNumber set to different integer values.  The SequenceNumber value is used as part of the enumeration of the artists to whom the recording is associated.

Example of DisplayArtistName and DisplayArtist

<DisplayArtistName> The Weeknd ft. Daft Punk</DisplayArtistName>
 
<DisplayArtist SequenceNumber="1">
  <PartyName LanguageAndScriptCode="en">
    <FullName>The Weeknd</FullName>
  </PartyName>
  <PartyId>
    <ProprietaryId Namespace="PADPIDA2007061301U">1234567
    </ProprietaryId>
  </PartyId>
  <DisplayArtistRole>MainArtist</DisplayArtistRole>
</DisplayArtist>
<DisplayArtist SequenceNumber="2">
  <PartyName LanguageAndScriptCode="en">
    <FullName>Daft Punk</FullName>
  </PartyName>
  <PartyId>
    <ProprietaryId Namespace="PADPIDA2007061301U">7654321
    </ProprietaryId>
  </PartyId>
  <DisplayArtistRole>FeaturedArtist</DisplayArtistRole>
</DisplayArtist>

DisplayComposer 

This field is mandatory when the Genre is Classical, which is indicated by setting the IsClassical flag to true. For classical recordings, this is needed (along with the work title) in order to disambiguate the recording and to match usage.

When the DisplayComposer is provided, the following are mandatory:

• FullName

• PrimaryRole

PLine

The PLine states the rightsholder detail at the time when the recording was published, and is not necessarily the same as the InitialProducer.  It is the nationality of the InitialProducer that is one of the “points of attachment” determining eligibility under the treaties.  The mandatory fields for PLine are:

• Year

• PLineText

HostSoundCarrier

For the ReleaseId - at least one of the following sub elements must be provided:

• ICPN

• CatalogNumber

• ProprietaryId

In addition

• HostSoundCarrier\Title is the title of the sound carrier / album that contains the track.

• HostSoundCarrier\DisplayArtistName are the name(s) of the artist(s) of the sound carrier / album on which the track is featured.

• HostSoundCarrier\LabelName is used for matching.  It is safer to include label information at the HostSoundCarrier node for a release than in the SoundRecordingDetailsByTerritory.

• HostSoundCarrier\NumberOfSoundRecordingsClaimedInCarrier helps to avoid double claims in compilations, and helps to avoid omitting relevant recordings.

• HostSoundCarrier\NumberOfTracksInCarrier indicates how many Tracks are included on the compilation. This needs to be provided if MessageSenderIsCompilatinCreator is set to true.

• HostSoundCarrier\IsInternalCompilation indicates whether the rights to all SoundRecordings on a compilation are controlled by the same record company.

• HostSoundCarrier\MessageSenderIsCompilationCreator indicates whether the MessageSender created the compilation.
  

The latter three elements have been introduced into RDR-N 1.5 to facilitate the registration of compilations and the accurate repatriation of revenue to individual licensors of individual tracks released on a compilation. In addition to the HostSoundCarrier elements listed in the recommended and core data profile those three additional elements are essential for the registration of compilations. For more detailed guidelines on how to register compilations and the use of elements required for each message sender depending on whether they are the compilation creator of an internal compilation, the compilation creator for a release with various artists licensed-in from a third party or a licensor of a sound recording on such a compilation please refer to Registering Compilations.

Genre

There are hundreds of genres and they correspond more to how an artist wants to be perceived or placed than to any objective criteria.
Typically, music licensing companies use Genre only for classical music as a trigger for special processing, such as to ensure composer information is present, and to apply matching rules better suited to classical metadata. When sending data about classical music it should be indicated using the Genre\IsClassical flag.

[1] It is important for music licensing companies to receive information about as many HostSoundCarriers – physical or electronic – as possible to in order to aid them in their matching and distribution efforts.