Skip to end of metadata
Go to start of metadata

Introduction

Within the DeclarationOfSoundRecordingRightsClaimMessage of the RDR-N Standard, the SoundRecordingDetailsByTerritory (SRDBT) composite within ResourceList/SoundRecording composite can be repeated to indicate territorial differences. The type of information contained within this composite and the flexible nature of a repeating element creates some challenges. Guidance for message senders is needed so that users adopt a standardised approach and message recipients can reliably process such declarations. 

While this document focuses on the best-practice for the message sender for RDR-N version 1.5, guidance for MLC version 1.4 elements that have been removed from the SRDBT composite in RDR-N 1.5 will be given in section 3 of this document. The structure of the SRDBT composite varies with respect to the RightsControllerPerformingContributor and OtherContributor composites.

For detailed guidance on how to implement the SRDBT composite in MLC 1.4 please see the following article on the Knowledge Base.

This guidance is equally applicable to VideoDetailsByTerritory within ResourceList/Video.

Guidance

ID

Principle

Area

Details

1

One (and only one) SRDBT element present for the default/worldwide values

SRDBT

There should be one occurrence of the SRDBT with the default values (e.g., Title, DisplayArtistName, PLine, etc) with the territory code set to a single value of Worldwide. 

2

Subsequent SRDBT element specify local territorial variations only

SRDBT

Any subsequent SRDBT tags are considered as local territorial overrides (e.g., ResourceTitle is different in Spain). Only elements with different values from the default/worldwide SRDBT should be included. 

Please see 9 as an exception to this principle.

3

No use of ExcludedTerritoryCode

Territories

The XSD provides a choice when listing territories within SRDBT – either a list of included territories (TerritoryCode) or a list of excluded territories (ExcludedTerritoryCode). Since this choice can change between different SRDBT elements, the scope of territories can quickly become unclear. It is proposed that only the TerritoryCode element be used. If a message sender wishes to use the excluded territory approach, they should instead explicitly declare the values for all other territories.

4

TerritoryCode not repeated across SRDBT elements

Territories

A territory should only be referenced once across all SRDBT, otherwise there could be different information declared for the same territory.

5

SRDBT should use a list of TerritoryCodes if more than one country with identical local variations.

Territories

The TerritoryCode within SRDBT allows for 1 to many elements to be specified, with one territory code per element. If there are multiple countries with the same local variations, then they can be combined by adding multiple TerritoryCode values. This creates a more compact declaration message.

6

Territory types to use in SRDBT

Territories

The territories declared in SRDBT/TerritoryCode should be limited to the ISO 3166-1 alpha-2 codes plus Worldwide. TIS TerritoryCodes are not widely used and may cause issues when messages are ingested.

7

HostSoundCarrierelement(s) only declared in default/worldwide SRDBT tag

Host Sound Carrier

For simplicity, all the Releases (host sound carriers) that the Resource is released on should be declared in the Worldwide SRDBT. Local territorial variations should actually be separate Releases so there is no need to override any Release details for specific territories.

8

DisplayArtistName's ApplicableTerritoryCode attribute

Display

The ApplicableTerritoryCode for the DisplayArtistName element should not be used as the SRDBT element already accommodates territorial variations.

9

DisplayConductor, DisplayArtist and DisplayComposer

Display

For SRDBT occurrences other than Worldwide, a change in one or more display elements should result in all display elements being listed in the local territorial variation. This allows for display information to be completely contained within the relevant SRDBT element.

Guidance for MLC 1.4

In RDR-N 1.5 the SRDBT has been simplified by moving the RightsControllerPerformingContributor and OtherContributor composites up one level. Due to the structural differences between the two versions of the standard the below two principles need to be also taken into consideration in addition to principles 1 to 9 listed above.

As the RightsController sits within the SRDBT composite, principle A below is the exemption to principle 2 above. 

ID

Principle

Area

Details

A

RightsController element(s) for each SRDBT should be identical

Rights Controller

The XSD makes the RightsController element mandatory each time a SRDBT is declared. The RightsController should contain the full rights picture for a Resource, including all territories, use types and periods. If the scope of rights declared varies with different SRDBT, then an inconsistent view of rights is provided. 

B

PerformingContributor and OtherContributor element(s) only declared in default/worldwide SRDBT tag

Contributor

As the contributions to a Resource do not vary by territory, the performing contributor(s) and other contributor(s) should only be listed once in the Worldwide composite.

  • No labels