Metadata Structure

This article will walk you through the fundamentals of the metadata structure, as well as

Metadata Schema

A metadata schema defines the structure of a data model, including field types, field names, access, validation rules, and hierarchy. This model does not comprise any values as the values vary depending on each schema instance.

A schema definition is a type of Dalet Flex object and can be created and edited.

Metadata schema adhere to the following rules:

  • Metadata schema must be associated with an Dalet Flex object type.
  • Whenever a new Dalet Flex object that supports metadata is instantiated, a new metadata instance is automatically created for the object.
  • Metadata schema must have at least one field.

Whenever a metadata schema is saved, a merge occurs to ensure that all the related schema instances are kept up to date with the new data model defined by the updated schema. Therefore, removing a field will result in data loss.

Metadata Instances (Instances of a Schema)

A metadata instance represents a single instance of a metadata schema. A metadata instance is created when an Dalet Flex object, which is associated with a metadata schema, is created. When a new metadata instance is created, all fields associated with the schema are converted to field instances within the metadata instance. Field instances reference the original field and also allow for the capture and storage of a value.

At first it can be hard to grasp the difference between a metadata schema and a metadata instance. Think of a metadata schema as a template for a questionnaire. It comprises a range of questions with a range of field types (multi-select, true/false, description, etc). Although this template defines the structure and the properties of a questionnaire, it isn’t a set of answers in itself. A single questionnaire template can be used to build a whole range of answers in the form of filled out questionnaires. Think of each filled out questionnaire created from the template as an “instance” and the original template as the “schema”. Hence, a metadata schema defines how a metadata instance is structured but not what the values are. A metadata instance is a single instance of a metadata schema with a unique collection of values.

Below is an example of a metadata instance, which is a single instance of the metadata schema shown above. You can see that there are fields that can be filled in with values, whereas the schema above simply defines the data model.

Metadata Fields

As mentioned, a metadata schema is a collection of related fields. Dalet Flex supports a large range of field types to assist with modelling your data in a meaningful fashion. Metadata field types are pluggable and new types can be created using Dalet Flex’s API. This section provides an insight into how to create and configure new fields, as well as what field types and options are available.

Field Types

Metadata field types can be grouped into three main types:

  • Basic: Fields that are classed as structural or container-based (or composite types) and can carry additional fields.
  • Primitive: Represent common, “primitive” data types such as float, integer, and date. These types are basic building blocks for data.
  • Object: These field types represent references to existing Dalet Flex objects.

Basic field Configuration

The following options are available for most field types:

  • Name: A name is unique to the metadata schema.
  • Display Name: A display name can be used to specify how the name is displayed in a user interface. By default the name is used.
  • Description: An optional description can be assigned.
  • Default Value: Some fields support a default value. This is used by Dalet Flex to set the initial value when a field is first instantiated. An example of a field type that supports this is the Integer.
  • Searchable: This option defines whether the field can be searched as part of a search form or via the API.
  • Editable: This option defines whether the field can be edited or is always read-only.
  • Form: The user interface form field to use when editing this field (example include date, text box, text area)

Please take note that the Name and Display Name fields have the following restrictions:

  • Both are mandatory
  • The field name and display name cannot be more than 50 characters in length
  • The field name can only comprise lower case letters, numbers and hyphens. For example, “a-field-name”
  • The field name must be unique within the current metadata definition, meaning that you cannot have two fields with the same name.

Advanced Field Configuration

Multiplicity

Multiplicity allows for more than one instance of this field type to be created. By default, when a field is defined, it results in the creation of one field instance per schema instance. If multiplicity is set, then the number of instances that can be created per field can be controlled. Examples include:

  • 1..* (one to many)
  • 1 (Only one of that field)
  • 0..1 (zero or one)
  • 0..* (zero to many)

Interdependent fields

Another advanced feature of Dalet Flex’s metadata framework is support for interdependent fields. Without interdependent field support, all metadata fields would operate in isolation and have no information about the state of other fields in the same schema. Interdependent field support allows the creator of a metadata schema to link together events generated from one field to updates on other fields. This functionality effectively allows fields to change their state based on changes made to other fields in the same metadata schema. With this functionality, it’s possible to change the state of form fields and show / hide fields depending on user actions carried out. It allows forms to be more dynamic and intuitive.

Permissions Options

Dalet Flex’s metadata framework supports per-field access control. This means that you can specify which user groups can view and edit a particular field in a schema instance. The options available are as follows:

  • Permissions: When this check box is selected, it implies permissions are applied to this field
  • Access: This means that the selected user group has access to the field
  • Read: This means that the selected user group has read access to the field (cannot edit)
  • Edit: This means that the selected user group has edit access to the field (can also read)

Access control when applied to metadata schema, is hierarchical. This means that if access is blocked to a user from higher up the metadata model tree, then branches further down the hierarchy are not visible to the user either.

Allowing the application of access control to individual fields in a metadata schema may seem like overkill but it’s actually incredibly powerful. Often the same metadata instance is presented to different user groups in different parts of an organisation. It is likely that some fields may not apply to some user groups, so hiding them helps to protect private information and also remove clutter from the user interface. The net result of applying access control to individual fields is that users can only see or edit fields that are relevant to them.

Field Validation Options

Validation options allow you to define how values entered into a field are validated. The following fields can be defined:

  • Validation: When this checkbox is selected, validation rules are applied.
  • Required: This is the most simple rule and simply states the validation applies and only fields with values entered will be accepted.
  • Description: This option allows you to provide a description of the validation rule. This can be presented to a user when they are filling in the form field to ensure that they know what the validation rules are.
  • Max. Length: This rule enforces a maximum text length for an entry type.
  • Script: This field allows you to validate a rule against some script. Please see the API Guide for more information on scripting.
  • Class Name: This is an advanced field that allows a developer to specify a class name to be used for the purposes of validating a field entry.

Form Types

When creating a new metadata field, you will be offered the option to choose a form type. The form type defines what input field type will be presented to the user when they enter values into a metadata field in the Dalet Flex console. The form types offered depend on the field type. For example for a field of type text, the user will be offered a standard one-line text input field or a multi-line textarea field.

The supported form types are as follows:

Text: A single line of text.

Textarea: Multiple lines of text.

Password: A password entry box (values hidden from the User).

Radio: A type of graphical User interface element that allows the User to choose only one of a predefined set of options.

Checkbox: A graphical user interface element that permits the user to make a binary choice, i.e. a choice between one of two possible mutually exclusive options.

Select: A select box with one or more values to choose from. For single option types, a drop down is shown, for multi-option types a multi-select box is shown.

Date: A date pop-up, supporting date selection only.

Time: A time pop-up supporting date and time selection.

Colour: A colour picker pop up.

Typeahead: A field that supports typeahead - a list of matching values are offered as the user begins to type a word or phrase. The typeahead form type is very useful when you have an option field type that has a large number of options.

Text Fields: Text fields represent strings of text. Examples of Text field types are:

  • String: A single line of text
  • Password: A single line of text, with the value hidden from the user
  • Text: One or more lines of text

Number Fields: The following options relate to number field types and further extend the capability of fields in the Dalet Flex metadata framework. Examples of number field types are integer and float.

  • Units: For number field types (integer, double) units are available. Examples include bitrate, bits, bytes.
  • Formatting: For number field types, formatting can be provided to control how a number is presented to users.
  • Format Description: This is an optional field that allows for a user to provide descriptive information about the format rules specified.
  • Generated Value: If this option is selected, then the value is auto-generated when the field is initiated.
  • Value Generator: This option will be presented so that the user can select the means by which the value is auto-generated

Unit types are pluggable and new types can be created using Dalet Flex’s API.

Examples of number field types are:

  • Integer
  • Long
  • Boolean
  • Float
  • Double

Date Fields

Date fields are used to capture time-based information. There are 2 main field types:

  • Date: Captures day, year and month (This field upports formatting)
  • Time: Captures day, year, month, hour, minute and second

Complex Fields

A complex field is a special type of field that enables nesting of other fields to make hierarchical data structures. Hence, a complex field acts as a container for other metadata fields. By adding complex fields to existing complex fields, you can nest fields several levels deep to make powerful, description data models. For example, you might create a complex field called “film-details” which contains key fields which describe a film.

A complex field definition:

A complex field instance:

Colour Field

There is a single colour field. This field allows a user to specify a color with a color chooser pop-up. The colour field can be surprisingly useful, particularly when capturing information about look and feel, e.g. in the case of a player definition.

Script Field

There is a single script field. This field allows a user to specify some script. The script field can be surprisingly useful, particularly when capturing information about configuration and runtime processing.

A script field definition:

A script field instance:

Option fields

Option fields allow you to select a value from a set list of options specified when the field is created. There are two types of option fields:

  • Single Option fields: Single option fields allow a user to select only one option form a set list of options.
  • Multiple Option fields: Multiple option fields allow a user to select one or more options form a set list of options.

When defining an option type field, you can enter option values. Each value comprises a name and a display name. You can also select default values, meaning that these values will be selected by default when a field of this type is first instantiated. The order of the individual option values can be set when the field is first defined. When creating a multiple option field, you can select more than one default value. For single option types, only one default value can be created.

A single option field definition:

A single option field instance:

A multi option field definition:

A multi option field instance:

Backing Store fields

When creating an option type field, a user is often expected to enter a static list of options, for example “red”, “green”, “yellow”. But what if the list of options is very large or changing regularly? What if the user does not know what the values are as they are stored in a different system? Backing Store field support is an advanced feature of option field types which addresses these challenges by allowing a user to configure an option type field to dynamically load the option values from an external source. This functionality offers some significant advantages:

  • Data Integrity: If the values are stored in an external system (i.e. a rights management system) then by loading the options dynamically, the user can be sure that the data is always up to date.
  • Easier Integration: This approach avoids data migration between external systems and Dalet Flex. By looking up data from the source as required, there is no need to migrate data and no need to rely on batch scripts and timed updates.
  • Intelligent Workflow: Often workflow decision nodes are driven by values held within metadata fields (i.e. if Content Type = “Movie”, then deliver to iTunes). Therefore workflow can be orchestrated by data contained in other systems without the need for data migration.

To configure an option field to be backing store enabled:

  1. Select the Backing Store checkbox.
  2. Next, select the Backing Store type:
  • File: The values are loaded from a flat file.
  • Database: The values are loaded from an external database.
  1. Next enter the Identifier. The identifier is a text string query that maps to the underlying data store, using Hibernate Query Notation.

External API Backing Store

The External API Backing Store enables users to populate a drop down (single or multi-value fields) in the Metadata Designer with data from an external API.

Once this custom development has been carried out, you can use the External API Backing Store functionality by following these steps:

  1. Open a metadata definition and create a single or multi-value field.
  2. In the configuration panel, select the Backing Store check box.
  3. Expand the Backing Store drop down.
  4. From the Type drop down, select External API.
  5. In the Identifier field, enter the name of an Dalet Flex customer specific service. This name will be registered in Consul.

When Dalet Flex requires values, it calls the Dalet Flex customer specific service, passing in the ID provided in the Metadata Designer, which in turn makes a call to the target external API, converting the data where necessary.

Object Fields

An object field is a field that allows a user to reference an existing Dalet Flex object. For example a user may create a field that references another asset or another user. This concept is extremely powerful as it allows metadata schema to reference other Dalet Flex object types in the system.

The two main types of object field are:

  • Object: Allows a user to define a reference to a specific type of Dalet Flex object.
  • Asset: Allows a user to define a reference to a specific type of Dalet Flex asset.

When making objects available in a metadata instance object field, Dalet Flex will only present objects that the user has visibility of.

See below a user object type defined in the metadata schema:

See below how this is displayed in the metadata instance:

Key-Value Variables

You can add key-value variables to your metadata schema in Metadata Designer. For example, if you had metadata which is associated with an asset, you could have a key-value field for actors-roles. You could have the name of the actor who appeared in the film, and the role they played as a pair in the same field.

A key-value definition:

A key-value field instance:

Internal Schema Types

Dalet Flex’s metadata framework a data-modelling tool in its own right. Elements of Dalet Flex use the metadata framework internally to support advanced functionality. Some of the areas where it is used are:

  • Profiles: Transcode and validation profiles use Dalet Flex’s metadata framework to store information about transcode rules and media validation profiles respectively. Each profile has its own internal Schema.
  • Actions: The configuration information for Dalet Flex actions is managed by Dalet Flex’s metadata framework. Each action has its own internal schema.
  • Resources: The configuration information for Dalet Flex resources is managed by Dalet Flex’s metadata framework. Each resource type has its own internal schema.