MEAD messages as a statement of truth

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: 

  • A metadata provider may have stated a fact X in the past and now also wants to state Y. This can be handled by a MEAD message stating XY.

  • Another metadata provider may have stated XY in the past, but wants to “disown” Y now. This can be handled by a MEAD message stating just X (the absence of Y indicates that Y is no longer claimed.

  • This also works for the case where the metadata provider claimed, for example, three genres for a sound recording and now wants retract one of them. This can be handled by sending a MEAD message with the two remaining genres (and omitting the third).

  • A metadata provider may have, say, a genre X in the past and wants to state a genre Y instead.  This can be handled by a MEAD message stating just the genre of Y instead of X. 

  • A metadata provider may have communicated a genre in the past and now wants to disown all genre information. This can be handled by completely omitting the GenreCategory tag. 

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 

  • ResourceSummary composite in case that the subject of the MeadMessage is a resource;

  • ReleaseSummary composite in case that the subject of the MeadMessage is a release;

  • WorkSummary composite in case that the subject of the MeadMessage is a work; or

  • PartySummary composite in case that the subject of the MeadMessage is a party.

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:

  • Metadata providers need to know what information they have provided in the past to all of their recipients, and always re-send previously sent information; and

  • Metadata recipients need to know what information was sent by whom, to enable them to disregard data, only once it has been disowned by all metadata providers that have provided the data in the first place.

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.

Search