1. Home
  2. EIDR Data Fields
  3. Data Fields – Introduction

Data Fields – Introduction

This document provides detailed descriptions of the metadata fields stored by EIDR for various types of audiovisual assets. One can use this reference manual to understand the results from EIDR resolutions and queries and to map to and from other metadata systems. Further guidance for EIDR record creators can be found in the Best Practices and Use Cases for Abstraction Records.

The manual is based on the EIDR XML Schema v2.6. All EIDR schemas are available at http://www.eidr.org/schema. The common.xsd and md-v28-eidr.xsd files are the starting point for other useful information about working with EIDR records.

The reader is assumed to be familiar with Introduction to the EIDR Data Model and Registry Technical Overview, which provide an overview of the EIDR System.

Composite Details

Abstraction records (Movie, TV, Short, Supplemental, and Web) can optionally include Composite information (as described in “Composite” below) within an Extra Object Metadata block following the Base Object Data. For example:

<BaseObjectData>
  <ID>10.5240/12C3-9CB2-24BA-03C6-03DB-O</ID>
  <StructuralType>Abstraction</StructuralType>
  <Mode>AudioVisual</Mode>
  <ReferentType>Movie</ReferentType>
  <ResourceName lang="en" titleClass="release">That's Entertainment</ResourceName>
  <OriginalLanguage mode="Audio" type="primary">en</OriginalLanguage>
…
</BaseObjectData>
<ExtraObjectMetadata>
  <CompositeInfo>
    <CompositeClass>Excerpt</CompositeClass>
    <Element>
      <ID>10.5240/1DF4-A55B-62FE-F2BF-B447-V</ID>
      <Description>Fred Astaire in “The Band Wagon”</Description>
    </Element>
    <Element>
      <ID>10.5240/CE08-A846-EB2B-C220-1B14-M</ID>
      <Description>Bing Crosby in “Going Hollywood”</Description>
    </Element>
…
  </CompositeInfo>
</ExtraObjectMetadata>
  • Derived Types – Objects of derived type include extra metadata (in addition to base metadata). The derived object types are: Series, Season, Compilation, Edit, Clip, and Manifestation.
  • Other Relationships – Lightweight relationships that connect records after they have been created. These are created with a small amount of extra metadata in a record.

In order to keep the amount of metadata small, the metadata required for an object has been chosen to meet these requirements:

Basic record syntax is described and enforced by the EIDR schema (e.g., you cannot list more than 4 actors). More complex business rules (e.g., you cannot create an Edit of a Compilation) are described and enforced by registry Data Validation Rules and are described below for each object type.

How to read the Tables

There are tables of metadata fields for each data type. For each of the metadata fields listed in this document, the following information is presented as columns.

FIELD Name: The name of the metadata field in the schema. Field attributes are separated from the field name by an at-symbol (@), while nested field names are separated with a forward slash (/).

type: The data type of the field is usually a standard programming type such as Boolean, integer, or string (including enumerated lists), which are expressed in XML as a simpleType. In other cases, a field is a more complex structure, including attributes and nested data fields.

Each data type is introduced by a simple description with an example followed by the XML definition for that data type.[1]

Many EIDR data types are inherited or extended from other standards, including:

NOTE: Text strings are not case sensitive in the EIDR database. Case should be used to improve readability in a user-provided string (for example in a title).

NOTE: Field names, attribute names, and enumerated values are case sensitive in XML and so will result in an EIDR schema-validation error if not capitalized correctly.

Cardinality: The number of times a particular element can appear within a single record, including if the field is required or optional.

  • Required: Fields required for registration. For child objects (such as series episodes), these fields may sometimes be inherited from the parent record and do not need to be provided directly unless the value is different in the child record.
  • Conditionally Required: Fields that are required under certain circumstances, but are optional in others.
  • Optional: Fields that are optional. Note that in case of child objects some optional fields can be inherited from the parent. Some optional fields are marked Recommended.

The cardinality for optional fields has a range that starts with 0 (such as 0 or 0-1). Required fields start with 1. Repeating items may have an upper limit (such as 1-8 or 0-32) or may repeat an unlimited number of times (1-∞).

NOTE: Required child elements and attributes are only required when their parent, or containing element, is present.

NOTE: For a quick reference to the required fields per record type, see EIDR Required Data Fields for Abstractions, Episodics, and Edits.

EXPLANATORY NOTeS: Additional details regarding the nature of the field. For instructions on how to populate the various fields under both common and unusual circumstances, see EIDR Best Practices Guide.

EIDR IDs

Various interrelated types of unique IDs are used within the EIDR system:

  1. Content ID – This is the ID issued to each unique record in the EIDR Content ID Registry. Whenever an “EIDR ID” is referenced without a qualifier (such as “Party” or “User”) it is a Content ID. These are referred to as assetDOIType in the data Type column, since they are considered “Assets” under the DOI standard. Content records are created and maintained by the EIDR members. The Content prefix in the Registry is 10.5240.
  2. Party ID – This identifies an organization. These are referred to as partyDOIType in the data Type column. Parties can be used is several ways in the EIDR system. For example, they can serve as the registrant of a content record or be referenced in an asset’s metadata as playing a role in the physical production of an audiovisual work. Party IDs are maintained by the EIDR system administrator. A Party used for registering content will have one or more associated Users. The Party prefix in the Registry is 10.5237.
  3. User ID – This identifies a user of the EIDR system. All Users are associated with a single Party. Your EIDR system administrator will supply your User ID and associated Party ID. The User prefix in the Registry is 10.5238.
  4. Video Service ID – This identifies a video content delivery service such as a broadcast network or data feed. These may be arranged in a hierarchy reflecting relationships such as corporate ownership. The Video Service prefix in the Registry is 10.5239.

Each of these IDs belongs to a different namespace (by virtue of their prefixes) and may have a different format for the unique suffix that follows the prefix. For more information, see EIDR ID Format.

See Also

  • Base Object Type
  • Derived Types
    • Series
    • Season
    • Episode
    • Clip
    • Compilation
    • Composite
    • Edit
    • Manifestation
    • Digital Manifestation Tracks
    • Digital Manifestation Containers
  • Other Relationships
  • Provenance Data
  • Fields that have ASCII Equivalents
  • DOI Resolution
  • Data Validation Rules
    • Create Validation
    • Modify Validation
    • Relationship API Validation
    • Promote API Validation
    • Alias & Delete API Validation

[1] In some cases, the XML schema may allow values that are restricted by EIDR Registry validation rules.

Updated on April 10, 2021

Was this article helpful?

Related Articles