DDEX standards support the automated exchange of data along the digital music value chain. There are three areas of standardisation that DDEX works on:

• Standard message formats, which define the syntax and semantics of the business data that is exchanged using computer messages between companies;

• Standard choreographies, which determine the order and flow of messages and define the “triggers” that govern when messages should be sent. The choreographies include but are not limited to acknowledgements; and

• Standard protocols, which define the mechanisms by which the messages are actually exchanged between business partners. These define details about how to exchange DDEX messages using web services or cloud storage services.

Together these three areas of standardisation can be used to automate the exchange of data for all the different types of business transactions that take place across the digital music value chain.

All the DDEX standards can be implemented free of charge provided the user acquires a DDEX Implementation Licence. You do not need to be a member of DDEX to implement any of its standards.

Although each of the standards DDEX has published are intended for use in different types of business transactions, they are all dealing with broadly data describing the same types of entities. These include:

• Data about all the individuals and organisations, and all the different roles they play in creating, managing rights in and delivering music to consumers;

• Data about all the different types of music that is created and packaged for consumers. This includes musical works, releases and resources, such as sound recordings and music videos; and

• Data about all the different types of transactions that take place and agreements that exist between all the different types of individuals and organisations that exist in the digital music value chain.

The message formats that DDEX has standardised contain ways to describe each of the above entities (and others) and the relationships between them.

Because the entities involved are common to all the message formats:

• DDEX tries wherever possible to structure data about these common entities in the same way across all the standards; and

• DDEX uses precise terms and definitions for these different types of entities so that sender and receiver of the message know exactly what is being communicated.

For example, what DDEX calls a musical work, is frequently known in North America as a “song” whereas in the UK it is usually just referred to as a “work”. By formalising the term that is used to identify a “Work intended to be perceivable as a combination of sounds, with or without accompanying text” as a musical work means that a US organisation that holds that data in a field called “song” can communicate with a UK organisation that holds that data in a field called “work”, by using DDEX standards because, they both know what entity they are talking about.

All of these entities have multiple attributes that describe them. DDEX orders these attributes together in a common way in what DDEX calls “composites”. So, for example, the Party composites (party is the term used by DDEX to describe individuals or organisations) contains attributes such as PartyId, PartyName which itself can be broken down into attributes such as FullName or AbbreviatedName. These composites appear in exactly the same or similar form throughout the different DDEX standards. They act as common building blocks for any new message formats DDEX works on and allow implementers to use the same code when implementing a new standard from a previous implementation that uses the same composites.

DDEX separates three core elements of the music that is consumed. This is done partly because rights ownership in these different elements is usually with different types of companies, but also to ensure that clarity is provided to the DSPs ultimately making the music available about what exactly they can do with that music. As with other entities that are described within DDEX standards, DDEX uses precise terms which might not normally be those that are used in day to day parlance. Again, however this is to ensure precision in the communication of data, so that both the sender and receiver of messages knows exactly what is being communicated.

There are therefore three elements that DDEX describes when referring to the music that is made available to consumers, each with their own attributes.

• At the bottom of the hierarchy is a Work. This refers to an abstract creation of the mind whose existence is known through performances of that work or manifestations of that work in the form of objects. Very often, within DDEX standards the Work described will be a musical work.

• Next in the hierarchy is a Resource. A Resource is a fixation of an expression of an abstract work and generally within DDEX standards will be a sound recording or a music video.

• Finally, there is a Release which is a bundle of resources, including, potentially a “bundle” of one resource.

Not widely used within DDEX is the concept of a product. Products are instantiations of releases as they are made (or have been made) available to consumers. They have thus two components: the release that is being made available, and the terms and conditions under which the release is made available.

Most of DDEX’s standards are expressed in XML (eXtensible Markup Language) because it provides a common syntax for messaging systems for the exchange of information. It is also flexible, allowing for the expression of hierarchies and linking of data.

However, XML can become verbose because, for certain types of business transactions, it results in data being repeated extensively, making files unnecessarily large and cumbersome. This is particularly true for business transactions involving the communication of what is essentially tabular data. One such example is the reporting of sales and usage information. Where such data is being exchanged, the relevant DDEX standards are “structured flat files”.

This enables sales and usage reporting files to remain compact, whilst retaining the flexibility of XML for other communications.