EIDR operates four separate ID registries, each with its own record types and data structures:
- Content ID – identifies audiovisual assets of various types.
- Video Services – identifies services that deliver audiovisual content to consumers.
- Party – identifies organizations such as a registrant or producer.
- User – identifies individuals or integrated systems associated with a particular Party.
All EIDR IDs are members of the Digital Object Identifier (DOI) family (ISO 26324). Each EIDR ID begins with a DOI prefix that identifies the registry that issues the ID:
- 10.5240 – Content ID Records: e.g., 10.5240/CA2D-7927-3635-DD8D-7D75-U
- 10.5239 – Video Services: e.g., 10.5237/2135-296E
- 10.5237 – Parties: e.g., 10.5237/2135-296E
- 10.5238 – Users: e.g., 10.5239/FD14-4D40
Video Services, Party, and User registries each contain a single type of record, as indicated by the registry’s name.
Party and User IDs are referenced internally by the EIDR access control system, where rights and privileges are assigned to Parties and then inherited by all of the Party’s Users. All Registry actions except for Resolution require authentication via User ID and password.
The Content ID registry is more complex than the others and contains a number of different record types, all in service of audiovisual content identification. As noted in Introduction to the EIDR Data Model, the Content ID registry has four fundamental record types:
- Collection – a grouping record such as a Series, Season, or Compilation.
- Abstraction – an abstract work in its most general form, including movies, episodes, and TV specials.
- Edit – creative changes to a work, including both complete versions and clips.
- Manifestation – technical representations and encodings, including language versions (“subs and dubs”).
The nature of a Content ID registry record is most strongly determined by the set of relationships it has (e.g., its position in the parent/child record registration tree) and by its referent type (e.g., Series, TV, Web, Movie, etc.).
The DOI system defines a particular record structure and nomenclature. EIDR extends and adapts this to serve the audiovisual industry. EIDR records are stored in the native EIDR format but can be transposed into the DOI-specific format as needed. See the EIDR DOI Mapping Table for details of mapping EIDR fields to DOI fields.
This section describes the underlying concepts used to describe content records in the EIDR data model. For more information, refer to Introduction to the EIDR Data Model and Best Practices and Use Cases for Abstraction Records.
All content objects in EIDR are categorized by their types and relationships.
EIDR has two general kinds of type:
- Object Type: Equivalent to the meaning of object type in programming languages, which encapsulates the data fields needed for a particular object
- Record Type: Describes the fundamental nature of an object, including its level of abstractness
Object Type: This is an extension of the DOI Kernel metadata. When the unqualified word type is used in EIDR documents, it refers to these object types.
The content record types are divided into two general classes:
- Basic Type: This type covers the minimal possible object. It is sufficient for describing a wide variety of content.
- Derived Types: These types include all the information in the Basic Type, and add extra information for describing more complex objects. The Derived Types in EIDR are Compilation, Series, Season, Episode, Edit, Clip, and Manifestation.
The DOI specification provides and requires two other kinds of type – Structural Type and Referent Type. Both of these are represented as Basic metadata fields:
Structural Type: This is based on a set of four particular structural types provided by DOI. They correspond to increasingly more specific manifestations of a work. Additionally, EIDR has a Record Type that provides a more concise means of referencing an object’s fundamental nature.
|Structural Type||Use||Record Type|
|Abstraction||Used for objects having no reality, such as a series collection or the most basic concept of the original work.||Collection: Series, Season, and Compilation records. (Compilations Abstraction, Performance, or Digital, depending on their contents.)|
|Abstraction: All abstract works, including both stand-alone (such as Movies) and Episodes.|
|Performance||Used for items that are particular manifestations or versions of something, such as the Director’s Cut of a film or the Welsh-language version of a TV show.||Edit: Edits and Clips (Clips being a special kind of Edit).|
|Digital||A particular digital manifestation of a work, such as an MPEG-2 encoding of a movie.||Manifestation: Manifestations are further stratified as being Digital or Physical via their Manifestation Class.|
|Physical||A physical version of an object. EIDR will support this for physical films and tapes in a future release|
Referent Type: In DOI terms, the referent is the item to which the DOI refers and is independent of any particular instantiation. The DOI handbook says, “referentType typically describes the abstract nature of the content of a referent irrespective of its structuralType”. For example, an object created as a Movie is a movie whether it is being shown in a cinema, broadcast as an edited version over terrestrial TV, or streamed over the Internet.
|Series||A collection object for ordered or unordered Seasons and Episodes.|
|Season||A collection object for ordered or unordered Episodes.|
|TV||Content that first appeared via broadcast.|
|Movie||Long-form content that first appeared in a theater (in the US) or a cinema (in most of the rest of the world).|
|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.|
|Compilation||A collection of discrete assets such as are found on a home entertainment product, franchise, etc.|
|Supplemental||This type is for secondary content whose primary purpose is to support, augment, or promote other content. Examples include trailers, outtakes, and promotional documentaries (“making of” pieces.)|
A relationship is a casual term for the way in which two objects are connected. Relationships are described with one or more objects and some metadata. They are classified as:
Inheritance relationships: The object on which the relationship exists can inherit basic metadata fields from the object to which the relationship refers. Only one inheritance relationship may exist on an object. The Inheritance relationships are isSeasonOf, isEpisodeOf, isEditOf, isManifestationOf, and isClipOf.
Dependence relationships: The objects to which the relationship refers have a strong bearing on the basic nature of the object on which the relationship exists. This means that the objects referred to in the relationship must be taken into account when checking for duplicates when an object is created or modified. The dependence relationships are isCompositeOf and isCompilationOf.
Lightweight relationships: There is no inheritance; the objects to which they refer do not influence the underlying nature of the object on which the relationship exists. These relationships are used primarily when moving around the object tree and connecting object trees to each other. The lightweight relationships are isPackagingOf, isPromotionFor, isSupplementTo, and isAlternateContentFor.
There is no structural connection between the Supplemental referent type and the isSupplementTo relationship. Although a content record with referent type Supplemental will typically have isPromotionFor or isSupplementTo to another content record, those relationships can exist on any content record, such as a Clip. Similarly, a Supplemental referent type need not have an isSupplementTo relationship to anything.
Most objects in the registry are related to each other as nodes in a tree. For example, all of the seasons and episodes of a series form a tree rooted in the series object. The registry also supports additional non-parental relationships, such as one object being included in a composite with items from outside its own hierarchy.
Items in a tree can inherit certain fields from their parent. See the Data Fields Reference for full descriptions of these fields. Only metadata from Base Object Data can be inherited. Furthermore, an object can only be part of one tree, so it has only a single chain of inheritance. Lightweight and dependence relationships allow records to interact with objects external to their own hierarchy.
This worldview uses standard computer science terminology: ancestors and descendants, root objects and leaf nodes. Items with both ancestors and descendants are called internal nodes.
An object may depend on another object in some way by including a reference to it. In such cases there is no inheritance, and the metadata of dependents and objects on which they depend have only coincidental relationship to each other. For example, when Manifestation A refers to Manifestation B by reference, A is dependent on B, and when Composite C includes Clip K, C is dependent on K.
Not all combinations of type, inheritance, and dependence are legal. The validation rules are the normative description of legal and illegal combinations. For more information, see the Data Fields Reference.
In order to reduce complexity, the HTTP API for creating and modifying objects is constrained in several ways, rather than exposing a generic data structure to be filled in. Nonetheless, all legal combinations of type and inheritance can be created and modified using the API, and all legitimate relationships to other objects can be added and removed.
The HTTP Create() call and its manifestations in the SDK use CreationType as an argument. This table shows the possible uses of CreationType.
|Creation of Objects||Creation Type|
|Basic Objects||Referent type can be: TV, Movie, Web, Short, Supplemental||CreateBasic or Basic|
|with IsSeasonOfinheritance relationship||Only way to create Season referent type||CreateSeason or Season|
|with information for derived type Series||Only way to create Series referent type||CreateSeries or Series|
|with IsManifestationOf inheritance relationship||Only way to create an object that has IsManifestationOf relationship||CreateManifestation or Manifestation|
|with IsEditOf inheritance relationship||Only way to create an object that has IsEditOf relationship||CreateEdit or Edit|
|with IsClipOf inheritance relationship||Only way to create an object that has IsClipOf relationship||CreateClip or Clip|
|with IsEpisodeOf inheritance relationship||Only way to create an object that has IsEpisodeOf relationship||CreateEpisode or Episode|
|with IsCompilationOf dependent relationship||Only way to create an object of Compilation Referent Type||CreateCompilation or Compilation|
A Referent Type of Movie, TV, Short, Web, or Supplemental can be changed to another one of those referent types. Other Referent Types cannot be changed. For example, the Referent Type of a record can change from TV to Movie, or from Web to Supplemental, but Series cannot change to Movie nor can Season change to TV.
Here is the summary of how relationships can interact with each other.
|Relationship||Type||Can co-exist with||Can be added after creation||Removable?|
|IsEpisodeOf||Inheritance||IsCompositeOf and Any Lightweight||No||No|
|IsManifestationOf||Inheritance Dependence||Any Lightweight||No||No|
|IsCompositeOf||Dependence||IsEpisodeOf and Any Lightweight||To Abstractions but not Collections||Yes|
|IsPromotionOf||Lightweight||Any||Yes||Multiple instances allowed on an object|
|IsPackagingOf||Lightweight||Any||Yes||Multiple instances allowed on an object|
|IsAlternateContentFor||Lightweight||Any||Yes||Multiple instances allowed on an object|
|IsSupplementTo||Lightweight||Any||Yes||Multiple instances allowed on an object|
The Alternate ID field is of particular significance in the EIDR metadata schema. It plays an important role in ensuring the interoperability of EIDR IDs with other existing ID systems.
The field consists of a type, value, and optional relation. For example, an Alternate ID could have a type of ISAN and a value of 0000-0000-61B3-0000-O-0000-0000-2. Proprietary IDs are supported as well, with an added attribute giving the domain within which the ID is valid. For example, an Alternate ID with the type Proprietary, domain spe.sony.com/MPM, and value E0089786000.
The Alternate ID field can also be used by metadata vendors to link EIDR records to vendor IDs that reference external sources of commercial metadata for the asset, such as CITWF, IMDb, or IVA. Studios or other content producers may cross-reference to internal IDs used for other production, distribution, or tracking purposes. EIDR serves as a useful cross-referencing tool for access to a wide variety of external sources of data about each registered asset.
Alternate IDs are also used within the EIDR de-duplication system to help identify similar records that may be described differently thanks to a common Alternate ID.
IDs in DOI registries must be permanent, and the records to which they refer are intended to be permanent. All records should be permanent and persistent absent special circumstances allowing aliasing or other extraordinary changes to the registry. If a record is inaccurate or otherwise corrupted, there are three ways of repairing the situation:
- Correct the descriptive metadata associated with the ID record so that it is complete and correct.
- If a duplicate ID already exists, one ID can be aliased to the other. This is used when a duplicate is registered mistakenly, or when a changed understanding of the underlying assets means that they should now be viewed as identical. Both IDs will still exist, but both will resolve to the same underlying EIDR metadata.
- If an ID really must be deleted (because it was a complete error, such as registering test data in the production system) the underlying metadata is removed and the ID is aliased to a tombstone record. The ID can still be resolved, which is important if it ever made its way into external systems.
An alias is a simple redirection from one DOI to another. An alias is not intended as a general tool; rather, it should only be used for correcting errors. Records cannot be aliased if they have any child records or if they are the target of any lightweight relationships.
Because the tombstone object for deleted records is of type Restricted, only three of its fields have guaranteed values. Other fields are not used.
|Resource Name||“EIDR Tombstone Object”|
Alias chains: An object may be aliased to an object that is itself an alias. If followAlias is true when doing a resolution (the normal case) the chain is followed until it ends up at a resolvable record or the chain is more than five levels deep, in which case the registry returns an aliasContinuation, which contains the last object reached and the object to which it is aliased. You can continue towards a real object by applying a resolve on the item to which the last object is aliased.
Record resurrection: If an EIDR record is erroneously aliased or deleted, it is possible to reclaim the ID and restore it to active use once again. This is a special administrative procedure. Requests for restoration of an aliased or deleted ID should be carefully considered and only made when absolutely necessary.
A Party represents an entity such as a Registrant or a producing agent. A User is an individual (or an abstract thing that can be treated as an individual, such as software program performing an automated task).
All Users are associated with a Party.
All Registry requests except Resolve require User authentication for a User, and all requests allow it.
Only Parties have permissions in the system; a User has all the permissions associated with its parent Party.
A Party can be either Active or Inactive. An inactive Party may not make any modifications to the database; that is, it may not be a Registrant or a Writer, and all Users associated with it are similarly restricted.
There is a predefined Party representing EIDR Operations (10.5237/superparty). Only the EIDR operator has the ability to create or modify Parties.
A Party can have one or more of the following roles in its list of AllowedRoles:
- AssociatedOrg: These are the organizations involved in the creation of a work: production companies, distributors producing local market edits, post houses encoding or transcoding digital works, etc.
- Registrant. The Party that initiated the EIDR record registration, distinct from the Party that created the identified work. The User requesting the creation of a new object must be associated with Party identified as the Registrant of the record.
- AltIDWriter. The Party can add or maintain Alternate IDs in any record in the Registry, even if they are not in that record’s ACL (Access Control List).
- MetadataAuthority: A Party that asserts it has complete and accurate descriptive metadata for the associated asset and agrees to participate in its ongoing maintenance. Need not be the same as the Associated Org(s) or Registrant. This could be the work’s original producer, current distributor, or an interested third party such as an archive or film library.
- EncodingAgent: A Party that produces encodings/transcodings, generally on behalf of a third party producer or distributor. Only used with Manifestations.
- ServiceAdmin: The equivalent of Registrant within the context of the Video Services registry. (All other roles apply to the Content ID registry.)
Additionally, an entity can be registered as:
- Reader: If the entity is on an object’s ACL (Access Control List), it can read objects and metadata that would otherwise be hidden. This applies only to “in development” objects and provenance data.
- Writer: Can read and modify objects, but not create them.
For example, an encoding house that registers new Manifestations is the Registrant for the object. In the strictest sense, they could be the producer as well, but that is not mandated; in this example the rights holder could require that the producer listed for the Manifestation be the same as that for the parent object. The encoding house may also be the EncodingAgent for each item, unless some aspect has been subcontracted to a third party such as a specialist subtitle shop.
A regular record can be created, modified, aliased, or deleted. An in-development record can also be Promoted. It is also possible to read certain types of administrative information about a record.
A Party (and its Users) can only create a new record if it has “Registrant” in the AllowedRoles field.
A Party (and its Users) must be on the object’s ACL in order to be able to create, modify, or read a record’s ACL or detailed provenance metadata. (Anyone can view any record or relationship in the Registry along with basic provenance metadata, except for In-Development records, as noted below).
Other actions are gated by ACLs on the individual records. Each regular record has an ACL for:
- Modify: Can contain Parties that are of type Registrant or Writer. Required to modify an object.
- Delete: Can contain Parties that are of type Registrant or Writer. Required to alias or delete an object.
- ReadACL: Can contain Parties that are of type Registrant, Writer, or Reader. Required to read any ACL.
- WriteACL: Can contain Parties that are of type Registrant. Required to modify any ACL.
- ReadProvenance: Can contain Parties that are of type Registrant, Writer, or Reader. Required to read the full provenance metadata.
In-Development records have two more ACLs:
- Promote: Contains Parties of type Registrant. Required to promote an In Development object to Valid.
- View: Contains Parties of any type. Required to view In Development objects or have them returned from a query.
The following table summarizes possible permissions based on the Role. For a given object, the associated permissions for a particular Party (with a Role) may be more restrictive than what is specified in the table.
|Role\Permission||View||Read ACL||Read Provenance||Modify||Delete||Write ACL||Promote|
If a Role is removed from a Party, any ACL that depends on the presence of that role will disallow the action, even if the Party is in the ACL. For example, if the Writer role is removed from a Party, that Party and its associated Users will not be able to modify records for which it was already on the ACLs for Modify, Delete, WriteACL, and Promote, and will not subsequently be able to be added to the ACLs for Modify, Delete, WriteACL, or Promote on any other objects.
In development records, as opposed to valid records, are records that are registered but not officially released. It is not recommended that records be in this state. They have two more ACLs than valid records:
- Promote: Entities on this list must be of type Registrant. Entities on this list can promote an In Development object to Valid.
- View: Entities on this list can be of any type. Entities on this list can view an in-development object or have them returned from a query.
- Catalog Matching and Registration
- Content Read Operations
- Using Parties
- Content Create and Modify Operations
- Registry Operation Status Codes
- Text Processing and Queries
 “Proprietary” is a term of art from the standards world. In this context it means an ID that isn’t part of an international standard. It does not imply that the ID is private or confidential.
 Or deleted, since delete is a special case of alias.