One component of Ooyala Flex that makes it extremely powerful is the Metadata framework. Ooyala Flex's Metadata framework enables Users to define data models (Schema) that comprise a wide range of Field types. In fact a Metadata Schema is simply a collection of related Fields.
Metadata Schema (Structure)
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 a 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 a 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. A full list of Metadata Field Types available is shown in the Metadata Field Types section.
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.
Note: Perhaps the most interesting Field Type is the Object Field type. This field allows Users to reference other Objects in the Ooyala Flex system.
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
- If a Field has already been saved, then the name will no longer be editable. It will be greyed out.
- 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.
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)
- 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.
Implementing Interdependent Fields is beyond the scope of the User Guide, however more information is available in the Super User Guide.
Ooyala Flex's metadata framework supports per-Field access control. This means that Users 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 checkbox 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 the User 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 the User 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 the User 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, Users 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 chooser pop-up
• Typeahead: A field that supports typeahead - a list of matching values are offered as the User types
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 description 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
Note: Unit Types are pluggable and new Types can be created using Ooyala Flex's API.
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, Users can nest Fields several levels deep to make powerful, description data models. For example, a User might create a Complex Field called "rights". They could then add another Complex Field inside called "region". Within each "region" Complex Field, the User could then add Fields pertaining to rights information such as "expiry date".
Complex Field Definition:
Instance of a Complex Field:
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.
Option fields allow Users 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, a User can enter Option values. Each value comprises a Name and a Display Name. A User 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, a User can select more than one default value. For Single Option Types, only one default value can be created.
Single Option Field Definition:
Instance of Single Option Field:
Multi Option Field Definition:
Instance of Multi Option Field:
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 form an external source. This functionality offers some significant advantages to Users:
• 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 check 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.
Note: Hibernate is a popular Object-Relational data mapping framework. This is beyond the scope of the User Guide. Please consult the API Guide for further information.
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. When a Field references another Object, then the Ooyala Flex Console will show a roll-over that can be clicked on to take the User to the Object that is being referenced.
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 an Object of Type Role defined in the Metadata Schema:
See below how this is displayed in the Metadata 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:
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.
The configuration information for Ooyala Flex Actions is managed by Ooyala Flex's Metadata Framework. Each Action has it own internal Schema.
The configuration information for Ooyala Flex Resources is managed by Ooyala Flex's Metadata Framework. Each Resource Type has it own internal Schema.