- Created by DDEX Secretariat, last modified on 2020-05-18
This section of the DDEX Knowledge Base contains the Standard for Version 1.0.1 of the Communication of Media Enrichment and Description Information (MEAD).
Download Standard (PDF)
Tabular representation of the MEAD Standard (XLS)
Download XML Schema Definition Files (ZIP)
... for the Recording Data and Rights Choreography Standard (RDR-C, Version 1.0): Message Structure and AVSs
... for the US Letters of Direction Choreography Standard (LoD, Version 1.0): Message Structure and AVSs
... for the Electronic Release Notification Message Suite Standard (ERN, Version 4.2): Message Structure and AVSs
... for the Musical Work Right Share Notification Choreography Standard (MWN. Version 1.2): Message Structure and AVSs
... for the US Musical Work Licensing Choreography Standard (MWL, Version 1.0): Message Structure and AVSs
... for the Standard for the Communication of Media Enrichment and Description Information (MEAD): Message Structure and AVSs
... f or the Standard for communicating links between Resources and Musical Works (Version 1.1)
... for the Recording Data and Rights Standard (Version 1.4)
... for Release Deliveries using SFTP or Web Service (Version 1.7)
... for the Recording Information Notification (Version 1.1)
1 Introduction
To offer a rich user experience, especially for instance, to support voice-activated music discovery and playback, DSPs require rich information which would not normally appear in current ERN formatted messages even though some of it might be available at the record company. However, DSPs may also obtain such information from other sources, herein called Metadata Providers, and this standard defines the means by which a DSP can obtain such information as part of an ERN feed, a separate FTP-communicated message or via web services.
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 https://ddex.net/implementation/implementation-licence-and-ddex-party-identifiers.
2 Scope
This first version of the Media Enrichment and Description standard focuses on the communication of such information from record companies to Release Distributors in a "feed" accompanying the communication of Release notifications using the ERN standard as well as bulk metadata feeds from metadata provider.
Clause 6 then defines the choreographies for the Communication of Media Enrichment and Description Information before Clause 7 details the web service calls for such communications. Finally, Clause 8 provides the syntax of the messages defined in this standard.
##other
element at the end of the MeadMessage
. The XSD for Version 1.0 did not allow the use of an XSD for any additional tags that a Message Sender may wish to included into the message; this has now been corrected.
3 Normative References
- DDEX. DDEX Data Dictionary Standard. Latest Version
- DDEX. Electronic Release Notification Standard. Version 4 or later.
- IETF. RfC 2616. Hypertext Transfer Protocol (HTTP/1.1). 1999
- IETF. RfC 5023. The Atom Publishing Protocol. October 2007
- IETF. RfC 6797. HTTP Strict Transport Security (HSTS). November 2012
- IETF. RfC 2026. SSH File Transfer Protocol. October 2001
- W3C: XML Schema Part 1: Structures. Second Edition. 2004
- W3C: XML Schema Part 2: Data types. Second Edition. 2004
4 Terms and Definitions
Atom
Formally, the Atom Syndication Format, is an XML language used for web service feeds. The Atom Publishing Protocol is a simple HTTP-based protocol for creating and updating web resources.
Metadata Provider
A company that provides, usually on request, information about Works, Resources, Releases or Parties other than the information communicated in a NewReleaseMessage defined in the ERN Standard.
Examples include record companies as well as dedicated metadata service companies.
Product
A Manifestation of a Release (or another Resource) which is made available to Consumers, by sale, loan or other means. The attributes of a Release in its digital manifestation as a Product may be technical (e.g., the codec or bit rate); a mode of distribution (e.g., downloading or streaming); or a commercial term (e.g., price).
Release
A Release is an abstract entity representing a bundle of one or more Resources compiled by an Issuer. The Resources in Releases are normally primarily sound recordings or music audio-visual recordings, but this is not invariably the case. The Release is not itself the item of trade (or “Product”). Products have more extensive attributes than Releases; one Release may be disseminated in many different Products.
Release Creator
Release Creator is an organisation which is the owner of copyrights in sound and/or music audiovisual recordings and/or exclusive licensees of copyrights in sound and/or music audiovisual recordings.
Typical Release Creators are record companies.
Release Distributor
Release Distributor is an organisation, which is duly authorised by a Release Creator to offer Releases manifested in the form of Products to consumers. Release Distributors include Digital Service Providers (DSPs) and Mobile Service Providers (MSPs) as well as other organisations.
Typical Release Distributors are DSPs.
Web Service
A modern set of web technologies that allow small pieces of information, typically in the form of XML files, to be exchanged. Augmented with FTP (or other file exchange mechanisms) they can be used to communicate Releases along the music supply chain.
Web Service Call
The sending of an XML document to a port/address on a web server, using HTTP or HTTPS.
Web Service Response
The sending of an XML document in direct response to a Web Service Call, using HTTP or HTTPS.
For the avoidance of doubt: the appropriate response is always the message indicated in the appropriate Choreography.
5 Abbreviations
AMEP | Automated Message Exchange Protocol |
ACA | Appointed Certification Agency |
AVS | Allowed Value Set |
BP | Business Profile |
BWARM | Bulk Communication of Work and Recording Metadata |
CISAC | Confédération internationale des sociétés d'auteurs et compositeurs, the International Confederation of Societies of Authors and Composers (see cisac.org) |
CA | Certification Agency |
CT | Conformance Tester |
DAW | Digital Audio Workstation |
DDEX | Digital Data Exchange |
DSIG | Digital Signature |
DSP | Digital Service Provider (incudes Mobile Service Providers) |
DSR | Digital Sales Reporting |
ERN | Electronic Release Notification |
FTP | File Transfer Protocol (FTP specifically includes SFTP) |
GRid | Global Release Identifier |
HTTP | Hypertext Transport Protocol (HTTP specifically includes HTTPS) |
HTTPS | Secure Hypertext Transport Protocol |
IEC | International Electrotechnical Commission (see iec.ch) |
ISO | International Organisation for Standardisation (see iso.org) |
MEAD | Media Enrichment And Description |
MIME | Multipurpose Internet Mail Extensions |
MWL | Musical Works Licensing |
MWN | Musical Works Notification |
MRBV | Multi-Record-Block Variant |
PCA | Private Certification Agency |
Portable Document Format | |
REST | REpresentational State Transfer |
RIN | Recording Information Notification |
SFTP | Secure FTP |
SRBV | Single-Record-Block Variant |
TIS | Territory Information System (a CISAC Standard) |
TLS | Transport Layer Security |
UGC | User-generated content |
URL | Uniform Resource Locator |
XML | eXtensible Markup Language |
XSD | XML Schema Definition |
W3C | World Wide Web Consortium (see w3c.org) |
WS | Web Service |
6 Choreograophies
- The media enrichment and description information can be provided in a separate XML document, containing one or more
MeadMessages
formed in accordance with Clause 8 of this standard that is attached to aNewReleaseMessage
. This allows record companies who have information that goes beyond what can be communicated in the ERN message to communicate such information using the already-established mechanisms to exchange this information. - The
MeadMessage
can also be sent independently from aNewReleaseMessage
using SFTP – whether from a record company or a third party Metadata Provider; and - The media enrichment and description information can be exchanged using web services using a call-back architecture where a DSP would "subscribe" to a specific metadata feed using a web service call and the Metadata Provider would reply, once it has new information, with a web service call.
Details for these cases are defined in the following subclauses.
MeadMessage
in accordance with Clause 8 of this standard, can be sent alongside a NewReleaseMessage.
DDEX has not defined a mechanism by which a MeadMessage
can be communicated alongside an ERN-3 message (which does not have a SupplementalDocumentList
element). The preferred approach is to send the MeadMessage
as a Text Resource with a user-defined TextType
of MeadMessage
.
The XML document containing the MeadMessage
shall be treated in accordance with the relevant ERN Choreography as if it were a Resource file. It shall, however, be referenced in the SupplementalDocumentList
composite in the NewReleaseMessage
instead of in the TechnicalDetails
composite. Any document referenced in the MeadMessage
shall also be treated as if it were a Resource file to the NewReleaseMessage
.
The information in each of the the MeadMessages
shall only contain information relevant to the Releases, Resources, Works or Parties referenced in the NewReleaseMessage
to which the MeadMessage
is attached.
MeadRequestMessage
shall be named as MEAD_Identifier_YYYYMMDDhhmmssnnn.xml
withIdentifier
being the identifier used in theMeadMessage
to identify the entity that the message that provides additional information for (should theMeadMessage
contain more than one entity, the identifier shall be the one identifying the main entity as determined by the sender of theMeadMessage
); andYYYYMMDDhhmmssnnn
being the date and time that the Release is placed on the ftp server.
For example MEAD_0000000114819103_20190504102412000.xml
is a file containing auxiliary information sent on 4th May 2019 at 10:24:12.000 for the band Marillion (who have been allocated an ISNI of 0000 0001 1481 9103).
Any additional documents referenced from the MeadMessage
shall be placed into the same folder as the MeadMessage
. It must be uploaded to the FTP server before the MeadMessage
is uploaded.
The recipient of such a
MeadMessage
may acknowledge the receipt by placing a file containing an FtpAcknowledgementMessage
in the same folder as the acknowledged message. The FtpAcknowledgementMessage
shall be named as ACK_Identifier_YYYYMMDDhhmmssnnn.xml
with the same naming convention as above.
MeadMessages
, the Metadata Provider shall create a separate folder for each Batch. To ensure sequential processing, a Batch shall be named YYYYMMDDhhmmssnnn/
with YYYYMMDDhhmmssnnn
being the date and time that the set of MeadMessages
is placed on the SFTP server.
The maximum size of a Batch is not defined in this standard but shall be agreed by the Metadata Provider and the Release Distributor before using this Profile. It is not permitted to include information about the same entity more than once in a single Batch.
If the Metadata Provider wants to have several Batches “open” at the same time, it needs to ensure that no information about the same entity is contained in more than one Batch.
The maximum time a Batch may be kept “open” is a matter for the Metadata Provider and the Release Distributor to define in their commercial agreement.
The Metadata Provider shall make sure that the Batch folder name is unique for each Batch.
The trigger to indicate that a Batch is complete, a zero-byte semaphore file shall be placed into the Batch folder. The semaphore file shall be named BatchComplete_YYYYMMDDhhmmssnnn
.
Each file containing a MeadMessage
shall be placed into such a batch folder, following the same file naming convention as defined in Clause 6.3.1 of this Standard.
Any additional documents referenced from the MeadMessage
shall be placed into the same folder as the MeadMessage
. It must be uploaded to the SFTP server before the batch is closed.
The recipient of such a Batch may acknowledge the receipt of each MeadMessage
by placing a file containing an FtpAcknowledgementMessage
into a sub-folder acknowledgements/
which is placed into the same folder as the MeadMessage
. The FtpAcknowledgementMessage
shall be named following the same file name convention as defined in Clause 6.3.1 of this Standard.
MeadMessage
deliveries defined in this clause is symmetric. Metadata Providers and Release Distributors will need to publish and maintain a web service. The diagram below shows a typical exchange enabled by this choreography:
This clause defines the minimum that a web service provider needs to publish in order to be conformant with this standard. Additional services may be added on top of the features of the standard. For instance, the call to subscribe to a feed is defined herein to only apply to cases where the query leads to a single result. When a query leads to multiple results, the standard calls for an error to be returned – an extended service might offer the means to handle multiple results in an automated fashion.Not shown in the above diagram is the ability to unsubscribe to a service.
Also not specifically shown is the ability to access documents that are referenced from the MeadMessage
. However, the process is the same as depicted above.
While it can be assumed that many URLs follow a common syntax, there is no compulsion to use this approach. Similarly it is not compulsory that all URLs from one company follow a common syntax.
All the Metadata Provider and Release Contributor need to do, is to agree the URLs for the subscribe and unsubscribe calls as well as the metadata delivery calls.
Wherever this standard mentions only the HTTP protocol, it is to be understood that HTTPS communications are also allowed.
This can be done with or without formal authentication (see Clauses 6.4.4 and 6.4.5, respectively). The benefit of using formal authentication is that it also allows Metadata Providers and Release Distributors to secure their communication.
The provisions defined in Clauses 6.4.2, 6.4.3, 6.4.4 and 6.4.5 also apply to the Atom-based choreography with the exceptions that (i) Metadata Providers and Release Distributors need to agree the URLs for the subscribe and unsubscribe calls as well as the Atom request call, and (ii) that the Metadata Provider must make sure that the URLs placed in the responses to web service calls are (a) valid and (b) active.
Not shown in the above diagram is the ability to unsubscribe to a service.
Also not specifically shown is the ability to access documents that are referenced from the MeadMessage
. However, the process is the same as depicted above.
7 Web Service Commands
This command can be used by a Release Distributor to request information about MeadMessage
s that are ready for that particular Release Distributor to receive from a Metadata Provider.
The Release Distributor will call, after appropriate authentication if needed, the web service address previously agreed between the Metadata Provider and the Release Distributor.
7.1.2 Syntax of Reply
The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 200 (OK);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found);
- 503 (Service unavailable due to a temporary overloading or maintenance of the server); and
- 500 (Internal server error)
Other standard HTTP status codes may be used on bilateral agreement between the Release Creator and the Release Distributor.
The web server shall also return to the calling web service client an Atom Feed document as defined in Clause 8.1.
7.2.1 Purpose
This command can be used by a Release Distributor to unsubscribe from a feed that it has previously subscribed to. The syntax for this call is not prescribed .
Below are two possible approaches (with base.url
being the URL agreed between the Metadata Provider and the Release Distributor and xxx being the identifier for the subscription that the Metadata Provider returned as part of the subscription request).
base.url/path?unsubscribe=xxx
base.url/unsubscribe/xxx
7.2.2 Syntax of Reply
The web server shall return one of the following standard HTTP response codes with their standard HTTP response code semantics:
- 200 (OK);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found); and
- 500 (Internal server error); and
- 503 (Service unavailable due to a temporary overloading or maintenance of the server).
If the status code is 200, the Web server shall stop sending further updates for the item from which the Release Distributor has just unsubscribed.
Other standard HTTP status codes may be used on bilateral agreement between the Metadata Provider and the Release Distributor.
7.3.1 Purpose
This command can be used by a Metadata Provider to provide information on an item that a Release Distributor has subscribed to. The document to be posted is an MeadMessage
as defined as in Clause 8.
7.3.2 Syntax of Reply
The web server of theRelease Distributor shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 204 (The server successfully processed the request but is not returning any content);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found); and
- 500 (Internal server error); and
- 503 (Service unavailable due to a temporary overloading or maintenance of the server).
Other standard HTTP status codes may be used on bilateral agreementbetween the Metadata Provider and the Release Distributor.
7.41 Purpose
This command can be used by a Release Distributor to request information about metadata that is ready for that particular Release Distributor to receive from a Metadata Provider.
The Release Distributor will call, after appropriate authentication, if needed, the web service address previously agreed between the Metadata Provider and the Release Distributor.
7.4.2 Syntax of Reply
The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 200 (OK);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found);
- 500 (Internal server error); and
- 503 (Service unavailable due to a temporary overloading or maintenance of the server).
If the status is 200, the web server shall also return to the calling web service client an Atom feed document as defined in Clause 8.
Other standard HTTP status codes may be used on bilateral agreement between the Metadata Provider and the Release Distributor.
This command can be used by a Release Distributor to request an MeadMessage
. The web service address for this call is the URL for the specific instance of the requested MeadMessage
.
The Release Distributor would typically have received this URL from an entry
composite in an Atom feed
document.
7.5.2 Syntax of Reply
The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 200 (OK);
- 301 (Moved permanently);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found);
- 500 (Internal server error); and
- 503 (Service unavailable due to a temporary overloading or maintenance of the server).
Other standard HTTP status codes may be used on bilateral agreement between the Metadata Provider and the Release Distributor.
If the status code is 200, the web server shall also return to the calling web service client an XML file containing a valid MeadMessage
as defined in Clause 8.
If the status code is 301, the web server shall also return to the calling web service client the correct URL.
7.6.1 Purpose
This command can be used by a Release Distributor to signal to the Metadata Provider, that the Release Distributor has ingested, but not necessarily processed a specific metadata item, including all referenced documents.
It therefore signals to the Metadata Provider, that the Release Distributor no longer needs to receive web service calls with respect to the said metadata item from the Metadata Provider. After receiving this call, a Metadata Provider is free to remove the associated entry from its Atom feed
.
If, after removing the item from the queue and removing the associated entry from its Atom feed, the Metadata Provider is updating the information about the item again, the metadata should – subject to its bilateral agreement with the Release Distributor – create a new Atom feed/entry for the same entity.
The syntax for this call is not prescribed except.
7.6.2 Syntax of Reply
The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 204 (The server successfully processed the request but is not returning any content);
- 208 (Already reported);
- 400 (Bad Request) – which in this case means that the URL does not lead to a valid metadata message (any more);
- 401 (Unauthorised);
- 404 (Not found);
- 500 (Internal server error); and
- 503 (Service unavailable due to a temporary overloading or maintenance of the server).
Other standard HTTP status codes may be used on bilateral agreement between the Metadata Provider and the Release Distributor.
This command can be used by a Release Distributor to request a supporting document that has been referenced in an MeadMessage
. The web service address for this call is the URL for the specific instance of the requested document as provided in the MeadMessage
.
7.7.2 Syntax of Reply
The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:
- 200 (OK);
- 301 (Moved permanently);
- 400 (Bad request);
- 401 (Unauthorised);
- 404 (Not found);
- 500 (Internal server error); and
- 503 (Service unavailable due to a temporary overloading or maintenance of the server).
Other standard HTTP status codes may be used on bilateral agreement between the Metadata Provider and the Release Distributor.
If the status code is 200, the web server shall also return to the calling web service client the supporting document.
If the status code is 301, the web server shall also return to the calling web service client the correct URL.
8 Syntax of XML Messages
8.1.1 Introduction
The Atom feeds shall have follow the syntax as defined in the relevant XML Schema Definition file.
The following Atom feed entry
elements have these meanings:
Atom Feed entry Element | NewReleaseMessage Element |
---|---|
//entry/title | The
|
//entry/SubscriptionId | The identifier for the subscription as provided, by the Metadata Provider to the Release Distributor during the subscription process |
//entry/Work /* | Information about the main entity for which information is provided. Only one of these elements can be provided in on //entry . |
//entry/Release /* | |
//entry/Resource /* | |
//entry/Party /* |
8.1.2 Feed Links
Entries should be entered into the feed sequentially, that is the oldest entry should be at the top and the latest addition should be at the bottom. A Metadata Provider may, however, add and remove entries at its own discretion.
The number of entry composites in the Atom feed is not prescribed by this standard. The Metadata Provider publishing the web service may, however, want to set a maximum number in collaboration with its business partner(s).
The following link types can be communicated in the //feed/link/@rel
attributes:
self
– to provide the URL of the feed itself;next
– to provide the URL to the next feed "page" (in the case where there is more than one feed page available to the Release Distributor); andprevious
– to provide the URL to the previous feed "page" (in the case where there is more than one feed page available to the Release Distributor).
8.1.3 Feed Entry Links
The following link types can be communicated in the //feed/entry/link/@rel
attributes:
alternate
– to provide the URL for theGET MeadMessage
method defined in Clause 7.5; anddelete
– to provide the URL for theDELETE MeadMessage
method defined in Clause 7.6.
MeadMessage
shall have follow the syntax as defined in the relevant XML Schema Definition file.
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:
- The suitability or fitness of the standards for any particular purpose;
- The merchantability of the standards;
- The accuracy, completeness, relevance or validity of the standards; or
- 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.