and Bundles (Technical Note) · 5 Using EIDR ... technical note and a specification, ... [DCoord]...

Technical Note: Content Structure. DRAFT v0.7

©2009-2012 Digital Entertainment Content Ecosystem (DECE) LLC P a g e | 1

1

Identifiers, Content Structure, Metadata and Bundles (Technical Note) Version 0.7, 27-February-2012



Notice:

THIS DOCUMENT IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY

OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY

WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Digital

Entertainment Content Ecosystem (DECE) LLC (“DECE”) and its members disclaim all liability, including

liability for infringement of any proprietary rights, relating to use of information in this specification. No

license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted herein.

Implementation of this specification requires a license from DECE. This document is subject to change

under applicable license provisions.

Copyright © 2009-2012 by DECE. Third-party brands and names are the property of their respective

owners.

Contact Information:

Licensing inquiries and requests should be addressed to us at: http://www.uvvu.com/uv-for-business.php

The URL for the DECE web site is http://www.uvvu.com

http://www.uvvu.com/uv-for-business.php

http://www.uvvu.com/



Contents

1 Introduction ......................................................................................................................................................... 4 1.1 Document Purpose ..................................................................................................................................... 4 1.2 Conformance .............................................................................................................................................. 4 1.3 References .................................................................................................................................................. 4

2 Identifiers ............................................................................................................................................................. 6 2.1 Note on Naming ......................................................................................................................................... 6 2.2 Content ID ................................................................................................................................................... 6 2.3 Physical Asset ID ......................................................................................................................................... 6 2.4 Logical Asset ID (ALID) ................................................................................................................................ 7 2.5 Bundle ID .................................................................................................................................................... 7 2.6 Final note on ID naming .............................................................................................................................. 8

3 Creating and Using Metadata .............................................................................................................................. 9 3.1 Relationships in metadata .......................................................................................................................... 9 3.2 Publishing relationships in metadata ....................................................................................................... 10 3.3 Constructing Content Structure from Metadata ...................................................................................... 11

3.3.1 Building structure .............................................................................................................................. 11 3.3.2 Basic Metadata View ......................................................................................................................... 12 3.3.3 Purchase View based on SoldAs ........................................................................................................ 14

4 Bundles ............................................................................................................................................................... 15 4.1 Publishing Bundles .................................................................................................................................... 15 4.2 Displaying Information from Bundles ....................................................................................................... 16

5 Using EIDR .......................................................................................................................................................... 17 5.1 MovieLabs Recommendation ................................................................................................................... 17 5.2 Which EIDR Objects to Use ....................................................................................................................... 17 5.3 Using EIDR in DECE ................................................................................................................................... 18 5.4 ID Format .................................................................................................................................................. 18

5.4.1 Content ID and ALID .......................................................................................................................... 19 5.4.2 APID ................................................................................................................................................... 19 5.4.3 Bundle ............................................................................................................................................... 19

5.5 Use of EIDR Short Forms ........................................................................................................................... 19 5.6 EIDR AND DECE Metadata ........................................................................................................................ 19 5.7 Further reading on EIDR ........................................................................................................................... 20



1 INTRODUCTION

1.1 Document Purpose

This Technical Note is intended to help Publishers better understand the thinking behind the Content Publishing

Specification [DPublish], particularly Section 6 and 7, and Content Metadata [DMeta], Section 3. [DMeta] heavily

references Common Metadata [TR-META-CM]. You should have those specifications nearby when reading this.

This is focused on information published to the Coordinator. Container publishing will be addressed separately.

Like many aspects of the Ecosystem, the publishing structure was designed to anticipate work types and business

uses cases that may not exist for a while. Without knowing all ways the Ecosystem was to be used, we designed

for the general case so as not to constrain the future.

That said, most of the complexity can be easily ignored. This document should help you do that.

1.2 Conformance

This document is guidance and does not supersede technical specifications. If there is any conflict between this

technical note and a specification, the specification takes precedence.

The author of this document would be most appreciative if you let us know if any information here contradicts

[DPublish].

1.3 References

[DCoord] Coordinator API Specification

[DDiscrete] Discrete Media

[DSystem] System Specification

[DDevice] Device Specification

[DMeta] Content Metadata Specification

[DMedia] Common File Format & Media Format Specification

[DSecMech] Message Security Mechanisms Specification

[DGeo] Geography Specification

[ISO-DP2] ISO/IEC Directives, Part 2, Annex H: http://www.iec.ch/tiss/iec/Directives-Part2-Ed5.pdf

[IANA-A] IANA Audio Media Types, http://www.iana.org/assignments/media-types/audio/

[IANA-V] IANA Video Media Types, http://www.iana.org/assignments/media-types/video/

http://www.iec.ch/tiss/iec/Directives-Part2-Ed5.pdf

http://www.iana.org/assignments/media-types/audio/

http://www.iana.org/assignments/media-types/video/



[TR-META-CM] Common Metadata, TR-META-CM, v1.2, November 1, 2011, Motion Picture Laboratories, Inc.,

http://www.movielabs.com/md/md/v1.2/Common%20Metadata%20v1.2.pdf

[XSD-META-CM] XML Schema to accompany [TR-META-CM], October 29, 2010,

http://www.movielabs.com/schema/md/v1.07/md.xsd

[TR-META-EMA] EMA Metadata,TR-META-EMA, v1.0, January 5, 2010,

[EIDR-REC] Entertainment ID Registry (EIDR) Resources. http://eidr.org/resources/

http://www.movielabs.com/md/md/v1.2/Common%20Metadata%20v1.2.pdf

http://www.movielabs.com/schema/md/v1.07/md.xsd

http://eidr.org/resources/



2 IDENTIFIERS

There are multiple identifiers associated with Content. These are necessary to sustain the information model for

the Ecosystem, but unfortunately they are confusing. In this section, we provide an informal description of these

identifiers to provide a better intuitive understanding of what they are.

2.1 Note on Naming

The identifiers are named somewhat abstractly because when we tried more meaningful names everyone got

confused. You’ll note that terms like ‘product’ are rigorously avoided because they are not precise and people

have preconceived notions of what they mean. The fact that nobody has a preconceived definition of “logical

asset” allows us to define it precisely.

2.2 Content ID

The Content ID (also referred to as ContentID and CID) is used exclusively as a reference to metadata. As such, it’s

important for User interface, but it has no actual function in UltraViolet core functionality such as Rights

management, licensing, distribution, and packaging.

A Content ID can describe an actual work, such as a movie, a TV episode or a short subject, or it can be an object

used to group things such as a season, series or franchise.

Everything identified by a Content ID should have Basic Metadata record. Basic Metadata is formally defined in

the context of UltraViolet in Content Metadata [DMeta], however the spec with the description of each field is

Common Metadata [TR-META-CM].

Keep in mind that Metadata is used by every User Interface in the Ecosystem (Web Portal, LASPs, Devices, etc.).

It’s important that it be properly included and described (more on that later).

ContentID covers n version of the work, regardless of where that work is released. Metadata can contain multiple

instances if localized information, so on ContentID can cover many regions and languages. Only if the edit

changes, is a new ContentID required.

2.3 Physical Asset ID

For download delivery using a DECE Container, an Asset Physical Identifier (APID) uniquely identifies each

Container and is used for fulfillment and licensing.

The Physical Asset ID is more commonly referred to as an APID. In general, the terms Physical Asset and Digital

Asset are synonymous, and you will see the term Digital Asset used more commonly in the specifications.

An APID refers to the contents of an Original DECE Common File Format Container (ODCC1). In other words, it

identifies the contents of the Container a Publisher publishes.

It’s important to understand the following

1 An ODCC is the Container produced by the Publisher before it gets Retailer-specific data and licenses.



An APID does not correspond to a specific, single file. A Container is a Container regardless of whether it’s

in a file by itself, part of a ZIP file or packaged in some other way.

Certain changes can be made to a Container without changing the APID. Most notably

o Adding a DRM license to a Container NEVER changes the APID. For example, if a Marlin license is

added to a Container, that Container still has the same APID.

o Changing metadata MAY change the APID at the discretion of the Publisher. We strongly

recommend changing the APID when metadata is changed. For example, if there is an error in

the title that is corrected, the Container with the corrected title should have a new APID.

o More than one APID can be assigned to identical ODCCs (identical, that is, except for the APID in

the Container). This can be useed for tracking, but don’t do this unless you have a compelling

reason to do so. The concept was originally derived from the practice of unique SKUs for

particular retailers. There is not a clear use case in UltraViolet, but the capability exists in case

something comes up in the future. In the meantime, this is not recommended.

The addition or removal of tracks from a Container creates a new Container that requires a new APID.

Digital Media Packages (DMPs) are ZIP files that can contain multiple Containers and other information.

Although use cases are not finalized, DMPs are anticipated for use with interactivity, late binding or to

package multiple Containers together. Each Container within a DMP is identified with the Container, but

the DMP is currently not identified with an APID.

2.4 Logical Asset ID (ALID)

The Logical Asset Identifier (ALID) defines the content that a person has Rights to. The ALID goes into the Rights

Token along with information about the profiles granted (e.g., SD, HD).

To understand an ALID, It’s useful to look at how the ALID is used. When a User gets a Right, a Rights Token is

posted to the Coordinator. The most important aspects of the Rights Token are the ALID and the Rights Profiles.

The ALID defines everything that can be fulfilled, and the Rights Profiles defines what subset of that is the User is

entitled to. Through the ALID a one can find a description of the Content (through ContentIDs) and can find all the

Containers for the Right (thought APIDs). The APID completes the picture. Rights Profiles define for each media

profile (i.e., SD, HD) whether a User can download and stream, and what discrete media rights apply.

The ALID is the glue that ties everything together.

2.5 Bundle ID

One needs a Bundle for any arbitrary grouping, especially when additional description is needed. This applies to

anything not covered by the metadata structure alone; typically something that is not a season, series, movie

series, franchise, or other naturally grouped object.

Bundles should not be used when metadata does the grouping. Examples are provided below.



2.6 Final note on ID naming

People ask why Physical Asset ID is APID, and Logical Asset ID is ALID. It’s because PAID and LAID are lousy

acronyms.



3 CREATING AND USING METADATA

Basic Metadata includes mechanisms to define the relationships between works, such as episodes, seasons and

shows. Section 7 of [DPublish] discusses this extensively. You should read that before reading this section.

Conceptually, Content is either naturally grouped or arbitrarily grouped. For example, TV Episodes are naturally

grouped, and a collection of movies filmed in San Francisco is arbitrarily grouped.

Generally:

Naturally grouped Content is handled exclusively in metadata

Arbitrarily grouped Content is handled in Bundles

People commonly assume that Bundles are necessary to group Content sold together (e.g., an entire season of TV

episodes). They are not, and this section describes the mechanisms for with grouping Content without Bundles.

3.1 Relationships in metadata

DECE Metadata (based on Common Metadata) was designed to incorporate content relationships. Some examples

of relationships easily expressed include

Episode to season

Season to show

Movie to movie series (e.g., Star Wars Rocky, Lord of the Rings)

Trailer to movie

TV shows, movies, and movie series to franchises

Furthermore, the structure also accommodates complex structures such as a talk show with clips from a movie, or

mashups. These are probably not of much concern for DECE, but they are there if you need them.

This can be thought of as the “natural structure” of the Content. The relationships are inherent in their structure,

not at all arbitrary. The natural structure of Content relationships can be expressed exclusively in metadata.

The following examples illustrate when it one should not use Bundles. Later we discuss when one should use

Bundles.

Standalone Movie

There is not structure to describe

Movie 1

Episodic TV

Episodic material is grouped by the Basic Metadata. No additional information is needed.

Episode 1

Episode 2

…

Episode n



Movie with related Ancillary material

Since each item relates back to Movie 1, there is no additional structure (i.e., Bundle) is needed.

Movie 1

Trailer (ispromotionfor Movie 1)

Making of (issupplementto Movie 1)

Movie with unrelated Ancillary material

The Bundle still isn’t necessary. Even though there is an unrelated item included, the Coordinator keeps track of

the grouping in the Rights Token SoldAs element2.

Movie 1



Trailer for another movie (ispromotionfor Movie 2)

3.2 Publishing relationships in metadata

Sections 7.1-7.4 of [DPublish] are dedicated to this topic. PLEASE read that carefully.

In the following sections, we will use an abstract TV Show for examples. Conceptually, the TV Show looks like this:

Season 2

Episode 1 Episode 2 Episode n…

Season m… Season 1

Show

2 Note that when multiple Rights are sold together the SoldAs element includes either a list of ContentIDs or a BundleID



For Season 2, the following BasicMetadata resources would be published (each with their own ContentID):

BasicMetadata Resource Parent

Show

Season 2

Show

Episode 1

Season 2

Episode 2

Season 2

… Season 2

Episode n

Season 2

Note that publishing BasicMetadata elements with Parents encapsulated in the Parent element is acceptable,

although it’s more confusing and it is recommended that individual resources be published with references to the

Parent rather than inclusion of Parent metadata. Note that it is easier to maintain Parent metadata when it is a

single separate record, than when it is repeated in each subordinate element.

3.3 Constructing Content Structure from Metadata

The Rights Locker is a flat structure. If it contains, for example, TV shows then it only lists episodes. As this section

will show, that is sufficient to build an organized view of the Content. The proper organization of Content for

display is always handled on the client side (i.e., Device, Web User Interface, etc.).

3.3.1 Building structure

It is presumed that applications will rebuild the hierarchical structure when managing data from a list of

ContentIDs (i.e., from a Rights Locker). The Rights Locker has only the Episodes, so as each episode is read, the

structure is built. The following illustrates how an application might build an internal data structure from a list of

ContentIDs and their associated metadata. Note that parent information would be in the Parent element, either

included as part of the metadata, or referenced through the parent’s ContentID.



BasicMetadata Resource

Parent Data structure in application

Episode 1

Season 2

Season 2

Episode 1

Show

Episode 2

Season 2

Season 2

Episode 1 Episode 2

Show

… Season 2

…

Episode n

Season 2

Season 2


Show

When the process is complete, the application has the complete structure. Had there been episodes from other

seasons, both the episodes and the seasons would be included in the structure.

This process applies whether or not a Bundle is used. This structure is always useful for displaying Content.

If there are episodes from other seasons, the structure expands accordingly.

Season 2



Show

Episode 1 Episode 2 Episode n… Episode 1 Episode 2 Episode n…

3.3.2 Basic Metadata View

It was conceived that Users would view their data based on Basic Metadata starting from the top. Given the

structure above, it would look something like this.



Here is how a TV show might conceptually look to a User. On the left is a schematic of the user interface. On the

Right is an illustration of the Content structure. Note that “DM” refers to Discrete Media.

User’s click on “+” to open up detail…

Season 2



Show

Season 2



Show

Season 2



Show

Season 2

Episode 1

SD DMHD DM

Episode 2

SD DMHD DM

Episode n

SD DMHD DM

…


Show

(note: red/pink items are digital assets, each with their own APID—

mappings come from LogicalAsset element)

Partial seasons will display with only the episodes that were included.

+ Show

- Show

+ Season 1

+ Season 2

…

+ Season m

- Show

+Season 1

- Season 2

+ Episode 1

+ Episode 2

…

+ Episode n

…

+ Season m

- Show

+Season 1

- Season 2

- Episode 1

HD

SD

DM + Episode 2

…

+ Episode n

…

+ Season m

Download Stream

Download

Download and Burn

Stream



3.3.3 Purchase View based on SoldAs

As illustrated above, Content is often self-organizing. However, User’s sometimes want to know what they bought.

For example:

Did I buy an individual season, or did I buy individual episodes?

Green Lantern: Emerald Knights appeared in my Rights Locker; where did it come from?

I thought I bought the Mission Impossible set, so why do I have Mission Impossible I and Mission

Impossible III, but not II?

To support this capability, the Rights Token contains an element called SoldAs. SoldAs contains a description, an

optional ProductID (not currently used), and choice of a list of ContentIDs or a BundleID.

When a more than one Rights Token is posted as part of a sale, it is required that the Retailer will put information

in the SoldAs element. If the Right is sold as part of a Bundle, the BundleID is put in SoldAs. If the Rights are sold

together, but not as part of a Bundle, a list of ContentIDs is put on SoldAs. If a Right is sold by itself, no SoldAs is

needed as it is implicit that the Right was sold separately.

To answer the questions above:

SoldAs for each episode lists the ContentIDs for the entire season, so I bought it as a season.

SoldAs should indicate that Emerald Knights was added to my Rights Locker when I bought Green Lantern.

SoldAs indicates I bought the MI:I and MI:III individually, and never bought MI:II.

The process of organizing these data is similar to reading data from the Rights Locker. The only difference is the

list of ContentIDs. That is, rather than using all ContentIDs in Rights Tokens, only use the ContentIDs in the SoldAs

element.

SoldAs can also contain Bundle information. This is discussed in a later section.

There is no mandate that UIs make use of SoldAs data. However, it is required that Retailers include SoldAs,

except when a single title is sold separately.



4 BUNDLES

The most important thing to know about Bundles is that if you are not absolutely certain you need one, then you

don’t need one.

The Rights Token was designed to support a wide range of options for displaying Rights. The data described above

are not sufficient to present the context of sale for arbitrary groupings. Bundles contain information about

arbitrary groupings.

In most cases, Bundles are not necessary. Before creating a Bundle, carefully consider whether the data in

BasicMetadata and SoldAs already covers the necessary grouping.

Sections 7.5 of [DPublish] is dedicated to this topic, so it won’t be repeated here. PLEASE read that carefully.

4.1 Publishing Bundles

In some cases, Content is offered in a grouping that is not immediately obvious. Additional information is needed

to group the Content for the User. Bundles are for the convenience of the User and don’t affect licensing,

fulfillment or other core functions.

Following are some examples of where Bundles are needed.

Arbitrary grouping of Movies

Movie 2 and 3 have no structural relationship with Movie 1, but structure is needed to present Content as

intended.

Movie 1



Movie 2

Trailer for another movie (ispromotionfor Movie 2)

Movie 3

The Coordinator still keeps track of the sale, but there is no way of describing how these items relate to each

other. The Bundle would add the following structure [info in brackets are comments]. Note that the description

and structure that’s not found elsewhere.

DisplayName: “Tom Cruise Collection”

LogicalAssetReference: ALID 1, ALID 2, ALID 3, ALID 4, ALID 5, ALID 6

CompObj:

o “Tom Cruise Collection”

(CID 1) [movie, titles picked up from metadata when CID given]

“Trailers”

(CID 2)

(CID 3)

(CID 4) [making of]



“The Early Years”

(CID 5) [Top Gun]

o “Teaser” (CID 6) [name overrides name in metadata]

(CID 7) [All the Right Moves]

4.2 Displaying Information from Bundles

Content sold as part of a Bundle can be presented either as part of the Bundle or as individual items tied together

through Basic Metadata. If presented as a Bundle, the structure is in encoded within the Bundle.



5 USING EIDR

This section describes how EIDR works within DECE (UltraViolet). EIDR is used in examples in the following section.

5.1 MovieLabs Recommendation

Although the range of EIDR identifiers is much broader than needed for DECE, DECE’s ID requirements can be met

using EIDR IDs.

Given the benefits of standard identifiers, MovieLabs recommends studios use EIDR IDs. EIDR was created to

promote efficiencies and to support interoperability between systems. Using EIDR in DECE not only supports

efficient publishing through metadata compatibility with internal studio systems using EIDR, it also allows DECE

applications and services to make use of other services that use EIDR. We believe this offers advantages for

studios, for partners and for customers.

5.2 Which EIDR Objects to Use

Content ID, ALID, APID, and Bundle align directly with EIDR objects as follows:

A Content ID for an individual work corresponds to an EIDR Edit object. These Edit objects represent

particular releases, edits, versions, or other instantiations of a title, but do not have a specific digital form.

(DECE metadata also uses Content IDs for abstract constructs such as Season and Series. In those cases,

the EIDR ID for the Series or Season would be used.)

An ALID corresponds to an EIDR Edit object, the same one used for the Content ID.

An APID corresponds to an EIDR Encoding object. These both represent the playable digital form of an

asset, including information about the encoding and the 'container' in which the encoding is carried

(Common File Format, in the case of DECE).

The DECE Bundle mechanism, which defines a group of assets (typically associated with a product

offering), corresponds to EIDR’s Composite object, which represents a collection of other EIDR objects.



5.3 Using EIDR in DECE

The following illustrates the correspondence between EIDR record types and DECE (excluding the use of Content

IDs in the context of DECE metadata for a Series or Season).

5.4 ID Format

In DECE, IDs are URNs with the following form

‘urn:dece:’<type>’:’<scheme>’:’<ID>.

When using an EIDR ID <scheme> is ‘eidr-s’, and the <ID> is the EIDR ID minus the prefix and slash. For

example,

EIDR: 10.5420/ABCD-ABCD-ABCD-ABCD-ABCD-E

ContentID: urn:dece:cid:eidr-s:ABCD-ABCD-ABCD-ABCD-ABCD-E

As shown, EIDR objects correspond directly to DECE’s Content, Containers and Bundles. Consequently, there is a

direct mapping of EIDR IDs to DECE’s Content ID, APID and Bundle ID.

DECE EIDR

Container (Physical Asset)

Logical

Asset

Content

Content ID

ALID

APID

Edit (Version)

Encoding (Digital Asset)

10.5420/ABCD-ABCD-ABCD-ABCD-ABCD-E

10.5420/DCAB-DCBA-DCBA-DCBA-DCBA-B

urn:dece:contentid:eidr-s:ABCD-ABCD-ABCD-ABCD-ABCD-E

urn:dece:apid:eidr-s:CDEF-CDEF-CDEF-CDEF-CDEF-A

urn:dece:alid:eidr-s:ABCD-ABCD-ABCD-ABCD-ABCD-E

Bundle

Bundle ID

Composite

10.5420/BCDA-BCDA-BCDA-BCDA-BCDA-C urn:dece:bid:eidr-s:BCDA-BCDA-BCDA-BCDA-BCDA-C



5.4.1 Content ID and ALID

In Content IDs for individual works and ALIDs, the EIDR ID for an Edit is used. This allows Rights to different

versions, such as a Director’s Cut, to be expressed. Most commonly there is only one Logical Asset (Right)

associated with a Content item. (HD vs. SD entitlement is expressed in the Rights Token, and so does not require a

separate ALID.) In this case, the EIDR used for the Content ID is also used in the ALID.

This mapping of EIDR Edit records to DECE Content ID and ALID holds for both movie and episodic content.

Generally, separate Rights Tokens are generated for each identifiable piece of content, e.g., each episode. So a

Series or Season EIDR would never be used in an ALID to represent a collection of episodes.

5.4.2 APID

In the case of a DECE APID, for a DECE Container, an EIDR ID for an Encoding is used. Digital asset metadata

generally distinguishes two Containers within EIDR. If more than one APID needs to be assigned for a given

encoding, the ContainerVersionReference metadata element within the Container is used to

differentiate.

5.4.3 Bundle

A DECE Bundle is represented by an EIDR Composite object. The EIDR Composite type groups multiple EIDR items

together by reference, using the EIDR IDs of the contained assets.

The EIDR Composite should be created with a Composite Class of “On-line delivery” and the Registrant Extra field

should include the string “DECE: Bundle” to facilitate searches. The elements of the composite should be the EIDR

Edits corresponding to the ALIDs of the bundle.

Furthermore, EIDR provides an IsPackagingOf relationship that can be applied to any pair of objects. An

IsPackagingOf relationship should be created if the set of objects in the bundle ('composite', in EIDR terms) is

related to some other identified grouping. For example, a composite composed of TV episodes can point to a

Season or Series, and a composite containing a movie and some extras can be labeled as a packaging of the movie

itself. The EIDR for a Series or Season should not be directly used to identify a DECE Bundle.

5.5 Use of EIDR Short Forms

The EIDR-S short-form ID used above is derived from the complete EIDR ID, which also includes a prefix (usually

10.5240/) placing the ID within the context of the global Handle System and the Digital Object Identifier (DOI)

family of registries. The complete EIDR ID with the prefix makes the ID resolvable in the Handle System and the

DOI infrastructure. The short-form EIDR-S uses a non-standard URN format recommended by EIDR for practical

operational use in some contexts. However, when the ID is used in other contexts or passed outside the DECE

infrastructure, it is important to re-append the full prefix in order to ensure successful DOI resolvability in a non-

DECE context.

5.6 EIDR AND DECE Metadata

EIDR and DECE were both designed around MovieLabs Common Metadata and therefore have consistent data

models and core data; making them highly compatible. Operationally, EIDR and DECE work off of the same basic

metadata, facilitating generation of consistent EIDR and DECE metadata.



Entertainment Merchants Association (EMA) metadata, anticipated for distribution to DECE Retailers, uses the

same data and model. We anticipate that metadata management in DECE will be much simplified with the use of

compatible standards, including EIDR.

The diagram below shows how the metadata may be generated in parallel for EIDR and DECE.

5.7 Further reading on EIDR

For more information, please see DECE System Specification for a description of DECE Identifiers. EIDR information

can be found in the EIDR Technical Overview and related documentation, especially the Data Fields Reference,

available at http://eidr.org/resources.

### END ###

DECE

Metadata

EIDR

Metadata

Same

Studio Metadata

EIDR-unique DECE-unique

http://eidr.org/resources

Date post:	20-Jun-2018
Category:	Documents
Upload:	hoangmien
View:	214 times
Download:	0 times

and Bundles (Technical Note) · 5 Using EIDR ... technical note and a specification, ... [DCoord]...

Documents