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.
The standard also allows companies to forward such information when they have received such information from third parties and for companies to ask other companies for such links.
Note: for such a link to be communicated it is neither mandatory for the Sound Recording(s) to be identified by an ISRC nor for the Musical Work(s) to be identified by an ISWC.
Clauses 1-4 provide an introduction, the scope of the standard as well as the definitions and abbreviations used in this standard. Clause 5 then defines the choreography for sharing information about links between Musical Works and Sound Recordings or Music Video Recordings between business partners before Clause 6 then defines the syntax of the messages used for that information exchange and discusses the approach used to determine the authority of a link communicated in a message conformant to this standard.
3 Normative References
- DDEX Data Dictionary Standard. Latest Version
- DDEX Party Identifier (DPID) Standard. Latest Version
- ISO 3901:2001, Information and documentation – International Standard Recording Code (ISRC). 2001
- ISO 8601:2004, Data elements and interchange formats – Information interchange – Representation of dates and times
- ISO 15707:2001, Information and documentation – International Standard Musical Work Code (ISWC). 2001
- W3C. XML Schema Part 1: Structures. Second Edition. 2004
- W3C. XML Schema Part 2: Datatypes. Second Edition. 2004
4 Terms and Abbreviations
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.
An audible persistent manifestation of a subject (often but not necessarily of a performance).
For the purposes of this standard, Sound Recordings must be eligible for the allocation of an ISRC.
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.
For the purposes of this standard, Resources are Sound Recordings and short form videos that are eligible for the allocation of an ISRC.
The link between a sound recording or video Resource and one or more Musical Work(s) in which a party asserts that the sound recording makes use of the Musical Work or Works.
|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|
|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)|
LinkResourceAndWorkMessage, can be sent by any party that wishes to communicate a Resource-Work Link. The recipient of this message shall reply, in a timely manner with a
LinkAcknowledgementMessageto inform the sender of the
LinkResourceAndWorkMessageof the receipt of the message. Such
LinkResourceAndWorkMessagess can be sent in reply to a
LinkRequestMessageor based on any other trigger.
The acknowledgement message can also be used to signal, for instance, conflicts between different link claims. For the avoidance of doubt, the resolution of any conflicts is outside the scope of this standard.
This choreography is show in the diagram below:
6 Message Definition
This Clause contains an overview of the three messages in the Standard for requesting and communicating Links between Resources and Musical Works in a tabular form. The full technical specification is included in the XML Schema files accompanying this standard.
The hierarchical structure of the messages is provided through indentation. On the
MessageHeader for example, the
PartyName is a child of
Sender. Thus, a
Sender contains a
PartyName (plus a
PartyId). A second example from the
MessageHeader is the
MessageAuditTrail that contains
MessageAuditTrailEvents which, in turn, contains a
MessagingPartyDescriptor and a
DateTime element. All elements that have sub-elements are printed in bold. The
MessageAuditTrailEvents element also shows a second structural feature of the
MessageSummary: 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 addition to the tabular description of the messages, 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 6.3.
The syntax as well as the semantics of the various elements in the message is provided in Clause 6.4. 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.
LinkResourceAndWorkMessagecontains one or more
AssertedLinkcomposites. Each of these links can be asserted by different parties at different points in time as communicated in an
AssertedLink/Assertioncomposite (also depicted above).
As mentioned above and as shown in the diagrams, each such assertion is made by a party, the identity of which is communicated in the
Assertion/Asserter composite. This asserter may well differ from the actual sender of the
LinkResourceAndWorkMessage was not conceived to enable the communication of information that provides an indication of the level of authority (that is, the reliability) that the recipient of a
LinkResourceAndWorkMessage should construe as to the validity of the AssertedLink contained in a
LinkResourceAndWorkMessage. Therefore, it is entirely up to the recipient of the
LinkResourceAndWorkMessage to assess the authority of the received information by means other than solely through the exchange of the
6.3.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.
6.3.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.
6.3.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 as agreed between two business partners.
In such circumstances, a message is deemed conformant only if and when it contains all the “contractually mandatory” fields as agreed by
6.3.5 Character Coding
All messages shall be sent in UTF-8.
The LinkResourcesAndWorkMessage is structured as shown in the three following diagrams:
The LinkAcknowledgementMessage is structured as shown in the three following diagrams:
LinkRequestMessageis structured as shown in the diagram below.
Senders of the
LinkRequestMessage should bear in mind that the quality of the information provided in the request will have a significant impact on the quality of any returned link; companies that provide such links may well establish minimum data quality rules that would stop them from returning any links based on what they perceive low quality data in requests. Senders of the
LinkRequestMessage are therefore advised to take care to provide as much high-quality information as possible when sending
The Table of AVSs is provided in a separate document. See the red 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.