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 Ooyala Flex object and can be created and edited. Metadata schema adhere to the following rules:
- Metadata schema must be associated with an Ooyala Flex object type.
- Whenever a new Ooyala 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. When you remove a field, this will result in data loss, so please consider your actions carefully.
Metadata Instances (Instances of a Schema)
A metadata instance represents a single instance of a metadata schema. A metadata instance is created when an Ooyala 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 a screen shot of a metadata instance, which is a single instance of the metadata schema shown in the screen shot above. You can see that there are fields that can be filled in with values, whereas the schema above simply defines the data model.
As mentioned, a metadata schema is a collection of related fields. Ooyala 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 Ooyala Flex's API.
As mentioned previously, metadata schema comprise fields. This section provides an insight into how to create and configure new fields and what field types and options are available.
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 Ooyala 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 Ooyala 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. So you cannot have two fields with the same name.
Advanced field Configuration
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)
Another advanced feature of Ooyala Flex's metadata framework is support for interdependent fields. Without interdependent field support, all metadata fields 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.
Ooyala 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 apply:
- Validation: When this checkbox is selected it implies validation rules are applied. The following fields are also available.
- 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 is another simple rule that, if set, 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.
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 Ooyala 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 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
The following options relate to number field types and further extend the capability of fields in the Ooyala 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: 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: Option will be presented so that the user can select the means by which the value is auto-generated
Examples of number field types are:
Date fields are used to capture time-based information. There are 2 main field types:
- Date: Captures day, year and month
- Time: Captures day, year, month, hour, minute and second
The Date field type also supports formatting.
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:
There is a single colour field. This field allows a user to specify a colour with a colour chooser pop-up. The colour field can be surprisingly useful, particularly when capturing information about look and feel for example in the case of a player definition.
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 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. These values are 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". However 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 address 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 Ooyala 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, simply select the Backing Store checkbox.
Next, select the Backing Store type:
- File: The values are loaded from a flat file.
- Database: The values are loaded from an external database.
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 Ooyala Flex customer specific service. This name will be registered in Consul.
When Ooyala Flex requires values, it calls the Ooyala 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.
An object field is a field that allows a user to reference an existing Ooyala 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 Ooyala 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 Ooyala Flex object.
- Asset: Allows a user to define a reference to a specific type of Ooyala Flex asset.
When making objects available in a metadata instance object field, Ooyala 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:
You can add key-value variables to your metadata schema, in the 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
By now readers will know that Ooyala Flex's metadata framework is very powerful and is in fact a data-modelling tool in its own right. It should therefore come as no surprise that elements of Ooyala 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 Ooyala Flex's metadata framework to store information about transcode rules and media validation profiles respectively. Each profile has it's own internal Schema.
- Actions: The configuration information for Ooyala Flex actions is managed by Ooyala Flex's metadata framework. Each action has it own internal schema.
- Resources: The configuration information for Ooyala Flex resources is managed by Ooyala Flex's metadata framework. Each resource type has it own internal schema.