DDEX Standard

Skip to end of metadata
Go to start of metadata
This section of the DDEX Knowledge Base contains version 1.1 of the Standard for "Communicating Links between Resources and Musical Works"



1 Introduction

This standard was developed by the member organisations of the Digital Data Exchange, LLC (DDEX) and provides a message that gives a uniform mechanism to inform business partners of links between Sound Recordings and other Resources such as music videos, and the MusicalWorks used in those Resources. It also provides a mechanism for such links to be requested.

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
The messages defined in this standard provides a mechanism for companies that have established the identity of the Musical Work or Works embodied in a Sound Recording or Video recording and enable them to inform their business partners of this fact. The message can also be used to communicate the fact that the Musical Work (or Works) identified in the message is not embodied in the Sound Recording or Video recording identified in the message.

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.

 2.2 Organisation of the Document
This standard has six Clauses.

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.

 2.3 Release Notes
Version 1.1 adds the capabilities for a company to query another company if they have information about a link between a Musical Work and a Resource.

3 Normative References

 3 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.
  • 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

 4.1 Terms and Definitions

Musical Work

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.


Sound Recording

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.

Work-Resource Link

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.

 4.2 Abbreviations
AMEPAutomated Message Exchange Protocol
ACAAppointed Certification Agency
AVSAllowed Value Set
BPBusiness Profile

Confédération internationale des sociétés d'auteurs et compositeurs, the International Confederation of Societies of Authors and Composers (see cisac.org)

CACertification Agency
CTConformance Tester
DAWDigital Audio Workstation

Digital Data Exchange

DSIGDigital Signature
DSPDigital Service Provider (incudes Mobile Service Providers)
DSRDigital Sales Reporting
ERNElectronic Release Notification
FTPFile Transfer Protocol (FTP specifically includes SFTP)
GRidGlobal Release Identifier
HTTPHypertext Transport Protocol  (HTTP specifically includes HTTPS)
HTTPSSecure Hypertext Transport Protocol
IECInternational Electrotechnical Commission (see iec.ch)
ISOInternational Organisation for Standardisation (see iso.org)
MIMEMultipurpose Internet Mail Extensions
MWLMusical Works Licensing
MWNMusical Works Notification

Multi-Record-Block Variant

PCAPrivate Certification Agency
PDFPortable Document Format
RESTREpresentational State Transfer
RINRecording Information Notification

Single-Record-Block Variant

TISTerritory Information System (a CISAC Standard)
TLSTransport Layer Security
UGCUser-generated content
URLUniform Resource Locator
XMLeXtensible Markup Language
XSDXML Schema Definition
W3CWorld Wide Web Consortium (see w3c.org)
WSWeb Service

5 Choreography

 5 Choreography
The message defined in this standard, the 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 LinkAcknowledgementMessage to inform the sender of the LinkResourceAndWorkMessage of the receipt of the message. Such LinkResourceAndWorkMessagess can be sent in reply to a LinkRequestMessage or 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

 6.1 Introduction

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 MessageAuditTrailEvents.

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.

 6.2 Authority of Assertions
As shown above, the LinkResourceAndWorkMessage contains one or more AssertedLink composites. Each of these links can be asserted by different parties at different points in time as communicated in an AssertedLink/Assertion composite (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.

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 LinkResourceAndWorkMessage.

 6.3 General Conformance Rules

6.3.1 Schema Validation

A message is conformant to this specification only when it validates against the set of XML Schema files provided.

6.3.2 Namespace

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 MessageSender and MessageRecipient.

6.3.5 Character Coding  

All messages shall be sent in UTF-8.


 6.4 Definition of Messages

 6.4.1 LinkResourcesAndWorkMessage



The LinkResourcesAndWorkMessage is structured as shown in the three following diagrams:


 6.4.2 LinkAcknowledgementMessage

The LinkAcknowledgementMessage is structured as shown in the three following diagrams:


 6.4.3 LinkRequestMessage
The LinkRequestMessage is 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 LinkRequestMessages.

 6.5 Allowed Value Sets
The table below lists all allowed value sets with their allowed values and definitions that are valid within this standard. Note, the allowed-value sets are maintained outside of this standard and DDEX may add to the list below.

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:

  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.