EIDR

The canonical form of an EIDR Content ID is an instance of a handle and has the format:

10.5240/XXXX-XXXX-XXXX-XXXX-XXXX-C

where

• 10.5240 is the DOI prefix for an EIDR asset. The "10" indicates the handle is a DOI; other prefixes are assigned to other asset types (e.g. academic publications). The digits between the "." and "/" form the sub-prefix, which indicates which registration agency within the International DOI Foundation (IDF) has rights to manage these handles. "5240" is assigned to the EIDR Association.
• XXXX-XXXX-XXXX-XXXX-XXXX-C is the DOI suffix. Each "X" denotes a hexadecimal digit (A-F), and "C" is an ISO 7064 Mod 37,36[2] check digit.

There is also a 96-bit compact binary form that is intended for embedding in small payloads such as watermarks. This form is generated from the canonical format as follows:

• 16-bit sub-prefix: generated by interpreting the sub-prefix as a binary value, e.g. B'0001010001111000'
• 80-bit suffix: the non-checksum part of the suffix, represented as 10 bytes

The Uniform Resource Name form for an EIDR ID is specified in RFC 7302.

For use on the web an EIDR content ID can be represented as a URI in one of these forms:

• https://doi.org/10.5240/XXXX-XXXX-XXXX-XXXX-XXXX-C: this is an EIDR ID represented as a DOI proxy reference (it will be redirected from DOI to the EIDR registry)
• info:doi:10.5240/XXXX-XXXX-XXXX-XXXX-XXXX-C [deprecated]: this is an EIDR ID represented as an RFC 4452 compliant "info" URI (remembering that all EIDR IDs are also DOI IDs, but not the converse).

There are four types of content records, each associated with a reserved prefix:

• Content ID (10.5240/XXXX-XXXX-XXXX-XXXX-XXXX-C): is associated with an entertainment asset such as a movie or TV series. Content records are hierarchical, allowing relationships to be expressed such as a Series, whose children would be Seasons, whose children in turn would be individual episodes. Many other relationships are supported, as described below. Content records form the bulk of the data in the EIDR registry.
• Party ID (10.5237/XXXX-XXXX): identifies entities such as registrants, content producers, and distributors.
• Video Service ID (10.5239/XXXX-XXXX): Identifies a video service, colloquially known as a "channel" or "network": a (usually) linear sequence of content scheduled to be broadcast at specified times (e.g. the Service ID for the Cartoon Network is 10.5239/8BE5-E3F6). Video services are hierarchical: for example, a parent may have several children to account for regional or language variations).
• User ID (10.5238/[0-9a-zA-Z_.#()]{2-32}): Identifies a user using a string of 2–32 alphanumeric and selected special characters (illustrated here with Perl syntax). A User is primarily an administrative concept that is subordinate to Parties (from whom they inherit access rights). Unlike the other EIDR DOIs, the User ID can only be used within EIDR (e.g. programming APIs).

The sub-prefixes 5237, 5238, 5239, and 5240 are all assigned to the EIDR Association.

Content records are objects categorized by their types and relationships. Each has three different (orthogonal) kinds of type:

• Object Type: there are a total of 10 of these. First is the Basic Type, which has the minimal fields necessary to describe a content record. The other 9 are derived from the basic type, and contain extra fields for describing more complex objects.
• Structural Type: these distinguish representations of a work and are listed in increasing order of specificity:
  • Abstraction: Used for objects having no reality, such as a series container or the most basic concept of the original work. This corresponds to the International Standard Musical Work Code (ISWC) for musical works, the International Standard Text Code (ISTC) for textual works, or the International Standard Audiovisual Number (ISAN) for audiovisual works.
  • Performance: Used for items that are particular versions of a work, such as the original theatrical release or director's cut of a film or a locally censored version of a TV show. This roughly corresponds to the International Standard Recording Code (ISRC) for musical works and to some uses of the Version ISAN (V-ISAN) for audiovisual works.
  • Digital: A particular digital representation of a work, such as an MPEG-2 encoding of a movie. This corresponds to some uses of the V-ISAN.
• Referent Type: the type of the content asset, independent of a particular manifestation (e.g. a movie shown on TV is still a movie):
  • Series: An Abstraction that contains ordered or unordered individual items.
  • Season: A second level of grouping below a Series, usually covering a time interval
  • TV: Content that first appeared via broadcast.
  • Movie: Long-form content that first appeared in a cinema or theater.
  • Short: Loosely defined to cover a work that is 40 minutes or less, such as music videos, theatrical newsreels, or theatrical or DTV cartoon shorts.
  • Web: Content that first appeared on the Web. This is different from content from elsewhere that has been made available on the Web.
  • Interactive Material: Content that is not strictly audio-visual. It covers DVD menus, interactive TV overlays, customized players, etc.
  • Compilation: Content composed of multiple other assets that cannot be more precisely described, such as a box set of a film franchise.
  • Supplemental: This type is for secondary content whose primary purpose is to support, augment, or promote other content. Examples include trailers, outtakes, and promotion documentaries ("making of" pieces).

The following fields (taken from a larger set) comprise the base object data of a content record:

• Structural Type: e.g. Abstraction
• Mode: e.g. AudioVisual (for a movie or TV program); "Audio" for a radio program; "Visual" for a silent work.
• Referent Type: e.g. Movie
• Title: the primary title. Titles and Alternate Titles are further distinguished by:
  • Lang: the language of the title expressed as ISO 639-1 code
  • Class: release or regional
• Alternate Title 1..N: one or more alternate titles (often regional or language variants)
• Original Language: the language of the original release expressed as ISO 639-1 code
• Associated Org 1..N: Party ID(s) of producer, studio, etc.
• Release Date: date title was originally released
• Country of Origin: ISO 3166-1 alpha 2 code, with extensions for defunct countries
• Approximate Length: expressed as XML Schema xs:duration[3] datatype
• Alternate ID 1..N: one or more equivalent IDs expressed in a different asset ID system (see discussion below).
• Credits: only skeletal credits are provided, typically restricted to the director and up to four of the main actors. As noted, it is a non-goal for EIDR to compete with proprietary systems with rich metadata (e.g. plot summaries). The main goal is to assist with disambiguating the title, and helping with validation and de-duplication efforts.
• Registrant: the party that created this content record (e.g. "10.5237/superparty")
• Creation Date: date this content record was created
• Status: normally "valid" (there are special cases for deleted records)
• Last Modification Date: last time this content record was changed

An EIDR ID must be always resolvable, thus under normal circumstances the corresponding Content Record will be permanent. There are two mechanisms available to deal with errors or other unusual circumstances. The preferred one is aliasing, whereby an EIDR ID is transparently redirected to another content record. Aliasing is commonly employed to deal with an asset being registered twice.

The other mechanism is the use of tombstone records. This is employed when the Content Record is corrupted, or an otherwise invalid asset was accidentally registered. In this case the ID will be aliased to a special tombstone record. The tombstone can be recognized by applications because its EIDR ID field will be set to the distinguished value "10.5240/0000-0000-0000-0000-0000-X". Note that "X" means the 24th letter of the Latin alphabet (ASCII 0x58 or Unicode U+0058).

Having a rich set of alternate IDs for content is one of the primary goals of EIDR. This allows EIDR IDs to be used everywhere in content workflows; if an alternate ID is needed it can be found in the metadata for the EIDR ID. EIDR supports the inclusion both proprietary and other standard (e.g. ISAN) ID references. Additional Alternate IDs can be added when needed (e.g. by parties wanting to support new workflows). Below is an example of alternate IDs for the EIDR asset 10.5240/EA73-79D7-1B2B-B378-3A73-M (the movie Blade Runner). If an alternate ID is resolvable algorithmically, for example by placing it appropriately in a template URL, EIDR makes that link available.

Alternate IDs are partitioned into non-proprietary and proprietary. The former have distinguished, predefined types (e.g. those issued by ISAN, IMDb, and IVA), whereas proprietary IDs are all of type "Proprietary", and are further distinguished by an associated DNS domain. As of July 2017, there are over 2 million alternate IDs directly available through EIDR.

Content objects can be related to each other according to the following table. These relations are expressed as additional fields in the content record and are thus relative to that object. Note that the subject object is the child and the target is the parent (e.g. subject is<relation-type>Of parent). Additional constraints are noted in the table.

Registration of new assets can be done individually or in bulk (up to 100,000 assets at a time). In either case, the workflow comprises a combination of automated (to perform well-defined but tedious tasks) and manual (where human judgment is called for) processes. It is also iterative, as the initial matching process may identify a variety of gaps and errors that need to be dealt with.

Registering new assets is a complex process that requires some preparation, particularly in the case of bulk submission. The automated processes will check syntax, make sure that the basic metadata is supplied, and that any dependencies (e.g. series records created before constituent episodes) are honored. Manual steps include making sure the correct Parties are associated with the asset. One of the most important steps is ensuring that a new asset does not already exist in the registry: this is covered in the next section.

In order to register a new asset a user must be associated with a party that has been granted the "Registrant" role by the EIDR operator. A registrant may be a principal agent, such as a studio or an encoding house, but it may also be a Party doing bulk registration of back-catalogue items, or a Party acting on behalf of someone else. It is also a requirement that a registrant be an EIDR member. In general, content ownership, metadata authority, and registration capability are separate and unrelated concepts.

This refers to flagging assets being submitted to the registry as falling into one of the following three categories:

• Candidate asset is unique (with respect to existing registry assets).
• Candidate asset is a duplicate of an existing record.
• Candidate asset has a high probability of being a duplicate.

This assessment is based on applying a (large) set of rules to the candidate asset, which results a numerical score. Bucketing occurs as the result of comparing the score to two thresholds:

• Low Threshold: any asset with a score below this value is deemed not to be a duplicate. This is the only case when a proposed record addition or modification will succeed.
• High Threshold: any asset with a score above this value is deemed to (almost certainly) be a duplicate. The proposed record addition/modification will not proceed, and an error status will be returned. Registrants will generally use the pre-existing ID for the item they tried to register, and can add missing information and Alternate IDs to the existing record.

Assets falling between the low and high threshold are deemed to have a high possibility of being a duplicate: the proposed record addition/modification will not proceed until manually reviewed by EIDR operations staff.

An EIDR ID is a specialized example of a Digital Object Identifier (DOI), which in turn is built on top of the Handle System developed by the Corporation for National Research Initiatives (CNRI). The EIDR-specific aspects of the lower layers are described in more detail below.

A Digital Object Identifier, standardized as ISO 26324,[16] seeks to uniquely identify a wide range of digital artifacts including books, recordings, research data, and other digital content. The goal is not just for the IDs to be unique, but persistent and immutable. As opposed to URLs, DOI identifiers stay the same even if the objects move to another location, or become owned by another organization. Here are some of the characteristics of DOI:

• The International DOI Foundation (IDF) enforces previously agreed rules on the constituent Registration Agencies (e.g. EIDR) to ensure continuity. In particular, if an RA ceases operation, the names it hosts will be taken over by another RA.
• The IDF defines rules to which all DOI names must adhere (what kinds of object may be named by a specific RA)
• The DOI system provides a data model, based on a data dictionary, to enable a structured means of expressing metadata (and inter-object relationships).
• The DOI system has its own highly redundant and distributed set of handle and proxy servers.
• All DOI prefixes are of the form "10.NNNN" where 10 is a directory indicator and "NNNN" is a registrant code in the range 1-65535 (e.g. EIDR content records use is 10.5240)

The DOI data model provides the means to associate metadata with each object, as well as policies governing its use. In the words of the DOI Handbook, metadata may include "names, identifiers, descriptions, types, classifications, locations, times, measurements, relationships and any other kind of information related to [an object]." Metadata flows between the following entities:

• Resource Provider: usually the owner of media asset, which is responsible for inputting metadata to the system.
• Registration Agency: the entities that serves as the repository of the assets (and associated metadata). As noted DOI supports a federation of independent RA's, each responsible for a set of assets. EIDR is one such RA. Others include CrossRef for scholarly articles, DataCite for research data, and OPOCE for official publications of the European Union.
• Service User: the entities making queries to RA's retrieve metadata associated with assets. The DOI resolution framework is responsible for dispatching a query to the appropriate RA (the Service User doesn't need to know this).

To foster interoperability between RAs, DOI has the concept of a metadata Kernel. This is a core set of metadata that all objects stored within the DOI framework should have. The full set may be found in the DOI handbook. Interoperability is a large topic extending beyond the scope of EIDR, but the following subset is particularly relevant to EIDR assets:

• referent: an object maintained in the DOI system.
• referentName: the name of the referent (e.g. the title of a movie)
• primaryReferentType: For EIDR, this includes creation (e.g. entertainment assets) and party (e.g. the creator thereof).
• structuralType: these are mutually exclusive categories that identify the form of an asset. Two particularly relevant to EIDR assets are an abstraction (an object such as a movie that may exist in multiple forms) and performance (a specific instance of an object such as Director's Cut).
• principalAgent: for creations, the entity principally responsible for its existence.
• registrationAuthorityCode: denotes the agency that issued the DOI. This would be the EIDR RA for EIDR assets.

EIDR metadata is available in standard DOI kernel metadata format as well as EIDR-specific formats. The DOI for the DOI metadata schema is doi:10.1000/276.

DOI is in turn implemented on top of the Handle System, a distributed, highly scalable, name resolution service. A handle is defined as:

<Handle> ::= <Handle Naming Authority> "/" <Handle Local Name>

The Naming Authority is globally unique and defines both an administrative space and the syntax of the Handle Local Name. For EIDR in the definition above, the "10.5240" is the EIDR Naming Authority, and is responsible for resolving the suffix (including that it conforms to the expected syntax for an EIDR asset). The range of allowable Naming Authorities is more general than is employed by DOI (or EIDR).

The distributed nature of the Handle System allows each local namespace to be hosted on multiple geographically distributed service sites. This is a federated model where each local name space has complete control over the placement and operation of its service sites. Furthermore, each service site may contain multiple resolution servers: requests directed to a particular service site will be dispatched evenly across its constituent servers.

The data model of the Handle System is simple but flexible. An arbitrary number of values may be associated with each handle. Over time, these values may be created, modified, and destroyed. Each such datum has the following attributes:

• index: an unsigned integer that identifies a data value from the others that may exist for this handle.
• type: a UTF-8 string identifying the type. The type system is extensible and common types are maintained as handles in the "0.TYPE" naming authority. There are no restrictions on the creation of new types, although using resolvable handles as type names is recommended best practice. Common types include URL for a single of indirection, "10320/loc" for a set of context-based resolution alternatives, and various administrative types for Handle System management, all of which are based on handle resolution.
• data: the value itself, represented as a sequence of octets which are interpreted in the context of the associated type
• permission: access rights to this particular value. Note that different data values of a handle may have different permissions
• TTL: an integer that specifies how long a value may be cached
• timestamp: an integer (expressed as milliseconds from the Unix epoch) that records the last time the value was updated
• reference: a list of references to other handle values. These are usually used to add credentials (e.g. a digital signature).

Accessing the Handle System is done via a wire protocol defined in RFC 3652; EIDR applications don't have to be concerned with this because of the layering of protocols.