This section provides information on registration workflows, modifying records, alias operations, and delete operations.
This section contains a description of synchronous and asynchronous registration workflows, including the usage of the user interface and automated processes.
This is how people are encouraged to use the registry for new Collection and Abstraction registrations (e.g., episodes in a season, movies, one-time-only television, new series). For Edits and Manifestations, any difference in metadata is probably distinguishing and does not normally require manual review (for example, a special version made for international release as opposed to domestic, MPEG4 instead of MPEG2).
In the case of someone performing a manual registration with the user interface, the process is somewhat transparent. If an asynchronous workflow requiring manual review returns a list of potential candidates, someone using the Web UI can review the list of candidates and choose one that matches, make their metadata distinct and resubmit, or request manual review by EIDR staff.
The synchronous workflow results in an immediate response, which could include a candidate list requiring manual review. If there are no candidates (nothing above Low Threshold), the result is immediate success with a new registration. If there is a system error, validation error, or record rejection, the user must fix the submission and resubmit. Otherwise, the system returns either a high single match or a list of candidates for consideration.
When reviewing de-duplication results, the user takes one of the following actions:
- Identifies an exact match. In this case the user has completed the task, though updating the existing record with expanded metadata – including alternate IDs – is recommended practice. If the user does not concur with the exact match identified, the record can be submitted for manual review by setting the dedupMode flag on the Operation element and re-submitting asynchronously.
- The metadata must be modified: the user resubmits synchronously.
- The metadata are correct: the user submits asynchronously to trigger manual review and returns later for status from the token.
- There is a metadata or validation error: the user fixes the metadata and resubmits. There is always the chance of a system error as well, though unlikely.
API calls can be immediate, in which case the result is returned immediately; or asynchronous, in which case the call returns a token which is used to discover the status of the request. Not all calls support asynchronous results; those that do have a flag in the interface specifying which mode to use.
The following diagram illustrates the asynchronous registration process using an automated API-based workflow:
An API-based application submits asynchronously and polls the result for a status of complete or incomplete. If the status is incomplete, the application waits and polls again. If the request is resolved automatically it will likely be returned within 10 seconds. It is advised to program a “back off” for progressively slower polling leading up to a one business day delay for manual review results.
If there is invalid metadata or a system error, a manual workflow may be used, registering in the UI may be attempted, or code logic errors may be identified.
There are three possible outcomes:
- An exact match is found. Compare the metadata for differences. If there is no difference, the process is complete (done). Otherwise, determine if the differences are significant. If they are not, the process is complete (done). If EIDR has incorrect or incomplete information, then the EIDR registry must be updated via a modification workflow.
- If the user has additional data such as an internal studio identifier (Alternate IDs) to be placed on the EIDR record, the user should initiate a modification workflow.
- Process modifications are needed. The EIDR user makes an administrative request to EIDR to add the User to the ACL. After the User is added to the ACL, the UI, API, or an Admin request to EIDR may be used to modify records.
In the case of new registration, there should be no corrections to the metadata and alternate IDs are part of the new registration request. The process is complete (done).
The EIDR Web user interface supports common workflows for registration and modification of objects as well as search and lookup. The Web UI is built on the EIDR HTTP API. The following are some of the use cases supported by the UI.
- Resolve an ID: View its metadata and relationships
- Search for records based on one or more know object attributes
- Create objects, with special screens for common cases (such as OTO)
- Modify objects
- Add or remove relationships for a selected object
- Create objects similar to or related to an existing object in the registry
- Check status of submitted registrations.
This example shows the Create screen of the Web UI with the list of Root and Child Objects that one can register in the EIDR system:
Modifying objects is done by retrieving current information on the object, modifying it, and re-submitting it, which must pass validation and de-duplication. There are APIs for retrieving object metadata and modifying an object.
If a data element is changed in a parent object, then that same element is changed in any child objects that inherited their values from the parent.
Objects having a status of “in development” are not checked by the de-duplication service. They are sent for de-duplication when they are promoted to a status of ”valid”.
Here are the permitted ways to add relationships after object creation:
The dependent relationship IsCompositeOf and the lightweight relationships (IsPromotionOf, IsPackagingOf, IsAlternateContentFor, and IsSupplementTo) can be added to any valid object at any time after original creation.
Any relationship that can be added after creation can be removed.
Modifying objects has two components:
- Changing Base Object Data only (Basic creation type) while preserving all Extra Object Metadata.
- Changing metadata for the creation type with which the object was originally created (Base Object Data plus any applicable Extra Object Metadata).
- Changing metadata for relationships which have been added to the object.