Search

Territorial variations in the SoundRecordingDetailsByTerritory Composite in RDR-N

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 RightsController, PerformingContributor 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 for version 1.5

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 `TerritoryCode`s 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 version 1.4

In RDR-N 1.5 the SRDBT has been simplified by moving the RightsController, PerformingContributor 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.