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, 

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: 

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:

• ResourceSummary composite where the subject of the MEAD message is a Resource;

• ReleaseSummary composite where the subject of the MEAD message is a Release;

• WorkSummary composite where the subject of the MEAD message is a Work; or

• PartySummary composite 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.