The PIE standard enables record companies, distributors or metadata companies to communicate non-core metadata to DSPs so that they can offer a rich user experience, for example, to support voice-activated music discovery and playback. The metadata that can be communication includes a significant range of information, but includes such items as:
Information about “focus tracks”, which is crucial for voice-activated services, for example:
When a consumer asks for, “the latest George-Ezra track” this may well be different from Ezra’s most recently released track;Journalistic material;
Information about artist nicknames;
Information about historic chart positions;
Awards won by am artist; or
Information of interest to aficionados of classical music.
You can access the current PIE specification in version 1.1 here.
PIE supports more than thirty different mechanisms for the description of parties, releases, resources such as sound recordings, and musical works. This type of descriptive information is therefore for music discovery or marketing and different from the “core” information about releases and resources communicated using ERN.
PIE and MEAD are very similar standards. They both provide “rich” metadata that is intended to enable DSPs to offer better user experiences to their customers. The difference between these two standards is that while MEAD focuses on creations (musical works, resources and releases), PIE focuses on parties (writers, recording artists, engineers, publishers and labels).
The PIE standard in version 1.1 supports information about parties (such as writers, recording artists and studio personnel).
The table below lists, in alphabetical order, the types of information that the PIE standard currently supports. The table represents the current extent of what PIE can express. We expect this to expand significantly over the years,
Type of information
Focus track for a specific musician
Historic charting information
Period/epoch in which a party was active or when music was created
Similar or related items or parties
Vocal register of an artist
Currently, PIE is a messaging standard to be exchanged between companies with the relevant data and DSPs. We envisage that PIE will eventually be extended to work as a query API. Such an API will allow a DSP to call a record company's, distributor's or metadata provider’s web service to request a specific piece of information. The reply to such a request should only contain a response to the request and not any other previously sent information. The response would not therefore update or retract any other information.
The standard also enables the communication of information about the source of any of the data. For example, a record company might include in their PIE feed a review of an album written by a reputable journalist. Providing the name of this journalist aids recipients of the data in assessing the reliability of the received information.
The messages defined by all DDEX standards are stateless. That is, they provide “statements of truth”, which means that 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 PIE.
However, MEAD and PIE differ from the other DDEX message standards in that it not intended to always provide a full picture. MEAD and PIE can be used by to send information just to describe, say, a sound recording. Recipients of MEAD and PIE messages may then take the various pieces of information received from multiple metadata providers about the same entity to create the data set it wants to use to describe that entity on its service.
However, it is possible that such metadata will change or require updating over time. Therefore, a message sender may need to correct or update some of the information it has sent out in the past. As a result the following rules apply when sending changed or updated information:
Approach using a MEAD/PIE message
A message sender previously sent information describing fact X and now wishes to sent information describing fact Y.
MEAD and PIE messages state information describing facts XY.
A message sender previously sent information describing fact XY and now wants to withdraw information describing fact Y.
MEAD and PIE messages state information describing fact X (the absence of information describing fact Y indicates it is no longer valid as far as the message sender is concerned).
A message sender previously sent information describing three genres for a resource and now wants to withdraw one of them.
MEAD and PIE messages state information describing the two genres that remain valid (omitting the third).
A message sender previously sent information describing genre X and now wants to withdraw that and state Y now.
MEAD and PIE messages state states information describing Y genre only.
The same approach can be used to completely withdraw any information previously communicated, in a MEAD or PIE message, about a specific party or creation. In that case the message sender shall send a new MEAD or PIE message with only a:
ResourceSummarycomposite where the subject of the MEAD message is a Resource;
ReleaseSummarycomposite where the subject of the MEAD message is a Release;
WorkSummarycomposite where the subject of the MEAD message is a Work; or
PartySummarycomposite where the subject of the PIE message is a Party.
This approach has many advantages. However, in the context of MEAD and PIE, a standard whereby multiple sources may provide data to a single recipient about the same entity, it also has a few drawbacks. These include:
Message senders need to know what information they have provided in the past to all of their recipients, and always re-send previously sent information; and
Message recipients need to know what information was sent by whom, to enable them to disregard data only once it has been withdrawn by all metadata providers that have provided information of that kind in the first place.