common metadata ‘md’ namespace - movielabs...common metadata draft ref: tr-meta-cm version: 2.8...
TRANSCRIPT
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. i
Common Metadata ‘md’ namespace
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. ii
CONTENTS 1 Introduction .............................................................................................................. 1
1.1 Overview of Common Metadata ....................................................................... 1 1.2 Document Organization .................................................................................... 2 1.3 Document Notation and Conventions ............................................................... 2
1.3.1 XML Conventions ...................................................................................... 3 1.3.2 General Notes ........................................................................................... 4
1.4 Normative References ...................................................................................... 4 1.5 Informative References..................................................................................... 8 1.6 Best Practices for Maximum Compatibility ...................................................... 10 1.7 Case Sensitivity .............................................................................................. 11
2 Identifiers ............................................................................................................... 12 2.1 Identifier Structure .......................................................................................... 12
2.1.1 ID Simple Types ...................................................................................... 13 2.1.2 EIDR Types ............................................................................................. 13
2.2 Asset Identifiers .............................................................................................. 14 2.2.1 ContentID ................................................................................................ 14 2.2.2 APID ........................................................................................................ 16
2.3 Organization ID ............................................................................................... 17 3 General Types Encoding ....................................................................................... 18
3.1 Language Encoding ........................................................................................ 18 3.2 Region encoding ............................................................................................. 18 3.3 Date and Time encoding ................................................................................. 19
3.3.1 Duration ................................................................................................... 19 3.3.2 Time ........................................................................................................ 19 3.3.3 Dates and times ...................................................................................... 19 3.3.4 Date and time ranges .............................................................................. 20
3.4 String encoding ............................................................................................... 20 3.5 Organization Naming and Credits ................................................................... 20
3.5.1 CompanyDisplayCredit-type .................................................................... 21 3.5.2 AssociatedOrg-type ................................................................................. 21
3.6 People Naming and Identification ................................................................... 22 3.6.1 PersonName-type.................................................................................... 22 3.6.2 PersonIdentifier-type ............................................................................... 23
3.7 Money-type and Currency .............................................................................. 23 3.8 Role Encoding, Role-type ............................................................................... 23 3.9 Keywords Encoding ........................................................................................ 24
3.9.1 Name/Value Pairs, NVPair-type, NVPairMoney-type .............................. 24 3.10 Personal/Corporate Contact Information, ContactInfo-type ............................ 24 3.11 Cryptographic Hash ........................................................................................ 25 3.12 GroupingEntity-type ........................................................................................ 25 3.13 Private Data .................................................................................................... 26 3.14 MIME .............................................................................................................. 26
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. iii
3.15 Workflow Attribute Group ................................................................................ 26 3.16 Gender-type .................................................................................................... 27 3.17 Compliance-type ............................................................................................. 28 3.18 Terms-type ..................................................................................................... 29 3.19 Compatibility ................................................................................................... 31
4 Basic Metadata ...................................................................................................... 32 4.1 BasicMetadata-type ........................................................................................ 32
4.1.1 Basic Metadata Definitions ...................................................................... 34 4.1.2 BasicMetadataInfo-type ........................................................................... 40 4.1.3 ContentIdentifier-type, AltIdentifier-type .................................................. 44 4.1.4 BasicMetadataPeople-type ...................................................................... 45
4.2 Compilation Object ......................................................................................... 50 4.2.1 CompObj-type ......................................................................................... 50 4.2.2 CompObjID-type ...................................................................................... 50 4.2.3 CompObjData-type .................................................................................. 50 4.2.4 Comp-ObjEntry-type ................................................................................ 51
4.3 Content Related To ........................................................................................ 52 4.3.1 ContentRelatedTo-type ........................................................................... 52 4.3.2 ContentRelatedToRelationship-type ........................................................ 54 4.3.3 ContentRelatedToWork-type ................................................................... 55 4.3.4 ContentRelatedToCharacter-type ............................................................ 56 4.3.5 ContentRelatedToPerson-type ................................................................ 56 4.3.6 ContentRelatedToPeriod-type ................................................................. 57 4.3.7 ContentRelatedToEvent-type .................................................................. 57
5 Digital Asset Metadata ........................................................................................... 58 5.1 Digital Asset Metadata Description ................................................................. 58 5.2 Definitions ....................................................................................................... 58
5.2.1 DigitalAssetMetadata-type and DigitalAssetSet-type............................... 58 5.2.2 DigitalAssetAudioData-type ..................................................................... 59 5.2.3 DigitalAssetAudioEncoding-type ............................................................. 61 5.2.4 DigitalAssetVideoData-type ..................................................................... 67 5.2.5 DigitalAssetVideoEncoding-type ............................................................. 69 5.2.6 DigitalAssetVideoPicture-type ................................................................. 74 5.2.7 DigitalAssetSubtitleData-type .................................................................. 86 5.2.8 DigitalAssetImageData-type .................................................................... 90 5.2.9 DigitalAssetInteractiveData-type ............................................................. 91 5.2.10 DigitalAssetWatermark-type .................................................................... 94 5.2.11 Cards ....................................................................................................... 95 5.2.12 DigitalAssetAncillary-type ........................................................................ 97
6 Container Metadata ............................................................................................. 100 6.1 Container Metadata Description ................................................................... 100 6.2 Definitions ..................................................................................................... 100
6.2.1 ContainerMetadata-type ........................................................................ 100 6.2.2 ContainerProfile-type ............................................................................. 103
7 Content Ratings ................................................................................................... 104
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. iv
7.1 Description .................................................................................................... 104 7.2 Rules ............................................................................................................ 104 7.3 Definition ....................................................................................................... 104
7.3.1 ContentRating-type................................................................................ 104 7.3.2 ContentRatingDetail-type ...................................................................... 105
8 Content Rating Encoding ..................................................................................... 107 9 Selected Examples .............................................................................................. 108
9.1 People Name Examples ............................................................................... 108 9.2 Release History Example ............................................................................. 112 9.3 Content Rating Examples ............................................................................. 113
10 Redefine Support ................................................................................................. 115 10.1 General XML Type Redefines ...................................................................... 115 10.2 Type-specific Redefines ............................................................................... 115
10.2.1 Identifiers ............................................................................................... 115 10.2.2 Basic Metadata ...................................................................................... 116 10.2.3 Digital Asset Metadata ........................................................................... 117 10.2.4 Content Ratings ..................................................................................... 121 10.2.5 Container Metadata ............................................................................... 121 10.2.6 Compilation Object ................................................................................ 121 10.2.7 Additional Types .................................................................................... 121 10.2.8 Release History ..................................................................................... 122
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
NOTE: No effort is being made by the Motion Picture Laboratories to in any way obligate any
market participant to adhere to Common Metadata. Whether to adopt the Common Metadata in
whole or in part is left entirely to the individual discretion of individual market participants,
using their own independent business judgment. Moreover, Motion Picture Laboratories
disclaims any warranty or representation as to the suitability of the Common Metadata for any
purpose, and any liability for any damages or other harm you may incur as a result of subscribing
to this Common Metadata.
http://creativecommons.org/licenses/by/3.0/http://creativecommons.org/licenses/by/3.0/
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. v
REVISION HISTORY
See www.movielabs.com/md/md/history.html for detailed revision information.
Version Date Description
1.0 January 5, 2010 Original Version
1.1 January 6, 2011 Incorporates corrections.
1.2 November 1, 2011 Incorporates corrections and enhancements, primarily to support derived specifications.
1.2a-1.2e May 29, 2012, September 24, 2012, October 11, 2012
Minor schema alignment (no schema changes), EIDR IDs, additions to controlled vocabularies, Ratings improvements, and minor corrections and additions.
1.2f December 16, 2012 Moved Section 8 Content Ratings Encoding to a separate document: TR-META-CR, Common Metadata Content Ratings, www.movielabs.com/md/ratings
2.0 January 3, 2013 Major revision
2.0a January 7, 2013 Minor corrections to 2.0.AF
2.1 June 30, 2013 Minor revision with schema changes
2.1a-c January 4, 2013 Minor text corrections. References added to new Common Metadata Ratings to avoid duplication. Addition of VP9 codec. Note: no schema changes.
2.2 October 2, 2014 Added color authoring/encoding. Added video enhancement layer enumeration. Added codecs.
2.3 February 9, 2015 Minor corrections, new enumerations, etc. Added Ancillary track type to Digital Asset Metadata Added HDR metadata Added UHDImage flag in subtitle Entry in Compilation made optional
2.3a March 24, 2015 Added VBR and BitRateAverage to video encoding (has been in schema since v2.0)
http://www.movielabs.com/md/md/history.htmlhttp://www.movielabs.com/md/ratings
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. vi
2.3b June 3, 2015 Added WhitePointChromaticity to spec (was correct in schema). Added ‘App’ and ‘Gallery’ enumerations for WorkType Clarified enumerations of SDRDownConversion Clarified ‘cardset’ language. Added DTS:X codec.
2.3c July 1, 2015 Corrected cardinality on Image Language and Cardset Description.
2.4 October 13, 2015 This release adds a variety of small features to support specific Cross-Platform Extras and Media Manifest Core use cases.
2.5 December 16, 2016 Support for Immersive video including VARM (Virtual, Augmented and Mixed Reality) and 360 Video Improved image and interactive Digital Asset data Numerous changes to support supply chain use cases.
2.6 December 11, 2017 Added EIDR-URN ID scheme Added Atmos to codecs Added Scope and @subscope to ContentIdentifier-type Added Workflow-attr attribute group Added Drop Frame indication in subtitles Clarified ChannelMapping Added ‘AVOD’ and ‘PVOD’ release types Changed cardinality of Summary190 to 0..1 (optional) Added @condition to LocalizedInfo to supported windowed metadata. Changed TitleSort and Summary190 to optional Support UN M49 codes in Region/countryRegion Added Loudness to audio encoding Added information about video before encoding (cadence). Added to Audio support for SMPTE S 377-4 MCA Audio Content Kind and MCA Audio Element Kind
2.7 November 1, 2018 Basic Metadata
• Improved WorkType values to cover other media and non-
media objects that can be described using Common
Metadata, and to better support Cards
• Improved ReleaseType to include ‘Festival’ to capture
production date.
• Changed cardinality of CountryOfOrigin to 0..n to
accommodate titles with multiple countries of origin.
Provided improved definitions of CountryOfOrigin.
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. vii
• Clarified LocalizedInfo/@Region usage
• Improved People object to include better character
structure, top billing, and improved gender encoding
• Improved content relationships to better support season
reordering, related content (e.g., based on book),
franchise/brand/universe, and content grouping.
• Changed cardinality of WorkTypeDetail from 0..1 to 0..n
Digital Asset Metadata
• Added Compliance-type and Compliance elements to each
track definition.
• Improved Video to include BitDepth, dynamic metadata
(e.g., DV, HDR10+ and SD-HDR1), additional encoding
vocabulary, and color mastering vocabulary
• Improved timed text to include a default for
Video/SubtitelLanguage/@closed as ‘false’ (i.e. open
captions), and ‘noforced’ (timed text without forced
narrative)
• Added Health notice as a Card Type.
2.8 General
• Added Compatibility for improved validation
• Added Terms-type (same as avails:Terms-type) so it can be
used in Manifest, Delivery, etc.
• Added EIDRURN-type. Used in Delivery, and possibly
elsewhere.
Basic Metadata
• Added to LocalizedInfo: Audience and Audience/@window
• Added ‘md’ as an identifier scheme for use in
ContentIdentifier-type
• Added ReleaseType ‘FOD’ and ‘local’
• Mentioned MESA Language Metadata Table (LMT) in
Language Encoding
• Added note that PrimarySpokenLanguage could be a sign
language.
• Added WorkType values for ‘printed’ works (books, comics,
etc.)
• Expanded Related-to structure (content related to…)
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. viii
Digital Asset Metadata
• Added @value to Rating Reason.
• Added ProRes 4444 XQ and ProRes 4444 codecs
• Removed duplicate “ITT” timed text type
• Added “IAB” codec for SMPTE ST 2098-2 Immersive Audio
Bitstream
• Added “Silent” audio Type
• Added container types
• Aded singalong subtitle Type
• Added instructions for URI encoding of Genre @id
• Added SubType to video, subtitle and image. Increased
cardinality to 0..n in audio.
• Changed xs:integer Inventory terms that cannot be zero to
xs:nonNegativeInteger
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 1
1 INTRODUCTION
The B2B transfer of media requires metadata to describe that media. Several activities
underway at the time of this document’s authoring have metadata needs that overlap. This
document in conjunction with associated XML schemas defines the content and one possible
encoding of such data.
Common Metadata is part of the MovieLabs Digital Distribution Framework (MDDF) as
shown in the following illustration:
Studio Mastering
Distribution Entity
StudioDistribution
PlatformFulfillment
Business Terms(Avails, Title List)
Product Definition
Metadata (MEC, MMC)
Asset Availability
Mezz
Platform Business
Sales/Usage Reporting
Sales
Fulfillment
InteractivityPreprocessing
Cross-Platform Extras (CPE) Player
Consumer Experience
Offer Status
Asset Order
Media
MDDF
Media
Product Status/QC
Additional information on MDDF can be found at www.movielabs.com/md
This is designed as a resource. Those using this specification may extend the definition
with additional data element specific for their needs. They may replace elements with others
perhaps more suitable to their needs; however, for interoperability all are highly encouraged to
use the data elements exactly as defined.
1.1 Overview of Common Metadata
Common Metadata includes elements that cover typical definitions of media, particularly
movies and television. Common Metadata has two parts: Basic Metadata and Digital Asset
Metadata. Basic Metadata includes descriptions such as title and artists. It describes information
about the work independent of encoding. Digital Asset metadata describes information about
individual encoded audio, video and subtitle streams, and other media included. Package and
File Metadata describes one possible packaging scenario and ties in other metadata types.
Ratings and Parental Control information is described.
Common Metadata is designed to provide definitions to be inserted into other metadata
systems. A given metadata scheme, for example, the Entertainment Merchant’s Association
(EMA) may select element of the Common Metadata to be used within its definitions. EMA
would then define additional metadata to cover areas not included in Common Metadata.
http://www.movielabs.com/md
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 2
1.2 Document Organization
This document is organized as follows:
1. Introduction—Provides background, scope and conventions
2. Identifiers—Specification of identifiers used to reference metadata.
3. General Types Encoding—Specific of encoding methods (e.g., language, region).
4. Basic Metadata—Content descriptive metadata definition
5. Digital Asset Metadata—Encoded media metadata definition
6. Container Metadata – Metadata describing media containers
7. Content Rating—Methods for encoding content ratings
8. Content Rating Encoding—Content Ratings can now be found in Common Metadata Content Ratings at www.movielabs.com/md/ratings.
9. Examples
10. Redefine Support – Information on using schema features to tightly control vocabulary
1.3 Document Notation and Conventions
As a general guideline, the key words “MUST”, “MUST NOT”, “REQUIRED”,
“SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”,
and “OPTIONAL” in this document are to be interpreted as described in [RFC2119]. That is:
• “MUST”, “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.
• “MUST NOT” or “SHALL NOT” means that the definition is an absolute prohibition of the specification.
• “SHOULD” or “RECOMMENDED” mean that there may be valid reasons to ignore a particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
• “SHOULD NOT” or “NOT RECOMMENDED” mean that there may be valid reasons when the particular behavior is acceptable, but the full implications
should be understood and the case carefully weighed before implementing any
behavior described with this label.
• “MAY” or “OPTIONAL” mean the item is truly optional, however a preferred implementation may be specified for OPTIONAL features to improve
interoperability.
Terms defined to have a specific meaning within this specification will be capitalized,
e.g. “Track”, and should be interpreted with their general meaning if not capitalized.
http://www.movielabs.com/md/ratings
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 3
Normative key words are written in all caps, e.g. “SHALL”.
Normative requirements need not use the formal language above.
1.3.1 XML Conventions
XML is used extensively in this document to describe data. It does not necessarily imply
that actual data exchanged will be in XML. For example, JSON may be used equivalently.
This document uses tables to define XML structure. These tables may combine multiple
elements and attributes in a single table. Although this does not align with schema structure, it is
much more readable and hence easier to review and to implement.
Although the tables are less exact than XSD, the tables should not conflict with the
schema. Such contradictions should be noted as errors and corrected.
1.3.1.1 Naming Conventions
This section describes naming conventions for Common Metadata XML attributes,
element and other named entities. The conventions are as follows:
• Names use initial caps, as in InitialCaps.
• Elements begin with a capital letter, as in InitialCapitalElement.
• Attributes begin with a lowercase letter, as in initiaLowercaseAttribute.
• XML structures are formatted as Courier New, such as md:id-type
• Names of both simple and complex types are followed with “-type”
1.3.1.2 Structure of Element Table
Each section begins with an information introduction. For example, “The Bin Element
describes the unique case information assigned to the notice.”
This is followed by a table with the following structure.
The headings are
• Element—the name of the element.
• Attribute—the name of the attribute
• Definition—a descriptive definition. The definition may define conditions of usage or other constraints.
• Value—the format of the attribute or element. Value may be an XML type (e.g., “string”) or a reference to another element description (e.g., “See Bar Element”).
Annotations for limits or enumerations may be included (e.g.,” int [0..100]” to
indicate an XML xs:int type with an accepted range from 1 to 100 inclusively)
• Card—cardinality of the element. If blank, then it is 1. Other typical values are 0..1 (optional), 1..n and 0..n.
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 4
The first row of the table after the header is the element being defined. This is
immediately followed by attributes of this element, if any. Subsequent rows are child elements
and their attributes. All child elements (i.e., those that are direct descendants) are included in the
table. Simple child elements may be fully defined here (e.g., “Title”, “ ”, “Title of work”, “xs:string”), or described fully elsewhere (“POC”, “ ”, “Person to contact in case there is a problem”, “md:ContactInfo-type”). In this example, if POC was to be defined by a complex type defined as md:ContactInfo-type. Attributes immediately follow the containing element.
Accompanying the table is as much normative explanation as appropriate to fully define
the element, and potentially examples for clarity. Examples and other informative descriptive
text may follow. XML examples are included toward the end of the document and the
referenced web sites.
1.3.2 General Notes
All required elements and attributes must be included.
When enumerations are provided in the form ‘enumeration’, the quotation marks (‘’)
should not be included.
UTF-8 [RFC3629] encoding shall be used when ISO/IEC 10646 (Universal Character
Set) encoding is required.
1.4 Normative References
[TR-META-CR] Common Metadata Content Ratings. www.movielabs.com/md/ratings. Note
that a specific version is not referenced as it is intended that the latest version will be
used. Referencing specifications may selection a specific version of the referenced
document.
[TR-META-RS] Common Metadata Ratings Schema Definition, TR-META-RS, January 3,
2014, http://www.movielabs.com/md/ratings/doc.html
[ACES] Academy Color Encoding Specification (ACES), Specification S-2008-001, August 5,
2011. http://www.oscars.org/science-technology/council/projects/aces.html
[AES-TD1004] “Recommendation for Loudness of Audio Streaming and Network File
Playback”, Audio Engineering Society, AES TD1004.1.15-10,
http://www.aes.org/technical/documents/AESTD1004_1_15_10.pdf
[ANSI-Z39.56] ANIS/NISO Standard Z39.56, “Seriial Item and Contribution Identifier (SICI)”,
Version 2, ISSN-1041-5653, 1996
[ARIB-TRB32] “Operational Guidelines for Loudness of Digital Television Systems, Technical
Report TR-B32”, Association of Radio Industries and Businesses (ARIB),
https://www.arib.or.jp/english/std_tr/broadcasting/desc/tr-b32.html
[Atmos-Render] “Dolby Atmos Renderer Guide, Software Version 3”, August 2, 2018,
https://www.dolby.com/us/en/professional/content-creation/dolby-atmos/dolby-atmos-
http://www.movielabs.com/md/ratingshttp://www.movielabs.com/md/ratings/doc.htmlhttp://www.oscars.org/science-technology/council/projects/aces.htmlhttp://www.aes.org/technical/documents/AESTD1004_1_15_10.pdfhttps://www.arib.or.jp/english/std_tr/broadcasting/desc/tr-b32.htmlhttps://www.dolby.com/us/en/professional/content-creation/dolby-atmos/dolby-atmos-renderer-guide.pdf
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 5
renderer-guide.pdf[AES-TD1004] “Recommendation for Loudness of Audio Streaming
and Network File Playback”, Audio Engineering Society, AES TD1004.1.15-10,
[ATSC-A85] “ATSC Recommended Practice: Techniques for Establishing and Maintaining
Audio Loudness for Digital Television (A/85:2013)”, Advanced Television Systems
Committee, https://www.atsc.org/wp-content/uploads/2015/03/Techniques-for-
establishing-and-maintaining-audio-loudness.pdf
[AU-OP59] “FreeTV Australia, Operational Practice OP-59, Measurement and Management of
Loudness in Soundtracks for Television Broadcasting”, FreeTV Australia,
http://www.freetv.com.au/media/Engineering/OP59_Measurement_and_management_of
_Loudness_in_Soundtracks_for_Television_Broadcasting_-_Issue_1_-_July_2010.pdf
[CALM] 111th Congress, HR 1084, “Commercial Advertisement Loudness Mitigation Act”,
https://www.congress.gov/111/bills/hr1084/BILLS-111hr1084rfs.pdf
[CEA861.3] CEA Standard, HDR Static Metadata Extensions, CEA-861.3, January 2015
[CIE15] “CIE Colorimetry Technical Report 15:2004 (3rd edition)”, International Commission
on Illumination, 2004.
[CIE1931] “Proceedings of the 8th Session of CIE,” 19-29, 1931. Cambridge: Cambridge
University Press.
[CFFTT] Common File Format & Media Formats Specification version 2.2, Section 2.2, and
related schema, http://www.uvcentral.com/specs
[EBU-R128] EBU Recommendation 128, “Loudness Normalisation and Permitted Maximum
Level of Audio Signals”, European Broadcast Union. https://tech.ebu.ch/docs/r/r128.pdf
[EIDR-TOTD] EIDR Technical Overview, November 2010.Documentation,. [RFC2141] R.
Moats, RFC 2141, URN Syntax, May 1997, http://www.ietf.org/rfc/rfc2141.txt
https://eidr.org/technical-documentation
[EIDR-UG] EIDR Registry User’s Guide, January 4, 2017.
http://eidr.org/documents/EIDR_2.1_Registry_User_Guide.pdf,
https://eidr.org/technical-documentation
[ETSI-SL-HDR1] ETSI TS 103 433-1, “High-Performance Single Layer High Dynamic Range
(HDR) System for use in Consumer Electronics devices; Part 1: Directly Standard
Dynamic Range (SDR) Compatible HDR System (SL-HDR1)”, 2017-08
[ETSI-SL-HDR2] ETSI TS 103 433-2, “"Enhancements for Perceptual Quantization (PQ)
transfer function based High Dynamic Range (HDR) Systems (SL-HDR2)”, 2017-08
[RFC2046] Freed, N, N. Borenstein, RFC 2046, Multipurpose Internet Mail Extensions.
(MIME) Part Two: Media Types, November, 1996, https://tools.ietf.org/html/rfc2046.
[RFC3629] Yergeau, F., et al, RFC 3629, UTF-8, a transformation format of ISO 10646,
November, 2003. http://www.ietf.org/rfc/rfc3629.txt
https://www.dolby.com/us/en/professional/content-creation/dolby-atmos/dolby-atmos-renderer-guide.pdfhttps://www.atsc.org/wp-content/uploads/2015/03/Techniques-for-establishing-and-maintaining-audio-loudness.pdfhttps://www.atsc.org/wp-content/uploads/2015/03/Techniques-for-establishing-and-maintaining-audio-loudness.pdfhttp://www.freetv.com.au/media/Engineering/OP59_Measurement_and_management_of_Loudness_in_Soundtracks_for_Television_Broadcasting_-_Issue_1_-_July_2010.pdfhttp://www.freetv.com.au/media/Engineering/OP59_Measurement_and_management_of_Loudness_in_Soundtracks_for_Television_Broadcasting_-_Issue_1_-_July_2010.pdfhttps://www.congress.gov/111/bills/hr1084/BILLS-111hr1084rfs.pdfhttp://www.uvcentral.com/specshttps://tech.ebu.ch/docs/r/r128.pdfhttp://www.ietf.org/rfc/rfc2141.txthttps://eidr.org/technical-documentationhttp://eidr.org/documents/EIDR_2.1_Registry_User_Guide.pdfhttps://eidr.org/technical-documentationhttps://tools.ietf.org/html/rfc2046http://www.ietf.org/rfc/rfc3629.txt
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 6
[RFC3986] Berners-Lee, T., et al, RFC 3986, Uniform Resource Identifier (URI): Generic
Syntax, January 2005, http://www.ietf.org/rfc/rfc3986.txt
[RFC5646] Philips, A, et al, RFC 5646, Tags for Identifying Languages, IETF, September, 2009.
http://www.ietf.org/rfc/rfc5646.txt
[RFC7302], Lemieux, P., RFC 7972, Entertainment Identifier Registry (EIDR) URN Namespace
Definition, IETF, September 2016, https://tools.ietf.org/html/rfc7972
[IEC61966-2-4] IEC 61966-2-4:2006, Multimedia systems and equipment - Colour measurement
and management - Part 2-4: Colour management - Extended-gamut YCC colour space
for video applications – xvYCC, 2006
[IANA-LANG] IANA Language Subtag Registry. http://www.iana.org/assignments/language-
subtag-registry
[IANA-MIME] IANA Media Types Registry. http://www.iana.org/assignments/media-types.
[IMSC1] TTML Profiles for Internet Media Subtitles and Captions 1.0 (IMSC1), W3C
Recommendation 21 April 2016, https://www.w3.org/TR/ttml-imsc1/
[ITT] iTunes Timed Text from iTunes Packaged Film Specification.
[ITU-BT.601] ITU-R Recommendation, “BT.601 : Studio encoding parameters of digital
television for standard 4:3 and wide screen 16:9 aspect ratios”, International
Telecommunications Union.
[ITU-BT.709] ITU-R Recommendation, “BT.709 : Parameter values for the HDTV standards for
production and international programme exchange”, International Telecommunications
Union.
[ITU-BS.1770-3] ITU-R Recommendation, “Algorithms to measure audio programme loudness
and true-peak audio level”, International Telecommunications Union
[ITU-BT.1886] ITU-R Recommendation, “BT.1886 : Reference electro-optical transfer function
for flat panel displays used in HDTV studio production”, International
Telecommunications Union.
[ITU-BT.2020] ITU-R Recommendation, “BT.2020 : Parameter values for ultra-high definition
television systems for production and international programme exchange”, International
Telecommunications Union.
[ITU-BT.2100] ITU-R Recommendation, “BT.2100 : Image parameter values for high dynamic
range television for use in production and international programme exchange”,
International Telecommunications Union.
[ISO3166-1] Codes for the representation of names of countries and their subdivisions -- Part 1:
Country codes, 2007.
[ISO3166-2] ISO 3166-2:2007Codes for the representation of names of countries and their
subdivisions -- Part 2: Country subdivision code
[ISO4217] Currency shall be encoded using ISO 4217 Alphabetic Code.
http://www.iso.org/iso/home/standards/currency_codes.htm
http://www.ietf.org/rfc/rfc3986.txthttp://www.ietf.org/rfc/rfc5646.txthttps://tools.ietf.org/html/rfc7972http://www.iana.org/assignments/language-subtag-registryhttp://www.iana.org/assignments/language-subtag-registryhttp://www.iana.org/assignments/media-typeshttps://www.w3.org/TR/ttml-imsc1/
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 7
[ISO8601] ISO 8601:2000 Second Edition, Representation of dates and times, second edition,
2000-12-15.
[ISO13818-2] ISO/IEC 13818-2:2000, Information technology -- Generic coding of moving
pictures and associated audio information: Video, 1999-10-31.
[ISO14496-10] ISO/IEC 14496-10: 2012, Information technology — Coding of audio-visual
objects — Part 10: Advanced Video Coding, Seventh Edition, 2012-05-01.
[ISO26324] ISO26324:2012, Information and documentation -- Digital object identifier system.
[M49] Standard Country or Area Codes for Statistical Use (M49), United Nations Statistics
Division, https://unstats.un.org/unsd/iiss/Standard-Country-or-Area-Codes-for-Statistical-
Use-M49.ashx
[47CFR9.103(c)(9)] “Closed caption decoder requirements for all apparatus.”, Title 47, part
71.103(c)(9) 2012, 47 CFR 79.103(c)(9), http://ecfr.gpoaccess.gov/cgi/t/text/text-
idx?c=ecfr&sid=53ad878c54cd79758c7fa602e4bc8975&rgn=div8&view=text&node=47
:4.0.1.1.6.0.3.8&idno=47. See also, Federal Register 77:62 (30 March 2012) p. 19480.
http://www.gpo.gov/fdsys/pkg/FR-2012-03-30/pdf/2012-7247.pdf
[RFC2046] Freed, N, N. Borenstein, RFC 2046, Multipurpose Internet Mail Extensions. (MIME)
Part Two: Media Types, November, 1996, https://tools.ietf.org/html/rfc2046.
[RFC2141] R. Moats, RFC 2141, URN Syntax, May 1997, http://www.ietf.org/rfc/rfc2141.txt
[RFC3629] Yergeau, F., et al, RFC 3629, UTF-8, a transformation format of ISO 10646,
November, 2003. http://www.ietf.org/rfc/rfc3629.txt
[RFC3986] Berners-Lee, T., et al, RFC 3986, Uniform Resource Identifier (URI): Generic
Syntax, January 2005, http://www.ietf.org/rfc/rfc3986.txt
[RFC5646] Philips, A, et al, RFC 5646, Tags for Identifying Languages, IETF, September, 2009.
http://www.ietf.org/rfc/rfc5646.txt
[RFC7972], Lemieux, P., RFC 7972, Entertainment Identifier Registry (EIDR) URN Namespace
Definition, IETF, September 2016, https://tools.ietf.org/html/rfc7972
[SMPTE-377-4] SMPTE ST 377-4:2012, “MXF Multichannel Audio Labeling Framework”,
2012.
[SMPTE-428-1] SMPTE ST 428-1:2006, “D-Cinema Distribution Master —Image
Characteristics”, 2006.
[SMPTE-428-3] SMPTE ST 428-3:2006, “D-Cinema Distribution Master Audio Channel
Mapping and Channel Labeling”, 2006.
[SMPTE-431-2] SMPTE RP 431-3:2006, “D-Cinema Quality—Reference Projector and
Environment”, 2006.
[SMPTE-2019] SMPTE ST 2019-1:2014, “VC-3 Picture Compression and Data Stream Format”,
2014
[SMPTE-2042] SMPTE ST 2042 series, “VC-2 Video Compression”, 2012-2017
https://unstats.un.org/unsd/iiss/Standard-Country-or-Area-Codes-for-Statistical-Use-M49.ashxhttps://unstats.un.org/unsd/iiss/Standard-Country-or-Area-Codes-for-Statistical-Use-M49.ashxhttp://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=53ad878c54cd79758c7fa602e4bc8975&rgn=div8&view=text&node=47:4.0.1.1.6.0.3.8&idno=47http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=53ad878c54cd79758c7fa602e4bc8975&rgn=div8&view=text&node=47:4.0.1.1.6.0.3.8&idno=47http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&sid=53ad878c54cd79758c7fa602e4bc8975&rgn=div8&view=text&node=47:4.0.1.1.6.0.3.8&idno=47http://www.gpo.gov/fdsys/pkg/FR-2012-03-30/pdf/2012-7247.pdfhttps://tools.ietf.org/html/rfc2046http://www.ietf.org/rfc/rfc2141.txthttp://www.ietf.org/rfc/rfc3629.txthttp://www.ietf.org/rfc/rfc3986.txthttp://www.ietf.org/rfc/rfc5646.txthttps://tools.ietf.org/html/rfc7972
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 8
[SMPTE-2054] SMPTE RP 2054:2010, “Method of Measurement of Perceived Loudness of
Short Duration Motion Picture Audio Material”, 2010.
[SMPTE-2067] SMPTE OV 2067-0:2017, “Interoperable Master Format — Overview for the
SMPTE 2067 Document Suite”, 2017
[SMPTE-2073] SMPTE ST 2073 series, “VC-5 Video Essence”, 2014-2016.
[SMPTE-2084] SMPTE ST 2084:2014, “High Dynamic Range Electro-Optical Transfer
Function of Mastering Reference Displays”, 2014
[SMPTE-2085] SMPTE ST 2085:2015, “Y′D′ZD′X Color-Difference Computations for High
Dynamic Range X′Y′Z′ Signals”, 2015
[SMPTE-2086] SMPTE ST 2086:2018, “Mastering Display Color Volume Metadata Supporting
High Luminance and Wide Color Gamut Images.”
[SMPTE-2094-1] SMPTE ST 2094-1:2016, “Dynamic Metadata for Color Volume Transform –
Core Components”, 2016
[SMPTE-2094-10] SMPTE ST 2094-1:2016, “Dynamic Metadata for Color Volume Transform
– Application #1”, 2016
[SMPTE-2094-20] SMPTE ST 2094-1:2016, “Dynamic Metadata for Color Volume Transform
– Application #2”, 2016
[SMPTE-2094-30] SMPTE ST 2094-1:2016, “Dynamic Metadata for Color Volume Transform
– Application #3”, 2016
[SMPTE-2094-40] SMPTE ST 2094-1:2016, “Dynamic Metadata for Color Volume Transform
– Application #4”, 2016
[SMPTE-2098-2] SMPTE ST 2098-2:2018, “Immersive Audio Bitstream Specification”, 2018
[TASA] “Recommendation from TASA Ad Hoc Committee for regulating motion picture trailer
volume (updated 2013)”, http://tasatrailers.org/TASAStandard-Changed-April-2016.pdf
[TTML] W3C Timed Text Markup Language (TTML) 1.0, W3C Recommendation 18
November 2010. http://www.w3.org/TR/ttaf1-dfxp/
[XML] “XML Schema Part 1: Structures”, Henry S. Thompson, David Beech, Murray Maloney,
Noah Mendelsohn, W3C Recommendation 28 October 2004,
http://www.w3.org/TR/xmlschema-1/ and “XML Schema Part 2: Datatypes”, Paul Biron
and Ashok Malhotra, W3C Recommendation 28 October 2004,
http://www.w3.org/TR/xmlschema-2/
1.5 Informative References
[MEC] Media Entertainment Core, TR-META-MEC, http://www.movielabs.com/md/mec/
[Manifest] Common Media Manifest Metadata, TR-META-MMM,
http://www.movielabs.com/md/manifest
[MMC] Media Manifest Core, TR-META-MMC, www.movielabs.com/md/mmc
http://tasatrailers.org/TASAStandard-Changed-April-2016.pdfhttp://www.w3.org/TR/ttaf1-dfxp/http://www.w3.org/TR/xmlschema-1/http://www.movielabs.com/md/mec/http://www.movielabs.com/md/manifesthttp://www.movielabs.com/md/mmc
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 9
[Avails] EMA Content Availability Metadata (Avails and Title List), TR-META-AVAIL,
www.movielabs.com/md/avails
[Delivery] Asset Ordering and Delivery, Asset Ordering, Delivery and Tracking,TR-META-
AOD, www.movielabs.com/md/delivery
[MDC] Media Delivery Core, TR-META-MDC, www.movielabs.com/md/mdc
[EIDR] Entertainment Identifier Registry (EIDR), http://eidr.org/resources/
European Broadcast Union, Tech 3295 – P_META Metadata Library,
https://tech.ebu.ch/MetadataSpecifications
[CEN15744] CEN BS EN 15907:2010, “Film identification. Enhancing interoperability of
metadata. Element sets and structures”, 2010
[LMT] MESA Language Metadata Table (LMT), https://www.mesalliance.org/language-
metadata-table
[RFC4647] Philips, A., et al, RFC 4647, Matching of Language Tags, September 2006.
http://www.ietf.org/rfc/rfc4647.txt
[RFC6381] Singer, D; et al, The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types,
August 2011, http://tools.ietf.org/html/rfc6381.
[ISO23009-1] ISO/IEC 23009-1: 2012, Information technology — Dynamic adaptive streaming
over HTTP (DASH) —Part 1:Media presentation description andsegment formats, First
Edition, 2012-04-01.
[CMM] Common Media Manifest Metadata, TR-META-MMM,
[MEC] Media Entertainment Core, TR-META-MEC, ,
[EIDR] Entertainment Identifier Registry (EIDR), http://eidr.org/resources/
European Broadcast Union, Tech 3295 – P_META Metadata Library,
https://tech.ebu.ch/MetadataSpecifications
[CEN15744] CEN BS EN 15907:2010, “Film identification. Enhancing interoperability of
metadata. Element sets and structures”, 2010
[OFCOM-GN12-2] Ofcom, Guidance Notes, “Issue Twelve, Section 2: Harm and offense”, July
18, 2017
[ITU-BT.1702] ITU-R Recommendation, “BT.1702 : Guidance for the reduction of
photosensitive epileptic seizures caused by television”, International Telecommunications
Union
The following metadata standards activities have numerous associated specifications.
Rather than listing each specification, sites where specifications can be found are listed.
• AMPAS – Academy of Motion Picture Arts and Sciences http://www.oscars.org/science-technology/council/projects/index.html
• SMPTE Metadata Dictionary: http://www.smpte-ra.org/mdd/
http://www.movielabs.com/md/availshttp://www.movielabs.com/md/deliveryhttp://eidr.org/resources/https://tech.ebu.ch/MetadataSpecificationshttps://www.mesalliance.org/language-metadata-tablehttps://www.mesalliance.org/language-metadata-tablehttp://www.ietf.org/rfc/rfc4647.txthttp://tools.ietf.org/html/rfc6381http://eidr.org/resources/https://tech.ebu.ch/MetadataSpecificationshttp://www.oscars.org/science-technology/council/projects/index.htmlhttp://www.smpte-ra.org/mdd/
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 10
• MPEG – Motion Pictures Experts Group http://mpeg.chiariglione.org/
• MHP – DVB Multimedia Home Platform http://www.mhp.org
• CableLabs VOD Metadata 3.0 http://www.cablelabs.com/wp-content/uploads/specdocs/MD-SP-CONTENTv3.0-I01-100812.pdfl
• Dublin Core Metadata Initiative: http://dublincore.org/.
• TV Anytime (ETSI) http://www.tv-anytime.org/
• PBCore: www.pbcore.org
• Vocabulary Mapping Framework: http://www.doi.org/VMF/
1.6 Best Practices for Maximum Compatibility
Metadata typically evolves with the addition of new elements, attributes and
vocabularies. Existing applications should be capable of accepting metadata, even though there
might be more data than expected. Strict XML validation precludes an orderly evolution and can
be counterproductive to the flexibility needed in real implementations.
Metadata specifications and schema updates are designed to support backwards
compatibility. For example, element and attributes can be added, but required elements are not
removed; or more generally ordinality of elements and attributes can be widened but not
narrowed. Values are not changed in either syntax or semantics. Therefore, we strongly
encourage implementations to either be diligent in tracking to the latest version, or follow the
backwards compatibility rules provided here.
An XML document is considered compatible if its structure does not preclude the
extraction of data from the document. For example, a document with additional elements and
attributes do not preclude schema parsing and data extraction.
• Do not reject compatible XML documents, unless they fail schema validation against the definition for an exact version/namespace match.
• Extract data from compatible XML documents whenever possible
• It it allowable to ignore elements and attributes whose presence is not allowed in the specification and schema versions against which the implementation was built. For
example, if the original schema allows one instance and three instances are found,
the 2nd and 3rd instance may be ignored.
We will try to update metadata definitions such that following these rules work
consistently over time. Sometimes, changes must be made that are not always backwards
compatible, so we will do our best to note these.
Also, use the Compatibility information (Section 3.19) to ensure proper validation is
performed.
http://mpeg.chiariglione.org/http://www.mhp.org/http://www.cablelabs.com/specifications/md20.htmlhttp://www.cablelabs.com/specifications/md20.htmlhttp://dublincore.org/http://www.tv-anytime.org/http://www.pbcore.org/http://www.doi.org/VMF/
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 11
1.7 Case Sensitivity
All XML element and attribute names are case sensitive, as required by XML. For
example, is the required form, so will result in
a fatal XML validation error.
All controlled vocabulary defined by this specification must be encoded exactly as
written in the spec (i.e., case as specified). The Validator will reject incorrect case. When
decoding, we suggest accepting any case—it’s not work rejecting a file for a missed
capitalization—and report the mistake to the encoding party.
Terms defined elsewhere must be encoded in accordance with their definition, unless
otherwise noted. That is, if the external specification defines a term as case-sensitive, then its
usage must be case sensitive; and if defined as non-case sensitive, any case is acceptable. If
referenced specifications provide no guidance, we suggest encoding terms exactly as written in
those specs. When decoding, if case is not consequential, we suggest accepting any case, and
report the mistake to the encoding party
These rules comply are an application of Postel’s Law (Robustness Principle) which
states, “Be conservative in what you do, be liberal in what you accept from others”.
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 12
2 IDENTIFIERS
Identifiers and metadata are closely linked. In essence, all identifiers have corresponding
metadata that describes the object being identified. Just as it is useful to distinguish between
different kinds of objects with different kinds of identifiers, it is useful to distinguish the
metadata in terms of those same objects.
The primary objects being identified and described in metadata are:
• Content – Content ID (ContentID)
• Encoded Stream – Physical Asset (Asset Physical ID; APID)
2.1 Identifier Structure
The primary requirement for identifiers is globally uniqueness. Individual systems using
Common Metadata are free to use own identifiers as long as there is no identifier collision.
The following represents a structure for identifiers that should be used if specific usage
does not specify otherwise. This structure is designed around the following principles
• Global uniqueness
• Coexistence of identifier schemes (ID Federation)
• Ability to use identifiers within a URL
Common Metadata identifiers use the general structure of the “urn:” URI scheme as
discussed in RFC 3986 (URN) and RFC 3305 with a “md” namespace identifier (NID).
However, for Common Metadata, rather than the fully articulated “urn:md” we abbreviate to
“md:”. The basic structure for a Common Metadata ID is
::= “md:” “:”“:”
• is the type of identifier. These are defined in sections throughout the document defining specific identifiers.
• is either a Common Metadata recognized naming scheme (e.g., “ISAN”) or “org” non-standard naming. These are specific to ID type and are therefore discussed in
sections addressing IDs of each type.
• (scheme specific ID) is a string that corresponds with IDs in scheme . For example, if the scheme is “ISAN” then the would be an ISAN number.
There is a special case where is “org”. This means that the ID is assigned by a
recognized organization within their own naming conventions. If is “org” then
::=
• is a unique name assigned to an organization, with the following rules:
o Organization is defined as domain name, including identifier tag. For example, movielabs.com becomes org:titleid.movielabs.com:… and bbc.co.uk
becomes org:mpm.bbc.co.uk:…
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 13
o Other naming schemes may be used in contexts where names can be assigned within the scope of ID usage.
• is a unique identifier assigned by the organization identified in . Organizations may use any naming convention as long as it complies with RFC 3986
syntax.
Some sample identifiers are
• ContentID: md:cid:EIDR:10.5240%2fF592-58D1-A4D9-E968-5435-L
• Content ID: md:cid:org:ourid.mystudio.com:12345ABCDEF
2.1.1 ID Simple Types
The simple type md:id-type is the basic type for all IDs. It is XML type xs:anyURI.
All identifiers are case insensitive and should be registered in canonical format and case sensitive
identifiers should not be used.
The simple types ContentID-type AssetLogicalID-type and AssetPhysicalID-type are
defined as md:id-type and can be used when a more specific designation is required.
2.1.2 EIDR Types
EIDR idenifiers can be embedded IDs expressed in the md: structure (defined in this section), or
expressed explicitly in identifier structures, such as found in ContentIdentifier-type,
AltIdentifier-type (defined in Section 4.1.3). EIDR can also be experessed in elements using the
EIDRURN-type definition as follows:
Element Attribute Definition Value Card.
EIDRURN-type
EIDRURN EIDR expressed in EIDR URN format as
defined in [RFC7972].
xs:anyURI
scope Structural Type of EIDR as defined below xs:string 0..1
@scope may have the following enumerations based on EIDR Structural Type found in EIDR
Registry User’s Guide [EIDR-UG]. Note that the scope does use the same terminology as EIDR
Structural Type for backwards compatibility reasons.
• ‘Title’ – ID is an EIDR ID with Structural Type of “Abstraction”
• ‘Edit’ – ID is an EIDR ID with Structural Type of “Performance”
• ‘Manifestation’ – ID is an EIDR ID with Structural Type of “Digital”
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 14
2.2 Asset Identifiers
Content Identifiers are assigned by the content owner or its designee. The following
scheme provides flexibility in naming while maintaining uniqueness.
Common Metadata defines two types of asset identifiers:
• A Content Identifier (ContentID) denotes an abstract representation of a content item.
• Asset Physical Identifier (APID) refers to a physical entity (i.e., a file) that is associated with content.
2.2.1 ContentID
Syntax: “md:cid:”“:”
A ContentID points to Basic metadata. ContentIDs may refer to abstract items such as
shows or seasons, even if there is no separate asset for that entity. A ContentID must be globally
unique.
The following restrictions apply to the and part of a ContentID:
• A ContentID scheme may not contain the colon character.
• Where display formats existsexist (i.e., human readable versus computer-readable) use display format.
• ContentID < scheme> and ContentID shall be in accordance with Table 2-1. Additional schemes may be added in the future.
Table 2-1: Content Identifier Scheme and Value
Scheme Expected value for
ISAN An element, as specified in ISO15706-2 Annex D.
TVG TV Guide
AMG AMG
IMDB IMDB
MUZE Muze
TRIB Tribune
Baseline Baseline Research ID, www.baselineresearch.com (now Gracenote)
UUID A UUID in the form 8-4-4-4-12
http://www.baselineresearch.com/
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 15
URI A URI; this allows compatibility with TVAnytime and MPEG-21
GRid A Global Release identifier for a music video; exactly 18 alphanumeric
characters
EIDR Entertainment ID Registry. http://www.eidr.org. In accordance with [ISO26324] and
[EIDR-TOTD]
EIDR-S Entertainment ID Registry. http://www.eidr.org .EIDR-S is a shortened EIDR that does not include the “10.5240/” prefix.
EIDR-X Entertainment ID Registry. http://www.eidr.org .EIDR-X is an extended form of
EIDR-S. EIDR-X is an EIDR-S form identifier followed by a colon (“:”) and an
extension string. The extension string shall contain ASCII characters, with the
exception of URN Reserved Characters [RFC2141], Section 2.3 and URN
Excluded Characters [RFC21451], Section 2.4.
EIDR-URN EIDR in URN format in accordance with [RFC7302].
ISMN International Standard Music Number, ISO 10957
ISRC Master recordings, ISO 3901,
http://www.ifpi.org/content/section_resources/isrc.html
ISWC Musical Works, http://www.cisac.org , ISO 15707
SICI Serial Item and Contribution Identifier [ANSI-Z39.56]
DOI Digital Object Identifier http://www.doi.org
SMPTE-UMID SMPTE-UMID as per SMPTE ST 330-2004
Ad-ID Ad-ID as per format defined at http://www.ad-id.org/how-it-works/ad-id-structure
GTIN Global Trade Item Number. http://www.gtin.info/
UPC Universal Product Code (UPC). UPC-E should be converted to UPC-A form.
CRid CRid (Content Reference Identifier) as per RFC 4078
http://tools.ietf.org/html/rfc4078
cIDf Content ID Forum. cIDf Specification 2.0, Rev 1.1., 4/1/2007.
DPID DDEX Party ID, Digital Data Exchange (DDEX) Party Identifier Standard, DDEX-
PID-10-2006, https://kb.ddex.net/display/HBK/DDEX+Party+Identifier+Standard
http://www.eidr.org/http://www.eidr.org/http://www.eidr.org/http://www.ifpi.org/content/section_resources/isrc.htmlhttp://www.cisac.org/http://www.doi.org/http://www.ad-id.org/how-it-works/ad-id-structurehttp://www.gtin.info/http://tools.ietf.org/html/rfc4078https://kb.ddex.net/display/HBK/DDEX+Party+Identifier+Standard
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 16
file Indicates that the identifier that follows is a local file name.
org begins with the Organization ID of the assigning organization and
follows with a string of characters that provides a unique identifier. The
must conform to RFC 3986 with respect to valid characters. In the absence of
agreements between parties using IDs of this form, we recommend the use of an
organization DNS domain (e.g., movielabs.com).
md MDDF namespace (e.g., for Common Metadata identifiers). It is not use as a
scheme in an identifier, but it is used in Namespace within ContentIdentifier-
type.
Identifiers that contain URI shall use Percent-Encoding as per [RFC3986] for characters
not allows in URNs as per [RFC2141]. For example, space (SP) is replaced by ‘%20’ and slash
(‘/’) is replaced by ‘%2f’. For example,
EIDR: 10.5240/F592-58D1-A4D9-E968-5435-L
ContentID: md:cid:EIDR:10.5240%2fF592-58D1-A4D9-E968-5435-L
Note that we recommend the use of EIDR-S, EIDR-X or EIDR-URN to avoid this
situation when encoding EIDR.
2.2.2 APID
Syntax: “md:apid:< scheme>“:”[“:”]
An APID is constrained as follows:
• Each APID is globally unique
The following restrictions apply to the , and part of an APID:
• An APID scheme may not contain the colon character
• Where display formats exists (i.e., human readable versus computer-readable) use display format.
• APID < scheme> and APID shall be structured the same as ContentID
• Optional is additional characters appended to the APID and may not contain colons
For example
• APID: md:apid:EIDR-S:58D1-A4D9-E968-F592-5435-M
• APID: md:apid:ISAN:0000-3BAB-9352-0000-G-0000-0000-Q:p1
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 17
Note that APIDs may be constructed from ContentIDs. For example:
• ContentID: md:cid:org:myid.MyCompany.com:ABCDEFG
APID: md:apid:org:myid.MyCompany.com:ABCDEFG:100
• ContentID: md:cid:ISAN:0000-3BAB-9352-0000-G-0000-0000-Q
APID: md:apid:ISAN:0000-3BAB-9352-0000-G-0000-0000-Q:A203
2.3 Organization ID
Common Metadata assumes one additional type be provided. That is an Organization ID
(OrgID). md:orgID-type is a simple type of type md:id-type.
Currently, there is not an adequate global identification scheme, so this element should be
used only if both the sending and receiving parties have an a priori agreement regarding the
contents of this ID.
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 18
3 GENERAL TYPES ENCODING
3.1 Language Encoding
Language shall be encoded in accordance with RFC 5646, Tags for Identifying
Languages [RFC5646]. The subtags that are available for use with RFC 5646 are available from
the Internet Assigned Numbers Authority (IANA) at [IANA-LANG]
http://www.iana.org/assignments/language-subtag-registry.
Matching, if applicable, should be in accordance with RFC 4647, Matching Language
Tags, [RFC4647]. Note that the subtag ‘zxx’ is used when the tagged object has no linguistic
content. This must be considered when matching language as in many cases ‘zxx’ will match all
languages. For example, the music track for a silent film is used for all user languages.
The xs:language type shall be used for languages. Language should be as specific as possible; for example, ‘ja-kata’ is preferable to ‘ja’.
The Language Metadata Table (LMT) [LMT] is emerging as a standard for encoding
languages. Where languages are listed in LMT, Audio Language Tag or Visual Language Tag
should be used as listed. In some cases there are two encodings for the same language. Where
they are not ambiguous, the shortest form should be used. For example, Afrikaans can be
encoded as ‘af’ or ‘af-ZA’. As Afrikaans there is no Afrikaans dialect outside of South Africa
(ZA), ‘af’ is sufficient and recommended. LMT Policies and Practices should be followed.
3.2 Region encoding
Region coding shall use the ISO 3166-1 two-letter alpha-2 codes [ISO3166-1].
Informally described here: http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2.
When subdivisions are required, ISO3166-2 shall be used [ISO3166-2]. Informally
described here: http://en.wikipedia.org/wiki/ISO_3166-2.
United Nations (UN) M.49 Codes [M49] may be used. Note that unlike the ISO codes,
UN codes can define regions such as Northern America (‘021’). Common Metadata shall use the following type for region:
Element Attribute Definition Value Card.
Region-type
country ISO 3166-1 Alpha 2 code xs:string
Pattern: “[A-Z][A-Z]”
(choice)
countryRegion ISO 3166-2 Code or UN M.49 code xs:string
Pattern: ([A-Z][A-Z]-[A-
Z0-9]+)|([0-9]{3})
(choice)
http://www.iana.org/assignments/language-subtag-registryhttp://en.wikipedia.org/wiki/ISO_3166-1_alpha-2http://en.wikipedia.org/wiki/ISO_3166-2
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 19
The MadeforRegion-type simple type is a restriction of xs:string that allows country
code, ‘Domestic” or “International”. For example, it could be “US”, “Domestic” or
“International”.
3.3 Date and Time encoding
Date and time encoding shall use the XML rules, in accordance with [XML], Part 2,
Section 3.2. That is, where ISO 8601 [ISO8601] deviates from XML encoding, XML encoding
shall apply.
3.3.1 Duration
Durations are represented using xs:duration. xs:time should not be used for duration.
Addition of durations to dateTime are, are performed in accordance with the definition of
XML duration (see [XML], Part 2, Section 3.2.6 and Appendix E).
3.3.2 Time
xs:time is used for a recurring time.
3.3.3 Dates and times
XML is fairly rigid in its date and time encoding rules. Specifically, it is difficult to have
a single element where resolution may range from ‘year’ to ‘date’ to ‘time’. In some instances
such as air dates/time, resolution might be year (movie released in 1939), date (movie released
on December 25, 2009), or date and time (episode aired November 6, 2001, or November 6,
2001, 10:00 PM EST).
• Year encoding uses xs:gYear (Gregorian year)
• Date encoding (year, month and day) uses xs:date
• Date encoding that includes both date and time shall uses xs:dateTime
Time zone should be included with xs:dateTime elements to avoid ambiguity. If representing a single point in time with no relevant time zone, Coordinated Universal Time
(UTC) should be used.
In some cases, there are options for including year, date and date-time. Optional
elements should be included if known and relevant.
As of version 1.2 of this specification, a new type has been define to support elements
that require year, date (year and day), or time (including date) without a priori knowledge of the
resolution. This simple type is YearDateOrTime-type.
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 20
Element Attribute Definition Value Card.
YearDateOrTime-
type
A simple type that syntactically allows the
inclusion of a year, a date or a date-time.
xs:union with memberTypes of
xs:gYear, xs:date, xs:dateTime
3.3.4 Date and time ranges
Date Ranges may be encoded using the DateTimeRange-type:
Element Attribute Definition Value Card.
DateTimeRange
Start Start of time period xs:dateTime
End End of time period xs:dateTime
3.4 String encoding
String lengths are specified in characters (rather than bytes) unless otherwise stated. A
string using double-byte Unicode characters can result in string elements whose actual size in
bytes is larger than the stated length.
3.5 Organization Naming and Credits
Organization names shall include both a user-friendly display name and a sortable name.
If the display name and the sort name are the same, the SortName element may be excluded.
All names are optional in the schema although DisplayName is generally required. It is
necessary to supply either DisplayName or the combination of organizationID and idType.
Element Attribute Definition Value Card.
OrgName-type
organizationID Organization’s unique ID md:orgID-type 0..1
idType ID scheme used for organizationID xs:string 0..1
DisplayName General display format. Safest to use
as it accommodates various
permutation on the name.
xs:string 0..1
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 21
SortName Sortable version of name. This will
often be last name first. This may be
displayed.
xs:string 0..1
AlternateName Other names for this organization xs:string 0..n
3.5.1 CompanyDisplayCredit-type
This type describes the intended audience for metadata:
Element Attribute Definition Value Card.
MetadataCompanyCredits-
type
DisplayString String to be displayed. md:OrgName-type 0..n
language Language of DisplayString. If blank, then all
languages
xs:language 0..1
Region Region(s) for which credits apply. md:Region-type 0..n
DisplaySequence Order of display. Lower-numbered entries are
displayed before higher-numbered entries.
Entries without this element should be
displayed after numbered entries.
xs:integer 0..1
3.5.2 AssociatedOrg-type
This is an organization with a Role:
Element Attribute Definition Value Card.
AssociatedOrg-type md:OrgName-type
(by extension)
role Role of the associated organization xs:string 0..1
The AssociatedOrg element provides information about organizational entities involved in the production, distribution, broadcast or other function relating to the asset. Often organizations
provide different functions, so multiple organizations can be listed. The role attribute to AssociatedOrg may have one of the following values:
• ‘producer’ – involved in the production of the asset
• ‘broadcaster’ – network associated with asset’s broadcast
• ‘distributor’ – entity involved with distribution
• ‘editor’ - editor
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 22
• ‘encoding’ – entity that encodes media
• ‘post-production’ – entity that performs post-production functions, not in another category
• ‘licensor’ – Entity offering license for this asset. Generally, this is used only with avails.
• ‘other’ – any organization that does not fall into the previous categories.
3.6 People Naming and Identification
This section describes the internationalized naming approach used for encoding metadata.
This section also defines person identification for the purposes of metadata.
3.6.1 PersonName-type
Element Attribute Definition Value Card.
PersonName-type
DisplayName Person’s name for display purposes. xs:string 1..n
language Language of DisplayName. There may be
multiple instances of DisplayName, but only
with unique language attributes.
xs:language 0..1
SortName Name used to sort. May be excluded if
identical to DisplayName.
xs:string 0..n
language Language of SortName. There may be
multiple instances of SortName, but only with
unique language attributes.
xs:language 0..1
FirstGivenName First name xs:string 0..1
SecondGivenName Second name xs:string 0..1
FamilyName Family name xs:string 0..1
Suffix Suffix xs:string 0..1
Moniker Alternative name, usually of the form
“”
(e.g., Scatman in Benjamin
Sherman “Scatman” Crothers). Note,
Moniker is misspelled but retained for
backwards compatibility.
xs:string 0..1
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 23
3.6.2 PersonIdentifier-type
Assuming there is an identifier associated with the person, this structure holds
information about that identifier.
Element Attribute Definition Value Card.
PersonIdentifier-type
Identifier Identifier associated with this individual within
the Namespace
xs:string
Namespace Namespace for identifier.
xs:string
ReferenceLocation Location associated for the identifier within
the namespace. This is expected to be an
online reference to information about the
individual.
xs:anyURI
3.7 Money-type and Currency
Currency shall be encoded using ISO 4217 Alphabetic Code [ISO4217].
http://www.iso.org/iso/currency_codes_list-1
Element Attribute Definition Value Card.
Money-type
currency Currency as expressed in ISO 4217
Currency Alphabetic Code. For example,
‘USD” for US Dollars.
xs:string
Value Value xs:decimal
[ISO4217] typically allows two or three digits after the decimal. However, Value in this
element may have as many decimal places as necessary.
3.8 Role Encoding, Role-type
Roles shall be encoded in accordance with ‘Term’ column of EBU Role codes found
here: http://www.ebu.ch/metadata/cs/web/ebu_RoleCodeCS_p.xml.htm, plus “Other Group” and
“Other” (referring to an unclassified individual).
Roles are defined in the simple type md:Role-type.
The JobFunction element allows for alternate schemes, however the scheme attribute is not supported at this time. At a future release, alternate schemes may be defined.
http://www.iso.org/iso/currency_codes_list-1http://www.ebu.ch/metadata/cs/web/ebu_RoleCodeCS_p.xml.htm
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 24
3.9 Keywords Encoding
Keywords are often culturally specific, so different keywords may exist for different
regions. At this time, no keywords are defined.
3.9.1 Name/Value Pairs, NVPair-type, NVPairMoney-type
Use of Name/Value pairs provides considerable flexibility for growth. The NVPair-type
complex type allows for any additional business data to be included in tuple format.
Element Attribute Definition Value Card.
NVPair-type
Name Identification of the parameter being
specified
xs:string
Value Value specified for Name. xs:string
NVPairMoney-type is like NVPair-type except the Value is currency-based.
Element Attribute Definition Value Card.
NVPairMoney-type
Name Identification of the parameter being
specified
xs:string
Value Value specified for Name. avail:Money-type
3.10 Personal/Corporate Contact Information, ContactInfo-type
Element Attribute Definition Value Card.
ContactInfo-type
Name Person or point of contact xs:string
PrimaryEmail Primary email address for user. xs:string
AlternateEmail Alternate email addresses, if any xs:string 0..n
Address Mail address xs:string 0..n
Phone Phone number. Use international (i.e.,
+1 …) format.
xs:string 0..n
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 25
3.11 Cryptographic Hash
The Hash-type definition describes a cryptographic hash such as SHA-1 and MD5.
Element Attribute Definition Value Card.
Hash-type Value of the cryptographic hash or error
detection/correction code
xs:string
method The hash generation method. xs:string 0..n
Values for method include:
• ‘MD2’, ‘MD4’ ,’MD5’ – Message Digest algorithms.
• ‘SHA-0’, ‘SHA-1’, ‘SHA-2’, ‘SHA-3’. SHA (Secure Hash Algorithm) family of algorithms. Distinction between hashes of different length is implicit in the hash and
should not be mentioned specifically. For example, use ‘SHA-2’, not ‘SHA-224’.
• ‘CRC16’, ‘CRC32’, ‘CRC64’ – Cyclic Redundancy Check (CRC).
3.12 GroupingEntity-type
Grouping Entity type allows logical grouping of assets. This is typically around studio or
network, but it can be any logical content grouping.
Element Attribute Definition Value Card.
GroupingEntity-type
Type The type of the group. xs:string
GroupIdentity A string (identifier) that uniquely identifies the
group.
xs:string
DisplayName A string that will be displayed when referring to this
group.
xs:string 1..n
language The language associated with the DisplayName. If
language is absent, DisplayName applies to all
langauges.
xs:language 0..1
Region Region where group applies. If Region is absent,
the group applies internationally.
md:Region-type 0..1
AltGroupIdentifier Alternate identifiers for Group Identity. md:ContentIdentifier-
type
0..n
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 26
Type defines the type of grouping. Value depends on the context of use. When using for
storefront grouping, currently, the only defined value is “publisher”, although other values are
not prohibited. “publisher” indicates the grouping is around the organization publishing the
content. Note that the actual publisher may differ from the publisher visible to the consumer. In
that case, the GroupIdentity would reflect the actual publisher and the DisplayName would
reflect the publisher familiar to the consumer.
Other values for Type may be defined for other usese of GroupingEntity-type, such as
relationship groupings.
3.13 Private Data
The following is defined to allow schemas using Common Metadata to extend elements
with data specific to that use. Interoperability will be very limited, elements of this type should
be used with extreme caution.
Element Attribute Definition Value Card.
PrivateData-type Value of the cryptographic hash xs:string
(any) Any data outside of ‘md’ namespace. xs:any ##other 1..n
3.14 MIME
MIME encoding is in accordance with [IANA-MIME].
Using images as an example, MIME types are encoded here:
http://www.iana.org/assignments/media-types/media-types.xhtml#image. Encoding for JPEG
must be ‘/image/jpeg’, not ‘/image/jpg’, ‘jpg’ or ‘jpeg’.
3.15 Workflow Attribute Group
This attribute group defines a set of elements to support workflows. This includes
revision information and information the help recipient determine the workflow for which this as
generated.
Attribute Group Attribute Definition Value Card.
Workflow-attr
updateNum Version of the object. Initial release
should be 1. This is a value assigned by
the object creator that should only be
incremented if a new version of object is
released. If absent, 1 is to be assumed.
xs:int 0..1
http://www.iana.org/assignments/media-types/media-types.xhtml#image
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 27
workflow The workflow for which this object is
intended.
xs:string 0..1
updateDeliveryType This indicates the object includes just
portions required for an updated. It is not
a complete object. The exact definition is
subject to specific practices and is
reference by this string.
xs:string 0..1
versionDescription Text that describes this version. xs:string 0..1
timestamp Timestamp of object xs:dateTime 0..1
3.16 Gender-type
The Gender-type complex type is intended to encode gender identity. That is, how a person publicly identifies not necessarily how some in society might view them Sexual
orientation is not included/encoded. Gender expression (e.g., gender-specific clothing, hair
length, or makeup) is not included/encoded. Sexual reassignment status is not included/encoded.
Gender Gender xs:string 0..1
transgender If true, this indicates a person is
transgender. If false, a person is
cisgender (i.e., not transgender).
xs:boolean 0..1
specificGender Self-identified gender xs:string 0..1
Gender is encoded as follows:
• ‘male’
• ‘female’
• ‘neutral’ – Gender is not applicable, such as a character being an inanimate object such as a robot
• ‘other’ – Genders not covered by another category
• ‘plural’– Deprecated. Do not use. May pass validation for a period of time.
@trangender indicates whether a person is transgender. This generally applies to
transgender male, transgender female and most categories associated with ‘other’. Note that
when the ‘other’ category is selected to indicate a gender other than male or female, it is
generally desirable to set @transgender=true to improve search results.
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 28
@specificGender may include any self-identified gender. When matching, ignore dashes
and white space. For example, ‘non-binary should match ‘nonbinary’. Multiple values should
be separated by commas. specificGender should not be included if it is identical to Gender.
For example:
Actor
Actor
Nomi Marks
Female
Jamie Clayton
Clayton, Jamie
Jamie
Clayton
Female
3.17 Compliance-type
Compliance-type allows the encoding of the state of compliance of an object (e.g., audio
or video) against a standard. Recommendations for particular compliance regimes may be
provided in Best Practices.
Compliance can also signal proprietary certifications such as “IMAX Enhanced”.
Attribute Group Attribute Definition Value Card.
Compliance-type
Category Category of compliance, when applicable. xs:string 0..1
Standard Standard against which compliance is
determined.
xs:string 0..1
Disposition State of compliance against Category
and/or Standard.
xs:string
CompetentAuthority Organization that certifies compliance md:AssociatedOrg-
type
0..1
Certificate A certificate of compliance (or equivalent)
in digital form.
xs:base64Binary 0..1
-
Common Metadata DRAFT
Ref: TR-META-CM Version: 2.8 DRAFT Date: October 7, 2019
Motion Picture Laboratories, Inc. 29
MIME Media Type (MIME type) of Certificate as
defined in [RFC2046] and listed in [IANA-
MIME], For example, if Certificate is PDF
form, MIME would be ‘applciation/pdf’.
xs:string
TestingOrganization Organization that determines technical
compliance. This can be an organization
doing self-testing, or a 3rd party.
md:AssociatedOrg-
type
0..1
TestingMethod Any specific method, process or tool
applied.
xs:string 0..1
Comments Any additional comments xs:string 0..1
At least one of Category and Standard must be present.
Disposition represents the state of shall be encoded as follows:
• ‘pass’ – Object complies with the standard, or category. When necessary, certification has been issued.
• ‘fail’ – Object fails to comply
• ‘pending’ – Object technically complies, but certification is pending
• ‘other’ – Object has not been determined to comply or not. This includes objects being test.
An example of compliance is whether video meets Photosensitive Epilepsy (PSE)
guidelines. The Category is ‘EPS’. Standard would be BT.1702 (see [BT.1702]). Note that
Ofcom Guidance [OFCOM-GN12-2] simply restates BT.1702 and would not be the primary
reference. Assuming the video passes, Disposition would be ‘Pass’. There is no Competent
Authority issuing certificates, so Competent Authority and Certificate would not be included.
TestingOrganization would be one of the organizations that test; for example, hardingtest.com.
TestingMethod would be the method applied, in this generally “Harding Test” or “Harding Box”.
3.18 Terms-type
Terms allows arbitrary terms to be specified.
The precise interpretation is subject to the mutual agreement of parties involved, although
guidance is provided within.
Each term is a name/value pair with the name expressed as termName and the value
expressed as one of Money, Event, Duration or text depending on the data contained within the
term.