THIS VERSION IS NOT THE LATEST RELEVANT DDEX STANDARD. DDEX RECOMMENDS TO USE THE LATEST VERSION.

Skip to end of metadata
Go to start of metadata

 

 

This section of the DDEX Knowledge Base contains version 1.1 of the "Release Profiles for Common Release Types"

1 Introduction

The Digital Data Exchange, LLC (DDEX) has, in the past defined a series of message suite standards to make the communication of information along the digital music delivery chain more efficient. As part of these message is the communication of Release details, including information about their parts, i.e. Resources (such as SoundRecording or Videos) and, in some circumstances also Musical Works.

Such descriptions can, however, vary between different uses. For instance describing a Release that contains a single video ringtone track would differ greatly from a Release representing a digital equivalent of a 10-track pop album with previews. Similarly the commercial information regarding a subscription ringtone differs from commercial information regarding a pay-as-you go download.

In order to aid companies that only wish to communicate a small subset of the types of products that the “full” DDEX standards allow DDEX has developed a series of “profiles”. These profiles come in two flavours. Firstly “Release Profiles” that define subsets of Releases to be communicated along the music delivery chain and, secondly, “Business Profiles” that define subsets of the commercial information governing the distribution of Releases.

This standard defines a set of thirteen Release Profiles that define how to use the Electronic Release Notification Message Suite Standard to express the most common types of Releases. This is the second edition of Version 1.0 of the Release Profile Standard for Common Release Types. It adds support for Classical Releases by replacing the “Simple Digital Classical Audio Album” with a more complete “Classical Audio Album”.

The full set of Release and Business Profiles is available from http://ddex.net. Any organisation wishing to implement this (or any other DDEX Standard) is required to apply for an Implementation Licence. The terms of the licence and an application form can be found at http://ddex.net/implementing-ddex-standards.

2 Scope

 

 2.1 Introduction

This standard defines the Release Profiles for common Release Types. They are provided in two forms: A summary of the differences between this Release Profile and relevant “full” standard and through sample XML code.

Complete, valid, sample XML files supporting these Release Profiles are available for download from http://ddex.net as part of the DDEX.

 2.2 Nomenclature

The following mathematical nomenclature is used in this standard.
  • “0-1” means that at most one (i.e. either none or one) element has to be included in the relevant Profile;
  •  “0-∞” means that any number (i.e. either none, one or more) of elements may be included in the relevant Profile; and
  • “1-∞” means that at least one element have to be included in the relevant Profile.

The term “mandatory” encompasses the two cardinality expressions “1” and “1-∞”. The term “optional” encompasses the two cardinality expressions “0-1” and “0-∞”.

 2.3 Organisation of the Document

This standard has five clauses and two Annex.

Clauses 1 and 2 provides an introduction and scope as well as defining core terms. Clause 3 then defines the Release Profiles covered by this standard. Its components, and how they are to be communicated is then defined in Clause 4. Finally, Clause 5 documents constrains on various Release Types defined herein.

Annex A then provides information on how to communicate allowed-values defined in a later version of the Electronic Release Notification Message Suite Standard in a message created in accordance with an earlier version of the Electronic Release Notification Message Suite Standard.  Annex B provides the sample XML files.

 2.4 Normative References

The following normative documents contain provisions, which through reference in this text constitute provisions of this Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest version applies.
  • Digital Data Exchange (DDEX): Electronic Release Notification Message Suite Standard, Version 3.6

Note: the provisions within this standard are specific to the above-mentioned standard. However, users for older versions of the baseline standards are encouraged to still follow the rules defined herein wherever technically and practically possible as the provisions within this profile standard are accepted best practice for the communication of Release information.

Special notice is given to the definitions, abbreviations and conformance rules used/defined in these standards, which also apply to this standard.

 2.5 Release Notes

Version 1.1 provides additional Release Profiles to those defined in Version 1.1. Version 1.1 also tightens the rules for some of the profiles based on implementation experiences.

3 Definition of Release Profiles

 Click here to expand...

Special notice is given to the definitions, abbreviations and conformance rules used/defined in these standards, which also apply to this standard.

The Release Profiles defined herein is a subset of the descriptions for Releases, including their components and the order/grouping of such Resources as used in the relevant “full” message suite standard. The differences are described in Table 1.

Each of the lines of the table defines one Release Profile. Further details of these are then provided, for each of them, in Clauses 3 and 4.

Table 1 — Release Profiles defined in this Standard

Release Profile
Name and description

Resources contained in Release

Primary Resources/Collections

Secondary Resources

1. Audio Single

One or more SoundRecording(s) plus supporting cover image.

  • 1-∞ SoundRecording of type MusicalWorkSoundRecording
  • 1 Image of type FrontCoverImage,
  • 0-∞ items of bonus material
  • 1 Image of type FrontCoverImage,
  • 0-∞ items of bonus material

2. Video Single

One or more music video recording(s) plus support screen capture image.

  • 1-∞ Video of type ShortFormMusicalWorkVideo
  • 1 Image of type VideoScreenCapture
  • 0-∞ items of bonus material
  • 1 Image of type VideoScreenCapture
  • 0-∞ items of bonus material

3. Mixed Media Bundle

A product with a mixture of several audio and video recordings and potentially images and text, plus supporting screen capture per video track and a single cover image.

  • 0-∞ SoundRecordings of type MusicalWorkSoundRecording
  • 0-∞ Videos of type ShortForm­MusicalWorkVideo
  • 0-∞ Images with a type of either Photograph, FrontCoverImage, BackCoverImage, BookletFrontImage BookletBackImage, Poster or Wallpaper
  • 0-∞ Texts
  • At least 2 Resources of different types need to be communicated
  • 1 Image of type FrontCoverImage
  • 0-∞ Images of type Video­ScreenCapture
  • 0-∞ items of bonus material (e.g. such as Images and Booklets)
  • 1 Image of type FrontCoverImage
  • 0-∞ Images of type Video­ScreenCapture
  • 0-∞ items of bonus material (e.g. such as Images and Booklets)

4. Audio Album

A product with several audio recordings, some of which are not songs, plus supporting cover image, including singles containing more than one Resource. Examples include comedy shows.

  • 1-∞ SoundRecordings of type MusicalWorkSoundRecording or NonMusicalWorkSoundRecording
  • 1 Image of type FrontCoverImage
  • 0-∞ items of bonus material
  • 1 Image of type FrontCoverImage
  • 0-∞ items of bonus material

5. Video Album

A product with several video recordings, plus screen capture per track and supporting cover image.

  • 1-∞ Video of type ShortFormMusicalWorkVideo
  • 1 Image of type FrontCoverImage
  • 0-∞ Images of type VideoScreenCapture
  • 0-∞ items of bonus material
  • 1 Image of type FrontCoverImage
  • 0-∞ Images of type VideoScreenCapture
  • 0-∞ items of bonus material

6. Ringtone

A single audio mobile ringtone clip using a SoundRecioring Resource.

  • 1 SoundRecording of type of either MusicalWorkSoundRecording or NonMusicalWorkSoundRecording
  • 0-1 Image of type FrontCoverImage
0-1 Image of type FrontCoverImage

7. MidiRingtone

A single audio mobile ringtone clip using a MIDI Resource.

  • 1 Midi Resource of type of either MonophonicMidi or PolyphonicMidi
  • 0-1 Image of type FrontCoverImage
0-1 Image of type FrontCoverImage

8. Long-form Music Video

A multi-chapter long form video recording, plus a supporting cover image and potentially a screen capture per chapter.

  • 1 Video with a type of either LongFormMusicalWorkVideo, ConcertVideo or Documentary
  • 1 Image of type FrontCoverImage
  • 0-∞ Images of type VideoScreenCapture
  • 0-∞ items of bonus material
  • 1 Image of type FrontCoverImage
  • 0-∞ Images of type VideoScreenCapture
  • 0-∞ items of bonus material

9. Digital Boxed Set

A multi-volume/component digital product made up of a number of other existing digital products, plus supporting cover image(s).

  • 0-∞ SoundRecordings of type MusicalWorkSoundRecording
  • 0-∞ Videos of type ShortFormMusicalWorkVideo
  • 1-∞ Images of type FrontCoverImage
  • 0-∞ Images of type VideoScreenCapture
  • 0-∞ items of bonus material

10. Classical Audio Album

A product with several audio recordings, grouped into classical works, plus supporting cover image.

  • 1-∞ SoundRecordings of type MusicalWorkSoundRecording, albeit with additional elements as defined below
  • 0-∞ SoundRecordings of type MusicalWorkSoundRecording, without the additional elements referenced in the previous bullet
  • 1 Image of type FrontCoverImage
  • 0-∞ items of bonus material
  • 1 Image of type FrontCoverImage
  • 0-∞ items of bonus material

11. Single Resource Release

A single Resource not for distribution to consumers. Typically provided to a partner for finger printing /rights management type services.

  • 1 Resource of any type

None

4 Communication of Release Profiles in Release Notifications

 4.1 Set of Releases in a NewReleaseMessage

When communicating a specific Release Profile in a NewReleaseMessage defined in the Electronic Release Notification Message Suite Standard, the following individual Releases shall be communicated in one singe XML file:

Table 2 — Communicating Release Profiles

Release Profile

Main Release

Components Releases

1. Audio Single

1 Single Releases in accordance with  Clause 5.2.10 and Table 1

  • 1 TrackRelease in accordance with Clause 5.2.11
  • A Component Release should be supplied for the primary resource referenced on the Main release, regardless of whether there are any deals available for the Component Release.

2. Video Single

1 VideoSingle Release in accordance with  Clause 5.2.14 and Table 1

  • 1 VideoTrackRelease in accordance with Clause 5.2.15
  • AComponent Release should be supplied for the primary resource referenced on the Main release, regardless of whether there are any deals available for the Component Release.

3. Mixed Media Bundle

1 Bundle Release in accordance with Clause 5.2.6 and Table 1

  • 0-∞ TrackReleases in accordance with Clause 5.2.11
  • 0-∞ VideoTrackReleases in accordance with Clause 5.2.15
  • A Component Release should be supplied per primary resource referenced on the Main release, regardless of whether there are any deals available for the Component Release.

4. Audio Album (Music and Speech)

1 Album Release in accordance with Clause 5.2.4 and Table 1
or
1 Single Release (for multi-track singles) in accordance with Clause 5.2.10 and Table 1

  • 1-∞ TrackReleases in accordance with Clause 5.2.11
  • A Component Release should be supplied per primary resource referenced on the Main release, regardless of whether there are any deals available for the Component Release.

5. Video Album

1 VideoAlbum Release in accordance with Clause 5.2.13 and Table 1

  • 0-∞ VideoTrackReleases in accordance with Clause 5.2.15
  • A Component Release should be supplied per primary resource referenced on the Main release, regardless of whether there are any deals available for the Component Release.

6. Ringtone

1 RingtoneRelease Release in accordance with Clause 5.2.9 and Table 1

None

7. MidiRingtone

1 RingtoneRelease Release in accordance with Clause 5.2.9 and Table 1

None

8. Long-form Music Video

One LongFormMusicalWork-VideoRelease in accordance with Clause 5.2.8 and Table 1

None

9. Digital Boxed Set

1 DigitalBoxedSet Release in accordance with Clause 5.2.7 and Table 1

  • 0-∞ TrackReleases in accordance with Clause 5.2.11
  • 0-∞ VideoTrackReleases in accordance with Clause 5.2.15
  • A Component Release should be supplied per primary resource referenced on the Main release, regardless of whether there are any deals available for the Component Release.
  • The constituent Releases (i.e. the Releases (typically Albums or Bundles) shall not be communicated in the same NewRelease­Message. If to be offered, these need to be communicated as a Main Release in a separate NewReleaseMessage.

10. Classical Audio Album

1 Album Release in accordance with Clause 5.2.5 and Table 1

  • 1-∞ TrackReleases in accordance with Clause 5.2.11
  • A Component Release should be supplied per primary resource referenced on the Main release, regardless of whether there are any deals available for the Component Release.

11. Single Resource Release

1 Release with ReleaseType “SingleResourceRelease” in accordance with the rules defined in Clause 5.2.12 and Table 1

None


 4.2 Signalling a Specific Release Profile

To indicate in the NewRelaseMessage the use of a specific Profile, the ReleaseProfileVersionId attribute on the root tag of the message shall be set as follows:
CommonReleaseTypes/11/xxx

With “xxx” being the name of the Profile of the Main Release as defined in bold face in column 1 of Table 2 without any space, dash or parentheses characters. For example, a NewReleseMessage for communicating an Audio Album (Music and Speech) defined herein shall have the ReleaseProfileVersionId attribute set to

CommonReleaseTypes/11/AudioAlbumMusicandSpeech

 4.3 Communication of Resource Files

When communicating a Release, the message sender shall ensure that for all Resources a Resource File is communicated to the message recipient before the Release (or part of the Release) is to be made available to consumers.

When communicating a Resource File, the message sender shall include a TechnicalResourceDetails composite in the relevant Resource composite in the NewReleaseMessage.

When updating Resource information, the message sender is not obliged to re-send Resource Files. The absence of a Resource File for a specific Resource is indicated by the absence of the relevant TechnicalResourceDetails composite.

When the message sender wishes to update a Resource File for a specific Resource, the message sender shall include a TechnicalResourceDetails composite in the relevant Resource composite in the NewReleaseMessage.

 

5 Description of Release Profiles

5.1 Release Structures

 5.1.1 Release Structures for Main Releases

Main Releases shall use the ResourceGroup hierarchy depicted in Figure 1.

In addition the following rules shall be applied:

  1. Main Releases should have the IsMainRelease flag set to True.[1]
  2. Track bundle resource groups should be sequenced.
  3. All Primary Resources should be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).
  4. Secondary Resources (e.g. cover images) content items shall not be sequenced.
  5. For each Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided;
  6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to; and
  7. Resources Level Attributes held at the ResourceGroupContentItem level to qualify the use of a Resource on a Release include:
    1. Bonus Tracks and
    2. Hidden Tracks.

Figure 1 — Release Structures: Main Releases

Please note, that ResourceGroups are also used to represent multi-part musical works in Classical Audio Albums (see also Clause 5.2.5).



[1] In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.

 5.1.2 Release Structures for Component Releases

For Component Releases the resource grouping hierarchy depicted in Figure 2 shall be used.

 

Figure 2 — Release Structures: Component Releases

In addition the following rules shall be applied:

  1. All Primary Resources should be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).
  2. Secondary Resources (e.g. cover images) content items shall not be sequenced.
  3. For each Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided;

 5.1.3 Cue Sheet Structure for Longform Viedeo Releases

For Longform Video releases cue sheets are expressed using the CueSheetList. The following rules apply:

  1. Each primary Longform video resource should have a corresponding CueSheet referenced using the VideoCueSheetReference on the resource.
  2. Each CueSheet will consist of at least one Cue.
  3. Each Cue should have a StartTime and Duration.
  4. For NewReleaseMessages up to version 3.2 each Cue should reference a SoundRecording resource (using the CueResourceReference) OR a MusicalWork (using the CueWorkReference) included in the NewReleaseMessage.
  5. For NewReleaseMessages from version 3.3 upwards each Cue should include the following referenced creation details directly within the Cue:
    1. It should contain one ReferencedCreationId of type ISRC or ISWC.
    2. It should have exactly one ReferencedCreationTitle of type FormalTitle and a ReferencedCreationTitle of type DisplayTitle shall be provided.
    3. It should contain at least one ReferencedCreationContributor.
    4. It should contain a HasMusicalContent flag = ‘True’.
    5. It should contain a PLine.
    6. It should contain a CLine.

 5.1.4 Chapter Sheet Structure for Longform Viedeo Releases

For Longform Video releases chapters are expressed using the CollectionList. The following rules apply:

  1. Each collection item should have the collection type ‘VideoChapter’.
  2. Each collection item should have a proprietary CollectionId.
  3. Each collection item should have one Title.
  4. Each collection item should have an IsComplete flag set to ‘True’
  5. Each collection item should have a CollectionResourceReferenceList containing one reference to the Video representing the primary resource on the Longform release.
  6. Each collection item may have a RepresentativeImageReference which references the screen capture Image resource representing that chapter.
  7. The primary Video resource should have a SoundRecordingCollectionReference for each ‘VideoChapter’ collection item.
  8. Each SoundRecordingCollectionReference on the primary Video resource should have a StartTime indicating the chapter start time on the Video.

 5.1.5 Physical Releases

A Release that is made available to consumers using a UseType of PurchaseOfPhysicalProduct shall be a Release in accordance with a Relevant Release profile defined in Table1 and structured, using ResourceGroups, as follows:

5.1.5.1 PhysicalProduct

The top (root) level ResourceGroup represents the Release itself (it is therefore, the same as for digital Release structures)

  • The Product ResouceGroup is mandatory; and
  • The Product ResouceGroup contains either
    • 1-n ComponentProduct (i.e. boxed set); or
    • 1-n Components (i.e. non-boxed set); and
  • A SequenceNumber shall be used to order the ResouceGroup(s) within the PhysicalProduct ResourceGroup.

Note: ultimately, each PhysicalProduct contains Components. However, it may be that this relationship is via a ComponentProduct and not direct.

5.1.5.2 ComponentProduct

This ResourceGroup “mirrors” an existing physical product, bundled into a boxed set. It will consist of one or more Components (see below).

  • The ComponentProduct ResouceGroup is optional;
  • The ComponentProduct ResouceGroup shall be identified by a ICPN;
  • The ComponentProduct ResouceGroup shall have a DisplayTitle;
  • The ComponentProduct ResouceGroup shall contain 1-n Components; and
  • A SequenceNumber shall be used to order the ResouceGroup(s) within the ComponentProduct ResourceGroup.

5.1.5.3 Component

This ResourceGroup represents the physical instance of a sound carrier – i.e. a disk or tape or other sound carrier. It

  • The Component ResouceGroup is mandatory;
  • The Component ResouceGroup shall be identified by a ICPN;
  • The Component ResouceGroup shall have a SoundCarrierType
  • The ComponentProduct ResouceGroup may have a DisplayTitle
  •  The ComponentProduct ResouceGroupmay contain one of the following:
    • 0 or 2 Sides (if only 1 side is present, no Side is required);
    • 2-n Layers; or
    • 1 TrackList; and
  • A SequenceNumber shall be used to order the ResouceGroup(s) within the Component ResourceGroup.

Note: the SoundCarrierType is not supported in versions 3.5.x and older.

5.2.5.4 Side

Some SoundCarriers may have 2 sides. This ResouceGroup is not needed for single sided components.

  • A Side ResouceGroupmay contain one of the following:
    • 2-n Layer; or
    • 1 TrackList; and
  • A SequenceNumber shall be used to order the ResouceGroup(s) or ResouceGroupContentItems(s) within the Side ResouceGroup.

5.2.5.5 Layer

Some sound carriers may have multiple layers, supporting different media types. This ResouceGroup is not needed for single layered components.

  • A Layer ResouceGroup shall contain 1 TrackList; and
  • A SequenceNumber shall be used to order the ResouceGroup(s) or ResouceGroupContentItems(s) within the Layer ResouceGroup.

5.2.5.6 TrackList

Each component, or side, or layer, ultimately consists if of a sequence ResourceGroupContentItems.

A SequenceNumber shall be used to order the  ResouceGroupContentItems(s) within the TrackList ResouceGroup.

 

5.2 Release Descriptions

 5.2.1 Data fields not listed for a specific Release Profile

Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

 5.2.2 Territorial data for Releases or Resources

If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for the territory ‘worldwide’ or for all territories that MessageSender and MessageRecipient have commercial relationships about.

If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

  • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

or

  • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

 5.2.3 Data fields common to all Release Profiles

All Release Profiles defined herein shall follow these rules:

  1. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used.
  2. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable.
  3. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.
  4. Information about the issuing Label shall be communicated.
  5. At least one Genre shall be provided.
  6. The appropriate ParentalWarningType shall be provided.
  7. Either GlobalOriginalReleaseDate or, for each territorial variation, a ReleaseDate should be provided for the Release if available to the Message Sender.

    It should be noted, that a MessageReceiver may infer a GlobalOriginalReleaseDate by using the earliest territorial ReleaseDate.

  8. Any ComponentRelease shall provide a link back to the MainRelease using a ReleaseRelationshipType of IsParentRelease.
  9. For each Resource the sender shall provide
    1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access[1] to. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist.
    2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role.
    3. A DisplayArtist.
  10. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs.
  11. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites.
  12. For each Release the sender shall provide:
    1. A DisplayArtist. Note: providing a DisplayArtist on Release level does not mean that the same DisplayArtist can be omitted on Resource level.
  13. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release.
  14. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaim-Percentages for each MusicalWork may not exceed 100%.
  15. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders.
  16. To communicate that a Resource is either hidden, a bonus resource or an instant-gratification resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used.

When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayAtristName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayAtrist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayAtrist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them.

Note: While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator.



[1] Data that the sender has no authority, for instance because of contractual obligations, should not be communicated.

More information about the communication of artists can be found here.

 5.2.4 Album

A Release of type Album shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.
  2. The Release shall have a ReleaseType of Album.
  3. The Release shall be identified by either a GRid or by an ICPN.
  4. Primary Resources shall be identified with an ISRC.
  5. Secondary Resources shall be identified by a ProprietaryId.
  6. The Release resource structure as defined in Clause 5.1 shall be communicated.
  7. A LabelName shall be provided.
  8. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.

 5.2.5 Classical Album

A Release of type Classical Album shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1. The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.
  2. The Release shall have a ReleaseType of ClassicalAlbum.
  3. The Release shall be identified by either a GRid or by an ICPN.
  4. Primary Resources shall be identified with an ISRC.
  5. Secondary Resources shall be identified by a ProprietaryId.
  6. A LabelName shall be provided.
  7. At least one IndirectResourceContributors of type Composer or ComposerLyricist shall be communicated if available.
  8. If a publisher is to be communicated an IndirectResourceContributors of type Music–Publisher shall be communicated.
  9. The ReferenceTitle of each SoundRecording shall denote the most granular bit of the full title of a work. For instance in a CD of Vivaldi’s Four Seasons with 12 tracks (each representing one movement of each of the four concerts), the ReferenceTitles of the first four SoundRecordings would be “1. Allegro”, “2. Largo”, “3. Allegro Pastorale, and “1. Allegro”. The precise syntax of ReferenceTitles is left to the MessageSender and may (or may not include a sequence number). Note: The above only applies if the SoundRecording is based on a MusicalWorlk with a hierarchical title.
  10. 10. A GroupingTitle denoting the parent of each SoundRecording shall be communicated for each territorial variation if the SoundRecording is a MusicalWork that is part of a hierarchical Work. In the above example the Grouping Title for the first three SoundRecordings would be “Concerto for Violin and Strings in E-Major, Op. 8, No. 1, RV 296 ‘La Primavera’”. The precise syntax of GroupingTitles is left to the MessageSender
  11. A DisplayTitle should be communicated for each territorial variation. This title may be used to communicate concatenations of composer name, GroupingTitle and ReferenceTitle. The DisplayTitle may be omitted if the MessageSender does not want to communicate a specific title string for display purposes.
  12. ResourceGroups shall be used to communicate both work-related and carrier-related hierarchies. The former shall be indicated by providing a GroupingTitle and the latter by providing an un-typed Title. Work-related hierarchies shall only be provided for SoundRecordings that are based on a MusicalWork that is part of a hierarchical Work
  13. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message. This specifically includes the use of work information in the MusicalWorkList composite.

Samples of structured Classical Albums are shown in the table below.

Table 3: Samples of structured Classical Albums (Informative)

Type of Release

Rules for the Release Group

Collection of single segment Works
(e.g. a crossover album with one
segment[1] from three Works each)

ResourceGroup representing the disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

        ResourceGroup representing the 2nd Work containing

               ResourceGroupContentItem representing the 2nd segment (=Track 2)

        ResourceGroup representing the 3rd Work containing

               ResourceGroupContentItem representing the 3rd segment (=Track 3)

Collection of multi- segment Works (e.g. a
release with two Works with three segments each)

ResourceGroup representing the disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

               ResourceGroupContentItem representing the 2st segment (=Track 2)

               ResourceGroupContentItem representing the 3rd segment (=Track 3)

        ResourceGroup representing the 2nd Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 4)

               ResourceGroupContentItem representing the 2st segment (=Track 5)

               ResourceGroupContentItem representing the 3rd segment (=Track 6)

Single Work with multiple segments

ResourceGroup representing the disc containing

        ResourceGroup representing the Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

               ResourceGroupContentItem representing the 2st segment (=Track 2)

               ResourceGroupContentItem representing the 3rd segment (=Track 3)

Works and “tracks” mixed (disc containing
one Work with two segments, one track, a
second Work with two segments and a track)

ResourceGroup representing the disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

               ResourceGroupContentItem representing the 2st segment (=Track 2)

        ResourceGroup representing the 2nd Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 4)

               ResourceGroupContentItem representing the 1st segment (=Track 5)

        ResourceGroupContentItem representing the 1st segment (=Track 3)

        ResourceGroupContentItem representing the 1st segment (=Track 6)

Same Work repeated in product (disk with
segments one and two of the Work, then
segments one and two of a second Work
followed by segments three and four of the
first Work)

ResourceGroup representing the disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

               ResourceGroupContentItem representing the 2st segment (=Track 2)

        ResourceGroup representing the 2nd Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 3)

               ResourceGroupContentItem representing the 1st segment (=Track 4)

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 3rd segment (=Track 5)

               ResourceGroupContentItem representing the 4th segment (=Track 6)

Work spanning multiple discs (disk one
containing one Work with three segments
and disk two containing two further
segments of the same Work)

ResourceGroup representing the 1st disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

               ResourceGroupContentItem representing the 2st segment (=Track 2)

ResourceGroup representing the 2nd disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 3rd segment (=Track 3)

               ResourceGroupContentItem representing the 4th segment (=Track 4)



[1] A typical “segment” would be a work. A segment itself can be segmented itself using a ResourceGroup instead of a ResourcegroupContentItem.


 5.2.6 Mixed Media Bundle

A Release of type Mixed Media Bundle shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

1.    The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.

2.    The Release shall have a ReleaseType of Bundle.

3.    The Release shall be identified by either a GRid or by an ICPN.

4.    Primary Resources shall be identified with an ISRC if they are a SoundRecording or a music Video.

5.    Secondary Resources shall be identified by a ProprietaryId.

6.    The Release resource structure as defined in Clause 5.1 shall be communicated.

7.    A LabelName shall be provided.

8.    All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.

 

 

 5.2.7 Digital Boxed Set

A Release of type DigitalBoxedSet shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1. The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.
  2. The Release shall have a ReleaseType of DigitalBoxSetRelease.
  3. The Release shall be identified by either a GRid or by an ICPN.
  4. Primary Resources shall be identified with an ISRC.
  5. Secondary Resources shall be identified by a ProprietaryId.
  6. The Release resource structure as defined in Clause 5.1 shall be communicated.
  7. A LabelName shall be provided.
  8. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.

 5.2.8 Long-form Musical Work Video Release

A Release of type LongFormMusicalWorkVideoRelease shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1. The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.
  2. The Release shall have a ReleaseType of LongFormMusicalWorkVideoRelease.
  3. The Release shall be identified by either a GRid or by an ICPN.
  4. Primary Resources shall be identified with an ISRC.
  5. Secondary Resources shall be identified by a ProprietaryId.
  6. The Release resource structure as defined in Clause 5.1 shall be communicated.
  7. Each primary long form Video resource on the release shall contain a reference to a cue sheet as defined in Clause 5.1.3
  8. Each primary long form Video resource on the release shall contain 1 to many references to chapters as defined in Clause 5.1.4
  9. A LabelName shall be provided.
  10. 10. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.

 5.2.9 Ringtone Clip

A Release of type RingtoneClip shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1. The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.
  2. The Release shall have a ReleaseType of RingtoneRelease or RingbackToneRelease.
  3. The Release shall be identified by either a GRid or by an ICPN.
  4. Primary Resources shall be identified with an ISRC if the Release is a Ringtone bases on a SoundRecording.
  5. Primary Resources shall be identified with a ProprietaryId if the Release is a Ringtone bases on a MIDI Resource.
  6. The Release resource structure as defined in Clause 5.1 shall be communicated.
  7. A LabelName shall be provided.
  8. A RelatedRelease of type IsReleaseFromRelelease shall be provided if such a Release exists and the Message sender has reasonable access to it.
  9. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.

 5.2.10 Single

A Release of type Single shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1. The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.
  2. The Release shall have a ReleaseType of Single.
  3. The Release shall be identified by either a GRid or by an ICPN.
  4. Primary Resources shall be identified with an ISRC.
  5. Secondary Resources shall be identified by a ProprietaryId.
  6. The Release resource structure as defined in Clause 5.1 shall be communicated.
  7. A LabelName shall be provided.
  8. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.

 5.2.11 Track Release

A Release of type TrackRelease shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1. The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.
  2. The Release shall have a ReleaseType of TrackRelease.
  3. The Release shall be identified by either a GRid or by an ICPN.
  4. Primary Resources shall be identified with an ISRC.
  5. Secondary Resources shall be identified by a ProprietaryId.
  6. The Release resource structure as defined in Clause 5.1 shall be communicated.
  7. A LabelName shall be provided.
  8. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.

 5.2.12 Single Resource Release

A Release of type SingleResourceRelease shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1.  The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.
  2. The Release shall have a ReleaseType of SingleResourceRelease.
  3. The Release shall be identified by either a GRid or an ISRC.
  4. The one Primary Resource shall be identified with an ISRC.
  5. No Secondary Resources should be supplied.
  6. No release resource structure should be provided.
  7. A LabelName shall be provided.
  8. A RightShare for the publisher, owning the right share and the company administering the rights by providing
    1. A RightShareReference;
    2. The list of TerritoryCodes (or ExcludedTerritoryCodes) that identify the territorial reach of the RightsClaim;
    3. The FullName of the RightsController;
    4. The RightsAdministratorRole and
    5. A ValidityPeriod if known.
  9. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.

 5.2.13 Video Album

A Release of type VideoAlbum shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1.  The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.
  2. The Release shall have a ReleaseType of VideoAlbum.
  3. The Release shall be identified by either a GRid or by an ICPN.
  4. Primary Resources shall be identified with an ISRC.
  5. Secondary Resources shall be identified by a ProprietaryId.
  6. The Release resource structure as defined in Clause 5.1 shall be communicated.
  7. A LabelName shall be provided.
  8. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.

 5.2.14 Video Single

A Release of type VideoSingle shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1. The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.
  2. The Release shall have a ReleaseType of VideoSingle.
  3. The Release shall be identified by either a GRid or by an ICPN.
  4. Primary Resources shall be identified with an ISRC.
  5. Secondary Resources shall be identified by a ProprietaryId.
  6. The Release resource structure as defined in Clause 5.1 shall be communicated.
  7. A LabelName shall be provided.
  8. A RelatedRelease of type IsEquivalentToAudio may be provided if such information is available.
  9. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.

 5.2.15 Video Track Release

A Release of type VideoTrackRelease shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1.  The description shall follow the common rules defined in Clauses 5.1 and 5.2.2.
  2. The Release shall have a ReleaseType of VideoTrackRelease.
  3. The Release shall be identified by either a GRid or by an ICPN.
  4. Primary Resources shall be identified with an ISRC.
  5. Secondary Resources shall be identified by a ProprietaryId.
  6. The Release resource structure as defined in Clause 5.1 shall be communicated.
  7. A LabelName shall be provided.
  8. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.

Annexes

 Annex A (informative) Communication of Allowed Values defined in a later Standard

In order to communicate an allowed values defined by DDEX later than the message format used in the communication between two business partners the following approach shall be taken:
  1. The element shall contain the value “UserDefined”;
  2. The UserDefinedValue attribute shall be set to the value from the later standard; and
  3. The Namespace attribute shall be set to the same value as defined as normative content for the MessageVersionId attribute for that standard.

For example, to communicate a UseType of KioskDownload, a term defined for Version 3.3 of the Release Notification Standard in a Version 3.2 message the following XML code shall be used:

<UseType UserDefinedValue="KioskDownload" Namespace="ern/33">
   UserDefinedValue
</UseType>

 Annex B (normative) XML Samples
Normative XML Samples are provided in separate files as detailed below. Conformance requires looking at the relevant Release Profile files (defined here) and the relevant Business Profile files (defined elsewhere).

The XML Sample files are named in one of three ways:

The Business Profile samples are named Profile_xxx.xml with xxx being the name of the Profile or ProfileVariant_xxx.xml for a variant of a profile for a specific use case.

Evaluation Licence for DDEX Standards

 

 

Subject to your compliance with the terms and conditions of this Agreement, DDEX™ grants you a limited, nonexclusive, non-transferable, non-sublicenseable, royalty-free licence solely to reproduce, distribute within your organisation, and use the DDEX standard specifications (“DDEX Standards”) solely for the purpose of your internal evaluation. You may not make any commercial use of the DDEX Standards under this agreement. No other licences are granted under this agreement.

No representations or warranties (either express or implied) are made or offered by DDEX with regard to the DDEX Standards. In particular, but without limitation, no representations or warranties are made in relation to:

  1. The suitability or fitness of the standards for any particular purpose;
  2. The merchantability of the standards;
  3. The accuracy, completeness, relevance or validity of the standards; or
  4. The non-infringement of any third party intellectual property rights related to the DDEX Standards.

Accordingly, DDEX and/or its members shall not be liable for any direct, indirect, special, consequential or punitive loss or damages howsoever arising out of or in connection with the use of the standards. IN THE EVENT THAT ANY COURT OF COMPETENT JURISDICTION RENDERS JUDGEMENT AGAINST DDEX AND/OR ITS MEMBERS NOTWITHSTANDING THE ABOVE LIMITATION, THE AGGREGATE LIABILITY TO YOU IN CONNECTION WITH THIS AGREEMENT SHALL IN NO EVENT EXCEED THE AMOUNT OF ONE HUNDRED U.S. DOLLARS (US$ 100.00).

Users of the DDEX Standards are cautioned that it is subject to revision. Users are recommended to use the latest versions, which are available at http://www.ddex.net. The use of outdated versions of the standards is not recommended but may be required by agreement between implementers in particular cases.