You are viewing an old version of this page. View the current version.
This Profile of version 3.0 of the Flat File Variant has been developed in response to concerns regarding the file size and computational complexity of the XML Variant, and will lead to reduced implementation and running cost for Licensees and Licensors for user-generated content where the Message Sender either has, or has not, received a claim for a sound recording from the owner of that sound recording (the “master” Recording).
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 on https://ddex.net/implementation/implementation-licence-and-ddex-party-identifiers.
Finally Annexes A provides some examples.
Version 1.1 of the UGC Profile provides a series of minor updates to some record types and replaces the use of SY03 with SY04 and SY05.
Version 1.1.1 of the UGC Profile corrects a bug in the LI01 record.
Version 1.2 of the UGC Profile makes use of updated SY04, SY05, AS01, AS02, MW01, SU03 and LI01 records that support additional business requirements.
3 Normative References
The following normative documents contain provisions, which through reference in this text constitute provisions of this standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest version applies.
- DDEX. Digital Sales Reporting Message Suite Standard - Part 1: Architecture of the Flat File Variant.
- DDEX. Digital Sales Reporting Message Suite Standard - Part 2: Allowed Value Sets.
- DDEX. Digital Sales Reporting Message Suite Standard - Part 8: Record Type Definitions.
4 Terms and Abbreviations
The terms and abbreviations used in Digital Sales Reporting Message Suite Standard – Part 1: Architecture of the Flat File Variant. also apply to this Standard.
5 UGC profile
To indicate that a Sales/Usage Report is created in accordance with this Profile standard, the Profile Cell in the
HEAD Record shall contain the value
UGCProfile and the ProfileVersion Cell shall contain the value 1.2.
The following Records shall be communicated for each Block in this order:
- One Resource Record of type
AS02.02describing the Resource including basic information of the underlying Work (the Work part of this data shall be included as provided by the record company to the Licensee).
The Message Sender may wish to split the information into multiple Records instead of using one
- The first Record, of type
.01, contains information regarding the Sound Recordings, Videos and other “master” Resources that have been used in creating the user-generated content that has been accessed;
- The following none, one or more Musical Work Record(s), of type
MW01.01contain information about the Musical Work(s) utilised as provided by the record company to the Licensee. If the Resource contains more than one Work, the Work shall be communicated in multiple Blocks so that only one Work is reported in a Block).
- The first Record, of type
- None, one or more UGC Release Usage Records of type
RU01.01describing the use of UGC Releases.
Instead of a
RU01.01record, the Message Sender may use one
RU02.01Record for each UGC Release and its use.
It is not permissible to communicate
RU02.01Records in one Block.
The Block shall contain multiple
RUxxRecords for each
ASxxRecord in that one
RU01.01Record shall be provided for each ContentCategory (for a maximum of 100 Releases); one
RU02.01Record shall be provided for each UGC Release.
- None, one or more Intra-Block Groupings of Records providing
- One UGC Sales/Usage Record of type
SU03.02Record followed by
- None, one or more Licensor-specific Usage Data Record of type
LI01.02providing Licensor-specific information for the usages reported in the preceding
- Each of the
LI01.02records followed by none or one
MW01.01Record to indicate Licensor-specific Work information. These Records shall contain the Work information provided to the DSP by the RightsContoller referenced in the preceding
- One UGC Sales/Usage Record of type
The Blocks shall be preceded by one or more Summary Records
SY05.02 or SY09 for each type of use, commercial model and territory any Release contained in the Sales Report Message has been traded under. In cases where a Message Sender provides information at RightsController level, the fields at RightsController level in
LI01.02 records can be provided.
SY04.01 Records for the same RightsType and sales context (as defined in Clause 6.5 of Part 1 of this standard) may carry the same
SummaryRecordId if per-subscriber minima information needs communicating per context, but across different subscriber types. Each
SY04.01 records shall be followed by 1-n groupings of 1
SY09 Record, followed by 1-n
It is recommended to provide the Summary Records in a logical order to aid human readability. This would typically mean that Summary Records of different types are not mixed. For example a sequence of
SY04.01 meets this recommendation, whereas
SY02.02 does not.
Figure 1 shows two ways in which this Profile can be implemented. The left-hand diagram shows the case where Musical Work information is provided as part of the Resource Record (
AS02.02) and only a usage summary Record is
RU01.01 is provided and the right-hand diagram shows the case where Musical Work information is provided on an extra
MW01.01 Record and usage information is provided in multiple
RU02.01 Records. For the avoidance of doubt, it is also possible to use
AS02 Records together with
RU02.01 Records as well as
Figure 1 – One Block of Records when Reporting UGC-related Usages, Revenues or Sales
The table below provides an overview of the order and cardinality of the Records to be used in this Profile.
A combination of the four Summary record types is allowed:
May only follow an
This record will point to an RUxx Record for the relevant ContentCategory as well as the
This/these instance of
For cases where the Message Sender has not received a claim for a sound recording from its owner, the
record shall be virtually empty, only containing a RecordType and a BlockId.
Annex A (informative) Examples
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.