DDEX envisages two “modes” for MEAD. The first mode is where media enrichment and description information is sent as part of an ERN feed from a record company to a DSP (potentially, as with all DDEX standards, via aggregators or technical service companies). Labels would be able to send, for example, focus track information to DSPs that support voice-activated services or devices.

The second mode is where such media enrichment and description information is sent from a “metadata provider” to a DSP independently of an ERN feed. A DSP would subscribe to a metadata feed and would receive such information once new data becomes available. Such metadata providers can include record labels (although the label-internal data sources for MEAD may be different from the one used for an ERN feed) as well as companies that specialise in the aggregation of enriched data about parties, releases, resources and works not normally included in supply chain activities.

If media enrichment and description information is communicated alongside an ERN message, the MEAD message is sent like a resource that accompanies the ERN message. This approach works with ERN-3 as well as ERN-4. Therefore, neither the sender nor the recipients will need to update their message exchange process. There is, of course, code to be written for creating and ingesting the MEAD message itself.

Where media enrichment and description information is communicated independently from an ERN feed, the process depicted below is envisaged. This process can be implemented using (S)FTP or a web services API similar to the one used today to communicate ERN messages and their resource files.

The forthcoming MEAD standard supports information about musical works, recordings (primarily sound recordings), releases as well as parties such as writers, recording artists and studio personnel. 

The table below lists, in alphabetical order, the types of information that the draft version of the MEAD Standard currently contains, and who the likely sources of such information are. In addition, the standard will allow the communication of the name of the author of any of the pieces of information. A label might, for instance, include in their MEAD feed a review of an album written by a reputable journalist. The name of this journalist might then aid recipients of the media enrichment and description information to assess the reliability of the received information.

This list represents the current extent of what MEAD can express. DDEX expects this to expand significantly over the years:

It is essential to note that no company is expected to send or receive all types of media enrichment and description information. Instead, the standard provides a flexible “menu” approach were only those items that a party wishes to send (or receive) are actually communicated.

MEAD is based, like most DDEX standards, on an XML Schema Definition (XSD) that will seamlessly integrate with all other DDEX standards as all DDEX standards are based on a common data dictionary. Implementers of the ERN standard will therefore find it very easy to implement the new standard.

 As indicated above, MEAD is intended to be used in two modes: media enrichment and description information can be sent either as an accompaniment to an ERN message or independently of an ERN message. In the latter case, the organisation that wishes to receive media enrichment and description information will need to let the metadata provider know what information it seeks. This is done by means of a query which serves, effectively, as a subscription to a metadata feed about the entity (or entities) that match(es) the query. 

A DSP might, for example, ask a metadata provider about historic chart positions for John Lennon’s works. The metadata provider would then reply, until the DSP unsubscribes, with all charting information about John Lennon it knows of. And if it learns of a previously unknown chart entry, it would forward that information to all subscribers. DDEX has developed two approaches to allow DSPs – or other companies – to query metadata providers:

• The first method is an XML-based query message that can be sent via FTP or web services to a metadata provider;
• The second method is using web services. DDEX has defined a simple, yet powerful, URL syntax to convey the important query parameters:

The above example could be expressed by calling the following URL:

http://base.domain/path?API=1.0&
        QueryTarget=Work&
        RequestedInformation=HistoricChartingInformation&
        ISNI=0000000121174585

This can be read as “I am using the MEAD API in version 1.0; please provide me charting information for all works by the person with ISNI 0000 0001 2117 4585” (i.e. John Lennon).

The MEAD specification has been developed by DDEX’s ERN Working Group for a number of months now. However, before DDEX can publish MEAD as a standard that can be implemented and used by members and non-members alike, it needs to be evaluated and tested so that DDEX can be sure that the specification meets the requirements and that, ideally, all bugs have been removed. 

Once this process has been completed, MEAD is excepted to be published, as a “DDEX Standard”, in the course of 2019.