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
- Provide to Record Companies, DSPs and other companies information about ownership of Right Shares in one or more Musical Works in a standardised information flow;
- Exchange with DSPs offering “user-generated content” to consumers information about ownership of Rights Shares in one or more Musical Works.
As user-generated content is often based on musical works, it is essential for the owners of rights in the Musical Work as well as the DSP that the DSP has an accurate picture of the ownership of a Musical Work they want to exploit and monetise. This is particularly important for territories such as the US where licensing is typically de-centralised or on a Work-by-Work basis;
The Choreography can also be used for information exchanges regarding Musical Works and/or Right Shares as part of the US Musical Work Licensing Choreography as well as the US Letter of Directions Choreography.
Furthermore it allows DSPs, record companies and other companies to solicit such information from Works Licensors. Such requests may often include information about the Release(s) and Resource(s) such Works are used in.
Other applications include the provision of Lyrics to a Lyrics DSP, the provision of information on print rights, cases where a DSP might want to augment writer data they hold in order to improve consumer experience and supplying data to intermediaries who are doing administration on a DSP’s behalf.
3 Normative References
- DDEX Data Dictionary Standard. Latest Version
- DDEX Party Identifier (DPID) Standard. Latest Version
- IFPI: Global Release Identifier (GRid) Standard. Latest Version
- IETF. RfC 2026. SSH File Transfer Protocol. October 2001.
- IETF RfC 5646, Tags for Identifying Languages. Latest Version.
- ISO 639-1988, Code for the representation of the names of languages
- ISO 3166-1:1997 Codes for the representation of names of countries and their sub-divisions – Part 1: Country codes
- ISO 3901:2001, Information and documentation – International Standard Recording Code (ISRC)
- ISO 8601:2004, Data elements and interchange formats – Information interchange – Representation of dates and times
- W3C. XML Schema Part 1: Structures. Second Edition. 2004
- W3C. XML Schema Part 2: Datatypes. Second Edition. 2004
4 Terms and Abbreviations
A Party administrating Rights on behalf of one or more RightsControllers (in the context of this standard a Collecting Publisher).
A grouping of one or more DDEX Messages to be processed by the recipient together.
A RightsController who is, at the time of assertion, controlling the right to collect royalties for a specific RightsType in a specific Territory for a specific Musical Work. Collecting Publishers may ask Administrators to administer some of their rights. Note that a MusicalWork may have zero, one or many Collecting publishers.
Collective Rights Organisation
A Party that is an Administrator on behalf of many Rights Controllers usually in respect of one territory. A Collective Rights Organisation may also be a Rights Controller.
The proportion of the overall Musical Work that has been assigned to a Collecting Publisher or Administrator. Note that a Writer can have zero, one or many Original Publishers, and hence zero, one or many Distribution Shares.
The proportion of a Musical Work written by a Writer, as agreed between the Writers. Typically represented as a percentage or a fraction. Manuscript Shares may occasionally vary by territory and/or rights type.
A Work intended to be perceivable as a combination of sounds, with or without accompanying text.
Any words that are intended to be expressed with a MusicalWork (often termed Lyrics) form part of that MusicalWork; not all MusicalWorks have Lyrics.
A MusicalWork may be expressed and fixed to become part of a SoundRecording or a Video Recording, or may be used to create notated music (sheet music, scores, instrumental parts) or sound generation codes (such as MIDI files).
In some cases, the MusicalWork comes into existence simultaneously with its expression. This is common in extemporised forms such as jazz music.
A RightsController who is assigned rights directly by the Writer. Note that a writer may have zero, one or many Original Publishers.
Original Publisher Share
The proportion of the overall Musical Work that a writer has assigned to an Original Publisher. Note that each Writer can have zero, one or many Original Publishers, and hence zero, one or many Original Publisher Shares.
A Release is an abstract entity representing a bundle of one or more Resources compiled by an Issuer for the purpose of distribution to individual consumers, directly or through intermediaries. The Resources in Releases are normally primarily sound recordings or music audio-visual recordings, but this is not invariably the case. The Release is not itself the item of trade (or “Product”). Products have more extensive attributes than Releases; one Release may be disseminated in many different Products.
A digital fixation of an expression of an abstract Work (such as a sound recording, a video, an image, software or a passage of text). Resources are individual assets that make up a Release. Typical Resources are sound recordings, video clips and cover art images.
A percentage or fraction of a right for a Musical Work for a particular time and place in which a party claims a controlling interest. Note: controlling interest includes ownership and/or administration.
A Party who owns and/or controls rights in a Musical Work or other Creation.
In the context of this standard a Rights Controller is normally a Collecting Publisher or a Collective Rights Organisation.
Creations include Musical Works, Sound Recordings and other Resources as well as Releases. Rights Controllers are, in the context of a licence agreement, often referred to as Licensors.
Note: In many cases a RightsController is also the Licensor.
The type of right covered by a RightShare as defined by relevant law. Rights Types vary between territories. Typical rights types include mechanical rights, performing rights and synchronisation rights.
A creative creator of the musical or lyrical elements of a Musical Work. Writers include Adapters, Arrangers, Authors, Composers. ComposerLyricists, Librettists, Lyricists, NonLyricAuthors and Translators.
See Manuscript Share.
|AMEP||Automated Message Exchange Protocol|
|ACA||Appointed Certification Agency|
|AVS||Allowed Value Set|
Confédération internationale des sociétés d'auteurs et compositeurs, the International Confederation of Societies of Authors and Composers (see cisac.org)
|DAW||Digital Audio Workstation|
Digital Data Exchange
|DSP||Digital Service Provider (incudes Mobile Service Providers)|
|DSR||Digital Sales Reporting|
|ERN||Electronic Release Notification|
|FTP||File Transfer Protocol (FTP specifically includes SFTP)|
|GRid||Global Release Identifier|
|HTTP||Hypertext Transport Protocol (HTTP specifically includes HTTPS)|
|HTTPS||Secure Hypertext Transport Protocol|
|IEC||International Electrotechnical Commission (see iec.ch)|
|ISO||International Organisation for Standardisation (see iso.org)|
|MIME||Multipurpose Internet Mail Extensions|
|MLC||Music Licensing Company|
|MWL||Musical Works Licensing|
|MWN||Musical Works Notification|
|PCA||Private Certification Agency|
|Portable Document Format|
|RIN||Recording Information Notification|
|TIS||Territory Information System (a CISAC Standard)|
|TLS||Transport Layer Security|
|URL||Uniform Resource Locator|
|XML||eXtensible Markup Language|
|XSD||XML Schema Definition|
|W3C||World Wide Web Consortium (see w3c.org)|
The tables below summarises the points in the Musical Work and Right Share Notification Choreography that a message is sent.
If a Record Company, DSP or other Company wishes to receive information about a Musical Work and/or its ownership (e.g. for the purposes of obtaining a licence or to make available or monetise a Release containing a Musical Work) but has no, or insufficient, claims or Right Share information.
If a Works Licensor wishes to inform a DSP about its claims or Right Share information with respect to Works embodied in a Release  in response to a
If a Works Licensor wishes to provide Right Share information, or inform a business partner about its claims based on a trigger other than the receipt of a
Such triggers may include the case where the Licensor has previously provided a Right Claim for a Musical Work and subsequently loses the rights to that Right Share or Musical Work, or the resolution of a Right Share ownership conflict (possibly triggered by a message from DDEX’s Work Right Share Conflict Notification Choreography Standard).
|3||A party has finished collating |
|4||A party receives a Batch of messages in accordance with this standard. The party then acknowledges receipt of each message (not agreement with its content).|
 The message can also be used to communicate ownership information regarding a Musical Work not owned or controlled by the sender of the message. In that case, the recipient may use the information not as authoritative but solely as “helpful information”.
6 Message Exchange Protocol
The arrival of the Batch on the SFTP server shall be signified by placing a Manifest file at the appropriate location. The Manifest shall refer, indirectly or indirectly to all files that are part of the Batch. The Manifest may only be placed on the SFTP server, once all other files have been completely uploaded.
YYYYbeing the year of Batch creation;
MMbeing the month of Batch creation;
DDbeing the day of Batch creation;
hhbeing the hour of Batch creation;
mmbeing the minute of Batch creation;
ssbeing the second of Batch creation; and
nnnbeing the millisecond of Batch creation.
RRRRbeing the role of the message as follows:
- "Claim_Request" for the
- "Claim_Notification" for the
- "Claim_Request" for the
SSSSSbeing a zero padded serial number within that Batch.
FFFFbeing the file name (without extension) of the file to which supporting information is provided;
NNNNbeing a serial number; and
extbeing an extension suitable to the data type (e.g.
xmlfor an XML file or
csvfor a comma-separated value flat file).
manifest.xmland shall be placed into the same folder as all other files.
Its syntax is defined in Clause 7.
FFFFbeing the file name (without extension) of the Message acknowledged.
The Acknowledgement shall be placed into the same folder as the acknowledged file. Its syntax is defined in Clause 7.
The maximum number of files to be part of a Batch is not limited but may be agreed by Sender and Recipient.
7 Message Definition
This Clause contains an overview for each of the two messages in the Musical Work and Share Notification Choreography Standard in a tabular form. The full technical specification is includes the XML Schema files accompanying this standard.
The hierarchical structure of the messages is provided through indentation. On the Message Header for example, the
PartyName is a child of Sender. Thus, a Sender contains a
PartyName (plus a
PartyId). A second example from the Message Header is the
MessageAuditTrail that contains
MessageAuditTrailEvents which, in turn, contains a MessagingPartyDescriptor and a
DateTime element. All elements that have subelements are printed in bold. The
MessageAuditTrailEvents element also shows a second structural feature of the Message Summary: the cardinality. In the case of
MessageAuditTrailEvents the entry "1-n" means that each MessageAuditTrail contains one or more
Other possible cardinality entries are: "1" (for: exactly one), "0-1" (for none or one) or "0-n" (for none to multiple). Elements shown in italics are represented in the XML Schema as XML Attributes. In several places within the messages, the Message Sender may need to make a choice between using two or more XML elements. These instances are marked in the tabular representation of the messages below with the keyword
XmlChoice. This keyword is not part of the messages; instead exactly one of the “branches” below the
XmlChoice keyword has to be used.
In addition to the tabular description of the message, which should always be read in conjunction with the XML Schema files, additional conformance rules, which go beyond XML Schema validation, are provided where necessary. The general conformance rules for all messages within this Standard are provided in Clause 7.2.
Specific business processes between sender and recipient may require even further conformance rules. These are, however, not part of the Standard and will need to be agreed between business partners. Rules relating to the authority of business partners to unilaterally change the Message Standard in this way are set out in the current version of the Procedures for the Development and Maintenance of DDEX Standards which forms part of the overall governance of the DDEX Standards.
The syntax as well as the semantics of the various elements in the messages is provided in this Clause. They are taken from the current version of the DDEX Data Dictionary as defined through, and maintained in accordance with, the DDEX Data Dictionary Standard.
7.2.1 Schema Validation
A message is conformant to this specification only when it validates against the set of XML Schema files provided.
The full namespace for the XML Schema document for this Standard is
All messages developed within DDEX are based upon a common set of elements and their definitions. These are contained in the DDEX Data Dictionary available from ddex.net.
7.2.3 Allowed Value Lists
All messages defined in this standard make intensive use of allowed-value sets. These allowed value sets are shared between all DDEX standards and DDEX provides an XML Schema Definition file for all of these allowed values. These values are also contained in the DDEX Data Dictionary available from kb.ddex.net.
The full namespace for the XML Schema document for the allowed-value sets is:
DDEX may regularly extend this list of allowed-value sets. Any such extensions to this list issued on a date later than the date on which this Standard is issued form part of this Standard. This Clause contains the list of allowed-value sets valid on the date of issuance of this Standard.
7.2.4 Contractually Mandatory
The messages defined in this standard contain fields with cardinality “0-1” or “0-n”. Therefore these fields are from the standard’s point of view, optional. Such fields may, however, be mandatory when a DDEX message is sent in a specific commercial context.
In such circumstances, a message is deemed conformant only if and when it contains all the “contractually mandatory” fields as agreed by
The Table of AVSs is provided in a separate document. See the blue box here.
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:
- The suitability or fitness of the standards for any particular purpose;
- The merchantability of the standards;
- The accuracy, completeness, relevance or validity of the standards; or
- 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.