The messages will allow such standardised information flow about the Works themselves (i.e. Release metadata) as well as information about who owns and controls what shares of such Musical Works.

The messages defined herein also allow the works licensor to convey and express a licence for the share is owns or controls for use in the context of user-generated content sites; they do not convey any other licence for the Musical Work, either in total of in part, or any other Creation embodied in a musical product.

Clause 5 then provides a non-technical overview of the messages while Clause 6 defines the choreography for the messages defined in this standard. Clause 7 provides an example for a rights share chain that can be communicated with this standard, Finally, Clause 8 provide an overview of the messages as well as the normative definition of the messages defined herein.

Annex A then lists the allowed values to be used with this standard.

Collecting Publisher

A RightsController who is, at the time of assertion, controlling the right to collect royalties for a specific RightsType in a specific Territory for a specific Musical Work. Collecting Publishers may ask Administrators to administer some of their rights. Note that a MusicalWork may have zero, one or many Collecting publishers.

Distribution Share

The proportion of the overall Musical Work that has been assigned to a Collecting Publisher or Administrator.  Note that a Writer can have zero, one or many Original Publishers, and hence zero, one or many Distribution Shares.

Manuscript Share

The  proportion of a Musical Work written by a Writer, as agreed between the Writers.  Typically represented as a percentage or a fraction.  Manuscript Shares may occasionally vary by territory and/or rights type.

Musical Work

A Work intended to be perceivable as a combination of sounds, with or without accompanying text.

Any words that are intended to be expressed with a MusicalWork (often termed Lyrics) form part of that MusicalWork; not all MusicalWorks have Lyrics.
A MusicalWork may be expressed and fixed to become part of a SoundRecording or a Video Recording, or may be used to create notated music (sheet music, scores, instrumental parts) or sound generation codes (such as MIDI files).
In some cases, the MusicalWork comes into existence simultaneously with its expression. This is common in extemporised forms such as jazz music.

Original Publisher

Original Publisher Share

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.

Resource

A digital fixation of an expression of an abstract Work (such as a sound recording, a video, an image, software or a passage of text). Resources are individual assets that make up a Release. Typical Resources are sound recordings, video clips and cover art images.

Right Share

A percentage or fraction of a right for a Musical Work for a particular time and place in which a party claims a controlling interest. Note: controlling interest includes ownership and/or administration.

Rights Controller

A Party who owns and/or controls rights in a Musical Work or other Creation.

Creations include Musical Works, Sound Recordings and other Resources as well as Releases. Rights Controllers are, in the context of a licence agreement, often referred to as Licensors.

Note: In many cases a RightsController is also the Licensor.

Rights Type

The type of right covered by a RightShare as defined by relevant law. Rights Types vary between territories. Typical rights types include mechanical rights, performing rights and synchronisation rights.

Writer

A creative creator of the musical or lyrical elements of a Musical Work. Writers include Adapters, Arrangers, Authors, Composers. ComposerLyricists, Librettists, Lyricists, NonLyricAuthors and Translators.

WriterShare

See Manuscript Share.

http://ddex.net/xml/mwn/10

All messages developed within DDEX are based upon a common set of elements and their definitions. These are contained in the DDEX Data Dictionary available from ddex.net.

The full namespace for the XML Schema document for the allowed-value sets is

http://ddex.net/xml/avs/avs

DDEX may regularly extend this list of allowed-value sets. Any such extensions to this list are issued on a date later than the date on which this Standard is issued form part of this Standard. Thus the list of allowed-value sets provided Annex A contains the list of allowed-value sets valid on the data of issuance of this Standard.

• YYYY being the year of Batch creation;
• MM being the month of Batch creation;
• DD being the day of Batch creation;
• hh being the hour of Batch creation;
• mm being the minute of Batch creation;
• ss being the second of Batch creation; and
• nnn being the millisecond of Batch creation.

• MMMM being the name (root tag) of the Message; and
• SSSSS being a zero padded serial number within that batch.

Its syntax is defined in Clause 8.3 and shown below.

Figure 1 – Manifest Message

• MMMM being the name (root tag) of the Message acknowledged; and
• SSSSS being a zero padded serial number of the Message acknowledged within that batch.

The Acknowledgement shall be placed into the same folder as all other files. Its syntax is defined in Clause 8.3 and shown below.

Figure 2 – Ftp Acknowledgement Message

Figure 3 – Choreography of the Musical Work Notification Message Suite and Choreography Standard

The table below summarises the point in the Release cycle when each message is sent. The table also indicates who sends which message to whom and which of the messages are defined in this Standard. Note the table does not show the list manifests and acknowledgements.

Table 1: Triggers in the Musical Work Notification Message Suite and Choreography Standard

• Manuscript shares (also known as writer shares);
• Original publisher shares; and
• Distribution shares

It may be possible that an original publisher has obtained rights from more that one writer. Therefore, the percentage of the share obtained from each writer must be communicable. The following diagram provides an example for such data.

It should be noted, that the percentages provided in such fields is with respect to the entire Work. For instance if a Publisher obtains 50% from a publisher who, itself, controls 20% or the Work, the data to be communicated has to be be 10% (i.e. 50% of 20%) and not 50%.

Figure 14 – Sample of a RightShare Chain

The Standard defines three messages (plus a manifest and acknowledgement message not discussed here):

• MusicalWorkNotificationMessage, a message sent by a Musical Works Licensor to a DSP, to inform the DSP of its rights claims and how the user-generated content policies that the Licensor imposes on the DSP with respect to the Musical Work(s) mentioned in the message;
• MusicalWorkConflictNotificationMessage, a message sent by a DSP to those Works Licensors that have furnished the DSP with conflicting claims, typically sent using a MusicalWorkNotificationMessage, for the same Musical Work; and
• MusicalWorkClaimRequestMessage, a message sent by a DSP who wants to use or monetise a Release for which it does not know any or all rights holders. Such a message could be sent as a “broadcast” to all Musical Work Licensors the DSP has a commercial relationship with.

The diagrams below provide an (incomplete) overview of their content.

Figure 5 – MusicalWorkClaimNotificationMessage

Figure 6 - MusicalWorkClaimConflictNotificationMessage

Figure 7 - MusicalWorkClaimRequestMessage

Figure 8 – MessageHeader

Figure 9 - PartyList

Figure 10 – WorkList

Figure 11 - ResourceList

Figure 12 – ReleaseList

Figure 13 – RightShareList

Figure 14 – Condition

The full message structure for each of the message defined herein is provided in the next clause in tabular form. The hierarchical structure of the messages is provided through indentation. On the Message Header for example, the PartyName is a child of Sender. Thus, a Sender contains a PartyName (plus a PartyId). A second example from the MessageHeader is the MessageAuditTrail that contains MessageAuditTrailEvents which, in turn, contains a MessagingPartyDescriptor and a DateTime element. All elements that have subelements are printed in bold. The MessageAuditTrailEvents element also shows a second structural feature of the Message Summary: the cardinality. In the case of MessageAuditTrailEvents the entry "1-n" means that each MessageAuditTrail contains one or more MessageAuditTrailEvents.

Other possible cardinality entries are: "1" (for: exactly one), "0-1" (for none or one) or "0-n" (for none to multiple). Elements shown in italics are represented in the XML Schema as XML Attributes. In several places within the messages, the Message Sender may need to make a choice between using two or more XML elements. These instances are marked in the tabular representation of the messages below with the keyword XmlChoice. This keyword is not part of the messages; instead exactly one of the “branches” below the XmlChoice keyword has to be used.

In addition to the tabular description of the message, which should always be read in conjunction with the XML Schema files, additional conformance rules, which go beyond XML Schema validation, are provided where necessary. The general conformance rules for all messages within this Standard are provided in Clause 6.2.

Specific business processes between sender and recipient may require even further conformance rules. These are, however, not part of the Standard and will need to be agreed between business partners. Rules relating to the authority of business partners to unilaterally change the Message Standard in this way are set out in the current version of the Procedures for the Development and Maintenance of DDEX Standards which forms part of the overall governance of the DDEX Standards.

The syntax as well as the semantics of the various elements in the messages is provided in this Clause. They are taken from the current version of the DDEX Data Dictionary as defined through, and maintained in accordance with, the DDEX Data Dictionary Standard.

Note that one XML Attribute, LanguageAndScriptCode, is only shown on the top-level (message) composites. This attribute is, in fact, present on all composites or elements that might benefit from being coded in different languages and/0r scripts. If placed on a composite, its value applies to all sub-elements (and, potentially, overrides a different LanguageAndScriptCode “further up”. If placed on an element its value applies only to that element. The LanguageAndScriptCode is provided in accordance with IETF RfC 5646.