The messages defined by all DDEX standards are stateless; they provide “statements of truth”, i.e. the latest message always contains a complete view of the situation as known by the message sender at that moment it time. This also applies to MEAD.

However, MEAD differs from the other DDEX message standards in that it not intended to always provide a full picture – MEAD can be used by a metadata provider to send just one aspect to describe a, say, sound recording. Recipients of MEAD messages may then take the various aspects received from multiple metadata providers to create the data set it wants to use to describe the musical products and musicians in their service.

Such metadata will change over time. And a metadata provider may need to correct or update some of the information it has sent out in the past: 

The same approach can be used to completely disown any information previously communicated, in a MeadMessage, about a specific party or creation. In that case the metadata provider shall send a new MeadMessage with only a 


This approach has many advantages, which is why DDEX has adopted it across its messaging standards. However, in the context of MEAD – a standard through which multiple sources may provide data to a single recipient – it also has a few drawbacks:

MEAD as an API

Today MEAD is a messaging standard, i.e. metadata providers can send MEAD messages to their business partners. DDEX envisages, however, that MEAD will eventually be extended to also work as a query API. 

This API will allow a company to call a metadata provider’s web service to request a specific piece of information (e.g. the historic charting information for a specific artist). The reply to such a request should not contain any other previously sent information – and therefore it would not be able to update or retract any other information.