Skip to main content
MediaBeacon University

Fields Workspace

Defining XMP fields in MediaBeacon.

The Fields workspace defines each XMP metadata field in MediaBeacon using a specific field configuration asset and metadata in that asset defines the parameters of the field.

This interface for configuring fields has changed greatly from previous versions of MediaBeacon, as well as some nomenclature used. Notably the concept of schemas has changed:

  • No Schema Tabs: In past versions of MediaBeacon, a schema (aka URI: Universal Resource Identifier,) was created as a framework for subsequently creating fields. Current versions of MediaBeacon allow independent creation of fields, although a URI must still be defined.
  • No Autogenerated Metaforms: Each schema automatically generated a metaform, but these were not fully editable. Current versions of MediaBeacon do not autogenerate metaforms for fields, preventing a proliferation of unused metaforms.
  • No Namemapping Tab: Fields no longer need to be "namemapped" as each field has a "display name" field.

XMP and Other Metadata Standards

While MediaBeacon offers flexibility for field and metaform definition, it must be stressed that XMP nomenclature standards must still be rigorously followed.

Fields also have a large array of possible settings, some of which have implications for downstream data re-use, data design and governance, user experience, or other substantive things.

For these reasons, sections below will list Background and Best Practices for important points.

Field Configuration Asset Metadata

  • Schema: he identifier that all fields in a schema share.
    • Background
      • In the XMP standard, this is referred to a "namespace URI"
    • Best Practices:
      • Currently is less enforced in MediaBeacon than previous versions, it is generally desirable to have a small number of schema for fields created for private use by an organization.
    • Example:
      http://ns.companyname.com/en/packaging/administrative/1.0/
      • Protocol: Many URI's begin with "http://", but there is no commitment that they be resolvable web resources. The "ns.", therefore denotes this as a namespace, not web page.
      • Organization Name and top level domain: "companyname.com/"
      • Descriptors: "/en/packaging/descriptive" - This can be any number of descriptive identifiers that characterise the use of the schema as a whole, in this example "/en" identifies that the data is in english, "/packaging" identifies the fields are packaging related, and "/administrative" might indicate metadata that is not intended for general users.
      • Version "/1.0": a number that will identify the version of the schema, "1.0" is standard.
      • Ending slash: "/" this is mandatory on all schema names.
      • Allowed characters: a-z, A-Z, 0-9 (as long as a number is not the first character in a string), hyphen "-", and underscore "_". Spaces are not allowed.
  • Internal Name : This is the canonical name of the field, which is the data structure written into XMP and the field's name as it is stored internally in the database.
    • Background:
      • In the XMP standard, referred to as the "local name".
      • Technically, fields are properly referenced to using the XML Expanded Name, composed of the namespace URI and the internal name).
    • Best Practices
      • Allowed characters: a-z, A-Z, 0-9 (as long as a number is not the first character in a string), hyphen "-", and underscore "_".
      • Spaces and slashes "/ \"are not allowed.
  • Display Name: Display name is the default string used to identify a field in the interface, or the name as it is displayed to end users. It can contain any UTF-8 character.
    • Background: This is what used to be referred to as a Namemap or Field Label
  • Type (aka Type Validator): This defines the type of data allowed in a field. See the [Field Types] section for more information on the settings available.
  • UI Element: This setting defines a field's presentation in the interface. See the [Field Types] section for more information on the settings available.
  • Required Edit Level: This setting controls a field's editability compared to a user's group's Edit setting. The group setting must be equal to or higher than a field's setting for a user of that group to edit it. Ranges from 0-9.
  • Required View Level: This setting controls a field's visibility compared to a user's group View setting. The group setting must be equal to or higher than a field's setting for a user of that group to view it. Ranges from 0-9.
  • Index SQL: When enabled, this option will index this field (all values in all assets) as a SQL table The main benefit of this function is that it would allow the field to be used as a Highlight or as an Import/export Key field.
    • Background: By default, MediaBeacon allows up to 29 "String," 10 "Date," and 10 "Integer"-type fields. This can be increased but requires a modification to SQL database settings. A number of predefined fields in MediaBeacon use indexing, so the numbers above do not indicate the number available for use.
    • Best Practice: There are very few reasons to SQL index a field in current versions of MediaBeacon.
      • This setting allows a field to be used in View component's Highlight config.
      • This setting allows a field to be used as a Key Field in the Import/Export Wizard.
  • Index in Research: This option allows a field to be searchable in MediaBeacon. The setting here may be 100kb or 1Mb of metadata per file that is indexed.
    • Best Practice: Which is better? What are the implications of each setting? When would a admin know to se to one or the other?
  • Synchronization Strategy. Will affect how a field's data is written to the SQL database and into Asset XMP.
    • Best Practice: Always keep set to Asynchronous. The only exceptions are: custom fields
  • Display Order: The number here will determine the display order of the field. This field has no function other than when defined in a metaform, and is not inherited when a fields is placed in a metaform.
    • Best Practice: Safe to leave blank.
  • Locale Sorting: Changes rules for the alphanumeric sorting of a field's data in the Web UI, according to the sorting rules for the specified language.
  • Default Value: A value entered here will automatically be pre-filled to the the field whenever it is blank in a metaform.
    • Best Practice: This is best left blank in Field configuration, to be used primarily in metaform configuration
  • Substring Searching Allowed: When enabled, this option allows a field's value to be searched on a substring level.
    • Background:
      • Without this option, MediaBeacon's standard behavior is to break space delimited data into "whole words". So, normally, a search for "great" will return an asset that had a Keyword of "super great"
      • Enabling the substring option is only needed when it is desirable to return an asset containing the value "aubergine" when a search for the strings "gine" or "berg".
    • Best Practice:
      • While of moderate impact on most fields, enabling this option on a field that contains paragraphs of text over hundreds of thousands of files may create unnecessary load on the system.

Predefined XMP Fields

It is highly recommended to leave as is the settings of predefined fields in MediaBeacon. These may have an internal function that require specific settings to operate.

  • Was this article helpful?